ソフトウェア検証における見える化とは

～第3者による検証活動の事例紹介～

2015/6/10

宇宙航空研究開発機構 (JAXA)

第三研究ユニット

梅田 浩貴

宇宙システムの種類とソフトウェア

姿勢制御系、データ処理系、ミッション系、スタートラッカー／GPSRなどセンサー系など組込み系が中心

最近は書換可能のものもある

アセンブラ、C言語

再利用／シリーズ化

放射線の影響

管制システム等

安全性

C、JAVA言語

管制システム、マニュピュレータ、実験装置など膨大な数のソフトウエア

高い安全要求（2故障でも安全に！）

コマンド、データ、処理の独立性

システム構成にクルーが入る

Ada、C言語

宇宙ステーション

人工衛星 ロケット

航法誘導制御系等

高信頼性／多数決

アセンブラ、C言語

ハードリアルタイム

地上管制システム

2

目次

• ソフトウェアの検証とは

• アシュアランスケースの応用

• 「検証戦略」の可視化

3

下記の者が同じ目的のソフトウェアを作成した場合品質は同じになると思いますか？

・A：実験等で十分なプログラミング経験を有した学生

・B：業務目的でソフトウェア設計経験がある企業の技術者

その理由は、何が想定されますか？

4

問い

ソフトウェア検証とは・（一般用語）「検証」とは、実際に物事に当たって調べ、仮説などを証明すること。

・ソフトウェア開発における「検証」とは、ソフトウェア開発プロセスの各工程で作られるモデル（概念、数理、論理）がそれぞれ正しく変換されているかを確かめる作業

5

事象

中間モデル

コード

ソフトウェアで実現したい事象（ビジネス業務や機械の挙動など）

ユーザー要求から業務モデルなどの中間モデルを生成し、最終的に論理や計算などからなる抽象モデル（コード）に置き換える作業

プログラムの世界に変換していく

問題意識： 正しく変換されていることをどうやって確認したのか

6

開発モデル（V字モデル）と検証

システム適格性確認テスト

ソフトウェア適格性確認テスト

システム方式設計

ソフトウェア方式設計

ソフトウェア構築

検証

検証

検証

検証

検証

ソフトウェア要件定義

ユーザ要求

■妥当性確認と検証・検証とは、前工程の仕様に基づいて確認すること・妥当性とは、最終利用者の意図通りに動いているかどうかを確認すること

問題意識： 検証と妥当性を使い分けて効果的なレビューやテストはできているのか

ソフトウェア品質とテスト

方式設計

詳細設計

構築

要件定義 SW適格性確認テスト

SW結合テスト

SW単体テスト

内部品質

外部品質

SW内部特徴の品質（例：モジュール性、

追跡可能性）

SW実行時の品質（例：テスト実行結果）

利用時品質

プロセス品質

利用時の品質に合致するか

開発手順や方法

ソフトウェア品質モデル（ISO9126より）

依存 依存 依存

影響 影響 影響

7

ソフトウエアテストは、プログラムの実行によって・正しく動作するか・目標とした品質に到達しているか・意図しない動作をしないかどうか等を確認する作業→ 欠陥の検出はできるが

欠陥がないことは証明不可

欠陥が存在しない（ソフトウェアに仕様にない振舞がないこと）を保証

問題意識： ソフトウェアを高品質にする＝ テストの網羅度上げるになっていないか。

ソフトウェアテストの概念と課題

入力値タイミング（順番）

処理（演算）条件分岐状態

出力値

期待値

ソフトウェア

・特徴1： ハードウェアは摩耗による故障があるため、

ソフトウェアは同じ条件によるテストを繰り返したところで効果がない。

・特徴2： 数学的に入力値と条件を網羅的にテストすることは、現実的に不可能

問題意識： ソフトウェアテストケースが多い＝ 網羅度が高い、有効なテストと判断していないか

ソフトウェアテストの概念図

いろいろな試験条件を考える必要あり

全ての状態や入力の組合せを試験することはできない

比較して判定

8

アシュアランスケースとは

9

アシュアランスケースとは

10

■アシュアランスケースとは

システムが保証すること（想定された状況下で動作する）を

議論によって構造化されたドキュメントで表現する方法

