1. SE382 Software Engineering Lecture 04 Process Models (1)

2. 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.

3. 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.

4. 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.

5. 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

6. 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.

7. 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?

8. 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.

9. 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

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

11. 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.

12. 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

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

14. 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.

15. 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

16. 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

17. 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.

18. 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

19. SE382 Software Engineering Lecture 05 Process Models (2)

20. 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 page answers.

21. 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.

22. 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.

23. 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.

24. 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.

25. 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

26. 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.

27. 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

28. 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.

29. 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

30. 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.

31. 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.