02第二章：软件过程报告

软件工程过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。

本章讲述在软件生命周期全过程中应该完成的基本任务，并介绍各种常用的过程模型。第二章：软件过程2.1软件生命周期的基本任务2.2瀑布模型2.3快速原型模型2.4增量模型2.5螺旋模型2.6喷泉模型2.7Rational统一过程2.8敏捷过程与极限编程2.9能力成熟度模型第二章：软件过程1.软件定义：确定软件开发工程必须完成的总目标；确定工程的可行性；导出实现工程目标应该采用的策略及系统必须完成的功能；估计完成该项工程需要的资源和成本，并且制订工程进度表。这个时期的工作通常又称为系统分析，由系统分析员负责完成。软件定义时期通常进一步划分为3个阶段，即问题定义、可行性研究和需求分析。软件生命周期：2.软件开发：具体设计和实现在前一个时期定义的软件，它通常由下述4个阶段组成：概要设计、详细设计、编码和单元测试、综合测试。其中前两个阶段又称为系统设计，后两个阶段又称为系统实现。软件生命周期：3.运行维护：当软件在使用过程中发现错误时应该加以改正；当环境改变时应该修改软件以适应新的环境；当用户有新要求时应该及时改进软件以满足用户的新需要。通常对维护时期不再进一步划分阶段，但是每一次维护活动本质上都是一次压缩和简化了的定义和开发过程。软件生命周期：

通过调研，系统分析员应该提出关于问题性质、工程目标和工程规模的书面报告，并且需要得到客户对这份报告的确认。2.1.1问题定义确定上一个阶段的问题是否有行得通的解决办法用最小的代价在尽可能短的时间内确定问题是否能够解决。2.1.2可行性研究解决“目标系统必须做什么”这个问题可行性研究的基本目的是用较小的成本在较短的时间内确定是否存在可行的解法，因此许多细节被忽略了。然而在最终的系统中却不能遗漏任何一个微小的细节是用正式文档准确地记录对目标系统的需求，该文档通常称为规格说明书（specification）。2.1.3需求分析概括地回答“怎样实现目标系统？”概要设计又称为初步设计、逻辑设计、高层设计或总体设计。设计几种可能的方案推荐最佳方案制定详细计划模块化2.1.4概要设计将抽象概括的方式具体化“应该怎样具体地实现这个系统”设计出程序的详细规格说明详细设计也称为模块设计、物理设计或低层设计。在这个阶段将详细地设计每个模块，确定实现模块功能所需要的算法和数据结构。2.1.5详细设计这个阶段的关键任务是写出正确的，容易理解、容易维护的程序模块程序员应该根据目标系统的性质和实际环境，选取一种适当的高级程序设计语言（必要时用汇编语言），把详细设计的结果翻译成用选定的语言书写的程序，并且仔细测试编写出的每一个模块。2.1.6编码和单元测试这个阶段的关键任务是通过各种类型的测试（及相应的调试）使软件达到预定的要求。最基本的测试是集成测试和验收测试。必要时还可以再通过现场测试或平行运行等方法对目标系统进一步测试检验。2.1.7综合测试集成测试是根据设计的软件结构，把经过单元测试检验的模块按某种选定的策略装配起来，在装配过程中对程序进行必要的测试。验收测试则是按照规格说明书的规定（通常在需求分析阶段确定），由用户（或在用户积极参加下）对目标系统进行验收。2.1.7综合测试通过各种必要的维护活动使系统持久地满足用户的需要。改正性维护：也就是诊断和改正在使用过程中发现的软件错误适应性维护：即修改软件以适应环境的变化2.1.8软件维护完善性维护：即根据用户的要求改进或扩充软件使它更完善预防性维护：即修改软件为将来的维护活动预先做准备。2.1.8软件维护实际上每一项维护活动都应该经过提出维护要求（或报告问题），分析维护要求，提出维护方案，审批维护方案，确定维护计划，修改软件设计，修改程序，测试程序，复查验收等一系列步骤。因此，实质上是经历了一次压缩和简化了的软件定义和开发的全过程。每一项维护活动都应该准确地记录下来，作为正式的文档资料加以保存。2.1.8软件维护2.1软件生命周期的基本任务2.2瀑布模型2.3快速原型模型2.4增量模型2.5螺旋模型2.6喷泉模型2.7Rational统一过程2.8敏捷过程与极限编程2.9能力成熟度模型第二章：软件过程在20世纪80年代之前，瀑布模型（waterfallmodel）一直是唯一被广泛采用的生命周期模型，现在它仍然是软件工程中应用最广泛的过程模型。图2.1所示为传统的瀑布模型。2.2瀑布模型2.2瀑布模型图2.1传统的瀑布模型1.阶段间具有顺序性和依赖性

