软件工程-软件项目管理

软件工程系列文章五

软件项目的成功率非常低的原因可能就是项目管理能力太弱。由于软件本身的特殊性及复杂性，将项目管理思想引入软件工程领域，就形成了软件项目管理

软件项目管理涉及的范围

有效的软件项目管理集中在 4 个 P 上，即人员 (Person) 、产品 (Product) 、过程 (Procedure) 和项目 (Project)

软件项目估算

软件项目估算涉及人、技术、环境等多种因素，因此，需要一些方法和技术来支持项目的估算，常用的估算方法有下列 3 种

1. 基于已经完成的类似项目进行估算
2. 基于分解技术进行估算
3. 基于经验估算模型的估算。典型的有 IBM 估算模型、CoCoMo 模型和 Putnam 模型

上述方法可以组合使用，以提高估算的精度

COCOMO 估算模型

COCOMO 模型是一种精确的、易于使用的成本估算模型。COCOMO 模型按其详细程度分为基本 COCOMO 模型、中级 COCOMO 模型和详细 COCOMO 模型

基本 COCOMO 模型

基本 COCOMO 模型是一个静态单变量模型，用于对整个软件系统进行估算

其公式如下：

E=a(L)^b D=cE^d

其中，E 表示工作量，单位是人月；D 表示开发时间，单位是月；L 是项目的源代码行估计值，不包括程序中的注释及文档，其单位是千行代码；a、b、c、d 是常数

基本 COCOMO 模型可通过估算代码行的值 L，然后计算开发工作量和开发时间的估算值

中级 COCOMO 模型

中间 COCOMO 模型是一个静态多变量模型，它将软件系统模型分为系统和部件两个层次，系统由部件构成，它把软件开发所需的人力 (成本) 看作是程序大小和一系列 “成本驱动属性” 的函数

中级 COCOMO 模型以基本 COCOMO 模型为基础，并考虑了 15 种影响软件工作量的因素，通过工作量调节因子 (EAF) 修正对工作量的估算，从而使估算更合理

其公式如下：

E=a(L)^bEAF

其中，L 是软件产品的目标代码行数，单位是千行代码数；a、b 是常数

详细 COCOMO 模型

它将软件系统模型分为系统、子系统和模块 3 个层次，除包括中级模型所考虑的因素外，还考虑了在需求分析、软件设计等进一步的成本驱动属性的影响

COCOMOII 模型

最初的 COCOMO 模型是得到产业界最广泛应用和讨论的软件成本估算模型之一，现在它已经演化成更全面的估算模型，称为 COCOMOII。和其前身一样，COCOMOII 也是一种层次结构的估算模型，被分为 3 个阶段性模型

1. 应用组装模型。在软件工程的前期阶段使用，这时用户界面的原型开发、对软件和系统交互的考虑、性能的评估以及技术成熟度的评价是最重要的
2. 早期设计阶段模型。在需求已经稳定并且基本的软件体系结构已经建立时使用
3. 体系结构阶段模型。在软件的构造过程中使用

和所有的软件估算模型一样，COCOMOII 模型也需要使用规模估算信息，在模型层次结构中有 3 中不同的规模估算选择：对象点、功能点和代码行。应用组装模型使用的是对象点；早期设计阶段模型使用的是功能点，功能点可以转换为代码行

进度管理

软件项目进度管理的目的是确保软件项目在规定的时间内按期完成

进度管理的基本原则

1. 划分
2. 相互依赖性
3. 时间分配
4. 工作量确认
5. 确定责任
6. 明确输出结果
7. 确定里程碑

进度安排

进度安排的常用图形描述方法有 Gantt 图 (甘特图) 和项目计划评审技术 (Program Evaluation & Review Technique, PERT) 图

Gantt 图

Gantt 图是一种简单的水平条形图，它以日历为基准描述项目任务。水平轴表示日历时间线 (如时、天、周、月和年等) ，每个条形表示一个任务，任务名称垂直地列在左边的列中，图中水平条的起点和终点对应水平轴上的时间，分别表示该任务的开始时间和结束时间，水平条的长度表示完成该任务所持续的时间。当日历中同一时段存在多个水平条时，表示任务之间的并发

Gantt 图能清晰地描述每个任务从何时开始，到何时结束，任务的进展情况以及各个任务之间的并行性。但是它不能清晰地反映出各任务之间的依赖关系，难以确定整个项目的关键所在，也不能反映计划中有潜力的部分

PERT 图

PERT 图是一个有向图，图中的箭头表示任务，它可以标上完成该任务所需的时间。图中的结点表示流入结点的任务的结束，并开始流出结点的任务，这里把结点称为事件。只有当流入该结点的所有任务都结束时，结点所表示的事件才出现，流出结点的任务才可以开始。事件本身不消耗时间和资源，它仅表示某个时间点

