JaSST東海２０１０名古屋大学 情報連携統括本部 情報戦略室
教授 山本修一郎

Copyright Nagoya University 2010

自己紹介 ソフトウソフトウェア開発を実践
ア開発を実践
 NTT研究所、NTTデータ技術開発本部
 ソフトウェア工学の研究、教育 要求工学、設計法、プロジェクト管理、EA
 高信頼性システム開発手法
 IPA ソフトウェアエンジニアリングセンター
 比較コミュニケーション論
比較 ミ
ケ シ ン論 NTTデータ システム科学研究所
 持続的情報連携アーキテクチャの研究開発
 名古屋大学 情報連携統括本部 情報戦略室
Copyright Nagoya University 20102

1

実現した主なソフトウェア
プロジェクト

管理面

技術面

DIPS-APL(1980)

開発管理、事業化

言語処理系，移植技術，テスト

SoftDA(1984)

開発管理，社内導入

分析設計技術，関係情報管理，内製VGUIDE(1995)

事業化

分散システム，トランザクション処理

WebBASE(1996)

実証実験、事業化

Xform(1998)

開発管理
実証実験
標準化
事業会社連携InfoSTAGE(Σserv)(1998-2004)
NICE(2000-)) (注)NICE(2000
Cell computing(2003-08)
ODVPN(2002-)
RFID-PF(2004-06)

WebDB連携，検索技術
XML，セキュア配送，情報変換言語
XML，サービス連携，長期トランザクショ
ン処理
ICカード，セキュリティ，ユビキタスコンピューティング
PCグリッド

実証実験
事業化
標準化

VPN，セキュリティ，デバイス認証
RFID認証，プライバシー保護(注)マルチアプリケーションICカード向け情報流通プラットホームの実用化
http://www.dbjet.jp/pub/cgi-bin/detail_pro.php?id=1042
3

Copyright Nagoya University 2010

プロジェクト特性とツール導入
組織の成熟度
適用成功プロジェクトの平均•導入への管理者の積極性•設備投資の可能性•新規開発の割合

機能の適合度•提供機能の充足性•機能のカスタマイズ

担当者の成熟度•新手法の必要性の認識•新技術に対する教育レベル

方法論の適合度
適用失敗プロジェクトの平均
Copyright Nagoya University 2010

•新手法への移行計画の十分性•適用機能／工程の具体性•エンドユーザの参画
42

高信頼性システム開発手法の活動
年度

会合

イベント・報告書

委員構成

２００７

調査検討会7回・高信頼性システム開発手法フォーラム
・高信頼ソフトウェア構築技術に関する動向調査報告書

産：7
学：5
官：6

２００８

高信頼性システム
技術WG 6回

・日中高信頼性システム検討会
・第７回WOCS-Workshop Of Critical Software（JAXA/IPA-SEC）

産：13
学：5
官：5

２００９

高信頼性システム
技術WG 6回
PT 3回

・ソフトウェアジャパン２０１０
ソフトウェア開発のパラダイム・チェンジinマインド －IPA/SECにおける新しい取組み－
・高信頼システム開発技術の動向（予定）

産：16
学：7
官：8

(参考)山本修一郎，形式手法の誤解を解く，ソフトウェアジャパン2010
Copyright Nagoya University 20105

コミュニケーションのMIGEモデル
目的 Goal

自律

Internal

協働

自己実現
自己啓発
自己選択

矛盾調整
知識探索
資源配分

External

外

内
反省
記録
自問

内省

報告
連絡
相談
状況 Mediation

持続(参考)山本修一郎, 比較コミュニケーションモデル論に向けて, 第7回知識流通ネットワーク研究会,
http://www4.atpages.jp/sigksn/conf07/index.html
Copyright Nagoya University 2010

63

3階層情報連携アーキテクチャ
連携情報活用コミュニティ
情報連携基盤層
連携対象情報層参考）持続的情報連携サービス分析方法論の研究課題, KBSE研究会, 2010.11.24
7

Copyright Nagoya University 2010

主な著作
書籍

出版社

誰も語らなかったIT ９つの秘密

出版年

ダイヤモンド社

2004

要求定義･要求仕様書の作り方

ソフト･リサーチ･センター

2006

IT戦略デザイン

リックテレコム2006

ゴール指向による!!システム要求管理

ソフト･リサーチ･センター

2007

次世代プロジェクトリーダーのための～すりあわせの技術

ダイヤモンド社

2009

CMCで変わる組織コミュニケーション

NTT出版

2010

連載要求工学

ビジネス・コミュニケーション

www.bcm.co.jp/site/youkyu/index.html

Copyright Nagoya University 2010

2004-

8

4

主な議題
 なぜ独立検証なのか
 IEEE Std. 1012-2004 IV&V（独立検証確認）
 独立検証の先進事例
 テストと開発、運用

 相互理解モデル

9

Copyright Nagoya University 2010

ISO26000
３つの理由２つの実態５つの課題Copyright Nagoya University 201010

5

ISO26000

企業の社会的責任

７つの原則

説明責任
透明性
倫理的行動
利害関係者の尊重
法令順守
国際行動規範の尊重
人権尊重

Copyright Nagoya University 201011

独立検証確認が必要な理由
 システムに欠陥がないことをテストによって完全に保証することはできない システムの信頼性が高いほど，重大な欠陥の発見が遅れる
 最新の開発技術に基づいて，過去のシステム開発の妥当性が判断される

Copyright Nagoya University 2010126

検証確認の２つの実態
 事故が発生したとき
 計画した検証確認を実施していた 計画した検証確認を実施していなかった どのようにして説明するのか？

Copyright Nagoya University 201013

検証確認活動を保証するには？
 客観的な証跡がない限り，システムの信頼性をいく
ら当事者が主張しても信用されない
 当事者による客観的な検証確認結果を示す証跡
 当事者以外の第三者による客観的な検証確認（IV&V）の証跡

Copyright Nagoya University 201014

7

テストプロセスシステムとその関連生産物に対して、具体的な証跡を提供システムとその関連生産物に対して具体的な証跡を提供a) 要求を満足することb) 適切な問題を解決すること
 物理規則を正しくモデル化
 ビジネス規則を実現
 システムの前提条件を利用
