軟件生命周期模型與ＣＭＭ實施

摘要:對于采用不同軟件生命周期模型的項目在實施CMM 當(dāng)中遇到的實際問題及其產(chǎn)生機理進行了深入分析，并提出初步的解決方案，主要涉及:采用迭代式生命周期模型的項目在實施需求管理過程域的部分內(nèi)容時難以滿足CMM 的要求，建議通過擴展基線的概念，采用分步基線化#65380;分塊基線化的方法予以處理;軟件產(chǎn)品工程過程域的內(nèi)容更多地針對瀑布模型，針對迭代式生命周期的內(nèi)容較少，因而在實際使用迭代式生命周期模型時，工程活動不能局限于CMM 的內(nèi)容#65377;建議對CMM 中的工作產(chǎn)品與迭代式生命周期模型中的工作產(chǎn)品進行映射，并采用迭代式生命周期模型中的方法和概念作為替代實踐以符合軟件產(chǎn)品工程過程域的要求#65377;

關(guān)鍵詞:軟件生命周期; 軟件生命周期模型; 能力成熟度模型; 能力成熟度模型實施

中圖分類號:TP311.5文獻(xiàn)標(biāo)志碼:A

文章編號:1001-3695(2007)10-0206-05

0引言

軟件生命周期模型與能力成熟度模型(CMM)均是軟件工程領(lǐng)域的重要發(fā)展成果#65377;隨著軟件開發(fā)活動的不斷變化和發(fā)展，已經(jīng)提出諸如瀑布模型#65380;原型模型#65380;螺旋模型#65380;迭代模型等各種軟件生命周期模型，對軟件開發(fā)實踐起到了重要的指導(dǎo)作用[1]#65377;與此同時，CMM則定義了一個成熟軟件組織應(yīng)該具備的必要屬性，并提供改進路線圖來指導(dǎo)軟件組織不斷改進自身的軟件開發(fā)過程能力，目前也在業(yè)界得到廣泛應(yīng)用#65377;

在實踐中，軟件生命周期模型與CMM經(jīng)常被同時使用#65377;一個組織在運用CMM進行軟件過程改進的過程中，經(jīng)常需要面對這樣一個問題:CMM的實施與各種軟件生命周期模型之間是什么關(guān)系?回答這一問題對于CMM的實施工作具有非常重要的實際意義#65377;實施CMM的項目既要滿足CMM的要求，又要符合某種軟件生命周期模型的特點，如果對兩者特點和關(guān)聯(lián)缺乏深入理解，將給CMM實施乃至軟件開發(fā)活動帶來不良影響#65377;為此，本文將重點討論在實施CMM的過程中，CMM所要求的活動與各種軟件生命周期模型內(nèi)容之間的關(guān)系#65377;通過分析CMM中與軟件生命周期模型相關(guān)的內(nèi)容，討論CMM實施中與軟件生命周期模型有關(guān)系的一些現(xiàn)象#65377;

1CMM中與軟件生命周期模型相關(guān)的內(nèi)容

1.1CMM中明確包含軟件生命周期模型字樣的內(nèi)容

CMM的原文中沒有“software life cycle model”(軟件生命周期模型)的字樣，但有“software life cycle”(軟件生命周期)，這兩個詞匯含義差別較大#65377;

在國際標(biāo)準(zhǔn)ISO/IEC 12207《信息技術(shù)軟件生命周期過程》中，生命周期模型的定義是:一個框架，它含有遍歷系統(tǒng)從確定需求到終止使用這一生命周期的軟件產(chǎn)品的開發(fā)#65380;運行和維護中需實施的過程#65380;活動和任務(wù)#65377;[2]

IEEE對軟件生命周期的定義是:從設(shè)想一軟件產(chǎn)品開始到軟件不再供使用時為止的時間間隔[3]#65377;

從以上定義可見，軟件生命周期模型是一個過程框架，而軟件生命周期是一段時間間隔#65377;但是，CMM中部分內(nèi)容包含的“software life cycle”指的并不是一段時間間隔，如文獻(xiàn)[4]的第0~61頁:

The key practices are not meant to limit the choice of a software life cycle. People who have extensively used one particular software life cycle may perceive elements of that life cycle in the organization and structure of the key practices. However， there is no intent either to encourage or preclude the use of any particular software life cycle.

