软件过程模型与CMMI过程域

合集下载

软件过程改进与cmmcmmi介绍.ppt

软件过程改进与cmmcmmi介绍.ppt

7.2 制定适合于企业的过程规范

首先要深入调查企业过程能力的现状,识别出薄弱环节,分清“轻重缓急”。再根据 企业的实力(如资金和人力),确定过程改进的各个阶段目标。 企业在参考业界推荐的过程标准或规范时,要舍弃那些听起来很先进但是对本企业无 益处的东西,只选取对企业有实用价值的东西。如同老百姓买商品,“只买对的,不 买贵的”。 CMM/CMMI和ISO都只是用来参考的,而不是用来“迷信”的。
方法与规程
人员
过程
产品
技术与工具
Page 5
2.
工程类的主要过程域:需求开发、系统设计、软件实现、软件测试、软件维护等等; 管理类的主要过程域:项目规划、项目监控、需求管理、质量管理、配置管理等等。

上述过程域中的任何活动都会影响产品的质量、生产率和成本。

2.2 什么是软件过程改进

从20世纪90年代至今,软件过程改进成为软件工程学科的一个主流研究方向,其中 CMM和CMMI是该领域举世瞩目的重大成果。 提高软件过程能力的实践通称为软件过程改进(Software Process Improvement)。 软件过程改进的根本目的是:提高质量、提高生产率并且降低开发成本。
Page 6
3. CMM发展简史
3.1 CMM是什么
CMM(Capability Maturity Model)是用于衡量软件过程能力的事实上的标准,同时也 是目前软件过程改进最好的参考标准。 美国卡内基-梅隆大学软件工程研究所(SEI)研制

3.2 发展简史

CMM 1.0于1991年制定。 CMM 1.1于1993发布,该版本应用最广泛。 CMM 2.0草案于1997年制定(未广泛应用)。 到2000年,CMM演化成为CMMI(Capability Maturity Model Integration),CMM 2.0成为CMMI 1.0的主要组成部分。 CMMI-SE/SW 1.1(CMMI for System Engineering and Software Engineering)于 2002年1月正式推出。

CMM与CMMI

CMM与CMMI

2.2.2 系统工程能力模型
国际系统工程委员会(International Council on
Systems Engineering,INCOSE)基于各种工程标准
为评估系统工程能力建立了对照表。在此期间,该对照 表发展为成熟的能力模型,称为系统工程能力评估模型 (Systems Engineering Capability Assessment Model ,SECAM)。
IEEE 1074
IEEE/EIA 12207
ISO 15288*
EIA 632*
Copyright Software Productivity Consortium
18
quag14d: 5 June 1998 2013年6月18日星期二
/quagmire
虽然这些模型对许多组织是有用的,有助于改善 组织过程,以构造更好的产品,提高质量,降 低成本,但是在跨越不同组织、学科、单位或 文化的环境下,组织内存在的不同过程组可能 会选用不同的、有时甚至是相互冲突的过程改 进模型,这就失去了过程改进的意义。因此, 美国国防部提出了能力成熟度模型集成( CMMI)的设想,即把现有模型和即将开发的 模型全部集成到一个框架中去
17 2013年6月18日星期二
各类“框架”的沼泽
PSP People CMM SA-CMM SW-CMM SCE ISO 15504* (SPICE) IEEE Stds. 730,828 829, 830,1012,1016 1028,1058,1063 NATO AQAP1,4,9 EQA Trillium DOD IPPD AF IPD Guide Baldrige DO178B BS 5750 ISO/IEC 12207 SDCCR SDCE MIL-Q -9858 MIL-STD-1679 DODSTDDOD-STD 2168 -2167A DOD-STD -7935A

软件过程改进CMMI

软件过程改进CMMI

软件过程改进CMMI1、简介CMMI(Capability Maturity Model Integration)能力成熟度模型集成是产品与服务研发的过程成熟度模型,是美国国防部委托SEI研究产生的一套IT研发管理模型。

CMMI是从产品需求开始,至开发、测试、维护的研发管理水平,同时提升企业自身的研发过程管理能力。

2、适用范围CMMI适用于希望实施过程改进特纳别是实施美国卡内基梅隆大学软件工程研究所(SEI)推出的CMMI(能力成熟度模型)的软件企业或系统集成企业。

通常可包括以下类别的企业:软件开发企业软件外包企业系统集成企业硬件企业IT服务企业3、实施CMMI有什么好处?有来自70多个国家的500家以上企业在使用CMMI模型,包括美国、中国、德国、意大利、智利、印度、澳大利亚、埃及、土耳其和俄国。

实施CMMI,有利于满足以下目的:提供高质量的产品和服务:CMMI重点关注于质量相关的活动,包含需求管理、质量保证、验证和确认。

为股东创造价值:成熟的组织与不够成熟的组织相比,更有可能做出更好的成本和收入的预算,然后根据这些预算来执行。

CMMI 支持高质量的产品、可预测的进度和有效的度量,以此来支持管理人员进行精确而合理的预算。

这种过程成熟度可预防项目性能的产生,而这些问题是有可能降低在投资者心目中该组织的价值。

吸引和留驻人才:CMMI在学科和过程方面都强调培训。

以往的经验显示,和不成熟的组织相比,具有成熟过程的组织将产生更少的失误,在一个团结的和有能力的组织中工作,工程师们会感到特别的心情舒畅。

提高顾客满意度:在成本和进度的预定目标之内,提供根据顾客要求确认的高质量产品,只是顾客满意度的一个良好的公式。

通过强调计划、监控、度量、以及更有能力的过程带来的可预测性的提高,CMMI说明了所有的有关的要素。

增加市场份额:CMMI改进了预算估计并降低了过程波动性,以此来进行更好的,更精确的投标,这些头表示被证明可实现的。

