小型软件企业实施CMMI过程改进研究和分析

刘洪鹏

摘要: 首先介绍小型软件企业进行过程改进所面临的困难，解释为什么小型企业和项目实施CMMI时会遇到很多阻力，然后基于作者参与的一个典型组织CMMI改进进程，分析为什么CMMI有关内容不适合于小型企业和项目的实际情况，并概括如何在文档、管理、评审、资源和培训等方面进行剪裁和改进，使之适合于小型企业和项目的实际需求。
　　关键字: 软件过程；过程改进模型；CMMI；剪裁
1．引言
　　在过去十年中，高质量软件生产变得越加复杂和难以管理，其中部分原因是生产软件的技术和方法快速变革，要开发的应用程序愈加复杂。这两个因素是密切相关：技术的快速发展促使新产品、服务和活动不断产生，不断替换旧产品，而此也对技术产生新的需求。其次，软件过程是面向人的[2]，人之间，以及人与工具之间具有高度可变性和不可预测性。这个事实进一步增加软件过程的复杂性，对管理提出更高要求。最后，软件过程也许持续很长一段时间，在其生命周内也许会出现很多新需求，经历许多变更[3]，这类变更涉及到开发技术改变、开发策略和规程更新。软件过程改进的其他重要原因包括动态调整软件过程以适应项目参与人的需求和偏好，或者处理不可以预测的情况。

　　现在业界最成熟的过程评估和改进方法是美国卡内基-梅隆大学的软件工程研究所（SEI）提出的过程能力成熟度模型。这些模型描述了有效的过程单元的框架，为组织描述了从混乱的、不成熟的过程向成熟的、有纪律的过程改进的一条途径。自从1991年SEI发布SW-CMM（V1.0）以来，SEI逐渐开发了多种CMM模型，其中最有影响的包括：系统工程（SE-CMM）、软件工程(SW-CMM)、软件采办(SA-CMM)、人力资源管理(P-CMM)，以及集成的化产品和过程开发(IPPD-CMM)等。虽然这些模型对许多组织是有用的，有助于改善组织过程，以构造更好的产品，提高质量，降低成本。但是多种模型的共存逐渐显露出弊端。

