第14章 软件计划 14.1 软件范围界定 14.2 资源需求 14.3 项目估算 14.4 软件项目计划的结构

Presentation on theme: "第14章 软件计划 14.1 软件范围界定 14.2 资源需求 14.3 项目估算 14.4 软件项目计划的结构"— Presentation transcript:

1 第14章 软件计划 14.1 软件范围界定 14.2 资源需求 14.3 项目估算 14.4 软件项目计划的结构
第14章 软件计划 14.1 软件范围界定 14.2 资源需求 14.3 项目估算 14.4 软件项目计划的结构 14.5 项目计划的分解求精 14.6 计划跟踪监督 14.7 计划执行情况的度量与计划调控 14.8 小结

2 14.1 软件范围界定 软件项目计划的第一个活动是确定软件的范围。软件范围描述了软件项目的功能、性能、约束条件、接口以及可靠性等质量指标。此项工作旨在进一步将项目的开发任务明确化、具体化，并进行必要的功能分解，为下一步的估算工作打下基础。

3 在软件项目开始时，虽然已经定义了要求，并确立了基本的目标，但是还不足以作为开展估算的基础。必须对分配给软件的功能需求、性能需求进行评价，从管理角度和技术角度出发，确定明确的、可理解的项目范围。关于软件范围的描述应当尽量给出定量的说明(如最大并发用户数，最大允许响应时间等)，给出约束条件或针对项目的限制(例如成本限制、运行环境的限制等)。此外，还要界定某些质量因素(如可靠性等)。 由于对成本和进度的估算都和项目功能有关，因此常常采用某种程度的功能分解细化，以便结合历史数据，采用面向规模或面向功能的方法对项目规模、成本、工作量、进度、风险、资源诸方面做出估算。

4 性能的考虑包括处理复杂度和系统响应时间的需求；约束条件则标志着外部硬件或其他现有系统对软件的限制。功能、性能和约束必须在一起进行综合的评价。因为在功能相同时，性能限制不同，可能将导致开发工作量相差一个数量级，成本和进度也会有显著的差别。 软件和其他元素是相互作用的。计划制定者要考虑每个接口的性质和复杂程度，以确定其对资源、成本和进度的影响。接口的概念可以解释为： (1) 运行软件的硬件及间接受软件控制的设备和软件之间的接口。 (2) 必须和新软件连接的现有软件和新软件之间的接口。 (3) 人机接口。 (4) 软件运行前后的一系列操作过程。

5 针对每一种接口，都应当明确地理解通过接口的信息转换要求。
项目要求的软件可靠性指标也应当作为一种约束予以考虑，以便在进行规模、成本、工作量估算时能够更加精确。在FP度量方法中，功能点复杂度加权因子和从F1～F14的取值就反映了约束条件对最终度量结果的影响。作为例子，我们对一个传送带分类系统(如图14.1所示)的软件需求进行范围界定。

6 图14.1 一个传送带分类系统

7 原始的功能需求陈述： 传送带分类系统(CLSS)用来传送贴有识别条码的六类不同的产品。产品通过由一个条码阅读器和一台PC机组成的分类站。分类站的PC机连到一个分流器上，分流器将不同的产品分送到不同的包装箱中去。 CLSS软件以和传送带速度一致的时间间隔接收条码阅读器送来的数据，将条码数据译码转换为产品标识符的规定格式并以此为查询键值。在最多可容纳1000个条目的数据库中进行查询检索，以便确定当前产品应当放入哪个箱子中。查出来的该箱子的编号被送到分流器，分流器将根据接收到的数据将产品推入指定的箱子中。同时，每一个产品放入哪个箱子的信息还要写入数据库中备用。

8 CLSS软件还要接收来自脉冲流速计的输入，用以使控制信号和流速计同步。根据分类站和分流器之间产生的脉冲个数，软件将在适当时产生一个控制信号给分流器，以适当地确定产品去向。
根据以上陈述，我们就可以开始进行范围界定工作。

9 需求范围界定： (1) 读条形码作为输入。 (2) 读脉冲流速计输入。 (3) 对条码数据进行解码。 (4) 检索查询数据库。 (5) 确定合适的箱子号。 (6) 产生并输出分流器控制信号。 (7) 保存当前产品被存入的箱子的纪录。

10 性能要求： 每一个产品的全部处理都必须在下一个产品到达分类站之前处理完毕(根据传送带的流速可以换算出最大可接受的响应时间指标)。 接口要求： (1) PC和分类站之间的数据接口，用来传送原始条码数据。 (2) PC和脉冲流速计之间的接口，用来接收同步脉冲数据。 (3) PC和分流器之间的接口，用来输出分流器驱动数据。

