软件项目管理-第五章软件项目成本管理

'软件项目管理第五章软件项目成本管理SoftwareProjectCostManagement 项目成本管理是项目管理的一个重要组成部分，它是指在项目的具体实施过程中，为了保证完成项目所花费的实际成本不超过其预算成本而展开的项目成本估算、项目预算编制和项目成本控制等方面的管理活动。必须要加强对项目实际发生成本的控制。一旦项目成本失控，就很难在预算内完成项目。成本失控的情况常常是以下原因造成的：成本估算和成本预算不够准确细致；许多项目在成本估算、成本预算、成本控制方法上没有统一的标准可循。思想上的误区：实际成本超出预算是必然的。 5.1项目成本5.2项目成本管理的内容5.3资源计划5.4成本估算5.5软件项目的成本估算5.6成本预算5.7项目成本控制 5.1项目成本一般项目的成本主要由项目直接成本、管理费用和期间费用等组成。项目直接成本是指与项目有直接关系的成本费用。例如，直接人工费、直接材料费、其他直接费用等。管理费用是指为了组织、管理和控制项目所发生的费用。例如，管理人员费用支出、差旅费、固定资产和设备使用费、办公费、医疗保险费，以及其他一些间接费用。5.1.1项目成本 期间费用是指不受项目业务量增减影响的费用，如日常行政管理费、销售费等。软件项目由于其自身的特点，对整个项目的预算和成本控制更为困难。项目经理为了控制整个项目的预算和支出，必须正确估算软件开发的成本费用。软件项目的成本有4种：硬件/支持软件成本：包括项目所需的所有硬件设备、系统软件、数据资源的购置、运输、储存、安装、测试的费用。对于进口设备，还要包括国外运费、保险费、进口关税和增值税等费用。差旅及培训费：培训费用包括开发人员培训费和用户培训费。 软件开发成本：人工成本是最主要的软件开发成本。在软件开发项目中，付给软件工程师的人工费用占了开发成本的绝大部分。项目管理费用：用于项目组织、管理、控制的费用支出。尽管硬件/支持软件成本、差旅及培训费用可能在项目总成本中占较大比例，但最主要的成本还是在开发过程中所花费的工作量及相应的代价。软件产品生产不是一个重复的制造过程，而是以“一次性”开发过程的花费来计算的。软件项目开发成本的估算应以整个项目软件开发全过程所花费的人工代价作为计算的依据，并可以按与软 5.1.2影响项目成本的因素件生命周期对应的阶段进行估算。项目质量对成本的影响质量对成本的影响可通过质量成本表示。质量成本由质量故障成本和质量保证成本构成。质量故障成本是指为了排除因产品量差而产生的故障，保证产品重新恢复功能的费用。质量保证成本是指为了保证和提高产品质量，采取相应技术措施而消耗的费用。 质量故障成本与质量保证成本是相互矛盾的。质量保证成本高，故障就少，质量故障成本就低。反之亦然。因此，需要建立一个动态平衡。质量总成本质量保证成本质量故障成本质量成本 工期对成本的影响项目费用由直接费用和间接费用组成。一般工期越长，项目的直接费用越低，而间接费用越高。反之，缩短工期，需要更多的、技术水平越高的工程师，直接成本费用就会增加。项目总成本项目工期总成本间接费用成本直接费用成本 管理水平对成本的影响管理水平高，可以提高项目预算准确度，加强对项目预算的执行和监管，且对工期的控制可严格限制在计划许可的范围内。这样可以有效地控制由于设计方案和项目计划的变更所造成的成本变动。因此，管理水平对项目成本有关键影响。人力资源对成本的影响具有高技术能力和高技术素质的人才，人力成本较高，但可以有高生产率、可构建高质量产品、且工期较短，这样从整体上会降低成本。对于一般人员，还需要技术培训。对项目的理解 及生产率相对低下，工期会延长，造成成本的增加。因此，人力资源是重要的影响因素。价格对成本的影响中间产品和服务、市场人力资源、硬件、软件的价格也对成本产生直接的影响。因为价格对项目成本预算的影响很大。 5.2项目成本管理的内容项目成本管理主要由项目资源计划的编制，成本估算，成本预算和成本控制等4个过程组成，下图给出了这些过程的主要框架。以上四个过程相互影响、相互作用，有时也与外界的过程发生交互影响，根据项目的具体情况，每一过程由一人或数人或小组完成，在项目的每个阶段，上述过程至少出现一次。某些项目，特别是小项目，资源计划、成本估算和成本预算三者紧密相连，可把这些过程视为一个过程处理。 1.输入•工作分解结构•历史资料•范围说明•资源库描述•组织策略2.工具与技术•专家判断•头脑风暴法3.输出•资源需求计划1.输入•工作分解结构•资源需求•资源单价•活动时间估计•历史资料•财务图表2.工具与技术•类比估计3.输出•成本估算•详细说明•成本管理计划1.输入•成本估算•工作分解结构•项目进度2.工具与技术•成本估算工具与方法3.输出•基准成本项目成本管理1.输入•基准成本•执行情况•变更要求•成本管理计划2.工具与技术•成本变更控制系统•执行情况测量•另外的计划•项目管理软件3.输出•修改后成本估算•更新的预算•纠正措施•完成项目所需成本估算•经验与教训成本控制成本预算成本估算资源计划 5.3资源计划资源计划是确定为完成项目活动所需要的各种资源的种类、数量和时间，包括人力、财力和物力资源，完成资源的配置。在任何项目中，资源并不是无限制的，也不是可以随时随地能够获取的，项目的成本、可起作用的技术水平、时间进度等都受到可支配资源的限制。在项目进展过程中，如何合理配置和优化资源使用，是项目管理的重要问题。 5.3.1资源计划编制过程的依据工作分解结构WBS它是编制资源计划所依据的最重要的基础，根据工作分解结构，明确完成项目各项工作的资源需求。历史信息记录了以前类似项目的资源需求、资源计划、项目实施时实际耗费的资源等方面的有关情况。充分利用和借鉴相关历史信息来编制项目资源需求计划，可以提高资源需求计划的准确性，还可以减少编制的工作量。 范围说明范围说明描述了项目工作，界定了项目目标。这两者均应在编制资源计划时考虑。在编制资源计划时，逐项审查计划的资源需求能否满足项目的各项工作和项目目标的实现，对疏漏的资源需求要及时补充。项目资源库描述说明了在项目实施过程中具体有哪些资源可以利用，包括人员、设备、材料、资金等。在制定项目资源技术时，必须从项目资源库中了解这些相关的资源供给信息，分析现有资源储备能否满足项目实施的需要。 5.3.2项目资源计划编制的方法组织策略指有关人员的招聘，设备或材料的租赁或采购策略等。专家判断法由项目成本管理专家根据以往类似项目的历史信息和对当前项目的理解，经过严密思考计算，进行合理预测，制定项目资源计划。这样的专家应具有专业知识和受过专门训练，可从项目组织中的其他部门、咨询机构、专业技术协会获得。 定额法当项目实施所需要的某些资源（包括人力、设备、材料等）有国家或行业的统一标准定额，或有权威部门制定的规则时，应以这些统一的定额或规则为标准来制定项目资源需求计划。资料统计法参考以往类似项目的历史统计数据资料，计算并确定项目资源需求计划。它要求所采用的历史信息应与当前项目有可比性，并信息足够详细，有很强的可操作性。适合于创新性不强的项目。 利用工作分解结构根据工作分解结构所列出的项目全部工作的一览表，确定出每一项任务所需的各种资源，再将其汇总，编制出项目资源需求计划。这是最可行的一个方法。资源均衡法这是平衡各种资源在项目各个时期投入的一种常用方法。在保证项目完工时间不变的情况下可以调整资源的需求情况，控制资源投入时间，尽可能均衡使用各种资源来满足项目要求的完工进度。 5.3.3项目资源计划编制的结果编制项目资源计划的结果是编制出项目资源需求计划，对项目所需的各种资源的需求情况和使用计划给出详细的描述。项目资源的需求安排应当分解落实到具体的工作任务上。 5.4成本估算项目成本估算是项目成本管理的核心内容。通过成本估算，分析并确定项目的估算成本，以此为基础进行项目的成本预算，进而展开对项目进行成本控制等一系列管理活动。项目成本估算是指为了实现项目目标，完成项目的各项活动，根据项目资源计划中确定的各种资源需求（人员、设备、材料等）和市场上各种资源的价格，对完成项目所必需的各种资源的费用作出近似的估算。5.4.1项目成本估算的概念 简言之，项目成本就是项目形成全过程所耗用的各种费用的总和。项目定义与决策成本（可行性研究成本）项目设计成本（项目设计所花费成本）项目获得成本（为获取外部资源，如广告、招投标、询价等所花费成本）项目实施成本（项目实施过程所花费的硬/软件设施与支持平台、人工、咨询成本以及一定数量的意外成本的总和）。项目成本的耗费与项目所耗用资源的数量、质量和价格有关，与项目工期的长短有关，与项目结果的质量有关，与项目范围的广度／深度有关。 项目成本估算的步骤：识别与分析项目成本的构成要素。如人工费、咨询费、设备费、软件费等。根据已识别的成本构成要素，估算每一个要素的成本。分析成本估算的结果，找出可以互相补偿的成本，协调各种成本之间的比例关系。例如，设计质量的提高可能会大量减少项目实施阶段的成本。因此，项目设计成本增加会带来项目实施成本的降低，两种成本之间存在互相补偿的关系。 因此，在项目成本估算过程中，要积极寻找这种有补偿效应的成本，仔细研究成本之间的这种此消彼长的关系和量值对项目总成本造成的影响，努力使项目预期收益最大化。成本估算要以资源计划中所列的项目资源需求和项目组织对这些资源的预计价格为基础。项目成本估算的依据为：工作分解结构资源需求计划：资源数量和质量标准资源价格：市场价格或历史价格5.4.2项目成本估算的依据 5.4.3项目成本估算的方法项目持续时间：时间价值经济形势：通货膨胀和利率可以根据以往项目所积累的历史信息为基础进行项目成本估算。但项目之间总是存在一定差异，很少有简单重复，因此以往项目的成本只能作参考。通常可以采用以下方法进行成本估算。 类比估算法项目管理人员收集以往类似项目的有关历史信息，包括规模（代码行数或功能点数）、费用、人力、时间、物价等；会同有关成本估算专家对当前项目的总成本进行估算；将估算结果按照项目的工作分解结构的层次传递给直接下层的管理人员，由他们对自己负责的工作和活动的成本进行估算；继续向下一层管理人员传递他们的估算结果，直到项目的基层人员。 这种方法又称“自顶向下估算法”，其主要思想是从项目的整体出发，首先进行类推，再做分解。估算人员根据以前已完成的类似项目所消耗的总成本（总工作量），推算当前项目的总成本（总工作量），然后按比例将它分配到各工作分解单元中去，再来检验它是否能满足要求。分解比例参看下表。优点是简单易行，花费少。当项目详细资料难以得到时，这种方法行之有效。缺点是类似项目很难找，估算准确度较差。对项目中的特殊困难估计不足。 工料列表法基层管理人员计算出每个工作单元的生产成本；将各个工作单元的生产成本自下向上逐级累加，汇总到项目的高层管理者；项目的高层管理人员计算出项目的总成本。这种估算方法又称“自底向上估算法”。依据项目的工作分解结构，先“分解”，再对每个分解后的工作单元采取“类比”或其他方法进行估算，最后汇总。优点是结果十分详细，准确性高。 缺点是实际操作非常耗时，费用较高。而且通常估算值缺少各项子任务之间相互联系所需要的工作量，还缺少许多与项目实施有关的管理工作量.从心理学角度，通常会陷于一种恶圈：进行第一轮估算的基层管理人员会认为上级管理人员会以一定比例削减他们的成本估算，他们会过高估算自己工作的资源需求。基于这种情况，上层管理人员真的会认为应该削减估算的成本，这又恰恰证实了基层管理人员的怀疑。 参数模型法利用项目的一些特性参数（如代码行或功能点）建立数学模型来估算项目成本。这种方法有一组项目成本估算关系式，用它们对项目总成本作出近似估算。这种估算只针对影响项目总成本程度最大的成本变量进行估算，不考虑一些细节性成本因素。例如，考虑建立一个局域网系统的项目成本，先估算建造一个标准节点的成本作为系数因子，以标准节点数作为变量因子，两者相乘，得到项目的总成本。 优点是用这种方法估算项目成本的速度很快，只需要一小部分信息。缺点是不同的估算模型估算出的结果差异较大，因此，选择合适的模型以保证估算结果的准确性至关重要。为保证项目成本模型的适用性，在建立成本模型时，要注意：保证建立参数模型时所依据的历史信息的准确性；模型中的一些重要参数必须量化处理。根据项目的实际情况，对参数模型可按适当的比例调整。 5.4.4项目成本估算的结果利用项目成本管理软件利用项目成本管理软件，可以通过直接输入与项目成本有关的数据，或自定义项目成本函数，计算出项目成本的估算结果。目前几乎所有大型项目的成本估算，都是利用这类项目成本估算软件计算得到的。项目成本估算结果文件它以摘要或详细的形式描述了：实施项目必须的所有资源（人员、资金、硬/软件工具、可复用构件等），以及这些资源 的数量、质量标准、成本。为应付项目可能遇到的意外事件（通货膨胀、意外事故、原材料失窃等）所支付的具有不可预见性的意外成本。成本估算结果通常用货币量单位“元”表示，但有时为了管理方便，用工作量“人日”或“人月”来表示。相关支持性细节文件和结果它对项目成本估算的依据进行详细说明。项目工作范围说明。项目成本估算的基础和依据（采用的估算方 法、参考的国家有关规定、各种中间计算的结果等）。项目成本估算的假设（项目所需资源价格水平的估计、项目资源消耗定额的估计、项目实施人员的生产率等）。项目成本估算结果的误差范围。项目成本管理计划通常，在项目管理中用成本目标衡量项目绩效。但在项目开始后，会发生各种无法预见的情况，随时可能危及项目成本目标的实现。例如，人员流失、设备购进渠道不通、支持工具有缺陷等。 为实现在成本目标范围内完成项目可交付成果，必须对如何管理和控制项目成本变动的方案进行事先安排，即“有备无患”。管理计划的主要内容：识别并分析可能出现的各种意外事件；预测可能会发生损失的概率和程度；说明如何对费用偏差进行管理和如何对意外成本的使用进行管理；提出计划和解决方案。 5.5软件项目的成本估算软件项目管理过程开始于项目计划。在做项目计划时，第一项活动就是估算。常用的估算技术是对需要的人力（以人月为单位）、项目持续时间（以年份或月份为单位）、成本（以元为单位）做出估算。这种估算大多是利用以往类似项目的花费做为参考而做出的。如果新项目与以前的一个项目在大小上和功能上十分类似，则新项目需要工作量、开发持续时间、成本大致与那个老项目相同。 假使项目背景完全生疏，只凭过去的经验做出估算可能就不够了。现在已有了许多用于软件开发的估算技术。其共同特点是：事先建立软件范围；以软件度量（以往的度量）为基础，以做出估算；项目被分解为可单独进行估算的小块。 5.5.1软件的工作范围软件的工作范围即软件范围。包括：功能、性能、限制、接口和可靠性。估算开始时应对软件功能进行评价，对其进行适当的细化以便提供更详细的细节。由于成本和进度的估算都与功能有关，因此常采用某种程度的功能分解。性能的考虑包括处理时间和响应时间的需求。限制则标识产品成本、外部硬件、可用存储或其他现有系统对软件的限制。功能、性能和限制必须在一起进行评价。 当性能要求不同时，为实现同样的功能，开发工作量可能相差一个数量级。还要叙述某些质量因素（例如，给出的算法是否容易理解等）。软件与其它系统元素是相互作用的。要考虑每个接口的性质和复杂性，以确定对开发资源、成本和进度的影响。接口的概念可解释为：运行软件的硬件(如处理机与外设)及间接受软件控制的设备(如机器、显示器);必须与新软件连接的现有的软件(如数据库存取例程、子程序包、操作系统); 5.5.2软件开发中的资源软件开发所需的资源有:开发环境—硬件工具及软件工具—提供支持开发的基础.可复用软件构件—软件构造块.人员—主要资源通过终端或其他输入／输出设备使用该软件的人;该软件运行前后的一系列操作过程。对于每一种情况，都必须清楚地了解通过接口的信息转换。 人员可复用构件硬件/软件工具人员需要的技能,可用性开始时间,工作期限硬件开发系统,目标机器,新系统其他硬件部分软件支持软件可用性,投入时间,持续时间通常，对每一种资源，应说明以下四个特性：资源的描述;资源的有效性说明;资源在何时开始需要;使用资源的持续时间。最后两个特性统称为时间窗口。 1.人力资源在考虑各种软件开发资源时，人是最重要的资源。在安排开发活动时必须考虑人员的技术水平、专业、人数、以及在开发过程各阶段中对各种人员的需要。计划人员首先估算范围并选择为完成开发工作所需要的技能，然后在组织（如经理、系统分析员、软件设计师等）和专业（如网络、数据库、系统体系结构）两方面做出安排。对于相对比较小的项目（一个人年或更少），一个人就能完成所有软件开发工作，可在必要时咨询专家。 对一些规模较大的项目，在整个项目生命周期中，各种人员参与情况不同。下面是各类不同人员随开发进展在各个阶段参与情况的曲线。管理人员初级技术人员高级技术人员高人员参与程度计划需求分析概要设计详细分析程序编码单元测试集成测试确认测试 2.可复用构件库为了促成软件的复用，以提高软件生产率和产品质量，可建立可复用的软件构件库。Bennatan建议将软件资源分为4类：成品构件：由第三方厂商开发或在以前的项目中开发，经过严格测试确保无误的软件，通常称为COTS(commercialoff-the-shelf)。具有完全经验的构件：现有的为以前类似的项目建立的规格说明、设计、代码或测试数据。由于当前项目的成员在这些构件所代表的应用领域中有丰富的经验，应用这类有完全经验的构件时风险较小。 具有部分经验的构件：现有的为以前项目建立的规格说明、设计、代码或测试数据。这些项目与当前的项目相关，但需做实质上的修改。由于当前项目的成员在这些构件所代表的应用领域中仅有有限的经验，因此对于这类有部分经验的构件进行修改会有相当程度的风险。新构件：项目组为满足当前项目的特殊需要而必须专门开发的软件构件。最好能尽早说明软件的资源需求，这样才能进行软件可选方案的技术评估，并及时获得所需的构件。 3.硬件资源硬件是作为软件项目的一种工具而投入的。宿主机（Host）─软件开发时使用的计算机及外围设备；目标机（Target）─运行已开发成功软件的计算机及外围设备；其他硬件设备─专用软件开发时需要的特殊硬件资源；宿主机和必要的软件工具构成软件开发环境。这样的开发环境能够支持多种用户的需要，且能保持大量的由软件开发组成员共享的信息。宿主机与目标机可以是同一种机型。 4.软件资源软件人员在软件开发过程中使用了许多软件工具。将这些软件工具集成就叫做计算机辅助软件工程(CASE)。业务系统计划工具集项目管理工具集支持工具─文档生成工具、网络系统软件、数据库、电子邮件、通报板，以及配置管理工具分析和设计工具编程工具集成和测试工具 原型化和模拟工具维护工具框架工具─这些工具能够提供建立集成项目支撑环境（IPSE）的框架。5.5.3软件度量软件项目估算的依据是对以往项目进行度量所得到的有关工作量和时间的数据。只要事先建立特定的度量规程，很容易做到直接度量软件所需要的成本和工作量、产生的代码行数等。软件项目度量分为面向规模和面向功能度量： 1.面向规模的度量面向规模的度量是对软件产品和软件开发过程的直接度量。可以建立一个面向规模的数据表格来记录项目的某些信息。该表格列出了在过去几年完成的每一个软件开发项目和关于这些项目的相应面向规模的数据。例如，项目aaa-01的规模为12.1KLOC(千代码行)，工作量用了24个人月，成本为168,000元，文档为365页，在交付用户使用后第一年内发现了29个错误，有3个人参加了项目aaa-01的软件开发工作。 面向规模的数据表格项目工作量千元KLOC文档页数错误数人数aaa-012416812.1365293ccc-046244027.21224865fff-034331420.21050646…………………………………… 需要注意的是，在表格中记载的工作量和成本是整个软件工程的活动（分析、设计、编码和测试），而不仅仅是编码活动。对于每一个项目，可以根据表格中列出的基本数据计算简单的面向规模的生产率和质量的度量。生产率＝KLOC／PM（人月）质量＝错误数／KLOC成本＝元／LOC文档＝文档页数／KLOC 2.面向功能的度量面向功能的软件度量是对软件和软件开发过程的间接度量。面向功能度量主要考虑程序的“功能性”和“实用性”，而不是对LOC计数。该度量是一种叫做功能点方法的生产率度量法，利用软件信息域中的一些计数和软件复杂性估计的经验关系式而导出功能点FP。 面向功能的数据表格信息域参数用户输入数346=用户输出数457=用户查询数346=文件数71015=外部接口数5710=总计数计数加权因数简单中间复杂加权计数 功能点计算确定五个信息域的特征，并在表格中相应位置给出计数。用户输入数：各个用户输入是面向不同应用的输入数据。用户输出数：各个用户输出是面向应用的输出信息，包括报告，屏幕信息，错误信息等。在报告中的各个数据项不应再分别计数。用户查询数：查询是一种联机的交互操作，每次询问/响应具备应计数。 文件数：每一个逻辑的主文件（即数据的逻辑组合）都应计数。它可以是一个大数据库的一部分，也可以是一个单独的文件。外部接口数：与系统中其他设备（如磁盘文件）通过外部接口读写信息次数均应计数。一旦收集到上述数据，下一步确定与每一个计数相关的复杂性值（加权因子）。一个信息域是简单、平均还是复杂，由使用功能点方法的机构自行确定，从而计算出加权计数。计算功能点，使用如下的关系式：FP＝总计数×(0.65＋0.01×SUM(Fi))总计数是所有加权计数项的和； SUM(Fi)是求和函数:Fi（i＝1..14）是复杂性校正值，它们通过逐一回答如下提问来确定。F1系统是否需要可靠的备份和恢复？F2是否需要数据通信？F3是否有分布处理的功能？F4是否性能成为关键？F5系统是否运行在现存的高度实用化的操作环境中？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功能点度量是为了商用信息系统应用而设计的。 特征点度量（FeaturePoints）可以用于系统和工程软件应用特征点度量适合于算法复杂性高的应用。而实时处理、过程控制、嵌入式软件应用的算法复杂性都偏高，因此适合于特征点度量。为了计算特征点，可以象功能点计算那样，对信息域值进行计数和加权。此外，特征点度量要对一个新的软件特征“算法”进行计数。计算特征点可使用一个计算表格。对于每一个度量参数只使用一个权值，并且使用FP＝总计数×(0.65＋0.01×SUM(Fi))来计算总的特征点值。 特征点度量计算表格度量参数计数权值加权计数用户输入数4=用户输出数5=用户查询数4=文件数7=外部接口数7=算法3=总计数 3.协调不同的度量方法代码行数和功能点之间的关系依赖于用来实现软件的程序设计语言和设计质量。下面给出使用各种程序设计语言建立一个功能点所需要的平均代码行数的粗略估算。程序语言LOC∕FP(平均值)程序语言LOC∕FP(平均值)汇编语言320Ada9553C128VasualBasic32COBOL106Smalltalk22FOETRAN106PowerBuilder16Pascal90代码生成器15C++64SQL12 5.5.4软件项目估算在估算时往往存在某些不确定性，使得项目管理者无法正常进行管理而导致产品迟迟不能完成。项目复杂性对于增加软件计划的不确定性影响很大。复杂性越高，估算的风险就越高。项目规模对于软件估算的精确性和功效影响也比较大。随着软件规模的扩大，问题分解会更加困难。项目的规模越大，开发工作量越大，估算的风险越高。项目的结构化程度也影响项目估算的风险。随着结构化程度的提高，进行精确估算的能力就能提高，而风险将减少。 历史信息的有效性也影响估算的风险。对以往项目进行综合度量，可借用来比较准确地进行估算，安排进度以避免重走过去的弯路，而总的风险也减少了。如果对软件项目的工作范围还不十分清楚，或者用户的要求经常变更，都会导致对软件项目所需资源、成本、进度的估算频频变动，增加估算的风险。计划人员应当要求在软件的规格说明中给出完备的功能、性能、接口的定义。软件项目的估算能够通过一系列系统化的步骤，在可接受的风险范围内提供估算结果。 估算对风险的影响低风险区项目复杂性项目结构化、规约的不确定程度项目工作量大小 1.使用LOC和FP估算在软件项目估算中，在两个方面使用了LOC和FP数据：把LOC和FP数据当做一个估算变量，用于量度软件每一个元素的规模。LOC和FP数据作为从过去项目中收集到的基线数据，与其它估算变量联合使用，进行成本和工作量的估算。LOC和FP的共性在于:给出一个有界的软件范围的叙述由此叙述把软件分解成一些小的可分别独 立进行估算的子功能对每一个子功能估算LOC或FP把基线生产率度量(如LOC/PM或FP/PM)用做特定的估算变量，导出子功能的成本或工作量综合子功能的估算得到整个项目的总估算。用LOC做为估算变量时，必须进行功能分解,且需要达到很详细的程度。而估算FP时需要的数据是宏观的量，当把FP当做估算变量时不需分解得很详细。 LOC是直接估算的,而FP是通过估计输入、输出、数据文件、查询和外部接口的数目，以及14种复杂性校正值间接地确定的。项目计划人员可对每一个分解的功能提出一个有代表性的估算值范围。利用历史数据或凭实际经验（当其它的方法失效时），对每个功能分别按最佳的、可能的、悲观的三种情况给出LOC或FP估计值。记作a、m、b。接着计算LOC或FP的期望值E。 所有子功能的总估算变量值除以相应于该估算变量的平均生产率度量得到项目的总工作量。例如，若假定总的FP估算值是310，基于过去项目的平均FP生产率是5.5FP／PM，则项目的总工作量是：工作量＝310／5.5＝56PM作为LOC和FP估算的实例，考察一个为CAD应用而开发的软件包。系统定义评审指明，“软件是在一个工作站上运行，其接口必须使用各种计算机图形设备，包括鼠标器、数字化仪、高分辩率彩色显示器和激光打印机。” 在这个实例中，使用LOC做为估算变量。根据系统规格说明,软件范围的初步叙述如下“软件从操作员那里接收2维或3维几何数据。操作员通过用户界面与CAD系统交互并控制它，这种用户界面将表现出很好的人机接口设计特性。所有的几何数据和其它支持信息保存在一个CAD数据库内。要开发一些设计分析模块以产生在各种图形设备上显示的输出。软件要设计得能控制并与能各种外部设备，包括鼠标器、数字化仪、激光打印机和绘图仪交互。” 经过分解,识别出下列主要软件功能：用户界面和控制功能二维几何造型三维几何造型数据库管理计算机图形显示功能外设控制PC设计分析模块通过分解，可得到如下估算表 功能a乐观值m可能值b悲观值E期望值元/行行/PM成本(元)工作量(PM)用户接口控制180024002650234014315327607.4二维几何造型41005200740053802022010760024.4三维几何造型46006900860068002022013600030.9数据库管理2950340036003350182406030013.9图形显示40504900620049502220010890024.7外部设备控制2000210024502140281405992015.2设计分析66008500980084001830015120028.0总计33360656680144.5 从历史的基线数据求出生产率度量，即行／PM和元／行。需要根据复杂性程度的不同，对各功能使用不同的生产率度量值。在表中的因此可得，该项目总成本的估算值为657,000元，总工作量的估算值为145人月（PM）。 2.项目人工成本的估算项目人工成本主要是指软件开发过程中所花费的工作量及相应的代价。它不包括原材料和能源的消耗，主要是人的劳动的消耗。人的劳动消耗所需代价就是软件产品的人工成本。项目人工成本的计算方法不同于其它物理产品成本的计算，是以一次性开发过程所花费的代价来计算的。项目人工成本的估算，应是从软件计划、需求分析、设计、编码、单元测试、集成测试到确认测试，整个软件开发全过程的花费作为依据的。 3.软件项目成本估算方法—专家判定技术单独一位专家可能会有种种偏见，最好由多位专家进行估算，取得多个估算值。有多种方法把这些估算值合成一个估算值:一种方法是简单地求各估算值的中值或平均值。其优点是简便。缺点是可能会由于受一、二个极端估算值的影响而产生严重的偏差。另一种方法是召开小组会，使各位专家们统一于或至少同意某一个估算值。优点是可以摈弃蒙昧无知的估算值，缺点是一些组员可能会受权威或政治因素的影响。 Delphi技术标准Delphi技术组织者发给每位专家一份软件系统规格说明书和一张记录估算值的表格，请他们进行估算。专家详细研究软件规格说明书的内容，对该软件提出三个规模的估算值，即：ai(最小),mi(可能),bi(最大)，无记名地填写表格；组织者对专家们在表格中的答复进行整理：a.计算各专家估算的期望值Ei;b.对专家的估算结果分类摘要。 专家对此估算值另做一次估算。在综合专家估算结果的基础上，组织专家再次无记名地填写表格。比较两次估算的结果。若差异很大，要通过查询找出差异的原因。上述过程可重复多次。最终可获得一个得到多数专家共识的软件规模（源代码行数）。最后，通过与历史资料进行类比，根据过去完成软件项目的规模和成本等信息，推算出该软件每行源代码所需要的成本。然后再乘以该软件源代码行数的估算值，就可得到该软件的成本估算值。 5.5.5软件人工成本估算的经验模型软件开发人工成本估算是依据开发成本估算模型进行估算的。开发成本估算模型采用经验公式来预测软件项目计划所需要的成本、工作量和进度数据。根据模型中估算变量的依存关系，可把模型分为静态模型和动态模型。静态模型从一个唯一的估算变量（如源代码规模）计算其他变量（如工作量和时间），且所有计算公式对于所有场合都一样。动态模型中所有变量是相互依存的。 根据基本估算变量的多少，模型又可分为单变量模型和多变量模型。单变量模型只用一个估算变量计算出其他所有变量；多变量模型需要多个变量来描述过程。典型的静态单变量估算模型是通过对从以前的软件项目收集到的数据进行回归分析导出的。其总体结构具有以下形式：E=A+B*(ev)C其中，E是以人月为单位的工作量，A、B、C是经验常数，ev是估算变量（LOC或FP）。1.静态单变量估算模型 (1)面向LOC的估算模型E＝5.2(KLOC)0.91Walston-Felix模型E=5.5+0.73(KLOC)1.16Bailey-Basili模型E＝3.2(KLOC)1.05Boehm基本模型E＝5.288(KLOC)1.047Doty模型（针对KLOC>9的情况）除上述关系以外，大多数估算模型均有某种形式的项目调整措施，使得E能够根据其他的项目特性（如问题的复杂性、开发人员的经验、开发环境等）加以调整。 (2)面向FP的估算模型E＝-13.39+0.0545FPAlbrecht-Gaffney模型E=60.627.72810-8FP3Kemerer模型E＝585.7+15.12FPMaston-Barnett-Mellichamp模型从以上模型可知，每一个模型对于相同的LOC或FP值，会产生出不同的结果。这意味着使用这些估算模型时，必须根据当前项目的需要，对模型加以调整。 2.Putnam模型Putnam模型是一种动态多变量模型。适用于大型项目，也可用在一些较小的软件项目中。它是假定在软件开发的整个生存期中工作量有特定的分布。大型软件项目的开发工作量分布可以用Rayleigh-Norden曲线表示。用该曲线可以导出一个“软件方程”：td是开发持续时间(年)，K是整个软件生命周期的工作量(人年)，L是源代码行数(LOC)，Ck是技术状态常数，因开发环境而异。 系统定义功能设计规格说明系统开发系统维护与支持工作量（人月）时间系统定义功能设计规格说明安装测试与确认设计与编码开发工作=总工作量的40%维护与支持工作=总工作量的60% 技术状态常数Ck的取值Ck的典型值开发环境开发环境举例2000差没有系统的开发方法，缺乏文档和复审，批处理方式。8000好有合适的系统开发方法，有充分的文档和复审，交互执行方式。11000优有自动开发工具和技术 3.COCOMO81模型（COnstructiveCOstModel81）结构型成本估算模型是一种精确、易于使用的成本估算方法。DSI(DeliveredSourceInstruction)定义为代码的源程序行数。若一行有两个语句，则算做一条指令。它包括作业控制语句、格式语句和数据声明，但不包括注释语句。KDSI＝1024DSIMM(Man-Months)表示开发工作量（人月）。TDEV(TimeofDevelopment)表示开发进度。它由工作量决定（月）。 (1)COCOMO81模型的限制模型成本估算涵盖的开发期，开始于产品设计阶段之初，终止于集成与测试阶段之末。其他阶段的成本和进度单独估算。模型成本估算仅包含在开发期间工作分解结构中的活动，其中包含了管理和文档编制的工作量，但不包含用户培训、安装计划、移植计划等相关工作量。模型估算包括了项目中所有直接计费的劳动力的活动，包括项目经理和程序库管理员，但不包括计算中心操作员、人事部门职员、秘书、高层管理人员、房屋管理员等。 (2)COCOMO81模型中项目的分类组织型半独立型嵌入型产品目标的系统理解充分很多一般有关工作的经验大量很多适中对需求一致性的要求基本很多充分对外部接口说明一致性的要求基本很多充分有关新硬件和操作程序的并行开发若干适中大范围对创新的数据处理架构和算法的需求最低若干很多提前完成时的奖金低适中高产品范围的规模<50KDSI<300KDSI所有规模软件项目开发模式特性 COCOMO81模型分类COCOMO模型按其详细程度分成三级：基本COCOMO模型中间COCOMO模型详细COCOMO模型组织型半独立型嵌入型分批数据处理简单库存/生产管理熟悉的OS,编译器科学模型多数事务处理系统简单指令控制系统新的OS,DBMS大的库存/生产管理复杂事务处理系统超大型操作系统航天控制系统大的指令控制系统软件项目开发模式应用举例 基本COCOMO模型是静态单变量模型，用源代码行数(KDSI)为自变量的经验函数计算软件开发工作量。中间COCOMO模型在用KDSI为自变量的函数计算软件开发工作量（称为名义工作量）的基础上，用涉及产品、硬件、人员、项目等方面的影响因素调整工作量估算。详细COCOMO模型包括中间COCOMO模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中每一阶段（分析、设计等）的影响。 (3)基本COCOMO模型基本COCOMO模型的标称工作量和进度公式按这些公式得到的估算实例参看下表。它总结了每一种软件项目开发模式和不同规模产品中估算出来的工作量、生产率、开发进度等。产品规模：小型(2KDSI),中小型(8KDSI),中型(32KDSI),大型(128KDSI),超大型(256KDSI)。项目类型工作量进度组织型MM=2.4(KDSL)1.05TDEV=2.5(MM)0.38半独立型MM=3.0(KDSL)1.12TDEV=2.5(MM)0.35嵌入型MM=3.6(KDSL)1.20TDEV=2.5(MM)0.32 标准规模产品的基本COCOMO估算工作量(MM)小型中小型中型大型超大型组织型半独立型嵌入型5.06.58.321.3314491146230392687121632506420生产率(DSI/MM)小型中小型中型大型超大型组织型半独立型嵌入型40030824137625818235221913932718610515880 进度(月)小型中小型中型大型超大型组织型半独立型嵌入型4.64.84.98.08.38.41414142424244241平均投入人员(FSP)小型中小型中型大型超大型组织型半独立型嵌入型1.11.41.72.73.75.26.5101616295177157 (4)中间COCOMO模型进一步考虑15种影响工作量的因素（称成本驱动因素），通过定下乘法因子，修正COCOMO标称工作量公式和进度公式计算的结果，可以更合理地估算软件（各阶段）的工作量和进度。中间COCOMO模型的标称工作量与进度公式计算公式：MM=a(KDSI)bEAF项目类型工作量进度组织型MM=3.2(KDSL)1.05TDEV=2.5(MM)0.38半独立型MM=3.0(KDSL)1.12TDEV=2.5(MM)0.35嵌入型MM=2.8(KDSL)1.20TDEV=2.5(MM)0.32 EAF称为工作量调节因子，成本驱动因素fi产品因素：软件可靠性、数据库规模、产品复杂性硬件因素：执行时间限制、存储限制、虚拟机易变性、环境周转时间人的因素：分析员能力、应用领域实际经验、程序员能力、虚拟机使用经验、程序语言使用经验项目因素：现代程序设计技术、软件工具的使用、开发进度限制 成本驱动因素fi很低低正常高很高超高产品因素软件可靠性0.750.881.001.151.40数据库规模0.941.001.081.16产品复杂性0.700.851.001.151.301.65计算机因素执行时间限制1.001.111.301.66存储限制1.001.061.211.56虚拟机易变性0.871.001.151.30环境周转时间0.871.001.071.15虚拟机是指为完成某一软件任务所使用硬、软件的复合体。环境周转时间是指从用户输入到运算结果返回的时间。 成本驱动因素fi很低低正常高很高超高人员因素分析员能力1.461.000.860.71应用领域经验1.291.131.000.910.82程序员能力1.421.171.000.860.70虚拟机使用经验1.211.101.000.90程序语言经验1.411.071.000.95项目因素先进编程技术1.241.101.000.910.82使用软件工具1.241.101.000.910.83开发进度限制1.231.081.001.041.10 例1.一个32KDSI的声音输入系统是一个输入原型，或是一个可行性表演模型。所需可靠性非常低。把此模型看做半独立型软件。则有MM＝3.0（32）1.12＝146又查下表知f1＝0.75，其它fi＝1.00，则最终有MM＝146×0.75＝110.例2.一个规模为10KDSI的商用微机远程通信的嵌入型软件，使用中间COCOMO模型进行成本估算。程序标称工作量MM标称＝2.8(10)1.20＝44.38（MM） 影响因素fi情况取值1.软件可靠性只用于局部地区恢复问题不严重1.00(正常)2.数据库规模20000字节0.94(低)3.产品复杂性用于远程通信处理1.30(很高)4.时间限制使用70%的CPU时间1.10(高)5.存储限制64M中使用了45M1.06(高)6.机器使用商用微处理机1.00(正常)7.周转时间平均2小时1.00(正常)8.分析员能力优秀人才0.86(高)9.工作经验远程通信工作3年1.10(低)10.程序员能力优秀人才0.86(高)11.工作经验微型机工作3年1.00(正常)12.语言使用经验12个月1.00(正常) 影响因素fi情况取值13.使用现代编程技术1年以上0.91(高)14.使用软件工具基本的微机软件1.10(低)15.工期9个月1.00(正常)工作量调节因子程序实际工作量MM=MM标称×EAF=44.38×1.16＝=51.48（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模型相同。详细COCOMO模型引入了两种新特色：阶段敏感的工作量影响因素：把软件开发分为4个阶段：需求计划和产品设计、详细设计、编码和单元测试、集成与测试。三层次的产品分级结构：针对每一个影响因素，按模块层、子系统层、系统层，有相应工作量因素分级表，供不同层次的估算使用。 两者综合，每张表都按产品层次-开发阶段-要求高低，详细给出定量的估计。例如，软件可靠性（RELY）的工作量因素分级表（子系统层）和产品复杂性（CPLX）的工作量因素分级表（模块层）如表所示。使用这些表格，可以比中间COCOMO模型更方便、更准确地估算软件开发工作量。 软件可靠性成本驱动因素分级表(子系统层)阶段级别需求和产品设计详细设计编程和单元测试集成及测试综合非常低0.800.800.800.600.75低0.900.900.900.800.88正常1.001.001.001.001.00高1.101.101.101.301.15非常高1.301.301.301.701.400.80×0.15＋0.80×0.30＋0.80×0.30＋0.60×0.25==0.75各阶段工作量分配比例 产品复杂性成本驱动因素分级表(模块层)阶段级别需求和产品设计详细设计编程和单元测试集成及测试综合非常低0.700.700.700.700.70低0.850.850.850.850.85正常1.001.001.001.001.00高1.151.151.151.151.15非常高1.301.301.301.301.30 可靠性要求不同导致项目活动的差异等级需求与产品设计详细设计编码与单元测试集成与测试很低不详细;很多待定;较少确认;最小量QA,CM,用户手册草稿,测试计划;最少设计评审;基本设计信息;最小量QA,CM,用户手册草稿,测试计划;非正式设计检查;没有测试过程;最小路经测试;最小标准检查;最小QA,CM;最小I/O与非正式测试;最小用户手册;没有测试过程;很多需求未经测试；最小QA,CM;最小压力与非正常测试;最小所需文档；低基本信息,确认;频繁的待定;基本QA,CM,标准用户手册草稿,测试计划;中等详细;基本QA,CM,用户手册草稿,测试计划;最小测试过程;部分路径测试,标准检查;基本QA,CM,用户手册;部分I/O与非正常测试;最小测试过程;需求通常未经测试;基本QA,CM,用户手册;部分压力与非正常测试; 等级需求与产品设计详细设计编码与单元测试集成与测试正常正常项目V&V高详细的确认,QA,CM,标准,设计评审,文档编制;详细的测试计划,过程;详细的确认,QA,CM,标准,关键设计评审,文档编制;详细的测试计划,过程;详细的测试过程,QA,CM,文档化;广泛的非正常测试;详细的测试过程,QA,CM,文档化;广泛的压力与非正常测试;很高详细的确认,QA,CM,标准,设计评审,文档编制;与独立的V&V机构接口;非常详细的测试计划,过程;详细的确认,QA,CM,标准,关键设计评审,文档编制;非常彻底的设计检查;非常详细的测试计划,过程;与独立的V&V机构接口;详细的测试过程,QA,CM,文档化;非常彻底的代码检查;非常广泛的非正常测试;与独立的V&V机构接口;非常详细的测试过程,QA,CM,文档化;非常广泛的压力与非正常测试;与独立的V&V机构接口; 4.COCOMO-II模型COCOMO81模型适用于专用的定制的软件项目，它建立在“瀑布模型”的过程框架上。1997年Boehm等人提出来的COCOMO-II模型则适用于广泛汇集各种技术的软件项目，如商用软件、面向对象软件、通过螺旋型或演化型开发模型制作的软件。现在系统开发有三个关注点：应用程序生成器：事先为用户编程创建了大量程序包，使用应用组装工具来集成。应用组装：使用通用构件快速组装以得到应 用系统。系统集成：对系统的每一部分可用应用组装方式来开发，再做系统的集成。适用于规模较大、嵌入较多且先例较少的系统的开发。COCOMOII模型通过三个不同的模型分别对三个不同的阶段进行估算：应用组装模型（估算早期原型开发工作量）早期设计模型（估算探索和选择可用的系统∕软件体系结构和操作所用工作量）后架构模型（估算实际系统开发的工作量） (1)应用组装模型应用组装模型用于估算原型制作的工作量。适用场合如：用户界面的原型开发，软件和系统交互考虑，性能评估和技术成熟度评价等。模型使用“对象点”，而不用“源代码行”或“功能点”进行估算。对象点是1991年由Banker、Kauffman和Kumar等人提出的。它类似于功能点，是一种软件间接度量。根据（用户界面）屏幕（screen）数、报告（report）数、建造应用所需使用的第三代语言（3GL）构件数来计数。 屏幕、报告和3GL构件统称为元素。2000年Boehm等人在COCOMOII:2000中把“对象点”改为“应用点”，以避免概念的混淆。应用组装模型估算的步骤：评估应用计数：估算组成该应用的屏幕、报告和3GL构件数目。确定复杂性级别：对于每一个屏幕、报告、3GL构件，根据一些特征，把它们划分到简单、中等和困难等3个复杂性级别。其中，srvr为与屏幕或报告相关联的服务器（主机或同等物）数据表数，clnt为与屏幕或报告相关联的客户机（个人工作站）数据表数。 数据表的数量和来源包含的视图数总数<4(<2个srvr,<3个clnt)总数<8(2~3个srvr,<3~5个clnt)总数8(>3个srvr,>5个clnt)<3简单的简单的中等的3~7简单的中等的困难的8中等的困难的困难的表1屏幕应用点复杂性等级每一个屏幕可以展开为若干视图（views）。根据屏幕所涉及视图数和数据表数，可以确定该屏幕的复杂性等级。 数据表的数量和来源包含的节数总数<4(<2个srvr,<3个clnt)总数<8(2~3个srvr,<3~5个clnt)总数8(>3个srvr,>5个clnt)<2简单的简单的中等的2~3简单的中等的困难的4中等的困难的困难的表2报告应用点复杂性等级每一个报告可以包括有若干节（sections）。根据报告所涉及节数和数据表数，可以确定该报告的复杂性等级。 3)加权：根据每一个元素的复杂性级别，参照表3对其加权。4)计算应用点数：将每一个元素的计数乘以权值得到该元素的加权计数，再将各个元素的加权计数累加，得到总的应用点计数。表3应用点复杂性加权元素类型复杂性加权简单的中等的困难的屏幕123报表2583GL构件--10 估计项目复用的百分比r：如果项目在开发中使用了构件或复用了以前的软件，再估计复用的百分比r。计算要开发的新应用点数：通过以下公式得到调整后的新应用点数NAP。NAP=（应用点计数）×（100–r）/100例如，一个应用程序包含840个应用点，其中20%可以通过使用现成的构件来提供，那么调整后的新应用点（NAP）的得分将是NAP=840×(100-20)/100=6727)确定生产率：其单位是:PROD=NAP∕人月 表4对象点/工作量转换表8)估算工作量PM=NAP/PROD例如，一个应用程序有672个新应用点，开发环境的生产率是正常的，则项目的估计工作量为：PM=672/13=52（人月）开发者的经验和能力∕开发环境成熟度和能力很低低标称高很高生产率PROD47132550 (2)早期设计模型和后架构模型的标称工作量估算公式估算功能点。功能点通过量化与主要外部数据、控制输入／输出、文件相关的信息处理功能来度量软件项目。表5用户功能类型功能类型描述外部输入从系统边界外进入的各种（唯一的）用户数据外部输出从系统边界内流出的各种（唯一的）用户数据 (2)早期设计模型可以根据软件需求和设计文档的信息，对于每一个功能类型，分别统计功能计数。确定复杂性等级。按照下表，确定每个功能的复杂性等级。复杂性等级划分为“低”、“一般”或“高”。功能类型描述内部逻辑文件把系统中主要的用户数据或控制信息逻辑组定义为一个内部逻辑文件，包括系统产生的、使用的和维护的各个逻辑文件。外部接口文件系统之间传递或共享的文件都是外部接口文件外部查询根据用户输入的查询要求进行处理并导致一个直接输出即为一个外部查询 表6FP复杂性等级记录元素类型数1～1920～50≥511低低一般2～5低一般高≥6一般高高对于内部逻辑文件和外部接口文件数据元素类型数文件类型数1～56～19≥200～1低低一般2～3低一般高≥4一般高高对于外部输出和外部查询数据元素类型数 3)对各功能类型计数加权：根据表7。按照复杂性等级对各个功能类型计数加权。（该权值反映了实现功能所需工作量的大致估计）计算未调整的功能点：把所有加权后的功能计数相加，得到未调整功能点。根据表8，把未调整功能点转换成源代码行数。文件类型数1～56～19≥200～1低低一般2～3低一般高≥4一般高高对于外部输入数据元素类型数 表7功能点复杂性权值低一般高外部输入346外部输出457外部查询346内部逻辑文件71015外部接口文件5710传统的功能点度量，还需要考虑14种用于校正度量值的影响因素，然而COCOMOII没有这样做。COCOMOII先计算未调整功能点，再应用复用因子、成本驱动因子、尺度因子进行调整。复杂性权值功能类型 表8从UFP到SLOC的默认转换率语言SLOC∕UFP语言SLOC∕UFP机器代码640Lisp64基本汇编320Prolog64宏汇编213C++55C128Java53Fortran77107Ada9549UnixShellScripts107AIShell49CompiledBasic91VisualC++34Pascal91VisualBasic5.029Cobol(ANSI85)91PERL27Modula280SQL20Fortran9595PowerBuilder16Forth64HTML3.015 例如，项目的功能点数据如下：由此可计算未调整功能点为UFP=43+74+56+715+610=235若采用C编程，则源代码行数为：SLOC=235128=30080=29.375(KSLOC)功能类型类型数据元素复杂性权重功能计数外部输入文件18低34外部输出文件112低47外部查询文件716高65内部逻辑文件记录22104高157外部接口文件记录1456高106 估算工作量工作量估算公式为：其中，A=2.94（对COCOMOII.2000）。KSLOC是千源代码行数。指数E是5个尺度因子（SF,ScaleFactors）的总合。其中，B=0.91（对COCOMOII:2000）。EMi是工作量调整因素中的成本驱动因子。 尺度因子SFi的含义尺度因子解释先例性SF1反映机构对此类型项目的经验。包括机构对产品目标的理解程度，以往类似系统的工作经验，相关硬件和操作程序开发的熟悉和协同程度，数据处理、体系结构以及算法是否需要有创新等。“很低”代表无经验，“很高”代表对该领域有彻底了解。开发灵活性SF2反映开发过程中的灵活程度。“很低”代表软件范围必须与已建立的需求、外部接口规范等高度一致，“很高”代表客户只给出了总的目标。体系结构∕风险化解SF3反映风险分析情况。包括是否识别出关键风险项，软件体系结构在任务、接口、构件、技术、性能方面不确定性如何，是否通过设计评审和完善体系结构建立了化解这些风险项的里程碑。“很低”代表无分析，“很高”代表完全、彻底的风险分析。 尺度因子SFi的含义–续尺度因子解释团队凝聚力SF4反映开发团队相互了解和协作的程度。包括项目相关人员的目标和企业文化的一致性，项目相关人员是否有能力有意愿适应其他相关人员的目标，团队建设和团队工作是否有经验。“很低”代表交互很困难，“很高”代表团结高效。过程成熟度SF5反映机构的过程成熟度。可用5减去CMM过程成熟度等级得到。通过分析上表所示的5个尺度因子来计算指数E。这些因子有六个等级，从“很低”到“极高”，分别赋予5～0值，将这些估算值相加除以100，再加上B=0.91，就得到该指数的取值。 例如，一个组织正承担一个项目，该组织对于该项目所在领域没有经验。项目客户没有定义需采用的过程，需求和接口只有大概的构想。在项目进展中没有做重大风险分析，还需组织新的开发团队来完成这个系统。此外该组织最近刚实行过程改善计划，并且依据CMM模型被评为2级。在进行指数计算时，各尺度因子取值为：先例性机构的新项目，取值“低”(4)开发灵活性无客户介入，取值“很高”(1)体系结构∕风险化解无风险分析，取值“很低”(5) 团队凝聚力新团队，取值“一般”(3)过程成熟度有些过程控制，取值“一般”(3)计算得到的指数E为：后架构模型用在软件生命周期中软件体系架构完成后的系统构造阶段，应用于产品实际开发和维护。后架构模型的工作量调整 后架构模型采用17个成本驱动因子EMi，来调整标称工作量，以反映待开发软件的特征。该模型可用于为整个项目或由多个模块组成的项目估算工作量和进度。EMi描述很低低标称高很高极高产品RELY软件可靠性0.820.921.001.101.26—DATA数据库规模—0.901.001.141.28—CPLX产品复杂性0.730.871.001.171.341.74RUSE可复用开发—0.951.001.071.151.24DOCU文档编制0.810.911.001.111.23— EMi描述很低低正常高很高极高平台TIME执行时间限制——1.001.111.291.63STOR内存限制——1.001.051.171.46PVOL平台易变性—0.871.001.151.30—人员ACAP分析员能力1.421.191.000.850.71—PCAP程序员能力1.341.151.000.880.76—PCON人员连续性1.291.121.000.900.81—续一 EMi描述很低低正常高很高极高APEX应用经验1.221.101.000.880.81—PLEX平台经验1.191.091.000.910.85—LTEX语言和工具经验1.201.091.000.910.84—项目TOOL软件工具1.171.091.000.900.78—SITE多站点开发1.221.091.000.930.860.80SCED开发进度1.431.141.001.001.00—续二 各成本驱动因子等级的划分要求的可靠性：主要看软件失效造成的影响：数据库规模：因为测试数据库需大量测试数据，可用D/P即测试数据的字节数与程序SLOC的比率来衡量产生和维护这些测试数据所需工作量。很低低标称高很高极高n/aD/P＜1010≤D/P＜100100≤D/P＜10001000≤D/Pn/a很低低标称高很高极高仅有点不方便低度易弥补的损失中度易弥补的损失高财务损失性命攸关n/a 产品复杂性：从5个方面来综合衡量产品复杂性：很低低标称高很高极高控制操作控制转移少，简单模块连接结构化编程，多为简单谓词简单回调和消息传递，分布式处理存在复合谓词和高度嵌套多任务复杂分布式处理多资源调度，微指令控制，分布式硬实时控制计算操作简单表达式计算中等表达式计算标准算法和矩阵运算基本数值分析算法复杂数值分析算法随机数据分析，并行计算设备相关操作有简单格式的简单读写语句在GET／PUT级读写包括状态检查、错误处理的读写物理I/O操作，优化I/O通信链路处理、嵌入式系统微程序控制操作、性能关键嵌入式系统数据管理操作主存的简单数组，简单查询单文件子集、中等查询多文件读写和复杂数据查询、更新数据流触发器，数据重构分布式数据库、复杂触发器高耦合动态相关的对象结构，自然语言数据管理用户界面操作简单输入表单，报表生成器简单GUI生成器工具集的简单使用工具集开发扩展，多媒体中等2/3D动态图形和多媒体复杂多媒体、虚拟现实、自然语言界面 可复用开发：主要考虑构造在当前或未来项目中复用的构件所需要的额外工作量：匹配生命周期需求的文档编制：主要考虑在软件产品生命周期各阶段对项目文档的需求的适应性来评估的。很低低标称高很高极高未满足绝大多数生命周期需求未满足某些生命周期需求满足生命周期需求超出生命周期需求大大超出生命周期需求n/a很低低标称高很高极高n/a无跨项目跨程序跨产品线跨多条产品线 执行时间限制：主要通过系统或子系统预期消耗的时间与可用执行时间的比率（%）来确定其执行时间的限制等级：内存限制：主要通过系统或子系统预期使用的内存空间与可用空间的比率（%）来确定其内存限制的等级：内存消耗包括动态链接或动态嵌入构件所用存储很低低标称高很高极高n/an/a<50%50～70%70～85%85～95%很低低标称高很高极高n/an/a<50%50～70%70～85%85～95% 平台易变性：平台是指硬件和支持软件的总体（旧称虚拟机）。分析员能力：主要考虑分析和设计人员的分析和设计能力、生产率和彻底性、沟通和协作能力：很低低标称高很高极高15分35分55分75分90分n/a很低低标称高很高极高n/a每1年有主要变更,每1个月有次要变更每6个月有主要变更,每2周有次要变更每2个月有主要变更,每周有次要变更每2周有主要变更,每2天有次要变更n/a 程序员能力：能力评价应基于程序员作为小组的能力而不是作为个人能力。主要考虑能力、生产率、彻底性、沟通和协作能力，不考虑程序员的经验。人员连续性：主要根据人员的年周转率来确定：应用经验：根据项目组对应用领域的经验，包括对应用领域工作的经验和类似软件的使用经验确很低低标称高很高极高48%∕年24%／年12%∕年6%／年3%／年n/a很低低标称高很高极高15分35分55分75分90分n/a 定分级：平台经验：平台使用经验对生产率也有影响。平台包括GUI、数据库、网络和分布式中间件等。语言和工具经验：除了编程语言方面的经验外，项目支持工具集方面的经验也影响开发工作量。很低低标称高很高极高≤2个月6个月1年3年6年n/a很低低标称高很高极高≤2个月6个月1年3年6年n/a很低低标称高很高极高≤2个月6个月1年3年6年n/a 16)软件工具的使用：多点开发：主要根据两个因素来划分等级。很低低标称高很高极高编辑编码调试工具简单的前端/后端CASE，很少集成基本生命周期工具，中度集成健壮成熟的生命周期工具，中度集成健壮成熟主动的生命周期工具，与过程、方法、复用的良好集成n/a很低低标称高很高极高分布描述国际多城市和多企业多城市或多企业同一城市或大区域同一建筑或企业完全同处一地沟通描述电话邮件专用电话、传真宽带电子邮件窄带电子邮件窄带电子邮件、视频会议多媒体交互 18)要求的开发进度：这是描述整个项目进度伸缩的成本驱动因子，它度量施加在开发项目组上的进度限制。以相对于标称进度的加速或延长的百分比来划分等级。进度加速表明需要更多的工作量，在早期安排化解风险的措施和细化软件体系结构，在后期完成测试和文档工作；进度延长原则上可以不影响成本，但可能要执行更多的项目管理工作。很低低标称高很高极高标称进度的75%标称进度的85%标称进度的100%标称进度的130%标称进度的160%n/a 早期设计模型的工作量调整早期设计模型用在软件项目的早期阶段，采用了后架构模型成本驱动因子的简化集。每个成本驱动因子结合了后架构模型的几个成本驱动因子。因素描述结合后架构成本驱动因素RCPX产品可靠性和复杂性RELY,DATA,CPLX,DOCURUSE必要的复用RUSEPDIF平台困难程度TIME,STOR,PVOLPERS人员能力ACAP,PCAP,PCONPREX人员经验AEXP,PEXP,LTEXFCIL设施TOOL,SITESCED进度SCED 强调可靠性和文档化很少少有些基本强烈很强烈极强烈产品复杂性很简单简单有些中等复杂很复杂极复杂数据库规模小小小中等大很大极大等级极低很低低标称高很高极高EMi0.490.600.831.001.331.912.72产品可靠性和复杂性（RCPX）时间和存储限制≤50%≤50%65%80%90%平台易变性很稳定稳定有些不稳定不稳定极不稳定等级低标称高很高极高EMi0.871.001.291.812.61平台困难程度（PDIF） 应用、平台、语言和工具经验≤3个月5个月9个月1年2年4年6年等级极低很低低标称高很高极高EMi1.591.331.221.000.870.740.62分析员和程序员能力20分35分45分55分65分75分85分人员连续性45%30%20%12%9%6%4%等级极低很低低标称高很高极高EMi2.121.621.261.000.830.630.50人员能力（PERS）人员经验（PREX） 可复用开发（RUSE）与开发进度限制（SCED）与后架构模型的等级划分一致。TOOL支持少一些简单的CASE工具集基本生命周期工具良好、中度集成健壮、中度集成健壮、良好集成多点开发对多点复杂开发（M/S）有少量支持对复杂的M/S开发有些支持对中等复杂的M/S开发有些支持对中等复杂的M/S开发有基本支持对中等复杂的M/S开发有强力支持对简单的M/S开发有强力支持对同处一地或简单的M/S开发有超强支持等级极低很低低标称高很高极高EMi1.431.301.101.000.870.730.62设备（FCIL） COCOMO-II的进度估算开发产品所花费的时间TDEV由以下公式估算：其中，对于COCOMOII.2000，C=3.67，D=0.28。例如，对于一个开发规模为100KSLOC的正常项目，各成本驱动因子都为1.00，E设为1.15，用后架构模型：PM=2.94×1001.15=586.61（人月） 开发时间的估算为：TDEV=3.67(586.6)(0.28+0.2×(1.15-0.91))=3.67(586.6)0.328=29.7（月）开发所需人数为：就是说，一个规模为100KSLOC的正常的软件项目大约需要20人花30个月完成。 5.6成本预算项目成本预算是项目成本控制的基础，它将项目的成本估算分配到项目的各项具体工作上，以确定项目各项工作或活动的成本定额。制定项目成本的控制标准。规定项目意外成本的划分与使用规则。项目成本预算包括四部分：直接人工费用的预算；咨询服务费用的预算；资源采购费用的预算；意外成本的预算。5.6.1成本预算的概念 成本预算的三大作用项目成本预算是按计划分配项目资源的活动，以保证各项工作能够获得所需的各种资源。在做各项工作的成本预算时，要实事求是：过高会导致项目成本上升，过低会导致因省钱而偷工减料。项目成本预算是一种控制机制：项目成本预算作为项目各项具体工作的全部定额，是度量各项工作在实际实施过程资源使用数量和效率的标准。项目工作的所花费的实际成本应尽量保持在预算成本的限度以内。项目成本预算为项目经理监控项目实施进度提供 了一把标尺。在项目实施的任何时点上，都应有确定的预算成本。根据项目预算成本的完成情况和完成这些预算成本所消耗的实际工期，与完成同样成本额的计划工期相比较，项目经理可以及时掌握项目的进度情况，进行调整。累积费用时间实际成本额计划成本额实际支出线计划支出线观测时点线 5.6.2项目成本预算编制的依据项目成本估算项目成本预算是把项目的成本估算分配到项目的各项工作和活动中，因此必须以项目成本估算为依据。工作分解结构项目成本预算根据工作分解结构分配项目估算成本。项目进度计划项目进度计划（见项目时间管理）详细地安排了各项工作的起始时间和结束时间，是按时间进度分配资金的依据。 5.6.3项目成本预算编制的方法无论使用什么方法和技术来编制项目的成本预算，都必须经过以下几个步骤：分摊项目总成本到项目分解结构的各个工作包中，为每个工作包建立预算总成本。将每个工作包所分得的成本额进一步分配到工作包所包含的各项活动中。确定各项成本支出的时间计划，及每一个时间点对应的累积预算成本（截止到该时间点的每期预算成本额的总和），制定出项目成本预算计划。编制项目成本预算的方法与估算的方法相同。 5.6.4项目成本预算编制的结果项目各项工作或活动的成本预算给出了实施某一项工作或活动的成本定量。在项目的实施过程中，将以此为标准监控各项工作或活动的实际资源消耗量。成本基准计划描述了项目进展时间与项目花费的累积预算成本之间的对应关系。它将作为度量和监控项目实施过程中费用支出的主要依据。 5.7项目成本控制项目成本控制包括分析项目特点，确立项目管理目标；总结同类项目招投标经验，建立招投标的战略、评标与订立合同方法、分析招投标市场及参与者；结合可行性研究、价值工程分析、设计效率分析，采用项目前期评价系统，确定成本控制的方针与办法以及中心激励机制；项目后期评价，经验总结；基于成本基准计划，监视成本执行，等。 5.7.1项目成本控制的概念项目成本控制是指项目组织为保证在变化的条件下实现其预算成本，按照事先拟订的计划和标准，通过采用各种方法，对项目实施过程中发生的各种实际成本与计划成本进行对比、检查、监督、引导和纠正，尽量使项目的实际成本控制在计划和预算范围内的管理过程。项目成本控制的主要内容包括：识别可能引起项目基准计划发生变动的因素，并对这些因素施加影响，以保证这些变化朝着有利的方向发展。 以工作包为单位，监督成本的实施情况，发现实际成本与预算成本之间的偏差，找出产生偏差的原因。对发生成本偏差的工作包，有针对性地采取纠正措施，必要时可以根据实际情况对项目成本基准计划进行适当的调整。将核准的的成本变更和调整后的成本基准计划通知项目的干系人。防止不正确的、不合适的或未授权的项目变更所发生的费用被列入项目成本预算。防止因单纯控制成本而引起项目范围、进度和质量方面的问题，甚至出现更大的风险， 因此成本控制应与项目范围变更、进度计划变更、质量控制紧密结合。有效成本控制的关键是经常及时地分析成本绩效，尽早发现成本差异和成本执行低下的问题。以便在情况变坏之前能够及时采取纠正措施。一旦项目成本失控，在预算内完成项目是非常困难的。如果没有额外的资金支持，那么成本超支的后果就是：要么推迟项目工期，要么降低项目的质量标准，要么缩小项目的工作范围，这都是我们不愿看到的。 5.7.2项目成本控制的依据项目各项工作或活动的成本预算在项目的实施过程中，通常以此为标准，对各项工作的实际成本进行监控。它是进行成本控制的基础性文档。成本基准计划是按时间分段的费用预算计划，可用来测量和监督项目成本的实际发生情况，并能够很好地将成本支出与时间进度联系起来。它是按时间对项目成本支出进行控制的重要依据。成本绩效报告 是记载项目预算实际执行情况的资料。它的主要内容包括项目各个阶段或各项工作的成本完成情况，是否超出了预先分配的预算，存在哪些问题。分析项目成本绩效的基本指标为项目计划作业的预算成本。是按预算价格和预算工作量分配给每一项作业活动的预算成本。累积预算成本。将每一个工作包的总预算成本分摊到项目工期的各个时间分段，计算出截止到某个时点的各期预算成本的累计数，作为该时点的累积预算成本。 累积实际成本。项目已完成工作的实际成本，是截止到某一时点的各期发生的实际成本的累积数。累积盈余量。已完成工作的预算成本，是将每一个工作包的总预算成本乘以该工作包的完工比率所得的乘积。成本绩效指数。衡量成本效率的指标，是累积盈余量与累积实际成本的比值，反映了用多少实际成本才完成了一单位预算成本的工作量。成本差异。累积盈余量与累积实际成本之间的差异。 变更申请是项目干系人以口头或书面的方式提出的有关变更项目工作内容和成本的请求。项目的任何变动都要经过严格的评估和批准，并获得资金的支持。项目经理要根据变更后的项目工作范围或成本预算来对项目成本实施控制。项目成本管理计划这是识别和分析在项目的实施过程中可能会引起项目成本变化的各种潜在因素，提出解决和控制方案，确保在预算范围内完成项目的一个指导性文档。 5.7.3项目成本控制的方法成本变更控制系统该系统主要包括三部分：成本变更申请核准成本变更申请变更项目成本预算根据严格的项目成本变更控制流程，对变更申请进行评估，确定变更所导致的成本代价和时间代价，再将评估结果报告给客户，由他们判断是否接受这些代价，核准变更申请。变更申请被批准后，还要调整相关工作的成本预 算，对成本基准计划作相应修改。要注意，成本变更控制系统应与其他变更控制系统相协调，成本变更的结果应与其他变更的结果相协调。绩效测量主要用于估算实际发生的变化的大小。常用的绩效测量技术有：不确定性分析投资项目的不确定性分析就是通过计算分析，确定各种不确定因素的变化对项目经济效益的影响程度的一种经济分析方法。 盈亏平衡分析各种不确定因素（如投资、成本、销售量、产品价格、项目生命周期等）的变化会影响项目方案的经济效果。当这些因素的变化达到某一个临界值时，恰好使方案达到盈亏平衡。盈亏平衡分析目的就是要在一定的市场、生产能力及经营管理的条件下，找出这个临界值，判断项目对不确定因素变化的承受能力，为决策提供依据。敏感性分析通过测定一个或多个不确定因素的变化所导 致的决策评价指标的变化幅度，了解各种因素的变化对实现项目预期目标的影响程度，从而对外部条件发生不利变化时项目方案的承受能力做出判断。敏感性分析在一定程度上就各种不确定因素的变动对项目经济效果的影响做了定量描述，这有助于了解项目方案的风险，有助于确定在决策过程中及在方案实施过程中需要重点研究与控制的因素。缺点是没有考虑未来发生变动的概率。概率分析通过研究各种不确定因素发生不同幅度变 动的概率分布及其对项目方案经济效果的影响，对项目方案的净现金流量及经济效果指标做出某种概率描述，从而对项目方案的风险做出比较准确的判断。(5)挣值分析是一种综合范围、时间、资源和项目绩效测量的方法。通过与计划完成的工作量、实际挣得的收益、实际的成本进行比较，确定成本、进度是否按计划执行。（参看项目的集成管理）计算机工具如项目管理软件、电子表格等。用于对计划费 5.7.4项目成本控制的结果用和实际费用进行跟踪和比较，预测费用变更后的结果。修正后的成本估算根据实际需要修改和更新项目的成本估算。成本预算更新对原来的成本预算计划进行修订和调整，包括对成本基准计划进行必要的修改和更新。纠正措施使项目未来工作所花费的实际成本被控制在项目计划成本以内所采取的纠偏活动。'