問31
頻出度★★☆
システムが実現すべき応答時間などのシステムの品質を明確にする工程として, 適切なものはどれか。
平成25年度 秋期 ITパスポート試験 問31
ストラテジ系システム企画 › 要件定義
この問題の解説と、これまでの解答の記録です。
解説
問 31
不正解ア
システムテストは、開発したシステム全体が要件定義で定めた内容を満たしているかを、本番に近い環境で確認する工程である。応答時間についても、要件として定めた目標値を満たすかどうかを性能テストで測定・検証するが、それは「すでに明確になっている品質水準」を判定基準として使う立場であって、品質水準そのものをここで決めるわけではない。要件を明確にする工程 (入口) と、要件を満たしたか確かめる工程 (出口) を取り違えた選択肢である。
- イ
正解 正解はイ「システム要件定義」。システム開発は、企画 → 要件定義 → 設計 → プログラミング → テスト → 導入・運用という順に進み、「何を作るか」を決めるのが要件定義、「どう作るか」を決めるのが設計以降である。要件定義で扱う要件は大きく2種類あり、システムが提供する機能そのもの (どんな処理・データを扱うか) を定める機能要件と、その機能をどの程度の水準で実現するかを定める非機能要件に分かれる。設問の応答時間は、後者の非機能要件の代表例で、ほかに処理件数などの性能、稼働率・障害復旧時間などの可用性、セキュリティ、拡張性、運用・保守のしやすさなどが含まれる。これらのシステムに求める品質水準は、開発の入口であるシステム要件定義の工程で、利用者・発注側と開発側が合意して明確にしておく必要がある。ここで数値目標として文書化しておかないと、後工程の設計で必要な性能を確保できず、テスト時に合否の判断基準も持てないため、手戻りの原因になる。したがって、応答時間などのシステムの品質を明確にする工程はシステム要件定義である。
不正解ウ
ソフトウェア詳細設計は、要件定義とシステム方式設計で決まった内容を受けて、プログラムの内部構造 (モジュールの分割、処理手順、データ構造、入出力の詳細など) をプログラミングできる粒度まで具体化する工程である。応答時間の目標を達成するためにアルゴリズムやデータの持ち方を工夫することはあっても、それは与えられた目標値を実現する手段の検討であり、目標値そのものを定める工程ではない。要件は詳細設計の入力としてすでに確定している前提である。
不正解エ
プログラミングは、詳細設計の内容に基づいてプログラム言語でコードを記述し、単体テストで動作を確認する工程である。ここで行うのは設計どおりに動くものを作る作業であり、システムに求める品質水準を決める場面ではない。要件定義から最も遠い実装段階の工程であり、この段階で応答時間の目標を決め始めるようでは、要件を満たさない設計のまま実装が進んでしまい大きな手戻りになる。
ここがポイント
- 要件定義は「何を作るか」を決める工程で、要件は機能要件と非機能要件に分かれる。機能要件はシステムが備えるべき機能・処理・データの内容、非機能要件は応答時間や処理件数などの性能、稼働率などの可用性、セキュリティ、拡張性、運用・保守性といった品質面の要求で、いずれもシステム要件定義で明確にし、できるだけ数値で合意しておく。
- システム開発の工程は、企画 → 要件定義 (業務要件定義・システム要件定義) → システム方式設計・ソフトウェア設計 (基本設計・詳細設計) → プログラミング → テスト (単体・結合・システム・運用) → 導入・運用の順に進む。要件定義は開発の入口で「決める」工程、テストは出口で要件を満たしたか「確かめる」工程、設計・プログラミングはその間で要件を実現する手段を具体化する工程という役割の違いを押さえる。
用語