解説

1. コード作成
2. チェックリストに基づくコードの自己チェック
3. ピアコードレビュー
4. コードインスペクション

• 問題文には「プログラムのコード作成では，詳細設計書に基づいて，Java言語コーディング規約に準拠したコードを作成する」と記述されています。コーディング規約に準拠しているかの確認は、主に②のチェックリストを用いたレビューで確認することになるので誤りです。
• 正しい。〔コード作成における品質管理〕には以下の記載があります。
  • コードインスペクションでは，技術支援チームが①特定の視点に絞ってプログラムのコードを検査する。
  • データベース処理を含むコードをすべてコードインスペクションの対象とする。
  問題文から技術支援チームの役割に関する記述を探すと「技術支援チームはデータベース設計の検証とプログラムのデータベース処理性能面に関する技術支援を担当する」と記載されています。データベース設計の検証については、設計段階において実施するデザインレビューで検証済あると考えられるので、本プロジェクトのコードインスペクションでは、主にデータベース処理を含むコード、すなわちSQL文の記述を処理性能面からチェックすることになります。
• プログラムにおけるコメントは、そのプログラムの挙動などが記述され、ソースコードの共有やソフトウェア保守で他の人がソースコードを読むときに大変有用です。コメントの付け方は一般的にコーディング規約で定義される内容であり、②自己チェックリストまたは③チーム内のメンバーによるピアレビューで確認することになるので誤りです。
• 問題文より「プログラムのコード作成では、詳細設計書に基づいて、…」と記述されています。
  詳細設計書は内部設計書とも言われ、システム内部の設計をコーディングできるレベルまで詳細に記述したドキュメントのことです。状況ごとのメッセージの文言もこの設計書に記述されており、開発担当者は詳細設計書通りにソースコードを作成していきます。つまり、メッセージの文言の適切性はコード作成後ではなく、設計時のデザインレビューにおいて確認すべき事項であると考えられます。

解説

• 【プログラム名について】
  〔コード作成における品質管理〕(1)に記載されている、ピアコードレビューの品質基準に基づいて各プログラムの指摘密度を計算すると、以下のようになります。
  
  • プログラム1 … 14件÷1.0千行＝14件／千行
  • プログラム2 … 24件÷2.0千行＝12件／千行
  • プログラム3 … 12件÷1.5千行＝8件／千行
  • プログラム4 … 18件÷1.0千行＝18件／千行
  適正範囲は10件／千行の＋50％以下なので、上限は15件／千行となります。よって、適正範囲の上限を超えているプログラム4には品質管理上の対策が必要です。
  
  ∴プログラム4
  
  【実施すべき対策について】
  上記のピアコードレビューの品質基準には以下の記述があります。
  
  「指摘密度が適正範囲の上限を上回ったプログラムについては，品質管理上の対策として，指摘への対処完了後，再度ピアコードレビューを実施する」
  
  また〔初期点検〕には、「ピアコードレビューでは，Java言語コーディング規約に規定されたコメントが，プログラムのコードに記載されていないという指摘が多かった」と記述されていますが、プログラム4の指摘内容が上記のものに当てはまるのかは、問題文だけでは判断できません。
  
  本設問は品質基準に従って実施すべき対策が問われているので、個別具体的ではありませんが問題文の記述をそのまま抜き出し「指摘への対処完了後、再度ピアコードレビューを実施する」が適切となります。
  
  ∴指摘への対処完了後、再度ピアコードレビューを実施する
  
  
• 下線②の改善策は「コメントが、プログラムのコードに記載されていないという指摘が多かった」という問題に対処するためのものです。
  
  問題文には以下の記述があります。
  • A～Cの各チームとも、チェックリストに記載されている項目の確認は適切に実施されていた。
  • 開発管理チームは、本人の簡単な確認で解消させるような改善策を講じることにした。
  • 開発管理チームはチェックリストを提供し，必要に応じて，工程途中でもチェック項目の追加・改定をする。
  開発管理チームが実施する改善策であること、チェックリストによる自己チェックが確実に行われている状況を踏まえれば、開発管理チームが提供するチェックリストに「コメントの記載が漏れなく行われているか」の項目を加えることで、コーディング規約違反に開発担当者自身が気付き、ピアレビュー前に改善できるようになると考えられます。
  
  ∴チェックリストに，コメントの記載漏れがないかのチェック項目を追加する

解説

• 〔aについて〕
  表2の評価欄にあるように、プログラム1の不良密度は適正範囲の上限を上回っています。
  
  コードレビューではソースコードを人間の目で確認して不具合を除去するのに対し、単体テストでは実際にプログラムを動かし、その動作が詳細設計書通りになっているかを確認します。単体テストもソースコードに基づいて行うテストですが、コードの品質面ではなく、入力に対する出力の正しさ、分岐条件の適切性、エラー処理などが主な確認項目となります。
  
  〔単体テストにおける品質管理〕には「単体テストケースは…詳細設計書の要求事項を網羅するように作成する」と記載されているので、単体テストで不良が多発しているということは、詳細設計書の要求事項を満たさないソースコードが多いということです。よって、再実施するピアレビューでは詳細設計書の内容を正確に反映しているかどうかという視点でソースコードをチェックするのが適切です。
  
  なお、ピアレビューの結果を見るとプログラム1の指摘密度は適正範囲に収まっているので、ソースコードに関する「ア」「イ」については特段の問題はないと判断できます。また、もし「ア」「イ」の問題があったとしても単体テストでの不良原因にはなり得ません。「エ」の「テストデータの項目の不正な値」が入力値として不正な値ということであれば、単体テストでエラー処理をチェックする対象に含まれるので不良の原因とはなりません。
  
  ∴ウ：コードは詳細設計書の内容を正確に反映しているか
  
  
• 〔c，dについて〕
  単体テストでは10件／千行の±50％を適正範囲としています。プログラム3の不良密度は2件／千行ですので、不良密度の適正範囲の下限を下回っています。
  
  設問には空欄に入る字句を「本文中から選んで」という条件がありますが、上限を上回っているプログラム1の評価欄が「不良密度が適正範囲の上限を上回った」となっていること、問題文には「不良密度が適正範囲の上限を上回った，又は下限を下回ったプログラムについては，…対策を指示する」と記述されていることから、[c]には「不良密度」、[d]には「下限を下回った」が入ると判断できます。
  
  ∴c＝不良密度
  　d＝下限を下回った
  
  
• 今回の単体テストでは、適正範囲の設定はないもののテストケース密度の標準値を100ケース／千行と設定しています。プログラム3はコード行数1.5千行に対してテストケース数が90件ですので、テストケース密度は「90件÷1.5千行＝60ケース／千行」と標準値を大きく下回っています。
  
  不良検出数が少ない場合は本当に品質が高いこともありますが、テストケースの品質が悪かったり、テストが不足していたりして効果的に不良を検出できていないケースもあります。プログラム3ではソースコード行数に対するテストケース数が少ないので、テスト不足により不良数が少なくなっている可能性が高いと言えます。
  
  〔単体テストにおける品質基準〕では「単体テストケースは，…詳細設計書の要求事項を網羅するように作成する」とあるので、開発管理チームは品質基準に基づき、プログラム3の単体テストケースが詳細設計書の要求事項を網羅しているかどうかを確認すべきです。テストケースが十分かどうかは、数だけではなく、テストケースが仕様に基づいて作成されているなどによっても判断する必要があります。
  
  ∴単体テストケースが詳細設計書の要求事項を網羅しているか