CMMI简介及CMMI2级的实施方案设计(DOC).docx

该【CMMI简介及CMMI2级的实施方案设计(DOC) 】是由【xiaobaizhua】上传分享，文档一共【13】页，该文档可以免费在线阅读，需要了解更多关于【CMMI简介及CMMI2级的实施方案设计(DOC) 】的内容，可以使用淘豆网的站内搜索功能，选择自己适合的文档，以下文字是截取该文章内的部分文字，如需要获得完整电子版，请下载此文档到您的设备，方便您编辑和打印。CMMI简介及CMMI2级的实施方案设计
第一部分CMMI简介:
CMMI全称是CapabilityMaturityModelIntegration,,即软件能力成熟度模型集成模型,是由美国国防部与卡内基-梅隆大学和美国国防工业协会共同开发和研制的。 CMMI
(CMMI-SE/SW/IPPD),主要应用于软件业项目,帮助提升对软件项目的管理能力。随着模型本身的发展与应用的推广,CMMI逐渐演变成为了一种被广泛采用的综合性模型。在业界广泛使用的传统软件研发流程会带来一个严重的问题:存在于设计阶段的一个微小缺陷可能会直到后期的测试阶段才能被发现,而整个公司可能会花费数十倍甚至百倍的代价来改正这个缺陷。为此,人力资源管理、软件采购、集成产品和过程开发、以及系统工程等等,多元化覆盖范围越来越广的能力成熟度模型应运而生。
CMMI的作用
软件能力成熟度集成模型(CMMI)经过长期积累和不断地优化,已经成功地发展并被认可为软件研发领域的标准过程体系,通过CMMI可以增强企业核心竞争力、有效地提高软件企业产品质量,国内乃至国际上的广大软件厂商都已经见证了CMMI为企业带来的成功。目前众多业界的软件企业纷纷试图使用CMMI来达到过程改进的趋势,怎样才能将过程改进有效地实施,使其能实质地对软件研发过程起到优化效果,并带来行之有效地经济价值,已经逐渐成为了软件企业的决策者们最为关心的问题。由最新SEI评估报告中的数据显示,在进行了CMMI的评估的企业中,大部分都是商业组织,并且其中近一半的企业人员规模都是在100人以下。种种迹象均表明,CMMI评估已经不仅仅吸引了大型IT企业的注意力,同样存在大量的中小型企业也对此抱有浓厚的兴趣。对软件企业来讲,CMMI可以主要应用在两个地方:企业软件过程的改进和企业软件过程能力的评估。
过程改进
对软件来说,要对其进行过程改进需要企业中的所有成员都参加的,这个过程不是一次性的,而是长久持续的不断循环过程。CMMI制定了一整套的目标和框架来对软件企业的成熟度进行定义和诠释。这些目标和框架那个对软件过程中的关键活动做出了很详细地定义,还对软件工程和过程管理的提出了一系列具有参考价值的成功实践。软件企业可以在实施过程中根据自身情况采用成功实践中的经验来对软件开发的整个过程进行指导,从而有效地对自身软件过程不断改进。
能力评估
目前CMMI可以通过两种不同的方式来对软件过程的成熟度进行评估:软件能力评价以及软件过程评估。
软件过程评估:该评估方式主要用来评价和估量组织内部当前的软件过程管理状态和当前的软件过程优化问题。软件过程评估会将评估结果向企业领导层进行汇报,从而使领导层成为过程改进的坚强后盾。
软件能力评价:主要用来辨识或者监督软件承包方的软件研发和管控能力。软件能力评价的注意力主要基于在保证预算的前提下,能够按照预期的进度提交高质量的软件产品,并能够应对可能存在的诸多风险。
CMMI的成熟度模型

一件产品的开发过程越规范,说明该组织的能力成熟度越高。软件开发项目的管理能力越高,最终的软件产品质量也就越好。CMMI能力成熟度模型分为五个等级,按照级别依次为(高——低),见图1:

