Ch No. 1

2. Importance of software
Software can have a huge
impact in any aspect of
society.

3. Where can you find
software?

4. Some popular ones…

5. Some popular ones…

6. And even in…

7. Conclusion
Software is Almost
Everywhere.

8. Problems in software
development

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

11. Chaos Report

12. Conclusion
Programming is NOT enough!
It is not enough to do your best: you must
Know what to do, and THEN do your best.
-- W. Edwards Deming

13. Solution

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)

20. Build First
Version
Modify until
Customer satisfied
Operations
Retirement

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

22. Requirements
Validate
Design
Verify
Implementation
Test
Operations
Retirement

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

26. Requirements
Requirements Change
Validate
Design
Verify
Implementation
Test
Operations
Retirement

27. Requirements
Rapid Prototype Change
Validate
Design
Verify
Implementation
Test
Operations
Retirement

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%)

30. Requirements
Validate Architectural
Design
Verify
Detailed Design,
Implement, Test,
Deliver Feature Set
Operations
Retirement

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