Paul Duvall (paul.duvall@stelligent.com), CTO, Stelligent Incorporated

2006 年 10 月 23 日

由于有许多持续集成服务（CI）服务器可以选择，所以很难决定哪个适应自己。在 让开发自动化 系列的第二篇文章中，开发自动化专家 Duvall 采用一致的评估标准和很多说明性示例，介绍了一些开源 CI 服务器，包括 Continuum、CruiseControl 和 Luntbuild。

在我脑海里，我至少能想到 12 种在当前市场上可用的 CI 服务器，包括商业的和开源的。虽然它们都试图自动进行软件构建的过程，但是都有各自的优点和不足。而且，有太多工具可供选择的不良后果就是很难决定究竟应该选择使用哪个。

在选用自动化过程的工具时，要时刻记住的就是：工具要 确实适用。选择错误的工具可能会限制整体的灵活性，会导致执行简单动作反而需要更长时间，或者会把人锁定在特定的支持工具或过程。

选择 CI 服务器的标准

通常，对一个新工具的决策分析可以归结如下：

我听说 Tim 在使用 Acme Inc 的工具，而且我认为 Tim 是个聪明人。所以，我也要使用 Acme Inc 的工具。现在我也是个聪明人了。

关于本系列 作为开发人员，我们的工作就是为用户提供自动化处理；但是，我们中的许多人却忽视了自动化自己的开发过程的机会。出于这个目的，让开发自动化 这一系列的文章专门研究了自动化软件开发过程的实际应用，并教您 什么时候 和 如何 成功应用自动化。

反过来，如果您问 Tim 为什么 他选择使用 Acme Inc 的工具，您可能会发现是他的公司强制要求使用的。这就是为什么重要的是要根据 自己的 具体技术和政策需求对工具进行分析。如果不这么做，可能就会选择到不符合需求的工具，甚至更糟糕的是，不能带来任何帮助的工具。

在决策的时候，通常多数人都会把重点放在工具的特性上。但是要记住，虽然特性的确重要，但还有其他指标需要考虑。在我的实践中，我发现以下五个指标在评估工具时最有帮助：

什么是持续集成？ 持续集成（CI）是一种实践，可以让团队在持续的基础 上收到反馈并进行改进，不必等到开发周期后期才寻找和修复缺陷。诸如 CruiseControl 之类的检查工具是在后台运行的，它们轮询版本控制存储库，从中寻找更改之处。当发现某一更改时，这类工具就会通过 Ant 执行预定义的构建脚本。持续检查借助持续集成的实践得以改进。

• 特性
• 可靠性
• 寿命
• 目标环境
• 易用性

而且不要忘记，客观地 检查这五个方面也是重要的。

产品特性

说到 CI 服务器的特性，应当考虑该工具与版本控制系统的集成、处理构建平台（例如 Ant 和 Maven）的能力以及提供反馈和报告的能力。而且不要忘记检查其他特性，例如构建标号和管理项目的依赖项。最后，在需要做一些特定的增强时，理解产品的可扩展性会很有帮助。

表 1 详细说明了每个特性：

从特性的角度来说，以上提到的几点在选择所需要的正确的 CI 服务器时，至关重要。

产品可靠性

因为下载和使用开源 CI 服务器很简单，所以可以试用产品来判断它的可靠性。而且，在工具的可靠性和它在市场上的时间之间，通常存在一些相关性。使用新产品时，就会冒着有未发现的 bug 的风险。而且，用户群是发现工具出现的问题的优秀资源。大量的问题贴子或者过多的复杂问题，就表示用户对这个工具的意见较大。

因为我这里讨论的服务器是开源的，所以很容易发现下载的人数，这也会是产品健康程度的一个指示。用户少可能意味着反馈渠道少，可能需要换个地方看看。

寿命前景

在下载 CI 服务器之前，了解这个服务器未来的前景会有帮助。简单地说，使用已经死亡或正走向死亡的产品不是个好主意。可以检查该工具已经出现了多少年、在它的用户群中是否有正常数量的活动。就像可以从用户群来判断产品的可靠性一样，活跃的社区是工具未来前景良好的征兆。

目标环境

