软件项目管理 第五章 软件项目成本管理 清华大学计算机系 殷人昆

项目成本管理是项目管理的一个重要组成部分，它是指在项目的具体实施过程中，为了保证完成项目所花费的实际成本不超过其预算成本而展开的项目成本估算、项目预算编制和项目成本控制等方面的管理活动。 必须要加强对项目实际发生成本的控制。一旦项目成本失控，就很难在预算内完成项目。 成本失控的情况常常是以下原因造成的： 成本估算和成本预算不够准确细致； 许多项目在成本估算、成本预算、成本控制方法上没有统一的标准可循。 思想上的误区：实际成本超出预算是必然的。

5.1 项目成本 1. 项目成本 一般项目的成本主要由项目直接成本、管理费用和期间费用等组成。 项目直接成本是指与项目有直接关系的成本费用。例如，直接人工费、直接材料费、其他直接费用等。 管理费用是指为了组织、管理和控制项目所发生的费用。例如，管理人员费用支出、差旅费、固定资产和设备使用费、办公费、医疗保险费，以及其他一些间接费用。

期间费用是指不受项目业务量增减影响的费用，如日常行政管理费、销售费等。 IT 软件项目由于项目自身的特点，对整个项目的预算和成本控制更为困难。项目经理为了控制整个项目的预算和支出，必须正确估算软件开发的成本费用。IT 软件项目的成本有 4 种： 硬件/支持软件成本：包括项目所需的所有硬件设备、系统软件、数据资源的购置、运输、储存、安装、测试的费用。对于进口设备，还要包括国外运费、保险费、进口关税和增值税等费用。 差旅及培训费：培训费用包括开发人员培训费和用户培训费。

软件开发成本：人工成本是最主要的软件开发成本。在软件开发项目中，付给软件工程师的人工费用占了开发成本的绝大部分。 项目管理费用：用于项目组织、管理、控制的费用支出。 尽管硬件/支持软件成本、差旅及培训费用可能在项目总成本中占较大的成本，但最主要的成本还是指在开发过程中所花费的工作量及相应的代价，它不包括原材料及能源的消耗。主要是人的劳动消耗。 IT软件项目的产品生产不是一个重复的制造过程，而是以“一次性”开发过程所花费的代价来

发成本。在软件开发项目中，付给软件工程师的人工费用占了开发成本的绝大部分。 项目管理费用：用于项目组织、管理、控制的费用支出。 尽管硬件/支持软件成本、差旅及培训费用可能在项目总成本中占较大的成本，但最主要的成本还是指在开发过程中所花费的工作量及相应的代价，它不包括原材料及能源的消耗。主要是人的劳动消耗。 IT 软件项目的产品生产不是一个重复的制造过程，而是以“一次性”开发过程所花费的代价来计算的。IT 项目开发成本的估算应以整个项目

软件开发全过程所花费的人工代价作为计算的依据，并可以按与软件生命周期对应的阶段进行估算。 2. 影响项目成本的因素 项目质量对成本的影响 质量对成本的影响，可以通过质量成本构成示意图表示。质量成本是由质量故障成本和质量保证成本构成的。 质量故障成本是指为了排除因产品量差而产生的故障，保证产品重新恢复功能的费用。质量保证成本是指为了保证和提高产品质量，采取

质量故障成本与质量保证成本是相互矛盾的。质量保证成本高，故障就少，质量故障成本就低。反之亦然。因此，需要建立一个动态平衡。 相应技术措施而消耗的费用。 质量故障成本与质量保证成本是相互矛盾的。质量保证成本高，故障就少，质量故障成本就低。反之亦然。因此，需要建立一个动态平衡。 质量总成本 质量保证成本 质量故障成本 质量 成 本

工期对成本的影响 项目费用由直接费用和间接费用组成。一般工期越长，项目的直接费用越低，而间接费用越高。反之，缩短工期，需要更多的、技术水平越高的工程师，直接成本费用就会增加。 项目总成本 项目工期 总成本 间接费用成本 直接费用成本

管理水平对成本的影响 高的管理水平可以提高项目预算的准确度，加强对项目预算的执行和监管。同时，对工期的控制严格限制在计划许可的范围内，对由于设计方案和项目计划的变更所造成的成本增加 / 减少和工期的变动，可以较为有效地控制。因此，管理水平对项目成本有关键影响。 人力资源对成本的影响 对于高技术能力、高技术素质的人才，其人力资源成本比较高，但可以产生高的生产率、高质量的产品、较短的工期等间接效果，从整体上会降低成本。

对于一般人员，还需要技术培训。对项目的理解及生产率相对低下，工期会延长，造成成本的增加。因此，人力资源是重要的影响因素。 价格对成本的影响 中间产品和服务、市场人力资源、硬件、软件的价格也对成本产生直接的影响。因为价格对项目成本预算的影响很大。

5.2 项目成本管理的内容 项目成本管理主要由项目资源计划的编制，成本估算，成本预算和成本控制等 4 个过程组成，下图给出了这些过程的主要框架。 以上四个过程相互影响、相互作用，有时也与外界的过程发生交互影响，根据项目的具体情况，每一过程由一人或数人或小组完成，在项目的每个阶段，上述过程至少出现一次。 某些项目，特别是小项目，资源计划、成本估算和成本预算三者紧密相连，可把这些过程视为一个过程处理（例如，当这些过程可由一个人在短时间内完成时）。

1. 输入 • 工作分解结构 • 历史资料 • 范围说明 • 资源库描述 • 组织策略 2. 工具与技术 • 专家判断 • 头脑风暴法 3 1. 输入 • 工作分解结构 • 历史资料 • 范围说明 • 资源库描述 • 组织策略 2. 工具与技术 • 专家判断 • 头脑风暴法 3. 输出 • 资源需求计划 1. 输入 • 工作分解结构 • 资源需求 • 资源单价 • 活动时间估计 • 历史资料 • 财务图表 2. 工具与技术 • 类比估计 3. 输出 • 成本估算 • 详细说明 • 成本管理计划 1. 输入 • 成本估算 • 工作分解结构 • 项目进度 2. 工具与技术 • 成本估算工具与方法 3. 输出 • 基准成本 项目成本管理 1. 输入 • 基准成本 • 执行情况 • 变更要求 • 成本管理计划 2. 工具与技术 • 成本变更控制系统 • 执行情况测量 • 另外的计划 • 项目管理软件 3. 输出 • 修改后成本估算 • 更新的预算 • 纠正措施 • 完成项目所需成本估算 • 经验与教训 成本控制 成本预算 成本估算 资源计划

5.3 资源计划 资源计划是确定为完成项目活动所需要的各种资源的种类、数量和时间，包括人力、财力和物力资源，完成资源的配置。 在任何项目中，资源并不是无限制的，也不是可以随时随地能够获取的，项目的成本、可起作用的技术水平、时间进度等都受到可支配资源的限制。在项目进展过程中，如何合理配置和优化资源使用，是项目管理的重要问题。

1. 资源计划编制过程的输入 工作分解结构WBS 它是编制资源计划所依据的最重要的基础，根据工作分解结构，明确完成项目各项工作的资源需求，编制项目资源需求计划。 历史信息 记录了以前类似项目的资源需求、项目资源计划、项目实施时实际耗费的资源等方面的有关情况。充分利用和借鉴相关历史信息来编制项目资源需求计划，可以提高资源需求计划的准确性，还可以减少编制的工作量。

范围说明 范围说明描述了项目工作，界定了项目目标。这两者均应在编制资源计划时考虑。 在编制资源计划时，必须逐项审查计划的资源需求能否满足项目的各项工作和项目目标的实现，对疏漏的资源需求要及时补充。 项目资源库描述 说明了在项目实施过程中具体有哪些资源可以利用，包括人员、设备、材料、资金等。 在制定项目资源技术时，必须从项目资源库中了解这些相关的资源供给信息，分析现有资源储备能否满足项目实施的需要。

