一、引言

一位追求IT组织效率提高的管理人员除了想法设法提高组织的效率之外别无选择。非赢利组织已经建立起一种应用范围广泛的、客观独立的提高绩效的方法体系，它包括能力成熟度模型CMM（Capability Maturity Model）、IT基础架构库（IT Infrastructure Library）和IT控制目标（Control Objectives for IT）等。虽然，这样或那样的方法在应用领域和侧重点却是各不相同的，但是他们都为设计能产生最佳绩效的操作和开发环境的具体实现过程和实践提供了详细的指导。

既然存在这么多的模型，那么究竟哪一种模型是最好的呢？如何把他们有效地结合起来？又应该怎样把这些模型很好地应用于商业咨询服务之中呢？这些都是十分值得探讨的问题。本问就这些热点话题进行的初步的探讨，希望能对热衷于这些方面研究和应用的企业和个人有所帮助。

 

二、几种常用的提高组织IT效率的模型

1、能力成熟度模型CMM（Capability Maturity Model）

CMM是Capability Maturity Model for Software的简称，（详细具体的内容请参考网站 www.sei.cmu.edu/cmm/cmm.html）中文叫“软件能力成熟度模型”，是对组织软件过程能力的描述。

CMM起初是在美国国防部管理大型而又复杂的开发项目过成中形成的，后来逐步得到了公众和私营业主的认可而作为一种提高软件开发过程和软件质量的一种有用的框架模型被大家所接受。1984年美国国防部为降低采购风险，委托卡耐基—梅隆大学软件工程研究院（SEI）制定了软件过程改进、评估模型，也称为SEI SW-CMM。该模型于1991年正式推出，迅速得到广大软件企业及其顾客的认可。从1987年SEI推出SW－CMM框架开始，1991年推出 CMM 1.0 版，1993年推出CMM 1.1 版，2000年推出CMMI-SE/SW 1.0版。1986年,CMM首先于卡耐基 梅隆大学的软件工程学会SEI(Software Engineering Institute)和MITRE组织联合提出。

我国于2001年4月发布了《SJ/T 11234-2001 软件过程能力评估模型》和《SJ/T 11235-2001 软件能力成熟度模型》两个标准。我国政府一直重视软件产业的规范和发展，国务院于2000年6月颁发的“18号文件”第五章第十七条明确提出鼓励软件出口型企业通过ISO9000系列质量保证体系认证和CMM认证，其认证费用通过中央外贸发展基金适当予以支持。目前各省市、高新区、软件园都有对通过CMM的企业给予资金奖励的制度。

CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化，使企业能够更好的实现商业目标。它侧重于软件过程开发的管理及软件工程能力的改进与评估，因此CMM被用作评价软件承包商能力并帮助组织改善软件过程质量，是目前国际上最流行、最实用的一种软件生产过程标准，成为当今企业从事规模软件生产不可缺少的一项内容。

CMM的目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。企业实施CMM模型并评估可为企业带来如下好处：指导软件组织提高软件开发管理能力；降低软件承包商和采购者的风险；评估软件承包商的软件开发管理能力；帮助软件企业识别开发和维护软件的有效过程和关键实践；帮助软件企业识别为达到CMM更高成熟等级所必须的关键实践；增加软件企业的国际竞争能力。

CMM将软件开发过程和软件质量的成熟程度分成以下5个等级：提出了由第一级（低级）向第五级（高级）逐级发展的模式。模型的等级从低到高，可以预计企业的开发风险越来越低，开发能力越来越高。模型的每个等级由不同的过程方面（Process Area）构成，而每个过程方面又由各种目标构成，每个目标由各种特定惯例和通用惯例支持。

CMM的具体级别划分如下：

l      第一级：初始级（The Initial Level）：初始级的软件机构缺乏对软件过程的有效管理，其软件项目的成功来源于个人英雄主义而非机构行为，因此它不是可重复的。

l      第二级：可重复级（The Repeatable Level）

第二级软件机构的主要特点是：项目计划和跟踪的稳定性，项目过程的可控性和以往成功的可重复性。更具体的说：

