平成23年度秋期 情報処理安全確保支援士 午前Ⅰ 問15

システム開発の第一歩！「ユーザー（アクター）」と「システムができること（ユースケース）」の境界線をハッキリさせる

UMLの「ユースケース図」に関する問題だよ。システムの内部のプログラムコードやデータベース設計のような難しい話ではなく、システムの外側にいる「アクター（人間や別の外部システム）」が、システムを使って「どんな業務を行いたいか（ユースケース）」を楕円と線でシンプルにつないで示す図だよ。これによって、開発範囲（システムの境界）を顧客と開発者でカンタンに合意できるんだ。

この問題で問われていること

クラス間のデータ構造を表すクラス図や、業務の流れを示すアクティビティ図とは区別し、「システムが提供すべき機能（ユースケース）と、外部の利用者（アクター）との関係をビジュアルで表現する」ユースケース図の主な目的を選択しよう。

Use Case Diagram

a use case diagram organizes system requirements by showing actors and the functions they use

actors\nfunctions\nexternal viewpoint

確認ポイント

• 内部構造図ではありません。
• 利用者視点で表す。
• ユースケース図を選ぶ。

正解

ア

出典

問題文と解答は IPA 公開の過去問題冊子・解答例を基にしています。

選択肢ア（正解）

不正解だよ。実データを無作為に拾うのは、くじ引きで確認する場所を決めるようなものなんだ。たまたま大事な条件を見逃すかもしれないよね。ブラックボックステストでは、仕様書をもとに『この入力ならこの結果』と狙ってテストを作るのが基本だよ。

選択肢イ

不正解だよ。使用頻度が高いデータを重点的に見るのは、よく来るお客さんの対応だけを確認するようなものだよ。実務では役立つ考え方だけど、ブラックボックステストの本質は『仕様で決まっている機能や条件を外から確認すること』なので、この説明だけでは適切とはいえないんだ。

選択肢ウ

正解だよ。ブラックボックステストは、中身の配線を開けて見るのではなく、『外から見て何ができるべきか』で確認する方法なんだ。お店の窓口で、裏の事務処理を知らなくても『この手続きを頼んだら、この結果が返るはず』と確認する感じだね。仕様書を見て機能からテストケースを作るので、この説明がぴったりだよ。

選択肢エ

不正解だよ。プログラムの全命令を少なくとも1回実行するようにするのは、中の通路を全部歩いて点検するような方法で、ホワイトボックステストの考え方だよ。ブラックボックステストは中身の命令ではなく、外から見える機能や結果を仕様書ベースで確認するんだ。