NTTデータ
技術開発本部
副本部長
山本修一郎
概要
これまで2回にわたってSSMを紹介してきた[1][2][3]。今回はSSMによる情報システム分析プロセスの内容を「システム仕様の分析学」第6章[1]に基づいて紹介し、関連するシステム分析手法と比較する。
基本概念
情報とデータ
SSMでは、情報は処理対象となるデータについての意味を与えるものであり、データの意味はデータが支援する人間活動によって定められる。業務手順を効率化するシステムを実現するために、特定の作業手順に従って処理対象となるデータを定義する。これに対して情報は価値のある人間活動システムを支援するために、組織のコンセプトにとって望ましいコミュニケーションとコントロール(モニタリング)を定義する。このようにSSMではデータとその意味を情報として明確に区別して定義することで、論理的な人間活動では情報を扱い、情報システムはデータを処理する手順を与えると考える(表1)。これにより「現実世界」の情報システムを「現実世界についてのシステム思考」の概念モデルによって論理的に分析することができる。
分類 | 目的 | 用途 | 説明 |
---|---|---|---|
情報 | 価値のある人間活動システムを創造 | コミュニケーション コントロール | 組織のコンセプトを具体化することで、活動を支援するための情報を定義 |
データ | 業務手順を効率化するシステムを実現 | 処理 | 特定の作業手順に従って処理対象となるデータを定義 |
マルティーズクロス
図1 マルティーズクロスの構成
SSMでは、前回までに紹介した一般的な人間活動だけを対象とするだけではなく、データ処理システムにも適用することができる。しかし、そのためにはデータ処理手順に関する新たな表現法として「マルティーズクロス」が必要になったのである。マルティーズクロスは図1に示すようにデータと情報の観点から人間活動とデータ処理手順との関係を比較するために考案された手法である。マルティーズクロス図の上部は入力情報を出力情報に変換する活動を記述する。この活動は概念モデルの基本タスクに対応している。図の下部ではデータ処理レベルにおける入力データの出力データへの変換を記述する。このデータ処理手順は、既存のデータ処理システムに対応する。図の中央には情報カテゴリーを記述する。図の左右で同じ情報を配置する。図の上下左右の行列は以下の意味を持つ。
- 左上行列:
- 入力情報と基本タスク(活動)の関係
- 右上行列:
- 出力情報と基本タスク(活動)の関係
- 左下行列:
- 入力データとデータ処理手順の関係
- 右下行列:
- 出力データとデータ処理手順の関係
マルティーズクロスを用いることにより、データ処理システムを概念モデルに対応付けることができるようになる。以下のような分析ができる。
- 活動に対する必要な情報が存在しない。
- 複数の列で参照される情報には対応するデータ処理システムを用意する。
- 複数のデータ処理手順が同じデータを入出力していれば、手順に重複があるかもしれない。あるいはデータが同名意義語であるかもしれない。
- 活動が必要とする入力情報をデータ処理手順の出力が十分に提供しているか。
SSMによる情報システム分析
以下ではマルティーズクロスを用いたSSMによる情報システム分析手順の概要を示す(図2)。
図2 SSMによる情報要求分析
【ステージ1】状況理解
関心対象となる組織について活動を記述するために、組織のおかれた状況を理解できるように現行活動の課題を抽出する。
【ステージ2】基本定義を作成
抽出した組織の課題に対して論点分析型による基本定義を作成する。
【ステージ3】基本タスク概念モデルを作成
基本定義に対して基本タスクとその依存関係を明らかにして概念モデルを作成する。この過程で現実状況との比較により概念モデルについて合意を形成する。
【ステージ4】情報カテゴリを作成
基本タスクモデルの活動(基本タスク)について、活動の入力情報、活動の出力情報、活動のパフォーマンスを制御するために必要な評価尺度を明らかにする。この過程でデータ間の階層関係をデータモデルとして定義する。
【ステージ5】概念レベル情報フローを作成
活動と入出力情報に基づいて、概念レベルの情報フローを定義する。
【ステージ6】概念レベルマルティーズクロスを作成
概念レベル情報フローに基づいて、マルティーズクロスの上部を作成する。
【ステージ7】データレベルマルティーズクロスを作成
既存のデータ処理システムについて、入出力データをマルティーズクロスの入出力情報と対応付けることにより、マルティーズクロスの下部を作成する。もし、必要なデータ処理システムが存在しなければ、この過程で作成すべきデータ処理システムをマルティーズクロスのデータ処理手順に追加定義する。このとき新規開発すべきデータ処理システムとその入出力データがデータレベルマルティーズクロスによって定義される。
また既存のデータ処理システムの入出力データに対応する情報に着目することで、データ処理システムを扱うための活動を具体化する。これらの活動によりデータ処理システムが入出力するデータの意味を情報としてどう扱うのかを定義することができる。
【ステージ8】情報フローを組織の役割フローに対応付ける
基本タスクモデルの活動を組織の役割に対応付けることで、組織活動とそれが扱う情報ならびに、データ処理システムの関係を定義する。
- 60:要求とアーキテクチャ
- 61:要求と保守・運用
- 62:オープンソースソフトウェアと要求
- 63:要求工学のオープンな演習の試み
- 64:Web2.0と要求管理
- 65:ソフト製品開発の要求コミュニケーション
- 66:フィードバック型V字モデル
- 67:日本の要求定義の現状と要求工学への期待
- 68:活動理論と要求
- 69:ビジネスゴールと要求
- 緊急:今、なぜ第三者検証が必要か
- 71:BABOK2.0の知識構成
- 72:比較要求モデル論
- 73:第18回要求工学国際会議
- 74:クラウド時代の要求
- 75:運用要求定義
- 76:非機能要求とアーキテクチャ
- 77:バランス・スコアカードの本質
- 78:ゴール指向で考える競争戦略ストーリー
- 79:要求変化
- 80:物語指向要求記述
- 81:要求テンプレート
- 82:移行要求
- 83:要求抽出コミュニケーション
- 84:要求の構造化
- 85:アーキテクチャ設計のための要求定義
- 86:BABOKとREBOK
- 87:要求文の曖昧さの摘出法
- 88:システムとソフトウェアの保証ケースの動向
- 89:保証ケースのためのリスク分析手法
- 90:サービス保証ケース手法
- 91:保証ケースのレビュ手法
- 92:要求工学手法の再利用
- 93:SysML要求図をGSNと比較する
- 94:保証ケース作成上の落とし穴
- 95:ISO 26262に基づく安全性ケースの適用事例
- 96:大規模複雑なITシステムの要求
- 97:要求の創造
- 98:アーキテクチャと要求
- 99:保証ケース議論分解パターン
- 100:保証ケースの議論分解パターン[応用編]
- 101:要求発展型開発プロセスの事例
- 102:参照モデルに対する保証ケース
- 103:参SEMATの概要
- 104:参SEMATの活用
- 105:SEMATと保証ケース
- 106:Assure 2013の概要
- 107:要求の完全性
- 108:要求に基づくテストの十分性
- 109:システムの安全検証知識体系
- 110:機能要求の分類
- 111:IREB
- 112:IREB要求の抽出・確認・管理
- 113:IREB要求の文書化
- 114:安全要求の分析
- 115:Archimate 2.0のゴール指向要求
- 116:ゴール指向要求モデルの保証手法
- 117:要求テンプレートに基づく要求の作成手法
- 118:ビジネスゴールのテンプレート
- 119:持続可能性要求
- 120:操作性要求
- 121:安全性証跡の追跡性
- 122:要求仕様の保証性
- 123:システミグラムとドメインクラス図
- 124:機能的操作特性
- 125:セキュリティ要求管理
- 126:ソフトウェアプロダクトライン要求
- 127:システミグラムと安全分析
- 128:ITモダナイゼーションとITイノベーションにおける要求合意
- 129:ビジネスモデルに基づく要求
- 130:ビジネスゴール構造化記法
- 131:保証ケース導入上の課題
- 132:要求のまとめ方
- 133:要求整理学
- 134:要求分析手法の適切性
- 135:CROS法の適用例
- 136:保証ケース作成支援ツールの概要