CMM中的需求管理与需求开发

合集下载

CMM简介软件能力成熟度模型

CMM简介软件能力成熟度模型
CMM简介软件能力成熟度模型
CMM的五个等级
1. 初始级:软件过程的特点是无序的,甚至是混乱的。 几乎没有什么过程是经过妥善定义的,成功往往依 赖于个人或小组的能力。
2. 可重复级:建立了基本的项目管理过程来跟踪成本、 进度和功能特性。制定了必要的过程纪律,能重复 早先类似应用项目取得的成功。
3. 已定义级:已将管理和工程活动两方面的软件过程 文档化、标准化,并综合成该机构的标准软件过程。 所有项目均使用经批准、剪裁的标准软件过程来开 发和维护软件。
4. 已管理级:收集对软件过程和成品质量的详细度量 值,对软件过程和产品都有定量的理解和控制。
5. 优化级:过程的量化反馈和先进的新思想、新技术 促使过程不断改进C。MM简介软件能力成熟度模型
关键过程域
指明为了改进其软件过程组织应重点关注的区 域。识别出为了达到某个成熟度等级所必须着 手解决的问题。
SEI:美国卡耐基梅隆大学的软件工程研究 院产品
SEI:为美国联邦政府评估软件供应商能力,于 1986年开始研究的模型,于1993 年推出CMM 1.1版。
CMM 1.1版:是目前世界上比较流行和通用的CMM 版本。
新研究:
CMMI ( Integration ) P-CMM ( People ) SACMM ( 软件获取CMM )
CMM定义:对于软件组织在定义、实现、度量、控 制和改善其软件过程中各个发展阶段的描述。这个模 型便于确定软件组织的现有过程的能力和查找软件质 量及过程改进方面最关键的问题,从而为选择过程改 进战略提供指南。
CMM简介软件能力成熟度模型
SEI:Software Engineering Institute
组织过程定义的目标是,开发和维护一组可用的能提高项目软件 过程整体效能的软件过程资源集合,并为在定量过程管理中确定 有意义的数据提供基础,这些资源提供了一组稳定的准则,并通 过诸如培训等机制使其制度化。

需求开发与需求管理指引

需求开发与需求管理指引

需求开发与需求管理指引第1章C M M I综述·2·第1章 CMMI综述1.1CMMI简介 (4)1.1.1 CMMI发展简史 (4)1.1.2 CMMI的过程域 (5)1.1.3 CMMI的两种表⽰法 (6)1.2CMMI阶段式表⽰法 (7)1.2.1 成熟度等级L1:初始级的特征 (8)1.2.2 成熟度等级L2:已管理级的特征 (9)1.2.3 成熟度等级L3:已定义级的特征 (9)1.2.4 成熟度等级L4:量化管理级的特征 (9)1.2.5 成熟度等级L5:持续优化级的特征 (10)1.3CMMI连续式表⽰法 (10)1.3.1 能⼒等级0-不完整级的特征 (12)1.3.2 能⼒等级1-已执⾏级的特征 (12)1.3.3 能⼒等级2-已管理级的特征 (12)1.3.4 能⼒等级3-已定义级的特征 (13)1.3.5 能⼒等级4-量化管理级的特征 (13)1.3.6 能⼒等级5-持续优化级的特征 (14)1.4过程域的部件及解释 (14)1.4.1 必需部件 (15)1.4.2 期望部件 (15)1.4.3 信息部件 (16)1.5CMMI评估 (17)1.5.1 CMMI评估要求 (17)第1章 CMMI综述.3.1.5.2 CMMI标准评估⽅法SCAMPI (17) 1.5.3 CMMI评估考虑事项 (18)1.6CMMI和CMM的⽐较 (19)1.6.1 CMMI与CMM的模型⽐较 (19)1.6.2 CMMI 与CMM 过程域⽐较 (19)1.6.3 CMMI 与CMM评估⽅法⽐较 (21)1.7CMM/CMMI在中国 (21)·4·第1章 CMMI综述1.1 CMMI简介1.1.1 CMMI发展简史1981年,美国卡内基梅隆⼤学软件⼯程研究所(SEI),应美国联邦政府的要求开发了⼀种⽤于评价软件承包商能⼒并帮助其改善质量的⽅法。

Watts Humphrey将成熟框架带到了SEI并增加了成熟度等级的概念,将这些原理应⽤于软件开发,发展成为软件过程成熟度框架,它提供了⼀个评估软件开发过程的管理以及⼯程能⼒的标准。

CMM中的需求管理与需求开发

CMM中的需求管理与需求开发

需求管理(Requirements Management )是属于CMM2中的过程域,简称为REQM ,需求开发(Requirements Development )是CMM3中的过程域,简称RD 。

这两个过程域是CMMI 体系中关于需求的全部内容,下面分别对这两部分进行介绍。

本文对CMM 的一些基础知识、基础术语不再介绍。

需求管理与需求开发的分界线:市场营销用户需求管理层需求开发需求管理市场营销管理层项目环境项目变更 大家可以这样理解,需求管理是指对需求变更的管理、对需求的跟踪,而获取需求、定义需求则属于需求开发部分。

需求管理在CMMI 中,需求管理的目标定义为:a. 把软件需求建立一个基线供软件工程和管理使用。

