1.4.2 基本过程

为了有效地开展测度活动，需要在组织层面建立测度过程，并将它和其他过程一道集成到整个软件开发生命周期。测度过程的目的是针对开发的产品或者采用的软件过程，收集、分析和报告相关的数据，从而更加有效和客观地验证软件产品的质量。测度过程成功实施之后，可以实现下面的目标：

● 为测度确立和维持软件项目或者组织层面的承诺。

● 识别技术过程和管理过程的信息需求。

● 根据识别的信息需求，识别和开发合适的度量。

● 识别测度相关的活动。

● 计划测度相关的活动。

● 收集、储存和分析测度相关的数据，并对测度结果提供解释。

● 利用信息产品支持项目利益相关者做出决定，并提供客观的基础进行有效的沟通。

● 评估测度过程和度量指标。

● 测度过程的改进。

图1-12是来自ISO/IEC 15939：2007测度过程标准中的测度过程模型。从图中可以看出，整个测度过程由四个活动组成，它们分别是：

● 确立和维持测度承诺（Establish & Sustain Measurement Commiment）。

● 计划测度过程（Plan the Measurement Process）。

● 实施测度过程（Perform the Measurement Process）。

● 评估测度（Evaluate Measurement）。

测度过程的四个活动按照迭代方式排列，可以在测度过程中不断得到反馈，从而实现测度过程的持续改进。从图1-12可以看出，测度过程采用的是质量改进过程中常用的PDCA（Plan-Do-Check-Act）过程。对于每个测度过程的活动，其中的任务也是不断迭代的。

“计划测度过程”和“实施测度过程”是整个测度过程的核心活动，这两个活动通常是测度使用者所关心的，例如：测试经理。而其他两个活动：“确立和维持测度承诺”和“评估测度过程”为两个核心活动提供基础，并为它们提供及时的反馈。

图1-12中的“技术和管理过程”并不属于测度过程的范畴，但是它是测度过程重要的外部接口。核心测度过程是由组织或者项目的信息需求来驱动的。针对每个“技术和管理过程”中的信息需求，通过核心测度过程的活动，生成合适的信息产品满足其信息需求。而核心测度过程生成的信息产品是“技术和管理过程”用来做出决定的基础。因此，“技术和管理过程”的信息需求是整个测度过程的重要输入。而测度过程中得到的度量结果和信息产品可以更好地帮助“技术和管理过程”进行产品质量管理或者过程管理。

1.4.2.1 确立和维持测度承诺

来自于“技术和管理过程”的测度需求触发了整个测度过程。作为测度过程的第一步，“确立和维持测度承诺”将明确测度需求，并为整个测度活动分配相应的资源。“确立和维持测度承诺”将会从组织层面或者项目层面统一对测度需求的认识，明确测度的目的，同时也能够在具体行动开始之前对相应的资源进行分配，保证测度活动能够顺利进行。“确立和维持测度承诺”活动的主要任务包括接受测度需求和分配资源。

（1）接受测度需求

“技术和管理过程”的测度需求是进行整个测度过程的基础。获取了测度需求之后，首先需要定义测度的范围。测度范围可以是项目层面的，也可以是组织层面的。所有测度相关的任务都必须在定义的范围内进行。在测度范围定义过程中，需要明确测度的利益相关者，例如：针对某个测试项目，和测试相关的测度利益相关者包括测试经理、测试人员、开发人员、项目经理、产品经理、质量经理和客户等。测度利益相关者可以是属于组织内部的人员，也可以是外部人员。测度利益相关者的另一个重要任务是识别和明确测度的目的。

在确立测度需求的时候，需要确立测度相关的管理和人员方面的承诺，包括为整个测度活动取得资源上的承诺，例如：以组织层面的测度方针的形式定义，还包括对测度相关角色和职责的定义、对培训资源的承诺，以及对测度活动经费的承诺。测度相关的承诺应该通过正式的方式在整个组织内予以公布，例如：通过组织层面的公告方式。

（2）分配资源

为测度过程分配资源，首先涉及的是人力资源的分配，例如：针对测试活动的测度相关角色，应该包括信息产品的使用者、度量数据的设计和分析人员，以及度量数据收集人员等。在分配资源的时候需要考虑不同角色的能力要求，如果需要的话，可以对相关人员进行培训。在测度活动比较少的情况下，设计和分析人员以及度量数据收集人员可以是同一个人。在很多组织中参与测度过程的人员是兼职的，所以对人力资源的承诺显得尤为重要。在对相关人员分配任务的时候，必须和项目经理、测试经理进行全面沟通，保证他们的投入。

1.4.2.2 计划测度过程

