アーキテクチャと要件定義の隙間（PPT版）

アーキテクチャと要件定義の隙間
〜現状分析から得られること〜
1Copyright (C) 2013 Atsushi Takayasu All Rights Reserved.

1 2 3 4 5アジェンダ
▌ 自己紹介
▌ 1 はじめに
▌ 2 システム分析
▌ 3 アーキテクチャ分析
▌ 4 終わりに
Copyright (C) 2013 Atsushi Takayasu All Rights Reserved. 2

1 2 3 4 5自己紹介
高安厚思
▌ 活動領域・キーワード
▌ ２０年にわたり、ソフトウエアエンジニアリングを適用したシステム
開発やコンサルティングに携わる。
▌ 最新技術を適切に利用した、柔軟なシステム構成の構築、品質管理を
中心として技術マネージメントなどを主要テーマとして活動。
▌ 開発方法論、アーキテクチャ設計コンサルティング、システム全体設
計を得意分野とする。
▌ 東京電機大学非常勤講師、SQuBOK設計開発領域検討委員。
▌ 資格
▌ ネットワークスペシャリスト
▌ アプリケーションエンジニア（現システムアーキテクト）
▌ プロジェクトマネージャ
▌ ITストラテジスト
▌ MCSE
▌ MCSD
▌ VSP/VSTP

1 2 3 4 5対外活動
最近の著書、訳書
▌ 「システム設計の謎を解く（ソフトバンク）」
▌ 「StrutsによるWebアプリケーションスーパーサンプル
（ソフトバンク）」
▌ 「Seasar入門[（ソフトバンク）」
▌ 「Javaルールブック（エクスメディア）
▌ 「ITアーキテクトのためのシステム設計実践ガイド
アーキテクチャ編（日経BP）」など。
連載記事執筆
▌ 日経SYSTEMS誌「Webアーキテクチャ再入門」
講演
▌ SODEC ミッションクリティカル開発
▌ 日本テクノセンターセミナー
▌ UML Forum
▌ 日経BP社 ITアーキテクトのためのシステム設計フォーラム
特別講演
▌ Developers Summit 2013 Summer

1 はじめに

1 2 3 4 5今回の位置付け
▌ 今日の話は、現行システムからのリプレイスにおいて、
死角になりがちな内容について触れていきます。
▌ 新しい業務については重要ですが、今回お話する内容の対象外です！
要件定義
その
他
現状
分析
要求
開発

1 2 3 4 5本日の話の背景
▌ 要件定義は決められたことを元に思考するのではありません
▌ いわゆるWhatを定義するため、
背景にある方針や思考を意識する必要があります。
常に価値を
意識する
• 価値基準の
明確化
仮説検証型
の思考
• 差分を
確認する
モデルの
利用
• 網羅的な
遂行に
必要な道具
理想と現実
のバランス
• 事実に立脚
すること

1 2 3 4 5リファレンスモデルの代表例
▌ リファレンスモデルとして、参考としていくつかご紹介します。
Enterprise
Architecture
DMBoK
TOGAF ADM

1 2 3 4 5参考）Enterprise Architecture
▌ http://www.meti.go.jp/policy/it_policy/itasociate/EA3.ppt
「Enterprise Architectureについて」p41より引用
業績測定参照モデル
（Business Reference Model )
政策・業務参照モデル
（Performance Reference Model )
(Data Reference Model)
(Technical Reference Model )
技術参照モデル
データ参照モデル
サービスコンポーネント参照モデル
(Service Component Reference Model )
データ体系
技術体系
（TechnologyArchitecture）
適用処理体系
（DataArchitecture）
政策・業務体系
（BusinessArchitecture）
（ApplicationArchitecture）

2 システムの分析
EAの視点から

1 2 3 4 5業務
▌ 対象システムを超えて、業務の位置づけを把握（判断材料）
▌ 業務移行を意識して、業務内容を把握
全体システム化計画（最適化計画）での
課題認識
業務体系の確認
対象業務の詳細化（経営・管理・OP）
業務移行

