作者：張克強 軟件項目工作量估算從估算依據(jù)上看可以分成如下兩類：1，基于規(guī)模估算2，基于工作量估算基于規(guī)模估算的情況下，需要估算軟件項目的規(guī)模。本文首先來看規(guī)模方面的問題。問題1：如何表達(dá)規(guī)模？軟件產(chǎn)品或項目的功能規(guī)模是涉及軟件開發(fā)和交易的成本、項目資源投入的預(yù)測、項目維護(hù)成本的預(yù)算、項目質(zhì)量管理的要求以及產(chǎn)品上市的時間等方面的關(guān)鍵指標(biāo)。因此，進(jìn)行軟件產(chǎn)品的功能規(guī)模測量顯得尤其重要。如何測量軟件規(guī)模這個問題自軟件工程誕生起就一直是這個領(lǐng)域的焦點問題。剛開始，人們很自然的使用代碼行數(shù)作為規(guī)模的表達(dá)。但是作為規(guī)模表達(dá)方式的代碼行數(shù)隨著時間和技術(shù)的發(fā)展，越來越不正確了，主要原因是1，新工具自動生成大量代碼行；2復(fù)用構(gòu)件或源代碼；3，難以區(qū)分新開發(fā)代碼和舊代碼。而且最重要的是源代碼行數(shù)的實際測量只能在軟件項目開發(fā)的后期，缺乏在前期較精確指導(dǎo)項目的能力。世界上各個組織都看到了代碼行作為規(guī)模表達(dá)方式的弊端，紛紛發(fā)展了各自的規(guī)模表達(dá)方式，其中IFPUG的功能點計數(shù)是其中有顯著影響的。但是由于規(guī)模度量存在各種各樣的情況，IFPUG的方法并沒有統(tǒng)治地位，涌現(xiàn)了多種規(guī)模度量方法。目前，國內(nèi)外軟件領(lǐng)域的專家對軟件功能規(guī)模測量開展了極富成效的研究，提出了各類工業(yè)標(biāo)準(zhǔn)。國際標(biāo)準(zhǔn)化組織（ISO）和國際電工委員會（IEC）聯(lián)合技術(shù)委員會分別于1998、2002和2003年推出了軟件功能規(guī)模測量方面的系列標(biāo)準(zhǔn)。國際標(biāo)準(zhǔn)化組織ISO/IEC相繼發(fā)表了4個功能規(guī)模測量方法的標(biāo)準(zhǔn)，它們是：——ISO/IEC?19761（COSMIC-FFP方法）；——ISO/IEC?20926（IFPUG方法）；——ISO/IEC?20968（MkⅡ方法）；——ISO/IEC?24750（NESMA方法）。其中，COSMIC-FFP方法聲明可以應(yīng)用于管理信息系統(tǒng)（MIS）和實時類型二類軟件，IFPUG方法聲明可用于所有類型的軟件，MkⅡ方法聲明可用于邏輯事務(wù)能被確定的任何軟件類型，NESMA方法非常類似于IFPUG方法也可以用于所有軟件類型。我國也十分重視這類標(biāo)準(zhǔn)的研究，于2001年開始了這方面的工作。我國相繼發(fā)布了GB/T?18491.1～6《信息技術(shù)??軟件測量??功能規(guī)模測量》的系列標(biāo)準(zhǔn)，但具體的測量方法不包含在該系列標(biāo)準(zhǔn)中。由中國工業(yè)和信息化部支持的《軟件工程??軟件功能規(guī)模測量方法??????功能點計數(shù)》（征求意見稿）于2011年9月1日完成，現(xiàn)在正處于意見征集階段，這個標(biāo)準(zhǔn)非等效采用了ISO/IEC?20926:2003，為所有類型的軟件開發(fā)的全生存周期提供了一種統(tǒng)一的軟件功能規(guī)模計數(shù)方法。除了以上方法，常見的方法還有：其它各類功能點方法代碼行數(shù)?LOC數(shù)據(jù)點對象點用例點故事點，故事點是比較特殊的一個方法，下文還有說明。不少公司發(fā)展了自己的功能規(guī)模測量方法。問題2：如何測量規(guī)模？以上這些規(guī)模測量方法的基本框架是相同的，下面是一個概要的介紹。首先對做所測量對象進(jìn)行分解，針對分解得到的各個部分，估算或測量模塊的初始規(guī)模u（有些場合稱為未調(diào)整功能點），乘以模塊級調(diào)節(jié)參數(shù)f1，得到模塊一次調(diào)整后的規(guī)模，將所有一次調(diào)整后的規(guī)模累加得到一次調(diào)整后的總規(guī)模，乘以總體調(diào)節(jié)系數(shù)f2，得到二次調(diào)整后的總規(guī)模s，見如下公式：總規(guī)模S?=?(西格瑪u*f1)*f2有些方法只有一次調(diào)整，有些方法有上述的2次調(diào)整。問題3：如何根據(jù)規(guī)模估算工作量經(jīng)過前人的大量研究，認(rèn)為規(guī)模與工作量的數(shù)學(xué)關(guān)系如以下公式所示：估算工作量e??=??a?*?S的b次方?+?cs是代表了規(guī)模,?a,b,c是參數(shù)，其值的獲得需要大量數(shù)據(jù)分析，一般采用非線性轉(zhuǎn)換到線性，再進(jìn)行線性回歸分析。b的取值一般是1到1.2之間。從以上公式可以看出，隨著規(guī)模s的增加，工作量e是指數(shù)級增長，表明了軟件項目規(guī)模越大，所需要的工作量增加得更多，表明了軟件開發(fā)規(guī)模不經(jīng)濟(jì)的情況，這和我們直觀的感受是一致的。世界上各個軟件生產(chǎn)率研究組織（比如ISBSG，SPR，日本的IPA?SEC等）收集了成千上萬個項目數(shù)據(jù)，開展各種各樣的數(shù)學(xué)分析，試圖得到在各種情況下?a,?b?,c?的取值。在第5屆世界軟件質(zhì)量大會上，來自Toyo?University的野中誠（Makoto?Nonaka）介紹了日本IPA?SEC組織（http://sec.ipa.go.jp/），舉了某種情況下的一個工作量估算公式：工數(shù)?=?e的0.542次方*FP的1.154次方?=?1.719*FP的1.154次方。對于一般的場合，其規(guī)模在一定有限的范圍之內(nèi)，那么可以假設(shè)工作量與規(guī)模的關(guān)系是簡單的線性正相關(guān)，那么上述公式就變?yōu)?#xff1a;估算工作量e?=??a?*?S，即b=1,?c=0?。?那么參數(shù)?a?就是?表明了生產(chǎn)率，a的單位是?工作量/單位規(guī)模，比如8工時/FP；另外一種生產(chǎn)率單位是規(guī)模/單位工作量，比如30FP/Man-month，如果采用常見的生產(chǎn)率單位，那么a就是生產(chǎn)率的倒數(shù)。?這種做法是更容易為各方所理解，在很多組織里常見到這個做法。對比基于規(guī)模的工作量估算，直接的工作量估算方法所積累的數(shù)據(jù)和資料就少了,沒有看到哪個組織在收集積累這類數(shù)據(jù)，這與直接工作量估算方法本身的特征也有關(guān)系。下面來看看直接工作量估算方面的問題。問題4，如何表達(dá)工作量？工作量的單位一般是工時、人天、人月、人年。這些不同的單位是可以換算的。不同單位換算并不麻煩，在同一個國家沒有差異，在不同國家因為法定假期的不同，1人月所對應(yīng)的人天可能是不同的，但差異并不大。真正麻煩的是工作量表達(dá)有如下兩種：1，工作量2，理想工作量而工作量也有差異，有些地方是計毛時，比如一天都在某項目上工作，就直接記為8工時，有些地方是計凈時，雖然一天都在某項目上工作，但會把諸如非直接相關(guān)的工作（如部門例會、參加其它項目評審）等等剝離，一天在某項目上的工作量只有5工時。?這樣看，可以發(fā)現(xiàn)計凈時的工作量與理想工作量比較接近，但注意并不完全相等。問題5，如何直接估算工作量？主要的思路是分解和類比。把待完成物細(xì)分，根據(jù)以往估算和經(jīng)驗進(jìn)行類比估算。??對于以往估算和經(jīng)驗的處理，可以分為兩種做法：1，不做特別處理，自然停留在團(tuán)隊成員的頭腦里，使用時并不明確要求、不保證能夠想起來對照2，記錄典型事物（特性，用戶故事等）所需要的工作量，得到一套基準(zhǔn)類比庫，新任務(wù)根據(jù)這個基準(zhǔn)類比庫來估算。在使用理想工作量的情況下，需要一個名為capacity的參數(shù)。工作量?=?理想工作量?/?capacity?，capacity的取值一般是50%?~?80%。在估算時，本次待完成的理想工作量?=?計劃的工作容量?*?capacity在回顧時，capacity?=?原估算的理想工作量?/?實際工作容量?*?100%，注意工作容量并不等于工作量，而是團(tuán)隊在指定時段內(nèi)可以提供的工作量，比如?5個人的團(tuán)隊工作21天，那么這個工作容量就是5*21=105人天。在使用工作量時，注意區(qū)分毛時和凈時，在選擇凈時的情況下，需要注意一天按多少小時來計，比如按5小時來計算，估算工作量達(dá)到50工時，如果1個人做的話，需要10天來完成。問題6，在什么情況下使用直接工作量估算？?可以看到雖然以前也存在直接工作量估算的做法，但并沒有得到大力的宣揚，在以前的軟件工程教材里，一般很少提直接工作量估算。從敏捷類開發(fā)方法開始起，直接工作量估算得到了宣揚，得到了更廣泛的傳播。在敏捷類軟件迭代開發(fā)當(dāng)中存在對此方法的不少應(yīng)用。問題7，Story?Point的特殊情況是什么？Story?Point的起源與理想工作日緊密相關(guān)，一般的，在開始時，團(tuán)隊會將估計一理想人日能完成的用戶故事為一個故事點。如果始終保持一理想人日對等于一個故事點，那么故事點估算其實是直接工作量估算。但多數(shù)情況下，1個故事點對應(yīng)的工作量是會發(fā)生變化的，隨著團(tuán)隊的變化，對1個故事點所需要的工作量一般會減少。有些團(tuán)隊會始終維護(hù)一套用戶故事樣例庫，相當(dāng)于用戶故事的砝碼，新的用戶故事與樣例庫的用戶故事進(jìn)行比對，進(jìn)而判定新用戶故事的故事點數(shù)。在具體比對上，常見的方法有?排序法，排序法一般利用斐波那契數(shù)列（1，2，3，5，8，15,?…，？，無窮大），還有模仿T-shirt?size估算，常見的，分成3到5檔，比如?S、M、L、XL，或大、中、小，給每一檔設(shè)定故事點數(shù)值。可以看到排序法和T-shirt?size模仿估算在本質(zhì)上是一樣的，T-shirt?size模仿估算是排序法的一個實現(xiàn)。這有樣例庫的做法得到的估算點數(shù)就是規(guī)模，值得注意的是?故事點所表達(dá)的規(guī)模是相對的規(guī)模。不同組織、不同團(tuán)隊的故事點是不可以比較的。這與諸如IFPUG、NESMA等等的功能點是不一樣的。4個國際軟件功能規(guī)模測量標(biāo)準(zhǔn)的功能點是像“米”一樣的絕對單位。就是說?在中國A公司的A1軟件用IFPUG識別出了1000個功能點，美國B公司的B1軟件也用IFPUG識別出的1000個功能點，那么可以說A1軟件的規(guī)模與B1軟件規(guī)模相等。而如果中國A公司的A2軟件用Story?Point識別出了1000個故事點，美國B公司的B2軟件也用Story?Point識別出了1000個故事點，那么，是不能說A2軟件的規(guī)模與B2軟件規(guī)模相等，兩種不具備可比性，如果非要比較，那么需要分析A2和B2各自所依據(jù)的故事點樣例或基準(zhǔn)。前面說到新的用戶故事與樣例庫的用戶故事進(jìn)行比對，進(jìn)而判定新用戶故事的故事點數(shù)，目前這個比對并沒有絕對的做法，常見不同的做法有：1，是否考慮不同人做的影響2，是否考慮實現(xiàn)的復(fù)雜度、難度3，是否考慮新用戶故事關(guān)聯(lián)或依賴的事務(wù)4，是否考慮有疑問的部分目前業(yè)界對以上的問題并沒有定論，各家組織或團(tuán)隊結(jié)合各自情況和理解各有各的選擇。因此，Story?point具備在規(guī)模和直接工作量的兩種形態(tài)之間變化的多態(tài)，具備巨大的靈活性，具體組織在采用Story?Point時，可以做適應(yīng)性的選擇。問題8，哪種方法更加準(zhǔn)確？沒有結(jié)合具體情況，這個問題是無法回答的。假設(shè)誤差系數(shù)=?估算值/實際值。?估算值?=?實際值?*?誤差系數(shù)?絕對誤差?=??實際值-估算值?=?實際值?-?實際值?*?誤差系數(shù)?=?實際值*（1-誤差系數(shù)）可以看到的一點是?敏捷小團(tuán)隊短迭代的實際值是不大的。?假設(shè)9個人的團(tuán)隊，迭代周期是3周，那么?實際值約在135人天范圍之內(nèi)。就算誤差系數(shù)比較大，絕對誤差也是有限的。而傳統(tǒng)瀑布型項目就是另外一個樣子，比如時間跨度也許達(dá)到1年，總的人月數(shù)約是120人月，在這種情況下，就不難理解為什么存在多個組織來維護(hù)功能點定義，收集數(shù)據(jù)，給出需要指數(shù)運算的估算公式。因為就算誤差系數(shù)小，由于基數(shù)大，所造成的絕對誤差就比較大。在敏捷開發(fā)方法里，常見的，采用撲克估算方式，這個方法可以驅(qū)動整體團(tuán)隊的智慧來確定故事點的大小，也能提高估算的精確度，而且也能澄清不同的理解，是非常值得采納的一個方法。

總結(jié)

以上是生活随笔為你收集整理的关于软件项目工作量估算的若干问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。