n         机构建立了管理软件项目的策略和实现这些策略的过程。

n         新项目的计划和管理基于类似项目的经验。

n         过程能力的增强基于以各个项目为基础的有纪律的基本过程管理。

n         不同的项目可有不同的过程，而对机构的要求是具有指导项目建立适当管理过程的策略。

n         每个项目都确定了基本的软件管理控制，包括：基于前面项目的经验和新项目特点，做出现实的项目承诺（如预算、交付期、软件质量等）；软件项目管理者要跟踪开支、日程、软件功能；

n         满足承诺的过程中的出现的问题要及时发现，妥善解决；

n         定义了软件项目标准，且机构确保其被遵守。

本级的关键过程领域（KPA）包括：

n         需求管理（Requirements Management）——客户的需求是软件项目的基础。软件需求管理的目的是在客户和软件项目之间达成对客户需求的一致理解。

n         软件项目计划（Software Project Planning） ——为软件工程和项目管理建立一个合理的计划。

n         软件项目的跟踪和监督（Software Project Tacking and Oversight） ——使管理者对实际的软件项目进展过程有足够的了解，以在项目效能偏离计划太多是采取有效措施。　

n         软件子合同管理（Software Subcontract Management）——选择合格的分包商，并有效管理之。

n         软件质量保证（Software Quality Assurance） ——对软件项目过程及其间生产的各个产品进行监管以保证最终软件质量。

n        软件配置管理（Software Configuration Management） ——在整个软件生命周期里建立并维护软件项目的工作产品的完整性。

l        第三级：已定义级（The Defined Level）

第三级的主要特征在于软件过程已被提升成标准化过程，从而更加具有稳定性、可重复性和可控性。处于第三级的企业具有如下一些特征：

n         机构采用标准的软件过程，软件工程和管理活动被集成为一个有机的整体。标准化的目的是使之可使管理者和技术人员有效工作。

n         有一组人员专门负责机构的软件过程，并且在机构中有培训计划来确保stuff和manager有知识和技能完成所赋予的角色。

n         标准的软件过程结合项目的特点即形成定义的软件过程，它包括一组集成的定义良好的软件工程和管理过程。

n         一个定义良好的过程包括就绪准则、输入、完成工作过程、验证机制、输出和完成准则。

n         在已建立的产品线上cost, schedule, functionality 均可控制，软件质量被加以跟踪。

n         过程能力体现在在机构范围内对一个定义的软件过程活动、角色和责任的共同理解。

第三级主要处理以下的KPA：

n         机构过程关注（Organization Process Focus） ——机构对于改进机构的软件过程能力的软件过程活动的责任。

n         机构过程定义（Organization Process Definition） ——维护一组有用的软件过程assets和提供一个用于定义定量过程管理的有意义的数据的基础

n         培训计划（Training Program）——个体的技能和知识以使他们能够更加有效的完成他们的角色

n         集成软件管理（Integrated Software Management） ——业务环境和项目的技术需要，从机构的标准软件过程和相关的过程assets经过剪裁，将软件工程和管理活动集成为一个有机的定义的软件过程。

n         软件产品工程（Software Product Engineering） ——地完成定义良好的工程过程。它描述了项目的技术活动，如需求分析，设计，编码和测试。

n         组间协调（Intergroup Coordination） ——软件工程组主动介入其它工程组以便项目能更好满足客户要求的手段

n         同行评审（Peer Reviews） ——且有效的排除软件工作产品中的缺陷。它可通过inspection,structured walkthrough等手段进行。

l        第四级：已管理级（The Managed Level）

第四级的软件机构中软件过程和软件产品都有定量的目标，并被定量地管理，因而其软件过程能力是可预测的，其生产的软件产品是高质量的。具体地说，第四季的机构具有如下特征：

n         软件过程和产品有定量质量目标。

n         重要的软件过程活动均配有生产率和质量度量；

n         数据库被用来收集和分析定义软件过程的数据；

n         项目的软件过程和质量的评价有定量的基础；

n         项目的产品和过程控制具有可预测性。

