PMP：計画 - 時間 のバックアップ(No.16)

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

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

---

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

• 戻る

目次 †

概要 †

計画 - スケジュール・プロセスの主要な役割 †

• 後続の実行、監視・制御のプロセス群では、
  ココで決めた文書を使用して、プロジェクトの進捗状況を測定・評価する。

• 作業
  • スケジュール・マネジメント計画書を作成し、
  • WBSを使用して、アクティビティを順番に並べ、
  • 実行に必要な資源と時間を見積もり、
  • 最後に、プロジェクト・スケジュール, etc. を作成する。

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

スケジュール・マネジメント計画 †

インプット †

この中で、プロジェクト・マネジメント計画書には、

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

が含まれる。

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

専門家の判断 †

データ分析 †

(p) 代替案生成

会議 †

アウトプット †

スケジュール・マネジメント計画書 †

• プロジェクト・スケジュールの作成と、
  実行、監視・制御する方法を記述する。

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

• 以下の要素から構成される。

• スケジュール・モデル
  • 方法論
  • ツール（MS Project, etc.）

• 正確さのレベル、測定単位
  アクティビティの端数処理の単位：週、日、時間

• コントロールの閾値
  スケジュールの許容差異レベル：％、日、時間（たいてい％）

• パフォーマンスの測定規則
  • 測定の時期：WBSのレベルを指定
  • 測定の種類：アーンド・バリュー（予算・スケジュールの観点で定量的に評価）

アクティビティ定義 †

• ワーク・パッケージ・レベルを更に分解して、アクティビティを定義する。
• こてにより、簡単に、見積もり、スケジュール、割当などのコントロールするための基盤を構築する。

• アクティビティは、
  • 成果物を生成するために実行する個別の作業単位である。
  • 成果物・アクティビティは、名詞か？動詞か？で区別する。

• 実際には
  • WBS作成
  • アクティビティ順序設定

を同時に行い、完了させる。

インプット †

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

要素分解 †

ローリング・ウェーブ計画法 †

• 一種の段階的詳細化
• サブ・プロジェクトのアクティビティ定義は、
  サブ・マネージャーに委任することがある。

専門家の判断 †

テンプレート †

また、過去のアクティビティ・リスト（このプロセスのアウトプット）を、テンプレートとして使用することもできる。

アウトプット †

アクティビティ・リスト †

チーム・メンバが作業の内容と実行方法を理解できるようにする。

• 構成要素
  • スケジュール・アクティビティのアクティビティ名と同じ、
    プロジェクトで実行されるすべてのアクティビティ名。
  • 各アクティビティ名に対応する作業範囲の説明と識別子（コード or 番号）

アクティビティ属性 †

• アクティビティ・リストを拡張したもの。
• アクティビティの特性を記述する。
• 後述のスケジュール作成プロセスのインプットとなる。

• 項目（段階的詳細化）

• 上流
  • アクティビティID
  • WBS識別コード
  • アクティビティ名

• 下流
  • 先行 / 後続アクティビティ
  • 論理的順序関係
  • リードとラグ
  • 資源に対する要求事項
  • 前提条件・制約条件

マイルストーン・リスト †

• マイルストーン

• 大きな目標
  • 成果物の完了
  • 重要なイベント

• 例
  • 契約の承認
  • プロジェクト成果物の承認
  • プロトタイプの作成
  • システム・テストの完了

• マイルストーン・リスト
  • 成果の記録
  • 必須 / 任意の文書化

• アクティビティ順序設定プロセスのインプットとなる。

プロジェクト・マネジメント文書更新版 †

必要に応じて更新する。

アクティビティ順序設定 †

• アクティビティを正しい順番に並べる。

• 実際には
  • WBS作成
  • アクティビティ定義

を同時に行い、完了させる。

インプット †

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

依存関係の決定 †

プレシデンス・ダイアグラム法（PDM） †

リードとラグ †

スケジュール・ネットワーク・テンプレート †

• また、過去のプロジェクト・スケジュール・ネットワーク図（このプロセスのアウトプット）を、テンプレートとして使用することもできる。
• 部分的に適用するテンプレートは、サブ・ネットワーク・テンプレート、部分ネットワーク・テンプレートと呼ぶ。

アウトプット †

プロジェクト・スケジュール・ネットワーク図 †

• 手作業で作成してもコンピューターで作成しても良い。

• プロジェクトの複雑さによって記載のレベルは異なる。

• 複雑：概要レベルの情報のみ含まれているケース
  • 関連あるアクティビティの集合（ハンモック）
  • ハンモック：関連あるアクティビティのグループをひとまとめにし、
    そのグループに含まれるアクティビティに相応しい表題を付与したもの。

