1. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 3 Prescriptive Process Models Software Engineering: A Practitioner’s Approach, 6/e Chapter 3 Prescriptive Process Models copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.

2. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2 Prescriptive Models Prescriptive process models advocate an orderly approach to software engineering Prescriptive process models advocate an orderly approach to software engineering 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?

3. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3 Waterfall Model A.k.a.: Classic Life Cycle A.k.a.: Classic Life Cycle Useful for problems that are well understood Useful for problems that are well understood Real problems are more complex than that; changes = confusion Real problems are more complex than that; changes = confusion Customer must state all requirements upfront Customer must state all requirements upfront Customer must have patience Customer must have patience Lack of feedback to the customer makes blunders disastrous Lack of feedback to the customer makes blunders disastrous

4. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4 Incremental Model

5. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5 Incremental Model Applies elements of the waterfall model in incremental fashion Applies elements of the waterfall model in incremental fashion First increment is often a core product First increment is often a core product Subsequent elements offer expanded functionality Subsequent elements offer expanded functionality Subsequent features (some known, some unknown) are created, while the core product may undergo evaluation Subsequent features (some known, some unknown) are created, while the core product may undergo evaluation If a customer requires deadlines that are impossible to meet, a sequence of releases may solve the problem If a customer requires deadlines that are impossible to meet, a sequence of releases may solve the problem Permits for staffing of a team to fluctuate Permits for staffing of a team to fluctuate

6. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6 RAD Model

7. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7 RAD Model Emphasizes short development cycle Emphasizes short development cycle If requirements are well understood and project scope is constrained, it may allow rapid creation of S/W systems If requirements are well understood and project scope is constrained, it may allow rapid creation of S/W systems For large projects may require vast human resources (for many RAD teams) For large projects may require vast human resources (for many RAD teams) Developers and customers must be able to cope with fast action Developers and customers must be able to cope with fast action For systems that are not highly modularized the RAD approach may not work For systems that are not highly modularized the RAD approach may not work If systems require mutual tuning of various components, the RAD approach may not work If systems require mutual tuning of various components, the RAD approach may not work RAD may not be appropriate with technical risks high (new technology) RAD may not be appropriate with technical risks high (new technology)

8. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8 Evolutionary Models: Prototyping communication Quick plan Modeling Quick design Construction of prototype Deployment delivery & feedback

9. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9 Evolutionary Models: Prototyping Useful when the customer has a legitimate need but is clueless about the details Useful when the customer has a legitimate need but is clueless about the details First prototype may be barely useful: too slow, too big, too unfriendly, etc. First prototype may be barely useful: too slow, too big, too unfriendly, etc.DANGERS: The customer may “LOVE” the prototype which is held together with “chewing gum”. When informed that it is a prototype which has to be re-built, he may want “few fixes” only The customer may “LOVE” the prototype which is held together with “chewing gum”. When informed that it is a prototype which has to be re-built, he may want “few fixes” only The developer may be tempted to deliver the raw prototype as a final product, sacrificing quality for a quick buck The developer may be tempted to deliver the raw prototype as a final product, sacrificing quality for a quick buck

10. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 10 Evolutionary Models: The Spiral

11. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11 Evolutionary Models: The Spiral Combines iterative prototyping with systematic aspects of the waterfall model Combines iterative prototyping with systematic aspects of the waterfall model Can be used throughout the S/W life cycle: from conceptualization to maintenance Can be used throughout the S/W life cycle: from conceptualization to maintenance Anchor point milestones are used for each evolutionary pass Anchor point milestones are used for each evolutionary pass Anchor point milestones: Anchor point milestones: Work products Work products Required conditions to be attained Required conditions to be attained Realistic to the development of large-scale systems Realistic to the development of large-scale systems Iteratively reduces risk Iteratively reduces risk Allows repeated use of the prototyping approach Allows repeated use of the prototyping approach PROBLEM: Customers may not like it, fearing lack of control PROBLEM: Customers may not like it, fearing lack of control

12. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 12 Evolutionary Models: Concurrent

13. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 13 Evolutionary Models: Concurrent The former image depicted only the modeling activity The former image depicted only the modeling activity Indeed, concurrent engineering is a set of framework activities such as Communication, Modeling, etc. Indeed, concurrent engineering is a set of framework activities such as Communication, Modeling, etc. Each of these activities is in one of its states… Each of these activities is in one of its states… A state is some externally observable mode of behaviour A state is some externally observable mode of behaviour PROBLEMS: Prototyping (and other evolutionary processes) pose problems to project planning (too much uncertainty) Prototyping (and other evolutionary processes) pose problems to project planning (too much uncertainty) Evolutionary speed may not be optimal: too slow affects productivity, too fast leads to chaos Evolutionary speed may not be optimal: too slow affects productivity, too fast leads to chaos Sometimes software processes should focus on flexibility and extensibility, rather than on quality - delivery delays may make us miss the market niche and window of opportunity Sometimes software processes should focus on flexibility and extensibility, rather than on quality - delivery delays may make us miss the market niche and window of opportunity

14. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 14 Still Other Process Models Component based development—the process to apply when reuse is a development objective Component based development—the process to apply when reuse is a development objective Formal methods—emphasizes the mathematical specification of requirements Formal methods—emphasizes the mathematical specification of requirements AOSD—provides a process and methodological approach for defining, specifying, designing, and constructing aspects like security, fault tolerance, adherence to business rules, systemic: DB mirroring, memory management, concurrency AOSD—provides a process and methodological approach for defining, specifying, designing, and constructing aspects like security, fault tolerance, adherence to business rules, systemic: DB mirroring, memory management, concurrency Unified Process—a “use-case driven, architecture- centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML) Unified Process—a “use-case driven, architecture- centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML)

15. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 15 inception The Unified Process (UP) inception elaboration

16. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 16 UP Phases

17. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 17 UP Work Products