织梦网站需要付费吗,国外网站如何做seo,东莞的网站建设,魅族的网站建设与安全追溯性是指跟踪需求与其他工件#xff08;从测试用例到更高级别的系统或子系统需求#xff09;之间的上游和下游关系的能力。通过端到端的追溯性#xff0c;团队可以查看产品的开发过程是否当前处于正轨#xff0c;以及查看与其相关的所有历史和背景。
至少#xff0c;这…追溯性是指跟踪需求与其他工件从测试用例到更高级别的系统或子系统需求之间的上游和下游关系的能力。通过端到端的追溯性团队可以查看产品的开发过程是否当前处于正轨以及查看与其相关的所有历史和背景。
至少这是理想状态。
一、端到端的可追溯性所带来的益处
让我们看看使用像 PingCode 这样的解决方案实施端到端追溯性的四个主要好处。
1.需求信息透明和利益相关者可随时查看信息
追溯性其核心是关于各种关系的管理这些关系不仅包括需求与其他项目元素例如测试用例或更高级别的系统或子系统需求之间的关系还包括所有这些元素与负责管理这些元素的人员之间的关系。
通过实现端到端的追溯性团队能够清晰地看到以下几个方面
需求如何向前追溯到实际产品中即明确了解需求如何被转化为产品的功能同时也可以看到这些功能是如何反向追溯到原始的需求和设计的也就是说可以明确每个功能背后的原始需求和设计。所有需求是如何进行测试的也就是说可以查看与每个需求相关的测试用例了解这些测试用例是成功还是失败以及在测试过程中识别出的任何相关的问题或缺陷。能明确了解哪些人参与了特定需求和测试运行的开发并且这些人可以及时被通知关于下一步需要进行的工作或者需要采取的行动。这样能确保团队成员对项目进度的清晰了解以及对需求变更的及时响应。
这种全面的可视化提供了一个活动系统团队可以利用它来追踪每个工作元素的生命周期并启动适当的行动来维护产品开发的进度并确保需求得到完整的覆盖。例如团队可以使用这个系统来判断一个医疗设备是否安全使用它是否符合相关的标准以及在审计过程中用于开发这个设备的流程是否能够站得住脚。一个全面的追溯性解决方案能为这些问题以及其他相关问题提供明确的答案。
2.更好的变更影响分析
如果没有端到端的追溯性就无法进行真正有效的影响分析。影响分析的本质在于能够清楚地看到对某个元素的特定改动会对与它相关的其他元素产生怎样的影响。要做到这一点就需要依赖追溯性。
在传统的基于文件的工作流程中了解各个项目如何受到改变影响可能会非常困难。但在拥有端到端追溯性的平台上这项工作大部分都是自动完成的并成为你日常工作的一部分。这种解决方案会立即标记那些因为改动而可能出现问题的下游链接以便团队根据需要处理它们。
比如团队可以实时查看一个需求的改动是否影响到了下游的测试用例以及这些测试用例中有多少已经通过。这种设置比手动处理更能节省时间和精力。
3.更容易识别测试覆盖率中的缺口
当我们讨论测试时一个需求通常只有当有针对性的测试用例对其进行测试并且已经有测试工程师被分配进行这项工作时才会被认为是“被覆盖”。然而覆盖范围的缺口往往只有在事后才会暴露出来比如当一个产品的问题揭示出我们在开发过程中是如何忽视了一个关键缺陷的。
在变化和创新速度很快的领域如医疗设备开发和汽车制造任何未识别的覆盖范围的缺口都会对最终用户带来风险并且修复成本高昂。在具有端到端追溯性的平台上改进测试覆盖范围的追踪可以帮助消除这些盲点确保质量。
更具体地说这种具有追溯性的需求管理解决方案有助于测试工程师和项目经理能够看清哪些地方存在缺口以及测试是否已经得到批准、完成、拒绝或起草。结果产品开发的整体风险会降低。
3.简化审计过程、提高准确性
“显示你的工作”对于任何完成过数学作业的人来说都是一个熟悉的要求在追踪需求的过程中这个要求同样非常关键。当接受审计时你需要提供关于这些需求的具体信息并按照审查者和监管者的要求进行格式化。
像 PingCode 这样的平台可以简化这个过程它让团队可以清晰地展示他们全面追溯性的支持证据。它提供像追溯报告这样的导出模板来展示这些证据从而简化了监管提交和审计的过程。
二、可追溯性的局限及其解决方法
传统上追溯性是通过使用包括 Microsoft Word 和 Excel 在内的应用程序进行的基于文档的工作流程来实现的。团队成员会在文本文档或电子表格中创建一个追溯性矩阵并在产品开发生命周期中手动更新它。遗憾的是这种方法有明显的局限性而且很容易出错。
当团队在离散的和静态的文档中追踪需求时他们往往会给自己增加额外的工作量同时还可能会遗漏关键的更新或出现错误。
假设有人在Excel中更新了一个矩阵这个矩阵包含了一个正在开发的医疗设备相关的测试用例的最新状态。表面上进展顺利实际上可能存在以下问题
1.人为失误
由于所有的操作都是手动完成的所以这个人必须定期重新检查这个矩阵以确保它能够与整个组织的产品开发活动保持同步和更新。问题在于追溯性矩阵的复杂性包含了多个表格这些表格显示了需求和测试用例是如何相互关联的使得这项工作本质上非常复杂并且容易出错。
2.电子邮件中心化的协作
同时这些对矩阵的更新主要通过电子邮件进行沟通。考虑到每个人收件箱中的常规信息流动人们离开办公室以及其他复杂的情况比如糟糕的版本控制和处理每个人评论的不恰当方式这可能会导致错误和误解需要后续的重新工作来修正。
3.无法自动生成合规文件
最后即使一切都按照计划进行也不能保证所使用的追溯性工作流程能涵盖所有相关的需求和风险。例如在医疗设备开发的场景下通过 Excel 创建的矩阵并不会具备符合行业标准如ISO 14971的框架这使得保证协同追溯性以及确保合规性证明的成功变得更加困难。
幸运的是这些问题并不需要阻碍你的团队也不必让你的产品开发流程承担不必要的风险。通过从面向文档的工作流程升级到一个全面的需求管理平台你可以实现端到端的追溯性这个平台支持实时协作双向追溯性以及风险管理的集成。
需求管理 需求管理指南
需求管理 需求管理主要内容 | 需求管理的重要性 | 采用敏捷方法进行需求管理 | 如何克服需求管理的 5 大挑战 | 更多
需求编写 功能需求的示例和模板 | 采用 EARS 方法来改进需求工程 | 如何编写一份优秀的产品需求文档PRD | 功能性需求与非功能性需求的区别 | 有效需求的特征 | 更多
需求收集和管理流程 需求工程概述 | 产品团队的需求分析指南 | 敏捷产品团队的 11 种需求收集技巧 | 定义和实施需求基线 | 更多 需求的可追溯性 什么是需求可追溯性 | 可追溯性在现代产品和系统开发中的关键作用 | 如何创建和使用需求追溯矩阵 | 更多
需求确认和验证 产品团队的需求验证和确认 | 更多
