第 5 章 軟體估算

1. 第5章 軟體估算　

2. 本章大綱 5.1　何謂軟體估算 5.2　估算的困難 　 5.3　如何進行估算 　 5.4　估算的方法 　 5.5　功能點分析 5.6 COCOMO模型 5.7 模型的使用 5.8 估算的流程 5.9 估算的原則 5.10 結語　

3. 學習目標 瞭解何謂軟體估算 瞭解估算的困難 瞭解估算的方法 瞭解估算的流程 瞭解估算的原則

4. 何謂軟體估算(1/3) 軟體要以「工程化」的方法開發，就需要一些量化的數字，當作工程規劃的基礎。這些數字產生的途徑有兩種：一種是事前，另一種是事後。 事前的數字由於來自事情尚未發生之始，因此只是一種猜想、一種預估，但是又不能天馬行空，必須有所本，因此「預估」的同時還要加上「計算」的成分，稱為估算（estimation）。 專案應該先做估算，再來規劃。根據估算的結果，分配資源並進行任務的安排。 軟體開發的品質與生產力，取決於估算的準確與否，有好的估算才會有好的計畫與適當的資源分配，專案才有較佳的成功機會。

5. 何謂軟體估算(2/3) • 估算的影響 • 直接影響：資源分配、時程規劃、開發流程的安排，以及人力的派遣。 • 間接影響：軟體品質、產品功能，以及專案的成敗。 • 軟體估算是一件兩難的事情。若過分低估，將導致人員工作加重、生產品質低落、時程壓力增大；但是高估又會產生帕金森效應，徒然浪費資源。

6. 何謂軟體估算(3/3) • 估算的對象 • 只要是軟體開發活動中，有需要事前瞭解與安排的工作，都需要估算。 • 從軟體專案的角度來看，有四個重要項目需要估算，而這四個項目彼此之間，又存在著相互依存的關係。分別是： • 產品規模（size）。 • 勞力投入（effort）（亦即工作量）。 • 資源或成本（resource）。 • 開發時程（schedule）。

7. 估算的困難 • 外部因素 • 人員的無知。 • 顧客與開發人員對產品需求認知上的差異。 • 產品範圍不確定。 • 內部因素 • 度量工具的缺乏。 • 與估算相關的變數很難加以量化。

8. 如何進行估算(1/2) • 漸進式估算 • 整體而言，軟體開發是一個漸進改善的過程，在詳細瞭解各個功能前，無法準確估算軟體規模。 • 在專案初始階段，由於僅有關於產品需求約略的概念，此時的估算只能是一個大略的數字。隨著專案的進展，會逐漸知道更多關於專案的細節，這時候才可逐步精細化估算的結果。 • 如圖5.1所示。

9. 圖5.1 漸進式估算示意圖（以傳統軟體開發流程為例）

10. 如何進行估算(2/2) • 估算呈現的方式 • 加減修飾詞。4+1-1/2 • 範圍。3.5~5 • 風險定量化。+1:需求延遲;-1:新工具比預期好 • 個案化。最佳、最糟、預期情況，範圍 • 粗略的時程日期與時間。3Q06 • 信心指數。在每項估算後面加，80%達成率 • 單點估算與範圍估算的比較（如表5.1）。

11. 表5.1 單點與範圍估算的比較

12. 估算的方法(1/4) • 專家判斷法 • 就是一個或多個專家，各自根據他們的經驗做預測，最後再加以綜合。傳統上，有一個尋求群體共識的方法，稱為德菲法，包含六個步驟： • 專家們收到一份估算表單以及被估算的文件。 • 進行起始會議，討論與估算有關的對象及議題、背景等。 • 專家們各自獨立做出估算，然後交出結果。 • 經過計算後，專家們會收到估算的平均值，並與自己的估算做比較。 • 舉行專家會議，討論估算的結果；針對估算結果相差過大或意見不一致之處進行討論。 • 討論後之結果是否趨於一致？若是，則完成估算；否則回到步驟3，準備進行下一回合的估算。

