基于度量能力成熟度模型的组织级度量过程改进研究

朱方洲　周伟良

摘要:文章讨论了软件企业在采用同一度量方法度量软件过程和产品得到的质量差别却很大的现状。通过分析度量能力成熟度模型及通用过程改进模型,研究得出组织要改进度量效果,必须把精力集中于提高度量能力。本文提出了基于度量能力成熟度模型度量过程改进方法及流程,通过案例实施明显地提高了公司的项目管理的成熟度水平,使公司产品研发和项目管理的能力得到很大程度的提升。

关键词:度量能力成熟度模型;过程改进;关键过程域

中图分类号:TP311文献标识码:A文章编号:1009-3044(2009)22-pppp-0c

软件度量(Software Measurement)是通过各种不同的量度(metric)对软件生命周期中的各个元素进行度量(Measure),它能够为项目管理者提供有关项目的各种重要信息,同时也是进行大多评估活动的基础,软件度量是提高软件品质的一个重要方法。度量本身并不能增强或削弱软件过程的自适应能力,但它能给出对软件过程内、外部的清晰和明确的理解,为软件过程管理提供决策信息。度量从计划阶段到数据采集阶段再到度量应用阶段都明确体现了度量的过程性,度量过程既是软件过程域的一部分,又是软件管理过程的一部分。度量软件产品、过程的质量的高低依赖一个稳定、有效的度量过程,度量过程本身也需要不断改进。

通过对采用度量决策支持系统的软件研发组织的研究分析发现,采用同一方法的不同软件研发组织研发的软件产品及过程的质量差别却很大,这差异的原因可能在于组织的度量能力的高低[1]。因此如何改进度量过程是目前亟需研究的重要课题。

1 度量能力成熟度模型

通过大量度量程序案例研究得出,一些软件组织的软件度量能力强于另外一部分组织,部分原因可能在于它们度量能力的不同,例如软件组织在软件度量某些方面较成熟。度量能力是指组织能采用较低成本的方式度量产品,过程及资源的范围,得到实现商业目标所需的信息[2]。

1.1 体系结构

度量能力成熟度模型类似于CMM,也包含五个不同组织度量能力级别。每个成熟度级别由许多需要组织实现的关键过程域组成,当软件组织实现第二级别的所有关键过程域,就认为软件组织达到度量能力成熟度模型的第二级,当软件组织实现第二和第三所有关键过程域,软件组织达到第三级,依次类推。

1.2 关键过程域

除等级1外,每个成熟度等级被分解成几个关键过程域,指明了为改进软件组织能力成熟度应关注的几个区域,关键过程域识别出为了达到某个成熟度等级必须解决的问题。每个关键过程域识别出一串相关活动,当这些活动全部完成时,能达到一组对增强度量能力至关重要的目标。

为了使组织实现某个关键域,必须达到关键域上全部目标,当在连续的基础上,对所有项目均已达到一个关键区域的目标时,该组织达到以此区域为特征的度量能力规范化。

2 度量过程改进

软件度量过程是软件过程中进行确认、定义、收集和分析度量,以用于理解、评价、预测和控制软件过程和软件产品的部分。度量过程是软件过程不可分割的组成部分。

2.1 基于度量改进的通用过程模型

度量的对象是软件过程中的各项活动以及各阶段活动的中间产物,度量过程贯穿软件的整个生命周期。度量过程包括分析度量需求、制定度量计划、收集度量数据、分析数据等过程[3]。

图1模型包含三个概念:组织面临问题或目标、可能原因或可能的解决方案及设计度量程序或可能解决方法的实验;四个步骤为分析、方案的实施、分析及通过可行方案解决组织的问题或实现组织目标。该模型始于组织面临问题或目标,假设不考虑组织面临问题或目标的大小情况。组织所遇到的问题可能牵涉到软件设计者或软件组织,不论是组织还是个人,度量过程改进都必须经历上述四个步骤。软件组织首先通过自身组织的情况、相关专业知识及常识来分析所遇到的问题,得出一个或多个可能原因;然后组织根据其研究能力、专业知识根据分析的原因推断出其解决方案,多数情况下组织需要从多种原因中找出最可能的原因、多种方案中选出最优的一种方案,并得出该方案需要的基础数据,为了收集与问题相关重要数据,软件组织设计试验或建立一套度量程序;最后组织通过确定的方案实现组织的目标或解决所遇到的问题。

