1. 软市首页
  2. 软件开发

GJB5000A与DO178B/C简介及对比

• 软件开发

文章目录

    • 一、GJB5000A
    • 模型定义
    • 模型简介
    • 来源
    • 模型框架
    • 技术特点
    • 内容
    • 二、DO-178B
    • 内容
    • 软件级别
    • 流程和文件
      • 规划
      • 发展
      • 确认
      • 配置管理
      • 质量保证
      • 认证联络人
    • 工具
    • 需求管理
    • 批评
    • 资源
    • 也可以看看
    • 参考
    • 三、GJB5000A与DO178B/C对比分析

一、GJB5000A

GJB5000A是一个产品开发模型（Product Development Model ,PDM），关注整个体系的问题，是一个过程改进参考模型，描述的是一组有效过程的特征，提供了一套最佳实践。

模型定义

软件成熟度模型的核心思想是，把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。

软件过程成熟度概念的引入，是为了解决路径的问题，是指一个特定软件过程得到清晰的定义、管理、测量、控制和有效的程度。

成熟度概念蕴含的意义在于组织能力提高是需要一个演化的进程，由一个从不成熟到相对成熟的过程。通过软件过程评估，可以帮助企业认识所处的位置，通过软件过程模型，可以帮助企业找到前进的目标。

模型简介

GJB5000A是一个产品开发模型（Product Development Model ,PDM），关注整个体系的问题，是一个过程改进参考模型，描述的是一组有效过程的特征，提供了一套最佳实践，它关注的是：生产率（Productivity）、性能（Performance）、成本（Costs）、相关方满意（Stakeholder satisfaction）。

GJB5000A是一个产品集，它包括：

  • 军用软件能力成熟度模型框架
  • 集成模型
  • 评估方法和材料
  • 各种培训
  • 术语

来源

2008年前： GJB 5000-2003《军用软件能力成熟度模型》

2009年开始：GJB 5000A-2008《军用软件研制能力成熟度模型》 [1]

模型框架

GJB5000A军用软件能力成熟度模型框架

军用软件能力成熟度模型框架：

  • 由5个成熟度等级来表达：每个成熟度等级由若干过程域组成；
  • 每个过程域由目标、执行方法组成。

即，成熟度等级中包含关键的过程域，每个过程域中具有一定的目标，以及为了达到这些目标必须要做到的行动步骤，即最佳实践。GJB5000A根本来源是CMMI-DEV V1.2，略有删减。

技术特点

GJB5000A与GJB5000相比：

  • 增加、修改并删除了多个术语和定义；
  • 由原标准18个关键过程域，修改至本标准的22个过程域。而且更加强化了工程过程方面的内容；
  • 改进了共用目标、共用实践等的说明；
  • 删除了原标准中的共同特征的概念，实践不再按其共同特征进行分类；
  • 删除了原标准的附录B（资料性附录）等。

GJB5000A与CMMI-DEV V1.2相比：

  • 去掉了系统工程部分
  • 去掉了硬件部分
  • 去掉了连续模型
  • 评价方法不同

内容

GJB5000A的22个过程域（PA***Process Area）可分为以下四类

a) 过程管理类

b) 项目管理类

c) 工程类 [2]

d) 支持类

一、过程管理类过程域如下：

a) 组织创新和部署（**OID:**Organizational Innovation and Deployment）

b) 组织过程定义（**OPD:**Organizational Process Definition）

c) 组织过程焦点（**OPF:**Organizational Process Focus）

d) 组织过程绩效（**OPP:**Organizational Process Performance）

e) 组织培训（**OT:**Organizational Training）

二、项目管理类过程域如下：

a) 集成项目管理（**IPM:**IntegratedProject Management）

b) 项目监控（**PMC:**ProjectMonitoring and Control）

c) 项目策划（**PP:**ProjectPlanning）

d) 定量项目管理（**QPM:**Quantitative Project Management）

