谁动了项目的质量

申请免费试用、咨询电话：400-8352-114

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

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

　　1、分析阶段项目管理培训

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

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

　　A. 对旧系统的理解不足training

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

　　B. 对新需求的分析不够泛普软件-建筑工程项目管理系统

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

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

　　2、设计阶段bbs

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

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

　　3、编码阶段泛普软件-建筑工程项目管理系统

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