※アシュアランス（保証）をケース（論拠）する。

可視化する

議論する

合意する

基本効果

■品質とは

「品質とは誰かにとっての価値である」（Quality Software Management:ジェラルド・ワインバーグ著）

可視化することで

品質要求元と合意することが可能

トゥールミンロジックとGSN

11

事実・根拠

主張

論拠：理由

論拠（判断・推論）などを成り立たせるよりどころ。行動などの正当性を支える事実。

意見考え 主張（ゴール）

戦略

下位主張

コンテキスト

証拠（エビデンス）

論証において、ある事実の真偽を判定する根拠となる事柄。

GSN(Goal Structuring Notation)

＝ ゴール構造表記法トゥールミンロジック ＝ 論証の組み立て方

■GSNの効果

・階層化された複雑な議論を可視化し

主張の曖昧さや抜け漏れを防ぐ。

・第三者への説明しやすさも高める。

ソフトウェア検証

戦略の可視化

12

保証対象：ソフトウェア製品＋成果物

証拠：エビデンス（テスト仕様と実行結果）

テスト担当プロジェクトリーダー

ソフトウェアテスト版のアシュアランスケースとは

ソフトウェアテストが、次工程へ進む上で十分に実施されていることを

説明（保証）するために、「アシュアランスケース」を活用している。

説明元説明先

ソフトウェアテストが十分であること

主張

13

14

ソフトウェアテスト版のアシュアランスケース

G.0・プログラムの不具合を抽出し、抽出された不具合について処置が完了していることを確認すること

・プログラムが要求事項を満足していることを保証するために、必要十分な確認を行うこと

S.1

仕様書、要求書の

要求事項を満足する

試験戦略No1機能試験

G.11

機能について、

試験・検査を行う

試験戦略No2境界値試験

G.12

入力制限や閾値のある項目について、試験・検

査を行う

G.13

計測モードについて、状態遷移による試験・検査を行

う

試験戦略No4回帰試験

G.14

不具合について、

再検査を行う

試験戦略No5ユーザ試験

G.15

試験作業担当者等（設備運転者）による、試験・検査

を行う

試験戦略No7シナリオ試験

G.17

模擬環境において実施可能な範囲で、運用シナリオに基づいた操作による、試験・検査

を行う

試験戦略No6障害対策試験

G.16

障害対策機能に関して試験・検査

を行う

試験戦略No9探索的試験

G.19

検査担当者及び試験作業担当者等によるランダムな操作にて、試験・検査を行う

　　試験戦略No10総合動作確認

G.20

試験完了後、試験作業担当者等（設備運転者）により、次の試験・検査を行う

a .シナリオ試験

b .探索的試験

試験戦略No8取扱説明書に基づく試験

G.18

取扱説明書の記述通り操作し、試験・検査を行う

S.2過去の不具合の分析に基づき、起こり得る

不具合の発生のない

ことを確認する

S.3

発生した不具合の

再検査を実施する

S.4

想定される全ての

ケースを確認する

S.5文書どおりに動作する

ことを確認する

S.6想定外のことの発生が

ないか確認する

S.7要求事項の全てを満足

することを確認する

試験戦略No3状態遷移試験

G1：プログラムの不具合を抽出し、抽出された不具合について処置が完了していることを確認すること

プログラムが要求事項を満足していることを保証するために、必要十分な確認を行うこと

S.1

仕様書、要求書の要求事項を満足する

S.2

過去の不具合の分析に基づき、起こり得る不具合の発生のないことを確認する

・・・・・

最初に作成したケース図の全体

※2階層まで抜粋

前提（コンテキスト）を使いこなせず、チェックリストのような展開

→ 論理的な議論の余地がない（＝GSNの効果がない）

ソフトウェアテストにおける展開パターン

15

入力値タイミング（順番）

処理（演算）条件分岐状態

出力値

期待値（参照文書）

ソフトウェア

テストの効果を高めるため 論理モデルによる展開パターンを用意

No１：検証対象展開

対象を詳細化/具体化して分けること

No3:期待値展開

期待される値/結果で分けることNo2：試験条件展開

試験の条件で分けること

No4：リスク頻度展開

過去の不具合の分析結果に着目すること

