1. Chapter 7: Software production process Refers to the activities that are used for building, delivering, deploying, and evolving a software product, from inception of an idea all the way to the delivery and final retirement of the system

2. Life cycle (Overview of different Activities) The life cycle of a software product: The life cycle of a software product: from inception of an idea for a product towards: from inception of an idea for a product towards: requirements gathering and analysis requirements gathering and analysis architecture design and specification architecture design and specification coding and testing coding and testing delivery and deployment delivery and deployment maintenance and evolution maintenance and evolution retirement retirement

3. Software process model Attempt to organize the software life cycle by Attempt to organize the software life cycle by defining activities involved in software production defining activities involved in software production order of activities and their relationships order of activities and their relationships Goals of a software process Goals of a software process standardization, predictability, productivity, high product quality, ability to plan time and budget requirements standardization, predictability, productivity, high product quality, ability to plan time and budget requirements

4. Code & Fix The earliest approach Write code Write code Fix it to eliminate any errors that have been detected, to enhance existing functionality, or to add new features Fix it to eliminate any errors that have been detected, to enhance existing functionality, or to add new features Source of difficulties and deficiencies Source of difficulties and deficiencies impossible to predict impossible to predict impossible to manage impossible to manage CMM initial phase CMM initial phase

5. Models are needed Symptoms of inadequacy: the software crisis Symptoms of inadequacy: the software crisis scheduled time and cost exceeded scheduled time and cost exceeded user expectations not met user expectations not met poor quality poor quality The size and economic value of software applications required appropriate "process models" The size and economic value of software applications required appropriate "process models"

6. Process model goals (B. Boehm 1988) “Determine the order of stages involved in software development and evolution, and to establish the transition criteria for progressing from one stage to the next. These include completion criteria for the current stage plus choice criteria and entrance criteria for the next stage. Thus a process model addresses the following software project questions: What shall we do next? How long shall we continue to do it?"

7. Process as a "black box" Quality? Uncertain / Incomplete requirement In the beginning

8. Problems The assumption is that requirements can be fully understood prior to development The assumption is that requirements can be fully understood prior to development Interaction with the customer occurs only at the beginning (requirements) and end (after delivery) Interaction with the customer occurs only at the beginning (requirements) and end (after delivery) Unfortunately the assumption almost never holds Unfortunately the assumption almost never holds

9. Process as a "white box"

10. Waterfall Software Process model (1) Invented in the late 1950s for large air defense systems, popularized in the 1970s Invented in the late 1950s for large air defense systems, popularized in the 1970s They organize activities in a sequential flow They organize activities in a sequential flow Exist in many variants, all sharing sequential flow style Exist in many variants, all sharing sequential flow style

11. A waterfall model

12. Waterfall models (2) Organizations adopting them standardize the outputs of the various phases (deliverables) Organizations adopting them standardize the outputs of the various phases (deliverables) May also prescribe methods to follow in each phase May also prescribe methods to follow in each phase organization of methods in frameworks often called methodology organization of methods in frameworks often called methodology Example: Military Standard (MIL-STD- 2167) Example: Military Standard (MIL-STD- 2167)

13. Critical evaluation of the waterfall model  Software process subject to discipline, planning, and management.  Postpone implementation to after understanding objectives.  Linear, rigid, monolithic:  No feedback  No parallelism  A single delivery date

14. Waterfall with feedback

15. Problems with waterfall Estimates made when limited knowledge available Estimates made when limited knowledge available Difficult to gather all requirements once and for all Difficult to gather all requirements once and for all users may not know what they want users may not know what they want requirements cannot be frozen requirements cannot be frozen

16. Evolutionary models Many variants available Many variants available Product development evolves through increments Product development evolves through increments "do it twice" (F. Brooks, 1995) "do it twice" (F. Brooks, 1995) evolutionary prototype evolutionary prototype Evolutionary process model (B. Boehm, 1988) Evolutionary process model (B. Boehm, 1988) "model whose stages consist of expanding increments of an operational software product, with the direction of evolution being determined by operational experience"

17. Ch. 717 Spiral model B. Boehm, 1989 Spiral Model

18. Ch. 7 18 Unified Software Development Process (UP)

19. Ch. 719 Principles Industry standard process model, initiated by Ericsson, then Objectory and Rational companies Industry standard process model, initiated by Ericsson, then Objectory and Rational companies Development of an OO system Development of an OO system Uses the UML notation throughout the process: Uses the UML notation throughout the process: Different views that are informal and not necessarily consistent. Different views that are informal and not necessarily consistent. Supports an iterative and incremental process Supports an iterative and incremental process Decomposes a large process into controlled iterations (mini projects) Decomposes a large process into controlled iterations (mini projects)

20. Ch. 720 UML Models

21. Ch. 721 Unified Process (UP) Underlying model: Underlying model: Any large software project should be broken into controlled iterations (mini-projects) that provide increments of the product Any large software project should be broken into controlled iterations (mini-projects) that provide increments of the product A UP life cycle can be depicted abstractly as a sequence of cycles from the project’s inception to its termination. A UP life cycle can be depicted abstractly as a sequence of cycles from the project’s inception to its termination. Each cycle outputs a product release - (I.e., ready for delivery). Each cycle outputs a product release - (I.e., ready for delivery). The output is complete and consistent set of artifacts, including the executable code and all the needed documents (requ, design, tests,..), specified in UML. The output is complete and consistent set of artifacts, including the executable code and all the needed documents (requ, design, tests,..), specified in UML. Each cycle in turn is divided into a sequence of four phases, where each phase terminates with in a milestone that is used for project control. Each cycle in turn is divided into a sequence of four phases, where each phase terminates with in a milestone that is used for project control.

22. Ch. 722 Phases of a UP cycle important Phases of a UP cycle important Inception: roughly corresponds to feasibility study; that is documenting a vision of the product and a business analysis to justify why this product should be developed. Inception: roughly corresponds to feasibility study; that is documenting a vision of the product and a business analysis to justify why this product should be developed. Elaboration: defining use cases and software architecture for the current release, where the architecture will become a baseline that must be agreed on and stakeholders must adhere to it. Elaboration: defining use cases and software architecture for the current release, where the architecture will become a baseline that must be agreed on and stakeholders must adhere to it. Construction: building the product through enriching the architecture’s baseline and developing and testing the code. Milestone for this phase is quality control via validation checking. Construction: building the product through enriching the architecture’s baseline and developing and testing the code. Milestone for this phase is quality control via validation checking. Transition: corresponds to beta testing. A trusted set of early adopters tries the product and provides reports on possible defects. Either fixed or deferred to next release. Transition: corresponds to beta testing. A trusted set of early adopters tries the product and provides reports on possible defects. Either fixed or deferred to next release. Milestone: consists of delivering an intermediate set of artifacts that can be subject to quality control via reviews and inspections.

23. Ch. 723 Unified Process Cycles and phases of a cycle milestone product release Inception Elaboration Construction Transition Intermediate set of artifacts for quality control

24. Ch. 724 Distribution of workflows over phases -Feasibility - Use cases - Architecture - Base line -Develop -Test -Quality check -Beta test