580 likes | 773 Views
軟體成本預估. 預估軟體發展過程中所需的資源. 本章目的. 瞭解軟體成本和售價預估的基礎以及這兩者之間的複雜關係 瞭解三種評估軟體生產力的指標 瞭解軟體成本和時程預估時使用的不同技術 瞭解成本預估的 COCOMO2 模型原理. 本章內容. 生產力 預估技術 演算式成本模型 專案持續時間與參與人員. 基本預估問題. 完成一個活動需要投入多少工作量 ? 完成一個活動需要多少時間 ? 一個活動的總成本為何 ? 專案的預估與專案的時程規劃是同時進行的. 軟體成本單元. 硬體和軟體的成本 出差和訓練成本 投入的成本 軟體工程師的薪資費用
E N D
軟體成本預估 • 預估軟體發展過程中所需的資源
本章目的 • 瞭解軟體成本和售價預估的基礎以及這兩者之間的複雜關係 • 瞭解三種評估軟體生產力的指標 • 瞭解軟體成本和時程預估時使用的不同技術 • 瞭解成本預估的COCOMO2模型原理
本章內容 • 生產力 • 預估技術 • 演算式成本模型 • 專案持續時間與參與人員
基本預估問題 • 完成一個活動需要投入多少工作量 ? • 完成一個活動需要多少時間 ? • 一個活動的總成本為何 ? • 專案的預估與專案的時程規劃是同時進行的
軟體成本單元 • 硬體和軟體的成本 • 出差和訓練成本 • 投入的成本 • 軟體工程師的薪資費用 • 員工福利及保險成本 • 成本也應把下列包括在內 • 建築物成本,冷暖氣,燈光 • 網路及通訊成本 • 公用設施的成本 (如圖書,員工餐廳等等.)
成本與報價 • 軟體成本的預估應該客觀的以正確預測軟體開發承包商的成本為目標進行 • 決定專案成本併入客戶的報價計算情況 • 軟體售價受到組織、經濟、政治、商業考量的影響
程式設計師生產力 • 一個製造系統的生產力可以由產出的數量除以投入的人員工時計算而得 • 當有許多包含不同特性的解決方案存在時,用生產率做比較是沒有太大意義的。 • 單位時間內的生產力
生產力度量 • 大小有關的度量和活動輸出結果的大小有關。最常見的大小度量為程式碼的行數,其他還有目的程式碼的指令數和系統文件的頁數等。 • 功能性的度量和軟體整體功能有關。生產力是以給定時間內產生的有效功能數量為指標。功能點數和物件點數為這類型最有名的度量指標。
度量問題 • 預估系統大小方法 • 預估程式設計師每個月程式碼的數量 • 預估生產力(如文件數量)並將此種度量合併至總預估量做計算
程式碼行數 • 什麼是程式碼行數? • 每張卡片只有一個敘述。計算程式碼行數很簡單,只要算出程式的卡片數量即可 • 像Java或C++之類的程式語言,它們的程式是由宣告、可執行的敘述、備註說明等組成 • 什麼樣系統裏的程式碼須要計算? • 系統大小和卡片數量之間的線性關係
生產力的比較 • 較低階的程式語法,對於程式設計師有比較多的生產力 • 在相同的功能上,低階的語法要比高階語法有著更多程式碼 • 程式語言表達愈豐富,表面上的生產力就愈低 • 利用程式碼行數來量測生產力,通常看來寫比較多程式碼的程式設計師的生產力大於寫的較精簡式碼程式設計師
分析 設計 撰寫 確認 高和低階語言 低階語言 分析 設計 撰寫 確認 高階語言
功能點數 • 功能總點數是由度量或預估下列的程式特性而來 • 外部的輸入與輸出 • 使用者介面 • 外部介面 • 系統使用的檔案 • 範圍權重值 • 所有重點功能經由乘上預估的權重值,再將所以值加總而得
功能點數 • 修正因子是以專案的整體複雜度為基礎 • FPs 可以用來預估 LOC ,功能點數時所需的平均程式碼行數 • LOC = AVC * 功能點數 • AVC的範圍可以從組合語言中的200-300 LOC/FP到4GL的2-40 LOC/FP • FPs是非常主觀。他們通常靠主觀意見來判定 • 無法自動計算功能點數
物件點數 • 物件點數是一個功能的量測法,用在4Gl或相似語言的發展 • 相同的物件等級有不同物件點數 • 程式物件點數權重的預估 • 顯示成不同畫面的畫面數量 • 產生的報告數量 • 必須經過開發以補充4GL程式碼不足的3GL模組數量
物件點數預估 • 物件點數可以從畫面及功能點數來預估,並與3GL的模組有關 • 他們可能在發展過程中提早預估點數。而在這情況下通常難以預估系統的程式碼數目
生產力預估 • 即時嵌入式系統, 40-160 LOC/每個月 • 系統程式, 150-400 LOC/每個月 • 商用程式, 200-800 LOC/每個月 • 生產力的範圍可能會依據支援的工具和開發人員的能力,從每個月4個物件點數轉到每月50個物件點數。
品質與生產力 • 使用數量/時間的度量表示有其問題,它沒有將非功能的軟體特性列入考慮 • 生產力通常有可能會增加品質的成本 • 生產力與品質並沒有太大的相關 • 程式碼不斷簡化與改善,那麼程式碼的行數就沒有太大的意義了
預估技術 • 正確的預估軟體系統開發時所需的工作量並沒有簡單的方法 • 初始的預估可能就必須以高階使用者的需求定義為基礎 • 軟體可能必須在不熟悉的電腦作業環境下執行,或是使用新的技術開發 • 而參與專案的人員和技術也許都不清楚 • 專案成本預估通常是自己完成的 • 預估技術可以定義專案的預算,以及調整產品與實現預算的估算
預估技術 • 演算式成本模型 • 專家的判斷 • 以類推的方式預估 • Parkinson法則 • 價格取勝
演算式成本模型 • 利用過去的成本資訊開發出來的模型,這些成本資訊是與專案成本有關的軟體度量指標
專家判斷 • 諮詢多位對提案使用之軟體開發技術以及應用領域熟悉的多位專家 • 有利條件:可以得到非常正確的預估 • 不利條件:沒有專家的判斷可能會造成非常不正確的預估
類推預估 • 適用於同一應用領域或已經有其他專案完成時 • 有利條件:可用參考性資料 • 不利條件:無法完全利用於整個專案。必預有計畫的來調整預估
Parkinson`s 法則 • 成本是由可用資源來決定,而非對目標的評估 • 有利條件:不會超支 • 不利條件:系統通常尚未完成
價格取勝 • 專案價格以客戶的預算來預估 • 有利條件: 得到合約 • 不利條件: 客戶可能所得到的系統比他們所預想的還小。且成本也無法正確跟工作量成正比
由上而下及由下而上預估 • 任何方式都可以用由上而下或由下而上的預估 • 由上而下 • 由系統層次開始,預估者先檢驗整體的產品功能以及這些功能如何由子功能的互動提供 • 由下而上 • 系統分解成數個元件,所以先計算開發這些元件所需的工作量
由上而下預估 • 使用範圍以外的系統架構知識和將系統分為幾個部份來預估 • 成本的考量如整合、組態管理及文件 • 無法評估低階層技術問題
由下而上預估 • 使用本身系統所知架構和元件來預估 • 針對詳細系統設計上的是一個準確預估的好方法 • 無法評估系統面的問題如整合性及文件
預估方式 • 每個方式都有優點及缺點 • 預估方式應該由數種方式當基礎 • 如果成本預估和結果做比較沒有相同的結果,代表你的資訊還不足 • 重複計算成本的流程直到結果趨於相同為止 • 價格取勝有時也是唯一可用的方法
有經驗的預估 • 預估的方式主要依靠有經驗的基礎 • 新的方式及技術影響,下列這些變更可能會影響成本的預估 • 使用物件導向開發 • 使用主從式架構 • 使用商用現成軟體的元件 • 使用再利用式開發 • 使用CASE工具和程式產生器
價格取勝 • 這種方法可能是不合理的成本估算 • 當你缺乏詳細資訊,這種方式或許是你唯一的手段 • 成本是以客戶可投入在該專案發展的任何資源來預估 • 工作量是以客戶的預算來預估,而非軟體的功能
演算式成本模型 • 透過分析已完成專案的成本與特性可以建立出演算式成本模型 • Effort = A × SizeB × M • A為固定因素,依據組織本身而定,指數B大型專案所需成本呈現不均衡狀態 M由不同的流程、產品和發展特性結合而成 • 大部份一般產品預估都是利用程式碼的多寡 • 大部份的模型都算式都基本上類只是差異在數值A,B 和 M
準確預估 • 預估的正確性會根據完成的系統資訊而定 • 幾種因素會影響最後所完成的系統的大小 • 元件的使用 • 程式語法 • 分散式系統 • 軟體程序持續進行,有愈多的可用資訊出現時,預估的準確性就愈高
COCOMO模型 • 一個以經驗為主的模型 • 文件資料(independent) 模型,而非依附特定軟體廠商 • 歷史悠久最早出現1981(COCOMO-81)到現在的 COCOMO 2 • COCOMO 2 考慮不同的系統發展及可用性
COCOMO 2 階段 • COCOMO 2 一個三階段的模型。而程序剛開始時就預估,而在系統結構完成後再做更詳細的預估。 • 初期雛形階段(early prototyping level): • 軟體大小的預估是依照物件點數和簡單的大小/生產力公式來預估所需的工作量 • 初期設計階段(early design level): • 它的預估是依照功能點數為主,然後再將這些點數轉換成程式碼行數。 • 後架構階段(post-architecture level): • 預做完成後的程式碼
初期雛形階段 • 主要是用來支援使用雛形法的專案,以及使用組合現存元件方式開發的專案 • 是以一個預估的加權物件點數為主再將它除以預估生產力的標準估算 • 根據開發者的經驗、能力以及使用CASE工具的能力而定 • 公式 • PM = ( NOP ´ (1 - %reuse/100 ) ) / PROD • PM為以人月(person-months)計的工作量,NOP為物件點數(Number of Object Point),PROD為生產力(productivity)
初期設計階段 • 認同的預估 • 標準的演算式模型做為預估的標準 • PM = A × SizeB × M + PMm • M = PERS × RCPX × RUSE × PDIF × PREX × FCIL × SCED • PMm = (ASLOC ×(AT/100)) / ATPROD • A = 2.5 的係數,系統的大小是以KSLOC來表示 , B 值 從 1.1 到 1.24表示隨專案規模擴大所增加的工作量
乘數因子M • 乘數因子M則是取自專案及流程的七種重要因素 • RCPX -產品可靠度與複雜度 • RUSE -再利用需求 • PDIF -平台困難度 • PREX -個人能力 • PERS -個人經驗 • SCED -時程 • FCIL -支援設備 • PMm是在程式碼有很大的百分比是自動產生時使用的因子
後架構階段 • 使用初期設計公式 • 大小的調整預估 • 需求的易變性。依需求做改變 • 再利用的可能程度。大量重複使用表示必須修改真正由人為開發的程式碼行數 • ESLOC = ASLOC × (AA + SU +0.4DM + 0.3CM +0.3IM)/100 • ESLOC為新的程式碼行數,ASLOC為必須修正的可再利用之程式碼行數,DM為被修改的設計百分比,CM為被修改的程式碼百分比,IM則為整合再利用軟體所需的原始整合工作量。 • SU是指瞭解軟體的所需成本,範圍可以從50到10。AA則是決定軟體是否使用再利用元件的初始評估成本,根據需要測試與評估的量,它的數值範圍可以從0到0.8。
計算指數 • 五種因素的評估值加總後除以100,再加上1.01就是需要指數項。 • 範例 • 可循前例程度 – 新專案 – 4 • 開發彈性 -客戶未涉入 – Very High - 1 • 架構/風險分析程度 – 未做風險分析 - V. Low - 5 • 團隊向心力 – 新團隊 - nominal - 3 • 流程成熟度 –有些流程控制適當 - nominal - 3 • 最終的指數為1.17
相關指數 • 產品特性 • 正在開發的軟體產品所需的特色 • 電腦特性 • 由硬體平台加諸於軟體的限制 • 個人特性 • 將個人工作經驗及能力列入考慮的乘數因子 • 專案特性 • 與軟體開發專案相關的某些特色。