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

1、 生命周期模型选用指南内部资料，注意保密 Page 1 of 16生命周期模型选用指南版本 1.0发布时间：烟台海颐软件股份有限公文件变更记录*A - 增加 M - 修订 D - 删除变更版本号日期变更类型（ A*M*D）修改人 变更摘要 备注生命周期模型选用指南内部资料，注意保密 Page 2 of 161. 目的本文档统一规范描述了组织内软件开发过程中可以使用的各种生命周期模型，供项目策划时根据项目的具体情况选用，由此确定软件项目开发过程的各种不同的阶段以及各阶段的执行顺序，从而加强项目管理，提高过程能力成熟度级别，保证产品质量。2. 适用范围机构：产品部、开发部、工程部、质量部。业务：本

2、指南适用于组织内的全部软件项目。3. 名词术语软件生命周期：软件生命周期，是指从开始策划软件产品到软件不再使用为止这段时间。典型的软件生命周期包括策划阶段、需求阶段、分析与设计阶段、实现阶段（构造阶段） 、测试阶段、实施和维护阶段。软件生命周期模型软件生命周期模型是对软件工程活动的组织方式。软件生命周期模型通过确定软件开发活动的顺序和相互制约关系来保证软件工程活动的流程化。4. 软件生命周期模型4.1 瀑布模型(Waterfall)4.1.1 模型定义该模型首先由 Royce1970提出，又称线性顺序模型，或典型生命周期模型，指软件生命周期的各项活动始终按照固定顺序执行：需求、设计、构造、集成

3、、测试、维护，各活动之间有明确的界限，非连续的，对阶段结束的成果进行判断以确定是否可以开始下一阶段的工作，形如瀑布流水，最终得到软件产品。瀑布模型是所有软件生命周期模型的基础。生命周期模型选用指南内部资料，注意保密 Page 3 of 164.1.2 模型图产品交付需求 设计 实现 测试项目确定测试系统需求需求分析编码运行和维护设计瀑布模型4.1.3 模型特点1) 优点瀑布模型是一种文档驱动模型，主要的工作产品通过文档从一个阶段传递到下一阶段，瀑布模型的每个活动的完成都是以该活动的评审通过作为标志的。当项目有着明确的产品定义以及易于理解的技术方案的情况下，瀑布模型有助于及早发现问题，降低阶段成

4、本。瀑布模型的主要特点： 简单、易于理解 要求严格的管理，包括周密的项目计划、明确的交付物、严格的质量控制手段（如阶段的评审）等 客户在项目的后期才可以见到的产品以及判断产品的质量 强调产品的测试2) 缺点： 缺乏灵活性瀑布模型要求在项目的初期明确定义全部需求，然而客户在项目初期很难明确描述所有的需求，这种不确定性难以满足模型要求的“稳定的、明确定义的需求”的要求。事实上，在设计完成和代码完成之前很难充分描述需求，因为客户只能在最后阶段看到产品，产品是否满足客户的真正需求只有此刻才可以得以检验。因此是否满足客户真正需求的风险往往只能在开发过程后期才显露，相应的修改成本巨大。 很难反映实际的开发

5、过程生命周期模型选用指南内部资料，注意保密 Page 4 of 16实际的开发过程很难象瀑布模型中所有活动按照既定的顺序执行的设想一样，因为很多活动是重复进行的。 对于要求快速开发的项目，瀑布模型可能导致过多的文档 由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程； 用户的反馈只有到项目后期才看得到。4.1.4 适用场景 适合前期需求比较明确,且项目管理能力比较欠缺的的项目； 适合有稳定的产品定义和易于掌握的技术方案的项目 适合处理易于理解但复杂的项目 适合质量需求高于进度和成本需求的项目 适合项目的开发队伍的技术力量比较薄弱或缺乏经验的情况 适合于小型项目4.2 带反馈的瀑布模型(

6、Waterfall Model With Feedback)4.2.1 模型定义该模型是在瀑布模型的基础上，为了改变瀑布模型环节间的不可逆向交互的情况，而设置了反馈环节而成。4.2.2 模型图产品交付需求 设计 实现 测试项目确定测试系统需求需求分析编码运行和维护设计带反馈的瀑布模型生命周期模型选用指南内部资料，注意保密 Page 5 of 164.2.3 模型特点带反馈的瀑布模型在保持原有瀑布模型活动阶段自上而下、相互衔接、逐级下落的次序的同时，增加了反馈环节，当某阶段发现上游缺陷时可通过追溯予以消除或改进。4.2.4 使用场景 适用于需求比较明确，各环节间反馈更新信息较少的项目。针对烟台海

