PMP：計画 - 範囲 のバックアップ(No.24)

[ トップ ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• PMP：計画 - 範囲 へ行く。
  • 1 (2018-04-11 (水) 16:28:07)
  • 2 (2018-04-11 (水) 17:01:16)
  • 3 (2018-04-16 (月) 17:53:36)
  • 4 (2018-04-16 (月) 22:24:22)
  • 5 (2018-04-17 (火) 22:00:56)
  • 6 (2018-04-18 (水) 22:03:45)
  • 7 (2018-04-18 (水) 22:28:50)
  • 8 (2018-04-30 (月) 17:14:55)
  • 9 (2018-04-30 (月) 17:42:25)
  • 10 (2018-05-04 (金) 17:19:44)
  • 11 (2018-05-05 (土) 21:35:42)
  • 12 (2018-05-07 (月) 21:32:38)
  • 13 (2018-05-07 (月) 21:44:58)
  • 14 (2018-05-08 (火) 09:41:30)
  • 15 (2018-05-08 (火) 18:04:45)
  • 16 (2018-05-11 (金) 21:19:34)
  • 17 (2018-05-30 (水) 17:32:20)
  • 18 (2018-06-01 (金) 22:05:36)
  • 19 (2018-06-05 (火) 17:09:40)
  • 20 (2018-06-06 (水) 18:56:35)
  • 21 (2018-06-13 (水) 21:50:31)
  • 22 (2018-06-25 (月) 15:52:41)
  • 23 (2018-07-14 (土) 20:59:32)
  • 24 (2018-07-18 (水) 01:03:04)
  • 25 (2018-07-30 (月) 21:09:59)
  • 26 (2018-07-31 (火) 20:13:11)
  • 27 (2018-11-06 (火) 14:56:26)
  • 28 (2018-11-06 (火) 20:49:45)
  • 29 (2018-12-22 (土) 15:34:10)
  • 30 (2019-01-03 (木) 21:29:31)
  • 31 (2019-01-04 (金) 15:15:59)
  • 32 (2019-01-22 (火) 16:55:51)
  • 33 (2019-01-25 (金) 10:00:26)
  • 34 (2019-01-25 (金) 18:27:29)
  • 35 (2019-02-09 (土) 15:38:39)
  • 36 (2019-02-23 (土) 21:44:32)
  • 37 (2019-02-28 (木) 15:33:20)
  • 38 (2019-03-10 (日) 17:45:08)

---

「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

• 戻る

目次 †

概要 †

計画 - スコープ・プロセスの主要な役割 †

• 要求事項収集技法を使用して、
  • 計画会議
  • ブレーンストーミング
  • フォーカス・グループ

• ステークホルダーと共にプロダクトの詳細を評価し、
  • 要求事項
  • 制約条件
  • 前提条件

• スコープに関する記述を行う。

• プロジェクト・スコープに関する記述を行う。
  • プロジェクト・マネジメントに含まれるもの
  • プロジェクト・マネジメントに含まれないもの

• プロダクト・スコープに関する記述を行う。
  • 成果物（プロダクト / サービス / 所産）に含まれるもの
  • 成果物（プロダクト / サービス / 所産）に含まれないもの

• これらは、WBS作成の土台になる。

• プロダクトをマネジメントするために、スコープを分解して、WBS作成する。

※ 計画プロセス群の肝（≒SIだと要件定義などと呼ばれるフェーズ）。

インプット・アウトプット †

スコープ・マネジメント計画 †

• スコープ（成果物（プロダクト / サービス / 所産））から、プロジェクトの作業であるものと無いものを選別する。
• 「スコープ・マネジメント計画書」と「要求事項マネジメント計画書」の２つのアウトプットを生成する。

インプット †

• プロジェクトの背後の環境・目的を理解する。

• 対象
  成果物（プロダクト / サービス / 所産）

プロジェクト憲章 †

スコープに影響

• プロジェクトの目的
• ハイレベルの要求事項
• 一部の成果物（プロダクト / サービス / 所産）の記載

プロジェクト・マネジメント計画書 †

組織体の環境要因 †

スコープの管理方法に影響

• 市場の状況

• 組織の
  • 文化、人事管理
    • 人的資源の上申のスキル、知識、能力
  • 経済な状況
  • インフラストラクチャー
    • 物理的
    • 技術的

組織のプロセス資産 †

• スコープの管理方法に影響

• 方針・ガイドライン、手順
  • 組織の
  • 業界の

• 過去の情報
  規模とスコープが類似している過去のプロジェクト。

プロセス（ツールと技法） †

専門家の判断 †

• 上級管理職（立上の人物/組織）
• プロジェクト・スポンサー
  （オーナー、イニシエータ、顧客であることもある）
• 業界の専門家
• 専門的な訓練を受けたチーム・メンバ
• 類似プロジェクトの経験のあるPM

会議 †

スコープ・マネジメント計画書に含める内容を会議で決定する。

アウトプット †

スコープ・マネジメント計画書 †

• スコープ決定のプロセスを記述する。
  • スコープの定義方法
  • スコープの検証方法
  • スコープの制御方法
  • スコープの変更方法

• WBSを容易に作成できるようにする。
• 成果物（プロダクト / サービス / 所産）の検証/受入の方法を記述する。

• プロセスの相互作用と依存関係から、
  変更の監視・制御の方法を記述する。

• 構成要素
  • プロジェクト・スコープ記述書の作成プロセス
  • WBSの作成、承認、維持のプロセス
  • 成果物（プロダクト / サービス / 所産）の正確性を検証し、受入をするプロセス
  • プロセスの相互作用と依存関係から、変更の監視・制御のプロセス。
    （変更要求手順と、変更要求書式を入手する方法などを含む）

要求事項マネジメント計画書 †

• プロジェクト全期間に渡って要求事項を
  分析/文書化/追跡/報告/マネジメントする方法を記述する。

• スコープ・マネジメント計画書と似ているが、
  プロジェクトの要求事項に重点を置いている点が異なる。

• このプロセスの鍵は要求事項のマネジメントにある。
  • フェーズ間の関係は、要求事項のマネジメント方法に影響を与える。

• 例：
  • 直列関係：フェーズの開始時に要求事項が完成している必要がある。
  • 並列関係：段階的に詳細化されるため、開始時に完全に定義されない。

• プロセスの相互作用と依存関係から、
  変更の監視・制御の方法を記述する。

• 構成要素

• 要求事項の各アクティビティの実行方法
  • 計画アクティビティ
  • 追跡記録アクティビティ
  • 報告アクティビティ

• 要求事項の
  • 優先度付
  • 追跡に使用される評価基準
  • 変更の要求/追跡記録/分析
    （他のコンフィグレーション・マネジメントのアクティビティとともに）

• トレーサビリティ・マトリックス
  • 含める要素
  • 要素の属性

要求事項収集 †

• ステークホルダーの関心・期待、ニーズ、要望（要求事項）
  を理解するため、要求事項を収集・定量化し、文書化する。

• 成果物（プロダクト / サービス / 所産）の完成形態を定義する。

• ここでは、まず、スコープに含まれるものを収集する。

• 収集された要求事項をプロジェクトに含めるかどうかは次のプロセスで決定する。

インプット †

• ステークホルダーの関心・期待、ニーズ、要望（要求事項）
  を理解するため、要求事項を収集・定量化し、文書化する。

• 要求事項

• 測定 / 追跡 / テストが可能であるものであること。

• 以下のカテゴリーがある。
  • ビジネス
  • ステークホルダー
  • ソリューション
  • 機能
  • 非機能
  • 移行
  • プロジェクト
  • 品質

プロセス（ツールと技法） †

• コミュニケーション・スキルが重要になるプロセス。
  • 心を読む力
  • 要求事項を引き出す的確な質問を投げかける。

• ターゲット
  • ステークホルダー
    • 多くの場合、どのような成果物（プロダクト / サービス / 所産）が望ましいか解っている。
    • しかし、それを上手く表現できないことがある。

• （バリュー・チェーン中の）
  ビジネス・プロセスのオーナー
  • 中間管理職やライン・マネージャ
  • ライン（製造）以外のビジネス・エキスパート

• 目標達成のための成果物（プロダクト / サービス / 所産）の特性を記述する。
  • 満たすべき条件
  • 満たすべき機能

インタビュー †

• 一対一の会話
  • 質問
  • 回答を記録

• 対象を絞って短時間で多くの情報を入手できる。
  • 特性・機能に詳しい特定の分野の専門家
  • 経験豊富なチーム・メンバ

フォーカス・グループ †

• 訓練を受けたモデレータによって行われる。

• 参加者の選定が重要になる。
  • 特定の分野の専門家
  • ステークホルダー

ファシリテーション型ワークショップ †

• 様々な機能部門のステークホルダーが参加する。
• ファシリテーション型のフォーラムで
  複数の部署に影響を及ぼす要求事項に関する討議・定義。

• フォーカス・グループと違い、
  部門を跨る要求事項を定義できる。
  • 素早い相違の把握
  • 相違の解消と合意

• IT業界：JAD（共同アプリケーション設計・開発）

• 概要
  システムの利用者が開発の初期段階から参加し、要望を反映させる。

• 参加者：機能部門のステークホルダー

• 製造業界：QFD（品質機能展開）

• 概要
  品質保証や製品企画、顧客満足やマーケットインを実現するための方法論。
  • 製造者と顧客の考えの関係をチェックして、ミスマッチを減らす。
  • 特性値とそれを実現するための工程や、製造条件、等の関係を決める。

• 参加者
  • 顧客
  • ビジネス分野の専門家

グループ発想技法 †

• 技法

• ブレーン・ストーミング
  • アイデア・マップ法
  • マインド・マップ法

• ノミナル・グループ技法

• 親和図
• 多基準意思決定分析

※ 各技法についてはリスク特定プロセスで説明

グループ意思決定技法 †

• 投票
  • 満場一致
  • 過半数
  • 相対多数（過半数に達しない場合）

• 独裁（１人がグループを代表して意思決定）

• 多基準意思決定分析

アンケートと調査 †

• 大規模な母集団
• 素早い情報収集
• 結果の統計分析

観察と対話 †

• 作業観測とも呼ばれる。

• 方法
  • 観察者がプロダクトを使用した作業を観察する。
  • もしくは、観察者 自身が作業者になる。

• 通常、作業者が気が付かない要求事項を発見できる。

プロトタイプ †

• 成果物（プロダクト / サービス / 所産）のモックアップを開発してユーザに実験してもらう。
• プロトタイプのフィードバックを得て修正する反復プロセス

ベンチマーキング †

• 基準値と測定値を比較してパフォーマンスを測定する。
  • ベストプラクティスの精緻化
  • 慣行の改善のためのアイディア創出

• 測定対象
  • プロセス
  • 定常業務
  • マネジメント

• 基準値
  • 他部署
  • 他組織
  • 他業界

コンテキスト・ダイアグラム †

アクターとビジネス・プロセス（機器）の相互作用の視覚化する。

文書分析 †

• 組織のビジネス計画
• マーケティング計画
• 契約、ビジネス規則
• 戦略計画

アウトプット †

要求事項を文書化する。

• プロジェクトが長期化すると
  • ステークホルダーは要求事項を忘れる。
  • また、要求事項は段階的に詳細化される。

• 従って、文書化してステークホルダーからの承認を得ることが重要。

• これをベースにプロジェクト全期間に渡って要求事項を分析/文書化/追跡/報告/マネジメントする。

要求事項文書 †

• 要求事項が要求事項文書に記録される。
• また、ステークホルダーの署名が必要になる。

• 構成要素

• プロジェクト
  • のビジネス・ニーズ
  • の達成したいビジネス目標
  • が選定された理由

• 各種要件
  • 機能要件
  • 非機能要件
  • 品質要件

• 受入基準
  発注元の要件を満たすか。
• 引渡要件
  発注元の定常業務・エンドユーザの要件を満たすか。
• サポートとトレーニングに関する要件

• その他
  • ビジネス規則
  • 制約条件
  • 前提条件

要求事項トレーサビリティ・マトリックス †

• ココで記録・文書化するモノ
  • 要求事項の発生源
  • 要求事項の追跡の基準

• これにより、追跡を引渡 or 完了まで継続する。

• 記述項目
  マトリックスと言うよりリスト？

• 例１

• ID

• 要求事項の説明（要求事項名）
  短な、要求事項を特定可能な情報

• 発生源
  プロジェクト目標、ビジネス・ニーズ、WBS、
  製品設計、成果物（プロダクト / サービス / 所産）

• 優先度

• テスト・シナリオ
  要求事項のテスト方法とフェーズ

• オーナー
  要求事項のオーナー、合否判定も行う。

• 状態

• 例２
  IPAの例、こちらの例はVモデルに準拠。
  • 要求仕様
  • システム設計書
  • 基本設計書
  • 詳細設計書
  • ソースコード
  • 単体検査仕様書
  • 結合検査仕様書
  • システム検査仕様書

• これにより、
  • 要求事項がプロジェクト目標、ビジネス目標にリンクされる。
  • プロジェクト完了時の事業価値の実現の可能性が高くなる。

スコープ定義 †

• インプットをプロセス（ツールと技法）で処理してプロジェクト・スコープ記述書を作成する。

• プロジェクト・スコープの定義が
  成果物（プロダクト / サービス / 所産）（プロダクト・スコープ）を厳密に定義することにつながる。

• プロジェクトの成功に直結
  • プロセスの正確さと完全性に特に注意する必要がある。
  • 不完全な定義は、コスト増加、手直し、スケジュール遅れ、士気の低下を招く。

• 収集された要求事項をプロジェクトに含めるかどうかはこのプロセスで決定する。

• 以下の作成と文書化にも利用される。
  • 成果物（プロダクト / サービス / 所産） 自体
  • 成果物（プロダクト / サービス / 所産）の生成に必要な作業

インプット †

要求事項 → 成果物（プロダクト / サービス / 所産）の詳細な説明
予備的なスコープに含まれれている情報を収集する。

プロセス（ツールと技法） †

専門家の判断 †

プロダクト分析 †

プロダクトの最終結果がプロダクトであるとき最も役に立つ。

• インプット・アウトプット

• インプット
  • プロジェクト目標
  • プロダクト・スコープ記述書

• アウトプット（重要成功要因）
  合意されてた基準に基づいて生成されるようにプロジェクトをマネジメントする。
  • 要求事項（成果物（プロダクト / サービス / 所産）の仕様）
  • 成果物（プロダクト / サービス / 所産）（測定可能なゴールや目標の構成要素を記述）

• 構成要素
  • 価値分析、価値工学
  • システム分析、システム工学
  • プロダクト・ブレークダウン、機能要求事項

代替案生成 †

プロジェクト作業を実行するための異なる技法・方法を発見する技法

• ブレーン・ストーミング

• 水平思考（ ---> 水平思考パズル）

• ランダム発想法
  無作為に選び、興味分野と関連付けて発想を広げる。

• 刺激的発想法
  誇張、またはその逆を行い、アイデアの源にする。

• 挑戦的発想法
  既成事実を分析し、アイデアの源にする。

• 概念拡散発想法
  ある概念を他の事物に広く応用する。

• 反証的発想法
  説得力のある反証を試みる。

• 一対比較
  判断の対象となる選択肢を2つ一組とし、どちらがよりよいか選択する。

ファシリテーション型ワークショップ †

アウトプット †

プロジェクト・スコープ記述書 †

詳細に、要求事項（重要成功要因）を再文書化する。

• 目的
  すべてのステークホルダーにスコープを理解してもらう。
  • プロジェクト・チームと顧客との合意書。
  • 意思決定の基準として使用する。
  • プロジェクト作業の指揮の際に使用する。
  • 段階的に詳細化され、タスクやアクティビティに分解される。

• 内容
  • 成果物（プロダクト / サービス / 所産） 自体
  • 成果物（プロダクト / サービス / 所産）の生成に必要な作業

大きなプロジェクトでは、個々の成果物（プロダクト / サービス / 所産）ごとに生成される。

プロジェクト・スコープ記述書の構成要素 †

• プロダクト・スコープ記述書
  • 成果物（プロダクト / サービス / 所産）の特性
  • 一部は、プロジェクト憲章に含まれている。

• 受入基準
  成果物（プロダクト / サービス / 所産）の受入のための

• 仕様の定義

• 基準の定義
  • 品質標準
  • 使用適合性
  • パフォーマンス測定基準

• 受入プロセスの定義

• 成果物（プロダクト / サービス / 所産）（重要成功要因）

• 成果物（プロダクト / サービス / 所産）の定義
  • プロダクト / サービス / 所産
  • 補助的な成果物（プロダクト / サービス / 所産）を含むこともある。
  • 測定可能な成果・結果、特定の項目。
  • 具体性のある検証可能なもの。

• 目的
  • 成果物（プロダクト / サービス / 所産）の文書化。
  • プロジェクト期間全体で成果物（プロダクト / サービス / 所産）の進捗を監視する。

• 除外事項
  ステークホルダー・エンゲージメント・マネジメントの継続のため。

• 制約条件
  計画プロセス群の後続を行うための役に立つ。
  （スケジュール作成、見積、プロジェクト・マネジメント計画書作成）

• 三大制約条件
  プロジェクト目標や要求事項を導き出すのにも必要になる。
  三大制約条件にどう対処するかで、範囲と品質が決定される。
  範囲と品質を守るために、時間・予算のバランスを図るケースが多い。
  （時間・予算どちらか一方は可能だが、両方は無理。
  その場合、範囲や品質などの変更が必要になる。）。

• 範囲（スコープ）
• 時間（≒締め切り、≠スケジュール）
• 予算（コスト）

• 競合する要求
  上記に加え、以下のものがある。

• 品質
  プロダクト・スコープ記述書に記述された、
  成果物（プロダクト / サービス / 所産）の仕様によって課せられる。

• 人的資源
  非人的資源の、入手可能性や品質。
  人的資源の、入手可能性やスキル・レベル。

• リスク
  ・・・。

• その他

• スケジュール
  締め切りではなくてアクティビティの日程

• 技術
  リリース時期、テスト完了時期

• 指示
  経営陣からの方針、契約条項など。

• 前提条件
  プロジェクト / ステークホルダーの本当だと信用できる情報（確定ではない）。
  前提条件が間違っていたり、文書化されていなかったりすると、
  それが、プロジェクトにとって命取りになることがある。

• 前提条件の例
  • 主要なチーム・メンバが支障なく働ける。
  • プロジェクト計画の精度（契約締結日、プロジェクト開始日、フェーズ開始日）
  • 調達（ベンダーの納期、製品の入手可能性、コンストラクターの確保可能性）

• プロジェクトの前提条件の例
  • 資材の入手可能性（コモディティは入手容易で値段も手頃）
  • 契約労働者の雇用（景気や地域の労働市場状況によ左右される）

• ステークホルダーの前提条件の例
  • ・・・

• 前提条件の確実化の例
  • ベンダーにコンティンジェンシー・プランの実行を義務付ける。

※ 引掛けが多いが、制約条件は、

• 時間 > コストとなることが多い。
  
• また、資源の調達は予め既知の範囲で限定しない。

プロジェクト・スコープ記述書の承認と発行 †

• プロジェクト憲章と同様に、合意後に承認を受けて発行 / 配布する。
• 公式のアウトプットではなく、全てに合意 / 承認が必要と言う訳ではない。
• これにより、ステークホルダーは能動的プロジェクト参加者で有り続ける。

プロジェクト文書更新版 †

対象のプロジェクト文書の更新後、プロジェクト・スコープ記述書の再発行を行う。

WBS作成 †

• 要求事項（重要成功要因）を明確にした後、作業を構成要素に分解する（要素分解）。
  ※ ワーク・ブレークダウン・ストラクチャー（WBS : Work Breakdown Structure）

• 定義するもの
  • プロジェクト作業スコープ
  • プロジェクト作業の内容

• これにより、構成要素毎に、
  • アクティビティ定義
  • コストと資源の見積
  • スケジュール作成
  • 監視・制御（進捗）
    • WBSセグメントに割り当てられた見積と測定基準によって判断される。

できる。

• 従って、以下で重要な役割を果たす。
  • コスト・資源の見積
  • スケジュール作成
  • 品質マネジメント計画

• このため（重要な前提条件であるコストやスケジュールを狂わせるため）、正確さと完全性が要求される。
  • 正確さ：WBS検証、専門家の判断で正確さを判定できる。
  • 完全性：集合的にプロジェクトのすべての作業を網羅する（100％ルール）。

インプット †

• スコープ・マネジメント計画書
  • WBSの作成方法
  • WBSの承認方法
  • WBSの維持方法

• プロジェクト・スコープ記述書
  主要なインプット。最新版を使用する。

• 要求事項文書
  補助的なインプット。

• ----------
• 組織体の環境要因

• 組織のプロセス資産
  • プロセスと手順、企業知識ベース
  • テンプレート, ツール, etc.

プロセス（ツールと技法） †

要素分解 †

• 目的
  成果物（プロダクト / サービス / 所産）を簡単に
  計画、実行、監視・制御、終結させることができるように要素に分解する。

• 作業
  ブレークダウン・プロセス（要素分解プロセス）の5ステップ。

• プロジェクト・スコープ記述書により、主要な成果物（プロダクト / サービス / 所産）を特定する。

• WBSの構造を決定し、プロジェクト作業を体系化する。

• プロジェクト
  プロジェクト・レベルをWBSの第１レベルとする。

• 主要な成果物（プロダクト / サービス / 所産）とサブ・プロジェクト
  要素分解の第１レベル（＝WBSの第２レベル）として使用する。
  ※ 従って、例えば、各プロダクトを第１レベルに設定することもできる。

• プロジェクト・フェーズ
  要素分解の第２レベル（＝WBSの第３レベル）として使用する。

• プロジェクト要素成果物
  要素分解の最下位レベルをワーク・パッケージ・レベルと言う。

• アクティビティ

• WBSの構成要素を下位レベルの構成要素に分解する。

• 主要な要素成果物を、小さく、管理しやすい作業に対応する要素成果物に分解する。
  ※ WBSの最下位レベル（ワーク・パッケージ・レベル）まで分割する。

• この場合、測定・検証が可能な形式で、要素成果物を定義・記述する必要がある。

• プロジェクト・チームの外部で実施される可能性のあるサブ・プロジェクトのWBS

• 契約作業の一環として、納入者（コンストラクター、サプライヤー、別の部署）によってWBSが作成される。

• このため、実施時期が近くならないとWBSが作成されないことがある。
  ローリング・ウェーブ計画法では現時点で解っている範囲で詳細化する。

• このサブ・プロジェクトは元プロジェクトのワーク・パッケージ・レベルになる。
  サブ・プロジェクトは、要素分解の第１レベル（＝WBSの第２レベル）で、
  元プロジェクトのワーク・パッケージ・レベルと同じ階層でなくてイイ。

• WBSの構成要素にWBSコードを割り当てる。

• 各レベルに割り当てられたIDをハイフンで繋げてWBSコードを作成

• この識別コードはコントロール・アカウントと呼ばれ追跡に使用される。

• コストの追跡の場合、会計システムの勘定科目に関連付けられる。
  ※ 作業時間・割当資源の追跡というひっかけがあったが、「コスト追跡」が目的。

• WBSを検証する。
  構成要素が明確で完全なものであるか判断する。
  • 絶対不可欠なものか？
  • 作業を記述するに十分なものか？

• 補足
  • ワーク・パッケージ・レベル

• チーム・メンバにとって解り易く、適切な時間内に完了するようにする。
  過度の分解は非効率であり、細部までの定義はチーム・メンバの創造性を阻害する。

• ワーク・パッケージ・レベルを、測定・検証の責任を持つ組織に割り当てる。

• ワーク・パッケージ・レベルによって、コストと資源の見積、スケジュール作成を行う。

• ワーク・パッケージ・レベルは、アクティビティより上位になる。
  （通常、アクティビティはWBSの一部ではないということになっているため）
  しかし、小規模プロジェクトでは＝アクティビティというケースもある。

専門家の判断 †

• 上級管理職（立上の人物/組織）
• プロジェクト・スポンサー
  （オーナー、イニシエータ、顧客であることもある）
• 業界の専門家
• 専門的な訓練を受けたチーム・メンバ
• 類似プロジェクトの経験のあるPM

アウトプット †

スコープ・ベースライン †

• 補助計画書（ベースライン）の一部。
• プロジェクト・スコープ記述書で定義された作業を
  ブレークダウンして更に厳密に定義する。

• 内容
  プロジェクトのすべての作業が記載される。
  • 承認済みの、プロジェクト・スコープ記述書
  • WBS
  • WBS辞書

• 利用
  • アクティビティ定義
  • コストと資源の見積
  • スケジュール作成
  • 監視・制御（進捗）

WBS辞書 †

• 概要
  • スコープ・ベースラインの子要素。
  • 作業構成要素の内容が文書化される。

• 要素
  • WBS識別コード
  • 作業の記述
  • 前提条件
  • 制約条件
  • 担当組織

• 重要な前提条件
  • コストの見積
  • 資源の見積
  • スケジュール
    スケジュール・マイルストーン
    関連するスケジュール・アクティビティ
    
  • 品質要求事項

• 受入基準
• 技術的参照資料
• 合意情報

プロジェクト文書更新版 †

対象のプロジェクト文書の更新作業を行う。

• 要求済み変更の見直し
• 修正対象の修正
• 変更管理プロセスを利用して変更を承認 / 却下
• 修正対象に反映（プルリク・マージ的な）

     

Site admin: TechInfoOfMicrosoftTech

PukiWiki 1.4.7 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji. Powered by PHP 5.3.3. HTML convert time: 0.157 sec.