システム設計の謎を解く 改訂版 強いSEになるための機能設計と入出力設計の極意 (高安厚思)

書籍情報

• 著者:高安厚思(著)
• 発行日:2017-12-20
• ISBN:9784797393514
• URL:https://www.sbcr.jp/product/4797393514/

書籍目次

• 序章 本書の構成と概要
  • 0.1 本書の構成
  • 0.2 構成要素について
    • 1 背景
    • 2 入力
    • 3 出力
  • 0.3 各章の概要
    • 1 第1章の概要 〜設計の謎〜
    • 2 第2章の概要 〜設計へのインプット〜
    • 3 第3章の概要 〜設計の前にやるべき作業〜
    • 4 第4章の概要 〜アプリケーション設計としてやるべき作業〜
    • 5 第5章の概要 〜運用設計〜
    • 6 第6章の概要 〜アーキテクチャ設計としてやるべきこと〜
    • 7 第7章の概要 〜本書の知識を現場で活用するために〜
• 第1章 設計の謎
  • 1.1 設計が抱える2つの謎
    • 1 設計の「意味」がバラバラである謎
    • 2 設計の「範囲」の謎
  • 1.2 工程の設計とシステム構成要素の設計
    • 1 2つの設計:「工程」の設計/「システム構成要素」の設計
    • 2 工程の設計
      • 2-1 概念設計
      • 2-2 基本設計
      • 2-3 詳細設計
      • 2-4 外部設計
      • 2-5 内部設計
    • 3 システム構成要素の設計
      • 3-1 本書で解説するシステムの構成要素
      • 3-2 各要素における設計について
  • 1.3 「よい」設計とはなにか？
    • 1 よい設計とは
    • 2 よい設計 (その1) 要件を満たす設計
    • 3 よい設計 (その2) 網羅的な設計
    • 4 よい設計 (その3) 設計要素の一意性を確保した設計
    • 5 よい設計 (その4) 矛盾のない設計
      • 5-1 処理内容の矛盾
      • 5-2 データライフサイクルの矛盾
    • 6 よい設計 (その5) 運用を意識した設計
  • 1.4 課題・未決事項を洗い出す
    • 1 課題・未決事項の洗い出し
• 第2章 設計へのインプット 〜要件定義工程の概要〜
  • 2.1 本章の構成
  • 2.2 業務要件を確認する
    • 1 対象業務を確認する
    • 2 業務の登場人物 役割を確認する
    • 3 業務フローを確認し、粒度を整理する
    • 4 タスク定義を確認する
    • 5 動作場所を確認する
  • 2.3 機能要件を確認する
    • 1 機能一覧における機能の粒度を確認する
    • 2 機能の事前条件・事後条件を確認する
  • 2.4 データ要件を確認する
    • 1「概念モデル」でデータを確認する。
    • 2 主たるデータのライフサイクルを確認する
  • 2.5 外部連携要件を確認する
    • 1 外部連携一覧を確認する
    • 2 外部連携方式を確認する
      • 2-1 ファイル連携 (ETL)
      • 2-2 データベースによる連携
      • 2-3 APIの提供による連携
      • 2-4 メッセージによる連携
  • 2.6 システムの状態遷移を確認する
    • 1 要件で取り扱う「状態」
  • 2.7 非機能要件を確認する
    • 1 システムの価値を保つために重要な、非機能要件
