改進的PROBE方法模型的在軟件項目規模估算中的應用

賈瑛

改進的PROBE方法模型的在軟件項目規模估算中的應用

賈瑛

結合在實際項目中的經驗對PROBE方法進行改進，并提出了一個改進的PROBE方法模型。模型以改進PROBE方法為核心，分理解需求分析并進行概念設計、產生規模相關表、確定新增部件規模、確定基礎和重用部件規模、估算非編程任務、選取合適的proxy、選擇規模估算規程方法、根據線性回歸方程確定項目規模等八個階段對部件如何獲取，如何編寫與組織，何時進入估算，估算的具體過程給出了全面的指導。

PROBE方法；部件規模；軟件規模；線性回歸

章編號：1007-757X(2016)11-0069-05

0 引言

目前，軟件規模估算思想和方法層出不窮，其中圍繞功能點分析展開的各種研究占據了前沿的位置，但是功能點分析只是軟件規模估算的程序規模因子如何切割和度量的一個研究焦點，軟件規模估算視角還涉及如何利用歷史數據、如何建立準確的評價體系、如何設定各因子的評分系數、如何將軟件規模估算契合到先進的軟件團隊開發流程中、如何在功能點分析這個理念指導下劃分規模因子、如何結合技術人員的技術能力和程序員心理度量軟件規模。本文提出基于改進的PROBE（全文）方法的軟件規模估算方法與PSP的計劃這一層次下軟件規模估算的關注視角相吻合，在其模型的基礎上改進多個關鍵因素，創建一個 PSP背景下的新的軟件規模估算方法，并用實例進行驗證其效果。

1 PROBE方法改進要素的研究

PROBE方法在計劃中的地位如圖1所示。在圖1中，用PROBE方法做估算時，需要比較這項工作和以前工作的歷史數據。在每一次估算前，要保證所使用的歷史數據是來自于類似項目的。

1.1 設計模式視角改進

圖1 PROBE方法估算流程

目前PROBE方法在提到概念設計的時候，只是簡單地提到要進行部件分解為具體項目用于后續proxy的確定。如何在概念設計階段劃分出真實可用的部件，就要結合設計模式思想、UML和前面提到的功能點法來分解部件。

首先要根據需求確定系統的邊界。通過UML工具建立用例圖，用例圖展示了系統外部行為者與系統所提供的用例

之間的聯系。第二步是計算文件數，進行基于類圖的ILF和EIF計數，根據內部邏輯文件（ILF）和外部接口文件（ElF）的特點，它們的計數主要由UML的類圖計算出來。第三步進行基于交互圖的El、EO和EQ計數。部件的用例圖描述了系統提供的功能，也描述了系統的邊界，因此事務（外部輸入EI、外部輸出EO和外部查詢EQ）的個數可以由用例圖中的用例來確定。第四步對部件進行復雜度的判定。事務的復雜度值由數據元素類型DET和引用文件類型FIR決定，文件的復雜度值由數據元素類型DET和記錄元素類型RET決定。

1.2 估算數據約束

PROBE方法重要的一個步驟是利用線性回歸方法和統計方法估算計劃新增和修改的規模或時間，這個線性方程如下表示：

計劃新增和修改的規模或時間：P=β0+β1*E。β0表示初始時間，β1表示平均開發每個類或數據庫元素等項目所需的時間。關鍵就是如何利用數據求得β0和β1的值。這要看數據的質量以決定如何使用PROBE方法。

理想的情況是有 4個以上估算代理規模以及滿足相關性r＞0.7的實際新增和修改規模的數據點，暫且把這種情況下采取的PROBE方法叫做PROBE 1方法；其次情況是估算代理規模沒有4個以上，但是有計劃新增和修改的數據點以及滿足相關性r＞0.7的實際新增和修改規模的數據點各4個以上，暫且把這種情況下采取的PROBE方法叫做PROBE 2方法；在差的情況是在PROBE 2方法的情況下，滿足要求的數據點不在4個以上，其數據相關性也無法滿足r＞0.7，暫且把這種情況下采取的PROBE方法叫做PROBE 3方法；最差的情形是什么可用的數據都沒有，實際上沒有做預測而僅僅是猜測一個值作為計劃新增和修改的規模或者開發時間輸入到項目計劃中去，暫且把這種情況下采取的 PROBE方法叫做PROBE 4方法。

