ASPICE-SYSSWE

2024-03-15 04:44
文章标签 aspice sysswe

本文主要是介绍ASPICE-SYSSWE,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

文章主要内容:

Automotive SPICE 过程参考模型

SYS.1 需求挖掘

过程ID

SYS.1

过程名称

需求挖掘

过程目的

需求挖掘过程的目的是:在产品和/或服务的整个生命周期内收集、处理和跟踪不断变化的利益相关方的需要和需求,从而建立一个需求基线,作为定义所需工作产品的基础。

过程成果

成功实施这个过程的结果如下:

1)建立了与利益相关方的持续沟通;

2)定义和基线化了约定的利益相关方需求;

3)建立了变更机制,以便基于利益相关方需要的变化,评估利益相关方需求的变更并将其纳入需求基线;

4)建立了持续监控利益相关方需要的机制;

5)建立了机制,以确保客户可以容易地判定其要求的状态和处置结果

6)识别了因技术或利益相关方需要的变化而引发的变更评估相关的风险管理其带来的影响

基本实践

SYS.1.BP1:获得利益相关方需求和要求

通过直接征求客户意见并通过评审客户业务提案(相关部分),目标运行硬件环境以及其它影响客户需求的文档来获取并定义利益相关方的需求和要求。[成果1,4]

注 1:需求挖掘可能需要客户和供应商的参与

注 2:约定的利益相关方需求和对变更的评估可基于可行性研究和/或成本和时间分析。

注 3:必须收集并记录保持每个客户需求可追溯性所需的信息。

SYS.1.BP2:理解利益相关方的期望

确保供应商和客户对每个需求有同样的理解。[成果 2]

注 4:与客户一起评审需求和要求有助于更好的理解客户需要和期望。参见过程 SUP.4 联合评审。

SYS.1.BP3:达成需求共识

获得所有相关方关于需求的明确协议,以便于开展工作。[成果2]

SYS.1.BP4:建立利益相关方需求基线

将利益相关方的需求正式化,并建立基线以便项目使用和依照利益相关方需要进行监控。供应商应确定利益相关方未说明的但对指定和预期用途有必要的需求,并将其包括在基线中。[成果23]

SYS.1.BP5:管理利益相关方的需求变更

依照利益相关方需求基线来管理所有利益相关方需求的变更,以确保识别技术和利益相关方需要的变化而带来的改进,以及确保受变化影响的人能够评估影响和风险,并启动适当的变更控制和缓解措施。[成果3.6]

注 5:需求变化可有不同的来源,例如技术和利益相关方需求的变化、法律约束。

注 6:在定义约定的利益相关方需求时所获的和所需的信息可能需要信息管理系统来进行管理,存储和引用.

SYS.1.BP6:建立客户_供应商查询沟通机制

给客户提供可以了解其需求变更状态和外置结果的方法,供应商能够以客户指定的语言和形式沟通包括数据在内的必要信息。[成果 5]

输出工作产品

08-19风险管理计划→[成果6]

08-20风险缓解计划→[成果6]

13-04沟通记录    →[成果1,4]

13-19评审记录    →[成果4,5]

13-21变更控制记录→[成果3,4]

15-01需求分析报告    →[成果2,3,6]

17-03利益相关方需求→[成果1,2]

SYS.2 系统需求分析

过程ID

SYS.2

过程名称

系统需求分析

过程目的

系统需求分析过程的目的是:将已定义的利益相关方需求转换成一组系统需求,以指导系统设计。

过程成果

成功实施这个过程的结果如下;

1)建立了一组定义系统需求;

2)对系统需求进行分类,并分析了其正确性和可验证性;

3)分析了系统需求对运行环境的影响;

4)定义了系统需求实施的优先级;

5)根据需要更新系统需求;

6)建立了利益相关方需求系统需求之间的一致性和双向可追溯性;

7)从成本、进度和技术影响来评估系统需求;

8)约定了系统需求,并与所有受影响方沟通

基本实践

SYS.2.BP1:定义系统需求。

使用利益相关方需求及其变更,以识别系统所需的功能和能力。在系统需求规范中定义功能性和非功能性系统需求。[成果 1,5,7]

注 1:影响功能和能力的应用参数是系统需求的一部分。

注 2:关于利益相关方需求的变更,适用SUP.10

SYS.2.BP2:结构化系统需求。

系统需求规范中结构化系统需求,例如:

  1. 按项目相关集群进行分组
  2. 按项目中逻辑顺序排序
  3. 基于项目相关准则进行分类
  4. 根据利益相关方需要进行优先级排序

[成果24]

注 3:优先级排序通常包括将功能性内容分配给已发布的计划。参见 SPL.2.BP1。

SYS.2.BP3:分析系统需求。

分析已定义的系统需求(包括它们的相互依赖关系),确保正确性技术可行性可验证性,并且支持风险识别分析成本、进度和技术影响。[成果 1,2,7]

注4:对成本和进度的影响分析有助于项目估算的调整。参见MAN.3.BP5

SYS.2.BP4:分析对运行环境的影响

识别定义的系统运行环境中其他要素之间的接口。分析系统需求对这些接口和运行环境的影响。 [成果 3,7]

SYS.2.BP5:制订验证准则。

对每一个系统需求制订验证准则,定义定性的和定量的措施用于需求验证。 [成果 2,7]