b. 软件计划、活动和工作产品同软件需求保持一致。

更高的目标:软件需求的复用需求管理的原则和方法a. 必须与需求工程的其他活动紧密整合b. 需求必须是文档化的、正确的、最新的、可管理的、可理解的c. 只要需求变化了,需求变更的影响就必须被评估d. 需求必须分优先级e. 需求一定要分类管理需求管理的主要工作:特定目标和特定实践特定目标●管理需求管理需求并识别需求与项目计划和工作产品之间的差异。

●SP 1.1 取得需求理解●SP 1.2 取得需求承诺●SP 1.3 管理需求变更●SP 1.4 维护需求的双向追溯性●SP 1.5 识别项目工作与需求间的差异REQM特定目标的关系SP 1.1 取得需求理解SP 1.1 和需求提出者一同来了解需求。

l 识别出谁是需求的提供者l 识别出需求的接受标准:a. Clearly and properly stated得到清晰和恰当的定义b. Complete完整的c. Consistent with each other相互一致的d. Uniquely identified得到唯一标识的e. Appropriate to implement适宜实现f. Verifiable (testable)可以验证(测试)g. Traceable可追溯l 分析需求,确保符合已建立的准则。

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中过程区域分为四大类:过程管理、项目管理、工程以及支持。

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

这样,在按照连续式表示方法实施CMMI的时候,一个组织可以把项目管理或者其他某类的实践一直做到最好,而其他方面的过程区域可以完全不必考虑。

CMMI体系介绍

CMMI体系介绍
中油龙慧北京信息技术分公司内部资料
CMMI体系介绍
质量控制中心:董宝国 2011年4月
大纲
1 行业背景
2 MMI前世今生 3 CMMI基本框架
4
CMMI过程改进成果与经验
5
CMMI改进规划
6
问题交流
一 行业背景
截止2009年末,世界CMM/CMMI认证企业数量
CMM/CMMI认证数量
882, 16% 1200, 22%
09年度
进度偏差 成本偏差
某公司实施CMMI3过程改进三年数据对比
7% 3%
10年度
四 CMMI 改进经验分享-最佳实践
1. 建立组织资产库
1. 体系文件库(项目规范及模板文件) 2. 度量数据库(公司执行历史项目的数据汇总分析) 3. 风险库(成功的和失败的风险教训) 4. 经验库(历史项目文档;优秀样例;培训教材库;知识库) 2. 项目分类管理 3. 项目管理过程可视化、数据化,拒绝“讲故事”,用数据说话。 4. 项目绩效考核 5. 挣值管理 6. 代码走查、原型+用例描述需求…………
三 CMMI基本框架
1. CMMI的表现形式 2. CMMI的成熟度等级 3. CMMI的架构介绍 4. CMMI的评估方法
三 CMMI基本框架-表现形式
CMMI的两种表现形式: 阶段式Staged:用成熟度级别 连续式Continuous:用能力级别
CMMI的两种级别: Capability levels:用于衡量每个过程域的过程改进 Maturity levels:用于衡量整个组织的过程能力和组织成熟度
四 CMMI 改进经验分享
成功项目4个要素
清晰预算 需求明确 进度要求 交付质量 采纳变更

cmm是什么意思

cmm是什么意思

cmm是什么意思CMM是指能力成熟度模型,其它是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。

CMM的核心是把软件开发视为一个过程,并根据这一原则对软件开发和维护进行过程监控和研究,以使其更加科学化、标准化、使企业能够更好地实现商业目标。

此外还是化妆品的名字。

实施CMM的必要性。

软件开发其中最关键的问题在于软件开发组织不能很好地管理其软件过程,从而使一些好的开发方法和技术起不到预期的作用。

而且项目的成功也是通过工作组的杰出努力,所以仅仅建立在可得到特定人员上的成功不能为全组织的生产和质量的长期提高打下基础,必须在建立有效的软件如管理工程实践和管理实践的基础设施方面,坚持不懈地努力,才能不断改进,才能持续地成功。

软件质量是一模糊的、捉摸不定的概念。

我们常常听说某某软件好用,某某软件不好用。

某某某软件功能全、结构合理,某某某软件功能单一、操作困难。

这些模模糊糊的语言不能算作是软件质量评价,更不能算作是软件质量科学的定量的评价。

软件质量,乃至于任何产品质量,都是一个很复杂的事物性质和行为。

产品质量,包括软件质量,是人们实践产物的属性和行为,是可以认识,可以科学地描述的。

可以通过一些方法和人类活动,来改进生活质量。

实施CMM是改进软件质量的有效方法,控制软件生产过程、提高软件生产者组织性和软件生产者个人能力的有效合理的方法软件工程和很多研究领域及实际问题有关,主要相关领域和因素有,需求工。

理论上,需求工程是应用已被证明的原理、技术和工具,帮助系统分析人员理解问题或描述产品的外在行为。

软件复用。

定义为利用工程知识或方法,由一已存在的系统,来建造一新系统。

这种技术,可改进软件产品质量和生产率。

还有软件检查、软件计量、软件可靠性、软件可维修性、软件工具评估和选择等。

CMMI体系概述

CMMI体系概述

CMMI体系概述CMMI(Capability Maturity Model Integration)是一个被广泛采用的过程改进框架和评估模型。

