实施阶段
在这个阶段进行大部分编码和测试，也涉及少部分设计（大部分实施及测试，部分部署），如：设计变更或补充设计。
可能的风险事件
l 开发环境没有具备好
l 设计错误带来的实施困难
l 程序员开发能力差，或程序员对开发工具不熟
l 项目范围改变（突然要增加或修改一些功能，需要重新考虑设计）
l 项目进度改变（要求提前完成任务等）
l 人员离开，在一个项目内软件开发工作有一定的连续性，需要移交和交接，有时人员离开对项目的影响会很大
l 开发团队内部沟通不够，导致程序员对系统设计的理解上有偏差
l 没有有效的备份方案
l 没有切实可行的测试计划
l 测试人员经验不足
收尾阶段
在这个阶段进行安装及维护（大部分部署）。
可能的风险事件
l 质量差
l 客户不满意项目管理培训
l 设备没有按时到货
l 资金不能回收
以上只是例具了常见的风险事件，对不同项目可能发生的风险事件不同，应该对具体项目识别出真正有可能发生在该项目的风险事件。而且还要对这些风险事件进行描述，如：可能性、可能后果范围、预计发生时间、发生频率等。
风险识别的有效方法有很多，如：建立风险项目检查表、因果分析图、采访各种项目干系人等。
软件项目的风险可以从以下几方面检查：
产品规模风险
业务影响风险检
与客户相关的风险
过程风险
技术风险
开发环境风险
与人员的模式和经验有关的风险
以上我们讨论了在软件项目各个阶段中可能发生的风险事件和识别方法。下面我们看看如何对这些风险事件进行分析。
3．风险分析
风险分析就是对以上识别出来的风险事件做风险影响分析。
和风险相关的有四个因素：
风险事件，破坏或影响项目的事件
风险概率（%），事件发生的可能性
风险得失量（金额），说明可能造成的损失
风险影响（金额），等于 风险概率 × 风险得失量
通过对风险及风险的相互作用的估算来评价项目可能结果的范围，从成本、进度及性能三个方面对风险进行评价，确定哪些风险事件或来源可以避免，哪些可以忽略不考虑（包括可以承受），哪些要采取应对措施。
4．风险应对
1、应对方法
项目中的风险永远不能全部消除，PMBOK提到三种应对方法：
避免
通过分析找出来发生风险事件的原因，消除这些原因来避免一些特定的风险事件发生。
比如：
如何避免客户不满意？
客户不满意有两种情况，一种情况是没有判断客户满意度的依据，即没有双方互相认可的客户验收标准，还有一种是开发方没有达到验收标准，即没有满足用户需求。不管是哪一种，开发方都有不可推卸的责任，只要做好以下环节完全可以避免：
l 业务建模阶段要让客户参与
l 需求阶段要多和客户沟通，了解客户真正的需求
l 目标系统的模型或DEMO系统要向客户演示，并得到反馈意见，如果反馈的意见和DEMO系统出入比较大时，一定要将修改后的DEMO系统在次向客户演示，直到双方都达成共识为止
l 要有双方认可的验收方案和验收标准
l 做好变更控制和配置管理
减轻
通过降低风险事件发生的概率或得失量来减轻对项目的影响。也可以采用风险转移的方法来减轻风险对项目带来的影响。项目预算中考虑应急储备金是另一种降低风险影响的方法。
比如：
经过风险识别发现，项目组的程序员对所需开发技术不熟。可以采用熟悉的技术来减轻项目在成本或进度方面的影响。也可以事先进行培训来减轻对项目的影响。
接受
接收风险造成的后果。
比如：
为了避免自然灾害造成的后果，在一个大的软件项目中考虑了异地备份中心。
2、开发应对计划
针对需要采取应对措施的风险事件，开发应对计划，一旦发生风险事件，就实施应对计划。
比如：
有一个软件集成项目中包括了设备，而且计划在部署阶段之前设备必须到位，而这些设备从厂家直接进货。经过分析发现有可能不能按时进货，那就应该考虑备选方案，比如能不能周转等。
又比如：
在一个软件开发项目中，某开发人员有可能离职，离职后会对项目造成一定的影响，则应该对这个风险事件开发应对计划，过程可以参照如下：
l 进行调研，确定流动原因
l 在项目开始前，把缓解这些流动原因的工作列入风险管理计划
l 项目开始时，做好计划一旦人员离开时便可执行，以确保人员离开后项目仍能继续进行
l 制定文档标准，并建立一种机制，保证文档及时产生
l 对所有工作进行细微详审，使更多人能够按计划进度完成自己的工作
l 对每个关键性技术人员培养后备人员
在考虑风险成本之后，决定是否采用上述策略。
以上仅供大家参考，有什么不恰当的地方望大家多提出来。
