マインドマップギャラリー 高度なプロジェクト 第 5 章 - プロジェクト スコープ管理マインド マップ
これは、ハイプロジェクト - プロジェクトスコープ管理の第 5 章に関するマインドマップです。管理範囲や確認範囲などの観点から整理されており、内容が詳しく、構造が明確で、ロジックが厳密であるため、学ぶ価値があります。
2021-06-21 13:11:15 に編集されました第 5 章 - プロジェクトの範囲管理
5.1 計画範囲の管理
意味
プロジェクトの範囲をどのように定義、検証、制御するかを書面で説明する範囲管理計画を作成します。 手順。
2つの範囲
プロジェクト範囲
仕事
プロジェクトの境界を明確にする
プロジェクトの実行を監視する
プロジェクトスコープのクリープを防ぐ
意味
製品を提供するためにプロジェクトがしなければならないこと
プロジェクト管理計画を作成するための基礎
スコープ ベースラインは、承認されたプロジェクト スコープ ステートメント、WBS、WBS 辞書です。
製品の範囲
製品またはサービスに含めるべきもの
これは製品要件の説明であり、プロジェクト範囲の基礎となります。
製品の説明を満たしているかどうかに基づいて、製品の範囲が完全であるかどうかを判断します
5.2 要件の収集
意味
プロジェクトの目標を達成するために、利害関係者のニーズと要件を特定、文書化、管理するプロセス
分類
ビジネスニーズ
ステークホルダーのニーズ
ソリューションの要件
機能要件
非機能要件
移行のニーズ
プロジェクトの要件
品質要件
ツールとテクニック
インタビュー
フォーカスグループ
事前に選択した関係者と対象分野の専門家を集めて、提案された製品、サービス、または結果に対する期待と態度を理解します。訓練を受けたモデレーターが対話型のディスカッションを主導します。フォーカス グループは、1 対 1 のインタビューよりも魅力的な傾向があります。フォーカスグループとは、1対1の面接ではなくグループ面接のことです。
ガイド付きセミナー
主要な部門横断的な関係者を会議に招待する。製品要件に焦点を当てたガイド付きワークショップ 理論と定義。ワークショップは、部門を超えた要件を迅速に定義し、関係者間の相違を調整するための重要な手法です
グループ革新技術
ブレーンストーミング
名目上のグループ
さらなるブレインストーミングや優先順位付けに最も役立つアイデアをランク付けするための投票
デルフィ技法
匿名または連続的な手法、予測プロセス中に数回のフィードバックを行うことで、専門家の意見が徐々に収束します。
コンセプト/マインドマップ
親和性図
ある問題について、さまざまな経験、知識、考え、意見、その他の言語や言葉を十分に収集することです。 データを図表でまとめ、相互の親和性に基づいて要約・整理することで問題点を明確にします。
多基準の意思決定分析
グループでの意思決定テクニック
全会一致で同意した
ほとんど
サブトピック
アンケート
観察する
プロトタイプメソッド
ベンチマーク
システム相互作用図
ファイル分析
要件文書
ビジネスニーズ
ステークホルダーのニーズ
ソリューションの要件
プロジェクトの要件
移行のニーズ
仮定、依存関係、制約
要件の追跡
需要管理
製品開発中に要件の一貫性と正確性を維持するすべてのアクティビティが含まれます。これには、要件ベースラインの管理、プロジェクト計画と要件の一貫性の維持、個々の要件と要件文書のバージョン ステータスの管理、要件とコンタクト チェーン間の接続の管理、または個々の要件と要件間の依存関係の管理が含まれます。プロジェクトのその他の成果物、ベースラインでの要件のステータスの追跡
需要ベースライン
ソフトウェア プロジェクトの要件開発の結果には、プロジェクト ビューと範囲の文書、ユース ケースの文書、ソフトウェア要件の仕様、および関連する分析モデルが含まれる必要があります。レビューと承認の後、これらの文書は開発作業の要件ベースラインを定義します。このベースラインは、製品の機能要件および非機能要件を計画するための顧客と開発者間の合意を確立します。
要件の取得
ユーザーと積極的にコミュニケーションをとり、ユーザーニーズを把握し、分析・修正し、課題解決に適したユーザーインターフェースを形成します。 ユーザーのニーズを把握し、「ユーザーニーズ仕様書」を生成する
需要分析
さまざまな要件を分析して抽象的に記述し、システムをガイドできる概念モデルを確立します。
要件定義
需要の獲得と需要分析の結果に基づいて、正確な製品要件を定義し、「要求仕様書」を生成します 本"
要件の検証
5.3 スコープの定義
意味
範囲の定義は、プロジェクトと製品の詳細な説明を作成するプロセスであり、その主な機能は、収集された要件のうちどれがプロジェクトの範囲に含まれ、どれがプロジェクトの範囲から除外されるかを明確にし、それによって製品の境界を明確にすることです。サービスや結果。
ツールとテクニック
専門家の判断
製品分析
代替世代
ガイド付きセミナー
プロジェクトスコープステートメント
製品範囲の説明
合否基準
コスト、スケジュール、品質の測定指標
成果物
プロジェクトの除外
制約
仮定
効果
範囲
コミュニケーションの基本
計画と管理の基礎
変更基準
計画の基本
5.4 WBSの作成
意味
プロジェクトの成果物とプロジェクトの作業をより小さく、より管理しやすいものに分割する コンポーネントプロセス
マイルストーン
成果物またはフェーズの正式な完了を示します。重要なチェックポイントはマイルストーン、重要なマイルストーンはベースライン
ワークパッケージ
8時間以上、80時間以下
コントロールアカウント
制御アカウントには複数の作業パッケージが含まれていますが、作業パッケージは 1 つの制御アカウントにのみ属します
企画パッケージ
作業内容はわかっているものの、詳細な進捗アクティビティが不足している、管理アカウント下の WBS コンポーネントを指します。
WBS辞書
アカウントコードの識別、作業の説明、前提条件と制約、責任者または組織単位、スケジュールマイルストーン、関連スケジュールアクティビティ、必要なリソース、コスト見積もり、品質要件、合格基準、技術リファレンス、契約情報が含まれます。
分解活動
成果物と関連作業を特定して分析する
WBSの構造と配置を決定する
上から下へレイヤーごとに分解
識別コードを開発して WBS コンポーネントに割り当てる
成果物の分解レベルが適切であることを検証する
注意すべき8つの側面
WBS は成果物指向でなければなりません
WBS はプロジェクトの範囲内に収まる必要があります
WBS の基礎となる層は、計画と管理をサポートする必要があります。
WBS の要素に対して責任を負うのは 1 人だけでなければなりません
WBSの指導。原則ではなく目安として、WBSは4~6層で管理する必要がある
WBS には、プロジェクト管理作業と下請け作業も含める必要があります。
WBS の作成には、すべての (主要な) プロジェクト関係者の参加とプロジェクト チーム メンバーの参加が必要です。
WBS は静的ではありません
5.5 確認範囲
意味
プロジェクトの関係者が完成した成果物を正式に承認するプロセス
ツールとテクニック
診る
グループでの意思決定テクニック
ステップ
スコープ検証が必要な場合を決定する
スコープの検証に必要な入力を特定する
正式に受け入れられた範囲設定の基準と要素を決定する
スコーピング会議の組織的な手順を決定する
組織範囲確認会議
品質管理との違い
検証範囲では成果物の受け入れが重視され、品質管理では成果物の正確さが重視されます。
品質管理は通常、範囲が確認される前に、または通常は段階の最後に範囲が確認されると同時に実行されます。
品質管理は内部検査であり、範囲が確認され、成果物がプロジェクト関係者によって受け入れられます。
閉店との違い
スコープの確認では成果物の検証と受け入れが強調され、クロージングではプロジェクトまたはフェーズを終了するプロセスが強調されます。
確認範囲では成果物の受け入れが重視され、クロージングでは製品の受け入れが重視されます。
5.6 管理範囲
スコープの制御は、プロジェクトと製品のスコープのステータスを監視し、スコープのベースラインへの変更を管理するプロセスです。その主な役割は、プロジェクト全体を通じてスコープのベースラインを維持することです。
主な仕事
スコープ変更につながる要因に影響を与え、それらの要因が好ましい方向に発展するよう努める
スコープの変更が発生したかどうかを判断する
スコープの変更が発生したときに実際の変更を管理し、リクエストされたすべての変更がプロジェクト全体の変更管理プロセスに従って処理されるようにします。