CMMI软件范文

CMMI软件范文（精选9篇）

CMMI软件 第1篇

随着企业和社会信息化的日益普及,与信息技术紧密相关的各类软件项目,诸如软件开发、组建计算机网络和信息系统集成等软件项目和我们生活的联系越来越频繁。随着软件建设环境的日趋复杂,软件项目的投资和建设规模也急剧增加。软件项目所固有的需求很难准确定义、建设标准和目标不易统一、技术人员流动频繁、研发技术发展迅速等特点决定了它要充分考虑项目管理中可能遭遇的各种风险,还面临着其他类型项目所不具备的特殊风险。这些风险的存在很可能会造成数据丢失、进度推迟、成本增加等不良后果,更为严重的可能会导致项目中断甚至整个项目的失败。

软件项目风险管理是指贯穿于软件项目生命周期,保证项目按计划进行的策略、方法、技术和工具的集合,它含有风险辨识、评估、排序、计划、监督和控制活动,并成为软件项目管理的主要部分之一。软件项目风险管理的目标是识别可能影响软件项目成功的任何风险;提供识别和评估风险的标准过程和方法;通过适当的行动将风险产生的概率或后果压至最低;实时监测和报告风险,为制定防范和应对风险的措施提供决策依据。

项目风险管理强调对项目目标的主动控制,对项目实现过程中遭遇的风险和干扰因素可以做到防患于未然,以避免和减少损失。

1 基于CMMI的风险管理模型

美国卡内基梅隆大学软件工程研究院(SEI)在CMM(能力成熟度模型)的基础上提出了CMMI(能力成熟度模型集成)。

1.1 CMMI介绍

CMMI把各种能力成熟度模型集成到一个框架中去,这个框架有两个功能,第一,软件采购方法的改革;第二,建立一种从集成产品与过程发展的角度出发、包含健全的系统开发原则的过程改进。CMMI是CMM的修订本。CMMI的源模型为:CMM2.0(C稿);电子行业协会临时标准(EIA/IS)731;集成产品开发能力成熟度模型(IPD-CMM)v0.98。CMMI共有五个等级,分别标志着软件企业能力成熟度的五个层次。

(1)初始级:软件过程是无序的,有时甚至是混乱的,对过程几乎没有定义,成功取决于个人努力。管理是反应式的。(2)已管理级:建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律,能重复早先类似应用项目取得的成功经验。(3)已定义级:已将软件管理和工程两方面的过程文档化、标准化,并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件,软件产品的生产在整个软件过程是可见的。(4)量化管理级:分析对软件过程和产品质量的详细度量数据,对软件过程和产品都有定量的理解与控制。管理有一个做出结论的客观依据,管理能够在定量的范围内预测性能。(5)优化管理级过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。每个等级都被分解为若干关键过程域,特殊目标和特殊实践,通用目标、通用实践和共同特性。风险管理过程在CMMI第三级—已定义级中描述。[1]

1.2 CMMI风险管理模型

风险管理是一种连续的、前瞻性的过程。它要识别潜在的可能危及关键目标的因素,以便策划应对风险的活动和在必要时实施这些活动,缓解不利的影响,最终实现组织的目标。CMMI的风险管理被清晰地描述为实现三个目标,每个目标的实现又通过一系列的活动来完成(见图1)[2]。

1.2.1 目标1:准备风险管理

包括三个活动:确定风险来源和类别;定义风险参数;建立风险管理策略。在该目标实施过程中,将产生:①风险来源清单和风险类别清单;②)风险可能性(也就是风险发生的机率)、风险结果(也就是风险发生的影响和严重性)、引发管理活动的极限值;③项目风险管理策略等数据,并写进风险库。

1.2.2 目标2:识别并分析风险

包括两个活动:识别风险;评估、分类和排序风险。在该目标实施过程中,将产生:④已识别的风险清单;⑤风险清单(包含各个风险的优先级)等数据,并写进风险库。

1.2.3 目标3:降低风险

包括两个活动:制订风险降低计划;执行风险降低计划。在该目标实施过程中,将产生:⑥每个已识别风险的处理方案、风险降低计划、紧急应变计划、负责追踪和解决每个风险的人员清单;⑦更新后的风险状态清单、更新后的风险可能性、结果和极限值的评估、更新后的风险处理方案清单、更新后的风险处理行为清单、风险降低计划等数据,并写进风险库。

CMMI强调将所做的工作记录下来,作为后续工作的历史参考。该模型中各个目标的每个活动都会更新风险库,从而实现了管理的可追溯性。

2 基于CMMI的软件风险管理实践

2.1 风险形式化描述

定义1 风险可以用风险来源、风险类别、风险可能性、风险结果、风险系数、极限值和风险状态这七类信息来描述。故可令Risk=(Source,Categories,Likelihood,Effect,Coefficient,Threshold,Status)。简记为:R=(So,Ca,L,E,Co,T,St)。

定义2 风险可能性可以根据其发生的概率划分为五个等级:近乎确定(80%≤L≤100%)、非常可能(60%≤L<80%)、可能(40%≤L<60%))、不太可能(20%≤L<40%)和微乎其微(0≤L<20%)。

定义3 风险结果E由严重性(Severity,简称S)和风险发生的影响(Impact Rate,简称I)来共同标识。风险发生的严重性S可划分为五个等级:很高、比较高、中等、比较低和很低。可以量化为(5,4,3,2,1),即S={5,4,3,2,1}。

风险发生的影响I来源于N个因素。这N个因素在每个风险中所占的比重用Ii表示,严重性用Si表示。故风险结果可表示为:[3]

定义4 风险系数表示风险可能性和风险结果所带来的综合影响。风险系数的定义:Co=L*E。

定义5 极限值:对每一风险类别,可建立极限值以确定风险的可接受性或不可接受性、风险的优先级,或引发管理行为。

假设第i种类别的风险有Ni条,该类别风险中各条风险的风险系数表示为Cok(其中,1≤k≤Ni),则该类别风险的极限值Ti可表示为:

假设某软件项目有N种类别的风险,故针对整个项目风险的极限值可表示为:

定义6 风险状态St={S1,S2,S3,S4,S5}。

S1:新引入风险,即已经发现风险,但还未对其进行评估。

S2:对风险进行评估之后,发现风险系数低于极限值,表明该风险不是急迫的。

S3:对风险进行评估之后,发现风险系数高于极限值,表明该风险是急迫的。

S4:风险已经演化为问题,此时需要问题跟踪进行应对。

S5:通过风险应对,风险已经消除。

所以,也可将风险状态量化为:风险状态St={1,2,3,4,5}。[4]

2.2 软件风险管理实践

下面以某软件项目Project为例来实施CMMI软件风险管理。

如表1所示,风险评估与管理表确定11个风险来源,6个风险类别;设置各个风险的风险可能性。

如表2所示,假设风险受性能、支持、成本和进度这四个因素综合影响。设置各个风险的风险影响和风险严重性,按照定义3求得1号风险的风险结果。

将表2计算风险结果中得到的1号风险的风险结果填到表1中,依此类推,可得到这10个风险的风险结果,并依次填写到表1中。然后,按照定义4求出风险系数,根据定义5求出同类别风险的风险系数,以及引发管理活动的极限值。

在风险管理的过程中,我们通常只对极限值之上的风险进行重点关注。每周需要做一份新的风险评估与管理表,每周根据以上方式获得一个极限值,从而了解哪些风险是需要重点关注的,以便处理那些会对项目产生重大影响的风险。

3 结论

在软件项目开发过程中,当对软件的期望很高时,一般都会进行项目风险分析、预测、评估、管理及监控等风险管理。通过风险管理可以使项目进程更加平稳,可以获得更高的跟踪和控制项目的能力,并且可以增强项目组成员对项目如期完成的信心。风险管理是项目管理中很重要的管理活动,有效的实施软件风险管理是软件项目开发工作顺利完成的保证。[5]

目前的风险评估主要是依靠项目人员的经验以及风险库中积累的历史数据进行。如何确定风险的可能性;如何确定每个风险中若干个风险因素所占的比重和严重性,都需要进一步研究相应的模型来确定。

摘要：有效的软件风险管理能够主动防范风险,降低损失。目前,大多数软件项目采用定性方法进行风险管理。对这一问题,在对CMM(I能力成熟度集成)风险管理分析和研究的基础上,提出软件风险定量分析方法,并应用于软件项目中。有助于更细致、更精确地控制软件风险,提高软件项目的成功率。

关键词：CMMI,软件风险管理,定量,极限值

参考文献

[1]SEI.CMMI 1.1规范.http://www.sei.cmu.edu/cmmi/.

[2]毛明志,葛晓炜.软件项目风险管理模型的分析与研究[J].科技管理研究,2005,(6):148-151.

