软件工程中为了保障项目的高效准确的实施交付，研究者提出了不同软件工程模型和软件开发方法。工程模型从软件的角度来研究和发展软件工程的工作模式，开发方法基于工程模型提出具体的软件开发方法。模型和开发方法随着大量的软件开发时间不断的进化。目前最有名的模型就是瀑布模型和敏捷模型，其中敏捷模型是快速原型模型，递增模型和螺旋模型的集大成者。目前是最流行被广泛认可的软件工程模型，但是瀑布模型则奠定了软件工程的基础，瀑布模型的遗产还深刻的影响了后续的工程模型和开发方法。敏捷模型的开发方法包括极限编程和SCRUM

瀑布模型

年温斯顿·罗伊斯（WinstonRoyce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

瀑布模型有以下优点

为项目提供了按阶段划分的检查点。

它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

瀑布模型有以下缺点

各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。

由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。

通过过多的强制完成日期和里程碑来跟踪各个项目阶段。

瀑布模型的突出缺点是不适应用户需求的变化。

瀑布模型的提出者Winston一定是一位理想主义者，瀑布模型有效的前提是需求定义者能够完整清晰准确的定义需求，设计者能够考虑到各方面的因素，根据需求定义，进行很好的概要设计和详细设计，剩下的工作似乎就是码农搬砖的体力活了。外包公司也是在这种模式下工作的，但是现实是残酷的。产品经理无法写出这样的需求，架构师也无法交付这样完美的设计，所以后果就是产生了大量的浪费，产品的发布周期一在推迟。

瀑布模型的最大贡献就是将软件生命周期按阶段进行了划分，定义了每一个阶段的职责和分工。瀑布模型软件生命周期的8个阶段中问题定义、可行性研究属于计划期：需求分析、总体设计、详细设计，程序编制属于开发期；测试和运行、维护属于运行期。我们发现不论我们采用哪种工程模型，我们始终还是活在瀑布模型的影响下，按照大的阶段一步步的落实，只是每一个阶段具体实现和分工没有遵循瀑布模型的思想。

敏捷模型

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。敏捷模型的核心原则包括：

主张简单：当从事开发工作时，你应当主张最简单的解决方案就是最好的解决方案。用AM的说法就是，如果你现在并不需要这项额外功能，那就不要在模型中增加它。要有这样的勇气：你现在不必要对这个系统进行过分的建模（over-model），只要基于现有的需求进行建模，日后需求有变更时，再来重构这个系统。尽可能的保持模型的简单。

拥抱变化：需求时刻在变，人们对于需求的理解也时刻在变。项目进行中，Projectstakeholder可能变化，你努力的目标和成功标准也有可能发生变化。这就意味着随着项目的进行，项目环境也在不停的变化，因此你的开发方法必须要能够反映这种现实。

持续迭代：即便你的团队已经把一个能够运转的系统交付给用户，你的项目也还可能是失败的－－实现项目投资者的需求，其中就包括你的系统应该要有足够的鲁棒性（robust），能够适应日后的扩展。就像AlistairCockburn常说的，当你在进行软件开发的竞赛时，你的第二个目标就是准备下一场比赛。可持续性可能指的是系统的下一个主要发布版，或是你正在构建的系统的运转和支持。要做到这一点，你不仅仅要构建高质量的软件，还要创建足够的文档和支持材料，保证下一场比赛能有效的进行。你要考虑很多的因素，包括你现有的团队是不是还能够参加下一场的比赛，下一场比赛的环境，下一场比赛对你的组织的重要程度。简单的说，你在开发的时候，你要能想象到未来。

递增的变化：和建模相关的一个重要概念是你不用在一开始就准备好一切。实际上，你就算想这么做也不太可能。而且，你不用在模型中包容所有的细节，你只要足够的细节就够了。没有必要试图在一开始就建立一个囊括一切的模型，你只要开发一个小的模型，或是概要模型，打下一个基础，然后慢慢的改进模型，或是在不再需要的时候丢弃这个模型。这就是递增的思想。

