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