平成23年度 春期 午前Ⅱ プロジェクトマネージャ試験 | 解答一覧

1. 企画プロセスで作成されたシステム化計画書に従って、プロジェクトを運営していく。

2. システム化計画書に基づいてプロジェクト管理計画書を作成し、承認を得る。

3. システム化対象業務の課題に対して、ソフトウェア詳細設計段階で最新のシステム技術を使用した解決方法を採用する。

4. プロジェクトのスコープや目的をシステム方式設計に入ってから適宜明確にしていく。

システム化計画書に基づいてプロジェクト管理計画書を作成し、承認を得る。

1. プロジェクトコミュニケーションマネジメントの実行プロセス群

2. プロジェクトスコープマネジメントの計画プロセス群

3. プロジェクト統合マネジメントの計画プロセス群

4. プロジェクト統合マネジメントの立上げプロセス群

プロジェクト統合マネジメントの立上げプロセス群

1. 欠陥修正

2. 是正処置

3. 変更要求

4. 予防処置

変更要求

1.

2.

3.

4.

1. 工程管理上の重要ポイントの把握に適しており、個人の進捗管理などに用いられる。

2. 個々の作業の順序関係、所要日数、余裕日数などが把握できる。

3. 作業開始と作業終了の予定と実績や、仕掛かり中の作業などが把握できる。

4. 作業の出来高の時間的な推移を表現するのに適しており、費用管理と進捗管理が同時に行える。

作業開始と作業終了の予定と実績や、仕掛かり中の作業などが把握できる。

スポンサー

1. 業務の難易度が最も高いスケジュールアクティビティ

2. クリティカルパス上のスケジュールアクティビティ

3. 資源が確保できる時期に開始するスケジュールアクティビティ

4. 所要期間を最も長く必要とするスケジュールアクティビティ

クリティカルパス上のスケジュールアクティビティ

1.

2.

3.

4.

1. 指定された条件下で利用するとき、指定された達成水準を維持するソフトウェア製品の能力

2. 指定された条件の下で利用されるときに、明示的及び暗示的必要性に合致する機能を提供するソフトウェア製品の能力

3. 修正のしやすさに関するソフトウェア製品の能力

4. 明示的な条件の下で、使用する資源の量に対比して適切な性能を提供するソフトウェア製品の能力

明示的な条件の下で、使用する資源の量に対比して適切な性能を提供するソフトウェア製品の能力

1. 層グラフ

2. 積み上げ棒グラフ

3. 二重円グラフ

4. レーダチャート

積み上げ棒グラフ

1. 因果的順序法

2. 演繹的順序法

3. 起承転結型順序法

4. 帰納的順序法

帰納的順序法

スポンサー

1. インバスケットは、一定時間内に数多くの問題を処理させることによって、問題の関連性、緊急性、重要性などに対する総合的判断力を高める技法である。

2. ケーススタディは、日常の開発業務の中で、先輩や上司が個別に指導し、実体験から知識を習得させる技法である。

3. ブレーンストーミングは、参加者に特定の役割を演技させることによって、各立場の理解や問題解決力を高める技法である。

4. ロールプレイングは、参加者のアイディアを批判することなく、またそのアイディアから新たなアイディアを導き出そうとする創造的問題解決に適した技法である。

インバスケットは、一定時間内に数多くの問題を処理させることによって、問題の関連性、緊急性、重要性などに対する総合的判断力を高める技法である。

1. リスク事象発生時の影響金額×リスク事象の発生確率

2. リスク事象発生時の影響金額÷リスク事象の発生確率

3. リスク事象発生時の影響金額×リスク対応にかかるコスト

4. リスク事象発生時の影響金額÷リスク対応にかかるコスト

リスク事象発生時の影響金額×リスク事象の発生確率

1. ステークホルダや専門家にインタビューし、回答を収集してリスクとしてまとめる。

2. 複数の専門家にアンケートを行い、その結果を要約する。さらに要約結果でアンケートを行い、結果を要約することを繰り返すことでリスクをまとめる。

3. プロジェクトチームのメンバに複数の専門家を加えて会議をし、リスクに対する意見を出し合い、進行役がリスクとしてまとめる。

4. プロジェクトを強み、弱み、好機、脅威の各観点及びその組合せで分析し、リスクをまとめる。

複数の専門家にアンケートを行い、その結果を要約する。さらに要約結果でアンケートを行い、結果を要約することを繰り返すことでリスクをまとめる。

1. 強化は、マイナスのリスクに対して使用される戦略である。

2. 共有は、プラスのリスクとマイナスのリスクのどちらにも使用される戦略である。

3. 受容は、プラスのリスクとマイナスのリスクのどちらにも使用される戦略である。

4. 転嫁は、プラスのリスクに対して使用される戦略である。

受容は、プラスのリスクとマイナスのリスクのどちらにも使用される戦略である。

1. システムの機能要件は、広義にとらえることができる表現にする。

2. システムを構築する費用は、供給者選定後に話合いで決める。

3. 提案の評価項目を明示する。

4. プロジェクトのマイルストーンは、供給者に提案してもらう。

提案の評価項目を明示する。

スポンサー

1. 業務、組織及び利用者の要件

2. データ定義及びデータベースに対する要件

3. 利用者の運用に対する要件

4. 利用者の実行に対する要件

業務、組織及び利用者の要件

1.

2.

3.

4.

1. ソフトウェア開発組織及びプロジェクトのプロセスの成熟度を評価するためのモデルである。

2. ソフトウェア開発のプロセスモデルの一種である。

3. ソフトウェアを中心としたシステム開発及び取引のための共通フレームのことである。

4. プロジェクトの成熟度に応じてソフトウェア開発の手順を定義したモデルである。

ソフトウェア開発組織及びプロジェクトのプロセスの成熟度を評価するためのモデルである。

1. 運用テスト

2. システム適格性確認テスト

3. ソフトウェア結合

4. ソフトウェア適格性確認テスト

ソフトウェア適格性確認テスト

1.

2.

3.

4.

スポンサー

1.

2.

3.

4.

1.

2.

3.

4.

1. 機能要件の定義

2. 業務運用手順の文書化

3. 業務モデルの作成

4. システム方式の設計

業務モデルの作成

1. 15

2. 20

3. 30

4. 50

50

1. A社

2. A社とB社

3. A社とC社

4. A社とB社とC社

A社

スポンサー