小型软件企业实施CMMI过程改进案例

 

本文案例对象是一家小型软件组织A1，有员工12人，其中10人从事软件开发，2人从事管理、市场和销售等其他事务。A1细分为两个部门：生产部门和研发部门。这个组织属于典型的CMM级别1的组织，没有明显的过程支持，靠的是精英，没有质量控制和度量数据。按照CMMI模型提出一套简单可行的实施过程和模型，给出简单可行的操作步骤，大大减轻了企业的过程改进压力，充分利用兼职和全职资源，并同时提供“小型软件企业过程改进支持环境（SSE-PISE）”过程改进支持软件来支持其过程改进。

一. 剪裁过程和原则

CMMI剪裁过程的目的不是重新编写CMMI，而是根据小型软件企业的特点对其文档、实践、评审、资源、培训和管理等进行改造，同时保持CMMI的精粹和结构。由于各个软件企业的具体改进方向不同，采用的改进策略不同，使用的模型不同（连续式或者阶段式），本文不逐个解释如何剪裁KPA，这样做不容易抓住主题，而且容易陷入细节中，我们讨论剪裁文档、管理、评审、资源、培训等的普遍做法和原则。

1. 文档剪裁

CMMI过程模型包含大量文档，包括策略、计划、规程、标准和报告等，如果严格按照CMMI实践来做，小型软件企业的有限资源会被文档所淹没，而丧失对改进本质的掌握。我们采用的策略是合并或者扩充文档，减少生成文档的负担，并借助于“小型软件企业过程改进支持环境（SSE-PISE）”来实现文档的快速生成、分发、合并和管理。主要剪裁策略包括：

文档合并。 文档合并是符合CMMI主旨的，CMMI也定义非形式化计划作为形式化计划的一部分。我们可以扩展之，项目级文档可以是其他项目级文档的一部分，组织级文档可以是其他组织级文档的一部分，前提是保证文档的可识别性。

可以充分利用信息系统的访问控制机制，实现文档的更大程度合并，比如每个项目的项目级文档只有一个，比如项目计划，对于不同角色，只能看到相应的信息段，进行自己权限范围内的输入、修改、阅读、转发等操作。

对于相关性较强的文档，尤其是某文档是其他文档的简化版本，则完全取消前一个文档，或者借助于信息化系统来实现自动生成。

文档消除。 对于没有涉及到的文档，则完全删除，不必提供，但是要在项目级文档中解释所采取的措施。对于信息冗余的文档，则完全删除；对于有价值信息量很少的文档，则删除本文档，然后把有价值信息量合并到相关度最强的文档中。

数据项抽取。 对于不同文档中的公共信息，利用信息系统从公共数据源抽取，保证数据的正确性、一致性，同时减少重新输入的工作量。

在本文讨论的案例中，我们充分利用Lotus R5的多媒体文档有关机制，组织级文档只保留一个；每个项目只保留一个项目级文档。对于配置管理（SCM）等KPA，基本上也限制在每个项目一个配置计划文档。当然，这个系统提供有关机制，能够保证可以从同一个文档衍生、打印输出多个子牡担肿鞑煌『鲜褂谩?/p>

2. 管理剪裁

CMMI中任务分工非常细，涉及到的角色也非常多，但是对于小型软件企业来说，根本没有那么多人力资源来分工承担这么多管理任务。比如CMMI中的高级经理在小型软件企业中很可能就是公司总经理或者CEO，但是很多细节性任务他又不可能，也没有时间自己来做。而且，在小型组织和小型项目中，很多角色实际上是重复的，比如在小型项目中，任务领导、软件经理、项目软件经理，以及项目经理的角色时重复的，没有必要单独设置。鉴于CMMI的管理结构与小型软件企业存在较大差距，有必要对管理活动和管理角色进行剪裁。主要剪裁原则如下：

剖析KPA和管理任务，把相关的，不必要保证独立性的KPA综合起来，把相关管理职责分配给单个经理进行管理。

除非在绝对需要高级经理承诺的情况下，一般不设置高级经理这个管理职位。

合并管理任务，没有必要重复设置经理职位，可以把相关职责交给有关技术人员或者管理人员来实施。

在本文讨论的案例中，我们把KPA进行分类，保证“过程和产品质量管理”过程域的独立性，其他KPA进行实施时都实施一人承担多个职责，并把权利和职责合并和下放，每个项目只设立一个项目经理和一个SQA经理，项目经理负责项目的计划、实施、部署和维护。KPA经理负责对项目实施进行监控，安排评审、获取度量和分析数据，以及提出改进建议。

3. 评审剪裁

CMMI实践中涉及很多类型的评审活动——管理评审、同行评审、SQA审计/验证/评审、正式评审，以及技术评审，几乎对所有项目相关的关键决策和关键文档和活动都需要进行相应的评审，以建立公共基线。对于小型项目和企业而言，如果按照CMMI模型所有评审活动都实施的话，评审所花费的时间会严重影响开发时间，因此很有必要对评审活动进行剪裁。主要剪裁原则如下：

适当合并评笫导０凑誄MMI模型，高级管理层需要参与的评审太多，但是经理和具体实施者经常是在一个办公室工作，沟通非常方便，很多评审活动可以简化和合并，甚至取消。

实践证明，评审频率与项目是否关键，以及项目持续时间，关系非常密切。比如在非关键的和短期项目中，评审频率应该不影响项目生命周期，相应的管理评审、软件风险评审，以及SQA活动评审的频率应该降低。

把评审实践非正式化。充分利用其他会议或者碰头机会解决评审需求。

SQA评价、审计和评审没有必要对所以产品都及时进行，应该只进行抽查。SQA评审被证明会严重增加小型项目的工作量。应该在SQA计划中明确SQA抽查活动和工作产品。举例说明可以抽查进行评审的活动或者工作产品：

（1）对KPA中活动和工作产品的SQA评审和审计；

（2）关于软件基线的SCM审计；

（3）子承包商的SQA计划和活动的评审；

（4）子承包商执行情况的评价。

大型项目和小型项目的一个主要区别是在状态报告方面经理和员工之间工作关系不同。在小型项目中经理通常把主要精力放在技术层面上，因此在小型项目中实施大规模的状态报告机制是不必要和不合适的。为了解决这个问题，需要剪裁和合并很多CMMI评审实践，尤其与高层项目管理层和SQA联合进行的项目跟踪评审。在本文讨论的案例中，我们只对关键工作产品和里程碑进行正式评审，其余评审进行合并，或者进行抽查评审，或者非正式化，降低评审工作量，充分利用小型项目的沟通便利、合作紧密的优势。

4. 资源剪裁

CMMI模型规定很多执行管理和工程任务的角色，但是在小型组织和小型项目中根本没有那么多人能够全职执行CMMI要求的角色。实际情况是，工程师和管理人员可能同时执行多个角色，甚至跨越多个项目。比如，项目经理也许管理多个项目，也许同时从事管理和技术工作。SQA人员也许来自于其他项目，或者来自于其他组织和公司，SQA和SCM人员也许同时负责多个项目，并且个人也许参与到多个工程科目。同时，对于小项目而言，实现诸如SQA、SCM、培训和SEPG的人员全职化也是不现实的。通常是，这样的团队经常包括多个兼职人员，以及一个全职人员

在小型项目中，人员不是唯一受限的资源，每个KPA中“执行能力”部分提到的工具资源通常指的是自动化工具。在小型项目或者小型组织中，很多自动化工具不仅昂贵，而且不适合。对于不成熟的软件过程，通常不能有效地使用大型CASE自动化工具。为了解决小型软件组织和小型项目中有限资源问题，我们需要对CMMI进行剪裁，主要剪裁策略如下

个人可以执行项目或者组织中的多个角色；承认兼职角色和职责；可以利用组织之外的资源。

扩展组（group）的概念，，使之可以包含兼职人员。

根据项目和过程成熟度需要选择合适的自动化工具。在小型项目中，应该综合使用基本的自动化工具和人力。

在本文讨论的案例中，要求对资源进行分类，不仅按照人力资源、自动化工具等进行分类，而且进行进一步细化，比如人力资源根据专业方向、领导才能、沟通能力等进行分类，提出一个简单的分类和评估方法；对CMMI的资源和组概念扩展，不再局限于部门的概念，使之能够容纳各种全职和兼职人员，而且没有规模和其中职位的限制。基于不同成熟度的项目或者组织，对不同KPA提出不同的建议工具，尤其是“小型软件企业过程改进支持环境（SSE-PISE）”能够对这些工具提供接口，促进自动化工具的使用效率。

5. 培训剪裁

CMMI模型KPA的“执行能力”公共特性包含很多不同类型的培训需求，包括管理和技术方面的。由于培训是非常耗费资源和资金的事情，小型组织通常雇用已经被培训或者具备相关知识的人才。CMMI的培训程序KPA允许放弃培训，但是大多数企业没有认识到这个问题，仍旧坚持认为对所有员工进行培训是必不可少的。必须对CMMI进行剪裁以澄清这种误解。主要剪裁原则如下：

已经具备相应实践经验或者类似领域培训历史的员工可以免除培训。

培训可以当作以前培训的扩展，并且可以合并相关活动的培训。

可以扩展培训实践，消除不必要的内部培训，接收来自于外部资源或者方法的培训。

在我们讨论的案例中，我们对相关培训记录和人力资源培训技能和培训历史非常重视，并基于此来决定是否使用培训免除机制。如果使用这种机制，必须保证有当事人的签名。我们剪裁多个培训实践以合并或者扩充培训需求。比如，同行评审领导者培训可以与同行评审者培训合并。有些高等级成熟度KPA的活动是低等级成熟度活动的扩展，因此支持高等级成熟度活动的培训是支持低等级成熟度活动的培训的扩展，比如集成化软件管理KPA的项目管理培训。

6. 剪裁无关实践

CMMI是面向于大型软件企业的，其中很多实践是与小型企业不相关的，尤其很多过程实践不适合于小型项目，小型项目实施这些过程实践会花费比项目本身更多成本，并且由于部分项目的短时效性使得重新计划或者调整活动变得没有实际意义。

在组织过程焦点、组织过程定义、集成化软件管理，以及定量过程管理等KPA中，很多过程实践涉及到创建和维护项目已定义过程。但是在只有一个项目的组织中，项目过程和组织过程是完全相同的。如果组织的项目具备类似的特性（比如领域知识、规模和开发循环等），则所有小项目可能使用一个过程。并且这个过程是小型项目的组织标准过程。无论何种情况，那些剪裁组织标准软件过程作为项目已定义过程，以及集成项目已定义过程的变更到组织标准过程的实践都不适合。同时，对于那些开发时间很短的项目，则根本没有时间来实施项目重新计划、风险计划，以及过程调整等活动，那么这些实践对于这种项目来说也是没有用处的。

二. 总结

中国的软件企业80%都是小型企业，人员规模在15人以下[10]，而CMMI是面向于大型软件企业的过程改进模型，怎样使得小型企业和项目能够充分利用CMMI模型的过程改进优势，并获得相关CMMI认证呢？作者参与一个只有12名员工的小型企业软件过程改进项目，本文正是基于该项目总结而得的。

本文首先从企业组织结构、软件过程改进模型、小型组织面对的市场需求等三个方面剖析小型软件企业的过程改进面临与大型企业不同的需求。然后分析为什么CMMI的有关内容不适合于小型企业和项目的实际情况，并概括介绍如何在文档、管理、评审、资源和培训等方面进行剪裁和改进，使之适合于小型企业和项目的实际情况。

参考http://www.uml.org.cn/cmm/200809023.asp