7、颐软件股份有限公司而言，本模型适合于小型的、推广性质的网站、县级客服、营销管理系统等项目。4.3 V 型模型(V-shaped Model)4.3.1 模型定义V 形模型也是连续开发模型的一种，有时也被成为快速应用开发模型(RAD)，类似于瀑布模型。区别在于每个开发阶段有一个测试阶段与之匹配：需求同系统测试，架构设计同集成测试，子系统设计同单元测试。V 模型是瀑布模型的改进。4.3.2 模型图需求 设计 实现 测试单元测试需求分析编码软件集成测试概要设计V形模型详细设计系统测试4.3.3 模型特点1) 优点 应用和管理简单：为开发阶段定义的进入准则和出口准则可以清楚的定义，对项目进行有效管理的

8、相关评判尺度也可以清楚的定义。同时，由于软件开发过程的任何一个时间点，相应的文档和代码等都只有一个基线，所以对于配置管理也是一件比较轻松的事情。 强调测试阶段/过程与开发过程的对应关系：从模型中也可以看出，软件测试是 V 模型的重点。在 V 模型生命周期模型中，软件测试的活动是和开发的每个阶段活动对应的。生命周期模型选用指南内部资料，注意保密 Page 6 of 16 可以不考虑过程的反复 不必随时列出管理和支持过程2) 缺点： V 模型在处理风险方面存在不足：假如存在风险或者软件需求方面的大的变更，我们回头去修改前面阶段的框架、设计、代码或测试文档和测试用例等，将需要极大的成本，同时难度也较

9、大。 软件产品在开发过程中对用户是不可见的：在开发阶段中，用户没有直观的工作产品可以体验，只能是在产品交付之后才能使用。这导致用户在开发过程中参与的力度不足。4.3.4 适用场景 需求是稳定可靠的 软件实现方法是成熟的 软件结构清晰，模块间的界限明晰结合本组织实际情况，本模型可以被中小规模的系统改造项目所采用。4.4 原型法模型(Prototype Model)4.4.1 模型定义原型模型的基本指导思想是在需求阶段开始前或过程中，通过部分实现系统功能的方式，进行快速开发，建立软件中对用户可见的部分，即所谓的原型。然后基于这个原型，同客户进行沟通、交流，更好的了解客户需求，同时也使开发组对该软件

10、有更好的理解，过程中进行迭代，不断修改这个原型，到了双方都认可的程度，再做详细的分析、设计和编码、测试等，最终开发出客户满意的软件产品。4.4.2 模型图4.4.3 模型特点1) 优点 直观的表示：在需求定义之前可快速构建系统，构建部分系统实现的原型，构建的系统需求原型可以给予客户一个直观的认识。 用户反馈：客户直接对系统原型提供反馈，开发可以根据客户对原型提供的反馈，确认系统存在的问题以及系统实现的优点。可以作为系统开发人员进行系统需求规格的修改，以满足客户实际的需要。生命周期模型选用指南内部资料，注意保密 Page 7 of 162) 缺点： 开发人员和客户对系统需求的了解都不是很深入，存

11、在许多不确定的因素，仍有许多不能关闭的问题。 原型可能没有包含产品应该包含的各个方面。 原型可能使用了在实际环境中无法使用的资源比如操作系统。 原型可能无法处理在满负荷情况下的运行。 当需求不清楚时可能导致抛弃已开发出的原型，造成原型不能利用，从而导致成本的增加。4.4.4 适用场景 用户技术素养较差，不能清晰的描述其意图，对未来软件的功能和期望不明确，造成项目不明确因素太多； 用户的具体功能需求不明确； 用户定义了软件的一般性目标，但不能标识出详细的输入、处理和输出需求 分析设计人员对应用领域不熟悉； 开发者不能确定算法的有效性、操作系统的适应性或人机交互的形式； 新的产品领域，或者项目包含