注 5:验证准则证明了需求可以在约定的约束范围内得到验证,并且通常被用作系统测试用例开发或其它证明符合系统需求的验证措施的输入。

注 6:测试不能覆盖的验证由 SUP.2 覆盖。

SYS.2.BP6:建立双向可追溯性。

建立利益相关方需求和系统需求之间的双向可追溯性。[成果 6]

注 7:双向可追溯性有助于覆盖率, 一致性和影响分析。

SYS.2.BP7:确保一致性。

确保利益相关方需求和系统需求之间的一致性。[成果 6]

注 8:一致性由双向可迫溯性支持,并可通过评审记录来证明。

SYS.2.BP8:沟通约定的系统需求。

与所有相关方沟通约定的系统需求及对系统需求的更新。[成果8]

输出工作产品

04-06 系统架构设计→[成果 1,2,3,45]

13-04沟通记录→[成果6]

13-19评审记录→[成果5]

13-22追溯记录→[成果5]

17-08 接口需求规范→[成果3]

过程ID

SYS.3

过程名称

系统架构设计

过程目的

建立系统架构,确定哪些需求分配给哪些系统元素,并根据定义的标准评估所设计的系统架构。

过程成果

  1. 提供所有系统的设计;
  2. 描述系统元素之间的相互关系;
  3. 描述系统元素与软件之间的相互关系;
  4. 详细说明每个必需系统元素的设计,需要考虑到以下内容:内存和容量的需求、硬件接口需求、用户接口需求、外部系统接口需求、性能需求、指令结构、安全及数据保护特性、系统参数设定、人工操作、可重用组件等
  5. 系统元素与需求之间的映射关系
  6. 描述系统组件运行模式(启动、停止、睡眠模式、诊断模式等)
  7. 描述在不同运行模式下各个系统组件之间依赖关系;
  8. 描述系统和系统组件的动态行为。

输出工作产品

1.     沟通记录;

2.     审查记录;

3.     跟踪记录

4.     系统架构设计

Note:系统架构设计

a. 已经定义了系统架构设计,并已经标识了系统元素;

b. 系统需求已经被分配给了系统元素;

c. 系统元素的每个接口已经定义;

d. 已经定义了系统的动态行为目标;

e. 在系统需求和系统架构设计之间已经建立了一致性和双向可追溯性;

f. 系统架构设计已经传达给受影响的各方并且达成了一致。

SYS.4 系统集成与集成测试

过程ID

SYS.4

过程名称

系统集成与集成测试

过程目的

系统集成与集成测试过程的目的是:集成系统项以产生与系统架构设计相一致的集成系统,并确保系统项得到测试,以提供集成的系统项符合系统架构设计(包括系统项之间的接口)的证据。

过程成果

成功实施这个过程的结果如下;

1) 制订了与项目计划发布计划系统架构设计相一致的系统集成策略,以集成系统项;

2) 制订了包括回归测试策略在内的系统集成测试策略,以测试系统项之间的交互;

3) 根据系统集成测试策略,制订系统集成测试规范,以适于提供集成的系统项符合系统架构设计(包括系统项之间的接口)的证据;

4) 根据集成策略将系统项集成为完整的集成系统;

5) 根据系统集成测试策略发布计划选择了系统集成测试规范中的测试用例;

6) 使用选定的测试用例测试了系统项之间的交互,并记录了系统集成测试结果;

7) 建立了系统架构设计的要素系统集成测试规范中的测试用例之间的一致性和双向可追溯性,并建立了测试用例和测试结果之间的双向可追溯性;

8) 总结了系统集成测试结果,并与所有受影响方沟通。

基本实践

SYS.4.BP1:制订系统集成策略

制订与项目计划和发布计划相一致的系统项集成策略。基于系统架构设计识别系统项,并定义其集成顺序。[成果 1]

SYS.4.BP2:制订包括回归测试策略在内的系统集成测试策略.

遵循集成策略,制订集成系统项的测试策略。该策略包括当系统项变更时对集成的系统项实施再测试的回归测试策略。[成果 2]

SYS.4.BP3:开发系统集成测试规范.

根据系统集成测试策略,开发系统集成测试规范(包括系统项的各集成步骤的测试用例)。测试规范应话于提供集成的系统项符合系统架构设计的证据。[成果 3]

注 1:系统要素之间的接口描述是系统集成测试用例的输入。

注 2:符合系统架构设计是指,定义的集成测试适于证明系统项之间的接口满足系统架构设计的规范。

注 3:系统集成测试用例可关注:

  1. 系统项之间的正确信号流
  2. 系统项之间信号流的时效性和时序依赖性
  3. 使用接口正确解释所有系统项的信号
  4. 系统项之间的动态交互

注 4:可使用仿真环境(例如:硬件在环仿真,车载网络仿真,数字原型)支持系统集成测试。

SYS.4.BP4:集成系统项

根据系统集成策略,将系统项集成为集成系统,[成果4]

注 5:系统集成可逐步集成系统项(例如:作为原型硬件的硬件要素,外设(传感器和执行器),机械和集成软件),以产生与系统架构设计相一致的系统。

SYS.4.BP5:选择测试用例.

从系统集成测试规范中选择测试用例,测试用例的选择应根据系统集成测试策略和发布计划具备足够的要盖率。[成果 5]

