第46回 ソフトウェア品質の品質評価2

ソフトウェア品質の品質評価2

前回に引き続いて品質評価についてお話しします。

プログラム製造工程の評価は、単体テストにおける不具合の測定となります。測定方法としてはプログラム規模、不具合件数の報告と共に、簡単な分類をすると効果的です。

単純なコーディングミス、設計書の解釈不足のよる不具合、設計書のミスによる不具合。

この分類で要注意は解釈不足です。熟練のプログラマーであっても共通仕様を無視したり勝手な解釈で処理をしたりすることが多々あります。設計作業でもプログラム製造作業でも不具合集計する際には担当者別に集計することが必要です。評価作業において全ての資料を均等に確認すると時間は膨大となります。技術的に指摘事項が多い担当者を抽出して確認することで効率的な評価を行うことが可能となります。

テスト作業の評価は、テスト計画書から行います。開発規模に見合ったスケジュールや要員計画を確認し、充分な工数が確保できているか。一般的には開発工程の3割がテスト工数に割り当てられます。金融や生命のリスクがあるシステムの場合は5～8割がテスト工数と考えられています。余談ですがJAXA（宇宙航空研究開発機構）からテストや妥当性確認（評価）に関する「IV & Vガイドブック: 虎の巻」（＊）が読みやすく参考になります。

私たちの対象とするシステムは、ここまで要求されませんがテスト作業の結果は評価の最重要項目となります。実行する「テストの密度」があります。開発規模（機能数・項目数）に対してテストケース（パターン）は適当か。システムの目的に対してテストの網羅性は充分か。テスト環境は適切か。非機能要求（あたりまえ要求）試験は考慮されているか。不具合管理はどのように行われているか。テスト作業で検出された不具合件数を測定、数値化します。プログラム規模に対して不具合の検出率を計算します。1回目のテスト、2回目のテストと検出率が減少するのが一般的です。

最後は、プロジェクトとしての出荷基準を設定し、その条件を満たし、誰が判定したかを確認します。テスト作業において、このようなプロセスがしっかり確立されているプロジェクトであれば問題が少ないと思われます。

最後にマニュアル（利用者文書）も評価の対象となります。利用者にとっても、運用管理者にとっても重要な情報となります。提供されている機能とマニュアルの内容が一致しているか。エラーや障害時に表示するメッセージが適切か。その場合の対処方法が適切に案内されているか。問い合わせ先など重要な情報が提供されているか。最近はマニュアルが無い場合があります。その際でも必要な情報が提供されることが必須ですので、提供されていない製品は評価外であると思います。

製品評価は、妥当性確認であると思います。客観的に評価できない分野ですが数値化と基準を設定することで明確になる範囲も広がります。品質保証部において、その作業範囲が議論されますが、本コメントをご参考に社内基準を作成することをお勧めします。

表-1：IPA「ソフトウェア品質説明のための制度ガイドライン」引用

＊JAXA「IV＆Vガイドブック：虎の巻」
宇宙航空研究開発機構Webサイト

次回は7月27日（木）更新予定です。