组织策略 指有关人员的招聘，设备或材料的租赁或采购策略等。 2. 资源计划的工具与方法 专家判断法 由项目成本管理专家根据以往类似项目的历史信息和对当前项目的理解，经过严密思考计算，进行合理预测，制定项目资源计划。 这样的专家应具有专业知识和受过专门训练，可以从许多途径获得：

项目组织中的其他部门 咨询机构 专业技术协会 专家、顾问 定额法 当项目实施所需要的某些资源（包括人力、设备、材料等）有国家或行业的统一标准定额，或有权威部门制定的规则时，应以这些统一的定额或规则为标准来制定项目资源需求计划。 资料统计法 参考以往类似项目的历史统计数据资料，计算

它要求所采用的历史信息应与当前项目有可比性，并信息足够详细，有很强的可操作性。适合于创新性不强的项目。 并确定项目资源需求计划。 它要求所采用的历史信息应与当前项目有可比性，并信息足够详细，有很强的可操作性。适合于创新性不强的项目。 利用工作分解结构 根据工作分解结构所列出的项目全部工作的一览表，确定出每一项任务所需的各种资源，再将其汇总，编制出项目资源需求计划。这是最可行的一个方法。 资源均衡法 这是平衡各种资源在项目各个时期投入的一种常用方法。在保证项目完工时间不变的情况下

3. 项目资源计划编制的输出结果 编制项目资源计划的结果是编制出项目资源需求计划，对项目所需的各种资源的需求情况和使用计划给出详细的描述。 可以调整资源的需求情况，控制资源投入时间，尽可能均衡使用各种资源来满足项目要求的完工进度。 3. 项目资源计划编制的输出结果 编制项目资源计划的结果是编制出项目资源需求计划，对项目所需的各种资源的需求情况和使用计划给出详细的描述。 项目资源的需求安排应当分解落实到具体的工作任务上。

5.4 成本估算 项目成本估算是项目成本管理的核心内容。通过成本估算，分析并确定项目的估算成本，以此为基础进行项目的成本预算，进而展开对项目进行成本控制等一系列管理活动。 1. 项目成本估算的概念 项目成本估算是指为了实现项目目标，完成项目的各项活动，根据项目资源计划中确定的各种资源需求（人员、设备、材料等）和市场上各种资源的价格，对完成项目所必需的各种资源的费用作出近似的估算。

简言之，项目成本就是项目形成全过程所耗用的各种费用的总和。 项目定义与决策成本（可行性研究成本） 项目设计成本（项目设计所花费成本） 项目获得成本（为获取外部资源，如广告、招投标、询价等所花费成本） 项目实施成本（项目实施过程所花费的硬/软件设施与支持平台、人工、咨询成本以及一定数量的意外成本的总和）。 项目成本的耗费与项目所耗用资源的数量、质量和价格有关，与项目工期的长短有关，与项目结果的质量有关，与项目范围的广度／深度

有关。 项目成本估算的步骤： 识别与分析项目成本的构成要素。如人工费、咨询费、设备费、软件费等。 根据已识别的成本构成要素，估算每一个要素的成本。 分析成本估算的结果，找出可以互相补偿的成本，协调各种成本之间的比例关系。 例如，设计质量的提高可能会大量减少项目实施阶段的成本。因此，项目设计成本增加会带来项目实施成本的降低，两种成本之间存在互相补偿的关系。

2. 项目成本估算的依据 成本估算要以资源计划中所列的项目资源需求和项目组织对这些资源的预计价格为基础。 项目成本估算的依据为： 因此，在项目成本估算过程中，要积极寻找这种有补偿效应的成本，仔细研究成本之间的这种此消彼长的关系和量值对项目总成本造成的影响，努力使项目预期收益最大化。 2. 项目成本估算的依据 成本估算要以资源计划中所列的项目资源需求和项目组织对这些资源的预计价格为基础。 项目成本估算的依据为： 工作分解结构 资源需求计划：资源数量和质量标准 资源价格：市场价格或历史价格

3. 项目成本估算的方法 可以根据以往项目所积累的历史信息为基础进行项目成本估算。 项目持续时间：时间价值 经济形势：通货膨胀和利率 3. 项目成本估算的方法 可以根据以往项目所积累的历史信息为基础进行项目成本估算。 但项目之间总是存在一定差异，很少有简单重复，因此以往项目的成本只能作参考。 通常可以采用以下方法进行成本估算。

类比估算法 项目管理人员收集以往类似项目的有关历史信息，包括规模（代码行数或功能点数）、费用、人力、时间、物价等； 会同有关成本估算专家对当前项目的总成本进行估算； 将估算结果按照项目的工作分解结构的层次传递给直接下层的管理人员，由他们对自己负责的工作和活动的成本进行估算； 继续向下一层管理人员传递他们的估算结果，直到项目的基层人员。

这种方法又称“自顶向下估算法”，其主要思想是从项目的整体出发，首先进行类推，再做分解。 估算人员根据以前已完成的类似项目所消耗的总成本（总工作量），推算当前项目的总成本（总工作量），然后按比例将它分配到各工作分解单元中去，再来检验它是否能满足要求。分解比例参看下表。 优点是简单易行，花费少。当项目详细资料难以得到时，这种方法行之有效。 缺点是类似项目很难找，估算准确度较差。对项目中的特殊困难估计不足。

工料列表法 基层管理人员计算出每个工作单元的生产成本； 将各个工作单元的生产成本自下向上逐级累加，汇总到项目的高层管理者； 项目的高层管理人员计算出项目的总成本。 这种估算方法又称“自底向上估算法”。依据项目的工作分解结构，先“分解”，再对每个分解后的工作单元采取“类比”或其他方法进行估算，最后汇总。 优点是结果十分详细，准确性高。

缺点是实际操作非常耗时，费用较高。而且通常估算值缺少各项子任务之间相互联系所需要的工作量，还缺少许多与项目实施有关的管理工作量. 从心理学角度，通常会陷于一种恶圈：进行第一轮估算的基层管理人员会认为上级管理人员会以一定比例削减他们的成本估算，他们会过高估算自己工作的资源需求。基于这种情况，上层管理人员真的会认为应该削减估算的成本，这又恰恰证实了基层管理人员的怀疑。

参数模型法 利用项目的一些特性参数（如代码行或功能点）建立数学模型来估算项目成本。 这种方法有一组项目成本估算关系式，用它们对项目总成本作出近似估算。 这种估算只针对影响项目总成本程度最大的成本变量进行估算，不考虑一些细节性成本因素。 例如，考虑建立一个局域网系统的项目成本，先估算建造一个标准节点的成本作为系数因子，以标准节点数作为变量因子，两者相乘，得到项目的总成本。

优点是用这种方法估算项目成本的速度很快，只需要一小部分信息。 缺点是不同的估算模型估算出的结果差异较大，因此，选择合适的模型以保证估算结果的准确性至关重要。 为保证项目成本模型的适用性，在建立成本模型时，要注意： 保证建立参数模型时所依据的历史信息的准确性； 模型中的一些重要参数必须量化处理。 根据项目的实际情况，对参数模型可按适当的比例调整。

4. 项目成本估算的结果 项目成本估算结果文件 它以摘要或详细的形式描述了： 利用项目成本管理软件 利用项目成本管理软件，可以通过直接输入与项目成本有关的数据，或自定义项目成本函数，计算出项目成本的估算结果。 目前几乎所有大型项目的成本估算，都是利用这类项目成本估算软件计算得到的。 4. 项目成本估算的结果 项目成本估算结果文件 它以摘要或详细的形式描述了： 实施项目必须的所有资源（人员、资金、硬/软件工具、可复用构件等），以及这些

