在RUP中結合PSP

典型地說，軟件開發項目成敗的關鍵因素有三個：時間、成本和質量（圖一）。然而當我們把它們當作箭一樣射向目標時，卻經常會因為種種原因而無法正中靶心。 

　　在瑞典，瑞典專利注冊局有個著名的失敗的軟件項目，就是和很多軟件公司合作，要實現一個基于Web的在線專利注冊的解決方案。這個計劃始于1998年，預算一千五百萬美元，系統實際上在2000年9月交付，功能仍不完善，成本已達兩千五百萬。 



圖1：軟件開發項目成敗的關鍵因素 
　　為什么這個項目會失敗呢？關于這個話題有很多研究論文和書籍，可靠的說法是失敗同時源于內部和外部因素。例如，外部因素可能是產品開發出來時，已經過于陳舊而且沒什么價值了，也就是說，過時的技術導致產品難于使用（可用性很差）。另外可能的外部因素還包括項目核心人員的離職和客戶變更需求說明等。對于軟件開發者來說，這些因素是無法控制的。 

　　然而有個絕對可以控制的內部因素，就是軟件開發過程。已定義的成熟的過程通常輸出好的軟件產品。而且隨著系統越來越復雜和龐大，這樣的過程會越來越重要。 

軟件開發過程 
　　現在存在著大量的軟件開發過程，如：能力成熟度模型（CMM），Rational統一開發過程（RUP），個人軟件過程（PSP）和小組軟件過程（TSP）等等。大多數方法關注（支持）的焦點僅僅是一個層次上的過程改進。例如，RUP和CMM在組織級的層次上提供軟件開發支持，TSP提供團隊級別的支持，PSP提供個人級別的支持。 

　　象RUP和TSP支持組織和團隊級別的軟件開發卻不能適應組織中個體的軟件過程。它們關注和致力于團隊級別協同工作的活動卻忽略了對個體的指導。導致的后果就是只能或多或少依靠個體自己去尋找監測、控制和改進其軟件開發過程的方法。 

Rational統一開發過程 
　　RUP定義了一系列的過程元素，如角色、活動和產物，通過適當的組合，能幫助組織有效地管理軟件項目。然而，過程本身并不提供神奇的超水平解決方案，只有角色－－實際存在的人－－才是項目的驅動力。沒有人類的實踐，世上任何過程或者工具都無法單獨完成一個軟件項目。歸根結底，無論是項目按時完成還是發布高質量的系統，都很大程度上依賴于參胝吒鎏迦砑??痰鬧柿俊? 

　　RUP提供的是幫助人們更出色地工作的知識基礎。不同于PSP提供給軟件工程師直接支持的使用途徑，RUP規定的是各種各樣的活動發生時，需要怎樣做、做什么、何時做、由誰做以獲得滿意的成果的一個框架。換句話說，使用RUP的組織如果擁有合格的和有經驗的人員能作的相當好，而且顯然要比那些員工經驗不足、能力不夠也試行RUP的組織做得更好。為了節省時間和成本，對于那些員工經驗不足的組織來說，盡快地改善員工技能是非常重要的。遺憾的是，RUP在如何解決員工能力這個問題上沒有給出答案。 

　　相比之下，PSP則立足于員工能力的改進。PSP是軟件工程師個體軟件過程改進的指導框架，是賓夕法尼亞州-匹茲堡的軟件工程學會成員Watts Humphrey1995年創立的。PSP提供了一些度量標準、操作步驟和模板幫助工程師改進個人的軟件工程技巧。研究結果顯示軟件工程師應用PSP后軟件過程有顯著改進，在生產力、缺陷引入的數量、時間和規模的估算等方面也有明顯改善。 

　　圖二顯示PSP過程的成熟度等級。PSP0是最基礎的，使軟件工程師能夠建立基本的開發過程，而PSP3是最復雜的，提供大量有效的度量標準和模板。 



圖2：PSP成熟度等級 
PSP如何支持RUP 
　　正如運用PSP所能獲得的積極效果，我們可以認為RUP中類似的過程改進意識將幫助使用者改進他們自己的過程，從而提高組織整體的過程改進效果。假如你去研究并比較PSP和RUP，會很容易發現PSP具有可運用于RUP中的過程改進概念。 

