• 软件项目管理概述• 软件度量• 软件项目估算• 风险分析• 进度安排• 软件项目的组织

• 软件项目管理概述• 软件度量• 软件项目估算• 风险分析• 进度安排• 软件项目的组织

软件项目管理概述 软件项目管理是指软件生存周期中软件管理者所进行的一系列活动，其目的是在一定的时间和预算范围内，有效地利用人力、资源、技术和工具，使软件系统或软件产品按原定的计划和质量要求如期完成。

有效的项目管理集中在四个 P 上：• People 人员：人员管理上达到较高成熟度的组织更有可能实现有效的软件工程实践

• Product 产品：进行项目计划前应首先建立产品的目的和范围，考虑可选的解决方案，标识技术和管理的约束

• Process 过程：软件过程提供了一个框架，在这个框架下可以建立一个软件开发的全面计划。若干不同的任务集合（由任务、里程碑、工作产品和质量保证点组成）使框架活动能被修改，以适应不同软件项目的特征和项目组的需求

• Project 项目：进行有计划和可控制的软件项目，为避免项目失败，应避免常见的导致失败的警示，了解关键的导致好的项目管理的成功因素，使用好的用于计划和监控项目的方法

项目管理过程• 软件项目管理的对象是软件工程项目。它所涉及的范围覆盖了整个软件工程过程。

• 为使软件项目开发获得成功，关键问题是必须对软件项目的工作范围、可能风险、需要资源 ( 人、硬件／软件 ) 、要实现的任务、经历的里程碑、花费工作量 ( 成本 ) 、进度安排等做到心中有数。

• 软件项目管理可以提供这些信息。

• 这种管理在技术工作开始之前就应开始，在软件从概念到实现的过程中继续进行，当软件工程过程最后结束时才终止。

软件项目管理的主要活动• 启动软件项目• 软件度量• 软件项目估算• 风险分析• 进度安排• 项目组织• 软件配置管理

启动一个软件项目• 在制定软件项目计划之前，必须

明确项目的目标和范围 考虑候选的解决方案 标明技术和管理上的要求

• 有了这些信息，才能确定合理、精确的成本估算，实际可行的任务分解以及可管理的进度安排。

• 软件人员和用户是在系统工程步骤中确定项目的目标和范围。

• 目标标明了软件项目的目的但不涉及如何去达到这些目的。

• 范围标明了软件要实现的基本功能，并尽量以定量的方式界定这些功能。

• 当明确了软件项目的目标和范围后，就应考虑候选的解决方案。

• 有了方案，管理人员和技术人员就能够据此选择一种“好的”方法，给出诸如交付期限、预算、个人能力、技术界面及其它许多因素所构成的限制。

度量• 进行度量工作，是为了了解产品开发的技术过程和产品本身。 度量开发过程的目的是为了改进过程，

度量产品的目的是为了提高产品的质量。

• 度量的作用是为了有效地定量地进行管理。

• 为有效地度量，常常需要考虑：对于过程和产品， 合适的度量是什么？ 所收集的数据如何使用？ 用于比较个人、过程或产品的度量是否合理？

• 管理人员和技术人员可利用这些度量来了解软件工程过程的实际情况和它所生产的产品质量 。

估算• 在软件项目管理过程中关键的活动就是制定项目计划。

• 在做计划时必须就需要的人力（以人月为单位）、项目持续时间（以年份或月份为单位）、成本（以元为单位）做出估算。

• 这种估算大多是利用以前的花费作为参考而做出的。

• 如果新项目与以前的一个项目在规模上和功能上十分类似，则新项目需要的工作量、开发持续时间和成本大致与那个老项目相同。

• 假使项目背景完全生疏，只凭过去的经验做出估算可能就不够了。

• 现在已有了许多用于软件开发的估算技术。其共同特点是：

事先建立软件范围 以软件度量（以往的度量）为基础，以做出估算

项目被分解为可单独进行估算的小块

• 管理人员大多使用不止一种估算技术，并用一种估算技术作为另一种估算技术的交叉检查。

风险分析• 每当新建一个程序时，总是存在某些不确定性 用户要求是否能确切地被理解？ 在项目最后结束之前要求实现的功能能否建立？

是否存在目前仍未发现的技术难题？ 在项目出现严重误期时是否会发生某些变更？等等。

• 风险分析对于软件项目管理是决定性的，然而现在还有许多项目不考虑风险就着手进行。

• 所谓风险分析实际上就是一系列风险管理步骤，主要包括风险识别、风险估算、风险评价、风险管理和控制。这些步骤贯穿在软件工程过程中。

进度安排• 每一个软件项目都要求制定一个进度安排，但不是所有的进度都得一样安排。

• 指导进度安排的原则： 划分：项目必须被划分成若干可以管理的活动和任务

相互依赖性：必须确定活动或任务之间的相互关系

时间分配：必须为每个任务分配一定数量的工作时间，指定开始和结束日期

工作量确认：必须确保在任何时段中分配给任务的人员数不超过项目组的人员数

定义的责任：每个任务都应指定某个特定的小组成员来负责

定义的结果：每个任务都应有一个定义好的输出结果，软件项目的输出结果通常是一个工作产品（如一个模块的设计）或某个工作产品的一部分，通常将多个工作产品组合成“可交付产品”

定义的里程碑（ milestones ）：每个任务或任务组都应该与一个项目里程碑相关联。当一个或多个工作产品经过质量评审并得到认可时，标志着一个里程碑的完成

追踪和控制• 一旦建立了开发进度安排，就可以开始着手追踪和控制活动。

• 由项目管理人员负责追踪在进度安排中标明的每一个任务。

