ラン

ソフトウェアの品質(その5:ドキュメントの品質)

ドキュメント検査は、
曖昧な点、不明確な点を残さないこと。

ドキュメントは、検査の合否判定基準であると同時に、
製品を構成するプログラム間のインターフェースを決定するものである。

合否判定基準やインターフェースが曖昧であると、
合否判定を誤ったり、インターフェース不良を発生させることになる。

また、マニュアルは使用者にとって製品の使用方法を知る唯一のものであり、
マニュアルの良否によって製品の評価が決まることもある。

従って、マニュアルの検査はプログラムと同様入念に検査を行う必要がある。

品質保証部門は、
各種ドキュメントのレビューに積極的に参加しなければならない。

レビュー実施後は、
「レビュー報告書」を速やかに作成する/させること。

【ドキュメンテーションの3原則】
1)正確であり記載漏れがなく、
2)わかりやすい表現で、
3)量が少ない。

ドキュメントの品質水準

設計工程では、
コーディング後のプログラム規模(ステップ)と同様に、設計規模を考える必要がある。

設計品質を測るための設計規模は、
ドキュメントのページ数あるいは機能数/クラス数/メソッド数/データ数などとします。
ページ数は作られた「物」を測るもっとも基本的な単位です。

例えば、ある設計工程において、
1機能に対する設計が10ページと100ページでは、その質も異なります。

ページ数を生産性/品質評価に使う場合は、
ドキュメント毎の重み(データベース設計書と業務処理設計書の違いなど)を考慮する必要もあり、どの単位を使うかは個々のプロジェクトで検討する必要があります。

下記の水準を目安として品質の管理をするが、プログラム分野ごとに毎期見直しを行い設定する。

・共通品質目標値
社内品質(機能仕様書の検査指摘件数等)の目標値設定を行い品質の管理を行う。

・固有品質目標値
固有(デザインレビュー件数等)の品質目標値を定め品質の管理を行う。

【設計工程での目標値】
設計工程でのドキュメントの十分性を定量的に評価するための指標となる値です。
作成ページ当りの不良摘出件数の粗密度の基準値と、
作成ページ当りのレビュー時間の粗密度の基準値があります。

なお、1つの設計工程内では、
設計不良件数は減少していきますが、
各設計工程(業務要件設計~詳細設計)では必ずしも設計不良は減少しません。
これは、テスト工程のようにはじめに物を作ってしまうのではなく、
各設計工程で個々のドキュメントを作成するためです。
このため、ある程度のレビュー指摘が出るのが正常であるため、
下記のようにページ当たりの不良件数を把握する程度で管理し、
全く不良が摘出されない/不良が多発するような異常なケースの場合だけ原因究明し対策にあたることが望ましい。

下記は、一つの目安であり、プロジェクトの特性により設定する必要があります。
目標値(不良摘出)1~10件/10頁
目標値(時間率)0.1~0.3時間/頁

【テスト仕様のドキュメント化の必要性】
トップダウンでの展開によるテストの内容を上流工程で定義することにより、
担当者個人に依存型のテスト工程からの脱却にある。
更に、ドキュメント化することにより、「テスト」そのものを「設計」し「レビュー」することが可能となる。
名前:
コメント:

※文字化け等の原因になりますので顔文字の投稿はお控えください。

コメント利用規約に同意の上コメント投稿を行ってください。

 

最近の「品質保証活動のあり方」カテゴリーもっと見る

最近の記事
バックナンバー
人気記事