软件工程的风险管理
有关软件工程的开发当中，注重开发技术的同时也需要看重其中的风险，今天对有关的风险做一个小小的总结，也是因为有关论文需要写一篇这个东西。
工程类项目风险的管理：
1.风险的识别：风险的识别主要是对整个开发项目的已知可能的风险的认知，识别哪些风险的来源及产生的条件，然后识别其有可能影响本项目的风险特征
2.风险的预测：风险的预测需要对开发项目中的可能发生的风险进行统计和计算，通过数据、概率、经验去预测可能会发生的风险及概率，及影响项目的程度。
3.风险的评估：对其风险进行评估导致的结果是什么，为降底风险导致项目负面效应的一个讨论过程，风险应对的计划依据风险管理计划、风险排序、风险认知等依据，得出风险应对计划、剩余风险、次要风险以及为其它过程提供得依据。
4.风险的控制：整个项目开发过程中，管理层可以对其某些因素进行控制及通过评估的风险应对措施、管理方法、技术手段等对项目的风险进行有效管控，降底其风险导致的不良结果，妥善处理风险事件造成的不利后果，以最少的成本保证项目总体目标实现的管理工作。
关于各种软件开发模式的风险管理的方法：
PMI(Project Management Institute):
- 规划风险管理：定义如何实施项目风险管理活动的过程；
- 识别风险：判断哪些风险会影响项目并记录其特征的过程；
- 实施定性风险分析：评估并综合分析风险的发生概率和影响，对风险进行优先排序，从而为后续分析或行动提供基础的过程；
- 实施风险定量分析：就已识别风险对项目整体目标的影响进行定量分析的过程；
- 规划风险应对：针对项目目标，制定提高机会，降低威胁的方案和措施的过程；
- 监控风险：在整个项目中，实施风险应对计划，跟踪已识别的风险，监测残余风险，识别新风险和评估风险过程有效性的过程；
WWPMM(IBM全球项目管理方法):
- 风险识别：查找和定位风险；
- 风险分析：将风险相关的数据转换为可以提供决策支持的信息；
- 风险反应计划：根据风险相关信息制定可执行计划或行动；
- 风险跟踪和控制：监控风险指示器并采取相关行动；
- 风险反应：风险发生的时候采取对应的风险应对行为；
MSF(Microsoft Solutions Framework):
CMMI(Capability Maturity Model Integration):
软件项目中的风险
软件项目的风险无非体现在以下四个方面：需求、技术、成本和进度。IＴ项目开发中常见的风险有如下几类：
（1）需求风险
1.需求已经成为项目基准，但需求还在继续变化；
2.需求定义欠佳，而进一步的定义会扩展项目范畴；
3.产品定义含混的部分比预期需要更多的时间；
4.在做需求中客户参与不够；
5.缺少有效的需求变化管理过程。
（2）计划编制风险
1.计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致；
2.计划是优化的，是"最佳状态"，但计划不现实，只能算是"期望状态"；
3.计划基于使用特定的小组成员，而那个特定的小组成员其实指望不上；
4.产品规模(代码行数、功能点、与前一产品规模的百分比)比估计的要大；
5.完成目标日期提前，但没有相应地调整产品范围或可用资源；
6.涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。
（3）组织和管理风险
1.仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长；
2.低效的项目组结构降低生产率；
3.管理层审查 决策的周期比预期的时间长；
4.预算削减，打乱项目计划；
5.管理层作出了打击项目组织积极性的决定；
6.缺乏必要的规范，导致工作失误与重复工作；
7.非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。
（4）人员风险
1.作为先决条件的任务(如培训及其他项目)不能按时完成；
2.开发人员和管理层之间关系不佳，导致决策缓慢，影响全局；
3.缺乏激励措施，士气低下，降低了生产能力；
4.某些人员需要更多的时间适应还不熟悉的软件工具和环境；
5.项目后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低；
6.由于项目组成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作；
7.不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性；
8.没有找到项目急需的具有特定技能的人。
（5）开发环境风险
1.设施未及时到位；
2.设施虽到位，但不配套，如没有电话、网线、办公用品等；
3.设施拥挤、杂乱或者破损；
4.开发工具未及时到位；
5.开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工具；
6.新的开发工具的学习期比预期的长，内容繁多。
（6）客户风险
1.客户对于最后交付的产品不满意，要求重新设计和重做；
2.客户的意见未被采纳，造成产品最终无法满足用户要求，因而必须重做；
3.客户对规划、原型和规格的审核 决策周期比预期的要长；
4.客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更；
5.客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长；
6.客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作。
（7）产品风险
1.矫正质量低下的不可接受的产品，需要比预期更多的测试、设计和实现工作；
2.开发额外的不需要的功能(镀金)，延长了计划进度；
3.严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作；
4.要求与其他系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作；
5.在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题；
6.开发一种全新的模块将比预期花费更长的时间；
7.依赖正在开发中的技术将延长计划进度。
（8）设计和实现风险
1.设计质量低下，导致重复设计；
2.一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发新的功能；
3.代码和库质量低下，导致需要进行额外的测试，修正错误，或重新制作；
4.过高估计了增强型工具对计划进度的节省量；
5.分别开发的模块无法有效集成，需要重新设计或制作。
（9）过程风险
1.大量的纸面工作导致进程比预期的慢；
2.前期的质量保证行为不真实，导致后期的重复工作；
3.太不正规(缺乏对软件开发策略和标准的遵循)，导致沟通不足，质量欠佳，甚至需重新开发；
4.过于正规(教条地坚持软件开发策略和标准)，导致过多耗时于无用的工作；
5.向管理层撰写进程报告占用开发人员的时间比预期的多；
6.风险管理粗心，导致未能发现重大的项目风险。