AutomotiveSPICE 详解培训课件

1、Automotive SPICE 详解简介uAutomotive SPICE简介、特点与结构u关于Automotive SPICE的过程、过程能力级别和过程属性u过程评估模型(PAM)概述u与ISO/IEC 15504、ISO/IEC 330XX、CMMI、ISO26262关系 过程评估方法u能力级别u评级u评估过程 名词定义 u1、SPICE:Software process improvement and capability determination 软件过程改进和能力测定。u2、Automotive SPICE: Automotive Software process improve

2、ment and capability determination 汽车软件过程改进和能力测定u3. CMMI：能力成熟度模型集成u4. PAM: Process Assessment Model 过程评估模型u5. 嵌入式软件：嵌入在硬件中的操作系统和开发工具软件。汽车行业典型的嵌入式软件产品有TCU、EMS、ABS、BCM等等。Automotive SPICE 简介u在汽车行业，从2007年起，Automotive SPICE已作为实施评估的首选过程模型。Automotive SPICE是一个国际广泛使用的、评估和改进系统及软件开发过程的标准，也是由欧洲主要汽车制造商共同制定的面向汽车行业

3、的过程评估模型。目的是改善搭载于汽车上的电子控制单元ECU的质量。u 欧洲的主要汽车制造商在2005年发布初版的Automotive SPICE规格，并用其于指导配件供方的开发过程的改善活动。Automotive SPICE 特点 uAutomotive SPICE的最大特点是由ECU配件供方的OEM(汽车制造商)所策定的规范。因此它的意义不仅仅限于【取得评估】，更着重于【改善产品开发项目的质量】。u 奥迪、宝马、奔驰、保时捷、大众等OEM制造商要求其供应商至少要通过Automotive SPICE中的16个过程(HIS范围过程)达到能力等级3才能成为其合格供应商。随着新能源汽车行业的发展，他

4、们也陆续支持这个要求。u最近，汽车制造商开始要求供方对应Automotive SPICE，以满足功能安全ISO26262所要求的过程建立。u主要用途：1.作为判断供应商开发能力的评估指南 =通常用基于Automotive SPICE的评估的说法。 =主要是针对一个开发项目，而不是组织或部门。Automotive SPICE 特点 2.作为供应商改善自身流程活动的实施指南=有时候，汽车制造商会指定改善对象的流程。 =德国BMW公司和其他汽车公司共同推荐的流程组被成为HIS范围（SCOPE）。3.作为满足功能安全（ISO 26262）所要求的流程建立的指南=ISO 26262要求建立可以持续地实施

5、改善活动的组织体系和环境。 =这相当于达成Automotive SPICE的能力3级。Automotive SPICE 结构 uAutomotive SPICE3.0包括32个过程，能力级别分为0到5级，其中HIS 过程包括16个。uHIS：是德国的一个汽车组织，德文Hersteller Initiative Software，翻译成英文为OEM Initiative Software，中文含义是OEM所倡导的软件。uHIS包含五个成员:奥迪、宝马、奔驰、保时捷、大众；主要致力于软件产品和过程的标准化。HIS范围的Automotive SPICE过程是HIS成员对其供应商的最低要求。Autom

6、otive SPICE 结构 uAutomotive SPICE过程参考模型(PRM)-概括，图中红色字体的部分属“HIS范围”，为BMW及其他主机厂推荐的过程组。Automotive SPICE 能力等级 uAutomotive SPICE能力等级分为05等级，分别是:不完整级、已执行级、已管理级、已建立级、可预测级和创新级。Automotive SPICE 能力等级 uLevel 1:所有纳入评估的过程已经被执行了。所谓执行，就是基础实践已经做了，相应的输出工作产品已经有了。uLevel 2:所有纳入评估的过程已经被执行，且其执行过程得到了有效的控制，执行后的输出工作产品进行了配置管理。u

7、Level 3:所有纳入评估的过程已经被企业标准化，发布给所有的项目使用，且项目在使用标准过程时，可以进行适宜性的裁剪。uLevel 4:所有纳入评估的过程已经可以量化，并且经过统计分析，可以针对项目的情况，采取适宜的纠正措施。uLevel 5:企业可以根据不同项目的行为进行统计分析，判断哪方面的过程做的比较好，经过相关决策，进行过程的优化或持续改进。也就是企业具备了自我创新、自我改进的能力。过程评估模型(PAM)中过程定义示例过过程程IDIDMAN.3MAN.3过程名称项目管理过程目的项目管理过程的目的是在项目的要求和约束的背景下，识别、建立和控制项目生产产品所需的活动和资源。过程结果成功实

8、施这一过程的结果是:【1】项目工作的范围得到定义；【2】利用现有资源和限制达成项目目标的可行性得到评估【3】完成工作所需的活动和资源得到规模归类与估算；【4】项目内以及与其他项目和OU组织单位之间的接口被识别和监视；【5】项目实施计划得到开发、执行和维持；【6】项目进展得到监视和报告【7】在没有达成项目目标时，纠正措施获得实施，项目中被识别问题的重复发生 得到预防基本实践基本实践(BP)(BP)MAN.3.BP1:MAN.3.BP1:定义工作范围。定义项定义工作范围。定义项目的目标，动机和边界。目的目标，动机和边界。【结果结果1 1】MAN.3.BP2:MAN.3.BP2:定义项目生命周期。定