它提供了一种尝试和提高组织内软件和系统产品开发、维护和管理过程质量和效率的方法。

CMMI通过一个层次结构来组织和描述这些过程,并提供了一种评估和改进这些过程的方法。

CMMI最初是由美国国防部为了提高其软件和系统产品开发过程的能力而开发的。

该模型最早是以CMM(Capability Maturity Model)的形式出现,它被广泛应用于软件开发领域。

然而,随着对软件开发以外过程的需求增加,CMMI随后被引入和扩展到其他领域,如系统工程、工程、产品开发、供应链管理等。

CMMI采用了一个层次结构的方法来描述和评估组织的过程能力。

这个层次结构由五个不同的成熟度等级组成,从最初的“初始”级到最高的“优化”级。

这些级别反映了组织过程的能力水平和成熟度。

在每个成熟度等级中,CMMI描述了一系列的过程领域和实践,这些实践描述了在组织中实现成熟程度所需的活动和任务。

这些实践可以被组织用来评估并改进其过程的质量和效率。

CMMI的主要目标是帮助组织提高其过程能力,并在产品开发、维护和管理过程中实现更高的质量、效率和可靠性。

通过采用CMMI,组织可以更好地理解和管理其过程,提高与合作伙伴的协作和沟通,在市场上增强竞争力。

由于其广泛的应用和认可,CMMI已经成为许多组织在过程改进和能力评估方面的首选模型。

在一些领域,如国防、航空航天、金融和电信,CMMI已经成为实施组织过程改进的行业标准。

尽管CMMI在过程改进中有很多好处,但它也面临着一些挑战和批评。

有些人认为,CMMI过于复杂和繁琐,实施起来需要大量的时间和资源,特别是对于小型企业来说。

此外,一些人也认为,CMMI过于侧重于过程和文档,而忽视了创新和灵活性。

总的来说,CMMI是一个广泛应用的过程改进框架和评估模型,它提供了一种帮助组织提高过程能力和质量的方法。

CMM介绍与关键过程域说明

CMM介绍与关键过程域说明

CMM介绍与关键过程域说明CMM(Capability Maturity Model)是一种用于管理和评估组织软件开发能力的框架,旨在帮助组织提高其软件开发过程的成熟度,从而提高软件质量和效率。

CMM通过一系列定义明确的关键过程域来描述一个成熟的软件开发组织的特征和实践。

以下是关于CMM和关键过程域的详细介绍。

CMM是由美国软件工程研究所(SEI)于1980年代末开发的。

它最初是为了衡量美国国防部软件供应商的能力而设计的。

CMM在软件工程领域的可行性和实用性被广泛认可,并在全球范围内被广泛采用。

CMM的主要目标是帮助组织改进其软件开发过程的效率和质量,并推动软件工程实践的采用。

CMM采用了一个阶梯式模型,包括五个不同的成熟度级别,从初始级别到最高级别分别是:初始级别、可重复级别、已定义级别、已管理级别和优化级别。

每个级别都有一组关键过程域,这些关键过程域是用于衡量和评估组织软件开发能力的基础。

下面是对每个成熟度级别和相关关键过程域的详细说明:1. 初始级别(Level 1 - Initial)在初始级别,组织的软件开发过程是不可预测的,不受控制的。

该级别缺乏组织和过程的可见性和管理。

没有明确的目标和计划,开发活动主要靠个别开发人员的技能和经验来完成。

2. 可重复级别(Level 2 - Repeatable)在可重复级别,组织开始建立一些基本的项目管理和过程管理能力。

关键过程域包括需求管理、配置管理、项目计划和追踪、软件质量保证等。

目标是确保软件开发过程的可重复性和可控性。

3. 已定义级别(Level 3 - Defined)在已定义级别,组织建立了一套标准化的软件开发过程,并且这些过程已经在组织范围内得到了共享和理解。

关键过程域包括需求开发、软件设计、软件构建、软件测试等。

目标是确保软件开发过程的一致性和稳定性。

4. 已管理级别(Level 4 - Managed)在已管理级别,组织通过定量的管理和度量,对软件开发过程进行管理和优化。

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基础知识

cmmi基础知识

cmmi基础知识CMMI全称是Capability Maturity Model Integration,即能力成熟度模型集成,其目的是帮助软件企业对软件工程过程进行管理和改进,增强开发与改进能力,从而能按时地、不超预算地开发出高质量的软件。

以下是由店铺整理关于cmmi知识的内容,希望大家喜欢!CMMI版本介绍CMMI是一套融合多学科的、可扩充的产品集合,其研制的初步动机是为了利用两个或多个单一学科的模型实现一个组织的集成化过程改进。

CMMI的本质是软件管理工程的一个部分。

软件过程改善是当前软件管理工程的核心问题, 50多年来计算机的发展使人们认识到要高效率、高质量和低成本地开发软件,必须改善软件生产过程。

基于模型的过程改进是指采用能力模型来指导组织的过程改进,使之过程能力稳定的进行改善,该组织也能变得更加成熟。

CMMI的成功促使其他学科也相继开发类似的过程改进模型,例如系统工程、需求工程、人力资源、集成产品开发、软件采购等等,从CMM衍生出了一些改善模型,比如:SW-CMM,SE-CMM,IPD-CMM等。

