第5讲：软件开发中的“流水线”

相信同学们对上图的瀑布模型一定不会陌生，所有阶段都是线性的。完成一个阶段的工作再进入下一个阶段，之前阶段输出的成果物作为下一个阶段的输入。比如：设计阶段输出的设计书，作为编码阶段的输入并输出源代码。详细设计输出的详细设计书，作为单元测试的输入并输出单元测试的测试用例。

瀑布模型具有线性的特点，像“流水线”一样分为多个阶段，依次通过这些阶段最后出来成品。还记得上一节我们提过的吗？软件质量保证是通过保证过程来保证最终产品的质量。在这点上与瀑布模型非常契合。因此，我们以瀑布模型的各阶段来讲解质量保证相关流程，以及工具方法。

下面我们顺带简单介绍下瀑布模型的优缺点。瀑布模型拥有易于理解，方便进行各阶段规划等优点，同时也存在着以下的缺点：

1.越往后发生变更代价越高。当在编码阶段发生需求变更时，则需要修改需求文档，设计书，以及源代码。当测试阶段发现设计书问题时，需要修改设计书，源代码，以及测试用例。因此，瀑布模型更加适合需求清晰明确变更少的项目。

2.实际开发过程中，很难按照线性进行开发。根据人员的负荷以及交付期的压力，各阶段经常会有并行。比如：设计书还没有完全完成，一部分开发资源不可能空在那边，可能会针对编写完成但还没有评审的设计书先进行编码，因此并行经常伴有质量风险并导致返工。

3.客户很难在一开始就清楚所有的需求。客户往往看到原型或者实际的产品，通过试用后才能提出更加符合业务的需求。因此，低成本且快速的原型能力也非常重要哦。

4.产品在最后阶段才能被使用。这成为最大的风险，往往经过半年，一年的开发，最后发现已经跟不上市场的变化了。因此，针对不同的产品需要选择不同的开发模型。这个世界本来就没有“银弹”哈。

在实际项目中，比起瀑布模型，往往使用他的“升级版” V模型，且看改进后的“流水线”。

V模型是瀑布模型的升级版，将编码之后的阶段如图上折，形成V字型。V模型与瀑布最大的不同在于如上图的横向虚线。

虚线代表的含义很好理解。比如：详细设计完成后，就可以根据详细设计书编写单元测试的测试用例。也就是说：详细设计完成后，不仅可以开始编写代码，也可以开始编写单元测试的测试用例，尽管测试用例的执行需要等到编码完成以后。其他虚线对应的各阶段也是一样的道理。

由于V模型是瀑布模型的改进型，因此具有瀑布的优缺点，同时他在以下三个方面进行了改进。

1.更充分利用时间。比如：详细设计完成后就可以并行进行单元测试用例的编写。

2.反过来提高需求文档，设计文档的质量。比如：单元测试用例编写过程中，可以尽早发现详细设计书的问题，反过来提高了设计书的质量，减少了返工。

3.用例可以一并作为下一阶段的输入，增强理解。编码阶段的输入，除了详细设计书，如果单元测试用例已经完成也可以作为输入，程序员可以更好的理解业务逻辑，提高编码效率及质量。

由于V模型对瀑布模型进行了一些改进，相比瀑布模型，一般项目中都使用V模型。除了瀑布模型（V模型），还有增量，迭代，敏捷，看板等等。有兴趣同学可以自己查阅资料。但开发模型的选择不作为本专栏的重点。其他的开发模型可以做如下理解。比如：把迭代开发中的每个迭代看作瀑布模型。敏捷开发也同理，但同时要满足敏捷的主张及约束。因此，只要搞清楚V模型“流水线”各阶段的质量保证流程及工具方法，也就可以灵活运用到其他的模型了。接下来我们将深入“流水线”的各个环节了解提高质量的方法。

拒绝碎片化知识，订阅本专栏（免费）并关注大虾，系统化学习程序员需要掌握的质量知识，一起感受不同于技术的别样魅力，拓宽视野，为职业发展打好基础。