V Model、瀑布模型
v-model是一种软件生存期模型，由Paul Rook在1980年率先提出的，在1990年出现在英国国家计算中心的出版物中，旨在提高软件开发的效率和有效性，是我们熟知的瀑布模型的一种改进，瀑布模型（Waterfall Model）将软件生命周期划分为计划、分析、设计、构建、测试和维护六个阶段，且规定了它们自上而下、相互衔接的固定次序，由于早期的错误可能要等到开发后期的测试阶段才能发现，所以带来严重的后果。 v-model就是在这点改进了瀑布模型，在软件开发的生存期，开发活动和测试活动几乎同时的开始，这两个并行的动态的过程就会极大的较少bug和error出现的机率。在v-model中，我认为一个关键词就是parallel，说起来简单，却是v-model的核心。
v-model包含了三个等级，分别是生存期模型，分配模型，功能性工具需求模型，生存期模型回答了“What has to be done?”的问题，阐述了应当实施哪些活动，应当产生哪些结果，诸如此类。分配模型回答了“How is it be done”，决定了在实施活动的时候应该使用什么方法，功能性工具需求模型回答了“What is used to do it”，采用什么样的工具来实现这些活动。所有这些等级中又是由4个子模块组成的，分别是项目管理模块(PM)，系统开发模块(SD)，品质保证模块(QA)，配置管理模块(CM)，这些模块的功能就显而易见了。
最典型的V模型版本一般会在其开始部分对软件开发过程进行描述，如下图所示：
预验收测试
可行性分析 －－ －－－> 验收测试
↘ 预系统测试 ↗
需求分析 －－－－－> 系统测试
↘ 预集成测试 ↗
概要设计 －－－－> 集成测试
↘ 预单元测试 ↗
详细设计 －－－－－> 单元测试
↘ ↗
编码
单元测试所检测代码的开发是否符合详细设计的要求。集成测试所检测此前测试过的各组成部分是否能完好地结合到一起。系统测试所检测已集成在一起的产品是否符合系统规格说明书的要求。而验收测试则检测产品是否符合最终用户的需求。
V模型的缺陷
仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段
忽视了测试对需求分析,系统设计的验证，一直到后期的验收测试才被发现。
分析每一种生命周期模型优缺点、利用Internet搜索相关软件项目所使用生命周期模型并分析特点，从而更进一步的了解各生命周期模型的适用背景
1. 瀑布模型：
背景：在20实际80年代之前，瀑布模型一直被广泛采用的生命周期模型，现在它仍然是软件工程中应用得最广泛的过程模型。传统软件工程方法学的软件过程，基本上可以用瀑布模型来描述。
特点：
A.阶段间具有顺序性和依赖性：必须等前一阶段的工作完成之后，才能开始后一阶段的工作；前一阶段的输出文档就是后一阶段的输入文档，因此只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。
B.推迟实现的观点：瀑布模型在编码之前设置了系统分析与系统设计的各个阶段，分析与设计阶段的基本任务规定，在这个两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要指导思想。
C.质量保证的观点：软件工程的基本目标是优质、高产。瀑布模型的每个阶段都应坚持两个重要做法：
a.每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。完整、准确的合格文档不仅是软件开发时期各类人员之间相互通信的媒介，也是运行时期对软件进行维护的重要依据。
b．每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。
总之，瀑布模型胡完全依赖于书面的规格说明。
D．可强迫开发人员采用规范的方法；严格地规定了每个阶段必须提交的文档；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。
缺点：
A. 各个阶段产生的文档时维护软件产品时必不可少的，没有文档的软件几乎是不可能维护的。
B. 瀑布模型是由文档驱动的，在可运行的软件产品交付给用户之前，用户只能通过文档来了解产品是什么样的。
C. 由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。
2. 快速原型模型
背景：快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。快速原型模型的第一步是快速建立一个能反馈用户主要需求的原型系统，让用户在计算机上试用它，通过实践来了解目标系统的概貌。通常，用户试用原型系统之后会提出许多修改意见，开发人员按照用户的意见快速地修改原型系统，然后再次请用户试用……一旦用户认为这个圆形系统确实能做他们所需要的工作，开发人员便可据此书写规格说明文档，根据这份文档开发出的软件便可以满足用户的真实需求。
特点：
A. 原型系统已经通过与用户交互而得到验证，据此产生的规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工。
B. 开发人员通过建立原型系统已经学到了许多东西，因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续需要改正前面阶段所犯错的可能性。
C. 快速原型的本质是“快速”。开发人员应该尽可能快地建造出原型系统，以加速软件开发过程，节约软件开发成本。原型的用途是获知用户的真正需求，一旦需求确定了，原型将被抛弃。
缺点：
3. 增量模型
背景：增量模型也成为渐增模型。试用增量模型开发软件时，时把软件产品作为一系列的增量构建来设计、编码、集成和测试。
采用瀑布模型或快速模型开发软件时，目标都是一次就把一个满足所有需求的产品提交给用户。增量模型与之相反，它分批地逐步向用户提交产品，整个软件产品被分解成许多个增量构件，开发人员一个构件一个构件地向用户提交产品。从第一个构件交付之日起，用户就能做一些有用的工作。
特点：
A. 能在较短时间内向用户提交可完成部分工作的产品
B.逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一恶搞全新的软件可能给用户组织带来的冲击。
缺点：
A． 在把每个新的增量构建继承在现有软件体系结构中时，必须不破坏原来已经开发出的产品。
B． 必须把软件的体系结构设计的便于按这种方式进行扩充，向现有产品中加入新构建的过程必须简单、方便，也就是说，软件体系结构必须是开放的。
4. 螺旋模型
背景：软件开发几乎总要冒一定风险，软件风险是任何软件卡发项目中都普遍存在的实际问题，项目越大，软件越复杂，承担该项目所冒的风险也越大。软件风险可能在不同程度上损害软件开发过程和软件产品质量。因此，在软件开发过程中必须及时识别和分析风险，并且采取适当措施一、以消除或减少风险的危害。构建原型是一种能使某些类型的风险降至最低的方法，当然，原型并不能“包治百病”，对于某些类型的风险（例如，聘请不到需要的专业人员或关键的技术人员在项目完成前“跳槽”），原型方法是无能为力的。螺旋模型的基本思想是，试用原型及其他方法来尽量降低风险，理解这种模型的一个简便方法，是把它看做在每个阶段之前都增加了风险分析过程的快速原型模型。
特点：
A. 对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标。
B. 减少了过多测试（浪费资金）或测试不足（产品故障多）所带来的风险
C. 在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别。
D. 它是风险驱动的。
缺点：
A. 螺旋模型主要适用于内部开发的大规模软件项目。
B. 除非软件开发人员具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风险：当项目实际上正在走向灾难时，开发人员可能还认为一切正常。
5. 喷泉模型
背景：迭代式软件开发过程中普遍存在的一种内在属性。经验表明，软件过程各个阶段之间的迭代或一个阶段内各个工作步骤之间的迭代，在面向对象范型中比在结构化范型中更常见。一般来说，使用面向对象方法学开发软件时，工作重点应该放在生命周期中的分析阶段。这种方法在开发的早期阶段定义了一系列面向问题的对象，并且在整个开发过程中不断充实和扩充这些对象。由于在整个开发过程中都使用同一的软件概念“对象”，所有其他概念（例如功能、关系、时间等）都是围绕对象组成的，目的是确保分析工作中得到的信息不会丢失或改变，因此，对生命周期各阶段的区分自然就不重要、不明显了。分析阶段得到的对象模型也适用于设计阶段和实现阶段。由于各阶段都使用统一的概念和表示符号，因此，整个开发过程都是吻合一致的，或者说是“无缝”连接的，这自然就很容易实现各个开发步骤的多次反复迭代，达到认识的逐步深化。每次反复都会增加或者明确一些目标系统的性质，但却不是对先前工作结果的本质性改动，这一久减少了不一致性，降低了出错的可能性。
“喷泉”这个词体现了面向对象软件开发过程迭代和无缝的特性。
特点：
A. 开发过程迭代和无缝。
B. 采用面向对象范型之后，维护时间缩短了。
缺点：
A. 面向对象范型本身要求疆场对开发活动进行迭代或求精。