计算机第2章 软件项目管理

第2章软件项目管理

软件项目管理的概

软件度量\

软件项目计划

项目进度安排与跟踪

软件质量管理

软件配置管理

2.1软件项目管理的概念

•项目：以一套独特而相互联系的任务为前提，有

效的利用资源，为实现一个特定目标所作的工作。

项目的成功受以下几个因素的制约：

技术范围、成本、进度、用户满意度、人员等。

•项目管理的职责：确保项目目标的实现，即在预

算内按时完成质量合格的产品。

•软件项目管理：是对传统项目管理进行软件工程

化的一种扩展与拓延，是它在软件工程的任何技术活动

之前开始，并持续贯穿于整个软件定义、开发和支持阶

段的庇护性活动，是决定一个产品或项目能否成功最重

要的指标之一。

2

4个P(People、Product、Process>Project)

对软件项目管理有实质性的影响：

人员必须被组织成有效的开发团队\.

产品需求被划分成较小的组成部分，便于分配给

软件开发小组。

开发过程应根据人员和产品选择合适的开发模型。

项目必须被组织成便于控制和管理的方式，使有

计划的进行。

3

♦人员：

人员是一个成功软件项目中最重要的因素。

可分为5类：

⑴高级管理者：负责定义业务问题;影刑着项目。

⑵技术管理者：组织、激励和控制开发人员。

⑶开发人员：负责开发一个产品或应用所需的技术。

⑷客户(customer)：负责说明待开发的软件需求。

⑸最终用户(user)：直接使用发布的软件。

4

每一个软件项目都有上述的人员参与。必须被组织成有

效的小组，最大限度的发辉每个人的技术和能力，激励他们

进行高质量的工作，并协调他们实现有效的通信。Constantine

提出4个“组织范型”：

(1)封闭式范型：传统的控制层次，品直通信，难以创新。

(2)随机式范型：小组管理较松散，依赖于成员

个人的主动性。不适合“有次序地完成”。

(3)开放式范型：具有封闭式范型的控制性，又包含随机

式范型的创新性。适合于解决复杂问题。可能不像其他类型

小组那么有效率。

(4)同步式范型：依赖于问题的自然划分，小组成员各自

解决问题的独立部分。主动通信差。

建立一个有凝聚力的小组，要有团队精神。

5

♦产品：

进行项目计划之前，应该首先定义产品的目的和范围,

考虑可选的解决方案，标识技术和管理的约束。无这些

信息，就不可能进行合理的、准确的成本估算、有效的

风险评估、适当的项目任务划分、可管理的项目进度安

排。

“目的”指从用户的角度标识出该产品的总体目标而

不考虑这些目标如何实现。

“范围”指标识出与产品相关的主要数据、功能和行

为。

确定了目的和范围，就可以根据产品交付的期限、预

算的限制、可用的人员、技术接口及各种其他因素，选

择最好的解决方案途径。

6

.过程

根据以下条件选择一个合适的软件过程模型：

⑴开发人员及需要该产品的用户

⑵产品本身的特征

⑶项目组的工作环境

采用如下的框架活动集合：

客户交流、计划、风险分析、工程实施、构造及发

布、用户评估。这些活动可被修改以适应不同软件项目

的特征和项目组的需求。每个活动可被分解为更详细的

工作任务。

如客户交流活动可能需要下列任务：

7

⑴列出需要澄清问题的清单

⑵安排与用户进行讨论的会议、

⑶评审用户要求及范围的陈述、

⑷研究推荐的解决方案\一

⑸为正式的会议准备工作文档\

⑹共同制订能反映软件的数据、功能和行为特

征的规约，形成软件范围的文档、

⑺评审文档、

⑻根据需求修改文档

庇护性活动贯穿于整个过程。

8

.项目

有计划的控制软件项目？Boehm提出了一种方法，

强调项目目标、里程碑、进度、责任、管理和技术方

法以及需要的资源,称之为W5H2原则。通过下面一系列

的提问和回答,可以导出项目的关键特征并产生项目计

划的大纲：

⑴为什么（Why）该系统被开发？值得吗？

⑵将做什么（What）?什么时候（When）做？

建立项目进度，标识关键的项目任务和里程碑。

⑶某功能由谁（Who）负责？开发人员的角色和责任。

⑷哪里需要（Where）?客户、用户和其他投资者也有

责任。

⑸工作将如何（How）进行？定义项目的管理和技术

策略。

⑹资源需要多少（Howmuch）?

9

