关于软件项目工做量估算的若干问题

软件项目工做量估算从估算依据上看能够分红以下两类：

1，基于规模估算

2，基于工做量估算

基于规模估算的状况下，须要估算软件项目的规模。本文首先来看规模方面的问题。

问题1：如何表达规模？

软件产品或项目的功能规模是涉及软件开发和交易的成本、项目资源投入的预测、项目维护成本的预算、项目质量管理的要求以及产品上市的时间等方面的关键指标。所以，进行软件产品的功能规模测量显得尤为重要。

如何测量软件规模这个问题自软件工程诞生起就一直是这个领域的焦点问题。刚开始，人们很天然的使用代码行数做为规模的表达。可是做为规模表达方式的代码行数随着时间和技术的发展，愈来愈不正确了，主要缘由是

1，新工具自动生成大量代码行；

2复用构件或源代码；

3，难以区分新开发代码和旧代码。并且最重要的是源代码行数的实际测量只能在软件项目开发的后期，缺少在前期较精确指导项目的能力。

世界上各个组织都看到了代码行做为规模表达方式的弊端，纷纷发展了各自的规模表达方式，其中IFPUG的功能点计数是其中有显著影响的。可是因为规模度量存在各类各样的状况，IFPUG的方法并无统治地位，涌现了多种规模度量方法。目前，国内外软件领域的专家对软件功能规模测量开展了极富成效的研究，提出了各种工业标准。国际标准化组织（ISO）和国际电工委员会（IEC）联合技术委员会分别于199八、2002和2003年推出了软件功能规模测量方面的系列标准。

国际标准化组织ISO/IEC相继发表了4个功能规模测量方法的标准，它们是：

——ISO/IEC 19761（COSMIC-FFP方法）；

——ISO/IEC 20926（IFPUG方法）；

——ISO/IEC 20968（MkⅡ方法）；

——ISO/IEC 24750（NESMA方法）。

其中，COSMIC-FFP方法声明能够应用于管理信息系统（MIS）和实时类型二类软件，IFPUG方法声明可用于全部类型的软件，MkⅡ方法声明可用于逻辑事务能被肯定的任何软件类型，NESMA方法很是相似于IFPUG方法也能够用于全部软件类型。

我国也十分重视这类标准的研究，于2001年开始了这方面的工做。

我国相继发布了GB/T 18491.1～6《信息技术 软件测量 功能规模测量》的系列标准，但具体的测量方法不包含在该系列标准中。由中国工业和信息化部支持的《软件工程 软件功能规模测量方法 功能点计数》（征求意见稿）于2011年9月1日完成，如今正处于意见征集阶段，这个标准非等效采用了ISO/IEC 20926:2003，为全部类型的软件开发的全生存周期提供了一种统一的软件功能规模计数方法。

除了以上方法，常见的方法还有：

其它各种功能点方法

代码行数 LOC

数据点

对象点

用例点

故事点，故事点是比较特殊的一个方法，下文还有说明。

很多公司发展了本身的功能规模测量方法。

问题2：如何测量规模？

以上这些规模测量方法的基本框架是相同的，下面是一个概要的介绍。

首先对作所测量对象进行分解，针对分解获得的各个部分，估算或测量模块的初始规模u（有些场合称为未调整功能点），乘以模块级调节参数f1，获得模块一次调整后的规模，将全部一次调整后的规模累加获得一次调整后的总规模，乘以整体调节系数f2，获得二次调整后的总规模s，见以下公式：

总规模S = (西格玛u*f1)*f2

有些方法只有一次调整，有些方法有上述的2次调整。

问题3：如何根据规模估算工做量

通过前人的大量研究，认为规模与工做量的数学关系如如下公式所示：

估算工做量e = a * S的b次方 + c

s是表明了规模, a,b,c是参数，其值的得到须要大量数据分析，通常采用非线性转换到线性，再进行线性回归分析。b的取值通常是1到1.2之间。

从以上公式能够看出，随着规模s的增长，工做量e是指数级增加，代表了软件项目规模越大，所须要的工做量增长得更多，代表了软件开发规模不经济的状况，这和咱们直观的感觉是一致的。

世界上各个软件生产率研究组织（好比ISBSG，SPR，日本的IPA SEC等）收集了成千上万个项目数据，开展各类各样的数学分析，试图获得在各类状况下 a, b ,c 的取值。

在第5届世界软件质量大会上，来自Toyo University的野中诚（Makoto Nonaka）介绍了日本IPA SEC组织（http://sec.ipa.go.jp/），举了某种状况下的一个工做量估算公式：

工数 = e的0.542次方*FP的1.154次方 = 1.719*FP的1.154次方。

对于通常的场合，其规模在必定有限的范围以内，那么能够假设工做量与规模的关系是简单的线性正相关，那么上述公式就变为：

估算工做量e = a * S，即b=1, c=0 。 那么参数 a 就是 代表了生产率，a的单位是 工做量/单位规模，好比8工时/FP；另一种生产率单位是规模/单位工做量，好比30FP/Man-month，若是采用常见的生产率单位，那么a就是生产率的倒数。

这种作法是更容易为各方所理解，在不少组织里常见到这个作法。

对比基于规模的工做量估算，直接的工做量估算方法所积累的数据和资料就少了,没有看到哪一个组织在收集积累这类数据，这与直接工做量估算方法自己的特征也有关系。

下面来看看直接工做量估算方面的问题。

问题4，如何表达工做量？

工做量的单位通常是工时、人天、人月、人年。这些不一样的单位是能够换算的。不一样单位换算并不麻烦，在同一个国家没有差别，在不一样国家由于法定假期的不一样，1人月所对应的人天多是不一样的，但差别并不大。真正麻烦的是工做量表达有以下两种：

