システム設計の概念的なことをまとめた。
「外部設計」と「内部設計」に分かれる
設計は「外部設計」と「内部設計」に分かれる。
プロジェクトによっては「基本設計」や「詳細設計」と表現することも多い。この表現も間違っていないが、内容がぼやけてる気がするので自分は好きになれない。
実際「基本設計」「詳細設計」といってるプロジェクトの設計書は、それぞれで何を定義すべきかがぼやけている場合が多い。
では「外部設計」と「内部設計」で何が違うかというと
「外部設計」では「ユーザーが見える範囲」の仕様を設計する。
「内部設計」では「ユーザーから見えないPG内部の作りこみ」の仕様を設計する。
ことになる。
外部設計
主に「利用者」観点での設計を行う。
「外からみた挙動」に着目し、機能がどのような振る舞いであれば業務を最適に実行できるかを考える。
設計する流れとしては
「機能コンセプトの明確化」
を実施したのち、
「画面のふるまい」「計算ロジック」「DBやファイルへのI/O」
に落とし込んでいく。
機能コンセプトの明確化
具体的には各機能ごとに以下を定義すること。
・誰が
・いつ、どんなときに
・何をするために利用する
機能一覧に表現してもいいし、各機能単位の設計書に表現してもよい。
業務フローと組み合わせて、システム全体の使い方が概ね理解できる粒度で記述する。
仕様の設計
機能コンセプトをもとに、以下の仕様を設計書に落とし込む。
画面のふるまいに関する仕様
イベント発生時にどのような動きをするか。
・初期画面表示時の挙動
・〇〇ボタン押下時の挙動
・エラー発生時の挙動
計算ロジックに関する仕様
イベントに起因して処理される計算ロジックを定義する。
DBやファイルへのI/Oに関する仕様
ファイルから取得した項目のDB項目へのデータ転送仕様
DBから取得した項目と画面項目へのデータ転送仕様
画面項目からDBへのデータ転送仕様
ポイント
機能単体の仕様と、この機能によって影響を受ける別機能の記述をしておくと、後工程テストで確認すべき内容がわかりやすくなる。
機能単体の仕様 →単機能テストで確認
別機能への影響 →結合テストでの確認項目
内部設計
主に「プログラム」観点での設計を行う。
設計を行っていく過程で共通化や機能分割により、外部設計とは単位が変わる可能性があるため、別設計書とする。
内部設計で考慮すべき主な観点
・外部設計を実現すること
・誰が見てもわかりやすいこと(意味のある単位でメソッド分割する)
・排他タイミング、排他範囲
・メモリを使いすぎないこと
・無駄にDBアクセスしないこと
・無駄な項目を取得してこないこと
・無駄なループをさせないこと
・無駄な更新をさせないこと
・無駄に個性を出そうとしないこと
・細かく書きすぎないこと(設計書のメンテナンスが大変、プログラム見たほうが早い)
経験的に気を付けていること
設計書の設計を事前に行う。
設計書の設計は下流工程中心にやってきた人に任せない。(細かすぎてメンテされない設計書ができあがることが多い。)
設計書不要信者はプロジェクトから排除する。
設計書が汚い人は要注意。(頭の中が整理されていないので品質が悪い場合が多い)
コメント