c) 意図された利用とユーザニーズを満足すること
参考) IEEE Std. 829‐2008 Standard for Software and System Test Documentation
Copyright Nagoya University 201015

第三者検証確認の課題
 冗長ではないのか どこまで検証確認するのか
 第三者へ情報提示すると不利になるのではないのか
 第三者検証機関の責任はどうなるのか 開発組織の責任はどうなるのか

Copyright Nagoya University 2010168テストの限界説明責任17

Copyright Nagoya University 2010

ソフトウェアV&Vとは
活動

説明

判断内容

検証

開発活動による生産物が開発活動に対する要求に適合していること

ソフトウェアとコンポーネントが，その工程の開始時点で定められた条件を満たすこと確認

開発されたソフトウェアが意図された利用法とユーザニーズに適合していること

ソフトウェアとコンポ―ネントがソフトウェアとコンポ
ネントが開発プロセスの完了時までにユーザのニーズとしての要求を満たすこと

参考）IEEE Std. 1012‐2004 Software Verification and Validation
Copyright Nagoya University 2010189

検証確認の証跡
活動
検証

確認

証跡の内容
①各活動に対する要求に適合すること②標準，実践規約，慣例を満たすこと③各活動を完了すること④後続工程の開始基準を満たすこと①ソフトウェア要求を満たすこと②正しい問題を解決すること時期
ライフサイクルプロセスの活動過程
ライフサイクル活動の完了時参考）IEEE Std. 1012‐2004 Software Verification and Validation
19

Copyright Nagoya University 2010

IV&Vの基本概念
経営
部門

要求

開発
部門

ユーザ

開発
生産物

開発
プロセス

適合性

重要活動

①財政独立性検証
セン
ター②管理独立性

標準手順③技術独立性IEEE1012-2004
Copyright Nagoya University 201020

10

IV&Vの類型
管理独立性
厳格

統合型
財務，管理が独立

正統型
財務，技術，管理が独立

条件的

内部型
開発者が指揮修正型
主契約者が管理内蔵型
最小限 開発組織内で実施
最小限

条件的

厳格
技術独立性

参考）IEEE Std. 1012‐2004 Software Verification and Validation
21

Copyright Nagoya University 2010

ソフトウェア完全性水準
完全性水準

発生確率

4
3

確実，相当

≧偶発

確実，相当

相当，偶発

偶発，まれ

2

確実，相当

相当，偶発

まれ

1

相当≧

偶発，まれ

まれ

無視可能

軽微

重大

破局

影響度

参考）IEEE Std. 1012‐2004 Software Verification and Validation
Copyright Nagoya University 201022

11

ライフサイクルプロセスとV&V
ISO/IEC 12207
ライフサイクルプロセス

