リスクシナリオに繋がるコンテキスト情報を抽出するレビューメタモデルの提案

Review Meta Model to Identify Contexts Leading to Risk Scenarios

国立研究開発法人 宇宙航空研究開発機構

研究開発部門 第三研究ユニット

○梅田浩貴 波平晃佑 植田泰士 片平真史

名古屋大学 大学院情報学研究科 森崎 修司

e-mail：umeda.hiroki@jaxa.jp

ソフトウェア品質シンポジウム2019

目次

背景説明（前提知識等）

サイバーフィジカルシステム

クリティカルソフトウェア

ソフトウェア品質モデル（利用時品質：リスク回避性）

コンテキストと分析方法

提案手法の概要

リスクシナリオ設計手法

リスクシナリオレビュー手法

提案手法の有効性確認結果

有効性確認の条件と結果

まとめ

2ソフトウェア品質シンポジウム2019

本発表の概要

3

CPS（サイバーフィジカルシステム）やクリティカルソフトウェアの特性を活かしたリスクシナリオの設計手法及びレビュー技法の提案

提案①： 3つのビュー（構造、ツリー、時系列）によるリスクシナリオの作成方法

提案②： コンテキスト境界（システム制約やSWの前提）から仕様外を抽出

提案③： ビューのモデリングルール特性を活かしたレビュー項目の導出

（１） 提案手法は、物理と計算プロセスを融合したリスクシナリオが作成可能

（２） 提案手法は、 SW仕様外だが想定するリスクシナリオを作成可能。

（３） 提案手法は、「リスクシナリオ」に対し有効なレビューを実施できる。

結論

ソフトウェア品質シンポジウム2019

4

出典：三菱総合研究所

サイバーフィジカルシステム（CPS）とは

物理空間

仮想空間

物理事象a

データ

ネットワーク

アルゴリズム

センシング アクチュエーション

物理事象b

リアルタイムフィードバック

・物理的な時間経過（過渡）

・外部環境との積極的な相互作用

・構成要素の柔軟な変更

CPSの特徴（M2Mとの違い）

CPSイメージ図

ソフトウェア品質シンポジウム2019

サイバーフィジカルシステムとしての宇宙機

5

衛星本体 センサー アクチュエータ

自律制御ソフトウェア

・物理的な時間経過→ 運動量、光、電磁気、化学等の物理事象

・外部環境との積極的な相互作用→ 太陽風、放射線等の外乱から自律制御

・構成要素の柔軟な変更→ 環境と状態に合わせた機器の選択

基地局やネットワーク（通信制約あり）

化学反応

電磁気力

光検出

運動量検出

ソフトウェア品質シンポジウム2019

6

・クリティカルシステムとは、失敗したときの人的、経済的、社会的損害が重大なため、非常に高い保証が求められるシステム。

・クリティカルシステムに組み込まれて上記要求の主要な部分を担うソフトウェア

・予見できない使われ方（故障なし）でも問題がない（＝事故にならない）高いロバスト性※1が求められる。

クリティカルソフトウェアとは

※①：ロバスト性とは、アイテムが無効な入力又はストレスとなる環境条件で、正しく機能を遂行できる度合い、ある系が応力や環境の変化といった外乱の影響によって変化することを阻止する内的な仕組み、または性質（頑強性、強靭性、堅牢性、強さなど）のこと。(JIS-Z8115:2000 信頼性用語)

ソフトウェア品質シンポジウム2019

ロバスト性が必要な理由（事故事例）

故障はどこにもなかったが・・・ここで制御ソフトウェアが減速用エンジンを停止 → 事故

なぜ？

着陸機が、パラシュートの展開機構を広げるときセンサが着陸間近を示す様な信号を出力。ソフトウェアが着陸と認識し、エンジンを停止。

なぜ？

• End-to-End試験の不足• ソフトウェアの仕様定義のミス Touch down検知ロジック（着陸直前に動く機能）

が働くまでは、センサの値を無視する様に設計すべきだった・・・

ソフトウェア仕様定義として、どんな環境で使用する、又は使用してはいけないのか（制約）を分析すべきだった。

Mars Polar Landerの事故

7ソフトウェア品質シンポジウム2019

利用時の品質（ISO/IEC 25012）

有効性effectiveness

有効性

効率性efficiency

効率性

満足性satisfaction

実用性

信用性

快感性

快適性

リスク回避性freedom from risk

経済リスク緩和性

健康・安全リスク緩和性

