マインドマップギャラリー 第 4 版_10. プロジェクト統合管理
1.上級プロジェクトマネジメントエンジニア/情報システムプロジェクトマネージャ/ハイレベル 第4版のテキストは、マインドマップに含まれる知識ポイントをマスターすれば、45点は合格できます。 ~ 2. もちろん、これは知識の重要なポイントです。試験に合格するための本当の方法は、それを丸暗記することではなく、ある程度の理解を持っていることです。結局のところ、多くの上級試験では定義が直接テストされるわけではありません。 3. これらの資料を整理するのに多くの労力を費やしましたが、その価値に比べれば、このわずかな費用は単にそれを無料で提供するようなものです。 4. 最初の 3 章には書かれた内容がほとんど含まれていないため、ここではまとめません。 5. もちろん、上記の内容には間違いが必ずあります。もし発見した場合は、WeChat 18978793047 でご連絡ください。
2023-10-04 18:08:49 に編集されましたトップ 10 の知識分野
至高の絵画 15 番目
第 10 章: 範囲管理
テスト状況分析
総合的な知識
事例分析
高頻度テストポイント(要件収集、WBS作成、範囲確認、範囲管理)
エッセイのテーマ
頻繁にチェックする
スコープの概念とスコープ管理
製品の範囲
製品またはサービスの特徴と機能を表します。
プロジェクト範囲
製品やサービスが指定された機能を備えているようにするために実行する必要があるすべての作業。
プロジェクトの主な焦点はプロジェクトの範囲です
プロジェクト範囲のベースライン
承認された詳細なプロジェクト スコープ ステートメント、WBS、および WBS 辞書
1. 計画範囲管理
意味
プロジェクトの範囲と製品の範囲を定義、検証、管理し、範囲管理計画を作成する方法を文書化するプロセス
効果
プロジェクト全体を通じてプロジェクト範囲を管理する方法についてのガイダンスと指示を提供する
範囲管理計画の内容
1. プロジェクトスコープステートメントの作成方法
2. スコープステートメントに基づいて WBS を作成する方法
3. WBSの維持・承認方法
4. 完了したプロジェクト成果物を確認し、正式に受け入れる方法
5. 変更管理プロセス全体の実装に直接関係するプロジェクト スコープ ステートメントの変更をどのように処理するか
注: 上記の内容には需要収集の内容については言及されていませんが、対応する内容は需要管理計画に反映されます。出力のポイント 2 を参照してください。
一東
入力
1. プロジェクト管理計画
2. プロジェクト憲章
3. 事業環境要因
4. 組織プロセス資産
ツール技術
1. 専門家の判断
2.データ分析
3.打ち合わせ
出力
1. 範囲管理計画
2. 需要管理計画
2. 要件を収集する
意味
プロジェクトの目標を達成するために、利害関係者のニーズと要件を特定、文書化、管理するプロセス
効果
製品範囲を含むプロジェクト範囲を定義および管理するための基礎を築く
一東
入力
1. プロジェクト憲章
2. プロジェクト管理文書
3. プロジェクト管理計画
4.プロジェクトファイル
5. 同意
6. 事業環境要因
7. 組織プロセス資産
ツール技術
1. 専門家の判断
2. データ収集
3.データ分析
4.意思決定
5.データパフォーマンス
6.対人スキルとチームスキル
7. システム相互作用図
8.試作方法
出力
1.要件文書
2. 要件追跡マトリックス
要件追跡マトリックス
3. 範囲を定義する
意味
詳細なプロジェクトと製品の説明を作成するプロセス
スコープを定義する役割
収集した要件のうち、どの要件をプロジェクトのスコープに含め、どの要件をプロジェクトのスコープから除外するかを明確にし、製品、サービス、または成果の境界を明確にします。
一東
入力
1. プロジェクトスコープ管理計画
2. プロジェクト憲章
3.プロジェクトファイル
4. 事業環境要因
5. 組織プロセス資産
ツール技術
1. 専門家の判断
2.データ分析
3.意思決定
4.対人スキルとチームスキル
5. 製品分析
出力
1. プロジェクト スコープ ステートメント (スコープ ベースラインの構成要素)
2. プロジェクトファイルの更新
スコープステートメントの内容
1. 製品範囲の説明
2. 成果物
3. 製品の合格基準
4. プロジェクトの除外事項(プロジェクトの範囲外のもの)
5. 制約 (例: 必須の日付)
6. 仮定(検証せずに正しいとみなせる要素)
試験の説明: 事例分析とエッセイの両方がテストされる場合があります
スコープステートメントの役割
1. 範囲を決定する
2. コミュニケーションの基礎(コンセンサス)
3. 基準を変更する(範囲外かどうかを判断する)
4. 計画の根拠(コスト、スケジュール等の計画の根拠)
5. 計画と管理の基礎
試験の説明: 事例分析とエッセイの両方がテストされる場合があります
4. 作業分解構造を作成する
意味
プロジェクトの成果物とプロジェクトの作業を、より小さく、より管理しやすいコンポーネントに分割するプロセス
効果
配信されるコンテンツの構造化されたビューを提供する
一東
入力
1. プロジェクト管理計画
2.プロジェクトファイル
3. 事業環境要因
4. 組織プロセス資産
ツール技術
1.分解する
2. 専門家の判断
出力
1. スコープのベンチマーク
2. プロジェクトファイルの更新
実施する活動
1. 成果物と関連作業の特定と分析
2. WBSの構造と配置方法を決定する(ツリー型、リスト型)
ツリーWBS
明確で直感的、そして高度に構造化されている
適応: 中小規模のアプリケーションプロジェクト
リスト型WBS
すべての作業要素を反映できますが、直感的ではありません
適応: 大規模で複雑なプロジェクト
3. 上から下まで層ごとに精製および分解されます。
4. マーキング コードを作成して WBS コンポーネントに割り当てる
5. 作業分解のレベルが適切であることを確認する
考えられる形式
1. プロジェクトのライフサイクルの各段階を分解の第 2 レベルとして使用し、製品とプロジェクトの成果物を第 3 レベルに置きます。
2. 主要な成果物を分解の第 2 レベルとして使用する
WBSの分解原理
1. WBS は成果物指向でなければなりません。
2. プロジェクトの範囲を遵守し、すべてのレベルでプロジェクトの整合性を維持し、必要なコンポーネントの欠落を避ける必要があります (100% ルール)。
3. 最下位レベルの作業は、計画と制御をサポートし、比較可能で管理可能で定量的に検査可能である必要があります (8 ~ 80 時間ルール)。
ワークパッケージ
4. 作業単位は、異なる責任者と異なる作業内容を分離できる必要があります(各作業単位に責任者があり、担当者は 1 人だけです)。
5. ワークユニットは、相互従属を避けるために、上位レベルのユニットにのみ従属することができます (レイヤー 4 ~ 6)
6. 下請け作業を含む、プロジェクト管理作業を含める必要があります (管理はプロジェクトの特定作業の一部であるため)。
7. WBS の作成には、プロジェクトの (主要な) 関係者全員の参加が必要です。
8.WBS は静的ではありません。
9. 同じレベルの作業単位は同じ性質を持つ必要があります。
10.WBS の最下位の作業単位は作業パッケージです。プロジェクトの WBS を作業パッケージに分解するかどうかは、プロジェクトの段階、複雑さ、規模によって異なります。一般に、初期のプロジェクト、複雑なプロジェクト、または大規模なプロジェクトの場合、WBS 分解の粒度はより大きく、より粗くする必要があります。
コンセプトの拡張
企画パッケージ
これは制御アカウントの下にある WBS コンポーネントであり、作業内容はわかっていますが、詳細な進捗アクティビティはまだ利用できません。
コントロールアカウント
管理制御ポイント。範囲、予算、実際のコスト、スケジュールがこのコントロール ポイントで統合され、収益額と比較されてパフォーマンスを測定します。
WBS辞書
WBS の各部分には、コスト、スケジュール、およびリソース使用状況の情報を要約する階層構造であるアカウント コード識別子が割り当てられます。
マイルストーン
成果物またはフェーズの正式な完了を示します。
ワークパッケージ
作業パッケージは、WBS の各ブランチの下部にある成果物またはプロジェクト作業コンポーネントであり、責任者が自分のタスクを理解できるように、非常に具体的である必要があります。
WBS機能
1. プロジェクトレベルのメンバーがタスクの性質と取り組む必要がある方向性を明確に理解できるように、プロジェクトの範囲を明確に示します。
2. プロジェクトの境界を明確に定義し、プロジェクトの関係者が合意した、実行する必要がある作業と実行する必要のない作業を提供します。
3. 独立した各部門に人員を割り当て、プロジェクトを完了するために必要な技術的および人的リソースを決定するためのこれらの人員の責任を指定します。
4. 独立したユニットの場合、時間、コスト、およびリソースの要件を見積もり、見積もりの精度を向上させます。
5. 計画、予算編成、スケジュール、コスト管理のための共通の基盤を築き、プロジェクトの進行と管理のベースラインを決定する
6. プロジェクト作業をプロジェクトの財務口座にリンクする
7. 作業内容と作業順序を決定し、プロジェクトを特定の作業タスクに分解し、作業タスクの論理的な順序に従ってプロジェクトを実装します。
8. プロジェクト全体とプロセス全体のコストを見積もる
9. 需要の伝染を防ぐのに役立ちます
スコープのベースライン構成
作業内訳構造およびその他の内訳構造
5. 範囲の確認
意味
完了したプロジェクト成果物を正式に承認するプロセスです
効果
各成果物を受け入れることで最終製品、サービス、結果が受け入れられる可能性を高めながら、受け入れプロセスを具体的かつ客観的にします。
一東
入力
1. プロジェクト管理計画
2.プロジェクトファイル
3. 検証された成果物
4. 業務実績データ
ツール技術
1. 検査(レビュー、製品レビュー、監査、ウォークスルー、検査)
2. グループ意思決定技術
出力
1. 受け入れ可能な成果物
2. 変更リクエスト
3. 職務実績情報
4. プロジェクトファイルの更新
成果物 -- フローチャート
職務遂行データと職務遂行情報の違い
仕事のパフォーマンスデータ
プロジェクト作業の実行中に、実行される各アクティビティから収集された生の観察と測定値。
例: 作業完了率、品質および技術的パフォーマンスの測定、スケジュール活動の開始日と終了日、変更要求の数、欠陥の数、実際のコストと実際の期間など。
仕事のパフォーマンス情報
各制御プロセスから収集されたパフォーマンス データは、関連するコンテキストおよびクロスドメインの関係と結合され、統合された方法で分析されます。
例: 成果物のステータス、変更要求の実装ステータス、完了予測
仕事のパフォーマンスレポート
意思決定、質問、行動の実行、または懸念事項の提起を目的として、作業パフォーマンス情報を編集した物理的または電子的なプロジェクト文書。
例: 状況報告書、覚書、デモンストレーション報告書、情報メモ、電子報告書、勧告または状況の最新情報
技術的パフォーマンスの測定
プロジェクトの実行中に達成された技術的結果と、プロジェクト管理計画で要求される技術的結果を比較するパフォーマンス測定手法。プロジェクト製品の主要な技術パラメータは、品質測定指標として使用できます。測定結果は業務パフォーマンス情報の一部です。これらの技術的なパフォーマンスの尺度には、処理時間、欠陥の数、ストレージ容量などが含まれます。分散値は、プロジェクトの範囲の成功を予測し、プロジェクトが直面する技術的リスクの指標を提供するのに役立ちます。リスクをコントロールするためのツールでありテクノロジーです。
品質管理測定結果
品質計画のフォーマットに従って品質管理活動の結果を書面で記録したもの。それは品質管理のアウトプットであり、品質保証の実施のインプットでもあります。
検証範囲と品質管理
1. 範囲を確認し、成果物が受け入れられるかどうかを強調する
2. 品質管理は成果物が正しいかどうかを重視します
検査の焦点が違う
3. 品質管理は通常、範囲を確認する前に実行されますが、同時に実行することもできます。
4. 範囲の確認は通常、段階の最後に行われ、品質管理は必ずしも段階の最後に行われるわけではありません。
検査時間が異なります
5. 品質管理は社内検査であり、実施組織が実施します。
6. 確認範囲は外部の顧客またはスポンサーによって検査され、受け入れられます。
検査官は違う
7. ますます詳細な検査で製品、品質管理、検証範囲を検証します
6. 管理範囲
意味
プロジェクトと製品のスコープのステータスを監視し、スコープのベースライン変更のプロセスを管理します
効果
プロジェクト全体を通じてスコープのベースラインを維持する
一東
入力
1. プロジェクト管理計画
「○○の管理」のすべての工程は、対応するサブ工程の管理計画ではなく、「プロジェクト管理計画」に基づいて管理されます。これは、管理がプロジェクト全体を考慮する必要があるためであり、「管理進捗管理」プロセスでは、真ん中のものはかなり特殊で、「プロジェクト管理計画」と「プロジェクトスケジュール計画」の両方があります。
2.プロジェクトファイル
3. 仕事のパフォーマンスデータ
XXXを制御するすべてのプロセスにおいて、「作業実績データ」が入力され、「作業実績情報」が出力されます。
4. 組織プロセス資産
ツール技術
1.データ分析
現在行っていることと、将来計画していたことを比較してください
出力
1. 職務実績情報
2. 変更リクエスト
3. プロジェクト管理計画の更新
4. プロジェクトファイルの更新
5. 組織プロセス資産の更新
なお、制御…、確認…を伴う処理は、データを入力とする処理と情報を入力とする処理は一般的に同じ内容である。
関与するコンテンツ
1. スコープ変更につながる要因に影響を与え、それらの要因が好ましい方向に発展するよう努める
2. スコープの変更が発生したかどうかを判断する
3. 範囲の変更が発生したときに実際の変更を管理し、すべての変更リクエストがプロジェクトの全体的な変更管理プロセスに従って処理されるようにします。
集中
4. 制御範囲は他の制御プロセスとも組み合わせる必要があります
変更理由(経営陣全体の変更理由と同様)
1. プロジェクトの外部環境の変化
2. プロジェクト範囲計画が慎重に作成されておらず、特定の誤りまたは欠落が含まれています。
3. 新しい技術、新しい方法、新しいソリューションが市場に登場するか、設計者がそれらを提案します。
4. 事業実施組織自体の変更
5. プロジェクト、プロジェクト製品またはサービスに対する顧客の要件の変更
論文の要点
需要管理
ビジネスアナリスト
要件を確認する
作物
要件追跡マトリックスの更新
除外項目をさらに明確にすることができます
顧客に範囲を明確に確認する必要がある
どのような種類の契約が締結されますか (固定総額)?