第 13 章 システム開発技術
要件からテストまで。この章では次の 15 個の知識点を、解説・インタラクティブ教材・練習問題で学びます。
共通フレームとシステム開発の流れ
企業がシステムを作るときは、自社（ユーザ企業）が、システム開発会社（ベンダ企業）に開発を依頼することが多い。両者が同じ言葉で話せるように、ソフトウェア開発の工程や作業内容・作業範囲を定義したガイドラインが共通フレーム。流れは 企画 → 要件定義 → 開発 → 運用 → 保守 の 5 つのプロセス。企画では、ニーズや課題を確かめてシステム化構想を立て、具体的なシステム化計画にまとめる。
RFI と RFP
ユーザ企業が開発を任せるベンダ企業を選ぶときに使う文書が 2 つある。RFI（Request For Information：情報提供依頼書）は、ベンダが持つ製品・サービスや技術などの一般的な情報の提供を求める文書で、候補を絞る一次審査にあたる。RFP（Request For Proposal：提案依頼書）は、システムの要件などを示して、具体的なシステム提案を求める文書で、二次審査にあたる。提案を比べてベンダを選定し、契約を結ぶ。
ソフトウェア開発工程と V 字モデル
要件定義 → 外部設計（基本設計）→ 内部設計（詳細設計）→ コーディング と進め、テストは逆の順に 単体 → 結合 → 総合 → 受入 と進める。設計の各工程と、それを確かめるテストが対応しているのが V字モデル。要件定義では、業務で必要な機能要件と、性能・セキュリティ・開発標準など機能以外の非機能要件を定める。
レビュー手法
各工程の終わりに成果物（設計書など）を確認するのがレビュー。誤りを早い段階で見つけるほど、直すコストが小さい。ウォークスルー：作成者が関係者に内容を説明しながら確認する。インスペクション：モデレータ（進行役）が主導し、参加者の役割を決めて正式に検査する。ラウンドロビン：参加者全員が持ち回りで責任者になって進める。
EA（エンタープライズアーキテクチャ）
EA は、個々のシステムをばらばらに最適化するのではなく、企業全体で最適化するために、業務とシステムを 4 つの体系で整理する手法。ビジネス（業務内容・業務プロセス）・データ（必要なデータと関連）・アプリケーション（データを処理するシステムの機能）・テクノロジ（技術的な構成要素）。
開発手法（ウォーターフォール・アジャイル・プロトタイピングなど）
ウォーターフォールモデル：工程を上流から順番に進める（計画しやすいが、途中の変更に弱い）。アジャイル：短いサイクルを繰り返して機能ごとにリリースする（変更に強い）。代表的な手法が XP（ペアプログラミング・リファクタリング・テスト駆動開発）と スクラム（スプリント・デイリースクラム）。プロトタイピングモデル：試作品で利用者に確認してもらう。リバースエンジニアリング：既存のソフトウェアを解析して仕様を明らかにする。ほかに DevOps、ドメイン駆動設計（業務知識を軸に設計）。
業務モデル（E-R 図と DFD）
要件定義の前に、利用者の業務を聞き取って図にする（業務モデル）。E-R図：管理の対象（エンティティ）と、エンティティどうしの関係（リレーションシップ：1 対 1・1 対多・多対多）を表す。データベース設計で使う。DFD：データの流れを、データフロー（→）・プロセス（○）・データストア（＝）・源泉と吸収（□）の 4 つの記号で表す。
UI 設計と GUI 部品
インタフェース設計には、画面の項目や操作方法を決める画面設計と、帳票（伝票など）の印刷レイアウトを決める帳票設計がある。画面は「関連項目を近くに」「ボタンの位置や形をそろえる」「入力は左上から右下へ流れるように」配置する。GUI 部品：ラジオボタン（排他的に 1 つ）・チェックボックス（それぞれ選ぶ／選ばない）・プルダウンメニュー（一覧から 1 つ）・コンボボックス（一覧から選ぶか入力）・トグルボタン（ON／OFF）。操作方式には CUI・GUI・NUI がある。
UI / UX デザイン
UI は利用者と製品の接点（画面・ボタンなど）、UX は製品やサービスを通じて得られる体験。人とコンピュータのやり取りを設計するインタラクションデザインの 4 原則：① 説明がなくても操作できる ② 操作しやすい配置 ③ レスポンスの時間が適切 ④ デザインに一貫性。画面の大きさに合わせてレイアウトを最適化するレスポンシブデザインは UX を高める。
モジュール分割と結合度
システムを機能ごとのモジュールに分けると、並行して開発でき、再利用でき、問題があっても一部の修正で済む。良いモジュールは独立性が高い（他への影響が少ない）。モジュール同士のつながりの強さがモジュール結合度で、弱いほど良い：データ結合 ＜ スタンプ結合 ＜ 制御結合 ＜ 外部結合 ＜ 共通結合 ＜ 内容結合。
モジュール強度
1 つのモジュールの中の機能のまとまりの強さがモジュール強度で、強いほど良い：機能的強度 ＞ 情報的強度 ＞ 連絡的強度 ＞ 手順的強度 ＞ 時間的強度 ＞ 論理的強度 ＞ 暗号的強度。良いモジュールは「結合度は弱く、強度は強く」。
テストとバグ（信頼度成長曲線・バグ管理図）
テストの目的はバグを見つけて直すこと。信頼度成長曲線（バグ曲線）は、テスト項目数（時間）に対する累積バグ件数のグラフで、最初は少なく、途中で急に増え、最後は頭打ちになる S 字が理想。バグ管理図では、バグ検出数・未解決バグ数・未消化テスト項目数の推移を見て、テストの進み具合と品質を判断する。
単体テスト（ブラックボックスとホワイトボックス）
ブラックボックステストは内部を見ずに入力と出力だけで確かめる。テストケースは、境目の値を選ぶ限界値分析や、グループごとに代表値を選ぶ同値分割で作る。ホワイトボックステストは内部構造に注目し、網羅の基準は弱い順に 命令網羅（全命令を 1 回）・判定条件網羅（分岐の Yes／No を 1 回ずつ）・条件網羅（各条件の真偽を 1 回ずつ）・複数条件網羅（条件の真偽の組合せをすべて）。
結合テスト（スタブとドライバ）
単体テストが終わったモジュールを組み合わせて確かめるのが結合テスト。上位から順に結合するトップダウンテストでは、まだできていない下位モジュールの代わりにスタブ（呼び出される側の仮モジュール）を使う。下位から順に結合するボトムアップテストでは、まだできていない上位モジュールの代わりにドライバ（呼び出す側の仮モジュール）を使う。
総合テスト・受入テスト・リグレッションテスト
総合テスト（システムテスト）は、本番とほぼ同じ環境で、開発者がシステム全体を確かめる：機能テスト・性能テスト・負荷テスト・セキュリティテスト・ユーザビリティテストなど。受入テストは、利用者が業務で使える状態かを確かめて、受け入れるかどうかを判断する。リグレッションテスト（回帰テスト）は、修正や変更によって他の部分に不具合が出ていないかを確かめる。