质量管理体系（QMS）的主要目的是实施一个组织所选择的质量战略。QMS通过关注那些对成功实现质量目标和目的、提供高质量的产品和服务以及满足利益相关者的要求至关重要的领域来实现这一目的。QMS是组织与质量相关的组织结构、政策、流程、工作指南、计划、支持工具和基础设施的总和。QMS提供了计划、实施、维护和持续改进与质量管理、质量规划、质量工程、质量保证、质量控制以及验证和确认有关的活动和行动所需的标准、指导和技术。

质量目标和目的

设计与业务目标一致的软件质量目标和目的。将软件质量目标和目的纳入高水平的计划和项目计划。开发和使用必要的文件和流程来支持软件质量管理系统。

质量目标和目的

建立质量管理体系的首要目标是将与质量有关的活动制度化，纳入组织的各个方面及其关键的业务实践。这要从最高管理层开始，建立质量目标或指标，并将其纳入组织的战略计划。这些质量目标应与组织的业务目标和目的、组织的使命以及利益相关者的需求相一致。
以下组织质量目标的例子是根据ISO 9000质量管理原则（ISO 2015a）制定的。

• 通过持续关注顾客价值，满足顾客要求并努力超越顾客期望
• 建立统一的目标和方向，并创造条件让人们参与实现组织的质量目标
• 确保整个组织的各级人员都有能力、有能力、有参与感。
• 建立和维护一个由相互关联的过程组成的连贯系统，并加以理解、实施和管理，以便有效和高效地- 实现一致和可预测的结果。
• 保持对改进的持续关注
• 通过对数据和信息的分析和评估，做出明智的、基于事实的决策
• 积极管理与关键、相关利益相关者的关系

然后规划质量目标以实现这些质量目标。这些目标应该是SMART（具体的、可衡量的、可实现的、现实的和有时限的）。作为组织级质量计划的一部分，组织 "质量目标的定义是为了明确在特定的时间段内采取哪些具体行动，以实现可衡量的质量结果"（Westcott 2006）。组织软件质量目标的例子包括。

• 组织将被正式评估，并在2017年第二季度末达到开发能力成熟度模型集成（CMMI）1.3版的3级成熟度。
• 软件开发人员将接受交叉培训，以便在2018年第二季度末，90%的正在开发或维护的软件源代码模块至少由两名开发人员支持。
• 到2017年第四季度末，每个项目用于返工活动的开发资金比例将减少到15%或更少。
• 到2017年第三季度末，每个产品的回归测试套件中，自动化测试案例的比例将提高到50%或以上
• 到2018年底，利益相关者的满意度将提高到90%或更高，以客户满意度调查的前两个方框中的得分来衡量
• 对于同一产品的每个连续的新功能版本，发布后报告的缺陷数量将减少20%或更多，直到产品的总缺陷控制有效性措施达到至少95%。

这些组织层面的质量目标应该向下传播到较低层次的部门、团队和个人目标，以及支持它们的计划、项目、产品和过程目标。质量目标的具体责任需要在组织的各个层面上进行分配。这些目标需要被沟通，以便每个员工都知道他们的责任，以及他们的工作如何影响实现目标的进度。

质量规划

在组织层面，质量规划需要被纳入组织的年度运营计划。这些计划应包括确定的质量目标和下一财政年度的目标。如图6.1所示，组织的质量规划也应与组织的业务目标保持一致，并加以实施。
在项目层面，质量计划应包括项目打算如何实施组织的QMS的具体内容。项目质量计划必须包括项目打算如何实施组织层面的规划的战略和策略，包括质量目标和目的，并向下传播到该项目。项目质量计划可以是由项目计划引用的独立文件，也可以作为项目计划中的章节。项目质量计划也必须与其他项目计划保持一致。

质量管理系统（QMS）文件

QMS文件的层次结构定义了组织实现其质量目标和目的的战略和策略。图6.2说明了QMS文件层次结构中的不同层次和文件类型。

行业标准

在最高层次上，组织的QMS通常基于一个或多个行业标准或模型的框架。有各种质量管理系统和/或软件行业标准和模型可以使用（例子包括ISO 9001和相关的行业特定解释或ISO 9001的附加条款，IEEE软件标准，或第三章中的CMMI模型之一）。这些行业标准和模型代表了由行业专家定义的 "良好实践"。使用这些标准中的一个或多个，可以让组织利用这些专业知识，避免因 "重新发明车轮 "而浪费时间。然而，这些定义的行业 "良好实践 "可能需要根据组织的具体情况、需求和背景进行选择、采用和调整，以便将它们变成该组织的 "最佳实践"。

质量政策

在组织层面，质量政策是由高级管理层正式制定的，以确定在做出影响质量的决策和执行活动时应遵循的总体方向和原则。上层管理部门通常会制定质量政策，以传达QMS的意图及其目标。所有的CMMI模型都有一个通用做法，即建立和维护组织政策，以规划和执行每个模型中的所有过程。这种通用做法的目的是 "定义组织对过程的期望，并使这些期望对组织中受影响的成员可见"（SEI 2010，SEI 2010a，SEI 2010b）。

标准化的流程

标准化流程定义了在组织层面上实施QMS活动所需的机制。一个过程是一个可定义的、可重复的、可测量的任务序列，用于生产优质产品。ISO 9001要求指出，"组织应建立、实施、维护并持续改进质量管理体系，包括所需的过程及其相互作用。" (ISO 2015)所有的CMMI模型还包括一个用于组织过程定义的过程区域。这个过程领域的目的是 "建立和维护一套可用的组织过程资产和工作环境标准，以及团队的规则和指南"（SEI 2010）。

通过标准化和记录软件过程的定义，一个组织可以描述和交流通常最有效的方法。这可以通过以下方式帮助组织。

• 确保流程中的重要步骤不被遗忘和/或遗漏
• 促进经验教训在组织学习中的传播，使组织能够在一个又一个项目中重复其成功，并停止重复导致问题的行动。
• 缩短新员工或转岗员工的学习曲线
• 为每个新项目提供一个良好的基础，同时也允许灵活地根据项目的具体需要来调整流程。

定义和记录的标准化流程提供了结构化的基础，以创建了解流程能力和分析流程结果所需的指标。它们对于一致的培训、管理审查和工具支持是必要的。它们为组织学习和持续的过程改进提供了基础。

有许多不同的方法来绘制流程图。记录过程定义的一个简单方法是使用ETVX（进入标准、任务、验证步骤、eXit标准）方法。

• 进入标准。在进程开始前必须满足的具体的、可衡量的条件。
• 任务。必须执行的单个步骤或活动，以实施流程并创建结果产品。任务的定义还应该包括每个步骤的责任分配（角色）。
• 验证。描述用于验证任务是否按要求执行以及可交付产品是否符合要求的质量水平的机制的步骤。典型的验证步骤包括审查、测试或签收。
• 退出标准。在流程完成前必须满足的具体的、可衡量的条件。

进入和/或退出标准的例子包括。

