Transcript 第二十三章

軟體成本預估

預估軟體發展過程中所需的
資源
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 1
本章目的




瞭解軟體成本和售價預估的基礎以及這兩者之
間的複雜關係
瞭解三種評估軟體生產力的指標
瞭解軟體成本和時程預估時使用的不同技術
瞭解成本預估的COCOMO2模型原理
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 2
本章內容




生產力
預估技術
演算式成本模型
專案持續時間與參與人員
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 3
基本預估問題




完成一個活動需要投入多少工作量 ?
完成一個活動需要多少時間 ?
一個活動的總成本為何 ?
專案的預估與專案的時程規劃是同時進行的
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 4
軟體成本單元



硬體和軟體的成本
出差和訓練成本
投入的成本
• 軟體工程師的薪資費用
• 員工福利及保險成本

成本也應把下列包括在內
• 建築物成本,冷暖氣,燈光
• 網路及通訊成本
• 公用設施的成本 (如圖書，員工餐廳等等.)
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 5
成本與報價



軟體成本的預估應該客觀的以正確預測軟體開
發承包商的成本為目標進行
決定專案成本併入客戶的報價計算情況
軟體售價受到組織、經濟、政治、商業考量的
影響
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 6
軟體價格因素
因素
說明
市場機會
軟體開發公司可能會因為想要投入某個新的軟體市場，而將售
價估的非常低。接受某一個專案上的低獲利可能可以造就之後
更高獲利的機會。從獲得的經驗中可以開發新的產品。
成本預估不確定性
如果某個組織無法確定它的成本預估，它可能會在價格中加入
比正常利潤還高的一些其他費用，使得其售價增加。
契約項目
客戶可能允許開發者保留原始程式碼的擁有權，讓此程式碼可
以應用到其他專案。這個售價比將原始程式碼完全交給客戶的
售價要低。
需求易變
如果需求有可能改變，組織可能會降價以搶得合約。在取得合
約之後，再以需求變更的理由提高價格。
財務情形
開發者可能會因為財務上的困難而降價以取得合約。賺少一點
或是賺正常的利潤總比完全出局來得好。
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 7
程式設計師生產力



一個製造系統的生產力可以由產出的數量除以
投入的人員工時計算而得
當有許多包含不同特性的解決方案存在時，用
生產率做比較是沒有太大意義的。
單位時間內的生產力
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 8
生產力度量


大小有關的度量和活動輸出結果的大小有關。
最常見的大小度量為程式碼的行數，其他還有
目的程式碼的指令數和系統文件的頁數等。
功能性的度量和軟體整體功能有關。生產力是
以給定時間內產生的有效功能數量為指標。功
能點數和物件點數為這類型最有名的度量指標
。
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 9
度量問題



預估系統大小方法
預估程式設計師每個月程式碼的數量
預估生產力(如文件數量)並將此種度量合併至
總預估量做計算
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 10
程式碼行數

什麼是程式碼行數?
•
每張卡片只有一個敘述。計算程式碼行數很簡單，只要算
出程式的卡片數量即可
• 像Java或C++之類的程式語言，它們的程式是由宣告、可執
行的敘述、備註說明等組成


什麼樣系統裏的程式碼須要計算?
系統大小和卡片數量之間的線性關係
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 11
生產力的比較

較低階的程式語法，對於程式設計師有比較多
的生產力
• 在相同的功能上，低階的語法要比高階語法有著更多程式
碼

程式語言表達愈豐富，表面上的生產力就愈低
• 利用程式碼行數來量測生產力，通常看來寫比較多程式碼
的程式設計師的生產力大於寫的較精簡式碼程式設計師
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 12
高和低階語言
低階語言
分析
設計
撰寫
確認
高階語言
分析
©Ian Sommerville 2000
設計
撰寫
確認
Software Engineering, 6th edition. Chapter 23
Slide 13
系統開發時間
分析
設計
程式碼撰寫
測試
文件化
組合語言碼
3星期
5星期
8星期
10星期
2星期
高階語言
3星期
5星期
8星期
6星期
2星期
大小
工作量
生產力
組合語言碼
5000行
28星期
714行/月
高階語言
1500行
20星期
300行/月
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 14
功能點數