其中的“software life cycle”是名詞，而且指代的不是時間間隔，因為時間間隔無法選擇(choice)，也無法使用(use)，按照文中含義，這里應(yīng)該是指代軟件生命周期模型#65377;

CMM中另外一部分內(nèi)容中使用的“software life cycle”，其含義是軟件生命周期，本文不再贅述#65377;

分析CMM中明確包含軟件生命周期模型的內(nèi)容后可得出如下結(jié)論:CMM中關(guān)于軟件生命周期模型的內(nèi)容是貫穿整個模型的，從二級項目組的活動到三級整個組織的活動，再到四級相關(guān)質(zhì)量的活動，不同的級別有不同的要求#65377;

本文認(rèn)為，CMM對于工程活動的規(guī)范化是通過軟件生命周期模型進行的#65377;CMM通過在各個級別中對于軟件生命周期模型的規(guī)定，規(guī)范軟件組織對軟件生命周期模型的定義和使用，并提高工程活動的質(zhì)量#65377;

1.2CMM中未明確包含軟件生命周期模型字樣的內(nèi)容

通過對CMM的分析以及實踐中的經(jīng)驗，本文認(rèn)為，CMM與特定軟件生命周期模型相關(guān)的內(nèi)容體現(xiàn)在需求管理過程域和軟件產(chǎn)品工程過程域中，雖然這兩個過程域的內(nèi)容沒有明確包含軟件生命周期模型的字樣#65377;

需求管理是CMM二級的關(guān)鍵過程域，主要內(nèi)容是關(guān)于需求的管理活動;軟件產(chǎn)品工程是CMM三級的關(guān)鍵過程域，主要內(nèi)容是對于工程活動的要求#65377;

1.2.1需求管理過程域

需求管理過程域的目標(biāo)有兩個:

目標(biāo)1控制分配給軟件的系統(tǒng)需求，建立供軟件工程活動和管理活動使用的基線#65377;

目標(biāo)2保持軟件計劃#65380;產(chǎn)品和活動與指定給軟件的需求之間的一致性#65377;

其中目標(biāo)1與工程活動的關(guān)系比較密切#65377;目標(biāo)1中基線的定義是:“一種通過正式評審和認(rèn)可的規(guī)范說明或產(chǎn)品，此后將其作為進一步開發(fā)的基礎(chǔ)#65377;只有通過正式的變更控制過程才可以更改#65377;”[3]因此，目標(biāo)1的含義是在分配給軟件的系統(tǒng)需求被軟件項目組正式接收之前，由軟件項目組對其進行評審和認(rèn)可，評審?fù)ㄟ^后建立需求基線#65377;該基線作為項目軟件工程活動和管理活動的基礎(chǔ)#65377;

在該過程域的目標(biāo)2中指出，項目組要采用分配給軟件的系統(tǒng)需求作為軟件計劃#65380;工作產(chǎn)品和活動的基礎(chǔ)#65377;

CMM在該過程域的活動中，并沒有明確指出要在什么時候進行基線化，以及是否需要一次性基線化所有的需求#65377;但是，既然是供軟件工程活動和管理活動使用的基線，要作為軟件計劃#65380;工作產(chǎn)品和活動的基礎(chǔ)，其建立時機就應(yīng)該是在軟件工程活動和管理活動開始之前，至少是在其開始的早期#65377;而是否在項目的早期確定需求，不同的軟件生命周期模型有不同的處理方案#65377;

需求的開發(fā)和管理一直是軟件工程的重要領(lǐng)域#65377;需求是軟件開發(fā)的根源，因此有效地開發(fā)和管理需求一直是各種生命周期模型探討的重要問題#65377;瀑布模型強調(diào)前期固化需求;原型模型通過原型進行需求開發(fā);迭代模型通過每次迭代產(chǎn)生的可運行版本確認(rèn)需求#65377;這些模型均證明了需求活動是每一個軟件生命周期模型均要涉及的內(nèi)容#65377;因而，CMM中的這些內(nèi)容不可避免地與各種軟件生命周期模型有一定的聯(lián)系#65377;

1.2.2軟件產(chǎn)品工程過程域

軟件產(chǎn)品工程過程域有兩個目標(biāo):

目標(biāo)1定義和綜合軟件工程任務(wù)，并始終如一地加以執(zhí)行以生產(chǎn)軟件#65377;

