ソフトウェアの品質
目標
1/28 ページ
バージョン 3.0JP
ソース コードのソフトウェア品質目標
SOFTWARE QUALITY OBJECTIVES FOR SOURCE CODE (SQO)
MathWorks
http://www.mathworks.co.jp
ソフトウェア品質目標
改版表
インデッ
クス
V1.0
V2.0
日付
2009 年 2 月 15 日 初版
2010 年 3 月 5 日
-
SQR の形式の改善
-
明示的なコード メトリクス
-
系統的および潜在的なランタイム エラー、安
全および到達不可能な操作の定義
ISO 26262-6:2011 によるマッピングの追加。
V3.0
2012 年 5 月 2 日
V3.0JP 2014 年 3 月 28 日
節の
変更
変更の目的
すべて
すべて
§4
最初の MISRA サブセット内のルール 5.2 の追加。 §3.5.1
MISRA AC AGC サブセットの追加。
§3.5.1, §3.5.2
MISRA C++ サブセットの追加。
§3.5.1, §3.5.2
資料の日本語化
すべて
ソース コードのソフトウェア品質目標 - バージョン 3.0
2/28 ページ
ソフトウェア品質目標
目次
改版表 ............................................................................................................................................................................... 2
目次................................................................................................................................................................................... 3
1. 要件マッピング テーブル .......................................................................................................................................... 4
2. はじめに ..................................................................................................................................................................... 4
3. ソフトウェア品質目標 (SQO) ................................................................................................................................... 5
3.1.
ソフトウェア品質目標の概要 ........................................................................................................................... 5
3.2.
品質計画 ........................................................................................................................................................... 5
3.2.1.
品質レベルと納入回数 .............................................................................................................................. 6
3.2.2
人とツール ................................................................................................................................................ 7
3.2.3.
ランタイム エラーの定義 ......................................................................................................................... 8
3.2.4.
標準のコメントと正当化 .......................................................................................................................... 9
3.3.
詳細なデザイン説明 ....................................................................................................................................... 11
3.3.1.
アプリケーション レベル ....................................................................................................................... 11
3.3.2.
3.3.3.
モジュール レベル .................................................................................................................................. 11
ファイル ラベル ..................................................................................................................................... 11
3.4.
コード メトリクス .......................................................................................................................................... 12
3.5.
MISRA ルール サブセット ............................................................................................................................. 12
3.5.1.
3.5.2.
第 1 の MISRA ルール サブセット.......................................................................................................... 13
第 2 の MISRA ルール サブセット.......................................................................................................... 15
3.6.
系統ランタイム エラー................................................................................................................................... 18
3.7.
未終端の関数コールおよびループ ................................................................................................................. 19
3.8.
3.9.
到達不可能な分岐 ........................................................................................................................................... 19
潜在的ランタイム エラー ............................................................................................................................... 20
3.10.
データフロー解析 ........................................................................................................................................... 21
4. ISO 26262-6:2011 の要件マッピング ..................................................................................................................... 22
4.1.
4.2.
目的と範囲 ...................................................................................................................................................... 22
概要................................................................................................................... Error! Bookmark not defined.
4.3.
詳細................................................................................................................................................................. 23
4.3.1.
5 節：ソフトウェア レベルでの製品開発の開始 ................................................................................... 23
4.3.2.
4.3.3.
8 節：ソフトウェア ユニットの設計と実装 ........................................................................................... 24
9 節：ソフトウェア ユニット テスト .................................................................................................... 25
4.3.4.
10 節：ソフトウェアの統合とテスト .................................................................................................... 26
4.4.
トレーサビリティ SQO レベル / ISO 26262 要件 ......................................................................................... 26
ソース コードのソフトウェア品質目標 - バージョン 3.0
3/28 ページ
ソフトウェア品質目標
1. 要件マッピング テーブル
本書の範囲外にあるソフトウェア品質要件は、本書内に定義されている要件にマッピングすることができます。
この場合、サプライヤーは、2 つのセットの要件間のマッピングを定義するテーブルを提供するものと
します。
2. はじめに
本書は、コード品質および動的実行エラーにリンクした条件を使って、製品のソフトウェア品質を測定する
ための一般的および標準的な手法を定義します。
右の図は、次の 3 つのプロパティを示しています：「コスト」、「ソフトウェ
ア品質」、および「時間」は相互に関連してます。1 つのプロパティに対する要
件を変更すると、他の 2 つに影響が及びます。この文脈において、「時間」は製
品を納品するために必要な時間を意味し、「品質」は最終製品の品質を意味し、
「コスト」は製品を設計・製作するための総コストを意味します。
これらのプロパティの要件が定義されたら、次はこれらの要件をどのように達成
するかが問題となります。すべてのモジュールが必要な品質を満たすまでこれらのモジュールがテストされ
るという手法をとることができますが、品質改善のプロセスはしばしば途中で終了することになります。こ
れは、使用できる時間と予算を使い果たしてしまうことによるもので、品質目標に到達したからではありま
せん。開発プロセス内での検証プロセスを改善することで、高品質を達成するための時間とコストの削減に
役立ちます。
ソース コードのソフトウェア品質目標 - バージョン 3.0
4/28 ページ
ソフトウェア品質目標
3. ソフトウェア品質目標 (SQO)
本書では、4 つの品質レベルであるレベル QL-1 (最低品質) からレベル QL-4 (最高品質) に関連付けられる
6 つのソフトウェア品質目標 (SQO) を定義します。各ソフトウェア品質目標は、一連のソフトウェア品質
要件 (SQR) で構成されます。SQR の例としては、複雑性メトリクス、到達不可能コードの測定などがあ
ります。
3.1. ソフトウェア品質目標の概要
下表に、6 つのソフトウェア品質目標のそれぞれに到達するために必要なソフトウェア品質条件を示
します。
条件
目標
SQR
SQO-1
SQO-2
SQO-3
SQO-4
SQO-5
SQO-6
品質計画
SQR-10 SQR-100
X
X
X
X
X
X
詳細なデザイン説明
SQR-110 SQR-130
X
X
X
X
X
X
コード メトリクス
SQR-140 SQR-150
X
X
X
X
X
X
第 1 の MISRA-C:2004 ルール サブ
セット
SQR-160 SQR-170
X
X
X
X
X
X
系統的ランタイム エラー
SQR-200 SQR-210
X
X
X
X
X
終了しない機能
SQR-220
X
X
X
X
X
到達不可能な分岐
SQR-230
X
X
X
X
潜在的ランタイム エラーの第 1 の
サブセット
SQR-240
X
X
X
第 2 の MISRA-C:2004 ルール サブ
セット
SQR-180 SQR-190
X
X
潜在的ランタイム エラーの 第 2 の
サブセット
SQR-250
X
X
潜在的ランタイム エラーの
第三のサブセット
SQR-260
X
データフロー解析
SQR-270
X
以降の節にさまざまな条件を説明します (3.2 節で品質計画、3.3 節で詳細なデザイン説明、など)。
3.2. 品質計画
この節では、サプライヤーによって提供されることになる一般的な情報について説明します。これは、ソフト
ウェア品質要件の実現に関与する方法、ツール、およびチームに関する情報と、プロジェクトそのものに関す
る情報です。これらの情報により、作業を誰が行うか、作業をどこでどのように行うかが明確になります。
注意:「チーム」という言葉は、ドキュメンテーションのための情報を提供するツールを使用する人々や、
文書を執筆する人々を表します。
開発プロセスへの統合に関しては、サプライヤーがプロジェクト ライフ サイクルの間に SQO に関する情
報を提供するものとします。コード レビュー段階で該当の SQO アクティビティを実行することが推奨され
ます。これにより、メジャー納入のためのソフトウェア品質文書を簡潔かつ素早くまとめ上げて納入できる
ようになります。
ソース コードのソフトウェア品質目標 - バージョン 3.0
5/28 ページ
ソフトウェア品質目標
品質レベルと納入回数
3.2.1.
SQR-10
サプライヤーは各モジュールに品質レベルを関連付けそれらの選択を正当化す
るものとします。この要件は、アプリケーションのすべてのソース コード （たとえ
ば自動生成されたコード、レガシー コード、手書きコード、および COTS によって
生成されたコードなど) に及びます。
SQR-20
サプライヤーはソフトウェア納入回数とソフトウェア品質計画を提供するもの
とします。
ソフトウェア品質計画は、次のように各モジュールに示すテーブルで構成されるものとします。
• 対応する品質レベル (QL-1 から QL-4)。
• プロジェクト中にモジュールが納入される回数。
• このモジュールの納入ごとのソフトウェア品質目標。
注意：
-
製造会社はソフトウェア品質計画とそこで行われる決定を検証するものとします。
すべてのモジュールに対して、納入ごとに、同じ SQO 改善を持つことは必ずしも必要としません。
下表の例では、最終的なソフトウェア品質目標を達成するための各品質レベルの可能な進捗を示します。
品質レベル数は固定です。最初と最後と最後から 2 番目の納入に関連付けられている最小 SQO レベルも
固定です。納入回数（表中の行数）はプロジェクトに依存します。
品質レベル
納入
QL-1
QL-2
QL-3
QL-4
SQO-1
SQO-2
SQO-3
SQO-4
X 中間
...
...
...
...
X 中間
SQO-2
SQO-3
SQO-4
SQO-5
X 中間
...
...
...
...
最後から 2 番目
SQO-3
SQO-4
SQO-5
SQO-6
最後
SQO-3
SQO-4
SQO-5
SQO-6
最初
表の各セルは、最小許容ソフトウェア品質目標を示します
表に示すように、さまざまな品質レベルがさまざまな品質目標に対応できます。プロジェクトが複数のモジ
ュールで構成されている場合、各モジュールは異なる深刻度を持つことができます。したがって最終の
SQO レベルは、モジュールごとに異なることができます。この最終 SQO レベルでは、モジュールに対し
て対応する品質レベルを選択できます。プロジェクト中に複数回納入するモジュールは、選択した品質レベ
ルによってもモジュールの各納入の SQO レベルが定義されます。
ソース コードのソフトウェア品質目標 - バージョン 3.0
6/28 ページ
ソフトウェア品質目標
異なる深刻度の 3 つのモジュール（Module-1、Module-2、Module-3）で構成されるプロジェクトに対して
上記の表を使用した例：
-
Module-1 は非常に深刻と見なされます: その品質レベルは最高の QL-4 です。Module-1 の最初
の納入は少なくとも SQO-4、最後の 2 つの納入は SQO-6 でなければなりません。
Module-2 は深刻とは見なされません: その品質レベルは最低の QL-1 です。Module-2 の最初
の納入は少なくとも SQO-1、最後の 2 つの納入は少なくとも SQO-3 でなければなりません。
Module-3 は中程度の深刻と見なされます: これは、プロジェクトの開始時に品質レベルを QL-3 に設
定することに同意されています。Module-2 の最初の納入は少なくとも SQO-3、最後の
2 つの納入は少なくとも SQO-5 でなければなりません。
次の表は、プロジェクトの最後に 3 つのモジュールに対して到達すべき品質レベルと最小 SQO レベル
を示しています。
SQR-30
3.2.2
SQR-40
モジュール
品質レベル
到達すべき最小 SQO レベル（プロジ
ェクトの最後）
モジュール 1
QL-4
SQO-6
モジュール 2
QL-1
SQO-3
モジュール 3
QL-3
SQO-5
各モジュールの品質レベルとそれらを達成するためのプロセスがサプライヤーによって
定義されたら、サプライヤーは計画に対するすべての変更を正当化するものとします。
人とツール
サプライヤーは要件達成のために直接または間接的に関与した人に関する情報を提供
するものとします。
これには少なくとも次のことを含むものとします。
•
会社名
•
部および事業所名
•
所在地
•
実行した仕事：
データ生成（ツール ユーザー）、データ計算、検証、...
検証したモジュールのリスト
実現された要件のリスト
SQR-50
サプライヤーは使用したツールと方法のリストを提供するものとします。
これには少なくとも次のことを含むものとします。
•
ツールまたは方法の目的
•
影響を受けた要件と影響の方法
•
ツールまたは方法によってサポートされたアクティビティに責任を持つチーム
•
ツールまたは方法の経験。すなわち、チームがそのツールまたは方法を使用している期間
と頻度。頻度は次のように表現されなければなりません。
チームはこれらのツール（または方法）を年に何回使用しましたか？
これらのツールまたは方法を使用したプロジェクト数は？
ソース コードのソフトウェア品質目標 - バージョン 3.0
7/28 ページ
ソフトウェア品質目標
SQR-60
サプライヤーは、要件 SQR-50 に関するすべての変更を通知し正当化するもの
とします。
SQR-70
サプライヤーは使用した方法とツールが要件を達成するために適切であることを
正当化するものとする
これは、たとえば、ツールが提供するものおよび SQR を達成するためにこれがどのように役立つかを
説明しているツールのドキュメンテーションのセクションを参照することで実現できます。
SQR-80
3.2.3.
検証サイクルを通して、サプライヤーは、さまざまな納入の比較を簡易化するために、
使用したツールに対して同じオプション セットを維持することとする
ランタイム エラーの定義
この文書の他の部分では、ランタイム エラーに対する次の定義が使われます。
-
系統的ランタイム エラーとは、アプリケーションのすべての実行に対してエラーを発生する演算
です。これは一般的にはアプリケーションの入力の値には依存しません。
1: int foo (int a) {
2:
int b = 0;
3:
return (a / b); // 系統的なゼロ除算
4: }
-
潜在的ランタイム エラーとは、特定の状況で発生する可能性のあるエラーを生成するような演
算で、たとえばアプリケーションの入力の値に依存して発生します。
1: int foo (int a) {
2:
int b = 4;
3:
return (b / a); // 潜在的なゼロ除算
4: }
5:
注意: 潜在的エラー行 3 は、プログラムの入力である a に依存してエラーが発生するので、安全
であるかどうかを証明することはできません。
-
安全な演算とは、ランタイム エラーを生成できない演算（除算、乗算 ...）です。安全な演算の
例を次に示します。
1: int bar () {
2:
int x = 3;
3:
return (x);
4: }
5: int foo (int a) {
6:
int b = 4, c;
7:
c = bar ();
8:
b = a / (b – c); //安全な除算
9:
return (b / 2); //安全な除算
10:
}
注意: 除算行 8 は、ツールまたは人為的レビューにより安全であることが証明できます。
確かに、(b - c) = (4 - 3) = 1 でありゼロではありません。ゼロ除算は発生することがあ
りません。
ソース コードのソフトウェア品質目標 - バージョン 3.0
8/28 ページ
ソフトウェア品質目標
-
到達不可能な演算とは、アプリケーションの実行中に到達できない演算（除算、乗算 ...）です。
到達不可能な演算の例を次に示します。
1: int bar () {
2:
int x = 3;
3:
return (x);
4: }
5: int foo (int a) {
6:
int b;
7:
b = bar ();
8:
if (b < 0)
9:
b = b / a;
10:
return (b);
11:
}
//到達不可能な演算
注意:行 9 は、条件 (b < 0) が常に偽なので到達できません。したがって、この行ではゼロ除算は
発生することがありません。
3.2.4.
標準のコメントと正当化
この文書で定義されている SQR の一部は、安全または正当化の証明として結論されるための操作が必
要です。
-
コーディング ルール違反は修正または正当化されるものとします（(SQR-160, SQR-180 )。
潜在的ランタイム エラーのレビューは、目標に従って、定義されたレビュー範囲1 で実行される
必要があり、偏差は修正または正当化される必要があります (SQR-240 SQR-250 SQR-260 )。
ランタイム エラーの場合は、レビュー範囲はパーセンテージによって定義され、ランタイム エラー カテゴ
リの後に示されます（例：「ゼロ除算：80%」）これは、安全が証明されたまたは正当化されたとして結論
された演算の数を表しています。
これらの結論は次のように実行できます。
-
自動的（ツールによる）
一部自動および手動で完了
すべて手動。
例: 60 個の除算を含むアプリケーションを考えてみます。レビュー範囲目標が「ゼロ除算：80%」
であると仮定します。この 80% レビュー範囲は、除算の少なくとも 80% が「安全な演算」または正当化
できる「潜在的ランタイム エラー」であることを証明することにより達成できます。
ツールを使用する場合を考えてみます。ツールを使用して、60 個の除算のうち 45 個は「安全な演算」であ
ることを自動的に証明しました。レビュー目標は、少なくとも 3 つの「潜在的エラー」が正当化できること
を示すことにより達成できます。これは、(45 + 3) / 60 = 80% だからです。
正当化レビュー プロセスを簡易化する方法
•
•
1
系統的および潜在的エラーのステータス、およびオプションとして次のアクションが提供されるも
のとします。
品質要件の違反につながる系統的および潜在的エラーの深刻度を定義します。
レビュー範囲目標については、本書の後半の、対応する SQR が説明されている節で定義されています。
ソース コードのソフトウェア品質目標 - バージョン 3.0
9/28 ページ
ソフトウェア品質目標
SQR-90
サプライヤーは系統的および潜在的エラーの正規化ステータスを提供するもの
とします。
これは、次のリストから系統的および潜在的エラーに対してステータスを割り当てることで実現できます。
-
-
「未決定」
：ステータスがまだ割り当てられていません。このステータスは、系統的または潜在的エ
ラーについての決定を明示的に延期するために使用します。
「調査」
：潜在的エラーはさらに調査される必要があります。このステータスは、後で誰かが調査を実
施する必要のある場合などに便利です。
「修正」
：エラーを修正する必要があります。
「コード/モデルを変更」
：系統的または潜在的エラーをなくすためにコードを変更する必要があります。
コードがモデルから自動生成されている場合は、モデルを変更する必要があります。エラーが品質
要件の違反に結びつかない場合でもレビューアはコードの変更を望む場合があるという意味で、ス
テータスは「修正」とは異なります。
「別のオプションで再起動」
：ツールによって生成された潜在的エラーの場合、ツールを別のセットの
オプションまたは異なる構成で使用する必要があるときにこのステータスを使用できます。
「コード/モデル注釈で正当化」
：このステータスは、サプライヤーが潜在的エラーの正当化を不変的
にしたいときに使用できます。
「アクションの計画なし」
：このステータスは、サプライヤーが潜在的エラーに関して何もアクション
を計画しないときに使用できます。このステータスは、アクションを計画しない理由を説明するコ
メントと一緒に使用できます。
注意：
-
「アクションの計画なし」または「コード/モデル注釈で正当化」のステータスは、SQR-160
SQR-180 SQR-240 SQR-250 および SQR- 260 の意味で正当化される潜在的エラーへ繋がります。
-
「未決定」、
「調査」、
「修正」、
「コード/モデルを修正」または「別のオプションで再起動」のステー
タスは、SQR-160 SQR-180 SQR-240 SQR-250 および SQR-260 の意味で正当化されない潜在的エ
ラーへ繋がります。
-
サプライヤーは他のステータスを追加したり、自動車製造業者と交渉して、これらのステータスで
潜在的エラーの正当化が可能かどうかを決定したりできます。
SQR-100
サプライヤーは、品質要件の違反につながる系統的および潜在的エラーの深刻度を
提供するものとします。
深刻度は、品質要件の違反につながるすべての系統的および潜在的エラーに対して提供するものとします。
-
深刻度は、高、中、低が可能です。
深刻度は、少なくともステータスが「修正」および「コード/モデルを変更」の系統的および潜在的
エラーに対して提供されるものとします。
ソース コードのソフトウェア品質目標 - バージョン 3.0
10/28 ページ
ソフトウェア品質目標
3.3. 詳細なデザイン説明
この節に記載の情報は、アプリケーションのアーキテクチャとその完成度を評価することに役立ちます。
これは、本書の次の節のための基礎となります。
3.3.1.
SQR-110
アプリケーション レベル
サプライヤーはアプリケーションのアーキテクチャを説明するものとします。
これには少なくとも次のことを含むものとします。
•
ソフトウェア モジュールのリスト
•
モジュール間の関係
•
ソース ファイル数
•
ヘッダー ファイル数
3.3.2.
SQR-120
モジュール レベル
サプライヤーは各モジュールのアーキテクチャを説明するものとします。
これには少なくとも次のことを含むものとします。
•
各モジュールで使用されるソース ファイルのリスト
•
ファイル スコープを持つヘッダー ファイルのリスト。スコープは、プライベート、パブリック、
または外部のいずれかであることができます。
o 「プライベート」は 1 つのモジュールのみに使用されることを意味します。
o 「パブリック」は複数のモジュールによって使用されますが内部で開発されたものを意味します。
o 「外部」はオペレーティング システム、コンパイラー、デバイス ドライバー、またはサプライ
ヤーの知的財産ではない他のヘッダー ファイルを意味します。
3.3.3.
SQR-130
ファイル レベル
サプライヤーは各ファイルを説明する情報を提供するものとします。
これには少なくとも次のことを含むものとします。
•
サプライヤーのファイル管理（リビジョン コントロール）システムに基づいたファイル（ソースお
よびヘッダー）のバージョン
注意： バージョンがモジュール レベルでのみ管理されている場合は、サプライヤーはこの情報の
み提供する必要があります。
•
各ファイルの出自（次の例を参照）
COTS
生成されたコード
手書きコード
その他の場合、詳細を提示
注意： モジュール全体が同じ出自を持っている場合、情報はモジュール レベルで提供される必要
があります。
•
行数
ソース コードのソフトウェア品質目標 - バージョン 3.0
11/28 ページ
ソフトウェア品質目標
3.4. コード メトリクス
この節は、自動車製造会社がモジュールの特定を評価し、ラインタイム エラーのないアプリケーション品
質を例示するための方法とツールをよりよく理解することに役立つものです。
推奨される方法は、次のメトリクスを提供することです。
•
•
•
•
•
•
•
•
•
•
•
•
•
コメント密度：コメント数とステートメント数の関係
パス数
goto ステートメント数
サイクロマティック複雑度「v(G)」
関数当たりの呼び出し関数の数
関数当たりの呼び出された関数の数
関数のパラメーター数
関数当たりの命令数
コール レベル数
関数内の戻り点数
安定性指数：ソフトウェアの 2 つのバージョン間の変更箇所数の測定値を提供します
言語スコープ：関数を維持 / 変更するコストの指標
リカージョン数
注 1:
コード内のコメントに関する要件は、生成されたコードと COTS に対して任意です。
注 2:
上記のメトリクスは、HIS1 イニシアティブによって定義されたメトリクスの広範囲を提供
します。
SQR-140
自動車製造会社およびサプライヤーは、プロジェクトの開始時に、使用するコード
メトリクスを選択するものとします。
SQR-150
選択したメトリクスに対し、サプライヤーはモジュールが合意した境界制限に従う
こと、または偏差を正当化することを例示するものとします。
3.5. MISRA ルール サブセット
MISRA ルールの 2 つのサブセットが定義されています。これらの 2 つのサブセットは異なる品質目標に対
応しています。これらは、最終品質に到達するときの異なる手順として使用されることはありません。
1
HIS: Hersteller Inititiative Software。ドイツ自動車製造会社（Audi、BMW グループ、MaimlerChrysler、Porshe、
Volkswagen）によるイニシアティブで、その目的は ECU のネットワーク、プロセス成熟度の開発、ソフトウェア テ
スト、ソフトウェア ツール、およびプログラミングに対する標準ソフトウェア モジュールの分野内での合意による
標準の策定にあります。HIS は、ソフトウェアの評価で使用されるソフトウェア メトリクスの基本的なセットを指定
します。http://portal.automotive-his.de/images/pdf/SoftwareTest/his-sc-metriken.1.3.1_e.pdf を参照。
ソース コードのソフトウェア品質目標 - バージョン 3.0
12/28 ページ
ソフトウェア品質目標
3.5.1. 第 1 の MISRA ルール サブセット
MISRA-C:2004 に従った C コードのための 第 1 の MISRA ルール サブセットをここに示します。
このサブセットの一部は、MISRA AC AGC に従って自動生成されたコードに適用できます。
MISRA-C++:2008 に従って、等価なサブセットが C++ コードに適用できます。各 C ルールごとに、
最も近い C++ ルールの番号が表の最後に列に示されています。
MISRA-C の説明
MISRA-C
番号
MISRA-C
分類
MISRA AC
AGC
内部スコープの識別子は、外部スコープ内の識別子と同じ名前を
使用しないようにし、したがってその識別子を隠蔽することとし
ます。
5.2
必須
OBL
2-10-2
8.11
必須
OBL
3-3-2
外部リンクをもつ配列の宣言では、そのサイズが明示的に記述さ
れるか、初期化によって暗黙的に定義されるものとします。
8.12
必須
OBL
3-1-3
オブジェクトへのポインターと、整数型、オブジェクト型への別
のポインター、void へのポインター以外の型との間では変換は行
いません。
11.2
必須
OBL
5-2-8
ポインター型と整数型との間でキャストは行わないようにしま
す。
11.3
推奨
OBL
5-2-9
浮動小数点値の元になるビット表現は使用されません。
12.12
必須
OBL
3-9-3
浮動小数点式については、等価または非等価のテストは行われな
いものとします。
13.3
必須
6-2-2
含まれないものとします。
13.4
必須
6-5-1
for ステートメントの 3 つの式は、ループ制御のみを扱います。
13.5
必須
6-5-2
6-5-3
6-5-4
goto ステートメントは使用されません。
14.4
必須
6-6-1
6-6-2
6-6-4
関数はその最後に唯一の出口をもつものとします。
14.7
必須
OBL
6-6-5
関数は可変数の引数により定義しないものとします。
16.1
必須
OBL
8-4-1
関数は、その関数自身を直接的にも間接的にも呼び出しません。
16.2
必須
OBL
7-5-4
関数プロトタイプ内のポインターパラメーターは、そのポインタ
ーがアドレスされたオブジェクトの変更に使用する場合を除き、
const へのポインターとして宣言する必要があります。
16.7
推奨
>、>=、<、<= は、同じ配列を指す場合を除き、ポインター型に
は適用しません。
17.3
必須
配列のインデックス付けは、ポインター演算で唯一許可される形
式です。
17.4
必須
5-0-15
オブジェクトの宣言では、ポインター間接参照のレベルは 2 を超
えないようにします。
17.5
推奨
5-0-19
自動ストレージをもつオブジェクトのアドレスは、そのオブジェ
クトがなくなった後も残る可能性がある別のオブジェクトに代入
されません。
17.6
必須
メモリ領域は、無関係な目的に再利用されません。
18.3
必須
共用体は使用されません。
18.4
必須
動的ヒープメモリ割り当ては使用されません。
20.4
必須
Staticストーレジクラス指定子は、内部リンクをもつ
オブジェクトおよび関数の定義と宣言で使用されます。
for ステートメントの制御式には浮動小数点型のオブジェクトは
ソース コードのソフトウェア品質目標 - バージョン 3.0
MISRA-C++
等価
7-1-2
OBL
OBL
5-0-18
7-5-1
7-5-2
なし
OBL
9-5-1
18-4-1
13/28 ページ
ソフトウェア品質目標
C++ コードの場合、上記のリストは、MISRA-C++:2008 の次のサブセットによって完成されます。
MISRA-C++ の説明
MISRA-C
番号
MISRA-C++
分類
MISRA AC MISRA-C++
AGC
番号
基底クラスは、ダイヤモンド階層で使用される場合、単なる仮想
として宣言します。
なし
必須
なし
10-1-2
アクセス可能な基底クラスは、同じ階層内で仮想と非仮想の両方
にはなりません。
なし
必須
なし
10-1-3
継承階層全体で各パスの各仮想関数の定義は 1 つ以下です。
なし
必須
なし
10-3-1
オーバーライドする側の各仮想関数は、virtual キーワードを使
用して宣言されます。
なし
必須
なし
10-3-2
仮想関数は、それ自体が純粋仮想として宣言されている場合、純
粋仮想関数によってのみオーバーライドされます。
なし
必須
なし
10-3-3
制御は goto または switch ステートメントによって try または
catch ブロックに移されないものとします。
なし
必須
なし
15-0-3
空のスロー(throw;) は catch ハンドラーの複合ステートメント
においてのみ使用されます。
なし
必須
なし
15-1-3
クラスコンストラクターまたはデストラクターの function-tryblock 実装のハンドラーは、そのクラスまたはその基底クラスの
非静的メンバーを参照しません。
なし
必須
なし
15-3-3
クラスタイプ例外は常に参照でキャッチされるものとします。
なし
必須
なし
15-3-5
1 つの try-catch ステートメントまたは function-try-block 内
に、派生クラスおよびその基底クラスのいくつかまたはすべてに
対する複数のハンドラーがある場合、それらのハンドラーは、最
派生クラスから基底クラスの順に並ぶものとします。
なし
必須
なし
15-3-6
1 つの try-catch ステートメントまたは function-try-block 内
に複数のハンドラーがある場合、省略記号(catch-all) を指定し
たハンドラーは、最後になります。
なし
必須
なし
15-3-7
例外指定をもつ関数を宣言する場合、(他の翻訳単位内の) 同じ
関数のすべての宣言は、同じ一連の type-id (型 ID) を使用して
行われるものとします。
なし
必須
なし
15-4-1
クラスデストラクターは例外で終了されません。
なし
必須
なし
15-5-1
関数の宣言に例外指定が含まれる場合、その関数は、指定された
型の例外のみをスローできます。
なし
必須
なし
15-5-2
まとめとして、1 番目のサブセットのコーディング ルール数は次の通りです。
-
21 個が C 言語用
12 個が自動生成コード用
39 個が C++ 言語用
SQR-160
サプライヤーは、モジュール内のすべてのファイルが「第 1 の MISRA ルール セッ
ト」に順序していることを例示するものとします。サプライヤーは規則違反をすべて
修正または正当化するものとします。
目標はすべての違反を修正または正当化することになります。すなわち、ツールによって生成される違反が
ゼロである、または正当化されない違反がゼロであるということです。
ソース コードのソフトウェア品質目標 - バージョン 3.0
14/28 ページ
ソフトウェア品質目標
この例では、第 1 のサブセットにリストされている MISRA-C:2004 ルールの 78.49% が、準拠または正当
化されています。
ルール
5.2
8.11
8.12
11.2
11.3
12.2
13.3
13.4
13.5
14.4
14.7
16.1
16.2
16.7
17.3
17.4
17.5
17.6
18.3
18.4
20.4
合計
違反
0
10
0
150
0
0
10
0
2
0
0
2
0
0
5
0
6
0
0
1
0
コメント付き
0
10
0
120
0
0
8
0
2
0
0
1
0
0
5
0
0
0
0
0
0
186
146
78,49%
比率
SQR-170
3.5.2.
使用された 第 1 のサブセットのすべての変更は、サプライヤーと自動車製造会
社との間で合意されるものとします
第 2 の MISRA ルール サブセット
MISRA-C:2004 に従った C コードのための 第 1 の MISRA ルール サブセットをここに示します。
このサブセットの一部は、MISRA AC AGC に従って自動生成されたコードに適用できます。
MISRA-C++:2008 に従って、等価なサブセットが C++ コードに適用できます。各 C ルールごとに、
最も近い C++ ルールの番号が表の最後に列に示されています。
MISRA-C
番号
MISRA-C
分類
MISRA AC
AGC
MISRA-C++
等価
基本データ型の代わりに、サイズと符号の有無を示す typedef を
使用する必要があります。
6.3
推奨
OBL
3-9-2
単一の関数内からのみアクセスされるオブジェクトは、ブロック
スコープで定義されます。
8.7
必須
OBL
3-4-1
配列および構造体の非ゼロによる初期化では、構造を指示して一
致させるために中かっこが使用されます。
9.2
必須
列挙子リストでは、すべての項目を明示的に初期化する場合を除
き、最初のメンバー以外のメンバーを明示的に初期化するために
「＝」構造は使用されません。
9.3
必須
10.3
必須
5-0-7
5-0-8
5-0-9
ビット演算子 ~ および << が、基のタイプの符号なし char ま
たは符号なし short のオペランドに適用された場合、
結果は、オペランドの基のタイプにただちにキャストされ
るものとします。
10.5
必須
5-0-10
関数へのポインターと整数型以外の型との間では変換は行いま
せん。
11.1
必須
MISRA-C の説明
整数型の複合式の値は、式の元になる型と符号の有無が同じで
ある、より小さい型へのキャストのみが許されます。
ソース コードのソフトウェア品質目標 - バージョン 3.0
8-5-2
OBL
OBL
8-5-3
5-2-6
15/28 ページ
ソフトウェア品質目標
MISRA-C
番号
MISRA-C
分類
MISRA AC
AGC
MISRA-C++
等価
ポインターによってアドレスされたタイプから const または
volatile 修飾を削除するようなキャストは実行しないもの
とします。
11.5
必須
OBL
5-2-5
式中における C の演算子の優先順位規則への依存は制限する必
要があります。
12.1
推奨
式の値は、標準が許可する式のいかなる順序においても同じで
あるものとします。
12.2
必須
論理演算子&& または|| のオペランドは一次式になります。
12.5
必須
5-2-1
論理演算子(&&、|| および!) のオペランドは、実質的に
boolean でなければなりません。実質的に boolean である式は
、(&&、||または!) 以外の演算子のオペランドとして使用され
ないようにします。
12.6
推奨
4-5-1
単項マイナス演算子は、基のタイプが符号なしの式には適用し
ないものとします。
12.9
必須
OBL
5-3-2
コンマ演算子は使用しないものとします。
12.10
必須
OBL
5-18-1
論理値が生成される式では代入演算子は使用されません。
13.1
必須
6-2-1
オペランドが実質的に boolean である場合を除き、ゼロとの
比較テストは明示的に行うことが必要です。
13.2
推奨
5-0-13
for ループ内で反復回数のカウンターとして使用される数値変
数は、ループの本体内で変更されないようにします。
13.6
必須
6-5-3
switch、while、do ... while または for ステートメントのボディ
を形成するステートメントは、複合ステートメントであるもの
とします。
14.8
必須
6-3-1
すべての if/else if 構造には、最後の else 句が含まれる必
要があります。
14.10
必須
6-4-2
switch ステートメントの最後の句は、default 句になります。
15.3
必須
6-4-6
関数のプロトタイプ宣言では、すべてのパラメーターに対し識
別子が指定されます。
16.3
必須
OBL
なし
戻り値型が非 void である関数のすべての出口パスには、式を
もつ明示的な return ステートメントが記述されるものとしま
す。
16.8
必須
OBL
8-4-3
関数の識別子は、& が前に付くか、丸かっこで囲んだパラメー
ターリスト(空でも可)が指定された場合にのみ使用されます。
16.9
必須
OBL
8-4-4
C マクロは、中かっこで囲まれた初期化子、定数、丸かっこで
囲まれた式、型修飾子、ストレージクラス指定子、do-whilezero 構造にのみ展開されます。
19.4
必須
関数形式マクロの引数にはプリプロセッサ命令のようなトーク
ンは含めないものとします。
19.9
必須
OBL
16-0-5
関数形式マクロの定義では、パラメーターの各インスタンスは
、# または## のオペランドとして使用される場合を除き、丸
かっこで囲まれるものとします。
19.10
必須
OBL
16-0-6
MISRA-C の説明
ソース コードのソフトウェア品質目標 - バージョン 3.0
5-0-2
OBL
5-0-1
16-2-2
16/28 ページ
ソフトウェア品質目標
MISRA-C
番号
MISRA-C
分類
MISRA AC
AGC
MISRA-C++
等価
プリプロセッサ命令のすべてのマクロ識別子は、#ifdef およ
び#ifndef プリプロセッサ命令や defined() 演算子以外では
、使用前に定義されます。
19.11
必須
OBL
16-0-7
1 つのマクロ定義では#または##プリプロセッサ演算子は最大
でも 1 つとします。
19.12
必須
OBL
16-3-1
ライブラリ関数に渡される値の妥当性がチェックされます。
20.3
必須
OBL
なし
MISRA-C の説明
C++ コードの場合、上記のリストは、MISRA-C++:2008 の次のサブセットによって完成されます。
MISRA-C++ の説明
MISRA-C
番号
MISRA-C++
分類
MISRA AC
AGC
MISRA-C++
番号
仮想基底クラスへのポインターは dynamic_cast によって派生ク
ラスへのポインターにのみキャストされます。
なし
必須
なし
5-2-2
ポインター型のオブジェクトは、直接的にも間接的にも関連のな
いポインター型には変換されません。
なし
必須
なし
5-2-7
コンマ演算子、&& 演算子および|| 演算子がオーバーロードされ
ないようにします。
なし
必須
なし
5-2-11
単項演算子& はオーバーロードされません。
なし
必須
なし
5-3-3
非 POD クラスタイプのメンバーデータは private です。
なし
必須
なし
11-0-1
オブジェクトの動的な型は、そのコンストラクターまたはデスト
ラクターの本体から使用されないものとします。
なし
必須
なし
12-1-1
抽象クラスでは、コピー代入演算子は protected または private
として宣言されます。
なし
必須
なし
12-8-2
まとめとして、第 1 のサブセットのコーディング ルース数は次の通りです。
-
29 個が C 言語用
16 個が自動生成コード用
36 個が C++ 言語用
SQR-180
サプライヤーは、モジュール内のすべてのファイルが「第 2 の MISRA ルール セッ
ト」に順序していることを例示するものとします。サプライヤーは規則違反をすべて
修正または正当化するものとします。
目標はすべての違反を修正または正当化することにあります。すなわち、ツールによって生成される違反が
ゼロである、または正当化されない違反がゼロであるということです。
SQR-190
使用された 第 2 のサブセットのすべての変更は、サプライヤーと自動車製造会社
との間で合意されるものとします。
ソース コードのソフトウェア品質目標 - バージョン 3.0
17/28 ページ
ソフトウェア品質目標
3.6. 系統ランタイム エラー
SQR-200
サプライヤーは、モジュール内のすべてのファイルに対して系統的ランタイム エラ
ーのレビューが実行されたこと、および修正されなかったエラーが正当化さ
れたことを、次のカテゴリに対して例示するものとします。
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
SQR-210
範囲外の配列アクセス
ゼロ除算
未初期化データへのリード アクセス
未初期化の値を返す関数
整数オーバーフロー/アンダーフロー
浮動小数点オーバーフロー
NULL または範囲外ポインターによる逆参照
未初期化ポインターの使用（リードまたは逆参照）
0..31 (0..63) でのシフト量および左シフトの左オペランドが負
関数ポインターへ渡された引数の不正なタイプ
関数ポインターへ渡された引数の不正な個数
関数または関数ポインターの不正な戻りタイプ
算術関数の不正な戻りタイプ
非 NULL の this-pointer（C++ アプリケーションのみ）
正の配列サイズ（C++ アプリケーションのみ）
不正な typeid 引数（C++ アプリケーションのみ）
ポインターの不正な dynamic_cast（C++ アプリケーションのみ）
参照の不正な dynamic_cast（C++ アプリケーションのみ）
メンバーへの無効なポインター（C++ アプリケーションのみ）
純粋バーチャル関数のコール（C++ アプリケーションのみ）
this-pointer の不正タイプ（C++ アプリケーションのみ）
各種類のランタイム エラーに対して、サプライヤーは開発フェーズで適用した
方法およびプロセスを正当化してエラーのないようにするものとします。
ソース コードのソフトウェア品質目標 - バージョン 3.0
18/28 ページ
ソフトウェア品質目標
3.7. 未終端の関数コールおよびループ
SQR-220
サプライヤーは、開発フェーズ中に適用した方法とプロセスを正当化し、未終端の
コールやループがないようにするものとします。
注意: コードが次のものを意図的に含む場合
•
•
「while(1)」あるいは「for(;;)」のような未終端のループ
「exit」、
「stop」、
「My_Non_Returning_Function」のようなコールの未終端これらは
正当化される必要があります。
3.8. 到達不可能な分岐
SQR-230
サプライヤーは、ファイルが正当化されていないデッド コード分岐を含まないこと
を例示するものとします。
注意: アプリケーション内に意図的に含まれているすべての防衛的コードおよびデッド コードは、
正当化されるものとします。
ソース コードのソフトウェア品質目標 - バージョン 3.0
19/28 ページ
ソフトウェア品質目標
3.9. 潜在的ランタイム エラー
SQR-240
サプライヤーは、モジュール内のすべてのファイルに対して、レビュー範囲レベル 1
（最低）の潜在的ランタイム エラーのレビューが実行されたこと、および修正され
なかった潜在的エラーが正当化されたことを、例示するものとします。
下表の第 2 列を参照してください。
SQR-250
サプライヤーは、モジュール内のすべてのファイルに対して、レビュー範囲レベル 2
（中程度）の潜在的ランタイム エラーのレビューが実行されたこと、および修正さ
れなかった潜在的エラーが正当化されたことを、例示するものとします。
下表の第 3 列を参照してください。
SQR-260
サプライヤーは、モジュール内のすべてのファイルに対して、レビュー範囲レベル 3
（最高）の潜在的ランタイム エラーのレビューが実行されたこと、および修正さ
れなかった潜在的エラーが正当化されたことを、例示するものとします。
下表の最後の列を参照してください。
各 SQR に、サプライヤーは、少なくとも対応する列に示された次の目標を達成する
ものとします。
潜在的ランタイム エラー
範囲外の配列アクセス
ゼロ除算
ローカルの未初期化データへのリード アクセス
非ローカルの未初期化データへのリード アクセス
未初期化の値を返す関数
整数オーバーフロー/アンダーフロー
浮動小数点オーバーフロー
NULL または範囲外ポインターによる逆参照
未初期化ポインターの使用（リードまたは逆参照）
0..31 (0.63) でのシフト量および左シフトの左オペランドが負
関数ポインターへ渡された引数の不正なタイプ
関数ポインターへ渡された引数の不正な個数
関数または関数ポインターの不正な戻りタイプ
算術関数の不正な戻りタイプ
非 NULL の this-pointer（C++ アプリケーションのみ）
正の配列サイズ（C++ アプリケーションのみ）
不正な typeid 引数（C++ アプリケーションのみ）
ポインターの不正な動的キャスト（C++ アプリケーションのみ）
参照の不正な動的キャスト（C++ アプリケーションのみ）
メンバーへの無効なポインター（C++ アプリケーションのみ）
純粋バーチャル関数のコール（C++ アプリケーションのみ）
this-pointer の不正タイプ（C++ アプリケーションのみ）
ソース コードのソフトウェア品質目標 - バージョン 3.0
SQR-240
SQR-250
SQR-260
80%
90%
100%
80%
80%
60%
80%
60%
60%
90%
90%
70%
90%
80%
80%
100%
100%
80%
100%
100%
100%
60%
60%
80%
60%
60%
60%
70%
70%
90%
80%
80%
80%
80%
80%
100%
100%
100%
100%
60%
50%
50%
50%
50%
50%
50%
80%
70%
70%
70%
70%
70%
70%
100%
90%
90%
90%
90%
90%
90%
50%
50%
70%
70%
90%
90%
20/28 ページ
ソフトウェア品質目標
3.10. データフロー解析
SQR-270
サプライヤーは、各モジュールに、データ フロー解析結果を提供するもの
とします。
これには少なくとも次のことを含むものとします。
•
•
•
コンポーネント コール ツリー
グローバル変数への読み取り/書き込み アクセス
共有変数とそれに関連する同時実行アクセス保護（存在する場合）のリスト
ソース コードのソフトウェア品質目標 - バージョン 3.0
21/28 ページ
ソフトウェア品質目標
4. ISO 26262-6:2011 の要件マッピング
4.1. 目的と範囲
この節では、ソフトウェア レベルで一部の ISO 26262 目標を達成するための可能な方法を説明
します。
これは ISO 26262 で定義されている方法に準拠したガイダンスを提供します。これは、ISO 要件
に準拠するための方法と詳細を説明し、コードを検証するための方法を含み、ISO 26262 の表と
節に従います。
4.2. 概要
下表に、SQR グループと ISO 26262 のマッピングされた節と表の提案をまとめます。また、
コメント列に、SQO 文書が ISO 26262 検証プロセスの文脈において達成することに役立つもの
を説明します。
ISO 標準とのマッピングは、次の 2 種類が可能です。
•
•
表とのマッピング： SQR は表の一部の特定の方法に従います。
節とのマッピング： SQR は節の要件の一部を解決するために役立ちます。
文書が達成に役立つ要件提案は次の通りです。
非決定、実装定義済み、あるいは未定義の振舞を無効にする。
ソフトウェアロバスト性など、機能性以外の要件を達成する。
ISO 26262 節
ISO 参照
SQR
コメント
#5.ソフトウェア レベ
ルでの製品開発の開始
• 表1
• 140 ～ 190
• 270
これらの SQR を適用することにより、デザイン
と実装の正当性をサポートするために役立ちます。
#8.ソフトウェア ユニ
ットの設計と実装
• 表8
• 50 ～ 80
• 表9
• 140 ～ 200
• 220
• 240 ～ 270
SQO 文書の適用により、表 8 および 9 に定義さ
れている要件に準拠できます。
#9.ソフトウェア
ユニット テスト
• 9.4.3 節
• 200 ～ 270
SQO 文書の適用により、次のようなユニット テス
トを減ずることができます。
•
意図しない機能性の排除
•
堅牢性
9.4.3.e 節の例は「アクセス不可能なソフトウェア
の排除」に言及していますが、これは SQR-230 で
扱われています。
表 10 の注 b は、
「変数の値の破損」の場合のエ
ラーを検出する必要性について言及しています。
これは、アプリケーションの入力に対して全範囲が
使用された場合、SQR-200 から SQR-260 で扱わ
れています。
節とのマッピング
表との
マッピング
•
•
#10.ソフトウェアの
統合とテスト
• 10.4.3 節
• 230
SQO 文書の適用により、次のような統合とテスト
を減ずることができます。
•
堅牢性
10.4.3.d の例は「アクセス不可能なソフトウェ
アの排除」に言及していますが、これは SQR-230
で扱われています。
ソース コードのソフトウェア品質目標 - バージョン 3.0
22/28 ページ
ソフトウェア品質目標
4.3. 詳細
注 1:この節では、 MISRA-C:2004 ルールが例として提供されています。3.5 節の MISRA-C++:2008 対
応ルールを参照することにより、C++ に対する同じマッピングが得られます。
注 2:「関連 SQR」列のすべての SQR は、対応する ISO 26262 方法または節をカバーするために適用
されるものとします。
4.3.1.
5 節：ソフトウェア レベルでの製品開発の開始
表 1 - モデリングおよびコーディングのガイドラインによって言及されるトピック
方法
関連 SQR
コメント
1a
低複雑性の実施
140, 150
コード メトリクスとその境界の 1 つの目的は、ソフトウェ
アの複雑性を低くすることにあります。
1b
言語サブセットの使用
160, 170, 180,
190
3.5 節に定義されている両方の MISRA サブセットには、
C および C++ 言語のサブセットの使用を可能にするルール
が含まれています。
例：12.10, 13.1, 14.4, 18.4, ...
1c
厳密な型指定の実施
160, 170, 180,
190
3.5 節に定義されている両方の MISRA サブセットには、
C および C++ 言語で厳密な型指定を可能にするルールが含
まれています。
例：6.3, 8.12, 11.1, 16.7, 17.5, ...
1d
防衛的実装手法の使用
160, 170, 180,
190
3.5 節に定義されている 第 2 の MISRA サブセットには、
C および C++ 言語で防衛的プログラミングを可能にする
ルールが含まれています。
例：14.10, 15.3, ...
1e
確立されているデザイン法
則の使用
160, 170
180, 190
3.5 節に定義されている両方の MISRA サブセットには、
確立されているデザイン法則の使用を可能にするルールが
含まれています。
例：8.7, 16.2, 16.8, 17.5, ...
1h
命名規則の使用
270
データディクショナリーでは、グローバル変数に対する命
名規則をレビューできます。
ソース コードのソフトウェア品質目標 - バージョン 3.0
23/28 ページ
ソフトウェア品質目標
4.3.2.
8 節：ソフトウェア ユニットの設計と実装
表 8 - ソフトウェア ユニット デザインと実装のためのデザイン法則
方法
関連 SQR
コメント
1a
サブプログラムおよび関
数での 1 つの入口点と
1 つの出口点
160, 170
MISRA ルール 14.7
1b
動的オブジェクトまたは
変数なし、あるいは作成
中のオンライン テスト
160, 170
MISRA ルール 20.4
1c
変数の初期化
200, 240, 250,
260
表のこの尺度は、次のように、ラインタイム エラー結果
で追跡できます。
「ローカルの未初期化データへのリード アクセス」
「非ローカルの未初期化データへのリード アクセス」
1d
変数名の複数使
用なし
160, 170
1e
グローバル変数を避ける
またはその使用を正当化
します
160, 170,
180, 190,
270
1f
ポインターの制限使用
160, 170,
180, 190
MISRA ルール 5.2 の実施により、ネスト範囲内での同名
の変数の検出に役立ちます。
データフロー解析中に提供されたグローバル変数へ
の書き込み/読み取りアクセスを含むデータ辞書は、
このルールの実装に役立ちます。
MISRA ルール 8.11 および 8.7 を実施することに
より、範囲がグローバルであるべきでない変数を検
出するために役立ちます。
3.5c 節に定義されている両方の MISRA サブセットには、
確立されているデザイン法則の使用を可能にするルールが
含まれています。
例：11.1, 11.2, 11.3, 11.5, 16.7, 17.3, 17,4, 17.5, 17.6, ...
200, 240, 250,
260
表のこの尺度は、次のように、ラインタイム エラー結果
で追跡できます。
「ヌルまたは範囲外ポインターによる逆参照」
「未初期化ポインターの使用（リードまたは逆参照）
」
無効な動的引数をもつ関数ポインター
1g
暗黙の型変換なし
160, 170, 180,
190
3.5 節に定義されている両方の MISRA サブセットには、
確立されているデザイン法則の使用を可能にするルールが
含まれています。
例：11.1, 11.2, 11.3, 11.5
1h
160, 170
MISRA ルール 5.2
1i
隠蔽されたデータ フロー
またはコントロール フロー
なし
無条件ジャンプなし
160, 170
MISRA ルール 14.4
1j
リカージョンなし
140, 150
160, 170
MISRA ルール 16.2
ソース コードのソフトウェア品質目標 - バージョン 3.0
24/28 ページ
ソフトウェア品質目標
表 9 - ソフトウェア ユニット デザインと実装の検証のための方法
方法
関連 SQR
コメント
1a
ウォークスルー
200, 240
表のこの測定は、SQR 200 および 240 の出力により部分的
にサポートできます。潜在的ランタイム エラーのリストが生
成されると直ちに、それをウォークスルーできます。
1b
検査
200, 240,
250, 260,
270
表のこの測定は、SQR 200、240 ～ 260、および 270 の出力
により部分的にサポートできます。コードは、系統的および潜
在的ランタイム エラーの主要部分で検査できます。
コンポーネントのデータディクショナリーとコール ツリーを
検査して問題を検出することもできます。
1d
形式検証
200, 240,
250, 260
ゼロ除算またはオーバーフローなどのランタイム エラー
の排除は、システムの暗黙の仕様です。
これらが排除されていることを証明することは、この暗黙の仕
様に対してシステムの正しさを証明することの一部です。
C および C++ は形式表記ではないので、この方法は部
分的にカバーされています。
1e
制御フロー解析
110-120
表のこの測定は、SQR 110 ～120 の出力により部分的に提供
できます（アプリケーション レベルとファイル レベルの
説明）
。
備考： 表 9 の注意「c」に示したように、この要件は、形式検証
（「1d」）または意味論的コード解析（
「1h」
）に基づいた方
法を使ってカバーできます。
1f
データ フロー解析
これは SQR 270 の目的です。
270
備考： 表 9 の注意「c」に示したように、この要件は、形式検証
（「1d」）または意味論的コード解析（
「1h」
）に基づいた方
法を使ってカバーできます。
4.3.3.
1g
静的コード解析
140,
160, 170,
180, 190
複雑性メトリクスおよび MISRA ルールをチェックすることで、
表のこの測定を実現することに役立ちます。
1h
意味論的コード解析
70, 200,
240, 250,
260
抽象解釈によるランタイム エラー検出は、表 9 の注意「d」
で定義されているように、意味論的コード解析です。
9 節：ソフトウェア ユニット テスト
この節では、ISO 26262 の 9.4.3 節で定義されている要件を実現するための可能な方法を説明します。
ISO ユニット テスト目標
（「ソフトウェア ユニットが次の
ことを達成していることを例示する
ために適用されるものとします」）
関連 SQR
コメント
d. 意図しない機能性の排除の自信
230
コードのアクセス不可能な部分の存在/排除を制御すること
により、意図しない機能性の存在/排除を検出するために役
立ちます。
200, 240,
250, 260
これらの SQR をカバーすることで、意図しない機能性を
生成する不定義動作を減ずることに役立ちます。
たとえば、データが初期化されていないまたは範囲外の
配列アクセスにより、コンポーネントによって生成される
不明な値。
次に機能テスト（ユニットと統合）をプログラムの機能
性に対して実施できます。
e. ロバスト性
200, 240,
250, 260
実際の / 潜在的ランタイム エラーの解析と修正または正当化
を行うことで、一部の複雑なエラーが回避されます。これ
は、堅牢なコードの生成を実現するために役立ちます。たと
えば、ゼロ除算や、NULL ポインター変数の逆参照。
ソース コードのソフトウェア品質目標 - バージョン 3.0
25/28 ページ
ソフトウェア品質目標
SQR 200 ～ 260 が実現された場合、出願者は、9.4.3 節に定義されているその他の目標について、表 10、
11、12 に記載のソフトウェア ユニット テスト方法を重点に考慮することになるかもしれません。これ
らの目標は以下に示す通りです。
a. ソフトウェア ユニット デザイン仕様の準拠
b. ハードウェア-ソフトウェア インターフェイスの仕様の準拠
c. 指定された機能性（前のアクティビティの補足）
f. 機能性をサポートするための十分なリソース
10 節：ソフトウェアの統合とテスト
4.3.4.
SQO 文書を適用することで、ソフトウェア コンポーネントが ISO 26262 標準の 10.4.3 節に定義され
ている次の目標を達成することを例示することに役立ちます。
d. ロバスト性
したがって、SQR 140 ～ 270 が実現された場合、出願者は、10.4.3 節に定義されているその他の目標に
ついて、表 13、14、15 に記載のソフトウェア統合テスト方法を重点に考慮することになるかもしれま
せん。これらの目標は以下に示す通りです。
a. ソフトウェア アーキテクチャ デザインの準拠
b. ハードウェア-ソフトウェア インターフェイスの仕様の準拠
指定された機能性
d. 機能性をサポートするための十分なリソース
c.
4.4. トレーサビリティ SQO レベル / ISO 26262 要件
次ページの追跡性マトリクスの理解を簡単にするために、各 SQO レベルに関連した SQR を次の
表に再び示します。
SQO レベル
SQR
SQO-1
10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 170
SQO-2
Idem SQO-1, 200, 210, 220
SQO-3
Idem SQO-2, 230
SQO-4
Idem SQO-3, 240
SQO-5
Idem SQO-4, 180, 190, 250
SQO-6
Idem SQO-5, 260, 270
ソース コードのソフトウェア品質目標 - バージョン 3.0
26/28 ページ
ソフトウェア品質目標
次の表に、どの ISO 26262 要件がすべての SQO レベルに対してカバーされているかを示します。
要件が完全または部分的にカバーされていない場合も、そのことが記載されています。
ISO 26262 目標
表1
方法
モデリングおよびコーデ
ィングのガイドラインに
よって言及されるトピック
表
SQO レベ なし/部分的/
すべて
ル必須
1a 低複雑性の実施
SQO-1
すべて
1b 言語サブセットの使用
SQO-5
すべて
1c 厳密な型指定の実施
SQO-5
すべて
1d 防衛的実装手法の使用
SQO-5
部分的
1e 確立されているデザイン法則の使用
SQO-5
部分的
1f 明瞭なグラフィカル表現の使用
なし
なし
1g スタイル ガイドの使用
なし
なし
SQO-6
すべて
1h 命名規則の使用
ソフトウェア アーキテクチャ デザインの表記
なし
なし
表 3
ソフトウェア アーキテクチャ デザインの法則
なし
なし
表 4
ソフトウェア アーキテクチャ レベルでのエラー検出の機構
なし
なし
表 5
ソフトウェア アーキテクチャ レベルでのエラー処理の機構
なし
なし
表 6
ソフトウェア アーキテクチャ デザインの検証のための方法
なし
なし
表 7
ソフトウェア ユニット デザインの表記
なし
なし
表 9
ソフトウェア ユニット デザ
インと実装の検証
のための方法
表 8
ソフトウェア ユニット デザイ
ンと実装のためのデザイン法則
表 2
1a
サブプログラムおよび関数での 1 つの入口点と
1 つの出口点
SQO-1
部分的
1b
動的オブジェクトまたは変数なし、あるいは作成中の
オンライン テスト
SQO-1
すべて
1c
変数の初期化
SQO-6
部分的
1d
変数名の複数使用なし
SQO-1
部分的
1e
グローバル変数を避けるまたはその使用を正当化します
SQO-6
すべて
1f
ポインターの制限使用
SQO-6
すべて
1g
暗黙の型変換なし
SQO-5
部分的
1h
隠蔽されたデータ フローまたはコントロール フローなし
SQO-1
すべて
1i
無条件ジャンプなし
SQO-1
すべて
1j
リカージョンなし
SQO-1
部分的
1a ウォークスルー
SQO-4
部分的
1b 検査
SQO-6
部分的
なし
なし
1d 形式検証
SQO-6
部分的
1e 制御フロー解析
SQO-1
部分的
SQO-6
すべて
1g 静的コード解析
SQO-5
すべて
1h 意味論的コード解析
SQO-6
すべて
1c セミフォーマルな検証
1f
データ フロー解析
表 10
ソフトウェア ユニット テストの方法
なし
なし
表 11
ソフトウェア ユニット テストのテスト ケースを引き出す方法
なし
なし
表 12
ソフトウェア ユニット レベルの構造的カバレッジ メトリクス
なし
なし
表 13
ソフトウェア統合テストの方法
なし
なし
表 14
ソフトウェア統合テストのテスト ケースを引き出す方法
なし
なし
表 15
ソフトウェア統合レベルの構造的カバレッジ メトリクス
なし
なし
表 16
ソフトウェア安全性要件検証を実施するためのテスト環境
なし
なし
ソース コードのソフトウェア品質目標 - バージョン 3.0
27/28 ページ
ソフトウェア品質目標
COTS: 商用オフザシェルフ（Commercial, off-the-shelf）は、既製品で販売やリースまたはラ
イセンスを一般に提供できるようにしたソフトウェアまたはハードウェア（一般的には
技術製品またはコンピューター製品）に対する用語です。これらは社内開発または特定
の政府調達開発の対義語として使用されます。COTS の使用は、調達および保守におい
て大幅な金銭の節約になることがあるので、多くの政府および企業のプログラムで管理
されています。ただし、COTS ソフトウェア仕様は外部のソースによって書かれている
ので、政府機関はこれらの製品に慎重です。なぜなら将来に製品に変更が加えられるこ
とに対して管理できないという恐れがあるからです。
製造会社： 自社の製品内に別の会社によって製作されたコンポーネントを使用、または別の
会社の製品を自社ブランドで販売する会社。これは、製品を保証するために必要な連邦
政府ライセンスされたエンティティを構成します。政府指令レベルの責任に法的に拘束
されない「アフターマーケット」とは異なります。
HIS:
Hersteller Inititiative Software。ドイツ自動車製造会社（Audi、BMW グループ、
MaimlerChrysler、Porshe、Volkswagen）によるイニシアティブで、その目的は ECU の
ネットワーク、プロセス成熟度の開発、ソフトウェア テスト、ソフトウェア ツール、
およびプログラミングに対する標準ソフトウェア モジュールの分野内での合意による
標準の策定にあります。
HIS は、ソフトウェアの評価で使用されるソフトウェア メトリクスの基本的なセットを
指定します。
http://portal.automotive-his.de/images/pdf/SoftwareTest/his-sc-metriken.1.3.1_e.pdf を参照。
サプライヤー： 自動車部品製造会社
SQO: ソフトウェア品質目標
SQR: ソフトウェア品質要件
ソース コードのソフトウェア品質目標 - バージョン 3.0
28/28 ページ
© Copyright 2024 Paperzz