不过,在同一个组织中多个过程改进模型的存在可能会引起冲突和混淆。

CMMI就是为了解决怎么保持这些模式之间的协调。

CMMI 1、3是2010年11月SEI 发布的CMMI模型的最新版本。

CMMI 1、3包括CMMI采购模型1、3版、CMMI开发模型1、3版、CMMI服务模型1、3版。

CMMI开发模型1、3版(CMMI-DEV 1、3)与CMMI开发模型1、2版相比,做了如下改进:1)将过程域“组织级创新与部署”(Organizational Innovation and Deployment,OID)更名为“组织绩效管理”(Organizational Performance Management, OPM),并增加了一个新的特定目标与几个新的特定实践。

2)对模型架构进行了改进,简化对多个模型的使用。

cmm的工作原理

cmm的工作原理

CMM(软件成熟度模型)的工作原理主要体现在以下三个方面:
1. 传感器探测:CMM通过在软件过程中设置一些关键环节的探测点,建立起能够反映软件过程能力的传感器。

这些传感器负责收集相关的数据和信息,例如缺陷密度、变更频率、需求变更率等,以实现对软件过程的实时反馈。

2. 坐标系建立:CMM通过分析收集到的数据和信息,建立起反映软件过程能力的坐标系。

这个坐标系以软件过程能力成熟度等级为横轴,以过程能力指数为纵轴,从而能够定量地评估软件过程的能力水平。

3. 数据处理:CMM通过对收集到的数据进行分析和处理,识别出软件过程中的不足和改进点。

这些数据被用于指导软件过程的改进,例如发现潜在的缺陷、优化变更控制、提高需求管理能力等,从而推动软件过程能力的不断提升。

总的来说,CMM的工作原理就是通过监测、分析和改进的方式来持续优化和改进软件过程,以提高软件的质量、可靠性和开发效率。

什么是CMM,CMMI

什么是CMM,CMMI
·
监控具体实践级别上的约定
·
强调对风险和相关人员参与的监督
4.
软件子合同管理
SSM
Software Subcontract
Management
供应商合同管理SAM
Supplier Agreement
Management
·
引入了原"子商管理"和"组间协调"的意图
·
强调合同的概念
5.
软件质量保证SQA
Software Quality
什么是CMM/CMMI?
发表日期:来源:北软金分
什么是CMMI?
软件能力成熟度模型(Capability Maturity Model For Software ,简称SW-CMM/CMMI),是由美国卡内基梅隆大学软件工程研究所(CMU SEI)研究出的一种用于评价软件承包商能力并帮助改善软件质量的方法,其目的是帮助软件企业对软件工程过程进行管理和改进,增强开发与改进能力,从而能按时地、不超预算地开发出高质量的软件。其所依据的想法是:只要集中精力持续努力去建立有效的软件工程过程的基础结构,不断进行管理的实践和过程的改进,就可以克服软件开发中的困难。CMM/CMMI是目前国际上最流行、最实用的一种软件生产过程标准,已经得到了国际软件产业界的认可,成为当今(企业)从事规模软件生产不可缺少的一项内容。
CMM
CMMI
CMM与CMMI区别
1.
需求管理RM
Requirements
Management
需求管理ቤተ መጻሕፍቲ ባይዱM
Requirements
Management
·
要与需求开发Requirement Development并行工作

CMMI是什么

CMMI是什么

CMMI是什么???(Capability Maturity Model Integration,能力成熟度模式整合)CMMI(Capability Maturity Model Integration)的本质是软件管理工程的一个部分。

软件过程改善是当前软件管理工程的核心问题,50多年来计算的发展使人们认识到要高效率、高质量和低成本地开发软件,必须改善软件生产过程。

基於模型的过程改进是指用采用能力模型来指导组织的过程改进,使之过程能力稳定的进行改善,该组织也能变得更加成熟。

然而,软件组织形成一套完整而成熟的软件过程不是一蹴而就的事情,需要经历一系列的成熟度。

软件组织首先要进行差异分析,评定自己比较接近哪一个成熟度,然后再根据自身的情况来决定要采取哪些改进活动,来更有效地改进自己的软件过程。

这就对软件过程的评定提出了一个客观的标准。

美国卡内基梅隆大学软件工程学院於1987年研究成功的SW-CMM (Capability Maturity Model for Software)就是这样的一个理论模型,其目的在於帮助软件组织改善软件生产流程,以探索一个保证软件产品质量、缩短开发周期、提高工作效率的软件工程模式与标准规范。

CMMICMM的成功促使其他学科也相继开发类似的过程改进模型,例如系统工程、需求工程、人力资源、集成产品开发、软件采购等等,从CMM衍生出了一些改善模型,比如:SW-CMM,SE-CMM,IPD-CMM等。

不过,在同一个组织中多个过程改进模型的存在可能会引起冲突和混淆。

CMMI就是为了解决怎麼保持这些模式之间的协调。

由业界、美国政府和卡内基·梅隆大学软件工程研究所率先倡导的能力成熟度模型集成(CMMI)项目致力於帮助企业缓解这种困境。

CMMI为改进一个组织的各种过程提供了一个单一的集成化框架,新的集成模型框架消除了各个模型的不一致性,减少了模型间的重复,增加透明度和理解,建立了一个自动的、可扩展的框架。