软件项目管理中的主要元素及之间的关系

开发人员、小组、角色、任务、

工作产品、进度表（UML类图）之间的关系

10

软件项目管理的主要内容：

•定义问题（确定新系统的作用域-目标）

■确认项目的可行性

•建立项目的进度计划

•建立项目的质量保证体系

•建立项目配置管理体系和准则

■项目版本变更管理

•跟踪、监控项目的进展

•风险管理

•团队建设（人员管理，包括绩效评估等）

11

2.2可行性研究

1、可行性研究的任务和目的、

GB8566-88《计算机软件开发规范》中指出：

可行性研究的主要任务是了解客户的要求及现实环

境，从技术、经济和社会因素等方面研究并论证本软件

项目的可行性，编写可行性研究报告供项目管理人员评

审，以便作出是否开发软件项目的决策。

12

♦技术可行性

度量一个系统解决方案的实用性及技术资源的可用

性。

为醐何题：

⑴开发风险分析

(2)资源分析

(3)相关技术的发展(现有技术能否实现新系统、

技术难点、建议采用技术的先进性)

13

♦经济可行性

主要内容：

成本/效益分析

不可能得到精确的分析结果

.系统成本：

①软件开发费用〕\

②购置并安装软硬件机有关设备的费用估算

③系统安装、运行和维护费用

④人员培训费用J

.系统效益包括经济效益和社会效益

经济效益：可通过直接的或统计的方法估算

社会效益：定性的方法估算

14

♦社会因素可行性

政策、法律、使用、环境等

2、可行性研究的步骤

⑴复查确认系统目标、规模

⑵研究现行系统的工作流程

⑶导出目标系统高层逻辑模型

⑷导出和评价供选择的方案

⑸推荐可行的方案

(6)编写可行性研究报告，送审

15

3、可行性研究报告的编写提示

（1）引言：编写目的、背景、定义、参考资料；

（2）可行性研究的前提：要求、目标、条件、假

定和限制、进行可行性研究的方法、评价尺度;

（3）对现有系统的分析：工作流程、工作负荷、

费用开支、人员、设备、局限性；\

（4）所建议的系统：说明、数据流程和处理流程、

改进之处、影响、局限性、技术条件的可行性;

（5）可选择的其它系统方案；

（6）投资及收益分析：支出、收益、收益/投资比、

投资回收期等；

（7）社会条件方面的可行性（法律、使用）。

16

例：一个软件系统的开发费用（一次）：

人员：

2名系统分析员（450小时7名，45美元/小时）$40,500

5名系统开发人员（275小时/名，36美元/小时）$49,500

1名数据通讯专家（60小时/名，42美元/小时）$2,520

1名数据库管理员（30小时/名，42美元/小时）$1,260

2名技术写作者（120小时/名，25美元/小时）$6,000

1名秘书（160小时/名，15美元/小时）$2,400

2名在转换期间数据输入人员$960

（40小时/名，12美元/小时）

17

培训：

三天的开发人员内部培训课程$7,000

30个用户，三天的内部培训课程$10,000

复印$500

磁盘、纸张等消耗品X.$650

购买硬件、软件：

20台工作站Windows软件$1,000

20台工作站内存升级$8,000

网络软件$17,500

20台工作站办公软件产品$20,000

系统开发总费用$167,7901

（成本）

18

一个系统的年运行费用（每年）：

人员：

维护程序员/分析员（250小时/年,42美元/小时）

$10,500

网络管理量秘©小瞰年,50美元/小时

$15,000

购买硬件、软件升级：

硬件$5,000

软件$6,000

物资和杂项$3,500

每年总运行费用$40,000

19

2.3软件度量

软件度量（metrics）域分为过程度量、项目度量和

产品度量。对过程、项目及产品的特定属性进行度量

产生指导管理及技术动作的指标，使得管理者和开发

者能够：

•改善软件过程\

■辅助软件项目计划

■跟踪及控制软件项目的进展

•评价软件产品的质量

20

软件度量的方式：

直接度量

间接度量

­软件工程过程的直接度量包括所投入的成本和工作

量Q

■软件产品的直接度量包括产生的代码行数(LOC)、

执行速度、存储量大小、在某种时间周期中所报告

的错误数。

•软件产品的间接度量包括功能性、复杂性、效率、

可靠性、可维护性和许多其它的质量特性。

21

1.过程和项目的度量、、

♦过程度量：

使一个组织从战略上考察已有过程的功效，如开发