• 必须令人满意地完成的其他过程或活动
• 必须到位或必须更新的计划或文件
• 必须令人满意地完成的审查、测试或其他评估，或必须获得的批准
• 必须获得的具体测量值
• 必须有具备适当专业水平的工作人员来执行这一过程
• 在该过程中必须具备和/或准备使用的其他资源

ETVX图的一个扩展是EITVOX（Entry criteria, Inputs, Tasks, Verification steps, Outputs, eXit criteria）图，在传统的ETVX图上增加了输入和输出的定义。发展中的CMMI也对ETVX方法进行了扩展，并指出 "一个确定的流程清楚地说明了目的、输入、进入标准、活动、角色、措施、验证步骤、产出和退出标准"（SEI 2010）。
流程的目的是对流程的增值原因的陈述。目的定义了组织通过执行该流程中的步骤试图完成什么。例如，软件系统测试执行流程的目的可能是根据批准的需求验证软件系统，根据其预期用途进行验证，并在产品发布前识别产品缺陷。
输入是指输入到流程中并在流程中使用的有形的、物理的人工制品。这些输入可能是作为其他过程的一部分而创建的工作产品，也可能是由组织外部来源（例如，由客户或分包商）购买或提供的项目。软件系统测试执行过程的输入例子可能包括系统测试用例和程序（来自软件系统测试设计过程），软件构建（从软件集成测试执行过程中推广），以及用户手册（来自用户手册文档过程）。输入和输入标准之间的区别有时会显得很混乱。例如，测试用例是流程的输入，还是测试用例已被审查、批准并置于配置管理之下这一事实是流程的进入标准之一？为了消除这种混淆，一些流程定义将输入和进入标准合并为一个部分。

流程图可以通过显示各种任务、验证步骤和可交付成果之间的关系，以及说明谁（什么角色）负责每个任务或验证步骤，使该流程更容易理解。创建流程图的第一步是定义该流程的各种角色。角色是负责流程中各个步骤的个人或团体。他们的角色被列在流程图左侧的 "泳道 "上，如图6.3所示。
为了使标准化流程尽可能地适应多个项目，这些角色应该用通用术语来标注（例如，项目经理、开发人员、测试员、测试经理、SQE、SCM图书管理员），而不是使用具体的组织名称或个人或团体的实际名称。这是良好流程定义的一个保持概念，这样做的好处包括。

• 使组织不至于在每次重组、有人获得晋升或头衔改变、或有人员流动时都被迫更新流程定义。
• 允许不同规模的单个项目使用流程，而不需要通过指定个人或团队担任这些通用角色来进行调整。例如，在非常大的项目中，整个团队可能被分配到一个流程角色中，而在非常小的项目中，一个人可能被分配到几个角色。另一个例子是使用一个通用的角色，如批准权。
• 授权，它可以被分配给配置控制委员会（CCB）、审查小组或个人，取决于被批准的工作产品。
• 通过避免不增值的返工和不必要的裁剪来节省时间和金钱。
• 使配置管理更容易。
• 使得重复使用成为可能。

然后可以在泳道上画一个流程图。下面流程图说明了软件系统测试执行过程中的各种任务、验证步骤、决定和交付物。这个例子过程从步骤T1开始。分配测试用例，并遵循流程，在步骤T7结束：推广工作产品。这种方法使被分配到一个角色的人很容易读懂他们的 "泳道 "并确定他们的责任。如果一个步骤有多个角色负责，该步骤的方框就会跨越多个泳道（例如验证步骤V1及其相关的内部决策是测试人员、测试管理和项目经理的责任，验证步骤V3是测试经理和项目经理的责任）。过程任务或验证步骤也可以调用较低级别的过程（例如，任务T2：执行测试案例过程和验证步骤V2。同行评审过程是对下级过程的调用，如方框左右两边的双杠所表示）。) 在这个例子中，正常的过程流用实线箭头表示，只有在特定条件下发生的过程流则用虚线箭头表示。作为选择，流程图也可以显示流程的交付物（例如交付物D2：系统测试报告）。

这个例子使用流程图和流程图来说明流程，只是用图形表示流程的一种方式。在定义一个流程时，有许多不同的模型和技术可以使用。

对于流程图中定义的每个任务或验证步骤，应在流程定义中包括一个文本描述，详细描述该任务或验证步骤。这些描述可包括
指向描述如何完成该任务或验证步骤的详细工作说明。

• 对具体责任的额外描述。例如，"测试经理负责与审查参与者进行定期的测试状态审查，包括测试人员、测试负责人、工作产品拥有者和配置管理。"
• 负责任务或验证步骤的人必须具备的必要的专业知识水平（或指向必要的专业知识水平的描述）。例如，"测试人员必须熟练掌握XYZ测试工具集和ABC模拟器的使用。"
• 指向标准（例如，正式的检查过程标准，或工作产品的工艺标准）。
• 指向标准化模板（例如，文件、报告或会议议程模板），用于创建任务或验证步骤的输出。
• 在任务或核查步骤中应使用的其他资源（例如，工具或硬件）。
• 扩展的过程定义还可能包括对收集和/或使用的具体指标的描述（或指向描述），作为过程的一部分，或衡量其产品质量。

过程的输出包括可交付成果和质量记录。交付物是有形的、物理的物体，或具体的、可测量的成就，是任务或验证步骤的结果。质量记录，也称为文件化信息（ISO 2015），是提供证据的产出，证明发生了适当的活动，以及这些活动的执行符合规定的标准。质量记录的例子包括。

• 会议记录（例如，评审、配置控制委员会、审计）。
• 报告（例如，技术审查报告、管理审查报告、测试报告、审计报告、状态报告、度量报告
• 变更请求、行动项目清单、纠正行动，等等。
• 已完成的检查表
• 日志（例如，测试日志、工程笔记本、问题日志、风险日志）。
• 正式的签收和批准页
• 已完成的表格（例如，采购订单、审批表）。

与输入和进入标准一样，输出和退出标准之间的区别有时会显得很混乱。为了消除这种混淆，一些流程定义将产出和退出标准合并为一个部分。

流程架构

在定义和记录每个单独的流程之前，应该设计流程架构，以定义各个流程的顺序、它们的相互作用和相互依赖性、流程之间的工作产品流以及它们与外部流程的接口。下图是高层次流程结构流程图的例子。上图中详细定义的系统测试过程只是这个高层次架构中的一个方框。根据组织的需要和该组织流程的复杂性，可能有几个层次的流程架构。例如软件开发迭代框可能有自己的低级架构，定义了低级流程，包括软件需求、软件架构、软件设计、编码、单元测试、集成测试等等。最高级别的流程架构是生命周期模型。

标准化的工作指令

指南是工作指令的一种类型。例如，执行测试案例流程可能有一个 "在问题报告数据库中打开一个问题报告 "的任务。通过留下这个通用的任务，无论项目选择哪种问题报告工具，都可以使用同一个流程文件。为了支持这个过程，可能会有几个指南式的工作指令，每个指令都详细说明了如何在不同的工具中打开问题报告，哪些字段需要填写，以及应该输入每个字段的数据描述。这是一个例子，说明指南可以记录一个流程中的 "变化"，而不需要创建多个新的流程来处理这些变化。