SYS.4.BP6:执行系统集成测试.

使用选定的测试用例执行系统集成测试。记录华成测试结果和日志。[成果6]

注 6:不符合项的处理,见SUP.9

SYS.4.BP7:建立双向可追溯性.

建立系统架构设计要素与系统集成测试规范中的测试用例之间的双向可追溯性,建立系统集成测试规范中的测试用例与系统集成测试结果之间的双向可追溯性。[成果7]

注 7:双向可追溯性有助于覆盖率、一致性和影响分析。

SYS.4.BP8:确保一致性.

确保系统架构设计要素与系统集成测试规范中的测试用例之间的一致性。[成果 7]

注 8:一致性由双向可追溯性支持,并可通过评审记录来证明。

SYS.4.BP9:总结和沟通结果

总结系统集成测试结果,并与所有受影响方沟通。[成果 8]

注 9:在总结中提供来自测试用例执行的所有必要信息,以便其他方判断结果。

输出工作产品

08-50 测试规范→[成果3,5]

08-52 测试计划→[成果 1,2]

11-06 系统→[成果4]

13-04 沟通记录→[成果 8]

13-19评审记录→[成果7]

13-22 追溯记录→[成果 7]

13-50测试结果→[成果6,8]

SYS.5 系统合格性测试

过程ID

SYS.5

过程名称

系统合格测试

过程目的

系统合格性测试过程的目的是:确保集成系统得到测试,以提供符合系统需求的证据,并确保系统可用于交付。

过程成果

成功实施这个过程的结果如下;

1)制订了与项目计划发布计划相一致的系统合格性测试策略(包括回归测试策略),用以测试已集成的系统。

2) 根据系统合格性测试策略,制订了已集成系统的系统合格性测试规范以适于提供符合系统需求的证据。

3) 根据系统合格性测试策略和发布计划,选择了系统合格性测试规范中的测试用例

4)使用选择的测试用例测试了已集成的系统,并记录了系统合格性测试的结果

5)建立了系统需求与系统合格性测试规范中测试用例之间的一致性和双向可追溯性,并建立了测试用例与测试结果之间的一致性和双向可追溯性。

6)总结了系统合格性测试结果,并与所有受影响方沟通

基本实践

SYS.5.BP1:制订包括回归测试策略在内的系统合格性测试策略。

制订项目计划发布计划相一致的系统合格性测试策略。该策略包括当系统项变更时,对已集成系统实施再测试的回归测试策略。[成果1]

SYS.5.BP2: 开发系统合格性测试规范。

根据系统合格性测试策略开发系统合格性测试规范(包括基于验证准则的测试用例)。该规范应适于提供集成系统符合系统需求的证据。[成果2]

SYS.5.BP3:选择测试用例。

从系统合格性测试规范中选择测试用例。对于系统合格性测试策略和发布计划而言,所选择的测试用例应具备足够的覆盖率。[成果3]

SYS.5.BP4: 测试已集成的系统。

使用已选择的测试用例测试已集成的系统。记录系统合格性测试的结果和日志。[成果4]

注 1:不符合项的处理,见 SUP.9。

SYS.5.BP5:建立双向可追溯性

建立系统需求与系统合格性测试规范中的测试用例之间的双向可追溯性。建立系统合格性测试规范中的测试用例与系统合格性测试结果之间的双向可追溯性。[成果5]

注 2:双向可追溯性有助于覆盖率、一致性和影响分析。

SYS.5.BP6:确保一致性。

确保系统需求和系统合格性测试规范中的测试用例之间的一致性。 [成果5]

注 3:一致性由双向可追溯性支持,并可通过评审记录来证明。

SYS.5.BP7:总结和沟通结果

总结系统合格性测试结果,并与所有受影响方沟通。[成果6]

注 4:在总结中提供来自测试用例执行的所有必要信息,以便其他方判断结果。

输出工作产品

08-50测试规范→[成果2,3]

08-52测试计划→[成果1]

13-04沟通记录→[成果6]

13-19评审记录→[成果5]

13-22追溯记录→[成果5]

13-50测试结果→[成果4,6]

SWE.1软件需求分析

过程ID

SWE.1

过程名称

软件需求分析

过程目的

软件需求分析过程的目的是:将系统需求中与软件相关的部分转化为一组软件需求。

过程成果

成功实施这个过程的结果如下:

1)定义了系统中分配给软件要素的软件需求及其接口;

2)将软件需求进行分类,并分析了其正确性和可验证性;

3)分析了软件需求对运行环境的影响;

4)定义了软件需求实现的优先级;

5)根据需要更新了软件需求:

6)在系统需求与软件需求之间、在系统架构设计与软件需求之间建立了一致性和双向可追溯性;

7)从成本、进度和技术影响评估软件需求;

8)约定了软件需求,并与所有受影响方沟通。

基本实践

SWE.1.BP1:定义软件需求。

使用系统需求系统架构及其变更识别软件所需的功能和能力。在软件需求规范中定义功能性非功能性软件需求。[成果1,5,7]

注1:影响功能和能力的应用参数是系统需求的一部分。

注2: 如果只有软件开发,系统需求和系统架构是指给定的运行环境(参见注5)。在这种情况下,应将利益相关方需求作为识别软件所需功能和能力以及识别影响软件功能和能力的应用参数的基础。

