我是穿拖鞋的汉子，魔都中坚持长期主义的汽车电子工程师。
老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工程师：
屏蔽力是信息过载时代一个人的特殊竞争力，任何消耗你的人和事，多看一眼都是你的不对。非必要不费力证明自己，无利益不试图说服别人，是精神上的节能减排。
无人问津也好,技不如人也罢,你都要试着安静下来,去做自己该做的事.而不是让内心的烦躁、焦虑、毁掉你本就不多的热情和定力。
时间不知不觉中，快要来到深秋。国庆假期结束，又开始新的忙碌。成年人的我也不知道去哪里渡自己的灵魂，独自敲击一些文字算是对这段时间做一个记录。
本文分享电子电气架构---符合ASPICE 4.0 之软件开发流程（SWE)。
1、ASPICE介绍
ASPICE是Automotive SPICE的缩写，是一种用于评估和改进汽车软件开发过程的国际标准；ASPICE定义了一组标准化的软件开发过程和最佳实践，适用于整个软件生命周期，包括需求工程、软件设计、编码、测试和维护等各个领域。
通过规范化开发过程，ASPICE有助于提高软件产品的质量和可维护性，确保软件符合质量要求；同时对于开发者来讲，ASPICE的实施要求团队具备一定的技能和知识，这促进了团队技能和专业知识的提升，同时也促进了组织内的知识和经验的共享。
各家OEM与Tire1等可以去花费一定成本去做ASPICE评审，以彰显自家公司对于软件开发过程管理和实施能力水平。
评审的等级是基于ISO/IEC 15504的能力成熟度模型，对汽车软件开发过程的成熟度进行划分的。
ASPICE评审等级通常划分为以下六个等级，每个等级代表了不同的水平层次，目前行业内达到L1~L2的较多：
-> Level 0 - 未实施；
-> Level 1 - 执行；提供基本的项目管理和开发活动，但缺乏系统的管理；
-> Level 2 - 管理了过程的执行；企业不仅能够完成产品研发相关工作，还能提前制定严谨和周全的工作计划，确保各项目能够有序进行；
-> Level 3 - 定义了过程的执行；软件开发过程在组织范围内得到了定义和标准化，符合需求和目标；
-> Level 4 - 量化了过程的执行；软件开发过程的绩效进行了量化，通过数据分析和评估改进；
-> Level 5 - 优化了过程的执行；软件开发过程持续改进，并与组织的业务目标和策略相一致。
二、SWE介绍
ASPICE过程参考模型
作为汽车软件开发工程师，应该了解并尽量遵循SWE过程，不仅有助于提高软件质量，还能够降低开发成本、缩短开发周期，并增强软件的可维护性和可扩展性。
ASPICE SWE（Software Engineering Process Group，软件工程过程组）是ASPICE中的一个关键部分，它涵盖了软件开发的多个阶段和流程。SWE过程组的主要目标是确保软件开发过程中的各个阶段都遵循最佳实践，以提高软件质量、减少开发风险，并满足汽车行业的严格要求。
三、SWE.1
软件需求分析；目的是建立一套与系统需求和系统架构一致的结构化和分析的软件需求。
对应这一部分的开发者，应该接收来自SYS.2、SYS.3的输入，即系统需求和系统架构设计。
需要完成六项BP（Base Practices 基础实践；ASPICE各项流程均定义了不同的BP，需要开发者遵守并完成）：
-> Specify software requirements. 定义软件需求
-> Structure software requirements. 结构化软件需求
-> Analyze software requirements. 分析软件需求
-> Analyze the impact on the operating environment. 分析需求在操作环境中的影响
-> Ensure consistency and establish bidirectional traceability. 确保一致性和双向可追溯性
-> Communicate agreed system requirements and impact on the operating environment. 与利益相关者对系统需求及其影响沟通达成一致
举例说明，以车身控制中外灯系统中的近光灯部分需求点为例，SWE1对应描述如下：
SW_REQ-10001 若整车电源模式是ON，车辆应在打开近光灯开关被按下时打开近光灯；
SW_REQ-10002若整车电源模式是ON，车辆应在关闭所有灯光被按下时关闭近光灯；
SW_REQ-10003车辆应为用户提供信息（近光指示灯）以提示近光灯的工作状态。
架构化需求及环境模块影响分析：
四、SWE.2
软件架构设计；目的是建立一个与软件需求一致的且分析过的软件架构，包括静态和动态方面。
该过程的输入既是来源于SWE.1。
5个BP说明如下：
-> Specify static aspects of the software architecture.定义静态的软件架构
-> Specify dynamic aspects of the software architecture. 定义动态的软件架构
-> Analyze software architecture. 分析软件架构
-> Ensure consistency and establish bidirectional traceability. 确保一致性并建立双向可追溯性
-> Communicate agreed software architecture. 沟通商定的系统架构
静态架构示意：
定义软件模块的静态信息，如接口名、信号名、模块名等；
继续以上述SW_REQ-10001~ SW_REQ-10003需求为例
动态架构示意：重点在于模块的动态交互、时序等逻辑体现
