ＣＭＭ／ＣＭＭＩ與軟件生命周期模型關系的研究

摘要：對CMM/CMMI和主流軟件生命周期模型的關系進行了分析，認為：

a)CMM/CMMI與軟件生命周期模型都是軟件活動過程化的產物。在軟件過程化進程中，CMM/CMMI是軟件過程化成熟期的成果；軟件生命周期模型則是軟件過程化前期的成果。

b)由于發展背景不同，需要處理的問題各異，使得軟件生命周期模型關注于工程活動；CMM/CMMI關注于軟件開發活動的整體。

c)盡管CMM/CMMI編寫者的初衷是保持CMM/CMMI與特定軟件生命周期模型的無關性，但是其產生的時代背景卻使CMM/CMMI受到了軟件生命周期模型的影響。

關鍵詞：軟件生命周期模型； 軟件能力成熟度模型； 能力成熟度模型集成

中圖分類號：TP311.5文獻標志碼：A

文章編號：1001-3695(2007)11-0065-05

目前，能力成熟度模型（SW－CMM/CMMI）和各種軟件生命周期模型在軟件產業都得到了廣泛使用，而且經常被同時使用。當一個組織在運用CMM/CMMI進行軟件過程改進的過程中，往往會被其中涉及到的各種軟件生命周期模型及其與CMM/CMMI的關系所困惑，從而影響了過程改進的效果。

對CMM/CMMI與軟件生命周期模型之間整體關系的認識，是軟件組織對軟件開發活動進行宏觀決策的依據，將決定軟件開發活動的方向。例如，對于整個組織的軟件開發活動，軟件生命周期模型用于解決哪些問題，CMM/CMMI用于解決哪些問題，在應用中可能產生什么結果？對于不同類型的項目，這兩者的應用是否存在不同？這些宏觀的決策在組織中起著非常重要的作用。

為此，本文主要討論了CMM/CMMI與軟件生命周期模型之間的關系：

a）在發展歷史上，兩者之間的關系；

b）在軟件工程領域，兩者關注范圍的比較；

c）兩者內容的相互影響。

通過以上三方面的整體關系討論，將有助于進一步分析兩者具體內容之間的內在關聯，加深對兩者的理解和認識。

1發展歷史上的關系

1．1在軟件行業發展歷史上的地位

軟件行業迄今已有近五十年的發展歷程，R. Lai認為其中有三次較明顯的發展浪潮[1]：第一次浪潮以瀑布式生命周期和結構化方法為特征；第二次浪潮是過程成熟度運動；第三次浪潮將是預期中的軟件工業化。

第一次浪潮是對之前沒有結構的軟件活動的改進。通過瀑布模型和結構化分析設計方法，人們進一步理解了軟件開發活動。第二次浪潮改進的范圍更廣，覆蓋了軟件開發過程及其支持活動的各個方面。作為第二次浪潮的CMM模型，很可能會促使軟件工業在工程化的道路上更進一步，使軟件工業成為以過程為中心的工業，類似于制造業。

R. Lai對第一次浪潮和第二次浪潮的劃分，恰如其分地表明了軟件生命周期模型與CMM在軟件行業發展過程中的地位。

軟件生命周期模型的發展始自W. Royce在1970年發表的瀑布模型。瀑布模型將軟件開發活動分為需求分析、設計、編碼、測試等幾個過程。這樣的劃分具有里程碑意義，將人們從之前的沒有結構的軟件活動中解脫出來，開始從更高的角度審視軟件開發活動。

在瀑布模型的基礎上，各種軟件生命周期模型不斷被提出。后續的各種軟件生命周期模型是在與瀑布模型相同的層次上對各種軟件開發活動進行描述和總結。在這一時期，軟件生命周期模型是軟件工程領域的重要研究方向，各種軟件生命周期模型總結了產業界的各種軟件開發活動的特點，加深了對于軟件開發活動的認識。

