この規格ページの目次
- 6.2 リスク評価
- 6.3 システム完全性水準の決定
- 7. ソフトウェア完全性水準の決定
- 7.1 ソフトウェア完全性水準の決定における前提条件
- 7.2 ソフトウェア完全性水準の低減
- 7.3 危険な兆候となる可能性のある故障を発生するソフトウェア完全性水準の低減
- 7.4 自己の故障によって緩和機能を提供できなくなるソフトウェアの完全性水準の低減
- 8. ソフトウェア完全性要求事項の決定
- 8.1 信頼等級
- 8.2 ソフトウェアの信頼等級を達成する手法
- 8.3 ソフトウェアの信頼等級及び完全性水準の関連
- JIS X 0134:1999の引用国際規格 ISO 一覧
- JIS X 0134:1999の国際規格 ICS 分類一覧
- JIS X 0134:1999の関連規格と引用規格一覧
9
X 0134 : 1999 (ISO/IEC 15026 : 1998)
さ度合いとの組合せの交点に,例えば,高いリスク,中程度のリスク,低いリスク,又は,微かな (Trivial)
リスクといったリスク階級を割り当てる。
表2 リスクマトリックスの例
発生頻度 発生頻度の指標 影響の厳しさ度合い
(件/年) 破局的 重大 厳しい 軽微
(Catastrophic)(Major) (Severe) (Minor)
頻度 (Frequent) >1 高い 高い 高い 中程度
可能性大 (Probable) 1−10-1 高い 高い 中程度 低い
時折 (Occasional) 10-1−10-2 高い 高い 低い 低い
希有 (Remote) 10-2−10-4 高い 高い 低い 低い
可能性極小 (Improbable)10-4−10-6 高い 中程度 低い 微かな
皆無 (Incredible) <10-6 中程度 中程度 微かな 微かな
表2にIEC 60300-3-9からとったリスクマトリックスの例を示す。
設計責任機関及び完全性保証機関は,リスク計算に使われるすべてのリスクマトリックスに合意しなけ
ればならない。リスクマトリックスの合意書としては,引き金事象発生頻度の適切な範囲(値域)の合意
書,影響分類及びそれらの定義の合意書,並びに発生頻度範囲と影響分類との各組合せに関連したリスク
階級の合意書が必要とする。
6.2 リスク評価
リスク分析プロセスよって計算された各リスクの許容度合いに対する判定は,設計責任機関及び完全性
保証機関によってなされなければならない。この判定は,分野別の監督機関によって制定された規制値を
考慮に入れて行われている分野もある。
6.3 システム完全性水準の決定
最初に割り当てられたシステム完全性水準は,そのシステムに関する危険な兆候のすべてに割り当てら
れた中で最も高いリスク階級に対応する。完全性水準の値は識別されたリスク階級の等級値に対応する。
表3は,システム完全性水準とリスク階級の対応の例を示す。
表3 システム完全性水準とリスク階級の対応
リスク階級 システム完全性水準
高い A
中程度 B
低い C
微かな D
この規格では,完全性水準の等級の数も,表示記号も規定しない。
7. ソフトウェア完全性水準の決定
ソフトウェア完全性水準は,構成部品としてソフトウェアを含むサブシステム,又は,ソフトウェア単
独で構成されているサブシステムに対してシステム完全性水準を配分 (allocation) したものである。サブ
システムに対するソフトウェア完全性水準は,最初,システムに課せられたリスク抑制の完全性水準と同
一とする。
この条件は,次に示す点を考慮に入れ,ソフトウェア完全性水準が下げられなければ,そのままとする。
a) システムの危険な兆候となるサブシステム故障の影響を緩和するシステムの構成方式機構
b) 緩和機能をもつ複数個のサブシステムの単一故障又は多重故障において,引き金事象を緩和する機能
をもつ冗長性を備えたシステムの構成方式機構
――――― [JIS X 0134 pdf 11] ―――――
10
X 0134 : 1999 (ISO/IEC 15026 : 1998)
c) 識別された引き金事象又はその緩和機能に関与するか否かに関する当該サブシステムの役割
7.1 ソフトウェア完全性水準の決定における前提条件
a) システムに課せられたリスク抑制の完全性水準がシステムに割り当てられていること。
b) サブシステムの役割及びそれらのインタフェースが識別できるように,システムの構成方式機構が十
分詳細に定義されていること。
c) 入力として次を含むこと。
− システム完全性水準
− 危険な兆候のリスト及びそれぞれの兆候に対する次の情報
− 危険な兆候に至る引き金事象
− 各引き金事象の同時発生頻度又は同時生起確率
各サブシステムの役割の決定,及びすべての緩和特性を識別するのに十分なシステム構成方式機構
の定義
d) 出力は,ソフトウェア完全性水準とすること。
7.2 ソフトウェア完全性水準の低減
ソフトウェア完全性水準の可能な低減を決定するために,次の段階が実施されなければならない。
a) システム全体を構成するサブシステムの集合を識別する。
b) サブシステムの故障が独自に,又は他のサブシステムの状態との組合せによって危険な兆候となるか
どうかを決定する。サブシステムの故障が単独で危険な兆候となる場合には,そのサブシステムに課
せられたリスク抑制の完全性水準は,システムと同じ水準に割り当てられる。サブシステムの故障が
他のサブシステムの状態と組み合わさったときだけ危険な兆候となる場合には,そのサブシステム完
全性水準は,7.3で規定される総合評価の結果しだいで低減されうる。7.3で規定される総合評価は必
す(須)ではなく,より低いサブシステム完全性水準が要望されるときにだけ実施するとよい。
c) サブシステムの故障が独自に,又は他のサブシステムの状態との組合せによって緩和機能が提供でき
るかどうかを決定する。サブシステムの故障が単独で緩和機能を提供できなくなる場合には,そのサ
ブシステム完全性水準は,システムと同じ水準に割り当てられる。サブシステムの故障が他のサブシ
ステムの状態と組み合わさったときだけ緩和機能が提供できなくなる場合には,そのサブシステム完
全性水準は,7.4で規定される総合評価の結果しだいで低減されうる。7.4で規定される総合評価は必
すではなく,より低いサブシステム完全性水準が要望されるときにだけ実施するとよい。
d) ソフトウェア構成部品をもつサブシステムで,その故障が危険な兆候に至らず,かつ,その機能があ
らゆるシステム事象に対する緩和に関連しないかどうかを決定する。そのようなソフトウェアには最
も低い完全性水準が割り当てられる。障害隔離は,ソフトウェアの故障が危険な兆候に至らないよう
にするために必要である。設計責任機関及び完全性保証機関は,十分な障害隔離を確実に行うために
構成方式機構の十分性に関して合意しなければならない。障害隔離が故障処理機構によってなされる
ならば,その仕組みに対してはシステムと同等なソフトウェアの完全性水準を割り当てる。
割り当てられたシステム完全性水準からソフトウェア完全性水準を低減するための構成方式機構がもた
らす効用度合いは,完全性保証機関及び設計責任機関によって規定され,合意されなければならない。
段階a)からd)に規定した手順は,ソフトウェアだけしか含まないすべてのサブシステムに対するリスク
抑制の完全性水準が決まるまで,又は,これらのサブシステム中にあるすべてのソフトウェア構成部品に
完全性水準を割り当てるためにソフトウェアを含んでいるサブシステム完全性水準が設計責任機関及び保
証機関によって認められるまで,再帰的に適用される。
――――― [JIS X 0134 pdf 12] ―――――
11
X 0134 : 1999 (ISO/IEC 15026 : 1998)
7.3 危険な兆候となる可能性のある故障を発生するソフトウェア完全性水準の低減
故障が危険な兆候になりうるシステムに対するシステム完全性水準は,許容リスク目標と矛盾しないシ
ステム故障発生頻度の上限値だけに基づいている。他のサブシステムの状態との組合せによってソフトウ
ェアの故障が危険な兆候となる場合,ソフトウェア故障発生頻度に対して,システムで使われているもの
より厳しくない値を割り当ててもよい。
頻度分析を用いてソフトウェア故障発生頻度に対し,許容リスク目標を満足する最も厳しくない上限値
を決定してもよいが,その際には,サブシステム間の依存関係を考慮に入れなければならない。より高い
ソフトウェア故障頻度の上限値が決定したら,リスク計算を繰り返し,リスク階級に対して変更があるか
どうか,又は,これに関連して低いソフトウェア完全性水準に対応するかを決定してもよい。
故障処理機構は,ソフトウェア故障を検出したり,それらが引き金事象になることを防ぐために使用す
る。これらのケースでは,故障が起こり,故障処理機構が有効に働かない場合に限って,ソフトウェア故
障が引き金事象となる。故障処理機構の例としては,次のものがある。
・ データの一貫性検査(ソフトウェア手段)
・ ハードウェアによる時限監視(ハードウェア手段)
・ 手動による回復(人手による手段)
冗長性は,冗長なサブシステムの間での共通モード故障が避けられているならば,故障が危険な兆候に
至るのを防止するために使用してもよい。冗長性をソフトウェア構成品の間で採用する場合は,ソフトウ
ェア多様性のような戦略が共通モード故障を避けるのに使われなければならない。ソフトウェアの多様性
がソフトウェア故障の発生頻度に対する上限値の厳しさ (stringency) を低減するために用いるときには,
ソフトウェアの多様性によって提供される効用度合い及び十分な多様性を何が組成するかの定義が,設計
責任機関及び完全性保証機関によって合意されなければならない。
7.4 自己の故障によって緩和機能を提供できなくなるソフトウェアの完全性水準の低減
サブシステムの故障が他のサブシステムの状態との組合せによって緩和機能を提供できなくなるなら,
そのソフトウェアの信頼度は,システムの緩和機能に要求されている信頼度よりも低くすることができる。
7.3で定義したのと同様に,頻度分析に使われる技法は,システムに要求されている緩和機能の信頼度から
そのソフトウェアに割り当てるべき低減の度合いを決定するのに使用することができる。
8. ソフトウェア完全性要求事項の決定
8.1 信頼等級
ソフトウェアに課せられたリスク抑制の完全性水準は,緩和機能の提供に対する要求された信頼度,又
は危険な兆候をもたらしうる故障の発生頻度に対する要求された上限値のいずれかとする。ソフトウェア
の故障は,厳密には系統的故障であるので,ソフトウェア完全性水準は,緩和機能が高信頼度で提供され
るか,又は危険な兆候を引き起こすような故障は生じないかのいずれかの,要求された信頼等級を表示す
る。要求事項を満たした場合,必要とする信頼等級をもたらすはずであるソフトウェア及びそのライフサ
イクルプロセスによって満たすべき要求事項は,ソフトウェア完全性要求事項と呼ばれる。
ソフトウェアで確証を得るための戦略として,次に示すものがある :
a) 誤りの混入を最小限にする技法の適用
b) 誤りの検出を最大限にする検証又は妥当性の確認技法の適用
c) ソフトウェアが提供する緩和機能が高信頼度で動作しているか,又は故障が規定された上限値以下の
発生頻度でしか発生しないことを運用履歴によって実証する。
――――― [JIS X 0134 pdf 13] ―――――
12
X 0134 : 1999 (ISO/IEC 15026 : 1998)
8.2 ソフトウェアの信頼等級を達成する手法
表4は,諸特性を達成する際に各種の信頼等級で達成するのに使われる可能性のあるソフトウェア工学
におけるアクティビティ,アクティビティの出力の特性,及び手法の幾つかの例を概要付きで示す。この
規格は,特定のソフトウェアライフサイクルの採用を定めることを意図していない。JIS X 0160で規定さ
れた他のライフサイクルプロセスも等しく適用可能である。
ソフトウェアの確証は,ソフトウェアが一定の期間において運用され,その運用履歴が既に存在するな
らば,運用履歴に対する総合評価によって達成されてもよい。運用履歴によって得られた信頼等級は,そ
のソフトウェアの複雑性,その運用履歴の成功及びシステム中のそのソフトウェアに対する意図された使
い方と実際の運用とが類似していることなどの要因に依存する。
8.3 ソフトウェアの信頼等級及び完全性水準の関連
この規格は,与えられたソフトウェア完全性水準に対して適切な信頼等級を達成するために必要な特定
の要求事項を規定するものではない。
設計責任機関及び完全性保証機関は,それぞれの完全性水準のソフトウェアにおいて必要な信頼等級を
達成するのに満たさなければならない諸要求事項について双方の合意をとらなければならない。
表4 プロセス,アクティビティ,特性,信頼等級
アクティビティ 特性 ソフトウェアにおいて個々の完全性水準 (IL) の
信頼等級を達成する手法
IL 手法
ソフトウェア要求分析
精度 1 構造化アプローチ
完備性 2 IL.1+準形式的記法
正しさ 3 IL.1+形式的記法
抽象度 4 IL.3+形式的証明
一貫性
検証性
ソフトウェア設計 要求事項への追跡可能性 1 構造化アプローチ
検証性 2 IL.1+準形式的記法
モジュール性 3 IL.1+形式的記法
抽象度 4 IL.3+形式的証明
ソフトウェア 設計記述への追跡可能性 1 構造化プログラミング
コーディング 2
プログラムの構造・構成の非あいまい性 IL.1+型制約言語
プログラム言語の標準 3 IL.2+言語の安全なサブセットに制限
保守性 4 IL.3+形式的証明
IL : Integrity Levels完全性水準
――――― [JIS X 0134 pdf 14] ―――――
13
X 0134 : 1999 (ISO/IEC 15026 : 1998)
国内SC7/WG9小委員会 構成表
氏名 所属
主査 松尾谷 徹 日本電気株式会社
幹事 鍛 治 勝 三 日本情報処理開発協会
落 合 利 章 三菱電器株式会社
解 良 和 郎 株式会社日立製作所
中 村 英 夫 日本大学
松 原 友 夫 コンサルタント
松 本 甲太郎 科学技術庁航空宇宙技術研究所
オブザーバ 安 保 洋 子 日本電気株式会社
オブザーバ 志 村 順 アルシスKK株式会社
原案作成委員会 構成表
氏名 所属
(主査) 松尾谷 徹 日本電気株式会社
(幹事) 鍛 治 勝 三 日本情報処理開発協会
落 合 利 章 三菱電機株式会社
解 良 和 郎 株式会社日立製作所
中 村 英 夫 日本大学
松 原 友 夫 コンサルタント
松 本 甲太郎 科学技術庁航空宇宙技術研究所
安 保 洋 子 日本電気株式会社
志 村 順 アルシスKKE株式会社
湯 原 孝 通商産業省工業技術院
(事務局) 徳 岡 靖 崇 財団法人日本規格協会
JIS X 0134:1999の引用国際規格 ISO 一覧
- ISO/IEC 15026:1998(IDT)
JIS X 0134:1999の国際規格 ICS 分類一覧
JIS X 0134:1999の関連規格と引用規格一覧
- 規格番号
- 規格名称
- JISX0001:1994
- 情報処理用語―基本用語
- JISX0020:1992
- 情報処理用語(システム開発)
- JISX0160:2012
- ソフトウェアライフサイクルプロセス
- JISX0160:2021
- ソフトウェアライフサイクルプロセス