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] 但是，如果該工具本身可以代替人工檢查，則必須合格。
| 一種 | 災難性的 | 66 | 25 | 10?9/H |
| 乙 | 危險的 | 65 | 14 | 10?7/H |
| C | 主要的 | 57 | 2 | 10?5/H |
| d | 次要的 | 28 | 2 | 10?3/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航空航天
參考
三、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
總結
以上是生活随笔為你收集整理的GJB5000A与DO178B/C简介及对比的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： c++整理--虚函数
- 下一篇： 程序员须学计算机语言,IT程序员入门必须