模板和表格是另一种类型的工作指南。例如，计划项目流程通常有一个记录项目计划的任务。为了支持这个流程，可能有几个模板类型的工作指令，为几种不同的项目类型（大型项目、小型项目、维护项目、敏捷项目）中的每一种提供文档指导。这是一个例子，说明模板可以记录流程中的 "变化"，而不需要创建多个新流程来处理这些变化。表格的例子可能包括采购表、问题报告表、报告审计不符合要求或纠正措施的表格。

模板和表格使软件从业人员能够集中精力于内容而不是格式。模板和表格就像一个纲要，说明在每个部分或子部分或字段中应该记录什么，从而防止遗漏所需的信息。模板和表格可以是硬拷贝的，也可以是电子的，或者通过使用工具来实现。例如，许多需求管理工具允许输入需求信息，然后可以使用预先建立的或可定制的模板来发布。其他工具允许自动完成表格。使用工具的好处之一是，工具通常包括错误处理，可以提高准确性和一致性。

利用文件模板的层次结构和类似于下图所示的过程层次结构，也可以通过定义每类信息的记录位置来帮助减少整个文件集的内容冗余。例如，每个不同的计划文件（项目计划、软件质量计划、验证和确认计划等）都应该有自己的风险管理部分，定义与每个计划相关的具体风险，还是应该使用一个单独的综合风险管理计划？有了单独的风险部分，每一类计划的模板将包括一个风险管理部分。如果使用一个单独的风险管理计划，它将有自己的模板。

检查表是第三种类型的工作指示。核对表是用来验证一个过程、产品或服务的所有重要项目都被考虑的工具。核对表的不同用途的例子包括。

• 包括活动中所有步骤的检查表，这样就不会遗漏任何步骤，也不会乱来。
• 包括执行活动时应考虑的所有因素和属性的清单（例如，要执行的不同类型的测试的清单，包括性能、安全性、安全性、可用性、负载/容量/压力、资源使用等等
• 进行同行评审或测试时应检查的常见缺陷的检查表
• 在进行审计时要问的问题和要检查的领域的核对表

检查表通常需要针对流程或产品。例如，用于审计配置管理过程的检查表和用于审计需求开发过程的检查表是不同的。一个不同的核对表也将被用于同行审查设计规范和代码审查，不同的核对表将被用于Java代码审查和C代码的代码审查。检查表最初可以根据标准或指南创建，但随着时间的推移，应该随着经验教训的积累而不断发展。

另一种类型的工作指导是培训材料，用于教授质量管理系统及其流程、工作指导、方法和工具。培训材料的例子可以包括参考书、用户手册、基于计算机的培训、视频、网络研讨会，以及教师主导培训的学生手册。

项目层面的质量计划

项目级质量计划定义了一个项目打算如何实施组织的QMS，以满足组织和项目的质量目标和目的。软件质量计划可以在一个独立的软件质量保证计划文件中定义，也可以纳入项目计划中。其他质量计划，包括验证和确认计划、配置管理计划、供应商管理计划和风险管理计划，也可以作为子计划纳入项目管理计划或其他文件中，或者作为独立的计划文件。敏捷项目应该做质量计划，但这些计划可能很少或没有正式的文件（"只是足够的文件"）。对于敏捷项目，质量规划可以作为任务或项目记录在迭代积压（或Scrum积压）中。换句话说，计划的格式不是最重要的。重要的是，质量规划要发生，而且要根据项目的需要和风险程度来记录它的严格程度。
根据IEEE软件质量保证流程标准（IEEE 2014），项目级软件质量保证计划（SQAP）应包括。

• SQAP的目的和范围的声明，所有相关术语和缩略语的定义，以及适用参考文献的识别。
• SQAP的概述，其中涉及到
  • 质量从业人员的组织及其独立性，包括与质量有关的角色和责任，以及与其他利益相关者群体（项目管理、开发、组织质量管理、供应商等）的关系，以及与质量有关的角色的独立程度，以促进客观性.
  • 识别软件产品风险，包括安全、保障和其他产品风险（区别于项目风险）。
  • 描述用于执行SQA任务的工具
  • 识别具体的质量相关标准、实践、惯例和指标（例如，文档标准、建模和编码标准以及测试标准）。
  • 对工作的估计，人员和其他资源的分配，以及SQA里程碑和计划的SQA活动、任务和结果的时间表
• 对产品保证的具体活动、结果和任务的定义，包括评价。
  • 符合性的计划
  • 产品的符合性和可接受性
  • 产品生命周期中对一致性的支持
  • 测量是否客观地证明了产品的质量
• 过程保证的具体活动、结果和任务的定义，包括对以下内容的评价。
  • 生命周期过程的符合性
  • 促进一致性的环境
  • 供应商过程的一致性
  • 测量结果是否能客观地证明过程的质量
  • 工作人员的技能和知识
• 对其他SQA考虑的具体活动、结果和任务的定义，包括。
  • 合同审查
  • 质量测量
  • 弃权和偏差
  • 任务迭代
  • 沟通策略
  • 不符合要求的过程
• 确定与SQA相关的记录和报告，包括与分析、识别、归档、维护和处理这些记录和报告有关的活动和任务，并按要求提供这些记录和报告。

特定项目或量身定做的流程

虽然标准化流程定义了什么是 "通常最有效的"，但它们并不总是符合特定项目（项目或产品）的确切需要。处理这种情况的一种方法是对标准化流程进行定制。流程定制改变或调整一个流程以适应特定的用途，并允许标准化流程为项目的需要而适当地实施。定制可以详细说明过程描述，提供额外的细节，以适应特定项目的目的或背景。定制可以从一个过程中删除对特定项目不需要的步骤。定制也可以包括对流程的内容或步骤的广度和深度进行调整。例如，在一个比典型项目小的项目上，标准化的流程可以被定制，以消除不必要的审查或批准级别，因为同一个人被分配到多个角色。在比一般项目大的项目上，可能需要在标准化流程中增加额外的步骤，以允许额外的沟通渠道或管理级别。一个项目的流程定制可以作为项目计划的一部分来定义，也可以在单独的流程定制文件中定义。

所有的CMMI模型都包括一个建立定义流程的通用做法。"这种通用做法的目的是建立和维护从组织的标准流程集中定制的流程描述，以解决特定实例的需求"（SEI 2010）。

处理特定项目的流程要求的另一种方法是创建新的、特定项目的流程。例如，一个与另一个组织的合资项目可能需要的流程与标准的组织流程有很大的不同，以至于定制流程会很费力和混乱。在这种情况下，编写项目专用流程可能是最好的解决方案。

特定项目或量身定做的工作指令

与流程文件一样，根据项目（计划或产品）的需要，可能需要定制标准的工作指示。例如，审计的核对表可能需要定制，以包括针对被审计的过程所做的任何定制。
项目可能还需要创建针对项目的工作指南。例如，一个合资项目可能使用一个与组织通常使用的完全不同的问题报告工具。在这种情况下，将创建关于如何使用新工具打开问题报告的特定项目指南。

程序级和产品级的文件

