1. Software Life-Cycle Models
Life-cycle model (formerly, process model)
The steps through which the product progresses
Requirements phase
Specification phase
Design phase
Implementation phase
Integration phase
Maintenance phase
Retirement

2. Overview Build-and-fix model Waterfall model Rapid prototyping model
Incremental model
Extreme programming
Synchronize-and-stabilize model
Spiral model
V model
Object-oriented life-cycle models
Comparison of life-cycle models

3. Build and Fix Model
Product is constructed with no specifications

4. Build and Fix Model Problems Totally unsatisfactory
No specifications
No design
Totally unsatisfactory
Need life-cycle model
“Game plan”
Phases
Milestones

5. Build and Fix Model Disadvantages
Cost: changes are made in the later phases of software development life cycle
Maintenance is difficult

6. Waterfall Model
Requirements determined and checked by the client and SQA group.
Specifications drawn
Specification checked by the SQA group and shown to the client.
Sign off the specification document,
Software project management plan - checked by SQA group

7. Waterfall Model
Design -“how to do”. If some problems in specification (Incomplete, contradictory and ambiguous.)
Incomplete-: some features of the product have been omitted.
Contradictory-: two or more statements in the specification document differ.
Ambiguous-: the specification document has more than one possible interpretation.

8. Waterfall Model Implementation: If flaws--
Feedback loops permits modification to be made to design document, specification document and requirement if needed.
Documentation :
No phase without documentation
Also approved by SQA group.

9. Waterfall Model
Acceptance Testing: when the product is completed it is given to the client for testing. Deliverables at this stage include the user manual and other documentation listed in the contract. When the client agrees that that the product is as per the specification document, the product is installed on the client’s machine.
Installation
Maintenance- changes made after the installation of the product are handled in this phase.

10. Waterfall Model (contd)
Characterized by
Feedback loops
Documentation-driven
Advantages
Enforce the documentation after every phase
Products of each phase checked by SQA.
Testing is Inherent in every phase
Dynamic model-feedback loops
Maintenance easier

11. Waterfall Model (contd)
Disadvantages
Specification documents are long, detailed and very boring to read.
Client is inexperienced in reading software specification document because the specification document is written in the style client won’t understand.
The first time the client see a working product is only after the entire product has been coded.

12. Rapid Prototyping Model
Build a rapid prototype
The client and future users interact and experiment with it.
Once the client is satisfied, the developer can draw up specification document.
The feedback loops are not required in this model as the working prototype has been validated by the client, it is reasonable to expect that the resulting specification document will be correct. .

13. Rapid Prototyping Model
In the rapid prototyping model, the fact that a preliminary working model has been built tends to lessen the need to repair the design during or after the implementation.

14. Rapid Prototyping Model
Construct the prototype as rapidly as possible
The developers should develop the rapid prototype as rapidly as possible the speed up the software development process.
Use of rapid prototype - determine what the client’s real needs are;
Rapid prototype implementation is discarded
Internal structure of rapid prototype is not relevant.
Prototype is modified rapidly to reflect client need.

15. Waterfall and Rapid Prototyping Models
Waterfall model
Many successes
Client needs
Rapid prototyping model
Not proved
Has own problems
Solution
Rapid prototyping for requirements phase
Waterfall for rest of life cycle

16. Rapid Prototyping Model
Advantages
As compared to waterfall model –
Development of the process is linear preceding from rapid prototype to delivered product.
Feedback loops are less likely to be (needed) in this case.

17. Rapid Prototyping Model
Disadvantages
If user cannot be involved throughout the life cycle this model is not useful.
Development time may not be reduced if reusable components are not available.
Highly specialized and skilled developers are expected and such developers may not be available easily.
Client expects changes to made as rapidly as the rapid prototype

18. Incremental Model
The product is designed, implemented, integrated and tested as a series of incremental builds, where a build consist of code pieces from various modules interacting to provide a specific functional capability.

19. Incremental Model
At each stage- a new build is coded and then integrated and tested as a whole.
Break up the target product into builds subject to constraint that each build is integrated into existing software, the resulting product must be testable.

20. Incremental Model
If a product has too many builds, then at each stage, considerable time is spent in the integration testing of only a small amount of additional functionality. On the other hand, if a product has too few build then the incremental model degenerated into build and fix model.
Analysis –
In waterfall and rapid prototyping model –
deliver to client a complete product
There is project delivery date
Incremented Model – It deliver an operational quality product at each stage

21. Incremental Model (contd)
Advantages
Gradual introduction of the product via this model provides time for the client to adjust to the new product.
Change and Adoptions are natural

22. Incremental Model (contd)
Disadvantages
Each additional build has to be incorporated into existing structure without destroying what has been made till date.
Addition of new build should be simple and straightforward.
Incremental model does not distinguish between developing a product and maintaining it.
Begin with a design that support entire product
View product as a sequence of builds, each independent of next.

23. Incremental Model (contd)
More risky concurrent version—pieces may not fit