環境リスク緩和性

利用状況網羅性context coverage

利用状況安全性

柔軟性

CPS特性

クリティカルSW特性

物理と計算の融合

リスク保証

■品質測定量・仕様外シナリオ想定度

＝ 仕様外のリスクシナリオを考慮している件数

計測指標：システム及びSW特性とSW品質モデル

IPA.つながる世界のソフトウェア品質ガイド.2015,208p より8ソフトウェア品質シンポジウム2019

9

コンテキストとは

システム・SWコンテキスト

システムSW

システム・SW境界

コンテキスト境界

引用：要求開発の基礎知識: 要求プロセスと技法入門 著者: 山本 修一郎

■システム・SW境界（点線）・要求分析後に明確になり、「仕様」となる。

■コンテキスト境界・動作前提や制約（暗黙含む）

・システム稼働後にも変化

■システム・SWコンテキスト・ステークホルダ・運用中のシステム・プロセス（技術的、物理的、ビジネス的）・文書（法制度、標準）などがある。

■ソフトウェアのコンテキスト（一般）同じ処理や記述でも状況に応じて動作が異なる場合に、その選択基準となる判断材料や条件などを指している。

ソフトウェア品質シンポジウム2019

乗客

フロアセンサー

システムオペレータ

モータ制御装置

重量・振動センサーエレベータ

の制御用ソフトウエア

環境行き先階の指示

行き先の表示

フロア情報

重量・振動情報

到着の案内

システムの制御

(急)停止の指示

上昇・下降の制御

システム要求

ハードウエア要求

ビジネス要求

ソフトウエア要求

コンテキストダイアグラムの例

物理と計算の融合

CPS特性・物理的な時間経過

・外部環境への積極的作用

・構成要素の柔軟な変変更

・動的なコンテキスト・構成要素が同じコンテキストの共有

コンテキスト分析方法の例

コンテキスト分析技法の要件

10ソフトウェア品質シンポジウム2019

11

OOAJSD

領域分割

プロブレムフレーム

精造化インタビュー

認知技法

アブダクション

KAOS

GBRAM

ゴール

シナリオ

クレーム分析

ストーリーテリング

プロトタイピング

ロールプレイ

SSM 民俗学

文脈的技法

シナリオベース領域分割

ゴール指向ブレーンストーミング

ユースケース

ロジカルシンキング

閉じている(Closed)

空いている(Open)

動的

(Dynamic)静的

(Static)

i*

MSC

KJ法ブレーン

ストーミング

ガイドワード（5W1H、HAZOP）

出展：要求工学：現実と仮想をつなぐために,妻木 俊彦 コンピュータソフトウェア2012年29 巻2号 p.2_43-2_64

参考：コンテキスト分析方法の種類

GSN

ESD（イベントシーケンス図）

構造図

発表者追記

製品特性から手法へ要件概要

12

システム（CPS）特性 クリティカルSW特性

コンテキスト分析手法の要件

物理と計算の融合 リスク保証

手法背景

提案手法

文脈知識循環法（JCTXT法※1）によるリスクシナリオ作成及びレビュー技法（3つのビュー）

・手法は、動的なコンテキストを分析できること。（時間経過含む）

・手法は、システム構成要素が共有すべきコンテキストを抽出できること。

・手法は、コンテキスト境界を分析できること。

手法要件

構造ビュー 時系列ビューツリービュー

コンテキスト抽出 コンテキスト組合せ

※1：JAXA’s ConexT-based knowledge eXtraction and Thinking methods

13

クリティカルソフトウェア特性と提案手法の基本構造1

HWSW

HWSW

状態A イベント 状態B制約

下位

上位

下位

制約

構造ビュー ツリービュー： 時系列ビュー

SW

コンテキスト境界

SW境界

クリティカルソフトウェアとしてのコンテキスト分析の考え方

SW

コンテキスト境界

SW境界

SWコンテクスト SWコンテクスト

SW

コンテキスト境界

SW境界

SWコンテクスト

■提案手法の基本構造1

HW・運用制約等を分析する。

システム・SWの構成要素や状態を抽出する。

システム・SWの時間経過で制約違反となるか確認。

情報の入出力関係 システム・SW構成要素（状態）の同位包含関係

システム・SW動作の時間経過

ソフトウェア品質シンポジウム2019

クリティカルソフトウェア特性と提案手法の基本構造2

装置レベル、ボードレベル

サブシステム・コンポーネントレベル