1 2 3 4 5データ
▌ システム現状分析の要となる調査・分析
▌ 業務の視点とアプリの視点の双方が必要となり、
これらをインクリメンタルに実施
Copyright (C) 2013 Atsushi Takayasu All Rights Reserved 12
業務をデータの流れで追っていく
現行データの分析を実施詳細は次頁
データ分類の明確化
データ辞書の確認（作成）

1 2 3 4 5追加）現行データの分析
▌ 現行データの分析は、2つの理由から難しいですが実施すると
効果の高い作業です。
▌ 本作業の主たる作業は、主要データにおけるデータ分類を
明確化することです。
2つの理由
 アウトプットに対する工数比率が低くなる
 現行データを提供することのセキュリティ上の課題
データ分類の目的
 ロジックへの影響を確認する
 ドメイン値の統制がされているかどうかの確認をする
 移行における難易度や工数を評価するための情報を確認する
 テストデータへの変換に対する可否を確認する

1 2 3 4 5アプリケーション
▌ アプリケーションの分析は新システムのアプリケーション構造の
参考となる
▌ 課題はアプリケーションに埋め込まれていることも多い
▌ データ分類ごとのロジックを確認
アプリケーション間の関係を把握
アプリケーションの構造を把握
IOの確認
ロジックの分析
課題の原因を確認

3 アーキテクチャ分析

1 2 3 4 5アーキテクチャとは
▌ アーキテクチャは複雑であり、整理が重要
▌ 本日の視点はシステムアーキテクチャ
http://www.atmarkit.co.jp/fdotnet/softfactory/softfactory05/softfactory05_01.html から引用

1 2 3 4 5システムアーキテクチャ
▌ システムアーキテクチャとして、把握すべき内容は以下の4つ
▌ これらを非機能要件の視点から把握
ネット
ワーク
• システム間の
関係
ストレージ
• データの
格納領域
• IO性能値
サーバ
• 構成
• 性能
• OS
ソフト
ウェア
• ミドルウェア
• アプリケー
ション

1 2 3 4 5これらから読み取ること
▌ 現行のシステムが構成された背景を推測します。
もちろん、非機能要件定義書があれば確認をします。
▌ 現行で想定されているサービスレベルや非機能要件が推測できます。
可用性
運用方針（監視・バックアップ）
セキュリティ
オンラインとバッチの処理方針
（データ連携の方針）

1 2 3 4 5性能はデータから判断
▌ 現行システムの性能情報は必ず取得しましょう。
▌ 取得方法はいろいろあります！
▌ 平均値とピーク時の値を元に、将来値を考慮します。
CPU、メモリ使用率
IOPS、IOスループット
ネットワークスループット
イベントリ情報

1 2 3 4 5非機能要件のとりまとめ
▌ 現行情報と課題から、非機能要件をまとめる
▌ 対応すべき内容とコスト試算から適切な要件に落としこむ
非機能要件の確定
非機能要件の調整想定ソリューション
非機能要件整理
非機能要件と課題予算
現行要件
非機能要件
定義書
システム分析
アーキテクチャ
分析

4 終わりに

1 2 3 4 5蛇足）現実問題としての移行
▌ 移行は、必ず存在します。新システムだけでなく、現行システムを
知っておかないと破綻します。
業務移行
• 新システム業務フロー
• 新システム運用フロー
システム
移行
• システム切替
• 段階的切替
• 切戻
データ移
行
• 新旧マッピング
• クレンジング
• データ作成
• 更新停止・差分更新

1 2 3 4 5今日お伝えしたかったこと！
▌ 今日お伝えしたかったのは以下の3つです。
現状分析は重要です
• すべてヒアリングで確認することは
できません！
非機能要件は可能かどうか検討すること
• 非機能要件は実現手段を想定し、
コストパフォーマンスを意識します。
でも、現状と同じでは仕方ありません
• 何を変える必要があるのか、見極めましょう！

アーキテクチャと要件定義の隙間（PPT版）

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (15)

Más de Atsushi Takayasu

Más de Atsushi Takayasu (11)

アーキテクチャと要件定義の隙間（PPT版）