软件工程工作量的估算

这段时间在想关于软件工程的问题。

记得以前看过软件工程方面的书,但是很多东西都已经忘了,所以我也就从自己的实际出发来思考软件工程的问题。首先,从最近的北京报表之行吧,记得大/r 约两三周前,我数了一下我那时已完成的工作。因为我习惯会给自己列一个详细的功能点,完成了就打个勾。结果我数了一下,并按照实际完成情况,发现我大约也 就是一天完成一两个功能点左右,也就是我一个月下来大约30-40个点。

我自己定义的点粒度大概为界面上一个鼠标或者键盘操作带来的其它变化,譬如拖动一个Tree的节点到一个列表中放开,则列表有对应的项;又如,添加 一个过滤字符串的选择,则可以过滤掉Tree的对应节点。当然有的功能点和已经完成的功能点比较相似的话,完成就是复用代码的事情,所以还是比较容易的, 如果想对比较容易的话,就不算功能点了;当然如果一些已经很熟悉的框架代码也就不算什么功能点了;所以功能点在我的定义中是,让我觉得我必须花时间去设计 才可完成的功能。

当然我也不会觉得一两个功能点一天有什么不妥,只是觉得好像这些功能点如果有个比较傻的机器人来写倒是不错。之后我又觉得,是不是我的工作效率一直 就是这个一两个功能点每天呢?于是我就想,我可以考虑数一下之前花了大约3个多月时间写的文档生成的那个项目。但是一时我不高兴数,于是估计了一下,20 天*3.5月*2个大约是140个功能点,之后我又想如果我这个是平均效率的话,那么另外一个组在做的jsp编辑器的功能点是150个*4人大约600多/r 个吧,不过当时只是这么想着,并没有立刻去数。

今天觉得,如果把东西给记录下来,估计会忘掉的。于是我决定数一下文档生成我大约实现了多少个功能点。数的结果是界面上大概40个左右,三种文档本 身大约有50个左右,而底层文档生成工具实现的功能点大约20多个,性能方面的功能点10-20个,总体的功能点个数和我之前估算的相差不是很大。再想去 数那个jsp编辑器的功能点,大概数了一百多个的时候,我放弃了,因为我发现我不知道很多实现方面的细节,而我又知道这个编辑器用了ibm的一个框架,所/r 以具体该如何数只属于这个四个人在这段时间添加的功能点,我无法判定。不过我相信功能点也在我估算的范围。

之后我也就想起了原来尚未扩展的jsp编辑器,我稍微想一下,那个编辑器大概也就是10个功能点左右吧(主要是eclipse的text editor吧),那么从10个功能点一下子扩充到600多个(或者实际上是1500多个?)功能点,这里面的开发模式应该是如何处理的呢?这个好像,还 是挺有学问的,我认为。首先扩展功能点到10倍,可能是一种情况;再在10倍的基础上扩展10倍,这也是一种情况;而一下子扩展100倍,也是一种情况。 10倍10倍地扩展,则属于一般人可以控制的范围,但是如果一下扩展100倍(甚至1000倍)的话,已经不能算是简单的功能扩展了,而更多的是涉及到新 的框架的编写或者介入,新的工程管理模式,所以也是存在比较大的风险。

其实任何一个东西,都可以进行功能点的扩展,很熟悉的“记事本”,有人扩展为“ultraedit”,则这里面的功能点扩展至少是1000倍了。这/r 就要求一个软件工程在功能点数上的限定了,譬如说我这个东西我本来就只是想弄得简单点的,你就甭给我扩展了。一个编码人员没有节制地给你添加新的功能点只 会增加总体成本,成本的增加可能并不能够在软件的收益上得到回报,所以从一定程度上说,你老实点给我把必须的一些功能做好了就够了,甭天马行空了。这个我 在文档生成的实现上是有教训的。文档生成的东西确实你可以无限的做,大不了还可以引入一套类似编辑word文档的编辑框架来做。但是这绝对是不对的,绝对 是错误的。

但是还有另外一个问题,所谓的设计完整性问题。一个设计,如果就设计那么不多不少的功能点,那么可能会带了设计完整性的问题。就如一个jsp编辑 器,如果你从15个功能点开始扩展10倍到150个功能点,那么这没有质的变化,甚至给人的感觉是怎么这个东西总是那么让人别扭,提供了一些比较有用的功 能,可是确不做好,只做了一半,没有做完整。这个对于设计者来说,应该注意的,要么你就直接扩展100倍,要么你别扩展了。所以有时候编码人员很容易不注 意地扩展了功能点,造成设计和过程管理的冲突。另外的是给编码人员一个阈值,譬如可以跟编码人员说:嘿,你把这里面的一些功能扩展一倍就到顶了,别多弄了 啊。当然编码人员从那些方面和如何扩展功能点,以及设计人员设定扩展多少倍的功能点,就要看人员的水平了。

说了这么多,说回来我的实际经历的情况。我重新查看了一下之前几个月的代码情况,突然发现我平均每个月贡献的代码行数大概是10000多行,平均下 来每天500多行,当然如果去掉一些无用代码段和注释的话,大概在每天400行左右,之后想想,好像太多了点,是不对的,代码质量不能保证。想查一下大概 什么范围的代码行数是正常的,不过倒是发现其实代码行数多少是无所谓的,有两篇文章写的还不错:
1.It's Not About Lines of Code --By Charles Connell
http://www.developer.com/java/other/article.php/988641
2.软件开发过程的定量监理 作者:中国软件评测中心 陈兵
http://tech.ccidnet.com/pub/article/c29_a77106_p1.html
虽/r 然代码行数不是什么问题,还是值得关注的,譬如我在刚过去的9月份,就往报表的项目里添加了20000行新代码!而报表还准备10月初封代码的,这个…… 我添的代码是否太多了?是否我这个月来扩展的功能点倍数太大了,是否应该重新调整一下产品的质量,以保证软件工程管理能按时按点进行?这个是值得深思的问 题。

记录下来,以免以后忘了自己曾这么思考过软件工程的问题。

October 02 12:42 PM

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值