2.2六个传统软件模型：瀑布、V模型、原型、增量、螺旋、喷泉
2.2传统软件模型 瀑布、V模型
瀑布模型
由于瀑布模型规定的软件开发过程与软件生命周期一致，因此瀑布模型也称为经典生命周期模型。
注：瀑布模型一直被用来规范软件开发活动，很多后续其它模型都是在瀑布模型基础上的改进。
特点
瀑布模型是一种线性模型，各个阶段按照顺序依次进行，下一阶段依赖于上一阶段的结果。编码处于软件开发的中后期，体现了推迟实现的观点，强调需求分析和系统设计的重要性。
瀑布模型以文档为驱动，每个阶段都有与其相关联的里程碑和可交付产品。每个阶段都会产生相应的报告。每个阶段结束前都会进行文档审查，及早改正错误。
实际（带反馈）的瀑布模型
实际使用中，是带反馈的。
开发过程的后面的总会返回到上一级。例如：总体设计阶段发现需求错误，则反馈到需求分析阶段；详细设计阶段发现总体设计错误，则反馈到总体设计阶段。
但对软件的维护则反馈到相应的阶段。例如：若错误原因在于编码，则反馈到编码阶段；如果错误原因在于设计，则反馈到设计阶段；如果错误原因在于需求，则反馈到需求分析阶段。
缺点
- 瀑布模型中，各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
- 由于瀑布模型的开发过程是线性的，用户只有等到整个过程的末期，也就是编码和测试完成后，才能见到开发成果，增加了开发的风险；
- 早期的错误，比如需求分析的错误或者总体设计的错误，可能要等到开发后期的测试阶段才能发现，进而带来严重的后果，导致修复错误代价的剧增，甚至无法修复；
- 现代软件开发通常需要迭代，而瀑布模型是线性模型，不支持迭代，无法适应软件开发中的变化；最严重的是，需求不明确和需求变化是软件开发中的客观事实，但由于瀑布模型的线性特征，无法应对需求不明确和需求变化带来的影响。
适用场景
系统需求明确且稳定、技术成熟、工程管理较严格的场合，如军工、航天、医疗。能保证这些的高质量完成。
V模型（V-model）
是瀑布模型的变种。
在V模型中，处于顶端的是编码，左侧是分析设计阶段，右侧是测试运维阶段。该模型将测试的各个阶段和分析设计的各个阶段关联起来，单元测试验证详细设计，系统测试验证总体设计，验收测试验证需求分析。
V模型中发现问题
单元测试发现问题
如果在单元测试发现错误，则需要检查相应模块的详细设计，修改相应模块的代码，并重新进行单元测试。
系统测试发现问题
如果在系统测试中发现错误，则需要检查总体设计，检查可疑模块的详细设计，对错误模块进行代码修改，然后进行错误模块的单元测试，通过后再次进行系统测试。
验收测试发现问题
如果在验收测试中发现问题，则需要检查系统需求，然后检查系统总体设计，然后检查可疑模块的详细设计，对错误模块进行代码修改，然后进行错误模块的单元测试，单元测试通过后再次进行系统测试，系统测试通过后再次进行验收测试。
原型模型（Prototype model）
也称为原型化模型、快速原型模型
由于原型构建处于真正的系统开发之前，为了满足软件进度要求，要求原型构建过程要快，因此也称为快速原型模型。
原型
一个部分开发的产品，就是只开发了一部分。
作用
通过这个部分开发的产品，客户和开发人员能够对计划开发的产品的相关方面进行检查，以明确需求或者确定方案的可行性。
原型最终去向
根据原型质量和项目计划，可以选择抛弃原型或者把原型发展成最终产品。
例
例1 只做出了图书借阅系统的主要界面
例2 智能家居系统：只做出了少量的室内信息监视和电器控制
原型化的目的
- 明确并完善需求，通过演示原型实现，如图书借阅系统中的主要界面；
- 研究技术选择方案，通过技术验证原型实现，如智能家居系统中的部分监视和控制。
原型模型的阶段
共两个阶段：原型构建阶段、系统开发阶段。
原型模型构建阶段
原型构建阶段开始于策划原型需求，然后构建原型系统，部署原型系统，基于原型系统和客户沟通，明确需求或验证方案。如果用户不满意，则修改原型需求，修改原型系统，重新部署原型系统，再次和客户沟通，经过多次迭代，直到用户满意，才进入系统开发阶段。
系统开发阶段
按照正常的开发过程：进行需求分析，设计，实现，测试和维护。
原型模型的优缺点
优点
由于通过构建原型来明确需求，能减少需求不明确带来的风险
缺点
•由于构建原型要求快，构造原型采用的技术和工具不一定主流
•快速建立起来的系统加上连续的修改可能导致原型质量低下
•设计者可能需要在质量和原型中进行折中，可能产生客户意识不到一些质量问题
——“如果抛弃原型，则开发时间延长，若将原型发展成最终产品，则系统可能会存在一些客户意识不到的质量问题。”
适用场合
1、当客户定义一个总体目标集，但并不清楚系统的具体输入和输出
2、开发者不确定算法的效率、软件与操作系统是否兼容以及客户与计算机交互的方式等情况
增量模型（Incremental model）
增量
类似于原型，满足用户需求的一个子集，是能够完成一定功能、小而可用的软件
增量与原型的区别
都是系统的一部分，但是它们的构建原因不同和最终结局不同。
原型构建：明确需求或验证方案，最终可能会被抛弃
增量：是实际开发过程和最终系统的一部分
增量模型例子：文字处理软件的功能发布
文字处理软件：实现三个功能——创建文本、组织文本、格式化文本。依次实现每一个增量到发布的功能的转变，这时系统所有增量开发完成，系统开发完成。
增量模型开发阶段
增量开发1：先对整体分析设计
- 首先对整个系统进行需求分析和体系结构设计
- 根据增量的划分，分别对每个增量进行设计、编码、测试、交付，从而形成每一次发布。
- 增量的开发允许一定程度的并行，每一次发布都是在上一次发布的基础上增加新的增量。
- 当所有的增量开发并发布完成，则形成系统最终产品。
- 为了保证每个增量都能正确集成到系统中，增量模型要求系统体系结构具有开放式结构。
增量开发2：不对整体分析设计
如果在软件开发初期无法确定软件所有需求，则可以采用这种方式进行增量开发：
- 不进行整个系统的需求分析和体系结构设计，而是针对每个增量分别进行需求分析、设计、编码、测试、交付，形成每一次发布。
- 当所有增量开发完毕并成功集成，则形成系统最终产品。
- 由于没有进行整体的需求分析和系统体系结构设计，后面的增量有可能无法集成到前面的发布中，风险较大。
增量的方式
增量的方式可以采取两种：增量方式或者迭代方式。
增量方式
每个增量是一些新功能，通过增加新功能来增加增量，
迭代方式
每个增量是对一些功能的改进，通过改进功能来增加增量
增量和迭代方式举例
注：实际使用中，常常是两种方式的结合。
增量模型的特点
-
增量模型是一种非整体开发的模型，是一种进化式的开发过程
-
增量模型从部分需求出发，先建立一个不完整的系统，通过测试运行这个系统取得经验和反馈，进一步使系统扩充和完善
-
如此反复进行，直至软件人员和用户对所设计的软件系统满意为止
-
增量模型结合了原型模型的基本要素和迭代的特征，采用了基于时间的线性序列，每个线性序列都会输出该软件的一个“增量”
-
每个增量的开发可用瀑布或快速原型模型
优点
- 增量概念的引入，使得不需要提供完整的需求，只要有一个增量出现，开发就可以进行，软件能够更早投入市场。
- 在项目初期，由于只开发部分系统，不需要投入太多的人力物力。
- 整个开发过程中，产品逐步交付，软件开发能够较好地适应需求的变化，同时能够看到软件中间产品，提出改进意见，减少返工，降低开发风险。
- 增量模型要求系统具有开放式体系结构，以便于增量的集成，同时也便于维护。
缺点
- 每个增量必须提供一些系统功能，这使得开发者很难根据客户需求给出大小适合的增量。
- 其次，软件必须具备开放式体系结构，这在实践中往往是困难的。
- 如果不能进行良好的项目管理，采用增量模型的开发过程很容易退化成边做边改的方式，使软件过程控制失去整体性，从而导致软件开发失败。
适用场合
- 软件开发中需求可能发生变化、具有较大风险的项目
- 或者希望尽早进入市场的项目。
螺旋模型
把开发活动和风险管理结合起来控制风险
控制风险
前面课程中讲到的原型模型通过原型化降低需求不明确带来的风险，增量模型通过产品逐步交付降低需求变化带来的风险，但是当软件项目具有更大更多风险时，这些方法是不够的。
在软件开发过程中加入风险管理。
软件开发普遍存在风险，例如，最终交付的产品用户不满意，产品不能按期交付，开发成本超过了预算，产品开发期间关键人员离职，产品投入市场前竞争对手发布了功能相近价格更低的产品，等等。如何应对这些风险对软件项目的成功开发至关重要。
特点
- 开发过程分成若干次迭代，每次迭代代表开发的一个阶段，对应模型中一条环线
- 每次迭代分成四个方面的活动，对应笛卡尔坐标的四个象限：
- 经过若干次迭代后，完成项目开发。
展开：继承了瀑布模型和原型模型的特点
如果将螺旋模型展开，它实际上是瀑布模型，其中每个阶段加入了原型化过程，因此螺旋模型结合了瀑布模型和原型模型的特点。
以图为例：
-
第一次迭代，即第一条环线，产生操作概念
-
第二次迭代，即第二条环线，产生软件需求
-
第三次迭代产生软件设计
-
第四次迭代产生软件实现。
每一次迭代都首先进行预算、方案、约束，然后进行风险分析，并通过原型化进行验证，降低或消除风险；如果风险可消除，则继续进行开发验证，形成本阶段成果；最后计划下一阶段。
优点
1、螺旋模型强调原型的可扩充性和可修改性，原型的进化贯穿整个软件生存周期，这将有助于目标软件的适应能力，支持用户需求的动态变化；
2、原型可看作可执行的需求规格说明，易于为用户和开发人员共同理解，还可作为继续开发的基础，并为用户参与所有关键决策提供了方便；
3、螺旋模型为项目管理人员及时调整管理决策提供了方便，进而可降低开发风险。
缺点
- 由于每次迭代都会进行复杂的风险管理，如果每次迭代的效率不高，致使迭代次数过多，将会增加成本并推迟交付时间；
- 使用该模型需要有相当丰富的风险评估经验和专门知识，要求开发队伍水平高，否则会带来更大风险。
适用场合
- 螺旋模型适用于需求不明确或者需求可能发生变化的大型复杂的软件系统，也就是风险较大的复杂系统。
- 由于其复杂的项目管理，简单的软件系统不建议使用螺旋模型。
- 螺旋模型支持面向过程、面向对象等多种软件开发方法，是一种具有广阔前景的模型。
喷泉模型（Fountain model）
喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程
软件开发早期定义对象，整个开发过程充实和扩充对象
各个阶段使用统一的概念和表示方法，生命周期各阶段无缝连接
各个开发步骤多次反复迭代
一共五个阶段
各个开发阶段使用统一的概念和表示方法，因此各阶段之间无缝连接。各个开发阶段可以多次反复迭代，最终开发出完整的系统。
优点
喷泉模型的各个阶段没有明显的界限，开发人员可以同步进行开发，可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。
缺点
- 由于喷泉模型在各个开发阶段是重叠的，在开发过程中需要大量的开发人员，因此项目管理麻烦。
- 喷泉模型要求严格管理文档，使得审核的难度大，尤其是面对可能随时加入的各种信息、需求与资料的情况。
适用场合
面向对象开发