CMMI模型介绍

CMMI模型介绍
项目质量保证计划
项目配置管理计划
项目计划
取得对计划的承诺
评审影响项目 的各种计划
调整工作 和资源水平
取得计划承诺
相关干系人
建立并维护对项目计划的承诺
▪ SP 3.1 评审影响项目的各种计划
▪ 评审影响项目的所有计划,以了解项目承诺
▪ SP 3.2 调整工作和资源水平
▪ 调整项目计划,以反映可用的资源与估计的资源
▪ SP 2.5 计划所需的知识和技能
▪ 计划执行项目所需的知识和技能
▪ SP 2.6 计划干系人的参与
▪ 计划已识别的干系人的参与
▪ SP 2.7 建立项目计划
▪ 建立并维护全面的项目计划内容
项目计划
• 项目进度计划 • 项目风险计划 • 项目预算与成本计划 • 项目数据计划 • 项目沟通计划 • 项目资源计划 • 项目培训计划
过程改进的基本假设:
“过程质量决定产品质量”
过程
任务间的关系
A
B
D
C

人员的技能、培 训和动力
质量
工具和环境
五之一 CMMI概述 3-1过程与过程模型的理解-过程的定义
A model is a structured collection of elements that describe characteristics of effective processes. 模型所包含的过程是被实践证明为有效的过程,是最佳实践的总结。
厦门开发中心 黄斌
序言
“The quality of a product is largely determined by the quality of the process that is used to develop and maintain it.”

CMMIL3 各过程域解释(大信有诚咨询教育机构)

CMMIL3 各过程域解释(大信有诚咨询教育机构)

对CMMI3的学习和思考【IT168 专稿】近来笔者所在公司正在为过CMMI3做各种准备,对公司的员工进行了一些相关的培训,作为项目管理人员的我,在学习CMMI3的过程中,也有了自己的一点对于CMMI3的思考。

CMMI将软件过程中的很多步骤都通过步骤规范起来,它并没有告诉我们应该怎么去做,而只是告诉我们应该做些什么。

因为软件过程中的每一步都需要经过思考、决策、有依据才能得出过程的结果,所以减少了每一步发生错误的可能性。

一.CMMI概述CMMI是Capacity Maturity Model Integrated的简称,即集成的软件能力成熟度模型,CMM是CMMI的早期版本,它主要用于软件工程,而CMMI是一种综合性模型,它是工程实施和管理方法,它在软件与系统集成以外的如科研、工程等领域都得到了广泛的应用。

CMMI是一个由理论和经验部分组成的模型。

它有连续式和阶段式两种表述方式,其中连续式主要用于衡量一个企业的项目能力,而阶段式主要用来衡量一个企业的成熟度。

在连续式表述下,企业在接受评估时可以选择自己希望评估的项目来进行评估,所以评估通过率相对比较大,但它反映的那个相对比较窄,因为它仅仅反映该企业的该项目或类似项目达到了对应的等级。

而用阶段式来进行评估时,需由评估师自己来挑选内部的任何项目或其中的某一部分来进行评估。

阶段式的CMMI有5个等级,如下:第一级(初始级):在该等级下,项目的目标虽然得以实现,但它的实现带有很多的偶然性和风险性,该级对人员的依赖性比较大,性能依赖个人的能力,且随个人固有的性能、知识和动机的不同而变化。

第二级(受管理级):在该等级下,意味着组织要确保策划、文档化、执行、监督和控制项目级的过程,并且需要为过程建立明确的目标,并能实现成本、进度和质量目标等。

在这种情况下,组织已经营造了一个稳定的、受控的开发环境,项目已经在受控制的状态下运行。

该级包括如下7个过程域:需求管理(RM)、项目策划(PP)、项目监督与控制(PMC)、供方协定管理(SAM)、测量与分析(MA)、过程和产品质量保证(PPQA)和配置管理(CM)。

cmmi的过程域 ppt课件

cmmi的过程域 ppt课件
名称提供了对该内容进行查询的便利 方法。
例如:需求管理过程域的一个特定目 标的名称是“SG 1 管理需求”。
5.特定目标与实践摘要
提供实践到目标之间的映射 例如:需求管理过程域的特定目标及实践
摘要如下:
SG 1 管理需求 SP 1.1 了解需求 SP 1.2 取得需求承诺 SP 1.3 管理需求变更 SP 1.4 维护需求的双向追溯性 SP 1.5 界定项目工作与需求间的差异
能力等级2-已管理级的特征
已管理级过程是一个具有以下特征的 已执行级过程。
按照预定方针予以策划和执行的; 为了生成受控的输出,过程的执行都是
配备有适当的资源、有熟练技能的人; 各方利益相关者介入了该过程; 并且依据各项要求进行了审查和评价。
能力等级3-已定义级的特征
已定义级过程是这样一种受管理的过 程:
summary) 6. 注释(Notes) 7. 典型工作产品(Typical Work Products) 8. 子实践(Subpractices) 9. 学科扩充(Discipline Amplifications) 10. 共性实践详细说明(Generic Practice Elaborations)
从无序到有序、从特殊到一般、从定性管 理到定量管理、最终达到动态优化
阶段式模型
“吃饭”的例子!
CMMI”精神”
CMMI不是软件开发的方法学、也不 是产品模板、更不是一套过程法律
CMMI只是做事的一般方法
阶段式模型与过程域
连续式模型--4个能力等级
0 不完整级; 1 已执行级; 2 已管理级; 3 已定义级;
它是根据本组织的剪裁指南从本组织的 标准过程集合剪裁而得来;
它具有受到维护的过程描述;

16 软件过程模型CMMI

16 软件过程模型CMMI

