系统设计
优良的体系结构应当具备可扩展性和可配置性，这两方面因素的实现是通过Windows DNA的应用完成的，正如建议书中所述，在此不再赘述。
实现
实现也就是代码的生产过程。从设计的结构图中可以看出，生产的类别有类的生产，组件的生产，构件的生产，应用系统的整合，以及各种测试用例的生产。为了能够提高生产的质量，我们将生产的程序人员按职能分成两组，测试用例的生产和测试用例生产，也就是说如果某个程序员生产了某个组件，则其测试用例不能再由该程序员来生产，但他可以生产其他组件的测试用例。这样交叉生产更容易发现组件的存在的问题。测试人员按照测试用例来测试组件的各项指标提出测试报告。
随生产的不断深入，组件的生产日趋减少，构件的生产的量开始逐步增加，生产构件的过程又是对组件的考验过程。因此描述组件实现的文档是非常重要的，它将有可能成为阻碍进一步生产的瓶颈。文档组在生产过程中的重要工作是对各类部件的文档进行丰富和规范，同时进行版本的控制。文档的完备与否，在开发的后期，对项目进度有至关重要的影响。文档是共享前期开发成果的唯一手段。根据上一节描述的应用系统体系结构来看，整个开发环节丝丝相扣，每一步都受到上一步的制约。
为了控制系统开发过程中的往复，不至于产生重大过失和往复的泛滥。文档组和质量监督组协同完成软件开发的配置管理。
软件配置管理的目的在于控制软件开发过程中的"变化"，这种变化可能是外部引起的，如需求的变化。也可能是来自于内部的变化，如早期设计的某个部件不够完备，需要修改等。为了控制这些变化，把变化引起的波动尽可能的控制在有限的范围内。
配置项是指需要进行控制的任何文档单元，它可能是需求说明报告，也可能是需求说明报告的某个点。在本项目中需要控制的内部配置项包括需求报告，设计报告，组件代码，组件接口文档，构件及构件相关文档；外部配置项包括项目计划书，使用手册，系统安装说明和系统配置说明等。
从图中可以看出在文档没有被提交出开发组以前，文档可以在开发组内部"任意"地被修改，但一旦文档被提交，则相关的部门就会被调动，来维护文档的质量。因此为了保证工作效率，开发组提交文档之前必须慎重，以免引起不必要的工作量的增加。从另一角度来看，开发部受到严密的监督，从而保证了开发的各个环节对于开发的全过程保持透明，避免了因为个人的原因造成整个开发的瘫痪或受阻。项目经理通过质监报告可以了项目开发的进度和质量情况，为调整开发计划提供有利的依据。
显然开发部的内部流程在配置管理的过程中受到的监管是非常有限的。配置管理所能起的作用完全是建立在文档之上。当项目进度非常紧张时，开发部可能书写文档的时间会非常少，在此情况之下质量监督组和文档组就肩负将开发部提供的文档进行丰富和完善的工作，从而减少开发部书写文档的时间，当然这是增加质量监督组与开发部的口头交流为代价的。
测试
测试组的工作被分成若干阶段，不同阶段的划分是以保证软件质量的不同指标为目标的。
测试的软件指标分别包括： 软件的正确性：正确性测试主要是测试软件的功能是否被正确的实现。 测试的方式主要是按照功能的要求按照给定的输入，看是否有给定的输出。在非标称输入时，输出是否异常等。一方面测试软件的功能是否实现，同时是否实现的完整。
性能指标：该项目对性能的要求非同一般的软件项目。性能测试往往包含了压力测试、攻击性测试等测试，软件所能承受的极限是多少，一般来将软件的极限应当高出用户要求的性能，各种指标也应当为用户所了解。
易用性：软件的使用界面在设计实现的时候应当设法使之与功能的实现相脱离。脱离的原因在于易用性是通过友好的界面实现的。然而让开发人员以使用者的角度来确定软件是否易用是件非常困难的事情，在确定使用界面时往往需要多次的反复修改，甚至只能在软件的最后交付之前或用户使用一段时间之后才被提出来。鉴于这种特点，软件在开发的不同阶段都作了相应的保证措施，比如在软件需求界定的时候请领域专家参与，在软件设计阶段，让功能的实现尽可能地包含在软件的组件之中，也就是没有界面要求的底层实现。界面的实现仅仅依赖于一个数据接口，界面仅仅负责将用户输入的数据送到指定的数据块中，用于显示的数据也在指定的数据块中提取，只要保证数据块被互斥的访问就可以了。有了这样的设计结构，软件的易用性也就相当容易保证了。当测试中发现易用性的问题时，软件不会伤到筋骨，皮毛的修改总是非常容易的。
测试人员的角色也是逐步的由开发向用户方向转移。
测试存在两个非常重要的问题，一是保证测试的结果真正是反映了软件的质量。一般来讲，如果测试测出的错误数是收敛的情况，基本认为测试本身应当是比较全面的和足够深入的。二是测试结果的反馈。测试报告是测试结果的正式书面反馈形式。测试报需要经过质量监督组的复审，并进行统计，再形成质量监督报告的一部分，提交到项目经理和项目开发组组长处。同时，测试组产生的测试报告和测试统计报告也要进行归档，以便跟踪软件的质量进展。这也是软件进行版本编号的一个重要依据。
文档维护
文档维护主要是文档组的工作。文档从用途上分主要分为内部文档和外部文档。
内部文档包括： 项目开发计划； 需求分析； 体系结构设计说明； 详细设计说明； 构件索引； 构件成分说明； 构件接口及调用说明； 组件索引； 组件接口及调用说明； 类索引； 类属性及方法说明； 测试报告； 测试统计报告； 质量监督报告； 源代码； 文档分类版本索引； 软件安装打包文件。
外部文档主要包括： 软件安装手册； 软件操作手册； 在线帮助； 系统性能指标报告； 系统操作索引。
文档的重要性在前面的章节中已经多次提到。如何保证文档的全面性，使其真正为项目的进度提供保证，又不因为文档的写作而耽误项目的进度，这仍然是一个比较难解决的问题。解决此问题，其核心仍然是个"度"的问题。在本项目的开发中，文档组的一个非常重要的任务还是书写文档规范和文档模板。当有文档模板后需要书写文档的人员只剩下"填空"的工作，从某种意义上讲，书写文档的速度会加快。如果书写文档的人员认为文档的更细致的部分可以由他人帮助完成，则该文档即交由他人完成，但此时文档并不算被正式提交，当他人书写完毕之后，必须由文档的初写者进行复审，复审通过后方可以正式提交，进入软件配置管理的循环中。
文档组真正核心的工作是对文档的组织管理。根据文档的不同，文档的来源也不同，有些是通过质量监督组经过复审之后转交给文档组，有些则会直接从文档的出处到达文档组。文档的管理是一个非常烦琐的工作，但是长远来看它不仅使项目的开发对单个主要人员的依赖减少，从而减少人员流动给项目的带来的风险，更重要的是在项目进行到后百分之十的时候起到拉动项目的作用。从以往做大项目的经验来看，写作文档在项目开发的早期可能会使项目的进度比起不写文档要稍慢，但随着项目的进展，各个部门需要配合越来越多，开发者越来越需要知道其他人员的开发思路和开发过程，才能使自己的开发向前推进。一个明显的例子就是系统整合，或者某些环节是建立在其他环节完成的基础之上时，就更显现出文档交流的准确性和高效性。
系统维护保证
对于该项目，软件维护主要由公司的技术支持部来完成。技术支持在本公司的角色在第一章中已经有所描述。在这里需要重申的是，在本公司，技术支持的任务一方面是保证对项目客户的跟踪服务，另一方面是把该项目的开发人员从项目中尽快的解脱出来以便投入到下一个项目的开发中，因此要求技术支持人员在项目开始的时候就介入其中，并在开发的过程中不断跟踪项目，特别是开发中同客户的交流，他们必须参加。不仅如此，软件的代码编写，他们也需要有所了解，并对非核心代码能够进行一定的修改，最起码能够准确定位错误，以便提请公司以最快的速度修正错误。对于一般性的错误，如操作不当等引起的问题，全部由技术支持部来解决。
技术支持部的人员基本上是按项目跟进的。当一个项目刚刚交付用户时，在技术支持部会有较多的人员进行跟进，随软件的稳定，跟进的人逐步减少，并转移到其它项目中去。
