标签：sel 质量 类型 代码片段 应用 审核 文件 body 准备
瀑布模型、原型模型、螺旋模型、迭代模型、增量模型
瀑布模型-最早出现的软件开发模型
是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。
将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
优点：它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
适用于需求固定的项目
缺点：开发周期长，开发成本昂贵
对于需求不明确经常变化的项目而言，瀑布模型毫无价值。
各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
开发模式是线性的，必须严格按顺序进行软件开发。只有完成当前阶段工作才能开始下一阶段工作。
早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
瀑布模型的阶段划分，软件测试可以分为单元测试，集成测试，系统测试。
V模型：强调软件开发的协作和速度，将软件实现和验证有机地结合起来，在保证较高的软件质量情况下缩短开发周期
左边是软件设计与实现的过程。同时伴随着质量保证活动——审核的过程。
右边是对左边结果的验证，是动态测试的过程，即对设计和分析的结果进行测试，以确认是否满足用户的需求。
需求分析定义--验收测试（审查需求分析的结果，从而了解产品的设计特性、用户的真正需求，确定测试目标，可以准备用例(Use Case)并策划测试活动。）
系统设计--------系统测试（测试人员可以了解系统是如何实现的，基于什么样的平台，这样可以设计系统的测试方案和测试计划，并事先准备系统的测试环境，包括硬件和第三方软件的采购。因为这些准备工作，实际上是要花去很多时间。）
详细设计--------功能测试（测试人员可以参与设计，对设计进行评审，找出设计的缺陷，同时设计功能、新特性等各方面的测试用例，完善测试计划，并基于这些测试用例以开发测试脚本。）
编码--------------单元测试（软件中最小可测试单元。一般采用白盒测试(保证模块中所有独立路径至少执行一次）。java中指类，c中指函数，图形化软件中指窗口或菜单。
在软件开发时尽可能多的发现Bug，软件修改成本很低。
在软件开发的后期阶段，Bug的发现并修改将会变得更加困难，并要消耗大量的时间和开发费用）
单元测试需要了解程序的内部结构，测试用例是根据程序的内部逻辑来设计的。充分单元测试可以减少开发成本。
快速原型模型：也称演化模型。对需求进行初步而非完全的分析和定义，快速开发出可以运行的软件原型（一般是已有软件产品为原型）。不断获取与完善客户需求，对软件原
型进行修改完善，最终开发出符合用户需求的软件
优点：克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险。
适合预先不能确切定义需求的软件系统的开发。
缺点：快速建立起来的系统结构加上连续的修改可能导致产品质量低下。
使用这个模型的前提是要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。
各个阶段的类型：
探搜型原型：应用于需求分析阶段。主要针对开发目标模糊，用户与开发都对项目都缺乏经验的情况，通过对原型的开发来明确用户的需求。
实验型原型：这种原型主要用于设计阶段，考核实现方案是否合适，能否实现。对于一个大型系统，若对设计方案心中没有把握时，可通过这种原型来证实设计方案的正确性。
演化型模型：这种原型主要用于及早向用户提交一个原型系统，该原型系统或者包含系统的框架，或者包含系统的主要功能，在得到用户的认可后，将原型系统不断扩充演变为最终
的软件系统。它将原型的思想扩展到软件开发的全过程。
螺旋模型：软件开发是一系列的增量发布，逐步产生更完善的版本，强调风险分析
它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控，并增加了风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。
优点：
缺点：
迭代模型：分阶段进行，每个阶段都执行一个传统的，完整的串行过程，其中都包括不同比例的需求分析、设计、编码和测试等活动。
在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度（如3周）的小项目，被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。
教学中，对迭代和版本的区别，可理解如下： 迭代一般指某版本的生产过程，包括从需求分析到测试完成； 版本一般指某阶段软件开发的结果，一个可交付使用的产品。
与传统的瀑布模型相比较，迭代过程具有以下优点：
1）降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。
2）降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。
3）加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。
增量模型（Incremental Model）
与建造大厦相同，软件也是一步一步建造起来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。
增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。但是，增量模型也存在以下缺陷：
1） 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
2） 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。
在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。
例如，使用增量模型开发字处理软件。可以考虑，第一个增量发布基本的文件管理、编辑和文档生成功能，第二个增量发布更加完善的编辑和文档生成功能，第三个增量实现拼写和文法检查功能，第四个增量完成高级的页面布局功能。
各种软件过程模型的特点
| 模型名称 | 技术特点 | 适用范围 |
|---|---|---|
| 瀑布模型 | 简单，分阶段，阶段间存在因果关系，
各个阶段完成后都有评审，允许反馈，不支持 用户参与，要求预先确定需求 |
需求易于完善定义且不易变更的软件系统 |
| 快速原型模型 | 不要求需求预先完备定义，支持用户参与，
支持需求的渐进式完善和确认，能够适应用户需求的变化 |
需求复杂、难以确定、动态变化的软件系统 |
| 增量模型 | 软件产品是被增量式地一块块开发的，
允许开发活动并行和重叠 |
技术风险较大、用户需求较为稳定的软件系统 |
| 迭代模型 | 不要求一次性地开发出完整的软件系统，将软件
开发视为一个逐步获取用广需求、完善软件产品的过程 |
需求难以确定、不断变更的软件系统 |
| 螺旋模型 | 结合瀑布模型、快速原型模型和迭代模
型的思想，并引进了风险分析活动 |
需求难以获取和确定、软件开发风险较大的软件系统 |
| RUP | 可改造、扩展和剪裁：可以对它进行设计、
开发、维护和发布；强调迭代开发 |
复杂和需求难以获取和确定的软件系统；
软件开发项目组拥有丰富的软件开发和管理经验
|
参考资料：
迭代模型 ．智库百科
标签：sel 质量 类型 代码片段 应用 审核 文件 body 准备
原文地址：http://www.cnblogs.com/gne-hwz/p/7487063.html
