阅读作业二之waterfall——洪虹

 

　　所谓瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。 1970年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。我们可以通过图片一步步地了解所谓的瀑布模型：

一个小的程序只有简单的两步

 

经典的Waterfall软件工程模型包括以下几部分：用户需求，软件需求，需求分析，设计，编码，测试，运维。

 

为了保证每个步骤都能正确实施，要在每个步骤之间添加一定的交互

 

如果在测试的时候发现了设计甚至需求的问题，就必须返回

 

为了解决上面的“返工”问题，我们可以使用下面的几步来解决。

第一步，Preliminary Design，程序设计先行，确定在进入需求分析之前，概要设计要完整。

 

第二步，Document Design，书写设计文档，，总共6个文档，1）软件需求，2）概要设计，3）接口设计，4）各种最终设计，5）测试设计/计划，6）测试结果。流程开始变得复杂了。

 

第三步，“Do it Twice”，双保险，把文档了的东西试着预先走一遍，看看能否成为最终产品。

 

第四步，计划，控制和监控测试

 

第五步，用户介入，全程review各个环节

 

这就是完整的Waterfall软件工程模型

 

   

从上面的图中我们可以得到很多信息,瀑布模型的优缺点也不言自明：

1、瀑布模型有以下优点
　　1）为项目提供了按阶段划分的检查点。 
　　2）当前一阶段完成后，只需要去关注后续阶段。 
　　3）可在迭代模型中应用瀑布模型。
　　增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
2、瀑布模型有以下缺点
　　1）在项目各个阶段之间极少有反馈。
　　2）只有在项目生命周期的后期才能看到结果。
　　3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
　　4)瀑布模型的突出缺点是不适应用户需求的变化.

　　瀑布模型对很多类型的项目而言依然是有效的，如果正确使用，可以节省大量的时间和金钱。对于我们的项目而言，是否使用这一模型主要取决于是否能理解客户的需求以及在项目的进程中这些需求的变化程度，对于经常变化的项目而言，瀑布模型毫无价值，对于这种情况，您可以考虑其他的架构来进行项目管理，比如螺旋模型。

　　在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。
　　瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不太适合现代的软件开发模式，其主要问题在于： 
　　（1） 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
　　（2） 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；
　　（3） 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。 

　　其实不管是瀑布模型还是什么别的模型，都是被有意简化，以帮助我们解决真实生活中遇到的问题，后者往往复杂得令人生畏。但只有模型是不够的，即便在可以适用的场合，它们也仍然有失精确。这一点值得我们在做软件工程的过程中反思和借鉴，但凡模型都有其局限性，最好的做法就是在合适的地方用合适的模型，才能发挥其最大优势，如果使用后徒增工作量的话，绝对是得不偿失的。