戦国IT - 情報処理技術者試験の過去問対策サイト
ブログお知らせお問い合わせ料金プラン

基本情報技術者 2010年 春期 午後 問06


プロジェクトにおける品質管理に関する次の記述を読んで、設問1,2に答えよ。

 システムインテグレータX社は、Y社のシステム開発を3年前から担当している。初年度の新規開発が終了後、半年ごとにシステムの機能拡張を継続的に行っている。今年度は比較的大規模なシステム開発(以下、プロジェクトPという)をすることになり、表1のとおりに開発体制を変更(新規メンバを、グループG1に1名、G2に2名追加)した。プロジェクトPでは、開発体制の変更に伴うシステムの品質低下を防止するために、従来以上にプロジェクトにおける品質管理を徹底することにした。
基本情報技術者試験(平成22年 午後 問6 表1)
 過去のプロジェクトで蓄積された品質データ(バグ件数、バグ摘出率など)は、次のプロジェクトの品質管理に役立てることができる。蓄積された品質データを基に、新規プロジェクトの目標値を設定し、各開発工程での実績値との差異を分析する。差異が生じた場合には、その原因を見いだして、品質向上のための施策の実行、目標値の見直しなど、適切に対処することを繰り返す。これによって、開発工程が進むにつれて品質管理の精度が向上し、システムの品質が確保される。 (1) プロジェクトPの開発工程は、設計工程、製造工程、単体テスト工程及び結合テスト工程の四つの工程から成る。 (2) 設計工程の開始時点では、Y社のシステム開発における過去のプロジェクトでの品質データの実績値を基に、バグ総件数を予測し、工程ごとのバグ摘出率の目標値を設定する。設計工程の終了時には、バグ摘出件数の予測値と実績値の比較・分析を行い、バグ総件数の予測値を見直して、以降の工程での残存バグ件数を予測する。製造工程、単体テスト工程及び結合テスト工程の終了時に、この予測を繰り返す。 (3) 設計工程又は製造工程で生じた誤り(バグ)をテスト工程で発見して修正する場合には多くの工数を要するので、開発の生産性及びシステムの品質向上には、バグの早期発見が重要である。  X社では、設計工程及び製造工程でのバグ摘出率の向上を目指し、品質管理の全社目標を、“設計工程及び製造工程でのバグ摘出率65%以上”に設定している。各グループのこれまでの品質データに今回の開発体制の変更の影響を加味した結果と全社目標を基に、プロジェクトPの設計工程開始時点での工程ごとの目標バグ摘出率を表2のように設定した。
基本情報技術者試験(平成22年 午後 問6 表2)
(4) 各サブシステムとも、設計工程は計画どおりの期間で終了した。設計工程でのバグ摘出件数の実績値及び算出したバグ摘出率は、表3のとおりであった。
 設計工程でのバグ摘出率(%)は、次の式で算出する。    設計工程でのバグ摘出率 = 設計工程でのバグ摘出件数(実績値) ÷ 全工程でのバグ総件数(予測値) × 100   (5) 製造工程でのバグ摘出件数の実績値は、表4のとおりであった。バグ摘出件数の予測値と実績値を比較・分析した結果、製造工程の終了時に各サブシステムでの残存バグ件数を表4のとおりに予測した。
(6) テスト工程(単体テスト工程及び結合テスト工程)でのバグ摘出件数の実績値は、表5のとおりであった。

設問1:

問題文を見る
 次の記述中のに入れる適切な答えを、解答群の中から選べ。    プロジェクトマネージャのM課長は、表3の結果を見て、グループG1とG2の設計品質に対して表6に示す疑問をもち、グループリーダに各サブシステムの設計品質についての見解を説明させた。グループリーダからの回答内容は、表7のとおりであった。M課長は、この説明に納得して、各グループに製造工程への着手を指示した。
