ipa/sec 要求発展型開発wg 主査名古屋大学情報連携統 … ·...

Copyright Prof. Dr. Shuichiro Yamamoto 2013 1

山本修一郎

IPA/SEC 要求発展型開発WG 主査名古屋大学情報連携統拢本部情報戦略室

要求シンポジウム 2013

概要 ISO/IEC 29148-2011

要求発展型開発ワーキング

DEOS研究プロジェクト

要求変化への対応プロセス

要求が変化する９つの理由


Systems and software engineering —Life cycle processes —

Requirements engineering


要求管理要求が静的であることはまれである

開発管理の観点から, 要求を確定することが望ましいけれども,それが可能になるのはまれである．


参考） ISO/IEC/IEEE 29148:2011, Systems and software engineering —Life cycle processes — Requirements engineering, 6.5

要求属性要求属性説明

識別子要求を一意に識別

優先順位要求の優先順位を定義

依存関係要求間の依存関係を記述．修正時の影響範囲を特定．

リスクリスク分析手法を用いて，潜在的な経済損失，事業機会損失，信用失墜，環境への影響，安全性，健康問題，法制度などへの帰結を判別

出典要求の発案者

根拠要求を確立するための理由

難易度要求を実現する上での難易度

種別要求意図と要求が表現する特性の種類．機能要求，性能要求，ユーザビリティ要求，インタフェース要求，設計制約，プロセス要求，非機能要求，品質要求，ヒューマンファクタ要求


ISO/IEC/IEEE 29148:2011

ステークホルダの意図

ニーズ，ゴール，目標

運用概念

システム運用概念

組織の観点

システムの観点

ステークホルダの公式要求

ステークホルダ要求工学

システム要求システ

ム要求工学

参考） ISO/IEC/IEEE 29148:2011, Systems and software engineering —Life cycle processes — Requirements engineering, 5.2.3


ソフトウェア要求工学

ソフトウェア要求

ステークホルダ要求(StRS)の構成例章節

1. はじめに

1.1 ビジネスの目的 1.2 ビジネスの範囲 1.3 ビジネスの概要 1.4 定義 1.5 ステークホルダ

2. 参考文献

3. ビジネスマネジメント要求 3.1 ビジネス環境 3.2 ゴールと目標 3.3 ビジネスモデル 3.4 情報環境

4. ビジネス運用要求

4.1 ビジネスプロセス 4.2 ビジネス運用ポリシーと規則 4.3 ビジネス運用制約 4.4 ビジネス運用モード 4.5 ビジネス運用品質 4.6 ビジネス構造

5. ユーザ要求

6. 提案システムの概念 6.1 運用概念 6.2 運用シナリオ

7 プロジェクトの制約

8. 付録 8.1 Acronyms and abbreviations


システム要求SyRSの構成例章節

1. はじめに

1.1 システムの目的 1.2 システムの範囲 1.3 システム概要 1.3.1 システムのコンテクスト 1.3.2 システム機能 1.3.3 ユーザ特性 1.4 定義

2. 参考文献

3. システム要求

3.1 機能要求 3.2 操作性要求 3.3 性能要求 3.4 システムインタフェース 3.5 システム運用 3.6 システムモードと状態 3.7 物理特性 3.8 環境条件 3.9 システムセキュリティ 3.10 情報管理 3.11 ポリシーと法制度 3.12 システムライフサイクル継続（ sustainment） 3.13パッケージ化, ハンドリング, 出荷，配送

4. 検証

5. 付録前提条件と依存関係 Acronyms and abbreviations


ソフトウェア要求仕様SRS構成例章節

1. はじめに

1.1 目的 1.2 範囲 1.3 製品概要 1.3.1 製品展望 1.3.2 製品機能 1.3.3 ユーザ特性 1.3.4 限界 1.4 定義

2. 参考文献

3. 具体要求

3.1 外部インタフェース 3.2 機能 3.3 操作性要求 3.4 性能要求 3.5 論理データベース要求 3.6 設計制約 3.7 ソフトウェアシステム属性 3.8 支援情報

4. 検証

5. 付録 5.1 前提条件と依存関係 5.2 Acronyms and abbreviations


要求構文の例

要求構文の型例

[条件] [主体] が[対象]を[制約] [活動]する必要がある．

信号x を受信したとき [条件], システムが [主体] 信号 xの受信ビットを [対象] 2秒以内に[制約]設定 [活動]する必要がある.

