软件项目生命周期模型

软件项目生命周期模型

当一个软件产品在没有规格说明或主要设计的情况下被开发时，开发者往往不得不重新对产品编码多次直到他们得到正确稳定的产品。这种开发模型就是编码-修

补模型。

开发者们首先开发出一个产品的最初版本给客户验收，然后开发团队开发一个新的版本再次给客户验收。这个过程一直持续到客户感觉产品满意为止。

这种开发模型有几个缺点。最重要的缺点是存在于需求，设计和实现中的错误要到整个产品被构建出来后才能被发现。如果因为客户的验收，已经完成的模块需要重大的改变，那么整个开发的时间和花费将会大得多。编码-修补模型对于大于

100行代码的软件系统来说是个很坏的选择。另一个缺点就是这种模型开发出来的

产品很难去理解和维护，因为他们缺乏任何需求和设计文档。

因为这种模型没有包括编码前的开发阶段，所以它不被认为是一个完整的生命周期模型。然而在某些场合这种简单的方式非常有用。对于需求非常简单和容易明白，软件期望的功能行为容易定义，实现的成功或失败容易检验的工程可以使用这种模型。

瀑布模型

直到十九世纪八十年代早期，唯一被广泛接受的模型就是瀑布模型。

瀑布模型包括了全部的开发阶段（需求，规格说明，设计，实现，集成，操作和维护）。这些阶段被安排成一定的顺序。当每个阶段完成了，它将被检验和测试，也就是说每个阶段在被认为完成之前必须由软件质量保证小组认可。

瀑布模型的主要特征是它支持下一个阶段到上一阶段的反馈。假如，原是设计阶段的一个错误在实现阶段被发现。在瀑布模型中，设计所需的改变被输入设计阶段的第二次迭代，在工作继续之前这些改变需要被调整和经历一个额外的检验步骤。所有后继的阶段必须适应设计的改变。

一个正式反馈机制的出现保证了开发周期中的调整可以在最小破坏的范围内得到解决。然而瀑布模型有个重要的潜在缺陷。这种模型依赖详细的文档同客户关于软件的需求功能达成一致意见。因为它需要技术能力去明白详细的软件规约，可能会出现客户与开发者对软件理解不同的风险。这会导致开发者开发出的软件满足了规格说明，但是那不是客户所期望的。

快速原型模型

瀑布模型假设大多数，并不是所有的需求分析和规格说明发生在代码编码和模块测试之前。这个假设当客户缺少技术知识，不能写出一份详细的需求清单或者不能完全参与到需求分析过程时就没有作用了。快速原型模型快速创建一个软件系统原型。它可能包括期望功能或用户界面的一个子集，但是它可能在范畴，健壮性，性能和平台方面受限。

快速原型的优点是它可以使用户集中精力参与到需求的讨论中来。即使客户缺乏技术知识用软件工程术语来描述需求，客户也能够谈论用户界面，它是怎么样组织的，它提供了什么功能等等。如果开发者能够创建一个将要被开发系统的工作模型，

将会得到很多的用户反馈。另一个快速原型的优点是它可以帮助减轻技术风险。通过快速开发一个基础版本的软件，开发者可以揭示任何使用被提议的技术所不能预见的问题。

快速原型模型的一个缺点就是开发者可能想去重用那些没有根据软件工程过程指导开发的，用来开发原型的代码。原型代码常常质量低下，这样的代码不能用作实现完整系统的基础。

递增模型

在递增模型中，一个单独的软件产品被分割成一个连续发行版本的集合。这个开发周期将核心产品模块和许多增加到核心模块上的其他模块区别开来。每一个增加的模块是一个可完全操作的产品。

递增模型的最大优点是它在每一个步都提供料一个可操作的产品。第一个交付的产品常常包括核心功能模块。另一个优点是新的功能模块可以逐渐的增加进去。一个支持递增开发的产品设计常常意味着极容易的可维护性，因为系统的结构必须支持对核心模块的直接扩展。

递增模型有一些缺点。主要的缺点是待解决的问题必须允许有一个可递增的软件解决方案。如果需要的软件必须将所有的功能表现出来，那么递增的模型是不合适的。还有就是为了递增模型成功，必须找出整个系统的体系结构。

同步-稳定模型

此模型也叫做“微软模型”，这种开发方式在微软广泛使用。

产品的开发被分割成三或四个递增的版本。随着每一个版本被实现，开发团队进行同步稳定。一旦系统稳定，程序代码被保持不动，在这一点及时提供一个产品的工作快照。

主要优点有：支持早期测试，持续互用性，设计上的较早反馈。

主要缺点有：有限的经验和使用范围。

螺旋模型

在每一个阶段的开始进行一个风险分析。风险分析的目的是识别和解决那些对软件项目产生影响的软件风险。如果有任何风险被识别而不能解决的话，那么这个醒目可能会被终止。

螺旋模型好像就是在每个阶段进行风险分析的瀑布模型。

主要优点：支持软件重用，广泛的测试，方便维护。

主要缺点：仅适用于内部项目，大型项目受限，需要风险分析专家。