许多软件开发或维护计划是作为项目运行的。然而，根据开发或维护工作的背景，在程序级或产品级而不是在项目级实施质量计划和特定/定制的流程和工作指令可能更合适。程序级或产品级文件可能适合的例子包括：

• 如果多个项目作为一个单一的项目被协调，而相同的计划、过程和工作指令需要被所有的项目所共享
• 如果正在使用增量开发，并且需要在每个增量中共享相同的计划、流程和工作指示
• 如果使用的是迭代或敏捷开发，并且需要在整个产品中共享相同的计划、流程和工作指令，一个迭代接一个迭代。

客户和其他利益相关者

描述并分析各种利益相关者群体要求对软件项目和产品的影响。

利益相关者是指影响产品、项目或过程的决策、活动或结果或受其影响的个人、团体或组织，因此对该产品、项目或过程的要求有某种程度的影响。利益相关者可以是任何级别的。他们不一定要有管理职称或任何官方级别的权力。一个低层次的个人贡献者或用户可能是一个重要的利益相关者，如果他们能够影响产品、项目或过程的要求、接受度、质量认知或其他因素，无论是作为个人还是作为一个集体。

产品利益相关者

产品利益相关者主要有三类：软件的供应商、软件的获取者和其他利益相关者。

收购者类型的利益相关者可以分为两个主要群体。首先，是选择、要求、购买和/或支付软件的客户，以满足他们的商业目标。第二类是实际直接使用软件的用户，或通过接收软件产生的报告、输出或其他信息间接使用软件的用户。第三类用户是不友好的用户，用户认为软件应该 "不友好 "地阻止他们完成他们的目标。对于一个加油站的加油机系统来说，不友好用户的例子包括黑客、信用卡/借记卡窃贼、造假者、持有过期或超限信用卡/借记卡的人，以及试图未经授权访问软件的数据或功能的人。也可能有许多不同类型的直接用户。一个软件产品有新手用户、临时用户和高级用户。也可能有具有不同知识或技能水平、不同角色或目标、不同访问权限或不同动机的直接用户。例如，"加油站付费 "系统的用户包括加油站的经理、服务员、购买汽油的车主、购买柴油的十八轮车司机、文盲和不会说英语的人。这些利益相关者群体中的每一个都可能对软件提出不同的要求。

软件的供应商利益相关者被分为两类。开发者是属于开发和/或维护软件的组织的个人和团体。开发者利益相关者包括项目/技术经理、需求分析员、设计师、编码员、测试员、软件质量工程师、配置管理专家、市场、销售、制造、硬件开发、法律、技术支持人员或供应商组织内部的其他团体，以及供应商/分包商。分销商是指分销软件的个人和团体。分销商的利益相关者包括销售文字处理器软件包的办公用品商店，或者在他们正在建造的高楼中安装能源管理和建筑自动化系统的建筑公司。

其他利益相关者，即那些不属于供应商或收购商群体，但仍可能对软件有一定程度的影响的人，包括：。

• 制定影响软件产品的法律、法规和标准的立法者或监管机构。
• 为软件产品制定行业标准或准则或定义行业良好做法的组织
• 受产品收购者或供应商的行为或决定影响的其他团体或个人。
• 甚至整个社会都可能对软件有既得利益。

项目利益相关者

项目管理协会（PMI）《项目管理知识体系指南》（PMBOK指南）将项目利益相关者定义为 "积极参与项目的个人和组织，或者其利益可能受到项目执行或完成的积极或消极影响"（PMI 2013）。项目利益相关者包括。

• 资助、发起和/或支持项目的个人
• 项目经理和项目团队的成员
• 不在项目团队中的支持项目的个人（例如，律师、监管专家、审计师、采购）。
• 项目所产生的产品的利益相关者
• 必须与该项目对接或协调的其他项目/计划的个人
• 项目/计划管理办公室

CMMI for Development（SEI 2010）和CMMI for Acquisition（SEI 2010b）中的项目规划和项目监测与控制过程领域，以及CMMI for Service（SEI 2010a）中的工作规划和对照计划监测工作过程领域，都通过纳入规划和监测利益相关者参与的子实践来处理项目利益相关者。

下图显示了PMBOK中定义的四个项目利益相关者管理流程，以及这四个流程之间的内部信息流和与其他项目管理流程的外部信息流。这四个过程也可以被概括，适用于产品和过程的利益相关者，以及项目利益相关者。

识别利益相关者过程的目的是识别影响或受项目决策、活动或结果影响的个人、团体或组织。这个过程还分析和记录与项目有关的要求和这些利益相关者的动机，以及他们对项目的兴趣、权力/权威、与其他项目利益相关者的影响，以及他们对项目变化的影响或能力。

计划利益相关者管理过程的目的是计划适当的战略和战术，以便在整个项目中与确定的利益相关者有效互动。这个计划包括确定利益相关者沟通机制和利益相关者参与计划。

管理利益相关者参与过程的目的是在整个项目生命周期中与利益相关者有效沟通和合作，以满足他们的期望/要求，管理问题，并促进适当的利益相关者项目活动。根据Dudash（2015），"项目经理必须通过倾听当前的业务需求来管理利益相关者的期望，解决任何尚未说明的利益相关者要求，并调整项目交付物以满足这些需求"。
控制利益相关者管理参与过程的目的是监测利益相关者的沟通、互动和关系，并在必要时采取纠正措施。

过程利益相关者

过程利益相关者是指影响或受软件过程或其结果影响的个人。过程利益相关者包括

• 直接参与过程活动或步骤的计划、管理、执行、跟踪和/或控制的个人
• 界定、记录和改进过程的个人
• 负责资助过程活动的过程赞助商
• 支持该过程的个人
• 该过程所生产的产品的利益相关者
• 必须与该过程对接或协调的其他过程的利益相关者
• 负责审计或评估过程的个人

所有三个CMMI模型都包括识别和参与 "流程的相关利益相关者......在流程执行期间 "的通用做法（SEI 2010、SEI 2010a、SEI 2010b）。

识别和参与相关利益相关者的好处

在有关软件产品、流程和项目的决策中，识别并让相关利益相关者参与其中有很多好处。识别和考虑所有不同利益相关者的需求，有助于防止需求被忽视。例如，如果一个项目正在创建一个工资系统，而他们没有考虑到慈善机构是利益相关者之一，他们可能不包括软件扣留、处理、跟踪和报告慈善机构的工资扣除的要求。让利益相关者参与需求工程，可以消除两种最无效的需求激发技术：千里眼和心灵感应（基于Wiegers 2013）。

产品、流程或项目从业者永远不可能像利益相关者知道的那样了解利益相关者的工作。识别并让关键的利益相关者参与进来，可以接触到利益相关者的经验基础和领域知识。实践者的工作是分析、扩展、综合、解决所有利益相关者之间的冲突，并将所有的利益相关者的输入合并成一套有组织的产品需求、流程定义或项目计划。识别不同的利益相关者并让他们参与进来，也会带来不同的观点，有助于对要完成的工作有一个更完整的看法。