過程成熟度運動始于W. Humphrey在1986年的工作，他在軟件過程中采用統計質量控制原理，并將Crosby的成熟度量化的思想引入，形成成熟度等級的概念。在W. Humphrey的工作基礎上，軟件工程研究所先后發表了能力成熟度框架[2]、成熟度問卷[3]、CMM1.0、CMM1.1、CMMI1.0和CMMI1．1。

這些工作對軟件行業產生了巨大影響，在世界范圍內引起了軟件從業者的關注。各種其他學科的成熟度模型不斷被提出，其他標準組織也不斷接受過程思想，在其標準中加入過程元素。例如國際標準化組織廣泛應用的標準ISO9000，在其最新版本2000版中，也加入了過程思想[4]，在其引言中指出“本標準鼓勵在建立、實施質量管理體系以及改進其有效性時采用過程方法，通過滿足顧客要求，增強顧客滿意”“過程方法的優點是對諸過程的系統中單個過程之間的聯系以及過程的組合和相互作用進行連續的控制”。很多國家和組織也都開始了對軟件過程的研究并形成了自己的模型和標準[5]。

綜上所述，軟件生命周期模型和CMM/CMMI在軟件行業發展史上分別代表了第一次浪潮和第二次浪潮，影響都是深遠和巨大的。

1．2在軟件過程化進程中的位置

W. Humphrey第一次在軟件產業中提出過程的思想。但筆者認為，軟件產業的過程化并不是在W. Humphrey明確提出過程概念后才開始的。實際上，軟件產業的過程化可以追溯到瀑布模型和各種軟件生命周期模型[6]。

在瀑布模型產生之前，軟件開發以編碼活動為主，沒有過程和結構，不確定和混亂是軟件開發的重要特點。軟件已開始大量用于商業應用中，軟件的規模也越來越大，軟件開發的理論成為業界的研究對象。

結構化分析設計方法的提出使得軟件開發活動逐漸有了劃分，不再局限于編碼活動。該方法的分步驟進行及各步驟間相對獨立的特點為瀑布模型的產生提供了技術可行性。

瀑布模型正是在這樣的背景下產生的。瀑布模型與結構化分析設計方法一起對軟件開發活動進行了最初步的過程化：將沒有結構的軟件開發活動劃分為需求分析、設計、編碼、測試等幾個過程。與瀑布模型類似，其他的軟件生命周期模型也是對軟件開發活動進行著各種過程化，從不同的角度識別過程，確定過程之間的相互作用，從而更好地對軟件開發活動進行描述和總結。

可見，軟件生命周期模型是軟件過程化進程中的早期成果。

在技術相關的活動被過程化之后，其他方面的問題逐漸表現出來，如項目管理、風險問題。

在一些使用瀑布模型比較成熟的軟件組織，技術活動相對比較成熟，管理活動和其他活動成為進一步的改進方向，這些非技術活動包括項目管理活動、軟件開發相關的支持活動（如需求管理和配置管理）、提高軟件組織生產能力的活動（如統計質量控制原理的應用）等。在這些軟件組織，非技術活動的過程化得到了相當大的發展，相關理論和實踐經驗由W. Humphrey帶到了SEI，并據此形成了CMM/CMMI的早期版本。從此CMM/CMMI被不斷使用，過程思想逐漸形成了巨大的影響。

可見，CMM/CMMI模型是軟件過程化進程中的后期產物。

2兩者關注點的異同

在軟件工程領域，軟件生命周期模型更關注于軟件開發工程的過程，在這個過程中如何對各項活動進行工程化； CMM/CMMI則比較關注軟件開發活動的整體，如何對軟件開發活動的各個方面進行過程化，其中包括工程活動的過程化。

2．1軟件開發活動的分類

軟件開發活動是一個組織中與軟件開發相關活動的統稱。軟件開發中包含的活動很多，為方便討論，這里使用工程活動指代工程類的活動，用非工程活動指代除工程類活動以外的其他活動。