①必须等前一阶段的工作完成之后，才能开始后一阶段的工作；②前一阶段的输出文档就是后一阶段的输入文档。2.推迟实现的观点

实践表明，对于规模较大的软件项目来说，往往编码开始得越早最终完成开发工作所需要的时间反而越长。传统的瀑布模型的特点3.质量保证的观点①每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。②每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。传统的瀑布模型的特点传统的瀑布模型过于理想化了。事实上，人在工作过程中不可能不犯错误。因此，实际的瀑布模型是带“反馈环”的，如图2.2所示（图中实线箭头表示开发过程，虚线箭头表示维护过程）。当在后面阶段发现前面阶段的错误时，需要沿图中左侧的反馈线返回前面的阶段，修正前面阶段的产品之后再回来继续完成后面阶段的任务。2.2瀑布模型2.2瀑布模型图2.2加入迭代过程的瀑布模型可强迫开发人员采用规范的方法严格地规定了每个阶段必须提交的文档要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证瀑布模型的优点瀑布模型是由文档驱动的”：在可运行的软件产品交付给用户之前，用户只能通过文档来了解产品是什么样的。很可能最终开发出的软件产品不能真正满足用户的需要。瀑布模型的缺点（1）用户的需求非常清楚全面，且在开发过程中没有或很少变化（2）开发人员对软件的应用领域很熟悉（3）用户的使用环境非常稳定（4）开发工作对用户参与的要求很低瀑布模型的适用范围2.1软件生命周期的基本任务2.2瀑布模型2.3快速原型模型2.4增量模型2.5螺旋模型2.6喷泉模型2.7Rational统一过程2.8敏捷过程与极限编程2.9能力成熟度模型第二章：软件过程快速原型（rapidprototype）是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。如图2.3所示（图中实线箭头表示开发过程，虚线箭头表示维护过程）2.3快速原型模型2.3快速原型模型图2.3快速模型原型优点：快速原型模型是不带反馈环的，软件产品的开发基本上是按线性顺序进行的。原型系统已经通过与用户交互而得到验证，据此产生的规格说明文档正确地描述了用户需求。开发人员通过建立原型系统已经学到了许多东西，在设计和编码阶段发生错误的可能性也比较小。2.3快速原型模型快速原型的本质是“快速”。开发人员应该尽可能快地建造出原型系统，以加速软件开发过程，节约软件开发成本。原型的用途是获知用户的真正需求，一旦需求确定了，原型将被抛弃。当快速原型的某个部分是利用软件工具由计算机自动生成的时候，可以把这部分用到最终的软件产品中。2.3快速原型模型（1）对所开发的领域比较熟悉而且有快速的原型开发工具（2）项目招投标时，可以以原型模型作为软件的开发模型（3）进行产品移植或升级时，或对已有产品原型进行客户化工作时，原型模型是非常适合的2.3快速原型模型的适用范围2.1软件生命周期的基本任务2.2瀑布模型2.3快速原型模型2.4增量模型2.5螺旋模型2.6喷泉模型2.7Rational统一过程2.8敏捷过程与极限编程2.9能力成熟度模型第二章：软件过程增量模型也称为渐增模型，如图2.4所示。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。2.4增量模型2.4增量模型图2.4增量模型增量模型分批地逐步向用户提交产品，每次提交一个满足用户需求子集的可运行的产品。整个软件产品被分解成许多个增量构件，开发人员一个构件接一个构件地向用户提交产品。每次用户都得到一个满足部分需求的可运行的产品，直到最后一次得到满足全部需求的完整产品。2.4增量模型难点：把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。此外，必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便。2.4增量模型从某种意义上说，增量模型本身是自相矛盾的。它一方面要求开发人员把软件看做一个整体，另一方面又要求开发人员把软件看做构件序列，每个构件本质上都独立于另一个构件。除非开发人员有足够的技术能力协调好这一明显的矛盾，否则用增量模型开发出的产品可能并不令人满意。2.4增量模型（1）进行已有产品升级或新版本开发，增量模型是非常适合的；（2）对完成期限严格要求的产品，可以使用增量模型；（3）对所开发的领域比较熟悉而且已有原型系统，增量模型也是非常适合的。2.4增量模型的适用范围2.1软件生命周期的基本任务2.2瀑布模型2.3快速原型模型2.4增量模型2.5螺旋模型2.6喷泉模型2.7Rational统一过程2.8敏捷过程与极限编程2.9能力成熟度模型第二章软件过程使用原型及其他方法来尽量降低风险。理解这种模型的一个简便方法，是把它看做在每个阶段之前都增加了风险分析过程的快速原型模型，如图2.5所示。图中带箭头的点画线的长度代表当前累计的开发费用，螺线旋过的角度值代表开发进度。基本思想2.5螺旋模型图2.5螺旋模型设计上的灵活性，可以在项目的各个阶段进行变更；以小的分段来构建大型系统，使成本计算变得简单容易；客户始终参与每个阶段的开发，保证了项目不偏离正确方向以及项目的可控性；随着项目推进，客户始终掌握项目的最新信息，

