工作量评估

为什么必须首先做规模估计?

如何做好软件估计?

软件项目的工作量估算方法

七种场景下的软件工作量估算步骤

为什么必须首先做规模估计?

这个问题客户问过我，我也解答过多次，但是我一直没有更直接的理由说服我自己，认为必须先做规模估计再做工作量估计。 
比如：对维护类的项目，或者是维护类的活动，为什么要估计规模呢？项目组的人没有技术风险，对需求很熟悉。 

  我总结了如下的理由： 
（1）     以规模来估计工作量与成本 
（2）     规模估计与实现的人与技术无关，比较客观 
（3）     可以度量项目的开发效率：规模/工作量 
（4）     通过估计规模来细化需求 
（5）     通过规模的实现来度量项目的进展 
（6）     通过规模来度量项目的缺陷密度等指标，进行质量的设计 
（7）     可以与标杆数据进行横向比较 

  但是这些理由，我还是认为不是最根本的理由，因为： 
（1）     可以不通过规模来估计工作量与成本。 
（2）     如果项目组里的成员彼此比较熟悉，配合比较默契，对需求、对开发平台也很熟悉，直接估计工作量也是可以的啊。 
（3）     不需要估计项目的开发效率吧，只要统计实际的规模与工作量，跟踪实际的效率就可以了。 
（4）     不做规模估计，也可以细化需求啊，比如通过测试用例的设计 
（5）     度量项目的进展也可以采用EV值并不一定采用规模 
（6）     通过实际的规模来度量项目的缺陷密度，可以设定质量目标，并不一定需要估算规模吧 
（7）     和标杆数据真的有可比性吗？其实和我们项目组做过的历史项目比较就可以了啊，只要我们一次次在进步就OK了。 
  最根本的原因在什么地方呢?

如何做好软件估计?

1 有经验的人参与估算 
一方面要对估计的内容有开发经验,另一方面也要经过了估计的训练,在估计方面有经验.两种经验缺少其一,估计的风险都比较大. 

2 分解的颗粒度要小 
在估计时要对估计的内容进行分解,划整为零,对于小的任务进行估计时,才容易把握.比如让你估计一碗大米中有多少粒一样,一般的办法就是把大米划分成大小基本相等的几堆,先估计其中一小堆或者数一数,然后再估计整体的粒数. 

3 确保没有遗漏 
如果估计的内容遗漏了，显然整体的规模就会有偏差,所以穷举所有的任务是最基本的工作. 

4 要借鉴历史数据 
历史的类似的项目的数据可以和待估计的项目进行类比.就好象你昨天吃了3碗米饭,前天吃了3碗米饭,可以推测今天也可能吃3碗米饭一样. 

5 采用多种方法互相验证 
可以采用DELPHI方法,功能点法,类比法等等方法进行估计,然后对多种方法的估计结果进行对比,通过对比发现差异比较大,然后再仔细分析差异原因,提高估计的合理性.

软件项目的工作量估算方法

（1）经验法
    Ø     DELPHI方法：需要多个专家参与。
    Ø     类比法：可以一个专家根据历史相似的项目进行估计。

（2）模型法

    Ø     一元线性关系

      工作量=规模*生产率+C

      生产率借鉴历史项目的数据，C为一个常量，多数情况下为0。这是最简单的估算模型。

    Ø     多元线性关系

      工作量=规模*生产率*复用率*难度系数*人员能力系数*……+ C

      生产率借鉴历史项目的数据，C为一个常量，多数情况下为0。在CMMI里中进行估算时，要估计工作产品和任务的属性，这些属性包括了规模、复杂度等。比较多的二级、三级的企业采用了该方法。

    Ø     一元非线性关系

      工作量=a*规模^b+C

      基于历史的稳定的开发过程，可以对工作量和规模进行线性回归分析，一般情况在企业内部项目的规模不符合正态分布，因此分析的结果通常为非线性关系。对于4级的企业可以考虑采用该模型。

    Ø     多元非线性关系

      工作量=a*规模^b*人员能力系数*….. +C

      如果对于项目的工作量起关键作用的还包括人员能力、复用率、技术平台等，可以进行多元的线性回归分析，得出工作量与这些参数的关系。


  经验法和模型法在实际中一般混合使用，以互相补充、互相印证。两类方法各有优缺点，一般不可以只采用一种方法进行估算或只有一个人进行估算。

