软件工程的风险管理

有关软件工程的开发当中，注重开发技术的同时也需要看重其中的风险，今天对有关的风险做一个小小的总结，也是因为有关论文需要写一篇这个东西。
工程类项目风险的管理：
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.风险管理大意，导致未能发现严重的项目风险。