资源的数量、质量标准、成本。 为应付项目可能遇到的意外事件（通货膨胀、意外事故、原材料失窃等）所支付的具有不可预见性的意外成本。 成本估算结果通常用货币量单位“元”表示，但有时为了管理方便，用工作量“人日”或“人月”来表示。 相关支持性细节文件和结果 它对项目成本估算的依据进行详细说明。 项目工作范围说明。 项目成本估算的基础和依据（采用的估算

方法、参考的国家有关规定、各种中间计算的结果等）。 项目成本估算的假设（项目所需资源价格水平的估计、项目资源消耗定额的估计、项目实施人员的生产率等）。 项目成本估算结果的误差范围。 项目成本管理计划 通常，在项目管理中用成本目标衡量项目绩效。但在项目开始后，会发生各种无法预见的情况，随时可能危及项目成本目标的实现。例如，人员流失、设备购进渠道不通、支持工具有缺陷等。

为实现在成本目标范围内完成项目可交付成果，必须对如何管理和控制项目成本变动的方案进行事先安排，即“有备无患”。 管理计划的主要内容： 识别并分析可能出现的各种意外事件； 预测可能会发生损失的概率和程度； 说明如何对费用偏差进行管理和如何对意外成本的使用进行管理； 提出计划和解决方案。

5.5 软件项目的成本估算 软件项目管理过程开始于项目计划。在做项目计划时，第一项活动就是估算。 常用的估算技术是对需要的人力（以人月为单位）、项目持续时间（以年份或月份为单位）、成本（以元为单位）做出估算。 这种估算大多是利用以往类似项目的花费做为参考而做出的。 如果新项目与以前的一个项目在大小上和功能上十分类似，则新项目需要工作量、开发持续时间、成本大致与那个老项目相同。

假使项目背景完全生疏，只凭过去的经验做出估算可能就不够了。 现在已有了许多用于软件开发的估算技术。其共同特点是： 事先建立软件范围； 以软件度量（以往的度量）为基础，以做出估算； 项目被分解为可单独进行估算的小块。

1. 软件的工作范围 软件的工作范围即软件范围。包括：功能、性能、限制、接口和可靠性。 估算开始时应对软件功能进行评价，对其进行适当的细化以便提供更详细的细节。由于成本和进度的估算都与功能有关，因此常采用某种程度的功能分解。 性能的考虑包括处理时间和响应时间的需求。 限制则标识产品成本、外部硬件、可用存储或其他现有系统对软件的限制。 功能、性能和限制必须在一起进行评价。

当性能要求不同时，为实现同样的功能，开发工作量可能相差一个数量级。 还要叙述某些质量因素（例如，给出的算法是否容易理解等）。 软件与其它系统元素是相互作用的。要考虑每个接口的性质和复杂性，以确定对开发资源、成本和进度的影响。接口的概念可解释为： 运行软件的硬件 (如处理机与外设) 及间接受软件控制的设备 (如机器、显示器); 必须与新软件连接的现有的软件 (如数据库存取例程、子程序包、操作系统);

2. 软件开发中的资源 通过终端或其他输入／输出设备使用该软件的人; 该软件运行前后的一系列操作过程。 对于每一种情况，都必须清楚地了解通过接口的信息转换。 2. 软件开发中的资源 软件开发所需的资源有: 开发环境 — 硬件工具及软件工具 — 提供支持开发的基础. 可复用软件构件 — 软件构造块. 人员 — 主要资源

通常，对每一种资源，应说明以下四个特性： 资源的描述; 资源的有效性说明; 资源在何时开始需要; 使用资源的持续时间。 最后两个特性统称为时间窗口。 人员 可复用构件 硬件/软件工具 人员 需要的技能, 可用性 开始时间, 工作期限 硬件 开发系统, 目标机器, 新系统其他硬件部分 软件 支持软件 可用性,投入时间,持续时间

1) 人力资源 在考虑各种软件开发资源时，人是最重要的资源。在安排开发活动时必须考虑人员的技术水平、专业、人数、以及在开发过程各阶段中对各种人员的需要。 计划人员首先估算范围并选择为完成开发工作所需要的技能，然后在组织（如经理、系统分析员、软件设计师等）和专业（如网络、数据库、系统体系结构）两方面做出安排。 对于相对比较小的项目（一个人年或更少），一个人就能完成所有软件开发工作，可在必要时咨询专家。

对一些规模较大的项目，在整个项目生命周期中，各种人员参与情况不同。下面是各类不同人员随开发进展在各个阶段参与情况的曲线。 管理人员 初级技术人员 高级技术人员 高 人员参与程度 计 划 需求分析 概要设计 详细分析 程序编码 单元测试 集成测试 确认测试

2) 可复用构件库 为了促成软件的复用，以提高软件生产率和产品质量，可建立可复用的软件构件库。 Bennatan建议将软件资源分为 4 类： 成品构件：由第三方厂商开发或在以前的项目中开发，经过严格测试确保无误的软件，通常称为COTS (commercial off-the-shelf)。 具有完全经验的构件：现有的为以前类似的项目建立的规格说明、设计、代码或测试数据。由于当前项目的成员在这些构件所代表的应用领域中有丰富的经验，应用这类有完全经验的构件时风险较小。

具有部分经验的构件：现有的为以前项目建立的规格说明、设计、代码或测试数据。这些项目与当前的项目相关，但需做实质上的修改。由于当前项目的成员在这些构件所代表的应用领域中仅有有限的经验，因此对于这类有部分经验的构件进行修改会有相当程度的风险。 新构件：项目组为满足当前项目的特殊需要而必须专门开发的软件构件。 最好能尽早说明软件的资源需求，这样才能进行软件可选方案的技术评估，并及时获得所需的构件。

3) 硬件资源 硬件是作为软件项目的一种工具而投入的。 宿主机（Host）─ 软件开发时使用的计算机及外围设备； 目标机（Target）─ 运行已开发成功软件的计算机及外围设备； 其他硬件设备 ─ 专用软件开发时需要的特殊硬件资源； 宿主机和必要的软件工具构成软件开发环境。这样的开发环境能够支持多种用户的需要，且能保持大量的由软件开发组成员共享的信息。 宿主机与目标机可以是同一种机型。

4) 软件资源 软件人员在软件开发过程中使用了许多软件工具。将这些软件工具集成就叫做计算机辅助软件工程 (CASE)。 业务系统计划工具集 项目管理工具集 支持工具 ─ 文档生成工具、网络系统软件、数据库、电子邮件、通报板，以及配置管理工具。 分析和设计工具 编程工具 集成和测试工具

3. 软件度量 原型化和模拟工具 维护工具 框架工具 ─ 这些工具能够提供建立集成项目支撑环境（IPSE）的框架。 软件项目估算的依据是对以往项目进行度量所得到的有关工作量和时间的数据。 只要事先建立特定的度量规程，很容易做到直接度量软件所需要的成本和工作量、产生的代码行数等。 软件项目度量分为面向规模和面向功能度量：

1) 面向规模的度量 面向规模的度量是对软件产品和软件开发过程的直接度量。 可以建立一个面向规模的数据表格来记录项目的某些信息。该表格列出了在过去几年完成的每一个软件开发项目和关于这些项目的相应面向规模的数据。 例如，项目aaa-01的规模为 12.1 KLOC (千代码行)，工作量用了 24 个人月，成本为168,000元，文档为 365 页，在交付用户使用后第一年内发现了 29 个错误，有 3 个人参加了项目 aaa-01 的软件开发工作。

面向规模的数据表格 项目 工作量 千元 KLOC 文档页数 错误数 人数 … … … … … … … aaa-01 24 168 12.1 365 29 3 ccc-04 62 440 27.2 1224 86 5 fff-03 43 314 20.2 1050 64 6 … … … … … … …

需要注意的是，在表格中记载的工作量和成本是整个软件工程的活动（分析、设计、编码和测试），而不仅仅是编码活动。 对于每一个项目，可以根据表格中列出的基本数据计算简单的面向规模的生产率和质量的度量。 生产率 ＝ KLOC／PM（人月） 质量 ＝ 错误数／KLOC 成本 ＝ 元／LOC 文档 ＝ 文档页数／KLOC

