本文中所描述的對SW-CMM的剪裁主要側重于系統地檢查每個KPA中的三個過程元素，來決定所需要的活動，從而保證組織形成相應的OSSP。KPA中的過程元素描述為在過程表述中能夠滿足過程定義標準的那一部分。過程定義標準就是必須包含在軟件過程表述中并且對人們執行該過程有幫助的信息集合。過程定義標準一般表達為問句形式（由誰完成，做什么，什么時候做，為什么等等）。因此過程元素應該包括目的、輸入、輸出、角色、活動、進入和退出標準、以及其他一些部分。下面我們詳細討論圍繞過程元素所制定的對SW-CMM的剪裁方法。
KPA中的過程元素有很多，下面列出的是一些最重要的過程元素：
角色：描述參與過程活動的個人或者團體。他們可以是提供商、客戶、代理人、評論員或者實踐的檢驗員等。
輸出/工作產品：描述過程中所產生的產品，也就是說，產品是執行過程步驟所產生的結果。軟件模塊，經測試的代碼，會議記錄以及SQA報告等都是工作產品的例子。只有在過程被執行后工作產品才會存在。
退出標準：描述活動可以宣告完成的條件。退出標準可以是對工作產品、角色或活動狀態的簡單或復雜判斷�！败浖枨笠呀浗涍^了軟件管理員和其他有效小組的評定”就是一個退出標準的例子。
本文中所描述的剪裁方法是依次使用輸出、活動和角色這三個過程元素。下面的部分將討論對這三個過程元素分別進行分析和剪裁的技術。
一、輸出映射
剪裁一般都是從檢查每個KPA的輸出做起。這些輸出對于滿足每個KPA的目標是必需的——如果組織不能夠產生這種輸出，那就很難表明該KPA的目標已經被實現。我們可以使用核對表用來鑒定每個KPA所建議的輸出。表1就是一個輸出核對表。該表有一個標志欄（最左邊一欄），如果產生了某項輸出，就可以輸入組織中描述該輸出的術語，以及對OSSP所指定輸出的引用。
表1：輸出核對表（以需求管理過程域為例）
|
√ |
輸出 |
組織中的輸出 |
引用 |
|
已分配的需求（L2-5，A1） |
|||
|
由于改動分配需求而產生的對軟件計劃、工作產品以及活動的改變（L2-8，A3，2） |
|||
|
對已分配需求的改動（L2-7,A3） |
|||
|
對組織外部的個人或團體所做承諾的改動（L2-7,A3,1.1） |
|||
|
對組織內部承諾的改動（L2-7,A3,1.2） |
|||
|
根據已分配需求所做承諾（L2-6,A1,4） |
|||
|
對現有承諾的影響（L2-7,A3,1） |
|||
|
度量（L2-8,M1） |
|||
|
軟件活動（L2-10,V3,2） |
|||
|
軟件計劃（L2-10,V3,2） |
|||
|
軟件需求（L2-7,A2,3） |
|||
|
軟件工作產品（L2-10,V3,2） |
由于組織或許并不能精確提供SW-CMM中所提及的文檔集合，因此，將SW-CMM所涉及到的文檔的內容映射為組織中的文檔是非常有用的。第一步是考慮這樣一個問題：我們的組織是否產生這一輸出？如果產生，那么組織的文檔中是否包括了SW-CMM中所指定或推薦的所有內容？為了表示覆蓋程度，不能僅僅使用一個簡單的復選標記（√），還可以使用一些代碼進行描述，例如可以使用如下的代碼：
C——完全覆蓋
S——共享覆蓋，也就是說所有的條款都得到了滿足，但是涉及到了多個文檔。這時需要在“組織輸出”一欄中指明不同文檔的名稱。
P——部分覆蓋，即SW-CMM中推薦的某些條款沒有包含在當前的組織文檔中。
空白輸入（表示沒有相應的組織文檔）或標記為“P”的輸入表示組織應該對SW-CMM中所指定的該文檔加以特別的注意。該文檔對組織來說可能是不必要或不適用，然而，這也可能意味著組織的文檔集合缺少了某些有用的內容。
二、活動映射
檢查KPA中的每個活動，決定該實踐對組織的適用性。這一分析應該仔細執行，并且要牢記許多活動都是與其他活動密切相關的，因此對一個活動所做的決定可能會影響到對其他活動所做的決定。在做出這些決定時需要綜合考慮的因素組織的結構，客戶和終端用戶關系，剪裁程度屬性，商業目標和當前/將來的成熟度等級。
對每一個活動記錄下組織的接受程度代碼（接受，擴展，剪裁，可選，不推薦）。這些代碼在表3中有詳細描述。注意：這時檢查的結果也可以用在將來的剪裁活動中，因此，在檢查中包含對做出某個決定的原因的描述是很有用的，尤其是當一個實踐被斷定為不必要或不推薦時。
表2：活動核對表（以組織過程焦點過程域為例）
|
√ |
活動 |
引用 |
|
軟件過程被定期評估，并且開發了活動計劃用來表示評估發現（L3-6,A1） |
||
|
組織開發和維護其軟件過程開發和改進活動計劃（L3-7,A2） |
||
|
|
||
|
組織軟件過程數據庫的使用在組織級被協調（L3-8,A4） |
||
|
新的過程，方法和工具在組織中的有限使用被監控和評估，并且在適當的地方轉讓給組織的其它部分（L3-8,A5）。 |
||
|
對于組織和項目軟件過程的培訓在整個組織中被協調（L3-8,A6 |
||
|
執行軟件過程的小組知道軟件過程開發和改進的組織和項目活動。（L3-9,A7） |
|
代碼 |
描述 |
|
A |
接受��必須的和受歡迎的實踐。 |
|
E |
擴展��必須的和受歡迎的實踐，但是在使用時需要另外進行本地定義。不同的使用環境可能要求不同的定義。每一個獨立的定義集都被標以不同的下標，使用相同定義的環境也要使用相同的下標。（擴展的一個例子是為評論對已分配需求的改動而使用本地的文檔程序，這就是一個擴展的例子，因為SW-CMM（需求管理，活動3）中指明了需要進行評論，但是并沒有指明應該使用的文檔化程序） |
|
T |
剪裁��必須的和受歡迎的實踐，但是在使用時需要加以調整。這里的調整不僅僅是指本地化定義。不同的使用環境需要進行不同的調整。每一個獨立的調整集都應該使用起自己的下標來標記。使用相同調整的環境也應該使用相同的下標。（調整的一個例子就是對于軟件開發的所有階段/方面都應該有一個需要使用本地化程序的組織政策，用來代替需求管理，項目計劃等的詳細政策。這就是剪裁，因為每個政策的詳細內容沒有提及，但是為組織設定政策的目的已經達到。） |
|
O |
可選��實踐對環境中的某些項目有用，但不是對所有的項目都有用。 |
|
NR |
不推薦��實踐在該環境不推薦使用。 |
這里的分析應該集中在活動是否被執行，而不是由誰來執行或者輸出在哪里列出。輸出已經在前面被映射，而角色將在下面的部分中討論。這里的分析應該涉及到活動在OSSP中的什么地方被提及。 分析還可以擴展到SW-CMM中的其他關鍵實踐，而不僅僅是活動。如有必要，可以使用評審和審計、培訓、工具以及度量等方面的核對表。這些都可以通過使用上面表3所列的代碼來表示。
如果不使用核對表，組織也可以直接使用SW-CMM本身。在這種方法中，組織必須不厭其煩地檢查每一個關鍵實踐，包括所有其他的通用特征——執行承諾，執行能力，測試和分析，驗證執行，而不僅僅是活動。對每一個實踐的分析都被記錄下來。這種方法雖然詳盡徹底，但是需要耗費大量的時間和精力才能夠完成。
三、角色映射
我們知道，許多不同類型的組織都需要進行軟件開發和維護。并且，在使用相同組織原則的各個小組中，可以有不同的原則使用方式�？紤]到組織結構的多樣性，有必要提供一種方法用來識別出組織結構的特定屬性，以便于在對實踐進行剪裁時使用。因此，列出現有軟件角色的性質和相互關系是一個比較合理的方法。
當一個組織的結構與SW-CMM所假定的組織結構有明顯不同時，下面的技術可以用來識別出需要進行剪裁的實踐。
1、角色轉換
這一技術用來識別組織中的哪個或者哪些角色負責執行KPA中的每個關鍵實踐所涉及的角色功能。所獲取的信息可以用來調整關鍵實踐定義，使其適應軟件開發角色所表示的組織結構。并且也可以用來識別任何現存的可以由未來的過程改進活動所表示的“過程角色”。
表4所示的角色轉換表可以用來記錄組織中的哪個角色負責執行SW-CMM中的角色功能。角色轉換表中有一列是SW-CMM的角色/小組，另一列是組織中的角色/小組。其目的是為了標示出小組中對組織有意義的每一個角色。如果某個特定的角色沒有被包含在其中，可以檢查一下該角色的定義和每一個角色參與的活動。這些活動包含在KPA描述中。SW-CMM角色也可以由多個組織角色共享其功能。
表4：角色轉換表
|
SW-CMM角色/小組 |
組織中的角色/小組 |
|
行政人員 |
|
|
受影響的小組 |
|
|
受影響的個人 |
|
|
受影響的管理者 |
|
|
客戶 |
|
|
客戶SQA人員 |
|
|
文件專家 |
|
|
終端用戶 |
|
|
工程組 |
|
|
對定義和分析軟件過程有專門技術和經驗的人員 |
|
|
獨立于SQA小組的專家 |
|
|
首席軟件經理 |
|
|
負責分析和分配系統需求的小組 |
|
|
負責協調組織軟件過程活動（例如SEPG）的小組 |
|
|
負責協調組織的定量過程管理活動的小組 |
|
|
負責提供關鍵從屬項的小組 |
|
|
負責系統和接受測試的小組 |
|
|
負責組織的技術改進管理活動的小組 |
|
|
組織的軟件過程活動小組 |
|
|
系統需求小組 |
|
|
定義和維護受影響的過程描述 |
2、角色核對表 一旦SW-CMM角色被轉換成組織中的相應角色，就可以執行核對表功能，來檢查每個角色所參與的活動是否都已經被覆蓋到。每一個KPA可以有一個角色核對表，用來列出其中的角色以及這些角色所參與的活動。核對表中有一個標記欄，如果角色執行了特定的活動，就可以在該欄中標記一個復選標志（√），此外還有一個引用欄，用來標記OSSP在什么地方引用了該活動。
此處的目的是決定如何將SW-CMM的角色/活動轉換到組織結構中。下面闡明了角色核對表中推薦使用的各種操作。
如果活動是由角色轉換表中指定的組織角色來執行，可以為該活動標記一個復選標志。
如果活動是由另一個組織角色來執行，或者由多個角色共享執行，可以在引用欄里注明組織角色的名稱，以及OSSP引用。
如果活動被修改，或者根本不執行，則可以使用活動注釋代碼（參見表3）來表明該活動是否適合于組織。
表5：角色核對表（培訓計劃）的例子
|
√ |
角色 |
參與的活動 |
引用 |
|
受影響的小組 |
對于受影響的小組和個人，組織的培訓計劃是可用的（L3-31,A2,6） |
||
|
受影響的個人 |
組織的培訓計劃在首次發布以及形成主要版本時，由受影響的個人進行檢查（L3-31,A2,4）。 對于受影響的小組和個人，組織的培訓計劃是可用的（L3-31,A2,6） |
||
|
經理 |
有一個專門的經理負責執行組織的培訓計劃（L3-28,Ab2,6） |
||
|
高級管理 |
培訓計劃由高級管理人員周期性地進行檢查（L3-35,V1）。 |
||
|
軟件經理 |
軟件經理負責接受對培訓計劃的修改（L3-29,Ab4）。 |
||
|
培訓小組 |
培訓小組成員具備執行培訓活動所必需的技能和知識（L3-28,Ab3）。 |
對于面向多用戶環境（而不是只針對一個外部客戶）開發軟件的組織來說，需要特別注意對客戶和終端用戶所指定的活動。盡管有些活動可能是不適應的，但有些活動可以由軟件組織以外的角色來執行，而不是在公司內部執行（例如市場營銷）。 對于上面兩種技術（角色轉換和角色核對表）的替代做法是活動角色技術。這一技術用來識別組織中的哪個或哪些角色負責執行KPA的每個關鍵實踐中所引用的各種各樣的“活動角色”�！盎顒咏巧笨梢远x為成功執行某項活動所需要的明確的或暗含的人員。一般來講，活動角色包括：
提供商——負責為活動提供需求或者其他一些必須的輸入的個人或小組
代理——負責執行活動中主要元件的個人或小組
客戶——接受活動輸出的個人或小組
檢驗人員——負責保證輸出的質量令人滿意以及執行活動的過程被正確實施的個人或小組
評論人員——負責評論和/或批準輸出的個人或小組。（評論人員一般參照指定的標準和條件進行評定）
應該注意的是SW-CMM并不會為每一個活動都明確定義所有的這些角色。因此，執行這一分析是比較復雜的，因為SW-CMM不會為每一個角色明確指明對應于哪一個小組。不過，為了保證組織能夠成功執行某項活動，對所有這些角色的明確定義是非常有用處的。這一部分的意義在于，可以幫助調整關鍵實踐的定義，使之能夠適應由組織中的軟件開發角色所表示的組織結構。并且，還可以幫助識別出組織中存在的“過程漏洞”，并在以后的過程改進活動中進行加強。
表6所示的矩陣可以用來記錄組織中的每個角色分別對應于哪一個關鍵實踐。矩陣為每個活動都附加了一欄，用來表明該關鍵實踐是否適合于該組織。KPA中的每個關鍵實踐對應矩陣中的一行。
表6：SW-CMM關鍵實踐和活動角色示例矩陣
|
SW-CMM關鍵實踐 |
活動角色 | |||||
|
提供商 |
代理 |
客戶 |
檢驗人員 |
評論人員 |
N/A | |
|
CO1 |
X | |||||
|
CO2 |
O |
SEPG |
SEPG |
N/A |
SEPG |
|
|
AB1 |
-- |
SEPG |
SW |
SQA |
SEPG |
|
|
AB2 |
||||||
矩陣中行列交界處的每一個單元格中都包含了負責執行關鍵實踐中活動角色的組織角色。除了組織角色之外，還使用了如下所示的特殊單元格代碼： --：活動角色沒有在關鍵實踐中被引用
O：活動角色不被執行或者在組織中沒有定義
N/A：活動角色對組織不適用
X（在N/A欄）：實踐對組織不適用
表6中的例子可以解釋如下（左邊的欄代表關鍵實踐行）：
CO1：該實踐不適用于組織。（在N/A欄中標記為X）
CO2：對該實踐來說，組織沒有明確定義的對特定輸入的責任。（在提供商一欄標記為O）
軟件工程過程組（SEPG）負責執行所需任務，充當客戶以及評定工作產品。（在代理人，客戶和評論人員欄中分別標記為SEPG）
SQA負責評價過程和標準。（在檢驗人員欄中標記為SQA）
AB1：對該活動來說沒有特定的輸入。（在提供商一欄標記為--）
SEPG負責執行所需活動，并評定工作產品。（在代理人和評論人員欄中分別標記為SEPG）
軟件開發者是客戶。（在客戶一欄標記為SW）
SQA負責評定過程和標準（在評論人員欄標記為SQA）
對于面向多用戶環境（而不是只面對一個單一的外部客戶）開發軟件的組織來說，有關客戶和終端用戶角色的一些活動需要特別注意。盡管有些活動不適用，但仍有一些活動可以由軟件組織外部和公司內部的角色來執行（例如市場營銷）。
KPA中所描述的過程元素中，最重要的就是過程的輸出、活動和角色。對于過程元素的其他方面，也可以使用類似的技術對SW-CMM的要求進行剪裁，不存在其他的技術難題，并且工作量也不如以上三方面大，本文中不再一一論述。
使用上面所描述的剪裁技術所得出的要求范圍非常接近于原始SW-CMM實踐的要求。如果組織中包含一個或多個與SW-CMM中所描述的典型環境顯著不同的使用環境，那么在組織中就有可能還存在沒有被描述的過程需求。例如，如果組織的結構不同于SW-CMM中的術語所描述的結構，那么對角色界面的某些需求可能就會因為不適用而被刪除。這樣做是合理的，但是，同樣必須要做的還有檢查一下組織中獨特的角色界面，以保證找出任何附加的過程需求。
當組織中有顯著不同的項目環境時，每一種項目環境的需求都應該被描述。由于維持在組織間過程的通用性同樣也是非常需要的，因此對所有這些環境的過程需求的分析應該統一進行。有多個項目環境的組織可以通過將組織看成一個整體，或者通過將每個項目環境看成一個獨立的組織來逐項檢查SW-CMM實踐。前一種方法比較復雜，但是具有潛在的長期效益。例如，在考慮組織整體的同時，可以加強一些通用的過程元件，并且將一些最佳實踐在整個組織中進行轉換和推廣。另一方面，將每個項目環境看成一個獨立的組織比較簡單，但這種方法通常會強調過程之間的差別，并且在維護和執行過程改進時更加困難一些。
由于我們這里的目的就是要創建與SW-CMM一致的OSSP，因此所使用的剪裁方法應該取決于組織是想創建（或者需要創建）一個統一的OSSP，還是為每一種應用環境都創建一個OSSP。一般來說，每一種組織都需要有一個統一的方法，而不希望維護多個“特殊定制”的OSSP。
對于只有一個OSSP的組織來說，當一個或多個實踐需要根據不同的應用環境進行剪裁的時候，一套可接受的替代實踐的需求應該被列出并文檔化。這些需求不必將每一個特殊應用環境都關聯到一條相應的剪裁需求，而只需要列出覆蓋相關的環境需要所必需的能力范圍就可以了。對于特定環境中替代實踐的選擇在開發OSSP和相關的剪裁手冊時將會被描述。
對于創建多個OSSP的組織來說，每一種應用環境都有其自己的表集合。也就是說，上面部分中執行和列出的分析步驟需要在每一種應用環境中重復。這些表集合可以作為OSSP對每一種應用環境進行需求分析的基礎。經驗表明，建立一個唯一的OSSP是一種標準做法，但是每一個組織都應該根據自身需要來決定其結構。對于每一種應用環境的分析也可以進行比較，用來比較交迭的程度，從而決定是創建一個OSSP還是創建多個OSSP。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
