Software Project Estimation

為什麼要做軟體估計? 低估了軟體開發及導入的成本。 不同的估算法所得結果差異非常大。 低價搶標策略使得軟體成本的問題更加嚴重。 影響軟體成本的因素很多，精確的估算並不容易

Five levels of CMM Initial (1) Managed (2) Defined (3) Requirements Management Project Planning Project Monitoring and Control Supplier Agreement Management Measurement and Analysis Process and Product Quality Assurance Configuration Management Defined (3) Quantitatively Managed (4) Optimizing (5)

Project Planning SG1 Establish Estimates SG 2 Develop a Project Plan SP 1.1 Estimate the Scope of the Project SP 1.2 Establish Estimates of Work Product and Task Attributes SP 1.3 Define Project Life Cycle SP 1.4 Determine Estimates of Effort and Cost SG 2 Develop a Project Plan SP 2.1 Establish the Budget and Schedule SP 2.2 Identify Project Risks SP 2.3 Plan for Data Management SP 2.4 Plan for Project Resources SP 2.5 Plan for Needed Knowledge and Skills SP 2.6 Plan Stakeholder Involvement SP 2.7 Establish the Project Plan

軟體成本影響因素 影響軟體開發成本的因素稱為成本因子。這些因子可以歸納成七類屬性，有助於思考成本的來源與模式的建立 (林信惠, 1993) 規模屬性 產品屬性 資訊科技屬性 人員屬性 專案屬性 環境屬性 管理屬性 (林信惠, 1993)

規模屬性 原始碼的行數 子程式的數目 功能點 資料項目的數目 文件的頁數

產品屬性 軟體類型 軟體複雜度 使用的程式語言 要求的品質與可靠度 再用碼的數量 處理時間的限制

資訊科技屬性 硬體架構 網路架構 軟體平台 中央處理器、記憶體及通訊的限制 使用資訊科技的成熟度

人員屬性 開發者的一般能力與學習能力 開發者的經驗 類似專案與開發環境的經驗 專案經理的經驗

專案屬性 使用方法與工具 需求明確的程度 和顧客的溝通與關係 開發時程的緊迫性 專案組織的大小 預算充裕的程度

環境屬性 行政複雜度 使用者參與程度 需求變更的頻繁程度 市場競爭的程度

管理屬性 專案管理者的領導能力與經驗 團隊合作 資源分配 時程安排與控制 訓練 品質保證

軟體成本的分類 生命週期成本分類 成本會計分類

生命週期成本分類 生命週期成本分為開發成本和維護成本。依Putnam (1978)模式，開發成本約占45%；維護成本約占55%。 更詳細的分類則可依生命週期的需求分析、設計、編碼、整合測試及維護各階段所占的成本百分比 除了開發與維護成本外，一些重要的作業也應細估其成本： 轉換成本。 裝置成本。 訓練成本。 其他成本。

成本會計分類 直接成本 設備成本 費用 分攤費用 系統開發人員的成本，包括系統分析師、程式設計師、專案經理及其他直接參與專案開發的人員。 硬體、軟體、辦公設備及其他設施的成本。 費用 旅費、顧問費、訓練費用等。 分攤費用 行政人員費用、水電費、辦公用品費用、保險費、管理費等。

軟體成本估計的過程 軟體成本估計是一個估計的過程，由一開始非常粗略的估計慢慢深入，直到對所估計的系統有相當信心為止。

軟體成本估計過程 提出構想 粗略的成本估計與資料蒐集 專家判斷法 由上往下法 管理者依經驗與判斷評估可行性及成本效益 方案可行且 N 取消構想 方案可行且 效益大於成本？ 由專家小組分析需求並分解系統功能 正式估計成本 由下往上法 參數法 類比法 N Y

軟體成本估計過程 專案核准？ N 取消專案 Y 進行詳細的需求分析 與初步設計 修改估計的成本 成本太高？ 取消專案？ 細部設計、編碼、測試 調整及控制成本 結束 調整預算或調整專案功能