• 如果任务实际完成日期滞后于进度安排，则管理人员应确定在项目的中间里程碑上进度误期所造成的影响，并采取补救措施。

• 还可对资源重新分配• 对任务重新安排• （作为最坏的结果）可以修改交付日期以调整已经暴露的问题。用这种方式可以较好地控制软件的开发。

• 软件项目管理概述• 软件度量• 软件项目估算• 风险分析• 进度安排• 软件项目的组织

软件度量•软件生产率和质量度量•软件质量模型•软件复杂性度量•软件可靠性度量

软件度量•软件生产率和质量度量•软件质量模型•软件复杂性度量•软件可靠性度量

软件度量 --- 术语ISO/IEC 9126-1 Software engineering —product quality

Part 1: Quality model

• Metric 度量 The defined measurement method and the

measurement scale.• Measure(verb) 测量 Make a measurement.• Measure(noun) 测度 The number or category assigned to attribute

of an entity by making a measurement• Measurement 测量 The use of a metric to assign a value(which

may be a number or category)from a scale to an attribute of an entity.

• Metric 度量 定义测量方法和测量标度 标度指具有特性定义的一组值。如，一组类别，一组有序刻度的序数，一组等距的有序刻度

• Measure(verb) 测量 执行一次测量• Measure(noun) 测度 通过执行一次测量赋予实体属性的数字或类别• Measurement 测量 使用一种度量把标度值（可以是数字或类别）赋予实体的某个属性

• 直接测量（ direct measure ）： 一种不依赖于任何其它属性的测量的属性测量

• 间接测量（ indirect measure ）： 一种从一个或多个其它属性的测量导出的属性测量

• 内部测量（ internal measure ）： 一种对产品本身的直接或间接的测量• 外部测量（ external measure ）： 一种通过对系统行为的测量导出对产品（作为系统的一部分）的间接测量

软件度量分类

• 软件生产率度量主要集中在软件工程过程的输出

• 软件质量度量可指明了软件满足明确的和隐含的用户需求的程度

• 技术度量主要集中在软件的某些特性（如逻辑复杂性、模块化程度）上，而不是软件开发的全过程

• 面向规模的度量用于收集与直接度量有关的软件工程输出的信息和质量信息。

• 面向功能的度量的注意力集中在程序的“功能性”和“实用性”。

• 面向人的度量则收集有关人们开发计算机软件所用方式的信息和人们理解有关工具和方法的效率的信息。

面向规模的度量• 代码行数（ lines of code， LOC，KLOC 为千行代码数）：直接度量

• 生产率： P = LOC / E （其中 E 为开发工作量）

• 每行代码的平均成本： C = S / LOC

（其中 S 为总成本）• 文档与代码比： D = Pe / KLOC

（其中 Pe为文档页数）• 代码错误率： EQR = N / KLOC

（其中 N 为代码中的错误数）

• 需要注意的是，工作量和成本是指整个软件工程活动（分析、设计、编码和测试）的工作量和成本，而不仅仅指编码活动。

• 面向规模的度量是对软件和软件开发过程的直接度量。

• 可以建立一个面向规模的数据表格来记录与项目有关的面向规模的数据。

面向规模的数据表格

• 项目 aaa-01 规模为 12.1 KLOC （千代码行） 工作量用了 24 个人月 成本为 168,000元 文档页数为 365 在交付用户使用后第一年内发现了

29 个错误， 有 3 个人参加了项目 aaa-01 的软件开发工作

•根据表中列出的数据可计算以下简单的面向规模度量：

生产率： LOC／ PM （人月）质量： 错误数／ KLOC

成本： 投入的资金／ LOC

文档： 文档页数／ KLOC

其中 LOC 为代码行数， KLOC 为千行代码数， PM 为开发的人月数

面向功能的度量• 面向功能的软件度量是对软件和软件开发过程的间接度量。

• 面向功能度量主要考虑程序的“功能性”和“实用性”，而不是对 LOC计数。

• 该度量是一种称为“功能点”的生产率度量方法，该方法利用软件信息域中的一些计数和软件复杂性估计的经验关系式而导出功能点 （ function point， FP ）

面向功能的数据表格

• 功能点计算 确定五个信息域的特征，并在表格中相应位置给出计数。 (1) 用户输入数：计数每个用户输入，它们向软件提供不同的面向应用的数据。(2) 用户输出数：计数每个用户输出，它们向用户提供面向应用的信息。这里的输出是指报表、屏幕信息，出错消息等。报表中的单个数据项不单独计数。

(3) 用户查询数：查询是一种联机的交互操作，每个不同的查询都应计数。

(4) 文件数：每一个逻辑主文件都应计数。逻辑主文件是指数据的一个逻辑组合，它可能是某个大数据库的一部分，或是一个独立的文件。(5) 外部接口数：计数所有机器可读的接口（如存储介质上的数据文件），利用这些接口可以将信息从一个系统传送到另一个系统。

• 一个信息域是简单的、平均的还是复杂的，由使用功能点方法的机构自行确定，从而计算出每个信息域的加权计数和总计数。

• 使用如下的关系式计算功能点：FP ＝ 总计数 ×( 0.65＋ 0.01×SUM ( Fi ) )

其中： Fi（ i＝ 1..14 ）是复杂性校正值，它们通过逐一回答如下提问来确定，其取值范围是 0..5 ：

0 没有影响 1 偶然的2 适中的 3 普通的4 重要的 5 极重要

的SUM（ Fi ）是求和函数

• 复杂性校正值 Fi1. 系统是否需要可靠的备份和恢复？2. 是否需要数据通信？3. 是否有分布处理的功能？4. 性能是否关键？5. 系统是否运行在现存的高度实用化的操作环境中？