一个事件有一个事件号和出现该事件的最早时刻和最迟时刻。最早时刻表示在此时刻之前从该事件出发的任务不可能开始；最迟时刻表示从该事件出发的任务必须在此时刻之前开始，否则整个工程就不能如期完成。每个任务还可以有一个松弛时间 (Slack Time) ，表示在不影响整个工期的前提下完成该任务有多少机动余地

PERT 图不仅给出了每个任务的开始时间、结束时间和完成该任务所需的时间，还给出了任务之间的关系，即哪些任务完成后才能开始另外一些任务，以及如期完成整个工程的关键路径。图中的松弛时间 (最迟时刻 - 最早时刻) 则反应了完成某些任务时可以推迟其开始时间或延长其所需完成的时间。但是，PERT 图不能反映任务之间的并行关系

软件配置管理

软件配置管理其主要目标包括： 变更标识、变更控制、版本控制、确保变更正确的实现、变更报告

软件配置管理其主要内容包括：版本管理、配置支持、变更支持、过程支持、团队支持、变化报告、审计支持

或者：软件配置标识、变更管理、版本控制、系统建立、配置审核、配置状态报告

配置数据库可以分为以下三类：

1. 开发库。专供开发人员使用，其中的信息可能做频繁修改，对其控制相对宽松
2. 受控库。在生存期某一阶段工作结束时发布的阶段产品，这些是与软件开发工作相关的计算机可读信息和人工可读信息。软件配置管理正是对受控库中的各个软件项进行管理，受控库也称为软件配置库
3. 产品库。在开发的软件产品完成系统测试后，作为最终产品存入产品库，等待交付用户或现场安装

风险管理

一般认为软件风险包含两个特性：不确定性和损失。不确定性是指风险可能发生也可能不发生；损失是指如果风险发生，就会产生恶性后果。在进行风险分析时，重要的是量化每个风险的不确定程度和损失程度。为了实现这一点，必须考虑不同类型的风险

项目风险威胁到项目计划。也就是说，如果项目风险发生，就有可能拖延项目的进度和增加项目成本。项目风险是指预算、进度、人员 (聘用职员及组织) 、资源、利益相关者、需求等方面的潜在问题以及它们对软件项目的影响。项目复杂度、规模及结构不确定性也属于项目风险因素

技术风险威胁到要开发软件的质量及交付时间。如果技术风险发生，开发工作就可能变得很困难或根本不可能，技术风险是指设计、实现、接口、验证和维护等方面的潜在问题。此外，规格说明的歧义性、技术的不确定性、技术陈旧以及 “前沿” 技术也是技术风险因素。技术风险地发生是因为问题比我们所设想地更加难以解决

商业风险威胁到要开发软件地生存能力，且常常会危害到项目或产品。5 个主要的商业风险如下：

1. 市场风险。开发了一个没有人真正需要的优良产品
2. 策略风险。开发的产品不再符合公司的整体商业策略
3. 销售风险。开发了一个销售部门不知道如何去销售的产品
4. 管理风险。由于重点的转移或人员的变动而失去了高级管理层的支持
5. 预算风险。没有得到预算或人员的保证

(一) 风险识别

风险识别试图系统化地指出对项目计划 (估算、进度、资源分配等) 地威胁。识别出已知风险和可预测风险后，项目管理者首先要做的是在可能时回避这些风险，在必要时控制这些风险

识别风险的一种方法是建立风险条目检查表。该检查表可用于风险识别，并且主要用来识别下列几种类型中的一些已知风险和可预测风险

1. 产品规模。与要开发或要修改的软件的总体规模相关的风险
2. 商业影响。与管理者或市场所施加的约束相关的风险
3. 客户特性。与客户的素质以及开发者和客户定期沟通的能力相关的风险
4. 过程定义。与软件过程定义的程度以及该过程被开发组织遵守的程度相关的风险
5. 开发环境。与用来开发产品的工具的可得性及质量相关的风险
6. 开发技术。与待开发软件的复杂性及系统所包含技术的 “新奇性” 相关的风险
7. 人员才干及经验。与软件工程师的总体技术水平及项目经验相关的风险

风险条目检查表可以采用不同的方式来组织。与上述每个主题相关的问题可以针对每一个软件项目来回答。根据这些问题的答案，项目管理者就可以估计风险产生的影响

当然，也可以采用另一种风险条目检查表格式，即仅仅列出与每一种类型有关的特性，最终给出一组风险因素和驱动因子以及它们发生的概率。风险因素包括性能、成本、支持和进度。风险因素是以如下方式定义的：

1. 性能风险。产品能够满足需求且符合其使用目的的不确定程度
2. 成本风险。能够维持项目预算的不确定程度
3. 支持风险。开发出的软件易于纠错、修改及升级的不确定程度
4. 进度风险。能够维持项目进度且按时交付产品的不确定程度

