本文中所描述的对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的每个关键实践中所引用的各种各样的“活动角色”。“活动角色”可以定义为成功执行某项活动所需要的明确的或暗含的人员。一般来讲，活动角色包括：
提供商——负责为活动提供需求或者其他一些必须的输入的个人或小组
代理——负责执行活动中主要元件的个人或小组
客户——接受活动输出的个人或小组
检验人员——负责保证输出的质量令人满意以及执行活动的过程被正确实施的个人或小组
评论人员——负责评论和/或批准输出的个人或小组。（评论人员一般参照指定的标准和条件进行评定）
应该注意的是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。
文章来源于领测软件测试网 https://www.ltesting.net/