CI 服务器不能在 所有 环境下工作。需要考虑服务器支持哪个操作系统以及具体的系统需求。例如，如果工具是用最新版本的 Python 编写的，那么需要确定这个版本 Python 能够用于自己的操作系统。

易用性

产品的易用性可能是最主观的指标。有些人愿意手工修改配置文件，而有些人想让所有管理任务都在应用程序中执行，例如 Web 控制台。有些服务器要求从一个屏幕单击到下一个屏幕来执行简单的管理，而其他服务器则提供了直观的向导。

如果想理解 CI 服务器的具体细节，那么漂亮的管理 Web 表单就不重要了；但是，如果人手不足、工作繁忙，那么可能不会想在管理 CI 服务器上花太多时间。

记住我在这节讨论的五个方面，再来看一下三个 CI 服务器：Apache 的 Continuum、CruiseControl 和构建管理服务器 Luntbuild。

回页首

Apache Continuum

Continuum 是最新的 CI 服务器之一，也是值得关注的一个新进入者。Continuum 的安装和配置很简单：只要下载和释放 ZIP 文件，运行命令行程序，就可以运行了。基于 Web 的界面使得配置项目很容易。而且，还不需要安装 Web 服务器，因为 Continuum 内置了 Jetty Web 服务器。并且，Continuum 可以作为 Windows 服务运行，还在应用程序的某些部分嵌入了上下文敏感的文档，从而提供了很多帮助。

想要更多细节信息？ 面对如此之多 CI 服务器可以选择，本文可以引导您更详细地研究每个服务器，并决定哪个最合适。因为我比较了三个不同的服务器，所以我没有深入每个服务器的特定细节。我只是把重点放在了这些服务器安装后就提供的选项上。如果需要更多信息，请参考每个服务器的安装和配置指南。

易于使用

在使用 Continuum 时会注意到的第一件事就是它的易用性。能够在几分钟之内就把服务器运行起来并让它去查询修改。实际上，在 Windows 上启用 Continuum 只需要四步：

1. 下载 Continuum ZIP 文件（请参阅 参考资料）。
2. 把文件的内容释放到本地目录。
3. 运行 run.bat 文件，然后运行 InstallService.bat。
4. 打开浏览器指向 http://localhost:8080/。

Continuum 内置支持五个版本控制系统：Subversion、CVS、StarTeam、Bazaar 和 Perforce。也部分地支持其他版本控制工具，例如 Visual Source Safe 和 ClearCase。 Continuum 还支持四种构建机制：Ant、Maven1、Maven2 和 Shell（命令行）。

配置 Continuum

在第一次访问 Continuum Web 应用程序时，默认是 guest 帐户。guest 提供了对所有项目的只读存取，没有管理或配置项目的能力。但是，可以很容易地创建 Administrative 用户，然后设置一些适用于所有项目的属性。

图 1 显示了管理页面，它提供了管理所有项目的 Continuum 设置的能力，包括创建 Admin 帐户、构建的输出和部署目录：

把项目添加到监视器

对 Continuum 进行配置让它监视项目也非常简单。简单到仅仅是选择期望的构建平台，例如 Ant 或 Maven2，然后把 Continuum 指到期望的版本控制系统。

图 2 显示了设置 Ant 项目时需要填充的字段：

在保存了这个信息之后，Continuum 每小时查询版本控制系统一次。可以修改项目的设置，查询得更频繁或更少些。我们在这里谈到的是 持续 集成，我建议每五 分钟检查修改一次，而不要每小时一次。

默认情况下，在使用 Ant 时，Continuum 在项目的根目录查找项目的 build.xml 文件。如果使用不同的名称或者这个文件不在项目的根目录，可以修改这个设置。

虽然 Continuum 还是 CI 舞台上的新人，但是它以其易用性和对当前众多流行的版本控制系统和构建工具的支持，还是给这一领域带来了巨大的冲击。我希望在未来的版本中会有添加和查看报告的功能。

回页首

CruiseControl

CruiseControl 是 CI 服务器的老者。它已经用了有五年多了，在许多方面， CruiseControl 服务器 已经成为持续集成实践的同义词。出于完全坦白的目的，我应当提到，我也是 CruiseControl 的多年的老用户。