(二) 风险预测

风险预测又称风险估计，它试图从两个方面评估一个风险：风险发生的可能性或概率；如果风险发生了所产生的后果

(1) 风险预测活动

通常，项目计划人员与管理人员、技术人员一起进行以下 4 步风险预测活动

1. 建立一个尺度或标准，以反映风险发生的可能性
2. 描述风险产生的后果
3. 估算风险对项目和产品的影响
4. 标注风险预测的整体精确度，以免产生误解

一种简单的风险预测技术是建立风险表。风险表的第 1 列列出所有的风险 (由风险识别活动得到) ，第 2-4 列列出每个风险的种类、发生的概率以及所产生的影响。风险所产生的影响可用一个数字来表示：”1” 表示灾难性的；”2” 表示严重的；”3” 表示轻微的；”4” 表示可忽略的

(2) 评估风险影响

如果风险真的发生，有 3 个因素可能会影响风险所产生的后果，即风险的本质、范围和时间。风险的本质是指当风险发生时可能会带来的问题。例如，一个定义很差的与客户硬件的外部接口 (技术风险) 会妨碍早期的设计和测试，也有可能导致项目后期阶段的系统集成问题。风险的范围包括风险的严重性 (即风险有多严重) 及风险的整体分布情况 (即项目中有多少部分受到影响或有多少客户受到损害) 。风险的时间是指何时能够感受到风险的影响及风险的影响会持续多长时间。在大多数情况下，项目管理者希望 “坏消息” 越早出现越好，但在某些情况下则是越迟越好

整体的风险显露度 (Risk Exposure, RE) 可由下面的关系确定：

RE=P×C

其中，P 是风险发生的概率，C 是风险发生时带来的项目成本

(三) 风险评估

在进行风险评估时，建立了如下形式的三元组：

(R_i, l_i, x_i)

其中，r_i 表示风险，l_i 表示风险发生的概率，x_i 表示风险产生的影响

一种对风险评估很有用的技术就是定义风险参考水准。对于大多数软件项目来说，成本、进度和性能就是 3 种典型的风险参照水准。也就是说，对于成本超支、进度延期、性能降低 (或它们的某种组合) ，有一个表明导致项目终止的水准

在风险评估过程中，需要执行以下 4 个步骤

1. 定义项目的风险参考水平值
2. 建立每一组 (R_i, l_i, x_i) 与每一个参考水平值之间的关系
3. 预测一组临界点以定义项目终止区域，该区域由一条曲线或不确定区域所界定
4. 预测什么样的风险组合会影响参考水平值

(四) 风险控制

风险控制的目的是辅助项目组建立处理风险的策略。一个有效的策略必须考虑以下 3 个问题

(1) 风险避免

应对风险的最好方法是主动地避免风险，即在风险发生前分析引起风险的原因，然后采取措施，以避免风险的发生

例如项目风险 r_i 表示 “频繁的人员流动”，根据历史经验可知，该风险发生的概率 l_i 大约为 70%，该风险产生的影响 x_i 是第 2 级 (严重的) 。为了避免该风险，可以采取以下策略

1. 与现有人员一起探讨人员流动原因 (如恶劣的工作条件、低报酬、竞争激烈的劳动力市场等)
2. 在项目开始之前采取行动，设法缓解那些能够控制的起因
3. 项目启动之后，假设会发生人员流动，当有人员离开时，找到能够保证工作连续性的方法
4. 组织项目团队，使得每一个开发活动的信息都能被广泛传播和交流
5. 制定工作产品标准，并建立相应机制以确保能够及时创建所有的模型和文档
6. 同等对待所有工作的评审
7. 给每一个关键的技术人员都指定一个后背人员

(2) 风险监控

项目管理者应监控某些因素，这些因素可以提供风险是否正在变高或变低的指示。在频繁的人员流动的例子中，应该监测团队成员对项目压力的普遍态度、团队的凝聚力、团队成员彼此之间的关系、与报酬和利益相关的潜在问题、在公司内及公司外工作的可能性

(3) RMMM 计划

风险管理策略可以包含在软件项目计划中，或者风险管理步骤也可以组织成一个独立的风险缓解、监控和管理计划 (RMMM 计划) 。RMMM 计划将所有风险分析工作文档化，并由项目管理者作为整个项目计划中的一部分来使用

建立了 RMMM 计划，而且项目已经启动之后，风险缓解及检测步骤也就开始了。风险缓解是一种问题规避活动，而风险检测是一种项目跟踪活动，这种监测活动有 3 个主要目的；评估所预测的风险是否真的发生了；保证正确地实施了个风险的缓解步骤；收集能够用于今后风险缝隙的信息。在很多情况下，项目中发生的问题可以追溯到不止一个风险，所以风险监测的另一个任务就是试图找到 “起源” (在整个项目中是哪些风险引起了哪些问题)