問題一覧
1
A.プロジェクトを組織の戦略と整合させること
2
C.ビジネスの利点とリスクに従ってプロジェクトを選択する。
3
B.置換対策には、ポートフォリオ管理アプローチにおけるリソースの割り当てを統合していない複数の独立プロジェクトが含まれている。
4
A.プロジェクトスコープ管理
5
A.明確なビジネスケースが経営陣によって承認されていること。
6
B.ポートフォリオ管理
7
C.ビジネスプラン
8
A.リソースの利用が減少すれば、品質を向上させることができる。
9
C.プロジェクトポートフォリオのデータベース
10
A.システムのライフサイクルが終了するまで。
11
A.プロジェクト・スケジュールと実現された進捗度を比較する。
12
A.プロジェクトに割り当てられるリソースの量を増加させることで、標準への適合性を達成する。
13
D.プロジェクトパフォーマンス基準
14
B.正式なソフトウェアの検査を導入する。
15
A.アプリケーションはテストおよびIT全般統制の対象とはならない可能性がある。
16
C.テストプロセス中にコーディングエラーを正すこと
17
A.QA部門はプロジェクトマネジメントおよびユーザーマネジメントの間で対話する必要があるため、QA部門の有効性。
18
A.ユーザー管理者
19
D.システム設計がビジネス上のニーズに基づいたものとするため
20
D.ビジネスケースとプロジェクト管理をレビューする
21
A.プロジェクトに関連する複雑性およびリスクが分析されている。
22
B.ビジネスケースを更新し、潜在的な是正処置を特定する。
23
A.リスクを考慮し文書化することと、コンティンジェンシープランを作成することにプロジェクトのこの時点で時間を費やす重要性を強調する。
24
C.プロジェクト運営委員会
25
A.システム所有者
26
B.プロジェクトの限界を、効果的に説明している。
27
C.ビジネスユニットマネジメント
28
C.プロジェクトの成果物、コスト、スケジュール
29
D.テスト後に開発者がコードにアクセスできないようにする
30
B.ファンクションポイント分析法
31
C.プログラム評価レビュー手法(PERT手法)
32
B.PERT手法図
33
B.プロジェクトのクリティカルパス
34
C.コスト高および納入の遅延を防ぐ。
35
B.時間の猶予がゼロの活動
36
B.アーンド・バリュー分析
37
D.現在のリソースおよび残りの利用可能のプロジェクト予算に基づいた予想される終了日の算出。
38
D.ガントチャート
39
A.予定より遅れている。
40
C.組織環境全般
41
A.プロジェクトの初期計画ステージ。
42
A.システムが運用されるビジネス環境のように、要件がよく理解されており、安定な状態を保つと予想されている場合。
43
C.プロジェクトの始めに、責任範囲が正式に定められない。
44
C.フィージビリティ(実現性)を実証する
45
A.業務委託とソフトウェア開発に関連した、組織内の技術的スキルと知識
46
A.プログラム出力テスト
47
D.システム要件の定義にユーザーの参加が不適切であった。
48
C.要件収集プロセス
49
B.要件定義
50
D.ユーザー受入れテストの仕様
51
C.データパスおよびストレージをグラフィカルに要約する。
52
C.カスタムメイドのソフトウェアのベンダーが倒産した。
53
D.ETCSアプリケーションのソースコードがエスクロー(第三者)に保管されること。
54
B.ソフトウェアのエスクロー契約
55
C.ソフトウェアエスクロー契約
56
C.ソースコードエスクロー契約を締結する。
57
C.不正確に設定されたパラメータ
58
B.品質計画が契約された成果物に含まれないこと。
59
C.その時点後の変更のコスト効率の評価をさせるため。
60
C.スコープ肥大化
61
B.設計段階
62
B.ソフトウェア・ベースラインを確立する。
63
B.詳細で正しく適用された仕様
64
C.重要なモジュールのエラーがより速く検出される。
65
C.トップダウンテスト
66
A.インターフェースのエラーが早期に特定される。
67
D.ベータテスト
68
C.統合テスト
69
A.要件は、重要性および使用頻度に基づいてテストすべきである。
70
D.適用された変更が新しいエラーを引き起こさない。
71
B.受入れテスト
72
C.実際の作業負荷を使ったテスト環境
73
D.新しいシステムがユーザー要件を満たすことを確実にする
74
B.ユーザー受入れテストを実施すること。
75
C.プログラムの不適切な受け入れ
76
D.ソーシャビリティテスト
77
B.統合テスト
78
B.実際の処理に予想される条件を表すデータ
79
C.欠陥検出率を最大限に伸ばすために、主にテストを通じて欠陥の検出および修正に焦点を当てながら、プロジェクトの全過程において継続的に適用する。
80
C.プログラムの特定のロジックパス手順の正確性または条件を判断する。
81
A.別々のユーザー受入環境の実現可能性を考慮する。
82
A.上級情報システム管理者および経営者は、本番データがテストに使用される前にその使用を承認しなければならない。
83
A.機能を削減したパイロットをテストし、リリースする。
84
D.ユーザー受入れテスト時に、ストレステストの結果をレビューする。
85
B.並列テスト
86
C.ベータテスト
87
A.負荷テスト
88
B.ユーザー受入れテスト(UAT)
89
C.新しいシステムが機能要件を満たすことが保証できる
90
B.古いシステムから新しいシステムへの過去のデータの移行の失敗
91
C.最初の段階で行われたプログラム変更のプロジェクトの残りの部分に対する影響をレビューする。
92
C.単一システムの導入(single implementation) が計画されており、旧システムは直ちに廃止されること
93
C.直接的なカットオーバー
94
D.並行運用
95
D.データ所有者
96
A.2つのシステムの間で移行されたデータの意味的特性の相関関係。
97
D.並行稼動切替
98
B.ユーザー受入れテスト
99
A.プロジェクトの導入フェーズにおいて、バックアウトプラン (切り戻し計画)がない。
100
C.バックアウト手順
自己評価問題
自己評価問題
ユーザ名非公開 · 50問 · 7ヶ月前自己評価問題
自己評価問題
50問 • 7ヶ月前①1章 不正解
①1章 不正解
ユーザ名非公開 · 22問 · 7ヶ月前①1章 不正解
①1章 不正解
22問 • 7ヶ月前②2章不正解
②2章不正解
ユーザ名非公開 · 9問 · 7ヶ月前②2章不正解
②2章不正解
9問 • 7ヶ月前③3章不正解
③3章不正解
ユーザ名非公開 · 57問 · 7ヶ月前③3章不正解
③3章不正解
57問 • 7ヶ月前④4章不正解
④4章不正解
ユーザ名非公開 · 60問 · 7ヶ月前④4章不正解
④4章不正解
60問 • 7ヶ月前⑤5章不正解
⑤5章不正解
ユーザ名非公開 · 60問 · 7ヶ月前⑤5章不正解
⑤5章不正解
60問 • 7ヶ月前⑥自己評価問題不正解
⑥自己評価問題不正解
ユーザ名非公開 · 18問 · 7ヶ月前⑥自己評価問題不正解
⑥自己評価問題不正解
18問 • 7ヶ月前⑦追加問題不正解
⑦追加問題不正解
ユーザ名非公開 · 31問 · 7ヶ月前⑦追加問題不正解
⑦追加問題不正解
31問 • 7ヶ月前⑧不正解問題
⑧不正解問題
ユーザ名非公開 · 74問 · 7ヶ月前⑧不正解問題
⑧不正解問題
74問 • 7ヶ月前⑨不正解問題2
⑨不正解問題2
ユーザ名非公開 · 15問 · 7ヶ月前⑨不正解問題2
⑨不正解問題2
15問 • 7ヶ月前①1章 情報システム監査のプロセス
①1章 情報システム監査のプロセス
ユーザ名非公開 · 149問 · 6ヶ月前①1章 情報システム監査のプロセス
①1章 情報システム監査のプロセス
149問 • 6ヶ月前①2章 ITガバナンスとITマネジメント
①2章 ITガバナンスとITマネジメント
ユーザ名非公開 · 169問 · 6ヶ月前①2章 ITガバナンスとITマネジメント
①2章 ITガバナンスとITマネジメント
169問 • 6ヶ月前①4章 情報システムの運用とビジネスレジリエンス
①4章 情報システムの運用とビジネスレジリエンス
ユーザ名非公開 · 302問 · 6ヶ月前①4章 情報システムの運用とビジネスレジリエンス
①4章 情報システムの運用とビジネスレジリエンス
302問 • 6ヶ月前①5章 情報資産の保護
①5章 情報資産の保護
ユーザ名非公開 · 246問 · 6ヶ月前①5章 情報資産の保護
①5章 情報資産の保護
246問 • 6ヶ月前①2024年8月 新規追加問題
①2024年8月 新規追加問題
ユーザ名非公開 · 110問 · 6ヶ月前①2024年8月 新規追加問題
①2024年8月 新規追加問題
110問 • 6ヶ月前①自己評価問題
①自己評価問題
ユーザ名非公開 · 50問 · 6ヶ月前①自己評価問題
①自己評価問題
50問 • 6ヶ月前②1章 不正解
②1章 不正解
ユーザ名非公開 · 17問 · 6ヶ月前②1章 不正解
②1章 不正解
17問 • 6ヶ月前②2章 不正解
②2章 不正解
ユーザ名非公開 · 22問 · 6ヶ月前②2章 不正解
②2章 不正解
22問 • 6ヶ月前②3章 不正解
②3章 不正解
ユーザ名非公開 · 31問 · 6ヶ月前②3章 不正解
②3章 不正解
31問 • 6ヶ月前問題一覧
1
A.プロジェクトを組織の戦略と整合させること
2
C.ビジネスの利点とリスクに従ってプロジェクトを選択する。
3
B.置換対策には、ポートフォリオ管理アプローチにおけるリソースの割り当てを統合していない複数の独立プロジェクトが含まれている。
4
A.プロジェクトスコープ管理
5
A.明確なビジネスケースが経営陣によって承認されていること。
6
B.ポートフォリオ管理
7
C.ビジネスプラン
8
A.リソースの利用が減少すれば、品質を向上させることができる。
9
C.プロジェクトポートフォリオのデータベース
10
A.システムのライフサイクルが終了するまで。
11
A.プロジェクト・スケジュールと実現された進捗度を比較する。
12
A.プロジェクトに割り当てられるリソースの量を増加させることで、標準への適合性を達成する。
13
D.プロジェクトパフォーマンス基準
14
B.正式なソフトウェアの検査を導入する。
15
A.アプリケーションはテストおよびIT全般統制の対象とはならない可能性がある。
16
C.テストプロセス中にコーディングエラーを正すこと
17
A.QA部門はプロジェクトマネジメントおよびユーザーマネジメントの間で対話する必要があるため、QA部門の有効性。
18
A.ユーザー管理者
19
D.システム設計がビジネス上のニーズに基づいたものとするため
20
D.ビジネスケースとプロジェクト管理をレビューする
21
A.プロジェクトに関連する複雑性およびリスクが分析されている。
22
B.ビジネスケースを更新し、潜在的な是正処置を特定する。
23
A.リスクを考慮し文書化することと、コンティンジェンシープランを作成することにプロジェクトのこの時点で時間を費やす重要性を強調する。
24
C.プロジェクト運営委員会
25
A.システム所有者
26
B.プロジェクトの限界を、効果的に説明している。
27
C.ビジネスユニットマネジメント
28
C.プロジェクトの成果物、コスト、スケジュール
29
D.テスト後に開発者がコードにアクセスできないようにする
30
B.ファンクションポイント分析法
31
C.プログラム評価レビュー手法(PERT手法)
32
B.PERT手法図
33
B.プロジェクトのクリティカルパス
34
C.コスト高および納入の遅延を防ぐ。
35
B.時間の猶予がゼロの活動
36
B.アーンド・バリュー分析
37
D.現在のリソースおよび残りの利用可能のプロジェクト予算に基づいた予想される終了日の算出。
38
D.ガントチャート
39
A.予定より遅れている。
40
C.組織環境全般
41
A.プロジェクトの初期計画ステージ。
42
A.システムが運用されるビジネス環境のように、要件がよく理解されており、安定な状態を保つと予想されている場合。
43
C.プロジェクトの始めに、責任範囲が正式に定められない。
44
C.フィージビリティ(実現性)を実証する
45
A.業務委託とソフトウェア開発に関連した、組織内の技術的スキルと知識
46
A.プログラム出力テスト
47
D.システム要件の定義にユーザーの参加が不適切であった。
48
C.要件収集プロセス
49
B.要件定義
50
D.ユーザー受入れテストの仕様
51
C.データパスおよびストレージをグラフィカルに要約する。
52
C.カスタムメイドのソフトウェアのベンダーが倒産した。
53
D.ETCSアプリケーションのソースコードがエスクロー(第三者)に保管されること。
54
B.ソフトウェアのエスクロー契約
55
C.ソフトウェアエスクロー契約
56
C.ソースコードエスクロー契約を締結する。
57
C.不正確に設定されたパラメータ
58
B.品質計画が契約された成果物に含まれないこと。
59
C.その時点後の変更のコスト効率の評価をさせるため。
60
C.スコープ肥大化
61
B.設計段階
62
B.ソフトウェア・ベースラインを確立する。
63
B.詳細で正しく適用された仕様
64
C.重要なモジュールのエラーがより速く検出される。
65
C.トップダウンテスト
66
A.インターフェースのエラーが早期に特定される。
67
D.ベータテスト
68
C.統合テスト
69
A.要件は、重要性および使用頻度に基づいてテストすべきである。
70
D.適用された変更が新しいエラーを引き起こさない。
71
B.受入れテスト
72
C.実際の作業負荷を使ったテスト環境
73
D.新しいシステムがユーザー要件を満たすことを確実にする
74
B.ユーザー受入れテストを実施すること。
75
C.プログラムの不適切な受け入れ
76
D.ソーシャビリティテスト
77
B.統合テスト
78
B.実際の処理に予想される条件を表すデータ
79
C.欠陥検出率を最大限に伸ばすために、主にテストを通じて欠陥の検出および修正に焦点を当てながら、プロジェクトの全過程において継続的に適用する。
80
C.プログラムの特定のロジックパス手順の正確性または条件を判断する。
81
A.別々のユーザー受入環境の実現可能性を考慮する。
82
A.上級情報システム管理者および経営者は、本番データがテストに使用される前にその使用を承認しなければならない。
83
A.機能を削減したパイロットをテストし、リリースする。
84
D.ユーザー受入れテスト時に、ストレステストの結果をレビューする。
85
B.並列テスト
86
C.ベータテスト
87
A.負荷テスト
88
B.ユーザー受入れテスト(UAT)
89
C.新しいシステムが機能要件を満たすことが保証できる
90
B.古いシステムから新しいシステムへの過去のデータの移行の失敗
91
C.最初の段階で行われたプログラム変更のプロジェクトの残りの部分に対する影響をレビューする。
92
C.単一システムの導入(single implementation) が計画されており、旧システムは直ちに廃止されること
93
C.直接的なカットオーバー
94
D.並行運用
95
D.データ所有者
96
A.2つのシステムの間で移行されたデータの意味的特性の相関関係。
97
D.並行稼動切替
98
B.ユーザー受入れテスト
99
A.プロジェクトの導入フェーズにおいて、バックアウトプラン (切り戻し計画)がない。
100
C.バックアウト手順