ITパスポート 2017年 春期 問38

ソフトウェア開発プロジェクトにおけるプログラムの品質の指標【ITパスポート 解説】

正解の理由

解法ステップ

1. 問題のキーワードを確認：今回は「プログラムの品質の指標」。品質＝ソフトウェアそのものの出来を測る指標を求めている。
2. 各選択肢が何を測るかを考える：
   • ア: 計画時の予算 → プロジェクト管理やコストの指標
   • イ: 投資対効果（ROI: Return on Investment）→ 財務／経営の指標
   • ウ: 納期 → スケジュール（進捗）に関する指標
   • エ: バグ摘出数 → 不具合の数。ソフトウェア品質に直接関係
3. 上記を踏まえて、ソフトウェア品質に直結するものを選ぶ → エ。

選択肢別の誤答解説

• ア: 計画時の予算
  予算は「どれだけ費用をかけるか」を示します。プロジェクト全体の管理に関する指標で、プログラムの動作や品質そのものを直接示す指標ではありません。
• イ: 投資対効果（ROI: Return on Investment）
  ROIは投入した資金に対してどれだけ利益が出るかを見る経営指標です。ソフトウェアの品質（バグの少なさや信頼性）を直接表すものではありません。
• ウ: 納期
  納期は「予定どおりに完成したか」を示すスケジュール指標です。品質と関連することはあっても、納期そのものが品質の良し悪しを示す指標ではありません。
• エ: バグ摘出数
  テストで見つかった不具合の数で、プログラムの欠陥を直接示します。したがって品質を評価する指標として最も適切です。ただし「バグ数が多い＝ただちに品質が低い」と単純に判断するのは危険です（後述）。

よくある誤解

1. 「バグ摘出数が多ければ品質が低い」と考える誤解
   • バグ摘出数はテスト量やテストの丁寧さに左右されます。テストをたくさん行えば多くのバグが見つかるため、単純比較は誤りです。
2. 「バグが0なら完璧」と思う誤解
   • テストで見つからなかっただけで、本番で不具合が出ることはあります。バグ0は理想的ですが、保証にはなりません。
3. 「品質は一つの指標だけで判断できる」と考える誤解
   • 品質は信頼性（故障率）、保守性（修正のしやすさ）、性能など複数の観点があります。バグ摘出数は重要ですが、他の指標とも組み合わせて判断します。

補足コラム

• バグ密度（bug density）
  バグ数をソースコードの行数や機能数で割った値。たとえば、KLOC（千行あたり）で計算することが多いです。
  $$\text{バグ密度}=\frac{\text{バグ数}}{\text{ソースコードの行数（KLOC）}}$$
  例：10,000行中50件のバグ → バグ密度 = 5 / KLOC。
• 故障率（failure rate）
  実際に稼働中に発生した不具合の頻度。ユーザーが使っているときにどれくらい壊れるかを示します。
• MTTR（Mean Time To Repair：平均修復時間）
  不具合が発生してから復旧するまでの平均時間。短いほど運用上の品質が高いと評価できます。
• テストカバレッジ（coverage）
  コードの何割がテストされているか。カバレッジが高いほど検出されるバグも増える可能性があります。

FAQ