ASPICE软件架构设计模版

为了应对外部A客户的迎审，最近包括去年都做了比较久的ASPICE准备工作，作为一个软件研发，我的任务主要集中在软件详细设计，软件单元测试，软件集成测试，也涉及了一点软件合格性测试。但是前几天得知迎审取消了，有喜有忧，喜的是终于迎来一个双休，不用每天听英语听力了；忧的是这些工作要搁置了。所以，整理一下我在做ASPICE与准备迎审过程中的一些总结和感悟吧。

ASPICE，全称“Automotive Software Process Improvement and Capacity Determination” ，汽车软件过程改进及能力评定。听起来很抽象，解释起来也挺难，我之前看过一个讲解敏捷开发与ASPICE开发之间的关系的视频，**讲到ASPICE是告诉你做什么，敏捷(Agile)则是告诉你怎么做！**感觉颇有道理，ASPICE主要就是对诸如项目管理、供应商管理、系统域、软件域等共15个过程域进行了结果上的要求，比如说在软件详细设计过程中，必须要定义接口函数，描述动态行为，进行详细设计评估等等，比如下图就是详细设计过程SWE3要求的BP和Outcomes。

1. 有一个好的模板
   成熟的文档模板是做好ASPICE的重要一环，这会让工作变得简单，变成填鸭式的，而且能保证各项要求不被遗漏。但是有一个好的模板并不容易，因为这通常是一个公司的核心资产。一般的ASPICE咨询公司会卖模板，但是通常只能提供一个基础版本，需要经过QA在迭代开发中，在迎审准备中，在专家辅导中不断改进。
2. 讲究真凭实据
   “真凭实据”在我认为有两个方面。一个是要“真”，在ASPICE实施过程中，只靠作假，通过编文档、撒谎等方式是绝不可能通过迎审的，我们在迭代一的开发过程中，由于一开始对流程不熟悉，对有的环节不重视，导致后补了不少文档，就遭到了辅导专家的质疑。但是这个真当然也有一个度，有的不重要的适当地使用话术来解释也并非不可。
   第二个就是“据”，ASPICE的世界里非常讲求证据。换言之，你说的话别人都有不信的可能。你说我们每次上库都会进行静态扫描，那就要展示每次扫描的记录；你说我们每次文档基线都会评审，那就展示评审的记录，“什么？参与评审的总共8个人，只有一个人提了意见？”可以看到，证据是用来佐证“真”的。不管实施什么流程，务必保存有效的证据。
3. ASPICE有没有用？
   先说结论，由于我现在还在项目开发初期，所以我的体会是：不仅没用，还费劲。看过别人专家的说法，ASPICE在项目早期甚至是单个项目中确实成本大于收获，但是当项目变得庞大的时候会带来帮助。正是因为这样，我觉得ASPICE在实施的时候必然会导致下面搬砖员工的积极性很低，动辄上百页的文档让人写得想吐。所以，ASPICE也必须是一个自上而下的推行，项目经理+QA施压和审查，才能保证流程的完整和质量。
4. 双向可追溯
   双向可追溯，听起来就很厉害的词，其实是ASPICE中最常用到的词之一。它指的是两个过程的元素之间能够互相关联。比如下图中蓝色线指向的双方就需要可追溯，举例，软件详细设计与软件单元测试涉及的双向可追溯体现在：

• 每个测试用例都能对应到软件详细设计中的函数；
• 每个单元测试用例都能对应到单元测试用例执行结果。 要实现双向可追溯并不难，最简单的方法就是通过Excel管理，更好的方式则是通过专用的软件来建立（我司自研了管理工具）。 除了上述的追溯，还有系统需求与软件需求追溯、软件详细设计与软件架构之间的追溯、软件架构与软件集成测试的追溯、软件需求与软件合格性测试的追溯等等，这些都是每个过程域审查的重中之重！

• 
  

• 
  这一篇就先写到这儿吧，ASPICE是一个方法论，指导OEM或者Tier One的供应商怎么把软件开发做得规范、质量可保证，说难也难，说不难也简单。