|
MAKE MORE PEOPLE SUCCEED✨ 
— 前 言 — 从事汽车电子开发的你，是否有过这样的心路历程： 刚毕业时进入公司，懵懵懂懂地按照公司的培训，了解自己工作内容，以及与其他岗位的交互，还要熟悉V模型开发流程。 工作几年后，睁开眼睛看到了外部的世界。跟从事IT行业的同学们聊聊，跟转行做医疗器械的同学们扯扯，你是不是也曾想过：为什么汽车电子的开发会是这样一种形态呢？都涉及到系统和软件的开发，但是组织形式和开发形式却又如此的不一样？是什么东西在指导并搭建了这样一种特定的开发组织形式呢（即开发流程）？ 让我们把这几个问题再深入具体化： 为什么汽车电子行业的开发要有系统、软件、硬件、结构（机械）、匹配、集成、测试、验证、确认、制造、质量管理、工程项目管理、产线项目管理、产品管理、风险管理等复杂的开发人员设置？ 为什么在汽车电子相关的几个供应商和主机厂跳来跳去，发现公司的项目组织形式和部门组织形式都大差不差，都长成某种特定的样子呢？ 为什么汽车行业那么多搞开发的不会写代码？不会写代码也能特么叫开发人员？？ 为什么汽车电子开发要用V-model流程进行开发？
 牛喀I商城 ASPICE软件开发及测试流程落地培训  小程序
