ALM管理系统的基线，不是打一个版本号那么简单

版本号从V1.0走到V1.3，团队以为基线建好了。真正出事时，却没人说得清：当时批准了哪些需求，哪些用例覆盖了它们，哪次改动经过了谁同意。这样的基线，只是一个标签。

ALM管理系统管理应用从需求、设计、开发、测试到发布、维护的整条生命周期。它不是把项目管理、需求和测试堆在一起，而是让对象形成可追溯关系。基线是在特定时间点把一组配置项及其关系固定下来，经正式评审和批准，后续变更只能走正式变更控制。版本号回答这是第几版，基线回答这一版凭什么算数、改了影响谁、出问题能回到哪里。

一、先厘清概念：基线到底基在哪里

1. 国家标准给出的直接定义

GB/T11457-2006《信息技术 软件工程 术语》把基线定义为：经过正式审核与同意，可用作下一步开发的基础，并且只有通过正式修改管理步骤才能修改的规格说明或产品。正式评审、批准、受控变更，缺一不可。

2. 版本号与基线的四个差别

两者放在一起看，差别在管理强度。

版本号是基线的入口，不是全部。没有范围、关系和审批记录，团队拿到的只是一个编号。

3. 为什么只打版本号会失效

只打版本号，常见后果有三种：回溯时找不到完整配置，只能凭记忆拼；需求变更后，用例和发布说明没同步，交付与批准内容脱节；审计时拿不出评审和变更记录。配置基线的价值不在于存过，而在于证得清。完善文档管理和对象关联，比多打几个版本号更有意义。

二、ALM管理系统里的基线，至少要管住五件事

在应用生命周期里，基线跨过需求、开发、测试和发布多个环节。要真正可用，至少管住五个控制面。

1. 管住范围：哪些配置项进入基线

不是所有文件都要进基线，但影响交付、验证和追溯的配置项必须进，包括需求条目、设计说明、代码构建、测试用例、发布说明和环境配置。范围要在建基线前写清，需求池里的条目和状态也应明确。

2. 管住版本：每个配置项只取一个确定版本

基线不是最新版的集合，而是每个配置项各取一个确定版本。同一基线内不允许最新这类模糊指向，否则不同角色看到的可能不是同一个东西。版本管理不能只追编号，还要追受控状态。

3. 管住关系：需求、任务、用例、Bug、构建之间能互相找到

基线要保存对象关系：需求由哪个任务实现，被哪些测试用例验证，关联哪些Bug，进入哪个构建。关系完整，影响分析才有依据；关系缺失，基线就只剩一份文件清单。

4. 管住权限：谁提议、谁批准、谁发布

基线不是谁都能改的共享文件夹。提议、评估、批准、发布应由不同角色承担。配置控制委员会的价值，是让变更决策有明确责任主体。

5. 管住证据：评审、变更、审计记录能还原过程

评审记录说明基线为何被批准，变更记录说明改了什么，审计记录说明实际状态与批准状态是否一致。三者齐全，基线才可审计。

图1：范围、版本、关系、权限、证据，构成基线的五个控制面。

三、三种基线不是三个版本，而是三层管理基准

配置管理语境下，常把基线分为功能基线、分配基线和产品基线。它们对应不同管理问题，不是同一个版本改三次名字。

1. 功能基线：锁定系统要做什么

功能基线通常形成于系统分析与定义阶段结束，核心是经批准的系统规格说明。它回答功能、接口和验证要求，是后续分配与实现的源头。

2. 分配基线：锁定需求如何落到子系统

分配基线通常形成于需求分析阶段结束，把上层需求分配到产品、子系统或组件，并明确接口和验证要求。它让做什么变成由谁做、做到什么程度。

3. 产品基线：锁定最终交付物是什么

产品基线通常形成于组装与系统测试阶段结束，描述可交付产品的全部配置项及规格。它既是发布依据，也是后续维护的参照。

在ALM管理系统里，还会听到需求基线、测试基线、发布基线等说法。它们是面向不同对象的基线视图，通常不能替代功能、分配、产品三类配置基线。需求基线看需求条目与状态，测试基线看用例与验证证据，发布基线看构建与说明；彼此要能追溯。

图2：三类基线逐级细化，上层基线约束下层，下层基线细化上层。

四、基线不是一次性动作，而是一条闭环

1. 建之前：先定基线策略

先回答五个问题：建哪类基线、什么时候建、哪些配置项进入、谁批准、命名和存放规则是什么。策略不清，基线就会变成临时打标签。

2. 建之时：评审、批准、冻结、发布

基线建立至少包含评审、批准、冻结和发布四个动作。冻结不是永久不动，而是未经批准不得改变；发布是让相关角色拿到同一个确定状态。

3. 建之后：变更控制与影响分析

变更请求进入变更流程后，先做影响分析：影响哪些需求、任务、用例、构建和发布。批准后实施、验证，再形成新基线。基线不是禁止变化，而是让变化有迹可循。

4. 定期审计：功能配置审计与物理配置审计

功能配置审计检查配置项是否满足需求，物理配置审计检查实际交付物与记录是否一致，审计结论可在基线状态报告中汇总。没有审计，基线只能证明曾经记录过，不能证明现在仍一致。

5. 归档与回溯：能还原历史状态

基线记录、变更记录和发布记录要按规定保留。回溯时能还原当时的配置项、版本、关系和审批链，才算具备可回退能力。

图3：定策略、评审冻结、变更控制、配置审计、归档回溯，五个动作首尾相接。

五、落地时最容易踩的五个坑

1. 把最新版本当基线

最新版本会继续变化，基线必须指向确定版本。建立时写明版本号或唯一标识，不用最新、当前这类相对词。

2. 基线范围过大或过小

范围过大，维护成本高、变更频繁；范围过小，关键对象漏管。以影响交付和验证为边界，先覆盖关键项，再扩展。

3. 有基线，没有追溯关系

只归档文件，不记录需求、用例、构建之间的关联，变更时仍只能靠人问。基线要能回答问题，而不只是保存文件。

4. 变更不走评审，事后补记录

先改后补，会把基线变成历史台账。变更请求、影响分析、批准记录应在实施前完成，至少要在发布前闭环。

5. 只建基线，不做审计

基线建立后长期不检查，实际状态与记录会逐渐分离。把基线审计纳入发布前检查，比事后追责更有效。

六、常见问题：三个容易被忽略的疑问

1. 敏捷团队还需要基线吗？

需要，但可以更轻。按迭代或发布建立小范围基线，保留需求、用例、构建和发布说明的对应关系即可。基线是参照点，不是一次性冻结。

2. 基线应该多久建一次？

按事件触发，而不是只按日历。需求批准、版本发布、重大变更完成后，都是常见触发点。频率过高增加成本，过低失去参照意义。

3. 基线一定要包含代码吗？

不一定。功能基线以系统规格为主，分配基线以分配需求为主，产品基线才覆盖可交付配置项。是否包含代码，取决于基线类型和交付要求；关键不是把所有文件都塞进去，而是让进入基线的对象可追溯、可验证。

回到标题：ALM管理系统的基线，不是打一个版本号那么简单。它是配置项在特定时间点的受控状态，包含范围、版本、关系、权限和证据五个控制面，并通过评审、变更、审计形成闭环。

如果团队正准备建设或优化ALM管理系统，不妨先从一条产品线开始：选一个发布节点，写清基线范围，补齐需求到测试的追溯关系，做一次基线审计。当团队能说清这一版凭什么算数，基线才真正开始发挥作用。