電子文書(法令、タイムビジネス関連制度)2019-12-27Reactの5thステップ2019-12-20WWWブラウザの[×]ボタンのイベントをハンドルする。.NET開発基盤部会」によって運営されています。後続の実行、監視・制御のプロセス群では、ココで決めた文書を使用して、プロジェクトの進捗状況を測定・評価する。†この中で、プロジェクト・マネジメント計画書には、プロジェクト・ライフサイクルと、スコープ・ベースラインプロジェクトのすべての作業が記載される。承認済みの、プロジェクト・スコープ記述書WBSWBS辞書が含まれる。プロセスの相互作用と依存関係から、変更の反映方法を記述する。以下の要素から構成される。†ワーク・パッケージ・レベルを更に分解して、アクティビティを定義する。こてにより、簡単に、見積もり、スケジュール、割当などのコントロールするための基盤を構築する。所産)を生成するために実行する個別の作業単位である。所産)・アクティビティは、名詞か?動詞か?で区別する。実際にはWBS作成アクティビティ順序設定を同時に行い、完了させる。†WBSの要素分解所なり、アウトプットは、スケジュール・アクティビティになる。一種の段階的詳細化サブ・プロジェクトのアクティビティ定義は、サブ・マネージャーに委任することがある。†また、過去のアクティビティ・リスト(このプロセスのアウトプット)を、テンプレートとして使用することもできる。†チーム・メンバが作業の内容と実行方法を理解できるようにする。構成要素スケジュール・アクティビティのアクティビティ名と同じ、プロジェクトで実行されるすべてのアクティビティ名。†アクティビティ・リストを拡張したもの。アクティビティの特性を記述する。後述のスケジュール作成プロセスのインプットとなる。任意の文書化アクティビティ順序設定プロセスのインプットとなる。必要に応じて更新する。†アクティビティを正しい順番に並べる。実際にはWBS作成アクティビティ定義を同時に行い、完了させる。†また、過去のプロジェクト・スケジュール・ネットワーク図(このプロセスのアウトプット)を、テンプレートとして使用することもできる。部分的に適用するテンプレートは、サブ・ネットワーク・テンプレート、部分ネットワーク・テンプレートと呼ぶ。手作業で作成してもコンピューターで作成しても良い。プロジェクトの複雑さによって記載のレベルは異なる。複雑:概要レベルの情報のみ含まれているケース関連あるアクティビティの集合(ハンモック)ハンモック:関連あるアクティビティのグループをひとまとめにし、そのグループに含まれるアクティビティに相応しい表題を付与したもの。バーチャート管理者向けの広く使われている読みやすい図。バーチャートスケジューリング・ソフトウェアを使用する。見逃していたアクティビティが、浮上したり、1つで済むと思っていたアクティビティが、2つに分割されたり、するので、プロジェクト文書を更新する。必要に応じて更新する。必要な時間を、スケジュール作成に入力できるように見積もる。組織のプロセス資産にプロジェクト・カレンダーがある。†コンティンジェンシー予備リスク計画プロセスで特定される作業(既知の未知)に使用される。スケジュール・ベースラインに含まれる。不測のリスク(未知の未知)発生に対処するための予備の予算や期間スケジュール・ベースラインに含まれない(所要期間全体の要求事項の一部)。発生した場合は、スケジュール・ベースラインの変更が必要になる。†スケジューリング・ソフトウェアを使用できる。範囲の可能性を含める場合、100±10時間などと表記する。必要に応じて更新する。計画プロセス群の中の中心的なプロセス。承認後、ベースラインを追跡開始。†プロジェクト・スケジュール・モデルを作成する包括的な技法。資源の制約を考慮しないので理論上の期日になるので、アクティビティ予定の見当を付ける用途で使用する。第6版で活用ケースの少ないということで削除されている。資源の可用性を加えることにより、プロジェクト・バッファ、合流バッファ、リソース・バッファなどのバッファー・アクティビティを加え、CPを保護し、その所要期間を管理する。タスクごとにバッファをとるのではなく、全タスクの後ろでまとめてバッファをとる。予測不可能なプロジェクトの問題に対処できる。リソースが十分に存在し、各作業での競合が発生しない場合、クリティカル・チェーンとクリティカル・パスは同じになる。†プロダクト進展のためのプロダクト・ロードマップとプロダクト・ビジョンに基づいてリリース・スケジュールハイレベルの要求タイムラインを提示する。リリース内のイテレーションやスプリント数を設定する。†ココのアウトプットを使用して、プロジェクトの進捗状況を測定・評価する。補助計画書(ベースライン)の一部。承認プロジェクト・スケジュールを承認したもの。ステークホルダーと機能部門マネージャの承認を得る必要がある。期日と資源に対する確約は、協力の確認にもなる。終了日アクティビティの所要期間アクティビティの依存関係マイルストーン、資源など。資源について資源の割り当ては、資源の獲得(6)で行われる。コレが完了していない場合、スケジュールは暫定的なものと看做される。†スケジュールの根拠となるデータが記載された文書。†プロジェクトの稼働日を表す。必要に応じて更新する。必要に応じて更新する。†ハード・ロジック、ハード依存症とも呼ぶ。作業内容でアクティビティの順番が決まる。優先ロジック、ソフト・ロジック、選好ロジックとも呼ぶ。プロセス・手順、過去の経験によって導かれる。例:大まかにスプレー塗装、細かい部分は手作業。不規則なトータル・フロート値(最大余裕時間)を生成し、スケジュールの選択肢を狭める可能性がある(何故かが不明)。例:プロジェクト・組織内部の何らかの認可(内規の認可)がおりないと、先に進めない。一点見積(?)ダケを使用して所要期間を決定する。先行を終了しないと後続を開始できない。終了(FF)先行を終了しないと後続を終了できない。開始(SS)先行を開始しないと後続を開始できない。終了(SF)先行を開始しないと後続を終了できない。移行先システムが開始するまで移行元システムを終了できない(稀)。前置き古い、ほとんど使われない。業界によっては、PDMよりADMを好む業界がある。アクティビティ順序設定ツール・技法に含まれない。多点見積(?)ダケを使用して所要期間を決定する。条件による分岐・合流、ループを表すことができる。GERTは複数の仕事のうちどれかひとつが実施されればプロジェクト自体は完成するという不確定要素のはいった場合を取り扱うことを目標とする。後続アクティビティが遅れる(アクティビティ間で時間が経過すると発生)。後続のアクティビティの開始(日)・終了(日)が遅れる。例:下地塗りの後、下地が乾くのを待ってからペンキ塗りを開始した。後続アクティビティを早める。後続のアクティビティの開始(日)・終了(日)を早める(時間を差し引く)。概要プロジェクトの総体(全体)を見積る、一種の専門家の判断。過去のプロジェクト情報が文書化保存されていることが前提。アクティビティの経験者に見積もり作業を担当させる。特徴プロジェクト情報が限られているときに有用。時間がかからずコストも低いが制度が劣ることがある。従って、他の見積手法(三点見積)と併用して利用される。過去データと変数間に統計的な関係がある。上記のデータの信頼性が高い。6特徴リスクと不確実性を含めることで精度を上げる。類推見積(トップダウン見積)と併用する。概要WBSの下位レベルの構成要素単位に見積・集計する。必要に応じて、アクティビティ内の作業をさらに分解する。正確な見積もりが可能と言われている。制度は高いが、ただし、バッファが多くなる。終了日を(資源の制約を考慮せず)計算する。スラック)量(スケジュールの柔軟性)を計算する。逐次ネットワーク(終了‐開始(FS))アクティビティが次のアクティビティの前に実行される。一連のアクティビティが完了してから一連のアクティビティが開始する。従って、アロー・ダイアグラム法(ADM)ベース。プレシデンス・ダイアグラム法(PDM)を使用することもできるらしい。アクティビティごとに1つの所要期間クリティカル・パス(CP)プロジェクトの最長の経路トータル・フロートが0やマイナスになるアクティビティがCPタスクになる。CPタスクの所要期間の合計値が、CPの所要期間。フロートを持つアクティビティがフロートを使い果たすと、そのアクティビティがCPタスクになる。制約条件のマイルストーンなどで、CPが変化することがある。スラック)トータル・フロート(TF)プロジェクトの終了日を遅らせることなく、タスクの開始日を遅らせる事ができる期間。トータル・フロートはプラスになる場合とマイナスになる場合がある。プラス:余裕(往路計算の最早終了日より復路計算の最遅終了日が遅い)マイナス:スケジュールが逸脱している場合。フリー・フロート(FF)後続タスクの最早開始日を遅らせることなく、タスクの開始日を遅らせる事ができる期間。前のアクティビティの最早終了日(合流するときは遅い方)の翌日。前のアクティビティの最遅開始日(合流するときは早い方)の前日。Techniqueあまり使われていないが、大規模・複雑なプロジェクトでは有用。所要期間を三点見積(ベータ分布)で処理した期待値(加重平均)を使用する。6標準偏差毎の確率ベータ分布で、標準偏差毎の確率が決まっている。99.73%更に、各アクティビティの標準偏差を求めれば信頼係数を割り当てることができる。標準偏差CPの期待値と標準偏差を計算する。CPの期待値は、各アクティビティの期待値を合計する。CPの標準偏差は以下で算出する。各アクティビティの標準偏差の2乗を合計する。†クリティカル・パス法をベースとするが、クリティカル・パス法パート技法では考慮しない、資源の可用性を考慮に加えている。複数のアクティビティのタスクを割り当てる。スラック)を活用するが、資源の可用性に基づいてCPを変更する。以下のケースで使用する。資源の不均衡を解決するために、資源の可用性に基づいて開始日・終了日を調整する。CPに資源を割り当てる。2つの方法で資源平準化を実行する。重要なチーム・メンバのスケジュールに合わせて開始日を遅らせる。割当不足のチーム・メンバにタスクが割当られるように調整する。スラック)の範囲内で調整することでCPを変更しない。割当不足のチーム・メンバにタスクを割当てる(残業強制もある)。スラック)のあるタスクに割当てられているチーム・メンバを、CP上のタスクに割り当てる(ファスト・トラッキング)。優先度の高いタスク(CP上のタスク、重要なタスク)に割当てる。†ある人的資源がアクティビティを実行できる唯一の資源である場合などに使用される。開始日からではなく終了日からアクティビティに人的資源を割り当てる(なぜ?)。複数の前提条件に基づいて複数の所要期間を算出。不確定要素をマネジメントするために、所要期間バッファーを追加する。悪条件化でのプロジェクト・スケジュールの実行可能性を判断できる。リスク対応やコンティンジェンシー計画の準備に役立つ。各アクティビティの所要期間の確率分布を三点見積などで定義する。これに基づいて、プロジェクト全体の所要期間の確率分布を計算する。†アクティビティの所要期間の確率分布、スケジュール予想の計算を繰り返す。スラック)を算出する。当初予定していた期間に収まらなくなった場合に行われる可能性がある。コストやリスクが高まるコトがある。CPが変化するので、CPの確認(再計算)を行う。重複実行可能なアクティビティのタスクに対してのみ適用できる。(ハード・ロジック)でない任意依存(ソフト・ロジック)であれば適用可能な方法。言えば昔インターフェイスで切って、並行開発するって思想があった。重複実行なだけに、手直しなどのリスクが高まるコトがある。コストやCPに関しては明記されていないが、恐らく、コストは追加しない。CPは、CPが重複実行可能なら短縮可能。