1

Lecture 11 软件过程改进

2

1. 软件过程概念 ISO 的定义：软件过程（也称为软件生存

周期过程）是软件生存周期中的一系列相关过程（ Process ）。

过程就是活动的集合，活动是任务的集合，任务则起到把输入加工成输出的作用。活动的执行可以是顺序的、迭代的（重复的）、并行的、嵌套的，或者是有条件地引发的。

3

根据 IEEE 对软件过程概念的解释，软件过程分成七大类：软件采购、软件开发、软件维护、软件运作、软件获取、软件管理、软件支持而 ISO12207 （软件生存周期过程）则分别将这七大类活动划归到三大类中：基本过程、支持过程和组织过程

4

软件过程包含以下三个含义：1.个体含义，即指软件产品或系统在生存周期

中的某一类活动的集合。如获取过程、供应过程、开发过程、管理过程等等。

2.整体含义，即指软件产品或系统在所有上述含义下的软件过程的总体。

3.工程含义，即指解决软件过程的工程，它应用软件工程的原则、方法来构造软件过程模型，并结合软件产品的具体要求进行例化，以及在用户环境中运作，以此进一步提高软件生产率、降低成本。

5

过程的意义

输 入x

输出 P

系统因素

随机因素过程原理图与过程输出的分布

6

2. 软件过程质量1. 过程质量 质量是指“某一事物的特征和属性”，作为一个事物的属性，质量往往指的是事物的可度量的特征，且这些特征都是可以与已知标准进行比较的。

软件过程和软件产品一样，都是属于知识或信息实体，对其在质量方面的定义和描述具备一定的复杂性。尽管如此，软件过程质量（即过程质量）的表现形式不外乎体现在静态和动态这两个方面。

7

（ 1 ）软件过程静态方面 当软件过程仅以某种特定的描述形式存在时，过程质量就表现为静态的一面。此时的过程质量实际上就是软件过程描述本身所具备的属性，它表现为：功能性：该过程描述满足实际需要的程度；易使用性：用户使用该过程描述进行过程实施和运作所需的努力程度，其中包括易理解性和易学习性等子特性；准确性：描述特定类型的软件过程的准确程度，可包含精确性、一致性、完整性、冗余度等子特性；易维护性：用户在改进基于该描述形式的软件过程时所需的努力程度，其中包括易分析性和易修改性等子特性；

8

（ 2 ）软件过程动态方面 当软件过程在执行运作时，过程质量就表现为动态的一面。 此时的过程质量是以软件过程所表现出的过程运作能力来衡量，其中包括过程运作能否达到所预定的目标、是否保证了软件产品的质量等，可以简称为过程能力。

9

3. 软件过程改进三步：软件过程及其实例进行不断优化的活动。

过程度量过程评价过程改进

10

3.1 软件过程的度量 过程度量是针对所指定的软件过程，以某种方式对其过程能力指标实现合理的量化，从而以一定的标准衡量该软件过程的质量。过程度量的特点：

过程质量静态特征动态特征：过程能力是过程质量的动态表现、是通过过程运作而体现的。因而和产品度量不同，过程度量是同过程运作紧密相关的，只有经过过程运作，过程度量才能体现其“过程”含义，这是过程度量与产品度量的根本区别。

11

客观度量与主观度量度量的客观性是指所得到的关于某对象的度量值是该对象的真实描述。

例如 LOC 度量（代码行数）就是具备客观性的度量；

度量的主观性是指所得到的关于某对象的度量值是由度量者的主观判断得到的，因此所得到的度量值会随度量者的不同而异。

如系统的易学习性”的度量值。

12

过程度量的通用模式

问题解决

值转换

解释

数据获取

用户问题目标问题解决模型

用户解释目标解释模型

度量约束度量知识

获取约束获取技术模型

度量活动

外部输入 输出内容

原 始 数 据 ... ...

转换后的度量值 ... ...

度量结果 ... ...

分析结论

T ( 过程周期 )

t

13

3.2 过程评价（ Evaluation ） 过程评价：以一系列的标准对软件过程的质量进行评定而使软件过程不断改进和优化的系列活动。过程评价 / 过程评估： SEI 在 “评价 /评估指南”

“评估指南”：当用户以过程改进为出发点，对自身机构的软件过程进行评定时

• 评定过程现有的过程能力• 预见其能力，潜在缺陷和改进方向“评价指南” 仅是客观评定过程能力当时所达到的程度。

14

无论是过程评价还是过程评估，其目的都是：认知过程能力、比较过程能力、改进过程能力。

