作業:
|
目的
|
|
役割: プロジェクト管理者 | |
頻度: プロジェクトごとに 1 回。 | |
手順 | |
入力とする成果物: | 結果となる成果物: |
ツール・メンター: |
ワークフローの詳細: |
目的 | 製品の納品に必要な作業量を見積もる。
プロジェクトの制約を満たす最適なスケジュールを選択する。 |
方向付けフェーズでは、プロジェクトで提案された作業の見積もりを準備します (ソフトウェア・プロジェクトの見積もりについて詳しくは、参考資料 [BOE81]、[PUT92]、[MCO96] を参照)。ソフトウェア・プロジェクトの見積もりは複雑な数式に基づいているため、詳細な技術的背景については、ここでは説明しません。見積もりは次の 4 ステップのプロセスに従います。
これは、見積もりプロセスの中心となる入力です。作業量を見積もれない場合、プロジェクト・スケジュールを作成しても現実とはかけ離れたものになってしまいます。プロジェクトの初期段階で使用できる、ソフトウェア製品のサイズを見積もる方法には、類似度による見積もりと、分析による見積もりの 2 つの方法があります。もちろん、プロジェクトの後半 (推敲フェーズ中) に、プロジェクトの詳細な作業分解構造に基づいた厳密なボトムアップの見積もりも準備できます。
類似度による見積もり
類似度による見積もりを使用してプロジェクトの開発範囲を見積もる場合は、以前のプロジェクトで開発した (サイズがわかっている) 製品と開発中の新製品とを比較します。比較対象製品のビジネス・ユース・ケース数、アクター数、データベースのサイズ/複雑さ、オンライン・プログラムとバッチ・プログラムの予想数といった特性を比較します。
これらの特性を比較することで、旧製品との比較での新製品の相対的サイズを見積もることができ、旧製品のサイズがわかっていることから、新製品のサイズを計算できます。ユース・ケース記述の詳細レベルで製品の開発アプローチや複雑度に違いがあると比較が無効になる可能性があるため、同じようなアプローチを使用して開発した同じような複雑度の製品を比較することが重要であることを忘れないでください。
分析による見積もり
方向付けフェーズの後半では、新製品に関する十分な情報を収集し、分析手法を使用して製品のサイズを見積もることもできます。この手法は、ソフトウェア製品の使用可能な機能に関する説明 (ソフトウェア要求仕様やソフトウェア・アーキテクチャー説明書) に依存し、標準の経時規則を適用して、これらの説明からサイズの情報を決定します。このような技法で最もよく知られているのはファンクション・ポイント法ですが、ほかにもフィーチャー・ポイント法 (ファンクション・ポイントをリアルタイム・システムに適用できるように修正したもの) と予測オブジェクト・ポイント法 (クラスの複雑さと階層の分析に基づいたオブジェクト指向システムの測定) を始めとする、いくつかの測定方法が開発されています。
IBM Web サイト 上からは、ユース・ケースに基づくサイズの見積もり方法を記述したホワイト・ペーパーも入手できます (ただし、英語のみのご利用となります)。 このホワイト・ペーパーを使用する際は、ユース・ケースに基づいた初期のサイズの見積もりをするため、組織のユース・ケース・スタイルに合うように調整する必要があります。これは、ユース・ケースは抽象化レベルや表現方法が、組織間や、組織内でさえも大いに異なることがあるからです。 調整が済むと、選択した標準のユース・ケース記述スタイルを守ることが重要です。そうしなかった場合、サイズの見積もりは大幅にずれる可能性があります。
プロジェクト全体の作業とコストの見積もり
プロジェクトの要員全体の作業とスケジュールは、確立している科学モデルを使用して見積もった製品のサイズから計算できます。今日使用されている主要なモデルに、Barry Boehm が開発した COCOMO (COnstructive COst MOdel) と Larry Putnam の Putnam 法の 2 つがあります。これらのモデルは両方とも、業界データで検証が済んでいます。COCOMO の最新バージョンについて詳しくは、COCOMOII の Web サイトを参照してください。
サイズの入力以外の中心となる入力は、チームの生産性の測定です。この値はプロジェクト全体の作業を決定します。全体のプロジェクト・スケジュールは、全体の作業と非直線的に関連しています。このモデルは残念なことに数学的に複雑であり、計算を補助するソフトウェア・ツールを活用するのが最良の方法です。
制約と優先順位の適用
ほぼすべてのプロジェクトでは、ある種の制約 (出荷期日や、コスト限度額が 85 万ドルであるなど) または優先順位 (製品の早期入手の必要性など) に従います。製品のサイズを固定すると、これらの項目はチームの規模の調整によって影響されます。チームのサイズとスケジュール間の関係は直線的ではないことがわかり、チームのサイズが変化する場合には、科学的モデルを使用していくつかのシナリオを生成する必要があります。これを実践するには、自動見積ソフトウェアが非常に役立ちます。
最適なスケジュール、作業、コスト見積もりの選択
プロジェクトのシナリオを十分に作成したら、プロジェクトのニーズに最適なシナリオをレビューし、選択します。これにより、プロジェクトの全期間にわたる初期イメージを提案どおりに得ることができ、必要なチームのサイズと予算がわかります。
目的 | プロジェクトの進捗を正式に評価するためのポイントを定義する。
見積もった作業とコストを各フェーズに割り当てる。 |
ソフトウェア開発計画書では、最初に主要なマイルストーンの期日と性質を定義します (フェーズを参照)。 ソフトウェア開発計画書のこの部分はプロジェクト全体の「ロードマップ」として機能し、プロジェクトの開始時点 (方向付けフェーズ) で作成されます。
開発サイクルの初期でプロジェクトのフェーズ計画を立てるには、以下に基づいて、マイルストーンについて推測する必要があります。
同様な性質のほかのプロジェクトにおける自分自身の経験に基づく見積もりを使用して、全体の作業とコストから適切にプロジェクトの各フェーズに割り当てることで、プロジェクトの初期予算を作成できます。
目的 | フェーズを評価する基準を定義する。 |
各マイルストーンは、特定の納品可能物に焦点が置かれています。また、次のフェーズに向けて十分に定義された移行ポイントを提供します。
フェーズ |
マイルストーン |
目的 |
---|---|---|
方向付け | ライフサイクル目標 | プロジェクトへのリソースの投入 |
推敲 | ライフサイクル・アーキテクチャー | 製品アーキテクチャーの安定化 |
作成 | 初期運用能力 | 製品開発の完了 |
移行 | 製品リリース | 製品導入の成功 |
各マイルストーンは、プロジェクトが越える必要がある重要なハードルを示します。各マイルストーンで、プロジェクトは先へ進むか進まないかの決定に直面します。
目的 | 各プロジェクト・フェーズについて計画する反復の回数を決定する。
反復にまたがる適切な作業割り当てを決定する。 各反復の目的を決定する。 |
プロジェクト・フェーズの期間を決定したら、反復の回数と期間を決定する必要があります。 プロジェクトのタイプ、問題の領域、問題の領域の新規度に応じて、適用可能な反復パターンがいくつかあります (概念: 反復も参照)。
各反復では納品可能物を作成します。これは実行可能な製品のリリースで、進捗と品質の評価に使用します。各反復では絞り込み範囲が異なるため、反復における納品可能物の機能と完全性は異なります。反復の最後に反復の目標が達成できたかどうかを評価するため、反復の目標は詳細にする必要があります。初期の反復では、目標は緩和されたリスクの観点で表すのが普通です。後半の反復では、目標は機能的完成度と品質の観点で表します。
目的 | 方向付けフェーズの最後で、利用可能な情報に基づいて見積もりを洗練する |
方向づけフェーズの終わりに近づくにつれ、以下を考慮に入れるとフェーズをより正確に計画できます。
この大まかな計画は推敲フェーズ中に更新されます。これはプロジェクト計画の残りを作成するベースとして機能します。
目的 | フェーズ/反復ごとに割り当てられた、プロジェクトに必要なリソースの数とタイプを定義する。 |
作業見積もりと作業見積もりから得られるプロジェクト・スケジュールに基づいて、プロジェクトを実行するために必要なリソースを定義できます。各フェーズ/反復について、作業を担当する役割と人数を割り出します。
目的 | プロジェクトを順序に沿って完了するための計画を作成する。 |
プロジェクトの終了計画は、ソフトウェア開発計画書の 5.6 終了計画書で説明されています。プロジェクトの終了は、プロジェクトを順序正しく終了させるための一連の作業で、プロジェクトで得たメトリクスや教訓が将来の参考のために確実に把握するようにします。
次の条件を満たした場合に終了プロセスが始まります。
まず、プロジェクトの終了で行う作業を、計画書の中に一覧表示します。通常、以下の作業が含まれます。
次に、それぞれの終了作業に誰が関与するかを計画書で識別します。
次に、終了作業のスケジュールを定義します。この詳細は、プロジェクトの終了に向けてソフトウェア開発計画書に追加していくのが一般的です。
Rational Unified Process
|