传统开发模型vs敏捷开发模型——过程模型的变革

1、概念框架

    在了解一个新概念的时候，最好的方法就是把它插入到原有的概念体系中。在不只有助于对概念的记忆，更利于深入地认识概念的本质、精髓。下图说明了“敏捷开发”在软件工程理论体系中的位置。

 

    为何须要软件工程？很简单，为了让咱们更好地生产软件。这里的“好”包含多重含义，有成本上的“好”、维护上的“好”等等。可是咱们知道，不可能坐着想“我要写好软件”，而后就软件就能写好了。咱们须要一套系统化、理论化、工程化的方法，这就是软件工程。咱们经过研究以往的经验整理出来一系列活动，包括：沟通、策划、建模、构建、部署等。可是只知道可能须要这些活动还不太够，最好还能提供一些模型，告诉咱们设计一个软件先进行什么？接着进行什么？出了问题怎么办？等等。换言之，咱们不仅须要活动的集合，咱们须要一种更精细的结构来指导咱们作软件，这就是过程模型。典型的过程模型有：瀑布模型、增量模型、螺旋模型、协同模型等等，固然还包括敏捷开发模型。也就是说，“敏捷开发”是一种软件开发的过程模型。

2、传统过程模型

    什么是传统过程模型？很遗憾，我没有找到一个权威、详细的说法。不过，虽然这个概念的边界可能不是很清晰，可是其核心的部分仍是获得必定的公认。这里，咱们分析三个典型的传统过程模型：瀑布模型、增量模型和螺旋模型。

瀑布模型

    在20世纪80年代以前，瀑布模型是最先也是应用最普遍的软件过程模型，如今它仍然是软件工程中应用最普遍的过程模型。瀑布模型提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工做对象做为输入，利用这一输入实施该项活动应完成的内容，给出该项活动的工做成果，并做为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；不然返回前面，甚至更前面的活动。

 

    由于瀑布模型把关键的活动明确的划分，而且以线性的顺序依次完成，因此咱们可让活动之间的联系下降。这是一种优秀的性质，意味着咱们在进行一个活动的时候，只须要和上一个活动进行交互，而不须要关注过多的活动。一旦某一个活动出现问题，那么咱们只须要去纠正上一个活动的问题便可。同时，这种线性的方式很简单，方便了过程过程管理。

    然而，瀑布模型的线性特征也是它问题的根源。瀑布模型老是试图作好一件事情以后才作下一件事，可是错误是不可避免的。能够看出，在整个开发过程当中，只有在最后的部署阶段才能让客户看到这个软件。而一般需求分析阶段是最容易出现错误的阶段，因此极可能最开始的错误会一直流传到最后才会被发现，这意味着咱们必需要更改全部的活动以求改正错误，一样的问题还会出如今需求变动时。因此，瀑布模型在实际应用中经常会变为V模型，以下图所示。

 

 

增量模型

 

    增量模型（Incremental Model）是在项目的开发过程当中以一系列的增量方式开发系统。在增量模型中，软件被做为一系列的增量构件来设计、实现、集成和测试，每个构件是由多种相互做用的模块所造成的提供特定功能的代码片断构成。

    增量方式包括增量开发和增量提交。增量开发是指在项目开发周期内，以必定的时间间隔开发部分工做软件；增量提交是指在项目开发周期内，以必定的时间间隔增量方式向用户提交工做软件及相应文档。根据增量的方式和形式的不一样，分为渐增模型和原型模型。

    增量模型融合了线性顺序模型的基本成分和原型模型的迭代特征。增量模型采用随着日程时间的进展而交错的线性序列。每个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第一个增量每每是核心的产品，也就是说第一个增量实现了基本的需求，但不少补充的特征尚未发布。客户对每个增量的使用和评估，都做为下一个增量发布的新特征和功能。这个过程在每个增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每个增量均发布一个可操做的产品。

    增量模型引进了增量包的概念，无须等到全部需求都出来，只要某个需求的增量包出来便可进行开发。虽然某个增量包可能须要进一步适应客户的需求而且更改，但只要这个增量包足够小，其影响对整个项目来讲是能够承受的。

    因为增量模型可以在较短的时间内向用户提交一些有用的工做产品，所以可以解决用户的一些急用功能。同时，交付给用户部分功能后，用户学习、试用过程能够和软件下一个功能的开发并行。可是，增量模型也有以下缺点：

