專案成本控管
專案成本控管包括了成本的估算與執行成本的管理這兩個層面。
成本的估算
（プロジェクト・コスト見積り）
一般是在備標階段會採用「概略預估」的方式，等到成案後再採用「詳細預估」的方式。不過備標階段通常就已經是決定勝負的時機，成本估算是否準確，也是一個相當重要的成敗因素。因此相較之下，在備標階段是否擁有能夠以較少的資訊來進行概略預估的能力，會比是否擁有詳細預估的能力更為重要。
具代表性的估算方法
估算方法
|
說明
|
1.累計功能法
又名由下而上估算法
|
Bottom-Up Estimating
ボトムアップ見積法
PMBOK ® Guide推薦的方法之一。
是一種分別估算每項作業，然後再將其合計後得到整體成本的估算方法。
利用WBS拆出Work Package，然後估算出每個工作包的工時，然後再進行合計。所以WBS的正確性會決定估算值的精確度。WBS若能被正確細分的話，估算的精確度會比其他方法高。
估算每個功能項目的個別工時後，再累計得到整體開發時間。計算每個功能項目所需要的訪談、分析、設計、開發、測試，及文件製作的時間，再加上整合測試、壓力測試等整體性的工作，來估算開發工時。
一般來說這種方式也會有工時估算大於實際的傾向，可以根據經驗再進行適度的調整，並預留一定的緩衝時間，調整完成的結果就是最終所預估的開發工時。
|
2.類比估算法
|
Analogous Estimating
類推見積法
PMBOK ® Guide推薦的方法之一。
參考過去類似專案的實績值（範疇、成本、預算及期程）來估算現行專案成本的一種方法。在參考內容相似性高的情況，或是估算者專業性高的情況下，這方法的信賴度就會較高。不過一般來說，估算的精確度比較低。
用過去所開發類似的系統做為基礎來進行估算的這種方式，也是KKD法的一種。所謂的KKD（「勘、経験、度胸」）法，這是在日本頗為流行的一種以直覺、經驗、膽識來進行估算的一種方法。
在專案的初期階段，缺乏充分資訊與時間緊迫的情況下，讓有經驗的負責人以過去的經驗和直覺為基礎，用他主觀的想法來進行工時的估算。
有時在估算時會使用排程表作為輔助，在交付期限內進行工作項目的選擇與工時的配置，再檢視規劃內容的妥善性與合理性，所以也可以稱為排程表估算法
|
3.參數估算法
|
Parametric Estimating
PMBOK ® Guide推薦的方法之一。
利用統計而來的歷史資料與其他變數來估算成本、預算、工期。這種方法可以產出高精確度的估算值，可以用來估算整個專案或部分專案，並可與其他估算方式結合一併使用。參數估算法的特點是能夠很容易的讓使用者理解，而且估算方式跟程式語言脫勾，因此不受特定程式語言的影響。
|
3-1.功能點數計算法
|
Function Point
ファンクションポイント法
參數估算法的一種，是一種從軟體功能數量與複雜度來估算軟體規模的方法。
在每個功能乘上處理難易度來估算開發規模。將功能區分為資料功能與交易功能，前者包括內部邏輯檔案（IFL）及外部介面檔案（EIF），而後者包括外部輸入（EI）、外部輸出（EO），及外部參考（EQ）。
每種功能也可數個種等級（例如難中易），每種等級都有一個加權值，功能乘上生產標準值再累加後便可以得到FP值。將FP值除以生產性基準（換算基數），即可得到開發工時。加權值與生產性標準的精確度若不夠的話，會直接影響到估算的結果。
|
3-2.標準值法
|
參數估算法的一種。
以過去的開發經驗為基礎，計算出生產標準值，再評估並累計每個子系統的開發工時，也可以說是FP法的簡化版。
可將應用區分為「畫面輸入」「畫面參考」「表單輸出」「批次處理」四種（種類可視實際狀況增減），並區分為數種等級（例如難中易）。每種等級都有一個生產標準值，也就是完成工時，功能乘上生產標準值再累加後便可以得到總工時。
|
4.三點估算法
|
Three-Point Estimating
三点見積法
PMBOK ® Guide推薦的方法之一。
估算值是由以下三個項目分別計算而來：
1.樂觀值：在最佳條件下進行作業的估算值。
2.最可能值：在一般條件下進行作業的估算值。
3.悲觀值：在最差條件下進行作業的估算值。
三點估算值=(樂觀值+最可能值×4+悲觀值)÷6
|
5.COCOMO法
|
Constructive Cost Model
COCOMO法
考慮開發規模、難易度、開發特性等因子的預估模型，由生成應用、初期設計、後段架構三種模型所構成。
工時 = a × Sb
a跟b是由統計而來的常數，而S是表示軟體規模的指標。當初是使用在軟體程式的行數，但是因為分析與設計的估算有所困難，所以COCOMOⅡ又增加了軟體程式行數、Object Point與Function Point。
基本COCOMO適用於快速、早期地粗略估算軟體成本，但它沒有考慮如不同的硬體條件、人員素質及經驗、對現代工具與技術的使用，等其它會對軟體成本有深遠影響的項目屬性，所以它的準確程度有限。而中級COCOMO對軟體工作量的估算使用了程度大小以及一組「成本驅動者」，包括對產品、硬體、人員及項目屬性的客觀評價。
|
6.原始碼衡量法
|
Lines of Code
LOC法
舊時代的產物，也被稱為Program Step法，用程式的Step（行數）來估算開發規模與費用。特徵是若已有既有程式可參考，就可以很容易的進行估算。若是在沒有既有程式的情況下，也可以參考過去的開發案例，藉以推算出Step數以進行估算。至於開發語言、開發方法，以及程式設計師的能力都會影響到估算值。估算的精準度比Function Point或COCOMO來得低。
用專案產出的原始碼除以專案的全部人月，人月數包括系統分析、系統設計、程式撰寫、系統測試，與文件製作，以計算出估算標準。估算方式簡單且曾經被廣泛的使用，不過評量基準不夠客觀，而且不適用於物件導向與Web系統。
LOC也會被拿來與其他衡量指標結合，例如錯誤數、瑕疵數/KLOC(Thousand LOC)、費用/LOC，及文件頁數/KLOC。
|
PMBOK ® Guide推薦的估算法
PMBOK ® Guide除了累計功能法、類比估算法、參數估算法，以及三點估算法之外，還有推薦一種專家判斷法(Expert Judgment)。不過此方法因為太過於依賴專家的心證，因此個人並未採用。
標準值法與功能點數計算（FP）法的差異
FP法會先算出FP值求得開發規模，再乘上生產係數來計算開發工時。標準值法則不採用FP值指標，只要直接乘上各功能的生產標準值（完成工時），即可算出開發工時。
此外，在標準值法中是以畫面和表單作為估算的對象，而在FP法中資料應用所使用的檔案也是被估算的對象之一。
類比估算法+標準值法
一般來說標準值法的累計方式會有工時估算大於實際的傾向，所以可以使用工作排程方式檢查工作項目的規劃是否適當。而類比估算法因缺乏細部的系統功能項目，因此可搭配標準值法來進行系統功能開發工時的估算。
目前採用的作法
在備標階段使用由上而下的類比估算法搭配排程表的這種KKD方法，來快速的概估專案成本，等到得標後進入專案計畫書撰寫階段時（或是得到了更詳細的需求後），專案經理便會需要團隊來建立一個真正的預估值，從程式設計人員開始，由下而上用累計功能法再重新估算開發的工時，對工作描繪出更真實的預測數字。
沒有留言:
張貼留言