第5章关于过程的话题

1、第章关于过程的话题第章关于过程的话题5.1 5.1 为什么需要过程为什么需要过程5.2 5.2 主流软件开发过程简介主流软件开发过程简介 5.2.1 5.2.1 统一软件开发过程统一软件开发过程RUPRUP 5.2.2 5.2.2 测试驱动开发测试驱动开发TDDTDD5.2.3 5.2.3 极限编程极限编程XPXP5.2.4 5.2.4 特征驱动开发特征驱动开发FDDFDD 5.3 5.3 理解开发过程理解开发过程 5.3.1 5.3.1 模型的演化过程模型的演化过程 5.3.2 5.3.2 第一次迭代第一次迭代5.3.3 5.3.3 第二次迭代第二次迭代5.3.4 5.3.4 随后的迭代随后

2、的迭代5.3.5 5.3.5 最后的迭代最后的迭代5.4 5.4 本章小结本章小结第章关于过程的话题第章关于过程的话题5.1 5.1 为什么需要过程为什么需要过程开发一个具有一定规模和复杂性的软件系统和编写一个简单程序是大不开发一个具有一定规模和复杂性的软件系统和编写一个简单程序是大不一样的，其间的差别就如同建造一座大厦和搭建一个狗窝的差别。大型一样的，其间的差别就如同建造一座大厦和搭建一个狗窝的差别。大型的、复杂的软件系统的开发是一项工程，必须按工程学的方法组织软件的、复杂的软件系统的开发是一项工程，必须按工程学的方法组织软件的生产与管理，必须经过分析、设计、实现、测试、维护等一系列的软的生

3、产与管理，必须经过分析、设计、实现、测试、维护等一系列的软件生命周期阶段。编程仍然是重要的，但是更具有决定意义的是系统建件生命周期阶段。编程仍然是重要的，但是更具有决定意义的是系统建模。只有在分析和设计阶段建立了良好的系统模型，才有可能保证工程模。只有在分析和设计阶段建立了良好的系统模型，才有可能保证工程的正确实施。的正确实施。对于现代的软件开发来说，对于现代的软件开发来说，“过程过程”是一个绕不过去的话题。一个过程是一个绕不过去的话题。一个过程定义了为达到某个确定的目标，需要什么人在什么时间以何种方式做何定义了为达到某个确定的目标，需要什么人在什么时间以何种方式做何种工作。对于软件开发而言，

4、其目标是构造一个新的软件产品或者完善种工作。对于软件开发而言，其目标是构造一个新的软件产品或者完善一个旧的软件产品。一个有效的过程为有效地开发高质量的软件提供准一个旧的软件产品。一个有效的过程为有效地开发高质量的软件提供准则，它获取并提出当前技术条件下可行的最佳实践方案。因此，它可降则，它获取并提出当前技术条件下可行的最佳实践方案。因此，它可降低风险并增强预见性。低风险并增强预见性。第章关于过程的话题第章关于过程的话题目前，软件的趋势是朝着更庞大、更复杂的系统发展。软件问题可以归目前，软件的趋势是朝着更庞大、更复杂的系统发展。软件问题可以归结为开发人员面临的将一个大型复杂软件所包含的各个部分集

5、成为一个结为开发人员面临的将一个大型复杂软件所包含的各个部分集成为一个整体的难度。软件开发组织需要一种受控的工作方式，需要一个过程来整体的难度。软件开发组织需要一种受控的工作方式，需要一个过程来集成软件开发的方方面面，需要通用的方法或过程来完成以下工作：集成软件开发的方方面面，需要通用的方法或过程来完成以下工作：指导一个团队活动的顺序；指导一个团队活动的顺序；布置每个开发人员和整个团队的任务；布置每个开发人员和整个团队的任务；确定开发何种产品；确定开发何种产品；提出监控和测量一个项目的产品和活动的准则。提出监控和测量一个项目的产品和活动的准则。第章关于过程的话题第章关于过程的话题5.2 5.2

6、 主流软件开发过程简介主流软件开发过程简介在软件开发领域，许多新技术和新方法都是首先在编程领域出现，然后在软件开发领域，许多新技术和新方法都是首先在编程领域出现，然后很快地再拓展到软件生命周期的分析与设计阶段。面向对象方法正是经很快地再拓展到软件生命周期的分析与设计阶段。面向对象方法正是经历了这样的发展过程，它首先在编程领域兴起，作为一种崭新的程序设历了这样的发展过程，它首先在编程领域兴起，作为一种崭新的程序设计范型引起世人瞩目。继计范型引起世人瞩目。继Smalltalk-80之后，之后，20世纪世纪80年代又有一大批年代又有一大批面向对象的编程语言问世，标志着面向对象方法走向成熟和实用。此时

7、，面向对象的编程语言问世，标志着面向对象方法走向成熟和实用。此时，面向对象方法开始向系统设计阶段延伸，出现了如面向对象方法开始向系统设计阶段延伸，出现了如Booch86、GOOD（通用面向对象的开发）、（通用面向对象的开发）、HOOD（层次式面向对象的设计）、（层次式面向对象的设计）、OOSD（面向对象的结构设计）等一批（面向对象的结构设计）等一批OOD方法。但是这些早期的方法。但是这些早期的OOD方法方法不是以面向对象的分析（不是以面向对象的分析（OOA）为基础的，而主要是基于结构化分析。）为基础的，而主要是基于结构化分析。到到1989年之后，面向对象方法的研究重点开始转向软件生命周期的分年

