“金字塔工程”到“北極星導彈計劃”

論起專案管理的起源，其實很早。古代諸如金字塔、長城等著名的偉大工程專案的成功，都得助於當時對工程專案進行的嚴密和科學的管理。20世紀60年代初，在著名數學家華羅庚教授的倡導下，將專案管理的概念引入了我國，並在當時的國民經濟各個部門進行試點應用，將這種方法命名為“統籌法”。之後，中國科學院管理科學與科技政策研究所，還牽頭成立了“中國統籌法、優選法與經濟數學研究會

現代專案管理的概念起源於美國。上個世紀五十年代後期，美國的Booz-Allen

Lockheed公司首次在北極星導彈計劃中運用了PERT技術。同一時期，美國的Dupont and

RamintonnRand公司創造了CPM方法，用於研究和開發、生產控制和計劃編排，結果大大縮短了完成預定任務的時間，之後它們分別被稱為“計劃評審技術

9大知識體系與5個具體階段

早期的專案管理主要關注的是成本、進度(時間)，後來又擴充套件到質量。最近十幾年間，專案管理逐漸發展成為一個涵蓋9大知識體系、5個具體階段的單獨的學科分支。9大知識體系包括：

·整合管理在專案分析中，專案管理人員必須把各種能力綜合起來並加以協調利用。

·範圍管理定義專案的邊界，著眼於

·時間管理要求培養規劃技巧。有經驗的專案管理人員應該知道，當專案出現偏離規劃時，如何讓它重回規劃。

·成本管理要求專案管理人員培養經營技巧，處理諸如成本估計、計劃預算、成本控制、資本預算以及基本財務結算等事務。

·人力資源管理著重於人員的管理能力，包括衝突的處理、對職員工作動力的促進、高效率的組織結構規劃、團隊工作和團隊形成以及人際關係技巧。

·風險管理需要管理人員在資訊不完備的情況下作決定。風險管理模式通常由三個步驟組成：風險確定、風險影響分析以及風險應對計劃。

·質量管理要求專案管理人員熟悉基本的質量管理技術。例如：製作和說明質量控制圖、實施80：20規則、盡力達到零缺陷等。

·採購管理專案管理人員應掌握較強的合同管理技巧。例如，應能理解定價合同相對於“成本附加”合同所隱含的風險。應瞭解簽約中關鍵的法律原則。

·溝通管理要求專案管理人員能與他們的經理、客戶、廠商及屬下進行有效的交流。

5個階段是：專案啟動、專案計劃、專案執行、專案控制和專案收尾。

除此之外，作為一個稱職的專案管理專業人員，還必須具有相應的通用管理知識和經驗、相關的業務知識背景以及精深的風險管理經驗。也就是說，專案經理應當是一個具有相當豐富的知識並具有合理知識結構的高階複合型人才。

現在，專案管理在全球範圍內被政府、大型公司、企業以及小型非贏利組織廣泛地採用。與此同時，具備專案管理經驗和專案領導才能的管理者，在職場上變得炙手可熱。因為全球化的競爭要求新專案和新業務的發展都要在預算範圍內按時完成。

向專案管理要高效

專案是一項為了達到一個特殊目的而進行的臨時性活動。每一個專案有明確的開始和結束時間，專案能夠由組織的各個層次建立；涉及的人數可以是一個人，也可以是上千人；可以只涉及一個單獨的部門，也可以是跨部門的合作。專案管理可以應用於任何專案，而不受它的大小、預算或期限的限制，例如：

·開發一個新產品或服務；

·設計一個新車型；

·運作一次政治競選；

·建一座大橋；

·發射火星探測器；

·建立一個電子商務站點。

那麼，什麼是專案管理呢?按照PMBOK2000的定義，專案管理是運用相關的知識、工具和技術管理的活動，目的是滿足客戶對特定專案的要求。專案經理負責管理整個專案，他的工作主要是：

·在專案範圍、時間、成本、風險和質量之間做出最佳平衡；

·滿足不同專案干係人的不同需要和期望；

·實現既定的需求目標。

理想情況下，所有的企業都能夠從專案管理中獲益，特別是在管理資本投入和間接活動的花費上。在當今快速多變、全球化的市場環境下，所有型別的企業都需要看到它們投資在固定資產設施、房地產建設以及一些裝置的升級上面的回報和收益，或者要對一些內部功能的管理和跟蹤，如IT專案、市場專案等。無論什麼行業，專案管理都可以使企業通過更好的資訊共享來提高生產率和降低成本，在有限的資源條件下更快地以更低的成本交付產品和服務，從而增加營收。

專案管理可以幫助企業通過把日常工作標準化、減少可能被遺忘或被忽略的任務，來達到客戶的期望值；

專案管理也能使可利用的資源以最有效的方式得到最佳的利用；專案管理還能使高階管理者洞察到組織內正在發生的和將要發生的事件。

專案管理原則的應用能夠幫助高階管理層做到：