システムレベル

• 部品・回路レベルの冗長化• 装置自己故障診断及び回復• ソフトウエア故障診断及び回復• ソフトウエア耐性設計

（信号の冗長化、有効性チェック等）

• 装置・系（計算機、センサー）レベルの冗長化

• 多数決システム• 故障診断及び回復• 安全モード自動移行

• 宇宙機システムの詳細診断• 地上などからの処理支援（自動、人間）• 人間の介入

宇宙機の階層的な対故障設計

SW

システムコンテキスト境界

コンポーネントコンテキスト境界

SWコンテキスト境界

SW境界（＝仕様）

コンテキスト上のイメージ図

14

コンテキスト境界の多層化

ソフトウェア品質シンポジウム2019

15

SW

システムコンテキスト境界A

コンポーネントコンテキスト境界B

SWコンテキスト境界C

SW境界（＝仕様）

コンテキスト上のイメージ図

A B C

Bの制約 Cの制約

Cの入力前提

提案手法の基本構造2（構造ビュー）

クリティカルソフトウェア特性と提案手法の基本構造2

Aの制約

C（ソフトウェア）を保証するためには

A、B、Cは、一致した（矛盾しない）制約

を元に動作する必要がある。

ソフトウェア品質シンポジウム2019

16

クリティカルソフトウェア特性と提案手法の基本構造3

SW

システムコンテキスト境界

コンポーネントコンテキスト境界

SWコンテキスト境界

SW境界（＝仕様）

システム状態

コンポーネント・SW状態

広げる

絞る

仕様外・想定外

仕様内

仕様内

各層のコンテキスト境界の識別方法

コンテキスト上のイメージ図他からの視点

ソフトウェア品質シンポジウム2019

クリティカルソフトウェア特性と提案手法の基本構造3

下位

上位

下位

入力制約

MECE出力影響

提案手法の基本構造3（ツリービュー）

・ガイドワード（HAZOPや5W1H等）を適用・不具合が発生した要素とその状態組合せ

分類 入力タイミング 入力域 振る舞い データ完全性

ガイドワード 早過ぎる 遅すぎる 否定 量的

増加量的減少 逆 他 類

似 一部 前 後

システム状態

コンポーネント・SW状態

広げる

絞る

仕様外・想定外

仕様内

仕様内

制約と影響

ガイドワードと組合せ

同位関係

包含関係

17

他からの視点

MECEによる分類（抜け漏れ重複ない）

MECE：Mutually Exclusive and Collectively Exhaustive

18

CPS特性1：物理と計算プロセスの融合と提案手法

＜共有コンテキストの検証＞

外部環境システム状態

SW状態入出力

システム状態B

センサー入力

アクチュエータ動作

＜各構成要素が共有するコンテキストの識別＞

ツリービューで、上位下位の「包含関係」が確保されている場合、各要素のコンテキスト（境界）は、一致している（必要がある）。

※トップから末端までのルート上にあるコンテキストの組合せを「継承」と呼ぶ。

物理プロセス 計算プロセス 物理プロセス

各構成要素が共有するコンテキスト（の組合せ）は時間経過を含めたシナリオを作成できるか、確認。

コンポ状態

システム状態

制約

SW状態

制約

制約

継承

ルート毎（トップから末端）にシナリオ形成

■提案手法（JCTXT）の基本構造4（ツリーと時系列の関係）

19

具体

抽象

具体

特徴

MECE 懸念

CPS特性２：構成要素の変更と提案手法

角速度

センサー入力

星や太陽の位置

特徴：外部環境に依存しない位置推定方法

※省略懸念：地球と重なった時

位置推定できない。

時間積分

センサー入力

絶対座標参照方法

特徴：初期の動作時から高精度の位置推定が必要

※省略懸念：フィルタで

補正できない

抽象要素A

要素B状態A1

状態A2

要素A影響

状態B1

状態B2

要素A1 要素A2

要素A1の特徴

要素A2の特徴

■提案手法（JCTXT）の基本構造5（構成要素の集約）

コンテキストが変わることで、考えるべき対象が変わる例

変化があるか

影響があるか

状態を変化させるか

過去か現在の類似要素との違い

ソフトウェア品質シンポジウム2019

20

CPS特性３：外部環境との相互作用

CPSシステムSW 外部環境

システム状態

SWによる補正

入力値誤り

システム状態とSW認識の不一致

外部環境（シーンY）入力遅延

