中文翻译《ASPICE in practice》之“SUP.9 问题解决管理”

2.17 SUP.9 问题解决管理

2.17.1 目的

问题解决管理过程的目的是确保所有发现的问题都得到识别、分析、管理和控制以得到解决。

问题解决管理是关于组织以结构化、可追溯的方式识别、分析、监视、控制和消除问题的能力。 实际上，此过程的实施通常基于状态模型。 这样的模型包含问题的不同状态（例如，已接受、进行中、分析中，见图 2-15）以及状态转换的条件。

收集统计数据，例如有关特定状态下问题持续时间的统计数据以及以趋势分析形式进行的数据分析有助于确定项目问题管理随时间的改进或恶化，得出趋势，并在必要时启动反制措施。 问题解决管理可应用于各种问题和缺陷，是提高客户满意度的主要因素。 此过程与变更管理过程 (SUP.10) 密切相关。 SUP.10 描述了所有类型变更的变更管理中的工作流程，而不仅仅是问题。

就管理系统而言，问题和其他变更（例如，需求变更、设计变更）以相同的方式进行管理、处理和跟踪。SUP.9 侧重于解决问题特别需要的工作步骤。BP7 与 SUP.10 有一个清晰的接口：诊断出的缺陷是工作产品变更的基础，并在变更管理系统中进一步处理。

评估员须知

由于相似的工艺要求、相同的处理、相同的责任，这两个过程的访谈经常结合在一起。应注意两个过程的相互作用：SUP.9为SUP.10提供了可能的输入。

2.17.2 汽车行业特有的特征

在车辆系统的开发中，有一个生产开始 (SOP) 日期，在这一点上，产品（由硬件和软件组成的系统）应该100%完成且无故障。以后检测到的每个缺陷都将导致维修或召回和相关的高成本，以及制造商的形象损失。与IT系统的开发（在连续软件发布的上下文中很容易消除缺陷）相比，功能齐全的问题解决管理变得越来越重要。

复杂的车辆部件由许多具有分布式功能的子系统组成。在系统中特定位置发生的问题不一定是在该位置引起的。这使得问题的定位更加困难。

2.17.3 基本实践

BP1：制定问题解决管理策略。 制定问题解决管理策略，包括问题解决管理活动和生命周期模型、执行这些活动的职责和资源。

该策略的最低要素是：

1. 关于问题处理的规范，包括所需的活动（问题描述和问题捕获、数据收集、分析、更正等）
2. 指定负责执行这些活动的员工。
3. 问题跟踪系统（定义的生命周期，包括问题状态和问题优先级）
4. 问题处理的预定义时间段（状态转换的最长时间）
5. 关于对相关人员（报告缺陷的人、项目团队成员、管理层）的反馈的指南

问题解决管理策略可能是问题管理计划（第 2 级）的一部分，并且应该能够与变更管理策略（SUP.10，BP1）相互作用。

BP2：建立一致的问题解决管理程序。

  建立问题解决管理流程，以确保基于问题解决管理策略以一致和可追溯的方式检测、描述、记录、分析、解决和预防问题。 定义和维护与受影响方的接口。

基于问题解决管理策略，必须指定并记录合适的方法（例如，以问题管理计划的形式）。 它通常从问题的报告和记录开始，到最终和经过验证的删除结束。 有必要引导问题报告采用的路径。 为此，应指派一名中央联系人，并将其与所有其他职责一起记录在项目中。 最好有适当的工具支持，例如使用可通过内联网或互联网获得的变更管理系统或数据库。

在包含子项目的大型项目中，通常很难跟踪未解决的问题及其在特定截止日期（例如，交付前）的状态。 为了避免繁琐的人工收集信息，建议建立一个满足以下要求的问题解决管理系统：