过程评价有多种实现方法，其中过程度量便是一种最有效且最系统化的方法，其他诸如问卷调查、实际走查（ walk through ）等也是实现过程评价的常用方法。

15

3.3 过程改进过程改进是在软件过程工程中为了更有效地达到优化软件过程的目的所实施的改善或改变其软件过程的系列活动。认知现有软件过程发现软件过程存在的问题和缺陷提出改进的意见软件过程的改进和完善

过程改进的关键是发现软件过程中所存在的问题和缺陷，而过程度量正是发现问题和缺陷的必备手段。

16

3.4. 度量模型 过程度量模型就是要研究过程度量 所涉及的属性和问题，从而规范过程度量的内容和步骤，实现过程度量的目标。1. FCM （ Factor Criteria Metric ）模型 1976年 Bohem 等提出定量进行软件质量评价的概念，两年之后， Walters 和 McCall 提出一个质量要素 - 准则 - 度量的三层次式软件质量度量模型，其中，要素是软件质量的反映，软件属性可用作评价准则，量化地度量软件属性可反映软件质量的优劣。此后，G.Murine 提出软件质量度量技术 (SQM) ，用于定量地评价软件质量。 1991年 ISO推出了以 FCM 模型作为基准模型的标准 ISO9126 ：“信息技术：软件产品评价质量特性及其使用指南”

17

ISO/IEC 9126 质量模型分三个层次：质量特性（ 6个），质量子特性（ 21 个）功能性 Functionality

• 适合性 Suitability• 准确性 Accurateness• 互操作性 Interoperability• 依从性 Compliance• 安全性 Security

可靠性 Reliability• 成熟性 Maturity• 容错性 Fault tolerance• 易恢复性 Recoverability

易使用性 Usability• 易理解性 Understandability• 易学习性 Learnability• 易操作性 Operability

18

效率• 时间特性 Time behavior• 资源特性 Resource behavior

可维护性 Maintainability• 易分析性 Analyzability• 易改变性 Changeability• 稳定性 Stability• 易测试性 Testability

可移植性 Portability• 适应性 Adaptability• 易安装性 Installability• 一致性 Conformance• 易替换性 Replaceability

19

FCM 模型的基本出发点是：通过一种分层结构建立面向用户的质量要素、面向软件过程属性的准则和度量之间的关系，通过对软件过程属性的度量来反映软件过程质量特性。

FCM 模型

Factor

Criterion Criterion Criterion

Metric Metric Metric

20

以 FCM 模型为基础构造的度量模型的特点： （ 1 ）第一层先定义面向用户（或是“外部

的”）的关于软件过程质量的软件特性；

（ 2 ）第二层通过分解第一层的软件过程外部质量特性，建立可被度量的软件过程内部属性的基本范围；

（ 3 ）根据第二层指定的基本范围内的软件过程属性，找到使其量化的度量方法，形成第三层。

21

3.5 过程改进方式在软件过程工程的各项活动中，过程改进活

动是一项综合且需要持续开展的活动 .软件机构的过程模型，具体软件项目的过程实例

22

3.5.1 过程改进的对象过程模型过程实例

主要对过程模型改进，这是因为：1 ）过程模型代表了一类软件项目的共性，这使得针对过程模型的改进活动比针对具体项目的过程实例的改进活动更具有代表性，因而更加有效；

2 ）过程模型通常体现了该机构的项目管理和技术管理手段。优秀的软件机构更加注重过程模型的改进，以提高其管理水平。

23

3.5.2 过程改进的两种模式

目标驱动模式 目标驱动的过程改进模式是指根据一个预先给定的目标，自顶向下制定过程度量或评价模型，有目的地开展相关改进活动的过程改进模式；缺陷驱动 模式

缺陷驱动的过程改进模式是指根据过程实施时所产生的关于过程缺陷的反馈信息，进行有针对性改进活动的过程改进模式。

24

过程改进的通用步骤

过程改进的大纲方案

（ 1 ）确定机构的需求和商业目标

（ 2 ）初始化过程改进

（ 3 ）准备并实施过程评价

（ 6 ）确认改进结果

（ 4 ）分析评价结果和制定

改进活动计划

（ 5 ）实施改进活动

（ 8 ）监督改进后的过程性能

（ 7 ）维持改进结果

已识别的范围和优先级

初步的过程改进大纲方案

评价要求

当前评价的能力

评价结果

已实现的改进

已被证实的改进结果

再评价的要求

再评价结果

经批准的活动方案

工业标准 过程模型

中的实践描述 能力确定中的目标能力概括

针对能力确定的

已被保持的改进结果

改进的预备信息

过程改进的要求

