軟件本錢估算方法及應用

摘要軟件本錢估算是軟件開發必需品；按照基于算法模型的方法、非基于算法模型的方法以及組合方法的分類方式,分析了軟件本錢估算的各種代表性方法；與本錢估算強相關的軟件規模度量問題；研究了軟件本錢估算方法的評價標準,并給出了一個應用實例及其分析；從估算模型、估算演進、估算應用、估算內容、工具支持和人為因素6個方面說主要開展趨勢.背景 軟件本錢估算缺乏與需求不穩定并列,是造成軟件工程失控最普遍的兩個原因

是否采用算法模型分為3大類: 1基于算法模型的軟件本錢估算方法提供了一個或多個算法形式,如線性模型、乘法模型、分析模型、表格模型以及復合模型等,將軟件本錢估算為一系列主要本錢驅動因子變量的函數.該方法通過本錢估算關系(costestimatingrelationship)把系統特征與工作量、進度的估算值聯系起來.根本思想找到軟件工作量的各種本錢影響因子,并判定它對工作量所產生影響的程度是可加的、乘數的還是指數的,以期得到最正確的模型算法表達形式.優缺點一方面,它們比較客觀、高效、可重復,而且能夠利用以前的工程經驗進行校準,可以很好地支持工程預算、權衡分析、規劃控制和投資決策等;另一方面,它們難以用在沒有前例的場合,不能處理異常情況,也不能彌補不準確的規模輸入和本錢驅動因子級別的問題.通用形式A為校準因子(calibrationfactor);Size為對工作量呈可加性影響的軟件模塊的功能尺寸的度量;B為對工作量呈指數或非線性影響的比例因子(scalefactor);EM為影響軟件開發工作量的工作量乘數(effortmultiplicative).COCOMO81(1)根本(basic)模型,在工程相關信息極少的情況下使用;(2)中等(intermediate)模型,在需求確定以后使用;(3)詳細(detailed)模型,在設計完成后使用.模型通式Effort為工作量,表示為人月;a和b為系數,具體的值取決于建模等級(即根本、中等或詳細)以及工程的模式(組織型、半獨立型或嵌入型).KDSI為軟件工程開發中交付的源指令(deliveredsourceinstruction,簡稱DSI)千行數,也可用代碼行LOC表示,代表著軟件規模.F是調整因子,根本模型中,F=1,后兩個模型中,F為15個本錢因子對應的工作量乘數的乘積.例1要開發一個估計規模為30KDSI的銀行系統應用程序工程,其功能以數據處理為主,屬于組織型軟件模式,根據專家意見和工程數據校準,系數a=2.4,b=1.05;調整因子F=1,那么工作量Effort估算為隨著工程的進展和需求確實定,可以使用中等COCOMO81模型進行估算.例2對于例1的系統,隨著工程進展,可以確定其15個本錢因子的情況：其軟件可靠性因子RELY、計算機周轉時間因子TURN(computerTURNaroundtime)、要求的開發進度因子SCED(requireddevelopmentschedule)等特殊說明外,其余因子均為標稱取值1.00詳細COCOMO81模型與中等主要區別一旦軟件的各個模塊都已確定,估算者就可以使用詳細COCOMO81模型.其主要區別在于:(1)將待估算的軟件工程分解為模塊、子系統、系統3個等級.(2)增加了與開發階段相關的工作量乘數,它可以準確反映本錢驅動因子對工作量階段分布的影響.需求與產品設計RPD(requirements&productdesign)詳細設計DD(detaileddesign)代碼與單元測試CUT(code&unittest)集成與測試IT(integration&test).COCOMOII模型3個子模型組成(1)應用組合(applicationcomposition)模型,基于對象點(objectpoint)對采用集成計算機輔助軟件工程工具快速應用開發的軟件工程工作量和進度進行估算,用于工程規劃階段;(2)早期設計(earlydesign)模型,基于功能點(functionpoint,簡稱FP)或可用代碼行以及5個規模指數因子、7個工作量乘數因子,選擇軟件體系結構和操作,用于信息還缺乏以支持詳細的細粒度估算階段;(3)后體系結構(post-architecture)模型，發生在軟件體系結構完好定義和建立之后,基于源代碼行和功能點以及5個規模指數因子、17個工作量乘數因子,用于完成頂層設計和獲取詳細工程信息階段.改進 第一,COCOMOII規模度量在不同開發階段,可以分別用對象點、功能點或代碼行表示.第二,COCOMOII充分考慮了復用與再工程.其中需求演化和變更因子REVL：需求變更的百分比,等價KSLOC：將復用代碼和改編代碼的有效規模調整后的新代碼行.第三,進一步調整和改進本錢因子.先例性、開發靈活性、早期體系結構/風險化解RESL、團隊凝聚力、過程成熟度.2非基于算法模型的軟件本錢估算方法專家估算類比估算回歸分析2.1專家估算專家估算,由一個被認為是該任務專家的人來控制,并且估算過程的很大一局部是基于不清晰、不可重復的推理過程,也就是“直覺(intuition)〞.單個專家經常使用工作分解結構WBS(workbreakdownstructure),通過將工程元素放置到一定的等級劃分中來簡化預算估計與控制的相關工作.WBS包括兩個層次的分解:一個表示軟件產品本身的劃分,分解為各個功能組件及其各個子模塊;一個表示開發軟件所需活動的劃分,分解為需求、設計、編碼、測試、文檔等及其下更具體的細分,例如系統設計、數據庫設計、詳細設計等.Delphi方法首先,每個專家在不與其他人討論的前提下,先對某個問題給出自己的初步匿名評定.第1輪評定的結果收集、整理之后,返回給每個專家進行第2輪評定.這次專家們仍面對同一評定對象,所不同的是他們會知道第1輪總的匿名評定情況.第2輪的結果通常可以把評定結論縮小到一個小范圍,得到一個合理的中間范圍取值.2.2類比估算使用類比(analogy)的方法進行估算是CBR(case-basedreasoning,基于實例推理)的一種形式,即通過對一個或多個已完成的工程與新的類似工程的比照來預測當前工程的本錢與進度.在軟件本錢估算中,當把當前問題抽象為待估算的工程時,每個實例即指已完成的軟件工程.面對的問題(1)如何描述實例特征,即如何從相關工程特征中抽取出最具代表性的特征;(2)通過選取適宜的相似度/相異度的表達式,評價相似程度;(3)如何用相似的工程數據得到最終估算值.特征量的選取是一個決定哪些信息可用的實際問題,通常會征求專家意見以找出最相似實例的特征.中選取的特征不夠全面時,所用的解決方法也是使用專家意見.相似度計算可以直接取最相似的工程的工作量(對應P0工作量取1000);比較相似的幾個工程的工作量平均值(對應P0工作量取1900/2=950);采用某種調整策略,例如用工程的規模作調整參考,采用如下調整:Size(P0)/Size(P1)=Effort(P0)/Effort(P1),得到P0工作量為1000×180/200=900.缺乏點一是不能適用于早期規模等數據都不確定的情況二是應用一般集中于已有經驗的狹窄領域,不能跨領域應用;三是難以適應新的工程中約束條件、技術、人員等發生重大變化的情況.2.3回歸分析數據驅動方法；在對軟件工程進行估算時,通常情況下能得到相關軟件組織或軟件產品的某些歷史數據.充分利用這些歷史數據來預測與估算未來狀況。最傳統回歸方法OLS(普通最小二乘回歸,ordinaryleastsquaresregression),假定了將一個依賴變量與一個/多個獨立變量相關聯的一個函數形式OLS方法的回歸函數對于OLS回歸,指定一個模型(以表現依賴變量與獨立變量之間的關聯形式),然后將數據與這個指定的模型相配合,試圖使得方差的總和最小.這里,ikixx...2是對第i次觀測值的回歸變量,ββ2...是響應系數,β1是截距參數,yi是對第i次觀測值的響應變量,ui是隨機誤差.令ri表示對于第i次觀測值的實際觀測結果yi′與預計結果yi的差值,那么2ri就是平方誤差.OLS方法要做的就是估算出響應系數和截距參數,使得平方誤差的總和到達最小化,缺點(1)由于每一個觀測值對于模型公式有同等的影響,因此,哪怕只有一個差異過大的極端觀測值,也會對模型產生不可預計的影響.(2)由于所需的歷史數據依賴于回歸模型中的參數個數,當模型中回歸變量增多時,需要較多數量的歷史數據.通常,回歸模型所需的歷史數據數必須至少是模型中參數個數的5倍.(3)需要滿足對于軟件工程數據來說比較嚴格的假設條件,即回歸變量之間不能存在很強的相關性,回歸誤差的方差恒定.3軟件本錢估算的組合方法所謂軟件本錢估算的組合方法,就是在估算技術上明顯地綜合運用了多種技術與分析方法,這是目前軟件本錢估算的趨勢,也是中和各種估算方法利弊、適應不同估算場合與要求的更好選擇.3.1COBRACOBRA(costestimation,benchmarking,andriskassessment)是一種將算法方式與經驗方式相結合的混合估算方法,其核心是建立一個由兩組件構成的生產率估算模型步驟第一,建立因果關系模型(causalmodel),用來進行本錢超支(costoverhead)的估算.①確定最重要的本錢驅動因子.②建立定性的因果關系模型.③提出工程數據問卷.④量化關系.對各個本錢因子的量化就是反映它們在非正常工程中對本錢影響的百分比程度,該值稱為本錢超支乘數.⑤建立本錢超支估算模型,該模型由三角形分布的總和來表示.⑥估算本錢超支,用MonteCarlo仿真來對三角形分布取樣,仿真的結果是本錢超支的一個分布,可以選取分布的中值作為工程本錢超支的一個估算值.第二,建立生產率等式(productivityequation),得到對應于一個本錢超支值的資金數額或者工作量.優缺點優點:(1)在僅有少量工程數據時可選用該方法;(2)在工程估算方面,對可重用的專家知識進行了清晰的建模;(3)模型是以組織自身經驗為根底的,因此更容易被實踐者所接受.缺點：(1)需要專家接受面訪;(2)知識抽取比較困難,需要更多培訓與經驗.4軟件規模度量第一,在算法模型開展中,很多研究結論不約而同地沿用了本文引用的通用公式(2)或者另外一種表達形式:Effort=A+B×(Size)C,這都說明了軟件工作量PM或者Effort與規模Size直接的緊密聯系.隨著時間的開展,函數中的參數值發生了變化,規模度量形式也發生了改變,但是這種強相關的形式卻一直被沿用著.第二,目前在軟件估算方法的研究中又出現了一批更加直接使用規模度量值的方法。度量方式代碼行功能點及其擴展方式對象點用例點4.1代碼行(1)對代碼行沒有公認的可接受的標準定義.例如,最常見的計算代碼時的分歧有空代碼行、注釋代碼行、數據聲明、復用的代碼,以及包含多條指令的代碼行等.在Jones的研究中發現,對同一個產品進行代碼行計算,不同的計算方式可以帶來5倍之大的差異.(2)代碼行數量依賴于所用的編程語言和個人的編程風格.因此,計算的差異也會影響用多種語言編寫的程序規模,進而也很難對不同語言開發的工程的生產率進行直接比較.(3)在工程早期,需求不穩定、設計不成熟、實現不確定的情況下很難準確地估算代碼量.(4)代碼行強調編碼的工作量,只是工程實現階段的一局部.4.2功能點從需求得到系統所要實現功能的功能點,功能點的數量即系統規模.從功能點可以映射到代碼行,從而用于本錢和進度估算模型,這個轉換隨著開發語言的不同也會發生變化.兩步計算第1步,按照5種根本類型(外部輸入EI、外部輸出EO、內部邏輯文件ILF、外部接口文件EIF、外部查詢EQ)歸類,得到初始功能點數,分別乘以復雜性權重(根據每個功能類型所含數據元素和引用文件的數量分別歸為“簡單〞、“一般〞、“復雜〞3個復雜度等級,并對應不同的復雜性權重,見表3),5個加權后的數字相加即得到“未調整功能點〞UFP(unadjustedfunctionpoints)數;第2步,根據14個根本系統特征(generalsystemcharacteristic,簡稱GSC)確定調整因子VAF(valueadjustmentfactor),把調整因子應用到未調整功能點,即得到調整的功能點.4.4對象點對象點(objectpoint).可以應用于所有類型的軟件開發,而不局限于面向對象的開發.利用功能點的根本原理,對象點方法需要考慮那些需投入大工作量的方面來獲取規模,例如,效勞器數據表的數量、客戶數據表的數量、報表(report)和屏幕(screen)中可重用的百分比等等.要計算對象點,分析人員首先要計算應用中屏幕(screen)、報表(report)和第三代語言組件(3GLcomponent)數量的最可能值.4.5用例點用例點(usecasepoint,簡稱UCP)通過分析用例角色、場景和不同的技術與環境因子,把它們抽象到一個等式中.該等式由多個變量組成:未調整用例點(unadjustedusecasepoint,簡稱UUCP)、技術復雜度因子(technicalcomplexityfactor,簡稱TCF)和環境復雜度因子(environmentcomplexityfactor,簡稱ECF).5軟件本錢估算方法的評價與應用軟件本錢估算方法、技術和工具種類很多,如何客觀地評價和比較,以指導實際應用？Briand等人的3組軟件估算評價標準:(1)模型與估算的標準(modelandestimatecriteria),包括模型與估算的質量、所需輸入變量、估算的完整性、估算類型、校準、可解釋性等;(2)估算方法的標準(estimationmethodcriteria),包括假設、可重復性、復雜度、建模自動化、透明性等;(3)運用的標準(applicationcriteria),包括運用范圍、通用性、全面性、估算的可行性、方法使用的自動化等.自定義三段式評價標準估算輸入(1)易理解性(comprehensiveness):用戶是否能夠清楚了解估算方法所需各項輸入的定義與要求.(2)信息可得性(accessibility):所需輸入的信息是否能在估算階段實際得到,而不是直到工程完成才能給出.(3)客觀性(objectivity):能否盡量減少需用戶主觀判斷的信息.(4)精簡性(parsimony):是否排除了不必要信息輸入以及對結果影響不大的因素.估算過程(5)科學性(scientificalness):估算所使用的分析方法或數據處理方法是否有理有據,是否對根底假設條件沒有異議.(6)可重復性(repeatability):估算過程的描述是否足夠詳盡和清晰,是否可防止在應用時產生主觀上的理解誤差.(7)可持續性(sustainableness):能否通過對相關參數的調整和組織內的校準,使得估算方法能夠應對變更性增強、時效性延長等問題.估算輸出(8)信息全面性(completeness):提供的輸出是否可滿足用戶所需信息范圍的要求.(9)結果可信度(reliability):得到的估算結果是否能夠可信以及如何得到驗證.5.1系統規模估算對某“政府支持工程申報管理系統〞進行規模及本錢估算.其中,規模估算方法采用國際功能點用戶組IFPUG提出的功能點分析方法本錢估算那么是基于COCOMOII,借鑒了國外軟件采購方面的方法,并且基于國內政府數據、國內外工業界數據和國際基準數據等數據,所建立的適合中國政府軟件合同定價的方法.根據系統的需求確認書、系統架構圖和系統數據表,用開發的功能點估算工具進行了規模估算經過規模估算,該系統有138個未調整功能點5.2系統本錢估算我們利用所開發的軟件本錢估算與預算評估系統對“政府支持工程申報管理系統〞進行了本錢估算.如圖6所示為該系統的本錢估算界面.該系統包括一個基準庫.該基準庫中共有500多個工程,這些工程來自于ISBSG、本實驗室示范應用企業以及工程委托單位的歷史工程.計算過程是,首先根據系統規模信息,估算“政府支持工程申報管理系統〞所需的工作量,同時根據美國軟件生產率研究所的標桿數據[54],確定各類型軟件開發人員在軟件開發總工作量中所完成的比重.然后根據國內各類型軟件開發人員的參考工資率,再估算該系統的人力本錢.經過估算,該系統規模有138個未調整功能點,總工作量為3.7人月,總進度為5.4月,最可能的總人力本錢為2.83萬元人民幣軟件本錢估算方法的未來開展趨勢(1)估算模型:不斷會有新的軟件本錢估算模型和估算方法被提出,既會是對以往模型的有益補充,也可能帶來新的不適應.實際上,沒有一種模型或方法明顯優于其他模型或方法.如何根據具體應用背景與條件,在軟件開發過程的不同階段,評價和選擇適合的軟件本錢估算模型與方法,特別是這些模型與方法的適當組合應用及兼容性問題,將一直是軟件開發過程管理的首要問題.(2)估算演進:期望一次估算就非常準確是不現實的.由于影響本錢的軟件規模、工程風險和技術復雜度等信息,隨著軟件生命周期的演進而逐漸確定或始終動態變化,本錢估算模型需要能適應并表達軟件開發動態演進的特征,特別需要在軟件開發早期大量信息不確定的情況下進行合理估算并評估其可靠程度.同時,軟件開發技術的進步、軟件開發工具的普及、軟件應用