软件开发模型（SSD9 Life-Cycle Methodologies ）

文章来源http://hi.baidu.com/%D0%D0%D7%DF%D4%DA%BF%D5%D6%D0/blog/item/7bbb261bc20988f2af513319.html

1. 编码修补模型（Build-and-Fix Model）

实现产品既没有需求或规格说明书也没有设计方面的尝试，开发者简单的将代码拼凑在一起，软件随着客户的需要一次又一次地不断被修改. 在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。 这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：

　　（1） 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；

　　（2） 忽略需求环节，给软件开发带来很大的风险；

　　（3） 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。

2.瀑布模型（Waterfall Model）

瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。在任何阶段的文档完成并且该阶段产品被客户和SQA小组认可前，该阶段都是没有完成的。每个阶段都包含测试，他是靠文档驱动的，强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于：

　　（1） 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；

　　（2） 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；

　　（3） 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

3.快速原型模型（RAPId Prototype Model）

第一步是建立快速原型，让用户或客户试用，如果客户认为满足大多数要求，开发者就拟定规格文档。第二步则在第一步的基础上开发客户满意的软件产品。快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。

4.增量模型（Incremental Model）

在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成.。增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。但是，增量模型也存在以下缺陷：

　　（1） 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。

　　（2） 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。

在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。

5.同步--稳定模型（Synchronize-and-Stabilize Model）也被称为微软模式

将工作分为3或4个构件，每个构件由小组单独完成，每天工作结束，把部分完成的组件放在一起，测试和调试得到的产品（同步）。在每个构件结束时进行稳定化工作，修补至今遗留的错误，并将该构件冻结（即规格不再修改）。这种模型只在微软公司取得成功。

6.螺旋模型（Spiral Model）

它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。可以简单的将他看做是每个阶段前带有风险分析的瀑布模型，在开始每个阶段前努力减少风险，如果不能减少重大风险，则该项目停止。螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。但是，螺旋模型也有一定的限制条件，具体如下：

　　（1） 螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。

　　（2） 如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。

　　（3） 软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险 。

7.喷泉模型（Object-Oriented Life-Cycle Models）

喷泉模型与传统的结构化生存期比较，具有更多的增量和迭代性质，生存期的各个阶段可以相互重叠和多次反复，而且在项目的整个生存期中还可以嵌入子生存期。就像水喷上去又可以落下来，可以落在中间，也可以落在最底部。 该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。

各模型的比较（Comparison of the Models）

Life-Cycle Model	Strengths	Weaknesses
Build-and-Fix	Fine for short programs that do not require maintenance	Totally unsatisfactory for nontrivial programs
Waterfall	Disciplined; Document-driven	Product may not meet customer needs
Rapid Prototyping	Ensures product will meet client's needs	Temptation to reuse code that should be reimplemented instead
Incremental	Maximized early return on investment; Promotes maintainability	Requires open architecture; May degenerate into build-and-fix
Synchronize-and-Stabilize	Future users' needs are met; Ensures components can be integrated	Has not been widely used outside Microsoft
Spiral	Incorporates features of all the models above	Can be used only for large-scale, in-house projects; Developers must be competent in risk management
Object-Oriented	Supports iteration within phases, parallelism between phases	May degenerate into CABTAB