CMM在銀行軟體開發中的應用

CMM在銀行軟體開發中的應用

                                   ——馬希佳

CMM(軟體能力成熟度等級模型：Software Capability Maturity Model)，是由美國卡內基梅隆大學(CMU)的軟體工程研究所(SEI)制定的一種軟體評估標準，主要用於軟體開發過程和軟體開發能力的評估和改進。此標準自1991年提出以來，已在美國、印度、日本、歐洲等地成功應用，並成為軟體行業的工業標準。儘管CMM引起了軟體行業充分的重視，但如何將CMM應用到企業或專案管理中 ，大多數企業仍然毫無頭緒。而對於銀行的科技部門，屬於非軟體行業的軟體開發部門，是否可以通過應用CMM來最佳化項目開發過程，這是本文要探討的問題。

 

軟體能力描述了通過遵循軟體過程能夠實現預期結果的程度，就是軟體企業在一個項目時其項目過程曲線的“波動帶”，即項目圍繞專案計劃開發過程中的變化範圍。隨著成熟度等級層級的提高，在項目過程中關鍵點的目標結果與實際結果之間的差距越來越小、項目的可預見性將越來越高、項目過程中實際結果的變化範圍將越來越小。

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，就像前面所說的，我們有一些較大的項目，比如一些外掛的子系統或者一些底層的平台開發項目，我們是外包給軟體公司來做的。這樣做的好處一方面可以節省我們單位日常必須維持的人力物力，另一方面，也可以讓我們更好的專註於與金融業務相關的二次開發。這樣，也帶來了子合約管理的問題。子合約管理我們主要關注的有兩點，如何選擇軟體承包商與如何對承包出去的項目進行監控管理。我們通過衡量軟體企業的能力來選擇軟體承包商，當然還要考慮資金成本方面等因素，一般都是通過招標的方式來進行。對於承包出去的項目的監控管理，主要是還要靠交流，甲方和乙方通過不斷的互動交流，讓甲方對項目的進度有個整體的瞭解和把握。交流的方式有很多，有直接的諮詢，有正常化的文檔，有技術討論會議，還有項目周報等。

 

·軟體品質保證（SQA）

軟體品質保證是從項目流程管理上來保證軟體的品質。由於用於開發軟體系統或軟體產品的過程是決定項目成功與否的關鍵因素，因此軟體品質保證的工作是評審和審計軟體活動和軟體產品。評審和審計的依據是規定用於項目的步驟和相關標準。軟體品質保證活動不能是隨意的，必須經過充分的討論和協商。相關的組織和個人要瞭解品質保證的活動和品質保證活動的結果。為瞭解決品質保證組織與開發組織對某些項目開發活動或開發出的產品的評價所發生的爭議和分歧，企業要定義更高層次的管理組織，負責解決這些爭議和分歧。

 

·軟體組態管理（SCM）

軟體從需求分析開始到最後提交產品要經曆多個階段，每個階段的工作產品又會產生出不同的版本，如何在整個生存期內建立和維護產品的完整性是軟體組態管理的目的。CMM軟體組態管理關鍵過程域遵循了傳統軟體組態管理的概念，其基本工作內容是標識軟體配置項，建立產品基準庫，對配置項的修改加以系統的控制。

 

因為金融機構對軟體項目的品質要求要比一般的軟體項目高，在運行維護方面的要求也更規範更嚴格，所以，除了CMM2級的相關KPA，我們還需要增加CMM3級的組間協調、整合軟體管理、培訓大綱的KPA，以及CMM4級的軟體品質管理等KPA來完善我們的軟體過程。

 

在銀行的軟體開發部門應用CMM，能夠不斷的提高部門的開發效率，讓項目進度控制更嚴格，品質更有保證，管理更有序，但前提是要使用得當。它沒有一種固定的模式，也沒有確定的應用程式框架，更沒有明確指導我們要如何去實現，所以，我們科技部門需要結合自身的實際情況去裁剪，去探索出一套適用於銀行的軟體項目過程。