目組,針對一組不是很嚴格的需求開展工作(如,為一個熱傳輸系統(tǒng)開發(fā)的熱分析程序);(2)半分離模式——一個中等的軟件項目(在規(guī)模和復雜性上),具有不同經(jīng)驗水平的項目組必須滿足嚴格的及不嚴格的需求(如,一個事務處理系統(tǒng),對于終端硬件和數(shù)據(jù)庫軟件有確定需求);(3)嵌入模式——必須在一組嚴格的硬件、軟件及操作約束下開發(fā)的軟件項目(如,飛機的航空控制系統(tǒng))。
4.5、軟件方程式估算法
軟件方程式是一個多變量模型,它假設在軟件開發(fā)項目的整個生命周期中的一個特定的工作量分布。該模型是從4000 多個當代的軟件項目中收集的生產率數(shù)據(jù)中導出的公式。初期的方程式較為復雜,通過,Putnam 和Myers的努力又提出一組簡化的方程式。當然這種方法也是基于長期的參考數(shù)據(jù)的積累而得到的。
4.6、WBS估算法
這是一種基于WBS(工作任務分解)的方法,即先把項目任務進行合理的細分,分到可以確認的程度,如某種材料,某種設備,某一活動單元等。然后估算每個WBS要素的費用。采用這一方法的前提條件或先決步驟是:
對項目需求作出一個完整的限定。 制定完成任務所必需的邏輯步驟。 編制WBS表。
項目需求的完整限定應包括工作報告書、規(guī)格書以及總進度表。工作報告書是指實施項目所需的各項工作的敘述性說明,它應確認必須達到的目標。如果有資金等限制,該信息也應包括在內。規(guī)格書是對工時、設備以及材料標價的根據(jù)。它應該能使項目人員和用戶了解工時、設備以及材料估價的依據(jù)?傔M度表應明確項目實施的主要階段和分界點,其中應包括長期定貨、原型試驗、設計評審會議以及其他任何關鍵的決策點。如果可能,用來指導成本估算的總進度表應含有項目開始和結束的日歷時間。
除了以上介紹的幾種方法外,還有一些其他的方法:類比估算、推測估算、Standard-component估算法、普特南估算法等。當然不同的方法適用于不同的具體環(huán)境,有些方法雖然很好但并不一定適合當前的任務。只有量體裁衣,具體問題具體分析,才能得到盡量合理的估算。
5、估算的戒律
記。簯摑M足于事物的本性所能容許的精確度,當只能近似于真理時,不要去尋求絕對的準確?? ——亞里斯多德
對于任何一個項目經(jīng)理,都知道要慎重估算,但是我們仍然會看到人力資源的浪費和財力資源的匱乏,在許多項目中存在。對于寶貴的資源,我們不是用得太多,就是根本不夠用。因此,有以下前人總結出來的一些經(jīng)驗以供借鑒。
不要追求完美:就像沒有人能預測出未來,如果還沒有完成,就不要企圖完美的結果。更何況估算的太精確,反而會失去靈活機動的空間。
不要為滿足預算而估算:如果這個項目的預算根本不能完成100%的任務,那么就不要讓你的團隊委曲求全。正確地反映客觀現(xiàn)狀,不僅可以爭取應得的權利,而且是完成任務的前提。
不要隨意削減估算結果:有很多老板喜歡把項目經(jīng)理遞交的估算,不假思索地砍掉一部分。這是一種不負責任的做法,如果要削減一定要有理由。
客觀地估算,不貪多不偷減:就像老板不能隨便削減你的估算一樣,你也同樣不能在估算的時候,貪多或是偷減。貪多必然導致會浪費,偷減必然導致不足。這兩個結果恐怕都不是一個合格的項目經(jīng)理的作為。
客觀利用過去的經(jīng)驗:對于以往估算的經(jīng)驗,當然是寶貴的財富,但是如果財富用錯了地方就會變成垃圾。在使用經(jīng)驗時,要注意現(xiàn)在和參考經(jīng)驗之間的差異。不要忘記,隨著時間的推移,計算機領域技術的更新,許多觀念都在發(fā)生著改變。
不要以客戶目標作為估算的結果:客戶是上帝,軟件公司一定要盡力實現(xiàn)客戶的需求。但我們要實現(xiàn)的是合理的目標,況且不能為了完成目標而去堆積數(shù)字,這樣豈不是因果倒置了。
不要隱匿不確定的成本:軟件開發(fā)中存在潛在風險,是很正常的事情,F(xiàn)在風險就會帶來潛在的成本,如:突然一位程序員離職,導致工作進度路落后。我們不可能估算到任何一種可能發(fā)生的情況,但有責任把可能出現(xiàn)的一些關鍵環(huán)節(jié)列出來。
此文章共有6頁 上一頁 1 2 3 4 5 6
文章來源:中國項目管理資源網(wǎng)
|