基于UML與IFPUG功能點度量的裝備軟件計價方法研究*

邱勇強

(海軍裝備部裝備采購中心 北京 100841)

?

基于UML與IFPUG功能點度量的裝備軟件計價方法研究*

邱勇強

(海軍裝備部裝備采購中心 北京 100841)

隨著裝備費用需求的不斷增加,裝備軟件單獨計價顯得非常必要。如何客觀、準確地計算軟件成本,已成為亟待解決的問題。論文結合裝備軟件自身的特點,提出了基于UML建模的IFPUG功能點度量方法,闡述了利用UML中最常用的用例圖、類圖和順序圖三種工件進行功能點度量的方法和步驟,并在某裝備軟件項目計價活動實施應用,初步驗證了其有效性。

裝備軟件; 功能點度量; 計價; UML; IFPUG

Class Number E92

1 引言

隨著我國國防信息化裝備進入高新技術時代,裝備軟件已成為現代化武器裝備的“大腦”和“靈魂”,是構筑信息化、網絡化、智能化新型裝備體系的關鍵要素,為提升裝備整體作戰效能提供保證[1]。在裝備軟件含量逐年增大的同時,費用需求也在不斷增加,軍用裝備研制和生產定價的相關管理辦法都沒有軟件費用的專項規定,造成裝備軟件計價工作沒有標準可以參照的局面,使得軍隊信息化成本難以計算,對軍隊信息化的科學規劃和頂層設計造成了障礙[2],不僅影響到軍費的使用效率,還必將阻礙軍隊信息化的發展進程。因此,如何建立一套科學度量裝備軟件成本和價格審核的體系成為亟待解決的問題。

做好裝備軟件價格估算需特別關注軟件規模度量問題,它是估算軟件開發工作量、成本與資源需求的基礎,正確度量并估算軟件規模是準確估算軟件開發成本的重要前提。軟件規模估算方法主要有類比評估法、代碼行評估法、功能點分析法[3]。類比法依賴于估算人員的經驗和歷史數據,受人員的經驗和主觀意志約束,缺乏科學性、客觀性和標準性;代碼行評估法依賴于程序設計語言,同一軟件使用不同程序語言的代碼行數不一樣,采用這兩種方法的估算結果偏差較大。功能點分析法是從用戶的角度去度量一個軟件項目功能規模的一種方法,其最大程度地突破了傳統估算方法的局限,能夠不依賴于外部條件,與軟件開發語言及源代碼無關,在軟件開發初期就能進行功能規模的度量[4],且有國際性組織IFPUG負責標準制訂與推動事宜,具有客觀公正性。因此,通過功能點分析法度量裝備軟件規模,推算工作量,再計算軟件成本,能得到較準確、客觀、合理的裝備軟件價格。

2 IFPUG功能點度量

功能點分析法(Function Point Analysis,FPA)在1979年由IBM研究員Allan Albrecht首次提出,隨后被IFPUG(International Function Point Users Group)繼承,1999年發布了4.1版。2003年10月,國際標準化組織正式接納認可了《國際功能點協會(IFPUG)4.1版本未調整功能點計算手冊》,正式的國際標準編號是ISO/IEC20926:2003[5]。該方法目前在軟件行業應用最為廣泛,是一種與軟件實現語言、系統開發方法論和開發團隊的技術能力無關,從用戶的角度出發,以軟件功能性為尺度來度量和估算應用軟件規模的方法,易于理解,應用便捷[6]。

2.1 度量元素

IFPUG功能點分析法從用戶角度出發,將功能點分為五類,即內部邏輯文件(Internal Logical File,ILF)、外部接口文件(External Interface File,EIF)、外部輸入(External Input,EI)、外部輸出(External Output,EO)和外部查詢(External Query,EQ)。其中,ILF和EIF屬于數據類型的功能點,EI、EO、EQ屬于事物類型的功能點。

1) 內部邏輯文件(ILF)。用戶確認的、在應用程序內部維護的、邏輯上相關的數據塊或控制信息。

