1、瀑布模型
1.1 瀑布模型的特点
1970年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。
1.2 瀑布模型核心思想
瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。
将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，
并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
1.3 瀑布模型显著特点
1.严格把软件项目的开发分隔成各个开发阶段：需求分析，要件定义，基本设计，详细设计，编码，单体测试，结合测试，系统测试等。
使用里程碑的方式，严格定义了各开发阶段的输入和输出。如果达不到要求的输出，下一阶段的工作就不展开。
2.重视和强调过程文档，在开发的中后期才会看到软件原型，早期只能通过文档来了解系统的模样。
在这种情况下，文档的重要性仿佛已经超过了代码的重要性。
3.瀑布模型把每个开发阶段都定义为黑盒，希望每个阶段的人员只关心自己阶段的工作，不需要关注其他阶段的工作。
好处是：可以让开发人员能够更专注于本职工作，提高阶段效率。
坏处是：
- a.由于各阶段的开发人员只能接触到自己工作范围内的东西，所以对客户需求的理解程度高低不等，开发人员更像是定义为流水线上的工人。
- b.对于客户需求变更，编码人员会比设计人员更容易产生很强的抵触情绪。
- c.在每个开发阶段都会有一些信息刻意的不让其他开发阶段的人员知道（本意是为了提到效率，但实际上有时候产生的是互相的理解偏差）。
4.瀑布模型产生的管理文档(计划书，进度表)等，能让不太了解该项目的人也能看懂项目的进度情况（只有能看懂百分比就行），很适合向领导汇报用。
所以管理人员比较喜欢瀑布模型，但是开发人员不喜欢，因为它束缚了开发人员的创造性。
5.既然叫做瀑布，就意味着不应该走回头路。否则如果出现返工，付出的代价会很大。
软件生命周期前期造成的Bug的影响比后期的大的多。
代价比较大的主要原因还是每个开发阶段的步子过大，每一次调整都可能伤筋动骨。
6.更适合需求相对稳定的大型项目。
1.4 瀑布模型不足之处
- 在项目各个阶段之间极少有反馈。
- 只有在项目生命周期的后期才能看到结果。
- 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
- 瀑布模型的突出缺点是不适应用户需求的变化。
2、敏捷开发
是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。
相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本。
能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
敏捷建模（Agile Modeling，AM）的价值观包括了XP的四个价值观：沟通、简单、反馈、勇气，此外，还扩展了第五个价值观：谦逊。
2.1 敏捷开发特点
极限编程的思想体现了适应客户需求的快速变化，激发开发者的热情，也是目前敏捷开发思维的重要支持者。
敏捷软件开发是一个开发软件的管理新模式，用来替代以文件驱动开发的瀑布开发模式。
敏捷开发集成了新型开发模式的共同特点
- 敏捷就是“快”。快才可以适应目前社会的快节奏，要快就要发挥个人的个性思维多一些个性思维的增多。
- 客户参与。以人为本，客户是软件的使用者，是业务理解的专家，没有客户的参与，开发者很难理解客户的真实需求。
- 强调软件开发的产品是软件，而不是文档。文档是为软件开发服务的，而不是开发的主体。
- 设计周密是为了最终软件的质量，但不表明设计比实现更重要。
- 迭代。软件的功能是客户的需求，界面的操作是客户的“感觉”。对迭代的强调是缩短了软件版本的周期。
- 小版本。快速功能的展现，看似简单，但对于复杂的客户需求合理地分割与总体上的统一，要很好地二者兼顾是不容易的。
(1)人和交互 重于过程和工具。
(2)可以工作的软件 重于求全而完备的文档。
(3)客户协作重于合同谈判。
(4)随时应对变化重于循规蹈矩。
项目的敏捷开发,敏捷开发小组主要的工作方式可以归纳为：
- 作为一个整体工作；
- 按短迭代周期工作；
- 每次迭代交付一些成果:关注业务优先级；
- 检查与调整。
最重要的因素恐怕是项目的规模，规模增长，面对面的沟通就愈加困难， 因此敏捷方法更适用于较小的队伍，40、30、20、10人或者更少。
