專案活動

若要充分利用 MSF for CMMI Process Improvement v5.0，您應該將專案組織為長度介於四到八週的一系列反覆項目。 這可協助您降低由於需求和實作成本的提升而形成的專案風險。 反覆的專案結構是一項能滿足 CMMI 之風險管理需求的重要貢獻。

如需 CMMI 的詳細資訊，請參閱 CMMI 的背景。

在專案開始時

專案起始

「起始」包含定義專案願景，其陳述當專案發行產品後使用者可藉該產品完成何事。

還包含小組的設立、基礎結構和其他資源，以及決定開發程序。

如需詳細資訊，請參閱專案起始。

初期的專案規劃

專案規劃包含下列活動：

• 盡可能細部分析需求，以讓您形成計劃。 這項分析包含使用需求模型、腳本，以及有助於想像工作系統的其他工具。

• 規劃系統的整體設計或架構。 如果這涉及使用到小組成員未曾接觸過的平台，則必須指派一些時間讓成員加以熟悉。 在反覆項目的較早期階段，開發的進度將是緩慢的。

• 將需求轉換成一組可大略預估開發進度的遞增產品需求。 一般需求和產品需求之間的差異是一項重要的工作，也是一項顯著的活動。 如需詳細資訊，請參閱開發需求。

• 將產品需求初步指派給反覆項目。

• 設定發行日期。

由於在專案進行時會重新審視及修改計劃和需求模型， 因此，反覆開發的部分目的便是透過在早期階段示範可行軟體進而提供需求改善的空間。

反覆項目 0 的初期專案規劃即在此完成。

如需詳細資訊，請參閱規劃專案 (CMMI)。

探索現有的產品

專案的目標有可能是更新既有的產品。 在這種情況下，如果小組不熟悉該產品，探索程式碼便成為反覆項目 0 的活動。 在後續反覆項目中的每項開發作業也涉及特定區域之程式碼的了解程度，以及追蹤程式碼變更後的產出結果等作業。

如需詳細資訊，請參閱視覺化現有的程式碼。

在專案期間

專案進行時會檢閱計劃並可能變更計劃。

在專案期間，會定期執行數個和專案計劃相關的活動 (通常是在反覆項目結束時)。

驗證

請向客戶或商務專案關係人示範於反覆項目期間開發的軟體。 可以的話，請將軟體發行給這些人員，讓他們試用軟體或在實際環境中進行某些程度的使用。

在足夠的時間間隔後，安排會議以檢閱使用者的意見。 接著再使用這些意見產生變更要求。

如需詳細資訊，請參閱Validate a Customer Requirement。

風險管理

檢閱潛在負面事件的可能性和影響，並採取動作以降低風險。 如需詳細資訊，請參閱管理風險。

變更管理

您可以使用變更要求工作項目來記錄商務專案關係人陳述的需求變更。 這些變更可能來自業務環境的變更，也可能來自產品之早期版本的示範和試用。 應該虛心接受這些變更，因為它們能使產品更符合業務目標。 這種效果便是遞增開發的目標之一。

有些專案小組會在出現變更要求時調整產品需求工作項目，而不使用個別的工作項目。 不過，變更要求工作項目的優點即是讓您在專案的尾聲檢閱執行之變更的數量和本質。 日後您可以使用該資訊改善您的程序或架構。

您應該將變更要求當做產品計劃檢閱時的輸入。

如需詳細資訊，請參閱 管理變更 (CMMI)。

產品計劃檢閱

在規劃每個反覆項目之前，請先舉行產品計劃檢閱。 專案計劃負責將產品需求指派給反覆項目。

計劃會發生變更主要是由於兩個原因：

• 需求的變更。

• 開發人員預估的變更。 隨著專案進行，開發小組便能針對要完成之功能所需進行的必要工作，做出更可靠的預估。 在某些情況下，有些功能可能是先前反覆項目延後的功能，這便會在計劃中加入一項功能。

在往後的反覆項目中，這兩種變更的發生頻率即會降低。

檢閱衍生產品需求的需求模型。

修訂將需求指派給反覆項目的指派作業。 正如同在初期的規劃活動中，商務專案關係人提供優先順序、開發小組提供預估，而大家在會議中從反覆項目間變出各種功能。

如需詳細資訊，請參閱規劃專案 (CMMI)。

在產品的主要發行版本之前

與產品部署有關的活動會隨著產品的類型而有所不同，因此我們不在此處討論。

請考量下列有關軟體開發較後期之反覆項目的要點：

• 排除設計上的重大變更，以避免發生無法預見的問題。

• 在分級會議中訂定變更和 Bug 的限制。 除非變更和 Bug 會嚴重影響產品目的之可用性和適用性，否則應拒絕所提出的變更和 Bug 修正。

• 將資源分配給漸增的測試涵蓋範圍及執行手動測試等作業。