2) 外部接口文件(EIF)。由用戶確認的、被度量的應用程序引用,但是在其他應用程序內部維護、邏輯上相關的數據塊或控制信息。

3) 外部輸入(EI)。數據由外向內跨越邊界的基本處理過程。

4) 外部輸出(EO)。應用程序向其邊界之外提供數據或控制信息的基本處理過程。

5) 外部查詢(EQ)。應用程序向其邊界之外提供數據或控制信息查詢的基本處理過程。

每個ILF和EIF都必須根據相關的數據元素類型(Data Element Type,DET)和記錄元素類型(Record Element Type,RET)被賦予一個功能復雜度,同樣地,每個EI、EO、EQ也須根據所涉及的引用文件類型(File Type Referenced,FTR)和數據元素類型(DET)數量確定復雜度,按照低、平均、高三個復雜度級別確定功能點數[7]。

2.2 度量過程

IFPUG功能點分析法包括以下步驟:

1) 識別計算范圍和應用邊界。即明確哪些功能屬于本次計算的應用內部,哪些功能屬于應用外部。

2) 計算未調整功能點數(Unadjusted Function Point,UFP)。數據型功能點和事務型功能點的總和稱為未調整功能點。

3) 根據系統性能要求確定功能點調整系數(Value Adjustment Factor,VAF)。

4) 計算調整后的功能點數(Adjusted Function Point,AFP)。

3 基于UML建模的IFPUG功能點度量方法

裝備軟件作為軍事系統的特殊專用軟件,除了具有高可靠性、高安全性、高實時性、高保密性外,且軟件規模龐大,主要表現為需求多樣,接口復雜,軟件模型繁多,信息交換與處理量大等特點,這決定了面向過程的方法已無法完成大規模裝備應用程序的開發。當前,裝備軟件開發主要基于面向對象、組件、構件以及com技術等具有較強移植性和可重復性的開發技術。

UML是一種通用的可視化標準建模語言,它支持面向對象的分析設計和從需求分析開始的軟件開發的全過程[8]。基于它定義良好、易于表達、通用統一等特點能很好地在項目各個階段用圖形化方法進行描述,為客觀、可比較、自動化地度量面向對象軟件功能規模提供了一種有利手段。本文抽取UML中最常用的三種工件——用例圖、類圖和順序圖進行功能點分析,并結合IFPUG功能點度量步驟,詳細描述基于UML建模的功能點數量估算方法。

3.1 建立用例模型識別計算范圍和應用邊界

用例模型由兩個元素組成,一是參與者(Actor),二是用例(Use Case)。參與者是通過向系統輸入或請求系統輸出某些事件來觸發系統的執行。通常是人所擔當的角色,但也可以是任何類型的系統;用例是用戶與系統進行的一個交互,這個交互是為了達到某個目標所執行的一系列動作。用例模型能很好地描述系統外部行為者與系統所提供的用例之間的聯系[9],IFPUG功能點分析法所定義的邊界也指的是度量軟件和用戶之間的界限。因此,可以通過用例模型確定系統的邊界。

在建立用例模型時,用例圖方框中的每一個用例均在系統的邊界內,方框外的參與者都在系統的邊界外,這樣就確定了要度量的系統邊界,如圖1所示。

圖1 用例圖

3.2 建立靜態、動態模型識別未調整功能點

3.2.1 利用類圖識別數據型功能點數

UML建模中的類圖是一種靜態結構,它描述系統所需的類及其相互之間的各種關系,按UML標準劃分為三種版型:邊界類(boundary class)、控制類(control class)和實體類(entity class)。邊界類用來建立系統和參與者之間的交互關系,位于系統與系統邊界的交界處,包括所有窗口、報表、與外部系統的接口和與打印機等硬件的接口等,每一個邊界類至少與一個參與者相聯系。實體類用來保存系統的持久信息,通常表示一個邏輯的數據結構,有利于理解系統所需要的信息。控制類負責協調其它類的工作,每個用例一般有一個控制類,用來控制用例中事件發生的順序。