[3]杜庆峰,王帆.定量化风险评估及动态规划控制策略[J].电脑知识与技术,2009,(5):4317-4319.

[4]王天青,潘金贵.基于CMMI的软件风险管理[J].计算机科学,2005,(32):140-141.

CMMI评估指导 第2篇

CMMI前言

CMMI意为“集成的能力成熟度模型”，于2002年正式发布，由美国国防部与卡内基—梅隆大学等共同开发研制。1998年美国卡内基-梅隆大学软件工程研究所(SEI)启动了CMMI计划，目的在于用一个统一的框架协调和集成SEI已经存在的各种模型。

CMMI模型已经成为业界主要的过程管理模型，CMMI模型有两种表示方式，连续表示模型和分级表示模型。其中分级表示模型依次划分为五个等级(初始级、可重复级、已定义级、已管理级、优化级)，标志着软件企业能力成熟度的五个层次。级别越高，表示软件组织的成熟能力也越高，CMMI5是目前世界软件界对能力成熟度要求最高、申请难度最大、级别最高的评估，通过CMMI5级评估标志着本公司的质量管理和过程改进已跻身于全球软件业的顶尖水平。

从申请CMMI认证到评估完成，往往要经历1年左右的时间，主要包括四个阶段：

一、申请CMMI认证

选择CMMI级别

软件企业申请认证CMMI不同的级别标准要求，要审时度势自身情况。一方面了解公司现有质量体系、实施过程、实施效果的运行情况;另一方面要根据企业规模、公司实力、管理需求等综合要素，不可好大喜功，一味选择CMMI更高级别的认证。在申请的CMMI认证时，有的企业从CMMI2开始、有的企业从CMMI3开始、有的CMMI3通过后跳过CMMI4而直接申请CMMI5、有的就从CMMI2、CMMI3、CMMI4、CMMI5逐步申请认证。计划参与评估的部门

CMMI评估，有的是整个公司参与评估，有的是个别部门参与评估，不管以哪种方式参与评估，公司都要权衡决定，参与评估的部门。

CMMI培训

当确定申请CMMI认证的级别后，与申请CMMI认证级别的要求进行比较，从而找出区别。结合企业自身实际情况，从而可以为通过认证作好充分的准备，尤其是对此级别相关知识进行加强培训，了解标准的要求。

二、选择主任评估师

一般情况下，企业自身确认好CMMI等级后，可以找专业的CMMI咨询公司，协助完成后面的认证流程。

主任评估师是认证评估的发起者，也是评估小组的领导者，这个角色应该拥有足够的经验、知识、技术来负责和领导评估活动。CMMI评估是基于个人资格、信誉的认证，对个人专业技术及综合能力素质要求都很高。因此，要慎重选择，主要从以下几个方面考虑： 全球从事CMMI认证企业很多，拥有SEI评估师资格的也很多，通常有美国的、印度的、中国的。美国评估师直属于SEI，属本地认证，所以说美国评估师进行评估具有说服力，信服力，对于中国软件企业而言，聘请美国的主任评估师，由于语言的不同，在沟通上存在一定的困难，在进行评估面谈沟通交流时，要配置专门的翻译。

三、工作准备

选择评估小组成员

本活动包括识别有用的职员、评定其资格和从中挑选人员作为评估小组成员。它可以发生在评估发起者做出管理评估活动的许诺之后，并能为评估计划保证提供输入。具体的行为包括：(1)、保证评估小组成员满足个人的最低标准;(2)、保证评估小组作为一个整体满足的最低标准;(3)、文档化在评估输入中小组成员的职责和资格。

SCAMPI评估可接受的评估小组最小规模是4个成员(包括小组领导者)。推荐的最大规模是9个成员。所有小组成员之前必须完成获得SEI推荐的并由SEI认可的权威授课者所教授的CMMI课程。小组成员必须接受有关评估方法的培训。关于工程领域的经验，评估小组(作为一个整体)平均至少要有6年以上的经验，且小组总的经验要不少于25年，这些规定都隐藏在评估活动中。关于管理经验，评估小组(作为一个整体)总的经验不能少于10年，且至少有1名成员拥有6年以上的管理经验。

总的来说，评估小组应该在评估组织内部所使用的生命周期里具有代表性的经验。在任何特定的生命周期阶段，评估小组至少应有两名成员具有从事这方面工作的经验。此外，必须保证，小组成员不应该成为任何特定项目的管理者或者成为任何预定被访问者的直接管理链中的一个。

组建准备评估小组

评估小组领导者有责任确保评估小组成员为执行计划的评估活动完成充分的准备。这包括熟悉在评估过程中将使用的参考模型、SCAMPI、评估计划、组织数据和特征、工具和技术以及为评估任务分配任务和职责。小组建立练习通常被用来实践简单的技能和在理解小组目标及如何取得满意上达成一致。所有的小组成员被要求遵守严格规则以保证机密性、保护所有者或敏感数据以及项目参与者未知的信息。私下陈述通常被用来达成这些谅解。具体的行为包括：

保证评估小组成员已接受参考模型培训;为评估小组成员提供评估方法培训或确保他们已掌握此方法;为评估小组和小组规范的建立提供服务;为评估小组成员提供关于评估目标、计划和他们自身分配的职责和任务的定位。

模型培训必须利用CMMI课程的权威标准来提供，并由CMMI办事机构权威认证的授课者讲授。方法培训可能通过下面两种方法之一进行： 针对即将到来的评估作明确性的方法培训;对大量的目前并没有从事任何评估工作的潜在的小组成员进行方法培训。

对一个完全重新组建的小组进行方法培训至少持续两天，且必须强调那些小组成员在评估过程很可能遇到的情况。本培训在SCAMPI的应用中没有必要包含所有的变量。针对潜在的将来的小组成员所进行的团体式方法培训必须包含方法上剪裁部分的所有内容和允许的变更以应付一系列在将来的评估中他们很可能会遇到的情况。SEI评估程序为那些目前不是评估小组成员的人们所得到的培训指定了额外的要求。那些在以前的评估小组中作为成员已接受过培训的小组成员，如果并没有进行目前的方法培训，那么他们并不自动地具有参加当前评估的资格。在这样的案例中，评估小组领导者要求了解以前的培训的本质和为即将到来的评估开展的培训足够多的内容。这需要对以前的评估和计划的评估进行比较。例如，假如小组成员使用连续表示法参与了一个仅集中在软件工程领域的评估，而计划的评估是使用阶段表示法集中在SE/SW/IPPD领域，那么该小组成员需要许多重要的新概念来覆盖。作为一个整体，评估小组至少产生一个结果来说明如何为即将到来的评估展开工作，建立小组规范和操作决议的目的。

参评单位准备 组织级QA 组织组CM SEPG小组 高级经理

委员会(项目与质量管理委会员、变更委员会)人力资源的培训 维护服务的准备 商务法律部

四、预评估

通过预评估判定企业是否准备充分可以进行正式的 SCAMPI/CBA-IPI。通过一位主任评估师指导进行，初步了解项目的成熟度，按照CMMI相关级别的KPA识别明显缺陷并推荐纠正措施，以便更好进行正式评估。主要工作包括组织级和项目组长的文档审阅及与项目组人员的面谈。评估结束，提交预评估结果并与组织进行有关讨论。选择参与正式评估的项目，在预评估的过程中，从公司全体项目中，挑选出项目参与评估，并不是所有项目评估。

在预评估过程中，评估师考核公司背景，项目角色涉及到是否覆盖所在的范围，核实参与项目覆盖与所申请的级别一致，如：既要有软件项目，又要有集成项目，是一个事业部，还是所有事业部的。查看实际情况与所申请的级别相符，如果相距太大，会劝说降低认证级别。主动参与评估师沟通，向他咨询本次评估的主要思想，增加通过评估的概率。

五、正式评估

第四阶段的目标是进行正式的 SCAMPI/CBA-IPI，时间通常是实施第一阶段培训后12个月(根据企业实施情况有所不同)。正式评估，获取证据，根据评估师的要求，与从项目中获取证据。评估的重点是组织内部实施的软件过程，涉及相关级别的所有KPA。

正式评估按照 SCAMPI/CBA-IPI 的要求进行，原来一般为 6 天，CMMI V1.2规定，正式评估时间不能超过10天，主任评估师提供自动评估工具帮助管理分析评估数据、编写评估结果。评估工作主要包括：

启动会议;公司高层，评估小组，参评方三方相关人员参与会议，介绍评估日程，达成一致意见。

评估方式：文档审阅，也称文审，查阅过程、项目书面文档。所有参评的文档都是要书面打打印，然后装订成册，供评估师审查。