• CMMI 模型对工程活动进行了一定的强化。
– 在CMM中,只有3级中的软件产品工程和同行评审两个关键过程 域是与工程过程密切相关的, – 在CMMI中,则将需求开发,验证,确认,技术解决方案,产品集 成这些工程过程活动都作为单独的关键过程域进行了要求,从而 在实践上提出了对工程的更高要求和更具体的指导。
2.4 CMMI的 模型表述
• 一个组织可以从以下两种过程改进的方法 中选择其一:
– 组织成熟度 – 过程域能力
• CMMI 对不同过程改进方法采用不同表示 法
– 组织成熟度 – 分级(阶梯式)表示法 – 过程域能力 – 连续表示法
2.4分级表示法
规定了一系列已经证明的改进措施,每一级 都是其上一级的基础,服务于上一级.
量化管理
3 已定义
过程标准化
项目管理 2 已管理
风险 返工
1 初始级
4.3 CMMI 的新特性
• CMMI 模型中比CMM 进一步强化了对需求的重视。
– 在CMM 中,关于需求只有需求管理这一个关键过程域,也就是说, 强调对有质量的需求进行管理,而如何获取需求则没有提出明确 的要求。 – 在CMMI的阶段模要求和方法。
• CMMI中还强调了风险管理。
– 在CMM 中把风险的管理分散在项目计划和项目跟踪与监控中进行 要求, – CMMI3级里单独提出了一个独立的关键过程域叫做风险管理。
4.4 CMMI 的新特性
• 保留了CMM阶段式模式的基础 • 增加了连续式模型,
– 可以帮助组织其客户更加客观和全面的了解它的过程 成熟度。 – 可以给组织在进行过程改进的时候带来更大的自主性, – 不用再象CMM 中 一样,受到等级的严格限制。 – 这种改进的好处是灵活性和客观性强,弱点在于若缺 乏指导,一个组织可能缺乏对关键过程域之间依赖关 系的正确理解而片面的实施过程,造成一些过程成为 空中楼阁,缺少其他过程的支撑。 – 两种表现方式(连续的和阶段的)从他们所涵盖的过 程区域上来说并没有不同,不同的是过程区域的组织 方式以及对成熟度(能力)级别的判断方式。

CMMI和CMM区别

CMMI和CMM区别

CMMI和CMM区别CMMI的全称为:Capability Maturity Model Integration,即能力成熟度模型集成。

自从1994年SEI正式发布软件CMM以来,相继又开发出了系统工程、软件采购、人力资源管理以及集成产品和过程开发方面的多个能力成熟度模型。

虽然这些模型在许多组织都得到了良好的应用,但对于一些大型软件企业来说,可能会出现需要同时采用多种模型来改进自己多方面过程能力的情况。

这时他们就会发现存在一些问题,其中主要问题体现在:■不能集中其不同过程改进的能力以取得更大成绩;■要进行一些重复的培训、评估和改进活动,因而增加了许多成本;■不同模型对相同事物说法不一致,或活动不协调,甚至相抵触。

于是,希望整合不同CMM模型的需求产生了。

1997年,美国联邦航空管理局(FAA)开发了FAA-iCMMSM(联邦航空管理局的集成CMM),该模型集成了适用于系统工程的SE-CMM、软件获取的SA-CMM和软件的SW-CMM三个模型中的所有原则、概念和实践。

该模型被认为是第一个集成化的模型。

CMMI与CMM最大的不同点在于:■CMMISM-SE/SW/IPPD/SS 1.1版本有四个集成成分,即:系统工程(SE)和软件工程(SW)是基本的科目,对于有些组织还可以应用集成产品和过程开发方面(IPPD)的内容,如果涉及到供应商外包管理可以相应地应用SS(Supplier Sourcing)部分。

■CMMI有两种表示方法,一种是大家很熟悉的,和软件CMM一样的阶段式表现方法,另一种是连续式的表现方法。

这两种表现方法的区别是:阶段式表现方法仍然把CMMI 中的若干个过程区域分成了5个成熟度级别,帮助实施CMMI的组织建议一条比较容易实现的过程改进发展道路。

而连续式表现方法则通过将CMMI中过程区域分为四大类:过程管理、项目管理、工程以及支持。

对于每个大类中的过程区域,又进一步分为基本的和高级的。

CMMI3级18个过程域

CMMI3级18个过程域

CMMI3级18个过程域CMMI(Capability Maturity Model Integration)是一种用于评价和改进组织的软件工程能力的模型。

CMMI模型将软件工程能力分为不同的级别,目前最高级别是CMMI级别5、在CMMI模型中,共有18个过程域,每个过程域都包含一组过程目标和过程实践。

下面将介绍CMMI级别3中的18个过程域,并对每个过程域进行详细解析。

1. 要求开发(Requirements Development):该过程域涉及确定、分析和记录系统和软件需求的活动。

它包括需求的获取、管理、分析和验证。

2. 要求管理(Requirements Management):该过程域涉及组织和控制项目的需求。

它包括需求的识别、跟踪、控制和变更管理。

3. 项目计划和监控(Project Planning and Monitoring):该过程域涉及制定和维护项目计划,并监控项目活动的执行。

它包括识别和规划项目活动、建立项目计划、监控项目进展和基于此进行调整。

4. 项目监控和控制(Project Monitoring and Control):该过程域涉及监控和控制项目执行过程中的工作和活动。

它包括收集和分析项目绩效数据、对比实际和计划绩效,对项目进展进行控制。

5. 供应商协议管理(Supplier Agreement Management):该过程域涉及与供应商达成协议,并管理和监控供应商的活动。

它包括选择供应商、与供应商协商、管理和控制供应商的交付和绩效。

6. 产品集成(Product Integration):该过程域涉及对各个组成部分进行整合,形成最终产品。

它包括定义和实施产品集成策略、执行产品集成和验证集成后的产品。

