IBM SDP 簡介
IBM SDP 是 IBM 針對軟件開發(fā)" title="軟件開發(fā)">軟件開發(fā)而推出的一整套解決方案平臺,,它的全稱是 IBM Rational軟件開發(fā)平臺 (Software Development Platform) ,。它使得軟件開發(fā)組織能夠更有效地開發(fā)軟件產(chǎn)品,,提高軟件質(zhì)量,,保證開發(fā)進度,、控制開發(fā)成本,。?
軟件開發(fā)的四項基本原則?
IBM SDP 中集中體現(xiàn)了以下軟件開發(fā)的基本原則:?
??????? 迭代化開發(fā):有效控制項目風(fēng)險,、增加項目預(yù)見性,、盡早地發(fā)現(xiàn)軟件產(chǎn)品中的缺陷,;?
??????? 以架構(gòu)為中心:采用可視化建模技術(shù)來構(gòu)建以構(gòu)件為基礎(chǔ)的系統(tǒng)框架,有效地管理系統(tǒng)的復(fù)雜度,,增強系統(tǒng)的靈活性和可擴展性,;?
??????? 持續(xù)地質(zhì)量驗證:在整個產(chǎn)品生命周期" title="產(chǎn)品生命周期">產(chǎn)品生命周期中持續(xù)地驗證軟件質(zhì)量,確保產(chǎn)品滿足客戶的需求,,并且構(gòu)造一個高性能,、高可靠的軟件系統(tǒng);?
??????? 管理軟件資產(chǎn)和變更:在整個產(chǎn)品生命周期中管理好企業(yè)的軟件資產(chǎn),,并對所有的變更請求進行管理,,支持虛擬團隊的并行開發(fā)。?
按角色分工的工具平臺 ?
IBM SDP 中包括了支撐整個軟件開發(fā)生命周期所需的工具,,這些工具是以開發(fā)人員的角色來組織的,。?
角色 |
開發(fā)工具 |
業(yè)務(wù)分析員? |
Rational RequisitePro, Rational Software Modeler? |
系統(tǒng)架構(gòu)師? |
Rational Software Architect / Rational Software Modeler |
軟件工程師? |
Rational Application Developer / Rational Software Architect |
質(zhì)量工程師? |
Rational? Functional Tester, Rational Performance Tester |
項目管理人員? |
Rational Unified Process, Rational RequisitePro |
CMMI 模型簡介
CMMI 模型的內(nèi)容?
CMMI 是一個應(yīng)用于流程改進的模型,在 CMMI 中制定了流程改進的目標和最佳實踐,,它為需要提高自身開發(fā)能力的軟件組織提供了一個參考標準和實踐指南,,并且這個標準是在前人的實踐經(jīng)驗上總結(jié)出來的,具有很強的可實踐性,。?
CMMI 模型的內(nèi)容分為“需要的(required)”,、“期望的(expected)”和“用于提供信息(informative)”三類,。?
??????? 需要的:?CMMI 中定義了24個過程域(process area),每個過程域都有一到四個特定目標(specific goals),;另外,,針對于所有的過程域,也定義了一組共性目標(general goals),。?
??????? 期望的:針對每一個目標,,CMMI 定義了一組推薦的實踐(practices),通過實施這些實踐可以幫助軟件組織達到相應(yīng)的目標,。?
??????? 用于提供信息:另外,,CMMI 中也提供了其他一些用于輔助提供信息的內(nèi)容,如:相關(guān)過程域,、典型工作產(chǎn)品,、實踐與目標關(guān)系表等,。?
CMMI 的表示方法?
由于 CMMI 是對幾種不同的成熟度能力模型的集成,,它的源模型有著不同的表示形式,相應(yīng)的 CMMI 也有“連續(xù)式”和“階段式”兩種不同的表示方法,?!斑B續(xù)式”模型沒有規(guī)定在流程改進過程中對于過程域選擇的次序,各個組織根據(jù)自己的實際情況來選擇從那些過程域入手,;“階段式”模型則為流程改進提供了預(yù)定義的路線圖,,每一個階都有一組相應(yīng)的過程域,如果滿足了某一階段中的所有過程域目標,,我們稱該組織達到了該成熟度等級,。?
應(yīng)用IBM SDP 幫助 CMMI?流程改進實踐
IBM SDP 為流程改進提供了工程技術(shù)手段?
CMMI 為軟件組織的流程改進提供了一個系統(tǒng)的框架,但是它所提供的只是一個流程框圖架,,在實踐過程中還需要具體工程技術(shù)的支持,。如對于CMMI 中的每一個目標,CMMI 定義了一組特性實踐和共性實踐來達到該目標,,但這些實踐只是提出了在具體實踐過程應(yīng)該注意的事項,,并沒有列出具體可采用的工程技術(shù)。因為作為一個標準,,它不可能局陷在某一特定的工程技術(shù)之上,,不同的軟件組織可以采用不同的技術(shù)手段來達到相同的目標。?
IBM 的 SDP 正好作為一種特定的工程技術(shù)解決方案為 CMMI 流程改進提供了一種具體可操作的實踐手段,。以下以 CMMI 中兩個相關(guān)的過程域“需求管理”和“需求開發(fā)”為例,,展示 IBM SDP 解決方案是如何來實現(xiàn)每一個特定目標的。?CMMI 過程域“需求管理”的SDP 實現(xiàn)
CMMI 模型元素 |
描述 |
IBM SDP 解決方案 |
目的? |
需求管理 - 管理項目中產(chǎn)品和構(gòu)件的需求,,從而能夠及時發(fā)現(xiàn)需求,、項目計劃和工作產(chǎn)品之間的不一致性? |
RUP 需求方法集提供支撐該流程域的所有目標和實踐? |
SG1? |
管理需求,,及時發(fā)現(xiàn)需求和項目計劃以及其他工作產(chǎn)品之間的不一致性? |
RUP 中對于需求進行了分類(業(yè)務(wù)需要、產(chǎn)品特性,、軟件需求等),,并在不同的需求類型之間和其他工作產(chǎn)品之間建立追蹤關(guān)聯(lián),以此來管理開發(fā)過程中所產(chǎn)生的不一致性? |
SP 1.1? |
與需求提供者在需求的含義上達成一致理解? |
RUP 建議采用用例" title="用例">用例模型的方式來描述需求,,從而最大限度地保證雙方對于需求的理解是一致的? |
SP 1.2? |
從項目參與者那里獲得需求的承諾? |
RUP 中的前景(Vision)文檔定義了項目開發(fā)的目標和范圍,,并需要獲得項目參與者的認可? |
SP 1.3? |
在項目的發(fā)展過程中管理需求的變更? |
ClearQuest 為產(chǎn)品生命周期過程中的需求變更提供了全程的控制? |
SP 1.4? |
維護需求和需求、項目計劃以及其他工作產(chǎn)品之間的雙向追蹤性? |
RequisitePro 提供了不同類型的需求之間以及從需求到設(shè)計,、測試用例等其他工作產(chǎn)品之間的追蹤性? |
SP 1.5? |
發(fā)現(xiàn)需求和項目計劃以及其他工作產(chǎn)品之間的不一致性? |
通過追蹤性關(guān)聯(lián),,RequisitePro 可以自動地報告需求和其他工作產(chǎn)品之間所產(chǎn)生的不一致性? |
CMMI 過程域“需求開發(fā)”的SDP 實現(xiàn)
CMMI 模型元素 |
描述 |
IBM SDP 解決方案 |
目的? |
需求開發(fā) - 開發(fā)并分析客戶、產(chǎn)品和構(gòu)件的需求? |
|
SG 1? |
收集涉眾的需要,、期望,、約束和接口,并將其轉(zhuǎn)換成為客戶需求? |
RUP 需求方法集中的“理解涉眾需要”這一工作流" title="工作流">工作流明細詳細定義了如何收集涉眾需要的過程? |
SP 1.1? |
收集涉眾在產(chǎn)品生命周期各個階段的需要,、期望,、約束和接口? |
同上? |
SP 1.2? |
將涉眾的需要、期望,、約束和接口轉(zhuǎn)換成為客戶需求? |
RUP 需求方法集中的“定義系統(tǒng)”這一工作流明細詳細定義了如何將涉眾需要轉(zhuǎn)換成為客戶需求的過程? |
SG 2? |
對客戶需求進行提煉和細化來開發(fā)產(chǎn)品和構(gòu)件需求? |
RUP 中將客戶需求進一步提煉成為產(chǎn)品特性? |
SP 2.1? |
基于客戶需求來建立和維護產(chǎn)品和構(gòu)件需求? |
同上? |
SP 2.2? |
為每一個構(gòu)件分配需求? |
可以為每一個構(gòu)件(子系統(tǒng))定義一個用例模型來將系統(tǒng)需求分配下去? |
SP 2.3? |
標識接口需求? |
用例模型定義的就是系統(tǒng)對外的接口? |
SG 3? |
分析和確認需求,,并開發(fā)一個所需要的功能性定義? |
RUP 中利用用例模型來描述系統(tǒng)所有的功能性需求? |
SP 3.1? |
建立和維護操作概念及相關(guān)場景? |
每一個用例都包含了多個相關(guān)的應(yīng)用場景? |
SP 3.2? |
建立和維護一個所需要的功能性定義? |
用例建模技術(shù)可以詳盡地描述所有的系統(tǒng)功能? |
SP 3.3? |
分析已獲得的需求,確保他們是必要和充分的? |
通過業(yè)務(wù)需要,、產(chǎn)品特性和軟件需求之間的追蹤性,,確保了所有的需求都是必要和充分的? |
SP 3.4? |
分析需求來綜合考慮涉眾的需要和約束(從而決定項目成本、進度,、性能,、功能、可重用性,、可維護性,、風(fēng)險等)? |
需求是項目經(jīng)理進行項目計劃的重要輸入? |
SP 3.5? |
確認需求,保證生成的產(chǎn)品能夠在用戶不同的技術(shù)環(huán)境中按要求來工作? |
RUP 中的迭代化開發(fā)方法在每一個迭代中都對產(chǎn)品需求進行確認和驗證,,以保證生成的產(chǎn)品是可用的? |
方法和工具并重?
需要避免的一個常見誤解是 IBM SDP 不僅僅是一個軟件工程工具集合,,其中更重要的是包含了一整套指導(dǎo)軟件工程實踐的方法論,具體體現(xiàn)在 Rational Unified Process 和 Rational SUMMIT Ascendant 這兩個產(chǎn)品中,。我們在使用 IBM SDP 中的所有工具時都離不開相關(guān)方法論的指導(dǎo),,在開發(fā)的過程中掌握一個好的開發(fā)方法是成功的關(guān)鍵,工具只有在好的開發(fā)方法的指導(dǎo)下才能發(fā)揮作用,;反過來好的方法也需要高效的工具支持來提高工作效率和質(zhì)量,,兩者是相輔相成的。?
在 CMMI 流程改進的過程中,,很多過程域目標可以通過部署工具平臺來直接完成,,也有一些目標需要應(yīng)用 RUP 或 SUMMIT 中的流程方法來實現(xiàn),,尤其是一些涉及到與其他軟件團隊和個人協(xié)作的過程域目標,如供應(yīng)商合同管理和組織級過程管理等,,更多地是要實踐 IBM SDP 中方法流程,。?
另外,CMMI 非常強調(diào)流程的制度化(Institutionalization),,通過提升流程的制度化水平(”Performed” -> “Managed” -> “Defined” -> “Quantitatively Managed” -> “Optimizing”)來不斷地改進現(xiàn)有的開發(fā)流程,,這部分要求直接體現(xiàn)在共性目標和實踐中。這就要求軟件組織的各級管理層" title="管理層">管理層非常重視和支持相關(guān)的流程改進工作,,制定各種規(guī)章制度來保證流程的實踐,;并且要做好全體項目開發(fā)人員的培訓(xùn)工作,讓他們認識流程改進的目標和過程,,將流程改進工作落實到項目開發(fā)的每一個環(huán)節(jié),。?
總結(jié)
總之,基于 CMMI 模型的流程改進是一項非常艱巨而復(fù)雜的工作,,并不是應(yīng)用某一些工具平臺就可以達到相應(yīng)的成熟度等級,。在流程改進的過程中,經(jīng)常需要對現(xiàn)有的工作流程做出一些痛苦的改動,,所以取得管理層和所有相關(guān)人員的支持是一個關(guān)鍵,。另外要明確流程改進的目的,,必須把流程改進與業(yè)務(wù)目標聯(lián)系起來,,這樣才能夠取得實際有效的結(jié)果,否則易流于形式而達不到實際的效果,。?