估算技術 - 概述

---

---

估算是指找到一個估計值或近似值的過程，即使輸入資料可能不完整、不確定或不穩定，該值也可以用於某些目的。

估算確定構建特定系統或產品需要多少資金、精力、資源和時間。估算基於 -

• 歷史資料/以往經驗
• 可用文件/知識
• 假設
• 已識別的風險

軟體專案估算的四個基本步驟是 -

• 估算開發產品的規模。
• 估算以人月或人時為單位的工作量。
• 估算以日曆月為單位的進度安排。
• 估算以約定貨幣為單位的專案成本。

關於估算的觀察

• 估算不一定是專案中的一次性任務。它可以在以下期間進行 -

  • 獲取專案。
  • 計劃專案。
  • 根據需要執行專案。

• 在估算過程開始之前必須瞭解專案範圍。擁有歷史專案資料將有所幫助。

• 專案指標可以提供歷史視角和生成定量估算的寶貴輸入。

• 計劃要求技術經理和軟體團隊做出初步承諾，因為它會導致責任和問責制。

• 過去的經驗可以極大地幫助。

• 使用至少兩種估算技術得出估算結果，並協調所得值。請參閱下一節中的分解技術，瞭解如何協調估算。

• 計劃應具有迭代性，並允許隨著時間的推移和更多細節的瞭解進行調整。

通用專案估算方法

廣泛使用的一種專案估算方法是分解技術。分解技術採用分而治之的方法。規模、工作量和成本估算透過將專案分解成主要功能或相關的軟體工程活動，以逐步的方式進行。

步驟 1 - 瞭解要構建的軟體的範圍。

步驟 2 - 生成軟體規模的估算。

• 從範圍說明開始。

• 將軟體分解成可以分別估算的功能。

• 計算每個功能的規模。

• 透過將規模值應用於您的基線生產力指標來推匯出工作量和成本估算。

• 組合功能估算以生成整個專案的總體估算。

步驟 3 - 生成工作量和成本的估算。您可以透過將專案分解成相關的軟體工程活動來得出工作量和成本估算。

• 確定為了完成專案而需要執行的活動序列。

• 將活動分解成可以測量的任務。

• 估算完成每個任務所需的工作量（以人時/天為單位）。

• 組合活動任務的工作量估算以生成該活動的估算。

• 從資料庫中獲取每個活動的成本單位（即，成本/單位工作量）。

• 計算每個活動的工作量總和和成本總和。

• 組合每個活動的工作量和成本估算，以生成整個專案的總體工作量和成本估算。

步驟 4 - 調和估算：將步驟 3 中得出的值與從步驟 2 中獲得的值進行比較。如果這兩組估算結果一致，則您的數字非常可靠。否則，如果出現差異很大的估算結果，請進一步調查以下問題 -

• 專案的範圍沒有得到充分理解或被誤解。

• 功能和/或活動分解不準確。

• 用於估算技術的歷史資料不適用於應用程式，或已過時，或已被誤用。

步驟 5 - 確定差異的原因，然後協調估算。

估算準確性

準確性是指某事物與現實有多接近的指標。每當您生成估算時，每個人都想知道這些數字與現實有多接近。您希望每個估算都儘可能準確，前提是在生成估算時您掌握的資料。當然，您不希望以一種會讓人對數字產生錯誤的信心感的方式來呈現估算。

影響估算準確性的重要因素包括 -

• 所有估算輸入資料的準確性。

• 任何估算計算的準確性。

• 用於校準模型的歷史資料或行業資料與您正在估算的專案匹配的程度。

• 您組織的軟體開發過程的可預測性。

• 產品需求和支援軟體工程工作的環境的穩定性。

• 實際專案是否經過精心計劃、監控和控制，以及是否發生導致意外延遲的重大意外。

以下是一些實現可靠估算的指南 -

• 將估算基於已經完成的類似專案。
• 使用相對簡單的分解技術生成專案成本和工作量估算。
• 使用一個或多個經驗估算模型進行軟體成本和工作量估算。

請參閱本章關於估算指南的部分。

為了確保準確性，建議您始終使用至少兩種技術進行估算並比較結果。

估算問題

通常，專案經理會訴諸於估算進度安排，而跳過估算規模。這可能是由於高層管理或營銷團隊設定的時間限制。但是，無論原因是什麼，如果這樣做，那麼在後期將難以估算進度安排以適應範圍變更。

在估算過程中，可能會做出某些假設。重要的是在估算表中記錄所有這些假設，因為有些人仍然不會在估算表中記錄假設。

即使是好的估算也存在固有的假設、風險和不確定性，但它們常常被當作準確的對待。

表達估算的最佳方法是將其表示為一系列可能的結果，例如，說專案需要 5 到 7 個月才能完成，而不是說它將在特定日期完成或將在固定數量的月份內完成。警惕做出範圍過窄的承諾，因為這相當於做出明確的日期承諾。

• 您還可以將不確定性作為伴隨的機率值包含在內。例如，專案在特定日期或之前完成的機率為 90%。

• 組織不會收集準確的專案資料。由於估算的準確性取決於歷史資料，因此這將是一個問題。

• 對於任何專案，都存在一個最短的可能進度安排，它將允許您包含所需的功能併產生高質量的輸出。如果管理層和/或客戶有進度約束，您可以協商要交付的範圍和功能。

• 與客戶就處理範圍蔓延達成一致，以避免進度延誤。

• 在最終估算中未能考慮應急措施會導致問題。例如，會議、組織活動。

• 資源利用率應考慮低於 80%。這是因為資源只有 80% 的時間才能有效率。如果您分配的資源利用率超過 80%，則必然會出現偏差。

估算指南

在估算專案時，應牢記以下指南 -

• 在估算過程中，詢問其他人的經驗。此外，也要發揮自身經驗的作用。

• 假設資源只有 80% 的時間才能有效率。因此，在估算過程中，將資源利用率視為低於 80%。

• 在多個專案上工作的資源由於在專案之間切換而花費的時間導致任務完成時間更長。

• 在任何估算中都應包含管理時間。

• 始終為解決問題、開會和其他意外事件留出足夠的時間。

• 留出足夠的時間進行適當的專案估算。倉促的估算是不準確的、高風險的估算。對於大型開發專案，估算步驟實際上應該被視為一個小型專案。

• 在可能的情況下，使用組織類似過去專案的記錄資料。這將產生最準確的估算。如果您的組織沒有保留歷史資料，現在是開始收集資料的好時機。

• 使用開發人員的估算，因為由非工作者估算的準確性會較低。

• 使用多個人進行估算，並使用多種估算技術。

• 協調估算。觀察估算結果的收斂或分散。收斂意味著您已經獲得了良好的估算。寬頻德爾菲技術可用於使用一組人員收集和討論估算，目的是產生準確、無偏見的估算。

• 在專案的整個生命週期中多次重新估算專案。