この規格ページの目次
4
X 0134 : 1999 (ISO/IEC 15026 : 1998)
この規格では,記号を使用していない。略語に関しては,適切な場合に限って,初出の際に,その箇所
にその全綴りを示す。
5. ソフトウェアに課せられたリスク抑制の完全性水準
5.1 この規格の利用法
独立したリスク抑制の完全性保証機関という概念は,この規格の適切な利用のための基本となる。完全
性保証機関は,完全性要求事項の準拠性を認定する責任をもつ人,又は組織とする。設計責任機関と完全
性保証機関との間の折衝でなされた意思決定は,文書化される。折衝でなされる意思決定には,関連する
リスク次元,使用される特定の完全性水準,各水準を割り当てるための特定の基準,及び設計記述中にあ
る特定の構成方式機構に対して認められる効用度合い,及び特定の完全性水準を割り当てた結果として生
ずるソフトウェアへの要求事項の決定が含まれる。
この規格では,包括的なシステム工学プロセスとして区別してプロセスが示されているが,しかし,こ
の規格では,これらのプロセスをシステム工学プロセスに統合することを妨げるものではない。これらの
プロセスをどのように実現するかに関係なく,この規格の遵守は,その中の要求事項のすべてを満たすこ
とを要求する。
5.2は,リスク抑制の完全性水準,及びソフトウェア完全性要求事項を決定するプロセスの概要について
述べる。
6.,7.及び8.は,このプロセスをさらに詳しく定義し,このプロセスに課せられた要求事項を規定する。
5.2 概要
図1は,システム完全性水準,ソフトウェア完全性水準,及びその要求事項の決定に必要なプロセスの
概要を示す。表1は,システム完全性水準の決定,ソフトウェア完全性水準の決定,及びその要求事項の
決定,という三つの主なプロセスのそれぞれの入力及び出力を示す。
――――― [JIS X 0134 pdf 6] ―――――
5
X 0134 : 1999 (ISO/IEC 15026 : 1998)
図1 ソフトウェア完全性水準の決定及び適用のプロセス概要
――――― [JIS X 0134 pdf 7] ―――――
6
X 0134 : 1999 (ISO/IEC 15026 : 1998)
表1 入力及び出力
プロセス 入力 出力
システム − 関連する各リスク次元 − リスクのリスト
完全性水準の決 − システムに関する情報 − 危険な兆候のリスト
定 − 環境に関する情報 − 危険な兆候の許容発生頻度又は生起確
− システムの構成方式(入手可能な場合) 率
− 引き金事象のリスト
− 引き金事象の発生頻度又は生起確率
− システム完全性水準
ソフトウェア − システム完全性水準 − サブシステム・ソフトウェアの完全性
完全性水準の決 − サブシステム・ソフトウェアの構成方式 水準
定 − 完全性水準の低減を認めるのに信用に
− 危険な兆候のリストと,各々の危険な兆候ごと
に : 値する構成方式機構
− 危険な兆候の許容発生頻度又は生起確率
− 危険な兆候を生じるかもしれない引き金事
象
− 各引き金事象の推定発生頻度又は生起確率
ソフトウェア − サブシステム・ソフトウェアの完全性水準 − ソフトウェア完全性要求事項
完全性要求事項
の決定
この規格では,完全性水準決定に対するリスクに基づく取組みを用いる。したがって,対応するシステ
ム完全性水準を決定する最初の段階は,リスク分析の実施を含む。IEC 60300-3-9 “Risk Analysis of
Technological Systems” (工業的システムのリスク分析)は,リスク分析実施の手引きを提供する。リスク
分析を実施するシステムに関連するシステム,その環境及びリスク次元についての十分な情報は,あらか
じめ収集しておかなければならない。分析されるリスクは,設計責任機関及び完全性保証機関の合意のも
とに,安全性,経済性,セキュリティなどの,すべての関連するリスク次元を網羅するのがよい。
リスク分析で識別されたすべてのリスクは,そのリスクが許容できるかどうかを決定するために,評価
されなければならない。一度,システムの設計記述が許容できるリスクを保持しているかについて分析さ
れ評価された後,システム完全性水準が割り当てられる。システム完全性水準は,システムに関連する最
悪ケースのリスクを反映する。
当該システムに含まれるソフトウェア完全性水準は,最初の段階では,システム完全性水準と同じもの
が割り当てられる。システムの設計記述は,構成方式機構がシステムの設計記述の中にあるかどうかを分
析し,システム完全性水準より低い水準をソフトウェアに割り当てることの妥当性を決定するとよい。
システムは,一つ以上の構成部品からなる統合された複合物とする。構成部品は,単独のソフトウェア
でも,単独のハードウェアでもよいし,また,さらに分解した構成部品からなるサブシステムでもよい。
最初,システムのすべてのソフトウェア構成部品に,そのシステム完全性水準が割り当てられる。ソフト
ウェア完全性水準の決定には,システム完全性水準より低い水準をサブシステムに割り当てられるかどう
かを決定するための,システムの構成方式の分析が含まれる。このプロセスは,各サブシステム中にある
すべてのソフトウェア構成部品に完全性水準を割り当てるために,ソフトウェアだけしか含まないサブシ
ステム完全性水準が決まるまで,又は,ソフトウェアを含んでいるサブシステム完全性水準が,設計責任
機関及び完全性保証機関によって認められるまで,再帰的に適用可能である。
構成方式を分析している間に,以前に行ったリスク分析の期間では決定できなかった新たな危険な兆候
やリスクが識別されることもありうる。これには,新たなリスク情報を考慮に入れたリスク分析の反復が
要求されるだろう。
――――― [JIS X 0134 pdf 8] ―――――
7
X 0134 : 1999 (ISO/IEC 15026 : 1998)
ソフトウェア完全性水準は,緩和機能の提供の信頼度,又は危険な兆候をもたらすかもしれない故障の
発生頻度に対して要求された上限値のいずれかを指示する。ソフトウェアの故障は厳密には系統的故障で
あるので,ソフトウェア完全性水準は,緩和機能が高信頼に提供されるか,又は危険な兆候を引き起こす
ような故障は生じないかのいずれかの要求された信頼等級を表示する。
ソフトウェア完全性水準の決定及び適用は,リスク管理の包括的なプロセスの一部である。リスク管理
は,システム又はソフトウェア製品の全プロセスを通して実施され,種々の詳細水準の設計記述が意思決
定されたときに,すなわち設計記述の進行に応じて繰り返し実施されてもよい。図1に,包括的なシステ
ム工学プロセスと,リスク分析,リスク評価及びリスク制御からなるリスク管理との関係を示す。
システムの設計記述がリスク排除・軽減 (reduce) 可能な能力を組み込むために修正された場合,システ
ム又はソフトウェア完全性水準を割り当てる際に新たな危険な兆候が識別された場合,又は,システムの
設計記述が許容できるリスクを満たせない場合に,リスク管理を反復することができる。
ソフトウェア完全性水準は,ソフトウェアに対してシステムリスクに関連する役割にふさわしい信頼等
級を獲得して保持させるために,ソフトウェア及びそのソフトウェア工学プロセスに当てはめるべき要求
事項が何であるかを識別することによって,ソフトウェア構成部品に関連するリスクをどの程度制御する
かを決定するのに使用する。これらの要求事項は,ソフトウェア完全性要求事項と呼ばれている。
6. システム完全性水準の決定
システム完全性水準は,そのシステムに関係するリスクの許容水準に対応する。システムの故障が危険
な兆候を引き起こすということ,又は危険な兆候を引き起こす状況下において引き金事象の影響を緩和す
る機能をシステム機能中に備えるために,システムはリスクと関連づけられる。システム完全性水準は,
次の手順で決定しなければならない。
a) リスク分析によってそのシステムに関係するリスク水準を決定する。リスク分析は,入手可能な情報
を用いて,危険な兆候の識別又はそれら危険な兆候に関連するリスク見積りを行うプロセスである。
b) リスク評価は,各リスクの許容度合いを判定 (judgment) するプロセスである。リスク分析及びリスク
評価の出力によっては,リスクの排除又は軽減のためにシステムの設計記述の変更が行われる可能性
がある。
c) 許容可能なリスクをもつシステムの設計記述が識別されると,システム完全性水準の割当てが行われ
る。実際に選択を行う完全性水準の正確な等級の数又は水準間の評価基準は,設計責任機関と完全性
保証機関との間で折衝がなされなければならない。
6.1 リスク分析
リスク分析は,次の三つの基本的な質問に答えるように行われなければならない。
(危険な兆候の識別によって)悪くなる可能性のあるものは何か。
(頻度分析によって)それがどの程度発生するのか。
(影響分析によって)その影響はどの程度なのか。
これらの分析によって,各リスクが計算できる。それぞれ識別されたリスクに対するリスク分析の出力
は,次のすべてとする :
a) 適切な用語を用いたリスクの記述
b) そのリスクに関連した危険な兆候
c) それぞれの危険な兆候に関連した引き金事象
d) 引き金事象の推定発生頻度
――――― [JIS X 0134 pdf 9] ―――――
8
X 0134 : 1999 (ISO/IEC 15026 : 1998)
リスク分析から得られるリスクの記述は,リスクが許容可能かどうかを決定するリスク評価プロセスに
用いられる。リスク分析から得られるすべての出力は,システムに課せられたリスク抑制の完全性水準決
定プロセス,及びそのシステムのソフトウェア部品に要求きれる完全性水準を決めるソフトウェア完全性
水準決定プロセスに用いられる。
リスク分析に有用な指針としてIEC 60300-3-9 “Risk Analysis of Technological Systems” がある。IEC
60300-3-9の中で安全に関する術語として用いられている“hazard(危険)”及び“harm(危害)”という用
語は,それぞれ,“threat(危険な兆候)”及び“adverse effect(不利な結末)”に置き換える。
リスク分析は,安全性,経済性,セキュリティなどの多様なリスクの次元を網羅することができる。網
羅される対象のリスク次元は,設計責任機関及び完全性保証機関によって決定されなければならない。
6.1.1 危険な兆候の識別
システムに関連した危険な兆候は,その危険な兆候につながり得る引き金事象とともに識別するのがよ
い。危険な兆候は次に示すようにシステムと関連して存在する。システムの故障が危険な兆候に結びつく
場合,指定されたとおりのシステム運用が危険な兆候になる場合,又は危険な兆候になるような環境下で
引き金事象の緩和機能をシステムが遂行する場合。明確には認識されない危険な兆候を識別するため,特
別の状況を網羅する手法を用い,そして文書化するのがよい(IEC 60300-3-9参照)。システムの中で用い
られているそれぞれの技術に固有の故障モードを確実に考慮に入れるために,危険な兆候の識別作業は,
(入手可能ならば)システムの構成方式を考慮しなければならない。
6.1.2 頻度分析
頻度分析は,危険な兆候の識別によって決定された各引き金事象のゆう(尤)度(likelihood)を見積もるため
に用いる。システムの故障が引き金事象となる場合には,頻度分析は,故障発生のゆう(尤)度を見積もる
のではなく,代わりに故障の発生頻度の上限値を決定する。それは,許容されるリスク目標と矛盾せず,
かつ,実用上実現可能なものである。
事象の発生頻度は,FTA(障害の木分析)又はETA(イベントツリー分析)(IEC 60300-3-9参照)のよ
うな技法によって積み上げた適切な過去のデータ,又は,専門家の判定を用いて見積もられなければなら
ない。
システム完全性水準決定プロセスの間になされる頻度分析は,システムをブラックボックスとして扱う
ものとし,システムの構成方式を考慮に入れてはならない。システムの構成方式は,ソフトウェア完全性
水準決定プロセスにおいて考慮されるものである。頻度分析によって決定された事象発生頻度は,量的尺
度,又は,頻繁 (Frequent),可能性大 (Probable),時折 (Occasional),希有 (Remote),可能性極小 (Improbable),
皆無 (Incredible) などの発生頻度の等級を示す質的尺度によって表現してもよい。
頻度分析では,他の事象と組み合わさったり,事象の時系列の一部となったときにだけ危険な兆候とな
る引き金事象もあるということを考慮に入れておかなければならない。
6.1.3 影響分析
影響分析は,万一,引き金事象が発生した場合の危険な兆候の厳しさ度合い (severity) を見積もるため
に用いられる。引き金事象の影響を緩和するすべての手段を識別するのがよい。それぞれの危険な兆候は,
例えば,破局的 (Catastrophic),重大 (Major),厳しい (Severe),及び軽微 (Minor) といった種々の影響の
厳しさ度合いを示す一連の分類の中から一つの影響分類に結びつけられなければならない。
6.1.4 リスク計算
それぞれの危険な兆候に関連したリスクは,引き金事象の発生頻度と引き金事象の影響の厳しさ度合い
とを関連づけるリスクマトリックスを使って計算される。リスクマトリックスは,発生頻度と影響の厳し
――――― [JIS X 0134 pdf 10] ―――――
次のページ PDF 11
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
- ソフトウェアライフサイクルプロセス