7. 风险管理(Risk Management):该过程域涉及识别、评估和控制项目和产品的风险。

它包括制定风险管理计划、识别和评估风险、并采取相应的风险缓解措施。

8. 决策分析和解决方案评估(Decision Analysis and Resolution):该过程域涉及通过分析和评估不同的解决方案,制定决策。

CMM(CMMI)基础知识介绍

CMM(CMMI)基础知识介绍

第5级
◆ 特征 (1) 整个组织特别关注软件过程改进的持续性、预见及增强自身,防止缺陷及问题的发生,不 断地提高他们的过程处理能力。 (2) 加强定量分析,通过来自过程的质量反馈和吸收新观念,新科技,使软件过程不断地得到 改进。 (3) 根据软件过程的效果,进行成本 / 利润分析,从成功的软件过程中吸取经验,加以总结。 把最好的创新成绩迅速向全组织转移,对失败的案例,由软件过程小组进行分析以找出原因。 (4) 组织能找出过程的不足并预先改进,把失败的教训告知全组织以防止重复以前的错误。 (5) 对软件过程的评价和对标准软件过程的改进,都在全组织推广。 过程 不断地系统地改进软件过程。 理解并消除产生问题的公共根源,在任何一个系统中都可找到:由于随机变化造成重复工作、 进而导致时间浪费。为了防止浪费人力可能导致的系统变化,要消除“公共”的无效率根源”, 防止浪费发生。尽管所有级别都存在这些问题,但这是第5级的焦点。 ◆ 人员 整个组织都存在自觉的强烈的团队意识。 (2) 每个人都致力于过程改进,人们不再以达到里程碑式的成就而满足,而力求减少错误率。 ◆ 技术
CMM2级的关键过程域是8个,目标20个, 承诺9个,能力25个,活动62个,度量6个, 验证19个。
CMM等级及特点
12
CMM过程的可视性
5 输入
输出
4 输入
3 输入
2 输入 1 输入
13
输出 输出 输出 输出
1.6 CMM1.1的等级及其特征
第1级 ◆ 特征
(1) 软件过程的特点是杂乱无章,有时甚至是混乱,几乎没有定义过程 的规则或步骤。 (2) 过分的承诺。常作出良好的承诺:如“按照软件工程方式,有序的 工程步骤来做”;或达到高目标的许诺。实际上却出现一系列问题。 (3) 遇到危机就放弃院计划过程,反复编码和测试。 (4) 成功完全依赖个人努力和杰出的专业人才,取决于超常的管理人员 和杰出有效的软件开发人员。具体的表现和成果都源自于或者说决定于个 人的能力和他们先前的经验、知识以及他们的进取心和积极程度。 (5) 能力只是个人的特性,而不是开发组织的特性。依靠着个人的品质 或承受着巨大压力;或找窍门取得成果。但此类人一旦离去,组织的稳定 作用也随之消失。 (6) 软件过程是不可确定的和不可预见的。软件能力成熟度处于一级的 软件组织其软件过程在实际工作过程中经常被改变(过程是随意的)。这 类组织也在开发产品,但其成果是步稳定的,不可预见的不可重复的。也 就是说,软件的计划、预算、功能和产品的质量都是不可确定的和不可预 见的。

CMMI过程改善模型与软件开发共5页文档

CMMI过程改善模型与软件开发共5页文档

CMMI过程改善模型与软件开发软件外包是一些发达国家的企业为了降低成本,提高自身核心领域的专注度而将部分非核心的软件项目通过外包的方式交付给人力资源成本相对较低的发展中国家,从而有效的降低企业的运营成本又能很好的满足自身的软件需求活动。

我国从上世纪九十年代初期开始介入这个行业领域以来,通过近二十多年的发展,已经有了长足的发展。

其中软件外包产业发展比较成熟的地区有上海、深圳、大连等地。

由于软件外包行业的性质所决定,所接受到的项目往往都是外国企业软件系统非核心的内容,由于技术含量较低从而导致没有任何技术竞争力和任何知识产权。

但随着日元的不断贬值和国际形势的发展,让因历史文化等原因对日软件出口占主导地位慢慢发生改变。

据统计,从2012年以来,对欧美外包市场的增速达到年增长49%,超过对日外包的37%的增速。

欧美的软件外包市场已经悄然成为我国企业开拓的新方向。

我们知道企业能够提供相应产品的质量保证是软件企业开拓离岸外包市场的敲门砖。

比日本企业更注重软件项目管理能力的欧美企业,如何提高客户的信赖度和满意度,让能够从接手简单的软件开发及测试工作向参与设计承接及需求分析阶段介入,甚至能与承包商一起面对终端客户以获取项目,这些都是摆在我国外包企业面前的问题。

因此,诸如CMMI、ISO等欧美企业认可的国际专项认证,成为了企业研发能力和管理能力的标志。

什么是CMMI?CMMI,即软件能力成熟度模型集成,由美国宾州匹兹堡卡耐基梅隆大学软件工程研究院于1986年开始开发,是卡耐基梅隆大学的服务标记。

其主要的目的是帮助软件企业对软件开发工程过程进行有效的管理改进,增强自身的管理能力,从而能够更有效的开发出高品质的软件,以满足客户的需求。

一个系统或者产品的质量在很大程度上取决于开发与维护它的过程的质量,一个有效的过程将人员,工具和方法结合成一个有机的整体。

人、技术、方法,即是过程。

人员根据一种有效的方法使用相关技术便能够生产出高质量的产品。

第七章 软件能力成熟度模型

