9. Common issues
•The final Software doesn´t fulfill the needs of the
customer.
•Hard to extend and improve: if you want to add a
functionality later is mission impossible.
•Bad documentation.
•Bad quality: frequent errors, hard to use, ...
•More time and costs than expected
14. Software Engineering
What is it?
The application of a systematic, disciplined,
quantifiable approach to the development,
operation, and maintenance of software, and
the study of these approaches; that is, the
application of engineering to software.
-Wikipedia
15. Software Engineering
What is it?
The study and application of methodologies to
develop quality software that fulfill customer
needs.
16. Software Engineering
Objetive
To produce software that is:
• On time: is deliver at the established date.
• Reliable: doesn´t crash.
• Complete: good documentation, fulfill
customer needs.
17. Process means the events or tasks a development organization
does, and their sequence
› Again, think about construction
Organizations want a well-defined, well-understood,
repeatable software development process. Why?
Find and repeat good practices
Management: know what to do next; know when we’re done
with current task; know if we’re late; estimate time to
completion, costs; Etc.
New team-members know what to do
17 (CS340 J. Knight & T. Horton 2008)
18. Major Task Identification
Sequencing
General model to be tailored
19. There are general principles about:
› What we do at various stages of SW development
› How to inject quality into SW
› How to avoid early problems that cause huge
problems later
› Recognize that SE is not just writing code
No matter what process you end up doing,
these general principles are the most important
“take-away” from this material
19 (CS340 J. Knight & T. Horton 2008)
21. Really Bad
Really Common
Advantages
› No Overhead
› No Expertise
Disadvantages
› No means of assessing progress
› Difficult to coordinate multiple programmers
Useful for “hacking” single-use/personal-use programs:
start with empty program and debug until it works
23. REQUIREMENTS
ANALYSIS
SYSTEM
DESIGN
PROGRAM
DESIGN
CODING
UNIT & INTE-
GRATION TESTING
SYSTEM
TESTING
ACCEPTANCE
TESTING
OPERATION
& MAINTENANCE
24. Articulated by Win Royce, ~1970
Widely used today
Advantages
› Measurable progress
› Experience applying steps in past projects can be used in
estimating duration of “similar” steps in future projects
› Produces software artifacts that can be re-used in other projects
The original waterfall model (as interpreted by many) disallowed
iteration
› Inflexible
› Monolithic
› Requirements change over time
› Maintenance not handled well
The “waterfall with feedback” model was, however, what Royce
had in mind
25. REQUIREMENTS
ANALYSIS
SYSTEM
DESIGN
PROGRAM
DESIGN
CODING
UNIT & INTE-
GRATION TESTING
SYSTEM
TESTING
ACCEPTANCE
TESTING
OPERATION
& MAINTENANCE
28. Initial Concept
Design and
Implement
Initial Prototype
Refine Prototype
Until Acceptance
Complete and
Release
Prototype
29. Prototypes used to help develop requirements
specification
› Useful for rapidly changing requirements
› Or when customer won’t commit to specification
Once requirements “known”, waterfall (or some other
process model) is used
Prototypes discarded once design begins
› Prototypes should not be used as a basis for implementation,
since prototyping tools do not create production quality code
› Customer may need to be “educated” about prototypes, a
prototype is not 80-90% of the final product (not even 10%)
31. Iterations are classified according to feature
sets
› e.g., features 1 and 2 will be delivered
in this iteration, features 3 and 4 are
next
Series of increasingly “complete”
releases
32. DETERMINE GOALS, EVALUATE ALTERNATIVES
ALTERNATIVES, AND RISKS
CONSTRAINTS traints 4 Risk analysis 4
Cons
traints 3 Risk analysis 3
4 Cons
s
t ive
na
lt er traints 2 Risk analysis 2
A es
3 Cons
a tiv
rn
Alte es
2
Co
tiv
na ns Risk analysis 1
er tra Proto - Proto - Proto -
Alt Alte
rna int
tive s Prototype type 2 type 3 type 4
Budget 4 Budget 3 Budget Budget s 1 1
1 1
2
start Requirements, Concept of Detailed
sig re
e nts
de ftwa
design
life-cycle plan operation ar me
n
ftw ire
So
De
Int vel
op So qu
e
an grat pla men d re
date ts
dt i
es on
n t Vali iremen Code
tp requ ,
lan dated ign
Vali des
fied
veri Unit test
PLAN System DEVELOP AND TEST
test
Acceptance
Implementation
test
plan
33. Proposed by Barry Boehm, ~1986
Similar to Incremental Model, but each iteration
is driven by “risk management” and/or customer
feedback
Determine objectives and current status
Identify risks and priorities
Next iteration addresses (current) highest risk and/
or highest priority items
Repeat
Hinweis der Redaktion
i. The final Software doesn´t fit the needs of the customer ii. Hard to extend and improve: if you want to add a functionality later is mission impossible Bad documentation, bad software design iii. Bad quality: frequent errors, hard to use... iv. More time and costs than expected
Coming back to the Chaos Report 2006, the thing that doesn’t change significantly over all those years is percentage of projects with time or budget overrun. It still oscillates around 50%
In simple terms, is the study and application of methodologies to develop quality software that fulfill customer needs.
In simple terms, is the study and application of methodologies to develop quality software that fulfill customer needs.
On time: deliver at the established date Reliable: doesn´t crash often, etc Complete: good documentation, fulfill customer needs
[Royce 1970] - DoD contracts PROS: Focuses attention Easy to explain to customers Intermediate products are made explicit CONS: Does not really reflect how software is produced Imposes PM structure - no explanation of how artifact from one stage is transformed in the next Failure to treat software as problem-solving process
[Royce 1970] - DoD contracts PROS: Focuses attention Easy to explain to customers Intermediate products are made explicit CONS: Does not really reflect how software is produced Imposes PM structure - no explanation of how artifact from one stage is transformed in the next Failure to treat software as problem-solving process
[Boehm 88] Viewed in light of risks involved Combine development with risk MGT