ccxc

软件成本度量一直都是软件行业的一个痛点问题。软件度量一度乱象丛生。拍脑袋的定价方式曾大行其道。软件成本度量的乱象直接导致了软件价格的诸多问题。比如预算费用存在浪费或不足的现象，招标存在投标额过低过高等非正常状况。这些情况都是因为度量标准的缺失，导致定价没有依据。 《软件工程 软件开发成本度量规范》标准的出台为软件行业定价指定了一个国家标准，使得软件行业自此有了一个软件成本度量的标准规范。 软件成本度量的前提是软件规模大小及生产率。目前，每年都有CSBSC年度中国软件行业基准数据可以引用生产率等数据。由此，软件规模大小的度量就成为了重中之重。 软件开发成本分为人力成本和非人力成本。人力成本包括直接人力成本和间接人力成本，直接人力成本指参与项目研发的人员的工资、福利、奖金等费用，间接人力成本指部分参与项目研发的人员的费用分摊。非人力成本包括直接非人力成本和间接非人力成本。直接非人力成本指直接服务于项目所产生的设备、培训、差旅等费用，间接非人力成本指部分服务于某项目的费用分摊，如房租等。 目前，评估软件规模的方法主要分为两种：基于业务视角和基于开发视角。基于业务视角的方法从用户角度出发，如：功能点、故事点、用例点、对象点等方法。基于技术视角的方法是从开发人员的角度，方法包括代码行、数据库表、函数、接口、服务的数量等等。 基于开发视角的方法主要存在于技术人员之间，优势是实现起来简单容易，缺点是容易引起分歧，难以在项目初期进行度量，且难以在技术人员之外的其他人员之间得到应用，如部门之间、用户之间等。而基于用户视角的度量方法是站在使用者的角度来进行度量，并能够在项目初期得到应用，弥补技术度量方法的不足。因而，基于用户视角的度量方法在目前得到了广泛应用。 虽然基于用户视角的度量方法有多种，但真正被广大用户所接受的方法是功能点方法。功能点方法是IBM公司在1974-1979年间，由Albrecht通过对大量项目生产率进行研究得到的成果。随后多年不断完善升级，出现了多种标准和方法。 国家标准中，提到了如下5种估算方法都属于功能点度量方法： IFPUG NESMA FiSMA COSMIC MK II 上述5种方法各有特点，应用于不同的场景下，度量的方法和过程也各不相同。从应用角度而言，IFPUG和NESMA标准是国际上最主要的标准，国际基准比对组织中超过90%的数据采用IFPUG/NESMA方法，国内的行业数据百分百采用IFPUG/NESMA方法，由于IFPUG方法和NESMA方法被认为是基本等效的，所以近几年，这两种方法被各行业大量采用。但如想在早期（如预算）阶段进行度量，NESMA是更好的选择。 下表列出了几种不同方法的区别：

1.1 软件开发成本 software development cost 为达成软件开发项目目标开发方所需付出的各种资源代价总和。 注：资源包括人、财、物、信息等。 1.2 软件开发收入 software development income 因向委托方交付软件开发工作成果所获得的收入。 1.3 直接成本 direct cost 为达成软件开发项目目标而直接付出的各种资源代价总和。 注1：如可直接计入软件开发项目成本的直接材料、 直接人工等。 1.4 间接成本 indirect cost 与达成软件开发项目目标相关，但同一种投入可以支持一个以上项目的联合资源代价总和。 注：如开发管理人员工资、开发设备折旧、停工损失等。 1.5 人力成本 human resource cost 为达成软件开发项目目标所需付出的各种人力资源代价总和。 1.6 非人力成本 non-human resource cost 为达成软件开发项目目标所需付出的人力成本之外的其他资源代价总和。 1.7 成本度量 cost measurement 对软件开发成本的预计值进行估算或对实际值进行测量和分析的过程。 1.8 方程法 equation 基于基准数据建立参数模型，并通过输入各项参数，确定待估算项目工作量或成本估算值的方法。 1.9 类比法 comparison 将本项目的部分属性与类似的一组基准数据进行比对，进而获得待估算项目工作量或成本估算值的方法。 1.10 类推法 analogy 将本项目的部分属性与高度类似的一个或几个已完成项目的数据进行比对，适当调整后获得待估算项目工作量或成本估算值的方法。 [...]

