软件开发生命周期模型

编码-修补模型

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

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

    这种开发模型有几个缺点。最重要的缺点是存在于需求，设计和实现中的错误要到整个产品被构建出来后才能被发现。如果因为客户的验收，已经完成的模块需要重大的改变，那么整个开发的时间和花费将会大得多。编码-修补模型对于大于100行代码的软件系统来说是个很坏的选择。另一个缺点就是这种模型开发出来的产品很难去理解和维护，因为他们缺乏任何需求和设计文档。

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

 

瀑布模型

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

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

    瀑布模型的主要特征是它支持下一个阶段到上一阶段的反馈。假如，原是设计阶段的一个错误在实现阶段被发现。在瀑布模型中，设计所需的改变被输入设计阶段的第二次迭代，在工作继续之