·建立成功的衡量指標；

·以客戶為中心並與客戶保持一致；

·量化體現價值的成本；

·優化組織資源的使用；

·貫徹質量原則和標準；

·實施戰略計劃；

·縮短新產品的研製週期並快速進入市場。

相關小知識

IPMA：國際專案管理協會，是一個在瑞士註冊的非贏利性組織，是專案管理國際化的主要促進者。IPMA創建於1965年，最早是一個在國際專案領域的專案經理之間交流各自經驗的論壇。1967年，IPMA在維也納主持召開了第一屆國際會議，專案管理從那時起即作為一門學科而不斷髮展。

IPMA的成員主要是各個國家的專案管理協會，到目前為止共有29個成員組織。這些國家的組織用他們自己的語言服務於本國專案管理的專業要求，IPMA則以廣泛接受的英語作為工作語言提供有關需求的國際層次的服務。為了達到這一目的，IPMA提供了大量的產品和服務，包括研究與發展、培訓和教育、標準化和證書制以及有關廣泛的出版物支撐的會議、學習班和研討會等。

PMI： Project Management

Institute（美國專案管理學術組織），成立於1969年，是一個有近5萬名會員的國際性學會。它致力於向全球推行專案管理，是專案管理專業最大的由研究人員、學者、顧問和經理組成的全球性專業組織，在教育、會議、標準、出版和認證等方面發起技術計劃和活動，以提高專案管理專業的水準。PMI正在成為一個全球性的專案管理知識與智囊中心。

前言
CMM（Capability Marurity Model，軟體能力成熟度模型）是於1984年美國國會與美國主要的公司和研究中心合作創立的一個由聯邦資助的非盈利組織——軟體工程研究所（Software Engineering Institute,SEI）的一個早期研究成果。該模型提供了軟體工程成果和管理方法的框架，自90年代提出以來，已在北美、歐洲和日本成功地應用。現在該模型已成為事實上的軟體過程改進的工業標準。下面我們來一起學習有關CMM的一些基礎知識。  
一、 CMM基本概念  
過程（Process）：為實現既定目標的一系列操作步驟[IEEE-STD-610].  
     軟體過程（Software Process）：指人們用於開發和維護軟體及其相關產品的一系列活動、方法、時間和革新。其中相關產品是指專案計劃、設計文件、編碼、測試和使用者手冊。當一個企業逐步走向成熟，軟體過程的定義也會日趨完善，其企業內部的過程實施將更具有一致性。  
     軟體過程能力（Software Process Capability）：描述了在遵循一個軟體過程後能夠得到的預期結果的界限範圍。該指標是對能力的一種衡量，用它可以預測一個組織（企業）在承接下一個軟體專案時，所能期望得到的最可能的結果。

軟體過程效能（Software Process Performance）：表示遵循一個軟體過程後所得到的實際結果。
    軟體過程成熟度（Software Process Maturity）：是指一個具體的軟體過程被明確地定義、管理、評價、控制和產生實效的程度。所謂成熟度包含著能力的一種增長潛力，同時也表明了組織（企業）實施軟體過程的實際水平。隨著組織軟體過程成熟度能力的不斷提高，組織內部通過對過程的規範化和對成員的技術培訓，軟體過程也將會被他的使用者關注和不斷修改完善。從而使軟體的質量、生產率和生產週期的到改善。

CMM是軟體過程能力成熟度模型（Capacity Maturity Model）的簡稱，是卡內基－梅隆大學軟體工程研究院為了滿足美國聯邦政府評估軟體供應商能力的要求，於1986年開始研究的模型，並於1991年正式推出了CMM 1.0 版。CMM自問世以來備受關注，在一些發達國家和地區得到了廣泛應用，成為衡量軟體公司軟體開發管理水平的重要參考因素和軟體過程改進事實上的工業標準。

CMMI（Capability Maturity Model Integration）即能力成熟度模型整合，這也是美國國防部的一個設想，他們想把現在所有的以及將被髮展出來的各種能力成熟度模型，整合到一個框架中去。這個框架有兩個功能，第一，軟體獲取方法的改革；第二，建立一種從整合產品與過程發展的角度出發、包含健全的系統開發原則的過程改進。

關鍵過程（區）域（Key Process Area）是指一系列相互關聯的操作活動，這些活動反映了一個軟體組織改進軟體過程時所必須滿足的條件。也就是說，關鍵過程域標識了達到某個成熟程度級別時所必須滿足的條件。在CMM中一共有18個關鍵過程域，分佈在第二至五級中。  
     關鍵實踐（Key Practices）：是指關鍵過程域中的一些主要實踐活動。每個關鍵過程域最終由關鍵實踐所組成，通過實現這些關鍵實踐達到關鍵過程域的目標。