1，工做量

2，理想工做量

而工做量也有差别，有些地方是计毛时，好比一天都在某项目上工做，就直接记为8工时，有些地方是计净时，虽然一天都在某项目上工做，但会把诸如非直接相关的工做（如部门例会、参加其它项目评审）等等剥离，一天在某项目上的工做量只有5工时。 这样看，能够发现计净时的工做量与理想工做量比较接近，但注意并不彻底相等。

问题5，如何直接估算工做量？

主要的思路是分解和类比。

把待完成物细分，根据以往估算和经验进行类比估算。 对于以往估算和经验的处理，能够分为两种作法：

1，不作特别处理，天然停留在团队成员的头脑里，使用时并不明确要求、不保证可以想起来对照

2，记录典型事物（特性，用户故事等）所须要的工做量，获得一套基准类比库，新任务根据这个基准类比库来估算。

在使用理想工做量的状况下，须要一个名为capacity的参数。工做量 = 理想工做量 / capacity ，capacity的取值通常是50% ~ 80%。

在估算时，本次待完成的理想工做量 = 计划的工做容量 * capacity

在回顾时，capacity = 原估算的理想工做量 / 实际工做容量 * 100%，注意工做容量并不等于工做量，而是团队在指定时段内能够提供的工做量，好比 5我的的团队工做21天，那么这个工做容量就是5*21=105人天。

在使用工做量时，注意区分毛时和净时，在选择净时的状况下，须要注意一天按多少小时来计，好比按5小时来计算，估算工做量达到50工时，若是1我的作的话，须要10天来完成。

问题6，在什么状况下使用直接工做量估算？

能够看到虽然之前也存在直接工做量估算的作法，但并无获得大力的宣扬，在之前的软件工程教材里，通常不多提直接工做量估算。

从敏捷类开发方法开始起，直接工做量估算获得了宣扬，获得了更普遍的传播。

在敏捷类软件迭代开发当中存在对此方法的很多应用。

问题7，Story Point的特殊状况是什么？

Story Point的起源与理想工做日紧密相关，通常的，在开始时，团队会将估计一理想人日能完成的用户故事为一个故事点。

若是始终保持一理想人日对等于一个故事点，那么故事点估算实际上是直接工做量估算。

但多数状况下，1个故事点对应的工做量是会发生变化的，随着团队的变化，对1个故事点所须要的工做量通常会减小。

有些团队会始终维护一套用户故事样例库，至关于用户故事的砝码，新的用户故事与样例库的用户故事进行比对，进而断定新用户故事的故事点数。

在具体比对上，常见的方法有 排序法，排序法通常利用斐波那契数列（1，2，3，5，8，15, …，？，无穷大），还有模仿T-shirt size估算，常见的，分红3到5档，好比 S、M、L、XL，或大、中、小，给每一档设定故事点数值。

能够看到排序法和T-shirt size模仿估算在本质上是同样的，T-shirt size模仿估算是排序法的一个实现。

这有样例库的作法获得的估算点数就是规模，值得注意的是 故事点所表达的规模是相对的规模。不一样组织、不一样团队的故事点是不能够比较的。这与诸如IFPUG、NESMA等等的功能点是不同的。

4个国际软件功能规模测量标准的功能点是像“米”同样的绝对单位。就是说 在中国A公司的A1软件用IFPUG识别出了1000个功能点，美国B公司的B1软件也用IFPUG识别出的1000个功能点，那么能够说A1软件的规模与B1软件规模相等。而若是中国A公司的A2软件用Story Point识别出了1000个故事点，美国B公司的B2软件也用Story Point识别出了1000个故事点，那么，是不能说A2软件的规模与B2软件规模相等，两种不具有可比性，若是非要比较，那么须要分析A2和B2各自所依据的故事点样例或基准。

前面说到新的用户故事与样例库的用户故事进行比对，进而断定新用户故事的故事点数，目前这个比对并无绝对的作法，常见不一样的作法有：
1，是否考虑不一样人作的影响

2，是否考虑实现的复杂度、难度

3，是否考虑新用户故事关联或依赖的事务

4，是否考虑有疑问的部分

目前业界对以上的问题并无定论，各家组织或团队结合各自状况和理解各有各的选择。

所以，Story point具有在规模和直接工做量的两种形态之间变化的多态，具有巨大的灵活性，具体组织在采用Story Point时，能够作适应性的选择。

问题8，哪一种方法更加准确？

没有结合具体状况，这个问题是没法回答的。

假设偏差系数= 估算值/实际值。

估算值 = 实际值 * 偏差系数

绝对偏差 = 实际值-估算值 = 实际值 - 实际值 * 偏差系数 = 实际值*（1-偏差系数）

能够看到的一点是 敏捷小团队短迭代的实际值是不大的。 假设9我的的团队，迭代周期是3周，那么 实际值约在135人天范围以内。就算偏差系数比较大，绝对偏差也是有限的。

而传统瀑布型项目就是另一个样子，好比时间跨度也许达到1年，总的人月数约是120人月，在这种状况下，就不难理解为何存在多个组织来维护功能点定义，收集数据，给出须要指数运算的估算公式。由于就算偏差系数小，因为基数大，所形成的绝对偏差就比较大。

在敏捷开发方法里，常见的，采用扑克估算方式，这个方法能够驱动总体团队的智慧来肯定故事点的大小，也能提升估算的精确度，并且也能澄清不一样的理解，是很是值得采纳的一个方法。

 

做者：irenbest 来源：希赛网 发布于 2016-4-20