面谈及讨论，评估师都要和项目中每个角色进行面谈，这些角色主要包括有：项目经理、需求人员、设计人员、测试人员、配置人员、质量人员。

评估小组总结

评估小组对文审、面谈中的数据进行综合与分析，生成评估结果。

总结及末次会议

CMMI软件 第3篇

CMMI是一套融合多学科的、可扩充的产品集合, 其英文全称为Capability Maturity Model Integration。该模型包含了从软件需求提出、软件设计、开发、编码、测试、交付运行到软件退役的整个生存周期里各个过程的各项基本要素;是软件过程的有机汇集, 旨在为软件组织改进其过程和提高其对软件产品或服务的开发、采购以及维护的能力中提供指导。

CMMI起源于三个模型 (源模型) , 分别是:软件能力成熟度模型 (SW-CMM) 2.0版, C稿, 电子行业协会临时标准 (EIA/IS731) , 集成产品开发能力成熟度模型 (IPD-CMM) v0.98。CMMI模型涵盖了四个学科:软件工程 (SW) 、系统工程 (SW) 、集成过程和产品开发 (IPPD) 、供应商管理 (SS) , 为跨部门、学科的过程改进带来更多的交流, 从而利于组织进行全局的过程改进。同时, 统一模型的过程改进 (不仅仅是软件过程能力) 提供更大的适应性和扩充性, 减少冲突和冗余。CMMI模型分为五个等级, 分别是:初始级、受管理级、已定义级、定量管理级、持续优化级, 目前多数企业推行的都是已定义级, 即CMMI3级。

2 CMMI与ISO9000的兼容性

长期的实践表明, 很多软件企业实施CMMI体系之前都建立了ISO9000质量管理体系标准, 在推行CMMI过程中许多企业会担心CMMI与ISO9000之间有冲突。其实不然, ISO9000和CMMI是当前两个最流行的质量保证体系, 它们同是适用于软件和集成产品质量保证能力评价的两个方法, 只是两者考虑的角度不同。虽然ISO 9000和CMMI有差异, 但两者的互补性很强, 它们在管理思想和管理意图上是基本一致的, 在建立和改进质量管理体系的时候, ISO9000和CMMI可以同时作为依据和指南。

(1) 在管理思想上, ISO9000和CMMI同样强调管理体系和过程的管理, 并在过程管理中, 强调接口管理。ISO9000和CMMI同样强调沟通, 强调全员参与, 应赋予各部门、各岗位人员应有的职责和权限, 激励他们的创造性和积极性, 通过教育和培训, 增长他们的才干和能力, 发挥员工的革新和创新精神, 共享知识和经验, 为员工的成长和发展创造良好的条件。

(2) 在满足客户需求上, ISO9000和CMMI同样重视顾客的需求, 它们强调, 体系的结构总是相对保守和稳定的因素, 而市场和顾客的需求则是相对活跃和变化的因素。为了使体系能适应于市场和顾客的不断变化的需求, 必须要求一个组织不仅应当满足顾客当前的需求, 而且应当理解顾客未来的需求和争取超越顾客的期望。

(3) 在持续改进上, ISO9000和CMMI同样强调有效的持续改进, 特别是在正常情况下, 也要加强持续改进, 以保证体系的有效性和效率。ISO9000和CMMI同样允许对组织的过程、产品进行裁剪, 强调了适宜性和有效性。

(4) 在测量与分析上, ISO9000和CMMI同样明确地提出收集和分析数据是为了识别组织可以实施的改进。而且还指出资料分析可以提供顾客满意度、过程和产品的特性及其趋势, 以及供方提供产品/服务的信息。充分地体现信息和数据是组织进行管理的基础思想。

从上面的比较可以看出, ISO9000和CMMI的思想是一致的, 所以对做过ISO9000认证的企业来说, 其体系的融合就是理顺两者关系, 建立相互补充的唯一的质量体系描述。

3 CMMI对软件企业的主要作用

IT企业在软件能力评价、软件过程评估和过程改进三大方面实施CMMI, 可以对其软开发过程进行管理和改进, 监督、检查正处于制作过程中的软件状况, 增强开发与改进能力, 了解自己的强项和弱项, 找出自己在软件开发过程中急需解决的所有问题, 从而能按时、不超预算地开发出高质量的软件和系统集成项目, 帮助软件企业不断完善和改进软件开发过程, 确保软件质量, 提高软件开发效率。增强企业的国际竞争能力。具体表现在以下几个方面:

(1) 能保证软件开发的质量与进度, 能对“杂乱无章、无序管理”的项目开发过程进行规范。

(2) 有利于成本控制。因为质量有所保证, 浪费在减少、解决客户的抱怨方面的成本会降低很多。现在绝大多数情况是缺少规范制度, 只是求快。项目完成后, 要花很多时间修修补补, 费用很容易失控。

(3) 有助于提高软件开发者的职业素养。每一个具体参与其中的员工, 无论是项目经理, 还是工程师, 甚至一些高层管理人的做事方法逐渐变得标准化、规范化。

(4) 能够解决人员流动所带来的问题。公司通过过程改进, 建立了财富库以共享经验, 而不是单纯依靠某些人员。

(5) 有利于提升公司和员工绩效管理水平, 以持续改进效益。通过度量和分析开发过程和产品, 建立公司的效率指标。

4 软件企业如何实施CMMI

4.1 实施规划

(1) 确立实施原则。CMMI的实施过程, 切记不能以通过评估为唯一目的, 必须以注重实效和循序渐进为原则。一是要结合企业实际情况, 优化项目管理流程, 起到实在的效果。二是要按照先试点再推广的实施策略, 先选择基础好、有代表性的项目进行试点, 在试点成功的基础上进行全面推广。

(2) 开展差异分析。项目开始时需诊断企业当前软件开发过程, 了解企业产品及项目的开发过程和特点;找出与CMMI要求的差距, 建立当前过程的基线, 识别过程改善风险, 验证企业现有的管理制度与作业标准文件, 选择过程改善模式, 制定出符合企业实际的过程改进行动计划。

(3) 制定实施方案。完成差异分析后, 企业还需针对自身的情况制定具体的CMMI实施方案, 包括组织架构、推进步骤、任务分解、工作计划、提交文件、沟通机制等, 并对实施方案进行论证和评审, 确保实施方案合理、可行。

(4) 强调全员参与。CMMI实施的过程是一个企业全员参与的过程, 要提高整个企业员工和项目实施人员对CMMI的认识, 企业内部需采用相关手段进行一定的介绍和宣传, 比如有企业内部开设一些CMMI文化长廊、工作论坛等途径宣传普及CMMI知识, 还可以举办了一系列的CMMI座谈会, 让全企业的人员参与到CMMI的建设过程中来。

(5) 建立实施工作组。CMMI的实施需要有强有力的组织保障, 因此需要成立领导小组和专业的工作小组推进相关工作, 这是一个关键步骤。企业需成立CMMI推广实施领导小组、EPG (工程过程组) 和QAG (质量保障组) 。CMMI推广实施领导小组由企业高层组成, 组长是企业主要负责人。领导小组负责协调资源, 全面推进CMMI实施推广的各项工作。EPG由企业各部门和开发团队的主管组成, 主要负责企业标准过程体系的建立和维护、制定和跟踪实施计划、组织相关培训、审批过程改进建议等。QAG由企业项目管理及质量管理部门人员组成, 负责对试点项目组进行体系实施释疑、定期检查项目过程的执行情况、对不符合项提出改进建议、收集过程改进建议等。

4.2 过程定义

过程定义就是将组织对软件项目实施过程的要求及经验、建议等进行收集并文档化, 最终形成组织的标准过程体系文件。

一个企业的过程定义工作主要是对原有的标准过程体系进行优化调整。标准过程体系优化是指以CMMI所有过程域的目标及实践为指导, 融合相关制度对项目实施流程、管理要求、软件项目的任务流程、执行角色、工作产品 (含模板) 进行完整的定义, 可以采用信息化的形式展现, 便于项目实施团队学习和浏览。标准过程体系是项目过程实施的依据, 为确保其合理、可行, 在定义完成后, 需在企业内部进行广泛的意见征集并做好深入的评审。

4.3 试点实施

根据循序渐进的原则, 企业应在适当的时期选择在业务领域、技术先进性和生命周期模型方面具有代表性的三个项目进行试点。试点期间主要工作包括以下几个方面。

(1) 明确岗位和职责。明确项目经理为实施CMMI的第一责任人, 确保试点项目按照企业标准过程体系的要求实施;每个项目设立质量经理, 作为试点项目CMMI实施工作的接口人, 负责与EPG和QAG沟通协调, 并负责检查本项目实施过程与产品的符合情况。

