基于UML與IFPUG功能點(diǎn)度量的裝備軟件計(jì)價(jià)方法研究*

邱勇強(qiáng)

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

?

基于UML與IFPUG功能點(diǎn)度量的裝備軟件計(jì)價(jià)方法研究*

邱勇強(qiáng)

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

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

裝備軟件; 功能點(diǎn)度量; 計(jì)價(jià); UML; IFPUG

Class Number E92

1 引言

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

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

2 IFPUG功能點(diǎn)度量

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

2.1 度量元素

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

1) 內(nèi)部邏輯文件(ILF)。用戶確認(rèn)的、在應(yīng)用程序內(nèi)部維護(hù)的、邏輯上相關(guān)的數(shù)據(jù)塊或控制信息。

2) 外部接口文件(EIF)。由用戶確認(rèn)的、被度量的應(yīng)用程序引用,但是在其他應(yīng)用程序內(nèi)部維護(hù)、邏輯上相關(guān)的數(shù)據(jù)塊或控制信息。

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

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

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

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

2.2 度量過程

IFPUG功能點(diǎn)分析法包括以下步驟:

1) 識別計(jì)算范圍和應(yīng)用邊界。即明確哪些功能屬于本次計(jì)算的應(yīng)用內(nèi)部,哪些功能屬于應(yīng)用外部。

2) 計(jì)算未調(diào)整功能點(diǎn)數(shù)(Unadjusted Function Point,UFP)。數(shù)據(jù)型功能點(diǎn)和事務(wù)型功能點(diǎn)的總和稱為未調(diào)整功能點(diǎn)。

3) 根據(jù)系統(tǒng)性能要求確定功能點(diǎn)調(diào)整系數(shù)(Value Adjustment Factor,VAF)。

4) 計(jì)算調(diào)整后的功能點(diǎn)數(shù)(Adjusted Function Point,AFP)。

3 基于UML建模的IFPUG功能點(diǎn)度量方法

裝備軟件作為軍事系統(tǒng)的特殊專用軟件,除了具有高可靠性、高安全性、高實(shí)時性、高保密性外,且軟件規(guī)模龐大,主要表現(xiàn)為需求多樣,接口復(fù)雜,軟件模型繁多,信息交換與處理量大等特點(diǎn),這決定了面向過程的方法已無法完成大規(guī)模裝備應(yīng)用程序的開發(fā)。當(dāng)前,裝備軟件開發(fā)主要基于面向?qū)ο?、組件、構(gòu)件以及com技術(shù)等具有較強(qiáng)移植性和可重復(fù)性的開發(fā)技術(shù)。

UML是一種通用的可視化標(biāo)準(zhǔn)建模語言,它支持面向?qū)ο蟮姆治鲈O(shè)計(jì)和從需求分析開始的軟件開發(fā)的全過程[8]?；谒x良好、易于表達(dá)、通用統(tǒng)一等特點(diǎn)能很好地在項(xiàng)目各個階段用圖形化方法進(jìn)行描述,為客觀、可比較、自動化地度量面向?qū)ο筌浖δ芤?guī)模提供了一種有利手段。本文抽取UML中最常用的三種工件——用例圖、類圖和順序圖進(jìn)行功能點(diǎn)分析,并結(jié)合IFPUG功能點(diǎn)度量步驟,詳細(xì)描述基于UML建模的功能點(diǎn)數(shù)量估算方法。

3.1 建立用例模型識別計(jì)算范圍和應(yīng)用邊界

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

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

圖1 用例圖

3.2 建立靜態(tài)、動態(tài)模型識別未調(diào)整功能點(diǎn)

3.2.1 利用類圖識別數(shù)據(jù)型功能點(diǎn)數(shù)

UML建模中的類圖是一種靜態(tài)結(jié)構(gòu),它描述系統(tǒng)所需的類及其相互之間的各種關(guān)系,按UML標(biāo)準(zhǔn)劃分為三種版型:邊界類(boundary class)、控制類(control class)和實(shí)體類(entity class)。邊界類用來建立系統(tǒng)和參與者之間的交互關(guān)系,位于系統(tǒng)與系統(tǒng)邊界的交界處,包括所有窗口、報(bào)表、與外部系統(tǒng)的接口和與打印機(jī)等硬件的接口等,每一個邊界類至少與一個參與者相聯(lián)系。實(shí)體類用來保存系統(tǒng)的持久信息,通常表示一個邏輯的數(shù)據(jù)結(jié)構(gòu),有利于理解系統(tǒng)所需要的信息?？刂祁愗?fù)責(zé)協(xié)調(diào)其它類的工作,每個用例一般有一個控制類,用來控制用例中事件發(fā)生的順序。

1) 確定數(shù)據(jù)類型及個數(shù)

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

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

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

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

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

2) 確定數(shù)據(jù)復(fù)雜度

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

(1)關(guān)聯(lián)關(guān)系復(fù)雜度判定。如果關(guān)聯(lián)是單值的(如1和0..1),則被計(jì)算為一個DET,多值關(guān)聯(lián)則被計(jì)算為一個RET。

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

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

