• ホーム
• ソフトウェア工学
• プログラミング

品質評価

品質の高いソフトウェアを開発するには，ソフトウェアの試験段階で適切な品質評価データを収集し，品質の分析と評価を実施していく必要がある．

品質管理単位

品質管理単位とは，ソフトウェア開発の過程において品質の評価や管理を行う基本的な単位のことである． 品質管理単位は，一般にソフトウェアの開発工程に対応して決定される．品質管理の対象は，プログラムおよびドキュメント（設計書，マニュアル等）である．

ソフトウェアの開発工程と品質管理単位との一般的な対応は以下である．

1. 基本設計 (BI)
   品質管理単位：システム全体またはサブシステム単位
2. 機能設計 (FD)
   品質管理単位：サブシステム単位またはプログラム単位
3. 詳細設計 (DD)
   品質管理単位：プログラム単位（ライブラリなどの共通モジュールは別の単位）
4. 製造 (M)
   • コーディング (M1)
   • ソースコードレビュー (M2)
   • 単体試験 (M3)
   品質管理単位：モジュール単位
5. デバグ (DB)
   • 結合試験 (DB1)
   • 総合試験 (DB2)
   品質管理単位：プログラム単位またはサブシステム単位

試験と品質評価データの収集

品質を評価するためには，試験とともに品質評価データを収集しなければならない． プログラム試験と品質評価データ収集の一般的な手順を示す．

• 試験項目の抽出
  プログラムチェックリスト (PCL) を作成する．
  1. 単体試験工程
     a) 対象範囲は，少なくとも次のモジュールを対象とする．
     • 共通モジュール
     • 特殊なアルゴリズムを用いているなど，難易度の高いモジュール
     b) 試験項目は，カバレッジ率の目標値を満足するように網羅的に設定する．
     c) 試験項目は，詳細設計書（モジュール票やフローチャートなど）から抽出する．
  2. デバッグ工程
     a) 試験項目の消化は，マシンによる試験で行うことを原則とする．マシンによる試験が困難な試験項目については，その理由と机上での確認方法を明確にする．
     b) 試験項目は，機能設計書および基本設計書 (あればマニュアル) から抽出する．
• 試験手順書の作成
  試験項目を消化するための試験手順，消化基準を明確化し，試験手順書として文書化する． 机上でしか確認できない試験項目は，その確認手順とその基準を明記する．
  一般に，BI 工程から M2 工程の間は，机上レビューとなる．
• 試験の実施と不具合点の摘出
  1. 試験手順書に従い試験を実施する．
  2. 欠陥，改善点および不明点を摘出し，その内容を記録する．
• 不具合点の解析・変更・修正確認
  1. 個々の不具合点を解析し，バグ内容，バグ原因，およびバグ摘出遅延理由の分類を行い記録する．
  2. 不具合点に関する変更，修正内容の確認を行う．(==> 品質評価と処置を参照)
• 品質データの収集
  不具合の摘出状況，解析状況および修正・確認状況を把握する．
  1. 定期的に，品質データに対して次の集計を行う．
     • 品質管理単位別消化試験項目数
     • 摘出バグ数
     • 解決バグ数 (修正しその確認を終了したバグの件数)
     • バグ分類（重大なバグが摘出されているかどうか）
  2. 試験項目消化およびバグ摘出・解決数については，その計画と実績の対比を時系列で示す「品質管理図」を作成する．

品質評価と処置

品質データの収集中途時点および収集完了時点で，品質データを分析し品質目標の達成状況を判断する．また，各々の時点で明らかになった問題に対する処置を行う．

• 品質データの評価
  品質管理指標の集計状況，目標値達成の中間的状況，および大きな状況の変化（致命的な欠陥の摘出など）を把握する．
  次の観点から問題点を発見し，その原因を探る．
  1. 品質管理計画に問題はないか（プロセスの品質不良）
     • 試験方法について
       試験は網羅的か，試験は正確か, 試験の進捗は順調か，試験不良（試験漏れ，試験手順誤り，品質データ収集漏れなど）が特定の者に集中していないか 等
     • 品質目標について
       品質目標は妥当か， 品質管理単位の設定は妥当か， 品質管理体制は妥当か 等
  2. 製品および中間品の品質に問題はないか（プロダクトの品質不良）
     
     • 欠陥が多すぎないか
     • 重大な欠陥がでていないか
     • 欠陥が，特定の箇所（作成担当や品質管理単位など）に集中していないか
     • 解決が遅れている問題が放置されていないか
  
  品質データの収集完了時点では，すべての問題が解決されていることを確認し，最終的に品質目標が達成できているか否かを判断する．
