1.3 軟件項目估算及現行實踐做法的概述
首先我們概要地介紹一下估算過程，然后介紹一些現行的實踐和期望的做法。
1.3.1 估算過程的概述
軟件估算方法的概略描述如圖1.1所示。
圖1.1 估算過程的示意圖
（1）圖1.1的左邊部分是軟件估算過程的輸入條件。這些輸入一般包括以下內容。
·產品需求：
〇 用戶提出的功能需求，這些需求被分配在軟件中；
〇 非功能需求，其中一部分被分配到軟件中，其他的被分配到系統的其他部分中（硬件、操作手冊等）。
·軟件開發過程：通常先選擇一個生命周期模型（如敏捷、迭代等）及其各種組件，包括開發平臺、編程語言和項目組。
·項目約束：這些是外部施加給項目的約束（如預先確定的交付日期、最高可用預算等）。
（2）圖1.1的中間部分表示以生產率模型為基礎的估算過程，包含以下內容。
·每位參與估算過程的專家的“隱含”模型（一般來說，專家使用的生產率模型不會記錄下來）。
·數學模型：回歸、案例推理、神經網絡等。
（3）圖1.1的右邊部分通常是預期的估算成果物，包括軟件交付所需工作量（成本或項目工期）的估算結果，以及交付的軟件應滿足在輸入中規定的待交付軟件需滿足的質量水平要求。
1.3.2 糟糕的估算實踐
在很多文獻中都會用大量的篇幅介紹項目估算知識，尤其是軟件項目估算方面的知識。然而，實際上，軟件行業一直被大量的糟糕估算實踐困擾著，如圖1.2所示。
圖1.2 業界一些糟糕的估算實踐
（1）估算輸入。
·客戶對軟件系統的期望只有一個無比簡單的描述，經常是非常概略的定義，以及極少的文檔描述。有多少次項目組被要求基于半頁的用戶需求描述來進行估算？這種估算輸入在圖1.2中被稱為“愿望清單”。這樣的清單不可避免地會隨著時間更迭而改變，并且很有可能會以無法預測的速度進行變更。
·為了彌補用戶需求描述的缺乏，軟件經理必須盡可能地考慮更多的成本影響因子，以此降低其估算風險。
（2）估算模型。
估算模型有正式或者非正式的模型。依據該模型可以通過如下黑盒操作方式對這些未完整定義的需求進行估算。
·自身經驗，如內部經驗或外部經驗（專家經驗法）。
·書中或是估算工具中隱含的數學模型。
（3）估算輸出。
·一個單點值的估算結果。該結果必須嚴格依據項目的預算以及在已定義的工期內期望完成的需求得來。
·一個過于樂觀的態度，這在軟件從業者中是非常常見的。這意味著開發組將超越以往歷史績效，并且可以及時戰勝一切約束條件。
·同時，軟件工程師或項目經理給出的估算結果既要滿足客戶期望，也要遵守管理層分配的項目預算。
綜上所述，在這種最糟糕的實踐做法中，不管是客戶還是管理層都期望他們的員工（及供應商）會承諾不超時、不超預算地交付預期的軟件功能，并且還是在他們自己都不清楚期望獲得什么樣的具體產品功能的情況下。這種不確定性也同樣會遺留到所有的新項目中。
換句話說，一方面客戶和管理層期待奇跡發生，另一方面太多的軟件從業者進行著糟糕的單點值估算，表現得好像他們可以持續地創造奇跡一樣！
業界的一些最佳估算實踐
成熟的軟件組織把估算看作一個能給他們帶來競爭優勢的過程。為了得到這種競爭優勢，他們研究估算過程并掌握了其中的關鍵因素，包括以下內容：
〇調查收集項目需求并了解其質量；
〇使用軟件度量國際標準；
〇在整個項目生命周期中堅持量化度量方法；
〇量化分析他們的歷史性能，即他們在歷史項目的交付和滿足項目目標方面的能力如何；
〇深入分析他們的估算性能（實際與估算比較）。
業界的一些最差估算實踐
〇主觀臆斷和單點值估算；
〇使用黑盒估算（專家經驗和/或未文檔化的數學模型）；
〇依賴別人的數字：沒有對自己的估算過程進行研究，以形成持續性的競爭優勢。
1.3.3 糟糕的估算實踐的例子
以下是一些糟糕的估算實踐的例子，如圖1.3所示。
圖1.3 夢想：一個“準確的”估算結果
（1）估算模型的輸入。
·產品需求=愿望清單：
〇 沒有按照國際標準度量功能性用戶需求；
〇 使用項目結束后的KLOC（千行代碼），并沒有考慮各種編程語言的混合使用以及不同語言的特征；
〇 經常認為規模的計量單位無關緊要；
〇 基于糟糕的需求進行KLOC的猜估，以及對采用不同編程語言時的需求與KLOC之間關系的錯誤理解。
（2）模型建立過程。
·單個描述性因子轉變為量化影響因子，而沒有考慮其精確性和偏差。
·在自有的開發環境中，沒有對各項目變量的影響進行客觀的量化分析。
·完全依賴于沒有足夠證據支持的外部數據。
（3）生產率模型。
·在基于專家經驗的估算方法中，所謂專家的估算性能是未知的。
·沒有驗證各種統計技術所需的假設是否滿足（例如，回歸模型里的變量的“正態”分布）。
·變量太多，沒有足夠的數據來進行合理的統計分析。
·對基于專家經驗的方法進行性能分析時，沒有驗證已交付的軟件規模。
……
（4）估算輸出。
·夢想：一個“準確的”估算結果。
·對估算結果的備選值范圍和備選偏差原因只做了有限的分析。
·對估算結果的質量只做了很少的記錄。
1.3.4 現實：失敗記錄
在全世界大大小小的組織中，軟件項目估算是一個重復發生且重要的活動。在過去的50年里，人們對軟件項目估算已做了大量的研究，并提出了無數個業界模型。那么，業內的軟件估算到底怎么樣呢？
答案是，不怎么出色（Jorgensen and Molokken 2006; Jorgensen and Shepperd 2007; Petersen 2011），如圖1.4所示。
圖1.4 項目成功趨勢圖（基于Standish Group數據）（改編自Miranda 2010）
·圖1.4是由Eveleens and Verhoef（2010）引自Standish Group Chaos報告的數據，表明僅僅只有30%的軟件項目是按期、按預算交付的。
自從1995年Standish Group報告第1版發布以來，軟件開發行業在按時、按預算完成開發項目的能力上取得了一些進步，但仍有將近70%的軟件項目延遲交付并且超出預算，或者被取消。
·El Eman和Koru（2008）在2008年的研究中指出，艱難完成的項目和失敗的項目平均數量占比為50%。