« ATMが多すぎるわけですが | トップページ | 天国と地獄、または、この道はいつか来た道 »

2008年5月17日 (土)

詳細仕様がどうでも良ければ詳細設計書は要らない

ということなのかもしれないですね。結局。

とくにWebアプリ開発だと、ほんとに「プログラミングレベルの設計書」までくると、一切要らない、と思うことも多い。ので、勘違いがよりいっそう発生しやすそうというか。で、そうであっても、すべての画面設計図にすべてのシーケンス図をつけてすべての入出力値を、みたいな超細かい設計書が要らんってだけで、シーケンスやなんかは絶対絶対、考える。し、紙に書いたりもする、Webアプリであっても最低限の「設計」はしないといけない。

プログラミングファースト開発でも「設計」は必要 (歩きつづける ゆり 咲きつづける)

私は、工学計算的なアプリを手がけることが多いのですが、”プログラム設計書”には、画面、帳票、DBの各項目ごとに、以下のようなことを書いてます。

  1. 単位
  2. 精度
  3. 丸めの方法
  4. 計算式、 計算方法
  5. データの取得方法

項目の数は、”中規模”のもので数百くらいはありますので、設計書の厚みも相当なものになりますね。実際、「これ(設計書)って、プログラムそのものじゃないですか」なんて言われたこともあったりします。

しかしねえ、現実問題、これをやらないと計算結果が正しくならんのですよ。

この手のアプリというのは、あるフェーズで計算した結果を、次のフェーズで使う、という構造を持っていて、入力出力が連なっているんですよね。そうすると、すべての項目の計算がすべて正確に”仕様どおり”でないと、正しい結果は得られないわけです。当たり前の話ですけど。

単位についての思い出

昔、画面作成を外注して、納品されたものを確認していたら、単位の表示に大量の間違いが見つかりまして。

"kl(キロリットル)"と”l(リットル)”を間違えるって... 千円と百万円を間違えて平然と提出してくる、コイツらの神経が信じられん...

という心情でしたねえ。顧客がアプリ使って、計算結果が1,000倍になって出てきたら、仰天しますわな。世の中には、絶対に許されない誤字というのもあるんですよね。数字というのは、まさにそれ。

データの取得方法

これは、計算方法と関係してきます。画面とDBテーブルとに単純に対応が付いたりはしないですね。

「DBのこのテーブルからこうやって取った値を、この計算式のこのパラメータに代入し、計算して画面に表示」

といった感じです。

テーブルからの取り方というのも、一筋縄ではなかったりしてね。

イベント 測定日時 測定値
A 4/1
B 4/2 51
B 4/3 53
C 4/4
A 5/1
B 5/2 62
B 5/3 64
C 5/4

センサーなんかで採った、イベントと測定値が時系列にはいっていて、測定日時が Ai < Bi,j < Ai+1 を満たす、 最も日付の新しい Bi,max の測定値を取得するとか。ある条件を満たす場合には、二番目に新しいものとか、まあ、そんな感じのがあります。

Webアプリって何?

Webアプリというのは、システムの方式であって、アプリの内容を指す言葉ではないですよね。例えば、JAXAのサイトには、軌道計算をしてくれるWebアプリがありますけど。

軌道情報提供サービス (JAXA)

これを、プログラム設計書なしで作れるプログラマって、普通にいますかね?

結局

簡単なアプリ、定番のアプリなら、プログラム設計書がなくても作れる、ということでしょうかね。私はそういったものを手がけたことがありませんので、いまいち、どんなものなのか想像がつきませんけど。顧客がわざわざ高くつくスクラッチの受託開発を依頼してくる、ということは、”簡単じゃない”、”一筋縄ではいかない”ということだと今まで考えていました。

設計書が必要かどうか、というのは、設計書の”粒度”の問題だけでなく、そもそも何のアプリを作るのか、によっても全く話が違ってくるのでしょうね。

|

« ATMが多すぎるわけですが | トップページ | 天国と地獄、または、この道はいつか来た道 »

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/80472/20991559

この記事へのトラックバック一覧です: 詳細仕様がどうでも良ければ詳細設計書は要らない:

« ATMが多すぎるわけですが | トップページ | 天国と地獄、または、この道はいつか来た道 »