CMMI l2基础知识

合集下载

CMMI基础理论(全面介绍CMMI基础)

CMMI基础理论(全面介绍CMMI基础)

一:CMMI简介1.1 CMMI发展简史CMMI(Capability Maturity Model Integration,能力成熟度模型集成)是用于产品开发(或服务)的过程改进成熟度模型。

CMMI的最佳实践覆盖了产品构思、交付和维护的整个生命周期。

1981年,美国卡内基梅隆大学软件工程研究所(SEI),应美国联邦政府的要求开发的一种用于评价软件承包商能力并帮助其改善质量的方法。

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

1987年,基于Watts Humphery 等人的工作,SEI的Mark Pauk 等人建立了第一个CMM模型,即软件CMM。

1993年,SEI推出了CMM 1.1,这是目前世界上应用最广泛的CMM 版本。

十几年来CMM的改进工作一直不断地进行,相继有多个学科领域的CMM模型问世:SE-CMM, SW-CMM, IPD-CMM等。

美国国防采购与技术办公室领导了一个由政府、企业和SEI的代表组成的团队开始开发一个CMM模型的集成框架,即CMMI。

CMMI的基础源模型包括:软件CMM 2.0版本,EIA-731系统工程,以及IPD CMM (IPD) 0.98a版本。

2002年1月CMMI 1.1版本正式发布,并立即被广泛采用。

CMMI 1.2的三种模型·2·2006年8月,面向开发的CMMI(CMMI-DEV 1.2)版本正式发布。

为了适应更加广泛的应用,SEI 计划今后发布另外二种模型,分别是面向服务的CMMI(CMMI-SVC 1.2)版本和面向采购的CMMI(CMMI-ACQ 1.2)。

1.2 CMMI的过程域过程域(Process Area)是同属于某个领域而彼此相关的实践集合,当这些实践共同执行时,可以达到该领域过程改进的目标。

CMM(CMMI)基础知识介绍

CMM(CMMI)基础知识介绍
1987年9月,发表了关于过程成熟度框架简要说明和成熟度调查问卷。 以此为蓝本,1987——1991,在美国政府的促进下,美国一些大公司
的软件组织进行了软件过程成熟度模型的评估实践。SEI根据这四年 的实践经验,在原过程成熟度框架的基础上开发出了“软件能力成熟 度模型(CMM1.1版)”。 CMM1.1版发表后的两年里先后产生了三十多个草案,于己于1993年 2月发表了“软件能力成熟度模型的关键惯例1.1版”,统称SW— CMM1.1版,简称CMM。
◆ 技术 建立技术支持活动,并有稳定的计划。
◆ 度量 每个项目建立资源计划。主要关心成本、产品和进度。有相应的管理数据。
◆ 改进方向 (1) 不再按项目制定软件过程,而是总结各种项目的成功经验,使之规则 化,具体经验归纳为全组织的标准软件过程。把改进组织的整体软件过程能 力的软件过程活动,作为软件开发组织的责任。 (2) 确定全组织的标准软件过程,把软件工程及管理活动集成到一个稳固 确定的软件过程中。从而可以跨项目改进软件过程效果,也可作为过程剪裁 的基础。 (3) 建立软件工程过程小组(SEPG)长期承担评估与调整软件过程的任务, 以适应未来软件项目的要求。 (4) 积累数据,建立组织的软件过程库及软件过程相关文档库。 (5) 加强培训。
◆ 过程
软件开发和维护的过程是相对稳定的,但过程建立在项目一级。 有规则的软件过程是在一个有效的工程管理系统的控制之下,先前的成功经验
可以被重复。 问题出现时,有能力识别及纠正。承诺是可以实现的。
◆ 人员
项目的成功依赖于个人的能力以及管理层的支持。 理解管理的必要性及对管理的承诺。 注意人员的培训问题。
CMM/CMMI基础知识
1.1什么是CMM
CMM是指“软件能力成熟度模型”,其英文全称 为Capability Maturity Model

CMMI_L2标准体系详解

CMMI_L2标准体系详解

CMMI L2标准体系详解序:一个处于“无序化”生产的软件公司,要进行过程改进,首要是改进什么呢?做任何事情都需要计划,做软件开发这样复杂的工作更加需要计划,所以2级中有项目计划(PP)以及项目计划跟踪与控制(PMC)两个PA,分别对指定计划以及计划的执行给出了详细的标准。

人是会死的,需求是会变的。

需求变更是每个软件公司最头疼的问题,需求变更也是导致项目进度拖延、成本高涨的主要原因。

如何管理好需求呢?需求管理(RM)给出了详细的指引。

软件生产越来越复杂,有时候我们需要采购一些组件,用于项目中。

另外一个方面,纯软件的项目比例也慢慢缩小,很多软件是基于一定的硬件的,而不少硬件也是需要采购的。

如何采购到合适的软硬件,如何保证采购工作不影响项目成功呢?供应商协议管理(SAM)会给你一个解答。

软件是比较难进行量化管理的,但作为公司的管理者,总会想知道成本、进度、缺陷方面的一些数据,以了解项目的情况。

CMMI2级,已经对度量提出了要求,详细情况见度量(MA)这个PA。

如何保证软件生产过程中各类工作产品协调一致,配置管理(CM)会给出指导。

如何保证每个工作产品以及生产工作产品的过程是遵照规定执行的呢?产品与过程质量保证(PPQA)有明确的指引。

CMMI L2级一共有以下PA:1)项目计划(PP)2)项目计划跟踪与控制(PMC)3)需求管理(RM)4)供应商协议管理(SAM)5)度量(MA)6)配置管理(CM)7)产品与过程质量保证(PPQA)每个PA有什么乾坤呢?我们会详细向大家阐述。