SWE.1.BP2:结构化软件需求。

在软件需求规范中结构化软件需求,例如:

  • 按项目相关集群进行分组,
  • 按项目中逻辑顺序排序,
  • 基于项目相关准则进行分类,
  • 根据利益相关方需要进行优先级排序。

[成果2, 4]

注3: 优先级排序通常包括将软件内容分配给已计划的发布。参见SPL.2.BP1。

SWE.1.BP3:分析软件需求

分析已定义的软件需求,包括其相互依赖关系,以确保正确性、技术可行性和可验证性并支持风险识别,分析对成本、进度和技术的影响。[成果2, 7]

SWE.1.BP4:分析对运行环境的影响

分析软件需求对系统要素接口运行环境的影响。[成果3, 7]

注5: 运行环境是指软件运行所在的系统(例如:硬件、操作系统等) 。

SWE.1.BP5:制订验证准则。

对每个软件需求制订验证准则,定义定性的和定量的措施以用于需求验证。 [成果2, 7]

注6: 验证准则证明了需求可以在约定的约束范围内得到验证,并且通常被用作软件测试用例开发或其他证明符合软件需求的验证措施的输入。

注7:测试不能覆盖的验证由SUP.2覆盖。

SWE.1.BP6:建立双向可追溯性。

建立系统需求软件需求之间的双向可追溯性,建立系统架构设计软件需求之间的双向追溯性。[成果 6]

注8: 应通过建立同时满足项目和组织要求的方法来避免冗余。

注9:双向可追溯性有助于覆盖率、一致性和影响分析。

SWE.1.BP7:确保一致性。

确保系统需求软件需求之间的一致性,确保系统架构软件需求之间的一致性。[成果 6]

注10:一致性由双向可追溯性支持,并可通过评审记录来证明。

注11:如果只有软件开发,必须确保利益相关方需求与软件需求之间的一致性和双向可追溯性。

SWE.1.BP8:沟通约定的软件需求。

与所有相关方沟通约定的软件需求及对软件需求的更新。[成果 8]

输出

工作产品

  1. 沟通记录    -> [成果8]
  2. 评审记录    -> [成果6]
  3. 追溯记录    -> [成果1,6]
  4. 变更控制记录-> [成果5,7]
  5. 分析报告    -> [成果2,3,4,7]
  6. 接口需求规范-> [成果1,3]
  7. 软件需求规范-> [成果1]
  8. 验证准则    -> [成果2]

Note:

分析报告Analysis Record:分析的内容、分析人、所采用的分析准则(选择的准则或采用的优先级计划、决策准则、质量准则)、记录结果(决定或选择的内容、选择的原因、做出的假定、潜在风险)、正确性分析的方面(完整性、可理解性、可测试性、可验证性、可行性、有效性、一致性、内容的充分性)

软件需求说明书(Software Requirement Specification):识别适用的标准、识别软件架构考虑及约束条件、识别必需的软件元素、识别软件元素之间的关联关系、考虑给出以下信息(必需的软件性能特性、必需的软件接口、必需的安全特性、数据库设计需求、必需的错误处理及属性恢复机制、必需的资源消耗特性)

SWE.2软件架构设计

过程ID

SWE.2

过程名称

软件架构设计

过程目的

软件架构设计过程的目的是:建立软件架构设计,识别将哪些软件需求分配给软件的哪些要素,并依照定义的准则来评估软件架构设计。

过程成果

成功实施这个过程的结果如下:

1)定义了识别软件要素的软件架构设计;

2)将软件需求分配给软件的要素;

3)定义了每个软件要素的接口;

4)定义了软件要素的动态行为和资源消耗目标;

5)建立了软件需求与软件架构设计之间的一致性和双向可追溯性;

6)约定了软件架构设计,并与所有受影响方沟通。

基本实践

SWE.2.BP1: 开发软件架构设计。

开发并文档化软件架构设计,该设计基于软件功能性需求非功能性需求定义软件要素。[成果1]

注1: 将软件分解为适当的各层级上的要素,直至软件架构设计的最低层级要素,即详细设计种描述的软件组件。

SWE.2.BP2:分配软件需求。

将软件需求分配到软件架构设计的要素。 [成果2]

SWE.2.BP3:定义软件要素的接口。

识别、开发并记录软件要素的接口。[成果3]

SWE.2.BP4:描述动态行为。

评估并记录软件要素的时序和动态交互,以满足系统所需的动态行为。[成果4]

注2:动态行为取决于运行模式(例如:启动、关机、正常模式、标定、诊断等)、进程及进程间相互通信、任务、线程、时间片、中断等。

注3: 在评估动态行为时,宜考虑目标平台和目标对象的潜在负载。

SWE.2.BP5:定义资源消耗目标。

在适当的层级上确定并文档化软件架构设计的所有相关要素的资源消耗目标。[成果4]

注4:资源消耗通常取决于资源,如:内存(ROM、RAM、外部/内部EEPROM或数据闪存)、CPU负载等。

SWE.2.BP6:评估备选的软件架构。

定义架构的评估准则。根据定义的准则评估备选的软件架构,记录被选定的软件架构的选择理由。[成果1,2,3,4,5]

