rdra4越境アジャイル
TRANSCRIPT
バックエンドに切り込む
既存システムの全体像を把握する
わたしは…
• ㈱バリューソース– 代表取締役 社長– 神崎 善司– [email protected]– 要件定義の散歩道:https://www.facebook.com/youkennotsubo– twitter:@zenzengood
• 要件定義手法の開発
– RDRA Relationship driven requirement analysis
• 普段は– システム企画・要件定義などの支援– セミナー開催(要件定義、モデリング)– 要件定義用ツールの開発
• 要件定義との関係は– 25年ほど前からオブジェクト指向を中心にシステム開発全般に関わる– 20年ほど前から上流工程を中心としたセミナー・コンサルティングを行う– その間一貫してモデル中心で行う– その経験を活かしてモデルを使った要件定義の手法をRDRAとしてまとめる
システム価値
システム外部環境 システム境界 システム
コンテキスト
利用シーン
業務
イベント
ユースケース
概念
画面・帳表
機能
ドメイン
データ
要求
機能複合モデル
利用シーン&UC
業務&UC
状態
UC:ユーケース
UC&画面
UC&機能
RDRAとは
プロトコル
依存
画面
ユースケース機能
データ・ドメイン
外部システムイベント
要求
バックエンドシステム
サービスフロント
システムの地図を作る
バックエンドシステム
何をどう表現するどのように作成する
システムの地図を作る
何が
どこにある
地図は何を表している
区役所 XXホテル病院
駅
何が
役割の名前で対象を理解する
どこにあり
北
南西
東
道路を中心に住所を表す
一方通行
指定方向外進行禁止
目的地に進むためには
道路のルールに従う
ローカルなルールも
出典livedoor.blogimg.jp
システムに置き換えると
バックエンドシステム
<何が>
入出力が
<どこにあるのか>どのサブシステムのどのユースケース(画
面)
入出力 サブシステム
分類
UC UC UC UC
UC
UC
UC
UCUC
UC
UC
UC
UC
システムに切り込むには
バックエンドシステム
変更機能追加
ビジネス要求
影響範囲をどう見つけるのか
ルール
影響範囲
影響範囲
ルールの可視化
データ
影響範囲
影響範囲
機能
機能
機能
機能
機能 機能
機能
機能とデータの関係を可視化する
何がどこに
ルールが見えない
システム境界 システム
UC 機能
ビジネスルールの表現
システム
入出力
構造のルール
振舞のルール状態の変化
<式>金額=単価*数量
式、表形式のルール
状態
1 *
情報の時系列の変化
コスト構造 収益構造
パートナー
顧客セグメン
ト
価値提案リソース
主要活動
チャネル
顧客との関係
概念
取引先 商品 取引
組合せによる特報を分析
ビジネスモデル分析
リッチピクチャ
会社顧客
デリバリ
パートナー商品
商品
サービス
パートナー
サービス営業
購買
物流
取引
バリエーション分析
ビジネスルールの洗い出し
ビジネスルール
ビジネスモデルキャンバス
ビジネスルールがロジックに埋め込まれる
データ
機能
機能
機能
機能
機能 機能
機能
<式>金額=単価*数量
状態
1 *
振舞のルール
構造のルール
式・条件
システム価値
システム外部環境 システム境界 システム
コンテキスト
利用シーン
業務
イベント
ユースケース
概念
画面・帳表
機能
ドメイン
データ
要求
機能複合モデル
利用シーン&UC
業務&UC
UC:ユーケース
UC&画面
UC&機能
システム地図の構成要素
プロトコル
既存システムを調べ方
まともなドキュメントもないし、全体を理解している人もいない
プログラム単位のドキュメント化
• 混沌とした一枚岩のシステムをプログラム単位で調べてもシステム化の判断には役に立たない
Prg
既存システムは…
• 様々な制約によってプログラムが混沌としている
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
Prg
既存システムをわかりやすく整理する
モデル入力情報タイミング
機能
機能
機能
機能
機能
機能
出力情報タイミング
既存システム
Prg
物理制約 時間制約 開発時制約
入力情報タイミング
出力情報タイミング
現実とつながりながら現実の混沌に影響されずに整理する
システム境界とデータを一致させる
既存システムの情報はあまりないと言っても
• たいてい以下のドキュメントはある– テーブル定義書(実DBのスキーマ定義)– 電文レイアウト– ファイル交換のファイル定義書
• 保守されているシステムについては
– データとシステム境界の情報はある
システム境界
システムをよく知らないといっても
• この機能はこういうことを行っている– ここでこうするとあそこに影響する– こうしたいときはここをこうすればいんだよ
• 制約の説明– ここは時間がなくてこうしちゃったんだ!– この時代はこういうルールだったんだ
具体的な分析法
分析
分析方針
• 集めやすい情報から集める
• 抜けたピースを探す
• 集めた情報の特徴から切り込む– 分類する– 関係をつかむ
システム境界とデータを捉える
画面
システム
受信
送信
DB
File
送信
受信
帳票
データ交換
データ交換
入出力画面 稼働しているシステム帳票 〃通信 電文レイアウト
データ交換File FileレイアウトDB テーブル定義書
データテーブル定義書ファイルレイアウト
入出力をイベントで統一的に扱う
• システム境界をイベントとして扱う
– ポイント
•入出力は実体に合わす
画面
受信
送信
DB
File
受信
送信
システム画面
受信
送信イベント
状態の遷移として整理
ステートマシン
状態を振る舞いのルールとする
A画面
システム
受信
送信
DB
A_File
送信
受信受信
送信
解約待ち
開始済み開始前A画面
B画面
A_File
B_File
状態 状態XXX / YY機能
状態の洗い出し• 画面上の情報• オペレータが認識しているもの状態• テーブル上の区分やフラグなど• テーブルの関係• ビジネス上の概念
CRUD
既存のプログラムに影響されずに機能を記述する
機能
機能
機能
機能
画面
システム
受信
送信
File
送信
受信受信
送信
機能
<CU><U>
<R>
<R>
<RD>
イベント、データ、ステートマシンを元に機能を洗い出す
記述のパターン
定周期日
YY機能送信A機能
システム 受信 機能
通信
送信
機能
システム
画面 機能 機能 FileFile交換入
機能File交換出
電文
File
電文
Fileによるデータ交換画面処理
定周期
機能DB交換入
機能DB交換出
DBによるデータ交換データ
データ
画面・データ・機能・バッチの整理
• 画面– 主要な画面を洗い出す– 画面の内容から状態を洗い出す– サブシステムに分類する
• データ– ER図の作成: 主要なテーブルを識別– サブシステムに分類する
• 機能– イベントに対応付ける(ステートマシン)– バッチに対応付ける
• バッチの種類– 本来のバッチ処理– 定周期処理 ⇒ イベント– 入出力のバッチ ⇒ イベント
• File交換、DB経由
– ポイントデータ交換の処理とバッチ処理を切り分ける
隠れた情報をあぶり出す
• 隠れた情報– 複数の意味をもつデータ
• 意味の違うものを一つのレイアウトで扱う
– 複数のイベントを一度に扱う• タイミングが隠れる
システム情報
モデルイメージ 軽め
モデルイメージ 重め
画面・帳票モデル イベントモデル
プロトコルモデル
データモデル 機能複合モデル(CRUD)
まとめ
モデル
機能
機能
機能
機能
機能
機能
既存システム
Prg
Prg
Prg
システム境界とデータを一致させる
画面機能 データ・
ドメイン
外部システムイベント
状態