1.4 迭代模型
OOD启思录
软件开发的迭代模型看上去和瀑布模型差不多，区别只在于迭代模型允许开发者沿项目流程往返（见图1.2）。如果我们在为系统的某个部分编写代码时发现了一个设计缺陷，我们可以回到设计阶段来分析并改正它。或者，如果我们在测试系统的一部分时发现了新的系统需求，我们可以回到分析阶段来修正这个问题。在面向动作范型中，迭代模型会带来很多问题。面向动作的软件常常会有很多位于数据和行为之间的隐含依赖关系。再同集中控制机制一结合，你就会发现自己处于这样一个境地：如果触动了已经存在的应用程序的部分，整个系统就会轰然倒塌。如果已经为应用程序编写了90%的代码，那么增加需求或者改变设计是无法接受的。面向对象范型改正了这一问题，它向开发者提供分布式的流程控制，并使他们具备防止数据、行为间隐含依赖性的能力。于是，对面向对象开发者来说，软件开发的迭代模型就成了理所当然的选择。1
但是，迭代模型也不是一点问题都没有。虽然我相信，这个模型准确地反映了从系统构架师角度上看到的开发过程，但是对项目经理来说，它却带来了很大的问题。简而言之，这个模型目前缺乏一系列精确定义的开发里程碑。这并不意味着在整个软件系统构筑完毕移交客户的那一天之前，项目经理无法获得任何反馈；而是表明我们需要新的迭代式的里程碑来在应用系统成型之前就提供必要的反馈。
一种这样的工件（deliverable）是软件原型（software prototype）。原型领域源自这样的认知：现实世界中的复杂实体是逐渐生长而成的（grown），而不是创建而得的（built）。很多开发者都把原型看作是控制当今软件根本复杂性的方法。通过创建原型，应用程序可以一次增长一层，每层都经过彻底的测试，然后才开始下一层的增长。通过这种方法，设计缺陷就可以尽早发现，从而改正的代价也相对较低。而工作原型也可以用作生产率的衡量尺度。通过衡量原型中功能点的数目并将其同伪功能点（尚未真正实现其功能）相比较，我们可以跟踪进度。2
1译注：面向对象范型是通过解耦合来使得修改系统已有部分变得容易且不会引入bug，但这还不够，所以人们提出通过重构（refactoring）和单元测试（unit testing）使得迭代开发更容易。而在解耦合方向上的新的探索则包括AOP、MDA等。
2译注：作者在这里只是粗略提及这样的开发方式，本书出版几年后的今天，这样的开发方式已经成为现实。
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。