G1.2：非機能の要求事項の確認が十分にされている。

16

G0： Aシステムは、試験が十分に実施されている。

S0：【検証対象分解：設計解】要求事項の有無に分けて、試験をする。

G1：仕様書、要求書の要求事項通り、動作することの試験が十分にされている。

S1：【検証対象分解：論理】要求事項を機能、非機能

に分けて確認する。

G1.1：機能の要求事項の確認が十分にされている。

・・・・

C0-a：システムAのソフトウェアの最終試験

ソフトウェアテスト版のアシュアランスケース

C0-a：・仕様書・開発仕様書・技術要求書

S.0　【検証対象分解：設計解】要求事項の有無に分けて、試験

をする。

G.1仕様書、要求書の要求事項通り、動作することの試験が十分にされている。

　G.111　単発で動作する機能の確認が十分にされている。

　G.112　組み合わせで動作する機能の確認が十分にされている。

　　E.1　　試験戦略No1　機能試験　NoA

G.2仕様書、要求書に未記載であるが、装置の機能・性能上必要な要求事項通りに動作することの試験が十分にされている。

C.1-a・仕様書・開発仕様書・技術要求書

　E.2　試験戦略No2

　シナリオ試験

　C.112　・運用シナリオ　・取扱説明書

　S.2【リスク頻度：不具合分析】　　過去不具合を分析し、　　試験を行う。

G.21境界値試験が十分にされている。

G.22状態遷移試験が十分にされている。

G.23ユーザ試験が十分にされている。

C.2-a 不具合分析結果・境界値（入力制限、閾値）に関わる不具合①・モードの変更に関わる不具合②・ユーザの操作で複数の処理ケースが　発生する場合の不具合③・障害に関わる不具合④・想定外の操作による不具合⑤

C.2-b

不具合報告書

　E.3　試験戦略No3

　取扱説明書に基づく試験

　　E.4　　試験戦略No4　境界値試験

　E.5　　　試験戦略No5　状態遷移試験

　　E.6　試験戦略No6　ユーザ試験

G.0

　システムAの試験は十分にされている。

G.24障害対策試験が十分にされている。

　E.7　試験戦略No7　障害対策試験

G.25探索的試験が十分にされている。

　E.8　試験No8　探索的試験

G.26回帰試験が十分にされている。

　E.9　　　試験戦略No9　回帰試験

　　S.1【検証対象分解：論理】　　要求事項を機能、非機能に　　分けて確認する。

　G.11機能の要求事項の確認が十分にされている。

　G.12非機能の要求事項の確認が十分にされている。

　　S.11【試験条件分解：論理】　　単発と組み合わせで　　機能の動作を確認する。

　　S.12【期待値分解：設計解】　　性能（処理能力、保存能力）、　障害対策の要求事項に分けて　確認する。

　G.121処理能力、データ保存能力の確認が十分にされている。

　G.122　冗長性、データのバックアップの確認が十分にされている。

　　E.1　　試験戦略No1　機能試験　NoB

　　E.1　　試験戦略No1　機能試験　NoC

　　S.112【期待値分解：設計解】　　運用の開始から終了までの　　操作の組み合わせと　　各ウインドウの機能の　　組み合わせに分けて確認する。

　G.1121　　運用の開始から終了までの一連の操作の確認が十分にされている。

　G.1122　　各ウインドウの一連の機能の確認が十分されている。

C.0検証対象の構成は下記システムA

C.1-b・「機能」とは、システムに要求される特定の処理　能力の有無を示す定性的な要件である。・「非機能」とは、システムの要求される特定の　処理能力以外の要件（性能、障害対策、　セキュリティ）である。・「性能」とは、システムの処理能力毎の最大値や　有効値といった定量的な要件である。

　G.123セキュリティの確認が十分にされている。

　　E.1　　試験戦略No1　機能試験　NoD

改善されたケース図の全体

※2階層だった構造が4階層に

何に基づいて試験をするのか

どこまで試験しているのか

議論が可能になった

17

17

ソフトウェアテスト版のアシュアランスケース

議論による効果（テスト精度向上）の例

G.21

プログラムの条件を考慮した試験が十分にされている。

S.21【リスク頻度：期待値】コード上の条件について