e) 风险管理（**RskM:**RiskManagement）

f) 供方协议管理（**SAM:**SupplierAgreement Management）

三、工程类过程域：

a) 产品集成（**PI:**ProductIntegration ）

b) 需求开发（**RD:**RequirementDevelopment）

c) 需求管理（**ReqM:**RequirementManagement）

d) 技术解决方案（**TS:**TechnicalSolution）

e) 确认（**Val:**Validation）

f) 验证（**Ver:**Verification）

四、支持类过程域如下：

a) 配置管理（**CM:**ConfigurationManagement） [2]

b) 过程和产品质量保证（**PPQA:**Process and Product Quality Assurance）

c) 测量与分析（**MA:**Measurementand Analysis）

d) 决策分析和决定（**DAR:**DecisionAnalysis and Resolution）

e) 原因分析和决定（**CAR:**CauseAnalysis and Resolution）

GJB5000A各成熟度等级所含过程域

二、DO-178B

178B，机载系统和设备认证中的软件注意事项 是有关安全性的准则 安全至上 某些机载系统中使用的软件。尽管从技术上讲是一个准则，但这是一个 事实上的 开发标准 航空电子软件 系统，直到2012年被 DO-178C.

这 联邦航空局 将DO-178B用作其指导文件，以确定该软件在机载环境中是否能够可靠运行，[1] 当技术标准订单（TSO）规定要寻求认证时。在美国，将TSO引入适航审定过程中，并以DO-178B为扩展名，在美国《航空航天与航空技术》的标题14：航空和航天中得到了明确规定。 联邦法规法典 （CFR），也称为 联邦航空条例，第21部分，O部分。

它是由安全关键型RTCA SC-167工作组联合开发的。 RTCA 和WG-12 EUROCAE。 RTCA将文档发布为 RTCA / DO-178B，而EUROCAE将该文件发布为 ED-12B.

内容

  • 1 软件级别
  • 2 流程和文件
    • 2.1 规划
    • 2.2 发展
    • 2.3 确认
    • 2.4 配置管理
    • 2.5 质量保证
    • 2.6 认证联络人
  • 3 工具
  • 4 需求管理
  • 5 批评
  • 6 资源
  • 7 也可以看看
  • 8 参考
  • 9 外部链接

软件级别

