一、实验内容、要求
对高校教务管理信息系统开发过程中出现风险进行识别分析和解决。
通过对高校教务管理信息系统过程中产生的风险进行风险管理，使得学生能够了解风险管理的必要性，体验实际的开发中怎样识别风险、分析风险、控制风险以及风险发生后来解决风险。
学生根据所学知识，运用常用风险识别方法及以往的开发经验可以识别出开发一个信息管理系统时出现的常见风险并制定相应的缓解计划和应急计划。
实验任务：
任务1：根据SEI风险分类、SWOT、信息收集等方法识别项目中存在的至少5个风险
任务2：对风险进行分析，评估其发生的可能性（P）与影响程度（I）
任务3：制定风险应对计划
任务4：制定风险应急计划
任务5：风险追踪
使用以下模板记录识别的风险并对其进行追踪
| 风险ID |
风险类别 |
风险状态 |
||||
| 识别时间 |
可能性（P） |
影响程度（I） |
||||
| 风险强度（RE） |
优先级 |
|||||
| 风险描述 |
||||||
| 规避/减缓计划 |
时间 |
人员 |
负责人 |
|||
| 内容 |
||||||
| 执行情况 |
||||||
| 应急计划 |
触发条件 |
人员 |
负责人 |
|||
| 内容 |
||||||
| 执行情况 |
||||||
二、实验方法
（风险识别方法简介）
- 文档评审：对软件项目的计划、方案等文档和每个项目阶段的工作过程及其成果进行评审，可识别出项目的许多风险。
- 挣值分析：将计划的工作与已完成的工作进行比较，确定项目是否符合计划的费用和进度要求，如果偏差较大，则需要进一步进行项目的风险识别、评估和量化。
- 环境分析：对项目的环境（包括客户、竞争者、合作者、政府管理者等）进行分析，从而识别出项目风险，并重点考虑它们相互联系的特征和稳定性。
- 情景分析：通过有关数据和图表等，对项目未来的某个状态或某种情况进行详细的描绘和分析，从而识别引起项目风险的关键因素及风险的影响程度。它注重说明某些事件引发风险的条件和因素，并且还要说明当某些因素发生变化时，又会出现什么样的风险，会产生什么样的后果。
- 面谈：与软件项目的团队成员、有经验的项目干系人、有关专家和有类似项目经验的人进行有关风险的面谈，将有助于识别那些在常规方法中未被识别的风险。
三、实验结果
（风险登记册）
| 风险ID |
01 |
风险类别 |
产品规模 |
风险状态 |
Issue |
|
| 识别时间 |
5/04 |
可能性（P） |
60% |
影响程度（I） |
5 |
|
| 风险强度（RE） |
较高 |
优先级 |
1 |
|||
| 风险描述 |
产品初定在线活跃人数5000人，但是在教务系统的进行短时间内容发布并要求资源下载的时候，在线活跃人数超越5000人 |
|||||
| 规避/减缓计划 |
时间 |
5/04 |
人员 |
项目开发人员 |
负责人 |
项目开发负责人 |
| 内容 |
采用大型服务器 |
|||||
| 执行情况 |
有效能缓冲多人同时在线的情况 |
|||||
| 应急计划 |
触发条件 |
在线用户超过5000人 |
人员 |
项目开发人员 |
负责人 |
项目开发负责人 |
| 内容 |
追加服务器资源 |
|||||
| 执行情况 |
短暂时间后，恢复系统运行，支持超过5000人同时在线 |
|||||
| 风险ID |
02 |
风险类别 |
需求不明确 |
风险状态 |
Active |
|
| 识别时间 |
5/7 |
可能性（P） |
80% |
影响程度（I） |
5 |
|
| 风险强度（RE） |
高 |
优先级 |
2 |
|||
| 风险描述 |
需求要求未细化，需求描述不清楚，需求考虑不周全 |
|||||
| 规避/减缓计划 |
时间 |
5/7 |
人员 |
项目经理、需求分析人员 |
负责人 |
项目经理 |
| 内容 |
1、写出详细的需求文档 2、开发原型图 |
|||||
| 执行情况 |
有效，需求已经较为明确，将风险可能性改为“低”，优先级为“低” |
|||||
| 应急计划 |
触发条件 |
开发人员或用户质疑需求相关内容的实用性和可行性 |
人员 |
项目经理、需求分析人员 |
负责人 |
项目经理 |
| 内容 |
召开需求讨论会 |
|||||
| 执行情况 |
短时间内讨论出处理办法和内容调整，有效处理。 |
|||||
| 风险ID |
03 |
风险类别 |
人员数目及经验 |
风险状态 |
Active |
|
| 识别时间 |
5/10 |
可能性（P） |
60% |
影响程度（I） |
4 |
|
| 风险强度（RE） |
一般 |
优先级 |
3 |
|||
| 风险描述 |
开发过程中项目成员可敬会提出离职，导致部分工作无法继续 |
|||||
| 规避/减缓计划 |
时间 |
5/11 |
人员 |
项目开发人员 |
负责人 |
项目开发负责人 |
| 内容 |
|
|||||
| 执行情况 |
能及时规避人员流动风险，项目影响程度降为3 |
|||||
| 应急计划 |
触发条件 |
大量人同时离职 |
人员 |
项目开发人员 |
负责人 |
项目开发负责人 |
| 内容 |
后备人才的培养，最好形成一个梯队，前面的人员离职之后，梯队后面的人能顶上来。 核心功能的开发，可以分解成多个部分，分配给不同的开发人员来开发，不要集中在某个人身上。 |
|||||
| 执行情况 |
有效处理人员流动，保证项目的顺利进行 |
|||||
| 风险ID |
04 |
风险类别 |
技术情况 |
风险状态 |
Issue |
|
| 识别时间 |
5/12 |
可能性（P） |
60% |
影响程度（I） |
2 |
|
| 风险强度（RE） |
较高 |
优先级 |
4 |
|||
| 风险描述 |
采用新技术，可能制造未知的bug，从而降低软件的可用性，给你制造未知的bug，从而降低软件的可用性 |
|||||
| 规避/减缓计划 |
时间 |
5/13 |
人员 |
项目开发人员 |
负责人 |
项目开发负责人 |
| 内容 |
|
|||||
| 执行情况 |
有效能缓冲多人同时在线的情况 |
|||||
| 应急计划 |
触发条件 |
新技术导致进度延期 |
人员 |
项目开发人员 |
负责人 |
项目开发负责人 |
| 内容 |
|
|||||
| 执行情况 |
开发效果太差但能满足项目需求 |
|||||
| 风险ID |
05 |
风险类别 |
人员数目及经验 |
风险状态 |
Issue |
|
| 识别时间 |
5/13 |
可能性（P） |
60% |
影响程度（I） |
4 |
|
| 风险强度（RE） |
弱 |
优先级 |
3 |
|||
| 风险描述 |
对需求的开发或系统标准没有合适的测试案例 |
|||||
| 规避/减缓计划 |
时间 |
5/17 |
人员 |
项目测试人员 |
负责人 |
项目测试负责人 |
| 内容 |
|
|||||
| 执行情况 |
能够测试大部分的功能以及bug检测 |
|||||
| 应急计划 |
触发条件 |
测试无法实现全覆盖，不定时出现各类bug |
人员 |
项目测试人员 |
负责人 |
项目测试负责人 |
| 内容 |
找专业的测试公司进行测试 |
|||||
| 执行情况 |
使得项目测试更具有针对性，测试更全面 |
|||||
四、实验心得
通过本次实验，我了解到不同的风险分析方式，对于风险识别方法可以通过文档评审、挣值分析、情景分析、面谈等方式，风险评估时进行风险发生概率的估计和评价，并对风险后果的严重程度进行评价，对于风险概率和影响程度的评估，我们可以组织包括软件项目团队成员、项目干系人和项目外部的专业人士等在内的人员，采用召开会议或进行访谈等方式，对风险发生概率和影响程度进行分析。同时可以采取洁决策树分析法进行图形化的概率分析也可采取SWOT方式进行预测，蒙特卡洛模拟法最常用。