目標(biāo)2保持軟件工作產(chǎn)品間的一致性#65377;

為達(dá)到這兩個目標(biāo)，該過程域有10個活動，本文在此主要討論與需求#65380;設(shè)計和編碼分別對應(yīng)的活動2#65380;活動3和活動4#65377;

這三個活動的子實踐中需要討論的內(nèi)容摘抄如下:

a)在認(rèn)為軟件需求文檔已完成之前，對其進行同行評審#65377;

b)參與軟件設(shè)計的個人評審軟件需求，以保證影響軟件設(shè)計的問題得到鑒別和解決#65377;

c)軟件設(shè)計由軟件體系結(jié)構(gòu)設(shè)計和軟件詳細(xì)設(shè)計組成#65377;

d)評審軟件體系結(jié)構(gòu)設(shè)計以保證那些影響軟件詳細(xì)設(shè)計的體系結(jié)構(gòu)問題得到鑒別和解決#65377;

e)基于軟件體系結(jié)構(gòu)設(shè)計進行軟件的詳細(xì)設(shè)計#65377;

f)在認(rèn)為設(shè)計已完成之前，對其進行同行評審#65377;

g)參與編碼的個人評審軟件需求和軟件設(shè)計，以保證影響編碼的問題得到識別和解決#65377;

h)在認(rèn)為一個代碼單元已完成之前，對該代碼單元進行同行評審和單元測試#65377;

i)軟件需求或軟件設(shè)計若有改變，則適當(dāng)更改代碼#65377;

以上這些內(nèi)容，都是對于工程活動的明確要求#65377;由于各種生命周期模型中均明確地提出了一套工程活動的解決方案，CMM中的這些要求會與各種生命周期模型發(fā)生關(guān)聯(lián)#65377;

2軟件生命周期模型與CMM實施

CMM實施是指在一個組織中按照CMM的內(nèi)容，在軟件項目開發(fā)中開展活動，使得軟件項目的過程符合CMM要求#65377;通常會由一個小組負(fù)責(zé)將CMM的內(nèi)容映射成為一組規(guī)范，然后引導(dǎo)軟件項目組按照這一組規(guī)范進行開發(fā)活動#65377;

在這個過程中，規(guī)范的內(nèi)容既要符合CMM的要求，又要與組織目前對各種軟件生命周期模型的理解和實際使用相協(xié)調(diào)#65377;筆者在實踐中發(fā)現(xiàn)，在需求管理過程域和軟件產(chǎn)品工程過程域的實施中經(jīng)常會遇到難點#65377;

2.1需求管理過程域的實施

需求管理過程域?qū)嵤┗顒又械闹饕F(xiàn)象是:

a)對于二級的組織，CMM不要求定義組織級的軟件生命周期模型，沒有采用瀑布模型或拋棄型原型模型的項目組#65377;在項目進行中，由于需求不確定，項目經(jīng)理通常難以在早期建立需求基線，會盡量推遲需求基線建立的時間，而作為規(guī)范解釋者的過程，改進組通常也難以提出好的建議#65377;

b)對于三級的組織，難點在于確定組織級的軟件生命周期模型中非瀑布模型和拋棄型原型模型的其他模型的需求基線的建立時機，即使勉強確定也難以使用，難以產(chǎn)生實際效果#65377;

產(chǎn)生上述問題的具體原因分析如下:

在1.2.1節(jié)中已經(jīng)初步分析了需求管理過程域的相關(guān)內(nèi)容#65377;該過程域?qū)嵤┲械闹饕y點在于對需求的工作產(chǎn)品進行評審#65380;形成基線，并依據(jù)該基線進行項目策劃#65377;

實際項目中可能采用包括瀑布模型的各種生命周期模型#65377;各種生命周期模型是否能夠在早期產(chǎn)生穩(wěn)定的需求的工作產(chǎn)品用于評審，就成為該生命周期模型是否能滿足CMM要求的關(guān)鍵#65377;

對于不同的軟件生命周期模型，需求的工作產(chǎn)品大致有三類:a)瀑布模型中，文檔形式的需求規(guī)格說明書;b)拋棄型原型模型中的原型(演示之后重新設(shè)計);c)非拋棄型原型模型和其他迭代式軟件生命周期模型中可運行的版本(一次迭代的發(fā)布版或非拋棄型原型)#65377;

