谁动了项目的质量

  又一个项目结束了,终于闲出空来写些东西.有了以前的经验教训,这次在做项目的时候,我对时间的控制很关注,最后也基本上达到了计划的要求. 但最终交付产品的质量却让我不太满意:客户在做接受测试的时候发现了很多的问题,而且在我们进行修改的同时,又有BUG源源不断的报过来.甚至把更新的版本发给客户以后,还会发现不少问题.给客户留下了很不professional的印象.为什么问题总是要到项目快结束的时候才会出现呢?软件的质量为何不好?究竟是谁动了项目的质量?

  大家知道,项目的时间、成本及质量的三大要素是缺一不可.这三方面的符合程度直接决定了项目的成败与否.但事实上,想达到一个完美的等边三角形几乎是不可能完成的任务.这次的项目就让质量这个角短了很多,质量的问题暴露地很明显.所以,接下来,我就从项目的流程角度出发,一步步地分析到底是哪里出了质量问题.

 1.分析阶段

  项目的开始阶段,也是质量控制的开始.在这个阶段中,主要的工作是从客户方获得足够多的项目需求,并准确地记录在案,而且要使得项目组的成员对于需求足够得了解.先说说这个项目的基本情况:一个信息管理系统,而且是在原来的版本上进行的功能增加.项目组的成员,除了我以前参加了前一个版本的开发,其它的人员都不了解这个项目.就是这样的一个项目,在开始阶段,我先是安排了组员对以前版本的需求文档进行了阅读,并安装使用了软件.随后对新的需求进行了研究,分析了它们对于原有系统的影响.由于是在旧有系统的文档进行增加,所以加入的新内容并不是很多,需求文档很快就完成了.所谓的分析阶段的里程碑也就结束了.

  在需求阶段"顺利"结束的同时,问题也随之留下来,并对后面的阶段起到了"乘数效应"――影响变得越来越大:

   A.        对旧系统的理解不足

  由于开发人员没有参与过上一个版本的开发工作,他们对于旧系统并不了解.虽然在阅读了以前的需求文档以及使用了软件之后,大概对系统的功能有了一个初步的认识.但是对于系统中出现的各种逻辑关系并没有深入了解下去.作为项目经理,在这项工作中,失误之处在于任务的结果(即输出)没有事先定义清楚,从而也就导致无法确认目标是否已经达到,再加上需求文档描述的也不是十分清晰.最后,只是在开发人员觉得已经理解该系统的基本上,进行了下一步的工作.没有进行进一步的确认工作,不知道组员进行旧系统已经了解到了什么样的程度.这个问题的结果,就是直接导致了后期的开发过程中,由于对于原先系统的逻辑关系不是很清楚.对于旧代码理解和新代码编写进行地不是很顺利.

   B.       对新需求的分析不够

  这还是个老问题,但又不是一个问题.说它是个老问题,因为分析需求要求考虑细致全面,并且能引导客户,启发客户提供更有价值的信息.事实上,需求分析我们做的算是很尽力了,同时客户把需求一条条的列出来给我们,相对来说需求已经很清楚了.我们在接到这些需求后,不仅研究了新功能,还把他们对于旧系统的影响都做了分析.但还是有些问题没有能在需求文档中反映出来,后面的影响也是可想而知的了.我以前的文章中才曾提到过相关的问题,在这里就不再重复了.不过,从另一个角度来看,它又不是一个问题.为什么这么说呢,因为需求实在不是能够在分析阶段就能完全理解透彻的,甚至有的需求客户也模模糊糊,直到交付以后才提出了改动的要求.软件开发经过这么多年的发展,大家已经认识到了一点:需求是变化的.要达到能够拥抱变化的要求,我们要对开发方法进行改进,相关的问题我在后面也会提到.

  需求分析阶段出现的问题,解决的可操作性不是很大,更多的是从思想或经验上解决,而后面几个阶段出现的问题都相对具体一些.

 2.设计阶段

  设计阶段的问题相对比较明显――结构设计不合理,或者说还不够.一个传统的C/S结构的系统,基本结构我们采用了经典的三层模型来划分系统.由于是在旧有系统上的改进,我们在尽量不改变原有系统的基础上添加新的功能.

  主要的问题可能就是体现在没有对旧系统进行改进.旧系统本身有一些复杂的功能,逻辑关系也比较复杂,耦合度非常高.所以,在新需求来临的时候,我们的第一反应就是尽量不去动原来的设计与代码,保证原有系统功能不会发生变化.这一点就暴露出了我们没有去拥抱变化的决心与胆量.虽然旧系统很复杂,但是我们不能去故意回避它.对于旧系统中设计的不合理的地方,应该主动大胆的去进行重构.其实重构的作用就是对不合理结构的进行改进,设计模式更是在设计结构的变化改进中才能体现它的价值.而这些东西,在我们的项目中都没有应用.这可能跟我们的保守心理有关:只要不出问题,我们就不去动它,哪怕结构是多么的错综复杂.这种消极的观念在当今的充满变化的世界中是不太有前途的.项目经理要有足够的决心去做,同时,也不要担心去变化.当然,可能有人会说,时间紧怎么办,其实这种付出对于项目的整体是只有好处没有坏处的,因为结构合理会让开发人员会更少的时间去理解代码,减少代码开发的复杂度,提高代码编写的质量.唯一需要考虑的就是如果改动的话,如何来保证这种变化对原有系统的功能不产生影响.这就需要有更多的测试,最好是单元测试来保证,这就是下面会谈到的问题.

 3.编码阶段

  编码主要还是受了设计的限制,我们的主要工作就只是在原有的结构上添加一些类与方法,以及对原有的代码进行修改.前面也提到了,我们采用了比较保守的作法,没有对代码进行重构,放任这种高耦合的代码存在,导致我们在编码过程中花费了不少精力和时间去理解它们,并在其中加上一两条更加加深耦合度的代码.其实到了编码阶段,很多问题都纠缠到了一起,已经分不清因果了.比较说单元测试,首先我需要承认的一点就是没有足够的决心去做充分的单元测试,思想上也没有做好充分的准备.除去主观的因素之外,还有一点就是设计的结构不合理,很多的逻辑被处理在表示层中,数据处理则被加到了逻辑层中.没有划分出更多的接口供单元测试来验证.但反过来说,没有单元测试用例的支持,也降低了我们想要进行重构的决心.除了上述的问题之外,还有一些细节的地方,如硬编码,命名规则等都在一定程度上对代码的质量产生了影响.

  改进的办法,一是从主观上接受变化的现实,主动的对代码进行改动.单元测试一定要进行,最好结合统计覆盖率的工具一并进行,这样对于每个接口,都保证有充分多的测试用例来跑完尽可能多的路径.在项目的质量管理上面,要求还需要更加严格一些,一定要按照规范来进行编码.

 4.测试阶段

  代码完成之后,测试的工作也随之展开.但是由于成本的原因,我们并没有再加入专业的测试人员来进行,而只是用开发人员自己来进行系统测试,让开发人员互相测试别人实现的功能.由于开发人员与测试人员所需的专注点不同,造成了开发人员很多问题在测试中没有被发现,缺乏测试的经验.从另一个方面说,是开发人员不能够及时的转换自己的角色,而是还把自己定位在开发人员上面,更加关注的问题出在什么地方并立刻去解决它,而不是设法去发现隐藏的BUG.当然,还有一些细节的地方,比如说测试都应该是开发人员发布一个安装包,然后单独进行测试,但有的时候为了图省事,有的功能在调试状态下发现通过了,在安装包中就没有再验证,有时也会出现意想不到的情况发生.

   大家可以看到,软件的质量可能就是被这一步步的失误,错误,粗心等等影响了.这些问题都是在项目管理中暴露出来的,可以说是由于项目经理对于质量的要求还不高,有的时候为了片面追求成本与时间而忽视了质量,从而造成了质量的下降.算是个总结和教训吧.也希望大家能够说出你的想法与意见,多多交流,共同进步.

posted on 2006-12-11 10:39  布鲁斯南  阅读(8974)  评论(25编辑  收藏  举报

导航

本博客所有文章版权归本人所有,不得转为商业用途. 如需转载,请注明来源. 作者保留所有权利.

Google PR? - Post your Page Rank with MyGooglePageRank.com