1、 初始级(Initial):
所有没有经过CMMI能力成熟度模型的指导,并根据模型执行过开发过程改进活动的软件企业,其软件产品开发过程都被看做是初始级。
2、 受管理级(Managed)
具备了为每个软件开发项目定义明确目标、清晰过程的软件企业,可以被认定为处于受管理级的级别。通过了受管理级评估的软件企业,我们可以认为其在软件开发的过程中执行了适当的监控措施。
3、 已定义级(Defined)
如果企业已从其运作过的历史项目之中,提取出一套行之有效的项目开发规范,该企业可以被认定为处于已定义级的级别。“已定义级”可以在企业的所有项目的标准开发过程中推广使用,但是“受管理级”却只能在指定的项目中实施。
4、 定量管理级(Quantitativelymanaged)
已经能通过采取一系列量化的指标作为衡量标准的软件产品管理方式,则该企业可以被认定为处于定量管理级的级别。只要是具备定量管理级能力的软件企业,都能做到为实现软件产品的最终质量和项目过程的效率,创立一系列量化的目标,且运用了统计的方法来管理项目过程。“定量管理级”和“已定义级”之间的区别体现在对项目过程效率的预测与控制,处于“定量管理级”企业的软件产品开发过程管理是定量的。
5、 持续优化级(Optimizing)
已经具备通过执行一定的过程规范,对软件过程不断地进行改进,并且该过程是可持续的,可以被认为是处于持续优化级的级别。达到持续优化级的软件企业,可以根据自身的商业目标对的开发过程制定改善目标,并在开发过程中持续不断地进行改善。
:
不同的诸多过程域组合在一起,形成了CMMI的每个成熟度等级一一不包含初始级,所以CMMI开发模型共有项目管理、支持类、过程管理类、工程类四个类别包括22个相关过程域。CMMI过程域结构:每个过程中设定了通用目标和特定目标,每个目标下由若干惯例组成。这些惯例是根据各个软件组织长期开发实践活动的成功经验逐渐总结、提炼形成的,被认为是具有共性的最佳惯例。由于成熟度的各个等级之间是循序渐进的关系,所以如果想要达到某个成熟度等级,例如已定义级
Defined),除了满足该级本身的过程域之外,还要满足受管理级(Managed)的所有过程域。CMMI的模型层次结构如下图2所示。
感熟度暮Sk|
过程3
述圜3