计划测度过程将统筹安排整个测度活动，指导后面测度的实施和评估。该活动将会用到测度经验库中的内容，经验库中的信息产品和评估结果对当前的测度计划都有很重要的指导意义。计划测度过程的主要任务包括描述测度组织特征、识别信息需求、选择度量、定义度量数据的收集、分析和报告规程、定义信息产品和测度过程评估准则、评审/批准/提供测度任务的资源以及获取和部署支持技术。

（1）描述测度组织特征

应该明确地描述与测度选择和信息产品解释相关的组织特征。测度的内容是由组织来提供的，因此，将测度内容和它受到的限制进行文档化就显得非常重要。

（2）识别信息需求

信息需求来源于“技术和管理过程”。信息需求可以是基于团队目标、约束条件、风险和组织面临的问题等提炼而成的。信息需求也可以来源于商业需要、组织需要、政策法规、产品或者项目的目标等，例如：如何对下一个项目测试团队的生产率进行估算、当前被测试产品的质量如何、当前测试用例执行的进度如何等。从风险的角度来提炼信息需求是一个很好的方向（关于风险方面的知识，参见3.9节）。

识别和收集信息需求之后，需要对它们进行优先级划分。信息需求的优先级划分需要由利益相关者共同完成。识别的信息需求可能很多，但是最后只有部分信息需求会进行更进一步的分析和整理。特别是第一次进行测度工作的时候，一般都会从一个信息需求的子集开始，因为进行测度活动是有成本的，随着信息需求的增加，进行测度活动的成本也会不断上升。在实际的测度过程中，需要根据具体情况。判断投入和产出的效率以及项目的测度预算，对一些低优先级的信息需求进行裁减。

将识别并划分优先级之后的信息需求进行文档化，并在组织内进行有效的沟通。文档化可以是书面形式，也可以是电子文档形式。选择的信息需求需要和所有的利益相关者进行沟通，确保大家对信息需求的内容理解一致，例如：为什么需要收集特定的数据，它们是如何被使用的等。

（3）选择度量

确定信息需求之后，需要识别满足特定信息需求的潜在度量。这些候选的度量信息越详细越好，以方便在后续的过程中选择合适的度量。设计新的度量的时候，可能也会使用已经存在的一些度量。

最终的度量将会从候选的度量中选择出来。选择出来的度量应该可以反映前面得到的信息需求的优先级。在需要的时候，帮助解释度量的信息也应该考虑进去，例如：在比较不同软件产品的需求时，应该描述不同系统的特性，如安全关键系统、综合系统等。

最终确定的度量应该通过文档的方式进行记录。文档中应该包括度量的名称、度量的单位、正式的定义、数据收集的方法（例如：数据收集表格、问卷调查等）以及它和信息需求之间的联系。

（4）定义度量数据的收集、分析和报告规程

确定了度量之后，就需要定义度量相关数据的收集过程，其中包括数据的存储和验证的规程。这里需要定义度量数据是如何被收集的，以及它们是如何被保存的。

收集度量相关数据之后，需要对数据进行分析和报告，因此，需要定义数据分析和信息产品的报告规程。这个规程需要指明数据分析的方法以及对信息产品进行报告的格式等。

测度过程中收集的数据、分析结果、信息产品和选择的信息需求等，都应该处于配置管理的控制之下。测度过程中的配置管理活动可以作为整个软件开发生命周期配置管理的一部分。

（5）定义信息产品和测度过程评估准则

有了度量和信息产品之后，需要定义评估信息产品的准则。这个评估准则能够用来判断收集和分析的数据是否达到定义的质量要求，从而满足信息需求。这个评估准则必须在项目或测度活动开始的时候就进行定义，作为测度活动的成功准则。测度活动成功准则的定义应该结合组织内技术和商业目标。具体的评估准则可以是：最终信息产品的利用率、信息产品的可靠性、信息产品的可理解性和测度方法的可重复性等。

定义了信息产品的评估准则之后，还需要定义评估测度过程的标准。测度过程的评估，顾名思义，评估的是测度的过程，例如：测度过程能够提供的信息产品的及时性、测度过程的效率（执行测度的成本不能超过提供的测度信息的价值）、测度用户的满意度等。

（6）评审、批准和提供测度任务的资源

测度计划需要被评审，并被批准。测度计划中的任务应该包括前面涉及的所有任务。测度计划应该包括数据收集规程定义、数据储存、分析和报告的规程定义、评估准则、时间进度和职责等。测度计划还应该考虑测度过程的改进。

测度计划在发布之前需要由利益相关者进行评审。测度的发起人（例如：组织内的过程组成员）在测度计划评审和更新之后批准该文档。批准了该文档就意味着对测度活动的承诺。

批准测度计划之后，为计划的测度任务分配资源。测度计划中的信息需要得到管理层的同意，并为测度活动分配资源。

（7）获取和部署支持技术

