上周公司给新人上编程规范培训，期间三楼一哥问我瀑布模型主要步骤是什么。花擦，当时我很想问他瀑布模型是什么-.-，作为一个成年人我当然是忍住了，然后启动自己所有的扯淡能力，惶顾左右千回百转之时，平静的告诉他：就是一条道走到底嘛。呵呵，当场为自己的机智折服，正当陶醉在这应答如流壮举中时，老板说，你完全不知道是吧，不是计算机专业的吗？哈哈哈哈哈哈哈，说笑啦。。。。没错，我真不是计算机专业的==
软件开发模型从某种程度上来说是一种方法论，它指的是软件开发全部过程、活动和任务的结构框架。个人觉得要注意几个点，过程，就是确定方向以后，确定多个关节点，把路线定下来；活动，就是在这条路上做的事，走、跑、跳、羞羞的事等等；任务，想必是通过活动达到的目的，软件开发活动的指向；结构框架，就是对于以上三者的明确规定；最后，全部，当然只软件开发模型的作用域，从0到应用的全部范围都受其辖制。开发过程包括需求、设计、编码、测试和维护等阶段；而开发模型清晰、直观地表达开发的全过程，明确规定要进行的活动和要完成的任务，用来作为软件项目工作的基础。这以外的事，诸如要用什么语言、什么系统、什么团队、什么技术，我以为并不是被软件开发模型规定的。
那么简单了解软件开发模型以后，我们将目光投向问题的主角——瀑布模型。瀑布模型的English name叫做Waterfall Model（下文简称WM），说白了就是开发流程像瀑布一样（瀑布式开发流程）。所以说我之前扯的淡是有几分道理的，老板说我完全不知道，虽然事实是这样，但是可以委婉一点的好吗←_←
模型历史什么的我们不管，直接看WM是怎样指导开发的。翻看网上至少二十份关于WM的介绍，其中有十八份是相互抄的，这让我很忧伤。所以说，信息爆炸的年代，获取真知灼见诚如食堂的肉末茄子里找到肉末。那么有说WM把软件生命周期划分六个的，也有说八个的。我们多多益善，WM将软件的生命周期划分为以下八个，作为强迫症我一定要把每一步字数的方差缩到最小：问题的定义、可行性分析、项目需求分析、系统总体设计、具体功能设计、编写代码和单元测试、系统集成测试、部署运行维护。那么一个稍微看过网上资料的人都会发现我把他们改了，没错我就是这么吊。因为找不到1970年温斯顿·罗伊斯（Winston Royce）提出WM时的原始说明之类的东西，这个我就把握大意自定义了。
这八个阶段明显是甲方乙方含在一起的。问题的定义，也就是一个需求出现后，我们明确自己要解决什么，实现什么；这往往不是一句话能说清的，可以认为它是需求的骨架。可行性分析，就是做的做不到嘛，甲方常常会说的，这个不是很容易吗，你们随便实现一下就好了。。。信不信分分钟砍死你=.=项目需求分析，这个就要很详细了，因为它涉及到后面的具体设计和实现，也是联系甲方和乙方的桥梁，比如我现在正在做的这个项目的需求书，二三十页算少的。系统总体设计，就我目前来看包括架构（MVC等）和数据库物理模型（表结构）设计。写到这里你会发现IT中很多术语有被滥用的倾向，这些术语并没有一个具体的应用场景或是上下文，往往产生了一些隋丹妮的幻象。比如模型、框架、架构等等，想来也没必要去严格定义，说得多了也就知道丁卯。具体功能设计，这个就是我作为一个程序员要明确怎么写代码了，比如分组给他一个什么界面之类的，历史分组要怎么做到。编写代码和单元测试我放一起了，这本来就是一起的，单元测试的重要性希望慢慢在编程实践中体会吧。事实上你会发现，写代码只是所有工作中占用时间很少的一部分，哦嚯嚯，就是这样。系统集成测试，这个在近期应该有深刻体会，传说中的联调，当项目涉及到流程性的东西时，这一步是非常关键也非常耗时的。另外这里的测试包不包括UAT我不太清楚，暂时不说。最后就到了部署运行维护，也就是交付使用，售后服务的事情。那么WM就有这个八个阶段。
WM的本质是一次通过，即每个阶段的活动只执行一次，最后得到软件产品，很明显是个线性顺序结构。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。所以对经常变化的项目而言，瀑布模型毫无价值，不要他妈的改他妈的需求好吗。当然，也可以灵活运用，不过概念泛化没什么意义，比如说敏捷开发有点把大瀑布拆成小瀑布的意味，这个以后会研究，不展开。
WM的优点嘛，它对软件生命周期有非常明确的划分，我们可以很清楚的判断每个阶段工作的完成情况，同时由于WM的线型顺序结构，只有当上一步完成了以后，才能进行下一步，当上一步完成以后，我们可以全身心投入下一步。就好比一辆公交，司机可以很清楚的判断车是否到站，没到站的赶紧到站，到站的赶紧到下一站，直至终点。
那我们评判某事物优缺点的时候，事实上是在从不同的角度去阐释它最关键的特质或特点。WM的最大特点就是自上而下线性顺序，所以它的最大缺点是无法应对需求变化，而且用户只有等到整个过程的末期才能见到开发成果，增加了开发风险。另外一旦将开发流程用WM格式化之后，PM就很有可能通过大量的强制完成日期和里程碑来跟踪各个项目阶段，控制项目进度。最后，各阶段划分完全固定，阶段之间会有大量文档，工作量剧增。
作为软件开发模型届的老前辈，WM目前已经不太能跟上时代潮流，不过WM的各种变体，以及受WM启发衍生出的很多新模型妥妥的非常重要。所以我们有必要认识WM。
那么在这篇随笔的最后，瀑布模型主要步骤，细分可以是八个阶段：问题定义、可行性分析、需求分析、系统总体设计、具体功能设计、编写代码和单元测试、系统集成测试、部署运行维护；粗分可以是六个：需求、架构、设计、代码、测试、维护。