MT-0595A
【N/A】
2011年12月にDO-178のC改訂が発行された。
2013年7月にFAAもOrderを発行し、以降の搭載ソフトウェア開発はDO-178Cに準拠することになった。
本資料はDO-178Cを解説書という形で取りまとめたものである。
認証活動の中でDO-178Cの本文をそのまま引用するケースが多くみられるため、できうる限りノートの部分に原文（
和訳）をそのまま掲載した。その箇所は先頭と末尾を本文の章番号を記載した《》で囲っている。
例を以下に示す。
《4.1》 ソフトウェア計画プロセスの目的(Software Planning Process Objectives)
ソフトウェア計画プロセスの目的は、そのソフトウェア要求を満足し、与えられたソフトウェアレベルに合った信頼
のレベルを提供できるようなソフトウェアの開発方法を定義するものである。
ソフトウェア計画プロセスの目的(Objectives)は以下である。
(a) システム要求とソフトウェアレベルに対応するソフトウェアライフサイクルにおける開発プロセスとインテグラ
ルプロセスの活動が定義されている（4.2章参照）。
(b) プロセス間の相互関係、順序、フィードバック機構、及び遷移条件を含むソフトウェアライフサイクルが確定
している（3章参照）。
(c) 各ソフトウェアライフサイクルプロセスの活動に使用する手法、及びツールを含むソフトウェアライフサイク
ル環境が選定されている（4.4章参照）。
(d) 必要に応じて、12章で議論されているような追加の考慮事項が検討されている。
(e) 開発されるソフトウェアに対するシステム安全性の目的に合致するソフトウェア開発標準が定義されている
（4.5章参照）。
1
MT-0595A
(f)
4.3章、及び11章に準拠したソフトウェア計画が作成されている。
(g) ソフトウェア計画の作成、改訂に関して調整されている（4.3章参照）。
《4.1》
ノートの部分で、《》がついていない記載には解説と共に私的な解釈が含まれていることを理解していただきたい。
1
MT-0595A
【N/A】
2
MT-0595A
【N/A】
ここでは、C改訂のサマリーを説明する。詳しくは以降の説明の中で取り上げる。
1.
パラメータデータ項目(Parameter Data Items)
実行可能オブジェクトコードを変更することなくソフトウェアの振る舞いに影響を与えることができ、独立した形
態項目として管理されるデータセットをパラメータデータ項目と呼ぶ。
パラメータデータ項目は、実行可能オブジェクトコードとは管理形態を分け、個別に管理するように定義されて
いる。それに伴いDO-178C内の各所にパラメータデータ項目に関わる記述が追加されている。例えば6.6
Verification of Parameter Data Itemsでは、ソフトウェア検証プロセスの一環としてパラメータデータ項目の検証
が追加されている。
2.
ソフトウェアライフサイクルデータの追加
従来20項目だったソフトウェアライフサイクルデータに以下の2項目が追加されている。
21. Trace Data（トレースデータ）
22. Parameter Data Item File（パラメータデータ項目ファイル）
3.
ソフトウェア計画プロセスにおける品質保証
従来、ソフトウェア計画プロセスにおける品質保証については4.6章にReview and Assurance of the Software
Planning Processとあり、品質保証プロセス内には明示的に定義されていなかったが、今回4.6章からは
Assuranceが除かれ、Review of the Software Planning Processとなり、品質保証プロセスのObjectivesとしてソフ
トウェア計画に対する品質保証が追加となった。
4.
目的(Objectives)の追加
Level A 66項目 → 71項目(30項目)
Level B 65項目 → 69項目(18項目)
Level C 57項目 → 62項目(5項目)
3
MT-0595A
Level D
5.
28項目 → 26項目(2項目)
()内は独立した組織が実施すべき項目。
ツール資格
従来、ツールの種類としてソフトウェア開発プロセスに使用されるツールとソフトウェア検証プロセスに使用され
るツールの2種類としていたのに対して、3種類の分類となった。また、ツール資格レベル(Tool Qualification
Level)と言う5段階のレベルを設定し、3種類の分類との組み合わせで、資格化に必要な目的(Objectives)を設定
している。具体的なツールの資格化のプロセスについては以下の補足資料に規定されている。
DO-330 Software Tool Qualification Consideration
6.
補足資料
DO-178Cを補足する資料(Supplement)として以下の規格が制定された。
これに伴い、従来、12.3章の中にAlternative Methods(代替手法)として記載されていた形式手法(Formal
Method)に関する記述が全て削除された。
DO-330, Software Tool Qualification Considerations
DO-331, Model-Based Development and Verification Supplement to DO-178C and DO-278A
DO-332, Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A
DO-333, Formal Methods Supplement to DO-178C and DO-278A
3
MT-0595A
【N/A】
4
MT-0595A
【N/A】
5
MT-0595A
【N/A】
DO-178Cの上位文書としては以下がある。
(1) ARP4754 Certification Considerations for Highly-Integrated or Complex Aircraft Systems
(2) ARP4761 Guidelines and Methods for conducting the Safety Assessment Process on Civil Airborne Systems and
Equipment
また、DO-178Cの同列の文書として以下がある。
(1) DO-254 Design Assurance Guidance for Airborne Electronic Hardware
ARP4754では航空機システムの開発プロセスを定義している。
さらに上位の文書であるFAR(Federal Aviation Regulations 連邦航空規則)のPart25（民間機の耐空性に関する条項
）には以下が規定されている。
FAR25.1301 Function and installationでは各装備品は意図通りに機能することとあり、
FAR25.1309 Equipment, systems, and installationsでは各装備品は飛行安全に影響する故障を発生しないこととある
。
ARP4754はこの２つのFARへの適合を示すためのガイドラインであり、システムレベルでのセイフティを確立するた
めの設計プロセスが規定されている。
一方、ARP4761はFAR25.1309への適合を示すための安全評価方法のガイドラインであり、安全という観点から
ARP4754を補完する位置づけにある。
システム開発プロセスとして、ARP4754に従い安全面に関してはARP4761で補完し、与えられた要件（Aircraft
Function 航空機としての機能)をブレークダウンし、ハードウェア、ソフトウェアに対するシステム要求を導き出す。
ハードウェアに関しては、DO-254に基づきハードウェアの開発プロセスを実行する。
ソフトウェアに関しては、DO-178Cに基づきソフトウェアの開発プロセスを実行する。
両者の成果物を再びARP4754に基づくシステム開発プロセスに戻し、検証を経てシステムが出来上がる。
6
MT-0595A
【1.5】
ここでは、DO-178Cの文書としての全体像を示している。
DO-178Cは全部で12章より構成されている。
先にも述べたようにDO-178Cではプロセスを定義している文書である。
第3章から第9章は各プロセスについて記載している。
第11章では、各プロセスの成果物をまとめて定義している。
第12章では、前章までで記載しきれなかった追加の考慮事項について記載している。
7
MT-0595A
【2.3.2】
DO-178Cでは、対象となるソフトウェアの重要度に応じでA～Eまでのソフトウェアレベルを設定している。
重要度とは、もしそのソフトウェアが故障したことにより被害がどの程度に及ぶかということである。
故障により壊滅的な(Catastrophic)事態に陥るようなソフトウェアはソフトウェアレベルをAとし、特に飛行に影響がな
いものはソフトウェアレベルがEとなる。
A～Eのソフトウェアレベルに応じて、以降のプロセス内で開発のレベル（実施すべきことの範囲、作成する文書の量
、質など）を定義している。
これらのソフトウェアレベルの値は上位のプロセスから継承される。
上位のプロセスであるシステム開発プロセスでは。ARP4754に定義されているFHA(Functional Hazard Assessment)
を実施することにより、機器としてのDAL(Development Assurance Level)が設定される。
DALはこのソフトウェアレベルと同様に壊滅的(Catastrophic)から影響なし(No Effect)までのA～Eで定義されている
。
基本的には対象となるソフトウェアが搭載されている機器のDALをそのままソフトウェアレベルとして引き継ぐことに
なる。
ちなみに、ARP4754では、DALに対応して故障発生の確率が定義されている。
A(Catastrophic)は、1時間のフライトあたりの故障発生回数が 1x10-9 以下でなければならない。
同様にB(Hazardous)は、 1x10-7 以下、C(Major)は、 1x10-5 以下でなければならないとしている。
8
MT-0595A
【3.1】
DO-178Cでは、ソフトウェアのプロセスとして以下の３プロセスを定義している。
1.
ソフトウェア計画プロセス(Software Planning Process)
2.
ソフトウェア開発プロセス(Software Development Process)
3.
インテグラルプロセス(Integral Process)
9
MT-0595A
【5】
ソフトウェア開発プロセス(Software Development Process)はさらに以下の４つのプロセスに分けられる。
1.
ソフトウェア要求プロセス(Software Requirements Process)
2.
ソフトウェア設計プロセス(Software Development Process)
3.
ソフトウェアコーディングプロセス(Software Coding Process)
4.
統合プロセス(Integration Process)
この中で、1～3はその名の通り1.ソフトウェアの要求を定義する、2.ソフトウェアを設計する、3.プログラムをコーディ
ングするプロセスである。
4の統合プロセスは実行可能オブジェクトコードを生成するプロセスである。
一般的な開発プロセスにおいてこの統合プロセスをひとつのプロセスとして独立しているものはあまり見かけない。
以上より、ソフトウェア開発プロセスはお馴染みのV字モデルの左側のプロセスに対応していることがわかる。
右側のテストプロセスは次に説明するインテグラルプロセス内のソフトウェア検証プロセス内に存在する。
10
MT-0595A
【3.1】
インテグラルプロセス(Integral Process)は、さらに以下の４つのプロセスに分けられる。
1.
ソフトウェア検証プロセス(Software Verification Process)
ソフトウェア検証プロセスは、さらに以下より構成される。
(1) レビュー／分析(Software Reviews and Analyses)
ソフトウェア開発プロセスの各プロセス、及び以下に説明するテスト(Software Testing)にて作成する成果物を
レビュー／分析する。後述する各プロセスの詳細説明において、各プロセスにおけるレビュー／分析内容につ
いても併せて説明する。
(2) テスト(Software Testing)
このテストの部分がV字モデルの右側のテストプロセスに該当する。
2.
ソフトウェア形態管理プロセス(Software Configuration Management Process)
ソフトウェアの識別、構成管理、変更管理等を行うプロセスである。
3.
ソフトウェア品質保証プロセス(Software Quality Assurance Process)
ソフトウェア開発のプロセスが正しく実行されていること、及びソフトウェア製品の保証を行うプロセスである。
4.
認証連絡調整プロセス(Certification Liaison Process)
ソフトウェア認証を実現するために申請者が実施すべきプロセスである。
11
MT-0595A
【3.1】
以上の3つのプロセスの関係を図に表した。
ソフトウェア計画プロセスで策定した計画、標準に従って、ソフトウェア開発プロセス、インテグラルプロセスは実行さ
れる。
ソフトウェア開発プロセスとインテグラルプロセスは併行して実行され、ソフトウェア開発プロセスの成果物（設計文
書、ソースコード）がインテグラルプロセスに提供され、インテグラルプロセスの各プロセスで処理される。
特にソフトウェア検証プロセスの「Reviews/Analyses」と「Testing」は、ソフトウェア開発プロセスと密接に関連し、その
プロセスの成果物をレビュー／分析するとともに、実行可能オブジェクトコードのテストを実行する。
12
MT-0595A
【11】
ここでは、各プロセスの成果物であるソフトウェアライフサイクルデータの一覧を示した。
ソフトウェアライフサイクルデータとは、文書とソフトウェア（ソースコード、実行可能オブジェクトコード）より構成され
ている。
本資料内では、ソフトウェアライフサイクルデータと成果物を同意語として表現している。
表の右側の参照項番は本資料内で説明している項番である。
黄色で示した１～８は、ソフトウェア計画プロセスの成果物であり、濃い黄色は計画を薄い黄色は標準を示す。
ブルーで示した９～１２、２２は、ソフトウェア開発プロセスの成果物である。
ピンクで示した１３～２１は、インテグラルプロセスの成果物である。
13
MT-0595A
【7.3】
DO-178Cではソフトウェア・ライフサイクル・データの形態管理の方法を厳密に定義している。
詳細は６．ソフトウェア形態管理プロセスで説明するが、今後の説明の中で「形態管理カテゴリ」が随所に出てくるの
でここで簡単に説明しておく。
この表はソフトウェア形態管理プロセスで定義された13の形態管理項目を示している。
CC1は「Control Category 1」、CC2は「Control Category 2」の略である。
本資料では、「Control Category」を「形態管理カテゴリ」と訳している。
DO-178Cでは、ソフトウェアレベル(A～E)に応じてソフトウェア・ライフサイクル・データの形態管理のレベル(CC1、
CC2)を定めている。
CC1が指定されると１３項目の全ての形態管理項目を実施する必要がある。CC2が指定された場合は、表で○のつ
いた項目だけを最低限実施すればよい。
14
MT-0595A
【4】
15
MT-0595A
【4】
ソフトウェア計画プロセスでは、以下の４項目を実施する。
(1) ソフトウェア計画(Software Plans)
ソフトウェア開発プロセス、インテグラルプロセスの活動を定義するための計画を策定する。これらの計画は以
下の５つの文書としてとりまとめられる（詳細は後述）。
(a) ソフトウェア認証計画(Plan for Software Aspects of Certification)
(b) ソフトウェア開発計画(Software Development Plan)
(c) ソフトウェア検証計画(Software Verification Plan)
(d) ソフトウェア形態管理計画(Software Configuration Management Plan)
(e) ソフトウェア品質保証計画(Software Quality Assurance Plan)
(2) ソフトウェア・ライフサイクル環境計画(Software Life Cycle Environment Planning)
ソフトウェアライフサイクルデータとソフトウェア製品を開発、検討、管理、製造するために使用される手法、ツー
ル、手順、プログラミング言語、ハードウェアを定義する。定義された内容は、前述の各計画の中の項目として
記載される。
(3) ソフトウェア開発標準(Software Development Standards)
ソフトウェア開発プロセスに対してルールと制約を定める以下の３つの標準を制定する（詳細は後述）。これら
の標準は検証プロセスにおいて開発プロセスを評価する際の基準ともなる。
(a) ソフトウェア要求標準(Software Requirements Standards)
(b) ソフトウェア設計標準(Software Design Standards)
(c) ソフトウェアコード標準(Software Code Standards)
(4) ソフトウェア計画プロセスのレビューと保証(Review of the Software Planning Process)
ソフトウェア計画プロセスで作成した各計画、各標準がDO-178Cに準拠していることをレビューする。
これは、検証プロセスにおけるレビューと分析(Review & Analyses)に相当するものであり、そのレビュー結果を
ソフトウェア検証結果(Software Verification Results)に残すことを要求している。
DO-178Bでは、「Review and Assurance of the Software Planning Process」となっており、レビューに加えて品質
保証も要求していたが、品質保証の部分は品質保証プロセスに(8章)に移動された。
16
MT-0595A
《4.3》 ソフトウェア計画(Software Plans)
ソフトウェア計画は本書の目的を満足させる手段を定義するものである。この計画は、本書の活動を実施する組
織を特定する。
ソフトウェア計画は以下である。
(1) ソフトウェア認証計画(The Plan for Software Aspects of Certification)(11.1章参照)は、認証機関に対して提
案した開発手法を伝える主要な手段を提供するとともに、本書に準拠する手段を定義する。
(2) ソフトウェア開発計画(The Software Development Plan)(11.2章参照)は、ソフトウェアライフサイクル、ソフトウ
ェア開発環境、ソフトウェア開発プロセスの目的を満足させるための手段を定義する。
(3) ソフトウェア検証計画(The Software Verification Plan)(11.3章参照)は、ソフトウェア検証プロセスの目的を満
足させるための手段を定義する。
(4) ソフトウェア形態管理計画(The Software Configuration Management Plan)(11.4章参照)は、ソフトウェア形態
管理プロセスの目的を満足させる手段を定義する。
(5) ソフトウェア品質保証計画(The Software Quality Assurance Plan)(11.5章参照)は、ソフトウェア品質保証プロ
セスの目的を満足させる手段を定義する。
ソフトウェア計画の活動は、以下を含む。
(a) ソフトウェア計画は本書に準拠すべきである。
(b) ソフトウェア計画は、以下に指定されるソフトウェアライフサイクルプロセス間の移行基準を定義すべきであ
る。
1. プロセスへのインプット、他のプロセスからのフィードバックを含む
2. それらのインプットに従って行動することを要求されたインテグラルプロセスの活動
3. ツール、方法、計画、手順の有用性
(c) ソフトウェア計画には、既に認証された製品を使用するに先立ってソフトウェアの変更を実装するために使用
される手順が記載されるべきである。このような変更は、他のプロセスからのフィードバックの結果であって
もよい、またソフトウェア計画に変更を生じさせてもよい。
《4.3》
《4.4》 ソフトウェアライフサイクル環境計画(Software Life Cycle Environment Planning)
ソフトウェアライフサイクル環境の計画は、開発、検証、管理、ソフトウェアライフサイクルデータ(11章参照)とソフト
ウェア製品を作成するために使用される方法、ツール、手順、プログラミング言語、ハードウェアを定義する。
選ばれたソフトウェア環境の例は、ソフトウェアに対して、標準に従わせる、エラーを検出する、エラーを防止する
実装、フォールトトレランスな方法といった有益な効果をもたらす。
ソフトウェアライフサイクル環境は、故障状態に陥る潜在的なエラーの源でもある。
このソフトウェアライフサイクル環境の組み合わせは、システム安全性評価プロセスによって定義された安全性関
連要求（例えばデシミュラや冗長構成の使用）によって影響されてもよい。
エラーを防止する方法の目標は、故障状態に陥るかもしれないソフトウェア開発プロセスの間、エラーを回避する
ことである。
基本的な原理は、エラーが組み込まれる機会を制限するために要求開発と設計の手法、ツール、プログラミング
言語を選ぶことであり、また、組み込まれたエラーの検出を確実にするための検証手法を選ぶことである。
フォールトトレランス手法の目標はソフトウェア設計、またはソースコードに、ソフトウェアが入力データのエラーに
対して正しく反応し、出力と制御のエラーを防ぐことを確実にするために、安全性機能を組み込むことである。
エラーの防御、もしくはフォールトトレランス手法の必要性はシステム要求とシステム安全性評価プロセスによっ
て決定される。
上記に示した考慮すべき事項は以下に影響を与える。
(a) ソフトウェア要求プロセス及びソフトウェア設計プロセスにおける手法や表記法
16
MT-0595A
(b) ソフトウェアコーディングプロセスにおいて使用されるプログラミング言語や手法
(c) ソフトウェア開発環境ツール
(d) ソフトウェア検証及びソフトウェア形態管理ツール
(e) ツール資格化の必要性(12.2章参照)
《4.4》
《4.4.1》 ソフトウェア開発環境(Software Development Environment)
ソフトウェア開発環境は高い品質のソフトウェア製品に対して重要な要因である。
また、ソフトウェア開発環境は様々な形でソフトウェア製品に不利益な影響を与える。
例えば、コンパイラは不正な出力を作り出すことによってエラーを組み入れてしまい、リンカーは現存するメモリー
配置のエラーを明らかにすることに失敗する。
ソフトウェア開発環境の手法及びツールの選択の活動には以下を含む。
(a) ソフトウェア計画プロセスの間に、開発されるソフトウェアの潜在的なリスクを取り除くためのソフトウェア開
発環境が選択されるべきである。
(b) ツール群もしくはツールの組み合わせ、そしてソフトウェア開発環境の一部の使用が、必要となる信頼性の
レベル（ひとつのツールによって組み込まれたエラーが他のツールで検出されるような）を達成するために選
ばれるべきである。複数のツールが互いに一貫性を持って使用されたとき、受け入れ可能な環境が作られ
る。
(c) ソフトウェアレベルを考慮したソフトウェア検証プロセスの活動、もしくはソフトウェア開発標準は、潜在的なソ
フトウェア開発環境に関わるエラーを取り除くために定義されるべきである。
(d) もし認証クレジットを得るために複数のツールを組み合わせて使用することが求められるのであれば、それ
らのツールの操作の順番が適切な計画の中で特定されるべきである。
(e) ソフトウェアツールのオプション機能がプロジェクトにて使用することが選択された場合、そのオプションの効
果は適切な計画の中で試され、特定されるべきである。これはコンパイラや自動コード生成ツールにおいて
特に重要なことである。
(f)
既知のツールの問題や制約は評価されるべきであり、航空ソフトウェアに不利益な影響を与える事項は明
記されるべきである。
《4.4.1》
《4.4.2》 言語とコンパイラの考慮事項(Language and Compiler Considerations)
ソフトウェア製品の検証を成功のうちに完了するために、コンパイラはその製品にとって受け入れ可能かを検討さ
れる。
妥当性のために、ソフトウェア検証プロセスはプログラミング言語とコンパイラが持つ特有の特徴を検討する必要
がある。
ソフトウェア計画プロセスでは、プログラミング言語を選択し、検証の計画を立てるときに、これらの特徴を検討す
る。
その活動には以下が含まれる。
(a) いくつかのコンパイラはオブジェクトコードの性能を最適化させる特徴を持っている。もしテストケースがソフト
ウェアレベルに合致したカバレッジを与えているのなら、最適化の正確性は検証される必要はない。もしそう
でなければ、構造カバレッジ分析におけるこれらの特徴の影響は決定されるべきである。追加の情報は
6.4.4.2章を参照。
(b) 一定の特徴の実装において、いくつかの言語のコンパイラはソースコードに直接トレースしないオブジェクト
コードを生成する、例えば、初期化、組み込まれたエラー検出、例外処理などである(6.4.4.2b章を参照)。ソフ
トウェア計画プロセスでは、このオブジェクトコードを検出し、カバレッジ検証を確実にする方法を提供しなけ
ればならない、また適切な計画においてその方法を決定しなければならない。
(c) もしソフトウェアライフサイクルの間に、コンパイラ、リンクエディタ、ローダの新しいバージョンが導入された、
もしくはコンパイラオプションが変更されたなら、既に実施したテスト及びカバレッジ分析はもはや妥当性がな
い。検証計画は、6章、及び12.1.3章に合致した再検証の方法を提供するべきである。
注意：コンパイラが一旦、全ての検証目的を満足しているとして受け入れ可能となったとしても、そのコンパイラは
該当の製品に対してのみ受け入れ可能であり、他の製品に対しては必ずしも受け入れ可能ではない。
《4.4.2》
《4.4.3》 ソフトウェアテスト環境(Software Test Environment)
ソフトエアテスト環境計画は、インテグラルプロセスのアウトプットをテストするために使用する手法、ツール、手順
、ハードウェアを定義する。
16
MT-0595A
テストは、ターゲットコンピュータ、ターゲットコンピュータのエミュレータ、ホストコンピュータのシミュレータを使用し
て実施してもよい。
この活動には以下が含まれる。
(a) エミュレータやシミュレータは12.2章に記載された資格化の必要がある。
(b) ターゲットコンピュータとエミュレータもしくはシミュレータとの差異と、エラー検出と機能的な検証の能力にお
けるそれらの差異による影響は検討されるべきである。それらのエラーの検出はソフトウェア検証プロセスに
よって提供されるべきであり、ソフトウェア検証計画中に特定されるべきである。
《4.4.3》
《4.5》 ソフトウェア開発標準(Software Development Standards)
ソフトウェア開発標準はソフトウェア開発プロセスにおけるルールと制約を決定する。
ソフトウェア開発標準には、ソフトウェア要求標準、ソフトウェア設計標準、ソフトウェアコーディング標準が含まれ
る。
ソフトウェア検証プロセスでは、プロセスの実際のアウトプットが意図したアウトプットに準拠しているかを評価す
るための基本として、これらの標準を使用する。
ソフトウェア標準を作る活動には以下が含まれる。
(a) ソフトウェア開発標準は11章に準拠しなければならない。
(b) ソフトウェア開発標準は、与えられたソフトウェア製品、もしくは関連する製品のセットにおけるソフトウェアコ
ンポーネントが一律に設計され、実装できるようにしなければならない。
(c) ソフトウェア開発標準は、検証できなかったり、安全性関連要求に準拠しないアウトプットを作り出すような構
成と方法の使用を許可してはならない。
(d) 堅牢性はソフトウェア開発標準内で検討されるべきである。
注意1: 標準の作成においては、過去の経験に対して考慮することができる。開発、設計、コーディングの方法に
おける制約や規則には、複雑さのコントロールを含めることができる。防御的プログラミングの実行は堅牢性の改
良のために検討されてもよい。
注意2: もしシステム要求によってソフトウェアに割り当てられているのであれば、格納されたデータ内のエラーを
検出し管理する、またハードウェアの状態や形態を更新し、監視するといったことの実行は単一イベントの発生を
抑制するために使われてもよい。
《4.5》
《4.6》 ソフトウェア計画プロセスのレビュー(Review of the Software Planning Process)
ソフトウェア計画プロセスのレビューは、ソフトウェア計画とソフトウェア開発標準がDO-178Bのガイダンスに準拠
しており、それらを実行するための方法が提供されていることを確認するために実施される。
その活動は以下を含む。
(a) DO-178Bの目的を満足させる方法が選ばれている。
(b) ソフトウェアライフサイクルプロセスが一貫性を持って適用されることができる。
(c) 各プロセスは、そのアウトプットがそれらの活動とインプットをトレースできるようなエビデンスを作り出してい
る。活動、環境、使用された方法の独立の度合いを示している。
(d) ソフトウェア計画プロセスのアウトプットは11章と一致しており、準拠している。
《4.6》
16
MT-0595A
【Table A-1】
この表では、ソフトウェア計画プロセスの目的(Objectives)とソフトウェアレベルに対応しどのように実施するか（実施
しない／実施する／独立した組織が実施する）、その成果物は何か、そしてソフトウェアレベルに対応しその成果物
の形態管理カテゴリが規定されている。
DO-178Cでは、同様の表がANNEX AにTable A-1からA-10まで記載されており、各プロセスにおいて実施すべきこ
とが規定されている。
これらの表で、規定される項目(Objectives)は全部で71項目あり、ソフトウェアレベルに応じて以下のように実施が要
求されている。()内の数字は独立した組織で実施すべき項目数を示している。
Level A
71項目(30項目)
Level B
69項目(18項目)
Level C
62項目(5項目)
Level D
26項目(2項目)
Level E
0項目(0項目)
1項は、前述の「ソフトウェア計画」についてである。
2項は、以降のプロセスにおいてあるプロセスを終了し、次のプロセスへ移行する際の基準(Criteria)を定めることを
求めている。
3項は、前述の「ソフトウェアライフサイクル環境計画」についてである。
4項は、DO-178Cの12章に「Additional Consideration」という項が設けられており、追加で考慮すべき項目が記載さ
れている。ここでは、その項目の中で必要と思われる事項について検討し、計画に反映することを求めている。
5項は、前述の「ソフトウェア開発標準」についてである。
6、7項は、前述の「ソフトウェア計画プロセスのレビュー」についてである。この2つの項は、ソフトウェア計画プロセス
の検証の位置付けであり、他の項目と比べて趣旨が異なっている。従って、それを記録する成果物も「ソフトウェア
検証結果」といった文書となっている。
17
MT-0595A
【Table A-1】
《4.1》 ソフトウェア計画プロセスの目的(Software Planning Process Objectives)
ソフトウェア計画プロセスの目的は、そのソフトウェア要求を満足し、与えられたソフトウェアレベルに合った信頼
のレベルを提供できるようなソフトウェアの開発方法を定義するものである。
ソフトウェア計画プロセスの目的(Objectives)は以下である。
(a) システム要求とソフトウェアレベルに対応するソフトウェアライフサイクルにおける開発プロセスとインテグラ
ルプロセスの活動が定義されている（4.2章参照）。
(b) プロセス間の相互関係、順序、フィードバック機構、及び遷移条件を含むソフトウェアライフサイクルが確定
している（3章参照）。
(c) 各ソフトウェアライフサイクルプロセスの活動に使用する手法、及びツールを含むソフトウェアライフサイク
ル環境が選定されている（4.4章参照）。
(d) 必要に応じて、12章で議論されているような追加の考慮事項が検討されている。
(e) 開発されるソフトウェアに対するシステム安全性の目的に合致するソフトウェア開発標準が定義されている
（4.5章参照）。
(f)
4.3章、及び11章に準拠したソフトウェア計画が作成されている。
(g) ソフトウェア計画の作成、改訂に関して調整されている（4.3章参照）。
《4.1》
《4.2》 ソフトウェア計画プロセスの活動(Software Planning Process Activities)
効果的な計画は、本書のガイダンスを満足するソフトウェア開発において決定する要因である。
18
MT-0595A
ソフトウェア計画プロセスの活動は以下を含む。
(a) ソフトウェア計画は、ソフトウェアライフサイクルプロセスを実施する要員に対して指針を提供するために作
成されるべきである。9.1章を参照。
(b) プロジェクトで使用されるソフトウェア開発標準は定義されるか、選択されるべきである。
(c) ソフトウェア開発プロセスにおける、エラーの防止を助け、欠陥の検出を提供するための方法やツールが選
択されるべきである。
(d) ソフトウェア計画プロセスは、ソフトウェア計画における戦略間の一貫性を提供するために、ソフトウェア開発
プロセスとインテグラルプロセス間の調整を提供するべきである。
(e) プロジェクトの進捗に伴い、ソフトウェア計画を見直すためにその方法が特定されるべきである。
(f)
そのシステムにおいてマルチバージョンデシミュラソフトウェアが使われるとき、ソフトウェア計画プロセスに
おいてシステムの安全性目的を満足するために必要となるデシミュラリティを達成するための方法やツール
が選択されるべきである。
(g) ソフトウェア計画プロセスを完了させるために、ソフトウェア計画とソフトウェア開発標準は変更管理とそれら
を完全なレビューにかけるべきである。（4.6章参照）
(h) もし実行されないコードが計画されている場合は、ソフトウェア計画プロセスンにおいて、実行させない機構
や実行されないコードがどのように定義され、システムの安全性目的を満足していることを検証するのかを
記載しなければならない。
(i)
もし利用者が変更可能なソフトウェアが計画されている場合は、設計を立証する（5.2.3章参照）プロセス、ツ
ール、環境、データ項目がソフトウェア計画と標準の中で特定されるべきである。
(j)
パラメータデータ項目が計画されているとき、次のことが記載されるべきである。
1. パラメータデータ項目が使用される方法
2. パラメータデータ項目のソフトウェアレベル
3. バラメータデータ項目を開発、検証、修正するプロセス、及び関連するツール資格
4. ソフトウェアロード管理、及び整合性
(k) ソフトウェア計画プロセスは適用される追加の考慮事項について記載するべきである。
(l)
ソフトウェア開発活動がサプライヤによって実施される場合、計画にはサプライヤの監督について記載され
るべきである。
他のソフトウェアライフサイクルプロセスは、特定のプロセスへの移行基準を満足しているのであれば、ソフトウェ
ア計画プロセスの完了前に初めてもよい。
《4.2》
18
MT-0595A
【11】
以降、ソフトウェア計画プロセスの成果物について説明する。
前述したように、成果物（文書）としては、計画に係わる5種類の文書と、標準に関わる3種類の文書がある。
19
MT-0595A
【11.1】
ソフトウェア認証計画(Plan for Software Aspects of Certification)は、申請者が規定された通り、正しくソフトウェア開
発を実施しようとしているかを認証機関が判断するための文書である。後述する認証連絡調整プロセス
(Certification Liaison Process)の成果物でもある。
《11.1》ソフトウェア認証計画(Plan for Software Aspects of Certification)
ソフトウェア認証計画(PSAC)は、申請者が開発しようとしているソフトウェアのレベルに要求される厳格さに相当
するソフトウェアライフサイクルを提案しているかどうかを判断するために、認証機関によって使用される主要な
手段である。
この計画書には以下が含まれる。
(a) システム概要(System Overview)
システムの機能とそのハードウェア／ソフトウェア配分、システム構成、使用するプロセッサー、ハードウェ
ア／ソフトウェアインターフェース、安全性について記載する。
(b) ソフトウェア概要(Software Overview)
機能、特に安全性とパーティショニングコンセプトに関した機能（例えば、リソースの配分、冗長設計、マル
チバージョン・デシミュラ、フォールトトレランス、タイミング、スケジューリング）について記載する。
(c)
認証の考慮事項(Certification Consideration)
ソフトウェア認証に関わる事項（準拠の方法を含む）をまとめる。また、提案されたソフトウェアレベルについ
て記載するとともに、システム安全評価プロセスからのソフトウェアレベルの正当性について概要を記す。
(d) ソフトウェアライフサイクル(Software Life Cycle)
今回適用するソフトウェアライフサイクルを定義し、各プロセスの概略を記載する。その記載の中でDO178Cで要求されている目的(Objectives)をどのように実現するかを説明する。また実行する組織、及びその
責任についても明確にする。
(e) ソフトウェアライフサイクルデータ(Software Life Cycle Data)
ソフトウェアライスサイクルプロセスで作成するソフトウェアライフサイクルデータについて定義する。また
20
MT-0595A
データ間の関連性、システムで定義されたデータとの関連性、認証機関に提供されるデータについても記載
する。
(f)
スケジュール(Schedule)
申請者がソフトウェアライフサイクルプロセスの活動を可視化して認証機関に提供するために使用する方法
について記載する。
(g) 追加の考慮事項(Additional Considerations)
認証プロセスに影響を及ぼす特殊事項について記載する。準拠の代替方法、ツールの認証、既開発ソフト
ウェア、オプション選択可能なソフトウェア(option-selectable software)、ユーザ変更可能なソフトウェア(usermodifiable software)、COTS、フィールドロード可能なソフトウェア(field-loadable software)、マルチバージョン
デシミュラ、製品サービス履歴など。
(h) サプライヤの監督(Supplier oversight)
サプライヤのプロセスやアウトプットが承認されたソフトウェア計画や標準に準拠することを保証する手段に
ついて記載する。
《11.1》
20
MT-0595A
【11.2】
ソフトウェア開発計画(Software Development Plan)は、ソフトウェア開発プロセス(Software Development Process)にお
ける計画を策定する文書である。この文書は、ソフトウェア認証計画(Plan for Software Aspects of Certification)に含
まれてもよい。
《11.2》 ソフトウェア開発計画(Software Development Plan)
ソフトウェア開発計画(SDP)は、ソフトウェア開発プロセスの目的を満足させるために使用されるソフトウェア開発
手順とソフトウェアライフサイクルに関する記載である。これは、ソフトウェア認証計画(PSAC)に含まれてもよい。
この計画書の構成を以下に示す。
(a) 標準(Standards)
このプロジェクトで適用されるソフトウェア要求標準(Software Requirements Standards)、ソフトウェア設計標
準(Software Design Standards)、ソフトウェアコード標準(Software Code Standards)を特定する。COTSソフト
ウェアを含む既開発ソフトウェアを使用する場合、その開発で使用した標準が異なっている際は、その標準
も参照する。
(b) ソフトウェアライフサイクル(Software Life Cycle)
このプロジェクトで使用されるソフトウェアライフサイクルプロセス（ソフトウェア開発プロセスの移行基準を
含む）を記述する。この記述は、ソフトウェア認証計画(PSAC)内に記載された概要とは違うものであり、そ
の中で、ソフトウェアライフサイクルプロセスにおける適切な実装を保証するための詳細な必須項目を提供
する。
(c) ソフトウェア開発環境(Software Development Environment)
ソフトウェア開発プロセスで使用する環境について、ハードウェア、ソフトウェアの側面から記載する。
1. 使用される要求開発手法、ツール
2. 使用される設計手法、ツール
3. 使用されるコーディング手法、プログラミング言語、コーディングツール、必要に応じて自動コード生成ツ
21
MT-0595A
ールのオプションと制約
4. 使用されるコンパイラ、リンカー、ローダー
5. 使用されるツールのハードウェアプラットフォーム
《11.2》
以上に示したように、この文書は、今後のソフトウェア開発プロセスを実施していく上での必要となる情報を具体的な
レベルで網羅することが求められている。
３つの標準と合わせて、設計の方法論や表記法、使用するツールを厳密に定め、計画書というよりむしろ要領書の要
素が濃い文書と言える。
21
MT-0595A
【11.3】
ソフトウェア検証計画では、ソフトウェア検証プロセスの目的を満足するための検証手順について記載する。
これらの手順はソフトウェアレベルに応じて変更してよい。
《11.3》 ソフトウェア検証計画(Software Verification Plan)
ソフトウェア検証計画(SVP)は、ソフトウェア検証プロセスの目的を満足させるために使用される検証手順の記載
である。これらの手順は、Annex Aの表に定義されたソフトウェアレベルに応じて変更してもよい。
この計画は以下を含む。
(a) 組織(Organization)
ソフトウェア検証プロセスにおける組織的な責任と他のソフトウェアライフサイクルプロセスとのインター
フェースについて記載する。
(b) 独立(Independence)
独立した第三者組織が検証プロセスを実施することが求められている場合においては、独立性を確立する
ための方法について記載する。
(c) 検証手法(Verification methods)
検証プロセスの各活動で採用する手法について記載する。
1. レビュー手法 例えば、チェックリスト等
2. 分析手法
例えば、トレーサビリティ、カバレッジ分析
3. テスト手法
例えば、テストケース作成、テスト手順、テストデータ生成のガイドライン
(d) 検証環境(Verification environment)
テスト装置、テスト・分析ツール、ツール適用のガイドライン、ハードウェアテスト装置などを記述する。
22
MT-0595A
(e) 検証プロセスへの移行基準(Transition criteria)
ソフトウェア検証プロセスに移行するための基準について記述する。
(f)
パーティショニングの考慮事項(Partitioning considerations)
パーティショニングが使われる場合は、パーティショニングの完全性を検証する手法について記述する。
(g) コンパイラの前提(Compiler assumptions)
コンパイラ、リンカー、ローダの正確性についての申請者が設定した前提について記述する。
(h) 再検証ガイドライン(Reverification Guidelines)
ソフトウェアの変更に関して、ソフトウェアの影響する部分と、実行可能オブジェクトコードの変更部分を特定
する方法について記述する。再検証は、以前に報告されたエラーが除去されたことを保証しなければならな
い。
(i)
既開発ソフトウェア(Previously developed software)
既開発ソフトウェアに関して、もし検証プロセスの準拠基準がDO-178Cに準拠していなかったら、DO-178C
の目的を満足させる方法について記述する。
(j)
マルチバージンデシミュラ(Multiple-version dissimilar software)
マルチバージョンデシミュラが使われるのであれば、ソフトウェア検証プロセス活動について記述する。
《11.3》
22
MT-0595A
【11.4】
ソフトウェアライフサイクル全体を通して実施されるソフトウェア形態管理プロセスについてその実施方法を記載する
。
ソフトウェア形態管理プロセスにおける詳細の活動については「6.ソフトウェア形態管理プロセス」を参照。
《11.4》 ソフトウェア形態管理計画(Software Configuration Management Plan)
ソフトウェア形態管理計画は、ソフトウェアライフサイクルの間、SCMプロセスの目的を達成するために使用される方
法を確立する。
この計画は以下を含む。
(a) 環境(Environment)
使用されるSCM環境についての記載（含む手順、ツール、手法、標準、組織的な責任、インターフェース）。
(b) 活動(Activities)
ソフトウェアライフサイクルにおけるSCMプロセスの活動についての記載。
1. 形態識別(Configuration identification)
識別されるべき項目、いつそれらは識別されるのか、ソフトウェアライフサイクルデータを識別する方法（例
えば、部品番号）、及びソフトウェア識別とシステムまたは装置の識別との関連について。
2. ベースラインとトレーサビリティ(Baselines and traceability)
ベースラインを設定する方法、どんなベースラインが設定されるのか、いつ設定されるのか、ソフトウェアラ
イブラリの管理、形態項目とベースラインのトレーサビリティについて。
3. 不適合報告(Problem reporting)
ソフトウェア製品、及びソフトウェアライフサイクルプロセスに対する不適合報告の目次と識別、いつ起草さ
れるのか、不適合報告をクローズする方法、変更管理活動との関係について。
23
MT-0595A
4. 変更管理(Change control)
管理されるべき形態項目とベースライン、いつ管理されるのか、それらを管理する不適合／変更管理活動、
事前認証管理、事後認証管理、ベースラインと形態項目の完全性を保護する方法について。
5. 変更レビュー(Change review)
ソフトウェアライフサイクルプロセス間のフィードバックを取り扱う方法、不適合の評価・優先順位付けの方法
、変更の承認方法、それらの解決もしくは変更実装を管理する方法、これらの方法と不適合報告、変更管理活
動との関係について。
6. 形態ステータス報告(Configuration status accounting)
形態管理ステータスを報告するために記録されたデータ、それらのデータをどこに保管し、報告のためにどの
ように取得し、いつ利用可能であるかについて。
7. 保管、取得、リリース(Archive, retrieval and release)
完全性の管理、リリース方法、権限、データ保持について。
8. ソフトウェアロード管理(Software load control)
ソフトウェアロード管理保護と記録についての記載。
9. ソフトウェアライフサイクル環境管理(Software life cycle environment controls)
開発、ビルド、検証、ソフトウェアのロード、上記1.から7.に使用されるツールの管理について。資格化された
ツールの管理も含まれる。
10. ソフトウェアライフサイクルデータ管理(Software life cycle data controls)
形態管理カテゴリCC１及びCC２に関連する管理について。
(c) 移行基準(Transition criteria)
SCMプロセスに移行する基準について。
(d) ソフトウェア形態管理データ(SCM data)
SCMプロセスで作成されるソフトウェアライフサイクルデータの定義、含む、ソフトウェア形態管理記録、ソフトウ
ェア形態索引、ソフトウェアライフサイクル環境形態索引。
(e) サプライヤ管理(Supplier control)
SCMプロセス要求をサプライヤに適用する方法について。
《11.4》
23
MT-0595A
【11.5】
ソフトウェア品質保証計画では、ソフトウェア品質保証プロセスの目的を達成するために使用される手法について設
定する。
ソフトウェア品質保証計画には、プロセス改善、計測、進捗管理の方法についても記載してよい。
《11.5》 ソフトウェア品質保証計画(Software Quality Assurance Plan)
ソフトウェア品質保証計画は、SQAプロセスの目的を達成するために使用される方法を確立する。SQA計画は、プロ
セス改善、計測、進捗管理方法の記載を含んでもよい。
この計画は以下を含む。
(a) 環境(Environment)
SQA環境の記載、含む範囲、組織的な責任、インターフェース、標準、手順、ツール、手法について。
(b) 権威(Authority)
SQAの権威、責任、独立性の記載、含むソフトウェア製品のSQA認証。
(c) 活動(Activities)
ソフトウェアライフサイクルの間、各ソフトウェアライフサイクルプロセスにて実施されるSQAの活動。以下を含
む。
1. SQAの手法、例えば、ソフトウェアライフサイクルプロセスのレビュー、監査、報告、検査、モニタリング。
2. 不適合報告、追跡、是正に関わる活動。
3. ソフトウェア適合性レビュー活動についての記述。
(d) 移行基準(Transition criteria)
SQAプロセスに移行するための基準について記載する。
(e) タイミング(Timing)
24
MT-0595A
ソフトウェアライフサイクルプロセスの活動と関連して、ソフトウェア品質保証プロセスの活動のタイミングについ
て。
(f)
ソフトウェア品質保証記録(SQA Records)
SQAプロセスで作成される記録の定義について。
(g) サプライヤ監督(Supplier oversight)
サプライヤのプロセスと成果物が計画と標準に準拠していることを保証するための方法について。
《11.5》
24
MT-0595A
【11.6】
ソフトウェア要求標準は、ソフトウェア要求プロセスにおいて、ソフトウェア上位要求を設定する際に使用される手法
、ルール、ツールを定義する。
《11.6》 ソフトウェア要求標準(Software Requirements Standards)
ソフトウェア要求標準は、ソフトウェア上位要求を作るために使用される方法、ルール、ツールを定義する。
この標準には以下を含む。
(a) ソフトウェア要求を設定するために使用する手法、例えば、構造化手法など。
(b) 要求を表現するために使用する表記法、例えば、データフローダイアグラム、形式仕様言語など。
(c) 要求設定に使用されるツールの使用に関しての制約。
(d) 派生要求をシステムプロセスへ提供するときに使用される方法。
《11.6》
25
MT-0595A
【11.7】
ソフトウェア設計標準は、ソフトウェア設計プロセスにおいて、ソフトウェア構造とソフトウェア下位要求を設定する際
に使用される手法、ルール、ツールを定義する。
《11.7》 ソフトウェア設計標準(Software Design Standards)
ソフトウェア設計標準は、ソフトウェア構造とソフトウェア下位要求を作るために使用される方法、ルール、ツールを
定義する。
この標準には以下を含む。
(a) 使用される設計記述手法
(b) 使用される命名規約
(c) 許可された設計手法に課せられた条件、例えば、スケジューリング、割り込みとイベント駆動構造の使用、動的
タスク、リエントリ構造、グローバルデータ、例外処理、それらの使用の合理性。
(d) 設計ツールの使用の制約
(e) 設計の制約、例えば、再帰呼び出し、動的オブジェクト、データエイリアス、コンパクト表現など。
(f)
複雑度の制限、例えば、階層化された呼び出し、条件構造の最大階層、無条件ブランチの使用、入出力ポイン
トの数など。
《11.7》
26
MT-0595A
【11.8】
ソフトウェアコード標準は、ソフトウェアをコーディングする際に使用するプログラミング言語、手法、ルール、ツール
を定義する。
《11.8》 ソフトウェアコード標準(Software Code Standards)
ソフトウェアコード標準は、ソフトウェアをコーディングするために使用されるプログラミング言語、手法、ルール、ツー
ルを定義する。
この標準には以下を含む。
(a) 使用されるプログラミング言語と定義されたサブセット。プログラミング言語における、文法、制御の振る舞い、
データの振る舞い、言語の副作用を完全に定義したデータの参照。ここでは、言語の持ついくつかの機能の使
用を制限してもよい。
(b) ソースコード標準、例えば、行数制限、インデント、空白行の使用など、及びソースコードの文書標準、例えば、
著者名、リビジョン、入出力データ、関連するグローバルデータなど。
(c) コンポーネント、サブプログラム、変数、定数の命名規約
(d) コード規約に課せられた条件と制約、例えば、ソフトウェアコンポーネント間の結合度、論理表現、数値表現の
複雑度、それらの使用の合理性。
(e) コーディングツールの使用の制約
《11.8》
27
MT-0595A
【5】
28
MT-0595A
【5】
このフローはソフトウェア開発プロセスと関連するソフトウェア検証プロセスの関係を示している。
左のブルーのフローがソフトウェア開発プロセスを示し、グリーンのブロックがそのプロセスにおける成果物を示して
いる。
中央右のピンクのブロックはソフトウェア検証プロセス内の「レビュー／分析」であり、主として成果物を対象としてい
る（一部プロセスを対象とする）。右のオレンジのブロックは「レビュー／分析」の結果をまとめた成果物である。
以降、ソフトウェア開発プロセスの各プロセスについて説明する。
このフローにあるように、ソフトウェア開発プロセスは、ソフトウェア検証プロセスの「レビュー／分析」と並行して実施
される。
従って、以降の説明においても次の順に進めることとする。
(1)各開発プロセスの説明（ブルーのブロック）
(2)レビュー／分析の説明（ピンクのブロック）
(3)成果物の説明（グリーンのブロック）
29
MT-0595A
【5.1】
ここでは、ソフトウェア要求プロセス(Software Requirements Process)について説明する。
ソフトウェア要求プロセスは、システムからのシステム要求をインプットとして、ソフトウェア上位要求(High-Level
Requirements)、及び派生ソフトウェア上位要求(Derived High-Level Requirement)を設定するものである。これらのア
ウトプットは成果物としてソフトウェア要求データ(Software Requirements Data)にまとめられる。
システム・ライフサイクル・プロセス(System Life Cycle Process)より以下をインプットとして受ける。
(a) システム要求(System Requirement)
(b) ハードウェアインターフェース
(c) システムアーキテクチャー
ソフトウェア計画プロセス(Software Planning Process)より以下をインプットとして受ける。
(a) ソフトウェア開発計画(Software Development Plan)
(b) ソフトウェア要求標準(Software Requirement Standards)
30
MT-0595A
【Table A-2】
ソフトウェア要求プロセスで生成されるソフトウェア上位要求(High-Level Requirements)は、世間一般で言われてい
るところのソフトウェア機能仕様と捉えて良い。
DO-178Cでは、あくまでもこのプロセスのインプットであるシステム要求を基本として必ず双方向にトレースが取れる
ことを求めている。派生ソフトウェア上位要求(Derived High-Level Requirements)とは、システム要求とトレースがで
きない要求であり、このプロセスで新たに発生した要求のことである。派生ソフトウェア上位要求は、上位のプロセス
であるシステム安全評価プロセス(system safety assessment process)に提供され再評価されなければならない。
《5.1.1》 ソフトウェア要求プロセスの目的(Software Requirements Process Objectives)
ソフトウェア要求プロセスの目的は以下である。
(a)ソフトウェア上位要求が作られている。
(b) 派生ソフトウェア上位要求が定義されており、システム安全性評価プロセスを含むシステムプロセスに提供さ
れている。
《5.1.1》
《5.1.2》 ソフトウェア要求プロセスの活動(Software Requirements Process Activities)
ソフトウェア要求プロセスへのインプットには、システムライフサイクルプロセスからのシステム要求、ハードウェ
アインターフェース、システムアーキテクチャ(もし要求に含まれないなら)、及びソフトウェア計画プロセスからの
ソフトウェア開発計画、ソフトウェア要求標準が含まれる。
計画された移行基準を満たしたとき、これらのインプットが上位要求の作成に使用される。
このプロセスの主たるアウトプットはソフトウェア要求データである(11.9章参照)。
ソフトウェア要求プロセスは、その目的と関連するインテグラルプロセスの目的が満たされたとき完了する。
このプロセスにおける活動を以下に示す。
31
MT-0595A
(a) ソフトウェアに求められたシステムの機能・性能要求のあいまいな点、矛盾点、未定義の状態について分析
されなければならない。
(b) 不十分、不正として検出された本プロセスへのインプットは、明瞭化、訂正のためにそのインプットを作成し
たプロセスに対して報告されなければならない。
(c) ソフトウェアに求められた各システム要求は、ソフトウェア上位要求(High-Level Requirements)として挙げら
れなければならない。
(d) システムハザードを防ぐソフトウェア上位要求が定義されなければならない。
(e) ソフトウェア上位要求はソフトウェア要求標準(Software Requirements Standards)に準拠しており、検証可能
であり、一貫性がなければならない。
(f)
ソフトウェア上位要求は、適切な場所において、公差を定量的に表現していなければならない。
(g) ソフトウェア上位要求は、設計および検証の詳細を記述してはならない。ただし特定された正当な設計制約
を除いて。
(h) 派生ソフトウェア上位要求とその存在の理由が定義されなければならない。
(i)
派生ソフトウェア上位要求はシステム安全性評価プロセスを含む、システムプロセスに提供されなければな
らない。
(j)
パラメータデータ項目が計画されているのであれば、ソフトウェア上位要求にはソフトウェアによってどのよう
にパラメータデータ項目が使用されるのかが記載されるべきである。ソフトウェア上位要求では、それらの構
造、各データ要素の属性、各要素の値(適用されるのであれば)が特定されるべきである。パラメータデータ
項目の値は、パラメータデータ項目の構造とそのデータ要素の属性と一貫しているべきである。
《5.1.2》
31
MT-0595A
【Table A-3】
ここではソフトウェア要求プロセスの成果物であるソフトウェア要求データ（具体的にはソフトウェア上位要求）に対す
るレビュー／分析について説明する。レビューのポイントは表に挙げた７項目である。５項のみがソフトウェア要求プ
ロセスそのものに対するレビューである。
《6.3.1》 ソフトウェア上位要求のレビューと分析(Reviews and Analyses of High-Level Requirement)
これらのレビューと分析の活動は、ソフトウェア要求プロセスの間に入り込んだ要求レベルのエラーを検出し報
告するものである。
これらのレビューと分析の活動は、ソフトウェア上位要求において以下の目的が満足されていることを確認する
。
(a) システム要求との準拠(Compliance with system requirements)
システム要求で定義された機能要求、性能要求、安全関連要求がソフトウェア上位要求(High-Level
Requirements)に落とし込まれていることを保証する。また、派生ソフトウェア上位要求とその理由が正確に
定義されていることを保証する。
(b) 正確性・一貫性(Accuracy and consistency)
各ソフトウェア上位要求が正確で、あいまいさがなく、十分に詳細化されていることと、ソフトウェア上位要求
間に不整合がないことを保証する。
(c) ターゲットコンピュータとの整合性(Compatibility with the target computer)
ソフトウェア上位要求とターゲットコンピュータのハードウェア・ソフトウェア特性（特にシステム応答時間、入
出力ハードウェア）の間に不整合がないことを保証する。
(d) 検証可能性(Verifiability)
ソフトウェア上位要求が検証可能であることを保証する。
(e) 標準の準拠(Conformance to standards)
32
MT-0595A
ソフトウェア要求プロセスにおいてソフトウェア要求標準(Software Requirements Standards)に準拠して作業さ
れていることを保証する。また、逸脱があった場合は正当な理由があることを保証する。
(f)
トレース可能性(Traceability)
システムの機能要求、性能要求、安全要求がソフトウェア上位要求に反映されていることを保証する。
(g) アルゴリズム(Algorithm aspects)
提案されたアルゴリズムの正確性、ふるまいについて保証する。
《6.3.1》
32
MT-0595A
【11.9】
ソフトウェア要求プロセスの成果物はソフトウェア要求データ(Software Requirement Data)である。
ソフトウェア要求データ(Software Requirement Data)には、派生要求を含むソフトウェア上位要求(High-Level
Requirements)を定義する。
《11.9》 ソフトウェア要求データ(Software Requirement Data)
ソフトウェア要求データは、派生要求を含むソフトウェア上位要求(High-Level Requirements)の定義である。
ここでは、以下が記載されなければならない。
(a) 安全関連要求と潜在的な故障状態に注意したシステム要求のソフトウェアへの割り当ての記述
(b) 各運用モードにおける機能要求、運用要求
(c) 性能基準（精度、正確さ）
(d) タイミング要求、制約
(e) メモリ容量の制約
(f)
ハードウェアとソフトウェアインターフェース、例えば、プロトコル、フォーマット、入力周期、出力周期など
(g) フェール検知、安全モニター要求
(h) ソフトウェアに割り当てられたパーティショニング要求、パーティショニングされたソフトウェアコンポーネント間の
通信方法、各パーティションのソフトウェアレベル
33
MT-0595A
《11.9》
33
MT-0595A
【5.2】
ここでは、ソフトウェア設計プロセス(Software Design Process)について説明する。
ソフトウェア設計プロセスは、ソフトウェア上位要求(high-Level Requirements)からソフトウェア構造(Software
Architecture)とソフトウェア下位要求(Low-Level Requirements)、及び派生ソフトウェア下位要求(Derived Low-Level
Requirements)を設定するものである。これらのアウトプットは成果物として設計記述(Design Description)にまとめら
れる。
ソフトウェア要求プロセス(Software Requirements Process)より以下をインプットとして受ける。
(a) ソフトウェア要求データ(Software Requirements Data)
ソフトウェア計画プロセス(Software Planning Process)より以下をインプットとして受ける。
(a) ソフトウェア開発計画(Software Development Plan)
(b) ソフトウェア設計標準(Software Design Standards)
34
MT-0595A
【Table A-2】
ソフトウェア設計プロセスは、世間一般で言うところのソフトウェア構造設計とソフトウェア詳細設計がひとつになった
ものと言える。
DO-178Cでは、設計の結果としてソフトウェア構造(Software Architecture)とソフトウェア下位要求(Low-Level
Requirements)の２つを挙げている。
ソフトウェア構造は、クラス図、・・・といった設計文書をいい、ソフトウェア下位要求はユニット単位の動作を規定した
文書（フローチャート、ＰＤＬ、・・・）と言える。
後述するが、ソフトウェア下位要求はソースコードとのトレーサビリティを取る必要があるため、かなり粒度の細かい
レベルでの記述を求めている。
《5.2.1》 ソフトウェア設計プロセスの目的(Software Design Process Objectives)
ソフトウェア設計プロセスの目的は以下である。
(a) ソフトウェア上位要求からソフトウェア構造、及びソフトウェア下位要求が作られている。
(b) 派生ソフトウェア下位要求が定義されており、システム安全性評価プロセスを含むシステムプロセスに提供
されている。
《5.2.1》
《5.2.2》 ソフトウェア設計プロセスの活動(Software Design Process Activities)
ソフトウェア設計プロセスのインプットは、ソフトウェア要求データ、ソフトウェア設計計画、ソフトウェア設計標準
である。
計画された移行基準を満たしたとき、ソフトウェア設計プロセスにおいて、ソフトウェア構造とソフトウェア下位要
求を作り出すためにソフトウェア上位要求が使用される。ひとつもしくはそれ以上の要求の下位レベルを含んで
もよい。
このプロセスの主たるアウトプットはソフトウェア構造とソフトウェア下位要求を含んだ設計記述である(11.10章
35
MT-0595A
参照)。
ソフトウェア設計プロセスは、その目的と関連するインテグラルプロセスの目的が満たされたとき完了する。
このプロセスにおける活動を以下に示す。
(a) ソフトウェア下位要求(Low-Level Requirements)とソフトウェア構造(Software Architecture)は、ソフトウェア設
計標準(Software Design Standards)に準拠しており、検証可能であり、一貫性がなければならない。
(b) 派生要求は、ソフトウェア上位要求に抵触しないことを保証するために分析されなければならない。
(c) 可能な故障モードをソフトウェアに取り入れることができる。逆にそれ以外の故障モードは取り入れない。ソ
フトウェア設計におけるパーティショニング、または別の構造上の仕組みにより、いくつかのコンポーネントの
ソフトウェアレベルの割り当てを変えることができる。このような場合、派生要求として定義され、システム安
全評価プロセスを含むシステムプロセスに提供されなければならない。
(d) データフローや制御フローにおけるソフトウェアコンポーネント間のインターフェースは、コンポーネント間で
一貫していることを定義しなければならない。
(e) 安全に関連する要求があるとき、制御フローやデータフローは監視されなければならない。例えば、ウォッチ
ドッグタイマー、合理性検査、クロスチャンネル比較(cross-channel comparisons)。
(f)
故障状態への対応は、安全関連要求と一致していなければならない。
(g) 本プロセスにて検出された不十分、不正なインプットは、明瞭化、訂正のために、システム・ライフサイクル・
プロセス(System Life Cycle Process)、ソフトウェア要求プロセス(Software Requirements Process)、ソフトウェ
ア計画プロセス(Software Planning Process)のいずれかに提供されなければならない。
《5.2.2》
《5.2.3》 ユーザが変更可能なソフトウェアの設計(Designing for User-Modifiable Software)
ユーザが変更可能なソフトウェアはそのユーザによって変更されるように設計されている。変更可能なコンポーネ
ントは、ユーザによって意図的に変更されるソフトウェアの部品であり、変更不可能なコンポーネントは、ユーザに
よって意図的に変更できないものである。ユーザが変更可能なソフトウェアは複雑に様々な形をとる。例えば、装
置のオプションの二つの内の一つを選ぶために一つのメモリビットが使われる、メッセージのテーブルや、維持機
能のためのプラグラム、コンパイル、リンクが可能なメモリエリアなどである。いろいろなレベルのソフトウェアが変
更可能なコンポーネントには含まれる。
ユーザが変更可能なソフトウェアの活動には以下が含まれる。
(a) 変更不可能なコンポーネントは、その安全な操作における干渉を防ぐために変更可能なコンポーネントから
保護されるべきである。この保護は変更するときに使用されるハードウェア、ソフトウェア、ツールによって、
もしはその3つの組み合わせによって実行されるべきである。もし、その保護がソフトウェアによって提供され
る場合、そのソフトウェアは変更不可能なソフトウェアと同じソフトウェアレベルで設計され、検証されるべき
である。もし、その保護がツールによって提供される場合、そのツールは12.2章の定義に従って分類され、資
格化されるべきである。
(b) 変更可能なコンポーネントを変更するために提供された方法は、変更可能なコンポーネントを変更できる唯
一の方法として示されるべきである。
《5.2.3》
《5.2.4》 実行されないコードの設計(Designing for Deactivated Code)
システムや装置はいくつかの形態を含んだ形で設計されてもよく、全てのアプリケーションで全てが意図的に使用
されなくてもよい。これは、選ばれなかった機能、使用されないライブラリ機能、使用されないデータと言った実行
されることのないコードを導き出す。実行されないコードはデッドコードとは異なる。
実行されないコードの活動には以下が含まれる。
35
MT-0595A
(a) 実行されない機能もしくはコンポーネントが実行される機能もしくはコンポーネントに不都合なインパクトを与
えないことを保証するためのメカニズムが設計され、実装されるべきである。
(b) 実行されないコードがその使用を意図していない環境において使用不可になっていることの根拠が提供可
能であるべきである。システムの異常な状態による実行されないコードの実行は、実行されるコードの意図し
ない実行と同じである。
(c) 実行されないコードの開発は、実行されるコードの開発と同様に、DO-178Cの目的に準拠するべきである。
《5.2.4》
35
MT-0595A
【Table A-4】
ここではソフトウェア設計プロセスの成果物のひとつであるソフトウェア下位要求に対するレビュー／分析について
説明する。レビューのポイントは表に挙げた７項目である。５項のみがソフトウェア設計プロセスそのものに対するレ
ビューである。
《6.3.2》 ソフトウェア下位要求のレビューと分析(Reviews and Analyses of Low-Level Requirement)
これらのレビューと分析の活動は、ソフトウェア設計プロセスの間に入り込んだ要求レベルのエラーを検出し報
告するものである。
これらのレビューと分析の活動は、ソフトウェア下位要求において以下の目的が満足されていることを確認する
。
(a) ソフトウェア上位要求との準拠(Compliance with High-Level requirements)
ソフトウェア下位要求(Low-Level Requirements)がソフトウェア上位要求を満足していることを保証する。ま
た、派生要求とその設計理由が正確に定義されていることを保証する。
(b) 正確性・一貫性(Accuracy and consistency)
各ソフトウェア下位要求が正確で、あいまいさがないことと、ソフトウェア下位要求間に不一致がないことを
保証する。
(c) ターゲットコンピュータとの整合性(Compatibility with the target computer)
ソフトウェア下位要求とターゲットコンピュータのハードウェア・ソフトウェア特性（特にバス負荷といったリソ
ースの使用、システム応答時間、入出力ハードウェア）に不整合がないことを保証する。
(d) 検証可能性(Verifiability)
ソフトウェア下位要求が検証可能であることを保証する。
(e) 標準の準拠(Conformance to standards)
ソフトウェア設計プロセスにおいてソフトウェア設計標準(Software Design Standards)に準拠して作業してい
36
MT-0595A
ることを保証する。また、逸脱があった場合は正当な理由があることを保証する。
(f)
トレース可能性(Traceability)
ソフトウェア上位要求と派生要求がソフトウェア下位要求に反映されていることを保証する。
(g) アルゴリズム(Algorithm aspects)
提案されたアルゴリズムの正確性、ふるまいについて保証する。
《6.3.2》
36
MT-0595A
【Table A-4】
ここではソフトウェア設計プロセスのもうひとつの成果物であるソフトウェア構造に対するレビュー／分析について説
明する。レビューのポイントは表に挙げた６項目である。５項のみがソフトウェア設計プロセスそのものに対するレビ
ューである。
《6.3.3》 ソフトウェア構成のレビューと分析(Reviews and Analyses of Software Architecture)
これらのレビューと分析の活動は、ソフトウェア構成の開発の間に入り込んだエラーを検出し報告するものであ
る。
これらのレビューと分析の活動は、ソフトウェア構成が以下の目的が満足していることを確認する。
(a) ソフトウェア上位要求との整合性(Compatibility with the High-Level requirements)
ソフトウェア構造(Software Architecture)がソフトウェア上位要求を満足していることを保証する。
(b) 一貫性(Consistency)
ソフトウェア構造の各コンポーネント間に正確な関連性があることを保証する。この関連性はデータフロー
やコントロールフローとして表現される。
(c) ターゲットコンピュータとの整合性(Compatibility with the target computer)
ソフトウェア構造とターゲットコンピュータのハードウェア・ソフトウェア特性（特に初期化、非同期動作、同期
、割り込み）に不整合がないことを保証する。
(d) 検証可能性(Verifiability)
ソフトウェア構造が検証可能であることを保証する。例えば、限界の定められていない再帰呼び出しがない
など。
(e) 標準の準拠(Conformance to standards)
ソフトウェア設計プロセスにおいてソフトウェア設計標準(Software Design Standards)に準拠して作業してい
ることを保証する。また、逸脱があった場合は正当な理由があることを保証する。例えば、複雑度の制限や
37
MT-0595A
設計構成のルールなど。
(f)
パーティショニング(Partitioning integrity)
パーティショニング違反が防がれていることを保証する。
《6.3.3》
37
MT-0595A
【11.10】
本プロセスの成果物は設計記述(Software Description)である。
設計記述(Software Description)には、ソフトウェア上位要求(High-Level Requirements)を満足するソフトウェア構造
(Software Architecture)とソフトウェア下位要求(Low-Level Requirements)を定義する。
《11.10》 設計記述(Design Description)
設計記述は、ソフトウェア上位要求(High-Level Requirements)を満足するソフトウェア構造(Software Architecture)と
ソフトウェア下位要求(Low-Level Requirements)の定義である。
ここでは、以下が記載されなければならない。
(a) ソフトウェアが指定されたソフトウェア上位要求をどのように満足しているか（含むアルゴリズム、データ構造）、
またソフトウェア要求がどのようにプロセッサとタスクに割り当てられているかの詳細な記述。
(b) 要求を実装するためのソフトウェア構成を定義したソフトウェア構造(Software Architecture)の記述。
(c) 入出力の記述。例えば、ソフトウェア構造の内部、及び外部のデータ辞書。
(d) 設計のデータフロー及び制御フロー。
(e) リソースの制限。各リソースの管理、その制限、マージンの戦略とそれらのマージンの計測方法。例えばタイミ
ングとかメモリ。
(f)
スケジューリング手順、プロセッサ間／タスク間の通信方法。例えば、時間に厳格なシーケンス、プリエンプティ
ブなスケジューリング、Adaランデブー、割り込み。
(g) 設計方法と実装の詳細。例えば、ソフトウェアローディング、ユーザ変更可能ソフトウェア、マルチバージョンデ
38
MT-0595A
シミュラソフトウェア。
(h) パーティショニング方法、パーティショニング違反を防ぐ方法。
(i)
ソフトウェアコンポーネント（新規作成、既作成いずれも）の記述。もし、既作成であればそれらのベースライン。
(j)
ソフトウェア設計プロセスに発生した派生要求。
(k) システムが実行されないコードを含んでいる場合、そのコードがターゲットコンピュータ上で実行されないことを保
証する方法。
(l)
安全関連システム要求にトレース可能な設計判断の合理的根拠。
《11.10》
38
MT-0595A
【11.10】
本プロセスの成果物は設計記述(Software Description)である。
設計記述(Software Description)には、ソフトウェア上位要求(High-Level Requirements)を満足するソフトウェア構造
(Software Architecture)とソフトウェア下位要求(Low-Level Requirements)を定義する。
39
MT-0595A
【5.3】
ここでは、ソフトウェアコーディングプロセス(Software Coding Process)について説明する。
ソフトウェアコーディングプロセスにおいては、ソフトウェア構造(Software Architecture)とソフトウェア下位要求(LowLevel Requirements)からソースコードが実装される。ソースコードはトレース・検証が可能であり、一貫性があり、正し
くソフトウェア下位要求を実装されなければならない。
ソフトウェア設計プロセス(Software Design Process)より以下をインプットとして受ける。
(a) ソフトウェア下位要求(Software Low-Level Requirements)
(b) ソフトウェア構造(Software Architecture)
ソフトウェア計画プロセス(Software Planning Process)より以下をインプットとして受ける。
(a) ソフトウェア開発計画(Software Development Plan)
(b) ソフトウェアコーディング標準(Software Code Standards)
40
MT-0595A
【Table A-2】
《5.3.1》 ソフトウェアコーディングプロセスの目的(Software Coding Process Objectives)
ソフトウェアコーディングプロセスの目的は以下である。
(a) ソフトウェア下位要求からソースコードが作成されている。
《5.3.1》
《5.3.2》 ソフトウェアコーディングプロセスの活動(Software Coding Process Activities)
ソフトウェアコーディングプロセスのインプットは、ソフトウェア設計プロセスからのソフトウェア下位要求とソフトウ
ェア構成と、ソフトウェア開発計画、ソフトウェアコーディング標準である。計画された移行基準を満足したとき、ソ
フトウェアコーディングプロセスに移行する、もしは再移行してよい。このプロセスで作成されたコードはソフトウェ
ア構成とソフトウェア下位要求を基本としている。
主なこのプロセスのアウトプットはソースコードである(11.11章参照)。
ソフトウェアコーディングプロセスは、その目的と関連するインテグラルプロセスの目的を満たしたとき完了する。
このプロセスの活動について以下に示す。
(a) ソースコードはソフトウェア下位要求(Low-Level Requirements)を実装し、ソフトウェア構造(Software
Architecture)に準拠しなければならない。
(b) ソースコードはソフトウェアコード標準(Software Code Standards)に準拠しなければならない。
(c) 本プロセスにて検出された不十分、不正なインプットは、明瞭化、訂正のために、ソフトウェア要求プロセス
(Software Requirements Process)、ソフトウェア設計プロセス(Software Design Process)、ソフトウェア計画プ
ロセス(Software Planning Process)のいずれかに提供されなければならない。
41
MT-0595A
(d) 自動コード生成ツールの使用は、計画プロセスにて定義した制約に準拠しなければならない。
《5.3.2》
41
MT-0595A
【Table A-5】
ここではソフトウェアコーディングプロセスの成果物であるソースコードに対するレビュー／分析について説明する。
レビューのポイントは表に挙げた６項目である。
《6.3.4》 ソースコードのレビューと分析(Reviews and Analyses of Source Code)
これらのレビューと分析の活動は、ソフトウェアコーディングプロセスの間に入り込んだ要求レベルのエラーを検
出し報告するものである。主たる関心事は、ソフトウェア要求、ソフトウェア構成、ソフトウェアコーディング標準へ
の準拠と言う点において、コードを修正することである。
これらのレビューと分析の活動は、通常ソースコードに限られており、ソースコードが以下の目的を満足している
ことを確認する。
(a) ソフトウェア下位要求との準拠(Compliance with Low-Level requirements)
ソースコードがソフトウェア下位要求(Low-Level Requirements)に対して正確であり、完全であることを保証
する。また、文書化されていない機能が実装されていないことを保証する。
(b) ソフトウェア構造との準拠(Compliance with the Software Architecture)
ソースコードがソフトウェア構造(Software Architecture)で定義されたデータフローとコントロールフローと整
合することを保証する。
(c) 検証可能性(Verifiability)
ソースコードに検証不可能なコードや構造が含まれていないことを保証する。また、ソースコードを書き換え
ることなくテスト可能なことを保証する。
(d) 標準の準拠(Conformance to standards)
コーディングにおいてソフトウェアコーディング標準(Software Code Standards)（特にシステムの安全性に密
着した複雑度の制限とコードの制約）に準拠していることを保証する。複雑度にはソフトウェアコンポーネン
ト間の結合度、制御構造のネストのレベル、論理または数値表現の複雑さが含まれる。また、逸脱があっ
た場合は正当な理由があることを保証する。
42
MT-0595A
(e) トレース可能性(Traceability)
ソフトウェア下位要求がソースコードに反映されていることを保証する。
(f)
正確性・一貫性(Accuracy and consistency)
ソースコードが正確で、堅牢であることを保証する。例えば、スタックの使い方、固定小数点演算のオーバー
フローと精度、リソース競合、最悪ケースでの実行タイミング、例外処理、初期化なしの変数・定数の使用、
使用していない変数・定数、タスクや割り込みの衝突によるデータの変更。コンパイラ(含むそのオプション)、
リンカー(含むそのオプション)、いくつかのハードウェアの特徴は最悪ケースの実行タイミングにインパクトを
与える、このインパクトは評価すべきである。
《6.3.4》
42
MT-0595A
【11.11】
《11.11》 ソースコード(Source Code)
ソースコードはソース言語で書かれたコードから構成される。
ソースコードは、統合プロセスにてコンパイルデータ、リンクデータ、そしてロードデータと共に使用され、統合された
システム、または装置を作る。
各ソースコードコンポーネントにおいて、このデータには、名前、リビジョンの日付、それと（もしくは）バージョンを含む
ソフトウェア識別が含まれなければならない。
《11.11》
43
MT-0595A
【5.4】
ここでは、統合プロセス(Integration Process)について説明する。
統合プロセスは、ソースコードから実行可能オブジェクトコードを生成するプロセスである。
実行可能オブジェクトコード(Executable Object Code)はハードウェア／ソフトウェア統合のためにターゲットハードウ
ェアにロードされる。
ソフトウェア設計プロセス(Software Design Process)より以下をインプットとして受ける。
(a) ソフトウェア構造(Software Architecture)
ソフトウェアコーディングプロセス(Software Coding Process)より以下をインプットとして受ける。
(a) ソースコード(Source Code)
(b) オブジェクトコード(Object Code)
44
MT-0595A
【Table A-2】
統合プロセスは、ソフトウェア統合と、ハードウェア／ソフトウェア統合より構成される。
《5.4.1》 統合プロセスの目的(Integration Process Objectives)
統合プロセスの目的は以下である。
(a) 実行可能オブジェクトコードとそれに関連するパラメータデータ項目ファイル(もしあれば)が作られており、
ハードウェア／ソフトウェア統合のためにターゲットハードウェアにロードされている。
《5.4.1》
《5.4.2》 統合プロセスの活動(Integration Process Activities)
統合プロセスは、ソフトウェア統合とハードウェア／ソフトウェア統合より構成される。
計画された移行基準を満足したとき、統合プロセスに移行する、もしは再移行してよい。統合プロセスのインプッ
トは、ソフトウェア設計プロセスからのソフトウェア構成と、ソフトウェアコーディングプロセスからのソースコードで
ある。
統合プロセスのアウトプットはオブジェクトコード(実行可能オブジェクトコード(11.12章参照)、パラメータデータ項
目ファイル(11.22章参照)、コンパイル、リンク、ロードデータ)である。
統合プロセスは、その目的と関連するインテグラルプロセスの目的を満たしたとき完了する。
統合プロセスの活動について以下に示す。
(a) オブジェクトコードと実行可能オブジェクトコードは、ソースコードとコンパイル、リンク、ロードデータより生成
されなければならない。いくつかのパラメータデータ項目ファイルが生成されるべきである。
(b) ソフトウェア統合は、ホストコンピュータ、ターゲットエミュレータ、またはターゲットコンピュータ上で実行され
45
MT-0595A
るべきである。
(c) ソフトウェアは、ハードウェア／ソフトウェア統合のためにターゲットコンピュータにロードされなければならな
い。
(d) 本プロセスにて検出された不十分、不正なインプットは、明瞭化、訂正のために、ソフトウェア要求プロセス
(Software Requirements process)、ソフトウェア設計プロセス(Software Design Process)、ソフトウェアコーディ
ングプロセス(Software Coding Process)、ソフトウェア計画プロセス(Software Planning Process)のいずれかに
提供されなければならない。
(e) 認証された製品において使用するために提供されるソフトウェアにおいて、要求や構造の変更、ソフトウェア
検証プロセスの活動の結果発見された必要となる変更を実装するためのパッチは使用されるべきではない
。パッチは限定されたケースバイケースを基本として使用してもよい、例えば、既知のコンパイラの不具合と
いったソフトウェア開発環境の既知の欠陥を解決するために。
(f)
パッチが使用されたとき、以下が適用されるべきである。
1. ソフトウェア形態管理プロセスが効果的にパッチを追跡できることの確認。
2. パッチされたソフトウェアが全ての適用される目的を満足しているという証拠の提供のための分析。
3. ソフトウェア完了報告にパッチを使用することの正当性。
《5.4.2》
45
MT-0595A
【Table A-5】
統合プロセスの成果物が完全で正確であることを保証する。これは、リンク結果、ローディング結果、メモリマップを
詳細に検証することにより実行することができる。ここでは、誤ったハードウェアアドレス、メモリのオーバラップ、ソフ
トウェアコンポーネントの喪失などを検証する。
《6.3.5》 統合プロセスの出力のレビューと分析(Reviews and Analyses of the Outputs of the Integration Process)
これらのレビューと分析の活動は、統合プロセスの間に入り込んだ要求レベルのエラーを検出し報告するもので
ある。
この目的は以下である。
(a) 統合プロセスの出力が完全であり、性格であることを保証する。
この活動には、コンパイル、リンク及びロードのデータと、メモリマップの詳細な調査の実施が含まれる。
潜在的なエラーの典型的な例としては以下がある。
・コンパイラの警告
・誤ったハードウェアのアドレス
・メモリのオーバラップ
・ソフトウェアコンポーネントの損失
《6.3.5》
《6.6》 パラメータデータ項目の検証(Verification of Parameter Data Items)
パラメータデータ項目の検証は、以下の項目の全てが適用されるのであれば、実行可能オブジェクトコードの検
46
MT-0595A
証とは分離して実施されるべきである。
・ 実行可能オブジェクトコードが開発され、定義された構造と属性に従った全てのパラメータデータ項目が正しく取
り扱われている正常範囲テストにより検証されている。
・ 実行可能オブジェクトコードは、パラメータデータ項目ファイルの構造と属性に対してロバスト性がある。
・ パラメータデータ項目ファイルの内容による実行可能オブジェクトコードの全ての振る舞いは検証することがで
きる。
・ ライフサイクルデータの構成は、パラメータデータ項目を切り離して管理することを許す。
以上の全ての条件が合致した場合を除いて、パラメータデータ項目は他のソフトウェアから分離して検証されるべ
きではない。この場合、実行可能オブジェクトコードとパラメータデータ項目は一緒に検証されるべきである。
実行可能オブジェクトコードの検証と分離して検証可能なパラメータデータ項目にとって、以下に定義された目的
が適用される。以下の目的は、テスト、分析そしてレビューの組み合わせにより達成されてもよい。
(a) パラメータデータ項目ファイルは、ソフトウェア上位要求によって定義されたその構造の準拠していることを
検証されるべきである。この検証は、パラメータデータ項目ファイルが、ソフトウェア上位要求によって定義さ
れていない要素を含んでいないことを保証することも含まれる。パラメータデータ項目ファイル内の各データ
要素は、正しい値を保持しており、他のデータ要素との整合が取れており、ソフトウェア上位要求で定義され
たその属性に準拠していることを示すべきである。
注意： 値が固定のデータ要素にとって、それらの属性のみが検証を必要とする唯一の点である。他のケー
スでは、データ要素の値は検証を必要とする。
(b) パラメータデータ項目ファイルの全ての要素は、検証の間にカバーされている。
もしパラメータデータ項目の構造、または属性に変更があった場合、実行可能オブジェクトコードの修正と再検証
の必要性が分析されるべきである。
《6.6》
46
MT-0595A
【11.12】
本プロセスの成果物は実行可能オブジェクトコード(Executable Object Code)である。
《11.12》 実行可能オブジェクトコード(Executable Object Code)
実行可能オブジェクトコードは、ターゲットコンピュータのCPUで直接使用されるコードの形式で構成され、それゆえ、
ハードウェアもしくはシステムにロードされるソフトウェアである。
《11.12》
47
MT-0595A
【11.22】
《11.22》 パラメータデータ項目ファイル(Parameter Data Item File)
パラメータデータ項目ファイルは、ターゲットコンピュータのCPUで直接利用されるデータの形式により構成され
る。
このソフトウェアライフサイクルデータは、パラメータデータ項目のそれぞれの具体化として作られなければなら
ない。もし、分かれてパッケージされる場合は、このデータは関連する実行可能オブジェクトコードのソフトウェア
完了報告の参照を含まなければならない。
《11.22》
48
MT-0595A
【5.5】
《5.5》 ソフトウェア開発プロセストレーサビリティ(Software Development Process Traceability)
ソフトウェア開発プロセスにおけるトレーサビリティ活動には以下が含まれる。
(a) ソフトウェアに割り当てられたシステム要求とソフトウェア上位要求との間の双方向の関連性を示すトレー
スデータが作られている。
このトレースデータの目的は以下である。
1. ソフトウェアに割り当てられたシステム要求の完全な実装を検証することができる。
2. システム要求に直接トレースされない派生ソフトウェア上位要求を可視化する。
(b) ソフトウェア上位要求とソフトウェア下位要求間の双方向の関連性を示すトレースデータが作られている。
このトレースデータの目的は以下である。
1. ソフトウェア上位要求の完全な実装を検証することができる。
2. ソフトウェア上位要求に直接トレースされない派生ソフトウェア下位要求と、ソフトウェア設計プロセス間
に決定した構造設計の判断を可視化する。
(c) ソフトウェア下位要求とソースコード間の双方向の関連性を示すトレースデータが作られている。
このトレースデータの目的は以下である。
1. 文書化されていない機能を実装したソースコードがないことを検証することができる。
2. ソフトウェア下位要求の完全な実装を検証することができる。
《5.5》
49
MT-0595A
【6.4】
50
MT-0595A
【6.4】
ここでは、V字モデルの右側のプロセスとして、作成したソフトウェアの動作をテストするプロセスについて説明する。
先にも述べたようにDO-178Cでは、明確にテストをプロセスとして規定しておらず、ソフトウェア検証プロセス
(Software Verification Process)内にテスト(Software Testing)として以下の３種類のテストを定義している。
(1) ハードウェア／ソフトウェア統合テスト(Hardware/software Integration Testing)
(2) ソフトウェア統合テスト(Software Integration Testing)
(3) ソフトウェア下位要求テスト(Low-level Testing)
DO-178Cでは、特にこの３つのテストについて区別して詳細の手順を規定しているわけでなく、テスト全体としての手
順を規定している。従って、以降の説明も各テストに共通の規約として説明する。実際には３つのテストを通して全
体として規約を満足するようなテスト計画を立てることになる。
51
MT-0595A
【6.4】
V字モデルを考えた場合、右側の各テスト段階では左側のどの設計プロセスのアウトプットをテストしているのかを
明確にする必要がある。
(1) ハードウェア／ソフトウェア統合テスト
ソフトウェア要求プロセスのアウトプットであるソフトウェア上位要求を満足していることをテストすることになる。
(2) ソフトウェア統合テスト
ソフトウェア設計プロセスのアウトプットであるソフトウェア構造とソフトウェア要求（ここでは、ソフトウェア下位要
求とソフトウェア上位要求の両方を指していると思われる）を満足していることをテストすることになる。
(3) ソフトウェア下位要求テスト
ソフトウェア設計プロセスのアウトプットであるソフトウェア下位要求を満足していることをテストすることになる。
テスト環境については以下のように記述している。
もっとも理想的なテスト環境は、ターゲットコンピュータにソフトウェアがロードされ、ターゲットコンピュータ環境上で
外界がシミュレーションされてテストすることである。また、ターゲットコンピュータのエミュレータやホストコンピュータ
のシミュレータを使用してもよい。
ただし、ターゲットコンピュータ環境でしか検出できないエラーの検出を目的としたテストはその環境で実行されるべ
きである。
ハードウェア／ソフトウェア統合テストはターゲットコンピュータ上でテストしなければならない。
ソフトウェア計画プロセスにて作成するソフトウェア検証計画においては、後述する要求ベーステスト、ソフトウェアカ
バレッジ分析を含めて、テスト環境を含め、どのようにして要求を満足するテストを実行するのかその戦略を記載す
る必要がある。
《6.4》 ソフトウェアテスト(Software Testing)
52
MT-0595A
ソフトウェアテストは、ソフトウェアがその要求を満足していることを立証するために、また、システム安全性評価プ
ロセスで定義された受け入れ難い故障状態に陥るようなエラーが取り除かれており、高い信頼性があることを立
証するために、実施される。
ソフトウェアテストの目的は以下のことを確認するためにソフトウェアを実行することである。
(a) 実行可能オブジェクトコードがソフトウェア上位要求に準拠している。
(b) 実行可能オブジェクトコードがソフトウェア上位要求に対して堅牢性がある。
(c) 実行可能オブジェクトコードがソフトウェア下位要求に準拠している。
(d) 実行可能オブジェクトコードがソフトウェア下位要求に対して堅牢性がある。
(e) 実行可能オブジェクトコードがターゲットコンピュータと整合している。
図6-1は、ソフトウェアテストの目的を達成するためのソフトウェアテスト活動を図示したものである。
この図では、以下の3種類のテストを示している。
(1) ハードウェア／ソフトウェア統合テスト
ターゲットコンピュータ環境で、ソフトウェアが正しく動作することを検証する。
(2) ソフトウェア統合テスト
ソフトウェア要求とコンポーネント間の相互関係を検証するとともに、ソフトウェア構造内にソフトウェア要求と
ソフトウェアコンポーネントが実装されていることを検証する。
(3) ソフトウェア下位要求テスト
ソフトウェア下位要求の実装を検証する。
注意： ハードウェア／ソフトウェア統合テスト、もしくはソフトウェア統合テストにおいて、テストケースとそれに関
連するテスト手順が作られ、実行されており、要求ベースカバレッジと構造カバレッジが満足されている場合は、
ソフトウェア下位要求テストにおいて同じテストをする必要はない。上位レベルテストと等価の下位レベルテストを
名目上代用することは、全体の機能テストの量を削減するという点において非効率である。
《6.4》
《6.4.1》 テスト環境(Test Environment)
テストの目的を満たすため、複数のテスト環境を必要とする場合がある。推奨されるテスト環境には、対象コンピュー
タへロードされるソフトウェアで、対象コンピュータ環境の挙動に非常に似ている環境でテストされるものが含まれる。
注意事項: 多くの場合、要求ベースカバレッジと構造カバレッジは、完全な統合環境で一般的に可能であるより、テス
トへの入力とコード実行のより正確な管理と監視でのみ達成されうる。そのようなテストは、他のコンポーネントから分
離した機能である小さなソフトウェアコンポーネントで行われる必要があっても良い。
認証発行は対象コンピュータのエミュレータやホストコンピュータのシミュレータを使用して行われるテストのため与え
てもよい。テスト環境と関連のある活動には以下の項目がある。
(a) 選択したテストは統合された対象コンピュータ環境で行わなければならない。それは、その環境でのみ検出され
るエラーがあるからである。
《6.4.1》
52
MT-0595A
【6.4】
ソフトウェアテストの目的は以下の２点である。
(1) ソフトウェアがその要求を満足していることを確認する
(2) 受け入れ難い故障状態に陥るようなエラーが取り除かれていることを確認する
また、その目的を達成するために以下を要求している。
(1) テストケースはソフトウェア要求をベースとすること
(2) テストケースは正しい機能の検証、及び潜在エラーを明らかにするケースを抽出すること
(3) ソフトウェア要求カバレッジ分析はテストされていないソフトウェア要求を明らかにすること
(4) 構造カバレッジ分析は実行されていないソフトウェア構造を明らかにすること
このフローでは、テストプロセスの活動を示している。
先に記述したように３種類のテストの結果として、ソフトウェア要求カバレッジ、ソフトウェア構造カバレッジの解析を
求めており、個々のテストにおけるカバレッジを要求するものではない。
53
MT-0595A
【6.4.2】
テストは要求ベーステストに重点を置くこととしている。これは、開発の各段階において上下の関係のトレーサビリテ
ィが取れているため、要求ベーステストであってもコードのカバレッジは確保できるということであろう。
テストケースとしては、ノーマルレンジテストとロバストテスト（異常範囲テスト）の２つのテストの実施すること。
(1) ノーマルレンジテスト(Normal Range Test Cases)
ノーマルレンジテストの目的は、正常な入力、状態に対応するソフトウェアの動作を確認することである。
(a) 実数、整数の入力変数は正当な同値クラス(*1)と境界値を用いて実行されること。
(b) フィルタ、積分、遅れ、コードの複数繰り返しといった時間に係わる機能はその機能の特性がチェックされること
。
(c) 状態遷移では、正常オペレーションにおける可能な遷移を全て実行すること。
(d) 論理式で表現されたソフトウェア要求では、全てのブール演算の組み合わせを検証すること。
(2) ロバストテスト(Robustness Test Cases)
ロバストテストの目的は、異常な入力、状態に対応するソフトウェアの動作を確認することである。
(a) 実数、整数の入力変数は不正な値について同値クラス(*1)を用いて実行されること。
(b) 異常状態でのシステム初期化が実行されること。
(c) 処理可能な故障モードの入力データは明らかにされること。特に外部システムからのデジタルデータ列。
(d) ループカウンタが計算されているようなループにおいて、ループカウンタが範囲外に計算されるようなテストケ
ースが実行されること。これによりループに関わるコードのロバスト性を検証する。
(e) フレーム時間を超えることを防止するメカニズムが正しく動作していることを保証するチェックが実施されること。
(f)
フィルタ、積分、遅れといった時間に関わる機能において、算術演算オーバーフローを防止するメカニズムを確
認するテストケースが実行されること。
(g) 状態遷移において、ソフトウェア要求では許されない遷移を引き起こすようなテストケースが実行されること。
(*1) 同値クラスとは入力変数の値をソフトウェアが同じように扱うグループに分けることあり。テストにおいてはそれ
54
MT-0595A
ぞれの代表的な値を用いることとしている。
《6.4.2》 要求ベーステストの選択(Requirement-Based Test Selection)
この戦略がエラーを明らかにするために最も効果的であるため、要求ベーステストは重要視されている。
要求ベーステストの選択のための活動を以下に示す。
(1) 正常範囲テストケースとロバストテスト（異常範囲テスト）ケースを含んだ特定のテストケースが作られるべき
である。
(2) ソフトウェア要求とソフトウェア開発プロセスの間に備わったエラーの源泉から特定のテストケースが作られ
るべきである。
注意： ロバストテストケースは要求ベースである。もしソフトウェア要求が異常な状態やインプットに対して
正しいソフトウェアの反応を特定していないなら、ロバストテストの基準は十分に満足されるものではない。
そのテストケースは、ソフトウェア要求の不足を明らかにする、そのような場合、ソフトウェア要求は変更され
るべきである。逆に、もし全ての異常状態やインプットを網羅する完全な要求のセットが存在するのであれば
、ロバストテストケースはそれらのソフトウェア要求から導き出される。
(3) テスト手順はテストケースから作られる。
《6.4.2》
《6.4.2.1》 正常範囲テストケース(Normal Range Test Cases)
正常範囲テストケースは、正常な入力と状態に対応するソフトウェアの機能を立証する。
その活動を以下に示す。
(a) 実数、整数の入力変数は正当な同値クラスと境界値を用いて実行されること。
(b) フィルタ、積分、遅れ、コードの複数繰り返しといった時間に係わる機能はその機能の特性がチェックされる
こと。
(c) 状態遷移に対しては、正常オペレーションにおける可能な遷移を全て実行すること。
(d) 論理式で表現されたソフトウェア要求に対しては、全てのブール演算の組み合わせを検証すること。
《6.4.2.1》
《6.4.2.2》 ロバストテストケース(Robustness Test Cases)
ロバストテストは、異常な入力と状態に対応するソフトウェアの機能を立証する。
その活動を以下に示す。
(a) 実数、整数の入力変数は不正な値について同値クラスを用いて実行されること。
(b) 異常状態でのシステム初期化が実行されること。
(c) 処理可能な故障モードの入力データは明らかにされること。特に外部システムからのデジタルデータ列。
(d) ループカウンタが計算されているようなループにおいて、ループカウンタが範囲外に計算されるようなテスト
ケースが実行されること。これによりループに関わるコードのロバスト性を検証する。
(e) フレーム時間を超えることを防止するメカニズムが正しく動作していることを保証するチェックが実施されるこ
と。
(f)
フィルタ、積分、遅れといった時間に関わる機能において、算術演算オーバーフローを防止するメカニズムを
確認するテストケースが実行されること。
(g) 状態遷移において、ソフトウェア要求では許されない遷移を引き起こすようなテストケースが実行されること。
54
MT-0595A
《6.4.2.2》
《6.4.3》 要求ベーステスト手法(Requirement-Based Testing Methods)
本資料で論じる要求ベーステスト手法は、要求ベースのハードウェア/ソフトウェア統合テスト、要求ベースのソフトウェ
ア統合テスト、そして要求ベースの下位要求テストである。ハードウェア/ソフトウェア統合テストを除いて、これらの手
法は明確なテスト環境や手順を定めない。
活動には、以下に示す項目がある。
(a) 要求ベースハードウェア/ソフトウェア統合テスト: このテスト手法は、対象コンピュータ環境におけるソフトウェア
動作に関連するエラーの原因と、上位レベル機能(high-level functionary)に集中しなければならない。要求ベー
スハードウェア/ソフトウェア結合テストは、対象コンピュータ内のソフトウェアがソフトウェア上位要求を満たして
いることを保証する。
本テスト手法によって明らかとなる典型的なエラーを以下に示す。
・不適当な割込みハンドラ
・実行時間要求(execution time requirements)を満たせないこと
・ハードウェアトランジェントやハードウェア障害(例えば、スタートアップシーケンス処理、トランジェント入力不可
、入力電源トランジェントなど)への不適当なソフトウェア応答
・データバスと他のリソースの競合問題、例えば、メモリマッピングなど
・故障検出のためのビルトインテストができないこと
・ハードウェア/ソフトウェアインタフェースのエラー
・コントロールループの不適当な挙動
・メモリ管理ハードウェアやソフトウェア管理下のハードウェアデバイスの不適当な管理
・スタックオーバーフロー
・フィールドロード可能ソフトウェア(field-loadable software)の正当性と整合性を確認するため利用される機構の
不適当な動作
・ソフトウェアパーティショニング違反
(b) 要求ベースソフトウェア統合テスト: このテスト手法は、ソフトウェア要求の相互関係とソフトウェア構造による要
求実現に集中しなければならない。要求ベースソフトウェア統合テストは、ソフトウェアコンポーネントが互いに正
しく作用し、またソフトウェア要求とソフトウェア構造が満足されていることを保証する。この手法は、対応するテ
ストケース範囲の拡大とともにコードコンポーネントの継続的統合を通して要求範囲を拡大することで行われる
場合もある。
本テスト手法によって明らかとなる典型的なエラーを以下に示す。
・ 変数と定数の不適当な初期化
・パラメータ受け渡しエラー
・データ破壊、特にグローバルデータ
・包括的な数値精度の不十分さ
・イベントと動作の不適当なシーケンス処理
(c) 要求ベースソフトウェア下位要求テスト: このテスト手法は、それぞれのソフトウェアコンポーネントがその下位要
求に従うことの確認に集中しなければならない。要求ベース下位要求レベルテストは、ソフトウェアコンポーネン
トがそれらの下位要求を満たしていることを保証する。
本テスト手法によって明らかとなる典型的なエラーを以下に示す。
・ソフトウェア要求を満足させるためのアルゴリズムの失敗・
不適当なループ操作
・不適当な論理決定
・正しい入力条件の組み合わせを正しく処理できないこと
・欠陥データや破損データへの不適当な応答
・演算フォルト(arithmetic faults)や配列範囲違反(violations of array limits)のような不適当な例外処理
・不適当な計算順序(computation sequence)
・不十分な処理手順の精度、正確度、またはパフォーマンス
《6.4.3》
54
MT-0595A
【6.4.4】
テストカバレッジ分析には、以下の２種類がある。
(1) 要求ベーステストカバレッジ分析(Requirements-Based Test Coverage Analysis)
ソフトウェア要求の実装がどのくらい検証されているかを明らかにするものである。この分析は追加の要求ベーステ
ストケースの必要性を明らかにする。
(a) 各ソフトウェア要求に対応するテストケースが存在する。
(b) テストケースがノーマル、ロバストテストの評価基準(4.4(1)(2))を満足していること。
(2) 構造カバレッジ分析(Structural Coverage Analysis)
要求ベーステストにてどのコードが実行されていないかを明らかにするものである。要求ベーステスト実行後、全て
のコードが実行されていない場合、追加の検証が必要となる。
(a) この分析はソフトウェアレベルに対応したカバレッジの度合いを確立する必要がある。本資料の4.7レビュー／
分析(2/2)を参照。
(b) ソフトウェアレベルAでかつ、コンパイラが生成するオブジェクトコードがソースコードに直接トレースしない場合
を除いて、この分析は、ソースコード上で行えばよい。直接トレースしない場合、生成されたコードの正しさを確
認するために、この検証は、オブジェクトコード上で実行されなければならない。コンパイラがオブジェクトコード
内に自動生成する配列の境界チェックはソースコードにトレースしない一つの例である。
(c) この分析はコンポーネント間のデータの結合度、制御の結合度についても実行されなければならない。
《6.4.4》 テストカバレッジ分析(Test Coverage Analysis)
55
MT-0595A
テストカバレッジ分析は、要求ベースカバレッジ分析と構造カバレッジ分析の2つの段階のプロセスがある。
最初の段階では、選ばれたテストケースが特定の基準を満足することを確認するために、ソフトウェア要求に関
連したテストケースを分析する。
2番目の段階では、要求ベーステスト手順が適切なカバレッジ基準に従ってコード構造を実行していることを確認
する。
もし、構造カバレッジ分析において適切なカバレッジに合っていない場合は、デッドコードとしての状況を改善する
ために追加の活動が識別される。(6.4.4.3参照)
テストカバレッジ分析の目的は以下である。
(a) ソフトウェア上位要求のテストカバレッジが達成されている。
(b) ソフトウェア下位要求のテストカバレッジが達成されている。
(c) 適切なカバレッジ基準に基づくソフトウェア構造のテストカバレッジが達成されている。
(d) データ結合と制御結合に関わるソフトウェア構造のテストカバレッジが達成されている。
《6.4.4》
《6.4.4.1》 要求ベーステストカバレッジ分析(Requirements-Based Test Coverage Analysis)
この分析は、どのくらい要求ベーステストがソフトウェア要求の実装を検証したかを決定するものである。
この分析は、追加の要求ベーステストケースの必要性を明らかにする。
この活動を以下に示す。
(a) 関連するトレースデータを用いて、各ソフトウェア要求に対してテストケースが存在することを確認するため
の分析。
(b) テストケースが6.4.2章で決められたノーマルテスト、ロバストテストの基準を満足していることを確認するた
めの分析。
(c) 分析において特定された不足の解決。可能な解決方法はテストケースを追加することと増強することである
。
(d) 構造カバレッジの実施に使用される全てのテストケース、全てのテスト手順が要求にトレース可能であること
を確認するための分析。
《6.4.4.1》
《6.4.4.2》 構造カバレッジ分析(Structural Coverage Analysis)
この分析は、要求ベーステスト手順によってどのコード（コンポーネント間のインターフェースを含み）が実行され
なかったかを決定するものである。
要求ベーステストケースは、コード（インターフェースを含み）を完全に実行しなくてもよい、従って、構造カバレッジ
分析は実行され追加される検証である。
この活動を以下に示す。
(a) 構造カバレッジの度合いがソフトウェアレベルに対応していることを確認するために、要求ベーステストの間
に収集した構造カバレッジ情報の分析。
(b) 構造カバレッジ分析はソースコード、オブジェクトコード、もしくは実行可能オブジェクトコード上で実施してよ
い。ソフトウェアレベルがAで、コンパイラ、リンカー、または他の方法で、ソースコード行に直接トレースされ
ない追加のコードを生成する場合は、生成されたコードのシーケンスの正しさを示すために、追加の検証が
実施されるべきである。
注意： 「ソースコード行に直接トレースされない追加のコード」とは、ソースコードレベルには直接的に表れ
ない分岐や副作用を組み入れるコードである。例えば、コンパイラーが生成した配列チェックの手段は、構造
カバレッジ分析の目的に対してソースコード行に直接トレース可能とはならない、従って追加の検証が検討
されるべきである。
(c) 要求ベーステストがコードコンポーネント間のデータ及び制御の結合度について実行していることを確認す
55
MT-0595A
るための分析。
(d) 構造カバレッジ分析の解決(6.4.4.3章参照)
《6.4.4.2》
《6.4.4.3》 構造カバレッジ分析の解決(Structural Coverage Analysis Resolution)
構造カバレッジ分析は、テストにおいて実行されていないコード（インターフェースを含む）を明らかにする。解決の
ためには追加のソフトウェア検証プロセスの活動が要求される。実行されないコード（インターフェースを含む）の
原因とそれらを解決するための活動を以下に示す。
(a) 要求ベーステストケースと手順の不足
テストケースを増やすべきである、または、テスト手順を実行されないカバレッジを通すように変更する。要求
ベースカバレッジ分析を実行するために使用された手法はレビューの必要性がある。
(b) ソフトウェア要求における不十分
ソフトウェア要求は修正されるべきであり、追加で作られたテストケースとテスト手順が実行されるべきであ
る。
(c) デッドコードを含む無関係なコード
そのコードは取り除かれるべきであり、再検証の考課と必要性を評価するために分析が行われるべきであ
る。もし、無関係なコードがソースコード上、もしくはオブジェクトコードレベルで見つかった場合、分析により
実行可能オブジェクトコードにおいて存在しないことが示された場合においてのみそれを残すことが許される
（例えば、スマートコンパイル、リンク、または他のメカニズムによって）、また、将来のビルド時に含まれるこ
とを防ぐためにその手順を定める。
(d) 実行されないコード
実行されないコードは、以下に定義されたカテゴリに依存して2つの方法のうちの一つによって扱われなけれ
ばならない。
1. カテゴリ1
承認された製品の中で使用される如何なる形態においても意図的に実行されることのないコード。このカテ
ゴリでは、この実行されないコードが不注意に実行されるような手段が防がれている、分離されている、もしく
は排除されていることを、分析とテストの組み合わせにより示さなければならない。
カテゴリ1の実行されないコードによるソフトウェアレベルのいかなる再割り当てもシステム安全性評価プロセ
スにより正当化され、ソフトウェア認証計画(PSAC)に文書化されなければならない、カテゴリ1の実行されな
いコードによるソフトウェア検証プロセスの如何なる軽減もソフトウェア開発プロセスにより正当化され、ソフト
ウェア認証計画(PSAC)に文書化されなければならない。
2. カテゴリ2
ターゲットコンピュータ環境の特定の承認された形態においてのみ実行される実行されないコード。このコー
ドの正常な実行のために必要となる操作の形態は確立されなければならず、追加のテストケースとテスト手
順が要求されたカバレッジ目的を満足させるために作られる。
《6.4.4.3》
55
MT-0595A
【Table A-6】
この表はテストプロセスの実行に関しての規定を定めている。
１項、２項は、ソフトウェア上位要求に対するノーマルレンジテスト、ロバストテストを対象としており、ソフトウェア統合
テストが対象となる。
３項、４項は、ソフトウェア下位要求に対するノーマルレンジテスト、ロバストテストを対象としており、ソフトウェア下位
要求テストが対象となる。
ソフトウェア下位要求テストの一部は独立した第３者の実施を求めている。また、ソフトウェアレベルがDの場合は、
その実施を要求していない。
５項は、ハードウェア／ソフトウェア統合テストが対象であり、ターゲットコンピュータ上での実施を求めている。
56
MT-0595A
【Table A-7】
この表はテストプロセスにおけるレビュー／分析に関しての規定を定めており、コードのテストが正確に、完全に実
行されていることを保証するものである。
１項は、テストケースが正確にテスト手順と期待値に反映されていることを求めている。
２項は、テスト結果が正しく、期待値と実行値に差があった場合はその説明がされていることを求めている。
３項、４項は要求カバレッジの達成を要求するものである。
ソフトウェアレベルDは、前の表でソフトウェア下位要求テストを要求していないので、ここでも適用外となっている。
ソフトウェアレベルAに関しては、このレビュー／分析は全て独立した第３者が実施することを求めている。
《6.4.5》 テストケース、手順、結果のレビュー/分析(Reviews and Analyses of Test Cases, Procedures, and Results)
これらのレビュー/分析の活動は、テストが以下の目的(objectives)を満足させることを確認する。
(a) テストケース: テストケースの検証に関する目的(objectives)は、セクション6.4.4.aと6.4.4.bに示されている。
(b) テスト手順: 目的は、期待される結果を含むテストケースが、テスト手順に正しく落とし込まれたことを検証する
ことである。
(c) テスト結果: 目的は、テスト結果が正しいことと、実際の結果と期待された結果の不一致が説明されることを保
証することである。
《6.4.5》
57
MT-0595A
【Table A-7】
この表では、構造カバレッジ分析について定めている。
ソフトウェアレベルDでは、構造カバレッジ分析は求められていない。すなわちソフトウェア上位要求の要求カバレッ
ジのみが求められている。
７項はいわゆるC０カバレッジのことであり、ソフトウェアレベルC以上で要求されている。
８項はいわゆるC1カバレッジのことであり、ソフトウェアレベルB以上で要求されている。
ソフトウェアレベルAでは、それに加えてMCDCのカバレッジを要求されている。
ちなみに、全体としてソフトウェアAとBとの適用項目の違いはこの5項と9項のみである。
58
MT-0595A
【6.5】
《6.5》 ソフトウェア検証プロセストレーサビリティ(Software Verification Process Traceability)
ソフトウェア検証プロセスにおけるトレーサビリティ活動には以下が含まれる。
(a) ソフトウェア要求とテストケース間の双方向の関連性を示すトレースデータが作られている。
このトレースデータは、要求ベーステストカバレッジ分析を支援する。
(b) テストケースとテスト手順間の双方向の関連性を示すトレースデータが作られている。
このトレースデータは、テストケースの完全なセットがテスト手順の中に作られていることの検証を可能とす
る。
(c) テスト手順とテスト結果間の双方向の関連性を示すトレースデータが作られている。
このトレースデータは、テスト手順の完全なセットが実行されていることの検証を可能とする。
《6.5》
59
MT-0595A
【6.6】
TableA-7には明示的に示されていないが、パラメータデータ項目の検証のObjectivesとして2項目が追加された。
《6.6》 パラメータデータ項目の検証(Verification of Parameter Data Item)
パタメータデータ項目の検証は、以下の条件が揃った場合には、実行可能オブジェクトコードの検証とは別に行われ
る。
・ 実行可能オブジェクトコードが作成され、定義した構造と属性に従うすべてのパラメータデータ項目ファイルを正し
く処理するためノーマルレンジテストによって検証される。
・ 実行可能オブジェクトコードは、パラメータデータ項目ファイルの構造と属性に関してロバストである。
・ パラメータデータ項目ファイルの内容(contents)から生じる実行可能オブジェクトコードの動作が検証可能である。
・ ライフサイクルデータの構造が、パラメータデータ項目が別々に管理されるのを許す。
もし上記すべての条件が満たされていないならば、パラメータデータ項目はソフトウェアの残りとは別に検証しては
いけない。このケースでは、実行可能ブジェクトコードとパラメータデータ項目ファイルは一緒に検証しなければなら
ない。
実行可能オブジェクトコードの検証とは別に検証可能なパラメータデータ項目では、下記の目的が適用される。下記
の目的はテスト、分析/レビューの組み合わせによって達成されるだろう。
(a) パラメータデータ項目ファイルは,ソフトウェア上位要求によって定義された構造に準拠していることを検証され
なければならない。この検証には、パラメータデータ項目ファイルが上位要求によって定義されないどんな要素
も含まないことを確かめることが含まれる。パラメータデータ項目内の各データ要素は、正しい値を持ち、他の
データ要素と矛盾せず、上位要求によって定義された属性に準拠していることを示されなければならない。
60
MT-0595A
注意事項: あるデータ要素にとっては、それらの属性は検証される必要がある唯一の側面であるかもしれない。
その他の場合では、データ要素の値が検証される必要があるかもしれない。
(b) 検証中、パラメータデータ項目ファイルの全要素は網羅された。
もしパラメータデータ項目の構造と属性に変更があるならば、実行可能オブジェクトコードの改修と再検証の必要性
は分析されなければならない。
《6.6》
60
MT-0595A
【6】
61
MT-0595A
【6】
ソフトウェア検証プロセスはレビュー／分析(Reviews and Analyses)とテスト(Testing)から構成される。
前述したように、これらのプロセスはソフトウェア開発プロセスと並行して実施される。
既に先に説明したのでその参照先を以下に記述する。
1. レビュー／分析(Reviews and Analyses)
(1) ソフトウェア上位要求(Reviews and Analyses of the High-Level Requirements)
3.2.2 レビュー／分析（上位要求）参照。
(2) ソフトウェア下位要求(Reviews and Analyses of the Low-Level Requirements)
3.2.2 レビュー／分析（下位要求）参照。
(3) ソフトウェア構造(Reviews and Analyses of the Software Architectures)
3.2.2 レビュー／分析（ソフトウェア構造）参照。
(4) ソースコード(Reviews and Analyses of the Source Code)
3.4.2 レビュー／分析（ソースコード）参照。
(5) 統合プロセスの結果(Reviews and Analyses of the Outputs of the Integration Process)
3.5.2 レビュー／分析（統合プロセスの結果）参照。
(6) テストケース、手順、結果(Reviews and Analyses of the Test Cases, Procedures and Results)
4.7 レビュー／分析（テスト）参照。
2. テスト(Testing)
4.テストプロセス参照。
《6.0》 ソフトウェア検証プロセス(Software Verification Process)
62
MT-0595A
このセクションではソフトウェア検証プロセスの目的と活動について論じる。検証はソフト
ウェア計画プロセス、ソフトウェア開発プロセス、ソフトウェア検証プロセスの成果物の技
術的評価(technical assessment)である。ソフトウェア検証プロセスはソフトウェア計画プ
ロセス(4を参照)とソフトウェア検証計画(11.3を参照) によって定義されるように適用され
る。ソフトウェア計画プロセスの成果物の検証についてはセクション4.6を参照すること。
検証は単純なテストではない。一般的に、テストはエラーがないことを示すことができな
い。その故、以降のセクションでは、ソフトウェア検証プロセスの活動を議論するため、「
テスト」の代わりに「検証」とう用語を用いる。典型的に、ソフトウェア検証プロセスの活
動はレビュー/分析、テストの組み合わせである。
添付Aの表A‐3から表A‐7には、ソフトウェアレベルごとのソフトウェア検証プロセスの目
的と成果物の要約を示してある。
注意事項: より下位のソフトウェアレベルでは、下記項目の重要度は低くなる。
・ソースコードの検証
・下位要求の検証
・ソフトウェア構造の検証
・テスト網羅度の検証
・検証手順の管理
・ソフトウェア検証プロセスの活動の独立性
・ソフトウェア検証プロセスの活動の重複、つまり、多数の検証活動で、それぞれが同一
エラークラスを検出可能なもの
・ロバストテスト
・エラー防止や検出に間接的な効果を持つ検証活動、例えば、ソフトウェア開発標準へ
の準拠
《6.0》
《6.1》 ソフトウェア検証の目的(Purpose of Software Verification)
ソフトウェア検証プロセスの目的は、ソフトウェア開発プロセスで入り込んだエラーを検
出し、報告することである。また、そのエラーの除去はソフトウェア開発プロセスの活動
である。ソフトウェア検証プロセスでは以下の項目を検証する。
(a) ソフトウェアに割り当てられたシステム要求が、システム要求を満足させるソフトウェ
ア上位要求に落とし込まれている。
(b) ソフトウェア上位要求が、それを満足させるソフトウェア構造およびソフトウェア下位
62
MT-0595A
要求に落とし込まれている。もし1つまたは複数のソフトウェア要求レベルが上位要
求と下位要求の間にある場合、継承する要求レベルは、それぞれの下位要求がそ
の上位要求を満たすように連続的に落とし込まれている。もしコードがソフトウェア
上位要求から直接生成される場合、これは適用されない。
(c) ソフトウェア構造とソフトウェア下位要求が、ソフトウェア下位要求とソフトウェア構造
を満足するソースコードに落とし込まれている。
(d) 実行可能オブジェクトコードがソフトウェア要求（つまり、意図した機能）を満足させ、
意図しない機能がない信用を与える。
(e) 実行可能オブジェクトコードが、それが異常な入力・条件に正しく応答できるというソ
フトウェア要求に関して、ロバストである。
(f) この検証の実行手段が、ソフトウェアレベルに対し技術的に正しく完全である。
《6.1》
《6.2》 ソフトウェア検証プロセス活動の概要(Overview of Software Verification Process Activites)
ソフトウェア検証プロセスの目的は、レビュー/分析、テストケースと手順の作成、そして
後のテスト手順の実行により満たされる。レビュー/分析では、ソフトウェア要求、ソフトウ
ェア構造、ソースコードの正確性、完全性、検証可能性を評価する。テストケースと手順
の作成では、要求の内部一貫性と完全性のさらなるを評価を行ってもよい。テスト手順
の実行では、要求に従っていることを確認する。
ソフトウェア検証プロセスへの入力には、システム要求、ソフトウェア要求、ソフトウェア
構造、トレースデータ、ソースコード、実行可能オブジェクトコード、そしてソフトウェア検
証計画がある。
ソフトウェア検証プロセスの成果物は、ソフトウェア検証ケースと手順(11.13を参照)、ソ
フトウェア検証結果(11.14を参照)、そして関連するトレースデータ(11.21を参照)に記載さ
れている。
一度ソフトウェアに実現され検証可能となった要求の必要性は、自らソフトウェア開発プ
ロセスに追加の要求と制約を与えてもよい。
ソフトウェア検証の考慮事項を以下に示す。
(a) もしテストされたコードが航空機搭載ソフトウェアと同一でないなら、差異は明確にさ
れ正当な理由付けがなされなければならない。
(b) 実テスト環境でソフトウェアを動作させることで特有のソフトウェア要求を検証できな
い時、他の手段が利用できねばならず、そして検証計画やソフトウェア検証結果で
定義されたソフトウェア開発プロセスの目的を満たすためその手段を正当化しなけ
ればならない。
62
MT-0595A
(c) ソフトウェア検証プロセスで発見された欠陥やエラーは、適切な解明と修正のため
他のソフトウェアライフサイクルプロセスに報告されなければならない。
(d) 再検証は、既に検証した機能に強く影響する是正処置および(または)変更の後で行
われなければならない。再検証は改修が正しく行われたことを保証する。
(e) 検証項目の開発者とは別の者によって検証活動が行われる時、検証独立性は達成
される。ツールは人間による確認活動との等価性を達成するため使用してもよい。
独立性のため、下位要求ベーステストケース(low‐level requirements‐based test cases)を作成した者は、それらの下位要求から、関連したソースコードを作成した者
と同一であってはならない。
《6.2》
62
MT-0595A
【11.13】
(1)レビューと分析手順は、レビュー／分析に先立ってその詳細計画を作成するものである。
(2)テストケース(3)テスト手順は、テストプロセスの手順を作成するものである。
《11.13》 ソフトウェア検証ケース・手順(Software Verification Cases and Procedures)
ソフトウェア検証ケース・手順は、ソフトウェア検証プロセス活動がどのように実施されるかを詳しく述べるものである
。
ここでは、以下が記載されなければならない。
(a) レビューと分析手順(Review and analysis procedures)
ソフトウェア検証計画(Software Verification Plan)の記述に追加して、使用されるレビューまたは検証の方法の
範囲と深さ。
(b) テストケース(Test cases)
要求されるカバレッジ評価基準を達成するための、各テストケースの目的、入力データのセット、状態、期待さ
れる結果、良否判定基準。
(c) テスト手順(Test Proceed)
各テストケースがどの様に設定され実行されるか、テスト結果がどのように評価されるかのひとつひとつの手
順と使用されるテスト環境。
《11.13》
63
MT-0595A
【11.14】
これは、前述のソフトウェア検証ケース・手順を受けて、実際に「レビュー／分析」「テスト」を実施した結果について
まとめるものである。
《11.14》 ソフトウェア検証結果(Software Verification Results)
ソフトウェア検証結果はソフトウェア検証プロセス活動によって作られる。
ここでは、以下が記載されなければならない。
(a) 各レビュー、分析、テストにおける、活動の間の良否の過程と、最終的な良否の結果を示す。
(b) レビュー、分析、テストがなされた形態項目、またはソフトウェアバージョンを特定する。
(c) カバレッジ分析、トレーサビリティ分析を含んだテスト、レビュー、分析の結果を含む。
発見されたどのような不一致も不適合報告によって記録され、追跡されるべきである。
加えて、ソフトウェアプロセスによって提供された情報に対する、システムプロセスの評価の支援に対して提供され
た根拠資料は、ソフトウェア検証結果内に考慮されるべきである(2.2.1.f、2.2.1.gを参照)。
《11.14》
64
MT-0595A
【11.21】
《11.21》 トレースデータ(Trace Data)
トレースデータは、ライフサイクルデータ項目の内容の間の関連性を確立するものである。
トレースデータは、以下の双方向の関連性の立証を提供する。
(a) ソフトウェアに割り当てられたシステム要求とソフトウェア上位要求
(b) ソフトウェア上位要求とソフトウェア下位要求
(c) ソフトウェア下位要求とソースコード
(d) ソフトエア要求とテストケース
(e) テストケースとテスト手順
(f)
テスト手順とテスト結果
《11.21》
65
MT-0595A
【7】
《7.0》 ソフトウェア形態管理プロセス(Software Configuration Management Process)
このセクションでは、ソフトウェア形態管理プロセス(SCM)の目的と活動について論じる。SCMプロセスはソフトウェア
計画プロセス(4を参照)とソフトウェア形態管理計画(11.4を参照)によって定義されるように適用される。SCMプロセ
スの成果物はソフトウェア形態管理記録(11.18を参照)や他のソフトウェアライフサイクルデータに記録される。
SCMプロセスは、他のソフトウェアライフサイクルプロセスと協調して実施され下記項目を支援する。
(a) ソフトウェアライクサイクルを通し、定義され管理されたソフトウェアの形態(configuration)を提供すること
(b) もしあるなら、ソフトウェア製造のため実行可能オブジェクトコードとパラメータデータ項目ファイルを一貫して複
製する能力を提供する。または調査や改修の必要がある場合に、それを再構成する能力を供給すること
(c) プロセス活動の一貫性と再現性を確認するソフトウェアライフサイクルの間、プロセスの入力と出力の管理を提
供すること
(d) 形態項目とベースライン確立の管理によって、レビュー、評価のステータス、変更管理、の既知事項(known
point)を提供すること
(e) 問題が処置され、変更が記録・承認・実現されたことを確認する管理を提供すること
(f)
ソフトウェアライフサイクルプロセスの成果物管理によって、ソフトウェアの承認の根拠を提供すること
(g) ソフトウェア製品の要求の準拠を評価すること
(h) セキュアな物理的な保管、リカバリ、管理が形態項目のため維持されることを確認すること
《7.0》
66
MT-0595A
【7.2】
１． 形態識別(Configuration Identification)
形態識別の目的は、各形態項目（とそのバージョン）を明白にラベル付けし、特定できるようにするものである。
形態識別は、ソフトウェアライフサイクルデータに付与される。ソフトウェアライフサイクルデータには、ソフトウェ
ア製品そのものだけでなく各プロセスで作成された文書も含まれているため、当然のことながら、これらの文書
も形態管理の対象となる。
ソフトウェア製品に対して形態識別を付ける際は、ソフトウェア製品を構成するコンポーネントにまでブレークダ
ウンして付けることを定めている。原文では、”each separately controlled component”という表現がされている。
以降に出てくる変更管理やトレーサビリティにおいて対象を識別するためにも形態識別は用いられる。
２． ベースラインとトレーサビリティ(Baselines and Traceability)
ベースラインは、それ以降のソフトウェアライスサイクルプロセスにおいて使用する基本を決めるものである、と
書かれており、文書であればA改訂、B改訂、ソフトウェア製品であればバージョンのことと解釈できる。
トレース可能という意味には２種類あり、変更等によりベースラインが変わるときには以前のベースラインとの
間でトレース可能でなければならない、ということと、形態項目のベースラインがどの形態項目のベースライン
をインプットとして作られたものなのかがトレース可能でなければならない。
３． 不適合の報告、追跡、修正(Problem Reporting, Tracking and Corrective Action)
ここで言う不適合には3種類ある。①ソフトウェアライフサイクルプロセスにおいて、ソフトウェア計画、標準に準
拠していない、②ソフトウェアライフサイクルプロセスのアウトプットに欠陥がある、③ソフトウェア製品の異常な
ふるまいの3種類である。この不適合の報告、追跡、修正では、これらの不適合が記録され、解決されることを
保証することを求めている。
《7.2》 ソフトウェア形態管理プロセスの活動(Software Configuration Management Process Activities)
SCMプロセスには、関連するソフトウェアライフサイクルデータを含めたソフトウェア製品の形態識別、変更管理、ベ
67
MT-0595A
ースライン確立、そして保管の活動がある。SCMプロセスは、ソフトウェア製品が認証機関に承認される時に終わる
のではなく、システム又は装置の使用可能寿命(service life)の間ずっと続く。もしソフトウェアライフサイクル活動がサ
プライヤによって行われるなら、形態管理活動はサプライヤに適用されなければならない。
《7.2》
《7.2.1》 形態識別(Configuration Identification)
活動を以下に示す。
(a) 形態識別はソフトウェアライフサイクルデータに対して確立されなければならない。
(b) 形態識別は各形態項目に対して、別れて管理される形態項目のコンポーネントに対して、ソフトウェト製品を構
成する形態管理の組み合わせに対して確立されなければならない。
(c) 形態項目は、変更管理とトレーサビリティ解析の実行の前に識別された形態でなければならない。
(d) 形態項目は、他のソフトウェアライフサイクルプロセスによってその項目が使用される前に、他のソフトウェアファ
イルサイクルデータに参照(referenced)される前に、またソフトウェア製造やソフトウェアロードに使用される前に、
識別された形態でなければならない。
(e) もしソフトウェア製品の識別が物理検査(例えば、部品番号プレート検査)によって決定できないなら、実行可能オ
ブジェクトコードとパラメータデータ項目ファイル(もしあるならば)が、システム又は装置の他の部品によってアク
セス可能である形態識別を含まなければならない。これはフィールドローダブルなソフトウェアにも適用しても良
い。
《7.2.1》
《7.2.2》 ベースラインとトレーサビリティ(Baselines and Traceability)
活動を以下に示す。
(a) ベースラインは認証発行(certification credit)のため使用される形態項目のため確立されなければならない。中
間ベースラインはソフトウェアライフサイクルプロセス活動の管理支援のために確立されても良い。
(b) ソフトウェア製品ベースラインはソフトウェア製品のために確立され、ソフトウェア形態索引で定義されなければ
ならない11.16を参照)。
注意事項: ユーザー変更可能なソフトウェアは、それに関連する保護と境界コンポーネントを除き、ソフトウェア
製品ベースラインに含まれない。それ故、ソフトウェア製品ベースラインの形態識別に影響を与えないでユーザ
ー変更可能なソフトウェアに対して改修が行われても良い。
(c) ベースラインは、物理的、電気的、それ以外であっても、その完全さを保証するため管理されたソフトウェアライ
ブラリ内で確立されなければならない。
(d) 変更管理活動は、確立したベースラインから派生したベースラインを開発するためフォローされなければならな
い。
(e) もしソフトウェアライフサイクル活動や以前のベースラインの開発に関連するデータのため認証発行(certification
credit)が求められるなら、ベースラインは、それが派生したベースラインへ追跡可能でなければならない。
(f)
もしソフトウェアライフサイクル活動や以前の形態項目に関連するデータのため認証発行(certification credit)が
求められるなら、形態項目は、それが派生した形態項目へ追跡可能でなければならない。
(g) ベールラインや形態項目は、それが識別する成果物へ、またそれが関連するプロセスへ、追跡可能でなければ
ならない。
《7.2.2》
《7.2.3》不適合の報告、追跡、修正(Problem Reporting, Tracking and Corrective Action)
活動には以下ものがある。
(a) 不適合報告は、セクション11.17で定義されるように、計画に従わないプロセス、成果物の不足、ソフトウェアの異
常な動作と実施した修正を記述するものとして用意されなければならない。
67
MT-0595A
注意事項: ソフトウェアライフサイクルプロセスとソフトウェア製品の不適合は異なる不適合報告システム内で記
録されても良い。
(b) 不適合報告は影響を受けた形態項目の形態識別又は、影響を受けたプロセス活動の定義、不適合報告のステ
ータス報告(status reporting)、そして不適合報告の承認とクローズ方法(closure)を提供しなければならない。
(c) ソフトウェア製品やソフトウェアライフサイクルプロセスの修正を要求する不適合報告は、変更管理活動を実施し
なければならない。
《7.2.3》
67
MT-0595A
【7.2】
4. 変更管理(Change Control)
変更管理の目的は、ソフトウェアライフサイクルを通して変更の記録、評価、解決、承認を行うものである。一旦
、ベースライン化されたものは変更管理のプロセスを経由してのみ変更が許可される。前述の不適合報告と後
述の変更レビューは変更管理と密接に関連しており、不適合報告がトリガーとなり変更管理が実行される。変
更レビューは変更管理を支援するものである。
5. 変更レビュー(Change Review)
不適合管理に伴う変更、及び変更管理の結果を確認、評価するプロセスと位置づけられる。
6. 形態ステータス報告(Configuration Status Accounting)
報告先が不明だが、ソフトウェア形態管理プロセスの成果物であるソフトウェア形態管理記録(Software
Configuration Management Records)に残すことを意味しているのかもしれない。
《7.2.4》 変更管理(Change Control)
活動には以下のものがある。
(a) 変更管理は、変更に対する保護を提供することによって、形態項目とベースラインの完全性を保存する。
(b) 変更管理は、形態項目のいかなる変更もその形態識別への変更を要求することを保証しなければならない。
(c) 派生ベースラインを生成するための変更管理下での、ベースラインと形態項目への変更は記録、承認、追跡さ
れなければならない。不適合報告が変更管理と関係があるのは、報告された不適合の解決が形態項目又はベ
ースラインへの変更という結果となるからである。
注意事項: 早めの変更管理の実現がソフトウェアライフサイクルプロセス活動の管理とマネジメント
68
MT-0595A
(management)を支援するということは、一般的に認識されている。
(d) ソフトウェア変更は、それらの源泉と、その変更がそれらの成果物(outputs)へ影響を与える箇所から再度実施す
るソフトウェアライフライクルプロセスまでトレースされなければならない。例えば、ハードウェア/ソフトウェア統合
で発見されたエラー(すなわち、不適当な設計に起因するもの)は、設計修正、コード修正、そして関連したインテ
グラルプロセス活動の繰り返しとならなければならない。
(e) 変更活動の間ずっと、変更によって影響を受けたソフトウェアライフサイクルデータは更新され、記録(records)は
変更管理活動のため維持されなければならない。
変更管理活動は変更レビュー活動によって支援される。
《7.2.4》
《7.2.5》 変更レビュー(Change Review)
活動には以下のものがある。
(a) 不適合又はシステム要求における提案された変更のインパクトの評価。フィードバックはシステムプロセス(含む
システム安全評価プロセス)へ提供されなければならず、システムプロセスからのどんな応答も評価されなけれ
ばならない。
(b) 行われる変更と取られる行動を識別しているソフトウェアライフサイクルデータにおける不適合又は提案された
変更のインパクトの評価
(c) 影響する形態項目が特定された形態(configuration identified)であるという確認
(d) 不適合報告又は変更のインパクトのフィードバック、および影響を受けるプロセスの決定
《7.2.5》
《7.2.6》 形態ステータス報告(Configuration Status Accounting)
活動には以下のものがある。
(a) 形態項目識別、ベースライン識別、不適合報告ステータス、変更履歴、リリースステータスについて報告すること
(b) 維持されるデータの定義と、そのデータのステータスの記録・報告の手段
《7.2.6》
68
MT-0595A
【7.2】
7. 保管、取得、リリース(Archive, Retrieval and Release)
ソフトウェアライフサイクルデータをどのように保管すべきかについて記載されている。
ベースラインを含めた形態項目が正しく識別され、間違いなくデータが複製される手段を提供しなければならな
い。また、ストレージメディアに関しても安全性を要求している。
《7.2.7》
活動には以下のものがある。
(a) ソフトウェア製品に関連したソフトウェアライフサイクルデータは、承認されたソース(例えば、開発組織や会社で
の保管(archive))から取得可能でなければならない。
(b) 手順は、蓄積されたデータの完全性を保証するため、ストレージの媒体にかかわらず、以下の事項によって確
立されなければならない。
1. 無許可の変更がなされないことの保証
2. 最構成時のエラーや劣化を最小限にするストレージメディアの選択
3. 時間経過でのデータの損失・破損を防ぐこと。これには使用したストレージメディアに応じて、定期的にメディ
アを作動させ保管データ(archived date)をリフレッシュすることが含まれる。
4. 災害の発生での損失リスクを最小化する物理的に分かれたアーカイブ(archives)で、複製を保管すること
(c) 重複プロセスは正確なコピーを生産するため検証されなければならない。また、実行可能オブジェクトコードと
パラメータデータ項目(もしあれば)のエラーの無いコピーを保証する手順が存在しなければならない。
(d) 形態項目はソフトウェアの製造に使用されるまえに識別され、リリースされなければならず、また、そのリリース
のための許可が確立されなければならない。最低でも、航空機搭載システム又は装置にロードされるソフトウェ
ア製品のコンポーネントはリリースされなければならない。これには、実行可能オブジェクトコードとパラメータデ
ータ項目ファイル(もしあれば)が含まれ、ソフトウェアロード(software loading)のための関連メディアも含まれて
も良い。
69
MT-0595A
注意事項： リリースは一般的に、航空機搭載システム又は装置へのロードのための承認されたソフトウェアを定
義するデータも要求される。そのデータの定義は本ドキュメントの範囲外であるが、それにはソフトウェア形態索
引を含んでも良い。
(e) データ保持手順は耐空性(airworthiness)要求を満足させ、ソフトウェア改修を可能とされなければならない
注意事項： データ保存の追加の考慮事項には、業務上の要望と将来の認証機関レビューのような項目が含ま
れても良いが、それは本ドキュメントの範囲外である。
《7.2.7》
69
MT-0595A
【Table A-8】
ソフトウェア形態管理プロセスは、他のソフトウェアライフサイクルプロセスと並行して実施され、以下の目的を実現
する。
(1) ソフトウェアライフサイクル全体を通して、ソフトウェアの形態を定義する。
(2) 調査、改修が必要となった際に、実行可能オブジェクトコードの複製、再構築が可能な能力を提供する。
(3) ソフトウェアライフサイクルの各プロセスのインプットとアウトプットを管理する。これによりプロセスの一貫性を
保証する。
(4) 形態項目とベースラインの設定により、レビュー、評価、変更管理のベースとなるポイントを提供する。
(5) 不適合や変更が記録され、承認され、修正されていることを保証できる仕掛けを提供する。
(6) ソフトウェアライフサイクルのアウトプットを管理することにより、ソフトウェアの承認のエビデンスを提供する。
(7) ソフトウェア製品が要求に準拠していることの評価を支援する。
(8) 形態項目が安全に物理的に保管され、リカバリ、管理が維持されていることを保証する。
《7.1》 ソフトウェア形態管理プロセスの目的(Software Configuration Management Process Objectives)
SCMプロセスの目的を以下に示す。
(a) 形態項目の管理と参照のベースを確立するため、各形態項目とそのバージョンが明確に分類される
(b) さらなるソフトウェアライフサイクル活動のためにベースラインが定義される。そのベースラインは、形態項目へ
の参照、形態項目の管理、そして形態項目間のトレーサビリティを許す。
(c) 不適合報告プロセスでは、ソフトウェア計画と標準に従わないプロセスを記録し、ソフトウェアライフサイクルプ
ロセスの成果物の不足を記録し、ソフトウェア製品の異常な動作を記録し、そしてこれらの問題の解決を確認
する
(d) 変更管理は、ソフトウェアライフサイクルの間ずっと、変更の記録、評価、解決、そして承認を提供する
(e) 変更レビューは、ソフトウェア計画プロセスで定義された不適合報告と変更管理手法を通して、不適合と変更が
70
MT-0595A
評価され承認/不承認されること、承認された変更が実現されること、フィードバックが影響するプロセスに提供さ
れることを保証する。
(f)
形態ステータス報告は、形態識別、ベースライン、不適合報告、変更管理に関してソフトウェアライフサイクルプ
ロセスの形態管理のためデータを提供する。
(g) 保管と取得は、ソフトウェア製品に関連したソフトウェアライフサイクルデータが、ソフトウェア製品を複製、再生
成、再テスト、または改修する必要がある場合に取得可能であることを確認する。リリース活動の目的は、保管・
取得されていることに加え、特にソフトウェア製造のため、オーソライズされたソフトウェアのみ使用されことを確
認する。
(h) ソフトウェアロード管理は実行可能オブジェクトコードとパラメータデータ項目ファイルが、もしあるなら、適切なセ
ーフガードを持つシステムや装置へロードされることを確認する。
(i)
ソフトウェアライフサイクル環境管理は、ソフトウェアを生産するために使われるツールが、識別され、管理され、
取得可能であることを保証する。
SCMの目的はソフトウェアレベルから独立している。しかしながら、ソフトウェアライフサイクルデータの2つのカテゴリ
(two categories)は、データへ適用されるSCM管理に基づいて存在する。
添付Aの表A-8はSCMプロセスの目的と成果物の要約である。
《7.1》
70
MT-0595A
【7.3】
DO-178Cではソフトウェア・ライフサイクル・データの形態管理の方法を厳密に定義している。
この表は前述したソフトウェア形態管理プロセスで定義された13の形態管理項目を示している。
CC1は「Control Category 1」、CC2は「Control Category 2」の略である。
本資料では、「Control Category」を「形態管理カテゴリ」と訳している。
DO-178Cでは、ソフトウェアレベル(A～E)に応じてソフトウェア・ライフサイクル・データの形態管理のレベル(CC1、
CC2)を定めている。
CC1が指定されると１３項目の全ての形態管理項目を実施する必要がある。CC2が指定された場合は、表で○のつ
いた項目だけを最低限実施すればよい。
《7.3》 データ管理カテゴリ(Data Control Categories)
ソフトウェアライフサイクルデータは、2つの形態管理カテゴリ(形態管理カテゴリ1(CC1)と形態管理カテゴリ2(CC2))
のひとつに割り当てられる。表7-1では各形態管理カテゴリに関連するSCMプロセス活動を定義しており、○記号は
そのカテゴリのソフトウェアライフサイクルデータの最小限の活動を示している。CC2活動はCC1活動のサブセットで
ある。
添付Aのテーブルは、ソフトウェアライフサイクルデータ項目のソフトウェアレベルによって、形態管理カテゴリを明示
(specify)する。
《7.3》
71
MT-0595A
【7.4】
6.4 ソフトウェアロード管理(Software Load Control)
どの航空機にどの形態識別されたソフトウェア製品がロードされているのかを厳密に管理することが求められ
ている。
《7.4》 ソフトウェアロード管理(Software Load Control)
ソフトウェアロード管理は、プログラムされた命令データがマスタメモリデバイスからシステム又は装置へ転送される
プロセスを参照する。例えば手法には、工場でプリプログラムされたメモリデバイスや、フィールドローディングデバイ
スを利用するシステム又は装置の現場の書き換によるインストールがある(ただし、認証機関からの承認を条件とす
る)。どちらの手法を使っても、ソフトウェアロード管理には以下の項目が含まれる。
(a) 航空機搭載システム又は装置へのロードのための承認される予定であるソフトウェア形態を識別する、部品番
号とメディア識別の手続き
(b) ソフトウェアが最終品目として提供されようと、航空機搭載システム又は装置にインストールされ提供されようと
、航空機搭載システム又は装置のハードウェアとソフトウェア互換性(software compatibility)を確認する記録が
保たれなければならない。
《7.4》
72
MT-0595A
【7.5】
6.5 ソフトウェアライフサイクル環境管理
ここでは、ソフトウェアを作成するために使用されたツールの形態管理について規定している。
ソフトウェアライフサイクルデータを形態管理することはもちろんであるが、ソフトウェアライフサイクルプロセスで
使用された環境（ツール）に関しても形態管理される必要がある。ソフトウェアライスサイクルデータは再構築可
能でなければならず、そのためにはその時に使用した環境が特定でき、環境自体も再構築可能でなければな
らないからである。
《7.5》 ソフトウェアライフサイクル環境管理(Software Life Cycle Environment Control)
ソフトウェアライフサイクル環境ツールはソフトウェア計画プロセスで定義され、ソフトウェアライフサイクル環境形態
索引(11.15を参照)で明らかにされている。活動には以下ものがある。
(a) 形態識別は、ソフトウェアを開発、管理、ビルド、検証、ロードするために使うやツールの実行可能オブジェクト
コード(又はそれと等価なもの)のため確立されなければならない。
(b) 認定されたツールを管理するためのSCMプロセスは、セクション12.2.3で提供されたガイダンスに従い、形態管
理カテゴリ1や形態管理カテゴリ2のデータ(7.3を参照)に関連する目的に準拠しなければならない。
(c) もしセクション7.5bが適用されなかったら、ソフトウェアをビルド、ロードするために利用するツール(例えば、コン
パイラ、アセンブラ、リンカなど)の実行可能オブジェクトコード(又はそれと等価なもの)を管理しているSCMプロ
セスは、最低限、形態管理カテゴリ2に関連する目的に準拠しなければならない。
《7.5》
73
MT-0595A
【11.15】
1.ソフトウェアライフサイクル環境形態索引(Software Life Cycle Environment Configuration Index)
(2)の例として、コンパイラ、リンカー、ローダ、データ完全性ツール(チェックサム、冗長チェック)を挙げている。
(3)には、テストのみでなく検証プロセスで使用されたツール全般を含んでいる。
《11.15》 ソフトウェアライフサイクル環境形態索引
ソフトウェアライフサイクル環境形態索引(SECI)は、ソフトウェアライフサイクル環境の形態を識別する。
ソフトウェアの再構築、再検証、もしくはソフトウェアの修正のために、ハードウェア及びソフトウェアライフサイクル環
境を再構築することを目的としてこの索引は書かれる。
これには以下が書かれるべきである。
(a) ソフトウェアライフサイクル環境のハードウェアとそのOSを特定する。
(b) ソフトウェアの開発期間に使用されるツールを特定する。例えば、コンパイラ、リンケージエディタ、ローダ、デー
タ完全性ツール（例えばチェックサムやCRCを計算し埋め込むツール）、自動コード生成など。
(c) ソフトウェア製品を検証するために使用するテスト環境（例えばテストツール、分析ツールなど）を特定する。
(d) 資格化されたツールとそれらに関連するツール資格化データを特定する。
注意：このデータはソフトウェア形態索引に含まれてもよい。
《11.15》
74
MT-0595A
【11.16】
2.ソフトウェア形態索引(Software Configuration Index)
(7)には、コンパイルやリンク時の手順やデータ、ソフトウェアを再構築する際の手順が含まれる。
《11.16》 ソフトウェア形態索引(Software Configuration Index)
ソフトウェア形態索引(SCI)は、ソフトウェア製品の形態を識別する。
特定された形態識別やバージョンの識別が提供されるべきである。
注意： SCIはひとつのデータ項目、またはデータ項目のセット（階層的な）を含むことができる。SCIは以下にリストア
ップした項目を含むことができる、もしくは、個々の項目とそれらのバージョンを特定する別のSCIまたは別の形態識
別データを参照してもよい。
ここでは、以下が特定されるべきである。
(a) ソフトウェア製品
(b) 実行可能オブジェクトコード、もしあれば、パラメータデータ項目ファイル
(c) 各ソースコードコンポーネント
(d) もし使っているなら、ソフトウェア製品の中の既開発ソフトウェア
(e) ソフトウェアライフサイクルデータ
(f)
保管、リリースメディア
(g) 実行可能オブジェクトコードと、もしあれば、パラメータデータ項目ファイルを生成する手順、例えば、コンパイル
とリンクの手順とデータ、再構築、テスト、もしくは修正のためにソフトウェアをリカバーするために使用される手
順。
(h) ソフトウェアライフサイクル環境形態索引の参照（もし別にパッケージされているなら）。
75
MT-0595A
(i)
実行可能オブジェクトコードのデータ完全性チェック（もし使われているなら）
(j)
もしあれば、ユーザ編集可能なソフトウェアの編集のための手順、方法、ツール。
(k) ターゲットハードウェアへのソフトウェアのロード手順と方法。
注意： SCIはひとつのソフトウェア製品のバージョンのために作られてもよい、または、いくつかの代わりの、もしくは
連続したソフトウェア製品バージョンのためのデータを含んだ拡張がなされてもよい。
《11.16》
75
MT-0595A
【11.17】
3.不適合報告(Problem Reports)
《11.17》 不適合報告(Problem Reports)
不適合報告は、ソフトウェア製品の異常な動作、ソフトウェア契約や標準に準拠しないプロセス、ソフトウェアライフサ
イクルデータ内の不足に対する改善を特定し、記録する手段である。
不適合報告は以下を含む。
(a) 不適合が発見された形態項目、または／もしくはソフトウェアライフサイクルプロセス活動の特定。
(b) 変更した形態項目の特定、または変更したプロセスの記述。
(c) 不適合の内容が理解でき、解決できるような不適合の記述。不適合の記述には、不適合の潜在的な安全性に
関わる影響、または機能的な影響の評価を容易にするに十分な詳細な内容を含まなければならない。
(d) 報告された不適合を解決するために取られた改正内容の記述。
《11.17》
【11.18】
4.ソフトウェア形態管理記録(Software Configuration Management Records)
《11.18》 ソフトウェア形態管理記録(Software Configuration Management Records)
SCMプロセス活動の結果はソフトウェア形態管理記録(SCM Records)に記録される。例えば、形態識別リスト、ベー
スラインまたはソフトウェアライブラリ記録、変更履歴報告、保管記録、リリース記録などが含まれる。これらの例は、
これらの特定の型の記録を作らなければならないという意味ではない。
76
MT-0595A
注意： SCMプロセスの完全な性質のために、そのアウトプットはしばしば他のソフトウェアライフサイクルデータの一
部として含まれる。
《11.18》
76
MT-0595A
【8】
ソフトウェア品質保証プロセスは、承認された計画と標準に従ってプロセスが実行されていることを保証するもので
あり、それによりソフトウェアライフサイクルプロセスが要求に適合したソフトウェアを作成していることを保証するも
のである。
《8.0》 ソフトウェア品質保証プロセス(Software Quality Assurance Process)
このセクションではソフトウェア品質保証(SQA)プロセスの目的と活動について論じる。SQAプロセスはソフトウェア
計画プロセス(4を参照)とソフトウェア品質保証計画(11.5を参照)によって定義されたように適用されている。SQAプ
ロセス活動の成果物(outputs)は、ソフトウェア品質保証記録や他のソフトウェアライフサイクルデータに記録
(recorded)される。
SQAプロセスは、目的が満足され、不足が検出、評価、追跡、解決され、ソフトウェア製品とソフトウェアライフサイク
ルデータが認証要求に準拠するという保証を得るためにソフトウェアライフサイクルの成果物を評価する。
《8.0》
77
MT-0595A
【8.2】
《8.2》 ソフトウェア品質保証プロセスの活動(Software Quality Assurance Process Activities)
SQAプロセスの目的を満足させるための活動には以下のものが含まれる。
(a) SQAプロセスはソフトウェアライフサイクルの活動で積極的に役割を果たさなければならず、SQAプロセスの目
的が満足されることを保証するために、権威、責任(responsibility)、そして独立性を持ってSQAプロセスの実行
ができなければならない。
(b) SQAプロセスは、ソフトウェア計画と標準が作られ、DO-178Cに準拠していることと一貫性のためレビューされ
るという保証を提供しなければならない。
(c) SQAプロセスはソフトウェアライフサイクルプロセスが承認されたソフトウェア計画とプランに従っているという保
証を提供しなければならない。
(d) SQAプロセスには、ソフトウェアライフサイクルの間、ソフトウェアライフサイクルプロセスの監査が含まれなけ
ればならず、それは以下の保証を得るためである。
1. セクション4.2に規定されているように、ソフトウェア計画が利用できる
2. ソフトウェア計画と標準からの逸脱が検出、記録、評価、追跡、解決される
注意事項: プロセス逸脱の初期の検出がソフトウェアライフサイクル活動の目的の効率的な達成に支援するこ
とは、一般的に受け入れられている
3. 承認された逸脱が記録される
4. ソフトウェア開発環境がソフトウェア計画に規定されるように提供されている
5. 不適合報告、追跡、そして修正プロセス活動がソフトウェア形態管理計画に従っている
6. システム安全性評価プロセスを含むシステムプロセスによってソフトウェアライフサイクルプロセスへ提供さ
れる入力が提供されている
注意事項: ソフトウェアライフサイクルプロセスの活動の監視は、活動が管理下であることの保証を提供するた
めに行われても良い。
(e) SQAプロセスが、ソフトウェアライフサイクルプロセスの遷移基準が承認されたソフトウェア計画にしたがって満
足しているという保証を提供しなければならない
78
MT-0595A
(f)
SQAプロセスは、セクション7.3と添付Aの表で定義される管理カテゴリに従ってソフトウェアライフサイクルデータ
が管理されるという保証を提供しなければならない
(g) 認証申請(certification application)の一部として提出されるソフトウェア製品の提供の前に、ソフトウェア適合レビ
ューは行われなければならない
(h) SQAプロセスはSQAプロセス活動(11.19を参照)の記録を作成しなければならない。それには、認証申請の一部
として提出される各ソフトウェア製品のためのソフトウェア適合レビューの完了の証拠と監査結果が含まれる。
(i)
SQAプロセスは、サプライヤのプロセスと成果物が承認されたソフトウェア計画と標準に従っているという保証を
提供しなければならない
《8.2》
78
MT-0595A
【8.3】
《8.3》 ソフトウェア適合レビュー(Software Conformity Review)
ソフトウェア適合レビューの目的は、認証申請の一部として提出されるソフトウェア製品にとってソフトウェアライフサ
イクルプロセスが完全で、ソフトウェアライフサイクルデータが完全で、実行可能オブジェクトコードとパラメータデータ
項目(もしあれば)が、管理され再構築可能なことの保証を得ることである。
レビューは以下の項目を決定しなければならない。
(a) 認証発行のため計画されたソフトウェアライフサイクルプロセスの活動(ソフトウェアライフサイクルデータの作
成を含み)が完了し、その完了の記録が保存された
(b) 特定されたシステム要求、安全性要求、またはソフトウェア要求から開発されたソフトウェアライフサイクルデー
タが、それらの要求へ追跡可能であること
(c) ソフトウェアライフサイクルデータがソフトウェア計画と標準に合わせて生産され、SCM計画に合わせて管理さ
れているという証拠が存在する
(d) 不適合報告が評価され、それらのステータスが記録されたという証拠が存在する
(e) ソフトウェア要求逸脱が記録され、承認される
(f)
実行可能オブジェクトコードとパラメータデータ項目(もしあれば)が、保管されたソースコードから再生成される
(g) 承認されたソフトウェアが、リリースされた手順使用により首尾よくロード可能である
(h) 前回のソフトウェア適合レビューから持ち込まれた不適合報告が、そのステータスを決定するために再評価さ
れる
(i)
もし認証発行が既開発ソフトウェアの使用に求められるなら、現在ソフトウェア製品のベースラインは、前回の
ベースラインと、そのベースラインへの承認された変更について追跡可能である。
注意事項: 認定後のソフトウェアの改修のため、変更の重要性によって正当化されるよう、ソフトウェア適合レビュー
79
MT-0595A
活動のサブセットが実施されても良い
《8.3》
79
MT-0595A
【Table A-9】
《8.1》 ソフトウェア品質保証プロセスの目的(Software Quality Assurance Process Objectives)
SQAプロセスの目的は、ソフトウェアライフサイクルプロセスが、承認されたソフトウェア計画と標準に従いプロセス
がおこなわれるということを保証することによって、要求に準拠したソフトウェアを製造するという信用を提供すること
である。
SQAプロセスの目的は、以下の保証(assurance)を得ることである。
(a) ソフトウェア計画と標準が作られ、DO-178Cに従っており、また一貫性があることをレビューされる
(b) ソフトウェアライフサイクルプロセス(サプライヤのそれを含む)が、承認されたソフトウェア計画と標準に準拠し
ている
(c) ソフトウェアライフサイクルプロセスの遷移基準が満足されている
(d) ソフトウェア製品の適合レビューが行われている
添付Aの表A-9はSQAプロセスの目的と成果物の要約である。
《8.1》
80
MT-0595A
【Table A-9】
81
MT-0595A
【11.19】
《11.19》 ソフトウェア品質保証記録(Software Quality Assurance Records)
ソフトウェア品質保証プロセスの活動の結果は、ソフトウェア品質保証記録(SQA Records)に記録される。
それらには、SQAレビューまたは監査報告、会議議事録、認可されたプロセスの逸脱の記録、ソフトウェア適合性レ
ビューの記録が含まれる。
《11.19》
82
MT-0595A
【9】
認証連絡調整プロセスは、認証プロセスを支援するためにソフトウェアライフサイクルを通して、申請者と認証機関と
の間のコミュニケーションと理解を確立する。
83
MT-0595A
【9.1】
《9.1》 遵守の方法と計画(Means of Compliance and Planning)
申請者はどのように航空機搭載システム又は装置の開発が認証基準を満足させるかを定義する準拠の方法を提
案する。ソフトウェア認証計画(11.1を参照)は、提案された準拠の方法の文脈内で航空機搭載システム又は装置の
ソフトウェアについて定義する。この計画も、システム安全評価プロセスにより決定されるソフトウェアレベルを明言
(states)する。
活動を以下に示す。
(a) レビューのため認証機関へソフトウェア認証計画とその他の要求されたデータを提出すること
(b) ソフトウェア認証計画にかかわる認証機関によって識別された問題を解決すること
(c) 認証機関とソフトウェア認証計画の合意を得ること
《9.1》
84
MT-0595A
【9.2】
《9.2》 遵守の実証(Compliance Substantiation)
申請者は、レビューのためソフトウェアライフサイクルデータを認証機関が利用できるようにすることによって、ソフト
ウェアライフサイクルプロセスがソフトウェア計画を満足する証拠を提出する。認証機関のレビューは様々な施設で
行われても良い。例えば、レビューは申請者の設備で行われても良いし、申請者のサプライヤの設備で行われても
良いし、認証機関の設備で行われても良い。これは申請者やそのサプライヤとの討議を含んでも良い。申請者は、
これらのソフトウェアライフサイクルプロセスの活動のレビューをアレンジし、ソフトウェアライフサイクルデータを必要
に応じ利用できるようにする。
活動には以下のものが含まれる。
(a) レビューの結果として認証機関によって提出された問題を解決すること
(b) ソフトウェア完了報告(11.20を参照)、およびソフトウェア形態索引(11.16を参照)を認証機関へ提出すること
(c) 認証機関によって要求されたその他のデータや準拠の証拠を提出し、また利用可能にすること
《9.2》
《9.3》 認証機関へ提出される最低限のソフトウェアサイクルデータ(Minimum Software Life Cycle Data Submitted to
Certification Authority)
認証機関へ提出される最低限のソフトウェアライフサイクルデータを以下に示す。
(a) ソフトウェア認証計画
(b) ソフトウェア形態索引
85
MT-0595A
(c) ソフトウェア完了報告
《9.3》
《9.4》 型式仕様に関連するソフトウェアライフサイクルデータ(Software Life Cycle Data Related to Type Design)
別途認証機関に合意されない限り、認証されるべき製品の型式仕様に関するソフトウェアライフサイクルデータの取
得と承認に関して、規定(regulations)は以下の項目に適用される。
(a) ソフトウェ要求データ
(b) 設計記述
(c) ソースコード
(d) 実行可能オブジェクトコードとパラメータデータ項目ファイル(あるならば)
(e) ソフトウェア形態索引
(f)
ソフトウェア完了報告
《9.4》
85
MT-0595A
【Table A-10】
《9.0》 認証連絡調整プロセス(Certification Liaison Process)
認証連絡調整プロセスの目的を以下に示す。
(a) 認証プロセスを支援するため、ソフトウェアライフサイクルプロセスを通して、申請者と認証機関の間のコミュニ
ケーションと理解を確立すること
(b) ソフトウェア認証計画の承認を通して準拠の手段の合意を得ること
(c) 準拠の実証を提供すること
認証連絡調整プロセスはソフトウェア計画プロセス(4を参照)とソフトウェア認証計画(11.1を参照)に定義されるように
適用される。
添付Aの表A-10はこのプロセスの目的と成果物の要約である。
《9.0》
86
MT-0595A
【11.20】
《11.20》 ソフトウェア完了報告(Software Accomplishment Summary)
ソフトウェア完了報告はソフトウェア認証計画(PSAC)に準拠していることを示す基本データである。
ここには以下が含まれる。
(a) システム概要
この章は、システムの概要が記載され、その機能とそれらのハードウェア、ソフトウェアへの配置、アーキテクチ
ャ、使用するプロセッサー、ハードウェア／ソフトウェアインターフェース、安全性機能が含まれる。この章では、
ソフトウェア認証計画におけるシステム概要との差異についても記載する。
(b) ソフトウェア概要
この章では、特に、使用される安全性とパーティショニング概念を強調して、ソフトウェア機能について記載する
、また、ソフトウェア認証計画で提案されたソフトウェア概要との差異について説明する。
(c) 認証の考慮事項
この章では、ソフトウェア認証計画に記載された認証の考慮事項を再び述べる、またその際を記載する。
(d) ソフトウェアライフサイクル
この章では、実際のソフトウェアライフサイクルを要約し、ソフトウェア認証計画で提案されたソフトウェアライフ
サイクルプロセスとの違いを説明する。
(e) ソフトウェアライフサイクルデータ
この章では、作られるソフトウェアライフサイクルデータに関して、ソフトウェア認証計画で決めた計画との差異
、それぞれのデータ間及びシステムで定義されたデータの関係、そのデータを認証機関が利用できるようにす
る方法について記載する。この章は、形態識別とバージョンにより、適切なソフトウェア形態索引とソフトウェア
ライフサイクル環境形態索引を明示的に参照している。ソフトウェアライフサイクルデータの形態識別と特定の
バージョンに関する詳細の情報は、ソフトウェア形態索引の中に提供される。
87
MT-0595A
(f)
追加の考慮事項
この章では、認証機関の配慮を正当化する特別な考慮事項を要約する。ここには、そのような考慮事項に関し
てソフトウェア認証計画に書かれた提案からの際について説明する。イシューペーパー(issue paper)や特別な状
態(special conditions)と言ったこれらの事象に適用されるデータ項目に対する参照が作られるべきである。
(g) サプライヤ監督
この章では、どのようにサプライヤのプロセスとアウトプットを計画と標準に準拠させたかについて記載する。
(h) ソフトウェア識別
この章では、部品番号やバージョン番号によりソフトウェアの形態を識別する。
(i)
ソフトウェアの特性
この章では、実行可能オブジェクトコードのサイズ、最悪実行時間を含むタイミングの余裕、メモリの余裕、リソー
スの制限、それらの特性を図るために用いられる方法について述べる。
(j)
変更履歴
もし適用されるのであれば、この章には、以前の認証から安全性に影響を与える故障による変更と、変更前の
識別に注意したソフトウェアの変更、ソフトウェアライフサイクルプロセスに対する改良の要約を含む。
(k) ソフトウェアステータス
この章は、認証時に解決していなかった不適合報告の総括を含む。不適合報告の要約は、不適合報告をその
ままオープンにしておくという判断により安全性の面で、各不適合と関連するエラー、機能的な制限、運用的な
制約、潜在的なマイナス効果、及び今まで取られてきたいくつかの軽減行動の詳細を含む。
(l)
遵守ステートメント
この章では、DO-178Cの遵守のステートメント、ソフトウェア計画において特定された基準に準拠していることを
立証するために使用される方法の要約を含む。またこの章では、ソフトウェア完了報告の中ではどこでもカバー
しきれなかった認証機関によって作られた追加の規則、ソフトウェア計画、標準、DO-178Bからの逸脱について
も述べる。
《11.20》
87
MT-0595A
【12】
ここでは、１２章に記載されている追加の考慮事項(Additional Consideration)について説明する。
１２章では、以下の3項目について記載されている。
1.
既開発ソフトウェアの使用(Use of Previously Developed Software)
2.
ツール資格(Tool Qualification)
3.
代替手段(Alternative Methods)
88
MT-0595A
【12.1.1】
既開発ソフトウェアを使用する場合は、ここに挙げたどの例に属するかを判断し、その記載内容に従ってどのように
認証を得るのかについてソフトウェア認証計画(the Plan for Software Aspects of Certification)に記載しなければなら
ない。
9.1.1 既開発ソフトウェアの改修(Modification to Previously Developed Software)
ここでは、既にDO-178Cに従って開発されたソフトウェアに対して機能の追加等により改修を加える必要がある
場合について記載されている。
改修を加えることによりソフトウェアレベルが高くなる場合は、9.1.4のアップグレードのガイドラインが適用されな
ければならない。
変更が影響する領域を特定できればその部分に関して追加認証を受ければよいということになる。
89
MT-0595A
【12.1.2】
9.1.2 航空機インストールの変更(Change of Aircraft Installation)
既に認証を得たソフトウェアを搭載した航空システム（または装置）は、別の航空機に搭載してもよいとしている
。ただし、このガイドラインに従う必要がある。
(1)では、ソフトウェアレベルが変わらなければ、そのまま搭載してもいいことになる。明記はしていないがソフト
ウェアレベルが高くなる場合は、9.1.4のアップグレードのガイドラインが適用されると思われる。
(3)の解釈は難しいが、もともと認証を得ているソフトウェアであるからひと通りのソフトウェアライスサイクルデー
タが整っているはずである。従って、新しい航空機に搭載するという点に関しての安全性を立証するためのアウ
トプットがない場合と解釈できる。
90
MT-0595A
【12.1.3】
9.1.3 アプリケーション、開発環境の変更(Change of Application or Development Environment)
このケースは既開発ソフトウェアのソースコードをリコンパイルし新しい航空機に使用する場合や、アーキテクチ
ャが同じコンピュータに実行可能オブジェクトコードをインストールする場合などが想定される。
(2)のケースの解釈が難しいが、これは明らかに機能的にも変更がされるので9.1.1の改修のガイドラインが適
用されるべきと考える。
91
MT-0595A
【12.1.4】
9.1.4 開発ベースラインのアップグレード(Upgrading A Development Baseline)
ここでは、既開発ソフトウェアがDO-178Cに準拠していない場合について記載している。
これは、明らかに認証を受ける必要があり、その際に許される項目について記載されている。
(2)で言っているソフトウェア検証プロセスは、レビュー／分析のことと想定され、リバースエンジニアで作成され
た文書をレビュー／分析することを要求している。
(3)の製品サービス履歴については後述(9.3.2.5)する。
(4)に書かれていることは、アップグレードに限らず、既開発ソフトウェアを使用するに当たり、どのように認証を
得るのかをソフトウェア認証計画に明記し、承認を得なければならない。
92
MT-0595A
【12.1.5】
9.1.5 ソフトウェア形態管理の考慮事項(Software Configuration Management Considerations)
ここでは、既開発ソフトウェアを使用するに当たり、ソフトウェア形態管理として追加で考慮しなければならない
ことが記載されている。
(1)は既開発ソフトウェアとそれを流用したアプリケーション間のトレーサビリティを求めている。これはソフトウェ
ア製品だけでなくソフトウェアライフサイクルデータ間のトレーサビリティも要求されている。
(2)は、もし既開発ソフトウェアで不適合が発見されたら新しいアプリケーションにもその内容を反映できるような
管理をしなければならない、といった意味合いであると推測される。
【12.1.6】
9.1.6 ソフトウェア品質保証の考慮事項(Software Quality Assurance Considerations)
ここでは、既開発ソフトウェアを使用するに当たり、ソフトウェア品質保証として追加で考慮しなければならない
ことが記載されている。
(1)は手を加えずに使用する場合を想定していると推測される。手を加えられていれば、それなりに認証のプロ
セスが発生し、それを正規のソフトウェア品質保証プロセスで保証することになる。
(2)は、既開発ソフトウェアが使用されるからにはソフトウェアライフサイクルプロセスの省略があるはずなので、
それがソフトウェア計画で明確に定義されており承認されていることを保証することである。
93
MT-0595A
【12.2.1】
ツール資格に関しては、DO-178Bから大きく変更されている。
DO-178Bにおけるツール資格の基本は以下の通りであった。
Tool qualification is necessary when processes required by the rest of the document are eliminated, reduced or
automated by the use of a deterministic software tool whose outputs are not verified.
すなわち、そのアウトプットを検証されることなく、ツールを使用することによりプロセスが省略されたり、削減されたり
、自動化されるのであれば、ツール資格が必要となる。
この基本的な考え方はDO-178Cにおいても踏襲されている。
従来、ツールの種類としてソフトウェア開発プロセスに使用されるツールとソフトウェア検証プロセスに使用されるツ
ールの2種類としていたのに対して、3種類の分類としている。また、具体的なツールの資格化のプロセスについては
以下の補足資料で規定されている。
DO-330 Software Tool Qualification Consideration
94
MT-0595A
【12.2.2】
9.2.2 ツールの種類
DO-178Bでは開発ツールと検証ツールの2種類だったのに対して3種類に分類している。
Criteria1は、コンパイラやコード自動生成ツールなどがそれに分類される。ただし、多くの場合「ツールのアウト
プットがソフトウェア検証プロセスにより検証されるのであればツール資格の必要はない」に該当するのではな
いか。
ただし、コード自動生成ツールであったとしても、低レベル要求とソースコード間のトレーサビリティ(Table A-5 5.
Source Code is traceable to low-level requirement)のプロセスを自動化、省略することを目的として使用するので
あればCriteria2に分類されると思われる。
一方、検証ツールとしてテストツールやトレーサビリティの検証ツールなどがあるが、Criteria2か3のどちらに分
類されるか判断は難しいところである。
計画の段階で使用するツールに関してどれに分類するべきかを認証機関と調整する必要がある。
95
MT-0595A
【12.2.2】
9.2.3 ツール資格レベル(Tool Qualification Level)
ツール資格レベルとしてTQL-1からTQL-5までの5段階が設定されている。
TQL-1が一番厳しいレベルであり、TQL-5が一番緩いレベルである。
プロジェクトで使用するツールの資格化が必要となった場合は、できるだけ早い時期に認証機関(Certification
Authority)とTQLについて調整しなければならない。
96
MT-0595A
【12.2.3】
9.2.4 ツール資格のObjectives
DO-330Software Tool Qualification Considerationsで規定されているObjectiveの数を示した。
97
MT-0595A
【12.3】
DO-178Cが制定された段階でまだ推奨するだけの完成度に至っていない手法があり、そのいくつかをここで代替手
法(Alternative Methods)として取り上げている。
(2)(b)にあるようにソフトウェアライフサイクルプロセスにおいて代替手法を使用する場合は、ソフトウェア認証計画
(Plan for Software Aspects of Certification)にその手法を用いることを宣言しなければならない。また、そこにおいて
は以下について記載し、認証機関の同意を得る必要がある。
(i)
ソフトウェア開発プロセスにおけるその手法のインパクト
(ii)
ソフトウェアライフサイクルデータにおけるその手法のインパクト
(iii) 代替手法を使うことの合理性（システム安全目的を満足していることを示す）
98
MT-0595A
【12.3.2】
9.3.2.1 徹底的な入力テスト(Exhaustive Input Testing)
徹底的な入力テストは、テスト手法として同値テストと相対する手法である。
すなわち、入力データとして取り得る可能な値を全て網羅的にテストするという手法である。
ここでは、それが有効である場合、すなわち入力の値が限定されている時は実施してよいとしている。
99
MT-0595A
【12.3.3】
9.3.2.2 マルチバージョンデシミュラの検証
(Considerations for Multiple-Version Dissimilar Software Verification)
マルチバージョンデシミュラとは、多重化を構成するコンピュータシステムを異なるシステムで構築する技術であ
る。
ソフトウェアの不適合は多重化システムを構成しても同じソフトウェアが使われていれば信頼性は向上すること
はない。
従って、異なるソフトウェアで多重化システムを組むということは、信頼性を向上させる方法と言える。
航空システムでは、一般的に用いられている技術であるが、DO-178Cでは代替手法として扱われている。
ここでは、マルチバージョンデシミュラを構成する際の組み合わせについて述べている。
どの信頼性を向上させることを目的にするかによってその組み合わせは異なってくる。
100
MT-0595A
【12.3.3】
マルチバージョンデシミュラを採用する際の開発サイドの利点として、検証プロセスが若干ではあるが緩和される点
が挙げられる。
ここの表現はその根拠となる記載である。
また、マルチバージョンデシミュラを採用することにより、ソフトウェアレベルをダウンさせることができるらしいが、
DO-178Cの中にはそのような記載は見当たらない。
101
MT-0595A
【12.3.3.1】
(1) 独立したマルチバージョンデシミュラ(Independence Multiple-Version Dissimilar Software)
これは、別の開発チームが同じソフトウェアを作成する方法であり、(2)の異なるアーキテクチャのコンピュータシ
ステムを用いるマルチバージョンデシミュラと併せて一般的に用いられる方法である。
【12.3.3.2】
(2) マルチプロセッサ関連の検証(Multiple Processor-Related Verification)
これは、プロセッサーに内在している不適合がある場合、それを防ぐことができる。
102
MT-0595A
【12.3.3.3】
(3) マルチバージョンソースコードの検証(Multiple-Version Source Code Verification)
マルチバージョンデシミュラを使うことによる検証プロセスの緩和の一つとして、この項が挙げられる。
本来、構造カバレッジ分析（テストのコード網羅性分析）は、ソースコードとオブジェクトコードが直接トレースでき
ない場合（すなわちコンパイラ等がソースにないロジックを自動生成する場合）は、オブジェクトコードレベルで実
施しなければならない。ここでは、それを緩和しソースコードレベルでよいとしている。
【12.3.3.4】
(4) マルチバージョンデシミュラのツール資格(Tool Qualification for Multiple-Version Dissimilar Software)
マルチバージョンデシミュラとして開発されたツールの資格取得について記載されている。
その場合、ツール資格のプロセスを変更してよいとなっているが具体的な記載はない。ツール資格計画(Tool
Qualification Plan)に変更するプロセスの内容を記述し、認証機関の承認を得ると推測される。
103
MT-0595A
【12.3.3.5】
(5) マルチシミュレータと検証(Multiple Simulators and Verification)
この項も前述の(4)と同様にマルチバージョンデシミュラとして開発されたシミュレータを使用する場合にツール
資格を変更してもよいというものである。ここでも具体的な変更できる範囲に関して記述がないため、ツール資
格計画(Tool Qualification Plan)に変更するプロセスの内容を記述し、認証機関の承認を得ると推測される。
104
MT-0595A
【12.3.4】
9.3.2.3 ソフトウェア信頼性モデル(Software Reliability Models)
DO-178Cの制定にあたって、検証後のソフトウェアの含有エラー率を推定する手法について調査したが、高い
信頼性を持って推奨できる手法がなかったとして、代替手法として扱うことになったと記述がある。
【12.3.5】
9.3.2.4 製品サービス履歴(Product Service History)
これは、特にDO-178Cの認証を得ていないソフトウェアを使用する際に、以前の実績をもとに認証のレベルを緩
和させるものである。
これは、IEC61508における”proven in use”に相当する概念といえ、過去の実績から安全性、信頼性を推し量り、
認証を通そうとするものである。
DO-178Cの中では9.1.4開発ベースラインのアップグレードでも参照されている。
当然のことながら、DO-178Cの認証を得ていないとはいえ、それなりの管理（形態管理、不適合管理など）が施
されていないと認められない。また、ソフトウェア認証計画(Plan for Software Aspects of Certification)に認証機
関を納得させるだけの合理的な根拠を示す必要がある。
105
MT-0595A
106
MT-0595
107

Press Release - 株式会社ネクステッジテクノロジー

オープンソースソフトウェア開発における ソフトウェア

Multiskan FC+PC セットキャンペーン

ハードウェア出身のマネジャーに 分かっておいてほしい7つのこと

ソフトバンクモバイル：iPhone人気と純増数No.1を支えた

取扱説明書

多重録音可能なミキサーアプリの作成

衛星搭載ソフトウェ ア開発検証システ ム - National Instruments

カタログのダウンロード - SHOWA KIKAI