応用情報技術者 2018年 春期 午後 問08
プログラムの品質評価に関する次の記述を読んで、設問1〜3に答えよ。
Z社では、全国に店舗展開する家電量販店向けに、顧客管理システムを開発している。開発中の顧客管理システムは、運用開始後、家電量販店の業務内容の変化に合わせて、3か月おきを目安に継続的に改修していくことが想定されている。
Z社では、プログラムの品質を定量的に評価するために、メトリクスを計測し、サイクロマティック複雑度をメトリクスとして計測し、評価する。開発プロセスにおいては、プログラムのテストを開始する前にメトリクスを計測し、評価された値が、あらかじめ設定された小さい値を上回らないことを確認することにしている。
開発中の顧客管理システムについても、開発プロセスのルールに従い、この評価方法にそって評価した。
〔サイクロマティック複雑度〕
サイクロマティック複雑度とは、プログラムの複雑度を示す指標である。プログラムの制御構造を有向グラフで表したときの、グラフ中のノードの数 N とリンク(辺)の数 L を用いて次の式で算出する。
サイクロマティック複雑度 C = L - N + 2
プログラムの制御構造を有向グラフで表した例を図1に示す。プログラムの開始位置と終了位置、反復や条件分岐が開始する位置と終了する位置をノードとし、ノード間をつなぐ順次処理の部分をリンクとしてグラフにする。ノード間に含まれる順次処理のプログラムの行数は考慮せず、一つのリンクとして記述する。また、図1のリンク 1 やリンク 4 のように、処理がない場合も一つのリンクとして記述する。

図1の場合、ノードの数Nは4、リンクの数Lは4となり、Cは a と評価される。
ソフトウェアの内部構造及び内部仕様に基づいたテストを b という。Z社では、b を実施するに当たって、全ての条件分岐の箇所で、個々の判定条件の真及び偽の組合せを満たすことを基準としてテストを実施する方針としている。このような方針を c という。一般に、サイクロマティック複雑度は小さいが、実行網羅率 100 % を目指すために必要なテストケース数が多くなり、テスト工程の作業が容易になる。Z社では、サイクロマティック複雑度のしきい値を10に設定している。
〔評価対象のプログラム〕
開発中の顧客管理システムにおいて、顧客から問合せを受け付けた際に記録する情報には、タイトル、概要、発生店舗、詳細情報及び顧客の個人情報が含まれており、これらの情報をまとめたものを案件と呼ぶ。案件には、未完了と完了のステータスがある。画面に案件の情報を表示する際には、案件のステータスとシステムの利用者の立場によって、情報の公開範囲と編集可否の権限を制御する必要がある。
図2は、画面上に案件の一覧を表示する際の権限制御を行うプログラムの一部である。システムの利用者の役職や所属する店舗と、それぞれの案件のステータスから、画面上に表示する情報の公開範囲と編集可否についての権限を判定する。
図2のプログラムについて、メトリクスの計測を行った。計測結果を表1に示す。なお、サイクロマティック複雑度の計測のために作成した有向グラフの記載は省略する。


表1の計測結果から、図2のプログラムはサイクロマティック複雑度が大きい値を上回っており、テスト実施のコストが大きくなることが予想される。そこで、プログラムの外部的振る舞いを保ったままプログラムの理解や修正が簡単になるように内部構造を改善する d を行うことにした。改善する一つの方法として、図2のプログラム中(A)の範囲を“未完了案件権限判定”、(B)の範囲を“管理者権限判定”という名称で関数化することを検討した。改善後のプログラムを図3に、改善後のプログラムの有向グラフを図4に示す。