11 约束条件： (1) 传送带匀速运动。 (2) 传送带上的产品间隔均匀摆放。 如上例所示，进行了软件范围界定之后，就可以综合考虑功能、性能、接口、约束条件要求，开始进行计划的下一步工作——确定资源需求并进行估算。

12 14.2 资 源 需 求 在进行了范围界定之后，软件计划的第二个任务是估算为完成本软件开发工作所需要的资源。包括人力资源、可复用软件资源和环境资源(如图14.2所示)。 资源金字塔的底层是开发环境，包括硬件和软件工具，提供支持开发工作的基础；再高一层是可复用的软件构件——软件建筑块，能够极大地降低开发成本并缩短交付时间；金字塔的顶端是人力资源，这是资源中的主要成分。在项目计划中，针对所需要的每类资源，都应当从资源描述、可用性说明、需要该资源的时间以及该资源被使用的持续时间四个特征上进行说明。

13 图14.2 资源金字塔

14 计划者在开始时要评估需求范围并选择完成开发所需要的技术。对于开发组中所需要的各种角色(如项目经理、系统分析员、设计师、程序员等)和他们应当具备的专业技能都要进行描述。这就显化了对人力资源的能力要求。但所需要的人数要等到完成了项目工作量估算之后才能结合交付时间的限制完全确定。在开发过程的各个阶段，对人力资源的需求是不一样的(如图14.3所示)，应当按照动态的需求来制定人力资源的需求计划。

15 图14.3 不同开发阶段的人员参与情况

16 一个软件开发组织，总是不断地将自己的开发成果积累起来，形成自己的软件财富库。有一些通用功能(例如权限管理、数据维护、通用查询等等)自然地就形成了可复用的软件构件。而且分析、设计阶段的工作产品也都存在着在类似项目中重用的可能。直接使用可复用构件，将会使开发工作量(不仅仅是编码量)因重用而下降。所以，在计划阶段，就应当考虑对可复用资源的需求。考虑到需求吻合程度，对可复用构件的使用，分为完全复用和修改复用两种情况： (1) 存在着现成的、完全满足要求的软件构件，肯定应当重用它。 (2) 对于必须进行修改才能重用的软件成分，要慎重处理，建议权衡了修改工作量和重新开发工作量的对比情况后再考虑是否重用。

17 在项目计划阶段，常常会忽视可复用构件重用问题，应当引起注意。
硬件与软件资源环境，是支持软件开发的环境，通常称为“软件工程环境”，集成了硬件和软件两大部分。硬件提供了一个支持工具平台，如各类服务器、网络通信设备、各种外设等等；而软件资源是工作在这一平台上的工具集，包括分析设计工具、语言工具、中间件工具、数据库系统、操作系统等等。除了要明确所需要的软硬件资源环境之外，还应当明确地界定资源的时间窗口，并落实在指定的时间窗口中这些资源是否可用。

18 14.3 项 目 估 算 就本质来说，项目估算就是“超前度量”。直接度量和间接度量两种模式，面向规模度量和面向功能度量两种方法都可以用来进行估算。但是，由于“超前”的特点，必要的基本度量数据往往难以直接得到，历史数据和基于经验的模型往往成为进行估算的依据。“度量基线”在进行估算时的作用十分显著。没有度量基线，项目估算的基础就十分薄弱，很不稳定。

19 就种类而言，计划者要进行的项目估算主要包括项目规模估算、开发工作量估算、开发成本估算、进度估算等等。在估算中最经常使用的方法包括：
(1) 使用简单的“分解技术”来进行项目规模、工作量和成本的估算。 (2) 使用一个或多个经验模型进行软件规模、工作量和成本的估算。

20 分解技术采用“分而治之”的策略进行软件项目估算，将项目分解成若干主要功能及相关的软件工程活动，通过逐步求精的方式进行规模、工作量和成本的估算。经验估算模型是基于经验来进行的，可以表示成
d = f(vi) 其中d是要估算的对象，如规模、工作量、进度；vi 是选出来的独立参数(如FP、LOC)。这两种方法可以交叉使用，以便互相验证估算结果。也有一些自动估算工具能够实现一种或多种分解技术或经验模型，通过交互式地输入基本参数，自动完成估算，能够极大地提高估算效率。

