常用风险和相应对策

                                        10 种常用风险和相应对策

序号	软件风险	相应对策
1	人员不足	1． 录用优秀人才。 2． 人员应适用岗位工作。 3． 全面考虑团队建设。 4． 实施培训。 5． 预先安排关键人员的使用计划。
2	进度计划和预算不准	1． 详细评估多种资源成本和进度。 2． 依成本进行设计。 3． 采用渐增是开发。 4． 软件复用。 5． 纯净需求。
3	开发了错误的软件功能	1． 进行组织分析。 2． 实施任务分析。 3． 进行用户调查。 4． 开发原型。 5． 及早编制用户手册。
4	开发了不适用的用户接口	1． 开发原型。 2． 制作脚本。 3． 作业分析。 4． 弄清用户特征（功能型、风格、工作负荷）。
5	只追求表面效果，需求中含有一些不必要的功能（镀金）	1． 纯净需求。 2． 开发原型。 3． 成本-效益分析。 4． 依成本进行设计。
6	需求不断变更	1． 重大变更受限。 2． 信息隐蔽 3． 渐近式开发。
7	外供部条件不足	1． 制定基准点。 2． 检验。 3． 参考基准检查。 4． 兼容性分析。
8	外包任务问题	1． 参考基准检查。 2． 发包前审核。 3． 未发包合同。 4． 竞标设计或开发原型。 5． 建立团队。
9	实时性能达不到要求	1． 模拟。 2． 制定基准。 3． 建模。 4． 开发原型。 5． 安装测量装置。 6． 调准。
10	误解计算机科学能力	1． 技术分析。 2． 成本-效益分析。 3． 开发原型。 4． 参考基准检查。

 

序号	风险类型	化解措施
1	受过技术培训的人员不足	1． 在初期学习的短时间内及早做出估计。 2． 保留额外的资源储备。 3． 制定针对具体项目的培训大纲。 4． 开展互交互学活动。
2	过多的需求变更	1． 让客户在最初的需求规格说明上签字。 2． 让客户理解需求的变更将会影响项目进度。 3． 制定需求变更规程。 4． 按实际开发工作量计算开发费。
3	需求不明确	1． 根据实践经验和常规逻辑提出设想，征得客户同意，并签字承诺。 2． 开发原型或吸收客户参与需求评审。
4	人员流失	1． 确保项目的关键部位拥有多种人力资源。 2． 开展团队建设工作专题研讨。 3． 团队人员间进行工作轮换。 4． 保持项目的人力资源应有备用。 5． 保存员工个人工作的专门文件。 6． 严格遵循配置管理过程和制定的相关导则。
5	外部因素对项目决策的影响	1． 对事实或数据向与决策相关的人员说明并商讨不利条件。 2． 如果实属不可避免，就应识别实际风险，并遵循风险化解计划。
6	性能需求达不到需求	1． 制定明确的性能准则，请客户评审。 2． 制定应遵循的标准以满足性能准则。 3． 要求设计满足性能准则并对其进行评审。 4． 对关键的业务处理进行性能模拟和原型开发。 5． 若可能使用有代表性的数据进行批量测试。 6． 若可能实施强度测试。
7	进度计划不切实际	1． 商讨制定更为合理的项目进度。 2． 找出可并行开展的工作。 3． 尽早使资源准备就绪。 4． 识别可自动化进行的工作部分。 5． 如果关键路径超出计划进度，应与客户协商。 6． 商谈按实际投入工作量付开发费。
8	面临新技术的挑战	1． 考虑分阶段交付。 2． 从关键模块开始交付。 3． 在制定计划时考虑学习和掌握新技术所需的时间。 4． 针对新技术组织培训。 5． 开发证明概念的应用课题。
9	商业知识不足	1． 坚强和客户交流，从中获得商业知识。 2． 组织应用领域知识方面的培训。 3． 对客户的业务进行模拟开发或开发原型，并取得客户的认可。
10	连接故障或性能迟钝	1． 请客户提供适当的期望值。 2． 在连接装载前制定计划。 3． 采用最优连接使用计划。

转载于:https://www.cnblogs.com/etian/archive/2008/02/16/1070697.html