基本情報技術者試験(平成22年 午後 問6 表6)
基本情報技術者試験(平成22年 午後 問6 表7)
解答群  ア:過去のシステムの機能拡張で改造した機能と類似しているモジュールが予想以上に多かったこと  イ:新規メンバが要求仕様を完全に理解していなかったためにバグが発生したこと  ウ:新規メンバの1人が、類似システムの開発に関して、既存メンバを上回る経験を有していたこと  エ:設計の難度が高いモジュールが予測以上に多かったこと  オ:他システムの保守対応など緊急の割込み業務が多発して工数不足だったこと

模範解答

a:イ、b:エ、c:ア、d:ウ(a,bは順不同)

解説

解答の導き方

まず、表1から担当関係を確認します。G1はS1、G2はS2を担当しています。表2では、設計工程の目標バグ摘出率は30%です。一方、表3の実績は、S1が35%、S2が25%です。
バグ摘出率は、設計工程で見つけたバグの件数を、全工程で発生すると予測したバグ総件数で割った割合です。したがって、率が目標より高いからといって、必ず設計品質が悪いとは限りません。設計で発生したバグが多かった場合も、設計レビューで多くのバグを見つけた場合も、バグ摘出率は高くなります。
表3の数値から、全工程でのバグ総件数の予測値も確認できます。
  • S1は、280件を35%で割ると、予測値は800件です。
  • S2は、175件を25%で割ると、予測値は700件です。
このため、G1とG2では、目標との差が生じた理由を分けて考える必要があります。
G1について
表7では、設計レビューをこれまでより強化したと説明されています。設計レビューとは、設計内容を複数人で確認し、誤りを早い段階で見つける作業です。
G1では、新規メンバが要求仕様を十分に理解できずに設計すると、設計上の誤りが増える可能性があります。また、設計の難度が予測より高いモジュール(ソフトウェアを構成する機能単位)が多かった場合も、誤りが増える可能性があります。この2つが、G1のバグ摘出件数を増やす要因として考えられます。
さらに、設計レビューを強化したことで、発生していたバグを見つけやすくなっています。表7には、バグの改修が終了し、品質を十分に確保したとあります。したがって、目標の30%を上回った理由としては、要求仕様の理解不足によるバグと、予測より難度の高いモジュールの両方が考えられます。
そのため、aには「新規メンバが要求仕様を完全に理解していなかったためにバグが発生したこと」、bには「設計の難度が高いモジュールが予測以上に多かったこと」が入ります。解答群では、それぞれイ、エです。
G2について
G2は、目標の30%に対して実績が25%です。ただし、バグ摘出件数が少なかったからといって、すぐに設計レビューの不備とは判断できません。設計そのものに誤りが少なければ、レビューで見つかるバグも少なくなるからです。
表7では、過去の機能拡張で改造した機能と似たモジュールが予想以上に多く、設計の再利用率が計画値より高まったと説明されています。過去の設計を再利用できれば、新たに設計する部分が減り、設計上の誤りも減ると考えられます。これは解答群のアです。
また、G2に加わった新規メンバの1人は、類似システムの開発経験が既存メンバを上回っていました。その経験によってメンバの生産性が計画値より高まり、設計を効率よく進められたと考えられます。これが解答群のウです。
この2つの理由で、設計工程で発生するバグが少なくなれば、設計レビューが適切でも、バグ摘出件数とバグ摘出率は目標を下回ることがあります。そのため、cにはア、dにはウが入ります。
なお、解答群の「他システムの保守対応など緊急の割込み業務が多発して工数不足だったこと」は、作業時間が不足したという説明です。G1のようにレビューを強化してバグを多く見つけた理由にも、G2のように再利用や経験によってバグが減った理由にも当てはまりません。

誤りやすいポイント

  • バグ摘出率が目標を上回ったら品質が悪い、下回ったら品質がよい、と単純に判断しないようにします。バグ摘出率は、発生したバグの多さだけでなく、レビューで発見できた件数にも左右されます。
  • G1の35%を見て、新規メンバの能力だけを原因にしないことが大切です。表7では、要求仕様の理解不足だけでなく、設計の難度が予測より高かったことも要因として説明できます。
  • G2の25%を見て、設計レビューが不十分だったと決めつけないようにします。設計の再利用や経験のあるメンバによって、そもそも設計上のバグが少なかった可能性があります。
  • 「生産性が高い」だけを理由に、必ず品質が高いと判断するのは避けます。この問題では、設計の再利用と類似システムの経験が、バグ摘出件数の減少につながる説明になっています。

