品質評価指標

ソフトウェア開発における一般的な品質管理指標とその設定方法の例を示す.

設計書,マニュアル

機能設計書や詳細設計書などのドキュメントの品質評価指標である.

  1. エラー摘出密度
    単位規模 (またはドキュメント 1頁) 当りのエラー摘出数である. 特定の分野あるいは過去の類似事例がある場合は,開発規模よりもドキュメント枚数の方が適している.
      摘出エラー数/開発規模(ks)[件/ks]
     または,
      摘出エラー数/ドキュメント枚数[件/枚]
    
  2. エラー分類
    次の観点から分類したエラーの分布状況
    • エラー内容
    • エラー原因
    ここで,すべての観点のチェックが終了した段階で,次の状態になっていることを目標とする.
    • 致命的なエラーが出尽している.
    • エラー原因が除去されている.
  3. レビュー密度
    単位規模当りのドキュメントをチェックする稼動 (人時) である.
      チェック稼働(人h)/開発規模(ks)[人h/ks]
    
  4. コメント密度
    単位規模当りのドキュメントに対するコメント数である.
      コメント件数/開発規模(ks)[件/ks]
    
    品質管理単位の構成要素間でコメント密度が均質でない場合は,全ての構成要素のコメント件数の和を目標値とする.
    コメント件数 = Σ(コメント密度*開発規模)
    

プログラム

品質評価指標の目標値の設定

品質評価指標として,以下の指標の目標値を設定する.
  ・エラー摘出密度
  ・レビュー密度
  ・コメント密度
  ・試験密度
  ・バグ摘出密度

これらの指標の目標値を算出する式の例を示す.

目標値 = 1.基準値 × 2.プログラム難易度
          × 3.開発技術難易度 × 4.要員スキルレベル

上記の式は,基準値をもとにプログラム難易度,開発技術難易度,および要員スキルレベルを補正係数として目標値を定めるものである.各々の補正係数の設定方法の例を以下に示すが,これらの値は経験的ならびに試行錯誤的に調整すべきものである.なお.この他に特定の要因が考えられる場合は.補正係数として追加すれば良い.

すべての観点のチェックが終了した段階で,品質評価指標が目標値の範囲内にない場合は,品質不良(またはチェック不足)と判断する.

  1. 基準値
    過去の実績の平均より設定する.設定例を示す.
    • 設計工程
      設計工程 エラー摘出密度(件/ks) レビュー密度(人h/ks) コメント密度(件/ks)
      機能設計書 5 ~ 10 2 ~ 4 10 ~ 20
      詳細設計書 6 ~ 12 5 ~ 10 25 ~ 50
    • 製造工程
      製造工程 バグ摘出密度(件/ks) 試験密度(件/ks)
      M2 (コードレビュー) 12.0 80 ~ 100
      M3 (単体試験) 3.0
      DB1 3.5 20 ~ 30
      DB2 0.2
  2. プログラム難易度
    開発するプログラム内容が難しければ,目標値は高くなる.すなわち,エラーは多くなり,バグも多くなる.そのため,品質評価指標 (レビュー密度,コメント密度,試験密度) を上げなければならない.
    プログラム難易度 = 論理の複雑度×製品レベル×移植性×高品質度
    
    • 論理の複雑度
      プログラム論理の複雑さ,機能の豊富さ,対象データの複雑さを評価し,0.7(単純) ~ 1.5(複雑) 程度の値を設定する.
    • 製品レベル
      製品の実用化レベルに応じて,0.7 ~ 1.5 程度の値を設定する.
      一般ユーザが使う実用レベルの利用である程,高い値を設定する.試作や評価など厳密な機能確認を必要としない程,低い値を設定する.
    • 移植性
      プログラムの動作環境の種類に応じて,1.0 ~ 2.0 程度の値を設定する.
      プログラムを複数の異なる環境で動作させる場合(移植性を考慮),移植対象環境が多い程,高い値を設定する.対象環境が 1 種類の場合を平均 1.0 とする.
    • 高品質度
      高品質度 =  ユーザの範囲 × ユーザの熟練度 × システム寿命
                  × 実時間性
      
      • ユーザの範囲
        対象とするユーザの範囲に応じて,0.7 ~ 1.5 程度の値を設定する.
        対象ユーザがある範囲に限られる場合を平均 1.0 とし,ユーザが不特定多数になるほど高い値を設定する.
      • ユーザの熟練度
        対象とするユーザの熟練度に応じて,1.0 ~ 1.5 程度の値を設定する.
        対象ユーザが業務にも操作にも不慣れである程,高い値を設定する.
      • システム寿命
        プログラムが使われる年数を評価し,0.7 ~ 1.5 程度の値を設定する.
        数年の寿命を平均 1.0 とし,長く使われる程,大きな値を設定する.
      • 実時間性
        実時間性が高い程,高品質が要求されるため,次のような値を設定する.
        • オンラインリアルタイム処理:1.5
        • 対話型処理        :1.0
        • バッチ処理        :0.7
  3. 開発技術難易度
    開発技術が難しければ,エラーは多くなり,バグも多くなると想定される.そのため,レビュー密度,コメント密度,および試験密度を上げなければならない.
    開発技術難易度 = 開発技術の複雑度 × 基盤技術レベル × 経験レベル
             × 仕様確定レベル
    
    • 開発技術の複雑度
      複雑度 = 使用言語 × 開発規模レベル × 改造レベル
      
      • 使用言語
        使用言語の使用難易度により 0.5 ~ 1.2 程度の値を設定する.平均を 1.0 として,低級言語(アセンブラ,C など)程,高めに設定する.
      • 開発規模レベル
        開発規模に応じて,0.7 ~ 1.5 程度の値を設定する.過去の開発実績で最も多い規模を平均 1.0 とする.
        開発規模が大きくなる程,インタフェースなどが増え複雑性は増すため,目標値を高く設定する.
      • 改造レベル
        改造率を評価し,1.0 ~ 1.5 程度の値を設定する.

        改造率=改造分/開発規模×100(%)

        新規(改造率が10%未満)を平均 1.0 とし,改造率が大きい程,設定値を高くする.
    • 基盤技術レベル
      開発に利用する基盤技術(ターゲット環境,開発環境)の成熟レベルを評価し,0.7 ~ 1.5 程度の値を設定する.
      基盤技術は安定しているが,応用ノウハウが不足している状態を平均 1.0 とする.
    • 経験レベル
      過去の開発経験を評価し,0.5(継続開発の場合) ~ 2.0(経験が全くなく参考情報も無い場合) 程度の値を設定する.
    • 仕様確定レベル
      仕様変更の可能性の程度により 0.7(仕様は確定) ~ 1.5 程度の値を設定する.平均(仕様変更は少ない)を 1.0 として,仕様変更の可能性が大きい程,高めに設定する.
  4. 要員スキルレベル
    開発担当要員のスキルレベルを評価し,0.7 ~ 1.5 程度の値を設定する.
    スキルが低ければ,設定値を高くする.スキルレベルの評価方法は,特別な評価基準が無い場合経験年数とすることが多い.例えば,平均(経験 3年以上 7年未満)を 1.0 とする.
inserted by FC2 system