评估并选择合适的支持技术，例如：需要评估和选择自动化工具、测度相关的培训课程等。自动化工具的类型包括图形化显示工具、数据分析工具，也可能需要收集度量数据的工具。根据选择的支持技术和工具，测度计划可能需要进行相应的更新。

选择和获取了相关的支持技术之后，就是支持技术的应用，需要将选择的技术应用在测度过程中。

1.4.2.3 实施测度过程

实施测度过程主要是对前面测度计划中的任务进行实施，形成最终的信息产品。在实施测度过程的时候，需要考虑和应用“测度经验库”中的信息产品和评估结果。实施测度过程主要包括下面四个任务。

（1）集成规程

集成规程将度量数据收集集成到相关的软件开发过程中。由于测度过程的集成可能需要对当前的过程进行部分修改，以满足测度活动的要求，例如：审查过程可能需要更改，要求在审查活动结束之后，审查的主持人提供审查相关的工作量统计和缺陷记录，以输入测度经验数据库，这就需要审查过程进行相应的更改。集成规程需要考虑集成对现在过程的影响和可以忍受的程度，以及测度过程的需求，并在这两者之间进行平衡。集成的影响程度依赖于测度的类型和信息需求，例如：对员工进行一次满意度调查，对已有的过程影响就很小。

将集成后的数据收集过程和相关的数据提供者进行沟通，这样才能够保证数据提供者能够及时准确地提供需要收集的数据。沟通可以通过员工培训等方式完成。数据分析和报告通常都是周期性的活动，需要定期执行，因此，需要将数据分析和报告活动集成到当前组织和项目的过程中。

（2）收集数据

通过指定的测度方法对选定的实体属性进行测量之后，需要根据项目实际情况，通过自动化工具或者手动的方式进行相关数据的收集，例如：利用需求管理工具收集每次需求发生变更的相关的数据；通过缺陷数据表格的方式，将这些信息发给测度相关的人员。

数据收集之后，需要对收集的数据进行存储，包括对测度相关信息的验证、理解和评估。通常原始的度量数据的来源是分散的，有的可能来自配置管理系统、有的在缺陷管理系统中、有的在测试执行控制系统中，根据测度的需要，在条件允许的情况下，最好是将收集到的数据进行集中管理。

数据储存之后需要对度量数据进行验证。存在多种情况，可能造成收集到的度量数据是不正确的，例如：可能是测度收集人员的计算错误，可能是度量数据提供者对要提供的数据没有理解，也可能是自动化的工具产生的错误。所以对于收集到的度量数据必须进行验证，根据度量数据的规模，可以选择全部验证或者抽查的形式进行。利用检查表来检查度量数据是一种有效的数据验证手段。

（3）分析数据并获得信息产品

度量数据经过验证之后，需要对这些数据进行分析，例如：对数据进行整合和必要的格式化。度量数据分析的严格程度依赖于收集数据本身的属性和信息需求方面的要求。

测度分析人员首先根据整理的数据得到初步的结论，然后根据测度计划中的信息需求获得最终的信息产品。信息产品评审可以用来保证用户对信息产品的满意度。这个评审也可以是一种非正式的“自我检查”，或者是正式的审查。

（4）沟通结果

最终的信息产品应该被文档化。记录的信息产品可以作为其他活动的输入，也可以对测度活动进行评估，同时还可以用来更新测度经验库。

信息产品应该和测度用户进行沟通。需要将最终的信息产品和数据提供者以及其他相关人员进行沟通，他们的反馈可以作为评估信息产品和测度过程的输入。

1.4.2.4 评估测度

评估测度活动包括两个方面的任务：评估信息产品和测度过程、识别改进点。

（1）评估信息产品和测度过程

根据具体的评估准则对信息产品进行评估，了解整个信息产品的优缺点。评估的输入是测度过程的各个活动信息、最终的信息产品以及测度用户的反馈意见。具体的测度评估准则来源于测度计划中制定的准则。根据具体的评估准则对测度过程进行评估。测度过程的评估可以采用内部审计，也可以采用独立的外部审计的方法。

评估过程发现的经验教训应该记录在测度经验库中，具体可能包括：各种信息产品的优缺点、测度过程本身的优缺点、测度计划中的一些经验教训等。

（2）识别改进点

识别改进点可以分别从信息产品和测度过程入手，分别得到信息产品的改进点（例如：信息产品对应的度量指标的调整、产品规模的计算从代码规模换成功能点规模、缺陷类型的重新定义等）和测度过程改进点（例如：将测度过程集成到项目过程中是否可以改进、各个测度角色的培训的质量改进等）。

得到信息产品改进点和测度过程改进点之后，需要针对这些改进点进行沟通（例如：确定的改进点要和相关的测度分析员、质量人员或过程改进组进行沟通）。改进点沟通之后，需要制定相应的改进计划，使得后续进行的测度活动能够更加完善。