n         缩小过程效能落在可接受的定量界限内的偏差；

n         可区分过程效能的有效偏差和随机偏差；

n         面向新领域的风险是可知并被仔细管理；

本级的关键过程领域包括：

n         定量过程管理（Quantitative Process Management） ——地控制软件项目的过程效能。

n         软件质量管理（Software Quality Management） ——定量了解项目软件产品的质量，并达到既定的质量目标。

l        第五级：The Optimizing Level

概括来说，第五级的主要特点是技术和过程改进被作为常规的业务活动加以计划和管理。处于第五级的企业具有如下一些特征：

n         机构集中于连续的过程改进

n         具有标识弱点和增强过程的手段。

n         采用过程数据分析使用新技术的代价效益并提出改进。

n         项目队伍能够分析出错原因并防止其再次出现。

n         防止浪费是第五级的重点。

n         改进的途径在于已有过程的增量改进和使用新技术和新方法的革新

构成 ：

n      陷预防（Defect Prevention） ——出错原因，防止错误再现(通过改变定义的软件过程)

n      技术变更管理（Technology Change Management） ——有益的新技术(工具、方法和过程)，并按有序的方式将其转移至机构之中。其重点在于在变化的世界中有效的完成革新。

n      过程变更管理（Process Change Management）——改进机构所采用的软件过程，以改进软件质量，提高生产率和减少产品开发时间。

概括来说，第五级企业的重点是连续的过程改进。　

纵观整个CMM，软件企业提高自身成熟度的历程是一个从无序到有序，从特殊到一般，从定性到定量，最后不断自我完善的过程。

CMM与绩效提高

从提高绩效的角度分析，企业实施CMM后将受益匪浅。

企业实施CMM，可从如下几个步骤进行：1、提高思想认识，了解必要性和迫切性；2、确定合理的目标；3、进行CMM培训和咨询工作；4、成立工作组；5、制定和完善软件过程；6、内部评审；7、初期评估；8、正式评估；9、根据评估的结果改进软件过程。

CMM为了评价当前的水平，找出问题所在，指导如何改进和了解软件承包商的软件能力。目前针对CMM开发出许多的评估方法，其中公认评估方法有两个：一是用于内部过程改进的CMM评估称为CBA-IPI；二是用于选择和监控分承包方的CMM评估，称为SCE方法。这两种方法基于不同的目的，但评估的结果应一致。评估包括三个阶段：准备阶段、现场阶段和报告阶段。

可以预言：组织对软件开发过程及其有效性的控制在上述五个等级的规范和要求下肯定能得到提高。

 

2、CMM综合模型CMMI（Capability Maturity Model Integration）

最近，在CMM基础上又提出了一种升级了的CMM模型——CMM综合模型CMMI（Capability Maturity Model Integration），该模型是为了使应用软件的开发更贴近商业需求而打造出的一种提高软件开发效率的模型。除了具备上述CMM模型中的所有特点之外，CMMI在实践中更加强调以下几个目标的实现：

ü         CMMI更加强调实现商业目标时管理与工程活动间的明确的联系；

ü         CMMI把可视化程度扩展到产品的生命周期中和工程活动中，从而保证了产品和服务能更好地迎合客户的需求，达到客户的期望；

ü         CMMI融合了从额外的最佳实践领域中吸取过来的经验教训，如从评价、风险管理和供应商管理中吸取的各种经验教训；

ü         CMMI能更加健壮地实现高成熟度的实践；

ü         CMMI考虑到了组织中额外的关键产品和服务功能；

ü         CMMI更加贴近有关的ISO标准；

 

CMMI与绩效提高

利用CMMI来提高绩效的关键是要在评估过程中进行需求分析。需求分析的目的在于理解提出要求的组织对于这次评估的商业需要，评估小组领导将收集信息来帮助评估发起方对照评估目标和他们的商业目标。通过需求分析，可使评估人员在对评估目标，约束，输出和范围形成共同理解的基础上对下一步评估做出正确的决定。