2) 面向功能的度量 面向功能的软件度量是对软件和软件开发过程的间接度量。 面向功能度量主要考虑程序的“功能性”和“实用性”，而不是对 LOC计数。 该度量是一种叫做功能点方法的生产率度量法，利用软件信息域中的一些计数和软件复杂性估计的经验关系式而导出功能点 FP。

面向功能的数据表格 加 权 因 数 简单 中间 复杂 加权计数 信息域参数 计数 用户输入数  3 4 6 = 用户输入数  3 4 6 = 用户输出数  4 5 7 = 用户查询数  3 4 6 = 文 件 数  7 10 15 = 外部接口数  5 7 10 = 总 计 数 计数 加 权 因 数 简单 中间 复杂 加权计数

功能点计算 确定五个信息域的特征，并在表格中相应位置给出计数。 用户输入数：各个用户输入是面向不同应用的输入数据。 用户输出数：各个用户输出是面向应用的输出信息，包括报告，屏幕信息，错误信息等。在报告中的各个数据项不应再分别计数。 用户查询数：查询是一种联机的交互操作，每次询问/响应具备应计数。

文件数：每一个逻辑的主文件（即数据的逻辑组合）都应计数。它可以是一个大数据库的一部分，也可以是一个单独的文件。 外部接口数：与系统中其他设备（如磁盘文件）通过外部接口读写信息次数均应计数。 一旦收集到上述数据，下一步确定与每一个计数相关的复杂性值（加权因子）。 一个信息域是简单、平均还是复杂，由使用功能点方法的机构自行确定，从而计算出加权计数。 计算功能点，使用如下的关系式： FP ＝ 总计数×( 0.65＋0.01×SUM( Fi ) ) 总计数是所有加权计数项的和；

SUM( Fi ) 是求和函数: Fi（i＝1..14）是复杂性校正值，它们通过逐一回答如下提问来确定。 境中？ F6 系统是否需要联机数据项？ F7 联机数据项是否需要建立多重窗口显示和切 换，以完成处理输入处理。

F8 主文件是否联机更新？ F9 输入、输出、文件、查询是否复杂？ F10 内部处理过程是否复杂？ F11 是否需要将程序代码设计成可复用的？ F12 设计中是否包括了转移和安装？ F13 系统是否设计成可以重复安装在不同机构中? F14 系统是否设计成易修改和易使用？ 每个问题的回答按复杂性校正值给出(0～5)。 复杂性校正值 Fi 的取值0..5： = 0 没有影响 = 1 偶然的 = 2 适中的 = 3 普通的 = 4 重要的 = 5 极重要的

一旦计算出功能点，就可仿照LOC的方式度量软件的生产率、质量和其它属性： 生产率 ＝ FP／PM（人月） 质量 ＝ 错误数／FP 成本 ＝ 元／FP 文档 ＝ 文档页数／FP 功能点度量是为了商用信息系统应用而设计的。

特征点度量（Feature Points）可以用于系统和工程软件应用 特征点度量适合于算法复杂性高的应用。而实时处理、过程控制、嵌入式软件应用的算法复杂性都偏高，因此适合于特征点度量。 为了计算特征点，可以象功能点计算那样，对信息域值进行计数和加权。此外，特征点度量要对一个新的软件特征 “算法” 进行计数。 计算特征点可使用一个计算表格。对于每一个度量参数只使用一个权值，并且使用 FP＝总计数×( 0.65＋0.01×SUM( Fi ) ) 来计算总的特征点值。

特征点度量计算表格 度量参数 计数 权值 加权计数 用户输入数  4 = 用户输出数  5 = 用户查询数  4 = 度量参数 计数 权值 加权计数 用户输入数  4 = 用户输出数  5 = 用户查询数  4 = 文 件 数  7 = 外部接口数  7 = 算 法  3 = 总 计 数

3) 协调不同的度量方法 代码行数和功能点之间的关系依赖于用来实现软件的程序设计语言和设计质量。 下面给出使用各种程序设计语言建立一个功能点所需要的平均代码行数的粗略估算。

4. 软件项目估算 在估算时往往存在某些不确定性，使得项目管理者无法正常进行管理而导致产品迟迟不能完成。 项目复杂性对于增加软件计划的不确定性影响很大。复杂性越高，估算的风险就越高。 项目规模对于软件估算的精确性和功效影响也比较大。随着软件规模的扩大，问题分解会更加困难。项目的规模越大，开发工作量越大，估算的风险越高。 项目的结构化程度也影响项目估算的风险。随着结构化程度的提高，进行精确估算的能力就能提高，而风险将减少。

历史信息的有效性也影响估算的风险。对以往项目进行综合度量，可借用来比较准确地进行估算，安排进度以避免重走过去的弯路，而总的风险也减少了。 如果对软件项目的工作范围还不十分清楚，或者用户的要求经常变更，都会导致对软件项目所需资源、成本、进度的估算频频变动，增加估算的风险。 计划人员应当要求在软件的规格说明中给出完备的功能、性能、接口的定义。 软件项目的估算能够通过一系列系统化的步骤，在可接受的风险范围内提供估算结果。

估算对风险的影响 低风险区 项目复杂性 项目结构化、规约 的不确定程度 项目工作量大小

1) 使用LOC和FP估算 在软件项目估算中，在两个方面使用了LOC和FP数据： 给出一个有界的软件范围的叙述 由此叙述把软件分解成一些小的可分别独

立进行估算的子功能 对每一个子功能估算LOC或FP 把基线生产率度量(如 LOC/PM 或 FP/PM) 用做特定的估算变量，导出子功能的成本或工作量 综合子功能的估算得到整个项目的总估算。 用 LOC 做为估算变量时，必须进行功能分解, 且需要达到很详细的程度。而估算 FP 时需要的数据是宏观的量，当把 FP 当做估算变量时不需分解得很详细。

LOC 是直接估算的, 而 FP 是通过估计输入、输出、数据文件、查询和外部接口的数目，以及 14 种复杂性校正值间接地确定的。 项目计划人员可对每一个分解的功能提出一个有代表性的估算值范围。 利用历史数据或凭实际经验（当其它的方法失效时），对每个功能分别按最佳的、可能的、悲观的三种情况给出 LOC 或 FP 估计值。记作a、m、b。 接着计算LOC或FP的期望值 E。 E ＝ （a＋4m＋b）／6

所有子功能的总估算变量值除以相应于该估算变量的平均生产率度量得到项目的总工作量。 例如，若假定总的 FP 估算值是 310，基于过去项目的平均 FP 生产率是 5.5FP／PM，则项目的总工作量是： 工作量 ＝ 310／5.5 ＝ 56 PM 作为LOC和FP估算的实例，考察一 个为CAD应用而开发的软件包。 系统定义评审指明，“软件是在一个工作站上运行，其接口必须使用各种计算机图形设备，包括鼠标器、数字化仪、高分辩率彩色显示器和激光打印机。”

在这个实例中，使用 LOC 做为估算变量。 根据系统规格说明, 软件范围的初步叙述如下 “软件从操作员那里接收 2 维或 3 维几何数据。 操作员通过用户界面与 CAD 系统交互并控制它，这种用户界面将表现出很好的人机接口设计特性。所有的几何数据和其它支持信息保存在一个CAD数据库内。要开发一些设计分析模块以产生在各种图形设备上显示的输出。软件要设计得能控制并与能各种外部设备，包括鼠标器、数字化仪、激光打印机和绘图仪交互。”

经过分解, 识别出下列主要软件功能： 用户界面和控制功能 二维几何分析 三维几何分析 数据库管理 计算机图形显示功能 外设控制PC 设计分析模块 通过分解，可得到如下估算表

