品質管理とは

/マネジメント

品質管理

品質管理とは、提供する製品やシステムに対し、不具合を防ぎ、定められた品質を提供するための活動です。品質は本来、設計・製造工程で作り込むべきで、検査工程で担保するものではないと考えます。

品質特性

品質特性とは、品質の定義の1つで、プロジェクトに合わせて充填管理すべきものが選択されます。

機能性 ソフトウェアが目的を達成するために必要な機能
信頼性 実装している機能が機能要件を満たして正常動作を続ける度合い
使用性 システムの使いやすさ、分かりやすさなどの度合い
効率性 システムの目的達成と、使用する資源量との度合い
保守性 改訂や改修を行うための労力の度合い
移植性 ソフトウェアをある環境から別の環境の移す場合の互換性の度合い

品質目標

品質目標には定性的目標と定量的目標があります。定性的目標は数値で表せない目標で、品質管理の方針に相当します。定量的目標には以下があります。

設計フェーズ ・設計書の枚数
・レビュー時間(レビュー時間 ÷ 設計書の枚数)
・発見エラー数(発見エラー数 ÷ 設計書の枚数)
製造フェーズ ・予定したコメント行数合計
・予定した共通ルーティン÷全ステップ数
テストフェーズ ・プログラムステップ数
・テスト項目数(テスト項目数 ÷ プログラムステップ数)
・発見バグ数(発見バグ数 ÷ プログラムステップ数)

品質計画

レビュー計画

レビュー(デザインレビュー)は、あらゆる成果物の品質状況をチェックする手法で、要件定義・基本設計・詳細設計の終了時には必ず実施する必要があります。レビューの目的は以下の3つがあります。

  • 開発プロジェクトの状況把握と関係者への周知
  • プロジェクトの成果物に対する技術的評価
  • 定められた機関と費用でプロジェクトを完了させるための方策の検討

テスト計画

システム開発プロジェクトにおけるテストは、主に単体テスト・結合テスト・システムテスト・運用テストがあります。

テスト工程 対応する工程 テスト内容
単体テスト プログラム製造 モジュールまたはプログラム単位のテスト。ブラックボックステストとホワイトボックステストが併用される。
結合テスト プログラム設計 プログラム間の連携テスト。プログラムが他のプログラムを呼び出した場合に、全体として正しく機能していることを確認する。
システムテスト
総合テスト
外部設計
内部設計
システムの全体のテストで、システムの最初から最後まで一通り運用を行う。
運用テスト 要件定義 システムの運用部門が行い、開発されたシステムが実運用み耐えうることを確認する。

テスト手法

主なテスト手法は以下があります。

ホワイトボックス
テスト
プログラムのソースコードを見て、それに基づいてテストデータを作成するテスト方法。
ブラックボックス
テスト
プログラムのソースコードを見ずに、仕様書に基づいてテストデータを作成するテスト方法。
同値分割
限界値分析
同値分割とは、条件判定において、入力値の全体を同じ結果になる入力値にグループに分けること。限界値分析とは、グループの境界になる入力値をテストデータに選ぶテスト方法。

品質評価

実績把握

レビューから品質実績データを把握する場合は以下の項目を記録します。

・レビュー対象成果物
・実施日、出席者、実施時間
・エラー発見実績数

発見したエラー(バグ)は、以下の項目について、1件1枚でエラー記録票(バグ記録票)に記録します。

・件名、対象成果物
・エラー(バク)内容
・原因、処置

差異分析

差異分析は、予定と実績を比較し、その差異が大きい場合は原因を分析し、品質の評価を行います。例えば、テスト消化数と不良発見数の関係は以下になります。

状況 原因と対策
消化停滞
不良多発
レビュー(テスト)項目の消化が遅れており、不良が多発している。
原因:仕様変更による不良の混入、前工程のレビュー(テスト)不足。
対策:前工程に戻る。前工程のレビュー(テスト)を再実施する。
消化停滞
不良過少
レビュー(テスト)項目の消化が遅れており、不良の摘出も少ない。
原因:レビュー(テスト)の問題、または工数の不足。
対策:レビュー(テスト)要員の増強。
消化過大
不良過少
レビュー(テスト)項目の消化が進んでいるが、不良の摘出も少ない。
原因:レビュー(テスト)項目が少ない、結果判定が甘い。
対策:レビュー(テスト)項目の見直す。実施状態を見直す。

QC7つ道具

QC7つ道具は以下になります。

  • パレート図
  • ヒストグラム
  • 散布図
  • 特性要因図(フィッシュボーン図)
  • チェックシート
  • グラフ(棒グラフ、レーダチャート)
  • 管理図

品質改善

品質改善は、品質不良の原因除去を行います。

原因 改善策
開発要員のスキル不足 ・開発要員に教育研修させる
・開発要員を交代、チーム編成を変える
開発標準を順守していない ・開発標準の順守を徹底する
・開発標準を追加・変更する
仕様変更が多い ・仕様変更を一時的に凍結または時期をずらす
設計仕様があいまい
前工程のバグが原因
・前工程に戻って再設計・再定義を行う
・前工程のレビューを再実施する

 

IT
マネジメント、セキュリティ、ネットワーク、システム
散策路TOP
数学、応用数学、古典物理、量子力学、物性論、電子工学、IT、力学、電磁気学、熱・統計力学、連続体力学、解析学、代数学、幾何学、統計学、論理・基礎論、プラズマ物理、量子コンピュータ、情報・暗号、機械学習、金融・ゲーム理論

 

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