IEEE Std. 1012-2004
検証確認(V&V）プロセス

調達

調達V&V

提供

提供V&V

開発

開発V&V

運用

運用V&V

保守

保守V&V

組織的
その他の支援V&V管理参考）IEEE Std. 1012‐2004 Software Verification and Validation
Copyright Nagoya University 201023

IV&Vライフサイクル
IV&V活動のプロセスには，企画，実施，報告という３段階がある
段階
企画

実施
報告

説明
システム要求レビュ（SRR）に先行して計画立案に着手する．SRRと基本設計レビュ (PDR)の間にIV&V
計画 (IVVP)を策定する
IVVPをプロジェクトに提示し，IVVPに基づいて作業計画を立案する計画を立案する．
サービス開始直後に実施段階を終了する
最終技術報告として実施結果を報告し，解決した課
題を文書化する
Copyright Nagoya University 2010

24

12

IEEE Std. 1012-2004の要求V&V①追跡性分析
②要求評価③インタフェース分析④重要性分析
⑤システムテスト計画作成⑥受入れテスト計画作成⑦構成管理評価⑧危険性分析
⑨セキュリティ分析⑩リスク分析
参考）IEEE Std. 1012‐2004 Software Verification and Validation
Copyright Nagoya University 2010

25

IEEE Std. 1012-2004のテストV&V①追跡性分析
②受入れテスト手順作成③結合テスト実行④システムテスト実行⑤受入れテスト実行⑥危険性分析
⑦セキュリティ分析⑧リスク分析
参考）IEEE Std. 1012‐2004 Software Verification and Validation
Copyright Nagoya University 201026

13

テストにおける追跡性分析
V&Vテスト計画、テスト設計、テスト項目、テスト手続き間の関係を分析
性質

正当性

検証内容

対象

V&Vテスト計画
テスト設計
追跡関係が正しいこと
テスト項目
テスト手続き完全性

追跡できること

テスト手続きからテスト計画への追跡性

27

Copyright Nagoya University 2010

テストV&Vの危険性、セキュリティ、リスク分析
分析対象

内容

危険性

テストの仕組みが新たな危険性を持ち込まない
ことを検証

セキ リテ
セキュリティ

実装システムがセキュリティリスクを増加させないことを検証リスク

リスク分析を改訂する
リスク解消、低減、緩和対策を提供
Copyright Nagoya University 201028

14

受入れテスト手続きの作成
活動

4-3

2

受入れテスト手続きの作成

○

追跡性管理

○

開発者の受入れテスト手続きがテスト文書の目的、形式、内容にト文書 目的 形式 内容に適合していること○○

開発者の受入れテスト手続きが要求V&V活動を満たすこと

○

○

1

29

Copyright Nagoya University 2010

V&V受入れテスト計画への要求
重大性

作成対象計画
1.
2.
3.

4-3
4.
5.
6
6.

受入れV&V テストを実施
テスト結果を分析してソフトウェアがシステム要求を満たすことを検証
テスト結果がテスト計画文書のテスト追跡性によって定義されたテスト基準を満たすことを検証
受入れテスト計画で要求された結果を文書化
受入れV&Vテスト結果に基づいてソフトウェアがV&Vテスト受け入れ基準を満たすことを確認
期待結果と実施結果の食い違いを文書化

2

調達者による受入れテスト結果に基づいて、ソフトウェアが受入れテス
ト基準を満たすことを検証

1--参考）IEEE Std. 1012‐2004 Software Verification and Validation
Copyright Nagoya University 2010

30

15

V&Vのテスト活動
V&V活動
活動

受け入れ
V&Vテストシステム
V&V テスト結合
V&Vテストコンポーネント
V&V テスト

要求

計画作成

計画作成

設計

設計作成

設計作成

計画作成
設計作成

計画作成
設計作成

実装

テスト項目作成

テスト項目作成
テスト手順作成

テスト項目作成
テスト手順作成

テスト項目作成
テスト手順作成
テスト実行

テスト

テスト手順作成
テスト実行

テスト実行

テスト実行

参考）IEEE Std. 1012‐2004 Software Verification and Validation
31

Copyright Nagoya University 2010

要求V&V受入れテスト計画への要求
重大性

作成対象計画計画の解決対象

計画の検証基準

計画の確認基準4

受入れテスト計画
受入れテスト要求の追跡性確認計画
テスト文書化計画

運用環境の受入れ要求への適合性
文書の適切性テスト文書基準への適合性
受入れテスト要求の網羅性

期待結果への適合性
運用と保守の実現性

調達者による受入れテスト
が、受入れテスト要求の網
羅性
期待結果への適合性
期待結果の適合性
運用と保守の実現性
--

3

2

--

--

調達者による受入
れテストが、テスト文書基準への適合性
書基準
の適合性

1

--

--

--

参考）IEEE Std. 1012‐2004 Software Verification and Validation
Copyright Nagoya University 201032

16

要求V&Vシステムテスト計画への要求
重大性

3-4

作成対象計画計画の解決対象

計画の検証基準

計画の確認基準

システムテスト計画
システムテスト要求の追跡性確認計画システムテスト文書化計
画システム環境へのシ
ステム要求の適合性
文書の適切性
境界とストレス条件
での性能テスト文書基準への適合性
システム要求の網羅性

テスト手法の適切性
期待結果への適合性
システム品質テストの実現性
運用と保守の実現性--

テスト文書基準への適合性
システム要求の網羅性

テスト手法の適切性
期待結果への適合性
システム品質テストの実現性
運用と保守のケイパビ
リティ

1-2
1
2

--

参考）IEEE Std. 1012‐2004 Software Verification and Validation
33

Copyright Nagoya University 2010

設計V&Vコンポーネントテスト計画への要求
重大性

作成対象計画計画の解決対象

4

3

テスト計画
設計要求の追跡性確認計画
テスト文書化計画

設計要求への適合性
時期、規模、正確性の評価
性能（協会、インタ
フェース、ストレス、エラー条件）
要求網羅性の測定

計画の検証基準

計画の確認基準

テスト文書基準への適合性

要求と設計への追跡性
要求と設計の外部一貫性
単位要求間の内部一貫性
単位ごとの要求網羅性
結合とテストの実現性
運用と保守の実現性

2

--

--

開発者によるテスト
が、テスト文書基準への適合性

開発者によるテスト計画が、要求と設計への追跡性
要求と設計の外部一貫性
単位要求間の内部一貫性
単位要求間の内部
貫性
単位ごとの要求網羅性
結合とテストの実現性
運用と保守の実現性

1

--

--

--

--

参考）IEEE Std. 1012‐2004 Software Verification and Validation
Copyright Nagoya University 201034

17

設計V&V結合テスト計画への要求
重大性

作成対象計画計画の解決対象

4

3

テスト計画
設計要求の追跡性確認計画
テスト文書化計画

設計要求への適合性
時期、規模、正確性の評価
性能（協会、インタ
フェース、ストレス、エラー条件）
要求網羅性の測定

計画の検証基準

計画の確認基準

テスト文書基準への適合性

要求と設計への追跡性
要求と設計の外部一貫性
単位要求間の内部一貫性
単位ごとの要求網羅性
結合とテストの実現性
運用と保守の実現性

2

--

--

開発者によるテスト
が、テスト文書基準への適合性

開発者によるテスト計画が、要求と設計への追跡性
要求と設計の外部一貫性
単位要求間の内部一貫性
単位要求間の内部
貫性
単位ごとの要求網羅性
結合とテストの実現性
運用と保守の実現性

1

--

--

--

--

参考）IEEE Std. 1012‐2004 Software Verification and Validation
35

Copyright Nagoya University 2010

IEEE Std. 1012-2004の運用V&V
活動

内容

新規制約の評価システムやソフトウェア要求についての運用要求、プラットフォーム特性、運用環境などの新規制約を評価してSVVPの適用性を検証
性 運用環境などの新規制約を評価してSVVPの適用性を検証

運用手順評価運用手続きがユーザ文書と矛盾せずシステム要求に適合することを検
証

危険性分析

運用手続きと運用環境が新たな危険性をもたらさないことを検証
危険性分析を改訂

運用環境の変更に起因する新たなセキュリティリスクがないことを検証
セキュリティ分析 時間経過による外部インタフェース、脅威、技術の変化に従う新たな未処置リスクを判定するためのセキュリティ分析の改訂
リスク分析

リスク分析を改訂する
リスク解消、低減、緩和対策を提供
Copyright Nagoya University 2010

36

18

IEEE Std. 1012-2004の保守V&V①ソフトウェア検証確認計画（SVVP）改訂②不具合評価③重要性分析
④移行要求評価⑤退役要求⑥⑥危険性分析
⑦セキュリティ分析⑧リスク分析
⑨反復
Copyright Nagoya University 2010

37

期待効果
①ソフトウェア異常の検出と修正の早期化②開発プロセスと生産物のリスクに対する客観的な管理の推進③生産性，工期，予算に対してライフサイクルプロセスの適合性④ソフトウェアとシステム性能の影響評価の早期化⑤ソフトウェアとシステムの適合性に対して客観的な証跡に基づく，
公式検定プロセスの提供⑥開発保守プロセス改善⑦システム開発を統合的に分析できるモデル提供によるプロセス
改善

Copyright Nagoya University 201038

19

事例１ 東証 arrowhead
事例２ Felica
事例３ JAXA

39

Copyright Nagoya University 2010

我が国におけるIV&Vの先進事例
事例

IV&V

フィードバック形態

JAXA■開発メーカ内部の独
■開発メ
カ内部の独
立組織
■JAXA内部の別組織■検証部門から開発部門への問
題内容をタイムリーにフィード
バック■モデル検査■第三者機関が検証■各工程内で段階的作業による工程内フィードバック■工程間フィードバック■第三者による評価認証結果の開発部隊へのフィードバック■公的なセキュリティ評価・認証の枠組みによるVDM記
述を第三者機関が検証■検証結果を検証者とは別の第三者が認証■第三者機関が外部
設計を検証■工程ごとに障害発生件数を設定しておき、許容下限値に接近すると品質強化対策を実施する「リアルタイム品質管理」■後続工程で先行工程の障害を積極的に検出して先行工程にその内容をフィードバック

－－－

フェリカ
ネットワー
クス

東証

Copyright Nagoya University 2010

形式手法

40

20

フィードバック型V字モデル
要件定義

要件定義書
の評価

受入れ
テスト

状態遷移イベントパターン

外部設計

プレ受入れテスト
テストケース

機能設計

要件を設計書
に反映

システム
テスト

ウォークスルー評価
結合
テスト

処理設計

製造工程での
詳細設計書の評価
製造

単体
テスト

品質の作りこみ工程

品質の検証・確認工程

Copyright Nagoya University 2010

41

発注品質保証プロセス
施策

説明

要件ト
要件トレースオークションパターンを作成し要件定義書と外部設計書の品質を確保し，要件トレースできることを確認する
書の品質を確保し 要件トレ スできることを確認する

工程完了条件

次工程の準備ができていることを確認する．もし次工程に入るだけの準備ができていなければ，現工程を継続する

工程内品質管理

工程ごとに品質目標と品質アラーム線を予め設定しておき，品質アラーム線を超えると品質対策を実施する

工程完了判定予め工程完了基準を定義しておき，発注者が工程完了
判定を品質評価会議と稼働判定会議によって実施する

詳細設計書のレビュー

ベンダーが作成した詳細設計書を発注者がレビューすることにより要件トレースを確認する

品質実地検査サブシステムごとに品質を実地検査する

納入品質の確保

プレ受入れテストを実施し，検収前に入念に開発中のサブシステムの品質を確保する
Copyright Nagoya University 2010

4221

上流工程における欠陥検出率
欠陥検出率
60 %

結合試験
混入：10% 検出：50.5%

50
40
30

サービス開始後
検出：21%

20

受入試験
検出：9%

10

要求定義，設計，製造
要求定義
設計 製造
混入：70% 検出3.5%

単体試験
混入：20% 検出16%

0

欠陥混入率
0

20

40

60

80 %

（参考）NIST, Planning report 02-3, The Economic Impact of Inadequate Infrastructure for Software Testing, May 2002
Copyright Nagoya University 201043

独立検証のコスト推定（仮説）
コスト
（開発
＋テスト）

従来型

＋テスト活動の前倒し＋製造品質向上－前工程品質向上効果＋テスト活動の前倒し＋設計品質向上－要求品質向上効果

工期短縮
独立検証

＋テスト活動の前倒し＋要求品質向上

要求－テスト活動の前倒し
テスト活動の前倒し－上流品質向上効果

設計

製造

テスト

時間

（注意）切片，傾きは対象によって変化
Copyright Nagoya University 20104422事例１ 東証 arrowhead
事例２ Felica
事例３ JAXA

45

Copyright Nagoya University 2010

重要インフラ障害の原因分類
社会的に問題とされマスコミが取り上げた事例85件の分類（2006年12月～2007年10月）

運用
40%

開発
21%
保守
39%

参考）経済産業省，重要インフラ情報システム信頼性研究会 報告書，2009, IPA
Copyright Nagoya University 201046

23

運用前の要求品質の確保【問題１】運用手順を記述する方法が明確でない【問題２】運用手順と開発生産物とを対応付けて記述できない【問題３】運用手順の変更管理が困難である【原因】
運用活動の主体と対象には状況に応じた相互作用関係があるにもかかわらず，明確に定義されていない
参考）山本修一郎、システム運用知識抽出法の提案、知識流通ネットワーク研究会、2010
47

Copyright Nagoya University 2010

要求とテストの関係
どのような要求が実現できるか
どのような限界があるか

目的

テスト

要求

期待

手段

証跡

アカウンタビリティ
Copyright Nagoya University 2010

48

24

要求とテストの連携策の例
連携策

利点

要求レビュにテスト専門家が参画

最終テスト段階での要求変更の発生を抑止

課題

事業目的に対して要求仕様書の完全性と正当性をテスト

欠陥の早期発見

テスト専門家による事業目的の理解

要求を具体例でテスト

曖昧な要求仕様の改善

What if質問のスキル
想定ユーザの妥当性

非機能要求を測定する適切な基準を考えることでテストする

曖昧な非機能要求の明確化

曖昧な非機能要求のテストは困難
顧客の参加が重要

副作用の影響がないことを回帰テストで確認変更による影響に対してシステムが正常であることを確認

回帰テストのコスト

入出力，事前条件，事後条件の明確化システムが何をしているかと何をすべきかの差を解明

テスト専門家は答を知っているのが前提
要求がないと分からない

探索テストによりシステムの挙動を調査

テスト計画，テスト仕様などからなるテスト
ウェアで要求仕様を代替可能

不十分な要求の下ではテスト専門家の知識に依存

要求とテストの追跡性

テスト網羅性の向上
変更管理、欠陥摘出の効率化

追跡性の維持が困難
高い要求品質が前提条件

要求担当とテスト専門家のコミュ
ニケーション

テスト専門家による推測の削減
低い要求品質を補完
テスト結果の信頼性の向上

要求責任者の負荷が増加
業務知識専門家の確保が困難
情報の信頼性が絶対条件

テスト専門家による要求発見

テスト可能性の向上
テスト工数削減と工期短縮

指摘内容の質の向上
指摘内容の優先順位

顧客の参加が重要

Copyright Nagoya University 201049

要求仕様の完全性基準
項目

内容

人間・コンピュータ・イ 警報：イベント，型，個数，順序構造，通知，確認，削除
ンタフェース
トランザクション：構成要素，優先制御
タトザクシ
構成要素 優先制御
状態

正常／異常状態での期待入力
想定外入力の考慮

入出力

デバイス入出力：データの種別
操作の対称性：例えばオープンしたらクローズがある

イベント発生契機イ
ント発生契機
出力イベント

ロバスト性
非決定性
値・タイミング：前提条件，間隔，容量・負荷
環境の許容量，データの寿命，遅れ

入出力イベントの関係 応答性
状態間の関係到達性，回帰性，可逆性，優先性，ロバスト性

参考） Leveson, N.G., SAFEWARE – System Safety and Computers, Addison Wesley, 1995
Copyright Nagoya University 20105025

要求記述の構成要素
曖昧性：範囲，内容，関係の多義性・不明性
機能仕様

アクタ

事前
状況

イベント

入力

処理

アクタが
何を
どんな入力
どういうときに 契機として に対して

観測対象

観測事象

出力

事後
状況

応答

アクタ

システムが どんなこと何を出力す が発生して
ると

アクタに
何が起き
るのか

観測応答

参考)要求の曖昧さ，http://www.bcm.co.jp/site/youkyu/youkyu38.html
Copyright Nagoya University 2010