• 第3章 設計の前にやるべき作業 〜共通設計〜
  • 3.1 全体設計 〜システム構成を明確にする〜
    • 1 システム境界図を作成する
    • 2 システム鳥瞰図を作成する
    • 3 サブシステム連携概要を作成する
  • 3.2 アーキテクチャ方針を作成
    • 1 オンラインアプリケーション方針
    • 2 帳票出力方式
    • 3 ジョブ管理・実行方針
  • 3.3 標準設計を行い、チーム作業を円滑化
    • 1 文書テンプレートを共有する
    • 2 記述粒度ガイドライン
    • 3 設計標準
  • 3.4 共通設計で整合性を高める
    • 1 「画面共通」について
      • 1-1 クライアントが動作する環境
      • 1-2 画面分類
      • 1-3 共通画面
      • 1-4 画面レイアウト、
      • 1-5 デザイン共通
      • 1-6 利用できる画面部品の定義
      • 1-7 エラー画面方針
      • 1-8 命名 表現規則
      • 1-9 ポリシー
      • 1-10 項目チェックルール
      • 1-11 部品選択ルール
      • 1-12 ボタンの配置ルール
      • 1-13 項目の分割ルール
    • 2 「帳票共通」 について
      • 2-1 改ページ
      • 2-2 データあふれ
      • 2-3 ページ数制御
      • 2-4 プリンタ制御
      • 2-5 基本フォーマット
      • 2-6 エラー処理方針
      • 2-7 再印刷
      • 2-8 利用できる表現形式
      • 2-9 フォント・色
    • 3 「バッチ共通」 について
      • 3-1 バッチ種別
      • 3-2 バッチの処理粒度
      • 3-3 リラン (再実行) 方針
      • 3-4 バッチ処理時間帯
      • 3-5 エラー処理方針
      • 3-6 トランザクション処理方針
      • 3-7 バッチの実行状況
  • 4「DB共通」 について
    • 4-1 命名規則
    • 4-2 ドメイン定義
    • 4-3 サロゲートキー、ナチュラルキー
    • 4-4 テーブル区分
    • 4-5 コード体系
  • 5 「メッセージ共通」について
    • 5-1 ID
    • 5-2 メッセージ文言
    • 5-3 多言語対応
• 第4章 アプリケーション設計としてやるべき作業
  • 4.1 アプリケーションの複雑さ
    • 1 アプリケーションの複雑さを段階的に把握する
    • 2 機能の複雑さを段階的に把握する
      • 2-1 第1段階
      • 2-2 第2段階
      • 2-3 第3段階
      • 2-4 第4段階
  • 4.2 機能の粒度と、 機能間の関係を整理する
    • 1 「機能粒度の明確化」 が設計の極意
      • 1-1 機能レベル0 組織全体のレベル
      • 1-2 機能レベル1 部署間の連携業務のレベル
      • 1-3 機能レベル2 部署内の対象業務のレベル
      • 1-4 機能レベル3 業務機能を実現するための機能
      • 1-5 機能レベル4 アプリケーションの一動作を表す機能
      • 1-6 機能レベル4の具体例
    • 2 機能粒度を明確化した具体例
  • 4.3 入出力設計のまとめ方
    • 1 画面設計 〜メニューや遷移、入出力をまとめる〜
      • 1-1 メニュー
      • 1-2 画面遷移図
      • 1-3 画面一覧
      • 1-4 画面項目設計
    • 2 帳票設計 〜一覧と明細をまとめる〜
      • 2-1 帳票一覧
      • 2-2 帳票詳細
    • 3 DB設計 〜データの整合性をつねに意識する〜
      • 3-1 ER図
      • 3-2 テーブル定義
      • 3-3 ドメイン定義
      • 3-4 コード定義
      • 3-5 DB設計でのポイント、
    • 4 外部連携設計 〜連携方法と連携先を明確にする〜
      • 4-1 外部連携一覧
      • 4-2 連携方式
  • 4.4 処理詳細設計を行う
    • 1 処理パターン共通で検討すべき内容
      • 1-1 入出力パターン分析
      • 1-2 マトリクスによる整理
      • 1-3 処理の統合
      • 1-4 処理の設計
    • 2 オンライン機能 〜画面の表示 参照 更新機能を設計〜
      • 2-1 画面を表示する機能
      • 2-2 検索して情報を表示する機能 (参照)
      • 2-3 画面の情報を永続化する機能 (更新)
    • 3 バッチ機能を設計する
      • 3-1 バッチ一覧
      • 3-2 処理詳細
      • 3-3 バッチで留意する点
  • 4.5 機能間の整合性を確認する
    • 1 DFDでデータとインタフェースの構造を確認
    • 2 CRUDで機能とエンティティの関係を確認
    • 3 状態遷移図で状態と機能の関係を確認
