瀑布式开发是一种老旧的，正在过时的计算机软件开发方法。

最开始的软件行业普遍采用这种方法，但是这种方法套用自传统工业生产，不适应计算机软件开发的具体情况。

瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。

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

有论文统计他是造成70%软件开发失败的原因。

大体分为这几个阶段：需求分析、设计、编码、测试、维护。

需求阶段通常定义系统的需求，明白系统的目标。

设计阶段通常确定系统使用什么数据库，系统模块的划分，各个模块的功能。

编码阶段用编程语言对设计阶段的实现。

测试阶段分黑盒测试，白盒测试。测试系统的功能是否实现，是否准确。

维护阶段是根据用户新的需要重新修改系统，使系统更加稳定，更符合用户的要求。

需求阶段的工作是否到位是整个系统开发的关键，在需求阶段有很多方式可以帮助自己完成工作，例如与客户畅所欲言，跟随客户参与业务过程等等。不管任何一种方法，任何一种方式，在需求阶段首先确定系统边界，确定组织边界，然后摸清企业为消费者创造的价值，看清企业的价值链，摸清价值链上的实体。最后要平衡价值链上各个实体之间的利益，争取系统做到大家都满意这个理想的状态。

瀑布式开发
我收到一个开发任务，然后按照从需求到设计、从设计到编码、从编码到测试、从测试到发布这个流程去做；每个步骤都力求做到最好；上一个流程的输出作为下一个流程的输入，比如产品出一个需求文档，这个文档成为设计的依据；流程内是没有用户的反馈的。
迭代式开发
我收到一个开发任务，我依然按照瀑布式开发的流程去做事；但是区别是，这个过程中我不需要把每个流程都做到最好，而只是做好大体框架；比如写一个查询的功能，在用户输入关键字搜索之后，我能展示出结果就ok，至于分页、前端优化、搜索的算法以及其它细节，我先不做；然后去给用户使用，收集反馈，再按照反馈进行一次一次的迭代开发；迭代式开发适用于需求不能在最初完整确定或者在开发过程中会变化很多的场景。

瀑布式开发
简介:
 是以前常用的，类似与工厂生产线一样，一步一步执行，劣势
 1.软件只在SDLC的最后才产出，者期间可能持续数月或更长时间
 2.有很大的不确定性
 3.它不适合那些需求变化频繁的软件，比如电商项目
 4.没有可追溯性
 5.去测量每个阶段都相当困难的

优点:
开发需求明确，思路清晰

缺点:
 周期时间漫长，如果要修改，变动很大

敏捷式开发
简介:
 敏捷开发的原则:
 1.通过早期敏捷的持续传送开发的软件，达到客户满意度
 2.常常交付软件，就是交付时间短(可能在一周或者是一个月内)
 3.企业人员，开发者，用户之间更紧密的配合
 4.建项目的所有干系人，应该充分收到信任
 5.面对面的交流是最好的沟通方式
 6.软件交付周期时间短，可以对软件更好的测量
 7.持续关注好的技术和好的设计
 8.简单就是最好的
 9.自己组织内部的团队
10.经常适应不断变化的环境

敏捷的背后原则是增量，快速，灵活的软件开发，它促进了计划的多次变化

优点:
适合多变化，持续迭代更新

缺点:
对开发人员的要求高

Devops
促进开发和运维之间达成共识，打破传统开发的分组

优点:
适合多变化，持续迭代更新

缺点:
对开发人员的要求高

瀑布式开发是一种老旧的，正在过时的计算机软件开发方法。

最开始的软件行业普遍采用这种方法，但是这种方法套用自传统工业生产，不适应计算机软件开发的具体情况。

瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。

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

有论文统计他是造成70%软件开发失败的原因。

大体分为这几个阶段：需求分析、设计、编码、测试、维护。

需求阶段通常定义系统的需求，明白系统的目标。

设计阶段通常确定系统使用什么数据库，系统模块的划分，各个模块的功能。

编码阶段用编程语言对设计阶段的实现。

测试阶段分黑盒测试，白盒测试。测试系统的功能是否实现，是否准确。

维护阶段是根据用户新的需要重新修改系统，使系统更加稳定，更符合用户的要求。

需求阶段的工作是否到位是整个系统开发的关键，在需求阶段有很多方式可以帮助自己完成工作，例如与客户畅所欲言，跟随客户参与业务过程等等。不管任何一种方法，任何一种方式，在需求阶段首先确定系统边界，确定组织边界，然后摸清企业为消费者创造的价值，看清企业的价值链，摸清价值链上的实体。最后要平衡价值链上各个实体之间的利益，争取系统做到大家都满意这个理想的状态。


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

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


2、迭代式开发也被称作迭代增量式开发或迭代进化式开发，是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。
什么是迭代式开发？

每次只设计和实现这个产品的一部分, 

逐步逐步完成的方法叫迭代开发, 

每次设计和实现一个阶段叫做一个迭代. 

在迭代式开发方法中，整个开发工作被组织为一系列的短小的、

固定长度（如3周）的小项目，被称为一系列的迭代。

每一次迭代都包括了需求分析、设计、实现与测试。
采用这种方法，开发工作可以在需求被完整地确定之前启动，

并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。

再通过客户的反馈来细化需求，并开始新一轮的迭代。


迭代式开发的优点：

　　1、降低风险

　　2、得到早期用户反馈

　　3、持续的测试和集成

　　4、使用变更

　　5、提高复用性



螺旋开发，1988年，巴利·玻姆(Barry Boehm)正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。

“螺旋模型”刚开始规模很小，当项目被定义得更好、更稳定时，逐渐展开。 


　　“螺旋模型”的核心就在于您不需要在刚开始的时候就把所有事情都定义的清清楚楚。您轻松上阵，定义最重要的功能，实现它，然后听取客户的意见，之后再进入到下一个阶段。如此不断轮回重复，直到得到您满意的最终产品。 

       （1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件； 


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


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


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



　



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


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


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

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

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




四者对比区别：

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

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

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

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

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