基于ＳＰＥＭ擴展元模型的ＰＳＰ實施方法

摘要：提出了一種支持PSP過程的SPEM擴展元模型PSPEM，并給出了基于PSPEM的PSP實施過程及支持該過程的原型工具。其中使用PROBE方法幫助個體進行項目計劃和估算，用DEA分析方法綜合評價工程師的過程性能，有效地指導工程師實施PSP。

關鍵詞：個體軟件過程；軟件過程工程元模型；數據包絡分析

中圖分類號：TP311文獻標志碼：A

文章編號：1001－3695(2008)03－0775－04

卡內基梅隆大學軟件工程研究所提出的個體軟件過程PSP[1]從個體的層次描述了軟件開發過程，提供了詳細的控制、管理和改進工程師的工作方式的方法。它是一個包括軟件開發表格、指南和規程的結構化框架，為小型軟件組織及個體如何收集、管理過程數據提供量化指導。SEI的研究者對在校大學生進行了PSP課程培訓，收集了23個PSP課程中提交的數據，分析得出的結論是軟件工程師通過PSP培訓，顯著地改善了任務計劃的準確率和產品的質量[2]。但由于缺乏有效的實施方法及相關工具的支持，PSP在業界的應用并不理想，一份調查顯示[3]，在有78個學生的PSP課程結束后，其中的72個學生放棄了繼續使用PSP，因為PSP太過于“嚴格、不連貫”，難于實施。

SPEM[4]是國際對象管理組織OMG提出的軟件過程領域通用元模型。它歸納并抽象提取了RUP等軟件過程中通用的過程元素，并定義了相關的語法及語義，在RPW等軟件過程工具中得到了良好的應用[5]。但是，SPEM中并沒有針對PSP特定語義的建模支持。例如，PSP中的數據表格、數據分析方法以及項目計劃過程在SPEM元模型中沒有對應的概念支持，這給SPEM模型描述PSP語義以及定義PSP實施過程帶來了障礙。為此，本文針對PSP的特點對SPEM進行了擴展，定義了元模型PSPEM，并基于PSPEM提出了一種PSP實施方法。其中使用PROBE (proxy based estimating）[1]方法幫助軟件工程估算程序規模和所需資源，利用數據包絡分析方法DEA[6]綜合評價個體軟件過程性能，以協助下一次根據個體性能和任務要求作出更合理的分配策略，從而減少項目風險，提高項目產品質量。為驗證方法的有效性，開發了支持該實施過程的原型工具，并應用在中國科學院軟件研究所的軟件質量管理平臺SoftPM[7]上。

1基于PSP的SPEM擴展模型

1．1SPEM的擴展方法

SPEM支持兩種元模型擴展方式，即重型擴展和輕型擴展 [10]。在PSPEM的定義中，使用重型擴展為SPEM定義符合PSP的元類以及元類之間的關聯，最終建立PSPEM元模型；使用輕型擴展的UML profile機制進一步擴展PSPEM，使PSPEM符合UML的標準語法，可支持UML CASE工具操作。限于篇幅，本文只給出重型擴展模型及其說明。

1．2PSPEM

PSP為小型軟件組織及個體如何收集、管理過程數據提供量化指導，定義了一些腳本指南、日志格式、標準、表格等用于收集個體數據，同時還定義了相關數據統計、估算方法以及個體性能度量元、產品質量度量元等。 為了支持上述PSP中的元素和語義，本文在SPEM的extensions包中引入了一個新的PSP elements子包，該子包擴展了另外兩個子包，即BasicElements和ProcessStructure，如圖1所示。

在PSP elements子包中，將PSP中涉及到的元素和方法定義成新的元類，與SPEM現有的模型元素建立關聯，使新的模型PSPEM支持PSP過程語義。PSPEM主要的抽象語法如圖2 所示，圖中主要關注于PSP相關的元素，忽略了SPEM其他部分。主要元類的定義如下：

a)Person，即PSP過程中的個體，代表軟件工程師個體。它是process role的執行者。

b)PSP data。個體軟件過程中收集的歷史項目數據，包含了PSP中的主要數據。PSP data本身是一個抽象的元類，它主要的子類有PSP表格（PSP form）和PSP日志（PSP log）。PSP中主要涉及五種表格，即過程改進方案表、項目計劃總結表、PROBE估算表、設計模板和評審檢查表。PSP log 是一個體在執行任務時記錄的詳細信息，如時間日志time log、規模日志size log和缺陷日志defect log。

