軟件能力描述了通過遵循軟件過程能夠實現預期結果的程度，就是軟件企業在一個項目時其項目過程曲線的“波動帶”，即項目圍繞項目計劃開發過程中的變化范圍。隨著成熟度級別的提高，在項目過程中關鍵點的目標結果與實際結果之間的差距越來越小、項目的可預見性將越來越高、項目過程中實際結果的變化范圍將越來越小。
CMM在一個更高的層次抽象的關注組織上和管理上的問題，它只告訴我們要做什么，但卻沒有告訴我們要怎么做。它描述了一個軟件企業的流程管理需要關注的屬性和希望達到的目標，但它卻沒有在操作層面具體的描述要怎么實現這些目標。因為不同的軟件企業，在規模和管理模式上不盡相同，CMM不是一濟能醫治百病的靈丹妙藥，也不是一種“立竿見影”式的管理技術，它只是一種不斷改進企業自身能力的方法，在具體的應用上，還要和企業的生產流程、管理模式、職能分布等因素結合起來，建立一套適合本企業生產發展的軟件過程，才能使企業的軟件項目在成本、進度、質量這個鐵三角里找到最佳的平衡點。
CMM的官方文檔里面也有說到，當企業的員工少于50人時，需要對CMM的各個KPA做橫向、縱向和深度的剪裁。我們是金融機構的科技部門，只有在編員工四十人，所以，CMM龐大的體系并不完全適用于我們，必需根據我們自身的實際需要和管理特征，對CMM體系做相應的剪裁。
銀行的軟件開發部門和一般的軟件企業相比，有以下的不同點：
1、一般的軟件企業有產品發布的市場風險和產品開發的自由度，而我們沒有根據市場需求發布產品的需要，我們所做的項目也必須與企業的發展戰略相適應，為企業的發展助力。
2、一般的軟件企業在項目完成軟件產品交付以后只需對軟件做保修性質的維護，而我們需要對產品做長期的運行管理和升級維護，并且根據業務規模的擴大不斷的修改軟件的屬性和增加軟件的功能。
3、一般的軟件企業是由項目堆砌起來的，項目盈利了企業才能盈利；而我們是屬于銀行內部的軟件開發部門，承接的項目都是為企業服務的。
根據業務需求的范圍，把需求分為兩類：
項目級需求，新的子系統，主要通過合同外包或內部項目組開發完成。
交易級需求，在原有系統的基礎上增加新的交易或對原有的交易進行修改，主要由內部項目組完成。
根據我們自身的一些實際情況，在CMM的剪裁上，我們可以在縱向上以CMM2級為核心，向CMM3級CMM4級延伸，橫向保留CMM2級的大部分KPA，在此基礎上增加CMM3級的組間協調、集成軟件管理、培訓大綱的KPA，以及CMM4級的軟件質量管理KPA，在深度上做根據我們自身的需要，對各個KPA的具體活動做相應的裁減。
在這里，我們對CMM2級的相關KPA進行討論。CMM2級的核心是實現項目的文檔化管理，主要包含有六個KPA，分別是：需求管理(RM)；軟件項目計劃(SPP)；軟件項目跟蹤與監控(SPTO)；子合同管理(SSM)；軟件質量保證(SQA)；軟件配置管理(SCM)。
·需求管理(RM)
需求是整個項目的出發點和落腳點，是項目過程中其他各個環節依賴的基礎。但是，在一個軟件項目開發的過程中，隨著用戶對系統的了解和業務范圍的擴大，需求會發生變更；另一方面，產品在開發過程中會經歷分析、設計、編碼等步驟，由于各個階段的相關開發人員的知識水平與關注點不同，對需求的理解也會產生偏差。
需求管理的目的是在用戶與實現用戶需求的項目之間達成一種共識并維護這種共識，它針對對這兩個問題提出了相應的目標。軟件的需求可能是系統需求的一部分(系統工程的一部分)或是全部(單純的軟件工程)。無論是哪種情況，需求管理的第一個目標就是軟件需求應能被控制，并可產生一個可用于軟件工程過程和管理過程的基線。需求管理的第二個目標是確保軟件項目計劃、開發活動、產品與軟件需求一致，保證最終的項目成果能夠滿足用戶的需求。
·軟件項目計劃（SPP）是整個項目過程的骨架，它支撐起整個項目的過程。但大部分軟件開發管理人員對它的重視程度還不夠。軟件項目計劃前提是要有一個合理的、有效的計劃，然后還必須有很強的能力去執行它。項目對于某些人來說，感覺就像是一個黑盒子，看不見摸不著，要對它做出一個合理有效的計劃確實不是一件容易的事。我們的同事經常是一接到項目，掐指算算，然后就對領導拍胸脯保證一個月內完成任務，但是由于對項目過程中的資源調配和風險預期不足，導致項目進度一拖再拖。
要做出合理的項目計劃，首先是估算，通過以往的項目經驗擬訂一個估算的標準，然后對項目的規模、資源要求和風險進行合理的估算。軟件計劃制定時要包括所有項目活動和所有參加方面的責任，這些活動和責任要文檔化，以保證有效地將計劃傳達給項目各個參加方。在項目計劃執行前，各個項目參加方要認同所承擔的項目責任，并且項目計劃的執行有行政職能的監督，這些認同和監督是項目計劃有效性的基本保證。
·軟件項目跟蹤與監控（SPTO）
CMM里的軟件項目跟蹤與監控KPA涉及到三個關鍵詞：可見性、檢查點、修訂計劃。通過在項目過程中設置檢查點來展現項目過程的可見性，發現不足，然后修訂計劃。
由于軟件項目過程是一個邏輯活動過程的組合，因此，它不具備一個物理過程那樣的可見性。軟件項目跟蹤與監控的目的就是為項目實際過程提供充分的可見性，以保證當項目執行偏離項目計劃時能采取有效的解決手段。 項目跟蹤是基于計劃的，對一個項目要設定適當的檢查點。在檢查點上要將執行結果、執行狀態和軟件項目計劃進行比較。若發現較大的差異，則采取適當的步驟進行調整。在必要的情況下，也需對計劃本身進行修改和維護。若在修改計劃時，改變了某些項目的責任，那么這些改變必須得到有關責任方的重新認同。
·子合同管理（SSM）
子合同管理對金融機構來將是比較重要的KPA，就像前面所說的，我們有一些較大的項目，比如一些外掛的子系統或者一些底層的平臺開發項目，我們是外包給軟件公司來做的。這樣做的好處一方面可以節省我們單位日常必須維持的人力物力，另一方面，也可以讓我們更好的專注于與金融業務相關的二次開發。這樣，也帶來了子合同管理的問題。子合同管理我們主要關注的有兩點，如何選擇軟件承包商與如何對承包出去的項目進行監控管理。我們通過衡量軟件企業的能力來選擇軟件承包商，當然還要考慮資金成本方面等因素，一般都是通過招標的方式來進行。對于承包出去的項目的監控管理，主要是還要靠交流，甲方和乙方通過不斷的互動交流，讓甲方對項目的進度有個整體的了解和把握。交流的方式有很多，有直接的咨詢，有規范化的文檔，有技術討論會議，還有項目周報等。
軟件質量保證是從項目流程管理上來保證軟件的質量。由于用于開發軟件系統或軟件產品的過程是決定項目成功與否的關鍵因素，因此軟件質量保證的工作是評審和審計軟件活動和軟件產品。評審和審計的依據是規定用于項目的步驟和相關標準。軟件質量保證活動不能是隨意的，必須經過充分的討論和協商。相關的組織和個人要了解質量保證的活動和質量保證活動的結果。為了解決質量保證組織與開發組織對某些項目開發活動或開發出的產品的評價所發生的爭議和分歧，企業要定義更高層次的管理組織，負責解決這些爭議和分歧。
·軟件配置管理（SCM）
軟件從需求分析開始到最后提交產品要經歷多個階段，每個階段的工作產品又會產生出不同的版本，如何在整個生存期內建立和維護產品的完整性是軟件配置管理的目的。CMM軟件配置管理關鍵過程域遵循了傳統軟件配置管理的概念，其基本工作內容是標識軟件配置項，建立產品基線庫，對配置項的修改加以系統的控制。
因為金融機構對軟件項目的質量要求要比一般的軟件項目高，在運行維護方面的要求也更規范更嚴格，所以，除了CMM2級的相關KPA，我們還需要增加CMM3級的組間協調、集成軟件管理、培訓大綱的KPA，以及CMM4級的軟件質量管理等KPA來完善我們的軟件過程。
在銀行的軟件開發部門應用CMM，能夠不斷的提高部門的開發效率，讓項目進度控制更嚴格，品質更有保證，管理更有序，但前提是要使用得當。它沒有一種固定的模式，也沒有確定的應用框架，更沒有明確指導我們要如何去實現，所以，我們科技部門需要結合自身的實際情況去裁剪，去探索出一套適用于銀行的軟件項目過程。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/