生命周期模型选用指南

生命周期模型选用指南版本1.0发布时间：烟台海颐软件股份有限公文件变更记录1.目的本文档统一规范描述了组织内软件开发过程中可以使用的各种生命周期模型，供项目策划时根据项目的具体情况选用，由此确定软件项目开发过程的各种不同的阶段以及各阶段的执行顺序，从而加强项目管理，提高过程能力成熟度级别，保证产品质量。

2.适用范围机构：产品部、开发部、工程部、质量部。

业务：本指南适用于组织内的全部软件项目。

3.名词术语软件生命周期：软件生命周期，是指从开始策划软件产品到软件不再使用为止这段时间。

典型的软件生命周期包括策划阶段、需求阶段、分析与设计阶段、实现阶段（构造阶段）、测试阶段、实施和维护阶段。

软件生命周期模型软件生命周期模型是对软件工程活动的组织方式。

软件生命周期模型通过确定软件开发活动的顺序和相互制约关系来保证软件工程活动的流程化。

4.软件生命周期模型4.1瀑布模型(Waterfall)4.1.1模型定义该模型首先由Royce[1970]提出，又称线性顺序模型，或典型生命周期模型，指软件生命周期的各项活动始终按照固定顺序执行：需求、设计、构造、集成、测试、维护，各活动之间有明确的界限，非连续的，对阶段结束的成果进行判断以确定是否可以开始下一阶段的工作，形如瀑布流水，最终得到软件产品。

瀑布模型是所有软件生命周期模型的基础。

4.1.2模型图4.1.3模型特点1)优点瀑布模型是一种文档驱动模型，主要的工作产品通过文档从一个阶段传递到下一阶段，瀑布模型的每个活动的完成都是以该活动的评审通过作为标志的。

当项目有着明确的产品定义以及易于理解的技术方案的情况下，瀑布模型有助于及早发现问题，降低阶段成本。

瀑布模型的主要特点：·简单、易于理解·要求严格的管理，包括周密的项目计划、明确的交付物、严格的质量控制手段（如阶段的评审）等·客户在项目的后期才可以见到的产品以及判断产品的质量·强调产品的测试2)缺点：·缺乏灵活性瀑布模型要求在项目的初期明确定义全部需求，然而客户在项目初期很难明确描述所有的需求，这种不确定性难以满足模型要求的“稳定的、明确定义的需求”的要求。

事实上，在设计完成和代码完成之前很难充分描述需求，因为客户只能在最后阶段看到产品，产品是否满足客户的真正需求只有此刻才可以得以检验。

因此是否满足客户真正需求的风险往往只能在开发过程后期才显露，相应的修改成本巨大。

·很难反映实际的开发过程实际的开发过程很难象瀑布模型中所有活动按照既定的顺序执行的设想一样，因为很多活动是重复进行的。

·对于要求快速开发的项目，瀑布模型可能导致过多的文档·由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程；·用户的反馈只有到项目后期才看得到。

4.1.4适用场景●适合前期需求比较明确,且项目管理能力比较欠缺的的项目；●适合有稳定的产品定义和易于掌握的技术方案的项目●适合处理易于理解但复杂的项目●适合质量需求高于进度和成本需求的项目●适合项目的开发队伍的技术力量比较薄弱或缺乏经验的情况●适合于小型项目4.2带反馈的瀑布模型(Waterfall Model With Feedback)4.2.1模型定义该模型是在瀑布模型的基础上，为了改变瀑布模型环节间的不可逆向交互的情况，而设置了反馈环节而成。

4.2.2模型图4.2.3模型特点带反馈的瀑布模型在保持原有瀑布模型活动阶段自上而下、相互衔接、逐级下落的次序的同时，增加了反馈环节，当某阶段发现上游缺陷时可通过追溯予以消除或改进。

4.2.4使用场景●适用于需求比较明确，各环节间反馈更新信息较少的项目。

针对烟台海颐软件股份有限公司而言，本模型适合于小型的、推广性质的网站、县级客服、营销管理系统等项目。

4.3V型模型(V-shaped Model)4.3.1模型定义V 形模型也是连续开发模型的一种，有时也被成为快速应用开发模型(RAD)，类似于瀑布模型。

区别在于每个开发阶段有一个测试阶段与之匹配：需求同系统测试，架构设计同集成测试，子系统设计同单元测试。

V 模型是瀑布模型的改进。

4.3.2模型图4.3.3模型特点1)优点●应用和管理简单：为开发阶段定义的进入准则和出口准则可以清楚的定义，对项目进行有效管理的相关评判尺度也可以清楚的定义。

同时，由于软件开发过程的任何一个时间点，相应的文档和代码等都只有一个基线，所以对于配置管理也是一件比较轻松的事情。

●强调测试阶段/过程与开发过程的对应关系：从模型中也可以看出，软件测试是V 模型的重点。

在V 模型生命周期模型中，软件测试的活动是和开发的每个阶段活动对应的。

●可以不考虑过程的反复●不必随时列出管理和支持过程2)缺点：●V 模型在处理风险方面存在不足：假如存在风险或者软件需求方面的大的变更，我们回头去修改前面阶段的框架、设计、代码或测试文档和测试用例等，将需要极大的成本，同时难度也较大。

●软件产品在开发过程中对用户是不可见的：在开发阶段中，用户没有直观的工作产品可以体验，只能是在产品交付之后才能使用。

这导致用户在开发过程中参与的力度不足。

4.3.4适用场景需求是稳定可靠的软件实现方法是成熟的软件结构清晰，模块间的界限明晰结合本组织实际情况，本模型可以被中小规模的系统改造项目所采用。

