1

Chapter 3Process Models

（过程模型）

Chapter 3Process Models

（过程模型）Software Engineering: A Practitioner’s Approach, 6th editionby Roger S. Pressman

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

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

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"

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

Process model goalsProcess model goals

6

判断目前所处的阶段

是否符合转移条件

该阶段的完成条件和下一个阶段的任务

否

是

Process as a "black box"Process as a "black box"

Product

Process

Informal Requirements

Quality?Uncertain /Incomplete requirementIn the beginning

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（成立）

Process as a "white box"Process as a "white box"

Product

Process

Informal Requirements

feedback

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

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

12

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 advocatePrescriptive process models advocate （倡导）（倡导） an an orderly approachorderly approach （有序的方法）（有序的方法） to software to software engineeringengineering

13

The Waterfall ModelThe Waterfall Model

14

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.

15

16

Process for Offshore?Process for Offshore?

Deploy

Analysis

Design

Accept. test

Construct

System test

17

The V ModelThe V ModelIf we rely on testing alone, defects created first are detected lastIf 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

18

Incremental Models: IncrementalIncremental Models: Incremental

19

Incremental Models: RAD ModelIncremental Models: RAD Model

20

Evolutionary Models: PrototypingEvolutionary Models: Prototyping

21

Risk ExposureRisk Exposure

最佳时间点

22

Unified Process Model（统一过程模型）

Unified Process Model（统一过程模型）A software process that is:A software process that is:

use-case drivenuse-case driven （用例驱动）（用例驱动） architecture-centricarchitecture-centric （以架构为中心）（以架构为中心） iterative and incrementaliterative and incremental

（迭代和增量式）（迭代和增量式）

Closely alignedClosely aligned （结盟）（结盟） with thewith the

Unified Modeling Language (UML)Unified Modeling Language (UML)

23

inceptioninception

The Unified Process (UP)The Unified Process (UP)

24

UP Work ProductsUP Work Products

25/39

Enterprise Unified Process（企业统一过程）Enterprise Unified Process（企业统一过程） EUP （ Enterprise Unified Process ）

2003 年提出的企业统一过程，是对 RUP的扩展，试图从企业的角度，而非项目的角度，来看待 IT 项目对企业业务的价值。强调的是跨系统的问题，比如企业级的架构、战略性的重用以及组合管理。

EUP （ Enterprise Unified Process ）2003 年提出的企业统一过程，是对 RUP的扩展，试图从企业的角度，而非项目的角度，来看待 IT 项目对企业业务的价值。强调的是跨系统的问题，比如企业级的架构、战略性的重用以及组合管理。

26

Enterprise Unified Process（企业统一过程）Enterprise Unified Process（企业统一过程）

•Enterprise Business Modeling•Portfolio Management•Enterprise Architecture•Strategic Reuse•People Management•Enterprise Administration•Software Process Improvement

27/39

Enterprise Unified Process（企业统一过程）Enterprise Unified Process（企业统一过程）

EUP 阶段及里程碑 EUP 阶段及里程碑 先启定义项目范围估计成本和进度定义风险开发业务用例准备项目环境

精化描述需求细节识别架构确认架构改进项目环境为项目提供人员

构建建模、构建及测试系统开发支持文档

移交系统测试用户测试系统正式上线系统部署

产品化运营系统支持系统管理变更请求监视系统灾难恢复准备

退役详细的集成分析互联系统评估数据迁移系统集成测试删除系统

生命周期目标（ LCO ）并行范围初始需求定义并行计划风险验收过程验收业务用例项目计划

生命周期架构（ LCA ）前景的稳定性需求的稳定性架构的稳定性风险验收成本估算验收成功现实机会项目计划

初期操作能力（ IOC ）系统的稳定性需求的稳定性已准备的涉众风险验收费用估算验收项目计划

产品发布（ PR ）业务验收操作验收支持验收成本及估算验收

发布更新（ RR ）发布删除或删除系统进度表涉众验收操作验收支持验收

发布退役（ RET ）删除系统涉众验收

Enterprise Unified Process（企业统一过程）Enterprise Unified Process（企业统一过程）

四类生命周期 四类生命周期

28/39

系统开发生命周期

系统生命周期

信息技术（ IT ）生命周期

组织 / 业务生命周期

29

Enterprise Unified Process（企业统一过程）Enterprise Unified Process（企业统一过程）

项目组合管理流程 项目组合管理流程

30

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

31

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

32

Evolutionary Models: The SpiralEvolutionary Models: The Spiral

33

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

34

Simplified Spiral ModelSimplified Spiral Model

If risks cannot be resolved, project is immediately terminated

If risks cannot be resolved, project is immediately terminated

35

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 （沿着螺旋经历的过程）

36

Full Spiral Model (contd) Full Spiral Model (contd)

37

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

38

Software Process SpectrumSoftware Process Spectrum

lightweight heavyweightmiddleweight

XPSCRUM

DSDMFDD RUPdX

ICONIX

Crystal Clear清澈透明

Crystal Violet结晶紫兰

EUPOPEN

39

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 （混合 - 匹配生命周期模

式）