12、一种新技术，例：新硬件、新的开发语言、新的系统架构等； 高风险项目;结合本组织的情况，本模型可以适用于新产品开发、WEB网站建设等。4.5 螺旋模型 (Spiral)4.5.1 模型定义螺旋模型结合了瀑布模型的系统化特点和原型法模型的迭代的特征，并加入两者所忽略的风险分析所建立的一种软件开发模型。该模型于1998 年由美国TRW 公司（B.W.Boehm）提出。螺旋模型是一种风险驱动的模型。软件项目风险的大小作为指引软件过程的一个重要因素。采用螺旋模型的开发过程，交付的软件系统是通过一系列增量版本的发布组成，早期的增量版本可能是一个纸面上的模型或是一个原型，而最后的增量版本是日渐完善的软件系统

13、。生命周期模型选用指南内部资料，注意保密 Page 8 of 164.5.2 模型图4.5.3 模型特点1) 优点 包含瀑布模型和原型模型 将阶段分成更细小的块 允许设计的变化 受风险分析的驱动，可降低开发风险 用户可较早看到产品 用户与产品开发紧密相连 经费不必预先分配 需应用保护性活动（软件配置管理和软件质量保证）2) 缺点 模型比较复杂，对项目团队的管理能力，特别是风险的管理能力要求较高，同时需要人员，资金，和时间的投入。4.5.4 适用场景 风险是项目中最主要的限制因素 客户无法提出明确的需求 可能发生重大变更的项目 项目规模和资金投入较大的项目 新技术的引入，缺乏相关经验 开发团队要

14、求具备管理经验特别是风险管理经验和技能生命周期模型选用指南内部资料，注意保密 Page 9 of 164.6 增量模型4.6.1 模型定义增量模型，是具备迭代特征的瀑布模型。采用该模型，每一个增量的开发过程都采用瀑布模型，产生的结果是新增部分功能或性能。当使用增量模型时，第一个增量往往是核心产品，即实现了基本的需求；核心产品交用户使用（或进行更详细的复审），使用和/或评估的结果是下一个增量的开发计划，计划中明确了对下一增量版本内容的修改和新增待开发的功能，如此迭代，直至系统整体实现。增量模型和原型模型的不同之处是其强调每一个增量均要发布一个可操作产品。4.6.2 模型图维 护产 品 交 付需

15、求 设 计 实 现 测 试项 目 确 定测试 1系统需求 需求分析编码 1 验收 1概要设计增量模型详细设计 1运行维护详细设计 n编码 2编码 n测试 2测试 n验收 2验收 n详细设计 24.6.3 模型特点1) 优点 可快速生产出可使用的系统 在达到初始需求之前可降低成本 客户可将早期的增量作为系统的原型，从中获得对后面系统增量的需求经验 可以减少开发过程中的返工 项目总体性失败的风险比较低。虽然可能在一些增量中存在问题，但其他的增量会成功交付。 能够有计划地管理技术风险2) 缺点 由于增量模型的灵活性，如果没有完善的配置管理，容易造成边开发边修改，丧失软件的整体性。 由于在增量实现前，

16、需求不能被详细定义，对确定系统的架构及所有增量都用到的公共服务有一定的影响。 需要科学合理的进行控制增量规模和配置管理。过大的增量划分、杂乱的基线管理等都将增加项目的风险。生命周期模型选用指南内部资料，注意保密 Page 10 of 164.6.4 适用场景 项目工期较紧且客户接受分阶段交付的项目; 分析设计人员对应用领域不熟悉或难以全面把握的项目; 已有系统技术路线发生改变但需求明确的移植类项目。 各种中、大规模的项目类型； 结合本组织的情况，本模型可以适用于工期非常紧的项目以及新产品开发。4.7 RUP 的迭代模型4.7.1 模型定义迭代生命周期模型并不是在开始的时候就将软件的所有需求开发

17、出来。相反的，从实现软件的某个部分开始，通过对这个部分进行评审来明确更进一步的需要开发的需求。重复这个过程，在模型的每个周期都生成一个新的软件版本。迭代式模型是RUP推荐的周期模型。在RUP中，迭代被定义为：迭代包括产生产品发布的全部开发活动和必需的所有其他外围元素。RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：初始阶段(Inception) 、细化阶段 (Elaboration)、构造阶段(Construction)和交付阶段(Transition)。RUP认为，RUP中的每个阶段可以进一步分解为迭代。一个迭代是一个完整的开发循环，产生一个可执行的产品版本，是最终产品的一个子

