小蚂蚁  
风雨过后才见彩虹
公告

  • —————————————
    李丽君
    软件测试工作者
    广东籍贯的海南人
    北京生活12年
    目前在深圳

    邮箱:
    llj2003hbdd@163.com
    —————————————
    说明:本Blog中的内容均为本人原创或转载,本人依法保留Blog内原创文章的所有权利,如需转载,请注明作者及出处。未经许可,不得将本Blog内文章用于任何盈利性用途。
    —————————————
日历
<2010年7月>
27282930123
45678910
11121314151617
18192021222324
25262728293031
1234567

导航

常用链接

留言簿(174)

随笔分类(189)

0--感兴趣的网站

1--国内测试网站

2--测试同行的blog

3--开发好友的blog

最新评论

 
 

编写背景:

    今年的测试任务,开发工期非常紧张,导致开发提测的版本质量很差,每个月的bug总数都过百,对测试工作进度有一定影响;时间长了,对于这个现象突然觉的已经习惯了,对开发质量的改进工作已经不抱希望;但对测试工作的质量和效率改进还是很有期待。

这篇文章多少反馈了IT项目中的一些真实现象,在此收藏供以后查阅,题目我给改了!!

文章出处:http://www.blogjava.net/zbw25/archive/2005/11/07/20897.html

  在探寻软件开发以往的方法论背后的假设之前,首先要指出的是,这些假设很难被发现,不是说它们不存在,而是这些加上很少被看成是假设,往往作为理所当然的一部分,被排除在常规的思考范围之外。让我们来看几段大家都很熟悉的文字吧。
  大多数大型软件项目都没有达到预期的目标,交付推迟,预算超支,功能不完善。许多软件项目彻底失败了。
    ——FDD
  当前,软件开发的情况并不理想。很多系统最终不能交付,或者最终交付的系统经常性地发生延期或者超出预算;系统常常不能满足用户的需要,其结果是不得不一遍又一遍地开发。
    ——AM
  许多软件项目,或许应该说大部分软件项目实际的开发周期比预期的要长,实际的花费比预期的要多,实现的功能比预期的要少。这造成了严重的质量问题。
    ——某一本CMM的书籍
  怎么样,是不是似曾相识?我敢肯定,你不只在一本书的序言部分,看到过类似的文字。无论这本书写于70年代、80年代、90年代还是21世纪。情况一直都是这么糟糕。有趣的是,这些书都会在痛说软件开发现状之后,转而兜售自己的方案。当然,在Brooks的《没有银弹》之后,他们兜售的语气谦虚了很多。作为一个文化现象来说,这非常值得细细品味。但是,我们需要追问的是:为什么?
  难道软件开发是全世界最难的事情吗?为什么失败率如此之高?如果我们在使用了层出不穷的手段之后,还是不能提高成功率,我们应该怎么办?其实也很容易,当年我的一个老板就想出了一个绝妙的办法,绝对简单,就是将我自己的工作量估算乘2!我们的项目几乎从不失败,总是能够在计划时间内完成。于是我想,如果我们把全世界的软件项目估算都乘以2的话。也许软件开发这个行当,也能成为一个有尊严的职业。大家都会生活得更加幸福。
  这实在是太过分了!也许有人会说:你这是自欺欺人、掩耳盗铃、移靶就箭!但是且慢生气,生气的人应该冷静下来反思:如果目标如此难以达到,会不会是目标有问题呢?当然,事情没有这么简单,如果把目标直接乘2来提高成功率,全世界的老板都会发疯的!我们要做的,是提高估算的准确性。
  啧啧,还以为是什么了不得的结论呢!这个问题早就有人研究了,不就是IT度量吗?一定会有人站出来这么说。但是,IT度量的研究,提高了估算的准确度了吗?思路在这里被卡住了。直到有一天,我看到了量子力学中的测不准原理
  测不准原理告诉我们,在物理学中存在着很多对变量,当我们想要精确测量其中一个变量时,对另一个变量的测量误差就会越来越大。但是,在软件开发里,我们是进行估算,而不是进行测量,而且也不存在一个和工作量相对的变量,当工作量估算准确时,它会变得模糊。简单地套用物理定律是行不通的,思路又卡住了。
  突然有一天,我问自己:假设工作量已经估算精确到了99.9999%会出现什么情况?”“不可能!”“如果真的达到了这个精确度了呢?我对自己穷追不舍。那只有一种情况,就是项目已经接近完成了!”“我们估算完成时,项目接近完成,这意味着什么呢?”“这毫无意义,没有一个项目会花这个多时间来估算,而且如果要这样估算,估算本身要花多少时间都不知道。停!我已经想通这个问题了。
  估算工作量也是一种工作,同样也需要工作量。对于大多数任务来说,估算所花费的工作量,相对与总的工作量来说,几乎可以忽略不计,或者说:为了能够得到一个有指导价值的估算值,所花费的工作量,几乎可以忽略。但是,对于软件开发来说,这只是一个假设。我们假设对于软件开发的工作量估算,同样只需要花费极少的工作量。但事实上,当我们花费三五天时间得出结论,这个项目需要20个人月时,我们估算的误差,可能(甚至一定)会大于200%这就是我们这个行业显得如此失败的原因。
  为什么这个行业与其它行业不同呢?在建筑行业,工程概预算的费用,不超过总费用的百分之一、甚至千分之一。为什么软件项目的估算做不到这一点?因为两个原因:
  一是由于技术的复杂性,以及这个行业技术的飞速发展(也可说尚未定型),同样的需求,采用不同的设计,不同的技术实现,工作量相差极大。仅仅根据需求,无法估算出工作量。而随着概要设计、详细设计的层层分解,工作量估算的精确度的确会提高,但是对于软件开发来说,项目也越来越接近完成了。
  二是由于需求的变动性以及不可预测性。早期的估算、设计甚至代码,都有可能作废。一个项目实际上重做了N遍,在软件开发领域也是常有的事。估算的误差,自然也就大到不可思议了。
  然而,绝大多数人没有想过这个问题,大家都自然而然的根据最初的工作量估算,来评价以后的工作。
    工作量/人员效率=项目时间
    工作量×单位成本=项目成本
    缺陷总数/工作量=软件质量
  我们根据最初估算的工作量,来推出项目的时间、成本和质量目标,我们假设工作量估算只花费可以忽略不计的工作量,我们依据这些目标来衡量项目的成败,然后我们发现大多数项目都失败了,然后我们研究技术、改进过程、寻找银弹!最终,我们发现自己还是这么失败!
  是到了彻底反省我们的假设的时候了。

posted on 2010-07-29 16:56 lijun 阅读(676) 评论(0)  编辑  收藏 所属分类: 测试人生相关文档

只有注册用户登录后才能发表评论。


网站导航:
 
 
Copyright © lijun Powered by: 博客园 模板提供:沪江博客