CMMI体系简介及软件工作流程
CMMI体系简介及软件工作流程
质量管理部
2009年03 月
华丽娜主题
第一部分:CMMI基础知识
CMMI是什么
CMMI发展和厉史
CMMI模型组件概述
第二部分:公司质量体系文件综述
公司软件过程概述
公司过程文件概述
公司体系文件导读
CMMI是什么？
◆Capability Maturity Model Integration(能力成熟度模型综合) 它综合了以下几方面:
System engineering
Software engineering
Integrated Product and Process Development
Supplier Sourcing
◆该模型提供一套可供公众使用的准则；这些准则描述那些成功地
实施了过程改进的组织的特性。
◆该模型用“软件能力成熟度”来衡量这种软件综合能力
CMMI是什么？
?美国卡内塞一梅隆大学软件工程研究所(SEI)研制。
?CMMI的前身是SW-CMM和SE-CMM
?CMMI有专门认证评估方法一SCAMPI
发展简史
草案于1997年制定(未广泛应用)。
到2000年，CMM演化成为
Software Engineering)于2002年1月正式推出。
CMMI的诞生（1）
版，经历了十多年，在这期间，IT产业有了长足的发展，相应的工
业标准或规范必然要不断地改进。
不再局限于纯粹软件的范崎。虽然人们了解和应用CMMI需要一定的
时间，但走CMMI将取代CMM这走必然的趋势。
CMMI的诞生（2）
◆CMMI为工业界和政府部门提供了一个集成的产品集，其主要目的
是消除不同模型之间的不一致和重复，降低基于模型改善的成本。
CMMI将以更加系统和一致的框架来指导组织改善软件过程，提高产品和服务的开发、获取和维护能力。
CMMI模型组件概述
CMMI分级（阶段）模型
CMMI阶段式模型的结构
CMMI连续模型表示的结构
Process Area Components
特定目标Specific Goals(SGs)
◆特定目标是针对某一个过程域，它描述为了满足这个过程域的实
施所必须做到的特殊特性
◆例如在需求管理的PA中:
SG 1:Requirements are managed and
Inconsistencies with project plans and work products are identified
特定实践-Specific Practices (SPs)
◆特定实践是为了达成某一个特定目标而需要的特定活动
◆例如:Requirements Management:
Manage changes to the requirements as they evolv during the project.
通用目标一Generic Goal (GG)
◆可用于多个过程域的“目标”称为“办共目标”
◆例如:GG2:The process is institutionalized
as a managed process.
通用实践Generic Practices (GPs)
Required, Expected, and Informative Model Components
◆Required(必须的):SG和GG
◆Expected(期望的). SP和GP
◆Informative(提供信息的):子实践、典型的工作产品、一般实
践的详细描述等
◆问题:除了 Required的组件，其他的组件可以不要吗？
你会如何组织这个活动
?某个时间，办司进行聚餐活动。
?请你组织这次活动，目的是用合理的经费让大家高高兴兴地吃一顿!
?分组讨论，5分钟时间。
CMMI等级
◆在模型中，所有软件组织的软件能力成熟度划分为5个等级一第
1到第5级。数字越大，成熟度越高。高成熟度等级代表比较强的综合软件能力。
◆5个成熟度等级分别为:
第1级:初始级
第2级:受管理级
第3级:已定义级
第4级:定量管理级
第5级:持续优化级
CMMI级别
◆每一个级别，都包合几个到十几个PA
英文全写:Process Area
中文译名:过程域
◆什么叫“过程域”
简单的说就是做好一个事情的某一方面。
对应软件开发来说，就是做好软件开发的某一个方面。
CMMI级别
◆如果该级别的全部PA达到要求了，就认为该级别达到了。
◆如何列断PA达到要求呢
每个PA包合儿个目标((Goal)
如果这个几个目标都达到要求了，就认乃该PA达到要求了
◆如何列断Goal达到要求呢
每个Goal包合几个实践(Practice)
每个实践达到要求了，就认为该Goal达到要求了
Maturity Level 1:Initial
◆初始级的过程通常是随机、混乱和无序的。这种组织通常没有一个稳定的环境，它的成功依赖于组织中个人的能力和英雄主义，而不是依赖于使用经过脸证的过程。
◆尽管这种混乱、无序的环境，处于初始级别的组织也经常能制造出能工作的产品和服务，但是，他们的项目经常是超成本和进度的。
◆处于初始级的组织有过度承诺的趋势，在危机时放弃过程，不能重复他们过去的成功。
吃饭的“初始级”
◆不用做什么计划，提前一点订好座位
◆当天下班大家一哄而去
◆现场点菜，然后大吃一顿
这样做会有什么结果？
◆定不到位
◆菜不合大家口味
◆经费超出
◆大家心情变得很沮丧
◆有没有可能取得比较好效果呢
Maturity Level 2:Managed
◆—即使在时间压力下，依然能够保留现有的实践
◆组织中的项目确保需求得到管理，过程已经计划、执行、度量和
控制。
◆管理层在某些已定义点上对工作产品的状态和提交的服务共
有可视性
◆在干系人(风险承担者)之间建立了承诺，在必要的时候进行修正CMMI-SE/SW ML2 PAs
◆需求管理
Requirement Management (REQM)
◆项目计划
Project Planning (PP)
◆项目跟踪与控制
Project Monitoring and Control (PMC)
◆供应商合同管理
Supplier Agreement Management (SAM)
◆度量分析
Measurement and Analysis (MA)
◆产品与过程质量保证
Product and Process Quality Assurance (PPQA) ◆配置管理
Configuration Management (CM)
PA不是孤立的！
CMMl ML2 总结
◆坚持既往成功实践
◆从关注结果到关注过程
◆需求和项目进展得到控制
◆理解了数据的作用
◆从更宽的视野看待项目
◆从初始级到二级是
全体人员思想的转变
是文化的转变
走向规范化的第一步
讨论:吃饭的“受管理级”
◆用2级的特征策划吃饭过程。
◆讨论5分钟。
Level2:受管理级一1
Level2:受管理级-2
这样做会有什么结果？
◆大家吃得满意
◆预算控制得好
◆老板高兴
◆真的能这样吗
2级做法遗留的一些问题
◆不需要进行风险管理吗
◆用什么方法调查大家喜欢吃什么菜式呢有指南就好了
◆如何组织聚餐活动，是不是应该有个指导或者有成功经验可供参
考？
◆……
Maturity Level 3:Defined
—建立标准的，且不断得到改进的工作方式
◆过程得到很好地表现和理解，用标准、规程、工兵和方法表述过
程，从而建立组织内的一致性
◆组织标准过程已经建立并不断得到改进
◆项目根据裁剪指南，从组织标准过程中裁剪建立项目定义的过程◆组织管理层基于组织标准过程库建立过程目标，并确保这些目标
得到适当地表达
◆2级和3级关健区别在于
标准、过程和规程的适用范围
3级的过程比2级的描述更具体和更严格
CMMI-SE/SW ML3 PAs(1)
◆需求开发
Requirements Development (RD)
◆技术解决方素
Technical Solution (TS)
◆产品集成
Product Integration (PI)
◆验证
Verification(CWR)
◆确认
Validation (VAL)
CMMI-SE/SW ML3 PAs(2)
◆组织过程焦点
Organizational Process Focus (OPF)
◆组织过程定义
Organizational Process Definition (OPD)
◆组织培训
Organizational Training (OT)
◆集成项目管理
Integrated Project Management (IPM)
◆风险管理
Risk Management (RSKM)
◆决策分析与解决方素
Decision Analysis and Resolution (DAR)
level 3:已定义级
◆经过一段时间积累，以下活动都有明确的指导文档:
如何写计划
如何组织吃饭现场活动
如何确定餐单
....
◆对于确定餐单、选定酒水供应商方面采用决策分析的办法
◆进行风险管理。
◆建立了相应的培训制度。
◆另外，为了让组织聚餐活动越做越好，成立了门的SEPG来维护文
档。
这样做会有什么结果？
◆这次活动成功的几率大大提高了
◆但谁能拍胸口说:一定能成功
3级遗留的问题
◆感觉成功机会会提高很多，但没有一个底最好有个数字能说明问
题。
Maturity Level4、:Quantitatively Managed
—不仅有标准的工作方式，逐有量化的工作标准
◆选择那些对整体过程性能有较大影响的子过程进行统计和其它量
化手段控制。
◆制订质量和过程性能的量化目标，并贯串整个生命周期中;以统计
“词汇”理解质量和过程性能。
◆收集受控过程的度量数据，分析其性能。如果出现偏差，分析其
出现的(特殊)原因，以防止其今后再次出现。
◆质量和过程性能的数据要纳入到组织度量数据库中，以便帮
助今后进行客观的决策。
◆与3级的最大区别走，4级可以对过程性能进行预侧。
CMMI-SE/SW ML4 PAs
◆组织过程性能
Organizational Process Performance (OPP)
◆量化项目管理
Quantitative Project Management (QPM)
Maturity Level 5:Optimizing
—以量化为手段，以解决本质问题乃核心的持续改进
◆建立量化过程改进目标，并与商业目标的变化同步。
◆识别出针对根本原因(或根本问题)的过程改进方法，评佑其能否
满足
◆量化过程改进目标;对这些改进方法进行评佑、诚脸和推广。
◆组织过程应该走持续改进的
◆过程优化走否灵活并富于创造性，取决于参与其中的人是否理解
组织的商业价值和商业目标，而且：
过程改进，人人有责;
要改进标准过程，也要改进项目过程。
◆与4级本质区别:5级解决根本问题，4级解决特殊问题。
CMMI-SE/SW ML5 PAs
◆组织创新与部属
Organizational Innovation and Deployment
(OID)
◆原因分析与解决方素
Causal Analysis and Resolution (CAR)
某企业通过了某某级别的评估，意味着什么
◆评估是对企业准备的几个评佑项目按照CMMI的标准进行检查。
◆企业可以准备任意数量的项目，评佑的项目是企业有己指定的。
◆通过评佑，只代表评估小组认为参加评估的几个项目达到了CMMI
某个级别的标准。
◆通过评佑，不代表这个企业其它项目也达到了要求，也不代表这
个企业以后也会达到这个标准。
第二部分:公司质量体系文件综述
公司软件过程概述
公司过程文件既述
公司体系文件导读
软件过程概述
我公司软件产品的生产是以项目形式进行的
项目又分成三种类型号
研发类
工程类
维护类
研发类项目的任务
◆新产品的研发:进行产品的需求开发、解决方案设计、代码构建和
产品的初步集成，形成产品的核心版本。
◆产品线维护研发:对合同类实施和维护项目进行版本支持。
工程类项目的任务
◆依据与用户的合同、软件需求规格说明书等文件，对研发组提供
的核心版本进行确认侧诚，完成产品的最终集成，以及产品的部署、安装等工作，直到把产品交付给用户。
维护类项目的任务
◆在合同规定的产品维护期内，应用户的要求，完成产品的一些边
缘功能的开发，负责产品的一般性客户服务工作，配合产品维护
研发组完成产品的版本维护。
软件产品的开发活动
◆分成准备、计划、研发、测试、验收等五个阶段，CMMI中各个PA
在这些阶段中的相互关系，以及它们和公司各有关部门之间的关系如下图所示:
软件开发流程和职能：
软件开发流程
◆CMMI的四类PA在软件产品开发流程中的顺序和相互关系如图二
所示。图中淡蓝色框表示CMM!中的PA;淡黄色框不是CMMI中的PA。图中蓝色箭头表示的流程走开发过程中的主要流程，应根据不同的开发方法而采用适当的递归和迭代。黄色箭头表示的流程走辅助流程。
软件开发流程
软件产品维护流程
过程文件概述
◆公办司实际，实现了文档化。这些过程文件叙述软件产品开发活
动的过程、过程做什么、怎么做、怎么评枯绩效，以及怎么持续改进等问题。
体系文件构成
◆CMMI软件过程改进体系文件由三部分组成:
◆《质量手册》:在原来的《质量手册》基础上，改写其中有关软
件开发部分
◆《软件过程文件》:程序文件和作业指导书
◆《软件过程模板》:模板、表格、样件、示例
◆体系文件下载:OA一知识中心一常用文档一质量管理系统文件活动元素
◆概述
◆参与人员及职责
◆入口准则
◆输入
◆任务/步骤
◆出口准则
◆输出(工作产品）
◆资源和能力要求
◆度量
◆剪裁指南
软件过程文件
◆软件过程文件分三个层次
程序文件
作业指导书
模板
◆CMMIL2 、L3中的17个PA(我们剪裁了供产商协议管理)对应16
个程序文件、32个作用指导书和81个模板
作业指导书(规范/指南)
◆作业指导书统一用规范或指南的名称，它们的作用是详细描述程
序文件中比较复杂的活动，必要时引用模板。作业指导书的格式基本与程序文件相同。
模板
◆模板可以被作业指导书或程序文件引用。它们具体给出程序文件
或作业指导书中用到的说明书、记录、表格等的格式和细节，方便使用者应用。
标准过程
◆软件过程文件中描述的过程，都是办司的标准过程。
◆项目组可以根据剪我指南和项目的实际情况，对标准过程进行剪
裁以得到项目组的定义过程。
◆项目组执行其已定义过程，项目组也可以直接应用公司的标准过
程。
◆项目组采用什么样的软件过程应在“项目计划”中说明。
研发项目标准过程
工程项目标准过程
维护项目标准过程
公司体系文件导读
各职位体系学习质量管理体系指引
cmmi软件生产过程标准
何谓CMM? CMM是由美国卡内基-梅隆大学的软件工程研究所(SEI)推出的评估软件能力与成熟度的一套模型。它侧重于软件过程开发的管理及软件工程能力的改进与评估，是目前国际上最流行、比较实用的一种软件生产过程标准，成为当今企业从事规模软件生产不可缺少的一项内容。CMM模型共分为五个级别：初始级、可重复级、定义级、管理级和优化级。 软件工程：什么是CMMI? CMMI全称是Capability Maturity Model Integration, 即软件能力成熟度模型集成模型，是由美国国防部与卡内基-梅隆大学和美国国防工业协会共同开发和研制的。CMMI是一套融合多学科的、可扩充的产品集合，其研制的初步动机是为了利用两个或多个单一学科的模型实现一个组织的集成化过程改进 CMMI分为五个等级，二十五个过程区域（PA）（如图所示）。 1．初始级软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。 2．已管理级建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。 3．已定义级已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。 4．量化管理级分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。5．优化管理级过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。 每个等级都被分解为过程域，特殊目标和特殊实践，通用目标、通用实践和共同特性： 每个等级都有几个过程区域组成，这几个过程域共同形成一种软件过程能力。每个过程域，都有一些特殊目标和通用目标，通过相应的特殊实践和通用实践来实现这些目标。当一个过程域的所有特殊实践和通用实践都按要求得到实施，就能实现该过程域的目标。 CMMI的原则、目标和方法 一、CMMI的原则： 1．强调高层管理者的支持。过程改进往往也是由高层管理者认识和提出的，大力度的、一致的支持是过程改进的关键。 2．仔细确定改进目标，首先应该对给定时间内的所能完成的改进目标进行正确的估计和定义并制定计划。选择能够达到的目标和能够看到对组织的效益。 3．选择最佳实践，应该基于组织现有的软件活动和过程财富，参考其他标准模型，取其精华去其糟粕，得到新的实践活动模型。 4．过程改进要与组织的商务目标一致，与发展战略紧密结合。 二、CMMI目标:
cmmi软件开发流程
软件开发流程软件项目生命周期模型
需求分析 需求分析流程图 过程描述 1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。
2、PM制定需求阶段日程表，该表须通过研发经理审核。 3、PM指示配置管理员建立配置库。 4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。 5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。 6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。 7、项目组人员与客户进行沟通，编写需求清单列表。 8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。 对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠性等)、技术的发展前景、 供应商资质与实力等)及相对优先级，采用讨论表决的方法选择并确定最终的技术方 案。 关于自行开发和采购复用的分析， 如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、测试用例等)，一般应进行复用； 本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本在项目可接 受范围内，可考虑采购； 否则，由项目组自行开发。 架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。 9、PM召集临时项目组、测试负责人等技术骨干评审架构设计书和需求规格书。 10、PM组织临时项目组与客户沟通、说明需求，必要时编制系统原型向客户展示，直到临时项目组、客户就需求的真实含义达成共识、客户书面确认需求规格书为止。 11、临时项目组确定项目目标的范围，明确系统边界，建立系统的模块分解结构。 12、PM与测试负责人遵循《项目估算流程》组织人员进行项目估算。 13、PM、测试负责人与临时项目组确定项目关键参数。 工作量、工期、日程、人数 成本/预算（由于本公司的项目的绝大部分成本是人力成本，对估计成本的管理等同于估计工作量的管理，对实际成本的管理等同于实际工作量的管理，对预 算的管理等同于计划工作量的管理。） 质量目标 14、PM、测试负责人与部门经理协调人员及资源、计划知识技能、协调相关干系人的参与。 15、项目组基于公司环境标准，结合项目实际情况建立适合的工作环境。 16、PM、测试负责人编制项目计划书。 17、PM、测试负责人编制项目日程表。 18、临时项目组、研发部、QA评审项目计划书，评审通过后正式生效。 19、PM指示配置管理员建立配置基线。 20、PM编制阶段总结报告（项目总结报告中的度量分析页面），召开阶段会议。
cmmi软件开发流程
c m m i软件开发流程 Prepare d on 24 November 2020
软件开发流程软件项目生命周期模型
需求分析 需求分析流程图 过程描述 1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。
2、PM制定需求阶段日程表，该表须通过研发经理审核。 3、PM指示配置管理员建立配置库。 4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。 5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。 6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。 7、项目组人员与客户进行沟通，编写需求清单列表。 8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。 ?对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠性等)、技术的发展前景、供应商资质与实力等)及相对优先级，采用讨论表决的方法选择并确定最终的技术方案。 ?关于自行开发和采购复用的分析， ?如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、测试用例等)，一般应进行复用； ?本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本在项目可接受范围内，可考虑采购； ?否则，由项目组自行开发。 架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。 9、PM召集临时项目组、测试负责人等技术骨干评审架构设计书和需求规格书。 10、PM组织临时项目组与客户沟通、说明需求，必要时编制系统原型向客户展示，直到临时项目组、客户就需求的真实含义达成共识、客户书面确认需求规格书为止。 11、临时项目组确定项目目标的范围，明确系统边界，建立系统的模块分解结构。 12、PM与测试负责人遵循《项目估算流程》组织人员进行项目估算。 13、PM、测试负责人与临时项目组确定项目关键参数。 ?工作量、工期、日程、人数 ?成本/预算（由于本公司的项目的绝大部分成本是人力成本，对估计成本的管理等同于估计工作量的管理，对实际成本的管理等同于实际工作量的管理，对预算的管理等同于计划工作量的 管理。） ?质量目标 14、PM、测试负责人与部门经理协调人员及资源、计划知识技能、协调相关干系人的参与。 15、项目组基于公司环境标准，结合项目实际情况建立适合的工作环境。 16、PM、测试负责人编制项目计划书。 17、PM、测试负责人编制项目日程表。 18、临时项目组、研发部、QA评审项目计划书，评审通过后正式生效。 19、PM指示配置管理员建立配置基线。 20、PM编制阶段总结报告（项目总结报告中的度量分析页面），召开阶段会议。
cmmi软件开发流程
c m m i软件开发流程 公司内部编号：（GOOD-TMMT-MMUT-UUPTY-UUYY-DTTI-
软件开发流程软件项目生命周期模型
需求分析需求分析流程图
过程描述
1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。 2、PM制定需求阶段日程表，该表须通过研发经理审核。 3、PM指示配置管理员建立配置库。 4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。 5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。 6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。 7、项目组人员与客户进行沟通，编写需求清单列表。 8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。 对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事 先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠 性等)、技术的发展前景、供应商资质与实力等)及相对优先级，采用讨 论表决的方法选择并确定最终的技术方案。 关于自行开发和采购复用的分析， 如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、 测试用例等)，一般应进行复用； 本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本 在项目可接受范围内，可考虑采购； 否则，由项目组自行开发。 架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。
CMMI体系简介及软件工作流程
CMMI体系简介及软件工作流程 质量管理部 2009年03 月 华丽娜主题 第一部分:CMMI基础知识 CMMI是什么 CMMI发展和厉史 CMMI模型组件概述 第二部分:公司质量体系文件综述 公司软件过程概述 公司过程文件概述 公司体系文件导读 CMMI是什么？ ◆Capability Maturity Model Integration(能力成熟度模型综合) 它综合了以下几方面: System engineering Software engineering Integrated Product and Process Development Supplier Sourcing ◆该模型提供一套可供公众使用的准则；这些准则描述那些成功地 实施了过程改进的组织的特性。
◆该模型用“软件能力成熟度”来衡量这种软件综合能力 CMMI是什么？ ?美国卡内塞一梅隆大学软件工程研究所(SEI)研制。 ?CMMI的前身是SW-CMM和SE-CMM ?CMMI有专门认证评估方法一SCAMPI 发展简史 草案于1997年制定(未广泛应用)。 到2000年，CMM演化成为 Software Engineering)于2002年1月正式推出。 CMMI的诞生（1） 版，经历了十多年，在这期间，IT产业有了长足的发展，相应的工 业标准或规范必然要不断地改进。 不再局限于纯粹软件的范崎。虽然人们了解和应用CMMI需要一定的 时间，但走CMMI将取代CMM这走必然的趋势。 CMMI的诞生（2） ◆CMMI为工业界和政府部门提供了一个集成的产品集，其主要目的 是消除不同模型之间的不一致和重复，降低基于模型改善的成本。 CMMI将以更加系统和一致的框架来指导组织改善软件过程，提高产品和服务的开发、获取和维护能力。 CMMI模型组件概述 CMMI分级（阶段）模型 CMMI阶段式模型的结构
汽车电子CMMI软件开发流程
汽车电子软件开发流程 ——CMMI篇 作者:朱忠安 版本: 1.0 状态:草版
1历史记录
2索引 1历史记录 (2) 2索引 (3) 3概要 (4) 4一般嵌入式系统开发简介 (5) 4.1嵌入式系统定义 (5) 4.2嵌入式系统的开发组织架构 (5) 4.3嵌入式系统软件开发流程图 (6) 4.4流程图简介 (7) 5CMMI软件团队解析 (8) 5.1CMMI软件开发流程标准 (8) 5.2软件研发组织架构解析 (9) 5.3软件项目开发过程 (9) 5.4系统测试组织结构 (9) 6CMMI软件项目变更管理 (10) 6.1软件变更控制工具介绍 (10) 6.2软件变更控制流程 (10) 7软件开发知识简介 (11) 7.1软件开发的特点 (11) 7.2如何做好软件开发 (11) 7.2.1客户角度 (11) 7.2.2供应商角度 (11)
3概要 本着为客户服务的宗旨，让更多的想进入汽车研发团队的工程师们了解和熟悉的软件开发流程，减少项目开发过程中不必要的误解，故做此介绍抛砖引玉。
4一般嵌入式系统开发简介 4.1嵌入式系统定义 对于嵌入式系统，一般教科书上面有这样定义：以应用为中心，以计算机技术为基础，软硬件可裁剪，系统对功能、可靠性、成本、体积、耗电量和应用环境，有特殊要求的专用计算机系统，是将应用程序、操作系统和计算机硬件集成在一起的系统。 其实这句话不难理解，概括起来只有两点： <1>计算机系统 任何一个嵌入式系统必定是一个计算机系统,而最基本的计算机系统无外乎CPU,内存,输入设备,输出设备;嵌入式系统也是如此. 谈到这里,就必须要说到两个概念:微处理器和微控制器. 所谓微处理器很容易理解,就是中央处理器CPU,比如所ARM9,它的为处理器就是ARM920T.换句话说就是嵌入式系统的核心控制单元. 所谓微控制器,其实也不难理解;我们现在大部分的电子产品所使用的都是集成芯片,也就是一块芯片中不仅仅包含的是CPU,还把许多的外围设配都集成在一块芯片中,比如把PWM控制器，把flash，把音频处理器，把内存，把输入输出设备等都集成在一块芯片中，这样的一块集成多功能的芯片就是微控制器。基本上一块IC就是一个小型的嵌入式系统。这样的做的好处也是显而易见的：<1>可以减少嵌入式系统设计的复杂度；<2>节省成本,因为一块集成多功能的IC,比你去用一块CPU搭建外围设备的成本要少的多。 <2>特定应用 对于嵌入式产品的开发，一般都是具有特定的应用；根据特定的需求去定制的。比如仪表，一套完整的仪表系统，都是只适合与特定款型的车。因为电子产品的性质各有不同，嵌入式系统的开发也很难有一套统一的标准，没有一个国际标准组织或学术单位，规定嵌入式系统一定要用什么CPU，用什么开发语言，一定要用什么操作系统，一定要用哪一套开发工具。只会根据特定的需求去定制。 4.2嵌入式系统的开发组织架构 一般的研发团队都有很严谨漂亮的组织架构，嵌入式系统的研发团队也是如是；至少应该有以下小组。 <1>项目管理组 <2>硬件组 <3>产品外观和结构设计组 <4>软件组 1）软件项目管理组 2）固件组 3）系统组
CMMI需求开发
成熟度3级的工程过程域 目的 需求开发(Requirements Development, RD)的目的，在于产出并分 析客户、产品及产品组件的需求。 业界注释 本过程域描述客户、产品及产品组件等三种需求，这些需求说明相 关关键人员的需要，包括与产品生命周期各阶段 (如，验收测试准 则)及产品属性 (如，安全性、可靠性、与维护能力等) 有关的需 要。需求也包括选择某设计解决方案而产生的限制条件。例如：与 现成品整合的需求。 所有开发项目都有需求，从项目于维护活动的项目案例来看，产品 或产品组件的变更，是基于现有需求、设计、或实作的变更。需求 变更可能来自顾客或用户所记载的变更请求单，或来自于需求开发 过程的新需求形式。不论需求来源或型式，变更所驱动的维护活动 也要加以管理。 需求是设计的基础，需求的开发包括下列活动： 引导、分析、验证，以及沟通客户的需要、期望及限制，以获 得客户需求，并达成关键人员的共识 搜集和协调关键人员的需要 开发产品的生命周期需求 建立客户需求 建立与客户需求一致的原始产品及产品组件需 因为客户也可能提出特定的设计需求，本过程域讨论所有客户的需 求，而非局限于产品层次的需求。 客户需求可进一步细化为产品及产品组件需求。除客户需求外，选 定的解决方案也可能衍生产品及产品组件需求。整个过程域中，产 品及产品组件的意涵也包括服务及其组件。 在整个产品生命周期中识别并修订需求。对设计决策、后续的纠正 措施，以及产品生命周期各阶段所产生的回馈进行分析，以了解它 们对衍生及已配置需求的影响。 需求开发过程域包括三项特定目标。”开发客户需求」特定目标说 明如何定义完整的客户需求，以使用于产品需求开发。”开发产品 需求」特定目标说明如何定义完整的产品和产品组件需求，以使用 于产品和产品组件设计。”分析并确认需求」特定目标说明客户、 产品及产品组件需求须执行的必要分析，以定义、衍生及了解需求。 第三项特定目标的特定执行方法，用以辅助前两项特定目标的特定
cmmi软件开发流程
cmmi软件开发流程
软件开发流程软件项目生命周期模型
需求分析 需求分析流程图 需求分析 客户 部门经理 临时项目组 输入/输出 EPG QA 测试负责人 PM 开始6、确定项目管理机制 14、协调人员及资源 项目日程表 15、建立工作环境 项目计划书 17、编制项目日程表 5、审批裁剪 16、编制项目计划书 4、申请裁剪 1、组建临时项目组 11、确定项目目 标范围 13、确定项目关键参数 结束 项目裁剪表 2、制定需求阶段日程表 12、项目估算 规模估算表/项目 估算表 3、建立配置库 18、评审项目计划书 19、建立阶段 基线 20、阶段总结 需求分析阶段总 结报告 需求分析阶基线 7、编写需求清单 列表 需求清单列表 10、确认需求规格书 8、确定系统架构/编写需求规格书 架构设计书/需求规格书 9、评审架构设计书/需求规格书 过程描述
1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。 2、PM制定需求阶段日程表，该表须通过研发经理审核。 3、PM指示配置管理员建立配置库。 4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。 5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。 6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。 7、项目组人员与客户进行沟通，编写需求清单列表。 8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。 ?对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠性等)、技术的发展前景、供应商资质与实力等)及相对优 先级，采用讨论表决的方法选择并确定最终的技术方案。 ?关于自行开发和采购复用的分析， 如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、测试用例等)，一般应进行复 用； 本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本在项目可接受范围内，可考虑 采购； 否则，由项目组自行开发。 架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。 9、PM召集临时项目组、测试负责人等技术骨干评审架构设计书和需求规格书。 10、PM组织临时项目组与客户沟通、说明需求，必要时编制系统原型向客户展示，直到临时项目组、客户就需求的真实含义达成共识、客户书面确认需求规格书为止。 11、临时项目组确定项目目标的范围，明确系统边界，建立系统的模块分解结构。 12、PM与测试负责人遵循《项目估算流程》组织人员进行项目估算。 13、PM、测试负责人与临时项目组确定项目关键参数。 ?工作量、工期、日程、人数 ?成本/预算（由于本公司的项目的绝大部分成本是人力成本，对估计成本的管理等同于估计工作量的管理，对实际成本的管理等同于实际工作量的管理，对预算的管理等同于计划工作量的管 理。）
cmmi软件开发流程
软件开发流程软件项目生命周期模型 需求分析 需求分析流程图
过程描述 1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。 2、PM制定需求阶段日程表，该表须通过研发经理审核。 3、PM指示配置管理员建立配置库。 4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成
项目裁剪表。 5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。 6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。 7、项目组人员与客户进行沟通，编写需求清单列表。 8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。 ?对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠性等)、技术的发展前景、供应商资质与实力等)及相对优先级，采用讨论表决的方法选择并确定最终的技术方案。 ?关于自行开发和采购复用的分析，如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、测试用例等)，一般应进行复用； 本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本在项目可接受范围内，可考虑采购； 否则，由项目组自行开发。 架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。 9、PM召集临时项目组、测试负责人等技术骨干评审架构设计书和需求规格书。 10、PM组织临时项目组与客户沟通、说明需求，必要时编制系统原型向客户展示，直到临时项目组、客户就需求的真实含义达成共识、客户书面确认需求规格书为止。 11、临时项目组确定项目目标的范围，明确系统边界，建立系统的模块分解结构。 12、PM与测试负责人遵循《项目估算流程》组织人员进行项目估算。 13、PM、测试负责人与临时项目组确定项目关键参数。 ?工作量、工期、日程、人数 ?成本/预算（由于本公司的项目的绝大部分成本是人力成本，对估计成本的管理等同于估计工作量的管理，对实际成本的管理等同于实际工作量的管理，对预 算的管理等同于计划工作量的管理。） ?质量目标 14、PM、测试负责人与部门经理协调人员及资源、计划知识技能、协调相关干系人的参与。 15、项目组基于公司环境标准，结合项目实际情况建立适合的工作环境。 16、PM、测试负责人编制项目计划书。 17、PM、测试负责人编制项目日程表。 18、临时项目组、研发部、QA评审项目计划书，评审通过后正式生效。 19、PM指示配置管理员建立配置基线。 20、PM编制阶段总结报告（项目总结报告中的度量分析页面），召开阶段会议。 设计 设计流程图
CMMI流程之总结
从CMM软件开发流程的理念、流程这两个方面概括介绍一下CMM。 CMM软件开发流程试图将几十年来风险比较不可控的软件开发用一个规范的流程控制起来，变成一个类似传统工业化生产流程的工业。 CMM理念 CMM主要理念之一就是加强过程控制，认为只要开发的过程按照规定动作执行，就可以很大程度上降低软件开发的质量、进度风险。而过程质量控制的主要手段就是检视。 CMM的理念之二是根据经验数据指导新的软件开发项目。CMM定义了监控软件开发过程 是否规范的一系列指标，如软件生产率、检视缺陷密度、遗留缺陷密度等，并总结了同业的一些经验数据。当执行实际项目时，以这些经验数据指引开发过程，尽量使开发的关键质量指标落入经验数据区间。同时进行进一步分析总结，对质量目标进行修正，用以指导后续的新项目。通过在一个个的项目逐渐总结修正，最终得到一套适合自己的质量目标。 CMM的理念之三，也可以说是本质，是基于传统的瀑布软件开发模型的。 CMM全流程 CMM软件开发规范的流程。CMM规范基于瀑布软件开发模型，没有体现基于原型逐步求 精的思想，这也是近年来在实施中为人所诟病的一个方面。下面结合IPD流程阐述一下CMM 流程在公司实际的应用。 CDP-Charter CDP即Charter开发项目，主要的责任主体是Marketing团队和SE，目标是定义一个产品版本所要解决的主要目标和时间点，交付件是Charter。Charter要通过BMT，即业务管理团队的批准。Charter需要回答这些问题：版本的Top N需求和主要竞争需求，主要目标客户，完整的包需求，版本的里程碑时间点，应用的时间窗口以及在版本火车中所处的位置。 Charter-TR1 TR1即产品概念完成里程碑，主要的责任主体是SE团队，同时Marketing配合完成需求的细化、澄清和修订。这个阶段的目标是输出设计需求。相比包需求，设计需求粒度更细，能够清晰的描述每一个需求，包括每个需求的输入、输出参数，并输出低保真界面原型。 CDCP CDCP即Concept Decision Check Point，近年来大部分项目都裁剪，具体作用不明。 TR1-TR2 TR2即产品设计完成里程碑，主要的责任主体是SE团队。这个阶段的输出是设计规格。相
CMMI3访谈问题列表 for
EPG访谈 1.想问一下你们有专门的过程改进组吗由哪些人员组成 2.关于组织过程改进方面，是否有相关的方针方针是谁写的组织过程定义和组织过程焦点方针分别什么 有相关的方针,这个方针是我们的高层蔡总制订初稿的,我进行了修改，然后提交给蔡总再次审核。审核通过后，这个方针就做为公司进行CMMI三级过程改进的指导思想。 在这个方针里，对于组织过程定义和组织过程焦点的要求是：过程改进工作是有计划，并被跟踪的，且过程改进工作是一个持续进行的。 成立专让的过程改进小组（EPG）负责此项工作，EPG组的主要职责建立并维护组织级标准软件过程，并在全公司推广这套体系。收集项目中应用比较好的过程，做为最佳实践，为组织建立并维护财富库，供以后项目参考。 3.你了解公司目前公司的商业目标吗你是如何将公司商业目标体现在你的过程改进计划或活动中呢 我们能够有效识别客户的业务需求，并提供高质量的客户解决方案，同时秉承服务于客户需求，与客户共同发展的商业理念。 我们在公司进行CMMI过程改进的目的也就是征对公司的这一商业目标，改善软件开发过程，为公司的软件开发提供丰富的模板，并要求项目组按照已定义的过程来执行软件开发过程，提高阶段产品的质量，将问题发现在平时，解决在平时，从而提高产品的质量，提高客户的满意度。 4.你了解公司在过程改进方面投入情况吗具体提供了哪些资源 了解，公司提供的强有力的人力资源，成立了过程改进组。提供了有关CMMI的培训，并准备了很多CMMI的资料供大家学习。（可以扩充）
5.过程改进计划是如何制定的（由谁来审批） 过程改进计划是由我来制定的，我是根据差距分析报告中公司现状与CMMI三级的差距而制定的CMMI过程改进计划，计划主要内容由WBS任务分解，过程改进的成员，组间协调计划，配置管理计划，质量保证计划等等，我组织了一次对《过程改进计划》的评审，这次评审邀请了老总和所有的EPG组成员。评审中我们将发现的问题记录在问题跟踪表中，会后由我来进行修改，然后提交给周总，进行再次审核。 6.过程改进计划是否发生过变更，你是如何来处理的 过程改进计划发生过变更，我们EPG小组对变更的内容修改的增加，并重新对《过程改进计划》进行评审，评审通过后，由配置管理人员提交基线库，发布《基线发布报告》通知所有人员。 7.过程改进计划一般包括哪些方面的内容 过程改进计划里包括培训计划，质量保证计划，配置管理计划，组间协调计划，试点推广计划，过程改进进度表，风险计划，项目的组织架构图等等。 8.你是否清楚项目如何来对组织的标准过程进行裁剪的你们公司有这方面的裁剪规定吗你们裁剪后的结果，是否需要经你们小组来评审 清楚， 项目经理根据项目具体情况，按照组织级裁剪规，邀请项目组，高层，PPQA召开裁剪会议，项目经理将裁剪结果记录《裁剪表》里，并提交给我进行审核。 智多星学习软件项目是中型产品的项目，根据《裁剪规程》的要求，项目计划，项目估计不可以裁剪，角色指定、项目规划、立项会议、规划确定可以合并简化。学生自动化测试平台项目是中型产品的项目，根据《裁剪规程》的要求，项目计划，项目估计不可以裁剪，角色指定、项目规划、立项会议、规划确定可以合并简化。 兆和客户关系管理系统是中型产品的项目，根据《裁剪规程》的要求，项目计划，项目估计不可以裁剪，角色指定、项目规划、立项会议、规划确定可以合并简化。 9.你是否清楚公司未来几年对于过程改进方面的一些目标是什么 是的，公司计划用3年的时间来执行CMMI L3,解决目前存在的软件开发过程中存在的软件开发过程难以控制，产品质量难以保证的问题。 在这三年里，EPG组要根据公司的发现，除了及时的解决过程改进中发生的问题，还要定期的组织体系执行的评审活动，发现弱项与强项，并对弱项进行改进。 10.你作为EPG的代表，你受过哪些方面的培训 我接受过CMMI 17个过程域的培训 11.其他角色或成员是否接受过你们EPG组织的培训 接受过，EPG组在OSSP体系发布后，立即组织了一个连续一个星期对公司所有员工进行了OSSP体系的培训，主要内容是讲解OSSP体系中的所有过程，规程，模板，检查表的使用方法。
CMMI体系文件-OPD-标准软件过程裁剪指南
****信息系统有限公司 标准软件过程裁剪指南 文件编号：版本号： 编制：日期： 审核：日期： 批准：日期：
****信息系统有限公司 标准软件过程裁剪指南 文件编号：版本号： 编制：日期： 审核：日期： 批准：日期：
文件修订记录
目录 1目的........................................... 错误!未定义书签。2适用范围....................................... 错误!未定义书签。3资源和工具..................................... 错误!未定义书签。4定义和缩写..................................... 错误!未定义书签。5职责........................................... 错误!未定义书签。6指南........................................... 错误!未定义书签。 启动条件.................................... 错误!未定义书签。 输入........................................ 错误!未定义书签。 活动........................................ 错误!未定义书签。 确定项目特点............................ 错误!未定义书签。 裁剪要求................................ 错误!未定义书签。 裁剪对象.............................. 错误!未定义书签。 裁剪原则.............................. 错误!未定义书签。 裁剪产物.............................. 错误!未定义书签。 软件生命周期的裁剪指导.................. 错误!未定义书签。 过程裁剪指导............................ 错误!未定义书签。 概要裁剪.............................. 错误!未定义书签。 详细裁剪.............................. 错误!未定义书签。 需求开发与需求管理................ 错误!未定义书签。 技术解决过程...................... 错误!未定义书签。 验证.............................. 错误!未定义书签。 测试........................... 错误!未定义书签。 评审........................... 错误!未定义书签。 项目计划.......................... 错误!未定义书签。 项目监控.......................... 错误!未定义书签。 配置管理.......................... 错误!未定义书签。