很多项目一直到准备ASPICE评估的时候，才发现写下来的风险都太笼统了，像“进度延期”“需求变更”“测试不足”这一类的话，单从字面上看，倒也不能说它们就写错了，可真到了评审的时候，靠着这些描述，是很难继续往下追问责任在谁、影响有多大、又该用什么样的措施去应对的，识别风险这个动作，需要紧紧地贴着过程活动去走，而针对风险定出来的那些措施，也得能够拿得出证据来，证明它们确实是有效的。

　　一、ASPICE项目风险怎么识别

　　对ASPICE项目的风险进行识别，这件事不能只是靠着项目经理一个人的经验，随手列出几条就完事了，而是需要从需求、设计、开发、测试、变更，还有供应商这些过程里面，一项一项地去排查，风险被描述得越早越清楚，到了后面，去调整计划或者把问题往上升级的时候，才会有个牢靠的依据。

　　1、从需求质量里面去识别风险

　　我们先要去看看，客户给过来的需求，是不是都讲清楚了，它们之间有没有互相冲突的地方，还有，这些需求能不能被顺利地追溯到系统需求和软件需求那里去，比较常见的风险有，需求是从哪里来的，这个源头就没写明白；验收的标准到底是些什么，还缺着没定下来；需求被改来改去的次数太频繁；还有，一些需求压根儿就没有被分配到具体的软件模块上面去，在把这些风险识别出来的时候，不要就扔下一句“有需求风险”便不管了，要把它写成像是“某一类的诊断需求，到现在还缺少用来验收的条件，这样下去，测试用例可能会设计不出来”这种样子。

　　2、从技术的方案里面去识别风险

　　在架构、接口、算法、安全机制，还有性能的边界这些地方，都有可能会藏着风险，比如说，接口的定义，比模块的开发还要晚才出来；通信的矩阵，一直都没有被冻结住；资源占用了多少，心里根本没数，这些都会给后面的集成工作带来影响，在这个地方，需要把识别出来的风险，跟具体的工作产品挂上关系，比方说软件的架构说明、接口的文档，还有设计的评审记录。

　　3、从计划和资源上面去识别风险

　　ASPICE的评估，是很看重计划跟监控的，所以，在识别风险的时候，要去检查一下人员的能力够不够、任务的排期合不合理、评审的节点清不清晰、供应商的交付能不能接上，还有测试的资源匹不匹配，假如有一个人，被安排同时去负责需求的编写、设计的审核，还有测试的审核，那工作的独立性和整体的进度，都会被压得很紧，像这样的情况，就应该把它写进风险的清单里面去。

　　4、从测试的覆盖里面去识别风险

　　测试这一块的风险，通常是从用例没写全、环境一直不太稳定、自动化的脚本好长时间没人去维护、缺陷的回归做得不完整、还有测试的数据没办法重新复现这些地方来的，我们在识别的时候，要去看从需求到测试用例的追溯关系还在不在，也要去看那些跑失败的用例，有没有留下被关闭的证据，要是只在纸上写一句“测试的时间不够用”，对于后面怎么去处理，帮助其实不大。

　　二、ASPICE项目风险措施怎么验证

　　去验证ASPICE项目的风险措施，关键要看这些措施落实下去以后，是不是真的把原来那个风险的状态给改变了，不能只是在表格里面，把状态那一栏改成已关闭就完了，还得能够拿得出执行时候的记录、评审得出来的结论，还有跑出来的那些结果数据。

　　1、验证措施是不是对上了风险的原因

　　每一条被提出来的措施，都要先退回到风险的原因上面去检查一遍，比方说，风险的原因是接口被冻结的时间太晚了，那么针对它的措施，就不能光写一句“加强沟通”来交差，而是应该把冻结的节点具体定在哪一天、这事由谁来负责、接口评审的方式是什么，还有变更审批的路径要怎么走，都给写明白，如果措施没有打在最根本的原因上，那么后面就算是执行了，也很难真的把风险给降下来。

　　2、验证是不是把责任人和完成时间都落到了实处

　　措施，是一定要有明确的责任人、计划好的完成时间，还有当前正处于什么状态的，责任人的名字，不能只填一个部门的名头，时间那一栏，也不能给写成“尽快处理”这种模糊的说法，做ASPICE评估的时候，来审核的人，会去看你项目监控的记录，是不是能反映出风险发生的变化，所以，风险跟踪的表格、开会的纪要，还有项目的计划，这几样东西之间，是要能够对应得起来的。

　　3、验证是不是有东西能证明措施真的被执行了

　　风险措施被落实完了之后，是需要有对应的证据拿出来的，需求上的风险，可以去看需求的评审记录和追溯的矩阵；设计上的风险，可以去看架构的评审结论，还有接口的基线文件；测试上的风险，则可以去看测试的报告、缺陷被关闭的单子，还有回归测试跑出来的结果，一条措施如果连一点证据都拿不出来，那它只能算是口头上的一个动作罢了。

　　4、验证风险现在的状态是不是合理的

　　措施全部完成以后，要去重新判断一下，风险的等级是不是真的已经往下降了，如果这个风险还是存在着，那就要让它继续保持开放的状态，接着去追加新的措施，不要为了在评估的时候让表格显得好看，就把所有的风险一口气都给关掉了，一份真实可信的风险管理，是可以允许有还没有被关闭掉的风险的，但是，你要能够说清楚，当前是用什么方式在控制着它，后面又打算怎么去安排。

　　三、ASPICE风险记录怎么留存

　　对ASPICE风险的记录进行留存，目的是要让别人，能够顺着你留下的这些东西，把当时做出判断的那个过程给还原出来，记录是不需要写得多长的，但是，需要把风险是从哪里来的、影响的范围有多大、用了什么措施，还有最后验证的结果，都串在一起。

　　1、把风险的来源给保留下来

　　在风险清单里面，要写清楚这个风险是从需求的评审里面发现的、设计的评审里发现的、测试执行时碰到的、跟供应商开会提出来的，还是在项目的例会上冒出来的，来源一旦写明白了，后面去做追溯的时候，才能知道到底是谁发现的、又是谁去确认的、现在是由谁在跟着这件事。

　　2、把对影响的判断给保留下来

　　每一条风险，都要讲清楚它会影响到哪一个范围，比如说，是会影响到交付的进度、软件的质量、客户的验收、功能安全的活动，还是会影响到评估的准备，如果影响的范围写得太模糊，那么措施的优先级，就会不太好排。

　　3、把关闭时的依据给保留下来

　　当一个风险被关闭的时候，要把关闭它的原因，还有那些证据被放在了什么位置，都给记录下来，就拿一条接口的风险来说，它被关闭掉，是因为接口的文档已经被冻结了、评审中发现的问题已经全部被关闭了、集成测试也顺利通过了，把这些都写下来，评估的时候就可以直接去查证，用不着临时再去翻材料解释。

　　总结

　　说起来，ASPICE项目的风险到底要怎么去识别，针对风险定下来的那些措施，又要怎么去验证，这里面很关键的一点，就是要把风险给写到具体的过程，还有具体的证据上面去，在识别的阶段，我们要从需求、技术、计划、资源，还有测试的覆盖里面去发现藏在里面的问题；到了验证的阶段，我们则是要去看，措施是不是真的瞄准了原因去打、责任是不是被扛在了某个人的肩上、拿出来的证据是不是齐全的，还有风险的状态，现在来看是不是合理的，这样做出来的风险管理，才能真正地撑得起项目的控制，还有ASPICE的评估。