[条件] [活動または制約] は[値]である必要がある．

海の状態が 1のとき [条件], レーダーシステムが目標を検知すべき範囲は [活動または制約] 100 nautical マイル [値]である.必要がある．

[主体]が [値条件]で[活動] する必要がある．

請求書システムが[主体], 昇順 [値条件]で，支払いが保留中の顧客請求書を表示[活動]する必要がある.

参考） ISO/IEC/IEEE 29148:20115.2.4 Requirements construct 注意）日本語構文に合わせるために，助詞を補うとともに，語順を入れ替えている


要求発展型開発とは


ビジネスニーズや社会システムのすばやい変化に対応できる情報システムの必要性が増加

ベースとなる既存の情報システムに改良を加えることにより，新たなニーズに応える形態が増加

容易に保守できる情報システムを構築する必要性が増加

【背景】

②すでにあるもの再利用で変化に追随

①迅速な変化への対応技術を採用

④ベースとなる情報システムの一部にすでにある仕組みを利用

③変化が緩やかなベースとなる基盤と，変化を想定した部品群を備えて変化に対応

⑥ テスト済みで保証されたサービスの利用

⑤ 影響範囲が特定された部品の取り換えや修正対応

新しいシステム基盤への移行

要求変化へ迅速に対応

【２つの潮流】【対応】

WG活動概要


年度活動概要

２０１０保守性の高い情報システムの構築技術に関する調査

２０１１要求の変化に対応する情報システム構築技術の適用に関する調査

２０１２環境の変化に対応する情報システム構築技術の調査および課題の整理

参考） IPA/SEC,要求発展型開発WG 2011年度活動報告書,2012 IPA/SEC,要求発展型開発WG 2012年度活動報告書,2013(予定)

【要求発展型開発WG委員リスト】敬称略


氏名所属

主査山本修一郎国立大学法人名古屋大学

委員秋山浩一富士ゼロックス株式会社

委員小林茂憲日本電気株式会社

委員斎藤忍株式会社エヌ・ティ・ティ・データ

委員白坂成功慶應義塾大学大学院

委員成瀬泰生富士通株式会社

委員古川正伸株式会社東京証券取引所

委員山本久好日本アイ・ビー・エム株式会社

委員鷲崎弘宜学校法人早稲田大学

オブザーバ青木保壽富士通株式会社

オブザーバ赤埴淳一日本電信電話株式会社

オブザーバ宮本祐子独立行政法人宇宙航空研究開発機構

WGスコープの発展


参考）ISO/IEC/IEEE29148

市場動向法令と規則法的義務社会的責任技術基盤労働者人口競合製品標準と仕様公共の文化物理環境自然環境

ポリシー手順標準仕様ガイドライン領域技術組織文化

プロセス制約・方針規則運用モード品質業務構造

システム運用

システム要求

システムソフトウェア

ソフトウェア要求

事業水準ステークホルダ要求

運用水準ステークホルダ要求

２０１０年度２０１１年度２０１２年度

業務運用組織／事業外部環境

プロセス制約・方針規則品質運用構造

制約・方針品質アーキテクチャ

制約・方針品質アーキテクチャ

組織

2012年度の取り組み

ステークホルダ要求に影響を不える

「環境の変化」に着目することにより，

環境対応について議論


外部環境

内部環境

変化

丌確実な未来の分類

レベル未来説明

１【確実に見通せる未来】 A Clear-Enough Future

ある程度の正確さで未来を予測可能

２【可能性が選択できる未来】

Alternate Future 異なる複数のシナリオとして未来を予測可能

３【範囲が限定できる未来】

A Range of Future 起こりうる未来を一定範囲内で特定可能

４【まったく読めない未来】

True Ambiguity

さまざまな丌確実性が相互作用し予測丌能レベル４の状況は稀であり、時間が経過するにつれ、他のレベルに移行


参考）ヒュー・コートニー,丌確実性時代の戦略思考, DIAMONDハーバード・ビジネス・レビュー, July 2009

環境変化への姿勢


環境ソフトウェア

適応

形成

留保変化

参考）ヒュー・コートニー,丌確実性時代の戦略思考, DIAMONDハーバード・ビジネス・レビュー, July 2009

主な検討内容環境適応モデル

情報システム開発における環境適応モデル

アシュアランスケース

サービスデザイン

