在聊ASPICE SUP.1的配置管理怎么审计、审计出来的问题又该怎么关闭时，要紧的不是单独去查有没有版本号这回事，也不只是翻翻配置库，看文件有没有全塞进去。SUP.1真正操心的地方，是那些工作产品能不能被清楚地认出来并管住，发生了变更之后能不能顺着线索往回追，还有项目在往前跑的过程中，能不能随时都闹明白“当前到底用的哪个版本、是谁在什么时间改的、因为啥改的、这次改动又连累到了哪些别的东西”。所以，给配置管理做审计，就得围着配置项、基线、变更记录，还有最终交付物跟清单能不能对得上号来展开；而问题的关闭，也必须靠着实打实的证据串成一个闭环，不能只丢一句“已整改”就完事。

　　一、ASPICE SUP.1配置管理怎么审计

　　做配置管理审计，首先要看项目上有没有搭起一套基本的控制思路，然后再去瞧这套思路在实际跑起来的时候，是不是真的落到了每一件工作产品上头。审计那会儿，不能光追着问“有没有配置管理计划”，还得去核实计划里定下来的那些规则，在项目里是不是被老老实实地用了起来，比方说需求、设计、代码、测试用例、测试报告这些东西，是不是每一件都能找到各自对应的那个版本。

　　1、检查配置项范围是否完整

　　对照【配置项清单】核对项目中需要受控的工作产品是否已经纳入管理。

　　这一步，得把眼睛死死地盯在需求文档、架构设计、软件详细设计、源代码、测试用例、测试报告、发布出去的软件包，还有问题单这些东西上面，看它们是不是全被认了出来并纳入了受控范围。如果只管着代码那一块，把需求和测试资料甩在旁边不管，那到了后面，就容易闹出版本之间对不上号、问题冒出来以后也根本追溯不回去的麻烦。

　　2、检查基线是否清楚

　　审计时还要去看项目在那些关键节点上，到底有没有把基线建起来，比如需求基线、设计基线、测试基线，还有发布基线。基线这东西，可不是随随便便打个压缩包就能算数的，它得能讲清楚这一版里面都包含了哪些配置项，它们各自的版本号是啥，在什么时间点上被正式冻结的，最后又是经了谁的批准才生效。如果基线的内容一直含含糊糊的，那等后面想再去做变更影响分析，就会碰到很大的困难。

　　3、检查变更是否受控

　　通过【变更记录】查看配置项修改是否经过申请、评审、批准和执行。

　　到了这一步，就得去翻翻问题单、变更单，还有代码提交的记录，看这几样东西相互之间能不能扣到一起去，一一对应起来。比方说，如果某一条需求已经被改过了，顺着这条变更记录，能不能找到当初是出于什么原因要动它，这次改动的范围到底有多广，代码那边又跟着做了哪些对应的修改，测试这边是不是也补上了专门的用例。要是光看见文件被改过却翻不出变更的依据，这种情形通常就不能算配置管理真正起了作用。

　　二、ASPICE SUP.1配置审计问题怎么关闭

　　到了要动手关闭配置审计问题的时候，可不能只是简单回一句“已经补上了”“已经改好了”或者“后面会注意”。ASPICE评估更看重的，是你手上有没有实打实的证据，也就是说，那些被查出来的毛病是不是真被改正了，改正之后的结果又是不是能在配置库、各种记录和项目流程里被清楚地体现出来。要想把一个审计问题顺顺当当地关掉，原因得分析得明明白白，整改措施得写得足够具体，能让人随时翻出来查证的证据也得是现成摆在那儿的。

　　1、先确认问题类型

　　首先要做的，是把碰到的审计问题归到合适的类型里去。配置审计查出来的问题，一般也就那么几类：配置项整个被漏掉了、版本标识前后对不上、基线出现了缺漏、变更没照着流程去走审批、还有交付出去的软件包跟清单里的内容对不拢。不同类型的问题，关门的路数自然也不一样，不能老想着拿同一套笼统的话去应付所有场面。比如说，碰上的是配置项遗漏，那就得把清单补全，再放进版本控制下头去管起来；要是碰上的是变更没走审批，除了补上变更记录之外，还得顺手查一查别的地方，看是不是也藏着同样漏了审批的毛病。

　　2、补充整改证据

　　围绕【审计问题清单】逐条补充整改后的截图、记录、清单或评审结论。

　　比方说，问题是“测试报告到现在还没被纳入配置管理”，那用来关门的证据里头，就应该能让人一眼看见测试报告已经进了配置库，而且旁边清楚地带着版本号、负责人和更新时间。要是问题变成了“发布包跟清单对不上”，那就要把更新后的发布清单、包内容核对结果，还有批准这次发布的记录，全都完整地提供出来，缺一样都不行。

　　3、说明防止复发措施

　　关掉一个审计问题，不光是堵上眼前这个窟窿就算完事，还得接着往下说清楚，以后打算靠什么法子去防止它再换一个样子重新冒出来。比方说，可以在项目检查表里专门加一项核对配置项的动作；在每次正式发布前，多加一道检查基线和待发布内容是不是还保持一致的工序；在变更流程中，用强制手段把问题单和提交记录绑到一块儿去。这样一来，问题关闭才不是临时补材料，而是对配置管理过程本身做了一回实实在在的改进。

　　三、SUP.1配置管理审计容易忽略哪些细节

　　SUP.1从表面上看，好像只是一个在旁边默默做着支持工作的过程，可它其实跟需求、设计、测试还有发布这些主要过程全都紧紧地缠在一起。要是配置管理这块工作没做到位，很多主过程的证据也会跟着受拖累。比方说，需求的版本和测试时用的版本扣不到一块儿，到了评估那会儿，想证明测试覆盖了当前需求就很难；再比方说，代码版本和最后发布出去的软件包对不上号，想证明交付内容是受控的，也拿不出什么底气。

　　1、不要只审代码库

　　头一件要留心的事，就是千万别把审计目光只盯在代码库那一块。配置管理不等于单纯的代码管理，需求、设计、测试、问题单还有发布资料，全都是项目证据链上的一环。光顾着代码，就会把前后这些工作产品之间的线索给硬生生扯断。审计时要去看看不同产品之间能不能顺畅地互相追溯，不能只扫一眼代码提交规不规范就觉得行了。

　　2、注意交付包一致性

　　检查【发布清单】时，要确认交付包中的文件、版本号、编译结果、测试报告和批准记录是否一致。

　　交付包这一块最容易出的岔子，是包里的内容悄悄更新过了，可配套的发布清单还停在旧版本上没有同步；或者测试报告引用的还是老版本结果，发布说明里却写成了新版本。这类问题看着不大，实际上会把一次发布的可信程度给拉低不少。

　　3、问题关闭要留痕

　　配置审计问题关掉以后，还得把问题描述、原因分析、整改措施、责任人、完成时间还有验证结果这一整套信息都留下来。没拿到验证结果的问题，最好先别急着关。比较稳妥的做法，是让配置管理员或者项目里负责质量的人，把证据重新复核一遍，确认问题确实被纠正了，再去更新关闭状态。

　　总结

　　总的说来，ASPICE SUP.1配置管理怎么审计、审计问题怎么关闭，核心就是看配置项是不是完整受控、基线是不是清楚、变更有没有留下记录、交付内容跟清单能不能对得上。审计时从配置项清单、基线记录、变更记录和发布清单这几处入手；关闭问题时，要争取做到原因明白、证据充实、验证到位。只有这样，SUP.1才不会变成一项单纯为了应付整理材料的差事，而能真正成为支撑项目可追溯、可复现、可交付的基础过程。