在PROBE方法的概念設計、部件附加、確定基礎部件和重用部件規模階段，接下來的規模估算要按照上述的情形進行細化。對于PROBE 1方法使用線性回歸方法，根據估算代理規模和實際新增和修改規模的數據，計算參數β0和 β1；如果β0的絕對值不接近于0（小于新程序的預計規模的25%），或者β1不接近1.0，即在[0.5，2.0]區間之外，使用PROBE 2方法。此時同樣對于PROBE 2方法使用線性回歸方法，根據計劃新增和修改規模以及實際新增修改規模的數據計算參數β0和β1；如果β0的絕對值不接近于0（小于新程序的預計規模的25%），或者β1不接近1.0，即在[0.5，2.0]區間之外，使用PROBE 3方法。對于PROBE 3方法，β0=0，β1=累計實際新增和修改規模/累計計劃新增和修改規模。1.3 人員心理要素

應用PROBE方法的過程，除了上述技術要素的改進之外，還應該考慮人員的心理要素。這個心理要素包括兩方面，其一是估算人員的心理因素。另外一種是項目開發人員的心理因素。前者是影響PROBE方法的一個內在變量，后者是PROBE方法應用時需要考慮的外部變量。

項目開發人員的心理因素是由于雙重身份引起的。在估算過程中的個體在后續的項目進程中扮演不同的角色。高級程序員由于側重于概念設計的具體工作，因此對于 PROBE方法針對編碼元素的估算會顯得樂觀，做出的規模估算往往小于實際值；項目管理人員為了控制進度，保證項目的按時完成，有意識的壓縮時間進度，在估算時對部件的估算也會相應偏小；而編碼人員由于負責做這些部件的具體實現工作，希望能在盡可能長的時間完成單位工作，故在估算的時候有意識地將部件規模估計偏大以在后續的時間安排中排出更多的時間計劃。

1.4 激勵要素

在PROBE方法開始實行的初期，目的在于培養個體良好的軟件過程習慣。在這個階段，應該激勵那些嚴格按照PROBE方法流程進行個體改進的人員，而不必在意估算結果如何精確。當軟件工程師接受這個過程后，就習慣接受計劃規劃的思想，在概念設計階段會考慮軟件的局部架構，帶動個體軟件設計能力的提高以及相關技術和工具的使用，不經意間極大提高個體生產效率，這時就可以迫使那些最后接受PROBE方法的人為了追趕平均績效，不得不采取這種方法。在接下去的第三階段，當PROBE方法開始普遍使用后，才將注意力集中到規模估算的準確性上來，對于提供有效估算部件、對PROBE方法提出改進意見的人員實行激勵。

2 改進的PROBE方法模型

通過上述的研究，最終建立一個改進的PROBE方法模型，具體示意如圖2所示：

圖2 改進的PROBE方法模型

1）概念設計。根據設計模式思想，利用 UML工具標識類之間的關系；利用數據庫設計工具標識數據庫元素；明確文檔內容和文檔之間的關系。并將這些類（或者細分到類的方法）、數據庫元素、文檔進行部件編號。

2）獲取滿足5個標準要求的proxy，并產生規模相關表。規模等級的產生如下所敘。

（1）將部分規模除以該部分包含的項目數得到每個項的規模；

（2）將這些項規模分成各個功能類別的規模；

（3）對于每一個規模值，算出它的對數：ln（Xi）；

（4）計算這些對數的平均值ln（Xi）avg；

（5）由平均值得出各個對數值之間的差：

（6）得出標準差σ；

（7）計算對數范圍：ln（VS）=ln（Xi）avg-2σ，ln（S）=ln（Xi）avg-σ，

3）新增部件規模。輸入部件的名字、項的數目和相關的規模。對于每一個部件，從相應的規模表中取得每項的規模，用這個值乘以項數，并輸入到估算規模中；在任何新可重用的附加的估算規模后加上星號。開發之后，度量并輸入每個新部件或新部件項的實際規模和新部件的項數。

4）基礎和重用部件規模。對于基礎部件，度量并輸入基礎規模，估算并輸入對基礎程序的刪除、修改和新增的規模開發之后，度量并輸入基礎程序和任何刪除、修改或新增的實際規模。對于重用部件輸入每個不修改的重用部件的名字和每個不修改的重用部件的規模，開發后輸入每一個不修改的重用部件的實際規模。

