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