第七章 软件能力成熟度模型
CMMI过程改进需要多长时间?有何效果? ? 一般需要 2年才能把成熟度提升一级(建议安
排1.5年到2年)。 ? 根据CMU-SEI的统计,软件企业在引入 CMM
后劳动生产率平均增长了 35%;错误比率平均 减少39%;平均成本回报率为 5:1。
本章内容提要
? 软件过程与过程管理 ? CMMI概述 ? CMMI的成熟度等级及其过程域 ? CMMI的应用 ? PSP,TSP与CMMI
等级5:优化 组织革新与部署
管理级
原因分析与解决
缩写词 ISM OEI IT OPP QPM
OID CAR
5.CMMI的能力等级
? 能力等级 (Capability Level, CL )是指在一 个单独的过程域中执行的良好程度。
? CMMI包括6个能力等级: ?CL0 ,不完整级:过程域的一个或多个目标 没有被满足。 ?CL1 ,已执行级:过程通过转换可识别的输 入工作产品,产生可识别的输出工作产品。 能实现过程域的特定目标。
成熟度等级
关键过程域
等级2:已 需求管理
管理级
项目计划
项目监督与控制
供应商协议管理
度量和分析
过程和产品质量保证
配置管理
等级3:已 需求开发
定义级
技术解决方案
缩写词 REQM PP PMC SAM MA PPQA CM RD TS
4.CMMI的关键过程域(续)
成熟度等级
关键过程域
等级3:已 产品集成
1.CMMI的历史(续)
?IPD-CMM (Integrated systems product Development CMM): 集成系统产品开发 CMM,应用于集成系统产品的开发管理。

CMMI 简介+过程域介绍

CMMI 简介+过程域介绍
• 自1991 年SW-CMM首次发布后,SEI 又开发了其他成熟度 模型,包括:系统工程、采购、人力资源管理和集成产品 开发等。虽然各个模型针对的专业领域不同,但彼此之间 也有一定的重叠,后SEI将各个模型整合,建立统一模型, 就产生了CMMI模型。
第三页,共35页。
1.3 CMMI 起源
• CMMI 是一套融合多学科的、可扩充的产品集合,该模型 包含了从软件需求提出、软件设计、开发、编码、测试、 交付运行到软件退役的软件整个生存周期里各个软件过程 的各项基本要素;是软件过程的有机汇集,旨在为软件组 织改进其过程和提高其对软件产品或服务的开发、采购以 及维护的能力中提供指导。
SW-CMM, IPD-CMM等 1997:开发一个CMM模型的集成框架 2002:CMMI V1.1( 包含了CMMI-SE/SW/IPPD/SS 模型)正式发
布 2006:CMMI V1.2正式发布 2010:CMMI V1.3正式发布(包含开发、采购、服务模型)
第五页,共35页。
1.5 CMMI 评估方法
• SCAMPI ARC B类评估
• CMMI B类评估过程,则只需要满足部分的ARC要求,并可以只需要收集更少的信息 ,一般必须由访谈方式获得信息,这里不需要最终产生组织的成熟度级别,评估组 的负责人可以是授权评估师或由组织内部相应的有经验的成员担当,这可以认为是 组织内部的评估过程,可以在过程改进过程中的诊断过程中使用,也可以在组织发 展过程中进行阶段性评估审计时使用。
• 过去的成功能够重用在新的类似项目中
• 纪律保证现有惯例在多种压力情况下得以维持 • 工作任务和工作产品对于管理着在定义的点上是可见的
第十八页,共35页。
过程是 “已管理的”
In

CMMI的5个级别和25个过程域

CMMI的5个级别和25个过程域

CMMI的5个级别和25个过程域CMMI (Capability Maturity Model Integration)是一个结构化的过程改进方法,用于评估和提升组织的软件工程能力。

CMMI分为五个不同的成熟度级别,每个级别都有一组相关的过程域。

本文将详细介绍CMMI的五个级别和25个过程域。

1. 初始级别 (Level 1 - Initial)初始级别指的是一个组织在软件开发方面缺乏组织化和预测性的过程。

在这个级别上,软件开发过程通常是不可控制的,且无法重复使用。

这意味着项目结果无法预测和控制,导致成本和进度的不确定性。

2. 执行级别 (Level 2 - Managed)执行级别指的是一个组织开始建立和管理自己的软件开发过程。

在这个级别上,组织已经建立了一些基本的软件开发过程,并能够在不同的项目中重复使用这些过程。

然而,这些过程还没有得到完全的规范和标准化。

2.1 需求管理 (Requirements Management)需求管理是确保正确、一致和可追踪需求的过程。

它涉及定义、确认和维护需求,以确保项目能够满足用户的期望。

2.2 项目计划与监控 (Project Planning and Monitoring)项目计划与监控是制定和监控项目时间表、成本和资源的过程。

它确保项目能够按计划进行,并能够做出合适的调整以达到预期的目标。

2.3 供应商协商 (Supplier Agreement Management)供应商协商是与供应商建立和维护合作关系的过程。

它确保与供应商的交付和管理能够满足项目的需求。

2.4 产品质量保证 (Product Quality Assurance)产品质量保证是确保项目交付的产品符合质量标准和用户期望的过程。

它涉及质量计划、质量审查和质量度量等活动。

2.5 配置管理 (Configuration Management)配置管理是管理项目的配置项(包括软件、硬件和文档等)的过程。

软件过程度量和CMMI模型概述

软件过程度量和CMMI模型概述

软件过程度量和CMMI模型概述CMMI模型概述1.1.1 度量的概念软件度量是针对计算机软件的度量,是对软件系统、组件或过程中具有的某个给定属性进⾏的⼀个定量测量[15]。

在软件度量领域内经常出现Measure,Metric,Measurement,Indicator等与度量有关的相关概念,它们既相互联系⼜相互区别,以下是对它们的解释[16]:1.Measure,度量,分为名词和动词两种情况。