5）估算非編程任務。這已在前面專門敘述，這里不再展開。

選取的proxy需要滿足前面敘述的五個標準，就是合格的proxy。

6）選擇規模估算規程方法。

（1）確定新增規模A=新增基礎代碼BA+部件附加PA；

（2）估算代理規模E=A+修改代碼M；

（3）確定規模估算規程方法：分析有用的數據并選擇合適的PROBE估算方法。

7）根據線性回歸方程確定項目規模。

（1）如果選擇的是前面提到的 PROBE 1方法或者PROBE 2方法，計算相系數r；

（2）按照PROBE規程計算β0，β1的值；

（3）使用規模回歸參數和估算代理規模計算計劃新增和修改規模P=β0+β1*E；

（4）計算總的估算規模T=P+B-D-M+R；

（5）估算總的新的可重用的規模NR，用*號表示；

（6）計算并輸入預測區間；

（7）計算預測區間的上限UPI和下限LPI；

（8）列出計算預測區間的可能性百分比（70%或者90%）。

3 改進的PROBE方法模型的實證分析

項目是某儲運公司委托開發的信息系統，系統構架采用B/S和C/S的混合構架模式客戶端系統是個以財務為核心，以業務為導向的運輸管理信息系統，實現企業信息管理、車輛信息管理、車輛維修管理、司機信息管理、薪酬管理、運輸業務管理、貨代業務管理、事務提醒、業務數據匯總統計和報表打印、參數設置、數據庫備份還原、用戶權限管理十二大塊功能。

3.1 確定設計模式

目前有5個歷史項目在功能和規模上都是相近的，其中前4個采取的項目開發方法是一樣的，看起來似乎選取它們中的最后一個是最理想的選擇。但是觀察發現，最后一個項目與前 4個項目不同的原因是組織內在這個項目之前發起變革，為了解決代碼復用性和開發流程的規范化，對系統的架構進行了徹底改變，當然包括業務層的類發生了巨大的變化。基于上述原因，采用這個項目作為歷史數據的依據。核心部分即業務操作部分的UML活動圖與類、方法的關系如圖3所示：

圖3 UML活動圖

部件被清晰地分解，考察部件的復雜圖也有了依據。

3.2 獲取proxy并產生規模相關表

首先考察（規模，時間（小時））的關系。根據歷史數據選取15組，分別如表1所示：

表1 相關性計算數據表

顯著性t=|r|sqrt（n-2）/sqrt（1-r*r）=6.31，在t分布表中查詢95%一列，因為n=15，自由度d=13，6.31＞2.182，

所以顯著性小于0.05.

由此說明時間和規模是顯著相關的。

然后考察估算規模與實際規模的關系。如果歷史數據即上述基于相同設計模式的項目的估算規模與實際規模存在顯著的相關關系，結合前面得出時間和規模顯著相關的結論，則認為這些proxy是符合標準的。需要注意的是由于設計模式保持嚴格的一致性，因此現有項目24個部件與之前項目的16個部件在系統中的功能地位是近似的，因此可以作為對照，所得的結論才有參照意義。

選取歷史數據（估算規模，實際規模）的數據如表2所示：

表2 相關性計算數據表

又∑xi=610，∑yi=787；求得相關性r=0.83；同理顯著性小于0.05。

PROBE估算方法將歷史規模數據根據工作類型劃分成多個類別，這樣如果知道所有之前開發的關于某部件的規模，就能夠推測出類似的某部件的規模，制定一張規模相關表如表3所示：

表3 部件規模表

ContainerInfo 3 19 6.333 S CreateNewOrder 2 25 12.500 M AddI-temToOrder 3 47 15.667 M Complete 2 51 25.500 L Request-Shipment 2 43 21.500 L ShippingOrder-Item 4 73 18.250 L CloseShipment 2 29 14.500 M Create-BackOrder 3 13 6.500 S BackOrder-ItemArrives 3 21 7.000 S ReturnItem 3 13 4.333 VS ListReadyOrders 2 8 4.000 VS ListOrdersWithdersWith-Backorder 2 19 9.500 S

將規模數據劃分為很小（VS）、小（S）、中等（M）、大（L）、很大（VL），這樣可以為判斷部件規模提供一個初始結構[15]。

3.3 確定新增部件

