さて久しぶりのプロジェクト技術ですが、実は今回は新たな試みとして、「」で書いている雑文を加筆訂正して、「」に載せるという技を使ってみました。まあぶっちゃけ本来こちらに書くべき事柄ですが、平日は時間が取れないので備忘録としてつかっているだけですが^_^;
ひと昔前、アマチュアプログラマとプロのプログラマの違いは、ドキュメントの作成量とエラー処理をどこまで入れているかにあると考えていました、実際大学の研究室や、優秀な高校生などが作成したプログラムなどはこの条件に当てはまっていました、どころが最近はフリーソフト文化が発達したためか、アマチュアプログラマでも従来のプロと同等がそれ以上のドキュメント、エラー対処を入れているようです、逆にプロと言われている人たちが、予算と時間と妥協に追われドキュメント少なし、エラー処理部分的にしか入っていないというプロジェクトが増えているようです。フリーソフト・自社開発ソフト・パッケージソフトは予算と時間がある程度自由になるので、そこらへんはなんとかなるのでしょう。
しかし、ドキュメントは作成しなければいけません、それは、ソース保守のためです。作った人がずっと保守してくれるならいいのですが、そうはならないのが世の常です。そこでいかに手間暇をかけずにいいものを作成するか、「詳細はソースのコメントとして入れる」「ソースの地図」「開発運用方法」「システム構成図」「ソース修正履歴」ここらへんでしょうか、特にソースの地図とは、これが必須です。
| A | 詳細 | こおが一番大変ですが、ソースのコメントとして入れます、まず、ファイル/オブジェクト単位で概要を入れ、変数・関数等にもなにをやっているのか記入します。ソースの変更時にも変更者、日付、変更番号(修正履歴一覧と同期させておくことがポイント)変更内容等を記述しましょう。 |
| B | 修正履歴一覧 | ドキュメント、ソースに変更を入れる場合はとにかく番号をここでつけて管理します。修正依頼者、修正者、修正日時、修正理由、修正内容が必須です。 |
| C | ソースの地図 | どのような機能があり、その機能がどこにあるのか、オブジェクト単位でもなんでもいいんですが、概要は図に書き、詳細は表にまとめましょう。 |
| D | 開発運用方法 | 開発用のハード、ソフトのVerや特記事項、そして再設定する場合のための手順。開発時のハード・ソフトの設定、使用方法の手順、さらにハード・ソフト設定時や利用時に苦労した点や注意事項をまとめておけば完璧でしょう。 |
| E | システム構成図 | ソースとは別に、システム全体の構成図、理論的な構成、ネットワーク上での構成等、色々ありますね |
まあ、ここらへんはもっとスマートな解説がいっぱい出ていますが、上記は私が実際に引き継いだり、引き継いでもらったりした中で、最低限の努力で最大の効果を得るため試行錯誤を繰り返した中で、まとまってきたものです。
ではでは