環境変化に対応するシステムに関する課題


VSM

TOGAF－ADM

ITIL

DSPL

DEOS

要求変更管理


VSMの再帰的構成


実行

管理

調整

監督

ポリシー（S5）組織全体方針の決定により，現在と未来ならびに，部分全体を均衡

インテリジェンス(S4) 外部環境の変化に対しS3との相互作用により適応戦略的意思決定と危機管理

コントロール(S3) S1を制御、S2を監督システムの資源配置を維持責任体制の構築と制御

コーディネーション(S2) S1及びシステム間を調整するための情報チャネル

インプリメンテーション(S1) 対象システムの基本活動環境とのインタフェースを持つ

S5

S4

S2 S3

S1

345 2

345 2 1

将来環境

現在のシステム環境

局所環境

局所環境

適応

方針管理

外部環境

1

参考）Stafford Beer, DIAGNOSING THE SYSTEM For Organisations, 1985

ADMフェーズと技法の関係

22

アーキテクチャ変更管理

初期フェーズ

情報システムアーキテクチャ

テクノロジアーキテクチャ

実装ガバナンス

アーキテクチャ作成依頼

要件管理

ケイパビリティベースプランニング

ビジネスシナリオ変革即応性評価ビジネス要件・制約

ビジネスアーキテクチャ

アーキテクチャ策定作業計画

アーキテクチャコントラクトアーキテクチャ準拠性

アーキテクチャ要件仕様アーキテクチャ定義文書

移行計画コスト分析ビジネス価値割当

アーキテクチャビジョン

移行プランニング

機会とソリューション

再利用BB

SBB

ABB

トランジションアーキテクチャ

モニタリングビジネス価値最大化

アーキテクチャ作成依頼

アーキテクチャプリンシプル

再利用可能ビルディングブロック

アーキテクチャ

ソリューション

Copyright Prof. Dr. Shuichiro Yamamoto 2013 参考) THE Open GROUP, TOGAF V.9 A Pocket Guide, 2008

ITILのモニタ・コントロールループ「アウトプットをモニタリングし、そのアウトプットを事前に定義された基準と比較し、その比較に基づいて適切な処置を行う」

23

基準

コントロール比較

モニタ

活動入力出力

基準


モニタ

活動入力出力

基準


参考）ITIL2011用語集，要求発展型開発WG 2012年度活動報告書

DEOSプロセス


障害対応サイクル

変化対応サイクル

テスト検証設計実装ステークホルダ合意

要求抽出・リスク分析

合意形成開発

障害対応

D-Case D-Script

合意記述データベース

通常運用

予兆検知・障害発生

目的変化・環境変化

説明責任遂行

原因究明

迅速対応

未然回避

ディペンダビリティケース

参考）Tokoro, Eds., Open Systems Dependability, CRC Press, 2012

動的ソフトウェアプロダクトライン

受動

実体領域

能動

監視分析

実行計画

監視分析

実行計画

領域知識実体知識

製品

環境

製品モデル

コンテクストモデル

変化モデル

参照アーキテクチャモデル

参照監視分析知識

参照計画実行知識

25 Copyright Prof. Dr. Shuichiro Yamamoto 2013

M A

E P

K

M A

E P

K

参考)Bencomo, N.; Hallsteinsen, S.; Santana de Almeida, E., A View of the Dynamic Software Product Line Landscape, Vol. 45 , No.10, Computer,pp.36-41, 2012

VSMによる環境変化対応プロセスの比較


VSM TOGAF ADM DEOSプロセス ITIL MAPE-K

SIDA ISO 9004:2009

【S1】基本活動

環境インタフェース実装ガバナンス開発・通常運用活動 E 行動プロセス運用管理

【S2】情報調整チャネルモニタリング目的・環境変化予兆障害検知

モニタ M 感知監視，測定

【S3】 S1制御．S2監督．責任体制構築と制御

アーキテクチャ委員会

変化対応サイクル障害対応サイクル

コントロール

A 行動資源運用管理分析，レビュー

【S4】環境変化適応．戦略的判断と危機管理

機会と解決移行計画

説明責任遂行障害対応

比較 K 解釈持続的成功のための運営管理

【S5】部分と全体方針，現在と未来のバランス

アーキテクチャビジョン

要求マネジメント合意形成

基準 P 決定戦略及び方針

ディペンダブル・オペレーティングシステム