※どのタイミング（状態の組合せ等）で発生するかは、ツリービューのコンテキストで分析。ツリービュー上で抽象化による集約によって、シナリオ爆発を防ぐ。

外部環境（シーンX）

・同一タイミングで、外部環境の変化と入力誤りが発生した内容を表現する。

・外部環境とシステムやSWの認識が不一致となるシナリオを表現する。

誤った動作

正常動作

利用シーンX

利用シーンY状態A

物理プロセス計算プロセス物理プロセス 並列関係（同時イベント）

■提案手法（JCTXT）の基本構造6

提案手法の概要

21

要素A

要素B

情報入出力関係

構造ビュー

時系列ビュー

ツリービュー

【コンテキスト情報】・制約・影響

同位包含関係

要素A

要素B

状態X1

状態Y1

状態X2

状態Y2

時系列関係

同タイミング情報の入出力関係

要素

具体要素 具体要素

視点

コンテキスト情報

・共有コンテキストの検証（時間経過）

・コンテキスト境界の識別（ガイドワードと影響）

・抽象化と特徴（差分）による集約・コンテキストを共有する要素を識別（ツリー上の継承を元に）

・個別コンテキスト抽出（制約）

・階層的なコンテキスト境界（SWの保証前提）

要素C

ソフトウェア品質シンポジウム2019

提案手法の適用工程

22

①：システムの制約Cと状態S、逸脱状態Dを定義する。システム状態Sから逸脱状態Dとなる、システムレベルシナリオLsを作成する。

②：システムレベルシナリオLsにコンポーネントOのハードウェアや運用等の制約Cを識別する。

③：システム目的Gを達成するため、コンポーネントOに搭載するSWモジュールMとその入出力を定義する。

④：コンポーネントOとSWモジュールMのコンテキスト（入力前提）を用いて、SWモジュールの入力や状態の組合せを分析する。

⑤：SWモジュールの入力や状態の組合せ結果を

用いて、各コンテキストの組合せを考慮した、システムLs、コンポーネントLc、SWモジュールLmを含めたリスクシナリオを作成する。

内容 定式

システムの目的

システムの目的を達成する状態

システムの制約

システムの逸脱状態

システムの外部環境

システムレベルシナリオ

コンポーネントレベルシナリオ

SWモジュールレベルシナリオ

コンポーネント

SWモジュール

①：システムの異常状態を定義

②：運用やHWの制約を識別

③：制約に関連するSW情報を定義

④：SWのコンテキスト（入力前提や制約）を分析

⑤：リスクシナリオを作成

定式表現

事例を参照する際、添え字でトレース

ソフトウェア品質シンポジウム2019

事例説明（前提情報）

23

工程①：システムの異常状態を定義

システム状態

システム逸脱状態

衛星本体

基地局やネットワーク

センサー アクチュエータ

自律制御ソフトウェア

化学反応

電磁気力

光検出

運動量検出

事例説明（構造ビュー）

24

工程②：運用やHWの制約を識別 保証対象

※機器等の特性から発生する一般的な制約を列挙

運動量検出

光検出

電磁気作用

ソフトウェア品質シンポジウム2019

25

𝑆𝑆2：姿勢変更

𝑂𝑂3：計算機 他コンポ

𝑂𝑂𝑐𝑐41：回転速度に上限制約違反を持ちびく

モジュール毎

𝑂𝑂1：センサーA（星位置）𝑂𝑂𝑐𝑐11：太陽や地球により星が見えない𝑂𝑂2：センサーB（角速度）𝑂𝑂𝑐𝑐21：時間積分による誤差蓄積

外部環境時に入出力があるコンポーネント毎

𝐶𝐶1:回転速度が一定以下

𝐷𝐷1:姿勢不安定

𝐷𝐷2：電力確保不可

𝑆𝑆2:姿勢変更

𝐶𝐶2：不可視期間

𝑀𝑀11：補正フィルタ

𝑀𝑀12：位置推定

𝑚𝑚𝑖𝑖1:センサーAの値（なし）𝑚𝑚𝑖𝑖2:センサーBの値（過大）

𝑀𝑀12(𝑚𝑚𝑖𝑖1)：ノイズ除去後の値

M𝑐𝑐11：一定期間、データを取得できないと推定ができなくなる。

𝑚𝑚𝑠𝑠1：初期化状態

リスクシナリオ1

外部環境

制約違反を導くSWモジュール状態毎

事例説明（ツリービュー）