外部センサーの誤差の影響で条件外となるケースに着目

G.211

センサーの誤差の要因で条件外となるケースの試験が十分にされている。

C2.1

・前工程で条件網羅試験は実施済み

C.21

不具合情報

G.21

プログラムの条件を考慮した試験が十分にされている。

S.21

コード上の条件に着目する。

C.211

センサー情報

G.211

プログラムのコード上の条件外の試験がされている。

議論後

議論により入力特性を定め、根拠に基づく試験ケースの設定へ

保証対象：ソフトウェア製品＋成果物

証拠：エビデンス（IV&V活動の分析結果）

IV&V実施組織開発プロジェクト

第3者による検証活動版のアシュアランスケースとは

第3者による検証サービスは、ソフトウェアに「リスク（不具合要因）」がないことを

説明（保証）するために、「アシュアランスケース」を活用している。

※開発担当と異なる視点を持つことが必須のため。

説明元説明先

ソフトウェアリスクがないこと

主張

18

第3者による検証活動版のアシュアランスケース

19

（ゴール）システムとソフトウェアの状態遷移の齟齬により想定外の状態に陥らない

（ストラテジー）条件分岐に着目する

遷移条件に誤りがない 遷移条件の抜けがない

異常時の運用シナリオに着目する

運用シナリオにおける異常時のモード遷移の遷移条件が、

ソフトウェア要求と整合している

運用シナリオで規定された異常処理に範囲を限定する

・・・

運用シナリオとソフトウェア要求の整合性分析表

IV&Vとして保証したいこと＝ 依頼元と合意

分析作業の結果＝ 目的を達成している根拠

「目的（ゴール）」を達成するために必要な論理（視点）

評価できる「目的（ゴール）」まで分解

分類 例 図上の色

テスト担当が確認した内容 要求仕様にある各機能の動作不具合水平展開による試験

第3者検証担当のみ確認した内容

設計検証（マルチタスクにおける競合防止の有無）

コードレビュー（一貫した型定義や丸め誤差の影響有無）

テスト担当及び第3者検証ともに共通の確認内容

異常な外部入力値の試験

ソフトウェアテストと第3者検証を合わせた確認事例

20

テスト担当

第3者検証担当

共通

G.0過去に発生した不具合からシステムに潜在するリスクを抽出し、検証戦略を策定する。

（C1①に示す。ミッションが喪失してしまう恐れのある不具合を選定し各々に対してリスクを抽出する。）

検証戦略.1ソフトウェア開発成果物間の整合評価

C.1①以下の問題を含む不具合を抽出の対象とした。　(1) データの真値に支障が生じるもの　(2)　誤った情報を発信（保存・表示）してしまうもの　(3)　データの消失が生じてしてしまうもの

②その結果＊＊件の不具合を選定した。

③②にたいして不具合情報資料を作成し、不具　合の特性を洗い出した。

G.111時間の積算にあやまり

がある。

G.121閾値が正しく判定さ

れない

G.112試験時間が正しく積

算されない

G.113温度設定値の少数桁の

値が異常

G.131計測モード変更時にデータ表示ができない。（データ収集不

能）

G.122限界値リミットチェックを「有」から「無」に変更したにも関わらず、限界値リミ

ットエラーが出力される

G.123

測定IDのデータ名称を変更したところ、異なるチャンネルの名称が変更され

た。

G.124０時００分００秒の異常データだけ、時間データが

表示されない。

G.125表示されるはずの警報の元となった異常データの情報が表示されていな

い。

G.126

HH時MM分SS秒からHH

時MM分SS秒までのデー

タが表示されない。

【設計】SWの起動処理について明文化されていない

【設計】時間の保存方法が明確化されていない）

【設計】ソフトウェア設計結果と要求仕様が整合していない

【設計】計測器に誤差が発生することの考慮漏れ。

【実装】変数であるべき箇所を定数で実装

【試験】試験ケースの不足

【実装】実装者が通常

考慮することの抜け

・関数の選択方法・丸め誤差の防止テクニック

【設計】小数点の値の扱い方の定義

【設計】・各インターフェースの異常時における振る舞いについて明文化されていない

【設計】・マルチスレッドのデータ入出力のタイミングによる問題

