所谓的V模型,其实是对瀑布模型的一种修改,也算一个Change吧,详见下图:
由于瀑布模型对于软件的需求分析与设计阶段考虑不足,导致可能会出现严重的设计问题,最后交付到客户手里才会被发现,所以V模型就考虑到这点,针对开发的各个过程都会有相应的测试环节,比如用户需求会对应验收测试,需求分析和系统设计会对应确认测试和系统测试等等(详见上表),这样子起码在交付前会把用户需求方面的问题覆盖到,不太会出现说这个产品不是客户想要的这种问题。
但是缺点也是显而易见的,跟瀑布模型一样,测试过程还是放在了最后环节,虽然可以满足客户的需求,但是问题都只能到最后阶段才能被发现,必然会导致上面瀑布模型发生相同情况,也就是成本和时间的增加,所以V模型充其量也只能是瀑布模型的2.0版本。(不过好歹已经有了Change,我相信在那个年代的背景呀,已经算挺不错了,已经考虑到需要对需求分析这些进行测试了)
当然,时代总是在不断地变化之中,你不懂得Change,那唯一的结局就是落后,落后就要挨打,有多少曾经风光的软件公司在今天已经找不到踪影,活下来的公司都是能不断适应时代改变而改变的公司。
V模型虽然比瀑布模型稍微先进那么一点,但是总是没法跟得上时代的进步,因为有现在看来显而易见的缺点(当然,这里得说一下,即使在现在,瀑布模型和V模型还是有其用武之地,特别是那种对质量看得非常严格,基本上方案定了不会有改动的行业,所以它们没有被淘汰,我这里讲的Change其实更多是针对敏捷开发的公司的,这类公司其实以前就应该敏捷,只是那个时候没敏捷的想法,但是它们的开发流程总是有敏捷的需求,所以这个流程总是在Change中,并且不断地去适应和反过来推动它们的流程的继续发展。)
上面讲了这么多,大家已经知道了瀑布模型和V模型对于需要敏捷的公司有一个致命伤了,也就是他们的测试环节总是放在开发完成后,从而导致了所有的Bug都是只能在最后才能被发现,客观上增加了产品是否能按时和正确地发布的风险。既然知道了问题所在,咱们的过程分析管理人员们也不是盖的,纷纷想出了高招。
首先来介绍一下W模型(见下图),W模型其实是有两个V模型组成,其实也就是双V了,看起来像W就叫做W模型了,W模型强调测试需要和开发同步进行,开发包括哪几个步骤,测试就需要测哪几个步骤,更重要一点是需要同步进行,也就是说你做完这一步我就需要测掉这一步,那开发的步骤也无非就包括了需求、设计和代码了,所以这些步骤都进行测试。
一看W模型,我就觉得这个模型已经很现代了,因为它终于把测试环节解放出来了,可以说是一个革命性的改变,把大家一直认为开发最后一步的测试环节,提到了跟开发同步的环节,并且把测试环节扩展到了需求和设计环节,这个理念已经跟现在的测试理念一样了。
在W模型中,当客户需求出来后,测试就会开始介入,看看需求里写的是不是就是客户当时所说;在设计完成后,看看设计文档是不是真实地反映了客户需求精神;在开发完成后,就开始单元测试,集成测试,确认测试,集成测试和验收测试。这样子的话,基本上也就解决了前面瀑布模型和V模型碰到的问题。(能提出这个模型的研究员,我觉得很厉害,赞一下!)
当然说了优点还是得说一下缺点,W模型虽然把测试与开发过程同步进行了,但是总是有前后关系,也就是一个过程完全完成后,才能进行下一个阶段,比如说需求过程完全做完以后,再去由测试去研究是否符合客户要求,然后才能开始设计阶段;设计工作完全完成后,再检查设计文档是否真正体现客户的需求,然后再开始编码阶段。。。。。。,这样子的话,简单的软件还行,但是一旦一个软件很复杂,需求可能会经常变更,这个模型就不知道怎么处理这种变更,因为它认为需求处理完了就完了,以后不会再有变更;设计验证过了就Ok了,以后不会再有变化。如果某一天,已经在进行单元测试了,突然客户一个需求改了,或者加了一个新功能,这个模型看着就蒙了,如果是经常有更改的话,这个模型就疯了,呵呵。
其他还有几种著名模型,比如H模型和X模型,都是对瀑布模型和V模型进行了不错的更新,当然也还是有其局限性,上面W模型存在的问题还是没法解决。
不过,时代还在继续发展,还有More Change等着咱们呢,且继续听下回分解。
(未完待续)
文章作者:石磊