6. 系统是否需要联机数据项？

7. 联机数据项是否需要在多窗口或多操作之间切换以完成输入？

8. 主文件是否需要联机更新？9. 输入、输出、文件、查询是否复杂？10. 内部处理过程是否复杂？11. 程序代码是否需要设计成可复用的？12. 设计中是否包括了转换和安装？13. 系统是否设计成可以重复安装在不同机构中？

14. 应用是否被设计成易修改和易使用？

• 一旦计算出功能点，就可计算面向功能度量：

生产率： FP／ PM （人月）质量： 错误数／ FP

成本： 投入的资金／ FP

文档： 文档页数／ FP

• 功能点度量最初主要用于商用信息系统应用。

•扩展的功能点度量，也称特征点（ Feature Points ）度量可以用于系统和工程软件应用

• 特征点度量适合于算法复杂性高的应用。而实时处理、过程控制、嵌入式软件应用的算法复杂性都偏高，因此适合于特征点度量。

• 为了计算特征点，可以象功能点计算那样，对信息域值进行计数和加权。此外，特征点度量要对一个新的软件特征“算法”进行计数。

• 计算特征点可使用一个计算表格。 对于每一个度量参数只使用一个权值，并且使用

FP＝总计数 ×( 0.65＋ 0.01×SUM ( Fi ) )

来计算总的特征点值。

特征点度量计算表格

软件度量•软件生产率和质量度量•软件质量模型•软件复杂性度量•软件可靠性度量

McCall模型•三层式模型框架（质量要素，评价准则，度量），质量要素（特性 )反映了软件的质量，软件属性可用作评价准则，定量地度量软件属性可知软件质量的优劣

• 其质量概念基于 11 个质量要素上，它们分别面向软件产品的运行、修正和转移

• 定义了 21 个评价准则（见 P37 ），可通过评价准则间接度量软件质量要素

软件质量模型

• 软件质量要素的计算

其中： Fj表示质量特性， Cjk是加权系数， Mk

是 Fj对第 K 个评价准则的测量值• 评价准则分为 0~10级， 0 为最低， 10 为最高

• 加权系数 Cjk 0 ，若 Fj与第 K 个评价准则无关，则 Cjk = 0 ，并满足条件

11...2,1j

MCF21

1kkjkj

21

11

kjkC

• 质量要素之间的关系

• 质量要素与评价准则之间的关系

Boehm模型

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

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

ISO/IEC 9126 质量模型

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

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

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

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

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

软件度量•软件生产率和质量度量•软件质量模型•软件复杂性度量•软件可靠性度量

• 软件复杂性指理解和处理软件的难易程度

• 软件的复杂性主要体现在程序的复杂性• 典型的程序复杂性度量方法有

• McCabe环形复杂性度量• Halstead 的复杂性度量

程序复杂性度量

K.Magel 从六个方面描述程序复杂性• 理解程序的难度• 纠错、维护程序的难度• 向他人解释程序的难度• 按制定方法修改程序的难度• 根据设计文档编写程序的工作量• 执行程序时需要资源的程度

程序复杂性度量模型应遵循的基本原则• 软件复杂性与程序大小的关系不是线性的

• 控制结构复杂的程序较复杂• 数据结构复杂的程序较复杂• 转向语句使用不当的程序较复杂• 循环结构比选择结构复杂，选择结构比顺序结构复杂

• 非局部变量较多时程序较复杂• 参数按地址调用（ call by reference ）比按值调用（ call by value ）复杂

• 函数副作用比显式参数传递难以理解• 具有不同作用的变量共用一个名字时较难理解

• 模块间、过程间联系密切的程序较复杂• 嵌套深度越深程序越复杂

• 它是基于程序控制结构的程序复杂性度量，基于强连通图的理论

• 用程序图（退化的程序流程图）中的环路数表示程序的复杂性

• 程序图：把程序流程图中的每个处理符号退化成一个结点，连接不同处理符号的流线变成连接不同结点的有向弧

McCabe环形复杂性度量

有向图 G 中环的个数为 V(G) = e – n + p

其中： e是 G 中的弧数， n是 G 中的结点数， p是 G 中强连通分量的个数。对一个仅由单入口和单出口的模块， p = 1 。但程序模块通常不是强连通的，可以从出口结点到入口结点加一条有向弧，使其变成强连通。此时计算程序图中环数可用下式 V(G) = e – n + 2

见 P40图 2.7

• Halstead认为程序是由操作符和操作数组成的符号序列

• 操作符包括算术运算符、逻辑运算符、赋值符、分界符、括号、子程序调用符等，还包括“ begin ene” 、“ for do” 、“ repeat until” 、“ while do” 、“ if then else” 等，它们都看作单个运算符。

• 操作数指操作对象，包括变量、常量、数组、记录、指针等

Halstead复杂性度量

设： n1为程序中不同操作符的个数 n2为程序中不同操作数的个数 N1为程序中操作符的总数 N2为程序中操作数的总数•程序的符号长度： N = N1 + N2

•程序的词汇量： n = n1 + n2

•程序量： V = (N1 + N2 ) log 2 ( n1 + n2 )

•最小程序量： V* = (2 + n2* ) log 2 ( 2 + n2* )

•预测程序长度： N’ = n1 log 2 n1 + n2 log 2 n2

•预测程序的潜在错误： B’ = V / 3000

软件度量•软件生产率和质量度量•软件质量模型•软件复杂性度量•软件可靠性度量

• 软件可靠性（ reliability ）指在特定环境和特定时间间隔内，程序按照规格说明的要求无故障（不失效）地运行的概率