51

Teradine社における要求とテストとの追跡性の実証分析
 要求工学国際会議2010優秀論文
 追跡性についての技術者評価の差異分析
 要求とテスト項目の関係は比較的明確
 システム要求とサブシステム要求の関係は曖昧

追跡性の評価
技術者

有効性

適用性

設計検証者

80%

100%

システム開発者

70%

50%

サブシステム開発者

25%

60%

 システム要求は多様な情報源との関係が曖昧 検証テスト文書：要求IDを明示

要求追跡表
定義要求

準拠要求

RQ.Inst.Waveform

RQ.Inst.PgmSamples

なし

RQ.Inst.PgmRate

 要求追跡性のデグレード原因
 追跡関係
追跡関係の曖昧性
曖昧性強い関係：判断者が異動すると意味が変化
弱い関係：多すぎると意味がない

テスト項目表テストID

TC.Inst.RateErr

記述

サンプルエラーメッセージをテスト

 要求変化

要求ID

RQ.Inst.PgmSamples
RQ.Inst.PgmRate

 追跡性の保守が困難

手順

1.既定範囲外のサンプルレートを設定
2.エラーを観察Copyright Nagoya University 20105226

時間を考慮した利用モデルによるテスト手法の適用事例
 ISO 26262(2011年制定予定)で厳密な要求仕様が要請