CMMI简介

CMMI简介

CMMI简介目录第一节CMMI概述 (1)1. CMMI的历史 (1)2. 软件过程成熟度 (1)3. CMMI中的成熟度等级 (2)4. CMMI的关键过程域 (3)5. CMMI的能力等级 (3)第二节CMMI的成熟度等级及其过程域 (4)1. 初始级 (4)2. CMMI已管理级 (4)3. CMMI已定义级 (6)4. CMMI量化管理级 (7)5. CMMI优化管理级 (7)第三节CMMI的应用 (8)第四节PSP,TSP与CMMI的关系 (9)1. PSP (9)2. TSP (10)第一节CMMI概述CMMI( Capability Maturity Model Integration)即能力成熟度模型集成,由CMM (Capability Maturity Model)发展而来,它最早是应用于软件业的一个过程改进模型,为软件组织描述了从混乱的、不成熟的软件过程向成熟有序的软件过程进行改进的一条途径。

后来随着应用的推广和模型本身的发展,CMMI逐渐演化成为一个被广泛应用的综合性过程改进模型。

1. CMMI的历史1991年,美国卡耐基梅隆大学软件工程研究所(SEI)推出了能力成熟度模型CMM,CMM的作用主要有两方面:为软件客户提供评价软件开发商能力的方法。

帮助软件开发商改进其软件过程,提高成熟度。

随着CMM在软件界应用的不断推广,其它相关学科和领域也采用它的模式,开发出了许多类似于CMM的模型。

SE-CMM (System Engineering CMM) 系统工程CMM,应用于系统工程管理。

SA-CMM (Software Acquisition CMM) 软件获取CMM,应用于软件获取(采购)方的能力成熟度模型。

IPD-CMM (Integrated systems product Development CMM): 集成系统产品开发CMM,应用于集成系统产品的开发管理。

P-CMM (People CMM):人员能力成熟度模型,应用于人力资源管理。

软件过程及能力成熟度评估指南_概述说明

软件过程及能力成熟度评估指南_概述说明

软件过程及能力成熟度评估指南概述说明1. 引言1.1 概述软件过程及能力成熟度评估是指通过对软件开发过程的分析和评估,以及对组织在软件开发中的能力和成熟度水平进行检查和衡量的一种方法。

在现代软件开发中,为了提高质量、控制风险并提高效率,评估和改进软件过程的能力和成熟度变得至关重要。

本篇文章旨在介绍软件过程及能力成熟度评估指南,它是一个用于帮助组织进行软件过程评估和提升的实用工具。

本文将涵盖以下内容:从介绍基本概念开始,重点解释了软件过程能力成熟度模型(如CMMI)以及相关的评估方法、流程等内容。

同时还会详细说明了评估前的准备工作、环境设置要点,以及整个评估步骤和方法,并且重点讲解了数据分析和结果报告部分。

1.2 文章结构本文共分为五个部分,具体内容如下:第一部分是引言,在这里我们对全文做出总体概述,并简要介绍文章的结构。

第二部分是关于软件过程能力成熟度评估的概念,我们将介绍软件过程能力成熟度模型以及评估的重要性和优势与应用场景。

第三部分是关于软件过程模型(例如CMMI)的介绍,我们将详细解释CMMI 的基本原则和结构,并说明五个成熟度级别的含义和要点。

此外,我们还会介绍CMMI评估方法及流程,帮助读者更好地理解和应用这一评估模型。

第四部分是对软件过程能力成熟度评估指南进行详解。

在这一部分中,我们将拓展论述评估前的准备工作和环境设置要点,接着详细介绍评估步骤和方法,并且通过实例讲解数据分析和结果报告要点。

最后一部分是结论及展望,在这一部分中我们将总结软件过程能力成熟度评估对软件开发的影响,并探讨未来发展方向,并以结束语作为全文的收尾。

1.3 目的本文旨在帮助读者全面理解软件过程及能力成熟度评估指南,并能够应用该指南进行有效的软件过程能力和成熟度评估。

通过评估和提升软件过程的能力和成熟度,组织能够更好地控制风险、提高产品质量和开发效率,并在竞争激烈的市场中取得可持续发展的优势。

2. 软件过程能力成熟度评估概念:2.1 软件过程能力成熟度模型介绍在软件开发领域,软件过程能力成熟度模型(Software Process Capability Maturity Model,简称SP-CMM或CMM)是一种用于评估组织的软件开发和管理能力的模型。

CMMI L3标准体系详解

CMMI L3标准体系详解

CMMI L3标准体系详解序:2级其实有很多问题还没有解决的,细心的人会发现,2级对软件工程活动的指导很弱,如:需求开发、设计、编码、测试等。

在3级,你会发现:1)有指导需求开发的需求开发(Requirements Development)这个PA;2)有指导设计、编码工作的技术解决方案(Technical Solution)这个PA;3)有指导如何保证工作产品满足要求的验证(Verification);4)有指导如何保证软件产品满足真实使用环境要求的(Validation);5)还有指导如何把软件产品各组件集成在一起并保证能在相应的硬件载体运行正常的产品集成(Product Integration);2级的PP与PMC是直接与项目管理有关的两个PA,在3级,对项目管理的要求进一步提高:6)集成项目管理(Integrated Project Management):3级的项目管理,要求利用组织级的财富库进行项目估算,并且利用财富库裁剪出项目自己的过程,并用这个过程来管理项目。

