• 第五次作业


    需求分析中遇到的问题--软件工作量估计

    标签: 软件工作量估计

    说明:上周作业写了,刚好老师上课讲道我们需求中关于软件工程量的估计有些随意,我们组的需求文档中也确实遇到这样的问题,这次博客我来讲讲这个问题,算是补上次作业。

      在谈软件工作量估计问题之前,我们想想为什么要提出这个问题,我不打算去纠结它的定义,我这里不是写论文,只是打算写点我自己的学习心得。我认为提出这个问题,是因为我们在开发初期需要要对这个项目工作量有个估计,以便我们给客户或者上级有个交代。合理的工作量的估计和工作量的时间把控能够保证我们在规定的时间内完成任务。在签署某些项目合同时,工作量的估计也显得尤为重要。
      
    下而步入正题,就是软件工作量估算方法的总结啦。很多文章、书籍都做过类似的总结啦。估算的方法分为两类:直接估算法和间接估算法。直接法指基于WBS的工作量估算方法,直接估算出人天工作;间接估算法
    是先估算软件规模,再转换成人天工作盘。根据估算角度的不同,间接法又分为基于代码行(SLOC) 的工作量估算方法和基于功能点( FP ) 的 工作量估算方法。不管是哪种工作量估算方法,一般都会用到一些基本的估算方法,如类比法、 WBS 法、专家估算法等。

    1、 基于 WBS 的工作量估算方法
      基于 WBS 的工作量估算方法,是最常见的一种估算方法,也是厂商最常用的。基于 WBS工作量估算方法,又称为由底向上法(自下而上法),通常的估算步骤如下:
    1 ) 寻找类似的历史项目,进行项目的类比分析,根掘历史项目的工作量 凭经验估计本项目的总工作量;
    2 ) 进行 WBS 分解,力所能及地将整个项目的任务进行分解;
    3 ) 参考类似项目的数据,采用类比法或专家法,估计WBS中每类活动的工作量
    4 ) 汇总得到项目的总工作量;
    5 ) 与 第 1 ) 步的结果进行印证分析,根据分析结果,确定估计结果。

    2、 基 于 SLOC 的工作量估算
      基于代码行( SLOC)的工作量估算,是从开发者的技术角度出发来度最软件。代码行数是软件开发者最早进行规模测量的主要方法。进行工作量估算时,先采用WBS法、类比法等统计出软件项目的代码行数,然后将代码行数转换为人天数。其中,将代码行(SLOC)转换成人天数主要有2 种方法。
    (1) 生产率方法:要求有开发商每人天开发的代码行数,估算出代码行数后,直接利用代码行数+ SLOC /人天,即得工作量人天数。
    (2) 参数模型法:利用模型,将代码行数转换成人天数。
      常见的模型有:
      
    Putnam 模型
    Putnam 1978年提出的一种动态多变 M 模型。估算工作 S 的公式是 :K = LA 3/( CkA 3* tdM )
      其中: L 代表源代码行数(以行计),K代表整个开发过程所花费的工作 M (以人年计),td表示开发持续时间(以年计),Ck表示技术状态常数,它反映“ 妨碍开发进展的限制” ,取值因开发环境而异。
      
    COCOMOII 模型
      COCOMOII 模型由BarryW.Boehm教授提出。模型指出,软件开发工作量与软件规模呈指数关系,并且工作量受16个成木驱动因子的影响。COCOMO II 的计算步骤如下:

    1. 估算软件规模 Size ,这里以千代码行( KSLOC ) 计。
    2. 评估比例因子 SF ,求指数 E 。
    3. 求成本驱动因子值 EMi 。求标称进度工作量PM :

    3 、基 于 FP 的工作量估算
      基于功能点(fp)的工作量估算,是从用户的角度来度量软件。进行工作量估算时,先估计出软件项目的功能点数,然后将功能点数( FP ) 转换为人天数。其中,估算功能点数的主要方法有3 种: IFPUG 法、 Mark Ⅱ 法、 COSMIC FFP 法。这三种方法现在都已经成为国
    际标准,并有详细的操作手册。
      将功能点( FP ) 转换成人天数主要有2 种方法。
    1 ) 生产率法:要求有开发商每人天开发的功能点数,估算出功能点数后,直接利用功能点数+功能点/天,即得工作量人天数。对于开发商每人天开发的功能点数, SPR有统计,中国的值大约在5.5个功能点/人月。
    2 ) 经验模型法:可以依照本企业的历史数据得到关于功能点和工作量的统计方程也可以采用己有的经验模型,例如: COCOMO II模型(只需将 COCOMO II模型中的 Size 用未调整功能点数 UFP替换即可, 具体可看 COCOMO 的那本参考书)

      以上就是本人查阅资料总结的一些关于工作量估计的一些方法,我们小组采用的方法就书上的WBS方法,本人觉得这个方法是最直接也是最好操作的,难点在于我们将项目分解后,无法找到历史项目或者凭经验来类比,只能通过平时写代码经验加自我感觉去评估。

  • 相关阅读:
    POJ 2253 Frogger
    POJ 2387
    codevs3981动态最大子段和(线段树)
    P3398仓鼠(LCA)
    codevs1036商务旅行(LCA)
    codevs3728联合权值(LCA)
    P3390矩阵快速幂
    codevs1574广义斐波那契数列
    POJ3070Fibonacci
    P3379最近公共祖先(LCA)
  • 原文地址:https://www.cnblogs.com/xhw123/p/5353327.html
Copyright © 2020-2023  润新知