13. 估算的方法(2/4) • 類似推估法 • 類似推估法的精神，是利用同類型相似的專案做比較。 • 此一方法的最大優點，是當恰好有條件符合之「同類型專案」，且資料正確性高時，即可得到不錯的估算結果。不過此一估算引用的前提（存在維護良好的專案歷史資料），往往不成立。因此實務上必須加入人為的判斷與修正才可以使用。 • 在利用本方法前，應該深入思考如何利用這些經驗，卻又不被這些「經驗」所限。

14. 估算的方法(3/4) • 競標法 • 競標法或者帕金森法則，是一個憑直覺進行估算的方法；也就是說，估算是用喊價的：預估多少，就用掉多少；或者有多少，就做多少，然後再根據估算結果進行專案的開發。 • 此方法的優點是沒有估算準確與否的問題，因為專案會結束在所有資源都用光的時候，只是通常這時系統並未真正全部完成。 • 此一方法沒有多少科學上的根據，但卻是最常見到的方法。

15. 估算的方法(4/4) • 模型演算法 • 模型演算法主要是利用事前存在的經驗模型，帶入相關參數後求取估算值。 • 模型演算法的優點在於模型乃是許多經驗與歷史專案的集合，是經由統計分析後所得到的結果，較不會出現極端的估算數據。因此，此一方法對於估算生手特別值得考慮。 • 如圖5.2所示。

16. 圖5.2 軟體估算模型

17. 功能點分析(1/4) • 功能點分析是衡量軟體規模的一種方法。 • 功能點是功能規模的一種度量單位，其用意在於提出一種獨立於程式語言、工具與技術外，可用以衡量軟體規模的方法。 • 功能點分析衡量軟體的五個構面： • 輸入：是指透過螢幕、對話框、控制項或訊息，由使用者或其它程式所輸入之新增、刪除或修改的資料。 • 輸出：是指透過螢幕、對話框、控制項或訊息，由程式輸出給終端使用者，或其它程式。 • 查詢：是輸入／輸出的結合，代表一個藉由快速、簡單的查詢，所得到的輸出結果。

18. 功能點分析(2/4) • 內部邏輯檔：係指與終端用戶有關的資料檔或控制資訊，完全由程式所控制。該檔可由單一平面文件，或相關資料庫的單一表格所組成。 • 外部介面檔：係指來自於系統邊界外，由其它系統所提供與系統溝通之介面。 • 功能點估算模型如圖5.3所示。

19. 圖5.3 功能點估算模型

20. 功能點分析(3/4) • 功能點的計算 • 功能點的計算程序： • 閱讀軟體功能說明。 • 嘗試建立出「未來軟體」的概念性架構；換句話說，就是勾畫出一幅對於未來產品的藍圖。 • 根據功能點分析，分別找出並計算各個軟體輸出入畫面中的功能點元素。 • 計算畫面中功能點元素的個數，依據其類別，透過查表法進行「複雜度分級」，以決定其複雜度屬於簡單、中等或者複雜。

21. 功能點分析(4/4) 加權後之功能點=調整前的功能點數×影響係數 • 再一次透過查表換算，將複雜度轉換成功能點。 • 將個別所得到的功能點加總，成為調整前的功能點數。 • 估算該系統的影響因子，依照影響程度的大小，求出影響係數，乘以調整前的功能點數，得到加權後的功能點。

24. 14項影響因子 • 資料通訊 • 分散式資料處理 • 效能 • 硬體需求 • 交易頻率 • 線上資料輸入 • 終端使用之有效性 • 線上更新 • 複雜性 • 再用性 • 易於安裝性 • 易於操作性 • 多地域性 • 易於變更

25. Albrecht’s general formula for determining the number of Function Points

26. COCOMO模型(1/5) • COCOMO模型是由Boehm根據他在TRW公司的工作經驗，於1981年在Software Engineering Economics一書中所提出之模型。此模型所估算出來的結果，以及所提供的資訊，較為豐富，能估算的範圍較廣，包括諸如勞力投入、資源與成本、開發時程等；亦可利用敏感度分析（sensitivity analysis）擬訂不同的策略，來調整成本因子。 • COCOMO模型依據軟體的複雜度與困難度，分為三類： • 組織型：軟體專案由資深的開發人員於一個熟悉的開發環境中開發完成，且顧客的需求明確。 • 半分離型：軟體複雜度與困難度介於組織型和內含型之間。開發人員雖曾接觸過相同的專案，但經驗不足。 • 內含型：顧客的需求不明確可能需要較複雜的操作程序。