工程活動是與軟件建造本身密切相關的活動，包括確定軟件要解決的現實問題、構造軟件以解決該問題、對構造的軟件進行維護等。例如需求分析、設計、編碼、測試等活動。正是這些活動建造出最終軟件，因此是軟件開發活動中的核心活動。

非工程活動是為了使工程活動能進行得更加順利、更有效率而對工程活動進行的支持和保障，如項目管理活動、配置管理活動等。這些活動針對的對象是工程活動，不能脫離工程活動而單獨存在。這些非工程活動對軟件構造所起的作用是通過工程活動產生的，因此是工程活動的支持和保障。

區分工程活動與其他活動的原因在于，在軟件開發相關活動中，工程活動與其他活動的位置不同。工程活動在軟件開發相關活動中處于核心位置，非工程活動處于支持和保障位置。

2．2軟件生命周期模型關注于工程活動

在軟件生命周期模型的領域內有若干種模型，這些模型的主要關注點在工程活動，部分模型也關注一些非工程活動。

瀑布模型將軟件開發活動分為需求分析、設計、編碼、測試等幾個階段。這幾個階段是對工程活動的劃分。瀑布模型沒有再涉及其他方面的活動。因此瀑布模型關注于工程活動。

原型模型則主要是為了解決需求獲取的難題而創建原型用于需求的獲取和確認，再將需求轉換為軟件系統，其主要內容集中在軟件開發本身。因此原型模型也關注于工程活動。

螺旋模型的主要貢獻在于明確提出迭代概念和風險的問題，并指出在項目定義、需求、設計等階段均存在風險，需要重點考慮，并通過多次迭代的原型主動誘發風險。風險管理不屬于工程活動的范圍，但筆者仍然認為螺旋模型的主要內容是工程方面的。因為對于非工程活動，螺旋模型僅考慮了風險問題，而風險管理僅是非工程活動的一個小部分，不足以依此推斷螺旋模型主要關注于非工程活動。

增量模型將瀑布模型的順序化與多次迭代相結合。每個增量開發都是一次瀑布模型的過程，強調每一個增量均發布一個可運行版本，以滿足客戶和市場需要。增量模型主要考慮當需要快速推出可運行版本，而該版本不需要完整的功能時，在工程活動上的解決方案，因此增量模型也關注于工程活動。

圖1描述了幾種軟件生命周期模型的關注點。可以看出，軟件生命周期模型關注于工程活動。

2．3CMM/CMMI關注于軟件開發活動的整體

CMM/CMMI的關注點是軟件開發活動的整體。將整個軟件開發活動劃分成了不同的過程域，再針對各個過程域分別進一步描述，從而將軟件開發活動整體進行了過程化。在此基礎上，CMM/CMMI給出了對軟件開發活動進行不斷改進的方法——統計過程控制方法。

對于管理類的關鍵過程域，CMM有比較完整而清晰的活動劃分和改進目標。從第二級項目級的項目策劃和項目跟蹤等活動，進一步到第三級組織級的按照已定義的軟件過程進行項目管理，再到第四級的定量管理。

對于組織類的關鍵過程域，CMM也提供了比較清晰的改進方向和方案。從第三級開始，在項目級別的基礎上，組織開始對軟件過程進行管理和定義，形成組織標準過程；在第四級，對過程進行量化預測和控制；到第五級對過程不斷進行改進。

CMM中工程類的關鍵過程域，從第三級開始包含軟件產品工程，并要求進行同行評審；到第四級對質量活動的明確要求；再到第五級的缺陷預防和技術變更管理。

可以看出，CMM模型的內容比較全面，覆蓋了軟件開發活動的各個方面。工程類過程域是其中的一個方面，并不是其關注的焦點，地位與其他方面的過程域相同。

CMMI模型的情況與CMM類似，并且進一步加強了工程類過程域。這里不再贅述。