改进的安装

如果您从最后一次使用 CruiseControl 到现在已经有段时间，而且认为它的安装和配置是个负担，那么您可以看看最新版本。现有，有许多方式安装 CruiseControl。例如，如果使用 Windows，会发现最简单的方式是下载二进制可执行文件，然后运行它。不用担心，还可以下载源代码。

安装之后，CruiseControl 预先配置了一个配置文件，轮询 CVS 存储库并执行 Ant 构建脚本。同样也不需要安装 Web 服务器，因为 CruiseControl 也内嵌了 Jetty。

轮询版本控制系统

比起 Luntbuild 和 Continuum，CruiseControl 提供了对超过十种不同版本控制系统的支持。而且，CruiseControl 对这些工具中的许多定制命令也提供了支持。清单 1 是一个使用 CruiseControl config.xml 脚本轮询 Subversion 存储库的示例：

<listeners>
            <currentbuildstatuslistener file="logs/${project.name}/status.txt"/>
            </listeners>
            <modificationset quietperiod="30">
            <svn RepositoryLocation="http://www.qualitylabs.org/svn/ambientorb/trunk"
            username="bfranklin"
            password="G0Fly@Kite"
            />
            </modificationset>
            

执行构建脚本

当在版本控制系统（例如 Subversion）中发现修改时，可以很容易地配置 CruiseControl 去执行委托的构建脚本。例如，清单 2 演示了从 config.xml 调用 Ant 脚本，它指示 CruiseControl 每 60 秒钟查询 Subversion 存储库一次，并执行另一个 Ant 脚本。 委托的构建脚本（没有显示）删除旧文件，从 Subversion 签出最新的源代码，并在代码上运行项目的构建脚本。

<schedule interval="60">
            <ant anthome="apache-ant-1.6.5" buildfile="build-${project.name}.xml"/>
            </schedule>
            

当设置了 CruiseControl 的这个方面并启动服务器之后，可以访问如图 3 所示的 CruiseControl Web 控制板：

CruiseControl 控制板

要接收最新构建的反馈，可以把 htmlemail 插件添加到清单 3 所示的 config.xml 脚本。可以用 config.xml 文件配置更多反馈机制，例如发送文本消息、电子设备（通过 X10）、甚至即时消息。

...
            <plugin name="htmlemail"
            buildresultsurl="http://${env.COMPUTERNAME}/cruisecontrol/buildresults/${project.name}"
            mailhost="${smtp.server}"
            username="${mail.username}"
            password="${mail.password}"
            returnaddress="${buildmaster.email}"
            returnname="${buildmaster.name}"
            subjectprefix="${project.name} build"
            xsldir="webapps/cruisecontrol/xsl"
            css="${reportdir}/cruisecontrol.css"/>
            ...
            <htmlemail>
            <always address="${buildmaster.email}"/>
            <failure address="${buildmaster.email}"/>
            </htmlemail>
            

CruiseControl 提供了许多有用的特性，有强大的用户社区，极具扩展性。与本文中评估的其他工具相比，有些开发人员觉得 CruiseControl 不太容易使用。而另一方面，有些开发人员则发现用 XML 脚本进行修改提供了更好的控制。

回页首

Luntbuild

从面市年头上说，Luntbuild 位于 Continuum 和 CruiseControl 之间。比起 Continuum 和 CruiseControl，Luntbuild 的目标是为并行开发和用户管理之类的事情提供支持的构建管理服务器。它的整个配置是通过 Web 应用程序管理的，所以没有配置文件需要处理。它也有商业版可以使用，叫作 QuickBuild，商业版中包含用户支持。

Jetty 不再必需

Luntbuild 提供了几种安装方式。您可能会发现最简单的方式是通过 GUI 安装。用 Web 应用程序配置和管理 Luntbuild；所以，需要确保正在运行一个能够处理 JSP 的 Web 服务器，像 Tomcat 或 Jetty。

版本控制轮询

Luntbuild 提供了对八种不同版本控制系统的支持，例如 CVS、Subversion、ClearCase 和 Perforce。图 4 演示了 Luntbuild 被设置成轮询 Subversion：

执行构建