• 排除软件代码中的错误称为修复• 软件修复（ repair ）包括发现故障、纠正错误、测试和系统重新启动四个步骤

• 修复工作能提高系统的可靠性• 软件有效性（ availability ，也称可用性）指在某个给定的时间点上，程序能无故障（不失效）运行的概率

软件可靠性度量

• 可靠性的简单度量是平均故障（失效）间隔时间 MTBF（mean time between failure ）

MTBF = MTTF + MTTR

平均故障时间 MTTF: mean time to failure

平均修复时间 MTTR: mean time to repair

• 有效性度量 MTTF / （MTTF + MTTR ） * 100%

• 软件项目管理概述• 软件度量• 软件项目估算• 风险分析• 进度安排• 软件项目的组织

软件项目估算（ eatimation ）• 估算指对软件产品、过程、资源进行预测• 在软件项目管理过程中关键的活动就是制定项目计划。

• 在做计划时首先必须就需要的人力（以人月为单位）、项目持续时间（以年或月为单位）、成本（以元为单位）做出估算。

• 这种估算大多是参考以前的花费而做出的。• 如果新项目与以前的某个项目在规模和功能上十分类似，则开发新项目所需的工作量、持续时间、成本大致与那个老项目相同。

• 常用的估算手段： 1. 参照已完成的类似项目 2. 先估算子项目，再估算整个项目 3. 分别对软件生存周期各阶段进行估算，再汇总

4. 使用经验公式估算• 软件规模是影响软件成本和工作量的重要因素

•代码行和功能点直接反映了软件规模

•代码行、功能点估算1. 请若干名有经验的技术人员，每人对软件的规模（代码行或功能点）给出三个估计值：最少值 a i 、最大值 b i 、最有可能的值m i

2. 计算出平均值 a、 b、m3. 加权平均计算出软件规模估算值 （ a+4m+b） / 6

• 根据以往软件开发的平均生产率（规模 / 人月数） 和平均成本（资金 / 规模）计算工作量估算值和成本估算值

工作量估算值 = 规模估算值 / 平均生产率

成本估算值 = 规模估算值 * 平均成本

• 实例：考察一个为 CAD 应用而开发的软件包。（见 P29例 2.2 ）

• 系统定义指明，软件是在一个工作站上运行，其接口需使用各种计算机图形设备，包括鼠标器、数字化仪、高分辩率彩色显示器和激光打印机。

• 在这个实例中，使用 LOC 做为估算变量。

•根据系统规格说明 , 软件范围的初步叙述如下：

“软件将从操作员那里接收 2维或 3维几何数据。 操作员通过用户界面与 CAD 系统交互并控制它，这种用户界面将表现出很好的人机接口设计特性。所有的几何数据和其它支持信息保存在一个 CAD 数据库内。要开发一些设计分析模块以产生在各种图形设备上显示的输出。软件要设计得能控制并能与各种外部设备（包括鼠标器、数字化仪、激光打印机和绘图仪）交互。”

• 经过分解 , 识别出下列主要软件功能： 用户界面和控制 二维几何分析 三维几何分析 数据库管理 计算机图形显示 外设控制 设计分析

•通过分解，可得到如下估算表

估算表

经典的估算模型• 软件开发成本估算是依据开发成本估算模型进行估算的。

• 开发成本估算模型通常采用经验公式来预测软件项目计划所需要的成本、工作量和进度数据。

• 用以支持大多数模型的经验数据都是从有限的一些项目样本中得到的。

IBM 估算模型 E ＝ 5.2×L0.91

D ＝ 4.1×L0.36 ＝ 14.47×E0.35

S ＝ 0.54×E0.6

DOC ＝ 49×L1.01

其中： L 是源代码行数 (KLOC)， E 是工作量 (PM)， D 是项目持续时间 (月 )，S 是人员需要量 (人 )， DOC 是文档数量 (页 ) 。

• IBM模型是静态单变量模型。• 在此模型中，一般指一条机器指令为一行源代码。

• 一个软件的源代码行数不包括程序注释、作业命令、调试程序在内。

• 对于非机器指令编写的源程序，例如汇编语言或高级语言程序，应转换成机器指令源代码行数来考虑。

转换系数表

语语 言言 转转换换系系数数 简简单单汇汇编编 11

宏宏 汇汇 编编 11..22～～11..55 FFOORRTTRRAANN 44 ～～ 66 PPLL//II 44 ～～ 1100

定义定义 : : 转换系数＝机器指令条数／非转换系数＝机器指令条数／非机器语言执行步数。机器语言执行步数。

COCOMO模型 （ COnstructive COst MOdel ）

• 构造性成本估算模型是一种精确、易于使用的成本估算方法。

• DSI （源指令条数）定义为代码的源程序行数。若一行有两个语句，则算做一条指令。它包括作业控制语句和格式语句，但不包括注释语句。 KDSI＝ 1000DSI 。

• MM （度量单位为人月）表示开发工作量。

• TDEV （度量单位为月）表示开发进度。它由工作量决定。

• 软件开发项目的分类软件开发项目的总体类型 : 组织型（ organic ） 嵌入型（ embedded ） 半独立型（ semidetached ）

• 组织型：相对较小、较简单的软件项目，对需求不苛刻，开发人员对开发目标理解充分，相关的工作经验丰富，对使用环境熟悉，受硬件约束较少，程序规模不大（ < 5万行）。如多数应用软件、早期的操作系统和编译程序等。