2．4兩者關注點不同的原因分析

軟件生命周期模型關注于工程活動；CMM/CMMI關注于軟件開發活動的整體。這與工程活動和非工程活動在軟件開發活動中的位置不同有關系，也與軟件生命周期模型和CMM/CMMI發展的背景有關。

如前所述，在軟件開發活動中，工程活動承擔著從需求到軟件的轉換過程。這一過程是軟件開發活動的核心活動。有了這些活動，軟件的產出才成為可能，而其他非工程活動是為了讓工程活動進行得更順利、更高效而采取的輔助和保障活動。

因此，在軟件過程化進程中，作為核心活動的工程活動會首先被過程化，然后非工程活動才會被過程化。而軟件生命周期模型正是工程活動被過程化的成果；CMM/CMMI則是將各類活動過程化的成果。

在瀑布模型產生之前，軟件開發以程序編制活動為主，沒有需求分析、設計、測試等活動。這些活動與程序編制活動沒有結構地混合在一起，組成軟件構造的工程活動。這樣的工程活動難以預測和控制，使得管理活動難以開展。此時首先需要對工程活動進行過程化，只有當處于核心位置的工程活動能夠有序地進行，非工程活動才能根據工程活動的特點開展。

結構化分析設計方法對工程活動進行了改進，為從需求轉化到軟件的過程提供了完整的轉換方法，使得工程活動能夠按步驟、有次序地進行。瀑布模型是在結構化分析設計方法的基礎上對軟件開發活動進一步的過程化。

在瀑布模型的基礎上，其他軟件生命周期模型希望能夠更好地對軟件開發活動進行描述和總結，于是從不同的角度，對于不同類型的軟件開發過程提出了若干種軟件生命周期模型。由于這些模型的開發是在瀑布模型的背景下進行的，其研究范圍與瀑布模型接近，關注于工程活動較多。

工程活動被過程化之后，非工程活動的過程化也被重視起來。

與此同時，美國國防部對軟件承包商提出在進度和成本預算內開發出高質量軟件的要求，促使軟件產業界對相關問題進行研究。美國國防部的一個研究小組分析軟件危機后得出結論：“軍用軟件開發中，當前最主要的問題不是技術問題，而是管理問題[8]”。也就是說，不是工程活動的問題（技術問題），而是非工程活動的問題（管理問題）。

SEI在Watts Humphrey的領導下，收集產業經驗并借鑒傳統行業的質量理論，在此基礎上進一步發展并形成了CMM/CMMI模型。由于這樣的發展背景，CMM/CMMI關注于包括工程活動在內的軟件開發活動的各個方面。

3軟件生命周期模型對CMM/CMMI的影響

3．1CMM/CMMI的產生背景

從前面的討論可以看出，在軟件生命周期模型被提出的過程中，CMM/CMMI基本沒有影響軟件生命周期模型的發展，在各種軟件生命周期模型中都沒有受到CMM/CMMI影響的內容。但是，在CMM/CMMI模型中，卻可以看到瀑布模型的影子。本節將討論瀑布模型在整體上對CMM/CMMI的影響。

CMM/CMMI產生的一個目的是為了美國政府和美國國防部能有效地評估軟件承包商。而美國政府和美國國防部都有自己的軟件開發標準。從CMM/CMMI與美國國防部的軟件開發標準之間的關系，可以推斷出一些結論。

1988年之前，美國國防部的軟件研發標準是DOD—STD—2167。該標準將瀑布模型作為美國國防部軍用軟件的開發規范[9]。

1988年，重新修訂DOD—STD—2167，發布了DOD—STD—2167A。它允許但未制定新的模型如螺旋模型等。Barry Boehm報告指出：不幸的是，2167A所參考的軍標MILSPECS和說明性的例子依然是面向瀑布模型的，因此依然繼續使用瀑布模型[9]。