从而能够和管理层有效地交互。优点（1）采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失；（2）过多的迭代次数会增加开发成本，延迟提交时间。缺点螺旋模型主要适用于内部开发的大规模软件项目。如果进行风险分析的费用接近整个项目的经费预算，则风险分析是不可行的。事实上，项目越大，风险也越大，因此，进行风险分析的必要性也越大。螺旋模型的主要优势在于，它是风险驱动的，但是，这也可能是它的一个弱点。2.5螺旋模型2.1软件生命周期的基本任务2.2瀑布模型2.3快速原型模型2.4增量模型2.5螺旋模型2.6喷泉模型2.7Rational统一过程2.8敏捷过程与极限编程2.9能力成熟度模型第二章：软件过程迭代是软件开发过程中普遍存在的一种内在属性。经验表明，软件过程各个阶段之间的迭代或一个阶段内各个工作步骤之间的迭代，在面向对象范型中比在结构化范型中更常见。图2.6所示的喷泉模型是典型的面向对象生命周期模型。“喷泉”这个词体现了面向对象软件开发过程迭代和无缝的特性。2.6喷泉模型2.6喷泉模型图2.6喷泉模型为避免使用喷泉模型开发软件时开发过程过分无序，应该把一个线性过程（例如，快速原型模型或螺旋模型中的中心垂线）作为总目标。但是，同时也应该记住，面向对象范型本身要求经常对开发活动进行迭代或求精。2.6喷泉模型喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。优点其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。可以从任何一个阶段（圆圈）转到其它一个阶段。即，在整个过程中补漏、拾遗、纠错的切入点大大增多，受到的阶段性的限制较少。优点由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。喷泉模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。缺点2.1软件生命周期的基本任务2.2瀑布模型2.3快速原型模型2.4增量模型2.5螺旋模型2.6喷泉模型2.7Rational统一过程2.8敏捷过程与极限编程2.9能力成熟度模型第二章：软件过程Rational统一过程（rationalunifiedprocess，RUP）是由Rational软件公司（已被IBM并购）推出的一个软件开发过程框架。所谓软件开发过程框架是指团队可以根据具体的项目组或软件开发企业的不同需求，能够定义、配置、定制和实施一致的软件开发过程。2.7Rational统一过程1.用于成功开发软件的一组基本观念和原则。2.一套关于可重用方法内容和过程构建的框架。3.基础的方法和过程定义语言。RUP核心元素2.7.1最佳实践1.迭代式开发：迭代式开发允许在每次迭代过程中需求发生变化，这种开发方法通过一系列细化来加深对问题的理解，因此能更容易地容纳需求的变更。也可以把软件开发过程看做是一个风险管理过程，迭代式开发通过采用可验证的方法来减少风险。图2.7迭代式开发2.管理需求：在开发软件的过程中，客户需求将不断地发生变化，因此，确定系统的需求是一个连续的过程。RUP描述了如何提取、组织系统的功能性需求和约束条件并把它们文档化。RUP采用用例分析来捕获需求，并由它们驱动设计和实现。2.7.1最佳实践3.使用基于组件的架构：所谓组件就是功能清晰的模块或子系统。系统可以由已经存在的、由第三方开发商提供的组件构成，因此组件使软件重用成为可能。RUP提供了使用现有的或新开发的组件定义架构的系统化方法，从而有助于降低软件开发的复杂性，提高软件重用率。2.7.1最佳实践4.可视化建模：RUP与可视化的统一建模语言（UnifiedModelingLanguage，UML）紧密地联系在一起，在开发过程中建立起软件系统的可视化模型，可以帮助人们提高管理软件复杂性的能力。2.7.1最佳实践5.验证软件质量：某些软件不受用户欢迎的一个重要原因，是其质量低下。在软件投入运行后再去查找和修改出现的问题，比在开发的早期阶段就进行这项工作需要花费更多的人力和时间。在RUP中，软件质量评估不再是一种事后的行为或由单独小组进行的孤立活动，而是内建在贯穿于整个开发过程的、由全体成员参与的所有活动中。2.7.1最佳实践6.控制软件变更：在变更是不可避免的环境中，必须具有管理变更的能力，才能确保每个修改都是可接受的而且能被跟踪的。RUP描述了如何控制、跟踪和监控修改，以确保迭代开发的成功。2.7.1最佳实践（1）前景：制定前景