注5:评估准则可包括质量特性(模块性、可维护性、可扩展性、可扩缩性、可靠性、安全security可实现性和易用性)以及开发-购买-重用分析的结果。

SWE.2.BP7:建立双向可追溯性。

建立软件需求与软件架构设计要素之间的双向可追溯性。 [成果5]

注6:双向可追溯性覆盖软件需求向软件架构设计的要素的分配。

注7:双向可追溯性有助于覆盖率、一致性和影响分析。

SWE.2.BP8:确保一致性。

确保软件需求与软件架构设计之间的一致性。[成果1,2,5,6]

注8:一致性由双向可追溯性支持,并可通过评审记录来证明。

SWE.2.BP9:沟通约定的软件架构设计。

与所有相关方沟通已约定的软件架构设计及对软件架构设计的更新。[成果6]

输出

工作产品

  1. 软件架构设计->[成果1,2,3,4,5]
  2. 沟通记录    ->[成果6]
  3. 评审记录    ->[成果5]
  4. 追溯记录    ->[成果5]
  5. 接口需求规范->[成果3]

Note

软件架构设计包括内容有:

a. 软件架构整体描述;

b. 包含任务结构的运行系统描述;

c. 确定任务与进程之间的通信;

d. 识别必需的软件元素;

e. 识别自主开发及供应方提供的代码;

f. 识别软件元素之间的关联及依赖关系;

g. 确定数据存储及灾备方案;

h. 描述不同模型系列或配置如何衍生出产品变体;

i. 描述软件的动态行为(启动、关闭、软件升级、错误处理、恢复);

j. 确定数据存储位置及数据损坏的预防办法;

k. 描述哪些数据是在什么情况下是持续存在的;

l. 还要充分考虑以下内容(软件必需的性能特性、软件必需的接口、软件必需的安全特性、数据库设计需求)

SWE.3软件详细设计和单元构建

过程ID

SWE.3

过程名称

软件详细设计和单元构建

过程目的

软件详细设计和单元构建过程的目的是:为软件组件提供经过评估的详细设计,并定义和生成软件单元

过程成果

成功实施这个过程的结果如下:

1)开发了描述软件单元的详细设计

2)定义了各软件单元的接口;

3)定义了软件单元的动态行为;

4) 建立了软件需求软件单元之间的一致性和双向可追溯性;

建立了软件架构设计软件详细设计之间的一致性和双向可追溯性;

建立了软件详细设计软件单元之间一致性和双向可追溯性;

5)约定了软件详细设计该设计与软件架构设计的关系,并和所有受影响方沟通;

6)生成了软件详细设计所定义的软件单元

过程成果

SWE.3.BP1: 开发软件详细设计。

开发软件架构设计中定义的各软件组件的详细设计,该设计基于软件功能性需求非功能性需求定义软件单元。[成果1]

SWE.3.BP2:定义软件单元的接口。

识别、定义和文档化各软件单元的接口。[成果2]

SWE.3.BP3:描述动态行为。

评估文档化相关软件单元之间的动态行为和交互。[成果3]

注1:并非所有的软件单元都有动态行为可描述。

SWE.3.BP4:评估软件详细设计。

互操作性、交互、关键性、技术复杂性、风险和可测试性方面对软件详细设计进行评估。[成果1,2,3,4]

注2:评估结果能作为软件单元验证的输入。

SWE.3.BP5:建立双向可追溯性。

建立软件需求软件单元之间的双向可追溯性。

建立软件架构设计软件详细设计之间的双向可追溯性。

建立软件详细设计软件单元之间的双向可追溯性。[成果4]

注3:对以上方法进行组合,覆盖项目和组织需要,避免冗余。

注4:双向可追溯性有助于覆盖率、一致性和影响分析。

SWE.3.BP6:确保一致性。

确保软件需求软件单元之间的一致性。

确保软件架构设计、软件详细设计及软件单元之间的一致性。[成果4]

注5:一致性由双向可追溯性支持,并可通过评审记录来证明。

SWE.3.BP7:沟通约定的软件详细设计。

与所有相关方沟通已约定的软件详细设计及对软件详细设计的更新。[成果5]

SWE.3.BP8:开发软件单元。

根据软件详细设计,开发并文档化各软件单元的可执行形式。[成果6]

输出

工作产品

  1. 软件详细设计->[成果1,2,3]
  2. 软件单元    ->[成果6]
  3. 沟通记录    ->[成果5]
  4. 评审记录    ->[成果4]
  5. 追溯记录    ->[成果4]

SWE.4软件单元验证

过程ID

SWE.4

过程名称

软件单元验证

过程目的

软件单元验证过程的目的是:验证软件单元,以提供软件单元符合软件详细设计非功能性软件需求的证据

过程成果

成功实施这个过程的结果如下:

1)制订了包括回归策略在内的软件单元验证策略,以验证软件单元;

2)根据软件单元验证策略,制订了软件单元验证准则,以适于提供软件单元符合软件详细设计及非功能性软件需求的证据;

3)根据软件单元验证策略及软件单元验证准则,验证了软件单元并记录了结果;

4)建立了软件单元、验证准则及验证结果之间的双向可追溯性和一致性;

5)总结了单元验证结果,并与所有受影响方沟通

基本实践

SWE.4.BP1: 制订包括回归策略在内的软件单元验证策略。

