システム開発技術 ― 要件定義・設計・実装・テスト・保守

1. 開発工程の全体像と V 字モデル

システム開発は「決める → 分解する → 作る → 組み上げて確かめる → 使い続ける」という一方向の流れです。JIS X 0160（ソフトウェアライフサイクルプロセス）はこの流れをプロセスとして定めており、応用情報ではこのプロセス名がそのまま選択肢になります。まず全体像を 1 枚で押さえます。

V 字モデルは、左側に分解していく工程（要件定義・設計）を、右側に組み上げて確かめる工程（テスト）を並べ、同じ高さのものどうしを対応させた見方です。左で決めたことは、同じ高さの右のテストで確認します。詳細設計の誤りは単体テストで、要件定義の誤りは受入れテスト（資料により運用テストと呼ぶこともあります）で見つかる、という対応関係が試験の論点です。

右側のテスト工程の名前は、JIS X 0160 の呼称と実務での通称が食い違うため、両方を結び付けて覚えます。検証（verification）は「決めた仕様どおりに作れているか」、妥当性確認（validation）は「利用者の本来の目的に合っているか」で、対象が違います。仕様どおりでも業務で使えなければ妥当性確認では不合格です。

2. 要件定義 ― 何を作るかを確定する

要件定義はシステム要件定義とソフトウェア要件定義の 2 段階に分かれ、どちらも「境界の定義 → 要件の定義 → 要件の評価 → 共同レビュー」という同じ 4 つのタスクで進みます。境界の定義とは、利用の状況と運用シナリオをもとに「どこまでをシステムが担い、どこからを人が担うか」を線引きする作業です。ソフトウェア要件定義では業務モデルと論理データモデルを作り、5W2H（Why・When・Where・Who・What・How・How much）の観点で文書化します。

機能要件と非機能要件

機能要件は「業務として何ができるか」、非機能要件は「どれだけの品質・性能・運用しやすさで動くか」です。非機能要件は放置すると後工程で炎上するため、IPA は非機能要求グレードという 6 つの大項目のひな型を公開しています。要件定義の抜けを問う設問はこの 6 分類で整理すると答えやすくなります。

定義した要件は、共同レビューの前に評価基準に照らします。評価の観点は双方向の追跡可能性（トレーサビリティ）、一貫性、テスト可能性、システム設計の実現可能性、運用及び保守の実現可能性です。要件と設計・テストケースの対応表をトレーサビリティマトリクスと呼び、要件の取りこぼしを機械的に検出できるようにします。「取得ニーズとの一貫性が取れているか」を問う設問が H31 春に出ています。

業務分析・要件定義の技法

状態遷移表と状態遷移図

状態遷移表は行が現在の状態、列が事象、セルが遷移先の状態です。同じ仕様を図にしたものが状態遷移図で、試験では「表を渡され、事象を順に適用した後の状態を答える」形で出ます（R3 春 問 47）。音楽プレーヤの例で追ってみます。

決定表は条件の組合せを列（規則）にした表です。条件部に Y／N、動作部に X（実行する）／−（実行しない）を書き、条件が n 個なら規則は最大 2 の n 乗列になります。列が埋まっていない箇所が仕様の抜けです。

3. 設計 ― 要件を構造に落とす

設計は 3 段階で粒度を落としていきます。システム設計（システム方式設計）でハードウェア・ソフトウェア・サービス・手作業への振り分けを決め、ソフトウェア方式設計でソフトウェア要素とその間のインタフェースを決め、ソフトウェア詳細設計でソフトウェアユニット（プログラム）の仕様まで落とします。「最上位の設計を行うのはどの下位プロセスか」を問う設問は、この並びの 2 段目を答えさせるものです。

システム処理方式とアーキテクチャ

Web アプリのインタフェース設計では、資源を URI で表し、HTTP メソッド（GET・POST・PUT・DELETE）で操作を表すREST の考え方が基本になります。API 設計では、資源の単位・応答形式（JSON）・エラー時の状態コード・バージョニングを決めます。画面や帳票のレイアウト設計、UX デザインの詳細は第 8 章が扱います。

設計手法の系統

部品化と再利用では、内部構造を見せて改変できるホワイトボックス型と、インタフェースだけを公開するブラックボックス型を区別します。既存資産をそのまま使いつつ外側に新しいインタフェースを被せる手法がレガシーラッピング、市販の既製品を購入して使う方針が COTS（Commercial Off-The-Shelf）です。設計上のよくある問題と解法の定石をまとめたものがデザインパターンで、GoF の 23 パターンは生成・構造・振舞いの 3 分類に整理されています。

JIS X 25010 の品質特性