21 基于问题分解的估算 分解方法包括问题分解和过程分解，都可以用来进行项目的估算。在项目估算过程中，“规模”是一个基本的度量。如果能够估算出项目的规模，那么结合历史数据对规模进行计算与分析，就不难完成对工作量、成本的间接度量估算。在资源确定的前提下，进度估算也能够利用工作量估算结果，采用间接方法完成。就规模估算本身来说，只要界定了需求目标并且进行了必要的分解细化，那么既可以利用LOC方法进行直接度量，也能够使用功能点(或特征点、3D方法等)进行间接估算。

22 通过对“问题”的分解进行估算时，可以采用LOC或FP估算方法。LOC和FP的求取方法已经在前一章中介绍过，不再重复。具体来说，LOC和FP在估算中有两种作用：其一是作为一个估算变量，度量软件中每个成分的规模；其二是结合度量基线数据进行计算，得到工作量与成本估算数据。这时，来自度量基线中的生产率历史数据起着非常重要的作用。

23 由于项目的多样性，只用一个单一的生产率历史数据来作决定是不科学的。应当根据经验，从乐观的、可能的、悲观的三种主观前提出发进行估算，根据计算出来的三个结果值再来计算LOC或FP的期望值。基于经验，可以采用下述加权求和公式来计算： EV = (Sopt + 4Sm + Spess)/ 6 上式中，Sopt代表“乐观”值，Sm代表“可能”值，Spess代表“悲观”值。公式中给“可能值”以最大权重，并遵循概率分布。一旦确定了估算变量的期望值，就可以开始使用历史的LOC或FP相关数据作下一步估算。这种方法称为“三点估算”方法。

24 例一 基于LOC估算的例子，范围说明如下：
CAD软件接收来自工程师输入的三维或二维几何数据。工程师通过用户界面和CAD软件进行交互，并控制它，该界面应当表现出良好的人机界面设计的特征。所有几何数据及其他支持信息都保存在一个CAD数据库中。要求开发设计分析模块，以产生必要的输出，这些输出将表现在不同的图形设备上。软件在设计中要考虑与外设交互并控制它们。除显示器之外，外设包括鼠标、数字化仪和激光打印机。假设已经对上述要求进行了求精和分解，界定了以下的主要软件子功能：

25 (1) 用户界面及控制机制； (2) 二维几何分析(2DGA)； (3) 三维几何分析(3DGA)； (4) 数据库管理(DBM)； (5) 计算机图形显示机制(CGDF)； (6) 外设控制(PC)； (7) 设计分析模块(DAM)。

26 EV =(Sopt + 4Sm + Spess)/ 6 = 6800 LOC
利用本组织的度量基线数据，遵照LOC的“三点”估算技术，对分解后的需求进行LOC估算。例如，对于3DGA功能：Sopt = 4600；Sm = 6900；Spess = 8600。求得其期望值为 EV =(Sopt + 4Sm + Spess)/ 6 = 6800 LOC 类似地，求出其他被分解部分的LOC期望值，形成表14.1。

27 表14.1 基于问题分解的LOC方法的估算表 问题分解所得的子功能 估算的LOC期望值(行) 用户界面及控制机制 2300
二维几何分析(2DGA) 5300 三维几何分析(3DGA) 6800 数据库管理(DBM) 3350 计算机图形显示机制(CGDF) 4950 外设控制(PC) 2100 设计分析模块(DAM) 8400 估算总代码行数期望值 33 200

28 查询本组织的度量基线得知，此类系统的平均生产率为620LOC / PM；平均人月成本为8000美元/人月，则LOC平均成本为13美元 / LOC。计算可知本项目的总成本为 美元，总工作量54个人月。如果人力资源投入六名合格的工程师，则预计工期为九个月。 例二 基于FP估算的例子。对于上例中的各个子功能进一步细化，将所有功能都分解为EI、EO、EQ以及ILF、EIF的组合，假设加权因子都取为“平均”，计算出各类功能点见表14.2。

29 表14.2 估算信息域值——基于问题分解的FP估算
乐观值 可能值 悲观值 估算计数 加权因子 FP计数 EI 20 24 30 4 96 EO 12 15 22 16 5 80 EQ 28 88 ILF 10 40 EIF 2 3 7 14 总计数值 318

30 表14.3 CAD软件项目复杂度调整 因子 值 备份和复原 4 信息域值复杂度 5 数据通信 2 内部处理复杂度 分布式处理 可复用需求
可复用需求 关键性能 设计中的转换及安装 3 现有的操作环境 多次安装 联机数据登录 方便修改的应用设计 多屏幕输入切换 复杂度调整因子 1.17 主文件联机更新

31 最后，得到整个项目的FP估算期望值： FP = 318×[ ×∑Fi] = 372(功能点)。 查询组织的度量基线数据库得知，这类系统的平均生产率为6.5FP / PM，一个PM的成本仍取8000美元，则每个FP的平均成本约为1230美元，总项目成本估算约为 美元，工作量估算期望值是58个人月。

