《4-1.管理信息系统分析-案例2》由会员分享，可在线阅读，更多相关《4-1.管理信息系统分析-案例2（19页珍藏版）》请在金锄头文库上搜索。
1、第四 章 管理信息系统 的设计 第四 章 管理信息系统 的设计案例篇案例篇 TOPIC 什么是什么是WBS 回顾回顾 思考：第一阶段是什么?第一阶段做什么？ 第二阶段是什么?第二阶段做什么？ 系统规划系统是否可行？ 需求分析系统做什么？ 立项报告立项报告 立项建议书 立项调查报告 立项可行性分析报告 立项评审报告 立项报告立项报告案例案例 东方影都(见案例1) 东方影都开发策划 东方影都项目立项书 风险管理风险管理 风险检查表 风险管理报告 (见案例2) 风险管理风险管理-案例案例 项目:对现有的一个Web应用程序进行改造 背景:客户写了一份简单的需求说明，希望能在 12/25圣诞节之前投入使
2、用。 对策:根据这份需求说明，整理出了一份功能列 表，然后估算每个功能的代码规模.为了赶工 期，我们省略了概要设计和大部分的详细设计， 直接进入编码阶段。一部分用户需求还未确定， 只好先进行确定部分的编码工作，将那些迟迟没 有定论的需求放在beta版发布之后。 风险管理风险管理-案例案例(续续) 过程: 前期克服困难,如期发布了beta版 中期- 接下来的一个月中，未确定的需求和不 断发现的bug成了灾难。项目从原定的1/25推迟 到2/8，再推迟到2/16。而这时开发团队也由原 来的两个人增加到五个人，增加的三个人专职测 试。 后期-最后终于发布了，结果发布当天就因为一 个小bug导致数十个
3、用户数据被误删。于是暂停 服务继续修改，改为封闭式开发，并且继续增加 测试队伍到10个人，这样整个团队就有12个人 在工作。持续到二月底，项目总算正常发布了 风险管理风险管理-案例案例(续续) 实际情况:实际的工时约为预计的3倍。 为什么这个项目会失败？ 忽视项目风险。 对风险未采取相应对策。 人月神话。 盲目编程，跳过概要设计和详细设计，直接进行 编码。 风险管理风险管理-案例案例(续续) 忽视项目风险 风险 影响(人月) 发生的可能性 实际影响(人月) 未确定的需求 1 100% 1 原有框架的缺陷造成的实现困难 0.5 20% 0.1 开发环境不完善 0.2 50% 0.1 新的bug管
4、理系统造成的学习困难 0.2 50% 0.1 发布后的bug 1 50% 0.5 总计 1.7 风险管理风险管理-案例案例(续续) 对风险未采取相应对策 风险 对策 未确定的需求 严格控制流程，在详细设计未完 成之前禁止编码 原有框架的缺陷造成的实现困难 及早联系框架 开发者调整 开发环境不完善 尽早使用较为完善的开发环境 发布后的bug 发布版 风险管理风险管理-案例案例(续续) 人月神话 增加开发者并不能加快开发进程。 -人月神话 1) 从其他项目组临时借调过来的人员，完全不 熟悉项目，加上不完善的测试用例，导致他们无 法正确理解测试用例的意图。 2) 通常编码过程中的人月效应都能引起大家
5、的 重视，但实际上测试阶段也存在人月效应，它的 影响并不比编码时小多少。 并不是说不能加人， 加人时也要加有经验的开发者 风险管理风险管理-案例案例(续续) 盲目编程 随着项目的进行，修改一个bug所花费的时间 会呈指数增加。也就是说，一个本应在详细设计 阶段发现的bug，推迟到单元测试阶段修改，所 花时间将是详细设计阶段修改的几十倍；如果推 迟到正式部署之后再修改，所花费时间将是详细 设计阶段修改的上万倍。 因此，跳过概要设计和详细设 计，相当于增加了修改bug的时 间，扩大了项目风险。 风险管理风险管理-案例案例(续续) 结论 质量管理、进度管理、风险管理质量管理、进度管理、风险管理 通常
6、大家都会注意到前两者，而风险管理则鲜 有人知，为什么？因为风险是有概率的，不像质 量和进度那么实在，而这种不确定性使得它很容 易因为开发者的自负和自我膨胀心理而被忽略。 因此无论项目有多么紧急，请务必脚踏实地地分 析项目风险，不要抱有侥幸心理。 项目规划项目规划 项目估计表 项目计划 项目计划变更控制报告 项目规划项目规划案例案例 项目计划的制定是否困难? 见案例3 需求管理需求管理 需求跟踪报告 需求变更控制报告 需求分析途径需求分析途径 o 研究资料方法 o 问卷调查法 o 用户访谈(用户访谈记录表) o 实地观察法 需求分析文档案例需求分析文档案例 见案例4: DD省XX银行XX支行实时扣税项目需求书
