一、什么是質(zhì)量？ 作為軟件產(chǎn)品的銷售人員，市場人員或維護人員經(jīng)常會受到客戶這樣那樣的指責(zé)或抱怨，客戶說：你們產(chǎn)品的質(zhì)量太差，不穩(wěn)定等等。那么什么是質(zhì)量呢？我們該如何來衡量質(zhì)量呢？ 質(zhì)量具有三個維度： ?? 符合目標(biāo)。目標(biāo)是客戶所定義的，符合目標(biāo)即判斷我們是不是在做需要做的事情。 ?? 符合需求。即產(chǎn)品是不是在做讓它做的事情。 ?? 符合實際需求。實際的需求包括用戶明確說明的和隱含的需求。 ISO 關(guān)于質(zhì)量的定義表示如下： “ 一個實體（產(chǎn)品或服務(wù)）的所有特性，基于這些特性可以滿足明顯的或隱含的需要。 ” 注意，在這個定義中包含明顯的需求和隱含的需求。而往往我們會忽略隱含的需求。因此在控制一個產(chǎn)品的質(zhì)量的過程中必須關(guān)注這些隱含的需求，并給予應(yīng)有的驗證。 另一方面因為我們的產(chǎn)品是為客戶提供服務(wù)的，因此凡是不滿足客戶需求的，我們都認(rèn)為是一個失效（ failure ）。所以我們的產(chǎn)品必須始終圍繞著客戶的需求進行開發(fā)和驗證。 這里我們談到客戶，其實在一個軟件的需求收集過程中需要關(guān)注客戶和用戶。而我們經(jīng)常會忽略客戶與用戶之間的區(qū)別。那么誰是客戶？誰是用戶呢？簡單的來說，客戶是真正能夠決定是否購買你軟件的人，而用戶是實際使用軟件的人。了解了這個區(qū)別，對于你在分析需求的重要性的時候就可以進行參考。同時在產(chǎn)品質(zhì)量驗證的時候也可以做出不同的權(quán)衡。另一方面我們在考慮我們用戶需求的時候，往往只考慮了實際使用軟件的人員，而忽略了其它一些人員對軟件的要求或?qū)浖斐傻臐撛诟偁?，這包括維護人員的要求、系統(tǒng)管理人員的要求、軟件上下游人員的要求、先前版本的情況、市場上競爭對手的軟件情況等。 每個人提到質(zhì)量的時候，經(jīng)常會遇到下列矛盾，在這些矛盾中隱含著對質(zhì)量的承諾【 5 】： ?? 質(zhì)量需要一個承諾，尤其是高層管理者的承諾。但為了得到質(zhì)量，高層管理者必須和其雇用的員工進行緊密合作； ?? 許多人相信沒有缺陷的產(chǎn)品和服務(wù)是不可能的。但是控制在一定級別的缺陷數(shù)是正常并可接受的； ?? 質(zhì)量經(jīng)常是和成本緊密聯(lián)系在一起，一個高質(zhì)量的產(chǎn)品同時也意味著高投入。這是設(shè)計的質(zhì)量和一致性質(zhì)量的一個矛盾； ?? 一個高的質(zhì)量要求需求規(guī)格說明書足夠詳細，以便產(chǎn)品可以根據(jù)這些規(guī)格說明書進行定量的分析。然而許多組織沒有能力或者不愿意產(chǎn)生如此詳細程度的規(guī)格說明書； ?? 技術(shù)人員經(jīng)常相信規(guī)范和標(biāo)準(zhǔn)會束縛他們的創(chuàng)造力，因此就不遵照標(biāo)準(zhǔn)做事。然而如果要得到高質(zhì)量的產(chǎn)品，就必須遵循良好定義的標(biāo)準(zhǔn)和過程。 二、流程對質(zhì)量的貢獻 好了，既然已經(jīng)了解了什么是質(zhì)量，那么怎么才能改進軟件產(chǎn)品的質(zhì)量呢？從一個企業(yè)的長遠發(fā)展來看，首先應(yīng)當(dāng)從流程抓起，規(guī)范軟件產(chǎn)品的開發(fā)過程。這是一個軟件企業(yè)從小作坊的生產(chǎn)方式向集成化、規(guī)范化的大公司邁進的必經(jīng)之路，也是從根本上解決質(zhì)量問題，提高工作效率的一個關(guān)鍵手段。 軟件產(chǎn)品的開發(fā)同其它產(chǎn)品（如汽車）的生產(chǎn)有著共同特性，即需要按一定的過程來進行生產(chǎn)。在工業(yè)界，流水線生產(chǎn)方式被證明是一種高效且能夠比較穩(wěn)定地保證產(chǎn)品質(zhì)量的一種方式。通過這種方式，不同的人員被安排在流程的不同位置，最終為著一個目標(biāo)共同努力，這樣可以防止人員工作間的內(nèi)耗，極大的提高工作效率。并且由于其過程來源于成功的實例，因此其最終的產(chǎn)品質(zhì)量能夠滿足過程所設(shè)定的范圍要求。軟件工程在軟件的發(fā)展過程中吸取了這個經(jīng)驗并把它應(yīng)用到了軟件開發(fā)中，這就形成了軟件工程過程，簡單的說就是開發(fā)流程。 無論做什么事情，都有一個循序漸進的過程，從計劃到策略再到實現(xiàn)。軟件流程就是按照這種思維來定義開發(fā)過程，它根據(jù)不同的產(chǎn)品特點和以往的成功經(jīng)驗，定義了從需求到最終產(chǎn)品交付的一整套流程。流程告訴我們該怎么一步一步去實現(xiàn)產(chǎn)品，可能會有那些風(fēng)險，如何去避免風(fēng)險等等。由于流程來源于成功的經(jīng)驗，因此，按照流程進行開發(fā)可以使得我們少走彎路，并有效的提高產(chǎn)品質(zhì)量，提高用戶的滿意度。 目前流行的流程方法有很多種，不同的過程模型適合于不同類型的項目。瀑布模型是應(yīng)用的最為廣泛的一種模型，也是最容易理解和掌握的模型，然而它的缺陷也是顯而易見的。遺漏的需求或者不斷變更的需求會使得該模型無所適從。然而，對于那些容易理解但很復(fù)雜的項目，采用瀑布模型會是比較適合的，因為你可以按部就班的去處理復(fù)雜的問題。在質(zhì)量要求高于成本和進度要求的時候，該模型表現(xiàn)的尤其突出。 螺旋模型是也是一個經(jīng)典模型，它關(guān)注于發(fā)現(xiàn)和降低項目的風(fēng)險【 8 】。螺旋型項目從小的規(guī)模開始，然后探測風(fēng)險，制定風(fēng)險控制計劃，接著確定下一步項目是否還要繼續(xù)，然后進行下一個螺旋的反復(fù)。該模型的最大優(yōu)點就是隨著成本的增加，風(fēng)險程度隨之降低。然而螺旋模型的缺點是比較復(fù)雜，且需要管理人員有責(zé)任心，專注以及有管理方面經(jīng)驗。 RUP （ Rational Unified Process ）是 Rational 公司提出的一套開發(fā)過程模型，它是一個面向?qū)ο筌浖こ痰耐ㄓ脴I(yè)務(wù)流程【 9 】。它描述了一系列相關(guān)的軟件工程流程，它們具有相同的結(jié)構(gòu)，即相同的流程構(gòu)架。 RUP 為在開發(fā)組織中分配任務(wù)和職責(zé)提供了一種規(guī)范方法，其目標(biāo)是確保在可預(yù)計的時間安排和預(yù)算內(nèi)開發(fā)出滿足最終用戶需求的高品質(zhì)的軟件。 RUP 具有兩個軸，一個是時間軸，這是動態(tài)的。另一個是工作流軸，這是靜態(tài)的。在時間軸上， RUP 劃分了四個階段：初始階段、細化階段、構(gòu)造階段和發(fā)布階段。每個階段都使用了迭代的概念。在工作流軸上， RUP 設(shè)計了六個核心工作流程和三個核心支撐工作流程，核心工作流軸包括：業(yè)務(wù)建模工作流、需求工作流、分析設(shè)計工作流、實現(xiàn)工作流、測試工作流和發(fā)布工作流。核心支撐工作流包括：環(huán)境工作流、項目管理工作流和配置與變更管理工作流。具體可以參考圖 1 。 RUP 匯集現(xiàn)代軟件開發(fā)中多方面的最佳經(jīng)驗，并為適應(yīng)各種項目及組織的需要提供了靈活的形式。作為一個商業(yè)模型，它具有非常詳細的過程指導(dǎo)和模板。但是同樣由于該模型比較復(fù)雜，因此在模型的掌握上需要花費比較大的成本。尤其對項目管理者提出了比較高的要求。 圖1 RUP 工作流程示意圖 IPD （ Integrated Product Development ）流程是由 IBM 提出來的一套集成產(chǎn)品開發(fā)流程，非常適合于復(fù)雜的大型開發(fā)項目，尤其涉及到軟硬件結(jié)合的項目。 IPD 從整個產(chǎn)品角度出發(fā)，流程綜合考慮了從系統(tǒng)工程、研發(fā)（硬件、軟件、結(jié)構(gòu)工業(yè)設(shè)計、測試、資料開發(fā)等）、制造、財務(wù)到市場、采購、技術(shù)支援等所有流程。是一個端到端的流程。在 IPD 流程中總共劃分了六個階段（概念階段、計劃階段、開發(fā)階段、驗證階段、發(fā)布階段和生命周期階段），四個個決策評審點（概念階段決策評審點、計劃階段決策評審點、可獲得性決策評審點和生命周期終止決策評審點）以及六個技術(shù)評審點，具體可以參考圖 2 。 IPD 流程是一個階段性模型，具有瀑布模型的影子。該模型通過使用全面而又復(fù)雜的流程來把一個龐大而又復(fù)雜的系統(tǒng)進行分解并降低風(fēng)險。一定程度上，該模型是通過流程成本來提高整個產(chǎn)品的質(zhì)量并獲得市場的占有。由于該流程沒有定義如何進行流程回退的機制，因此對于需求經(jīng)常變動的項目該流程就顯得不大適合了。并且對于一些小的項目，也不是非常適合使用該流程。 圖2 IPD 流程示意圖 三、流程與技術(shù) 流程和成功不是等價的。沒有流程就成功是不可能得到保證，但有了流程并不意味著肯定能夠成功。這恐怕是很多迷信于流程的人所不能接受的。但這的確是個事實。記得有個做了將近 30 多年的需求分析專家說過：即使是一個已經(jīng)達到 CMM4 級的公司，也完全有可能做不好需求分析。為什么？技術(shù)，技術(shù)是成功的另外一個必要條件。就好比現(xiàn)在你要從上海到北京去，流程給你指出了最短的路徑，技術(shù)提供給你最快的交通工具。兩者結(jié)合就是完美。 對于軟件開發(fā)來說，要保證軟件的質(zhì)量，需要掌握多方面的技術(shù)，包括分析技術(shù)、設(shè)計技術(shù)、編碼技術(shù)和測試技術(shù)等等。在國內(nèi)有一個普遍的非正常現(xiàn)象，就是大家覺得只有編程能力才是玩電腦的真正技能。就好像造一套房子，其它都不重要，只要磚瓦匠有高超的技能就行了。盡管這個比喻會打擊很多程序員的自尊心，但這的確是一個事實。我們?nèi)鄙傧到y(tǒng)級的工程師，在分析和設(shè)計方面的工作做得很不扎實。 需求是一個項目的靈魂。模棱兩可的需求帶來不可避免的后果便是返工 —— 重做一些你認(rèn)為已做好的事情。返工會耗費開發(fā)總費用的 4 0 % ，而 7 0 % ～ 8 5 % 的重做是由于需求方面的錯誤所導(dǎo)致的（ l e ff i n g w e l l1 9 9 7 ）【 10 】。想像一下如果你能減少一半的返工會是怎樣的情況？你能更快地開發(fā)出產(chǎn)品，在同樣的時間內(nèi)開發(fā)更多、更好的產(chǎn)品，甚至能偶爾回家休息休息。在《軟件需求》一書中關(guān)于如何進行需求分析給出了比較詳細的介紹【 7 】， RUP 中關(guān)于需求的指導(dǎo)也是很實用的。 設(shè)計是最能體現(xiàn)一個工程師能力和水平的環(huán)節(jié)。一個好的設(shè)計基本上決定了產(chǎn)品的最終質(zhì)量。設(shè)計是把需求轉(zhuǎn)換成系統(tǒng)的一個關(guān)鍵步驟，它需要從自然語言描述的需求中尋找出設(shè)計的基礎(chǔ)單元，構(gòu)建出整個系統(tǒng)的構(gòu)架。在 RUP 中關(guān)于系統(tǒng)構(gòu)架師和設(shè)計師的定位是相當(dāng)高的。關(guān)于設(shè)計方面的技能涉及面是很廣的，包括傳統(tǒng)的結(jié)構(gòu)化設(shè)計到面向?qū)ο笤O(shè)計。設(shè)計人員需要掌握一定的建模技術(shù)。 UML 是國際上比較流行的一種建模語言【 11 】。在嵌入式方面， SDL 也是一種非常好的選擇?！对O(shè)計模式》是在設(shè)計思想方面總結(jié)的非常出色的一本書【 6 】，作為一名設(shè)計人員（尤其是面向?qū)ο笤O(shè)計人員）必須要好好研究一下。但是對這些模式的應(yīng)用應(yīng)當(dāng)講究一種自然的應(yīng)用，千萬不要因為模式而去設(shè)計模式，否則會適得其反。 現(xiàn)在的程序員熱中于掌握多種編程語言，或者講究語言的過分技巧化，而往往忽略了編程語言的規(guī)范化。不規(guī)范的語言應(yīng)用給程序的可理解性、可維護性以及可測試性帶來了大的傷害，進而損害了產(chǎn)品的質(zhì)量。某公司曾對中國程序員和印度程序員做過一個測驗，這個測驗要求參加者對一組數(shù)進行排序。測試結(jié)果發(fā)現(xiàn)，印度程序員設(shè)計的程序使用的算法并不是最優(yōu)，但卻是最不容易出錯的，并且?guī)讉€程序員寫出來的代碼如出一轍。而幾個中國程序員寫出的代碼，有的非常漂亮，很精練，效率很高；有的卻很冗雜，還有錯誤。如果大家是在做研究性的項目或純粹興趣性的項目，那么充分發(fā)揮自己的編程天才也無可厚非。然而，對于一個軟件公司，產(chǎn)品最終是要交給用戶的，需要遵循的是一個軟件產(chǎn)品的開發(fā)工程。因此這類軟件的開發(fā)需要遵循一定的編程規(guī)范，畢竟開發(fā)的軟件不是自己用，還需要和別人的集成，還需要給以后版本重用和維護。 測試的技術(shù)將在第五節(jié)進行闡述。總之流程很關(guān)鍵，技術(shù)也很重要，我的觀點是：魚和熊掌，兩者都不能放。 四、全面質(zhì)量管理 自從 Deming 的全面質(zhì)量管理（ TQM ）原則在日本工業(yè)界獲得了巨大成功之后，這個原則迅速被傳播到了世界各個地方，同樣，全面質(zhì)量管理原則也被應(yīng)用到了軟件開發(fā)當(dāng)中。如前面提到的，軟件開發(fā)也是一個工程性的工作，因此必須提高整個工程的質(zhì)量。產(chǎn)業(yè)界的大量研究（ TRW 、 Nippon Electric 和 Mitre Corp. 以及其它一些公司）表明設(shè)計活動引入的錯誤占軟件過程中出現(xiàn)所有錯誤（和最終的缺陷）數(shù)量的 50 ％到 65 ％。根據(jù) IBM 的研究表明，假定在分析階段發(fā)現(xiàn)的錯誤其改正成本為 1 個單位的話，那么在測試之前（設(shè)計編碼階段）發(fā)現(xiàn)一個錯誤的修改成本約為 個貨幣單位，在測試時（集成測試，系統(tǒng)測試和驗收測試）發(fā)現(xiàn)一個錯誤的修改成本約為 15 個貨幣單位，而在發(fā)布之后（已經(jīng)交到用戶手上）發(fā)現(xiàn)一個錯誤的修改成本約為 60 到 100 個貨幣單位。同樣該比例也適用用于發(fā)現(xiàn)一個錯誤需要的時間。我們可以看下面兩條曲線圖： 圖3 缺陷代價曲線 為了提高產(chǎn)品質(zhì)量，縮短產(chǎn)品開發(fā)進度，節(jié)約產(chǎn)品開發(fā)成本，必須盡早的進行產(chǎn)品質(zhì)量控制。全面質(zhì)量控制要求在過程的每個階段每個步驟上都要進行嚴(yán)格的驗證和確認(rèn)活動。 什么是驗證？ 驗證 就是要用數(shù)據(jù)證明我們是不是在正確的制造產(chǎn)品。注意這里強調(diào)的是過程的正確行【 12 】。 什么是確認(rèn)？ 確認(rèn) 就是要用數(shù)據(jù)證明我們是不是制造了正確的產(chǎn)品。注意這里強調(diào)的是結(jié)果的正確性。 IEEE 給出的驗證和確認(rèn)過程可以用下圖來表示。驗證和確認(rèn)是一個廣泛的概念，感興趣的讀者可以參考 IEEE Std 1012-1998 。 圖4 驗證和確認(rèn)模型 五、關(guān)注測試 軟件測試是軟件質(zhì)量控制中的關(guān)鍵活動。業(yè)界的統(tǒng)計數(shù)據(jù)表明，測試的成本大約占軟件開發(fā)總成本的 50 ％左右。 軟件測試的目的是要發(fā)現(xiàn)軟件中的錯誤。一個好的測試是發(fā)現(xiàn)至今沒有被發(fā)現(xiàn)的錯誤。傳統(tǒng)的軟件測試專注于動態(tài)測試范疇，如：單元測試，集成測試和系統(tǒng)測試。而測試工程的發(fā)展已經(jīng)進入到了全流程的測試，包括開發(fā)過程前期的靜態(tài)測試。 一般我們可以把測試分為白盒測試和黑盒測試。 白盒測試 ：顧名思義，白盒測試應(yīng)當(dāng)是透明的。的確，該類測試是根據(jù)程序代碼的內(nèi)部邏輯結(jié)構(gòu)來設(shè)計測試用例進行測試。那么什么是測試用例？ 一個 測試用例 就是一個文檔，描述輸入、動作、或者時間和一個期望的結(jié)果，其目的是確定應(yīng)用程序的某個特性是否正常的工作。 黑盒測試 ：看了白盒測試的解釋，我想你很快就能猜出黑盒測試是不考慮程序內(nèi)部結(jié)構(gòu)情況的。事實上也是這樣。黑盒測試是根據(jù)規(guī)格說明書進行的測試。 規(guī)格說明書 記錄了用戶的需求。比如用戶希望在編輯器中增加查找功能，那么我們把該需求寫入規(guī)格說明書，根據(jù)該項要求，直接調(diào)用應(yīng)用程序的該項功能進行測試，而不管其內(nèi)部是用什么算法實現(xiàn)的。 白盒和黑盒這兩類測試是從完全不同的出發(fā)點，并且是兩個完全對立點，反映了事物的兩個極端，兩種方法各有側(cè)重，不能替代。但是在現(xiàn)代測試?yán)砟钪校@兩種測試往往不是決然分開的，一般在白盒測試中交叉使用黑盒測試的方法，在黑盒測試中交叉使用白盒測試的方法。 常見的白盒測試是單元測試。 單元測試 是測試中最小單位的測試。簡而言之，就是拿一個函數(shù)出來，加上驅(qū)動模塊，樁模塊，讓它能夠運行起來，然后設(shè)計一些用例測試其內(nèi)部的控制點（如：條件判斷點，循環(huán)點，選擇分支點等）。 驅(qū)動模塊 是模擬調(diào)用被測函數(shù)的函數(shù)。 樁函數(shù) 是模擬當(dāng)前測試函數(shù)所調(diào)用的函數(shù)。 常見的黑盒測試包括：集成測試，系統(tǒng)測試。 集成測試 是在單元測試的基礎(chǔ)上，將所有模塊按照設(shè)計要求（如根據(jù)結(jié)構(gòu)圖）組裝成為子系統(tǒng)或系統(tǒng)，進行集成測試。實踐表明，一些模塊雖然能夠單獨地工作，但并不能保證連接起來也能正常的工作。程序在某些局部反映不出來的問題，在全局上很可能暴露出來，影響功能的實現(xiàn)。 系統(tǒng)測試 的目的在于通過與系統(tǒng)的需求定義作比較，發(fā)現(xiàn)軟件與系統(tǒng)定義不符合或與之矛盾的地方。系統(tǒng)測試的測試用例應(yīng)根據(jù)需求分析說明書來設(shè)計，并在實際使用環(huán)境下來運行。系統(tǒng)測試的內(nèi)容極其廣泛，包括功能測試、協(xié)議測試、性能測試、壓力測試、容量測試等等。有關(guān)測試方面的概念可以參考本人已出版的《軟件測試技術(shù)概論》。 軟件測試是產(chǎn)品最終交付到用戶之前的最后一道防線，有著舉足輕重的地位。然而，做好軟件測試卻是不容易的，一方面你需要同時掌握軟件開發(fā)的技能和軟件測試方面的技能；另一方面產(chǎn)品必須給予測試充分的獨立性和資源保證。 六、成功的鐵三角 在一個軟件企業(yè)中，如果能夠良性的發(fā)展，必須關(guān)注組織，流程和人三者之間的關(guān)系。組織是流程成功實施的保障，好的組織結(jié)構(gòu)能夠有效的促進流程的實施；流程對于產(chǎn)品的成功有著關(guān)鍵的作用，一個適合于組織特點和產(chǎn)品特點的流程能夠極大的提高產(chǎn)品開發(fā)的效率和產(chǎn)品質(zhì)量，反之則會拖延產(chǎn)品開發(fā)進度，并且質(zhì)量也無法得到保證；對企業(yè)來說，人是最寶貴的財富，它們是技術(shù)的載體。對于一個軟件公司來說，無論是開發(fā)人員還是測試人員，都非常關(guān)心其今后的發(fā)展通道，如果有一條清晰的技術(shù)發(fā)展線為其指明今后的職業(yè)發(fā)展方向的話，這可以大大激勵員工的士氣和工作積極性。另外技術(shù)發(fā)展的方向應(yīng)該與現(xiàn)在的開發(fā)流程和規(guī)范相結(jié)合，這樣有利于專業(yè)技能的提高。 總之，組織，流程和人這三者是一個企業(yè)成功的鐵三角，理想的情況下它們彼此促進，糟糕的情況下它們彼此制約。 七、國際上流行的質(zhì)量標(biāo)準(zhǔn) 最早進入國內(nèi)的質(zhì)量標(biāo)準(zhǔn)是 ISO 系列。在軟件方面主要使用 ISO9000 系列標(biāo)準(zhǔn)。 ISO9000 是一個非常完整的標(biāo)準(zhǔn)，并且定義了供應(yīng)商設(shè)計和交付一個有質(zhì)量產(chǎn)品的能力所需要的所有元素。 ISO9002 涵蓋了對供應(yīng)商控制設(shè)計和開發(fā)活動所認(rèn)為重要的質(zhì)量標(biāo)準(zhǔn)。 ISO9003 用于證明供應(yīng)商在檢視和測試期間檢測和控制產(chǎn)品不一致性的能力。 ISO9004 描述和 ISO9001 、 ISO9002 和 ISO9003 相關(guān)的質(zhì)量標(biāo)準(zhǔn)，并提供了一個完整的質(zhì)量查檢表。 軟件能力成熟度模型是目前國內(nèi)軟件企業(yè)中非常受歡迎的一個質(zhì)量標(biāo)準(zhǔn)。并且該標(biāo)準(zhǔn)已經(jīng)成為業(yè)界一個事實上的標(biāo)準(zhǔn)。 CMM 為軟件組織提供了一個指導(dǎo)性的管理框架。在這個框架的指導(dǎo)下： ?? 軟件組織可以對其軟件開發(fā)、維護過程獲得控制。 ?? 軟件組織可以推進其軟件工程更為科學(xué)、推進軟件過程管理更為卓越。 ?? CMM 通過確定當(dāng)前軟件過程管理的成熟度，通過標(biāo)識軟件的質(zhì)量和過程改進中關(guān)鍵的、要害的問題，可以指導(dǎo)軟件組織選擇正確的軟件過程改進策略。 ?? CMM 將其焦點，聚焦在一系列具體的軟件過程活動上，并以侵略方式（ Aggressively ）達到這些活動。一個軟件組織就可以穩(wěn)定地、持續(xù)地改進其整個軟件組織過程，使得其軟件過程管理能力取得持續(xù)地、持久地不斷爭長提高。 在 CMM 中，把軟件工廠分為五個等級：初始級、可重復(fù)級、已定義級、管理級和優(yōu)化級。其中： 初始級 ：軟件過程是未加定義的隨意過程，項目的執(zhí)行是隨意甚至是混亂的。也許，有些企業(yè)制定了一些軟件工程規(guī)范，但若這些規(guī)范未能覆蓋基本的關(guān)鍵過程要求，且執(zhí)行沒有政策、資源等方面的保證時，那么它仍然被視為初始級。 可重復(fù)級 ：人們根據(jù)多年的經(jīng)驗和教訓(xùn)，總結(jié)出軟件開發(fā)的首要問題不是技術(shù)問題而是管理問題。因此，第二級的焦點集中在軟件管理過程上。一個可管理的過程則是一個可重復(fù)的過程，可重復(fù)的過程才能逐漸改進和成熟?？芍貜?fù)級的管理過程包括了需求管理、項目管理、質(zhì)量管理、配置管理和子合同管理五個方面；其中項目管理過程又分為計劃過程和跟蹤與監(jiān)控過程。通過實施這些過程，從管理角度可以看到一個按計劃執(zhí)行的且階段可控的軟件開發(fā)過程。 已定義級： 要求制定企業(yè)范圍的工程化標(biāo)準(zhǔn)，并將這些標(biāo)準(zhǔn)集成到企業(yè)軟件開發(fā)標(biāo)準(zhǔn)過程中去。所有開發(fā)的項目需根據(jù)這個標(biāo)準(zhǔn)過程裁剪出與項目適宜的過程，并且按照過程執(zhí)行。過程的裁剪不是隨意的，在使用前必須經(jīng)過企業(yè)有關(guān)人員的批準(zhǔn)。 管理級 ：所有過程需建立相應(yīng)的度量方式，所有產(chǎn)品的質(zhì)量（包括工作產(chǎn)品和提交給用戶的最終產(chǎn)品）需要有明確的度量指標(biāo)。這些度量應(yīng)是詳盡的，且可用于理解和控制軟件過程和產(chǎn)品。量化控制將使軟件開發(fā)真正成為一種工業(yè)生產(chǎn)活動。 優(yōu)化級： 的目標(biāo)是達到一個持續(xù)改善的境界。所謂持續(xù)改善是指可以根據(jù)過程執(zhí)行的反饋信息來改善下一步的執(zhí)行過程，即優(yōu)化執(zhí)行步驟。如果企業(yè)達到了第五級，就表明該企業(yè)能夠根據(jù)實際的項目性質(zhì)、技術(shù)等因素，不斷調(diào)整軟件生產(chǎn)過程以求達到最佳。 美國國防部規(guī)定，重要性級別高的軟件應(yīng)該由質(zhì)量級別高的企業(yè)承擔(dān)。不同等級的軟件公司提交的軟件，其軟件質(zhì)量也相差很大，國外的一份統(tǒng)計資料如下： 表 1 、 CMM 級別與軟件質(zhì)量關(guān)系表格 每千行軟件的缺陷數(shù)目 軟件過程成熟度等級 軟件準(zhǔn)時提交的百分比 每人每月生產(chǎn)的程序行數(shù) 軟件需要返工的百分比 平均軟件失效時間（近似） 大于 10 初始級 <=50 Z >=45 2 到 60 分鐘 小于 10 可重復(fù)級 90 20 1-160 小時 小于 1 已定義級 99 10 不確定 小于 管理級 降低開發(fā)時間到 1/2 5 Z 5 不確定 小于 優(yōu)化級 降低開發(fā)時間到 1/4 10Z <=2 近似完全可靠 對于很多已經(jīng)推行或者準(zhǔn)備推行 CMM 的公司來說， CMM 的起步是很難的，因此 Humphrey 又提出了 PSP （ Person Software Process ）和 TSP （ Team Software Process ）【 2 】【 3 】。 CMM 是過程改善的第一步，它提供了評價組織的能力、識別優(yōu)先改善需求和追蹤改善進展的管理方式【 1 】。企業(yè)只有開始 CMM 改善后，才能接受需要規(guī)劃的事實，認(rèn)識到質(zhì)量的重要性，才能注重對員工經(jīng)常進行培訓(xùn)，合理分配項目人員，并且建立起有效的項目小組。然而，它實現(xiàn)的成功與否與組織內(nèi)部有關(guān)人員的積極參加和創(chuàng)造性活動密不可分。 PSP 能夠指導(dǎo)軟件工程師如何保證自己的工作質(zhì)量，估計和規(guī)劃自身的工作，度量和追蹤個人的表現(xiàn)，管理自身的軟件過程和產(chǎn)品質(zhì)量。經(jīng)過 PSP 學(xué)習(xí)和實踐的正規(guī)訓(xùn)練，軟件工程師們能夠在他們參與的項目工作之中充分運用 PSP ，從而有助于 CMM 目標(biāo)的實現(xiàn)。 TSP 結(jié)合了 CMM 的管理方法和 PSP 的工程技能，通過告訴軟件工程師如何將個體過程結(jié)合進小組軟件過程，并將后者與組織進而整個管理系統(tǒng)相聯(lián)系；通過告訴管理層如何支持和授權(quán)項目小組，堅持高質(zhì)量的工作，并且依據(jù)數(shù)據(jù)進行項目的管理，向組織展示如何應(yīng)用 CMM 的原則和 PSP 的技能去生產(chǎn)高質(zhì)量的產(chǎn)品。 軟件的生產(chǎn)過程及其它的許多子過程、軟件的開發(fā)者和用戶、以及系統(tǒng)的使用中存在著巨大的變化和不同，要使一個軟件過程對軟件生產(chǎn)的改善真正有所幫助，其框架應(yīng)是由 CMM 、 TSP 和 PSP 組成的一個完整體系，即從組織、群組和個人三個層次進行良好的軟件工程和管理實踐的指導(dǎo)和支持?？偠灾?，單純實施 CMM ，永遠不能真正做到能力成熟度的升級，只有將實施 CMM 與實施 PSP 和 TSP 有機地結(jié)合起來，才能發(fā)揮最大的效力。 八、如何起步？ 質(zhì)量改進需要花費成本，因此改進的途徑需要視不同公司的規(guī)模、業(yè)務(wù)、財務(wù)狀況、人員技術(shù)水平等多方面綜合進行考慮。一般建議中型以上的較大的軟件公司實施 CMM 體系。而對于一些小型的軟件公司可以采取比較實際的，相對成本較少，且容易操作的方面進行，這些方面大致如下： ?? 實施簡潔的開發(fā)過程體系，根據(jù)不同業(yè)務(wù)特點可以選擇瀑布模型，迭代模型等，并在這些模型上進行適當(dāng)?shù)淖兓赃m應(yīng)于短平快的產(chǎn)品開發(fā)特點。 ?? 提高需求分析和設(shè)計方面的技術(shù)，例如：原型法技術(shù)，分析模式，設(shè)計模式，面向?qū)ο笤O(shè)計， UML 等； ?? 加強文檔化工作。文檔是經(jīng)驗的保留，對于一個企業(yè)要想獲得長期的發(fā)展，必須加強文檔化工作； ?? 加強編程規(guī)范工作； ?? 進行適當(dāng)?shù)臏y試工作，建議進行單元測試和系統(tǒng)測試； ?? 實施配置管理工作，加強版本控制； ?? 開展走讀、評審和檢視活動，尤其要加強代碼走讀，建議進行每日交叉走讀活動； ?? 進行簡單的度量分析獲得；建議實施 PSP 活動；