32 基于过程分解的估算 通过对工作过程进行分解，也能够结合度量基线进行估算。方法是将过程分解为相对较小的活动或任务，估算出完成每项任务的工作量，最后汇总即可。和基于问题分解的估算一样，基于过程分解的估算也是开始于软件功能描述。对于每一个功能，都必须要执行一系列的活动，如果能够利用同类项目的度量基线估算出对应于每项任务所需要的工作量，则加总值就是本项目的工作量估算值。 仍以CAD软件开发项目为例，基础参数见表14.4，仍然按照每人月8000美元计算，项目总成本 美元，工作量共46个人月。

33 表14.4 CAD软件项目基于过程分解的工作量估算
   活动 任务 用户 通信 计划 制订 风险 分析 工 程 设计 UIGF 0.50 2.50 2DGA 0.75 4.00 3DGA DSM 3.00 CGDF PCF 0.25 2.00 DAM 总和 3.50 20.50 工作量 0.5% 8% 45%

34 表14.4 CAD软件项目基于过程分解的工作量估算
建造发布 用户 评估 总和 编码 测试 0.40 5.00 8.40 0.60 2.00 7.35 1.00 3.00 8.50 1.50 6.00 0.75 5.75 0.50 4.25 4.75 16.50 46.00 10% 36%

35 由上面的例子可见，采用不同的估算方法，结果会有一定的误差。这在一定范围内是正常的，可以用几种方法的平均估算值作为最终估算值。同时，也可以看出，度量基线在估算中的作用是无庸置疑的。
如果几种方法的估算偏差过大(一般以20%为界)，则需要分析原因，进行再估算。可能的原因主要有两种，其一是度量基线中的数据和当前问题的类型不匹配；其二是对项目的范围理解不充分。计划者必须确定偏差过大的原因，并调和各个估算结果。

36 经验估算模型 经验估算模型是用经验公式来进行项目的估算。因为公式是通过对有限样本集的分析得出的，因此得到的结果并不一定适合当前项目类型，这种方法应当慎重使用。使用这种方法，工作量是LOC 或FP的函数。 典型的经验估算模型是通过对以前项目中收集到的数据进行回归分析导出的。总体结构具有类似的形式： E = A + B×(ev)C

37 其中，ev是估算变量，A、B、C是基于经验导出来的常数，E是以人月为单位的工作量值。同时，还可以在公式中加一些调整因素以便适应当前项目的特征。基于工作实践，许多人提出了行之有效的经验估算模型，主要的有： (1) 面向LOC的经验估算模型： Walston-Felix模型 E = 5.2×( KLOC) 0.91 Bailey-Basili模型 E = ×(KLOC)1.16 Boehm的简单模型 E = 3.2×(KLOC)1.05

38 (2) 面向FP的经验估算模型： Albrecnt-Gaffney模型 E = － FP Kemerer模型 E = 60.62×7.728×10－8 (FP)3 Maston-Barnett模型 E = FP 不同的模型来源于不同的样本数据集，结果对于相同的ev值会算出不同的结果。因此，估算模型必须按照当前项目特点进行调整。

39 COCOMO模型 构造性成本模型(COCOMO，Constructive Cost Model)是由Barry Boehm提出的一种被广为应用的估算模型，它共有三个层次。 (1) 基本的COCOMO模型：将软件开发工作量(及成本)作为程序规模函数进行计算，程序规模以估算的代码行数来表示。该模型是一个静态单变量经验模型。 (2) 中级COCOMO模型：将软件开发工作量(及成本)作为程序规模及一组“成本驱动因子”的函数(共15项)来进行计算。其中，“成本驱动因子”包括对产品、硬件、人员及项目属性的主观评估。

40 (3) 高级COCOMO模型：包含了中级模型的所有特征，并结合了成本驱动因子对软件工程过程中每一个步骤(分析、设计、编码等)的影响的评估。
源指令行数：DSI或KDSI，度量单位为行或千行，1KDSI = 1024 DSI(不包括注释行)。 开发工作量：MM，度量单位为“人月”，1MM = 19人日 = 152 人时 = 1/12 人年。 开发进度：TDEV，度量单位为月，它由工作量确定。 在使用COCOMO模型进行度量时，应当考虑到具体项目的特点和具体的开发环境。