制订软件单元验证策略(包括软件单元变更时实施再验证的回归策略)。验证策略应定义如何提供软件单元符合软件详细设计和非功能性需求的证据。[成果1]

注1:可能的单元验证的方法包括静态/动态分析、代码评审、单元测试等。

SWE.4.BP2:制订单元验证准则。

根据验证策略,制订单元验证准则,以适于提供软件单元及其在组件内的交互符合软件详细设计及非功能性需求的证据。对单元测试而言,该准则应定义在单元测试规范中。[成果2]

注2:可能的单元验证准则包括单元测试用例、单元测试数据、静态验证、覆盖率目标及编码规范(如MISRA规则)。

注3:单元测试规范的实施形式可为:例如自动测试台上的脚本。

SWE.4.BP3:执行软件单元的静态验证。

使用已定义的验证准则来验证软件单元的正确性记录静态验证的结果。[成果3]

注4:静态验证可包括静态分析、代码评审、依照编码规范和指南的检查、及其它方法。

注5: 不符合项的处理,见SUP.9.

SWE.4.BP4:测试软件单元。

根据软件单元验证策略,使用单元测试规范测试软件单元记录测试结果和日志。[成果3]

注6: 不符合项的处理,见SUP.9.

SWE.4.BP5:建立双向可追溯性。

建立软件单元与静态验证结果之间的双向可追溯性。

建立软件详细设计与单元测试规范之间的双向可追溯性。

建立单元测试规范与单元测试结果之间的双向可追溯性。 [成果4]

注7:双向可追溯性有助于覆盖率、一致性和影响分析。

SWE.4.BP6:确保一致性。

确保软件详细设计与单元测试规范之间的一致性。[成果4]

注8:一致性由双向可追溯性支持,并可通过评审记录来证明。

SWE.4.BP7:总结并沟通结果。

总结单元测试结果和静态验证结果,并与所有受影响方沟通。[成果5]

注9:在总结中提供来自测试用例执行的所有必要信息,以便其他方得以判断结果。

输出

工作产品

  1. 测试规范->[成果2]
  2. 测试计划->[成果1]
  3. 沟通记录->[成果5]
  4. 评审记录->[成果3,4]
  5. 追溯记录->[成果4]
  6. 验证结果->[成果3,5]
  7. 测试结果->[成果3,5]
  8. 分析报告->[成果3]

Note

测试规范说明书 Test Specification:包括测试设计规格书、测试用例规格书、测试过程规格书、识别回归测试的测试用例;对于系统集成测试,要识别必需的系统要素,例如硬件要素、接线要素、参数设定和数据库等;识别系统元素集成必要的序列或排序

测试计划Test Plan:分级的测试计划、测试策略(黑盒/白盒测试、系统边界测试、回归测试策略等);如有必要,编制综合测试计划

验证结果及测试报告Verification Result and Test Report:验证checklist、通过的项、失败的项、待验证的项、发现的问题issue、风险分析、解决方案、结论、签名确认。测试报告按照要求,形成测试日志分级、形成异常报告、形成测试报告分级。

SWE.5软件集成和集成测试

过程ID

SWE.5

过程名称

软件集成和集成测试

过程目的

软件集成和集成测试过程的目的是:将软件单元集成到更大的软件项,直至与软件架构设计相一致的完整的集成软件,并确保集成的软件项得到测试,以提供集成的软件项符合软件架构设计(包括软件单元之间和软件项之间的接口)的证据。

过程成果

成功实施这个过程的结果如下:

1)制订了与项目计划、发布计划和软件架构设计相一致的软件集成策略,以集成软件项;

2)制订了包括软件回归测试策略在内的软件集成测试策略,以测试软件单元之间和软件项之间的交互;

3)根据软件集成测试策略,开发了软件集成测试规范,以适于提供集成的软件项符合软件架构设计(包括软件单元之间和软件项之间的接口)的证据

4)根据集成策略集成了软件单元和软件项直至完整的集成软件

5)根据软件集成测试策略和发布计划选择了软件集成测试规范中的测试用例

6)使用选定的测试用例测试了集成的软件项,并记录了测试结果

7)建立了软件架构设计要素软件集成测试规范中的测试用例之间的一致性和双向可追溯性,并建立了测试用例与测试结果之间的一致性和双向可追溯性;

8)总结了软件集成测试结果,并与所有受影响方沟通

基本实践

SWE.5.BP1:制订软件集成策略

制订与项目计划和发布计划相一致的软件项集成策略。基于软件架构设计识别软件项,并定义其集成顺序。[成果1]

SWE.5.BP2:制订包含回归测试策略在内的软件集成测试策略

遵循集成策略,制订集成的软件项的测试策略。该策略包括当软件项发生变更时,对集成的软件项实施再测试的回归测试策略。[成果2]

SWE.5.BP3:开发软件集成测试规范。

根据软件集成测试策略,为各集成的软件项开发测试规范(包括各集成的软件项的测试用例)。测试规范应适于提供集成的软件项符合软件架构设计的证据。[成果3]

注1:符合架构设计是指,定义的集成测试适于证明软件单元之间的接口以及软件项之间的接口满足软件架构设计的规范。

注2:软件集成测试用例可关注:

  • 软件项之间正确的数据流
  • 软件项之间数据流的时效和时序依赖性
  • 所有软件项接口的数据的正确解释
  • 软件想之间的动态交互
  • 与接口的资源消耗目标的符合性

