草记瀑布模型和螺旋模型

     早在学习<软件工程>的时候就知道了描述软件开发过程的瀑布模型和螺旋模型，但是对其了解却是不甚了了。随着工作中项目实施遇到的困惑和思考，对这两个模型也渐渐有了些许体会。

     首先，这两个模型不是用来描述软件的开发或产品形态，而都是描述软件工程在"时间轴"上的纵向演进过程。

瀑布模型（Waterfall Model）

     1970年温斯顿•罗伊斯（Winston Royce）提出了著名的“瀑布模型”，提供了软件开发的基本框架。瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。就像唱的一样：这是最美的传说，在我心里，你就是唯一。

瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动，同时评审该项活动的实施。

     但是瀑布模型的线性过程确实太理想化了，我的体会主要有以下几点：

    （1）它的线性属性决定了只有等到整个过程的末期才能见到开发成果，然而在软件项目实施时，主管和客户通常希望很快看到一个原型产品；

    （2）前几个阶段的产出都是文档性质的，而项目分析和设计时，某些技术需求很可能是超出分析和设计人员的当前能力的，关键技术无法做到预先的验证，增加了开发的风险；

    （3）当项目需求经常变化时，瀑布模型的响应显得似乎过于臃肿。可能对于任何软件模型，项目需求变动的响应都是一个棘手的问题，而不应该仅仅是诟病瀑布模型的理由。

     当项目的需求是十分清晰和确定的，而分析和设计人员对业务领域有足够的把握，主管和客户能够接受这种按部就班的方式时，可以说瀑布模型是首选的最为直观和高效的选择。

     然而，现实往往不这么理想，项目需求的变化更是常态，上述三个问题往往是软件开发中经常遇到的问题，这时就需要原型化方法的引入和实施过程中的迭代，于是就产生了螺旋模型。

螺旋模型（Spiral Model）

     1988年巴利·玻姆Barry Boehm正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。

     螺旋模型采用一种周期性的方法来进行系统开发。该模型是快速原型法，以进化的开发方式为中心，在每个项目阶段使用瀑布模型法。这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代。软件开发过程每迭代一次，软件开发又前进一个层次。使用这种模型，项目经理在早期就能够为客户实证某些概念，系统分析和设计人员可以预先验证某些关键技术。

     螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应，因此特别适用于庞大、复杂并具有高风险的系统。

螺旋模型限制条件

    （1）螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，说服一个项目主管拿出资源来解决这些问题，也是相当困难的，因此，这种模型往往适应于内部的大规模软件开发。

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

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

     一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。

     螺旋模型虽然对大型风险软件工程给出了宏观理论上的支撑，但是在实际的工作中，对于中小型的软件工程，我们完全可以使用原型化和迭代思想，根据项目需求、进度要求、人力资源等情况加以权衡，选择最为合适的实施过程，而不是拘泥于螺旋模型的每次迭代步骤。