汽车零部件软件开发及交付质量管理手册.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
升级会员 