4.剪裁過程和原則
CMMI剪裁過程的目的不是重新編寫CMMI，而是根據小型軟件企業的特點對其文檔、實踐、評審、資源、培訓和管理等進行改造，同時保持CMMI的精粹和結構。由于各個軟件企業的具體改進方向不同，采用的改進策略不同，使用的模型不同(連續式或者階段式)，本文不逐個解釋如何剪裁KPA，這樣做不容易抓住主題，而且容易陷入細節中，我們討論剪裁文檔、管理、評審、資源、培訓等的普遍做法和原則。
4.1 文檔剪裁
CMMI過程模型包含大量文檔，包括策略、計劃、規程、標準和報告等，如果嚴格按照CMMI實踐來做，小型軟件企業的有限資源會被文檔所淹沒，而喪失對改進本質的掌握。我們采用的策略是合并或者擴充文檔，減少生成文檔的負擔，并借助于“小型軟件企業過程改進支持環境(SSE-PISE)”來實現文檔的快速生成、分發、合并和管理。主要剪裁策略包括：
l 文檔合并。 文檔合并是符合CMMI主旨的，CMMI也定義非形式化計劃作為形式化計劃的一部分。我們可以擴展之，項目級文檔可以是其他項目級文檔的一部分，組織級文檔可以是其他組織級文檔的一部分，前提是保證文檔的可識別性。
可以充分利用信息系統的訪問控制機制，實現文檔的更大程度合并，比如每個項目的項目級文檔只有一個，比如項目計劃，對于不同角色，只能看到相應的信息段，進行自己權限范圍內的輸入、修改、閱讀、轉發等操作。
對于相關性較強的文檔，尤其是某文檔是其他文檔的簡化版本，則完全取消前一個文檔，或者借助于信息化系統來實現自動生成。
l 文檔消除。 對于沒有涉及到的文檔，則完全刪除，不必提供，但是要在項目級文檔中解釋所采取的措施。對于信息冗余的文檔，則完全刪除;對于有價值信息量很少的文檔，則刪除本文檔，然后把有價值信息量合并到相關度最強的文檔中。
l 數據項抽取。 對于不同文檔中的公共信息，利用信息系統從公共數據源抽取，保證數據的正確性、一致性，同時減少重新輸入的工作量。
在本文討論的案例中，我們充分利用Lotus R5的多媒體文檔有關機制，組織級文檔只保留一個;每個項目只保留一個項目級文檔。對于配置管理(SCM)等KPA，基本上也限制在每個項目一個配置計劃文檔。當然，這個系統提供有關機制，能夠保證可以從同一個文檔衍生、打印輸出多個子文檔，分作不同場合使用。
4.2 管理剪裁
CMMI中任務分工非常細，涉及到的角色也非常多，但是對于小型軟件企業來說，根本沒有那么多人力資源來分工承擔這么多管理任務。比如CMMI中的高級經理在小型軟件企業中很可能就是公司總經理或者CEO，但是很多細節性任務他又不可能，也沒有時間自己來做。而且，在小型組織和小型項目中，很多角色實際上是重復的，比如在小型項目中，任務領導、軟件經理、項目軟件經理，以及項目經理的角色時重復的，沒有必要單獨設置。鑒于CMMI的管理結構與小型軟件企業存在較大差距，有必要對管理活動和管理角色進行剪裁。主要剪裁原則如下：
l 剖析KPA和管理任務，把相關的，不必要保證獨立性的KPA綜合起來，把相關管理職責分配給單個經理進行管理。
l 除非在絕對需要高級經理承諾的情況下，一般不設置高級經理這個管理職位。
l 合并管理任務，沒有必要重復設置經理職位，可以把相關職責交給有關技術人員或者管理人員來實施。
在本文討論的案例中，我們把KPA進行分類，保證“過程和產品質量管理”過程域的獨立性，其他KPA進行實施時都實施一人承擔多個職責，并把權利和職責合并和下放，每個項目只設立一個項目經理和一個SQA經理，項目經理負責項目的計劃、實施、部署和維護。KPA經理負責對項目實施進行監控，安排評審、獲取度量和分析數據，以及提出改進建議。
4.3評審剪裁
CMMI實踐中涉及很多類型的評審活動——管理評審、同行評審、SQA審計/驗證/評審、正式評審，以及技術評審，幾乎對所有項目相關的關鍵決策和關鍵文檔和活動都需要進行相應的評審，以建立公共基線。對于小型項目和企業而言，如果按照CMMI模型所有評審活動都實施的話，評審所花費的時間會嚴重影響開發時間，因此很有必要對評審活動進行剪裁。主要剪裁原則如下：
l 適當合并評審實踐。按照CMMI模型，高級管理層需要參與的評審太多，但是經理和具體實施者經常是在一個辦公室工作，溝通非常方便，很多評審活動可以簡化和合并，甚至取消。
實踐證明，評審頻率與項目是否關鍵，以及項目持續時間，關系非常密切。比如在非關鍵的和短期項目中，評審頻率應該不影響項目生命周期，相應的管理評審、軟件風險評審，以及SQA活動評審的頻率應該降低。
l 把評審實踐非正式化。充分利用其他會議或者碰頭機會解決評審需求。
l SQA評價、審計和評審沒有必要對所以產品都及時進行，應該只進行抽查。SQA評審被證明會嚴重增加小型項目的工作量。應該在SQA計劃中明確SQA抽查活動和工作產品。舉例說明可以抽查進行評審的活動或者工作產品：
(1)對KPA中活動和工作產品的SQA評審和審計;
(2)關于軟件基線的SCM審計;
(3)子承包商的SQA計劃和活動的評審;
(4)子承包商執行情況的評價。
大型項目和小型項目的一個主要區別是在狀態報告方面經理和員工之間工作關系不同。在小型項目中經理通常把主要精力放在技術層面上，因此在小型項目中實施大規模的狀態報告機制是不必要和不合適的。為了解決這個問題，需要剪裁和合并很多CMMI評審實踐，尤其與高層項目管理層和SQA聯合進行的項目跟蹤評審。在本文討論的案例中，我們只對關鍵工作產品和里程碑進行正式評審，其余評審進行合并，或者進行抽查評審，或者非正式化，降低評審工作量，充分利用小型項目的溝通便利、合作緊密的優勢。
4.4資源剪裁
CMMI模型規定很多執行管理和工程任務的角色，但是在小型組織和小型項目中根本沒有那么多人能夠全職執行CMMI要求的角色。實際情況是，工程師和管理人員可能同時執行多個角色，甚至跨越多個項目。比如，項目經理也許管理多個項目，也許同時從事管理和技術工作。SQA人員也許來自于其他項目，或者來自于其他組織和公司，SQA和SCM人員也許同時負責多個項目，并且個人也許參與到多個工程科目。同時，對于小項目而言，實現諸如SQA、SCM、培訓和SEPG的人員全職化也是不現實的。通常是，這樣的團隊經常包括多個兼職人員，以及一個全職人員。
在小型項目中，人員不是唯一受限的資源，每個KPA中“執行能力”部分提到的工具資源通常指的是自動化工具。在小型項目或者小型組織中，很多自動化工具不僅昂貴，而且不適合。對于不成熟的軟件過程，通常不能有效地使用大型CASE自動化工具。為了解決小型軟件組織和小型項目中有限資源問題，我們需要對CMMI進行剪裁，主要剪裁策略如下：
l 個人可以執行項目或者組織中的多個角色;承認兼職角色和職責;可以利用組織之外的資源。
l 擴展組(group)的概念，，使之可以包含兼職人員。
l 根據項目和過程成熟度需要選擇合適的自動化工具。在小型項目中，應該綜合使用基本的自動化工具和人力。
在本文討論的案例中，要求對資源進行分類，不僅按照人力資源、自動化工具等進行分類，而且進行進一步細化，比如人力資源根據專業方向、領導才能、溝通能力等進行分類，提出一個簡單的分類和評估方法;對CMMI的資源和組概念擴展，不再局限于部門的概念，使之能夠容納各種全職和兼職人員，而且沒有規模和其中職位的限制�；诓煌墒於鹊捻椖炕蛘呓M織，對不同KPA提出不同的建議工具，尤其是“小型軟件企業過程改進支持環境(SSE-PISE)”能夠對這些工具提供接口，促進自動化工具的使用效率。
文章來源于領測軟件測試網 http://www.k11sc111.com/