SWE.5.BP4:集成软件单元和软件项。

根据软件集成策略,将软件单元集成到软件项,进而将软件项集成到集成软件。[成果4]

SWE.5.BP5:选择测试用例。

软件集成测试规范中选择测试用例。根据软件合格性测试策略发布计划选定的测试用例应具备足够的覆盖率。[成果5]

SWE.5.BP6:执行软件集成测试。

使用选定的测试用例执行软件集成测试,并记录集成测试结果和日志。 [成果6]

注4:不符合项的处理,见SUP.9

注5:可用硬件的调试接口或仿真环境(例如,软件在环仿真)支持软件集成测试。

SWE.5.BP7:建立双向可追溯性。

建立软件架构设计要素软件集成测试规范中的测试用例之间的双向可追溯性。

建立软件集成测试规范中的测试用例软件集成测试结果之间的双向可追溯性。[成果7]

注7:一致性由双向可追溯性支持,并可通过评审记录来证明。

SWE.5.BP8:确保一致性。

确保软件架构设计要素软件集成测试规范中的测试用例之间的一致性。[成果7]

注8:在总结中提供来自测试用例执行的所有必要信息,以便其他地方可以判断结果。

SWE.5.BP9:总结和沟通测试结果。

总结软件集成测试结果,并与所有受影响方沟通。[成果8]

注8:在总结中提供来自测试用例执行的所有必要信息,以便其他方可以判断结果。

输出

工作产品

  1. 软件项  ->[成果4]
  2. 集成软件->[成果4]
  3. 测试规范->[成果3,5]
  4. 测试计划->[成果1,2]
  5. 沟通记录->[成果8]
  6. 评审记录->[成果7]
  7. 追溯记录->[成果7]
  8. 测试结果->[成果6,8]
  9. 编译清单->[成果4,7]

Note

软件项,两大块,一个是集成的软件,一个是文档。集成的软件可分为:源代码、软件元素、可执行代码、配置文件;文档包括:描述和识别源代码、描述和识别软件元素、描述和识别配置文件、描述和识别可执行代码、描述软件生命周期状态、描述归档和发布标准、描述软件单元编译、描述软件组件的构建

集成的软件:多个软件组件的集合。这里的软件一般是针对某一特定ECU配置的一组可执行文件以及有关的文档和数据。

构建列表Build list: 识别软件应用系统的聚合、识别所需的系统元素(参数设定、宏程序库、基本数据、作业控制语言等)、识别软件编译时必需的顺序序列、识别输入输出资源库。

SWE.6软件合格性测试

过程ID

SWE.6

过程名称

软件合格性测试

过程目的

软件合格性测试的目的是: 确保集成软件得到测试,以提供符合软件需求的证据。

过程成果

成功实施这个过程的结果如下:

1)制订了与项目计划和发布计划相一致的包括回归测试策略在内的软件合格性测试策略,以测试集成软件;

2)根据软件合格性测试策略,开发了集成软件的软件合格性测试规范,以适于提供符合软件需求的证据;

3)根据软件合格性测试策略和发布计划,选择了软件合格性测试规范中的测试用例

4)使用选定的测试用例测试了集成软件,并记录了软件合格性测试结果

5)建立了软件需求软件合格性测试规范中的测试用例之间的一致性和双向可追溯性,

建立了测试用例测试结果之间的一致性和双向的可追溯性;

6)总结了软件合格性测试结果,并与所有受影响方沟通。

基本实践

SWE.6.BP1: 制订包括回归测试策略在内的软件合格性测试策略

制订与项目计划和发布计划相一致的软件合格性测试策略。该策略包括当软件项发生变更时,对集成软件实施再测试的回归测试策略。[成果1]

SWE.6.BP2: 开发软件合格性测试规范。

根据软件合格性测试策略,基于验证准则,开发包含测试用例在内的软件合格性测试规范。测试规范应适于提供集成软件符合软件需求的证据。[成果2]

SWE.6.BP3:选择测试用例。

从测试规范中选择测试用例。根据软件合格性测试策略发布计划,选定的测试用例应具备足够的覆盖率。[成果3]

SWE.6.BP4:测试集成软件。

使用选定的测试用例测试集成软件。记录测试结果和日志。[成果4]

注1:不符合项的处理,见SUP.9。

SWE.6.BP5:建立双向可追溯性。

建立软件需求软件合格性测试规范中的测试用例之间的双向可追溯性。

建立软件合格性测试规范中的测试用例软件合格性测试结果之间的双向可追溯性。[成果5]

注2:双向可追溯性有助于覆盖率、一致性和影响分析。

SWE.6.BP6:确保一致性。

确保软件需求软件合格性测试规范中的测试用例的一致性。 [成果5]

注3:一致性由双向可追溯性支持,并可通过评审记录来证明。

SWE.6.BP7:总结和沟通结果。

总结软件合格性测试结果,并与所有受影响方沟通。[成果6]

注4:在总结中提供来自测试用例执行的所有必要信息,以便其他方判断结果。

输出

工作产品

  1. 测试规范->[成果2,3]
  2. 测试计划->[成果1]
  3. 沟通记录->[成果6]
  4. 评审记录->[成果5]
  5. 追溯记录->[成果5]
  6. 测试结果->[成果4,6]