在這三類軟件生命周期模型中，a)#65380;b)均可以在項目的早期完成該工作產(chǎn)品，然后進行評審并基線化，能夠滿足需求基線的目標(biāo)并具備需求基線化的意義:作為軟件工程活動和管理活動的基礎(chǔ)#65377;

對于軟件生命周期模型c)，由于需求的不斷細(xì)化和變化，通常很難在項目的早期穩(wěn)定下來進行評審#65380;形成基線#65377;盡管可以在項目進行過程中的某一時期建立需求基線，但要將需求基線作為軟件工程活動和管理活動以及制訂項目計劃的基礎(chǔ)，則存在實踐中的困難#65377;

對于非拋棄型原型模型，在工具的支持下，原型可能會演化成為最終產(chǎn)品，因此原型建立過程中的活動依據(jù)的是沒有進行基線化的用戶需求，需求基線因而無法作為軟件工程活動和管理活動以及制訂項目計劃的基礎(chǔ)#65377;而非拋棄型原型模型將對原型進行多次迭代#65380;逐步精化，每次迭代產(chǎn)生的原型所代表的需求均有可能修改，因此在早期#65380;基線化需求難以進行#65377;

對于迭代式軟件生命周期模型，典型的如統(tǒng)一軟件開發(fā)過程，在其建議的先啟#65380;精化#65380;構(gòu)建#65380;產(chǎn)品化四個階段中，每個階段均會通過可運行的版本對需求模型進行確認(rèn)和改進，也可能在設(shè)計活動中對需求模型進行一致性維護#65377;

盡管在某一次迭代中可以將所有需求基線化，但由于基線化的時機會因為項目的不同而或早或晚，較晚基線化的需求基線不適合作為軟件工程活動和管理活動的基礎(chǔ)——因為活動已經(jīng)進行#65377;

通過以上分析，筆者認(rèn)為:

對于瀑布模型和拋棄型原型模型這兩種軟件生命周期模型，需求管理過程域的目標(biāo)1可以比較容易達(dá)到，并且具備將需求基線作為軟件工程活動和管理活動以及制訂項目計劃的基礎(chǔ)的意義#65377;

對于非拋棄型原型模型和其他迭代式軟件生命周期模型，需求管理過程域的目標(biāo)1難以達(dá)到，難以將需求基線作為軟件工程活動和管理活動以及制訂項目計劃的基礎(chǔ)#65377;

綜上所述，部分軟件生命周期模型為了處理需求不明確而采用了逐步細(xì)化需求的方案，需求不能在早期形成基線，因此難以滿足CMM中將需求基線作為軟件工程活動和管理活動以及制訂項目計劃基礎(chǔ)的要求#65377;

2.2軟件產(chǎn)品工程過程域的實施

軟件產(chǎn)品工程過程域?qū)嵤┗顒又械闹饕F(xiàn)象是:

在制訂組織級使用的軟件生命周期模型時，需要考慮與軟件產(chǎn)品工程過程域內(nèi)容的協(xié)調(diào)性#65377;瀑布模型和拋棄型原型模型以外的軟件生命周期模型比較難以處理:如果遵循CMM而偏離原生命周期模型的內(nèi)容，則無法利用該生命周期模型的優(yōu)點;如果遵循生命周期模型的內(nèi)容，則與CMM差距過大，難以獲得評估方的認(rèn)可#65377;

產(chǎn)生上述問題的具體原因分析如下:

通過對1.2.2節(jié)中軟件產(chǎn)品工程過程域相關(guān)內(nèi)容的分析，可以勾勒出CMM中工程活動的概貌:

a)需求#65380;體系結(jié)構(gòu)設(shè)計#65380;詳細(xì)設(shè)計#65380;編碼活動之間具有明顯的間斷性和順序性;

b)以通過同行評審作為活動已經(jīng)完成的標(biāo)志;

c)上一階段的工作產(chǎn)品需要經(jīng)過本階段活動執(zhí)行者的評審，才能視為完成#65377;

表1是與瀑布模型特點所作的對比，可以看出該工程活動基本符合瀑布式生命周期的特點[5]#65377;