许多人对变化感到不舒服，因此抵制变化。新的或改进的软件产品、流程和项目通常需要改变至少一些利益相关者执行其部分或全部工作的方式。获取利益相关者的意见和参与，让他们根据自己的需要参与到变革中来。参与的利益相关者更有可能接受已完成的工作，这可以创造 "所有权"，并使他们成为利益相关者社区中变革的拥护者。这对新产品、流程或项目向利益相关者环境的过渡是有益的。

"也许开发工作中最常见的一个错误就是把一个重要的人排除在过程之外"（Gause 1989），而利益相关者的识别和参与有助于避免这种错误。

外包服务

目的：确定外包服务对组织目标和目的的影响，并确定评估供应商/供应商和分包商的标准。

在当今快节奏的软件业中，客户要求更大、更复杂的软件产品具有高质量、更低的成本和更快的上市时间，软件组织不得不寻求他们所能获得的任何竞争优势。将全部或部分软件产品的开发或维护工作外包给组织外的供应商，有时可以提供一种优势。外包可以通过多种方式完成。

• 现场，供应商与收购方在同一地点。
• 异地，供应商与收购方位于同一城市、州或国家。
• 离岸，供应商位于与收单方不同的国家。

根据不同情况，外包可以提供几种不同的竞争优势，包括。

通过利用价格较低但能力相当的外包人员来减少人员。

• 通过减少国内其他地区或其他国家的间接费用和设施费用来降低运营成本。例如，德克萨斯州普莱诺市每平方英尺的办公空间成本比纽约曼哈顿市低。
• 提供获得更多熟练人员以及其他资源的机会，而不需要花费时间和费用来雇用和培训个人或购买非人力资源。
• 通过提供更多的人员和资源，减少准备时间，从而使更多的工作在更短的时间内完成，从而缩短了进入市场的时间。请记住，这些新增人员必须经过适当的计划并整合到项目中。正如Fredrick Brooks (1995)在《神话般的人月》中指出的那样，"在一个晚期的软件项目中增加人力会使它更晚"。
• 通过与在某一特定领域拥有更多专业知识的供应商合作，或与组织内部拥有的更成熟的流程合作，来提高质量。例如，一家电信公司可能将他们的关系数据库开发外包给在该领域具有更多专业知识的组织。
• 利用供应商提供的创新。
• 允许组织专注于核心竞争力，同时获得创造这些竞争力之外的软件所需的专业知识。例如，一家生物医学公司可能专注于开发生物医学软件，并将其工资或库存控制软件外包。
• 通过将部分风险转移给供应商来减轻或分担风险。

虽然存在许多潜在的外包好处，但外包也可能是有风险的。"管理不善、无法阐明利益相关者的需求、需求定义不完善、供应商选择和签约过程不完善、技术选择程序不完善、需求变化不受控制，都是导致项目失败的因素"（SEI 2007）。

采集过程

收购是获得软件的过程。获取可以通过内部开发、外包或这些方法的组合来完成。外包可以包括购买现成的商业软件（COTS），由第三方供应商开发定制的软件，或者两者兼有。

有了明确的软件采购管理流程，也有利于将一个采购项目的经验教训传播到下一个项目，这样我们就可以重复我们的成功，停止重复导致问题的行动。

步骤1：启动和计划收购

当想法或需求被确定后，启动和计划收购步骤就开始了。在这个收购过程的第一步中。

• 确定采购的利益相关者，并确定其动机。

• 对软件的业务需求进行描述。业务需求定义了软件采购背后的 "原因"。商业需求可以是一个需要解决的问题，也可以是一个企业希望通过购买软件来利用的机会。业务需求还包括对项目所基于的任何假设的描述，以及对项目的任何限制，包括诸如时间表、预算、资源、要重复使用的软件、要采用的技术，以及与其他产品的接口等因素。

• 购置项目是由管理层制定的。在一个公司里，资源总是有限的。因此，必须进行成本/效益和风险分析，以确定资助和执行潜在的收购项目是否是企业的正确选择。如果是这样的话，收购项目就会被特许进行。

• 指定关键的收购角色，包括。

  • 收购发起人。负责提供组织影响力的角色，以帮助在收购方的组织内证明和推销 收购的合理性。
  • 收购经理。这个角色作为收购项目的项目经理。
  • 收购团队的成员。收购团队成员个人的作用是充分代表他们的利益相关者组织，并执行指定的任务。
  • 代表。来自客户和/或用户社区，以及其他与收购团队合作的关键利益相关者，以确定业务需求和软件要求。

• 购置计划。建立计划以详细说明在整个采购项目的生命周期中要采用的方法。从长远来看，花在前面的时间来定义采购策略将得到回报，因为它保证了整个采购过程和软件寿命的稳定性。采购计划过程应该

  • 将采购目标和任务与资源（时间、人员、资金和技术）联系起来
  • 估算资源需求，并计划获取、利用和控制这些资源
  • 确定一种方法来获得所有利益相关者的批准，以保证采购计划的通过。
  • 界定采购活动，并规定工作的整合性
  • 指定用于跟踪和控制该采购项目的审查和关键测量指标
  • 识别、分析、减轻和控制风险

步骤2：定义产品需求

在采购过程中，定义产品需求的步骤定义了软件产品本身。这包括将业务需求清单细化为明确的、业务层面和利益相关者层面的需求。这个步骤也定义了采购的范围。必须对所需的产品进行充分的分析，并确定和记录其业务目标、利益相关者的功能要求、业务规则和质量属性。采购团队应该对需求进行优先排序，并将需求与愿望分开。成功的采购项目取决于对所需产品的明确定义。

第三步：确定采购方法

在确定收购方式的步骤中，收购团队必须确定收购软件的机制。有三种基本选择。

• 内部开发软件。在这种情况下，收购项目成为一个软件开发项目，不被视为外包。
• 将软件外包。软件外包可以通过购买以下一种方式完成。
  • 现成的商业软件（COTS）是现成的软件，可以被组织收购和使用。这可以包括。
    • 现成的商业软件（例如，文字处理器，或支持工具，如编译器、测试自动化工具或分析器）。
    • 可修改的现成软件（MOTS），可根据个人要求进行调整或定制（例如，允许定制字段和报告的数据库工具）。
    • 政府现成的（GOTS）软件，是政府提供的即用型软件产品。
  • 开放源码软件
  • 由外包组织（供应商/卖家）开发的定制软件

这些采购方法的组合。该组织可以选择使用内部开发和外包的软件的组合。他们可能在内部开发大部分的软件，但将一个或多个功能分包给具有专业技能的供应商。例如，他们可以将GUI界面或安全功能分包给在这些领域有特殊专长的供应商。另一个选择是将执行特定功能的COTS软件整合到内部或外包的定制软件产品中。例如，一个COTS数据库管理器可以被整合到一个正在内部开发的库存跟踪软件产品中。

第四步：识别和评估潜在的供应商