目录一章:需求管理(Requirements Management) (2)二章:项目计划(Project Planning) (4)三章:项目跟踪和控制(Project Monitoring and Control) (6)四章:供应商协议(Supplier Agreement Management) (8)五章:过程与产品质量保证(Process and Product Quality Assurance) (9)六章:配置管理(Configuration Management) (10)七章:度量(Measurement and Analysis) (13)一章:需求管理(Requirements Management)人是会死的,需求是会变的。

CMMI+L2标准体系详解

CMMI+L2标准体系详解

CMMI L2标准体系详解序:一个处于“无序化”生产的软件公司,要进行过程改进,首要是改进什么呢?做任何事情都需要计划,做软件开发这样复杂的工作更加需要计划,所以2级中有项目计划(PP)以及项目计划跟踪与控制(PMC)两个PA,分别对指定计划以及计划的执行给出了详细的标准。

人是会死的,需求是会变的。

需求变更是每个软件公司最头疼的问题,需求变更也是导致项目进度拖延、成本高涨的主要原因。

如何管理好需求呢?需求管理(RM)给出了详细的指引。

软件生产越来越复杂,有时候我们需要采购一些组件,用于项目中。

另外一个方面,纯软件的项目比例也慢慢缩小,很多软件是基于一定的硬件的,而不少硬件也是需要采购的。

如何采购到合适的软硬件,如何保证采购工作不影响项目成功呢?供应商协议管理(SAM)会给你一个解答。

软件是比较难进行量化管理的,但作为公司的管理者,总会想知道成本、进度、缺陷方面的一些数据,以了解项目的情况。

CMMI2级,已经对度量提出了要求,详细情况见度量(MA)这个PA。

如何保证软件生产过程中各类工作产品协调一致,配置管理(CM)会给出指导。

如何保证每个工作产品以及生产工作产品的过程是遵照规定执行的呢?产品与过程质量保证(PPQA)有明确的指引。

CMMI L2级一共有以下PA:1)项目计划(PP)2)项目计划跟踪与控制(PMC)3)需求管理(RM)4)供应商协议管理(SAM)5)度量(MA)6)配置管理(CM)7)产品与过程质量保证(PPQA)每个PA有什么乾坤呢?我们会详细向大家阐述。

目录一章:需求管理(Requirements Management) (2)二章:项目计划(Project Planning) (4)三章:项目跟踪和控制(Project Monitoring and Control) (6)四章:供应商协议(Supplier Agreement Management) (8)五章:过程与产品质量保证(Process and Product Quality Assurance) (9)六章:配置管理(Configuration Management) (10)七章:度量(Measurement and Analysis) (13)一章:需求管理(Requirements Management)人是会死的,需求是会变的。

cmmi基础知识

cmmi基础知识
CMM CMM 2 CMM 3 CMM 5 工作启动 评估通过 评估通过 评估通过 CMMI 5 评估通过
CMMI 复评
1999
2000.9.29 2000.3.15
2001.6.26
2002.12.31 2003.4.4
2004.12.3 2003.11.28 2005.5.27 2006.6.22
Description 基本信息 MEAN 总代码行 有效代码行 需求规模 测试项规模 总工作量 总工期 总缺陷数 % 重用比例 发布前缺陷密度 发布后缺陷密度 总缺陷密度 ST 缺陷密度 客户发现缺陷密度 评审发现缺陷比率 平均生产率 编码生产率 COQ (%) COPQ (% ) 责任延期 规模偏差 工作量偏差 进度偏差 缺陷偏差 54 28 184 1645 46 174 262 35 9 0.07 9 4.9 0.8 36 632 2230 45 4 0 23 20 0 17 MAX 161 82 319 2700 162 457 730 96 13 0.31 13 9.2 1.5 52 989 4844 60 14 14 99 84 8 67 MIN 15 6 86 520 11 38 33 0 4 0.00 4 0.4 0.1 12 233 674 32 1 -10 -9 -12 -6 -46 UCL/UTL LCL/LTL Unit KLOC KLOC 个 个 人月 天 个 % Defects/KLOC Defects/KLOC Defects/KLOC Defects/KLOC Defects/KLOC % LOC/人月 LOC/人月 % % 天 % % % %
Neusoft Co., Ltd.
Beyond Technology
CMMI基础知识

CMMI L2 PPQA

