浅谈软件开发工作量估算方法.docVIP

浅谈软件开发工作量估算方法?? 2010-05-15 18:21:13|??分类： 项目管理 |??标签： |字号大中小?订阅 打开博客，发现最新的一篇博文仍是1月15日发表的。1月16日本是我发表博文的，但因家里有事（外婆去世，1月16日提前离校回家），没有更新博客。今天补发一篇，亦更新一下博客。文章的主题是：软件开发工作量估算，主要是将自己过去对软件规模（工作量）估算方法的研究做一个初步小结，给大家提供参考。原创作品，如有错误，敬请指出，欢迎交流。 在详细讨论软件开发工作量估算方法前，先回答几个问题： 1、什么是工作量估算？工作量估算和规模估算的区别？ 有书上定义（Swapna Kishore, Rajesh Naik 著.? 软件需求与估算. 机械工业出版社）：“工作量估算，这是对开发软件产品所需的人力的估算。这是任何软件项目所共有的主要成本。它和进度估算一起决定了开发团队的规模和构建。通常以人天、人月、人年的形式来衡量，并且有转换系数在不同单位之间进行转换。工作量估算是由规模和与项目有关的因素所驱动的，如团队的技术和能力、所使用的语言和平台、平台的可用性与适用性、团队的稳定性、项目中的自动化程度等等。” 当然，这个定义可能不是最权威的定义。我理解的工作量估算，就是估算软件项目所耗费的资源数，这个资源包含人力和时间，一般用人天、人月的形式来衡量。（而软件的成本=耗费的资源*资源的单价）。 软件规模是软件的大小。有的书上把工作量估算等同于规模估算，认为人天和规模估算的单位（如功能点、代码行）是等效的，都是度量了软件的大小。我认为这个是不妥的。软件的大小应该是固定不变的，不会因为不同公司开发大小不同，它只跟需求有关；而工作量会因为开发公司的不同而不同。生产率低的公司，开发同一个软件所需的人天数一般也会多。因此，我个人比较同意上段的定义“工作量估算是由规模和与项目有关的因素所驱动的”。 有一张图片，说明了规模估算、工作量估算、成本估算等的关系，但我现在暂时传不了。（这副图我曾经在交流会上展示过）图片大致是说：由软件需求估算出软件的规模，再考虑一些项目的因素，即可估算得到软件的工作量，而软件的成本就由软件工作量来决定。也就是说，存在下述链条关系：需求——规模估算——工作量估算——成本估算。 但我觉得，其实是可以直接从软件的规模得到软件的成本。也就是说，存在两个链条:1)需求——规模估算——工作量估算——成本估算。2）需求——规模估算——成本估算。?由两种公式计算软件成本：1）软件成本=工作量（人天）*人工费率（元/人天）；2）软件成本=规模（功能点、代码行）*单位规模成本（元/功能点、元/代码行）? （PS：这两个公式很像，也许正是因为这个想象的公式，所以有人就把工作量估算和规模估算等效了） 2、为什么要做工作量估算？ 做软件估算，最重要的是要得到软件的成本估算，为软件投资提供依据。上面讲了规模估算、工作量估算、成本估算等的关系。也许有人会问，既然可以直接从规模得到软件的成本，又为什么要绕个圈，做工作量估算呢。我想原因可能有：1）大部分企业/开发商没有历史数据的积累，单位规模成本（元/功能点、元/代码行..）不确定；2）以前企业都是用工作量（人天）*人工费率（元/人天）来估算成本的，由于历史合作谈判的积累，企业对于开发商的人天单价定价基本是确定的（或有小小的浮动范围），所以用工作量估算成本还是比较方便的，会省一些谈判成本吧。也就是说，对现阶段的大部分企业来说，可能用软件成本=工作量*人工费率这个公式估算成本还是比较好的，即便有些公司开始推行功能点法，但过渡时期还是要先转换工作量再估算。除非企业愿意花谈判成本去和开发商讨论出一个彼此都接受的单位规模成本。 好了，下面步入正题，就是软件工作量估算方法的总结啦。很多文章、书籍都做过类似的总结啦。我主要从估算单位的角度来总结。首先将工作量估算的方法分为两类：直接估算法和间接估算法。直接法指基于WBS的工作量估算方法，直接估算出人天工作量；间接估算法是先估算软件规模，再转换成人天工作量。根据估算角度的不同，间接法又分为基于代码行（SLOC）的工作量估算方法和基于功能点（FP）的工作量估算方法。不管是哪种工作量估算方法，一般都会用到一些基本的估算方法，如类比法、WBS法、专家估算法等。 1、基于WBS的工作量估算基于WBS的工作量估算方法，是最常见的一种估算方法，也是厂商最常用的。基于WBS的工作量的估算方法，又称为由底向上法（自下而上法），通常的估算步骤如下：1）寻找类似的历史项目，进行项目的类比分析，根据历史项目的工作量凭经验估计本项目的总工作量；2）进行WBS分解，力所能及地将整个项目的任务进行分解；3）参考类似项目的数据，采用类比法或专家法，估计WBS中每类活动的工作量；