41 软件项目的类型一般可以分为三类。 (1) 组织型：相对较小较简单的软件项目(KDSI<50)。需求不很苛刻，开发人员对软件产品开发目标理解充分，软件工作经验丰富，对软件使用环境熟悉，受硬件约束小。多数应用软件均属此类。 (2) 嵌入型：要求在紧密联系的硬件、软件和操作的限制条件下运行。通常与某些硬设备紧密结合，因此对算法、数据结构、接口要求较高的软件规模任意。例如大型OS软件、大型指挥系统软件等都属此类。

42 (3) 半独立型：要求介于以上两种之间的软件。规模、复杂性规模都在中等以上。KDSI可能在300以上。例如大型ERP、简单的指挥系统、大型事务处理软件等属于此类。
针对不同的项目任务，应当选择使用不同层次的COCOMO模型进行估算。基本的COCOMO模型工作量与进度估算公式见表14.5。

43 表14.5 基本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

44 表14.6 中级的COCOMO模型工作量与进度估算公式
总体类型 名义工作量 名义进度 组织型 MM1 = 3.2(KDSI)1.05 TDEV = 2.5(MM1)0.38 半独立型 MM1= 3.0(KDSI)1.12 TDEV = 2.5(MM1)0.35 嵌入型 MM1 = 2.8(KDSI)1.20 TDEV = 2.5(MM1)0.32

45 对于计算的结果，要基于经验进行调整，实际工作量：
这里，R是经验系数，∏Fi 是15项调整函数F1 ～F15的连乘积。实际进度也要利用实际工作量调整。15种影响软件工作量的因素见表14.7。

46 表 种影响软件工作量因素Fi

47 高级的COCOMO模型的名义工作量和名义进度计算公式和中级的类同， 但是调整方式有区别：不再使用统一的工作量调整因子表，而是将15项工作量调整因子按照不同工作阶段(分析与高层设计、详细设计、编码与单元测试、集成及测试)分别考虑，给出不同的阶段工作量调整数据表，最后使用各个阶段工作量调整因子的综合均值进行工作量和工作进度调整，更为贴近实际。

48 软件方程式是一种多变量估算模型。这种模型是从4000多个当代软件项目中收集的生产率数据中总结出来的。该模型具有如下的形式：
E = [LOC×B0.333/p]3 ×(1/t4 ) 其中，E = 以人月或人年为单位的工作量数据。 t = 以月或年表示的项目持续时间。 B = “特殊技术因子”，它随着“对集成、测试、质量保证、文档及管理技术的需求的增长”而缓慢增加。对于KLOC在5～15的较小的程序，B = 0.16；对于超过70 KLOC的较大的程序，B = 0.39。

49 P = “生产率参数”，它反映了： (1) 总的过程成熟度及管理水平。 (2) 使用良好的软件工程时间的程度。 (3) 使用的程序设计语言的级别。 (4) 软件环境的状态。 (5) 软件项目组的技术及经验。 (6) 应用的复杂性。

50 对于实时嵌入式软件的开发，典型值是p = 2000；对于电信软件及系统软件，p = ；对于科学计算软件，p = ；而对于商业系统应用，p = 。当前项目的生产率数据可以从以前开发工作中收集到的历史数据中导出。 应当注意的是，软件方程中有两个独立的参数： (1) 规模的估算值(以LOC表示)； (2) 以月或年表示的项目持续时间。

51 为了简化估算过程，并将该模型表示为更通用的形式，Putnum等又提出了一组方程式，它们均从软件方程式中导出。
最小开发时间被定义为tmin： tmin = 8.14( LOC / P )0.43，单位是月 工作量数据E： E = 180Bt3，单位是人月(t的单位是人年) 对于前面讨论过的CAD软件开发项目，当规模确定之后，利用上式进行计算可得 tmin = 8.14( / )0.43 = 12.6 (月)； E=180×0.28×(1.05)3 = 58 (人月)

52 自动估算工具 前面所介绍的分解技术和经验估算模型已经在很多的软件工具中得以实现。这些软件称之为“自动估算工具”。结合历史数据使用自动估算工具，使得计划者能够估算项目的成本以及工作量，并对重要的项目变量如交付日期或人员进行分析。这些工具的共同作用是提高了估算效率，它们的共同点是都需要以下的一种或几种数据：

53 (1) 对于项目规模(如LOC)或功能(如功能点)的定量估算。
(2) 定性的项目特性，如复杂度、所要求的可靠性或交付期限的紧迫程度。 (3) 对于开发人员和环境的描述。 根据这些基本数据，利用自动估算工具能够提供关于如下数据的间接估算：完成该项目所需的工作量，预期的工程成本，项目持续时间，人员配置以及在某些情况下的开发进度及相关的风险防范。 应当强调的是，实践证明，若干种不同工具应用于同一个项目时，得到的估算结果可能存在很大偏差。因此，应当明确，自动估算工具的输出不应当作为惟一的估算数据来源。