http://www.crest-os.jst.go.jp/index.html

http://www.crest-os.jst.go.jp/index.html

DEOSプロジェクト・ロードマップ


「発展型DEOSプロセス・アーキテクチャの研究」

名古屋大学の研究実施項目

D-Case実証実験

発展型DEOSプロセス開発

発展型DEOSアーキテクチャ開発

国際実証実験のスキーム整備


D-Caseの例サービス運用レベルのマネジメント


【根拠】主張が成立する理由

【説明】上位の主張を下位の主張に分解して説明

【主張】

【前提条件】

ゴール指向とディペンダビリティケース

項目ゴール指向要求工学ディペンダビリティケース

用途システム要求の獲得システム要求の保証

分解目的手段展開前提と証拠への主張の説明分解

関係の方向下位から上位上位から下位

分解の種類 AND分解とOR分解なし

分解の属性肯定的と否定的なし

関係の理由分解関係に対する非機能要求説明分解


最近の活動状況


D-Case実証評価研究会（２０１２年９月設立）

D-Case講習会・説明会

Open Group DEOS 標準化活動

ET2012展示、講演

2nd International Workshop on Open Systems Dependability

OMG 消費者機械標準化活動

D-Case Editorモジュール拡張試験実装

研究発表(DSW, KBSE研究会, 国際会議など)

要求工学 http://www.bcm.co.jp/site/youkyu/


D-Case 入門松野，高井，山本， 2012


編内容執筆者頁数

背景編

オープンシステム・ディペンダビリティ要求工学概論ディペンダビリティ標準規格システムリスク分析

松野山本高井山本

１４１６１２１６

基礎編アシュアランスケース概論 D-Case作成法

松野松野

１０２６

応用編 D-Case演習議論分解パターン D-Caseエディタの使い方

山本山本松野

１５１５４

http://www.dcase.jp/


2nd WOSD


GSNの提案者 Tim Kellyの講演@ダラス・テキサス、１１月２７日

現代のシステムリスク


種別従来開発リスク

顧客対応リスク対象外訴訟リスク

ビジネス継続性リスク

対象外コミュニケーションリスク

システムリスク要求，設計，実装，

試験独立検証確認なし

開発活動の妥当性証明リスク

金融系システム障害、故障信号に丌具合

サーバ主要機

サーバ予備機

②正常信号途絶

④停止命令

①メモリ障害発生

③自動起動

⑧停止信号発信丌能

⑤停止 ⑦丌具合

⑨正常動作丌能

参考）日経新聞電子版，2012/2/10 2:00

予備機立上確認プログラム ⑩自動切り替え機能の

動作状況を誤認識

運用担当者

⑥予備機立上確認

⑪手動切り替え遅延

ハードエラー

ソフトエラー

運用エラー

40 Copyright Prof. Dr. Shuichiro Yamamoto 2013

要求変化対策の経済効果


経費

要求変化対策貧弱豊富

経済的損失

要求変化対策経費

適切

要求変化対応の限界

プロダクト（システム，ソフトウェア）だけで

要求変化に対応しようとしても限界がある

プロセス（運用）についても

要求変化に備える必要がある


システム変化対応D-Case


正常系

前提条件

例外系丌測の事態への対応

運用時要求マネジメント

要求状態管理モデル

44

抽出合意

逸脱通常運用

合意形成

実装

目的変化／環境変化

修正

迅速対応通常対応原因分析

通常運用範囲の逸脱

①

②

①目的環境変化対応サイクル ②障害対応サイクル

開発時要求マネジメント

合意形成

削除追加

Copyright Prof. Dr. Shuichiro Yamamoto 2013

Copyright © 2013 FUJITSU LIMITED

ｻﾌﾟﾗｲﾔ管理

現場で発生する要求への対応

継続的サービス改善

現場の要求現場の要求現場の要求

対応手順が明確に定義されているもの

サービスの維持や復旧を目指すもの

サービス内容変更を必要とするもの

要求実現

サービスレベル管理

運用活動(機能)

ｾｷｭﾘﾃｨ管理継続性管理可用性管理

インシデント管理

問題管理

ｷｬﾊﾟｼﾃｨ管理

サービスストラテジ

サービスデザインサービス

オペレーション

サービストランジション

現場の要求現場の要求現場の要求

要求変化の検知/収集

要求変化への対応

事業関係管理

サービスデスク

イベント管理

