「システム設計のセオリー」を読んだ
2019年10月頃にタイトルの書籍を読んだ。 編集方法を変えたので再投稿。
読書目的
要件定義から設計・開発・保守まで一通り経験はしたけれど、進め方や成果物が現場によって様々で何が正解かわからないのでなんとかしたい。要件定義〜設計に関して全体像をしっかりと把握したい。
書籍の内容
目次
- 情報システムと設計
- 論理設計のはじめに
- データ設計のセオリー
- プロセス設計のセオリー
- 機能設計のセオリー
- ユーザビリティ設計のセオリー
- 設計のToBeを実装のAsIsへつなぐために
概要
情報システムの使命は「適切な時に適切な人が適切な情報をインプットすることにより、必要な時に必要な人へ必要な情報をアウトプットすること」であるという考えを念頭に置いて、設計の方法が記載されている。
論理設計は、要件定義(論理)→基本設計(論理)を行う工程、物理設計は、基本設計(物理)→詳細設計(物理)を行う工程であるとし、必要なインプット、アウトプット、具体的な手順について説明がされている。
以下に各設計でやること、作成する成果物(数が多いため主要なもののみ)について記載する。
データ設計
- 概念データモデル→論理データモデル→物理データモデル→コード定義
- 外部インタフェースの要件の明確化→外部インタフェースの概要→外部インタフェースの詳細→データ移行の設計
- データベースの実装
プロセス設計
- ToBe業務フローの概要→ToBe業務フローの詳細→AsIs業務フローの分析→業務プロセスの概要
- 画面のラフイメージ→業務プロセスの詳細
機能設計
- 画面・帳票の概要→バッチ処理の概要→論理CRUDマトリクス分析→サブシステム分割→物理CRUDマトリクス→サブシステム定義の詳細
- 機能の詳細→画面・帳票の詳細→バッチ処理の詳細→共通機能の詳細→実装準備
ユーザビリティ設計
読んだ感想
優れた設計を行うためには次の3つの成果物がとくに重要であると思った。 ビジネスの静的な側面と動的な側面、そしてその交差点をまとめたものだからである。
概念・論理データモデル
エンティティ同士の関連性をER図で表したもの。
業務フロー図
業務の流れをDFD等で表したもの。
CRUD図(業務プロセス×エンティティ)
業務プロセスとエンティティのCRUD(登録・参照・更新・削除)の対応関係をマトリクスで表したもの。 業務フロー図や概念データモデルがインプットになる。
今まで関わった仕事では、こういった成果物が既に完成されていることが殆どだったが、その重要性やポイントについて理解していなかったので、少しはましになったのかなと思う。
読んでいる途中で成果物同士の関連を忘れてしまうことがあったので、インプット、アウトプットの関係を記載した一覧(もしくは一枚絵)が欲しいなと思った。
なお、上流工程に関する書籍をもう2、3冊読む予定。