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

软件工程管理第五章软件工程本钱管理SoftwareProjectCostManagement工程本钱管理是工程管理的一个重要组成局部，它是指在工程的具体实施过程中，为了保证完成工程所花费的实际本钱不超过其预算本钱而展开的工程本钱估算、工程预算编制和工程本钱控制等方面的管理活动。必须要加强对工程实际发生本钱的控制。一旦工程本钱失控，就很难在预算内完成工程。本钱失控的情况常常是以下原因造成的：本钱估算和本钱预算不够准确细致；许多工程在本钱估算、本钱预算、本钱控制方法上没有统一的标准可循。思想上的误区：实际本钱超出预算是必然的。5.1工程本钱5.2工程本钱管理的内容5.3资源方案5.4本钱估算5.5软件工程的本钱估算5.6本钱预算5.7工程本钱控制5.1工程本钱一般工程的本钱主要由工程直接本钱、管理费用和期间费用等组成。工程直接本钱是指与工程有直接关系的本钱费用。例如，直接人工费、直接材料费、其他直接费用等。管理费用是指为了组织、管理和控制工程所发生的费用。例如，管理人员费用支出、差旅费、固定资产和设备使用费、办公费、医疗保险费，以及其他一些间接费用。5.1.1工程本钱期间费用是指不受工程业务量增减影响的费用，如日常行政管理费、销售费等。软件工程由于其自身的特点，对整个工程的预算和本钱控制更为困难。工程经理为了控制整个工程的预算和支出，必须正确估算软件开发的本钱费用。软件工程的本钱有4种：硬件/支持软件本钱：包括工程所需的所有硬件设备、系统软件、数据资源的购置、运输、储存、安装、测试的费用。对于进口设备，还要包括国外运费、保险费、进口关税和增值税等费用。差旅及培训费：培训费用包括开发人员培训费和用户培训费。软件开发本钱：人工本钱是最主要的软件开发本钱。在软件开发工程中，付给软件工程师的人工费用占了开发本钱的绝大局部。工程管理费用：用于工程组织、管理、控制的费用支出。尽管硬件/支持软件本钱、差旅及培训费用可能在工程总本钱中占较大比例，但最主要的本钱还是在开发过程中所花费的工作量及相应的代价。软件产品生产不是一个重复的制造过程，而是以“一次性〞开发过程的花费来计算的。软件工程开发本钱的估算应以整个工程软件开发全过程所花费的人工代价作为计算的依据，并可以按与软影响工程本钱的因素 件生命周期对应的阶段进行估算。工程质量对本钱的影响 质量对本钱的影响可通过质量本钱表示。质量本钱由质量故障本钱和质量保证本钱构成。质量故障本钱是指为了排除因产品量差而产生的故障，保证产品重新恢复功能的费用。质量保证本钱是指为了保证和提高产品质量，采取相应技术措施而消耗的费用。质量故障本钱与质量保证本钱是相互矛盾的。质量保证本钱高，故障就少，质量故障本钱就低。反之亦然。因此，需要建立一个动态平衡。质量总成本质量保证成本质量故障成本质量成本工期对本钱的影响 工程费用由直接费用和间接费用组成。一般工期越长，工程的直接费用越低，而间接费用越高。反之，缩短工期，需要更多的、技术水平越高的工程师，直接本钱费用就会增加。项目总成本项目工期总成本间接费用成本直接费用成本管理水平对本钱的影响 管理水平高，可以提高工程预算准确度，加强对工程预算的执行和监管，且对工期的控制可严格限制在方案许可的范围内。这样可以有效地控制由于设计方案和工程方案的变更所造成的本钱变动。因此，管理水平对工程本钱有关键影响。人力资源对本钱的影响 具有高技术能力和高技术素质的人才，人力本钱较高，但可以有高生产率、可构建高质量产品、且工期较短，这样从整体上会降低本钱。 对于一般人员，还需要技术培训。对工程的理解 及生产率相对低下，工期会延长，造成本钱的增加。因此，人力资源是重要的影响因素。价格对本钱的影响 中间产品和效劳、市场人力资源、硬件、软件的价格也对本钱产生直接的影响。因为价格对工程本钱预算的影响很大。5.2工程本钱管理的内容工程本钱管理主要由工程资源方案的编制，本钱估算，本钱预算和本钱控制等4个过程组成，以下图给出了这些过程的主要框架。以上四个过程相互影响、相互作用，有时也与外界的过程发生交互影响，根据工程的具体情况，每一过程由一人或数人或小组完成，在工程的每个阶段，上述过程至少出现一次。某些工程，特别是小工程，资源方案、本钱估算和本钱预算三者紧密相连，可把这些过程视为一个过程处理。1.输入