(2) 加强实施培训。在试点前, 需让参与三个项目实施的所有人员都参加CMMI的实施培训, 最好让EPG负责培训的实施。培训内容包括CMMI基础知识、标准过程体系、每个项目的经验分享、目前实施情况分析及问题解决等。

(3) 定期开展项目体检。根据体系相关要求, QAG制定了项目体检表, 每周对三个试点项目进行过程和产品检查, 发现项目实施过程与体系的不符合项, 并跟踪改进情况。

(4) 定期召开CMMI推进例会。由企业主要负责人主持, EPG、QAG和试点项目组成员参加, 分别汇报本阶段工作情况及下阶段计划, 提出实施过程中遇到的问题, 明确解决方案。

(5) 搭建实践经验分享平台。由QAG收集各项目的实践经验, 定期召集各项目QAG进行讨论, 分享最佳实践。

4.4 认证评估

在正式评估之前, 企业需对自己CMMI实施的过程进行一次预评估, 这是企业发现实施过程中存在的不足和感受正式评估过程的宝贵机会, 针对在预评估中发现的弱项和改进项, 及时采取积极的改进措施, 包括制定改进计划、加强体系培训、进行QAG工作辅导、加强项目组之间经验交流等, 为正式评估做好准备。

正式评估是依据CMMI框架进行, 由SEI授权的主任评估师为评估小组的组长, 对公司试点实施的相关情况进行审查, 并对参与实施的相关人员进行访谈。时间为7天左右。若评估通过, 主任评估师将会现场提交评估结果, 提出企业后续工作方向的意见建议等。

4.5 持续改进

CMMI的实施过程是一项长期细致的工作, EPG组织的工作模式和个人技能的好坏, 对公司日后软件过程实质性的改进影响很大。因此, EPG应长期存在, 并积极了解本行业标准和模型的最新资讯。评估活动结束后, 企业应严格按照CMMI的文件体系和标准流程执行, 企业也应该制定更高级别的改进行动计划。

5 在软件企业实施CMMI的主要体会

通过对几十家软件企业的咨询实践, 深深感到, 软件企业要想有效推行软件能力成熟度模型, 必须做到以下几点:

5.1 领导重视

领导的重视是实施CMMI的关键。实施CMMI是一个破旧立新的过程, 会改变现有的做法和原有的习惯, 这必然会遇到一定的阻力。只有企业的最高领导对CMMI知识及其价值有明确认识, 有实施CMMI的决心和信心, 才能排除阻力, 协调各方面资源, 制定有力的措施保障实施工作的正常推进。而各部门、开发团队主管、项目经理只有在清楚认识到实施CMMI是企业的意志、并不是个别部门的想法的情况下才会密切配合CMMI实施的相关工作, 这样试点及实施的各项工作措施才能得以顺利落实。

5.2 系统培训

培训工作很重要, 从实施前的宣传、全员的基本知识普及, 到对试点项目组成员的体系强化、模拟演练、QAG工作辅导、合作公司的经验交流等, 企业一定要将培训作为重要的工作来抓。通过对不同对象进行不同内容、不同形式的培训, 使企业和合作公司的每一个人都接受一次以上的培训, 从而使标准过程体系在企业得到广泛理解和使用, 提高项目实施人员对CMMI的认识, 形成了企业统一的质量文化。

5.3 紧密合作

各团队的密切协作不可缺失, CMMI实施不是一个项目管理部门的事情, 它需要全企业各部门的密切协作。其中, 推广实施领导小组对整体实施工作负责, EPG负责企业体系的建设、实施、过程改进, QAG负责过程实施辅导和过程及产品检查, 各项目组按相关工作要求落实各项工作。只有各团队各司其职、密切配合, 才能保障CMMI实施工作的顺利推进。

当然, 实施CMMI没有一套固定的模式和方法, 不同的软件组织应该根据自身的实际情况和具体要求, 采用不同的形式来实现CMMI的目标。CMMI实施和过程改进是一个持续而长期的过程。软件企业的项目实施过程也将一直正处于不断改进过程之中, 同时要不断完善CMMI的过程体系, 使软件过程符合更高的标准, 切实提高软件企业项目实施和项目管理的水平。

摘要：近年来, 我国资讯科技发展迅速, 特别是软件产业在政府的大力推动下快速发展, 随着软件企业数量的不断增多, 行业竞争越来越激烈, 为了提高软件开发效率、规范软件开发管理, 许多企业纷纷导入CMMI (Capability Maturity Model Integration) 作为软件质量流程评估标准来提升产品质量。本文结合软件研发组织贯彻CMMI的实际, 就如何抓住CMMI的精髓, 有效推行CMMI的软件项目过程管理, 切实提高软件开发能力和项目管理水平进行了阐述。

cmmi实施的个人总结 第4篇

文/质安部

一、心得感受

一年前，我开始了我的CMMI5旅程。顺境、逆境，坎坷的、平坦的，处处碰壁的死胡同、豁然开朗的桃花源，我们一路走来，风雨过后终见彩虹。

刚刚接触CMMI时，对基本术语的理解还很含混，感觉就像进入另一个工作领域。什么是PA，什么是CAR，什么是PPB和PPM，什么是Minitab、水晶球和蒙特卡洛，CMM与CMMI有什么区别，要通过CMMI5要哪些方面的工作，我们还有哪些方面需要改进，收集了一堆看似杂乱、不规则的数据，如何应用到项目中，并给项目带来实质性的效用，所有这些问题都要得以解决，在整个CMMI5实施过程中，我们从众多数据入手，分析并挖掘它们之间的关系，结合相关培训，在咨询顾问的指导下，我从略知一二到理解掌握了CMMI5的基础知识，并开始慢慢地理清思路。

其实学习CMMI5是个融会贯通的过程，而在工作中，CMMI5的思想又是触类旁通的，过程改进的思想在工作中、生活中各个方面皆可运用。我们将有用的数据抽离，并建立了基线和模型，在反复的实验中得到验证，用数据说话，指导项目实施。为了实现CMMI5，我们深入地参与到CMMI5试点项目中，实际运用基线和模型、数据和模板，在实践中不断完善表格模板和体系文件，规范项目实施工作和管理机制，并做好公司过程改进，组织相关培训，在公司自上而下落到实处。用实例证明我们的实力，成功地说服了主任评估师，最终华丽地完成CMMI5认证目标!

宝剑锋从磨砺出，梅花香自苦寒来。历尽千辛，最终尝到甜头，这次的胜利可以说是我职业旅途中的一座里程碑。前方还有很长的路要走，持续的过程改进还在继续，我也会保持CMMI5工作的劲头，坚定地走下去!

二、基线建立

基线建立的前提是公司的项目管理过程趋于稳定，项目过程数据趋于可控。基线反映了公司的过程性能能力。我们是用Minitab工具以控制图的方式做出基线的，需要注意的是： 控制图中的异常点不能随意删除，需进行根原因分析;

表现差异较大的项目不能放在一起，应分类做出基线;

项目经理在制定项目目标时，应参考组织级基线，结合项目特性确定本项目的目标; MiniTab的I-MR图对数据的检验规则如下：

1) 1个点距离中心线大于3个标准差

2) 连续9个点在中心线同一侧

3) 连续6个点，全部递增或递减

4) 连续14个点，上下交错

5) 2个点中有1个点，距离中心线(

同侧)大于2个标准差

6) 4个点中有3个点，距离中心线(同侧)大于2个标准差

7) 连续15个点，距离中心线(任一侧)1个标准差以内

8) 连续8个点，距离中心线(任一侧)大于1个标准差

三、模型建立

3.1模型建立的八步骤：

(一) 获取组织目标

1) 获取商业目标：结合往年的市场投入、同行竞争力分析得出当年的商业目标。

2) 量化组织绩效目标：从商业目标出发，采集目标分析法，逐步分析出关键的组织绩效目标。(确定目标)

(二) 比较当前基线与组织绩效目标的差距

1) 采集上一年的历史绩效数据：以组织绩效目标为基础，采集上一年的绩效数据，并分析出基线。

2) 假设检验分析差距：用假设检验的方法分析当前过程能力与组织绩效目标的差距。

(三) 分析影响目标的因素(大鱼-中鱼)

1) CAR分析影响目标的因素：采集与组织绩效目标有关的项目数据，对每一个数据的表现进行原因分析，并逐层找出根原因(确定因子1)。

2) 头脑风暴分析影响目标的因素：组织公司内核心人员进行讨论会议，以头脑风暴的形式讨论出影响因素。

3) 投票选择：对上一步头脑风暴产生的多个影响因素按照一定的规则，投票选择产生强相关的影响因素(确定因子2)

(四) 分析上一年的性能基线(采集中鱼)

1) 采集上一年历史性能数据：根据上一步确定的因子，采集该因子的上一年项目数据。

