バーニィの徒然なるままに

※スマホで表示がおかしくなる方はコチラ ※本サイトはJavaScriptを有効化して御覧ください
最終更新日:2014/05/21

論理設計、物理設計


必要スキル

コミュニケーション能力・・・★★★★~
プログラミング能力・・・★★★~★★★★★
経験・・・★★★~


論理設計、物理設計の仕事を大雑把に説明すると、

要件定義の内容を元に、
この設計書を見ればプログラムが書けるような設計書を作成する仕事です。


要件定義以上に、この工程はプロジェクト毎に全くやり方や作成物が変わります。
このページでは論理設計、物理設計という単語を使用していますが、
外部設計、基本設計、曖昧設計、詳細設計、プログラム設計など、呼び方もプロジェクト毎に違ったりします。

外部設計、基本設計、詳細設計と3段階に工程を分けていたプロジェクトもありましたので、、
呼び方や分け方はあまり気にしないで下さい。

経験上、「この内容は本来、論理設計としてこっちに書くべき内容だ。」
「この内容は物理設計に書くべき内容だから、この論理設計からは消しておいて」
と、拘りを持っている人もいましたが、それよりもプロジェクトで統一させるため、
決められたフォーマットに沿った内容で作成しましょう。



では要件定義の仕事を具体的に説明します。

なお、会社やプロジェクトによっては全然別のやり方の場合もあります。
管理人はWeb系のシステムエンジニアだったので、Web系の話になります。
組込み系はまた違うかもしれません。
一例として読んでください。

ここでは管理人が経験した中で一番多かったパターンで説明します。
最初に述べたように、プロジェクト毎に全く違いますので、論理や物理の分け方は参考程度でお願いします。

というか管理人自体も、論理設計、物理設計の本当?の分け方は知りません^^;
それくらいプロジェクトや会社、人によってそれぞれ違う定義を持っています^^;

・論理設計
主に概念的な設計になります。

具体的には、
画面間での遷移のやり方、遷移の方向(片方向なのか双方向なのか)。
などをエクセルなどの図で定義した画面遷移図。

画面の見た目をエクセルやパワーポイントなどで表現した画面設計書。
もしくは実際にHTMLで見た目だけ作成したモック(mock)。

データベース関連だと、テーブルの関連性を表現したデータフロー図。

システムを使用して印刷物を作成する機能があるなら、帳票設計書。
(帳票設計書とは例えば、コンビニのレシートをどのように表示させるかなどを定義したものです。)

システム間で値の受け渡しが複雑に行われる場合は、インターフェース設計書。

などを作成します。

いずれも要件定義書を元に、次の物理設計に繋げれるよう、
見やすい仕様書を作成していきます。

システムで考えられる限りのエラー内容、文章を定義したエラー設計書などを作成する場合もありますが、
いずれにしても、内部で使用する具体的な値などは論理設計では定義しない場合が多く、
次の物理設計にて、この論理設計も元にして、具体的な値も定義していきます。


・物理設計
論理設計を元により詳細に、これを見ればプログラムが書けるような設計書を作成します。

画面では、画面設計書もこちらに入る場合もありますが、
例えば、プロフィール入力画面があったとして、
「OKボタン」を押したときに、項目が入力されていなければ、
内部的にエラーコード「err_001」をログに残して、画面には「名前が入力されていません」というメッセージを出力する。
など、作成に必要な具体的な値、数値、文章などもここで定義します。

正常終了した場合は、次の画面に遷移する。
異常終了の場合は、メッセージを表示させて、ユーザーに入力を促す。
など、要件定義や論理設計、読み取れなければ要件定義に関わった人へ直接聞くなどをして、
具体的に記載していきます。


データベース関連なら、テーブル名:PRIFILE_TABLEには
NAMEとADDRESSというカラムがあり、それぞれデータ長はこれだけ確保する。
このカラムには具体的にはこのような値が入る可能性がある。
などを記載したデータベース設計書を作成します。

データ間でそれぞれ1対多、なのか多対多なのかを定義したER図もこちらで作成する場合があります。
(これは論理の段階で設計する場合も結構あった気がします^^;)

このように物理設計書をメインに、補足資料として論理、要件定義を見れば、
誰でもプログラムを書けるようにするのが物理設計の仕事です。


次の工程のプログラム作成者が、ここはどのような動作をするのだろう?と疑問を持つようなことがあれば、
それは物理設計者の実力不足や手抜きといってもいいです。
それくらい、この工程で全ての動作をはっきりとさせます。

そのため、プログラムについてはしっかり理解できており、
プログラムで何が出来るか、どのように書くかをすぐ思いつける実力をもっているのがベストです。

プログラム能力がなくても設計書は書けますが、実際にプログラムをしてみると、
実現するのがとても難しい。もしくは実現できない。でも、ちょっと仕様を変えるだけで簡単に実現できる。
という状況がよく起こります^^;






Copyright © 2014 barney.webcrow.jp All Rights Reserved.
ご意見、ご要望はこちらまで→webbarney80@gmail.com