上述一切的答案就在于ISO15504 - Automotive Software Process Improvement and Capability dEtermination（Automotive SPICE，软件流程改进和能力测定的汽车行业定制化版本）。 Automotive SPICE于2005年由AutoSIG发布，是SPICE(ISO\IEC15504国际标准)在汽车行业的衍生标准，其关注汽车行业的软件过程改进和能力测定。ASPICE兴起于欧洲，广泛用于主机厂以及供应商企业自身的的过程能力改进，以及对供应商的风险评估。从更务实的角度，主机厂基于供应商的ASPICE等级评定其是否具有供应商资质。 — A-SPICE 3.0总览 — 
— 具体工程开发流程步骤（ENG） — 
现在你知道汽车电子零部件供应商里的系统工程师角色来源了吗？ 由上图可知，SYS.1/SYS.2/SYS.3/SYS.4/SYS.5的流程定义，需要一个角色来负责对应着五个环节的任务。分别是：需求获取、系统需求分析、系统架构设计、系统集成和集成测试、系统确认测试。 接下来，我们讲按照开发步骤来讲讲工程开发的细节。 当然，除了流程，如果你想更深入了解关于ASPICE软件工程开发及测试流程的落地实践，可以关注牛喀学城于6月15日~16日举办的培训课程，详情请点击以下海报： 
Step 1：需求获取 从客户获取客户需求，并确认需求被正确理解 Step 2：系统需求分析 将已定义的客户需求转换为一组系统需求，用以指导系统设计； 过程成果： 已经定义了系统需求； 已经对系统需求进行了分类和分析以获取正确性和可验证性； 已经分析了系统需求对运行环境的影响； 已经定义了实现系统需求的优先级； 系统需求能够根据需要更新； 已经在利益相关者（客户等）需求和系统需求之间建立了一致性和双向可追溯性； 利益相关者需求已经根据成本，进度和技术影响进行了评估； 系统需求已经传达给受影响的各方并且达成了一致。
输出物包括以下八种： 需求分析报告（RAR, Requirement Analysis Report）,比如诊断、CAN通信、XCP、电源、KAM存储机制等模块的RAR分析报告； 系统需求说明书（SYSRS, System Requirement Specification），里面需要定义好功能需求和非功能需求。系统说明书的结构可是按照项目相关集分组，也可按照项目逻辑顺序进行排序，也可根据项目相关标准进行分类，还可根据客户要求来分类； 接口需求说明书（IRS，Interface Requirement Specification），定义各个系统模块之间的接口。例如：两个产品之间、过程之间或者过程任务之间的关联；双方共同遵守的准则及格式；关键时间依赖性或前后顺序；描述各个系统组件之间的物理接口，如总线接口（CAN、LIN）、收发器（类型、制造厂商）、附加接口（IEEE、ISO、USB等）、数字接口（PWM）和模拟接口等；识别软件与软件组件之间的接口，如进程间通信机制、总线通信机制等。 验证标准（Validation Specification）。具体内容包括：1. 每条需求都可验证或评估；2. 验证准则定义了验证需求时所遵循的定性及定量的准则；3. 验证准则标明进行需求验证时所遵循的已达成共识的约束条件； 审查记录（RR，Review Record），需提供评审的上下文信息（内容、出席评审的人员列表、评审状态）、覆盖信息（checklist、review标准、需求、标准符合性）、检查发现（不一致性、改进建议）、记录信息（评审准备完成状态、评审准备所花时间、评审所花时间、评审人员和角色的评审意见）、识别所需的纠正信息（风险识别、偏差list、解决问题所要求的行动及任务、纠正措施的负责人、已识别问题的状态及目标关闭日期）； 跟踪记录（TR，Traceability Record）：，跟踪所有需求（客户需求和内部需求）、识别生命周期中的产品&需求之间的映射关系、需求和工作产品之间的连接关系（例如：需求-设计-代码-测试-交付）、在生命周期各阶段提供需求到相关工作产品之间的正向和反向映射； 沟通记录（Communication Record），信件、传真、电子邮件、语音记录、电报； 变更控制记录（Change Control Record）, 记录变更请求，生成基线化产品（baseline product）。具体包括：采用控制机制来控制正式项目的基线化产品（baseline）、变更请求记录（识别受变更影响的系统即文档、识别变更请求、识别变更的负责团队、识别变更的状态）、与相关客户请求及内部变更请求建立连接关系、适当的批准、对重复的请求进行识别和分组。
Step 3：系统架构设计 建立系统架构，确定哪些需求分配给哪些系统元素，并根据定义的标准评估所设计的系统架构。具体内容如下： 可能产生的过程成果： Step 4：软件需求分析 将系统需求的相关部分转换为一组软件需求 指定软件需求：使用系统需求、系统架构及以上两者的变更需求来确定所需软件的功能和特性。在软件需求规范中指定功能性和非功能性软件需求。只有在软件开发中，系统需求和系统架构才会设计到一个给定的操作环境； 结构化软件需求：结构化可以按照项目相关的集群分组，或者按照逻辑排序，或者按照相关标准进行分类，或者为干系人需求设置优先级； 分析软件需求：分析指定的软件需求包括他们的相互依赖关系、确保正确性、技术可行性、可验证性和支持风险识别。分析成本影响，进度和技术的影响； 分析对操作环境的影响：分析系统元素接口和操作环境对软件需求的影响； 开发验证标准：为每个软件需求开发验证标准，以便于每条需求验证可以定性和定量的度量； 建立双向可追溯性：建立系统需求和软件需求之间的双向可追溯性。建立系统架构和软件需求之间的双向可追溯性； 确保一致性：确保系统需求和软件需求之间的一致性。保证系统架构和软件需求之间的一致性要求； 沟通已确认的软件需求：沟通已确认的软件需求并为所有相关方更新这些软件需求。
输出物包括： 沟通记录； 审查记录； 变更控制记录； 追溯性记录； 分析报告Analysis Record：分析的内容、分析人、所采用的分析准则（选择的准则或采用的优先级计划、决策准则、质量准则）、记录结果（决定或选择的内容、选择的原因、做出的假定、潜在风险）、正确性分析的方面（完整性、可理解性、可测试性、可验证性、可行性、有效性、一致性、内容的充分性）； 接口需求规格说明书（IRS）：更新细化； 软件需求说明书（Software Requirement Specification）：识别适用的标准、识别软件架构考虑及约束条件、识别必需的软件元素、识别软件元素之间的关联关系、考虑给出以下信息（必需的软件性能特性、必需的软件接口、必需的安全特性、数据库设计需求、必需的错误处理及属性恢复机制、必需的资源消耗特性）； 验证标准。
Step 4：软件架构设计 建立一个架构设计和确定哪些软件需求分配给软件的哪些元素，并根据定义的标准评估软件架构设计。 过程成果 具体步骤 软件架构设计：指定软件要素和相关方面的功能和非功能软件需求；软件在适当的层级分解为元素，并在详细设计中描述组件（所谓组件，指软件架构设计的最底层的元素）； 分配软件需求：分配所有软件需求到软件架构设计元素； 定义软件元素接口：识别、开发和文档化软件元素之间的接口； 描述动态行为：参照系统动态行为，评估和文档化软件元素间的时序和动态交互行为。（动态行为是由操作模式确定的，如启动、关闭、正常模式、校准、诊断等等；进程和进程内部通信、任务、线程、时间片、中断等。另外，在评估动态行为时，目标平台和潜在载荷应被考虑）； 定义资源消耗目标：在软件架构设计的适当层级，为相关元素定义并记录所有软件组件的资源消耗目标。（资源消耗通常被明确为资源，诸如内存ROM、RAM、外部/内部EEPROM或Flash数据，CPU负载等）； 评估可替代的软件架构； 双向可追溯性（需求与架构之间）； 确保一致性； 沟通已确定的软件架构设计。
输出物 1.软件架构设计： 2.接口需求规格说明书： 3.跟踪记录； 4.审查需求： 5.沟通记录。 Step 5：软件详细设计和单元实现 步骤几乎和以上步骤完全一致... Step 6：软件单元验证 软件单元测试过程的目的是验证软件单元，证明软件单元符合软件详细设计和非功能性软件需求。 过程成果 指定了包括回归策略在内的软件单元验证策略；包括软件单元发生变更时重新验证的回归策略。验证策略应定义如何证明软件单元符合软件详细设计和非功能性需求。单元验证的技术可能包括静态/动态分析、代码审查、单元测试等； 根据软件单元验证策略开发软件单元验证标准，该策略适用于证明软件单元提供符合软件详细设计和非功能性软件需求；单元验证标准可能包括单元测试用例，单元测试数据，静态验证，覆盖目标和编码标准；单元测试规范可以实现诸如作为自动测试台中的脚本； 根据软件单元验证策略和软件单元验证标准对软件单元进行验证，并记录结果；其中，静态验证可能包括静态分析、代码审查、针对编码标准和指南的检查以及其他技术； 在软件单元之间建立一致性和双向可追溯性，验证标准和验证结果； 汇总单元验证结果，并传达给所有相关方
输出物 测试规范说明书 Test Specification：包括测试设计规格书、测试用例规格书、测试过程规格书、识别回归测试的测试用例；对于系统集成测试，要识别必需的系统要素，例如硬件要素、接线要素、参数设定和数据库等；识别系统元素集成必要的序列或排序； 测试计划Test Plan：分级的测试计划、测试策略（黑盒/白盒测试、系统边界测试、回归测试策略等）；如有必要，编制综合测试计划； 验证结果及测试报告Verification Result and Test Report：验证checklist、通过的项、失败的项、待验证的项、发现的问题issue、风险分析、解决方案、结论、签名确认。测试报告按照要求，形成测试日志分级、形成异常报告、形成测试报告分级； 分析报告Analysis Reprot； 三记录（沟通记录、审查记录、跟踪记录）
Step 7：软件集成和集成测试 将软件单元集成到更大的软件项目中，直到形成与软件架构设计一致的完整集成软件，并确保软件项目是经过测试的，可以证明包括软件单元之间和软件项目之间的接口在内的集成软件项目符合软件架构设计。 具体步骤 开发软件集成策略； 开发包括回归测试策略在内的软件集成测试策略； 制定软件集成测试规范。软件集成测试用例可能关注：软件项目间的正确数据流、软件项目间的数据流的及时性和时间依赖性、使用界面对所有软件项目数据的正确解释、软件项目间的动态交互、符合接口的资源消耗目标； 集成软件单元和软件项； 选择测试用例，要有足够的覆盖度； 执行软件集成测试； 老三样（双向可追溯、确保一致性、总结和交流经验）。
输出物 软件项，分为两大块，一个是集成的软件，一个是文档。集成的软件可分为：源代码、软件元素、可执行代码、配置文件；文档包括：描述和识别源代码、描述和识别软件元素、描述和识别配置文件、描述和识别可执行代码、描述软件生命周期状态、描述归档和发布标准、描述软件单元编译、描述软件组件的构建； 集成的软件：多个软件组件的集合。这里的软件一般是针对某一特定ECU配置的一组可执行文件以及有关的文档和数据； 测试老三样（说明书、计划、报告）； 记录老三样（沟通、审查、追溯）； 构建列表Build list: 识别软件应用系统的聚合、识别所需的系统元素（参数设定、宏程序库、基本数据、作业控制语言等）、识别软件编译时必需的顺序序列、识别输入输出资源库。
Step 8：软件确认测试 确保集成的软件已经过了测试并满足软件需求。与上一步几乎相同。 Step 9：系统集成和集成测试 集成系统项以生成集成系统，符合系统架构设计并确保系统项被测试，用以证明集成的系统项与系统架构设计的一致性，包括系统项之间的接口。 具体步骤 开发包含回归测试策略的系统集成测试策略； 开发系统集成测试规格说明书，包含根据系统集成测试策略的每一个系统项集成阶段的测试用例。 有四个需要注意的点： a. 接口描述系统元素和系统集成测试用例的输入关系； b. 符合架构设计：指定的集成测试能够适时证明，系统项间的接口满足系统架构设计提供的规范； c. 系统集成测试用例应关注：系统项间正确的信号流、系统项间信号流的及时性和时序、使用一个接口信号的所有系统项的正确解释、系统之间的动态交互关系； d. 系统集成测试可能支持使用仿真环境（硬件在环仿真、车辆网络仿真、数字样机）。 集成系统项：按系统集成策略，整合系统项，形成集成系统。系统集成可以逐步执行集成系统项（例如，作为原型硬件的硬件元素、外围设备、传感器、执行器、结构和已集成的软件），生产出与系统架构设计保持一致的集成的系统； 选择测试用例：从系统集成测试规范说明书中选择测试用例。有足够覆盖率； 执行系统集成测试； 老三样（双向可追溯、确保一致性、总结和交流经验）。
Step 10：系统确认测试 确保集成的系统已经测试，为符合系统需求和系统准备交付提供依据。与上述步骤大同小异，略。 由于篇幅原因，本篇到此结束，下一篇我们将为大家讲解具体支持流程步骤（SUP）。
|
