システム設計の考え方まとめ
主に上流部分
目的
設計の原理原則を知るため
ウォーターフォールを知る事により、アジャイルとの違いを知るため
基本の工程
-
上流工程
- 要求分析
- 要求定義
- 要件定義
- 外部設計
- 論理設計
-
下流工程
- 内部設計
- 物理設計
- 実装
- テスト
- 運用
基本原則
論理から物理へ
抽象から具体へ
概要から詳細へ
基本方針
最小の労力で、最大の効果
成果物はより少なく、より良く
システムの究極目的を理解する
適切な時（タイミング）に、
適切な人（場所）が、
適切な（品質の）情報をインプット（入力）することにより、
必要な時（タイミング）に、
必要な人（場所）へ、
必要な（品質の）情報をアウトプット（出力）すること
情報システムの価値とは
「唯一の使命」を果たせること
設計図の存在意義
合意形成のためのもの
設計書の性質
納品された直後から劣化すること
実体との乖離が発生し始め、結局コードの分析は必要になる
設計情報を一元化すること
分析・調査のための収集コストを削減できる
コミュニケーションコストを削減できる
設計の大枠
- 要件定義
- 予算、制約条件、要求実現性、将来性などが勘案対象
- 基本設計
- 図面への落とし込み
- 詳細設計
- 着手可能レベルへの落とし込み
要件定義
要求仕様書、RFP、業務規定・業務ルールなどを基に以下を作成する
- 要件定義書
- 要求要件追跡書
- システム全体図
目的
要求を要件へトレースし、設計に漏れなく反映する
-
ビジネス要求をシステム要件に整理する
-
「要求」＝本当に欲しいもの「要件」＝本当に要るもの
-
要件は要求の一部であり、然るべき制約の中で実現可能な要求だけを、要件としてまとめる
-
要求
- ビジネス要求 -> システム要求
-
要件
- ビジネス要件 -> システム要件
-
要求 -> 要件
- ビジネス要求 -> ビジネス要件
- システム要求 -> システム要件
トレースの優先順位
- 経営の要求把握
- 要求の発生源特定
- 課題・問題点の明確化
- 目的・理由の明確化
- 要求のランク付け
- 要求の選択
- 要求->要件->成果物の確定・紐付け
- プロジェクトスコーピング
システム全体図
要件定義書に基づき作成する
アーキテクチャの方針
要件定義書とシステム全体図に基づき策定する
- スケーラビリティ
- 処理量増加への対応策など
- 可用性
- ハードウェアの二重化等、システムが動き続けるための対策など
- セキュリティ
- データの保護・保全に関する対策など
- パフォーマンス
- サーバースペック、サーバー構成、ネットワーク構成など
インフラ設計
要件定義書とシステム全体図、アーキテクチャの方針に基づき作成する
-
ハードウェア構成
- オンプレかクラウドか
- データ容量
- ドライブ構成
- RAID構成
- ストレージ
- メモリ
-
ソフトウェア構成
- OS
- データ管理
- ミドルウェア
-
開発支援ソフトウェア
-
運用支援ソフトウェア
-
エンドユーザー支援ソフトウェア
-
ネットワーク構成
非機能要件
要件定義時に併せて考慮して決める
- スケーラビリティ
- 処理量増加への対応策など
- 可用性
- ハードウェアの二重化等、システムが動き続けるための対策など
- セキュリティ
- データの保護・保全に関する対策など
- パフォーマンス
- サーバースペック、サーバー構成、ネットワーク構成など
運用要件
システム全体図と非機能要件に基づき策定する
- システムの目的
- 運用方針（安定的運用、効率的運用など）
- 利用者の義務と制限（罰則規定）
- 運用方法
- 実施体制
- 支援体制
- システム運用を担当する組織体制
- サーバーの起動／停止、運用スケジュール、バッチ処理の手動実行
- 障害監視
- 障害検知
- リカバリー方法
信頼性要件
システム全体図と非機能要件に基づき策定する
- 目標稼働率
- 目標復旧時間・目標復旧地点（トランザクション単位）
- 目標復旧レベル（全ての業務を遂行可能とする等）
- ハードウエア障害
- サイバー攻撃
- 急激な負荷増大によるシステムの停止や遅延
性能要件
システム全体図と非機能要件に基づき策定する
- データの発生件数（平均、ピーク時）
- 性能目標（レスポンスタイム、バッチターンアラウンドタイム）
セキュリティ要件
システム全体図と非機能要件に基づき策定する
- 適用範囲
- 情報資産の保護
- 活動組織（体制）
- セキュリティ監視及び監査
- 安全処置
- 研修の実施
- 機密保持
- コンプライアンス
- 継続的な改善について
- 情報セキュリティの対象事項・対象項目・対策検討
- データ操作、アプリケーション、デバイス単位に権限と制限
- ログ監視
- パスワード変更サイクル、シングルサインオン
基本設計
データモデル
ER図は最低限作成する
-
概念の定義をしっかり行い、属性を定義する
-
独立エンティティ
- 他のエンティティに依存することなく存在するもの
-
従属エンティティ
- 他のエンティティに依存して存在するもの
-
命名ルールの標準化
- エイリアス
- シノニム(異音同義語)
- ホモニム(同音意義語)
-
正規化
- 繰り返しの排除
- 部分従属の排除
- 推移従属の排除
-
ナチュラルキーから考えることによって、「何をもって一意に識別されるか」を明確にする
外部インターフェース設計
システム全体図、要件定義書、データモデルを基に策定する
-
概要定義
- データ受け渡し対象となる外部接続先システムの特性(企業組織内外、API有無など)
- 受け渡しデータの名称、項目
- 受け渡しの方向性(一方向、両方向)
- 受け渡し方法(連携方式)
- 受け渡しタイミング
-
詳細定義
- 連携項目
- 連携方式
- 引数・戻り値
- 条件
- 例外処理
キャパシティプランニング
データベースの容量見積もり
- 初期のデータ量
- データの増加率
- 最大量
- 保存期間
パーティショニング
テーブルまたはファイルの分割
データセキュリティ
ユーザー権限の定義
排他制御
下記の定義
- 楽観的排他
- 悲観的排他
- ロック
性能要件の確認
- スペック上げ
- インデックス
- SQLチューニング
- 非正規化
トランザクション単位の決定
- 原子性
- 一貫性
- 独立性
- 永続性
業務フロー図
システムの専門知識を持たない人と実装担当者との認識を合わせる際などに使う
- 画面登録系プロセス
- 画面参照系プロセス
- バッチ系プロセス
- 帳票系プロセス
- 手作業系プロセス
バッチ処理
各項目の方針を決めていく
- バッチ種別(トランザクション、数値計算)
- 処理の実行時間帯
- 実行スケジュール
- 処理件数
- エラー処理方針(障害発生時、再処理方法)
- 同時実行の検討
ユーザビリティ設計
- ユーザビリティ要件定義
- ペルソナとユーザーシナリオの作成
- UIラフデザイン
- ユーザビリティ設計書
- セキュリティ対策
アクセシビリティ
- 対応デバイス
- 対応ブラウザ
- ネットワーク環境
- 他国語
- 操作性
書籍情報
赤俊哉, ユーザー要件を正しく実装へつなぐシステム設計のセオリー
https://amzn.to/2GtRerK
雑感
概要単位、詳細単位で定義していくという流れが、1つ1つは分かり易いがものによっては重複しているように感じた。目的は合意形成のためのものかつより良く少なくなので関わる人にあった粒度や量を作ることが大事そう