机构的需求

25

4. CMM 软件过程成熟度模型CMM （ Capability Maturity Model ）即

能力成熟度模型美国卡内基梅隆大学软件工程研究所（ SEI ）在美国国防部资助下于二十世纪八十年代末建立的用于评价软件机构的软件过程能力成熟度的模型。主要目的在于为大型软件项目的招投标活动提供一种全面而客观的评审依据，而发展到后来，又同时被应用于许多软件机构内部的过程改进活动中。

26

CMM 可以指导软件机构，通过确定当前的过程成熟度状况，识别对过程改进起关键作用的一些问题，来明确过程改进的方向和策略；通过一组有限的与过程改进的方向和策略相一致的过程改进活动，软件机构便能稳步而有效地改善其软件过程，使其过程能力得到循序渐进的增长。

CMM 提供了一个级别框架： 1级 -初始级、 2级 - 可重复级、 3级 - 已定义级、 4级 -已管理级和 5级 - 优化级。

27

软件组织的成熟与不成熟

成熟表现不成熟表现

28

软件组织的成熟与不成熟 1. 不成熟的软件组织软件过程一般并不预先计划，而是在项目进行中由实际工作人员及管理员临时计划有时，即使软件过程已计划好，仍不按计划执行没有一个客观的基准来判断产品质量，或解决产品和过程中的问题对软件过程步骤如何影响软件质量，一无所知，产品质量得不到保证。而且，一些提高质量的环节，如检查、测试等经常由于要赶进度而减少或取消。

29

产品在交付前，对客户来说，一切都是不可见的没有长远目标，管理员通常只关注解决任何当前的危机由于没有实事求是地估计进度、预算，因此他们经常超支、超时。当最后期限临近，他们往往在功能性和质量上妥协，或以加班加点方式赶进度。

30

2. 成熟的软件组织具有全面而充分的组织和管理软件开发和维护过程的能力管理员监视软件产品的质量以及生产这些产品的过程制定了一系列客观基准来判别产品质量，并分析产品和过程中的问题进度和预算可以按照以前积累的经验来制定，结果可行。预期的成本、进度、功能与性能和质量都能实现，并达到目的能准确及时地向工作人员通报实际软件过程，并按照计划有规则地 (前后一致，不互相矛盾 ) 工作

31

凡规定的过程都编成文档软件过程和实际工作方法相吻合。必要时，过程定义会及时更新，通过测试，或者通过成本 -效益分析来改进过程。全体人员普遍地、积极地参与改进软件过程的活动。在组织内部的各项目中，每人在软件过程中的职责都十分清晰而明确，每人各守其责，协同工作，有条不紊，甚至能预见和防范问题的发生。

32

软件过程成熟度级别 1.初始（ initial ）级： 软件过程的特点是无秩序的，甚至是混乱的。几乎没有什么过程是经过妥善定义的，成功往往依赖于个人或小组的努力。

2. 可重复（ repeatable ）级： 建立了基本的项目管理过程来跟踪成本、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功。

33

3. 已定义（ defined ）级： 己将管理和工程活动两方面的软件过程文档化、标准化，并综合成该机构的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。

4. 已管理（ managed ）级： 收集对软件过程和产品质量的详细度量值，对软件过程和产品都有定量的理解和控制。

5. 优化（ optimizing ）级： 过程的量化反馈和先进的新思想、新技术促使过程不断改进。

34

5.优化级

4.已管理级

3.已定义级

2.可重复级

1.初始级

标准、一致的过程

有纪律的过程

可预测的过程

持续改进过程

软件过程成熟度的 5个级别

35

成熟度级别的行为特征1. 初始级：(1) 软件过程的特点是杂乱无章，有时甚至混乱。几

乎没有定义过程的规则或步骤。(2) 过分的承诺。常作出良好的承诺：如“按照软件

工程方式，有序的工程过程来工作”；或达到高目标的许诺。但实际上却出现一系列危机。

(3)遇到危机就放弃原计划过程，反复编码和测试。(4) 成功完全依赖个人努力和杰出的专业人才，取决

于超常的管理人员和杰出有效的软件开发人员。具体的表现和成果都源于或者说是决定于个人的能力和他们先前的经验、知识以及他们的进取心和积极程度。

36

(5) 能力只是个人的特性，而不是开发组织的特性。依靠着个人的品质或承受着巨大压力，或找窍门取得成果。但此类人一旦离去，对组织的稳定作用也消失。