4.4原型法模型(Prototype Model)4.4.1模型定义原型模型的基本指导思想是在需求阶段开始前或过程中，通过部分实现系统功能的方式，进行快速开发，建立软件中对用户可见的部分，即所谓的原型。

然后基于这个原型，同客户进行沟通、交流，更好的了解客户需求，同时也使开发组对该软件有更好的理解，过程中进行迭代，不断修改这个原型，到了双方都认可的程度，再做详细的分析、设计和编码、测试等，最终开发出客户满意的软件产品。

4.4.2模型图4.4.3模型特点1)优点●直观的表示：在需求定义之前可快速构建系统，构建部分系统实现的原型，构建的系统需求原型可以给予客户一个直观的认识。

●用户反馈：客户直接对系统原型提供反馈，开发可以根据客户对原型提供的反馈，确认系统存在的问题以及系统实现的优点。

可以作为系统开发人员进行系统需求规格的修改，以满足客户实际的需要。

2)缺点：●开发人员和客户对系统需求的了解都不是很深入，存在许多不确定的因素，仍有许多不能关闭的问题。

●原型可能没有包含产品应该包含的各个方面。

●原型可能使用了在实际环境中无法使用的资源比如操作系统。

●原型可能无法处理在满负荷情况下的运行。

●当需求不清楚时可能导致抛弃已开发出的原型，造成原型不能利用，从而导致成本的增加。

4.4.4适用场景●用户技术素养较差，不能清晰的描述其意图，对未来软件的功能和期望不明确，造成项目不明确因素太多；●用户的具体功能需求不明确；●用户定义了软件的一般性目标，但不能标识出详细的输入、处理和输出需求●分析设计人员对应用领域不熟悉；●开发者不能确定算法的有效性、操作系统的适应性或人机交互的形式；●新的产品领域，或者项目包含一种新技术，例：新硬件、新的开发语言、新的系统架构等；●高风险项目;结合本组织的情况，本模型可以适用于新产品开发、WEB网站建设等。

4.5螺旋模型(Spiral)4.5.1模型定义螺旋模型结合了瀑布模型的系统化特点和原型法模型的迭代的特征，并加入两者所忽略的风险分析所建立的一种软件开发模型。

该模型于1998 年由美国TRW 公司（B.W.Boehm）提出。

螺旋模型是一种风险驱动的模型。

软件项目风险的大小作为指引软件过程的一个重要因素。

采用螺旋模型的开发过程，交付的软件系统是通过一系列增量版本的发布组成，早期的增量版本可能是一个纸面上的模型或是一个原型，而最后的增量版本是日渐完善的软件系统。

4.5.2模型图1)优点●包含瀑布模型和原型模型●将阶段分成更细小的块●允许设计的变化●受风险分析的驱动，可降低开发风险●用户可较早看到产品●用户与产品开发紧密相连●经费不必预先分配●需应用保护性活动（软件配置管理和软件质量保证）2)缺点●模型比较复杂，对项目团队的管理能力，特别是风险的管理能力要求较高，同时需要人员，资金，和时间的投入。

4.5.4适用场景●风险是项目中最主要的限制因素●客户无法提出明确的需求●可能发生重大变更的项目●项目规模和资金投入较大的项目●新技术的引入，缺乏相关经验●开发团队要求具备管理经验特别是风险管理经验和技能4.6增量模型4.6.1模型定义增量模型，是具备迭代特征的瀑布模型。

采用该模型，每一个增量的开发过程都采用瀑布模型，产生的结果是新增部分功能或性能。

当使用增量模型时，第一个增量往往是核心产品，即实现了基本的需求；核心产品交用户使用（或进行更详细的复审），使用和/或评估的结果是下一个增量的开发计划，计划中明确了对下一增量版本内容的修改和新增待开发的功能，如此迭代，直至系统整体实现。

增量模型和原型模型的不同之处是其强调每一个增量均要发布一个可操作产品。

4.6.3模型特点1)优点●可快速生产出可使用的系统●在达到初始需求之前可降低成本●客户可将早期的增量作为系统的原型，从中获得对后面系统增量的需求经验●可以减少开发过程中的返工●项目总体性失败的风险比较低。

虽然可能在一些增量中存在问题，但其他的增量会成功交付。

●能够有计划地管理技术风险2)缺点●由于增量模型的灵活性，如果没有完善的配置管理，容易造成边开发边修改，丧失软件的整体性。

●由于在增量实现前，需求不能被详细定义，对确定系统的架构及所有增量都用到的公共服务有一定的影响。

●需要科学合理的进行控制增量规模和配置管理。

过大的增量划分、杂乱的基线管理等都将增加项目的风险。

4.6.4适用场景●项目工期较紧且客户接受分阶段交付的项目;●分析设计人员对应用领域不熟悉或难以全面把握的项目;●已有系统技术路线发生改变但需求明确的移植类项目。

●各种中、大规模的项目类型；结合本组织的情况，本模型可以适用于工期非常紧的项目以及新产品开发。

4.7RUP的迭代模型4.7.1模型定义迭代生命周期模型并不是在开始的时候就将软件的所有需求开发出来。

相反的，从实现软件的某个部分开始，通过对这个部分进行评审来明确更进一步的需要开发的需求。

重复这个过程，在模型的每个周期都生成一个新的软件版本。

迭代式模型是RUP推荐的周期模型。

在RUP中，迭代被定义为：迭代包括产生产品发布的全部开发活动和必需的所有其他外围元素。

RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：初始阶段(Inception)、细化阶段(Elaboration)、构造阶段(Construction)和交付阶段(Transition)。

RUP认为，RUP中的每个阶段可以进一步分解为迭代。