功能總點數是由度量或預估下列的程式特性而
來
•
•
•
•


外部的輸入與輸出
使用者介面
外部介面
系統使用的檔案
範圍權重值
所有重點功能經由乘上預估的權重值，再將所
以值加總而得
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 15
功能點數


修正因子是以專案的整體複雜度為基礎
FPs 可以用來預估 LOC ，功能點數時所需的
平均程式碼行數
• LOC = AVC * 功能點數
• AVC的範圍可以從組合語言中的200-300 LOC/FP到4GL的240 LOC/FP

FPs是非常主觀。他們通常靠主觀意見來判定
• 無法自動計算功能點數
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 16
物件點數



物件點數是一個功能的量測法，用在4Gl或相
似語言的發展
相同的物件等級有不同物件點數
程式物件點數權重的預估
• 顯示成不同畫面的畫面數量
• 產生的報告數量
• 必須經過開發以補充4GL程式碼不足的3GL模組數量
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 17
物件點數預估


物件點數可以從畫面及功能點數來預估，並與
3GL的模組有關
他們可能在發展過程中提早預估點數。而在這
情況下通常難以預估系統的程式碼數目
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 18
生產力預估




即時嵌入式系統, 40-160
LOC/每個月
系統程式, 150-400 LOC/每個月
商用程式, 200-800
LOC/每個月
生產力的範圍可能會依據支援的工具和開發人
員的能力，從每個月4個物件點數轉到每月50
個物件點數。
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 19
生產力因素
因素
說明
應用領域經驗
應用領域知識對有效的軟體開發很重要，若工程師已經非常瞭解該領
域，就可以有非常高的生產力。
流程品質
開發流程對生產力也有很明顯的影響，我們將於第25章做介紹。
專案大小（規模）
大型專案的團隊溝通需要較多的時間，開發的可用時間就會減少，個
人生產力就因此而降低。
技術支援
良好的技術支援，如CASE工具、組態管理系統的支持度等，都可以
增進生產力。
工作環境
如第22章所討論，工作環境若是安靜且獨立的空間，生產力也會提高
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 20
品質與生產力




使用數量／時間的度量表示有其問題，它沒有
將非功能的軟體特性列入考慮
生產力通常有可能會增加品質的成本
生產力與品質並沒有太大的相關
程式碼不斷簡化與改善，那麼程式碼的行數就
沒有太大的意義了
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 21
預估技術

正確的預估軟體系統開發時所需的工作量並沒
有簡單的方法
• 初始的預估可能就必須以高階使用者的需求定義為基礎
• 軟體可能必須在不熟悉的電腦作業環境下執行，或是使用
新的技術開發
• 而參與專案的人員和技術也許都不清楚

專案成本預估通常是自己完成的
•
預估技術可以定義專案的預算，以及調整產品與實現預算
的估算
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 22
預估技術





演算式成本模型
專家的判斷
以類推的方式預估
Parkinson法則
價格取勝
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 23
演算式成本模型

利用過去的成本資訊開發出來的模型，這些成
本資訊是與專案成本有關的軟體度量指標
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 24
專家判斷



諮詢多位對提案使用之軟體開發技術以及應用
領域熟悉的多位專家
有利條件：可以得到非常正確的預估
不利條件：沒有專家的判斷可能會造成非常不
正確的預估
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 25
類推預估