27. COCOMO模型(2/5) • COCOMO的估算步驟 • 基本模型(Basic)：依照三種軟體專案的特性，分別各有不同的人力與時程的估算公式（如表5.7）。 • 估算步驟如下： • 判斷所要開發的專案係屬於何種類型，如組織型、半分離型或內含型。 • 估算出專案規模，也就是軟體的程式千行數（KLOC），並代入相對應的人力公式中，以得出開發所需的人力，單位為人月（MM）。 • 於前一步驟得到所需人力之後，代入相對應的時程公式中，以得出專案開發的總時程（Time of DEVelopment, TDEV）。

28. 表5.7 COCOMO基本模型的計算公式

29. COCOMO模型(3/5) • 適中模型(Intermediate)：Boehm將軟體成本的因子分成四個構面，分別為：產品屬性、電腦屬性、人員屬性以及專案屬性，用以調整成本估計值。這15個成本因子與評分法如表5.8所示。 • 估算步驟如下： • 計算修正調整因子。 • 計算調整後的程式千行數。 • 估算名目人力。 • 評估成本因子並求出其乘積。 • 估算調整後的人力。 • 估算開發時程。

30. 產品 表5.8 COCOMO適中模型的成本因子

31. 表5.9 COCOMO適中模型的估算公式

32. 適中模型範例(1/3) • 計算調整因子(Adaptation Adjustment Factor) • 僅用於延伸自先前專案者 • AAF=0.4(DM)+0.3(CM)+0.3(IM) • DM: percent of design modification • CM: percent of code modification • IM: percent of integration required for modified software

33. 適中模型範例(2/3) • 計算調整後的程式千行數(Adjusted number of thousand line of code, Adj KLOC) • Adj KLOC = KLOC * AAF • 計算名目人力(nominal effort) • 表5.9

34. 適中模型範例(3/3) • 評估成本因子，求出其乘積(effort adjustment factor, EAF) • 估算調整後的人力 • 估算專案時程(TDEV)，表5.9

35. COCOMO模型(4/5) • 詳細模型(Detailed) • 若進一步考量軟體開發的不同階段，則其成本因子對專案的影響程度可能會有所不同。因此，依據不同的開發階段，給予成本因子不同的權重，會更符合實際的開發狀況，如表5.10所示。 • 詳細模型會將軟體開發分成四個階段：需求與初步設計（Requirement Planning and Design, RPD）、細部設計（Detailed Design, DD）、程式設計與單元測試（Code and Unit Test, CUT）及整合階段（Integration and Test, IT）。每個成本因子在各個階段皆指定有不同的權重。

36. 表5.10 COCOMO詳細模型中分析師能力對專案成本的影響

37. COCOMO模型(5/5) • COCOMO II • 隨著軟體技術的演進，許多新的軟體工程進展，已不在原始模型所涵蓋的範圍內。經過陸續的改進，COCOMO II模型的構想於1995年被提出。此一模型考量了各種新的軟體類型。 • COCOMO II將軟體估算分成三種基本情境： • 應用組合（application composition） • 早期設計（early design） • 結構後期（post-architecture）。

38. 模型的使用(1/2) • 模型的校正 • 模型並非可直接拿來使用，其中的一些參數還需用戶自己設定。 • 較好的解決辦法是由使用者根據自身的經驗，蒐集歷史的專案資料，並參考組織的特性，然後利用迴歸分析來設定或校正這些參數值。 • 模型只是現實世界的抽象表達，還有很多東西是模型無法涵蓋或描述的。因此，還是需要參考專家的意見或加入專業的判斷，以做進一步調整。

39. 模型的使用(2/2) • 估算之分解與混合 • 為了得到更好的結果，軟體的估算應該進行分解，由上到下或者由下而上皆可。 • 「由上到下」是指從大處著眼，比較會考慮到整合、構型管理、文件等所需要的規模與資源。 • 「由下而上」則是先從元件或模組著手。 • 估算原本只是一種預測和猜想，所以每種方法都有其優缺點，這些估算方法基本上是獨立的，彼此不會互相干擾。如果每種方法代表一位專家的意見，那麼可將其集合起來，對照彼此的結果，以增加預測的可靠度。