1) 確定數據類型及個數

數據型功能點ILF和EIF的計數主要由實體類來計算,在實際的計算過程中,并不是每一個實體類都計算為一個ILF或EIF,需根據實體類的關聯、聚合、組合、泛化關系的不同進行識別,方法描述如下[10]:

(1)關聯關系文件映射方法。如果一個實體類與其他類存在關聯關系,不存在聚合、組合和泛化關系,則該實體類計算為一個ILF或EIF。

(2)聚合關系文件映射方法。如果一個實體類與其他類之間存在聚合關系,即整體與部分共存亡,則將從最低層次到最高層次整體組成結構計算為一個ILF或EIF。

(3)組合關系文件映射方法。如果一個實體類與其他類之間存在組合關系,則將從最低層次到最高層次整體組成結構計算為一個ILF或EIF。

(4)泛化關系文件映射方法。如果一個實體類與其他類之間存在繼承關系,則要根據父類是否是抽象類來計算。如果父類是抽象類,則不將其計算為ILF或EIF;如果父類是具體類,則將父類計算為一個ILF或EIF。另外,參考需求規格說明書,將需要分開的類分別計算為ILF或EIF,而不是簡單地將所有的繼承層次上的類集合都看成是一個ILF或EIF。

2) 確定數據復雜度

根據IFPUG的FPA手冊可知,ILF和EIF的復雜度是由DET和RET確定的。一般地,一個ILF或EIF的DET相當于該文件對應類的屬性,它的計數等于該類所有屬性的計數,如果類的屬性是類類型或另一個類的引用,被計為一個RET。具體的計算規則需要根據類關系的不同進行判定。

(1)關聯關系復雜度判定。如果關聯是單值的(如1和0..1),則被計算為一個DET,多值關聯則被計算為一個RET。

(2)聚合、組合關系復雜度判定。如果一個ILF或EIF包含聚合、組合關系類,DET的計數等于整體類與每個聚集類的屬性個數之和,并將每一層的每一部分類分別計算為最高整體類的一個RET。

(3)泛化關系復雜度判定。如果一個ILF或EIF包含泛化關系類,不管父類是否為抽象類,均將父類計算為繼承它的每1個具有實例化子類的一個RET。DET的計數等于父類與每個具體子類的屬性個數之和。

根據IFPUG給出的ILF、EIF、DET、FTR個數與復雜度關系的判定表得到復雜度等級,見表1,再根據復雜度等級權值計算未調整的數據型功能點個數。

表1 ILF/EIF復雜度判定表

3.2.2 利用順序圖識別事物型功能點數

用例視圖是被稱為參與者的外部用戶所能觀察到的系統功能的模型圖,每個用例描述了系統提供的功能性需求,事物(EI、EO、EQ)的個數可以由用例模型來確定,但用例模型對事物描述略粗,往往一個用例可能對應若干個事物,因此,具體的個數應由描述用例行為的順序圖來計算。通過統計順序圖中消息及參數的個數來計算事物型功能點個數,由參與者發送給邊界類的消息和由邊界類發送給參與者的消息為事物識別的范圍,但是并非每個消息都計算為一個事務。下面通過分析順序圖中各種消息交互傳遞的模式來確定事物類型、個數及復雜度(DET、FTR)。

1) 確定事物類型及個數

(1)外部輸入型消息模式

由參與者發送一條消息給對象,且每條消息的參數一樣,則該消息類型為EI,計為一個EI。

(2)外部查詢、外部輸出型消息模式

對象發送一條消息給參與者,如果消息的所有參數都是對象的屬性,則該消息類型為EQ,計為一個EQ;如果消息的參數包含但不全部是對象的屬性,則該消息類型為EO,計為一個EO。

(3)組合型消息模式

參與者向對象發送一條消息,并得到一條返回消息,此模式是前兩種消息傳遞模式的組合。如果返回消息的參數與實體對象的屬性相同,則該消息類型為EQ,兩條消息計為一個EQ,否則該消息類型為EO,兩條消息計為一個EO。此模式沒有計EI個數的原因是包含在查詢或者輸出中的輸入請求不應識別為EI。