功能 a 乐观值 m 可能值 b 悲观值 E 期望值 元/行 行/PM 成本 (元) 工作量 (PM) 用户接口控制 1800 2400 2650 2340 14 315 32760 7.4 二维几何造型 4100 5200 7400 5380 20 220 107600 24.4 三维几何造型 4600 6900 8600 6800 136000 30.9 数据库管理 2950 3400 3600 3350 18 240 60300 13.9 图 形 显 示 4050 4900 6200 4950 22 200 108900 24.7 外部设备控制 2000 2100 2450 2140 28 140 59920 15.2 设计分析 6600 8500 9800 8400 300 151200 28.0 总 计 33360 656680 144.5

从历史的基线数据求出生产率度量，即行／PM和元／行。 需要根据复杂性程度的不同，对各功能使用不同的生产率度量值。 在表中的成本 = LOC的期望值 E与元／行相乘，工作量 = 用LOC 的期望值 E与行／PM相除。 因此可得，该项目总成本的估算值为657,000元，总工作量的估算值为145人月（PM）。

2) 项目人工成本的估算 项目人工成本主要是指软件开发过程中所花费的工作量及相应的代价。它不包括原材料和能源的消耗，主要是人的劳动的消耗。人的劳动消耗所需代价就是软件产品的人工成本。 项目人工成本的计算方法不同于其它物理产品成本的计算，是以一次性开发过程所花费的代价来计算的。 项目人工成本的估算，应是从软件计划、需求分析、设计、编码、单元测试、集成测试到确认测试，整个软件开发全过程所花费的代价作为依据的。

3) 软件项目成本估算方法 — 专家判定技术 单独一位专家可能会有种种偏见，最好由多位专家进行估算，取得多个估算值。 有多种方法把这些估算值合成一个估算值: 一种方法是简单地求各估算值的中值或平均值。其优点是简便。缺点是可能会由于受一、二个极端估算值的影响而产生严重的偏差。 另一种方法是召开小组会，使各位专家们统一于或至少同意某一个估算值。优点是可以摈弃蒙昧无知的估算值，缺点是一些组员可能会受权威或政治因素的影响。

Delphi技术 标准Delphi技术 组织者发给每位专家一份软件系统规格说明书和一张记录估算值的表格，请他们进行估算。 专家详细研究软件规格说明书的内容，对该软件提出三个规模的估算值，即：ai (最小), mi (可能), bi (最大)，无记名地填写表格； 组织者对专家们在表格中的答复进行整理： a. 计算各专家估算的期望值 Ei; b. 对专家的估算结果分类摘要。

专家对此估算值另做一次估算。 在综合专家估算结果的基础上，组织专家再次无记名地填写表格。比较两次估算的结果。若差异很大，要通过查询找出差异的原因。 上述过程可重复多次。最终可获得一个得到多数专家共识的软件规模 (源代码行数)。 最后，通过与历史资料进行类比，根据过去完成软件项目的规模和成本等信息，推算出该软件每行源代码所需要的成本。然后再乘以该软件源代码行数的估算值，就可得到该软件的成本估算值。

5. 软件项目人工成本估算的经验模型 软件开发人工成本估算是依据开发成本估算模型进行估算的。 开发成本估算模型采用经验公式来预测软件项目计划所需要的成本、工作量和进度数据。 根据模型中估算变量的依存关系，可把模型分为静态模型和动态模型。 静态模型从一个唯一的估算变量（如源代码规模）计算其他变量（如工作量和时间），且所有计算公式对于所有场合都一样。 动态模型中所有变量是相互依存的。

1) 静态单变量估算模型 典型的静态单变量估算模型是通过对从以前的软件项目收集到的数据进行回归分析导出的。其总体结构具有以下形式： 根据基本估算变量的多少，模型又可分为单变量模型和多变量模型。 单变量模型只用一个估算变量计算出其他所有变量；多变量模型需要多个变量来描述过程。 1) 静态单变量估算模型 典型的静态单变量估算模型是通过对从以前的软件项目收集到的数据进行回归分析导出的。其总体结构具有以下形式： E = A+B*(ev)C 其中，E 是以人月为单位的工作量，A、B、C是经验常数，ev是估算变量（LOC或FP）.

(1) 面向LOC的估算模型 E＝5.2(KLOC)0.91 Walston-Felix模型 E = 5.5+0.73(KLOC)1.16 Bailey-Basili模型 E＝3.2(KLOC)1.05 Boehm基本模型 E＝5.288(KLOC)1.047 Doty模型 （针对 KLOC > 9 的情况） 除上述关系以外，大多数估算模型均有某种形式的项目调整措施，使得 E 能够根据其他的项目特性（如问题的复杂性、开发人员的经验、开发环境等）加以调整。

(2) 面向FP的估算模型 E＝-13.39+0.0545FP Albrecht-Gaffney模型 E = 60.627.72810-8 FP3 Kemerer模型 E＝585.7+15.12FP Maston-Barnett-Mellichamp模型 从以上模型可知，每一个模型对于相同的 LOC或 FP 值，会产生出不同的结果。 这意味着使用这些估算模型时，必须根据当前项目的需要，对模型加以调整。

2) Putnam模型 Putnam 模型是一种动态多变量模型。适用于大型项目，也可用在一些较小的软件项目中。 它是假定在软件开发的整个生存期中工作量有特定的分布。大型软件项目的开发工作量分布可以用 Rayleigh-Norden 曲线表示。 用该曲线可以导出一个“软件方程”： td 是开发持续时间 (年)， K是整个软件生命周期的工作量 (人年)，L是源代码行数 (LOC)，Ck是技术状态常数，因开发环境而异。

系统定义 功能设计 规格说明 系统开发 系统维护与支持 工作量（人月） 时间 安装 测试与确认 设计与编码 开发工作 = 总工作量的40% 维护与支持工作 = 总工作量的60%

技术状态常数Ck的取值 Ck的 典型值 开发 环境 开 发 环 境 举 例 2000 差 没有系统的开发方法，缺乏文档和复审，批处理方式。 8000 好 有合适的系统开发方法，有充分的文档和复审，交互执行方式。 11000 优 有自动开发工具和技术

3) COCOMO模型 （COnstructive COst MOdel） 结构型成本估算模型是一种精确、易于使用的成本估算方法。 DSI (Delivered Source Instruction) 定义为代码的源程序行数。若一行有两个语句，则算做一条指令。它包括作业控制语句、格式语句和数据声明，但不包括注释语句。 KDSI＝1024 DSI MM (Man-Months) 表示开发工作量（人月）。 TDEV (Time of Development) 表示开发进度。它由工作量决定（月）。

(1) COCOMO模型的限制 模型成本估算涵盖的开发期，开始于产品设计阶段之初，终止于集成与测试阶段之末。其他阶段的成本和进度单独估算。 模型成本估算仅包含在开发期间工作分解结构中的活动，其中包含了管理和文档编制的工作量，但不包含用户培训、安装计划、移植计划等相关工作量。 模型估算包括了项目中所有直接计费的劳动力的活动，包括项目经理和程序库管理员，但不包括计算中心操作员、人事部门职员、秘书、高层管理人员、房屋管理员等。

(2) COCOMO模型中项目的分类 软件项目开发模式 组织型 半独立型 嵌入型 产品目标的系统理解 充分 很多 一般 有关工作的经验 大量 特 性 组织型 半独立型 嵌入型 产品目标的系统理解 充分 很多 一般 有关工作的经验 大量 适中 对需求一致性的要求 基本 对外部接口说明一致性的要求 有关新硬件和操作程序的并行开发 若干 大范围 对创新的数据处理架构和算法的需求 最低 提前完成时的奖金 低 高 产品范围的规模 < 50 KDSI < 300 KDSI 所有规模

