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