有一个清晰的前景是开发一个满足项目干系人（stakeholder）需求的产品的关键。前景（vision）给更详细的技术需求提供了一个高层的、有时候是合同式的基础。前景的内容将回答以下问题：

关键术语是什么？（词汇表）2.7.2RUP的十大要素

我们要尝试解决什么问题？（问题声明）

谁是项目干系人？谁是用户？他们的需要是什么？

产品的特性是什么？

功能性需求是什么？（用例）

非功能性需求是什么？

设计约束是什么？2.7.2RUP的十大要素（2）计划：按计划管理

在RUP中，软件开发计划（softwaredevelopmentplan，SDP）综合了管理项目所需的各种信息，也许会包括一些在先启阶段开发的单独的内容。SDP必须在整个项目中被维护和更新。2.7.2RUP的十大要素（3）风险：降低风险并跟踪相关问题RUP的要点之一是在项目早期就标识并处理最大的风险。项目组标识的每一个风险都应该有一个相应的缓解或解决计划。风险列表应该既作为项目活动的计划工具，又作为组织迭代的基础。2.7.2RUP的十大要素（4）业务案例：检验业务案例

业务案例主要用于为实现项目前景而制定经济计划。一旦制定之后，业务案例就用来对项目提供的投资收益率（ROI）进行精确的评估。

业务案例的描述不应深挖问题的细节，而应就为什么需要该产品树立一个有说服力的论点。2.7.2RUP的十大要素（5）架构：设计组件架构

在RUP中，软件系统的架构是指一个系统关键部件的组织或结构，组件之间通过接口交互，而组件是由一些更小的组件和接口组成的。架构由软件架构文档通过多个视图表示，每个视图都描述了某一组项目干系人所关心的系统的某个方面2.7.2RUP的十大要素（6）原型：增量地构建和测试产品RUP是为了尽早排除问题和解决风险和问题而构建、测试和评估产品的可执行版本的一种迭代方法。递增地构造和测试系统的组件，这是实施和测试规程及原则通过迭代证明价值的“要素”。2.7.2RUP的十大要素（7）评估：定期评估结果

顾名思义，RUP的迭代评估审查了迭代的结果。评估得出了迭代满足需求规范的程度，同时还包括学到的教训和实施的过程改进。根据项目的规模、风险以及迭代的特点，评估可以是对演示及其结果的一条简单的记录，也可能是一个完整的、正式的测试评审记录。2.7.2RUP的十大要素（8）变更请求：管理并控制变更RUP的配置和变更管理流程的要点是当变化发生时管理和控制项目的规模，并且贯穿整个生命周期。在RUP中，变更请求通常用于记录和跟踪缺陷和增强功能的要求，或者对产品提出的任何其他类型的变更请求。2.7.2RUP的十大要素（9）用户支持：部署可用的产品

在RUP中，部署流程的要点是包装和交付产品，同时交付有助于最终用户学习、使用和维护产品的所有必要的材料。项目组至少要给用户提供一个用户指南（也许是通过联机帮助的方式提供），可能还有一个安装指南和版本发布说明。2.7.2RUP的十大要素（10）过程：采用适合项目的过程