8、之后，面向对象方法的研究重点开始转向软件生命周期的分析阶段，并将析阶段，并将OOA和和OOD密切地联系在一起，出现了一大批面向对象密切地联系在一起，出现了一大批面向对象的分析与设计（的分析与设计（OOA&D）方法，如）方法，如Booch方法、方法、Coad/Yourdon方法、方法、Firesmith方法、方法、Jacobon的的OOSE、Martin/Odell方法、方法、Rumbaugh等人等人OMT、Shlaer/Mellor方法等等、截至方法等等、截至1994年，公开发表并具有一年，公开发表并具有一定影响的定影响的OOA&D方法已达方法已达50多种。多种。第章关于过程的话题第章关于过程

9、的话题这种繁荣的局面表明面向对象方法已经深入到分析与设计领域，并随着这种繁荣的局面表明面向对象方法已经深入到分析与设计领域，并随着面向对象的测试、集成与演化技术的出现而发展成为一套贯穿整个软件面向对象的测试、集成与演化技术的出现而发展成为一套贯穿整个软件生命周期的方法体系。目前，大多数较规范的软件开发组织已经从分析、生命周期的方法体系。目前，大多数较规范的软件开发组织已经从分析、设计到编程、测试阶段全面地采用面向对象方法，使面向对象无可置疑设计到编程、测试阶段全面地采用面向对象方法，使面向对象无可置疑地成为当前软件领域的主流技术。地成为当前软件领域的主流技术。任何技术和方法的发展，都要经历群雄

10、并起到大浪淘沙的过程，面向对任何技术和方法的发展，都要经历群雄并起到大浪淘沙的过程，面向对象方法的发展也不例外。经过几轮淘汰，表达工具已从上世纪年代象方法的发展也不例外。经过几轮淘汰，表达工具已从上世纪年代的无序格局到今天的一统天下，而经得住时间考验的软件开发过的无序格局到今天的一统天下，而经得住时间考验的软件开发过程也已为数不多。下面，我们将简单介绍几个当前的主流软件开发过程。程也已为数不多。下面，我们将简单介绍几个当前的主流软件开发过程。5.2.1 5.2.1 统一软件开发过程（统一软件开发过程（The Unified Software Devolopment The Unified So

11、ftware Devolopment ProcessProcess，RUPRUP）RUP是重型方法论的典型代表，它的核心理念是：是重型方法论的典型代表，它的核心理念是：“用例驱动、以架构用例驱动、以架构为中心、迭代和增量的软件开发过程。为中心、迭代和增量的软件开发过程。”它也是三位创建人的共它也是三位创建人的共同主张。它把整个软件开发过程分成了四个阶段：初始（先启）、精化、同主张。它把整个软件开发过程分成了四个阶段：初始（先启）、精化、构建、交付（产品化），而每个阶段又可以细分为多个迭代，如图构建、交付（产品化），而每个阶段又可以细分为多个迭代，如图5.15.1所所示。示。第章关于过程的话题第

12、章关于过程的话题图图5.1 RUP5.1 RUP软件开发过程软件开发过程第章关于过程的话题第章关于过程的话题图图5.15.1是是RUPRUP的一个核心概念图，它诠释了的一个核心概念图，它诠释了RUPRUP提倡的过程精髓。图解如提倡的过程精髓。图解如下：下：1.1.图的横轴表示项目的生命周期，也就是时间轴；图的横轴表示项目的生命周期，也就是时间轴；2.2.横轴上划分了四个阶段，每个阶段又会有横轴上划分了四个阶段，每个阶段又会有1 1N N个迭代，迭代个数的多个迭代，迭代个数的多少视阶段工作进展而定；少视阶段工作进展而定；3.3.图的纵轴罗列了项目中可能实施的工作流程；图的纵轴罗列了项目中可能实施

13、的工作流程；4.4.每个工作流程都在横轴上有一个波形图，用来表示它在时间线上工作每个工作流程都在横轴上有一个波形图，用来表示它在时间线上工作量的起伏变化。量的起伏变化。图中四个阶段很容易让人迷惑，我们来简单解释一下：图中四个阶段很容易让人迷惑，我们来简单解释一下： 先启阶段先启阶段 - - 明确项目目标和范围，其主要任务是理解与分析需求，生明确项目目标和范围，其主要任务是理解与分析需求，生成用例模型框架，对优先级较高的用例进行细化。成用例模型框架，对优先级较高的用例进行细化。精化阶段精化阶段 - - 确立系统架构和技术方向，完成部分优先级最高的用例开确立系统架构和技术方向，完成部分优先级最高的

14、用例开发，并完善所有的用例模型。发，并完善所有的用例模型。构建阶段构建阶段 - - 大规模并行实施设计、开发、单元测试，即经多次迭代，大规模并行实施设计、开发、单元测试，即经多次迭代，逐渐完成不同优先级的用例开发。逐渐完成不同优先级的用例开发。产品化阶段产品化阶段 - - 产品验收、部署、发布，即进行各种功能、性能测试，产品验收、部署、发布，即进行各种功能、性能测试，对其进行产品化、部署，完成整个系统的开发工作。对其进行产品化、部署，完成整个系统的开发工作。 第章关于过程的话题第章关于过程的话题在在RUPRUP中，需求、设计、编码与测试不再是过程阶段，而是工作流程，中，需求、设计、编码与测试不

15、再是过程阶段，而是工作流程，从图从图5.15.1中已经明确表明这些工作几乎存在于生命周期的每个阶段，只中已经明确表明这些工作几乎存在于生命周期的每个阶段，只是不同的阶段工作量有多有少而已。每个阶段的目标不一样，工作的侧是不同的阶段工作量有多有少而已。每个阶段的目标不一样，工作的侧重点自然不同，但上述四个工作流程却一个都不能少。通过各个工作流重点自然不同，但上述四个工作流程却一个都不能少。通过各个工作流程的配合，实现阶段目标的演进，最终实现产品化。程的配合，实现阶段目标的演进，最终实现产品化。 对事物从认知到理解，是一个由抽象到具体的演化过程。软件开发也是对事物从认知到理解，是一个由抽象到具体的