9、定义项目生命周期。定义项目的生命周期，这适合于项目义项目的生命周期，这适合于项目的范围的范围i i，环境，规模和复杂性。，环境，规模和复杂性。【结果结果2 2】MAN.3.BP3:MAN.3.BP3:评估项目的可行性。评评估项目的可行性。评估在时间，项目估计和可用资源方估在时间，项目估计和可用资源方面的限制内的技术可行性方面达成面的限制内的技术可行性方面达成项目目标的可行性。项目目标的可行性。【结果结果2 2】MAN.3.BP4:MAN.3.BP4:定义，监视和调整项目定义，监视和调整项目活动。根据定义的项目生命周期和活动。根据定义的项目生命周期和估计，定义、监视和调整项目活动估计，定义、监视

10、和调整项目活动及其依赖性。根据需要调整活动及及其依赖性。根据需要调整活动及其依赖关系。其依赖关系。【结果结果3 3，5 5，7 7】输出工作产品输出工作产品(WP)(WP)项目计划项目计划-【结果结果1 1，3 3，4 4，5 5】交流记录交流记录-【结果结果4 4，6 6】变更请求变更请求-【结果结果7 7】评审记录评审记录-【结果结果2 2，7 7】纠正措施登记纠正措施登记-【结果结果7 7】进度表进度表-【结果结果3 3，5 5】工作分解结果工作分解结果-【结果结果3 3，4 4，5 5】利益相关团体清单利益相关团体清单-【结果结果4 4】项目状态报告项目状态报告-【结果结果4 4，6

11、6】Automotive SPICE与其他标准的关系ASPICE 最初是完全沿用CMMI的初始版本CMM（能力成熟度模型，Capability Maturity Model ），ASPICE与CMM相似程度99%，最初的CMMI审核结果与ASPICE的审核结果可以直接互相转化，而CMMI的审核员可以直接获得ASPICE审核员资质。CMMI目前由美国的CMMI Institute运营，ASPICE由欧洲的VDA QMS运营。而随着多年的发展，两个标准已经逐渐发展成了独立的体系。CMMI适用于所有研发团队，ASPICE仅用于汽车行业的软件研发团队。ASPICE模型相对于CMMI模型其针对系统需求到

12、软件需求、系统设计到软件设计、软件测试到系统测试、需求跟踪等流程给出了更细节的要求。另外针对竞标、采购、交付等环节也提出了更细节的要求。总体而言，截止目前最新版本，ASPICE与CMMI模型依然有极大的相似程度，通常而言，企业实施两者中任何一个模型，都可以同时满足另一个模型的要求。ASPICECMMIAutomotive SPICE与其他标准的关系ISO15504是ASPICE的前身，ISO15504又称SPICE，包含三个SPICE标准：汽车行业的SPICE、医疗设备行业的SPICE、航天行业的SPICE。2005年汽车行业的SPICE从ISO体系中独立出来，由德国汽车行业联合会独立运作，即

13、为现在ASPICE。ASPICEISO15504Automotive SPICE与其他标准的关系ISO33020是一个过程评估的标准，适用于ISO体系下所有过程评估。该标准参考CMM模型和CMMI的评估流程标准SCAMPI（Standard CMMI Appraisal Method for Process Improvement）而制定。目前最新版ASPICE已经既包含了流程要求（PRM）也包含了评估要求（PAM），而其中的评估要求完全符合ISO33020标准。即，执行ASPICE审核完全满足ISO33020标准。ASPICEISO33020Automotive SPICE与其他标准的关系I

14、SO26262是道路车辆功能安全标准，针对与安全相关功能的研发活动中如何进行安全管理，给出了具体操作标准，包含具体的流程和方法。ISO26262中明确要求企业建立可以持续的实施改善活动组织体系和环境。ASPICE三级中明确要求建立相关流程体系和组织环境，因此实施ASPICE同时有助于满足ISO26262中相关要求。而另一方便ISO26262中给出了研发生命周期的具体流程和方法指引也有助于企业实施ASPICE。ASPICEISO26262Automotive SPICE与其他标准的关系TS16949是根据汽车行业特定需要在ISO9001上的扩充，加入了汽车行业的特定技术规范。对汽车零部件开发的流

15、程和质量控方法给出了具体要求，其完全满足ISO9001。最新版的TS16949中对企业定期进行过程评估进行了明确要求，企业可以选择采用CMMI评估或者ASPICE评估。即，实施ASPICE可以满足TS16949中关于过程评估相关要求。ASPICETS16949AUTOMOTIVE SPICE的过程包括：主要生命周期过程类-20个过程,组织生命周期过程类-5个过程支持生命周期过程类-7个过程奥迪、宝马、奔驰、保时捷、大众等主机厂要求至少通过其中的16个过程（HIS范围过程），其能力达到等级3才能成为其合格供应商。其中：主要生命周期过程类-10个过程,组织生命周期过程类-1个过程支持生命周期过程类

16、-5个过程 AUTOMOTIVE SPICE模型-过程要求介绍 AUTOMOTIVE SPICE模型-过程要求介绍主要生命周期过程类-SYS.2：系统需求分析步骤：SYS.2.BP1（指定）明确系统需求。使用利益相关方（干系方）要求和其要求的变更确定系统所需的功能和能力。在系统需求规范中指定功能和非功能系统需求。 SYS.2.BP2：结构化系统需求。在系统需求规范中结构化系统需求。分组到项目相关群集，为项目安排逻辑顺序分类，基于项目的相关准则进行分类，根据利益相关方（干系方）的需求确定优先级。SYS.2.BP3：分析系统需求。分析指定的系统需求，包括其相互依赖性，以确保正确性、技术可行性和可验