軟體過程評估（Software Process Assessment）是用來判斷一個組織當前所涉及的軟體過程的能力狀態，判斷下一個組織所面向得更高層次上的與軟體過程相關的課題，以及利用組織的鼎力支援來對該組織的軟體過程進行有效的改進。  
     軟體能力評價是（Software Capability Appraisal）用來判斷有意承擔某個軟體專案的軟體組織的軟體過程能力，或是判斷已進行的軟體過程所處的狀態是否正確或是否正常。  

軟體工程組（Software Engineering Group）：負責一個專案的軟體開發和維護活動的團體。活動包括需求分析、設計、編碼和測試等。  
     軟體相關組（Software Related Groups）：代表一種軟體工程科目的團體，它支援但不直接負責軟體開發或維護工作，如軟體質量保證組、軟體配置管理組合軟體工程過程組等等。在CMM的關鍵實踐中，軟體相關組通常應該根據關鍵過程域和組織的上下文來理解。

軟體工程過程組（Software Engineering Process Group）：是由專家組成的組，他們推進組織採用的軟體過程的定義、維護和改進工作。在關鍵實踐中，這個組織通常指“負責組織軟體過程活動的組”。  
     系統工程組（System Engineering Group）：是負責下列工作的個人的團體：分析系統需求；將系統需求分配給硬體、軟體和其他成分；規定硬體、軟體和其他成分的介面；監控這些成分的設計和開發以保證它們符合其規格說明。

系統測試組（System Test Group）：是一些負責策劃和完成獨立的軟體系統測試的團體，測試的目的是為了確定軟體產品是否滿足對它的需求。

     軟體質量保證組（Software Quality Assurance Group）：是一些計劃和實施專案的質量保證的團體，其工作目的是保證軟體過程的步驟和標準是否得到遵守。

軟體配置管理組（Software Configuration Management Group）：是一些負責策劃、協調和實施軟體專案的正式配置活動的團體。

     培訓組（Training Group）：是一些負責協調和安排組織培訓活動的團體。通常這個組織負責準備和講授大多數培訓課程並協調其他培訓方式的使用。
CMM 的分級
任何一個軟體的開發、維護和軟體組織的發展離不開軟體過程，而軟體過程經歷了不成熟到成熟、不完善到完善的發展過程。它不是一朝一夕就能成功的，需要持續不斷的對軟體過程進行改進，才能取得最終的成效。CMM就是根據這一指導思想設計出來的。該模型為了正確和有序地引導軟體過程活動的開展，建立一個能夠有效地描述和表示的軟體過程的改進框架，使其能夠對各階段軟體過程的任務和管理起指導作用。該模型以產品質量的概念和軟體工程的經驗教訓為基礎，指導企業如何控制開發、維護軟體的生產過程和如何制定一套與之相適應的軟體過程及管理體系。
（一）、分級標準
CMM模型描述和分析了軟體過程能力的發展程度，確立了一個軟體過程成熟程度的分級標準。一方面軟體組織利用它可以評估自己當前的過程成熟度，並以此提出嚴格的軟體質量標準和過程改進的方法和策略，通過不斷的努力去達到更高的成熟程度。另一方面，該標準也可以作為使用者對軟體組織的一種評價標準，使之在選擇軟體開發商時不再是盲目的和無把握的。

CMM的分級結構可以描述為：
     ①、初始級：軟體過程的特點是無秩序的，有時甚至是混亂的。軟體過程定義幾乎處於無章法和步驟可循的狀態，軟體產品所取得的成功往往依賴於極個別人的努力和機遇。
     ②、可重複級：已建立了基本的專案管理過程，可用於對成本、進度和功能特性進行跟蹤。對類似的應用專案，有章可循並能重複以往所取得的成功。
     ③、已定義級：用於管理的和工程的軟體過程均已文件化、標準化，並形成了整個軟體組織的標準軟體過程。全部專案均採用與實際情況相吻合的、適當修改後的標準軟體過程來進行操作。

④、已管理級：軟體過程和產品質量有詳細的度量標準。軟體過程和產品質量得到了定量的認識和控制。
     ⑤、優化級：通過對來自過程、新概念和新技術等方面的各種有用資訊的定量分析，能夠不斷地、持續地對促進過程進行改進。
除第一級外，每一級都設定了一組目標，如果達到了這組目標，則表明達到了這個成熟級別，自然可以向下一級別邁進。CMM體系不主張跨級別的進化。因為從第二級開始，每一個低級別的實現均是高級別實現的基礎。
（二）CMM的主要內容
CMM為軟體企業的過程能力提供了一個階梯式的進化框架，它採用分層的方式來解釋其組成部分，如圖示。在第二至第五個成熟等級中，每個等級包含一個內部結構的概念。      每一級向上一級邁進的過程中都有其特定的改進計劃，具體情況如下。

