目录
边做边改模型（Build-and-Fix-Model）
在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户和测试等等满意为止。
优点
：
这是一种类似作坊的开发方式，边做边改模型的优点毫无疑问就是前期出成效快。
缺点
：
对编写逻辑不需要太严谨的小程序来说还可以对付得过去，但这种方法对任何规模的开发来说都是不能令人满意的。
原因在于
- 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；
- 忽略需求环节，给软件开发带来很大的风险；
- 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。
瀑布模式（Waterfall-Model）
特点:
- 严格按照需求 ->分析->设计->编码->测试的阶段进行
- 阶段间具有顺序性和依赖性:
-
- 前一阶段完成后,才能开始后一阶段
- 前一阶段的输出文本为后一阶段的输入文本
- 适合于一些大型稳定的项目
- 推迟实现的观点
- 质量保证:
- 以质量为第一目标
- 每个阶段必须交付出合格的文档
- 对文档进行审核
优点:
- 可以保证整个软件产品较高的质量
- 保证缺陷能够提前的被发现和解决
- 可以保证系统在整体上的充分把握,使系统具备良好 的扩展性和可维护性
缺点:
缺乏灵活性，太过线性理想化，不适合现代软件开发
- 前期就需要把需求做到最全。所以对于前期需求不明确,而又很难短时间明确清楚的项目则很难很好的利用瀑布模型。
- 瀑布模型强调的保证软件的质量,往往忽略人力,时间,资源等成本因素。对于中小型的项目,需求设计和开发人员往往在项 目开始后就会全部投入到项目中,而不是分阶段投入,因此采用瀑布模型会导致项目人力资源过多的闲置的情况
- 惧怕用户测试中的反馈,惧怕需求变更
- 每次需求发生变更都要从头再来
当一个新系统的开发存在多个完全不相关的独立需求的功能开发的时候,这个时候也可以选择将整个开发过程按独立的需求来分为多个小瀑布进行操作.这种方式的最大问题就是没有一个完全总体的设计,架构设计人员无法在洞悉了所有需求后从系统的可扩展性,复用等方面总体规划.
BTW：
很多人往往会以进度约束而不选择瀑布模型,这往往是一个错误的观点.导致这种情况的一个关键因素往往是概念需求阶段人力不足.因此在概念需求阶段人力能 够得到充分保证的情况下,瀑布模型和迭代模型在开发周期上并不会存在太大的差别.反而是很多项目对于迭代或敏捷模型用不好,为了赶进度在前期需求不明确, 没有经过一个总体的架构设计情况下就开始编码,后期出现大量的返工而严重影响进度.
在项目管理中有一种压缩进度的方法叫赶工,因此瀑布模型的另外改进处就在适当的重叠各个阶段过程,达到资源的有效利用.比如我们通过讨论,会议确定的实现方式就可以开始执导下一个阶段的工作而不一定完全等到相关的交付物文档化出来.
螺旋模型（Spiral-Model）
1988年，巴利·玻姆(Barry Boehm)正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。
螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：
（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
（2）风险分析：分析评估所选方案，考虑如何识别和消除风险；
（3）实施工程：实施软件开发和验证；
（4）客户评估：评价开发工作，提出修正建议，制定下一步计划。
特点:
- 需求->架构->设计->开发->测试
- 螺旋模型最大的价值在于整个开发过程是迭代和风险驱动的.通过将瀑布模型的多个阶段转化到多个迭代过程中,以减少项目的风险.
- 软件开发人员应该擅长寻找可能的风险,准确地分析风险,否则将会带来更大的风险
- 适合于前期需求不稳定,后期需求新增变更较多的项目,这是一种增量迭代开发的模型,每一次循环都是一次版本的升级。
- 核心在于您不需要在刚开始的时候就把所有事情都定义的清清楚楚.在定义最重要的功能时,去实现它,然后听取客户的意见,之后再进入到下一个阶段.如此不断轮回重复,直到得到您满意的最终产品
优点:
- 设计上的灵活性,可以在项目的各个阶段进行变更.
- 以小的分段来构建大型系统,使成本计算变得简单容易
- 客户始终参与保证了项目不偏离正确方向以及项目的可控性
- 客户始终掌握项目的最新信息,从而他或她能够和管理层有效地交互.
- 客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品.
缺点:
很难让用户确信这种演化方法的结果是可以控制的.建设周期长,而软件技术发展比较快,所以经常出现软件开发完毕后,和当前的技术水平有了较大的差距,无法满足当前用户需求.
每轮循环包含六个步骤:
- 确定目标,可选项（替代方案）,以及强制条件（约束条件）
- 识别并化解风险
- 评估可选项
- 开发并测试当前阶段
- 规划下一阶段
- 确定进入下一阶段的方法步骤.
模型:
BTW：
螺旋模型实现了随着项目成本投入不断增加,风险逐渐减小.以帮我我们加强项目的管理和跟踪,在每次迭代结束后都需要对产出物进行评估和验证,当发现无法继续进行下去时可以及早的终止项目.
螺旋模型复杂的地方在于尽责,专心和知识渊博的管理.因为对于每一次迭代我们要制定出清晰的目标,分析出相关的关键风险和计划中可以验证和测试的交付物并不是一件容易的事情.
螺旋模型的每一次迭代只包含了瀑布模型的某一个或两个阶段.如第二次迭代重点是需求,第三次迭代是总体设计和后续设计开发计划等.因此这是和RUP（Rational Unified Process，统一软件开发过程）提倡 的迭代模型是有区别的,RUP的每一次迭代都会包含需求,设计,开发和测试等各个阶段的活动.RUP迭代的目的在于逐步求精而不是仅仅完成瀑布模型某一阶 段的工作.
快速原型模型（Rapid-Prototype-Model）
快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。
显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。
快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。
快速原型模型有点整合“边做边改”与“瀑布模型”优点的意味。
优点：
- 生命周期短
- 整合“边做边改”与“瀑布模型”优点
- 减少软件需求不明确带来的开发风险
- 适用于小型、交互型的系统，大型系统的某些部分
缺点：
- 所选用的开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量低下，难以维护。
原型类型:
- 探索型原型:目的是要型清用户的需求,确定所期望的特性,并探索各种方案的可行性。它主要针对开发目标模糊,
- 实验型原型:主要用于设计阶段,考核；实现方案是否合适,能否实陋
- 演化型原型:主要用于及早向用户提交一个原型系统,该原型系统或者包含系统的框架,或者包含系统的主要功能,在得到用户的认可后,将原型系统不断扩充演变为最终的软件系统
原型的运用方式:
- 抛弃策略是将原型用于开发过程的某个阶段,促使该阶段的开发结果更加完整、准确、一致、可靠,该阶段结束后,原型随之作废。探索型和实验型就是采用此策略的。
- 附加策略是将原型用于开发的全过程,原型由最基本的核心开始,逐步增加新的功能和新的需求,反复修改反复扩充,最后发展为用户满意的最终系统,演化型快速原型就是采用此策略
模型:
增量和迭代模型
增量迭代是RUP统一过程常采用的软件开发生命周期模型.增量和迭代有区别但两者又经常一起使用.所以这里要先解释下增量和迭代的概念。假设现在要开发 A,B,C,D四个大的业务功能,每个功能都需要开发两周的时间.则对于增量方法而言可以将四个功能分为两次增量来完成,第一个增量完成A,B功能,第二 次增量完成C,D功能;而对于迭代开发来将则是分两次迭代来开发,第一次迭代完成A,B,C,D四个基本业务功能但不含复杂的业务逻辑,而第二个功能再逐 渐细化补充完整相关的业务逻辑.在第一个月过去后采用增量开始时候A,B全部开发完成而C,D还一点都没有动;而采用迭代开发的时候A,B,C,D四个的 基础功能都已经完成.
增量模型（Incremental-Model）
在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。
增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。但是，增量模型也存在以下缺陷：
- 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
- 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。
在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。
例如，使用增量模型开发字处理软件。可以考虑，第一个增量发布基本的文件管理、编辑和文档生成功能，第二个增量发布更加完善的编辑和文档生成功能，第三个增量实现拼写和文法检查功能，第四个增量完成高级的页面布局功能。
优点：
- 人员分配灵活，一开始不需要投入大量人力
- 先推出核心的产品，在后续增加相应的功能
- 增量能够有计划的管理技术风险
- 适用于需求经常变更的软件开发过程
缺点：
- 如果增量包之间存在相交的情况未很好的处理，则必须做全盘的系统分析
迭代模型（Stagewise-Model）（迭代增量式开发/迭代进化式开发）
在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度（如3周）的小项目，被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。
迭代和版本的区别，可理解如下：迭代一般指某版本的生产过程，包括从需求分析到测试完成；版本一般指某阶段软件开发的结果，一个可交付使用的产品。
优点：
- 降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。
- 降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。
- 加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。
- 由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。因此复用性更高
喷泉模型
（
Fountain-Model
）
以用户需求为动力，以对象为驱动的模型，主要用于采用对象技术的软件开发项目
喷泉模型与传统的结构化生存期比较，具有更多的增量和迭代性质，生存期的各个阶段可以相互重叠和多次反复，而且在项目的整个生存期中还可以嵌入子生存期。就像水喷上去又可以落下来，可以落在中间，也可以落在最底部。
喷泉模型不像瀑布模型那样,需要分析活动结束后才开始设计活动,设计活动结束后才开始编码活动.该模型的各个阶段没有明显的界限,开发人员可以同步进行开发.
优点
:
- 可以提高软件项目开发效率,节省开发时间,适应于面向对象的软件开发过程.
缺点
:
- 由于喷泉模型在各个开发阶段是重叠的,因此在开发过程中需要大量的开发人员,因此不利于项目的管理
- 此外这种模型要求严格管理文档,使得审核的难度加大,尤其是面对可能随时加入各种信息、需求与资料的情况
模型
:
演化模型（Evolutionary-Model）
思想
:
主要针对事先不能完整定义需求的软件开发。用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现。软件开发人员根据用户的需求，首先开发核心系统。当该核心系统投入运行后，用户试用之，完成他们的工作，并提出精化系统、增强系统能力的需求。软件开发人员根据用户的反馈，实施开发的迭代过程。第一迭代过程均由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集。
在开发模式上采取分批循环开发的办法，每循环开发一部分的功能，它们成为这个产品的原型的新增功能。于是，设计就不断地演化出新的系统。 实际上，这个模型可看作是重复执行的多个“瀑布模型”。
“演化模型”要求开发人员有能力把项目的产品需求分解为不同组，以便分批循环开发。这种分组并不是绝对随意性的，而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。有经验指出，每个开发循环以六周到八周为适当的长度。
优点:
- 任何功能一经开发就能进入测试以便验证是否符合产品需求
- 开发中的经验教训能反馈应用于本产品的下一个循环过程,大大提高质量与效率
- 开发中的经验教训能反馈应用于本产品的下一个循环过程,大大提高质量与效率
- 大大有助于早期建立产品开发的配置管理
缺点
:
- 主要需求开始并不完全弄清楚的话,会给总体设计带来困难及削弱产品设计的完整性,并因而影响产品性能的优化及产品的可维护性
- 缺乏严格过程管理的话,这生命周期模型很可能退化为“试－错－改”模式
- 不加控制地让用户接触开发中尚未测试稳定的功能,可能对开发人员及用户都产生负面的影响
敏捷开发模型（Agile-Development-Model）
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷开发小组主要的工作方式：
- 作为一个整体工作；
- 按短迭代周期工作；
- 每次迭代交付一些成果，关注业务优先级，检查与调整。
敏捷开发的4个核心思想：
- 强调面对面的沟通，人和人的相互交流胜于任何流程和工具
- 把精力集中在可执行的程序上，可以运行的产品胜于编制综合性文档，强调了原型、模型、demo等的重要性
- 团队合作和团队激励，合作胜于谈判，敏捷开发能将需求、开发、测试等全部团队成员融合成一个整体，大家都是一条线上的蚂蚱
- 超强的适应能力，适应变化胜于按部就班，敏捷开发的特点就是快速
敏捷软件开发要注意项目规模，规模增长，团队交流成本就上去了，因此敏捷软件开发暂时适合不是特别大的团队开发，比较适合一个组的团队使用。
智能模型（四代技术4GL）
智能模型拥有一组工具（如数据查询、报表生成、数据处理、屏幕定义、代码生成、高层图形功能及电子表格等），每个工具都能使开发人员在高层次上定义软件的某些特性，并把开发人员定义的这些软件自动地生成为源代码。这种方法需要四代语言（4GL）的支持。4GL不同于三代语言，其主要特征是用户界面极端友好，即使没有受过训练的非专业程序员，也能用它编写程序；它是一种声明式、交互式和非过程性编程语言。4GL还具有高效的程序代码、智能缺省假设、完备的数据库和应用程序生成器。目前市场上流行的4GL（如Foxpro等）都不同程度地具有上述特征。但4GL目前主要限于事务信息系统的中、小型应用程序的开发。
混合模型（Hybrid-Model）
过程开发模型又叫混合模型（hybrid model），或元模型（meta-model）,把几种不同模型组合成一种混合模型，它允许一个项目能沿着最有效的路径发展，这就是过程开发模型（或混合模型）。实际上，一些软件开发单位都是使用几种不同的开发方法组成他们自己的混合模型。
大概对比了部分的模型方法
|
模型名称
|
技术特点
|
适用范围
|
|
瀑布模型
|
简单，分阶段，阶段间存在因果关系，
各个阶段完成后都有评审，允许反馈，不支持
用户参与，要求预先确定需求
|
需求易于完善定义且不易变更的软件系统
|
|
快速原型模型
|
不要求需求预先完备定义，支持用户参与，
支持需求的渐进式完善和确认，能够适应用户需求的变化
|
需求复杂、难以确定、动态变化的软件系统
|
|
增量模型
|
软件产品是被增量式地一块块开发的，
允许开发活动并行和重叠
|
技术风险较大、用户需求较为稳定的软件系统
|
|
迭代模型
|
不要求一次性地开发出完整的软件系统，将软件
开发视为一个逐步获取用广需求、完善软件产品的过程
|
需求难以确定、不断变更的软件系统
|
|
螺旋模型
|
结合瀑布模型、快速原型模型和迭代模
型的思想，并引进了风险分析活动
|
需求难以获取和确定、软件开发风险较大的软件系统
|
一个有趣的介绍：
参考资料：