開発
適用事例
 Audi AG開発での適用事例
 ECU :350状態, 42遷移, 37テスト項目
 Energy 管理：250状態, 310遷移 TUM: Timed Usage Model 状態，遷移，刺激（イベント），遷移確率，滞留時間（状態，遷移） TUMプロセス 要求仕様からTUMモデルを作成
 TUMモデルからテスト項目を自動生成
 テスト項目をEXAMテストベンチで実行してテスト結果を報告
 EXAM: Extended Automation Method

Copyright Nagoya University 201053

シーケンスベースソフトウェア仕様記述法
 システム境界を識別
シ テ 境界を識別
 すべての刺激と応答のシーケンスをシステム境界について列挙
 刺激に対してシステムが応答
 刺激には入力が対応
 応答には出力が対応
 刺激と応答の組（u‐>r）の簡約規則：将来の応答結果の等価性
 不可能イベント①環境が生成できない②システムで観測できない(参考)Stacy J. Prowell and Jesse H. Poore, Foundations of Sequence‐Based
Software Specification, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 29, NO. 5, pp.417‐429, MAY 2003
Copyright Nagoya University 20105427

テストと，BABOK：ビジネスアナリシス知識体系
運用要求知識要求変更，コンポネント調達，要求監視55

Copyright Nagoya University 2010

