平成27年度 秋期 午前Ⅱ システムアーキテクト試験 | 解答一覧

1. ソフトウェア構成品目の明確化

2. ソフトウェアコンポーネントの構成の明確化

3. ソフトウェアのインタフェース仕様の決定

4. ソフトウェアのユニットごとのテスト要求事項の定義

ソフトウェア構成品目の明確化

1.

2.

3.

4.

1. オブジェクト間の相互作用を制御するためのオブジェクト

2. 画面操作や画面表示などのGUIオブジェクト

3. システムの中核となるデータとその操作のオブジェクト

4. データモデルにおけるエンティティに相当するオブジェクト

画面操作や画面表示などのGUIオブジェクト

1. クラスにもたせる役割は一つだけにするべきであり、複数の役割が存在する場合にはクラスを分割する。

2. クラスを利用するクライアントごとに異なるメソッドが必要な場合は、インタフェースを分ける。

3. 上位のモジュールは、下位のモジュールに依存してはならない。

4. モジュールの機能には、追加や変更が可能であり、その影響が他のモジュールに及ばないようにする。

モジュールの機能には、追加や変更が可能であり、その影響が他のモジュールに及ばないようにする。

1.

2.

3.

4.

スポンサー

1. 2相コミット

2. KVS

3. MapReduce

4. マルチスレッド

MapReduce

1. 幾つかのクラスに共通する性質を抽出して、一般化したクラスを定義したものである。

2. 同じ性質をもつオブジェクト群を、更にクラスとして抽象化したものである。

3. オブジェクトの内部にデータを隠蔽し、オブジェクトの仕様と実装を分離したものである。

4. システムの構造や機能について、典型的な設計上の問題とその解決策を示し、再利用できるようにしたものである。

システムの構造や機能について、典型的な設計上の問題とその解決策を示し、再利用できるようにしたものである。

1. 実データからテストデータを無作為に抽出して、テストケースを設計する。

2. 実データのうち使用頻度が高いものを重点的に抽出して、テストケースを設計する。

3. プログラムがどのような機能を果たすのかを仕様書で調べて、テストケースを設計する。

4. プログラムの全命令が少なくとも1回は実行されるように、テストケースを設計する。

プログラムがどのような機能を果たすのかを仕様書で調べて、テストケースを設計する。

1. 1,000

2. 1,500

3. 2,000

4. 2,250

1,000

1.

2.

3.

4.

スポンサー

1. システムが運用環境に適合し、利用者の用途を満足しているかどうかを、実運用環境又は擬似運用環境において評価する。

2. システムが業務運用時に使いやすいかどうかを定期的に評価する。

3. システムの投資効果及び業務効果の実績を評価する。

4. システム要件について実装の適合性をテストし、システムの納入準備ができているかどうかを評価する。

システム要件について実装の適合性をテストし、システムの納入準備ができているかどうかを評価する。

1. a

2. b

3. c

4. d

d

1. コンカレントエンジニアリング

2. ドメインエンジニアリング

3. フォワードエンジニアリング

4. リバースエンジニアリング

ドメインエンジニアリング

1. 経営戦略や情報化戦略などから求められる要求であり、エンタープライズアナリシスの活動で定義している。

2. 新システムへのデータ変換や要員教育などに関する要求であり、ソリューションのアセスメントと妥当性確認の活動で定義している。

3. 組織・業務・システムが実現すべき機能要求と非機能要求であり、要求アナリシスの活動で定義している。

4. 利用部門や運用部門などから個別に発せられるニーズであり、要求アナリシスの活動で定義している。

組織・業務・システムが実現すべき機能要求と非機能要求であり、要求アナリシスの活動で定義している。

1. 現行システムの内容、流れの調査及び課題の分析、抽出

2. システム稼働時期の設定と全体開発スケジュールの作成

3. システム化の対象となる利害関係者の要件の抽出

4. システム実現のための費用と実現時の効果の予測

システム化の対象となる利害関係者の要件の抽出

スポンサー