　　在RUP中融合PSP的主要好處如下： 

任務和進度計劃模板 RUP在一次迭代過程中對團隊成員如何控制工作僅提供有限的支持，而RUP的一次迭代可能持續數周或數月。項目經理（或其它領導者）分配任務和職責給項目組成員，但在迭代中如何計劃則取決于每個項目組成員自己。對此RUP未提供任何支持。相比之下，PSP提供了任務和進度計劃模板用以監控項目的進展。利用這些工具，軟件工程師能夠追蹤他們的進程，知道什么時候開始落后于進度，并且將其通報項目經理以采取相應的糾正措施。 
基于個體缺陷數據的檢查表 RUP角色不執行基于個人缺陷數據的復查。他們只有從整個組織收集的最典型缺陷類型的檢查表。由此導致的結果是軟件工程師們查找的缺陷類型也許是他們從來不會引入的。相比之下，PSP具有基于個體缺陷數據的檢查表，因此軟件工程師查找的缺陷類型正是他們經常涉及的。 

記錄過程改進想法以及幫助推動過程改進的模板 RUP不提供模板記錄關于過程改進的想法，PSP卻提供這樣的模板讓軟件工程師象記錄項目下一步要完成的任務一樣記載這些想法。 

幫助改進過程的度量標準（方法） RUP不提供給軟件工程師預先定義好的監控軟件過程的度量標準（方法）。其實每個新項目開始前，度量標準（方法）必須定義并且解釋給所有項目組成員。然而，該度量標準（方法）不能保證提供了軟件工程師為監控其軟件開發過程所希望的和需要的那類信息。在這種情況下，就要依靠軟件工程師自己定義和運用適當的度量標準（方法）。相比之下，PSP擁有許多度量標準（方法），提供大量個體軟件開發過程改進的信息。 

　　可惜的是，PSP的模型不能直接被RUP角色運用，它必須經過修改才能適合RUP環境。假如每個RUP項目都以同樣的方式控制--即假如產物，活動，工作流，生命周期模型等等從來都不會變更--那么PSP模型只需修改一次就可以適用了。然而這是不可能的，因為每個項目都是唯一的，為了成功地完成都需要用特定的方式來管理。這意味著RUP的各建模元素--活動, 產物,及工作流--在每個即將實施的特定的項目中都必須修改和定義。 

RUP成員的PSP工具箱 

　　為了決定用PSP支持RUP的時機，我們給那些在整個過程中承擔部分任務：設計，編碼和測試活動的角色定義了“PSP工具箱”。該工具箱包含過程腳本、模板，以及RUP角色適用的度量標準（方法）（見圖3），使他們能分析和控制自己的軟件開發過程。 



圖3：RUP成員的PSP過程改進基礎工具箱 
　　我們給RUP定義的5種角色：實現者，集成者，測試設計者，測試者，以及設計者都設置了其獨有的PSP工具箱。他們從事PSP相關的活動，而且他們應該作為運用PSP模型的主要的候選對象。盡管RUP中也有其他一些角色從事PSP相關的活動，但是在相對次要的層次上，比如處理并發事件的概要設計者，他們可以被當作局部設計人員。因此，定義PSP工具箱限制在以上提及的主要角色類別。但應該指出，RUP的每種角色都應該有一個自己的過程改進框架，特別地定義那些個別角色的需求和工作環境。然而，這是另外的話題，在此就不再深入討論了。 

把PSP應用到RUP中 

　　到目前為止，我們為5個選定的角色定義PSP工具箱，而且PSP工具箱中的模型可以幫助他們監視和控制他們的軟件開發過程。但是還有兩件事沒有做。第一，一種新的過程--在這里就是指PSP -- 要用適當的方式把它引入組織中。經驗告訴我們表一中列舉的一些概括性的指導方針對于過程的引入很有效。 


表1：把新過程引入組織中的指導方針 
方針 
說明 

包括合適的人員 
有決策權并且對新過程有興趣的有能力的人應該包含其中。


文檔化新規程 
決定誰什么時候做什么。當出現問題時這些文檔可以用于參考。 


要求反饋 
在新過程引入時，相關責任人應該懇請別人提出批評和建議。使用新過程的人應該覺得他們能夠對過程引入有關的重要決策產生影響。 