18、集，它增量式地发展，从一个迭代过程到另一个迭代过程到成为最终的系统每一次的迭代都会产生一个可以发布的产品。RUP用二维坐标来描述。横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期(Cycle)、阶段(Phase)、迭代(Iteration)和里程碑(Milestone)；纵轴以内容来组织为自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动(Activity)、产物(Artifact)、工作者(Worker)和工作流(Workflow)。4.7.2 模型图生命周期模型选用指南内部资料，注意保密 Page 11 of 164.7.3

19、 模型特点1) 优点 降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。 降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。 加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。 由于用户的需求并不能在一开始就做出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。 迭代和瀑布的最大的差别就在于风险的暴露时间上。二者的区别如下图所示： 2) 缺点需要完备的项目管理过程支持，例如配置管理等。4.7.4 适用场景 较复杂的

20、应用项目 大型应用项目(10人以上) 高风险的项目5. 选用软件生命周期模型的策略选择项目软件的生命周期模型，一般来说包括如下步骤：步骤一：明确项目特点步骤二：根据项目特点分析识别项目风险和需求的清晰性步骤三：根据项目目标和风险、需求不确定性分析结果确定软件生命周期策略步骤四：根据软件生命周期策略选择并剪裁软件生命周期模型步骤五：评审选定的软件生命周期模型生命周期模型选用指南内部资料，注意保密 Page 12 of 165.1 分析项目的特点软件生命周期模型的选择首先要考虑项目的特点，包括： 项目借鉴资源(如是否有类似项目、类似产品的实施经验) 资源的可用性（包括人、资金、设施、工具） 项目复

21、杂度（如子系统数量） 项目的难度(如新技术的采用、新领域产品等) 开发成本（包括人力、物力、资金等） 项目进度压力 需求的不确定性和稳定性（需求是否明确、是否逐渐变更、性能要求） 项目版本要求（是否以后升级、是否逐渐变更、版本重用性要求） 项目风险分析5.2 分析项目风险和需求的不确定性根据项目特点分析项目的风险和需求的不确定性，不同的生命周期模型在解决风险和不确定性方面的能力是不同的，例如螺旋模型是一种以风险为导向的模型，确保随着项目成本投入的增加，风险程度降低；而瀑布模型对风险的应对能力相对较弱，采用瀑布模型的项目中可能遗留关键的项目风险在项目后期才能暴露出来，而这种风险的发生带来的损失比

22、项目前期引起的损失大的多。当然，风险和不确定性的管理需要投入项目资源，并对项目团队提出了相应的要求，如风险管理的能力和技能的要求、项目计划和跟踪与监督的要求等，所以风险和需求不确定性大小是选择软件生命周期模型的重要因素，却不是绝对的。5.3 生命周期模型选择矩阵根据如下矩阵来评估项目，确定要选用的生命周期模型。标准 V形模型 瀑布模型 原型模型 增量模型 螺旋模型 迭代模型资源可用性 低 高 有一些 有一些 有一些 中项目复杂度 低 低 中 高 高 高项目成本 低 低 低 中 高 高以后的升级成本 高 高 低 低 低 低不连续的需求变更 大 大 小 小 小 小易使用性 简单 简单 简单 复杂

23、复杂 复杂应用功能需求 明确 明确 不明确 不明确 不明确 不明确渐进式的需求变更 小 小 小 大 大 大项目寿命 短 长 长 长产品技术 存在 存在 新 新 新 新生产率 高 高 低 高 高 高生命周期模型选用指南内部资料，注意保密 Page 13 of 16产品和交付的阶段工作产品的重用性低 低 低 高 高 高需求的不确定性 否 否 是 是 是 是未知需求 否 否 是 是 是 是5.4 合并生命周期模型一个项目在不同的阶段可根据需要合并生命周期模型。例如：在项目需求阶段使用原型模型；在设计和编码阶段使用V 形模型；在测试活动中使用瀑布模型；在运行和维护时使用迭代模型。6. 附录 RUP 介

