额外工作量。
出现概率：高
影响程度：中
处理建议：实施方要科学控制需求变更，通过项目组集体决策的方式确定变更，除了严重影响使用外，细节变更要批量修改，不要一事一改。
8、需求变更缺乏管理风险：业主缺少有效的需求变化管理。
出现概率：中
影响程度：中
处理建议：实施方协助业主加强对需求变更的管理，责任到人，签字确认。
9、文档管理风险：实施方缺乏有效的文档管理体系。
出现概率：高
影响程度：低
处理建议：应建立严格的文档管理制度，包含对错误的管理，建立完善的错误追踪管理系统。
10、需求变更缺乏分析风险：实施方对需求的变化缺少象原始需求一样的分析过程。
出现概率：高
影响程度：低
处理建议：实施管理者要对所有需求的变更与原始需求一样重视，要逐条进行详细分析，确定对原设计的影响，全面变更实施计划后再进行变更实施。
B、设计阶段
1、项目团队经验风险：实施方项目队伍缺乏经验，或缺乏有经验的核心技术人员。
出现概率：中
影响程度：高
处理建议：业主加强对开发团队的审核，包括团队合作、组成人员资质和经验等。
2、实施者自行变更风险：实施者根据自己的经验或考虑自身成本利益等原因在未得到业主允许的情况下私自变更需求或需求的实现方式。
出现概率：低
影响程度：中
处理建议：要明确约定实施者不得随意变更用户需求，如需变更需得到需求者认可方可实施。
3、计划风险：仓促计划，盲目制定工期，造成进度无法按计划控制。
出现概率：低
影响程度：中
处理建议：科学制定详细的开发计划，并经过共同论证后再严格实施。
4、漏项风险：由于设计人员的疏忽某个功能没有考虑进去。
出现概率：低
影响程度：中
处理建议：设计后需要多方复核，仔细对比需求说明书与设计说明书的各相关项。
C、实施阶段
1、开发环境风险：开发软件环境没有准备好或与实际环境不同，导致产品无法装载到运行环境。
出现概率：低
影响程度：低
处理建议：需要双方技术人员共同确认环境的一致性，要精确到产品的版本号及补丁情况。
2、整合风险：所实施的项目中涉及对旧有异构数据和系统的整合。
出现概率：中
影响程度：低
处理建议：在实施前应做充分调查，了解相关系统的所有技术细节，采用比较成熟和稳定的整合方案，并制定接口规范，规划时尽量减少新系统的异构。
3、布署风险：运行环境和产品开发环境差异，尤其是开发机器与服务器硬件配置差异等原因造成布署困难。
出现概率：低
影响程度：低
处理建议：尽量保证开发时使用与最终布署环境相同的硬件条件，如果布署环境硬件条件过高则应事先与厂商了解硬件相关特性，确保布署可能性。
4、设计风险：由于系统设计错误带来实施困难。
出现概率：低
影响程度：高
处理建议：系统设计方案完成后，需要业主方组织成立技术专家组共同确认设计方案，及时发现设计漏洞。
5、人员能力风险：程序员开发能力差，或程序员对开发工具不熟。
出现概率：高
影响程度：低
处理建议：所有的项目组成员要做预先业务能力审核，如遇更替人员也要进行相应的审核，确保人员具备足够的业务能力。
6、项目范围改变风险：已经开始实施后用户突然要增加或变更一些结构性的功能，需要重新考虑架构设计。
出现概率：低
影响程度：高
处理建议：架构设计尽量灵活，采用构件开发等方式增加应变能力，同时要加强前期的静态原型细度并将可能存在的问题及时提交给业主，避免实施过程中发生结构性修改。
7、项目进度改变风险：由于特殊事件或得到上级领导指示，业主方要求提前完