-
要件定義工程では、プロセスとデータのモデルを作成し、外部設計工程では、インターフェースレイアウト（画面定義書、帳票定義書など）を作成する。
〇
-
ビジネス・業務を理解し、業務の仕組みを分析するために、モデリングの技法が有効である
〇
-
データ中心アプローチ（DOA）では、プロセス分析とデータ分析を実施する。
〇
-
UML(Unified Modeling Language)はオブジェクト指向開発におけるモデリングの標準的な表記方法である。
〇
-
データ分析では、管理対象であるエンティティとエンティティ間のリレーションシップの構造をERD（Entity-Relationship Diagram）を利用して視覚的に表現する。
〇
-
ユースケース分析の目的は、ユーザから見たシステムの振る舞いを図や文書で表現することにより、システムがどのような人に、どう使われるかを明確にすることである。
〇
-
JAVAなどのオブジェクト指向言語やフレームワークを利用して情報システムを開発する場合、内部設計以降の工程では、オブジェクト指向設計の考え方で設計しなければならない。
〇
-
プロジェクトマネジメント、プロダクト開発の手順や技法が決まっていても、現場の実践力がなければ、プロジェクトの成功確率は高くならない。
〇
-
IT構想・企画のフェーズでは何のために（Why）、どのようなシステムを（What）、どのように実現するか（How）の手順で実施される。
〇
-
稚拙なプロジェクトマネジメントへの対策の一つとして、｢リスクを予測して、先手を打つ｣ことがあげられる。
〇
-
アクティビティ所用期間見積りの技法の一つである類推見積りでは、過去の類似プロジェクトの所要時間、予算、規模などを利用する。
〇
-
プロジェクトマネージャーはプロジェクト目標を達成することに責任を持つ人。
〇
-
PMBOKとは、プロジェクトマネジメントのプロセス、ツール、技法を明確にして、プロジェクトを成功に導くために、プロジェクトマネジメントの知識体系を整備したものである。
〇
-
プロジェクト憲章とは、プロジェクトやフェーズを公式に認可する文書である。
〇
-
プロジェクト憲章とは、プロジェクトやフェーズを公式に認可する文書である。スケジュール・モデルを構築するための一つの方法であるプレシデンス・ダイアグラム法（PDM）では、ノードと呼ぶボックスや長方形でアクティビティを表し、それらアクティビティ間にある論理的な関係を示す矢印でアクティビティを相互に結合している。
〇
-
リスクマネジメントの目標は、プロジェクトの成功の可能性を最大限に高めるために、ポジティブ・リスクの発生確率と影響度を増加させ、ネガティブ・リスクの発生確率と影響度を減少させることである。
〇
-
コスト見積りにおけるコンティンジェンシー予備とは、特定リスクのために配賦されるコスト・ベースライン内の予算である。多くの場合、プロジェクトに影響する可能性がある「既知の未知」に備えるための予算の一部とみなされる。
〇
-
士気を高め、コンフリクトを抑え、チームワークを向上させるために、チーム・メンバー間の信頼と合意の意識を改善することも、プロジェクト・チーム育成の目標の一つである。
〇
-
ステークホルダー・エンゲージメントのマネジメントとは、ステークホルダーのニーズや期待に応え、課題に対処し、ステークホルダーの適切な関与を促すためにステークホルダーとコミュニケーションをとり協働するプロセスである。 1
〇
-
リスクマネジメントの目標は、プロジェクトの成功の可能性を最大限に高めるために、ポジティブ・リスクの発生確率と影響度を増加させ、ネガティブ・リスクの発生確率と影響度を減少させることである。
〇
-
プロジェクトの全期間を通じて、リスクの特定、アクションプランの実施、その実施結果の確認を行う。
〇
-
リスクの発生時対策を確実に実施するために、リスクの発生を検知するためのトリガーとなる状況を予め決めておく必要がある。
〇
-
.プロジェクトの計画時点で、プロジェクトの各フェーズで作成する成果物を定義すると共に、その成果物のレビュー、承認の基準と方法を決めておく必要がある。
〇
-
2. マイルストーンとは、プロジェクトにおいて重要な意味をもつ時点やイベントである。
〇
-
1. スコープを定義するとは、プロジェクトに何が含まれ、何が含まれないかを明確にすることであるが、スコープには、プロダクト・スコープ（何を開発するのか）とプロジェクト・スコープ（どんな作業を行うか）がある。
〇
-
5.コミュニケーション計画の立案にあたって、経営層やプロジェクトマネージャーに正しい情報が適切なタイミングで提供される“しくみ”作りを計画することが重要である。
〇
-
1. 情報システムにおける品質とは、それが稼動した時、そのシステムがビジネス要求（あるいはユーザー要求）を達成している度合のことである。
〇
-
. システム開発の各工程完了時点で実施する品質保証活動は審査と呼ばれる。
〇
-
4. 品質保証活動の実施により、問題や不具合が明らかになった場合、すみやかに是正処置を講じる。
〇
-
プロジェクトマネージャーは真の原因を解決するために、プロジェクトの状況やリソースから判断して、もっとも効果がある対策案を選択する必要がある。
〇
-
問題課題管理では、洗い出された問題や課題に対して、解決期限や対応する担当者を明確にすることが重要である
〇
-
システム開発における構成管理とは、設計書やプログラムなどのプロジェクト成果物を、ライフサイクルを通じて整合性をもって維持することである。
〇
-
変更管理では、計画段階で変更管理手順や管理の仕組みを決定し、顧客（ユーザー）と合意していることが重要である。
〇
-
単体テストでは、要件定義や外部設計で定義された通りにシステムが動作することを検証する。
単体テストでは、詳細設計で定義された個々のモジュールやコンポーネントが正しく動作することを検証する。
-
テストの結果発生した調査や作業手戻りの費用、あるいは情報システム稼動後の問題対策の費用などを評価コストという。
テストの結果発生した調査や作業手戻りの費用、あるいは情報システム稼動後の問題対策の費用などは、問題コストとして評価される。
-
情報システム開発において、最終成果物である情報システムが｢モノ｣ではなく、目に見えない機能であるため、要求されている機能が開発途中であまり変動しない。
情報システム開発において、最終成果物である情報システムが｢モノ｣ではなく、目に見えない機能であるため、要求されている機能が開発途中であまり変動する。
-
プロジェクトは独自性のある活動であるため、不確実性を伴うが、特に何も手を打たなくても、通常は成功する。
プロジェクトは、独自性のある活動であるため、不確実性を伴う。 要するにリスクがあり、何も手を打たなければければ、失敗する可能性が高い。
-
プロジェクト計画立案時には、特にリスクを考慮する必要はない。
×
-
プロジェクトマネージャーが「リスクを予想して先手を打つ」ためには、直感に頼るしかない。
プロジェクトマネージャーが「リスクを予想して先手を打つ」ためには、様々な種類の信頼でき る情報に基づかないと実行できない。
-
プロジェクト・スコープ・マネジメントは、プロジェクトを所定の時期に完了させるために必要なプロセスからなる
プロジェクト・スコープ・マネジメントは、必要 なすべての作業を、かつ必要な作業のみを含めることを確実にするために必要なプ ロセスからなる。（ス家ジュール）
-
ワーク・パッケージとは、プロジェクト目標を達成し、必要な要素成果物を生成するために、プロジェクトチームが実行する作業を、要素成果物を主体に階層的に要素分解したものである。
WBSの最下位で作業のコストと アクティビティの所要期間を高い 信頼度をもった見積り およびマネジメントができる レベル
-
アーンド・バリュー・マネジメントにおいて、SV（スケジュール差異）＞０の場合は、スケジュールが遅延している。
×
-
品質のマネジメントのプロセスでは、パフォーマンスを査定し、プロジェクトのアウトプットを完了し、正しく、顧客の期待を満たすことを保証するために、品質マネジメント活動の結果を監視し、記録する。
品質のマネジメントのプロセスでは、組織の品質方針をプロジェクトに組み入れて、組織の品質マネジメント計画を実行可能な品質活動に転換するプロセス（コントロール）
-
プロジェクトマネジメント・チームの中のプロジェクトマネジャーのみが、倫理的な行動をすることに注意を払い、それに同意し、それを確実に守るようにしなければならない。
プロジェクトマネジメント・チームの中のプロジェクトマネジャーが倫理的な行動を認識し、体現し、すべてのチーム・メンバーがこ れらの行動に確実に従うようにすべきである。
-
プロジェクトの全体リスクとは、発生が不確実な事象または状態であり、発生した場合はひとつ以上のプロジェクト目標にプラスあるいはマイナスの影響を及ぼすリスクである。
プロジェクトの全体リスクとは、プロジェクト全体に及ぼす不確実性の影響であり、個別リスクを含む不確実性のすべて の源から発生する。
-
タイム・アンド・マテリアル契約では、完了した作業にかかったすべての正当な実コストに、納入者の利益相当分を加えた金額を納入者に支払う。
タイム・アンド・マテリアル契約では、実費償還と定額契約の両方の側面を複合させたタイプの契約である（実費償還契約）
-
プロジェクトの計画を作成する上で、プロジェクトを取り巻く前提条件や制約事項については、特に考慮する必要はない
×
-
ITプロジェクトの現場では、実証済みのWBSをそのまま利用して、スケジュールを作成するべきであり、個別のプロジェクトの事情に応じて、変更するべきでない。
×
-
WBSの作成、タスクの分解という作業の結果と関連せずに、同時並行してスケジュールを作成することは可能である。
×
-
ITプロジェクトにおいて、データ分析やデータベースの管理を受け持つ専門家はビジネス・アナリストと呼ばれる。
ITプロジェクトにおいて、データ分析やデータベースの管理を受け持つ専門家はﾃﾞｰﾀ・ｱﾅﾘｽﾄと呼ばれる。
-
プロジェクトの品質保証活動である品質のレビューやテストに要する費用を「予防コスト」と呼ぶ。
評価コスト
-
プロジェクトの問題の兆候は、公式な会議のみから収集する。
非公式も
-
表面的な問題から、真の原因を掘り下げるためには、時間がかかるため、すぐに対応できる対策のみを実施する。
×
-
仕様変更とは、計画との大幅なズレにより、プロジェクト計画全体の見直し、すなわち、範囲、納期、コストなどの計画を全面的に変更することである。
プロジェクト変更
-
概算見積りの段階では、システムの要件や詳細な作業が未確定であるため、類推見積りの技法を利用する。
類推見積りは初期見積もりの時．係数モデル 見積りの説明
-
テストでは、作成されたソフトウェアが設計された仕様通りに動作するかどうかを検証する機能要件テストのみを実施する。
非機能要件テストも
-
性能やユーザビリティなどの非機能要件のテストは、結合テスト工程で実施する。
システムテストで実施
-
不具合管理では、テストで発生した不具合の原因調査、対応策の決定、対応作業の推進などを行う。
〇
-
プロジェクトの完了報告では、プロジェクトの評価のみならず、プロジェクトで得られた実績値（工数、生産性など）や学んだ教訓も報告することによって、後続プロジェクトにその成果を引き継ぐことが重要である。
〇
-