24、绍软件过程是指实施于软件开发和维护中的阶段、方法、技术、实践及相关产物(计划、文档、模型、代码、测试用例和手册等)的集合。行之有效的软件过程可以提高开发软件组织的生产效率、提高软件质量、降低成本并减少风险。目前市场上领先的软件过程主要有RUP(Rational Unified Process)、OPEN Process和OOSP(Object-Oriented Software Process)。 RUP的提出者Rational软件公司聚集了面向对象领域三位杰出专家Booch、Rumbaugh和Jacobson，同时它又是面向对象开发的行业标准语言标准建模语言(UML)的创立者。RUP是由Ob

25、jectory过程演化而来，其初始版本为5.0，先后经历了5.1、5.11、5.5、 Rational Unified Process2000等版本。6.1 RUP 的二维开发模型 RUP可以用二维坐标来描述。横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期(Cycle)、阶段(Phase)、迭代(Iteration)和里程碑(Milestone)；纵轴以内容来组织为自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动(Activity)、产物(Artifact)、工作者(Worker)和工作流(Workflow)。如图: 6.2

26、 开发过程中的各个阶段和里程碑RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：初始阶段(Inception)、细化阶段(Elaboration)、构造阶段(Construction)和交付阶段(Transition)。每个阶段结束于一个主要的里程生命周期模型选用指南内部资料，注意保密 Page 14 of 16碑(Major Milestones)；每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。 6.2.1 初始阶段初始阶段的目标是为系统建立商业案例并确定项目的边界。为

27、了达到该目的必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。本阶段具有非常重要的意义，在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来讲，初始阶段可能很短。 初始阶段结束时是第一个重要的里程碑：生命周期目标(Lifecycle Objective)里程碑。生命周期目标里程碑评价项目基本的生存能力。6.2.2 细化阶段 细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。为了达到该目的，必须在理解整个系统的基础上，对体系结构作出决策，包括其范围、主要功能和诸如性能等非功能需求。同时为项目建

28、立支持环境，包括创建开发案例，创建模板、准则并准备工具。 细化阶段结束时第二个重要的里程碑：生命周期结构(Lifecycle Architecture)里程碑。生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。此刻，要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。6.2.3 构造阶段 在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制运作以优化成本、进度和质量。 构建阶段结束时是第三个重要的里程碑：初始功能(Initial Operational)里程碑

29、。初始功能里程碑决定了产品是否可以在测试环境中进行部署。此刻，要确定软件、环境、用户是否可以开始系统的运作。此时的产品版本也常被称为“beta”版。6.2.4 交付阶段 交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。在生命周期的这一点上，用户反馈应主要集中在产品调整，设置、安装和可用性问题，所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。 在交付阶段的终点是第四个里程碑：产品发布(Product Release)里程碑。此时，要确定目标是否实现，是否应该开始另一个开发周期。在一些情况下这个里程碑可能与下一个

30、周期的初始阶段的结束重合。6.3 RUP 的核心工作流 (Core Workflows) RUP中有9个核心工作流，分为6个核心过程工作流(Core Process Workflows)和3个核心支持工作流(Core Supporting Workflows)。尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段，但应注意迭代过程中的阶段是完全不同的，这些工作流在整个生命周期中一次又一次被访问。9个核心工作流在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复。6.3.1 商业建模(Business Modeling) 商业建模工作流描述了如何为新的目标组织开发一个构想，并基于这个构

31、想在商业用例模型和商业对象模型中定义组织的过程，角色和责任。 6.3.2 需求(Requirements)需求工作流的目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。为了达到该目标，要对需要的功能和约束进行提取、组织、文档化；最重要的是理解系统所解决问题的定义和范围。6.3.3 分析和设计(Analysis & Design) 分析和设计工作流将需求转化成未来系统的设计，为系统开发一个健壮的结构并调整设计使其与实现环境相匹配，优化其性能。分析设计的结果是一个设计模型和一个可选的分析模型。设计模型是源代码的抽象，由设计类和一些描述组成。设计类被组织成具有良好接口的设计包(Pack

32、age)和设计子系统(Subsystem)，而描述则体现了类的对象如何协同工作实现用例的功能。 设计活动以体系结构设计为中心，体系结构由若干结构视图来表达，结构视图是整个设计的抽象和简化，该视图中省略了一些细节，生命周期模型选用指南内部资料，注意保密 Page 15 of 16使重要的特点体现得更加清晰。体系结构不仅仅是良好设计模型的承载媒介，而且在系统的开发中能提高被创建模型的质量。 6.3.4 实现(Implementation)实现工作流的目的包括以层次化的子系统形式定义代码的组织结构；以组件的形式(源文件、二进制文件、可执行文件)实现类和对象；将开发出的组件作为单元进行测试以及集成由单