　　于是出现了能力成熟度模型集成（Capability Maturity Model Integration ，CMMI）。集成的目的是通过以下手段降低基于多学科模型的过程改进成本：消除不一致性；减少重复；增加透明度和可理解性；提供公共术语；提供一致的风格；建立统一的构造规则；维护公共构件；确保与ISO 15504保存一致；实现尽量好的可继承性。SEI计划逐步用CMMI取代现行的包括SW-CMM和SA-CMM在内的多个现行的成熟度模型 [11][12]。
1．1小型企业实施过程改进遇到的困难
　　实施CMM和ISO 9001的经验表明：在人员只有15人，甚至更少的小型软件企业中，应用这些模型时会遇到很多困难。即使对于大型软件企业来言，其中的小部门和小项目在单独应用这些模型时也会遇到这种问题，需要对这些模型进行调整，以适应小型企业、小部门和小项目（SB/SO/SP）的资源、结构和实践。SB/SO/SP环境下遇到的问题可以分成三大类[1]：
（1）与软件企业组织结构相关的问题
　　小型软件组织的组织结构是实施过程改进的最大困难，通常这种企业没有正式定义角色、职责和过程。做法经常是每日都变化，没有长期计划，这种结构使得软件企业很难生成高质量大规模软件，或者及时满足不断变化的用户需求。总结如下：
　　l 缺乏负责质量的专门人员。在小型企业中，通常没有人具备软件过程改进的经验和相关培训，即使知道基本概念和技术，但是对底层原理缺乏正确认识，无法解释本组织的质量模型需求。
　　人员有限。在小型软件企业中，难以形成专职的过程改进团队。
　　资金有限。小型软件企业通常资金有限，很容易受到市场的影响。
　　当前过程的状态。小型软件企业通常只处于CMM等级1的水平。经验表明等级1的公司需要花费4或者6年的水平才能达到CMM 3级的水平。对于大多数小型企业而言，这么长时间难以忍受。
　　非软件过程的问题。在小型软件企业中，对于那些与软件开发不直接相关的组织过程，通常缺乏所必需的成熟度。这个问题进一步加剧解决软件开发相关问题的难度。
　　黑客文化。小型软件企业通常具有黑客文化，严重依赖于少数高水平的程序员。
　　缺乏定量数据。小型软件企业通常没有收集数据以度量过程和执行情况，这与它们缺乏定义明确的过程和固有开发模式紧密相关。
（2）与软件过程改进模型相关的问题
　　诸如CMM和ISO 9001之类被广泛应用的软件过程改进模型有很多不适合小型软件企业的固有问题，总结如下：
　　缺乏指导。质量模型，尤其是ISO 9001，解释了应该具备的质量系统基本元素，但是没有提供何处启动和如何启动这些属性的指南。CMM稍强一点，定义了关键过程域，然而对于小型企业而言，没有那么多资源来实现这么多关键过程域，而且没有关于如何实施的详细指南。如果操作顺序不符合规范，则所有努力有可能付之东流。
　　缺乏行动知识。缺乏软件过程改进专门知识的小型软件企业需要如何在企业内部应用质量模型需求的详细步骤说明。
　　没有从小型企业角度考虑。已有的软件过程改进模型没有考虑到小型软件企业的特点，那就是灵活、快速反应和沟通能力。
　　假设具备多种领域的专门知识。当前过程改进模型隐含地假设软件组织具备形成能够在不同过程域中并行实施的资源，而小型企业没有那么多人力资源来组建这么多成员组。
（3）与小型企业所面对市场相关的问题
　　小型软件企业面对的市场有很多影响改进活动的特性。通常而言，小型软件企业与其顾客关系紧密沟通，容易受到市场经济的影响。与市场相关的问题总结如下：
　　应变能力假设。小型软件企业的软件的用户群较小（相对于庞大的软件企业），与客户关系很密切。这种密切关系有助于企业更加快捷了解用户需求，同时这也是一个问题。正如Brooks所说的那样，当用户的需求发生变化时，它们首先想到修改软件，而且认为软件修改起来更加容易。
　　低投资回报率。小型软件企业通常的市场用户比较少，如果组织不能显著的扩展其市场份额，则投资回报率也许会使公司上层丧失信心。
2．案例
　　由于多种CMM模型引起的混乱，以及在CMMI推出之后，SEI宣称在不久将来不再进行支持CMM，我们决定使用CMMI作为研究课题，研究如何在小型软件企业中剪裁CMMI，克服&ldquo小&rdquo带来的问题，以适应小型软件企业的改进需求。
　　本文研究对象是一家小型软件组织A1，有员工12人，其中10人从事软件开发，2人从事管理、市场和销售等其他事务。A1细分为两个部门：生产部门和研发部门。这个组织属于典型的CMM级别1的组织，没有明显的过程支持，靠的是精英，没有质量控制和度量数据。
　　我们从2002年10月开展对这家企业的过程改进，按照CMMI模型提出一套简单可行的实施过程和模型，给出简单可行的操作步骤，大大减轻了企业的过程改进压力，充分利用兼职和全职资源，并同时提供&ldquo小型软件企业过程改进支持环境（SSE-PISE）&rdquo过程改进支持软件来支持其过程改进。

刘洪鹏

