第7章 软件项目风险管理解析.ppt

* * * * * * * * * * * * * * * * 7.6 案例分析 以一个教育管理系统项目为例。某教育管理系统项目是一个基于J2EE技术的Web应用项目。它主要为个公司或者一个部门的所有员工提供教育培训的管理。这个项目的需求来自一家大型公司，我们要在规定期限内提交产品，并保证软件的质量。这里我们将探讨软件项目风险管理等内容在软件项目管理中的具体应用，总结出一些有价值的软件项目管理经验，为以后在软件项目中实施项目管理提供了有益的借鉴。教育管理系统项目项目被划分成多个较小的模块或单元，分配给项目的各个小组的成员，每个小组成员承担一个或几个任务。首先是子系统和模块的分解，子系统和模块的分解着重于功能，本系统的分解，依据需求所要求的三个角色的不同操作进行划分。系统被划分员工操作子系统、部门领导管理子系统以及系统管理员子系统这样三个子系统。然后，根据功能，将各个子系统又划分成几个模块。整个教育管理系统的功能划分如图7-1所示。 案例分析 案例分析 由于风险是在项目开始之后才开始对项目的开发起负面的影响，所以风险分析的不足，或是风险回避措施不得力，都很有可能造成软件开发的失败。风险分析是在事前的一种估计，凭借一定的技术手段和丰富的经验，基本能够对项目的风险做出比较准确的估计，经过慎重的考虑提出可行的风险回避措施，是避免损失的重要环节。下面主要关注软件开发中的主要风险，但是这只是项目风险中的一部分，在资金、预算、合同等方面都存在风险。 案例分析 项目过程中在几乎每个阶段都会出现风险。因此，正确评估每个阶段可能的风险是保证项目按时按质完成的重要环节。软件在需求分析阶段、设计阶段、实现阶段以及测试维护阶段等，会出现不同的风险。 需求分析阶段的风险 软件的开发是以用户的需求开始，在大多数情况下，用户需求要靠软件开发方的引导才能保证需求的完整，再以书面的形式形成 《用户需求》这一重要的文档。需求分析更多的是开发方确认需求的可行性和一致性的过程，在此阶段需要和用户进行广泛的交流和确认。需求和需求分析的任何疏漏造成的损失会在软件系统的后续阶段被一级级地放大，因此本阶段的风险最大。 案例分析 设计阶段的风险 设计的主要目的在于软件的功能正确的反映了需求。可见需求的不完整和对需求分析的不完整和错误，在设计阶段被成倍地放大。设计阶段的主要任务是完成系统体系结构的定义，使之能够完成需求阶段的即定目标;另一方面也是检验需求的一致性和需求分析的完整性和正确性。 设计本身的风险主要来自于系统分析人员。分析人员在设计系统结构时过于定制，系统的可扩展性较弱，会给后期维护带来巨大的负担，和维护成本的激增。 设计阶段蕴涵的另一种风险来自于设计文档。文档的不健全不仅会造成实现阶段的困难，更会在后期的测试和维护造成灾难性的后果，例如根本无法对软件系统进行版本升级，甚至是发现的简单错误都无从更正。 案例分析 开发测试阶段的风险 软件的实现从某种意义上讲是软件代码的生产。原代码本身也是文档的一部分，同时它又是将来运行于计算机系统之上的实体。源代码书写的规范性，可读性是该阶段的主要风险来源。规范的代码生产会把属于程序员自身个性风格的成分引入代码的比例降到最低限度，从而减小了系统整合的风险。 维护阶段的风险 从软件工程的角度看，软件维护费用约占总费用的 55%-70%，系统越大，该费用越高。对系统可维护性的轻视是大型软件系统的最大风险。在软件漫长的运营期内，业务规则肯定会不断发展，科学的解决此问题的做法是不断对软件系统进行版本升级，在确保可维护性的前提下逐步扩展系统。 案例分析 在软件系统运营期间，主要的风险源自于技术支持体系的无效运转。科学的方法是有一支客户支持队伍不断收集运行中发现的问题，并将解决问题的方法传授给软件系统的所有使用者。 体系结构方面的风险 本项目采用J2EE技术和三层结构，在技术的成熟度上来说，不存在风险。但是，在实现上，对开发人员的技术要求，以及在实现良好的软件构架和稳定的组件方面，也存在风险性。 软件体系结构影响到软件的如下质量因素： 软件的可伸缩性： 软件的可维护性： 软件易用性： 案例分析 项目管理中的风险 ——项目管理中主要考虑的风险问题有： 软件是否能够按工期的要求完成 软件需求的调研是否深入透彻 软件的实现技术手段是否能够同时满足性能要求 软件质量体系是否能够被有效地保证 案例分析 风险管理贯穿于整个项目生命周期。风险管理包括三个阶段：风险标识别、风险量化以及风险规避。和其他的软件项目一样，在教育管理系统项目中也存在着许多风险。我们将风险影响划分为四级，从高到低为:一级、二级、三级、四级，级别越高，表示风险发生后带来的影响越大;同时我们也将风险发生率分为四级，一级最高，级别越高，表示风险发生的几率越大