迭代式生命周期模型中，工作產(chǎn)品的演化在一個迭代內(nèi)是按照類似于瀑布模型的形式進行的，而在迭代層次之上，整個生命周期中不同的迭代有著不同的關(guān)注焦點[6]#65377;例如，瑞理統(tǒng)一軟件開發(fā)過程要求整個項目要有整體的項目計劃，包括每個階段分為幾次迭代#65380;每次迭代的目標(biāo)等;而每次迭代均要有迭代計劃，規(guī)劃本次迭代的具體活動#65377;如圖1所示，CMM中軟件產(chǎn)品工程過程域的關(guān)注點是在迭代內(nèi)的，沒有對迭代層次之上的實踐加以關(guān)注#65377;

由于CMM的關(guān)注點在迭代內(nèi)部，對于采用迭代式生命周期模型的項目，CMM對工程活動的指導(dǎo)意義有限，具體表現(xiàn)在:

a)沒有強調(diào)迭代過程，沒有突出迭代過程的優(yōu)秀實踐;

b)強調(diào)的活動大多是瀑布模型中的活動，對于迭代式軟件生命周期模型中的活動強調(diào)較少;

c)強調(diào)的工作產(chǎn)品大多是瀑布模型中的工作產(chǎn)品，對于迭代式軟件生命周期模型中的工作產(chǎn)品強調(diào)較少;

d)可能引導(dǎo)組織傾向于采用瀑布模型#65377;

因此，CMM中軟件產(chǎn)品工程過程域的內(nèi)容更多地針對瀑布模型，針對迭代式生命周期的內(nèi)容較少，因而在實際使用迭代式生命周期時，不能局限于CMM的內(nèi)容#65377;

原型模型分為拋棄型原型模型和非拋棄型原型模型#65377;拋棄型原型模型中的原型用于獲取和驗證需求，然后重新進行最終系統(tǒng)設(shè)計#65380;最終系統(tǒng)實現(xiàn)等活動，因此可以將原型看做需求活動的工作產(chǎn)品，其他后續(xù)活動與瀑布模型相同#65377;拋棄型原型模型能夠滿足CMM中軟件產(chǎn)品工程過程域的要求#65377;

非拋棄型原型的主要階段是聽取用戶意見#65380;建造/修改原型#65380;用戶測試運行原型#65377;這三個階段不斷循環(huán)，直到形成最終產(chǎn)品#65377;通常情況下，通過第四代開發(fā)語言的支持，系統(tǒng)的體系結(jié)構(gòu)設(shè)計和詳細(xì)設(shè)計活動被組合在編碼活動中，以快速生成原型#65377;由于沒有獨立的體系結(jié)構(gòu)設(shè)計和詳細(xì)設(shè)計活動，非拋棄型原型模型的活動難以符合CMM中軟件產(chǎn)品工程中活動的內(nèi)容#65377;

綜上所述，由于CMM中軟件產(chǎn)品工程過程域的內(nèi)容更接近于瀑布模型，對于其他生命周期模型不能局限于CMM的內(nèi)容，要將兩者進行靈活處理，結(jié)合使用#65377;

2.3初步的解決方案

由于非拋棄型原型的特點與迭代式生命周期模型具有一定的相似性，本文以下僅分析針對迭代式生命周期模型的初步解決方案，并以統(tǒng)一軟件開發(fā)過程(USDP)作為迭代式生命周期模型的具體代表#65377;

下面先分析需求管理過程域?qū)嵤﹩栴}的解決方案#65377;

統(tǒng)一軟件開發(fā)過程處理需求有兩個主要特點，即強調(diào)關(guān)鍵需求的優(yōu)先處理和強調(diào)通過迭代不斷確認(rèn)需求#65377;從這兩點出發(fā)，將需求項分類處理，不能一視同仁;要承認(rèn)需求變更在迭代過程中的正常性#65377;

考慮到CMM強調(diào)以需求基線作為基礎(chǔ)進行后續(xù)活動的思想，本文對統(tǒng)一軟件開發(fā)過程中需求基線問題的解決方案是將需求基線的概念進行擴展，不局限于一個項目的所有需求一次基線化，采取分步基線化#65380;分塊基線化的方式#65377;

