2.1 通用过程模型

过程被定义为在工作产品构建过程中，所需完成的工作活动、动作和任务的集合。这些活动、动作和任务中的每一个都隶属于某一框架或者模型，框架或模型定义了它们同过程之间或者相互之间的关系。

软件过程示意图如图2-1所示，可以看出，每个框架活动由一系列软件工程动作构成，每个软件工程动作由任务集合来定义，这个任务集合明确了将要完成的工作任务、将要产生的工作产品、所需要的质量保证点，以及用于表明过程状态的里程碑。

图2-1 软件过程框架

2.1.1 定义框架活动

软件工程的通用过程框架定义了5种框架活动——沟通、策划、建模、构建和部署。此外，一系列普适性活动——项目跟踪控制、风险管理、质量保证、配置管理、技术评审及其他活动——贯穿软件过程始终。过程流描述了在执行顺序和执行时间上，如何组织框架中的活动、动作和任务，如图2-2所示。

线性过程流从沟通到部署顺序执行五个框架活动（见图2-2a）。迭代过程流在执行下一个活动前重复执行之前的一个或多个活动（见图2-2b）。演化过程流采用循环的方式执行各个活动，每次循环都能产生更为完善的软件版本（见图2-2c）。并行过程流（见图2-2d）将一个或多个活动与其他活动并行执行（例如，软件一个方面的建模可以同软件另一个方面的构建活动并行执行）。

对于由个人负责的小型软件项目（可能远程），其需求简单明确，沟通也许仅仅是与合适的干系人的一个电话。因此，主要的动作是电话交流，这个动作所包括的主要工作任务集如下。

1）通过电话与干系人取得联系。

2）讨论需求并做记录。

3）将笔记整理成一份简单的书面需求。

4）通过E-mail，请干系人审阅并批准。

如果项目有多个干系人，则要复杂得多，每个干系人都有着不同的需求（有时这些需求甚至是相互冲突的），沟通活动可能会包含6个不同的动作：启动、需求获取、需求系统、谈判、规格说明和确认。每个软件工程动作都可能有很多工作任务和一些不同的工作成果。

图2-2 过程流

a）线性过程流 b）迭代过程流 c）演化过程流 d）并行过程流

2.1.2 明确任务集

每一个软件工程动作（或称行动）都由若干个任务集构成，而每一个任务集都由软件工程工作任务、相关工作产品、质量保证点和项目里程碑等部分组成，需要选择最满足项目要求并适合开发团队特点的任务集。这就意味着软件工程动作可以根据软件项目的特定需要和开发队伍的特点做适当的调整。

任务集定义了为达到一个软件工程动作的目标所需要完成的工作。例如，需求获取（或称需求收集）就是发生在沟通活动中一个重要的软件工程动作。需求获取的目的是理解干系人对将构建的软件的需求。

对于一个小型、相对简单的项目而言，获取需求的任务集可能包括以下几个。

1）制定项目的干系人列表。

2）邀请所有的干系人参加一个非正式会议。

3）征询每一个人对于软件特征和功能的需求。

4）讨论需求，并确定最终的需求列表。

5）划定需求优先级。

6）标出不确定领域。

对于大型、复杂的软件工程项目而言，可能需要以下几个不同的任务集。

1）制定项目的干系人列表。

2）和干系人的每一个成员分别单独讨论，获取所有的要求。

3）基于任务集2）中的调查，建立初步的功能和特征列表。

4）安排一系列促进需求获取的会议。

5）组织会议。

6）在每次会议上建立非正式的用户场景。

7）根据干系人的反馈，进一步细化用户场景。

8）建立一个修正的需求列表。

9）使用质量功能部署技术，划分需求优先级。

10）将需求打包，以便软件可以增量交付。

11）标注系统的约束和限制。

12）讨论系统验证方法。

上面两种任务集都可以完成需求获取，但是无论是从深度还是形式化^[1]的程度来说，二者都有很大区别。软件团队应采取适当的任务集，以达到每个动作的目的，并且保持软件质量和开发的灵活性。

2.1.3 过程模式

每个软件团队在软件过程中都会遇到很多问题。针对这些问题，如果软件团队能够得到已有的经过验证的解决方案，将有助于他们快速地分析和解决问题。过程模式（Process Pattern）描述了软件工程工作中遇到的与过程相关的问题、明确问题环境，并给出了针对该问题的一种或几种可证明的解决方案。通俗地讲，过程模式提供了一个模板——一种在软件过程的背景下，统一描述问题解决方案的方法。通过模式组合，软件团队可以解决问题并定义最符合项目需求的开发过程。

可以在不同抽象层次上定义模式。在某些情况下，模式可以描述一个与完整过程模型（例如原型开发）相关的问题（及其解决方案）。在其他的情况下，模式可以描述一个与框架活动（譬如策划）或者框架活动中的一项具体任务（譬如项目估算）相关的问题（及其解决方案）。

例如，过程模式的描述模板可以是下列形式。

1）模式名称。模式名称应能清楚地表述该模式在软件过程中的含义（如技术评审）。

2）驱动力。模式使用环境及主要问题，以明确主要难点及可能的解决方案。

3）类型。定义模式类型。例如，3种类型分别如下。

①步骤模式，定义了与过程的框架活动相关的问题。由于框架活动包括很多动作和工作任务，步骤模式包括与步骤（框架活动）有关的许多任务模式。例如，建立沟通可能作为一个步骤模式。该步骤模式可能包括需求获取等任务模式。