这篇关于ASPICE-SYSSWE的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/810833

相关文章

ISO26262和Aspice之间的关联

ASPICE 介绍: ASPICE(Automotive Software Process Improvement and Capability dEtermination)是汽车软件过程改进及能力评定的模型,它侧重于汽车软件的开发过程。ASPICE 定义了一系列的过程和活动,包括需求管理、软件设计、软件实现、软件测试、软件集成、软件配置管理、软件质量保证等方面。其目的是通过评估和改进汽车软件的

ASPICE和ISO 26262集成的应对方法

ASPICE和ISO 26262集成的应对方法: 1.明确集成目标和范围:在集成过程中,需要明确集成目标和范围,确保ASPICE和ISO 26262在不同领域的协同作用得到充分发挥。 2.统一术语和概念:在团队内部建立共同的语言和理解,将ISO 26262和ASPICE中的术语和概念进行对齐,以减少混淆和不一致。 3.制定统一的评估框架:结合ISO 26262和ASPICE的评估标准

ASPICE和ISO 26262集成的优势

ASPICE和ISO 26262集成的优势有以下几点: 流程成熟度和安全保证:ASPICE 3级标准标志着软件开发流程成熟且定义明确。与ISO 26262标准相结合,企业可为安全保证和系统化开发奠定更为坚实的基础。 这有助于确保安全活动的规范性和严谨性,降低出错和发生危险的可能性。流程校准:符合ASPICE标准的开发流程可与ISO 26262所要求的特定安全相关活动和工作成果进行整合和统一布

ASPICE、ISO 26262与ISO 21434在汽车行业中的核心共性与协同发展

ASPICE、ISO 26262和ISO 21434在汽车行业中都是重要的标准,它们各自关注不同的方面,但也有一些共性可以归纳如下: 1.目标定位: 三者都以提高汽车产品的安全性、可靠性和质量为目标。 ASPICE:旨在提高汽车软件开发过程的质量、安全性和效率。 ISO 26262:确保汽车电子系统对车辆操作的安全性,特别是安全相关电子电气系统。 ISO 21434:确保车辆网络

ASPICE的卓越性与价值--深入解析其优势与益处!

ASPICE,即汽车软件过程改进和能力确定(Automotive SPICE),是一套针对汽车行业的软件开发过程评估和改进的标准。它旨在帮助企业提高其软件开发过程的能力,进而提升软件产品的质量和可靠性。ASPICE的优势与好处主要体现在以下几个方面: 1. 提高软件过程能力 :ASPICE提供了一套全面的软件开发过程标准,使企业能够系统地建立、管理和改进其软件开发流程。通过遵循这些标准,企业可以

企业该如何实施ASPICE?

企业实施ASPICE以确保汽车软件和系统开发过程的质量,可以按照以下步骤进行: 一、明确目标和范围 确定评估的主要目的,例如过程改进、能力评定或合规性验证。 界定评估的范围,包括将涵盖的过程、项目和产品。 二、选择评估方法和工具 参考ASPICE提供的标准评估方法,同时根据企业自身需求和资源选择其他方法。 确定评估过程中所需的工具,如文档管理工具、数据分析工具等。 点击查看亚远景

Aspice介绍——测试流程

文章目录 ASPICE简介一、V字模型的示意二、测试领域2.1 SWE.6:软件合格性测试过程目的过程成果基本实践(BP) 2.2 SYS.4:系统集成和集成测试过程目的过程成果基本实践(BP) 2.3 SYS.5:系统合格性测试过程目的过程成果基本实践(BP) 三、测试类型之间的区别软件合格性测试系统集成测试系统合格性测试 四、追溯性和一致性 ASPICE简介 ASPIC

ASPICE与ISO 21434对汽车行业的影响

ASPICE,即汽车软件过程改进和能力确定,是一套针对汽车软件开发的国际标准。它强调软件开发过程的规范化和质量管理,通过定义一系列的过程要求和评估方法,帮助汽车制造商和供应商提高汽车电子电气系统的质量和可靠性,减少故障率和维修成本。同时,ASPICE还有助于提高开发效率,促进合作和协作,改进软件安全性,从而保护车辆和乘客的安全。 而ISO 21434则是针对车辆网络安全性的国际标准,旨在确保汽车

双标引领:汽车软件安全的ASPICE与ISO21434之道

随着汽车行业的飞速发展,尤其是智能化、网联化趋势的加剧,汽车软件开发的复杂性和安全性需求日益提升。在这样的背景下,ASPICE标准和ISO21434安全标准应运而生,为汽车软件的开发和管理提供了坚实的支撑。 ASPICE(Automotive Software Process Improvement and Capability Determination)是一种专门针对汽车软件开发过程的标准。

ISO 26262认证与ASPICE认证是汽车电子软件的双重保障

为了确保汽车电子软件的高品质与可靠性,ISO 26262与ASPICE两大认证标准应运而生,它们共同为汽车电子软件的开发提供了双重保障。  (要明确的是:在ASPICE行业中专业来说,ASPICE项目是没有认证,而只有评估。不过,为了方便沟通,人们常将这一评估过程称为认证。) 一、ISO 26262:功能安全的守护者 ISO 26262,全称《道路车辆功能安全》(Road vehic