BABOKのステークホルダ
ステークホルダ関係■ビジネス分析者

分析

□顧客

利用

□スポンサ
□スポンサーニ
ニーズズ■分野専門家トピック□エンドユーザ■実装専門家①開発専門家②組織管理専門家③システムアーキテクト④訓練専門家
⑤ユーザビリティ専門家

管理■テスト専門家検証□サプライヤービジネス
ビジネス
ソリューション

使用、参加
構築
①開発
②組織による受容③コンポネント分解④エンドユーザによる受容⑤操作性■プロジェクトマネジャ

□規制者

対象

ソリューション

標準の定義，施行
提供参考）BABOK 2.0, IIBA 日本支部, ビジネスアナリシス知識体系ガイド, 2009
Copyright Nagoya University 2010

56

28

BABOK 2.0の知識領域とタスク
BABOK 2.0 知識領域

知識領域の用途

作業

ビジネス分析活動を定義①ビジネス分析接近計画②ステークホルダ分析主導③ビジネス分析活動計画④ビジネス分析コミュニケー
ション計画⑤要求管理プロセス計画⑥ビジネス分析
有効性管理報告

要求管理
コミュニケーション

要求矛盾，課題，変更管理とス
要求矛盾
課題 変更管理とス
コープでステークホルダと合意形
成①ソリューションと要求のスコープ管理②要求追跡性① リ
シ ンと要求のス
プ管理②要求追跡性
管理③再利用のための要求保守④要求パッケージ準備⑤要求コミュニケーション

エンタープライズ分析

ビジネスニーズを選択，洗練，明確化しソリューションスコープを定義①ビジネスニーズ定義②ビジネスニーズ充足上のギャップ決定③ソリューション接近法決定④ソリューションスコープ定義⑤ビジネスケース開発

ビジネス分析
計画監視抽出

