ユーザー要求を正しく実装へつなぐ―システム設計のセオリー
著:赤 俊哉
情報システムの構築は、がんじがらめのなかで、細かい作業をシステムが完成するまで延々と続けていく。一行一句も間違えることができない、苦行の如しである。
基本設計と詳細設計の粒度は、本書でも明言できておらず、あいまいさを残したままである
本書は、セオリーであり、仮説であり、理論であるので、具体的な方法論については、さらに具体的な書を参考にしたほうが良いと思えるのである
要件の確認からはじまって、保守の手順の策定まで、長い長い道のりを経なければ、まともな情報システムを創ることができないと本書はいっています
気になったのは、以下です
・本書の特徴 基本設計に、論理設計と物理設計を重視する
①要件定義(論理設計)
②基本設計(論理設計)
③基本設計(物理設計)
④詳細設計(物理設計)
・システム設計における、2つの基本方針
①最小の労力で最大の効果を実現する
②成果物はより少なく、しかし、より良く
・設計で決める3つの定義
①データ
②業務プロセスとその機能
③データと業務業務プロセスの交差点、データと機能の交差点
・データへの操作:CRUD:クラッド
①C:生成
②R:参照
③U:更新
④D:削除
・設計情報を一元管理せよ
①変更時の影響分析が容易になる
②コミュニケーションコストを削減できる
・細分化された工程
2.1.1 工程名:要求から要件へのトレース
入力:要求仕様書、RFP,業務規定、業務ルール
出力:要件定義書、要求要件追跡書
処理:要求を要件の形にまとめ、要求のぬけもれを防ぐ
要求:本当に欲しいもの
要件:本当に要るもの
2.1.2 工程名:設計範囲全体を把握しよう
入力:要求仕様書、RFP,業務規定、業務ルール、要件定義書、要求要件追跡書
出力:システム全体図
処理:対象となりシステムの全体像を把握する
前提条件、制約条件を明確にしておく、メモ書きで構わない
2.1.3 工程名:設計標準をつくろう
入力:システム全体図
出力:設計標準
処理:設計を行う際の、標準規約を定める
文字コード
UI標準
データ標準
業務フローに関する標準
開発標準
コーディング規約
2.1.4 工程名:非機能要件の概要定義
入力:要求仕様書、RFP,業務規定、業務ルール、要件定義書
出力:非機能要件定義書
処理:非機能要件を検討し、方向性を確認する
非機能要件 FURPS F:機能性、U:操作性、R:信頼性、P:性能、S:保守容易性
2.2.1 工程名:アーキテクチャ方針を考えよう
入力:要件定義書、システム全体図、非機能要件定義書
出力:アーキテクチャー方針
処理:アーキテクチャー方針を明確にする
業務体系
データ体系
適用処理体系
技術体系
2.2.2 工程名:システムインフラの構成を考えよう
入力:要件定義書、システム全体図、非機能要件定義書、アーキテクチャー方針
出力:ハードウェア構成要件定義書、ソフトウェア構成要件定義書、ネットワーク要件定義書、移行要件書
処理:システムの基本構成とシステム移行に関する要件を明確にする
2.2.3 工程名:運用まわりの要件を考えよう
入力:システム全体図、非機能要件定義書、各要件書
出力:運用要件書、信頼性要件書、性能要件書、セキュリティ要件書
処理:運用に関する要件を明確にする
3.1.1 工程名:概念データモデルをつくろう
入力:要求仕様書、RFP,業務規定、業務ルール、要件定義書、システム全体図
出力:概念データモデル、ビジネスルール集
処理:データ構造を見える化し、ビジネスの全体像と静的側面の概要を把握する
データモデルは、4種
①サブジェクトエリアモデル
②概念データモデル
③論理データモデル
④物理データモデル
3.1.2 工程名:論理データモデルを作ろう
入力:概念データモデル、ビジネスルール集、ToBe詳細業務フロー図、画面UIラフデザイン
出力:論理データモデル、ドメイン定義書、用語集、ビジネスルール集
処理:データ要求と静的ビジネスルールを把握する
⇒主キーの設定、正規化
⇒用語集をつくろう
3.1.3 工程名:物理データモデルをつくろう
入力:論理データモデル、用語集、ビジネスルール集、ドメイン定義書、論理CRUDマトリクス、アーキテクチャー設計書
出力:物理データモデル、ドメイン定義書
処理:データ要求、静的ビジネスルールを最適に実現する実装を可能とする
3.1.4 工程名:コードを設計しよう
入力:論理データモデル、用語集、ドメイン定義書、物理データモデル
出力:コード定義書、コード仕様書
処理:コード化が必要な属性を抽出し、コード体系を決定する
3.2.1 工程名:外部インタフェースの要件を明確にしよう
入力:システム全体図、概念データモデル、要件定義書
出力:外部インタフェース要件定義書、概念モデル
処理:開発予定のシステムの範囲を明確化し、外部システムとのインタフェース要件を把握する
3.2.2 工程名:外部インタフェースの概要を定義しよう
入力:外部インタフェース要件定義書、論理データモデル
出力:外部インタフェース概要定義書、論理データモデル
処理:外部インタフェースを項目単位まで確定し、連携方式を検討する
3.2.3 工程名:外部インタフェースの詳細を定義しよう
入力:外部インタフェース概要定義書、物理データモデル
出力:外部インタフェース詳細定義書、物理データモデル
処理:外部インタフェースを確定し、連携方式を確定する
⇒連携方式とは、ETL
3.2.4 工程名:データ移行を設計しよう
入力:移行要件書、論理データモデル、物理データモデル
出力:移行設計書、手順書、物理データモデル
処理:旧システムから新システムへのデータ移行の仕様を確定させる
3.3.1 工程名:データベースに実装しよう
入力:物理データモデル、ドメイン定義書、外部インタフェース詳細定義書、移行設計書
出力:実装な可能なデータベース定義体、テーブル定義書、インデックス定義書、ビュー定義書
処理:実装可能なデータベース定義体を作成し、システムのデータに関する実装を確立する
⇒チューニング
①インフラの対応
②SQL文のチューニング
③データベーステーブルの非正規化
・ACID A:原子性 C:一貫性 I:独立性 D:永続性
4.1.1 工程名:ToBe業務フローの概要を定義しよう
入力:要求仕様書、RFP,業務規定、業務ルール、現行業務フロー、要件定義書、システム全体図
出力:ToBe概要業務フォロー図
処理:新システム稼働時のプロセスモデルの全容を把握できるようにする
BDF,他に、BPMN,UMLなど
⇒ 業務フロー図の階層は、3~5階層が目安
⇒ すべてのフロー図に~すると、記述する
4.1.2 工程名:ToBe業務フローの詳細を定義しよう
入力:要求仕様書、RFP,業務規定、業務ルール、現行業務フロー、要件定義書、概念データモデル、ToBe概要業務フローズ
出力:ToBe詳細業務フロー図
処理:新システムのプロセスモデルを確定する
⇒ 粒度
⇒ スイムレーン
4.1.3 工程名:AsIs業務フローを分析しよう
入力:要求仕様書、RFP,業務規定、業務ルール、現行業務フロー、ToBe詳細業務フロー図
出力:AsIs業務フロー図
処理:AsIs業務フローを作成し、現状分析を行う
4.1.4 工程名:業務プロセス個々の概要を定義しよう
入力:概念データモデル、ToBe詳細業務フロー
出力:プロセス概要定義書
処理:新システム稼働時の業務プロセスの存在意義を明確する
⇒ ユースケース
4.2.1 工程名:画面のラフイメージを考えよう
入力:概念データモデル、ToBe詳細業務フロー図、プロセス概要定義書
出力:画面UIラフデザイン
処理:該当業務プロセス、機能のデザインイメージ、必要項目の早期把握を可能にする
4.2.2 工程名:業務プロセス個々の詳細を定義しよう
入力:ToBe詳細業務フロー図、プロセス概要定義補、画面UIラフデザイン
出力:プロセス詳細定義書
処理:必要とされる機能と使用項目を確定する
5.1.1 工程名:画面・帳票の概要を定義しよう
入力:ToBe詳細業務フロー図、プロセス概要定義書、画面UIラフデザイン、プロセス詳細定義書
出力:画面帳票概要定義書(入出力定義書)、論理データモデル、機能定義書、画面UIラフデザイン
処理:画面・帳票の入力要件、出力要件を明らかにしていく
IPO Input/Process/Output
⇒ 必要なら、モックアップ(プロトタイプ)を作る
5.1.2 工程名:バッチ処理の概要を定義しよう
入力:外部インタフェース概要定義書、ToBe詳細業務フロー図、プロセス詳細定義書
出力:バッチ概要定義書
処理:バッチ処理の概要を定義することにより、その入出力要件を明らかにする
5.1.3 工程名:論理CRUDマトリクス分析をしよう
入力:物理データモデル、ToBe詳細業務フロー図、プロセス詳細定義書、画面帳票概要定義書
出力:論理CRUDマトリクス
処理:データとプロセス、データと機能の交差地点を明確にする
5.1.4 工程名:サブシステムに分割しよう
入力:システム全体図、論理データモデル、論理CRUDマトリクス
出力:サブシステム定義書
処理:システム化の管理・作業単位となるサブシステムへの分割を行う
5.1.5 工程名:物理CRUDマトリクス分析をしよう
入力:物理CRUDマトリクス、物理データモデル
出力:物理CRUDマトリクス
処理:実装イメージのデータと業務プロセス、および、データと機能の交差地点を明確にする
5.1.6 工程名:サブシステム定義を詳細化しよう
入力:物理データモデル、サブシステム定義書、物理CRUDマトリクス
出力:サブシステム定義書
処理:システム化の管理対象および作業単位となるサブシステムの粒度を確定する
5.2.1 工程名:機能の詳細を定義しよう
入力:画面UIラフデザイン、画面帳票概要定義書(入出力定義書)、機能定義書、サブシステム定義書、バッチ概要定義書
出力:機能定義書
処理:機能定義を確定させる
5.2.2 工程名:画面帳票の詳細を定義しよう
入力:画面UIラフデザイン、画面帳票概要定義書(入出力定義書)、サブシステム定義書、機能定義書
出力:画面帳票詳細定義書
処理:画面帳票及び、UIの定義を確定する
5.2.3 工程名:バッチ処理の詳細を定義しよう
入力:外部インタフェース詳細定義書、バッチ概要定義書、機能定義書
出力:バッチ詳細定義書、ToBe詳細業務フロー図
処理:バッチ処理の詳細定義として、その入力要件と出力要件を具体的に定義する
5.2.4 工程名:共通で使用する機能を定義しよう
入力:バッチ詳細定義書、機能定義書、画面帳票詳細定義書(入出力定義書)、アークテクチャ設計書
出力:機能定義書
処理:共通で使用する機能の詳細定義を行うことにより、処理パターンの共通化を実現する
5.2.5 工程名:実装の準備をしよう
入力:機能定義書、画面帳票詳細定義書、バッチ詳細定義書、各構成仕様書、各対策設計書、アークテクチャ設計書
出力:機能ごとの詳細定義書、システム全体の詳細定義書
処理:アプリケーションの実装に必要な事柄を整理する
⇒ クラス図の作成
6.1.1 工程名:ユーザビリティの要件を明確にしよう
入力:画面UIラフデザイン、プロセス詳細定義書
出力:ユーザビリティ要件定義書
処理:UIのユーザビリティに関する要件を明確にする
⇒ 画面効果、アニメーション
⇒ 画面遷移
6.1.2 工程名:ユーザビリティの概要を定義しよう
入力:画面UIラフデザイン、ユーザビリティ要件定義書
出力:画面帳票概要定義
処理:UIのユーザビリティ要件を、画面UIラフデザインに反映させる
⇒ 代表的ユーザ:ペルソナの設定
6.2.1 工程名:アクセシビリティの定義をしよう
入力:画面UIラフデザイン、ユーザビリティ設計書
出力:画面UIラフデザイン、ユーザビリティ設計書
処理:UIのアクセシビリティを向上させるための要件を明確にし、画面UIデザインとユーザビリティ設計に反映させる
6.2.2 工程名:ユーザビリティの詳細を定義しよう
入力:画面UIラフデザイン、ユーザビリティ設計書、画面帳票詳細定義書
出力:画面UIラフデザイン、画面帳票詳細定義書
処理:ユーザビリティの実現手段を画面設計として具体的に設計していく
⇒ 操作性の確認
7.1.1 工程名:アプリケーションアーキテクチャを設計しよう
入力:アーキテクチャ方針
出力:アーキテクチャ設計書
処理:アプリケーションアーキテクチャーを定義設計する
⇒ 共通機能の基本方針の決定
7.1.2 工程名:システムインフラの構成仕様を固めよう
入力:各要件書、アーキテクチャ設計書
出力:各構成仕様書
処理:要件定義段階で検討した各要件書に対して詳細定義を行う
7.1.3 工程名:運用まわりの共通仕様を固めよう
入力:各共通要件書、アーキテクチャ設計書
出力:各対策設計書
処理:システム共通である、運用・保守、障害・セキュリティ対策の使用をまとめ、アプリケーション以外の共通設計を行う
⇒ 運用手順、保守手順の設定
・SOAへの適用 SOAがトップダウンなら、マイクロサービスはボトムアップ
・アジャイル開発 使いどころがある、基幹システムはウォータフォールのほうが成功率は高い
目次
はじめに
設計工程と説明の流れ
序章
0.1 システム設計へのアプローチ
第1章 情報システムと設計
1.1 情報システムにおける設計
1.2 設計の全体像と基本方針
第2章 論理設計のはじめに
2.1 要件定義でやっておくべきこと
2.2 実装への下準備
第3章 データ設計のセオリー
3.1 データの設計
3.2 外部インターフェースの設計
3.3 データの実装
第4章 プロセス設計のセオリー
4.1 業務プロセスの概要定義
4.2 業務プロセスの詳細定義
第5章 機能設計のセオリー
5.1 機能の概要定義
5.2 機能の詳細定義
第6章 ユーザビリティ設計のセオリー
6.1 ユーザビリティの概要定義
6.2 ユーザビリティの詳細定義
第7章 設計のToBeを実装のAsIsへつなぐために
7.1 インフラ系と運用系の仕様固め
7.2 SOA・アジャイル開発への期待
あとがきに代えて
参考文献
索引
ISBN:9784865940053
出版社:リックテレコム
判型:A5
ページ数:427ページ
定価:3300円(本体)
発売日:2016年03月10日