2) 形成上一年历史性能数据基线：用I-MR图的方法形成因子的性能基线，对异常点需进行根原因分析。

(五) 相关性分析关键因素(中鱼-小鱼)

1) 相关性分析：用Pearson(柏松)系数方法，分析因子1、因子2与目标的相关性，相关性强的因子可用于回归模型的建立。

2) 关键子过程的改进计划(矩阵)：对小鱼、中鱼、大鱼所有的因子，找出对应的关键子过程，并依次按照高、中、低的优先级顺利，计划改进周期。

(六) 建立性能模型

用统计分析工具Minitab>>统计>>回归>>回归,“响应”设定为目标值，“预测变量”设 定为因子后，可得出回归方程。

(七) 达成目标模拟

1) 水晶球分析：用水晶球工具Crystal Ball(蒙特卡洛原理)分析模拟出，当前过程能力对目标达成的Certainty值，以及改进因子后对目标达成的Certainty值。

2) 引入革新点和改进措施：从数据层面，分析因子的历史数据中，可改进的空间，并引出改进措施。(需启动DAR确定革新点)

(八) 引入革新点的成本效益分析

1) 成本分析：预测出实施革新点的各项成本(如资源、人力、开发、维护、推广等)，并将成本数据进行量化。

2) 预计收益分析(可节约成本)：预计实施革新点后，可收获的价值。(如成本降低、绩效提升等)

CMMI软件 第5篇

(一) 项目描述

项目描述主要是对项目背景交待;项目开发周期、各项计划安排恰当;开发环境、技术选型合理。指导学生应考虑的问题包括:

1. 开发环境需求:

选用不同软件开发环境的成本是不一样。

2. 开发周期:

人员的调配, 设计人员的需求, 开发, 测试, 监控, 每个功能需要时间, 成本估算, 进度估算。

3. 需求采集:

WBS, 功能描述, 规格说明书, 用例图。

4. 需求分析:

业务流程图, 基本业务框架, 写用例的前置, 后置。重点在关键业务, 足够分析, 不然会影响进程 (风险评估) 。界面原型图, 理清思路的方法。用户看了上面的, 希望加东西, 那么, 经过开会, 建立需求, 变量机制, 要用户确定签字。客户提供足够资料, 因为开发组不了解客户。客户提供充分资料, 一定的时间就提供。这个介入要找准时间点, 不早不晚, 向客户什么时候介入, 向软件公司经理提出什么时候收钱。有一些软件可以保证监控。

航空公司管理信息系统项目描述阶段:

(1) 项目背景

一个正常营运的航空公司需要管理所拥有的飞机、航线的设置、客户的信息等, 更重要的还要提供票务管理。面对各种不同种类的信息, 需要合理的数据库结构来保存数据信息以及有效的程序结构支持各种数据操作的执行。

(2) 项目规模与开发周期

1) 开发规模:3人, 12天

2) 开发周期: (1) 项目说明:4小时; (2) 项目系统分析 (系统分析, 系统分析评审) :1天4小时; (3) 项目系统设计 (系统总体设计, 系统功能设计, 系统业务流程设计, 数据库设计, 界面设计, 系统设计评审) :2天4小时; (4) 项目实施 (客机信息管理模块开发, 航线信息管理模块开发, 客户类型管理模块开发, 单元测试, 舱位信息管理模块开发, 客户管理模块开发, 订票信息管理模块开发, 单元测试) :5天; (5) 系统测试 (集成测试, 验收测试, 系统发布) :2天。

(3) 开发进度安排通过甘特图来控制。

(4) 开发环境 (包括操作系统环境、硬件环境和网络环境) :软件环境:操作系统Windows2003/开发工具VS2008;硬件环境:奔腾III 1.0GHZ以上处理器, 512M以上内存;网络环境:局域网。

(5) 开发技术要求 (包括开发技术、技术架构、数据库管理系统) :采用B/S体系架构的网络应用系统;开发技术采用C#面向对象编程+ASP.NET技术;技术架构采用三层架构, 即客户端---服务器---数据库;数据库管理系统采用SQL Server 2005数据库。

(6) 各阶段应交付的内容:调研阶段:调研报告 (标书或方案书) ;需求分析阶段:需求分析报告、系统原型;系统设计阶段:开发计划、系统设计说明书;软件开发阶段:可安装软件、安装手册、用户手册、培训手册;交付阶段:可安装软件、源代码、安装手册、用户手册、培训手册、结题确认;运行、维护阶段:维护报告。

(二) 项目设计

项目设计阶段主要体现多层架构思想;架构设计能体现安全、稳定及延展性;系统流程清晰, 符合客户方需求;数据库设计合理而有效;模块划分符合软件开发规范。指导学生应考虑的问题包括:技术选型:什么时候选用合理的技术;开发难易程度, 人员配备能力成本;关键技术研究, 这一点会直接影响到进度。数据库设计:表与表之间的关系, 一定要表示, 通过power design, 合适的数据库设计工具。冗余要进行评估, 适当的数据冗余是必要的。航空公司管理信息系统项目设计阶段:

1. 系统采用B/S架构思想开发系统

2. 系统功能分析。航空公司管理信息系统需要完成功能主要有: (1) 舱位信息:舱位信息的增、删、改。信息包括:舱位等级编号等信息; (2) 客机信息:客机信息的增、删、改、查。信息包括:客机编号和型号等信息; (3) 航线信息:航线信息的增、删、改、查。信息包括:航线编号、航班日期等信息; (4) 客户类型信息:客户类型信息的增、改、查。信息包括:客户类型编号等信息; (5) 客户信息:客户信息的增、改、查。信息包括:客户编号、客户姓名等信息; (6) 订票信息:订票信息的增、删、改、查。信息包括:订票编号、客户编号等信息。

对上述各项功能进行集中、分块, 按照结构化程序设计的要求, 形成系统功能模块。系统数据库设计, 仔细调查分析航空公司管理信息需求的基础上, 将得到如图1所示的系统的数据流程。

(三) 项目实施

项目实施阶段主要体现有版本控制;代码编写规范有明确要求;有项目开发的进度控制策略;体现软件开发QA思想。指导学生应考虑的问题包括:开发和测试中, 规范是一个标准, 让开发人员有方向做。开发的积累, 不需要都去开发, 形成相形的DOC文档。开发习惯, 新人如何适应, 简单模块, 中等难度的模块, 统一的规范。数据库变量的机制, 任何数据库的变更会影响到很多的代码, 任何人不能改数据库。

1. 系统实现运行

完成的功能模块的创建, 实现系统运行。如图2所示实现系统运行业务流程。

2. 编码的规范性

在整个代码开发过程中, 代码规范应贯彻整个。包括有:标示符命名规范, 统一的命名规则。标识符的命名要清晰、明了, 有明确含义, 使用完整的单词或大家基本可以理解的缩写;对所调用函数的错误返回码要仔细、全面地处理。明确函数功能, 精确 (而不是近似) 地实现函数设计;常用类型声明规范;源程序中有效注释量必须在20%以上, 注释的内容要清楚、明了, 含义准确, 防止注释二义性。文件头部应进行注释, 列出:版权说明、版本号、生成日期、作者、内容、功能、与其它文件的关系简要说明。

3. 项目开发的进度控制策略

(1) 在项目组内建立VSS配置服务器。每个项目参与者每人一个VSS帐号, 每天下班前将自己做的东西 (文档, 源泉程序) 存入VSS服务器中, 每天上班后从VSS服务器中下载自己的源程序。

(2) 项目参与人必须使用周报系统每周汇报自己的工作情况, 项目负责人根据参与人的汇报在每周的例会上与其进行沟通, 了解项目的实施情况, 做出相应的调整。

(3) 每个重要阶段评审或者单元测试后由项目经理发布成基线。成为基线后, 若需要修改则要进行专家评审, 并进入变更管理。

(4) 若需要修改的问题太多, 经过专家评审, 需进入版本升级阶段, 进行大问题修改, 并有新的版本生成, 例2.0版, 3.0版。

4. 系统测试

系统测试阶段采用V模型测试, 包括:单元测试, 集成测试, 系统测试。

从开发过程的用户需求进行验收测试, 到需求分析和系统设计的确认测试和系统测试, 然后概念设计的集成测试, 再到系统详细设计和编码的单元测试。左边依次下降的是开发过程各阶段, 与此相对应的是右边依次上升的部分, 即各测试过程的各个阶段。

系统测试时的测试用例 (如下表1) :测试用例 (Test Case) 是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果, 以便测试某个程序路径或核实是否满足某个特定需求。

(四) 系统维护和发布

1. 系统发布。

