仮の宿 学習室 資格 応用情報技術者 合格ラボ 開発技術 応用情報技術者 APPLIED IT ENGINEER
開発技術
講義 4 本・確認問題 45 問 ｜ 本試験では「テクノロジ系」（50問）の一部 ｜ 最終更新 2026-09-24
この章で学ぶこと どの進め方をいつ選ぶか、そして「作るものを決める工程」で何をするかが分かります。 構造化設計とオブジェクト指向の道具立てと、「よい分割」を測る物差しを身につけます。 「どこまでテストしたか」を数字で言えるようになり、品質の判断ができるようになります。 工数をどう見積もり、変更をどう管理し、品質をどんな観点で語るかを整理します。 1. 開発プロセスと要件定義
どの進め方をいつ選ぶか、そして「作るものを決める工程」で何をするかが分かります。
ソフトウェア開発の進め方には型があり、それぞれ得意な状況が違います。ウォーターフォールモデルは、要件定義、外部設計、内部設計、プログラミング、テスト、運用という工程を順に進め、前の工程が終わってから次に進みます。工程ごとに成果物と承認があるので進捗が管理しやすく、大人数でも分担しやすい反面、後工程で要件の誤りが見つかると手戻りが大きくなります。だから、要件が安定していて、法令や取引先との取決めで作るものがはっきり決まっている案件に向きます。
要件が固まりきらない案件には別の型が要ります。プロトタイピングモデルは、早い段階で試作品を見せて認識のずれを潰す方法です。スパイラルモデルは、システムをいくつかの部分に分け、各部分について設計・実装・評価を繰り返しながら、リスクの大きいところから片付けていく方法です。段階的に動くものを増やしていくインクリメンタル開発、機能を少しずつ育てるエボリューショナル開発なども、いずれも「一度で全部決めない」ことで手戻りの被害を小さくしようとしています。応用情報では、案件の性質を示す文章を読んで、どのモデルが適切かを選ばせる形で問われます。
アジャイル開発は、短い期間の反復で動くソフトウェアを作り続け、変化に対応することを重んじる考え方の総称です。代表的な枠組みがスクラムで、プロダクトオーナー、スクラムマスター、開発者という役割と、スプリント計画、デイリースクラム、スプリントレビュー、レトロスペクティブという場、プロダクトバックログ、スプリントバックログ、インクリメントという成果物で構成されます。プロダクトオーナーは何を作るかの優先順位に責任をもち、スクラムマスターは進め方を支える役で、指示を出す管理者ではありません。ここを取り違える設問がよく出ます。エクストリームプログラミング（XP）はより実装寄りの技法群で、ペアプログラミング、テスト駆動開発、継続的インテグレーション、リファクタリング、小さなリリースなどを掲げます。
見積もりと進捗の見方もウォーターフォールとは異なります。アジャイルでは、作業量を絶対時間ではなく相対的な大きさ（ストーリポイント）で表し、1回の反復でこなせた合計をベロシティとして記録して、次回以降の予測に使います。残作業の推移を描いた図がバーンダウンチャートです。また、機能を減らせても納期と品質は動かしたくない、というように、スコープを調整弁にする点も特徴です。逆に、契約で機能一式と納期が同時に固定されている案件では、アジャイルの利点が出にくくなります。
DevOpsは、開発と運用が対立せずに協働し、変更を素早く安全に本番へ届けることを目指す文化と実践です。これを支える技術がCI/CDです。継続的インテグレーション（CI）は、変更を1日に何度も共通のリポジトリへ統合し、そのたびに自動でビルドとテストを走らせて、壊れたことをすぐ知る仕組みです。継続的デリバリは、そこからいつでもリリースできる状態を常に保つこと、継続的デプロイメントは、検査に通った変更を自動で本番へ反映することを指します。あわせて、サーバの構成をコードで定義して再現可能にするInfrastructure as Codeや、コンテナによる環境の統一が使われます。狙いは、1回のリリースを大きくしないことで失敗の影響を小さくし、切り戻しを容易にすることにあります。
工程の共通の言葉としては、共通フレームが用意されています。企画、要件定義、開発、運用、保守といった作業を、発注側と受注側が同じ言葉で語れるようにするための枠組みで、「何をどこまでやるか」の取り違えを防ぐことが目的です。何をどう作るかまで規定するものではない点に注意します。
作るものを決める工程が要求分析と要件定義です。まず現状の業務と課題を把握し、利害関係者から要求を引き出します。引出しの技法には、インタビュー、アンケート、観察、ワークショップ、既存資料の分析、プロトタイプへの反応の観察などがあります。集めた要求は整理して、実現する範囲を決めます。要件は、業務要件（業務としてどうなっていたいか）、機能要件（システムが何をするか）、非機能要件（どのくらいの品質で提供するか）に分けます。非機能要件には、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境などの区分があり、IPAの非機能要求グレードが整理の手掛かりになります。
要件定義の成否を分けるのは、要求の質を確かめる作業です。よい要件は、検証可能であること（何をもって満たしたと言えるかが書いてある）、一意であること（読む人によって解釈が変わらない）、実現可能であること、そして要求元までたどれること（トレーサビリティ）を満たします。「使いやすいこと」「高速であること」のような書き方は検証できないので、応答時間や操作手順数のように測れる形に直します。また、要件は途中で必ず変わるので、変更を受け付ける手続と、変更が及ぼす影響の評価方法を最初に決めておくことが、後の混乱を防ぎます。
開発モデルの選び分け モデル 向いている案件 弱点 ウォーターフォール 要件が安定し、成果物と承認を明確にしたい大規模案件 後工程で要件の誤りが判明したときの手戻りが大きい プロトタイピング 画面や操作感の合意が難しく、言葉では詰めきれない案件 試作品が完成品と誤解されやすく、作り捨ての工数がかかる スパイラル 技術的なリスクが高く、早く見極めたい案件 反復の管理が複雑になり、終わりが見えにくくなりやすい アジャイル（スクラム） 要件の変化が前提で、利用者と密に関われる案件 機能一式と納期が同時に固定された契約とは相性が悪い
用語 ウォーターフォールモデル 工程を順に進め、前工程の完了を承認してから次へ進む開発モデル。進捗管理と分担がしやすい反面、後工程での手戻りが大きい。 プロトタイピングモデル 早い段階で試作品を作って利用者に見せ、認識のずれを解消してから作り込む開発モデル。要件が固まりにくい案件に向く。 スパイラルモデル システムを部分に分け、各部分で設計・実装・評価を繰り返しながら、リスクの大きいところから解決していく開発モデル。 アジャイル開発 短い反復で動くソフトウェアを作り続け、変化への対応を重んじる開発の考え方の総称。スクラムやXPが代表的な実践。 スクラム プロダクトオーナー、スクラムマスター、開発者の役割と、スプリントを軸とした場と成果物で構成されるアジャイルの枠組み。 プロダクトオーナー 何を作るかの優先順位に責任をもつ役割。プロダクトバックログの並び順を決める権限をもつ。 スクラムマスター 進め方が機能するよう支援し、障害を取り除く役割。開発者に作業を割り当てる管理者ではない。 スプリント スクラムにおける固定長の反復期間。期間中に完成の定義を満たすインクリメントを作る。期間の途中で目標を差し替えない。 ストーリポイントとベロシティ 作業量を相対的な大きさで表した値と、1回の反復で完了できた合計値。実績から次回の予測を立てるために使う。 バーンダウンチャート 残作業量の推移を時間軸に沿って描いた図。予定線との差から遅れや前倒しを早く見つけられる。 エクストリームプログラミング ペアプログラミング、テスト駆動開発、継続的インテグレーション、リファクタリング、小さなリリースなどを掲げる実装寄りのアジャイル技法群。 DevOps 開発と運用が協働し、変更を素早く安全に本番へ届けることを目指す文化と実践。自動化と計測、責任の共有を柱とする。 継続的インテグレーション 変更を頻繁に共通のリポジトリへ統合し、そのたびに自動でビルドとテストを実行して、壊れたことを早く知る仕組み。 継続的デリバリと継続的デプロイメント 前者はいつでもリリースできる状態を保つこと、後者は検査に通った変更を自動で本番へ反映すること。人の承認を挟むかどうかが違う。 Infrastructure as Code サーバやネットワークの構成をコードで定義し、同じ環境を何度でも再現できるようにする手法。差異による障害を減らせる。 共通フレーム 企画から保守までの作業を、発注側と受注側が同じ言葉で語れるように整理した枠組み。作り方そのものを規定するものではない。 要求分析 現状の業務と課題を把握し、利害関係者から要求を引き出して整理する作業。インタビュー、観察、ワークショップなどの技法がある。 機能要件と非機能要件 機能要件はシステムが何をするか、非機能要件はどのくらいの品質で提供するか。可用性、性能、運用保守性、移行性、セキュリティなどが後者に含まれる。 非機能要求グレード 非機能要件の項目と水準を段階で示し、発注側と受注側で合意しやすくするために整理された手引。 トレーサビリティ ある要件がどの要求から来て、どの設計・実装・テストに対応するかをたどれること。変更時の影響範囲の特定に効く。 例題
例題：「新サービスの利用者向け画面を作りたいが、どんな機能が受け入れられるか自社でも読み切れていない。利用部門の担当者は週2回、開発チームと同席できる」という案件がある。適した進め方はどれか。
答えと考え方 アジャイル開発、なかでもスクラムのような反復型が適する。作るものが読み切れていない以上、最初に全機能を確定させる前提のウォーターフォールでは、要件の誤りが後工程でまとめて表面化する。短い反復ごとに動くものを見せ、利用部門の反応を次の優先順位に反映できるほうが有利で、利用部門が定期的に同席できるという条件もこれを後押しする。逆に、
例題：非機能要件として「レスポンスが速いこと」と書かれていた。この記述の何が問題で、どう直せばよいか。
答えと考え方 問題は検証可能でないことである。「速い」の水準が人によって異なるため、完成後に満たしたかどうかを誰も判定できず、受入れの場で争いになる。直すには、対象の処理、条件、測る位置、目標値、達成率を明示する。たとえば「同時利用者50人の状態で、月次の一覧表示の応答時間が3秒以内であることを、全要求の90パーセントについて満たす」といった形にする。同じ考え方は可用性（稼働率と計画停止の扱い）、移行性（切替えに許される時間）にも当てはまる。
出典・根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
2. 設計とモジュールの良し悪し
構造化設計とオブジェクト指向の道具立てと、「よい分割」を測る物差しを身につけます。
設計は、外部設計と内部設計に分けて考えます。外部設計は利用者やほかのシステムから見える面を決める工程で、画面、帳票、外部インタフェース、コード体系、論理データ構造などを設計します。内部設計はそれを実現する内側を決める工程で、モジュールへの分割、モジュール間のインタフェース、物理データ構造、処理の詳細などを設計します。境目は「利用者に見えるかどうか」で、たとえば画面の項目配置は外部設計、その画面を作るモジュールの分け方は内部設計です。
構造化設計では、処理の流れとデータの流れに着目します。DFDはデータの流れ、処理、データストア、外部実体の四つの記号で業務やシステムを表す図で、データがどこから来てどこへ行くかを追えます。状態が意味をもつ対象には状態遷移図、データの意味と関連を整理するにはE-R図を使います。モジュールへの分割方針としては、データの流れの変換点で切るSTS分割、入力データの種類ごとに切るトランザクション分割、共通処理を切り出す共通機能分割などが知られています。
分割の良し悪しを測る物差しが結合度と凝集度です。結合度はモジュール間の結び付きの強さで、弱いほどよい設計です。弱い順に、データ結合（必要なデータ項目だけを引数で渡す）、スタンプ結合（データ構造全体を渡し、受け手は一部だけ使う）、制御結合（相手の動作を切り替える制御用の値を渡す）、外部結合（外部宣言した個々のデータを共有する）、共通結合（共通領域のデータを複数モジュールが参照する）、内容結合（相手の内部を直接参照したり飛び込んだりする）の順に強くなります。結合が強いほど、片方を直すともう片方も壊れやすくなります。
凝集度はモジュール内部のまとまりの良さで、強いほどよい設計です。弱い順に、暗合的凝集（関係のない処理を寄せ集めただけ）、論理的凝集（似た種類の処理をまとめ、引数で選ばせる）、時間的凝集（初期化処理のように同じ時期に実行するものをまとめる）、手順的凝集（順に実行する処理をまとめる）、連絡的凝集（同じデータを扱う処理を順にまとめる）、情報的凝集（同じデータ構造を扱う複数の入口をもつ）、機能的凝集（単一の機能だけを実現する）の順に強くなります。目指すのは「結合度は弱く、凝集度は強く」で、この二つは対の物差しとして覚えます。
オブジェクト指向設計は、データとそれを操作する手続きを一体にしたオブジェクトを単位に組み立てます。中心となる概念はカプセル化、継承、多相性（ポリモーフィズム）です。カプセル化は内部のデータを隠して公開した操作だけを通じて扱わせること、継承は共通の性質を上位のクラスにまとめて下位が引き継ぐこと、多相性は同じ呼び出しに対してオブジェクトの種類ごとに異なる動作を返せることです。多相性があると、種類が増えても呼び出す側を書き換えずに済みます。関連する概念に、実装をもたない操作だけを定めた抽象クラスやインタフェース、クラスの集約と合成、そして継承よりも委譲を優先するという設計上の指針があります。
モデルを表す標準の記法がUMLです。構造を表す図にはクラス図、オブジェクト図、コンポーネント図、配置図があり、ふるまいを表す図にはユースケース図、シーケンス図、コミュニケーション図、アクティビティ図、状態マシン図があります。どの図が何を表すかは頻出です。クラス図はクラスと属性、操作、関連、多重度を表し、シーケンス図はオブジェクト間のメッセージのやり取りを時間軸に沿って表し、ユースケース図は利用者から見た機能のまとまりと利用者との関係を表します。アクティビティ図は処理や業務の流れ、状態マシン図は一つの対象がとる状態と遷移の条件を表します。
設計の定石を名前付きで共有したものがデザインパターンです。生成に関するもの、構造に関するもの、ふるまいに関するものに大別されます。よく問われるのは、インスタンスを一つに限るSingleton、生成するクラスの決定を下位に委ねるFactory Method、状態の変化を登録された相手へ知らせるObserver、既存のインタフェースを別の形に合わせるAdapter、アルゴリズムを差し替え可能にするStrategy、対象を包んで機能を足すDecoratorあたりです。パターンは目的があってこそ意味があるので、当てはめること自体が目的にならないように注意します。
設計を評価するときの一般的な指針もあります。単一責任の原則は、一つのモジュールが変更される理由は一つであるべきだという考え方です。開放閉鎖の原則は、機能追加に対しては開いていて、既存コードの修正に対しては閉じている構造を目指すという考え方で、多相性やインタフェースの活用で実現します。関心の分離、疎結合と高凝集、そして重複を作らないことは、構造化設計でもオブジェクト指向設計でも共通して効く指針です。
結合度と凝集度（上ほど望ましい） 望ましさ 結合度（弱いほどよい） 凝集度（強いほどよい） 最もよい データ結合 機能的凝集 よい スタンプ結合 情報的凝集 ふつう 制御結合 連絡的凝集 やや悪い 外部結合 手順的凝集 悪い 共通結合 時間的凝集 最も悪い 内容結合 論理的凝集、暗合的凝集
クラス図の読み方（属性・操作・関連の多重度）
+-----------------+ +-----------------+ | 注文 | | 注文明細 | +-----------------+ 1 0..* +-----------------+ | -注文番号 | ----------- | -行番号 | | -注文日 | | -数量 | +-----------------+ +-----------------+ | +合計を求める() | | +小計を求める() | +-----------------+ +-----------------+ | 0..* | | 1 +-----------+ | 商品 | +-----------+ | -商品番号 | | -単価 | +-----------+ /* 端の数字は多重度。1つの注文に明細が0本以上、 1つの明細が指す商品はちょうど1つ、と読む */ 用語 外部設計と内部設計 外部設計は画面、帳票、外部インタフェースなど利用者から見える面を決める工程。内部設計はモジュール分割や物理データ構造など内側を決める工程。 DFD データの流れ、処理、データストア、外部実体の4記号で業務やシステムを表す図。データがどこから来てどこへ行くかを追える。 STS分割 処理を入力（源泉）、変換、出力（吸収）の3つに分け、データの流れの変換点でモジュールを切る分割技法。 結合度 モジュール間の結び付きの強さ。弱いほどよい。弱い順にデータ結合、スタンプ結合、制御結合、外部結合、共通結合、内容結合。 データ結合 必要なデータ項目だけを引数として受け渡す、最も弱い結合。相手の内部構造に依存しないので変更に強い。 制御結合 相手の動作を切り替えるための制御用の値を渡す結合。呼ぶ側が相手の内部の処理分岐を知っている状態になるため、結合が強い。 共通結合 共通領域に置いたデータを複数のモジュールが参照・更新する結合。誰がいつ書き換えたかを追いにくく、影響範囲が広がる。 内容結合 相手の内部データを直接参照したり、途中へ飛び込んだりする最も強い結合。片方の変更がそのまま相手を壊す。 凝集度 モジュール内部のまとまりの良さ。強いほどよい。弱い順に暗合的、論理的、時間的、手順的、連絡的、情報的、機能的。 論理的凝集 似た種類の処理をひとまとめにし、引数で実行する処理を選ばせる弱い凝集。分岐が増え、呼ぶ側との結合も強くなりやすい。 機能的凝集 単一の機能だけを実現している最も強い凝集。再利用しやすく、変更の影響も閉じ込めやすい。 カプセル化 内部のデータを隠し、公開した操作を通じてのみ扱わせること。内部の作りを変えても利用側に影響が及ばない。 多相性 同じ呼び出しに対して、オブジェクトの種類ごとに異なる動作が実行される性質。種類が増えても呼ぶ側を変えずに済む。 クラス図 クラスとその属性・操作、クラス間の関連や多重度、継承関係を表すUMLの構造図。 シーケンス図 オブジェクト間でやり取りされるメッセージを、時間の流れに沿って表すUMLのふるまい図。 ユースケース図 利用者（アクタ）から見た機能のまとまりと、その利用関係を表すUMLの図。システムの範囲を合意するのに使う。 状態マシン図 一つの対象がとりうる状態と、状態を移す事象や条件を表すUMLの図。状態が意味をもつ対象の設計に使う。 Singleton そのクラスのインスタンスが一つしか存在しないことを保証する生成に関するデザインパターン。 Observer 対象の状態が変わったときに、登録された相手へ自動的に通知するふるまいに関するデザインパターン。 Strategy アルゴリズムを個別のクラスに切り出し、実行時に差し替えられるようにするふるまいに関するデザインパターン。 単一責任の原則 一つのモジュールが変更される理由は一つであるべきだという設計指針。責任が混ざると、片方の変更が他方を壊す。 開放閉鎖の原則 機能の追加に対しては開いており、既存コードの修正に対しては閉じている構造を目指す設計指針。多相性やインタフェースで実現する。 例題
例題：あるモジュールが、呼出し側から渡された区分値によって「登録」「更新」「削除」のいずれかを内部で選んで実行している。結合度と凝集度の観点でどう評価できるか。
答えと考え方 結合度は制御結合、凝集度は論理的凝集にあたり、どちらも望ましくない側である。呼出し側が相手の内部の分岐を知っていないと正しい区分値を渡せないので、相手の作りを変えると呼出し側も直すことになる。また、モジュールの中に関係の薄い三つの処理が同居しているので、片方の修正が他方を壊す危険がある。登録・更新・削除をそれぞれ独立したモジュールに分け、必要なデータ項目だけを引数で渡すデータ結合にすれば、結合度は弱く、凝集度は機能的凝集まで上げられる。
例題：ある顧客クラスが、顧客の属性の保持に加えて、請求書のPDFへの整形と、データベースへの保存処理まで抱えている。設計上どこが問題で、どう直すか。
答えと考え方 一つのクラスが変更される理由を三つ抱えている点が問題で、単一責任の原則に反している。請求書の様式が変わっても、保存先のデータベース製品が変わっても、顧客の属性が増えても、同じクラスを直すことになるため、無関係な変更が互いに影響し合う。直すには、顧客の属性と業務上のふるまいを持つクラス、整形を担うクラス、保存を担うクラスに分ける。こうすると、それぞれのクラスの変更理由が一つになり、テストも独立して書けるようになる。関心の分離と高凝集は、オブジェクト指向でも構造化設計でも共通して効く指針である。
出典・根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
3. 実装とテスト
「どこまでテストしたか」を数字で言えるようになり、品質の判断ができるようになります。
実装工程では、書き方をそろえるコーディング規約が土台になります。命名、字下げ、コメント、エラー処理の書き方、禁止する構文などを決めておくと、読みやすさが上がり、レビューでの指摘が本質的な内容に集中します。規約への適合や典型的な不具合の兆候は、プログラムを実行せずにソースコードを解析する静的解析ツールで機械的に調べられます。実際に動かして挙動を調べるのは動的解析で、両者は補い合う関係です。
人の目による確認がレビューです。作成者が説明して参加者が指摘するウォークスルー、あらかじめ役割と手順を定めて記録を残す公式なインスペクション、机上で他人のコードを読むデスクチェック、その場で相談しながら書くペアプログラミングなどがあります。レビューの効用は、テストより前の段階で欠陥を見つけられることにあります。欠陥は見つかるのが遅いほど修正費用が大きくなるため、上流での検出は費用対効果が高くなります。レビューの場では、欠陥を指摘することに集中し、人を責めないこと、その場で修正方法まで議論しすぎないことが実務上の要点です。
テストは、内部構造を見て設計するホワイトボックステストと、仕様だけを見て設計するブラックボックステストに大別されます。ホワイトボックステストの網羅基準には段階があります。命令網羅（C0）はすべての命令を少なくとも1回実行すること、判定条件網羅（分岐網羅、C1）はすべての判定の真と偽を少なくとも1回ずつ通ること、条件網羅（C2）は判定の中の個々の条件が真と偽を少なくとも1回ずつとること、複数条件網羅は個々の条件の真偽のすべての組合せを通ることです。強さは、命令網羅より分岐網羅、分岐網羅より複数条件網羅が強くなります。注意したいのは、条件網羅を満たしても判定条件網羅を満たすとは限らない点です。個々の条件の真偽はそろっていても、判定全体の結果が片方に偏ることがあるためです。
ブラックボックステストの基本技法は、同値分割と境界値分析です。同値分割は、入力の集合を「同じ結果になるはず」のグループに分け、各グループから代表値を1つ選ぶ方法です。有効な値のグループと、無効な値のグループを両方作るのが要点になります。境界値分析は、グループの境目の値とその隣の値を選ぶ方法です。境目の判定は不等号の向きや等号の有無を間違えやすく、欠陥が集中するので、少ないケース数で多くの欠陥を拾えます。ほかに、条件の組合せを表にする決定表、入力の順序や状態の遷移に着目する状態遷移テスト、複数の要因の組合せを効率よく網羅する直交表を使う技法などがあります。
テストの工程は段階を追って広がります。単体テストはモジュール単体の内部構造まで見て確かめ、結合テストはモジュール間のインタフェースを確かめます。結合の進め方には、上位から順に組んで下位の代わりにスタブを使うトップダウンテストと、下位から順に組んで上位の代わりにドライバを使うボトムアップテスト、両方から進めるサンドイッチテストがあります。システムテストは、機能だけでなく性能、負荷、セキュリティ、障害時のふるまいなど、システム全体の要件を確かめます。運用テストや受入テストは、発注側が実際の業務の流れで使えるかを確かめる段階です。あわせて、変更した箇所以外が壊れていないことを確かめる回帰テストが、修正のたびに要ります。回帰テストは繰り返し実行されるので、自動化の効果が最も大きい領域です。
品質の状態を数字で判断するための指標もあります。バグ密度は、検出した欠陥数を規模で割った値で、単位は1キロステップあたりの件数がよく使われます。テスト密度は、テストケース数を規模で割った値です。この二つを組み合わせると、テストが足りないのか、品質が高いのかを切り分けられます。たとえばバグ密度が想定より低いとき、品質が高いという解釈と、テストが十分に行われていないという解釈の両方がありえます。テスト密度も低ければ後者の疑いが濃くなり、テスト密度が十分なのにバグ密度が低いなら前者の可能性が高まる、という読み方をします。数字を1つだけ見て結論を出さないのが要点です。
テストの進み具合を見る図が信頼度成長曲線（ゴンペルツ曲線やロジスティック曲線）です。横軸にテストの経過（時間やテストケースの累計）、縦軸に累積の欠陥検出数をとると、初期はゆるやかに、中盤は急に、終盤は再びゆるやかになるS字を描きます。曲線が寝てきて新たな欠陥がほとんど出なくなったことが、テスト終了を判断する材料の一つになります。ただし、曲線が寝ているのは欠陥が出尽くしたからではなく、テストの内容が偏っていて同じ経路ばかり通っている場合もあるので、網羅率や未実施のテストケース数と合わせて判断します。
テストで見つけた欠陥は記録して管理します。発見日、発生条件、再現手順、原因、修正内容、確認結果を残すと、同じ原因の欠陥がどこに潜んでいるかを推測でき、再発防止の議論にもつながります。欠陥の原因を「作り込んだ工程」と「見つけた工程」の組合せで集計すると、どの工程の検証が弱いかが見えてきます。上流で作り込んだ欠陥が下流で見つかっているなら、レビューの強化が効く、という判断ができます。
テスト工程と、確かめること 工程 確かめること 特徴的な道具・技法 単体テスト モジュール単体が仕様どおり動くか ホワイトボックステスト、網羅基準、静的解析 結合テスト モジュール間のインタフェースが合っているか スタブ、ドライバ、トップダウン・ボトムアップ システムテスト 性能、負荷、セキュリティ、障害時のふるまい 負荷試験、障害注入、セキュリティ診断 運用テスト・受入テスト 実際の業務の流れで使えるか 業務シナリオ、本番相当データ 回帰テスト 変更した箇所以外が壊れていないか テストの自動化、継続的インテグレーション
○文字列型: 判定(整数型: score) 文字列型: rank if (score ≧ 80) rank ← "A" elseif (score ≧ 60) rank ← "B" else rank ← "C" endif return rank /* 命令網羅も判定条件網羅も、最小3ケースで満たせる（例: 80、60、0）*/ /* 境界値分析で選ぶ値は 59、60、79、80 の4点 */ /* 境目のずれは探索にも現れる。while の条件を lo < hi と書くと、 候補が1個になった時点で抜けてしまい、その1個を調べ損ねる */ ○整数型: 二分探索(整数型の配列: a, 整数型: 値) 整数型: lo ← 1 整数型: hi ← aの要素数 整数型: mid while (lo ≦ hi) mid ← (lo + hi) ÷ 2 の商 if (a[mid] = 値) return mid elseif (a[mid] < 値) lo ← mid + 1 else hi ← mid - 1 endif endwhile return -1 /* 見つからない */ 用語 コーディング規約 命名、字下げ、コメント、エラー処理などの書き方をそろえる取決め。読みやすさが上がり、レビューが本質的な指摘に集中できる。 静的解析 プログラムを実行せずにソースコードを解析し、規約違反や典型的な不具合の兆候を検出する手法。動的解析と補い合う。 インスペクション あらかじめ役割と手順を定め、記録を残して行う公式なレビュー。検出した欠陥を集計し、工程の改善につなげられる。 命令網羅（C0） すべての命令を少なくとも1回実行するホワイトボックステストの網羅基準。最も弱い基準で、判定の偽の側を通らないことがある。 判定条件網羅（C1） すべての判定について、真になる場合と偽になる場合を少なくとも1回ずつ通す基準。分岐網羅ともいう。 条件網羅（C2） 判定の中の個々の条件が、真と偽を少なくとも1回ずつとるようにする基準。判定全体の結果が偏り、分岐網羅を満たさないことがある。 複数条件網羅 判定の中の個々の条件の真偽について、すべての組合せを通す最も強い基準。条件が増えるとケース数が急増する。 同値分割 入力を同じ結果になるはずのグループに分け、各グループから代表値を1つ選ぶ技法。有効なグループと無効なグループの両方を作る。 境界値分析 グループの境目の値とその隣の値を選ぶ技法。不等号の向きや等号の有無の誤りが集中するため、少ないケースで多くの欠陥を拾える。 決定表 条件の組合せと、それに対する動作を表形式で整理したもの。条件が複数絡む仕様の抜け漏れを見つけやすい。 スタブとドライバ 結合テストで使う仮のモジュール。スタブは呼ばれる側の代わり（トップダウンで使う）、ドライバは呼ぶ側の代わり（ボトムアップで使う）。 回帰テスト 変更した箇所以外が壊れていないことを確かめるテスト。修正のたびに繰り返すため、自動化の効果が最も大きい。 バグ密度 検出した欠陥数を規模で割った値。1キロステップあたりの件数で表すことが多い。単独では品質の高低を判断できない。 テスト密度 テストケース数を規模で割った値。バグ密度と組み合わせて、テスト不足なのか品質が高いのかを切り分ける。 信頼度成長曲線 テストの経過に対する累積欠陥検出数を描いたS字の曲線。ゴンペルツ曲線やロジスティック曲線が使われ、終了判断の材料になる。 システムテスト 機能に加えて性能、負荷、セキュリティ、障害時のふるまいなど、システム全体の要件を確かめる工程。 受入テスト 発注側が、実際の業務の流れでシステムが使えるかを確かめる工程。合格をもって検収に進む。 欠陥の作り込み工程と検出工程 欠陥をこの2つの組合せで集計すると、どの工程の検証が弱いかが見える。上流で作り込み下流で検出されているならレビューの強化が効く。 例題
例題：上の擬似言語のプログラムについて、命令網羅と判定条件網羅を満たす最小のテストケース数はそれぞれいくつか。また境界値分析ではどの値を選ぶか。
答えと考え方 命令網羅は3ケース、判定条件網羅も3ケースである。rankへの代入は3か所あり、それぞれ別の経路でしか実行されないので、命令をすべて通すには3ケースが要る。そしてこの3ケースを通せば、2つの判定それぞれについて真と偽の両方を通っているので、判定条件網羅も同時に満たされる。境界値分析では、区分の境目が60と80なので、59、60、79、80の4点を選ぶ。80以上と60以上という判定は、不等号に等号を含めるかどうかを間違えやすいところで、まさに境界値が効く。
例題：「x が 5 以上、かつ y が 3 以下」という判定について、テストケースを（x が5、y が10）と（x が1、y が3）の2件だけ用意した。条件網羅と判定条件網羅のどちらを満たしているか。
答えと考え方 条件網羅は満たすが、判定条件網羅は満たさない。1件目では「x が5以上」が真、「y が3以下」が偽、2件目では「x が5以上」が偽、「y が3以下」が真となり、個々の条件はどちらも真と偽の両方をとっている。ところが、かつ（論理積）で結んだ判定全体の結果は、1件目も2件目も偽である。判定が真になる場合を1度も通っていないので、分岐網羅は満たしていない。条件網羅は判定条件網羅を包含しない、という定番の注意点がここに表れている。
出典・根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
4. 見積もり・構成管理・保守と品質
工数をどう見積もり、変更をどう管理し、品質をどんな観点で語るかを整理します。
見積もりの方法は大きく三系統です。類推見積法は、過去の似た案件の実績を土台に、規模や難易度の差を補正して見積もる方法で、手早くできる反面、似た実績がないと精度が落ちます。ボトムアップ見積法（積上げ法、標準タスク法）は、作業を細かく分解して各作業の工数を積み上げる方法で、精度は高いものの、作業を分解できる程度まで内容が固まっていないと使えません。パラメトリック見積法は、規模などの数値から統計的な式で工数を算出する方法で、ファンクションポイント法やCOCOMOが該当します。ほかに、複数の専門家の見積もりを匿名で集めて収束させるデルファイ法があります。工程の初期は類推やパラメトリック、内容が固まってきたらボトムアップ、と使い分けるのが定石です。
ファンクションポイント法は、利用者から見た機能の数と複雑さから規模を測る方法です。数えるのは、システムが内部で保持するデータの集まり（内部論理ファイル）、外部から参照するデータの集まり（外部インタフェースファイル）、外部からの入力（外部入力）、外部への出力（外部出力）、外部からの照会（外部照会）の五種類です。それぞれの件数に複雑さに応じた重みを掛けて合計したものが未調整ファンクションポイントで、ここにシステム特性による補正係数を掛けて調整済みの値を得ます。この方法の利点は、プログラム言語や実装方法に依存せず、利用者と会話できる単位で規模を語れることです。逆に、内部の処理が重いだけで画面や帳票が少ないシステムでは実態より小さく出ることがあります。
COCOMOは、規模（キロステップ）から工数を推定する式を用いる方法です。工数は規模の1より大きいべき乗に比例する形になっていて、規模が2倍になると工数は2倍より大きくなります。たとえば指数が1.05なら、規模2倍で工数は約2.07倍です。これは、規模が大きくなるほど連絡や調整の手間が増えることを表しています。同じ理由で、遅れているプロジェクトに人を追加するとかえって遅くなる、というブルックスの法則が知られています。工数と期間は独立ではなく、要員を増やして期間を無理に縮めようとすると、追加の伝達コストが効いて破綻しやすくなります。
見積もりで押さえたいのは、工数と期間の区別です。工数は延べの作業量（人月、人日）で、期間は暦の上での長さです。10人月の作業を1か月で終わらせるには10人が同時に動ける前提が要りますが、作業には順序の制約があるので、単純に割り算はできません。また、見積もりには前提条件が必ず付きます。要件の確定時期、利用できる要員の技能、既存システムの資料の有無などを明記しないと、後で「そんな話は聞いていない」となります。
変更を管理する仕組みが構成管理です。何を管理対象とするか（構成品目の識別）、変更をどう申請し承認するか（変更管理）、いまどの版が正なのかをどう記録するか（構成状況の記録）、実物と記録が一致しているか（構成監査）という要素からなります。管理対象はソースコードだけでなく、設計書、テスト仕様書、環境の設定、依存するライブラリの版も含みます。リリースした版と、その版に含まれる構成品目の対応が記録されていないと、障害が起きたときに何が動いているのかが分からなくなります。
バージョン管理システムは構成管理を支える道具です。変更の履歴を記録し、誰がいつ何を変えたかを追え、任意の時点へ戻せます。複数人での同時作業は、ブランチを切って独立に進め、完了したら本流へ統合する形で扱います。統合の際に同じ箇所を別々に変更していると競合が起き、人が判断して解決します。ブランチを長く放置するほど競合は大きくなるので、こまめに統合するのが継続的インテグレーションの発想です。タグを打ってリリース時点を記録しておくと、後から正確にその版を再現できます。
本番化の前後で必要になるのが移行と保守です。移行では、データの移し替え、並行稼働の期間、切戻しの判断基準と手順、利用者への周知を計画します。切替え方式には、いっせいに切り替える一斉移行、部門や機能ごとに段階的に移す段階移行、新旧を一定期間並べて動かす並行運用があり、リスクとコストの兼ね合いで選びます。保守は、障害を直す是正保守、障害になる前に予兆に手を打つ予防保守、環境の変化に合わせる適応保守、性能や保守性を高める完全化保守に分類されます。是正保守だけが保守ではない、という点が問われます。
品質を語る共通の言葉がソフトウェア品質特性です。ISO/IEC 25010:2011では、機能適合性、性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性といった特性が定められ、それぞれが副特性に分かれます。要件定義でこの一覧を手掛かりにすると、抜け落ちがちな観点に気付けます。あわせて、ソフトウェアの再利用も品質と生産性の両面に効きます。共通部品化、ライブラリやフレームワークの活用、コード生成、そして既存システムを解析して仕様を取り出すリバースエンジニアリング、取り出した仕様から作り直すフォワードエンジニアリングといった手法があります。再利用は、部品の品質と説明書、そして版の管理が伴って初めて効果が出ます。
見積技法の使い分け 技法 使える時期 強み 弱み 類推見積法 企画から要件定義の初期 短時間で概算が出せる 似た実績がないと精度が落ちる ファンクションポイント法 要件が機能単位で見えてきた時期 言語に依存せず利用者と会話できる 内部処理が重いシステムでは小さく出やすい COCOMO 規模をキロステップで見積もれる時期 規模と工数の非線形な関係を扱える 規模の見積もりそのものに精度が要る ボトムアップ見積法 作業を分解できる程度に固まった時期 精度が高く、担当者の納得も得やすい 分解に手間がかかり、初期には使えない
用語 類推見積法 過去の似た案件の実績を土台に、規模や難易度の差を補正して見積もる方法。手早いが、似た実績がないと精度が落ちる。 ボトムアップ見積法 作業を細かく分解し、各作業の工数を積み上げる方法。標準タスク法ともいう。精度は高いが、作業を分解できるまで内容が固まっている必要がある。 パラメトリック見積法 規模などの数値から統計的な式で工数を算出する方法。ファンクションポイント法やCOCOMOが該当する。 デルファイ法 複数の専門家の見積もりを匿名で集め、結果を共有して繰り返すことで収束させる方法。声の大きさに引きずられにくい。 ファンクションポイント法 内部論理ファイル、外部インタフェースファイル、外部入力、外部出力、外部照会の件数に重みを掛けて規模を測る方法。言語に依存しない。 未調整ファンクションポイント 各機能の件数に複雑さに応じた重みを掛けて合計した値。ここにシステム特性による補正係数を掛けて調整済みの値を得る。 COCOMO 規模から工数を推定する式を用いる見積技法。工数は規模の1より大きいべき乗に比例し、規模が2倍になると工数は2倍より大きくなる。 ブルックスの法則 遅れているプロジェクトに人を追加すると、伝達と教育の手間が増えてさらに遅れるという経験則。 工数と期間 工数は延べの作業量（人月、人日）、期間は暦の上での長さ。作業には順序の制約があるため、工数を人数で割っても期間にはならない。 構成管理 構成品目の識別、変更管理、構成状況の記録、構成監査からなる仕組み。ソースコードだけでなく設計書や環境設定、依存ライブラリの版も対象になる。 構成監査 記録されている構成と実物が一致しているかを確かめる活動。記録だけが更新されて実物が違う、という食い違いを見つける。 ブランチとマージ 本流から分岐して独立に作業し、完了後に本流へ統合する仕組み。放置するほど競合が大きくなるため、こまめな統合が望ましい。 一斉移行・段階移行・並行運用 新システムへの切替え方式。順に、いっせいに切り替える、部門や機能ごとに移す、新旧を一定期間並べて動かす。リスクとコストの兼ね合いで選ぶ。 是正保守 発生した障害を取り除く保守。発見された欠陥への対応にあたる。 予防保守 障害として現れる前に、潜在的な欠陥や劣化の予兆に手を打つ保守。 適応保守 OSの更新、法令の改正、業務の変更といった環境の変化にソフトウェアを合わせる保守。 完全化保守 性能、保守性、使いやすさなどを高めるための保守。障害への対応ではなく、よりよくするための変更である。 ソフトウェア品質特性 ISO/IEC 25010:2011が定める、機能適合性、性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性などの観点。要件の抜け漏れを防ぐ手掛かりになる。 リバースエンジニアリング 既存のソフトウェアを解析して、設計や仕様を取り出す手法。資料が失われた既存システムの刷新で使われる。 リエンジニアリング 既存システムを解析して仕様を取り出し、それをもとに新しい技術で作り直す取組み全体。リバースエンジニアリングとフォワードエンジニアリングを合わせたもの。 フォワードエンジニアリング リバースエンジニアリングで取り出した仕様をもとに、新しいソフトウェアを作成する手法。 例題
例題：内部論理ファイルが2件、外部インタフェースファイルが1件、外部入力が5件、外部出力が3件、外部照会が4件と数えられた。重みをそれぞれ10、7、4、5、4とするとき、未調整ファンクションポイントはいくつか。
答えと考え方 件数と重みを掛けて足し合わせる。2×10で20、1×7で7、5×4で20、3×5で15、4×4で16となり、合計は78である。ここでよくある誤りが、外部インタフェースファイルを数え忘れて71としてしまうこと、そして件数をそのまま足して15としてしまうことである。実際にはこの後、システム特性による補正係数を掛けて調整済みの値を求める。補正係数は0.65に影響度の合計の1パーセント分を足す形で計算されるので、影響度の合計が35なら係数は1.00、45なら1.10になる。
例題：あるチームの過去の実績では、ソフトウェア規模が2倍になると工数はおよそ2.07倍になっていた。この関係が意味することは何か。
答えと考え方 工数が規模に単純比例せず、規模の1より大きいべき乗に比例していることを意味する。指数を1.05とすると、2の1.05乗が約2.07になり実績と合う。規模が大きくなるほど、要員間の連絡、仕様のすり合わせ、統合作業といった調整の手間が増えるためで、COCOMOの式もこの形をとる。ここから導かれる実務上の判断が二つある。一つは、大きな案件を分割できるなら分割したほうが総工数は小さくなりうること。もう一つは、遅れを人員追加で取り戻そうとすると伝達コストが増えてかえって遅れる、というブルックスの法則である。
出典・根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
確認問題（45問） 四肢択一。「正解と解説」を開くと、正解の理由と他の選択肢が違う理由を確認できます。
問1｜WFの適用
ウォーターフォールモデルが適している案件の特徴として最も適切なものはどれか。
利用部門も何が受け入れられるか読み切れておらず、作りながら方針を決めたい 採用する新技術が使い物になるかを、早い段階で試して見極める必要がある 利用者の反応を見ながら、優先順位を毎週入れ替えていきたい 法令対応のように作るべき機能と期限が外部の取決めで確定しており、要件が安定している 正解と解説 正解：D. 法令対応のように作るべき機能と期限が外部の取決めで確定しており、要件が安定している ウォーターフォールモデルは、工程を順に進め、前工程の完了を承認してから次に進む方式である。工程ごとに成果物と承認があるため進捗管理と分担がしやすい反面、後工程で要件の誤りが判明したときの手戻りが大きい。したがって、要件が安定していて作るものが確定している案件に向く。要件が読み切れない案件、技術リスクを早期に見極めたい案件、優先順位を頻繁に入れ替える案件は、それぞれプロトタイピング、スパイラル、アジャイルのほうが適する。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問2｜プロトタイプ
プロトタイピングモデルを採用する主な狙いはどれか。
試作品をそのまま本番システムとして使い、開発工数を半分に減らす 早い段階で試作品を利用者に見せ、言葉では詰めきれない認識のずれを解消してから作り込む 要件をすべて確定させてから作り始めることで、手戻りを完全になくす 設計書の作成を省略し、テスト工程だけで品質を確保する 正解と解説 正解：B. 早い段階で試作品を利用者に見せ、言葉では詰めきれない認識のずれを解消してから作り込む プロトタイピングモデルは、画面や操作感のように文章では合意しにくい部分について、動くものを早く見せて認識を合わせる方式である。試作品は合意を得るための手段であり、そのまま本番に使う前提ではない点、そして作り捨てになる工数がかかる点が注意事項になる。要件を完全に確定させてから作るのはウォーターフォールの考え方であり、設計書の省略はプロトタイピングとは関係がない。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問3｜スパイラル
スパイラルモデルの特徴として適切なものはどれか。
要件定義から順に全工程を1回だけ実施し、各工程の終了時に承認を得てから次の工程へ進む 早い段階で利用者に試作品を見せて意見を聞き、それをもとに一度だけ作り直してから本開発に移る 固定長の反復ごとに、完成の定義を満たす成果物を必ず本番へ反映し、続いて次の反復の計画をあらためて立て直す システムを部分に分け、それぞれについて設計・実装・評価を繰り返し、リスクの大きいところから解決していく 正解と解説 正解：D. システムを部分に分け、それぞれについて設計・実装・評価を繰り返し、リスクの大きいところから解決していく スパイラルモデルは、開発対象を分割し、各部分について設計・実装・評価のサイクルを繰り返しながら、リスクの大きい部分から先に片付けていく方式である。技術的な不確実性が高い案件で、早い段階に見極めをつけられる点が利点になる。全工程を一度だけ順に行うのはウォーターフォール、試作品で認識を合わせるのはプロトタイピング、固定長の反復で成果物を作るのはスクラムの説明である。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問4｜スクラム
スクラムにおけるスクラムマスターの役割として適切なものはどれか。
何を作るかの優先順位を決め、プロダクトバックログの並び順に責任をもつ 開発者に作業を割り当て、日々の進捗を管理して指示を出す 完成した成果物を検収し、契約上の合否を判定する 進め方が機能するよう支援し、チームの障害を取り除く 正解と解説 正解：D. 進め方が機能するよう支援し、チームの障害を取り除く スクラムマスターは、スクラムの進め方がうまく働くように支援し、チームの妨げになっているものを取り除く役割である。作業を割り当てて指示を出す管理者ではない点が、繰り返し問われる。何を作るかの優先順位に責任をもつのはプロダクトオーナー、どう作るかを決めて作業を進めるのは開発者自身であり、成果物の検収は発注側が契約に基づいて行うことである。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問5｜スプリント
スクラムのスプリントの扱いに関する記述のうち、適切なものはどれか。
作業が終わらない場合は、期間を延長して予定した項目をすべて完了させる スプリントは固定長の期間であり、期間中にスプリントゴールを差し替えることはしない スプリントごとに期間の長さを変え、対象の項目の量に合わせるのが原則である スプリントの終了時点では、動作する成果物ではなく設計書を提出すればよい 正解と解説 正解：B. スプリントは固定長の期間であり、期間中にスプリントゴールを差し替えることはしない スプリントは固定長の反復期間で、期間中に目標を差し替えないことがリズムと予測可能性を生む。終わらない項目があれば、期間を延ばすのではなく、その項目をプロダクトバックログへ戻して次回以降に回す。期間の長さを毎回変えると実績からの予測が働かなくなる。また、スプリントの成果は完成の定義を満たす動くインクリメントであり、設計書だけでは要件を満たさない。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問6｜ベロシティ
アジャイル開発でストーリポイントとベロシティを使う目的として最も適切なものはどれか。
作業を絶対時間で見積もることで、担当者ごとの生産性を比較して評価する 作業量を相対的な大きさで表し、反復ごとの完了実績を記録して、次回以降にこなせる量を予測する 残っている作業の総量を金額に換算し、契約金額の変更根拠として使う 反復ごとに作業量の目標値を引き上げ、チームの負荷を意図的に高める 正解と解説 正解：B. 作業量を相対的な大きさで表し、反復ごとの完了実績を記録して、次回以降にこなせる量を予測する ストーリポイントは、作業量を時間ではなく相対的な大きさで表した値である。人によって作業速度が違っても相対的な大きさなら合意しやすく、それを反復ごとに合計した実績がベロシティとなって、次回以降の予測に使える。担当者の評価に使うと、見積もりを大きく申告する誘因が働いて数字が壊れるので避ける。金額換算のための指標でもなく、目標値を吊り上げる道具でもない。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問7｜CI
継続的インテグレーション（CI）の説明として適切なものはどれか。
すべての開発が完了してから、一度だけまとめてビルドとテストを実行する 検査に通った変更を、人の判断を挟まずに自動で本番環境へ反映する サーバの構成をコードで定義し、同じ環境を何度でも再現できるようにする 変更を頻繁に共通のリポジトリへ統合し、そのたびに自動でビルドとテストを実行して、壊れたことを早く知る 正解と解説 正解：D. 変更を頻繁に共通のリポジトリへ統合し、そのたびに自動でビルドとテストを実行して、壊れたことを早く知る 継続的インテグレーションは、変更を小さく頻繁に統合し、そのたびに自動でビルドとテストを走らせることで、壊れた箇所を早く小さいうちに見つける実践である。まとめて統合すると原因の切り分けが難しくなるので、これとは逆の発想になる。検査に通った変更を自動で本番へ反映するのは継続的デプロイメント、構成をコードで定義するのはInfrastructure as Codeであり、いずれも別の実践である。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問8｜CDの違い
継続的デリバリと継続的デプロイメントの違いの説明として適切なものはどれか。
継続的デリバリは自動で本番へ反映することを指し、継続的デプロイメントはリリース可能な状態を保つことを指す どちらも同じ意味であり、呼び名が違うだけで実践の内容に違いはない 継続的デリバリはいつでもリリースできる状態を保つことを指し、継続的デプロイメントは検査に通った変更を自動で本番へ反映することを指す 継続的デリバリは開発環境、継続的デプロイメントはテスト環境に限って適用される 正解と解説 正解：C. 継続的デリバリはいつでもリリースできる状態を保つことを指し、継続的デプロイメントは検査に通った変更を自動で本番へ反映することを指す 両者の違いは、本番への反映に人の判断を挟むかどうかにある。継続的デリバリは、いつリリースを決めても実行できる状態を常に保つところまでを自動化し、実際にリリースするかどうかは人が判断する。継続的デプロイメントは、自動の検査に通った変更をそのまま本番へ反映する。説明を入れ替えた記述、同一視する記述、対象環境で区別する記述はいずれも誤りである。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問9｜非機能要件
要件定義で整理した次の項目のうち、非機能要件に当たるものはどれか。
利用者が入力した住所から郵便番号を自動で補完すること 同時利用者が100人の状態で、検索画面の応答時間を2秒以内とすること 月末に締め処理を実行して請求データを作成すること 承認者が申請内容を確認して差し戻せるようにすること 正解と解説 正解：B. 同時利用者が100人の状態で、検索画面の応答時間を2秒以内とすること 非機能要件は、システムが何をするかではなく、どのくらいの品質で提供するかを定めるものである。可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境といった区分があり、応答時間の目標は性能に関する非機能要件にあたる。郵便番号の自動補完、締め処理による請求データの作成、承認と差戻しは、いずれもシステムが行う処理そのものを述べており、機能要件である。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問10｜検証可能性
要件定義の成果物に「操作しやすい画面であること」と記述されていた。この記述の問題点として最も適切なものはどれか。
何をもって満たしたと判定するかが決められないため、検証可能でないこと 機能要件として書くべき内容を、非機能要件として書いていること 利用者の要望をそのまま記述しており、開発側の意見が入っていないこと 対象となる画面の数を明示していないため、工数を見積もれないこと 正解と解説 正解：A. 何をもって満たしたと判定するかが決められないため、検証可能でないこと よい要件が満たすべき性質は、検証可能であること、読む人によって解釈が変わらないこと、実現可能であること、要求元までたどれることである。「操作しやすい」は水準が人によって異なり、完成後に満たしたかどうかを誰も判定できないので、検証可能性を欠く。直すには、たとえば「主要な3つの業務について、初めての利用者が説明なしで5分以内に完了できる」のように、測れる形にする。分類の誤りや工数の話は、この記述の主たる問題ではない。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問11｜追跡可能性
要件のトレーサビリティを確保しておくことの利点として最も適切なものはどれか。
ある要件が変更されたとき、影響を受ける設計、実装、テストケースを特定できる 要件の総数が把握できるため、開発の総工数を正確に算出できる 要件の記述が自動的に検証可能な形式に書き換えられる 要件の変更そのものを禁止でき、仕様の凍結を確実にできる 正解と解説 正解：A. ある要件が変更されたとき、影響を受ける設計、実装、テストケースを特定できる トレーサビリティは、ある要件がどの要求から来て、どの設計・実装・テストケースに対応しているかをたどれるようにしておくことである。要件は必ず変わるので、変更が及ぶ範囲を短時間で特定できることが最大の利点になる。テストの抜け漏れの点検にも使える。要件の数が分かっても工数が正確に出るわけではなく、記述の質が自動的に上がるわけでもない。変更を禁止するための仕組みでもなく、むしろ変更を安全に扱うための仕組みである。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問12｜外部設計
外部設計で行う作業として適切なものはどれか。
処理をモジュールに分割し、モジュール間の引数の受渡し方を決める 表の物理的な格納方法や索引の張り方を決める 画面の項目配置や帳票の様式、外部システムとやり取りするデータの形式を決める 各モジュール内部の処理手順を擬似言語で詳細に記述する 正解と解説 正解：C. 画面の項目配置や帳票の様式、外部システムとやり取りするデータの形式を決める 外部設計は、利用者やほかのシステムから見える面を決める工程で、画面、帳票、外部インタフェース、コード体系、論理データ構造などが対象になる。モジュールへの分割とその間のインタフェース、物理データ構造、処理の詳細は、いずれも内側の作りを決める内部設計の作業である。境目は「利用者から見えるかどうか」で判断するとよい。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問13｜DFD
DFDで用いる構成要素の組合せとして適切なものはどれか。
クラス、属性、操作、関連 データフロー、プロセス、データストア、外部実体 状態、遷移、事象、動作 エンティティ、リレーションシップ、属性、多重度 正解と解説 正解：B. データフロー、プロセス、データストア、外部実体 DFDは、データの流れ（データフロー）、処理（プロセス）、データの蓄積場所（データストア）、システムの外側にある発生元や行き先（外部実体）の四つで、業務やシステムを表す図である。クラスや属性、操作、関連はクラス図の構成要素、状態と遷移と事象は状態遷移図の構成要素、エンティティとリレーションシップはE-R図の構成要素であり、それぞれ表すものが異なる。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問14｜結合度
モジュール間の結合度が最も弱く、望ましいとされるものはどれか。
スタンプ結合 共通結合 内容結合 データ結合 正解と解説 正解：D. データ結合 結合度は弱いほど望ましく、弱い順にデータ結合、スタンプ結合、制御結合、外部結合、共通結合、内容結合となる。データ結合は、必要なデータ項目だけを引数として受け渡すもので、相手の内部構造に依存しないため変更に強い。スタンプ結合はデータ構造全体を渡して一部だけ使う形、共通結合は共通領域のデータを複数のモジュールが参照する形、内容結合は相手の内部を直接参照したり途中へ飛び込んだりする最も強い結合である。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問15｜制御結合
次の擬似言語における、出力処理 から 帳票出力 への呼出しは、どの結合に当たるか。
渡している値は、データか、動作の指示か
○出力処理() 帳票出力(1, 受注) /* 1 は請求書を表す */ 帳票出力(2, 受注) /* 2 は納品書を表す */ ○帳票出力(整数型: 区分, 受注型: 受注) if (区分 = 1) 請求書を印字する(受注) elseif (区分 = 2) 納品書を印字する(受注) else 領収書を印字する(受注) endif データ結合 スタンプ結合 制御結合 外部結合 正解と解説 正解：C. 制御結合 渡している 1 や 2 は帳票の中身ではなく、相手のどの枝を実行させるかを指示する制御用の値なので、制御結合である。呼出し元は 帳票出力 の内部にどんな分岐があるかを知っていなければ正しい値を渡せず、分岐を1本増やすと呼出し元も直すことになる。データ結合は受注のように必要なデータ項目だけを渡す形、スタンプ結合はデータ構造全体を渡して相手が一部だけ使う形、外部結合は外部宣言した個々のデータを共有する形である。帳票の種類ごとにモジュールを分ければ、この呼出しはデータ結合になる。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問16｜共通結合
共通領域に置いたデータを複数のモジュールが参照・更新している設計の問題点として最も適切なものはどれか。
どのモジュールがいつデータを書き換えたかを追いにくく、1か所の変更が広い範囲に波及する データを渡すたびに複写が発生するため、実行時のメモリ使用量が必ず増える モジュールの数が増えるほど、呼出しの引数の個数が自動的に増える モジュールごとに異なるプログラム言語を使えなくなる 正解と解説 正解：A. どのモジュールがいつデータを書き換えたかを追いにくく、1か所の変更が広い範囲に波及する 共通結合は、共通領域のデータを複数のモジュールが参照・更新する結合で、結合度は強い側にある。問題は、そのデータを誰がいつ書き換えたかを追いにくく、影響範囲が広がることである。ある不具合の原因を突き止めるのに、共通領域を触るすべてのモジュールを調べることになる。メモリ使用量の増加や引数の個数、使用言語の制約は、共通結合の本質的な問題ではない。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問17｜凝集度
モジュールの凝集度が最も強く、望ましいとされるものはどれか。
論理的凝集 時間的凝集 機能的凝集 手順的凝集 正解と解説 正解：C. 機能的凝集 凝集度は強いほど望ましく、弱い順に暗合的凝集、論理的凝集、時間的凝集、手順的凝集、連絡的凝集、情報的凝集、機能的凝集となる。機能的凝集は単一の機能だけを実現している状態で、再利用しやすく変更の影響も閉じ込めやすい。論理的凝集は似た処理をまとめて引数で選ばせる弱い形、時間的凝集は初期化処理のように同じ時期に実行するものをまとめた形、手順的凝集は順に実行する処理をまとめた形である。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問18｜論理的凝集
「帳票出力」というモジュールが、引数で渡された種別に応じて請求書、納品書、領収書のいずれかを出力している。このモジュールの凝集度と、改善の方向として適切な組合せはどれか。
機能的凝集であり、すでに望ましい状態なので改善は不要である 時間的凝集であり、実行するタイミングごとにモジュールをまとめ直す 情報的凝集であり、扱うデータ構造ごとにモジュールを統合する 論理的凝集であり、帳票の種類ごとにモジュールを分けて機能的凝集に近づける 正解と解説 正解：D. 論理的凝集であり、帳票の種類ごとにモジュールを分けて機能的凝集に近づける 似た種類の処理をひとまとめにし、引数で実行する処理を選ばせている状態は論理的凝集である。モジュールの中に関係の薄い処理が同居しているため、片方の修正が他方を壊しやすく、呼出し元との間も制御結合になってしまう。帳票の種類ごとにモジュールを分ければ、それぞれが単一の機能だけを実現する機能的凝集に近づき、呼出し元も必要なデータ項目だけを渡すデータ結合にできる。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問19｜UMLの図
次の図は、UMLのある図をアスキー文字で表したものである。当てはまる図はどれか。
縦線は生存線、横向きの矢印はメッセージ
:利用者 :予約画面 :予約管理 :在庫DB | 申し込む | | | |------------->| | | | | 予約する | | | |-------------->| | | | | 在庫を問う | | | |-------------->| | | | 残数 3 | | | |<--------------| | | 受付番号 | | | |<--------------| | | 完了を表示 | | | |<-------------| | | | | | | シーケンス図 クラス図 ユースケース図 配置図 正解と解説 正解：A. シーケンス図 縦の生存線に沿って、オブジェクトの間のメッセージを上から下へ時間順に並べたものがシーケンス図である。図では利用者の申込みが予約画面、予約管理、在庫DBへと伝わり、残数の返答が戻って受付番号が返るまでの往復が読み取れる。クラス図はクラスと属性・操作・関連を表す構造図で時間の流れは表せず、ユースケース図は利用者から見た機能のまとまりと利用関係、配置図はノードへの成果物の配置を表す図である。同じやり取りを別の書き方で表すふるまい図としては、コミュニケーション図もある。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問20｜状態マシン図
注文の状態遷移を次の図のように定めた。ある注文が 受注登録、引当完了、出荷完了、取消要求 の順に事象を受け取ったとき、最後の状態はどれか。
図に描かれていない遷移は起こらない
(開始) | 受注登録 v +--------+ +------------+ +--------+ | 受付済 | 引当完了 | 出荷準備中 | 出荷完了 | 出荷済 | +--------+--------> +------------+--------> +--------+ | | | 取消要求 | 取消要求 v v +------+ | | 取消 | <--------------+ +------+ (取消 は終了状態。出荷済 に 取消要求 の遷移は無い) 受付済 出荷準備中 出荷済 取消 正解と解説 正解：C. 出荷済 受注登録で受付済になり、引当完了で出荷準備中へ、出荷完了で出荷済へ移る。出荷済からは 取消要求 に対する遷移が図に無いので、この事象は受け付けられず状態は変わらない。したがって最後の状態は出荷済である。取消になるのは、受付済または出荷準備中の間に取消要求を受けた場合だけで、いったん出荷済になってからの取り消しは、返品という別の遷移として設計し直す必要がある。状態と事象の対応表を作ると、こうした抜けを機械的に洗い出せる。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問21｜開放閉鎖
支払方法が今後も増える見込みのシステムを、次のクラス図のように設計した。呼出し側に支払方法ごとの条件分岐を並べる代わりにこの形を採る理由として、適切なものはどれか。
呼出し側はインタフェースだけを知る
+-----------------+ +---------------+ | 注文確定処理 | 利用 | <<interface>> | +-----------------+ -----> | 支払方法 | | +確定する(注文) | +---------------+ +-----------------+ | +支払う(金額) | +---------------+ /_\ | +------------------+-----------------+ | | | +----------------+ +------------+ +----------+ | クレジット払い | | コード決済 | | 銀行振込 | +----------------+ +------------+ +----------+ 呼出し側の条件分岐が減ることで、実行時の処理速度が必ず向上するから 支払方法の追加をクラスの追加だけで行え、呼出し側の既存コードを修正せずに済むから インタフェースを導入すると、クラスの数が減って保守の対象が少なくなるから 多相性を使えば、実装クラスごとのテストケースを作らなくても正しさが保証されるから 正解と解説 正解：B. 支払方法の追加をクラスの追加だけで行え、呼出し側の既存コードを修正せずに済むから 機能の追加に対しては開いていて、既存コードの修正に対しては閉じている構造を目指す考え方を開放閉鎖の原則という。注文確定処理は 支払方法 というインタフェースしか知らないので、電子マネー払いを足すときは実装クラスを1つ追加するだけで済み、呼出し側は手を入れなくてよい。これが多相性の活用で、デザインパターンでいえばStrategyに当たる。呼出しは仮想的な解決を挟むぶん速くなるとは限らず、クラスの数はむしろ増える。新しい実装クラスにはその都度テストが要る。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問22｜パターン
在庫が入荷したときに、あらかじめ登録しておいた複数の相手へ自動的に通知したい。次のクラス図が表しているデザインパターンはどれか。
通知する側は、受け手の具体的な種類を知らない
+-------------------+ +-------------------+ | 在庫管理 | | <<interface>> | +-------------------+ 通知先 0..* | 通知先 | | +登録する(通知先) | ----------> +-------------------+ | +解除する(通知先) | | +更新された(商品) | | +入荷する(商品) | +-------------------+ +-------------------+ /_\ | +--------------------+ | | +------------+ +----------+ | メール送信 | | 画面表示 | +------------+ +----------+ /* 入荷する() の中で、登録済みの通知先すべてに 更新された(商品) を呼び出す */ Singleton Adapter Observer Factory Method 正解と解説 正解：C. Observer Observerは、監視される側の状態が変わったときに、登録された監視者へ通知を送るふるまいに関するパターンである。図の在庫管理は通知先インタフェースしか知らないので、受け手をメール送信や画面表示のように後から増やせる。登録する・解除する・入荷したら全員に知らせる、という三つの操作がそろっている点が目印になる。Singletonはインスタンスを一つに限る生成に関するパターン、Adapterは既存のインタフェースを別の形に合わせる構造に関するパターン、Factory Methodは生成するクラスの決定を下位に委ねる生成に関するパターンである。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問23｜静的解析
次の擬似言語について、プログラムを実行せずにソースコードを解析することで指摘できる不具合はどれか。
停止条件はどの入力を受け止めるか
○整数型: 階乗(整数型: n) if (n = 1) return 1 endif return n × 階乗(n − 1) n が 0 以下のとき停止条件に達せず、呼出しが終わらない n が 1 のときに限り、戻り値が 0 になってしまう n が 2 以上のとき、戻り値が常に 1 だけ小さくなる n が 3 のとき、再帰の深さが 4 段になってしまう 正解と解説 正解：A. n が 0 以下のとき停止条件に達せず、呼出しが終わらない 停止条件が n = 1 だけなので、0 や負の値を渡すと n は 0, -1, -2 と減り続け、決して 1 に一致せず呼出しが止まらない。値の範囲と停止条件の対応が取れていないことは、実行しなくてもコードを読むだけで分かる典型的な指摘であり、これが静的解析の役割である。停止条件を n ≦ 1 にするか、n が 1 未満なら誤りとして返す形にすれば直る。n が 1 なら 1、2 なら 2、3 なら 6 と正しい値が返り、n が 3 のときの再帰の深さは 3 段なので、他の記述は当たらない。実際にデータを与えて動かして確かめるのは動的解析であり、静的解析と補い合う関係にある。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問24｜レビュー
設計段階でレビューを重点的に行うことが費用対効果の面で有利とされる理由はどれか。
設計段階の欠陥は、テスト工程では原理的に検出できないため 欠陥は発見が遅い工程ほど修正費用が大きくなるため、上流で見つけるほど総費用を抑えられる レビューはテストより短時間で終わるため、工程全体の期間を必ず短縮できるため レビューで見つけた欠陥は記録する必要がなく、管理の手間がかからないため 正解と解説 正解：B. 欠陥は発見が遅い工程ほど修正費用が大きくなるため、上流で見つけるほど総費用を抑えられる 欠陥は、作り込んだ工程から離れるほど修正費用が膨らむ。設計の誤りが実装とテストを経て運用で見つかれば、設計書、コード、テストケース、場合によっては本番データまで直すことになる。だから上流での検出は費用対効果が高い。設計の欠陥がテストで検出できないわけではなく、レビューが常に短時間で済むわけでもない。レビューで見つけた欠陥も記録して集計し、どの工程の検証が弱いかを見る材料にする。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問25｜網羅の最小
次の擬似言語について、命令網羅と判定条件網羅（分岐網羅）をそれぞれ満たすために必要な、最小のテストケース数の組合せはどれか。
if は二つ、いずれも else の側に処理が無い
○整数型: 集計(整数型: x, 整数型: y) 整数型: n ← 0 if (x > 0) n ← n + 1 /* 処理P */ endif if (y > 0) n ← n + 2 /* 処理Q */ endif return n 命令網羅は2件、判定条件網羅は2件 命令網羅は1件、判定条件網羅は4件 命令網羅は2件、判定条件網羅は4件 命令網羅は1件、判定条件網羅は2件 正解と解説 正解：D. 命令網羅は1件、判定条件網羅は2件 命令網羅はすべての命令を1回以上実行すればよい。x も y も正の値、たとえば (1, 1) の1件で処理Pと処理Qの両方を通れるので1件で足りる。判定条件網羅は各判定について真と偽の両方を通す必要があるので、(1, 1) に加えて (0, 0) の1件を用意すれば、二つの判定それぞれで真と偽がそろい2件で足りる。この二つは同じテストケースの中で別々の判定に割り当ててよいので、判定の数だけケースが要るわけではない。4件が必要になるのは、二つの条件の真偽の全組合せを通す複数条件網羅の場合である。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問26｜条件網羅
次の擬似言語に対し、テストケースを (a, b) が (10, 1) の1件と (5, 0) の1件の合計2件だけ用意した。このとき満たされる網羅基準はどれか。
個々の条件と、判定全体を分けて見る
○文字列型: 受付判定(整数型: a, 整数型: b) if (a ≧ 10 and b = 0) return "受理" endif return "却下" 条件網羅も判定条件網羅も、ともに満たす 判定条件網羅は満たすが、条件網羅は満たさない 条件網羅は満たすが、判定条件網羅は満たさない 条件網羅も判定条件網羅も、ともに満たさない 正解と解説 正解：C. 条件網羅は満たすが、判定条件網羅は満たさない 1件目では a ≧ 10 が真、b = 0 が偽、2件目ではその逆になるので、個々の条件はどちらも真と偽の両方をとっており、条件網羅は満たされる。しかし論理積で結んだ判定全体の結果は、1件目も2件目も偽で、戻り値はどちらも 却下 である。判定が真になる場合を一度も通っていないので、判定条件網羅は満たさない。条件網羅は判定条件網羅を包含しない、という点がこの問題の要点である。(10, 0) と (5, 1) の2件にすれば、戻り値が 受理 と 却下 の両方になり、条件網羅と判定条件網羅の両方を満たせる。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問27｜網羅の強さ
ホワイトボックステストの網羅基準について、弱いものから強いものへ並べた順序として適切なものはどれか。
判定条件網羅、命令網羅、複数条件網羅 命令網羅、判定条件網羅、複数条件網羅 複数条件網羅、判定条件網羅、命令網羅 命令網羅、複数条件網羅、判定条件網羅 正解と解説 正解：B. 命令網羅、判定条件網羅、複数条件網羅 命令網羅はすべての命令を1回以上実行することだけを求めるため最も弱く、判定の偽の側を一度も通らないことがありうる。判定条件網羅はすべての判定について真と偽の両方を通すので命令網羅より強い。複数条件網羅は判定の中の個々の条件の真偽のすべての組合せを通すので最も強いが、条件の数が増えるとテストケース数が急増するため、実務では対象を絞って適用する。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問28｜同値分割
同値分割によるテストケースの設計の説明として適切なものはどれか。
入力として指定できるすべての値を、1つずつ漏れなく試す プログラムの内部構造を調べ、実行されていない命令が残らないように値を選ぶ 入力を同じ結果になるはずのグループに分け、有効なグループと無効なグループのそれぞれから代表値を選ぶ グループの境目に当たる値と、その隣の値だけを選ぶ 正解と解説 正解：C. 入力を同じ結果になるはずのグループに分け、有効なグループと無効なグループのそれぞれから代表値を選ぶ 同値分割は、入力の集合を「同じ結果になるはず」のグループに分け、各グループから代表値を1つ選ぶブラックボックステストの技法である。有効な値のグループだけでなく、無効な値のグループからも選ぶことが要点になる。すべての値を試すのは全数テストで現実的でなく、内部構造から値を選ぶのはホワイトボックステストの考え方、境目とその隣の値を選ぶのは境界値分析である。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問29｜境界値
次の擬似言語について、上限と下限のそれぞれで、有効となる境目の値と、無効となるその隣の値の両方を確かめたい。テストデータの組合せとして最も適切なものはどれか。
1以上100以下だけを有効とする入力欄
○文字列型: 検査(整数型: n) if (n ≧ 1 and n ≦ 100) return "有効" endif return "無効" 1、50、100 0、50、101 1、2、99、100 0、1、100、101 正解と解説 正解：D. 0、1、100、101 境界値分析では、有効なグループと無効なグループの境目の値と、その隣の値を選ぶ。境目は1と100の2か所なので、0、1、100、101 の4点を取ると、戻り値は順に 無効、有効、有効、無効 となり、両側の切り替わりを確かめられる。1、50、100 はすべて 有効 しか返さず、無効側との境目を越えない。1、2、99、100 も同じくすべて 有効 で、不等号を ≦ 101 のように書き間違えても気付けない。0、50、101 は 無効、有効、無効 となるが、有効となる境目の 1 と 100 を通らないので、境目が1つずれる誤りを見つけられない。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問30｜スタブ
結合テストにおけるスタブとドライバの説明として適切なものはどれか。
スタブは呼び出される側の代わりに用意する仮のモジュールで、トップダウンテストで使う スタブは呼び出す側の代わりに用意する仮のモジュールで、ボトムアップテストで使う ドライバは呼び出される側の代わりに用意する仮のモジュールで、トップダウンテストで使う スタブもドライバも、本番環境での性能測定のために用意する監視用のモジュールである 正解と解説 正解：A. スタブは呼び出される側の代わりに用意する仮のモジュールで、トップダウンテストで使う トップダウンテストは上位のモジュールから順に組み上げるので、まだ完成していない下位の代わりが要る。これがスタブで、決まった値を返すだけの仮のモジュールである。ボトムアップテストは下位から組み上げるので、まだ完成していない上位の代わりとして、対象を呼び出して結果を確かめるドライバを用意する。この対応を入れ替えた記述は誤りで、どちらも性能測定のための仕組みではない。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問31｜回帰テスト
回帰テストを行う目的として適切なものはどれか。
変更した箇所が仕様どおりに動くことだけを確かめる 本番稼働後の利用状況から、次に追加すべき機能を洗い出す 変更を加えた箇所以外の機能が、その変更によって壊れていないことを確かめる 利用者が実際の業務の流れでシステムを使えるかを確かめる 正解と解説 正解：C. 変更を加えた箇所以外の機能が、その変更によって壊れていないことを確かめる 回帰テストは、変更によって既存の機能が壊れていないことを確かめるテストである。修正のたびに繰り返し実行されるため、自動化の効果が最も大きい領域で、継続的インテグレーションの土台にもなる。変更箇所そのものが仕様どおり動くかを確かめるのは確認テストの役割であり、次の機能の洗い出しや業務の流れでの確認は、それぞれ企画や受入テストの活動である。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問32｜バグ密度
規模が25キロステップのプログラムについて、単体テストで100件の欠陥を検出した。バグ密度は1キロステップあたり何件か。
0.25件 0.004件 250件 4.0件 正解と解説 正解：D. 4.0件 バグ密度は、検出した欠陥数を規模で割って求める。100件を25キロステップで割って4.0件となる。0.25件は25を100で割ったもの、0.004件は100をステップ数25000で割ってキロステップへの換算を忘れたもの、250件は25000を100で割ったものであり、いずれも計算の向きか単位を取り違えている。求めた密度は、計画時に定めた目標値と比べて、テストの十分さや品質の状態を判断する材料にする。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問33｜密度の解釈
結合テストの結果、バグ密度が計画値を大きく下回った。この結果の解釈として最も適切なものはどれか。
バグ密度が低いので、品質が高いと結論してよい 品質が高い可能性と、テストが十分に行われていない可能性の両方があるため、テスト密度や網羅率と併せて判断する バグ密度が低いので、次の工程へは進まず、欠陥が計画値に達するまでテストを続ける バグ密度は規模に依存する指標なので、品質の判断には使えない 正解と解説 正解：B. 品質が高い可能性と、テストが十分に行われていない可能性の両方があるため、テスト密度や網羅率と併せて判断する バグ密度が低いという事実だけでは、実際に欠陥が少ないのか、テストが浅くて見つけられていないのかを区別できない。テスト密度が計画どおりで網羅率も十分ならば品質が高いという解釈が有力になり、テスト密度も低ければテスト不足の疑いが濃くなる。数字を1つだけ見て結論を出さないのが要点である。欠陥件数を計画値に合わせること自体を目的にするのは本末転倒であり、バグ密度は規模で割ることで規模の違いを吸収した比較可能な指標になっている。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問34｜成長曲線
信頼度成長曲線の使い方に関する記述のうち、適切なものはどれか。
累積欠陥検出数の伸びが緩やかになったことをテスト終了の材料にするが、網羅率や未実施のテストケース数と併せて判断する 曲線が寝てきたら、テストの内容に偏りがないかを確かめるまでもなく、それだけで欠陥が出尽くしたと判断してテストを終えてよい 曲線が直線に近い形になるほど、単位時間あたりの検出数が一定でテストが順調に進んでいることを表す 曲線は投入した開発工数の累積を表すので、テストの進み具合ではなく要員計画の見直しに使う 正解と解説 正解：A. 累積欠陥検出数の伸びが緩やかになったことをテスト終了の材料にするが、網羅率や未実施のテストケース数と併せて判断する 信頼度成長曲線は、テストの経過に対する累積欠陥検出数を描いたS字の曲線で、終盤に伸びが緩やかになる。この寝てきた形はテスト終了を判断する材料になるが、テストの内容が偏って同じ経路ばかり通っている場合にも同じ形になるため、それだけでは根拠にならない。網羅率、未実施のテストケース数、テストの種類の偏りと併せて見る。直線に近い形は欠陥がまだ出続けている状態を示し、この曲線は工数の累積を表すものでもない。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問35｜選択ソート
次の擬似言語に配列 {4, 1, 3, 2} を渡して実行したとき、if による比較の回数と、要素の交換が実際に行われた回数の組合せはどれか。
隣どうしを比べて入れ替える整列
○整数型の配列: 整列(整数型の配列: 配列) 整数型: i, j, 最小位置, 作業 for (i を 1 から 配列の要素数 − 1 まで 1 ずつ増やす) 最小位置 ← i for (j を i + 1 から 配列の要素数 まで 1 ずつ増やす) if (配列[j] < 配列[最小位置]) 最小位置 ← j endif endfor if (最小位置 ≠ i) 作業 ← 配列[i] 配列[i] ← 配列[最小位置] 配列[最小位置] ← 作業 endif endfor return 配列 比較 6回、交換 3回 比較 6回、交換 2回 比較 3回、交換 2回 比較 4回、交換 3回 正解と解説 正解：B. 比較 6回、交換 2回 内側のforは i が1、2、3 のときに 3回、2回、1回まわるので、比較は 3 + 2 + 1 で6回である。これは配列の中身によらず一定で、要素数 n に対して n(n − 1) ÷ 2 になる。交換のほうは1巡ごとに多くても1回で、しかも最小位置が i と同じなら起こらない。{4, 1, 3, 2} では1巡目に 4 と 1 を入れ替えて {1, 4, 3, 2}、2巡目に 4 と 2 を入れ替えて {1, 2, 3, 4} となり、3巡目は最小位置が i と同じなので交換せず、合計2回である。交換3回は最後の巡でも入れ替わると数えた誤り、比較3回は外側のforの回数、比較4回は要素数を答えた誤りである。交換法（隣接交換）は交換が最大で比較と同じ回数まで増えるのに対し、選択ソートは交換が n − 1 回を超えないので、要素の移動が重い場面で選ばれる。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問36｜類推見積
企画段階で、まだ作業を細かく分解できない時期に概算の工数を出したい。適した見積技法はどれか。
ボトムアップ見積法 標準タスク法 類推見積法 実績工数の集計 正解と解説 正解：C. 類推見積法 類推見積法は、過去の似た案件の実績を土台に、規模や難易度の差を補正して見積もる方法で、作業の分解が済んでいない初期の段階でも短時間で概算を出せる。ボトムアップ見積法と標準タスク法は、いずれも作業を細かく分解して積み上げる方法なので、内容が固まるまで使えない。実績工数の集計は終わった作業の記録であり、これから行う作業の見積りにはならない。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問37｜積上げ
ボトムアップ見積法（標準タスク法）の特徴として適切なものはどれか。
規模の数値から統計的な式で工数を算出するため、初期段階から使える 複数の専門家の見積もりを匿名で集めて収束させるため、意見の偏りが出にくい 作業を細かく分解して各作業の工数を積み上げるため精度は高いが、分解できるまで内容が固まっていないと使えない 過去の似た案件の実績を補正して求めるため、短時間で概算を出せる 正解と解説 正解：C. 作業を細かく分解して各作業の工数を積み上げるため精度は高いが、分解できるまで内容が固まっていないと使えない ボトムアップ見積法は、作業をWBSなどで分解し、一つ一つの工数を積み上げる方法である。担当者が自分の作業を見積もるので納得も得やすく精度は高いが、分解できる程度まで内容が固まっている必要があり、分解そのものに手間もかかる。統計的な式で算出するのはパラメトリック見積法、専門家の意見を匿名で収束させるのはデルファイ法、過去の実績を補正するのは類推見積法である。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問38｜FPの計算
ファンクションポイント法で機能を数えたところ、内部論理ファイルが3件、外部インタフェースファイルが2件、外部入力が6件、外部出力が4件、外部照会が5件であった。重みをそれぞれ10、7、4、5、4とするとき、未調整ファンクションポイントはいくつか。
94 99 20 108 正解と解説 正解：D. 108 件数に重みを掛けて合計する。3×10で30、2×7で14、6×4で24、4×5で20、5×4で20となり、合計は108である。94は外部インタフェースファイルの14を数え忘れた値、99は内部論理ファイルの重みを誤って7として計算した値、20は件数をそのまま足した値であり、いずれも誤りである。実際にはこの後、システム特性による補正係数を掛けて調整済みの値を求める。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問39｜補正係数
未調整ファンクションポイントが120と算出された。システム特性の影響度の合計が50で、補正係数を「0.65に影響度の合計の1パーセント分を加えた値」とするとき、調整済みファンクションポイントはいくつか。
138 120 180 78 正解と解説 正解：A. 138 補正係数は0.65に0.01×50を加えて1.15である。これに未調整の120を掛けて138になる。120は補正係数を1.00とした値で、これは影響度の合計が35のときの結果である。180は係数を1.5と誤ったもの、78は0.65だけを掛けて影響度の加算を忘れたものであり、いずれも誤りである。補正係数は影響度の合計が0のとき0.65、70のとき1.35の範囲に収まる。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問40｜規模と工数
工数が規模の1.05乗に比例するモデルを用いる。規模が3倍になったとき、工数はおよそ何倍になるか。
約3.17倍 約2.07倍 約3.00倍 約9.00倍 正解と解説 正解：A. 約3.17倍 3の1.05乗を計算すると約3.1694なので、およそ3.17倍である。約3.00倍は指数を1.0とみなして単純比例と考えた値、約2.07倍は規模が2倍のときの値、約9.00倍は指数を2と誤った値である。指数が1より大きいのは、規模が大きくなるほど連絡や仕様のすり合わせ、統合作業といった調整の手間が増えるためで、COCOMOもこの形の式を用いる。同じ理屈から、遅れているプロジェクトへの人員追加がかえって遅れを生むというブルックスの法則が導かれる。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問41｜工数の換算
調整済みファンクションポイントが264と見積もられた。過去の実績から、この種の開発の生産性は1人日あたり0.8ファンクションポイントである。必要な工数はおよそ何人日か。
330人日 211人日 132人日 528人日 正解と解説 正解：A. 330人日 工数は、規模を生産性で割って求める。264を0.8で割って330人日である。211人日は264に0.8を掛けてしまった値、132人日は264を2で割った値、528人日は264に2を掛けた値であり、いずれも誤りである。なお、330人日という工数がそのまま期間を表すわけではない点にも注意する。作業には順序の制約があるため、人数で割っただけの期間で終わることはまずない。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問42｜構成管理
ソフトウェア構成管理の対象とすべきものとして、最も適切なものはどれか。
ソースコードだけに限り、文書類は対象としない ソースコードに加え、設計書、テスト仕様書、環境の設定、依存するライブラリの版 本番環境で稼働中のプログラムだけを対象とし、開発中のものは含めない 担当者ごとの作業時間の記録と勤怠の情報 正解と解説 正解：B. ソースコードに加え、設計書、テスト仕様書、環境の設定、依存するライブラリの版 構成管理は、構成品目の識別、変更管理、構成状況の記録、構成監査からなる仕組みである。リリースした版に何が含まれているかを正確に再現できることが目的なので、対象はソースコードだけでなく、設計書、テスト仕様書、ビルド手順、環境の設定、依存するライブラリの版まで広がる。これらが管理されていないと、障害時に「いま何が動いているのか」を特定できない。作業時間や勤怠の記録は、構成管理ではなくプロジェクト管理の領域である。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問43｜ブランチ
複数人がそれぞれブランチを切って長期間作業を続けたところ、本流への統合時に大量の競合が発生した。再発を防ぐ進め方として最も適切なものはどれか。
ブランチを使うのをやめ、全員が本流へ直接、無検査で変更を書き込む 統合の作業を月末にまとめて行い、担当者を1人に固定する 作業単位を小さくし、こまめに本流へ統合して、そのたびに自動でビルドとテストを実行する 競合が起きた箇所は、後から統合した側の変更を機械的に採用する規則にする 正解と解説 正解：C. 作業単位を小さくし、こまめに本流へ統合して、そのたびに自動でビルドとテストを実行する 統合を先送りするほど、同じ箇所への別々の変更が積み上がって競合は大きくなる。したがって、作業単位を小さくし、こまめに本流へ統合し、そのたびに自動でビルドとテストを走らせるのが有効で、これが継続的インテグレーションの発想である。本流へ無検査で直接書き込むのは品質を落とし、統合を月末にまとめるのは問題を悪化させる。競合の内容は業務上の意味を伴うので、機械的にどちらかを採用する規則で解決してはならない。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問44｜保守の分類
OSの版が上がったことに伴い、そのままでは動作しなくなった機能を修正した。この保守はどれに分類されるか。
適応保守 是正保守 予防保守 完全化保守 正解と解説 正解：A. 適応保守 適応保守は、OSの更新、法令の改正、業務の変更といった環境の変化にソフトウェアを合わせるための保守である。是正保守は発生した障害を取り除く保守、予防保守は障害として現れる前に潜在的な欠陥や劣化の予兆へ手を打つ保守、完全化保守は性能や保守性、使いやすさを高めるための保守である。ソフトウェアそのものに欠陥があったわけではなく、外側の環境が変わったことへの対応なので、適応保守にあたる。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
問45｜既存解析
設計書が失われた既存システムについて、稼働中のプログラムを解析して仕様を取り出し、それをもとに新しい技術で作り直すことにした。前半と後半の作業を表す用語の組合せとして適切なものはどれか。
前半がフォワードエンジニアリング、後半がリファクタリング 前半がリファクタリング、後半がリバースエンジニアリング 前半がリエンジニアリング、後半がリバースエンジニアリング 前半がリバースエンジニアリング、後半がフォワードエンジニアリング 正解と解説 正解：D. 前半がリバースエンジニアリング、後半がフォワードエンジニアリング 既存のソフトウェアを解析して設計や仕様を取り出す作業がリバースエンジニアリング、そこで得た仕様をもとに新しいソフトウェアを作成する作業がフォワードエンジニアリングである。両者を合わせて既存資産から新システムを作り直す取組み全体をリエンジニアリングと呼ぶので、後半だけをリエンジニアリングとするのは誤り。リファクタリングは外部から見た動作を変えずに内部構造を整理する作業であり、この記述には当たらない。
根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類4：開発技術
演習：この章の問題を解く ランダム出題の演習ツールです（JavaScript が有効な場合に動きます）。上の「確認問題」はそのままでもすべて読めます。
← 前の章：セキュリティ 次の章：マネジメントと監査 → ※ 解説は学習用の情報提供です。最新の出題範囲・制度は必ずIPAの公式発表をご確認ください。