レベルエンター山本大のブログ

面白いプログラミング教育を若い人たちに

BLOCKVROCKリファレンス目次はこちら

メンテナンスに必要な設計書を、出来上がったシステムから考えてみる。

かなり前のひがさんのブログを引用

仕様が固まった後に作成するドキュメントは、プログラムと一対一になるようなドキュメントではない。そんなのはプログラムを見ればすむ話だから。メンテナンスする人が必要になるドキュメントを書く。メンテナンスする人にとってはドキュメントは必要ですよ。全部ソース読めはきつい。

http://d.hatena.ne.jp/higayasuo/20080721/1216607451

さて、メンテナンスに必要な設計書ってどんなだろうか。
出来上がったシステムを見ながら考えてみる。

機能概要は必須

機能の概要がわかるものが欲しいけど、
”機能”の一覧よりは、”要件”の一覧が良い。


例えば、「商品マスタデータのメンテナンス機能」だとしたら、

登録ボタンを押したら、画面の入力に従って商品データが登録される
その際に、商品テーブルと価格テーブルと価格履歴テーブルにデータが登録される

とかじゃなく、

・セール期間は価格を下げ、セール期間後に価格を戻すことを可能とするために価格履歴を管理する。
・商品価格の変遷は、経営戦略上も重視しており、1年まえの同時期と比較する要件がある。
・3年分の価格変遷は追えること。

っていうこと。

機能間の連携を一覧できる機能間見取り図のようなものがあれば嬉しい

ユースケース図に機能名が配置されている程度でもかまわない。

データベースのレコードの状態のパターンを!

データベースに関する仕様がハッキリしていると、保守メンテナンスのやりやすさは全然違う。
完成したシステムから逆算すると考えれば、テーブル定義などは、実DBからスキーマ情報を引っ張って来ればよく、ほぼ不要といえる。(それでも、全体のER図は便利。)


それよりはテーブルの意味や使われ方(標準的な更新タイミング)
データベースの区分値の意味や、既知のイレギュラーなデータパターンが、大きなポイント。


既知のイレギュラーなデータパターンって何かを、売上管理っぽいシステムで考えてみよう。

例)
予約された商品が、予約取り消しされたレコードはどうなっているか。
返品された商品は、在庫上どうなっているか。

など、これも業務要件のパターンに合わせて書かれているとわかりやすいと思う。


あと、どこでどのデータが書き変えられるのか?がわかると、よりメンテがしやすい。
詳細なデータフローダイアグラム(DFD)のようなもの?かな、
しかし、これは膨大な労力がかかるから、データベースの初期設計段階で作っていなければ、後付けで作るのは骨が折れますね。


→これってソースからリバースできないかな?
DIでやってればある程度できそうな気もする。