CMMI过程域过程域(ProcessArea),简单的说就是做好一个事情的某一个方面。对应软件开发来说,就是做好软件开发的某一个方面。
CMMI2、3级共有18个过程域(PA),主要内容如下,分四大类:
过程管理:
OPD:(OrganizationalProcessDefinition)组织级过程定义。建立和维护有用的组织过程资产。
OPF:(OrganizationalProcessFocus)组织级过程焦点。在理解现有过程强项和弱项的基础上计划和实施组织过程改善。
OT:(OrganizationalTraining)组织培训管理。增加组织各级人员的技能和知识,使他们能有效地执行他们的任务。
OPP:(OrganizationalProcessPerformance)组织过程性能。建立与维护组织过程性能的量化标准,以便使用量化方式的管理项目。
OID:(OrganizationalInnovationandDeployment)组织的创新与推展,选择并推展渐进创新的组织过程和技术改善,改善应是可度量的,所选择及推展的改善需支持基于组织业务目的的质量及过程执行目标。
项目管理:
PP:(ProjectPlanning)项目计划。保证在正确的时间有正确的资源可用。为每个人员分配任务。协调人员。根据实际情况,调整项目。
PMC:(ProjectMonitoringandControl)项目监督与控制。通过项目的跟踪与监控活动,及时反映项目的进度、费用、风险、规模、关键计算机资源及工作量等情况,通过对跟踪结果的分析,依据跟踪与监控策略采取有效的行动,使项目组能在既定的时间、费用、质量要求等情况下完成项目。
SAM:(SupplierAgreementManagement)供应商协议管理。旨在对以正式协定的形式从项目之外的供方采办的产品和服务实施管理。
IPM:(IntegratedProjectManagement)集成项目管理。根据从组织标准过程剪裁而来的集成的、定义的过程对项目和利益相关者的介入进行管理。
10)RSKM:(RiskManagement)风险管理。识别潜在的问题,以便策划应对风险的活动和必要时在整个项目生存周期中实施这些活动,缓解不利的影响,实现目标。
11)QPM:(QuantitativeProjectManagement)量化的项目管理,量化管理项目已定义的项目过程,以达成项目既定的质量和过程性能目标。
(3)工程管理:
⑵RD:(RequirementDevelopment)需求开发。需求开发的目的在于定义系统的边界和功能、非功能需求,以便使用户(客户、最终用户)和项目组对所开发的内容达成一致。
REQM:(RequirementManagement)需求管理。需求管理的目的是在客户和软件项目之间就需要满足的需求建立和维护一致的约定。
TS:(TechnicalSolution)技术解决方案。在开发、设计和实现满足需求的解决方案。解决方案的设计和实现等都围绕产品、产品组件和与过程有关的产品。
PI:(ProductIntegration)产品集成。从产品部件组装产品,确保集成产品功能正确并交付产品。
VER:(Verification验证。验证确保选定的工作产品满足需求规格。
VAL:(Validation)确认。确认证明产品或产品部件在实际应用下满足应用要求。
(4)支持管理:
CM:(ConfigurationManagement)配置管理。建立和维护在项目的整个软件生存周期中软件项目产品的完整性。
PPQA:(ProcessandProductQualityAssurance)过程和产品质量保证。为项目组和管理层提供项目过程和相关工作产品的客观信息。
MA:(MeasurementandAnalysis)度量与分析。开发和维持度量的能力,以便支持对管理信息的需要。作为改进、了解、控制决策。
DAR:(DecisionAnalysisandResolution)决策分析。应用正式的评估过程依据指标评估候选方案,在此基础上进行决策。
CAR:(CausalAnalysisandResolution)原因分析与解决,识别缺失的原因并进行矫正进一步的防止未来再次发生。

成熟度级别
过程域
过程域类别
CMMI2级:受管理级(Managed)
REQM:(RequirementManagement)需求管理
工程管理
PP:(ProjectPlanning)项目计划
项目管理
PMC:(ProjectMonitoringand
Control)项目监督与控制
项目管理
SAM:(SupplierAgreementManagement)供应商协议管理
项目管理
MA:(MeasurementandAnalysis)
度量与分析
支持管理
PPQA:(ProcessandProductQualityAssurance)过程和产品质量保证
支持管理
CM:(ConfigurationManagement)
配置管理
支持管理
RD:(RequirementDevelopment)
工程管理
CMMI3级:已定义级(Defined)
需求开发
TS:(TechnicalSolution)技术解决
方案
工程管理
PI:(ProductIntegration)产品集成
工程管理
VER:(Verification)验证
工程管理
VAL:(Validation)确认
工程管理
OPD:(OrganizationalProcessDefinition)组织级过程定义
过程管理
OPF:(OrganizationalProcess
Focus)组织级过程焦点
过程管理
OT:(OrganizationalTraining)组织
培训管理
过程管理
IPM:(IntegratedProjectManagement)集成化项目管理
项目管理
RSKM:(RiskManagement)风险管
理
项目管理
DAR:(DecisionAnalysisandResolution)决策分析
支持类
CMMI4级:定量管理级
(Quantitativelymanaged)
OPP:(OrganizationalProcessPerformance)组织过程性能
过程管理
QPM:(QuantitativeProject
Management)量化的项目管理
项目管理
CMMI5级:持续优化级
(Optimizing)
OID:(OrganizationalInnovationandDeployment)组织的创新与推展
过程管理
CAR:(CausalAnalysisandResolution)原因分析与解决
支持管理
CMMI改进的六项基本原则
(1)重要的软件过程改进必须是从高层到下层的依次进行。过程改进的启动、改进活动的优先安排、持续的资源支持等等,都离不开高级管理层的领导;
(2)必须人人都参与。树立团队意识,软件工程的改进是整个团队共同的活动;
(3)改进需要认清现状,了解当前的过程,树立明确的目标;
(4)持续的进行改进。软件过程不能一蹴而就,需要不断持续的学****和提高;
(5)过程改进不会自发进行,持久的软件过程改进需要有意识的推动和周期性的增强。
(6)软件过程改进需要大量的投资。无论是在时间上、个人技能上还是资金上,都需要不菲的投资。
第二部分CMMI2的实施方案设计

确定改进模型等级
考虑到本次实施过程改进的机构为研发部门,而研发部门各项目组成员均在10人以
下,固选用CMMI-2级作为本次过程改进的模型。
确定过程机构及人员
1、 Sponsors(发起者)
发起者包括总经理及所有SEPG组成员,主要职责包括:从最上层开始推动SPI;支持过程改进,提供足够的资源、允许项目计划作适当调整对过、改进执行较好的给予奖励帮助解决冲突,每月开一次会议检讨工作进展
2、 SEPGLeader(软件工程过程改进组组长)
SEPGLeader主要职责为:制定SPI计划,并实施SPI计划;组织SEPG组的工作,制定OSSP;新过程试用、评估,推动OSSP的实施;为工作组提供培训和支持;维护过程数据库;阶段性评估软件过程,每月进行工作总结,并向发起者汇报工作进展。
3、 SEPG(软件工程过程改进组)
SEPG组成员及其分工如下,见表2。

姓名
过程改进职责说明
项目角色
甲
EPG组长,负责推进和督导过程改进
研发部门经历
乙
EPG组员,负责项目监控PMC
项目经理
丙
EPG组员,负责项目规划PP、需求管理RM
项目经理
丁
EPG组员,负责配制管理CM
美工
戊
EPG组员,负责度量与分析MA
开发经理
己
EPG组员,负责过程与产品品质保证PPQA
测试经理
庚
EPG组员,负责供应商合约管理SAM
公司执行经理
4、 WorkingGroup(工作组)
工作组是具体实施CMMI体系的项目组成员,应积极参与过程改进。SEPG要对工作组的工作给予支持。
5、 SPIConsultant(软件过程改进顾问)中国软件评测中心
制定过程改进规程
方针与目标
EPG作为软件过程制定和优化的专业小组在公司长期存在;
其组长由公司任命并直接向公司高层管理负责;
公司的目标是在项目启动一年内通过CMMI二级评估;
系统集成和软件过程改进要结合市场特点和实践,有可操纵性;
注意工作阶段重点和工作的逐步完善;
确定公司的过程改进计划。
公司要执行的过程标准和产品标准
定期评估和改进策划
按照CMMI的评估模型开展公司的升级评估和内部小评估,评估时间可在每年的管理发展计划中规定。
改进策划:1)将ISO/CMMI过程评估结果作为改进策划的主要输入;2)定义待改进的活动和这些活动的时间表;3)规定负责这些活动的组及个人;4)确定所要求的资源,包括资金和工具;5)当计划首次发行及每当修改时,需经评审;6)受到组织的软件经理和高级经理的评审和批准。
,在应用到试点、推广项目时各过程域的计划文档需要经过评审并得到
EPG组长的认可后方可执行。具体项目中的需求文档则必须经过同行评审通过后方可纳入配置管理。评审流程:1)各过程域计划文档提交QA;2)QA跟据产品审计检查单对计划内容、格式等进行审计;3)QA审计通过后召开评审会,进行会签,生成评审记录;4)需求产生和变更需要提交项目组成员进行同行评审,获取每个成员的认可后由项目经理召开评审会,生成评审记录。