16、演化过程。软件开发也是一样，起初是一些表象和问题，经过第一次迭代理解了表象和解决了一一样，起初是一些表象和问题，经过第一次迭代理解了表象和解决了一些问题，但又产生了新的问题，在经过第二次迭代解决了第一次的问题些问题，但又产生了新的问题，在经过第二次迭代解决了第一次的问题之后，可能又会产生第二次的问题之后，可能又会产生第二次的问题. 这样反反复复，从二维的角度看好像是原地踏步，但从三维的角度看，这样反反复复，从二维的角度看好像是原地踏步，但从三维的角度看，在理解事物本质的纵向上我们却有了很大的进展。项目范围在一段时间在理解事物本质的纵向上我们却有了很大的进展。项目范围在一段时间内是相对稳定的，那

17、么迭代的周期也是固定的。但从宏观上看，这个迭内是相对稳定的，那么迭代的周期也是固定的。但从宏观上看，这个迭代还会持续下去，就像代还会持续下去，就像officeoffice从从9797到现在，十多年间历经了多少迭代！到现在，十多年间历经了多少迭代！有两种办法可以结束迭代：有两种办法可以结束迭代： 1 1）限定项目范围，这样问题域是有限的；）限定项目范围，这样问题域是有限的；2 2）终止项目。）终止项目。 第章关于过程的话题第章关于过程的话题5.2.2 5.2.2 测试驱动开发（测试驱动开发（Test-Driven DevelopmentTest-Driven Development，TDDTDD

18、） 1.1.什么是什么是TDDTDD测试驱动开发是敏捷开发中的一项核心实践和技术，也是一种设计方法测试驱动开发是敏捷开发中的一项核心实践和技术，也是一种设计方法论。的原理是在开发功能代码之前，先编写单元测试用例代码，论。的原理是在开发功能代码之前，先编写单元测试用例代码，以测试代码来确定需要编写什么产品代码。以测试代码来确定需要编写什么产品代码。的基本思路就是通过测试来推动整个开发的进行，但测试驱动开的基本思路就是通过测试来推动整个开发的进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析、设计、编码质量控制进发并不只是单纯的测试工作，而是把需求分析、设计、编码质量控制进行量化的过程。行

19、量化的过程。我们知道工人盖房子砌墙时先用桩子拉上线，以使砖垒得笔直。木匠打我们知道工人盖房子砌墙时先用桩子拉上线，以使砖垒得笔直。木匠打造家具切割木料时，先在木头上实线打上各种各样的墨线，这样锯木头造家具切割木料时，先在木头上实线打上各种各样的墨线，这样锯木头时才不会锯偏。中的测试代码就好似我们编码时的规范之线。时才不会锯偏。中的测试代码就好似我们编码时的规范之线。第章关于过程的话题第章关于过程的话题2. TDD2. TDD的步骤的步骤的开发过程如图的开发过程如图5.2.2所示。所示。增加一个测试增加一个测试运行这个测试运行这个测试改变一些代码改变一些代码运行这个测试运行这个测试失败失败成功成

20、功失败失败成功成功图图5.2 TDD5.2 TDD开发过程开发过程第章关于过程的话题第章关于过程的话题在图在图5.25.2中，首先根据用户需求，增加一个测试（开始测试代码的编写），中，首先根据用户需求，增加一个测试（开始测试代码的编写），运行这个测试，如果编译失败，则添加或者改变一些代码（开始编码）运行这个测试，如果编译失败，则添加或者改变一些代码（开始编码）后，再次运行测试，如果还失败，则重复修改代码，直到成功。然后循后，再次运行测试，如果还失败，则重复修改代码，直到成功。然后循环增加下一个测试。环增加下一个测试。我们用更为详细的红绿金（重构）三色六步图来进一步讲解测试驱动开我们用更为详细的

21、红绿金（重构）三色六步图来进一步讲解测试驱动开发的过程循环，如图发的过程循环，如图5.35.3所示。所示。图图5.3 5.3 测试驱动开发循环图测试驱动开发循环图编译编译为新功能写为新功能写一个测试一个测试运行测试观运行测试观察编译错误察编译错误编写一些代码编写一些代码按照需求重构按照需求重构代码编译通过代码编译通过重新运行重新运行测试通过测试通过开始开始TDDTDD过程过程红色步骤红色步骤绿色步骤绿色步骤金色步骤金色步骤第章关于过程的话题第章关于过程的话题图图5.35.3的步骤为：的步骤为：1.1.写一个单一的测试。写一个单一的测试。2.2.编译它。这时因为我们没有编写任何代码，编译肯定通不

22、过。编译它。这时因为我们没有编写任何代码，编译肯定通不过。3.3.添加一些代码使其能通过编译。这时我们对添加代码没有太多的要求，添加一些代码使其能通过编译。这时我们对添加代码没有太多的要求，只要刚刚能通过测试即可。只要刚刚能通过测试即可。4.4.运行这个测试，观察编译结果，如果未通过，重复上一步，如果通过则运行这个测试，观察编译结果，如果未通过，重复上一步，如果通过则进入下一步。进入下一步。5.5.迭代式的重构添加的代码。迭代式的重构添加的代码。6.6.重复增加下一个测试。重复增加下一个测试。从以上步骤可以看出，我们在明确要开发的某个功能后，首先思考如何对从以上步骤可以看出，我们在明确要开发的

