基本情報技術者 科目A 想定問題集
開発技術の要点整理と想定問題
公式のシラバスの「テクノロジ系 大分類 4：開発技術（中分類 12：システム開発技術、中分類 13：ソフトウェア開発管理技術）」にあたる分野です。まず要点整理で全体をつかみ、下の演習で 33 問を 1 問ずつ解けます。答えると A〜D すべての解説が出ます。
この分野の小項目
- 12-1 要件定義（4 問） システム及び／又はソフトウェアの要件定義のタスク、要件の定義と評価及びレビュー、業務分析や要件定義に用いられる手法のあらましを理解する。
- 12-2 設計（8 問） システム設計とソフトウェア設計のタスク、ソフトウェア品質、ソフトウェア設計手法、モジュールの設計（モジュール結合度など）、部品化と再利用、アーキテクチャパターン、デザインパターン、レビューのあらましを理解する。
- 12-3, 12-4 実装・構築と統合・テスト（6 問） ソフトウェアユニットの作成、コーディング標準、コードレビュー、デバッグ、ユニットのテストと、ソフトウェア及びシステムの統合テスト・検証テストの考え方・手順・手法（ブラックボックステスト・ホワイトボックステストなど）を修得し、適用する。
- 12-5, 12-6 導入・受入れ支援と保守・廃棄（4 問） システム及び／又はソフトウェアの導入と受入れ支援、妥当性確認テストの考え方と手順、保守のタイプ及び形態と手順、廃棄の考え方と手順を理解し、担当する事項に適用する。
- 13-1 開発プロセス・手法（7 問） ソフトウェア開発プロセスに関する代表的な手法（構造化手法・形式手法・オブジェクト指向など）の考え方と、アジャイルの概要とアジャイルソフトウェア開発手法（スクラムなど）の考え方を理解し、担当する事項に適用する。
- 13-2, 13-3, 13-4 知的財産適用管理・開発環境管理・構成管理（4 問） ソフトウェア開発における知的財産権（著作権・特許・ライセンス）の管理と技術的保護、開発環境を管理する必要性と管理対象、構成管理と変更管理のあらましを理解する。
要点整理
要件定義
要件定義は「何を作るか」を利用者と合意する工程
要件定義では、システムの境界を決め、要件を定義し、評価し、取得者（発注者）と供給者（開発側）が共同でレビューします。シラバスは、システム要件定義とソフトウェア要件定義の両方で、この流れを示しています。
要件は大きく、システムが何をするかを定める機能要件と、それ以外の非機能要件に分かれます。応答時間（レスポンスタイム）や処理件数（スループット）などの性能、信頼性、セキュリティ、移行や運用の要件は、非機能要件の側に入ります。
要件を引き出す手法も問われます。利用者へのヒアリング、1 つの目標についての利用者とシステムのやり取りを書くユースケース、画面などの試作品で仕様を確かめるプロトタイプが代表です。プロトタイプは、仕様の漏れや実現の可能性を早めに評価し、手戻りを防ぐ目的で作ります。
業務の分析には、データの流れを表す DFD、データの構造を表すE-R 図、オブジェクト指向の表記法である UML を使います。アジャイルではユーザーストーリーで要件を書くこともあります。
要件定義書を作った後は、要件が上位の要件に合っているか、実現できるかを評価します。このとき大切なのが双方向の追跡可能性（トレーサビリティ）です。トレーサビリティマトリクスで要件と設計・テストの対応を表にしておくと、要件が変わったときに影響する設計書やテスト項目をすぐに洗い出せます。
| 手法 | 何を表す・何に使うか | 試験での見分け方 |
|---|---|---|
| ユースケース | 利用者（アクター）とシステムのやり取り | 「目標を達成するためのやり取り」 |
| プロトタイプ | 画面などの試作品で仕様を確かめる | 「使い勝手を想像できない」「手戻りを防ぐ」 |
| E-R 図 | データの実体と関連 | 「データの構造」 |
| トレーサビリティマトリクス | 要件と設計・テストの対応 | 「変更の影響を洗い出す」 |
設計
設計は品質特性・モジュール分割・オブジェクト指向・レビューを押さえる
ソフトウェアの品質は JIS X 25010 で整理されています。シラバス（Ver.9.2）が示す製品品質モデルは、機能適合性・性能効率性・互換性・使用性・信頼性・セキュリティ・保守性・移植性の 8 特性です。利用時の品質モデルは、有効性・効率性・満足性・リスク回避性・利用状況網羅性の 5 特性です。どちらのモデルの特性かを問う問題に備え、2 つを分けて覚えます。
モジュールの独立性は、モジュールの中の機能のまとまりであるモジュール強度（結束性）と、モジュールどうしの結び付きであるモジュール結合度で評価します。強度は強く、結合度は弱いほど独立性が高くなります。必要なデータだけを引数で渡すデータ結合は結び付きが弱く、処理の流れを切り替えるフラグを渡す制御結合はそれより強い結び付きです。
オブジェクト指向設計では、データと操作をまとめて中身を隠すカプセル化、共通する性質を上位のクラスにまとめる汎化と、その性質を下位のクラスが受け継ぐ継承がよく出ます。全体と部分の関係は集約と呼びます。
UML の図は目的で選びます。クラスの構造はクラス図、利用者とシステムの機能の関係はユースケース図、オブジェクト間のメッセージの時間の順序はシーケンス図、状態の移り変わりはステートマシン図です。
ソフトウェア構造の型であるアーキテクチャパターンの代表はMVC モデルです。データと処理、表示、入力の制御を分けるので、画面だけを差し替えやすくなります。デザインパターンは主にオブジェクト指向設計で使い、生成・構造・振る舞いの 3 種類に分類されます。
レビューの方式も区別できるようにします。ウォークスルーは作成者が説明して意見を集める方式で、作成者が中心になります。インスペクションは進行役（モデレーター）が主催し、役割と手順を厳密に定める最も公式な方式で、作成者は他の役を兼ねません。
| レビュー方式 | 進め方 | 特徴 |
|---|---|---|
| ウォークスルー | 作成者が説明し、参加者が意見を出す | 作成者が司会を兼ねることが多く、答えを得やすい |
| インスペクション | モデレーターが主催し、役割を分けて行う | 最も厳格で公式。作成者は他の役を兼ねない |
| パス・アラウンド | 成果物を複数の人に回し、各自が確認する | 集まらずに多くの人から意見を集められる |
| ペアプログラミング | 2 人が 1 台の PC で一緒に作る | XP の実践で、作りながら確認する |
出典: 基本情報技術者試験（レベル 2）シラバス Ver.9.2（IPA）／応用情報技術者試験（レベル 3）シラバス Ver.7.2（IPA）／高信頼化ソフトウェアのための開発手法ガイドブック（IPA SEC・2010 年）
実装・構築と統合・テスト
テストは技法の選び分けと網羅基準の計算がポイント
テストの技法は、仕様を基にするブラックボックステストと、内部の構造を基にするホワイトボックステストに分かれます。
ブラックボックスの基本は同値分割と限界値分析です。同値分割は、同じ処理になる入力を有効と無効の同値クラスに分け、各クラスから代表値を選びます。限界値分析は、クラスの境目の値とその隣の値を選びます。境目の付近は誤りが起きやすいからです。例えば 1〜99 が有効なら、同値分割では −5・50・150 のように各クラスから 1 つずつ、限界値分析では 0・1・99・100 を選びます。
複数の条件の組合せで結果が変わる仕様には決定表（デシジョンテーブル）を使います。条件の組合せ（ルール）ごとに動作を表にまとめ、組合せの漏れを確かめます。
ホワイトボックスでは網羅基準を使います。命令網羅（C0）はすべての命令を 1 回以上通す基準、判定条件網羅（C1）は各判定の真と偽を 1 回以上通す基準です。判定条件網羅を 100％満たせば、命令網羅も 100％になります。判定が 2 つ順に並ぶ場合、命令網羅は両方を真にする 1 件で足りますが、判定条件網羅には「両方真」と「両方偽」の 2 件が要ります。
モジュールを結合して試すときは、仮のプログラムを使います。上位から結合するトップダウンテストでは、未完成の下位モジュールの代わりにスタブを置きます。下位から結合するボトムアップテストでは、未完成の上位モジュールの代わりにドライバを置きます。
修正の後に、直していない部分に悪い影響が出ていないかを確かめるのが回帰テストです。シラバスは検証テストの種類として、機能テスト・性能テスト・負荷テスト・セキュリティテスト・回帰テストなどを挙げています。
| 技法・基準 | 種類 | テストデータの選び方 |
|---|---|---|
| 同値分割 | ブラックボックス | 各同値クラスから代表値を 1 つずつ |
| 限界値分析 | ブラックボックス | クラスの境目とその隣の値 |
| 決定表 | ブラックボックス | 条件の組合せ（ルール）ごとに |
| 命令網羅 | ホワイトボックス | すべての命令を 1 回以上通す |
| 判定条件網羅 | ホワイトボックス | 各判定の真と偽を 1 回以上通す |
出典: 高信頼化ソフトウェアのための開発手法ガイドブック（IPA SEC・2010 年）／基本情報技術者試験（レベル 2）シラバス Ver.9.2（IPA）
導入・受入れ支援と保守・廃棄
導入・受入れ・保守・廃棄は「誰が主体か」と「手順」で覚える
導入では、実環境への導入や新旧システムの移行をどう行うか、データの保全や業務への影響、スケジュールと体制を導入計画にまとめます。
受入れでは、取得者（発注者）が主体です。供給者の支援を受けながら、受入れ基準に照らして受入れレビューや受入れテストを行い、結果を文書にします。供給者は、教育訓練や利用者マニュアルの提供などで取得者を支えます。
保守では、問題の発生や改善、機能拡張の要求に応じて、既存システムの安全性を保ちながら修正します。同じ障害が続くときは、特性要因分析などで根本原因を探り、類似事故の可能性も検討して、改善やマニュアルの改訂を行います。修正の後には回帰テストを行います。
移行の留意事項として、シラバスは移行計画の文書化と関係者全員への通知、新旧環境の並行運用と旧環境の停止、移行結果の検証、旧環境に関わるデータの保持と安全性の確保を挙げています。
廃棄でも手順があります。廃棄計画を立てて利用者に通知し、必要なら新旧環境を並行運用し、関係者全員に廃棄を知らせます。廃棄に関わるデータは保持し、後から参照できるようにしておきます。
開発プロセス・手法
開発モデルとアジャイル（スクラム・XP）
ウォーターフォールモデルは、要件定義から設計・実装・テストへ工程を順に進めます。要件を最初に固める前提なので、要求があいまいな開発では手戻りが大きくなりやすいです。要求をはっきり言えない場合は、試作品で利用者の評価を受けながら要求を固めるプロトタイピングモデルが向きます。
アジャイルの代表的な手法がスクラムと XP（エクストリームプログラミング）です。スクラムは、スプリントと呼ぶ 1〜4 週間の時間枠を繰り返します。スプリントは、予定の機能が完成しなくても延長しません。スプリントの中では、スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブ（ふりかえり）を行います。
プロダクトバックログは、プロダクトに加える要求の一覧で、プロダクトオーナーが管理して優先順位を付けます。スプリントで行う作業の一覧はスプリントバックログです。
XP の実践には、ペアプログラミング、テスト駆動開発、リファクタリング、継続的インテグレーション、ソースコードの共同所有などがあります。継続的インテグレーションは、変更をこまめに統合して確かめるので、不具合を早く見つけて原因を絞り込みやすくなります。
DevOps は、開発チームと運用チームが連携して素早く柔軟に開発する考え方です。形式手法は、仕様を形式仕様記述言語でルールに従って厳密に書く手法です。組織のプロセスの成熟度を段階で評価するモデルとしては CMMI があります。
| スクラムの役割 | 主な責任 |
|---|---|
| プロダクトオーナー | 何を開発するかを決め、プロダクトバックログを管理する |
| スクラムマスター | スクラムのプロセスを回し、生産性を高めることに責任を持つ |
| 開発者（開発チーム） | スプリントで実際の開発作業を行う |
| ステークホルダ | 利用者や出資者などの利害関係者。スプリントレビューなどで意見を出す |
出典: 基本情報技術者試験（レベル 2）シラバス Ver.9.2（IPA）／アジャイル領域へのスキル変革の指針 アジャイル開発の進め方（IPA・2024 年 5 月）／アジャイル型開発におけるプラクティス活用 リファレンスガイド（IPA・2013 年）
知的財産適用管理・開発環境管理・構成管理
知的財産・開発環境・構成管理
会社の業務で作ったプログラムの著作者が誰かはよく問われます。著作権法 15 条 2 項は、法人の発意に基づいて業務に従事する者が職務上作るプログラムの著作者は、作成時の契約や勤務規則に別段の定めがない限り法人になると定めています。これが職務著作です。プログラムは、法人の名義で公表するかどうかを問いません。
自社が権利を持たないソフトウェアを使うにはライセンスを受け、使用の実態がライセンス契約の範囲を超えないように管理します。シラバスは、インストール数と保有ライセンス数を定期的に照合することを挙げています。
開発環境の管理では、担当者ごとにツールや版が違うと互換性の問題が起きるため、使うツールと版をそろえて管理します。設計データは、版の管理、アクセス権の管理、持出しや改ざんの防止が必要です。
構成管理では、ソフトウェアがどの構成品目の組合せでできているかを識別し、変更の履歴や最新の版を記録します。ソフトウェアを構成する部品の一覧である SBOM を整えておくと、部品に脆弱性が見つかったときに、影響する製品をすぐに特定できます。
リバースエンジニアリングは既存のソフトウェアを解析して仕様を得ることです。その結果を基に権利者の許可なく開発や販売をすると、知的財産権の侵害になる可能性があります。利用許諾契約で禁止されている場合もあります。
出典: 著作権法 第 15 条（e-Gov 法令検索）／基本情報技術者試験（レベル 2）シラバス Ver.9.2（IPA）
演習（33 問）
結果はこのブラウザに保存され、ハブの「自分の成績」と弱点モードに使われます。
第 1 問 / 33 問
問題を読み込んでいます…
全問と解説の一覧
正解と解説は折りたたんであります。先に自分で考えてから開いてください。
全 33 問
要件定義
在庫管理システムの要件をまとめている。次のうち、非機能要件に当たるものはどれか。
A. 商品コードを入れると在庫数を表示する B. 入荷予定の一覧を帳票として出力する C. 画面の応答時間を通常時 2 秒以内にする D. 在庫が基準を下回ったら発注データを作る
この問題へのリンク答えと解説
正解: C 【A（不正解）】 ？ 利用者が使う働きの 1 つを定めています。 システムが何をするかを定めたもので、機能要件に当たる。 【B（不正解）】 ？ 出力する帳票の中身を定めています。 帳票の出力も、システムが提供する働きを定めた機能要件である。 【C（正解）】 ？ どれだけ速く応えるかを定めています。 性能に関する要件で、非機能要件に当たる。シラバスは性能要件の例としてレスポンスタイムを挙げている。 【D（不正解）】 ？ 条件に応じて行う処理を定めています。 業務上の処理を定めたもので、機能要件に当たる。
図書館システムで「利用者が本を予約する」という目標について、利用者とシステムのやり取りを順に定義したい。使う手法はどれか。
A. ユースケース B. E-R 図 C. ガントチャート D. パレート図
この問題へのリンク答えと解説
正解: A 【A（正解）】 ？ アクターと呼ぶ利用者の立場から、システムの使われ方を書く手法です。 ユースケースは、1 つの目標を達成するための利用者とシステムのやり取りを定義するために使う。 【B（不正解）】 ？ データの実体と、その間の関連を表す図です。 データの構造を表す図で、利用者とシステムのやり取りの順序は表さない。 【C（不正解）】 ？ 作業の予定や実績を横棒で表す図です。 日程を管理するための図で、要件の定義には使わない。 【D（不正解）】 ？ 項目を多い順に並べた棒グラフと累積比率の折れ線の図です。 問題の重点を見つけるための図で、やり取りの定義には使わない。
利用者が新しい受付画面の使い勝手を想像できず、要件がなかなか固まらない。後の手戻りを防ぐ進め方として最も適切なものはどれか。
A. 設計に入らず、要件の文書の承認だけを何度も繰り返す B. 先に全機能を作り込み、総合テストで利用者に確認してもらう C. 開発者が経験から画面を決め、利用者の確認は省く D. 画面のプロトタイプを作り、利用者に触ってもらって確かめる
この問題へのリンク答えと解説
正解: D 【A（不正解）】 ？ 文書のやり取りだけで合意を目指す進め方です。 画面を想像できない状況では、文書だけでは仕様の漏れに気付きにくい。 【B（不正解）】 ？ 完成してから確かめる進め方です。 問題が見つかるのが遅く、大きな手戻りになりやすい。 【C（不正解）】 ？ 利用者の意見を聞かない進め方です。 要件の漏れや使いにくさに気付けず、受入れの段階で差し戻されるおそれがある。 【D（正解）】 ？ 試作品を見せて確かめる進め方です。 シラバスは、外部仕様の有効性や漏れを評価して手戻りを防ぐために、モックアップやプロトタイプを作ることがあると説明している。
要件定義の後で、ある要件が変更された。影響する設計書とテスト項目を漏れなく洗い出すため、日頃から整えておくべきものはどれか。
A. 作業時間を記録した日報 B. トレーサビリティマトリクス C. 不具合の原因別のパレート図 D. プログラムの行数の一覧
この問題へのリンク答えと解説
正解: B 【A（不正解）】 ？ 作業者ごとの時間の記録です。 工数の把握には使えるが、要件と設計・テストの対応は分からない。 【B（正解）】 ？ 成果物どうしの対応関係を表にしたものです。 要件・設計・テストの対応を双方向にたどれるので、変わった要件から影響する設計書やテスト項目を洗い出せる。シラバスは要件の評価とレビューで双方向の追跡可能性を挙げている。 【C（不正解）】 ？ 不具合の多い原因を見つける図です。 品質の分析に使う図で、要件の変更が及ぶ範囲は分からない。 【D（不正解）】 ？ ソフトウェアの大きさを測る記録です。 規模の把握には使えるが、どの要件がどの設計に対応するかは分からない。
設計
モジュールの独立性を高める設計の方針として、適切なものはどれか。
A. モジュール強度を強く、モジュール結合度を弱くする B. モジュール強度を弱く、モジュール結合度を強くする C. モジュール強度も、モジュール結合度も強くする D. モジュール強度も、モジュール結合度も弱くする
この問題へのリンク答えと解説
正解: A 【A（正解）】 ？ モジュールの中のまとまりと、モジュールどうしのつながりの組合せです。 1 つのモジュールの中の機能のまとまり（強度）が強く、モジュールどうしの結び付き（結合度）が弱いほど、独立性は高い。 【B（不正解）】 ？ 中のまとまりを弱め、つながりを強める組合せです。 まとまりの弱いモジュールが互いに強く依存し、修正の影響が広がりやすくなる。 【C（不正解）】 ？ 両方を強める組合せです。 結合度が強いと、1 つの修正が他のモジュールに及びやすく、独立性は下がる。 【D（不正解）】 ？ 両方を弱める組合せです。 強度が弱いと、関係の薄い機能が 1 つのモジュールに混ざり、分かりにくく直しにくくなる。
出典: 基本情報技術者試験（レベル 2）シラバス Ver.9.2（IPA）／応用情報技術者試験（レベル 3）シラバス Ver.7.2（IPA）
給与計算で、税額を求めるモジュールが他のモジュールと多くの大域変数を共有し、修正の影響が広がりやすい。改善策として最も適切なものはどれか。
A. 共有する大域変数をさらに増やし、受渡しの手間を減らす B. 税額モジュールに、他のモジュールの処理もまとめて入れる C. 必要なデータだけを引数で受け渡す形に改める D. 呼出し側から、処理の流れを切り替えるフラグを渡す
この問題へのリンク答えと解説
正解: C 【A（不正解）】 ？ 共有するデータを増やす方向の変更です。 共有データが増えるほどモジュール間の結び付きが強まり、修正の影響範囲が広がる。 【B（不正解）】 ？ 関係の薄い処理を 1 つに集める変更です。 関係の薄い処理を詰め込むと、モジュールの中のまとまり（強度）が弱くなる。 【C（正解）】 ？ 受け渡すものを必要な分に絞る変更です。 必要なデータだけを引数で渡す結合（データ結合）は結び付きが弱く、モジュールの独立性が高まる。 【D（不正解）】 ？ 相手の処理の流れを外から指示する変更です。 制御の情報を渡す結合（制御結合）は、相手の内部の流れに依存するので、データだけを渡す場合より結び付きが強い。
出典: 基本情報技術者試験（レベル 2）シラバス Ver.9.2（IPA）／応用情報技術者試験（レベル 3）シラバス Ver.7.2（IPA）
社内アプリを、今のサーバから別の OS のクラウド環境へ移しても、手直しを少なく動かしたい。シラバスが示す JIS X 25010 の製品品質特性で、この要求に当たるものはどれか。
A. 使用性 B. 移植性 C. 機能適合性 D. セキュリティ
この問題へのリンク答えと解説
正解: B 【A（不正解）】 ？ 利用者にとっての使いやすさや学びやすさに関わる特性です。 利用者が使いやすいかを表す特性で、別の環境への移しやすさは表さない。 【B（正解）】 ？ ハードウェアやソフトウェアなどの動作環境との関係を扱う特性です。 移植性は、別のハードウェアやソフトウェアの環境へ移しやすいかを表す。シラバスは製品品質モデルの 8 特性の 1 つに挙げている。 【C（不正解）】 ？ 必要な機能がそろい、仕様どおりに働くかに関わる特性です。 必要な機能を正しく提供できるかを表す特性で、環境を変えたときの移しやすさとは別である。 【D（不正解）】 ？ 情報やデータを守る程度に関わる特性です。 許可された人だけがデータを使えるようにする特性で、移しやすさとは関係しない。
シラバスが示す JIS X 25010 の「利用時の品質モデル」に含まれる特性はどれか。
A. 保守性 B. 移植性 C. 互換性 D. 満足性
この問題へのリンク答えと解説
正解: D 【A（不正解）】 ？ 修正や改良のしやすさに関わる特性です。 製品品質モデルの 8 特性の 1 つで、利用時の品質モデルには含まれない。 【B（不正解）】 ？ 別の環境への移しやすさに関わる特性です。 製品品質モデルの 8 特性の 1 つで、利用時の品質モデルには含まれない。 【C（不正解）】 ？ 他の製品と情報をやり取りしたり共存したりする力に関わる特性です。 製品品質モデルの 8 特性の 1 つで、利用時の品質モデルには含まれない。 【D（正解）】 ？ 使った人がどれだけ満たされるかに関わる特性です。 利用時の品質モデルは、有効性・効率性・満足性・リスク回避性・利用状況網羅性の 5 特性からなる（シラバス）。
Web アプリで、画面のデザインだけを頻繁に変えたい。データの処理と画面の表示を分けておくのに向くアーキテクチャパターンはどれか。
A. MVC モデル B. ウォーターフォールモデル C. クリティカルパス D. ハフマン符号
この問題へのリンク答えと解説
正解: A 【A（正解）】 ？ モデル・ビュー・コントローラの 3 つに役割を分ける構造です。 データと処理（モデル）、表示（ビュー）、入力の受付と制御（コントローラ）を分けるので、表示だけを差し替えやすい。シラバスはアーキテクチャパターンの例に挙げている。 【B（不正解）】 ？ 工程を順番に進める開発の進め方です。 開発プロセスのモデルで、ソフトウェアの構造を分けるパターンではない。 【C（不正解）】 ？ 日程計画の中で最も長くかかる経路です。 プロジェクトの日程管理の考え方で、ソフトウェアの構造とは関係しない。 【D（不正解）】 ？ 出現の頻度に応じて符号の長さを変える方式です。 データ圧縮のための符号化方式で、ソフトウェアの構造を分ける考え方ではない。
銀行システムで、普通預金と定期預金に共通する口座番号や残高を「口座」クラスにまとめ、違いだけを各クラスに持たせた。このクラス間の関係はどれか。
A. 集約 B. カプセル化 C. 汎化 D. インスタンス化
この問題へのリンク答えと解説
正解: C 【A（不正解）】 ？ 全体と部分の関係を表します。 注文と注文明細のような全体と部分の関係で、共通する性質のくくり出しではない。 【B（不正解）】 ？ データと操作をまとめ、中身を外から隠すことです。 1 つのクラスの内部を隠す考え方で、クラスどうしの共通部分をまとめる関係ではない。 【C（正解）】 ？ 下位のクラスから上位のクラスを見たときの関係です。 複数のクラスに共通する性質を上位のクラスにまとめる関係を汎化という。下位のクラスは上位のクラスの属性や操作を継承する。 【D（不正解）】 ？ クラスから具体的なオブジェクトを作ることです。 クラスから実体を作る操作で、クラスどうしの関係ではない。
注文処理で、画面・注文・在庫の各オブジェクトがやり取りするメッセージを時間の順に描きたい。使う UML の図はどれか。
A. クラス図 B. シーケンス図 C. ユースケース図 D. パッケージ図
この問題へのリンク答えと解説
正解: B 【A（不正解）】 ？ クラスの属性・操作とクラス間の関係を表す図です。 クラスの構造を表す静的な図で、メッセージの時間の順序は表さない。 【B（正解）】 ？ 縦の方向に時間の流れをとる図です。 オブジェクト間のメッセージのやり取りを時間の順に表すので、処理の流れの確認に向く。 【C（不正解）】 ？ アクターとシステムの機能の関係を表す図です。 誰がどの機能を使うかを表す図で、オブジェクト間のメッセージの順序は表さない。 【D（不正解）】 ？ 要素をまとまりごとに整理して表す図です。 モデルの要素をグループに分けて示す図で、時間の順序は表さない。
設計書のレビューで、作成者自身が司会を務め、悩んでいる点を説明して参加者から意見を集めた。このレビューの方式はどれか。
A. インスペクション B. パス・アラウンド C. ペアプログラミング D. ウォークスルー
この問題へのリンク答えと解説
正解: D 【A（不正解）】 ？ 役割を分け、手順を厳密に定めて行うレビューです。 インスペクションは進行役（モデレーター）が主催し、作成者は他の役を兼ねない。作成者が司会する形とは違う。 【B（不正解）】 ？ 成果物を複数の人に回し、それぞれが同時に確認する方式です。 参加者が集まらず各自で確認して意見を返す方式で、作成者が場で説明して進めるものではない。 【C（不正解）】 ？ 2 人で 1 台の PC を使って開発する進め方です。 XP の実践の 1 つで、設計書のレビューの方式ではない。 【D（正解）】 ？ 作成者が中心になって進めるレビューです。 ウォークスルーは、作成者が他のメンバーに問題点を説明してコメントを得る形をとる。作成者が司会を兼ねる点が特徴である。
出典: 高信頼化ソフトウェアのための開発手法ガイドブック（IPA SEC・2010 年）／基本情報技術者試験（レベル 2）シラバス Ver.9.2（IPA）
実装・構築と統合・テスト
注文画面の数量欄は 1〜99 が有効で、それ以外は入力エラーにする。同値分割で選ぶテストデータとして適切な組はどれか。
A. 0、100 B. −5、50、150 C. 1、50、99 D. 50、150
この問題へのリンク答えと解説
正解: B 【A（不正解）】 ？ 範囲の外側の値だけの組です。 無効な 2 つのクラスだけで、有効なクラス（1〜99）の代表値を試していない。 【B（正解）】 ？ 範囲の下・中・上から 1 つずつ選んだ組です。 無効（1 未満）・有効（1〜99）・無効（100 以上）の 3 つの同値クラスから、代表値を 1 つずつ選んでいる。 【C（不正解）】 ？ 有効な範囲の中の値だけの組です。 どれも同じ有効同値クラスに入り、無効な入力を 1 つも試していない。 【D（不正解）】 ？ 範囲の中と、上側の外の値の組です。 1 未満の無効クラスを試していない。下限の側の入力チェックの誤りを見逃す。
会員登録で、年齢は 18 歳以上 64 歳以下を受け付ける。限界値分析で選ぶテストデータの組として適切なものはどれか。
A. 18、64 B. 0、18、64、100 C. 17、18、64、65 D. 19、30、63
この問題へのリンク答えと解説
正解: C 【A（不正解）】 ？ 有効な範囲の両端だけの組です。 有効側の端だけでは、無効な 17 や 65 を誤って受け付ける誤りを見つけられない。 【B（不正解）】 ？ 範囲の両端と、離れた値の組です。 0 と 100 は境界から離れており、17 や 65 を受け付けてしまう誤りを見逃す。 【C（正解）】 ？ 範囲の両端と、その 1 つ外側の値の組です。 有効同値クラスの端（18・64）と、無効同値クラスの端（17・65）を選ぶ。境界の付近は誤りが起きやすいからである。 【D（不正解）】 ？ 範囲の内側の値だけの組です。 境界の値を含まず、「以上」と「より大きい」の書き誤りのような境目の誤りを見つけにくい。
ある処理に判定が 2 つ順に並ぶ。「X＞0 なら処理 P」の次に「Y＞0 なら処理 Q」で、偽なら何もしない。判定条件網羅に必要な最少のテストケース数はどれか。
A. 2 B. 1 C. 3 D. 4
この問題へのリンク答えと解説
正解: A 【A（正解）】 ？ 2 つの判定の真と偽を、組み合わせて出すときの数です。 1 件目で X＞0・Y＞0（両方真）、2 件目で X≦0・Y≦0（両方偽）とすれば、各判定の真と偽を 2 件で通せる。1 件では各判定の片方しか通らないので、最少は 2 件である。 【B（不正解）】 ？ すべての命令を 1 回ずつ通すときの数です。 両方を真にする 1 件で全命令は通るが、それは命令網羅の数で、偽の分岐が残る。 【C（不正解）】 ？ 判定の数に 1 を足した数です。 3 件でも網羅はできるが、最少ではない。 【D（不正解）】 ？ 真と偽のすべての組合せを試すときの数です。 4 件は真偽の全組合せで、判定条件網羅の最少の数より多い。
出典: 高信頼化ソフトウェアのための開発手法ガイドブック（IPA SEC・2010 年）／基本情報技術者試験（レベル 2）シラバス Ver.9.2（IPA）
下位のモジュールから順に結合して試すテストで、まだできていない上位モジュールの代わりに、下位モジュールを呼び出す仮のプログラムはどれか。
A. スタブ B. デバッガ C. テストデータジェネレーター D. ドライバ
この問題へのリンク答えと解説
正解: D 【A（不正解）】 ？ 英語で「切り株」を意味する名前の、仮のプログラムです。 スタブは、未完成の下位モジュールの代わりに呼び出される仮のプログラムで、上位から結合するトップダウンテストで使う。 【B（不正解）】 ？ プログラムを止めながら変数などを調べる道具です。 誤りの場所を探すための道具で、未完成のモジュールの代わりはしない。 【C（不正解）】 ？ テスト用の入力データを作る道具です。 テストデータを作る道具で、モジュールを呼び出す役目はしない。 【D（正解）】 ？ 英語で「動かすもの」を意味する名前の、仮のプログラムです。 ドライバは、未完成の上位モジュールの代わりに下位モジュールを呼び出す。下位から結合するボトムアップテストで使う。
請求書の端数処理を修正した。直していない他の機能に悪い影響が出ていないかを確かめるテストはどれか。
A. 回帰テスト B. 負荷テスト C. 受入れテスト D. 使用性テスト
この問題へのリンク答えと解説
正解: A 【A（正解）】 ？ 変更の後に、変えていない部分を確かめ直すテストです。 修正による思わぬ影響がないかを確かめるテストで、シラバスは保守の用語にも挙げている。 【B（不正解）】 ？ 大量の処理を与えて耐えられるかを試すテストです。 性能の限界を確かめるテストで、修正の影響の確認が目的ではない。 【C（不正解）】 ？ 発注者が受け取ってよいかを確かめるテストです。 納入の前に発注者が要件を満たすかを確かめるテストで、修正の影響の確認が目的ではない。 【D（不正解）】 ？ 利用者にとっての使いやすさを確かめるテストです。 使いやすさを確かめるテストで、既存の機能への影響は確かめない。
送料は「会員か」「購入額が 5,000 円以上か」「離島か」の組合せで決まる。条件の組合せと処理の漏れを、表で確かめたいときに使う技法はどれか。
A. 限界値分析 B. 命令網羅 C. 決定表 D. ペアプログラミング
この問題へのリンク答えと解説
正解: C 【A（不正解）】 ？ 範囲の境目に注目して値を選ぶ技法です。 1 つの値の範囲の境目を試す技法で、複数の条件の組合せの整理には向かない。 【B（不正解）】 ？ プログラムの各命令を通すことを目標にする基準です。 内部の構造に基づくホワイトボックスの基準で、仕様の条件の組合せを整理する技法ではない。 【C（正解）】 ？ 条件と動作を行と列に並べた表を使う技法です。 条件の組合せ（ルール）ごとに動作を表にまとめ、組合せの漏れを確かめるブラックボックスの技法である。 【D（不正解）】 ？ 2 人で 1 台の PC を使って開発する進め方です。 開発の進め方で、条件の組合せを整理するテストの技法ではない。
導入・受入れ支援と保守・廃棄
販売管理システムを外部のベンダに委託して開発した。納入に先立つ受入れテストの進め方として適切なものはどれか。
A. ベンダが自社の基準だけで合否を決め、発注者は結果を受け取る B. 発注者が受入れ基準に照らして実施し、ベンダはそれを支援する C. 受入れテストは行わず、本番の運用で問題を見つける D. ベンダの単体テストの結果を見直すだけで受入れとする
この問題へのリンク答えと解説
正解: B 【A（不正解）】 ？ 供給者の判断に任せる進め方です。 受入れの合否は、取得者（発注者）が受入れ基準に照らして判断する。 【B（正解）】 ？ 発注者が主体となる進め方です。 シラバスは、取得者が供給者の支援を受けて受入れレビューやテストを行い、結果を文書にするとしている。 【C（不正解）】 ？ 使いながら確かめる進め方です。 本番で初めて問題が見つかると、業務への影響が大きい。受入れの確認は運用を始める前に行う。 【D（不正解）】 ？ 開発側の記録を確認する進め方です。 単体テストは開発側のテストで、利用者の立場で要件を満たすかは確かめられない。
基幹システムを新システムへ切り替える。切替え直後の不具合で業務が止まるリスクを下げたい。シラバスの移行の考え方に沿う進め方はどれか。
A. 新旧を並行運用して結果を照合し、その後に旧環境を止める B. 計画を関係者に知らせず、休日に一斉に切り替える C. 切替えと同時に、旧環境のデータをすべて消す D. 移行結果は検証せず、利用者の苦情で問題を見つける
この問題へのリンク答えと解説
正解: A 【A（正解）】 ？ 新旧を同時に動かす期間を設ける進め方です。 シラバスは移行の留意事項として、新旧環境の並行運用と旧環境の停止、移行結果の検証を挙げている。 【B（不正解）】 ？ 関係者への通知をしない進め方です。 移行計画や移行そのものは、関係者全員に通知する。 【C（不正解）】 ？ 旧環境のデータを残さない進め方です。 旧環境に関わるデータは保持し、その安全性を確保する。 【D（不正解）】 ？ 検証を省く進め方です。 移行の結果は検証し、評価する。苦情を待つのでは影響が大きくなる。
保守中のシステムで、同じ種類の障害が何度も起きている。保守の手順として、次に行うべきことはどれか。
A. 障害のたびに再起動して復旧させ、記録は残さない B. 利用者に注意を呼びかけるだけにし、原因は調べない C. 障害の起きた機能を使用禁止にして、そのまま運用を続ける D. 特性要因分析などで根本原因を探り、改善や手順書の改訂を行う
この問題へのリンク答えと解説
正解: D 【A（不正解）】 ？ その場の復旧だけを繰り返す対応です。 記録がなければ原因をたどれず、同じ障害が繰り返される。 【B（不正解）】 ？ 利用者の操作に頼る対応です。 根本原因が残るので、再発を防げない。 【C（不正解）】 ？ 機能を止めて様子を見る対応です。 一時的な回避策にはなるが、原因を取り除かないので解決にならない。 【D（正解）】 ？ 原因を突き止めてから手を打つ対応です。 シラバスは再発防止策として、特性要因分析などで根本原因を抽出し、類似事故の可能性を検討して改善やマニュアルの改訂を行うとしている。
古い顧客管理システムを廃棄する。廃棄の手順として適切なものはどれか。
A. 利用者に知らせないまま、ある日に突然システムを止める B. 新システムが動き出したら、旧データをすぐにすべて消す C. 廃棄を利用者に知らせ、必要なデータは保持して参照できるようにする D. 旧システムを止めずに残し、誰も使わないまま放置する
この問題へのリンク答えと解説
正解: C 【A（不正解）】 ？ 事前の通知をしない進め方です。 廃棄の計画は利用者に通知し、関係者全員にも廃棄を知らせる。 【B（不正解）】 ？ 古いデータを残さない進め方です。 廃棄に関わるデータは保持し、必要なときに参照できるようにしておく。 【C（正解）】 ？ 通知とデータの扱いを決めて進める方法です。 シラバスは廃棄の手順に、廃棄計画の立案と利用者への通知、廃棄関連データの保持とアクセス可能性の確保を挙げている。 【D（不正解）】 ？ 止めずに置いておく進め方です。 使わない機器やソフトウェアを動かしたままにすると、管理の手間や情報漏えいのおそれが残る。
開発プロセス・手法
スクラムで、プロダクトバックログを管理し、項目の優先順位を決める役割はどれか。
A. スクラムマスター B. プロダクトオーナー C. 開発者 D. ステークホルダ
この問題へのリンク答えと解説
正解: B 【A（不正解）】 ？ スクラムの進め方がうまく回るよう支える役割です。 スクラムのプロセスを回し、生産性を高めることに責任を持つ。バックログの優先順位を決める役割ではない。 【B（正解）】 ？ プロダクトの価値に責任を持つ役割です。 IPA の資料は、プロダクトバックログはプロダクトオーナーが管理し、優先順位付けされているとしている。 【C（不正解）】 ？ 実際の開発作業に携わる人たちです。 スプリントで開発を行う人たちで、プロダクトバックログの優先順位を決める役割ではない。 【D（不正解）】 ？ 利用者や出資者などの利害関係者です。 意見や要望を出す立場で、バックログの管理はしない。
2 週間のスプリントの最終日に、予定した機能の 1 つが完成しなかった。スクラムの考え方に沿った対応はどれか。
A. 完成するまで、今回のスプリントを 1 週間延ばす B. 未完成のまま完成扱いにして、リリースする C. スプリントは延ばさず、残った項目は次の計画で扱いを決め直す D. スクラムマスターが一人で、残りを作り終える
この問題へのリンク答えと解説
正解: C 【A（不正解）】 ？ 期間を延ばして完成させる対応です。 スプリントは決まった時間枠で、予定の機能が完成しなくても延長しない。 【B（不正解）】 ？ 完成の判断を甘くする対応です。 リリースするかどうかは、スプリントレビューを経てプロダクトオーナーが決める。未完成のものを完成扱いにはしない。 【C（正解）】 ？ 時間枠を守る対応です。 IPA の資料は、スプリントは 1〜4 週間の時間枠で、予定の機能が完成しなくても延長されないとしている。残った項目は次のスプリントプランニングで扱う。 【D（不正解）】 ？ 役割の違う人に作業を任せる対応です。 開発は開発者が行う。スクラムマスターは進め方を支える役割である。
2 人が 1 台の PC を共有し、1 人が入力し、もう 1 人が確認しながら指示を出して同じプログラムを作る。この XP の実践はどれか。
A. ペアプログラミング B. リファクタリング C. 継続的インテグレーション D. ウォークスルー
この問題へのリンク答えと解説
正解: A 【A（正解）】 ？ 役割を交代しながら進める XP の実践です。 キーボードを持つドライバーと、作業を見て先を考えるナビゲーターに分かれ、役割を交代しながら開発する。シラバスは XP の特徴の用語例に挙げている。 【B（不正解）】 ？ 外から見た動きを変えずに、中の構造を整えることです。 コードの内部を整える作業で、2 人 1 組で開発する方法ではない。 【C（不正解）】 ？ 変更をこまめに統合して確かめる実践です。 変更を頻繁に統合する実践で、2 人で同じプログラムを作る方法ではない。 【D（不正解）】 ？ 作成者が説明して意見を集めるレビューです。 作り終えた成果物を見直すレビューの方式で、2 人で同時に作る方法ではない。
出典: 基本情報技術者試験（レベル 2）シラバス Ver.9.2（IPA）／アジャイル型開発におけるプラクティス活用 リファレンスガイド（IPA・2013 年）
利用者自身も要求をはっきり言えない新サービスを開発する。早い段階で試作品を見せ、反応を聞いて要求を固めたい。向く開発モデルはどれか。
A. ウォーターフォールモデル B. 形式手法 C. DevOps D. プロトタイピングモデル
この問題へのリンク答えと解説
正解: D 【A（不正解）】 ？ 工程を上から順に一方向に進めるモデルです。 要件を最初に固めて順に進めるので、要求があいまいなまま始めると後で大きな手戻りになりやすい。 【B（不正解）】 ？ 仕様を規則に従って厳密に書く手法です。 仕様のあいまいさをなくす手法で、試作品で要求を引き出す進め方ではない。 【C（不正解）】 ？ 開発と運用が協力して素早く届ける考え方です。 開発と運用の連携の考え方で、試作品で要求を固めるモデルそのものではない。 【D（正解）】 ？ 利用者の評価を取り入れながら進めるモデルです。 早い段階で試作品を作り、利用者の評価を受けて要求を明らかにしていくので、要求があいまいな開発に向く。
開発者が多いチームで、結合の段階で不具合がまとめて見つかり、原因の特定に時間がかかっている。改善策として最も適切なものはどれか。
A. 各自の変更を月末にまとめて結合し、一度に試験する B. 変更をこまめに統合し、自動でビルドとテストを行う C. 結合テストは省き、本番の環境で利用者に確かめてもらう D. 開発者ごとに別の版を作り、統合しないまま出荷する
この問題へのリンク答えと解説
正解: B 【A（不正解）】 ？ 変更をためてから結合する進め方です。 変更をためるほど一度に混ざる変更が増え、不具合の原因を絞り込みにくくなる。 【B（正解）】 ？ 小さな単位で頻繁に統合する進め方です。 継続的インテグレーションである。小さな変更ごとに統合して確かめるので、不具合を早く見つけ、原因も絞り込みやすい。 【C（不正解）】 ？ テストを利用者に任せる進め方です。 本番で不具合が見つかれば業務への影響が大きく、原因の特定もさらに難しくなる。 【D（不正解）】 ？ 統合をしない進め方です。 版がばらばらになり、どの版が正しいのか管理できなくなる。
出典: 基本情報技術者試験（レベル 2）シラバス Ver.9.2（IPA）／アジャイル型開発におけるプラクティス活用 リファレンスガイド（IPA・2013 年）
鉄道の制御ソフトで、自然言語のあいまいさを避けるため、仕様を専用の言語で規則に従って厳密に書く。この手法はどれか。
A. 構造化手法 B. アジャイル C. 形式手法 D. リバースエンジニアリング
この問題へのリンク答えと解説
正解: C 【A（不正解）】 ？ 機能を階層に分け、段階的に詳しくしていく手法です。 機能分割と段階的詳細化の手法で、専用の言語で仕様を厳密に書く手法ではない。 【B（不正解）】 ？ 短い反復で動くソフトウェアを作っていく考え方です。 変化に素早く対応する開発の考え方で、仕様を厳密に書く手法ではない。 【C（正解）】 ？ VDM などの道具が知られる手法です。 シラバスは形式手法を、自然言語で書いていた仕様を形式仕様記述言語でルールに従って厳密に書き、品質を高める手法としている。 【D（不正解）】 ？ 既存のソフトウェアを解析して仕様を明らかにすることです。 でき上がったものから仕様を読み取る作業で、新しく仕様を書く手法ではない。
ソフトウェア開発会社が、自社の開発と保守のプロセスがどの水準にあるかを段階で評価し、改善の目標にしたい。使うモデルはどれか。
A. CMMI B. ITIL C. PPM D. SWOT 分析
この問題へのリンク答えと解説
正解: A 【A（正解）】 ？ 組織のプロセスの成熟度を段階で示すモデルです。 シラバスは、開発や保守を行う組織のプロセス成熟度の水準を識別する成熟度モデルとして CMMI を挙げている。 【B（不正解）】 ？ IT サービスマネジメントの実践をまとめたものです。 IT サービスの運用管理の実践集で、開発プロセスの成熟度を段階で評価するモデルではない。 【C（不正解）】 ？ 事業や製品を、市場の成長率と占有率で分類する手法です。 経営資源の配分を考える手法で、開発プロセスの評価には使わない。 【D（不正解）】 ？ 強み・弱み・機会・脅威で環境を整理する手法です。 経営戦略を考えるための手法で、プロセスの成熟度は測らない。
知的財産適用管理・開発環境管理・構成管理
A 社の社員が、会社の指示で業務用のプログラムを作った。契約や就業規則に別段の定めはない。このプログラムの著作者はどれか。
A. 作成した社員個人 B. A 社 C. 社員と A 社の共有 D. プログラムを使う顧客
この問題へのリンク答えと解説
正解: B 【A（不正解）】 ？ 実際にプログラムを書いた人です。 職務著作の条件を満たすので、別段の定めがない限り、社員個人は著作者にならない。 【B（正解）】 ？ 社員を雇っている法人です。 著作権法 15 条 2 項により、法人の発意で業務に従事する者が職務上作るプログラムは、別段の定めがない限り法人が著作者となる。プログラムは法人の名義で公表するかを問わない。 【C（不正解）】 ？ 個人と法人の両方とする考え方です。 法律に共有とする定めはなく、条件を満たせば法人が著作者になる。 【D（不正解）】 ？ プログラムの利用者です。 利用者であるだけでは著作者にならない。
出典: 著作権法 第 15 条（e-Gov 法令検索）／基本情報技術者試験（レベル 2）シラバス Ver.9.2（IPA）
部署で有料の開発ツールを使っている。ライセンス違反を防ぐための管理として適切なものはどれか。
A. 便利なので、1 本分のライセンスを全員の PC に入れる B. 購入時に一度確かめれば、その後は確かめない C. 退職者の PC に入ったツールは、そのまま放置する D. インストール数と保有ライセンス数を定期的に照合する
この問題へのリンク答えと解説
正解: D 【A（不正解）】 ？ 購入した数より多く入れる使い方です。 ライセンス条項に違反した使い方は不正利用で、法的な処罰の対象になる。 【B（不正解）】 ？ 最初だけ確認する管理です。 使う人や台数は変わるので、一度の確認だけでは違反に気付けない。 【C（不正解）】 ？ 使われていない導入を残す管理です。 誰が使っているか分からない導入が残り、保有数との照合ができなくなる。 【D（正解）】 ？ 数を定期的に突き合わせる管理です。 シラバスは、ライセンスの内容を理解し、定期的にインストール数と保有ライセンス数を照合することが必要だとしている。
利用している OSS に脆弱性が公表された。自社のどの製品がその部品を含むかを素早く調べられるよう、日頃から整えておくものはどれか。
A. SBOM B. WBS C. RFP D. SLA
この問題へのリンク答えと解説
正解: A 【A（正解）】 ？ ソフトウェアを構成する部品の一覧です。 製品ごとに使っている部品と版が分かるので、脆弱性のある部品を含む製品をすぐに特定できる。シラバスは構成管理の用語に挙げ、SBOM を利用した脆弱性管理にも触れている。 【B（不正解）】 ？ 作業を階層的に分解したものです。 プロジェクトの作業を整理するもので、製品に含まれる部品は分からない。 【C（不正解）】 ？ 発注先の候補に提案を求める文書です。 調達のための文書で、製品の部品の構成は記録しない。 【D（不正解）】 ？ サービスの水準を提供者と利用者で取り決めた合意です。 サービスの品質の約束で、部品の構成の把握には使わない。
複数の担当者で同じソフトウェアを開発している。担当者ごとにコンパイラの版が違い、動きに差が出た。開発環境の管理として適切なものはどれか。
A. 各担当者が好きな版を使い、問題が出たら個別に直す B. 版は記録せず、新しい版が出るたびに各自で入れ替える C. 使うツールと版をそろえ、構成品目として管理する D. コンパイラを使わず、すべて手作業で確かめる
この問題へのリンク答えと解説
正解: C 【A（不正解）】 ？ 版をそろえない管理です。 版の違いで互換性の問題が起き続け、原因の切り分けも難しくなる。 【B（不正解）】 ？ 版を記録しない管理です。 どの版で作ったかが分からず、同じ結果を再現できなくなる。 【C（正解）】 ？ ツールそのものも管理の対象にする方法です。 シラバスは、ツールや版の違いが互換性の問題を生むため、使うツールや版を統一して管理する必要があるとしている。 【D（不正解）】 ？ 道具を使わない進め方です。 ツールをやめても問題の解決にはならず、開発の効率も大きく落ちる。
この分野に出てくる用語（53 語）
CMMI：開発や保守を行う組織のプロセスの成熟度の水準を、段階で示すモデル。
DevOps：開発担当と運用担当が協力し、ソフトウェアの開発から運用までを素早く回す考え方。
E-R 図：データの対象（エンティティ）と、その間の関連（リレーションシップ）を図で表したもの。
ITIL：IT サービスマネジメントの実践の方法をまとめたベストプラクティス集。
JIS X 25010：システムとソフトウェア製品の品質のモデルを定めた日本産業規格。シラバスは製品品質の 8 特性と利用時の品質の 5 特性を挙げる。
MVC モデル：ソフトウェアをモデル（データと処理）、ビュー（表示）、コントローラ（入力と制御）に分けるアーキテクチャパターン。
PPM：市場成長率と市場占有率で事業や製品を分類し、経営資源の配分を考える手法。
RFP：システムの調達で、発注者が要件や条件を示し、供給者に提案を求める文書。
SBOM：ソフトウェアを構成する部品（コンポーネント）の一覧。脆弱性のある部品を含む製品を探すのに使う。
SLA：サービスの提供者と利用者の間で、サービスの内容と達成すべき水準を取り決めた合意。
SWOT 分析：自社の強み・弱みと、外部環境の機会・脅威を整理して戦略を考える手法。
UML：オブジェクト指向の分析・設計で使う、図の表記法を定めたモデリング言語。
WBS：プロジェクトの成果物や作業を、管理しやすい大きさまで階層的に分解したもの。
アジャイル：短い期間の反復で動くソフトウェアを作り、変化に柔軟に対応する開発の考え方。
インスペクション：進行役（モデレーター）が主催し、役割と手順を厳密に定めて行う公式なレビュー。作成者は他の役を兼ねない。
ウォークスルー：作成者が他のメンバーに成果物や問題点を説明し、意見を得る形のレビュー。作成者が中心になって進める。
ウォーターフォールモデル：要件定義から設計・実装・テストへと、工程を順番に進めていく開発モデル。
オブジェクト指向：データと操作を 1 つにまとめたオブジェクトを単位として、ソフトウェアを分析・設計・開発する考え方。
カプセル化：データとそれを操作するメソッドを 1 つにまとめ、内部の詳細を外部から見えなくすること。
ガントチャート：縦に作業、横に時間をとり、各作業の予定や実績を横棒で表した図。
クリティカルパス：プロジェクトの作業の流れのうち、最も時間がかかる経路。この経路の作業が遅れると全体が遅れる。
シーケンス図：オブジェクトの間のメッセージのやり取りを、時間の順に表す UML の図。
スクラム：スプリントと呼ぶ短い期間を繰り返し、チームで開発を進めるアジャイルの枠組み。
スタブ：テストで、まだできていない下位のモジュールの代わりに呼び出される仮のプログラム。
ステークホルダ：プロジェクトに関わる、またはその影響を受ける個人や組織。
ドライバ：テストで、まだできていない上位のモジュールの代わりに、テスト対象のモジュールを呼び出す仮のプログラム。
トレーサビリティマトリクス：要件と設計・テストなどの成果物の対応を表にしたもの。双方向にたどれるようにして変更の影響を調べる。
ハフマン符号：出現する頻度の高い記号に短い符号を割り当て、全体のデータ量を減らす符号化の方式。
パレート図：項目を値の大きい順に並べた棒グラフと、累積比率の折れ線を組み合わせた図。重点項目の把握に使う。
ブラックボックステスト：プログラムの内部構造を考えず、仕様どおりの入力に対して正しい出力が得られるかを確かめるテスト。
プロダクトオーナー：スクラムで、何を開発するかを決め、プロダクトバックログを管理する役割。
プロダクトバックログ：プロダクトに加える要求の一覧。プロダクトオーナーが管理し、優先順位を付ける。
プロトタイピングモデル：早い段階で試作品を作り、利用者の評価を受けながら要求を明らかにしていく開発モデル。
プロトタイプ：仕様の漏れや使い勝手を早めに確かめるために作る試作品。手戻りを防ぐ目的で使う。
ペアプログラミング：2 人が 1 つの画面に向き合い、入力するドライバーと全体を見るナビゲーターに分かれて開発する XP の実践。
ホワイトボックステスト：プログラムの内部構造に着目し、命令や分岐をもれなく通るように行うテスト。
モジュール強度：1 つのモジュールの中の機能のまとまりの強さ。強いほどモジュールの独立性が高い。
モジュール結合度：モジュール同士の関係の強さ。結合度が弱いほど、モジュールの独立性が高い。
ユースケース：1 つの目標を達成するための、利用者（アクター）とシステムのやり取りを定義したもの。
リバースエンジニアリング：既存のソフトウェアなどを解析して、その仕様や設計を明らかにすること。
リファクタリング：外から見た動きを変えずに、プログラムの内部の構造を分かりやすく整えること。
回帰テスト：プログラムを変更した後、変更していない部分に悪い影響が出ていないかを確かめるテスト。
形式手法：仕様を形式仕様記述言語でルールに従って厳密に書き、ソフトウェアの品質を高める手法。
継続的インテグレーション：変更をこまめに統合し、ビルドとテストを自動で繰り返して問題を早く見つける実践。CI とも呼ぶ。
決定表：条件の組合せ（ルール）と、それに対応する動作を表にまとめたもの。条件の組合せの漏れを確かめるのに使う。
限界値分析：入力の有効範囲と無効範囲の境目の値を、テストデータとして選ぶ技法。境界値分析とも呼ぶ。
受入れテスト：システムの取得者（発注者）が、受入れ基準に照らして納入物を受け入れてよいかを確かめるテスト。
職務著作：法人の発意に基づき、その業務に従事する者が職務上作った著作物は、条件を満たすと法人が著作者になるという定め。
同値分割：同じ処理になると期待できる入力をクラスに分け、各クラスから代表値を選んでテストする技法。
判定条件網羅：各判定の真と偽の分岐を、少なくとも 1 回ずつ通るようにテストする網羅基準。C1 カバレッジとも呼ぶ。
汎化：複数のクラスに共通する性質を、上位のクラスにまとめる関係。下位のクラスは上位の性質を継承する。
非機能要件：パフォーマンス・信頼性・移行など、機能以外にシステムに求められる性質についての要件。
命令網羅：すべての命令を少なくとも 1 回は実行するようにテストする網羅基準。C0 カバレッジとも呼ぶ。
独学の次に、講座で体系立てて学びたい人へ
この問題集は独学用です。IT の基礎から講師つきで体系立てて学びたい人には、資格や IT の講座がそろうスクールも選択肢になります。
本ページは広告・アフィリエイトプログラムを利用しており、リンク経由でのお申し込み・購入により当サイトに収益が発生することがあります。ただし、ランキング・評価・掲載内容は広告費や報酬の有無に関わらず編集部の独自基準で決定しており、広告主からの指示により内容を変更することはありません。
IT・Webデザイン・資格まで幅広い講座。生成AI/DX講座はリスキリング補助金の対象
まずは無料ではじめられます。リンク先は公式サイトです。
このサービスの解説記事を読む →