• 第5章 運用設計
  • 5.1 運用とは
  • 5.2 ITIL
    • 1 サービスオペレーション
      • 1-1 イベント管理。
      • 1-2 インシデント管理
      • 1-3 問題管理
      • 1-4 要求実現
      • 1-5 アクセス管理
      • 1-6 サービスデスク
    • 2 サービストランジション
      • 2-1 変更管理
      • 2-2 サービス資産管理および構成管理
      • 2-3 リリース管理および展開管理
  • 5.3 設計の側面
    • 1 要件の確認
    • 2 運用設計のまとめ方
      • 2-1 体制
      • 2-2 運用管理方針
      • 2-3 運用管理項目
    • 3 要素設計
      • 3-1 監視方針設計
      • 3-2 バックアップ・リストア方針設計
• 第6章 アーキテクチャ設計としてやるべきこと
  • 6.1 アーキテクチャとは?
    • 1 アーキテクチャの概要
  • 6.2 システムアーキテクチャについて
    • 1 インフラ 〜システムの土台となるハードウェア/ミドルウェア〜
      • 1-1 サーバ (ハードウェア)
      • 1-2 ネットワーク
      • 1-3 ストレージ
      • 1-4 OS
      • 1-5 ミドルウェア
  • 6.3 アプリケーションアーキテクチャについて
    • 1 アプリケーションのレイヤー構造について、
      • 1-1 MVC アーキテクチャに基づくレイヤー構成
      • 1-2 MVCアーキテクチャ2の拡張
    • 2 レイヤー間のインタフェースと相互作用 (インタラクション)
    • 3 レイヤーにおける実装方針
  • 6.4 アーキテクチャ設計上のポイント
    • 1 データ整合性 〜非機能要件として重要な要素〜
      • 1-1 トランザクション
      • 1-2 データ更新タイミングとロックについて
      • 1-3 マスタ系履歴方針を決める
      • 1-4 データ削除方針
      • 1-5 補正トランザクション方針
    • 2 セキュリティ
      • 2-1 認証
      • 2-2 権限管理
      • 2-3 セッション管理
      • 2-4 暗号化
    • 3 例外処理の設計
      • 3-1 例外の種類
      • 3-2 例外の処理方法
    • 4 ログ出力の設計
      • 4-1 ログフォーマット
      • 4-2 ログ出力先
      • 4-3 ログ出力タイミング
    • 5 メッセージ管理
    • 6 性能を実現するためのポイント
      • 6-1 性能要件における4つの視点
      • 6-2 性能要件を満たすためのアーキテクチャでの工夫
    • 7 可用性を高めるためのポイント
      • 7-1 可用性要件
      • 7-2 アーキテクチャでの配慮
• 第7章 本書の知識を現場で活用するために
  • 7.1 詳細設計工程を理解する
    • 1 アーキテクチャに基づく、 設計要素の分割・分類
    • 2 レイヤーごとに詳細設計を行う。
      • 2-1 画面の部品の割り当てと物理名の決定
      • 2-2 イベント詳細
      • 2-3 その他レイヤーの処理詳細
    • 3 抽象化と共通化について
  • 7.2 アジャイル開発との関係
    • 1 なぜアジャイル開発を取り上げるのか
    • 2 アジャイル開発でも設計は行う
    • 3 どの開発手法においても基本は同じ
    • 4 アジャイル開発によるさらなる成功を
• 付録
• A1 演習の解答例
• A2 参考図書
• 索引