作为行动方针时。类似的，一个项目阶段可以在没有决定启动任何其他阶段的时候就结 束，例如当项目结束或如果项目持续下去风险太大时。
一个IT公司使用迭代式的生命周期，项目中可以同时开展多个阶段。每个模块都要 经过需求获取、分析、设计和构造几个阶段，但当一个模块的分析工作将要完成时，另 一模块的需求收集工作就可以并行开始了。
阶段的正式完成不包括对后续阶段的批准。为了有效地控制，每个阶段都要明确该 阶段的任务作为正式启动。如图4-11所示。在获得授权的情况下，阶段末的评审可以结 束当前阶段并肩动后续阶段。有些时假一次评审就可以取得这两项授权。这样的阶段末 评审通常被称为阶段出口、阶段验收或终止点。
4.3.3项目生命周期与产品生命周期的关系
一个项目要交付特定的产品、成果和完成特定的服务。项目生命周期定义项目的开 始与结束。假如一个项目交付特定的产品，那么该产品的生命期比项目生命周期更长， 从该产品的研发（此时是项目的任务），到该产品投入使用（或运营），直到该产品的消 亡就构成了该产品的生命周期。许多项目与组织发展战略或正在进行的工作有关。在一 些组织中，一个项目只有在完成了可行性研究、初步计划或者其他等同形式的分析之后 才能正式批准。在这些案例中，初步规划或分析可以采用独立项目的形式。例如，在确 定开发最终产品之前，可以将原型的开发和测试作为单独的项目。
问题、机会或业务需求是典型的激发项目的驱动力。这些压力的结果就导致管理层 通常必须在尊重其他潜在项目的需要和资源要求的前提下排定当前项目申请的优先级。 为将项目与执行组织中的持续运营联系起来，项目生命周期定义中也明确了在项目 结束时所包括（或不包括）的移交行为。例如当一项新产品投入生产或一个新的软件程 序投入市场的时候，应当注意将项目生命周期和产品生命周期区分开。例如，一个负责 开发准备投入市场的新的台式计算机的项目只是产品生命周期中的一部分。图4-12描绘 了这两者的联系。在某些应用领域（例如新产品开发和软件开发）中，组织是将项目生 命周期作为产品生命周期的一部分来考虑的。
4.4典型的信息系统项目的生命周期模型
在实施一个信息系统项目时，不仅需要管理过程组，也需要工程技术过程组和支持 过程组。感兴趣的读者，请参见CMMI或过程改进的相关内容。
以下饼述典型的信息系统项目的生命周期模型，这些生命周期模型均按项目的工程 技术过程的先后顺序来划分的。
1．瀑布模型
瀑布模型是一个经典的软件生命周期模型，一般将软件开发分为可行性分析（计 划）、需求分析、软件设计（概要设计、详细设计）、编码（含单元测试）、测试、运行维 护等几个阶段，如图4-13所示。瀑布模型中每项开发活动具有以下特点。 (l)从上一项开发活动接受其成果作为本次活动的输入。 (2)利用这一输入，实施本次活动应完成的工作内容。
(3)给出本次活动的工作成果，作为输出传给下一项开发活动。
(4)对
本次活动的实施工作成果进行评审。若其工作成果得到确认，则继续进行下
一项开发活动；否则返回前一项，甚至更前项的活动。尽量减少多个阶段间的反复。以 相对来说较小的费用来开发软件。
2．V模型
首先，看V模型的图示。V模型如图4-14所示。
V模型的左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测 试过程的各个阶段。在不同的组织中对测试阶段的命名可能有所不同。
在模型图中的开发阶段一侧，先从定义业务需求、需求确认或测试计划开始，然后 要把这些需求转换到概要设计、概要设计的验证及测试计划，从概要设计进一步分解到 详细设计、详细设计的验证及测试计划，最后进行开发，得到程序代码和代码测试计划。
接着就是测试执行阶段一侧，执行先从单元测试开始，然后是集成测试、系统测试和验 收测试。
V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描 述了这些测试阶段和开发各阶段的对应关系。
(1)．单元测试的主要目的是针对编码过程中可能存在的各种错误，例如用户输入验 证过程中的边界值的错误。
(2)集成测试主要目的是针对详细设计中可能存在的问题，尤其是检查各单元与其 他程序部分之间的接口上可能存在的错误。
(3)系统测试主要针对概要设计，检查系统作为一个整体是否有效地得到运行，例 如在产品设置中是否能达到预期的高性能。
(4)验收测试通常由业务专家或用户进行，以确认产品能真正符合用户业务上的 需要。
在不同的开发阶段，会出现不同类型的缺陷和错误，所以需要不同的测试技术和方 法来发现这些缺陷。
3．原型化模型
原型化模型是为弥补瀑布模型的不足而产生的。
，原型化模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互， 经过和用户针对原型的讨论和交流，弄清需求以便真正把握用户需要的软件产品是什么 样子的。充分了解后，再在原型基础上开发出用户满意的产品。在实际中原型化经常在 需求分析定义的过程进行。原型化模型减少了瀑布模型中因为软件需求不明确而给开发 工作带来的风险，因为在原型基础上的沟通更为直观，也为需求分析和定义，提供了新 的方法。原型化模型的应用意义很广，瀑布和V棋型将原型化模型的思想用于需求分析 环节，来解决因为需求不明确而导致产品出现严重后果的缺陷。
对于复杂的大型软件，开发一个原型往往达不到要求，为减少开发风险，在瀑布模 型和原型化模型的基础上的演进，出现了螺旋模型以及大量使用的RUP。
4．螺旋模型
螺旋模型是一个演化软件过程模型，将原型实现的迭代特征与线性顺序（瀑布）模 型中控制的和系统化的方面结合起来。使得软件的增量版本的快速开发成为可能。在螺 旋模型中，软件开发是一系列的增量发布。在早期的迭代中，发布的增量可能是一个纸 上的模型或原型；在以后的迭代中，被开发系统的更加完善的版本逐步产生。螺旋模型 的整个开发过程如图4-15所示。
图4-15中的螺旋线代表随着时间推进的工作进展；开发过程具有周期性重复的螺旋 线形状。4个象限分别标志每个周期所划分的4个阶段：制定计划、风险分析、实施工 程和客户评估。螺旋模型强调了风险分析，特别适用于庞大而复杂的、高风险的系统。
5．迭代模型
在大多数传统的生命周期中，阶段是以其中的主要活动命名的：需求分析、设计、
编码、测试。传统的软件开发工作大部分强调过程的串行执行，也就是一个活动需要在 前一个活动完成后才开始，从而形成一个过裎串，该过程串就组成了软件项目的生命周 期。在迭代模型中，每个阶段都执行一次传统的、完整的串行过程串，执行一次过程串 就是一次迭代。每次迭代涉及的过程都包括不同比例的所有活动。
RUP (Rarional Uni;fied Process)软件统一过程是一种“过程方法”，它就是迭代模型 的一种。
RUP可以用二维坐标来描述。横轴表示时间，是项目的生命周期，体现开发过程的 动态结构，主要包括周期(Cycle)、阶段(Phase)、迭代(Iteration)和里程碑(Milestone): 纵轴表示自然的逻辑活动，体现开发过程的静态结构，主要包括活动(Activity)、产物 (Artifact)、工作者(Worker)和工作流(Workflow)。如图4-16所示。
RUP中的软件生命周期在时间上被分解为4个顺序的阶段，分别是：初始阶段 (Inception)、细化阶段(Elaboration)、构建阶段(Construction)和交付阶段（Transition）。 这4个阶段的顺序执行就形成了一个周期。
每个阶段结束干一个主要的里程碑（Major Milestones）。在每个阶段的结尾执行一 次评估以确定这个阶段的目标是否已经满足。
每个阶段，从上到下迭代，亦即从核心过程工作流“商业建模”、“需求调研”、“分 析与设计”……执行到“部署”，再从核心支持工作流“配置与变更管理”、“项目管理” 执行到“环境”完成一次迭代。根据需要，在一个阶段内部，可以完成一次到多次的选 代。各阶段的主要任务如下。