目次
システム開発ライフサイクル
システム開発は、企画、要件定義、設計、実装、テスト、移行、運用・保守といった流れで進んでいきます。これをシステム開発ライフサイクルと呼びます。それぞれの工程でやるべきことが決まっており、順番に進めることで品質を確保します。
試験でこう出る：企画から運用・保守までの工程名と順番を問う問題が定番です。「要件定義→設計→プログラミング→テスト」の流れがよく出題されます。
小学生でもわかる説明：なにを作るか考えて、作るきまりを決めて、作って、ちゃんと動くか調べて、使っていく…という一連の流れのことです。
要件定義（要求分析）
要件定義は「システムに何をしてほしいか」を整理する工程です。利用者の業務をヒアリングし、必要な機能や性能、使いやすさ、制約条件などをまとめて文書化します。ここがあいまいだと、作ったあとに「思っていたのと違う」となりやすくなります。
試験でこう出る：要件定義＝システムの「あるべき姿」「何をするか」を決める工程であり、「どのように作るか」は設計以降だと区別できるかが問われます。
小学生でもわかる説明：ゲームを作る前に、「どんなゲームにするか」をみんなで話し合って決めるところです。
外部設計と内部設計
外部設計は、利用者から見た動きや画面、帳票、入力・出力の形式などを決める工程です。内部設計は、プログラム内部でどのように処理するか、データ構造やモジュール構成などを決める工程です。外部設計は「外から見える仕様」、内部設計は「中の作り」のイメージです。
試験でこう出る：外部設計＝画面や帳票などユーザー視点、内部設計＝プログラム構造やデータ構造という対比を問う問題が頻出です。
小学生でもわかる説明：外から見えるかたちを決めるのが外部設計、中のしくみをこまかく決めるのが内部設計です。
プログラミング（実装）
設計書に基づいて、実際にプログラム言語を使ってコードを書く工程です。設計通りに動くように、コーディング規約やレビューなどを通じて品質を確保します。
試験でこう出る：プログラミングは「設計を具体的なプログラムにする工程」として出されます。要件定義・設計との違いがポイントです。
小学生でもわかる説明：決めたとおりにコンピュータにわかる言葉で書いていく作業です。
テスト工程（単体・結合・システム・受入）
テストは、バグを見つけて品質を確かめる工程です。単体テストは小さなプログラム部品ごと、結合テストは部品をつなげたとき、システムテストはシステム全体として、受入テストは利用者が自分たちの業務でちゃんと使えるかを確認します。工程が進むほどテスト対象も大きくなります。
試験でこう出る：単体→結合→システム→受入というテストの順番と、それぞれの目的を対応させる問題がよく出題されます。単体＝モジュール単位、受入＝ユーザーによる確認が重要キーワードです。
小学生でもわかる説明：小さな部品からだんだんまとめていって、最後は本番と同じようにちゃんと動くかたしかめることです。
ウォータフォールモデル
ウォーターフォールモデルは、上流から下流へ工程を一方向に順番に進めていく開発モデルです。要件定義、設計、実装、テストなどを段階ごとに区切り、前の工程をきちんと終わらせてから次へ進みます。大規模開発や変更が少ない場合に向いています。
試験でこう出る：工程が「基本的に前に戻らない一方向」であること、上流工程の品質が重要であることなどが問われます。アジャイルとの対比問題も頻出です。
小学生でもわかる説明：上から下へ水が流れるように、順番どおりに工程を進めていく作り方です。
アジャイル開発
アジャイル開発は、短いサイクルで設計・実装・テストを繰り返しながら、少しずつシステムを育てていく開発手法です。仕様変更に柔軟に対応でき、利用者との対話を重視します。代表的な手法にスクラムがあります。
試験でこう出る：アジャイル＝反復・短いサイクル・変化対応・顧客との対話重視といったキーワードがセットで出ます。ウォーターフォールとの違いが定番問題です。
小学生でもわかる説明：少し作っては見せて、なおして、また少し作る…をくり返して完成させる作り方です。
レビューとテストの違い
レビューは、設計書やコードなどの成果物を人の目で点検する活動です。テストは、プログラムを実際に動かして動作を確認する活動です。レビューは「動かす前に気づく」、テストは「動かして確かめる」という違いがあります。
試験でこう出る：レビュー＝静的、テスト＝動的という整理が問われます。仕様書や設計書はレビュー、動作確認はテストと結びつけられるかがポイントです。
小学生でもわかる説明：ノートを見てまちがいをさがすのがレビュー、実際にやってみてまちがいをさがすのがテストです。
ソフトウェア保守
稼働開始後のシステムに対して行う作業が保守です。バグを直す修正保守、環境変化への対応などの適応保守、性能改善を行う予防保守、機能追加・改善を行う改善保守などの分類があります。システムは運用開始後も手入れが必要です。
試験でこう出る：保守の分類名と内容の組合せ問題が頻出です。バグ修正＝修正保守、機能追加＝改善保守といった対応を覚えることが重要です。
小学生でもわかる説明：直して、なおして、もっとよくして、こわれないようにする、というお世話をつづけることです。
構成管理（バージョン管理）
プログラムやドキュメントの変更履歴を管理する活動です。どの版がどこで使われているかを明確にして、誤ったバージョンを使うトラブルを防ぎます。変更の記録を残すことで原因調査も容易になります。
試験でこう出る：構成管理＝バージョンや構成要素を管理すること、と定義できるかがポイントです。開発プロセス管理の一つとして出題されます。
小学生でもわかる説明：いつ、だれが、どこを直したかをきちんとメモしておくことです。