c)PSP plan activity 主要是個體對任務的PSP相關計劃活動，主要從規模、資源和日程表等方面制訂的詳細計劃。這些計劃數據都是參照歷史經驗數據PSP data來估算，并由PSP Util輔助執行。

d)PSP Util是PSP提供的輔助工具，主要有PSP standards和PSP scripts。

e)Analyze method是PSP的數據統計分析方法，如平均數法、PROBE方法以及本文引入的DEA分析方法等。

f)PSP metrics是從個體數據PSP data中統計出來的度量元，用于度量個體軟件過程的性能或產品質量，如缺陷密度、評審率、收益、A/FR、時間估算準確率、編碼效率、CPI、重用百分比、缺陷密度等。這些度量元數據都從PSP data的表格或者日志中分析得來。

g)PSP capability 代表個體軟件過程性能的綜合評價，是PSP Metrics的特殊子類。通過DEA方法對其他PSP metrics度量元分析所得。

h)PSP level和PSP KPA。PSP雖然沒有像CMM那樣嚴格定義了不同層次以及KPA，但它定義了一個個體過程進化框架，分為四個PSP level，即PSP0~PSP3，每個級別包含一些基本訓練要求，稱之為PSP KPA。

PSP data是PSPEM中的核心元素，PSP data和PSP util輔助個體執行任務計劃活動。其中PSP Util隨著個體所屬的PSP level而變更。個體在計劃活動以及執行任務的過程中收集PSP data數據，通過analyze method更新度量元PSP metrics以及PSP capability數據，進而用于指導個體下次的任務計劃以及任務執行過程。

2基于PSPEM的PSP實施過程

PSPEM的實例就是一個PSP實施過程。PROBE是以proxy或者對象為基礎，參照歷史數據來估算、預測目標數據的方法。PSP過程收集了工程師在以往項目中的規模和時間數據，因而在PSP實施過程中采用PROBE方法來估算當前任務中的規模、時間數據，幫助工程師制訂更準確的項目計劃。DEA方法是在相對效率評價概念基礎上發展起來的一種新的評價技術。它的適用對象是一組同類型的決策單元DMU。本文引入DEA數據分析方法來評價組織中工程師的個體軟件過程性能PSP capability，從而協助下一次根據個體性能和任務要求制訂更合理的分配策略。

2．1PSP實施過程

圖3中是一個基于PSPEM的PSP實施過程。實例圖中主要關注了PSP語義相關的元素和活動，忽略了其他不相關部分。

主要活動定義為：

a)任務分配。當獲得客戶需求定義后，參照任務需求和組織個體中的PSP capability數據確定分配策略，尋找最合適的執行者來負責任務的執行。

b)概要設計。為了對任務進行精確的估算，工程師根據任務需求確定目標產品大致會是如何設計和構建的。同時PSP提供了PSP standards（如design standards）和PSP scripts來協助工程師進行標準的設計。

c)規模估算。工程師根據概念設計中描述的要構建的產品，采用PROBE方法來估算任務的規模數據。

d)資源估計。根據上一步中估算得到的程序規模來確定完成任務所需要的時間資源。在time DB中記錄了以往任務的實際執行時間t和規模s，利用兩者之間的關系，同樣采用PROBE方法的線性回歸模型來估算開發需要的時間資源。

e)日程制訂。有了時間資源的估算值后，根據time DB中的歷史數據確定各階段占用時間比例（即項目計劃總結表中的ToDate%項），預測各個階段（設計、開發、測試等）需要的時間。再參照個體的PSP metric數據日有效工作時間DayAviableTime或者每周有效工作時間WeekAviableTime來確定各個階段的開始和結束時間，進而定制詳細的日程計劃。

f)產品交付。在交付客戶期望的產品同時，提交開發過程中收集的時間、規模以及缺陷相關的計劃和實際數據。

g)數據統計。任務完成之后，工程師根據收集的表格數據更新自己的各項PSP數據庫，并重新計算各項與個體性能、產品質量相關的PSP metrics，檢查過程改進方案PIP并作出調整；review編譯和測試過程中的缺陷，并更新個人的review checklist來幫助下次fix同類缺陷。