使用VS 2008的发布功能直接发布系统, 这样的发布方式还需要手动安装framework等。在VS 2008中建立制作安装包的工程, 将web程序打包到Setup程序中, 并自动检测是否按照了framework、语言包等。数据库设计报告可以使用PowerDesigner来自动生成。程序说明文档可以使用NDoc来自动生成。

2. 系统维护, 对于每次发现的Bug必须记录, 并说明修改的方法和修改的部分。

使用专门的Bug管理程序TestTrack, 可以高效的纪录和查询Bug的描述及其处理方法.为项目的维护打下基础。

3. 系统试运用和技术支持, 系统正式发布后将试运行一个月, 对于此间用户需求的更改要求做出更改说明书, 并经过用户的确认。

试运行后将有半年的免费技术支持时间, 解决此间用户发现的问题并一一记录和确认。系统的更新使用局部更新的方式, 解决问题时找到影响和改动最小的方案, 编译后只对影响的dll和文件更新即可。每次改动必须记录修改的时间和修改代码的位置。每个新的版本的发布需要在VSS中做标签来区分, 并且将发布的版本做出一个分支, 并对改动做出说明。

4. 开发中的辅助工具, 在系统开发过程中, 适当的使用一些辅助工具, 将有助于系统的开发。

(1) MSDN (Microsoft Developer Network) MSDN库涵盖了微软全套可开发产品线的技术开发文档和科技文献 (部分包括源代码)

(2) Visual Assist X Visual Assist X能自动识别各种关键字、系统函数自动标示错误等, 有助于提高开发过程的自动化和开发效率。

(3) MS VS2008 web Deployment Projects MS VS2005 web Deployment Projects编译插件能够更加方便地实现Web工程的部署定制。

(4) PowerDesigner PowerDesigner制作数据流程图、概念数据模型、物理数据模型。

(5) TestTrack利用TestTrack进行Bug管理及追踪。除了使用辅助工具提高开发效率外, 在系统开发过程沟通也是非常重要的, 无论是开发组内部的, 还是和客户的外部沟通。

(6) 内部沟通, 可以使用QQ, MSN, 邮件 (把任何信息都可以落实到邮件) , wiki, 百度百科, 工作日志:大家的知识共享, 工作日志把项目需求变更记到wiki。

(7) 外部沟通:邮件 (有效, 合法备份) 需求, 过程, 跟客户的沟通有邮件确认。需求变更确认机制。

摘要：文章探讨了指导高职院校学生基于CMMI进行软件项目设计与实施。项目式教学作为教学改革的一个环节。通过基于CMMI进行的软件项目开发过程, 使学生能够体验到什么是基于CMMI软件项目开发方法, 在以后的实际工作中也能较快进入软件开发过程。

关键词：CMMI能力成熟度模型集成,软件项目式教学,软件开发过程,项目设计阶段,项目实施阶段

参考文献

[1]Jeffrey L.Whitten System analysis and design methods[M].McGraw-Hill Companies, 2003.691.

CMMI软件 第6篇

在计算机软件工程方面,质量常常被视为系统内部部件或系统过程中满足的以下两个要求:(1)明确的需求。(2)客户或用户对系统的需要或期望的程度。更为重要的是,软件产品的质量往往是软件工程的核心所在[1]。可是,目前在软件工程中还没有形成完整且统一的软件质量的概念,而目前比较权威的观点则认为质量满足有以下四种条件:首先,软件质量需要集合计算机系统稳定和卓越程度的所有属性;其次,软件质量需要集合软件产品中满足明确需求程度的属性;第三,软件质量需要集合软件产品的明确或隐含的需求能力的特性或者特征;最后,软件质量需要满足在质量定义中客户明确指出的需求[2]。

综上所述,软件质量需满足以下三个特性:(1)软件需求成为度量软件质量的基础。(2)软件质量是一种难以定量度量的属性。(3)软件质量需要同时保证客户的明确需求和隐含需求。

2 软件的质量管理(Software quality management)

而软件的质量管理则包括执行确定的质量政策、目标与职责过程相关的活动,进而使待完成的项目满足一开始制定的需求。随着各行各业中信息技术越来越广泛的使用,软件质量受到了越来越多的关注和重视。因此,软件质量的好坏与否已经越来越成为公司能否生存的核心竞争力之一。而这种决定企业生存的竞争力除了体现在多样的产品类型和先进的产品功能上外,更多的竞争力则体现在产品是否具有可靠且稳定的质量保证上。随着目前信息科技在社会日常需求上的发展,软件被应用的领域在进一步被细化。随之而来的则是进一步复杂的设计程度,以及不断被要求缩短的软件研发周期。只有软件具有的质量和服务在制定之处就以利润最大化和质量最优化为市场导向,才能将软件具有的市场价值最大化[3]。

而目前有很多能够影响软件质量的因素。首先影响软件质量的管理学因素主要有软件执行的正确性,软件的健壮性,软件运行的效率,软件的安全性和可用性,软件运行的风险,软件执行的可理解性,软件本身的可维护性和适应性,以及软件的可移植性和可再用性等因素。而软件的复杂性这个属性则决定了必须由相应固定的标准来保证软件质量,从而形成了完整统一的软件质量保证体系。

3 软件的质量保证(Software quality assurance)

软件质量保证(Software Quality Assurance,SQA)也往往具有不同的定义。目前比较权威的定义是:软件质量保证是软件质量评估和度量的一个功能单位,其包括过程和产品的保证。它的基本任务是确保软件项目履行的过程中对产品和过程的承诺。在整个软件的开发过程中,软件质量保证应该一直贯穿其中,且在该过程中软件不会被耗损,这是与硬件系统最大的不同。因此,在软件交付使用之后,该软件的可用性不会随着时间的流逝而改变,具有相当的稳定性[4]。

针对软件质量保证的软件质量管理体系是标准化组织经过长期的研究和实践逐步演化和制定的一整套适用于软件管理的理论体系。它的目的是对质量管理过程进行规范,使得软件质量管理有据可依。目前在国际社会中有两种被广泛采用的软件质量管理体系分别是ISO9000和CMM/CMMI。前者是集合了国际标准化组织的现代管理学理念的精华部分,并合并了ISO9001、ISO9002和ISO9003三种标准,进一步将PDCA戴明环闭环管理模式引入其中,同时把持续改进的思想引进并贯穿于整个软件质量管理标准,从而建立一种可持续改进的结构。后者ISO9001:2000则为各种机构和组织提供了软件质量管理的另一种切实可行的方案,并以体系化模式来管理软件组织的质量,该体系把“以顾客为中心”和“持续改进”的理念彻底贯彻到标准中,以拥有持续满意的顾客为目的,从而使软件质量和软件服务更好地满足顾客的期望值。

4 基于CMMI的软件质量保证(On software qualityassurance of CMMI)

软件能力成熟度模型集成(Capability Maturity Model Integration,CMMI)是软件能力成熟度模型(Capability Maturity Model for Software,CMM)模型的最新版本。CMMI可以描述组织软件过程的能力,其核心是将软件开发过程花,并对软件开发和维护进行监控和研究,使其满足标准化,科学化的要求,帮助企业实现更好的商业目的。在实际的执行过程中CMMI将能力成熟度划分为五个等级,分别是:初始级、已管理级、已定义级、量化管理级和优化级。这个五个等级中的每一个级别都将构成下一个级别的基础。CMMI被公认为是软件产品进入国际市场的通行证,它为改进软件组织的过程提供了一种单一的集成化框架,消除了模型之间的差异性,减少了各类模型的重复劳动,增加了软件的透明度和理解,从而建立了一个自动的并可扩展的框架,并从总体上改进软件组织的质量和运行效率。因此,有效实施地CMMI可以有效地提升软件开发项目的成功率,进一步降低软件开发风险和成本,并提高产品的质量,使得企业的竞争力在根本上得到提升。在目前看来,有两点原因促使企业实施CMMI,其一是为适应市场需求,特别是提升企业在投标活动中通过CMMI门槛的概率;第二个方面出于有效管理的目的,通过CMMI的顺利实施来对组织内部的管理进行改进,从而有效提升组织的工作效率。迄今为止,CMMI主要被应用在软件能力评估和持续过程改进这两大方面。

在实际的操作过程中,开发人员的素质和团队管理能力则往往更多地决定了软件质量,而在大型软件开发的项目中,主要体团队的总体能力又体现在软件开发人员的能力上。而软件开发过程中的控制力和自我改善能力又决定了软件的成熟度,其对软件的实际开发质量起到了至关重要的作用。因此,只有不断的加强软件开发成员团队素质的管理,才能更好地建立有效且稳定的软件开发过程,进而达到对软件开发质量的控制,以更好地保证软件的开发质量。

以上的描述主要从理论上阐述了基于CMMI的软件质量保证的概念与理论,为了更好地诠释基于CMMI的软件质量保证,本文将进一步从工程实际出发描述软件质量保证的实际操作。