1. 尽可能准确地记录与问题描述相关的信息。 除了对问题的描述外，这还包括问题出现的条件、发生日期、报告人等。
2. 每个问题都被唯一标识，例如，通过编号方案。
3. 每个问题都分配给一个人进行分析、解决等。明确分配了与结果工作步骤有关的责任。
4. 区分不同的问题状态。 这样就可以在任何给定时间确定问题的确切状态以及它保持该状态的时间。 如果状态中的滞后时间超过允许的时间，则可以注意到并迅速做出反应。 例如，可能已定义客户将在问题报告后的三天内收到有关问题解决方案的信息以及问题原因的简要说明和更正日期。图 2–15 说明检测到问题或缺陷后，其状态通常设置为状态 »open«。 进一步处理的关键是后续的问题或缺陷分析（状态»分析中«）。 根据结果，启动进一步的步骤，最终导致问题的解决。 然后状态设置为 »closed«。

图 2–15 问题状态示例

1. 分配问题处理的优先级（关于这一点另见 SUP.9 BP4）。
2. 计划已完成（例如，定义问题解决的截止日期）。客户、最终客户和问题报告者分别期望与他们的问题相关的反馈。 这就是为什么要定义问题报告者接收有关问题解决进度的反馈的时间和频率的原因。 以下以客户为导向的时间管理方法在实践中被证明是成功的：

• 问题报告者会立即收到他的报告已被记录的反馈，包括可能查询的参考编号 (ID)，

• 关于预期更正日期的反馈（尽快）

• 关于成功关闭的反馈，包括影响或变化的指示。

BP3：识别并记录问题。 每个问题都被唯一标识和记录。

注意：问题通常记录在数据库中。 需要提供必要的支持信息以支持问题的诊断。

注意：唯一标识支持对所做更改的可追溯性。

解决问题的前提是它的描述。 描述得越具体、越详细，后续的根因分析就越容易。 如果只是为了可追溯性和后期可检测性，问题必须被唯一标识（例如，通过 ID）并在记录后集中管理（例如，通过数据库）。 问题和其他变化通常是共同管理的。 如果两个实体的后续划分（例如，为了统计评估）是可能的，则对此没有异议。 此外，并非每个公认的问题都必然会导致改变。

已接受问题的记录和管理在问题解决管理系统或包含问题记录的所有必要信息的列表中完成，例如：

1. 问题编号（ID）
2. 优先事项
3. 日期（报告的）
4. 受影响的硬件版本、受影响的软件版本
5. 问题记者
6. 问题描述，包括约束和支持问题诊断的所有可用附加信息
7. 分析结果
8. 问题对其他系统/领域的影响
9. 必要的措施和变更，包括唯一变更 ID
10. 负责人（解决）
11. 目标发布版本
12. 到期日

图 2–16 显示了问题或更改报告的示例。

图2-16问题或变更报告的示例

BP4：调查并诊断问题的原因和影响。

调查和诊断问题的原因和影响，以确定适当的操作并提供分类。

注：问题分类（例如，A、B、C、轻度、中度、严重）可能基于严重性、影响、关键性、紧迫性、相关性等。

问题在收到时进行分类（另请参见图 2-17）。 同时问题报告者被告知收据。 一个先决条件是解决问题和问题分类所需的所有信息都是完全可用的，或者可以在短时间内获得（即通过向问题报告者查询）。 问题分类用于确定问题的优先级并导出一系列解决步骤。 优先级的标准是，例如，关键性、紧迫性、对主承包商或最终客户的预期影响。

图 2–17 问题分类方案示例

最重要的是，必须承认特别紧急的措施（见 BP5）。 通常在采取任何有关消除问题的行动之前进行分析。 这样做的原因是通常只报告问题的症状或影响，而不能直接得出关于其原因的结论。 在实践中，问题的分析通常分配给负责假设缺陷的开发人员。他负责详细的调查和分析、文档、状态更新，并且——尤其是——在计划内解决问题。 这并不一定意味着他需要自己完成所有这些活动。

许多问题都是局部的，不费吹灰之力就可以解决。 然而，有些问题需要在整个系统的不同部分进行修复才能消除。 由此确定的影响为回归测试提供了重要信息。 有些问题的影响远远超出项目范围：例如，如果在广泛使用的软件单元（例如驱动程序、平台软件）、其他项目甚至可能已经交付给客户的产品中检测到缺陷 通常也会受到影响。 在这些情况下，将需要更全面的措施。

作为补充措施，可以执行“根本原因分析”(RCA) 以改进流程。 在 RCA 中，不仅要分析和消除问题，还要分析和消除其原因（例如，工艺差距、工具问题）。 这是防止将来再次出现问题的唯一方法。

