軟件開發(fā)過程學(xué)習(xí)總結(jié)
目的：初步理解CMM、RUP、XP分別是怎樣的過程，弄懂其關(guān)鍵步驟，分析其優(yōu)劣及適應(yīng)情況。最后綜各家之長，給出一個可能較實用可行的軟件開發(fā)過程體系X Process，以用在項目(或產(chǎn)品)開發(fā)中。
By Robin Zhang. http://robinzhang.cnblogs.com/ MSN:Robinsz@hotmail.com
一、 CMM
1. 綜述
CMM2－CMM3，可以看作是一個嚴謹?shù)?，傳統(tǒng)瀑布式的開發(fā)體系。
CMM并未提供具體的過程體系，它只是一個評價標準(“軟件能力成熟度”)。
但它提供了一個目標：一個可重復(fù)賦值成功經(jīng)驗的開發(fā)體系應(yīng)該是怎樣的。
知識點：
1).通常應(yīng)該從CMM2開始實現(xiàn)，一般做到CMM3的已經(jīng)難得了。
2).CMM2是一套已定義的項目管理過程，CMM3是總結(jié)不同項目的經(jīng)驗，最終形成組織（公司）的一套過程標準。
3).可以考慮交叉引用，即上CMM2及CMM3的培訓(xùn)、同行評審。
4).CMM與CMMI的區(qū)別：前者僅限于軟件工程,后者還包括其他學(xué)科的CMM，如系統(tǒng)工程等；前者一般意味著瀑布過程，后者支持迭代方法。
參考：
CMM2:“定義了項目管理過程，將項目劃分成幾個明確定義的階段，每個階段結(jié)束都是控制點，增加了軟件開發(fā)過程的透明度和可控性。項目執(zhí)行中好的經(jīng)驗可以在別的項目中重復(fù)，軟件開發(fā)有了一定的保證。”
CMM3: “是對CMM 2 項目管理的全面整合和提高，綜合公司所有類型項目的過程經(jīng)驗，制定公司統(tǒng)一的最佳過程，增加了對項目每個階段的內(nèi)部過程規(guī)定和檢查點，使得軟件開發(fā)工程更加透明和可控。”
2. 關(guān)鍵過程
包括：
CMM2：項目計劃、需求管理、配置管理、質(zhì)量管理、項目過程控制。
CMM3：同行評審(需求、設(shè)計、代碼評審)、培訓(xùn)計劃、體系規(guī)范
注：能做到上面8項就可以了。
|
CMM等級
|
關(guān)鍵域 KPA
|
對應(yīng)產(chǎn)出、流程操作
|
相關(guān)產(chǎn)出、過程(參考)
|
|
CMM2
|
需求管理
|
需求基線
|
項目建議書,概要需求,需求評審,需求規(guī)格書
|
|
軟件項目計劃
|
建立一個合理有效的軟件項目計劃
|
軟件項目立項書、風(fēng)險分析控制報告等
|
|
軟件項目跟蹤和監(jiān)督
|
項目管理,過程管理
|
任務(wù)分解、下達，每日耗費，每周例會，單元測試報告，里程碑等
|
|
軟件配置管理
|
標識軟件配置項，建立產(chǎn)品基線庫，對配置項的修改加以系統(tǒng)的控制
|
配置管理計劃,VSS代碼庫,版本,代碼同步,演示帳套
|
|
軟件質(zhì)量管理
|
單元測試、功能測試、繼承測試等
|
質(zhì)量保證計劃,測試計劃,測試用例,產(chǎn)品質(zhì)量報告,單元測試、功能測試、繼承測試等
|
|
子合同管理
|
外包管理
|
|
|
CMM3
|
同行評審
|
|
需求評審,設(shè)計評審,代碼評審
|
|
培訓(xùn)計劃
|
|
知識共享,內(nèi)部培訓(xùn),VSS共享,創(chuàng)新獎等
|
|
組織級過程焦點，組織級過程定義，集成軟件管理，軟件產(chǎn)品工程，組間協(xié)調(diào)，
|
|
1.各種規(guī)范：需求、分析設(shè)計、編碼、
數(shù)據(jù)庫規(guī)范。
2.體系規(guī)定文檔
|
3. 適用情況
1).中大型軟件企業(yè)，同時進行多個項目、產(chǎn)品的研發(fā)（必須有一套體系以便管理、控制）。
2).需求比較明確，并已經(jīng)定義凍結(jié)的情況，如產(chǎn)品項目。
3)適合用瀑布式過程開發(fā)的項目。
4. 優(yōu)劣
優(yōu)點：體系嚴謹，提高了軟件開發(fā)過程的透明度和可控性，令項目成功經(jīng)驗可以重復(fù)復(fù)制。
缺點：因瀑布過程需要，要求需求凍結(jié)，導(dǎo)致需求過程要求非常高。而在項目中，需求變更是不可避免的。
5. 其他
企業(yè)上到一定規(guī)模，偏重產(chǎn)品開發(fā)時，可以考慮上CMM。中小軟件企業(yè)可借鑒并精簡地實現(xiàn)它的關(guān)鍵過程，如項目計劃、需求管理、配置管理、質(zhì)量管理、項目過程控制、同行評審、培訓(xùn)計劃。
二、 RUP
1． 綜述
RUP是一個由用例驅(qū)動、以架構(gòu)為中心的、迭代增量的開發(fā)過程框架。
2． 關(guān)鍵過程
迭代開發(fā)過程及產(chǎn)出：見：《UML和設(shè)計模式》第一頁。
|
流程
|
工件
|
初始
|
精化
|
構(gòu)造
|
交付
|
|
項目管理
|
軟件開發(fā)計劃等
|
S:1)定義項目目的，范圍、約束。
2)第一個迭代計劃
|
1） 分析需求用例，確定迭代計劃(任務(wù)時間表)。
2） 確定編碼等規(guī)范
3） 需求基線
|
1）按迭代計劃進行開發(fā)
2）每個迭代都實現(xiàn)一個用例集，包含一個設(shè)計編碼測試過程。
|
客戶測試評估
上線運行
|
|
業(yè)務(wù)建模
|
領(lǐng)域模型
|
|
S 細化建模
|
|
|
|
需求
|
用例模型、需求規(guī)格說明書、補充需求文檔
|
S:1)確定Actor及其需要。2)確定最重要的用例
|
R 1)編寫詳細用例需求規(guī)格書 2)確定更多用戶需要、產(chǎn)品特性、用例集合并確定其優(yōu)先級重要性風(fēng)險。需求初步基線。
|
r迭代過程中允許需求變更，但必須受控，分析對目前需求的影響，再決定是否在下一個迭代基線進去。
|
|
|
設(shè)計
|
設(shè)計模型、軟件架構(gòu)文檔
|
|
R挑選部分重要用例，開始建設(shè)計模型
|
R對迭代內(nèi)的用例進行更詳細的設(shè)計
|
|
|
實現(xiàn)
|
實現(xiàn)代碼
|
|
S 1）實現(xiàn)部分重要且風(fēng)險大的用例，以驗證并確定架構(gòu)設(shè)計。
|
R 全力編碼，按時完成迭代內(nèi)的用例實現(xiàn)。
|
|
|
測試
|
測試用例
|
|
S根據(jù)用例編寫測試用例
|
測試已實現(xiàn)迭代功能，編寫新迭代的測試用例
|
|
|
文檔等
|
使用文檔等
|
|
s
|
|
產(chǎn)品文檔，用戶培訓(xùn)
|
|
產(chǎn)出
|
|
項目計劃書(前景文檔)、高層用例模型、最重要用例規(guī)格說明書、(概要設(shè)計說明書？)、開發(fā)環(huán)境(總體軟件架構(gòu)、開發(fā)規(guī)范)
|
80%詳細需求規(guī)格書(用例集及補充說明書)、用例模型、領(lǐng)域模型及設(shè)計模型，部分詳細設(shè)計文檔，部分測試用例，產(chǎn)生一個可執(zhí)行的原型(實現(xiàn)部分重要用例)
|
內(nèi)部發(fā)版，可用于測試的完整產(chǎn)品。詳細設(shè)計說明書
|
|
|
產(chǎn)出2
|
|
項目計劃、概要需求列表、初步架構(gòu)說明、重要用例需求規(guī)格書、編碼規(guī)范
|
需求規(guī)格說明書(80%)，概要設(shè)計文檔(?)、項目迭代計劃、重要用例的設(shè)計及實現(xiàn),
|
設(shè)計模型，詳細設(shè)計說明書，代碼實現(xiàn)，測試用例（迭代）
|
產(chǎn)品、說明文檔，用戶培訓(xùn)
|
s開始，r精化提煉
3． 適用情況
4． 優(yōu)劣
5． 其他
參考：
三、 XP
Xp注重人的因數(shù)，提倡盡量敏捷輕量級的過程。
重要過程：測試驅(qū)動、迭代開發(fā)、持續(xù)集成構(gòu)建、客戶現(xiàn)場參與(確定迭代內(nèi)的功能集，提供業(yè)務(wù)邏輯的確認，驗證程序等)、只在必要時做簡單設(shè)計
一)、Xp的缺點：
1. 要求客戶現(xiàn)場參與。通常國內(nèi)項目都是前期作需求確認，無法提供整個開發(fā)過程的需求確認支持。除非是分段來確認（如迭代結(jié)束時）。
2. 測試驅(qū)動開發(fā)。目前還很難做到，因為編寫測試腳本需要花費不少精力，一般項目無法做到。由此也無法作重構(gòu)，無法保證能有靈活的設(shè)計來支持因前期不明確的需求而導(dǎo)致的變更。
3. 缺少文檔、設(shè)計支持。Xp只在必要時才寫文檔及設(shè)計，這樣可能導(dǎo)致xp新手缺乏良好的設(shè)計指引，項目開發(fā)過程透明度不夠，可能會失控。
二）、xp可借鑒的地方
1. 對整個開發(fā)過程：迭代開發(fā)、持續(xù)集成
2. 對特定迭代：編碼規(guī)范、保持設(shè)計靈活(允許需求改動)
3. 設(shè)計編碼過程：測試驅(qū)動、重構(gòu)(用在編碼過程中，以客戶端來“測試驅(qū)動”業(yè)務(wù)邏輯層、以重構(gòu)減少重復(fù)代碼)
參考：
四、實用過程X Process：RUP+XP，并達到CMM2-3
考慮目前國內(nèi)項目現(xiàn)況：需求調(diào)研先行，但需求不明確導(dǎo)致需求變更。中小公司缺乏過程規(guī)范指導(dǎo)，基本在CMM1即混亂狀態(tài)。
X Process ＝ CMM的體系+RUP的過程+XP的最佳實踐
參考文檔：xp_vs_cmm.pdf, RUPvsXP.pdf, RUP and XP.pdf,dX Process
1. 過程：取RUP的過程
過程還是取項目啟動、細化、構(gòu)建、交付四個過程。
啟動階段：
定義項目計劃、風(fēng)險分析、項目前景、范圍、約束；確定Actor、涉眾及收益；確定概要需求；作一個原型，實現(xiàn)關(guān)鍵用例。
細化階段：
確定用戶需要、產(chǎn)品特性并確認優(yōu)先級、風(fēng)險；確定80%需求，編寫需求規(guī)格書。制定迭代計劃，需求基線；完成重要用例的設(shè)計及實現(xiàn)，由此確定系統(tǒng)架構(gòu)及第三方組件。已制定迭代計劃。同時編寫對應(yīng)用例的測試用例。
構(gòu)建階段：
按計劃迭代開發(fā)。在每個迭代里采用小瀑布的方式，應(yīng)用部分XP的最佳實踐(見下2)，每個迭代為一個里程碑，提交給客戶確認，由此得到需求變更，分析后調(diào)整迭代計劃。
交付階段：
提交客戶測試，作小的修改。編寫產(chǎn)品說明，用戶培訓(xùn)，上線運行。項目總結(jié)、關(guān)閉報告。
2. 迭代內(nèi)的步驟：取xp的最佳實踐
合并細化的后期+構(gòu)造期，為“設(shè)計編程期”，在這期間，啟用“保持設(shè)計靈活”、編碼規(guī)范、代碼審核(結(jié)隊編程)、持續(xù)集成、測試驅(qū)動、重構(gòu)的最佳實踐。
3. 使用CMM的關(guān)鍵域的規(guī)范流程，，以達到CMM2-3的效果
在RUP的四個階段中，應(yīng)用CMM的關(guān)鍵域，來保證各種產(chǎn)出的質(zhì)量。如下：
先啟階段：項目計劃、項目過程控制、配置管理、培訓(xùn)計劃(設(shè)計、編碼規(guī)范)
細化階段：體系規(guī)范、同行評審(需求、設(shè)計、代碼評審)、需求管理、質(zhì)量管理
構(gòu)建階段：編碼規(guī)范、設(shè)計、代碼評審、需求變更管理
交付階段：體系規(guī)范
三者的關(guān)系如下：
1. RUP：是由用例驅(qū)動、迭代增量開發(fā)的過程，主要定義了各個階段應(yīng)該做什么，做到什么程度。
2. CMM：是一套評估標準，提供了一些關(guān)鍵實現(xiàn)域(需求管理等)，對每一個產(chǎn)出提出了質(zhì)量要求。
3. XP：主要關(guān)注編碼階段的一些最佳實踐。是一個提倡敏捷的輕量級軟件開發(fā)方法。強調(diào)“交流；簡單；反饋；實事求是”。強調(diào)客戶參與，簡單設(shè)計(靈活設(shè)計)、允許需求變更等。
4. 下面是按傳統(tǒng)瀑布式的過程，來考察三種過程方法在各個階段的活動及產(chǎn)出。
|
過程
|
RUP
|
CMM
|
XP
|
|
項目啟動
|
先啟
|
項目計劃、風(fēng)險列表、過程控制、配置計劃、概要需求列表等
|
客戶盡可能參與
|
|
需求調(diào)研
|
先啟、精化(用例模型)
|
需求管理、需求評審、需求基線
|
客戶盡可能參與
|
|
分析設(shè)計
|
精化、構(gòu)建(領(lǐng)域模型、設(shè)計模型)
|
設(shè)計評審、軟件配置、培訓(xùn)計劃
|
靈活設(shè)計、需求變更
|
|
編碼實現(xiàn)
|
構(gòu)建、啟動、精華(代碼)
|
代碼評審、需求變更控制
|
測試驅(qū)動開發(fā)、重構(gòu)、編碼規(guī)范、日構(gòu)建、小版本發(fā)布、簡單實現(xiàn)
|
|
測試
|
構(gòu)建、精化
|
質(zhì)量管理
|
Unit Test
|
|
文檔及實施等
|
交付
|
|
|