軟體成本估計的方法 Boehm(1984) Mohanty(1981) 多種方法相互驗證 演算模式 專家判斷法 類比法 由上往下法 由下往上法 巴金森法(Parkinson Method) – 多少預算做多少事 勝算價格法 (Price-to-Win Method) – 以可獲得合約的價格為基礎 Mohanty(1981) 歷史資料模式 統計分析模式 理論模式 多種方法相互驗證

專家判斷法 專家判斷法是依賴一個或多個專家的經驗來做估計。 專家判斷適用於專案的早期，當需求仍不甚明確時。在引進新科技或新方法時，因為沒有歷史資料，所以也要借助於專家判斷。 專家判斷法仍是目前最廣為應用的方法。

專家群體決策判斷法 多估計值的綜合方法： 平均法 去除極值平均法 中位數法 三點估計法(每位專家分別估計三個值) 德菲法 - Delphi method (無經驗時) 群體決策用來達成共識的方法，使用匿名會議，經過數回合評估，每回合評估將彙總資料公佈，希望去除極值並減少估計者受權威人士的影響。

依環境的改變、技術、需求、人事成本及風險等加以調整 類比法 找一個已完成且類似的專案 將目標專案及已完成專案的 功能分解成子功能 找出要修改、刪除及新增的模組 估計修改、刪除及新增模組 所需的成本 依環境的改變、技術、需求、人事成本及風險等加以調整 看起來相似可能存在大的誤差

參數模式 參數模式(Parametric Models) 參數模式又稱演算法則模式或統計模式，這些模式的基本概念是軟體的開發成本為軟體規模和調整因子的函數。 軟體規模的單位為原始碼的行數或功能點；調整因子則是影響軟體開發成本的因素。函數的型式可為線性或非線性。參數估計模式可為下列的型式。

參數模式 成本＝常數＋軟體規模之成本函數 × 調整因子 或 成本＝常數＋軟體規模之成本函數＋調整因子 若以數學式表示則為： 　或 成本＝常數＋軟體規模之成本函數＋調整因子 若以數學式表示則為： C：估計成本；以人-月或人-天為單位 s：軟體規模；以程式行數或功能點為單位 f：規模函數 x：調整因子的向量；x=(x1, x2, …, xn) g：調整函數 C0：常數

規模函數 規模函數 f 可為線性規模函數或非線性規模函數式中的係數 a 和 b 為統計迴歸分析所得的結果。 f(s)＝a．s　 （線性規劃函數） f(s)＝aSb　　　（非線性規劃函數）

調整函數 調整函數 g(x) 則為個別調整因子函數值 gi(xi)的總和或乘績，亦即：

參數模式 - Farr and Zagorski模式 此模式為一簡單的加法模式，可以寫成： 其中C0 ＝－188，a＝2.68 成本因子及其係數如下表

Farr 與 Zagorski 的成本因子及係數 值 成本因子 單位 2.68 2.3 33 －17 10 1 指令數 旅行哩數 文件數 系統程式師經歷 螢幕畫面數 新碼的百分比 千行 千哩 實際數 年 百分比

COCOMO 模式 COCOMO模式 COCOMO模式可分為三個估計的詳細程度： 此模式為一非線性的模式，其型式如下： 基本模式：是一種粗略的估計。 中級模式：考慮15項的成本調整因子。 詳細模式：將成本因子的權重依開發階段來劃分。 Note: C (effort) 單位為 人月 S 單位為 KDSI - Thousands (K) of Deliverable Source Instructions (KDSI).

COCOMO 模式 軟體複雜度的分類 簡單型 中間形 複雜型 小型、簡單、低複雜度、低風險，開發團隊對所開發之專案有豐富的經驗且需求定義明確。 中間形 中等規模、中等複雜度的專案。 複雜型 高複雜度、限制嚴格的專案。例如整合性系統、高品質、高可靠度要求、及重要任務系統。

