SE382 Software Engineering Lecture 04 Process Models (1)

Chapter 4 Process Models Slide Set to accompany Software Engineering: A Practitioner’s Approach, 8/e by Roger S. Pressman and Bruce R. Maxim Slides copyright © 1996, 2001, 2005, 2009, 2014 by Roger S. Pressman For non-profit educational use only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach, 8/e. Any other reproduction or use is prohibited without the express written permission of the author. All copyright information MUST appear if these slides are posted on a website for student use. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

Prescriptive Models 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? 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? These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

The Waterfall Model These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

The Waterfall Model Strengths Easy to understand and execute Weaknesses Requirements: can’t change once finalized; become outdated by the time the system is delivered Product becomes available only towards the end of the project Some team members are always doing nothing Where to Use? Where requirements are well understood (e.g. when rebuilding an existing system using new tools) Large scale, complex projects

The V-Model The V-model is similar to waterfall, but highlights test planning and execution. For example, the acceptance testing plan and test cases are created during the requirements and architectural design activities. Acceptance testing is executed as the final activity in the project. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

The V-Model Strengths Similar to the classic waterfall, but highlights the quality assurance activities of each waterfall phase. The quality documentation is generated in advance and quality is assured at each stage. Weaknesses Same as waterfall Where to Use?

The Incremental Model These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

The Incremental Model Strengths Customer gets exactly what meets her needs as requirement changes can be incorporated throughout most of the duration of the project Customer is able to use core functionality quite quickly and provide feedback to developers The whole team is busy most of the time Weaknesses Complex and difficult to manage process Constant rework due to changing requirements/ design leads to lower quality Where to Use? Where requirements are not well understood Where core functionality is required quickly

Evolutionary Process Models Iterative Increasingly more complete versions of the software are developed

Evolutionary Models: Prototyping Construction of prototype These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

Evolutionary Models: Prototyping Strengths Helps the developer in identifying and clarify requirements Weaknesses At times, the customer may force the developer to deliver the prototype as the finished product At times, the developer makes less-than-ideal design choices due to time constraints. Later those choice become part of the actual system as she forgets about the drawbacks of those choices. Where to Use? Where requirements are not well understood

Incremental Model vs. Prototyping Both are iterative, but … Requirements are well known in the incremental case Prototyping produces a model, not a deliverable product

Evolutionary Models: Spiral These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

Evolutionary Models: Spiral Strengths Explicitly considers the risk at every stage of he project, and if applied correctly, reduces those risks before they negatively impact the project Weaknesses The evolutionary nature of the model makes it difficult to predict the end-date of the project Requires considerably mastery of risk-assessment Where to Use? Where the risk of developing the whole system at once is high

Evolutionary Models: Concurrent The software development process is not limited to precisely defined sequence of activities Instead, the concurrent model defines a network of activities that are all present simultaneously These activities keep on transitioning from state to state Events generated at one point in the process network trigger transitions among states

Evolutionary Models: Concurrent These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

Evolutionary Models: Concurrent Strengths Shortens project duration through concurrency Enables discovery of errors in the early stages when the design is more flexible and easy to modify Weaknesses Complex and difficult to manage process that requires efficient communication among teams and team members Requires considerable training to enable efficient execution Where to Use? Where a product is being developed by a collection of teams

SE382 Software Engineering Lecture 05 Process Models (2)

First Midterm Exam Tuesday, 3 March 2015 (same time as the lecture) Duration: 75 minutes Will cover all lectures delivered before the exam date Will consist of MCQ’s, fill-in-the-blanks, questions with short answers, and drawing of diagrams If you miss any midterm exams for any reason, you will have to appear for a makeup exam on the Thursday of the last week of teaching. This exam will cover all lectures delivered in the semester. It will consist of drawing of diagrams and answering questions having 0.5-1 page answers.

Still Other Process Models Component-based development—the process to apply when reuse is a development objective Formal methods—emphasizes the mathematical specification of requirements Aspect-Oriented Software Development (AOSD)— provides a process and methodological approach for defining, specifying, designing, and constructing aspects (e.g. security, privacy, availability) Unified Process—a “use-case driven, architecture- centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML) These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

The Unified Process (UP) These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

UP Phases These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

UP Work Products These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

The Unified Process Strengths Has all the benefits of iterative & incremental models Focuses on defining and validating an executable architecture early, resulting in stable development Addresses risks at an early stage Closely aligned with UML Weaknesses Complex and difficult to manage process Unsuitable for small projects Where to Use? High-risk and/or mission-critical projects

Multi-site Development Process Attributes Waterfall V Incremental Prototyping Spiral Concurrent Unified Process Iterations 1 Many Fast Feedback No Yes Speed to Change Low Medium High Ease of Management Predictability Multi-site Development Easy Difficult Team Utilization This table was inspired by Table 2 in R. Chillarege, The Marriage Of Business Dynamics And Software Engineering. IEEE Software, Nov/Dec 2002.

Team and Personal Processes Team Software Process (TSP) is a well defined process that small teams (3-20 members) can adopt to improve their productivity Personal Software Process (PSP) equips an individual will the knowledge and skills required to become an effective member of a TSP team

Team Software Process (TSP) Builds self-directed teams that plan and track their work, establish goals, and own their processes and plans. These can be software teams or integrated product teams Shows managers how to coach and motivate their teams and how to help them sustain peak performance. Accelerates software process improvement by making CMM Level 5 behavior normal and expected. The Capability Maturity Model (CMM), a measure of the effectiveness of a software process Provides improvement guidance to high-maturity organizations Facilitates teaching of industrial-grade team skills These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

Personal Software Process (PSP) PSP represents a disciplined, metrics-based approach to an individual’s software development process If properly utilized, PSP may result in a 10x increase in the productivity of an individual developer PSP stresses the need for each software engineer to identify errors early, and just as important, to understand the types of errors she is likely to make 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

PSP: Activities Planning activity isolates requirements and develops both size and resource estimates. In addition, a defect estimate (the number of defects projected for the work) is made. All metrics are recorded on worksheets or templates. Finally, development tasks are identified and a project schedule is created. High-level design. An external specification is created for each component and a component design is created. Prototypes are built when uncertainty exists. All issues are recorded and tracked. High-level design review. Formal verification methods are applied to uncover errors in the design. Metrics are maintained for all important tasks and work results. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.

PSP: Activities (contd.) Development. The component level design is refined and reviewed. Code is generated, reviewed, compiled, and tested. Metrics are maintained for all important tasks and work results. Postmortem. Using measures and metrics collected the effectiveness of the process is determined. (If this is a large amount of data it should be analyzed statistically). Measures and metrics should provide guidance for modifying the process to improve its effectiveness. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.