在进行需求分析之前，应确保满足以下两个进入标准：评估发起方已经决定使用SCAMPI方法；能够提供评估要求综述的人有时间接受访问。发起者、初始要求和约束、过程相关的历史信息是需求分析的三个输入因素，评估输入是需求分析的输出因素。

l         确定评估目标

我们知道，以满足商业需要为出发点的过程改进最为关心的三个因素是减少费用、改善质量、缩短产品面市时间。为此，本阶段所必需的实践是：

1.       标明评估发起者和相关的利益分担者，并在他们之间建立经常性的交流；

2.       将商业目标和评估目标文档化；

3.     确保评估目标与商业目标的一致性；

4.     确定评估使用方式（内部过程改进，供应商选择，过程监视），并将其文档化。

此外，在本阶段评估小组领导和发起者之间至少有一次交流。在某些情况下，还必须通过其他方式确保他们之间存在经常性的面谈。

l         确定评估约束

评估约束是由评估小组领导和评估发起方或者高级管理人员讨论得出的。它是一个不断反复的过程，以在满足评估发起者提出的要求、评估所采取方法的限制和对资源的要求之间达到平衡，最终达到评估输入参数的优化。为此，本阶段所必需的实践是：

1.       建立高层费用和日程安排约束；

2.     确定评估包含哪些过程域和哪些组织实体；

3.     确定对评估结果的最小期望和最大期望，或达到某一特殊的目的；

4.     和评估行为的利益分享者商谈约束条件和目的，确保评估活动的可行性；

5.     将商谈好的约束文档化。

同样，在本阶段评估小组领导和发起者之间至少有一次交流。在某些情况下，还必须通过其他方式确保他们之间存在经常性的面谈。此外，在评估早期阶段标识的费用和日程安排的约束应该是针对高层而言的，是一种系统的估计，而不是详细的估计。

 

l         确定评估范围

在评估过程中，由参考模型范围和组织范围决定了评估的范围。无论使用阶段式表示法或者连续式表达法，在过程改进执行的早期，模型范围都应该被确定并文档化。评估小组领导有责任保证发起者能够考虑到评估范围中所涉及的过程域和采取的模型表示法。评估的输出应该由他们根据实用价值来决定，在需求分析活动中制定，并且尽可能在那些可选择的模型范围内做出选择。组织范围定义了评估中调查的边界，例如：对于每一个项目的实践完成情况、为了完成组织级目标所做的实践，可被选来作为组织代表和过程执行的背景。为此，本阶段所必需的实践是：

1.       确定评估所使用的参考模型范围和表示法，并将其文档化；

2.     确定评估期间调查的组织单位，并将其文档化。

 

参考模型应包括过程域和相关的评估小组调查的最大能力等级或者成熟度等级（例如：评估范围内的过程域的共性目标）。参考模型表示法的选取应该在确定评估目标时就讨论过了，这是因为表示法的选取可能影响到评估目标的实现。

评估模型的范围至少应该包括一个过程域。所有的共性目标和特定目标应包含确定的过程域能力等级或者成熟度等级；过程域内单个的目标不能被排斥在外。

通常来说，评估期间被调查的组织单位的确定应该满足以下条件：至少有两个被调查的过程是可以作为目标证据源，而且，要能获得组织使用的生命周期的典型覆盖。组织单位实例的选取可以通过调查表，或者通过和组织人员讨论得出的概要信息来决定。对于组织级别的过程实现（例如：组织培训），不要求多个实例。

评估中将调查的典型实例也会驱动提供目标证据信息源的参与者的选取。评估参与者（名字，角色）在初期所做的决定应该作为组织范围确定的一个部分，和评估发起者或者高层管理者磋商。这在后面的详细评估计划中将得到进一步确定。

l         确定评估输出

本阶段的目标是确定特定的评估输出。有些评估结果是必需的，而附加输出是可以剪裁的。在确定评估输出之前，应清楚地了解下面的问题的答案：

1.       评估中将产生什么级别；

2.     文档化评估结果，是否要写最终报告；

