RTCA/DO-178Cの詳細
～満たすべきObjectivesとツール資格について～
平成２５年１２月２６日
ＭＨＩエアロスペースシステムズ株式会社
1.1 概要
DO-178Cとは、そのタイトルが「 Software Considerations in Airborne Systems
and Equipment Certification 」であり、RTCA（航空無線技術委員会：米国の
航空関連団体）が2011年12月13日にC改訂された航空機搭載システム・機
器を対象としたソフトウェア開発のガイドラインである。
FAA（連邦航空局）がデジタル・コンピュータ・ソフトウェアを認証するにあたり、
適用を奨励している。
2013年7月にFAAによりAC20-115Cが発行され、DO-178C及びその補足規
格であるDO-330、331、332、333の適用が定められた。
http://www.masc.co.jp1.2 上位文書との関連
System Development Process
ARP4754
Safety Assessment Process
ARP4761
H/W Development Life Cycle
DO-254
S/W Development Life Cycle
DO-178
Aircraft
Function
Functional
System
Requirements → ← Derived Requirements ← Implementations System Design Safety Requirement Aircraft System Development Process H/W and S/W Life-Cycle Process http://www.masc.co.jp1.4 ソフトウェアレベル
故障状態のカテゴリ
内
容
ソフトウェア
レベル
壊滅的
（
Catastrophic）
安全な飛行の続行と着陸が不可能とな
る故障状態
A
危険
/非常に重大
（
Hazardous/Severe-Major）
航空機の能力または悪状況により乗務
員の対応能力が任務遂行不可まで低下
し、生命にかかわる負傷者が出るような
故障状態
B
重大
（
Major）
航空機の能力または悪状況により乗務
員の対応能力が任務遂行の妨げになる
ほど低下し、乗員乗客が不快症状とな
るような故障状態
C
軽微
（
Minor）
航空機の安全が著しく低下することはな
く、乗員は対応能力範囲内で任務を遂
行できるような故障状態
D
影響なし
（
No Effect）
航空機の操縦能力や乗員負荷に影響し
ない故障状態
E
http://www.masc.co.jp1.5
ソフトウェア・ライフサイクル・プロセス
ソフトウェア計画プロセス
(Software Planning Process)
DO-178Cでは、ソフトウェアのプロセスとして３プロセスを定義している。
ソフトウェア開発プロセス
(Software Development Process)
インテグラルプロセス
(Integral Process)
1.6 ソフトウェア開発プロセス
ソフトウェア開発プロセス
(Software Development Process)
ソフトウェア要求プロセス(Software Requirements Process)
ソフトウェア設計プロセス(Software Development Process)
ソフトウェアコーディングプロセス(Software Coding Process)
統合プロセス(Integration Process)
1.7 インテグラルプロセス
インテグラルプロセス
(Integral Process)
ソフトウェア検証プロセス(Software Verification Process)
ソフトウェア形態管理プロセス(Software Configuration Management Process)
ソフトウェア品質保証プロセス(Software Quality Assurance Process)
認証連絡調整プロセス(Certification Liaison Process)
1.7 インテグラルプロセス
インテグラルプロセス
(Integral Process)
ソフトウェア検証プロセス(Software Verification Process)
ソフトウェア形態管理プロセス(Software Configuration Management Process)
ソフトウェア品質保証プロセス(Software Quality Assurance Process)
認証連絡調整プロセス(Certification Liaison Process)
今回の焦点
1.8 各プロセスの関係(その1)
インテグラルプロセス(Integral Process)
ソフトウェア検証プロセス
(Software Verification Process)
ソフトウェア形態管理プロセス
(Software Configuration
Management Process)
ソフトウェア品質保証プロセス
(Software Quality Assurance Process)
認証連絡調整プロセス
(Certification Liaison Process)
Testing
ソフトウェア計画プロセス
(Software Planning Process)
ソフトウェア開発プロセス
(Software Development Process)
計画
成果物
計画
標準
検証結果
Reviews/Analyses
http://www.masc.co.jp1.8 各プロセスの関係(その2)
ソフトウェア開発プロセスとソフトウェア検証プロセスの関係
ソフトウェア開発プロセス ソフトウェア検証プロセス
1.9 ソフトウェアライフサイクルデータ
No
名
称
参照項番1
ソフトウェア認証計画(Plan for Software Aspects of Certification)
2.3-1
2
ソフトウェア開発計画(Software Development Plan)
2.3-2
3
ソフトウェア検証計画(Software Verification Plan)
2.3-3
4
ソフトウェア形態管理計画(Software Configuration Management Plan)
2.3-4
5
ソフトウェア品質保証計画(Software Quality Assurance Plan)
2.3-5
6
ソフトウェア要求標準(Software Requirements Standards)
2.3-6
7
ソフトウェア設計標準(Software Design Standards)
2.3-7
8
ソフトウェアコード標準(Software Code Standards)
2.3-8
9
ソフトウェア要求データ(Software Requirements Data)
3.2.3
10
設計記述(Design Description)
3.3.3
11
ソースコード(Source Code)
3.4.3
12
実行可能オブジェクトコード(Executable Object Code)
3.5.3-1
13
ソフトウェア検証ケース・手順(Software Verification Cases and Procedures)
5.2-1
14
ソフトウェア検証結果(Software Verification Results)
5.2-2
15
ソフトウェアライフサイクル環境形態索引
(Software Life Cycle Environment Configuration Index)
6.4-1
16
ソフトウェア形態索引(Software Configuration Index)
6.4-2
17
不適合報告(Problem Reports)
6.4-3
18
ソフトウェア形態管理記録(Software Configuration Management Records)
6.4-4
19
ソフトウェア品質保証記録(Software Quality Assurance Records)
7.4
20
ソフトウェア完了報告(Software Accomplishment Summary)
8.4
21
トレースデータ(Trace Data)
5.2-3
11
1.10 達成すべきObjectives
DO-178CはObjective Orientedな規格と言われている。
ソフトウェアレベルに応じて達成すべきObjectivesが定義されている。
Table Process Software Level
A B C D
A-1 Software Planning Process
7
7
7
2
A-2 Software Development Process7
7
7
4
A-3 Verification of Outputs of Software Requirements Process7(3)
7(3)
6
3
A-4 Verification of Outputs of Software Design Process13(6)
13(3)
9
1
A-5 Verification of Outputs of Software Coding & Integration
Process
9(5)
9(3)
8
1
A-6 Testing of Outputs of Integration Process
5(2)
5(1)
5
3
A-7 Verification of Verification Process Results9(9)
7(3)
6
1
A-8 Software Configuration Management Process6
6
6
6
A-9 Software Quality Assurance Process5(5)
5(5)
5(5)
2(2)
A-10 Certification Liaison Process3
3
3
3
Total
71(30)
69(18)
62(5)
26(2)
1.10 達成すべきObjectives
DO-178CはObjective Orientedな規格と言われている。
ソフトウェアレベルに応じて達成すべきObjectivesが定義されている。
Table Process Software Level
A B C D
A-1 Software Planning Process
7
7
7
2
A-2 Software Development Process7
7
7
4
A-3 Verification of Outputs of Software Requirements Process7(3)
7(3)
6
3
A-4 Verification of Outputs of Software Design Process13(6)
13(3)
9
1
A-5 Verification of Outputs of Software Coding & Integration
Process
9(5)
9(3)
8
1
A-6 Testing of Outputs of Integration Process
5(2)
5(1)
5
3
A-7 Verification of Verification Process Results9(9)
7(3)
6
1
A-8 Software Configuration Management Process6
6
6
6
A-9 Software Quality Assurance Process5(5)
5(5)
5(5)
2(2)
A-10 Certification Liaison Process3
3
3
3
Total
71(30)
69(18)
62(5)
26(2)
43(25) 41(13) 34 9
ソフトウェア開発プロセスと検証プロセス
(Software Development Process & Verification Process)
3.1 プロセスフロー
ソフトウェア開発プロセス
ソフトウェア検証プロセス(レビュー／分析)
3.2.2 レビュー／分析（上位要求）
目的 活動 適用 成果物 形態管理 カテゴリ 内容 参照 参照 A B C D 名称 参照 A B C D 1 ソフトウェア上位要求はシステム要 求を遵守している 6.3.1a 6.3.1 ● ● ○ ○ ソフトウェア検証 結果 11.14 ② ② ② ② 2 ソフトウェア上位要求は正確であり、 一貫している 6.3.1b 6.3.1 ● ● ○ ○ ソフトウェア検証 結果 11.14 ② ② ② ② 3 ソフトウェア上位要求はターゲット コンピュータと整合している 6.3.1c 6.3.1 ○ ○ ソフトウェア検証 結果 11.14 ② ② 4 ソフトウェア上位要求は検証可能 である 6.3.1d 6.3.1 ○ ○ ○ ソフトウェア検証 結果 11.14 ② ② ② 5 ソフトウェア上位要求は標準に準 拠している 6.3.1e 6.3.1 ○ ○ ○ ソフトウェア検証 結果 11.14 ② ② ② 6 ソフトウェア上位要求はシステム要 求にトレース可能である 6.3.1f 6.3.1 ○ ○ ○ ○ ソフトウェア検証 結果 11.14 ② ② ② ② 7 アルゴリズムが正確である 6.3.1g 6.3.1 ● ● ○ ソフトウェア検証結果 11.14 ② ② ②○：実施、●：独立した組織が実施
①：カテゴリ１、②：カテゴリ２
Compliance
Accuracy & Consistency
HW Compatibility
Verifiability
Conformance
Traceability
Algorithm Accuracy
http://www.masc.co.jp3.3.2 レビュー／分析（下位要求）
目的 活動 適用 成果物 形態管理 カテゴリ 内容 参照 参照 A B C D 名称 参照 A B C D 1 ソフトウェア下位要求はソフトウェア上 位要求を遵守している 6.3.2a 6.3.2 ● ● ○ ソフトウェア検証 結果 11.14 ② ② ② 2 ソフトウェア下位要求は正確であり一 貫性がある 6.3.2b 6.3.2 ● ● ○ ソフトウェア検証 結果 11.14 ② ② ② 3 ソフトウェア下位要求はターゲットコン ピュータと整合している 6.3.2c 6.3.2 ○ ○ ソフトウェア検証 結果 11.14 ② ② 4 ソフトウェア下位要求は検証可能である 6.3.2d 6.3.2 ○ ○ ソフトウェア検証結果 11.14 ② ② 5 ソフトウェア下位要求は標準に準拠し ている 6.3.2e 6.3.2 ○ ○ ○ ソフトウェア検証 結果 11.14 ② ② ② 6 ソフトウェア下位要求はソフトウェア上 位要求にトレース可能である 6.3.2f 6.3.2 ○ ○ ○ ソフトウェア検証 結果 11.14 ② ② ② 7 アルゴリズムは正確である 6.3.2g 6.3.2 ● ● ○ ソフトウェア検証 結果 11.14 ② ② ②○：実施、●：独立した組織が実施
①：カテゴリ１、②：カテゴリ２
Compliance
Accuracy & Consistency
HW Compatibility
Verifiability
Conformance
Traceability
Algorithm Accuracy
http://www.masc.co.jp3.3.2 レビュー／分析（ソフトウェア構造）
目的 活動 適用 成果物 形態管理 カテゴリ 内容 参照 参照 A B C D 名称 参照 A B C D 8 ソフトウェア構造はソフトウェア上 位要求と整合している 6.3.3a 6.3.3 ● ○ ○ ソフトウェア検証 結果 11.14 ② ② ② 9 ソフトウェア構造は一貫性がある 6.3.3b 6.3.3 ● ○ ○ ソフトウェア検証 結果 11.14 ② ② ② 10 ソフトウェア構造はターゲットコン ピュータと整合している 6.3.3c 6.3.3 ○ ○ ソフトウェア検証 結果 11.14 ② ② 11 ソフトウェア構造は検証可能であ る 6.3.3d 6.3.3 ○ ○ ソフトウェア検証 結果 11.14 ② ② 12 ソフトウェア構造は標準に準拠し ている 6.3.3e 6.3.3 ○ ○ ○ ソフトウェア検証 結果 11.14 ② ② ② 13 ソフトウェアパーティショニングの 完全性が確認されている 6.3.3f 6.3.3 ● ○ ○ ○ ソフトウェア検証 結果 11.14 ② ② ② ②○：実施、●：独立した組織が実施
①：カテゴリ１、②：カテゴリ２
Compatibility
Consistency
HW Compatibility
Verifiability
Conformance
Partition Integrity
http://www.masc.co.jp目的 活動 適用 成果物 形態管理 カテゴリ 内容 参照 参照 A B C D 名称 参照 A B C D 1 ソースコードはソフトウェア下位要 求を遵守している 6.3.4a 6.3.4 ● ● ○ ソフトウェア検証 結果 11.14 ② ② ② 2 ソースコードはソフトウェア構造を 遵守している 6.3.4b 6.3.4 ● ○ ○ ソフトウェア検証 結果 11.14 ② ② ② 3 ソースコードは検証可能である 6.3.4c 6.3.4 ○ ○ ソフトウェア検証 結果 11.14 ② ② 4 ソースコードは標準に準拠してい る 6.3.4d 6.3.4 ○ ○ ○ ソフトウェア検証 結果 11.14 ② ② ② 5 ソースコードはソフトウェア下位要 求にトレース可能である 6.3.4e 6.3.4 ○ ○ ○ ソフトウェア検証 結果 11.14 ② ② ② 6 ソースコードは正確であり一貫性 がある 6.3.2f 6.3.4 ● ○ ○ ソフトウェア検証 結果 11.14 ② ② ②
3.4.2 レビュー／分析（ソースコード）
○：実施、●：独立した組織が実施
①：カテゴリ１、②：カテゴリ２
Compliance
Compliance
Verifiability
Conformance
Traceability
Accuracy & Consistency
3.5.2 レビュー／分析
目的 活動 適用 成果物 形態管理 カテゴリ 内容 参照 参照 A B C D 名称 参照 A B C D 7 ソフトウェア統合プロセスのア ウトプットは完全であり、正確で ある 6.3.5.a 6.3.5 ○ ○ ○ ソフトウェア検証 結果 11.14 ② ② ② 8 パラメータデータ項目ファイル は正確であり、完全である 6.6.a 6.6 ● ● ○ ○ ソフトウェア検証 ケース・手順 ソフトウェア検証 結果 11.13 11.14 ① ② ① ② ① ② ① ② 9 パラメータデータ項目ファイル の検証が達成されている 6.6.b 6.6 ● ● ○ ソフトウェア検証 結果 11.14 ② ② ②○：実施、●：独立した組織が実施
①：カテゴリ１、②：カテゴリ２
Complete & Correct
Correct & Complete
Verification
3.6 開発プロセスにおける検証
System
Requirements
High-Level
Requirements
Software
Architecture
Low-Level
Requirements
Source Code
Executable
Parameter Data
ソフトウェア開発プロセスにおける検証プロセス(レビュー/分析)をまとめると・・・
3.6 開発プロセスにおける検証
System
Requirements
High-Level
Requirements
Software
Architecture
Low-Level
Requirements
Source Code
Executable
A-3.2 Accuracy & Consistency
A-3.3 HW Compatibility
A-3.4 Verifiability
A-3.5 Conformance
A-3.7 Algorithm Accuracy
A-4.8 Compatibility
A-4.2 Accuracy & Consistency
A-4.3 HW Compatibility
A-4.4 Verifiability
A-4.5 Conformance
A-4.7 Algorithm Accuracy
A-3.1 Compliance
A-3.6 Traceability
A-4.1 Compliance
A-4.6 Traceability
A-4.9 Consistency
A-4.10 HW Compatibility
A-4.11 Verifiability
A-4.12 Conformance
A-4.13 Partition Integrity
A-5.7 Complete & Correct
A-5.3 Verifiability
A-5.4 Conformance
A-5.6 Accuracy & Consistency
Parameter Data
A-5.1 Compliance
A-5.6 Traceability
A-5.9 Verification
A-5.2 Compliance
A-5.8 Correct & Complete
ソフトウェア開発プロセスにおける検証プロセス(レビュー/分析)をまとめると・・・
3.6 開発プロセスにおける検証
ソフトウェアレベルAとBの場合・・・
System
Requirements
High-Level
Requirements
Software
Architecture
Low-Level
Requirements
Source Code
Executable
A-3.2 Accuracy & Consistency
A-3.3 HW Compatibility
A-3.4 Verifiability
A-3.5 Conformance
A-3.7 Algorithm Accuracy
A-4.8 Compatibility
A-4.2 Accuracy & Consistency
A-4.3 HW Compatibility
A-4.4 Verifiability
A-4.5 Conformance
A-4.7 Algorithm Accuracy
A-3.1 Compliance
A-3.6 Traceability
A-4.1 Compliance
A-4.6 Traceability
A-4.9 Consistency
A-4.10 HW Compatibility
A-4.11 Verifiability
A-4.12 Conformance
A-4.13 Partition Integrity
A-5.7 Complete & Correct
A-5.3 Verifiability
A-5.4 Conformance
A-5.6 Accuracy & Consistency
Parameter Data
A-5.1 Compliance
A-5.6 Traceability
A-5.9 Verification
A-5.2 Compliance
A,B共に第三者が実施 Aは第三者が実施A-5.8 Correct & Complete
3.6 開発プロセスにおける検証
System
Requirements
High-Level
Requirements
Software
Architecture
Low-Level
Requirements
Source Code
Executable
A-3.2 Accuracy & Consistency
A-3.4 Verifiability
A-3.5 Conformance
A-3.7 Algorithm Accuracy
A-4.8 Compatibility
A-4.2 Accuracy & Consistency
A-4.5 Conformance
A-4.7 Algorithm Accuracy
A-3.1 Compliance
A-3.6 Traceability
A-4.1 Compliance
A-4.6 Traceability
A-4.9 Consistency
A-4.12 Conformance
A-4.13 Partition Integrity
A-5.7 Complete & Correct
A-5.3 Verifiability
A-5.4 Conformance
A-5.6 Accuracy & Consistency
Parameter Data
A-5.1 Compliance
A-5.6 Traceability
A-5.9 Verification
A-5.2 Compliance
A-5.8 Correct & Complete
http://www.masc.co.jp
3.6 開発プロセスにおける検証
System
Requirements
High-Level
Requirements
Software
Architecture
Low-Level
Requirements
Source Code
Executable
A-3.2 Accuracy & Consistency
A-3.1 Compliance
A-3.6 Traceability
A-4.13 Partition Integrity
Parameter Data
A-5.8 Correct & Complete
http://www.masc.co.jp
3.7 トレーサビリティ
以下の双方向のトレーサビリティを示すトレースデータが作らなければなら
ない。
(1) ソフトウェアに割り当てられたシステム要求 ⇔ ソフトウェア上位要求
(2) ソフトウェア上位要求 ⇔ ソフトウェア下位要求
(3) ソフトウェア下位要求 ⇔ ソースコード
ソフトウェア開発プロセスにおけるトレーサビリティ
http://www.masc.co.jp4. ソフトウェアテストプロセス
ソフトウェアテストプロセス
(Software Test Process)
4.2 テストの種類
(1) ハードウェア／ソフトウェア統合テスト
(Hardware/software Integration Testing)
ターゲットコンピュータ上でソフトウェアがソフトウェア上位要求
(High-Level Requirements)を満足していることを保証する。
(2) ソフトウェア統合テスト(Software Integration Testing)
ソフトウェアコンポーネント間が正しく相互作用しており、ソフトウェア
要求とソフトウェア構造を満足していることを保証する。
(3) ソフトウェア下位要求テスト(Low-level Testing)
ソフトウェアコンポーネントがソフトウェア下位要求
(Low-Level Requirements)を満足していることを保証する。
http://www.masc.co.jp4.4 要求ベーステスト
テストは要求ベーステストに重点を置くこと。すなわち、テストケースはソフト
ウェア要求から作り出すこと。
(1) ノーマルレンジテスト(Normal Range Test Cases)
ノーマルレンジテストの目的は、正常な入力、状態に対応する
ソフトウェアの動作を確認することである。
(2) ロバストテスト(Robustness Test Cases)
ロバストテストの目的は、異常な入力、状態に対応するソフトウェア
の動作を確認することである。
4.6 テストプロセス
目的 活動 適用 成果物 形態管理 カテゴリ 内容 参照 参照 A B C D 名称 参照 A B C D 1 実行可能オブジェクトコードはソ フトウェア上位要求に準拠してい る 6.4.a 6.4.2 6.4.2.1 6.4.3 6.5 ○ ○ ○ ○ SW検証ケース・手順 SW検証結果 トレースデータ 11.13 11.14 11.21 ① ② ① ① ② ① ② ② ② ② ② ② 2 実行可能オブジェクトコードはソ フトウェア上位要求のロバスト性 がある 6.4.b 6.4.2 6.4.2.2 6.4.3 6.5 ○ ○ ○ ○ SW検証ケース・手順 SW検証結果 トレースデータ 11.13 11.14 11.21 ① ② ① ① ② ① ② ② ② ② ② ② 3 実行可能オブジェクトコードはソ フトウェア下位要求に準拠してい る 6.4.c 6.4.2 6.4.2.1 6.4.3 6.5 ● ● ○ SW検証ケース・手順 SW検証結果 トレースデータ 11.13 11.14 11.21 ① ② ① ① ② ① ② ② ② 4 実行可能オブジェクトコードはソ フトウェア下位要求のロバスト性 がある 6.4.d 6.4.2 6.4.2.2 6.4.3 6.5 ● ○ ○ SW検証ケース・手順 SW検証結果 トレースデータ 11.13 11.14 11.21 ① ② ① ① ② ① ② ② ② 5 実 行 可 能 オ ブ ジ ェ ク ト コ ー ド は ターゲットコンピュータに整合して いる 6.4.e 6.4.1.a 6.4.3.a ○ ○ ○ ○ SW検証ケース・手順 SW検証結果 11.13 11.14 ① ② ① ② ② ② ② ② http://www.masc.co.jp4.6 テストプロセス
System
Requirements
High-Level
Requirements
Software
Architecture
Low-Level
Requirements
Source Code
Executable
Parameter Data
http://www.masc.co.jp
テストプロセスをまとめると・・・
A,B共に第三者が実施 Aは第三者が実施 Dは不要A-6.1 Compliance
A-6.2 Robustness
A-6.5 Compliance with Target
A-6.3 Compliance
A-6.4 Robustness
4.5 テストカバレッジ分析
(1) 要求ベーステストカバレッジ分析(Requirements-Based Test Coverage Analysis)
ソフトウェア要求の実装がどのくらい検証されているかを明らかにするものである。
(a) 各ソフトウェア要求に対応するテストケースが存在する。
(b) テストケースがノーマルレンジテスト、ロバストテストの評価基準を満足して
いること。
(2) 構造カバレッジ分析(Structural Coverage Analysis)
要求ベーステストにてどのコードが実行されていないかを明らかにするものである。
(a) ソフトウェアレベルに対応したカバレッジの度合いを確立する。
(b) ソフトウェアレベルAでかつ、コンパイラが生成するオブジェクトコードが
ソースコードに直接トレースしない場合を除いて、この分析は、ソースコード上
で行えばよい。
(c) この分析はコンポーネント間のデータの結合度、制御の結合度についても
実行されなければならない。
http://www.masc.co.jp4.7 レビュー／分析（テスト） (1/2)
目的 活動 適用 成果物 形態管理 カテゴリ 内容 参照 参照 A B C D 名称 参照 A B C D 1 テスト手順は正しい 6.4.5.b 6.4.5 ● ○ ○ SW検証結果 11.14 ② ② ② 2 テスト結果は正しく、不一致は説 明されている 6.4.5.c 6.4.5 ● ○ ○ SW検証結果 11.14 ② ② ② 3 ソフトウェア上位要求のテストカ バレッジが達成されている 6.4.4.a 6.4.4.1 ● ○ ○ ○ SW検証結果 11.14 ② ② ② ② 4 ソフトウェア下位要求のテストカ バレッジが達成されている 6.4.4.b 6.4.4.1 ● ○ ○ SW検証結果 11.14 ② ② ②○：実施、●：独立した組織が実施
①：カテゴリ１、②：カテゴリ２
http://www.masc.co.jp4.7 レビュー／分析（テスト） (2/2)
目的 活動 適用 成果物 形態管理 カテゴリ 内容 参照 参照 A B C D 名称 参照 A B C D 5 ソフトウェア構造のテストカバレッジ(MCDC)が達成されている 6.4.4.c 6.4.4.2.a 6.4.4.2.b 6.4.4.2.d 6.4.4.3 ● SW検証結果 11.14 ② 6 ソフトウェア構造のテストカバレッ ジ(decision coverage）が達成され ている 6.4.4.c 6.4.4.2.a 6.4.4.2.b 6.4.4.2.d 6.4.4.3 ● ● SW検証結果 11.14 ② ② 7 ソフトウェア構造のテストカバレッ ジ(statement coverage)が達成さ れている 6.4.4.c 6.4.4.2.a 6.4.4.2.b 6.4.4.2.d 6.4.4.3 ● ● ○ SW検証結果 11.14 ② ② ② 8 ソフトウェア構造のテストカバレッ ジ (data coupling and control coupling)が達成されている 6.4.4.d 6.4.4.2.c 6.4.4.2.d 6.4.4.3 ● ● ○ SW検証結果 11.14 ② ② ② 9 ソースコードとトレースが取れてい ない追加のコードの検証が達成さ れている 6.4.4.c 6.4.4.2.b ● SW検証結果 11.14 ② http://www.masc.co.jp4.8 トレーサビリティ
以下の双方向のトレーサビリティを示すトレースデータが作らなければなら
ない。
(1) ソフトウェア要求 ⇔ テストケース
(2) テストケース ⇔ テスト手順
(3) テスト手順 ⇔ テスト結果
ソフトウェア検証プロセスにおけるトレーサビリティ
http://www.masc.co.jpツール資格
(Tool Qualification)
1. ツール開発ライフサイクルのV字構造
2. ツール運用要求定義プロセス
3. ツール統合プロセス
http://www.masc.co.jp9.2 ツール資格 (1/4)
9.2.1 概要
(1) ツールによりDO-178Cのプロセスが省略、削除、自動化される場合、
ツールの資格化が必要である。ただし、
ツールのアウトプットがソフトウェ
ア検証プロセスにより検証されるのであればその限りでない。
(2) 複数の機能を持つツールの場合、機能間の保護が立証できれば、使用
する機能のみを資格化すればよい。
(3) ツール資格はシステム単位に実施しなければならず、
あるシステムで既
に資格化されているツールを他のシステムで使用する場合も再資格化
が必要
である。
9.2 ツール資格(Tool Qualification)
http://www.masc.co.jp9.2 ツール資格 (2/4)
9.2.2 ツールの種類
Criteria 1 :
そのツールのアウトプットが航空ソフトウェアの一部となり、それゆえエ
ラーを入り込ませる可能性があるツール。
Criteria 2 :
検証プロセスを自動化する検証ツールであり、それゆえエラーの検出を誤
る可能性があるツール。また、そのアウトプットが以下のプロセスの削除、
省略を正当化するために使用されるツール。
◇ツールによって自動化されたプロセス以外の検証プロセス
◇航空機ソフトウェアにインパクトを与える開発プロセス
Criteria 3 :
そのツールの意図した使用の範囲内でエラーの検出を誤る可能性がある
ツール。
http://www.masc.co.jp9.2 ツール資格 (2/4)
9.2.2 ツールの種類
Criteria 1 :
そのツールのアウトプットが航空ソフトウェアの一部となり、それゆえエ
ラーを入り込ませる可能性があるツール。
Criteria 2 :
検証プロセスを自動化する検証ツールであり、それゆえエラーの検出を誤
る可能性があるツール。また、そのアウトプットが以下のプロセスの削除、
省略を正当化するために使用されるツール。
◇ツールによって自動化されたプロセス以外の検証プロセス
◇航空機ソフトウェアにインパクトを与える開発プロセス
Criteria 3 :
そのツールの意図した使用の範囲内でエラーの検出を誤る可能性がある
ツール。
DO-178Bにおける開発ツール
DO-178Bにおける検証ツール
http://www.masc.co.jp9.2 ツール資格 (3/4)
9.2.3 ツール資格レベル
(Tool Qualification Level)
Criteriaと適用する航空ソフトウェアのソフトウェアレベルの組み合わせで
ツール資格レベルを設定している。
Software
Level
Criteria
1
2
3
A
TQL-1
TQL-4
TQL-5
B
TQL-2
TQL-4
TQL-5
C
TQL-3
TQL-5
TQL-5
D
TQL-4
TQL-5
TQL-5
検証ツール
開発ツール
http://www.masc.co.jp9.2 ツール資格 (4/4)
9.2.4 ツール資格のObjectives
参考のためにDO-330 Software Tool Qualification Considerationsで規定され
ている各TQLに対するObjectivesの数を下表に示す。
Table Process TQL
1 2 3 4 5
T-0 Tool Operational Process 7(3) 7(3) 7 7 6 T-1 Tool Planning Process 7 7 7 2 0 T-2 Tool Development Process 8 8 8 5 0 T-3 Verification of Outputs of Tool Requirements Process 9(6) 9(6) 9 8 0 T-4 Verification of Outputs of Tool Design Process 11(7) 11(3) 9 1 0 T-5 Verification of Outputs of Tool Coding & Integration
Process 7(3) 7 6 0 0
T-6 Testing of Outputs of Integration Process 4(2) 4(1) 4 2 0 T-7 Verification of Outputs of Tool Testing 9(9) 7(3) 6 2 0 T-8 Tool Configuration Management Process 5 5 5 5 2 T-9 Tool Quality Assurance Process 5(5) 5(5) 5(5) 2(2) 2(2) T-10 Tool Qualification Liaison Process 4 4 4 4 4
Total 76(35) 74(21) 70(5) 38(2) 14(2)
9.2 ツール資格 (4/4)
9.2.4 ツール資格のObjectives
参考のためにDO-330 Software Tool Qualification Considerationsで規定され
ている各TQLに対するObjectivesの数を下表に示す。
Table Process TQL
1 2 3 4 5
T-0 Tool Operational Process 7(3) 7(3) 7 7 6 T-1 Tool Planning Process 7 7 7 2 0 T-2 Tool Development Process 8 8 8 5 0 T-3 Verification of Outputs of Tool Requirements Process 9(6) 9(6) 9 8 0 T-4 Verification of Outputs of Tool Design Process 11(7) 11(3) 9 1 0 T-5 Verification of Outputs of Tool Coding & Integration
Process 7(3) 7 6 0 0
T-6 Testing of Outputs of Integration Process 4(2) 4(1) 4 2 0 T-7 Verification of Outputs of Tool Testing 9(9) 7(3) 6 2 0 T-8 Tool Configuration Management Process 5 5 5 5 2 T-9 Tool Quality Assurance Process 5(5) 5(5) 5(5) 2(2) 2(2) T-10 Tool Qualification Liaison Process 4 4 4 4 4
Total 76(35) 74(21) 70(5) 38(2) 14(2)
ツールベンダーのプロセス
3.0 ツール開発ライフサイクル
ツール開発ライフサイクル
(Tool Development Life Cycle)
1. ツール開発ライフサイクルのV字構造
2. ツール運用要求定義プロセス
3. ツール統合プロセス
3.1 ツール開発ライフサイクルのV字構造
ツール運用要求定義プロセス (Tool Operational Requirements
Definition Process)
ツール運用統合プロセス (Tool Operational Integration Process)
ツール開発プロセス (Tool Development Process)
ツール要求プロセス ツール設計プロセス ツールコーディングプロセス
ツール統合プロセス
ツール検証プロセス (Tool Verification Process) レビュー/分析(ツール要求) レビュー/分析(下位ツール要求/ ツール構造) レビュー/分析(ツールソースコード) レビュー/分析(統合プロセスの結果) ツール検証プロセ ス (Tool Verification Process) レビュー/分析 (テストケース、 手順、結果) ツール検証プロセス (Tool Verification Process) テスト ツール運用検証/妥当性確認プロセス
(Tool Operational Verification and Validation Process) レビュー/分析(ツール運用要求)
ツール運用検証/妥当性確認 プロセス
(Tool Operational Verification and Validation Process)
テスト
ツール運用検証/妥当性確認 プロセス
(Tool Operational Verification and Validation Process) レビュー/分析(テスト結果)
3.1 ツール開発ライフサイクルのV字構造
ツール運用要求定義プロセス (Tool Operational Requirements
Definition Process)
ツール運用統合プロセス (Tool Operational Integration Process)
ツール開発プロセス (Tool Development Process)
ツール要求プロセス ツール設計プロセス ツールコーディングプロセス
ツール統合プロセス
ツール検証プロセス (Tool Verification Process) レビュー/分析(ツール要求) レビュー/分析(下位ツール要求/ ツール構造) レビュー/分析(ツールソースコード) レビュー/分析(統合プロセスの結果) ツール検証プロセ ス (Tool Verification Process) レビュー/分析 (テストケース、 手順、結果) ツール検証プロセス (Tool Verification Process) テスト ツール運用検証/妥当性確認プロセス
(Tool Operational Verification and Validation Process) レビュー/分析(ツール運用要求)
ツール運用検証/妥当性確認 プロセス
(Tool Operational Verification and Validation Process)
テスト
ツール運用検証/妥当性確認 プロセス
(Tool Operational Verification and Validation Process) レビュー/分析(テスト結果)
ツール利用者のプロセス
ツールベンダーのプロセス
3.2 ツール運用要求定義プロセス
ツール運用要求定義プロセス (Tool Operational Requirements
Definition Process)
ツール運用統合プロセス (Tool Operational Integration Process)
ツール開発プロセス (Tool Development Process)
ツール要求プロセス ツール設計プロセス ツールコーディングプロセス
ツール統合プロセス
ツール検証プロセス (Tool Verification Process) レビュー/分析(ツール要求) レビュー/分析(下位ツール要求/ ツール構造) レビュー/分析(ツールソースコード) レビュー/分析(統合プロセスの結果) ツール検証プロセ ス (Tool Verification Process) レビュー/分析 (テストケース、 手順、結果) ツール検証プロセス (Tool Verification Process) テスト ツール運用検証/妥当性確認プロセス
(Tool Operational Verification and Validation Process) レビュー/分析(ツール運用要求)
ツール運用検証/妥当性確認 プロセス
(Tool Operational Verification and Validation Process)
テスト
ツール運用検証/妥当性確認 プロセス
(Tool Operational Verification and Validation Process) レビュー/分析(テスト結果)
3.2.1 ツール運用要求定義プロセスへのインプット
ソフトウェア計画プロセス
(Software Planning Process)
ツール計画プロセス
(Software Planning Process)
ツール運用要求定義プロセス
(Tool Operational Requirements Definition Process) ツール運用要求(Tool Operational Requirements)
ソフトウェア計画(Software Plans)
ソフトウェア認証計画 ソフトウェア開発計画 ソフトウェア検証計画 ソフトウェアレ形態管理計画 ソフトウェア品質保証計画ツール計画(Software Plans)
ツール資格計画 ツール開発計画 ツール検証計画 ツール形態管理計画 ツール品質保証計画Software Lifecycle Process Tool Lifecycle Process
ツール運用要求定義プロセス ツール運用要求定義プロセス
Tool Operational Requirements Definition Process ツール運用要求 Tool Operational Requirements レビュー/分析 (ツール運用要求)
Reviews and Analyses of the Tool Operational Requirements
ツール運用検証/妥当性確認結果
Tool Operational Verification and Validation Results
ツール運用要求定義プロセスの成果物
ツール運用検証/妥当性確認プロセス
ツール運用検証/妥当性確認プロセスの成果物
目的(Objectives) 活動 適用(TQL) 成果物 形態管理 カテゴリ 内容 参照 参照 1 2 3 4 5 名称 参照 1 2 3 4 5 4 ツール運用要求は完全 であり、正確であり、検証 可能であり、一貫してい る。 6.2.1.a 6.2.2.a ● ● ○ ○ ツール運用検証/妥当 性確認結果 10.3.4 ② ② ② ② 6 ツール運用要求は十分であり、正しい。 6.2.1.aa 6.2.2.b ● ● ○ ○ ○ ツール運用検証/妥当性確認結果 10.3.4 ② ② ② ② ②
○：実施、●：独立した組織が実施
①：カテゴリ１、②：カテゴリ２
3.2.3 レビュー/分析(ツール運用要求)
http://www.masc.co.jp3.3 ツール運用統合プロセス
ツール運用要求定義プロセス (Tool Operational Requirements
Definition Process)
ツール運用統合プロセス (Tool Operational Integration Process)
ツール開発プロセス (Tool Development Process)
ツール要求プロセス ツール設計プロセス ツールコーディングプロセス
ツール統合プロセス
ツール検証プロセス (Tool Verification Process) レビュー/分析(ツール要求) レビュー/分析(下位ツール要求/ ツール構造) レビュー/分析(ツールソースコード) レビュー/分析(統合プロセスの結果) ツール検証プロセ ス (Tool Verification Process) レビュー/分析 (テストケース、 手順、結果) ツール検証プロセス (Tool Verification Process) テスト ツール運用検証/妥当性確認プロセス
(Tool Operational Verification and Validation Process) レビュー/分析(ツール運用要求)
ツール運用検証/妥当性確認 プロセス
(Tool Operational Verification and Validation Process)
テスト
ツール運用検証/妥当性確認 プロセス
(Tool Operational Verification and Validation Process) レビュー/分析(テスト結果)
ツール運用統合プロセス
レビュー/分析(テスト結果) Review and Analyses of Test
Results ツール運用統合プロセスの成果物 ツール運用検証/妥当性確認プロセス ツール運用検証/妥当性確認プロセスの成果物
3.3.1 ツール運用統合プロセスのフロー
ツール運用統合プロセスTool Operational Integration Process ツールインストール報告 Tool Operational Requirements ツール実行可能オブジェク トコード
Tool Executable Object Code
テスト(運用環境にインストールされ たツール実行可能オブジェクトコード)
Review and Analyses of Test Results
ツール運用検証/妥当性確認結果
Tool Operational Verification and Validation Results
ツール運用検証/妥当性確認ケー ス・手順
Tool Operational Verification and Validation Cases and Procedures
目的(Objectives) 活動 適用(TQL) 成果物 形態管理 カテゴリ 内容 参照 参照 1 2 3 4 5 名称 参照 1 2 3 4 5 5 ツール運用はツール運用要求に準拠している。 6.2.1.b 6.2.2.c ● ● ○ ○ ○ ツール運用検証/妥当 性確認ケース・手順 ツール運用検証/妥当 性確認結果 10.3.3 10.3.4 ② ② ② ② ② ② ② ② ② ② 7 ツールによって、ソフトウェ アライフサイクルプロセス の要求が満たされている。 6.2.1.bb 6.2.2.c ○ ○ ○ ○ ○ ツール運用検証/妥当 性確認ケース・手順 ツール運用検証/妥当 性確認結果 10.3.3 10.3.4 ② ② ② ② ② ② ② ② ② ②
