基本情報技術者試験 システム開発完全対策
開発モデル・テスト技法・UML・アジャイル
システム開発は、ソフトウェアをどのような手順・手法で作るかを学ぶ分野です。 基本情報技術者試験では、開発モデルの特徴（ウォーターフォール・アジャイル）と テスト技法（ブラックボックス・ホワイトボックス）が毎回のように出題されます。 用語の意味と使い分けをしっかり押さえることが、この分野の得点アップの鍵です。
1. 開発モデルの種類と特徴
ソフトウェアをどのような順序・サイクルで開発するかを定めたのが開発モデル（開発プロセスモデル）です。 試験では各モデルの特徴と向いているプロジェクトのタイプを問う問題が頻出です。
| モデル | 特徴 | 向いているケース |
|---|---|---|
| ウォーターフォール | 要件定義→設計→製造→テストを順番に進める。各工程の完了後に次へ。後戻りが困難 | 要件が最初から明確で変更が少ない大規模システム |
| アジャイル | 短いサイクル（イテレーション・スプリント）で開発とリリースを繰り返す。変更に柔軟 | 要件が変わりやすいWebサービス・スタートアップ |
| スクラム | アジャイルの代表的フレームワーク。スプリント（1〜4週間）単位で計画・開発・レビューを繰り返す | 小規模チームの反復開発 |
| プロトタイピング | 試作品（プロトタイプ）を早期に作り、利用者の確認を得ながら要件を固める | 要件があいまいで利用者の確認が必要なシステム |
| スパイラルモデル | 開発をらせん状に繰り返し、各サイクルでリスク評価を行いながら進める | リスクが高く段階的に確認が必要な大規模開発 |
| RAD（高速開発） | ツールや既存コンポーネントを活用して短期間でシステムを構築する | 短納期が求められる中小規模の開発 |
2. 開発工程の流れと各フェーズ
ウォーターフォールモデルの代表的な工程を理解しておくと、テスト段階の対応関係も整理しやすくなります。 上流工程と下流工程のテストが対応する「V字モデル」は試験頻出です。
| 上流工程 | 内容 | 対応するテスト（V字モデル） |
|---|---|---|
| 要件定義 | 利用者の要求を整理し、何を作るか決める | 運用テスト（受け入れテスト） |
| 外部設計（基本設計） | 利用者から見た画面・帳票・インターフェースを設計 | システムテスト |
| 内部設計（詳細設計） | プログラム内部のモジュール構造・データ構造を設計 | 結合テスト |
| プログラミング（製造） | 設計書をもとにコードを作成 | 単体テスト |
V字モデルでは「左側の工程（上流）」と「右側のテスト（下流）」が対応しており、 たとえば外部設計で決めた仕様がシステムテストで検証されます。 この対応を覚えておくと、「〇〇設計に対応するテストは？」という問題がすぐ解けます。
SLCP（共通フレーム）
SLCP（Software Life Cycle Process）は、ソフトウェア開発の各プロセスを標準化したフレームワークです。 日本では「共通フレーム」として広く参照されています。 発注者・開発者・運用者など関係者間の認識を合わせるための共通語彙を提供します。
3. テスト技法（ブラックボックス・ホワイトボックス）
テストはソフトウェアの欠陥（バグ）を発見するための活動です。 テスト技法は大きく2つの観点に分かれます。
ブラックボックステスト
ブラックボックステストは、プログラムの内部構造を見ずに、 仕様（入力と期待される出力）に基づいてテストを行う手法です。 「箱の中身を知らずに外から動作を確認する」イメージです。
| 技法 | 内容 | 例 |
|---|---|---|
| 同値分割 | 入力値を同じ処理をする「同値クラス」に分け、各クラスの代表値1つでテストする | 1〜100が有効なら代表値として50をテスト、101以上の代表値として200をテスト |
| 限界値分析（境界値分析） | 同値クラスの境界付近（境界値とその前後）を重点的にテストする。バグが境界に集中しやすいため | 1〜100が有効なら0、1、100、101をテスト |
| デシジョンテーブル | 複数の条件の組み合わせと対応する動作を表にまとめてテストケースを設計する | 「会員かつクーポンあり→最大割引」などの条件組み合わせ |
| 状態遷移テスト | システムの状態と遷移をモデル化し、各遷移をテストする | ログイン状態・ログアウト状態の遷移を網羅 |
ホワイトボックステスト
ホワイトボックステストは、プログラムの内部構造（ソースコード）に着目し、 命令や分岐を網羅的に実行することを目標とするテスト手法です。 「箱の中身を見ながらすべての経路を通す」イメージです。 主にプログラマーが行う単体テストで使われます。
4. カバレッジ基準（命令網羅・分岐網羅）
ホワイトボックステストでは、テストがどれだけコードを「カバー（網羅）」しているかを カバレッジ（網羅率）で表します。 カバレッジ基準が高いほど多くのテストケースが必要になりますが、より多くのバグを発見できます。
| 基準 | 内容 | 必要テストケース数 |
|---|---|---|
| 命令網羅（C0） | すべての命令（ステートメント）を最低1回実行する | 少ない（最も弱い基準） |
| 分岐網羅（C1） | すべての分岐（if文のTRUE側・FALSE側の両方）を最低1回通る | 中程度（命令網羅を含む） |
| 条件網羅（C2） | 複合条件の各単純条件がTRUE・FALSEの両方を取るようにテストする | 多い（分岐網羅より強い） |
| 複数条件網羅 | 複合条件の全組み合わせを網羅する | 非常に多い（最も強い基準） |
5. UMLの主要図
UML（Unified Modeling Language：統一モデリング言語）は、 システムの設計・仕様を図で表現するための国際標準の記法です。 オブジェクト指向システムの設計に広く使われています。
| 図の種類 | 目的 | 主な使いどころ |
|---|---|---|
| クラス図 | クラスの属性・操作・クラス間の関係（継承・集約・関連）を表す | システムの静的構造の設計 |
| シーケンス図 | オブジェクト間のメッセージのやり取りを時系列で表す | 処理の流れ・インタラクションの設計 |
| ユースケース図 | 利用者（アクター）とシステムの機能（ユースケース）の関係を表す | 要件定義・機能一覧の可視化 |
| アクティビティ図 | 処理の流れをフローチャートのように表す | 業務フロー・アルゴリズムの可視化 |
| 状態遷移図（ステートマシン図） | オブジェクトの状態変化とトリガーを表す | 状態管理が複雑なシステムの設計 |
試験では「クラス図・シーケンス図・ユースケース図のどれを使うべきか」という問題が出ます。 「構造→クラス図」「処理の流れ→シーケンス図」「利用者と機能→ユースケース図」と用途で覚えましょう。
6. レビュー手法
レビューは、設計書やコードを関係者が確認して早期に欠陥を発見する活動です。 テストよりも早い段階で欠陥を取り除けるため、修正コストを大幅に削減できます。
| 手法 | 内容 | 特徴 |
|---|---|---|
| ウォークスルー | 作成者が参加者に成果物を説明しながら確認する非公式なレビュー | 和やかな雰囲気で意見を集めやすい。早期段階に適している |
| インスペクション | モデレーター・作成者・レビュワーなど役割を決めて行う公式かつ構造化されたレビュー | 最も厳格で欠陥発見率が高い。記録・追跡も行う |
| ラウンドロビンレビュー | 参加者が順番に成果物を読み込んでコメントする方式 | 全員が積極的に参加する |
| ピアレビュー | 同僚（ピア）が相互にコードや設計をレビューする | コードレビューとして開発現場で広く使われる |
7. 例題で確認
8. よくある質問（FAQ）
Q. ウォーターフォールとアジャイルの違いがあいまいです。
A. 「ウォーターフォール＝計画通り順番に・後戻りが困難・要件が最初から決まっているプロジェクト向け」「アジャイル＝小さく反復・変更に強い・要件が変わりやすいWebサービス向け」と対比で覚えましょう。試験では特徴の文章から正しい開発モデルを選ぶ問題が多いです。
Q. ブラックボックスとホワイトボックスの区別は？
A. 「ブラック＝中が見えない＝仕様（入出力）で検証」「ホワイト＝中が見える＝内部構造（命令・分岐）で検証」と名前の由来で覚えましょう。同値分割・限界値分析はブラックボックス、命令網羅・分岐網羅はホワイトボックスです。
Q. 同値分割と限界値分析の違いがわかりません。
A. 同値分割は「同じ処理をするグループを作って代表値1つをテストする」、限界値分析は「グループの境界付近（端の値）を重点的にテストする」です。実際の試験ではセットで問われることが多く、両方の考え方でテストケースを設計するのが一般的です。
Q. テストの段階の順番が覚えられません。
A. 「単体→結合→システム→運用（受け入れ）」と、小さい単位から大きい単位へ進むと覚えましょう。単体テストは1つのモジュール、結合テストは複数のモジュールの組み合わせ、システムテストはシステム全体、運用テストは実際の利用者が確認する、という流れです。
Q. UMLの図が多くて覚えられません。
A. 試験で頻出なのはクラス図・シーケンス図・ユースケース図の3つです。「構造→クラス図」「処理の時系列→シーケンス図」「利用者と機能→ユースケース図」と用途で整理するのが最短です。
Q. インスペクションとウォークスルーの違いは？
A. インスペクションは「役割を決めた公式で厳格なレビュー」、ウォークスルーは「作成者が説明する非公式なレビュー」です。欠陥発見率はインスペクションの方が高く、ウォークスルーは手軽さが利点です。
Q. スクラムのスプリントとは何ですか？
A. スプリントはスクラムにおける反復開発の1サイクルで、通常1〜4週間の固定期間です。各スプリントでは計画（スプリントプランニング）→開発→レビュー→振り返り（レトロスペクティブ）を繰り返します。スプリントの終了時に動くソフトウェアをリリースするのが原則です。