基于范圍估算的情況下，需要估算軟件項目的范圍。本文首先來看范圍方面的問題。

問題1：如何表達(dá)范圍？

軟件產(chǎn)品或項目的功能范圍是觸及軟件開發(fā)和交易的本錢、項目資源投入的預(yù)測、項目保護(hù)本錢的預(yù)算、項目質(zhì)量管理的要求和產(chǎn)品上市的時間等方面的關(guān)鍵指標(biāo)。因此，進(jìn)行軟件產(chǎn)品的功能范圍丈量顯得特別重要。

如何丈量軟件范圍這個問題自軟件工程誕生起就1直是這個領(lǐng)域的焦點(diǎn)問題。剛開始，人們很自然的使用代碼行數(shù)作為范圍的表達(dá)。但是作為范圍表達(dá)方式的代碼行數(shù)隨著時間和技術(shù)的發(fā)展，愈來愈不正確了，主要緣由是1，新工具自動生成大量代碼行；2復(fù)用構(gòu)件或源代碼；3，難以辨別新開發(fā)代碼和舊代碼。而且最重要的是源代碼行數(shù)的實(shí)際丈量只能在軟件項目開發(fā)的后期，缺少在前期較精確指點(diǎn)項目的能力。

世界上各個組織都看到了代碼行作為范圍表達(dá)方式的弊端，紛紜發(fā)展了各自的范圍表達(dá)方式，其中IFPUG的功能點(diǎn)計數(shù)是其中有顯著影響的。但是由于范圍度量存在各種各樣的情況，IFPUG的方法并沒有統(tǒng)治地位，出現(xiàn)了多種范圍度量方法。目前，國內(nèi)外軟件領(lǐng)域的專家對軟件功能范圍丈量展開了極富成效的研究，提出了各類工業(yè)標(biāo)準(zhǔn)。國際標(biāo)準(zhǔn)化組織（ISO）和國際電工委員會（IEC）聯(lián)合技術(shù)委員會分別于1998、2002和2003年推出了軟件功能范圍丈量方面的系列標(biāo)準(zhǔn)。國際標(biāo)準(zhǔn)化組織ISO/IEC相繼發(fā)表了4個功能范圍丈量方法的標(biāo)準(zhǔn)，它們是：

――ISO/IEC 19761（COSMIC-FFP方法）；

――ISO/IEC 20926（IFPUG方法）；

――ISO/IEC 20968（MkⅡ方法）；

――ISO/IEC 24750（NESMA方法）。

其中，COSMIC-FFP方法聲明可以利用于管理信息系統(tǒng)（MIS）和實(shí)時類型2類軟件，IFPUG方法聲明可用于所有類型的軟件，MkⅡ方法聲明可用于邏輯事務(wù)能被肯定的任何軟件類型，NESMA方法非常類似于IFPUG方法也能夠用于所有軟件類型。

我國也10分重視這類標(biāo)準(zhǔn)的研究，于2001年開始了這方面的工作。

我國相繼發(fā)布了GB/T 18491.1～6《信息技術(shù)  軟件丈量  功能范圍丈量》的系列標(biāo)準(zhǔn)，但具體的丈量方法不包括在該系列標(biāo)準(zhǔn)中。由中國工業(yè)和信息化部支持的《軟件工程  軟件功能范圍丈量方法      功能點(diǎn)計數(shù)》（征求意見稿）于2011年9月1日完成，現(xiàn)在正處于意見征集階段，這個標(biāo)準(zhǔn)非等效采取了ISO/IEC 20926:2003，為所有類型的軟件開發(fā)的全生存周期提供了1種統(tǒng)1的軟件功能范圍計數(shù)方法。

除以上方法，常見的方法還有：

其它各類功能點(diǎn)方法

代碼行數(shù) LOC

數(shù)據(jù)點(diǎn)

對象點(diǎn)

用例點(diǎn)

故事點(diǎn)，故事點(diǎn)是比較特殊的1個方法，下文還有說明。

很多公司發(fā)展了自己的功能范圍丈量方法。

問題2：如何丈量范圍？

以上這些范圍丈量方法的基本框架是相同的，下面是1個概要的介紹。

首先對做所丈量對象進(jìn)行分解，針對分解得到的各個部份，估算或丈量模塊的初始范圍u（有些場合稱為未調(diào)劑功能點(diǎn)），乘以模塊級調(diào)理參數(shù)f1，得到模塊1次調(diào)劑后的范圍，將所有1次調(diào)劑后的范圍累加得到1次調(diào)劑后的總范圍，乘以整體調(diào)理系數(shù)f2，得到2次調(diào)劑后的總范圍s，見以下公式：

總范圍S = (西格瑪u*f1)*f2

有些方法只有1次調(diào)劑，有些方法有上述的2次調(diào)劑。

問題3：如何根據(jù)范圍估算工作量

經(jīng)過前人的大量研究，認(rèn)為范圍與工作量的數(shù)學(xué)關(guān)系如以下公式所示：

