CMMI生命周期模型選用指引

編碼：SHZIM-O-OPD-P02xxxx技術(shù)股份有限公司生命周期模型選用指南擬制人 日期2014年07月03日審核人日期年月日批準(zhǔn)人日期年月日

更改控制頁序號版本號更改時間更改內(nèi)容描述填寫人12TOC\o"1-5"\h\z\o"CurrentDocument"目的 0\o"CurrentDocument"范圍 0\o"CurrentDocument"模型介紹 0\o"CurrentDocument"瀑布模型 0\o"CurrentDocument"模型說明 0\o"CurrentDocument"模型分析 0\o"CurrentDocument"迭代模型 1\o"CurrentDocument"模型說明 1\o"CurrentDocument"模型分析 2\o"CurrentDocument"快速原型模型 2\o"CurrentDocument"模型說明 2\o"CurrentDocument"模型分析 3\o"CurrentDocument"精簡模型 3\o"CurrentDocument"模型說明 3\o"CurrentDocument"模型分析 4\o"CurrentDocument"V模型 5\o"CurrentDocument"模型說明 5模型分析 5\o"CurrentDocument"模型選擇 7\o"CurrentDocument"模型選擇原則 7\o"CurrentDocument"項目分類 7\o"CurrentDocument"模型選擇指南 81目的描述適合公司現(xiàn)狀、可供項目選擇的組織級生命周期模型2范圍公司所有軟件項目。3模型介紹3.1瀑布模型模型說明對于需求比較明確的項目，可以使用瀑布模型進行項目開發(fā)，每個階段的輸入都是依靠上一個階段的輸出，每個階段內(nèi)都需要完成與最終產(chǎn)品相關(guān)的所有工作。模型分析優(yōu)點：可以明確劃分項目的各個階段，便于管理；項目成員只需要在被安排的階段開展項目工作，不需要全程參與；階段工作內(nèi)容清晰，降低了開發(fā)難度。缺點：對項目的啟動條件要求較高；若出現(xiàn)需求不明確或設(shè)計開發(fā)技術(shù)瓶頸，將會影響后續(xù)階段的工作啟動;最終產(chǎn)品提交給用戶確認(rèn)的時間比較晚，存在一定的風(fēng)險。模型參照參見《瀑布模型》。3.2迭代模型模型說明通常有許多項目不能在需求開發(fā)階段提供準(zhǔn)確的需求，對于這樣的項目，可以選擇迭代開發(fā)模型，將能夠確定的需求分析確定下來。之后便可以對這部分確定的需求進行系統(tǒng)設(shè)計、編碼和測試。整個項目可以進行多次迭代的過程，一般情況下迭代的起點從需求開發(fā)開始，然后進行設(shè)計、編碼和測試，但是有時候也可能出現(xiàn)從設(shè)計或編碼階段安排新的迭代過程。322 模型分析優(yōu)點：項目的啟動條件比較靈活、只要用戶有基本的立項意向和需求范圍就可以開始計劃工作；可以在項目早期識別和管理風(fēng)險；可以較快的展現(xiàn)項目開發(fā)的成果，有益于增強客戶受信度和滿意度。缺點：迭代過程和范圍劃分比較復(fù)雜，項目的過程管理難度較大；產(chǎn)品的設(shè)計開發(fā)是迭代過程完成的，容易出現(xiàn)產(chǎn)品構(gòu)件兼容性問題，如果處理不當(dāng)會出大量返工的工作。3.3快速原型模型模型說明快収、驗證三：構(gòu)說.修改

需求啊確認(rèn)原型圖3快速原型模型在很多時候，需求分析人員無法通過與用戶交談就能獲得明確的、詳細(xì)的需求。這種情況可以選擇快速原型開發(fā)方法，它的主要目的就是獲得與驗證需求。首先由開發(fā)人員構(gòu)造原型，然后讓用戶試驗該原型。一般地，當(dāng)用戶面對一個可操作的軟件時，他比較容易說清楚“需要什么”和“不要什么”。從而有助于分析人員獲取更詳細(xì)的需求，以及驗證需求是否正確。不斷迭代上述過程，直至滿足用戶的所有需求為止。

