作業: 規畫階段和反覆
這項作業說明如何規劃專案的各個階段和反覆:目標是什麼、期間如何、反覆多少次等。
目的

這項作業的目的如下:

  • 預估專案的總範圍、工作和成本。
  • 開發粗略的專案計劃,將焦點放在產品生命週期中的主要里程碑和主要交付項目。
  • 在各專案階段內定義一組反覆,識別各次反覆的目標。
  • 開發專案的排程和預算。
  • 開發專案的資源計劃。
  • 定義循序完成專案的各項作業。
關係
角色主要: 其他的: 協助:
輸入強制: 選用:
外部:
輸出
步驟
預估專案
目的 預估交付專案所需要的工作強度。
選取符合專案限制的最佳排程。 

初始階段期間,您應該準備預估專案所提出的工作(如需軟體專案預估的一般討論,請參閱 [BOE81]、[PUT92] 和 [MCO96])。軟體專案預估的基礎是一些複雜的數學運算,這裡不討論詳細的技術背景。預估遵循一個四步驟的程序:

  1. 預估產品大小。
  2. 預估專案的總體工作和成本
  3. 套用限制和優先順序(如人員數量、交付日期、預算等)
  4. 選取最佳排程、工作和成本預估

預估產品大小

這是預估流程的主要輸入。如果您無法預估要完成的工作強度,所建立的任何專案排程都可能不符實際。您可以利用兩種方法來預估專案初期所能使用的軟體產品大小:類比大小和分析大小。當然,在專案後期(詳述階段期間),您可以根據詳細的專案工作分解結構來準備更嚴格的、由下而上的預估。

類比大小

當您利用「類比大小」方法來預估專案範圍時,您會比較將開發的新產品及先前的專案所開發之已知大小的產品。您要比較的各項產品,各種特性都應該比較,例如商業使用案例數目、參與者數目、資料庫大小/複雜度,以及可能的線上和批次程式數目。

您可以比較這些特性來預估新產品相對於舊產品的大小,之後,再利用舊產品的已知大小來計算新產品的預估大小。請記住,您一定要比較複雜度相近、開發方法相似的產品,否則,您的比較有可能因為使用案例說明之詳細層次等事項的差異而失效。

分析大小

在稍後的初始階段中,您可能會收集到足夠的新產品資訊,可供您利用分析技術來預估產品大小。這些技術有賴於可用軟體產品的功能說明(如軟體需求規格、軟體架構文件),它們會套用標準計數規則,從這些說明中得出預估的大小。在這些技術中,最廣為人知的應該是「功能點計數」,不過,另外還有許多已開發的其他測量方式,其中包括「特性點」(為了適用於即時系統而修正的「功能點」)和「預測物件點」(以類別複雜度和階層的分析為基礎之物件導向系統的測量)。 

另外,還有 IBM 網站所提供的白皮書,它們會說明以使用案例為基礎的大小預估方法。當使用這些白皮書時,您應該知道,如果要根據使用案例來建立起始大小預估,您必須進行校準來配合組織的使用案例樣式,因為不同組織的使用案例之抽象層次和表現方式可能極為不同,甚至在一個組織內,也會千差萬別。在校準之後,請務必保持所選撰寫使用案例的標準樣式,否則,大小預估會出現嚴重錯誤。

預估專案的總工作和成本

您可以利用既有的科學模型,從產品大小預估中,計算出人員工作總成本和專案的排程。目前所用的兩個重要模型是 Barry Boehm 所開發的「建構成本模型」(COnstructive COst MOdel, COCOMO) 和 Larry Putnam 的 Putnam 方法學。這兩個模型都已對照業界資料驗證過。如需 COCOMO 最新版本的相關資訊,請參閱 COCOMOII 網站

除了大小輸入之外,另一項主要輸入是測量小組生產力。這個值決定了整體的專案工作。 專案總排程以非線性方式關聯於總工作量。不幸,模型在數學上非常複雜,因此,最好是利用軟體工具來協助計算。

套用限制和優先順序

幾乎所有專案都會受制於某些限制(例如,必須在特定日期出貨,或成本不能超出 $850,000)或優先順序(例如,需要儘快完成的產品)。在取得固定的產品大小之後,調整小組大小會影響這些項目。結果在小組的大小和排程之間,會呈現非線性關係,因此,您必須利用科學模型,根據不同的小組大小來產生許多情境。自動化預估軟體對這個練習很有幫助。

選取最佳排程、工作和成本預估

現在專案已有一系列情境,您要審查和選取最適合您的專案需求的情境。這會依照建議來提供專案整體持續時間的初步圖像,且會指出必要的小組大小和預算。

定義專案階段里程碑
目的 定義正式評量專案進度的點。
配置每個階段的預估工作和成本。 