17、证性，并支持风险识别。分析对成本，进度和技术影响的影响。SYS.2.BP4：分析对操作环境的影响。识别指定系统与操作环境的其他元素之间的接口。分析系统需求对这些接口和操作环境的影响。SYS.2.BP5：开发验证准则。为每个系统需求开发定义用于验证要求的定性和定量措施的验证准则。SYS.2.BP6：建立双向可追溯性。 建立利益相关方（干系方）要求和系统需求之间的双向可追溯性。SYS.2.BP7：确保一致性。 确保利益相关方（干系方）要求和系统需求之间的一致性。SYS.2.BP8：沟通共识的系统需求。 将所共识的系统需求和系统需求的更新通知所有相关方。定义：系统需求分析过程的目的是将定义的利益相关

18、方（干系方）的需求转换为一系列系统需求，以指导系统的设计。 AUTOMOTIVE SPICE模型-过程要求介绍主要生命周期过程类-SYS.3 系统架构设计步骤：SYS.3.BP1:开发系统架构设计。 开发和文档化系统架构设计，系统要素相应的功能性和非功能性系统要求。SYS.3.BP2: 分配系统要求。 分配系统要求到系统架构设计的元素。SYS.3.BP3: 确定系统要素界面（接口）。 定义、开发和文档化每个系统要素的界面（接口）。SYS.3.BP4: 描述动态行为。 评价和文档化系统元素之间交互的动态行为。SYS.3.BP5: 评价系统构架的可选择性确定构架设计的评价标准。 根据确定的标准来评

19、价系统构架的可选择性。为选择的系统构架记录基本原理。SYS.3.BP6: 建立双向可追溯性。在系统要求和系统构建元素之间建立双向可追溯性。SYS.3.BP7: 确保一致性。保证系统要求和系统构架设计之间的一致性。SYS.3.BP8:沟通一致的系统构架设计。所有相关方系统构架设计沟通一致，更新系统构架设计。定义：系统构建设计过程的目的在于建立一个系统架构设计，且定义哪一个系统要求被分配给系统的哪一个要素，在特定的标准下评价系统构建设计 。 AUTOMOTIVE SPICE模型-过程要求介绍主要生命周期过程类- SWE.1 软件需求分析步骤：SWE.1 BP1：详细说明软件要求。通过系统要求及系统

20、架构，和系统要求及系统架构的变化，来确定软件所需的功能和能力。在软件要求说明中详细说明软件的功能和非功能要求。SWE.1 ：结构软件要求。通过以下方面来构造软件要求说明中的软件要求：1. 分组项目相关的群集2. 按逻辑指令筛选项目3. 按照项目的相关标准进行分类4. 根据相关利益者的需求，确定优先顺序。SWE.1 BP3 ：分析软件要求。分析特定的软件要求，包括他们的相关性，以确保正确性、技术可行性和可验证性，同时也可用于风险识别。分析对成本、进程和技术效果的影响。SWE.1 BP4 ：分析对操作环境的影响。分析软件要求对系统元素的接口和操作环境的影响。SWE.1 BP5 ：确定验证标准。建立

21、每一个软件要求的验证标准，明确验证的质性和量性的测量。SWE.1 BP6 ：建立双向追溯性。在系统要求和软件要求之间建立一致性和双向追溯性，并且在系统的结构设计和软件要求之间建立一致性和双向追溯性。SWE.1 BP7：确保一致性。确保系统要求和软件要求的一致性。确保系统构架和软件要求的一致性。SWE.1 BP8：沟通已经同意的软件要求。在所有相关方中沟通已经同意的软件要求，并适时更新。定义：软件需求分析程序的目的在于将系统要求中的与软件相关的部门，转化为一组软件要求。 AUTOMOTIVE SPICE模型-过程要求介绍主要生命周期过程类- SWE.2 软件架构设计步骤：SWE.2. BP1：确

22、定软件架构设计。关于功能性及非功能性的软件要求的软件元素，在软件架构设计中得到详细说明。SWE.2. BP2：软件要求的配置。根据软件架构设计元素分配软件要求。SWE.2. BP3：确定软件元素的接口。识别、发展并归档各个软件元素的接口。SWE.2. BP4：描述动态行为。SWE.2. BP5：确定资源消耗的目标。在恰当的层次，决定所有软件架构设计相关方的资源消耗目标，并将其文件化。SWE.2. BP6：评估可选择的软件架构。确定架构设计的评估标准。根据确定的标准来评估可选择的软件架构。记录被选择的软件架构的基本原理。SWE.2. BP7：建立双向可追溯性。在系统的结构元素和软件要求之间建立双

23、向追溯性。SWE.2. BP8：确保一致性。确保软件架构设计和软件要求的一致性。SWE.2.BP9：软件架构设计得到所有相关方的同意和沟通。软件架构设计和适时更新，得到所有相关方的同意和沟通。定义：软件架构设计程序的目的在于确定架构设计，确定各每一个软件要求被分配给哪一个软件元素，并根据既定的标准来评估软件架构设计。 AUTOMOTIVE SPICE模型-过程要求介绍主要生命周期过程类- SWE.3 软件详细设计和单元结构步骤：SWE.3. BP1：确定软件详细设计。对每一个在软件架构设计中确定的软件组件开发一个详细的设计。软件架构设计详细规定了所有软件单元的功能性和非功能性的软件要求。SWE