FAQ

Q: バグ摘出率が高いことは、いつも悪い結果ですか?
A: いいえ。発生したバグが多かった可能性もありますが、レビューを強化したことで多くのバグを発見できた可能性もあります。見つけたバグを修正できているかなども合わせて考えます。
Q: バグ摘出件数が少ないと、レビュー不足を疑うべきですか?
A: 件数だけでは判断できません。設計の再利用などによって、設計時点で発生するバグ自体が少なかった場合もあります。この問題では、G2の再利用率とメンバの経験が理由として示されています。
Q: 目標値と実績値に差があった場合、何を確認しますか?
A: 差が生じた理由を確認します。予測したバグ総件数、実際に見つかった件数、レビューの実施状況、設計の再利用などを見て、品質に問題があるのか、予測と実績の前提が異なったのかを考えます。

関連キーワード: 品質管理、バグ摘出率、設計レビュー、ソフトウェア再利用、品質データ

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

 テスト工程での品質に関する次の記述中のに入れる適切な答えを、解答群の中から選べ。  なお、解答群の数値は小数点以下を四捨五入した値である。    表4及び表5の結果を見たM課長は、S2に関して、製造工程終了時の残存バグ件数の予測値が170件であるのに対し、テスト工程でのバグ摘出件数は160件であり、10件の摘出不足があることから、まだバグが残っており、テスト不足ではないのかとの疑問をもった。  そこで、S2に対して追加テストが必要かどうかを見極めるために、テスト工程でのバグ成長曲線を確認することにした。テスト工程における検査項目の完了数とバグ摘出件数との関係を表すグラフがeであることから、S2のテスト工程での品質は十分に安定していると評価した。また、S2の設計工程においても、表7の回答内容から品質の良さが想定される。さらに、最終的な製造工程のバグ摘出率はf%であり、製造工程での品質確保も十分であると考えられる。最終的な製造工程のバグ摘出率(%)は、次の式で算出する。    製造工程でのバグ摘出率 = 製造工程でのバグ摘出件数(実績値) ÷ 全工程でのバグ総件数(実績値) × 100    これらのことから、S2のバグ総件数の実績値は当初の予測値よりも少ない値であるが、バグは残っていないと判断してテストを完了した。  その後、Y社へシステムをリリースして3か月が経過したが、Y社からの不具合の報告はなかった。この結果から、最終的に設計工程及び製造工程でのバグ摘出率の合算値が最も高かったのは、グループgであり、バグ摘出率の合算値はh%である。   eに関する解答群 基本情報技術者試験(平成22年 午後 問6 設問2 eに関する解答群)   fに関する解答群  ア:30  イ:32  ウ:34  エ:36  オ:38   gに関する解答群  ア:G1  イ:G2  ウ:G3   hに関する解答群  ア:66  イ:68  ウ:70  エ:72  オ:74

模範解答

e:イ、f:ウ、g:イ、h:イ

解説

解答の導き方

