下流の設計に必要なこと

March 28 [Thu], 2013, 11:11
通常SEの卵は、下流の設計から経験をし、学んでいくことになります。

上流からおりてきた設計書を基に、より細かな下流の設計を起こしていきます。

まず、下流の設計は、上流の設計をきちんと受けていなければなりません。

プロジェクトの規模にもよりますが、下流の設計を行う際には通常、適当な範囲を複数人数で分担して取り組みます。

自分が担当した範囲について足りない箇所はないか、求められていない機能を勝手に追加していないかをきちんとチェックする必要があります。

コーディング担当者が、詳細設計に不明点があるので設計者に聞きに行ったら「基本設計を見て考えろ」と言われた、そんな話を聞きます。

しかし、それはダメな設計担当者です。

もちろん上流の設計と同じ事を書く必要があるなどと言うつもりはありません。

上流の設計は、開発するシステムのいわば「全体像」と「考え方」をまとめ上げるものです。

そして下流の設計は、それらを「どう実現するか」を明確にしなければならないのです。

たとえば、すなわち、下流の工程に必要な情報がきちんと記載されている設計書を書かなければなりません。

ファイル変換のプログラムを作成するとします。

Aというファイル形式のファイルをBというファイル形式に変換するプログラムだとします。

ファイル内に格納されている個々のデータについての説明があっても、両方のファイル形式の間で、個々のデータがどう結びつけるかを書いていなければ、プログラムのコーディングを行うことはできませんから、そこまできちんと書かなければなりません。

「入り」と「出」がつながっていることがわかるような書き方でなければならないのです。

「あとは勝手にやって」、「わからなかったら聞いて」、「行聞を読んで理解してね」、あるいは「暗黙の了解でわかるだろう」というやり方で下流の設計を行うSEがいますが、それはダメです。

かといって、どこまでもどこまでも詳細に書き連ねる必要があるかというと、そうではありません。

プログラマの裁量にまかせて自分で考えてもらってよい部分もあり、裁量にゆだねてはならなぃ、考えてもらってはダメな部分もあるのです。

それは仕様にかかわる部分であり、設計書に書いでなければならない部分です。

下流の設計の場合、「コーディング仕様書」はつくらずにプログラミングを行う場合もあります。

その場合は、あとの人が見てもわかるように、コードの中に必要な情報が埋め込まれている必要があります。

そこさえきちんとしていれば、「コーディング仕様書」というドキュメントをなくし、工程を短縮することができます。

また、どういうアルゴリズムを使うかなどを設計書におこさず、コーディング仕様書も作成しないけれど、プログラミング・ルlルがきちんとある、という場合もあります。

いずれにせよ、きちんと何らかの形で必要な情報を残さないと、メンテナンスや仕様変更の際に、時聞をかけて解析しなければならないという事態に陥ることになります。

http://xn--08jzira8dxe2kz91qo6is08c.net/