汽车零部件软件开发及交付质量管理手册.docx
《汽车零部件软件开发及交付质量管理手册.docx》由会员分享,可在线阅读,更多相关《汽车零部件软件开发及交付质量管理手册.docx(47页珍藏版)》请在冰豆网上搜索。
汽车零部件软件开发及交付质量管理手册
汽车零部件软件开发及交付
质量管理手册
1.概述
1.1目的
本分册定义了供应商在软件开发、发布及交付过程中的基本质量要求,基本输出物及关键控制点,用于指导供应商建立内部软件开发、发布及交付的相关流程,以实现软件开发、发布及交付过程的质量可控。
1.2适用范围
乘用车公司涉及软件开发或灌装的供应商。
1.3供货模式的定义
根据供应商承担的职责不同,包括但不限于如下四种模式:
模式A:
供应商开发,供应商灌装。
模式B:
主机厂开发应用软件及标定文件,供应商灌装。
模式C:
供应商开发,主机厂灌装标定文件。
模式D:
供应商开发,上汽灌装应用软件及标定文件。
1.4过程定义
开发过程:
软件开发、软件测试、开发支持、软件验收。
交付过程:
供应商产线灌装、试装件准备、库存返工、项目样品准备
1.5供货模式与过程的对应
供应商应根据承担的职责不同,选择本分册适用的过程,最终适用过程由主机厂PDT小组进行确认。
基本划分可参见下表一:
开发过程
交付过程
模式A
X
X
模式B
仅底层开发
X
模式C
X
X
模式D
X
X
2.开发过程
2.1概述
2.1.1"V"开发模型
如下图一所示为控制器类零件的“V”开发模型,本章将围绕这些部分及其支持部分展开相关质量管理要求
2.1.2"V"开发模型
2.1.3"V"开发模型与GVDP流程的关联
整车电器架构对各造车阶段功能的定义:
1)模拟样车:
具备安全与行驶相关的功能;
2)EP1车:
具备基本功能;
3)EP2车:
具备所有功能;
一般在这三个造车阶段交样之前,相关零件软件的开发都要经历一个“V”的开发过程;依据零件的开发类型(全新开发、平台开发或沿用开发等)及零件的特性,每个“V”的开发过程(及其内部过程)是否可裁剪,及每个“V”开发过程具体时间节点,应依据主机厂DRE的要求进行最终调整确认。
2.2软件开发
2.2.1技术需求导出
目的:
制定符合技术要求的基线,包括在产品的实施生命周期中的功能及非功能的需求;收集、处理和跟踪在产品和服务生命周期中不断变化的各方需求,作为定义后续工作产品的基础。
基本要求:
1)导出的技术需求应包括:
客户需求、各级标准要求、法规要求及产品对运行环境(硬件、系统)影响的评估;
2)建立机制,以持续监控新增需求和变更需求;
3)建立机制,以使需求方清晰了解和处理状态和处理方式。
输出物:
名称
描述及内容
来源
递交等级
《需求管理表》
《需求管理表》是所有活动展开的依据,应包括:
需求的类别,需求状态,优先级,需求方,认可条件和相关标准。
2.2.1-1
B
应包括:
变更识别、描述、分析和实施,变更请求追踪方法,验证及确认,审查
2.2.2-1
B
《评审记录》
应包括:
评审活动的内容,人员,状态,范围,历时,结果及纠正措施
2.2.3-1
B
注:
递交等级A:
递交主机厂检查;B:
供应商内部检查;C建议具备
2.2.2系统需求分析
目的:
将定义的技术需求转化为一系列系统需求组,以指导系统的设计。
基本要求:
1)确定系统需求,建立系统需求集合;
2)对系统需求进行结构化,并形成系统需求规范,例如:
对系统需求进行分组、进行逻辑排序、根据相关标准进行分类、根据各方需求确定优先级;
3)分析系统需求,包括它们之间的相互依赖关系,以确保正确性、技术可行性和可验证性。
并识别风险,评估系统需求对成本、进度、技术等方面的影响;
4)为每个系统需求制定验证标准,包括定性和定量的验证方法;
5)受影响方均知晓并就系统需求达成一致,对受影响方需求的所有更改进行管理。
以确保那些受更改影响的人能够评估影响和风险。
输出物:
名称
描述及内容
来源
递交等级
《系统需求规范》
应包括:
系统概述、系统元素间约束、系统元素(内存、性能、硬件、用户界面、系统参数设置),系统操作功能,文档类需求,物流及安全需求,诊断需求等
2.2.2-1
A
《需求分解与确认分析报告》
应包括:
分析内容及人员,标准,结果,分析正确性,测试性,验证性,有效性一致等
2.2.2-2
B
《接口需求规范》
应包括:
需求间的关系,共用标准和格式,系统物理接口,软件接口,如进程间通信机制
2.2.2-3
B
《系统需求验证标准》
如有客户标准,使用客户标准,否则使用行业标准或企业内部标准,需求包含验证标准及方法
2.2.2-4
A
《评审记录》
应包括:
评审活动的内容,人员,状态,范围,历时,结果,及纠正措施。
2.2.2-5
A
注:
递交等级A:
递交主机厂检查;B:
供应商内部检查;C建议具备
2.2.3系统架构设计
目的:
建立系统架构,为架构中的系统元素分配系统需求,并评估架构设计。
基本要求:
1)设计系统架构,定义系统元素,描述功能和非功能系统需求;
2)为系统元素分配系统需求;
3)评估并记录系统元素间的动态行为;
4)定义系统架构设计的评估标准;
5)识别、开发系统元素间的接口;
输出物:
名称
描述及内容
来源
递交等级
《系统架构设计》
应包括:
设计概述、系统框图、系统元素相互关系,系统元素和软件关系描述,系统元素设计要求(内存,性能,参数设置,硬件接口),需求到系统元素的映射,操作模式(关机,启动,诊断等),动态行为描述
2.2.3-1~4
B
《元素间接口需求规范》
应包括:
系统元素间关系,共用标准和格式,系统特殊接口,软件接口,如进程间通信机制
2.2.3-5
B
注:
递交等级A:
递交主机厂检查;B:
供应商内部检查;C建议具备
2.2.4软件需求分析
目的:
将系统需求的软件部分转换成软件需求集合。
基本要求:
1)根据系统需求和系统架构,对软件需求进行结构化,并形成软件需求规范,例如:
对软件需求进行分组和逻辑排序,根据相关标准进行分类、确定受影响方需求优先级;
2)软件需求分开到系统的软件元素中,并定义软件元素间的接口;
3)分析软件需求,包括它们之产蝗相互依赖关系,以确保正确性,技术可行性和可验证性,并识别风险,评估软件需求对成本、进度、技术等方面的影响;
4)分析软件需求在操作环境上的影响,并为每个软件需求开发验证标准,包括定性和定量的验证方法。
输出物:
名称
描述及内容
来源
递交等级
《软件需求规范》
应包括:
适用标准、软件结构约束、软件其关系(系统框图)、软件特性、数据库设计要求、错误处理方式、资源消耗等
2.2.4-1~3
B
《分析验证》
应包括:
分析部分与验证部分;
分析部分包含:
分析内容,人员,标准,结果;
验证部分包含:
验证分析的正确性,可测试性,可验证性,有效性,一致性,验证标准及方法
2.2.4-4
B
注:
递交等级A:
递交主机厂检查;B:
供应商内部检查;C建议具备
2.2.5软件架构设计
目的:
建立软件架构,为软件元素分配软件需求,并评估软件架构设计。
基本要求:
1)开发软件架构设计,定义软件元素;
2)为软件元素分配软件需求;
3)识别、开发软件元素间的接口;
4)评估并记录软件元素间的动态行为;
5)确定软件架构设计的评估标准。
输出物:
名称
描述及内容
来源
递交等级
《软件架构设计》
应包括:
软件结构概述,软件元素,代码类别,元素间依赖关系,数据容错校验措施,配置信息,动态行为,数据持久性(软件接口,数据库,安全性等)
2.2.5-1~6
B
注:
递交等级A:
递交主机厂检查;B:
供应商内部检查;C建议具备
2.2.6软件详细设计和单元构建
目的:
开发经过评估的详细设计方案,并生成软件单元。
基本要求:
1)开发软件架构设计中软件单元的详细设计方案,包括所有功能性和非功能性的软件单元;
2)识别、指定软件单元间的接口;
3)评估并记录相关软件单元之间的动态行为;
4)根据软件的详细设计,进行软件单元的详细开发。
输出物:
名称
描述及内容
来源
递交等级
《软件详细设计》文档
应包括:
详细设计(流程图,实体关系图)、数据格式、资源需求(CPU,ROM)等、中断优先级、数据命名规范、程序结构
2.2.6-1~3
B
《软件单元设计》
应包括:
应遵循的编码标准及数据定义标准,实体关系,文件结构和区块,数据结构,算法,功能接口
2.2.6-4
B
注:
递交等级A:
递交主机厂检查;B:
供应商内部检查;C建议具备
2.3软件测试
2.3.1软件单元验证
目的:
验证软件单元,证明软件单元符合软件详细设计要求,以及符合非功能性软件需求。
基本要求:
1)开发软件单元验证策略,形成软件单元验证测试规范,验证测试规范须包括回归测试方案;
2)进行软件单元静态验证及软件单元测试,记录测试结果并形成日志,不符合项进入2.4.4问题解决管理过程,跟踪处理;
3)评审软件单元测试结果,并通知受影响方。
输出物:
名称
描述及内容
来源
递交等级
《软件单元验证测试规范》
应包括如下内容:
测试类型(例如:
动态测试、静态测试、基于功能的测试、代码评审等),回归测试方案、测试用例、测试数据、静态测试及动态测试覆盖率目标、基于功能的覆盖率目标
2.3.1-1
B
《软件单元测试结果》
应包括:
静态测试结果、测试用例执行结果、覆盖率结果、测试结论
2.3.1-2
B
《软件问题跟踪表》
参见2.4.4问题解决管理
2.3.1-2
参见2.4.4
《评审记录》
应包括:
评审活动的内容、人员、问题描述、问题状态、总体结果、纠正措施及责任人。
2.3.1-5
B
注:
递交等级A:
递交主机厂检查;B:
供应商内部检查;C建议具备
2.3.2软件集成和集成测试
目的:
根据软件架构设计逐步集成软件单元,最终形成完整的集成软件;并进行软件集成测试,以确认软件符合软件架构设计(包括软件单元之间的软件项之间的接口)。
基本要求:
1)开发软件集成策略,须与项目计划、发布计划及软件架构设计相一致,根据软件架构设计识别软件项,并定义集成的顺序;
2)根据软件集成策略策划软件集成测试方案,形成软件集成测试规范,验证集成软件与软件架构设计的符合性(包括软件单元之间和软件项之间的接口),测试规范须包括回归测试方案;
3)根据软件集成策略,集成软件单元;
4)根据集成测试策略和发布计划,选择测试用例,进行软件集成测试,记录测试结果并形成日志,不符合项进入2.4.4问题解决管理过程,跟踪处理;
5)评审软件集成测试结果,并通知受影响方。
输出物:
名称
描述及内容
来源
递交等级
《软件集成策划》
应包括:
集成的方式(根据项目情况,选用增量式、Bigbang方式集成方案)、需要集成的功能、顺序及时间计划。
2.3.2-1
C
《软件集成测试规范》
应包括:
时间计划、类型、回归测试方案、测试用例、测试数据、测试计划中定义的各类测试目标
2.3.2-2
B
《集成软件配置清单》
应包括:
集成的软件单元、软件项及其版本、参数及宏定义等
2.3.2-3
B
《软件集成测试结果》
应包括:
原始测试输出数据、测试用例执行结果、测试结论
2.3.2-4
B
《软件问题跟踪表》
参见2.4.4问题解决管理
2.3.2-4
参见2.4.4
《评审记录》
应包括:
评审活动的内容、人员、问题描述、问题状态、总体结果、纠正措施及责任人
2.3.2-5
B
注:
递交等级A:
递交主机厂检查;B:
供应商内部检查;C建议具备
2.3.3软件验收测试
目的:
验证集成软件,确认其满足软件需求。
基本要求:
1)开发软件验收测试策略,形成软件验收测试规范,测试规范须包括回归测试方案;
2)根据软件测试策略和发布计划,选择测试用例;
3)进行软件验收测试,记录测试结果并形成日志,不符合项进行2.4.4问题解决管理流程,跟踪处理;
4)评审软件验收测试结果,并通知受影响方。
输出物:
名称
描述及内容
来源
递交等级
《软件验收测试规范》
应包括:
时间计划、测试方案、回归测试方案、测试用例、测试计划中定义的各类测试目标。
2.3.3-1
C
《软件验收测试结果》
应包括:
原始测试输出数据、测试用例执行结果、测试结论
2.3.3-3
C
《软件问题跟踪表》
参见2.4.4问题解决管理
2.3.3-3
参见2.4.4
《评审记录》
应包括:
评审活动的内容、人员、问题描述、问题状态、总体结果、纠正措施及责任人。
2.3.3-4
C
注:
递交等级A:
递交主机厂检查;B:
供应商内部检查;C建议具备
2.3.4系统集成和集成测试
目的:
根据系统架构逐步集成系统项,形成集成系统,并进行系统测试测试,以确认集成系统符合系统架构设计(包括系统项之间的接口)。
基本要求:
1)根据项目计划和发布计划,开发系统集成策略,根据系统架构设计识别系统项,定义集成的顺序;
2)开发系统集成测试策略,形成系统集成测试规范,以确保集成系统符合系统架构设计(包括系统项之间的接口)
3)根据系统集成策略,集成系统项;
4)根据系统集成测试策略和发布计划,选择测试用例,进行系统集成测试,记录测试结果并形成日志,不符合项进入2.4.4问题解决管理过程,跟踪处理;
5)评审系统集成测试结果,并通知受影响方。
输出物:
名称
描述及内容
来源
递交等级
《系统集成策划》
应包括:
集成方式、每次集成时自身系统及子系统所集成的功能、顺序和时间计划
2.3.4-1
C
《系统集成测试规范》
应包括:
时间计划、测试类型、回归测试方案、测试用例、测试策略中定义的各类测试目标。
2.3.4-2
B
《系统集成测试结果》
应包括:
原始测试输出数据、测试用例执行结果、测试结论。
2.3.4-4
B
《软件问题跟踪表》
参见2.4.4问题解决管理
2.3.4-4
参见2.4.2
《评审记录》
应包括:
评审活动的内容、人员、问题描述、问题状态、总体结果、纠正措施及责任人。
2.3.4-5
B
注:
递交等级A:
递交主机厂检查;B:
供应商内部检查;C建议具备
2.3.5系统验收测试
目的:
测试完整的集成系统,确保其符合系统需求,同时满足系统交付要求。
基本要求:
1)根据项目计划和发布计划,开发系统验收测试策略,形成系统验收测试规范,测试规范须包括回归测试方案;
2)根据系统验收测试策略和发布计划,选择测试用例,进行系统验收测试,记录测试结果并形成日志,不符合项进入2.4.2问题解决管理过程,跟踪处理;
3)评审系统验收测试结果,并通知受影响方,主机厂将一同参与此评审。
输出物:
名称
描述及内容
来源
递交等级
《系统验收测试规范》
应包括:
时间计划、测试类型(例如:
台架测试、实车测试、硬件在环测试等)、回归测试方案、测试用例、测试策略中定义的各类测试目标
2.3.5-1
A
《系统验收测试结果》
应包括:
原始测试输出数据、测试用例我执行结果、测试结论
2.3.5-2
A
《软件问题跟踪表》
参见2.4.4问题解决管理
2.3.5-2
参见2.4.4
《评审记录》
应包括:
评审活动的内容、人员、问题描述、问题状态、总体结果、纠正措施及责任人
2.3.5-3
A
注:
递交等级A:
递交主机厂检查;B:
供应商内部检查;C建议具备
2.4开发支持
2.4.1质量保证
目的:
建立独立的质量保证团队,确保工作产品和工作过程满足预先定义的计划和要求,并确保解决不符合项。
基本要求:
1)建立不隶属于项目的独立质量保证团队;
2)制定项目质量保证策略;
3)定期向管理层及受影响方汇报质量保证结果,建立问题升级机制,确保问题快速解决;
4)按照项目质量保证策略及项目计划开展质量保证活动,进行产品审核及过程评审,确保工作产品及项目过程符合项目要求,并保留记录,形成文档;
5)不符合项进入2.4.4问题解决管理过程,跟踪处理,防止问题再次发生。
输出物:
名称
描述及内容
来源
递交等级
《软件质量计划》
此文件是项目质量计划的一个组成部分。
应包括:
项目组织机构图,软件质量保证人员及资质,资源配置清单,质量目标管理计划,节点评审计划,问题升级流程,偏差放行的方式。
2.4.1-2
A
《质量评审记录》
应包括:
日期、质量活动名称、质量活动信息、关联的质量标准、不符合项。
2.4.1-4
B
《软件问题跟踪表》
参见2.4.4问题解决管理
2.4.1-5
参见2.4.4
注:
递交等级A:
递交主机厂检查;B:
供应商内部检查;C建议具备
2.4.2项目管理
目的:
根据项目主计划,组织相应活动,为项目活动提供必须的资源,确保满足项目需求。
基本要求:
1)确定项目所有活动的进度安排,并进行派发,确保拥有足够的技术及资源,同时,确保项目进度安排被持续更新;
2)根据项目进度安排,实施项目活动;
3)根据项目进度安排,与受影响方对项目状态进行评审,并定期向主机厂进行汇报;
输出物:
名称
描述及内容
来源
递交等级
《软件开发计划》
此文件是项目开发计划的一个组成部分,包括:
项目资源、项目里程碑(包括需要联合评审时间)及目标时间、任务要求、任务开始及完成时间、任务状态、任务分解结构及分配资源。
2.4.2-1
A
注:
递交等级A:
递交主机厂检查;B:
供应商内部检查;C建议具备
2.4.3配置管理
目的:
维护所有项目或过程工作产品的完整性,并提供给项目相关人员。
基本要求:
1)制定配置管理策略;
2)根据配置管理策略,识别配置项;
Ø对于配置项的内容,需在产品EOP后十年予以保留;
Ø对于配置项的命名规则应确保清晰性、唯一性和追溯性;
3)根据配置管理策略,针对不同配置项建立配置管理系统,以提供处理配置项的有效手段;
Ø配置管理系统应包括介质、结构和分类、流程、访问控制和访问配置项的工具;
Ø常用的配置管理系统有:
SVN、Git、MKS、Doors、CDB、Documentum、RTC、RKM等;
4)根据配置管理策略,适时建立基线,以用于内部和外部交付;
5)记录和报告配置状态(例如:
Woking、Review、Release),以支持项目管理和其他流程
输出物:
名称
描述及内容
来源
递交等级
《配置管理计划》
应包括对如下内容的规划:
1)配置库工具或机制;
2)配置项的标识及其命名规则;
3)访问机制及权限;
4)修改和发布策略;
5)分支管理策略;
6)配置项的历史及基线的记录。
2.4.3-1
B
《配置项》
可纳入配置管理的配置项包括:
配置管理计划、需求文档、架构和设计文档、软件开发环境、软件开发计划、质量保证计划、软件单元(包括代码和文档),应用参数,测试用例和测试结果及其评审记录,编译清单和集成报告,已编译软件,客户手册等。
具体包括内容依据项目要求而定,但至少应包括:
需求文档、软件开发计划、软件单元(包括代码及文档),测试用例和测试结果及其评审记录,编译清单和集成报告,已编译软件。
2.4.3-2
B
《配置状态报告》
应包括:
配置项数量、配置项状态、配置管理问题、已建立的基本
2.4.3-5
C
注:
递交等级A:
递交主机厂检查;B:
供应商内部检查;C建议具备
2.4.4问题解决管理
目的:
确保所有发现的软件问题都被识别、分析、管理、受控直到解决。
基本要求:
1)针对软件开发中可能遇到的问题,须制定相关的问题管理策略,明确需要纳入管理清单的问题类型、输入来源、以及参与问题解决的相关方;
2)按照问题管理策略,对发现的问题进行识别、记录和分类、汇总在统一的清单(参见输出物《软件问题跟踪表》)中;
3)按照项目节点或定期在项目会中对清单中的问题进行分析评估,由项目团队确定解决方案,明确责任人员和支持人员;
4)问题责任人或团队执行问题解决措施,完成必要的软件更改、测试和归档工作,其中涉及软件变更部分,参见2.4.5变更请求管理;
5)定义专门人员跟踪和推动问题的分析和解决,定期确认问题状态,直至问题关闭。
输出物:
名称
描述及内容
来源
递交等级
《软件问题跟踪表》
此表格是对软件问题描述、解决方案、实施结果等的记录。
应包括:
问题来源、问题描述、问题分类、提出时间、解决方案、责任人、工作进展、问题推进状态等信息
2.4.4-1~5
A
《软件变更请求跟踪表》
参见2.4.5变更请求管理
2.4.4-5
参见2.4.5
注:
递交等级A:
递交主机厂检查;B:
供应商内部检查;C建议具备
2.4.5变更请求管理
目的:
确保变更请求被管理、跟踪、并受控。
基本要求:
1)对团队内部和外部输入的软件变更请求进行识别,并记录在《变更请求清单》中;
2)需要识别软件变更请求与其他软件/非软件变更的之间的依赖关系,对由此带来的关联性工作做好安排;
3)当软件变更请求较多时,需要对不同变更的紧迫性和实施难度进行评估,从而设定合适的优先级;
4)变更正式实施前,须取得内部批准;特别来自主机厂的变更请求,需要得到主机厂的正式输入,变更的实施也须得到主机厂的批准;
5)变更开始后,项目团队需要跟踪必要的软件更改、测试和发布工作,对各个变更请求的状态须清晰明确,直到变更请求关闭;
6)所有的软件历史版本的详细信息,需要记录在《软件履历表》中,并在表中建立与供应商产线及上汽版本的对应关系。
输出物:
名称
描述及内容
来源
递交等级
《软件变更请求跟踪表》
此文件是对软件变更请求的识别和实现过程的记录。
应包括:
变更请求来源、内容描述、变更请求完成时间、计划实施时间、责任人、变更工作进度等。
2.4.5-1、5
B
《软件变更评估报告》
此文档是对软件变更内容的解读,以及实施对策分析,同时也是启动软件变更工作的关键输入项。
应包括对如下内容的分析:
变更涉及的软件模块、配置、硬件资源;开发、测试需要的相关设备、样件、人力资源;变更实施的优先级、时间计划、责任人。
2.4.5-2~4
C
《软件履历表》
此文件包含软件各版本的详细信息和变更历史。
应包括:
发布日期、版本名、项目、客户、变更内容描述、与产线版本的对应关系、与主机厂版本的对应关系
2.4.5-6
A
注:
递交等级A:
递交主机厂检查;B:
供应商内部检查;C建议具备
2.5软件验收
2.5.1产品发布
目的:
确保产品发布的过程可控。
基本要求:
1)制定发布计划,定义每次发布的时间节点及所包括的功能;
2)确保构建环境的一致性及确定性,并从配置项中构建,以确保发布的完整性;
3)完整功能软件最终发布前,客户参与系统验收测试评审并确认发布状态;
4)确保软件发布版本、纸质标签和EEPROM的版本信息的一致性;
版本信息包括:
硬件号、软件号、标定号、网络配置号、总成号。
输出物:
名称
描述及内容
来源
递交等级
《发布计划》
应包括:
每个项目节点发布时应包括的功能,需定义硬件、软件、文档等关联元素,以及映射客户需求到发布的版本
2.5.1