分步基線化的概念是將基線的概念與迭代的概念進行結(jié)合#65377;基線的定義是:“一種通過正式評審和認(rèn)可的規(guī)范說明或產(chǎn)品，此后將其作為進一步開發(fā)的基礎(chǔ)#65377;只有通過正式的變更控制過程才可以更改#65377;”在此基礎(chǔ)上，分步基線化將基線概念擴展為對一個工作產(chǎn)品在本次迭代中當(dāng)前的#65380;暫時的評審?fù)ㄟ^和認(rèn)可，在本次迭代中以此次基線為工作基礎(chǔ)，并鼓勵下次迭代中對本次基線化的工作產(chǎn)品進行改進和升級#65377;

這里強調(diào)基線的暫時性和變化性，這樣的解釋比較符合項目迭代的特點，并會減輕項目經(jīng)理對基線化和基線變更的畏懼心理#65377;

分塊基線化是指將需求項根據(jù)重要性和風(fēng)險程度分成優(yōu)先級不同的幾個部分，各部分視演化程度分別進行基線化，分別進行后續(xù)的工作#65377;這樣可以避免需求的幾個部分之間追求相同的細(xì)致程度和基線化程度，以致回到瀑布模型的框架中#65377;

分塊基線化的關(guān)鍵在于如何對需求項進行分塊，良好的分塊方案除考慮需求項的優(yōu)先級外，還要考慮需求項之間的依賴關(guān)系#65380;分塊方案對未來架構(gòu)設(shè)計的影響以及項目的人員安排和進度計劃#65377;

以下分析軟件產(chǎn)品工程過程域?qū)嵤﹩栴}的解決方案#65377;

在2.2節(jié)中總結(jié)了CMM中工程活動的概貌，可以看出，CMM以通過評審作為一種工程活動結(jié)束的標(biāo)志，關(guān)鍵有兩點:一個階段的結(jié)束以一種工程活動的結(jié)束作為標(biāo)志;以通過評審作為一種工程活動結(jié)束的標(biāo)志#65377;

對于統(tǒng)一軟件開發(fā)過程，在迭代層次上以及每次迭代內(nèi)部，這些工程活動均存在，而且不一定是間斷和順序的，各項活動之間可能會有部分重合#65377;例如，在以設(shè)計活動為主的時間段中，前期可能有需求活動，后期可能有編碼活動，因此不能以這些活動是否完成作為階段的標(biāo)志#65377;

對于工作產(chǎn)品的評審是對其質(zhì)量進行保障的重要手段，因此以同行評審作為保障設(shè)計活動質(zhì)量的手段，但是不以同行評審作為完成標(biāo)志，因為這往往會誤導(dǎo)活動執(zhí)行者在評審前追求盡可能精細(xì)化，在評審后對變化產(chǎn)生抵觸情緒#65377;

在階段劃分和評審的意義上，本文傾向于使用統(tǒng)一軟件開發(fā)過程中的概念和方法，吸取評審作為質(zhì)量保障的手段，作為該過程域的替代實踐#65377;

軟件產(chǎn)品工程過程域?qū)嵤┲械牧硪粋€問題是，軟件產(chǎn)品工程過程域中強調(diào)的活動和工作產(chǎn)品多為瀑布模型的活動和工作產(chǎn)品，沒有包含統(tǒng)一軟件開發(fā)過程中的分析活動#65380;分析模型和設(shè)計模型等#65377;針對這個問題，在現(xiàn)實中的變通做法是，將目前開發(fā)活動中已經(jīng)有的活動和工作產(chǎn)品與CMM中的進行映射，將CMM中的概念用目前的實際情況進行解釋#65377;例如，將CMM要求的體系結(jié)構(gòu)設(shè)計定義為某種規(guī)格要求下的分析模型和設(shè)計模型#65377;

3關(guān)于CMMI

作為CMM的替代者，CMMI有了比較大的變動，如漸進式表示法和階段式表示法的引入，以及過程域的變化#65377;CMMI中涉及軟件生命周期模型的內(nèi)容有了較大的變化#65377;其中明確包含軟件生命周期模型字樣的內(nèi)容與特定的軟件生命周期模型無關(guān)，適用于各種生命周期模型，這一點與CMM相同#65377;下面簡單介紹沒有明確包含軟件生命周期模型字樣但與之有關(guān)的需求管理和軟件產(chǎn)品工程兩個關(guān)鍵過程域#65377;