33、个开发者（或小组）所产生的结果，使其成为可执行的系统。 6.3.5 测试(Test) 测试工作流要验证对象间的交互作用，验证软件中所有组件的正确集成，检验所有的需求已被正确的实现, 识别并确认缺陷在软件部署之前被提出并处理。RUP提出了迭代的方法，意味着在整个项目中进行测试，从而尽可能早地发现缺陷，从根本上降低了修改缺陷的成本。测试类似于三维模型，分别从可靠性、功能性和系统性能来进行。6.3.6 部署(Deployment) 部署工作流的目的是成功的生成版本并将软件分发给最终用户。部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动，包括：软件打包、生成软件本身以外的产品、安装软件

34、、为用户提供帮助。在有些情况下，还可能包括计划和进行beta测试版、移植现有的软件和数据以及正式验收。6.3.7 配置和变更管理(Configuration & Change Management) 配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。配置和变更管理工作流提供了准则来管理演化系统中的多个变体，跟踪软件创建过程中的版本。工作流描述了如何管理并行开发、分布式开发、如何自动化创建工程。同时也阐述了对产品修改原因、时间、人员保持审计记录。6.3.8 项目管理(Project Management) 软件项目管理平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付

35、使用户满意的产品。其目标包括：为项目的管理提供框架，为计划、人员配备、执行和监控项目提供实用的准则，为管理风险提供框架等。6.3.9 环境(Environment) 环境工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。环境工作流集中于配置项目过程中所需要的活动，同样也支持开发项目规范的活动，提供了逐步的指导手册并介绍了如何在组织中实现过程。6.4 RUP 的迭代开发模式 RUP中的每个阶段可以进一步分解为迭代。一个迭代是一个完整的开发循环，产生一个可执行的产品版本，是最终产品的一个子集，它增量式地发展，从一个迭代过程到另一个迭代过程到成为最终的系统。传统上的项目组织是顺序通过每个

36、工作流，每个工作流只有一次，也就是我们熟悉的瀑布生命周期，如图：这样做的结果是到实现末期产品完成并开始测试，在分析、设计和实现阶段所遗留的隐藏问题会大量出现，项目可能要停止并开始一个漫长的错误修正周期。 一种更灵活，风险更小的方法是多次通过不同的开发工作流，这样可以更好的理解需求，构造一个健壮的体系结构，并最终交付一系列逐步完成的版本。这叫做一个迭代生命周期。在工作流中的每一次顺序的通过称为一次迭代。软件生命周期是迭代的连续，通过它，软件是增量的开发。一次迭代包括了生成一个可执行版本的开发活动，还有使用这个版本所必需的其他辅助成分，如版本描述、用户文档等。因此一个开发迭代在某种意义上是在所有工

37、作流中的一次完整的经过，这些工作流至少包括：需求工作生命周期模型选用指南内部资料，注意保密 Page 16 of 16流、分析和设计工作流、实现工作流、测试工作流。其本身就像一个小型的瀑布项目： 图 3 RUP 的迭代模型 6.5 总结 RUP具有很多长处：提高了团队生产力，在迭代的开发过程、需求管理、基于组件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面，针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导，并确保全体成员共享相同的知识基础。它建立了简洁和清晰的过程结构，为开发过程提供较大的通用性。但同时它也存在一些不足： RUP只是一个开发过程，并没有涵盖软件过程的全部内容，例如它缺少关于软件运行和支持等方面的内容；此外，它没有支持多项目的开发结构，这在一定程度上降低了在开发组织内大范围实现重用的可能性。可以说RUP是一个非常好的开端，但并不完美，在实际的应用中可以根据需要对其进行改进并可以用OPEN和OOSP等其他软件过程的相关内容对RUP进行补充和完善。