【文章內容簡介】 力成熟度”)。但它提供了一個目標：一個可重復賦值成功經驗的開發(fā)體系應該是怎樣的。知識點：1).通常應該從CMM2開始實現，一般做到CMM3的已經難得了。2).CMM2是一套已定義的項目管理過程，CMM3是總結不同項目的經驗，最終形成組織（公司）的一套過程標準。3).可以考慮交叉引用，即上CMM2及CMM3的培訓、同行評審。4).CMM與CMMI的區(qū)別：前者僅限于軟件工程,后者還包括其他學科的CMM，如系統(tǒng)工程等；前者一般意味著瀑布過程，后者支持迭代方法。參考：CMM2:“定義了項目管理過程，將項目劃分成幾個明確定義的階段，每個階段結束都是控制點，增加了軟件開發(fā)過程的透明度和可控性。項目執(zhí)行中好的經驗可以在別的項目中重復，軟件開發(fā)有了一定的保證?！盋MM3: “是對CMM 2 項目管理的全面整合和提高，綜合公司所有類型項目的過程經驗，制定公司統(tǒng)一的最佳過程，增加了對項目每個階段的內部過程規(guī)定和檢查點，使得軟件開發(fā)工程更加透明和可控?！?. 關鍵過程包括：CMM2：項目計劃、需求管理、配置管理、質量管理、項目過程控制。CMM3：同行評審(需求、設計、代碼評審)、培訓計劃、體系規(guī)范注：能做到上面8項就可以了。CMM等級關鍵域 KPA對應產出、流程操作相關產出、過程(參考)CMM2需求管理需求基線項目建議書,概要需求,需求評審,需求規(guī)格書軟件項目計劃建立一個合理有效的軟件項目計劃軟件項目立項書、風險分析控制報告等 軟件項目跟蹤和監(jiān)督項目管理,過程管理任務分解、下達，每日耗費，每周例會，單元測試報告，里程碑等軟件配置管理標識軟件配置項，建立產品基線庫，對配置項的修改加以系統(tǒng)的控制配置管理計劃,VSS代碼庫,版本,代碼同步,演示帳套軟件質量管理單元測試、功能測試、繼承測試等質量保證計劃,測試計劃,測試用例,產品質量報告,單元測試、功能測試、繼承測試等子合同管理外包管理　CMM3同行評審需求評審,設計評審,代碼評審培訓計劃知識共享,內部培訓,VSS共享,創(chuàng)新獎等組織級過程焦點，組織級過程定義，集成軟件管理，軟件產品工程，組間協(xié)調，　：需求、分析設計、編碼、數據庫規(guī)范。3. 適用情況1).中大型軟件企業(yè)，同時進行多個項目、產品的研發(fā)（必須有一套體系以便管理、控制）。2).需求比較明確，并已經定義凍結的情況，如產品項目。3)適合用瀑布式過程開發(fā)的項目。4. 優(yōu)劣優(yōu)點：體系嚴謹，提高了軟件開發(fā)過程的透明度和可控性，令項目成功經驗可以重復復制。缺點：因瀑布過程需要，要求需求凍結，導致需求過程要求非常高。而在項目中，需求變更是不可避免的。5. 其他企業(yè)上到一定規(guī)模，偏重產品開發(fā)時，可以考慮上CMM。中小軟件企業(yè)可借鑒并精簡地實現它的關鍵過程，如項目計劃、需求管理、配置管理、質量管理、項目過程控制、同行評審、培訓計劃。二、 RUP1． 綜述RUP是一個由用例驅動、以架構為中心的、迭代增量的開發(fā)過程框架。2． 關鍵過程迭代開發(fā)過程及產出：見：《UML和設計模式》第一頁。流程工件初始精化構造交付項目管理軟件開發(fā)計劃等S:1)定義項目目的，范圍、約束。2)第一個迭代計劃1） 分析需求用例，確定迭代計劃(任務時間表)。2） 確定編碼等規(guī)范3） 需求基線1）按迭代計劃進行開發(fā)2）每個迭代都實現一個用例集，包含一個設計編碼測試過程?？蛻魷y試評估上線運行業(yè)務建模領域模型S 細化建模需求用例模型、需求規(guī)格說明書、補充需求文檔S:1)確定Actor及其需要。2)確定最重要的用例R 1)編寫詳細用例需求規(guī)格書 2)確定更多用戶需要、產品特性、用例集合并確定其優(yōu)先級重要性風險。需求初步基線。r迭代過程中允許需求變更，但必須受控，分析對目前需求的影響，再決定是否在下一個迭代基線進去。設計設計模型、軟件架構文檔R挑選部分重要用例，開始建設計模型R對迭代內的用例進行更詳細的設計實現實現代碼S 1）實現部分重要且風險大的用例，以驗證并確定架構設計。R 全力編碼，按時完成迭代內的用例實現。測試測試用例S根據用例編寫測試用例測試已實現迭代功能，編寫新迭代的測試用例文檔等使用文檔等s產品文檔，用戶培訓產出項目計劃書(前景文檔)、高層用例模型、最重要用例規(guī)格說明書、(概要設計說明書？)、開發(fā)環(huán)境(總體軟件架構、開發(fā)規(guī)范) 80%詳細需求規(guī)格書(用例集及補充說明書)、用例模型、領域模型及設計模型，部分詳細設計文檔，部分測試用例，產生一個可執(zhí)行的原型(實現部分重要用例) 內部發(fā)版，可用于測試的完整產品。詳細設計說明書產出2項目計劃、概要需求列表、初步架構說明、重要用例需求規(guī)格書、編碼規(guī)范需求規(guī)格說明書(80%)，概要設計文檔(?)、項目迭代計劃、重要用例的設計及實現,設計模型，詳細設計說明書，代碼實現，測試用例（迭代）產品、說明文檔，用戶培訓s開始，r精化提煉3． 適用情況4． 優(yōu)劣5． 其他參考：三、 XPXp注重人的因數，提倡盡量敏捷輕量級的過程。重要過程：測試驅動、迭代開發(fā)、持續(xù)集成構建、客戶現場參與(確定迭代內的功能集，提供業(yè)務邏輯的確認，驗證程序等)、只在必要時做簡單設計一)、Xp的缺點：1. 要求客戶現場參與。通常國內項目都是前期作需求確認，無法提供整個開發(fā)過程的需求確認支持。除非是分段來確認（如迭代結束時）。2. 測試驅動開發(fā)。目前還很難做到，因為編寫測試腳本需要花費不少精力，一般項目無法做到。由此也無法作重構，無法保證能有靈活的設計來支持因前期不明確的需求而導致的變更。3. 缺少文檔、設計支持。Xp只在必要時才寫文檔及設計，這樣可能導致xp新手缺乏良好的設計指引，項目開發(fā)過程透明度不夠，可能會失控。二）、xp可借鑒的地方1. 對整個開發(fā)過程：迭代開發(fā)、持續(xù)集成2. 對特定迭代：編碼規(guī)范、保持設計靈活(允許需求改動)3. 設計編碼過程：測試驅動、重構(用在編碼過程中，以客戶端來“測試驅動”業(yè)務邏輯層、以重構減少重復代碼)參考：四、實用過程X Process：RUP+XP，并達到CMM23考慮目前國內項目現況：需求調研先行，但需求不明確導致需求變更。中小公司缺乏過程規(guī)范指導，基本在CMM1即混亂狀態(tài)。X Process ＝ CMM的體系+RUP的過程+XP的最佳實踐參考文檔：, , RUP and ,dX Process1. 過程：取RUP的過程過程還是取項目啟動、細化、構建、交付四個過程。啟動階段：定義項目計劃、風險分析、項目前景、范圍、約束；確定Actor、涉眾及收益；確定概要需求；作一個原型，實現關鍵用例。細化階段：確定用戶需要、產品特性并確認優(yōu)先級、風險；確定80%需求，編寫需求規(guī)格書。制定迭代計劃，需求基線；完成重要用例的設計及實現，由此確定系統(tǒng)架構及第三方組件。已制定迭代計劃。同時編寫對應用例的測試用例。 構建階段：按計劃迭代開發(fā)。在每個迭代里采用小瀑布的方式，應用部分XP的最佳實踐(見下2)，每個迭代為一個里程碑，提交給客戶確認，由此得到需求變更，分析后調整迭代計劃。 交付階段：提交客戶測試，作小的修改。編寫產品說明，用戶培訓，上線運行。項目總結、關閉報告。2. 迭代內的步驟：取xp的最佳實踐合并細化的后期+構造期，為“設計編程期”，在這期間，啟用“保持設計靈活”、編碼規(guī)范、代碼審核(結隊編程)、持續(xù)集成、測試驅動、重構的最佳實踐。3. 使用CMM的關鍵域的規(guī)范流程，以達到CMM23的效果在RUP的四個階段中，應用CMM的關鍵域，來保證各種產出的質量。如下：先啟階段：項目計劃、項目過程控制、配置管理、培訓計劃(設計、編碼規(guī)范)細化階段：體系規(guī)范、同行評審(需求、設計、代碼評審)、需求管理、質量管理構建階段：編碼規(guī)范、設計、代碼評審、需求變更管理交付階段：體系規(guī)范三者的關系如下：1. RUP：是由用例驅動、迭代增量開發(fā)的過程，主要定義了各個階段應該做什么，做到什么程度。2. CMM：是一套評估標準，提供了一些關鍵實現域(需求管理等)，對每一個產出提出了質量要求。3. XP：主要關注編碼階段的一些最佳實踐。是一個提倡敏捷的輕量級軟件開發(fā)方法。強調“交流；簡單；反饋；實事求是”。強調客戶參與，簡單設計(靈活設計)、允許需求變更等。4. 下面是按傳統(tǒng)瀑布式的過程，來考察三種過程方法在各個階段的活動及產出。過程RUPCMMXP項目啟動先啟項目計劃、風險列表、過程控制、配置計劃、概要需求列表等客戶盡可能參與需求調研先啟、精化(用例模型)需求管理、需求評審、需求基線客戶盡可能參與分析設計精化、構建(領域模型、設計模型)設計評審、軟件配置、培訓計劃靈活設計、需求變更編碼實現構建、啟動、精華(代碼)代碼評審、需求變更控制測試驅動開發(fā)、重構、編碼規(guī)范、日構建、小版本發(fā)布、簡單實現測試構建、精化質量管理Unit Test文檔及實施等交付RUP與Scrum的對話作者：IBM摘要　　現在使用RUP的軟件項目可以很容易地從Scrum原則中獲益，即使已經開始的項目也是如此。首先需要調研的是RUP過程模型，Scrum如何影響RUP最好的實踐活動，四個階段（初始，細化，構建和產品化），以及RUP的九個原則。 來自于 Rational Edge：本文介紹了被稱為Scrum的靈活軟件開發(fā)過程。作者闡述了軟件開發(fā)團隊在已有RUP環(huán)境中加入Scrum理念的技術。 正如你所知道的，RUP（Rational Unified Process，Rational 統(tǒng)一過程），是一種被廣泛使用的軟件過程框架。它可以很好地迎合你的軟件開發(fā)過程的需要，還可以容納其他技術。Scrum是一系列有趣的，用來包裝靈活軟件項目的項目管理模式。本文介紹了Scrum的一些重要特性，并闡述了可以讓你在已有RUP環(huán)境中加入Scrum理念的技術。我在工具條內提供了關于Scrum和“靈活”的術語的詞匯表，并且在下文中這些術語首次出現的地方用星號作了標記。 什么是Scrum？ Scrum是一種靈活的軟件管理過程，它可以幫助你駕馭迭代，遞增的軟件開發(fā)過程。Scrum于1995年由Advanced Development Methodologies,Inc提出，并在2001年“敏捷聯盟（Agile Alliance）”形成后受到了更多歡迎。這個輕量的過程可以作為包裝器，也就是說你可以把Scrum與其它靈活的過程框架組合起來，比如說RUP。 Scrum提供了一種經驗方法，它使得團隊成員能夠獨立地，集中地在創(chuàng)造性的環(huán)境下工作。它發(fā)現了軟件工程的社會意義。Scrum一詞來源于橄欖球運動，暗指這種情況：“在橄欖球比賽中，雙方前鋒站在一起緊密相連，當球在他們之間投擲時他們奮力爭球。2 ” 這一過程是迅速，有適應性，自組織的，它代表了從順序開發(fā)過程以來的重大變化。Scrum認為軟件的開發(fā)不應使用和一般制造業(yè)相同的方法，也就是不應采用一種反復的模式。這種重復使得輸入和輸出參數更加容易預測和描