项目的时间、成本及质量的三大要素是缺一不可。这三方面的符合程度直接决定了项目的成败与否。那么如何做好项目的质量管理呢？一起来学习学习！

　　1、分析阶段

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

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

　　A. 对旧系统的理解不足

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

　　B. 对新需求的分析不够

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

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

　　2、设计阶段

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

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

　　3、编码阶段

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

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

　　4、测试阶段

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