• 単純：全ての詳細情報が含まれているケース

• 表現方法

• ガントチャート / バーチャート
  管理者向けの広く使われている読みやすい図。

• マイルストーン・チャート
  経営層向けのハイレベルなガントチャート / バーチャート

• スケジューリング・ソフトウェアを使用する。

• 効果
  アクティビティ・リストで、
  • 見逃していたアクティビティが、浮上したり、
  • １つで済むと思っていたアクティビティが、２つに分割されたり、

するので、プロジェクト文書を更新する。

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

必要に応じて更新する。

アクティビティ資源見積(6) †

スケジュール → 資源に移動。

アクティビティ所要期間見積 †

必要な時間を、スケジュール作成に入力できるように見積もる。

インプット †

組織のプロセス資産にプロジェクト・カレンダーがある。

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

所要期間見積 †

その他 †

• グループ意思決定技法

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

• デルファイ法 多数の専門家や個人にアンケート調査を行い、結果を回答者にフィードバック、
  さらに予測を繰り返し、予測の正確度を上げながら、全体の答えや意見を絞る。

• ノミナル・グループ技法
  ブレーン・ストーミングに投票プロセスを加え、結論を出す方法。

• 予備設定分析
  • コンティンジェンシー予備
    • スケジュール・ベースラインに含まれる。
    • リスク計画プロセスで特定される作業（既知の未知）に使用される。

• マネジメント予備
  • スケジュール・ベースラインに含まれない（所要期間全体の要求事項の一部）。
  • 不測のリスク（未知の未知）発生に対処するための予備の予算や期間
  • 発生した場合は、スケジュール・ベースラインの変更が必要になる。

• スケジューリング・ソフトウェアを使用できる。
  • プロジェクト・カレンダーを入力
  • 所要期間を入力
  • 所要期間を出力

アウトプット †

アクティビティ所要期間見積 †

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

必要に応じて更新する。

スケジュール作成 †

• 計画プロセス群の中の中心的なプロセス。

• スケージュールの作成
  • 開始/終了日
  • 所要期間
  • スケジューリング・ソフトウェアに入力

• 承認後、ベースラインを追跡開始。

インプット †

プロジェクト・スコープ記述書の、前提条件・制約条件が特に重要になる。

前提条件 †

制約条件 †

時間の制約

• 指摘日
  • アクティビティの開始/終了日に影響を与える。
  • スケジューリング・ソフトウェアが処理する。

• 重要なイベント、主要なマイルストーン
  • 特定の期日までに特定の成果物を完成させる必要がある。
  • ステークホルダー・顧客との引渡期日の
    合意（口頭/思い込みも含まれる）も制約条件になる。

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

スケジュール・ネットワーク分析 †

• プロジェクト・スケジュール・モデルを作成する包括的な技法。

• 以下の技法を使用してプロジェクトの最早/最遅 開始日、最早/最遅 終了日を計算する。
  • クリティカル・パス法
  • クリティカル・チェーン法(6)
  • 資源最適化技法
  • モデリング技法

• 資源の制約を考慮しないので理論上の期日になるので、
  アクティビティ予定の見当を付ける用途で使用する。

クリティカル・パス法 †

• CP : クリティカル・パス
• CPM : クリティカル・パス法

クリティカル・チェーン法(6) †

※ PMBOK 第6版で活用ケースの少ないということで削除されている。

• スケジュール・ネットワーク分析の１技法
• 資源の限られた or 予測不可能なプロジェクトの問題に対処できる。

• クリティカル・パス法の入力に
  • 制約条件
  • 資源の可用性

を加えることにより、プロジェクト・バッファ、合流バッファ、リソース・バッファ
などのバッファー・アクティビティを加え、CPを保護し、その所要期間を管理する。

• リソースが十分に存在し、各作業での競合が発生しない場合、
  クリティカル・チェーンとクリティカル・パスは同じになる。

資源最適化技法 †

モデリング技法 †

リードとラグ †

スケジュール短縮 †

プロジェクト・マネジメント情報システム（PMIS） †

アジャイルのリリース計画 †

• プロダクト進展のための

• プロダクト・ロードマップと
• プロダクト・ビジョン

に基づいて

• リリース・スケジュール
• ハイレベルの要求タイムライン

を提示する。

• リリース内のイテレーションやスプリント数を設定する。

• リリース

• スプリント
  • イテレーション１
  • イテレーション２
  • ・・・
  • イテレーションｎ

• ユーザ・ストーリ
  • フィーチャー１
  • フィーチャー２
  • ・・・
  • フィーチャーｎ

