ホーム > システムアーキテクト試験 > 2018年
システムアーキテクト試験 2018年 午前2 問12
共通フレーム2013において、システム適格性確認テストで適合を評価する対象となるのは、どのアクティビティで定義又は設計した内容か。
ア：システム方式設計
イ：システム要件定義（正解）
ウ：ソフトウェア方式設計
エ：ソフトウェア要件定義
解説
共通フレーム2013 システム適格性確認テストの評価対象【午前2 解説】
要点まとめ
- 結論：システム適格性確認テストは「システム要件定義」で定義した内容の適合を評価します。
- 根拠：共通フレーム2013では、システム適格性確認テストはシステム全体の要件が満たされているかを検証する工程だからです。
- 差がつくポイント：システム要件定義と方式設計の違いを正確に理解し、テストの目的に合致する工程を選ぶことが重要です。
正解の理由
システム適格性確認テストは、システム全体の要件が正しく実現されているかを確認するテストです。
このため、評価対象は「システム要件定義」で定義された内容となります。
方式設計は要件を実現するための設計段階であり、テストの評価対象としては上位の要件定義が基準となるため、正解はイです。
このため、評価対象は「システム要件定義」で定義された内容となります。
方式設計は要件を実現するための設計段階であり、テストの評価対象としては上位の要件定義が基準となるため、正解はイです。
よくある誤解
方式設計の内容を評価対象と誤解しやすいですが、適格性確認テストは設計ではなく要件の適合性を評価します。
また、ソフトウェア単体の要件や設計ではなく、システム全体の要件に着目する点も混同しやすいポイントです。
また、ソフトウェア単体の要件や設計ではなく、システム全体の要件に着目する点も混同しやすいポイントです。
解法ステップ
- 問題文の「システム適格性確認テスト」の目的を確認する。
- 共通フレーム2013の定義で、適格性確認テストがどの工程の成果物を評価するかを思い出す。
- システム要件定義はシステム全体の要求事項をまとめる工程であることを理解する。
- 方式設計は要件を実現するための設計であり、テストの評価対象ではないと判断する。
- 選択肢の中から「システム要件定義」を選ぶ。
選択肢別の誤答解説
- ア: システム方式設計
システム方式設計は要件を実現するための設計段階であり、適格性確認テストの評価対象ではありません。 - イ: システム要件定義
システム全体の要件を定義する工程であり、適格性確認テストの評価対象として正解です。 - ウ: ソフトウェア方式設計
ソフトウェア単体の設計であり、システム全体の適合性を評価する適格性確認テストの対象外です。 - エ: ソフトウェア要件定義
ソフトウェア単体の要件定義であり、システム全体の適合性を評価するテストの対象ではありません。
補足コラム
共通フレーム2013では、テスト工程が複数階層に分かれており、単体テストや結合テストはソフトウェアレベルの評価、適格性確認テストはシステム全体の要件適合性を評価します。
この階層構造を理解することが、問題を正確に解く鍵となります。
この階層構造を理解することが、問題を正確に解く鍵となります。
FAQ
Q: システム適格性確認テストと受入テストは同じですか？
A: ほぼ同義で、システム要件に対する適合性を確認するテストを指します。
A: ほぼ同義で、システム要件に対する適合性を確認するテストを指します。
Q: 方式設計の内容はテストで全く評価されないのですか？
A: 方式設計は内部設計の基礎ですが、適格性確認テストでは要件定義に対する適合性が主な評価対象です。
A: 方式設計は内部設計の基礎ですが、適格性確認テストでは要件定義に対する適合性が主な評価対象です。
関連キーワード: 共通フレーム2013, システム適格性確認テスト, システム要件定義, テスト工程, ソフトウェア開発プロセス