• 嵌入型：软件在紧密联系的硬件、其它软件和操作的限制条件下运行，通常与硬件设备紧密结合在一起，对接口、数据结构、算法要求较高，软件规模任意。如，大而复杂的事务处理系统、大型 /超大型操作系统、航天用控制系统、大型指挥系统等。

• 半独立型：介于组织型和嵌入型之间，软件规模和复杂性属中等以上，最大可达 30万行。如多数事务处理系统、操作系统、数据库管理系统、大型库存 / 生产控制系统、简单的指挥系统等。

• COCOMO模型的分类COCOMO模型按其详细程度分成三级： 基本 COCOMO模型 中间 COCOMO模型 详细 COCOMO模型

• 基本 COCOMO模型是静态单变量模型，用源代码行数 (LOC) 为自变量的经验函数计算软件开发工作量。

• 中间 COCOMO模型在用 LOC 为自变量的函数计算软件开发工作量（称为名义工作量）的基础上，用涉及产品、硬件、人员、项目等方面的影响因素调整工作量估算。

• 详细 COCOMO模型包括中间 CO COMO模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中每一步骤（分析、设计等）的影响。

基本 COCOMO模型• 基本 COCOMO模型的工作量和进度公式

总体类型 工 作 量 进 度 组织型 MM＝

= 2.4（KDSI）1.05 TDEV＝ = 2.5（MM）0.38

半独立 型

MM＝ = 3.0（KDSI）1.12

TDEV＝ = 2.5（MM）0.35

嵌入型 MM＝ = 3.6（KDSI）1.20

TDEV＝ = 2.5（MM）0.32

中间 COCOMO模型• 进一步考虑 15 种影响软件工作量的因素，通过定下乘法因子，修正 COCOMO 工作量公式和进度公式，可以更合理地估算软件（各阶段）的工作量和进度。

• 中间 COCOMO模型的名义工作量与进度公式如下所示。

总体类型 工 作 量 进 度 组织型 MM＝

= 3.2（KDSI）1.05 TDEV＝ = 2.5（MM）0.38

半独立 型

MM＝ = 3.0（KDSI）1.12

TDEV＝ = 2.5（MM）0.35

嵌入型 MM＝ = 2.8（KDSI）1.20

TDEV＝ = 2.5（MM）0.32

中间 COCOMO模型的名义工作量与进度公式

15 种影响软件工作量的因素 Fi

• 产品因素：软件可靠性、数据库规模、产品复杂性

• 硬件因素：执行时间限制、存储限制、虚拟机易变性、环境周转时间

• 人的因素：分析员能力、应用领域实际经验、程序员能力、虚拟机使用经验、程序语言使用经验

• 项目因素：现代程序设计技术、软件工具的使用、开发进度限制

• 此时，工作量计算公式改成

• 例 . 一个 32KDSI 的声音输入系统是一个输入原型，或是一个可行性表演模型。所需可靠性非常低。把此模型看做半独立型软件。则有 MM ＝ 3.0（ 32） 1.12 ＝ 146又查表知 f1＝ 0.75 ，其它 fi＝ 1.00 ，则最终有 MM ＝ 146×0.75 ＝ 110.

15

1i

c fi(KDEV)rMM

• 例 . 一个规模为 10KDSI 的商用微机远程通信的嵌入型软件，使用中间COCOMO模型进行成本估算。

• 程序名义工作量 MM ＝ 2.8 (10)1.20 ＝ 44.38（MM ）• 程序实际工作量 MM ＝ 44.38×

＝ 44.38×1.17 ＝ 51.5（MM ）

15

1i

fi

影响工作量因素 fi 情 况 取 值 1 软件可靠性 只用于局部地区，恢

复问题不严重 1.00（正常）

2 数据库规模 20000字节 0.94（低） 3 产品复杂性 用于远程通信处理 1.30（很高） 4 时间限制 使用70%的CPU时间 1.10（高） 5 存储限制 64K中使用45K 1.06（高） 6 机器 使用商用微处理机 1.00（额定值） 7 周转时间 平均2小时 1.00（额定值） 8 分析员能力 优秀人才 0.86（高） 9 工作经验 远程通信工作3年 1.10（低）10 程序员能力 优秀人才 0.86（高）11 工作经验 微型机工作6个月 1.00（正常）12 语言使用经验 12个月 1.00（正常）13 使用现代程序设计技术 1年以上 0.91（高）14 使用软件工具 基本的微型机软件 1.10（低）15 工期 9个月 1.00（正常）

• 开发所用时间 TDEV ＝ 2.5 (51.5)0.32 ＝ 8.9 （月）• 如果分析员与程序员的工资都按每月

6,000美元计算，则该项目的开发人员的工资总额为

51.5×6,000 ＝ 309,000 （美元）• 作为对比，现在用 IBM模型计算： PM ＝ 5.2 (10)0.91 ＝ 42.27 （人月）

D ＝ 4.1 (10)0.38 ＝ 9.84 （月） S ＝ 0.54 (42.27)0.60 ＝ 5.1 (人 )

详细 COCOMO模型• 详细 COCOMO模型的名义工作量公式和进度公式与中间 COCOMO模型相同。

• 工作量因素分级表分层、分阶段给出。针对每一个影响因素，按模块层、子系统层、系统层，有三张工作量因素分级表，供不同层次的估算使用。每一张表中工作量因素又按开发各个不同阶段给出。

• 例如，关于软件可靠性（ RELY ）要求的工作量因素分级表（子系统层），如表所示。

• 使用这些表格，可以比中间COCO MO模型更方便、更准确地估算软件开发工作量。

软件可靠性工作量因素分级表(子系统层 )

Putnam模型

• Putnam模型是一种动态多变量模型。适用于大型项目，但也可以应用在一些较小的软件项目中。

