1. Ch7: Software Production Process

2. 1 Questions  What is the life cycle of a software product?  Why do we need software process models?  What are the goals of a software process and what makes it different from other industrial processes?

3. 2 Software production process  What is a software process?  Goal:  Hard to automate the production process:  Production models attempt to capture the software life cycle.

4. 3 Software production process (contd..)  Engineering disciplines have well-define processes  For example, to build a house:  Can software have a similar, methodological approach?

5. 4 Life cycle of a software product  What is a software life cycle?  Activities in the software life cycle

6. 5 Software process model  Attempt to organize the software life cycle by  Goals of a software process

7. 6 Code and fix model  Earlier programmers used the code-and-fix approach:  Source of difficulties and deficiencies:

8. 7 Need for models  Need for sophisticated models:  Symptoms of inadequacy of the code & fix model: the software crisis

9. 8 Need for models (contd..)  Software development process needed to:  Boehm states that the goals of a process model are:

10. 9 Process as a black-box Product Process Informal Requirements

11. 10 Process as a white-box

12. 11 Main activities in software production  Relationship between the main activities:

13. 12 Feasibility study  What is a feasibility study?  People:  Produces a Feasibility Study Document

14. 13 Feasibility study (contd..)  For a commercial product:  For a product to be used in-house  Customized software

15. 14 Requirements engineering  Purpose:  People:  Focus on

16. 15 Requirements engineering (contd..)  Understand:  Identify:  Requirements analysis and elicitation activities produces a:

17. 16 Requirements specification document  Provides:  Has its own qualities  Role of stakeholders  Relationship with testing:

18. 17 Requirements specification document (contd..)  As any large document, it must be modular  Vertical modularity:  Horizontal modularity:

19. 18 Requirements specification document (contd..)  Functional requirements:  Non-functional requirements:

20. 19 Software architecture and detailed design  Purpose:  People:  Produces a:  Decomposition usually has two phases:

21. 20 Software architecture and detailed design (contd..)  Design alternatives are suggested and evaluated:

22. 21 Code and module testing  Purpose:  People:  Coding and algorithm alternatives are implemented and evaluated:

23. 22 Code and module testing  Coding may be subject to company-wide standards:  Module testing may also follow company standards:  Other activities:

24. 23 Integration and system testing  Purpose:  People:  Integration may be done incrementally through subsystems  The last step is system test  Alpha testing:

25. 24 Integration and system testing (contd..)  Company standards may apply to:

26. 25 Delivery and maintenance  Purpose:  People:  Delivery is done in two stages:

27. 26 Delivery and maintenance (contd..)  Maintenance might be better named evolution  Lientz and Swanson’s study:  Changes to user requirements (42%)  Changes in the data format (17%)  Emergency fixes (12%)  Routine debugging (9%)  Hardware changes (6%)  Improvements in documentation (5%)  Improvements in efficiency (4%)  Other (5%)

28. 27 Delivery and maintenance (contd..)  Role of requirements analysis on maintenance:  Many errors are not removed until the system is delivered.  Change is an intrinsic property of software, but hard to incorporate into a product.

29. 28 Other software activities  Some activities span all phases of life cycle  Documentation  Verification:

30. 29 Other software activities (contd..)  Management:  Three main aspects: