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的资源和组概念扩展，不再局限于部门的概念，使之能够容纳各种全职和兼职人员，而且没有规模和其中职位的限制。基于不同成熟度的项目或者组织，对不同KPA提出不同的建议工具，尤其是“小型软件企业过程改进支持环境(SSE-PISE)”能够对这些工具提供接口，促进自动化工具的使用效率。
文章来源于领测软件测试网 https://www.ltesting.net/
