Ch7: Software Production Process

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?

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.

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

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

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

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

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

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

9 Process as a black-box Product Process Informal Requirements

10 Process as a white-box

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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%)

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.

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

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