1994年，美國國防部發布了MIL—STD—498《軍用標準——軟件開發和文檔》，以此取代了上述DOD—STD—2167A等三部軍用標準。在與軟件生命周期模型的關系上，MIL—STD—498標準提高了與增量模型和演化模型的兼容性[10]。

1995年ISO/IEC頒布了關于軟件研發工業上貫徹的國際標準，即ISO/IEC12207—1995《信息技術——軟件生命周期過程》。IEEE根據ISO/IEC12207的內容制定了標準IEEE/EIA12207.0。1997年IEEE/EIA協會又相繼頒布了兩部指南， 12207.1和12207.2。

1998年4月，美國國防部批準采用以上三個標準取代MIL—STD—498軍用標準。

ISO/IEC12207提供了一個軟件生命周期過程的高層次的通用框架。在此框架下可以容納各種軟件生命周期模型，并給出了裁減指南[11]。

由此可以看出，在1988—1998年的十年間，美國國防部的軟件開發標準所允許采用的軟件生命周期模型從瀑布模型擴展到了各種軟件生命周期模型。可以判斷在1988年之前，美國國防部的軟件開發標準所允許采用的軟件生命周期模型是瀑布模型，承接美國國防部軟件項目的軟件企業應該會按照瀑布模型進行軟件開發。

CMM模型的1.0版本于1991年提出，最早期的版本于1987年提出。因此CMM主要內容的確定是在20個世紀80年代，其主要實踐經驗都來源于當時承接美國國防部項目的軟件企業的軟件開發活動。

并且，對于非美國國防部承包商的其他軟件企業，也在廣泛使用瀑布模型，“在1985年，幾乎所有明確定義了軟件開發生命周期的項目都采用了瀑布模型”[12]。

由此可以推斷，CMM的主要實踐經驗都來源于瀑布模型的實踐經驗。

上文提到，到1998年，美國國防部的標準所允許采用的軟件生命周期模型從瀑布模型擴展到了各種軟件生命周期模型，這是美國國防部對非瀑布生命周期模型的認可，也反映了非瀑布生命周期模型在產業界的應用已經較為普遍。

CMMI模型的第一個版本是在1999年提出的。該模型的產生原因之一是對CMM模型進行改進，處理CMM模型在使用中發現的問題，吸收產業界新的實踐經驗。非瀑布生命周期模型的普遍應用所產生的實踐經驗，也對CMMI模型產生了一些影響。

3．2瀑布模型對CMM的影響

CMM作為通用的模型，要適用于各種工程環境中，因此既不提倡也不反對各種軟件生命周期模型的使用。在CMM中明確對軟件生命周期模型的問題進行了說明[7]：

“關鍵實踐并不意味著限制軟件生命周期的選擇。已多次使用某一個特定軟件生命周期的人可能會在關鍵實踐的組織和結構中察覺到該生命周期的元素。可是，并不存在鼓勵或阻礙使用任何特定軟件生命周期的企圖。

術語‘階段’用來指示軟件項目工作的一種已定義的劃分，但它并不與任何特定的軟件生命周期相聯系。正如在關鍵實踐中所用的那樣，階段可以指嚴格的序列階段，也可以指部分重疊的和迭代的階段。”

上述說明基本上表明了CMM編寫者的初衷：避免CMM受到軟件生命周期模型的影響；希望CMM模型能夠適用于各種軟件生命周期模型。盡管CMM的編寫者存在這樣的愿望，但CMM產生的時代背景使CMM受到了瀑布模型的影響。瀑布模型對于CMM的主要影響表現在：

CMM將統計質量控制理論應用在軟件行業；

CMM過于強調需求的固化和跟蹤；CMM過于強調瀑布模型的產出物和典型活動。

以上幾點通常會使實施CMM的軟件組織認為與CMM最匹配的軟件生命周期模型是瀑布模型。下面將分別對這幾點進行討論。

1）將統計質量控制理論應用在軟件行業