7)风险管理(Risk Management):2级只有PP的SP2.2中提到要识别风险,而在3级专门有一个PA对风险管理提出更高的要求。

大家不知道有没有发现,2级的PA都是直接针对项目提出要求的。

3级的IPM和RSKM,除了对项目级提出要求,另外也对组织级提出了要求,IPM要求有组织级的资产库,RSKM要求要有组织级的风险管理策略等。

另外,3级有几个“O”开头的PA,这几个PA都是直接对组织级的提出要求。

8)组织过程焦点(Organizational Process Focus):这个PA要求组织成立SEPG来推动过程改进的工作,要求识别、计划、实施改进过程,保证组织过程能持续改进。

9)组织过程定义(Organizational Training):这个PA要求组织级建立财富库,财富库内容要包括标准的过程、裁剪库、度量库、生命周期模型等。

CMM关键过程域

CMM关键过程域

CMM关键过程域CMM(Capability Maturity Model)是一个软件工程目标模型,用于评估和改进组织的软件开发过程的能力。

它将软件开发过程分为五个层次,从初始(Level 1)到最优化(Level 5),每个层次都代表着一定的过程成熟度。

CMM的五个层次称为“关键过程域”,每个关键过程域都代表了一个关键的软件开发活动。

1.软件需求管理软件需求管理是指通过适当的技术和工具,对软件需求进行识别、分析、规划和管理的过程。

在这个关键过程域中,组织应明确定义需求,制定合适的需求开发计划,并确保需求管理过程与其他项目管理过程有效地整合。

2.软件项目计划与管理软件项目计划与管理是指通过合适的技术和工具,对软件开发项目的范围、任务、资源、进度和风险进行计划和管理的过程。

在这个关键过程域中,组织应制定一个合适的项目计划,明确项目的目标、范围和约束条件,并建立一个有效的项目管理过程来确保项目按时、按质量地完成。

3.软件工程与迭代开发软件工程与迭代开发是指通过适当的技术和工具,设计、开发和验证高质量的软件的过程。

在这个关键过程域中,组织应建立一个适当的软件开发方法,确保软件开发过程的可控性和迭代性,并建立一个有效的软件工程过程来确保软件的质量。

4.软件产品集成与测试软件产品集成与测试是指通过适当的技术和工具,将各个软件组件整合在一起,并进行验证和确认的过程。

在这个关键过程域中,组织应确保软件组件集成的有效性和可靠性,并建立一个有效的软件测试过程来确保软件在各个集成阶段的质量。

5.软件配置管理软件配置管理是指通过适当的技术和工具,对软件产品的配置项进行控制和管理的过程。

在这个关键过程域中,组织应建立一个适当的配置管理策略,确保软件配置项的完整性和一致性,并建立一个有效的配置管理过程来确保软件配置的可追溯性和可控性。

这些关键过程域是CMM模型的基础,组织可以通过评估它们的成熟度来确定自己的软件开发能力,并制定相应的改进措施。

需求管理和需求分析

需求管理和需求分析

需求工程简介
把全部与需求直接有关旳活动通称为需求工程。需求工程中旳活 动可分为两大类,一类属于需求开发,另一类属于需求管理。 需求工程旳构造图
需求工程简介
市场
顾客/系统
管理者
初始需求
获取,分 析,定义, 验证需求
需求规格阐明
需求开发
变更旳需求
控制需求 变更
项目 环境
需求管理
需求工程简介
需求开发过程
系统需求(1) 系统需求(2) 系统需求(n)
软件需求
序言
➢“顾客”(user)是一种泛称,它可细分为“客户” (customer)、“最终顾客”(the end user)和“间接顾客” (或称为关系人)。掏钱买软件旳顾客称为客户,而真正操作软 件旳顾客叫最终顾客。客户与最终顾客可能是同一种人也可能不 是同一种人。 ➢客户是掏钱买软件旳人,所以他是“上帝” 。某饭店经理在解 释“先有鸡还是先有蛋”这个哲学问题时,精辟地论述了客户旳 地位:假如顾客先点鸡,那么就先有鸡;假如顾客先点蛋,那么 就先有蛋。 ➢客户旳需要才是最精确需求之源
需求开发旳主要困难与对策
7 顾客经常变更需求
需求变更一般会对项目旳进度、人力资源、经费产生很大旳影响,这是开发 商非常畏惧旳问题。
假如在项目开发旳初始阶段,开发人员和顾客没有搞清楚需求或者搞错了需 求,到了项目开发后期才将需求纠正过来,造成产品旳部分内容需要重新开 发。毫无疑问,这种需求变更将使项目付出额外旳代价。这种损失是因为双 方工作失误造成旳,双方应该好好反省,仔细学习需求开发和管理旳措施, 防止再犯相同旳错误。
需求开发旳主要困难与对策
5 双方误解需求
人们在交流旳时候,经常会发生“问非所求,答非所问 ”旳事情。

CMMI模型简介

CMMI模型简介