(6) 软件过程是不可确定的和不可预见的。软件成熟性程度处于第一级的软件组织的软件过程在实际的工作过程中被经常的改变( 过程是随意的 ) 。这类组织也在开发产品，但其成果是不稳定的，不可预见的，不可重复的。也就是说，软件的计划、预算、功能和产品的质量都是不可确定和不可预见的。

37

2. 可重复级：(1) 进行较为现实的承诺，可按以前在同类项

目上的成功经验建立的必要过程准则来确保再一次的成功。

(2) 主要是逐个项目地建立基本过程管理条例来加强过程能力。

(3) 建立了基本的项目管理过程来跟踪成本、进度和功能。

(4) 管理工作主要跟踪软件经费支出、进度及功能。识别在承诺方面出现的问题。

38

(5) 采用基线 (baseline) 来标志进展、控制完整性。基线是指已经通过正式评审和批准的某规约或产品（一个版本），可作为进一步开发的基础，并只能通过正式的变更控制规程被改变。

(6) 项目的软件标准均已确定，并且机构应保证能准确地遵循这些标准。

(7) 通过子合同建立有效的供求关系。

39

3. 已定义级：(1) 无论管理方面或工程方面的软件过程都己文档化、标准化，并综合成软件开发组织的标准软件过程。

(2) 软件过程标准被应用到所有的工程中，用于编制和维护软件。有的项目也可根据实际情况，对软件开发组织的标准软件过程进行剪裁。

(3) 在从事一项工程时，产品的生产过程、花费、计划以及功能都是可以完全控制的， 从而软件质量也可以控制。

40

(4) 软件工程过程组 (SEPG)负责软件过程活动

(5) 在全组织范围内安排培训计划。

41

4. 已管理级：(1) 制定了软件过程和产品质量的详细而具体

的度量标准。软件过程和产品的质量都可以被理解和控制。

(2) 软件组织的能力是可预见的。原因是软件过程是被明确的度量标准所度量和操作。不言而喻，软件产品的质量就可以预见和得以控制。

(3) 组织的度量工程保证所有项目对生产率和质量进行度量，并作为重要的软件过程活动

42

(4) 具有良好定义及一致的度量标准来指导软件过程，并作为评价软件过程及产品的定量基础。

(5) 在开发组织内已建立软件过程数据库，保存收集到的数据，可用于各项目的软件过程

43

5. 优化级：(1) 整个组织特别关注软件过程改进的持续性、

预见及增强自身。防止缺陷及问题的发生。不断地提高他们的过程能力。

(2) 加强定量分析，通过来自过程的质量反馈和吸收新观念、新科技，使软件过程能不断地得到改进。

(3) 根据软件过程的效果，进行成本 /效益分析，从成功的软件过程实践中吸取经验，加以总结。把最好的创新成果迅速向全组织转移。对失败的案例，由软件过程小组进行分析以找出原因。

44

(4) 组织能找出过程的不足并预先改进。把失败的教训告知全体组织以防止重复以前的错误。

(5) 对软件过程的评价和对标准软件过程的改进，都在全组织内推广。

45

4.1. 能力成熟度模型的结构 每一个成熟度级别由几个关键过程域组成，

每一个关键过程域被分解成称为共同特性的五个部分（执行约定，执行能力，执行活动，测量和分析，验证实现 ），这些共同特性包括了关键实践，实现了这些关键实践后，就实现了关键过程域的目标。

每一个成熟级别的分解都由一个抽象的摘要开始，最后到对关键过程实践的操作定义。

46

成熟度级别

关键过程域

共同特性

关键实践

包含

划分为

包含

过程能力

表明

目标

实现

实施或制度化

解决

活动或基础设施

描述

CMM 结构

47

成熟度级别（ maturity level ） 成熟度级别是一个严格定义的、向着达

到成熟软件过程目标进发的平台。 CMM的顶层结构中包括五个成熟度级别。

每个成熟度级别表示了过程能力的水平。

48

关键过程域（ Key Process Area ，简称 KPA ）

CMM 提供了 18 个关键过程域，除级别 1外，每个成熟度级别都包含几个关键过程域。关键过程域确定了实现一个成熟度级别所必须解决的问题。关键过程域体现了该成熟度级别的要求。为

了达到一个成熟度级别，该级别 ( 以及较低级别 ) 的所有关键过程域必须得到满足，并且过程必须规范化。每一个关键过程域都有一组对改进过程能力非常重要的目标，并确定了一组相应的活动，完成了这些活动，就达到了相应的目标。

49

缺陷预防技术更新管理过程更改管理

优化级

定量过程管理软件质量管理

已管理级

机构过程焦点机构过程定义培训大纲综合软件管理软件产品工程组间协调同行评审