范型、工程任务的划分、工作产品、里程碑等，使管理者

评估那些部分起了作用。度量数据的收集跨越所有的项目,

经历较长的时间，目的是改善软件过程。

间接的度量一个软件过程的功效：

■软件发布之前发现的错误数

•交付给用户后报告的缺陷数

•花费的工作量、时间、成本

•与进度计划是否一致

22

个体软件过程（如PSP）提供了表格、脚本、标准以帮

助开发人员估算、计划以及度量、跟踪自己工作的方法。

过程度量对于一个组织（如企业）提高其总体的过程成

熟度能提供很大的帮助。如一个产品中，需求规约缺陷占

了25.5%,原因如图所示。

遗漏二义性通过分析一个完整

的鱼骨图可以导出能

改进软件过程以降低

错误和缺陷率的频率。

鱼骨图显示r某一类缺陷产生的原因

♦项目度量：

是战术的，使项目管理者能够以实时的方式改进项

目的工作流程及技术方法，如软件项目的工作量及时间

的估算。

项目度量的基础是历史项目中收集的数据。随着项

目的进展，所花费的工作量及时间和预算的值进行比较,

从而控制项目的进展。

另外，可根据文档的页数、评审的时间、功能点及

源代码行数来度量软件的生产率。

24

项目度量可在项目进行的基础上评估产品的质量，

以指导在必要时修改技术方法以改进质量。

软件项目度量建议每个项目都应该测量：

•输入：完成工作所需要的资源（如人员、环境）；

•输出：软件工程过程中产生的工作产品；

•结果：最终产品的有效性。

项目度量集成起来产生对整个软件组织公用的过程

度量。

25

2.软件度量的方法、、

(1)面向规模的度量

是对软件和软件开发过程的直接度.W

可以建立一个面向规模的数据表格来记录项目的某

些信息。该表格列出了在过去几年完成的每匚个软件开

发项目和关于这些项目的相应面向规模的数据。

26

基于所生产软件的“规模”，使用代码行作为其他

计算的规范化因子。计算：

•每千行代码（KLOC）的错误数。

•每KLOC的缺陷数。

・每个LOC的花费成本。

•每KLOC的文档页数

•每人月的错误数。

•每人月的代码行。

•每页文档的成本。

27

可制作一个如下的表:

项目名KLOC工作量成本文档错误缺陷人员

（人月）（万元）页数、

BETA12361015560\85

对该方法的有效性有争议：

支持：易计算，很多软件估算模型以它为关键的输入。

反对：LOC依赖于语言，不适用于非过程化语言，在

分析与设计完成之前难以估算。

28

（2）面向功能的度量

“功能”不能直接测量，利用其他的测量数据间接

地导出。Albrecht提出来的一种称为功能点的度量。用

下表计算5个信息域的值：

信息蜷数计数就加权不因加数权计数

用户输入数X46

用户输出数X57

用户查询数X46

文件数X1015

外部接口数X10

总计数

29

其中：

・用户输入数：每个用户向系统提供的不同应用

的输入数据。、

・用户输出数：系统向每个用户提供的信息，如

报表、屏幕信息、出错信息等。

•用户查询数：每个不同的询问/响应的交互操作。

■文件数：可以是数据库的一部分或是一个

独立的文件。

•外部接口数：与系统中其他设备通过外部接口

读写信息的次数。

“简单、平均、复杂”中的常量值是加权因子，

根据经验确定。

30

利用以下公式计算功能点（FP）：

FP=总计数值X（0.65+0.01X2Fi）

其中Fi（i=l〜14）是回答14个方面问题而得到的复

杂度调整值（值域为0〜5）,如输入、输出、查询及内

部处理复杂吗？代码复用吗？有分布处理吗等等（详见

p64）o

计算出功能点。就可进行以下度量：

■每个功能点的错误数。

■每个功能点的缺陷数。\

•每个功能点的成本。

■每个功能点的文档页数。W

•每人月完成的功能点数。

31

代码行和功能点度量之间的关系依赖于实现软件所

采用的程序设计语言及设计的质量。下面给出了在不同的

程序设计语言中建造一个功能点所需的平均代码行数的统

计：

程序设计语言LOC/FP

汇编语言320

C128

FORTRAN106

Pascal90

C++64

Java46

VisualBASIC32

PowerBuilder16

SQL12

32

3、软件质量度量

软件工程的目标是产生高质量的系统或产品。质量

依赖于描述问题的需求、建模、设计、编码、测试。