23、某个功能后，首先思考如何对这个功能进行测试，快速完成针对此功能的测试用例编写，而缺少对象的这个功能进行测试，快速完成针对此功能的测试用例编写，而缺少对象的测试代码肯定无法通过编译，这时编译器一般会出现红色编译错误提示，测试代码肯定无法通过编译，这时编译器一般会出现红色编译错误提示，简称为简称为“红色步骤红色步骤”；根据错误提示，编写对应的功能代码以满足测试用；根据错误提示，编写对应的功能代码以满足测试用例直到测试通过，这时编译器会显示绿色编译通过的进度条，简称为例直到测试通过，这时编译器会显示绿色编译通过的进度条，简称为“绿绿色步骤色步骤”；在绿色步骤过程中持续进行代码重构，使功能优化、效率提

24、升，；在绿色步骤过程中持续进行代码重构，使功能优化、效率提升，代码逐步完善，追求代码逐步完善，追求“金色代码金色代码”，简称为，简称为“金色步骤金色步骤”。至此，一项功。至此，一项功能完成，然后循环添加其它功能，直到完成全部功能的开发。能完成，然后循环添加其它功能，直到完成全部功能的开发。第章关于过程的话题第章关于过程的话题5.2.3 5.2.3 极限编程（极限编程（Extereme Programming,XPExtereme Programming,XP） 极限编程是一种较有影响的轻量级软件开发方法论。轻量开发方法是相极限编程是一种较有影响的轻量级软件开发方法论。轻量开发方法是相对于传统的

25、重量开发方法而言。简单地理解，对于传统的重量开发方法而言。简单地理解，“量量”的轻重是指用于软的轻重是指用于软件过程管理和控制的、除程序量以外的件过程管理和控制的、除程序量以外的“文档量文档量”的多少。的多少。XPXP等轻量开等轻量开发方法认识到，在当前很多情况下，按传统观念建立的大量文档，一方发方法认识到，在当前很多情况下，按传统观念建立的大量文档，一方面需要消耗大量开发资源，同时却已失去帮助面需要消耗大量开发资源，同时却已失去帮助“预见、管理、决策和控预见、管理、决策和控制的依据制的依据”的作用。因此必须重新审视开发环节，去除臃肿累赘，轻装的作用。因此必须重新审视开发环节，去除臃肿累赘，轻

26、装上阵。上阵。XPXP的主要特征是要适应环境变化和需求变化，充分发挥开发人员的主动的主要特征是要适应环境变化和需求变化，充分发挥开发人员的主动精神。在精神。在XPXP的项目开发中，首先引入了四个变量：成本、时间、质量和的项目开发中，首先引入了四个变量：成本、时间、质量和范围，通过研究变量之间的相互作用，将项目开发分析得更加透彻，成范围，通过研究变量之间的相互作用，将项目开发分析得更加透彻，成功讲述一个项目成功的原则。功讲述一个项目成功的原则。XP XP 强调四种价值：交流，简单，回馈，勇气。强调四种价值：交流，简单，回馈，勇气。 程序员之间紧密的相互程序员之间紧密的相互交流，程序员也和客户紧密

27、的交流。他们总是保持他们的设计简单明了。交流，程序员也和客户紧密的交流。他们总是保持他们的设计简单明了。项目一开始，项目一开始，XP XP 就强调通过对软件的不断测试来获得反馈，程序员尽可就强调通过对软件的不断测试来获得反馈，程序员尽可能早的把软件交给客户，并实现客户对软件需求提出的变化。有了这些能早的把软件交给客户，并实现客户对软件需求提出的变化。有了这些基础，基础，XP XP 程序员就可以自信的面对需求和软件技术的变化。程序员就可以自信的面对需求和软件技术的变化。 第章关于过程的话题第章关于过程的话题极限编程是一套快速开发高质量软件的方法。极限编程是一套快速开发高质量软件的方法。“极限极限

28、”意味着以最快的意味着以最快的速度获得最高的客户价值。极限编程建立在以下十二条基本原则的基础速度获得最高的客户价值。极限编程建立在以下十二条基本原则的基础上。上。1.1.计划游戏计划游戏（The Planning GameThe Planning Game）客户与开发人员合作进行项目的计划与估算。基本的程序是：客户与开发人员合作进行项目的计划与估算。基本的程序是：）客户列出系统的功能表。每个功能作为一个）客户列出系统的功能表。每个功能作为一个“用户故事用户故事”(User (User Story)Story)写出，用户故事中有功能名称、所要求的操作和应完成的功能。写出，用户故事中有功能名称、所

29、要求的操作和应完成的功能。用户故事通常写在一张卡片上。用户故事通常写在一张卡片上。）开发组估计每个用户故事需要投入多少人力，以及在给定的时间内开）开发组估计每个用户故事需要投入多少人力，以及在给定的时间内开发组有多少人力可以投入。发组有多少人力可以投入。）客户再决定用户故事的优先级，也就是开发的先后次序。然后决定）客户再决定用户故事的优先级，也就是开发的先后次序。然后决定在什么时候、多久发行一个版本。在什么时候、多久发行一个版本。2.2.频繁发布小版本频繁发布小版本（Small ReleasesSmall Releases）从最小的功能集开始，经常推出新版本。每个版本仅比前一个版本增加从最小的

30、功能集开始，经常推出新版本。每个版本仅比前一个版本增加几个新功能。在系统的开发过程中，获得有价值的反馈是非常重要的，几个新功能。在系统的开发过程中，获得有价值的反馈是非常重要的，对开发出来的系统的质量有重要的影响。系统的使用者越晚接触系统，对开发出来的系统的质量有重要的影响。系统的使用者越晚接触系统，留给开发者完善系统的时间就越少。显然，这是一个迭代过程。留给开发者完善系统的时间就越少。显然，这是一个迭代过程。第章关于过程的话题第章关于过程的话题3.3.命名一致命名一致（MetaphorMetaphor）使用容易记忆的前后一致的命名原则，以方便开发与交流。使用容易记忆的前后一致的命名原则，以方