1. 委託業務の進行中に発生するリスクはベンダが負い、発注者は注文時に合意した価格を支払う。

2. 契約期間が長期にわたる場面などで、インフレ率や特定の商品コストの変化に応じて、あらかじめ取り決められた契約金額を調整する。

3. 注文時に、目標とするコスト、利益、利益配分率、上限を合意し、目標コストと実際に発生したコストの差異に基づいて利益を配分する。

4. ベンダの役務や技術に対する報酬に加え、委託業務の遂行に要した費用の全てをベンダに支払う。

ベンダの役務や技術に対する報酬に加え、委託業務の遂行に要した費用の全てをベンダに支払う。

1. 災害時に代替手段で運用していた業務が、完全に元の状態に戻るまでの時間

2. 災害による業務の停止が深刻な被害とならないために許容される時間

3. 障害発生時のシステム縮退運用を継続することが許容される時間

4. 対策本部の立上げや判定会議の時間を除く、待機系への切替えに要する時間

災害による業務の停止が深刻な被害とならないために許容される時間

1. OSがシステム異常を検出した。

2. ウォッチドッグタイマが最大カウントに達した。

3. システム監視LSIが割込み要求を出した。

4. ユーザプログラムがカーネルの機能を呼び出した。

ユーザプログラムがカーネルの機能を呼び出した。

1. ソフトウェアのバグによるシステム故障のようなソフトウェアフォールトに対処した設計を、フェールソフトと呼ぶ。

2. フェールセーフはフォールトトレランスに含まれるが、フェールソフトは含まれない。

3. フォールトトレランスの例として、システム全体を二重化する方式がある。

4. フォールトトレランスは、システムを多重化することなく、故障の検出から回復までの時間をゼロにすることである。

フォールトトレランスの例として、システム全体を二重化する方式がある。

1.

2.

3.

4.

スポンサー

1. ダイス

2. データクレンジング

3. ドリルダウン

4. ロールアップ

ダイス

1. キャリア信号を検出し、データの送信を制御する。

2. 送信権をもつメッセージ（トークン）を得た端末がデータを送信する。

3. データ送信中に衝突が起こった場合は、直ちに再送を行う。

4. 伝送路が使用中でもデータの送信はできる。

キャリア信号を検出し、データの送信を制御する。

1. 送信者Aは、共通鍵暗号方式の鍵でファイルを暗号化し、鍵と一緒に暗号化ファイルを受信者Bへ送付する。受信者Bは、受信した鍵で暗号化ファイルを復号する。

2. 送信者Aは、公開鍵暗号方式において送信者Aが公開している鍵でファイルを暗号化し、暗号化ファイルを受信者Bへ送付する。受信者Bは、受信者Bが秘密に管理している鍵で暗号化ファイルを復号する。

3. 送信者Aは、公開鍵暗号方式において送信者Aが秘密に管理している鍵でファイルを暗号化し、暗号化ファイルを受信者Bへ送付する。受信者Bは、送信者Aが公開している鍵で暗号化ファイルを復号する。

4. 送信者Aは、パスワードから生成した共通鍵暗号方式の鍵でファイルを暗号化し、暗号化ファイルを受信者Bへ送付する。受信者Bは、送信者Aからパスワードの通知を別手段で受け、そのパスワードから生成した鍵で暗号化ファイルを復号する。

送信者Aは、パスワードから生成した共通鍵暗号方式の鍵でファイルを暗号化し、暗号化ファイルを受信者Bへ送付する。受信者Bは、送信者Aからパスワードの通知を別手段で受け、そのパスワードから生成した鍵で暗号化ファイルを復号する。

1. CA

2. CP

3. CPS

4. CRL

CRL

1. Webアプリケーションへの攻撃を監視し阻止する。

2. Webブラウザの通信内容を改ざんする攻撃をPC内で監視し検出する。

3. サーバのOSへの不正なログインを監視する。

4. ファイルのウイルス感染を監視し検出する。

Webアプリケーションへの攻撃を監視し阻止する。

スポンサー