1. Software Development Process Models Derived from Dr. Fawcett’s slides Phil Pratt-Szeliga CSE 784 Fall 2009

2. Overview Definitions Software Process Model Process Models  Waterfall  Spiral  Incremental Development  Design by Contract  Evolutionary  Extreme Programming  Microsoft Development

3. Definitions Model  A representation of the most essential features of a physical object or process  Used as a pattern for reasoning about, analyzing, or predicting behavior Software Process Model  A model of the phases, activities, products and roles of people involved with the development of software

4. Software Process Models: Overview A model of the way software is built Production of large scale software is a complex endeavor  Many documents are produced  Code is written Product code Prototype code Test code  Many reviews are held internally with the development team and for the customer  Enormous amounts of data are collected and used to manage the development and keep developers and customer apprised of the program’s status Models are used to  Guide developers in their day-to-day activities  Keep the program focused on it’s principle objectives  Promote communication through the use of standardized documentation and reviews

5. Waterfall Process Model A software development process that proceeds linearly in time through phases Originally taken from the construction industry where some types of changes late in the project can be prohibitively expensive or impossible Requirements Analysis design code and Unit Test integration test Qualification Test

6. Waterfall Development Roles Software Product Manager  Responsible for cost and schedule  Has ultimate authority on all software development decisions  Depends on Architect, Test Manager and Team Leaders to implement decisions

7. Waterfall Development Roles Software Architect  Responsible for top-level software partitioning, defining user interfaces  Manages interfaces between software developed by each team  Is the source of knowledge on how the system works

8. Waterfall Development Roles Test Manager  Responsible for Test Plan and Qualification  Develops, with the test team, test descriptions and procedures, usually by assigning them to individual teams for elaboration  Conducts the Test Readiness Review and Qualification Test

9. Waterfall Development Roles Team Leader  Responsible for one subsystem – may be one module or a family of modules  Responsible for production of B and C specifications for the team’s software Presents his or her B-Spec at the Software Requirements Specification Review Usually delegates C-Spec development to team members  Responsible, with other team leaders, for software integration  Responsible to fully support Test Manager for the team’s part of the system, including production of Test Descriptions, Test Procedures and test conduct

10. Waterfall Development Roles Team Members  Responsible for their assigned part of the team’s C-Specification, code and unit test  Usually present at two reviews Preliminary Design Review Critical Design Review

11. Waterfall Development Roles Quality Assurance  Responsible for continuing assessment of the software quality  Reports to the Program Manager

12. Waterfall Model: Customer Reviews Requirements Analysis  Software Specification Review Architecture B-Spec (DFDs + HIPOs + Data dict + RTM) Derived Requirements Design and requirements issues

13. Waterfall Model: Customer Reviews Design  Preliminary Design Review Module Structure Preliminary C-Specs  Module Charts, Structure Charts  Class Structures, HIPOs Resolution of design and requirements issues Derived Requirements Design and test issues  Critical Design Review Full C-Specs with Pseudo-code Resolution of design and test issues

14. Waterfall Model: Customer Reviews Code and Unit Test  Informal code walkthroughs and inspections Integration Testing  Test Readiness Review (TRR) Major Test Groups Test Procedures Test Equipment, environment

15. Waterfall Model: Customer Reviews Qualification Testing  Formal, step-by-step proof that system meets A and B level specification requirements Demonstration Inspection Analysis Test

16. Waterfall Model: Reviews Audits:  Functional Configuration Audit (FCA) an Audit of both contracting office and contractor by outside agency to verify that contractual obligations have been met. Includes specification and test report reviews.  Physical Configuration Audit (PCA) an Audit of both contracting office and contractor by outside agency to verify that all the component parts purchased by the contract are in fact the ones tested and delivered.