3.3.2模型分析優(yōu)點：可以直觀地讓用戶確定其需求，降低了用戶對其提供的需求的不確定性。缺點：1.原型開發(fā)需要較早投入開發(fā)成本，如果原型不能在產(chǎn)品開發(fā)過程中進行復(fù)用，將會導(dǎo)致項目成本的增加。3.3.3模型參照參見《快速原型模型》3.4精簡模型模型說明對于一些規(guī)模較小、版本升級、或者是有大量可復(fù)用構(gòu)件的項目，這些項目需求相對比較明確、產(chǎn)品架構(gòu)比較成熟和穩(wěn)定，因此可以選擇精簡生命周期模型。根據(jù)項目的不同情況：可以將設(shè)計階段和編碼階段精簡為一個工程階段（如圖4）;也可將需求開發(fā)階段和設(shè)計階段精簡為一個階段、將編碼階段和測試階段精簡為一個階段（如圖5）。342 模型分析優(yōu)點：縮短開發(fā)周期、降低各階段工作的銜接工作；可以一定程度降低項目的成本。缺點：1.如果精簡方式選擇不合理，可能會造成產(chǎn)品質(zhì)量降低。模型參照參見《精簡瀑布模型-1》和《精簡瀑布模型-2》。

3.5V模型模型說明演變而來，由于將整個開發(fā)過程構(gòu)造成一個V字形而得名。V模型強調(diào)軟件開發(fā)的協(xié)作和速度，將軟件實現(xiàn)和驗證有機地結(jié)合起來，在保證較高的軟件質(zhì)量情況下縮短開發(fā)周期。對于一些規(guī)劃較小、版本升級、或者是有大量可復(fù)用構(gòu)件的項目，這些項目需求相對比較明確、產(chǎn)品架構(gòu)比較成熟和穩(wěn)定，因此亦可以選擇V模型。（如圖6）。模型分析從水平對應(yīng)關(guān)系看左邊是設(shè)計和分析，是軟件設(shè)計實現(xiàn)的過程，同時伴隨著質(zhì)量保證活動——審核的過程，也就是靜態(tài)的測試過程；右邊是對左邊結(jié)果的驗證，是動態(tài)測試的過程，即對設(shè)計和分析的結(jié)果進行測試，以確認(rèn)是否滿足用戶的需求。如：?需求分析和功能設(shè)計對應(yīng)驗收測試，說明在做需求分析、產(chǎn)品功能設(shè)計的同時，測試人員就可以閱讀、審查需求分析的結(jié)果，從而了解產(chǎn)品的設(shè)計特性、用戶的真正需求，確定測試目標(biāo)，可以準(zhǔn)備用例(UseCase)并策劃測試活動。?當(dāng)系統(tǒng)設(shè)計人員在做系統(tǒng)設(shè)計時，測試人員可以了解系統(tǒng)是如何實現(xiàn)的，基于什么樣的平臺，這樣可以設(shè)計系統(tǒng)的測試方案和測試計劃，并事先準(zhǔn)備系統(tǒng)的測試環(huán)境，包括硬件和第三方軟件的采購。因為這些準(zhǔn)備工作，實際上是要花去很多時間。?當(dāng)設(shè)計人員在做在做詳細(xì)設(shè)計時，測試人員可以參與設(shè)計，對設(shè)計進行評審，找出設(shè)計的缺陷，同時設(shè)計功能、新特性等各方面的測試用例，完善測試計劃，并基于這些測試用例以開發(fā)測試腳本。?在編程的同時，進行單元測試，是一種很有效的辦法，可以盡快找出程序中的錯誤，充分的單元測試可以大幅度提高程序質(zhì)量、減少成本。從中可以看出，V模型使我們能清楚地看到質(zhì)量保證活動和項目同時展開，項目一啟動，軟件測試的工作也就啟動了,避免了瀑布模型所帶來的誤區(qū)——軟件測試是在代碼完成之后進行。從垂直方向看水平虛線上部表明，其需求分析、定義和驗收測試等主要工作是面向用戶，要和用戶進行充分的溝通和交流，或者是和用戶一起完成。水平虛線下部的大部分工作，相對來說，都是技術(shù)工作，在開發(fā)組織內(nèi)部進行，主要是由工程師、技術(shù)人員完成。從垂直方向看，越在下面，白盒測試方法使用越多，到了集成、系統(tǒng)測試，更多是將白盒測試方法和黑盒測試方法結(jié)合起來使用，形成灰盒測試方法。而在驗收測試過程中，由于用戶一般要參與，使用黑盒測試方法。模型參照參見《V模型》。4模型選擇4.1模型選擇原則能夠滿足公司“開發(fā)管理方針”的要求；不會降低項目開發(fā)過程和工作產(chǎn)品的質(zhì)量；不會失去對工作進展的（跟蹤）可視性；不會失去對軟件工作產(chǎn)品的配置管理和控制，也不會額外增加無益的工作;不會降低工程師的開發(fā)效率；在維持現(xiàn)有人力資源的情況下，能夠按計劃如期完成工作；項目資金可以控制在目標(biāo)成本范圍內(nèi)。4.2項目分類類別領(lǐng)域和方法項目人員復(fù)用度需要應(yīng)對的主要風(fēng)險項目管理的重點基礎(chǔ)研究型基礎(chǔ)算法和技術(shù)的研發(fā)?？偣せ蛩惴ńM<20%技術(shù)實現(xiàn)的難度和技術(shù)風(fēng)險造成了研究的進度的風(fēng)險和實現(xiàn)的質(zhì)量風(fēng)險。積極研究國內(nèi)外先進的相關(guān)技術(shù)和研究成果，并將其快速的轉(zhuǎn)換成為可實現(xiàn)的關(guān)鍵技術(shù)。產(chǎn)品研發(fā)型根據(jù)公司的產(chǎn)品定義和規(guī)劃進行的基礎(chǔ)產(chǎn)品和架構(gòu)開發(fā)、升級的項目，用于適用某領(lǐng)域內(nèi)大多數(shù)項目運營的功能要求。總工或產(chǎn)品開發(fā)核心組<40%產(chǎn)品需求概念早期不完備，考慮的相關(guān)技術(shù)和實現(xiàn)的因素較少，需要米用原型的方式進行開發(fā)完備需求，以及采用結(jié)構(gòu)化決策的方式綜合考慮各種影響因素，造成了實現(xiàn)客戶需求，維護客戶滿意度。進行前瞻性技術(shù)研究，完成科研成果向應(yīng)用的轉(zhuǎn)換。鍛煉隊伍，發(fā)現(xiàn)新的項目目標(biāo)和機會。按期按質(zhì)實現(xiàn)項目目標(biāo)，積累客戶需求，提供確定類型客戶需求解決方案。

后續(xù)隨著開發(fā)過程進展需求概念和實現(xiàn)方式變更較多?？蛻赳庵菩驮诠井a(chǎn)品基礎(chǔ)上根據(jù)客戶的特殊需求進行局部開發(fā)的項目。目項組>70%主要是需求開發(fā)質(zhì)量不足的風(fēng)險，造成的后期需求變更較多。及早溝通和確定項目需求，精確復(fù)用，鍛煉隊伍、強化管理，協(xié)調(diào)資源，解決風(fēng)險問題，按期，按質(zhì)量完成項目要求。其/、他和公司主營業(yè)務(wù)領(lǐng)域無直接關(guān)系的項目。時目臨項組不確疋不確定。鍛煉隊伍，維護客戶關(guān)系，發(fā)現(xiàn)新的項目目標(biāo)和機會。4.3模型選擇指南公司的項目生命周期選擇參見下表項目類型需求明確生命周期模型注釋產(chǎn)品研發(fā)型明確（8