h)DEA數據統計之后，利用個體的PSP metrics數據和DEA方法評價組織中個體之間的相對性能，即PSP capability，以供下次任務分配時參考。

2．2用PROBE方法估算項目規模

PROBE以proxy為基礎，參照歷史數據來估算目標數據。Proxy代表要估算的目標所能劃分成的最小元素，在PSP中選objects或者objects所包含的方法作為proxy來估算程序規模。PROBE方法分為四個步驟：a)確定proxy歷史參考數據表；b)統計當前估算目標的proxy類型和數目；c)計算估算proxy規模E；d)利用E值和線性回歸模型計算目標數據。定義1定義了本節使用的規模變量。

定義 1B=基本規模，E=估算proxy規模，M=修改規模，D=刪除規模，BA=基本新增規模，PA=局部新增規模，AM=新增以及修改規模，R=重用規模， T=總規模。

1)Proxy歷史數據參考表

Proxy歷史數據參考表，即歷史項目中同等類型方法的規模參考數據。表 1是CMUSEI在PSP課程中收集的規模數據[1]。工程師在每次完成任務后，提交方法的實際規模，并用平均數方法更新此表。

2)統計當前估算目標的proxy類型和數目

概要設計的作用就是幫助工程師確定目標產品的大致形態，了解產品開發所需新增、修改、刪除以及重用的objects。根據這些objects對照表1統計出所需開發的不同類型和大小的方法數目。

3)估算proxy規模

若程序有n個屬于新增object的method，根據表2，第i個新增方法所需要的代碼行記為L(ci，si)。其中ci為第i個方法的category，si為第i個方法對應的大小（VS/S/M/L/VL），則程序基本新增規模BA的計算方式為

BA=nm=1L(ci，si)

同樣可估算出程序的局部新增規模BA、修改規模M、刪除規模D和重用規模R。從而得出估算proxy規模：

E=BA+PA+M

4)運用線性回歸模型計算目標數據

估算的目標數據是程序的新增、修改規模MA，估算proxy規模E和MA之間相互關聯[1]。利用兩者的歷史數據和線性回歸模型以及當前的E值來推導MA的值：

μ=xavg=（1/n）ni=1Xi

β1=a[（ni=1xiyi-nxavgyavg）/（ni=1x2i-nx2avg）]

β0=yavg-β1xavg

y=β0+β1X

其中:y是要估算的目標值MA，x是當前參考值E，xi、yi分別為i個歷史任務中對應的數據，n為歷史任務數據個數。依此計算出線性回歸模型的參數β0和β1，可推導當前程序新增修改規模AM以及程序總規模的估算值：

新增修改規模：AM=β0+β1E

程序總規模：T =AM+B-M+R

PROBE方法也可用于估算任務所需時間資源，此時線性回歸模型y=β0+β1X中，X為程序新增修改規模MA，y為任務成本，即開發時間。PROBE方法根據個體的歷史數據對當前任務的規模和所需時間資源進行比較合理的估算，能幫助軟件工程師進一步制訂更詳細的計劃。

2．3用DEA方法評價個體軟件過程性能

DEA適用于評價一組同類型的決策單元(DMU)的相對性能。DMU是指代表或表現出一定的經濟意義，將一定輸入轉換為一定輸出的實體。DEA方法的最主要應用就是根據輸入／輸出數據對同類型的DMU進行相對有效性的評價。本文選擇DEA方法來分析PSP capability，以軟件工程師作為DMU，個體的資源消耗作為輸入，關于產品質量和個體效率的PSP metrics作為輸出來評價個體軟件過程相對性能。選用DEA的BCC模型來評價PSP capability：

min y-ε (mi=1si+sk=1tk)

s.t.nj=1aij+si = aij0y;i=1，2，…，m

nj=1bkjxj-tk=bkj0;k=1，2，…，s

nj=1xj=1

xj≥0，j=1，2，…，n；si≥0，i=1，2，…，m；tk≥0，j=1，2，…，s