• タクス
  • タクス１
  • タクス２
  • タクス３

アウトプット †

プロジェクト・スケジュール †

• 以下の内容に基づく
  • タイムライン
  • スコープ文書
  • 資源計画書

• 以下の結果を含む
  • アクティビティ順序設定
  • アクティビティ所要期間見積
  • スケジュールの制約条件の検討結果
  • 資源に対する要求事項の分析結果

• 内容
  • アクティビティの開始日 / 終了日
  • アクティビティの所要期間
  • アクティビティの依存関係
  • マイルストーン、資源など。

• 資源について
  • 資源の割り当ては、[[資源の獲得>]](6)で行われる。
  • コレが完了していない場合、スケジュールは暫定的なものと看做される。

• 承認
  • ステークホルダーと機能部門マネージャの承認を得る必要がある。
  • 期日と資源に対する確約は、協力の確認にもなる。
  • 承認されたものがスケジュール・ベースラインになる。

スケジュール・ベースライン †

補助計画書（ベースライン）の一部。

スケジュール・データ †

• スケジュールの根拠となるデータが記載された文書。

• 最小限
  • マイルストーン
  • スケジュール・アクティビティ
  • アクティビティ属性
  • スケジュールの前提条件・制約条件

• 推奨（PMBOK）
  • コンティンジェンシー予備
  • 代替スケジュール案
  • [[資源ヒストグラム>]]

プロジェクト・カレンダー †

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

必要に応じて更新する。

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

必要に応じて更新する。

ツールと技法 †

依存関係の決定 †

強制依存関係 †

• ハード・ロジック、ハード依存症とも呼ぶ。
• 作業内容でアクティビティの順番が決まる。
• 例：ペンキ剥ぎ、下地塗り、ペンキ塗り

任意依存関係 †

• 優先ロジック、ソフト・ロジック、選好ロジックとも呼ぶ。
• プロセス・手順、過去の経験によって導かれる。
• 例：大まかにスプレー塗装、細かい部分は手作業。

• 試験に出る。
  • 不規則なトータル・フロート値（最大余裕時間）を生成し、
    スケジュールの選択肢を狭める可能性がある（何故かが不明）。
  • 故に、ファスト・トラッキングの際には、変更・削除の検討対象になる。

外部依存関係 †

• プロジェクト外部の依存関係
• 例：プロジェクト外部の何らかの認可（法律の認可）がおりないと、先に進めない。

内部依存関係 †

• プロジェクト内部の依存関係
• 例：プロジェクト・組織内部の何らかの認可（内規の認可）がおりないと、先に進めない。

プレシデンス・ダイアグラム法（PDM） †

特徴 †

一点見積（？）ダケを使用して所要期間を決定する。

図 †

• ノード = アクティビティ
  アクティビティ・オン・ノード（AON）

• 名
• 番号
• 開始・終了日
• 期限
• フロート（= スラック）

• 矢印 = 順序関係
  論理的順序関係、プレシデンス順序関係

順序関係 †

• 終了‐ 開始（FS）
  先行を終了しないと後続を開始できない（多）。
• 開始‐ 終了（SF）
  先行を開始しないと後続を終了できない（僅）。

• 並行
  • 終了‐ 終了（FF）
    行を終了しないと後続を終了できない。
  • 開始‐ 開始（SS）
    先行を開始しないと後続を開始できない。

アロー・ダイアグラム法（ADM） †

• 前置き
  • 古い、ほとんど使われない。
  • 業界によっては、PDMよりADMを好む業界がある。
  • アクティビティ順序設定ツール・技法に含まれない。
  • しかし、試験には出るらしい。

• 特徴
  • 終了‐開始（FS）の依存関係だけを使用し、
    多点見積（？）ダケを使用して所要期間を決定する。

• 図
  • ノード = 終了‐ 開始（FS）
  • 矢印 = アクティビティ
    • アクティビティ・オン・アロー（AOA）
    • アクティビティ・オン・ライン（AOL）

GEAT（Graphical Evaluative Review Technique） †

• 条件分岐法。

• 作業のネットワークを示す手法で、
  条件による分岐・合流、ループを表すことができる。

• GERTは複数の仕事のうちどれかひとつが実施されればプロジェクト自体は
  完成するという不確定要素のはいった場合を取り扱うことを目標とする。

リードとラグ †

ラグ †

• 後続アクティビティが遅れる（アクティビティ間で時間が経過すると発生）。
• 後続のアクティビティの開始（日）・終了（日）が遅れる。
• 例：下地塗りの後、下地が乾くのを待ってからペンキ塗りを開始した。

リード †

