現代軟件開發的高速度為開發團隊造成了一些嚴峻的挑戰:
- 需求在項目的生存周期中不斷變化。
- 你不能第一次就得到正確的模型,例如,就像你在造一座橋時。
- 采用最新技術的項目也無法依賴于已證明的技術。
圖1:來自Standish的軟件開發項目成功率Chaos Report 2001
IBM Rational統一過程,即RUP,起源于應對上述挑戰的一組最佳實踐。它幫助軟件開發組織決定哪些角色可以最好地執行特定活動,并定義了一組工件(如,成果)來支持這些活動。此外,它為這些元素間的互動和依賴性建立模型,因此也為項目帶來更多透明性。
RUP采用了面向執行的方法并給出了詳細的指導,一些過程改進框架對其進行了補充,比如ISO 9000:2000,eSourcing Capability Model for Service Providers (eSCM),以及Capability Maturity Model Integration (CMMI),這些框架在更為籠統的意義下工作。它們強調通過結構化一個組織來實現過程驅動的質量,而把如何執行過程的細節問題留給每個組織。
本文借助“軟件功能成熟度模型集成”(Capability Maturity Model Integration for Software (CMMI-SW 1.1))的評估功能探討了RUP在幫助組織實現更高的過程質量中的作用。
CMMI
CMMI通過提供更好的預測性和更高的效率,并最終導致更低的成本和更滿意的客戶來幫助組織提高競爭力。在CMMI過程改進首期進行的公司(如Siemens,JP Morgan,Chase和Lockheed Martin)中收集的數據告訴我們,支持一個主要過程改進需要項目涉及的2%到10%的工程能量。但是實現CMMI的收益足夠補償這一努力,如卡內基梅隆大學軟件工程研究院 (SEI)發布的調查2所顯示的。改進百分比的中心分布如下:
- 成本降低20%
- 計劃實現程度提高37%
- 生產力提高67%
- 缺陷減少50%
- 客戶滿意度提高14%
使用CMMI來評估RUP為組織提供了一種將RUP與其它過程和過程模型進行比較的手段,以發現RUP在作為單獨過程使用時需要改進之處。經理還可以使用這一評估來發現他們可能有效地使用RUP作為對其組織當前過程的補充的地方。
CMMI成熟度2級評估
CMMI提供了兩種架構表述方式:“連續式”和“階段式”。
連續式的版本將CMMI過程領域分為四個子過程域:
- 過程管理
- 項目管理
- 工程
- 支持
初始級:過程是渾沌不可描述的。這導致了不可預測性,且過程是不可重復和被動的。
受管理級:項目的過程被定義,但是基本是被動的。項目團隊確實從涉眾處獲得承諾,且工作狀態對管理是可見的。
已定義級:根據組織的過程資產調整過程。相互關系被更好地理解,輸出被更為詳細地度量,過程管理是前攝的,且結果在性質上是可預測的。
定量管理級:過程通過統計數據被控制和度量,因此結果在數量上是可預測的。
持續優化級:過程指出了過程變化的原因并做出自我調整。它包括定義成功因素和把它們加入組織的過程資產中。
成熟度級別被定義為過程領域的一個特定集合;每個過程領域組合了一組通過實踐實現的目標。這里的評估將把RUP視為實現2級的一個助手。這一級定義的需求包含了最重要的項目管理領域,且是獲得更高成熟度級別的先決條件。這里的評估將指出RUP的優點和缺點以及要實現CMMI 2級需要改進的領域。
我將使用的方法是一個A類評估方法,它是由SEI開發的,名為過程改進的標準CMMI評估方法(SCAMPI)。A類方法最大限度地實現需求并產生過程比較需要的比率。使用SCAMPI方法——一個“現實”的方法,需要與執行過程和評估工作結果的人進行對話。當僅僅把RUP作為一個產品評估時這些對話是不可能的,而評估RUP實現的單獨一個實例會造成失真,因為組織通常會按照它們的組織和具體項目需要調整RUP。因此,在分析這一評估的結果時,我們必須想象一種中立的環境,在這里RUP沒有經過被某個組織調整而是在“經典”配置下執行的。
CMMI 2級包含下列過程領域:
- 需求管理
- 項目策
- 項目監督和控制
- 供應商合同管理
- 度量和分析
- 過程和產品質量保
- 配置管理
根據SCAMPI,一個實踐可以四種不同程度實現:
完全實現:針對這一實踐的元素被完成,且沒有實質性缺陷。
大部分實現:針對這一實踐的元素被完成,但是存在一些缺陷。
部分實現:針對這一實踐的主要元素有所缺失,但是覆蓋了實踐一部分的元素作為副產品被實現;這一方法有其弱點。
尚未實現:實踐需求沒有實現。
SCAMPI將一個實踐定義為完成的如果它至少是“大部分實現”的。如果所有實踐都完成了,相應的目標也就達到了;如果所有目標都達到了,過程領域就被覆蓋了。你通過實現所有過程領域目標和一般目標實現成熟度級別。例如,一個2級的一般目標是:
制度化一個被管理的過程
一般目標適用于多個過程領域,因此被分別對待。但是實現它們是必須的。
RUP的CMMI成熟度級別2評估
表格1-6顯示了RUP對CMMI成熟度級別2的六個過程領域的覆蓋。
表1:RUP對需求管理過程領域的覆蓋
表2:RUP對項目策劃過程領域的覆蓋
表3:RUP對項目監督和控制過程領域的覆蓋
表4:RUP對度量和分析過程領域的覆蓋
表5:RUP對過程和產品質量保證過程領域的覆蓋
表6:RUP對配置管理過程領域的覆蓋
兩個可以補充RUP的過程領域
除去上面討論的過程領域,我們應該注意到RUP并沒有提供對供應商協議過程領域和制度化一個被管理過程的一般目標的足夠覆蓋。使用RUP的組織可以在這些領域中使用CMMI作為RUP的補充。
供應商協議管理
RUP沒有為供應商協議管理領域過程提供實現。由于強調的是軟件開發,RUP假定組織將開發整個產品。這是一個弱點,因為依賴于已證實的解決方案可能比完全自主開發更好;你可以集成現成即用的(COTS)產品或部件同時再創造一個為客戶帶來價值的新產品。通常,這還可以幫助降低開發成本和縮短發布時間。表7顯示了CMMI的供應商協議管理過程領域下的實踐;使用RUP的組織可以使用CMMI來補充RUP的指導。
表7:RUP對供應商協議管理過程領域的覆蓋
制度化一個被管理的過程
RUP也沒有考慮員工培訓,因為它將重點放在了項目上而不是周邊的組織需要上。盡管它包含了一個涉及員工的活動,它很少談及職位應該為擁有所需要的技術,經驗和能力的人占有。表8顯示了CMMI制度化一個被管理的過程這一過程領域下的實踐。同樣,使用RUP的組織可以使用CMMI來補充RUP的指導。
表8:RUP對制度化一個被管理的過程這一過程領域的覆蓋
結論
盡管RUP覆蓋了CMMI對成熟度2級97%的需求,如果實現時沒有其它任何補充實踐,它實際上并不能在這一級別上工作。這是由于它沒有包括2級的兩個過程領域,而它們包含了項目實現中基本的最佳實踐。
當然,一個使用RUP的項目可能由于與這兩個過程領域完全無關的原因失敗,但是在CMMI評估中定義的領域內對RUP加以補充是組織可以借助防止失敗的一個手段。請注意我不是要求經理們傳達任務——建立大量文檔和執行不需要的活動——只為實現CMMI標準。一個項目的最終目標是滿足客戶的需要,而像CMMI之類的框架是設計來幫助你實現這一目標的。在實際情況中,執行活動和建立工件應該只在它們是項目需要時發生。
幸運的是,RUP是建立在一個可擴展的,允許你通過使用插件來使過程適應你的需要的構架上的。一些現有插件已經解決了我前面提出的一些需要。例如,COTS插件可以用于實現缺失的供應商協議管理。
你還可以通過最近為IBM Rational Method Composer解決方案發布的一組工具來實現更多過程領域實踐。它們允許RUP的工具驅動定制化并支持插件開發。你可以使用這些工具基于本文的評估,為其它你定義的需求,或將RUP集成到一個現有的,相關主題的組織過程開發插件。
組織可能希望額外的實現是單獨的插件的形式,這樣它們可以從組織過程資產中選擇針對具體項目的具體需要(比如,需要哪些技能,COTS是不是一種可能,等等)以及形式化程度的過程組件作為插件。
盡管RUP并不需要補充來實現成熟度級別2,我還是推薦組織通過遵從CMMI標準獲得更好項目結果。它的公開構架使你能夠復用你現有的合作過程。作為一個過程模型屬性,這種公開性是一個關鍵因素,因為它導致無縫集成,當通訊改變過程或過程改進發生時,無縫集成是一個重要優勢。RUP還帶有對通過插件和已植入的定制化集成子過程必要的工具,這對尋找最佳開發過程的組織來說也是一個巨大的優勢。
文章來源于領測軟件測試網 http://www.kjueaiud.com/