1. e:テスト工程で品質が安定しているグラフを選びます
バグ(プログラムや設計に含まれる誤り)の累積摘出件数は、テストを進めるにつれて増えていきます。テストの終盤で曲線がほぼ横ばいになれば、検査項目をさらに進めても、新たに見つかるバグが少なくなっていると考えられます。
解答群のイは、曲線が途中で上昇した後、終盤にほぼ横ばいになります。また、最後の摘出件数は、残存バグ件数の予測値を示す線よりも少ない位置にあります。予測した件数まで見つからなくても、曲線が横ばいになっていれば、当初の予測より実際のバグ総数が少なかった可能性があります。
一方、アは終盤に曲線が急上昇しており、最後までバグが多く見つかっている状態です。イのように終盤で横ばいになっているとはいえません。したがって、S2のテスト工程で品質が安定していることを示すのはイです。
2. f:製造工程でのバグ摘出率を計算します
バグ摘出率(全バグのうち、その工程で見つかった割合)は、設問に示されたとおり、製造工程で見つかった件数を、全工程で見つかったバグの総数で割って求めます。
S2では、設計工程で175件、製造工程で170件、単体テスト工程で100件、結合テスト工程で60件が見つかっています。テスト工程で見つかった件数は、表5の100件と60件を合わせた160件です。したがって、全工程で見つかったバグの総数は次のとおりです。
この505件を使って製造工程の摘出率を計算します。
解答群の数値は小数点以下を四捨五入するため、fは34%です。製造工程終了時に予測した残存バグ件数170件や、設計工程の開始時点での予測値ではなく、全工程で見つかった実績件数505件が分母になる点に注意してください。
表2の製造工程の目標値は35%なので、34%は単独では目標をわずかに下回ります。ただし、全社目標は「設計工程及び製造工程でのバグ摘出率65%以上」です。設計工程と製造工程を合わせると、次のようになります。
四捨五入すると68%で、全社目標の65%以上を満たしています。したがって、製造工程単独の目標35%を達成したということではなく、設計工程と製造工程を合わせた目標を達成していることが、品質確保の判断につながります。
3. g・h:各グループの設計工程と製造工程の摘出率を合わせます
表1では、G1がS1、G2がS2、G3がS3を担当しています。各サブシステムについて、設計工程と製造工程で見つかった件数を合計し、それを全工程で見つかった件数の合計で割ります。
  • G1(S1)
    全工程の件数は、件です。
    設計工程と製造工程の合計は、件です。
    なので、四捨五入して65%です。
  • G2(S2)
    全工程の件数は505件です。設計工程と製造工程の合計は、件です。
    なので、四捨五入して68%です。
  • G3(S3)
    全工程の件数は、件です。
    設計工程と製造工程の合計は、件です。
    なので、四捨五入して65%です。
最も高い値はG2の68%です。よって、gはG2、hは68%です。なお、各工程の率を四捨五入してから足すのではなく、件数を先に合計して率を計算します。

誤りやすいポイント

  • 製造工程終了時の残存バグ件数の予測値は、確定した件数ではありません。S2では予測値170件に対してテスト工程で160件が見つかっていますが、その差の10件が必ず残っているとは限りません。
  • fの計算で、設計工程開始時点の予測値を分母に使わないようにします。設問の式では、全工程でのバグ総件数の実績値を使います。
  • 製造工程の摘出率34%は、表2の目標値35%を単独では満たしていません。品質確保の根拠は、設計工程と製造工程を合わせた率68%が全社目標65%以上であることなどです。
  • hを求めるとき、設計工程と製造工程の率をそれぞれ四捨五入してから足すと、正しい値にならないことがあります。件数を合計してから計算します。

FAQ

Q: S2では予測した170件より10件少ない160件しか見つかっていません。それでも、バグが残っていないと判断できるのですか?
A: 170件は製造工程の終了時点での予測値であり、実際に残っている件数を確定したものではありません。テスト工程の曲線が終盤でほぼ横ばいになっていることや、設計・製造工程の品質状況も合わせて判断しています。
Q: 製造工程の摘出率が目標の35%に届かないのに、なぜ品質確保が十分と考えられるのですか?
A: 製造工程単独では目標をわずかに下回ります。一方、設計工程と製造工程を合わせた率は68%で、全社目標の65%以上を満たしています。設問では、この合算値などを踏まえて品質を判断しています。
Q: hは35%と34%を足して69%にするのではないのですか?
A: 35%と34%は、それぞれの率を別々に四捨五入した値です。合算値は、設計工程と製造工程の件数を先に足し、全工程の件数で割ってから四捨五入します。そのため、hは68%になります。

関連キーワード: 品質管理、バグ摘出率、バグ成長曲線、残存バグ件数、品質目標

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

戦国ITクイズ機能

\ せっかくなら /

基本情報技術者を
クイズ形式で学習しませんか?

クイズ画面へ遷移する→

すぐに利用可能!

©︎2026 情報処理技術者試験対策アプリ

このサイトについてブログプライバシーポリシー利用規約特商法表記開発者について