統計質量控制理論主要應用于傳統行業中的組織。這些組織的生產特點是產品的規模化生產，生產工藝穩定，同一生產流程多次重復，因此可以對某一生產流程的數據進行統計。通過與統計結果的比較確定該次生產流程的質量，從而對產品質量進行控制。而軟件行業的特點是難以規模化生產。規模化生產是軟件工程學科的發展目標。

本文認為，在瀑布模型成熟應用的時代，在某些適合應用瀑布模型的軟件開發領域，已經存在類似項目不斷重復、生產流程不斷重復的情形。這種情形還不是規模化生產，但已經有了規模化生產的征兆，如流程的穩定重復。

瀑布模型簡單而易于理解，在適合于使用瀑布模型的軟件開發活動當中，各項活動的穩定性和可重復性較強。在瀑布模型盛行的20世紀70~80年代這二十年間，大廠商和美國國防部的軟件合同商都在廣泛使用瀑布模型。

由于瀑布模型和結構化分析設計方法的成熟應用，軟件的需求分析、設計、編碼、測試活動相對比較成熟可控，不同項目之間的可比性較強，數據有較強的統計意義，可以應用統計質量控制理論對各類活動進行統計和質量控制。

2）CMM過于強調需求的固化和跟蹤

需求的開發和管理，由于其對于軟件開發的重要性和復雜性，一直是各種軟件生命周期模型關注的問題。原型模型通過原型來誘導和確認需求；增量模型通過每次增量發布的可運行的版本來確認需求；瀑布模型則通過需求規格說明書來確認需求。

瀑布模型從需求開始，以需求規格說明書來固化需求，強調后續活動與需求的一致性。瀑布模型的這一特點與CMM模型的需求管理關鍵過程域中的部分內容非常類似。需求管理關鍵過程域規定要建立需求基線作為后續工作的基礎，要對需求進行跟蹤。

相對于原型模型通過原型對需求不斷的精化，增量模型通過可運行的版本對需求進行確認。CMM中需求管理的思想更接近于瀑布模型。

3）CMM過于強調瀑布模型的產出物和典型活動

CMM模型中軟件產品工程關鍵過程域中，規定了需要進行的工程活動。CMM規定的工程活動包括需求分析、體系結構設計、詳細設計、編碼、集成測試、系統測試和驗收測試等。CMM并沒有說明這些工程活動要嚴格按照瀑布模型的順序進行，也沒有說明這些活動不能重疊和迭代。但是相比較其他軟件生命周期模型的產出物和典型活動，這些活動與瀑布模型過于相似。

3．3軟件生命周期模型對CMMI的影響

從軟件行業的角度看，CMMI吸收了最近若干年軟件產業的一些實踐經驗，也參考了CMM在使用過程中的反饋問題，因此內容上受到了新的生命周期模型的影響。這些影響主要表現在兩個方面：

a）修正CMM中受到瀑布模型影響的內容。

瀑布模型對CMM的影響在3．2節已有描述。其中CMM過于強調需求的固化和跟蹤以及CMM過于強調瀑布模型的產出物和典型活動在CMMI中都得到了修正。CMMI中的需求管理過程域不再要求建立需求基線；在相關工程類過程域中也不再強調瀑布模型的產出物和典型活動，而代之以各種類型的產出物和典型活動。這一修正也從側面支持了本文3．2節中的部分觀點。

但對于將統計質量控制理論應用在軟件行業，CMMI模型沒有變化，依然以統計質量控制理論作為過程改進的主導思想。

b）吸收了迭代式生命周期模型的思想。迭代式生命周期模型典型的如螺旋模型、增量模型、統一軟件開發模型等，在產業界已經普遍應用。通過迭代來規避風險、確認需求等優秀實踐是產業界比較新的實踐成果。CMMI模型吸收了迭代的思想，認為項目過程本身是一個不斷演化、經過多次迭代的過程，在模型中多處反映了這一思想。

