软件生命周期模型定义与选择策略(模型项目生命周期需求开发)

☆规范项目开发流程；

☆提高产品质量；

☆降低项目管理难度；

☆为过程改进和度量提供基线；

☆增强项目可控性和可视性。

用于软件项目在项目规划时根据项目特点确定项目的主要阶段及开发模型。
每个软件开发项目可以在本规范定义的生命周期模型范围内，选择不同的生命周期模型，也可以通过裁剪标准适当的裁剪生命周期模型，使之更加适合于项目。

1.3.1 软件生命周期：是指从开始策划软件产品到该软件不在使用为止这段时间。
典型的软件生命周期包括策划阶段、需求分析阶段、设计阶段、实现阶段、测试阶段、实施和维护阶段。

1.3.2 软件生命周期模型：是指对软件工程活动的组织方式。
公司软件过程体系中定义的软件工程过程活动包含了需求、设计、实现、测试和维护等活动。
软件生命周期模型通过确定软件开发活动的顺序及相互制约关系来保证软件工程活动的流程化。

1.3.3 选择软件生命周期模型：选择一个适当的软件生命周期对项目来说至关重要。
在项目策划的初期，就应该确定项目所采用的软件生命周期模型，统筹规划项目的整体开发流程。
选择合适的软件生命周期模型要考虑项目的特点，主要是指不确定性及项目的风险。
选择恰当的生命周期模型可以提高开发效率、提升产品质量、降低成本，控制风险，有助于项目的成功。

瀑布模型最早由Winston Royce于1970年提出， 瀑布模型有时也称为线性模型或典型生命周期模型，在该模型中软件生命周期的各项活动始终按照固定顺序执行：需求分析、设计、编码、测试、维护，各活动之间有明确的界限，对阶段结束的成果进行判断以确定是否可以开始下一阶段的工作，最终得到软件产品。
瀑布模型可以说是所有软件生命周期模型的基础。

瀑布模型的核心思想是将软件开发划分为若干阶段，按线性顺序执行，至于究竟要划分为多少个阶段，各阶段做什么，应该根据实际情况来定。

瀑布模型是一种文档驱动模型，主要的工作产品通过文档从一个阶段传递到下一阶段。
当项目有着明确的产品定义以及易于理解的技术方案的情况下，瀑布模型有助于及早发现问题，降低阶段成本。

瀑布模型的主要特点：

1、简单、易于理解；

2、要求严格的管理，包括周密的项目计划、明确的交付物、严格的质量控制手段（如阶段的评审）等；

3、客户在项目的后期才可以见到产品以及判断产品的质量；

4、强调产品的测试。

瀑布模型具有以下缺点：

1、缺乏灵活性

瀑布模型要求在项目的初期明确定义全部需求，然而客户在项目初期很难明确描述所有的需求，这种不确定性难以满足模型要求的“稳定的、明确定义的需求”的要求。
事实上，在设计完成和代码完成之前很难充分描述需求，因为客户只能在最后阶段看到产品，产品是否满足客户的真正需求只有此刻才可以得以检验。
因此是否满足客户真正需求的风险往往只能在开发过程后期才暴露，相应的修改成本巨大。

2、开发人员常常陷入“阻塞状态”，一部分成员不得不停下来等待别人把前头的工作干完。

3、对于要求快速开发的项目，瀑布模型可能导致过多的文档。

4、由于是线性单一流程，开发中的经验教训不能反馈应用于本产品的过程。

尽管瀑布模型有许多缺点，但其仍然被广泛使用。
它能提供项目开发人员清晰的开发思路，此外，可以将此模型与其它模型融合修正以适应项目的实际需要。

1、适合有稳定的产品定义和易于掌握的技术方案的项目。

2、适合处理易于理解但复杂的项目。

3、适合质量需求高于进度和成本需求的项目。

4、适合项目的开发队伍的技术力量和项目管理比较薄弱或缺乏经验的情况。

V字模型类似于瀑布模型。
区别在于每个开发阶段有一个测试阶段与之匹配：需求同系统测试，概要设计同集成测试，详细设计同单元测试。
V字模型是瀑布模型的一种改进。
它将瀑布模型的测试阶段进行细分，并与前面的阶段进行对应。
细分出来的这些阶段分别为：单元测试阶段、集成测试阶段和系统测试阶段。