40. 估算的流程(1/7) • 一個軟體專案的進行，通常需要估算四個主要項目，分別是 • 產品規模 • 工作量 • 人力資源 • 開發時程 • 這些數據是專案規劃的重要依據，彼此之間又存在著相依性的關係。 • 估算的流程如圖5.4所示。

41. 圖5.4 估算的流程

42. 估算的流程(2/7) • 需求的度量 • 需求是軟體專案的源頭，但是需求如何度量，就目前所知，並沒有很好的工具。 • 要得知需求的規模或大小，可能的辦法是建立一種混合的指標計算。例如，需求背後商業規則的數量、資料檔案的數量、使用案例的數量、報表的數量等，以某種函數加總當作需求的度量。 • 產品規模的度量。 • 產品規模就是軟體的大小。嚴格說來，軟體的度量單位只有一種，也就是程式行數或者SLOC（Source Line of Code）。但由於不同類型間的程式碼差異太大，不具有比較意義，故又衍生出如功能點（FP）或物件點（OP）等，與實作無關的度量單位。

43. 估算的流程(3/7) • 勞力需求（或工作量）的度量 • 勞力的基本單位是以工程師的人月（MM）、人天（MD）或人年（MY）作為計算尺度。 • 勞力的估算可利用COCOMO模型的換算公式估算，也可藉由Putnam and Myer的查表法，直接從編碼行數轉換成工作量的估算。 • 人力資源的度量 • 人力資源約略代表專案的成本，工作量不等於人力資源的需求，還必須加計專案的風險成本、管理成本，以及其他雜項事物的成本之後，才是最後專案的人力需求。 • 人力資源的估算方法與工作量的估算相同，可使用一般性的方法，或者也可以分別計算風險成本、管理成本與其它雜項事物的成本，再加上前面的勞力估算，得出最後的人力需求。

44. 估算的流程(4/7) • 工作時程的估算 • 工作時程的估算有一個簡單、由勞力估算換算的公式： 時程（月份數）＝3.0×人月1/3 或者 時程（月份數）＝2.5×人月0.38 • 如果採用的是功能點估算，則可以使用Jones的第一階估算（first-order estimation）。 • 也可利用COCOMO模型來進行工作時程的估算。

45. Jones First-Order Estimation for example: you have a 350 functions point shrink-wrap project, your team technical level is average, you would raise 350 to the 0.42 power (3500.42), for a rough schedule of 12 calendar months.

46. 估算的流程(5/7) • 以「承諾」為基礎的工作時程 • 工作時程的估算有時會受到其它商業或管理上的考量所影響，不經由工作量的估算，就直接從需求推估工作時程。此時開發人員會被要求「承諾」一個工作時程。雖然這是一種很不科學的方式，但實務中卻經常被使用。 • 以承諾為基礎的時程估算，好處在於能夠提升開發人員對工作時程的認可，以及隨著承諾所產生的工作士氣；缺點則是開發人員的估算經常過於樂觀，相對於實際的工作時程，通常少了20%～30%。這會造成專案的時程過於緊張，以致於犧牲了專案品質，使得專案的風險升高。

47. 估算的流程(6/7) • 最短工作時程 • 每一個專案都有一個工作時程底線，而這個時程是無論如何不能再減少的（亦即最短工作時程，如圖5.5）。當愈趨近於這個底線時，專案達成目標的可能性就愈低，且所承受的風險就愈大。故於估算工作時程時，應該先用最樂觀的假設，找出最短工作時程的位置。然後要確定所計劃的工作時程，至少要超過最短工作時程某個比例，否則專案將會面臨巨大的風險。 • 從成本的角度考量，工作時程的規劃應以「合理」為依歸，這樣的花費會比最短的工作時程少很多（如圖5.6）。

48. 圖5.5 最短可能的工作時程

49. 圖5.6 成本和工作時程之關係

50. 估算的流程(7/7) • 時程的縮減 • 倘若一定要縮短工作時程，比較有效的方法，是縮小產品規模或變更系統設計。這些作為可直接降低專案的工作量或勞力需求，進而縮短專案時程。