Process Models
Anas Ali
Department of Computer Science
NUML Lahore
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
• 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
2
Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
The Unified Process (UP)
elaboration
inception
These slides are designed to accompany Software Engineering: A Practitioner’s
3
Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
UP Phases
These slides are designed to accompany Software Engineering: A Practitioner’s
4
Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
UP Work Products
These slides are designed to accompany Software Engineering: A Practitioner’s
5
Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Personal Software Process (PSP)
• Planning. This 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. External specifications for each component to be constructed are developed 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 (Chapter 21) are applied to uncover errors in the
design. Metrics are maintained for all important tasks and work results.
• 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 the measures and metrics collected (this is a substantial amount of data that should be
analyzed statistically), the effectiveness of the process is determined. 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
6
Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Team Software Process (TSP)
• Build self-directed teams that plan and track their work, establish goals, and own their processes
and plans. These can be pure software teams or integrated product teams (IPT) of three to about 20
engineers.
• Show managers how to coach and motivate their teams and how to help them sustain peak
performance.
• Accelerate 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, is
discussed in Chapter 30.
• Provide improvement guidance to high-maturity organizations.
• Facilitate university teaching of industrial-grade team skills.
These slides are designed to accompany Software Engineering: A Practitioner’s
7
Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.