爱华网论文既是探讨问题进行学术研究的一种手段，又是描述学术研究成果进行学术交流的一种工具。这是小编为大家整理的cmm质量管理论文，仅供参考!
基于CMM软件项目质量管理的研究篇一
摘要: 软件企业或单位软件过程的改进是软件能力成熟度模型关注的焦点,首先对软件能力成熟度模型进行简单介绍,并以中小型软件企业为分析对象,对其软件过程管理现有不足进行探讨,之后对模型的改进及实施方案进行深入阐述。
关键词: 软件能力成熟度模型;软件过程管理;项目测试
0 前言
中中国软件行业协会相关统计资料显示,从数量上来分析,我国拥有的软件企业并不少,然而大多数的软件企业的规模有限,抗风险能力有限。实践证实,中小型软件企业在进行软件项目研发的过程中,管理无序、工期延期、系统缺乏可维护性以及经费预算不准等问题普遍存在,这些问题给软件企业业务的开展造成了极大的负面影响,甚至会造成软件项目失败。笔者分析,导致这些问题的主要原因并非研发技术不够先进,软件研发人员的业务能力不够,而是这些软件企业在进行软件研发过程中处于无序状态,将主要的注意力集中在技巧方面,对管理的重视程度不够,换句话说,就是软件生产过程对目标管理关注过度,而忽视了过程管理。
1 CMM相关理论及等级选择
CMM,即软件能力成熟度模型,其主要关注的焦点为软件企业改进软件生产过程,致力于不断提升软件研发组织或项目的软件过程能力以及软件成熟度。对软件能力成熟度模型准确而合理的运用可以促进软件研发质量及效率的不断提升。软件能力成熟度模型自提出之后,其影响范围迅速扩大,并得到广泛应用,给各国软件行业带来了深远影响,其作为国际主流行业标准的角色已经得到普遍认可。按照从高到低的顺序,可以将软件能力成熟度模型划分为五大不同等级,其共涉及关键过程域18个,目标52个以及关键实践316个。所有成熟度等级主要是由初始级以及软件能力成熟度模型数个关键过程域构成。CMM2级企业已经具备软件项目管理相关测量以及具体的实施规程,软件研发及维护过程波动不大,并具有可以重复使用的成功经验。以项目为主要对象制定过程管理策略,项目经理的主要职责是对成本、进度以及软件功能进行跟进,并找出其中存在的不足;遇到问题时,具备识别及纠正的能力,并可以实现相关承诺。CMM等级及管件过程域分类详见下表所示。
对基于中小型软件企业而言,企业规模有限,但一般具备突出的创造力,灵活性也较高,容易沟通;在人才配置方面,主要是技术研发人员,其同时兼顾管理,一般没有专业且经验丰富的管理人员;质量意识淡薄,管理水平有限,软件研发规范性有待提升;大多数是短期星期,产品及过程欠缺重复利用性。结合中小软件企业实际存在的上述不足,在实施软件项目研发管理的过程中引入CMM项目管理标准,可以为软件项目的实施及管理提供比那里,在很大程度上提升软件项目过程及质量。若以CMM标准为参考,中小型软件企业尚处于CMM初级阶段,从这点分析,由CMM2级切入较为适合;但笔者并不赞同对CMM2级管理标准进行简单的照抄照搬,原因在于:1)CMM内容的复杂系数较高,具备较为完善的标准,中小型企业的资源有限,若进行过度评审和实践将会造成实施上的不便;2)CMM培训时间长、花费大,会给中小企业造成极大压力;3)CMM只对软件能力成熟度要实现的结果作出了相关规定,但并没有对如何实现这样的结果作出说明。所以,要想使其更加适应于中小型企业的CMM,还需要对CMM管理内容及相关标准进行优化。
CMM软件的技术核心是网络计划,因为网络计划直接影响了施工生产的进度和所产生的费用,而且整个资源的动态管理与控制也都在这个网络计划的核心中,所以这个技术非常的有价值,对于企业的各项管理来说,都是很有管理价值的。在整个过程中,要先做好进度计划安排,实施好计划和编制,然后根据编制的进度进行施工项目,合理的进行工作结构的分解和作业工期等各个工序的逻辑关系,使得这样能够对于施工生产的流程和方案要求进行计算。最后还要对于这些成果进行优化和分析,对于进度编制要积极的检查和优化,这样能够对于生产作业的逻辑关系进行检查和完善,检查企业的生产是否满足其工期的要求,资源配置是否合理。
2 模型改进及实施方案
2.1 改进模型
笔笔者在此介绍一个以CMM2级为基础的软件项目管理模型,具体的结构详见下图所示。
该基于CMM2级的软件项目管理模型的生命周期结合了软件项目研发生命周期,主要包括需求的确定、制定计划、具体实施、测试维护以及最终交付等五个阶段,每个阶段中均含有对应的CMM2级关键过程域,软件质量保证以及软件配置管理贯穿于软件研发过程始终,对于大部分的中小型软件企业而言,软件研发项目并不会采取外包的方式,因此,可以用软件子合同管理KPA对其进行裁剪;若在实践中遇到需要外包的情况,可以在具体的实施阶段有项目经理筛选资质合格的转包商对子项目进行转包。
2.2 组织结构
改在进CMM过程的第一步就是要调整软件组织结构,将之前的不科学之处予以舍弃,并根据实际需求裁剪CMM2级的组织结构。对于中小型软件企业而言,研发人员队伍较为薄弱,如果设置过多人员或是过于复杂的角色关系,实现起来比较困难。组织结构角色及其工作职责为:高级经理一名,主要职责是对软件项目进行管理;项目经理数名,主要职责是对整个项目进行管理;软件工程组,一般需要根据项目规模确定组成人数,主要作用是开发、维护软件;系统测试组,可以由软件工程组兼任,但必须交叉,也就是说,同一个模块的开发及测试不能是同一组人员;软件配置人员,可由项目经理兼任,主要工作时配置软件产品;软件质量保证组,要尽可能的确保该机构在组织上的独立性,如果条件不具备,也能由项目经理或者是测试人员兼任。
2.3 实施方案
首首先,确定需求,主要是开展需求调研、分析可行性、制定需求文档以及出具可行性报告等工作。在该阶段,需要注意以下几方面内容:建立相应的管理制度,从实际情况出发,开展必要的培训,并积极创造交流机会;适时引进管理工具,并加以推广,以便于尽可能的降低软件项目管理压力;开展尽可能详细的需求调研,并且尽量多采用选择题的方式,避免使用开放性问题;其次,制定计划,主要是向软件工程的实施及各个阶段的管理提供一个科学可行的计划,具体的工作包括:选择软件项目开发模型;明确项目资源;对项目进行风险评估;工作分解与职责分配;编订项目计划书。此阶段需要注意以下几方面:根据每个开发模型的优点及不足、具体需求、项目开发周期以及研发队伍能力等因素来挑选开发模型;项目经理要带领团队对项目进行全面评估;结合研发人员特长分配职责;再次,具体实施,为了提供足够的项目实施实际进度可见度,防止在项目实际实施过程与原计划出现较大偏差的情况下,管理部门可以及时采取有效应对方案,需啊哟开展项目跟踪及监控。在此阶段,需要注意的是,在进行编码时,客户有可能对需求进行调整,这就要求项目经理能够随时提出需求变更请求,评估及批准权掌握在如见配置组手中;使用VSS等版本管理工具,这样既可以保证项目开发组成员使用最新的代码及文档,由便于程序的调试、修改和管理;项目的测试及维护,主要目的是为确保软件及服务质量,软件研发及软件项目管理的每个阶段都贯穿着项目的测试及维护;最后一个阶段就是最终交付,在项目的最终交付时并不包含任何KPA,主要涉及到的工作有项目验收、项目资料归档以及培训等。
3 结语
综综上所述,对于规模有限的软件企业而言,在进行软件项目研发的过程中,普遍存在着管理无序、工期延期、系统缺乏可维护性等问题,给软件企业业务的开展造成了极大的负面影响,导致这些问题的主要原因在于对管理的重视程度不够,笔者在软件开发生命周期的基础之上,运用CMM2级项目管理关键过程域,构建了依托于CMM2级的软件项目管理模型,并分别从需求的确定、制定计划、具体实施、测试维护以及最终交付等五个阶段对项目模型的具体实施进行了阐述。
参考文献:
[1]宋华青,国内软件企业软件开发质量与项目管理[D].对外经济贸易大学,2003:56.
[2]董锋,基于软件过程改进理论提高软件生产能力的研究[D].首都经济贸易大学,2003:45-46.
[3]王嘉鹏,软件项目质量成本模型与管理方法的研究[D].首都经济贸易大学,2005:34-35.
[4]陈宇静,基于CMM的软件过程改进案例分析[D].首都经济贸易大学,2005:45-46.
[5]李帜、林立新、曹亚波编著,软件工程项目管理功能点分析方法与实践[M].清华大学出版社,2005:243-250.
[6]孙煜,P6项目管理软件在建筑工程中的应用研究[D].华南理工大学,2010:54.
[7]李洪东、孙艺键,工程项目管理软件的发展趋势与应用现状初探[J].中国建设信息,2008(10):123-125.
基于CMM子合同管理对RUP的改进篇二
摘 要：通过运用CMM模型对RUP进行评估，计算出了RUP对CMM2级和CMM3级中的每个KPA所支持的百分比，根据计算结果分析了RUP与CMM2级和3级的差异，提出了RUP在软件开发过程中的不足，并针对软件子合同管理一项进行了充分的分析，提出了改进建议。
关键词：RUP开发;软件能力成熟度模型;软件子合同管理
中图分类号：TP311.5
21世纪是信息社会高速发展的世纪，软件成为信息技术的核心，并起着至关重要的作用。伴随着信息产业不断发展，人们开始关注软件开发过程中管理的规范化及标准化问题，软件质量的不断提高对于企业或集团的生存和发展都有着举足轻重的意义。因此，人们逐渐将研究重点转向软件开发过程。期间陆续出现了许多软件质量和过程的改进模型，比较重要的两种模型是RUP和CMM。
RUP所研究的是软件开发过程，可以用其他的软件模型对其进行评估和改进。而本文之所以选择CMM，是由于CMM在全世界范围内得到了广泛应用，影响极为深远并取得了很大成功。
1 对RUP、CMM的介绍
1.1 RUP简介
RUP(Rational Unified Process)是一个软件开发过程，使用的是生命周期迭代法。它提供了在一个开发团队内分配任务和职责的一套严格的方法。它的目标是在可预测的进度和预算内完成高质量软件的生产，满足用户的需要[1]。作为一个典型的软件过程模型，RUP的主要特点是用例驱动过程。用例不仅定义了系统需要，同时驱动了系统的设计、分析、执行和测试。
RUP是一个二维的开发模型。横轴是过程展开的生命周期特征，通过时间来组织，体现了软件开发过程的动态结构，术语主要包括迭代(Iteration)、阶段(Phase)、周期(Cycle)和里程碑(Milestone);纵轴体现自然的逻辑活动，通过内容来组织，体现了软件开发过程的静态结构，用来描述它的术语主要包括工作流(Workflow)、产物(Artifact)、工作者(Worker)、和活动(Activity)。如图1：
图1 RUP迭代模型
RUP的生命周期在时间上被分解为4个阶段，分别是初始阶段、细化阶段、构造阶段和交付阶段。每个阶段包含着一个或更多的迭代。一个典型的迭代将包括9个核心工作流，分别是商业建模、需求、分析和设计、实现、测试、部署、配置和变更管理、项目管理、环境。每个阶段在一个主要的里程碑处结束;每个阶段的本质实质上是两个里程碑之间的时间跨度。如果想要确定这个阶段的目标是否已经满足，那么需要在每个阶段的结尾执行一次评估。若评估结果令人满意的话，可以允许项目进入到下一个阶段。
1.2 CMM模型简介
CMM(Capability Maturity Model)，即软件能力成熟度模型，是由美国卡内基梅隆大学的软件工程研究所研发的。该模型提供了一个软件工程成果和管理方法的框架，旨在帮助软件企业保证软件产品的质量并提高软件企业的管理水平[2]。CMM包含5个成熟度等级，如初始级、可重复级、已定义级、已管理级和优化级。除初始级以外，CMM对每个等级规定了关键过程域(key process areas，KPA)，每个KPA都关联着一些目标。这些目标满足了该KPA过程所需的要求。不同成熟度的KPA可以用于评估现有的过程能力，也可以识别出哪些领域需要加强，便于软件开发过程从低成熟度级别向高成熟度级别递进。
关键实践(key practice，KP)是一种基础设施和活动，其对KPA的有效实现和制度化起到了非常重要的作用。在软件组织取得更高级别的过程成熟度时，每一项KPA中所要执行的特定KP都将得到进一步展开。根据KP的共同特征(common features)，我们可将关键实践分为五大类：执行约定，执行能力，进行的活动，测量和分析，验证实施。
2 运用CMM对RUP的评价及其结果分析
2.1 评估
在该评估过程中，RUP以Rational公司2001年3月份发布的《Rational统一过程》为准，CMM中有关KP的规定以《Key Practices of the Capability Maturity Model》，Version 1.1为基准。
制定的评估的方针是评价RUP是否支持CMM2和CMM3中的KP标准，看CMM2和CMM3中的KP是否在RUP的一系列活动、角色、产物和工作流中得到了实施。当这种支持率达到75%以上时，那么就认为此KP得到了RUP的支持。
表1-表2是运用CMM2和3对RUP进行评估和计算后的结果。[3]
表1 RUP所支持的KP数量及支持率
关键过程域(KPA) 关键实践(KP)
总数 支持个数 支持率
同行评审 9 6 67%
组间协调 17 13 76%
软件产品工程 20 16 80%
集成化软件管理 19 15 79%
培训大纲 16 0 0%
组织过程定义 11 9 82%
组织过程焦点 16 7 44%
软件配置管理 21 18 86%
软件质量保证 17 10 59%
软件子合同管理 22 0 0%
项目跟踪与监督 24 20 83%
软件项目计划 25 20 80%
需求管理 12 10 83%
表2 去除执行能力后对KP的支持率
关键过程域(KPA) 关键实践(KP)
总数 支持个数 支持率
同行评审 6 6 100% 组间协调 12 12 100%
软件产品工程 16 16 100%
集成化软件管理 16 15 94%
组织过程定义 9 9 100%
组织过程焦点 12 6 50%
软件配置管理 16 16 100%
软件质量保证 13 9 69%
项目跟踪与监督 19 18 95%
软件项目计划 21 18 86%
需求管理 8 8 100%
2.2 评估结果分析
表1列出了CMM2和CMM3中KPA的KP的总数，以及KP得到RUP支持的个数和支持率。表1中对KP支持率达75%以上的，我们认为其得到了RUP的支持。但我们可以看出，RUP对软件质量保证、组织过程焦点和同行评审的支持率较低，其原因归结如下：
(1)RUP未协调好软件开发人员和质量保证人员的关系，二者处于对立地位;衡量软件质量保证的成本和进度状况的方法在RUP中也未进行阐述;
(2)RUP没有阐明如何实施、协调和实现组织当前过程和改进域;
(3)RUP没有对项目资源和投资进行评审。
RUP不支持软件子合同管理和培训大纲。RUP认为这两项不属于软件过程的范围，但组织应对这两项提供支持。因此在表2中这两项被裁剪。
表2列出了在去掉执行能力后各KPA所得到的支持率。通过分析我们可以看出，KPA所得到的支持率都有所提高，有些甚至达到100%。这也表明RUP强调的是软件开发过程，而不是与系统管理有关的其他方面。这是因为RUP不是从项目管理过程演化来的，是从统一软件开发方法演变而来。[4]
3 对RUP的改进
根据前面的分析，影响RUP对CMM2和CMM3中各KPA支持率的原因有很多，但主要集中在以下三个方面：没有对计算机资源进行较好的评估和监督;未对员工进行有效的培训;没有对子合同进行充分管理。下文主要针对子合同管理方面提出改进建议。
3.1 软件子合同管理概述
所谓软件子合同管理SSM(Software Subcontract Management)，是指主承包方所承制的产品中有一部分软件利用组织外的其它力量来完成，为此签订合同，并按合同进行管理的过程。实质上与合同管理基本一样，只是要受顾客要求的约束，要符合顾客所提的要求。是确保主承包商产品质量的重要环节。
一般软件子合同管理分为6个主要阶段进行：
(1)准备和策划：确定外购的产品及外购时间;
(2)子合同定义：将外购需求文档化，并确定潜在资源;
(3)招标：从潜在子承包商处获取其解决方案;
(4)评价和选择：选择合格的一个或几个子承包商;
(5)管理和控制：监督和管理子承包商的有关活动;
(6)子合同结束：验收、完成子合同，解决残留问题。[5]
3.2 CMM的关键过程域SSM
SSM的目的在于选择合格的软件子承包商并有效地管理它们。内容包括选择软件子承包商、建立和子承包商的约定，及跟踪和评审子承包商的性能和结果。这些实践包括对纯软件子合同的管理，也包括对子合同的软件成分的管理，后者含有软件、硬件和可能有的其它系统成分。
为使软件子合同管理活动能顺利进行并取得成功，首先必须有必要的领导支持和保证条件。所谓领导支持，是要制定管理软件子合同的书面的组织方针，并要求项目遵守，同时指派一个子合同经理负责建立和管理软件子合同;必要的保证条件包括提供足够的资源和投资、进行必要的培训和定向培训。
其次，为使该过程制度化和不断改进，还必须对过程活动的实施情况进行测量分析和验证。对软件子合同管理活动进行测量，分析测量结果用来确定该管理活动的状态。而对过程活动的验证包括如下几点：
(1)高级管理者定期参与评审软件子合同的管理活动;
(2)项目经理既定期地也事件驱动地参与评审管理软件子合同的活动;
(3)软件质量保证组评审(或)审核软件子合同的管理活动和工作产品，并报告其结果。[6]
图2-图3是软件子合同管理过程活动的概要和活动流程
图2 SSM活动概要
图3 SMM活动流程
3.3 结合SSM改进RUP
由于RUP是从统一软件开发方法而不是从项目管理过程演化而来，所以在软件子合同管理等方面未能给予充分的重视。而在软件项目的实施过程中，妨碍SSM成功的因素有很多，包括：
(1)没有选择子承包商的准则;
(2)没有管理子合同的规范;
(3)缺乏沟通;
(4)对术语、文化、专有信息等方面缺乏理解;
(5)缺少战略伙伴共同发展的思想。
那么在实际的软件项目开发过程中，要尽量克服以上因素，将软件子合同管理真正融入到其中，不断完善RUP使其成为满足各自项目的利器，而不再只是一种单纯的框架模式。
4 结束语
RUP虽然作为一套成熟的软件过程管理方法，但因为其演化背景所限，并没有涉及太多整个系统管理的其他方面，如人力资源管理、子合同管理等等。
对于一些希望通过采用RUP来通过CMM2级或3级的组织来说，必须对RUP进行合理的改进。想要通过CMM2级的组织必须对子合同进行有效管理，对计算机资源进行有效评估和跟踪，完善同行评审。对于一些想通过CMM3的组织，除了完善上述机制以外，还需要对组织的软件过程进行持续改进，制定软件过程的改进计划并交由高级经理进行评审，同时对员工进行有效的培训，从而满足需要。
参考文献：
[1]张俊惠.基于RUP的质量管理系统的研究与实现[D].大连海事大学，2006.
[2]杨华煜.CMM在我国中小型软件企业中应用的研究[D].哈尔滨工程大学，2003.
[3]Lisandra V.Manzoni and Roberto T.Price，Member，IEEE.Identifying Extensions Required by RUP(Rational Unified Process) to Comply with CMM(Capability Maturity Model) Levels 2 and 3[J].IEEE TRANSACTIONS ON SOFTWARE ENGINEERING.2003.VOL2：NO2.
[4]赵岳松，张亚军.运用CMM对RUP的评估和改进[J].微机发展，2004(14)：100.
[5]Software Subcontract Management Process，Version 2.0，CIG Software Engineering Process Group，March，1997.
[6]王霞.软件外包项目管理的CMM实践[J].福建电脑，2004(04)：25.
作者简介：侯文昊(1987-)，男，河北迁安人，研究生，主要从事工业工程方面的研究。
作者单位：北京建筑大学机电与车辆工程学院，北京 100044
