第三者検証における保証の見える化 ～独立検証及び妥当性確認（IV&V）における事例紹介～ 2015年7月17日 SEC高信頼化技術適用事例セミナー 国立研究開発法人 宇宙航空研究開発機構 研究開発部門 第三研究ユニット 神戸 大輔 2015/7/17 Ⓒ Copyright 2015 JAXA All rights reserved 1 目次 1. ソフトウェア品質とは 2. 宇宙機ソフトウェアと第三者検証（IV&V） 3. IV&V活動における保証の見える化 2015/7/17 Ⓒ Copyright 2015 JAXA All rights reserved 2 第1部 ソフトウェア品質とは 2015/7/17 Ⓒ Copyright 2015 JAXA All rights reserved 3 品質とソフトウェアの特徴 ■品質とは 「品質とは誰かにとっての価値である」 （Quality Software Management:ジェラルド・ワインバーグ著） 「品質」は、概念であるため、何かしらの視点（指標等）で 「可視化」することが必要である。 ■ソフトウェアの特徴（ハードウェアと比較して） ・特徴1： ソフトウェアは見えない ・特徴2： ソフトウェアは自由度が高い ・特徴3： ソフトウェアは人への依存が高い 2015/7/17 Ⓒ Copyright 2015 JAXA All rights reserved 4 ソフトウェアの特徴から品質確保 ・特徴1： ソフトウェアは見えない → テスト結果から、ソフトウェアが期待通り動作することを確認 ・特徴2： ソフトウェアは自由度が高い 例：ソースコードの変更は容易にできる等 → ソフトウェアへ期待することを要求として明記 プログラムの振る舞いや構造を明記 ・特徴3： ソフトウェアは人への依存が高い → 開発方法やプロセスを決め、個人スキルへの依存を低下 2015/7/17 Ⓒ Copyright 2015 JAXA All rights reserved 5 ソフトウェア品質の概念 ソフトウェアの内部的な特徴（仕様書 等の文書も含む） 例：モジュール性や要求追跡性等 ソフトウェア品質モデル （ISO9126より） プロセス 品質 影響 依存 設計／開発の方法や手順 2015/7/17 利用者の必要性に合致するか ソフトウェア 内部 品質 影響 ソフトウェア製品の効果 外部 品質 依存 影響 利用時 品質 依存 一般的に言われるソフトウェアの「品質」 例：テスト実行結果にバグがない Ⓒ Copyright 2015 JAXA All rights reserved 6 第2部 宇宙機ソフトウェアと第三者検証（IV&V） 2015/7/17 Ⓒ Copyright 2015 JAXA All rights reserved 7 宇宙機ソフトウェアの特徴 • ソフトウェアの誤動作により多大な損失が発生しうる。 もしロケットの打ち上げが失敗した場合、ロケットや人工衛星等の損失だけでなく、 環境の汚染や人命・財産の喪失にもつながりうる。 • システムの動作環境が過酷。 太陽電池の電力で駆動するが、日陰のため発電できない時間帯が存在する。 地球との通信が常に可能とは限らない。 放射線によるメモリ化けが発生する。 • 部品交換はできない。 基本的にハードウェアは予備（冗長系）を搭載している。 • 製品開発が単発。 • 実際の運用環境での試験ができない。 ロケット 2015/7/17 人工衛星 宇宙ステーション Ⓒ Copyright 2015 JAXA All rights reserved 地上管制システム 8 IV&V活動（ソフトウェア第三者検証）とは IV&V（Independent Verification and Validation）活動とは、 開発組織とは、技術的、組織的、資金的に独立して行う、品質を確認する活動のこと。 システム開発 成果物 システム 要件定義書 システム要件定義 ソフトウェア開発 通常の開発 ソフトウェア要件定義 ソフトウェア 要件定義書 ソフトウェア方式設計 ソフトウェア 設計仕様書 担当による 検証や ソフトウェアIV&V 検証 妥当性確認 評価 評価 評価 評価 評価 評価 評価 評価 作成 ソフトウェア構築 ソースコード ソフトウェア ユニットテスト ソフトウェア 試験仕様書 適格性確認テスト システム 試験仕様書 基本方針 リスク*の 視点から 評価 妥当性確認 評価 (*)リスクとはソフトウェア開発上の問題となりうる点 2015/7/17 Ⓒ Copyright 2015 JAXA All rights reserved 9 IV&V活動の目的 システムが致命的な状況（衛星喪失、ミッション喪失）に 陥る可能性（リスク）を低減させる。 → ステークホルダー（発注元）にソフトウェアが「安心」であることを示す。 3つの問い： ソフトウェアは、意図どおりに正しく振る舞うか？ Will the system software do what it is supposed to do? ソフトウェアは、意図しない振る舞いをしないか？ Will the system software do what it is not supposed to do? ソフトウェアは、不都合な事態に期待どおり振る舞うか？ Will the system software respond as expected under adverse conditions? 2015/7/17 Ⓒ Copyright 2015 JAXA All rights reserved 10 ソフトウェア品質におけるJAXA IV&V活動の範囲 ソフトウェア品質モデル （ISO9126より） プロセス 品質 影響 影響 内部 品質 依存 依存 SW実行時の品質 （例：テスト実行結果） 利用時 品質 利用時の品質に 合致するか 品質 定義 要件定義 SW適格性確認テスト 方式設計 開発担当の検証 （V&V） テスト 詳細設計 構築 2015/7/17 影響 依存 SW内部特徴の品質 （例：モジュール性、 追跡可能性） 開発手順や方法 発注元 外部 品質 SW結合テスト 意図通り設計されている ことを確認するテスト （製品保証） SW単体テスト Ⓒ Copyright 2015 JAXA All rights reserved 11 ソフトウェア品質におけるJAXA IV&V活動の範囲 JAXA IV&V活動の領域 ソフトウェア品質モデル （ISO9126より） プロセス 品質 影響 影響 内部 品質 依存 依存 第三者評価（IV&V) 「リスク」の視点で 論理的な検証 （検証説明責任の確保） 2015/7/17 利用時 品質 SW実行時の品質 （例：テスト実行結果） 利用時の品質に 合致するか 品質 定義 要件定義 検証説明責任 第3者（IV&V） 影響 依存 SW内部特徴の品質 （例：モジュール性、 追跡可能性） 開発手順や方法 発注元 外部 品質 論理 検証 SW適格性確認テスト 方式設計 開発担当の検証 （V&V） テスト 詳細設計 構築 SW結合テスト 意図通り設計されている ことを確認するテスト （製品保証） SW単体テスト Ⓒ Copyright 2015 JAXA All rights reserved 12 JAXA IV&V活動における価値創出 要点1： ステークホルダー（発注元）に説明責任を果たす。 ・開発担当が行う「テスト」との違いを説明する。 ・IV&Vは「バグ（外部品質）」に対して有効、という誤解を防ぐ。 JAXA IV&V活動の領域 発注元 品質 定義 要件定義 検証説明責任 第3者（IV&V） 論理 検証 SW適格性確認テスト 方式設計 テスト 詳細設計 構築 SW結合テスト SW単体テスト 要点2： 開発担当のレビューと異なる視点をもつ。 ・ソフトウェア開発上のどんな「リスク」が確認できたのか。 ・開発担当が作成した情報をそのまま鵜呑みしない。 2015/7/17 Ⓒ Copyright 2015 JAXA All rights reserved 13 JAXA IV&V活動における課題 ■課題 ■対策 • ステークホルダーに対する検証の説明責任 が果たせておらず、IV&Vの価値が伝わって いない。 • ステークホルダーに対して、IV&Vが確認した 範囲と根拠を示す必要がある。 • IV&Vの知見の蓄積と活用がされておらず、 開発担当の検証（V&V）に対するIV&Vの 強み・独自性が出せていない。 • IV&V活動の強み・独自性を出すための知見を 識別して、蓄積する必要がある。 • IV&Vエンジニアの入れ替わりが激しく、 組織としてIV&Vの品質を維持できていない。 • 経験の浅いIV&Vエンジニアでも、一定レベルの 品質でIV&V活動を実施できる仕組みを作る必要 がある。 「アシュアランスケース」をIV&V活動に導入し、 “保証の見える化“を実施 2015/7/17 Ⓒ Copyright 2015 JAXA All rights reserved 14 第3部 IV&V活動における保証の見える化 2015/7/17 Ⓒ Copyright 2015 JAXA All rights reserved 15 アシュアランスケースとは ■アシュアランスケースとは システムが保証すること（想定された状況下で動作する）を 議論によって構造化されたドキュメントで表現する方法 ※アシュアランス（保証）をケース（論拠）する。 基本効果 可視化する 見えないソフトウェア品質や サービスを要求元と 議論する 合意することに向いている 合意する 2015/7/17 Ⓒ Copyright 2015 JAXA All rights reserved 16 トゥールミンロジックとGSN GSN(Goal Structuring Notation) ＝ ゴール構造表記法 トゥールミンロジック ＝ 論証の組み立て方 主張 意見 考え 主張（ゴール） コンテキスト 論拠・理由 下位主張 論証において、ある事実の真偽を 判定する根拠となる事柄。 証拠（エビデンス） 事実・根拠 論拠（判断・推論）など を成り立たせるよりどころ。 行動などの正当性を支える事実。 2015/7/17 戦略 ■GSNの効果 • 階層化された複雑な議論を可視化し、 主張の曖昧さや抜け漏れを防ぐ。 • 第三者への説明しやすさを高める。 Ⓒ Copyright 2015 JAXA All rights reserved 17 IV&V活動版のアシュアランスケースとは（1/2） IV&V活動（サービス）が、ソフトウェアに「リスク（不具合要因）」がないことを 説明（保証）するために、「アシュアランスケース」を活用している。 説明先 主張 説明元 IV&V実施組織 開発プロジェクト ソフトウェアリスク がないこと 保証対象： ソフトウェア製品 ＋成果物 2015/7/17 証拠：エビデンス （IV&V活動の分析結果） Ⓒ Copyright 2015 JAXA All rights reserved 18 IV&V活動版のアシュアランスケースとは（2/2） 記法として、GSN（Goal Structuring Notation）を応用 （ゴール） システムとソフトウェアの状態遷移の 齟齬により想定外の状態に陥らない （戦略） 遷移条件に着目する 遷移条件に誤りがない 運用シナリオで規定 された異常処理に 範囲を限定する ・・・ IV&Vとして保証したいこと ＝ 発注元と合意 「目的（ゴール）」を達成するため に必要な論理（視点） 遷移条件の抜けがない 異常時の 運用シナリオに 着目する 運用シナリオにおける異常時の 状態遷移の遷移条件が、 ソフトウェア要求と整合している 評価できる「目的（ゴール）」 まで分解 分析作業の結果 ＝ 目的を達成している根拠 運用シナリオとソフトウェア要求 の整合性分析表 2015/7/17 Ⓒ Copyright 2015 JAXA All rights reserved 19 IV&V活動版アシュアランスケースのイメージ IV&V活動 開発プロジェクト リスク提示 システム要求 ゴール （保証したいこと） データ蓄積 （GSN形式） ソフトウェア要求 提供 ソフトウェア設計 コーディング 検証計画作成 コンテキスト 不具合分析 SW開発成果物 IV&V ソフトウェア 開発成果物 ソフトウェア試験 システム分析 リスク分析 戦略 評価作業 エビデンス ソフトウェア開発企業 2015/7/17 Ⓒ Copyright 2015 JAXA All rights reserved 20 IV&V活動版アシュアランスケースの具体例（1/6） 【コンテキスト】 開発成果物情報 2015/7/17 【エビデンス】 評価結果 （への参照） 【ゴール】 リスク 【戦略】 ゴール達成に必要な 下位目標を洗い出す 観点 【下位目標】 評価項目 Ⓒ Copyright 2015 JAXA All rights reserved 21 IV&V活動版アシュアランスケースの具体例（2/6） 【コンテキスト】 開発成果物情報 【ゴール】 リスク ＜＜トップゴール＞＞ 以下で識別された「リスク」 ・リスク分析での不具合分析 ・システム分析でのシステム特性分析 2015/7/17 【エビデンス】 評価結果 （への参照） 【戦略】 ゴール達成に必要な 下位目標を洗い出す 観点 【下位目標】 GSNのゴールは「達成したいこと」のため、ゴールとしては 評価項目 「リスクが十分に軽減されていること」という表現になる。 Ⓒ Copyright 2015 JAXA All rights reserved 22 IV&V活動版アシュアランスケースの具体例（3/6） 【コンテキスト】 IVVケース ＜＜最下層ゴール＞＞ 「評価項目」。以下の2点が明確になっている。 （検証戦略）の例 開発成果物情報 ・評価対象：評価の範囲。何を評価するか。 ・評価観点：評価の方法。どのように評価するか。 2015/7/17 【エビデンス】 評価結果 （への参照） 【ゴール】 リスク 【戦略】 ゴール達成に必要な 下位目標を洗い出す 観点 【下位目標】 評価項目 Ⓒ Copyright 2015 JAXA All rights reserved 23 IV&V活動版アシュアランスケースの具体例（4/6） 「リスク」から「評価項目」を段階的に導出 していくときの、考え方。 【コンテキスト】 （作成時の留意点） 開発仕様情報 ・戦略と上のゴール、下のゴールが 論理的につながっている ・下位のゴールの粒度がそろっている ・MECE感がある 2015/7/17 【エビデンス】 評価結果 （への参照） 【ゴール】 リスク 【戦略】 ゴール達成に必要な 下位目標を洗い出す 観点 【下位目標】 評価項目 Ⓒ Copyright 2015 JAXA All rights reserved 24 IV&V活動版アシュアランスケースの具体例（5/6） 【コンテキスト】 開発成果物情報 【ゴール】 リスク 評価結果にはIDを振って、 一意に管理できるようにする。 2015/7/17 【エビデンス】 評価結果 （への参照） 【戦略】 ゴール達成に必要な 下位目標を洗い出す 観点 【下位目標】 評価項目 Ⓒ Copyright 2015 JAXA All rights reserved 25 IV&V活動版アシュアランスケースの具体例（6/6） 【コンテキスト】 【コンテキスト】 開発成果物情 開発成果物情報 報 2015/7/17 【エビデンス】 評価結果 （への参照） 【ゴール】 リスク 【戦略】 ゴール達成に必要な ゴールで表現している内容を 下位目標を洗い出す 観点 開発成果物の情報から具体化する。 【下位目標】 評価項目 Ⓒ Copyright 2015 JAXA All rights reserved 26 GSN形式成果物の課題 課題1 • 「GSN」は表現する形式（記法）であるため、 具体的に何を記述するのか不明である。 課題2 • 「GSN」は、ツリー型の構造図なので、 末端ノードが増えすぎてしまう。 課題3 • 「説明責任を果たす」だけが目的となると エンジニアに新たな負荷を強いてしまう。 2015/7/17 Ⓒ Copyright 2015 JAXA All rights reserved 27 課題1： 何を記述したらいいのかわからない。 対策1-1 IV&Vプロセス（抜粋） 各プロセスの目的に 合わせてGSNを作成 目的の例 1つのケース（GSN）を限定 作成や議論できる作業量へ 成果物 システムやソフトウェアの情報 リスク抽出（RK) IV&Vが確認する「リスク」を 合意 GSN リスク導出経緯 リスク 検証戦略（VSC) 評価作業（RV～TV） システムやソフトウェアの 特徴から「評価観点（戦略）」 を説明 凡例 開発情報 検証 戦略 評価項目 ※作業成果物を作成 検証結果（AR） 「リスクがないこと」を 作業結果から論理的に説明 検証 結果 作業結果 不具合分析（ANA） 2015/7/17 不具合発生時の説明 不具合情報 Ⓒ Copyright 2015 JAXA All rights reserved 作成 部分 28 課題1： 何を記述したらいいのかわからない。 対策1-2 IV&Vプロセス（抜粋） リスク抽出（RK) 各プロセスの目的に 合わせてGSNを作成 ※作業成果物を作成 検証結果（AR） 不具合分析（ANA） 2015/7/17 • IV&V実施組織内で ケースの品質をレビュー 役割を定義 IV&Vが確認する 「リスク」を合意 IVVリーダー 開発プロジェクト 視点 定義 視点 評価作業（RV～TV） 目的に合わせて各ケース （GSN）の基準を規定 目的 成果物 検証戦略（VSC) • リスク導出経緯 基準 リスク 項目 リスク分析者 レビュー構造の定義 ■レビュー基準の例 ・記法に準拠しているか ・V&Vとの差別化はされているか ・IV&Vのコンセプトに合致しているか リスク導出経緯のレビュー項目例 ■記法の準拠 ・IV&V実施方針をコンテキストとして反映しているか。 ・最下層のゴール（リスク）がエビデンスと対応しているか。 ■開発担当による検証（V&V）との差別化 ・過去のIV&V活動結果を反映しているか。 ・独自に不具合分析した結果を反映しているか。 ・システムや開発特性を考慮してリスク定義しているか。 ■IV&Vのコンセプトへの合致 ・導出されたリスクは、影響度や発生頻度が高いか。 Ⓒ Copyright 2015 JAXA All rights reserved 29 IV&V活動版アシュアランスケース（検証戦略） システムや C0-a： ・対象システムは、リアルタイム性 が求められている。 （システム分析結果） 30 G0：処理の遅延によりソフトウェア の振る舞いに悪影響を及ぼさない ソフトウェアの特性 を検証の前提とした C0-b： ・非同期処理がタスクとして実装 （設計書より） ・処理はX秒以内に出力する （要求仕様書より） S0：自タスクへの影響（実行時間）と、 他タスクへの影響（機能）に分けて 確認する G1：処理負荷が最大となる場合 において、規定時間内に処理が 完了する C1： ・入力データは、Aデータ ・ファイル処理がある ・異常、割り込みが発生する （設計書より） G1.1：過剰な数(チャネルなど）の 入力データを処理する場合に、 規定時間内に処理が完了する。 2015/7/17 ・・・・ 懸念事項による S1：処理の遅延要因に分けて 確認する G1.2：過剰な数のファイルを処理 する場合に、規定時間内に処理 が完了する。 Ⓒ Copyright 2015 JAXA All rights reserved 戦略の展開 G1.3：異常（SW及びHW）が発生 した場合に、規定時間内に処理 が完了する。 30 30 課題2： 「GSN」は、ツリー型の構造図なので末端ノードが増え過ぎる。 G0:各運用フェーズにおいて 各サブシステムは、 ミッションを達成できる S0:運用フェーズごとに確認する G1:運用フェーズＸ S1:サブシステムごと に確認する G1.1: サブシス テムＡ 2015/7/17 G1.2: サブシス テムB G2:運用フェーズＹ G3:運用フェーズＺ S3:サブシステムごと に確認する S2:サブシステムごと に確認する G1.3: サブシス テムC G2.1: サブシス テムＡ G2.2: サブシス テムB G2.3: サブシス テムC 【問題点】 構成要素を網羅しようとしており、GSNで表現する効果が薄い。 （同じ戦略の繰り返しになってしまっている） Ⓒ Copyright 2015 JAXA All rights reserved G3.1: サブシス テムＡ 31 課題2： 「GSN」は、ツリー型の構造図なので、末端ノードが増え過ぎる 対策2： 分析方法を「コンテキスト」として表現し、「検証」としての論理を 中心に「可視化」した。 G0:各運用フェーズにおいて、 各サブシステムは、 ミッションを達成できる システム分析結果 重要機能表 (ID:aaaa-999) S0:重要機能ごとに確認する G1.1: 重要機能1 G1.2: 重要機能2 コンテキストにより外部 資料を参照する。 議論要素のない分解を GSNで表現せず、 シンプルにする。 2015/7/17 G1.3: 重要機能3 G1.4: 重要機能4 G1.5: 重要機能5 システム分析結果 重要機能表（ID:aaaa-999） 運用フェーズ Ｘ 運用フェーズ Ｙ 運用フェーズ Ｚ サブシステムＡ 重要機能１ 重要機能２ 重要機能３ － サブシステムＢ － － 重要機能４ サブシステムＣ － 重要機能５ － Ⓒ Copyright 2015 JAXA All rights reserved 32 課題3： 「説明責任を果たす」だけが目的となるとエンジニアに新たな 負荷が発生する。 ゴール GSNの特徴 エンジニアへの効果 ①：前提と考えを分離 困った内容を相談 ※論点の局所化 コンテキスト 戦略 ②：全体像の把握 サブゴール エビデンス 2015/7/17 他の人の作業を活用 サブゴール エビデンス ③：背景情報の伝達 Ⓒ Copyright 2015 JAXA All rights reserved 過去資産の活用 33 GSN活用のポイント ■GSN作成のポイント ・記法重視ではなく、業務上の意義や目的に合っているか、よく確認する。 例： IV&V活動としては、評価の「観点や対象」を限定することが重要であるため、 「機能毎、工程毎に確認する」といった戦略は、有効ではない。 ・GSNに求めることは、可視化により議論を活性化させること。 可視化によって不完全な箇所が明示されることも成果の一つ。 ・前提（コンテキスト）を如何に設定するか、によってGSNの有効性が大きく左右される。 （コンテキスト＞戦略＞ゴール） ■GSN導入のための促進方法 ・用語の定義や関係性を統一していく。 （概念をモデル化して認識を統一する） ・GSNで表現する内容を減らす仕組みを導入する。 （コンテキストをうまく活用する） ・最も効果的となる箇所に限定して議論の場を設ける。 （GSNの全ての戦略を順番に見ていく、というやり方は避ける） ・一度作成したGSNはフル活用する。 （計画の合意 → 作業時の参照 → 結果の提示 → データ蓄積） 2015/7/17 Ⓒ Copyright 2015 JAXA All rights reserved 34 IV&V活動の課題に対する効果 • ステークホルダー（発注元）への説明力の向上 → 開発担当が行う検証と異なる、IV&V独自の評価内容が伝わり、 より効果的にIV&V活動を行うことができる。 IV&Vの需要向上 → ステークホルダーからの新たな要望に応えられる。 • IV&V活動の強み・独自性を出すための知見の可視化 → リスクベース検証に必要な知見が具体化され、不具合情報や IV&Vの価値向上 過去のIV&V活動の結果を具体的に活用できるようになった。 • IV&V活動の品質確保 → 計画時に検証内容が具体化され、エンジニアの能力に IV&Vの品質確保 検証結果が左右されなくなった。 → 難易度が高い業務に、IV&V熟練エンジニアを投入する等の 分業体制が確立した。 2015/7/17 Ⓒ Copyright 2015 JAXA All rights reserved 35 IV&V活動版アシュアランスケースの導入効果 作業結果 検証の論理構造の 可視化 過去データの活用 （不具合、IV&V結果） 直接効果 議論の活性化 知見の具体化 ステークホルダー 理解促進 波及効果 技術移転 の促進 分業体制 の確立 エンジニアの モチベーション 向上 技術研究データ の蓄積 ステークホルダー 視点の獲得 2015/7/17 Ⓒ Copyright 2015 JAXA All rights reserved 36 IV&V活動版アシュアランスケースの課題 2015/7/17 活用 • 年間100件以上のケースが蓄積される。 • 各ケースへのアクセス精度と速度を高める 仕組みが必要である。 品質 • より多くの人がケースを作成する。 • 基本検証戦略等のベースラインが必要である。 表現 • より多くのステークホルダーへ説明する機会が 増える。 • 説明目的に合わせた「ビュー」が必要である。 Ⓒ Copyright 2015 JAXA All rights reserved 37 まとめ • ソフトウェア品質とJAXAにおけるソフトウェア第三者検証活動 （IV&V）のご紹介をした。 • IV&V活動では、アシュアランスケースを活用して“保証の見える 化”を行うことで、より活動の価値が向上すること、また、その活 用方法をご紹介した。 ソフトウェア第三者検証活動 （IV&V：Independent Verification and Validation） については、「IV&Vガイドブック」をご覧ください。 （無償配布中！） お問い合わせ先：IVV_INFO@jaxa.jp 2015/7/17 Ⓒ Copyright 2015 JAXA All rights reserved 38
© Copyright 2024 Paperzz
