平成22年秋期試験午後問題 問10

問10 プロジェクトマネジメント

⇱問題PDF
ソフトウェアパッケージ開発プロジェクトでの品質管理に関する次の記述を読んで,設問1~3に答えよ。
 Y社は,企業向けのソフトウェアパッケージを開発し,販売している。Y社では,現在,販売管理パッケージの全面改訂プロジェクト(以下,改訂プロジェクトという)を進めている。現行の販売管理パッケージは,度重なる仕様の追加・変更によってデータベースへのアクセスが複雑になり,レスポンスに悪影響を及ぼす状況が発生している。今回の改訂は,顧客から寄せられた要望への対応と,レスポンスの向上を目標としている。
 販売管理パッケージの開発言語はJavaで,データベースには関係データベースを使用している。改訂プロジェクトの体制は図のとおりである。
pm10_1.png
 A~Cチームは,それぞれ異なるサブシステムの開発を担当する。技術支援チームはデータベース設計の検証とプログラムのデータベース処理性能面に関する技術支援を担当する。開発管理チームは品質管理を担当する。
 改訂プロジェクトは現在,プログラムの詳細設計工程を完了し,コード作成・単体テスト工程を開始したところである。

〔コード作成における品質管理〕
 コード作成は,プログラムのコード作成,チェックリストに基づくコードの自己チェック,ピアコードレビュー,及びコードインスペクションの手順で実施する。
 プログラムのコード作成では,詳細設計書に基づいて,Java言語コーディング規約に準拠したコードを作成する。自己チェックでは,コード作成の担当者自身が,チェックリストの項目に沿ってプログラムのコードを確認する。チェックリストは,本人の簡単な確認で是正できるチェック項目を列挙したものである。開発管理チームはチェックリストを提供し,必要に応じて,工程途中でもチェック項目の追加・改定をする。ピアコードレビューでは,チームリーダーが進行役となり,チーム内のメンバー同士でプログラムのコードを相互に確認する。コードインスペクションでは,技術支援チームが①特定の視点に絞ってプログラムのコードを検査する。
 ピアコードレビューとコードインスペクションの品質基準は,次のとおりである。
  • ピアコードレビュー
    • 作成されたプログラムのコードすべてをピアコードレビューの対象とする。
    • レビューを実施した結果の指摘数と,レビュー対象コードの行数からプログラム単位の指摘密度を算出する。
    • 指摘密度は,過去の類似プロジェクトにおける指摘密度の平均値である10件/千行に対し,+50%以下を適正範囲の目安とする。
    • 指摘密度が適正範囲の上限を上回ったプログラムについては,品質管理上の対策として,指摘への対処完了後,再度ピアコードレビューを実施する。
  • 技術支援チームによるコードインスペクション
    • データベース処理を含むコードをすべてコードインスペクションの対象とする。
    • コードインスペクションによる指摘数は,指摘密度による管理対象としない。
〔単体テストにおける品質管理〕
 単体テストは,プログラム単位に,コード作成担当者以外のメンバーが,単体テストケースに基づいて実施する。単体テストケースは,単体テストを実施するメンバーが,詳細設計書の要求事項を網羅するように作成する。単体テストで発見した不良については,一覧形式の管理表に記録し,プログラム単位の不良密度を算出する。
 単体テストの品質基準は,次のとおりである。
  • 不良密度は,過去の類似プロジェクトの平均値を参考に設定した標準値である10件/千行に対し,±50%を適正範囲の目安とする。
  • 不良密度が適正範囲の上限を上回った,又は下限を下回ったプログラムについては,開発管理チームが問題点の有無を確認し,必要な場合には,品質管理上の対策を指示する。
  • 単体テストケースの妥当性を確認する一つの目安であるケース密度を算出するために,プログラムごとの単体テストケース数も測定する。過去の類似プロジェクトのケース密度の平均値を参考に,標準値を100ケース/千行に設定するが,適正範囲の設定は特に行わないものとする。
〔初期点検〕
 コード作成・単体テスト工程全体の約2割まで進んだ時点で,開発管理チームは,工程の初期段階の問題から品質管理面の改善策を導き出す目的で初期点検を開始した。
 初期点検では,チーム単位に,ピアコードレビューと単体テストを現時点までに終えているプログラムに対し,評価を実施することにした。開発管理チームは,最初にAチームのピアコードレビューの状況を表1にまとめた。
pm10_2.png
 A~Cの各チームとも,チェックリストに記載されている項目の確認は適切に実施されていた。しかし,ピアコードレビューでは,Java言語コーディング規約に規定されたコメントが,プログラムのコードに記載されていないという指摘が多かった。開発管理チームは,本人の簡単な確認で解消させるような②改善策を講じることにした。
 開発管理チームは続けて,Aチームの単体テストの状況を表2にまとめた。品質管理上の対策として,プログラム1については,ピアコードレビューを再度実施してaを確認し,プログラム3については,bを確認するようAチームに指示した。
pm10_3.png

設問1

本文中の下線①について,技術支援チームの役割上,コードインスペクションに最も重要となる視点を解答群の中から選び,記号で答えよ。
解答群
  • Java言語コーディング規約に準拠しているか
  • SQL文の記述に処理性能面の問題がないか
  • コメントの記述に過不足がないか
  • メッセージの文言は状況を適切に表現しているか

解答例・解答の要点


解説

まず、〔コード作成における品質管理〕に基づいてコード作成の手順を整理しておきます。
  1. コード作成
  2. チェックリストに基づくコードの自己チェック
  3. ピアコードレビュー
  4. コードインスペクション
