仕様が固まった後に作成するドキュメントは、プログラムと一対一になるようなドキュメントではない。そんなのはプログラムを見ればすむ話だから。メンテナンスする人が必要になるドキュメントを書く。メンテナンスする人にとってはドキュメントは必要ですよ。全部ソース読めはきつい。
http://d.hatena.ne.jp/higayasuo/20080721/1216607451
メンテナンスに必要な設計書ってどんなだろうか。
現在システムテストの段階にあるプロジェクトに参画しているので、
出来上がりつつあるシステムを見ながら考えてみる。
機能概要は必須だ。
機能の一覧よりは、要件の一覧が良い。
例えば、「商品データのメンテナンス機能」だとしたら、
登録ボタンを押したら、画面の入力に従って商品データが登録される
その際に、「商品テーブル」と「価格テーブル」と「価格履歴テーブル」にデータが登録される
とかじゃなく、
・セール期間は価格を下げ、セール期間後に価格を戻すことを可能とするために価格履歴を管理する。
・商品価格の変遷は、経営戦略上も重視しており、1年まえの同時期と比較する要件がある。
・3年分の価格変遷は追えること。
っていう要件。
データベース定義よりもエンティティーのパターンを！
データベースに関する仕様がハッキリしていると、保守メンテナンスのやりやすさは全然違う。
テーブル定義などは、それこそスキーマ情報を引っ張って来ればいいので、全く不要。全体のERがあればこと足りる。
それよりはデータベースの区分値の意味や、
既知のイレギュラーなデータパターンが、大きなポイント。
売上管理っぽいシステムで考えてみよう。
予約された商品が、予約取り消しされたレコードはどうなっているか。
返品された商品は、在庫上どうなっているか。
など、これも業務要件のパターンに合わせて書かれているとわかりやすいと思う。
どこでどのデータが書き変えられるのか？
どこでどのデータが書き変えられるのか？がわかると、よりメンテがしやすい。
詳細なデータフローダイアグラム（DFD）のようなもの？かな、
しかし、これは膨大な労力がかかるから、データベースの初期設計段階で作っていなければ
後付けで作るのは骨が折れます。
継続予定。
