您好,欢迎来到上海锦心-cmmi认证-cmmi查询-cmmi培训-cmmi标准官方网站!
专业资料
专业资料
网站首页 > 专业资料 > 如何做工作量的估算

如何做工作量的估算

  • 上海锦心-cmmi认证-cmmi查询-cmmi培训-cmmi标准
  • 上海锦心-cmmi认证-cmmi查询-cmmi培训-cmmi标准
  • 2018-08-07
  • 279

1估算的时机
(1)只有初步的概要需求,合同未签或项目未正式立项之前
 可以采用DELPHI方法,根据初步的需求进行经验估计。
 可以采用类比法,与历史项目的同类任务进行对比。
 可以采用简单的估算模型,如一个USE CASE平均8.5个功能点,每个功能点平均2天。
(2)需求基本确定,项目计划未定
 对于开发活动,可以先估计规模再估计工作量
 对于管理活动,可以直接采用DELPHI方法估计工作量
(3)需求变更
 估计变更的规模,根据实际的生产率计算工作量
 直接采用DELPHI方法估计工作量

2 可能的估算输入
(1)概要需求
(2)详细需求
(3)类似项目的生产率数据
(4)类似项目的估算数据
(5)类似项目的工作量分布
阶段分布:每个阶段占总工作量的百分比;
工种分布:每个工种占总工作量的百分比;
阶段工种分布:每个阶段每个工种占本阶段工作量的百分比。

在借鉴历史项目的数据时,一般要慎重考虑如下的5个问题:
 是否采用相同的技术平台?
 是否是同类型的软件,比如都是嵌入式软件或者都是MIS软件?
 是否项目的规模相近?
 是否采用相同的生命周期模型?
 是否人员的专业技能相近?

3 估算的对象
(1)有文档产出的活动
 文档规模敏感的活动,即规模是影响其工作量的主要因素。先估计文档规模,再估计活动的工作量。软件开发活动一般是规模敏感的活动,但是也有的软件开发是复杂度敏感或其他特征敏感的,比如算法类的软件。
 文档规模不敏感的活动,即工作量与规模关系不大。采用经验法直接估计工作量,如编写管理类文档的活动可能就和规模关系不大。
(2)有代码产出的活动
先估计代码的规模,再根据生产率、复用率、难度系数等估计工作量。
(3)无工作产品产出的活动
采用经验法,直接估计工作量

4 估算的颗粒度
     (1)整个项目的总工作量
     (2)某类任务的工作量
     (3)某个阶段的工作量
     (4)某个任务的工作量

不同颗粒度之间的换算关系:
 项目的总工作量等于所有任务类型的工作量之和;
 项目的总工作量等于所有任务的工作量之和;
 项目的总工作量等于所有阶段的工作量之和;
 某个阶段的总工作量等于该阶段的所有任务的工作量之和;
 某个阶段的总工作量等于该阶段的所有任务类型的工作量之和;
 某种任务类型的工作量等于所有阶段的该类型的任务的工作量之和;
这些换算关系可以用来校验从不同的角度进行估算时的可接受性。

5 估算方法
  (1)经验法
 DELPHI方法:需要多个专家参与。
 类比法:可以一个专家根据历史相似的项目进行估计。
  (2)模型法
 一元线性关系
工作量=规模*生产率+C
生产率借鉴历史项目的数据,C为一个常量,多数情况下为0。这是最简单的估算模型。
 多元线性关系
工作量=规模*生产率*复用率*难度系数*人员能力系数*……+ C
生产率借鉴历史项目的数据,C为一个常量,多数情况下为0。在CMMI®里中进行估算时,要估计工作产品和任务的属性,这些属性包括了规模、复杂度等。比较多的二级、三级的企业采用了该方法。
 一元非线性关系
工作量=a*规模b+C
基于历史的稳定的开发过程,可以对工作量和规模进行线性回归分析,一般情况在企业内部项目的规模不符合正态分布,因此分析的结果通常为非线性关系。对于4级的企业可以考虑采用该模型。
 多元非线性关系
工作量=a*规模b*人员能力系数*….. +C
如果对于项目的工作量起关键作用的还包括人员能力、复用率、技术平台等,可以进行多元的线性回归分析,得出工作量与这些参数的关系。

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