初始級的改進方向是：建立專案過程管理，是使規範化管理，保障專案的承諾；豔進行需求管理方面的工作，建立使用者域軟體專案之間的溝通，使專案真正反映使用者的需求；建立各種軟體專案幾乎，如軟體開發計劃、軟體質量保證計劃、軟體配置管理計劃、軟體測試計劃、風險管理計劃及過程改進計劃等；積極開展軟體質量保證活動（SQA）。
     可重複級的改進方向是：不再按專案制定軟體過程，而是總結各種專案的成功經驗，使之規則化，把具體經驗歸納為權利組織的標準軟體過程，把改進軟體組織的整體軟體過程能力的軟體過程活動，作為軟體開發組織的責任；確定全組織的標準軟體過程，把軟體工程及管理活動整合到一個穩固確定的軟體過程中，從而可以跨專案改進軟體過程效果，也可以作為軟體過程剪裁的基礎；建立軟體工程過程小組（SPEG）長期承擔評估域調整軟體過程的任務，以適應未來軟體專案的要求；積累資料，建立組織的軟體過程庫及軟體過程相關的文件；加強培訓。

已定義級的改進方向是：著手軟體過程的定量分析，已達到定量地控制軟體專案過程的效果；通過軟體的質量管理達到軟體質量的目標。
     已管理級的改進方向是：防範缺陷，不僅在發現了問題能及時改進，而且應採取特定行動防止將來出現這類缺陷；主動進行技術改革管理、標識、選擇和評價新技術，是有效的新技術能在開發組織中實施；進行過程變更管理，定義過程改進的目的，經常不斷地進行過程改進。
     優化級的改進目標方向是：保持持續不斷的軟體過程改進。
（三）CMM的內部結構
CMM為軟體過程能力的提高提供了一條改進的途徑。CMM由5個成熟度等級組成，每個成熟度等級有著各自的功能。除第一級外，CMM的每一級按完全相同的內部結構構成的。成熟度等級為頂層，不同的成熟度等級反映了軟體組織的軟體過程能力和該組織可能實現預期結果的程度。 在CMM中，每個成熟度等級（第一級除外）規定了不同的關鍵過程域，一個軟體組織如果希望達到某一個成熟度級別，就必須完全滿足關鍵過程域所規定的要求，即滿足關鍵過程域的目標。
（四）軟體過程評估和軟體能力評價
軟體過程評估所針對的是軟體組織自身內部軟體過程的改進問題，目的在於發現缺陷，提出改進方向。評估組以CMM模型為指引調查、鑑別軟體過程中的問題，翻過來將這些問題與CMM關鍵實踐活動所提出的指導一起用於確定組織的軟體過程改進策略。
     軟體能力評價是對接受評價者在一定條件下、規定時間內能否完成特定專案的能力考核，即承擔風險的係數大小。評價包括承包者是否有能力按計劃開發軟體產品，是否能按預算完成等。通過利用CMM模型確定評價結果後，就可以利用這些結果確定選擇某一承包商的風險。也可以用來判斷承包者的工作程序，推動他們解決軟體過程。

CMM為評估和評價提供了一個參考框架，指出了在評估和評價中通常採用的步驟。      具體來說，評估過程是：選擇一個工作組；完成問卷調查和取樣工作；結果分析；現場訪問；與CMM模型對照分析；依據關鍵過程域的基本情況列出評估提綱。以上步驟在軟體過程評估和軟體能力評價題勾勒很有參考價值的方法，但在具體操作時以下這些特點也值得考慮：

     ①、在現場訪問和考察中，充分運用成熟度問卷和結果分析為依據。
     ②、以CMM模型作為現場調查的路線圖。
     ③、利用CMM中的關鍵過程域定義軟體過程中的優點和缺陷，從中發現差異。
     ④、對關鍵過程域目標是否是滿足的實際情況出發，分析滿意程度，寫出書面報告。
     儘管軟體過程評估和軟體能力評價有很多相似之處，但由於其目的和結果的不同，它們之間的差異也是必然存在的，如：

①、軟體過程評估和軟體能力評價在出發點和目標上的不同，使得會談目的、調查範圍、收集的資訊和輸出的表示方式上有著本質的不同。尤其在一些細節規範方面，評估和評價的方法有很大差異。      ②、軟體過程評估和軟體能力評價的結果和結果所起的作用不同。因為兩者的側重點不一樣，即使是對同一個應用專案，運用相同的方法，也不會得出相同的結果。      ③、被評估和評價單位的態度對評估和評價活動的影響。評估在某種意義上被評估單位的態度較積極，而評價在某種意義上被評價單位的態度可能比較慎重。軟體過程評估是在一個開放的、互相協作的環境中進行的，而軟體能力評價往往是在有較大的阻力的環境中進行的。