24. Extreme Programming Somewhat controversial new approach
Software development team determines the various features (Stories)
Estimate duration and cost of each feature
Client select features for next build using cost benefit analysis
Each build is divided into tasks
Test cases for task are drawn up first
Pair programming (working with a partner on one screen)
Continuous integration of tasks

25. Extreme Programming
Tasks are integrated into the current version of the product
Test cases used for the tasks are retained and utilized in all further integration testing

26. Unusual Features of XP
Computers are put in center of large room lined with small cubicles
Client representative is always present
No individual can work overtime for 2 successive weeks
No specialization. All members of XP team work on specifications, design, code and testing
There is no overall design is modified while the product is being built. The design is modified while product is being built. This procedure is known as refactoring

27. Evaluating XP
XP has had some successes on small and medium sized projects
Good when requirements are vague or changing
Too soon to evaluate XP

28. Synchronize-and Stabilize Model
Microsoft’s life-cycle model
Requirements analysis—interview potential customers and extract a list of features with priorities set up by the customers
Draw up specifications
Divide project into 3 or 4 builds
First build consists of the most critical features, the second build consists of the next most critical features and so on.
Each build is carried out by small teams working in parallel

29. Synchronize-and Stabilize Model (contd)
At the end of the day all the teams—put together the partially completed components and synchronize (test and debug)
At the end of the build—stabilize (freeze build i.e. any remaining faults that have been detected are fixed).
Repeated synchronization steps ensure that the components always work together
Developers get early insights into operation of product and can modify the requirements

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

31. Simplified Spiral Model
If risks cannot be resolved, project is immediately terminated
Prototypes can be effectively used to provide information about certain classes of risks

32. Full Spiral Model
Represents cumulative cost to date and progress through the spiral
Each cycle of the spiral corresponds to a phase
Phase begins by determining objectives of that phase, alternatives for achieving those objectives, and constraints imposed on these alternatives
Strategy is analyzed from view point of risk
If all risks are successfully resolved development starts
Then the results of the phase are evaluated

33. Full Spiral Model (contd)

34. Analysis of Spiral Model
Strengths
Incorporation of software quality
Easy to judge how much to test as risks for too much and too low testing are analyzed
No distinction between development, maintenance i.e. maintenance is treated same way as development
Weaknesses
For large-scale software only. In case of contract all risk analysis should be made before the contract is signed.
Skilled developers are required for analyzing and detecting potential risks
For internal (in-house) software only

35. 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

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

37. V Shaped Software Life cycle Model
There is a shift in testing activities from validation to verification where we want to review/inspect every activity of software development life cycle.
These verification activities are treated as error preventive exercises and are applied at requirements analysis and specification phase, high level design, detailed design phase, implementation phase.
We not only want to improve the quality of end products of all phases but also want to design test cases and test plans during these phases.
V shaped model is the modified form of waterfall model with a special focus on testing activities at every phase.
Workshop on "How to find software faults before our customers find them" Copyright©2007

38. V Shaped Software Life cycle Model
Requirements Analysis and Specification
Acceptance Testing
High level design
System testing
Detailed design
Unit and Integration testing
Implementation A B C
Development Part
Testing Part
A: Acceptance test cases design and planning
B: System test cases design and planning
C: Unit and integration test cases design and planning
Workshop on "How to find software faults before our customers find them" Copyright©2007

39. V Shaped Software Life cycle Model
The model brings the quality into the development of our products
The encouragement of writing test cases and test plans in the early phases of software development life cycle is the real strength of this model.
We require more resources to implement this model as compared to waterfall model.
LIMITATIONS
This model suffers from many disadvantages of waterfall model like non availability of working version of the product until late in the life cycle, difficult to accommodate any change etc. this model has also limited applications in today’s iterative software processes
Workshop on "How to find software faults before our customers find them" Copyright©2007

40. 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

41. Conclusions Life cycle model Strengths Weaknesses Build and fix
Fine for short programs that will not require any maintenance
Totally unsatisfactory for nontrivial programs
Waterfall model
Disciplined approach
Document driven
Delivered product may not meet client’s needs
Rapid prototype model
Ensure that delivered product meets client’s needs
Not yet proven beyond all doubt
Incremental model
Maximizes early return on investment
Promotes maintainability
Requires open architecture
May degenerate into build-and-fix

42. Conclusions Life cycle model Strengths Weaknesses Extreme programming
Maximizes early return on investment
Works well when client’s requirement are vague
Has not yet been widely used
Synchronize and stablize model
Future user’s needs are met
Ensures components can be successfully integrated
Has not been widely used other than Microsoft
Spiral model
Incorporates features of all the models
Can be used only for large scale in-house products
Developers have to be competent in risk analysis and risk resolution

43. Conclusions Life cycle model Strengths Weaknesses V shaped model
Incorporates testing at each phase
Usable product will be deliver very late
Object-oriented models
Support iteration within phases, parallelism between phases
May degenerate into code a bit test a bit (CABTAB)