【設計】・マルチスレッドの同期非同期処理の遅延の取扱い

【実装】実装者が通常

考慮することの抜け　・入力値、引数、配列、内部変数等を、理解（レビュー）しやすい変数名で命名する

【設計】文書定義の抜け

　・　変数、配列定義　・　運用者の利用方法（レアケースを含めて）

【設計】設計結果の検証不足

【試験】試験ケースの不足

【試験】試験ケースの不足

【設計】データ構造（識別等）に関する検証不足

【設計】標準関数の使用に関する検証不足

【試験】試験ケースの不足

【設計】設計結果の検証不足

【試験】試験ケースの不足

検証戦略.2外部インターフェース仕様に対する評価

検証戦略.3外部データ入出力タイミングの完全性評価

検証戦略4同期及び非同期処理の遅延の確認

検証戦略.5ソフトウェア設計仕様等と試験仕様との整合性確認

　不具合情報■設計検証・設計結果の検証不足

■試験検証・試験ケースの検証不足

検証戦略6ソフトウェア試験条件の完全性確認検証戦略.7

コード評価

S.1A1不具合情報から

特性を洗い出す。

S.191不具合情報から不具合の特性を

洗い出す。

不具合情報■設計検証・データ構造（識別等）に関する検証不足

■試験検証・試験ケースの検証不足

不具合情報■設計検証・標準関数の使用に関する検証不足

■試験検証・試験ケースの検証不足

S.181不具合情報から不具合の特性を

洗い出す。

不具合情報■設計検証・設計結果の検証不足

■試験検証・試験ケースの検証不足 S.171

不具合情報から不具合の特性を

洗い出す。

　不具合情報■実装者が通常考慮することの抜け　・入力値、引数、配列、内部変数等を、理解（レビュー）しやすい変数名で命名する■文書定義の抜け　・　変数、配列定義　・　運用者の利用方法（レアケースを含めて）

S.161不具合情報から不具合の特性を

洗い出す。

S.151不具合情報から不具合の特性を洗い出

す。

　　不具合情報■設計・各インターフェースの異常時における振る舞いについて明文化されていない。・マルチスレッドのデータ入出力のタイミングによる問題。・マルチスレッドの同期非同期処理の遅延の取扱い

S.141不具合情報から不具合の特性を

洗い出す。

不具合情報

【特性】■実装者が通常考慮することの抜

け

・関数の選択方法

　・丸め誤差の防止テクニック

■文書定義の抜け

　・　小数点の値の扱い方の定義

S.131不具合情報から不具合の特性を

洗い出す。

　　不具合情報

資料

■実装・定数でない箇所を定

数で実装

■試験・ﾕｰｻﾞが選択可能な設定要素について、網羅

的に試験していない

S.121不具合情報から不具合の特性を

洗い出す。

　

不具合情報

資料

【特性】

■設計

・計測器誤差考慮漏れ

　　不具合情報

【特性】

■設計

・起動処理の明文化

・保存使用の明文化

■試験・要求事項と設計結果

の不整合

S.121不具合情報から不具合の特性を

洗い出す。

検証戦略8ソフトウェア設計結果の完全性確認

検証戦略8ソフトウェア設計結果の完全性確認

C2今回、設計で特化して確認する内容（ネットワーク統合やSQLデータベース化等）を検証戦略８としてまとめます。

システム分析編と兼ねる予定です。　　　　　　　　↓しかし、設計書で確認できなかっため、コード評価にて行うこととした。（点線参照）

S.11計測データの真値に支障が生じるもの

に対してリスクを抽出する。

S.12誤った情報を発信（保存・表示）してし

まうものに対してリスクを抽出する。

S.13計測データの消失が生じてしてしまうも

のに対してリスクを抽出する。

検証戦略.7コード評価(設計評価で確認できなかった為、コード評価にて実施する。

まとめ

ソフトウェア第3者検証活動（IV&V：Independent Verification and Validation）については、「IV&Vガイドブック」をご覧ください。

お問い合わせ先：IVV_INFO@jaxa.jp

ソフトウェアテスト、第3者による検証と妥当性確認に対し

アシュアランスケースを応用し、可視化や議論の事例

をご紹介した。

21