（五）CMM的組織保證

    當人們面對CMM實施時，首先想到的就是人員的構成和各種小組的劃分。它是實施CMM的組織保證，是一切活動的基礎。CMM在制定軟體過程實施中本著儘量不和具體的組織機構和組織形式相聯絡的原則，為的是提供一個獨立於具體企業而又有廣泛指導意義的模型框架。但在實施各種軟體關鍵實踐中，不可避免地要涉及到角色和組織結構。所以為了使CMM能夠適用各種級別和各種規模的企業，SEI提出了一個相對抽象的組織結構，它與組織、專案、人員（角色）相關聯，具有自己特定的術語，而且可能不同於其他組織所用的名詞。例如基本概念中提到的主要的軟體工作組的概念。

三、 正確的態度看待CMM

    SEI的CMM並不是軟體開發的方法學，也不是產品模板，更不是過程法律。CMM是過程改進的途徑，是一套指南，幫助你通過持續的重複、測量和提煉，穩步創造與淨化開發環境。CMM的假定是：如果你實施一個不斷重複、測量和提煉的大綱，作為環境改進的副產物，質量便會自然的提高。不要把CMM設想為一套規則，而應將它理解為一個學科，做事的一般方法。在這套指南下運作，你會發現這裡有著廣闊的空間，讓你剪裁和塑造自己的大綱，以適應組織的特定要求。

CMM不採用“用這種方法做這類事”的風格，它也不對由問題的IT組織提供快速的糾正方案。CMM是一個指南針，指導你如何逃離暴風雪。CMM是一個大綱，要求你對整個IT組織的有關部分，從高層領導到軟體生產的第一次線工作者，都做出堅定的、長期的實施承諾。成熟的過程不可能在它之間實現。
     在如何解釋CMM建議時，它允許極大的靈活性。CMM意識到，IT組織之間存在著很大的差別。他們的客戶不同，使用的工具不同，人員智力和專業背景不同，從事的專案屬於不同的型別，規模大小不同，要求也各不相同。因而，他們應當以自己的方式走向成熟。在一處活用的東西，在另一處未必適用。這一點非常重要，中國部分軟體公司的前車之鑑也從某種程度上給了我們建議和經驗教訓，那就是，要靈活應用CMM，不要幻想一夜就有成效。
從 CMM 到 CMMI 的對映
CMM 到 CMMI 的對映是一個複雜的體系，它涉及到 KPA 重構， KP 的再組織。圖 1 只是從總體上描述了 CMM 到 CMMI 的對映關係。

對映分析
CMMI 雖然是建立在 CMM 基礎之上，兩者大部分相似，但還是有很大差異。從總體上講， CMMI 更加清晰的說明各過程域和類屬實踐（ generic practice ）如何應用實施，並指出如何將工作產品納入相應等級的配置和資料管理基線，風險管理策略，驗證策略等。 CMMI 包含更多工程活動，如需求開發，產品整合，驗證等過程域；過程內容的定義更加清晰，較少強調文件化規程。
如圖，在 CMMI2 級中增加了測量和分析 KPA （ Measurement and analysis ），將各測量分析實踐（ KP ）歸結為一個正式的關鍵過程域，而在 CMM 中測量分析實踐是散落在各等級中的。因此在 CMMI 中更加強調了量化管理，管理的透明度和軟體開發的透明度得到了升級。

CMMI3 級中增加了需求開發（ Requirements Development ）、技術解決方案（ Technical Solution ）、產品整合（ Product Integration ）、驗證（ Verification ）、確認（ Validation ）、風險管理（ Risk Management ）、決策分析和決定（ Decision Analysis and Resolution ） KPAs 。 CMM 中的軟體產品工程 KPA 被需求開發，技術解決方案，產品整合，驗證，確認 KPAs 所取代；同行評審 KPA 被融入到驗證 KPA 中； CMM 中整合軟體管理 KPA 所闡述的風險管理在 CMMI3 中形成了一個獨立風險管理 KPA 。同時整合軟體管理和組間協調 KPAs 合併成整合專案管理 KPA 。合成團隊、決定分析和解決方案、組織的一體化環境 KPAs 是全新的，其過程內容在 CMM 中沒有提及。
CMMI4 中沒有新的過程域，只是對原來的定量過程管理，軟體質量管理 KPAs 重新構建為定量專案管理和組織過程效能 KPAs 。
CMMI5 中的技術變更管理和過程變更管理 KPAs 合併為組織革新與技術推廣 KPA ，缺陷防範 KPA 重新構建為原因分析和解決方案 KPA 。
CMM 到 CMMI 的升級
升級前的準備工作
(1) 回顧 CMMI 模型和其他的 CMMI 資訊，確定如何使 CMMI 最好的滿足組織需要（ 2 ）擬訂升級策略。（ 3 ） 在升級過程中確保以前用於 CMM 改進的投資得到維持和運用（ 4 ）將升級事項通告客戶（ 5 ）將對現有過程域和新增過程域的改進費用編入預算，並提供有關改進需要的培訓。（ 6 ）確定組織升級計劃的風險表並管理這些風險，關鍵要識別 CMM 和 CMMI 之間的差異以及這些差異如何得到支援。

