人、系统分析员以及技术支持所了解。为保证分析工作高质量进行，同时分析工作又不被过分打扰，质量监督组则主要针对《系统分析报告》进行复审，只在认为确实有必要的情况下才召开质量复审会议。质量复审会议的主要参与者是项目经理、项目负责人、分析人员和质量监督组组长。会议的主要议题是提出质量质疑，给出改进建议即可。具体是否存在质量问题，是否需要改进，不在会议中进行讨论。以此保证了会议参与的人数较少，会议的时间尽可能的短。
通过技术支持的职责可以发现，技术支持参与分析调研有利于对分析工作的监督，在获得用户需求的口头表达之后，能帮助技术支持更好地扮演开发阶段"用户"的角色。技术支持具有相当的计算机技术背景，在接下来的开发过程中就能较好的起到监督的作用，也为将来维护和为用户提供更好的服务奠定基础。
系统设计
优良的体系结构应当具备可扩展性和可配置性，这两方面因素的实现是通过Windows DNA的应用完成的，正如建议书中所述，在此不再赘述。
实现
实现也就是代码的生产过程。从设计的结构图中可以看出，生产的类别有类的生产，组件的生产，构件的生产，应用系统的整合，以及各种测试用例的生产。为了能够提高生产的质量，我们将生产的程序人员按职能分成两组，测试用例的生产和测试用例生产，也就是说如果某个程序员生产了某个组件，则其测试用例不能再由该程序员来生产，但他可以生产其他组件的测试用例。这样交叉生产更容易发现组件的存在的问题。测试人员按照测试用例来测试组件的各项指标提出测试报告。
随生产的不断深入，组件的生产日趋减少，构件的生产的量开始逐步增加，生产构件的过程又是对组件的考验过程。因此描述组件实现的文档是非常重要的，它将有可能成为阻碍进一步生产的瓶颈。文档组在生产过程中的重要工作是对各类部件的文档进行丰富和规范，同时进行版本的控制。文档的完备与否，在开发的后期，对项目进度有至关重要的影响。文档是共享前期开发成果的唯一手段。根据上一节描述的应用系统体系结构来看，整个开发环节丝丝相扣，每一步都受到上一步的制约。
为了控制系统开发过程中的往复，不至于产生重大过失和往复的泛滥。文档组和质量监督组协同完成软件开发的配置管理。
软件配置管理的目的在于控制软件开发过程中的"变化"，这种变化可能是外部引起的，如需求的变化。也可能是来自于内部的变化，如早期设计的某个部件不够完备，需要修改等。为了控制这些变化，把变化引起的波动尽可能的控制在有限的范围内，配置管理的管理模型如下图：
配置项是指需要进行控制的任何文档单元，它可能是需求说明报告，也可能是需求说明报告的某个点。在本项目中需要控制的内部配置项包括需求报告，设计报告，组件代码，组件接口文档，构件及构件相关文档；外部配置项包括项目计划书，使用手册，系统安装说明和系统配置说明等。
上图完整描述了软件配置管理的流程。
从图中可以看出在文档没有被提交出开发组以前，文档可以在开发组内部"任意"地被修改，但一旦文档被提交，则相关的部门就会被调动，来维护文档的质量。因此为了保证工作效率，开发组提交文档之前必须慎重，以免引起不必要的工作量的增加。从另一角度来看，开发部受到严密的监督，从而保证了开发的各个环节对于开发的全过程保持透明，避免了因为个人的原因造成整个开发的瘫痪或受阻。项目经理通过质监报告可以了项目开发的进度和质量情况，为调整开发计划提供有利的依据。
显然开发部的内部流程在配置管理的过程中受到的监管是非常有限的。配置管理所能起的作用完全是建立在文档之上。当项目进度非常紧张时