RMMM计划.doc
《RMMM计划.doc》由会员分享，可在线阅读，更多相关《RMMM计划.doc（6页珍藏版）》请在冰点文库上搜索。
RMMM计划
项目名称:
图书管理系统
编写者：
“精锐联盟”开发小组
编写日期：
2012年5月28日
审核者：
审核日期：
年月日
批准者：
批准日期：
年月日
开发小组成员:
1.引言
1.1文档的范围和目的
本文档的适用范围是信息技术工程学院。
本文档目的是为了更好的规划此系统，缩小项目风险，使系统更加符合现代图书馆系统的要求。
本文档的适用范围是软件项目管理分组中的本小组所有人员。
也作为今后从事此系统开发及维护人员的技术参考资料。
1.2主要风险综述
a.管理风险
（1）项目范围定义不清楚
（2）进度拖延
（3）沟通不善
b.技术风险
（1）数据加密技术不够安全
（2）数据库过小不能及时交付
（3）防止黑客攻击技术不够
（4）设计错误编码导致程序实现困难
（5）缺少测试计划
c.开发环境风险
（1）所使用开发软件的质量问题
（2）设计工具不合用
（3）设备不能按时到位
（4）系统崩溃
（5）备份环境不稳定
1.3责任
一般参与软件开发的人员（包括管理者和技术人员）和其责任进行分析如下：
a.项目负责人:
主要职责：
制定项目开发计划和开发策略，参与项目核心系统的分析设计，同时努力保证开发计划的按时完成和开发策略的真正贯彻落实。
b.程序员:
主要职责：
协助分析人员进行详细设计，和软件系统的代码实现，并进行适当的测试。
c.测试员:
主要职责：
已经实现的软件组件、构件或系统进行正确性验证测试，整合后的系统的性能测试等。
书写测试报告和测试统计报告提请质量监督组复审。
2.项目风险表
风险
类别
概率
影响
RMMM
规模估算可能非常低
PS
60%
2
用户数量大大超出计划
PS
30
3
使用程度低于计划
PS
70
2
最终用户抵制该系统
BU
40
3
交付期限将被紧缩
BU
50
2
资金将会流失
CU
40
1
用户将改变需求
PS
80
2
技术达不到预期的效果
TE
30
1
缺少对工具的培训
DE
80
3
人员缺乏经验
ST
30
2
人员流动比较频繁
ST
60
2
类别：
PS---------产品规模风险
PD---------过程定义风险
ST----------人员与经验风险
CU---------客户特征风险
DE----------开发环境风险
TE----------技术风险
BU----------商业风险
影响值：
1-----------灾难的
2-----------严重的
3-----------轻微的
4-----------可忽略的
2.1中止线以上风险描述
规模估算可能非常低:
定量估算软件规模的方法不准确，从而导致对软件规模估计产生偏差
用户数量大大超出计划:
在做需求分析时，未能准确把握使用该系统的用户数量，导致树勇数量超出系统最大承载数
使用程度低于计划:
项目执行过程中，未能与客户及时沟通，导致系统功能不完善，未能完全满足用户的要求
最终用户抵制该系统:
完成后的系统与预期相比相差太大，不符合用户的要求，无法完成相应功能
2.2影响概率及影响的因素
（1）需制定的规范和标准较多，而同时需完成其他工作，使得可使用的时间和资源有限
（2）由于设备未到位导致延误开发
（3）由于都是全新的课题，对于技术的掌握程度和经验仍很欠缺
（4）由于学习曲线过长延误时间
（5）测评结果对功能规格和系统设计影响较大
3.风险缓解、监控和管理
3.1规模估算可能非常低
a.缓解
（1）一般策略
使用合理的定量估算软件规模的方法，并用多种估算方法进行计算，以避免出错。
（2）缓解风险的特定步骤
用其他估算方法重新计算软件的规模，调整项目的实施计划。
b.监控
（1）被监控的因素
软件规模估算的值。
（2）监控方法
进行估算的软件规模大小是否与实际相符合。
c.管理
（1）意外事件计划
对于意外事件，由项目负责人重新进行估算，并修改项目计划。
（2）特殊的考虑
对于软件规模的估算值，项目负责人亲自参与，验证结果是否准确。
3.2用户数量大大超出计划
a.缓解
（1）一般策略
在需求分析阶段，与客户充分沟通，并对涉及的用户数量作足够的估计。
（2）缓解风险的特定步骤
在项目实施阶段，提高软件所能的承受的最大用户数量。
b.监控
（1）被监控的因素
客户提出的用户数量和软件的最大承载数。
（2）监控方法
经常与客户交流，及时了解软件所要达到的最大用户数。
c.管理
（1）意外事件计划
与客户交流之后，发现用户数量大于软件所能承受的最大数量，由项目负责人与客户进行协商，重新作需求分析或者是修改交付产品的日期。
（2）特殊的考虑
在项目进行到中后期，对客户提出的新需求，进行临时程序修改，如果不可修改，告知客户在下一个版本解决。
3.3交付期限将被紧缩
a.缓解
（1）一般策略
每天召开开发小组的晨会，总结前一天的工作，并对当天的工作作出安排。
（2）缓解风险的特定步骤
在项目的关键阶段设置里程碑，并确定完成时间。
在作计划时，预留机动时间。
b.监控
（1）被监控的因素
计划要求的所形成文档的时间。
（2）监控方法
每天的开发进度是否按照计划进行。
c.管理
（1）意外事件计划
对于意外事件，由项目负责人重新制定项目开发计划。
（2）特殊的考虑
在项目的关键阶段设置里程碑，并确定完成时间。
在作计划时，预留机动时间。
4.RMMM计划迭代时间安排
该计划只作为项目计划初期使用，在开发阶段的需求分析，总体设计，详细设计和编码阶段均需要进行根据具体开发中存在的概率进行迭代修改。
在开发中可能由于估计不足产生新的的风险条目，可利用附表风险记录报告增加新的风险评估，修改风险计划。
5.总结
软件项目风险管理是一种特殊的规划方式，当对软件项目有较高的期望值时，一般都要进行风险分析。
进行过大中型项目开发的人都亲身体验到许多事情可能出错，最成功的项目就是采取积极的步骤对要发生或即将发生的风险进行管理。
对任何一个软件项目，可以有最佳的期望值，但更应该要有最坏的准备，“最坏的准备”在项目管理中就是进行项目的风险分析。
升级会员 