• 後続アクティビティを早める。
• 後続のアクティビティの開始（日）・終了（日）を早める（時間を差し引く）。
• 例：ペンキ剥ぎが不要な部位があったため、下地塗りを開始した。

所要期間見積 †

類推見積 †

• 概要
  • プロジェクトの総体（全体）を見積る方法
  • トップダウン見積もりとも呼ばれる一種の、専門家の判断。
  • 過去のプロジェクト情報が文書化保存されていることが前提。
  • アクティビティの経験者に見積もり作業を担当させる。

• 特徴
  • プロジェクト情報が限られているときに有用。
  • 時間がかからずコストも低いが制度が劣ることがある。

パラメトリック見積 †

• 概要
  • プロジェクトの全体や一部を見積る方法
  • アルゴリズム（作業量 * 単価）と過去データの併用

• 特徴
  以下のケースで正確
  • 過去データと変数間に統計的な関係がある。
  • 上記のデータの信頼性が高い。

三点見積 †

• 概要 以下の平均値を求める。
  • 最頻値(tM)：最も可能性が高い
  • 楽観値(tO)：最良のケース
  • 悲観値(tP)：最悪のケース
  • 平均値
    • 三角分布の期待値：tE = (tO + tM + tP) / 3
    • ベータ分布の期待値：：tE = (tO + 4tM + tP) / 6

• 特徴
  類推見積と併用する。

ボトムアップ見積 †

• 概要
  • WBSの下位レベルの構成要素単位に見積・集計する。
  • 必要に応じて、アクティビティ内の作業をさらに分解する。

• 特徴
  • 最も制度が高い。
  • ただし、バッファが多くなる。

クリティカル・パス法 †

概要 †

クリティカル・パス法（CPM）は、

• スケジュール・ネットワーク分析の１技法
  • プロジェクトの最早/最遅 開始日、最早/最遅 終了日を（資源の制約を考慮せず）計算する。
  • 各ネットワーク・パスのフロート（= スラック）量（スケジュールの柔軟性）を計算する。
  • プレシデンス・ダイアグラム法（PDM）を使用してクリティカル・パス法（CPM）を実行することもできる。

• 前提

• 逐次ネットワーク（終了‐開始（FS））
  • アクティビティが次のアクティビティの前に実行される。
  • 一連のアクティビティが完了してから一連のアクティビティが開始する。

• アクティビティごとに１つの所要期間

• クリティカル・パス（CP）

• プロジェクトの最長の経路

• フロートが０やマイナスになるアクティビティがCPタスクになる。

• CPタスクの所要期間の合計値が、CPの所要期間。

• フロートを持つアクティビティがフロートを使い果たすと、そのアクティビティがCPタスクになる。

• 制約条件のマイルストーンなどで、CPが変化することがある。

• フロート（= スラック）

• トータル・フロート（TF）
  プロジェクトの終了日を遅らせることなく、
  タスクの開始日を遅らせる事ができる期間。
  

• フリー・フロート（FF）
  後続タスクの最早開始日を遅らせることなく、
  タスクの開始日を遅らせる事ができる期間。
  

サンプル †

• アクティビティ・依存関係の情報収集

• CPの図
  （プロジェクト・スケジュール・ネットワーク図）

• CPMの計算シート

• アクティビティ番号
• アクティビティの説明

• 依存関係
  開始前に終了しなければならないアクティビティの番号を記入

• 所要期間
  月, 日, 時などの単位を指定して記入。開始日・終了日なら日

• 最早開始日
• 最早終了日

• 最遅開始日：フロート 0 のCPでは、= 最早開始日
• 最遅終了日：フロート 0 のCPでは、= 最早終了日

• フロート（= スラック） = 最遅終了日 - 最早開始日

• 往路時間計算と復路時間計算

• 往路時間計算：
  最早開始日、最早終了日を求めることができる。

• 最早開始日：
  CPの先頭アクティビティの開始日
  or 前のアクティビティの最早終了日（合流するときは遅い方）の翌日。

• 最早終了日：
  = 最早開始日 + 所要期間 - 1

• 復路時間計算：
  最遅開始日、最遅終了日を求めることができる。

• 最遅終了日：
  CPの末端アクティビティの最早終了日
  or 前のアクティビティの最遅開始日（合流するときは早い方）の前日。
  

• 最遅開始日：
  = 最遅終了日 - 所要期間 + 1

パート技法 †

概要 †

PERT : Program Evaluation and Review Technique

• あまり使われていないが、大規模・複雑なプロジェクトでは有用。

• CPMでは所要期間を使用したが、PERTでは、
  所要期間を三点見積（ベータ分布）で処理した期待値（加重平均）を使用する。