5 基于CMMI的软件质量保证的实际工程操作(Thepractice of software quality assurance of CMMI)

在软件开发项目立项后,需要首先任命一名该项目的测试负责人。该测试负责人需要具体负责项目测试的相关文档,测试进度,测试质量,测试过程的管控。进而在软件测试开始前,团队的开发人员需要首先熟悉产品需求规格说明书,产品开发计划和产品详细设计等准备工作。

在熟悉产品需求规格书方面,测试人员应该参与产品需求规格说明书的审核,产品需求规格说明书完成后,需求人员应以邮件方式及时发送给测试人员,避免在产品开发完成提交测试时才告知测试人员。当开发过程和测试过程中发现需求定义有问题的,开发人员和测试人员都只能向需求人员提出问题,当需求出现疑义时,必须由需求人员与客户沟通确认,并更新需求规格说明书。在产品开发计划方面,在确定开发人员提交测试版本的时间时需要开发负责人签字确认,开发人员在提交测试版本同时给出测试说明,测试说明包括本测试版本已知重要问题,未完成功能(如果存在),测试建议等。在产品详细设计方面,对于软件项目的需求,开发人员提交测试版本时同时提交该需求的产品详细设计,内容包含开发人员为实现需求,所做的改动,新增的功能,删除的功能等说明。同时其他项目的产品详细设计内容,见软件开发流程中产品详细设计的相关说明。在整个准备过程中,开发人员、测试人员和需求分析人员需要保持充分积极的沟通,以保证所设计出的软件能够体现客户的真正需要。

在软件的设计过程中,需要详尽地将整个软件设计过程分成若干可执行的阶段,确定好每阶段的时间节点和完成需求,保证每一个阶段的充分可执行性。在完成软件设计后,测试团队需要根据最初的设计制定完备的测试需求并搭建测试平台,编写测试计划,完成测试用例审核和测试人员评估,最后在测试的完成阶段做好详尽的测试报告以备客户查询。

总之,软件的设计与测试的实际操作是一个严丝合缝并环环相扣的过程。

6 结论(Conclusion)

基于CMMI的软件测试是一个庞大且详细的框架体系,其对软件质量的保证和企业市场的扩大有着非常重要的促进作用。而基于CMMI的软件测试需要整个设计和测试团队的密切配合和积极沟通,其实际操作具有相当大的探讨空间。

摘要：软件质量保证是当今软件行业一个值得关注的重要问题。软件的质量则直接关系到用户的生命和财产安全。而在实际的工程应用中,软件质量的优劣与软件工程过程的合理与否有着密切的关系。本文从理论和实践两个角度详细阐述了基于CMMI的软件质量保证过程,从而实现了基于CMMI的软件质量保证的定量和全面的质量管理。

CMMI软件 第7篇

1. 项目管理与质量概述。

项目管理就是以项目为对象, 通过一个临时性组织, 运用知识、技能、工具和方法, 对项目进行高效率的计划、组织、指导、控制, 以实现项目目标的综合协调与优化过程。

质量是产品的一组固有特性稳定地满足用户需求的程度, 具有经济性、广义性、时效性和相对性。对于项目管理而言, 过程质量和质量管理体系质量更为重要, 只有这两种质量保证了, 产品的质量才能保证。

2. 软件项目质量管理概述。

(1) 软件项目质量管理的概念。软件项目管理是20世纪70年代中期美国国防部针对软件产品不能按时提交、软件开发的预算严重超支以及软件的质量达不到预期的原因等问题提出的。软件项目质量管理的目的是为了让软件项目的生命周期都能在管理者的控制之下, 以达到软件质量符合用户明确或隐含的需求。

(2) 软件项目质量管理的内容。为了开发出符合质量要求的软件产品, 贯穿于软件开发生存周期过程的质量管理工作, 包括建立对项目的软件产品实现的特定质量目标、制定达到这些目标的计划, 监控并调整软件计划、软件工作产品、活动及质量目标以满足最终用户的需要。软件项目质量管理的过程一般包括:软件项目质量计划编制、质量保证、质量控制等。

二、软件项目质量管理的必要性

1. 软件项目质量管理的重要性。

软件属于纯知识产品, 完全是人们大脑思维的产物。其开发的进度和质量很难估计和度量, 生产效率也难以预测和保证。此外, 软件质量不达标, 不仅会增加后期的管理经营与维护成本, 还可能会引起难以预料的后果。软件项目管理质量先行, 如果我们能够控制软件生命周期每一个阶段的质量, 就能很好地控制软件开发的整个过程。

2. 软件质量的影响因素。

软件能力成熟度模型的重点是从组织管理方面研究评估软件生产过程, 从而提高软件质量。软件业经过多年的实践总结, 得出软件质量是人员、过程和技术的函数, 即Q=f (M, P, T) 。其中, Q是软件质量;M代表人员;P代表软件生产过程;T代表技术。从项目管理的角度看, 影响软件质量的结构因素即组织管理、项目的过程管理和技术工具的使用。

3. CMMI软件质量认证体系。

CMMI (Capability Maturity Model Integration, 即能力成熟度模型集成) 认证是由美国软件工程学会 (software engineering institute, 简称SEI) 制定的一套专门针对软禁产品的质量管理和质量保证标准。近年来, 很多软件企业纷纷实施CMMI管理模式, 如东软、华为等企业已通过了三级或四级评估。CMMI技术不仅能够提升企业的管理水平, 还能够引入科学的管理理念, 提升企业的整体管理水平。

三、基于CMMI的软件项目质量管理改进建议

1. 软件项目需求管理过程改进。

软件项目经理应组织相关人员制定需求计划文档, 从项目质量管理的整体角度及时掌握用户需求信息。为了管理分配需求, 项目开发过程应该遵循一个书面的约定或组织策略, 其内容包括: (1) 为了在开发过程中有章可循, 要为分配需求建立文档; (2) 为了使分配需求能切实可行, 必须由软件经理和其它受影响组成员进行审查; (3) 当分配需求变更时, 软件计划、工作产品和活动也要随之更改。

2. 软件项目计划执行过程改进。

软件开发计划 (SDP, Software Development Plan) 是关于软件项目的策划、建议与评审、确定易于管理的软件生命周期。在此过程中, 需要编制软件进度表、软件风险的鉴别与估计、制定项目软件工程设施和支持工具的计划以及软件策划数据。在执行项目生命周期过程中分别进行概要设计和详细设计, 并针对各个环节上出现的问题进行评审, 有利于提高整体质量。

3. 软件项目监督控制过程改进。

项目经理及相关人员应制定好质量管理的规章制度或计划, 从技术和管理两方面, 由质量监督人员进行定期的质量检查和不定期的抽查, 严把质量关, 预防不合格品的产生。首先, 要明确规定好项目经理和项目小组成员的角色及其职责;其次, 要对项目进行实时跟踪, 掌握项目的实际实施情况。此外, 项目经理还应该定期召开项目阶段评审会议及时发现问题, 总结经验。

四、总结

本文结合项目管理的理论知识, 介绍了企业软件项目质量管理的内涵及重要性;着重以软件能力成熟度模型CMMI为指导, 分析改善软件项目质量的管理活动;并提出了项目实施各过程的改进建议。

参考文献

[1]马慧, 杨一平.《软件质量管理与认证方法》[M].北京:清华大学出版社, 2011.

[2]瞿焱.《项目质量管理》[M].杭州:浙江大学出版社, 2004.

CMMI软件 第8篇

军事气象水文保障工作的日益发展,对军事气象水文保障的实时性、精确性和综合性的要求越来越高。保障水平的高低很大程度上依赖于气象水文装备质量的优劣,而软件在气象水文装备系统的研发过程中起着神经中枢的作用,软件质量的好坏关系到气象水文装备的效能能否有效发挥,关系到军队战时能否充分应用气象水文条件。因此根据气象水文软件的特点研发高质量的软件是实施正确的作战指挥,取得作战胜利的重要前提之一。

1军事气象水文软件特点

(1)政治性。军事气象水文软件的质量关乎国家军队的根本利益,这就要求软件研发人员要始终保持高度的政治敏感性和觉悟,并保持高度的事业心和责任心。

(2)秘密性。军事气象水文软件是整套装备系统的神经枢纽,关乎到国家的安全,必须具有一定的保密等级。

(3)及时性。普通软件的研发往往因为一些意外情况导致项目进程的滞后,但是由于军事气象水文软件的军事属性,要求软件的研发必须按时交付。

(4)精确性。军事气象水文软件是战时军队了解、运用气象水文条件的工具,必须能为军队提供具有代表性、精确性的气象水文资料,不能有丝毫的差错。