要件定義と設計で「どの品質をどこまで作り込むか」を決める共通のものさしが JIS X 25010 です。製品品質モデルは 8 特性、利用時の品質モデルは 5 特性で、目標値の例からどの特性かを当てさせる形で出ます。

4. モジュール分割 ― 結合度と強度

この節が本章で最も出る領域です。直近 10 年 19 回のうち結合度・強度は 5 問出ており、R4 春・R5 春・R6 春は 3 回連続で春の問 46 に置かれました。まず分割の技法、次に分割の良し悪しを測る 2 つのものさし（結合度と強度）という順で押さえます。

モジュール分割技法

結合度と強度 ― 独立性を測る 2 つのものさし

良いモジュール分割とは独立性が高いこと、つまり結合度が低く、強度（結束性）が高いことです。結合度はモジュール間の依存の強さ、強度は 1 つのモジュール内部のまとまりの良さを表します。名前と順序だけでなく、「何をどう受け渡すか」で判定できるようにしておきます。

強度の側も同じ要領で、「1 つのモジュールが何を理由にまとまっているか」で判定します。単一の機能のためなら機能的強度、同じデータ構造を扱う複数の機能をまとめて内部データを隠蔽していれば情報的強度、初期化処理のように「同じタイミングで実行する」だけの理由で集めていれば時間的強度、引数のフラグで似た機能を選ばせていれば論理的強度です。

分割の量も評価対象です。モジュールが直接・間接に呼び出す範囲を制御領域、そのモジュールの変更が影響を及ぼす範囲を影響領域と呼び、影響領域が制御領域の中に収まっている分割が望ましいとされます。モジュール仕様の記述には、流れ図のほか NS 図（Nassi-Shneiderman 図）、PAD（Problem Analysis Diagram）、HCP チャート、PSD（Program Structure Diagram）、DSD（Design Structure Diagram）、SPD（Structured Programming Diagrams）、決定表が使われます。

5. オブジェクト指向設計と UML

オブジェクト指向はデータ（属性）と操作（メソッド）を 1 つのクラスにまとめ、外部には必要な操作だけを見せるという考え方です。科目 A では直近 10 年で 3 問、科目 B ではクラス図を読ませる問題が直近 5 回のうち 3 回出ており、この節は両方の土台になります。

設計原則としてはSOLID（単一責任・開放閉鎖・リスコフの置換・インタフェース分離・依存性逆転の 5 原則）が用語例に挙がっています。名称と「1 クラスの責任は 1 つ」「拡張には開き、修正には閉じる」という趣旨を押さえておけば足ります。

UML の図の種類

UML の図は構造図（静的に何でできているか）と振る舞い図（動的にどう動くか）の 2 系統に分かれます。試験では図名の入れ替えが定番の誤答肢なので、まず系統で切り分けます。

クラス間の関係と多重度

クラス図で最も問われるのが関係の種類です。汎化は「〜の一種（is-a）」、集約は「〜を持つ（has-a）」で部分が単独でも存在できる、コンポジションは集約のうち全体と部分の生存期間が一致するものです。多重度は関連の線の両端に書き、1（ちょうど 1）、0..*（0 個以上）、1..*（1 個以上）を読み分けます。

6. 実装とテスト ― 網羅基準とテストケース設計

実装・構築の作法

実装工程は「ソフトウェアユニットの作成 → テスト手順とテストデータの作成 → ユニットのテスト → 利用者用文書類の更新 → コードとテスト結果の評価」というタスクで進みます。品質を人の注意力に頼らないために、規約と道具で機械的に潰すのが基本方針です。

プログラム言語の選択は、処理方式・実行環境・既存資産・技術者の確保しやすさから決めます。手続型のほかに、宣言的に規則を書く論理型プログラミング、複数の処理を同時に走らせる並列処理プログラミング、ログ出力のような横断的関心事を本体から切り離して書くアスペクト指向プログラミングがあります。2 人 1 組で 1 つのコードを書くペアプログラミングは、書きながらレビューする効果を狙ったプラクティスです（XP のプラクティスとしての位置づけは第 14 章）。

テストの階層

テストは小さい単位から大きい単位へ積み上げます。どの工程の誤りを拾うテストかは、図 13-1 の V 字の対応で決まります。

ホワイトボックステスト ― 網羅基準

ホワイトボックステストは内部の制御構造を見てテストケースを作ります。どこまで通せば十分とするかの基準が網羅基準で、直近 10 年で 5 問と本章の最頻出テーマの 1 つです。同じ判定文に対して 4 つの基準が何ケースを要求するかを、1 枚で比較します。