工程③：制約に関連するSW情報を定義※上位と下位が同位包含関係

工程④：SWのコンテキスト（入力前提や制約）を分析

全ての入力ではなく、下記を満たす入力にガイドワードを適用

・システムやセンサーの状態から発生する入力（ツリー上の上位層）

・補正フィルタへの入力※一定期間、入力なしとなる

システムコンテキスト境界

コンポーネントコンテキスト境界

上位全てのコンテキストを満たした「シナリオ」となる。

ソフトウェア品質シンポジウム2019

センサーAにノイズが発生

運用による補正フィルタがリセットされる。

センサーAの値が来ない

初期化された補正フィルタでセンサーBの値が誤差大（過大）

センサーAからの

値が復帰するが、センサーBと比較

結果で棄却

アクチュエータが

誤作動し、回転速度が高くなる。

最終的に姿勢が不安定になる。

時間経過（物理事象）を考慮したリスクシナリオ

ツリー上のコンテキストの継承でリスクシナリオの源泉を作成。

センサーAからの値が復帰時、過去の処理結果から、AとBのどちらの値が信用できるか、判断する。

あるべきシナリオ

工程⑤：リスクシナリオを作成

事例説明（時系列ビュー）

定義されていた仕様

26

異なる物理プロセス

ソフトウェア品質シンポジウム2019

27

提案手法適用時の課題

■手法特性異なる特性（入出力、同位包含、時間経過等）のビューが、コンテキストで連接されている。

■課題：レビューに前提知識（JCTXT）が必要

28

3つのビューを用いたレビュー項目の導出アプローチ

課題： 3つのビュー（JCTXT）の成果物に対してレビュー難易度が高い。

アプローチ： 3つのビューは、設計対象物によってルーリングが異なるためメタレビュー項目を作成。（本発表では、SW異常設計）

メタレビュー導出観点

メタレビュー項目 レビュー項目

3つのビュー（ JCTXT ）

個別業務特性・SW異常設計・リスクベーステスト設計・非定常運用設計・FMEA等

19項目 SW異常設計は28項目

ソフトウェア品質シンポジウム2019

29

ビューX ビューY要素AX

要素BX

トレース

逆トレース

・要素単体

・要素間関係

・ビュー間関係

ステップ1：レビュー項目の導出方法と事例1

メタレビュー導出観点

メタレビュー項目

3つのビュー（JCTXT）

＋

要素関係 メタレビュー項目情報の入出力関係 コンテキスト情報（特徴）を考慮し、該当の要素は、他

の要素に影響を与える/受けるか。包含関係 上位下位要素は、包含関係となっているか。同位関係 要素の同位関係となっているか。継承関係 最上位から最下層の要素にあるコンテキスト情報を

組み合わせて、1つのシナリオを作成できるか。順序関係 シナリオにある状態やイベントは、

その順序（入出力と時間推移）が正しいか。同タイミング関係 要素間で共有するイベントが抜けていないか。分岐関係 シナリオの分岐が不足していないか。

ソフトウェア品質シンポジウム2019

30

メタレビュー項目 レビュー項目＋

個別業務特性・SW異常設計

過去のモデリングミス

要素関係 メタレビュー項目 レビュー項目情報の入出力関係

コンテキスト情報（特徴）を考慮し、該当の要素は、他の要素に影響を与える/受けるか。

・該当アイテムの特徴によって、与えている影響は明確か。

包含関係 上位下位要素は、包含関係となっているか。

・下位のアイテムは、上位アイテムより、具体的になっているか。

同位関係

要素の同位関係となっているか。

・「詳細化・具体化視点」が2項対立やMECEであるか。・「詳細化・具体化視点」がアイテム名と一致していないか。・「詳細化・具体化視点」が「～毎」となり、且つ、下位アイテムの「特徴」がない展開になっていないか。・「詳細化・具体化視点」が「～毎」となっている場合、上位と下位のアイテムで、解析対象が変わっていないか。

継承関係 最上位から最下層の要素にあるコンテキスト情報を組み合わせて、1つのシナリオを作成できるか。

・最下層のアイテムは、最上位アイテムまでに付属する「特徴情報」を考慮しているか。（キーワードがあるか）

ステップ2：レビュー項目の導出方法と事例2

ソフトウェア品質シンポジウム2019

31

提案手法の有効性評価

設計者 レビューア

評価ステップ

1：方法論なし

2：提案手法

SW要求仕様の定義※自然言語 又は、