BP5：必要时执行紧急解决行动。

如果在实际更改之前需要立即解决问题，则获得立即修复的授权。

注：在紧急解决行动之后，应根据 BP2 建立问题解决管理程序，并根据 BP3、BP4、BP7 和 BP8 推进。

在出现影响严重的严重问题（如严重故障、系统故障、系统无法启动、生命和肢体有危险等）时是否需要立即采取行动。 充其量，已经制定了可以立即实施的应急计划。

可能的立即措施是，例如，立即消除缺陷原因，可能与关闭已经运行的系统有关。 可能的直接外部措施可能包括发布警告通知或召回行动。 此类措施需要管理层授权。大多数直接措施会影响整个项目，即供应商和 OEM。

为了使项目或组织能够应对即时措施的实施，必须事先建立必要的规则和条件（应急计划）作为问题解决管理策略的一部分。 因此，可以定义以下参数：

1. 预定义的组织警报级别
2. 明确供应商和主机厂在紧急情况下的责任和任务
3. 决策权或升级机制取决于警报级别
4. 进一步的行动过程，例如：

• 成立专家团队进行问题厘清。
• 以最紧迫的方式进行澄清。
• 根据决策规则制定并商定一揽子措施或可能的几个选项。
• 验证措施的有效性。
• 在立即采取措施后，将进行详细分析并消除问题原因，以提供持久和准确的缺陷消除（见注释）。

BP6：必要时发出警报通知。 如果问题属于高级别问题并影响其他系统或用户，则可能需要发出警报通知，等待修复或更改。

注：在发出警报通知后，应根据 BP2 建立问题解决管理程序，并根据 BP3、BP4、BP7 和 BP8 推进。

必须立即通知客户、用户、最终客户、其他项目和其他受影响的各方。 这尤其适用于产品包含严重缺陷或使用它会带来严重危险的情况（另请参见 BP5）。 这样应该可以防止任何可能的损坏。 相应的行动方案记录在问题解决管理策略中。

BP7：发起变更请求。 对诊断出的问题发起变更请求。

注意：变更请求的实施在 SUP.10 变更请求管理流程中完成。

如果一个问题可以归因于缺陷，并且如果已经决定移除它，那么必须启动移除它的行动。 缺陷消除是在 SUP.10 过程的上下文中完成的（如果已实施），并以一个或多个变更请求的形式传递给它。 通常在整个工作产品范围（例如，代码、设计文 档、测试文档）中进行更改，甚至可能在过程和工作流中进行更改。

BP8：跟踪问题直至关闭。 跟踪所有报告问题的状态直至关闭。 在关闭之前，必须授权正式验收。

必须仔细记录问题和问题状态。 必须发现在特定状态下停留时间过长的问题（例如，分析时间过长），不能丢失或遗忘问题，并且必须保证遵守承诺的完成日期（例如，分配给某个特定对象） 发布）。 如果个人或团体（项目经理、变更经理、变更请求委员会（参见 SUP.10 BP6））具有监督能力并且定期讨论状态（例如，在项目会议期间），这将很有帮助。 适当的工具支持也非常有用，例如，以具有配置管理系统接口的变更管理系统的形式。 这样的系统通常有一个工作流组件，可以向个人分配任务并自动管理状态转换。 在大多数情况下，它们还支持统计状态评估，以便可以使用图表随时间跟踪当前状态和问题解决方案。 图 2–18 提供了一个示例。

图 2–18 随时间推移跟踪问题和解决方案的示例

在最终解决问题之前，应获得授权人员的正式批准（关于这一点，另请参阅 SUP.10 BP.11）。 审核结果记录在案。

BP9：分析问题趋势。 从问题管理系统（发生、检测、影响范围等）收集和分析数据，确定趋势并在必要时采取行动。

优良作法是在不同级别（例如，在产品、过程、项目和组织级别）收集有关问题状态和解决方案进度的数据，以便识别与问题和缺陷相关的趋势。

