OOA&D实践之路——真实案例解析OO理论与实践（六、迭代式开发与用例驱动）

这种开发流程的优势是明显的：我们总是能在相对较短的时间内，完成整个系统功能的一个“子集”，这个子集是可以运行的，可以看到效果，所以如果用户不满意，反馈是及时的，修改代价也较小。通过合理的过程控制，变更代价总可以控制在一个可以接受的范围内。

　　 在实施迭代&增量过程时，要注意一下两点：

　　 1）迭代单元不是环节，而是系统功能的某个子集。如不能说第一次迭代完成需求分析、第二次迭代完成设计……这不叫迭代式开发，这叫里程碑式开发，和迭代有本质区别。

　　 2）每次迭代一定要完整完成需求分析、系统分析、概要设计、详细设计、编码、测试、部署实施这一套环节，产生的成果必须是成品，是可运行、可交付的，是整个系统的一个子集，而不能是一个半成品。

　　系统阶段的法宝2：用例驱动

　　 相信，大家或多或少听说过“用例驱动”。那么什么是用例驱动呢？如果你理解了上文的迭代&增量过程，就很好理解用例驱动了。上文不是说过，迭代时每次选取一个或少数几个“单元”吗？那么这个“单元”是什么？理论上，什么都可以，只要是对系统合理的划分。但在实践中，人们发现，使用业务用例作为迭代单元是最合适的。为什么呢？

　　 其一，业务用例大小适中，规模平均。

　　 其二，业务用例大多相互独立性好，适合进行迭代。

　　 其三，业务用例能很好反映系统的功能单元。

　　 所以，所谓的用例驱动就是以业务用例作为迭代单元进行迭代开发的流程。

　　 你看，我们前面做了那么多业务分析，其中成果之一就是业务用例图。而这里，业务用例成了我们进行系统迭代开发的单元和驱动者，所以，软件开发过程不是割裂的，而是相互联系的，不会说上一个阶段过去就过去了，和下一阶段毫无联系。一般，上一阶段的产品总会成为下一阶段的材料。

 

在这里附上一副我自己画的示意图，希望能帮助大家理解本文内容：

　　图片看不清楚？请点击这里查看原图（大图）。

　　 本文理论讲得多了点，有点枯燥，但是必须讲，因为明白这些是以后进行系统阶段的基础。从下一篇开始，我们回归示例，进入真正的系统阶段了。下一篇，将开始第一轮迭代的起始阶段：需求分析。

　　重点总结

　　 1.软件过程大致可分为业务阶段和系统阶段。

　　 2.业务阶段进行业务建模流程，与计算机领域无关；系统阶段进行系统建模、分析设计建模和部署建模阶段，与计算机相关。

　　 3.系统阶段的两大法宝：迭代式开发与用例驱动。