適用於同一應用領域或已經有其他專案完成時
有利條件：可用參考性資料
不利條件：無法完全利用於整個專案。必預有
計畫的來調整預估
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 26
Parkinson`s 法則



成本是由可用資源來決定，而非對目標的評估
有利條件：不會超支
不利條件：系統通常尚未完成
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 27
價格取勝



專案價格以客戶的預算來預估
有利條件： 得到合約
不利條件： 客戶可能所得到的系統比他們所
預想的還小。且成本也無法正確跟工作量成正
比
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 28
由上而下及由下而上預估


任何方式都可以用由上而下或由下而上的預估
由上而下
• 由系統層次開始，預估者先檢驗整體的產品功能以及這些
功能如何由子功能的互動提供

由下而上
• 系統分解成數個元件，所以先計算開發這些元件所需的工
作量
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 29
由上而下預估



使用範圍以外的系統架構知識和將系統分為幾
個部份來預估
成本的考量如整合、組態管理及文件
無法評估低階層技術問題
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 30
由下而上預估



使用本身系統所知架構和元件來預估
針對詳細系統設計上的是一個準確預估的好方
法
無法評估系統面的問題如整合性及文件
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 31
預估方式





每個方式都有優點及缺點
預估方式應該由數種方式當基礎
如果成本預估和結果做比較沒有相同的結果，
代表你的資訊還不足
重複計算成本的流程直到結果趨於相同為止
價格取勝有時也是唯一可用的方法
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 32
有經驗的預估


預估的方式主要依靠有經驗的基礎
新的方式及技術影響，下列這些變更可能會影
響成本的預估
•
•
•
•
•
使用物件導向開發
使用主從式架構
使用商用現成軟體的元件
使用再利用式開發
使用CASE工具和程式產生器
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 33
價格取勝




這種方法可能是不合理的成本估算
當你缺乏詳細資訊，這種方式或許是你唯一的
手段
成本是以客戶可投入在該專案發展的任何資源
來預估
工作量是以客戶的預算來預估，而非軟體的功
能
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 34
演算式成本模型

透過分析已完成專案的成本與特性可以建立出
演算式成本模型
• Effort ＝ A × SizeB × M
• A為固定因素，依據組織本身而定，指數B大型專案所需成
本呈現不均衡狀態 M由不同的流程、產品和發展特性結合
而成


大部份一般產品預估都是利用程式碼的多寡
大部份的模型都算式都基本上類只是差異在數
值A，B 和 M
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 35
準確預估


預估的正確性會根據完成的系統資訊而定
幾種因素會影響最後所完成的系統的大小
• 元件的使用
• 程式語法
• 分散式系統

軟體程序持續進行，有愈多的可用資訊出現時
，預估的準確性就愈高
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 36
不確定的預估
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 37
COCOMO模型




一個以經驗為主的模型
文件資料（independent） 模型，而非依附特
定軟體廠商
歷史悠久最早出現1981(COCOMO-81)到現在的
COCOMO 2
COCOMO 2 考慮不同的系統發展及可用性
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 38
COCOMO 81
專案複雜度
方程式
說明
簡單
PM = 2.4 (KDSI)1.05 ×M
由小型團隊所開發的且容易理解的應
用程式。
適度的
PM = 3.0 (KDSI)1.12 ×M
比較複雜的專案，開發成員可能對此
系統只有少許的經驗
內嵌的
PM = 3.6 (KDSI)1.20 ×M
複雜的專案，軟體是一個包含硬體、
軟體、規則以及作業程序所組成且具
有複雜強偶合關係的系統其中一部分
。
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 39
COCOMO 2 階段


COCOMO 2 一個三階段的模型。而程序剛開始時就
預估，而在系統結構完成後再做更詳細的預估。
初期雛形階段（early prototyping level）：
• 軟體大小的預估是依照物件點數和簡單的大小／生產力公式來
預估所需的工作量

初期設計階段（early design level）：
• 它的預估是依照功能點數為主，然後再將這些點數轉換成程式
碼行數。

後架構階段（post-architecture level）：
• 預做完成後的程式碼
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 40
初期雛形階段




主要是用來支援使用雛形法的專案，以及使用
組合現存元件方式開發的專案
是以一個預估的加權物件點數為主再將它除以
預估生產力的標準估算
根據開發者的經驗、能力以及使用CASE工具的
能力而定
公式
• PM = ( NOP ´ (1 - %reuse/100 ) ) / PROD
• PM為以人月（person-months）計的工作量，NOP為物件點
數 （ Number of Object Point ） ， PROD 為 生 產 力 （
productivity）
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 41
物件點數的生產力
開發者的經驗與能力
Very low Low
Nominal High
Very high
ICASE成熟度與能力
Very low Low
Nominal High
Very high
PROD (NOP/month)
4
13
50
©Ian Sommerville 2000
8
Software Engineering, 6th edition. Chapter 23
25
Slide 42
初期設計階段


認同的預估
標準的演算式模型做為預估的標準
• 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表示隨專案規模擴大所增加的工作量
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 43
乘數因子M

乘數因子M則是取自專案及流程的七種重要因
素
•
•
•
•
•
•
•

RCPX
RUSE
PDIF
PREX
PERS
SCED
FCIL
-產品可靠度與複雜度
-再利用需求
-平台困難度
-個人能力
-個人經驗
-時程
-支援設備
PMm是在程式碼有很大的百分比是自動產生時
使用的因子
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 44
後架構階段


使用初期設計公式
大小的調整預估
• 需求的易變性。依需求做改變
• 再利用的可能程度。大量重複使用表示必須修改真正由人為開
發的程式碼行數
• ESLOC = ASLOC × (AA + SU +0.4DM + 0.3CM +0.3IM)/100
» ESLOC為新的程式碼行數，ASLOC為必須修正的可再利用之程式碼
行數，DM為被修改的設計百分比，CM為被修改的程式碼百分比，
IM則為整合再利用軟體所需的原始整合工作量。
» SU是指瞭解軟體的所需成本，範圍可以從50到10。AA則是決定軟
體是否使用再利用元件的初始評估成本，根據需要測試與評估的
量，它的數值範圍可以從0到0.8。
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 45
計算指數


五種因素的評估值加總後除以100，再加上
1.01就是需要指數項。
範例
•
•
•
•
•

可循前例程度 – 新專案 – ４
開發彈性 -客戶未涉入 – Very High - 1
架構/風險分析程度 – 未做風險分析 - V. Low - 5
團隊向心力 – 新團隊 - nominal - 3
流程成熟度 –有些流程控制適當 - nominal - 3
最終的指數為1.17
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 46
指數計算調整因素
調整因素
說明
可循前例程度
反應組織在此類型的專案方面之前的經驗。Very low表示毫無任何經驗；Extra
high表示組織完全熟悉這個應用領域。
開發彈性
反應開發流程中彈性程度。Very low表示使用規定的流程；Extra high表示客戶只
設定一般的目的。
架構/風險分析程度
反應執行風險分析的程度。Very low表示只有少許分析；Extra high表示完整且徹
底的風險分析。
團隊向心力
反應開發團隊彼此了解與相互合作的程度。Very low表示互動困難； Extra high
表示有效率的整合團隊，完全無溝通上的任何問題。
流程成熟度
反應組織的流程成熟度。這個值是根據CMM成熟度問卷計算而來，但是預估值可
以從CMM流程成熟度減五得到。
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 47
相關指數

產品特性
• 正在開發的軟體產品所需的特色

電腦特性
• 由硬體平台加諸於軟體的限制

個人特性
• 將個人工作經驗及能力列入考慮的乘數因子

專案特性
• 與軟體開發專案相關的某些特色。
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 48
專案的成本動因
產品特性
RELX
所需系統可靠度
DATA
使用資料庫的大小
CPLX
系統模組複雜度
RUSE
所需可再利用元件的百分比
DOCU
所需文件程度
STOR
記憶體限制
電腦特性
TIME
執行時間的限制
PVOL
開發平台的變異性
個人特性
ACAP
專案分析能力
PCAP
程式設計師能力
PCON
個人連續性
AEXP
專案領域的分析師經驗
PEXP
程式設計師專案領域的經驗
LTEX
語言和工具經驗
TOOL
軟體工具的使用
SITE
多重地點的工作與溝通品質的程度
SCED
開發時程壓縮
專案特性
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 49
成本動因對投入預估的影響
指數值
系統大小（包括再利用與需求易變的因素）
不包含成本動因的初始COCOMO預估
1.17
128,000DSI
730 人月
可靠度
複雜度
記憶體限制
工具使用
時程
調整後的COCOMO預估
Very high，乘數因子 = 1.39
Very high，乘數因子 = 1.3
High，乘數因子 = 1.21
Low，乘數因子 = 1.12
加速，乘數因子 = 1.29
2306 人月
可靠度
複雜度
記憶體限制
工具使用
時程
調整後的COCOMO預估
Very low，乘數因子 = 0.75
Very low，乘數因子 = 0.75
None，乘數因子 = 1
Very high，乘數因子 = 0.72
Normal，乘數因子 = 1
295 人月
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 50
專案計畫


演算式成本模型提供基本的專案計畫
太空梭內嵌式系統
• 可用性
• 最輕重量(晶片數量)
• 電腦限制和可靠度為主的乘數因子必定> 1

成本單元
• 目標硬體成本
• 開發系統的平台成本
• 開發軟體的所需投入的工作量成本
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 51
管理項目
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 52
管理選項成本
選項
RELY
STOR
TIME
TOOLS
LTEX
總工作量
軟體成本
硬體成本
總成本
A
1.39
1.06
1.11
0.86
1
63
949,393
100,000
1,049,393
B
1.39
1
1
1.12
1.12
88
1,313,550
120,000
1,402,025
C
1.39
1
1.11
0.86
1
60
895,653
105,000
1,000,653
D
1.39
1.06
1.11
0.86
0.84
51
769,008
100,000
897,490
E
1.39
1
1
0.72
1.22
56
844,425
220,000
1,044,159
F
1.39
1
1
1.12
0.84
57
851,180
120,000
1,002,706
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 53
選項選擇

選項D的所有基本成本預估都是最低的
• 必須從內部尋找人才若不可行，則必須從外部招聘，但需
要更多的成本及風險


選項C (昇級記憶體)沒有太大風險
所有的選項在一個系統發展中都顯示出不同的
經驗
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 54
專案持續時間和人員


專案經理還必須預估完成軟體開發所需的時間
和何時需要工作人員加入
使用COCOMO 2公式來預估專案時程
• TDEV = 3 × (PM)(0.33+0.2*(B-1.01))
• PM為工作量計算，B為之前討論的指數（初始雛形模型的B
為1）。這個計算可以預估專案的正常時程

專案人數會影響專案時程
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 55
人員需求



人員需求並不能計算出專案時程
軟體專案工作人數從少量增加到巔峰後再減少
非常急速增加專案成員通常和專案時程減少有
關
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 56
重點整理



影響生產力的因素包括個人態度（主要因素）
、應用領域經驗、開發流程、專案規模、支援
工具以及工作環境。
軟體成本預估有許多不同技術。在準備預估時
，應該多用一些技術。若預估值出現很大的差
異，表示沒有足夠的資訊提供做為預。
軟體的報價通常會以取得合約為主，因此系統
的功能通常需要經過調整，以符合預估的價格
。
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 57
重點整理




演算式的成本模型它必須依賴過去完成產品的一些特性
做成本的預估，在專案初期這些特性是不可能正確的預
估。
COCOMO成本預估模型是一個發展完全的模型，在建立成
本預估公式時它將專案、產品、硬體以及個人特性都列
入考慮。
演算式成本模型對管理非常有價值，因為支援量化的選
項分析，允許計算不同選項的成本這些選項還是可以用
客觀的標準做比較。
完成專案的所需時間與參與專案的工作人員數量不是成
簡單的正比關係；加入愈多的工作人員，可能會讓完成
時間愈長。
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 23
Slide 58