31、便开发与交流。4.4.简单设计简单设计（Simple DesignSimple Design）因为客户的要求在不断地改变，所以使用能满足当前客户要求的最简单的因为客户的要求在不断地改变，所以使用能满足当前客户要求的最简单的设计。在保证功能的基础上，要尽可能采取简单的实现方法，以节省时间。设计。在保证功能的基础上，要尽可能采取简单的实现方法，以节省时间。5.5.测试测试（TestingTesting）编程前先写测试。测试通过之日也就是程序完成之时。极限编程中的测试编程前先写测试。测试通过之日也就是程序完成之时。极限编程中的测试包括两个方面：包括两个方面：）单元测试是程序员编写的自动化测试的程序，

32、一般用单元测试框架写）单元测试是程序员编写的自动化测试的程序，一般用单元测试框架写成，如成，如JUnitJUnit。每一个单元测试通常测试一个或几个类。单元测试用例应该。每一个单元测试通常测试一个或几个类。单元测试用例应该和被测试的代码一起发布到代码库中，没有经过测试的代码不能发布。每和被测试的代码一起发布到代码库中，没有经过测试的代码不能发布。每当发现一个错误的时候，就应该添加测试用例，以防止错误再次出现。针当发现一个错误的时候，就应该添加测试用例，以防止错误再次出现。针对错误的测试用例可以帮助开发者集中注意力检查问题是否已经得到纠正。对错误的测试用例可以帮助开发者集中注意力检查问题是否已经

33、得到纠正。）接收测试（又称功能测试）是客户进行的测试以确认系统功能运行是）接收测试（又称功能测试）是客户进行的测试以确认系统功能运行是否正常。接收测试通常测试整个系统。当给定的用户故事中所有的接收测否正常。接收测试通常测试整个系统。当给定的用户故事中所有的接收测试都通过了，用户故事就完成了。试都通过了，用户故事就完成了。测试过程也是一个迭代的过程。测试过程也是一个迭代的过程。第章关于过程的话题第章关于过程的话题6.6.代码重构代码重构（RefactoringRefactoring）去除在编程中产生的任何重复的代码。因为所有的程序都有相应的测试，去除在编程中产生的任何重复的代码。因为所有的程序都

34、有相应的测试，开发组可以大胆地整理程序，而不必顾虑影响其它的功能模块。在可能开发组可以大胆地整理程序，而不必顾虑影响其它的功能模块。在可能的情况下，开发者应该每过几个小时就做一次代码整合，然后更新代码的情况下，开发者应该每过几个小时就做一次代码整合，然后更新代码库一次。无论如何都不能超过一天不去整合代码。不断地整合将避免代库一次。无论如何都不能超过一天不去整合代码。不断地整合将避免代码的离题和支离破碎。如果不跟其他人交流，开发者就没有办法知道哪码的离题和支离破碎。如果不跟其他人交流，开发者就没有办法知道哪些代码是可以重用的。每个人都必须在最新的版本中开发，避免不应该些代码是可以重用的。每个人都

35、必须在最新的版本中开发，避免不应该产生的废码导致整合的复杂性。产生的废码导致整合的复杂性。7.7.结对编程结对编程（Pair ProgrammingPair Programming）一个版本中所有的代码都由两个人一起在一台电脑里编写。结对编程只是一个版本中所有的代码都由两个人一起在一台电脑里编写。结对编程只是提高了软件的质量，而不会加快版本发布的进度。但是，两个人结对编程提高了软件的质量，而不会加快版本发布的进度。但是，两个人结对编程会更加高效，特别是在质量上会有更好的保障，从而节省项目后期的时间。会更加高效，特别是在质量上会有更好的保障，从而节省项目后期的时间。结对编程最好的方式是：两个人肩

36、并肩地坐在电脑前，共同操作键盘和鼠结对编程最好的方式是：两个人肩并肩地坐在电脑前，共同操作键盘和鼠标。当一个人从整体考虑方法如何去适应类的时候，另外一个人就输入代标。当一个人从整体考虑方法如何去适应类的时候，另外一个人就输入代码、考虑如何具体实现方法。你需要花些时间来适应结对编程的过程，所码、考虑如何具体实现方法。你需要花些时间来适应结对编程的过程，所以在开始的时候感觉有些难以把握是很正常的。以在开始的时候感觉有些难以把握是很正常的。第章关于过程的话题第章关于过程的话题8.8.共同拥有代码共同拥有代码（Collective Code OwnershipCollective Code Owner

37、ship）共同拥有代码，鼓励任何人在任何时候对系统的任何部分提出自己新的共同拥有代码，鼓励任何人在任何时候对系统的任何部分提出自己新的想法。任何人都可以为了添加功能、修改错误而修改任何一行代码。想法。任何人都可以为了添加功能、修改错误而修改任何一行代码。团队中的每一个人都不会因为修改代码而感到不便。当然，在一开始这团队中的每一个人都不会因为修改代码而感到不便。当然，在一开始这是很难理解的，很难想象团队中的每个人都需要对系统的体系结构负责。是很难理解的，很难想象团队中的每个人都需要对系统的体系结构负责。没有一个主要的系统设计者来保持系统的完整性和系统的开发进程，这没有一个主要的系统设计者来保持系

