1. SWE311_Ch03 (071) Software & Software Engineering Slide 1 Chapter 3 Prescriptive Process Models

2. SWE311_Ch03 (071) Software & Software Engineering Slide 2 Overview Prescriptive process models prescribe a distinct set of activities, actions, tasks, milestones, and work products required to engineer high quality software. Prescriptive software process models are adapted to meet the needs of software engineers and managers for a specific project. Prescriptive software models provide stability, control, and organization to a process that if not managed can easily get out of control. Framework activities for a particular process model may be organized into a process flow that may be linear, incremental, or evolutionary.

3. SWE311_Ch03 (071) Software & Software Engineering Slide 3 Overview (cont) The software engineer's work products (programs, documentation, data) are produced as a consequence of the activities defined by the software process. The best indicators of how well a software process has worked are the quality, timeliness, and long-term viability of the resulting software product.

4. SWE311_Ch03 (071) Software & Software Engineering Slide 4 Objectives Introduce process models and the roles they play in a software engineering environment Introduce process models and the roles they play in a software engineering environment Give examples of some of the most common process models Give examples of some of the most common process models Provide means of comparing process model Provide means of comparing process model

5. SWE311_Ch03 (071) Software & Software Engineering Slide 5 Software Process Aimed to control the activities of software development and as such improve quality... Aimed to control the activities of software development and as such improve quality... A structured set of activities for A structured set of activities for Specifying, Specifying, Designing, Designing, Implementing and Implementing and Testing software systems Testing software systems A software process model is an abstract representation of a process A software process model is an abstract representation of a process a description of a process from a particular perspective a description of a process from a particular perspective

6. SWE311_Ch03 (071) Software & Software Engineering Slide 6 Software Process Models Software process models are general approaches for organizing a project into activities Software process models are general approaches for organizing a project into activities Help the project manager and his team to decide: Help the project manager and his team to decide: What work should be done What work should be done In what sequence to perform the work In what sequence to perform the work The models should be seen as aids to thinking, not rigid prescriptions of the way to do things The models should be seen as aids to thinking, not rigid prescriptions of the way to do things Each project ends up with its own unique plan because Each project ends up with its own unique plan because Projects differs in the nature of the project, people doing the work, and the work environment Projects differs in the nature of the project, people doing the work, and the work environment

7. SWE311_Ch03 (071) Software & Software Engineering Slide 7 Prescriptive Models Prescriptive process models advocate an orderly approach to software engineering Prescriptive process models advocate an orderly approach to software engineering Organize framework activities in a certain order Organize framework activities in a certain order Originally proposed to bring order to the chaos of software development Originally proposed to bring order to the chaos of software development They brought order to software engineering work and provide reasonable guidance to software teams They brought order to software engineering work and provide reasonable guidance to software teams Adopt following activities Adopt following activities Communication Communication Planning Planning Modeling Modeling Construction Construction Deployment Deployment Differ in Differ in Emphasis of these activities Emphasis of these activities Manners in which the framework is invoked and its relationship with other activities Manners in which the framework is invoked and its relationship with other activities

8. SWE311_Ch03 (071) Software & Software Engineering Slide 8 Prescriptive Models That leads to a few questions … If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change? If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change? Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work? Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?

9. SWE311_Ch03 (071) Software & Software Engineering Slide 9 Software Processes Every software engineering organization needs to describe a set of framework activities for the processes it adopts Every software engineering organization needs to describe a set of framework activities for the processes it adopts Each framework activity needs to be populated with software engineering actions Each framework activity needs to be populated with software engineering actions Each engineering action needs to be defined in terms of a task set that defines the work and work products needed to meet the development goals Each engineering action needs to be defined in terms of a task set that defines the work and work products needed to meet the development goals The resulting process model should be adapted to accommodate the nature of the specific project, people doing the work, and the work environment The resulting process model should be adapted to accommodate the nature of the specific project, people doing the work, and the work environment