2.2.2 模型特点

1、V字模型使用简单。

2、主要强调测试阶段与开发过程的对应关系。

1、充分理解用户需求，且认为该需求是固定不变的。

2、充分理解该解决方案的技术和体系。

3、需要一个高可维护性和可支持性的解决方案。

4、适合于需求明确的，进行外包的项目。

原型模型是在需求阶段开始前或过程中，通过部分实现系统功能的方式，进行快速设计，建立软件中对用户可见的部分，即“原型”。
原型由用户评估，并据此进一步精化待开发软件的需求，逐步调整原型使其满足用户的要求，同时也使开发组对该软件有更好的理解，这个过程是迭代的。

快速原型的特色体现在“快速”上。
原型内部结构及其实现并不重要，重要的是原型必须能被快速的开发出来，以迅速反映用户的需求。
一旦需求明确了，原型就完成了使命，应该保留还是抛弃，就看此原型是否值得复用。

2.3.2 模型特点

1、在需求定义之前可快速构建系统。

2、用户可向开发者提供反馈。

3、根据用户反馈意见修改系统需求以满足用户需要。

快速原型模型缺点：

由于原型开发的目的是尽快实现系统对客户可见的部分，传达项目组对客户需求的理解并得到客户的反馈进而改进软件需求，因此，往往对原型中采用的操作系统、编程语言的可行性和效率以及算法的效率等缺乏充分的考虑，因此，是否将原型作为后续开发的基础要根据各项目的实际情况确定。

1、需求在开发前不清晰。

2、需要减少项目需求的不确定性带来的风险。

3、研发新产品。

快速原型模型通常与其他生命周期模型结合使用，例如，可以先用快速原型模型确定用户的真正需求，然后采用瀑布模型进行正式的产品开发。

增量开发模型由若干个开发序列组成，每个序列均采用瀑布模型来开发可以发行的增量。
每产生一个增量相当于推出一个新版本。
这个过程不断的重复，直到产生最终完善的产品。

2.4.2 模型特点

1、在达到初始需求之前可降低成本。

2、可快速生产出可使用的系统。

3、客户可将早期的增量作为系统的原型，从中获得对后面系统的增量的需求经验。

4、可以减少开发过程中的返工。

5、项目总体性失败的风险比较低。

6、能够有计划的管理技术风险。

增量模型的缺点是，由于在增量实现前，需求不能被完整定义，对确定系统的架构及所有增量都用到服务有一定的影响。
对系统设计师的水平要求比较高。

1、熟悉问题领域（可以在开发初期将架构及需求稳定下来）。

2、项目团队有丰富的设计及开发经验。

3、增量式的功能发布对客户具有很高的价值。

迭代式模型是RUP(Rational Unified Process)推荐的周期模型，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。
所以在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。
实质上，它类似小型的瀑布式项目。
RUP认为，所有的阶段（需求及其它）都可以细分为迭代。
每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。
迭代的思想如下图所示。

在迭代式模型中，集成可以说是连续不断的，每一次迭代都会集成一些新的系统功能，但要集成的元素都比过去少得多，所以工作量和难度都是比较低的。
另外，迭代式开发模型还可以帮助企业尽早降低软件开发风险，提高IT团队士气以及生成更高质量的产品。
由于每次迭代都会产生一个可运行的系统，通过对这个可运行系统进行测试，企业在早期的迭代中就可以及时发现缺陷并改正，性能上的瓶颈也可以尽早发现并处理。
因为在每次迭代中总是不断地纠正错误，企业可以得到更高质量的产品。

2.5.2 模型特点

迭代式模型解决的主要是对于风险的控制问题，传统的开发流程中系统的风险要到项目开发的后期（主要是测试阶段）才能够被真正降低。
而迭代式开发中的风险可以在项目开发的早期通过几次迭代尽早地解决。
因此，在大型应用软件的开发过程中，企业应尽量采用迭代方式，把要开发的应用软件分成数个可以完成的阶段性目标，以降低企业软件开发风险。

1、可以在生命周期早期强制性的确定项目中存在的风险。

2、采用迭代的、增量式的开发过程。

3、采用UML语言描述软件开发过程。