在识别和评估潜在供应商的步骤中，采购团队要进行市场搜索以识别可能的供应商。在市场搜索过程中收集的数据可以作为反馈，重新评估最初的产品定义，并确定对该定义的修改是否会在成本、性能、可用性、可靠性和其他属性方面产生更大的整体价值。市场分析还应该评估维护和支持、测试结果和用户满意度分析。利用市场搜索的信息，采购团队将所有可用的供应商名单缩小到最符合业务需求和产品定义的少数潜在供应商。这就使评估有的放矢，使评估费用降到最低。然后，采购团队通过检查他们的能力、质量体系和产品（例如，通过供应商资格审计或评估软件的演示副本）来评估这些被选中的潜在供应商。另一种方法是，从预审合格的首选供应商名单开始，完成这项工作。这种分析所需的深度取决于采购的需求和特点。然而，应注意获得足够的信息，以比较每个潜在供应商的资格，从而做出一个明智的决定。
正式的征求建议书（RFP）过程通常用于涉及由供应商开发的定制软件的大型项目。这是一个非常正式的过程，收购方在招标书中列出具体的建议要求和问题，并由供应商在书面建议中作出回应。在即将到来的招标书上做广告，可以发现未知的供应商，也可以鼓励供应商提供技术投入和商业建议。潜在的供应商可能会提出以前不知道或不考虑的新技术和能力。征求建议书应包括由供应商执行的可量化、可测量和可测试的任务，项目使用的规格和标准，收购方提供的设备、信息和/或使用的软件，以及对生产的产品和服务的要求（GSAM 2000）。
其他获得信息和评估潜在COTS供应商的机制包括。

• 供应商演示。对于COTS软件，举行供应商演示提供了一个很好的机会，可以亲眼看到产品并提出问题。在现场演示中实际看到不同软件的功能，为比较提供了一个背景。也许基本功能是相当的，但一个产品有一个更直观的用户界面。供应商代表的产品知识和信心水平，以及他们回答棘手问题的意愿，可以成为未来关系的一个指标。未来支持的另一个指标是供应商是否提供了一个 "罐装 "演示，或花时间定制他们的演示以具体解决收购方的业务需求和要求。
• 评估副本。对于许多COTS产品来说，评估副本可以作为演示软件功能和能力的机制，也可以引起用户的认同。
• 参考资料。评估参考资料和过去的产品性能可以提供信息，用来评估软件的功能和质量。

获取信息和评估潜在的定制软件供应商的其他机制包括：。

• 过去的业绩。评估推荐人和过去的项目业绩可以提供有用的信息。一个拥有成功提供软件的一贯历史的供应商，更有可能在未来有效地执行。过去的业绩是一个强有力的指标，表明供应商是否有能力在计划内、预算内成功完成交付，并达到所需的功能和质量水平。以前在类似产品上的经验也是一个可靠的指标，表明供应商在未来能成功履约的可能性。
• 资格预审审计。对潜在供应商的审计信息可用于确定他们是否有能力生产符合质量、完整性、安全或保障水平要求的产品。
• 原型。对于定制的软件，原型设计可以用来确定供应商是否理解要求，或者作为概念的证明。

第五步：确定合同要求

采购过程中的定义合同要求步骤通常只对开发定制软件的供应商有必要。选择合同或供应商协议的类型，并确定所需合同或协议的内容。合同/协议的内容是基于最初的要求，以及确定的产品和能力，因为潜在的供应商被评估了。成本、进度和范围之间的权衡也会影响合同/协议的内容。因此，采购过程中的第4步和第5步是反复进行的，因为它们相互影响。

第6步：选择供应商

在采购流程的选择供应商步骤中，根据既定的选择标准对供应商的评估结果进行判断。与每个供应商相关的风险被识别和分析，并进行成本/效益分析。基于这些信息，外包服务的最终供应商被选中。

可以创建一个或多个供应商评估记分卡，以总结所有的评估标准信息和单个成本、进度、产品和工艺属性的分数。应注意收集所有信息，并对供应商进行打分，以消除打分中的差异。这最好是在小组评分会议上进行，参与者可以得到所有收集到的信息来协助他们的评分决定。使用这些表格，并作为一个小组来评估分数，可以帮助保持势头，避免个人偏见，并确保一致性。可以使用不同的技术来给每个属性或标准打分。例如。

计算得分法: 根据预定的公式为每个属性分配分数。

加权计分法。给每个评价标准分配一个数字权重，然后将该权重乘以给每个潜在供应商的等级，得到各个标准的得分。各个分数相加后得出总分。

指数化打分法。使用特定的预定标准来选择每个分数，如图6.11所示。

一旦选定了主要的候选供应商，在最终选择之前，可以使用供应商资格审核作为对该供应商的质量体系和生产所需软件的能力的最后深入评估。

第七步：谈判和授予合同

一旦供应商被选中，就会就合同或供应商协议条款进行谈判，并授予合同/协议。现在是与首选供应商进行最后谈判的时候了。根据收购的类型，这个步骤可能像为COTS软件发布采购订单一样简单，也可能像谈判一个正式的法律合同一样复杂。

当需要一个正式的合同或协议时，一个写得很好的合同/协议可以将误解的概率降到最低，并且是收购方和供应商之间融洽关系的一个主要因素。经验表明，如果合同/协议是明确的，并清楚地界定了每一方的义务和责任，通常可以避免因对履行义务的争论而产生的敌意。在处理正式合同时，应始终寻求法律意见，并建议对大多数其他类型的协议进行法律意见。合同应该是定制的，以考虑收购方和供应商的优势和劣势。

如果谈判的结果是无法与供应商达成协议，可能需要选择另一个供应商。在这种情况下，采购流程的第6和第7步是反复进行的。

管理供应商

管理供应商的步骤包括在整个收购项目的执行过程中监控供应商的表现，以验证合同/协议的成功完成。同样，这个步骤的严格程度取决于采购的类型。它可能只是简单地验证COTS软件的订单是否到达并正确安装，没有问题，也可能是复杂地管理供应商多年的开发项目。
对于涉及定制化软件开发的收购，应使用持续的正式评估和衡量标准来监测供应商在基准预算、时间表和质量标准方面的进展，并管理与收购相关的风险。这可能包括持续的供应商审计、联合项目或产品审查，以及合作开展联合流程改进行动。其目的是让收购方对供应商的工作活动有足够的了解，以确信合同/协议义务和产品要求正在得到满足，或发现需要纠正的问题。"当供应商的表现、流程或产品不能满足供应商协议中的既定标准时，收购方可以采取纠正措施"（SEI 2010b）。

对于任何长度的收购项目，都会发生变化。因此，这一步也涉及到在整个收购项目的执行过程中对需求的管理和维护。必须实施需求管理机制来管理和控制这些需求的变化，并确认批准的变化被整合到采购计划、软件产品和活动中。这一步也可能涉及到在项目期间对合同/协议的任何需要的改变的管理。

第9步：管理采购项目

在整个收购过程中，收购项目应该像其他项目一样被管理。这包括执行项目，持续监控，采取纠正措施，如果实际情况和计划之间的差异变得不可接受，则跟踪纠正措施的结束，控制变化，并在获得更多信息时逐步阐述项目计划（或根据需要重新规划）。