这 软件级别，也称为 设计保证水平 （DAL）或 物品开发保证等级 （IDAL），如 ARP4754 (DO-178C 仅提到IDAL与软件级别同义[2]），由 安全评估程序 和 危害分析 通过检查系统中故障条件的影响。失效条件按其对飞机，机组人员和乘客的影响进行分类。

  • 灾难性的 –故障可能导致崩溃。安全飞行和降落飞机所需的关键功能的错误或丧失。
  • 危险的 –故障会给人身安全或性能造成很大的负面影响，或者由于人员身体不适或工作量增加而降低机组人员操作飞机的能力，或者对乘客造成严重或致命的伤害。 （重要）
  • 主要的 –故障很严重，但其影响要小于危险故障（例如，导致乘客不适而不是受伤）或显着增加机组人员的工作量（与安全相关）
  • 次要的 –故障明显，但比重大故障影响较小（例如，造成乘客不便或更改常规航班计划）
  • 没有效果 –故障不会影响安全，飞机运行或机组人员的工作量。

单独使用DO-178B并不能保证软件的安全性。设计中的安全属性和作为功能实现的安全属性必须接受其他强制性系统安全任务，以驱动和显示满足明确安全要求的客观证据。通常，按顺序分配IEEE STD-1228-1994软件安全计划，并按顺序完成软件安全分析任务（需求分析，顶层设计分析，详细设计分析，代码级分析，测试分析和变更分析）。这些软件安全任务和工件是过程中不可或缺的支持部分，用于危险严重性和DAL确定，并将其记录在系统安全评估（SSA）中。认证机构要求，DO-178B使用这些综合分析方法指定正确的DAL，以建立软件级别A-E。任何命令，控制和监视安全关键功能的软件都应获得最高的DAL-A级。正是软件安全分析推动了系统安全评估，从而确定了DAL决定了DO-178B中的适当严格程度。系统安全评估与诸如以下方法相结合 SAE ARP 4754A 确定缓解后的DAL，并且如果冗余，设计安全功能和其他缓解风险的体系结构形式对安全分析的要求较高，则可以确定降低DO-178B软件级别的目标。因此，DO-178B的中心主题是在建立必要的安全要求之后进行设计保证和验证。

要满足的目标数量（最终是独立的）由软件级别A-E决定。短语“具有独立性”是指职责分离，其中通过软件开发团队的“独立性”确保验证和确认过程的客观性。对于必须满足独立性的目标，验证项目（例如要求或源代码）的人员可能不是项目的作者，并且必须明确记录这种分离。[3] 在某些情况下，自动化工具可能等同于独立性。[4] 但是，如果该工具本身可以代替人工检查，则必须合格。

等级 失败条件 目标[5] 具有独立性 失败率
一种 灾难性的 66 25 10/H
乙 危险的 65 14 10/H
C 主要的 57 2 10/H
d 次要的 28 2 10/H
E 没有效果 0 0 不适用

流程和文件

根据软件级别，过程旨在支持目标（A至D – E级不在DO-178B的范围之内）。在DO-178B中，过程被描述为工作的抽象领域，而实际项目的计划者则要定义和记录如何执行过程的细节。在真实项目中，必须显示将在流程环境中进行的实际活动以支持目标。这些活动由项目计划人员定义为计划过程的一部分。

DO-178B的这种基于目标的特性在遵循以下不同样式时提供了很大的灵活性 软件生命周期。一旦定义了流程中的活动，通常期望项目尊重其流程中所记录的活动。此外，根据DO-178B，过程（及其具体活动）必须具有明确定义的进入和退出标准，并且项目必须表明在执行过程中的活动时遵守了这些标准。

DO-178B的流程和进入/退出标准的灵活性使得首次实施变得困难，因为这些方面是抽象的，并且没有开展活动的“基础”。 DO-178B的意图不是规定性的。实际项目中定义这些方面的方式有很多可能并且可以接受。公司首次尝试根据此标准开发民用航空电子系统，并为DO-178B培训和咨询创造了一个利基市场，这可能很难。

对于基于DO-178B的通用过程， 视觉总结 提供的内容包括FAA在“软件和复杂电子硬件的指导和职位帮助”中定义的参与阶段（SOI）。

规划

系统需求通常输入到整个项目中。

D级软件不需要最后3个文档（标准）。

发展

DO-178B并非旨在作为软件开发标准；它是使用一组任务来满足目标和严格级别的软件保证。

开发过程输出文件：

  • 软件需求数据（SRD）
  • 软件设计说明（SDD）
  • 源代码
  • 可执行的 目标代码

通常需要从系统要求到所有源代码或可执行目标代码的可追溯性（取决于软件级别）。

通常使用 软件开发过程:

  • 瀑布模型
  • 螺旋模型
  • V型

确认

通过此过程生成的文档输出：

  • 软件验证 案件和程序（SVCP）
  • 软件验证结果（SVR）：
    • 审查所有要求，设计和规范
    • 测试可执行文件 目标代码
    • 代码覆盖率 分析

通常需要对所有代码以及从测试，结果到所有要求的可追溯性进行分析（取决于软件级别）。

此过程通常还涉及：

  • 基于需求的测试工具
  • 代码覆盖率 分析仪工具

在此过程中执行的测试的其他名称可以是：

  • 单元测试
  • 整合测试
  • 黑盒子 和 验收测试

配置管理

维护的文件 配置管理 过程：

  • 软件配置索引（SCI）
  • 软件生命周期 环境配置索引（SECI）

此过程处理问题报告，更改和相关活动。配置管理过程通常提供以下内容的存档和修订标识：

  • 源代码开发环境
  • 其他开发环境（例如测试/分析工具）
  • 软件整合工具
  • 所有其他文档，软件和硬件

质量保证

质量保证过程的输出文件：

  • 软件 质量保证 记录（SQAR）
  • 软件符合性审查（SCR）
  • 软件完成摘要（SAS）

此过程进行检查和审核，以证明符合DO-178B。与证书颁发机构的接口也由质量保证过程处理。

认证联络人

通常是 指定工程代表 （DER）审查技术数据，作为提交给FAA批准的一部分。

工具

软件可以在DO-178B流程中实现自动化，协助或以其他方式处理或帮助。用于DO-178B开发的所有工具必须是认证过程的一部分。生成嵌入式代码的工具是 有资格作为开发工具，其约束与嵌入式代码相同。必须使用用于验证代码的工具（模拟器，测试执行工具，覆盖率工具，报告工具等）。 有资格作为验证工具，整个过程要轻得多， 黑匣子测试 该工具。

可以将第三方工具作为验证工具，但必须按照DO-178流程开发开发工具。提供这类工具的公司 床 受到认证机构的审核，他们可以完全访问源代码，规范和所有认证工件。

在此范围之外，任何使用过的工具的输出都必须由人工手动验证。

  • 一种 问题管理 工具可以提供变更的可追溯性。
  • 可以从日志中创建SCI和SECI 修订控制 工具。

需求管理

需求可追溯性与记录需求的生命周期有关。应该可以追溯到每个需求的来源，因此，对需求所做的每次更改都应记录在案，以实现可追溯性。甚至在部署和使用实现的功能之后使用需求也应该是可追溯的。

批评

VDC Research指出，DO-178B已变得“过时”，因为它无法很好地适应当今工程师的需求和偏好。在同一份报告中，他们还指出 DO-178C 似乎已准备好解决此问题。[需要引用]

资源

  • 远的 第23/25条§1301/§1309
  • 远的 第27/29部分
  • 交流电 23/25.1309
  • 交流电 20-115B
  • RTCA / DO-178B
  • FAA订单8110.49软件批准指南

也可以看看

  • DO-178C
  • 航空电子软件
  • ARP4761 （安全评估程序）
  • ARP4754 （系统开发过程）
  • DO-248B （澄清DO-178B的最终报告）
  • DO-254 （类似于DO-178B，但用于硬件）
  • 需求管理 （太笼统而不能“直接应用于” DO-178B）
  • IEC 61508
  • ISO / IEC 12207 （软件生命周期过程开发标准）
  • ED-153 （ANS软件安全保证准则）
  • 修改的条件/决策范围
  • DO-178B航空航天

参考

  1. ^ 美国联邦航空局（FAA）咨询通告20-115B
  2. ^ RTCA / DO-178C“机载系统和设备认证中的软件注意事项”，第1页。 116.“一个例子是术语“项目开发保证水平”（IDAL），对于软件而言，它与术语“软件水平”同义。
  3. ^ RTCA / DO-178B“机载系统和设备认证中的软件注意事项”，第1页。 82
  4. ^ RTCA / DO-178B“机载系统和设备认证中的软件注意事项”，第82页
  5. ^ RTCA / DO-178B“机载系统和设备认证中的软件注意事项”，附件A

三、GJB5000A与DO178B/C对比分析

可以参考下面几篇文章：

满足GJB 5000A认证和DO-178C要求的航空软件研制体系建设

GJB5000A与DO-178B/C的综合应用研究

DO-178B与GJB 5000A对比分析研究

https://baike.baidu.com/item/GJB5000A/6106590

https://upwikizh.top/wiki/DO-178B

来源：小熊coder

声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！

上一篇 2022年4月23日
下一篇 2022年4月23日

相关推荐

首页
软件超市
企服市场
会员中心