赤俊哉のレビュー一覧
-
Posted by ブクログ
ユーザー要求を正しく実装へつなぐ―システム設計のセオリー
著：赤 俊哉
情報システムの構築は、がんじがらめのなかで、細かい作業をシステムが完成するまで延々と続けていく。一行一句も間違えることができない、苦行の如しである。
基本設計と詳細設計の粒度は、本書でも明言できておらず、あいまいさを残したままである
本書は、セオリーであり、仮説であり、理論であるので、具体的な方法論については、さらに具体的な書を参考にしたほうが良いと思えるのである
要件の確認からはじまって、保守の手順の策定まで、長い長い道のりを経なければ、まともな情報システムを創ることができないと本書はいっています
気になったのは、以下です
・本書の特徴 基本設計に、論理設計と物理設計を重視する
①要件定義（論理設計）
②基本設計（論理設計）
③基本設計（物理設計）
④詳細設計（物理設計）
・システム設計における、２つの基本方針
①最小の労力で最大の効果を実現する
②成果物はより少なく、しかし、より良く
・設計で決める３つの定義
①データ
②業務プロセスとその機能
③データと業務業務プロセスの交差点、データと機能の交差点
・データへの操作：ＣＲＵＤ：クラッド
①Ｃ：生成
②Ｒ：参照
③Ｕ：更新
④Ｄ：削除
・設計情報を一元管理せよ
①変更時の影響分析が容易になる
②コミュニケーションコストを削減できる
・細分化された工程
2.1.1 工程名：要求から要件へのトレース
入力：要求仕様書、ＲＦＰ，業務規定、業務ルール
出力：要件定義書、要求要件追跡書
処理：要求を要件の形にまとめ、要求のぬけもれを防ぐ
要求：本当に欲しいもの
要件：本当に要るもの
2.1.2 工程名：設計範囲全体を把握しよう
入力：要求仕様書、ＲＦＰ，業務規定、業務ルール、要件定義書、要求要件追跡書
出力：システム全体図
処理：対象となりシステムの全体像を把握する
前提条件、制約条件を明確にしておく、メモ書きで構わない
2.1.3 工程名：設計標準をつくろう
入力：システム全体図
出力：設計標準
処理：設計を行う際の、標準規約を定める
文字コード
ＵＩ標準
データ標準
業務フローに関する標準
開発標準
コーディング規約
2.1.4 工程名：非機能要件の概要定義
入力：要求仕様書、ＲＦＰ，業務規定、業務ルール、要件定義書
出力：非機能要件定義書
処理：非機能要件を検討し、方向性を確認する
非機能要件 ＦＵＲＰＳ Ｆ：機能性、Ｕ：操作性、Ｒ：信頼性、Ｐ：性能、Ｓ：保守容易性
2.2.1 工程名：アーキテクチャ方針を考えよう
入力：要件定義書、システム全体図、非機能要件定義書
出力：アーキテクチャー方針
処理：アーキテクチャー方針を明確にする
業務体系
データ体系
適用処理体系
技術体系
2.2.2 工程名：システムインフラの構成を考えよう
入力：要件定義書、システム全体図、非機能要件定義書、アーキテクチャー方針
出力：ハードウェア構成要件定義書、ソフトウェア構成要件定義書、ネットワーク要件定義書、移行要件書
処理：システムの基本構成とシステム移行に関する要件を明確にする
2.2.3 工程名：運用まわりの要件を考えよう
入力：システム全体図、非機能要件定義書、各要件書
出力：運用要件書、信頼性要件書、性能要件書、セキュリティ要件書
処理：運用に関する要件を明確にする
3.1.1 工程名：概念データモデルをつくろう
入力：要求仕様書、ＲＦＰ，業務規定、業務ルール、要件定義書、システム全体図
出力：概念データモデル、ビジネスルール集
処理：データ構造を見える化し、ビジネスの全体像と静的側面の概要を把握する
データモデルは、４種
①サブジェクトエリアモデル
②概念データモデル
③論理データモデル
④物理データモデル
3.1.2 工程名：論理データモデルを作ろう
入力：概念データモデル、ビジネスルール集、ＴｏＢｅ詳細業務フロー図、画面ＵＩラフデザイン
出力：論理データモデル、ドメイン定義書、用語集、ビジネスルール集
処理：データ要求と静的ビジネスルールを把握する
⇒主キーの設定、正規化
⇒用語集をつくろう
3.1.3 工程名：物理データモデルをつくろう
入力：論理データモデル、用語集、ビジネスルール集、ドメイン定義書、論理ＣＲＵＤマトリクス、アーキテクチャー設計書
出力：物理データモデル、ドメイン定義書
処理：データ要求、静的ビジネスルールを最適に実現する実装を可能とする
3.1.4 工程名：コードを設計しよう
入力：論理データモデル、用語集、ドメイン定義書、物理データモデル
出力：コード定義書、コード仕様書
処理：コード化が必要な属性を抽出し、コード体系を決定する
3.2.1 工程名：外部インタフェースの要件を明確にしよう
入力：システム全体図、概念データモデル、要件定義書
出力：外部インタフェース要件定義書、概念モデル
処理：開発予定のシステムの範囲を明確化し、外部システムとのインタフェース要件を把握する
3.2.2 工程名：外部インタフェースの概要を定義しよう
入力：外部インタフェース要件定義書、論理データモデル
出力：外部インタフェース概要定義書、論理データモデル
処理：外部インタフェースを項目単位まで確定し、連携方式を検討する
3.2.3 工程名：外部インタフェースの詳細を定義しよう
入力：外部インタフェース概要定義書、物理データモデル
出力：外部インタフェース詳細定義書、物理データモデル
処理：外部インタフェースを確定し、連携方式を確定する
⇒連携方式とは、ETL
3.2.4 工程名：データ移行を設計しよう
入力：移行要件書、論理データモデル、物理データモデル
出力：移行設計書、手順書、物理データモデル
処理：旧システムから新システムへのデータ移行の仕様を確定させる
3.3.1 工程名：データベースに実装しよう
入力：物理データモデル、ドメイン定義書、外部インタフェース詳細定義書、移行設計書
出力：実装な可能なデータベース定義体、テーブル定義書、インデックス定義書、ビュー定義書
処理：実装可能なデータベース定義体を作成し、システムのデータに関する実装を確立する
⇒チューニング
①インフラの対応
②ＳＱＬ文のチューニング
③データベーステーブルの非正規化
・ACID A:原子性 C:一貫性 I:独立性 D:永続性
4.1.1 工程名：ＴｏＢｅ業務フローの概要を定義しよう
入力：要求仕様書、ＲＦＰ，業務規定、業務ルール、現行業務フロー、要件定義書、システム全体図
出力：ＴｏＢｅ概要業務フォロー図
処理：新システム稼働時のプロセスモデルの全容を把握できるようにする
ＢＤＦ，他に、ＢＰＭＮ，ＵＭＬなど
⇒ 業務フロー図の階層は、３～５階層が目安
⇒ すべてのフロー図に～すると、記述する
4.1.2 工程名：ＴｏＢｅ業務フローの詳細を定義しよう
入力：要求仕様書、ＲＦＰ，業務規定、業務ルール、現行業務フロー、要件定義書、概念データモデル、ＴｏＢｅ概要業務フローズ
出力：ＴｏＢｅ詳細業務フロー図
処理：新システムのプロセスモデルを確定する
⇒ 粒度
⇒ スイムレーン
4.1.3 工程名：ＡｓＩｓ業務フローを分析しよう
入力：要求仕様書、ＲＦＰ，業務規定、業務ルール、現行業務フロー、ＴｏＢｅ詳細業務フロー図
出力：ＡｓＩｓ業務フロー図
処理：ＡｓＩｓ業務フローを作成し、現状分析を行う
4.1.4 工程名：業務プロセス個々の概要を定義しよう
入力：概念データモデル、ＴｏＢｅ詳細業務フロー
出力：プロセス概要定義書
処理：新システム稼働時の業務プロセスの存在意義を明確する
⇒ ユースケース
4.2.1 工程名：画面のラフイメージを考えよう
入力：概念データモデル、ＴｏＢｅ詳細業務フロー図、プロセス概要定義書
出力：画面ＵＩラフデザイン
処理：該当業務プロセス、機能のデザインイメージ、必要項目の早期把握を可能にする
4.2.2 工程名：業務プロセス個々の詳細を定義しよう
入力：ＴｏＢｅ詳細業務フロー図、プロセス概要定義補、画面ＵＩラフデザイン
出力：プロセス詳細定義書
処理：必要とされる機能と使用項目を確定する
5.1.1 工程名：画面・帳票の概要を定義しよう
入力：ＴｏＢｅ詳細業務フロー図、プロセス概要定義書、画面ＵＩラフデザイン、プロセス詳細定義書
出力：画面帳票概要定義書（入出力定義書）、論理データモデル、機能定義書、画面ＵＩラフデザイン
処理：画面・帳票の入力要件、出力要件を明らかにしていく
IPO Input/Process/Output
⇒ 必要なら、モックアップ（プロトタイプ）を作る
5.1.2 工程名：バッチ処理の概要を定義しよう
入力：外部インタフェース概要定義書、ＴｏＢｅ詳細業務フロー図、プロセス詳細定義書
出力：バッチ概要定義書
処理：バッチ処理の概要を定義することにより、その入出力要件を明らかにする
5.1.3 工程名：論理ＣＲＵＤマトリクス分析をしよう
入力：物理データモデル、ＴｏＢｅ詳細業務フロー図、プロセス詳細定義書、画面帳票概要定義書
出力：論理ＣＲＵＤマトリクス
処理：データとプロセス、データと機能の交差地点を明確にする
5.1.4 工程名：サブシステムに分割しよう
入力：システム全体図、論理データモデル、論理ＣＲＵＤマトリクス
出力：サブシステム定義書
処理：システム化の管理・作業単位となるサブシステムへの分割を行う
5.1.5 工程名：物理ＣＲＵＤマトリクス分析をしよう
入力：物理ＣＲＵＤマトリクス、物理データモデル
出力：物理ＣＲＵＤマトリクス
処理：実装イメージのデータと業務プロセス、および、データと機能の交差地点を明確にする
5.1.6 工程名：サブシステム定義を詳細化しよう
入力：物理データモデル、サブシステム定義書、物理ＣＲＵＤマトリクス
出力：サブシステム定義書
処理：システム化の管理対象および作業単位となるサブシステムの粒度を確定する
5.2.1 工程名：機能の詳細を定義しよう
入力：画面ＵＩラフデザイン、画面帳票概要定義書（入出力定義書）、機能定義書、サブシステム定義書、バッチ概要定義書
出力：機能定義書
処理：機能定義を確定させる
5.2.2 工程名：画面帳票の詳細を定義しよう
入力：画面ＵＩラフデザイン、画面帳票概要定義書（入出力定義書）、サブシステム定義書、機能定義書
出力：画面帳票詳細定義書
処理：画面帳票及び、ＵＩの定義を確定する
5.2.3 工程名：バッチ処理の詳細を定義しよう
入力：外部インタフェース詳細定義書、バッチ概要定義書、機能定義書
出力：バッチ詳細定義書、ＴｏＢｅ詳細業務フロー図
処理：バッチ処理の詳細定義として、その入力要件と出力要件を具体的に定義する
5.2.4 工程名：共通で使用する機能を定義しよう
入力：バッチ詳細定義書、機能定義書、画面帳票詳細定義書（入出力定義書）、アークテクチャ設計書
出力：機能定義書
処理：共通で使用する機能の詳細定義を行うことにより、処理パターンの共通化を実現する
5.2.5 工程名：実装の準備をしよう
入力：機能定義書、画面帳票詳細定義書、バッチ詳細定義書、各構成仕様書、各対策設計書、アークテクチャ設計書
出力：機能ごとの詳細定義書、システム全体の詳細定義書
処理：アプリケーションの実装に必要な事柄を整理する
⇒ クラス図の作成
6.1.1 工程名：ユーザビリティの要件を明確にしよう
入力：画面ＵＩラフデザイン、プロセス詳細定義書
出力：ユーザビリティ要件定義書
処理：ＵＩのユーザビリティに関する要件を明確にする
⇒ 画面効果、アニメーション
⇒ 画面遷移
6.1.2 工程名：ユーザビリティの概要を定義しよう
入力：画面ＵＩラフデザイン、ユーザビリティ要件定義書
出力：画面帳票概要定義
処理：ＵＩのユーザビリティ要件を、画面ＵＩラフデザインに反映させる
⇒ 代表的ユーザ：ペルソナの設定
6.2.1 工程名：アクセシビリティの定義をしよう
入力：画面ＵＩラフデザイン、ユーザビリティ設計書
出力：画面ＵＩラフデザイン、ユーザビリティ設計書
処理：ＵＩのアクセシビリティを向上させるための要件を明確にし、画面ＵＩデザインとユーザビリティ設計に反映させる
6.2.2 工程名：ユーザビリティの詳細を定義しよう
入力：画面ＵＩラフデザイン、ユーザビリティ設計書、画面帳票詳細定義書
出力：画面ＵＩラフデザイン、画面帳票詳細定義書
処理：ユーザビリティの実現手段を画面設計として具体的に設計していく
⇒ 操作性の確認
7.1.1 工程名：アプリケーションアーキテクチャを設計しよう
入力：アーキテクチャ方針
出力：アーキテクチャ設計書
処理：アプリケーションアーキテクチャーを定義設計する
⇒ 共通機能の基本方針の決定
7.1.2 工程名：システムインフラの構成仕様を固めよう
入力：各要件書、アーキテクチャ設計書
出力：各構成仕様書
処理：要件定義段階で検討した各要件書に対して詳細定義を行う
7.1.3 工程名：運用まわりの共通仕様を固めよう
入力：各共通要件書、アーキテクチャ設計書
出力：各対策設計書
処理：システム共通である、運用・保守、障害・セキュリティ対策の使用をまとめ、アプリケーション以外の共通設計を行う
⇒ 運用手順、保守手順の設定
・ＳＯＡへの適用 ＳＯＡがトップダウンなら、マイクロサービスはボトムアップ
・アジャイル開発 使いどころがある、基幹システムはウォータフォールのほうが成功率は高い
目次
はじめに
設計工程と説明の流れ
序章
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日 -
-
-
Posted by ブクログ
ネタバレ業務システムの要件定義を行うにあたって初心者ベースで非常にわかりやすい。
○ 1 要件定義とは
要求分析と要件定義の作業
1．じっくりと時間をかけて要求を明確化し、ToBeビジネスモデルを検討する。
2． 明確化された要求を基に、ToBe（あるべき）プロセスモデル(業務プロセス手順の図解)とToBe概念データモデル(管理すべきデータと、データの構造を図解したもの)を作成
3. Aslsモデルを検証。（ここまでが要求分析）
4. Aslsモデルを参考にして、人、モノ、金等のプロジェクトとして意識せざるをえない制約を考慮しつつToBeの実現可能性を検討
5.実現可能性が低いと判断されたら、ToBeを修正
6. Aslsから新ToBeモデルへ至るプランを策定
要求(欲しいもの)と要件(要るもの)を明確に区別する
上流工程は、システムのプロと業務のプロとが相互翻訳を行いシステム構想を作り上げる工程
要件定義はトップダウンで骨組み、ボトムアップで肉付けがセオリー
○ 2 要検定後の前段
・ウォーターフォール型で手戻りは認めないために、90点の要件定義を100点にするためにリソースを注ぎ込むより、変更発生時に遡って反映できるようにトレーサビリティを高めておくことで手戻りコストを抑制することは得策。
・アジャイル開発においては、新しい価値を生み出すプロセスであり要件は固まらないという限定があるものの、その上での最低限の要件の明確化は必要
・アジャイル工程の考え方は①要件定義、設計、実装をいきなり繰り返すもの、②要件定義を前半できちんと行ってから繰り返すもの、があるが本書は②をとる
・要件定義と基本設計は一般に別工程として分けられるが、同時に行った方が効率性は抜群に高まる
○ 3 ビジネス要求の整理
* 目的の明確化
* 目的
* 対象
* 効果 定性、定量、投資回収期間
* 新システムイメージ
* システム以外の組織、役割イメージ
* システム化計画
* 新業務イメージの図示
* Tobeモデルの作成
* プロセスモデルとデータモデルを詳細に図示
要求を三種に分類
1. 「ビジネス要求」＝トップダウンの要求
2. 「業務要求」＝業務レベルの要求
3. 「システム要求」＝システムレベルの要求
4-1 要求明確化の手順
* step 1 ビジネス要求、業務要求を把握する
* システム化企画、ToBe モデルから、「ビジネス要求」を抽出
* 「ビジネス要来」から「薬務要求」へのブレイクダウン(各部署や現場の要求を取り込み)
* ToBe モデル、プロセスモデル、データモデルに反映
* Step 2要求の発生源を明確にする
* 現場からの要求度合いが強い「業務要求」の発生部門と担当者を明確化
* 経営課題の解決につながるものを優先事項としてチェック(業務要求から遡りビジネス要求との整合性をチェックし、ビジネス要求たりうるものを優先とする)
* Step 3要求の背景にある課題・問題点を明確にする
* 要求の背景を認識し、課題や問題点を明確にする。「ビジネス要求」と「業務要求」について、要求が発生した原因や理由を明らかにする
* Step 4 システム要求への落とし込み
* 「ビジネス要求」と「業務要求」のうち、優先順位を参考にして「システム要求」への落とし込み
* 経営視点、現場視点、システム視点と多方面からの検討
* システム要求を基に必要なUI、機能／非機能への対応を検討
* Step 5要求のランク付け
* 重要度合いを5段階にランク付け
- 経営およびビジネスに与える影響の大きさ
- 緊急度
- 課題解決に要する規模など
* 総合的なランクを決定
* 改めて、優先順位の高い要求のUI、機能／非機能について多面的に検討
* Step 6要求の階層化を整理する
* 要求の分類、ブレイクダウンの整合、トレーザビリティ可能か、ToBeモデルが各要求を反映しているか確認
* ビジネス要求は不変、業務要求レベル、システム要求レベルの修正の場合、ビジネス要求との整合性をとりつつ、速やかにシステム要求を明確化
4-2 システム全体図
・制約を踏まえて要件を確定させる。
・要件化された開発対象を、外部接続形態と共に認識するためのもの
4-3 業務フローの明確化
・ブレイクダウンされた業務要件を表すフロー図を作成
・やかりやすさを軽視しない
・人が行う処理、システムが行う処理を明確に区別、レーンを仕切るのも良い
4-4 業務プロセスの定義
・以下の5W2Hを定義すること
* When いつ→実施タイミング（事前／開始条件含む）
* Where どこで→場所、組織
* Who 誰が→担当者、ユーザー
* What 何を→対象データ
* Why 何のために→目的、狙い
* 当該プロセスが完了した時点で達成される目的と事後条件（プロセス完了時に達成できていること）、を含む
* How どのようにして→実施要領（制約条件含む）
* ユースケース記述まで書くのが望ましいが、シナリオ（手順）までは最低でも把握可能なレベルで記述）
* How many どれくらい→ データ量、時間
・開始条件、制約条件、前提条件の3つを持つとも捉えられる
4-5 UI・機能要件の明確化
* UIの基本形
* 検索
* 参照表示
* 選択
* 入力
* 実行
* 結果表示
* 画面遷移
* UIにおけるデータ操作: CRUD
* 生成 Create
* 参照 Read
* 更新 Update
* 削除 Delete
・UIは機能を実現するために存在するため、併行して定義すべき、ただしバッチ処理は例外
・機能の主な役割はデータ操作
・プロトタイプはUIを決める上で有益だが、業務フロー、業務プロセス、5W2Hがある程度明確になってから。機能が肥大化する懸念あり
4-6 データ要件の明確化
・ER図でエンティティ(SFのオブジェクト)とリレーションの関係を定義
・IE記法が基本
・リレーションの定義文は、〜する〜されるの動詞句を基本とする
4-7CRUDマトリクス分析
・エンティティ、プロセス、ごとに操作するCRUDを整理すること。
○ 5 非機能要件
・社会的責任を最優先
・FURPS+のうちFを除いたもの
* Functionality：機能性。画面や帳票など、利用者が扱うUIと処理要求を含む
* Usability 操作性。使いやすさ。画面の使い勝手や見栄え等を含みます。
* Reliability 信頼性。システムの停止要件（停止許容時間）、障害対策（ネットワークやハードウェアの二重化など）
* Performance 性能。オンライン処理の応答時間やバッチ処理時間など
* Supportability：保守の容易性。ハードの拡張性や互換性、プログラムの保守性
* + 設置場所、言語の規定、セキュリティ要件など
・業務プロセスの定義から明確化する
○ 6 アーキテクチャ
システムアーキテクチャの枠組み
* ホスト中心ー昔ながらのメインレームを使用するシステム
* 2層クライアント／サーバー型ーオープン系のサーバーとクライアントPCで処理を分担するシステム
* 3層クライアント／サーバー型ー データベースサーバー、アプリケーションサーバー、クライアントで処理を分担
* Webシステム（PCプラウザ・モバイル）ークライアントとしてPCまたはモバイルのWebブラウザを使用するシステム
* Webシステム（リッチクライアント）ークライアントとして「リッチクライアント」と呼ばれる特殊なプラウザを使用するシステム。スマートフォン専用アプリケーションもこの分類
* その他のシステムーIoTデバイスを使用するシステムや、サーバーレスのP2P（ピアソービア）、エッジコンピューティングなど
・疎結合がキーワードになる程分散が主流
・非機能要件をもとに最適な組み合わせを決める
アプリケーションアーキテクチャの位置付け
・明確にすべき項目
* 処理形態（オンライン・バッチ等）
* アプリケーション方針（オンライン・バッチ連動方法、どこまでサーバー側で処理するか)
* サーバー側プログラミング言語・フレームワークの使用
* DB操作方法
* 通信プロトコル
* クライアント側プログラミング言語
* ユーザーアクションの検知方法
* データ保持方法・チェック方法
* 画面遷移方法
* 排他制方式（楽観ロック、悲観ロック）
* 取消方法
* ログ
○ 7 妥当性確認
成果物の確認
① 要求・要件トレース図
② システム全体図
③ 概念／論理データモデル（ER図・用語集・データ項目書)
④ ビジネスルール集（要件定義レベル）
⑤ ToBe業務フロー及びプロセス定義（プロセスモデル）
③ UI定義（プロトタイプ）／画面遷移図
⑦ 非機能要件定義晝
⑧ アーキテクチャ要件定義書
・未決事項の把握と対応策 -
-
-
-
-
Posted by ブクログ
実はこの書籍の著者の方とは、とあるIT系のコミュニティで面識があります。（とはいってもお会いしたのが一度だけですが・・・）
いわゆる「IT土方」からキャリアをスタートし、事業会社の情報システム部門・営業・工場責任者を経て、現在では自社のIT戦略を担当されているそうです。
興味深いのは、それまでのご自身の経験を血肉にして、業務システムに関して独自の哲学を持たれているという点です。
テクノロジーや方法論には流行り廃りがつきものですが、こうしたブレない「哲学」を貫く姿には一種の憧れのようなものを感じますし、是非自分もそうありたいと思った次第です。