EPG小组负责将公司的标准过程在全公司范围内推广。推广流程:1)定义过程体系文件和模版;2)选择试点项目运行已建立的体系;3)总结试点中的成果,优化已有的体系;4)将优化后的体系运用到推广项目中;5)再次总结和优化体系并更广泛的推广。过程改进流程:
一、流程:
总结出过程体系存在的问题;
EPG小组开会对总结出的问题进行分析,并创建出更适合的过程体系;
将新的体系试用于一个项目,由QA观察实施效果;
若新体系实施效果良好,则将其在整个研发部范围内实施;若效果不好,则重复2);
5)记录过程改进的成果。二、触发条件:
在执行完一个项目后;
在项目开发中发现体系不适用;
咨询师检查后给出更加好的建议;
、文档模板、教程置于组织财富库中,并指定人员进行维护。1)存
放位置:OUTLOOK'公用文件夹\所有的公用文件夹\公共信息\CMMI文档;2)维护人员:EPGLeader,配置管理员。
所需培训和技能组织人员进行项目组的新过程的培训工作。培训规程:1)在建立体系前对各过程域负
责人作专业培;2)在具体项目启动前对项目组相关人员作CMMI相关培训;3)当有新加入的项目成员时,单独对其进行CMMI相关培训;4)当有新过程发布时,对新过程的改进点及使用作培训。
工具与设备要求
OUTLOOK:作为组织财富库存放最新的过程体系相关文件;
MicrosoftVisualSourceSafe:作为配置库建立地址;
mtc-05服务器:存放CMMI所有过程改进相关文件;
WSS站点、rdsd-06服务器:均可作为具体项目的数据管理库存放地址,由项目经理在项目计划中指定。
:1)员工的知识和技能不足:安排专业培训EPG小组权威不够,总经办思想不完全统一,对工作的支持和理解不够,流程制定后无法有效的实施2)因为EPG成员大多是兼职,在与具体的项目进度产生资源冲突的情况下,比较难确定优先级,EPG小组的工作优先级可能会降低3)一年内达到CMMI2级的目标是否能够达到,在这么短的时间内是否能够找到一个有效的过程;4)在强大的市场压力和时间进度压力下,是否能够保证有效的实施CMMI。