升級的方法：
一旦做好了升級前的準備工作，弄清了升級可帶來的利益和成本，可執行下列活動進行升級，這些活動是迭代的。
（ 1 ） 選擇適合組織最好的 CMMI 模型。 CMMI 覆蓋各種知識體，包括專案管理，軟體工程，系統工程，整合產品，過程開發供應商來源。按組織的商業目標選擇模型。
（ 2 ）選擇最適合組織的表示法。 CMMI 有階段式表示法和連續式表示法，由於 CMM 採用的是階段式的表示法，許多組織都採取 CMMI 階段式表示法，若組織對連續式表示法較熟悉，也可以採取連續式表示法。
（ 3 ）將選擇的 CMMI 模型與 CMM 對比，確定需要變更的範疇。具體的對比見上文。 變更的主要活動是對 CMMI 中重組的 KPA 及 CMMI 中新增的 KPA 進行更新。

（ 4 ） 確定升級會帶來的影響。
（ 5 ）向 CMMI 升級因該報高階管理層的認可。
（ 6 ）變更組織目前的過程改進計劃以支援 CMMI 升級。過程改進計劃要反映出工作的優先順序、組織所需增加的新部門。將該計劃送交評審，得到關鍵儲金保管者（ key stakeholders ）的許諾和認可，計劃要說明升級可能帶來的管理風險和進度風險，所需的培訓，工具，和服務支援。傳達這個計劃並保持更新。
（ 7 ）確保對工程過程組，技術工作組及其他相關的員工進行 CMMI 的培訓。
（ 8 ）獲取 SCAMPI 評估支援。
（ 9 ） 修改每個專案已定義的過程使其與專案改進計劃一致。
（ 10 ）給每個專案制定升級進度表 不同的專案升級進度表可能不同，如果有的升級工作已經完成則該工作可以拋棄。
（ 11 ）執行 SCAMPI 評估，看是否所有的目標過程域和目標得到支援。
處於 CMM 不同成熟等級的組織所做的具體工作
（ 1 ） CMM1 級：
如果組織正使用 CMM 模型致力於過程改進而並處於 CMM1 級，那麼組織應該繼續用 CMM 模型。在改進的同時，組織將 CMM2 與 CMMI2 進行對比和差異確認，分析這些差異中哪些是對組織有價值的。當組織剛達到 CMM2 級時其主要工作時立即從 CMM2 向 CMMI2 升級。
（ 2 ） CMM2 級，
組織應該把其當前的過程改進向 CMMI2 級對映，填補兩者之間的差距，從 CMM2 升級到 CMMI2 完成後，在下一步的工作中採用 CMMI 模型進行過程改進。主要有一下幾方面

(1) 將 CMM 中分散的測量分析活動集中到 CMMI2 級測量分析 KPA 中，形成一個獨立的過程域，提高開發的透明度。
(2) 重定位測量分析 KPA （ Measurement and Analysis ）的共同特徵（ common feature ）
測量分析 KPA 重組見表 所示。

表示符說明： QPM Co 2 Ac1,3,4,5,6 表示定量過程管理（ Quantitative Process Management ）過程域執行的約定（ Commitment to perform ） 2 和執行活動（ Activities to perform ） 1,3,4,5,6 。
Co 表示執行的約定； Ab 表示執行的能力； Ac 表示執行的活動； SG 表示特殊目標（ Special Goal ）； GG 表示一般目標（ Generic Goal ）；其他可類推。

（ 3 ） CMMI3 級
①將 CMM 軟體產品工程 KPA 分解為需求開發、技術解決方案、產品整合、認證、確認 KPAs ，並進行擴充。
②瞭解 CMMI3 級中新增的決定分析和解決方案、合成團隊，組織一體化環境 KPAs ，並填補。
③迭代 CMM2 級的工作。
說明
卡內基梅隆大學軟體工程研究所推出 CMM Version 2.0 draft C 後就停止了在 CMM 的改進。 CMM 被 CMMI 所取代是大勢所趨。許多正在運用 CMM 模型進行軟體過程改進的組織紛紛向 CMMI 升級。而 CMMI 模型迄今還沒有成熟，卡內基梅隆大學軟體工程研究所 推出了 CMMI-SE/SW 1.1 和 CMMI-SE/SW/IPPD ，在目前的產品集中沒有關於軟體採購方面的內容，估計以後還會推出這個科目。而且從 CMM 向 CMMI 升級也只是處於嘗試階段。組織升級的操作過程，運用 CMMI 模型所帶來的效益等資訊還很匱乏，這些資訊也為未能及時反饋到卡內基梅隆大學軟體工程研究所，這也給 CMMI 模型的改進及向 CMMI 的升級工作帶來了一定的難度。

