基本情報技術者 2009年 秋期 午前(科目A) 問47
問題文
開発プロセスにおける、ソフトウェア方式設計で行うべき作業はどれか。
選択肢
ア:顧客に意見を求めて仕様を決定する。
イ:既に決定しているソフトウェア要件を、どのように実現させるかを決める。(正解)
ウ:プログラム1行ごとの処理まで明確になるように詳細化する。
エ:要求内容を図表などの形式でまとめ、段階的に詳細化して分析する。
開発プロセスにおける、ソフトウェア方式設計で行うべき作業はどれか。【午前2 解説】
要点まとめ
- 結論: ソフトウェア方式設計は、ソフトウェア要件をどのように実現するかを決める高水準設計であり、モジュール分割やインタフェース設計、技術選定を含みます。
- 根拠: 開発プロセスは要件定義→方式設計→詳細設計→実装に分かれ、方式設計は実現方針や構成を決定する段階に相当します。
- 差がつくポイント: 「プログラム1行ごとの処理」は詳細設計の範囲で、要求を図表にまとめる作業は要件定義側であり、段階を混同しないことが重要です。
正解の理由
正解は イ です。方式設計は「既に決定しているソフトウェア要件を、どのように実現させるかを決める」作業に該当します。具体的にはシステムをどのようなモジュールやコンポーネントに分割するか、各コンポーネント間のインタフェース、データの流れ、利用する技術やミドルウェアなどの設計方針を定めます。これは要件を実装可能な構造に落とし込む高水準の設計工程であり、選択肢イの記述と一致します。
よくある誤解
方式設計を「詳細設計」と混同して、処理手順やプログラムの行単位まで詰めようとする誤りが多いです。要求整理や図表化は要件定義寄りの作業であり、方式設計単独の作業ではありません。
解法ステップ
- 選択肢のキーワードに注目し、「方式設計」「詳細化」「要求まとめ」などの語を抽出する。
- 開発工程の一般的な流れ(要件定義→方式設計→詳細設計→実装)を思い出す。
- 各選択肢がどの工程に該当するかを対応付ける(要件定義・方式設計・詳細設計)。
- 「どのように実現するか」を扱うものが方式設計であると判断する。
- 該当する選択肢(イ)を正解とする。
選択肢別の誤答解説
- ア: 顧客に意見を求めて仕様を決定する。
→ これは主に要件定義や要求定義のフェーズで行う作業であり、方式設計の直接の役割ではありません。 - イ: 既に決定しているソフトウェア要件を、どのように実現させるかを決める。
→ 正解。方式設計(アーキテクチャ設計や基本設計とも)に該当し、構成やインタフェース、技術方針を決定します。 - ウ: プログラム1行ごとの処理まで明確になるように詳細化する。
→ これは詳細設計(プログラム設計、コーディング前の細部仕様)に該当し、方式設計の後続工程です。 - エ: 要求内容を図表などの形式でまとめ、段階的に詳細化して分析する。
→ これは要求定義や要件分析の説明であり、方式設計ではなく上流工程の作業です。
補足コラム
方式設計は「基本設計」「アーキテクチャ設計」とも呼ばれることが多く、成果物としてはモジュール構成図、コンポーネント間のインタフェース仕様、非機能要件の設計方針(パフォーマンス、可用性、セキュリティ)、技術選定リストなどが含まれます。詳細設計ではこれらを基にクラス設計やアルゴリズム設計、データベースの物理設計やプログラム単位の処理仕様を作成します。方式設計で粒度と境界を明確にしておくと、後工程での手戻りを減らせます。
FAQ
Q: 方式設計と基本設計は同じですか?
A: 多くの場合ほぼ同義で使われます。組織によって用語の範囲は異なりますが、どちらも高水準での構成と実現方針を決める工程です。
A: 多くの場合ほぼ同義で使われます。組織によって用語の範囲は異なりますが、どちらも高水準での構成と実現方針を決める工程です。
Q: 非機能要求の検討は方式設計で行いますか?
A: はい。性能、可用性、セキュリティなどの非機能要件は方式設計で考慮し、アーキテクチャや技術選定に反映させます。
A: はい。性能、可用性、セキュリティなどの非機能要件は方式設計で考慮し、アーキテクチャや技術選定に反映させます。
Q: 要求を図表にまとめる作業はどの段階ですか?
A: 主に要件定義・要件分析の段階で行います。方式設計では、既に明確になった要件を実現するための設計へ移ります。
A: 主に要件定義・要件分析の段階で行います。方式設計では、既に明確になった要件を実現するための設計へ移ります。
関連キーワード: 方式設計、アーキテクチャ設計、基本設計、詳細設計、要件定義、非機能要件、モジュール分割、インタフェース設計

\ せっかくなら /
基本情報技術者を
クイズ形式で学習しませんか?
クイズ画面へ遷移する→
すぐに利用可能!