质量度量贯穿于软件工程的全过程中以及软件交付用

户使用之后。应评估分析与设计模型、源代码、测试案例

的质量。

33

在软件交付之前得到的度量数据可作为判断设计和

测试质量好坏的依据。这一类度量包括程序复杂性、有

效的模块性和总的程序规模。

在软件交付之后的度量数据则把注意力集中于还未

发现的缺陷数和系统的可维护性方面。

MeCall提出了影响软件质量的11个因素（详见P367）,

其中重要的有以下几点：

・正确性：软件完成所需功能的程度，最常用

“缺陷数/kLoc”来测量。

34

•可维护性：遇到错误时程序能被修改的容易程度、

环境变化时程序能被适应的容易程度、

用户希望改变需求时程序能被增强的容

易程度，一种最简单的测量方法是计算平

均修改时间（MTTC）o

■完整性：测量系统在安全方面的抗攻击性。

完整性=况（1-威胁）X（1-安全性）］

其中威胁是某个特定类型的攻击在给定时

间内发生的可能性。安全性是某个特定类

型的攻击将被击退的可能性。

•可用性：用户友好性。

另外还有可靠性、效率、可测试性、可移植性、可复

田枇笺笺

35

2.4软件项目计划

项目计划既指出了项目组织未来努力的方向和奋斗

目标，又是当前行动的准则。

针对不同工作目标，软件项目计划有：

•项目实施计划（软件开发计划）这是软件开发的

综合性计划，通常应包括任务、进度、人力、环境、资

源、组织等多个方面。

■质量保证计划把软件开发的质量要求具体规定为

每个开发阶段可以检查的质量保证活动。

■软件测试计划规定测试活动的任务、测试方法、

进度、资源、人员职责等。

36

■文档编制计划规定所开发项目应编制的文档种类、

内容、进度、人员职责等。

・用户培训计划规定对用户进行培训的目标、要求、

进度、人员职责等。

■综合支持计划规定软件开发过程中所需要的支持,

以及如何获取和利用这些支持。

■软件发布计划软件开发项目完成后，如何提交给

用户。

这里，主要针对综合计划来介绍。

37

项目管理是一个创造的过程，项目早期的不确定性

因素，使计划不可能在启动阶段就全部一次完成，需逐

步展开和不断修正，这又取决于计划执行情况的反馈与

及时的信息交流。

制订项目基准计划(BaselinePlan)的步骤：

①定义项目目标，确定软件范围

②把项目按项目范围分解为多个任务

③确定对应每个任务必须执行的活动

④将每个任务分配给一个小组，并为每个开堵者

分配角色和职责

⑤用Gantt图或PERT图表示出项目的进度

38

1、软件项目估算

项目计划的一个重要的前提是项目估算(有时在可行

性研究阶段完成)，一般以团队的历史经验为基础，让团

队中的一线人员参与估算，才能保证项目计划的可行性。

成本及工作量的估算不是一门精确的科学，有几种选

•基于已完成的类似项目进行估算；

•使用分解技术以生成项目成本及工作量的估算；

•使用一个或多个经验模型；

(1)分解技术

分解技术采用“分而治之”的策略进行软件项目估算。

将项目分解成若干主要功能及相关的软件过程活动，通

过逐步求精的方式进行成本及工作量估算。具体方法为：

39

划分主要的软件功能，接着估算：

①Loc的数量

②对于FP,估算每个信息域特征（输入、输出、数

据文件、查询、外部接口）及14个复杂度调整值

③实现每个功能所需的人月数

④每个软件过程活动所需人月数

基本的估算方法：

・自顶向下估算：

总成本按阶段、步骤、工作单元

•自底向上估算：

先划分，分别估算每个子任务所需的工作量，

然后士。

40

•差别估算法：

与类似项目比较，估算每个不同之处对成本的影响。

还有专家估算法等等。

（2）经验估算模型

经验估算模型可用于补充分解技术，并提供一种潜在

有价值的估算方法。该模型是基于经验（历史数据）

的，可以用下面的形式表示：

5-f（v（）

其中3是要估算的值（如工作量、成本、项目持砥时

间）之一，％是选择出来的独立参数（如被估算的Loc或

FP）o

41

由经验导出的公式，最著名的是COCOMO模型，构造

型成本模型(ConstructiveCOstMOdel)。初期的模型广

泛的使用于软件成本估算，发展到反映不同阶段的成本。

初始模型的分类：

■基本COCOMO模型

是静态单变量模型，用源代码行数(LOC)为自变量的

