现今的开发环境正不断呈现出以下特征：软件开发与测试组织遍布全球、应用程序涉及更多利益相关者、复杂性不断加剧，且监管与审核限制灵活多变。正如 Butler 集团 2005 年度 ALM 总结报告中说的那样，需求变更是开发人员面临的最大难题，很少有一个项目能从头到尾保持同样的需求。而且据有关权威机构证明："最终发行版本仅反映最初所分配需求的 52%" ;"如果在需求收集阶段修复一个所发现的缺陷需花费 1 美元，则在设计阶段修复该缺陷需花费 2 美元，那么直至产品投入使用后才发现该缺陷，则修复所需的费用将暴涨至 69 美元"。种种数据表明测量和监控开发工作再不允许被忽视，闭环跟踪恰好为我们提供了软件开发生命周期的完全可见性，使利益相关者及其客户可以评估变更对系统所造成的影响，并报告和监控开发工作以确保不断得以改善。

　　闭环跟踪始于自上而下法

　　通常跟踪通过自上而下法得以实现，自上而下方法的核心是：保持对需求变更的控制，即确保正确管理和跟踪需求变更，以变更请求并最终变更软件代码。以这种方法执行流程时，需求和执行请求可与代码、文档及测试产品彼此相链接。在确保团队遵照最新决策和优先权开展工作的同时，开发活动与客户需求将自动进行关联以降低流程开销，从而显著提高生产率。在生命周期中尽早改善开发测试将减少软件错误，从而将不良影响降至最低。

　　自上而下跟踪报告示例

　　自上而下跟踪报告有助于经理和测试人员在变更贯穿的开发流程(即设计、代码、单元测试、集成测试和最终测试)中协调的分配、规划开发和监控状态。并且自上而下的跟踪是帮助实现持续合规(架构 - SOA/ITIL，或法规 - COBIT/FDA)的关键功能。自上而下方法：保持对需求变更的控制

　　管理需求变更的自上而下方法可分为三个方面：

　　1. 收集"客户反馈"，确保在整个开发生命周期中有效管理、审查并跟踪客户请求。对需求和客户请求进行跟踪使组织可以收集到原本经常会遗漏、草率处理或无法跟踪的"客户反馈"请求。跟踪提供了可行且可重复的流程，供所有利益相关者进行初步需求收集与分析。

　　需求收集：客户反馈

　　这种跟踪还可从内部团队收集"创新灵感"。由于团队遵循标准的批准流程来确保有效分析，因此组织可避免请求遗漏或沟通中断的情况。这种跟踪最终使组织实现了"客户至上"。

　　2. 需求工作流程管理，通过灵活和可重复流程来保持对需求变更的跟踪

　　项目一旦启动，团队就需要准备好处理变更、频繁的源错误和返工情况。团队需记录和管理系统及业务变更请求，以及影响所有项目产品(而不仅限于源代码)的变更，该流程可扩展到包括其它负责提交和管理缺陷或请求的传统团队。

　　示例：需求变更工作流程

　　当变更对商定的需求及规范基线(项目的基础)造成影响时，采用具有一致性和集成性的方法至关重要。需求工作流程管理为负责需求和规范的分析人员引入变更管理，提供了灵活、一致且可重复的流程来管理需求变更及其可跟踪链接。这种首选方法使分析人员只需指明其正在处理的需求变更请求，提交的所有变更即会自动得以跟踪、打包并链接到需求变更请求。然后，审查与批准团队将获悉所建议的变更，并着眼于整个组织查看规范与变更的状况。

　　3. 需求执行，确保需求变更在最终产品中得以执行

　　通过采取自上而下的方法来确保需求变更在最终解决方案中得以执行，分析人员或领导会根据需求、案例详情、使用案例或规范要素创建执行请求。随即，执行任务将出现在开发团队的工作列表中，显示关键属性(优先权、期限等)和业务数据。自动建立需求与相关开发活动之间的关联并实现实时可见性，有助于项目经理简化开发流程并监控项目进展。

　　S/W 需求执行请求的自上而下跟踪报告采用自下而上的方法

　　文章开头我们已经提过，自上而下的方法始终存在着它自身的不足之处，它无法验证预期的需求、缺陷或请求是否已在发布的产品中得以积极妥善地处理。而且只采用自上而下法常导致开发人员仍在依据错误版本的规范工作，并且对背景和业务价值不甚明了。自下而上的跟踪方法可以通过关闭验证循环来从根本上解决这个问题。并且可以有效的需求驱动开发流程来控制变更的执行，跟踪每个开发任务以及受影响对象至原始客户需要、需求或变更请求。不仅使开发团队能确保其配置的完整性，还使测试与质量保证工程师能确保交付的代码符合批准的需求。

　　自下而上方法与自上而下方法的不同之处在于，验证人员(开发人员、测试人员和团队领导)要求 CM系统验证从文件变更回溯到需求的跟踪，而不是简单地信任 CM 系统。

　　采用自下而上的跟踪方法，可以检验每个构建与测试阶段(如单元测试或集成测试)以验证内部版本的完整性。它存在于渐进测试的每个阶段，使团队可以确保是否满足了需求。这与迭代开发流程和依靠流程早期演示功能的测试驱动开发环境(其中，进行必要变更的成本非常低)紧密结合。

　　支持自下而上方法的配置管理系统允许任何团队成员从某内部版本产品的代码库开始追溯产生变更的需求。跨开发生命周期移动文件，同时监控文件相关变更请求和用途以探测文件和相关活动(与变更请求相链接)之间冲突的能力，不仅在开发环境中而且在构建管理与 QA 过程中均有助于产生稳定的开发迭代。

　　自下而上跟踪的基线比较

　　闭环跟踪的自身优势

　　自下而上跟踪根据原始需求跟踪测试，从而确保最终产品中满足了需求。自下而上跟踪可实现覆盖分析，以确保每个需求或缺陷至少对应一个计划的措施并最终得以执行;或每个应对措施都具有相关需求并能使需求受益。在开发过程中最难做出的判断之一是确定完成充分测试的时间。质量保证工程师主要关注测试，大部分测试人员的工作都通过测试应用程序执行。通过进行相应跟踪，每个测试的相对重要性以及测试的成败都可以追溯至相关需求。自下而上方法帮助测试人员在开发早期就找出错误，此时修复成本尚不至于很高。这显著增加了测试和产品管理团队之间的交流从而减少了风险，最终确保按计划实现功能。

　　通过自上而下和自下而上两种方法，利益相关者无疑可以轻松地在整个产品工作流程中保持对需求变更和变更请求的跟踪。

　　闭环跟踪管理方法

　　但是，要有效地监控和管理对应用程序所作的变更，利益相关者还必须能够访问自下而上的活动报告，比如：

　　• 执行报告(提供重点开发的闭环跟踪)

　　• 带功能列表的构建和基线(使测试人员和 QA 与快节奏开发保持一致)

　　• 自动生成的发行说明(详述每次交付产品中的功能和错误修复)

　　• 提供给文档人员的自动变更通知(节省了验证从客户到审核者等各方合规情况的时间)

　　上述这些跟踪报告有助于最佳实践的实施，而且相关建议在创建跨开发生命周期的可见性和可预测性方面起着重要作用。

　　提高开发环境中的可见性对于大多数流程改进方案(如 CMMI、SPICE 和 ISO)都是一个十分关键的因素。如果分析人员、开发人员和测试人员能保持完全同步，则开发就能获得持续竞争的优势。