上記の②から④の作業をまとめてコードレビューと言います。コードレビューとは、開発者担当者が書いたソースコードを人間の目で確認し、不具合を発生させるコードや、著しくパフォーマンスを劣化させるコード、セキュリティ上問題となるコードなどを除去する活動のことです。ソースコードの正しさを検証するための単体テストは必ず行いますが、その前にコードレビューでソースコードをブラッシュアップ(以前より良く)することにより、事前に不具合の何割かを除去しておくことができます。

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

設問2

初期点検におけるピアコードレビューの状況について,(1),(2)に答えよ。
  • 表1に示したプログラム1~4のうち,品質管理上の対策が必要なプログラム名を一つ挙げよ。また,品質基準に従って実施すべき対策の内容を35字以内で述べよ。
  • 本文中の下線②の改善策について,本文中のコード作成の手順に含まれる活動にかかわる対策として適切と考えられる手段を40字以内で述べよ。

解答例・解答の要点

  • プログラム名:プログラム4
    実施すべき対策:指摘への対処完了後,再度ピアコードレビューを実施する (26文字)
  • チェックリストに,コメントの記載漏れがないかのチェック項目を追加する (34文字)

解説

  • 【プログラム名について】
    〔コード作成における品質管理〕(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の各チームとも、チェックリストに記載されている項目の確認は適切に実施されていた。
    • 開発管理チームは、本人の簡単な確認で解消させるような改善策を講じることにした。
    • 開発管理チームはチェックリストを提供し,必要に応じて,工程途中でもチェック項目の追加・改定をする。
    開発管理チームが実施する改善策であること、チェックリストによる自己チェックが確実に行われている状況を踏まえれば、開発管理チームが提供するチェックリストに「コメントの記載が漏れなく行われているか」の項目を加えることで、コーディング規約違反に開発担当者自身が気付き、ピアレビュー前に改善できるようになると考えられます。

    ∴チェックリストに,コメントの記載漏れがないかのチェック項目を追加する

設問3

初期点検における単体テストの状況について,(1)~(3)に答えよ。
  • 本文中のaに入れる適切な字句を解答群の中から選び,記号で答えよ。
  • 表2中のcdに入れる適切な字句を本文中から選んで答えよ。
  • 本文中のbに入れる適切な字句を35字以内で述べよ。
a に関する解答群
  • 共通化がされていない冗長なコードがないか
  • コードが読みやすいよう字下げが適切にされているか
  • コードは詳細設計書の内容を正確に反映しているか
  • テストデータの項目に不正な値がないか

解答例・解答の要点

  • a:
  • c:不良密度
    d:下限を下回った
  • b:単体テストケースが詳細設計書の要求事項を網羅しているか (27文字)

解説

  • aについて〕
    表2の評価欄にあるように、プログラム1の不良密度は適正範囲の上限を上回っています。

    コードレビューではソースコードを人間の目で確認して不具合を除去するのに対し、単体テストでは実際にプログラムを動かし、その動作が詳細設計書通りになっているかを確認します。単体テストもソースコードに基づいて行うテストですが、コードの品質面ではなく、入力に対する出力の正しさ、分岐条件の適切性、エラー処理などが主な確認項目となります。

    〔単体テストにおける品質管理〕には「単体テストケースは…詳細設計書の要求事項を網羅するように作成する」と記載されているので、単体テストで不良が多発しているということは、詳細設計書の要求事項を満たさないソースコードが多いということです。よって、再実施するピアレビューでは詳細設計書の内容を正確に反映しているかどうかという視点でソースコードをチェックするのが適切です。

    なお、ピアレビューの結果を見るとプログラム1の指摘密度は適正範囲に収まっているので、ソースコードに関する「ア」「イ」については特段の問題はないと判断できます。また、もし「ア」「イ」の問題があったとしても単体テストでの不良原因にはなり得ません。「エ」の「テストデータの項目の不正な値」が入力値として不正な値ということであれば、単体テストでエラー処理をチェックする対象に含まれるので不良の原因とはなりません。

    ∴ウ:コードは詳細設計書の内容を正確に反映しているか

  • cdについて〕
    単体テストでは10件/千行の±50%を適正範囲としています。プログラム3の不良密度は2件/千行ですので、不良密度の適正範囲の下限を下回っています。

    設問には空欄に入る字句を「本文中から選んで」という条件がありますが、上限を上回っているプログラム1の評価欄が「不良密度が適正範囲の上限を上回った」となっていること、問題文には「不良密度が適正範囲の上限を上回った,又は下限を下回ったプログラムについては,…対策を指示する」と記述されていることから、[c]には「不良密度」、[d]には「下限を下回った」が入ると判断できます。

    c=不良密度
     d=下限を下回った

  • 今回の単体テストでは、適正範囲の設定はないもののテストケース密度の標準値を100ケース/千行と設定しています。プログラム3はコード行数1.5千行に対してテストケース数が90件ですので、テストケース密度は「90件÷1.5千行=60ケース/千行」と標準値を大きく下回っています。

    不良検出数が少ない場合は本当に品質が高いこともありますが、テストケースの品質が悪かったり、テストが不足していたりして効果的に不良を検出できていないケースもあります。プログラム3ではソースコード行数に対するテストケース数が少ないので、テスト不足により不良数が少なくなっている可能性が高いと言えます。

    〔単体テストにおける品質基準〕では「単体テストケースは,…詳細設計書の要求事項を網羅するように作成する」とあるので、開発管理チームは品質基準に基づき、プログラム3の単体テストケースが詳細設計書の要求事項を網羅しているかどうかを確認すべきです。テストケースが十分かどうかは、数だけではなく、テストケースが仕様に基づいて作成されているなどによっても判断する必要があります。

    ∴単体テストケースが詳細設計書の要求事項を網羅しているか
模範解答

Pagetop