3．相关研究
　　关于小型企业如何实施过程改进问题，已经引起美国和欧洲等国家等重视，并就此开展多项研究和试验。
　　[1]中提出一个基于CMM、ISO 9001和ISO 9000-3的综合模型，该模型改造ISO 9001和CMM的需求以满足小型企业的需求，本模型包含三个阶段，分别是：准备阶段、控制阶段和稳定阶段。[4]提出改造IDEAL模型的各个阶段和步骤，给出比较仔细的行动计划。[5]尝试在小型软件企业中创建ISO 9001兼容的质量系统。[6]介绍了European Commission支持的项目SPIRE( Software Process Improvement in Region of European)的进展情况，&rdquoSPIRE Handbook&mdash&mdashBetter ,Faster, Cheaper, Software Development in Small Organization&rdquo 使用SPICE自评估指南的结果，提供在小型软件企业中实施过程改进的详细指南。改进方法分为6个步骤，分别是：（1）细化与软件相关的商业目标；（2）评估当前软件实践；（3）评价员工态度；（4）开发过程改进的焦点计划；（5）基于既定改进目标来实施计划；（6）评价改进过程和结果。本改进方法的一个特点是专门对员工态度进行特殊评价。[7]分析小型软件企业实施过程化改进时应该包含的8种SPI特性，分别是：与企业商业目标相关；集中于最重要的软件过程；充分利用资金；进行能够在尽可能短时间内提供尽可能大收效的改进；提供快速的投资回报；面向过程；与其他软件模型相关；足够灵活和易于使用。[8]简单介绍LOGOS Tailored CMM的基本思想，以及简单实施指南，并给出剪裁过程，宣称本方法适合于所有规模的组织和项目，不是CMM的简单重写和改进。
4．剪裁过程和原则
　　CMMI剪裁过程的目的不是重新编写CMMI，而是根据小型软件企业的特点对其文档、实践、评审、资源、培训和管理等进行改造，同时保持CMMI的精粹和结构。由于各个软件企业的具体改进方向不同，采用的改进策略不同，使用的模型不同（连续式或者阶段式），本文不逐个解释如何剪裁KPA，这样做不容易抓住主题，而且容易陷入细节中，我们讨论剪裁文档、管理、评审、资源、培训等的普遍做法和原则。
4．1 文档剪裁
　　CMMI过程模型包含大量文档，包括策略、计划、规程、标准和报告等，如果严格按照CMMI实践来做，小型软件企业的有限资源会被文档所淹没，而丧失对改进本质的掌握。我们采用的策略是合并或者扩充文档，减少生成文档的负担，并借助于&ldquo小型软件企业过程改进支持环境（SSE-PISE）&rdquo来实现文档的快速生成、分发、合并和管理。主要剪裁策略包括：
　　文档合并。  文档合并是符合CMMI主旨的，CMMI也定义非形式化计划作为形式化计划的一部分。我们可以扩展之，项目级文档可以是其他项目级文档的一部分，组织级文档可以是其他组织级文档的一部分，前提是保证文档的可识别性。
　　可以充分利用信息系统的访问控制机制，实现文档的更大程度合并，比如每个项目的项目级文档只有一个，比如项目计划，对于不同角色，只能看到相应的信息段，进行自己权限范围内的输入、修改、阅读、转发等操作。
　　对于相关性较强的文档，尤其是某文档是其他文档的简化版本，则完全取消前一个文档，或者借助于信息化系统来实现自动生成。
　　文档消除。 对于没有涉及到的文档，则完全删除，不必提供，但是要在项目级文档中解释所采取的措施。对于信息冗余的文档，则完全删除；对于有价值信息量很少的文档，则删除本文档，然后把有价值信息量合并到相关度最强的文档中。
　　数据项抽取。 对于不同文档中的公共信息，利用信息系统从公共数据源抽取，保证数据的正确性、一致性，同时减少重新输入的工作量。
　　在本文讨论的案例中，我们充分利用Lotus R5的多媒体文档有关机制，组织级文档只保留一个；每个项目只保留一个项目级文档。对于配置管理（SCM）等KPA，基本上也限制在每个项目一个配置计划文档。当然，这个系统提供有关机制，能够保证可以从同一个文档衍生、打印输出多个子文档，分作不同场合使用。
4．2 管理剪裁
　　CMMI中任务分工非常细，涉及到的角色也非常多，但是对于小型软件企业来说，根本没有那么多人力资源来分工承担这么多管理任务。比如CMMI中的高级经理在小型软件企业中很可能就是公司总经理或者CEO，但是很多细节性任务他又不可能，也没有时间自己来做。而且，在小型组织和小型项目中，很多角色实际上是重复的，比如在小型项目中，任务领导、软件经理、项目软件经理，以及项目经理的角色时重复的，没有必要单独设置。鉴于CMMI的管理结构与小型软件企业存在较大差距，有必要对管理活动和管理角色进行剪裁。主要剪裁原则如下：
　　剖析KPA和管理任务，把相关的，不必要保证独立性的KPA综合起来，把相关管理职责分配给单个经理进行管理。
　　除非在绝对需要高级经理承诺的情况下，一般不设置高级经理这个管理职位。
　　合并管理任务，没有必要重复设置经理职位，可以把相关职责交给有关技术人员或者管理人员来实施。
　　在本文讨论的案例中，我们把KPA进行分类，保证&ldquo过程和产品质量管理&rdquo过程域的独立性，其他KPA进行实施时都实施一人承担多个职责，并把权利和职责合并和下放，每个项目只设立一个项目经理和一个SQA经理，项目经理负责项目的计划、实施、部署和维护。KPA经理负责对项目实施进行监控，安排评审、获取度量和分析数据，以及提出改进建议。
4．3评审剪裁
　　CMMI实践中涉及很多类型的评审活动&mdash&mdash管理评审、同行评审、SQA审计/验证/评审、正式评审，以及技术评审，几乎对所有项目相关的关键决策和关键文档和活动都需要进行相应的评审，以建立公共基线。对于小型项目和企业而言，如果按照CMMI模型所有评审活动都实施的话，评审所花费的时间会严重影响开发时间，因此很有必要对评审活动进行剪裁。主要剪裁原则如下：
　　适当合并评审实践。按照CMMI模型，高级管理层需要参与的评审太多，但是经理和具体实施者经常是在一个办公室工作，沟通非常方便，很多评审活动可以简化和合并，甚至取消。
　　实践证明，评审频率与项目是否关键，以及项目持续时间，关系非常密切。比如在非关键的和短期项目中，评审频率应该不影响项目生命周期，相应的管理评审、软件风险评审，以及SQA活动评审的频率应该降低。
　　把评审实践非正式化。充分利用其他会议或者碰头机会解决评审需求。
　　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中&ldquo执行能力&rdquo部分提到的工具资源通常指的是自动化工具。在小型项目或者小型组织中，很多自动化工具不仅昂贵，而且不适合。对于不成熟的软件过程，通常不能有效地使用大型CASE自动化工具。为了解决小型软件组织和小型项目中有限资源问题，我们需要对CMMI进行剪裁，主要剪裁策略如下：
　　个人可以执行项目或者组织中的多个角色；承认兼职角色和职责；可以利用组织之外的资源。
　　扩展组（group）的概念，，使之可以包含兼职人员。
　　根据项目和过程成熟度需要选择合适的自动化工具。在小型项目中，应该综合使用基本的自动化工具和人力。
　　在本文讨论的案例中，要求对资源进行分类，不仅按照人力资源、自动化工具等进行分类，而且进行进一步细化，比如人力资源根据专业方向、领导才能、沟通能力等进行分类，提出一个简单的分类和评估方法；对CMMI的资源和组概念扩展，不再局限于部门的概念，使之能够容纳各种全职和兼职人员，而且没有规模和其中职位的限制。基于不同成熟度的项目或者组织，对不同KPA提出不同的建议工具，尤其是&ldquo小型软件企业过程改进支持环境（SSE-PISE）&rdquo能够对这些工具提供接口，促进自动化工具的使用效率。
4．5培训剪裁
　　CMMI模型KPA的&ldquo执行能力&rdquo公共特性包含很多不同类型的培训需求，包括管理和技术方面的。由于培训是非常耗费资源和资金的事情，小型组织通常雇用已经被培训或者具备相关知识的人才。CMMI的培训程序KPA允许放弃培训，但是大多数企业没有认识到这个问题，仍旧坚持认为对所有员工进行培训是必不可少的。必须对CMMI进行剪裁以澄清这种误解。主要剪裁原则如下：
　　已经具备相应实践经验或者类似领域培训历史的员工可以免除培训。
　　培训可以当作以前培训的扩展，并且可以合并相关活动的培训。
　　可以扩展培训实践，消除不必要的内部培训，接收来自于外部资源或者方法的培训。
　　在我们讨论的案例中，我们对相关培训记录和人力资源培训技能和培训历史非常重视，并基于此来决定是否使用培训免除机制。如果使用这种机制，必须保证有当事人的签名。我们剪裁多个培训实践以合并或者扩充培训需求。比如，同行评审领导者培训可以与同行评审者培训合并。有些高等级成熟度KPA的活动是低等级成熟度活动的扩展，因此支持高等级成熟度活动的培训是支持低等级成熟度活动的培训的扩展，比如集成化软件管理KPA的项目管理培训。
4．6剪裁无关实践
　　CMMI是面向于大型软件企业的，其中很多实践是与小型企业不相关的，尤其很多过程实践不适合于小型项目，小型项目实施这些过程实践会花费比项目本身更多成本，并且由于部分项目的短时效性使得重新计划或者调整活动变得没有实际意义。
　　在组织过程焦点、组织过程定义、集成化软件管理，以及定量过程管理等KPA中，很多过程实践涉及到创建和维护项目已定义过程。但是在只有一个项目的组织中，项目过程和组织过程是完全相同的。如果组织的项目具备类似的特性（比如领域知识、规模和开发循环等），则所有小项目可能使用一个过程。并且这个过程是小型项目的组织标准过程。无论何种情况，那些剪裁组织标准软件过程作为项目已定义过程，以及集成项目已定义过程的变更到组织标准过程的实践都不适合。同时，对于那些开发时间很短的项目，则根本没有时间来实施项目重新计划、风险计划，以及过程调整等活动，那么这些实践对于这种项目来说也是没有用处的。
5．总结
　　中国的软件企业80%都是小型企业，人员规模在15人以下[10]，而CMMI是面向于大型软件企业的过程改进模型，怎样使得小型企业和项目能够充分利用CMMI模型的过程改进优势，并获得相关CMMI认证呢？作者参与一个只有12名员工的小型企业软件过程改进项目，本文正是基于该项目总结而得的。
　　本文首先从企业组织结构、软件过程改进模型、小型组织面对的市场需求等三个方面剖析小型软件企业的过程改进面临与大型企业不同的需求。然后分析为什么CMMI的有关内容不适合于小型企业和项目的实际情况，并概括介绍如何在文档、管理、评审、资源和培训等方面进行剪裁和改进，使之适合于小型企业和项目的实际情况。

刘洪鹏

SPICE自评估指南的结果，提供在小型软件企业中实施过程改进的详细指南。改进方法分为6个步骤，分别是：
（1）细化与软件相关的商业目标；
（2）评估当前软件实践；
（3）评价员工态度；
（4）开发过程改进的焦点计划；
（5）基于既定改进目标来实施计划；
（6）评价改进过程和结果