軟體開發計劃會先定義主要里程碑的日期和本質(請參閱階段)。這部分的軟體開發計劃用來作為專案的整體「藍圖」,它是在專案開始之時(初始階段)建立的。

如果要規劃專案起始開發週期的各個階段,您可能需要根據下列各項,針對里程碑做一些有知識經驗基礎的猜測:

  • 有類似本質和領域的專案經驗。
  • 新穎程度。
  • 特定環境限制,如回應時間、分佈和安全。
  • 組織的成熟度。

您利用自己基於本質相近的其他專案經驗而來的預估,藉由將總預估工作和成本的適當部分配置給專案的每個階段來建立初步的專案預算。

如需如何定義反覆長度和反覆數目的相關資訊,請參閱準則:軟體開發計劃

定義里程碑目標
目的 定義用來評量階段的準則。 

每個里程碑的焦點都在於特定交付項目;每個里程碑都提供一個定義好進入下一階段的轉換點。

階段
里程碑
目的
初始階段  生命週期目標里程碑 在專案中確定資源
詳述階段  生命週期架構里程碑 使產品的架構穩定
建構階段  初步運作能力里程碑 完成產品開發 
產品發行里程碑 順利部署產品

每個里程碑都代表一個專案必須清除的重要障礙;在每個里程碑,專案都必須面對前進/不前進的決策。

定義階段內的反覆數目、長度和目標
目的 確定每個專案階段要規劃多少次反覆。
確定跨越各次反覆的相對工作配置。
確定每次反覆的目標。 

確定專案階段的長度之後,就必須確定反覆的數目及長度。如需如何定義反覆長度和反覆數目的相關資訊,請參閱 準則:軟體開發計劃。您可以套用許多反覆型樣,它們會隨著專案類型、問題領域和問題領域的新穎程度而不同(另請參閱概念:反覆)。

每次反覆都會產生一個交付項目,一個用來評量進度和品質的可執行產品版本。由於每次反覆都會有不同的焦點,因此,反覆交付項目的功能和完成度可能會不同。反覆目標必須足夠明確,以便在反覆結束時,評量是否已符合反覆目標。在初期的反覆中,通常是透過緩和的風險來表示目標;在後期的反覆中,則是由功能完成度和品質的測量來表示目標。

修正里程碑日期和範圍
目的 根據初始階段結束時所取得的資訊來修正預估 

在初始階段即將結束時,您可以將下列各項列入考量來更精確地規劃幾個階段:

  • 識別的使用案例數目。
  • 已研究之使用案例的複雜度。
  • 識別的風險,包括技術風險和商業風險。
  • 功能點或使用案例測量值。
  • 任何建立原型的結果。

這是一項很粗略的計劃,在詳述階段會加以更新。它是專案計劃其餘部分的建置基礎。

判斷專案資源需求
目的 依階段/反覆來配置,定義這個專案所需要的資源數量和類型。 

現在,您可以根據您的工作預估及從中衍生出來的專案排程來定義完成專案所需要的資源。請針對每個階段/反覆,識別出必須包含的角色以及所需要的數量。

開發專案結案計劃
目的 開發循序終止專案的計劃。 

專案結案計劃文件在軟體開發計劃的 5.6 節 結案計劃中。專案結案是循序結束專案時所執行的一系列作業,以確保會擷取所得到的任何測量值和體會,供未來參考。

當符合下列條件時,結案流程便告開始:

  • 已在配置控制之下,完成和儲存所有專案交付項目
  • 已完成驗收測試,且客戶已正式接受產品
  • 產品已正式交付給客戶

定義結案作業

首先,請在您的清單中,列出您將在專案結案時執行的作業。這通常會包括下列各項:

  • 專案後置審查會議
  • 開發專案後置審查報告
  • 專案人員審查結束
  • 保存專案工作成果
  • 重新指派專案人員
  • 將專案測量值加入組織歷程測量值資料庫中,供未來專案預估之用。

識別結案作業的參與者

之後,請在您的計劃中,識別每個結案作業將包括哪些個人。

定義結案作業的排程

之後,請定義結案作業的排程。在專案即將結束時,通常會將這個詳細資料加到軟體開發計劃中。



內容
多次出現的項目
事件驅動
持續進行中
選用
規劃
可重複的
主要考量

專案管理人員利用專案規劃來建立專案特定交付流程(請參閱工作成果:開發流程)的實例,以及在執行這個實例時進行後續的管理工作。這通常稱為流程條例。

「已建立實例」的流程是一項可實施的專案/反覆/活動計劃,其中包括實際專案的實際活動和工作成果。您可以從 Rational 方法編製器 中,將交付流程 匯入 Rational 資料夾管理程式 (RPM) 中,再複製已設成 isRepeatable 或 hasMultipleOccurences 的活動和作業、建立真實的工作成果、指派真實資源給角色等,來建立交付流程的實例。

詳細資訊