项目质量控制：分析阶段

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

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

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

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

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