已定义级

需求管理软件项目计划软件项目跟踪和监督软件分包合同管理软件质量保证软件配置管理

可重复级

初始级

能力成熟度级别中的关键过程域（共 18 个）

50

关键实践（ key practices ）18 个关键过程包含 316 个关键实践。关键

实践描述了对关键过程域的有效实施和规范化起最重要作用的基础设施和活动。

关键实践描述要做“什么”，但是它们没有强行规定应当“怎样”完成目标。每一个关键实践由一个单独的句子组成，后面常常有更详细的描述信息，这些描述信息可能包括实例和有关该关键实践的详细阐述。

51

共同特性 共同特性是一些属性，指明一个关键过程域

的执行和规范化是否有效、可重复和可持续。共有 5 个共同特性 : 执行约定，执行能力，执行活动，测量和分析，验证实现。

执行约定： 执行约定描述机构为确保过程的建立和持续而必须采取的一些措施。典型内容包括建立机构策略和领导关系。

52

执行能力： 执行能力描述了项目或机构完整地实现软件过程所必须有的先决条件。典型内容包括资源、机构结构和培训。

执行活动： 执行活动描述了执行一个关键过程域所必需的活动、任务和规程。典型内容包括制定计划和规程、执行和跟踪以及必要时采取纠正措施。

测量和分析： 测量和分析描述了为确定与过程有关的状态所需的基本测量实践。这些测量可用来控制和改进过程。典型内容包括可能采用的测量实例。

53

验证实现： 验证实现描述了为确保执行的活动与已建立的过程一致所采取的步骤。典型内容包括管理部门和软件质量保证组实施的评审和审核。

各关键过程域的详细描述，参见《能力成熟度模型（ CMM ）：软件过程改进指南》，卡耐基梅隆大学软件工程研究所编著，刘孟仁等译，电子工业出版社出版。

54

关键过程域实例第 3级的关键过程域：机构过程焦点 机构过程焦点的目的是，为能改进机构整体软件

过程能力的软件过程活动建立机构的职责。 机构过程焦点包括，建立和维护机构软件过程和项目软

件过程的默契关系，并协调有关评估、开发、维护和改进这些过程的活动。

机构提供长期的约定和资源，以协调现在和将来的软件项目的软件过程的开发和维护。该项工作由某个小组实施，例如软件工程过程组。它负责机构的软件过程活动，特别是负责开发和维护机构标准软件过程和相关过程资源（如在机构过程定义关键过程域中说明的），并协调软件项目的过程活动。

55

目标目标 1：机构内部软件过程的制定和改进活动

协调一致。目标 2：相对于过程标准，所使用的软件过程

的优势和薄弱环节标识清楚。目标 3 ：机构级的过程开发和改进活动有计划。

56

执行约定约定 1：机构遵循书面的管理策略，协调整个机构范围内的软件过程开发和改进活动。

该策略一般规定 : 1. 建立一个小组，负责机构级的软件过程活动，

使这些活动与各项目协调一致。 2. 定期评估项目所使用的软件过程，以确定其优势和薄弱环节。

3. 对机构标准软件过程进行合理地剪裁，以得到项目使用的软件过程。

关于机构标准软件过程，参见综合软件管理关键过程域的活动 1 。

4. 每个项目的软件过程、工具和方法的改进和其他有用信息，可用于其他项目。

57

约定 2：上级管理部门倡导和支持机构的软件过程开发和改进活动。

上级管理部门： 1. 向机构成员和负责人说明有关软件过程活动的约定。

2. 制定资金、人员配备和其他资源的长期计划和约定。

3. 制定管理和执行有关软件过程开发和改进活动的策略。

58

约定 3：上级管理部门监督机构的软件过程开发和改进活动。

l. 确保机构标准软件过程满足企业目标和策略。

2. 提出关于软件过程开发和改进活动优先次序的建议。

3. 参与制定软件过程开发和改进计划。 a. 上级管理部门与更高层人员和负责人共同协调软件过程需求及问题

b. 上级管理部门与该机构负责人进行协调，以获得负责人和机构成员的支持和参与

59

执行能力能力 1：有一个负责机构的软件过程活动的小组。 一个小组是一些部门、负责人和人员的组合，负责一组

任务和活动。小组的规模可以不同，既可以是单个兼职的人，也可以是多个来自不同部门的兼职人员，也可以由几个专职人员组成。组成小组时考虑的因素包括：分派的任务和活动、项目规模、机构结构和机构文化。某些小组，如软件质量保证组，集中关注项目活动 ; 而其他一些小组，例如软件工程过程组，集中关注机构范围内的活动。