Luntbuild 支持五种不同的构建平台，包括 Ant、Maven、Maven2、命令行和 rake （用来构建 Ruby 应用程序）。图 5 显示了 Ant 构建器的配置页面：

构建安排

通过使用 Luntbuild 中的 Schedule 标签（如图 6 所示），可以设置 Luntbuild 多久轮询一次版本控制系统来获得修改。在这个标签上，还可以指定分配给每个构建的唯一构建标号。

在 Luntbuild 中发布结果

配置了项目、版本控制系统适配器、构建和计划程序之后，就可以指定用户接收反馈的方式了。但是，Luntbuild 只内置了对电子邮件和即时消息的支持。另外，可以从 Luntbuild 的主页监视构建，如图 7 所示：

Luntbuild 提供了一整套强大的功能，包括管理项目依赖项和大量的版本控制系统适配器。我认为工作流和用户界面可以简化，因为需要许多步骤来设置和配置工具。

回页首

CI 记分卡

在不理解具体需求的情况下，就推荐哪个工具合适是非常冒失的。每个服务器都有许多优秀的特性，而且就像我在开始时所提到的，仅仅因为某个 CI 服务器最适合某人，并不意味着它必然满足您的需求。

如果寻找的是易于使用的工具，请选择 Continuum。如果扩展性、灵活性和繁荣的用户社区对您很重要，请使用 CruiseControl。如果需要 Web 管理和扩展的用户支持选项，请考虑 Luntbuild。围绕这些服务器已经形成了开发“生态”系统，所以如果遗漏了某个特性，一般都会找到适合需求的扩展。

在表 2 中，是我根据自己的使用经验为所考察的每个 CI 服务器总结的特性、可靠性、寿命、目标环境和易用性这五个核心方面：

我在本文中只评估了三个服务器；还有许多服务器可能更适合您的需求。但是既然您理解了如何挑选 CI 服务器，那么选择工作就应当很容易了。请继续关注下个月的文章，我将介绍在开发项目中经常会遇到的构建问题。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
  
  
• 让开发自动化 （Paul Duvall，developerWorks）：阅读完整系列。
  
  
• “自动进行团队构建和单元测试过程”（Mark Wilkinson，developerWorks，2005 年 10 月）：一本关于为 Java 项目设置基于 Linux 的构建服务器的实际问题的指南。
  
  
• “Realizing Continuous Integration”（Kevin Lee，developerWorks，2005 年 9 月）：学习持续集成的概念和实践。
  
  
• “Continuous Integration”（Martin Fowler，martinfowler.com，2006 年 5 月）：对持续集成的目的和实践的描述。
  
  
• Practical Continuous Integration（Testearly.com）：关于安装和配置 Continuum、CruiseControl 和 Luntbuild 的更详细信息。
  
  
• developerWorks：数百篇关于 Java 编程各个方面的文章。
  
  

• Continuous Integration Server Feature Matrix：目前市场上的 CI 服务器以及它们各自特性的对照表。
  
  
• Continuum：Apache 进入 CI 服务器领域。
  
  
• CruiseControl：免费的开源持续集成服务器。
  
  
• Luntbuild：另一个带有扩展商业支持的持续集成服务器。
  
  

• Improve Your Java Code Quality discussion forum：Andrew Glover 经常在 developerWorks 发表文章，作为专注于改进代码质量的顾问，他将自己的许多专业意见都带到了这个他主持的讨论组中。

关于作者

		Paul Duvall 是 Stelligent Incorporated 的 CTO，该公司利用有效的开发人员测试策略，以及能够让团队尽早尽多地监视和提高代码质量的持续集成技术，帮助其他企业解决软件的质量问题。他还是 UML™ 2 Toolkit 一书的作者之一，目前正在与他人合作撰写 Continuous Integration: Improving Software Quality and Reducing Risk （Addison-Wesley）

图中的每个关键过程域分别针对软件过程的某一方面，具体描述了某级成熟度下软件过程在该方面所应达到的的一组目标和实现这些目标的一组关键活动（Key Practice）。所有关键活动被划分为五类，分别为完成该组目标所需的承诺（Commitment to Perform）、前提条件（Ability to Perform）、实际动作（Activities performed）、度量分析（Measurement and Analysis）以及验证（Verifying Implementation）。上述五方面被称为五个Common Features。