例如CMMI原文中對需求管理 SP1.2的解釋[13]：

“Requirements evolve throughout the project， especially as described by the specific practices of the Requirements Development process area and the Technical Solution process area. As the requirements evolve， this specific practice ensures that project participants commit to the current， approved requirements and the resulting changes in project plans， activities， and work products.”

可翻譯為：“在項目過程中，需求不斷進化，特別是在需求開發和技術解決方案過程域的特定實踐中。在需求不斷進化的情況下，本特定實踐確保項目的參與人對當前的、經過批準的需求達成一致，并對后續的項目計劃、活動和工作產品的變更達成一致。”

又如在對產品集成過程域的介紹性說明中提到：

“Product integration is more than just a one－time assembly of the product components at the conclusion of design and fabrication. Product integration can be conducted incrementally， using an iterative process of assembling product components， evaluating them， and then assembling more product components. This process may begin with analysis and simulations (e.g.， threads， rapid prototypes， virtual prototypes， and physical prototypes) and steadily progress through increasingly more realistic incremental functionality until the final product is achieved.”

可翻譯為：“產品集成不只是在設計和建造結束時對產品組件的一次性組裝。產品集成通常增量地進行，采取集成產品組件、評價它們、再集成更多的產品組件這樣一個迭代的過程。這一過程可以開始于分析和模擬（如相關串聯、快速原型、虛擬原型和實體原型），并穩步進展，逐漸增加更多實現了的功能，直至達成最終產品。”

這些內容已經完全符合迭代式生命周期模型的思想。類似以上的內容，在CMMI模型中還有很多，本文不再一一贅述。

CMMI對于迭代思想的吸收使之更加貼近各種迭代式生命周期模型，使得使用這些生命周期模型的項目能更加順暢地符合CMMI的要求。

4結束語

本文從整體上討論了CMM/CMMI與軟件生命周期模型的關系。討論了兩者在發展歷史中的關系、兩者關注范圍的比較以及兩者內容的相互影響。為進一步研究兩者內容上的具體聯系和相互影響提供了基礎，對CMM/CMMI的實施活動也具備一定的參考意義。

參考文獻：

［1］LAI R. The move to mature process[J].IEEE Software， 1993，10(4):14－17.

［2］HUMPHREY W S. Characterizing the software process: a maturity framework[R]. Pittsburgh:Carnegie Mellon Software Engineering Institute， 1987.

［3］HUMPHREY W S， SWEET W L. A method for assessing the software engineering capability of contractors[R]. Pittsburgh:Carnegie Mellon Software Engineering Institute， 1987.

［4］International Standards Organization.ISO 9001—2000，Quality ma￣nagement systems－requirements[S]. 2000.

［5］ZAHRAN S.軟件過程改進[M]. 陳新，等譯. 北京:機械工業出版社， 2002:46-47.

［6］FUGGETTA A. Software process: a roadmap[C]//FINKELSTEIN A. Future of software engineering. Proc of the 22nd International Conference on Software Engineering (ICSE2000). New York: ACM Press， 2000:25-34.

［7］PAULK M C， et al. Key practices of the capability maturity model SM， version 1.1[R]. Pittsburgh: Carnegie Mellon Software Engineering Institute， 1993.

［8］Department of Defense. Report of the defense science board task force on military software[R]. Washington， D C:Office of the Under Secretary of Defense for Acquisition，1987.

［9］BROOKS F P.人月神話[M]. 汪穎，等譯. 北京:清華大學出版社， 2002:367.

［10］US Department of Defense. MIL－STD-498， Military standard－software development and documentation[S]. 1994.

［11］ISO/IEC 12207—1995. Information technology software life cycle processes[S].1995.

［12］POLLICE G. How far have we come?[EB/OL]. [2006-09-25].http://www－128.ibm.com/developerworks/rational/library/dec04/pollice/index.html.

［13］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-87.

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