顾名思义，瀑布模型就如同瀑布⼀样，从⼀个特定的阶段流向下⼀个阶段，如图 6-1所⽰。 1.瀑布模型的核⼼思想
瀑布模型认为，软件开发是⼀个阶段化的精确的过程。就像要制造⼀艘航空母舰，⾸先需要知道航空母舰的参数（长、宽、⾼、排⽔量、航速等）。在这些参数的技术上需要对航空母舰进⾏设计，设计包括总体设计和详细设计。只有设计得⼀清⼆楚的图纸才能交付施⼯，否则造出的零件肯定拼装不到⼀起。制造完毕后，要把这些零件⼀个⼀个地拼装起来，拼装成发动机、船舱等部分，并检查这些部分是否符合设计标准，这就是集成测试。最后，把各个部分组合在⼀起，造出⼀艘巨⼤的航母。这个过程正如图 5-1 中的描述，软件要经过需求分析、总体设计、详细设计、编码、调试、集成测试和系统测试阶段才能够被准确地实现。在图 6-1 中，每⼀阶段都有回到前⼀阶段的反馈线，这指的是，在软件开发中当在后续阶段发现缺陷的时候，可以把这个缺陷反馈到上⼀阶段进⾏修正。 航空母舰模型从图 6-1 中可以看出瀑布模型的⼀个重要特点：软件开发的阶段划分是明确的，⼀个阶段到下⼀个阶段有明显的界线。在每个阶段结束后，都会有固定的⽂档或源程序流⼊下⼀阶段。在需求分析阶段结束后，需要有明确的描述软件需求的⽂档；总体设计结束后，需要有描述软件总体结构的⽂档；详细设计结束后，需要有可以⽤来编码的详细设计⽂档；⽽编码结束后，代码本⾝被作为⽂档流到下⼀个阶段。因此也称瀑布模型是⾯向⽂档的软件开发模型。
当软件需求明确、稳定时，可以采⽤瀑布模型按部就班地开发软件，当软件需求不明确或变动剧烈时，瀑布模型中往往要到测试阶段才会暴露出需求的缺陷，造成后期修改代价太⼤，难以控制开发的风险。
2．瀑布 V 模型
瀑布 V 模型是瀑布模型的⼀种变体。随着对瀑布模型的应⽤，⼈们发现，缺陷是⽆法避免的，任何⼀个阶段都会在软件中引⼊缺陷，⽽最后的测试也不能保证软件完全没有缺陷，只能争取在交付前发现更多的缺陷。测试成为软件开发中⾮常重要的环节，测试的质量直接影响到软件的质量。因此，⼈们对瀑布模型进⾏了⼩⼩的更改，提出了更强调测试的瀑布 V 模型，如图 6-2 所⽰。
整个瀑布模型在编码与调试阶段转了个弯，形成了⼀个对称的 V 字。瀑布 V 模型同标准瀑布模型⼀样，在进⾏完需求分析后就将进⼊总体设计阶段，但是除总体设计外，需求分析还有⼀条虚线指向系统测试。这指的是，需求分析的结果将作为系统测试的准则，即需求分析阶段也将产⽣同软件需求⼀
致的系统测试；同时软件产品是否符合最初的需求将在系统测试阶段得到验证。以此类推，总体设计对应了集成测试，详细设计对应了单元测试。瀑布 V 模型不但保持了瀑布模型的阶段式⽂档驱动的特点，⽽且更强调了软件产品的验证⼯作。
3．瀑布模型的缺点
虽然是经典的开发模型，但瀑布模型中仍存在⼀些难以克服的缺陷，即使是在改进的瀑布 V 模型中还是会存在。
⾸先，在瀑布模型中，需求分析阶段是⼀切活动的基础，设计、实现和验证活动都是从需求分析阶段的结果导出的。⼀旦需求分析的结果不完全正确，存在偏差，那么后续的活动只能放⼤这个偏差，在错误的道路上越⾛越远。事实上，由于⽤户和开发者的⽴场、经验、知识域都不相同，不同的⼈对同⼀件事物的表述也不同，这就造成需求分析的结果不可能精确、完整地描述整个软件系统。所以瀑布模型后期的维护⼯作相当繁重，⽽这些维护⼯作⼤多都是修正在需求分析阶段引⼊的缺陷。这个问题是瀑布模型难以克服的。
其次，瀑布模型难以适应变化。在瀑布模型中精确地定义了每⼀个阶段的活动和活动结果，⽽每⼀阶段都紧密依赖于上⼀阶段的结果。如果在软件的后期出现了需求的变化，整个系统⼜要从头开始。
再次，使⽤瀑布模型意味着当所有阶段都结束才能最终交付软件产品，所以在提出需求后需要相当长⼀段时间的等待才能够看到最终结果，才能发现软件产品究竟能不能够满⾜客户的需求。
最后，⽂档驱动型的瀑布模型除了制造出软件产品外还将产⽣⼀⼤堆的⽂档，⼤部分的⽂档对客户没有任何意义，但完成这些对客户没有意义的⽂档却需要花费⼤量的⼈⼒。所以瀑布模型也是⼀种重载过程。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议