各工程で心がけたい思想を掘り起こしてみる
年末ですね。ということで開発の最後に片づける「ドキュメント整理」について考えてみます。
ドキュメント整理とは？
ドキュメント整理とは、要求仕様書とそれに対する上流工程から下流工程の設計書、試験仕様書など複数のドキュメントを紐づけて、一つの体系的なドキュメントとして完成させることですね。
どのように要求仕様、設計書を紐づけていくかはプロジェクト立ち上げの段階から規定されていることがほとんどなので、要求から設計書・試験仕様書作成し、ルールに従ってドキュメントを登録していけば、体系化させることにはそれほど手間はかからないはずです。
ルールでよくあるのは、各要求項目ごとにナンバリングして、その要求に対応するドキュメントやコードのコメントにもナンバーを記載していく、なんてのをよく聞きますね。設計仕様に記載される設計がどの要求に対応したもで、そのための試験がどの試験仕様書で表現されているか追跡できることが重要です。要求仕様、各設計書、試験仕様書が体系的に管理されていれば、機能漏れ、試験漏れを防ぐことができます。
設計変更
設計・コーディングが終わり、試験工程にはいると当然不具合が検出され、コード修正を繰り返し、製品の品質を上げていくことになります。大きな設計変更がなければドキュメント整理なんて楽なもんです。
ただ、途中で要求が追加されたり当初の機能設計ではもともとの要求にも対応できていない、なんてことも発生します。逐次設計書の修正・コード修正と段取りを踏めればよいのですが、大抵は設計追加・変更の簡単な資料を作っておいて、正式なドキュメントの修正は後回しになってしまいますね。
最新化
こうなると、ただのドキュメント整理に、設計仕様書・試験仕様書の最新化というひと手間が入ります。変更箇所が少なければそれほど辛くはないですが、不思議なもので変更が入る機能には山ほど変更がはいるんですよね。 ただし、ここでしっかりと最新化をしておけば設計資料は後継機開発の重要な財産となります。ここは覚悟を決めてしっかりと資料の最新化をしておきたいところです。
何か掘り起こせた？
- 体系的にドキュメント整理されていれば、実装漏れ、試験漏れを防ぐことができる
- 手間暇かけて最新化をしておけば、システムの財産となる。
逆に、ここができていないとせっかくの財産がいまいち役に立たないなんてことになります。流用元の設計書とコードを見比べたら、なんか違うことやってる、みたいなことも時々ありますね。
おしまい
他のメンバが後継機の初期検討に入っているのに自分だけまだドキュメント整理やってるなんてときは、なんとなくさみしくなります。