令投资最大化：你的项目投资者为了开发出满足自己需要的软件，需要投入时间、金钱、设备等各种资源。投资者应该可以选取最好的方式投资，也可以要求你的团队不浪费资源。并且，他们还有最后的发言权，决定要投入多少的资源。如果是这些资源是你自己的，你希望你的资源被误用吗。

高质量的工作：没有人喜欢烂糟糟的工作。做这项工作的人不喜欢，是因为没有成就感；日后负责重构这项工作（因为某些原因）的人不喜欢，是因为它难以理解，难以更新；最终用户不喜欢，是因为它太脆弱，容易出错，也不符合他们的期望。

快速反馈：从开始采取行动，到获得行动的反馈，二者之间的时间至关紧要。和其他人一共开发模型，你的想法可以立刻获得反馈，特别是你的工作采用了共享建模技术的时候，例如白板、CRC卡片或即时贴之类的基本建模材料。和你的客户紧密工作，去了解他们的的需求，去分析这些需求，或是去开发满足他们需求的用户界面，这样，你就提供了快速反馈的机会。

敏捷模型的两种开发方法：

极限编程：极限编程（ExtremeProgramming，简称XP）是由KentBeck在年提出的，是一种软件工程方法学，是敏捷软件开发中可能是最富有成效的几种方法学之一。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。“Extreme”（极限）是指，对比传统的项目开发方式，XP强调把它列出的每个方法和思想做到极限、做到最好；其它XP所不提倡的，则一概忽略（如开发前期的整体设计等）。一个严格实施XP的项目，其开发过程应该是平稳的、高效的和快速的，能够做到一周40小时工作制而不拖延项目进度。极限编程的实施方法提出了结对编程（英语：Pairprogramming）是一种敏捷软件开发的方法，两个程序员在一个计算机上共同工作。一个人输入代码，而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员，审查代码的人称作观察员（或导航员）。两个程序员经常互换角色。在结对编程中，观察员同时考虑工作的战略性方向，提出改进的意见，或将来可能出现的问题以便处理。这样使得驾驶者可以集中全部注意力在完成当前任务的“战术”方面。观察员当作安全网和指南。结对编程对开发程序有很多好处。比如增加纪律性，写出更好的代码等。

SCRUM：年，Sutherland读到了两位日本管理教授竹内弘高和野中郁次郎介绍制造业里出现的新的产品开发方法Rugby（橄榄球）的文章。这种方法的特点是整个流程都由一个高性能、跨功能的团队执行到底。他受到启发，结合自己多年的经验，与Easel公司的JohnScumniotales和JeffMcKenna一起开发了一套方法，取名为Scrum（来源于橄榄球术语，不是缩写）。而Schwaber则从杜邦公司一位化工过程控制专家那里取经，意识到项目分为两种：确定性项目，一切都已经确定，可以自动化生产流程；实验性项目，充满不确定性，哪怕一点微小的变化也会牵一发而动全身，因此只能用各种仪表不断监控，随时做出调整——这就是每日站会的由来。两人在一个IBM项目合作，并做了更详尽的研究，Scrum诞生了。年OOPSLA大会上他们第一次向世人介绍了Scrum。

在每一次冲刺（一个15到30天周期，长度由开发团队决定），开发团队创建可用的（可以随时推出）软件的一个增量。每一个冲刺所要实现的特性来自产品订单（productbacklog，我觉得翻译成“产品目标”更恰当），产品订单（产品目标）是指按照优先级排列的需要完成的工作的概要的需求（目标）。哪些订单项（目标项目）会被加入一次冲刺，由冲刺计划会议决定。在会议中，产品负责人告诉开发团队他需要完成产品订单中的哪些订单项。开发团队决定在下一次冲刺中他们能够承诺完成多少订单项。在冲刺的过程中，没有人能够变更冲刺订单（sprintbacklog），这意味着在一个冲刺中需求是被冻结的。

Scrum没有对软件的整个实施过程开出工程实践的处方，要求开发者自觉保证。但XP对整个流程方法定义非常严格，规定需要采用TDD、自动测试、结对编程、简单设计、重构等约束团队的行为。