作为名词,度量指的是在⼀定的规则下,软件过程或产品属性的数值或类别;作为动词,度量指的是按照度量过程中的过程定义,对软件过程或软件产品实施度量的实际动作。

2.Measurement,测量,是指按照⼀定的规则⽤度量(名词)给软件实体属性赋值的过程。

测量强调量化软件实体属性的过程性,⽬的是提取软件过程或软件产品属性的度量(名词)。

3.Metric,度量,是⼰定义的测量⽅法和测量尺度,在很多场合与指⽰器(Indicator)交叉出现,泛指软件对象的属性的量化表现,其内涵⼤于Indicator。

4.Indicator,指⽰器,是指⽤于评价或预测其他度量(名词)的度量(名词)。

它是⼀个或多个度量的综合,能够对软件产品或过程的某⼀⽅⾯特征作出某种程度的反映。

软件度量过程是进⾏确认、定义、收集和分析度量的软件过程,也是对软件属性定量化分析的过程,以此我们可以更好地了解和评估项⽬、产品和过程,并可以对项⽬进⾏进⼀步的预测和改进。

度量过程可根据度量对象的不同分为项⽬度量、产品度量和过程度量三类,其分类如图1.1所⽰。

1.1 度量过程分类软件过程度量是本⽂讨论的重点,它是对软件开发过程本⾝的度量,其度量结果可以为持续改进软件开发过程进⾏提供依据。

在IEEE标准1061-1998[17]中对其定义如下:过程度量:⼀种⽤来测量在软件系统开发、实现、测试和维护过程中使⽤的⽅法、技术和过程本⾝的属性的度量。

过程度量⼀般不直接进⾏,它通过⼤量的项⽬度量数据分析和总结得出。

CMMI过程域全ppt课件

CMMI过程域全ppt课件
SP2.1 收集和分析问题,并确定解决问题的必要的纠正行动 ● 采集问题,以供分析 ● 分析问题,以确定是否需要采取纠正措施
项目监督和控制—特殊实践分析
SP2.2 对照项目计划中标识出的承诺进行监督。 – 确定需要采取的相应措施 – 与相关的共利益者共同审查并达成协议 – 协商改变内部和外部承诺 SP2.3 管理纠正行动,直到问题得到解决。 – 监督纠正措施的完成情况 – 分析纠正措施的结果及效果 – 确定不适当的纠正措施,并形成文件
量和费用进行估计。
项目策划——PP
特定目标(SG2): 建立和维护项目计划并作为管理项目的 基础。
特定实践: SP2.1 建立和维护项目的预算和进度。 SP2.2 识别和分析项目风险。 SP2.3 计划项目数据的管理。 SP2.4 计划执行项目的必需的资源。 SP2.5 计划执行项目的所需的技能和知识。 SP2.6 计划利益关系人的投入。 SP2.7 建立和维护总体项目计划内容。
3)CMMI-SE/SW/IPPD/SS
25个过程域
组织在开发过程中需要获取或转包某些关键构件:考虑使用CMMISE/SW/IPPD/SS模型。
CMMI阶段式成熟度等级
关注于过程改进 过程已度量和控制 过程主动为组织服务 过程为项目服务,通常为被动的 过程不可预测且缺乏控制,是被动的
等级5:优化的 等级4:定量管理的 等级3:已定义的 等级2:已管理的 等级1:初始的
确定获 取 方式
选择供 应商
建立供 应商 合同
供应商需求
供应商合同
产品
满足供应商合同
获取
COTS 产品
执行供 应商 合同
验收获 得的 产品
转交产
PI

供应商合同管理—特殊实践分析

《CMMI体系介绍》课件

《CMMI体系介绍》课件
详细描述
CMMI是一种评估和改进软件过程的方法论,它提供了一种框架,帮助组织识 别、管理和改进软件开发的实践过程,从而提高软件质量、降低风险、优化成 本。
CMMI的发展历程
• 总结词:CMMI的发展历程包括初始阶段、已管理阶段、已定义阶段、 量化管理阶段、优化管理阶段。
• 详细描述:CMMI的初始阶段是组织开始意识到软件过程改进的需要,并采取一些基本的实践措施来满足基本的质量要 求。已管理阶段是组织开始建立一套完整的软件过程管理体系,并开始对软件开发过程进行全面的管理和监控。已定义 阶段是组织进一步标准化和优化软件开发过程,形成一套完整的标准过程体系。量化管理阶段是组织通过数据分析和度 量,对软件开发过程进行精细化的管理和优化。优化管理阶段是组织通过持续的过程改进和创新,实现软件开发的卓越 和领先。
3
总结经验教训
根据评审结果,总结经验教训,为后续的改进工 作提供参考和借鉴。
THANKS
感谢观看
REPORTING
CMMI的评级
总结词
CMMI的评级分为五个等级,从低到高分别为:初始级、已管理级、已定义级、 量化管理级和优化管理级。
详细描述
每个等级都代表了组织在软件过程改进方面所达到的不同成熟度水平。评级越高 ,表示组织的软件过程管理能力越强,能够更好地保证软件质量、降低风险和优 化成本。
PART 02
CMMI的五大过程域
项目管理
定义:项目管理是指对项目从开始到结束的整个生命周期 进行规划、组织、指导和控制的过程,以确保项目能够按 照预定的时间、成本和质量完成。
项目管理涉及对项目目标、范围、进度、成本、质量等方 面的规划和控制。项目管理需要制定项目计划,分配资源 ,建立项目组织结构,指导项目团队成员完成工作任务, 确保项目能够按照预定的时间、成本和质量完成。

2024年软件资格考试软件过程能力评估师(中级)(基础知识、应用技术)合卷试题与参考答案

2024年软件资格考试软件过程能力评估师(中级)(基础知识、应用技术)合卷试题与参考答案