(4)混合型消息模式

參與者向對象發送消息,并從多個對象得到返回消息,此模式是前三種消息傳遞模式的組合,具體情況按照上述三種模式進行處理。

圖2綜合了四種消息傳遞模式,下面對事物型功能點數的計算方法進一步詳細說明。

圖2 混合型消息模式

由圖2可知,該順序圖有三個消息序列,即第一個為message1、message2、message3,第二個為message4、message5、message6、message7、message9、message10、message11,第三個為message7、message12、message13。第一個消息序列是由參與者發送一條消息給對象,且每條消息的參數一樣,符合外部輸入型傳遞模式,計為1個EI;第二個消息序列是由參與者向對象發送一條消息,并得到一條返回消息,屬于組合型傳遞模式,如果實體對象1、實體對象2的屬性只有arg5和arg6,那么計為一個EQ,如果實體對象1、實體對象2的屬性包含arg5和arg6,那么計為一個EO;第三個消息序列是由對象發送一條消息給參與者,符合外部查詢、外部輸出型傳遞模式,同樣地,如果實體對象1的屬性只有arg7和arg8,那么計為一個EQ,如果實體對象1的屬性包含arg5和arg6,那么計為一個EO。

2) 確定事物復雜度

事物(EI、EO、EQ)的復雜度由DET、FTR決定。首先確定DET和FTR的個數,DET的數目由消息中屬于實體對象的屬性的參數個數決定,FTR則是參與消息交換的實體對象的個數決定,再根據IFPUG給出的EI、EO、EQ、DET、FTR個數與復雜度關系的判定表得到復雜度等級,見表2、表3,然后根據復雜度等級與權值的對照表計算各類型事物功能點值,進而計算未調整事物型功能點數。

表2 EI復雜度判定表

表3 EO/EQ復雜度判定表

3.3 確定功能點調整系數

考慮到系統的一些非功能性指標要求會影響系統開發的復雜度和工作量投入。在IFPUG功能點分析方法中,通過調整系數來對整體功能點個數進行調整。調整系數的計算涉及14個系統基本特征值(General System Characteristics,GSC),即數據通信、分布式處理、性能、配置負載、交易率、在線數據輸入、最終用戶效率、在線更新、復雜處理、可重用性、易安裝、易操作、多場所、支持變更。對每個調整因子進行評分,評分標準如表4所示。

表4 重要程度評級

調整系數的計算公式如式(1):

(1)

VAF為功能點調整系數,Fi為14個調整因子的評分值。

3.4 計算調整后的功能點數

調整后的功能點數由式(2)計算:

AFP=UFP×VAF

(2)

AFP為調整后的功能點個數,UFP為未調整的功能點個數。

4 應用實例分析

裝備軟件開發成本由直接成本與間接成本構成。直接成本主要指軟件開發人員工資費,間接成本包括設計費、材料費、外協費、專用費、測試費、試驗費、會議費、差旅費、專家咨詢費、固定資產使用費和管理費等。本文的方法適用于直接成本的估算,間接成本不是本文考慮的范圍,即下文出現的軟件成本均指直接成本。

下面以某裝備軟件研制為例,驗證本文的模型和方法在裝備軟件計價方面的有效性。首先需明確用戶需求,建立用例模型,以確定系統的邊界,再利用類圖建立靜態模型,識別數據型功能點,然后利用順序圖建立動態模型,識別事務型功能點,通過計算調整系數,確定調整后的功能點數,以功能點數作為軟件計價的輸入,最終確定軟件成本。

4.1 度量功能點個數

利用本文模型和方法進行功能點度量,得到的度量結果如表5、表6所示。

表5 未調整功能點數計算

表6 特征值評分結果

4.2 估算軟件成本

本案例采用目前在業界影響最大、最具代表性、最準確的構造性成本模型COCOMOⅡ進行軟件成本估算。工作量計算公式為

(3)