24、.3. BP2：确定软件单元的接口。识别、确定每一个软件单元的接口，并将其文件化。SWE.3. BP3：描述动态行动。评估动态行动及其与相关软件单元之间的互相作用，并将其文件化。SWE.3. BP4：评估软件详细设计。根据互操作性、相互作用、关键性、技术复杂性、风险可测试性来评估软件的详细设计。SWE.3. BP5：建立双向追溯性。建立软件要求和软件单元之间的一致性和双向追溯性，建立软件架构设计和软件详细设计之间的一致性和双向追溯性，建立软件详细设计和软件单元之间的一致性和双向追溯性。SWE.3. BP6：确保一致性。确保软件要求和软件单元的一致性，确保软件架构设计、软件详细设计和软件单元之间

25、的一致性。SWE.3. BP7：沟通已经确定的软件详细设计。与所有相关方沟通已经同意的软件详细设计，并适时更新。SWE.3. BP8：开发软件单元。根据软件详细设计，开发各个可执行的软件单元，并将其文件化。定义：软件详细设计和单元结构的目的在于提供一个评估过的软件单元的详细设计并生成这个软件单元。 AUTOMOTIVE SPICE模型-过程要求介绍主要生命周期过程类- SWE.4：软件单元验证步骤：SWE.4.BP1：开发软件单元验证策略，包括回归策略。制定软件单元验证策略，包括软件单元变更时的重新验证的回归策略。验证策略应定义如何为软件单元符合软件详细设计和非功能要求提供证据。SWE.4.B

26、P2：制定单元核查（验证）准则。 制定单元验证准则，以便根据验证策略提供软件单元符合软件详细设计和非功能要求的证据。 对于单元测试，应在单元测试规范中定义准则。SWE.4.BP3：执行软件单元的静态验证。使用定义的准则验证软件单元的正确性。记录静态验证的结果。SWE.4.BP4：测试软件单元。根据软件单元验证策略使用单元测试规范测试软件单元。记录测试结果和日志。SWE.4.BP5：建立双向可追溯性。建立软件单元和静态验证结果之间的双向可追溯性。在软件详细设计和单元测试规范之间建立双向可追溯性。在单元测试规范和单元测试结果之间建立双向可追溯性。SWE.4.BP6：确保一致性。确保软件详细设计和单

27、元测试规范之间的一致性。SWE.4.BP7：总结和沟通结果。总结单元测试结果和静态验证结果，并将其传达给所有受影响的各方。定义：软件单元验证过程的目的是验证软件单元，以提供软件单元与软件详细设计和非功能软件要求的符合性的证据。 AUTOMOTIVE SPICE模型-过程要求介绍主要生命周期过程类- SWE.5 软件集成和集成测试步骤：SWE.5.BP1：确定软件集成策略。确定与项目计划和放行计划一致的软件集成策略。根据软件架构设计，确定软件项目，并确定集成的顺序。SWE.5.BP2：确定软件集成测试策略，包括回归测试策略。根据软件集成测试策略， 确定集成软件项目的测试策略。这包括在软件项目出现

28、变更的情况下，对集成软件项目进行重新测试的回归测试策略。SWE.5.BP3：确定软件集成测试的规范。根据软件集成测试策略，为每一个集成软件项目确定包括测试案例的集成软件测试规范。这个测试规范必须为集成软件项目和软件架构设计的符合性提供证据。SWE.5.BP4：集成软件单元和软件项目。根据软件集成策略，将软件单元集成软件项目，再将软件项目集成为一个完整的集成软件。SWE.5.BP5：选择测试案例。在软件集成测试规范中，选择测试案例。测试案例必须根据软件集成测试策略和放行计划，有充分的覆盖范围。SWE.5.BP6：运行软件集成测试。通过所选择的测试案例，运行软件集成测试，并记录结果。SWE.5.B

29、P7：建立双向追溯性。建立软件架构设计的元素和包含在软件集成测试规范中的测试案例之间的双向追溯性，建立包含在软件集成测试规范中的测试案例和软件集成测试结果之间的双向追溯性。SWE.5.BP8：确保一致性。确保软件架构设计的元素和包含在软件集成测试规范中的测试案例之间的一致性。SWE.5.BP9：总结和沟通结果。总结软件集成测试结果，并在各相关方之间传递。定义：软件集成和集成测试的目的在于将软件单元整合成较大的软件项目，并上升为一个完整的集成软件，这个集成软件与软件架构设计相符合，并能确保软件的项目得到测试，可以为集成软件项目和软件架构设计的符合性提供证据，包括软件单元和软件项目之间的接口。 A

30、UTOMOTIVE SPICE模型-过程要求介绍主要生命周期过程类- SWE.6 软件一致性测试步骤：SWE.6. BP1：确定软件一致性测试策略，包括回归测试策略。根据项目计划和放行计划， 确定软件一致性测试策略。 这包括在软件项目出现变更的情况下，对集成软件项目进行重新测试的回归测试策略。SWE.6. BP2：确定软件一致性测试规范。根据软件一致性测试策略，确定包括基于验证标准的测试案例的集成软件的质量测试规范，可以为集成软件和软件要求的符合性提供证据。SWE.6. BP3：选择测试案例。在软件测试规范中，选择测试案例。测试案例必须对于软件测试策略和放行计划，有充分的覆盖范围。SWE.6.

31、 BP4：测试集成软件。通过所选择的案例对集成软件进行测试，并记录软件测试结果。SWE.6. BP5：建立双向追溯性。建立软件要求和包含在软件一致性测试规范中的测试案例之间的双向追溯性，建立包含在软件一致性测试规范中的测试案例和软件一致性测试结果之间的双向追溯性。SWE.6. BP6：确保一致性。确保软件要求和包含在软件一致性测试规范中的测试案例之间的一致性。SWE.6. BP7：总结和沟通结果。总结软件一致性测试结果，并在各相关方之间传递。定义：软件一致性测试的目的在于确保集成软件得到测试，可以为集成软件项目和软件要求的符合性提供证据。 AUTOMOTIVE SPICE模型-过程要求介绍主要