COCOMO模型分类 COCOMO模型按其详细程度分成三级： 基本COCOMO模型 中间COCOMO模型 详细COCOMO模型 软件项目开发模式 应用举例 组织型 半独立型 嵌入型 分批数据处理 简单库存/生产管理 熟悉的OS, 编译器 科学模型 多数事务处理系统 简单指令控制系统 新的OS, DBMS 大的库存/生产管理 复杂事务处理系统 超大型操作系统 航天控制系统 大的指令控制系统 COCOMO模型分类 COCOMO模型按其详细程度分成三级： 基本COCOMO模型 中间COCOMO模型 详细COCOMO模型

基本 COCOMO 模型是静态单变量模型，用源代码行数(KDSI) 为自变量的经验函数计算软件开发工作量。 详细 COCOMO 模型包括中间COCOMO模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中每一阶段（分析、设计等）的影响。

(3) 基本COCOMO模型 基本COCOMO模型的标称工作量和进度公式 按这些公式得到的估算实例参看下表。它总结了每一种软件项目开发模式和不同规模产品中估算出来的工作量、生产率、开发进度等。 产品规模：小型(2KDSI), 中小型(8KDSI), 中型(32KDSI), 大型(128KDSI), 超大型(256KDSI)。

标准规模产品的基本COCOMO估算 工作量(MM) 小型 中小型 中型 大型 超大型 组织型 半独立型 嵌入型 5.0 6.5 8.3 21.3 31 44 91 146 230 392 687 1216 3250 6420 生产率(DSI/MM) 小型 中小型 中型 大型 超大型 组织型 半独立型 嵌入型 400 308 241 376 258 182 352 219 139 327 186 105 158 80

进度(月) 小型 中小型 中型 大型 超大型 组织型 半独立型 嵌入型 4.6 4.8 4.9 8.0 8.3 8.4 14 24 42 41 平均投入人员 (FSP) 小型 中小型 中型 大型 超大型 组织型 半独立型 嵌入型 1.1 1.4 1.7 2.7 3.7 5.2 6.5 10 16 29 51 77 157

(4) 中间COCOMO模型 进一步考虑 15 种影响工作量的因素（称成本驱动因素），通过定下乘法因子，修正COCOMO 标称工作量公式和进度公式计算的结果，可以更合理地估算软件（各阶段）的工作量和进度。 中间 COCOMO 模型的标称工作量与进度公式 计算公式：MM = a (KDSI) b  EAF

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

成本驱动因素 fi 产品因素：软件可靠性、数据库规模、产品复杂性 硬件因素：执行时间限制、存储限制、虚拟机易变性、环境周转时间 人的因素：分析员能力、应用领域实际经验、程序员能力、虚拟机使用经验、程序语言使用经验 项目因素：现代程序设计技术、软件工具的使用、开发进度限制

虚拟机是指为完成某一软件任务所使用硬、软件的结合。 成本驱动因素 fi 很低 低 正常 高 很高 超高 产品因素 软件可靠性 0.75 0.88 1.00 1.15 1.40 数据库规模 0.94 1.08 1.16 产品复杂性 0.70 0.85 1.30 1.65 计算机因素 执行时间限制 1.11 1.66 存储限制 1.06 1.21 1.56 虚拟机易变性 0.87 环境周转时间 1.07 虚拟机是指为完成某一软件任务所使用硬、软件的结合。

成本驱动因素 fi 很低 低 正常 高 很高 超高 人员因素 分析员能力 1.46 1.00 0.86 0.71 应用领域经验 1.29 1.13 0.91 0.82 程序员能力 1.42 1.17 0.70 虚拟机使用经验 1.21 1.10 0.90 程序语言经验 1.41 1.07 0.95 项目因素 先进编程技术 1.24 使用软件工具 0.83 开发进度限制 1.23 1.08 1.04

例2. 一个规模为10KDSI 的商用微机远程通信的嵌入型软件，使用中间COCOMO模型进行成本估算。 程序标称工作量 MM ＝ 2.8 (10)1.20 ＝ 44.38（MM） 程序实际工作量 MM ＝ 44.38× ＝ 44.38×1.17 ＝ 51.5（MM） 开发所用时间 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 ＝1.84 （月） S ＝ 0.54 (42.27)0.60 ＝ 5.1 (人)

(5) 详细COCOMO模型 详细COCOMO模型的标称工作量公式和进度公式与中间COCOMO模型相同。 阶段敏感的工作量影响因素：把软件开发分为 4 个阶段：需求计划和产品设计、详细设计、编码和单元测试、集成与测试。 三层次的产品分级结构：针对每一个影响因素，按模块层、子系统层、系统层，有相应工作量因素分级表，供不同层次的估算使用。

两者综合，每张表都按产品层次-开发阶段-要求高低，详细给出定量的估计。 例如，软件可靠性（RELY）的工作量因素分级表（子系统层）和产品复杂性（CPLX）的工作量因素分级表（模块层）如表所示。 使用这些表格，可以比中间COCO MO模型更方便、更准确地估算软件开发工作量。

软件可靠性成本驱动因素分级表 (子系统层) 阶段 级别 需求和 产品设计 详细设计 编程和 单元测试 集成 及测试 综合 非常低 0.80 0.60 0.75 低 0.90 0.88 正常 1.00 高 1.10 1.30 1.15 非常高 1.70 1.40

产品复杂性成本驱动因素分级表 (模块层) 阶段 级别 需求和 产品设计 详细设计 编程和 单元测试 集成 及测试 综合 非常低 0.70 低 0.85 正常 1.00 高 1.15 非常高 1.30

可靠性要求不同导致项目活动的差异 等级 需求与产品设计 详细设计 编码与单元测试 集成与测试 很低 不详细; 很多待定; 较少确认; 最小量QA, CM, 用户手册草稿,测试计划; 最少设计评审; 基本设计信息; 最小量QA, CM,用户手册草稿,测试计划; 非正式设计检查; 没有测试过程; 最小路经测试; 最小标准检查; 最小QA, CM; 最小I/O与非正式测试; 最小用户手册; 很多需求未经测试； 最小压力与非正常测试; 最小所需文档； 低 基本信息,确认; 频繁的待定; 基本QA, CM, 标准用户手册草稿, 测试计划; 中等详细; 基本QA, CM,用户手册草稿,测试计划; 最小测试过程; 部分路径测试,标准检查; 基本QA, CM, 用户手册; 部分I/O与非正常测试; 需求通常未经测试; 部分压力与非正常测试;

等级 需求与产品设计 详细设计 编码与单元测试 集成与测试 正常 正常项目V&V 高 详细的确认, QA, CM, 标准, 设计评审, 文档编制; 详细的测试计划, 过程; 详细的确认, QA, CM, 标准, 关键设计评审, 文档编制; 详细的测试过程, QA, CM, 文档化; 广泛的非正常测试; 广泛的压力与非正常测试; 很高 与独立的V&V机构接口; 非常详细的测试计划, 过程; 非常彻底的设计检查; 非常彻底的代码检查; 非常广泛的非正常测试; 非常详细的测试过程, QA, CM, 文档化; 非常广泛的压力与非正常测试;

4) COCOMO-II模型 COCOMO模型适用于专用的定制的软件项目。1997年 Boehm 等人提出来的 COCOMO-II 模型则适用于广泛汇集各种技术的软件项目，如商用软件、面向对象软件、通过螺旋型或演化型开发模型制作的软件。 COCOMO-II 模型通过三个不同的模型分别对三个不同的阶段进行估算： 应用组合模型（用于早期原型） 更详细的早期设计模型 后续的后架构模型

(1) 应用组合模型 该模型用于估算原型制作的工作量。 适用场合如：用户界面的原型开发，软件和系统交互考虑，性能评估和技术成熟度评价等。 模型使用“对象点”，而不用“源代码行”进行估算。 对象点是由纽约大学Leonard N. Sterm商学院提出的。它类似于功能点，是一种软件间接度量。根据（用户界面）屏幕数、报表数、建造应用可能需要的3GL构件数来计数。 屏幕数、报表数和3GL构件数统称为对象。