CMM的结构如图所示：

需要提出的是，任何一个成熟度级别的关键过程域集都是本级描述的关键过程域集和所有下级的关键过程域集的并集。如3级的关键过程域就应有13个不同的域，其中7个是3级自己包含的，6个属于2级成熟度，而4级应有15个域。

第一级：初始级（ The Initial Level ）

初始级的软件机构缺乏对软件过程的有效管理，其软件项目的成功来源于个人英雄主义而非机构行为，因此它不是可重复的。

第二级：可重复级（ The Repeatable Level ）

概述：

第二级软件机构的主要特点是：项目计划和跟踪的稳定性，项目过程的可控性和以往成功的可重复性。更具体的说：

• 机构建立了管理软件项目的策略和实现这些策略的过程。
• 新项目的计划和管理基于类似项目的经验。
• 过程能力的增强基于以各个项目为基础的有纪律的基本过程管理。
• 不同的项目可有不同的过程，而对机构的要求是具有指导项目建立适当管理过程的策略。
• 每个项目都确定了基本的软件管理控制，包括：
  • 基于前面项目的经验和新项目特点，做出现实的项目承诺（如预算、交付期、软件质量等）；
  • 软件项目管理者要跟踪开支、日程、软件功能；
  • 满足承诺的过程中的出现的问题要及时发现，妥善解决；
  • 定义了软件项目标准，且机构确保其被遵守。

构成：

本级的关键过程领域（KPA）包括：

• 需求管理（Requirements Management）

客户的需求是软件项目的基础。软件需求管理的目的是在客户和软件项目之间达成对客户需求的一致理解。

• 软件项目计划（Software Project Planning）

为软件工程和项目管理建立一个合理的计划。

• 软件项目的跟踪和监督（Software Project Tacking and Oversight）

使管理者对实际的软件项目进展过程有足够的了解，以在项目效能偏离计划太多是采取有效措施。

• 软件子合同管理（Software Subcontract Management）

选择合格的分包商，并有效管理之。

• 软件质量保证（Software Quality Assurance）

对软件项目过程及其间生产的各个产品进行监管以保证最终软件质量。

• 软件配置管理（Software Configuration Management）

在整个软件生命周期里建立并维护软件项目的工作产品的完整性。

第三级：已定义级（ The Defined Level ）

概述

第三级的主要特征在于软件过程已被提升成标准化过程，从而更加具有稳定性、可重复性和可控性。处于第三级的企业具有如下一些特征：

• 机构采用标准的软件过程，软件工程和管理活动被集成为一个有机的整体。标准化的目的是使之可使管理者和技术人员有效工作。
• 有一组人员专门负责机构的软件过程，并且在机构中有培训计划来确保 stuff 和 manager 有知识和技能完成所赋予的角色。
• 标准的软件过程结合项目的特点即形成定义的软件过程，它包括一组集成的定义良好的软件工程和管理过程。
• 一个定义良好的过程包括就绪准则、输入、完成工作过程、验证机制、输出和完成准则。
• 在已建立的产品线上 cost, schedule, functionality 均可控制，软件质量被加以跟踪。
• 过程能力体现在在机构范围内对一个定义的软件过程活动、角色和责任的共同理解。

构成

第三级主要处理以下的 KPA：

• 机构过程关注（Organization Process Focus）

确立机构对于改进机构的软件过程能力的软件过程活动的责任。

• 机构过程定义（Organization Process Definition）

开发和维护一组有用的软件过程assets和提供一个用于定义定量过程管理的有意义的数据的基础

• 培训计划（Training Program）

开发个体的技能和知识以使他们能够更加有效的完成他们的角色

• 集成软件管理（Integrated Software Management）

基于业务环境和项目的技术需要，从机构的标准软件过程和相关的过程assets经过剪裁，将软件工程和管理活动集成为一个有机的定义的软件过程。

• 软件产品工程（Software Product Engineering）

一致地完成定义良好的工程过程。它描述了项目的技术活动，如需求分析，设计，编码和测试。

• 组间协调（Intergroup Coordination）