1） 因为各个构件是逐渐并入已有的软件体系结构中的，因此加入构件必须不破坏已构造好的系统部分，这须要软件具有开放式的体系结构。

2） 在开发过程当中，需求的变化是不可避免的。增量模型的灵活性可使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边作边改模型，从而使软件过程的控制失去总体性。

3）若是增量包之间存在相交的状况且未很好处理，则必须作全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求常常改变的软件开发过程。

 

3、敏捷开发模型

    敏捷软件开发又称敏捷开发，是一种从1990年代开始逐渐引发普遍关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。虽然在国外已经获得了普遍应用，在中国国内，敏捷开发用的还不算不少。可是随着Agile敏捷开发的流行，愈来愈多的公司采用敏捷开发用于软件产品和应用的开发。

    敏捷开发是一种以人为核心、迭代、按部就班的开发方法，相对于传统软件开发方法的“非敏捷”，更强调程序员团队与业务专家之间的紧密协做、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、可以很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的做用。

 

4、敏捷开发过程VS传统开发过程

    敏捷开发区别于瀑布式的特征很明显，敏捷开发是以一种迭代的方式推动的，而瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行，步骤成果做为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。敏捷开发过程当中，软件一直处于可以使用状态，它将项目分红若干相互联系、能够独立运行的子项目，所以，每一个阶段软件都是可见的，客户能够直观的体验并提出意见。若是按照瀑布式流程，客户可能在签定开发合同3个月后，看到的还只是各类文档（需求文档、设计文档、详细设计文档等等），客户心理或许会不踏实。瀑布式的主要的问题是它的严格分级致使的自由度下降，项目早期即做出承诺致使对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明而且在项目进行过程当中可能变化的状况下基本是不可行的。在瀑布式开发中，需求修改的时间越靠后，成本越大，因此需求分析人员的压力很大。因为敏捷开发是迭代式的，，而且迭代周期较短，所以很容易相应新需求或是对旧需求的修改。瀑布式开发有不少文档，但敏捷开发不是没有文档，而是轻文档。在敏捷开发过程当中，适量的文档仍是颇有帮助，有助于整理思路，加快沟通和讨论，好比概念设计文档、架构图、SWOT分析文档等等，这些文档在每一个产品版本开始以前会有产生，在每一个迭代的过程当中根据业务人员和市场的反馈也会有一些变动。经过实践证实，这对产品的思路、沟通讨论都很是有帮助。并且这些文档，大可能是几页PPT，书写和维护工做都很小。

    相比迭代式的增量开发，相同的是二者都强调在较短的开发周期提交软件。基于Scrum的迭代增量开发通常会在一个比较长的一个迭代周期频率下不断交付，同时迭代中不容许有变化的需求，这样就有一些场景让这种迭代很困难，例如紧急的技术支持、临时增长的很是高的优先级的需求等等，另外项目的估算很是难，致使不容易承诺。相比较，敏捷方法的周期可能更短，而且更增强调队伍中的高度协做。敏捷开发的原则之一是拥抱变化需求时刻在变，人们对于需求的理解也时刻在变，项目环境也在不停的变化，所以你的开发方法必需要可以反映这种现实，敏捷开发方法就是属于适应性的开发方法，而非预设性。另外，敏捷开发更适用于小型团队，在一个办公室工做，属于那种通讯基本靠吼的状态，固然团队成员之间的交互会更方便。另外敏捷开发强调用户（或用户表明）要与开发团队在一块儿工做，便于及时沟通交流。重视交互也应该能够算是最明显的区别之一。这样还有一个好处，就是有利于团队中知识的迅速传播。即便有人离开团队，另外的人也能完成相应的工做。所以，“人与交互”被列为敏捷开发价值观之一，并排在第一位。

 

参考文献：

[1] 普雷斯曼. 软件工程：实践者的研究方法[M]. 北京：机械工业出版社，2011.

[2] 窦万峰. 系统分析与设计方法及实践[M]. 北京：机械工业出版社，2013.

[3] 梁永幸. 浅谈敏捷开发与其余传统开发方式的区别[J]. 电子世界，2012.12.