aspice软件开发流程(二)（aspice l2）
本篇文章给大家谈谈aspice软件开发流程(二)，以及aspice l2对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
本文目录一览：
工作笔记 aspice基础知识
最近给某OEM做了一次Automotive SPICE CL2评估，很多朋友就问我关于Automotive SPICE评估的一些事情。本文算是一个科普吧，给不太了解Automotive SPICE的人介绍一下Automotive SPICE和Automotive SPICE评估的事情。
1. Automotive SPICE
1.1 什么是Automotive SPICE？
Automotive SPICE是一个”过程模型”，适用于”基于软件的车载系统”的”设计开发过程”。过程模型是一个集合，是包含了与设计开发过程相关的优秀实践的集合。既然是一个集合，那就需要按照一定的结构把这些实践组织起来：
方式一：按照实践所属的不同领域进行组织，比如有些实践是和项目管理相关的，有些实践是和软件需求相关的，有些实践是和软件单元测试相关的….，不同的领域被称为“过程”，这就是Automotive SPICE中的“过程纬度”。Automotive SPICE PAM V3.1中包括有32个过程。
方式二：按照做事情的方式进行组织，比如：依靠个人的经验来做，是能力度级别1（CL 1）的实践；按照可管理的方式（活动管理和工作产品管理）来做，是能力度级别2（CL 2）的实践；按照组织的要求来做，是能力度级别3（CL 3）的实践….，这就是Automotive SPICE中的”能力度纬度”。
“能力度”是“过程的能力度”。如果说“某个项目达到了能力度2级”，是不准确的，应该说“某个项目中的某些过程达到了能力度2级”。同样的，如果说某个组织达到了能力度2级，也是不准确的。
下图是常见的体现评估结果的形式，评估范围内的过程，分别达到了什么样的过程能力度。
1.2 怎么用Automotive SPICE？
Automotive SPICE是欧洲车厂在认识到软件质量的重要性之后，制定的一个规范。目的是希望其供应商能按照Automotive SPICE的要求进行产品的设计开发，以提供高质量的产品。
Automotive SPICE中包括有那么多的过程，那么OEM对供应商的具体要求是什么呢？要求供应商需要应用哪些过程，这些过程需要达到几级呢？
一般来说，OEM不会要求供应商去遵守Automotive SPICE的所有过程的，为什么呢？
性价比！
实施Automotive SPICE的成本，评估的成本，最后都是产品成本，OEM是需要买单的。
所以OEM会基于其对软件质量的理解，选择最重要的过程来要求其供应商。
起初的时候，不同的OEM有不同的使用Automotive SPICE的观点，形成气候的，如下图所示：
说明：
HIS是Audi AG, BMW, DaimlerChrysler, Porsche, Volkswagen成立的制定软件开发规则的组织
如上的过程划分，是基于Automotive SPICE PAM V2.4/V2.5
逐渐的，各OEM的要求开始统一，目前逐渐形成了如下两类：
说明：
2016年HIS组织解散了，VDA QMC（Automotive SPICE PAM V2.5及其以后版本的Owner）在2017年Automotive SPICE PAM V3.0发布时，将之前在业界应用非常广泛的HIS Scope，改名定义为VDA Scope
如上的过程划分，是基于Automotive SPICE PAM V3.0/V3.1
各个与汽车软件相关的供应商在应用Automotive SPICE时，往往最终都是为了满足OEM的要求，其应用Automotive SPICE的过程范围及目标级别，遵照其所服务的OEM的要求。
2. Automotive SPICE评估
接下来我们谈一谈Automotive SPICE评估，在谈Automotive SPICE评估之前，需要先谈一谈与Automotive SPICE相关的组织。
2.1 Automotive SPICE相关的组织
在Automotive SPICE领域，没有机构去管理“评估”，只是有机构去管理“评估师”。这个管理评估师的机构就是iNTACS（国际评估师认证机构，INTernational Assessor Certification Scheme）。iNTACS定义了评估师的级别划分，以及级别晋升和级别维持的条件。Automotive SPICE评估师的级别从低到高分别为：Provisional Assessor, Competent Assessor, Principal Assessor。
晋升到competent Assessor或Principal Assessor，或维持competent Assessor或Principal Assessor资质时，其条件之一就是需要实施Automotive SPICE评估：
作为Assessor晋升证据（或维持资质的证据）的评估要求包括：
评估由至少2个评估师来实施，评估组组长需要Competent Assessor或Principal Assessor，评估组组员可以是Provisional Assessor或Competent Assessor或Principal Assessor
评估的过程范围至少包括项目管理相关的过程、支持类相关的过程和工程类相关的过程
评估的时间需要至少50小时
2.2 Automotive SPICE评估的类型
在1次Automotive SPICE评估时，Automotive SPICE相当于评估的准则（Criteria），而还需要有评估方法，根据所选择的评估方法不同，Automotive SPICE评估分为两种类型，一种是项目能力度评估，一种是组织成熟度评估。
项目能力度评估
遵照ISO/IEC 15504-2 Performing an assessment实施的评估，是项目能力度评估。在这类评估中，是由Sponsor（发起评估的人）确定评估的模型范围（选择哪些过程，这些过程需要评估到几级）、项目范围（评估哪个项目），而Assessor是根据Sponsor的要求实施评估。
（企业想评价哪个项目，评价哪个过程，评价到几级，不是Assessor决定的！）
组织成熟度评估
ISO/IEC 15504-7 TR Assessment of organizational maturity定义的是组织成熟度评估的评估方法，在组织成熟度评估时：Sponsor确定被评估的组织，以及目标级别；由Assessor根据对被评估组织进行分析，之后进行项目抽样（使得被抽样的项目能代表整个组织的水平），然后通过对被抽样项目进行预定义过程的评估，进而得出组织的过程成熟度水平。
简单来说：在组织成熟度评估时，是由Assessor确定被评估的项目，而过程范围也是需要预定义的（应该由Automotive SPICE的Owner来定义，详细的原因，这里不再赘述，读者可以思考思考~~）
组织成熟度评估在业界很少被用到，主要的原因是OEM不太认可组织成熟度评估的方式。我分析有两个原因：
OEM更关注的是供应商为其开发的项目的情况如何，而不关注供应商的组织
Automotive SPICE的业界大咖们不希望Automotive SPICE因为组织成熟度的评估方式而商业化（Automotive SPICE还是很高冷的，不像CMMI那么商业化）
基于如上原因ISO/IEC 15504-7在2008年发布之后，至今也还是TR，始终不是一个正式的ISO标准，本文后续的描述，不再讨论组织成熟度评估。
注：此处的标准号都是15504，15504系列标准正在被330XX标准所替代。
2.3 被认可的Automotive SPICE评估
什么样的Automotive SPICE评估才是正式的评估，或者说是被认可的评估呢？
经常经常有人问我这个问题，但这个问题的题干是不完全的。
是被谁认可的评估呢？
举个例子：如果需要OEM A认可的评估，那么这个认可的条件就需要OEM A来定义。OEM A可以指定某个专业的软件过程专家（该专家可能不具备任何Automotive SPICE的Assessor资质），然后只要是该专家实施的评估，OEM A都认可。
所以说，这个问题不能问我，你应该去问那个“谁”
这么分析问题，有点杠精的行为了~~
正式的评估或者被认可的评估，在Automotive SPICE领域引申是指“可以做为Assessor资质维持或资质晋升的证据的评估”，那这样的评估需要满足什么条件呢？这个答案就是在前文（2.1节）中的阐述。
只要满足2.1节所阐述的条件的评估，就可以认为是一个正式的评估和受认可的评估。与实施评估的组织是无关的哦~~，对吗？
2.4 Automotive SPICE评估结果的有效性和有效期
Automotive SPICE评估是在某个时间点，对某个项目中已经实施的过程的能力度进行的评估，评估结果是代表了历史上的某个项目，在历史上的某个时间点的过程能力情况。
评估结果只是对被评估项目有效，对其它项目是无效的。
在VDA Guideline中，增加了12个月有效期的说法：在被评估项目中，如果没有发生变更，则可以认为评估结果在12个月之内是有效的（这个有效是对同一个被评估项目来说的）；这里的变更是指过程的变更，包括：开发地点的变更、团队组织结构的调整、人员的更替、开发过程的调整等。
虽然某一次Automotive SPICE评估结果只是对被评估的项目有效，对其它的项目无效。但该次评估结果也往往还是可以在一定程度上反映其它项目的过程能力，特别是当其它项目与被评估项目在项目特征上一致时。
1）比如：某个OEM在考察供应商时，供应商展示了3个月之前实施的一次Automotive SPICE评估结果，则OEM可能会认为：“既然是在这么短的时间之前做的评估，那么该评估结果能代表企业目前的能力”（接受）。如果供应商展示了10年之前实施的一次Automotive SPICE评估结果，则OEM可能会认为：“这是太久之前的一次评估，很难代表企业现在的能力”（不接受）。3个月的时间可以接受，10年的时间不可以接受，那么中间的临界时间点在哪里呢？没有答案哦~~
2）不同的Automotive SPICE能力度级别也会对评估结果的有效性产生影响。
Automotive SPICE能力度二级时，具备相同项目特征的项目之间，其项目过程可以是不一致的；Automotive SPICE能力度三级时，具备相同项目特征的项目之间，其项目过程是一致的，都是遵照了标准的组织过程。基于此，企业的某个项目的某些过程如果达成了Automotive SPICE能力度三级，则客户可能会相信其它项目的过程能力也是如此的。
2.5 评估通过证书
当第三方机构在为某企业实施了Automotive SPICE评估之后，如果评估范围内的过程都达到了目标级别，则第三方机构会应被评估组织的要求，发一个通过Automotive SPICE评估的证书。
注：评估通过证书不是Automotive SPICE评估所要求的。是被评估组织为了其Marketing及Business目的，而要求评估机构颁发的。
Automotive SPICE评估通过证书是Automotive SPICE评估结果的Summary，虽然不同的第三方机构，颁发证书的格式和内容都不尽相同，但为了能客观全面的反映评估结果，一般需要包括如下信息：
被评估的组织及部门（是对某个部门下的项目进行的评估，项目所在的具体部门信息需要体现出来）
评估所遵照的Automotive SPICE模型信息，目标级别
评估方法
评估的项目名称，及评估的过程范围，评估日期
实施评估的组织
评估组组长信息及签名
ASPICE 汽车软件过程改进及能力评定
ASPICE：Automotive Software Process Improvement and Capacity Determination
汽车软件过程改进及能力评定，汽车行业评价软件开发团队的研发能力水平模型
由欧盟多家主要汽车制造商共同制定，2005年发布
CMM：最初基于CMM Capability Maturity Model
ISO：国际标准化组织ISO、国际电工委员会IEC、信息技术委员会JTC1联合制定并发布了国际标准ISO/IEC15504，又称SPICE，包含汽车行业SPICE、医疗设备行业、航天行业
ASPICE：从ISO拆分出来，由德国汽车工业联合会（VDA）的质量管理中心（QMC）运营发展
CMM和SPICE：CMM可以针对项目的某个领域、也可以面向整个项目或组织，可以用于评级，如CMMI3，而SPICE只能用于评价项目中的特定过程域（ Process Instance ）
3个过程组别：主要生命周期过程、组织生命周期过程、支持生命周期过程
双向可追溯性和一致性
评估、验证准则和复合性
过程评估模型分为“过程实施指标”和“过程能力指标”
1.过程实施指标——只适用于L1
又分为：基本实践（BP 面向活动，一组任务或活动）、工作成果物（WP，面向结果）
2.过程能力指标——适用于L2~L5
又分为：通用实践（GP 面向活动）、通用资源（GR 面向基础设施）
【0级】代表一种混乱的状态。
【1级】代表企业已经能够完成产品研发相关的工作，但缺乏管理，虽然偶尔能够成功，但项目中存在大量不确定的因素，对项目缺乏掌控能力，无法确保一定能够按时交付高质量的产品
【2级】代表企业不仅能够完成产品研发相关工作还能有提前制定严谨和周全的工作计划，并能有效根据计划实施项目监控和管理，各项目能够有序进行
【3级】代表不仅各项目能够管理得很好，而且能够有效的从历史项目中积累经验和教训，形成公司的知识资产和标准工作流程，用于对今后项目的参考和指导以及公司管理的持续改善
【4级】引入统计学知识和技术，对项目相关各项数据进行统计和分析，并将之运用于未来的项目管理之中，达到对项目结果的预测，并根据预测结果对项目进行实时的调整，确保达成项目目标
【5级】代表企业能够基于商业目标的需要，主动的对过程进行调整，对变革管理有很强的管理能力，能够基于对过程的量化分析设定明确有效的过程改进目标，并能对过程改进结果进行有效的量化监控和分析
主要聚焦在软件，没有包含硬件和机械功能；其他关键部分可以以拆件的形式融合到ASPICE
aspice2级要求权限怎么写
ASPICE（汽车软件过程改进与能力评估）是一种用于汽车软件开发的标准。如果您想要编写ASPICE 2级权限要求，下面是一个可能的范例：
1. 软件需求规格书（SDS）：具有对需求进行编辑、更新和批准的权限。
2. 软件设计文档（SDD）：具备对系统架构、模块、接口和模块实现进行编辑、更新和批准的权限。
3. 代码：具备对源代码、库文件、makefile 和构建脚本进行编辑、更新和批准的权限。
4. 单元测试文档：具备编写单元测试用例和对测试文档进行编辑、更新和批准的权限。
5. 集成测试计划：具备规划集成测试、设计测试用例和对测试文档进行编辑、更新和批准的权限。
6. 缺陷管理系统：具备记录和跟踪软件缺陷、问题和改进措施的权限。
7. 变更管理系统：具备跟踪和管理软件变更和版本控制的权限。
以上是一些例子，具体的ASPICE 2级权限要求会根据你的组织、项目和特定情况而异。在编写要求时，请确保将所有需要的权限列出来，并确保明确规定谁有权批准和执行这些操作。
关于aspice软件开发流程(二)和aspice l2的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。