根據(jù)IFPUG給出的ILF、EIF、DET、FTR個數(shù)與復(fù)雜度關(guān)系的判定表得到復(fù)雜度等級,見表1,再根據(jù)復(fù)雜度等級權(quán)值計(jì)算未調(diào)整的數(shù)據(jù)型功能點(diǎn)個數(shù)。

表1 ILF/EIF復(fù)雜度判定表

3.2.2 利用順序圖識別事物型功能點(diǎn)數(shù)

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

1) 確定事物類型及個數(shù)

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

由參與者發(fā)送一條消息給對象,且每條消息的參數(shù)一樣,則該消息類型為EI,計(jì)為一個EI。

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

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

(3)組合型消息模式

參與者向?qū)ο蟀l(fā)送一條消息,并得到一條返回消息,此模式是前兩種消息傳遞模式的組合。如果返回消息的參數(shù)與實(shí)體對象的屬性相同,則該消息類型為EQ,兩條消息計(jì)為一個EQ,否則該消息類型為EO,兩條消息計(jì)為一個EO。此模式?jīng)]有計(jì)EI個數(shù)的原因是包含在查詢或者輸出中的輸入請求不應(yīng)識別為EI。

(4)混合型消息模式

參與者向?qū)ο蟀l(fā)送消息,并從多個對象得到返回消息,此模式是前三種消息傳遞模式的組合,具體情況按照上述三種模式進(jìn)行處理。

圖2綜合了四種消息傳遞模式,下面對事物型功能點(diǎn)數(shù)的計(jì)算方法進(jìn)一步詳細(xì)說明。

圖2 混合型消息模式

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

2) 確定事物復(fù)雜度

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

表2 EI復(fù)雜度判定表

表3 EO/EQ復(fù)雜度判定表

3.3 確定功能點(diǎn)調(diào)整系數(shù)

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

表4 重要程度評級

調(diào)整系數(shù)的計(jì)算公式如式(1):

(1)

VAF為功能點(diǎn)調(diào)整系數(shù),Fi為14個調(diào)整因子的評分值。

3.4 計(jì)算調(diào)整后的功能點(diǎn)數(shù)

調(diào)整后的功能點(diǎn)數(shù)由式(2)計(jì)算:

AFP=UFP×VAF

(2)

AFP為調(diào)整后的功能點(diǎn)個數(shù),UFP為未調(diào)整的功能點(diǎn)個數(shù)。

4 應(yīng)用實(shí)例分析

裝備軟件開發(fā)成本由直接成本與間接成本構(gòu)成。直接成本主要指軟件開發(fā)人員工資費(fèi),間接成本包括設(shè)計(jì)費(fèi)、材料費(fèi)、外協(xié)費(fèi)、專用費(fèi)、測試費(fèi)、試驗(yàn)費(fèi)、會議費(fèi)、差旅費(fèi)、專家咨詢費(fèi)、固定資產(chǎn)使用費(fèi)和管理費(fèi)等。本文的方法適用于直接成本的估算,間接成本不是本文考慮的范圍,即下文出現(xiàn)的軟件成本均指直接成本。

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

4.1 度量功能點(diǎn)個數(shù)

利用本文模型和方法進(jìn)行功能點(diǎn)度量,得到的度量結(jié)果如表5、表6所示。

表5 未調(diào)整功能點(diǎn)數(shù)計(jì)算

表6 特征值評分結(jié)果

4.2 估算軟件成本

本案例采用目前在業(yè)界影響最大、最具代表性、最準(zhǔn)確的構(gòu)造性成本模型COCOMOⅡ進(jìn)行軟件成本估算。工作量計(jì)算公式為

(3)

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

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

5 結(jié)語

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

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

[2] 吳琴,吳龍祥.裝備軟件計(jì)價(jià)依據(jù)與工作現(xiàn)狀分析[J].民營科技,2014,4:252

[3] 孫偉華.軟件評估方法及其應(yīng)用[D].北京:北京交通大學(xué),2013.

[4] 姚偉春,計(jì)春雷.基于UML技術(shù)的功能點(diǎn)規(guī)模度量研究[J].上海電機(jī)學(xué)院學(xué)報(bào),2008,11(2):128-133

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

[6] 于洪玉,孟慶順,楊富玉.應(yīng)用IFPUG功能點(diǎn)分析方法進(jìn)行軟件規(guī)模估算實(shí)踐[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ì)春雷,肖薇.統(tǒng)一建模語言的全功能點(diǎn)度量方法[J].上海電機(jī)學(xué)院學(xué)報(bào),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建模技術(shù)的功能點(diǎn)度量研究[J].小型微型計(jì)算機(jī)系統(tǒng),2007,28(9):1660-1664.

[11] 郭薇,李想,曾斌.面向軍用軟件的COCOMOⅡ改進(jìn)模型研究[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日

邱勇強(qiáng),男,碩士,高級會計(jì)師,研究方向:裝備經(jīng)濟(jì)管理。

E92

10.3969/j.issn.1672-9730.2015.09.025