ステークホルダのニーズを抽出し， ①抽出準備②抽出活動指揮③抽出結果の文書化
その正当性，完全性を確認④抽出結果確認

要求分析

ビジネスとステークホルダのニーズを満足するソリューションを定義①要求優先順位付け②要求体系化③要求仕様化④前提と制約の決定⑤要求検証⑥要求確認

ソリューション
評価確認

提案ソリューションとビジネスニー
ズとの適合性を評価，問題点抽出
改善案を提示①提案ソリューション評価②要求割付③組織準備判
断④移行要求判断⑤ソリューション確認⑥ソリューション有効性評価

基礎能力

ビジネス分析を適切に実行する能力①分析思考と問題解決②倫理等の行動特性③ビジネス領域知識④コミュニケーション能力⑤グループ活動能力⑥オフィスソフトウェア知識

参考）BABOK 2.0, IIBA 日本支部, ビジネスアナリシス知識体系ガイド, 2009
Copyright Nagoya University 201057

BABOK 2.0の知識領域と技法
BABOK 2.0 知識領域

技法

ビジネス分析計画監視①決定分析②プロセスモデリング③構造化ウォークスルー④受け入れ基準と評価基準の定義⑤ブレーン
ストーミング⑥インタビュー⑦組織モデリング⑧要求ワークショップ⑨リスク分析⑩シナリオとユースケース⑪ユーザーストーリ⑫スコープモデリング⑬調査とアンケート⑭見積もり⑮機能分解⑯問題のトラッキング⑰教訓プロセス⑱メトリクスとKPI⑲根本原因分析■RACIマトリクス■ステークホルダマップ■差異分析

抽出①ブレーンストーミング②文書分析③焦点グループ④インタフェース識別⑤インタビュ⑥観察⑦プロトタイピ
ング⑧要求ワークショップ⑨調査とアンケート⑩問題トラッキング

要求管理コミュニケー
ション①問題トラッキング②要求ワークショップ③構造化ウォークスルー■ベースライン化■サインオフ■カバレッジマトリック■要求の文書化■ベンダー選定のための要求

エンタープライズ分析①ベンチマーク②ブレーンストーミング③ビジネスルール分析④焦点グループ⑤機能分解⑥根本原因分析⑦文書分析⑧SWOT分析⑨ベンチマーク⑩決定分析⑪見積もり⑫インタフェース分析⑬スコープモデリン
グ⑮ユーザストーリ⑯決定分析⑰メトリクスとKPI⑱リスク分析■フィージビリティ分析■ステートメント

要求分析①決定分析②リスク分析③ビジネスルール分析④データフロー図⑤データモデリング⑥機能分解⑦組織モ
デリング⑧プロセスモデリング⑨シナリオとユースケース⑩スコープモデリング⑪ユーザーストーリ⑫受け
入れ基準と評価基準の定義⑬データディクショナリと用語集⑭インタフェース分析⑮メトリクスとKPI⑯非機
能要求⑰シーケンス図⑱状態遷移図⑲問題トラッキング⑳リスク分析⑳プロトタイピング⑳構造化ウォークスルー■MoSCoW分析■時間制限／予算制限■投票■チェックリスト

ソリューション評価確認①受け入れ基準と評価基準の定義②決定分析③ベンダのアセスメント④ビジネスルール分析⑤機能分解⑥プロセスモデリング⑦シナリオとユースケース⑧データフロー図⑨プロセスモデリング⑩焦点グループ⑪
インタビュ⑫調査とアンケート⑬組織モデリング⑭問題トラッキング⑮リスク分析⑯SWOT分析⑰データモデ
リング⑱根本原因分析■フォースフィールド分析参考）BABOK 2.0, IIBA 日本支部, ビジネスアナリシス知識体系ガイド, 2009
Copyright Nagoya University 2010

58

29

TODサイクル
変更
運用

変更

相互理解
デ
モデル
開発

変更

テスト

59

Copyright Nagoya University 2010

比較モデル論モデル

アクタ

データフロー

○

ゴール

状態遷移
アクタ関係

○

○

アクタ状況

○

○

事前／事後
状況

CATWOE

○

○

○

○

CORE

○

アクタ相互作用

○

○

機能

○

○

○

○

○

○

○

○

○

○

○

○

○

○

○

○

活動理論

入出力

○

ユースケース
シナリオ

契機・応答

○

○

○

○

○

○

○

○

規則

役割分担

○
○

○

○

○

（参考）山本修一郎、システム運用知識抽出法の提案、知識流通ネットワーク研究会、2010
http://www4.atpages.jp/sigksn/conf07/index.html
Copyright Nagoya University 20106030

運用要求の基本構造
役割分担

契機

応答

共同体

対象

活動

主体

事前状況

入力

規則

事後状況

出力

参考）山本修一郎, システム運用知識抽出法の提案, 2010
61

Copyright Nagoya University 2010

運用要求定義票
要求ID
主体

事前状況

運用規則

契機

運用手順

入力

応答

出力

関係者

対象

事後状況

役割分担