选择适合正开发的产品类型的流程是非常必要的。即使在选定一个流程后，也不能盲目遵循这个流程——必须应用常理和经验来配置流程和工具，以满足组织和项目的需要。2.7.2RUP的十大要素2.7.3RUP生命周期图2.8方法内容定义与方法内容在流程中的应用业务建模：深入了解使用目标系统的机构及其商业运作，评估目标系统对使用它的机构的影响。需求：捕获客户的需求，并且使开发人员和用户达成对需求描述的共识。分析与设计：把需求分析的结果转化成分析模型与设计模型。（1）核心流程实现：把设计模型转换成实现结果（形式化地定义代码结构；用构件实现类和对象；对开发出的构件进行单元测试；把不同实现人员开发出的模块集成为可执行的系统）。测试：检查各个子系统的交互与集成，验证所有需求是否都被正确地实现了，识别、确认缺陷并确保在软件部署之前消除缺陷。（1）核心流程部署：成功地生成目标系统的可运行的版本，并把软件移交给最终用户。配置与变更管理：跟踪并维护在软件开发过程中产生的所有制品的完整性和一致性。项目管理：提供项目管理框架，为软件开发项目制定计划、人员配备、执行和监控等方面的实用准则，并为风险管理提供框架。（1）核心流程环境：向软件开发机构提供软件开发环境，包括过程管理和工具支持。（1）核心流程先启阶段：建立业务模型，定义最终产品视图，并且确定项目的范围。精化阶段：设计并确定系统的体系结构，制定项目计划，确定资源需求。构建阶段：开发出所有构件和应用程序，把它们集成为客户需要的产品，并且详尽地测试所有功能。移交阶段：把开发出的产品提交给用户使用。（2）工作阶段（2）工作阶段图2.9项目的阶段和里程碑RUP强调采用迭代和渐增的方式来开发软件，整个项目开发过程由多个迭代过程组成。事实上，RUP重复一系列组成软件生命周期的循环。每个阶段又进一步细分为一次或多次迭代过程。（3）RUP迭代式开发2.1软件生命周期的基本任务2.2瀑布模型2.3快速原型模型2.4增量模型2.5螺旋模型2.6喷泉模型2.7Rational统一过程2.8敏捷过程与极限编程2.9能力成熟度模型第二章：软件过程（1）“个体和交互”胜过“过程和工具”

优秀的团队成员是软件开发项目获得成功的最重要因素，但不好的过程和工具也会使最优秀的团队成员无法发挥作用。团队成员的合作、沟通以及交互能力要比单纯的软件编程能力更为重要2.8.1敏捷过程概述（2）“可以使用的软件”胜过“面面俱到的文档”

软件开发的主要目标是向用户提供可以使用的软件而不是文档，但是，完全没有文档的软件也是一种灾难。开发人员应该把主要精力放在创建可使用的软件上面，仅当迫切需要并且具有重大意义时，才进行文档编制工作，而且所编织的内部文档应该尽量简明扼要和主题突出。2.8.1敏捷过程概述（3）“客户合作”胜过“合同谈判”

客户通常不可能做到一次性地把他们的需求完整准确地表述在合同中。能够满足客户不断变化的需求的切实可行的途径是：开发团队与客户密切协作。因此，能指导开发团队与客户协同工作的合同才是最好的合同。2.8.1敏捷过程概述（4）“响应变化”胜过“遵循计划”

软件开发过程总会有变化，这是客观存在的现实。一个软件过程必须反映现实，因此，软件过程应该有足够的能力及时响应变化。然而没有计划的项目也会因陷入混乱而失败，关键是计划必须有足够的灵活性和可塑性，在形势发生变化时能迅速调整，以适应业务、技术等方面的变化。2.8.1敏捷过程概述1.最重要的是通过尽早和持续地交付有价值的软件以满足客户需要。2.即使在开发后期也欢迎需求的变化。敏捷过程驾驭变化带给客户竞争优势。3.经常交付可以使用的软件，间隔可以从几星期到几个月，时间尺度越短越好。4.业务人员和开发人员应该在整个项目过程中每天都在一起工作。“敏捷宣言”的原则5.使用积极的开发人员进行项目，给他们提供所需环境和支持，并信任他们能够完成任务。6.在开发小组中最有效率和效果的信息传达方式是面对面的交谈。7.可以使用的软件是度量进度的主要标准。8.敏捷过程提倡的是持续开发过程。投资“敏捷宣言”的原则人、开发人员和用户应该维持一个长期稳定的步调。9.持续地追求卓越的技术与良好的设计会增加敏捷性。10.简单（尽可能减少工作量）是最重要的。11.最好的架构、需求和设计都来自于自组织的团队。

