[讀書筆記]軟體估算-估算方法(二)
1 專家個人判斷
1.1 有組織的專家判斷
專家判斷並不是說是基於直覺的,同樣可以是有組織的,有組織的專家判斷估算準確度要高.
對於特定的任務(譬如模組的編碼除錯等),具體由誰來估算最準確?經驗得知由將要實際承擔工作的人來進行估算最準確.所以要獲得任務一級的估算,就應該讓實際做這項工作的人來進行估算.要提高任務一級估算準確度的最佳方法是把較大的任務分解為較小的任務,然後由相關的人員進行估算.
單點估算:讓開發人員對某一特性進行估算,譬如”資料轉換”估計要用2天的時間;
最好最壞情況估算:讓開發人員對某一特性進行最好情況下和最壞情況下估算,譬如單點估算:讓開發人員對某一特性進行估算,譬如”資料轉換”估計最好要用1天的時間,最壞要用3天;
我們常用的做法是讓開發人員先進行單點估算,然後不看這個單點值情況下進行最好最壞情況估算,這樣容易讓開發人員想起容易遺漏的工作;
如何利用這個最好情況和最壞情況的估算值?
l 1:公式1----預期情況=[最好情況+(4*最可能情況)+最差情況]/6,這個公式叫做PERT(program evaluation and review technique)
l 2:公式2----預期情況=[最好情況+(3*最可能情況)+(2*最差情況)]/6,這個公式考慮了估算人員總是得到樂觀的估算.
為了避免在估算中遺漏某些工作,需要製作一張簡單的檢查表,用於提高估算的準確度.檢查表如下:
l 是否明確定義了估算的物件?
l 估算中是否包括了完成任務所需的工作型別?
l 估算中是否包括了完成任務所需的功能領域?
l 估算是否被分解的足夠詳細?
l 是使用來自過去工作的已記錄事實還是單純的根據記憶估算?
l 估算是否被實際將要工作的人的認可?
l 估算中設定的生產率是否接近類似工作達到的生產率?
l 估算中是否包括了最好情況,最壞情況和最可能情況?
l 估算的最差值是否是真正的最差值?是否還要考慮更差的情況?
l 是否從這些情況中正確的計算出預期情況?
l 是否記錄估算的假設?
l 作出估算之後情況是否發生改變?
使用這些檢查表來概算個人估算的能力,建立和維護個人檢查表來提高估算的準確度.
1.2 比較估算值和實際值
對實際結果進行比較,提高個人的估算能力,
保留好估算清單,在工作完成時填寫實際結果,然後計算出估算的相對誤差.
MRE(mangintude of relative error)=[(實際結果-估算結果)/實際結果]的絕對值;
隨著估算的改進,可以看倒MRE在逐漸的減小;
2 分解和重組
分解就是把估算物件分成多個部分,分別對單個部分進行估算,再把單個估算聚合成總體估算的實踐活動,又叫自底向上,微估算等
2.1 計算準確的整體預期情況
我們把大的估算物件分解為許多個小的估算物件,然後對小的估算物件進行估算,可能會出現這樣的情況:每個估算物件的誤差都很大,但是總體的誤差很小,這就是統計學中的大數法則,即要對某個大物件進行估算,可能偏大,也可能偏小,如果我們把大物件分解為很多個小物件進行估算,同樣會可能偏大,也可能偏小,但這個誤差可以相互抵消,這就是大數法則.
2.2 通過基於活動的工作分解結構進行分解
有些未發現的工作是以被遺忘的特性的形式隱藏起來,或者以被遺忘的任務隱藏起來,通過基於活動的工作分解結構來分解專案有助於避免遺忘任務.
使用通用的軟體專案分解結構(WBS)來避免遺漏常見的活動.
2.3 累加最好情況和最壞情況的危害
簡單累加分解後的單點估算值得到的估算結果是帶有樂觀主義和前面討論的”90%置信度”的影響.
統計學原理:假設最小值和最大值之差的1/6大致等於標準差,這一近似方法假設實際結果小於最小值的可能性為0.135%.而大於最大值的可能性是99.86%.
2.4 建立有意義的總體最好情況和最差情況估算
對於少量的任務(不超過10個),可以根據簡單的標準偏差來計算最好情況和最差情況.首先把單個任務的最好情況和最差情況分別相加,然後使用下面的公式計算出標準偏差.
標準偏差=(最差情況之和-最好情況之和)/6.
然後利用標準偏差計算出具有百分比表示的可能性估算值
百分比置信度 |
計算方法 |
60% |
預期情況+(0.25*標準差) |
70% |
預期情況+(0.52*標準差) |
75% |
預期情況+(0.67*標準差) |
80% |
預期情況+(0.84*標準差) |
84% |
預期情況+(1*標準差) |
90% |
預期情況+(1.28*標準差) |
98% |
預期情況+(2*標準差) |
50% |
預期情況 |
譬如某個專案的最好情況之和為20人周,最壞情況之和為38.6人周,那麼標準差為3.1,預期情況(50%可能情況)為29人周,具有75%完成該專案的可能性的估算值為29+(0.67*3.1).為31人周.
為什麼不能是31.1人周?因為輸出的準確度不能超過輸入的準確度.
但是如果超過10個以上的任務,這種用標準差計算的方法就會失效,需要用更復雜的公式來計算,有以下幾步:
l 對每一個單個的估算值分別應用標準偏差公式:單個標準偏差=(單個最差情況估算值-單個最好情況估算值)/6
l 計算每項任務的標準偏差的平方,得到方差;
l 對方差求和;
l 得到方差和的平方根.
上面第一步計算標準差是除以6,除以6的前提是達到97%的置信度,當然實際情況不會達到這個準度,具體達到什麼置信度比較合理.看下面的表格:
實際結果落入估算範圍的可能性 |
用於計算單個估算標準差的除數 |
10% |
0.25 |
20% |
0.51 |
30% |
0.77 |
40% |
1.0 |
50% |
1.4 |
60% |
1.7 |
70% |
2.1 |
80% |
2.6 |
90% |
3.3 |
99% |
6 |
所以要使實際結果落入估算範圍的可能性達到70%,那麼單個標準差的的除數為2.1,即(單個最差情況-單個最好情況)/2.1為單個標準差的計算公式.
上述的估算方法有個缺陷:就是預期情況的估算值必須是準確的,即它們確實具有50%的可能性,
如果單個估算值是準確的,那麼進行聚合就不會產生問題,如果單個估算值不準確,那麼進行聚合就會有問題,所以輸入的單個估算必須準確,利用本章的計算公式才有意義.
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/22878014/viewspace-620691/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- [讀書筆記]軟體估算-估算方法(一)筆記
- [讀書筆記]軟體估算-估算的含義筆記
- 貓讀《軟體估算》三
- 軟體工程估算的技巧 - shubhro軟體工程
- 軟體專案計劃-估算雜談
- 軟體專案中的功能點法估算-原理
- 軟體開發週期估算及探討(轉)
- "軟體隨想錄" 讀書筆記筆記
- 專案規模估算方法論
- 軟體專案中的功能點法估算-例項
- 軟體開發的成本估算—我的程式碼行
- 《軟體架構設計》讀書筆記架構筆記
- 「修改軟體的藝術」 讀書筆記筆記
- Oracle 估算資料庫大小的方法Oracle資料庫
- 三種專案成本估算方法(轉)
- 軟體開發相關的讀書筆記 問題與方法筆記
- 軟體專案估算是一件很難的事情
- The Great Gatsby讀書筆記(二)筆記
- TIJ讀書筆記(二) (轉)筆記
- 《軟體開發本質論》讀書筆記筆記
- 讀書筆記——《軟體工程》第10~12章筆記軟體工程
- 《深度探索c++記憶體模型》讀書筆記 (二)C++記憶體模型筆記
- 五大定律:軟體開發中的時間估算
- 七種場景下的軟體工作量估算步驟
- 軟體安全開發生命週期讀書筆記筆記
- 敏捷估算:點之殤敏捷
- process和session引數最大值估算方法Session
- PostgreSQL任意列組合條件行數估算實踐-取樣估算SQL
- 《簡約之美:軟體設計之道》- 讀書筆記筆記
- 《分散式快取》讀書筆記二分散式快取筆記
- 《深入剖析Tomcat》讀書筆記(二)Tomcat筆記
- 人月神話讀書筆記(二) (轉)筆記
- 《具體數學》讀書筆記筆記
- 遊戲ROI估算模型(附工具)遊戲模型
- 架構設計(九):估算架構
- 專案成本估算快速指南
- 有關專案的估算
- 軟體開發週期估算及探討-程式碼例項講解