• 期待値（加重平均）= (tO + 4tM + tP) / 6
• 標準偏差 = (tP - tO) / 6

• 標準偏差毎の確率
  分布で、標準偏差毎の確率が決まっている。
  • ± 1 標準偏差 : 68.26%
  • ± 2 標準偏差 : 95.44%
  • ± 3 標準偏差 : 99.73%

• 更に、各アクティビティの標準偏差を求めれば信頼係数を割り当てることができる。

サンプル †

• アクティビティ・依存関係の情報収集

• CPの図
  （プロジェクト・スケジュール・ネットワーク図）

• パート技法の計算シート

• アクティビティ番号
• アクティビティの説明

• 最頻値(tM)：最も可能性が高い
• 楽観値(tO)：最良のケース
• 悲観値(tP)：最悪のケース
• 期待値（ベータ分布）：= (tO + 4tM + tP) / 6

• 標準偏差：= (tP - tO) / 6
• 標準偏差の2乗：標準偏差 * 標準偏差

• CPの期待値と標準偏差を計算する。

• CPの期待値は、各アクティビティの期待値を合計する。

• CPの標準偏差は以下で算出する。
  • 各アクティビティの標準偏差の2乗を合計する。
  • 上記の合計値の平方根を求める。

資源最適化技法 †

クリティカル・パス法をベースとするが、

• クリティカル・パス法
• パート技法

では考慮しない、資源の可用性を考慮に加えている。

• 資源 余剰（割当不足）の場合は、
  複数のアクティビティのタスクを割り当てる。

• 資源 不足（割当超過）の場合は、
  以下の 3 つの技法を使用する。

資源平準化 †

資源ベース技法とも呼ばれる。

フロート（= スラック）を活用するが、
資源の可用性に基づいてCPを変更する。

• 以下のケースで使用する。
  • 資源 不足（割当超過）の場合
  • 資源が特定の時期にしか利用できない場合
  • 資源が同時に複数のアクティビティに割当られている場合

• 資源の不均衡を解決するために、資源の可用性に基づいて開始日・終了日を調整する。
  • 先ず、CPに資源を割り当てる。
  • 2つの方法で資源平準化を実行する。
    • 重要なチーム・メンバのスケジュールに合わせて開始日を遅らせる。
    • 割当不足のチーム・メンバにタスクが割当られるように調整する。

資源円滑化 †

フロート（= スラック）の範囲内で調整することでCPを変更しない。

• 割当不足のチーム・メンバにタスクを割当てる（残業強制もある）。

• フロート（= スラック）のあるタスクに割当てられているチーム・メンバを、
  CP上のタスクに割り当てる（ファスト・トラッキング）。

• スキルの優れたチーム・メンバを、
  優先度の高いタスク（CP上のタスク、重要なタスク）に割当てる。

逆資源配分スケジューリング †

逆資源ベース法とも呼ばれる。

• ある人的資源がアクティビティを実行できる唯一の資源である場合などに使用される。
• 開始日からではなく終了日からアクティビティに人的資源を割り当てる（なぜ？）。

モデリング技法 †

What-If分析 †

• 複数の前提条件に基づいて複数の所要期間を算出。
• 悪条件化でのプロジェクト・スケジュールの実行可能性を判断できる。
• または、リクス対応やコンティンジェンシー計画の準備に役立つ。

シミュレーション †

• 各アクティビティの所要期間の確率分布を三点見積などで定義する。
• これに基づいて、プロジェクト全体の所要期間の確率分布を計算する。

モンテカルロ分析 †

• アクティビティの所要期間の確率分布、スケジュール予想の計算を繰り返す。
• これにより、予測の確率、CPの所要期間とフロート（= スラック）を算出する。

スケジュール短縮 †

• 「スコープを変更させることなく」、所要期間を短縮する一種の数学的分析

• CPMやPERTで分析を行った結果、
  当初予定していた期間に収まらなくなった場合に行われる可能性がある。

クラッシング †

• コストとスケジュールのトレードオフを検討する短縮技法
• 最小のコストで、最大のスケジュール短縮を試行する。

• CPに資源を追加することによって短縮が行われる。
  • 強制残業
  • 翌日配送

• クラッシングによって、コストやリクスが高まるコトがある。

• CPが変化するので、CPの確認（再計算）を行う。

ファスト・トラッキング †

• マルチフェーズ・プロジェクト＝重複関係化による短縮技法。

• 重複実行可能なアクティビティのタスクに対してのみ適用できる。
  （そう言えば昔インターフェイスで切って、並行開発するって思想があった）

• ファスト・トラッキングによって、リクスが高まるコトがある。

     

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.165 sec.