“敏捷宣言”的原则12.团队要定期总结如何提高效率，然后相应地调整自己的行为。根据上述价值观提出的软件过程统称为敏捷过程，其中应用比较广泛的是极限编程和Scrum。“敏捷宣言”的原则极限编程（extremeprogramming）是敏捷过程中最负盛名的一个，其名称中“极限”二字的含义是指把好的开发实践运用到极致。目前，极限编程已经成为一个典型的开发方法，广泛应用于需求模糊且经常改变的场合。2.8.2极限编程

客户作为开发团队的成员

使用用户素材

短交付周期

验收测试

结对编程

测试驱动开发

集体所有1．极限编程的有效实践

持续集成

可持续的开发速度

开放的工作空间

及时调整计划

简单的设计

重构

使用隐喻1．极限编程的有效实践

必须至少有一名客户代表在项目的整个开发周期中与开发人员在一起紧密地配合工作，客户代表负责确定需求、回答开发人员的问题并且设计功能验收测试方案。客户作为开发团队的成员

所谓用户素材就是正在进行的关于需求的谈话内容的助记符。根据用户素材可以合理地安排实现该项需求的时间。使用用户素材

每两周完成一次的迭代过程实现了用户的一些需求，交付出目标系统的一个可工作的版本。通过向有关的用户演示迭代生成的系统，获得他们的反馈意见。短交付周期

通过执行由客户制定的验收测试来捕获用户素材的细节。验收测试

结对编程就是由两名开发人员在同一台计算机上共同编写解决同一个问题的程序代码，通常一个人编码，另一个人对代码进行审查与测试，以保证代码的正确性与可读性。结对编程是加强开发人员相互沟通与评审的一种方式。结对编程

极限编程强调“测试先行”。在编码之前应该首先设计好测试方案，然后再编程，直至所有测试都获得通过之后才可以结束工作。测试驱动开发

极限编程强调程序代码属于整个开发小组集体所有，小组每个成员都有更改代码的权利，每个成员都对全部代码的质量负责。集体所有

极限编程主张在一天之内多次集成系统，而且随着需求的变更，应该不断地进行回归测试。持续集成

开发人员以能够长期维持的速度努力工作。XP（extremeprogramming）规定开发人员每周工作时间不超过40h，连续加班不可以超过两周，以免降低生产率。可持续的开发速度XP项目的全体参与者（开发人员、客户等）一起在一个开放的场所中工作，项目组成员在这个场所中自由地交流和讨论。开放的工作空间

计划应该是灵活的、循序渐进的。制订出项目计划之后，必须根据项目进展情况及时进行调整，没有一成不变的计划。及时调整计划

开发人员应该使设计与计划要在本次迭代过程中完成的用户素材完全匹配，设计时不需要考虑未来的用户素材。在一次次的迭代过程中，项目组成员不断变更系统设计，使之相对于正在实现的用户素材而言始终处于最优状态。简单的设计

所谓代码重构就是在不改变系统行为的前提下，重新调整和优化系统的内部结构，以降低复杂性、消除冗余、增加灵活性和提高性能。应该注意的是，在开发过程中不要过分依赖重构，特别是不能轻视设计，对于大中型系统而言，如果推迟设计或者干脆不做设计，将造成一场灾难。重构

可以将隐喻看做是把整个系统联系在一起的全局视图，它描述系统如何运作，以及用何种方式把新功能加入到系统中。使用隐喻首先，项目组针对客户代表提出的“用户故事”然后，项目组在隐喻和用户故事的基础上，根据客户设定的优先级制订交付计划最后，开始多个迭代过程，在迭代期内产生的新用户故事不在本次迭代内解决，以保证本次开发过程不受干扰。2．极限编程的整体开发过程2．极限编程的整体开发过程图2.10极限编程的整体开发过程3．极限编程的迭代过程图2.11极限编程的迭代过程