38、统的完整性和系统的开发进程，这看上去好像会导致工作很难进行。但是，你经常会碰到这样的情况：当看上去好像会导致工作很难进行。但是，你经常会碰到这样的情况：当你问主要设计者一个问题的时候，他的回答经常答非所问。这并不是他你问主要设计者一个问题的时候，他的回答经常答非所问。这并不是他的错，因为他不可能明白程序所有的细节。不管你知道什么，你都应该的错，因为他不可能明白程序所有的细节。不管你知道什么，你都应该让整个开发团队的成员熟知你的编码部分。为了贯彻这种工作方式，就让整个开发团队的成员熟知你的编码部分。为了贯彻这种工作方式，就必须保证代码库中的代码永远都是通过测试的、最新的代码。必须保证代码库中的代

39、码永远都是通过测试的、最新的代码。代码共有的机制要比独个儿拥有代码可靠得多，尤其是当有人在开发过代码共有的机制要比独个儿拥有代码可靠得多，尤其是当有人在开发过程中离开时。程中离开时。第章关于过程的话题第章关于过程的话题9.9.持续集成持续集成（Continuous IntegrationContinuous Integration）如果不控制源代码的集成，开发者就会随意测试、集成他们认为已经很如果不控制源代码的集成，开发者就会随意测试、集成他们认为已经很好的代码。但是因为代码集成是平行的，就可能有些需要做整体测试的好的代码。但是因为代码集成是平行的，就可能有些需要做整体测试的源代码没有放在一起

40、进行整体测试，所以大多数集成的问题在开始时都源代码没有放在一起进行整体测试，所以大多数集成的问题在开始时都很难发现。很难发现。每天都要将所有的修改集成到代码库中。在集成前后，应该地每天都要将所有的修改集成到代码库中。在集成前后，应该地通过测试。通过测试。为了解决这个问题，对代码库必须引入上锁的机制。如果一个团队相对为了解决这个问题，对代码库必须引入上锁的机制。如果一个团队相对独立的话，应该有一台专门用于集成的电脑。经常集成和发布代码将会独立的话，应该有一台专门用于集成的电脑。经常集成和发布代码将会大大缩短上锁的时间，减少锁的等待时间。大大缩短上锁的时间，减少锁的等待时间。10.10.每周工作每

41、周工作4040小时小时（40-Hour Work Week40-Hour Work Week）疲惫的程序员容易出错。程序员准时下班以确保他们的健康和高效率。疲惫的程序员容易出错。程序员准时下班以确保他们的健康和高效率。在项目的关键时刻少量的超时工作是允许的，但在极限编程项目中不允在项目的关键时刻少量的超时工作是允许的，但在极限编程项目中不允许发生经常的、连续的加班。许发生经常的、连续的加班。第章关于过程的话题第章关于过程的话题11.11.现场客户现场客户（On-site CustomerOn-site Customer）开发组能够不断地和真正使用系统的客户联系。对于商业通用软件，通开发组能够不

42、断地和真正使用系统的客户联系。对于商业通用软件，通常是产品经理担任客户这一角色。这样既可以改善开发组与客户之间的常是产品经理担任客户这一角色。这样既可以改善开发组与客户之间的交流，又可以省去大量耗时耗力的文档工作。交流，又可以省去大量耗时耗力的文档工作。12.12.编码标准编码标准（Coding StandardsCoding Standards）编码标准将保证代码的一致性、易读性和可重构性。因此，所有的程序员编码标准将保证代码的一致性、易读性和可重构性。因此，所有的程序员必须以同样的方式、遵循同样的规则来编写代码。必须以同样的方式、遵循同样的规则来编写代码。5.2.4 5.2.4 特征驱动开

43、发（特征驱动开发（Feature-Driven Devolopment,FDDFeature-Driven Devolopment,FDD） 特征驱动开发的诞生有些戏剧性。当年，特征驱动开发的诞生有些戏剧性。当年，Jeff De Luca受命于危难，接受命于危难，接手了新加坡的一个大型软件开发项目。该项目不仅规模大，而且涉及了手了新加坡的一个大型软件开发项目。该项目不仅规模大，而且涉及了不同的三个商业领域，同时还要对原有的系统进行集成，并且在此之前不同的三个商业领域，同时还要对原有的系统进行集成，并且在此之前其他人已经有过一次失败的尝试。接手之后，其他人已经有过一次失败的尝试。接手之后，Jef

44、f邀请他的好友、对象邀请他的好友、对象建模专家建模专家Peter Coad担任项目的主设计师。在两人的默契配合下，项目担任项目的主设计师。在两人的默契配合下，项目取得了成功。取得了成功。第章关于过程的话题第章关于过程的话题作为该项目成功经验的总结，产生了两个重大的成果：特征驱动开发和作为该项目成功经验的总结，产生了两个重大的成果：特征驱动开发和彩色建模法。后来，彩色建模法。后来，Peter Coad使用使用FDD，开发出了杰出的建模工具，开发出了杰出的建模工具Together，成为，成为Rational Rose最有力的竞争者。最有力的竞争者。1.1.什么是什么是FDDFDDFDDFDD是一个

45、模型驱动的快速迭代开发过程，它强调的是简化、实用、易于是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、易于被开发团队接受，适用于需求经常变动的项目。简单地说，被开发团队接受，适用于需求经常变动的项目。简单地说，FDD“FDD“是一个是一个以以ArchitectureArchitecture为中心的，采用短迭代期，目标驱动的开发过程为中心的，采用短迭代期，目标驱动的开发过程”。它。它首先对整个项目建立起一个整体的模型，然后通过两周一次首先对整个项目建立起一个整体的模型，然后通过两周一次”设计功能设计功能- -实现功能实现功能”的迭代来完成项目的开发。此处的的迭代来完成项目的开发。此处的“