54 14.4 软件项目计划的结构 当界定了软件范围，明晰了约束条件和接口要求，确定了资源需求，估算出项目规模、成本和工作量之后，制定项目开发计划就有了科学的依据。 软件项目计划由项目开发计划和相关的工作计划构成。相关工作计划包括测试计划、品质保证计划、配置管理计划、进度计划、培训计划等等。在软件项目开发计划的结构中，应当包括任务描述、过程模型选择、资源需求描述、项目度量估算、阶段任务划分、里程碑设置和工作产品清单等内容。具体的项目开发计划的结构可以参考“国家计算机软件产品标准”中的标准样表。各个开发组织也可以按照自己的过程定义方法，定义本组织的项目计划结构。

55 例 一个项目开发计划结构的参考样例。 下面是一个达到CMM 3级成熟度标准的软件开发组织的软件项目开发计划的结构模板，可供我们在设计项目开发计划结构时参考。 1. 引言 1.1 编写目的 1.2 项目背景 1.3 术语定义 1.4 参考资料

56 2. 项目概述 2.1 项目目标及功能界定 2.2 项目开发方法选择 2.2.1 体系结构选择 2.2.2 约束条件 2.2.3 开发技术路线 2.3 软件工作产品 程序产品 2.3.2 文档产品 2.4 产品运行环境说明 2.5 技术服务 2.6 软件验收标准

57 3. 规模、工作量、成本及资源需求 3.1 软件规模估算 3.2 软件工作量估算与阶段工作量分配 3.3 项目成本估算与成本控制计划 3.4 关键资源需求估算 4. 项目开发计划 4.1 项目组组织结构 4.1.1 角色定义 4.1.2 人员分配

58 4.2 阶段工作计划 4.2.1 项目计划阶段计划 4.2.2 需求分析阶段计划 4.2.3 体系结构设计计划 4.2.4 详细设计计划 4.2.5 测试的策划 4.2.6 编码计划 4.2.7 测试计划 4.2.8 系统实施及试运行计划 4.2.9 验收计划 项目维护计划

59 5. 人员培训计划 6. 变更控制规范 7. 配置管理计划 8. 风险预测及应对措施 9. 关于本软件开发计划的补充说明 在软件能力成熟度模型CMM中，将“软件项目计划”作为CMM 2级的一个重要的KPA提了出来。

60 14.5 项目计划的分解求精 “按照分阶段的生命周期计划进行严格的控制”是软件工程七项原则的第一项。计划是控制工程过程的依据，离开了计划，对工作的评价就没有标准，对过程的控制就没有根据。因此，在按照规范完成了包括范围界定、规模估算、资源需求分析、阶段划分、角色定义等内容的项目开发计划之后，应当进一步对其分解细化、调整求精。这样将能够使得开发工作步步、时时、事事有据可依、有章可循。

61 任务的确定与并发处理 在项目开发计划中，已经对项目的阶段工作任务进行了划分。但是在多人参加的项目中，开发工作中必然会出现并行情况，如图14.4所示。

62 图14.4 软件项目阶段任务的并行性

63 从图14.4中可以看到，在开发进程中设置了许多里程碑。里程碑为管理人员提供了指示项目进度的可靠依据。当一个软件任务成功完成并通过评审，产生了文档后，就完成了一个里程碑。阶段任务之间的“并行”特征也表示得较为清晰。 由于软件工程项目的“并行性”，就提出了一系列的进度要求。因为并行任务是同时发生的，所以进度计划必须决定任务之间的从属关系，确定各个任务的先后次序和彼此的衔接，确定各个任务完成的持续时间。此外，项目管理者必须特别注意构成关键路径的任务。在细化进度计划时，必须保证关键任务能够提前，至少是按期完成。否则必然导致项目的延误。同时在人力资源的调配上，也要注意到并行工作带来的影响。

64 制定明细的开发进度计划 当项目规模、开发工作量已经估算完毕，资源也已经明确后，可以按照表14.8的建议来确定各个阶段的工作量的分配比例，从而确定每一阶段所需的开发时间，然后再针对每个阶段进行任务分解，最后为分解出的各个任务进行工作量估算和开发时间的分配。在这个过程中，项目的进度计划被进一步求精，细化到了任务级。 表14.8 阶段任务时间比例分配 阶段任务 需求分析 设 计 编码与单元测试 组装与测试 占开发时间的百分比 10%～30% 17%～27% 25%～60% 16%～28%