确立软件工程组主动介入其它工程组以便项目能更好满足客户要求的手段

• 同行评审（Peer Reviews）

早而且有效的排除软件工作产品中的缺陷。它可通过 inspection,structured walkthrough等手段进行。

概括来说，第三级企业的重点是 Engineering processes and organizational support 。

第四级：已管理级（ The Managed Level ）

概述：

第四级的软件机构中软件过程和软件产品都有定量的目标，并被定量地管理，因而其软件过程能力是可预测的，其生产的软件产品是高质量的。具体地说，第四季的机构具有如下特征：

• 软件过程和产品有定量质量目标。
  • 重要的软件过程活动均配有生产率和质量度量；
  • 数据库被用来收集和分析定义软件过程的数据；
  • 项目的软件过程和质量的评价有定量的基础；
• 项目的产品和过程控制具有可预测性。
  • 缩小过程效能落在可接受的定量界限内的偏差；
  • 可区分过程效能的有效偏差和随机偏差；
  • 面向新领域的风险是可知并被仔细管理；

构成 ：

本级的关键过程领域包括：

• 定量过程管理（Quantitative Process Management）

　　　　 定量地控制软件项目的过程效能。

• 软件质量管理（Software Quality Management）

　　　　　 定量了解项目软件产品的质量，并达到既定的质量目标。

第五级： The Optimizing Level

概述

概括来说，第五级的主要特点是技术和过程改进被作为常规的业务活动加以计划和管理。处于第五级的企业具有如下一些特征：

• 机构集中于连续的过程改进
  • 具有标识弱点和增强过程的手段。
  • 采用过程数据分析使用新技术的代价效益并提出改进。
  • 项目队伍能够分析出错原因并防止其再次出现。
  • 防止浪费是第五级的重点。
• 改进的途径在于已有过程的增量改进和使用新技术和新方法的革新

构成

• 缺陷预防（Defect Prevention）

识别出错原因，防止错误再现 (通过改变定义的软件过程)

• 技术变更管理（Technology Change Management）

识别有益的新技术 (工具、方法和过程)，并按有序的方式将其转移至机构之中。其重点在于在变化的世界中有效的完成革新。

• 过程变更管理（Process Change Management）

连续改进机构所采用的软件过程，以改进软件质量，提高生产率和减少产品开发时间

概括来说，第五级企业的重点是连续的过程改进 。　

纵观整个 CMM，软件企业提高自身成熟度的历程是一个从无序到有序，从特殊到一般，从定性到定量，最后不断自我完善的过程。

计算机软件开发的问题一直是困扰软件企业的关键问题。随着时代的发展人们开始意识到这些企业的基本问题不在于新技术是否使用，而在于软件过程的管理问题。软件过程包括两个方面，其一是软件开发的管理过程（Software Management Process），其二则是软件开发的工程过程（Software Engineering Process）。软件企业的开发机构在形成一套完整而成熟的软件过程后，软件的开发才能够步入正轨，才能保证在约定的期限内以固定的成本生产出客户满意的产品。

软件机构形成一套完整而成熟的软件过程不是一蹴而就的，它需要一个从无序到有序，从特殊到一般，从定性到定量，最后再从静态到动态的历程，或者说软件机构在形成成熟的软件过程之前必须经历一系列的成熟阶段（Maturity Level）。软件机构首先要判断自己属于哪一个成熟阶段，然后再根据自身的实际情况决定应该重点采取哪一些活动（Activity）来更有效地改进自己的软件过程。其他企业在同软件企业订立软件开发合同时也可以根据该企业机构所处的成熟阶段判断其软件开发能力，进而判断相关的软件风险。所有这些都需要一个理论指导来作出相关判断，能力成熟度模型（CMM）就是这样一个理论模型，它规定了机构成熟阶段的框架，以及如何据之判断软件机构所处的成熟阶段和机构为改进自己的软件过程应该采取的办法。

CMM产生背景

主要问题

在过去的二十年里，新的软件开发方法和技术的使用并未使软件生产率和生产质量得到有效的提高。软件生产商开始意识到他们的基本问题在于对软件的生产过程管理不力，主要体现在：软件产品不能按时完成、超出预算的成本、以及采用新的技术和工具后其好处难以体现。

