常用风险和相应对策
|
序号 |
软件风险 |
相应对策 |
|
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． 采用最优连接使用计划。 |