当最终的软件产品包括内部开发的软件，并与一个或多个供应商的软件集成时，在收购方和他们的供应商之间建立充分的沟通是必要的。一个有效的机制是组建一个集成产品团队（IPT）。IPT是一个跨职能的团队，其具体目的是交付一个集成产品。IPT是由所有适当的组织（收购方和供应商）和职能部门的代表组成。IPT团队成员与团队领导一起工作，计划和实施一个成功的项目（收购方和供应商开发项目的相互关联的集合），识别和解决跨职能的问题，并作出合理和及时的决定。IPT成员应具有互补的技能，并致力于共同的目的、绩效目标和方法，并为之相互负责。

第十步 验收产品

在整个软件开发过程中，供应商应该进行验证和确认（V&V）活动。对于定制的软件，收购方应将这些活动作为供应商管理过程的一部分进行监控。作为产品验收的一部分，收购方也应该对交付的产品进行自己的V&V活动。V&V活动的例子可能包括α、β或验收测试，和/或功能和物理配置审计。这些V&V活动应根据合同/协议中包含的协商验收标准进行，以验证交付的产品符合所有商定的要求。供应商应纠正任何已发现的产品问题。

验收合格的软件将按照交付的方式使用，或者作为其中的一个组成部分被纳入收购方的软件中。如果该软件被集成到一个更大的产品中，集成和系统测试也应由收购方在该大产品上进行。

与其他项目一样，一个收购项目将结束，并需要关闭。这包括将产品过渡到运营，并将其支持过渡到维护模式。如果收购公司没有购买软件源代码的权利，该代码可以过渡到托管，这样，如果供应商倒闭或不再支持该产品，收购方就不会受到实质性的损害。收购方将能够从托管处获得源代码，并仍然支持其产品。

这一步还包括合同/协议的完成和结束以及任何其他相关活动。

第11步：使用软件

供应商的作用通常不会在软件被接受并投入使用时结束。供应商将继续为软件提供技术支持、纠正性发布以解决已发现的问题和/或功能发布以增加新的/更新的功能（完善性、预防性或适应性维护）。服务水平协议需要作为初始供应商协议的一部分进行谈判，或者作为补充协议，以确定供应商对这种持续支持的义务。

优选的供应商关系

尽量减少选择和监督供应商所需的努力的一个方法是建立首选供应商关系。潜在的和/或现有的供应商根据标准化的标准进行评估和评级，如他们的质量管理系统的有效性和过去的表现。达到或超过标准的供应商被确认为首选供应商，并有权获得额外的好处。这些好处可能包括选择优先权、减少监督、减少核查和验证活动，以及更多的商业机会。

首选供应商也可以被考虑在多个采购项目中建立战略伙伴关系。战略伙伴关系是一种企业战略，与一个或多个具有互补资源的供应商合作，以实现共同的商业目标。首选供应商和战略伙伴关系的好处可以包括。

• 充分利用能力
• 降低成本，改善服务
• 腾出内部资源
• 减少需要管理的供应商数量
• 分享最佳实践和流程改进措施，以提供共同利益

业务连续性、数据保护和数据管理

设计业务连续性、灾难恢复、业务文件和变更管理、信息安全以及敏感和个人数据保护的计划。

业务连续性

业务连续性被定义为 "组织在发生破坏性事件后以可接受的预定水平继续提供产品或服务的能力"（ISO 2012）。业务连续性是指规划、建立、实施、运行、监测、审查、维护和持续改进一个文件化的管理系统，以。

• 通过减少破坏性事件发生的概率来防止破坏性事件的发生
• 在破坏性事件发生时做好准备，制定应对和恢复策略和计划，使企业准备好采取适当的行动，从而将潜在的损失降到最低。

无论破坏性事件是属于 "照常营业 "的负面问题，还是属于重大灾难，都要做到这一点。根据业务连续性协会的说法，"业务连续性是指在你的企业中建立和提高复原力。复原力被广泛定义为一个组织吸收、应对和恢复中断的能力"（BCI 2013）。

业务连续性的管理从根本上说是风险管理的一部分。然而，业务连续性也包括信息安全、信息技术管理、合规和治理等方面。业务连续性协会定义了一个业务连续性管理的生命周期，其中包括六项良好的实践（基于BCI 2013）。

• 两个管理实践。
  • 政策和计划管理。界定业务连续性的组织政策，以及如何利用业务连续性项目管理来实施、控制和评估该政策的战略和战术
  • 嵌入业务连续性。将业务连续性做法制度化，纳入正在进行的日常业务活动和组织文化。
• 四项技术实践。
  • 分析。对组织及其关键业务功能进行分析和评估，以确定潜在的破坏性事件、其发生的概率，以及在这些破坏性事件发生时对组织继续履行关键业务功能的能力的影响。
  • 设计。确定并选择适当的战略和策略，以应对破坏性事件，并从破坏性事件中恢复，以尽量减少组织的关键业务功能的停止或阻碍。
  • 实施。创建并记录业务连续性计划，其中包括使组织能够应对破坏性事件并从中恢复的指示和程序，使组织的关键业务功能尽量不中断或受阻。
  • 验证。评估并确认业务连续性管理计划符合业务连续性政策目标，并确认该组织的业务连续性计划将实现其目的。

灾难恢复是业务连续性的一个子集，重点是组织在发生灾难（自然或人为因素）后恢复或继续运行支持关键业务功能的重要信息技术和技术系统的能力。

数据保护和安全

数据安全验证了正确的人可以正确地收集、访问、利用和更新数据，同时也检测、预防或恢复对数据的不适当的安全攻击。安全攻击的例子包括以下企图。

• 获得对数据的未经授权的访问（例如，通过后门访问数据，或通过欺骗、黑客攻击或隧道）。
• 破坏数据的完整性、可用性或保密性（例如，通过病毒、蠕虫、或拒绝服务攻击）。
• 不适当地收集、伪造或破坏数据（例如，未经授权或无意中披露机密信息，破坏数据加密，或数据污染)

安全攻击可以来自外部，来自黑客、被盗的身份或密码，或其他人试图利用数据/数据库的安全漏洞。安全攻击也可以来自内部，通过破坏行为、恶意代码（例如，定时炸弹、逻辑炸弹或特洛伊木马），或从业人员创建的后门。数据安全集中在四个主要目标上。

• 保持访问控制（密码、防火墙、多级权限)
• 维护数据的完整性
• 提供备份和/或恢复，如果安全机制发生故障，导致数据库或数据的损坏或丢失。
• 提供数据访问和使用的审计跟踪，以提供问责所需的信息。

备份数据是一个组织可以做的最重要的事情，以保护数据不丢失，并允许从数据损坏或灾难中快速恢复。

数据管理

从本质上讲，数据管理这个词实际上是对自己的定义--也就是说，它只是对数据的管理。数据管理也被称为信息管理、企业信息管理、企业数据管理、数据资源管理、信息资源管理和信息资产管理。数据管理活动包括

• 对数据管理进行规划
• 协调/控制数据收集和存储活动
• 协调数据维护活动
• 协调/控制数据传播活动，以响应和经济地获取、访问和分发数据
• 协调数据归档和处理活动

