開発会社さんにWebシステムを開発して貰っていますが、色々な経緯からマニュアル以外のドキュメントが一切ないシステムを引き継ぎ、現在ディレクションを行っています。

http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=22248&am...

ここでいうところの「要件定義書」は必須。基本設計書はあれば、尚、良し。

詳細設計書と基本設計書はソース類から書き起こすことはできますが、要件定義書に込められたお客さんの想いを行間から読むのは大変ですからね。また、潜在バグがあり、仕様を誤認する可能性もあります。

外部設計的なところで

・画面遷移図・画面設計書（ボタンを押したらどういう動きをするなどを記述）

内部的なところで

・DB設計書（これはツールがあれば自動生成可能ですね。OracleだったらObject browser等）

・クラス設計書・内部設計書（JavaあたりではJavaDocが詳しく記述されていれば代用になるかと思います）

とまあ、小手先の対応でよければこの程度でも何とかなります。

一番重要なのはやはり内部設計書でこれと実際のソースコードを見てどこに変更が入りそうなのか当たりをつけることができます。

クラス一覧のような物を作ってクラスの継承関係や簡単な説明をつける。

クラス個別に定数値やクラス変数、メソッドなどの説明をつける。メソッドは引数・戻り値・処理の流れの説明は最低限必要。

DB設計書はテーブルごとの想定件数を書いておくとSQL文の最適化に役立つかもしれません。

あとは、概要設計書的なもので対象業務の流れを説明した物があると仕様変更の際に背景を知ることができよりよい提案ができるかもしれません。

・ER図

・クラス図

・ソース

が最低あれば、なんとかなると思います。

特にDBは、テーブルとその列が何のためにつかわれているか

わからないと、怖くて更新すらできません。

ソースがあれば、なんとか解読できると思いますが、

クラス図は、漏れがないかをチェックするために使えば

いいじゃないでしょうか？

あとは、ユースケース図、シーケンス図があれば、

なおよしって感じですね。

サーバーが別々なのであれば、インフラ関連の設定書は、

欲しいところです。

昔、javaのclassファイルしかない業務を引き継ぎましたが

上記があれば、なんとか対応した覚えがあります。

基本設計書は必ずあるはずです。これは最低限いります。

これがなくてつくることはありえません。

http://www.thinkit.co.jp/free/project/4/3/1.html

DB設計書でも、きちんとその項目の意味とか使用目的が

書いてないのはＮＧです。

＞クラスに関しては、そういう感じの綺麗なコーディングで

＞はないと思われるので、今回は見送ろうかと思っています。

あと、細かいプログラムは諦めるとして、

フレームワークとかそういうブラックボックスになる要素を

つかってるのなら、システム構造がわかる資料がないと

ソース解読は難しいかもしれません。

方式設計というか構造設計書みたいなもの。

例：strutsをつかってるとか・・。

---------

　　Javaなら、JavaDOCがきちんとできてるのなら良いですが。