|
とかく設計書というと形式ばっていて、難しくて、書くのが面倒と思われています。
できれば書かないで済ませたいと思っている人も多いのではないでしょうか。
あるいは、逆に、やたらと形式的に厳密で複雑な設計書を書いている人もいます。
何か自己満足的ですらあります。
最近は特に様々な設計技法が紹介されていますが、基本を忘れ、表記法のみに溺れると、
余り役に立たない設計書ができ上がります。
設計書の基本は書くことより伝えることをより大切に考えます。
書きたいことを書くのではなく、読み手の気持ちになって書いてあげることです。
もちろん、厳密さが大事ではないと言っているわけではりません。
設計書には細かなこともきちんと規定すべきではあります。
しかし、数学的厳密さを極限まで追求すると、それはプログラムと同じレベルにまでなってしまい、
かえって判りにくくなってしまします。
設計書を書く上で注意して頂きたいことは次のことです。
（１）機能（何をどうするか）を中心に”わかりやすく”書く。
次工程の開発者やレビューする人に理解してもらうことが第一です。
（２）網羅的に検討しておく。
正常時だけでなく異常時、例外事項、制約条件など広い範囲を網羅して検討しておきます。
異常状態はできるだけ全ての組み合せを記述することは不可能ですから、
考え方を整理して記述することがポイントです。
異常状態と、そのときのアクションを表現するにはマトリクス（表）の形で記述すると判りやすくなります。
（３）図表だけでなく、デモ画面などのように動きのある媒体を含めて
総合的に”設計”を考えます。
要するに設計の狙いまで含めて理解してもらうことが大事なのです。
（４）設計対象以外の周辺との関係にも配慮しておきます。
・一番大事なのは”人の動き”です。システムを操作する人がどのように
動くのかが設計書から見えてこないといけません。
時間を追った動きが必要になる場合もあります。
センター運用者の操作も忘れないようにします。
・次に他のシステムのと関係です。つながりのあるシステムは何か、
タイムフローやインタフェースが記述されています。
（５）その他の考慮点
性能や信頼性、セキュリティ、移行システム、移行作業も検討して
おきます。
設計書の作成がプログラム開発の後回しになることも、しばしばあります。
設計書作成が後回しになると、他人への説明がついつい疎かになり、
プログラム・コーディングの表記を変えただけで設計書に代えてしまうことがありがちです。
でも、これでは紙数が増えただけで、内容的には意味がありません。
プログラムが修正されても設計書が変更されないことがあると、かえってトラブルの元になります。
特に外注業者に設計書作成も委託するときは、このような本末転倒のコーディングの翻訳に
ならないように気を付ける必要があります。
|
コメント（0）