關於CMM評估的一些背景資料
CMM評估包括5個等級，共計18個關鍵過程域，52個目標，300多個關鍵實踐。每一個CMM等級評估週期（從準備到完成）約需12-30個月。每一級別的評估由美國卡內基梅隆大學的軟體工程研究所授權的主任評估師領導一個評審小組進行，其成員大部分來自企業內部。評估過程包括員工培訓（企業的高層領導也要參加）、問卷填寫和統計、文件審查、資料分析、與企業的高層領導討論和撰寫評估報告等。評估結束由主任評估師簽字生效。國外CMM等級評估生效，只需要主任評估師的簽字，既沒有某主管單位的批准，也沒有蓋上公章的證書。顯然，國外更看重主任評估師及公司的信譽。

取得主任評估師的資格的條件： § 首先要有10年以上的軟體開發經驗； § 其次要在美國卡內基梅隆大學的軟體工程研究所接受培訓，培訓費用每人約需數萬美元，非美國人加倍； § 第三要經過兩次以上CMM評估的全過程實習； § 第四要得到已有主任評估師資格的人推薦。主任評估師的資格並非終身制，如要繼續保持，每年至少要參加兩次CMM評估。 目前全世界一共只有313個主任評估師，大部分在美國，而我國大陸還沒有一個主任評估師。由於我國在CMM評估中要聘請外籍主任評估師，所以費用較高。據估計，要通過一個級別的CMM評估，費用是通過ISO9001認證的十多倍。
作業
1、請用圖表的形式描述CMM的分級結構？
2、軟體過程效能和軟體過程能力的主要區別是什麼？
3、關鍵實踐的主要描述的是什麼？
4、CMM和CMMI的主要區別有哪些？
5、假如你是SQA，你應該具有什麼樣的心態去看待CMM的評定？

軟體工程的七條基本原理

       自從1968年提出“軟體工程”這一術語以來，研究軟體工程的專家學者們陸續提出了100多條關於軟體工程的準則或信條。美國著名的軟體工程專家 Boehm 綜合這些專家的意見，並總結了TRW公司多年的開發軟件的經驗，於1983年提出了軟體工程的七條基本原理。

Boehm 認為，這七條原理是確保軟體產品質量和開發效率的原理的最小集合。它們是相互獨立的，是缺一不可的最小集合；同時，它們又是相當完備的。人們當然不能用數學方法嚴格證明它們是一個完備的集合，但是可以證明，在此之前已經提出的100多條軟體工程準則都可以有這七條原理的任意組合蘊含或派生。下面簡要介紹軟體工程的七條原理：

1 用分階段的生命週期計劃嚴格管理這一條是吸取前人的教訓而提出來的。統計表明，50%以上的失敗專案是由於計劃不周而造成的。在軟體開發與維護的漫長生命週期中，需要完成許多性質各異的工作。這條原理意味著，應該把軟體生命週期分成若干階段，並相應制定出切實可行的計劃，然後嚴格按照計劃對軟體的開發和維護進行管理。 Boehm 認為，在整個軟體生命週期中應指定並嚴格執行6類計劃：專案概要計劃、里程碑計劃、專案控制計劃、產品控制計劃、驗證計劃、執行維護計劃。

2 堅持進行階段評審統計結果顯示：大部分錯誤是在編碼之前造成的，大約佔63%; <2> 錯誤發現的越晚，改正它要付出的代價就越大，要差2到3個數量級。因此，軟體的質量保證工作不能等到編碼結束之後再進行，應堅持進行嚴格的階段評審，以便儘早發現錯誤。

3 實行嚴格的產品控制開發人員最痛恨的事情之一就是改動需求。但是實踐告訴我們，需求的改動往往是不可避免的。這就要求我們要採用科學的產品控制技術來順應這種要求。也就是要採用變動控制，又叫基準配置管理。當需求變動時，其它各個階段的文件或程式碼隨之相應變動，以保證軟體的一致性。

4 採納現代程式設計技術從六、七時年代的結構化軟體開發技術，到最近的面向物件技術，從第一、第二代語言，到第四代語言，人們已經充分認識到：方法大似氣力。採用先進的技術即可以提高軟體開發的效率，又可以減少軟體維護的成本。

5 結果應能清楚地審查軟體是一種看不見、摸不著的邏輯產品。軟體開發小組的工作進展情況可見性差，難於評價和管理。為更好地進行管理，應根據軟體開發的總目標及完成期限，儘量明確地規定開發小組的責任和產品標準，從而使所得到的標準能清楚地審查。

6 開發小組的人員應少而精開發人員的素質和數量是影響軟體質量和開發效率的重要因素，應該少而精。這一條基於兩點原因：高素質開發人員的效率比低素質開發人員的效率要高几倍到幾十倍，開發工作中犯的錯誤也要少的多；當開發小組為N人時，可能的通訊通道為N(N-1)/2, 可見隨著人數N的增大，通訊開銷將急劇增大。

