软件生命周期（SDLC）——第二季

简介

之前在第一季介绍了在不同时期比较有代表性的软件生命周期，比如上个世界五十年代的瀑布模型，还有八十年代的螺旋模型，最后介绍了本世纪的敏捷开发。在这一章我将分别对比一下这几个比较有代表性的生命周期，并在下一季谈谈影响软件生命周期发展的影响要素。

瀑布模型 VS. 螺旋模型

螺旋模型可以说是瀑布模型的变形，引进了一些重要的要素比如迭代和风险分析，但并不代表螺旋模型就可以取代瀑布模型，相反这两个软件生命周期至今非常流行并且被广泛应用。原因很简单就是每个生命周期都有相对适合的项目，只有深刻的理解了每个软件生命周期的差异才能运用自如，并且使用最合适的方案使利益达到最大化。
从客户的角度来看，两种模型都会有客户参与的阶段，但是客户却代表不同的功能。比如瀑布模型客户只参与需求分析和验收的阶段，但是对于螺旋模型客户可以参与大部分的阶段，对软件的整个开发过程有所了解并及时提出修改方案。由此可见对于瀑布模型往往对于客户是不公平的，因为只要当客户签字结束需求分析阶段后，之后的开发过程客户就很难在参与了，这样往往会造成开发的结果并不是客户想要的。所以瀑布模型相对螺旋模型风险更大。
相对瀑布模型，螺旋模型所引入的另一大要素就是迭代，因为简单直接是瀑布模型的最大优势也是最大劣势，为了实现效率节约成本，瀑布模型往往当一个步骤提交之后就很难回滚了。这个原因往往导致一些开发停滞，例如需求文档很难被设计人员理解或者设计文档看起来是可行的但是开发人员却很难实现。所以螺旋模型采用迭代来弥补瀑布模型的缺陷，它可以更容易的解决开发停滞需求更变等风险。
相对瀑布模型的简单易用，螺旋模型更加复杂并且需要风险分析专家的参与，不停地迭代但缺乏文档造成瀑布模型相对难以控制与管理，往往过多的迭代或者过短的迭代周期会造成开发目标不明确与进度混乱。相反瀑布模型的明确里程碑和大量的文档支持可以保证整个项目的准确性和进度，使得项目更加方便管理和控制。

瀑布模型 VS. 敏捷开发

瀑布模型和敏捷开发都是名气非常响的软件生命周期，瀑布模型拥有比敏捷开发多出50多年的历史，但是当更多的公司开始接受并采用敏捷开发后，瀑布模型的应用率开始大规模下滑。然而这能说明敏捷开发就一定比瀑布模型好么？
瀑布模型与敏捷开发往往在软件生命周期中都是拥有相同的目标的，比如定义，收集，分析，设计，开发，测试，发布，维护，只是他们实现目标的方式确是截然不同的。
瀑布模型的进度往往是根据时间线与预算直接挂钩的，并且拥有大量的文档支持项目的交付与进度。然而这些会给带来很多不利因素，比如缺乏迭代使瀑布模型很难处理需求变更，所以瀑布模型往往需要大量的时间用作前期的项目计划与需求分析来确保整个后面的步骤不受影响。
相对大量的前期工作，敏捷开发却放弃项目计划阶段，取而代之的事开发人员通过以周为单位的短期冲刺来针对小型的模块开发，这样需求的变更往往影响是最小的。而且客户是参与整个开发周期的，通过与开发人员的频繁交流来确保项目的正确性。然而相对瀑布模型明确的时间线和里程碑，敏捷开发最大的挑战是难以计算的时间线与项目预算，例如Scrum的燃尽图就是解决这一问题的一个方案。

螺旋模型 VS. 敏捷开发

其实敏捷开发就是螺旋模型，因为敏捷开发拥有螺旋模型的核心概念并同时抛弃了它的一些过于繁琐的缺点。螺旋模型的迭代周期比敏捷开发更长并拥有更加复杂的步骤，例如每个周期都需要计划和风险分析，很明显螺旋模型更加繁琐复杂，因为它的每个迭代通常比较类似一个瀑布模型周期。
螺旋模型的项目可以经常添加或更改功能，但是新功能不能与之前的需求有太大的差异，但是敏捷开发的短迭代周期就可以更加方便的处理这类问题。通常螺旋模型与瀑布模型一样只有最终以此的版本发布，但是敏捷开发通过连续交付的技术来频繁发布版本，并通过客户的反馈快速的作出响应。

总结

总体来说，这三个生命周期都有自己的优缺点，而且大部分都是互补的。所以针对他们的选择就相对容易，由于瀑布模型的的简单直接，通常比较适合目标明确或者外包类的项目，例如现有项目的新版本或者相对简单直接的项目，因为前期的需求分析与设计越完美，瀑布模型带来的效益就会越大。而螺旋模型更加适合一些风险较大的项目，通过不停地迭代与风险分析来规避风险，并且通过频繁的预算控制也能更好地管理项目。对于敏捷开发，它比螺旋模型处理非常频繁需求变更的能力更强，通过与客户不停地面对面交互而摈弃文档使敏捷开发更加灵活易用，所以敏捷开发通常适合拥有丰富经验的小型团队使用。

第二季针对之前介绍的瀑布模型，螺旋模型与敏捷开发分别做了一些对比。第三季我打算分析一下影响软件生命周期的发展的主要因素。