The document discusses various software life cycle models that describe the stages a software product undergoes from inception to retirement. It explains that software life cycle models encourage systematic and disciplined development. Each model has entry and exit criteria for phases. Following no clear model can make progress difficult to track. The document then covers various life cycle models like waterfall, prototyping, incremental, spiral and object-oriented models. It analyzes the strengths and weaknesses of each model and concludes that a mix-and-match approach works best depending on factors like organization and product.

1. 1

2. Software life cycle model
 software life cycle
series of identifiable stages that a software
product undergoes during its lifetime
software life cycle model
It is a descriptive and diagrammatic
representation of software life cycle
2

3. Why Software life cycle model?
It encourages development of s/w in a systematic and
discipline way
It is necessary to have precise understanding among
team members otherwise it will lead to chaos and
project failure
3

4. PHASE ENTRY AND EXIT CRITERIA
 Every software life cycle model normally define entry
and exit criteria every phase
 A phase can begin only when corresponding phase
entry are satisfied
4

5. 99% complete syndrome
 When there is no clear specification of the entry and
exit criteria for every phase and if no life cycle model
is followed
 It becomes very difficult to chart the progress of the
project
5

6. Software process model
Attempt to organize the software life cycle by
defining activities involved in software production
 order of activities and their relationships

Goals of a software process
standardization, predictability, productivity, high
product quality, ability to plan time and budget
requirements

7. Code&Fix
The earliest approach
 Write code
 Fix it to eliminate any errors that have been
detected, to enhance existing functionality, or to
add new features
 Source of difficulties and deficiencies


impossible to predict
impossible to manage

8. Models are needed
Symptoms of inadequacy: the software crisis
scheduled time and cost exceeded
user expectations not met
poor quality
The size and economic value of software
applications required appropriate "process models"

9. The Waterfall Model
9

10. Waterfall Model Assumptions
1. The requirements are knowable in advance of
2.
3.
4.
5.
implementation.
The nature of the requirements will not change very
much
 During development; during evolution
The requirements are compatible with all the key
system stakeholders’ expectations
 e.g., users, customer, developers, maintainers,
investors
The right architecture for implementing the
requirements is well understood.
There is enough calendar time to proceed
sequentially.
10

11. Process for Offshore?
Analysis
Design
Construct
System test
Accept. test
Deploy
11

12. 12

13. Disadvantages of waterfall
model
 Real projects rarely follow sequential flow
 Difficult for the customer to state all requirements
 Customer to show patience. Working version of
program will not be available until late in the project
13

14. Evolutionary Models:
Prototyping
14

15. Prototyping model
This begins with requirement gathering . Developer
and customer meet and define overall objectives for
the s/w
Then quick design occurs which focus on
representation of those aspects of the s/w that are
visible to customer
After the quick design prototype is build and then
evaluated and feedback given
15

16. 16

17. Evolutionary process models
All the linear sequential models are design for
straight line development
In waterfall model complete system will be delivered
after linear sequence is completed
The prototyping is designed to assist the customer in
understanding requirements
17

18. Incremental Models:
Incremental
18

19. Incremental model
The incremental model combines elements of linear
sequential model with iterative nature of prototyping
For example: word processing s/w
First increment product is core product which is used
by customer in which modifications he can add
The process is repeated until the complete product is
produced
19

20. Usefulness of the model
 When staffing unavailable for whole complete
implementation by business deadline
 Increments can be planned to manage technical
risks
 Best when: you encounter a difficult deadline that
cant be changed
20

21. If we rely on testing alone, defects created
first are detected last
User
Need
system test plan
System
System
Requirements
Testing
software test plan Software
Software
Requirements
Testing
integration plan
Software
Integration
Design
Testing
unit plan
Software
Unit
Implementation
Testing
time
Product
Release
21

22. Incremental Models: RAD Model
22

23. Risk
Exposur
e
23

24. Unified
A software process that is:
Process
use-case driven
Model
architecture-centric



iterative and incremental
Closely aligned with the
Unified Modeling Language (UML)
24

25. The Unified Process (UP)
inception
25

26. UP Work Products
inception
26

27. Lifecycle for Enterprise Unified Process
inception
27

28. Synchronize-and Stabilize Model
 Microsoft’s life-cycle model
 Requirements analysis—interview potential
customers
 Draw up specifications
 Divide project into 3 or 4 builds
 Each build is carried out by small teams
working in parallel
28

29. Synchronize-and Stabilize Model
(contd)
 At the end of the day—synchronize (test and
debug)
 At the end of the build—stabilize (freeze build)
 Components always work together
› Get early insights into operation of product
29

30. Evolutionary Models:
The Spiral
30

31. Spiral Model
Simplified form
 Waterfall model plus
risk analysis
Precede each phase
by
 Alternatives
 Risk analysis
Follow each phase
by
 Evaluation
 Planning of next
phase
31

32. Simplified Spiral Model
If risks
cannot be
resolved,
project is
immediately
terminated
32

33. Full Spiral Model
Radial dimension: cumulative cost to date
Angular dimension: progress through the
spiral
33

34. Full Spiral Model (contd)
34

35. Analysis of Spiral Model
Strengths
Easy to judge how much to test
No distinction between development,
maintenance
Weaknesses
For large-scale software only
For internal (in-house) software only
35

36. Object-Oriented Life-Cycle
Models
Need for iteration within and between phases
 Fountain model
 Recursive/parallel life cycle
 Round-trip gestalt
 Unified software development process
All incorporate some form of
 Iteration
 Parallelism
 Incremental development
Danger
 CABTAB
36

37. Fountain Model
Features
Overlap
(parallelism)
Arrows (iteration)
Smaller
maintenance circle
37

38. Software Process Spectrum
Crystal Clear
XP
DSDM
SCRUM dX
lightweight
ICONIX
FDD
middleweight
Crystal Violet
OPEN
EUP
RUP
heavyweight
38

39. Conclusions
Different life-cycle models
Each with own strengths
Each with own weaknesses
Criteria for deciding on a model include
 The organization
 Its management
 Skills of the employees
 The nature of the product
Best suggestion
 “Mix-and-match” life-cycle model
39

40. 40

41. What is MDA in essence?
Automated approach to translate high level
design to low level implementation by means of
separation of concerns
From high-level model to running application
Risk proportional to expectations!
41

42. Finding the “right” language
Developer
IDEs & 4GL
3GL
Automation
Abstraction
Model Driven Architecture
Assembler
Computer Hardware
42

43. Martin Fowler
43

44. Model Driven Architecture
Can you actually have incremental MDA?
Or is it automated waterfall?
Need rigorous models
Need high quality requirements
Capture requirements
Understand requirements
44

45. MDA or Offshore?
Automation versus reduce cost of labor
Objectives
Reduce required intelligence
Increase repetition
Goal
Reduce costs of development
45