1. CS3300 Fall 2015 Software Development Lifecycles

2. What is a lifecycle? (SDLC) A description of the development effort from birth to death (the project lifetime). Sometimes referred to as a Software Process Model The lifecycle processes defined in ISO 12207 includes processes divided into groups.

4. The Development Processes Primary: Acquisition, Supply, Development, Operation, and Maintenance Supporting: Documentation, Configuration Management, Quality Assurance, Joint Review, Audit, Verification, Validation, Problem Resolution Organizational: Mangement, Infrastructure, Improvement, Training, Tailoring

5. Life Cycle: Simple Definition The Order we do things, and when we can start something else We read papers for three life cycles:  Waterfall  Spiral  Evolutionary Prototyping with Risk Reduction

6. Winston Royce Written in 1970, probably the most maligned, misquoted and misunderstood paper ever written For example: “The waterfall model has many well- documented shortcomings including lack of feedback between phases [Royce 70]”. Figure 2 vs Figure 4

7. Are these valid? No feedback between phases Completely document driven Requires requirements be “frozen” early One phase must complete before another can start No Customer interaction after first requirements effort

8. From Facebook Post: is telling us how the waterfall model is not so bad.

9. Code and Fix Simplest lifecycle: No documentation, no design, maybe some requirements, just write code and fix bugs until product complete Where waterfall is document-driven, this is a total code-driven approach

10. Spiral Model Barry Boehm, USC, 1988 What is the major feature of this model? Why called the spiral? Fail Fast philosophy

11. Some claims Spiral model is adaptable to ANY development project. Most applicable to large, complex software efforts

12. What happens when customers totally don’t know what they want? Enter evolutionary prototyping Think about specifying your desired car to an automotive engineer Picture from Steve McConnell Rapid Development

13. Evolutionary Prototyping Claims Use when requirements change rapidly Customer won’t commit to requirements Nobody understands the application domain well. Developers unsure of algorithms or architecture to use Impossible to know how long project will take at outset Don’t know how many iterations are required Less likely to have project cancelled since customers see progress regularly Can degenerate into Code and Fix Early detection and resolution of requirements conflicts

14. McConnell Selection Table Rapid Development – dated but excellent book for those who think they want the project management side of life Also recommend “Death March” surviving the death march project