46、功能功能”是指是指“用户眼中最用户眼中最小的有用的功能小的有用的功能”，它是可理解的、可度量的，并且可以在有限的时间内，它是可理解的、可度量的，并且可以在有限的时间内（两周）实现。在开发过程中，开发计划的制定、报告的生成、开发进度（两周）实现。在开发过程中，开发计划的制定、报告的生成、开发进度的跟踪均是以上述的跟踪均是以上述“功能功能”为单位进行的。为单位进行的。FDDFDD认为：只有良好定义的并认为：只有良好定义的并且简单的过程才能被很好地执行。另外，由于在且简单的过程才能被很好地执行。另外，由于在FDDFDD中采用了短周期的迭中采用了短周期的迭代，最小化的功能划分法，所以可以对项目的开发进

47、程进行精确、及时的代，最小化的功能划分法，所以可以对项目的开发进程进行精确、及时的监控。监控。 第章关于过程的话题第章关于过程的话题2.2.什么是什么是“特征特征”特征是特征是FDDFDD方法论中最核心的概念，在的定义中，特征就是具有客方法论中最核心的概念，在的定义中，特征就是具有客户价值的功能。它通常是采用户价值的功能。它通常是采用“”的形式来的形式来描述的，例如描述的，例如“统计本月业务总额统计本月业务总额”（统计是（统计是actionaction，本月业务是，本月业务是objectobject，总额是，总额是resultresult）。也就是希望一开始就将软件开发团队从技术）。也就是希望

48、一开始就将软件开发团队从技术领域、技术视角中拉出来，而将注意力放在领域、技术视角中拉出来，而将注意力放在“客户价值客户价值”的体现上。的体现上。的的Feature与中的与中的“user store（用户故事）（用户故事）”和中的和中的“use case（用例）（用例）”无论是在思想上还是在形式上，基本是一致的，无论是在思想上还是在形式上，基本是一致的，它们都是试图从用户的角度以及问题域的角度来理解软件的需求。它们都是试图从用户的角度以及问题域的角度来理解软件的需求。3.FDD3.FDD过程简述过程简述与其它方法论的一个明显的区别是，致力于软件系统的实际与其它方法论的一个明显的区别是，致力于软件

49、系统的实际设计和构造，它仅仅关注进行设计和编写软件所需的特定活动和产生的工设计和构造，它仅仅关注进行设计和编写软件所需的特定活动和产生的工作成果。从与领域专家合作创建一个领域对象模型开始，结合需求作成果。从与领域专家合作创建一个领域对象模型开始，结合需求过程的信息，为开发人员创建一个特征表，接着在特征表的基础上制定一过程的信息，为开发人员创建一个特征表，接着在特征表的基础上制定一个迭代的开发计划，最后通过几个个迭代的开发计划，最后通过几个“设计、构造设计、构造”的迭代完成开发任务。的迭代完成开发任务。过程如图过程如图5.45.4所示。所示。第章关于过程的话题第章关于过程的话题开发一个开发一个整

50、体模型整体模型构造一个构造一个特征表特征表根据特征根据特征制定计划制定计划开发一个开发一个整体模型整体模型根据特征根据特征进行设计进行设计根据特征根据特征进行构造进行构造图图5.45.4过程过程4.FDD4.FDD的实践集合的实践集合）领域对象建模：为了使软件开发过程中的问题域和解决域更紧密的结）领域对象建模：为了使软件开发过程中的问题域和解决域更紧密的结合起来，非常强调合起来，非常强调“领域模型领域模型”的重要性。你可以使用传统的的重要性。你可以使用传统的图、类图来建模，也可以使用图、类图来建模，也可以使用PeterPeter的的“彩色建模法彩色建模法”来建模。来建模。）根据特征组织开发：在

51、整个开发过程中，使用）根据特征组织开发：在整个开发过程中，使用“特征特征”为主线完成任为主线完成任务分工、任务实现、进度监控等。务分工、任务实现、进度监控等。）类的所有者：一个类有且只有一个所有者，即一个类只能由一名开发）类的所有者：一个类有且只有一个所有者，即一个类只能由一名开发人员进行设计及编码。采用这种方式是十分有效的，因为开发人员会感觉人员进行设计及编码。采用这种方式是十分有效的，因为开发人员会感觉他拥有了部分属于自已的代码，他会以此为荣；此外，它还可以保证相关他拥有了部分属于自已的代码，他会以此为荣；此外，它还可以保证相关代码的一致性。如果此类中包含有复杂的算法，那么可以再增加一名专

52、门代码的一致性。如果此类中包含有复杂的算法，那么可以再增加一名专门负责算法的开发人员。虽然负责算法的开发人员。虽然FDDFDD是面向用户功能的，而不是面向类的，但是面向用户功能的，而不是面向类的，但用户最终关心的是他们所需要的功能，而并不关心在开发时采用何种框架用户最终关心的是他们所需要的功能，而并不关心在开发时采用何种框架模式，所以以类为单位进行人员分配与开发的宗旨并不矛盾。模式，所以以类为单位进行人员分配与开发的宗旨并不矛盾。 第章关于过程的话题第章关于过程的话题）特征开发小组：在中，将形成动态矩阵式管理。一方面是从）特征开发小组：在中，将形成动态矩阵式管理。一方面是从解决领域入手，每个类

53、都有一个责任人；另一方面则是从问题域入手，解决领域入手，每个类都有一个责任人；另一方面则是从问题域入手，每一个特征也有一个责任人。并将相关的特征组织成特征集，建立特征每一个特征也有一个责任人。并将相关的特征组织成特征集，建立特征开发小组，承担特征、特征集开发的任务。开发小组，承担特征、特征集开发的任务。）审查：通过代码审查、设计审查、同级评审等机制来强调每个）审查：通过代码审查、设计审查、同级评审等机制来强调每个环节的质量保证。审查的目的是质量控制，而不是绩效考核。环节的质量保证。审查的目的是质量控制，而不是绩效考核。）定期构造：是一个迭代的过程，在开发中将特征分配到几个迭）定期构造：是一个迭