主要作用

CMM可以指导软件机构如何控制软件产品的开发和维护过程，以及如何向成熟的软件工程体系演化，并形成一套良性循环的管理文化。具体说来，一个企业要想改进其生产过程，应该采取如下策略和步骤：

• 确定软件企业当前所处的过程成熟级别；
• 了解对改进软件生产质量和加强生产过程控制起关键作用的因素；
• 将工作重点集中在有限几个关键目标上，有效达到改进机构软件生产过程的效果，进而可持续地改进其软件生产能力。

CMM的基本概念

• 软件过程

人们在开发和维护软件及其相关产品时所涉及的各种活动、方法、实践和改革等。其中软件相关产品包括软件项目计划、设计文档、程序代码、测试用例和用户手册等。

• 软件过程能力

当遵循某个软件过程时所能达到的期望效果，它可以有效预测企业接收新的软件项目时可能得到的结果。

• 软件过程性能

当遵循某个软件过程时所达到的实际效果。它可以用于验证软件过程能力。

• 软件过程成熟度

指一个特定的软件过程被显式定义、管理、度量、控制和能行的程度。成熟度可以用于指示企业加强其软件过程能力的潜力。 当一个企业达到了一定的软件过程成熟级别后，它将通过制定策略、建立标准和确立机构结构使它的软件过程制度化。而制度化又促使企业通过建立基础设施和公司文化来支持相关的方法、实践和过程。从而使之可以持续并维持一个良性循环。

• 成熟与不成熟

企业要通过选择最关键的目标来进行过程改进，应该搞清成熟的软件过程和不成熟的过程之间的差异。

不成熟的企业有如下标志：

• 缺乏确定的软件过程和相应的管理和控制；
• 即使给出了软件过程，也不严格的遵循和强制执行；
• 管理是完全被动的，管理者采用的策略是救火式的，即出了事才去解决，解决的时候也难以纵观全局，往往只顾眼前；
• 由于缺乏有依据的估算，制订软件预算和生产计划时往往跟着感觉走，实际生产时则常常超标；
• 如果强制在预定期限内完成，那么软件的功能和质量肯定是得不到保证；
• 缺乏评价软件产品质量和解决产品缺陷和过程问题的客观基础。

成熟的企业则有如下标志：

• 具有在企业范围内管理、控制软件开发和维护过程的能力；
• 现有人员和新进人员均了解所遵循的软件过程，且工作活动均按照事先的计划完成；
• 在定义好的软件过程中，所有项目和机构中的角色和责任分明；
• 制定的计划是有效的且与实际的工作进展一致；
• 软件过程在必要时可按照一定规则和程序加以修改；
• 软件产品和过程的具有一定的可控性。这主要体现在：
  1. 管理者能够监督软件产品的质量和生产过程；
  2. 具有客观的和定量化的措施来判断产品质量并分析产品与生产过程中的问题；
  3. 计划和预算有章可循，它是基于历史数据的，从而是实际可行的；
  4. 预算的结果，包括成本、时间表、产品功能和质量等，通常能够达到；
  5. 有关的参与者完全理解遵循软件过程的价值并认真地遵循之；
  6. 具有支撑软件过程的基础设施，如标准过程库、历史数据库等。

CMM的五级成熟度

基本前提

• 软件质量在很大程度上取决于产生软件的软件过程的质量和能力；
• 软件过程是一个可管理、可度量并不断改进的过程；
• 软件过程的质量受到用以支撑它的技术和设施的影响；
• 企业在软件过程中所采用的技术层次应适应于软件过程的成熟度。

基本原理

• CMM强调连续的软件过程改进。该连续的改进基于多个演化步骤。CMM将这些演化步骤划分成五个级别。这种分级结构的理论依据是软件质量原理。
• 每一级别都包括若干目标。当满足某一目标后，软件过程的相应部分便确定下来。
• 五级成熟度定义了一个标准，用以度量机构的软件过程成熟度和评价其软件过程能力。

基本内容

CMM的成熟度理论目前主要涉及如下内容：