1. 条件可能时，小组成员以专职工作的软件专业人员为核心，并尽可能有其他的兼职人员支持。

该小组最一般的例子是软件工程过程组（ SEPG）。 2. 小组成员中有软件工程及软件相关科目的代表。

60

软件工程及软件相关科目的实例有：• 软件需求分析• 软件设计• 程序编码• 软件测试• 软件配置管理• 软件质量保证

61

能力 2：为实施机构的软件过程活动提供了充足的资源和资金。

1. 委派在特定领域具有特长的人员支持该小组。 特定领域的实例有：

• 软件重用• 计算机辅助软件工程技术 (CASE) • 测量• 培训课程开设

2. 有支持该机构软件过程活动的工具。 支持工具的实例有：

• 统计分析工具• 桌面出版工具• 数据库管理系统• 过程建模工具

62

能力 3 ：负责机构软件过程活动的小组成员接受过实施这些活动所需的培训。

培训的实例有：• 软件工程实践• 过程控制技术• 机构过程变动管理• 软件过程计划、管理和监督• 技术转变参见培训大纲关键过程域。

63

能力 4：软件工程组和其他软件相关小组的成员接受过机构软件过程活动及其在这些活动中的任务方面的定向培训。

参见培训大纲关键过程域。

64

执行活动活动 1：定期评估软件过程，并根据评估结果制定行

动计划。 评估一般每隔一年、一年半至三年进行一次。

评估可针对机构中所使用的所有软件过程，也可通过对过程和项目进行抽样评估。评估机构软件过程能力的方法实例之一是 SEI 软件过程评估方法。

行动计划标识：涉及哪些评估结果针对评估结果实施更改软件过程的准则负责实施更改的小组或个人

65

活动 2：机构制定和维护它的软件过程开发和改进活动的计划。

该计划：1. 以软件过程评估后的行动计划和其他的机构过程改

进倡议为基础。2. 确定要实施的活动及实施这些活动的进度。3. 确定负责这些活动的小组和个人。4. 确定所需的资源，包括人员配备和工具。5. 初始发布和有大改动时通过同行评审。

参见同行评审关键过程域。 6. 机构的软件负责人和上级负责人评审认可。

66

活动 3 ：在机构级协调关于机构和项目的软件过程的开发和改进活动。

涉及的软件过程有： 1. 机构标准软件过程。 关于机构标准过程，参见机构过程定义关键

过程域的活动 1 和活动 2 。 2. 项目定义的软件过程。 关于项目定义的软件过程。参见综合软件管

理关键过程域的活动 1 和活动 2 。

67

活动 4 ：在机构级协调有关软件过程数据库的使用。

机构的软件过程数据库用来收集机构和项目的软件过程以及生成的软件产品的信息。

关于机构的软件过程数据库，参见机构过程定义关键过程域的活动 5 。

68

活动 5：监控和评价机构中限制使用的新过程、方法和工具。合适时，推广到机构的其他部分。

活动 6 ：在机构内协调机构和项目的软件过程的培训。

1. 制定有关机构和项目软件过程的专题培训计划。

2. 合适时，培训由负责机构软件过程活动的小组（如软件工程过程组）或培训小组准备和实施。

参见培训大纲关键过程域。

69

活动 7 ：向与实施软件过程有关的小组通报机构和项目中软件过程开发和改进活动的情况。

通报方式的实例有：• 过程电子公告板• 过程咨询委员会• 工作小组• 信息交流会• 调查• 过程改进组• 日常讨论

70

测量和分析测量 1：测量机构的软件过程开发和改进活动

的状态 测量的实例有：

• 机构在过程评估、开发和改进活动中已完成的工作、工作量和耗费的资金，与计划相比较

• 每次软件过程的评估结果，与以前的评估结果和建议相比较

71

验证执行验证 1：上级管理部门定期评审软件过程开发和改进

活动。 上级管理部门实施定期评审的主要目

的是适当地、及时地掌握软件过程活动。在满足机构需求的前提下，只要有适当的机制来报告异常情况，评审的时间间隔就尽可能长些。

1. 对照计划，评审有关开发和改进软件过程活动的进展和状态。

2. 讨论低层不能解决的冲突和问题。 3. 指定和评审行动措施，并跟踪到关闭。 4. 编写评审的总结报告，并分发给相关的小组和

个人。

72

4.2. 基于 CMM 的过程改进 基于 CMM 的过程改进是目标驱动的过程改进模式。基于 CMM 的过程改进步骤如下：（ 1 ）确定本机构目前的 CMM 成熟度级别，明确下一步需要达到的级别 CMM 要求一个机构的成熟度级别应当从第2级开始并逐步升级实施，不允许进行成熟度级别的跨越实施。