CMMI L2 PPQA
过程和产品的质量保证 Process and Product Quality Assurance
北京英普信科技有限公司 Process Improvement Solution., Inc. 2006年3月 年 月
内部培训参考教材
声明
• • 此教材限量用于已与北京英普信科技有限公司签订合同的组织实施CMMI的内 的内 此教材限量用于已与北京英普信科技有限公司签订合同的组织实施 部培训参考使用,不能用于任何其它目的。 部培训参考使用,不能用于任何其它目的。 材料主要来源于CMU/SEI已公布的材料 已公布的材料 材料主要来源于 – “Introduction to Capability Maturity Model® Integration (CMMI®) Version 1.1 – Capability Maturity Model® Integration (CMMISM), Version 1.1 • 由于时间关系,翻译中会存在不准确或错误,请参照英文原文为主, 由于时间关系,翻译中会存在不准确或错误,请参照英文原文为主,并欢迎给 我们反馈。( 。(support@) 我们反馈。(
– SP2.1 沟通质量问题,并且确保找到解决不一致问题 沟通质量问题, 的办法 – SP2.2 建立和维护质量保证的 目标
客观地评价过程和工作产品 客观地 评价过程 客观地 评价工作 产品和 服务
报告和记录 提供客观的敏锐洞察 交流 并确保不 一致问题 的解决
建立记录
评价的特定工作产品
• 可以根据统计采样原理或者根据与组织方针、项目需求 可以根据统计采样原理或者根据与组织方针、 和要求一致的客观标准, 和要求一致的客观标准,来指定特定项目中要评价的特 定过程和相关工作产品
客观地评价过程

CMMI基础知识2-2和3级

CMMI基础知识2-2和3级
3
项目计划(Project Planning)(PP)

Project Planning的目的:

建立和维护计划,计划规定了项目需要做 的活动。

那么,需要做到怎样的程度,才算把 PP做好考虑,发表一下?
4
1.基础工作
1. 2. 3. 4.
分解项目任务,做WBS 列出工作产品和工作任务 考虑采用怎样的软件开发生命周期 确定工作量、费用等
8

2级特点小结


软件开发的一些细节没有定义:如需求 开发、设计、编码、测试 全部的PA都是针对项目这一级的,没 有组织级的PA。
9
2级和我们的水平比较

我们完全达到了2级的水平! 大家充分理解了2级所需要做的各项工 作!
10
3级的特点



项目管理水平升级 细化了软件工程的各个环节 增加了决策流程 加入了组织级方面的要求
27
组织级方面的要求



组织过程聚焦(Organizational Process Focus)(OPF) 组织过程定义(Organizational Process Definition)(OPD) 组织培训(Organizational Training)
28
3级小结-1

项目管理水平升级


这类工作,就是要满足项目计划的第一个目 标(Goal):建立评估(Establish Estimates) 而以上每一项,就是一个实践(Practice)
5
2.写计划
1. 2. 3.
4.
5. 6. 7.
建立预算和进度 识别项目风险 计划好如何管理各类文档、代码等 计划好软硬件资源 计划好需要哪些培训或者技术支援 计划好与用户、外单位的交涉 把以上内容文档化 这是项目计划的第二个Goal:开发一个项目 计划(Develop a Project Plan)

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

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

CMMI简介及CMMI2级的实施⽅案设计(DOC)CMMI简介及CMMI2级的实施⽅案设计第⼀部分 CMMI简介:CMMI 全称是Capability Maturity Model Integration,,即软件能⼒成熟度模型集成模型,是由美国国防部与卡内基-梅隆⼤学和美国国防⼯业协会共同开发和研制的。

CMMI (CMMI-SE/SW/IPPD)1.02 版本在部分国家和地区被SEI 开始推⼴和试⽤,主要应⽤于软件业项⽬,帮助提升对软件项⽬的管理能⼒。

随着模型本⾝的发展与应⽤的推⼴,CMMI 逐渐演变成为了⼀种被⼴泛采⽤的综合性模型。

在业界⼴泛使⽤的传统软件研发流程会带来⼀个严重的问题:存在于设计阶段的⼀个微⼩缺陷可能会直到后期的测试阶段才能被发现,⽽整个公司可能会花费数⼗倍甚⾄百倍的代价来改正这个缺陷。

为此,⼈⼒资源管理、软件采购、集成产品和过程开发、以及系统⼯程等等,多元化覆盖范围越来越⼴的能⼒成熟度模型应运⽽⽣。

1.1 CMMI 的作⽤软件能⼒成熟度集成模型(CMMI)经过长期积累和不断地优化,已经成功地发展并被认可为软件研发领域的标准过程体系,通过CMMI 可以增强企业核⼼竞争⼒、有效地提⾼软件企业产品质量,国内乃⾄国际上的⼴⼤软件⼚商都已经见证了CMMI 为企业带来的成功。

⽬前众多业界的软件企业纷纷试图使⽤CMMI 来达到过程改进的趋势,怎样才能将过程改进有效地实施,使其能实质地对软件研发过程起到优化效果,并带来⾏之有效地经济价值,已经逐渐成为了软件企业的决策者们最为关⼼的问题。

由最新SEI 评估报告中的数据显⽰,在进⾏了CMMI 的评估的企业中,⼤部分都是商业组织,并且其中近⼀半的企业⼈员规模都是在100 ⼈以下。

种种迹象均表明,CMMI 评估已经不仅仅吸引了⼤型IT 企业的注意⼒,同样存在⼤量的中⼩型企业也对此抱有浓厚的兴趣。

对软件企业来讲,CMMI 可以主要应⽤在两个地⽅:企业软件过程的改进和企业软件过程能⼒的评估。

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 基础培训资料

刘佳荔liujiali@质量是什么产品或服务满足用户给定要求的程度质量产生于每个人之手,而不是检验一组数据1.一个缺陷随着项目的进展越迟发现所消耗的成本越大2.每一个人的每一步工作都得到保证,才能确保产品按期、保质地完成,并节约项目的成本3.与质量有关的角色项目经理、需求分析师、设计分析师、编码工程师、测试工程师、配置工程师、QA工程师、项目的高层经理、其他:如文档工程师、评审组、客服过程的地位决定软件产品的成本、进度和质量的主要因素质量三角架过程、技术、人员过程过程的定义:(ISO/IEC 12207;GB/T 8566)指一系列活动、任务、和它们之间的关系、它们共同把一组输入转换成所需要的输出。

练习(过程的定义)1.项目情况:项目接到一个任务,负责实现一个模块,该模块主要实现将产品A输出进行加工转换成用户要求的格式。

目前已经进展到编码阶段。

2.任务:请各项目组明确编码过程的具体活动,以及各个角色的职责,派一名代表描述。

(五分钟明确,五分钟阐述)练习总结(过程的定义)1.不同的过程产生不同的结果2.同一任务由不同的项目组来完成,产生不同的结果3.即使在项目组内,每个项目成员的做法也不同(能过过程规范工作,尽量缩小每个人、每个组之间的不同,使得所生产出来的产品质量是可控的,产品是可共用的)什么是CMMI?1.集成的软件能力成熟度模型2.Capability Maturity Model-Integration美国国防部在卡内基-梅隆大学成立了软件工程研究所,于1987年推出SW-CMM框架,1993年推出SEI CMM1.1版并得到推行,2002年8月CMMI-SW1.1版发布实施。

CMMI将系统工程和软件工程集成在一起,将系统学科和软件学科集成为一个过程改进框架。

CMMI模型目前CMMI V1.1成套产品,按学科建立模型1.系统工程SE2.软件工程SW3.集成产品和过程开发(IPPD)4.供应商来源(SS)CMMI-WS/SE阶段式模型5优化级4定量管理级3定义级2管理级1初始极不同等级的关注焦点CMMI L2与L3二级:1.项目级2.反应试三级1.组织级,将管理和工程两方面的过程文档化和标准化,并形成了组织级的过程资产。

CMMIL2考题

CMMIL2考题

CMMI 简介(25空)1、CMMI来源于全面质量管理(TQM)思想。

TQM认为,产品的质量在很大程度上取决于生产和维护这个产品所使用的过程。

2、CMMI模型有两种表述方式(Representation),他们是式表达和阶段式表达3、CMMI 阶段式表述2级一共有7个过程域(PA),这些过程域中属于项目管理领域的有:、、。

属于工程领域的有:。

属于支持领域的有:、、。

4、CMMI 阶段式表述将成熟度级别分为5级,它们的名称1-5级分别是:、、、、。

5、所有PA的内容在组织结构上是完全相同的,这些内容分为三类:必需的、和信息性的。

其中,必需的内容被称为和共性目标,共性目标下面所属的实践叫做实践。

6、一个过程就是为了某个结果而进行的一系列。

7、项目的三个基本特点是、独特的、。

8、对一个普通的项目通常需要管理其8个方面,并对这8个方面进行整体管理。

它们分别是、、、、人力资源、沟通、风险、采购。

9、项目是复杂的、长期的活动,因此常分成若干个阶段逐步进行,这些阶段的集合,就叫做项目的。

Project Planning (25空)1、在CMMI中阐述的项目计划的目的是:建立并维护项目计划,以定义项目。

2、CMMI PP过程域设立了3个特性目标(SG),它们依次是:、开发项目计划、。

3、计划的第一步是估算,估算的第一步是开发一个顶层WBS用来估计项目的。

然后要估算任务和产品的属性,其中最重要的是产品的。

接下来通过划分一些阶段,定义项目的。

最后,要为项目的工作产品和任务估算和成本。

4、项目计划过程域的SG2是说要开发一个项目计划,SP2.1到SP2.6分别指名了项目计划中应该包含的6项内容,这包括:、、数据管理、、知识和技能、。

5、项目计划需要与项目组内、外各相关干系人进行评审,达成广泛的。

6、一般的,组织通过建立并召开一个启动会议,以正式地启动一个项目。

7、项目计划是有层次的。

作为项目与相关干系人之间建立的“合同”、并不能随便修改的那种计划叫做。

CMMI基础简介ppt课件

CMMI基础简介ppt课件

SE制I对度过程化改的进过有程一个不简会单随描着述,建把立过它程们改进的当人作的公司离的去一而个消项目失来,考它虑作,制为定企一业个的
包含文制化定的过一程和部制分度被化保这些留过并程被(使the用big着ger。task)活动的综合计划,并实施。
下面是一个没有被制度化的场景,SEI对这个场景的描述是“奇迹是如何发生的”:
需求管理(REQM)
工程类
2
2
项目策划(PP)
3
项目监控(PMC)
4
供方采购管理(SAM)
5
度量与分析(MA)
6
配置管理(CM)
项目管理类 项目管理类 项目管理类 支持类 支持类
2

2

2
度 等
2

2

7
过程和产品质量保证(PPQA)
8
需求开发(RD)
9
技术解决方案(TS)
10 产品集成(PI)
11 验证(VER)
CMMI是一个用于产品与服务开发的过程改进成熟度模型。它包含开 发与维护活动的最佳执行方法,涵盖产品从构思到交付与维护的生 命周期。
CMMI是美国国防部委托卡耐基-梅隆大学(Carnegie Mellon University)软件工程学院(Software Engineering Institute)开 发出来的,作为采购方评估供应方的过程能力与组织成熟度标准, 也作为企业提高产品开发过程管理水品的参考。
高层审查过程改进的 效果。
EPG
高层
项目组向高层汇报过 项 项 目目 执执 行行 的的 状状 态态 。。 高层审查项目组执行 的效果。
项目组向EPG提出过
程改进建议。

CMMI的2级是成功实施CMMI的基础

CMMI的2级是成功实施CMMI的基础

CMMI的2级是成功实施CMMI的基础CMMI的2级是成功实施CMMI的基础,真正将2级做好了,对企业的帮助也是很显著的,而很多企业恰恰忽略了2级PA的实施,从而导致CMMI 的实施难以见到实效,2级需要抓住哪些实效点一定要落实呢?我做了如下的归纳:1 建立WBS分解的方法指南,训练项目经理如何进行任务分解,充分识别项目范围。

很多项目经理即使经受了PMP的专业培训,仍然没有掌握WBS 分解的方法,正如很多人拿到了驾照不会开车一样,缺乏实际训练。

在实施CMMI2级时,组织级应该定义出来WBS分解的方法指南、模板,供项目经理参考,并对项目经理建立的WBS进行多次评审,训练其分解的技能。

2 建立组织级的估算方法指南,教会项目经理如果做估算,为项目的工作量、工期、质量的平衡提供依据。

估算是帮助项目经理进行能力平衡的手段,通过估算工作量、工期、成本等可以平衡能力需求与实际可提供的能力之间的差别,即使不能满足能力也要知道差别有多大,这种差别是否可以通过加班、加人、裁剪需求等来弥补,不能糊里糊涂的做项目,即使死,也要死的明白。

在项目组需要进行估算的时机主要有3个时间点:(1)需求不明确,需要给客户报价或项目立项时;(2)需求明确时,需要制定项目的开发计划;(3)在开发或维护过程中,需求发生变更时,需要变更项目计划或给客户承诺变更的完成时间。

在不同的时机,不同的输入条件下,对于不同类型的任务采用的估算方法不同,不能一概而论,因此项目经理要灵活掌握,组织级要给出明确的指南。

3 教会项目经理使用project排进度表,合理安排进度,优化资源投入。

排进度表时要定义出任务之间的先后顺序关系,然后识别关键路径,想办法减少关键路径的长度,然后安排资源,再识别出关键链,减少关键链的长度,合理安排缓冲的时间,这样才能保证项目在比较短的时间内完成,如果进度安排不合理,会造成人为地工期拉长,有人忙,有人闲。

借助于项目管理的工具可以帮助项目经理识别关键路径,减少排计划的工作量。

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

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

CMMI Level 2 GP2.1 方针GP2.1 方针对每一个PA,公司都应该有相应的高层次的要求来指导该方面的工作,也就是所谓的方针。

方针这东西很很容易被认为是虚的东西,我们需要仔细体会方针,这个GP是公司商业目标与过程的结合点,过程是否能为商业目标带来价值,很大程度上就看这个方针是怎样定的,并且要把方针贯彻到过程中。

我们以PP这个PA为例子,如果微软要定PP的方针,我想会是:1.赋予小组成员权力,每个人都承担项目管理的责任;2.保持灵巧,预测变化;3.由底而上的估算办法;......在MSF中,我们会看到很多微软进行项目管理的一些原理和法则,这些法则,指导着如何做项目计划,不同的这些方针指导下,做出来的过程是不一样的。

每个公司都有自己的特点、商业目标、企业文化等,最开始我们可能难以制定出详细具体的过程,但首先要把这些过程的指导原则想好,方针是过程的灵魂,过程是否有魅力,是否可以让大家“愉快地”执行,关键就是看过程的方针了。

在我们公司,所有过程都遵循这样的一个方针,就是简单有效,我们要求所有过程都是必须用来执行的,做不到的过程不做,没有效果的过程不要,因为有这样一个原则,我们需要发动所有执行过程的同事来参与制定过程,以保证“简单有效”。

我们除了有简单有效这样的一个大原则,每个PA又会制定自己相应的方针。

大家在制定方针内容的时候,要从高层及执行过程的员工两个层面同时下手,整理出简单的有效的容易记忆的方针,并且在以后不断更新这个方针,保证这个方针能不断促进公司的发展。

项目监督和控制计划不是用来看的,是用来执行的。

PP讲述了如何做计划,PMC讲述的就是如何跟踪计划的执行并在实际情况偏离计划时采取纠正行动。

我们先看看SG1,SG1讲述的是如何根据计划来跟踪计划的执行问题。

SG1: Actual performance and progress of the project are monitored against the project plan.中文大意是:根据计划,跟踪项目的实际性能和过程。

CMM教材I培训讲义CMMI1跟CMMI2

CMM教材I培训讲义CMMI1跟CMMI2
第三部分
CMMI2级:已管理
培训目标
•使学员能够了解如下知识:
–定义与成熟度2级相关的CMMISM专用术语 –阐明处于成熟度2级的组织的行为特征. –介绍成熟度2级过程域的目标描述、目的、关
系图和详细描述
•使学员能够掌握如下技能:
–能将工程活动与模型中的元素相对应 –采用流程图方式绘制特殊实践的活动细节
主题
• 成熟度1级和2级组织的特征 • 过程域图 • 成熟度2级的过程域 • 过程域关系 • 总结
分级表示法的成熟度等级
5 强调持续改进 4 量化控制过程 3 过程改进体现组织
优化管理 量化管理 已定义
2 过程改进体现项目. 1 过程不可预测,难以控制.
已管理 初始级
成熟度1级:初始级
• 过程能够执行, 但往往处于一种异常 或无序的状态.
优化管理 量化管理 已定义 已管理
初始级
项目策划
• 目的: 建立并维护定义项目活动的计划。
项目策划 - 特殊目标
• SG 1: 建立估算 估算项目计划参数并予以维护.
• SG 2: 制定项目计划 建立并维护项目计划,以此作为项目管理 的基础.
• SG 3: 获得对计划的承诺 建立并维护对项目计划的承诺.
通用实践的例子
•GP 2.3: 提供资源 对执行所策划的过程,开发工作产品,提供 需求管理过程的服务,提供足够的资源.
•用于执行需求管理活动的工具例子如下: - 需求跟踪工具 - 可追溯工具
成熟度2级的过程域
需求管理(REQM) 项目策划(PP) 项目监控(PMC) 供应协议管理(SAM) 测量与分析(MA) 过程与产品质量保证(PPQA) 配置管理(CM)
获得 对计划的承诺

1 CMMI L2 REQM(需求管理)

1 CMMI L2 REQM(需求管理)

CMMI L2 REQM需求管理过程域赛柏科技n初始级o 已管理级p 已定义级r 优化级n 初始级已管理级p 已定义级q 定量管理级主题I 需求开发与需求管理II REQM的SG和SPsIII REQM的GGs和GPsIV 需求管理示例V 小结VI 参考材料#已管理级的特点•特点是:项目级。

建立了基本的项目管理过程来跟踪成本、进度和功能特性,制定了必要的过程纪律,能重复早先类似项目取得的成功。

•项目过程得到计划和执行,并遵循相应的方针•提供了适当的资源来执行过程,并分配了执行过程的职责•对执行过程的人进行培训•过程的工作产品得到了管理和控制•过程本身得到了监督、控制和评审,并得到了客观评价#过程域图示表示法II #需求开发和需求管理需求相关活动需求开发需求管理需求调研需求分析需求定义需求确定管理需求实现管理需求变更管理#需求开发的目的#客户、产品及产品构件的需求-1#客户、产品及产品构件的需求-2#需求开发语境图确认后的客户需求产品需求需求需求管理的目的需求要控制•将需求交给开发组之前,必须对需求进行评审并解决发现的问题•所有需求要文档化并且受到控制•所有相关的计划、活动及其它与生命周期相关的工作产品要与需求保持一致•在整个产品开发过程中,建立并维护可跟踪性#需求管理过程#需求管理过程的流程图#需求管理过程流示例需求是构建系统的基础•构建任何系统,都是基于我们与客户共同确认的最小需求,对于用户的需求了解得越是确切,需求的稳定性就越高。

解决方案的不断演化,就是不断满足客户需求的过程(需求基线/变更)•对于大型系统,系统设计应从客户问题的专门知识入手,通过不断提炼的系统设计和软件设计,逐步增强对客户问题及相关知识的理解(需求确认)•如果上层设计选择正确,则很多低层设计将不会影响需求。

当然,需求问题可能在任何开发阶段出现,此时必须在需求层次上恰当地解决,不能只是在设计或编码上修补了事(追溯性)需求管理的基本任务•项目要采取适当的步骤来确保管理已得到批准的需求集,以便支持项目的计划和执行的需要–获得对需求的理解:从被认可的需求提供者收集需求,并与他们共同评审,以便在将需求纳入项目计划之前,解决不明确的问题并排除误解–获得对需求的承诺:一旦需求提供者和需求接收者达成了协议,从项目参与者获得对需求的承诺–管理需求变更:随着项目进展,当计划、工作产品和需求之间出现不一致时,项目经理要更改需求或更改计划–维持需求的双向可跟踪性:需求管理要将需求的变更及其变更的理由文档化,并维持源需求与所有产品和产品构件的需求之间的双向可跟踪性#有哪几类需求?•功能需求•性能需求•界面需求•接口需求•资源需求(管理方面的需求)•潜在需求(potential requirements)等#Requirements与Specification?•生命周期分若干个阶段,每个阶段的输出是下一阶段的Requirements,每个阶段的输出是该阶段的Specification •看Specification是否满足Requirements:称Verification •看每个阶段的输出是否满足最初的输入:称Validation •对第一阶段来讲:Verification也叫Validation•每个阶段既要进行Verification,也要进行Validation需求的双向可跟踪性-1•没有需求的可跟踪性,就不能有效地管理需求•一个需求是可跟踪的,其条件是当且仅当:–知道每个需求的源–知道为什么需要这个需求–知道哪些需求与它相关–知道需求如何与其它信息(如系统设计、实现及用户文档等)相关•可跟踪信息可用于发现哪些需求可能会受到需求变更的影响需求的双向可跟踪性-2•如果在系统实现过程中提出需求变更,应考虑以下情况:–变更对需求、系统设计及其实现影响的程度•如果在系统运行后提出需求变更,还应考虑以下情况:–该系统中有多少利益相关者受到此变更的影响需求的双向可跟踪性-3•在整个产品生命周期中,要捕捉所有需求和需求变更请求,并将他们放在配置管理之下(需求库)•在对项目计划、活动及工作产品执行需求变更请求的影响进行分析时,需求应该是可跟踪的(每项需求有唯一的标识符)•要生成一个需求跟踪矩阵,并可用于向前和向后的(双向)跟踪#需求跟踪矩阵•需求跟踪矩阵用于在各个生命周期阶段跟踪所有需求,确保每一项需求可以跟踪到实现该需求的设计、编码以及测试实现的测试用例•需求跟跟矩阵建立了从需求单元到设计单元、从设计单元到编码单元、从编码单元到测试用例的映射•通过跟踪,可以验证软件是否实现了所有需求以及软件是否对所有需求进行过测试,还可以在需求变更时分析变更带来的影响#前向跟踪和反向跟踪•存在两种类型的跟踪:–前向跟踪–后向跟踪•前向跟踪意味着看需求是否在生命周期的后期阶段(如设计和编码阶段)的输出元素中得到体现•后向跟踪则相反,它意味着后期各个阶段的输出元素满足何种需求。

CMMI L2 SAM解析

CMMI L2 SAM解析

– 安全性需求
– 来自于未来产品发布的好处和影响 未来产品发布可能提供附加的功能支持对项目已计划的和预 期的升级,但也可能导致供应商撤回对项目获取的产品版本 的支持
4. 评估供应商执行性能和交付能力
5. 识别与所选择的COTS产品和供应商协议相关的风险
版权所有 请勿翻印 31
CyberKeJi
子实践 -3
版权所有 请勿翻印 24
CyberKeJi
子实践 -3
– 识别项目监督供应商的形式及深度、规程、 供应商绩效的评 估准则
– 识别与供应商应进行评审的类型 – 识别供应商对项目获取的产品持续维护和支持的职责 – 识别所获取的产品的保修单、所有权、使用权 – 识别接收准则 4. 确保协议的各方在执行协议前对其中所有需求的理解和同意 5. 必要时,修订供应商协议 6. 必要时,修订项目计划和承诺,以反映供应商协议的修订
CyberKeJi
CMMI L2 SAM
供应商协议管理
Supplier Agreement Management
优化级
已定量管理级 定量管理级
已定义级 已定义级
赛柏科技
已管理级 已管理级
初始级 初始级
版权所有 请勿翻印 1
CyberKeJi


I. 基本概念与示例
II. SG1及其特定实践

• 需要建立准则来,来处理项目的重要要素。如: – 供应商的地理位置 – 供应商在类似工作上的表现记录 – 工程能力
– 可用于执行工作的员工和设施
同样应用程序上的历史经验 版权所有 – 请勿翻印
17
CyberKeJi
典型工作产品
1. 候选供应商的列表 2. 首选供应商的列表 3. 选择供应商的理由 4. 候选供应商的优缺点 5. 评价准则 6. 邀标材料和需求

2CMMIL2PPv2

2CMMIL2PPv2

CMMI L2 PP项目策划过程域赛柏科技n初始级o 已管理级p 已定义级q 定量管理级r 优化级n 初始级已管理级p 已定义级q 已定量管理级主题I 基本概念和示例II PP的SGs和SPs III PP的GGs和GPs VI 小结V 参考材料I 基本概念和示例•PP(Project Planning)的目的•CMMI中的项目管理过程域•PP的结构•PP的目标关系图•项目策划的基础是估计CMMI中的项目管理过程域•项目管理过程域(PAs)覆盖方面:–有关项目策划、监督和控制等管理活动•项目计划•项目监督和控制•供应商合同管理过程域•集成项目管理•风险管理•定量项目管理PP的结构15+2 实践d需求管理SG1:GG2:10 GP GG3: 2 GPPP的目的PP的目的就是制定和维护定义项目活动的计划制定项目计划是实施项目管理的基础PP的要点-1•PP包括以下主要活动:–开发项目计划–与项目相关人员适当的交流–得到对计划的承诺–维护计划•策划工作从定义产品和项目的需求开始•术语“项目计划”指的是控制项目的整体计划PP的要点-2•策划通过如下活动,迭代地建立项目计划–估计工作产品和任务的属性–确定需要的资源–商讨承诺–产生进度安排–标识和分析项目风险•项目计划提供执行和控制项目活动的基础,以满足项目对客户的承诺•当遇到需求和承诺变更、不正确的估计、纠正行动和项目过程变更时,通常需要修改项目计划PP的SGs和SPsSG 1 建立估计-1SG 1建立估计: 建立和维护项目计划参数的估计•项目规划参数包括项目从事下列活动所需的所有信息:规划、组织、用人、指导、协调、报告及预算。

•规划参数的估计值应有充分的根据,以提高自信心:任何以此估计值所做的计划,能够支持项目目标。

•有必要把估计的理由和支持性数据形成文件,以便在项目相关人员评审和获得对计划的承诺以及在项目进展过程中维护计划.SG 1 建立估计-2•在估计项目计划参数时,通常要考虑以下因素:–项目需求,包括产品需求、组织的需求、客户的需求和其它影响项目的需求–项目的范围–已识别的任务和工作产品–技术实现方法–选择的生命周期模型(如瀑布、增量、螺旋等)–工作产品和任务的属性(如规模或复杂度)–进度–转换工作产品和任务的属性为工时和成本的模型或历史数据–确定需要的材料、技能、工时和成本的方法(模型、数据和算法)SP 1.1估计项目的范围SP 1.1估计项目的范围: 建立顶层的工作分解结构(WBS)来估计项目的范围–WBS与项目一起进化,初期的最顶层WBS 用于初期估计。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

度量和分析过程域(续)
提供度量结果, 提供度量结果,以便处理信息需要和目标
包括: 包括:获得指定的度量数据 分析并解释度量数据 管理并存储度量数据和分析结果 向所有相关利益者报告度量和分析活动的结果
过程和产品质量保证过程域( PA) 过程和产品质量保证过程域(PPQA PA)
组织实施“过程和产品质量保证”过程域的目标是 组织实施“过程和产品质量保证” 要使工作人员和管理者能客观了解过程和相关的工 作产品的状况 客观评价过程和工作产品 包括:对照适用的过程描述、标准和规程, 包括:对照适用的过程描述、标准和规程,对 指定的已实施的过程进行客观评价 对照适用的过程描述、标准和规程, 对照适用的过程描述、标准和规程,客观评价 所指定的工作产品和服务
项目计划过程域(续)
制订并维护项目计划,作为项目管理的基础 制订并维护项目计划,
建立项目的预算和ቤተ መጻሕፍቲ ባይዱ度 识别并分析项目风险 计划数据管理 计划项目的资源 计划所需的知识和技能, 计划所需的知识和技能,培训相关人员 计划项目相关人员的参与。( 。(使已识别的利益相关者介 计划项目相关人员的参与。(使已识别的利益相关者介 入的计划) 入的计划) 制订并维护整个项目计划内容。 制订并维护整个项目计划内容。
组织实施“项目监督和控制” 组织实施“项目监督和控制”过程域的目标是监督项目的进 以便在项目性能明显偏离计划时, 展,以便在项目性能明显偏离计划时,采取适当的纠正措施 对照项目计划监督该项目的实际性能和进展 对照项目计划监督项目策划参数的实际值 对照项目计划中确定的承诺进行监督 对照项目计划中标识出的风险进行监督 监督项目数据的管理 对照项目计划监督利益相关者介入情况 定期审查项目进度、 定期审查项目进度、性能和问题 在所选定的项目里程碑处审查项目的完成情况和结果
项目计划过程域(PP PA)
组织实施“项目策划” 过程域的目标是制订并维 组织实施“项目策划” 护规定项目各项活动的计划 建立项目估计
建立并维护顶层工作分解结构,以便估计项目的范围 建立并维护顶层工作分解结构, 估计项目的总体规模和各阶段主要工作产品的规模 确定项目生命周期阶段 估计项目工作量和成本
CMMI L2基础知识 L2基础知识
七个过程域
CMMI(Capability Maturity Model Illtegration)
需求管理(REQM: Management) 需求管理(REQM:Requirements Management) 项目策划(PP: Planning) 项目策划(PP:Project Planning) 项目监督和控制(PMC: control) 项目监督和控制(PMC:Project Monitoring and control) 供应商协议管理(SAM: Management) 供应商协议管理(SAM:Supplier Agreement Management) 度量与分析(MA: analysis) 度量与分析(MA:Measurement and analysis) 过程与产品质量保证(PPQA:Process and Product 过程与产品质量保证(PPQA: Quality) Assurance Quality) 配置管理(CM: Management)) 配置管理(CM:Configuration Management))
项目计划过程域(续)
建立并维护对该项目计划的承诺
评审项目的附属计划, 评审项目的附属计划,以便了解项目承诺 协调项目计划,以反映项目可用的资源和计划的资源 协调项目计划, 获得项目计划的承诺。 获得项目计划的承诺。从各个负责实施和支持该项目 计划实施的利益相关者处获得承诺
项目监督和控制过程域(PMC PA)
项目监督和控制过程域(续)
当项目性能或结果明显偏离计划时,采取并 当项目性能或结果明显偏离计划时, 管理纠正措施,直到结束 管理纠正措施,
包括:收集并分析问题, 包括:收集并分析问题,确定处理这些问题所 需的纠正措施 对所识别的问题采取纠正措施 管理纠正措施, 管理纠正措施,直到结束
供应商协议管理过程域(SAM PA)
七个过程域
需求管理(REQM: Management) 需求管理(REQM:Requirements Management) 项目策划(PP: Planning) 项目策划(PP:Project Planning) 项目监督和控制(PMC: 项目监督和控制(PMC:Project Monitoring control) and control)
过程和产品质量保证过程域( 过程和产品质量保证过程域(续)
客观地跟踪和通报不符合问题, 客观地跟踪和通报不符合问题,并且确保解 决它们
向相关责任人和管理者通报质量问题, 向相关责任人和管理者通报质量问题,并且确 保解决它们 建立并维护质量保证记录
配置管理过程域(CM PA)
组织实施“配置管理”过程域的目标是运用配置标 组织实施“配置管理” 配置控制、配置状态统计和配置审计, 识、配置控制、配置状态统计和配置审计,建立和 维护工作产品的完整性 建立并维护用于标识工作产品的基线 包括: 包括: 识别将置于配置管理之下的配置项和有 关的工作产品 建立并维护用于控制工作产品的配置管理系统 和变更管理系统 创建或放行基线, 创建或放行基线,供内部使用和交付给顾客
需求管理过程域(REQM PA)
组织实施“需求管理” 组织实施“需求管理”过程域的目标是识别项目计 划和工作产品与需求之间的不一致之处, 划和工作产品与需求之间的不一致之处,确保能把 需求、需求的变更反映到项目计划、 需求、需求的变更反映到项目计划、活动和工作产 品中
获得对需求的理解(理解需求提供者提出的需求的含义) 获得对需求的理解(理解需求提供者提出的需求的含义) 获得对需求的承诺( 获得对需求的承诺(从各个项目参与者处求得对需求的 承诺) 承诺) 对需求的变更进行管理 维护在需求与项目计划和工作产品之间的双向可跟踪性 识别项目计划和工作产品与需求之间的不一致之处
组织实施“供方协定管理” 组织实施“供方协定管理”过程域的目标管
理每一个有正式合同或协议的供应商 处获得的产品
确定由外部获取的产品清单 根据对供方满足规定需求和准则的能力进行的 评估, 评估,选择供方 与供方签订协议并予以维护
供应商协议管理过程域(SAM PA)
供方和项目双方共同执行与供方的协议
采办商业现货产品 与供方共同执行供应商协议中规定的活动 在接受所采办的产品之前要确保供方协议得到 满足 把所采办的产品从供方纳入到项目中
度量和分析过程域(MA PA)
组织实施“测量和分析” 组织实施“测量和分析”过程域的目标是开发和维持度量能 力,以便支持对管理信息的需要 使度量目标和度量行为与项目的信息需要和目标相一致 包括: 包括:根据信息需要和度量目的建立度量目标并予以维 护 确定可度量概念, 确定可度量概念,选择可应用的度量 说明如何采集并存储度量数据 规定如何对度量数据进行分析和报告, 规定如何对度量数据进行分析和报告,并且安排优先顺 序。
配置管理过程域(续)
跟踪并控制被置于配置管理之下的工作产品
跟踪对配置项的变更请求 控制对配置项内容的变更
建立并维护基线的完整性。 建立并维护基线的完整性。
建立并维护描述配置项的记录 进行配置审计, 进行配置审计,以便维护配置基线的完整性
谢谢!
相关文档
最新文档