•工作分解结构

•历史资料

•范围说明

•资源库描述

•组织策略

2.工具与技术

•专家判断

•头脑风暴法

3.输出

•资源需求计划1.输入

•工作分解结构

•资源需求

•资源单价

•活动时间估计

•历史资料

•财务图表

2.工具与技术

•类比估计

3.输出

•成本估算

•详细说明

•成本管理计划1.输入

•成本估算

•工作分解结构

•项目进度

2.工具与技术

•成本估算工具与方法

3.输出

•基准成本项目成本管理1.输入

•基准成本

•执行情况

•变更要求

•成本管理计划

2.工具与技术

•成本变更控制系统

•执行情况测量

•另外的计划

•项目管理软件

3.输出

•修改后成本估算

•更新的预算

•纠正措施

•完成项目所需成本估算

•经验与教训成本控制成本预算成本估算资源计划5.3资源方案资源方案是确定为完成工程活动所需要的各种资源的种类、数量和时间，包括人力、财力和物力资源，完成资源的配置。在任何工程中，资源并不是无限制的，也不是可以随时随地能够获取的，工程的本钱、可起作用的技术水平、时间进度等都受到可支配资源的限制。在工程进展过程中，如何合理配置和优化资源使用，是工程管理的重要问题。 资源方案编制过程的依据工作分解结构WBS 它是编制资源方案所依据的最重要的根底，根据工作分解结构，明确完成工程各项工作的资源需求。历史信息 记录了以前类似工程的资源需求、资源方案、工程实施时实际消耗的资源等方面的有关情况。 充分利用和借鉴相关历史信息来编制工程资源需求方案，可以提高资源需求方案的准确性，还可以减少编制的工作量。范围说明 范围说明描述了工程工作，界定了工程目标。这两者均应在编制资源方案时考虑。 在编制资源方案时，逐项审查方案的资源需求能否满足工程的各项工作和工程目标的实现，对疏漏的资源需求要及时补充。工程资源库描述 说明了在工程实施过程中具体有哪些资源可以利用，包括人员、设备、材料、资金等。 在制定工程资源技术时，必须从工程资源库中了解这些相关的资源供给信息，分析现有资源储藏能否满足工程实施的需要。5.3.2工程资源方案编制的方法组织策略 指有关人员的招聘，设备或材料的租赁或采购策略等。专家判断法 由工程本钱管理专家根据以往类似工程的历史信息和对当前工程的理解，经过严密思考计算，进行合理预测，制定工程资源方案。 这样的专家应具有专业知识和受过专门训练，可从工程组织中的其他部门、咨询机构、专业技术协会获得。定额法 当工程实施所需要的某些资源〔包括人力、设备、材料等〕有国家或行业的统一标准定额，或有权威部门制定的规那么时，应以这些统一的定额或规那么为标准来制定工程资源需求方案。资料统计法 参考以往类似工程的历史统计数据资料，计算并确定工程资源需求方案。 它要求所采用的历史信息应与当前工程有可比性，并信息足够详细，有很强的可操作性。适合于创新性不强的工程。利用工作分解结构 根据工作分解结构所列出的工程全部工作的一览表，确定出每一项任务所需的各种资源，再将其汇总，编制出工程资源需求方案。这是最可行的一个方法。资源均衡法 这是平衡各种资源在工程各个时期投入的一种常用方法。在保证工程完工时间不变的情况下可以调整资源的需求情况，控制资源投入时间，尽可能均衡使用各种资源来满足工程要求的完工进度。工程资源方案编制的结果编制工程资源方案的结果是编制出工程资源需求方案，对工程所需的各种资源的需求情况和使用方案给出详细的描述。工程资源的需求安排应当分解落实到具体的工作任务上。5.4本钱估算工程本钱估算是工程本钱管理的核心内容。通过本钱估算，分析并确定工程的估算本钱，以此为根底进行工程的本钱预算，进而展开对工程进行本钱控制等一系列管理活动。工程本钱估算是指为了实现工程目标，完成工程的各项活动，根据工程资源方案中确定的各种资源需求〔人员、设备、材料等〕和市场上各种资源的价格，对完成工程所必需的各种资源的费用作出近似的估算。5.4.1工程本钱估算的概念简言之，工程本钱就是工程形成全过程所耗用的各种费用的总和。工程定义与决策本钱〔可行性研究本钱〕工程设计本钱〔工程设计所花费本钱〕工程获得本钱〔为获取外部资源，如广告、招投标、询价等所花费本钱〕工程实施本钱〔工程实施过程所花费的硬/软件设施与支持平台、人工、咨询本钱以及一定数量的意外本钱的总和〕。工程本钱的消耗与工程所耗用资源的数量、质量和价格有关，与工程工期的长短有关，与工程结果的质量有关，与工程范围的广度／深度有关。工程本钱估算的步骤：识别与分析工程本钱的构成要素。如人工费、咨询费、设备费、软件费等。根据已识别的本钱构成要素，估算每一个要素的本钱。分析本钱估算的结果，找出可以互相补偿的本钱，协调各种本钱之间的比例关系。例如，设计质量的提高可能会大量减少工程实施阶段的本钱。因此，工程设计本钱增加会带来工程实施本钱的降低，两种本钱之间存在互相补偿的关系。因此，在工程本钱估算过程中，要积极寻找这种有补偿效应的本钱，仔细研究本钱之间的这种此消彼长的关系和量值对工程总本钱造成的影响，努力使工程预期收益最大化。本钱估算要以资源方案中所列的工程资源需求和工程组织对这些资源的预计价格为根底。工程本钱估算的依据为：工作分解结构资源需求方案：资源数量和质量标准资源价格：市场价格或历史价格工程本钱估算的依据工程本钱估算的方法工程持续时间：时间价值经济形势：通货膨胀和利率可以根据以往工程所积累的历史信息为根底进行工程本钱估算。但工程之间总是存在一定差异，很少有简单重复，因此以往工程的本钱只能作参考。通常可以采用以下方法进行本钱估算。类比估算法工程管理人员收集以往类似工程的有关历史信息，包括规模〔代码行数或功能点数〕、费用、人力、时间、物价等；会同有关本钱估算专家对当前工程的总本钱进行估算；将估算结果按照工程的工作分解结构的层次传递给直接下层的管理人员，由他们对自己负责的工作和活动的本钱进行估算；继续向下一层管理人员传递他们的估算结果，直到工程的基层人员。 这种方法又称“自顶向下估算法〞，其主要思想是从工程的整体出发，首先进行类推，再做分解。估算人员根据以前已完成的类似工程所消耗的总本钱〔总工作量〕，推算当前工程的总本钱〔总工作量〕，然后按比例将它分配到各工作分解单元中去，再来检验它是否能满足要求。分解比例参看下表。优点是简单易行，花费少。当工程详细资料难以得到时，这种方法行之有效。缺点是类似工程很难找，估算准确度较差。对工程中的特殊困难估计缺乏。工料列表法基层管理人员计算出每个工作单元的生产本钱；将各个工作单元的生产本钱自下向上逐级累加，汇总到工程的高层管理者；工程的高层管理人员计算出工程的总本钱。这种估算方法又称“自底向上估算法〞。依据工程的工作分解结构，先“分解〞，再对每个分解后的工作单元采取“类比〞或其他方法进行估算，最后汇总。优点是结果十分详细，准确性高。缺点是实际操作非常耗时，费用较高。而且通常估算值缺少各项子任务之间相互联系所需要的工作量，还缺少许多与工程实施有关的管理工作量.从心理学角度，通常会陷于一种恶圈：进行第一轮估算的基层管理人员会认为上级管理人员会以一定比例削减他们的本钱估算，他们会过高估算自己工作的资源需求。基于这种情况，上层管理人员真的会认为应该削减估算的本钱，这又恰恰证实了基层管理人员的疑心。参数模型法利用工程的一些特性参数〔如代码行或功能点〕建立数学模型来估算工程本钱。这种方法有一组工程本钱估算关系式，用它们对工程总本钱作出近似估算。这种估算只针对影响工程总本钱程度最大的本钱变量进行估算，不考虑一些细节性本钱因素。例如，考虑建立一个局域网系统的工程本钱，先估算建造一个标准节点的本钱作为系数因子，以标准节点数作为变量因子，两者相乘，得到工程的总本钱。优点是用这种方法估算工程本钱的速度很快，只需要一小局部信息。缺点是不同的估算模型估算出的结果差异较大，因此，选择适宜的模型以保证估算结果的准确性至关重要。为保证工程本钱模型的适用性，在建立本钱模型时，要注意：保证建立参数模型时所依据的历史信息的准确性；模型中的一些重要参数必须量化处理。根据工程的实际情况，对参数模型可按适当的比例调整。工程本钱估算的结果利用工程本钱管理软件利用工程本钱管理软件，可以通过直接输入与工程本钱有关的数据，或自定义工程本钱函数，计算出工程本钱的估算结果。目前几乎所有大型工程的本钱估算，都是利用这类工程本钱估算软件计算得到的。工程本钱估算结果文件 它以摘要或详细的形式描述了：实施工程必须的所有资源〔人员、资金、硬/软件工具、可复用构件等〕，以及这些资源的数量、质量标准、本钱。为应付工程可能遇到的意外事件〔通货膨胀、意外事故、原材料失窃等〕所支付的具有不可预见性的意外本钱。 本钱估算结果通常用货币量单位“元〞表示，但有时为了管理方便，用工作量“人日〞或“人月〞来表示。相关支持性细节文件和结果 它对工程本钱估算的依据进行详细说明。工程工作范围说明。工程本钱估算的根底和依据〔采用的估算方 法、参考的国家有关规定、各种中间计算的结果等〕。工程本钱估算的假设〔工程所需资源价格水平的估计、工程资源消耗定额的估计、工程实施人员的生产率等〕。工程本钱估算结果的误差范围。工程本钱管理方案通常，在工程管理中用本钱目标衡量工程绩效。但在工程开始后，会发生各种无法预见的情况，随时可能危及工程本钱目标的实现。例如，人员流失、设备购进渠道不通、支持工具有缺陷等。为实现在本钱目标范围内完成工程可交付成果，必须对如何管理和控制工程本钱变动的方案进行事先安排，即“有备无患〞。管理方案的主要内容：识别并分析可能出现的各种意外事件；预测可能会发生损失的概率和程度；说明如何对费用偏差进行管理和如何对意外本钱的使用进行管理；提出方案和解决方案。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.21050

