変更要約: 初版（第5章・s1-s5）
5.1システム開発技術
ソフトウェア開発プロセス（要件定義・外部設計・内部設計・実装・テスト・運用）の流れと、モジュール分割（強度・結合度）、オブジェクト指向設計とUML、テスト技法（ホワイトボックステスト・ブラックボックステスト・網羅基準）、レビュー（インスペクション・ウォークスルー）を学びます。
システム開発は「何を作るか」を決める上流工程から「正しく動くか」を確かめる下流工程まで、段階を踏んで進みます。各工程で何を確定させるかと、設計・実装の質を高める技法（分割の指針、テストの網羅基準、レビュー）を対応づけて理解することが、応用情報につながる実務理解の土台になります。
5.1.1開発プロセスと設計の階層
- 要件定義＝利用者・発注者の業務要求を明確化し、システムが何を実現すべきかを定義する工程。ここで確定した要件は以降の全工程の基準になり、後工程での要件変更ほど手戻りコストが大きくなります。
- 外部設計（基本設計）＝利用者から見える画面・帳票・インタフェースを設計する工程。内部設計（詳細設計）＝外部設計を実現するための内部構造・モジュール分割・データ構造をプログラマ視点で設計する工程。外部設計は「利用者が見るもの」、内部設計は「開発者が実装するもの」という視点の違いを区別します。
- モジュール分割＝プログラムを機能単位に分割する設計技法。分割の質はモジュール強度（1つのモジュール内の処理のまとまりの強さ、高いほど良い）とモジュール結合度（モジュール間の依存の強さ、低いほど良い）の2軸で評価します。「強度は高く・結合度は低く」が良い設計の指針です。
5.1.2オブジェクト指向設計とUML
- オブジェクト指向設計＝データと処理を1つのオブジェクト（クラス）にまとめ、カプセル化（内部実装の隠蔽）・継承（既存クラスの性質の再利用）・多態性（ポリモーフィズム）（同じ呼び出しで異なる振る舞いを実現）を活用して部品化・再利用性を高める設計手法。
- UML（統一モデリング言語）＝オブジェクト指向設計を図で表す標準記法。代表的な図に、クラス間の静的関係を表すクラス図、オブジェクト間のメッセージのやり取りを時系列で表すシーケンス図、利用者から見た機能を表すユースケース図、状態の遷移を表す状態遷移図があります。用途に応じて図の種類を使い分けます。
「モジュール強度は高いほど良い・モジュール結合度は低いほど良い」「外部設計＝利用者が見るもの／内部設計＝開発者が実装するもの」「クラス図＝静的関係、シーケンス図＝時系列のメッセージ、ユースケース図＝利用者視点の機能」が最頻出です。強度と結合度の方向（どちらが高い/低いのが良いか）の取り違えが典型的な誤答パターンとして繰り返し出ます。
5.1.3テスト技法と網羅基準
- ホワイトボックステスト＝プログラムの内部構造（論理・分岐）に着目し、コードのパスを網羅するようにテストケースを設計する技法。網羅基準には、全命令を最低1回通す命令網羅（C0）、全分岐の真偽を最低1回通す分岐網羅（C1）、条件式内の各条件の真偽を全て網羅する条件網羅（C2）があり、C0が最も緩く、条件を組み合わせた網羅ほど厳しくなります。
- ブラックボックステスト＝プログラムの内部構造を見ずに、入力と出力の関係からテストケースを設計する技法。代表的手法に、入力を有効/無効な範囲（同値クラス）に分けて各クラスから代表値を選ぶ同値分割、範囲の境界値付近（境界そのもの・境界の直前直後）を重点的に検証する限界値分析（境界値分析）があります。境界値分析は境界での誤り（off-by-oneなど）を検出しやすいのが利点です。
- レビュー＝コードやドキュメントを人手で検証し欠陥を早期発見する手法。インスペクション＝あらかじめ定めた役割（モデレータ等）と手順に従う最も形式的で厳格なレビュー。ウォークスルー＝作成者が進行役となり参加者に説明しながら比較的インフォーマルに検証する手法。上流工程でのレビューほど手戻りコストの抑制効果が大きいとされます。
設計とテストのつながりを、ある注文金額計算モジュールの開発を例に追ってみます。まず内部設計で「割引率の判定と合計金額の計算」という1つのまとまった処理だけを担当するモジュールに切り出せば、モジュール強度は高くなります。逆に、このモジュールが他のモジュールの内部変数を直接書き換えるような作りにしてしまうと結合度が高くなり、片方の修正がもう片方に予期せぬ影響を及ぼしやすくなります。実装後のテスト設計では、まずホワイトボックステストの観点で「割引率が10%・20%・0%のいずれの分岐も最低1回は通るか」を分岐網羅（C1）で確認します。次にブラックボックステストの観点で、金額に応じた割引率が「1万円未満は0%・1万円以上5万円未満は10%・5万円以上は20%」と定義されているなら、境界値分析により9999円・10000円・49999円・50000円といった境界付近の値を重点的にテストします。ここで仮に「10000円ちょうど」が意図せず0%側の判定になっていた、というような境界の誤り（off-by-one）は、代表値だけを選ぶ同値分割では見逃しやすく、境界値分析でこそ検出しやすいという関係を理解しておくと、テスト技法の使い分けが実務でも試験でも役立ちます。最後に、このロジックをコードレビューに出す場合、リリース直前の軽い確認ならウォークスルーで十分ですが、金額計算という誤りの影響が大きい重要ロジックであれば、モデレータを立てて手順に従うインスペクションの方が欠陥の早期検出に適しています。
| 技法 | 着眼点 | 代表手法 |
|---|---|---|
| ホワイトボックステスト | 内部構造（論理・分岐） | 命令網羅(C0)/分岐網羅(C1)/条件網羅(C2) |
| ブラックボックステスト | 入力と出力の関係 | 同値分割・限界値分析 |
| インスペクション | 形式的・厳格な手順 | モデレータを立てて実施 |
| ウォークスルー | 比較的インフォーマル | 作成者が進行役 |
ひっかけ： 「モジュール結合度は高いほど良い設計である」は誤りです。良い設計の指針は結合度は低く・強度は高くの逆です。また「同値分割を行えば境界付近の誤りも十分検出できる」も誤り＝同値分割は代表値を選ぶ手法のため境界の誤りは見逃しやすく、境界値分析の方が適しています。さらに「命令網羅（C0）を満たせば条件網羅（C2）も自動的に満たされる」も誤り＝網羅基準には強弱があり、C0を満たしてもC1・C2までカバーしているとは限りません。
5.1.4この節のまとめ
- 開発プロセス＝要件定義→外部設計（利用者視点）→内部設計（開発者視点）→実装→テスト→運用。モジュール強度は高く・結合度は低くが良い設計
- UMLはクラス図（静的関係）・シーケンス図（時系列メッセージ）・ユースケース図（利用者視点）などを使い分け
- ホワイトボックステストは内部構造（命令網羅/分岐網羅/条件網羅）、ブラックボックステストは入出力（同値分割/限界値分析）に着目。インスペクションが最も形式的、ウォークスルーは比較的インフォーマル
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. あるモジュールの設計を見直したところ、金額計算・在庫更新・メール送信という無関係な複数の処理が1つのモジュールに詰め込まれていた。この状態を改善する方向として最も適切なのは？
Q2. 割引率が「1万円未満は0%、1万円以上は10%」と定義されたロジックのテストで、10000円ちょうどの金額が誤って0%側と判定される欠陥が疑われる。この欠陥を検出する可能性が最も高いテスト技法は？
Q3. 金額計算という誤りの影響が大きい重要ロジックのレビューを行うことになった。欠陥の早期発見を重視し、形式的な手順とモデレータを伴う厳格なレビュー方式を選びたい。最も適切なのは？