Download - Slides chapter 3
![Page 1: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/1.jpg)
1
Chapter 3Prescriptive Process
Models
Chapter 3Prescriptive Process
Models
Software Engineering: A Practitioner’s Approach, 6th editionby Roger S. Pressman
![Page 2: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/2.jpg)
Software process modelSoftware process model Attempt to organize the software life cycle by
defining activities involved in software production order of activities and their relationships
Goals of a software process standardization, predictability, productivity, high
product quality, ability to plan time and budget requirements
Attempt to organize the software life cycle by defining activities involved in software production order of activities and their relationships
Goals of a software process standardization, predictability, productivity, high
product quality, ability to plan time and budget requirements
![Page 3: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/3.jpg)
Code&FixCode&Fix
The earliest approach Write code Fix it to eliminate any errors that have been
detected, to enhance existing functionality, or to add new features
Source of difficulties and deficiencies impossible to predict impossible to manage
The earliest approach Write code Fix it to eliminate any errors that have been
detected, to enhance existing functionality, or to add new features
Source of difficulties and deficiencies impossible to predict impossible to manage
![Page 4: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/4.jpg)
Models are neededModels are needed
Symptoms of inadequacy: the software crisis scheduled time and cost exceeded user expectations not met poor quality
The size and economic value of software applications required appropriate "process models"
Symptoms of inadequacy: the software crisis scheduled time and cost exceeded user expectations not met poor quality
The size and economic value of software applications required appropriate "process models"
![Page 5: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/5.jpg)
Process model goals (B. Boehm 1988)Process model goals (B. Boehm 1988)
"determine the order of stages involved in software development and evolution, and to establish the transition criteria for progressing from one stage to the next. These include completion criteria for the current stage plus choice criteria and entrance criteria for the next stage. Thus a process model addresses the following software project questions:
What shall we do next?How long shall we continue to do it?"
![Page 6: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/6.jpg)
Process as a "black box"Process as a "black box"
Product
Process
Informal Requirements
Quality?Uncertain /Incomplete requirementIn the beginning
![Page 7: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/7.jpg)
ProblemsProblems
The assumption is that requirements can be fully understood prior to development
Interaction with the customer occurs only at the beginning (requirements) and end (after delivery)
Unfortunately the assumption almost never holds
The assumption is that requirements can be fully understood prior to development
Interaction with the customer occurs only at the beginning (requirements) and end (after delivery)
Unfortunately the assumption almost never holds
![Page 8: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/8.jpg)
Process as a "white box"Process as a "white box"
Product
Process
Informal Requirements
feedback
![Page 9: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/9.jpg)
AdvantagesAdvantages
Reduce risks by improving visibility Allow project changes as the project
progresses based on feedback from the customer
Reduce risks by improving visibility Allow project changes as the project
progresses based on feedback from the customer
![Page 10: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/10.jpg)
The main activities of software productionThe main activities of software production They must be performed independently
of the model The model simply affects the flow
among activities
They must be performed independently of the model
The model simply affects the flow among activities
![Page 11: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/11.jpg)
11
Prescriptive ModelsPrescriptive 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? 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?
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?
Prescriptive process models advocate an Prescriptive process models advocate an orderly approach to software engineeringorderly approach to software engineering
![Page 12: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/12.jpg)
12
The Waterfall Model
![Page 13: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/13.jpg)
13
Waterfall Model AssumptionsWaterfall Model Assumptions1. The requirements are knowable in advance of implementation.
2. The requirements have no unresolved, high-risk implications
e.g., risks due to COTS choices, cost, schedule, performance, safety, security, user interfaces, organizational impacts
3. The nature of the requirements will not change very much During development; during evolution
4. The requirements are compatible with all the key system stakeholders’ expectations e.g., users, customer, developers, maintainers, investors
5. The right architecture for implementing the requirements is well understood.
6. There is enough calendar time to proceed sequentially.
![Page 14: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/14.jpg)
14
Process for Offshore?Process for Offshore?
Deploy
Analysis
Design
Accept. test
Construct
System test
![Page 15: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/15.jpg)
15
The V ModelThe V ModelIf we rely on testing alone, defects created first are detected last
SystemRequirements
SoftwareRequirements
SoftwareDesign
SoftwareImplementation
UnitTesting
IntegrationTesting
SoftwareTesting
SystemTesting
system test plan
software test plan
integration plan
unit plan
ProductRelease
time
UserNeed
![Page 16: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/16.jpg)
16
Incremental Models: Incremental
![Page 17: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/17.jpg)
17
Incremental Models: RAD ModelIncremental Models: RAD Model
![Page 18: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/18.jpg)
18
Evolutionary Models: Prototyping
![Page 19: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/19.jpg)
19
Risk Exposure
![Page 20: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/20.jpg)
20
Unified Process ModelA software process that is:A software process that is:
use-case drivenuse-case driven architecture-centricarchitecture-centric iterative and incrementaliterative and incremental
Closely aligned with theClosely aligned with the
Unified Modeling Language Unified Modeling Language (UML)(UML)
![Page 21: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/21.jpg)
21
inceptioninception
The Unified Process (UP)The Unified Process (UP)
![Page 22: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/22.jpg)
22
UP Work ProductsUP Work Products
inceptioninception
![Page 23: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/23.jpg)
23
Lifecycle for Enterprise Unified ProcessLifecycle for Enterprise Unified Process
inceptioninception
![Page 24: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/24.jpg)
24
Synchronize-and Stabilize ModelSynchronize-and Stabilize Model Microsoft’s life-cycle model Requirements analysis—interview potential
customers Draw up specifications Divide project into 3 or 4 builds Each build is carried out by small teams
working in parallel
Microsoft’s life-cycle model Requirements analysis—interview potential
customers Draw up specifications Divide project into 3 or 4 builds Each build is carried out by small teams
working in parallel
![Page 25: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/25.jpg)
25
Synchronize-and Stabilize Model (contd)Synchronize-and Stabilize Model (contd) At the end of the day—synchronize (test and
debug) At the end of the build—stabilize (freeze build) Components always work together
Get early insights into operation of product
At the end of the day—synchronize (test and debug)
At the end of the build—stabilize (freeze build) Components always work together
Get early insights into operation of product
![Page 26: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/26.jpg)
26
Evolutionary Models: The Spiral
![Page 27: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/27.jpg)
27
Spiral ModelSpiral Model Simplified form
Waterfall model plus risk analysis
Precede each phase by Alternatives Risk analysis
Follow each phase by Evaluation Planning of next
phase
Simplified form Waterfall model
plus risk analysis Precede each
phase by Alternatives Risk analysis
Follow each phase by Evaluation Planning of next
phase
![Page 28: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/28.jpg)
28
Simplified Spiral ModelSimplified Spiral Model
If risks cannot be resolved, project is immediately terminated
If risks cannot be resolved, project is immediately terminated
![Page 29: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/29.jpg)
29
Full Spiral ModelFull Spiral Model
Radial dimension: cumulative cost to date Angular dimension: progress through the
spiral
Radial dimension: cumulative cost to date Angular dimension: progress through the
spiral
![Page 30: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/30.jpg)
30
Full Spiral Model (contd) Full Spiral Model (contd)
![Page 31: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/31.jpg)
31
Analysis of Spiral ModelAnalysis of Spiral Model Strengths
Easy to judge how much to test No distinction between development, maintenance
Weaknesses For large-scale software only For internal (in-house) software only
Strengths Easy to judge how much to test No distinction between development, maintenance
Weaknesses For large-scale software only For internal (in-house) software only
![Page 32: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/32.jpg)
32
Object-Oriented Life-Cycle ModelsObject-Oriented Life-Cycle Models Need for iteration within and between phases
Fountain model Recursive/parallel life cycle Round-trip gestalt Unified software development process
All incorporate some form of Iteration Parallelism Incremental development
Danger CABTAB
Need for iteration within and between phases Fountain model Recursive/parallel life cycle Round-trip gestalt Unified software development process
All incorporate some form of Iteration Parallelism Incremental development
Danger CABTAB
![Page 33: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/33.jpg)
33
Fountain ModelFountain Model
Features Overlap
(parallelism) Arrows
(iteration) Smaller
maintenance circle
Features Overlap
(parallelism) Arrows
(iteration) Smaller
maintenance circle
![Page 34: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/34.jpg)
34
Software Process SpectrumSoftware Process Spectrum
lightweight heavyweightmiddleweight
XPSCRUM
DSDMFDD RUPdX
ICONIXCrystal Clear Crystal Violet
EUPOPEN
![Page 35: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/35.jpg)
35
ConclusionsConclusions Different life-cycle models Each with own strengths Each with own weaknesses Criteria for deciding on a model include
The organization Its management Skills of the employees The nature of the product
Best suggestion “Mix-and-match” life-cycle model
Different life-cycle models Each with own strengths Each with own weaknesses Criteria for deciding on a model include
The organization Its management Skills of the employees The nature of the product
Best suggestion “Mix-and-match” life-cycle model
![Page 36: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/36.jpg)
36
Model Driven ArchitectureModel Driven Architecture
![Page 37: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/37.jpg)
37
What is MDA in essence?What is MDA in essence?
Automated approach to translate high level design to low level implementation by means of separation of concerns
From high-level model to running application
Risk proportional to expectations!
Automated approach to translate high level design to low level implementation by means of separation of concerns
From high-level model to running application
Risk proportional to expectations!
![Page 38: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/38.jpg)
38
Finding the “right” languageFinding the “right” language
Assembler
3GL
IDEs & 4GL
Model Driven Architecture
Computer Hardware
DeveloperA
uto
matio
n
Ab
straction
![Page 39: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/39.jpg)
39
“ You should use iterative development only on projects you want to
succeed”
“ You should use iterative development only on projects you want to
succeed”
Martin FowlerMartin Fowler
![Page 40: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/40.jpg)
40
Model Driven ArchitectureModel Driven Architecture
Can you actually have incremental MDA? Or is it automated waterfall?
Need rigorous models Need high quality requirements
Capture requirements Understand requirements
Can you actually have incremental MDA? Or is it automated waterfall?
Need rigorous models Need high quality requirements
Capture requirements Understand requirements
![Page 41: Slides chapter 3](https://reader035.vdocuments.net/reader035/viewer/2022081507/55598218d8b42a65298b574d/html5/thumbnails/41.jpg)
41
MDA or Offshore?MDA or Offshore?
Automation versus reduce cost of labor
Objectives Reduce required intelligence Increase repetition
Goal Reduce costs of development
Automation versus reduce cost of labor
Objectives Reduce required intelligence Increase repetition
Goal Reduce costs of development