又一个项目结束了，终于闲出空来写些东西．有了以前的经验教训，这次在做项目的时候，我对时间的控制很关注，最后也基本上达到了计划的要求． 但最终交付产品的质量却让我不太满意：客户在做接受测试的时候发现了很多的问题，而且在我们进行修改的同时，又有BUG源源不断的报过来．甚至把更新的版本发给客户以后，还会发现不少问题．给客户留下了很不professional的印象．为什么问题总是要到项目快结束的时候才会出现呢？软件的质量为何不好？究竟是谁动了项目的质量？
大家知道，项目的时间、成本及质量的三大要素是缺一不可．这三方面的符合程度直接决定了项目的成败与否．但事实上，想达到一个完美的等边三角形几乎是不可能完成的任务．这次的项目就让质量这个角短了很多，质量的问题暴露地很明显．所以，接下来，我就从项目的流程角度出发，一步步地分析到底是哪里出了质量问题．
１．分析阶段
项目的开始阶段，也是质量控制的开始．在这个阶段中，主要的工作是从客户方获得足够多的项目需求，并准确地记录在案，而且要使得项目组的成员对于需求足够得了解．先说说这个项目的基本情况：一个信息管理系统，而且是在原来的版本上进行的功能增加．项目组的成员，除了我以前参加了前一个版本的开发，其它的人员都不了解这个项目．就是这样的一个项目，在开始阶段，我先是安排了组员对以前版本的需求文档进行了阅读，并安装使用了软件．随后对新的需求进行了研究，分析了它们对于原有系统的影响．由于是在旧有系统的文档进行增加，所以加入的新内容并不是很多，需求文档很快就完成了．所谓的分析阶段的里程碑也就结束了．
在需求阶段＂顺利＂结束的同时，问题也随之留下来，并对后面的阶段起到了＂乘数效应＂――影响变得越来越大：
A. 对旧系统的理解不足
由于开发人员没有参与过上一个版本的开发工作，他们对于旧系统并不了解．虽然在阅读了以前的需求文档以及使用了软件之后，大概对系统的功能有了一个初步的认识．但是对于系统中出现的各种逻辑关系并没有深入了解下去．作为项目经理，在这项工作中，失误之处在于任务的结果（即输出）没有事先定义清楚，从而也就导致无法确认目标是否已经达到，再加上需求文档描述的也不是十分清晰．最后，只是在开发人员觉得已经理解该系统的基本上，进行了下一步的工作．没有进行进一步的确认工作，不知道组员进行旧系统已经了解到了什么样的程度．这个问题的结果，就是直接导致了后期的开发过程中，由于对于原先系统的逻辑关系不是很清楚．对于旧代码理解和新代码编写进行地不是很顺利．
B. 对新需求的分析不够
这还是个老问题，但又不是一个问题．说它是个老问题，因为分析需求要求考虑细致全面，并且能引导客户，启发客户提供更有价值的信息．事实上，需求分析我们做的算是很尽力了，同时客户把需求一条条的列出来给我们，相对来说需求已经很清楚了．我们在接到这些需求后，不仅研究了新功能，还把他们对于旧系统的影响都做了分析．但还是有些问题没有能在需求文档中反映出来，后面的影响也是可想而知的了．我以前的文章中才曾提到过相关的问题，在这里就不再重复了．不过，从另一个角度来看，它又不是一个问题．为什么这么说呢，因为需求实在不是能够在分析阶段就能完全理解透彻的，甚至有的需求客户也模模糊糊，直到交付以后才提出了改动的要求．软件开发经过这么多年的发展，大家已经认识到了一点：需求是变化的．要达到能够拥抱变化的要求，我们要对开发方法进行改进，相关的问题我在后面也会提到．
需求分析阶段出现的问题，解决的可操作性不是很大，更多的是从思想或经验上解决，而后面几个阶段出现的问题都相对具体一些．
２．设计阶段
设计阶段的问题相对比较明显――结构设计不合理，或者说还不够．一个传统的Ｃ／Ｓ结构的系统，基本结构我们采用了经典的三层模型来划分系统．由于是在旧有系统上的改进，我们在尽量不改变原有系统的基础上添加新的功能．
主要的问题可能就是体现在没有对旧系统进行改进．旧系统本身有一些复杂的功能，逻辑关系也比较复杂，耦合度非常高．所以，在新需求来临的时候，我们的第一反应就是尽量不去动原来的设计与代码，保证原有系统功能不会发生变化．这一点就暴露出了我们没有去拥抱变化的决心与胆量．虽然旧系统很复杂，但是我们不能去故意回避它．对于旧系统中设计的不合理的地方，应该主动大胆的去进行重构．其实重构的作用就是对不合理结构的进行改进，设计模式更是在设计结构的变化改进中才能体现它的价值．而这些东西，在我们的项目中都没有应用．这可能跟我们的保守心理有关：只要不出问题，我们就不去动它，哪怕结构是多么的错综复杂．这种消极的观念在当今的充满变化的世界中是不太有前途的．项目经理要有足够的决心去做，同时，也不要担心去变化．当然，可能有人会说，时间紧怎么办，其实这种付出对于项目的整体是只有好处没有坏处的，因为结构合理会让开发人员会更少的时间去理解代码，减少代码开发的复杂度，提高代码编写的质量．唯一需要考虑的就是如果改动的话，如何来保证这种变化对原有系统的功能不产生影响．这就需要有更多的测试，最好是单元测试来保证，这就是下面会谈到的问题．
３．编码阶段
编码主要还是受了设计的限制,我们的主要工作就只是在原有的结构上添加一些类与方法，以及对原有的代码进行修改．前面也提到了，我们采用了比较保守的作法，没有对代码进行重构，放任这种高耦合的代码存在，导致我们在编码过程中花费了不少精力和时间去理解它们，并在其中加上一两条更加加深耦合度的代码．其实到了编码阶段，很多问题都纠缠到了一起，已经分不清因果了．比较说单元测试，首先我需要承认的一点就是没有足够的决心去做充分的单元测试，思想上也没有做好充分的准备．除去主观的因素之外，还有一点就是设计的结构不合理，很多的逻辑被处理在表示层中，数据处理则被加到了逻辑层中．没有划分出更多的接口供单元测试来验证．但反过来说，没有单元测试用例的支持，也降低了我们想要进行重构的决心．除了上述的问题之外，还有一些细节的地方，如硬编码，命名规则等都在一定程度上对代码的质量产生了影响．
改进的办法，一是从主观上接受变化的现实，主动的对代码进行改动．单元测试一定要进行，最好结合统计覆盖率的工具一并进行，这样对于每个接口，都保证有充分多的测试用例来跑完尽可能多的路径．在项目的质量管理上面，要求还需要更加严格一些，一定要按照规范来进行编码．
４．测试阶段
代码完成之后，测试的工作也随之展开．但是由于成本的原因，我们并没有再加入专业的测试人员来进行，而只是用开发人员自己来进行系统测试，让开发人员互相测试别人实现的功能．由于开发人员与测试人员所需的专注点不同，造成了开发人员很多问题在测试中没有被发现，缺乏测试的经验．从另一个方面说，是开发人员不能够及时的转换自己的角色，而是还把自己定位在开发人员上面，更加关注的问题出在什么地方并立刻去解决它,而不是设法去发现隐藏的ＢＵＧ．当然，还有一些细节的地方，比如说测试都应该是开发人员发布一个安装包，然后单独进行测试，但有的时候为了图省事，有的功能在调试状态下发现通过了，在安装包中就没有再验证，有时也会出现意想不到的情况发生．
大家可以看到，软件的质量可能就是被这一步步的失误，错误，粗心等等影响了．这些问题都是在项目管理中暴露出来的，可以说是由于项目经理对于质量的要求还不高，有的时候为了片面追求成本与时间而忽视了质量，从而造成了质量的下降．算是个总结和教训吧．也希望大家能够说出你的想法与意见，多多交流，共同进步．