文档介绍：: .
开发过程是在软件项目的开发完成才能明了的。因此项目开发之初只
能根据项目的特点和开发经验进行选择，并在开发过程中不断的调整。
大型软件项目往往是"一次性"的。以往的经验可以被借鉴的地方不多。回避
和控制软件管理风险的唯一办法就是设立监督制度，项目开发中任何较大的决定都必须有主要技术环节甚至是由用户参与进行的。在该项目中项目监督由项目开
发中的质量监督组来实施。
一般参与软件开发的人员（包括管理者和技术人员）和其责任进行分析如下：
参与者
项目经理 1 人
主要职责：进行全局把握，侧重于项目的商务方面，充当项目组同客户正式交流
的接口环节。
项目负责人 1 人
主要职责：制定项目开发计划和开发策略，参与项目核心系统的分析设计，同时
努力保证开发计划的按时完成和开发策略的真正贯彻落实。
领域专家 1 或 2 人
主要职责：在软件分析阶段帮助分析人员界定系统实现边界和实现的功能，对特
定检测点进行算法审核，同时对测试策略和软件操作界面提出参考意见。
质量监督组 1 或 2 人
主要职责：编制软件质量控制计划，并负责落实；控制必要文档的生产，通过文
档，监督项目实施过程中软件的质量，并产生软件质量报告，提请项目经理和项
目负责人审阅；对于项目中出现的质量问题，主持召开质量复审会议。
系统分析员 1 或 2 人
主要职责：协同项目负责人进行软件系统的分析和设计工作，书写软件需求分析
和系统设计相关文档。在软件实现阶段进行测试策略的编制和对性能测试的指导。
程序员 2 或 3 人
主要职责：协助分析人员进行详细设计，和软件系统的代码实现，并进行适当的白盒测试。
测试员 2 或 3 人
主要职责：已经实现的软件组件、构件或系统进行正确性验证测试，整合后的系
统的性能测试等。书写测试报告和测试统计报告提请质量监督组复审。
技术支持 2 或 3 人
主要职责：协同系统分析人员听取用户需求，对需求分析进行参考性复审。协同
测试人员进行测试，书写操作手册和在线帮助，在项目交付用户之后进行跟踪服
务。
文档组 1 或 2 人
主要职责：对各部门产生的文档进行格式规范、版本编号和控制、存档文件的检
索；协助质量监督组进行软件质量监督。通过适当的人员配备和职责划分，能有
效的降低软件开发在后期的失控的可能性，和软件对关键人员的依赖性。
软件技术风险
本系统拟订采用的两个重大的软件技术是面向对象的构件和基于微软的
COM 组件技术。组件和构件技术都是为了提高软件的可靠性和软件的可扩展性
而采用的技术手段。从技术成熟度上说不存在风险，但为了实现良好的软件构架
和稳定的组件，与传统开发方法比较，有相当的多的额外工作需要做，这会给项
目工期带来较大的风险。
回避和控制这部分风险的办法是在项目进行的过程不断的对该阶段进行风
险估计和指定有效的里程碑。同时采用"范例"方式提高开发人员的构件组件的分
析识别能力，适时调整构件组件的数量和粒度。软件过程风险
软件需求阶段的风险
软件的开发是以用户的需求开始，在大多数情况下，用户需求要靠软件开发
方诱导才能保证需求的完整，再以书面的形式形成《用户需求》这一重要的文档。
需求分析更多的是开发方确认需求的可行性和一致性的过程，在此阶段需要和用
户进行广泛的交流和确认。需求和需求分析的任何疏漏造成的损失会在软件系统
的后续阶段被一级一级地放大，因此本阶段的风险最大。
设计阶段的风险
设计的主要目的在于软件的功能正确的反映了需求。可见需求的不完整和对
需求分析的不完整和错误，在设计阶段被成倍地放大。设计阶段的主要任务是完
成系统体系结构的定义，使之能够完成需求阶段的即定目标；另一方面也是检验
需求的一致性和需求分析的完整性和正确性。
设计本身的风险主要来自于系统分析人员。分析人员在设计系统结构时过于
定制，系统的可扩展性较弱，会给后期维护带来巨大的负担，和维护成本的激增。
对用户来说系统的使用比例会有明显的折扣，甚至造成软件寿命过短。反之，软
件结构的过于灵活和通