73

（ 2 ）初始化过程改进 应当将过程改进本身作为一个项目来进行管理和策划。过程改进策划的内容包括：需确定详细步骤和活动及所涉及的里程碑、所涉及的关键人物、资源、进度，并确保所有相关人员得到并确认所策划的内容。。

74

（ 3 ）准备并实施过程评价 由于当前所处的级别已经明确，可以直接利用 CMM 得到当前软件机构的过程评价结果。例如，假如当前级别已被评价为 3级，则可根据第 2 、 3级所标明的能力特点、关键过程域、关键实践来表明本机构当前的过程评价结果

75

（ 4 ）分析评价结果和制定改进活动计划 根据所希望达到的 CMM级别的关键过程域中对目标、执行约定、执行能力、执行活动、测量和分析、验证执行等关键实践的要求，列出各子目标，对每个子目标，详细计划所需增加的活动、资源、度量方法或工具、验证手段等，并依此制定达到每个子目标的具体计划和实施策略。（ 5 ）实施改进活动 依照计划实施改进活动，注意应有必要的监控手段。

76

（ 6 ）确认改进结果 组织合格的评估师对所进行的改进活动进行评价，以判定是否达到本机构所希望达到的 CMM级别。对于那些希望其 CMM级别获得 SEI认可的软件机构而言，所聘请的评估师必须获得 SEI颁发的 CMM 评估师资质，而对那些仅希望通过 CMM 评价达到自身改进目标的软件机构而言，可在本机构内部组织进行 CMM级别的评价，其方式可模仿 SEI 要求的评价方式，也可用自身特有的方式进行评价，以判断是否达到了所希望的 CMM级别。

77

（ 7 ）维持和监督改进的结果 努力将机构维持在新的 CMM级别上。应当建立有效的监控机制来保持已达到的级别的持续性。对于 CMM5级的机构而言，由于这样的监控机制已经制度化，机构只需保持该制度的正常执行，就能确保改进结果的持续性。但对于其他级别的机构而言，应当指定专门人员监督新级别的维持，并赋予足够的权限。（ 8 ）重复 1到 7

78

5. SPICE 软件过程改进模式 SPICE （ Software Process Improvement an

d Capability dEtermine ）过程改进模式（ ISO15504 ）所面向的对象也是软件机构，其目标是通过对一个软件机构软件过程的评价达到以下目的：

1. 确定被评价的软件过程的能力；2. 对被评价的软件过程加以改进。

79

软件过程评价标准中过程评价、过程能力确定与过程改进之间的关系

过程评价

过程改进 过程能力确定

导致导致

评测

激发

软件过程

预测结果

改进结果

80

SPICE 软件过程评价标准由下述九个部分构成：第 1部分：概念和介绍指南第 2部分：过程和过程能力的基准模型第 3部分：评价第 4部分：评价指南第 5部分：评价模型和标识指南第 6部分：审核员资格指南第 7部分：过程改进指南第 8部分：确定承包方过程能力的使用指南第 9部分：术语

81

ISO15504 各部分之间的关系

(第 8部分 )

(第 3部分 )

(第 5部分 )

指示器

兼容性要求

基准模型(第 2部分 )

过程改进过程能力

过程评价

方法模型

评估师

(第 6部分 )

需求

指南(第 4部分 )

(第 7部分 )

82

ISO15504 过程评价模型是一个两维空间的模型：“过程”维和“过程能力”维。横向“过程”维参考了 ISO12207 （“软件

生存周期过程”），给出一个软件机构所应具备的 5 类软件生存周期过程，即客户供方类过程、工程类过程、支持类过程、管理类过程和机构一级过程类，每类过程中又有若干个具体的过程，这样的横轴表示出对一个软件机构而言，应当提供被评价的所有过程，见 P155 表5.2 。

83

评价模型的纵向“过程能力”维在一定程度上参考了 CMM 的评价模式，它给出每个过程所处的从 0级到 5级的 6 个过程能力级别，即不完整级（ 0级）、已执行级（ 1级）、已管理级（ 2级）、已建立级（ 3级）、可预测级（ 4级）和不断优化级（ 5级），这 6 个级别又由 9 个具体的过程属性加以细化，见 P156表 5.3 ，对不同属性的满足程度决定了一个过程所处的级别，级别越高，表明一个软件过程越成熟，而级别越低，则表明该过程需要进行的改进更多。表 5.4 （ P158 ）显示出评价每个过程能力级别的评价尺度。