UML（ユースケース等）

提案手法（JCTXT）でリスクシナリオを作成

3つのビューをレビュー

提案手法（レビュー項目）を参照して3つのビューをレビュー

計測指標 ・リスクシナリオ数・仕様外シナリオ想定度が増加するか。

・リスクシナリオ数・仕様外シナリオ想定度・工数が増加するか。

評価実験1 評価実験2

ソフトウェア品質シンポジウム2019

実験条件

32

No 企業 SW種別 機能 シナリオ作成者 レビューア 補足説明（機能の特徴等）

1-1 企業A 組み込み 機能A1 同一人物 A1

1-2 企業A 組み込み 機能A2 同一人物 A1

1-3 企業A 組み込み 機能A3 異なる人物 A2

1-4 企業A 組み込み 機能A4 同一人物 A1 安全化時のみ動作

2-1 企業B エンタープライズ 機能B1 同一人物 B1

2-2 企業B エンタープライズ 機能B2 同一人物 B1

3-1 企業C エンタープライズ 機能C 同一人物 C1、C2複数の他システムへ指示を出す大規模な複合機能

・実際に開発しているSWへ手法を適用

・システム仕様やSW仕様が確定後に実施

・ミッションクリティカルな機能を選定

・提案手法によるリスクシナリオ作成者は「設計者」

レビューアは類似SW開発の経験あり。

※No1-3のみ設計者ではない。

ソフトウェア品質シンポジウム2019

33

評価実験1：従来手法と提案手法（JCTXT）の比較

リスクシナリオ数の増加率 仕様外シナリオ想定度の増加率

従来（仕様書にある自然言語やUML）に対するシナリオ増加率

％％

ソフトウェア品質シンポジウム2019

0

20

40

60

80

100

No1-1 No1-2 No1-3 No1-4 No2-1 No2-2 No3-1

％

0

20

40

60

80

100

120

No1-1 No1-2 No1-3 No1-4 No2-1 No2-2 No3-1

リスクシナリオ数

仕様外シナリオ想定度

シナリオ数

評価実験1：提案手法（J-ConEXT）によるリスクシナリオ数

リスクシナリオに対する仕様外シナリオの抽出割合

故障・異常・非定常・例外発生時

システムの状況に応じて

SWがどのくらいの動作するか

表現している。

（＝ リスクシナリオ数）

仕様にないリスクシナリオ数は

平均68％の抽出率である

34

01020304050607080

手法なし 手法あり35

0

20

40

60

80

100

120

140

No1-1 No1-2 No1-3 No1-4 No2-1 No2-2 No3-1 No3-2

レビュー前 方法なし 方法あり

0

20

40

60

80

100

120

No1-1 No1-2 No1-3 No1-4 No2-1 No2-2 No3-1 No3-2

レビュー前 方法なし 方法あり

01020304050607080

手法なし 手法あり

評価実験2：レビューによるリスクシナリオ数の増加

リスクシナリオ数 仕様外シナリオ想定度シナリオ数 シナリオ数

提案手法は、

通常のレビュー後でも

さらにリスクシナリオ数を

増加させることができる。

％ ％

020406080

100120140

手法なし 手法あり

評価実験2：レビュー工数比較%

リスクシナリオ設計部は、支援ツールがある。

※EXCELのアドインツール問い合わせ先：umeda.hiroki@jaxa.jp

レビュー部はツールの支援なし

従来より、20％以上の工数増加している。

時間 評価実験1：1リスクシナリオの作成時間

0.0

0.5

1.0

1.5

2.0

2.5

No1-1 No1-2 No1-4 No2-2 No3-1

評価実験1と2における工数情報

36

まとめ

37

①： 複数の要素の並列な時間経過が重要となる設計対象※例：運用業務の設計

②： コンテキスト境界（前提や制約）が重要となる設計対象※本番環境で試験できない対象

③： 利用前提等の明確化や説明責任が必要な設計対象※例：ブラックボックスで内部の網羅検証が説明困難等

（１） 提案手法は、物理と計算プロセスを融合したリスクシナリオが作成可能

（２） 提案手法は、 SW仕様外だが想定するリスクシナリオを作成可能。

（３） 提案手法は、「リスクシナリオ」に対し有効なレビューを実施できる。

結論

応用可能性

※本手法を試行したい方の問い合わせ先： umeda.hiroki@jaxa.jp

ご清聴 ありがとうございました。

38ソフトウェア品質シンポジウム2019