估算工作量e  =  a * S的b次方 + c

s是代表了范圍, a,b,c是參數(shù)，其值的取得需要大量數(shù)據(jù)分析，1般采取非線性轉(zhuǎn)換到線性，再進(jìn)行線性回歸分析。b的取值1般是1到1.2之間。

從以上公式可以看出，隨著范圍s的增加，工作量e是指數(shù)級增長，表明了軟件項目范圍越大，所需要的工作量增加得更多，表明了軟件開發(fā)范圍不經(jīng)濟(jì)的情況，這和我們直觀的感受是1致的。

世界上各個軟件生產(chǎn)率研究組織（比如ISBSG，SPR，日本的IPA SEC等）搜集了不計其數(shù)個項目數(shù)據(jù)，展開各種各樣的數(shù)學(xué)分析，試圖得到在各種情況下 a, b ,c 的取值。

在第5屆世界軟件質(zhì)量大會上，來自Toyo University的野中誠（Makoto Nonaka）介紹了日本IPA SEC組織（http://sec.ipa.go.jp/），舉了某種情況下的1個工作量估算公式：

工數(shù) = e的0.542次方*FP的1.154次方 = 1.719*FP的1.154次方。

對1般的場合，其范圍在1定有限的范圍以內(nèi)，那末可以假定工作量與范圍的關(guān)系是簡單的線性正相干，那末上述公式就變成：

估算工作量e =  a * S，即b=1, c=0 。 那末參數(shù) a 就是 表明了生產(chǎn)率，a的單位是 工作量/單位范圍，比如8工時/FP；另外1種生產(chǎn)率單位是范圍/單位工作量，比如30FP/Man-month，如果采取常見的生產(chǎn)率單位，那末a就是生產(chǎn)率的倒數(shù)。 

這類做法是更容易為各方所理解，在很多組織里常見到這個做法。

對照基于范圍的工作量估算，直接的工作量估算方法所積累的數(shù)據(jù)和資料就少了,沒有看到哪一個組織在搜集積累這類數(shù)據(jù)，這與直接工作量估算方法本身的特點(diǎn)也有關(guān)系。

下面來看看直接工作量估算方面的問題。

問題4，如何表達(dá)工作量？

工作量的單位1般是工時、人天、人月、人年。這些不同的單位是可以換算的。不同單位換算其實(shí)不麻煩，在同1個國家沒有差異，在不同國家由于法定假期的不同，1人月所對應(yīng)的人天多是不同的，但差異其實(shí)不大。真正麻煩的是工作量表達(dá)有以下兩種：

1，工作量

2，理想工作量

而工作量也有差異，有些地方是計毛時，比如1天都在某項目上工作，就直接記為8工時，有些地方是計凈時，雖然1天都在某項目上工作，但會把諸如非直接相干的工作（如部門例會、參加其它項目評審）等等剝離，1天在某項目上的工作量只有5工時。 這樣看，可以發(fā)現(xiàn)計凈時的工作量與理想工作量比較接近，但注意其實(shí)不完全相等。

問題5，如何直接估算工作量？

主要的思路是分解和類比。

把待完成物細(xì)分，根據(jù)以往估算和經(jīng)驗進(jìn)行類比估算。  對以往估算和經(jīng)驗的處理，可以分為兩種做法：

1，不做特別處理，自然停留在團(tuán)隊成員的頭腦里，使用時其實(shí)不明確要求、不保證能夠想起來對比

2，記錄典型事物（特性，用戶故事等）所需要的工作量，得到1套基準(zhǔn)類比庫，新任務(wù)根據(jù)這個基準(zhǔn)類比庫來估算。

在使用理想工作量的情況下，需要1個名為capacity的參數(shù)。工作量 = 理想工作量 / capacity ，capacity的取值1般是50% ~ 80%。

在估算時，本次待完成的理想工作量 = 計劃的工作容量 * capacity

在回顧時，capacity = 原估算的理想工作量 / 實(shí)際工作容量 * 100%，注意工作容量其實(shí)不等于工作量，而是團(tuán)隊在指定時段內(nèi)可以提供的工作量，比如 5個人的團(tuán)隊工作21天，那末這個工作容量就是5*21=105人天。

在使用工作量時，注意辨別毛時和凈時，在選擇凈時的情況下，需要注意1天按多少小時來計，比如按5小時來計算，估算工作量到達(dá)50工時，如果1個人做的話，需要10天來完成。

問題6，在甚么情況下使用直接工作量估算？ 

可以看到雖然之前也存在直接工作量估算的做法，但并沒有得到大力的宣揚(yáng)，在之前的軟件工程教材里，1般很少提直接工作量估算。

從敏捷類開發(fā)方法開始起，直接工作量估算得到了宣揚(yáng)，得到了更廣泛的傳播。

在敏捷類軟件迭代開發(fā)當(dāng)中存在對此方法的很多利用。