網羅の達成度は網羅率（カバレージ）で測ります。C0 が 100% でも C1 が 100% とは限らない、というのが計算問題の急所です。

ブラックボックステスト ― 入力と出力だけで作る

ブラックボックステストは内部構造を見ず、仕様上の入力と期待する出力だけでテストケースを作ります。結合テスト以降の主役です。

結合テストの統合順序 ― スタブとドライバ

ユニットを組み上げるとき、まだできていない相手の代わりに仮のモジュールを用意します。呼ばれる側（下位）の代わりがスタブ、呼ぶ側（上位）の代わりがドライバです。上から組むトップダウンテストではスタブ、下から組むボトムアップテストではドライバが必要になります。

システム検証テストの種類

テストの実行は自動化して回帰テストを毎回流せるようにするのが定石です。テストデータジェネレーター、シミュレーター、テストベッド（試験環境）といった道具が用語例に挙がっています。継続的インテグレーション（CI）による自動実行は第 14 章が扱います。

7. 品質評価とレビュー

作ったものが十分な品質かは、レビューという人の目と、メトリクスという数字の 2 系統で判断します。どちらも科目 A・科目 B の両方で問われます。

レビュー技法

レビューの目的はその工程の中で問題点を発見し、後工程へ持ち出さないことです。技法は「誰が進行し、どこまで公式に記録するか」で区別します。

インスペクションの役割は、モデレーター（計画・進行・是正の確認）、作成者、読み手（成果物を読み上げる）、記録係、レビューアに分かれます。集合の場では欠陥の指摘までを行い、修正方法の議論はしないのが原則です。修正の議論を始めると時間が発散し、指摘の網羅性が落ちるためで、科目 B（R4 秋）でこの原則が問われました。修正によって新たに生まれる欠陥を二次欠陥と呼び、修正後の再レビューと回帰テストで拾います。

品質メトリクスとバグ収束の判定

8. 導入・受入れ・保守・廃棄

導入と移行

導入では、実環境への設置と新旧システムの切替えをどう行うかを導入計画にまとめます。移行方式の選択は「業務を止められる時間」と「二重運用のコスト」のトレードオフです。

リリースの方式としては、本番と同構成の環境を 2 つ用意して切り替えるブルーグリーンデプロイメント（R7 春に出題）、一部の利用者にだけ新版を出して様子を見るカナリアリリースがあります。どちらも切戻しを容易にする狙いです。移行前には移行リハーサルを行い、手順と所要時間を実測します。

受入れ支援と教育訓練

供給者は取得者の受入れレビューと受入れテストを支援します。合否は受入れ基準（検収基準）に照らして判定し、結果を文書化します。利用者用文書類（利用者マニュアル）は設計時に暫定版を作り、開発の進行に合わせて更新します。ウィザード・チュートリアル・オンラインヘルプのようにソフトウェアに組み込む組込文書類と、冊子として分ける分離形文書類があります。教育訓練の効果測定には、反応・学習・行動・結果の 4 段階で測るカークパトリックの教育効果の 4 段階モデルが用語例に挙がっています。

保守と廃棄

保守は何をきっかけに、何のために直すかで 4 つに分類します。この分類は直近 10 年で 2 問出ており、リバースエンジニアリングによる文書再作成がどれに当たるかが定番の論点です。

既存のソースコードや実行モジュールを解析して設計仕様を復元する作業がリバースエンジニアリングです。復元した仕様をもとに作り直すのがリエンジニアリング、別のプラットフォームへ移し替えるのがマイグレーションです。リファクタリングは外部から見た振る舞いを変えずに内部構造だけを改善する作業で、変更前後で結果が変わらないことを回帰テストで担保します。

保守の手順は、開発から成果物を引き継ぐ準備 → 問題報告・修正依頼の分析 → 修正の実施 → 保守レビューと受入れ → 再発防止策 → 移行、と進みます。再発防止では FTA・FMEA・STAMP/STPA などの解析技法で根本原因を洗い出します。廃棄では、廃棄計画を立てて利用者へ通知し、新旧の並行運用と教育訓練を経て旧環境を停止します。廃棄後もデータの保持とアクセス可能性を確保しておく点が用語例に挙げられています。

出題頻度は低いが 1 行で押さえる用語

ひっかけポイント

理解度チェック（科目 A 形式）

まとめ

本章は工程・技法・数値の対応を覚える章でした。次の第 14 章では、これらの工程をどの順序でどう回すか（ウォーターフォール・アジャイル・DevOps）と、成果物をどう管理するか（構成管理・バージョン管理・知的財産）を扱います。V 字の各工程を短いサイクルで何度も回すのがアジャイルだと捉えると、両章がつながります。