参考）山本修一郎、システム運用知識抽出法の提案、知識流通ネットワーク研究会、2010
Copyright Nagoya University 2010

6231

アクタ連携モデル
洗練
アクタ連携
クタ連携
モデル
抽出
抽入
生成
改善
現行システムTobeモデル

参考）山本修一郎、システム運用知識抽出法の提案、知識流通ネットワーク研究会、2010
63

Copyright Nagoya University 2010

サービス要求水準サービス
コンポネント

分類

0

管理

1

目的

前提，制約

責任分担

要求，制約

充足性評価

2

設計原則

インタフェース

作業分担

機能分担

分担性評価

3

アーキテクチャ

環境モデル

運用モデル

機能モデル

モデル確認

4

設計仕様

I/F設計

HCI設計

サービス仕
様

サービステス
ト

5

物理仕様

物理設計

コード

テスト

運用手順

障害報告

運用性確認

6

運用

サービス環境

サービス
運用者

水準

管理計画

監査手順

サービス確認
点検結果参考）Israel Navarro, Nancy Leveson, Kristina Lunqvist, Semantic decoupling: reducing the impact of requirementschange, Requirements Engineering, Springer, 03 June 2010
Copyright Nagoya University 201064

32

モデルベースコンポネント調達
CFP

コンポネ
ント仕様

コンポネ
ントインテ
グレータ

コンポネント仕様

顧客

コンポネントリポジトリ

コンポネント提
供者

モデル
仮想統合
コンポネント
モデル

統合
システム

仮想統合に適合したコンポネントを
調達

コンポネ
ント

（参考）Lewis, B., Architectural Computer System Model-Based Engineering with AADL, Sept. 2008, SEI
Copyright Nagoya University 201065

4階層要求監視フレームワーク
階層

名称

説明

1

応用層

デバグ，検証，確認，業務活動監視，進化

2

表示層

表示
ツール

3

4

モデル層

診断モデル，ユーザモデル，モデルリポジトリ

イベント層

イベント・リポジトリ
イベント・フィルタ
イベント・ソース
イベント（ソフトウェア，CPUなど）

参考）William Robinson, A roadmap for comprehensive requierments monitoring, IEEE Computer, May, 2010, pp.64‐72.
Copyright Nagoya University 2010

66

33

まとめ
 なぜ独立検証なのか
 IEEE Std. 1012-2004 IV&V（独立検証確認）
 独立検証の先進事例
 テストと開発、運用

 相互理解モデル

Copyright Nagoya University 2010

67

参考文献
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.

IEEE Std. 1012‐2004 Software Verification and Validation
IEEE Std. 829‐2008 Standard for Software and System Test Documentation
NIST, Planning report 02‐3, The Economic Impact of Inadequate Infrastructure for Software Testing, May 2002
Israel Navarro, Nancy Leveson, Kristina Lunqvist, Semantic decoupling: reducing the impact of requirements change,
Requirements Engineering, Springer, 03 June 2010
Leveson,L
N.G.,
N G SAFEWARE – System
S
SafetyS f andd Computers,
C
Addison
Addi
Wesley,W l 1995
経済産業省，重要インフラ情報システム信頼性研究会 報告書，2009, IPA
山本修一郎、独立検証確認と形式手法がもたらすソフトウェア開発プロセスの改革, IPA SEC Journal, 2010
宇宙航空研究開発機構，~究極の高品質ソフトウェア開発プロセスをめざして~ベストプラクティス調査報告書，経済産業省，プ
ロセス改善研究部会，2007, http://sec.ipa.go.jp/reports/20070514/JAXA.pdf
栗田太郎，モバイルFeliCaのソフトウェア開発における品質確保のための構造と実践～抽象度の制御やコミュニケーションの活性化に向けて，情報処理学会デジタルプラクティス，Vol.1, No.3, 2010, http://www.ipsj.or.jp/15dp/Vol1/No3/dp0103.html
田倉聡史，上流工程での品質確保のための発注者責任，SEC Journal, Vol.6, No.2, 2010
M.Panis, Successful Deployment of Requirements Traceability in a Commercial Engineering Organization…Really , RE2010,
pp.303‐307, 2010
S.Siegl, K‐S.Hielscher, R.German , Model Based Requirements Analysis and Testing of Automotive Systems with Timed
Usage Models,Models RE2010,
RE20 0 pp.345‐350,
pp 34 3 0 20
2010
0Stacy J. Prowell and Jesse H. Poore, Foundations of Sequence‐Based Software Specification, IEEE TRANSACTIONS ON
SOFTWARE ENGINEERING, VOL. 29, NO. 5, pp.417‐429, MAY 2003
山本修一郎、システム運用知識抽出法の提案、知識流通ネットワーク研究会、2010
BABOK 2.0, IIBA 日本支部, ビジネスアナリシス知識体系ガイド, 2009
William Robinson, A roadmap for comprehensive requirements monitoring, IEEE Computer, May, 2010, pp.64‐72.
Lewis, B., Architectural Computer System Model‐Based Engineering with AADL, Sept. 2008, SEI

Copyright Nagoya University 20106834