7 承認不斷改進軟體工程實踐的必要性遵從上述六條基本原理，就能夠較好地實現軟體的工程化生產。但是，它們只是對現有的經驗的總結和歸納，並不能保證趕上技術不斷前進發展的步伐。因此，Boehm提出應把承認不斷改進軟體工程實踐的必要性作為軟體工程的第七條原理。根據這條原理，不僅要積極採納新的軟體開發技術，還要注意不斷總結經驗，收集進度和消耗等資料，進行出錯型別和問題報告統計。這些資料既可以用來評估新的軟體技術的效果，也可以用來指明必須著重注意的問題和應該優先進行研究的工具和技術。

常用的功能測試方法

   此文是對我個人測試思想的一個總結，由於經驗不夠，知識淺薄，如果有什麼不合理的地方請一笑了之。一、面向物件的概念所謂的面向物件是軟體開發的一種重要的思維方式，是把軟體開發過程中出現的事物,用一個個的對像來分析.一般一張資料表可以封裝為一個對像。用個形象的比喻：我們現在要做一張桌子，首先我們考慮到的是我們要做的是什麼？是桌子；桌子是用來幹什麼的呢？是用來吃飯、喝茶、看書、打麻將的；然後就要考慮桌子由哪些部分組成？由桌面和桌腿來組成；接著我們需要考慮我們採用什麼材料呢？紙？不行...那可什麼都幹不成，OK，用木頭；接著就可以開始把組成桌子的元件做為物件開始分析--桌面如何做是用刀砍的還是用刨子刨呢？桌腿又如何做...
一套完整的方法成形了就可以具體實現了，在做的過程中桌面要做多大，桌腿要做多長都要事先考慮到是不是要留出介面，這些就是我們給組成桌子的元件賦予的屬性。OK，現在可以做出具體的實物了，做好實物元件（物件）以後就要將做好的桌面桌腿進行組裝，由於我們事先考慮好了元件的屬性，考慮到了必須預留介面，因此我們可以很輕易的組合成功，桌子做出來了。以上就是面向物件的思想的一個簡要的比喻瞭解面向物件必須瞭解的幾個名詞：物件、方法、屬性、繼承、多型二、遊戲測試遊戲測試是整個軟體測試行業中比較特殊的一部份，他有著大多數軟體測試的共性，也具備自身的特性，而相對於許多通用軟體的測試來說，遊戲測試所具備的特性是非常明顯的。現在就簡要的說說上面提到的共性和特性。共性：
1、測試的目的就是為了儘可能的發現軟體存在和潛在的問題。
2、測試都是需要測試人員按照產品行為描述來實施。產品行為描述可以是書面的規格說明書、需求文件、產品檔案、或是使用者手冊、原始碼、或是工作的可執行程式。
3、每一種測試都需要產品運行於真實的或是模擬環境之下。
4、每一種測試都要求以系統方法展示產品功能，以證明測試結果是否有效，以及發現其中出錯的原因，從而讓程式人員進行改進。總之，軟體測試就是對產品進行儘可能的全面檢查，儘可能的發掘bug，提高軟體質量，從而為企業創造利潤。特性：網路遊戲世界從某種意義上說是另一個人類社會，只是人們在網路遊戲世界中進行著在被允許的範圍內的活動，包括了修煉、交流、合作、經商、欺詐、情感、衝突等等。而在遊戲製作時這些進行這些行為的部分就是一個個完整的功能，我們在進行測試的時候，需要考慮的不僅僅是能否實現功能，要考慮更多的是人們在進行操作時會如何做，可能有多少種做法，這些做法應該有什麼樣的響應，哪些做法是被禁止的，在進行了被禁止的操作後應該有什麼的響應。因此這裡就是涉及到了遊戲世界的測試方法：
1、遊戲情節的測試，主要指遊戲世界中的任務系統的組成，有人也稱為遊戲世界的事件驅動，我喜歡稱為遊戲情感世界的測試。
2、遊戲世界的平衡測試，主要表現在經濟平衡,能力平衡（包含技能，屬性等等）,保證遊戲世界競爭公平。
3、遊戲文化的測試，比如整個遊戲世界的風格，是中國文化主導,還是日韓風格等等，大到遊戲整體，小到N P C（遊戲世界人物）對話，比如一個書生，他的對話就必需斯文，不可以用江湖語言。以上陳述中關於遊戲特性的部分概念是曾在金山公司的測試人陳衛俊提出來過的,在此引用三、如何用面向物件的思想進行測試上面瞭解了面向物件的概念以及遊戲測試和通用軟體測試的區別以後我們可以進入正題了---如何用面向物件的思想進行遊戲測試?
    首先,和所有通用軟體以及硬體產品一樣,我們的遊戲是一個產品,是一個存在的實體,因此,我們把這個"實體"當做一個大的物件開始分析,整個遊戲由哪些部分構成,而構成整個遊戲的大的部分又由哪些元件構成,認真分析完這些以後就可以著手進行測試了,注意,這裡說"可以進行測試了"意思不是馬上就能進入測試,聽我慢慢道來.
     "工欲善