个人和组织从问题和失败中学习。 系统地消除缺陷源为降低成本和提高质量开辟了可能性。 这可能会导致流程的改变和增强、更好的工具支持和改进的指南，或者经过专门培训的员工在问题处理方面的表现。 SUP.9 过程提供了一个极好的数据源，可以在过程改进过程 (PIM.3) 的背景下对其进行评估。 这尤其适用于关于缺陷类别、缺陷注入时间和受影响的产品部件的统计评估。

2.17.4 指定工作产品

08-27 问题管理计划

问题管理计划定义并描述了从识别、记录、描述和分类到解决的问题解决活动。 它还包含评估和消除问题的要求和标准。 此外，它还描述了问题解决活动的跟踪机制以及解决方案和方法的收集和分发。 在实践中，这些事情通常在组织级别的过程描述中进行规定，并可能由特定于项目的承诺进行补充。

13-07 问题记录

问题记录包含与问题有关的所有描述性和相关信息。 就个别问题而言，问题记录包含以下内容：

1. 问题记录作者
2. 问题描述
3. 问题分类（例如，关键性、紧迫性）
4. 解决的目标截止日期
5. 决议成功的验证措施

实际上，术语问题记录使用不同的名称（例如，测试事件报告、故障单等）。 通常可以使用可用的变更管理工具记录问题。 问题记录作为后续更改的输入信息，因此是 SUP.10 过程的重要输入。 重要的是，当前状态和负责人的分配是可见的。 该工作产品与变更请求 WP-ID 13-16 密切相关。 实际上，用于问题记录和变更请求的文档模板通常是相同的。 BP3 描述了问题描述中的内容。

15-01 分析报告或 15-05 评估报告

分析或评估报告记录问题分析或相应评估的结果。 重要的是要知道是谁在什么时间进行了分析或评估，结果如何。 必须充分记录分析或评估的结果。 评估报告通常是问题记录的一部分，并保存在一个单独的部分（如果适用，在数据库中）。

15-12 问题状态报告

问题状态报告包含有关当前问题及其状态的摘要信息。 这种报告形式非常适合对缺陷分类、不同状态的问题数量、问题频率、解决速度、特定状态的滞后时间、客户反馈等进行统计评估。

2.17.5  2级特性

随后的审议也参考了 SUP.10 变更管理。

论绩效管理

问题解决管理和变更管理都特别适合证明流程和工作产品的管理和控制，以及将其对外进行规划。 由于外部客户是许多问题报告和变更说明的幕后推手，这使开发组织有机会表明客户请求被视为他们正在进行的活动的重要组成部分，并且这些请求得到妥善处理并系统地完成。 在实践中，通过度量跟踪缺陷/问题和变化已被证明是有用的（例如，识别特定状态下问题的滞后时间），尽管在 2 级，这在 Automotive SPICE 中没有明确要求。

各个处理步骤不是在项目级别计划的，而是由任务分配给的个人计划和跟踪的。 此人全权负责分配给他的活动。 在项目级别，安排项目会议（期间讨论问题管理问题）。

定期跟踪各个问题（问题/缺陷和变更）的完成状态（例如，在每周会议中）。 如果发现无法达到既定目标，则启动有充分证据的反制措施。 例如，如果无法保留为特定交付计划的问题消除，则必须为该任务提供额外的资源。 这可以通过外包给外部服务提供商来实现。

如果发生变化，时间表会相应调整。 问题消除的状态（例如，项目中的缺陷数量）会定期分发并传达给受影响的个人，同时——尤其是——传达给外部客户。

论工作产品管理

Process Attribute PA 2.2 的要求，例如，指定问题报告的布局，问题输入掩码的哪些字段必须以何种方式完成，哪些要求文档必须满足，以及如何将此信息和其他相关信息 传达。 这样就建立了一个系统，允许项目团队的各个成员轻松访问他们日常工作所需的信息（例如，问题数据库或 LOI 数据库）。 工作产品通过对其状态的定期讨论和评估来控制（例如，在团队会议中）。 可以提供已完成的证明。 识别出各个问题之间的相互依赖性，并可能确定解决这些问题的顺序。 例如，导致功能需求、体系结构、软件设计等发生变化的问题报告就是如此。 相关信息和文件明确分配给一个问题。 定期审查报告的问题（例如，问题列表）。