2.1 项目阶段和项目生命期
1．项目阶段

通常按照工作出现的先后，将项目分成若干个项目阶段，项目阶段的全体被称为项目生命期。项目生命期用来定义一个项目的开始与结束。项目中的各个子项目也可能有明显

不同的项目生命期。将项目分成若干个项目阶段，以便提供更好的管理控制。

每个项目阶段以一个或几个可交付成果的完成作为标志。项目

 
2．项目生命期的特点
 
    项目生命期在以下 5 个方面的特点如图 2.1 所示。 „
    •一般产品生命期比项目生命期长。
常见的生命周期模型：
 
（1）线性模型： 瀑布模型（waterfall Model）； V 模型（V Model）。

（2）迭代模型： 原型模型； 喷泉模型； 增量模型； 统一过程； 敏捷方法。
 
（3）螺旋模型。
 
生命周期模型的选择
 
    项目计划的关键步骤是为项目选定合适的生命周期模型，在该模型的指导下，确定活动之间的顺序和依赖关系；
 
    生命周期模型的选择基准：确保在正确的阶段，做正确的事情；

    必须确保项目的特征可以使得在相应的阶段，具备足够的条件有效开展相应的活动。
   
1．瀑布模型 (线形顺序模型)

瀑布模型如图 2.2 所示，其特点有：

    •将用户的原始需求逐步求精的过程。每个阶段都进行了一次变换或求精；

„    •每个阶段定义明确，以上个阶段输出为输入，产生下一个阶段所需的输入；

„    •强调了可追溯性，可控制性；

    „• 提供了一个软件工程化的模板；

   „ •是很多改进模型的基础。 

瀑布模型的优点：强调开发的阶段性；强调早期计划及需求调查；强调产品测试。

瀑布模型的缺点：

    瀑布模型中划分的几个阶段，没有反映出人类认识过程的反复性。 特别是瀑布模型过于依赖早期进行的唯一一次需求调查，不能适应需求的变化；

    由于瀑布模型是单一流程，开发中的经验教训不能反馈应用于本产品的过程。


瀑布模型适合的项目

    ♦在项目开始前，项目的需求很明确；
 
    ♦在项目开始前，解决方案也很明确；
 
    ♦类似的项目如：公司的财务系统；库存管理系统；短期项目。
 
2.V 模型

    V 模型是更严格的线性模型，提出了测试提前的理念，重视前期工作产品的验证。如图 2.3 左边是软件设计实现过程，同时伴随着制定测试计划的过程。右边是对左边结果的验证。V 模型具体过程是：
 
    ①设计人员在做需求分析的同时，测试人员就开始阅读、审查需求分析结果，确定测试目标，准备测试用例，并制定验收测试计划。
 
    ②设计人员在做概要设计时，测试人员可以了解系统是如何实现的，基于什么样的平台，于是设计系统测试方案和系统测试计划，并准备好测试环境。
 
    ③设计人员在做详细设计时，测试人员可以参与、评审设计，同时设计功能方面的测试用例。
 
    ④在编程的同时，进行单元测试，可以尽早查出程序中的错误。

V 模型适合的项目

    ♦在项目开始前，项目的需求很明确；

    ♦在项目开始前，解决方案也很明确；

    ♦对系统的性能安全很严格的项目；类似的项目如：航天飞机等；公司的财务系统。

线性模型的缺陷

  ‹ •在项目开始阶段，用户常常难以清楚的给出所有需求。但线性模型却依赖于此，还不能接受许多项目的开始阶段自然存在的不确定性；
‹
   •产品的运行版本要到项目开发晚期才能得到。由于缺乏有效的中间产品验证手段，很多致命错误可能很晚才能发现；

‹   •对用户提出的修改适应性差，容易造成混乱；

  ‹ •一次难以构造一个完全符合用户需求的产品  
    迭代式模型基于这样一个事实：就像任何一个复杂产品一样要经过一段时间的演化：业务和产品需求随着开发工作的进展常常发生变化；紧迫的市场期限难于完成一个完善的

产品；只要核心能够被很好的理解，产品的细节可以以后丰富和定义。

1.原型模型（快速成型模型）
 
    原型：一个真实的可执行模型，它实现了系统的若干基本功能。
 
    原型法：不断地运行系统“原型”来进行启发、揭示和判断的系统开发方法，如图 2.4 所示。在获取一组基本的需求定义后，快速建立一个目标系统的最初版本-原型，并把

它交给用户试用、补充和修改，再进行新的版本开发。反复进行这个过程，直到用户满意为止。从而应用系统的“最初版本”就逐步演变为系统的“最终版本”。
 
    原型法的开发步骤，如图 2.5 所示。



