 |
||||||||||||||||||||
|
||||||||||||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||||||||||||
|
||||||||||||||||||||
| 最初から高い精度で臨むことが肝心 | ||||||||||||||||||||
|
「スペックパターン開発プロセス」に限らず、業務や要求の理解についてできるだけ早くから「高い精度」で行わなければ、いくらドキュメントの保守性を高めたところで、必要とされる労力とのバランスがとれなくなってしまいます。 そうなるとドキュメントは混乱し、「作りやすさ」が実現できなくなってきます。これがひどくなるとシステムは「作れない」ものになってしまい、それでも何とか作ったことにしようとしますので、「使いやすさ」も犠牲になります。 |
||||||||||||||||||||
| 参照性（コレだけ） | ||||||||||||||||||||
|
最初の「コレだけ（各項目に共通する情報を別資料にまとめるという方法を用いるのは極力避けなければならない）」については以前紹介した通り、「バラバラに記述されている情報をプログラマが各個に組み合わせて1つの動作を実現したところで、それが間違いでないということは、できあがって実際に見てからでないとわからない」という事実からです。 極力、「この文書だけを見ればコーディングができる」「あちこちの文書を捜さなくてよい」という考え方でドキュメントを作成する必要があります。 よく見る仕様書は一般的な表計算アプリケーションやワープロなどを、特に保守性についての考慮のない運用の中で使用して作成しています。そして作る立場の仕様策定者からすれば、実際の顧客業務など詳細に知っていることを自分なりの解釈によって時間をかけて分類・分解し、それぞれ別々の文書データとして記述していきます。 個々の情報だけを見ても、そのほとんどがそれだけでは完結しません。その上、参照すべき情報や文書の情報が口頭での説明のみであったり、参照箇所の記述がしっかりと保守されておらず、間違っていることもあります。また完結している情報もそれが本当に完結しているのか、それとも他に記述がないかはっきりとわからないこともしばしばです。 言い換えると、「他の文書にはこの情報に関連する記述は一切ない」という読む人に向けた仕様書記述を過去に見たことがないのですが、これが問題の本質だと思っています。 つまり、仕様書がそれを見て作る人のために書かれているのではなく、実はほとんどの場合は仕様策定者の分析過程記録、備忘録的な観点のみで書かれるようになってしまっているということです。ですので、理解を細かく分解して共通点をまとめるというような流れになっていきます。 「スペックパターン」が実現したいのは、「プログラマが仕様書を見れば、どうコーディングすればよいかがわかる」ということです。しかし、事前に顧客から承認は得なければなりません。プロトタイピングは一見良さそうでいて、よほど簡単な開発でない限り大きな確率で混乱を招きます。 これらすべてを考慮した結果として生まれたのが、「承認者が承認する必要のある情報をコンピュータのプロフェッショナルではない人でも理解できるように記述して承認を受け、同じものを見てプログラマがどうコーディングすればよいのかがわかるように、事前に対応を取っておく」という「スペックパターン」の考え方です。 |
||||||||||||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||||||||||||
|
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
-
-
連載
