文章目录
[+]
开发模型 是 软件工程当中指导开发的一种开发思想和开发体系。
不同的开发过程，分了不同的阶段，有着不同的指导思想，做着不同的事情。
开发模型的多种多样，经过几十年的发展，产生了很多很多的开发模型，各种开发模式各有特色。
（图片来自网络侵删）
而曾经使用的最多的模型就是瀑布模型。
瀑布模型瀑布模型是一九七几年提出来的。这个模型提出来之后，就得到了广泛的应用与认可。
当时盛极一时。在全盛时期，大概有90%以上的项目采用的是突瀑布模型，包括美国的国防部都是指定用瀑布模型开发。
但是慢慢地，瀑布模型已经淡出了人们的视线。基本上已经属于被淘汰的模型。
为什么会有这种现象呢？原因很简单，它有重大的缺陷，这种缺陷足以导致项目的失败。
因为有研究机构进行过统计分析，发现了利用瀑布模型做开发，十有八九会失败，这种失败体现在要么延期，要么成本超支，要么根本做不下去。为什么会有这种现象的诞生呢？
那要从瀑布模型本身的结构说起了。
瀑布模型的结构如上图所示：
要做软件计划需求分析设计编码软件测试运行维护在用瀑布模型开发的这个过程中，每一个阶段末尾的地方都会有软件的评审工作，评审上一个阶段的工作是否做好和这一个阶段的相应的一个产出物是否符合相关的要求。而且瀑布模型强调了文档化标准。瀑布模型是一个典型的结构化方法的模型非常具有代表性，把结构化方法的各种特点表现得淋漓尽致。到这里似乎还没有看出有什么缺陷。做事情先有计划，再分阶段进行阶段之后做评审，这似乎是一种很好的方式。
并且在后来改进的瀑布模型中，加了回溯的通道：下一个阶段遇到问题，可以回到上一个阶段去把一些问题解决了，再往下走。
这样看起来瀑布模型非常不错，但为什么会导致上面说的这么严重的问题呢？
其根本原因就在于——需求阶段难以把控。为什么这么讲呢？
软件的需求往往都是不明确尤其在项目的初期，要把这个软件需求完全弄明确几乎不可能。而瀑布模型就是在项目初期，通过猜测用户的需求去进行设计的导致了我们在需求不是很明确的时候，就要开始动手去做。这样带来的后果就是我们认为的我们做的需求，就是用户所需要的东西。
结果做了需求，做设计，做了设计，做编码。做了编码，做测试回过头来把完成的软件的产品给用户去看的时候，我们认为项目快要结束了，已经走到了末尾的阶段。但事实上呢，很大概率用户会推翻你的所有工作他会讲软件这里不行，那里要改。这里的思路和我原来想的不一样，等等这些问题。一旦用户提出这些问题，要去修改怎么办呢？就要回到需求阶段，把需求做调整，调整之后重新做设计或调整设计。再做编码再做测试，这样一来呢，会浪费大量的时间，所以导致软件项目的失败。正是这个原因呢，使得瀑布模型难以完成很多项目的开发。
但瀑布模型也是有适用的场景的那就是需求明确或是二次开发的项目。我们也可以用其他的方法把需求先把做明确，再用瀑布模型来完成项目。
简单总结首先，瀑布模型是结构化方法的模型。一般用于结构化开发。
第二，瀑布模型只适用于需求明确的项目，对于需求不明的项目，千万不要用瀑布模型去做开发。
