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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。