测试员2或3人
主要职责：已经实现的软件组件、构件或系统进行正确性验证测试，整合后的系统的性能测试等。书写测试报告和测试统计报告提请质量监督组复审。
技术支持2或3人
主要职责：协同系统分析人员听取用户需求，对需求分析进行参考性复审。协同测试人员进行测试，书写操作手册和在线帮助，在项目交付用户之后进行跟踪服务。
文档组1或2人
主要职责：对各部门产生的文档进行格式规范、版本编号和控制、存档文件的检索；协助质量监督组进行软件质量监督。 通过适当的人员配备和职责划分，能有效的降低软件开发在后期的失控的可能性，和软件对关键人员的依赖性。
软件技术风险
本系统拟订采用的两个重大的软件技术是面向对象的构件和基于微软的COM组件技术。组件和构件技术都是为了提高软件的可靠性和软件的可扩展性而采用的技术手段。从技术成熟度上说不存在风险，但为了实现良好的软件构架和稳定的组件，与传统开发方法比较，有相当的多的额外工作需要做，这会给项目工期带来较大的风险。
回避和控制这部分风险的办法是在项目进行的过程不断的对该阶段进行风险估计和指定有效的里程碑。同时采用“范例”方式提高开发人员的构件组件的分析识别能力，适时调整构件组件的数量和粒度。
软件过程风险
软件需求阶段的风险
软件的开发是以用户的需求开始，在大多数情况下，用户需求要靠软件开发方诱导才能保证需求的完整，再以书面的形式形成《用户需求》这一重要的文档。需求分析更多的是开发方确认需求的可行性和一致性的过程，在此阶段需要和用户进行广泛的交流和确认。需求和需求分析的任何疏漏造成的损失会在软件系统的后续阶段被一级一级地放大，因此本阶段的风险最大。
设计阶段的风险
设计的主要目的在于软件的功能正确的反映了需求。可见需求的不完整和对需求分析的不完整和错误，在设计阶段被成倍地放大。设计阶段的主要任务是完成系统体系结构的定义，使之能够完成需求阶段的即定目标；另一方面也是检验需求的一致性和需求分析的完整性和正确性。
设计本身的风险主要来自于系统分析人员。分析人员在设计系统结构时过于定制，系统的可扩展性较弱，会给后期维护带来巨大的负担，和维护成本的激增。对用户来说系统的使用比例会有明显的折扣，甚至造成软件寿命过短。反之，软件结构的过于灵活和通用，必然引起软件实现的难度增加，系统的复杂度会上升，这又会在实现和测试阶段带来风险，系统的稳定性也会受到影响。从另一个角度上看，业务规则的变化，或说用户需求和将来软件运行环境的变化都是必然的情况，目前软件设计的所谓“通用性”是否就能很好的适应将来需求和运行环境的的变化，是需要认真折衷的。这种折中也蕴涵着很大的风险。
设计阶段蕴涵的另一种风险来自于设计文档。文档的不健全不仅会造成实现阶段的困难，更会在后期的测试和维护造成灾难性的后果，例如根本无法对软件系统进行版本升级，甚至是发现的简单错误都无从更正。实现阶段引入的风险软件的实现从某种意义上讲是软件代码的生产。原代码本身也是文档的一部分，同时它又是将来运行于计算机系统之上的实体。源代码书写的规范性，可读性是该阶段的主要风险来源。规范的代码生产会把属于程序员自身个性风格的成分引入代码的比例降到最低限度，从而减小了系统整合的风险。
维护阶段的风险
软件维护包含两个主要的维护阶段，一个是软件生产完毕到软件试运行阶段的维护，这个阶段是一种实环境的测试性维护，其主要目的是发现在测试环境中不能或未发现的问题；另一个阶段是当软件的运行不再能适应用户业务需求或是用户的运行环境（包括硬件平台，软件环境等）时进行的
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