需求管理和軟件產(chǎn)品工程這兩個過程域在CMMI中有比較大的變化#65377;CMMI的階段式表示法中，需求管理過程域依然在二級被要求，內(nèi)容也與CMM中有較大變化，比較明顯的變化是其不再要求需求基線，與其有關(guān)的是取得需求的承諾(SP 1.2)，并明確了需求是不斷進化的(evolve)#65377;例如CMMI原文中對需求管理 SP 1.2的解釋[7]:

Requirements evolve throughout the project， especially …… process area. As the requirements evolve， this specific …… work products.

可翻譯為:“在項目過程中，需求不斷進化，特別是……過程域#65377;在需求不斷進化的情況下，本特定……工作產(chǎn)品#65377;”CMMI的這一改動，更加貼近各種迭代式生命周期的內(nèi)容，使得使用這些生命周期模型的項目能更加順暢地符合CMMI的要求#65377;

在CMMI的階段式表示法中，沒有軟件產(chǎn)品工程這一過程域#65377;根據(jù)相關(guān)研究[8]，CMM的軟件產(chǎn)品工程關(guān)鍵過程域的內(nèi)容可以映射到若干個過程域中#65377;本文關(guān)注的該關(guān)鍵過程域的活動2~活動4可以映射到需求開發(fā)(requirements development)#65380;需求管理(requirements management)#65380;產(chǎn)品集成(product integration)#65380;技術(shù)解決方案(technical solution)#65380;確認(rèn)(validation)和驗證(verification)等幾個過程域中#65377;通過分析這幾個過程域的內(nèi)容，可以得出結(jié)論:CMMI對于工程活動的要求，抽象的程度比CMM高，更具備普適性，也適用于各種軟件生命周期模型#65377;CMMI的連續(xù)式表示法的內(nèi)容本文不再贅述#65377;CMMI對CMM相關(guān)內(nèi)容的改進，也能從側(cè)面反映本文的論點#65377;

4結(jié)束語

本文對CMM實施過程中發(fā)現(xiàn)的一些現(xiàn)象進行了分析，這些現(xiàn)象主要是難以協(xié)調(diào)項目實施的具體活動與CMM要求的活動，包括:

a)非瀑布生命周期模型的項目在實施需求管理過程域的部分內(nèi)容時效果不明顯#65377;

b)非瀑布生命周期模型的項目部分工程活動和工作產(chǎn)品與軟件產(chǎn)品工程過程域的部分內(nèi)容難以協(xié)調(diào)#65377;

盡管CMM將會被CMMI所取代，對其進行研究依然具有意義#65377;這是因為，一方面，已經(jīng)有大量的組織正在使用CMM作為過程改進的模型，它們要轉(zhuǎn)而采用CMMI則需要相當(dāng)長的時間，在此期間，這些組織依然會關(guān)注對于CMM的研究;另一方面，對于CMM的研究，也將有利于進一步了解和更好地使用CMMI#65377;

參考文獻(xiàn):

[1]PRESSMAN R S.軟件工程——實踐者的研究方法[M].梅宏，譯.北京:機械工業(yè)出版社，2002:21.

[2]ISO/IEC 12207—1995， Information technology: software life cycle processes[S].

[3]IEEE/ANSI Std 610.12—1990， Standard glossary of software engineering terminology[S].

[4]PAULK M C， WEBER C V， GARCIA S M， et al. Key practices of the capability maturity model， version 1.1[R]. Pittsburgh: Carnegie Mellon Software Engineering Institute， 1993:218.

[5]周之英.現(xiàn)代軟件工程[M].北京:科學(xué)出版社，1999:58.

[6]JACOBSN I， BOOCH G， RUMBAUGH J. 統(tǒng)一軟件開發(fā)過程[M].周伯生，等譯.北京:機械工業(yè)出版社，2002:65.

[7]CMMI Product Team. Capability maturity model integration(CMMI) version 1.1(CMMISE/SW/IPPD，v1.1) staged representation[R]. Pittsburgh:Carnegie Mellon Software Engineering Institute，2001:86.

[8]USAF Software Technology Support Center(STSC). CMMISE/SW v1.1 to SWCMM v1.1 mapping[EB/OL].(20051210).http://www.sei.cmu.edu/cmmi/ adoption/pdf/stscmappings.pdf.



“本文中所涉及到的圖表、注解、公式等內(nèi)容請以PDF格式閱讀原文”