要求構文を用いた要求変更管理

要求構成要素が変化した場合，対応する要素を含む要求と，その要求に含まれる他の要求構成要素を特定することにより，要求変更の影響範囲を分析できる


要求

主体活動対象

条件値条件値制約

要求変更管理


変更管理プロセス

変化水準プロセス

ISO/IEC/IEEE 29148

要求ベースラインの変化要求集合要求構成管理

要求状態管理要求の逸脱要求要求状態遷移

要求構文を用いた変更管理

要求記述要素の変化要求要素変化要求追跡

2階層適応型MAPE－K

環境と製品の変化コンポネント MAPE-K

発展と変革現状と将来のシステムの差異システム差異分析

TOGAFのADM 現状と将来のエンタープライズアーキテクチャの差異

システム集合 ADMサイクル

要求変化の次元


変化要素追跡要求状態管理要求構成管理

システム集合システム集合変化要素追跡

システム集合状態管理

システム集合構成管理

システムシステム

変化要素追跡システム状態管理

システム構成管理

コンポネントコンポネント変化要素追跡

コンポネント状態管理

コンポネント構成管理

要求が変化する９つの理由


要求が変化する９つの理由 1. 外部環境の変化

2. 内部環境の変化

3. 要求定義完了基準の曖昧性

4. 知識の限界

5. 論証文化の丌足

6. 人工物の境界原理

7. 残余リスク

8. コミュニケーション丌足

9. プロジェクトの多様性


要求変化の構造


変化

顧客コミュニケーション

要件リスク

要件レビュ

要件マネジメント

要件保証

環境

要求

対策

対策

原因

手段

手段

手段

管理

管理

手段

原因

①外部環境の変化 ②内部環境の変化

⑦残余リスク

⑤論証文化の丌足

③要求定義完了基準の曖昧性

⑧コミュニケーション丌足

④知識の限界

⑥人工物の境界原理

⑨プロジェクトの多様性

本質的なこと（根幹）だけが大事「剣法には固定した型というものはない，というのが武蔵の考えであった．

相手に応じて常に変化するというのが武蔵の考えで，

だから武蔵は型にとらわれた柳生流を非難していた．

柳生流には大小六十二種の太刀数があって，

変化に応じたあらゆる太刀をあらかじめ学ばせようというのだが，

武蔵はこれを否定して，

変化は無限だからいくら型を教えても駄目で

あらゆる変化に応じる根幹だけが大事だと言って，その形式主義を非難したのである」


出典）坂口安吾, 青春論, 青空文庫, http://www.aozora.gr.jp/

参考文献 [1] ISO/IEC/IEEE 29148-2011, Systems and software engineering —Life cycle processes — Requirements engineering, 2011 [2] ヒュー・コートニー,不確実性時代の戦略思考, DIAMONDハーバード・ビジネス・レビュー, July 2009 [3] Stafford Beer, DIAGNOSING THE SYSTEM For Organisations, 1985 [4] THE Open GROUP, TOGAF V.9 A Pocket Guide, 2008 [5] ITIL2011用語集 [6] IPA/SEC, 要求発展型開発WG 2011年度活動報告書,2012 sec.ipa.go.jp/reports/20120426/20120426.pdf [7] IPA/SEC, 要求発展型開発WG 2012年度活動報告書,2013(予定) [8] Tokoro, Eds., Open Systems Dependability, CRC Press, 2012 [9] Bencomo, N.; Hallsteinsen, S.; Santana de Almeida, E., A View of the Dynamic Software Product

Line Landscape, Vol. 45 , No.10, Computer,pp.36-41, 2012 [10] DEOS研究領域, http://www.crest-os.jst.go.jp/index.html [11] 山本修一郎, 要求工学, http://www.bcm.co.jp/site/youkyu/ [12] 松野裕，，高井利憲，山本修一郎，D-Case 入門，～ディペンダビリティ・ケースを書いてみよう～，ダイテックホールディング，2012

[13] D-Case, http://www.dcase.jp/ [14] 日経新聞電子版，金融系システム障害、故障信号に不具合, 2012/2/10 2:00 [15] 坂口安吾, 青春論, 青空文庫, http://www.aozora.gr.jp/


ipa/sec 要求発展型開発wg 主査 名古屋大学情報連携統 … ·...

Documents

ipa/sec 要求発展型開発wg 主査名古屋大学情報連携統 … ·...