数字化校园项目系统风险分析.docxVIP

数字化校园项目系统风险分析 依据项目管理的相关规定，结合我们在以往项目的成功和失败的经验，我们进行了细致的分析，提出了大学的风险管理与质量保证计划。 我们详细分析了整个开发过程，针对大学项目的要求，在半年的时间里实现校园网基础平台及业务系统的运行，在这个过程中会产生什么样的风险，并且阐述了我们是如何规避和应对这些风险的。同时介绍了我们以往的一些高校项目在执行过程中遇到的风险和问题，以及遇到问题后我们的应对措施。 需求阶段 一、学校用户难以界定产品功能范围，希望要一个在任何平台、任何情况下都适用的产品。“完美”是不存在的，导致双方不断确定、更改相应文档。 应对措施： 1）对用户进行软件需求的培训； 2）项目初期明确方向，界定范围； 3）使用原型开发； 4）给用户演示已结束的类似项目，获取用户需求。 二、随着用户对项目产品的不断了解（通过各种渠道），不断提出新的或者更加有难度的需求，造成频繁变更。 应对措施： 1）需求分析结果客户签字确认，如要更改已确认的需求，需双方进行联合评审，评估变更风险后方可实施； 2）设计采用松耦合设计，降低非预期变更带来的影响范围； 3）对于新需求，由双方沟通，采用非技术手段解决，或者留在以后版本处理； 三、开发中途变更产品的硬件环境要求，导致软、硬件接口出现问题。 应对措施： 1）对于硬件环境的变更必须及时评估对于设计的影响； 2）设计方案应有较大弹性，以适应硬件环境的变化。 设计阶段 一、阶段交付/迭代开发模型带来的风险 迭代法虽然能减少软件系统的后期维护费用，降低因需求不明确带来的项目风险，但是初期交付原型本身功能设置不齐全、 性能不好，会导致原型的设计和使用超出预期的花费和时间，并且使客户产生项目是否能够实现的疑虑。 应对措施： 1）设立阶段目标； 2）给客户进行设计及实现过程讲解，使客户要求的阶段交付目标尽量与阶段实现的目标相一致。 二、在系统设计时为考虑软件平台的应用范围，不断修改设计，进行讨论，反复评审，始终拿捏不定，导致设计时间过长。 应对措施： 1）寻求有经验、有判断权的领导作为项目组的核心力量，短时间内判断适用技术，确定模块性能； 2）项目前期与用户充分交流，多调研需求，后快速开发，之后再进行升级； 三、不像桌面程序的开发，发展时间长，已逐渐形成了一套规范，而WEB应用刚刚发展不长时间，很多东西仍延用桌面程序的要求，但桌面程序与WEB程序的不同导致这些规范不可能完全适用，甚至大部分的都不适用。而且WEB的表现形式决定了界面布局有着自己的特点，依赖程序员之间自发的保持界面一致很难达到希望的效果。 应对措施： 提供学校一套WEB界面设计规范； 四、项目规模估计不足，不能在预定时间交付系统。 应对措施： 1）细化需求分析，做好任务分解； 2）掌握先进估计方法，使用估计工具； 3）聘请专家进行估计或参与策划评审； 4）设定弹性任务； 五、开发任务未细化，任务遗漏，导致最终需求没有完成。 应对措施： 使用任务分解和需求跟踪矩阵技术（公司内的开发跟踪工具）； 六、根据以往经验，对于系统性能的要求，各高校均有所差异，这种差异会给软件设计带来较大的影响。 应对措施： 1）向客户展示过去完成的较为成功的设计及实现的功能模块，说明已完成项目功能齐备、性能优异； 2）通过平台及数据库的优化（我们是IBM及ORACLE的合作伙伴，厂商支持力度大）。 编码阶段 一、由于修改代码时会涉及他人编写的代码，而且由于代码封装的不好，容易在某人的代码修改后给他人的代码代来影响。 应对措施： 1）明确模块之间的相互依赖关系，对于依赖性较强的模块加强详细设计： 2）明确人员沟通渠道，对于发现问题确保有合理的问题关闭机制； 二、团体配合能力差，有些模块间接口定义不明确而导致开发返工。 应对措施： 1）详细定义模块间接口联系； 2）加强开发规范的管理，在编码前再次强化开发规范管理的培训； 测试阶段 一、测试设备陈旧落后，导致测试进展缓慢或者测试中得到的数据对用户意义不大。 应对措施： 确认测试环境，提前借用或购置设备； 二、测试用例不完善。测试人员测试不全面，考虑不周，导致程序仍存在很多问题，无法结束项目。 应对措施： 1）测试人员参加需求评审或由PSM对测试人员进行软件需求的培训； 2）加强测试用例评审； 三、对项目开发版本控制不力，在后期开发测试阶段出现版本错误，测试的版本不是最新的，导致无效工作。 应对措施： 1）编码结束后进行配置审计； 2）测试过程中由测试人员控制配置库中的代码版本更新； 实施 一、对实施人员和客户培训不到位，实施难度大。 应对措施： 1）项目任务紧张时也要求形成《技术报告》和《用户手册》作为培训资料； 2）可以由实施人员和客户共同参与系统测试，达到一定培训效果； 二、客户对开发人员依赖感过强，迟迟不