表1 屏幕对象点复杂性等级 每一个对象可以被分为简单的、中等的、困难的三个类型之一。 数据表 的数量和来源 包含的视图数 总数 < 4 表1 屏幕对象点复杂性等级 数据表 的数量和来源 包含的视图数 总数 < 4 ( < 2个服务器, < 3个客户机 ) 总数 < 8 ( < 3个服务器, < 3~5个客户机 ) 总数  8 ( > 3个服务器, > 5个客户机 ) < 3 简单的 中等的 3 ~ 7 困难的  8

表2 报表对象点复杂性等级 复杂性要根据客户机、服务器数据表的数量和来源，屏幕或报表的视图或部分的数量而定。 数据表 的数量和来源 表2 报表对象点复杂性等级 数据表 的数量和来源 包含的部分数 总数 < 4 ( < 2个服务器, < 3个客户机 ) 总数 < 8 ( < 3个服务器, < 3~5个客户机 ) 总数  8 ( > 3个服务器, > 5个客户机 ) < 2 简单的 中等的 2 ~ 3 困难的  4 复杂性要根据客户机、服务器数据表的数量和来源，屏幕或报表的视图或部分的数量而定。

表3 对象点复杂性加权 一旦确定了屏幕、报表和3GL构件的相应计数，以及复杂性，参照表 3 加权，以调整工作量。 表3 对象点复杂性加权 简单的 中等的 困难的 屏幕 1 2 3 报表 5 8 3GL构件 - 10 复 杂 性 加 权 对象类型 一旦确定了屏幕、报表和3GL构件的相应计数，以及复杂性，参照表 3 加权，以调整工作量。 将各个对象的加权计数累加，得到总的对象点计数。

如果开发中使用了构件或复用了以前的软件，再估计复用的百分比 r。 通过以下公式得到调整后的对象点计数（称为新对象点NOP） NOP = (对象点计数)×(100 - r) / 100 例如，一个应用程序包含 840 个对象点，其中20%可以通过使用现成的构件来提供，那么调整后的新对象点（NOP）的得分将是 NOP = 840 ×(100 - 20) / 100 = 672 为了基于新对象点估算工作量，考虑“生产率”这一概念，其单位是: PROD = NOP/人月

开发者的经验和能力 / 开发环境成熟度和能力 对象点/工作量转换表 开发者的经验和能力 / 开发环境成熟度和能力 很低 低 一般 高 很高 生产率PROD 4 7 13 25 50 估算工作量 E = NOP / PROD 例如，一个应用程序有 672 个新对象点，开发环境的生产率是正常的，则项目的估计工作量为： E = 672 / 13 = 52 （月）

(2) 早期设计模型 该模型用于评价可供选择的软件/系统体系结构和操作概念。 首先估算功能点，用未加调整的功能点根据下表来计算LOC。 早期设计模型的方程为： E = a(KLOC)×EAF 其中，a是常数，暂定为2.45。EAF是工作量调整因素。

每个功能点的编程语言级别 和源代码语句范围 最小 标称 最大 机器语言 0.1 — 640 汇编语言 1.00 237 320 416 C语言 2.50 60 128 170 RPGH语言 5.50 40 58 85 C++语言 6.00 55 140 Visual C++语言 9.50 34 PowerBuilder语言 20.00 16 Excel语言 57.00 5.5

可按下表中的7个早期设计的成本驱动因素来计算工作量调整因素 EAF，就像 COCOMO模型那样。 描 述 结合后架构成本驱动因素 RCPX 产品可靠性和复杂性 RELY,DATA,CPLX,DOCU RUSE 必要的复用 PDIF 平台困难程度 TIME,STOR,PVOL PERS 人员能力 ACAP,PCAP,PCON PREX 人员经验 AEXP,PEXP,LTEX FCIL 设施 TOOL,SITE SCED 进度

(3) 后架构模型 该模型应用于产品实际开发和维护。 在该模型中使用功能点或LOC。 后结构模型的方程为 E = a(KLOC)b×EAF 其中，a 设为2.55，b 按下式计算： b = 1.01 + 0.01×SUM( wi ) 其中，wi 按下表的 5 个尺度因素设定。这 5 个尺度因素代替了原来 COCOMO 模型中的项目类型（组织型、半独立型和嵌入型）

COCOMO-II的尺度因素 Wi 很低 低 一般 高 很高 非常高 有先例性 4.05 3.24 2.42 1.62 0.81 0.00 开发灵活性 6.07 4.86 3.64 2.43 1.21 架构/风险决策 4.22 3.38 2.53 1.69 0.84 团队内聚力 4.94 3.95 2.97 1.98 0.99 过程成熟度 4.54 2.73 1.82 0.91 有先例性：指正在计划中的项目在过去的项目里有类似情况的先例的程度。项目的新颖性越大，不确定性就越大，这个尺度因素的取值越高。

开发灵活性：指需求能以多种方式被满足的程度。越缺乏灵活性，这个尺度因素取值越高。 架构/风险对策：与需求的不确定性有关。如果需求没有严格地确定，而且很有可能要变更，则这个尺度因素取值越高。 团队凝聚力：指大型分散团队（也许在几个国家）紧密结合的程度。 过程成熟度：软件越是按结构化的、有组织的方式生产，不确定就越低，这个尺度因素的取值就越低。

利用下面的后架构成本驱动因素 fi，计算EAF，调整工作量。 描述 很低 低 正常 高 很高 极高 产品 RELY 软件可靠性 0.75 0.88 1.00 1.15 1.39 — DATA 数据库规模 0.93 1.09 1.19 CPLX 产品复杂性 0.70 1.30 1.66 RUSE 要求复用性 0.91 1.14 1.29 1.49 DOCU 文档编制 0.95 1.06 1.13

续一 fi 描述 很低 低 正常 高 很高 极高 平台 TIME 执行时间限制 — 1.00 1.11 1.31 1.67 STOR 内存限制 1.06 1.21 1.57 PVOL 平台易变性 0.87 1.15 1.30 人员 ACAP 分析员能力 1.50 1.22 0.83 0.67 PCAP 程序员能力 1.37 1.16 0.74 PCON 人员连续性 1.24 1.10 0.92 0.84

续二 fi 描述 很低 低 正常 高 很高 极高 AEXP 应用经验 1.22 1.10 1.00 0.89 0.81 — PEXP 平台经验 1.25 1.12 0.88 LTEX 语言和工具经验 0.91 0.84 项目 TOOL 软件工具 1.24 0.86 0.72 SITE 多站点开发 0.92 0.78 SCED 开发进度 1.29

5.6 成本预算 1. 成本预算的概念 项目成本预算是项目成本控制的基础，它 5.6 成本预算 1. 成本预算的概念 项目成本预算是项目成本控制的基础，它 将项目的成本估算分配到项目的各项具体工作上，以确定项目各项工作或活动的成本定额。 制定项目成本的控制标准。 规定项目意外成本的划分与使用规则。 项目成本预算包括四部分：直接人工费用的预算；咨询服务费用的预算；资源采购费用的预算；意外成本的预算。

成本预算的三大作用 项目成本预算是按计划分配项目资源的活动，以保证各项工作能够获得所需的各种资源。在做各项工作的成本预算时，要实事求是：过高会导致项目成本上升，过低会导致因省钱而偷工减料。 项目成本预算是一种控制机制：项目成本预算作为项目各项具体工作的全部定额，是度量各项工作在实际实施过程资源使用数量和效率的标准。项目工作的所花费的实际成本应尽量保持在预算成本的限度以内。 项目成本预算为项目经理监控项目实施进度提

供了一把标尺。在项目实施的任何时点上，都应有确定的预算成本。根据项目预算成本的完成情况和完成这些预算成本所消耗的实际工期，与完成同样成本额的计划工期相比较，项目经理可以及时掌握项目的进度情况，进行调整。 累积费用 时间 实际成本额 计划成本额 实际支出线 计划支出线 观测时点线