一．什么是软件估算 软件估算是软件量化管理的重要部分。随着科技和社会的快速发展，软件应用领域在不断扩大，同时，越来越多的软件功能越来越复杂。如何更好更快开发出更多更复杂的软件是摆在软件从业者面前的重要问题。 软件估算包括：软件规模估算、生产率估算、工作量估算、软件成本估算、开发周期估算、缺陷估算、风险估算、资源估算等。 软件估算一直都是非常复杂的事情。项目变更、开发团队人员变化、需求改变、工作能力大小等都会导致估算结果的差异。据有关统计，延期的软件项目中，约有超过60%的项目是因为软件估算没有做好。不是技术水平达不到要求，而是估算结果与实际情况有重大差异或者没有进行估算导致的。所以说，软件估算是非常重要的，准确的估算结果是软件项目成功的重要保障。 失败的项目最常见的六个原因： 如上图中所示，六个原因中的任何一个都可能导致项目失败，很多时候是多个原因同时出现。做好软件估算可以完善上述原因中的不足部分，解决大多数上述问题。 二．软件估算面临的问题 软件估算虽然非常重要，但在实际中面临一些实施困难，主要表现在如下方面： 1.规模越大的软件，复杂性越高，面临的问题就越多，越难以估算； 2.需求不确定性，导致估算结果容易出现较大偏差； 3.陌生领域的项目，复杂性和认知性差，不确定性增大； 4.估算人员的水平、经验、对估算项目的理解能力等可能会对估算结果产生一定影响； 三．软件规模估算 软件规模估算是软件估算中的首要环节，是其他估算项目的基础。软件规模估算定义了软件的客观大小，而且不因为测量的人员、方式、时间的不同而变化。 对于甲方（发包方）而言，软件规模估算决定了项目的预算、招标金额，为费用申请提供了科学依据。 对于乙方（开发方）来说，软件规模估算可以帮助乙方确定投标金额，还能确定需要投入的资源及开发成本的评估等。 不识别规模的情况下，项目管理的三个重要目标无法提升：效率、质量和成本？ 效率 = 总工时/软件规模 质量 = 缺陷加权总数/软件规模 成本 = 单位成本 * 软件规模 合理地对软件项目进行规模估算，能够更加精准确定项目开发所需的资源、费用、周期等。所以说软件规模估算是其他估算内容的重中之重。 软件规模大小决定了软件的成本及开发资源的投入。由于估算活动的不确定性，软件规模是最难确定的因素，虽然不能百分百准确，但从国际到国内，软件规模已经成为衡量软件开发的一个非常重要的指标。 依据合理的方法对软件规模进行估算，相较于拍脑袋、拍大腿等的“六拍法”，可以提供更加科学合理的估算结果。 四．常见的估算方法 1. 经验法（专家法，包括PERT法、DELPHI法） 根据管理人员以往的项目或领域的经验，对未来的工作量进行估计。 2. 类推法 将本项目的部分属性与高度类似的一个或几个完成的项目进行比对，适当调整后获得待估算项目的工作量、工期或成本估算值的方法。 3. 类比法 将项目的部分属性与类似的一组基准数据进行对比，进而获得待评估项目的工作量、工期和成本估算值的方法。基于基准数据通常以50百分位数为参考而非均值。 4. 方程法 根据一个相对稳定的公式对未来的工作量进行估计。基于基准数据建模，可以与行业和企业数据相结合。 5. 交叉验证 估算过程中宜采用不同的方法分别估算，并进行交叉验证。 如果不同方法的估算结果产生较大差异，可采用专家评审的方法确定估算结果，也可以使用简单的加权平均方法。 五．软件规模度量的发展 软饭规模度量的发展经历了长期的过程。 最初，采用物理的度量方法：测量纸带的长度，或者汇总程序的字节数。这种方法在早期阶段，程序功能比较单一、开发语言相对固定的情况下，对软件规模度量提供了一定的参考价值。 后来，发展到了技术度量过程：比如代码行、函数数量、数据库、模块、类的数量等。这些方法是属于特定历史时期的产物，在那段时期，这些方法都对软件规模度量的发展起到了巨大的推动作用。也正是这些方法的出现，体现出了其中的优劣势，使得软件规模度量发展到了“功能”的阶段。 功能的规模体现在：用例数、功能点数、故事点数、页面数、窗口数、按钮数等。这其中，最得到普及应用的是功能点方法。 上纪70年代中期，IBM委派工程师Allan Albrecht和他的同事共同研究软件测量和度量分析方法。经过一年多的研究，Albrecht和他的团队发布了名为“功能点”的度量方法第一版。 [...]