一旦需求发生了修改,跟它关联在一起的那些设计说明、测试用例,还有下游的需求,就不一定还能原样成立了。DOORS会把受到牵连的对象标成“存在可疑链接”,用来提醒项目里的人重新去确认一下追溯关系。可疑状态并不等于链接本身就错了,也不代表应该马上把链接删掉,它只是在说,上游或者下游的对象已经变动过,需要重新去掂量一下影响的范围。
一、DOORS怎么做可疑链接检查
在做可疑链接检查的时候,比较建议的做法是从当前的模块开始,不要一上手就去扫描全部内容。先把变更所涉及的那些需求模块给打开,然后再分别去看一看它的入链和出链,这样要处理的范围就会清楚很多。
1、把带有可疑链接的对象筛出来
先打开目标模块,顺着菜单的【分析】→【可疑链接】→【筛选】点进去,再选择一下是要检查入链、出链,还是把两个方向的链接都查一遍。筛选完之后,页面上就只保留那些存在可疑状态的对象了,很适合拿来做集中的复核。
2、让可疑链接的标记显示出来
接下来,到【分析】→【可疑链接】→【显示指示器】里面去,挑好自己要查看的链接方向。系统会在模块里多出一个标记列,通过这列标记,就能把哪些对象带着可疑入链、哪些对象带着可疑出链,给区分开来。
3、看一看最近一次改动的内容
利用【分析】→【可疑链接】→【显示最近更改】这个功能,可以查看到底是哪一次修改触发了可疑状态。这时要重点核对的,是修改的时间、对象的编号,还有被改动的属性名称,然后自己来判断一下,这次改动是不是真的对关联的那些对象造成了影响。
4、有必要时把全部更改都展开
要是只靠最近那一次修改还说不清楚问题,那就可以再进到【分析】→【可疑链接】→【显示所有更改】里面去看看。DOORS会把相关的模块路径、对象编号、修改的次数、属性的名称,还有每次修改的时间,全都给列出来,这样就很方便去做接下来的影响分析了。
二、DOORS可疑链接太多怎么清理
当列表里面压着的可疑链接数量非常多的时候,可不要急急忙忙地就去点那个全部清除的按钮。最好先按照不同的模块、链接的方向,还有需求的层级,把它们拆开来处理,然后再来决定到底哪些状态是能够安全关掉的。
1、先处理那些因为核心需求改动而产生的可疑链接
比如说安全需求、系统级的需求、接口需求,还有测试验收的条件,这些应该优先去检查。因为这些种类的需求一旦变了,通常都会牵涉到很多下游的对象。至于那些一般性的文字修订、排版上的调整,还有额外补充的备注说明,都可以排在后面再慢慢清理。
2、逐条去核实链接是不是还有效
把可疑的对象打开,仔细核对一下来源对象和目标对象。要是需求的内容虽然已经变过了,但是下游派生出来的设计或者测试用例仍然还适用,那就可以放心地把它的可疑状态给清除掉;可要是发觉关联两边的信息已经对不上号了,那就应该先去把下游的对象更新好,然后再回来清除这个可疑状态。
3、碰到问题数量不多的时候,就用单条清除的办法
从【分析】→【可疑链接】→【清除】进去,分别查看一下入链和出链的情况,然后对已经复核过、认为没有问题的链接,一条一条地执行清除。这种方式很适合那种变更带来的影响比较大,需要给每一条处理都留下判断记录的场景。
4、等到全部确认没问题了,再走批量清除的路子
在同一个模块当中,如果已经有大量的链接挨个儿评审完,确认都没有问题了,那就可以进入【分析】→【可疑链接】→【全部清除】,按自己的需要,选择是去清除全部的入链、全部的出链,还是把两个方向同时清掉。在做批量操作之前,先保留下评审的记录和模块的备份,会保险很多。
三、DOORS可疑链接清理后还要检查什么
把可疑状态都清干净之后,还不能马上就停下来,必须再去确认一下整个追溯的链路本身,是不是真的完整、没有缺失。要不然,光从列表上看好像是干净了,但实际上需求之间的覆盖关系却可能已经发生了断裂。
1、检查一下访问的权限
在头一次动手清除可疑链接的时候,系统是会往链接模块里面创建一些相关属性的,因此操作的那个人,手上必须要有链接模块的创建权限。而后续再去继续清理的时候,除了链接模块本身的修改权限之外,来源模块和目标模块的修改权限也是少不了的,这些都要一块儿核验清楚。
2、千万不要在基线模块里直接清除
DOOLS是不允许在模块基线里面直接去清除可疑链接的。如果真的需要处理,也应该退回到当前那个能够编辑的模块里面,把复核工作做完了,再去重新建立一条新的基线,不能图省事一步跨过去。
3、重新把追溯的覆盖情况核实一遍
清理全部完成以后,也不要忘了再抽查一下,看看从需求到设计、到测试用例,再到下游需求的那一条条链接,是不是都还保持得完完整整。DOORS本身是支持通过动态追溯视图,来做影响分析还有缺口检查的,这个功能同时也可以帮助我们识别范围是不是发生过变动。
总结
概括起来说,在DOORS里面对可疑链接进行检查,经常用到的一条路径就是先进到【分析】→【可疑链接】,然后按照顺序把筛选、显示指示器、显示最近更改,还有显示所有更改这几个功能,挨个儿都用上。当可疑链接压得比较多了,要着手清理的时候,真正的重点并不是求快,急着把列表一口气清空,而是要先去确认每一次变更到底有没有对下游的对象产生实质影响,然后再根据实际情况,去选择是单条清除还是批量清除。最后,只有把权限、基线,还有追溯的覆盖情况都放到一起复核过了,清理出来的结果才能真正让人放心。