10. SWE311_Ch03 (071) Software & Software Engineering Slide 10 Software Processes (cont) Regardless of the process model selected, software engineers will chose a generic process framework that includes these activities: communication, planning, modeling, construction, and deployment Regardless of the process model selected, software engineers will chose a generic process framework that includes these activities: communication, planning, modeling, construction, and deployment Each process model will prescribe a set of process elements (framework activities, software engineering actions, tasks, work products, quality assurance, and change control mechanisms) and a workflow (the manner in which the process elements are interrelated) Each process model will prescribe a set of process elements (framework activities, software engineering actions, tasks, work products, quality assurance, and change control mechanisms) and a workflow (the manner in which the process elements are interrelated) All software process models discussed in this chapter can accommodate the generic framework activities described previously All software process models discussed in this chapter can accommodate the generic framework activities described previously

11. SWE311_Ch03 (071) Software & Software Engineering Slide 11 The Waterfall Model Old fashioned but reasonable approach when requirements are well understood

12. SWE311_Ch03 (071) Software & Software Engineering Slide 12 Limitations of the waterfall model The model implies that you should attempt to complete a given stage before moving on to the next stage The model implies that you should attempt to complete a given stage before moving on to the next stage Does not account for the fact that requirements constantly change. Does not account for the fact that requirements constantly change. It also means that customers can not use anything until the entire system is complete. It also means that customers can not use anything until the entire system is complete. The model makes no allowances for prototyping. The model makes no allowances for prototyping. Assumes understanding of problem and full requirements early on Assumes understanding of problem and full requirements early on It implies that you can get the requirements right by simply writing them down and reviewing them. It implies that you can get the requirements right by simply writing them down and reviewing them. Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements.

13. SWE311_Ch03 (071) Software & Software Engineering Slide 13 Critique of Waterfall Model continued Followed systematic approach to development Followed systematic approach to development The model implies that once the product is finished, everything else is maintenance. The model implies that once the product is finished, everything else is maintenance. Assumes patience from customer Assumes patience from customer Surprises at the end are very expensive Surprises at the end are very expensive Some teams sit ideal for other teams to finish Some teams sit ideal for other teams to finish Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process. Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process.

14. SWE311_Ch03 (071) Software & Software Engineering Slide 14 The Incremental Model Delivers software in small but usable pieces, each piece builds on pieces already delivered

15. SWE311_Ch03 (071) Software & Software Engineering Slide 15 The Incremental Model Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality. Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality. First Increment is often core product First Increment is often core product Includes basic requirement Includes basic requirement Many supplementary features (known & unknown) remain undelivered Many supplementary features (known & unknown) remain undelivered First Increment is used or evaluated First Increment is used or evaluated A plan of next increment is prepared A plan of next increment is prepared Modifications of the first increment Modifications of the first increment Additional features of the first increment Additional features of the first increment It is particularly useful when enough staffing is not available for the whole project It is particularly useful when enough staffing is not available for the whole project Increment can be planned to manage technical risks Increment can be planned to manage technical risks

16. SWE311_Ch03 (071) Software & Software Engineering Slide 16 The Incremental Model User requirements are prioritised and the highest priority requirements are included in early increments. User requirements are prioritised and the highest priority requirements are included in early increments. Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve. Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve. Customer value can be delivered with each increment so system functionality is available earlier. Customer value can be delivered with each increment so system functionality is available earlier. Early increments act as a prototype to help elicit requirements for later increments. Early increments act as a prototype to help elicit requirements for later increments. Lower risk of overall project failure. Lower risk of overall project failure. The highest priority system services tend to receive the most testing. The highest priority system services tend to receive the most testing.

17. SWE311_Ch03 (071) Software & Software Engineering Slide 17 The RAD Model Makes heavy use of reusable software components with an extremely short development cycle