COCOMO基本模式 基本模式 基本模式依下列公式估計成本： a 和 b 的係數如下表所示 類型 模式 基本模式 中級模式 詳細模式 基本模式 中級模式 詳細模式 a b a b a b 簡單型 中間型 複雜型 2.4 1.05 3.2 1.05 3.2 1.05 3.0 1.12 3.0 1.12 3.0 1.12 3.6 1.20 2.8 1.20 2.8 1.20

Total Development time months k 簡單型 0.38 中間型 0.35 複雜型 0.32

COCOMO中級模式 中級模式 中級模式依下列公式估計成本： 和基本模式不同的是它考慮了十五個調整因子。

COCOMO 調整因子乘數 等 級 成本因子 很低 低 中等 高 很高 超高 產品屬性 軟體可靠度的需求 .75 .88 1.00 1.15 等　　　　級 成本因子 很低 低 中等 高 很高 超高 產品屬性 軟體可靠度的需求 .75 .88 1.00 1.15 1.40 資料庫大小 .94 1.08 1.16 產品複雜度 .70 .85 1.30 1.65 電腦屬性 執行時間的限制 1.11 1.66 主記憶體的限制 1.06 1.21 1.56 系統軟體 (OS 、 DBMS 等 ) 的更換 .87 電腦停機時間 1.07 人員屬性 分析師的能力 1.46 1.19 .86 .71 工作經驗 1.29 1.13 .91 .82 程式設計師的能力 1.42 1.17 相關系統軟體的經驗 1.10 .90 程式語言的經驗 1.14 .95 專案屬性 使用新的規劃方法 1.24 1.1 使用軟體工具 .83 開發時程的需求 1.23 1.04

COCOMO 詳細模式 詳細模式 詳細模式將調整乘數再分配到各個不同的開發階段，例如，程式設計師的能力若被評為非常低時，依上表其調整乘數為1.42，將此乘數分配到四個開發階段的結果如下：

Phase Effort Distribution Mode Phase Small 2 KDSI Intermediate 8 KDSI Medium 32 KDSI Large 128 KDSI Very Large 512 KDSI ORGANIC Product Design 16 --- Programming 68 65 62 59 Detailed Design 26 25 24 23 Code & Unit Test 42 40 38 36 Integration & Testing 19 22 SEMI-DETACHED 17 64 61 58 55 52 27 37 35 33 31 29 28 EMBEDDED 18 60 57 54 51 48 32 30 34 Note: KDSI - Thousands (K) of Deliverable Source Instructions (KDSI).

Reference for COCOMO 模式 Software Estimating - Basic Time & Cost, CASG Journal, Allen (1995)

COCOMO II 以調整指數 E 取代簡單、中間、及複雜型等軟體複雜程度 Note: 調整因子分別代表 (1) 先前經驗 (2) 需求與時程的彈性 (3) 系統架構與風險 (4) 團隊凝聚力 (5) 成熟度 (CMMI)

COCOMO II 三階段法取代基本、中級、以及詳細模式 第一階段-Application Composition Model: 以 object-point 估計軟體規模 以軟體規模轉換為人-月為單位成本 適用於物件組成軟體，如多媒體應用 第二階段-Early Design Model: 以功能點來估計軟體規模 依功能點轉換位為原始碼行數(S) 七個調整因子修正

COCOMO II 第三階段-Post Architecture Model: 同第二階段資料 七個調整因子變為十七個

功能點分析法 (Function Point Analysis) 不論導入CMM或CMMI制度Leve l，2 中皆有一項重要的工作為專案預估(Project Estimation)。目前國際上常使用的方法為IFPUG(Internal Function Point User Group)所發展之功能點分析法(Function Point Analysis)，此方法能有效度量軟體專案規模(SIZE)進而估算出軟體專案所需成本，可以有效協助專案估價、成本監控、度量分析等專案後續作業。 功能點分析法為一種系統化分析與度量專案開發階段之成本，且能依據組織之專案特性持續改善預估準確度的一種方法。