原型特征：

     ♦ 它是一个可实际运行的系统，具有满足用户需求的必要属性； „ 它没有固定的生存期。一种极端是扔掉原型（以最简便方式大量借用已有软件，做出最后产品的模型，
 
     ♦证实产品设想是成功的，但在产品中并不使用这些模块）；另一种极端是最终产品的一部分即增量原型（先做出最终产品的核心部分，逐步增加补充模块），演进原型居于

其中（每一版本扔掉一点，增加一点，逐步完善至最终产品）。在这期间，用户和开发团队都不为程序算法或设计技巧等枝节问题分心，而是要确定开发团队是否理解了用户的意

思，同时试验实现它们的若干方法；
 
     ♦它是迭代过程的集成部分，即每次经用户评价后修改、运行，不断重复双方认可。
 
原型法优点

     •及时验证开发的功能是否符合产品需求。

     •帮助导引出高质量的产品要求。如果没有可能在一开始就弄清楚所有的产品需求，它们可以分批取得。而对于已提出的产品需求，则可根据对现阶段原型的试用而做出修

改。

     •风险管理可以在早期就获得项目进程数据，可据此对后续的开发循环做出比较切实的估算。提供机会去采取早期预防措施，增加项目成功的机率。 

     •有助于早期建立产品开发的配置管理，产品构建，自动化测试，缺陷跟踪，文档管理。均衡整个开发过程的负荷。

     •开发中的经验教训能反馈应用于本产品的下一个循环过程，提高质量与效率。
  
     •如果风险管理发现资金或时间已超出可承受的程度，则可以决定调整后续的开发，或在一个适当的时刻结束开发，但仍然有一个具有部分功能的，可工作的产品。

     •使用户可以在新的一批功能开发测试后，立即参加验证，以便提供非常有价值的反馈。
 
原型法缺点

     ♦ 原型化方法开发的时候，测试和文档工作常常容易被忽略；

     ♦ 运行的效率可能会比较低。
 
Prototype 模型适合的项目

     •原型化方法适用于用户需求不清，管理及业务处理不稳定，需求常常变化；

     •规模小，不太复杂，而且不要求集中处理的系统；

     •有比较成熟借鉴经验的系统开发；

     •用于开发信息系统中的最终用户界面；

     •原型化方法不适于开发大的系统。

2．喷泉模型(RAD)
 
    喷泉模型(Rapid Application Development Model)如图 2.6 所示，其特点是：
 
    ♦认为软件生命周期的各个阶段是相互重叠和多次反复的；

    ♦也是一种线性开发模型，与瀑布模型类似，只是从串行改并行；
 
    ♦主要用于面向对象方法中，面向对象的分析和设计重叠，交叉、并行进行。
 
3、增量模型(递增模型、产品改进模型 Incremental Model)
 
    增量模型就是先完成一个系统子集的开发，再按同样的开发步骤增加功能 (系统子集)，如此递增下去直至满足全部系统需求。如图 2.7 所示。

增量模型特点

    •融合了线性顺序模型的基本成分和原型的迭代特征；

„    •是随着日程时间的进展而交错的线性序列；

„    •与原型不一样的地方是强调每个增量均发布一个可操作产品；

„    •版本增量模型融合了线性模型的基本特征，每一个线性序列产生软件的一个可发布的“增量”；

„    •第一个增量往往着重在系统架构和核心功能，系统架构反映了系统的核心需求

增量模型适合的项目

    ♦ 项目开始，明确了需求的大部分，但是需求可能会发生变化；

    ♦对于市场和用户把握不是很准，需要逐步了解； 

    ♦对于有庞大和复杂功能的系统进行功能改进，就需要一步一步实施的。 

4、统一过程
 
    统一过程模型是一种“用例和风险驱动，以架构为中心，迭代并且增量”的开发过程，由 UML 方法和工具支持。它把整个软件开发项目划分为许多小的“袖珍项目”，每

个“袖珍项目”都包含正常软件项目的所有元素。 RUP 的统一过程结构如图 2.8 所示。

    RUP 的时间轴被分解为四个顺序阶段：（1）阶段(Inception)；（2）细化阶段(Elaboration)；（3）构造阶段(Construction)；（4）交付阶段(Transition)。
 
    每个阶段结束于一个主要的里程碑，本质上是两个里程碑之间的时间跨度；

    在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。
 
RUP 的阶段目标

   （1）初始阶段的目标是为系统建立业务案例并确定项目的边界；
 
   （2）细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素；
 
   （3）构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试；（4）交付阶段的重点是确保软件对最终用户是可用的。
 