• 它是假定在软件开发的整个生存期中工作量有特定的分布。

• 大型软件项目的开发工作量分布可以用 Rayleigh-Norden曲线表示。

• 用 Rayleigh-Norden曲线可以导出一个“软件方程”

• td 是开发持续时间 (年 ) ， K是软件开发与维护在内的整个生存期所花费的工作量 ( 人年 )， L 是源代码行数 (LOC)，Ck是技术状态常数，因开发环境而异。

34

31

dk tKCL

技术状态常数 Ck 的取值

Ck的 典型值

开发环境

开 发 环 境 举 例

2000 差 没有系统的开发方法，缺乏 文档和复审，批处理方式。

8000 好 有合适的系统开发方法，有 充分的文档和复审，交互执 行方式。

11000 优 有自动开发工具和技术。

软件可靠性估算• 故障数估算 1. 故障植入法 设：植入故障数为 Ns，经测试后发现 ns个植入故障和 n 个原有故障，则程序中原有故障总数的估算值： N’ = （ n Ns ） / ns

2. 分别测试法 两组（个）测试员同时独立地测试同一程序，设： E1、 E2分别是各组发现的故障数， E0为两组发现的相同故障的数目，则程序中原有故障总数的估算值： Er = ( E1E2 )/E0

•平均故障间隔时间 MTBF 的估算 假定软件故障率是常数，若程序在运行 H小时的过程中出现的故障数为 r ，则

故障率： r / H

MTBF = 1 / = H / r

• 软件项目管理概述• 软件度量• 软件项目估算• 风险分析• 进度安排• 软件项目的组织

风险分析风险分析的主要活动：• 风险识别• 风险估算• 风险评价• 风险管理

风险识别风险主要有：• 项目风险：预算、进度、人力、资源、顾客、需求等方面的潜在问题

• 技术风险：设计、实现、接口、验证和维护过程中可能发生的潜在问题

•商业风险：是否符合市场需求；是否符合公司销售战略；销售部门是否熟悉产品；上级管理部门的支持程度；预算和人员的估算是否合理（预算风险）

• 人员配备风险检测表（见 P47例 2.5)

风险估算•假定风险检测表由 m 项组成，每项的取值范围是 0 ~ n， 0表示无风险，当 n=1时即为“假 /真”

•设第 i 种风险检测表的第 j 项的值是 xij，其加权系数为 Wij，则第 i 种风险的估算值为

其中 Wij 0

m