功能點分析方法之演進 功能點分析法（Function Point Analysis）最早是在1970 年代，由IBM 一位工程師Allan Albrecht 開始發展度量軟體專案規模之觀念。經過了數年的研究，Albrecht 發展出最初的Function Point 版本提供給IBM 內部使用，並於1984 年發表IBM CIS & A Guideline 313 AD/M Productivity Measurement and Estimate Validation 概念文件。直到1988 年由於使用者眾多而產生了一個非營利的IFPUG (The International Function Point Users Group）組織的成立，並逐年成長，發展成為目前世界上最大的軟體預估相關機構組織之一。目前最新的版本為IFPUG 在2000 年4 月發表的Function Point Counting Practice Manual Release 4.1.1。 ISO/IEC 20926:2003 Software engineering

功能點分析方法之演進

使用者觀點(User View) 與功能分類 功能點分析方法強調由使用者觀點(User View)估算所開發之軟體系統功能性並量化成功能點數(Function Points)，而並不是由技術觀點(Technical View)分析系統之功能。 所謂使用觀點為採用使用者的語言來描述使用者的功能需求，而系統開發人員依據使用者功能需求提供解決方案並使用資訊技術翻譯使用者功能需求，不是站在開發人員角度與使用技術觀點分析量化系統規模大小。 實務上導入初期時許多人員因觀念不清處而以技術觀點使用本分析方法，所以會對本方法產生許多質疑，如系統中有多複雜之特殊模組、副程式或使用最新之語言技術皆為由技術觀點估算系統規模。

使用者觀點的功能型態 資料功能類(Data Function Type) 內部邏輯檔案(Internal Logical File) 外部介面檔案(External Interface File) 交易功能類(Transaction Function Type) 外部輸入檔案(External Input File) 外部輸出檔案(External Output File) 外部查詢檔案(External Inquire File)

Internal Logical Files The first data function allows users to utilize data they are responsible for maintaining. For example, a pilot may enter navigational data through a display in the cockpit prior to departure. The data is stored in a file for use and can be modified during the mission. Therefore the pilot is responsible for maintaining the file that contains the navigational information. Logical groupings of data in a system, maintained by an end user, are referred to as Internal Logical Files (ILF).

External Interface Files The second Data Function a system provides an end user is also related to logical groupings of data. In this case the user is not responsible for maintaining the data. The data resides in another system and is maintained by another user or system. The user of the system being counted requires this data for reference purposes only. For example, it may be necessary for a pilot to reference position data from a satellite or ground-based facility during flight. The pilot does not have the responsibility for updating data at these sites but must reference it during the flight. Groupings of data from another system that are used only for reference purposes are defined as External Interface Files (EIF).

External Input The first Transactional Function allows a user to maintain Internal Logical Files (ILFs) through the ability to add, change and delete the data. For example, a pilot can add, change and delete navigational information prior to and during the mission. In this case the pilot is utilizing a transaction referred to as an External Input (EI). An External Input gives the user the capability to maintain the data in ILF's through adding, changing and deleting its contents.

External Output The next Transactional Function gives the user the ability to produce outputs. For example a pilot has the ability to separately display ground speed, true air speed and calibrated air speed. The results displayed are derived using data that is maintained and data that is referenced. In function point terminology the resulting display is called an External Output (EO).

External Inquiries The final capability provided to users through a computerized system addresses the requirement to select and display specific data from files. To accomplish this a user inputs selection information that is used to retrieve data that meets the specific criteria. In this situation there is no manipulation of the data. It is a direct retrieval of information contained on the files. For example if a pilot displays terrain clearance data that was previously set, the resulting output is the direct retrieval of stored information. These transactions are referred to as External Inquiries (EQ).

Function Point Calculation Procedure Function point calculation is a three step process: Evaluate the Unadjusted Function point count Evaluate the Value Adjustment Factor (VAF) Apply the VAF to the Unadjusted Function Point Count (depending on project grouping)

Function Point Analysis Worksheet

未調整功能點數 (Unadjusted Function Point) 記錄元素(Record Element Type):使用者於內部邏輯檔案(ILF)與外部介面檔案(EIF)中可以辨別的一組子資料元素群組，每一組子群組中的資料有邏輯相關性。如個人資料群組檔案與交易記錄檔案屬於兩種不同群組織資料元素。 參考檔案(File Type Reference):為系統處理交易時相關聯性之檔案。FTR 的檔案類型必為內部邏輯檔案(ILF)或外部介面檔案(EIF) 。 資料元素(Data Element Type):使用者可以辦視的單一資料元素，計算時不包含遞迴之資料元素(不重複計算)。如個人資料中的姓名、年齡、聯絡地址等皆屬於一個資料元素。

Functional Complexity These five function types are given a numerical rating from 3 to 15 depending on their complexity Complexity for each Data Function Type (ILF & EIF) is determined by Record Element Types (RET) and Data Element Type (DET) Complexity for each Transactional Function Type (EI, EO, and EQ) is determined by File Types Referenced (FTR) and Data Element Types (DET)

Functional Complexity Shared Internal Logic File (ILF) and External Interface File (EIF) Table 1 to 19 DET 20 to 50 DET 51 or more DET 0 or 1 RET Low Average 2 - 5 RET High 6 or more RET

Functional Complexity External Input (EI) Table 1 to 4 DET 5 to 15 DET 16 or more DET 0 or 1 FTR Low Average 2 FTR High 3 + FTR

Functional Complexity Shared External Output (EO) and External Inquires table(EQ): 1 to 5 DET 6 to 19 DET 20 or more DET 0 or 1 FTR Low Average 2 or 3 FTR High 4 or more FTR

Example:a simple navigational system used by pilot www Example:a simple navigational system used by pilot www.process-strategies.com/pp_4.htm Function name Function type RET DET FTR Complexity Navigational data ILF 3 36 N/A Positional data EIF Navigational data-add EI 1 Navigational data-del Navigational data-change Ground speed display EO 20 Air speed display Calibrated air speed display Terrain clearance display EQ

Value Adjustment Factor 1. Data Communications (資料通訊) The data and control information used in the application are sent or received over communication facilities. 2. Distributed Data Processing (分散式功能) Distributed data or processing functions are a characteristic of the application within the application boundary. 3. Performance (效能要求) Application performance objectives, stated or approved by the user, in either response or throughput, influence (or will influence) the design, development, installation and support of the application. 4. Heavily Used Configuration (使用量) A heavily used operational configuration, requiring special design considerations, is a characteristic of the application.

Value Adjustment Factor 5. Transaction Rate (交易處理頻率) The transaction rate is high and influences the design, development, installation and support. 6. On-line Data Entry (線上輸入) On-line data entry and control information functions are provided in the application. 7. End -User Efficiency (提供線上功能提升末端使用者效率) The on-line functions provided emphasize a design for end-user efficiency. 8. On-line Update (線上更新) The application provides on-line update for the internal logical files. 9. Complex Processing (處理複雜度) Complex processing is a characteristic of the application. 10. Reusability (程式再使用) The application and the code in the application have been specifically designed, developed and supported to be usable in other applications.

Value Adjustment Factor 11. Installation Ease (安裝容易度) Conversion and installation ease are characteristics of the application. A conversion and installation plan and/or conversion tools were provided and tested during the system test phase. 12. Operational Ease (操作容易性) Operational ease is a characteristic of the application. Effective start-up, backup and recovery procedures were provided and tested during the system test phase. 13. Multiple Sites (多點安裝) The application has been specifically designed, developed and supported to be installed at multiple sites for multiple organizations. 14. Facilitate Change (設備變更仍可使用) The application has been specifically designed, developed and supported to facilitate change.

Value Adjustment Factor Value Adjustment Factor = (TDI x 0.01) + 0.65

Development ( Project ) Function Point Calculation DFP = UFP * VAF Where: DFP = Development ( Project ) Function Point Count VAF = Value Adjustment Factor UFP = Unadjusted Function Point Count

LOC (optional) LOC = DFP X LOC/DFP