软件开发模式资料整理

边做边改模型

现在的许多产品实际都是使用“边做边改”模型开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。

在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户和测试等等满意为止。

这种模型适合周期很短而且逻辑不需要太严谨的小程序，但这种方法对任何规模的开发来说都是不能令人满意的。其主要问题在于：

• 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；
• 忽略需求环节，给软件开发带来很大的风险；
• 没有考虑测试和程序的可维护性，也任何文档，软件的维护十分困难。

瀑布模型

瀑布模型是一种比较老旧的软件开发模型，瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。

瀑布模型的优点是严格遵循预先计划的步骤顺序进行，一切按部就班比较严谨。

瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太过理想化，已不再适合现代的软件的软件开发模式，几乎被抛弃。其主要问题在于：

• 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
• 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；
• 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果；
• 各个软件生命周期衔接花费时间较长，团队人员交流成本大；
• 瀑布式方法在需求不明确并且在项目进行过程中可能变化的情况下基本是不可行的。

迭代模型

是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。

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

　教学中，对迭代和版本的区别，可理解如下： 迭代一般指某版本的生产过程，包括从需求分析到测试完成； 
  版本一般指某阶段软件开发的结果，一个可交付使用的产品。

与传统的瀑布模型相比，迭代过程具有以下优点：

• 降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是一个开发有误的迭代的花费。
• 降低了产品服务按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。
• 加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。
• 由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。

快速原型模型

快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的需求，开发人员可以确定客户真正的需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。

显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。

快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。

快速原型模型有点整合“边做边改”与“瀑布模型”优点的意味。

螺旋模型

之后补充

敏捷软件开发

敏捷开发是一种以人为核心、迭代、循序渐进的开发软件。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个项目联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

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

敏捷软件开发要注意项目规模，规模增长，团队交流成本就上去了。因此敏捷软件开发暂时适合不是特别大的团队开发，比较适合一个组的团队使用。