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

查看本系列全部文章：
《OOA&D实践之路——真实案例解析OO理论与实践》索引贴

再次明晰开发流程
      在上一篇文章“OOA&D实践之路——真实案例解析OO理论与实践（五、需求分析之前的故事）”中，我给出了一幅开发流程图：

      这幅图，加上前几篇文章的内容，给不少朋友留下诸多困惑。如“特性列表不算需求分析吗？”、“用例图怎么跑到需求分析前面去了？没有需求分析哪来的用例图？”为了解开这些困惑，我们应该先把开发流程各个相关概念给明确了。
      在一般开发流程中，直观上可以分为两个部分：业务阶段和系统阶段。明确这一点非常重要。其中业务阶段主要进行的工作是与计算机无关的，而系统阶段才是和计算机相关的东西。上图中“我们在这里”那道竖线所指的地方，就是业务阶段和系统阶段的分界点。
      而如果从建模角度分析，整个开发流程分为四个子流程：
      a）业务建模流程
      b）系统建模流程
      c）分析设计建模流程
      d）部署实施建模流程
      其中a）属于业务阶段，而b）c）d）均属于系统阶段。
      业务建模流程的任务就是做业务分析、降低风险和给出系统总体概览模型。系统建模主要就是需求工程。分析设计建模就是我们熟悉的概要设计和详细设计。而部署实施建模是对系统的具体实施建立模型。
      其中，我们一般所说的“需求”，实际是指“系统需求”，是在b）阶段进行的，所以a）阶段的一切工作，都不能算是需求分析。（当然，如果加一个前缀，说是“业务需求分析”，也是可以的，但是一般在软件工程领域，说“需求分析”是特指“系统需求分析”。）
      而关于用例图的疑惑，大家应该知道，用例图分为业务用例图和系统用例图，而业务用例图产生于a）流程，这样它们当然会出现在b）流程，也就是需求分析之前。当然，在b）流程中还会出现用例图，这时就是系统用例图了。
      明白了以上开发流程，我想很多疑惑就自然解开了。所以，其实我们所谓的“需求分析之前的故事”，就是业务建模流程。

系统阶段的法宝1：迭代与增量
      在上文中，我们提到软件过程大体分为业务阶段是系统阶段。在前面几篇文章中，我们已经基本完成业务阶段，下面是进入系统阶段了。不过莫急，在正式进入系统阶段之前，我们有几个重要的、关于系统阶段的话题要聊一下。
      如果你问我，在系统阶段最应该被牢记的是什么，我会告诉你，是两个词：迭代&增量。
      我们已经知道，系统阶段是在业务阶段的基础上，在计算机领域内进行需求分析、系统分析、概要设计、详细设计、编码、测试、部署实施等一系列环节。但是，如果你想仅施行一遍这个流程，而完成整个系统的话，不好意思，你大致会精神崩溃。
      如果这个过程仅实施一遍，其实就成了瀑布模型。小系统也许可以，但是稍大点的系统，将会带来严重的后果。我们知道，“软件开发中永远不变的就是变化”，如果采用瀑布模型，反馈将会非常靠后，一直要到部署实施阶段才能看到成果，如果客户要求更改需求或认为当前系统不是他们想要的，那么修改过程会异常惨烈，代价也是巨大的。
      那么，我们应该如何实施系统阶段开发呢？法宝就是迭代和增量。具体做法是：
      我们将整个系统分为许多相对独立的“单元”，每次只对一个或少数几个单元实施需求分析、系统分析、概要设计、详细设计、编码、测试、部署实施等一系列过程，一次这样的过程叫做一次迭代，而将一次迭代的成果加入现有成果的过程就叫做增量。
      这种开发流程的优势是明显的：我们总是能在相对较短的时间内，完成整个系统功能的一个“子集”，这个子集是可以运行的，可以看到效果，所以如果用户不满意，反馈是及时的，修改代价也较小。通过合理的过程控制，变更代价总可以控制在一个可以接受的范围内。
      在实施迭代&增量过程时，要注意一下两点：
      1）迭代单元不是环节，而是系统功能的某个子集。如不能说第一次迭代完成需求分析、第二次迭代完成设计……这不叫迭代式开发，这叫里程碑式开发，和迭代有本质区别。
      2）每次迭代一定要完整完成需求分析、系统分析、概要设计、详细设计、编码、测试、部署实施这一套环节，产生的成果必须是成品，是可运行、可交付的，是整个系统的一个子集，而不能是一个半成品。

系统阶段的法宝2：用例驱动
      相信，大家或多或少听说过“用例驱动”。那么什么是用例驱动呢？如果你理解了上文的迭代&增量过程，就很好理解用例驱动了。上文不是说过，迭代时每次选取一个或少数几个“单元”吗？那么这个“单元”是什么？理论上，什么都可以，只要是对系统合理的划分。但在实践中，人们发现，使用业务用例作为迭代单元是最合适的。为什么呢？
      其一，业务用例大小适中，规模平均。
      其二，业务用例大多相互独立性好，适合进行迭代。
      其三，业务用例能很好反映系统的功能单元。
      所以，所谓的用例驱动就是以业务用例作为迭代单元进行迭代开发的流程。
      你看，我们前面做了那么多业务分析，其中成果之一就是业务用例图。而这里，业务用例成了我们进行系统迭代开发的单元和驱动者，所以，软件开发过程不是割裂的，而是相互联系的，不会说上一个阶段过去就过去了，和下一阶段毫无联系。一般，上一阶段的产品总会成为下一阶段的材料。
      在这里附上一副我自己画的示意图，希望能帮助大家理解本文内容：

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

重点总结
      1.软件过程大致可分为业务阶段和系统阶段。
      2.业务阶段进行业务建模流程，与计算机领域无关；系统阶段进行系统建模、分析设计建模和部署建模阶段，与计算机相关。
      3.系统阶段的两大法宝：迭代式开发与用例驱动。