式(3)中,Effort以人月為單位的工作量,Size是以千源代碼行計數的程序規模,EMi是從公認的值表中得到的成本驅動因子的值,a和b是兩個隨開發模式而變化的因子[11]。

該裝備軟件的開發語言是C++,代碼行轉換系數為29,即該軟件規模為208.69千行代碼,依照式3,計算得到工作量為343.15人月,平均人力成本費率19000元/月,最終用本文方法估算的軟件價格為652萬元,該軟件的真實成本為730萬。由計算結果可知,采用本文方法計算的裝備軟件計價誤差在10.68%,可以很好地滿足裝備軟件計價需求,表明了本文方法的有效性,有較高的應用價值。

5 結語

隨著軟件在武器裝備系統中的重要性越來越突出,武器裝備系統全壽命費用中軟件費用所占比例也越來越大,裝備軟件單獨計價已顯得十分必要。本文結合裝備軟件自身的特點利用UML用例模型確定系統邊界,再采用類圖、順序圖分別建立靜態模型和動態模型進行功能點分析,并與IFPUG定義的功能點度量方法相結合,進行了基于UML建模的功能點規模度量實例分析,最后采用COCOMOⅡ模型進行軟件成本估算。實例分析結果表明該方法在一定程度上緩解了功能分解隨意性較大的問題,估算結果較準確,對實際中軍工企業裝備軟件計價具有較強的指導意義。

[1] 顧利剛,徐衛東.裝備軟件成本測算工作的思考[J].上海船舶運輸科學研究所學報,2014,37(4):79-82.

[2] 吳琴,吳龍祥.裝備軟件計價依據與工作現狀分析[J].民營科技,2014,4:252

[3] 孫偉華.軟件評估方法及其應用[D].北京:北京交通大學,2013.

[4] 姚偉春,計春雷.基于UML技術的功能點規模度量研究[J].上海電機學院學報,2008,11(2):128-133

[5] 馬賢穎,張敏,董石磊.功能點估算方法研究及應用[J].現代電子技術,2011,34(8):58-61

[6] 于洪玉,孟慶順,楊富玉.應用IFPUG功能點分析方法進行軟件規模估算實踐[J].金融電子化,2010,11:73-75

[7] Caldiera G, Antoniol G, Fiutem R, et al. Definition and Experimental Evaluation of Function Points for Object-oriented Systems[C]//IEEE Proceedings of 5thInternational Software Metrics Symposium. Bethesda, Maryland: IEEE,1998:167-178.

[8] 計春雷,肖薇.統一建模語言的全功能點度量方法[J].上海電機學院學報,2011,14(5):319-324.

[9] Mohammad Azzeh. Software Cost Estimation Based on Use Case Points for Global Software Development[C]//2013 5thInternational Conference on Computer Science and Information Technology(CSIT),2013:214-218.

[10] 李師賢,程利,杜云梅,等.基于UML建模技術的功能點度量研究[J].小型微型計算機系統,2007,28(9):1660-1664.

[11] 郭薇,李想,曾斌.面向軍用軟件的COCOMOⅡ改進模型研究[J].艦船電子工程,2014,34(1):104-107.

Equipment Software Cost Estimation Based on UML and IFPUG Function Point Analysis

QIU Yongqiang

(Procurement Center of Naval Equipment Department, Beijing 100841)

With the increasing demand for equipment cost, equipment software cost alone is valued necessarily. How to objectively and accurately estimate software cost has become a serious problem. Combined with its own characteristics of equipment software, the paper presents the approach of IFPUG function point estimation based on UML modeling, and expounds methods and procedures of function point estimation using three common artifacts such as use case diagram, class diagram and sequence diagram. The validity of the approach, which is implemented in the estimation activity of equipment software project, has been validated preliminarily.

equipment software, function point estimation, cost estimation, UML, IFPUG

2015年3月2日,

2015年4月27日

邱勇強,男,碩士,高級會計師,研究方向:裝備經濟管理。

E92

10.3969/j.issn.1672-9730.2015.09.025