经验函数计算软件开发工作量。

•中间COCOMO模型

该模型在用LOC为自变量的函数计算软件开发工作量

的基础上，用涉及产品、硬件、人员、项目等方面的影响

因素调整工作量估算。

•详细COCOMO模型

该模型包括中间COCOMO模型的所有特性，但用上述各

种影响因素调整工作量估算时，还要考虑对软件工程过程

中每一步骤(分析、设计等)的影响。

42

模型的扩展：

COCOCOMII使用对象点、功能点、源代码行作为不同层

次模型的参数。

对象点只是一种间接软件测量数，使用以下计数：

①用户界面上的屏幕数

②报表数

③建立应用软件需要的构件数。

每个对象实例（如一个屏幕或一个报表）给出三个复

杂度权数（简单、中等、复杂），如一个屏幕的权简单为1,

中等为2,复杂为3。

通过以下公式计算总对象点数：

43

S（初始的对象实例数x加权因子）=总的对象点（NOP）

当应用基于构件的开发时，对象点计数调整为：

NOP=NOPX[（100-%复用）/100]

I进而计算：生产率=NOP/人月

针对不同级别的开发者经验和开发环境成熟度，给出

对象点的生产率：

非常低低额定高非常高

47132550

项目工作量=NOP/生产率

44

2、项目进度安排

项目计划中的一个重要内容是建立进度表，该表对项目

进度进行科学度量、调整项目计划起很重要的作用。在众多

软件项目中，缺乏合理的进度安排是造成项目泄后的最主要

原因。进度安排为项目管理者和开发者建立了一张行路图。

(1＞进度安排的指导原则：

•划分：项目分解成若干易于管理的任务。如何进行任务

的分解呢？可从两个方面获得帮助：

①软件开发模型：模型帮助将整个项目进行阶段性的划

分，这些阶段可以做计划中很重要的里程碑。

②软件开发需求：开发模型只给项目计划提供了个框架,

需求的整理与规格化，是细化项目计划的基础。

45

■相互依赖性：各个被划分的活动或任务之间的相互关系必

须是确定的。有些任务必须顺序进行，有些可以并发进行。

•时间分配：必须为每个被调度的任务分配一定数量的工作

单位（如，人天、人月），并指定开始和结束日期。

■工作量确认：每个项目都有预定数量的人员参与。在进行

时间分配时，必须确保在任意时段中分配给任务的人员数

量不会超过项目组中的人员总量。

•定义的责任：每个被调度的任务都应该指定某个特定的小

组成员来负责。

•定义的结果：每个被调度的任务都应该有一个定义好的输

出结果，输出结果通常是一个工作产品或某个工作产品的

一部分。

•定义的里程碑：每个任务或任务组都应该与一个项口里程

碑相关联。当一个或多个工作产品经过质量评审并且得到

认可时，标志着一个里程碑的完成。

46

（2）工作量分配（指导原则）

计划需求分析设计编码测试

2%〜3%10%〜25%20%〜25%15%〜20%30%〜40%

⑶进度表（图）

•甘特图（GanttChart）

也称时间表，所有的项目任务都在左边的栏目中列出。

水平条表示每个任务的持续时间，当同一时间段中存在多

个水平条时，表示任务之间存在并发。

•PERT（ProgramEvaluationReviewTechnique）图

也称任务网络图，表示一个项目的任务流程，刻画了

各项任务、任务之间的依赖关系及任务的持续时间。它的

最简单形式可当作宏观进度表使用。

47

M丽

TaskNstneStertFinishDuratiot)

t13Hfj情n心固N

Taskl2003-12-112003-12-122d

Task22003-12-152003-12-162d>

-

Task32003-12-152003-12-195d*

*

SubTask3.12003-12-152003-12-162d

1

3.2SubTask3.22003-12-172003-12-193d3T

_iL________

Task42003-12-222003-12-232d

Gantt图

Gantt图可清晰的表达每个任务活动的进展以及并发活

动。水平条的颜色既可以表示概要任务和详细任务的分解，

也可以表示任务完成的情况。用一个特定的符号（如黑菱形）

表示一个活动的结束（里程碑），以便检查阶段成果和最后

成果。

48

PERT图

PERT图另一个重要的用途是用来判断关键路径，关键

路径表明了完成该项目可能需要的最小时间，并能识别最

有可能成为瓶颈的活动,该路径上的活动是项目负责人或

小组长抓的主要工作。非关键路径上的活动延迟，不会导

