as-isシステム分析は入出力から始めよ
DESCRIPTION
オープンコミュニティ「要求開発アライアンス」(http://www.openthology.org)の2011年2月定例会発表資料です。 Open Community "Requirement Development Alliance" 2011/2 regular meeting of the presentation materials.TRANSCRIPT
As-Is ステム分析は入出力から始めよ
既存システムの全体像を把握する
株式会社バリューソース 神崎善司
わたしは
㈱バリューソース 代表取締役 社長
神崎 善司
はてな:good_way
twitter:zenzengood
普段は 要件定義のコンサルテーション
オブジェクト指向やUMLのセミナー開催
要件定義ツール「要件のツボ」開発
経験 20年ほど前からオブジェクト指向を中心にシステム開発全般のコンサルティングを行う
10年ほど前から上流工程を中心としたコンサルティングを行う
その経験を活かしてモデルを使った要件定義の手法をまとめる
大規模システムの保守性向上のための既存システムの分析を行う
要件のツボ
http://www.vsa.co.jp/kaname
既存システムを取り巻く状況は
ドキュメントがない
ドキュメントは最新ではない
ソースが最新かどうか分からない
さまざまな言語で開発されている
聞いたことがない言語である
アーキテクチャが明確ではない
システムの利用者 普段使っている機能だけ知っている
なんでこうなっているのか分からない
問題のはじまり
新システムの企画段階で
今のうちに既存のシステムを調べよう
システムのドキュメントを再度作成する!
よく起こること
システムのドキュメントを整理する → プログラム単位のドキュメント
数千本のプログラムについて細かい仕様を調べる
複数の担当者が担当を割り振られ黙々と作る
キングファイルが積み上がる
プログラム単位のドキュメント化
混沌とした一枚岩のシステムをプログラム単位で調べてもシステム化の判断には役に立たない
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
PrgPrg
Prg
Prg
そんな現場では
何を書くんですか?
どの範囲まで書くんですか?
どの粒度で書くんですか?
一ヶ月後
いつまでやるんですか?
やれと言われればやりますが。 ??????
目的が曖昧なままスタートしたので終わるタイミングが分からない
そして…
As-Isの資料作成がいつのまにかTo-Beの資料作成に
この部分は君が詳しいから次期システムもここは君が担当してくれ
細かいことは分かるけど、次期システムについて判断出来ない
結局方向性のない焼き直しシステムができあがる
データ構造の見直しは行われず 保守性はいっこうに改善しない
迷信
保守中のバグは新システムでは再現させたくない 何でシステムで同じようなバグが出るの?
既存のシステムとほとんど同じだから… 「ほとんど」とはどこですか? ?????
「細かいことを知っている」は「システムをよく知っている」ことにならない 結局システムは何をしているのですか? ?????
ほとんど同じ
イメージ 実際は
どうすりゃいい
何を調べたいのか
現在のシステムはこうなっている
次のシステムの方向性はこうだ!
だから次のシステムはこうする
必要なことを判断出来る情報が重要!
判断するためには何を何のためにが分かる必要
がある
つまり つじつまのあう説明ができる
目指すべきは
プログラムに左右されずにシステムが何を行っているかを明らかにする
システムにとって大事なことは
何ができればいいのか
どう整合しているのか 主要な機能は?
主要な情報は?
機能と情報の関係は?
そこで…
本質を捉えるためにモデリングだ
えっ モデリング ほんとか?
既存のシステムを調べているんだ
モデルと既存のシステムの関係は?
既存のシステムは綺麗ではない
綺麗なモデルは現実と離れていく
綺麗なモデルは結局何を表しているんだ!
どうモデルを活かす
現実とつながりながら現実の混沌に影
響されずに整理する
そのためには…
前提
細かなルールにこだわらなくていい
既存システムの仕組みは無視していい
既存のシステムとは
様々な制約によってプログラムが混沌としている
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
何を捉える
システム境界とデータを捉える
だから~ 情報のない中でどうやってやるんですか?
ドキュメントがないと言っても
たいてい以下のドキュメントはある テーブル定義書
電文レイアウト
ファイル交換のファイル定義書
保守されているシステムについては
データと他システムにつながる部分の情報はある
システムをよく知らないといっても
この機能はこういうことを行っている
ここでこうするとあそこに影響する
こうしたいときはここをこうすればいんだよ
制約の説明
ここは時間がなくてこうしちゃったんだ!
この時代はこういうルールだったんだ
具体的にどうするの?
分析
分析方針
集めやすい情報から集める
抜けたピースを探す
集めた情報の特徴から切り込む
分類する
関係をつかむ
現実とつながりながら現実の混沌に影響されずに整理する
モデル入力情報タイミング
機能
機能
機能
機能
機能
機能
出力情報タイミング
既存システム
Prg
Prg
Prg
Prg
Prg
Prg
物理制約 時間制約 開発時制約
Prg
Prg
Prg
Prg
Prg
Prg
システム境界のレベルで一致させる
入力情報タイミング
出力情報タイミング
認識する情報
入出力
画面 稼働しているシステム
帳票 〃
通信 電文レイアウト
データ交換
File Fileレイアウト
DB テーブル定義書
データ
テーブル定義書
ファイルレイアウト
システムの入出力を捉える
データ集約的なシステム
入れポン 出しポン
入力と出力を把握できればいい
システム境界を捉える
画面
システム
受信
送信
DB
File
送信
受信
帳票
データ交換
データ交換
通信
システムが関心をもつ状態を捉える
状態監視的なシステム 監視対象があって今を意識 一連の手続きの管理 プロセス管理、ロングトランザクション管
理
状態としてルールを整理
ユーザが認識している状態を把握するために 画面上の情報 オペレータが画面の振る舞いとして認識しているもの テーブル上の区分やフラグなど テーブルの関係 ビジネス上の概念
状態の遷移として整理
状態を振る舞いのルールとする
A画面
システム
受信
送信
DB
A_File送信
受信受信
送信
解約待ち
開始済み開始前A画面
B画面
A_File
B_File
状態 状態XXX / YY機能
入出力をイベントで統一的に扱う
システム境界をイベントとして扱う
ポイント
画面やデータ交換は実体に合わす
画面
受信
送信
DB
File
受信
送信
システム画面
受信
送信イベント
隠れた情報をあぶり出す
隠れた情報
複数の意味をもつデータ
意味の違うものを一つのレイアウトで扱う
複数のイベントを一度に扱う
タイミングが隠れる
システム情報
システム
CRUD
既存のプログラムに影響されずに機能を記述する
機能
機能
機能
機能
画面
システム
受信
送信
File
送信
受信受信
送信
機能
<CU><U>
<R>
<R>
<RD>
データと機能の整理
データ ほとんどの場合DBのテーブル整理
ER図の作成: 主要なテーブルを識別
サブシステムに分類する
機能 イベントに対応付ける
バッチに対応付ける 機能イベント
バッチを洗い出す
バッチの種類
定期監視
本来のバッチ処理
入出力のバッチ
File交換
DB経由
ポイント
データ交換の処理とバッチ処理を切り分ける
記述のパターン
定周期日
YY機能送信A機能
システム 受信 機能
通信
送信
機能
システム
画面 機能 機能 FileFile交換入
機能File交換出
電文
File
電文
Fileによるデータ交換画面処理
定周期
機能DB交換入
機能DB交換出
DBによるデータ交換データ
データ
システムを適切な大きさに分割する
事実
ある閾値を境に開発費は急激に上昇する
システム開発に関わる変化を止めることはできない
いかに分けるか
データ中心にわける
機能を中心にわける
業務を中心にわける
綺麗に分けようとしない
その企業の文化に併せて分割する
規模10 規模20
重複5
規模
工数コスト
5 10 15 20 25
規模30
5
10
15
20
25304045
規模25のシステムを分けると重複分を含めて規模30に増える。しかし、それが閾値よりも低ければ重複分5は無視できる
閾値
サブシステムに分類する
機能
機能
機能
機能
システム
受信
送信
File
送信
受信受信
送信
機能
画面
分け方の例
データ中心
データを役割から分ける
業務別にデータを分ける
データに機能を紐付け分類する
機能中心
機能の役割から分ける
業務別に機能を分ける
機能にデータを紐付け分類する 暗黙的な分類を引き出す制約を意識する
分けやすいところから分ける
その分類に他のものを寄せる
特徴をつかみ方針を決める
掘り起し岩を砕く
特徴をつかみそこから切り込む
トップダウンアプローチ ビジネスモデルから把握する
会社の外の登場人物を整理する 会社の中の登場人物を整理する ビジネスモデルとしての分類を求める
ボトムアップアプローチ CRUD表
正確なCRUD表ではなく妥当なコストで把握できる精度のものを目指す
マクロにながめる プログラムの分類を見直す テーブルの分類を見直す
トップダウンアプローチ
会社登場人物
登場人物
登場人物
登場人物
登場人物
登場人物
会社
部署
部署
部署
部署
会社外の登場人物
会社内の登場人物
・切り込めるところから切り込む・いろいろな手を試す
ボトムアップアプローチCRUD表 テーブル
プログラム
分類をモデルとあわす
システム価値 システム外部環境 システム境界 システム
コンテキスト
利用シーン
業務
イベント
プロトコル
ユースケース
概念
画面・帳表
機能
ドメイン
データ
要求
機能複合モデル
利用シーン&UC
業務&UC
UC:ユーケース
UC&画面
UC&機能
RDRA(リレーションシップ駆動要件分析)全体像
①②
どう管理するのか
コンテキスト
ドメインモデル
システム論理構成
サブシステム
パッケージA
画面・帳票モデル
パッケージB
イベントモデル
データモデル
機能複合モデル
プロトコルモデル
まとめ
システム境界とデータで合わせる
特徴をつかみ洗練化する
分類し整理する
得られる情報から切り口を探し整理する
モデル
機能
機能
機能
機能
機能
機能
既存システム
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
システム境界のレベルで一致させる