七种场景下的软件工作量估算步骤

场景一：合同前的工作量估算
场景描述：
（1） 没有实施过CMMI2级
（2） 合同未签，需要给客户报价
（3） 有客户的概要需求，有类似的项目数据可供参考
（4） 需要估计整个项目的总工作量，以便于估算总成本，给客户报价

估算步骤：
（1）寻找类似的历史项目，进行项目的类比分析，根据历史项目的工作量凭经验估计本项目的总工作量；
（2）进行WBS分解，力所能及地将整个项目的任务进行分解；
（3）参考类似项目的数据，采用经验法估计WBS中每类活动的工作量；
（4）汇总得到项目的总工作量；
（5）与第（1）步的结果进行印证分析，根据分析结果，确定估计结果。


场景二：基于详细需求的经验估计
场景描述：
（1） 只有详细需求，没有历史数据
估算步骤：
（1）WBS分解，将任务分解到一个人或者一个小团队可以执行的颗粒度；WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。
（2）采用经验法估计每个活动的工作量；
（3）汇总得到：每个阶段的工作量、项目的总工作量。
其他说明：
在该场景下，只使用了经验法，无法对结果进行印证，难以判断结果的合理性。


场景三：由编码估算整体
场景描述：
（1）有类似项目的历史数据
（2）有编码活动的生产率数据
（3）有详细需求
（4）实施了CMMI2级，但是没有积累历史项目的工作量分布数据
估算步骤：
（1）产品分解，将系统分为子系统，子系统分解为模块；
（2）WBS分解，将任务分解到一个人或者一个小团队可以执行的颗粒度；WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。
（3）建立WBS分解中的活动与产品元素的映射关系，识别出WBS中哪些活动可以采用模型法估算；
（4）估计产品元素的规模，可以采用代码行法或功能点法，并估计每个产品元素的复杂度、复用率等；
（5）根据历史的编码阶段的生产率数据和产品元素的规模估计、复杂度、复用率等采用模型法计算每个产品元素的编码工作量；
（6）根据历史的类似项目的数据及估算人的经验估计其他活动的工作量，可以采用经验法。
（7）汇总得到：每个阶段的工作量、项目的总工作量。
其他说明：
在该场景下，混合使用了经验法与模型法，这2种方法互相补充，而不是互相印证。


场景四：由总体印证基于WBS的估计
场景描述：
（1）有类似项目的历史数据 
(2) 有类似项目的全生命周期的生产率数据（含管理工作量）
（3）有详细需求
（4）实施了CMMI2级，但是没有积累历史项目的工作量分布数据
估算步骤：
（1）产品分解，将系统分为子系统，子系统分解为模块；
（2）估计产品元素的规模，可以采用代码行法或功能点法；
（3）累计出整个产品的总规模，并估计产品总体的复杂度、复用率等；
（4）根据类似项目的全生命周期的生产率数据和产品的总规模、复杂度、复用率等采用模型法计算总的开发工作量；
（5）WBS分解，将任务分解到一个人或者一个小团队可以执行的颗粒度；WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。
（6）根据历史的类似项目的数据及估算人的经验估计所有活动的工作量，可以采用经验法。
（7）汇总得到：每个阶段的工作量、项目的总工作量。
（8）与第（4）步得出的工作量进行比较印证，如果偏差不大，则以第（7）步的结果为准，如果偏差比较大，要仔细分析原因，可能的原因举例如下：
Ø 类似项目的生产率数据不适合本项目；
Ø WBS分解的颗粒度不够详细；
Ø 估算专家的经验不适合本项目；
Ø 具体任务的估计不合理；
针对原因，对估算的结果进行调整，使其趋向合理。
其他说明：
在该场景下，对于项目的总工作量有2个结果或者多个结果，这些结果可以互相印证，以发现估算过程中的不合理之处，是估计更加合理。


场景五：三维印证基于WBS的估计 

