IBM Engineering Lifecycle Management在什么情况下需要使用 Lifecycle Query Engine 功能？

最新推荐文章于 2025-10-22 10:18:57 发布

原创最新推荐文章于 2025-10-22 10:18:57 发布 · 729 阅读

CC 4.0 BY-SA版权

文章标签：

IBM Engineering Lifecycle Management（ELM）中的 Lifecycle Query Engine（LQE） 是一个强大的报告和数据分析组件。它的存在不是为了完成日常的核心工作流（如创建需求、缺陷或测试用例），而是为了在复杂项目中提供跨学科、跨工具、跨项目的洞察力。

简单来说，当基本的查找和过滤功能无法满足你的信息需求时，就是需要使用 LQE 的时候。

以下是需要使用 Lifecycle Query Engine 的典型情况和场景：

1. 需要进行跨学科/跨工具的联合查询时

这是 LQE 最核心的价值所在。ELM 套件包含多个工具（如 DOORS Next 用于需求，ETM 用于测试，ECC/RTC 用于开发和缺陷管理）。这些工具中的数据是相互关联的。

场景举例：

查询：“找出所有被标记为‘高优先级’且关联的测试用例执行‘失败’的需求。”
- 为什么需要 LQE： 需求在 DOORS Next 中，测试结果在 ETM 中。没有 LQE，你需要在两个工具中手动交叉核对，效率极低且容易出错。LQE 可以无缝地从一个工具（需求）查询到另一个工具（测试结果）。
查询：“显示所有由‘模块X’中发现的严重缺陷所阻塞的测试用例。”
- 为什么需要 LQE： 缺陷在 RTC 中，测试用例在 ETM 中，模块信息可能在 EWM 中。LQE 可以建立这种复杂的关联。

2. 需要创建复杂的、自定义的报告和仪表盘时

当项目干系人（如项目经理、架构师、质量负责人）需要一目了然地了解项目健康状况时，简单的列表无法满足要求。

场景举例：

创建项目经理仪表盘： 在一个视图中集中展示需求覆盖率、缺陷趋势图、测试通过率、关键质量指标。
创建质量保证仪表盘： 跟踪缺陷密度、按组件分类的缺陷分布、回归测试的稳定性。
生成合规性报告： 对于安全关键行业（如汽车、航空、医疗），需要证明每个需求都已被验证和确认。LQE 可以生成包含需求、测试用例、测试结果和缺陷跟踪的完整追溯性报告。

3. 需要执行影响分析和根源分析时

当系统发生变更或出现问题时，需要快速评估影响范围或找到根本原因。

场景举例：

影响分析：“如果这个需求发生变更，会影响到哪些设计文档、测试用例和代码模块？”
- 为什么需要 LQE： LQE 可以逆向追踪链接，清晰地展示出变更的“涟漪效应”，帮助团队评估变更成本和工作量。
根源分析：“这个测试用例为什么一直失败？”
- 为什么需要 LQE： 你可以通过 LQE 追溯与该测试用例相关的所有工件——它验证的需求、它运行的测试环境、关联的缺陷记录等，从而快速定位问题根源（例如，是由于一个特定的代码缺陷，还是需求本身不清晰）。

4. 项目规模庞大且复杂时

在小型项目中，团队成员可能通过记忆和简单的沟通来管理信息。但在大型复杂系统（如汽车、航空航天系统）开发中：

工件数量可能达到成千上万个。
团队分布在全球各地。
系统层级很深（系统-子系统-组件）。

场景举例：

系统架构师需要确保顶层系统需求已经正确地分配并落实到各个子系统的设计和实现中。LQE 提供的全局视图和报告是唯一高效的方式。

5. 需要审计和合规性证明时

在受监管的行业中，开发过程必须符合特定标准（如 ISO 26262, DO-178C, IEC 62304）。审计人员需要看到客观证据。

场景举例：

向审计员展示： “请证明所有安全需求都经过了100%的测试，并且所有未通过的测试都已关联到缺陷并进行跟踪。”
- 为什么需要 LQE： LQE 可以生成标准化的、基于事实的（而非人工整理的）报告，直接满足审计要求，极大地减少了审计准备的工作量。

LQE 与工具内建查询的对比

为了更清晰地理解，可以做一个对比：

特性	工具内建查询（如 RTC 工作项查询）	Lifecycle Query Engine (LQE)
范围	单个工具内（如只查 RTC 中的缺陷）	跨整个 ELM 套件（DOORS Next, ETM, RTC/EWM）
复杂性	相对简单，基于工作项的属性和简单链接	高度复杂，可以处理复杂的链接关系和条件
输出形式	主要是列表	列表、图表（饼图、柱状图、趋势线）、仪表盘
主要用户	开发人员、测试人员（日常任务）	项目经理、架构师、质量工程师、流程负责人（分析和决策）
目的	执行日常任务	分析、监控、报告和决策