17. Waterfall Model: Summary The waterfall model does a good job of capturing the essentials of large software development process  Activities Required  Roles of Specific Project Personnel  Products Generated It does not do a very good job of accounting for many realities of the development process:  Need for constant change due to: Requirements, Design and Implementation errors Performance deficits Accommodation of changes in another part of the system  Need to carefully control change  Discovery of unforeseen risks  Uncertainty of scheduling work that the team has not done before

18. Waterfall Model: Summary The failing of the waterfall model has prompted the development of several new variations  Incremental Development  Spiral Model  Design by Contract  Extreme Programming  Combinations of two or more of these

19. Side Note: Capability Maturity Model (CMM) Describes software development process in terms of five levels  Level 1 – Initial Ad hoc process, unpredictable results  Level 2 – Repeatable Disciplined process using standard management principles Key Process Areas:  Requirements Management, Project Planning, Project Tracking and Oversight, Configuration Management, Quality Assurance  Level 3 – Defined Standard Process applied consistently across organization  Level 4 – Managed Predictable Process using metrics gathered as part of the applied process  Level 5 – Optimizing Continuously improving process with a mandated process for defect prevention

20. Spiral Model Development proceeds through several prototypes, culminating in the completed system. Each prototype is developed according to the waterfall model  requirements analysis, code and unit test, integration, and system testing. Its intent is to deal effectively with the uncertainties and risks associated with a large new development.

21. Spiral Model

22. Incremental Development Model 1. Begins with requirements analysis and preliminary design 2. As soon as modules are defined, one is selected that has all of its dependencies met 3. This module’s development proceeds as with the Spiral Model, until unit test is complete 4. A summary level test (regression) is put in a test stub and used to verify the module’s operation 5. The module is then integrated into the baseline of code 6. Steps 2 through 4 are repeated until the project is complete 7. Qualification Test demonstrates that the software meets requirements

23. Incremental Development Model Requirements Analysis Preliminary Design Design Code & UT Integration Test Qualification Test Integration Test correct code partially tested code partially tested code --- phases modules

24. Design by Contract  A design process based on built in test  Uses assertions to guarantee correctness Pre-conditions  Conditions which must be satisfied by the caller Post-conditions  Conditions which the service supplier guarantees to hold after delivery of the service Invariants  Conditions which must hold at the end of every service invocation

25. Evolutionary Project Management Plan for frequent deliveries of a production quality system that run with growing functionality Goals  Budget cost and schedule for the complete project  Divide the project into a series of small delivery cycles  Focus on short-term, clear goals with a high expectation of meeting them  Deliver fully tested, production quality software with the right documentation at the end of each cycle

26. Evolutionary Project Management Goals  Solicit feedback from the customer and management at the end of each cycle  At the beginning of each cycle Reassess objectives Estimate effort  Make quality objectives part of the requirements  Conclude the project when the budgeted cost or schedule has been consumed Customer has the option to contract further work on the system

27. Evolutionary Project Management Inspection Process  All deliverable items are inspected using a walkthrough process lead by the originator. Inspectors Present: Project Manager Inspection committee of developers  All defects are recorded  The originator removes all defects and resubmits the item for inspection  This is repeated until the item meets or exceeds its planned level of quality

28. Extreme Programming A development process designed to develop high quality software using an incremental development process

29. Extreme Programming User stories are created by the customer that shed light on features needed Each user story is implemented, starting with the most important one  Analysis  Design  Code  Test  Production

30. Extreme Programming Test Driven Development is used for all implementation with Programmer Pairs Refactoring is used with TDD Short standup meetings are used to coordinate the team After each user story is implemented it should be of quality to deliver to the customer

31. References  The Capability Maturity Model, Software Engineering Institute, Addison Wesley, 1994  Process Improvement for Small Organizations, Kelly & Culleton, IEEE Computer, October 1999  Evolutionary Project Management, Woodward, IEEE Computer, October 1999  http://www.extremeprogramming.org/light2.html http://www.extremeprogramming.org/light2.html  Software Development on Internet Time, Cusumano & Yoffie, IEEE Computer, October 1999