646

…

………………

…

………………需要注意的是，在表格中记载的工作量和本钱是整个软件工程的活动〔分析、设计、编码和测试〕，而不仅仅是编码活动。对于每一个工程，可以根据表格中列出的根本数据计算简单的面向规模的生产率和质量的度量。生产率＝KLOC／PM〔人月〕质量＝错误数／KLOC本钱＝元／LOC文档＝文档页数／KLOC2.面向功能的度量面向功能的软件度量是对软件和软件开发过程的间接度量。面向功能度量主要考虑程序的“功能性〞和“实用性〞，而不是对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++64SQL125.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.对专家的估算结果分类摘要。专家对此估算值另做一次估算。在综合专家估算结果的根底上，组织专家再次无记名地填写表格。比较两次估算的结果。假设差异很大，要通过查询找出差异的原因。上述过程可重复屡次。最终可获得一个得到多数专家共识的软件规模〔源代码行数〕。最后，通过与历史资料进行类比，根据过去完成软件工程的规模和本钱等信息，推算出该软件每行源代码所需要的本钱。然后再乘以该软件源代码行数的估算值，就可得到该软件的本钱估算值。软件人工本钱估算的经验模型软件开发人工本钱估算是依据开发本钱估算模型进行估算的。开发本钱估算模型采用经验公式来预测软件工程方案所需要的本钱、工作量和进度数据。根据模型中估算变量的依存关系，可把模型分为静态模型和动态模型。静态模型从一个唯一的估算变量〔如源代码规模〕计算其他变量〔如工作量和时间〕，且所有计算公式对于所有场合都一样。动态模型中所有变量是相互依存的。根据根本估算变量的多少，模型又可分为单变量模型和多变量模型。单变量模型只用一个估算变量计算出其他所有变量；多变量模型需要多个变量来描述过程。典型的静态单变量估算模型是通过对从以前的软件工程收集到的数据进行回归分析导出的。其总体结构具有以下形式： 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.0545FPAlbrecht-Gaffney模型E=60.627.72810-8FP3Kemerer模型E＝585.7+15.12FPMaston-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)bEAF项目类型工作量进度组织型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.32EAF称为工作量调节因子，

本钱驱动因素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=43+74+56+715+610=235假设采用C编程，那么源代码行数为： SLOC=235128=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的比率来衡量产生和维护这些测试数据所需工作量。很低低标称高