2.2有效度量程序关键要素

通过对度量成熟度模型及通用过程模型的分析,可以把M-CMM应用到通用过程模型如下图2所示。

分析发现M-CMM的所有关键过程域映射在通用过程模型的右半部分,这也说明软件组织要改进度量效果,必须把精力集中于度量能力。如果企业的目标并没有定位于M-CMM之内,从度量的观点它们的目标是可以变化的。度量过程首先必须把企业目标转换成度量目标,最终再把收集的数据及反馈情况解释给软件组织。

3 组织级软件度量过程改进实现

软件度量过程改进的建立需要在组织的环境中进行考虑,创建组织级的软件度量过程改进需要将软件度量与组织标准的软件过程集成在一起,使软件度量成为组织软件开发活动中的一个标准实践[4]。不同的组织由于其目标不同,所选择的测量元是不同的。但是在不同的组织会拥有一些相同的度量模式。

3.1 度量过程改进的目标

在任何一个软件组织中,组织实施过程改进都需要花费很大的人力、物力和财力,并学习采用新的过程。此外,还需要购置辅助工具(软件支持系统)、对员工进行相应的专业培训、度量及邀请专家现场进行指导。通过过程改进,软件组织达到本组织所需要的目标,如企业的经济效益、技术革新及高效的开发能力、产品的质量及效率、客户的高满意度及减少成本等等。

为了有效实现组织的改进目标,应用卡普兰和诺顿提出了平衡积分卡(The Balanced Scorecard,简称BSC)理论,提出了平衡积分卡度量框架[5],提供了一些相关的问题和度量去判定组织的目标和策略实现情况。它扩展了软件组织评价业绩的指标体系,不仅围绕财务层面,而且还包括了顾客层面、内部经营层面和学习成长层面。对平衡积分卡的度量指标进行筛选时,不但要遵循 SMART原则(即具体的Specific;可度量的 Measurable;可实现的Attainable;现实的 Realistic;有时限的Time—bound),而且要求各层面及各层面指标之间呈因果链关系。上述四个方面主要内容:

1) 财务层面:商业目标及从项目所得利润。

2) 客户满意度:内、外部客户的满意度,主要有性价比、平均故障时间及请求响应时间等。

3) 软件开发层面:软件需求分析、开发、维护及服务过程的实践及方法的改进,也包括组织人力资源的管理及协调能力的提高。

4) 学习和成长层面:组织开发能力的提高,如全体职员的技术技能,领域知识的层次及员工的斗志等。

为达到改进目标,可度量的指标如下表:

通过这些改进转化为对现有和潜在客户业务的扩大,并最终转化为财务业绩的提高,即达到既定的目标。

3.2 过程改进的计划

通常,软件组织进行过程改进,是由于软件开发组织在管理过程中存在着问题,有改进的需要。典型的问题如顾客的不满、软件的质量缺陷、预算范围内无法按时交货和过度返工,如果软件组织的各层次人员都感觉到存在这些问题,推动过程改进计划是比较有力的,得到组织中高层领导或高层管理的支持和参与的过程改进是比较易于实施和推广的。制定度量过程的计划包括两个方面的活动,一个是确认范围,一个是定义程序步骤[6]。确认范围根据是要明确度量需求的大小,以限定一个适合于企业本身需求的度量过程。因为在整个度量过程中是需要花费人力物力等有限资源的,不切实际的大而全或不足以反映实际结果的需求都会影响度量过程的可靠性以及企业的发展能力。在确认了范围后,就需要定义操作及度量过程的步骤,在构造的同时建立过程改进计划书。计划书主要内容如下表:

根据组织的战略不同,改进的目标,管理优先级,实践运行的层次,实施每次实践对组织的价值也不相同。软件工程过程组必须确定那些需要作过程改进,如何实现更改,以及如何获得所需要的改进。在实施计划时,过程组可以用度量成熟度模型的不同阶段和关键领域来构造部门可操作的行动计划和定义软件过程。

3.3 建立过程改进的组织架构

设置过程改进的角色和职责是启动和规划过程改进的一个关键部分。有些场合的讨论会、工作组、或领导班子能够承担这些角色和职责。支持过程改进的基础架构取决于多种因素,其中包括该组织的文化和规模,多样性的软件群体,和软件过程改进的方式选择。