32、生命周期过程类- SYS.4 系统集成和集成测试步骤：SYS.4.BP1:开发系统集成策略。制定一项战略,集成系统项目的项目计划和发布计划。识别系统项目基于集成的系统架构设计和定义一个序列。SYS.4.BP2:开发系统集成测试策略包括回归测试策略。制定一项战略,测试后的集成系统项目集成策略。这包括一个回归测试策略,测试集成系统项目系统项是否改变。SYS.4.BP3: 为系统集成测试创建说明书。 根据系统一体化测试战略为系统测试创建说明书包括系统项目测试案例一体化的每一个步骤 。该测试说明书应适用于为一体化在系统构设计下的系统项目的顺从性提供证据SYS.4.BP4:集成系统项目。根据系统一体化战

33、略将系统项目综合纳入综合系统项目。SYS.4.BP5: 选择测试案例。 从测试说明中选择测试案例。根据系统一体化测试战略和发布计划制定的测试案例的选择应包含足够地覆盖范围 。SYS.4.BP6: 执行系统集成测试。 使用选择后的测试案例来执行系统集成测试。记载集成测试结果和记录。SYS.4.BP7:建立双向可追溯性。在构建设计元素和测试案例中建立双向可追溯性包含系统一体化测试说明。在测试案例包括和系统一体化测试说明中的测试案例和测试结果中建立双向可追溯性。SYS.4.BP8:确保一致性 在系统元素和系统构架设计，测试案例包括系统一体化测试说明中保证一致性。SYS.4.BP9: 总结和交流结果。

34、 总结系统集成测试结果并且与所有相关方交流。定义：系统集成和系统集成测试过程的目的，集成系统的项目，来制造一个集成系统，与系统构架设计保持一致，确保系统项目得到检测，同时为系统构架设计包括系统项目间的界面（接口）提供证据。 AUTOMOTIVE SPICE模型-过程要求介绍主要生命周期过程类- SYS.5 系统一致性测试步骤：SYS.5. BP1：确定系统一致性测试方法包括回归测试方法。确定与项目计划一致的系统质量测试方法和放行计划。这包括如果系统项目发生变化以后，重新测试系统的回归测试方法。SYS.5. BP2：确定系统一致性测试的规范。根据系统测试方法的确认标准，确定系统质量测试的规范，包

35、括测量案例。测试规范必须要与整个系统的系统要求相符合。SYS.5. BP3：选择测试案例。根据系统质量测试规范，选择测试案例。测试案例的选择必须充分涵盖系统测试方法和放行计划。SYS.5. BP4：测试综合系统。使用所选择的测试案例来测试综合系统。记录系统测试结果。SYS.5. BP5：建立双向追溯性。在系统要求和测试案例包括系统质量测试规范之间，建立一致性和双向追溯性。在包含了系统质量测试规范的测试案例，和系统质量测试结果之间，建立一致性和双向追溯性。SYS.5. BP6：确保一致性。确保系统要求和包括系统质量测试规范的测试案例质检的一致性。SYS.5. BP7：总结并交流结果。总结系统质量

36、测试的结果并在相关方之间得到传递。定义：系统一致性测试的目的在于确保综合系统经过测试，能够符合系统要求，并且系统已经为输出做好准备。 AUTOMOTIVE SPICE模型-过程要求介绍主要生命周期过程类- ACQ.4：供应商监测步骤：ACQ.4.BP.1: 协商一致并保持联合过程、联合接口以及信息的交流。建立和保持对信息进行交换，以及关于联合过程和联合接口、责任、联合活动的类型和频率、通信、会议、状态报告和审查的协议。ACQ.4.BP.2: 交换所有双方协定的信息。 利用客户和供应商双方所定义的联合接口沟通所有双方协定的信息。ACQ.4.BP.3. 与供应商一起评估技术开发。根据双方协商一致定

37、期与供应商一起评估技术开发，包含技术方面、问题、风险以及全程跟踪已经开始的项目。ACQ.4.BP.4: 对供应商的进展进行评估。根据双方协商一致定期对供应商的进展进行评估，包括计划安排你、质量以及成本。全程跟踪已经开始的项目，并开展风险消减活动。ACQ.4.BP.5: 采取行动纠正偏差。 当双方协商一致的目标未能达成时，采取行动纠正偏离项目计划的行为，防止已被发现的问题再次发生。根据目标协商改变行为，并将此改变体现在协议中。定义：供应商监督的目的是为了根据双方协定的要求跟踪及评估供应商的执行情况。 AUTOMOTIVE SPICE模型-过程要求介绍组织生命周期过程类- MAN.3：项目管理步骤

38、：MAN.3.BP1: 定义工作范围：定义项目的目标，动机和边界。MAN.3.BP2：定义项目生命周期。定义项目的生命周期，这适合于项目的范围，环境，规模和复杂性。MAN.3.BP3：评估项目的可行性。评估在时间，项目估计和可用资源方面的限制内的技术可行性方面达成项目目标的可行性。MAN.3.BP4：定义，监测和调整项目活动。根据定义的项目生命周期和估计，定义、监测和调整项目活动及其依赖性。根据需要调整活动及其依赖关系。MAN.3.BP5：确定，监测和调整项目估计和资源。根据项目的目标，项目风险，动机和边界，定义，维护/监控和调整项目的努力和资源估算。MAN.3.BP6：确保所需的技能，知识和