致项目总体进度偏离。下图是一个项目的总的PERT图。

49

测试计划测试过程测试评审

50

说明：

①考虑进度表中的变化:、\

建立进度表时，项目分解为哪些任务以及任务持续的

时间往往根据历史数据估算而来，项目进展过程中未预料

到的事件，如需求的变化或较晚发现的设计缺陷，都会打

乱进度表，因此在进度表中为将来可能的变化留有余地。

②进度表可有不同的抽象层次：

高层进度表反映整个项目的进度，应包括所有可交付

产品的期限，底层进度表是任务和时间的分解。可制作短

期内的进度表，其余部分在项目进行过程中完成。底层进

度表可用于指导每个小组的进度。

③每个里程碑可以附带一个标识进度值的百分比，用来

说明项目完成了多少，如：030%o

51

2.5项目进度的跟踪

r

LJ

项目开展阶段管理活动图（UML活动图）

刘海岩52

1、项目启动进行项目计划

2、项目开展项目的监督与跟踪

(1)收集状况信息的方式

•定期报告：非正式的会议和交流，报告工作产品、

进度误差等需要及早沟通的信息。

•里程碑的监督与验证：里程碑可以是事件，也可以

是工作产品，验证是否在预定时间内完成。

•项目检查：正式会议，所有开发人员交换活动进展

状况，比较各项任务实际开始日期与计划开始日期。

•代码检查：同事之间的正式代码检查。

•原型示范：原型是为了验证需求或为了评估技术和

功能而部分实现的系统，可用来估算初始进度。

53

•度量：主要是修正错误数目的度量，即还需要付出多

少努力的估量。

(2)项目再计划

根据项目的变化动态更新项目计划，应对一些新的

需求、新的变化、突发因素做出响应，或解决问题以适

应计划，或调整计划以保证最后按时交付产品。

(3)风险管理

风险是一些不利因素实际发生的可能性。如：人员

跳槽，管理层变更，硬件缺乏，需求变化，描述延迟，

低估了系统的规模，工具性能差，技术变更，产品竞争

等等。

54

风险管理的活动有

•风险识别：确定风险的类型（管理、技术）。

•风险分析：评估风险出现的可能性及其后果。

•风险规划：制定避免或降低风F寸的枣略。

•风险控制：定期进行风险评估，及时修正缓解风险的

计划。\、

3、项目总结

•用户验收：根据项目协议中规定的验收标准对素统进行

评价，并通过场景演示，测试系统功能性和非功能性需求。

■安装：在目标环境下安装、运行系统并提交文档。

•总结：总结经验教训，建立团队工作效率的历史档案，

以便提高个人和团队整体的软件工程能力。

55

2.6软件质量保证―

1、概述

软件质量是软件产品、体系或过程的一组固有特性满

足(顾客和其他相关方)要求的程度。

软件质量保证(SoftwareQualityAssurance,SQA)是一种

应用于整个软件过程的庇护性活动，包含：

•质量管理方法

•有效的软件工程方法和工具

•过程中采用的正式技术评审

•多层次的测试策略

•对软件文档及其修改的控制

■保证与开发标准符合的规程

•软件度量及报告机制

等等方面的内容

56

软件质量保证的对象一般有三方面：

产品、过程和质量体系

实施软件质量保证需运用几种支持过程作为质

量保证的手段。

■验证或确认：通过提供客观证据对规定要求已

得到满足的认定。\.

•评审或审核：确定主题事项达到规定目标的适

应性、充分性和有效性所进行的活动。联合评审是

由任何两方（评价方和被评价方）用来在适当时机

对项目的某个活动的状态和产品进行评价并可能形

成文件的过程。

57

2、软件质量保证过程中的数据

SQA过程中必然产生有关产品、过程和体系质量的多

种数据，是进行下一步工作的决策依据，对于提高质量管

理效果和改进质量管理过程至关重要。要收集、存储、及

时分析和使用这些数据，才能做好质量保证工作。

质量数据有多种：

•项目规模：FP表示软件大小，以功能点计数；

■工作量E：表示项目的人力总投入，以人月计数；

•生产率：P=FP/E；

•缺陷数：D1表示软件交付前发现的错误数，D2表示交

付后发现的缺陷数；

■质量：Q=D2/FP,表示每个功能点包含多少交付的缺陷,

•缺陷引入率：DI=(D1+D2)/FP,整个项目生存期中每个

功能点发现的缺陷数；

•缺陷排除率：DR=D1/DI