2024年软件资格考试软件过程能力评估师(基础知识、应用技术)合卷(中级)自测试题(答案在后面)一、基础知识(客观选择题,75题,每题1分,共75分)1、在CMMI(Capability Maturity Model Integration)模型中,哪一个级别标志着组织已经定义了标准的过程,并且这些过程被文档化和标准化?A. 初始级B. 可管理级C. 已定义级D. 量化管理级2、下列哪一项不是敏捷开发方法论的核心价值?A. 个体和互动高于流程和工具B. 工作的软件高于详尽的文档C. 客户合作高于合同谈判D. 计划高于响应变化3、在软件过程能力成熟度模型(CMM)中,哪一级别被定义为“已管理级”(Managed Level)?A、CMM1:初始级(Initial Level)B、CMM2:可重复级(Repeatable Level)C、CMM3:已管理级(Managed Level)D、CMM4:已定义级(Defined Level)4、在软件开发生命周期(SDLC)中,以下哪一项不是系统开发生命周期(SDLC)的典型阶段?A、需求分析(Requirement Analysis)B、系统设计(System Design)C、编码(Coding)D、部署和维护(Deployment and Maintenance)5、以下哪种模型不是软件开发过程模型?A. 瀑布模型B. 喷泉模型C. 增量模型D. 面向对象模型6、在软件生命周期中,哪一个阶段确定了软件系统必须做什么,而不是如何做?A. 需求分析B. 设计C. 编码D. 测试7、在软件开发生命周期中,以下哪个阶段通常不涉及软件产品的实际编码工作?A. 需求分析B. 系统设计C. 编码实现D. 测试与验收8、软件过程能力成熟度模型CMMI中,哪一级别代表了组织在软件过程管理方面有明确的政策和目标?A. CMMI Level 1:初始级B. CMMI Level 2:已管理级C. CMMI Level 3:已定义级D. CMMI Level 4:定量管理级9、关于软件生命周期模型,下列说法正确的是:A. 瀑布模型是一种迭代开发模型。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
试运行和客户验收
VAL
试用:项目经理、售后服务人员或项目组、用户
验收:项目经理、公司方验收人员或测试工程师、用户、第三方
机构支撑过程
CMMI3过程域
决策分析及决议
DAR
项目经理、决策组成员、高级管理层
度量和分析
MA
度量负责人、项目组
配置管理
CM
配置管理:配置管理员、QA
配置变更:变更申请人、CCB、项目组成员、验证人
图:特通技术中心项目组软件过程模型和CMMI3关系图
项目管理过程
CMMI3过程域
目的
立项管理
采纳符合机构最大利益的立项建议,通过立项管理使该建议成为正式的项目。杜绝不符合机构最大利益的立项建议被采纳,避免浪费机构的资源、资金、时间等。
项目计划
PP、VER
为项目的研发和管理工作制定合理的行动纲领(即项目计划),以便所有相关人员按照该计划有条不紊地开展工作。
风险管理
RSKM
在风险产生危害之前识别它们,从而有计划地消除或削弱风险。
需求管理
REQM
在客户与开发方之间建立对需求的共同理解,维护需求与其它工作成果的一致性,并控制需求的变更。
结项管理
PMC、MA
在项目开发工作结束后,对项目的有形资产和无形资产进行清算、对项目进行综合指标评估以及总结经验教训等。
项目研发过程
《需求开发计划》、《需求分析表》、《需求调研记录表》、《用户需求说明书》、《软件需求规格说明书》、《需求确认表》、《差异记录》
、QA依据需求检查表检查需求、QA的需求检查结果、(《不符合项跟踪表》)、需求里程碑报告、《配置申请表》、针对《软件需求规格说明书》进行同行评审、《评审通知》、《预读记录》、《评审意见汇总》、《评审报告》
项目管理过程
CMMI3过程域
涉及角色
立项管理
研发部门经理
项目计划
PP、VER
研发部门经理、项目经理、项目成员
项目监控
PMC
项目经理、项目成员
风险管理
RSKM
项目经理、项目组成员、风险负责人
需求管理
REQM
CCB、CCB负责人、变更提出人、项目组成员
结项管理
PMC、MA
项目经理、项目成员、度量负责人
项目研发过程
度量和分析
MA
度量分析的目的在发展与维持度量能力,以支持管理的信息需求。
配置管理
CM
通过执行版本控制、变更控制等规程,以及使用配置管理软件来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。
质量保证
PPQA
提供一种有效的人员组织形式和管理方法,通过客观地检查和监控“过程质量”与“产品质量”,从而实现持续地改进质量。
质量保证
PPQA
QA、研发部门经理、项目经理、质量管理部经理、高层管理者
组织过程
CMMI3过程域
组织过程专注
OPF
过程改进建议人、EPG(组长)、QA、试点组项目、所有项目组
组织过程定义
OPD
EPG组长和成员、各过程定义负责人、试点项目组
培训管理
OT
公司级:公司级培训员、人力资源部经理、总裁
部门级:部门培训员、部门经理
CMMI3过程域
目的
需求开发
RD、VER
通过调查与分析,获取用户需求并定义产品需求,并对用户的需求进行验证。
技术预研
TS、VER
在立项之后到开发工作完成之前的时间内,对项目将采用的关键技术提前学习和研究,尽可能早地发现并解决开发过程中将会遇到的技术障碍。
概要和详细设计
设计软件系统的体系结构、用户界面、数据库、模块等,从而在需求与代码之间建立桥梁,指导开发人员去实现能满足用户需求的软件产品。
项目管理过程
CMMI3过程域
输出
立项管理
《项目论证报告》、《项目立项审批表》、《项目任务书》
项目计划
PP、VER
计划初稿:《项目总计划》(初稿)、《项目计划》(初稿)、《质量保证计划》、《配置管理计划》、《风险管理计划》、《数据收集与分析计划》
计划定稿:《项目总计划》、《项目计划》、《工作量估算纪录》、《项目估算报告》、《项目进度计划》、《项目工作任务表》;各附属子计划《质量保证计划》、《配置管理计划》、《风险管理计划》、《数据收集与分析计划》《测试计划》;针对《项目计划》进行同行评审《评审通知》、《预读记录》、《评审意见汇总》、《评审报告》
试运行
VAL
在产品正式销售之前,开发方将产品交付给一些潜在的客户免费试用,请他们对产品进行测试,并获取他们对产品的建议。
客户验收
客户依据合同对产品进行审查和测试,确保产品满足客户需求。
机构支撑过程
CMMI3过程域
目的
决策分析及决议
DAR
决策分析及决议的目的在于使用正式评估过程,依据已建立的准则评估各种已识别的备选方案,以分析可能的决策。
CMMI3过程域
需求开发
RD、VER
需求工程师、项目经理、客户
概要设计
TS、VER
系统分析员、评审组
详细设计
项目组成员、评审组
编码和单元测试
项目组成员
产品集成
PI、VER
项目经理
集成和系统测试
VER
工作产品评审过程:评审组长、评审作者、评审人员、会议记录人
工作产品测试过程:测试组长、项目组、测试人员
项目监控
PMC
《项目跟踪报告》、《里程碑报告》、《工作周报、月报》、《问题记录表》
风险管理
RSKM
《风险清单》、《已发生风险事件列表》、《风险检查表》
需ቤተ መጻሕፍቲ ባይዱ管理
REQM
《需求变更登记表》、《需求变更汇总表》、《需求跟踪矩阵》
结项管理
PMC、MA
《项目结项报告》
项目研发过程
CMMI3过程域
需求开发
RD、VER
试运行和客户验收
VAL
《用户试用计划》、《用户试用报告》、《验收测试大纲》、《验收测试报告》、《验收计划》、《验收报告》、QA依据试运行、验收检查表、检查试运行、验收、QA的试运行、验收检查结果、(《不符合项跟踪表》)、《试运行、验收里程碑报告》、《配置申请表》
机构支撑过程
CMMI3过程域
决策分析及决议
主要包括项目计划初稿和项目计划定稿。对于项目计划定稿要进行计划验证工作。
外包与采购管理
SAM
选择合适的承包商(外包)和供应商(采购),并依据合同进行有效的管理。
项目监控
PMC
周期性地跟踪项目计划的各种参数如进度、工作量、费用、资源等,不断地了解项目的进展情况,以便当项目实际进展显著偏离计划时能够及时采取纠正措施。
DAR
《通知》、《决策打分表》、《决策报告》
度量和分析
MA
项目总结报告
配置管理
CM
《配置状态报告》、《配置变更申请表》、《配置管理台帐》、《项目QA对配置管理员进行的配置审计以及审计过程中发现的问题记录》
质量保证
PPQA
《质量保证阶段报告》、《质量保证报告》、《组织级QA对项目QA的检查以及检查过程中发现的不符合项问题记录》
组织过程
CMMI3过程域
目的
组织过程专注
OPF
组织过程专注的目的在于以充分了解现行组织过程及过程资产的优点与缺点为基础,策划、执行与开展组织过程改进。
组织过程定义
OPD
组织过程定义的目的是建立并维护可用的组织过程资产与工作环境标准。
培训管理
OT
根据机构(或项目)的需求来制定培训计划,并监督该计划的实施,确保培训取得预期效果。
组织过程
CMMI3过程域
组织过程专注
OPF
《过程改进建议表》、《过程评估报告》、《过程改进计划》、《过程改进试点计划》、《过程改进实施报告》、《修改后的规范》、《制度文件》
组织过程定义
OPD
《各PA相关文件》、《评审报告或会签报告》
培训管理
OT
《培训实施计划》、《培训材料》、《培训记录表》、《培训考核表》、《培训反馈表》、《用人部门意见》、《反馈表》、《培训总结报告》、《培训心得》、《考核成绩或证书》
内部培训:培训员、讲师、人力资源部经理或部门经理
外部培训:培训员、外部讲师、受训人员、人力资源部经理
编码和单元测试
《开发与测试计划》、代码;《单元测试报告》、《单元测试缺陷记录》
产品集成
PI、VER
《产品集成计划》、针对《产品集成计划》进行同行评审、QA依据产品集成检查表检查、QA的产品集成检查结果、(《不符合项跟踪表》)、《产品集成里程碑报告》、《配置申请表》、《用户手册》
集成和系统测试
VER
《集成测试报告》、《集成测试缺陷记录》、《系统测试报告》、《系统测试缺陷记录》、QA依据测试检查表检查设计、QA的测试检查结果、(《不符合项跟踪表》)、《测试里程碑报告》、《配置申请表》、针对《集成测试报告》、《系统测试报告》进行同行评审
概要设计
TS、VER
《概要设计说明书》、《备选方案》、系统原型、针对《概要设计说明书》、进行同行评审、概要、详细设计到重大方案选择,启用DAR、《通知》、《决策分析打分表》、《决策分析报告》
详细设计
《详细设计说明书》、《数据库设计说明书》、针对《详细设计说明书》进行同行评审、QA依据设计检查表检查设计、QA的设计检查结果、(《不符合项跟踪表》)、《设计里程碑报告》、《配置申请表》
编码和单元测试
依据系统设计文档,编写并测试整个系统的代码。实现与测试是“编程、代码审查、单元测试、集成测试、缺陷管理与改错”的综合表述。
产品集成
PI、VER
产品集成的目的在于将产品组件组合为产品、确保已集成的产品能适当地运作及交付产品。
相关文档
最新文档