生命周期模型选用指南.doc

PAGE 编号：XXXXXXXX Page PAGE 3 of NUMPAGES 3 生命周期模型选用指南 目 录 TOC \o 1-5 \h \z 1 目的 1 2 适用范围 1 3 模型介绍 1 3.1 瀑布模型 1 3.1.1 模型说明 1 3.1.2 模型分析 1 3.2 迭代模型 2 3.2.1 模型说明 2 3.2.2 模型分析 2 3.3 快速原型模型 3 3.3.1 模型说明 3 3.3.2 模型分析 3 3.4 精简模型 4 3.4.1 模型说明 4 3.4.2 模型分析 4 4 模型选择 6 4.1 模型选择原则 6 4.2 项目分类 6 4.3 模型选择指南 7 目的 描述适合公司现状、可供项目选择的组织级生命周期模型。 适用范围 公司所有软件项目。 模型介绍 瀑布模型 模型说明 图1 瀑布模型 对于需求比较明确的项目，可以使用瀑布模型进行项目开发，每个阶段的输入都是依靠上一个阶段的输出，每个阶段内都需要完成与最终产品相关的所有工作。 模型分析 优点： 可以明确划分项目的各个阶段，便于管理； 项目成员只需要在被安排的阶段开展项目工作，不需要全程参与； 阶段工作内容清晰，降低了开发难度。 缺点： 对项目的启动条件要求较高； 如果出现需求不明确或设计开发技术瓶颈，将会影响后续阶段的工作启动； 最终产品提交给用户确认的时间比较晚，存在一定的风险。 迭代模型 模型说明 图2 迭代模型 通常有许多项目不能在需求开发阶段提供准确的需求，对于这样的项目，可以选择迭代开发模型，将能够确定的需求分析确定下来。之后便可以对这部分确定的需求进行系统设计、编码和测试。整个项目可以进行多次迭代的过程，现般情况下迭代的起点从需求开发开始，然后进行设计、编码和测试，但是有时候也可能出现从设计或编码阶段安排新的迭代过程。 模型分析 优点： 项目的启动条件比较灵活、只要用户有基本的立项意向和需求范围就可以开始计划工作； 可以在项目早期识别和管理风险； 可以较快的展项目开发的成果，有益于增强客户授信度和满意度。 缺点： 迭代过程和范围划分比较复杂，项目的过程管理难度较大； 产品的设计开发是迭代过程完成的，容易出现产品构件兼容性问题，如果处理不当会出大量返工的工作。 快速原型模型 模型说明 图3 快速原型模型 在很多时候，需求分析人员无法通过与用户交谈就能获得明确的、详细的需求。这种情况可以选择快速原型开发方法，它的主要目的就是获得与验证需求。首先由开发人员构造原型，然后让用户试验该原型。一般地，当用户面对一个可操作的软件时，他比较容易说清楚“需要什么”和“不要什么”。从而有助于分析人员获取更详细的需求，以及验证需求是否正确。不断重复上述过程，直至满足用户的需求为止。 模型分析 优点： 可以直观地让用户确定其需求，降低了用户对其提供的需求的不确定性。 缺点： 原型开发需要较早投入开发成本，如果原型不能在产品开发过程中进行复用，将会导致项目成本的增加。 精简模型 模型说明 图4 精简模型1 图5 精简模型2 对于一些规划较小、版本升级、或者是有大量可复用构件的项目，这些项目需求相对比较明确、产品架构比较成熟和稳定，因此可以选择精简生命周期模型。根据项目的不同情况：可以将设计阶段和编码阶段精简为一个工程阶段（如图4）；也可将需求开发阶段和设计阶段精简为一个阶段、将编码阶段和测试阶段精简为一个阶段（如图5）。 模型分析 优点： 缩短开发周期、降低各阶段工作的衔接工作； 可以一定程度降低项目的成本。 缺点： 如果精简方式选择不合理，可能会造成产品质量降低。 模型选择 模型选择原则 能够满足公司“开发管理方针”的要求； 不会降低项目开发过程和工作产品的质量； 不会失去对工作进展的（跟踪）可视性； 不会失去对软件工作产品的配置管理和控制，也不会额外增加无益的工作； 不会降低工程师的开发效率； 在维持现有人力资源的情况下，能够按计划如期完成工作； 项目资金是否可以控制在目标成本范围内。 项目分类 项目类别 金额 （万元） 项目周 期(月） 总工时（人月） 需求明确程度 需要应对的主要风险 项目管理的重点 管理级别A 100 12 50～70 任意 主要是需求不明确和进度风险，人员的项目工时安排受到限制，容易在项目关键点出现生产力和关键资源缺失的现象。 按