汽车软件过程“作文提纲或模板“之ASPICE 3.1品读（中）
书接上回：
4
过程参考模型和实施指标（等级1级）
上一篇文章写了ASPICE3.1的前三章节，讲了ASPICE的基本运作逻辑。
今天接着写第四章，就是我们所说的作文提纲或模板（参考模型：3个过程类别，8个过程组，32个过程），它同时也引出了作文所需要的基本要素（实施指标：BP和WP），就像议论文的论点论据论证都要有，也没跑题，达成完整成文的目标后算是1级，所以叫基本实践。
我们回到标准，下图显示了过程描述的样子（作文提纲或模板），以下所有子章节描述的8个过程组都是一样的结构。对照我们实际工作，这就是描述了一个流程，你要做什么、为什么这么做、做到什么程度及输出什么成果。
既然是品读，我们也不必把原文都誊上来，具体的细节可以直接查阅标准，文章里侧重于摘出实践中的关键信息。
4.1 获取过程组（ACQ）
这个ACQ被翻译成了获取，但业内习惯叫法是报价，基本都是发生在新项目报价时的OEM对Tier 1或者Tier 1对Tier 2，也就是客户与供应商。
一般来说，客户采购会通过供应商销售这个口子将询价的各类需求（比如叫RFQ或SOR之类）送达，并限定报价时间。
销售呢，转手将相关文件分发给工程、工厂、物流等角色去分析，各个责任人与客户或内部采购或供应商对应接口将方案、风险等确认后，再协同对应部门的成本一起汇总给销售，销售综合之后，向客户报价。
这是个简单的理论路径，实际上，报价阶段项目组介入不多，参与者多是销售或项目经理等少数人，流程也不会非常规范，会有各种操作。
4.1.1 ACQ.3合同协定
当走到这一步，前期工作基本做得差不多了，要准备定点给这家供应商了，后续要走商务合同的签署，明确好双方的权利与义务，也就是本节所谓的“合同协定”。
商务合同涉及到法律条文，所以多数是定式，修改里面部分项目信息即可，但是在报价阶段形成的和与项目相关的技术协议、技术方案、各类承诺文档乃至邮件，其实都是可以作为合同的附属物来约束双方。
甲方爸爸的威严和乙方孙子的挣扎很多时候需要台面上的这些东西来维护和推进。
商业社会，项目经理或销售都需要有敏感的法律和契约意识，邮件不乱发，字不乱签，话不乱说。
尽管合作成熟的甲乙方不怎么会对簿公堂，但“扯皮”是极为常见的，因为某方乱承诺或没有留好证据，导致自己陷入被动和胶着是非常常见的。
4.1.2 ACQ.4供应商监控
监控这个词放在汽车行业的语境里是不够精准的，其实就是日常项目开展中，客户对供应商的管控。
比如，根据客户行业地位的高低和前期的约定，进行开会盯、评审看、电话催、微 信问、邮件投诉各类常规操作，就是客户要想办法让供应商按时保质地完成他的各种要求，包括但不限于上一部分的合同协议涵盖的内容。
4.1.3 ACQ.11技术需求
需求与技术需求这两个概念本身都不复杂，但后面章节还专门细分了系统、软件需求，所以这里的需求实际上更侧重于报价阶段宏观的、描述性的、概要的需求定义。
理论上或期望上，我们追求在报价阶段就将需求范围锁定，做什么，不做什么，什么时候做，一清二楚。显然，又是不太可能的，一来报价阶段持续时间很短，介入的人不太容易涉及到各方专家；二来这个阶段的很多信息还不清楚，无法做决定。
风险和不确定性一定存在。
那么，怎么做呢？其实，就是基于经验、项目复杂度及重要程度，关于到底带多大的风险而进行的权衡。
如果面对相对成熟的或重要级别没那么高的项目，会使用参考或假设的描述，比如，对于尚不清晰的部分，可以说基于某款量产的整车空间和某款量产ECU的技术要求，增加某项功能，参数范围是多少，并按照哪一标准完成实验，如后续有超出的范围，另行谈判……通过这样的方式，框定一个范围，并留有一定的余量，虽说带一些风险，但后期总是有办法吃掉的。
但如果面对的是新型的或很重要的项目，可能会引入更多的职能角色进行更细致的分析，结合历史LLs和新的要求考虑得更全面，尽量避免难以掌控的情况出现。
4.1.4 ACQ.12法律和行政要求
这个属于项目红线，相关角色要绷紧神经。
一般涉及到出口国家的法规、认证、运输等各类需求，或者本国的法律、行业的强标以及专利侵权的一些考量。
比如，有些产品受到政治限制是无法出口到伊拉克之类，或者型式认可（上公告）需要特定状态的产品，或者UI文言涉及到国家主 权之类的……
4.1.5 ACQ.13项目需求
这部分包罗万象，除了技术的、法规的、资质的等特定需求部分，其余所有需求都可以划归到这里，所谓万事皆可项目，万事不离项目，万事都可找项目经理。
具体来说，要看具体的产品特点和以往项目的运作模式，双方的项目接口人员与内部团队在共同协定下，定义好怎么推进问题、怎么跟踪进展、怎么分配任务、怎么划分职责、怎么沟通交流、怎么交付软件或样件、怎么付款、怎么进行风险或缺陷管理、安排什么资质的工程师……
期望的做法是不仅仅停留在口头上和不正式的临时约定上，要落实成规则、流程。
4.1.6 ACQ.14提案要求
在汽车行业，将其粗略理解为RFQ或SOR包更好些。
采购发包时会将很多需求包含在内，除了前面提到的项目、技术、财务、人力、法规之类，报价本身也会有一些特殊的要求，可能会对R&D成本有特别的拆分需求，可能会有多家供应商竞标的要求，可能会有供应商能力评定的要求，可能会有售后支持的要求……
标准里的描述很宽泛，仅仅给了一个概念上的框架。实际操作中，会有不同的类别的要求通过该阶段发布给竞标供应商。
4.1.7 ACQ.15供应商资质鉴定
这和ASPICE、16949以及所有考级或认证的考试或评定一样，在建立好的一套评估体系里给它打个分、划个级别、贴个标签，以便于后续选择时作为参考。
采购部门里一般会有供应商的库，可能会有不同的标签标记，比如红黄绿或者首选次选之类。
然而，无论如何，供应商资质只是一个很低的门槛，选定一家供应商有诸多无法尽述的明暗规则。
4.2 供应过程组（SPL）
4.2.1 SPL.1供应商投标
这里不作详述，因为这部分和ACQ实质上是混杂在一起的，招标与投标是协同做一件事情。
4.2.2 SPL.2产品发布
换句话说，产品发布就是供应商将样件或软件交付给客户的过程。
在此过程中，会涉及到软件版本号定义、样件标签定义、供应商内部批准、Release Note编制、测试报告提交、客户认可……一系列管理过程，目标是将客户需求的软硬件正确及时地交给客户。
4.3 系统工程过程组（SYS）
系统工程和软件工程组的整体思路是从需求、设计、验证三个角度逐级拆分并形成追溯对应的层次化，从客户一句话到一段代码，颗粒度越来越小，做得越来越精细。
就像做十字绣，从想要“家和万事兴”的一句话，到一张布画出很细碎的格子，再到明确每个格子谁来用什么线与什么针法。格子越细，越容易标准化，越容易分工，出错的概率越低，难度越低，越容易重复成功。
4.3.1 SYS.1需求挖掘
需求是我们开展项目的目标，所谓目标导向，就是需求导向。
这里所讲的需求不仅仅限于客户需求，是指所有相关方的需求，领导的、工厂的、采购的、销售的、开发的、测试的……也会以各种形式存在，明示的、暗示的、文本的、邮件的、微 信的、电话的……总之，所有有关系的人的想要的都要被考虑到，只是有些不那么重要的人的需求往往被忽略和平衡掉。
需求挖掘的几个核心点是要沟通、要理解、要达成一致，而后要持续跟踪、变更要被管理、是否实现要定义清楚等。
4.3.2 SYS.2系统需求分析
在识别出各位想要什么之后，不是满口答应，而是要去分析，要看它们对不对、能不能验、能不能做、值不值得做，还要将上一阶段相对杂乱的需求整理，进行结构化和优先级排序，要确保把相关方的需求很好地梳理了出来，形成了清晰、层次分明且不遗漏的技术语言。
4.3.3 SYS.3系统架构设计
要什么清楚了，然后就是设计，这步是架构的设计，比如要形成架构框图、接口定义、时序图等，还要进行与需求的追溯。相当于你要装修房子，店家给你弄了个效果图。
4.3.4 SYS.4系统集成与集成测试
从技术上来讲，系统集成就是根据BOM在硬件上刷新软件，并搭建好相关的整车或网络环境等。集成测试的目标是确认架构对不对，可能会关注到系统组件之间的正确信号流、信号流的时效性、时序依赖性、接口的动态交互等。
4.3.5 SYS.5系统合格性测试
系统合格性测试也叫系统测试或者系统需求测试，就是看看系统需求有没有做到位。
4.4 软件工程组（SWE）
4.4.1 SWE.1软件需求分析
软件需求和系统需求类似，就是将上一层级的系统需求与系统架构再细分为更贴合编码的软件需求语言。
4.4.2 SWE.2软件架构设计
架构设计呢，也就是针对最后一层的需求——软件需求，进行的方案和架构设计。
4.4.3 SWE.3软件详细设计和单元构建
根据架构划分的模块，软件开发人员就可以进行详细的编码设计，会形成一个个的可执行文件。
4.4.4 SWE.4软件单元验证
软件单元设计完后，依然需要验证，只不过这里更多是针对本身设计合理性进行的，比如静态分析、依照编码规范的检查等。
4.4.5 SWE.5软件集成和集成测试
将一个个可执行的单元文件集成到符合软件架构的完整的集成软件，而后进行集成测试，以确认其是否符合软件架构设计。
4.4.6 SWE.6软件合格性测试
同系统测试类似，也就是针对软件需求进行的测试。
4.5 支持过程组（SUP）
4.5.1 SUP.1质量保证
特别是在国内环境下，这个角色其实一直处于相对比较尴尬的境地。
理论上的定义是，作为独立第三方去保证工作产品（不单单是软件产品，还包括其他各类要交付的文档等）和流程符合规定和计划，但达到这个目标的前提是有脱离于具体场景的标准（即不是具体问题具体分析）和执行标准的文化，显然这很难具备。
ASPICE似乎也意识到了，所以有这么两句话“建立了将不符合项升级到适当管理层的权限“和”管理层确保已升级的不符合项得到解决”，但这两条里提到的管理层多数并无这样的认识。
“实事求是”、“具体问题具体分析”、“成王败寇”是中国的经典智慧，但执行起来就是给质量保证工作当头棒喝，如果事情以结果论英雄，凡事可讨论，质量保证很难有发挥空间。
不过，到什么山唱什么歌，什么环境按照什么样的方式做事，这个角色依然可以拓展到不同的领域。
4.5.2 SUP.2验证
这里的验证和软件的测试是不同的概念，它具有更广泛的涵义，是指对确认每个工作产品是否满足定义的要求的行为，包含但大于测试，比如，同行评审、领导签字、第三方审核等。
4.5.3 SUP.4联合评审
这个概念单独拿出来，其实是侧重于整体的项目状态和多个相关方的需求满足得如何的确认，所谓联合就是整体，所谓评审就是确认。
大家一起理理清，对对齐。
对照实际的工作，基本可以等同于质量组织的各个里程碑的质量阀评审，这部分也是质量保证工作难得的发声场景。
4.5.4 SUP.7文档化
标准定义的目的是“开发和维护由过程产出的记录信息”，关键词在“信息”，尽管大家往往比较反感这部分工作，但至少截至目前，我们找不到更好的信息传递的方式，数字化可能能解决一部分传统文档化的弊端，但由于其工具使用有一定的门槛、编辑展示不够灵活、未足够普及、技术尚未成熟等不足，并不能取代文档。
无论是敏捷变更也好，还是数字化转型也好，文档的优化都是一大课题，后续我们可以继续思考探讨。
4.5.5 SUP.8配置管理
关于配置管理，我们前面写了好几篇文章，这里不赘述了。
4.5.6 SUP.9问题解决管理
问题包括软件缺陷或其他项目相关问题，总体要求是要有特定ID、来源、发生阶段、严重或紧急等级、发生场景、发生版本、原因分析、解决方案、责任人等。
由于软件缺陷动辄几百上千，所以缺陷的管理流程是相对规范的，而且缺陷基本代表了软件产品的状态，相应地，受到的关注度也比较高。
后续我们会出一篇文章详细写一下缺陷管理。
4.5.7 SUP.10变更请求管理
变更是个老生常谈的话题，变更本身不具备特殊性，实际上会驱动一次简化的或完整的开发过程。
其中的关键点在于，变更要经过预先可行性分析和CCB上是否执行的批准。
4.6 管理过程组（MAN）
4.6.1 MAN.3项目管理
ASPICE并没有将项目管理讲出什么花样来，权威的论述还是要看项目管理宝典PMBOK。
这里其实想分享点对项目管理另外的看法，如果要挑选出前三点，一个好的项目经理最需要的素质是：积极的沟通、很强的抗压能力和全面的业务逻辑。其余呢，要靠经验积累了。
4.6.2 MAN.5风险管理
每次看到风险管理，总有种无语的感觉。除了比较流行的FMEA、FTA等工具，常规的项目经理维护的那个风险管理表格，确实有种应付交差的样子。
真正的项目推动，可以靠开口项，可以靠缺陷管理，可以靠变更管理，唯独风险，着实难以独立落地，并不是不存在，而是都融合到了其余环节，比如，识别出什么风险后，会首先定义相关的调整任务，而不是去做一下风险管理。
当然，有时候需要汇报项目状态时，或者做一个什么决策选择时，也会用到这个概念。
4.6.3 MAN.6度量
度量离不开数据，数据离不开真实、及时和完整。
这也是比较难做到的，但聊胜于无吧，越是关键的判断和决策越会关注数据的有效性。
前两天看了马云的一个演讲，特别提到了数字化和数据在未来的重要性，这值得我们所有从业者认真思考一下这个课题。
4.7 过程改进过程组（PIM）
4.7.1 PIM.3过程改进
过程改进是个很有价值的点，最有机会的人是前线战斗的人，但这批人往往没动力，反正一个项目交付了就好了，所以这部分常会沦落为EPG自嗨的领地。
这很需要制度来驱动大家的积极性，最直接的是通过钱来鼓励大家动起来。
4.8 重用过程组（REU）
4.8.1 REU.2重用程序管理
这个概念和平台化与共享化很接近，核心在于如何最大化利用现有资源。
对于汽车行业软件开发，相当于裁剪，针对不同复杂度的项目，将部分活动进行裁剪，主要也就是进行复用或重用，比如A项目的某些测试结果可被B项目拿来重用等。
不算很详细地梳理了一下第四章，算是聊了下ASPICE眼里应该完成的基本任务和达到的基本目标在实际工作中怎么体现的，即一篇作文基本成文后是什么样子的，下一篇文章我们再来看看ASPICE认为的高水平以及满分作文应该是什么样的。
ASPICE 3.1原文下载链接：
完