最好的基础架构和组织的各层次都有良好的协调配合。通常有三个或四个基础架构因素。

SEPG(Software Engineering Process Group)是指由软件过程专家组成的团队,负责在软件组织内推动和促进软件过程改进。

进程行动小组(Process Action Teams)是指由项目经理和软件工程师组成的团队,负责软件开发和改进任务,通常由SEPG和一些兼职专家领导,任务一旦完成一般就解散的团体。

度量专组应该利用真实的项目对度量过程进行测试和调整,然后才能将该过程应用到整个组织中去,专组应确保所有的项目都能理解并执行度量过程,并帮助他们实现具体的细节。专组根据度量总结报告步审视度量过程是否满足了企业的目标需求,在进一步确认后应进行文档化管理,使其成为企业组织软件标准化过程中的一部分,同时定义工作的模板,角色,以及责任,今后组织按照已经定义的度量标准来进行过程的实施。

3.4 过程改进的实施

过程的实施也包括两方面的活动,一个是数据的采集,一个是数据的分析。数据的采集根据已定义的度量操作进行数据的采集,记录及存储。此外,数据还应经过适当的校验以确认有效性。在进行该项活动时应具有一定的针对性,对于不同的项目或活动所需要的实际数据量是有差别的,而且对活动状态的跟踪也是非常重要的。

数据的分析包括分析数据及准备报告,并提交报告,当然进行评审以确保报告足够的确实性是有必要的。这些程序步骤可能会需要更新,因为报告可能没有为使用者提供有益的帮助或使用者对报告中的内容不理解,在这两种情况下,都应回馈并更新度量过程以再进行数据分析。

3.5 持续过程的改进

过程的改进是一个不断持续的过程。我们应建立一种机制便于过程小组把有助于过程改进的方法反馈给SEPG,并应用与将来的过程改进策略和计划[7]。以外,对度量过程本身进行评估,报告的使用者会对数据的有效性进行反馈。这些反馈可能来自其他的活动,但一般都会溶入到度量过程新一轮的生命周期中去,对度量过程进行新的确认及定义。在整个改进过程中不断地根据反馈进行监督,并建立有效的项目管理工具集、有效的软件开发工具集、有效的质量保证和测试工具、有效的软件过程和方法、有效的组织结构及高效的管理者队伍,以提高组织的竞争力,实现企业阶段目标及终极目标。

4 总结

软件过程改进是提高软件组织开发能力的重要途径,它具有的渐进性、系统性、长期性等特征,客观上需要在软件研发过程中持续地积累和有效地应用,通过在项目的实施,过程改进取得了一定的成果,明显地提高了公司的项目管理、度量能力的成熟度,增强了项目管理的可视性和可预测性,降低了项目的风险,提高了客户的信任感和满意度。

参考文献:

[1] Victor Basili, Lionel Briand, Steven Condon, Yong-Mi Kim, Walc'elio L. Melo, and Jon D.Valett. Understanding and Predicting the Process of Software Maintenance Releases.In Proceedings of the 18th International Conference on Software Engineering, pages 464–474, Berlin,Germany, May 25-29, 1996. IEEE Computer Society Press.

[2] Barbara Kitchenham, Shari Lawrence Pfleeger, and Norman Fenton. Towards a Framework for Software Measurement Validation. IEEE Transactions on Software Engineering, 21(12),December 1995.

[3] Frank Niessink and Hans van Vliet. Towards Mature Measurement Programs. In Paolo Nesi and Franz Lehner, editors, Proceedings of the Second Euromicro Conference on Software Maintenance and Reengineering, pages 82–88, Florence, Italy, March 8-11,1998. IEEE Computer Society.

[4] 杨海燕,赵巍,张力.软件度量[M].北京:机械工业出版社,2004.

[5] 4. Software Engineering Institute, CMMI for Systems Engineering /Software Engineering, Version 1.1 (Staged Representation), CMU/SEI-2002-TR-004, Software Engineering Institute, Pittsburgh PA, December 2001..

[6] 9. Beth Layman and Charles Weber, "Measurement Maturity and the CMM: How Measurement Practices Evolve as Processes Mature,"Software Quality Practitioner,4,3,2002.

[7] Beth Layman and Joyce Statz, "Navigating the Speed Bumps for Measurement and Analysis,"Tutorial pre6sentation, SEPG Conference,March 2004, Orlando, FL.