スポンサーリンク

◆ドキュメントの検収チェック・ポイントは?

システム開発

◆ドキュメント
 ドキュメントは無くてもシステムは動く。しかし、納品物としてはプログラムと同様に重要なものである。一つには、要件定義や要求仕様が、確実にプログラムに盛り込まれているか、その作業過程の結果としての設計書試験報告書。もう一つは、システムの運用・保守に必要な情報源として。

 検査のポイントとしては、プログラムと同様、「美しさ」と「シンプル」が総合的な判断基準となる。さらに、要件定義書や要求仕様書から、プログラムに至までの追跡性(トレーサビリティ)が確保されていることが重要である。ところが、システム構築のスケジュールが切羽詰ってくると、このドキュメント整備にしわ寄せが来て、手抜きされることが少なくない。追跡性も不明確、運用・保守にも使えない、そのようなドキュメントを大量に納品してもらってもゴミになるだけだ

 設計書のチェック・ポイントは、レビューでも述べたように上位の要求事項及び下位のプログラムとの追跡性が、確保されているかどうかが重要である。どんなに美しくまとめられていても、その設計結果が、どの要求事項に対するものか、どのプログラムに反映されているかが、すぐに分かるように記述されていなければ、要求事項が、設計書とプログラムに確実に反映されているかどうかを確認することが困難であるばかりでなく、保守においても使いづらいものとなる。

 特に、保守においては、プログラムの保守性を補完するものであるので、プログラムとの関連性が不明確なようでは、結局、プログラムを解読しなければならなくなる。最悪の場合、どのプログラムを解読すれば良いのかさえも分からなければ、全体を虱潰しに調べるハメになる。これでは、何のために費用を出して、大量のドキュメントを作成してもらったのか分からなくなる。したがって、納品検査においては、実際に保守をするという前提で、ドキュメントが使い物になるかどうかをチェックする必要がある。そのような目で、見てみると結構、基本的な情報が欠けていたりする。

 個々のプログラムや設定の内容については技術的に詳細に記述しているわりに、肝心のプログラムが、どこにどうやって保管されているのか、設定内容を変更するには、どうやったらよいのか、システムの全体構成プログラム間、データ間の関連がどうなっているのか等が記載されていないこともある。こういった、基本的な情報は、プログラムを作った本人からすれば「知っていて当然」のことであるため、ついつい記述を忘れることが多い。ところが、第三者がプログラムを保守しようとすると、こうした基本的な入り口でつまずき、結局、業者に問い合わせなければ分からないということになる。

 前述した「プログラマーズ・マニュアル」の記載事項を参考に、これらの情報が漏れなく記載され、ドキュメントに従って、実際に保守ができるかどうかを確かめて欲しい。その上で、不足の情報があれば、追記するように業者に申し入れよう。

 試験報告書のチェック・ポイントも、設計書と同様に追跡性は重要である。各試験結果が、それぞれ、どの要求事項、設計書、プログラムに対応するものであるかが、明確になっていなければならない。基本的には、単体試験は、各プログラムに対する試験結果、統合試験結果は、各設計結果に対する試験結果である。さらに、期待したような結果が得られたことを確認できるように、処理結果を表示した画面のハードコピーや、ダンプリストマーキング、付番等して該当の設計書やプログラムと対応付けしてあること。これなしで、大量の画面コピーやダンプリストを添付してあるだけでは、試験者が本当に試験結果を確認したのかどうかを事後確認することができない。また、試験結果は、正常に処理されたケースだけではなく、不正に処理されたケース、例外処理に対して処理されたケースなどが含まれているかを確認する。 

コメント

タイトルとURLをコピーしました