1jijiji )mn/(xw

m

1jij mw

•设第 i 种风险在整个项目风险中的加权系数为 i （ i =1,2…k ），则整个软件项目的风险估算值为

其中 ， i 0

• 0 R 1 ，当 R接近 0 时风险较小，当 R接近 1 时风险较大

• 当 i i较大时，表示第 i 种风险出现

k

1iR ii

k

1i1i

风险评价

• 用三元组 [ ri , li , xi ]描述风险，其中 ri

代表风险； li表示风险 ri发生的概率； xi表示风险 ri带来的影响。

• 风险参照水准（ risk referent level ）

• 风险评价过程1.定义项目的风险参照量（成本、进度、性能）

2.找出每个风险三元组 [ ri , li , xi ]与风险参照量的关系

3.定义项目被迫终止的临界区域4.预测哪些风险组合对参照量的综合影响

风险参照水准

参照点 ( 成本值 . 时间值 )

将造成项目终止估计进度超出

估计成本超出

风险管理和控制

• 风险管理和控制活动（见 P48图 2.9 ）•例因高级职员流动给项目带来的风险（见 P48 ）

• 风险管理和监控计划 RMMP

Risk Management and Monitoring Plan

（见 P49表 2.14 ）

• 软件项目管理概述• 软件度量• 软件项目估算• 风险分析• 进度安排• 软件项目的组织

进度安排• 软件开发项目的进度安排有两种方式：（ 1 ）系统最终交付日期已经确定，软件开发部门必须在规定期限内完成；（ 2 ）系统最终交付日期只确定了大致的年限，最後交付日期由软件开发部门确定。

• 进度安排落空，会导致市场机会的丧失，使用户不满意，而且也会导致成本的增加。

• 因此，在考虑进度安排时，要把工作量与花费的时间联系起来，合理分配工作量 , 利用进度安排的有效方法严密监控软件开发的进展情况，使软件开发的进度不致拖延。

开发人数与软件生产率的关系

• 当几个人共同承担软件开发项目中的某一任务时，人与人之间必须通过交流来解决各自承担任务之间的接口问题，即所谓通信问题。通信需花费时间和代价，会引起软件错误的增加，降低软件生产率。

• 若两个人之间需要通信，则称在这两个人之间存在一条通信路径。如果一个软件开发小组有 n 个人，每两人之间都需要通信，则总的通信路径有 n(n-1)/2 (条 ) 。

• 设一个人单独开发软件，生产率是5000 行／人年。若 4 个人组成一个小组共同开发这个软件，则需要 6条通信路径。若在每条通信路径上耗费的工作量是 250 行／人年。则小组中每个人的软件生产率降低为

5000－ 6×250／ 4 ＝ = 5000－ 375 ＝ = 4625 行／人年。

• 从上述分析可知，一个软件任务由一个人单独开发，生产率最高；而对于一个稍大型的软件项目，一个人单独开发，时间太长。因此软件开发小组是必要的。

• 但是，开发小组不宜太大，成员之间避免太多的通信路径。

• 在开发进程中，切忌中途加人，避免太多的生产率损失。

任务的分解与并行性• 当参加同一软件工程项目的人数不止一人的时候，开发工作就会出现并行情形。

• 软件开发进程中设置许多里程碑。里程碑为管理人员提供了指示项目进度的可靠依据。

• 软件工程项目的并行性提出了一系列的进度要求。

• 因为并行任务是同时发生的，所以进度计划表必须决定任务之间的从属关系，确定各个任务的先后次序和衔接，确定各个任务完成的持续时间。

• 项目负责人应注意构成关键路径的任务，即若要保证整个项目能按进度要求完成，就必须保证这些任务要按进度要求完成。

制定开发进度计划• 40－ 20－ 40规则

在整个软件开发过程中，编码工作量仅占 20％，编码前工作量占 40％，编码后工作量占 40％。

40－ 20－ 40 规则相当粗糙，只能用来作为 一个指南。实际的工作量分配比例必须按照各项目的特点来决定。

• COCOMO模型开发进度 TDEV与工作量 MM的关系：

TDEV ＝ a（MM） b

如果想要缩短开发时间，或想要保证开发进度，必须考虑影响工作量的那些因素。按可减小工作量的因素取值。

按此比例确定各个阶段工作量的分配，从而进一步确定每一阶段所需的开发时间，然后在每个阶段，进行任务分解，对各个任务再进行工作量和开发时间的分配。

进度安排的方法• 可以把用于一般开发项目的进度安排的技术和工具应用于软件项目。

• 为监控软件项目的进度计划和工作的实际进展情况，为表现各项任务之间进度的相互依赖关系，需要采用图示的方法。

• 在图示方法中，必须明确标明： 各个任务的计划开始时间，完成时间；

各个任务完成标志（即○文档编写和△评审）；

各个任务与参与工作的人数，各个任务与工作量之间的衔接情况；

完成各个任务所需的物理资源和数据资源。

(1) 甘特图（ Gantt Chart ）• 在甘特图中，每一任务完成的标准，不是以能否继续下一阶段任务为标准，而是以必须交付应交付的文档与通过评审为标准。因此在甘特图中，文档编制与评审是软件开发进度的里程碑。

(2) PERT 技术和 CPM 方法

• PERT（ Program Evaluation and review Technique ）技术叫做计划评审技术， CPM（ Critical Path Method ）方法叫做关键路径法，它们都是安排开发进度，制定软件开发计划的最常用的方法。

• 它们都采用网络图来描述一个项目的任务网络，也就是从一个项目的开始到结束，把应当完成的任务用图或表的形式表示出来。

• PERT图是一个有向图，图中的箭头表示任务（或作业），箭头上可标上完成该任务所需的时间，图中的结点表示流入该结点的任务已完成，可以开始流出该结点的任务，我们把结点称为事件。仅当所有流入结点的任务都完成时，流出该结点的任务才同时开始。事件本身不消耗时间和资源，它仅代表某个时间点。

• 每个事件有一个事件号和出现该事件的最早时刻和最迟时刻。

• 最早时刻表示所有到达该事件的任务最早在此时刻时完成，或从该事件出发的任务最早在此时刻时才可开始。

• 最迟时刻表示所有到达该事件的任务最迟必须在此时刻时完成，或从该事件出发的任务最迟必须在此时刻时开始，否则整个工期就无法按期完成。

• 每个任务还可以有一个机动时间，表示在不影响整个工期的前提下，完成该任务有多少机动余地。

• 为了表示任务间的关系，可以加入空任务，完成空任务的时间为 0 。

事件号

最早时刻

最迟时刻

•事件和任务（作业）的图形表示完成任务所需的时间（机动时间）

• 最早时刻 EET 的计算 第一个事件的最早时刻为 0 ，从左到右按事件发生顺序计算每个事件（包括空事件）的最早时刻

Ed = max( Ea + ta , Eb + tb , Ec + tc )

ta

tb

tc

d Ed

c Ec

b Eb

a Ea

• 最迟时刻 LET 的计算 最后一个事件的最迟时刻等于它的最早时刻，从右到左按事件发生的逆序计算每个事件（包括空事件）的最迟时刻

Ld = min( La - ta , Lb - tb , Lc - tc )

ta

tb

tc

d

c

b

aLa

Lb

Ld

Lc

• 机动时间的计算机动时间 = Lb - Ea - t

• 机动时间为 0 的任务（作业流）组成整个工程的关键路径

• 组成关键路径的任务所需的实际完成时间不得超过整个工程的预定时间

（机动时间）

ta b

LbLa

Ea Eb

• 例

2

1

6

0

3

40

2

3

4

2

3

0

1

2

4

6

7

5

2

1

6

0

3

40

2

3

4

2

36

00

14

24

410

613

715

55

2

1

6

0

3

40

2

3

4

2

36

9

00

0

14

4

24

4

41010

61313

71515

55

11

(0)

(6)

(0)

(6)

(0)

(4)

(4)

(3)

(0)

(1)

(0)

2

1

6

0

3

40

2

3

4

2

36

9

00

0

14

4

24

4

41010

61313

71515

55

11

项目的追踪和控制软件项目管理一项重要工作就是在项目实施过程中进行追踪和控制：• 定期举行项目状态会议。由每位项目成员报告其进展和遇到的问题。

• 评价在软件工程过程中所产生的所有评审的结果。

• 确定由项目的计划进度所安排的可能选择的正式的里程碑。

• 比较在项目资源表中所列出的每一个项目任务的实际开始时间和计划开始时间。

• 非正式地与开发人员交谈，以得到他们对开发进展和刚冒头的问题的客观评价。

• 当问题出现的时候， 项目管理人员必须实行控制以尽快地排解问题。

• 软件项目管理概述• 软件度量• 软件项目估算• 风险分析• 进度安排• 软件项目的组织

软件项目的组织• 开发组织采用什么形式，要针对软件项目的特点来决定，同时也与参与人员的素质有关。

1 、组织原则 (1) 尽早落实责任： 在软件项目工作开始时，要尽早指定专人负责。使他有权进行管理，并对任务的完成负全责。

（ 2 ）减少接口： 一个组织的生产率随完成任务中存在的通信路径数目增加而降低。要有合理的人员分工、好的组织结构、有效的通信，减少不必要的生产率的损失。

（ 3 ）责权均衡： 软件经理人员所负的责任不应比委任给他的权力还大。

2. 组织结构的模式 （ 1 ）按课题划分的模式 把软件开发人员按课题组成小组，小组成员自始至终参加所承担课题的各项任务。他们应负责完成软件产品的定义、分析、设计、实现、测试、复查、文档编制、甚至包括维护在内的全过程。

（ 2 ）按职能划分的模式 把参加开发项目的软件人员按任务的工作阶段划分成若干个专业小组。要开发的软件产品在每个专业小组完成阶段加工（即工序）以后，沿工序流水线向下传递。例如，分别建立计划组、需求分析组、设计组、实现组、系统测试组、质量保证组、维护组等。各种文档资料按工序在各组之间传递。

（ 3 ）矩阵形模式 这种模式实际上是以上两种模式的复合。一方面，按工作性质，成立一些专门组，如开发组、业务组、测试组等；另一方面，每一个项目又有它的经理人员负责管理。每个软件人员属于某一个 专门组，又参加某一项目的工作。

3. 程序设计小组的组织形式• 小组内部人员的组织形式对生产率也有影响。现有的组织形式有三种。

（ 1 ）主程序员制小组 小组的核心由一位主程序员 ( 高级工程师 ) 、二至五位程序员、一位后援程序员组成。主程序员负责小组全部技术活动的计划、协调与审查，设计和实现项目中的关键部分。

程序员负责项目的具体分析与开发，文档资料的编写工作。后援程序员支持主程序员的工作，为主程序员提供咨询，也做部分分析、设计和实现的工作。并在必要时能代替主程序员工作。

主程序员制小组还可以由一些专家 ( 如通信专家或数据库设计专家 ) 、辅助人员 ( 如打字员和秘书 ) 、软件资料员协助工作。

（ 2 ）民主制小组 在民主制小组中，遇到问题，组内成员之间可以平等地交换意见。工作目标的制定及做出决定都由全体成员参加。虽然也有一位成员当组长，但工作的讨论、成果的检验都公开进行。这种组织形式强调发挥小组每个成员的积极性。有人认为这种组织形式适合于研制时间长、开发难度大的项目。

（ 3 ）层次式小组 在层次式小组中，组内人员分为 三级：组长（项目负责人）一人负责全组工作，包括任务分配、技术评审和走查、掌握工作量和参加技术活动。 他直接领导二至三名高级程序员，每位高级程序员通过基层小组，管理若干位程序员。

• 这种组织结构只允许必要的人际通信。比较适用于项目本身就是层次结构的课题。因为这样可以把项目按功能划分成若干个子项目，把子项目分配给基层小组，由基层小组完成。

• 这种组织方式比较适合于大型软件项目的开发。

人员配备• 如何合理地配备人员，也是成功地完成软件项目的切实保证。所谓合理地配备人员应包括： 按不同阶段适时任用人员 恰当掌握用人标准。

1. 项目开发各阶段所需人员• 一个软件项目完成的快慢，取决于参与开发人员的多少。

• 在开发的整个过程中，多数软件项目是以恒定人力配备的。

• 实际人力需求与开发进度的关系如下图中的曲线所示。

• 按此曲线，需要的人力随开发进展逐渐增加，在编码与单元测试阶段达到高峰，以后又逐渐减少。

• 如果恒定地配备人力，在开发初期将会有部分人力资源用不上而浪费掉。在开发中期，需要人力不够，造成进度的延误。在开发后期就需要增加人力以赶进度。

• 恒定地配备人力将浪费人力资源。

2. 配备人员的原则• 重质量 软件项目是技术性很强的工作，要任用少量有实践经验、有能力的人员去完成关键性的任务。

• 重培训 培养所需技术人员和管理人员是有效解决人员问题的好方法。

• 双阶梯提升 人员提升应分别按技术职务和管理职务进行，不能混在一起。

3. 对项目经理人员的要求• 软件经理人员是工作的组织者，他的管理能力的强弱是项目成败的关键。他应具有以下能力：

把用户提出的非技术性要求加以整理提炼 , 以技术说明书的形式转告给分析员和测试员。

能说服用户放弃一些不切实际的要求 , 以保证合理的要求得以满足。

能够把表面上似乎无关的要求集中在一起 , 归结为 “需要什么” , “ 要解决什么问题”。这是一种综合问题的能力。

要懂得心理学 , 能说服上级领导和用户，让他们理解什么是不合理的要求。但又要使他们毫不勉强 , 乐 于接受，并受到启发。

4. 评价人员的条件• 软件项目中人的因素越来越受重视。在评价和任用软件人员时，必须掌握一定的标准。人员素质的优劣常常影响到项目的成败。

牢固掌握计算机软件的基本知识和技能。

善于分析和综合问题，具有严密的逻辑思维能力。

工作踏实、细致 , 不靠碰运气，遵循标准和规范，具有严格的科学作风。

工作中表现出有耐心、有毅力、有责任心。

善于听取别人的意见，善于与周围人员团结协作，建立良好的人际关系。

具有良好的书面和口头表达能力。