2. 项目成本预算编制的依据 项目成本估算 项目成本预算是把项目的成本估算分配到项目的各项工作和活动中，因此必须以项目成本估算为依据。 工作分解结构 项目成本预算根据工作分解结构分配项目估算成本。 项目进度计划 项目进度计划（见项目时间管理）详细地安排了各项工作的起始时间和结束时间，是按时间进度分配资金的依据。

3. 项目成本预算编制的方法和技术 无论使用什么方法和技术来编制项目的成本预算，都必须经过以下几个步骤： 分摊项目总成本到项目分解结构的各个工作包中，为每个工作包建立预算总成本。 将每个工作包所分得的成本额进一步分配到工作包所包含的各项活动中。 确定各项成本支出的时间计划，及每一个时间点对应的累积预算成本（截止到该时间点的每期预算成本额的总和），制定出项目成本预算计划。 编制项目成本预算的方法与估算的方法相同。

4. 项目成本预算编制的结果 项目各项工作或活动的成本预算 给出了实施某一项工作或活动的成本定量。在项目的实施过程中，将以此为标准监控各项工作或活动的实际资源消耗量。 成本基准计划 描述了项目进展时间与项目花费的累积预算成本之间的对应关系。它将作为度量和监控项目实施过程中费用支出的主要依据。

5.7 项目成本控制 项目成本控制包括 分析项目特点，确立项目管理目标； 5.7 项目成本控制 项目成本控制包括 分析项目特点，确立项目管理目标； 总结同类项目招投标经验，建立招投标的战略、评标与订立合同方法、分析招投标市场及参与者； 结合可行性研究、价值工程分析、设计效率分析，采用项目前期评价系统，确定成本控制的方针与办法以及中心激励机制； 项目后期评价，经验总结； 基于成本基准计划，监视成本执行，等。

1. 项目成本控制的概念 项目成本控制是指项目组织为保证在变化的条件下实现其预算成本，按照事先拟订的计划和标准，通过采用各种方法，对项目实施过程中发生的各种实际成本与计划成本进行对比、检查、监督、引导和纠正，尽量使项目的实际成本控制在计划和预算范围内的管理过程。 项目成本控制的主要内容包括： 识别可能引起项目基准计划发生变动的因素，并对这些因素施加影响，以保证这些变化朝着有利的方向发展。

以工作包为单位，监督成本的实施情况，发现实际成本与预算成本之间的偏差，找出产生偏差的原因。 对发生成本偏差的工作包，有针对性地采取纠正措施，必要时可以根据实际情况对项目成本基准计划进行适当的调整。 将核准的的成本变更和调整后的成本基准计划通知项目的干系人。 防止不正确的、不合适的或未授权的项目变更所发生的费用被列入项目成本预算。 防止因单纯控制成本而引起项目范围、进度和质量方面的问题，甚至出现更大的风险，

因此成本控制应与项目范围变更、进度计划变更、质量控制紧密结合。 有效成本控制的关键是经常及时地分析成本绩效，尽早发现成本差异和成本执行低下的问题。以便在情况变坏之前能够及时采取纠正措施。 一旦项目成本失控，在预算内完成项目是非常困难的。如果没有额外的资金支持，那么成本超支的后果就是：要么推迟项目工期，要么降低项目的质量标准，要么缩小项目的工作范围，这都是我们不愿看到的。

2. 项目成本控制的依据 项目各项工作或活动的成本预算 在项目的实施过程中，通常以此为标准，对各项工作的实际成本进行监控。它是进行成本控制的基础性文档。 成本基准计划 是按时间分段的费用预算计划，可用来测量和监督项目成本的实际发生情况，并能够很好地将成本支出与时间进度联系起来。它是按时间对项目成本支出进行控制的重要依据。 成本绩效报告

是记载项目预算实际执行情况的资料。它的主要内容包括项目各个阶段或各项工作的成本完成情况，是否超出了预先分配的预算，存在哪些问题。 分析项目成本绩效的基本指标为 项目计划作业的预算成本。是按预算价格和预算工作量分配给每一项作业活动的预算成本。 累积预算成本。将每一个工作包的总预算成本分摊到项目工期的各个时间分段，计算出截止到某个时点的各期预算成本的累计数，作为该时点的累积预算成本。

累积实际成本。项目已完成工作的实际成本，是截止到某一时点的各期发生的实际成本的累积数。 累积盈余量。已完成工作的预算成本，是将每一个工作包的总预算成本乘以该工作包的完工比率所得的乘积。 成本绩效指数。衡量成本效率的指标，是累积盈余量与累积实际成本的比值，反映了用多少实际成本才完成了一单位预算成本的工作量。 成本差异。累积盈余量与累积实际成本之间的差异。

变更申请 是项目干系人以口头或书面的方式提出的有关变更项目工作内容和成本的请求。 项目的任何变动都要经过严格的评估和批准，并获得资金的支持。 项目经理要根据变更后的项目工作范围或成本预算来对项目成本实施控制。 项目成本管理计划 这是识别和分析在项目的实施过程中可能会引起项目成本变化的各种潜在因素，提出解决和控制方案，确保在预算范围内完成项目的一个指导性文档。

3. 项目成本控制的方法和技术 成本变更控制系统 该系统主要包括三部分： 成本变更申请 核准成本变更申请 变更项目成本预算 根据严格的项目成本变更控制流程，对变更申请进行评估，确定变更所导致的成本代价和时间代价，再将评估结果报告给客户，由他们判断是否接受这些代价，核准变更申请。 变更申请被批准后，还要调整相关工作的成本预

算，对成本基准计划作相应修改。 要注意，成本变更控制系统应与其他变更控制系统相协调，成本变更的结果应与其他变更的结果相协调。 绩效测量 主要用于估算实际发生的变化的大小。常用的绩效测量技术有： 不确定性分析 投资项目的不确定性分析就是通过计算分析，确定各种不确定因素的变化对项目经济效益的影响程度的一种经济分析方法。

盈亏平衡分析 各种不确定因素（如投资、成本、销售量、产品价格、项目生命周期等）的变化会影响项目方案的经济效果。当这些因素的变化达到某一个临界值时，恰好使方案达到盈亏平衡。 盈亏平衡分析目的就是要在一定的市场、生产能力及经营管理的条件下，找出这个临界值，判断项目对不确定因素变化的承受能力，为决策提供依据。 敏感性分析 通过测定一个或多个不确定因素的变化所导

致的决策评价指标的变化幅度，了解各种因素的变化对实现项目预期目标的影响程度，从而对外部条件发生不利变化时项目方案的承受能力做出判断。 敏感性分析在一定程度上就各种不确定因素的变动对项目经济效果的影响做了定量描述，这有助于了解项目方案的风险，有助于确定在决策过程中及在方案实施过程中需要重点研究与控制的因素。缺点是没有考虑未来发生变动的概率。 概率分析 通过研究各种不确定因素发生不同幅度变

动的概率分布及其对项目方案经济效果的影响，对项目方案的净现金流量及经济效果指标做出某种概率描述，从而对项目方案的风险做出比较准确的判断。 挣值分析 是一种综合范围、时间、资源和项目绩效测量的方法。通过与计划完成的工作量、实际挣得的收益、实际的成本进行比较，确定成本、进度是否按计划执行。（参看项目的集成管理） 计算机工具 如项目管理软件、电子表格等。用于对计划费

4. 项目成本控制的结果 用和实际费用进行跟踪和比较，预测费用变更后的结果。 修正后的成本估算 根据实际需要修改和更新项目的成本估算。 成本预算更新 对原来的成本预算计划进行修订和调整，包括对成本基准计划进行必要的修改和更新。 纠正措施 使项目未来工作所花费的实际成本被控制在项目计划成本以内所采取的纠偏活动。