ソフトウェア開発及びソフトウェア プロジェクトマネジメント（VII） 北航软件学院 马 平 博士 副教授 [email protected] レビュー １．プロダクトスコープとプロジェクトスコープの区別は？ ２．スコープ・マネジメントには、（？ ）のプロセスがある。 各プロセスの主なアウトプットは？ ３．プロジェクト憲章の記述項目は？ ４．スコープ記述書とスコープ・マネジメント計画書の明記さ れるべき事項は？ ５．WBSとは？WBSの役割は？ ソフトウェアプロジェクトのWBS例 ソフトウェア プロジェクト 要求分析 外部設計 内部設計 モジュール１ コーディング フェーズ 総合テスト モジュール２ システム テスト モジュール３ 作業分 解 モジュール２ コーディング モジュール２ テスト モジュール２ レビュー モジュール２ ディバーグ プロジェクト マネジメント 第7回 タイム・マネジメント 7.1 アクティビティ定義 7.2 アクティビティ順序設定 7.3 アクティビティ所要期間見積もり 7.4 スケジュール作成 7.5 スケジュール・コントロール 7.6 システム開発における考慮点 タイム・マネジメントのプロセス タイム・マネジメントは次の図に示す ５つのプロセスがある。 タイム・マネジメント アクティビティ定義 計画のプロセス アクティビティ順序設定 計画のプロセス アクティビティ所要期間見積り スケジュール作成 スケジュール・コントロール 計画のプロセス 計画のプロセス コントロールのプロセス 7.1 アクティビティ定義 アクティビティ定義 インプット １．ワーク・ブレークダウン ・ストラクチャー（WBS） 2. スコープ記述書 3．過去の情報 ４．制約条件 ５．前提条件 ６．専門家の判断 ツールと技法 1. 要素分解 ２．テンプレート アウトプット １．アクティビティ・リスト 2. 詳細資料 ３．ワーク・ブレークダウン ・ストラクチャー（WBS） 更新版 7.1.1 WBSでスケジュールを作る例 WBSでスケジュールを作る流れ WBSワークパッケージ アクティビティ アクティビティの所要時間見積り アクティビティ間の順序関係決定 要員決定 アクティビティ実施時期の決定（スケジュール） 7.1.2 アクティビティの定義の例 作業ID 作業名 作業時間 A．01.01 全体設計完了 0 … B.00 プロジェクトマネジメント 172 C.01 全体設計 160 C.02 システムインストール 40 C.03 システムテスト 120 D.01.01 Web デザイン 16 D.01.02 Web 画面構造設計 24 D.01.03 Web 画面製作 120 D.02.01 Web CGI設計 96 D.02.02 Web CGI製作 552 D.03.01 Web プログラミング（統合） 112 D.03.02 Web 単体テスト 96 E.01 … 7.2 アクティビティ順序設定 アクティビティ順序設定 インプット 1. アクティビティ・リスト 2. 成果物記述書 3．強制依存関係 ４．任意依存関係 ５．外部依存関係 ６．マイルストーン(milestone) ツールと技法 １．プレシデンス ・ダイアグラム法 （PDM） ２．アロー・ダイアグラム法 （ADM） 3. 条件ダイアグラム法 ４．ネットワーク・テンプレート アウトプット １．プロジェクト ・ネットワーク図 2. アクティビティ・リスト 更新版 7.2.1 アクティビティ順序設定の技法 ツールと技法は以下のものがある。 ① プレシデンス・ダイアグラム法（PDM） PDMはアクティビティの順序関係を論理的に定義していく手法である。 Activity on Node（AoN）とも呼ばれる。４つの順序関係（ FS、FF、SS、 SF）があり、FS（完了ー開始）が最も一般的である。 ② アローダイアグラム法（ADM） 工程の個々のアクティビティを矢印で表現するもので、ADMは Activity on Arrow（AoA）とも呼ばれる。順序関係は、FS(完了ー開始)のみ。かつ、ダミー （順序関係を表すのみの、所要期間がゼロの作業）（アクティビティの順序を示 すのみで、時間・コストの消費は伴わない）が存在する。 ③ クリティカル・パス（CPM） ４つの依存関係 作業間には次の４つの依存関係が設定できます。 FS（Finish-to-Start）：前の作業が終わると次の作業が始まる。 SS（Start-to-Start）：前の作業が始まると次の作業も始まる。 FF（Finish-to-Finish）：前の作業が終わると次の作業も終わる。 SF（Start-to-Finish） ：前の作業が始まると次の作業が終わる。 7.2.1 アクティビティ順序設定の技法 先行タスク 後続タスク タイプ ラグ（間隔） C.01 D.01.01 FS ０ D.01.01 D.01.02 FS ０ D.01.02 D.01.03 FS ０ D.01.02 D.02.01 FS ０ D.02.01 D.02.02 FS ０ D.01.03 D.03.01 FS ０ D.02.02 D.03.01 FS ０ D.03.01 D.03.02 FS ０ … … … … ＰＤＭ法によるプロジェクト・ネットワーク例 プロジェクト・ネットワーク例 ② ⑤ 5日 機能仕様書 作成 ③ 5日 導入サポート 計画書作成 ④ FS SS 5日 プロジェクト 計画書作成 SS 5日 分析レビュー 実施 PDM法の例 ADM法の例 No. アクティビティ 所要期間 先行タスク A 要求分析 ２５ ― B 設計 １８ A C コーディング １３ B D 単体テスト １０ C E システムテストケースの作成 １２ A F 総合テストケースの作成 １５ B G 総合テスト ５ D,F H システムテスト ７ G,E ADM法の例（１） １ ２５ A ２ １８ B ３ １３ ４ C １０ １５ F D ５ １２ ５ G E ６ ７ H ７ ADM法の例（２） １ ２５ ２ A １８ １３ ３ B ４ C １０ ３ １５ F I D ５ ２’ ５ G １２ E ６ ７ H ７ 7.3 アクティビティ所要期間見積り アクティビティ所要期間見積り インプット 1. アクティビティ・リスト 2. 制約条件 3．前提条件 ４．資源に対する要求事項 ５．資源能力 ６．過去の情報 ７．識別されたリスク ツールと技法 アウトプット １．専門家の判断 ２．類推見積り 3. 定量ベース所要期間 ４．予備時間 （コンティンジェンシー） １．アクティビティ所要期間 見積り ２．見積りの根拠 ３．アクティビティ・リスト 更新版 7.4 スケジュール作成 スケジュール作成 インプット 1. プロジェクト・ネットワーク図 2. アクティビティ所要期間見積り 3．資源に対する要求事項 ４．資源プール記述書 ５．カレンダー ６．制約条件 ７．前提条件 ８．リードとラグ ９．リスク・マネジメント計画書 １０．アクティビティ属性 ツールと技法 アウトプット １．数理解析 ２．所要期間の短縮 3. シミュレーション ４．資源平準化の経験則 ５．プロジェクトマネジメント ・ソフトウェア ６．コード体系 １．プロジェクト ・スケジュール 2. 詳細資料 ３．スケジュール ・マネジメント計画書 ４．資源に対する要求事項 更新版 スケジュールの表現形式 グラフ、テーブル等 日付のプロジェクトネットワーク図 ガンとチャート図 マイルストン … アウトプットの表現形式（Ⅰ） ガントチャート図の例 タスク ID タスク名 C.01 全体設計 C.02 システムインストール C.03 システムテスト D.01.01 Web デザイン D.01.02 Web 画面構造設計 D.01.03 Web 画面製作 D.02.01 Web CGI 設計 D.02.02 Web D.03.01 Web プログラミング（統合） D.03.02 Web 単体テスト … … 他の例 CGI 製作 6月 7月 8月 9月 ガントチャート図の例（Ms Projectにより） 7.4.1 スケジュール作成技法 ① スケジュール作成までのプロセス （2.4.1.1） スケジュール作成技法 （2.4.1.2） プレシデンス・ダイアグラム法の適用例 （2.4.1.3） ５つの基本値とクリティカル・パス （2.4.1.4） 日程計算の方法（2.4.1.5） アロー・ダイアグラム法の適用例 （2.4.1.6） ダミー （2.4.1.7） 7.4.1.1 スケジュール作成までのプロセス (1)「スコープ定義」プロセスでWBSを作成する。 (2)「アクティビティ定義」プロセスでWBSの最下層（ワークパッケージ）をさ らに要素分解してアクティビティを定義する。 (3)「アクティビティ順序設定」プロセスで各アクティビティ間の順序関係を 明確にする。 (4)「アクティビティ所要期間見積り」プロセスで各アクティビティの所要期 間を見積る。 (5)「スケジュール作成」プロセスでネットワーク図を完成させ、プロジェクト 全体のスケジュールを作成する。 7.4.1.１ スケジュール作成までのプロセス 7.4.1.2 スケジュール作成技法Ⅰ １．プレシデンス・ダイアグラム法 （PDM：Precedence Diagramming Method） 作業をノードで表現し、ノード間を、依存関係を表す矢線（アロー）で結 んで作業の順序を表現したネットワーク図。 ・Activity on Node（AON）とも呼ばれます。 ・作業間には次の４つの依存関係が設定できます。 FS（Finish-to-Start） ：前の作業が終わると次の作業が始まる。 SS（Start-to-Start） ：前の作業が始まると次の作業も始まる。 FF（Finish-to-Finish）：前の作業が終わると次の作業も終わる。 SF（Start-to-Finish） ：前の作業が始まると次の作業が終わる。 7.4.1.2 スケジュール作成技法Ⅱ ２．アロー・ダイアグラム法 （ADM：Arrow Diagramming Method） 作業をアローで表現し、作業間の接続表示にノードを用いて作業の順 序を表現したネットワーク図。 Activity on Arrow（AOA）とも呼ばれます。 作業間の依存関係は、FS（終了－開始）のみが設定できます。 ダミー（順序関係を表すのみの、所要期間がゼロの作業）という便宜 的な作業を必要とする場合があります。 7.4.1.3 プレシデンス・ダイアグラム法の適用例 7.4.1.4 ５つの基本値とクリティカル・パス ES（Early Start）：最早開始日（その作業を始めうる最も早い日） EF（Early Finish）：最早終了日（最早開始日に作業を始めた時の予定 終了日） LS（Late Start） ：最遅開始日（その作業を遅くとも始めなければな らない限界日） LF（Late Finish）：最遅終了日（その作業を遅くとも終えなければな らない限界日） TF（Total Float）：全余裕日数（その作業が持つ総余裕日数。これを 使い切ると後に続く経路はクリティカル・パスとなる） クリティカル・パス （Critical Path）：TF=0 の作業の経路（最長経路すなわち工期） 7.4.1.5 日程計算の方法 ・前進計算 ES =［先行作業のEFの内、最も遅いEF ］+ 1 EF = ES + DUR - 1 （DUR：作業期間） ・後退計算 LF =［後続作業のLSの内、最も早いLS ］- 1 LS = LF - DUR + 1 ・全余裕日数の計算 TF = LS - ES = LF - EF 7.4.1.5 日程計算結果 ネットワークについて日程計算をすると次のようになります。 7.4.1.6 アロー・ダイアグラム法の適用例 7.4.1.7 ダミー ダミーとは、 アロー・ダイアグラム法で作業の順序関係を正しく図示 するために導入された、作業の順序関係のみを規定する 所要期間ゼロの「みせかけの作業」です。 プレシデンス・ダイアグラム法ではダミーは必要ありま せん。 7.4.2 スケジュール作成技法 ② ◆ PERT （2.4.2.1） （Program Evaluation and Review Technique） ◆ ◆ ◆ ３点見積法 （2.4.2.2） スケジュール・リスク分析 （2.4.2.3） モンテカルロ・シミュレーション （2.4.2.4） 7.4.2.1 PERT PERT（Program Evaluation and Review Technique） PERTは、1950年代後半に米国海軍ポラリス・ミサイル開発プロ ジェクトで実用化された日程計画・管理のための技法としてあ まりにも有名です。なお、同様の技法として、費用との関係を 見ながら工期短縮を図ることをねらいとしたCPM（Critical Path Method）も、同じ頃にデュポン社工場建設のために実用 化されています。 PERTの用法の一つとして、確率・統計理論を用いてプロジェク トに内包するスケジュール・リスクを分析することが挙げられ ます。例えば、各作業の所要期間を１通りではなく、楽観値、 最可能値、悲観値の３通りで見積り、個々の作業のバラツキ具 合を基にプロジェクト工期のバラツキ具合を予測して、スケジ ュール達成の可能性を予見するなどのように使われます。これ を３点見積法と呼びます。 7.4.2.2 ３点見積法 7.4.2 工期算出の前提 工期の平均と分散 工期はクリティカル・パスにある各作業の 平均日数の和で求められ、その分散もクリテ ィカル・パス上の各作業の分散の和で求めら れる。（平均と分散の加法性） 工期の分布 このときの分布は中心極限定理（個々の事 象の分布を重ね合わせると正規分布に近づく） により正規分布にしたがう。 計算結果 7.4.2.3 スケジュール・リスク分析 7.4.2.4 モンテカルロ・シミュレーション モンテカルロ・シミュレーションはリスク分析でよく使われる技法 です。これは、乱数を用いて幾度もシミュレーションを繰り返し、 その結果得られる測定値の平均で真の値を推定しようというもので す。解析的に解を求めることが難しい問題に有効な方法です。 試行回数： 1000回 平均値： 10.96 標準偏差： 1.09 7.4.3 スケジュール作成技法 ③ ―スケジュール短縮技法 スケジュール短縮技法を３つ紹介する。 再見積り（2.4.3.1） ファスト・トラッキング（Fast tracking） （2.4.3.2） クラッシング（Crashing） （2.4.3.3） 7.4.3.1 再見積り ◆再見積り 再見積りは最初に採るべきアプローチで、各作業の所要期間見 積りは正確かどうか、つまり、正しい前提条件のもとで適切な 方法で見積ったかどうかを再度確認します。 さらに、見積りの際に判明した課題は解決できるのか、識別さ れたリスクへの対処方法はあるのか、これら課題やリスクへの 対応により各作業の所要期間見積りは短縮可能か、逆に短縮に より新たに生じるリスクは何か、などの点も併せてレビューし、 結果としてクリティカル・パスが短縮可能かどうか調べます。 なお、各作業の所要期間が変わるとクリティカル・パスも変わ る場合があるので注意が必要です。 7.4.3.2 ファスト・トラッキング ファスト・トラッキング ファスト・トラッキングは現実にはよく使われます。これ は、特にクリティカル・パス上の作業間の順序や依存関係を見 直し、リソース上の制約を考慮しながら並行作業を増やすこと で工期を短縮する技法です。 ファスト・トラッキングではリスクの予見が重要です。即 ち、工期短縮の効果と、短縮により新たに生じるリスクを的確 に認識しておくことです。また、短縮によるクリティカル・パ スの変化にも注意します。 ファスト・トラッキングの例 例Ⅰ 前作業の完了を待って開始する後作業を、その完了を待たずに先行開始 して並行して作業します。 例えば、詳細設計が完了する前に、設計がある程度できている部分からコーデ ィングを開始するなど。この場合、詳細設計の完了レビューが行われていない ため、コーディングに手戻りが発生するリスクがあります。 なお、この前倒しした期間をリードと呼びます。 例Ⅱ プロジェクト・ネットワークの構造を変えることで、並行作業を増やす 例えば、作業間の依存関係のうち、FS（終了－開始）の関係をSS（開始－開始） やFF（終了－終了）の関係にできれば、その部分のパス（経路）が直列パスか ら並列パスになるのでスケジュールの短縮に効果があります。 リード（Leads）とラグ（Lags） リード： 後続作業の開始を前倒しするような論理的順序関係の修正。例えば、10日間のリー ドがあるFS（終了－開始）の依存関係では、後続作業は先行作業の終了よりも10日 前に開始することができる。 ラグ： 後続作業の開始を遅らせるような論理的順序関係の修正。 例えば、10日間のラグ があるFS（終了－開始）の依存関係では、後続作業は先行作業が終了して10日間経 たないと開始できない。 7.4.3.3 クラッシング（1） プロジェクトの計画段階における、クラッシングの一般的な手順は次の通りです (1) クラッシング対象作業の選定： 通常はクリティカル・パス上の作業がクラッシングの対象になります。対象 作業の選定は、プロジェクトの事情に即した観点から適宜な方法で行います よく使われる方法 短縮コスト（１日当りの必要コスト）の小さい作業から優先順位づけする。 なるべく早い段階で行う作業の優先度を上げる。（予見していないリスクの 対応などのために時間的な余裕を持ちえる） 所要期間の長い作業の優先度を上げる。（短い作業に比べ短縮の影響が少な い） 要となる作業の優先度を上げる。（多くの後続作業への影響を減じる） 7.4.3.3 クラッシング（2） (2)必要リソースの手当て （当該プロジェクトの中で手当てする場合）： 選定された作業と並行した、スケジュールに余裕のある作業のうち、必 要かつ適切なリソースがあり、リソース供出後の影響の少ない作業から リソースを振り向ける。 (2)´必要リソースの手当て （当該プロジェクトの外から手当てする場合）： 選定された作業に対して、そのプロジェクトの外部から必要かつ適切なリソース を投入する。 (3) クリティカル・パス再計算： クリティカル・パスを再計算して短縮効果を確認する。 (4) (1)→(2)（(2)´）→(3)を、 短縮目標が達成されるか、または短縮可能限界まで繰り返す。 7.5 スケジュール・コントロール スケジュール・コントロール インプット １．プロジェクト ・スケジュール 2. 実績報告書 3．変更要求 ４．スケジュール ・マネジメント計画書 ツールと技法 １．スケジュール変更管理 システム ２．実績測定 3. 追加の計画 ４．プロジェクトマネジメント ・ソフトウェア ５．差異分析 アウトプット １．スケジュール更新版 2. 是正処置 ３．教訓 7.5.1 ケジュール・コントロールの対象 ケジュール・コントロールの対象 WBS 作業１２ WBS コード 作業１２２ 作業１２３ ワーク パッケージ 作業１２33 タイム・マネジメント コスト・マネジメント 管理対象 作業１２34 アクティビティ アクティビティ 7.6 システム開発における考慮点 アクティビティ定義での考慮点 所要期間見積りでの考慮点 スケジュールの作成の考慮点 7.6.1 システム開発における考慮点① アクティビティ定義での考慮点 ① アクティビティ・リストには、プロジェクトのために実施され るすべての活動を列挙する ② アクティビティ定義の中には、顧客担当の作業や関連す る他ベンダーの作業も含める。 ③ 各工程の準備作業もアクティビティとして明確に定義する。 7.6.1 システム開発における考慮点2 所要期間見積りで以下の点を考慮する ① インプット ② 見積りでは、妥当性（だとうせい）や実現可能性評価 を得る。 ③ 見積りを左右する要因 ④ 見積りは、プロジェクトマネージャも必ず確認する。 7.6.3 システム開発における考慮点 ③ スケジュール作成では、以下の点を考慮する。 ① プロジェクト・カレンダとして稼働日、稼働時間を考慮して いること。 ② ファスト・トラッキングを行わない計画を作成してみて、そ のときの終了日と要求されている終了日との差異を重要 な情報として扱う。 ③ スケジュール・コントロールのルールを決めておく。
© Copyright 2024 ExpyDoc