场景描述：
（1）有类似项目的历史数据 
(2) 有类似项目的全生命周期的生产率数据（含管理工作量）
（3）有详细需求
（4）实施了CMMI3级，有历史项目的工作量分布数据（阶段分布、工种分布）
估算步骤：
（1）产品分解，将系统分为子系统，子系统分解为模块；
（2）估计产品元素的规模，可以采用代码行法或功能点法；
（3）累计出整个产品的总规模，并估计产品总体的复杂度、复用率等；
（4）根据类似项目的全生命周期的生产率数据和产品的总规模、复杂度、复用率等采用模型法计算总的开发工作量；
（5）根据历史项目的工作量分布数据及第（4）步估算的项目总工作量，计算：
Ø 每个阶段的工作量
Ø 每个工种的工作量
（6）WBS分解，将任务分解到一个人或者一个小团队可以执行的颗粒度；WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。
（7）根据历史的类似项目的数据及估算人的经验估计所有活动的工作量，可以采用经验法。
（8）汇总得到：每个阶段的工作量、每个工种的工作量、项目的总工作量。
（9）与第（4）、（5）步得出的工作量进行比较印证，如果偏差不大，则以第（7）步的结果为准，如果偏差比较大，要仔细分析原因，可能的原因举例如下：
Ø 类似项目的生产率数据不适合本项目；
Ø WBS分解的颗粒度不够详细；
Ø 估算专家的经验不适合本项目；
Ø 具体任务的估计不合理；
针对原因，对估算的结果进行调整，使其趋向合理。
其他说明：
在该场景下，对于项目的总工作量有2个结果或者多个结果，并且采用2种方法都得到了每个阶段、每个工种的工作量、项目的总工作量，可以从上述的3个维度对这些结果进行互相印证，以发现估算过程中的不合理之处，是估计更加合理。


场景六：四维印证基于WBS的估计
场景描述：
（1）有类似项目的历史数据 
(2) 有类似项目的编码活动的生产率数据（不含管理工作量）
（3）有详细需求
（4）实施了CMMI3级，有历史项目的工作量分布数据（阶段分布、工种分布、阶段工种分布）
（5）项目采用了瀑布模型
估算步骤：
（1）产品分解，将系统分为子系统，子系统分解为模块；
（2）估计产品元素的规模，可以采用代码行法或功能点法，并估计每个产品元素的复杂度、复用率等；
（3）根据类似项目的编码活动的生产率数据和产品元素的规模、复杂度、复用率等采用模型法计算每个产品元素的编码工作量；
（4）根据历史项目的按工种的工作量分布数据及第（3）步的估算的编码工作量依次计算：
i)根据历史项目的编码的工作量占编码阶段的工作量的百分比与第（3）部计算出的编码工作量计算编码阶段的总工作量；
ii)根据历史项目的编码阶段各工种的工作量分布百分比计算编码阶段每个工种的工作量；
iii)根据历史项目的其他阶段的工作量与编码阶段的工作量比例计算其他阶段的总工作量；
iv)根据历史项目的其他阶段的每个工种的工作量分布百分比及第iii)步的结果计算其他阶段的每个工种的工作量；
（5）WBS分解，将任务分解到一个人或者一个小团队可以执行的颗粒度；WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。
（6）根据历史的类似项目的数据及估算人的经验估计所有活动的工作量，可以采用经验法。
（7）汇总得到：每个阶段每个工种的工作量、每个阶段的工作量、每个工种的工作量、项目的总工作量。
（8）与第（4）步得出的工作量进行比较印证，如果偏差不大，则以第（6）步的结果为准，如果偏差比较大，要仔细分析原因，可能的原因举例如下：
Ø 类似项目的生产率数据不适合本项目；
Ø WBS分解的颗粒度不够详细；
Ø 估算专家的经验不适合本项目；
Ø 具体任务的估计不合理；
针对原因，对估算的结果进行调整，使其趋向合理。
其他说明：
在该场景下，对于项目的总工作量有2个结果或者多个结果，并且采用2种方法都得到了每个阶段的工作量、每个工种的工作量、每个阶段每个工种的工作量、项目的总工作量，可以从上述的4个维度对这些结果进行互相印证，以发现估算过程中的不合理之处，是估计更加合理。


场景七：需求变更的工作量估计
场景描述：
（1） 有变更的需求描述
（2） 项目进行到了编码阶段
（3） 有本项目的编码的生产率
估算步骤：
（1）进行需求变更的波及范围分析
（2）进行本次变更的的WBS分解
（3）对于变更引起的代码变化进行规模、复杂度等其他属性的估计
（4）根据本项目的编码的生产率及估计的规模采用模型法估计工作量
（5）对于WBS分解中其他活动进行经验估计
（6）汇总所有的工作量得到本次变更的工作量估计