CMMI l2基础知识

一：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）是同属于某个领域而彼此相关的实践集合，当这些实践共同执行时，可以达到该领域过程改进的目标。

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标准体系详解序：一个处于“无序化”生产的软件公司，要进行过程改进，首要是改进什么呢？做任何事情都需要计划，做软件开发这样复杂的工作更加需要计划，所以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简介及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 (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)配置管理是管理项目的配置项（包括软件、硬件和文档等）的过程。

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

练习（过程的定义）１．项目情况：项目接到一个任务，负责实现一个模块，该模块主要实现将产品A输出进行加工转换成用户要求的格式。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.中文大意是：根据计划，跟踪项目的实际性能和过程。

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 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 用于初期估计。