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

软件项目管理,第五章 软件项目成本管理 Software Project Cost Management,项目成本管理是项目管理的一个重要组成部分，它是指在项目的具体实施过程中，为了保证完成项目所花费的实际成本不超过其预算成本而展开的项目成本估算、项目预算编制和项目成本控制等方面的管理活动。 必须要加强对项目实际发生成本的控制。一旦项目成本失控，就很难在预算内完成项目。 成本失控的情况常常是以下原因造成的： 成本估算和成本预算不够准确细致； 许多项目在成本估算、成本预算、成本控制方法上没有统一的标准可循。 思想上的误区：实际成本超出预算是必然的。,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 个过程组成，下图给出了这些过程的主要框架。 以上四个过程相互影响、相互作用，有时也与外界的过程发生交互影响，根据项目的具体情况，每一过程由一人或数人或小组完成，在项目的每个阶段，上述过程至少出现一次。 某些项目，特别是小项目，资源计划、成本估算和成本预算三者紧密相连，可把这些过程视为一个过程处理。,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 (commercial off-the-shelf)。 具有完全经验的构件：现有的为以前类似的项目建立的规格说明、设计、代码或测试数据。由于当前项目的成员在这些构件所代表的应用领域中有丰富的经验，应用这类有完全经验的构件时风险较小。,具有部分经验的构件：现有的为以前项目建立的规格说明、设计、代码或测试数据。这些项目与当前的项目相关，但需做实质上的修改。由于当前项目的成员在这些构件所代表的应用领域中仅有有限的经验，因此对于这类有部分经验的构件进行修改会有相当程度的风险。 新构件：项目组为满足当前项目的特殊需要而必须专门开发的软件构件。 最好能尽早说明软件的资源需求，这样才能进行软件可选方案的技术评估，并及时获得所需的构件。,3. 硬件资源,硬件是作为软件项目的一种工具而投入的。 宿主机（Host） 软件开发时使用的计算机及外围设备； 目标机（Target） 运行已开发成功软件的计算机及外围设备； 其他硬件设备 专用软件开发时需要的特殊硬件资源； 宿主机和必要的软件工具构成软件开发环境。这样的开发环境能够支持多种用户的需要，且能保持大量的由软件开发组成员共享的信息。 宿主机与目标机可以是同一种机型。,4. 软件资源,软件人员在软件开发过程中使用了许多软件工具。将这些软件工具集成就叫做计算机辅助软件工程 (CASE)。 业务系统计划工具集 项目管理工具集 支持工具 文档生成工具、网络系统软件、数据库、电子邮件、通报板，以及配置管理工具 分析和设计工具 编程工具 集成和测试工具,原型化和模拟工具 维护工具 框架工具 这些工具能够提供建立集成项目支撑环境（IPSE）的框架。,5.5.3 软件度量,软件项目估算的依据是对以往项目进行度量所得到的有关工作量和时间的数据。 只要事先建立特定的度量规程，很容易做到直接度量软件所需要的成本和工作量、产生的代码行数等。 软件项目度量分为面向规模和面向功能度量：,1. 面向规模的度量,面向规模的度量是对软件产品和软件开发过程的直接度量。 可以建立一个面向规模的数据表格来记录项目的某些信息。该表格列出了在过去几年完成的每一个软件开发项目和关于这些项目的相应面向规模的数据。 例如，项目aaa-01的规模为 12.1 KLOC (千代码行)，工作量用了 24 个人月，成本为168,000元，文档为 365 页，在交付用户使用后第一年内发现了 29 个错误，有 3 个人参加了项目 aaa-01 的软件开发工作。,面向规模的数据表格,需要注意的是，在表格中记载的工作量和成本是整个软件工程的活动（分析、设计、编码和测试），而不仅仅是编码活动。 对于每一个项目，可以根据表格中列出的基本数据计算简单的面向规模的生产率和质量的度量。 生产率 KLOCPM（人月） 质量 错误数KLOC 成本 元LOC 文档 文档页数KLOC,2. 面向功能的度量,面向功能的软件度量是对软件和软件开发过程的间接度量。 面向功能度量主要考虑程序的“功能性”和“实用性”，而不是对 LOC计数。 该度量是一种叫做功能点方法的生产率度量法，利用软件信息域中的一些计数和软件复杂性估计的经验关系式而导出功能点 FP。,面向功能的数据表格,功能点计算,确定五个信息域的特征，并在表格中相应位置给出计数。 用户输入数：各个用户输入是面向不同应用的输入数据。 用户输出数：各个用户输出是面向应用的输出信息，包括报告，屏幕信息，错误信息等。在报告中的各个数据项不应再分别计数。 用户查询数：查询是一种联机的交互操作，每次询问/响应具备应计数。,文件数：每一个逻辑的主文件（即数据的逻辑组合）都应计数。它可以是一个大数据库的一部分，也可以是一个单独的文件。 外部接口数：与系统中其他设备（如磁盘文件）通过外部接口读写信息次数均应计数。 一旦收集到上述数据，下一步确定与每一个计数相关的复杂性值（加权因子）。 一个信息域是简单、平均还是复杂，由使用功能点方法的机构自行确定，从而计算出加权计数。 计算功能点，使用如下的关系式： FP 总计数( 0.650.01SUM( Fi ) ) 总计数是所有加权计数项的和；,SUM( Fi ) 是求和函数: Fi（i114）是复杂性校正值，它们通过逐一回答如下提问来确定。 F1 系统是否需要可靠的备份和恢复？ F2 是否需要数据通信？ F3 是否有分布处理的功能？ F4 是否性能成为关键？ F5 系统是否运行在现存的高度实用化的操作环 境中？ F6 系统是否需要联机数据项？ F7 联机数据项是否需要建立多重窗口显示和切 换，以完成处理输入处理。,F8 主文件是否联机更新？ F9 输入、输出、文件、查询是否复杂？ F10 内部处理过程是否复杂？ F11 是否需要将程序代码设计成可复用的？ F12 设计中是否包括了转移和安装？ F13 系统是否设计成可以重复安装在不同机构中? F14 系统是否设计成易修改和易使用？ 每个问题的回答按复杂性校正值给出(05)。 复杂性校正值 Fi 的取值05： = 0 没有影响 = 1 偶然的 = 2 适中的 = 3 普通的 = 4 重要的 = 5 极重要的,一旦计算出功能点，就可仿照LOC的方式度量软件的生产率、质量和其它属性： 生产率 FPPM（人月） 质量 错误数FP 成本 元FP 文档 文档页数FP 功能点度量是为了商用信息系统应用而设计的。,特征点度量（Feature Points）可以用于系统和工程软件应用 特征点度量适合于算法复杂性高的应用。而实时处理、过程控制、嵌入式软件应用的算法复杂性都偏高，因此适合于特征点度量。 为了计算特征点，可以象功能点计算那样，对信息域值进行计数和加权。此外，特征点度量要对一个新的软件特征 “算法” 进行计数。 计算特征点可使用一个计算表格。对于每一个度量参数只使用一个权值，并且使用 FP总计数( 0.650.01SUM( Fi ) ) 来计算总的特征点值。,特征点度量计算表格,3. 协调不同的度量方法,代码行数和功能点之间的关系依赖于用来实现软件的程序设计语言和设计质量。 下面给出使用各种程序设计语言建立一个功能点所需要的平均代码行数的粗略估算。,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.5FPPM，则项目的总工作量是： 工作量 3105.5 56 PM 作为LOC和FP估算的实例，考察一 个为CAD应用而开发的软件包。 系统定义评审指明，“软件是在一个工作站上运行，其接口必须使用各种计算机图形设备，包括鼠标器、数字化仪、高分辩率彩色显示器和激光打印机。”,在这个实例中，使用 LOC 做为估算变量。 根据系统规格说明, 软件范围的初步叙述如下 “软件从操作员那里接收 2 维或 3 维几何数据。 操作员通过用户界面与 CAD 系统交互并控制它，这种用户界面将表现出很好的人机接口设计特性。所有的几何数据和其它支持信息保存在一个CAD数据库内。要开发一些设计分析模块以产生在各种图形设备上显示的输出。软件要设计得能控制并与能各种外部设备，包括鼠标器、数字化仪、激光打印机和绘图仪交互。”,经过分解, 识别出下列主要软件功能： 用户界面和控制功能 二维几何造型 三维几何造型 数据库管理 计算机图形显示功能 外设控制PC 设计分析模块 通过分解，可得到如下估算表,从历史的基线数据求出生产率度量，即行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的估算模型,E5.2(KLOC)0.91 Walston-Felix模型 E = 5.5+0.73(KLOC)1.16 Bailey-Basili模型 E3.2(KLOC)1.05 Boehm基本模型 E5.288(KLOC)1.047 Doty模型 （针对 KLOC 9 的情况） 除上述关系以外，大多数估算模型均有某种形式的项目调整措施，使得 E 能够根据其他的项目特性（如问题的复杂性、开发人员的经验、开发环境等）加以调整。,(2) 面向FP的估算模型,E-13.39+0.0545FP Albrecht-Gaffney模型 E = 60.627.72810-8 FP3 Kemerer模型 E585.7+15.12FP Maston-Barnett-Mellichamp模型 从以上模型可知，每一个模型对于相同的 LOC或 FP 值，会产生出不同的结果。 这意味着使用这些估算模型时，必须根据当前项目的需要，对模型加以调整。,2. Putnam模型,Putnam 模型是一种动态多变量模型。适用于大型项目，也可用在一些较小的软件项目中。 它是假定在软件开发的整个生存期中工作量有特定的分布。大型软件项目的开发工作量分布可以用 Rayleigh-Norden 曲线表示。 用该曲线可以导出一个“软件方程”： td 是开发持续时间 (年)， K是整个软件生命周期的工作量 (人年)，L是源代码行数 (LOC)，Ck 是技术状态常数，因开发环境而异。,技术状态常数Ck的取值,3. COCOMO 81模型 （COnstructive COst Model 81）,结构型成本估算模型是一种精确、易于使用的成本估算方法。 DSI (Delivered Source Instruction) 定义为代码的源程序行数。若一行有两个语句，则算做一条指令。它包括作业控制语句、格式语句和数据声明，但不包括注释语句。 KDSI1024 DSI MM (Man-Months) 表示开发工作量（人月）。 TDEV (Time of Development) 表示开发进度。它由工作量决定（月）。,(1) COCOMO 81模型的限制,模型成本估算涵盖的开发期，开始于产品设计阶段之初，终止于集成与测试阶段之末。其他阶段的成本和进度单独估算。 模型成本估算仅包含在开发期间工作分解结构中的活动，其中包含了管理和文档编制的工作量，但不包含用户培训、安装计划、移植计划等相关工作量。 模型估算包括了项目中所有直接计费的劳动力的活动，包括项目经理和程序库管理员，但不包括计算中心操作员、人事部门职员、秘书、高层管理人员、房屋管理员等。,(2) COCOMO 81模型中项目的分类,特 性,COCOMO 81模型分类,COCOMO模型按其详细程度分成三级： 基本COCOMO模型 中间COCOMO模型 详细COCOMO模型,基本 COCOMO 模型是静态单变量模型，用源代码行数(KDSI) 为自变量的经验函数计算软件开发工作量。 中间 COCOMO 模型在用 KDSI 为自变量的函数计算软件开发工作量（称为名义工作量）的基础上，用涉及产品、硬件、人员、项目等方面的影响因素调整工作量估算。 详细 COCOMO 模型包括中间COCOMO模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中每一阶段（分析、设计等）的影响。,(3) 基本COCOMO模型,基本COCOMO模型的标称工作量和进度公式 按这些公式得到的估算实例参看下表。它总结了每一种软件项目开发模式和不同规模产品中估算出来的工作量、生产率、开发进度等。 产品规模：小型(2KDSI), 中小型(8KDSI), 中型(32KDSI), 大型(128KDSI), 超大型(256KDSI)。,标准规模产品的基本COCOMO估算,(4) 中间COCOMO模型,进一步考虑 15 种影响工作量的因素（称成本驱动因素），通过定下乘法因子，修正COCOMO 标称工作量公式和进度公式计算的结果，可以更合理地估算软件（各阶段）的工作量和进度。 中间 COCOMO 模型的标称工作量与进度公式计算公式：MM = a (KDSI) b EAF,EAF称为工作量调节因子， 成本驱动因素 fi 产品因素：软件可靠性、数据库规模、产品复杂性 硬件因素：执行时间限制、存储限制、虚拟机易变性、环境周转时间 人的因素：分析员能力、应用领域实际经验、程序员能力、虚拟机使用经验、程序语言使用经验 项目因素：现代程序设计技术、软件工具的使用、开发进度限制,虚拟机是指为完成某一软件任务所使用硬、软件的复合体。 环境周转时间是指从用户输入到运算结果返回的时间。,例1. 一个 32 KDSI 的声音输入系统是一个输入原型，或是一个可行性表演模型。所需可靠性非常低。把此模型看做半独立型软件。则有 MM 3.0（32）1.12 146 又查下表知 f10.75，其它 fi1.00，则最终有 MM 1460.75 110. 例2. 一个规模为10 KDSI 的商用微机远程通信的嵌入型软件，使用中间 COCOMO 模型进行成本估算。 程序标称工作量 MM标称 2.8 (10)1.20 44.38（MM）,工作量调节因子 程序实际工作量 MM = MM标称EAF = 44.381.16 = 51.48（MM）,开发所用时间 TDEV 2.5 (51.5)0.32 8.9 （月） 如果分析员与程序员的工资都按每月6,000美元计算，则该项目的开发人员的工资总额为 51.56,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）的工作量因素分级表（模块层）如表所示。 使用这些表格，可以比中间COCO MO模型更方便、更准确地估算软件开发工作量。,软件可靠性成本驱动因素分级表 (子系统层),0.800.150.800.300.800.300.600.25 = = 0.75,各阶段工作量分配比例,产品复杂性成本驱动因素分级表 (模块层),可靠性要求不同导致项目活动的差异,4. COCOMO-II模型,COCOMO 81模型适用于专用的定制的软件项目，它建立在“瀑布模型”的过程框架上。 1997年 Boehm 等人提出来的 COCOMO-II 模型则适用于广泛汇集各种技术的软件项目，如商用软件、面向对象软件、通过螺旋型或演化型开发模型制作的软件。 现在系统开发有三个关注点： 应用程序生成器：事先为用户编程创建了大量程序包，使用应用组装工具来集成。 应用组装：使用通用构件快速组装以得到应,用系统。 系统集成：对系统的每一部分可用应用组装方式来开发，再做系统的集成。适用于规模较大、嵌入较多且先例较少的系统的开发。 COCOMO II 模型通过三个不同的模型分别对三个不同的阶段进行估算： 应用组装模型（估算早期原型开发工作量） 早期设计模型（估算探索和选择可用的系统软件体系结构和操作所用工作量） 后架构模型（估算实际系统开发的工作量）,(1) 应用组装模型,应用组装模型用于估算原型制作的工作量。 适用场合如：用户界面的原型开发，软件和系统交互考虑，性能评估和技术成熟度评价等。 模型使用“对象点”，而不用“源代码行”或“功能点”进行估算。 对象点是1991年由 Banker、Kauffman和Kumar等人提出的。它类似于功能点，是一种软件间接度量。根据（用户界面）屏幕（screen）数、报告（report）数、建造应用所需使用的第三代语言（3GL）构件数来计数。,屏幕、报告和3GL构件统称为元素。 2000年Boehm等人在COCOMO II: 2000中把“对象点”改为“应用点”，以避免概念的混淆。 应用组装模型估算的步骤： 评估应用计数：估算组成该应用的屏幕、报告和3GL构件数目。 确定复杂性级别：对于每一个屏幕、报告、3GL构件，根据一些特征，把它们划分到简单、中等和困难等3个复杂性级别。 其中，srvr 为与屏幕或报告相关联的服务器（主机或同等物）数据表数，clnt 为与屏幕或报告相关联的客户机（个人工作站）数据表数。,表1 屏幕应用点复杂性等级,每一个屏幕可以展开为若干视图（views）。根据屏幕所涉及视图数和数据表数，可以确定该屏幕的复杂性等级。,表2 报告应用点复杂性等级,每一个报告可以包括有若干节（sections）。根据报告所涉及节数和数据表数，可以确定该报告的复杂性等级。,3) 加权：根据每一个元素的复杂性级别，参照表3对其加权。 4) 计算应用点数：将每一个元素的计数乘以权值得到该元素的加权计数，再将各个元素的加权计数累加，得到总的应用点计数。,表3 应用点复杂性加权,估计项目复用的百分比 r：如果项目在开发中使用了构件或复用了以前的软件，再估计复用的百分比 r。 计算要开发的新应用点数：通过以下公式得到调整后的新应用点数NAP。 NAP =（应用点计数）（100 r）/ 100 例如，一个应用程序包含 840 个应用点，其中20%可以通过使用现成的构件来提供，那么调整后的新应用点（NAP）的得分将是 NAP = 840(100 - 20) / 100 = 672 7) 确定生产率：其单位是: PROD = NAP人月,表4 对象点/工作量转换表,8) 估算工作量 PM = NAP / PROD 例如，一个应用程序有 672 个新应用点，开发环境的生产率是正常的，则项目的估计工作量为： PM = 672 / 13 = 52 （人月）,(2) 早期设计模型和后架构模型的标称工作量估算公式,估算功能点。功能点通过量化与主要外部数据、控制输入输出、文件相关的信息处理功能来度量软件项目。 表5 用户功能类型,(2) 早期设计模型,可以根据软件需求和设计文档的信息，对于每一个功能类型，分别统计功能计数。 确定复杂性等级。按照下表，确定每个功能的复杂性等级。复杂性等级划分为“低”、“一般”或“高”。,表6 FP复杂性等级,对于内部逻辑文件和外部接口文件,数据元素类型数,对于外部输出和外部查询,数据元素类型数,3) 对各功能类型计数加权：根据表7。按照复杂性等级对各个功能类型计数加权。（该权值反映了实现功能所需工作量的大致估计） 计算未调整的功能点：把所有加权后的功能计数相加，得到未调整功能点。 根据表8，把未调整功能点转换成源代码行数。,对于外部输入,数据元素类型数,表7 功能点复杂性权值,传统的功能点度量，还需要考虑 14 种用于校正度量值的影响因素，然而COCOMO II 没有这样做。COCOMO II 先计算未调整功能点，再应用复用因子、成本驱动因子、尺度因子进行调整。,复 杂 性 权 值,功能类型,表8 从UFP到SLOC的默认转换率,例如，项目的功能点数据如下： 由此可计算未调整功能点为 UFP = 4 3 + 7 4 + 5 6 + 7 15 + 6 10 = 235 若采用C编程，则源代码行数为： SLOC = 235 128 = 30080 = 29.375 (KSLOC),估算工作量,工作量估算公式为： 其中，A = 2.94（对COCOMO II.2000）。KSLOC 是千源代码行数。指数 E 是 5 个尺度因子（SF, Scale Factors）的总合。 其中，B = 0.91（对COCOMO II: 2000）。EMi 是工作量调整因素中的成本驱动因子。,尺度因子 SFi 的含义,尺度因子 SFi 的含义 续,通过分析上表所示的 5 个尺度因子来计算指数E。这些因子有六个等级，从“很低”到“极高”，分别赋予 50 值，将这些估算值相加除以 100，再加上 B = 0.91，就得到该指数的取值。,例如，一个组织正承担一个项目，该组织对于该项目所在领域没有经验。项目客户没有定义需采用的过程，需求和接口只有大概的构想。在项目进展中没有做重大风险分析，还需组织新的开发团队来完成这个系统。此外该组织最近刚实行过程改善计划，并且依据CMM模型被评为2级。 在进行指数计算时，各尺度因子取值为： 先例性 机构的新项目，取值“低” (4) 开发灵活性 无客户介入，取值“很高” (1) 体系结构风险化解 无风险分析，取值 “很低” (5),团队凝聚力 新团队，取值“一般” (3) 过程成熟度 有些过程控制，取值“一般” (3) 计算得到的指数 E 为： 后架构模型用在软件生命周期中软件体系架构完成后的系统构造阶段，应用于产品实际开发和维护。,后架构模型的工作量调整,后架构模型采用 17 个成本驱动因子 EMi，来调整标称工作量，以反映待开发软件的特