問題7，Story Point的特殊情況是甚么？

Story Point的起源與理想工作日緊密相干，1般的，在開始時，團(tuán)隊會將估計1理想人日能完成的用戶故事為1個故事點(diǎn)。

如果始終保持1理想人日對等于1個故事點(diǎn)，那末故事點(diǎn)估算實(shí)際上是直接工作量估算。

但多數(shù)情況下，1個故事點(diǎn)對應(yīng)的工作量是會產(chǎn)生變化的，隨著團(tuán)隊的變化，對1個故事點(diǎn)所需要的工作量1般會減少。

有些團(tuán)隊會始終保護(hù)1套用戶故事樣例庫，相當(dāng)于用戶故事的砝碼，新的用戶故事與樣例庫的用戶故事進(jìn)行比對，進(jìn)而判定新用戶故事的故事點(diǎn)數(shù)。

在具體比對上，常見的方法有 排序法，排序法1般利用斐波那契數(shù)列（1，2，3，5，8，15, …，？，無窮大），還有模仿T-shirt size估算，常見的，分成3到5檔，比如 S、M、L、XL，或大、中、小，給每檔設(shè)定故事點(diǎn)數(shù)值。

可以看到排序法和T-shirt size模仿估算在本質(zhì)上是1樣的，T-shirt size模仿估算是排序法的1個實(shí)現(xiàn)。

這有樣例庫的做法得到的估算點(diǎn)數(shù)就是范圍，值得注意的是 故事點(diǎn)所表達(dá)的范圍是相對的范圍。不同組織、不同團(tuán)隊的故事點(diǎn)是不可以比較的。這與諸如IFPUG、NESMA等等的功能點(diǎn)是不1樣的。

4個國際軟件功能范圍丈量標(biāo)準(zhǔn)的功能點(diǎn)是像“米”1樣的絕對單位。就是說 在中國A公司的A1軟件用IFPUG辨認(rèn)出了1000個功能點(diǎn)，美國B公司的B1軟件也用IFPUG辨認(rèn)出的1000個功能點(diǎn)，那末可以說A1軟件的范圍與B1軟件范圍相等。而如果中國A公司的A2軟件用Story Point辨認(rèn)出了1000個故事點(diǎn)，美國B公司的B2軟件也用Story Point辨認(rèn)出了1000個故事點(diǎn)，那末，是不能說A2軟件的范圍與B2軟件范圍相等，兩種不具有可比性，如果非要比較，那末需要分析A2和B2各自所根據(jù)的故事點(diǎn)樣例或基準(zhǔn)。

前面說到新的用戶故事與樣例庫的用戶故事進(jìn)行比對，進(jìn)而判定新用戶故事的故事點(diǎn)數(shù)，目前這個比對并沒有絕對的做法，常見不同的做法有：

1，是不是斟酌不同人做的影響

2，是不是斟酌實(shí)現(xiàn)的復(fù)雜度、難度

3，是不是斟酌新用戶故事關(guān)聯(lián)或依賴的事務(wù)

4，是不是斟酌有疑問的部份

目前業(yè)界對以上的問題并沒有定論，各家組織或團(tuán)隊結(jié)合各自情況和理解各有各的選擇。

因此，Story point具有在范圍和直接工作量的兩種形態(tài)之間變化的多態(tài)，具有巨大的靈活性，具體組織在采取Story Point時，可以做適應(yīng)性的選擇。

問題8，哪一種方法更加準(zhǔn)確？

沒有結(jié)合具體情況，這個問題是沒法回答的。

假定誤差系數(shù)= 估算值/實(shí)際值。 

估算值 = 實(shí)際值 * 誤差系數(shù) 

絕對誤差 =  實(shí)際值-估算值 = 實(shí)際值 - 實(shí)際值 * 誤差系數(shù) = 實(shí)際值*（1-誤差系數(shù)）

可以看到的1點(diǎn)是 敏捷小團(tuán)隊短迭代的實(shí)際值是不大的。 假定9個人的團(tuán)隊，迭代周期是3周，那末 實(shí)際值約在135人天范圍以內(nèi)。就算誤差系數(shù)比較大，絕對誤差也是有限的。

而傳統(tǒng)瀑布型項目就是另外1個模樣，比如時間跨度或許到達(dá)1年，總的人月數(shù)約是120人月，在這類情況下，就不難理解為何存在多個組織來保護(hù)功能點(diǎn)定義，搜集數(shù)據(jù)，給出需要指數(shù)運(yùn)算的估算公式。由于就算誤差系數(shù)小，由于基數(shù)大，所釀成的絕對誤差就比較大。

在敏捷開發(fā)方法里，常見的，采取撲克估算方式，這個方法可以驅(qū)動整體團(tuán)隊的智慧來肯定故事點(diǎn)的大小，也能提高估算的精確度，而且也能澄清不同的理解，是非常值得采用的1個方法。