図3のプログラムのサイクロマティック複雑度は f であった。また、関数“未完了案件権限判定”については 6、“管理者権限判定”については 2 となった。その結果、全てのプログラムのサイクロマティック複雑度がしきい値を上回らないことが確認された。
〔改善の効果〕
簡潔なプログラムにすることによって、プログラムの可読性が高まり、初期開発時の機能実装のミスを減少させることができる。また、プログラムのリリース後に発生する改修や修正の難易度を下げることができる。そうすることによって、ソフトウェアの品質モデルのうち、機能適合性及び g を高めることができる。
Z社で開発している顧客管理システムのような場合、①リリース後の改修や修正の難易度を下げることが、初期開発が容易になることよりも重要であることが多い。
設問1:本文中のa〜cに入れる適切な字句を答えよ。
本文中のa〜cに入れる適切な字句を答えよ。
模範解答
a:2
b:ホワイトボックステスト
c:条件網羅
解説
解答の論理構成
-
【問題文】には「サイクロマティック複雑度 C は
と定義され、図1の場合、ノードの数 N は 4、リンクの数 L は 4 となり、C は a と評価される。」とあります。
したがって
となり、a は 2 です。 -
「ソフトウェアの内部構造及び内部仕様に基づいたテストを b という。」と明示されています。
内部構造に着目するテストはホワイトボックステスト(構造テスト)です。よって b は ホワイトボックステスト となります。 -
続いて「Z社では、b を実施するに当たって、全ての条件分岐の箇所で、個々の判定条件の真及び偽の組合せを満たすことを基準としてテストを実施する方針としている。このような方針を c という。」とあります。
個々の判定条件ごとに真・偽を網羅する基準は条件網羅(Condition Coverage)です。したがって c は 条件網羅 になります。
誤りやすいポイント
- サイクロマティック複雑度の公式を と覚えていても、ノード数とリンク数を逆に代入して と誤計算するケースが多いです。
- 「内部構造に基づくテスト」を“ブラックボックステスト”と書いてしまう混同ミス。ブラックボックスは外部仕様のみを対象とします。
- 「真偽の組合せを満たす」という記述から“判定条件の真偽を一度ずつ通す”決定網羅(Decision Coverage)と早合点しがちですが、個々の条件式を対象にするため正しくは条件網羅です。
FAQ
Q: サイクロマティック複雑度が高いと必ずバグが多いのですか?
A: 高いほど理解・保守が難しくバグ混入リスクが増す傾向はありますが、必ずしもバグが多いと断言できません。複雑度≒テストケース数の増大と捉えるのが実務的です。
A: 高いほど理解・保守が難しくバグ混入リスクが増す傾向はありますが、必ずしもバグが多いと断言できません。複雑度≒テストケース数の増大と捉えるのが実務的です。
Q: ホワイトボックステストでもブラックボックス的な観点は必要ですか?
A: はい。内部構造を網羅しても外部仕様どおりに振る舞う保証にはなりません。両方組み合わせてテストするのが一般的です。
A: はい。内部構造を網羅しても外部仕様どおりに振る舞う保証にはなりません。両方組み合わせてテストするのが一般的です。
Q: 条件網羅と判定網羅の違いは何ですか?
A: 判定網羅は if 文全体の真偽を最低1回ずつ実行する基準、条件網羅は if 文に含まれる 個々の条件式(AND/OR で結ばれた要素)それぞれの真偽を1回ずつ実行する基準です。
A: 判定網羅は if 文全体の真偽を最低1回ずつ実行する基準、条件網羅は if 文に含まれる 個々の条件式(AND/OR で結ばれた要素)それぞれの真偽を1回ずつ実行する基準です。
関連キーワード: サイクロマティック複雑度, ホワイトボックステスト, 条件網羅
設問2:〔評価対象のプログラム〕について、(1)、(2)に答えよ。
(1)本文中のdに入れる適切な字句を答えよ。
模範解答
d:リファクタリング
解説
解答の論理構成
- 【問題文】には
“プログラムの外部的振る舞いを保ったままプログラムの理解や修正が簡単になるように内部構造を改善する d を行うことにした。”
とあります。 - “外部的振る舞いを保ったまま”という条件は、機能・入出力の振る舞いを変えずに内部構造だけを改善する手法を示しています。
- ソフトウェア開発で、この手法を指す用語は “リファクタリング” です。
- したがって、d に入る適切な字句は “リファクタリング” になります。
誤りやすいポイント
- “リストラクチャリング” との混同
“リストラクチャリング”は組織再編などでも使われる語で、ソースコード改善を直接示すとは限りません。 - “リデザイン” と解答する誤り
“リデザイン”は外部仕様も含めて作り直す場合に用いられることが多く、“外部的振る舞いを保ったまま” という条件に合致しません。 - “コード最適化” との取り違え
性能チューニングのみを目的にする場合が多く、理解・保守性向上を目的とする“リファクタリング”とは意図が異なります。
FAQ
Q: “リファクタリング” はどの工程で実施するのが一般的ですか?
A: 実装後のテスト前だけでなく、保守フェーズや機能追加時など、品質向上が必要と判断したタイミングで継続的に実施します。
A: 実装後のテスト前だけでなく、保守フェーズや機能追加時など、品質向上が必要と判断したタイミングで継続的に実施します。
Q: リファクタリングを行うとバグが入り込みませんか?
A: 自動テストを整備し、変更前後で同じテストケースがパスすることを確認すれば、外部的振る舞いの維持を保証できます。
A: 自動テストを整備し、変更前後で同じテストケースがパスすることを確認すれば、外部的振る舞いの維持を保証できます。
Q: サイクロマティック複雑度とリファクタリングの関係は?
A: 複雑度が高い関数を小さく分割・再構成することで複雑度を下げ、テストケース数と保守コストを削減するのがリファクタリングの典型的な効果です。
A: 複雑度が高い関数を小さく分割・再構成することで複雑度を下げ、テストケース数と保守コストを削減するのがリファクタリングの典型的な効果です。
関連キーワード: リファクタリング, サイクロマティック複雑度, テストケース網羅, 保守性, 内部構造改善
設問2:〔評価対象のプログラム〕について、(1)、(2)に答えよ。
(2)図4中のeを埋めて有向グラフを完成させよ。また、本文中のfに入れるサイクロマティック複雑度を求めよ。
模範解答
e:


f:5
解説
解答の論理構成
-
図3のコードを確認すると、未完了案件を扱う部分は次の一行に集約されています。
―― 権限 ← 未完了案件権限判定()(【問題文】図3)
改善前に(A)で示されていた大きな入れ子 if を、名前付き関数に置き換えた箇所です。図4では、その呼出し部のみを一つの処理ノード(長方形)として表現しているため、e には“未完了案件権限判定”というラベルが入ります。 -
サイクロマティック複雑度は
―― サイクロマティック複雑度 C = L - N + 2(【問題文】〔サイクロマティック複雑度〕)
ですが、「判定条件の数+1」で数える方法が実務でよく用いられます。本関数内の判定は
・for( 案件の数だけ繰り返し )
・if( 案件のステータスが完了でない )
・if ( 公開フラグが立っている )
・if ( システム管理者である )
の4か所。したがってとなり、f には “5” が入ります。Z社のしきい値「10」(【問題文】「しきい値を10に設定」)を下回るため、目標を達成しています。
誤りやすいポイント
- “関数に切り出したから 0 に近づく”と早合点し、for ループの判定を数え忘れる。
- if と else の両方を 2 と数えてしまい、複雑度を過大評価する。
- 図4の四角形を「管理者権限判定」と読み違え、e を誤記入する。
FAQ
Q: ループの判定は必ず1カウントするのですか?
A: はい。for や while は分岐点(真なら継続、偽なら終了)を一つ持つので 1 カウントします。
A: はい。for や while は分岐点(真なら継続、偽なら終了)を一つ持つので 1 カウントします。
Q: 関数に切り出すと複雑度が減る理由は?
A: 元の関数から条件分岐を外に出せるため、元関数の判定点が減るからです。切り出した先の関数は個別に測定します。
A: 元の関数から条件分岐を外に出せるため、元関数の判定点が減るからです。切り出した先の関数は個別に測定します。
Q: しきい値を超えたら必ずリファクタリングが必要?
A: 絶対ではありませんが、品質基準として設定している以上、超えた場合は見直しや例外承認が求められるのが一般的です。
A: 絶対ではありませんが、品質基準として設定している以上、超えた場合は見直しや例外承認が求められるのが一般的です。
関連キーワード: サイクロマティック複雑度, メトリクス, 分岐網羅, リファクタリング, 可読性
設問3:〔改善の効果〕について、(1)、(2)に答えよ。
(1)本文中のgに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア:移植性
イ:互換性
ウ:使用性
エ:信頼性
オ:性能効率性
カ:保守性
模範解答
g:カ
解説
解答の論理構成
- 【問題文】には「ソフトウェアの品質モデルのうち、機能適合性及び g を高めることができる。」とあります。
- 直後に「①リリース後の改修や修正の難易度を下げることが、初期開発が容易になることよりも重要である」と続き、改善の狙いが“改修や修正の容易さ”であることを強調しています。
- ISO/IEC 25010 の品質特性で、改修や修正のしやすさを示すのは「保守性(Maintainability)」です。
- 解答群で「保守性」に該当するのは「カ:保守性」であるため、g には「カ」が入ります。
誤りやすいポイント
- 「使用性(ウ)」と混同する
“使いやすさ”という語感で選びがちですが、本文は“改修や修正”に焦点を当てています。 - 「信頼性(エ)」と取り違える
バグが減る→信頼性向上、と短絡しやすいものの、本文は「難易度を下げること」がキーワードです。 - 品質モデルの用語を暗記だけで判断する
文脈(改修・修正)とキーワード(保守容易性)を結び付けて確認することが重要です。
FAQ
Q: 「機能適合性」と「保守性」は同時に向上させられるのですか?
A: はい。今回のように内部構造を整理しテスト容易性を高めれば、正しい機能実装(機能適合性)と改修のしやすさ(保守性)の両方に寄与します。
A: はい。今回のように内部構造を整理しテスト容易性を高めれば、正しい機能実装(機能適合性)と改修のしやすさ(保守性)の両方に寄与します。
Q: “保守性”には具体的にどのような副特性がありますか?
A: ISO/IEC 25010 では「解析性」「変更性」「安定性」「試験性」などが含まれます。今回の文脈は特に「変更性」と「試験性」に該当します。
A: ISO/IEC 25010 では「解析性」「変更性」「安定性」「試験性」などが含まれます。今回の文脈は特に「変更性」と「試験性」に該当します。
Q: サイクロマティック複雑度を下げる以外の保守性向上策は?
A: コーディング規約遵守、命名の一貫性、モジュール間の結合度低減、ドキュメント整備などが代表的です。
A: コーディング規約遵守、命名の一貫性、モジュール間の結合度低減、ドキュメント整備などが代表的です。
関連キーワード: サイクロマティック複雑度, ISO/IEC 25010, メトリクス, モジュール化
設問3:〔改善の効果〕について、(1)、(2)に答えよ。
(2)本文中の下線①について、その理由を35字以内で述べよ。
模範解答
プログラムの改修や修正が継続的に発生することが想定されるから
解説
解答の論理構成
-
開発方針の前提
- 問題文には「運用開始後、家電量販店の業務内容の変化に合わせて、3か月おきを目安に継続的に改修していくことが想定されている。」とあり、リリース後も頻繁に変更が入ることが明示されています。
-
品質改善の目的
- さらに、「簡潔なプログラムにすることによって、…改修や修正の難易度を下げることができる。」と述べ、改修容易性(可保守性)向上が主眼であることを示しています。
-
下線①の主張
- 本文中の下線①は「リリース後の改修や修正の難易度を下げることが、初期開発が容易になることよりも重要である」という主張です。
-
理由付け
- 改修が「3か月おき」に「継続的に改修」されるため、保守工程の負荷が高い。
- したがって、初期開発時よりもリリース後の改修効率が全体のコスト・品質に大きく影響する。
-
以上から、模範解答「プログラムの改修や修正が継続的に発生することが想定されるから」が論理的に導かれます。
誤りやすいポイント
- 「3か月おき」の記述を見落とし、初期開発の容易さを優先してしまう。
- サイクロマティック複雑度のしきい値「10」に着目し過ぎて、保守性との関係を答えに盛り込めない。
- 下線①を“テストの効率が高くなるため”と誤解し、保守性よりテストコスト削減を理由に挙げてしまう。
FAQ
Q: サイクロマティック複雑度を下げるとテストケースは減るのですか?
A: 本文では「サイクロマティック複雑度は小さいが…テストケース数が多くなる」ように、必ずしも比例しません。複雑度低減は主に可読性・保守性向上が狙いです。
A: 本文では「サイクロマティック複雑度は小さいが…テストケース数が多くなる」ように、必ずしも比例しません。複雑度低減は主に可読性・保守性向上が狙いです。
Q: なぜ「3か月おき」の頻度が強調されているのですか?
A: 改修サイクルが短いほど保守コストの割合が大きくなるため、初期開発より改修容易性の方が重要になることを示す根拠になります。
A: 改修サイクルが短いほど保守コストの割合が大きくなるため、初期開発より改修容易性の方が重要になることを示す根拠になります。
Q: 「機能適合性」と並んで強調されている品質特性は何ですか?
A: 文章中の空欄 g は「保守性」に対応します。
A: 文章中の空欄 g は「保守性」に対応します。
関連キーワード: サイクロマティック複雑度, リファクタリング, 可保守性, メトリクス, 継続的改修