确定改进范围 以及获 取支 持
建立改 进机制
评估当前实 践情况
提出建议 并记录阶 段成果
诊断
计划,执行 和跟踪改进 方案
设定战略 和优先级
建立过程行 动组
做行动计划
建立
7
CMMI & ISO
• 都是过程改进模型 • 都是质量体系 • ISO适用范围广、普遍性 • ISO提出较早 • CMMI针对性、专业性强 • CMMI对软件开发更有具体指导性 • 两者不冲突,可以融为一体化
• 能力成熟度模型集成
一句话概括描述CMMI
• CMMI是一个企业实施开发、管理过程规 范化,或者是优化现有管理体系、制度的 行动框架或指南。 • —黄敬悦
12
CMM 的产生
• 在美国国防部资助下,由卡内基梅隆大学软件 工程研究所(SEI)建立,用于评价软件开发组织 软件过程能力成熟度的模型。
13
0 0 21
10
2
2
8
7
00
0 0 035 4 5 0 0 0 3
2 0 51
00
1 4 3 08
4 7 732 3 0 0
37 7
5 6 72
10
2
5 14 10 0 8
4 7 17 7 9 8 5 0 6 7 10
7 6 144
实践实施率
大部分满足 部分满足
不满足
50%
15%
35%
评估结果
评估结果-1
• 组织管理层基于组织标准过程库建立了过程目 标,并确保这些目标得到适当地表达。
• 2级和3级关键区别在于标准、过程和规程的范围 • 另外一个关键区别在于3级的过程比2级的描述更

基于CMM的需求管理活动

基于CMM的需求管理活动

C MM 提 出 了 一 个 软 件 过 程 改 进 的 框
档 就 定 义 了 开 发 工 作 的 需 求 基 线 。这 个 基 架 , 据 这 个 框 架 开 发 企 业 内 部 具 体 的 软 根 线 在 客 户 和 开 发 人 员 之 间 就 构 筑 了计 划 产 件 过 程 , 以 极 大 程 度 地 提 高 按 计 划 的 时 可 品 功 能 需 求 和 非 功 能 需 求 的 一 个 约 定 。 需 间 和 成 本 提 交 有 质 量 保 证 的 软 件 产 品 的 能 求 约 定 是 需 求 开 发 和 需 求 管 理 之 间 的 桥 力 。 在 C MM 的 实 践 中 , 业 的 软 件 过 程 企 梁 , 求 管 理 包 括 在 工 程 进 展 过 程 中 维 持 能 力 被 作 为 一 项 关 键 因 素 来 考 虑 。 所 谓 软 需
软 件 需 求 分 析 的 目 的 是 使 软 件 设 计 人 阶 段 的 错 误 只 占 9 。另 外 , GT TR % 对 E、 w 过 程 域 共 同 形 成 一 种 软 件 过 程 能 力 。 每 个
员 和 用 户 之 间 进 行 全 面 和 深 入 的 沟 通 , 和 I M 三 家 公 司 的 研 究 结 果 表 明 : 需 求 关 键 过 程 域 都 有 一 些 特 定 的 目 标 , 过 相 以 B 在 通
是 软 件 评 审 、 定 和 验 收 的 依 据 之 一 。 因 2 鉴 O倍 。 这 就 意 味 着 在 需 求 阶 段 与 维 护 阶 段 过 程 域 的 所 有 关 键 分 析 是 软 件 生 产 中 的 一 个 首 要 步 修 改 一 个 错 误 的 代 价 比值 可 高 达 1 2 0 需 :0 。
并 且 坚 持 不 懈 地 付 诸 实 践 , 能 取 得 全 组 中 , 有 被 检 测 出 来 的 错 误 , 4 是 在 编 码 分 解 为 三 个 层 次 加 以 定 义 。 这 三 个 层 次 是 才 所 5 %
相关主题
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

需求管理(Requirements Management )是属于CMM2中的过程域,简
称为REQM ,需求开发(Requirements Development )是CMM3中的过程域,简称RD 。

这两个过程域是CMMI 体系中关于需求的全部内容,下面分别对这两部分进行介绍。

本文对CMM 的一些基础知识、基础术语不再介绍。

需求管理与需求开发的分界线:
市场营销
用户需求
管理层
需求开发
需求管理
市场
营销
管理层需求变更项目环境
项目变更 大家可以这样理解,需求管理是指对需求变更的管理、对需求的跟踪,而获取需求、定义需求则属于需求开发部分。

需求管理
在CMMI 中,需求管理的目标定义为:
a. 把软件需求建立一个基线供软件工程和管理使用。

b. 软件计划、活动和工作产品同软件需求保持一致。

更高的目标:
软件需求的复用
需求管理的原则和方法
a. 必须与需求工程的其他活动紧密整合
b. 需求必须是文档化的、正确的、最新的、可管理的、可理解的
c. 只要需求变化了,需求变更的影响就必须被评估
d. 需求必须分优先级
e. 需求一定要分类管理
需求管理的主要工作:
特定目标和特定实践
特定目标
●管理需求
管理需求并识别需求与项目计划和工作产品之间的差
异。

●SP 1.1 取得需求理解
●SP 1.2 取得需求承诺
●SP 1.3 管理需求变更
●SP 1.4 维护需求的双向追溯性
●SP 1.5 识别项目工作与需求间的差异
REQM特定目标的关系
SP 1.1 取得需求理解
SP 1.1 和需求提出者一同来了解需求。

