软件开发模式对比(瀑布、迭代、螺旋、敏捷)

1、瀑布模型是由W.W.Royce在1970年最初提出的软件开发模型，　瀑布式开发是一种老旧的计算机软件开发方法。
瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。
步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。 

瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，
代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。 


2、迭代式开发也被称作迭代增量式开发或迭代进化式开发，是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。
什么是迭代式开发？
每次只设计和实现这个产品的一部分, 
逐步逐步完成的方法叫迭代开发, 
每次设计和实现一个阶段叫做一个迭代. 

在迭代式开发方法中，整个开发工作被组织为一系列的短小的、
固定长度（如3周）的小项目，被称为一系列的迭代。
每一次迭代都包括了需求分析、设计、实现与测试。
采用这种方法，开发工作可以在需求被完整地确定之前启动，
并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。
再通过客户的反馈来细化需求，并开始新一轮的迭代。

迭代式开发的优点：
　　1、降低风险
　　2、得到早期用户反馈
　　3、持续的测试和集成
　　4、使用变更
　　5、提高复用性



螺旋开发，1988年，巴利·玻姆(Barry Boehm)正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。
“螺旋模型”刚开始规模很小，当项目被定义得更好、更稳定时，逐渐展开。 

　　“螺旋模型”的核心就在于您不需要在刚开始的时候就把所有事情都定义的清清楚楚。您轻松上阵，定义最重要的功能，实现它，然后听取客户的意见，之后再进入到下一个阶段。如此不断轮回重复，直到得到您满意的最终产品。 
       （1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件； 

　　（2）风险分析：分析评估所选方案，考虑如何识别和消除风险； 

　　（3）实施工程：实施软件开发和验证； 

　　（4）客户评估：评价开发工作，提出修正建议，制定下一步计划。 
螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。


　



敏捷软件开发又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。

人和交互 重于过程和工具。可以工作的软件 重于求全而完备的文档。客户协作重于合同谈判。随时应对变化重于循规蹈矩。

其中位于右边的内容虽然也有其价值，但是左边的内容最为重要。
人员彼此信任 人少但是精干 可以面对面的沟通

项目的敏捷开发：
敏捷开发小组主要的工作方式可以归纳为：作为一个整体工作； 按短迭代周期工作； 每次迭代交付一些成果； 
关注业务优先级； 检查与调整。

最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，
因此敏捷方法更适用于较小的队伍，40、30、20、10人或者更少。
大规模的敏捷软件开发尚处于积极研究的领域。




四者对比区别：

传统的瀑布式开发，也就是从需求到设计，从设计到编码，从编码到测试，从测试到提交大概这样的流程，要求每一个开发阶段都要做到最好。
特别是前期阶段，设计的越完美，提交后的成本损失就越少。

迭代式开发，不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间，
最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。

螺旋开发，很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。

敏捷开发，相比迭代式开发两者都强调在较短的开发周期提交软件，但是，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。
敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。 

适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化.

如果你没有条件能与客户时常沟通建议采用瀑布模型
1.需求分析
   1.1 需求采集               粗粒度的收集材料
   1.2 需求细化
        1.2.1 菜单确认        确认软件应有的菜单,功能等软件先范围信息.
        1.2.2 流程确认        确认软件中有那工作流,重点绘制流程图.
        1.2.3 功能确认        确认每一个功能点的具体需求.
2.软件设计
   2.1 ER设计
   2.2 原型设计
3.编码实现
4.单元测试                    研发人员自测
   4.1 结对测试
   4.2 用例测试
5.集成测试
   5.1 通盘业务测试
   5.1 边界测试
   5.2 压力测试
   5.3 数据接口测试
6.出厂评审                    项目经理,研发经理,测试经理会签.
7.软件实施
   7.1 业务数据维护
   7.2 培训
   7.3 操作手册编写
8.软件验收
   8.1 验收报告
   8.2 项目总结
如果你有较好(有定期的碰头会,和阶段性里程碑会议)的条件与客户沟通建议采用迭代模型
   把瀑布模型中的1-7变为3周左右的循环进行迭代推进,最好完成8
如果你有非常好的条件(有关键用户和软件团队一起工作)和用户沟通那请使用敏捷开发模型

人和交互 重于过程和工具。
可以工作的软件 重于求全而完备的文档。
客户协作重于合同谈判。
随时应对变化重于循规蹈矩。