雖然估算是一門科學，更是一門藝術(shù)，這個重要的活動不能以隨意的方式來進行……因為估算是所有其他項目計劃活動的基礎(chǔ)，而項目計劃又提供了通往成功
的軟件工程的道路圖，所以，沒有它我們就會搭錯車。——Roger S. Pressman 《軟件工程——實踐者的研究方法》
1、估算前的規(guī)劃
當我們的辦公室內(nèi)堆滿了雜亂無章的文件時，恐怕無法知道對于我們真正有用的文件在哪里，當我們的軟件相目中收集了各種需求、意見、問題時，我們
也很難從中估算出整個項目的規(guī)模、工作量以及成本。因此，在估算之前我們首先要對眾多信息進行整理、歸類分析，從而得到一個條理清晰的項目計劃，在這個計
劃提供的框架內(nèi)，才可能開始正確的估算。精心的規(guī)劃是任何一個軟件開發(fā)項目成功與否的關(guān)鍵，有了規(guī)劃就有如成竹在胸，之后無論風云變幻，都有應對入流的方
法。當然只有正確的規(guī)劃，才能給軟件開發(fā)指引正確的方向。
軟件項目規(guī)劃的重點是對人員角色、任務進度、經(jīng)費、設(shè)備資源、工作成果等等做出合適的安排，制定出一些計劃(包括高層的和細節(jié)的)，使大家按照計劃行事，最終順利地達到預定的目標。blog.mypm.net
1.1、規(guī)劃的第一步：確定軟件范圍
確定軟件范圍，就是確定目標軟件的數(shù)據(jù)和控制、功能、性能、約束、接口以及可靠性。這項工作和需求分析是很類似的，如果之前已經(jīng)達成需求分析規(guī)
約，那么可以直接從《需求分析說明書》中把有用的部分拿來使用。如果還沒有開始需求分析，關(guān)于確定軟件范圍的方法方面，我們可以采用許多需求分析技術(shù)(如
需求誘導)，從客戶那里得到一個具體的軟件范圍。當然如果是一次全新的軟件邊界探索，就應當考慮軟件本身可行性問題，包括團隊是否具備在技術(shù)、財務、時
間、資源上游可靠的保障，軟件本身在市場上是否有可靠的競爭優(yōu)勢 ，等等。
獲得軟件范圍，最直接最可靠的來源就是用戶對軟件的需求描述。例如，在開發(fā)一個C/S架構(gòu)的鐵路供電段數(shù)據(jù)上報系統(tǒng)中，客戶向我們提供了以下的目標軟件需求描述：
在供電站總部每天結(jié)束前要審核下屬節(jié)點操作員(30~40個)的供電安全數(shù)據(jù)報表，要求每個節(jié)點必須在下午5：30~6：00之間上傳數(shù)據(jù)。總
部系統(tǒng)通過自動分析，整理出整個區(qū)內(nèi)的安全形勢報表，并自動反饋到每個節(jié)點。各個節(jié)點之間通過調(diào)制解調(diào)器撥號(MODEM)用內(nèi)部電話線相連，每個節(jié)點電
腦主機配備一個MODEM。上傳數(shù)據(jù)為制式報表出了制式信息外，系統(tǒng)自動附加操作員姓名、上報時間、上報節(jié)點名稱。信息一旦上傳，節(jié)點端就不可以對已提交
信息進行修改、刪除，只能閱讀、查詢。節(jié)點間數(shù)據(jù)互相隔離，只有總部才具備對各個節(jié)點數(shù)據(jù)的管理權(quán)限，但是對于歸檔數(shù)據(jù)(一旦審核完畢的數(shù)據(jù)，就進行歸
檔)總部不具備刪改的權(quán)限。系統(tǒng)設(shè)置數(shù)據(jù)庫管理員，獨立于審核權(quán)限，其職責是對歷史數(shù)據(jù)的清理維護。項目經(jīng)理圈子
通過上面的描述，我們通過提煉和簡化，得到軟件的一下功能：
◆ 節(jié)點數(shù)據(jù)錄入、查詢、上傳
◆ 總部數(shù)據(jù)匯總、查詢、反饋
◆ 總部與節(jié)點的互聯(lián)
◆ 總部數(shù)據(jù)庫存儲
◆ 節(jié)點數(shù)據(jù)的本地存儲項目管理者聯(lián)盟文章
在本例中，軟件的性能是潛在的。客戶雖然沒有明確提出，但是由于數(shù)據(jù)本身的重要性，要求系統(tǒng)在數(shù)據(jù)上傳、反饋、存儲過程中安全可靠。客戶要求使
用MODEM進行撥號連接，那么鑒于MODEM連接過程中可能會出現(xiàn)，由于撥號斷開而道導致的數(shù)據(jù)丟失，在節(jié)點本地存放一份數(shù)據(jù)副本是有必要的。由于系統(tǒng)
要求每天上傳數(shù)據(jù)，總部數(shù)據(jù)庫應當是7X24小時不間斷服務的，再加上目前總部只有該系統(tǒng)運行接受數(shù)據(jù)任務，各節(jié)點數(shù)據(jù)量并不大，那么在建議用戶選擇服務
器時，應當考慮性能穩(wěn)定可靠，但并不一定要購買大容量磁盤陣列和高性能雙CPU主機。由于每天上傳數(shù)據(jù)接近下班時間，那么總部匯總數(shù)據(jù)應當是自動進行的，
一旦分析發(fā)現(xiàn)重大問題，可以通過與外部網(wǎng)絡(luò)的設(shè)置，向值班人員發(fā)送手機訊息、E-MAIL或其他警示。由于不同人員對于上報數(shù)據(jù)的權(quán)限不同，對于系統(tǒng)用戶
實行分級管理。不同級別的用戶，具有對數(shù)據(jù)的不同管理權(quán)力，從而保證在軟件使用過程中不發(fā)生混亂。
那么現(xiàn)在一個較為清晰的軟件模型已經(jīng)構(gòu)造完畢，接下來我們需要進入計劃的第二步：確定工作所需資源。
1.2、規(guī)劃的第二步：確定工作所需資源
軟件工作所需資源包括：工作環(huán)境(軟硬件環(huán)境、辦公室環(huán)境)、可復用軟件資源(構(gòu)件、中間件)、人力資源(包括不同各種角色的人員：分析師、設(shè)
計師、測試師、程序員、項目經(jīng)理……)。這三種資源的組成比例，可以看作一個金字塔的模式，最上面是人力資源、其次是可復用軟件資源、最下面是工作環(huán)境。
最上面的是組成比例最小的，最下面的是組成比例最大的部分。
■ 人力資源
一個項目到底需要多少種職務的人員構(gòu)成、多少數(shù)量的人員總量，再能成為最有創(chuàng)造力的團隊呢?這恐怕是最讓項目經(jīng)理頭疼的事情了。任何一個軟件工
程，都必須在確定軟件的工作量之后，才能清楚地知道究竟需要多少人力才能以最小成本和最高效率完成任務。在這之前，不能盲目地進行人力擴充，而且絕對不能
為了給公司抬高門面，盲目招收高學歷。
■ 可復用軟件資源
這是一個容易在計劃階段被忽視的重要資源，很多人總是進入編碼階段才發(fā)現(xiàn)可復用資源的價值和存在。經(jīng)過長期的項目積累或是購買，公司的軟件資源
庫中或許已經(jīng)積累了大量的可復用資源，但在當前任務中，只能選擇有價值的資源。根據(jù)不同的應用、時間、來源，可復用軟件資源被分為以下幾種：
可直接使用的構(gòu)件：已有的，能夠從第三方廠商獲得或已經(jīng)在以前的項目中開發(fā)過的軟件。這些構(gòu)件已經(jīng)經(jīng)過驗證及確認且可以直接用在當前的項目中。
具有完全經(jīng)驗的構(gòu)件：已有的為以前類似于當前要開發(fā)的項目建立的規(guī)約、設(shè)計、代碼、或測試數(shù)據(jù)。當前軟件項目組的成員在這些構(gòu)件所代表的應用領(lǐng)域中具有豐富的經(jīng)驗。因此，對于這類構(gòu)件進行所需的修改其風險相對較小。
具有部分經(jīng)驗的構(gòu)件：已有的為以前與當前要開發(fā)的項目相關(guān)的項目建立的規(guī)約、設(shè)計、代碼、或測試數(shù)據(jù)，但需做實質(zhì)上的修改。當前軟件項目組的成員在這些構(gòu)件所代表的應用領(lǐng)域中僅有有限的經(jīng)驗，因此，對于這類構(gòu)件進行所需的修改會有相當程度的風險。
新構(gòu)件：軟件項目組為滿足當前項目的特定需要而必須專門開發(fā)的軟件構(gòu)件。training.mypm.net
在采用構(gòu)件的時候，應當以低成本、低風險為使用前提。如果任何一個漂亮的構(gòu)件的應用，可能會帶來潛在出錯的風險或者必須經(jīng)過復雜修改或者效率低
下時，我們都應當毫不猶豫地把它拋棄。我們只采用那些能夠滿足項目的需要且可直接使用的構(gòu)件，或者具有完全經(jīng)驗的構(gòu)件，或者經(jīng)過稍微修改便可使用的構(gòu)件。
■ 環(huán)境資源
“工欲善其事，必先利其器”，要得到高效的開發(fā)過程，就必須向工作人員提供良好的軟硬件環(huán)境，包括開發(fā)工具、開發(fā)設(shè)備、工作環(huán)境、管理制度。一般管理人員都會購買可以滿足需要的軟件開發(fā)工具和硬件平臺，但是工作環(huán)境和管理制度往往被忽視。
站在人件的角度看，向工作人員提供更輕松自在、安靜舒適的辦公環(huán)境的公司員工往往比整天在狹小隔間中工作的公司員工，產(chǎn)生更高的工作效率。而那
些擁有靈活人性化的管理制度的公司，比整天加班的公司更能留住高技術(shù)的人才。所以如何在有限資金中，規(guī)劃一個合理的環(huán)境是很重要的事情。
到此為止，估算前的項目計劃已經(jīng)完成，我們已經(jīng)形成一個工程開發(fā)框架。這是一個有界限的框架，雖然還不夠精確，但足以進行估算的工作。
2、估算的對象
目前為止，一個較為準確的軟件項目估算的定義是：在給定公差范圍內(nèi)，對于姚開發(fā)的軟件規(guī)模的預測，以及對開發(fā)軟件所需的工作量、成本和日歷事件的預測。這個概念指出了一個事實，即估算是一種大約的估計，是將誤差限定在一定范圍內(nèi)的估計。
估算主要包括以下幾個重要內(nèi)容：項目管理者聯(lián)盟
◆ 規(guī)模估算
軟件估算首先要將整個工程的規(guī)模估算出來，才能進行下面的其他估算。規(guī)模，就是一個工程可量化的結(jié)果，是用具體數(shù)字來體現(xiàn)項目的描述。規(guī)模估算的信息來源是清晰、有界限的用戶需求。
◆ 工作量估算
這是對開發(fā)軟件所需的工作時間的估算，它和進度估算一起決定了開發(fā)團隊的規(guī)模和構(gòu)建。通常以人時、人天、人月、人年的單位來衡量，這些不同單位之間可以進行合理的轉(zhuǎn)換。blog.mypm.net
◆ 進度估算
進度時項目自始至終之間的一個時間段。進度以不同階段的里程碑作為標志。進度估算是針對以階段為單位的估算，而不是對每一個細小任務都加以估算，對任務的適當分解很重要，分解得越細反而會不準確。因為任何一個軟件工程，在各個方面都有與生俱來的不確定性。
◆ 成本估算
包括人力、物質(zhì)、有形的、無形的支出成本估算，其中以人力成本為主要部分。比較容易被忽視的使學習成本、軟件培訓成本、人員變動風險成本、開發(fā)延期成本等，一些潛在成本消耗。轉(zhuǎn)自項目管理者聯(lián)盟
3、估算的策略
在軟件估算的眾多方法中，存在著“自頂向下”和“自底向上”兩種不同的策略，兩種策略的出發(fā)點不同，適應于不同的場合使用。項目管理培訓
3.1、自頂向下的策略
這是一種站在客戶的角度來看問題的策略。它總是以客戶的要求為最高目標，任何估算結(jié)果都必須符合這個目標。其工作方法是，由項目經(jīng)理為主的一個核心小組根據(jù)客戶的要求，確定一個時間期限，然后根據(jù)這個期限，將任務分解，將開發(fā)工作進行對號入座，以獲得一個估算結(jié)果。
當然由于這完全是從客戶要求出發(fā)的策略，而由于軟件工程是一個綜合項目，幾乎沒有哪個項目能完全保質(zhì)保量按照預定工期完工，那么這樣一個策略就
缺少了許多客觀性。但是由于這樣完成的估算比較容易被客戶、甚至被項目經(jīng)理所接受，在許多公司我們看到這樣一個并不科學的策略仍然被堅定地執(zhí)行著。
3.2、自底向上的策略
與自頂向下的策略完全相反，自底向上的策略是一種從技術(shù)、人性的角度出發(fā)看問題的策略。在這樣一個策略指引下，將項目充分討論得到一個合理的任
務分解。在將每個任務的難易程度，每個任務依照項目成員的特點、興趣特長進行分配，并要求進行估算。最后將估算加起來就是項目的估算值。
顯然自底向上的這種策略具有較為客觀的特點，但是它的缺點就是這樣一來項目工期就和客戶的要求不一致了。而且由于其帶來的不確定性，許多項目經(jīng)理也不會采用這種方法。
4、估算的方法
顯然估算是建立在客觀實際上，對未來盡可能合理的一種預測。那么估算本身的不確定性，決定了它不可能是百分之百準確無誤的。在項目剛開始時，人
們對產(chǎn)品需求、技術(shù)、市場預期、人員素質(zhì)等因素的了解還遠遠不夠，在這種情況下人們很難作出準確的估計。但是依據(jù)某種方法進行估計顯然比瞎猜好得多。
估算方法有很多，大致分為基于分解的技術(shù)和基于經(jīng)驗模型兩大類。基于分解的技術(shù)的方法包括功能點估算法、LOC估算法、MARK II等;基于經(jīng)驗模型的方法包括IBM模型、普特南模型、COCOMO模型等。
4.1、FP功能點估算法
功能點估算法是一種在需求分析階段基于系統(tǒng)功能的一種規(guī)模估計方法。通過研究初始應用需求來確定各種輸入、輸出、計算和數(shù)據(jù)庫需求的數(shù)量和特
性。這種方法的計算公式是：功能點=信息處理規(guī)模x技術(shù)復雜度。信息處理規(guī)模包括各種輸入、輸出、查詢、內(nèi)部邏輯文件數(shù)、外部接口文件數(shù)等等;技術(shù)復雜度
包括性能復雜度、配置項目復雜度、數(shù)據(jù)通信復雜度、分布式處理復雜度、在線更新復雜度等等。
4.2、LOC估算法
這是一種從技術(shù)的角度來估算的方法總稱，其中又包含許多方法。這類方法以代碼(LOC)作為軟件工作量的估算單位，在早期的系統(tǒng)開發(fā)中較為廣泛
使用。基于LOC的估算，又有點也有缺點。優(yōu)點在于方便計算、容易監(jiān)控、能反映程序員的思維能力;缺點在于代碼行數(shù)的含糊不清，不能正確反映一項工作的難
易程度以及代碼的效率。因此在傳統(tǒng)的LOC方法進行了許多改進。其中不斷被使用，且不斷演化的方法包括以下：www.mypm.net
PERT功能點估算法：PERT對各個項目活動的完成時間按三種不同情況估計：一個產(chǎn)品的期望規(guī)模，一個最低可能估計，一個最高可能估計。用這三個估計用來得到一個產(chǎn)品期望規(guī)模和標準偏差的Pert 統(tǒng)計估計，Pert 估計可得到代碼行的期望值和標準偏差SD。
類比估算法：類比法適合評估一些與歷史項目在應用領(lǐng)域、環(huán)境和復雜度的相似的項目，通過新項目與歷史項目的比較得到規(guī)模估計。類比法估計結(jié)果的
精確度取決于歷史項目數(shù)據(jù)的完整性和準確度，因此，用好類比法的前提條件之一是組織建立起較好的項目后評價與分析機制，對歷史項目的數(shù)據(jù)分析是可信賴的。項目管理者聯(lián)盟
Delphi估算法：Delphi法是一種專家評估技術(shù)，在沒有歷史數(shù)據(jù)的情況下，這種方式適用于評定過去與將來，新技術(shù)與特定程序之間的差別。對于需要預測和深度分析的領(lǐng)域，依賴于專家的技術(shù)指導，可以獲得較為客觀的估算。通過專家們的互相討論，還可以博取眾長。
系統(tǒng)分解：將系統(tǒng)分成若干個易于用LOC估算的部分，將其各個估算結(jié)果累加就是LOC的總規(guī)模。其中關(guān)鍵是建立起SBS(系統(tǒng)分解結(jié)構(gòu))，它描述了
系統(tǒng)的不同組件。SBS還被使用在其他重要的地方，如系統(tǒng)設(shè)計、系統(tǒng)分析等。在進行分解的時候，可以采用自由討論的形式，可以獲得更合理的SBS構(gòu)成。
4.3、IBM模型估算法
該模型是Watson和Felix在1977年發(fā)布的，是基于IBM聯(lián)合系統(tǒng)分布負責的60個項目的總結(jié)而得到的模型。該模型是一個靜態(tài)模型，而參考數(shù)據(jù)只有60多個項目，因此有很大的局限性。項目經(jīng)理圈子
4.4、COCOMO估算法
Boehm在其經(jīng)典著作“軟件工程經(jīng)濟學”(software engineering
conomics)中，介紹了一種軟件估算模型的層次體系， 稱為COCOMO(構(gòu)造性成本模型，COnstructive COst
MOdel)，它代表了軟件估算的一個綜合經(jīng)驗模型。
COCOMO
模型是適用于三種類型的軟件項目：(1)組織模式——較小的、簡單的軟件項目，有良好應用經(jīng)驗的小型項目組，針對一組不是很嚴格的需求開展工作(如，為一
個熱傳輸系統(tǒng)開發(fā)的熱分析程序);(2)半分離模式——一個中等的軟件項目(在規(guī)模和復雜性上)，具有不同經(jīng)驗水平的項目組必須滿足嚴格的及不嚴格的需求
(如，一個事務處理系統(tǒng)，對于終端硬件和數(shù)據(jù)庫軟件有確定需求);(3)嵌入模式——必須在一組嚴格的硬件、軟件及操作約束下開發(fā)的軟件項目(如，飛機的
航空控制系統(tǒng))。項目管理培訓
4.5、軟件方程式估算法
軟件方程式是一個多變量模型，它假設(shè)在軟件開發(fā)項目的整個生命周期中的一個特定的工作量分布。該模型是從4000
多個當代的軟件項目中收集的生產(chǎn)率數(shù)據(jù)中導出的公式。初期的方程式較為復雜，通過，Putnam
和Myers的努力又提出一組簡化的方程式。當然這種方法也是基于長期的參考數(shù)據(jù)的積累而得到的。
4.6、WBS估算法
這是一種基于WBS(工作任務分解)的方法，即先把項目任務進行合理的細分，分到可以確認的程度，如某種材料，某種設(shè)備，某一活動單元等。然后估算每個WBS要素的費用。采用這一方法的前提條件或先決步驟是：
對項目需求作出一個完整的限定。blog.mypm.net
制定完成任務所必需的邏輯步驟。
編制WBS表。
項目需求的完整限定應包括工作報告書、規(guī)格書以及總進度表。工作報告書是指實施項目所需的各項工作的敘述性說明，它應確認必須達到的目標。如果
有資金等限制，該信息也應包括在內(nèi)。規(guī)格書是對工時、設(shè)備以及材料標價的根據(jù)。它應該能使項目人員和用戶了解工時、設(shè)備以及材料估價的依據(jù)。總進度表應明
確項目實施的主要階段和分界點，其中應包括長期定貨、原型試驗、設(shè)計評審會議以及其他任何關(guān)鍵的決策點。如果可能，用來指導成本估算的總進度表應含有項目
開始和結(jié)束的日歷時間。
除了以上介紹的幾種方法外，還有一些其他的方法：類比估算、推測估算、Standard-component估算法、普特南估算法等。當然不同
的方法適用于不同的具體環(huán)境，有些方法雖然很好但并不一定適合當前的任務。只有量體裁衣，具體問題具體分析，才能得到盡量合理的估算。
5、估算的戒律
記住：應該滿足于事物的本性所能容許的精確度，當只能近似于真理時，不要去尋求絕對的準確?? ——亞里斯多德
對于任何一個項目經(jīng)理，都知道要慎重估算，但是我們?nèi)匀粫吹饺肆Y源的浪費和財力資源的匱乏，在許多項目中存在。對于寶貴的資源，我們不是用得太多，就是根本不夠用。因此，有以下前人總結(jié)出來的一些經(jīng)驗以供借鑒。項目經(jīng)理圈子
不要追求完美：就像沒有人能預測出未來，如果還沒有完成，就不要企圖完美的結(jié)果。更何況估算的太精確，反而會失去靈活機動的空間。
不要為滿足預算而估算：如果這個項目的預算根本不能完成100%的任務，那么就不要讓你的團隊委曲求全。正確地反映客觀現(xiàn)狀，不僅可以爭取應得的權(quán)利，而且是完成任務的前提。
不要隨意削減估算結(jié)果：有很多老板喜歡把項目經(jīng)理遞交的估算，不假思索地砍掉一部分。這是一種不負責任的做法，如果要削減一定要有理由。項目管理培訓
客觀地估算，不貪多不偷減：就像老板不能隨便削減你的估算一樣，你也同樣不能在估算的時候，貪多或是偷減。貪多必然導致會浪費，偷減必然導致不足。這兩個結(jié)果恐怕都不是一個合格的項目經(jīng)理的作為。
客觀利用過去的經(jīng)驗：對于以往估算的經(jīng)驗，當然是寶貴的財富，但是如果財富用錯了地方就會變成垃圾。在使用經(jīng)驗時，要注意現(xiàn)在和參考經(jīng)驗之間的差異。不要忘記，隨著時間的推移，計算機領(lǐng)域技術(shù)的更新，許多觀念都在發(fā)生著改變。
不要以客戶目標作為估算的結(jié)果：客戶是上帝，軟件公司一定要盡力實現(xiàn)客戶的需求。但我們要實現(xiàn)的是合理的目標，況且不能為了完成目標而去堆積數(shù)字，這樣豈不是因果倒置了。
不要隱匿不確定的成本：軟件開發(fā)中存在潛在風險，是很正常的事情。現(xiàn)在風險就會帶來潛在的成本，如：突然一位程序員離職，導致工作進度路落后。我們不可能估算到任何一種可能發(fā)生的情況，但有責任把可能出現(xiàn)的一些關(guān)鍵環(huán)節(jié)列出來。