39、经验。识别项目所需的技能，知识和经验，并确保选定的个人和团队及时拥有或获得这些。 MAN.3.BP7：识别、监测和调整项目接口和商定承诺。识别和同意项目与其他（子）项目，组织单位和其他受影响利益相关方（干系方）的接口，并监测商定的承诺。MAN.3.BP8：定义，监测和调整项目进度。 为活动分配资源，并安排整个项目的每个活动。 在项目的生命周期中，必须不断更新进度表。MAN.3.BP9：确保一致性。 确保项目的估计、活动、时间表、计划、接口、技能和承诺在受影响各方之间保持一致。MAN.3.BP10：评审和报告项目进展情况。 定期评审并向所有受影响的各方报告项目的状况和活动的执行情况，以及估计的努

40、力和持续时间。 防止识别的问题的再发生。定义：项目管理程序是为了识别、建立和控制一个项目所需要的行动和资源，在项目的要求和限制条件下，生产出产品。 AUTOMOTIVE SPICE模型-过程要求介绍支持生命周期过程类- SUP.1：质量保证步骤：SUP.1.BP1：制定项目质量保证策略。制定策略，以确保工作产品（WP）和过程质量保证在项目层面独立和客观地进行，没有利益冲突。SUP1.BP2：确保工作产品（WP）的质量。根据质量保证策略和项目进度执行活动，以确保工作产品（WP）符合定义的工作产品（WP）要求并记录结果。 SUP1.BP3：确保过程活动的质量。根据质量保证策略和项目进度执行活动，以

41、确保过程满足其定义的目标并记录结果。SUP.1.BP4：总结和沟通质量保证活动和结果。定期向相关方报告质量保证活动的绩效，偏差和趋势，以根据质量保证策略提供信息和采取措施。SUP1.BP5：确保解决不合格。在过程和产品质量保证活动中发现的偏差或不一致应该被分析、跟踪、纠正和进一步防止。SUP1.BP6：实施升级机制。根据质量保证策略建立和维持升级机制，确保质量保证可能将问题升级到适当级别的管理层和其他相关利益相关方（干系方）以解决这些问题。定义：质量保证过程的目的在于：为工作产品和流程能遵守既定条款和计划，不符合项能得到解决和预防，提供独立客观的保障。 AUTOMOTIVE SPICE模型-过

42、程要求介绍支持生命周期过程类- SUP.8：配置管理步骤：SUP.8.BP1：确定配置管理策略。确定配置管理策略。包括：1.职责和资源； 2.工具和资源库；3.配置项的识别及其命名惯例；4.访问权限；5.配置项和基线的历史，包括：必须和可选的基线；命名惯例；分化、合并和建立基线的方法；发布和批准的流程SUP.8. BP2：确定配置项。根据配置管理策略，识别并记录配置项。SUP.8. BP3：建立配置管理系统。根据配置管理策略建立配置管理系统。SUP.8. BP4：建立分支管理策略。建立适用于使用相同基础的平行项目的分支管理策略。SUP.8. BP5：控制调整和发布。根据配置管理策略建立配置项的

43、控制机制，通过这些机制来控制调整和发布。SUP.8. BP6：建立基线。根据配置管理策略，建立内部目标和外部交付的基线。SUP.8. BP7：报告配置状态。为支持项目管理和其他相关流程，记录并汇报配置项的状态。SUP.8. BP8：确认配置项的信息。确认配置项及其基线的信息是完整的，并确定基线的一致性。SUP.8. BP9:管理存储的配置项和基线。确保配置项和基线的完整性和可用性，通过适当的规划调度和存储资源的分配、归档的长期存储和备份使用CM系统。定义：配置管理过程的目的在于建立和维护一个流程或项目所有的工作产品的完整性，并对所有相关方可用。 AUTOMOTIVE SPICE模型-过程要求介

44、绍支持生命周期过程类- SUP.9 问题解决管理步骤：SUP.9.BP1：建立解决问题的管理策略。建立解决问题的管理策略，包括解决问题的行动、问题的状态模型、警报通知、行动的执行责任人和紧急情况处理机制。各方的影响因素都很明确，而且也有明确定义。SUP.9.BP2： 确定和记录问题每一个问题都被独立的确认、描述和记录。在问题重现和判定过程中，须提供其他支持性的信息。SUP.9.BP3：记录问题的状态。每一个问题都需要一个指定的状态模式来跟踪状态，以便追溯。SUP.9.BP4：判定出根本原因，并确定出问题的影响范围。调查问题，确定问题的根本原因和影响范围，以便给该问题分类，并决定合适的解决方案。

45、SUP.9.BP5：授权紧急情况的解决方案。如果问题管理机制要求一个紧急预案，则须获得紧急预案的许可，这个紧急预案必须要符合问题解决机制的要求。SUP.9.BP6：建立警报通知。如果问题管理机制要求，其他系统或其他关联方出现了有较大影响问题，则需要建立一个预警通知机制，这个警报机制必须要符合问题解决机制要求。SUP.9.BP7：开始问题解决根据问题解决策略，开始问题解决的适当措施，包括评审行动措施，或提出变更申请。SUP.9.BP8：跟踪并关闭问题。跟踪并关闭问题，包括所有相关的变更申请。在问题关闭之前，需要得到关于变更申请的正式许可。SUP.9.BP9：分析问题趋势。收集并分析问题解决管理的