其中：aij0和bkj0分別為決策單元j0的第i種輸入指標數據和第k種輸出指標數據；xj為第j個決策單元的決策變量，si為第i種輸入指標的松弛變量，tk為第k種輸出指標的剩余變量，y為輸入比例變量；ε為非阿基米德無窮小量，具體計算時，可取ε=10-6。從項目計劃總結表中提取如表2中的PSP metrics參數作為評價輸入/輸出（由于缺陷率越高產品質量越低，本文取其倒數）。

經DEA 的BCC模型求解計算結果如表4所示。從結果可以看出，代表DMU 1、4、8、10的個體其過程性能相對其他個體較好，而3、9兩個體的過程性能較差，在下一次任務分配時，這些結果可用于指導分配策略。由于不同的任務對工程師的各項指標要求不同，可選取任務所關注的輸入/輸出指標來進行評價，能更明確地找出最合適當前任務的執行者，從而降低項目延遲的風險，提高產品質量。

3工具及應用

以PSPEM元模型為基礎，開發了原型工具PSPEMQMP，并實施在中國科學院軟件研究所軟件質量管理平臺（SoftPM）中，如圖4所示。該工具以周報或日報的形式收集工程師執行任務的數據，自動統計個體的PSP規模、時間、缺陷等歷史數據，計算并更新個體的性能數據PSP metrics。在任務分配時，系統根據任務需求用DEA方法計算組織中可用工程師的PSP capability，協助找出任務最合適的執行者。任務初始化期間，應用PROBE方法自動估算任務的規模、時間資源，并為工程師制訂計劃日程表，有效地降低了PSP過程實施的障礙，為工程師改進其開發過程提供持續的指導。

4結束語

PSP提供了一套循序進化框架，能有效地引導軟件工程師持續改進其開發過程，提高開發產品質量。但一直以來PSP在業界的應用都不理想，原因之一是缺乏良好的PSP實施過程和工具的支持。本文給出了一種面向PSP的SPEM擴展模型PSPEM，并基于PSPEM提出了PSP實施方法及其支持工具。其中，使用PROBE方法指導工程師制訂任務計劃，采用DEA方法綜合評價個體軟件過程性能，幫助軟件工程師更深刻地理解PSP過程。應用開發的工具原型有助于降低PSP實施的障礙，有效地指導工程師持續改進其開發過程。

在進一步工作中，將就元模型的自動化實施以及如何擴展元模型和工具實現對TSP的支持進行研究。

參考文獻：

［1］HUMPHREY W S.The personal software process，CMU/SEI－2000TR－022[R].Pittsburgh:CMU/SEI，2000:1－39.

[2]HAYES W，OVER J W.The personal software process (PSP):an empirical study of the impact of PSP on individual engineers， CMU/SEI97TR－001[R].Pittsburgh:CMU/SEI， 1997:4－20.

[3]BORSTLER J，CARRINGTON D，HISLOP G W，et al.Teaching PSP:challenges and lessons learned[J].IEEE Software，2002，19(5):518.

[4]Object Management Group. Software process engineering metamodel (SPEM) specification，version1.1，formal/05－01－06 [R]. Needham:Object Management Group， 2005:20－56.

[5]BENCOMO A.Extending the RUP:process modeling [EB/OL].[2007－01－26].http://www128.ibm.com/developerworks/rational/library/05/323_extrup1/.

[6]DING Liping，YANG Qiusong，SUN Liang，et al.Evaluation of the capability of personal software process based on data envelopment analysis[C]//Proc of the Software Process Management LNCS 3840.Beijing:[s.n.]，2005:235－248.

[7]WANG Qing，LI Mingshu.Software process management:practices in China[C]//Proc of the Software Process Workshop LNCS 3840.Beijing:[s.n.]，2005:317－331.

[8]JOHNSON P M，KOU Hongbing，AGUSTIN J，et al.Beyond the personal software process:metrics collection and analysis for the differently disciplined[C]//Proc of the 25th Inernational Conference on Software Engineering.Washington D C:IEEE Computer Society，2003:641－646.

[9]PUTZ V.The Personal software process:an independent study[EB/OL].[2007－01－26].http://www.nyx.net/~vputz/psp_index/book1.html.

[10]FRANKEL D S.應用MDA[M].鮑志云，譯.北京:人民郵電出版社，2003:145161.

[11]HUMPHREY W S.個體軟件過程[M].吳超英，譯.北京:人民郵電出版社，2002:86125.

“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”