58

3、SQA的实施

(1)SQA小组的职责

SQA活动与两种不同的参与者相关：做开发工作的

软件工程师和独立的SQA小组。

软件开发人员对质量的考虑：采用可靠的技术方法,

进行正式的技术评审，严格的、按计划的测试软件。

SQA小组的职责是辅助开发人员得到高质量的产品,

负责质量保证的计划、监督、记录、分析及报告工作。

(2)SQA过程的进入与退出

•进入准则：

①方针明确■

②能力具备

③项目已定义

④已有SQAP制定规程和偏差处理规程

59

■退出准则：

①产品符合需求

②数据记录完整、受控

•具体活动的输入《施的数据）与输出（产生的结果）：

输入包括合同中的有关说明或协议，软件开发标准和规

范，软件设计准则，软件测试标准或规范，软件配置管理规

范，软件质量保证规范，软件质量数据采集规程等。

输出包括SQAP,项目采用的标准和规程，各种评审和审

核活动的记录和报告、问题报告、问题解决报告和软件质量

有关的数据。

（3）SQA活动流程（见下图）

60

测

量

、

分

析

蛉

证

实

施

SQA活动流程

刘海岩61

需要指出的是，软件测试与软件质量保证是由不同人

员实施的两种不同过程，软件测试是软件开发过程的一个

阶段，而软件质量保证贯穿于整个软件开发过程。

软件开发过程需要多人合作，不按照一定的标准、规

程、准则去做，很难将众多的工作产品集成起来。不把开

发过程分解为可控制的阶段并对每个阶段的工作和结果加

以控制，很难保证产品的质量。

正式技术评审是软件质量保证的主要手段之一，也是

使用最多的监督方法。为了使评审取得应有的效果，注意

-二-占八、、.•

①有计划，■

②有规程，W

③认真执行计划和规程。

62

2.7软件配置管理

1、概念

软件配置管理(SoftwareConfigurationManagement,SCM)

是应用于整个软件过程中的庇护性活动。软件配置是一个

软件产品在生存期各个阶段的不同形式和不同版本的程序、

文档及相关数据的集合。软件开发过程中，会得到许多工

作产品或阶段产品，还会用到许多工具软件，所有这些信

息都需要管理，以便在提出某些特定的要求时能将其进行

约定的组合来满足使用的目的(见下图)。

63

两个产品具有不同的配置

刘海岩64

软件开发属于变化驱动的过程。软件时时处于演化变

更状态。技术的快速发展、业务环境的不断改变、不同用

户的不同需求、需求在开发中的频繁变更、开发人员对阶

段产品的改变等等，都会对产品的最后质量造成影响。

SCM是对软件生存期过程中的各阶段产品和最终产品演

化和变更的管理，是CMM第二级中的关键过程域。它的主

要目的是对变更加以控制，将变更对成本、进度和质量影

响降到最小。

SCM的任务：

•制定SCM计划

•配置标识

•变更控制

•配置审核

■版本管理和发行管理

65

2、软件配置标识

(1)确定配置项(SCI)

大中型软件项目在开发中产生几十个、上百个文档,

每个阶段都在演化，后期版本是对前期的修改及扩展

(两者有继承关系)，确定配置项就是确定哪些文档需

要被保存、被管理。\

(2)配置项标识

•唯一性：在一个项目内不能出现重名，

•可追溯性：名字能体现相邻配置项之间的关系，如

采用层次式命令规则反映树状结构。

66

3、变更管理

(1)软件变更

■软件变更的不可避免性：变更来源于用户或开发人

员；

•变更的复杂性：涉及一些相关部件和文档，需要将某

些变更通知相关人员。

(2)变更管理的任务

•分析变更：研究变更的必要性、经济可行性(成本一

效益比，是否合理)和技术可行性(能否实现)。

•记录和追踪变更。

•采取措施保证变更在受控状态下进行。

67

(3)建立配置项库

♦配置项库的作用

①记录与配置相关的所有信息，其中很重要的内容

是存放受控的软件配置项。

②利用库中的信息评价变更的后果，对变更控制有

重要的意义。

③从库中提取各种配置管理过程的管理信息，可利

用库中的信息查询回答许多配置管理问题，例如：

・哪些客户已提取了某个特定的系统版本？

•运行一个给定的系统版本需要什么硬件和系统软件?

•一个系统到目前已生成了多少个版本，何时生成的?

•如果某一特定的构件变更了，会影响到系统的咖些

版本？