18. SWE311_Ch03 (071) Software & Software Engineering Slide 18 Critique of RAD If requirements are well understood and project scope is constrained If requirements are well understood and project scope is constrained Very short development time Very short development time Construction emphasizes the reuse and the automatic code generation Construction emphasizes the reuse and the automatic code generation For large but scalable projects For large but scalable projects RAD requires sufficient human resources RAD requires sufficient human resources Projects fail if developers and customers are not committed in a much abbreviated time-frame Projects fail if developers and customers are not committed in a much abbreviated time-frame Problematic if system can not be modularized Problematic if system can not be modularized Not appropriate when technical risks are high Not appropriate when technical risks are high

19. SWE311_Ch03 (071) Software & Software Engineering Slide 19 Evolutionary Models: Prototyping Quick plan Modeling Quick design Construction of prototype Good first step when customer has a legitimate need, but is clueless about the details, developer needs to resist pressure to extend a rough prototype into a production product

20. SWE311_Ch03 (071) Software & Software Engineering Slide 20 Evolutionary Models: The Spiral Couples iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model

21. SWE311_Ch03 (071) Software & Software Engineering Slide 21

22. SWE311_Ch03 (071) Software & Software Engineering Slide 22 Evolutionary Models: Concurrent Similar to spiral model often used in development of client/server applications

23. SWE311_Ch03 (071) Software & Software Engineering Slide 23 Specialized Process Models Component based development— spiral model variation in which applications are built from prepackaged software components called classes Component based development— spiral model variation in which applications are built from prepackaged software components called classes Formal methods—emphasizes the mathematical specification of requirements. Rigorous mathematical notation used to specify, design, and verify computer-based systems Formal methods—emphasizes the mathematical specification of requirements. Rigorous mathematical notation used to specify, design, and verify computer-based systems )— provides a process and methodological approach for defining, specifying, designing, and constructing aspects like user interfaces, security, and memory management that impact many parts of the system being developed Aspect-Oriented Software Development (AOSD)— provides a process and methodological approach for defining, specifying, designing, and constructing aspects like user interfaces, security, and memory management that impact many parts of the system being developed

24. SWE311_Ch03 (071) Software & Software Engineering Slide 24 Unified Process Use-case driven, architecture centric, iterative, and incremental software process closely aligned with the Unified Modeling Language (UML) Use-case driven, architecture centric, iterative, and incremental software process closely aligned with the Unified Modeling Language (UML) Attempts to draw on best features of traditional software process models and implements many features of agile software development Attempts to draw on best features of traditional software process models and implements many features of agile software development Phases Phases Inception phase (customer communication and planning) Inception phase (customer communication and planning) Elaboration phase (communication and modeling) Elaboration phase (communication and modeling) Construction phase Construction phase Transition phase (customer delivery and feedback) Transition phase (customer delivery and feedback) Production phase (software monitoring and support) Production phase (software monitoring and support)

25. SWE311_Ch03 (071) Software & Software Engineering Slide 25 inception The Unified Process (UP) inception elaboration

26. SWE311_Ch03 (071) Software & Software Engineering Slide 26 UP Phases

27. SWE311_Ch03 (071) Software & Software Engineering Slide 27 UP Work Products

28. SWE311_Ch03 (071) Software & Software Engineering Slide 28 Attributes for Comparing Process Models Overall flow and level of interdependencies among tasks Overall flow and level of interdependencies among tasks Degree to which work tasks are defined within each framework activity Degree to which work tasks are defined within each framework activity Degree to which work products are identified and required Degree to which work products are identified and required Manner in which quality assurance activities are applied Manner in which quality assurance activities are applied

29. SWE311_Ch03 (071) Software & Software Engineering Slide 29 Attributes for Comparing Process Models (cont) Manner in which project tracking and control activities are applied Manner in which project tracking and control activities are applied Overall degree of detail and rigor of process description Overall degree of detail and rigor of process description Degree to which stakeholders are involved in the project Degree to which stakeholders are involved in the project Level of autonomy given to project team Level of autonomy given to project team Degree to which team organization and roles are prescribed Degree to which team organization and roles are prescribed