實施事后分析 
在引入的每個階段，稍加停頓以評價前期的工作，不斷地嘗試改進新過程的適應性。 

　　第二，針對每個不同的項目，PSP工具箱中的模型應該作適當的調整。例如，要提前為軟件開發項目定義度量規模的標準以便開發組成員估算產品規模、時間和工作量。但是，事先不可能知道應用過程中是否會有問題，以代碼行和功能點這兩種規模度量方法（標準）為例，方法（標準）的選擇依賴于應用程序的類型或者開發過程中使用的工具。另外，如果使用代碼行度量，還是不可能預先知道應該統計物理行數還是邏輯行數的問題，而用功能點度量就會存在選用哪些因素和權值的問題。正如這個小例子說明的，任何項目，實際使用PSP工具箱的人都應該對其中的內容進行調整。 

　　如表二所示，RUP提供了大量關于新項目RUP調整的指導方針供參考。 

表2：新項目RUP調整的指導方針
方針 
說明 

分析項目和組織 
分析即將開發的項目的類型、規模和組織方面的因素。 


定義項目的范圍 
定義項目的作業流程；選擇使用的工具。 


描述迭代計劃 
確定整個迭代過程中的活動以及它們的次序。這個過程需要精確的定義。


改進項目過程 
每次迭代過程之后對RUP進行評估。 

　　為了使PSP和RUP完美地結合起來，同時針對這兩個過程考慮表二中所列出的因素是很有意義的。這樣，當你準備一個新項目時，就可以在相同的范圍內同時考慮PSP和RUP，并且以相似的方式將它們文檔化，從而輕松地把PSP結合到RUP之中。 


　　對于如何使PSP工具適合RUP過程，表2、3中的每個要素都提供了相應的指導。 

表3：使PSP工具適合RUP過程的指導方針
（斜體字表示PSP指導方針）
方針 
說明 

分析項目和組織 
分析即將開發的項目的類型。
選擇適當的模版，模版應該適合應用軟件的需求，對過程和組織的關鍵過程（要素）進行剪裁，
先在小的團隊（小范圍）執行和評價。不要在整個組織內強制執行PSP。

定義項目的范圍 
定義項目的作業流程；選擇使用的工具。
確定適當的度量標準。使用LOC代碼行度量，所有的度量過程都基于這個標準。 

描述迭代規劃 
確定整個迭代過程中的活動以及它們的次序。 這個過程需要精確的定義。 

改進項目過程 
每次迭代過程之后對RUP進行評估。 
評價PSP組合到RUP中的益處，關注成員之間的溝通，找出PSP的各種原理在什么時間和位置（迭代過程中）適用，循序漸進。

　　用PSP支持RUP的主要優勢在表4中給出。但或許最重要的優勢是PSP為個人特長的發揮提供驅動。PSP強調個人的承諾和優秀是對過程改進結果有重要影響的要素。軟件工程師總是努力追求完美，這種作法使他們再也不會因所做的努力是否會得到尊重而耿耿于懷。在這種承諾方式下的員工總是比那些不關心工作成果只要薪水保持增長的人做得更好，因為PSP使人為個人的卓越而努力。 

表4：PSP支持RUP的主要優勢
PSP支持RUP的主要優勢 
說明 

減少工作成果缺陷的數量 
調查基于個人的缺陷數據。 

軟件開發過程中的定量度量
通過模板和標準的支持為軟件開發過程提供更好的控制。 

更多正確和精確的評價 
評價基于個人的過程數據。 

追求個人的卓越 
PSP使人努力改進工作程序。 

迭代過程中更好的規劃和控制 
PSP提供短期的計劃和控制，是RUP迭代趨于長時間段的理想補充。 

　最重要的要記得軟件開發過程對所有層次的工作都提供支持：無論是對個人、對團隊、還是對組織。定義過程的目的是為了確保工作能夠具有相當高的質量而且提前完成。俗話說“一環薄弱,全局必垮。（鏈條的強度是由最薄弱的環節決定的）”。一個項目的成敗依賴于所有相關的個體，而這些個體可以通過改進他們的工作流程對項目提供最大的支持。這就是PSP可以提升RUP之處。 

原文轉自：http://www.kjueaiud.com