(前NTTデータ フェロー システム科学研究所長)山本 修一郎
本稿では、保証ケース(Assurance case)をレビュする方法を、文献[1]に基づいて紹介する。保証ケースについては本連載[2]、保証ケースのためのリスク分析手法については前々回[3]紹介した。サービス保証ケース作成手法については前回[4]紹介した。
ところで、「アシュアランスケース」としないで「保証ケース」と表記している理由は、カナ漢字変換の時に、「亜種ランスケース」などと、筆者がタイプミスしやすいことと、「アシュアランス」の方が「保証」よりも、文字数が長くなるためである。それ以外に理由があるわけではない。気になる方は、保証ケースをアシュアランスケースと読み変えていただいて結構である。実際に、この連載でも最初は「アシュアランスケース」としていたものである。そういえばある講演を依頼された際に、「ソフトウェア・アシュアランス」について話しましょうかと提案したところ、「某基本ソフトウェア企業のサービスのことですね」といわれて驚いたことがある。「保証」にいろいろな意味があるように、「アシュアランス」にもいろんな意味がある。言葉の選択には難しいところがある。
保証ケースのレビュプロセス
Kellyは、表1に示すような4段階の保証ケースレビュ手法を提案している。
保証ケースレビュでは、まず、議論構造を理解し、次いで議論構造について構造面から問題がないことを確認する。さらに、議論状況について十分性とともに、議論の完全性を確認する。Kellyの段階的レビュ手法では、十分性と完全性の段階だけが反復するプロセスになっている。
以下では、Kellyの方法を説明しよう。
表1 保証ケースの段階的レビュプロセスの概要(クリックで拡大)
◆議論構造の理解
保証ケースのレビュでは、保証ケースで記述されている議論の内容を理解することから始める。保証ケースを構成している議論の構造を理解するために、まず議論の基本要素として、主張や前提条件、証跡を識別する。次いで、議論の構成要素間の関係を識別するために、主張や前提条件、証跡の相互関係を明らかにする。さらに、保証ケースが文章で記述されている場合には、GSN(Goal Structuring Notation)などの構造記法を用いて、議論構造を再表現する。
◆議論構造の検査
議論構造が理解できたら、次は議論構造の妥当性を検査する必要がある。議論構造が良くなければ主張を証跡によって保証できないからである。良くない議論構造として、議論構造に欠陥がある、議論が循環している、議論構造に抜けがあり不完全である、主張に対する証跡の役割が曖昧である、議論の構成要素間の結合関係に問題があるなどがある。
ここで議論の循環というのは、証跡が前提条件になっているような主張があることである。この場合、議論が堂々めぐりしてしまうことになる。
◆議論状況の十分性と完全性
保証ケースの議論を構造面から理解して検査できたら、次は意味面から保証ケースを確認する段階になる。意味的な妥当性を確認する場合、主張に対して証跡が十分であることと、主張を反証するような証跡がないことを検査することになる。主張に対して十分な証跡があることを議論状況の十分性ということにする。一方、主張に対する証跡による議論に反証がないことを議論状況の完全性という。主張と証跡に対して反証できる証跡が見つかった場合、対立する主張とその証跡を含めることによって完全性がより高くなるように、議論を再構成する必要がある。
議論状況の十分性の検査では、議論の構成要素に抜けがないことを検査するとともに、前提条件が必要ならコンテクスト情報を追加する。
◆議論の批判と反論
議論状況の完全性を検査するために、議論状況に対する反論を試みることで批判的に検査する必要がある。議論状況の批判では、まず演繹証明的議論と帰納推論的議論を識別する。ここで主張の真偽が確定できるような議論のことを演繹証明的議論という。これに対して、主張の真偽が確率的にしか決定できない不確定的な議論のことを帰納推論的議論という。
演繹証明的議論では真偽の妥当性を確認する。帰納推論的議論では結論に対する前提の十分性を確認する。
反復的レビュプロセス
Kellyの段階的レビュ手法では、段階1から段階2、段階3、段階4へと順番に進み、段階4から段階3へ戻り、段階3と段階4だけが反復するプロセスになっている。しかし、本当にそうだろうか?なぜ、段階4から段階1に戻ることはないのだろうか?もし段階4で結論が反駁される場合が発見されたら、それに対する対立主張と対立証跡が保証ケースの構造に追加されることになる。したがってもう一度、議論構造についても理解と検査が必要になるはずだ。このように考えると、図1のような反復的保証ケースレビュプロセスのほうが自然であると思われる。
以下では、第4段階の議論状況の理解について、議論の完全性の具体的な検査内容について説明する。議論状況の完全性として、証跡と主張の関係、証跡の監査、議論の妥当性に分けて述べる。
図1 保証ケースの反復的レビュプロセス(クリックで拡大)
保証ケースの証跡と主張の関係
保証ケースでは、証跡に基づいて結論としての主張が議論構造によって保証されることを確認する。Kellyは、証跡と主張との関係について表2に示すような6特性を提示している。すなわち、議論が網羅性、独立性、限定性、直接性、関連性、頑健性を持つ必要があるというのである。もし、議論がこれらの特性を持たないと、主張が反駁される可能性がある。以下では、これらの特性ごとに説明しよう。
続きは本誌でご覧頂けます。→本誌を購入する
ご購入のお申込みは電話(03-3507-0560)でも承っております。
- 60:要求とアーキテクチャ
- 61:要求と保守・運用
- 62:オープンソースソフトウェアと要求
- 63:要求工学のオープンな演習の試み
- 64:Web2.0と要求管理
- 65:ソフト製品開発の要求コミュニケーション
- 66:フィードバック型V字モデル
- 67:日本の要求定義の現状と要求工学への期待
- 68:活動理論と要求
- 69:ビジネスゴールと要求
- 緊急:今、なぜ第三者検証が必要か
- 71:BABOK2.0の知識構成
- 72:比較要求モデル論
- 73:第18回要求工学国際会議
- 74:クラウド時代の要求
- 75:運用要求定義
- 76:非機能要求とアーキテクチャ
- 77:バランス・スコアカードの本質
- 78:ゴール指向で考える競争戦略ストーリー
- 79:要求変化
- 80:物語指向要求記述
- 81:要求テンプレート
- 82:移行要求
- 83:要求抽出コミュニケーション
- 84:要求の構造化
- 85:アーキテクチャ設計のための要求定義
- 86:BABOKとREBOK
- 87:要求文の曖昧さの摘出法
- 88:システムとソフトウェアの保証ケースの動向
- 89:保証ケースのためのリスク分析手法
- 90:サービス保証ケース手法
- 91:保証ケースのレビュ手法
- 92:要求工学手法の再利用
- 93:SysML要求図をGSNと比較する
- 94:保証ケース作成上の落とし穴
- 95:ISO 26262に基づく安全性ケースの適用事例
- 96:大規模複雑なITシステムの要求
- 97:要求の創造
- 98:アーキテクチャと要求
- 99:保証ケース議論分解パターン
- 100:保証ケースの議論分解パターン[応用編]
- 101:要求発展型開発プロセスの事例
- 102:参照モデルに対する保証ケース
- 103:参SEMATの概要
- 104:参SEMATの活用
- 105:SEMATと保証ケース
- 106:Assure 2013の概要
- 107:要求の完全性
- 108:要求に基づくテストの十分性
- 109:システムの安全検証知識体系
- 110:機能要求の分類
- 111:IREB
- 112:IREB要求の抽出・確認・管理
- 113:IREB要求の文書化
- 114:安全要求の分析
- 115:Archimate 2.0のゴール指向要求
- 116:ゴール指向要求モデルの保証手法
- 117:要求テンプレートに基づく要求の作成手法
- 118:ビジネスゴールのテンプレート
- 119:持続可能性要求
- 120:操作性要求
- 121:安全性証跡の追跡性
- 122:要求仕様の保証性
- 123:システミグラムとドメインクラス図
- 124:機能的操作特性
- 125:セキュリティ要求管理
- 126:ソフトウェアプロダクトライン要求
- 127:システミグラムと安全分析
- 128:ITモダナイゼーションとITイノベーションにおける要求合意
- 129:ビジネスモデルに基づく要求
- 130:ビジネスゴール構造化記法
- 131:保証ケース導入上の課題
- 132:要求のまとめ方
- 133:要求整理学
- 134:要求分析手法の適切性
- 135:CROS法の適用例
- 136:保証ケース作成支援ツールの概要