• 品質分析の観点 (試験途中)
  • 試験項目の消化が，計画より大幅に遅れている場合
    • 試験項目数・試験内容に対応した試験時間・要員数が割り当てられていない．
      試験の効率化を図る．不可ならば，マシン時間増・要員増を考える．
    • 試験項目の消化日程配分が不適切である．
      進捗回復策も加味して，試験項目の消化日程配分を見直す．
    • 試験手順書が不適切である．
      進捗回復策も加味して，試験手順書を見直す．
  • 試験項目の消化に対応した摘出バク数が計画を大きく下回る場合
    • 試験対象が全体の機能を網羅していないと判断できる場合，試験対象の偏りや重複をなくす．
    • バグ摘出密度の目標値が不正である（ 高すぎる）と判断できる場合．バグ摘出密度の目標値を再設定する．
  • 摘出バグ数が，試験途中で目標値を超える場合
    • 前工程での品質作り込みが不良であると判断できる場合，摘出されたバクの傾向を分析し， バク作り込み工程に戻って類以バグの一掃を図る．
      ・M2（単体試験，机上デバグ）の見直し
      ・DD（処理フローのレビューなど）の見直し
    • バグ摘出密度の目標値が不正である (低すぎる) と判断できる場合，バグ摘出密度の目標値を再設定する．
    • 特定の箇所（モジュール，機能，担当者）の品質が極端に悪い場合，該当箇所の周辺について， 試験項目・試験手順を見直し集中的に再試験（あるいは，追加試験）を行う．極端な不良モジュールについては作り直しも考慮する．
  • 摘出バグ数はほぼ計画どおりだが， 未解決バグ数が増加傾向にある場合
    • ハードウェア，OS などの前提環境に製品固有の欠陥があり，欠陥の解消が期間内にできない場合は，期間延長，機能の修正/削減などを調整する．
    • 上流工程（BI ，FD）のバグが多く存在し，設計変更による手戻りがあ場合，責任の所在を明らかにし，計画線表の修正等を調整する．
    • 障害解析者のスキルあるいは稼働が不足している場合，試験を中断し，試験担当を解析に回すなどして障害解析を優先する．
• 品質分析の観点 (試験完了) 試験完了時点で摘出バグ数が
  • 収束していない場合
  • 目標値を大きく下回る場合
  • 目標値を大きく上回る場合
  のとき，次の観点から状況を判断し適切な処置を行う．
  • バグ摘出密度の目標値が不正である (高すぎる，あるいは低すぎる) と判断できる場合，バグ摘出密度の目標設定方法を見直す．
  • 試験手順が妥当でないと判断できる場合，摘出バグの傾向を考慮に入れながら，試験項目の抽出方法・試験手順を見直し，追加試験を行う．
  • 試験対象の選択が不適切か， 試験項目が不足していると判断できる場合，試験が不十分な箇所の追加試験を行う．特に，机上チェックのみの機能・ルートに留意する．
  • 特定の箇所（モジュール，機能，担当者）の品質が極端に悪い場合，問題箇所を特定し，関連する試験項目・試験手順を見直し，集中的に再試験（あるいは追加試験）を行う．極端な不良モジュールについては作り直しも考慮する．
• 問題点の処置
  問題の原因が，品質管理計画 (プロセス) にあるのかプロダクト (管理対象の製品) にあるのかを判断する．
  1. プロセス不良の場合
     品質管理計画を見直して，品質データの収集，評価，および処置を再度行う．
  2. プロダクト不良の場合
     品質不安箇所を対象にして，品質管理のやり直しを行う．その際，極端に品質が悪ければ，その箇所の作り直し（さらに上流の工程への手戻りを含む）を行う．

／