IBM Rational DOORS怎么做基线，IBM Rational DOORS基线与版本如何管理，很多团队不是不会用DOORS，而是把“基线”“版本”“变更”“交付”当成四件互不相关的事：有人在模块里随手点一次Baseline就算完成，有人在发版前才临时复制模块当备份，还有人靠邮件和表格记版本号，最后一到追溯就对不上。

　　一、‌IBM Rational DOORS怎么做基线

　　在IBM Rational DOORS里做基线，不是“点一下就结束”，而是一次可追溯的冻结动作：冻结的对象是什么、冻结前是否允许继续编辑、冻结后如何对比差异、出现问题如何回到指定状态，这些都要在基线创建前先想清楚，否则基线会越做越多但越用越乱。

　　1、基线前先把模块口径收敛到可冻结状态

　　（1）先确认要做基线的是哪个模块与哪个视图范围，尤其是属性列、过滤条件、对象层级是否已按评审口径整理好，避免把临时筛选当成最终交付口径；

　　（2）把本轮需要纳入基线的对象状态统一，后续做基线对比时才不会把“状态没填”误判为“需求变更”；

　　（3）对链接关系做一次快速自检，重点看上游下游链接是否缺失、是否存在明显的悬空对象，基线更像“定格镜头”，镜头里如果本来就脏，后面只会更难擦。

　　2、在模块层面创建基线并把信息写完整

　　（1）在模块打开状态下进入基线相关功能入口，新建基线时不要只写“V1”“备份”，而要写清基线用途与范围，让IBM Rational DOORS基线在列表里一眼可检索；

　　（2）基线描述里至少包含三类信息：对应的评审节点或迭代号、冻结人或责任角色、冻结前最后一次变更的时间点或变更单号，这些信息能显着降低后续追溯成本；

　　（3）如果团队有权限管理要求，基线创建后要确认基线对象是否对指定角色可见，并同步约定基线后是否允许继续在当前模块上编辑。

　　3、用对比与查看把基线从“存档”变成“可用证据”

　　（1）基线创建完成后，立刻做一次与当前模块的差异检查，确认新增、删除、修改三类变化是否符合预期，尤其关注属性字段变化与对象层级移动，这类变化最容易在后期造成争议；

　　（2）把常用的对比输出方式固定下来，例如只看正文、只看关键属性、只看链接差异；

　　（3）当需要引用基线作为评审证据时，优先用基线视图打开进行核对，而不是把当前模块“假装没改过”，这样才能把“当时评审的是哪一版”说清楚。

　　4、跨多个模块时优先用Baseline Set统一时间点

　　（1）当一个交付包含多个相互链接的模块时，建议用Baseline Set在同一时间点对多个模块一起做冻结；

　　（2）Baseline Set更适合做里程碑型冻结，例如阶段评审、版本发布、外部交付，因为它强调“多个模块同一时刻的整体快照”；

　　（3）如果团队经常做跨模块追溯，把Baseline Set作为默认动作会更稳，因为它能让相关数据在同一冻结点被一起查看与复核。

　　二、IBM Rational DOORS基线与版本如何管理

　　IBM Rational DOORS里“基线”更像可追溯的冻结点，“版本管理”更像一套长期规则：怎么命名、怎么分层、怎么授权、怎么留档、怎么回滚。

　　1、用命名规则把基线变成可检索资产

　　（1）统一基线命名结构，建议包含“对象范围+节点+版本号”三段，让DOORS基线列表可按节点快速筛；

　　（2）把“临时基线”和“交付基线”在命名上区分开，例如临时基线加TEMP或DEV标识，交付基线加REL或DELIVER标识；

　　（3）对Baseline Set同样做命名统一，建议把包含的模块范围写进描述里，例如“系统需求+软件需求+接口需求_交付冻结”，否则Baseline Set久了也会变成一串看不懂的条目。

　　2、把基线频率与变更节奏绑定，避免无效堆叠

　　（1）以评审节点为主线做基线：需求评审、设计评审、版本发布、外部交付，这些节点做基线价值最高；

　　（2）日常小改动不要每改一次就做基线，改动应先落在变更单或评审记录里，等到需要冻结证据时再做基线；

　　（3）对高风险模块可以提高冻结密度，例如法规强约束、接口强依赖的模块，可以在关键变更前后各冻结一次，但也要明确触发条件，不能靠个人感觉。

　　3、用权限与流程把“谁能改、谁能冻、谁能发”分开

　　（1）把模块编辑权限与基线创建权限分离：编辑者负责内容变更，配置管理员或负责人负责冻结与发布，能显着减少“基线刚做完就被改”的问题；

　　（2）把“冻结前检查”写成清单并固化执行，例如状态字段齐全、关键链接完整、未解决问题已记录，这类检查比事后追责更有效；

　　（3）对外部交付基线建议加审批动作，例如冻结后由评审负责人确认，再允许导出或共享。

　　4、把对比、回滚、导出三件事做成固定口径

　　（1）对比口径固定：同一类交付只用同一套对比维度，例如只看正文与关键属性、只看链接差异与对象结构；

　　（2）回滚口径固定：明确“回滚到基线”是为了查看历史还是为了恢复工作基线，如果是恢复工作，必须同步处理后续变更如何重新合并；

　　（3）导出口径固定：每次导出都记录模板、过滤条件、入口模块或Baseline Set名称，让“导出的文档”与“基线冻结点”可一一对应。

　　5、如果你用的是DOORS Next Generation要先弄清基线粒度

　　（1）有些团队同时使用DOORS Classic与DOORS Next Generation时，会把两者的基线概念混用；

　　（2）在DOORS Next Generation里，基线通常以组件为粒度，回到某个基线往往影响范围更大，因此在设计版本策略时要更强调组件边界与模块划分；

　　（3）选型或并行使用时，先把粒度差异说清楚。

　　三、IBM Rational DOORS基线策略怎么和评审发布打通

　　只在IBM Rational DOORS里“会做基线”还不够，真正决定体系能不能长期稳定的，是把基线与评审、变更、发布三条线连起来：评审在基线上做结论，变更在基线后有记录，发布从基线或Baseline Set导出交付物。

　　1、评审顺序固定为“当前工作版确认→基线冻结→基线版评审”

　　（1）评审前先在当前工作版确认范围与入口模块，确保大家看的就是同一批内容；

　　（2）确认无误后创建基线或Baseline Set，把评审对象冻结下来，再进入评审会议或线上审阅；

　　（3）评审结论、问题单、变更单号写回到基线描述或评审记录中，形成“评审结论绑定冻结点”的证据链。

　　2、发布动作固定为“基线导出+版本号登记+交付包留档”

　　（1）发布时只允许从指定基线或Baseline Set导出，不允许从当前工作版随手导出，避免把未冻结内容混入交付；

　　（2）版本号登记要与基线命名一致，建议在发布记录里写清基线名称、导出时间、导出模板与过滤条件，保证可复现；

　　（3）交付包留档建议包含导出文档、关键截图或对比摘要、基线清单，后续追溯时可以不打开DOORS也能先定位到正确版本。

　　总结

　　IBM Rational DOORS怎么做基线IBM Rational DOORS基线与版本如何管理，落地时抓住一条主线就够了：模块基线把单模块冻结点做扎实，Baseline Set把跨模块同一时间点的快照做统一，再用命名、权限、对比、导出把基线变成可检索、可复现、可交付的资产。