本站原创该文是行政管理专业软件开发论文范文，主要论述了关于软件开发相关毕业论文参考文献格式,与软件过程管理相关论文范文资料，适合软件开发及软件工程及项目方面的的大学硕士和本科毕业论文以及软件开发相关开题报告范文和职称论文写作参考文献资料下载。
【摘 要 】CMMI利用了两个或多个单一学科的模型实现了组织的集成化过程改进,提炼了公共过程域,缩减了过程域的总数量,提高了软件开发质量和生产效率,推动了软件产业的发展.对CMMI的重要内容做了相应解释,并阐述了在应用CMMI中的经验和感想.
【关 键 词 】CMMI；软件过程；项目管理
一、CMMI概述
CMMI（Capability Maturity Model Integration）,英文的意思是”能力成熟度模型集成”.由卡内基.梅隆大学的软件工程协会（Software Engineering Institute,简称SEI）在CMM的基础上完善而成,目的是通过一个合理的体系模型来对软件组织开发能力进行合理有效的评估,帮助软件组织在模型实施的过程中提高软件过程管理能力,降低软件系统开发风险,在预定的项目周期和预算内开发出高质量的软件产品.并且充分考虑了软件工程与系统工程的集成,使得CMMI不再局限于纯粹软件的范畴.
二、CMMI模型概要
软件开发的风险之所以大,是由于软件过程能力低,其中最关键的问题在于软件开发组织不能很好的管理其软件过程,从而使一些好的开发方法和技术起不到预期的作用.而且项目的成功也是通过工作组的杰出努力,所以仅仅建立特定人员上的成功不能为全组织的生产和质量的长期提高大下基础,必须在建立有效的软件工程实践和管理实践的基础设施方面,坚持不懈地努力,才能不断改进,才能持续的成功.
CMMI提供了一个框架,将软件过程改进的进化步骤组织成5个成熟等级,为过程不断改进奠定了循序渐进的基础.表1给出了CMMI-SE/SW 1.1 Staged Representation模型概要,5个等级各有其不同的行为特征.不同等级组织的行为特征：即一个组织为建立或改进软件过程所进行的活动,对每个项目所进行的活动和所产生的横跨各项目的过程能力.
以下是5个等级其不同的行为特征：
初始级：在成熟度第一级中,过程通常是特殊而混乱的,而且组织通常没有提供稳定的环境.这些组织的成功,往往依赖组织成员的能力与英雄主义,而不是使用一套经过验证的过程.除了特殊、混乱的环境之外,成熟度第一级的组织也经常会产生可运行的产品和服务,不过它们经常会超过项目的预算和进度.成熟度第一级组织的特征有过度承诺的倾向、在紧急关头放弃过程,以及无法重复成功经验.
已管理级：在成熟度第二级中,组织已达到成熟度第二级所有过程域的特定及共性目标.换言之,组织的项目已确保需求是被管理的,而且其过程是经过规划、执行、度量及控制的.在处于压力的期间,成熟度第二级所反映的过程规范,可提供协助以确保现行的实践会保持不变.在这些实践适宜的情况下,项目的执行和管理,就按计划进行.在成熟度第二级,需求、过程、工作产品及服务是受管理的.在定义的时间点（例如：重要里程碑、重要任务完成时）,管理等级都可以了解工作产品的状况和服务的交付情形.建立有关相关人员的承诺,并视需要修订.管控工作产品并与相关人员共同审查工作产品和服务可满足其特定的需求、标准及目标.
已定义级：已将管理和工程两方面的软件过程文档化、标准化,并综合成该组织的标准软件过程.所有项目均使用经批准的、剪裁的标准软件过程来开发和维护软件.
量化管理级：收集了软件过程和产品质量的度量数据.软件过程和产品质量均得到定量的了解和控制.软件开发的成本、进度和软件质量等都可以定量预测.
优化级：通过收集来自过程和来自实验创新思想和技术的定量反馈信息,使得持续的过程改进成为可能.
三、经验体会：
众所周知,商业公司以追求利润为目的,实施CMM（或CMMI）对公司的帮助何在?一次在面试软件开发工程师问到公司实施CMMI对你的工作有什么帮助,或者你觉得有什么益处.他想了想说觉得没有什么益处,除了大量的文档以外.笔者听了觉得有一种振动,如果所有接受这个流程,或者使用这个流程的人都是这个感受的话,这将是过程改进从业人员的悲哀.
公司在流程建设以及流程改进过程中,希望更多的从实施人员的立场来考虑,希望流程真正体现了公司需要的工作过程,并对此工作过程进行不断的优化.业界在谈到过程改进时,都会提到过程改进是为商业目标服务的,但是在遵循商业目标的前提下,流程要实施其实主要还是要靠项目组来实施,而不是靠质量保证组（QA）去检查,或者说质量管理部门成天追着后面要文档.在流程建设过程中,应更多地考虑怎么帮助项目组提高工作效率,减少重复劳动,让项目组人员真正感受到过程改进人员是提供帮助的,流程是必须的工作过程,而不是带来更多的文档或更多的不愿意做的事情.
以下是笔者对于公司的过程以及过程改进的一些体会：
1.过程改进形成了良好的工作氛围
公司在建立流程文档的时候,是从公司已有的工作过程出发,进行整理,而不是质量管理人员孤立地闭门造车.质量管理人员经过与项目组人员多次的沟通、了解,最后总结并形成流程文档.从符合公司商业目标来说,软件工程过程组（SEPG）一直致力于组织文化的培育.这个文化培育可能是比较虚的词,这么说吧,当有新人加入公司的时候,大家可以不断感受到这种气氛,就是这个组织是一个什么样的工作氛围.
倡导一个开明公正的氛围,而这个倡导因为是从上到下进行的,因此比较有效.从高层经理,中层经理,一直到下面普通员工,一直在一个开明、公正的氛围中工作的话,大家都会自觉维护这个氛围.当新人加入时,尤其是新毕业的学生,一进来感觉就比较好,而且很快会接受这种氛围.
从过程改进方面来说,也是在这个氛围中进行的,对于工作流程的整合,对于工作流程的每一个细小的改进,组织中的每一个人都可以进言献策,而不是由领导说了算,或由质量管理人员说了算.也正因为如此,过程改进以及执行都能比较得到大家的认可,项目组人员在项目开发过程中也比较乐于接受这些流程. 2.流程化管理让工作更有序化
流程文档是从实际工作过程中抽取并定义的.在整合过程中,对于过程角色以及角色的职责做了进一步的清晰定义,同时,对于工作过程也做了制定了工作步骤要求.这样,从客户方发出项目开始,一直到项目验收,项目总结,定出了一整套的流程.就是从第一步开始,下一步怎么做,定义了一个做事方式.另外,在流程里面定义了在一个阶段到下个阶段的职责,比如说这个阶段谁负责,负责人干什么事,其他人员干什么事,基本上都定义清楚了.这样很大程度上避免了有些事情大家都觉得应该干,而有些事情却没有人干的局面.所以,流程定义到了每个角色的头上,这样的话,不同的角色,比如在这个项目组是一个负责人,可能到另外一个项目组是一个普通的工程师,因为角色不同,在不同项目里面的工作也不同.而这些定义,当项目启动的时候,都转化为项目开发计划.
每个项目都要求做项目开发计划,这个计划包括这个项目在自己开发部是怎么做的,同时还包括如果在这个项目外包给软件公司,对软件公司怎么管理的计划,还有我们这边人员怎么配置的计划,这个计划里面包括了很多内容.其他还有配置管理的计划,SQA计划等等,这些计划都包含在软件开发的计划里面.从这个计划建立以后,在后面的过程中基本上要求按照计划执行.但是同时因为项目是变化的,有可能项目定义的内容会有一些偏差,这个时候要求对计划进行监控,如果出现大的偏差的话,开发计划就要调整,如果出现小的偏差,就需要对Schedule进行调整.同时,如果外包给软件公司的项目,也要求软件公司提供项目计划,而且要求他们每周对进度进行汇报.同时,在计划里面还定义了milestone review,不同阶段的review谁参加,大概是什么时候,这个都要求在计划里面进行定义.
项目组人员在项目计划的指导下,因为职责明确,步骤清晰,都能更有效和高效地工作,避免了许多不必要的重复工作（rework）,大家感觉项目做的比以前更顺畅,同事间合作也更融洽,少了很多互相推诿.
3.通过流程化管理,全员的风险意识会大大提高
定义一个比较详细的风险分析流程,流程中要求制作风险标注表.风险标注表是基于FMEA的方式,里面有风险的发生概率,发现的严重程度等等.所以要求在项目开始时候,就进行风险分析,风险分析的结果作为项目开发计划的一部分.风险分析时主要从资源和项目进度等各方面进行分析,同时提供了一套典型的分析表给大家作为参考.所谓的典型风险表就是从各个项目里面制定的风险中抽取,以及从各个项目反馈回来的可能风险,不断更新和充实典型风险表.在执行这个流程的时候,在项目一开始就要标识风险,如果超过一定数值的风险,就要做对应的策略.这样的话,项目开始就有风险的计划,风险的标识,和风险对应计划.在项目开发过程中每周对风险进行识别,有没有新的风险出现,有没有原来的风险数值的降低,等于就是在全项目的过程中,对风险有一个控制.在项目过程中有一整套的风险管理,可能大家在不知不觉中接受了这种风险管理的意识,有的时候在日常生活,甚至是整个公司的其他事情都不自觉的就有了风险意识.所有的东西归根到底就是给每个员工成功感,觉得在这个公司有发展的前途.
下面说一下工作量的量化.工作量的量化不是一件容易的事情,从实际需要出发,做了一些量化的工作.前面提到的项目开发计划,根据WBS分割,对项目规模进行估计,在此估计的基础上安排人员与进度.同时,收集每天的工作记录,以便进行计划工时与实际工时的比较、追踪与监控.为此特意开发了一个系统来录入计划,并可以让每一个员工按照不同分类记录自己每天的工作工时.在此过程中,可能会遇到数据不准确的问题,但基于公司比较开明的氛围,以及让每个员工意识到收集数据并非是为了限制员工,而是为了帮助员工,收集到的数据的可信度也在逐步提高.这些收集到的数据,一是作为经验数值,被用于其他项目计划,二是作为实际与计划的偏差依据,便于项目经理对人员的工作负荷进行调整,或者在发现偏差时,尽早采取行动.正是让项目组人员看到数据对于自己的好处,大家都积极配合,提交尽量准确的数据.比如：从普通的项目组的感觉来说,至少工作量的量化可以给普通开发人员一个机会,可以提出来工作量超时的问题,在真正超时情况下,可以拒绝一些事情,而不是说上面领导说了算,不顾下面员工的实际情况,只能靠加班来达到经理的要求.所以,这个流程带给普通的开发人员一个渠道,来反应这个工作确实是超时了,而且需要上面的经理,甚至高层经理帮助解决.
4.流程化管理给普通开发人员带来了工作成就感
关于工作的成就感,涉及到每个人的感受.从流程角度来说,或者说从过程改进的角度来说,在计划方面,Review方面能促使组织中的每个人的工作更有成就感.Review分技术Review和管理Review.技术Review就是提前介入,提前减少风险,使项目的质量朝预想方向进行.实际上Review也是减少了项目组人员的工作时间.还有计划、Review,风险分析等等,都减少了救火事件.当然每个项目都会存在救火的时间,但是流程就是帮助项目组尽量减少救火的出现.在很多公司里面存在这种状况,如果某个项目一直很顺利,什么事都没有出,平平淡淡过去了,领导会觉得这个项目没有出现英雄人物,如果出现救火了,出现一个大问题,出现一个或几个英雄把这个困难克服了,事情终于做完了,可能觉得体现了公司的能力.但是如果软件开发想产业化,比如说想做大规模的开发的话,应该还是尽量避免救火的出现,而且尽量避免靠某些英雄人物的存在.
还有一个,定义的比较好的项目总结流程,也在一定程度上增加了成就感.根据流程定义,到项目验收通过,无论涉及到三方或者两方的情况,要求三方或者两方必须做总结,一个是质量数据的总结,再一个就是经验教训的总结,总结项目过程中好的点、不好的点,给其他方.比如说软件公司觉得需求写得不是很清晰,可以在项目总结时反馈.而且在做完总结之后,不是说做完了就完了,还要开会讨论,要定义下一个项目该怎么改进,关联各方怎么改进.而且自己内部在项目结束之后要在相应的人员中开总结会,开总结会的时候,管理方面有什么做得不好的,技术方面哪些方面要提高的,沟通方面有哪些问题,这些东西都要总结下来.这些总结,三方或者两方都是共享,在下一个项目的时候,就不会犯同样的错误.所以,从流程的角度来说,项目组感觉虽然这&#
该文是行政管理专业软件开发论文范文，主要论述了关于软件开发相关毕业论文参考文献格式,与软件过程管理相关论文范文资料，适合软件开发及软件工程及项目方面的的大学硕士和本科毕业论文以及软件开发相关开题报告范文和职称论文写作参考文献资料下载。
20010;项目很繁杂,工作任务很重,但是工作还是很有成就感的.四、小结
软件过程管理的度需要根据具体公司的实际情况,人力、物力投入,人员素质,项目情况来选择,抽象的软件过程管理理论固然完美,但只有对提高本公司、本部门软件开发水平和质量有帮助的才是最合适的.