54、代的过程，在开发中将特征分配到几个迭代过程中去，每次迭代都将产生一个可执行的中间产品，这为定期构造提代过程中去，每次迭代都将产生一个可执行的中间产品，这为定期构造提供了可能，也使得在开发的过程中能够定期构造出一些可进行质量度量的供了可能，也使得在开发的过程中能够定期构造出一些可进行质量度量的工作成果。工作成果。）配置管理：在的多次迭代过程中将产生众多的中间版本，因）配置管理：在的多次迭代过程中将产生众多的中间版本，因此，如果没有有效的配置管理，系统的开发过程将会乱了套。此，如果没有有效的配置管理，系统的开发过程将会乱了套。）可视的结果报告：定期构造可以使得开发过程中能够不断地产生）可视的结果报

55、告：定期构造可以使得开发过程中能够不断地产生“可可视视”的中间结果，这使得进度更加容易得到监控。另外，还创建了的中间结果，这使得进度更加容易得到监控。另外，还创建了一种可视化的项目进度报表格式，使得进度情况一目了然。一种可视化的项目进度报表格式，使得进度情况一目了然。第章关于过程的话题第章关于过程的话题以上所介绍的几种目前主流的软件开发过程，无论是强调文档的重量级方以上所介绍的几种目前主流的软件开发过程，无论是强调文档的重量级方法论如统一过程，还是强调人和协作的轻量级敏捷方法论，都有一个共同法论如统一过程，还是强调人和协作的轻量级敏捷方法论，都有一个共同的特点，那就是的特点，那就是迭代的、增量

56、的迭代的、增量的开发过程。这并不是一种偶然，而是为了开发过程。这并不是一种偶然，而是为了更好地适应变化的一种必然选择。更好地适应变化的一种必然选择。5.3 5.3 理解开发过程理解开发过程在前面各章中，我们以在前面各章中，我们以“个人图书管理系统个人图书管理系统”为例，以作为工具，为例，以作为工具，介绍了如何使用面向对象方法对应用系统进行分析和设计，分别阐述了介绍了如何使用面向对象方法对应用系统进行分析和设计，分别阐述了体现业务领域知识的问题域模型的建立、实现系统需求整合的用例模型体现业务领域知识的问题域模型的建立、实现系统需求整合的用例模型的建立、通过健壮性分析来实现从需求分析到设计的过渡、

57、以及使用交的建立、通过健壮性分析来实现从需求分析到设计的过渡、以及使用交互模型进行详细设计等四个方面的内容。在介绍上述内容的过程中，我互模型进行详细设计等四个方面的内容。在介绍上述内容的过程中，我们把重点放在每种方法的局部应用中，这容易让人产生们把重点放在每种方法的局部应用中，这容易让人产生“只见树木，不只见树木，不见森林见森林”的错觉，而这同时也是应用面向对象方法中可能犯的错误之一。的错觉，而这同时也是应用面向对象方法中可能犯的错误之一。为此，我们在上一节介绍了主流的开发过程，而在这一节将结合我们的为此，我们在上一节介绍了主流的开发过程，而在这一节将结合我们的例子对开发过程进行归纳和总结，以

58、便我们既见到了树木，也见到了森例子对开发过程进行归纳和总结，以便我们既见到了树木，也见到了森林。林。第章关于过程的话题第章关于过程的话题5.3.1 5.3.1 模型的演化过程模型的演化过程我们在前四章中所介绍的内容，可以归纳为图我们在前四章中所介绍的内容，可以归纳为图5.5所示的模型演化过程。所示的模型演化过程。用户界面原型用户界面原型软件需求软件需求动态模型动态模型用例模型用例模型健壮性分析图健壮性分析图交互模型交互模型静态模型静态模型概念模型概念模型类模型类模型代码代码图图5.55.5模型演化过程模型演化过程第章关于过程的话题第章关于过程的话题由图由图5.5中，我们可以归纳出涉及到的各种模

59、型的演化过程中，我们可以归纳出涉及到的各种模型的演化过程:）从需求出发，创建问题域一静一动两个模型：概念模型）从需求出发，创建问题域一静一动两个模型：概念模型和用例模型。首先利用和用例模型。首先利用“名词动词法名词动词法”从需求描述中提取相从需求描述中提取相应的类来建立概念模型，并添加主要属性及识别它们之间的应的类来建立概念模型，并添加主要属性及识别它们之间的关联关系；对于较复杂的应用系统，则必须首先进行业务分关联关系；对于较复杂的应用系统，则必须首先进行业务分析，建立业务模型后再建立概念模型。其次根据用户需求编析，建立业务模型后再建立概念模型。其次根据用户需求编写用例描述、绘制用例图，建立包

60、括用例描述和用例图在内写用例描述、绘制用例图，建立包括用例描述和用例图在内的用例模型，此时可以进行用户界面原型的创建，从中发现的用例模型，此时可以进行用户界面原型的创建，从中发现用户的使用场景，建立开发人员与用户之间进行沟通的共同用户的使用场景，建立开发人员与用户之间进行沟通的共同基础。用户界面模型的创建既可以使用可视化语言，也可以基础。用户界面模型的创建既可以使用可视化语言，也可以简单地使用绘制草图的方式来实现。简单地使用绘制草图的方式来实现。第章关于过程的话题第章关于过程的话题）在用例模型的基础上，进行健壮性分析，目的是发现实）在用例模型的基础上，进行健壮性分析，目的是发现实体类、控制类和