• 机构和资源的管理: 涉及机构本身的责任，人员和其它资源设施。
• 软件工程过程及其管理: 涉及软件工程过程，即软件过程的深度、范围和完整性以及如何度量、管理和改进这样的过程。
• 工具和技术: 软件工程过程中使用的开发工具和技术。

五个成熟度级别

• 初始级
• 可重复级：有规章的过程
• 定义级：标准化、一致的过程
• 管理级：可预测过程
• 优化级：可持续改进的过程

成熟度的行为刻划

第一级：初始级

• 成功来源于个人英雄主义而非机构行为，因此它不可重复，更换人员后成功便难以维持。

第二级：可重复级

• 针对特定软件项目建立管理该项目的策略和实现这些策略的过程。
• 新项目的计划和管理基于类似项目的经验。
• 软件过程能力主要通过管理单个项目的软件生产过程来得到提高和增强。
• 不同的项目可有不同的软件过程，机构应当建立一定的方针和策略以针对具体的项目选择合适的软件生产过程并进行管理。

可重复级的主要特点在于确定了基本的软件生产管理和控制，具体来讲，有：

• 结合已有项目的经验和新项目的特点来确定本项目的责任和承诺；
• 软件生产成本、时间表和实现的功能被有效跟踪；
• 识别实现承诺所需解决的关键问题；
• 定义软件项目过程标准，机构要确保其被遵守。

概括来说，第二级的主要特点是项目计划和跟踪是确定且有效的，项目的软件过程是可控的，以及已有的成功经验是可重复的。

第三级：定义级

• 有一个机构范围内标准的软件过程，软件工程活动和管理活动被集成为一个有机的整体。标准化的目的是使高层管理者和软件技术人员能够有效合作。
• 有一个组例如软件工程组（SEPG）专门负责订立机构的标准软件过程，并且在机构中制定培训计划来确保相关人员和管理者有足够的知识和技能完成标准过程所赋予的角色。
• 标准的软件过程结合具体项目的特点经过裁剪即形成项目定义软件过程，它是一组集成的完善定义的软件工程和管理过程。
• 一个完善定义的软件过程应包括就绪准则、输入、工作过程、验证机制、输出和完成准则。
• 对于已建立的产品生产线，其成本、时间表和实现功能均可跟踪和控制，软件产品的质量可以得到保证。
• 软件过程能力的实现主要基于在机构范围内对一个定义软件过程的活动、角色和责任的共同理解。

概括来说，第三级的主要特征在于软件过程已被提升成标准化过程，从而更加具有稳定性、重复性和可控性。

第四级：管理级

• 软件的过程和产品有定量的质量指标。
  • 重要的软件过程活动均配有生产率和质量方面的度量指标；
  • 应用数据库来收集和分析定义软件过程中涉及的各种数据；
  • 对项目软件过程和软件质量的评价有定量的基准。
• 软件项目的产品和生产过程的控制具有可预测性。
  • 将软件过程性能可能出现的偏差控制在可接受的量化界限内；
  • 具体区分影响过程性能发生偏差的有效因素和偶然因素；
  • 向新领域拓展的风险是可预知的并被仔细管理和权衡。

概括来说，第四级的主要特征是定量化、可预测、异常控制和高质量。

第五级：优化级

• 机构集中于持续的过程改进
  • 具有标识过程缺陷和增强过程能力的有效手段。
  • 利用试验数据分析使用新技术所需的代价和带来的效益，然后再有选择地采用。
  • 当出现偏差时，软件项目人员能够分析出错原因并采取有效手段防止其再次出现。
  • 防止不必要的浪费是第五级的重点。
• 改进的途径有两个，一个是对已有过程的渐进式改进；另一个则是有选择地使用新技术和新方法所带来的革新。

概括来说，第五级的主要特征是新技术的采用和软件过程的改进被作为日常的业务活动来加以计划和管理。

• 立项管理流程

• 结项管理流程

• 项目规划流程

• 项目监控流程

• 风险管理流程

• 需求管理流程

• 需求开发流程

• 技术预研流程

• 系统设计流程

• 实现与测试流程

• 系统测试流程

• Beta测试流程

• 客户验收流程

• 技术评审流程

• 配置管理流程

• 质量保证流程

• 外包与采购管理流程

• 培训管理流程

• 服务与维护流程