l 识别出谁是需求的提供者
l 识别出需求的接受标准:
a. Clearly and properly stated得到清晰和恰当的定义
b. Complete完整的
c. Consistent with each other相互一致的
d. Uniquely identified得到唯一标识的
e. Appropriate to implement适宜实现
f. Verifiable (testable)可以验证(测试)
g. Traceable可追溯
l 分析需求,确保符合已建立的准则。

l 与需求提供者达到需求共识,以使项目成员能承诺它们SP1.2 获取对需求的承诺
SP1.2 取得项目成员对需求的承诺。

●评估需求对现有承诺的影响。

需求变更或新需求发生时,评估它们对项目成员的影
响。

●协商并记录承诺。

在项目成员对需求或需求改变承诺之前,对现有承诺
的改变应先进行协商。

●承诺的时间点:
a. 需求刚建立时
b. 需求变更时
产出物
●需求影响评估
●需求和需求变更承诺的纪录
●项目组成员工作任务书
SP 1.3 管理需求变更
SP 1.3 当需求在项目执行期间逐渐开发时,管理
需求的变更。

●在项目执行期间,造成需求变更的原因很多:
a. 需要改变
b. 工作进行中产生新需求
●提出需求变更的动机是好的,目的是希望产品更加符合用户的需求。

对项目
开发小组而言,变更需求意味着要调整资源、重新分配任务、修改前期工作成果等,开发小组要为此付出较重的代价。

如果每次需求变更请求都被采纳的话,这个项目也许永远不能按时完成。

配置变更委员会CCB
●CCB是授权进行正式基线变更的机构
✓例如客户需求、设计基线。

●职能:
✓确保变更被分类以及被评估
✓评审和批准变更
✓确保只有被批准的变更得到实施
✓决定需要实施的变更的优先级
●变更控制活动必须在整个项目中具有可视性
●CCB成员可能包括:项目经理,配置管理员,质量保证人员,开发人员代表,
客户代表。

需求变更的阶段
●提交
●评估
●审批
●实施
●验证
●关闭
产出物
●需求变更申请表
●需求变更汇总表
SP 1.4 维护需求的双向追溯性
●维护需求与项目计划和工作产品间的双向追溯性。

●产出物:
需求跟踪矩阵
需求跟踪矩阵的主要作用
RTM的作用
A、验证需求的可实现性、可测试性
B、进行需求变更的影响分析
C、维护阶段,管理需求的变更
需求跟踪矩阵分为:纵向跟踪和横向跟踪
应该建立哪些需求跟踪矩阵?
●在SEI的调查中达成的基本共识是:纵向跟踪是必须的,如果没有,则REQM
SP1.4无法通过。

●对于纵向跟踪矩阵:
必需的:
✓客户需求与产品需求的跟踪
✓产品需求与测试用例的跟踪
✓100%的接口需求
✓全局性需求
✓核心需求
并非必需的:
✓性能需求
✓不影响系统架构的功能需求
需求跟踪矩阵由谁来建立?
●有多个角色参与建立RTM:
a. 需求开发人员
b. 设计人员
c. 测试用例的编写人员
d. PPQA
RTM是否纳入基线管理?
●RTM要纳入基线管理。

●纳入基线后,每次变更都要申请,RTM的变更一般是和其他配置项的变更一
起申请,很少单独申请变更RTM,除非RTM有错误。

●如何简化RTM的工作?
●由于在RTM中,需求可能有很多项,设计、测试用例、代码等都有多项,所
以建立和维护RTM的工作量还是比较大、比较烦琐。

对于变化频繁的项目,更是如此。

在实践中,为了简化该RTM的建立与维护工作,有的企业仅仅通
过需求与设计、代码、测试用例的编号来实现跟踪,如需求为:r1,r2,
……等编号,而设计的编号为:r1-d1,r1-d2,…….,测试用例的编号为:r1-t1,r1-t2等等。

需要注意的是需求与它们之间是多对多的关系,仅通过编号是无法实现这种关系的。

如果不借助DOORS之类的需求管理工具,一般只能通过EXCEL来维护RTM,工作量就
●是比较大。

要简化,就要平衡管理的投入与产出。

●当然也可以考虑增大需求、设计、代码、测试用例的颗粒度大小,但是那样
RTM的作用就打了折扣,还是一个平衡问题。

SP1.5 确认项目工作和需求间的差异
主要活动:
●评审项目计划、活动和工作产品是否与需求和需求变更相符。

●识别差异来源及其理由。

●当需求基线有变动时,识别有关计划和工作产品所需的变更。

●启动纠正措施。

识别差距的时机?
●评审时
●变更时
●日常工作中
识别出的不一致问题要有记录,并跟踪问题的关闭需求管理我们需要客户方如何做。

●了解乙方需求变更流程,并与乙方就此流程达成一致
●指定专人负责需求变更
●内部形成一个需求变更流程
●针对内部提交的需求变更,在提交乙方之前横向分析对业务的影响
●在提交乙方之前,内部达成一致意见
●需求变更必将导致乙方开发成本增加,为保证项目成功,必要时追加合同资

● .

●。

相关文档
最新文档