65 为了比较清楚地表现各项阶段任务之间在进度上的相互依赖关系，利用图形方法表示进度计划比使用语言叙述更清楚。
在计划的图形表示中，必须明确标明各个阶段任务的计划开始时间、完成时间；各个任务完成的标志(约定：○表示文档编写；△代表评审)；各个任务中参加工作的人数；各个任务和工作量之间的衔接情况；完成各项任务所需要的物理资源和数据资源。甘特图(Gannt Chart)常用来表示细化的进度计划。在用甘特图进行进度求精时，时间单位可以分解到每周、每一个工作日乃至每一个工时，资源可以对应到每一个人。

66 图14.5 用甘特图表示进度计划

67 在表示进度计划的各种形式之间进行切换，比如数据表、甘特图、网络图等等。使用甘特图时，每一任务的完成，不是以能否继续下一阶段的任务为标准，而是以必须交付应当交付的文档和通过评审为标准。因此在甘特图中，文档编制和评审是软件开发进度的里程碑。

68 除甘特图之外，计划评审技术(PET，Program Evaluation Technigue)和关键路径方法(CPM，Critical Path Method)也都是安排开发进度、细化软件开发计划的常用方法。他们都采用“网络图”来描述一个项目的任务网络，利用识别关键路径和关键活动的方法，很便于进行计划的优化。 在制订软件开发计划并对其细化求精的过程中，应当注意处理好进度和质量之间的关系。不能为了进度牺牲质量，尤其不能为了加快进度去压缩各类审查、评审活动。

69 14.6 计划跟踪监督 没有计划的工程是混乱的工程、没有跟踪监督的计划是无效的计划。
14.6 计划跟踪监督 没有计划的工程是混乱的工程、没有跟踪监督的计划是无效的计划。 制订计划是严格项目管理的第一步。在计划执行的过程中，必须对计划的执行情况进行跟踪。并对跟踪所得的结果和计划情况进行对比分析。当计划与实际之间存在着较大偏差时，必须对过程活动或者计划进行调整。计划的跟踪监督在能力成熟度模型 CMM 中是一个重要的关键活动域。

70 计划是我们考核评价工作的标准，但是由于计划的基础是建立在不能完全保证精确度的“估算值”之上，所以，即使是精心制订的计划，也不见得就完全没有偏差。从另一个角度来看，即使计划制订得十分准确，当需求发生变更、资源发生变化或者发生了其他的风险，也会产生计划与实际进展情况脱节的现象。 对于项目计划进行跟踪和监督的目的是建立对实际进展的适当可视性，使管理者能在软件项目性能明显偏离软件计划时采取有效措施。

71 项目计划的跟踪和监督活动包括对照文件化的估计、约定和计划审查和跟踪软件完成情况和结果，并且根据实际的完成情况和结果调整这些计划。
软件项目的文件化的计划(即软件开发计划)用作跟踪软件活动、通报状态和修订计划的标准。管理者监控软件活动，主要通过在所选出的软件产品完成时和在所选择的里程碑处，将实际的软件规模、工作量、成本、资源和进度与计划值相比较，来确定真实的进展情况。必要时采取纠正措施。这些措施可以包括修订软件开发计划，重新策划遗留的工作或者改进过程性能。

72 不论是什么原因导致了计划和工程活动之间的偏差，都可能造成项目的失控。因此，对计划的执行情况进行制度化的跟踪度量，是项目管理过程中的一项重要任务。一种可行的方法是采用周计划/周总结的方式来进行跟踪监督。项目经理将项目开发计划分解到每个人、每一周。每个工作人员都必须按照项目计划制订自己本周的工作计划并严格执行，记录必要的工作数据。在每周结束时进行周工作总结，对照自己的计划进行工作量、进度、成本等数据的度量，找出存在的偏差并制定纠正偏差的措施。整个小组在个人跟踪的基础上进行项目的跟踪与监督。在计划的跟踪监督活动中，最重要的跟踪对象是工程活动、工作进度、项目资源、工作成本和工作质量。

73 除了内部的跟踪与监督之外，独立于项目组的SQA人员也应当进行项目计划的跟踪与监督，并将发现的问题通报给项目成员，必要时向上级管理部门通报。
对计划跟踪监督活动本身的进展，也应当进行度量，并将度量结果用于确定软件跟踪和监督活动的状态。需要度量的对象包括： (1) 在完成跟踪和监督活动时所花费的工作量和其他资源； (2) 根据跟踪结果对软件开发计划的更改活动，包括对软件工作产品的规模估计、软件成本估计、关键计算机资源估计和进度的更改。

