汽车ASPICE流程详解(⼆):怎么才能保障汽车软件质量?
1 需求获取:从客户获取客户需求,并确认需求被正确理解;
2 系统需求分析:将已定义的客户需求转换为⼀组系统需求,⽤以指导系统设计;
3 系统架构设计:建⽴系统架构,确定哪些需求分配给哪些系统元素,并根据定义的标准评估所
设计的系统架构;
4 软件需求分析:将系统需求的相关部分转换为⼀组软件需求;Step
5 软件架构设计:建⽴⼀
个架构设计和确定哪些软件需求分配给软件的哪些元素,并根据定义的标准评估软件架构设
计;
6 软件详细设计和单元实现;
7 软件单元验证:软件单元测试过程的⽬的是验证软件单元,证明软件单元符合软件详细设计和
⾮功能性软件需求;
8 软件确认测试:确保集成的软件已经过了测试并满⾜软件需求;
9 系统集成和集成测试:集成系统项以⽣成集成系统,符合系统架构设计并确保系统项被测试,
⽤以证明集成的系统项与系统架构设计的⼀致性,包括系统项之间的接⼝;
0 系统确认测试:确保集成的系统已经测试,为符合系统需求和系统准备交付提供依据。
本篇我们继续讲解具体⽀持流程步骤(SUP)。
如果您想学习更多的软件⼯程开发和测试实践技术,更快的导⼊ASPICE,可关注如下培训课
程,课程由多年软件开发⾼级⼯程专家主讲,结合具体项⽬案例进⾏深⼊分析和指导,详情点
击如下海报了解。
⽜喀I商城 ASPICE软件开发及测试流程落地培训⼩程序
— 具体⽀持流程步骤(SUP) —
Step 1:质量保证流程 Quality Assurance(SUP1)
⽬的:为⼯作产品和流程严格按照预定义的规定和计划提供独⽴的、客观的保证,并解决和预
防不符合性的情况。
开发项⽬质量保证策略。主要是保证⼯作产品和质量保证在项⽬层⾯独⽴、客观且⽆利益冲突
地执⾏。所谓独⽴性,可能是财务或组织架构的独⽴。质量保证可能协调并利⽤其它流程的成
果,⽐如核查、验证、联合评审、审计与问题管理。流程质量保证包括流程评估和审计,问题
分析,定期检查的⽅法、⼯具、⽂档和流程定义的坚持,报告和经验教训,为未来的项⽬改善
流程。⼯作产品质量保证包括评审、问题分析、报告和经验教训,来改善未来的⼯作产品。
确保⼯作产品质量。相关⼯作产品的需求可能包括适当标准带来的需求。被发现的不符合的⼯
作产品会进⼊问题解决流程(SUP9),并被归档、分析、解决和追踪以关闭问题并预防。
保证流程活动的质量。按照质量保证策略和项⽬⽇程表执⾏流程活动质量保证,以确保活动契
合既定⽬标并把结果归档。相关过程项⽬标可包括从适当标准带来的⽬标;在流程定义或实施
过程中发现的问题可进⼊流程改善流程(PIM3),以描述、记录、分析、解决和追踪,最终关
闭问题并预防。
汽车商城总结和沟通质量保证活动和结果。根据质量保证策略,定期给相关责任⼈报告性能、偏差和质
量保证活动的趋势以获取信息和⾏动。
确保不符合项的解决。应当就过程和产品的质量保证活动中发现的不⼀致和偏差进⾏分析、追
踪、纠正并预防的⼯作。
实施质量问题升级机制。根据质量保证策略建⽴⼀个渐进式管理机制,以确保可以将问题升⾄
合适的质量保证管理等级和其它利益攸关⽅来解决问题。
输出物:
质量计划:
a. 质量⽬标;
b. 定义保证质量所需的活动任务;
c. 参考相关⼯作产品;
d. 质量评估/保证的⽅法;
e. 参考法规要求、标准及客户需求;
f. 识别预期的质量标准;
g. 为定义的⽣命周期和计划的相关活动指定监控时间表及质量检查点;
h. 以达到预期质量为⽬标设⽴时间表;
i. 实现⽬标的⽅法:需要执⾏的任务、任务负责⼈、需要执⾏的审计、资源承诺;j. 识别⼯作产品和过程任务的质量标准;
k. 指定采取纠正措施前允许的门限/耐受度;
l. 定义质量度量和基准数据;
m. 定义质量记录采集机制和采集时机;
n. 指定质量报告对过低质量所影响过程的反馈机制;
o. 由质量责任机构/部门的批准;
p. 定义质量保证(QA)的独⽴性;
q. 确定升级机会和渠道;
r. 定义客户与供应商质量保证之间的协作。
质量记录:
a.定义需要保罗的信息;
b.定义产⽣信息的任务/活动/过程;
c.定义数据收集⽇期;
d.定义相关数据来源;
e.识别相关质量准则;
f.使⽤信息识别相关的度量;
g.识别创建记录或记录需要满⾜的、需要遵循的任何需求。
审查记录:略;
问题记录:
a.识别问题报送⼈的姓名与相关联系细节;
b.识别负责修复问题的组织/⼈员;
c.包含问题描述;
d.识别问题的分类(严重度、紧急度、关联性等);
e.识别已报告问题的状态;
f.识别问题修复的⽬标发布版本;
g.识别问题的预期关闭⽇期;
h.识别问题关闭准则;
i.识别问题复验活动。
纠正措施记录:
a.识别初始问题;
b.识别⾏动项的负责⼈;
c.定义解决⽅案(为解决问题⽽采取的⼀系列⾏动);
d.识别问题发现⽇期及期望关闭⽇期;
e.包含状态指⽰器;
f.标明后续的审核活动。
质量标准:
a.定义对质量的期望;
b.建⽴⼯作产品充分程度的准则(必需元素、预期的完整性、精确度);
c.识别构成已定义任务的完整性的内容;
d.建⽴⽣命周期变迁准则,以及每个已定义过程/活动的准⼊准出条件;
e.建⽴预期的性能属性;建⽴产品可靠性属性。
Step 2:配置管理 Configuration Management(SUP8)
⽬的:为了建⽴和维护所有流程或项⽬⼯作产品的完整性,并提供给相关⼲系⼈。
开发配置管理策略。包括:职责和资源、⼯具和存储库、对配置项及其命名规范的识别、权限、配置项的历史和基线(需要/可选的基线;命名规范;分⽀⽅法、合并以及建⽴基线;发布和批准基线)。配置管理策略通常为了配合商务搞的不同版本的产品(Variants变种)配置管理。
识别配置项。软件开发的配置项通常包括:配置管理计划;需求⽂档、架构和设计⽂档;软件开发环境;软件开发计划;供应商协议;质量保证计划;软件单元代码和⽂档;应⽤参数;测试⽤例和测试结
果,评审记录;编译清单,集成报告;⽤户⼿册。硬件和结构也可以有配置项,例如硬件布局、图纸、电路板、物料清单等。
建⽴分⽀管理策略。指定分⽀管理策略,适⽤于使⽤相同源码基线进⾏并⾏开发。分⽀管理策略列出了关于何种情况下允许分⽀,是否需要认证,分⽀如何合并,需要怎样处理以确认所有变更在未央及其他变更和原⽣软件的情况下相容地集成到⼀起。
控制修改和发布。根据配置管理策略建⽴配置项控制机制,并使⽤此机制控制修改和发布。
建⽴基线(baseline)。根据配置管理策略建⽴内部和外部交付基线。
报告配置状态。记录并报告配置项状态,以便于⽀持项⽬管理和其他相关流程。
核实配置项信息。例如评审
管理配置项和基线的存储。
输出物
配置项:
包含模块、⼦系统、函数库、测试⽤例、编译器、数据、⽂档、物理介质和外部接⼝。
除此之外,配置项还要有版本维护相关信息。
⼀般建⽴配置项表格时,需要包含配置项类型、相关配置管理库/⽂件/系统、责任⼈、置于配置管理控制下的⽇期、状态信息(例如:开发阶段、已打基线、已发布)、与下⼀层配置项的关联关系、变更控制记录的识别、变更历史的识别。
处理和存储指南:
a.定义以下任务来实现产品的处理和存储:提供原版代码副本及⽂档、灾难恢复⽅案、登记关键安全性问题;
b.提供描述来指导如何存储产品:所需存储环境、使⽤的保护媒介、所需包装材料、存储项、评估存储产品;
c.提供恢复指南。
配置管理计划:
a.定义或引⽤流程来控制配置项的变更;
b.定义度量标准来确定配置管理活动的状态;
c.定义配置管理审计标准;
d.由配置管理职能部门批准;
e.确定配置库⼯具或机制;
f.含有控制项历史及状态的管理记录及状态报告;
g.为配置管理库指定位置及访问机制;
h.指定存储、处理及交付机制。
恢复计划:
a.识别恢复项,如执⾏恢复的规程和⽅法;
b.恢复的时间表;
c.关键的依赖关系;
d.恢复所需的资源;
e.备份维护列表;
f.负责恢复的⼈员及分配的⾓⾊;
g.所需特殊材料;
h.所需⼯作产品;
i.所需设备资源;
j.所需⽂档;
k.备份的存储位置;
l.恢复的通知⼈联系⽅式;
m.验证步骤;
n.恢复的成本估算。
基线:
a.标识⼀致且完整的⼀条或⼀组⼯作产品和⼯件的状态;
b.下⼀个过程阶段的基础;
c.唯⼀的且不能更改的。
配置管理记录(⼯作产品或⼯作项的修改状态;识别配置项;识别要执⾏的活动,例如备份、存储、归档和交付配置项;维持产品⼀致性);
变更历史(变更描述、变更对象的版本信息、变更⽇期、变更发起⼈信息、变更控制记录信息)。
配置管理系统
Step 3:解决问题管理 Problem Resolution Management
总览:解决问题管理流程,是为了确保所有发现的问题都被识别、分析、管理、受控知道解决。
整个流程将会产⽣的成果:
制定问题管理策略;
记录、唯⼀标识并且分类问题;
对问题进⾏分析和评估,确定可接受的解决⽅案;
执⾏解决问题措施;
跟踪问题直⾄关闭;
所有问题状态和趋势可知。
步骤流程:
1.制定解决问题管理策略:制定问题对策管理策略,包括问题对策活动、问题状态模型、警报通知、执⾏这些操作后的响应能⼒和紧急处理策略。设定好到关切⽅的接⼝,并维护。
2.识别并记录问题:每个问题都要单独识别、描述并记录。应当提供⽀持信息来重现和诊断该问题。⽀持信息⼀般包括问题的起源。如何重现。环境信息、何⼈发现等等;单独识别问题有助于对变更的追踪能⼒。
3.记录问题状态信息:根据问题状态模型得出的状态信息是绑定到问题上的,有利于对问题的追踪。
4.诊断问题原因及其影响:调查、诊断问题原因及影响,确定适当⾏为项并对问题进⾏分类。问题分类(例如,A/B/C, 轻微,中等,严重)可根据严重程度、影响、危害性,紧迫性,相关性等进⾏分类。
5.授权紧急问题处理⾏动:若根据问题对管理策略,解决问题需要⼀个紧急对策,那同样根据本策略,为了紧急响应必须包含⼀定的授权。
6.提出警报通知:根据策略,若⼀个问题对其他的系统或者攸关⽅有很强的影响,那么必须发出提⽰警告信息。
7.启动问题解决:根据对策管理策略,采取适当措施以解决问题,包括对过往⾏为的审查,或发起更新请求。合适的⾏为包含发起以变更请求,参考变更请求管理流程。
8.跟踪问题直⾄问题解决:跟踪问题的状态信息,直指问题关闭。关闭问题之前,需得到正式的问题关闭授权。
9.分析问题趋势:从问题管理系统收集并分析数据(发⽣频率、探测度、影响范围等),识别趋