經過分析，發現主框架、數據基礎訪問層、數據持久層等通用類的基礎部件共計代碼1445行，都無需新增和刪除，需要在主框架修改12行。重用部件是關于報表操作的類。基礎和重用部件如下表4、表5、表6所示：實際程序規模，且r＞0.7，因此采取PROBE 1方法。

表4 基礎部件估算值

表5 基礎部件實際值

表6 重用部件估算值和實際值

根據上述分析得出的數據，可以利用PROBE 2方法的線性回歸方法計算規模，如下表7所示：

表7 PROBE方法計算規模

計劃新增和修改的規模（P） P=β0+β1*E 1741總的估算規模（T） T=P+B-D-M+R 3538預測范圍 范圍 348預測區間上限 UPI=P+范圍 2089預測區間下限 LPI=P-范圍 1393預測區間百分比 95

從這個實證中可以看出，PROBE方法利用歷史數據進行軟件規模的估算，在下次的估算中這次的實際值將影響下次的估算值，不斷重復迭代，使線性回歸方程日趨合理，不斷提高軟件規模估算的準確度。

4 總結

PROBE是一種簡單的基于代理的軟件規模估算方法，它是基于軟件工程邏輯和統計方法之上提出的，本文對一般的PROBE方法進行了改進。改進的PROBE方法簡單易用，能夠在較短的時間內，利用方法對軟件規模進行估算，得到規模估算的結果。

[1] 胡云龍.軟件規模度量方法介紹[J].計算機時代，2006，7：17-18.

[2] Zhang Junguang， Zhao Yumei. Study on Top--Down Estimation Method of Software Project Planning[J]. The Journal of China Universities of Posts and Telecommunications，2006，13（2）：108-111.

[3] 劉澤星，李建華，費耀平.軟件規模評估方法的研究與應用[J].計算機工程，2002，28（12）：113-114.

[4] 唐林燕.COCOMO估算模型改進研究[J].微電子學與計算機，2006，23（12）：58-60.

[5] 張維明，劉忠，肖衛東等.信息系統建模[M].北京：電子工業出版社，2002：160-176.

[6] 王宏宇，黨齊民.面向對象軟件項目估算方法的研究[J].計算機與數字工程，2005，33（7）：338.

[7] 周楊，吳海濤， 張棟偉.擴展的用例點估算方法[J].計算機技術與發展，2006，16（12）：64-66.

[8] 夏正煜，孫蕾.面向對象軟件規模估算方法的研究[J].電腦知識與技術，2005，15：12-15.

[9] Costagliola G，Tortora G．Class Point：An Approach for the Size Estimation of Object—Orinted Systems[J]．IEEE Transactions on Software Engineering，2005，31（1）：52-74．

[10] Kenneth E.Kendall， Julie E.Kendall. System Analysis and Design（Six Edition）. Beijing： Tsinghua University Press，2006：580-593.

[11] 魏永合，張力爭.軟件規模估算在RAD系統中的應用與改進，2003，22（3）：36-38.

[12] 魏蔚，石柱，鄒軍.軟件項目估算與測量的工程實踐[J].航天控制，2006，24（5）：58-62.

[13] 劉克青，廖建新，張俊光.軟件項目策劃中的工作量估算方法探討[J].計算機工程與應用，2004，27：90-92.

[14] Asutina S， NewtonB A， Steeleb J， etal. Modeling and managing project complexity. International[J] Journal of Project Management，2002，20（3）：191-198.

[15] Abdomerrovic M， Blakemore G. Project process interactions[J]. International Journal of ProJect Management. 2002， 20（3）：31323.

Application of Improved PROBE method Model in Software Project Scale Estimation

Jia Ying
(Baoji Professional Technology Institute, Baoji 721000)

Combine with the actual project experience in the PROBE method to improve, and put forward an improved model of PROBE method. The model takes improving the PROBE method as the core to understand the demand analysis. Then do the conceptual design, produce the scale related tables, determine the size of the new parts, determine the basis and reuse of parts scale, estimate the non programming tasks, select the appropriate proxy, select the size of the standard method, according to the linear regression equation to determine the project size. These above eight stages give a comprehensive guide of how to get, write and organize the parts, when to enter the estimate and the specific process of it.

PROBE method； Component size； Software size； Linear regression

TP311

A

2015.12.28）

賈 瑛（1983-）,女，寶雞職業技術學院，研究生，講師，新疆哈密人，研究方向：網絡和多媒體，寶雞，721013