46、数据，确定趋势，并根据问题解决管理机制采取相关行动。定义：问题解决管理过程的目的在于问题得到确定、分析、管理和控制。 AUTOMOTIVE SPICE模型-过程要求介绍支持生命周期过程类- SUP.10 变更申请管理步骤：SUP.10.BP1：建立变更申请的管理机制建立变更申请的管理机制，包括变更申请行为、变更申请的状态模式、分析准则和执行这些行动的责任人。影响各方的因素得到明确和维护。SUP.10.BP2：确定和记录变更申请每一个变更申请都根据变更管理机制，被单独识别、描述和记录，包括变更申请的发起人和变更理由。SUP.10.BP3：记录变更申请的状态每一个变更申请都有一个指定的状态模式，以

47、便进行追溯。SUP.10.BP4：分析并评估变更申请。根据策略分析变更申请，包括和其他受影响的工作产品和其他变更申请的依赖性。评估变更申请的影响，并建立确认实施的评判标准。SUP.10.BP5：在执行之前批准变更申请。在执行之前，基于分析结果和资源的可用性，确定变更申请的优先级，并根据策略获得认可。SUP.10.BP6：评审变更申请的执行变更申请的执行在关闭之前需要被评审，以确保确认执行的条件是否满意，以及其他所有相关程序是否已经得到应用。SUP.10.BP7：跟踪变更申请直至关闭跟踪变更申请制止关闭。跟踪反馈会提供给发起人。SUP.10.BP8：建立双向追溯机制。在已有的变更申请和受影响的工

48、作产品之间建立双向追溯性。如果是因为出现问题才发起的变更申请，则需要在相关的问题报告和相应的变更申请之间，建立双向追溯性。定义：过程的变更申请管理目的在于确保变更申请可以被管理、追溯和执行。能力级别实践中相关的指标（指示器）类型（能力）实践中相关的指标（指示器）类型（能力）=以活动为导向的指标（指示器）=以结果为导向的指标（指示器）评估指标（指示器）CL1指标（指示器） 即PA1.1CL1*和2至5指标（指示器）BP基本实践 输出WP工作产品GP通用实践*CL1的GP1.1.1仅仅是其BP基本实践的编辑参考PAMPAM中过程定义的示例中过程定义的示例过程IDMAN.3过程名称项目管理过程目的项

49、目管理过程的目的是在项目的要求和约束的背景下，识别、建立和控制项目生产产品所需的活动和资源。过程结果成功实施这一过程的结果是：1）项目工作的范围得到定义；2）利用现有资源和限制达到项目目标的 可行性得到评估；3）完成工作所需的活动和资源得到规模归类和估算；4）项目内以及其他项目和OU组织单位之间的接口被识别和监视；5）项目实施计划得到开发、执行和维持；6）项目进展得到监视和报告；7）在没有达成项目目标时，纠正措施获得实施，项目中被识别问题的重复发生得到预防。PRMPRM元素元素基本实践（BP）MAN.3.BP1:定义工作范围。定义项目的目标，动机和边界。结果1MAN.3.BP2:定义项目生命周

50、期。定义项目的生命周期，这适合于项目的范围，环境，规模和复杂性。结果2MAN.3.BP3:评估项目的可行性。评估在时间，项目估计和可用资源方面的限制内的技术可行性方面达成项目目标的可行性。结果2MAN.3.BP4:定义，监视和调整项目活动及其依赖性。根据需要调整活动及其依赖关系。结果3，5，7输出工作产品（WP）08-12 项目计划 结果1，3，4 ,5 13-04 交流记录 结果4 ,6 13-16 变更请求 结果713-19 评审记录 结果2，714-02 纠正措施登记 结果714-06 进度表 结果3,5 14-09 工作分解结果 结果3 ,4，5 14-50 利益相关团体清单 结果4

51、15-06 项目状态报告 结果4， 6 PAMPAM元素，即元素，即CL1CL1的指标的指标能力级别ISO/IEC 33020ISO/IEC 33020中的中的PAPA过程示例和相应的过程示例和相应的GP2.1.XGP2.1.X定义定义ISO/IEC 33020ISO/IEC 33020PA2.1PA2.1执行管理过程属性执行管理过程属性执行管理过程属性是对过程的执行进行管理的程度的度量。作为完全达成该过程属性的结果：a) 过程执行的目标得到识别；b) 过程的执行被计划；c) 过程的执行得到监视；d) 过程的执行获得调整以满足计划；e) 执行过程的职责和权限得到定义、分配和沟通；f) 执行过程

52、的人员履行其职责被准备；g) 执行过程所需的资源和信息得到识别、提供、分配和使用；h) 相关方之间的接口被管理，以确保有效沟通和明确的责任分配。ISO/IEC 15504-5ISO/IEC 15504-5GP2.1.1 识别过程执行的目标；GP2.1.2 计划过程的执行，以达成确定的目标。GP2.1.3 根据计划监视过程的执行情况。GP2.1.4 调整过程的执行。GP2.1.5 定义执行过程的职责和权限。GP2.1.6 根据计划识别、准备和提供可用资源以及执行过程。GP2.1.7 管理相关方之间的接口。能力级别ISO/IEC 33020ISO/IEC 33020中的中的PAPA过程示例和相应的

53、过程示例和相应的GP2.2.XGP2.2.X定义定义ISO/IEC 33020ISO/IEC 33020PA2.2PA2.2工作产品（工作产品（WPWP）管理过程属性）管理过程属性工作产品（WP）管理过程属性是对由过程产生的工作产品（WP）被适当管理的程度的度量。作为完全达成该过程属性的结果：a) 过程工作产品（WP）的需求得到定义；b) 过程工作产品（WP）的文件化和控制需求得到定义；c) 过程工作产品（WP）被适当地识别、文件化和控制；d) 过程工作产品（WP）根据计划被安排评审并根据需要得到调整以满足需求。ISO/IEC 15504-5ISO/IEC 15504-5GP2.2.1 定义W