过程改进计划,见表3:

里程碑
活动
日期
参与者
成功标准
1
建立符合CMMI2即标准的可操作的过程文件
2014-10
EPG小组成员
建立符合2级标准的可操作过程文件,并通过评审
2
选择试点项目推行过程体系,指定过程域的负责人,启动试点项目
2014-12
EPG小组成员,试点项目成员,公司高层
各过程域有指定的负
责人,试点
3
试点项目总结
2015-4
EPG小组
总结CMMI体系在试点中的推广效果,提取出好的经验和不足之处
4
评审修正后的过程体系
2015-5
EPG小组
建立起更优化的体系
5
启动推广项目,正式应用过程体系
2015-6
EPG小组成员、试点项目成员、公司高层
推广项目建立优化后的过程体系,制定各过程域责任人
6
预评估
2015-9
评估师、EPG小组成员、公司高层
识别到项目前体系和
CMMI2级标准的偏差,并进一步优化过程体系
7
正式评估
2016-1
评估师、EPG小组成员、公司高层
通过正式评估的结果
进一步优化过程体系


在本次过程改进中,需求管理过程域需要实现以下要求:。(如研发部门负责人、测试、质量保证、配置管理、开发)的评审。、工作产品、活动应与变化了的需求保持一致。根据CMMI对过程域的目标定义,需求管理过程域目标及输出,见表4

SG(特定目标)
说明
工作产品
对需求的理解
区别适合的需求提供者的准则
需求管理方针
确定是否理解了需求的准则
对照准则分析后所得的结果
项目需求说明书
达成一致的需求集合
对需求的承诺
需求冲突评估
用户需求确认书
需求以及需求改变的书目承诺
管理需求变更
需求状态
需求溯源性矩阵
需求数据库
需求决策数据库
需求重要度评估表
维护对需求的双向溯源性
需求溯源性度量值
需求溯源性矩阵
需求跟踪系统
识别项目工作与需求之间的不一致
关于不一致之处的文档,包括来源、条件和理由
需求变更申请书
对纠正措施的需求
需求审核报告
纠正措施

在本次过程改进中,项目计划过程域需要实现以下要求:,并在项目启动会议上明确通知相关人员(如研发部门负责人、测试、质量保证、配置管理、开发)。项目经理负责协商承诺和制定项目软件开发计划。。。(负责测试、硬件、集成等工程小组或工程人员)必须定义自己如何参与到软件项目中,并文档化。,软件规模、开发成本、时间表、承诺须由相关人员(公司高层管理者、研发部门负责人、项目管理部负责人、测试、质量保证、配置管理、开发)评审。。。根据CMMI对过程域的目标定义,项目计划过程域目标及输出,见表5.

SG
工作产品
说明
完成参数估计
《项目评估书》
包括:项目性质(确定是软件产品还是软件项目);说明项目采用的开发模型、软件技术、体系结构;以往模型和历史数据规模估计;工作量估计;成本估计;风险估计
《项目周期分析说明书》
包括:项目开发模型;模型决定的软件工程周期说明;周期中每个阶段的起始时间、大概目标和完成标准以及应该提交的工作成果;每个周期的工作量、人员组成和大概的工作成本
拟定项目计划
《项目计划书》
包括:技术预研计划、技术预研结果评审计划、产品生产周期规划、技术管理目标、开发目标、预算和进度计划、里程碑、数据管理、项目涉及的软件技术和人员技能、项目组人员组成,角色分配和岗位职责
《项目计划变更书》
包括:变更原因说明、详细变更说明、变更的影响分析说明
《项目计划变更记录表》
记录项目计划每次变更时间、内容和简要说明
获得对计划的承诺
《项目计划评审表》
包括:项目计划评审内容、评审标准,评委评审意见
《项目计划评审报告》
记录说明项目评审委员会根据每