瀑布模型软件生命周期

导读：
　　
　　瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
　　在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。
　　瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于：
　　（1） 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
　　（2） 由于开发模型是线性的，在项目各个阶段之间极少有反馈,用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；
　　（3） 在项目各个阶段之间极少有反馈,早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
　　纯瀑布模型的缺点是在项目开始的时候，在设计工作完成前和在代码写出来前，很难充分地描述需求·费用·进度·产品，开始就抱怨用户不知道他们自己想要些什么，而且通常把自己扮演的角色给颠倒了。想像一下，你是用户，你向一位汽车工程师详细说明你要的汽车。你告诉工程师，你想要发动机、车身、车窗、方向盘、油门踏板、刹车踏板、紧急刹车、座位，如此等等。但是，你能了解一个汽车工程师制造你要的汽车所需要的全部部件吗？
　　假设你忘记了倒车时要打开的倒车灯。工程师干了6个月，给了你一辆没有倒车灯的车。这时你才说：“啊呀！我忘了说倒车的时候车需要能自动打开的倒车灯了。”
　　工程师跳了起来，“你知道要花多少钱去拆开汽车，将电源线接到车的后面吗？我们得重新设计车后面的面板、插入刹车电缆、加上传感器。这些改变如果不花几个月的话，也得花几个星期的时间！为什么不一开始就告诉我？”
　　你一脸苦相，但它看起来只不过是个小问题，还有其他的问题多得是.....
　　我们应该认识到，"线性"是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复杂的"非线性"问题时，总是千方百计地将其分解或转化为一系列简单的线性问题，然后逐个解决。一个软件系统的整体可能是复杂的，而单个子程序总是简单的，可以用线性的方式来实现，否则干活就太累了。线性是一种简洁，简洁就是美。当我们领会了线性的精神，就不要再呆板地套用线性模型的外表，而应该用活它。例如增量模型实质就是分段的线性模型，螺旋模型则是接连的弯曲了的线性模型，在其它模型中也能够找到线性模型的影子。
　　通常瀑布模型法的缺点是它很大程度上是文档导向的,而这会耗费时日。使用瀑布模型法,项目经理能够游刃有余,但给客户带来了麻烦。例如,在典型的建筑项目中,通常有很详尽的规范,并且需要花非常多的时间去完成。必须等到房子最后盖好,客户才第一次真正看到最终产品。客户如果此时想要改变某些东西的话,不但为时己晚,而且变化会是过于艰巨的事情.
　　瀑布模型这种模型本质上是一种线性顺序模型，因此存在着较明显的缺点，各阶段之间存在着严格的顺序性和依赖性，特别强调预先定义需求的重要性，在着手进行具体的开发工作之前，必须通过需求分析预先定义并“冻结”软件需求，然后再一步一步的实现这些需求。但是实际项目很少遵循着这种线性顺序进行的。虽然瀑布模型也允许迭代，但这种改变往往对项目开发带来混乱。在系统建立之前很难只依靠分析就确定出一套完整、准确、一致、有效的用户需求，这种预先定义需求的方法更不能适应用户需求的不断变化的情况。
　　1.需求是可变的
　　某些应用软件的需求与外部环境、公司经营策略或经营内容等密切相关，因此需求是随时变化的。
　　2.需求是模糊的
　　对于大多数更常使用的应用系统，例如管理信息系统，其需求往往很难预先准确的指定，也就是说，预先定义需求的策略所做出的假设，只对某些软件成立，对多数软件并不成立。许多用户对他们的需求最初只是模糊的概念，想要求一个对需求只有初步设想的人准确无误的说出全部需求，显然是不切实际的。人们为了充实和细化他们的初步设想，通常需要经过在某个能运行的系统上实践的过程。
　　3.用户和开发者难于沟通
　　大型软件的开发需要系统分析员、软件工程师、程序员、用户、领域专家等各类人员的协调配合。然而大多数用户和领域专家不熟悉计算机和软件技术，软件开发人员也往往不熟悉用户的专业领域，开发人员和用户之间很难做到完全沟通和相互理解，在需求分析阶段做出的用户需求常常是不完整、不正确的。传统的瀑布模型很难适应需求可变、模糊不定的软件系统的开发，而且在开发过程中，用户很难参与进去，只有到开发结束才能看到整个软件系统。这种理想的、线性的开发过程，缺乏灵活性，不适应实际的开发过程。
　　按照传统的生命周期方法学开发软件，各阶段的工作自顶向下从抽象到具体顺序进行，就好像奔流不息的瀑布，一泻千里，总是从高处依次流到低处。因此，传统的生命周期方法学可以用瀑布模型(Waterfallmodel)来模拟。按照传统的瀑布模型来开发软件，有如下几个特点，这些特点隐含在软件生命周期各阶段的观点和指导思想中，是比具体任务更根本的东西。
　　(1) 阶段间具有顺序性和依赖性
　　这个特点有两重含义：第一，必须等前一阶段的工作完成之后，才能开始后一阶段的工作；第二，前一阶段的输出文档就是后一阶段的输入文档，因此只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。
　　(2) 推迟实现的观点
　　清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，前面阶段的工作没做或做得不扎实，过早地考虑进行程序实现，往往导致大量返工，有时甚至发生无法弥补的问题，带来灾难性后果。瀑布模型在编码之前设置了系统分析与系统设计阶段，这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。
　　(3) 质量保证的观点
　　软件工程的基本目标是优质、高产。保证所开发的软件的质量，在瀑布模型的每个阶段都应坚持两个重要做法：
　　第一，每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。完整、准确的合格文档不仅是软件开发时期各类人员之间相互通信的媒介，也是运行时期对软件进行维护的重要依据。
　　第二，每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。及时审查是保证软件质量、降低软件成本的重要措施。
　　如图所示，瀑布式生命周期的开发过程是顺序行进的；活动流向基本是单向的。它假设开发者在开发初期对系统的了解足够清楚。不幸的是，任何软件开发活动都不可避免地要涉及大量迭代过程，无论你事先是否安排。好的设计人员指的是那些能同时在抽象的层面和具体的细节上进行工作的实践家。总的来说，瀑布式生命周期的缺点表现在三个方面：<1> 后期的变化、迭代、改动困难 <2> 不支持重用 <3> 没有一个联系各个阶段的统一模型。
　　最近作项目比较郁闷，倒也不是忙，主要是计划性不足，致使许多的无用功，不过也成就了所谓的瀑布式开发模型。
　　什么是瀑布模型呢？简单的说就是现阶段的工作指导下一阶段工作，下一阶段的工作验证、修正现阶段工作，任何后阶段的工作只依赖于前阶段的工作成果，这意味着一担发现错误，最多只需要修改上一阶段，而不是全盘否定、重新来过。然后就是一个瀑布模型的实例：
　　A、我有一个笼统的需求文档，其实客户的需求并非像想象中的那么清晰。
　　B、根据这个需求，我做了概要设计，画了一些图，写了一些文档，当然因为需求中的一些略显暧昧或者说朦胧的词，致使概要设计跟实际客户的想法有些出入也在所难免。
　　C、根据设计进行了编码，形成了软件的原形，客户当然不会满意也许根本就认为这不是根据他提出的需求制作的。因为在从抽象的需求到具体的功能实现的过程中，那些原本朦胧暧昧的词汇被不同人员理解成了不同的意义，这一点出于中文的博大精深是在不可避免的。
　　D、从现在可是就是瀑布模型的精髓了：客户验收时发现不符可要求，导致需要修改编码来迎合客户。于是我们回到了编码阶段，但是发现问题出在设计上，一些问题设计时就没有给出或者给出了错误的解决。于是我们回到了设计阶段，但是发现问题的根源仍然在上一阶段，那就是客户提供的需求中暧昧词汇。于是我们最终回到了客户身上，然而客户不是专业人士，他们是没有责任的，责任在于我们对于暧昧词汇的理解出了偏差，于是新一轮的瀑布式开发过程开始了。
　　所以说理论与实际操作永远是存在差距的，当邪恶的种子在一开始就被埋藏在地下，它终将绽放出黑暗之花。