54、P工作产品的需求。定义工作产品（WP）的需求。GP2.2.2 定义WP工作产品文件化和控制的需求。GP2.2.3 识别、文档化和控制WP工作产品。GP2.2.4 评审和调整WP工作产品以满足定义的需求。能力级别ISO/IEC 33020ISO/IEC 33020中的中的PAPA过程示例和相应的过程示例和相应的GP3.1.XGP3.1.X定义定义ISO/IEC 33020ISO/IEC 33020PA3.1PA3.1过程定义过程属性过程定义过程属性过程定义过程属性是维护标准过程以支持定义的过程部署的程度的度量。作为完全达成该过程属性的结果：a) 一个标准过程，包括适当的裁剪（定制）指南得到 定义

55、和维持，描述必须纳入定义过程的基本要素；b) 标准过程与其他过程的顺序和相互作用得到决定；c) 执行过程所需的能力和岗位被识别为标准过程的一部分；d) 执行过程所需的基础设施和工作环境被识别为标准过程的一部分；e) 用于监视方法的有效性和适用性的合适的方法和措施得到决定。ISO/IEC 15504-5ISO/IEC 15504-5GP3.1.1 定义和维持支持已定义过程部署的标准过程。GP3.1.2 决定过程间的顺序和交互，以使其能够作为过程的整体系统工作。GP3.1.3 识别执行标准过程的角色和能力、职责和权限。GP3.1.4 识别执行标准过程所需的基础设施和工作环境。GP3.1.5 决定适

56、当的方法和措施，以监视标准过程的有效性和适用性。能力级别ISO/IEC 33020ISO/IEC 33020中的中的PAPA过程示例和相应的过程示例和相应的GP3.2.XGP3.2.X定义定义ISO/IEC 33020ISO/IEC 33020PA3.2PA3.2过程部署过程属性过程部署过程属性过程部署过程属性是衡量标准过程部署为已定义过程以达成其过程结果的程度的度量。作为完全达成该过程属性的结果：a) 基于适当选择和/或裁剪（定制）的标准过程，已定义过程得到部署；b) 执行已定义过程所需的岗位、职责和权限得到指派并沟通；c) 执行已定义过程的人员基于适当的教育，培训和经验具备能力；d) 执行

57、已定义过程所需的必要资源和信息被提供、分配和使用；e) 执行已定义过程所需的基础设施和工作环境获得提供、管理和维护；f) 作为理解过程行为的基础，以证明过程的适用性和有效性，并用以评估过程可以持续改进的地方，适当的数据得到收集和分析。ISO/IEC 15504-5ISO/IEC 15504-5GP3.2.1 部署已定义过程满足标准过程使用环境特定要求的过程。GP3.2.2 指派并沟通执行已定义过程的岗位、职责和权限作。GP3.2.3 确保执行已定义过程的必要能力。GP3.2.4 提供资源和信息以支持已定义过程的执行。GP3.2.5 提供充分的过程基础设施以支持已定义过程的执行。GP3.2.6

58、收集并分析关于过程绩效的数据以证明其适用性和有效性。能力级别评级结果有评级结果有6 6级级CL1已执行PA1.1过程执行（*）CL2已管理PA2.1 执行管理PA2.2工作产品管理CL3已确立PA3.1过程定义PA3.2 过程部署CL4 可预测PA4.1 定量分析PA4.2 定量控制CL5可创新PA5.1 过程创新PA5.2 过程创新落实CL0 不完整能力级别过程能力级别及过程属性过程能力级别及过程属性存在6个能力级别 ，表现为 9个过程属性级别0：不完整过程过程没有执行，或无法达成其过程目的。级别1：已执行过程执行的过程达成其过程目的。级别2：已管理过程先前描述的所执行的过程现在以受管理的方

59、式（计划、监视和调整）实施，并且其工作产品（WP）被适当地建立、控制和维护。级别3：已建立过程先前描述的管理过程现在使用能够达成其过程结果的定义的过程来执行。级别4：可预测过程先前描述的已建立的过程现在在定义的范围内可预见性地运行达成其过程结果。定量管理需求识别，测量数据被收集和分析以识别可归因的变差原因。采取纠正措施来解决可归因的变差原因。级别5：可创新过程先前描述的可预测过程正持续改进以相应组织变化。注意：评级是评过程属性注意：评级是评过程属性能力级别过程能力级别及过程属性过程能力级别及过程属性在这个过程评估模型中，能力的定义是基于ISO/IEC33020定义的9个过程属性，如表：级别0：

60、不完整过程级别1：已执行过程PA1.1过程执行过程属性级别2：已管理过程PA2.1执行管理过程属性PA2.2工作产品（WP）管理过程属性级别3：已建立过程PA3.1过程定义过程属性PA3.2过程部署过程属性级别4：可预测过程PA4.1定量分析过程属性PA4.2定量控制过程属性级别5：可创新过程PA5.1过程创新过程属性PA5.2过程创新落实过程属性能力级别评级PAPA可以获得什么等级值？（可以获得什么等级值？（ISO/IEC33020ISO/IEC33020）NPLF未达成未达成 0%0%至至15%15%“很少或根本没有证据表明达成被评估过程，定义的属性。”部分达成部分达成 15%15%至至5