迭代和瀑布的最大的差别就在于风险的暴露时间上。
“任何项目都会涉及到一定的风险。
如果能在生命周期中尽早确保避免了风险，那么您的计划自然会更趋精确。
有许多风险直到已准备集成系统时才被发现。
不管开发团队经验如何，都绝不可能预知所有的风险。
”

1、在生命周期的早期，这种方法可以及时地发现一些严重的需求理解错误，此时还可能修正这些错误。

2、允许并鼓励用户反馈信息，以明确系统的真实需求。

3、这种方法使开发小组重视项目中关键的问题，而屏蔽掉那些使他们远离项目真实风险的问题。

4、不断地迭代测试能够给出项目状况的客观评价

5、尽早地发现需求、设计和实现中的不一致。

6、在整个项目生命周期中更加平均地分配开发组的工作量，特别是测试小组的工作量。

7、开发组可以不断的在开发中进行学习从而改进过程。

8、在整个生命周期中，项目相关人员可以通过具体证据了解项目状况。

需要强调的是，并不是企业应用迭代模型开发软件后就万无一失，如果对迭代模型本身缺乏严格的过程管理，生命周期模型很可能退化为一种原始的无计划的“试－错－改”的模式。

选择软件项目的生命周期模型的过程如下图所示：

主要步骤如下：

1）、分析并确定项目特点；

2）、根据项目特点识别评估项目风险和需求清晰度；

3）、根据对项目目标、风险和需求清晰度的综合分析结果确定软件生命周期选择策略；

4）、根据选择策略选择并裁剪生命周期模型；

5）、评审选定的软件生命周期模型。

软件生命周期模型的选择首先要考虑项目的特点，包括：

1、资源的可用性（包括人、资金、设施、工具）；

2、项目复杂度（如子系统数量、新技术的使用）；

3、开发成本（包括人力、物力、资金等）；

4、需求的清晰度（需求是否明确、是否逐渐变更、性能要求）；

5、软件产品版本要求（以后是否升级、是否逐渐变更、版本重用性要求）；

6、项目风险分析。

根据项目特点识别、分析项目的风险，评估需求清晰度（需求是否全面、明确等），不同的生命周期模型在应对风险和需求不确定性方面的能力是不同的。

例如螺旋模型是一种以风险为导向的模型，确保随着项目成本投入的增加，风险程度得到降低；而瀑布模型对风险的应对能力相对较弱，采用瀑布模型的项目中可能遗留关键的项目风险在项目后期才能暴露出来，而这种风险的发生带来的损失比项目前期引起的损失大得多。
当然，风险和需求不确定性的管理需要投入项目资源，并对项目团队提出了相应的要求，如风险管理的能力和技能的要求、项目计划和跟踪与监督的要求等，所以风险和需求清晰度大小是选择软件生命周期模型的重要因素，但不是绝对的。

根据对项目特点、风险、需求清晰度的分析，结合下表中对生命周期模型特性的比对说明，确定要选用的生命周期模型。

模型

特性

瀑布模型

V字模型

快速原型

增量模型

迭代模型

项目复杂度

低

低

中

高

高

项目成本

低

低

低

中

高

版本升级成本

高

高

低

低

低

易使用性

简单

简单

简单

复杂

复杂

应用功能需求

明确

明确

不明确

较明确

不明确

渐进式的需求变更

小

小

小

大

大

产品开发技术

存在

存在

新

存在

新

生产率

高

高

低

高

高

质量成本

高

高

低

低

低

项目质量手段

返工

返工

一次

一次

一次

阶段产品的重用性

低

低

低

高

高

需求的不确定性

否

否

是

是

是

项目寿命

—

—

短

长

长

风险及项目管理

能力要求

一般

一般

一般

高

高

项目进展可视性

差

差

一般

好

好

1、一个项目在不同的阶段可根据需要使用不同的生命周期模型。
例如，在项目需求阶段使用快速原型模型；在设计和编码阶段使用V字模型；在测试活动中使用瀑布模型；在系统维护时使用增量模型或迭代模型。

2、对于每种模型本身，也可根据项目特点对模型自身进行裁剪，例如，在使用V字模型时，如果是软件系统移植类的项目，可以只选择设计、编码与单元测试、系统测试等工作阶段。