プログラム設計書の良い部分と悪い部分 - GeekFactory

設計書の定義は、おおよそ開発標準や慣例で決まっています。逆に言うと、設計書名やその中身を書くと社名がバレるかもしれません。だからみんな書きたがらないのでは。中でもプログラム設計書はベンダによる違いが大きく、結果的に技術力の差となることが多いです。 前回のエントリでは、プログラム設計書のすべてが不要と言っているわけではありません。 プログラム設計書には、良い部分もあります。内部設計では表現できない設計思想が書いてあるので、変更容易性が向上します。例えば、クラス図からは具体的にどんなデータを扱って処理しているのか読み取れます。そもそもの話ですがインタフェースが決まらないと分業ができませんので、他所と共有するメソッドは設計書に落ちている必要があります。小規模だと細かいメソッド名まで決めない場合もあるし、逆にprivateメソッドまで決めてから実装する場合もあります。 ただ、言語レベルの記述方法ま

[fuktommy]

この例だと"ビジネスルール"までしか作らないなあ。"手数料計算機能"以下はソース嫁。Web系だからね。

[tarchan]

あるある。このレベルの設計書だと設計のバグを人力で探さなくちゃならないので死ぬ。

[shozzy]

保守性向上したい（http://d.hatena.ne.jp/int128/20080330/1206882137にもある通り）⇒トリッキーなコードは書かせたくない⇒あえて「プログラム構造を日本語で書いた設計書」を書く　という流れもあるよ。

[okazbb]

なんと生SQLが記述されていてしかもそれが間違っていました！ステキ！

[katzchang]

「良い具体例」って無いものかな。

[terazzo]

これは良い整理。こうやって実例ベースで話をしないと論点がずれて話が噛み合ない。

[RanTairyu]

[]「もっと面白くて良い例があれば教えて下さい＾＾」

[gothedistance]

やべー、悪い設計書書いてるSIer多くね？