以极限编程为杰出代表的敏捷过程，可以快速、敏捷地响应变化和不确定的需求，同时仍然能够保持可持续的开发速度。上述这些特点使得敏捷过程能够较好地适应商业竞争环境下对项目提出的有限资源和有限开发时间的约束。3．极限编程的迭代过程2.1软件生命周期的基本任务2.2瀑布模型2.3快速原型模型2.4增量模型2.5螺旋模型2.6喷泉模型2.7Rational统一过程2.8敏捷过程与极限编程2.9能力成熟度模型第二章：软件过程能力成熟度模型（capabilitymaturitymodel，CMM）并不是一个软件生命周期模型，而是改进软件过程的一种策略，它与实际使用的过程模型无关。1986年美国卡内基—梅隆大学软件工程研究所首次提出能力成熟度模型（CMM），不过在当时它被称为过程成熟度模型。2.9能力成熟度模型问题是由管理软件过程的方法不当引起的，所以新软件技术的运用并不会自动提高生产率和软件质量。能力成熟度模型有助于软件开发组织建立一个有规律的、成熟的软件过程。改进后的过程将开发出质量更好的软件，使更多的软件项目免受时间和费用超支之苦。基本思想1.成熟度等级（maturitylevels）：一个成熟度等级是在朝着实现成熟软件过程进化途中的一个妥善定义的平台。5个成熟度等级构成了CMM的顶层结构。2.过程能力（processcapability）：软件过程能力描述，通过遵循软件过程能实现预期结果的程度。2.9.1能力成熟度模型的结构3.关键过程域（keyprocessareas，KPA）：每个成熟度等级由若干关键过程域组成。每个关键过程域都标识出一串相关的活动，当把这些活动都完成时所达到的一组目标，对建立该过程成熟度等级是至关重要的。2.9.1能力成熟度模型的结构4.目标（goals）：目标概括了关键过程域中的关键实践，并可用于确定一个组织或项目是否已有效地实施了该关键过程域。5.公共特性（commonfeatures）：CMM把关键实践分别归入下列5个公共特性之中：执行约定、执行能力、执行的活动、测量和分析以及验证实施。2.9.1能力成熟度模型的结构6.关键实践（keypractices）：每个关键过程域都用若干关键实践描述，实施关键实践有助于实现相应的关键过程域的目标。2.9.1能力成熟度模型的结构2.9.1能力成熟度模型的结构图2.12CMM结构1．初始级

软件过程的特征是无序的，有时甚至是混乱的。几乎没有什么过程是经过定义的，项目能否成功完全取决于个人能力。

处于这个最低成熟度等级的组织，基本上没有健全的软件工程管理制度。每件事情都以特殊的方法来做。2.9.2能力成熟度等级2．可重复级

建立了基本的项目管理过程，以追踪成本、进度和功能性。必要的过程规范已经建立起来了，使得可以重复以前类似项目所取得的成功。2.9.2能力成熟度等级3．已定义级

用于管理和工程活动的软件过程已经文档化和标准化，并且已经集成到整个组织的软件过程中。所有项目都使用文档化的、组织批准的过程来开发和维护软件。这一级包含了第2级的所有特征。2.9.2能力成熟度等级4．已管理级

已收集了软件过程和产品质量的详细度量数据，使用这些详细的度量数据，能够定量地理解和控制软件过程和产品。这一级包含了第3级的所有特征。2.9.2能力成熟度等级5．优化级

通过定量的反馈能够实现持续的过程改进，这些反馈是从过程及对新想法和技术的测试中获得的。这一级包含了第4级的所有特征。2.9.2能力成熟度等级能力成熟度模型并不详细描述所有与软件开发和维护有关的过程，但是，有一些过程是决定过程能力的关键因素，这就是CMM所称的关键过程域。关键过程域是达到一个成熟度等级的必要条件。除第1级成熟度之外，每个成熟度等级都指明了为改进其软件过程，软件开发组织应该重视的区域，同时也指明了为达到某个成熟度等级所必须解决的问题。2.9.3关键过程域（a）软件配置管理。（b）软件质量保证。（c）软件子合同管理。（d）软件项目跟踪和监督软件。（e）项目计划。（f）需求管理。1．成熟度第2级（a）同事复审。（b）组间协作。（c）软件产品工程。（d）集成的软件管理。（e）培训计划。（f）组织过程定义。（g）组织过程焦点。2．成熟度第3级（a）软件质量管理。（b）定量的过程管理。3．成熟度第4