军事气象水文软件的特殊性对软件的研发提出了更高的要求。目前,气象水文软件在研发过程中存在诸多问题,导致软件的质量不尽人意,特别是与硬件的可靠性相比,软件的可靠性有待提升。

2军事气象水文软件开发中存在的问题

(1)软件开发进度难以控制。在军事气象水文软件开发过程中,经常出现资源匮乏、人员流失、资金不到位等情况,导致软件开发难以按计划实施,往往后期为了能按时交付不顾质量好坏而加快进度。

(2)软件研发成本日益增长。随着计算机市场化和民用化进程的加速,软件开发成本不断增加。在硬件成本不断降低的情况下软件成本在整套装备系统中所占的比例越来越大,通过牺牲软 件质量来 缩减成本 的情况日 趋明显。

(3)软件交付后难以维护。软件交付并不意味着开发工作结束,软件本身隐含的一些错误只会在某些特定的情况下才暴露出来。随着时间的推移,用户需求及软件的运行环境也会发生变化,从而导致软件的可靠性大大降低。

上述问题是军事气象水文软件研发中普遍存在的现象,亟待改进。要解决上述问题,最根本的一条是必须“树立软件产品质量 观念”和“用软 件工程方 法组织软 件开发”[1],并按照软件工程方法的基本原则不断改进软件开发过程。目前,国内控制软件质量比较常用的方法是采用质量管理体系。

3军内软件质量控制方法及其缺陷

目前,军用软件 研制质量 控制模型 源于GJB9001B《质量管理体系要求》,该标准明确了军用软件立项论证、设计、研制、生产、试验、审查、维修的质量管理体系,并为实施质量管理体系的评定提供了依据,推动了军工产品质量管理体系建设的迅速发展,促进了军用产品质量与可靠性水平的提高。对于软件的设计和开发,GJB9001B强调“按软件工程方法,设计和开发计算机软件”[2]。通过强调过程,将组织内所有的工作定义为明确的过程进行质量保证和评估,使影响软件产品质量的因素在产品形成的全过程中始终处于受控状态,以此来提高其使用的可靠性、安全性,将持续改进作为提高质量管理水平的重要手段[3]。

仅依据GJB9001B《质量管理体系要求》模型来控制军用软件的质量存在一定缺陷:1GJB9001B主要针对硬件、软件、流程和服务类产品,是由制造业的质量理论和实践总结发展而成,不可能针对软件产品及其制造的特点展开说明,尤其是在型号不断改进,装备状态的多次更改之后,对军用软件的配置管理等更高层次的问题缺乏行之有效的指导;2各组织在 实施该标 准时没有 引起足够 的重视,认为不发生安全事故就万事大吉,对质量没有提出更高的要求,忽略了该标准反复强调的“必须持续进行质量改进”[2],研制单位缺乏一套适用的质量管理体系;3GJB9001B评估的目的是认证组织是否建立了有效的质量管理体系,给出简明、科学、原则性的要求,评估结论只是合格与否,无法找出软件研制过程中的强项和弱项,不能就软件开发过程给出详细描述,对能力提高不能指出简明科学途径。

军事气象水文软件质量控制中应用质量管理体系,采用过程模式,将软件质量的持续改进作为控制软件质量的重要手段,具有深远意义。但仅运用该模式难以使软件质量控制有质的提高,提出一种新的军事气象水文软件质量控制方法势在必行。

4基于 CMMI的军事气象水文软件质量控制方法

4.1CMMI软件质量控制思想

CMMI(CapabilityMaturityModelIntegration)即能力成熟度集成模型,由美国卡内基·梅隆大学的软件工程研究所提出[4]。它采用了质量管理体系的过程管理思想,将软件开发视为过程,对软件开发和维护过程进行监控和研究,使其更加科学化、标准化,使企业能够更好地实现商业目标;从集成产品与过程发展的角度出发,建立起包含健全系统开发原则的软件过程改进模型。

CMMI侧重软件过程开发的管理及软件工程能力改进与评估[5],它的本质是通过软件研制过程中关键过程域的精确定义,使软件研制从一 个不确定 的“黑箱”操作过程,变成一个各步骤可视化、偏差可随时控制的“透明”操作过程[6]。消除不同模型之间的不一致和重复,以系统和一致的框架来指导组织改善软件开发过程,降低成本。因此,它被广泛应用于软件开发能力评价并帮助组织改善软件开发质量,是目前国际上最流行、最实用的软件生产过程标准和软件企业成熟度等级认证标准。

4.2基于 CMMI的军事气象水文软件质量控制模型

军事气象水文软件开发程序一般分为问题定义、需求分析、总体设计、详细设计、程序编码和软件测试与评估6个步骤。本文将CMMI中关键过程域与军事气象水文软件开发的一般流程相 结合,提出一种 新的质量 控制模型(见图1)。

基于该模型,军事气象水文软件质量监控过程如下:

(1)问题定义。本阶段主要任务是对软件需求进行论证,以确定软件开发的目标及可行性。

(2)需求分析。本阶段通过需求管理和需求开发两个关键过程域对软件需要实现的功能进行分析,选定适当的规范,通过与客户交流制定软件质量大纲实施计划。在软件开发全过程中进行需求跟踪和需求验证,将跟踪和验证的结果及时反馈给客户,确保客户需求得到满足。

(3)总体设计。根据GJB9001B的总体要求,通过项目策划对软件项目进行整体规划。总体设计是软件项目管理的基础,没有切合实际的计划就不可能有效进行项目管理。质量控制的任务是通过估计软件产品的规模及所需要的资源,制定时间表,评估软件风险;根据客户需求、GJB9001B以及CMMI总体要求编写软件总体设计说明。

(4)详细设计。通过配置管理、过程与产品质量保证、项目监督与控制3个关键过程域对项目进行全方位设计。对项目进行全程监督和质量控制,实现项目进展可视化。更改配置必须遵循软件更改规范,更改后必须进行测试和验证;及时发现项目计划偏离,并采取有效措施进行调整,并最终形成相应的文 档;质量管理 部门通过 评审过程 文档,依据CMMI识别软件开发过程中的强项和弱项,针对性地开展工作,保障软件质量。

(5)程序编码。将软件设计的结果转化为计算机可运行的程序代码,进行程序静态分析和单元测试,并编写软件使用说明。严格软件配置管理,确保编码中所有工程活动在CMMI的框架下进行。根据程序单元测试规程进行源程序走查和单元测试,测试完毕后提交测试报告。

(6)软件测试与评估。通过测量分析与验证两个关键过程域检验软件能否满足客户需求。通过文档审阅、代码走查、数据整合和验证进行阶段评审,生成评审结果草案;通过阶段性文档审阅,数据整合和验证检查本阶段的工作是否满足质量要求和技术指标,进而作出决策是否可以进入下一阶段。软件研制成功后,通过内部测试和第三方测试对软件 进行质量 验证 ,根据测试 结果查找 缺陷 ;根据CMMI评判的等级审阅评审结果草案,采取措施纠正、完善,直到客户满意为止。

(7)持续过程改进。根据评估报告、客户需求及软件交付后运行的实际情况,提出持续改进建议并制定相应计划。通过加强软件配置管理,严格控制软件更改,加强更改后的回归测试和二次评审,使软件质量缺陷得到系统解决。

5结语

宝信软件再获CMMI5国际认证 第9篇

2016年3月,宝信软件研发部经过15个月的过程改进,成功达到CMMI 5级过程能力并通过CMMI5级组织成熟度(1.3版)认证。

宝信软件于2006年已达到CMMI 5级(1.1版)成熟度能力并获得认证,使公司建立起一套科学、完整、高效的过程管控体系和一支专业、稳定的过程改进、QA团队,为公司过程改进管理发挥了积极的引领和示范作用,在保证软件开发质量与进度、规范项目开发过程、提升成本控制能力、提高软件开发人员的职业素养、推进知识库建设和经验共享、提升公司和员工绩效管理水平,以及提升用户满意度等诸多方面发挥了积极作用。经过10年的发展和坚持不懈的改进,宝信软件研发部已经积累了丰富的量化数据和项目实例,为全面并深入评估组织过程能力成熟度做好了充分的准备。2014年,为顺应CMMI新版标准变化和业务发展需要,公司决定重新启动CMMI 5认证工作,经过15个月的培训、评估和改进,在减少交付工期偏差、降低缺陷密度、提高工作效率、提升产品用户满意度方面都圆满实现了设定的目标,最终顺利通过各项评估。

CMMI 5级的再次认证成功,标志着公司研发过程管理、体系管理达到了行业最高水准,是公司持续拥有国际最高水准的软件开发和过程控制综合实力的再一次展现,必将进一步提升宝信软件市场竞争力和品牌影响力。