汤姆-彼得斯指出，"那些不了解在新经济中把数据和信息作为有形资产进行管理的极端重要性的组织将无法生存"（DAMA 2009）。数据管理流程的输入包括来自数据供应商的需要管理的数据产品，以及来自组织、项目和人员以及其他流程的数据请求。数据管理过程的输出被存储在受保护的数据存储库中，数据和信息产品被交付给组织、项目和人员以及其他过程。数据管理协会（DAMA）的《数据管理知识体系指南》（DAMA 2009）所定义的数据管理的功能如图。

GEIA-859数据管理标准（2009）"旨在阐明当代数据管理原则和方法，广泛适用于商业和政府部门的电子和非电子数据的管理"。该标准定义了图中所示的九项数据管理原则。

数据管理-治理

数据治理是数据管理的集中和整合活动。数据治理涉及数据管理规划和数据资产的监控。数据治理活动包括。

• 规划。
  • 战略。了解组织的战略数据需求，并开发、定义和执行一个数据战略以满足这些需求。
  • 组织和角色。定义和建立参与执行和管理每个数据管理和治理活动的组织和角色
  • 政策和标准。建立、记录、实施和维护数据政策、标准和程序
  • 项目和服务。启动、规划和赞助数据管理项目和服务，包括审查和批准数据架构，估计数据资产价值和相关成本。

监测和控制。

• 监督。监督数据专业组织和工作人员，管理数据管理项目和服务，并协调数据治理活动。
• 问题。跟踪数据管理问题的解决
• 变更管理。要求、记录、进行影响分析、审查、批准和跟踪对受控数据、数据记录、数据架构和信息产品的修改要求，直至解决。
• 保证。监测和验证监管合规性，以及对数据政策、标准、程序和架构的合规性。
• 锦标赛。沟通和促进数据资产的价值

数据管理-规划

数据管理规划为组织内或计划/项目内的所有数据管理建立和沟通流程，这取决于规划所涉及的数据管理水平。与其他规划活动一样，数据管理规划所要求的严格程度和文件数量可能会根据组织的需求和涉及的风险而有所不同。数据管理规划考虑了以下计划。

• 数据管理利益相关者的识别
• 数据的收集/接收，包括组织/计划/项目内的数据流，以及来自外部利益相关者（如客户或供应商）的数据流
• 独特的数据识别，包括版本控制
• 数据管理角色和责任/权力分配
• 数据质量的保证
• 储存、转换、传输和提供对数据的访问
• 数据管理中使用的工具
• 数据变更管理
• 与数据管理有关的培训

数据管理-数据收集和存储

协调/控制数据收集和存储活动，首先要确定数据要求。这包括识别元数据的要求，元数据是关于数据的数据。数据识别对数据和数据产品进行定性，以确认其充分性、独特性和一致性。它保障了团队成员之间的数据互操作性，因此每个人都在以一致的方式收集、解释和使用数据。建立机制来分配识别信息，以区分类似或相关的数据产品（例如，配置控制委员会（CCB）的名称和会议日期可能被用来区分一组CCB会议记录和另一个）。

然后设计数据管理架构。数据管理架构是一套集成的规范，它定义了信息需求、用于设计数据解决方案的数据模型、数据库的架构、数据集成、数据仓库、商业信息和元数据。数据管理架构定义了正式的名称、数据定义、数据结构、数据完整性规则，以及为满足这些信息需求所需的每个数据项目的健全的数据文档。数据管理架构有助于为重要的计划/项目实体，以及关于这些实体的数据属性建立一个共同的词汇表。

一旦架构建立，就必须设计和实施解决方案组件，包括数据库和其他数据结构、数据采集、访问和使用组件以及用户界面组件。

如果不能正确地收集正确的数据，那么数据管理项目的目标就不能实现。没有好的数据，数据分析是毫无意义的。因此，建立良好的数据收集过程是任何成功的数据管理计划的基石。其目标是：数据收集应该是。

• 客观性。每次都由同一个人以同样的方式收集数据。
• 明确：两个不同的人，为同一个项目收集相同的数据，将以相同的方式收集数据。
• 方便的。数据收集必须足够简单，以至于不会扰乱收集数据的人的工作模式。这意味着数据收集必须成为流程的一部分，而不是在工作流程之外的一个额外步骤。
• 可访问性。为了使数据变得有用并被使用，需要对数据进行方便的访问。这通常意味着，即使数据是在表格上手工收集的，它们最终也必须被输入到数据库。
• 及时性。数据收集和报告必须是及时的。

数据管理-数据维护

数据维护活动包括

• 通过调整、监控、访问控制、错误报告、纠正措施和变更控制，保障数据库的性能、可靠性、完整性和安全性。
• 提供支持数据可用性要求的机制
• 实施和控制数据库环境
• 安装和管理数据技术
• 支持数据技术的使用和相关问题
• 对收集的数据进行技术数据完整性检查，监测存储的数据以确认是否符合内容和格式要求，并识别存储数据的错误或损坏。
• 处理数据技术许可证
• 核实当前备份副本的存在，以便进行紧急恢复
• 如果数据的预期寿命长于媒体的预期寿命，则补充当前的存储媒体，或将数据迁移到现代的存储媒体。

如果发现问题领域或改进机会，数据维护活动包括实施适当的纠正或预防措施。数据管理纠正或预防行动的例子包括。

• 纠正数据的异常情况
• 改进数据收集或报告机制
• 纠正/改进数据管理流程，使其更有效率或效果
• 对数据管理工具或基础设施进行改进，包括。
  • 更新到一个新版本的工具
  • 迁移到一个更好的工具
  • 购买更快的数据存储设备
  • 为网络添加更多的容量以提高可用性

数据维护活动还包括实施经批准的变更控制流程，用于控制对以下内容的变更。

• 数据和元数据
• 数据要求、数据管理架构、数据组件设计和实施
• 数据产品和视图
• 数据库环境及其配置
• 数据管理流程
• 数据管理工具和基础设施

数据管理-数据传播

协调/控制数据传播活动，向授权方提供数据，包括。

• 创建、实施和维护提供数据访问指示的文件
• 接收、评估和回应对数据和信息的请求
• 在允许访问数据库之前，以及在将数据和信息发布/转移给请求者之前，确认电子访问规则得到遵守

当数据被用来制作正式的信息产品时，它们通常要经过一个过程，由数据供应商创建并提供信息产品，然后在正式接受之前经过验证和确认。数据和信息产品也可以通过直接访问查询和响应对进行不太正式的分配。例如，一个用户可能使用结构化查询语言（SQL）来请求一份在指定时间段内针对指定产品报告的所有缺陷的报告，而响应则是这些缺陷的列表。许多数据库都有预定义的报告，称为视图，允许用户通过选择该视图并输入特定的参数来直接生成他们自己的报告。例如，一个项目管理工具可能有一个挣值报告视图，可以为当前活动项目选择。

数据管理-数据归档和处置

协调数据归档和处置活动包括。

• 确定数据何时不再被积极使用（但对组织仍有价值），以便将其归档（注意，可能有法律和/或法规规定了记录保留期，因此影响到数据归档和处置的做法）。
• 当数据不再有价值时，对数据进行处置