システム設計の謎を解く 改訂版

システム設計

2018-05-06 22:45:30

システム設計の謎を解く 改訂版

  • 第1章 設計の謎
  • 第2章 設計へのインプット
  • 第3章 設計する前にやるべきこと
  • 第4章 アプリケーション設計としてやるべきもの?
  • 第5章 アーキテクチャ設計としてやるべきこと
  • 第6章 本書で得た知識を現場で活用するために
  • 付録
    • ・A1 演習の回答例
    • ・A2 参考図書

第1章 設計の謎

1.2 工程の設計とシステム構成要素の設計

3 システム構成要素の設計

p.16

  • 設計の共通ルール
    • 複数ある選択肢の中から適切なものを1つ選択する
      • 設計は選択である

3-2 各要素における設計について

p.20
  • 機能の洗い出し
    • 業務フロー、利用者の目的、システムの目的・施策などから洗い出すのがセオリー
    • 慣れないうちは画面からアプローチしてもよい

1.3 「よい」設計とはなにか?

1 よい設計とは

p.23

  • 要件を満たしているかどうか(要件とのトレーサビリティ)
  • 設計要素(デザインパターンや処理パターン)が網羅的に設計されているかどうか
  • 同じような設計要素(名称が違うが内容の違いが微少である要素)が複数存在しないか
  • 設計要素間で矛盾がないか
  • 運用を意識した設計になっているか
  • わかりやすい構造になっているか
  • 修正しやすい構造になっているか
  • テストしやすい構造になっているか
  • 再利用しやすい構造になっているか
  • 拡張しやすい構造になっているか

第2章 設計へのインプット 〜要件定義工程の概要〜

2.6 システムの状態遷移を確認する

1 要件で取り扱う「状態」

p.65

  • 要件定義で整合性を保つための記述方法
    • 定義・分類
    • 概要
    • 状態遷移
    • 機能

2.7 非機能要件を確認する

1 システムの価値を保つために重要な、非機能要件

p.67

  • システムが持つ価値としての機能の定義を機能要件とすると、その価値が損なわれないように定義されるのが非機能要件
    • 性能やセキュリティ、ユーザービリティ、運用など

第3章 設計の前にやるべき作業 〜共通設計〜

3.3 標準設計を行い、チーム作業を円滑化

2 記述粒度・ガイドライン

p.83

  • 設計文書を書く時の粒度や基準を明確にする

第4章

4.1 アプリケーションの複雑さ

p.118

  • アプリケーション設計の定義
    • どのように機能要件を満たすかを検討し、インプット、データ格納、アウトプットに分けること