RUP 的核心工作流
 
    RUP 中有 9 个核心工作流，分为：6 个核心过程工作流(Core Process Workflows)；3 个核心支持工作流(Core Supporting Workflows)。
 
    尽管 6 个核心过程工作流可能使人想起传统瀑布模型中的几个阶段，但应注意迭代过程中的阶段是完全不同的，这些工作流在整个生命周期中一次又一次被访问。
 
    9 个核心工作流在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复。
 
核心过程工作流
 
   （1）业务建模工作流为组织开发一个构想，并基于这个构想在业务用例模型和业务对象模型中定义组织的过程，角色和责任。
 
   （2）需求工作流的目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。
 
   （3）分析和设计工作流将需求转化成未来系统的设计，为系统开发一个健壮的结构并调整设计使其与实现环境相匹配，优化其性能。
 
   （4）实现工作流的目的包括以层次化的子系统形式定义代码的组织结构；以组件的形式(源文件、二进制文件、可执行文件)实现类和对象；将开发出的组件作为单元进行测试

以及集成由单个开发者（或小组）所产生的结果，使其成为可执行的系统。
 
   （5）测试工作流要验证对象间的交互作用，验证软件中所有组件的正确集成，检验所有的需求已被正确的实现，识别、提出缺陷并确认缺陷在软件部署之前被处理。
  
   （6）部署工作流的目的是成功的生成版本并将软件分发给最终用户。

核心支持工作流
 
   （1）配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物，管理演化系统中的多个变体，跟踪软件创建过程中的版本。
 
   （2）软件项目管理工作流平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。
 
   （3）环境工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。
 
RUP 模型的优点：
 
   （1）提高了团队生产力，在迭代的开发过程、需求管理、基于组件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面，针对所有关键的开发活动为每个开发

成员提供了必要的准则、模板和工具指导，并确保全体成员共享相同的知识基础；
 
   （2）它建立了简洁和清晰的过程结构，为开发过程提供较大的通用性。
   
    螺旋模型 —— 在原型基础上，进行多次原型反复并增加风险评估，形成螺旋模型。如图 2.9 所示。

    螺旋模型＝瀑布+迭代+原型+风险。



螺旋模型优点：
 
     •强调严格的全过程风险管理；

     •强调各开发阶段的质量；
 
     •提供机会检讨项目是否有价值继续下去。
 
螺旋模型缺点：必须引入非常严格的风险识别，风险分析和风险控制，这对风险管理的技能水平提出了很高的要求。也需要人员，资金和时间的大量投入。
 
    ♦螺旋模型适合的项目
 
    ♦风险是主要的制约因素； 

    ♦不确定因素和风险限制了项目进度；
 
    ♦用户对自己的需求也不是很明确； 

    ♦需要对一些基本的概念进行验证； 

    ♦可能发生一些重大的变更； 

    ♦项目规模很大； 

    ♦项目中采用了新技术。 

    各种模型技术特点与适用范围对比


 
1．项目过程
 
    过程就是基于一定输入，采用相关工具和技术，产生一定输出的活动集合。项目由多个过程构成。项目过程分为：
 
    •项目管理过程 关心描述和组织项目的各项工作；
 
    • 面向产品过程 关心具体描述和创造项目产品。
 
    项目管理过程和面向产品过程在项目整个过程中重叠并相互作用。例如，项目范围的定义不可能缺少对如何生产产品的基本理解。
 
过程分类

    •管理类过程；
 
    •技术类过程——需求分析，总体设计，编码，测试等；

    •支持类过程——配置管理；

    •改进类过程——总结经验教训，部署改进。
 
2．项目管理过程组
 
    项目管理的过程可以被分成 5 个过程组，所有过程组有一个或多个管理过程。各过程组之间的联系如图 2.10 所示，各过程组之间活动的交叉如图 2.11 所示。


（1）项目启动过程组——明确项目的环境和约束；明确项目的目标与范围界定；对候选项目进行可行性分析；选定项目。
 
（2）项目计划过程组——为了指导项目实施所进行的有关项目实施方案的事先规划。
 
（3）项目执行过程组——为完成在项目管理计划中确定的工作，以达到项目目标所必须的各个过程。
 
（4）项目监控过程组——项目管理者根据项目进展的状况，对比原计划找出偏差、分析成因，研究纠偏对策，并实施纠偏措施的全过程。
 
（5）项目收尾过程组——包括正式结束项目或项目阶段的所有活动，将完成的成果交与他人或结束已取消的项目的各个过程，包括项目收尾和合同收尾。