②任务模式，定义了与软件工程动作或工作任务相关、关系软件工程实践成败的问题（例如，需求获取是一个任务模式）。

③阶段模式，定义了在过程中发生的框架活动序列，即使这些活动流本质上是迭代的。例如，螺旋模型和原型开发就是两种阶段模式。

4）启动条件。它描述的是模式应用的前提条件。在应用模式之前需要明确以下几点。

①在此之前，整个开发组织或是开发团队内已经有哪些活动？

②过程的进入状态是什么？

③已经有哪些软件工程信息或项目信息？

例如，策划模式（阶段模式）需要的前提条件有：

①客户和软件工程师已经建立了合作的交流机制。

②已经成功完成一些客户沟通模式中特定的任务模式。

③项目范围、基本业务需求和项目限制条件已经确定。

5）问题。描述模式将要解决的具体问题。

6）解决办法。描述如何成功实现模式。这部分主要讨论随着模式的启动，过程的初始状态（模式应用之前就已经存在）是如何发生改变的。解决方法也描述了随着模式的成功执行，模式启动之前所获得的软件工程信息和项目信息是如何变换的。

7）结束条件。描述模式成功执行之后的结果。模式结束时需要明确：

①必须完成哪些开发组织或是开发团队相关的活动？

②过程的结束状态是什么？

③产生了哪些软件工程信息或项目信息？

8）相关模式。以层次或其他图的方式列举与该模式直接相关的其他过程模式。例如步骤模式沟通包括了一组任务模式：项目团队组织、合作指导原则定义、范围分解、需求获取、约束描述及场景模式的创建等。

9）已知应用实例。说明该模式可应用的具体实例。例如，沟通在每一个软件项目的开始都是必需的，建议在整个软件项目过程中采用，并规定在部署活动中必须进行。

过程模式提供了一种有效的机制，用以解决任何与软件过程相关的问题。模式使得软件工程组织能够从高层抽象开始（阶段模式），建立层次化的过程描述。高层抽象描述进一步细化为一系列步骤模式以描述框架活动，然后每一个步骤模式又进一步逐层细化为更详细的任务模式。过程模式一旦建立起来，就可以复用来定义各种过程变体——即软件开发队伍可以将模式作为过程模型的构建模块，定制特定的过程模型。

2.1.4 过程评估与改进

软件过程并不能保证软件按期交付，也不能保证软件满足客户要求或软件具备了长期质量保证的技术特点。软件过程模型必须与切实的软件工程实践相结合。另外，对过程本身也要进行评估，以确保满足了成功软件工程所必需的基本过程标准要求。

在过去的几十年中，提出了多种软件过程评估和改进方法，列举如下。

（1）用于组织内部过程改进的CMM评估，采用CMM作为评估的依据，提供了一种诊断方法，用以分析软件开发机构的相对成熟度。

CMM（Capability Maturity Modelfor Software）是指“能力成熟度模型”，它是对软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化，使企业能够更好地实现商业目标。

（2）用于过程改进的CMMI标准评估方法提供了5步的过程评估模型：启动、诊断、建立、执行和学习。该方法采用CMMI作为评估的依据，CMMI详细介绍了软件过程的基本特征及过程成功的标准。

CMMI（Capability Maturity Model Integration）是指“软件能力成熟度模型集成”（也称为软件能力成熟度集成模型），是美国国防部的一个设想，1994年由美国国防部与卡内基-梅隆大学的软件工程研究中心（SEISM）及美国国防工业协会共同开发和研制。他们计划把现在所有现存实施的与即将开发出来的各种能力成熟度模型集成到一个框架中去。申请此认证的前提条件是该企业具有有效的软件企业认定证书。其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。其所依据的想法是：只要集中精力持续努力地去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件开发中的困难。CMMI为改进一个组织的各种过程提供了一个单一的集成化框架，新的集成模型框架消除了各个模型的不一致性，减少了模型间的重复，增加了透明度和理解，建立了一个自动的、可扩展的框架。因而能够从总体上改进组织的质量和效率。CMMI的主要关注点就是成本效益、明确重点、过程集中和灵活性4个方面。

CMMI是一套融合多学科的、可扩充的产品集合，其研制的初步动机是为了利用两个或多个单一学科的模型实现一个组织的集成化过程改进。CMMI的本质是软件管理工程的一个部分。软件过程改善是当前软件管理工程的核心问题，50多年来，计算机的发展使人们认识到要想高效率、高质量和低成本地开发软件，必须改善软件生产过程。基于模型的过程改进是指采用能力模型来指导组织的过程改进，使其过程能力稳定地进行改善，该组织也能变得更加成熟。

CMMI的成功促使其他学科也相继开发出类似的过程改进模型，如系统工程、需求工程、人力资源、集成产品开发和软件采购等，从CMMI衍生出一些改善模型。不过，同一个组织中存在多个过程改进模型可能会引起冲突和混淆，CMMI就在这些模式之间进行协调。

●SPICE标准定义了软件过程评估的一系列要求。该标准的目的是帮助软件开发组织建立客观的评价体系，以评估定义的软件过程的有效性。

●软件ISO 9001：2000，这是一个通用标准，任何开发组织如果希望提高所提供的产品、系统或服务的整体质量，都可以采用这个标准。因此，该标准可直接应用于软件组织和公司。