3.     是否要产生和报告关于怎样致力于特定发现的建议。

 为此，本阶段所必需的实践是：与评估发起方一起检查要求的输出；与评估发起方一起检查并选择可选的过程改进评估方法的输出。要求的过程改进评估方法输出包括：评估记录；评估发现的事项综述；CMMI干事数据。

尽管可以选择不向评估发起方之外的任何人公布定级结果，但因为在ARC中规定了，至少过程域的目标和调查的过程域都必须定级。因此，评估发起方至少要得到如下评估结果：

1.       最终发现，包括评估小组对每个调查的过程域的文档化的强项和弱项陈述；

2.       计划内的、评估小组对相应评估对象的定级描述。

 

是否达到评估输出的决定，包括将报告的定级，应在评估输入中写明。此外，评估发起方可能要求附加的定级输出来作为评估的结果。可能选择的典型的定级结果包括：

1.       成熟度等级或者能力等级评定；

2.     过程域满意／能力等级剖面；

3.     实践定级；

4.     可选择：使用“部分满意Partially Satisfied”用于过程域定级；

5.     15504过程剖面；

6.     特定学科定级（例如：SE或者SW）；

7.     项目级别的发现或者定级；

8.     其他（非典型）的期望的输出。

 

评估发起方可能也要求其他的产品作为评估结果，可能要求的典型的产品有：

1.       评估最终报告；

2.     基于评估结果，采取行动的建议；

3.     .过程改进活动计划。

4.     获得评估输入的许可

 

本阶段的目的是确认评估发起方对评估输入的正式批准，并且这些信息集合置于变更管理之下。为此，本阶段所必需的实践是：

1.       记录评估输入记录的要求信息；

2.     获取评估输入记录的发起方的正式批准；

3.     管理评估输入的变更，获取发起方对于变更的承认。

 

评估输入可能是在计划中逐步产生的，但必须在数据收集开始之前得到正式批准。因此，评估输入至少应该包含如下必需的信息：
1.评估发起方的身份，发起方和被评估组织单位之间的关系；

2.评估目的，包括相应的商业目标；

3.评估参考模型范围；

4.被评估组织单位；

4.     评估过程背景，包括：组织单位的大小和人员统计情况，应用领域、大小、危险程度和复杂度；组织单位产品和服务的高优先级特征（例如：面市时间，多功能，可靠性）；

5.     评估约束，包括：关键资源的可用性（例如： 人员，资金，工具，便利设施，日程安排约束，评估可用的最多时间，评估之外的特定过程域或者组织实体，评估期望的最大、最小或者特定样例大小或覆盖，评估结果的所有权归属以及使用的限制，一致同意的信息结果的控制，评估结果与相关来源的属性。

6.       使用的CMMI模型标识（版本，学科，表示法）；

7.     将成为评估小组领导者的主任评估师的身份和联系方法；

8.     评估小组成员的身份和联系方法，以及他们各自特定的评估责任；

9.     .评估参与者和支持人员的身份（名字和组织关系），以及他们各自在评估中的特定责任；

1   .为实现评估目标，评估期间收集的任何附加信息；

1   .包括将产生的定级的计划评估输出描述；

1    预期的进一步活动（例如：报告，评估活动计划，再评估）；

1    计划的SCAMPI剪裁和相关的折衷，包括组织单位的样例大小或覆盖；

1    评估使用的方式（例如：内部过程改进，供应商选取，过程监视）。

 

需求分析作为过程改进评估方法的第一步，是进行准确评估的前提条件。当满足下面三个退出标准时，我们认为需求分析阶段可以结束：评估发起方和权威的SCAMPI主任评估师进行了初步的接触；主任评估师已经访问了发起方组织的成员；评估输入已经被评估发起者证明并且置于变更管理之下。

值得注意的是，评估发起者在过程评估方面的经验将推动这一过程的剪裁选择。一个没有评估经验的发起者将需要大量的信息和合作的咨询，以提供有意义和完整的评估需求；而有经验的发起者很可能会提供很有针对性的需求分析。

IT绩效提高的几大最佳实践标准（二）（AMT研究院 张艳）