汪福明



摘要摘要:COSMIC功能點度量算法作為IFPUG度量算法的擴展,在軟件項目早期預估中起著非常重要的作用,同時軟件項目對早期度量精度和準確度的要求也越來越高。針對早期功能點度量算法COSMIC方法在預估過程中準確性不足的缺點,提出通過增加調整因子來提高軟件項目度量的準確性。該方法通過增加復雜度、可重用性和效能3個調整因子來調整實際度量的功能點總數,提高度量的準確性,避免了因功能點數不足帶來的誤差。
關鍵詞關鍵詞:早期快速預估;軟件度量;COSMIC方法;非功能性需求
DOIDOI:10.11907/rjdk.162292
中圖分類號:TP302文獻標識碼:A文章編號文章編號:16727800(2017)001001104
0引言
項目規模預估作為軟件項目管理過程中非常重要的環節,它是后續項目計劃編制和人員預算安排的重要依據和基礎。在一些研發型的軟件項目或者是軟件項目的立項評審階段,由于軟件項目目標的不準確性、需求的多變性和項目功能的漸近性,只能粗略地定義項目需求[1],同時標準的估算方法此時并不適用在項目的早期階段,而且在項目的早期進行標準的度量往往也是不經濟、合算的[2]。因而需要一種有效、快速并相對精確的項目估算方法來進行軟件項目規模的度量。
軟件項目規模的度量主要有定量預估方法和定性預估方法,包括DELPHI法、類比法、功能點分析方法、經驗法、COCOMO法、代碼行評估法等。目前對軟件規模度量的主流方法是功能點方法,功能點方法根據軟件項目的功能性需求來度量軟件的規模大小[3]。功能點早期估算方法在軟件早期規模度量中占有重要地位。
主流早期功能點方法包含COSMIC估算方法、NESMA方法、IFPUG方法、Mark Ⅱ方法、FISMA方法等。不同的方法適用范圍不同,根據相關國際標準中的方法適用范圍聲明,IFPUG適用于所有類型軟件系統;NESMA與IFPUG非常類似,但對功能點計數作了分級,以便在測算的不同時期選擇不同精度的方法進行度量,MK Ⅱ方法適用于邏輯事務能被確定的軟件系統。FISMA方法可用于度量所有類型的軟件,與其它功能點方法的不同之處在于它是面向服務而非面向過程的。
相比其它功能點估算方法,COSMIC方法適用的項目類型更多樣,它為業務應用軟件或MIS軟件、實時軟件、基礎設施軟件以及一些科學或工程軟件提供了一種度量軟件功能規模的標準方法。它計數規則相對簡單、學習成本低,可以在項目早期比較快速地對項目規模進行度量[4]。但是COSMIC方法不適合復雜算法系統和連續變量系統的處理,比如天氣預報、聲音和圖像處理系統等。
本文研究分析了非功能性需求對度量規模的影響,通過增加重用率、效能、復雜度調整因子對功能模組進行加權處理來改進COSMIC方法,提高估算的準確性。并通過一些項目的數據,驗證該方法確實提高了軟件度量的有效性和準確性。
1COSMIC方法簡介
COSMIC方法又叫全功能點方法,是由從Alain Abran博士的“全功能點”方法演化而來,并結合了Charles Symon的MarkⅡ功能點方法的一些思想,是IFPUG功能點方法的一種擴展。COSMIC方法是通過國際標準協會認證的5種標準度量方法之一。
COSMIC包含了應用一組模型、原則、規則和過程來度量給定軟件塊的功能性用戶需求(Function User Requirement,簡FUR)的方法。ISO定義的功能性用戶需求包含數據傳輸、數據變換、數據存儲和數據檢索[5]。1.1基本原理
COSMIC方法將軟件系統分解為若干功能過程并通過“數據移動”進行度量。本質上看,功能過程就是一個唯一的、內聚的、獨立并且可執行的數據移動集合。一個數據移動是一個數據組的傳輸,一個數據組是一個可區分的、非空的、無序且無冗余的數據屬性的集合。數據移動分為4種類型:數據入(Entry)、數據出(Exit)、讀(Read)和寫(Write),一個數據移動即為一個COSMIC功能點。
數據輸入是指功能用戶跨越被度量系統的邊界傳輸到系統內部的過程,這里的功能用戶是指與被度量的系統進行交互的自然人或物,可以是使用系統的終端用戶,也可以是其它系統和硬件設備;數據輸出是指一個數據組從一個功能過程移動到其他功能用戶;讀是指從持久性設備讀取數據組;寫是指將數據組寫到持久性設備。
一個功能過程至少從一個可識別出來的功能用戶需求(FUR)派生出來。功能用戶通過觸發事件作用于功能過程。當一個觸發事件發生時,一個功能過程就被執行。在COSMIC方法中,一個功能過程至少由兩個數據移動組成,比如一個數據輸入(Entry)加上一個數據輸出(Exit)。該方法的估算模型如圖1所示。
1.2度量過程
該方法度量過程分為三大階段,度量策略階段、映射階段和度量階段。度量策略階段主要用來闡述軟件功能4個關鍵的規模度量參數:度量目的、度量范圍、識別功能用戶和粒度級別。在映射階段,通過度量策略階段所完成的工作以及被度量軟件的功能用戶需求相關文檔,識別功能過程,進而識別數據組和數據屬性。COSMIC度量階段的主要任務是,根據COSMIC通用軟件模型所表示的功能用戶需求,識別數據移動及其數量,匯總所有數據移動的數量從而得到被度量軟件的功能規模。1.3功能點計算匯總
在COSMIC方法模型里,一個數據移動被認為是一個COSMIC功能點(Cosmic Function Point,CFP),CFP是COSMIC方法模型中標準的度量單位。通過計算軟件項目中所有“數據移動”的數量得到整個項目的功能規模[6]。在為每一個功能過程找到所有數據移動之后,將它們累加在一起就可以得到該功能過程的規模,如式(1):
Size(FPi)=Size(Entryi)+Size(Exiti)+Size(Readi)+Size(Writei)(1)
將所有功能過程的大小數值加以累計就可以得到整個軟件系統的度量規模。
度量功能過程時需要從FUR的角度進行,不同的角度度量的規模大小會不一致,用戶角度和開發人員角度所度量出來的結果是不一致的[7]。
1.4COSIMIC在具體軟件項目中的運用
對筆者參與過的8個軟件項目運用COSMIC方法進行軟件規模度量,這8個項目歷時3~6個月,開發團隊成員在2~6人,這8個項目中,調整了由于中途的需求變更帶來的CFP追加和減少的部分,并基于鄰近度的離群點檢測處理掉離群點[8]偏離比較大的項目,最后實際進入規模度量范圍的為5個項目。
對軟件進行規模度量時將總的CFP數轉換為實際的人月數,公式為:總人月數=總的CFP數/(生產率*每月工作日),生產率取值為0.8個功能點/人日,生產率從歷史數據中獲取。
統計學中,常用的誤差為相對誤差( Magnitude of Relative Error,簡稱MRE)。針對工作量估算,其計算方式為估算誤差絕對值除以實際工作量,如式(2):
MRE=|Effortactual-Effortestimated|/Effortactual(2)
其中,Effortestimated是改進后的估算方法得出的工作量值, Effortactual是實際工作量[9]。
登陸用戶名和密碼輸入用戶名和密碼數據入1從數據庫讀取用戶名和密碼信息用戶名和密碼讀1登陸成功進入指定界面數據出1顯示用戶名和密碼錯誤數據出1記錄登陸日志用戶名和密碼寫1從表2中對比可以看出,預估出來的度量工作量與實際工作量誤差較大,通過對偏差原因進行分析,發現同等粒度的每個功能點由于代碼模組重用率、不同復雜度和不同效能的要求引起實際所花費的工作量與預估的工作量偏差較大。
COSMIC方法是對軟件功能規模的間接性度量。其基礎是軟件功能需求分析,COSMIC方法度量的功能規模被設計成只與被度量軟件的FUR有關,而不依賴于實現FUR的需求和限制。因此它所度量的軟件規模是只反映了與軟件系統功能相關的那一部分,不包括系統的非功能性需求部分(Nonfunctional Requirement,簡稱NFR)[10]。
在實際軟件項目開發過程中,FUR被映射為COSMIC軟件模型前,度量者需要從軟件相關文檔提取FUR。實際發現,能夠從軟件相關文檔(如需求文檔、設計文檔)中將FUR與其它需求清楚地區分開并且表示成一種適合于直接度量的形式是比較難的。
研究表明,一些最初呈現為系統NFR的需求(如質量約束、環境約束)會隨著項目的進展演化為在軟件功能中可以實現并可以當作功能性需求度量的混合需求,比如要求更高的執行效率。特別是對質量和環境約束而言,這些在項目初期藏在NFR中的軟件功能,一旦被識別,就可以像對待別的軟件功能一樣,用COSMIC方法度量其規模。軟件規模會隨著項目進展不斷增長的原因之一就是沒有識別出這些隱藏的功能規模。NFR處理不當會導致項目失敗,或者導致相當大的延遲,其結果是成本的大幅增加[11]。在非業務軟件系統領域,NFR工作量能夠占到整個項目工作量的50%[12]。
2基于非功能性需求引入調整因子的改進預估模型2.1基本思路
在功能點方法的其它方法中,通過調整因子來對系統進行非功能性需求處理,COSMIC與IFPUG、MarkⅡ計算規則[1314]的對比如表3所示。
本研究結合ISO/IEC TR 14143-3:200質量標準[15],通過追加幾個調整因子來建立一個改進模型。
目前存在較多的調整因子被加入到預估模型中并已經被證明對預估結果有改進效果,這些調整因子包含了團隊規模、程序語言類型、組織類型、業務領域類型、應用程序類型以及開發平臺[16]。在基于IFPUG和MarkⅡ評估方法中,調整因子是基于基礎組件進行加權處理[17]。在該改進模型中,為了評估的準確性和一致性,評估的粒度也是基于基礎組件層面即COSMIC的功能過程。
2.2應用驗證
運用新的CFP計算公式(3),對5個項目重新計算,每個功能模組按基礎組件里CFP分別進行加權處理。首先按功能模組計算功能點數(見表1),然后對功能模組按基礎組件分別運用調整因子計算加權值(見表5),最后累加所有功能模組的功能點數即為優化后的功能點總數,并比對未調整前的功能點數(見表6)。具體運用規則舉例如表5所示。
運用以上優化規則,重新計算5個項目的預估工作量,并匯總計算結果;同時分析運用調整因子和未運用調整因子的工作量偏差原因,并對比結果,如表6所示。
通過對功能模組CFP加權后,總的CFP數有所增加,而這部分增加的CFP則是從非功能性需求分析中的重用率、復雜度和效能識別出來的,并轉換為可以度量其規模的功能點。
根據表6的偏差結果分析可知,CFP基數比較大的項目由于重用率大、相對較大的復雜度以及在效能方面更多的要求,引入調整因子后,工作量預估結果的相對偏差有明顯降低。這符合越大的項目在復雜度、效能以及重用率上的影響會更大,從非功能需求中轉換而產生的新功能點總數也會相應增加。
本文分析了非功能性需求部分對功能性需求的影響,并基于COSMIC方法增加了3個調整因子來改善軟件項目工作量預估偏差,3個調整因子從單個功能過程的粒度將功能過程的非功能性需求轉換為可以度量的功能點數,并且通過功能過程中數據入、數據出、讀和寫4個方面,能夠較為精確地控制和評估這些調整因子對功能過程的影響程度。相對于系統級評估調整因子對所有功能過程的影響,其準確度更高。
通過筆者實際參與的項目論證了調整因子對預估有一定的改善作用。但目前調整因子只使用了重用性、復雜性和效能3個影響系統的非功能需求因子,還未能覆蓋其它權重的因子。這是需要今后逐步改善和在實際軟件項目中繼續論證的部分。參考文獻參考文獻:
[1]盧向南.項目計劃與控制[M].北京:機械工業出版社,2009.
[2]朱安江.早期階段軟件規模估算方法研究與應用[D].長沙:國防科技大學,2011.
[3]蔣輝.COSMIC方法客觀性風險評估方法的研究與應用[D].長沙:國防科技大學,2008.
[4]羅懷勇.COSMIC方法研究及度量過程改進[D].長沙:國防科技大學,2010.
[5]方小龍.I F P U G功能點分析方法的研究與應用[D].長沙:國防科技大學,2007.
[6]SOUMAYA BARKALLAH,ABDELOUAHED GHERBI,ALAIN ABRAN.COSMIC functional size measurement using UML models[C].ASEA/DRBC/EL 2011, CCIS 25,Berlin Heidelberg:SpringerVerlag,2011:137146.
[7]王昕渝,侯紅,郝克剛.COSMICFFP方法的研究及應用[J].計算機應用與軟件,2008,25(10):1113.
[8]王茜,楊正寬.一種基于加權KNN的大數據集下離群檢測算法[J].計算機科學,2011,38(10):177180.
[9]SHEPPERD,M J MACDONELL S G.Evaluating prediction systems in software project estimation[J].Information & Software Technology,2012,54(8):820827.
[10]ISO/IEC 14143/1:2011.Software engineeringCOSMIC:a functional size measurement method[EB/OL].www.iso.org.
[11]MOHAMAD KASSAB,OLGA ORMANDJIEVA,MAYA DANEVA,et al.Nonfunctional requirements size measurement method(NFSM) with COSMICFFP[C].IWSMmensura 2007,LNCS 4895,Berlin Heidelberg:SpringerVerlag,2008:168182.
[12]LUIGI BUGLIONE,OLGA ORMANDJIEVA,and MAYA DANEVA.Using PSU for early prediction of COSMIC size of functional and nonfunctional requirements[C].IWSM/MetriKon/Mensura 2008,LNCS 5338,Berlin Heidelberg:SpringerVerlag,2008:352361.
[13]ISO/IEC IS 20926.Software engineeringifpug 4.1 unadjusted functional size measurement methodcounting practices manual,international organization for standardization[Z].2003.
[14]ISO/IEC IS 20968.Software engineeringMK II function point analysiscounting practices manual,international organization for standardization[Z].2002.
[15]ISO/IEC TR 141433.Information technologysoftware measurementfunctional size measurementpart 3:verification of functional size measurement methods[EB/OL].www.iso.org.
[16]LUIGI BUGLIONE,CIGDEM GENCEL.Impact of base functional component types on software functional size based effort estimation[C].PROFES 2008, LNCS 5089,Berlin Heidelberg:SpringerVerlag,2008:7589.
[17]蔣輝,尹俊文,何鴻君.功能點方法的分析與比較[J].計算機工程與科學,2009(31):8789.
責任編輯(責任編輯:孫娟)