•一个特定的版本曾提出过哪几个变更请求？

•一个特定的版本有多少已报告的错误？

68

♦配置项库的类别

•开发库

存放开发过程中需要保留的各种信息，供开发人员个

人使用，库中的信息无需对其做任何限制，可以有较为频

繁的修改。

・受控库

在软件开发的某个阶段工作结束时，将工作产品或有

关信息存入，应该对库内的信息的读写和修改加以控制。

•产品库

所开发的软件产品完成系统测试后，作为最终产品存

入库内，库内的信息也应加以控制。

受控库和产品库的规范化运行是实现软件配置项管理的

重要手段。

69

(4)建立配置基线(baseline)

基线是软件生存期各开发阶段末尾的特定点，也称

为里程碑。在这些特定点上，阶段工作已结束，并且已经

取得了正式的阶段产品。

建立基线的概念是为了把各开发阶段的工作划分得

更加明确，这样有利于检验和肯定阶段工作的成果。同时

也有利于变更控制。有了基线的规定后，就可以禁止跨越

里程碑去修改另一开发阶段“已冻结”的工作成果。

70

（5）变更请求与变更控制

•变更请求

变更请求是实施变更控制的起始步。最常见的变更理

由可能是清除缺陷、或适应运行平台的变更、或是软件扩

展提出的要求，例如增加功能、提高性能等。

•利用配置库实现变更控制

变更控制过程从变更请求开始，处于开发状态SCI尚

未稳定下来，不受SCM的控制，对SCI的变更不受限制。

但当开发人员认为工作已告完成，可供其他配置项使用时,

配置项进入评审状态，若通过评审作为基线允许进入配置

项库（check-in）,配置项处于受控状态，开发人员不允许

对其做任何修改。

配置项的状态变化见下图。

71

未通过评审

check-out

配置项的状态变化

变更控制过程见下图。

72

变更请求

..4..

授权人决定

请求排入队列尸变更请求谢晓

4

check-out（捡出配置对象）

修改并进行合适的SQA

4

审计变更

check-in（提交配置库）

4

执行下一个变更

;

重建软件版本

执行SQA及测试活动

审计所有的SCI的变更

.，八....,,.......

发布包含变更的新版本

变更控制过程

(6)两个变更控制因素

•访问控制：管理哪个程序员有权访问和修改SCI。

•同步控制：保证两个不同人员完成的并行变更不会

相互覆盖。

访问控制与同步控制流程如下图所示。

74

访问控制和同步控制流程

加锁：使得当前被提取的版本在放回之前别人不能对它

作任何修改（同步控制）。

解锁：在经过SQA和测试后，新的基线对象被解锁并提

交修改后的版本。

75

4、配置审核

配置审核是一个SQA活动人确保SCM的有效性,

不允许出现混乱现象。

如何实施：

(1)实施的时机：

软件产品交付或正式发行前；

开发过程中的阶段工作结束之后；

在维护工作中定期进行。

(2)审核的责任人：软件配置管理员或审核员。

(3)审核工作的开展：

76

■项目经理决定配置审核的时间和范围；

・审核员准备配置审核检查与

・审核员安排时间审核文档和记录，审核活动可能

涉及到：项目范围、评审记录、测试记录、变更请求、

配置项的入库和出库记录、配置项的变更历史、文件的

命名、版本的编号等等；

・审核员发现不符合现象时做出记录；

•项目经理负责消除不符合现象；

・审核员验证所有不符合现象确已得到解决。

77

5、配置状态报告

其任务是有效地记录和报告管理配置所需要的信息，

以便及时、准确地给出软件配置的当前状况，加强SCM工

作。

需要跟踪捕获的状态报告信息有：

SCI的当前标识、已交付软件的配置、变更请求或问

题报告的状态、已获准变更的状态。

软件开发中，存在着“右手不知左手在干什么”。两

个开发者可能以不同的意图去修改同一个SCL配置状态

报告能改善开发人员之间的通信，更好的控制软件版本的

变更。

78

SuccesswithMoneyandJoy

附落人生心语

•成功是一种观念

•致富是一种义务

•快乐是一种权利

•每个人都有能力、有义

务、有权利办到成功

致富快乐

附赠人生心语

成成功不是打败别人

功成功不是超越别人

成功不是名、利、权的获得

致拥有健康的身体

丰足的物质生活

富平衡的心理状态

又才能拥有成功

快SuccesswithMoneyandJoy

战胜自己

乐贡献自己

扮演好自己的历史角色

才能超