84

对每个过程而言，其能力的提高也需由低到高逐级提升，不能跨越。对一个软件机构而言， ISO15504 并不要求象 CMM 过程能力成熟度那样给出一个整体的过程能力评价值，而是要求给出机构内不同软件过程的能力成熟度。显然，由于不同的软件过程可能会有不同的能力成熟度，因此依据 ISO15504 评价模型所产生的评价结果，将会形成关于过程能力的一条能力曲线，曲线上方的部分表明该过程的改进空间。

85

0

1

2

3

4

5

CU

S.1

CU

S.2

CU

S.3

CU

S.4

CU

S.5

EN

G.1

EN

G.2

EN

G.3

EN

G.4

EN

G.5

EN

G.6

EN

G.7

SUP

.1

SUP

.2

SUP

.3

SUP

.4

SUP

.5

SUP

.6

SUP

.7

SUP

.8

MA

N.1

MA

N.2

MA

N.3

MA

N.4

OR

G.1

OR

G.2

OR

G.3

OR

G.4

OR

G.5

过程

过程能力

某软件机构过程能力曲线

86

SPICE 过程改进步骤 同 CMM 一样， SPICE 过程改进模式也是

目标驱动的过程改进模式，所不同的是， SPICE既可针对机构内单个过程模型的改进，也可针对一个机构整体过程模型的改进。当针对机构整体过程模型时，这种改进就是指机构的能力曲线的改进。

87

SPICE 过程改进步骤如下：（ 1 ）确定本机构目前的能力曲线，明确下一步需要达到的能力曲线 SPICE 要求一个机构的每一个软件过程的成熟度级别从第 0级开始并逐步升级实施，不允许进行成熟度级别的跨越实施。一个机构很容易确定自己当前每个软件过程所达到的成熟度级别，从而可绘制本机构的过程能力曲线。在此基础上，机构可根据适合度、资金状况、人员状况等因素，确定适合本机构的能力曲线目标。注意，该曲线中每个过程能力值最多只能比原过程能力提高一级，并将此曲线作为当前改进的目标。

88

0

1

2

3

4

5

CU

S.1

CU

S.2

CU

S.3

CU

S.4

CU

S.5

EN

G.1

EN

G.2

EN

G.3

EN

G.4

EN

G.5

EN

G.6

EN

G.7

SU

P.1

SU

P.2

SU

P.3

SU

P.4

SU

P.5

SU

P.6

SU

P.7

SU

P.8

MA

N.1

MA

N.2

MA

N.3

MA

N.4

OR

G.1

OR

G.2

OR

G.3

OR

G.4

OR

G.5

过程

过程

能力

某软件机构过程能力改进目标曲线

89

（ 2 ）初始化过程改进 应当将过程改进本身作为一个项目来进行管理和策划，因此首先应进行过程改进的完整策划。该策划应包括以下内容：需确定详细步骤和活动及所涉及的里程碑、所涉及的关键人物、资源、进度，并确保所有相关人员得到并确认所策划的内容。

90

（ 3 ）准备并实施过程评价 由于当前所处的级别已经明确，可以直接利用 SPICE 过程评价基准模型得到当前软件机构的过程评价结果。 例如，假如当前过程 ENG.1 的能力级别已被评价为 1级，则可根据第 1级级别的过程属性 1.1“ 过程执行属性”，以及 SPICE第 5部分“评价模型和标识指南”中关于 ENG.1的基本实践的要求，明确本机构当前的过程评价结果，而不必在此组织力量进行当前过程的评价。

91

（ 4 ）分析评价结果和制定改进活动计划 根据所希望达到的每个过程的 SPICE级别的过程属性要求及相关的过程实践活动的要求，列出各过程的改进子目标，对每个子目标，详细计划所需增加的活动、资源、度量方法或工具、验证手段等，并依此制定达到每个子目标的具体计划和实施策略。（ 5）实施改进活动 依照计划实施改进活动，注意应有必要的监控手段。

92

（ 6 ）确认改进结果 组织合格的评估师对所进行的改进活动进行评价，以判定是否达到机构所希望达到的能力曲线。（ 7）维持和监督改进的结果 如何使机构维持在新的能力曲线是本步骤需要解决的问题。应当建立有效的监控机制来保持已达到的级别的持续性，对于已达到第 5级的软件过程而言，由于这样的监控机制已经制度化，机构只需保持该制度的正常执行，就能确保改进结果的持续性，但对于处在其他级别的软件过程而言，应当指定专门的人员监督新级别的维持，并被赋予足够的权限。（ 8 ）重复 1到 7