6 生产率的含义
  生产率=规模/工作量。

不同的类型的项目,生产率是不同的。
  当定义了生产率的明确含义时,要和将来的实际度量的生产率的定义相一致。

  (1)对于规模的度量:
 软件:
 物理规模:代码行
              对于代码行,要注意明确定义如下的规则:
 是否包含注释行?
 是否包含空行?
 是否包含机器自动生成的代码?
 是物理行还是逻辑行?
 逻辑规模:功能点
 文档:
          页数

 (2)工作量的度量:
      2种维度的度量:
 按阶段:
 全生命周期的工作量
 编码阶段的工作量
 按是否含管理:
 含管理活动的工作量
 不含管理活动的工作量

7 多种场景下的估算步骤
序号 场景名称 估算步骤概要
1 合同前的工作量估算 (1)根据客户的概要需求及历史类似的项目采用经验法估计项目的总工作量。
2 基于详细需求的经验估计 (1)根据客户的详细需求采用经验法估计项目的工作量。
3 由编码估算整体 (1) 根据客户的详细需求、类似项目的编码生产率数据采用模型法计算编码的工作量
(2) 采用经验法估计其他活动的工作量。
(3) 汇总(1)和(2)的结果
4 由总体印证基于WBS的估计 (1) 估计规模,再估计项目的总体工作量
(2) WBS分解,估计每个任务的工作量
(3) 印证(1)和(2)结果
5 三维印证基于WBS的估计 (1) 估计规模,再估计项目的总体工作量
(2) 根据历史工作量的分布,利用(1)的结果估计每个阶段、每个工种的工作量
(3) WBS分解,估计每个任务的工作量
(4) 根据(3)的结果累计每个阶段、每个工种的工作量
(5) 印证(2)和(4)的结果
6 四维印证基于WBS的估计 (1) 估计规模,再估计项目的总体工作量
(2) 根据历史工作量的分布,利用(1)的结果估计每个阶段、每个工种、每个阶段每个工种的工作量
(3) WBS分解,估计每个任务的工作量
(4) 根据(3)的结果累计每个阶段、每个工种、每个阶段每个工种的工作量
(5) 印证(2)和(4)的结果
7 需求变更的工作量估计 (1) 变更的WBS分解
(2) 模型法估计编码的工作量
(3) 经验法估计其他活动的工作量
(4) 汇总(2)和(3)的结果

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

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

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

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

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

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

场景六:四维印证基于WBS的估计
场景描述:
(1)有类似项目的历史数据 
(2)  有类似项目的编码活动的生产率数据(不含管理工作量)
(3)有详细需求
(4)实施了CMMI®3级,有历史项目的工作量分布数据(阶段分布、工种分布、阶段工种分布)
(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)汇总所有的工作量得到本次变更的工作量估计

8 工作量估算成功的要点
(1)有经验的人参与估算 
  一方面要对估计的内容有开发经验,另一方面也要经过了估计的训练,在估计方面有经验.两种经验缺少其一,估计的风险都比较大. 
(2)分解的颗粒度要小
在估计时要对估计的内容进行分解,划整为零,对于小的任务进行估计时,才容易把握.比如让你估计一碗大米中有多少粒一样,一般的办法就是把大米划分成大小基本相等的几堆,先估计其中一小堆或者数一数,然后再估计整体的粒数. 
(3)确保没有遗漏 
    如果估计的内容遗漏了,显然整体的规模就会有偏差,所以穷举所有的任务是最基本的工作. 
(4)要借鉴历史数据 
历史的类似的项目的数据可以和待估计的项目进行类比.就好象你昨天吃了3碗米饭,前天吃了3碗米饭,可以推测今天也可能吃3碗米饭一样. 
(5)采用多种方法互相验证 
可以采用DELPHI方法,功能点法,类比法等等方法进行估计,然后对多种方法的估计结果进行对比,通过对比发现差异比较大,然后再仔细分析差异原因,提高估计的合理性. 
(6)在项目进展过程中要持续估算,逐渐优化
随着项目的进展,对项目的了解越来越深刻,估算会越来越合理。

13162132569