在汽车软件外包、嵌入式开发还有系统集成这些项目里，评估一个供应商的ASPICE能力，还有后续怎么去跟踪它的表现，不能只是看供应商有没有证书、是不是做过类似的项目，真正会影响到最后交付的，是供应商能不能把需求、设计、编码、测试、配置管理、问题管理，还有变更管理这些过程，稳稳当当地跑起来，在评估的阶段把对方能力的边界看清楚，在跟踪的阶段盯住每一个问题是不是都闭环了，这样到了项目后期，才不容易出现一种情况，就是交付的东西虽然都齐了，可是背后的证据链却断了。

　　一、ASPICE供应商能力怎么评估

　　要去评估供应商的ASPICE能力，首先得把这次外包的范围给弄明白，供应商如果只是负责软件的单元开发，跟它要承担系统设计、软件架构、集成测试，还有发布支持，这几种情况下，评估的重点是会跟着变的。

　　1.先看过程覆盖的范围

　　评估的时候，要去看供应商的项目，是不是覆盖了我们需要的那些过程，比如需求的变更管理、软件架构设计、软件的详细设计、软件的单元验证、软件的集成测试、配置管理、问题的解决管理，还有变更请求的管理，不要光是听对方说一句“我们是按照ASPICE来做的”就行了，得让他们把真实项目里做出来的例子拿出来看。

　　2.检查交付出来的东西质量怎么样

　　可以抽几样东西出来看一看，像是需求规格说明书、架构设计、接口说明、测试用例、测试报告、评审的记录，还有问题单，重点去看这些内容相互之间，能不能追溯得上，比如说，一条软件需求，能不能一路追到设计、代码、测试用例，还有最后测试的结果，如果只是靠着现成的模板堆出来的一堆文档，通常你顺着查一查，就会发现中间是断开的。

　　3.核对一下项目里的角色，还有他们的经验

　　要确认一下，他们的项目经理、软件负责人、测试负责人、配置管理员、质量负责人，这些角色是不是都明确下来了，还要看一看，核心的人员是不是有在汽车项目里做过的经验，他们是不是真的理解像客户的变更、软件的基线、评审的冻结、版本的发布，这些在实际流程里到底是怎么一回事。

　　4.去验证一下他们用的工具和环境

　　供应商在用的需求工具、配置管理工具、缺陷管理工具、测试环境，还有编译环境，是要和我们的项目协作方式能对得上的，工具不一样，不是说就不能合作，但得提前把导出的格式、权限、数据交接的方式，还有记录的保存周期这些东西，都给说清楚。

　　二、ASPICE供应商评价结果怎么跟踪

　　对供应商的评价做完了，那个评估报告，是不能就这么直接给放进文件夹里存起来的，评价得出来的结论，要把它转成后续项目里要去跟踪的一个个具体事项，特别是那些能力偏弱的项、证据不太足的项、流程上有弱点的项，在项目启动之后，是要一直盯着的。

　　1.把评价时发现的问题，转成具体的行动项

　　评估过程中发现的问题，要形成一个清单，里面要写清楚问题的描述、它会影响到什么范围、由谁来负责整改、什么时候完成，还有最后用什么方式来验证，打个比方，如果发现测试报告里少了判定的依据，就不能只是说一句“加强测试文档的编写”就完了，应该把它写成像“补充测试结果的字段、增加评审的签字、统一报告的模板”这样具体的动作。

　　2.设置分阶段的检查点

　　可以在需求冻结、架构评审、代码提交、集成测试，还有版本发布之前，设置几个检查的点，每一个检查点，只去查跟当前这个阶段相关的那些证据，不要什么事情都等到快要交付之前，再一次性去补，不然的话，不管是供应商还是我们自己，都会变得很被动。

　　3.去跟踪问题被关闭的质量

　　一个问题的关闭，不能光看它的状态是不是变成了“已关闭”，还要去看支撑它的证据是不是足够，比如，供应商说已经把追溯的关系给完善了，那我们就要抽几条需求的链路来查一查；供应商说已经把测试用例给补齐了，那我们就要去看这些用例是不是真的覆盖了对应的风险，而不是只去看数量有没有变多。

　　4.把沟通和确认的记录给保留下来

　　对供应商的评价，会牵扯到商务、质量、研发，还有项目管理等好多个方面的人，光是口头上的结论，是很容易传着传着就变样的，每一次的评审会、整改的确认、风险的接受，都要有记录留下来，尤其是像延期交付、过程上出现了偏差、证据缺失这类问题，到了项目的后期，是最容易变成责任上的争议点的。

　　三、ASPICE供应商能力为什么要定期复核

　　供应商的ASPICE能力，是会跟着项目阶段的不同、人员的变动，还有交付上受到的压力，发生一些波动的，前期评估的时候是合格的，可不代表它后面执行起来，就一直能那么稳，所以，定期的复核，是要跟项目的节奏绑在一起的。

　　1.关注人员的变动情况

　　供应商那边的核心人员要是换掉了，那原来我们评估到的那个能力水平，就很有可能会打折扣，特别是当软件负责人、测试负责人，还有质量的接口人发生变动的时候，就要重新去确认一下，关于交付物的审核、问题的处理，还有沟通的机制，这些是不是还能跟原来保持一致。

　　2.关注变更是怎么处理的

　　在一个项目里，需求的变更、接口的变更、平台的切换，这些都是很常见的，复核的时候，要去看供应商是不是真的按照流程去评估了影响、去更新了设计、去补充了测试，而不是仅仅去改一下代码，看一个供应商处理变更的能力，通常就能看出来，它的那一套过程是不是真的在运转。

　　3.关注交付的趋势

　　如果出现了连续地延期、问题被反复地打开、测试的缺陷集中地爆发、文档频繁地被打回来重做，这些信号都在说明，供应商的能力有可能在往下走，或者是它承接的范围，已经超出了它实际能做到的了，到了这个时候，就要及时地把风险往上报，不要一直等到项目的节点快到了，才开始集中地去想办法补救。

　　4.形成对供应商的分层管理

　　多次评价得到的结果，可以沉淀成一份供应商能力的档案，用来给后续的项目准入、任务的分配，还有风险的控制做一个参考，能力表现一直很稳的供应商，可以把复杂的模块交给它；而过程上弱项比较明显的供应商，就需要限制一下它承接的范围，同时，要把过程检查的频次给提上来。

　　总结

　　总的来说，ASPICE供应商能力怎么去评估，还有评价出来的结果要怎么去跟踪，关键的地方，就是要把评估得出来的那些结论，给落到项目的实际执行当中去，在前期，去看它的过程覆盖、交付物质量、人员经验，还有工具环境；到了中期，把发现的问题转成具体的行动项，按照不同的阶段去检查证据；到了后期，再结合人员、变更和交付的趋势，去做定期的复核，这样做了之后，对供应商的评价才不会只停留在一张打分表上，而是能真正帮着项目去降低交付上的风险。