关于工作量估算,我提一个自己的看法

dxymm 2004-05-08 11:37:09
我们公司的项目都是差不多,很多时候可以套用,但是因为通用性没做好,导致很多时候要重写

经常做此类项目

我提一个工作量估算的公式

工作量=复杂度的平方 / 旧模式的相近度(0.1 - 0.9)

大家认为如何?
...全文
543 8 点赞 打赏 收藏 举报
写回复
8 条回复
切换为时间正序
当前发帖距今超过3年,不再开放新的回复
发表回复
linnet2000 2004-06-11
功能点的计算由于开发工具的不同,参数也不同,诸如COCOMO模型等经验公式,没有实际意义。
  • 打赏
  • 举报
回复
rolandash 2004-06-08
都是经验公式而已,不可能强求一致
  • 打赏
  • 举报
回复
sxzz 2004-06-08
我不知道用你的公式最后得出的工作量是什么或多少。
我认为:
工作量的度量单位:人时、人天、人月、人年,1人年=12人月,1人月=22人天,1人天=8人时;
工作量的种类:研发工作量、管理工作量、支撑工作量。
研发工作量≈新开发软件规模*难度系数/人均生产率。
管理工作量≈项目研发工作量*比例系数。
支撑工作量≈项目研发工作量*比例系数。
在这里“新开发软件规模、难度系数、人均生产率、比例系数”将会因为各公司各团队的不同而有差别,具体的取值会因人而异,更多的会是经验数据。
软件规模的定义方法有很多文献介绍,大家可以选一些参照,较常见的定义方法是代码行定义法:
1. 小规模软件源程序行数小于5000的软件;
2. 中规模软件源程序行数为10000~50000的软件;
3. 大规模软件源程序行数为100000—500000的软件;
4. 特大规模软件源程序行数大于500000的软件。
难度系数就更主观了,可以说完全由团队实际情况根据经验给出。
我觉得这样的量化也许直观一些。
  • 打赏
  • 举报
回复
dxymm 2004-05-09
Good,我没从头到尾读过《人月神话》,只大致翻阅了一下,有时间一定仔细研究。

至于是1.5还是2,我觉得这是一个对开发工具熟悉的程序

如果对开发工具异常熟悉,1.5有可能,但是如果不是非常熟悉(我感觉国内大部分如此),2还是比较合理,甚至取2.5也不为过

  • 打赏
  • 举报
回复
once168 2004-05-08
COCOMO
  • 打赏
  • 举报
回复
zhf_karen 2004-05-08
嘿嘿,复杂度如何衡量?相近度如何衡量?而且,某些模块不仅仅是复杂和相近的问题,还有很多其他的问题,比如相对过于少的时间,就需要把某个模块的工作量扩大几倍,因为大家承担了过于多的压力。那么你最好还是有个系数来平衡,但是这些要素如果没有大量的用例来证明,还是会出现不是量化而是定性的问题。

不管如何工作量的考核,至少在现在,落实在最后就是主管的主观感受。仅此而已。
  • 打赏
  • 举报
回复
stonespace 2004-05-08
根据《人月神话》的数据,工作量和代码行数的关系是1.5次方,不是平方。复杂度和代码行数的关系应该是线性的。所以复杂度的幂用1.5可能更接近事实。

相近度的幂是不是-1就很难说了,再说感觉搂主对相近度也没有一个精确定义,很难分析相近读的影响。我感觉相近度的幂不应该是-1,相近之所以能够节省工作量,是因为可以重用,而重用导致工作量减少,应该是一个差值,比如我可以重用1000行代码,那么工作量就可以减去1000行代码的工作量。所以用减可能比用除好。
  • 打赏
  • 举报
回复
dxymm 2004-05-08
我的观点

复杂度可拆分成两点
1、模块数、模块功能点
2、技术难点
这里需要做一些研究,搞出一些公式或者数据表出来

相近度可以这样核算
旧模式中可利用的功能点)/旧模式的所有功能点

各位,再想想,还有什么要素要考虑进去
  • 打赏
  • 举报
回复
相关推荐
发帖
研发管理
加入

1227

社区成员

软件工程/管理 管理版
申请成为版主
帖子事件
创建了帖子
2004-05-08 11:37
社区公告
暂无公告