74 14.7 计划执行情况的度量与计划调控 在计划制订并被细化求精之后，它实际上就已经界定了工作的目标，给出了项目规模，预计的工作量，各个阶段任务的完成期限，项目的总体成本和各个阶段的成本，所需要的资源和可能发生的风险。因此，在项目工作中，应当针对这些方面的实际进展进行度量。这种度量应当是量化的、客观的并应当形成书面的度量数据表，包括：

75 (1) 度量计划中罗列出来的所有软件工作产品的实际规模数据(代码行、文档页等等)；
(2) 度量完成各项任务的实际时间； (3) 度量完成各项工作所耗费的实际成本； (4) 度量人力资源、可复用构件资源和硬件/软件环境资源的实际状态(到位/未到位)； (5) 度量实际的工作进度； (6) 度量计划中指出的可能发生的风险情况(检查特定的风险标识出现/未出现)； (7) 度量在一段时间内发生的变更情况。

76 上述所有度量的结果应当在项目组的周报和里程碑阶段总结报告中明确地进行表述。必要时，增加对有关度量结果的说明和分析。这些工作必须形成制度，保证能够得到执行。
度量数据和计划数据之间不可避免会存在偏差。项目管理者要对照计划进行偏差分析。当偏差超过一定范围后，要采用修订计划、改进工作、调配资源等手段对工程过程进行调控。只有这样才能够保持开发工作能够在计划允许的偏差范围内不断推进。

77 通过度量与对比，有时会发现由于估算误差或后续变更等原因造成的偏差，项目中估算的规模、成本、进度等数据与工作实际相比存在过大的偏差，这时就有必要进行迭代估算，对计划进行再一次修订求精，确保计划反映实际情况。开发组织可以自行设定偏差阈值，决定究竟当偏差达到什么程度就必须进行重新估算并修订计划。 如果通过计划和工作过程度量数据的对比，发现由于资源缺口导致了进度滞后等情况，则应当通过资源调配，扭转工作滞后的局面。

78 当度量结果预示出某种风险已经实际发生时，应当启动抗风险措施，将风险带来的损失降到最小。
在根据度量结果对计划进行变更调整时，应当形成变更备忘录，通知所有有关系的小组和个人，并将其纳入配置管理库。凡是涉及到对外承诺的变更(如工期后延、追加预算)，必须经过高级管理人员审查核准后才能够进行。

79 14.8 小 结 保证软件项目的开发活动按照严格的、科学的计划有序地进行是现代软件工程的基本要求。计划的制定有赖于对项目需求的充分理解和对自身能力的客观评价。 对任务进行深入细致的分析，明确地界定任务范围与目标，全面地了解约束条件能够帮助我们解决“究竟要做什么”和“希望做到什么程度”的问题。以此为据，能够确定为完成目标所需要的环境资源、可重用构件资源和人力资源。

80 估算工作使得我们对任务的理解从定性层面进化到定量理解层面。利用直接度量或间接度量的模式，采用面向规模或者面向功能的方法，能够估算出任务的规模等制定计划所需要的基础数据。在估算的过程中，历史数据具有十分重要的作用。不了解自身的能力基线(例如生产率)，就无法保证估算的准确性。 在总结了大量项目经验的基础上，人们提出了一系列的基于经验模型的估算公式。其中，COCOMO模型的多层次估算方法具有明显的特征，得到了广泛的应用。

81 基于对主观能力和客观问题两方面的理解，我们能够按照选定的软件工程模型，制定出分阶段的软件工程计划，用作工程的指导方针。一个完备的软件开发计划，应当涵盖工程、测试、配置管理、品质保证各个方面，对项目规模、工程环节、开发进度、产品界定、成本分配、资源需求、风险防范都做出明确的描述，是有序开展工程活动的依据。使用甘特图等工具，有助于计划求精和细化，并能够使计划的可视性得到明显改善。 计划指导工程实践，工程实践又将验证计划的科学性与合理性。在工程过程中对计划的执行情况进行跟踪监督，是在实践中不断完善计划的必需，也是采集、积累实际度量数据，充实与完善度量基线的有效手段。

82 计划跟踪过程中不可避免地会出现偏差。造成偏差的原因包括估算失误、后期变更、工作过错和发生意外风险等等。正是由于通过跟踪发现了各类偏差，才使得我们能够对估算的准确度进行度量，在必要时进行重新估算并在新的基础上更新计划，或者调整工程实践活动中的不合理部分。 通过对本章的学习，希望读者能够初步掌握有关项目计划的基本知识，学会估算项目规模、工作量与成本等要素的方法，对度量工作和度量基线的作用与意义有一定的了解。