cmmi实施方案（精选7篇）
1.cmmi实施方案 篇一
CMMI培训总结
自从踏出学校走入社会，直到现在，时光倒数，已有两年多了。回首本段时间，感叹万分。
自踏入社会即踏入研发部，工作中，更多的是酸苦。酸得难于入口，苦于无奈。一天到来，在当中，感觉似乎工作非常繁忙，电话响个不停，也让人接得眼前仿佛晴空深夜里的星星密密麻麻----让人头昏不已，甚至有时还真一口水都没时间或没心情喝。俗话说：多劳多得，付出与回报成正比。做为踏入社会不久的我，本应庆幸，在这繁忙的工作氛围，应该能接触到更多新事物，学到更多的东西。
但事实却并不此，繁忙的一天过来了，习惯于入寝前回想当天的工作情况，却总是不如人意。领导安排的设计图、工装，一天天过去了，却进展缓慢。随着时间流逝，前一设计样品已接近尾声，而目前的设计所剩时间已慢慢逼紧，此设计阶段已延期了好几天。事实上，一天当中真正静下心搞当中的设计却不到整天时间的1/4。由于前一产品设计已完成，正处于试样制作阶段。设计完图纸后，我列出配制，并将配制与其相应的图纸转至采购。采购在寻找供应商及询价当中，进展得更是蜗牛，每天我总需抽点时间至采购询问进展，但却无济于事，总是在询问、敷衍、辩论，有时基至争吵中循环。而在浪费几天后，却收到的答复是，部份材料难于采购，无法进行。某些零件由公司车间加工，却在加工中才发现某此工序达不了要求。质检把关不严，最后到试装配中，却发现有些零件装不入，而使用强制装配，导致某此产品零件变形而作废。这等等的一系列问题，导致了，前面所反应的情况，响个不停的电话，开个不完的推卸职任的会议。搞得我身心疲备，而最后产品却迟迟难于现身。内心也挺抱怨其它不合作的部门的。很想改变此种现状，却无从下手。所幸是，转进我司不到半个月，却得到一个难得的机会让我参加了CMMI培训。从中让我解开了大部份迷团。原来出现那种情况并不是工作者的问题，而是流程的问题。我们应该整理好流程，梳理好源头，以及前后或因果关系。成立项目小组，建立项目流程是势在必行。
项目流程可分成以下几个阶段：
1、需求分析：调查用户需求，确定需求规格。再进行产品可行性分析，并做出产品产项报告，最后进行分析评审。
2、概念设计方案：要对成本、进度、风险进行准确评估。在新技术在产品中的使用比例不要超出30%，因为如果这个产品大量使用新技术，那么，质量和进度往往不容易保证。通过此评审，项目组会组织相关部门的优秀人才对此设计做出相应的建议。使此产品设计得更实际。
3、详细设计方案:在概念设计方案评审通过后，把《初步设计》提交给该项目的硬件工程师、软件工程师和结构工程师分别提交《硬件详细设计》、《软件详细设计》和《结构详细设计》；
在此详细设计当中包括对成本、进度、风险进行细化，提出对资源的要求。最后对其评审，在此当中，避免了以下阶段在各部门遇到了一些矛盾与难题，减少事情的返工性。同时促使各部门达成一致，有效地提高工作效率。最大可能地将“有时间做没用的事情，却没时间做有用的事情”转化为“有时间做有用的事情，没时间做没用的事情”.如果之前搞设计前，有做这一步流程，将大家的意见集合在一起，相信当时就不会出现在设计、制造、装配方面造成如此大的分歧、矛盾。
4、实施设计
5、测试
6、出样机
在项目管理的流程中，每个阶段都有自己的起止范围，有本阶段的输入文件和本阶段要产生的输出文件。同时，每个阶段都有本阶段的控制关口，即本阶段完成时将产生的重要文件也是进入下一阶段的重要输入文件。每个阶段完成时一定要通过本阶段的控制关口，才能进入下一阶段的工作。
在此培训中，让我深深的体会“预先控制不如事外控制，事外控制不如事前控制”，“好的方法，好的流程才得制作出好的管理，好的工作效率，盲目的工作只是在做无用功”。
2.cmmi实施方案 篇二
软件过程管理是指在软件开发过程中除了先进技术和开发方法外，还有一整套的管理方法。它侧重的是软件组织在软件开发的过程中对需求管理、计划安排、合同管理、项目跟踪、资源分配和质量要求等的管理方式，也就是对软件开发、维护全过程规范化、透明化、标准化的管理。目前，普遍采用的软件过程管理方法是由SEI提出的CM-MI(Capability Maturity Model Integration)，即软件能力成熟度模型集成模型，是由美国国防部与卡内基-梅隆大学和美国国防工业协会共同开发和研制的。CMMI是一套融合多学科的、可扩充的产品集合，其研制的初步动机是为了利用两个或多个单一学科的模型实现一个组织的集成化过程改进。该模型提供了一种渐进式的软件过程改进途径，体现了软件工程和软件管理的最佳实践，为软件开发单位提供了逐步达到成熟的规范化过程的框架。CMMI分为5个等级，共22个过程区域(PA)，每个等级都被分解为过程域，特定目标和特定实践，通用目标、通用实践和共同特性;每个等级都由几个过程区域组成，这几个过程域共同形成一种软件过程能力。每个过程域，都有一些特定目标和通用目标，通过相应的特定实践和通用实践来实现这些目标。当一个过程域的所有特定实践和通用实践都按要求得到实施，就能实现该过程域的目标。
2 有效实施软件过程管理的策略
在CMMI模型中，主要以过程域(PA)为主题，阐述了对各PA的要求，描述了PA要达到的目标以及为实现目标而必须实践的过程;模型还描述了实践后要达到的效果，但并没有描述应该如何去做，尽管模型中也给出了少量的实例说明。然而，照搬照抄CMMI模型并不能帮助企业达到期望的成熟度，必须将CMMI模型转换成与公司业务目标相适应的体系规范。因此，本文从以下7个方面确定了实施CMMI模型的策略：
2.1 明确软件公司的发展愿景
在知识经济时代，企业发展更加依赖于技术进步和技术创新，谁抢占了技术的制高点，谁就抢占了市场的制高点。要以市场武装技术，以技术占领市场，走上市场和技术交替推动的持续发展之路。另外，还要建立可量化的业务目标并分阶段具体实施。有了愿景以及近期可以实施的业务目标，就可以对实施CMMI进行规划。通过实施CMMI模型对公司内部软件开发过程进行管理。
2.2 建立实施CMMI的组织机构
为了真正落实和加强软件开发过程的控制与管理，需要建立起软件开发质量保证的组织机构，明确与软件开发相关联的各级人员(小组/部门)的职责、权限和沟通方式，确保软件过程管理的有效性。这样才能使CMMI工作持续地开展下去，达到不断提高产品质量的目的(如图1)。
在整个组织框架内，实施负责人确立一个长期的过程改进目标，并带领大家为此目标而努力，是过程改进的动力和鼓动者。SEPG(软件过程改进小组)是过程改进的核心，承担整个过程改进的组织、策划和实施推广工作，他们通常是由公司内部各方面的资深专家组成。项目人员通常来自各职能部门，因此要处理好SEPG、项目和部门之间的关系。在这个团队中，职能部门经理的地位非常重要。图2给出了每个项目组的构成。
项目经理负责管理组内所有工作，以及与其他组之间的协调;变更控制委员会(CCB)的目的是确保每个基线变更都经过所有相关方的考虑，每个变更在实施前都经过批准。CCB是对每个变更进行评审，做出批准、不批准或推迟实施以获得更多信息的一个实体。它至少要包括从事开发、文档编写、测试、保证、维护和发布等方面工作的的人员。
2.3 确定软件项目开发过程
软件开发中心从业务部门收到软件需求计划之后，任命一名项目经理负责。项目经理根据软件需求计划，撰写软件开发计划书草稿，软件开发计划书定义了软件开发团队职责范围、人员数量和结构需求、阶段性里程碑的设置和产出、风险的识别和规避办法、人员的培训计划、软件开发过程的定义等。软件开发计划书完成后，召开软件项目开发启动会议，邀请人力资源部、培训部、过程改进组。在会上，项目经理根据软件开发计划向人力资源部代表提出各阶段的人力资源计划需求，向培训部提出相关培训需求，同时与过程改进组讨论、裁剪软件开发过程。
软件启动会议召开后，项目经理根据相关与会部门代表商议的结果修改软件开发计划书并形成正式版本。同时，配置管理员对该文档形成基线并收进配置管理库。之后，软件项目将按照软件开发计划书进行。每月末，质量监察员将依据项目软件开发计划书对项目进展和质量进行评审并责令项目经理限时整改。
每周五，项目经理通过周报形式向业务部门代表和开发中心高级经理汇报项目的进展情况。周报的内容包括：本周完成工作的情况、遇到的问题和是否解决、下周计划完成的工作和预计可能遇到的问题。周报作为正式的沟通渠道让相关领导和部门实时监控项目的进展和风险。
当项目完成并获得业务部门的认可之后，项目经理将根据软件开发计划书召集项目团队成员、人力资源部代表、过程改进组代表召开项目总结大会。在会上，项目经理和团队成员就该项目遇到的困难和解决方法进行总结分析，并形成项目总结报告。该报告由软件过程改进组收入软件开发经验共享库以供所有开发人员分享经验。同时，会议召开后，项目组将解散，所有成员将归还人力资源部重新分配。
2.4 制定软件过程管理体系规范，确保过程可以固化
按照CMMI的软件过程改进标准制定管理策略和技术文档，制定适合软件开发的过程管理体系规范，是CMMI实施中一项非常重要的工作，它将软件开发所运用的方法和流程加以固化，并同时进行改进，以达到相应的CMMI能力成熟度级别要求。统一适用的管理体系规范使各项目组执行的方法和流程进一步规范。
软件文档分为过程管理文档和工作产品文档两大类。过程管理类文档描述了每个过程的目的、开展的活动、遵循的步骤和规则、人员的职责和应当输出的工作产品等;工作产品类文档给出了每个过程输出的工作产品的内容和形式模板。表1给出了几个关键过程域的过程管理文档和工作产品文档。
2.5 选择项目试点，确保体系规范的适应性
选择需求规范覆盖至少为公司主营业务的一部分项目，将制定好的过程文档和模板，在试点项目中进行试运行，消除不符合要求的地方，对过程进一步改进。面向项目组进行培训，根据项目组整体的过程成熟度有针对性地开展，就过程中存在的问题开展辅导，此阶段的培训和辅导主要是由质量经理担任。在实施过程中，首先重点关注成熟度较低的PA实施，并制定切实可行的办法进行整改;其次要关注每一个PA的难点实施，要做到各个击破，将实施工作做到位。对实施过程中遇到的问题要及时加以解决，问题长期得不到解决会对项目组的实施热情造成伤害。还要定期开展评估工作，了解目前的进展以及存在的差距，树立过程改进的信心。
2.6 适时认证和推广，树立过程改进信心
在初步达到相应的成熟度级别后，就可以开展相关的CMMI认证工作，具体可与一些有资质的公司联系。与此同时还要对过程管理体系规范进行推广，制订切实可行的推广计划，使项目组对投入到管理、文档上的工作量要有预估，在时间效率上达到平衡。在实施过程中，各部门在观念、利益上存在冲突，会给实施工作带来较大的阻力，因此需要有力的领导来总控，确保CMMI实施工作顺利进行。最后还要加强对问题的跟踪力度，对推广过程中出现的问题要加以分析并快速解决。
2.7 不断深化，使过程改进工作持续推进
当过程管理体系规范在公司得到全面推广后，并不代表过程改进工作结束了，只是表明企业目前已取得了阶段性成果，还需要不断深化，总结经验。要将过程改进工作持续推进，还要做好以下工作：一是建立收集过程改进意见通道;二是对过程管理体系规范进行定期修订，确保对项目有较强的适应性;三是用工具完成对开发流程的支撑;最后要大力推进质量文化建设，使过程改进工作深入人心，落到实处。
软件过程管理体系制定出来后，一定要先全员培训，经试点后再推广。
3 结语
3.cmmi实施方案 篇三
2007-12-22 ATM培训总结：
通过本次ATM培训对CMMI的评估方法、组织方式、评估过程、评估组成员职责等有了初步的了解。结合课程本身对公司进行评估需要做得工作有了一定的理解。
一、培训目标
本课程培训的目标：通过培训帮助评估组成员为组织进行SCAMPI CLASS A评估时能够高效的履行职责、了解评估步骤、了解评估方法背后隐含的基本概念、通过培训练习熟悉评估方法。具体期望如下：
A.能够有效和高效的做好文档评审
B.能够有效和高效的做好访谈
C.知道如何为每个项目在每条实践上的实施程度进行评分
D.学会如何给出初步结论
E.学会如何基于每条结论给出最终的目标评分、成熟度评分
F.总结
二、评估组的建立
1.CLASS A评估组成员的选择标准：
A.首先是一批有经验的个人，具体的经验要求如下：
a)接受过SEI证书培训
b)接受ATM小组培训
c)整个评估组成员工程经验总计要25年、平均要6年
d)整个评估组成员管理经验总计要10年，至少有一人是6年 e)公司产品开发生命周期的每个阶段至少有两人参与经历过
B.评估组成员不能是被访谈项目的项目经理、上司
C.内部评估和外部评估人员总共加一起一般是4～9人，不能低于4人，可以超过9人，但不建议超过。
2.为什么评估组对于评估非常重要：
A.评估结果反映整个评估组的知识、经验和技能：能够给出切实有益的改进建议
B.评估的结果客观与否取决于评估组；
C.评估结果可信与否也取决于评估组的结论以及评估过程
3.评估组团队的成长过程
评估团队应建立共同工作的目的，团队成员间的经验、能力是可以共享的，团队成员都相信团队的力量比个人的力量大。
评估组的成长过程经历7个步骤：
A.定方向阶段：组员了解为什么到这个组；
B.建信任阶段：组员彼此熟悉、信任、了解；
C.界定清楚角色和职责；
D.作承诺；
E.过程管理、执行阶段；
F.跟踪控制团队表现，提高团队表现的过程；
G.团队的持续改进过程：为公司培养内部改进人员。
4.评估组章程：
A.严格遵照SCAMPI评估方法
B.提供准确清晰的结果
C.经过协商产生结果，确保每个人都支持这个结论
D.小组协商一致时要进行表决
E.遵守保密协议，避免泄露可能称为口实的消息，是评估组陷于被动 F.所有参加人员要参加会议，按时开始、结束
G.当一个成员休息时，全体休息
H.不同意见要公开，没有隐瞒子自己的意见
I.只有理解后才能表示同意，并基于负责任的态度提出异议
J.相互尊重
K.整个组织按预定的计划实施活动，对离题的现象要控制，避免严重争执 L.即时提出好的建议、积极的观点
5.评估主意事项：
A.每个成员都要进行记录
B.笔记一定记录被访谈者的陈述，不做解释、不做推论、不做结论
C.不做自己的事情
D.不要在访谈时提到其他访谈的消息
E.事先准备好访谈问题
F.仔细听、努力理解被访谈者的意见
G.不要忽视访谈者的话，不要问重复的问题
H.如果被访谈者难以回答，不要建议答案
I.被访谈者不明白问题时，重复问题或询问被访谈者是否明白
J.每次只一个人发言，不要抢话
K.记录要求被访谈者会后提供的证据，并在会后提醒跟踪。
三、评估方法介绍
SCAMPI方法（Standard CMMI Appraisal Method for Process
Improvement）：SCAMPI评估方法是一种诊断工具，是标准的CMMI过程改进评估方法，支持和推动组织对过程改进进行承诺。通过确认组织和一个或多个CMMI模型相关(CMMI-SE/SW)的现有过程的强/弱项，SCAMPI能够帮助组织对它自身的过程能力或组织成熟度有一个全面的了解。
西安和北京预评估实行的是SCAMPI ARC A类评估，要对工作产品和面谈人员进行广泛的评审，从而得出成熟度等级或能力等级的评定。
CMMI的SCAMPI评估分为三种评估方法：CLASS A、CLASS B、CLASS C，其中： CLASS A：完整的、综合性能的评估方法，要求组织严格按照体系文件执行，可以允许有个别项目例外。例如体系文件主要针对研发项目，对维护项目则可以例外，但需要提供合理的原因。
CLASS A评估的目的：结合CMMI模型能够理解公司当前过程、通过理解过程了解公司的弱项及强项、对CMMI过程目标的满意度进行评价、对过程域成熟度等级进行评分。
CLASS B&C：通常用于组织内部的考察，例如考察体系文件与模型的差别、考察试点项目运行结果与模型的差距、预评估等。
组织可根据实施状态选择评估方式，三类评估结果都可以上报SEI，但评估的主导者不同，A类为主任评估师，BC类为SEI授权的组长即可，目前上报到
SEI的国内企业基本采用A类评估方法。
正式评估时要求：列出公司项目剖面图，包括项目名称、周期、当前阶段、生命周期模型、人数、组织形式，评估组从中进行采样评估。
CLASS A评估方法的评估原则：
i.要以过程模型为开始
ii.要有一个一定义的评估方法
iii.要求高级管理人员支持本次评估
iv.评估过程要遵循保密原则，不点名，评估笔记最终要销毁
v.通过协作来达到评估目的vi.关注行动，对事不对人
正式评估时需要上报给SEI的数据：组织范围项目数/组织单位项目数、组织范围人数/组织单位人数。覆盖率偏低对公司通过评估有一定压力。组织范围指参与评估以及支持评估的范围，组织单位指评估实体范围，可以是组织的一部分也可以是组织全体。
客观证据，指文档或访谈的结果，表明各条实践的实施程度。客观证据来源有以下几种：
A.工具（常指调查问卷），可选
B.展示（演示），可选
C.文档（电子、纸质、工具记录均可），必选
D.访谈，必选
实例：指组织单位里面按照模型实施的项目。评估时就是从实例中进行采样，采样评估结果指示整个组织单位在模型实施的能力水平。正式评估时要求列出：几个部门、每个部门的项目数、项目的开发周期、项目采用的生命周期模型、当前处于什么阶段、项目人数、项目的组织形式、项目在每个部门的情况。评估组根据项目剖面图进行采样。
实践实施指示器（PIIDS表）： 走路留脚印，做事留痕迹。做事过程中留下的证据，证据分为直接证据、间接证据、人证：
A.直接证据指实践产生的有形的产出物
B.间接证据指涉及实践的会议记录、过程数据、邮件等
C.人证指口头的或书面的陈述来确认实践的实施、由实践的实施者或
相关人员提供，人证的获取方式可以是面对面的访谈、电话访谈、视频会议、调查问卷等。
咨询师的要求：访谈证据是否充分一定要听到两次（至少有两个人证），看到一次。在评估方法中没有明确要求。
四、评估阶段介绍
SCAMPI评估方法分为三个阶段：计划阶段、现场评估阶段、报告阶段。
1、计划阶段工作内容：
A)确定评估目标和目的B)确定评估计划
C)培训评估组
D)评估组内部准备PIIDS表
E)进行内部分析
F)策划现场活动
G)评估前进行就绪检查：检查客观证据、评估组是否就绪、设备是否就绪
2、现场评估阶段工作内容：
A)召开开幕会：要求出资人必须参加，如不能召开要委托他人参加
B)找到直接证据、间接证据
C)确认证据
D)进行访谈
E)进行初步结论
F)确认初步结论：最后提供证据的机会
G)组织级的评分
3、报告阶段
A)汇报正式结论
B)与出资人最后沟通
C)总结
具体步骤如下：
第一步，进行评估策划。
1)确定被访谈成员，被访谈成员角色需要包括：
评估出资人：保证证据的真实性、保证证据至少保留三年
中层经理：项目直接上司，参加被访谈，也是数据提供者、对访谈结果进行初步确认
项目负责人：单独被访谈，数据提供者、参与访谈结果的初步确认
职能代表：具体的实践人员，如：QA、CM、EPG、培训、软件开发人员、硬件开发人员、测试人员等。
一般按照职能组进行分组进行，也可按照不同角色进行分组访谈。
2)确定评估组成员角色，评估过程需设定以下角色：
评估组组长：负责整个评估过程，需要得到SEI授权，且需要对最终评估结果进行确认和负责。职责：确保整个评估的策划过程是完整的、给评估小组分配角色及职责、确保评估方法得到遵循、监督过程的表现、推动问题的解决、与出资人接口、负责上报结果给SEI。
库管理员：管理评估期间的文档，在评估结束后将文档返回
计时员：控制访谈时间，进度控制
3)进行评估分组，评估分组一般可采用以下形式：
项目管理：PP、PMC、SAM、IPM、RSKM
工程：REQM、RD、TS、VER、VAL、PI
过程管理：OPF、OPD、OT、QA、CM、MA、DAR
评估策划主要由评估组长来做，正式评估时需要写评估计划文档（正式评估前一个半月应提供），文档内容应包含：
A.评估的商业目的B.评估目的C.评估关键参数：出资人姓名、出资人头衔、出资人单位、联系方式
等
D.评估组组长信息
E.评估组成员组成：名字、参与培训的培训师、工程经验年限、管理
经验年限、参与执行过哪些PA
F.评估组成员职责、联系信息
G.评估参与者：姓名、头衔、职责
H.项目名称、支持组名称、项目类型（FOCUS项目、NON FOCUS项目）、项目规模、项目组织级的职能、项目在组织单位的具体位置
FOCUS项目：覆盖所有PA的项目
NON FOCUS项目：补充提供证据的项目，只覆盖个别PA，不要求完
全覆盖所有PA
第二步，完成评估策划后，组织单位需要进行准备工作：
A.收集客观证据并进行记录（填写PIIDS表）：围绕项目生命周期进行
B.客观证据的评审和初步分析，要求在访谈前进行文档评审，确认
PIIDS表中提到的客观证据
第三步，就绪检查：客观证据是否准备充分、评估组是否就绪、后勤设施（如设备、场地等）是否准备就绪。就绪检查不符合要求的情况，评估组长要进行决策，决策有以下三类：
A.按计划继续进行评估
B.重新安排计划
C.取消计划
就绪检查可能会进行多次。就绪检查需要回答的问题：有多少证据？结合CMMI模型要求还缺少什么证据？在什么地方可以得到缺少的证据？
第四步，进行访谈，访谈的目的是为了收集口头的人证信息来证明实践的实施。首先进行访谈准备，确定访谈类型、被访谈人员分组、准备访谈问题。访谈的类型分为：
A.Standard：事先做好计划，准备好问题，根据类似职责分组，整个评
估组参加。
B.On－call：证据不足或不充分或相互冲突的时候，采用事后访谈。也
要求事先计划，通过现场协调员通知被访谈人，组长制定至少两个人
以上的评估组成员对其进行访谈，也需要事先准备好问题。
C.Office hour：去位置上访谈
对被访谈人员的分组可参考以下情况：
A.项目负责任：单独访谈
B.中、高层经理：可合并一起访谈
C.QA
D.CM
E.PM
F.开发人员，可根据相似只能合并
G.测试人员
其次，确定访谈计划，包括：开场白（访谈、被访谈人员自我介绍、评估目的等）、安排座位、访谈角色确定等
访谈角色包括：
A.主导者：问问题、访谈的推动者，每个成员都是所负责的PA的主导
者
B.计时员：控制实践，提醒
C.库管理员：记录访谈会后需提供的证据，责任人
访谈问题分为三类：
A.开放式的问题：没有标准答案
B.直接问题：有标准答案，必须做出回答
C.转移性问题：随着问题问问题
访谈中的经验介绍：
A.不要心中装着自己想好的答案
B.不要对别人说的话做出反应
C.不要表露怀疑、轻蔑的态度
D.认真听每个人说的话
E.不要问已问过的问题
F.遇到问题的事后巧妙的转移，避免陷入僵局
最后，汇总访谈结果，整理PIIDS表，给出评分结论，并确认。
注意：
间接证据和人证是和或的关系，如没有直接证据，光有间接证据是不够的，还需要有人证的支持。
人证的覆盖规则：
A.一行一列规则：每一个实践至少有一个项目提供人证信息，每一个
项目至少为一个实践提供人证信息。如果满足这个要求，则表明这
个目标人证满足要求。如果某条实践没有人证信息，则必须找到直
接、间接证据，才能说明这条实践被完全实施。此规则只针对人证，对直接证据不适用此规则。对没有间接证据的实践，在访谈时一定
得问到，得到人证，否则此实践的评估结果只能是PI
B.50%规则：对实践、项目需要提供的人证只要达到50％的比例即可。
如四个实践、四个项目在执行，人证只需要提供8个即可。
五、评分方法
1、对SP的评分标准
对每个项目每条实践的评分标准：
FI：全部实施：有直接证据，且有间接证据或者人证，且没有找到弱项 LI：大部分实施：有直接证据或间接证据，但有弱项
PI：部分实施：直接证据不存在，或有直接证据但证据不充分；
或无直接证据，但间接证据说明做了；
或有直接证据且证据充分，但访谈中无间接证据，也无人证
NI：未实施：无直接、间接、人证，且应该做的实践但没有做；
NY：未到实施时机：还未到时间做，未作。
对组织单位级实践的评分标准：
所有项目都是FI/NY，至少有一个FI，则这条实践为FI
所有项目都是LI/FI/NY，则这条实践为LI
至少有一个LI/FI，至少有一个PI/NI，则这条实践为LI或PI
所有项目都是PI/NI/NY，至少一个PI，则这条实践为PI
所有项目都是NI/NY，至少一个NI，则这条实践为NI
所有项目都是NY，则这条实践为NY。这种情况在正式评估时是不允许的，认为组织未到评估时机。
正式评估的初步结论如何写？将每个项目的实现转化为组织级的实现情况，将每个项目的观察项转换为组织级的观察项，并将每个项目的每条实践结果概括为综合组织级在每条实践的发现。
2、对SG的满足评价
进行目标的评分必须满足三个条件：
A.所有相关信息评估组已经收到并已考虑过
B.所有实践都在组织单位级给予综合评分
C.已经做过初步结论反馈
判断目标是否满足必须达到两个条件：
A.所有相关实践在组织单位级必须为FI或LI
B.如果有LI出现，说明一定还存在弱项，需要评估弱项对目标的影响，不能对目标有大的影响
达到上述两个条件才能说这个目标在组织级得到了满足。
对弱项的影响主要考虑：
A.现在满足了，但对今后实施是否有信心？如果无，则不满足
B.这里满足了，是否会影响其他方面？
3、对PA的满足评价
有5个等级：
过程域满足：过程域的满足必须是过程域的所有目标都满足。
过程域不满足：只要有一个目标不满足，过程域就不满足
过程域不适用：三级只有SAM过程域可以不适用，但我司可以适用
过程域不评：还未到时机，及SP为NY
过程域超出范围：超出评估等级范围
4、对CL的满足评价
4.cmmi实施方案 篇四
过程开始 组织发展战略规划《组织级方针》 原有的组织过程资产1.确定组织过程改进目标《过程改进目标》《过程改进目标》2.收集、汇总过程改进建议《过程改进建议表》原有的组织过程资产3.评估组织现行过程《过程改进评估报告》或《差距分析报告》《过程改进建议表》《过程改进评估报告》或《差距分析报告》《过程改进目标》《过程改进评估报告》《组织过程改进点列表》4.识别组织过程改进点《组织过程改进点列表》5.制定过程改进计划并评审《组织过程改进计划》《组织过程改进进度表》《组织过程改进计划》 原有的组织过程资产6.建立和维护组织过程资产过程资产库（试用版）10.过程改进管理活动（跟踪和监控、配置管理、质量保证、度量等）过程资产库（试用版）《组织过程改进计划》7.在项目中试点改进后的组织过程资产《过程改进建议表》过程资产库（试用版）《过程改进建议表》8.评估、部署新的组织过程资产过程资产库（正式版）过程资产库（正式版）9.组织中全面实施推广《过程改进建议表》《EPG会议记录》《过程改进月报》《组织过程改进总结报告》《过程改进进展通告》《过程资产修订记录》过程结束
【培训】组织培训[OT]
过程开始组织发展战略规划《人员岗位技能表》培训需求调研《培训需求调查表》《培训申请表》编制培训计划《战略培训计划》《培训计划》不通过审核通过《战略培训计划》《培训计划》培训讲师培训教材培训场地培训教具等建立培训能力《培训计划表》实施培训培训通知（邮件）《培训签到表》培训考核《培训成绩记录表》《培训满意度评估表》建立培训记录《人员岗位技能表》定期培训总结《讲师考评记录》《培训总结报告》过程结束 【项目经理】立项过程 [PIM] 【项目经理】结项过程[PCM]
过程开始《项目计划》1.结项申请《结项申请书》《结项总结报告》2.高层经理审批否审批通过？是《结项申请书》《结项总结报告》否会议通过？是4.提交组织过程资产项目资产3.结项会议《结项会议纪要》过程结束
【项目经理】项目计划[PP]项目估算过程
项目估算过程输入项目经理输出项目估算模板开始需求规格说明书组建估算小组小组确定估算模型和方法估算项目规模估算项目工作量项目估算表估算项目成本估算过程估算结果跟踪结束
【项目经理】项目监控[PMC]
过程开始1.制定监控目标组织度量库《项目计划》2.项目状态监控《项目计划》是否存在偏差Y3.采取纠正措施《个人周报》《项目周/月报》《里程碑报告》《项目会议纪要》《项目问题跟踪表》《风险计划与跟踪表》《项目变更申请单》《项目变更记录》N项目结项Y过程结束
【项目经理】风险管理[RSKM]
过程开始《组织风险列表库》《项目计划》1.风险识别2.风险分析《风险管理计划及跟踪表》3.风险处理4.风险跟踪5.更新《组织风险列表库》及通报风险状态过程结束
【项目经理】度量分析[MA]
过程开始《项目计划》1.建立项目度量目标2.确定项目度量点《度量分析计划》3.制定《度量分析计划》《度量分析计划》4.收集和分析度量数据项目度量库5.存储和更新、通报度量结果过程结束《项目进度表》《项目周报》《项目里程碑报告》《不一致项问题跟踪表》 各类《评审报告》《测试报告》《项目变更记录》《项目问题跟踪表》《风险管理计划及跟踪表》
【项目经理、需求】需求开发与管理[RDM]需求管理过程同行评审过程同行评审过程同行评审过程-个人评审过程
过程开始待评审的工作产品1.发起评审请求评审通知待评审的工作产品2.评审工作产品《评审缺陷记录》《评审缺陷记录》3.产品返工返工更新后的《评审缺陷记录》《评审缺陷记录》4.发布评审记录过程结束
【项目经理、需求、设计】决策分析与解决方案[DAR]
开始决策分析实施指南确定决策内容成立决策组 决策分析计划编写决策分析计划决策分析计划建立评价准则和评价方法决策分析评价表识别候选方案候选解决方案候选解决方案决策分析评价表评价候选方案决策分析报告发布决策分析结果及跟踪解决方案执行情况结束 【设计】技术解决方案[TS]
过程开始《产品需求规格说明书》《产品需求规格说明书》《技术解决方案》《数据库设计规范》数据库设计《概要设计说明书》《界面设计规范》《详细设计说明书》 系统开发原型Demo《编码规范》1.建立技术解决方案《技术解决方案》2.系统设计 《数据库设计说明书》 《概要设计说明书》3.详细设计《详细设计说明书》4.编码实现模块代码数据库对象代码《详细设计说明书》《编码规范》《数据库设计规范》 模块/数据库对象代码5.代码走查bug记录《产品需求规格说明书》6.编写支持文档《用户操作手册》《运行维护手册》过程结束 【开发】产品集成[PI]
过程开始《概要设计说明书》1.制定产品集成计划《产品集成计划》2.审查接口的兼容性《接口关系管理表》《数据库设计说明书》《概要设计说明书》3.组装产品组件集成产品验证不通过《测试计划》《测试用例》 Bug记录4.验证活动验证通过《测试报告》系统测试通过的集成产品5.产品交付已打包产品（安装光盘等）《产品打包清单》《产品交接验收单》《客户验收报告》过程结束 【测试】确认[VAL]
过程开始《项目计划》《产品需求规格说明书》《概要设计说明书》《数据库设计说明书》《详细设计说明书》1.制定测试计划《XX测试计划》《产品需求规格说明书》2.编写测试用例XX测试用例《测试计划》《测试用例》3.执行测试Bug记录4.发布测试报告《XX测试报告》过程结束 【配置】配置管理[CM]
过程开始《项目计划》《项目进度表》《项目已定义过程》1.识别并标识配置项2.制定配置管理计划《配置管理计划》工作库目录结构3.建立配置管理系统、创建配置项项目配置工作库《基线创建申请单》4.基线发布（多次）《基线创建申请单》 XXXX基线《变更申请单》5.跟踪配置项变更请求《项目变更申请单》《项目变更记录表》《基线创建申请单》6.产品发布发布的产品7.配置审计《配置项维护与审计记录》《配置管理里程碑报告》《CM周（月）报》过程结束
【QA】质量保证[PPQA]
5.CMMI软件风险定量研究 篇五
随着企业和社会信息化的日益普及,与信息技术紧密相关的各类软件项目,诸如软件开发、组建计算机网络和信息系统集成等软件项目和我们生活的联系越来越频繁。随着软件建设环境的日趋复杂,软件项目的投资和建设规模也急剧增加。软件项目所固有的需求很难准确定义、建设标准和目标不易统一、技术人员流动频繁、研发技术发展迅速等特点决定了它要充分考虑项目管理中可能遭遇的各种风险,还面临着其他类型项目所不具备的特殊风险。这些风险的存在很可能会造成数据丢失、进度推迟、成本增加等不良后果,更为严重的可能会导致项目中断甚至整个项目的失败。
软件项目风险管理是指贯穿于软件项目生命周期,保证项目按计划进行的策略、方法、技术和工具的集合,它含有风险辨识、评估、排序、计划、监督和控制活动,并成为软件项目管理的主要部分之一。软件项目风险管理的目标是识别可能影响软件项目成功的任何风险;提供识别和评估风险的标准过程和方法;通过适当的行动将风险产生的概率或后果压至最低;实时监测和报告风险,为制定防范和应对风险的措施提供决策依据。
项目风险管理强调对项目目标的主动控制,对项目实现过程中遭遇的风险和干扰因素可以做到防患于未然,以避免和减少损失。
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.
6.CMMI研究所助企业提升绩效 篇六
CMMI研究所创立于卡内基梅隆大学(Carnegie Mellon University),是软件能力成熟度模型集成(CMMI)的发源地。CMMI是软件和系统开发卓越度的黄金标准。研究所将继续帮助市场解决商业问题,将模型的使用推广至全球新的行业领域。
CMMI被三星、埃森哲、宝洁、西门子等全球最受推崇和最具创新性的机构所使用。CMMI的推广是企业有力的竞争优势,也是推动其广泛普及区域经济增长的催化剂。
CMMI研究所首席执行官Kirk Botula表示:“为了在全球市场竞争, 领导层必须确保机构能持续带来具备品质和价值的产品和服务。CMMI研究所帮助机构追求卓越,在对于公司目标产生重大影响的领域达成可测量的成果。CMMI提供的使用框架可帮助机构识别和处理关键挑战,改善绩效和利润。”
CMMI模型通过政府、行业和学术机构的合作在卡内基梅隆大学软件工程研究所(SEI)开发,帮助美国国防部及其承包商(雷神、诺斯洛普? 格鲁门、洛克希德?马丁、波音等)改善软件工程能力。CMMI被广泛认为是可靠性的重要标准,被许多机构作为参与合同竞标的先决条件。
全球94个国家和地区多个行业领域的数千家企业利用CMMI模型提高绩效,并通过CMMI方法评估其能力和成熟度。CMMI产品套件包括产品开发、服务交付、采购和员工管理,对所有企业而言都是一笔有价值的投资。 卡内基梅隆大学成立CMMI研究所,旨在将CMMI的效益拓展至软件和系统工程之外的各个行业及规模的生产或服务企业。
来自毕马威印度事务所(曾获得卓越商业合作伙伴奖) 的KK Raman表示:“卡内基梅隆大学是开发最佳实践并推进其产业化的先锋,CMMI在全球受到广泛采纳便印证了这一点。毕马威是全球最著名机构之一, 与卡内基梅隆大学合作十余年。我们帮助客户使用CMMI研究所产品套件(框架、培训、认证和评估方法),通过改善机构流程达到其目标。”
拓展CMMI的效益
CMMI在全球受到广泛采纳有赖于广泛的合作伙伴网络,他们将帮助客户机构成功应用CMMI模型。 CMMI研究所将推出在线自我评估工具和面向从业人员的新专业认证,以推进CMMI的使用。
●CMMI自我评估工具:机构通过这项新在线工具可评估其现状, 开启提升绩效的历程及诊断当前实施状况。用户通过回答一组简单的问题,便可获得关于机构优势和弱势的分析、改善机构能力的解决方案等重要见解。
●CMMI助理和CMMI专业人士认证:CMMI研究所将推出认证计划,帮助相关人员将CMMI经验转化为职业发展机会。 CMMI助理和CMMI专业人士认证可作为相关人员对于CMMI基础和高级概念知识水平的证明,向当前和潜在雇主证明其对卓越的追求及拥有宝贵技能帮助提升机构绩效。
来自Hubbert Systems Consulting, Inc. 的Capri Dye表示:“作为每天工作都要使用CMMI的专业人士,我将努力提高对该模型的认识,帮助我的客户和机构更好地定位,成功实现目标。从业人员认证不仅为我们的职业成长提供了清晰的路径,还有利于向客户和所在机构沟通和证明我的技能。”
CMMI自我评估工具和从业人员认证将于2014年初开放。
关于CMMI研究所
7.cmmi实施方案 篇七
关键词：汽车电子,CMMI,软件开发,软件质量
0 引言
在中国软件行业发展的近30年中,集成能力成熟度模型CMMI(Capability Maturity Model Integration)已经在国内的软件企业广泛实施并探索出有效的实施方法,越来越多软件企业通过实施CMMI来规范企业管理体系,提升软件产品质量。
随着中国汽车电子的飞速发展,汽车与软件的联系越来越紧密,已成为汽车创新发展不可缺少的因素之一。为了在有限资源范围内最大限度地提高主机厂自主开发的软件质量,必须引入CMMI管理体系指导软件开发。
1 CMMI概述及应用现状
CMMI起源于美国政府和军工软件企业的一些成功经验及实践。2002年1月,由美国国防部、卡内基-梅隆大学与美国国防工业协会共同开发研制并发布的CMMI1.1版本,标志着CMMI模型的正式启用。其研究目的主要是提高软件行业开发能力,帮助企业建立适合企业自身发展的软件开发质量保证体系,从而保证软件产品能及时、高效地输出到客户。另外,通过不断积累和发展使软件开发向着流水线方向发展、帮助企业节省开发成本也是CMMI的重要目的。CMMI按企业软件的成熟度共分为5级22个过程域,分别为初始级、可重复级、已定义级、量化管理级、优化管理级。
自1999年起,中国软件企业开始接受并逐步推广CMMI体系,通过学习和不断探索,已经在软件开发标准化方面取得了一定进展。据SEI统计,通过评估的软件公司对项目的估计与控制能力提升了40%~50%,生产率提高了10%~20%,软件产品出错率下降超过1/3[1]。截至2011年底,包括IBM中国、宝信软件、东软集团等在内的28家企业通过了CMMI5 级认证。如今,已有越来越多软件企业通过了CMMI认证,主要涉及计算机、手机软件等相关行业。随着汽车电子的快速发展,其规模和复杂度也日益提高,汽车嵌入式软件与其它行业软件相比有着更高的质量要求,其对响应速度及安全性的要求更高。
2 CMMI软件开发模型
CMMI开发模型(CMMI For Development)是在产品与服务开发活动中处理问题的最佳实验[2],此模型涵盖了工程学科共有的开发与维护活动,涉及产品开发的过程均可利用此模型来进行过程改进,包括银行、计算机软硬件、航空航天、国防等在内的各个领域。CMMI开发模型包含16个核心过程域及5 个开发活动特有的过程域,这5 个关于开发活动特有的实践包括:需求开发、技术解决方案、产品集成、验证和确认。
CMMI指出,CMMI的本质是软件管理工程的一部分[3]。就目前CMMI发展总体情况而言,SPI(Software Process Improvement)是软件管理工程的核心问题。对软件过程进行改进,可高效、高质量和低成本地开发软件,能够通过过程监控管理达到提高开发质量、减少产品缺陷、减少退货、提高用户满意度等目的,对于提高软件产品质量与生产率、缩短上市时间也能够起到重要的指导作用。
3 CMMI软件过程改进实施
汽车软件因其特殊的应用领域,不同于一般软件产品,其对产品的安全性和可靠性有着严格要求。因此汽车软件不仅需要一般的软件工程方法、软件质量管理手段来提高软件可靠性,为了满足针对性,首先要结合自身特点,如组织结构、工作范围、公司状况来明确当前需要改进的地方。选择合适的方法,从人力、物力上保证,对CMMI模型进行合理裁剪,避免周期过长、程度不够深入以及无法实施等问题。
3.1 支撑V模型开发的完善工具链
通常的产品开发模式是,开发工作从客户的需求定义开始,经过系统设计、软硬件架构设计到单元开发完成为止,将工程参数层层分解,需求逐步细化,最终形成软件代码。在该过程中首要的因素是各级理解必须正确,然后是追溯开发过程没有产生遗漏。当前业内流行的开发方式是V模型,不但满足了一般的开发需求,还将测试和验证过程加入开发迭代。
V模型的价值在于其非常明确地描述了测试阶段与开发过程期间的对应关系,工程开发人员往往期望有一款工具既能够支持V模型的工程开发需求,也能够实现测试和验证自动化。然而在业界,这样的工具往往属于大型企业的秘密,不会出售,一般软件也往往只解决流程问题,而无法解决技术整合问题。因此,泛亚汽车技术中心摸索开发了一系列自主工具,既能在流程上符合V模型开发方式,又能整合各层次的技术资源和分类工具,彻底实现了一个完整的工具开发链路,具有很高的产业价值。
3.2 基于AUTOSAR架构的分工和交付物管理协作模式
随着团队的扩大以及更细的人员分工,制定一套标准的开发流程能够显著降低开发成本,缩短开发周期。从制定各个里程碑开发节点出发,到软件需求理解、软件架构设计、软件编码及建模,再到软件集成测试,每个开发活动都有明确的输入需求、交付物以及对应人员。创建符合CMMI的软件开发流程关键,还在于在项目开发大节点有相应的质量阀评审,若评审不通过,则需要对交付物采取补救措施。
AUTOSAR(Automotive Open System Architecture,汽车开放系统架构)由全球汽车制造商、部件供应商及其它电子、半导体和软件系统公司联合建立,是目前汽车厂商统一、开放的软件架构,但国内应用此架构开发的汽车厂商还不多,都还处于初级阶段。企业应基于AUTO-SAR架构原理,根据专业工作细化结果,结合团队自身特点,制定相应措施以达到提高开发效率、缩短开发周期的效果;另一方面,还应强化软件架构设计及软件集成的执行,从软件架构流程确保整个项目开发的统一设计,再逐步细化到各个子模块的实现中,同时确保所有交付物都通过专家评审,力保在软件设计之初就发现问题,从而有效降低开发成本;此外,通过软件持续集成、统一发布,控制开发节奏,驱动开发进展,逐步完善软件成熟度。图1为基于AUTOSAR软件架构的软件开发流程。
3.3 软件质量目标定义
软件开发的质量管理主要细分为质量保证及质量控制两类活动。其中,质量保证是针对开发过程开展的活动,质量目标包括评审度量指标、评审投入比例、过程失控度目标等。质量控制主要是针对测试及验证活动,定义的主要度量指标包括项目测试收束目标、测试逃逸率以及逃逸的千行代码缺陷率。最常用的3个质量目标定义如表1所示。
3.4 软件度量制度建立
项目的健康化发展离不开对缺陷数据的统计,通过统计可知道项目的薄弱点,也能对项目进行横向比对。Mantis系统是软件行业最常使用的bug跟踪系统,在原有的统计功能上可通过定制化统计功能将上述3个指标(未修复不符合项平均Open时间、未解决不符合项数及过程失控度)通过二次开发纳入Mantis统计中,从而能够实时监控软件bug的状态;另外,通过Mantis系统能够对问题的各个纬度进行统计,包括问题的状态、项目、严重性、报告阶段、处理员等,通过这些数据能够清晰了解项目目前的缺陷状态,若出现超标和即将超标的情况,QA(Quality Assurance)人员将及时对项目报警,分析原因并采取相应措施,使项目处于一个健康状态。图2 为应用Mantis软件对bug进行处理的流程。
4 结语
目前,我国汽车软件的开发和管理能力与世界水平还存在一定差距,要开发高可靠性与稳定性的软件产品必须建立良好的软件工程文化和管理制度。本文基于CMMI开发模型,建立了软件开发流程及管理制度,有效提高了开发效率,缩短了开发周期。此外,软件质量保证体系的建立,可通过自查、评审、测试等活动在软件开发前期发现软件缺陷,从而大大降低因后期更改而带来的巨大维护成本,有效地提升了软件开发质量,加快软件管理的规范化进程。
参考文献
[1]周桂钧,周禄华.基于CMMI的空管系统软件管理技术研究及应用[J].计算机安全,2013(5):2-5.
[2]卡内基梅隆大学软件研究院.CMMI开发模型V1.3[M].赵悦,等,译.2010:39-43,211-221.
[3]刘婧.软件过程改进研究[J].软件导刊,2013(5):11-12.