导图社区 信息系统项目管理师（第3版）二、范围管理
- 95
- 10
- 2
- 举报
信息系统项目管理师（第3版）二、范围管理
主要学习项目范围管理知识，主要涉及项目范围管理的六个过程：规划范围管理、收集需求、定义范围、创建工作分解结构、确认范围、控制范围等内容。
编辑于2020-09-18 04:47:00
- 相似推荐
- 大纲
信息系统管理师(PMBOK)

二、范围管理
项目范围管理是为了达到项目目标，交付具有某种特质的产品和服务项目所规定要做的工作。 项目范围管理工作内容： 1.明确项目边界，那些该做，哪些不该做 2.对项目执行工作进行监控，该做的都做了，没有多做也没少做 3.防止项目范围发生蔓延 范围管理领域输入、输出、工具和技术表如表 5-1 所示。 
范围管理概述
1.项目范围管理就是要做范围内的事，而且只做范围内的事，既不少做也不多做。 项目范围管理需要做以下三个方面的工作： ①明确项目边界； ②对项目执行工作进行监控； ③防止项目范围发生蔓延。
2.产品范围是指产品或者服务所应包含的功能，项目范围是指为了能够交付产品，项目所必须做的工作。 产品范围是项目范围的基础，产品范围的定义是产品要求的描述； 而项目范围的定义是产生项目管理计划的基础。 判断项目范围是否完成，要以范围基准来衡量； 而产品范围是否完成，则根据产品是否满足了产品描述来判断。 产品范围描述是项目范围说明书的重要组成部分，因此，产品范围变更后，首先受到影响的是项目的范围。
3.项目的范围基准是经过批准的项目范围说明书、WBS 和 WBS 词典。
7、规划范围管理
创建范围管理计划，书面描述将如何定义、确认和控制 项目范围的过程
1.规划范围管理是编制范围管理计划，书面描述将如何定义、确认和控制项目范围的过程，其主要作用是在整个项目中对如何管理范围提供指南和方向。
2.范围管理计划是制定项目管理计划过程和其他范围管理过程的主要输入，包括如下内容：
（1） 如何制定项目范围说明书。
（2） 如何根据范围说明书创建 WBS。
（3） 如何维护和批准 WBS。
（4）如何确认和正式验收已完成的项目可交付成果。
（5）如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相联。 项目范围管理计划可能在项目管理计划之中，也可能作为单独的一项。 根据不同的项目，可以是详细的或者概括的，可以是正式的或者非正式的。
3.需求管理贯穿于整个过程，其最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线。 另外，还要建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全控制其影响范围，始终保持产品与需求的一致性。
4.需求管理计划描述在整个项目生命周期内如何分析、记录和管理需求。 主要包括以下内容：
（1）如何规划、跟踪和汇报各种需求活动。
（2） 需求管理需要使用的资源。
（3） 培训计划。
（4）项目干系人参与需求管理的策略。
（5）判断项目范围与需求不一致的准则和纠正规程。
（6）需求跟踪结构，即哪些需求属性将列入跟踪矩阵，并可在其他哪些项目文件中追踪到这些需求。
（7）配置管理活动。
输入、输出、工具
输入
1.项目章程
2.项目管理计划
3.事业环境因素
4.组织过程资产
工具与技术
1.专家判断 （１）
基于某应用领域、知识领域、学科和行业等的专业知识而做出的，关于当前活动的合理判断。这些专业知识可来自具有专业学历、知识、技能、经验或培训经历的任何小组或个人 (也叫德尔菲法) (1)贯穿项目始终 (2)质量管理3过程没有
2.引导技术（２）
（头脑风暴、冲突处理、问题解决、会议管理等）。 头脑风暴、冲突处理、问题解决和会议管理等，都是引导者可以用来帮助团队和个人完成项目活动的关键技术； 有一个引导者
输出
1.范围管理计划
范围管理计划要对下列工作的管理过程做出规定： 1.如何制定项目范围说明书 2.如何根据范围说明书创建WBS 3.如何维护和批准WBS 4.如何确认和正式验收已完成的项目可交付成果 5.如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相连
2.需求管理计划
需求管理计划的内容 1.如何规划、跟踪和汇报各种需求活动 2.需求管理需要使用的资源 3.培训计划 4.项目干系人参与需求管理的策略 5.判断项目范围与需求不一致的准则和纠正程序
8、收集需求
为实现项目目标而确定、记录并管理干系人的需要和需求的过程
1.收集需求是为实现项目目标而确定、记录并管理干系人的需要和需求的过程，其作用是为定义和管理项目范围（包括产品范围）奠定基础。
2. 需求的分类。
（1）业务需求： 整个组织的高层级需要，如解决业务问题或抓住业务机会，以及实施项目的原因。
（2）干系人需求： 是指干系人或干系人群体的需要。
（3）解决方案需求： 是为满足业务需求和干系人需求，产品、服务或成果必须具备的特性、功能和特征。 解决方案需求又进一步分为功能需求和非功能需求。 功能需求是关于产品能开展的行为，如流程、数据以及与产品的互动等。 非功能需求是对功能需求的补充，是产品正常运行所需的环境条件或质量，如可靠性、安全性、性能、服务水平等。
（4）过渡需求： 从当前状态过渡到将来状态所需的临时能力，如数据转换和培训需求。
（5）项目需求： 项目需要满足的行动、过程或其他条件。
（6）质量需求： 用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准。 QFD对质量需求进行了细分，分为基本需求、期望需求和意外需求。
3.收集需求的工具与技术主要有访谈、焦点小组、引导式研讨会、群体创新技术、多标准决策分析、群体决策技术、问卷调查、观察、原型法、标杆对照、系统交互图、文件分析等。
（1）访谈： 通过与干系人直接交谈来获取信息的正式或非正式的方法，是最基本的一种收集需求的手段。
（2）焦点小组： 将预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度。 由一位受过训练的主持人引导大家进行互动式讨论。 焦点小组往往比一对一的访谈更加热烈。 焦点小组是一种群体访谈而非一对一访谈，可以有6〜10个被访谈者参加。| 针对访谈者提出的问题，被访谈者之间开展互动式讨论，以求得到更有价值的意见。
（3）引导式研讨会： 邀请主要的跨职能干系人一起参加会议。 引导式研讨会对产品需求进行集中讨论与定义。 研讨会是快速定义跨职能需求和协调干系人差异的重要技术。 由于群体互动的特点，被有效引导的研讨会有助于建立信任、促进关系、改善沟通，从而有利于参加者达成一致意见。 该技术的另一个好处是，能够比单项会议更快地发现和解决问题。
（4）群体创新技术： 是指可以组织一些群体活动来识别项目和产品需求，包括头脑风暴法、名义小组技术、德尔菲技术、概念/思维导图、亲和图和多标准决策分析等。
1) 头脑风暴法：各抒己见。
2)名义小组技术： 通过投票来选出最有用的创意，以便进行进一步的头脑风暴或优先排序。 名义小组技术是头脑风暴法的深化应用，是更加结构化的头脑风暴法。
3)德尔菲技术： 经过多次综合各专家的观点，最终形成一个各专家都认可的方案。 可以防止个人的观点被不正确地放大。
4)概念/思维导图： 是用一张简单的图将从头脑风暴中获得的创意联系起来，以反映这些创意之间的共性与差异，从而引导出新的创意。
5) 亲和图： 又称为KJ法，是针对某一问题，充分收集各种经验、知识、想法和意见等语言、文字资料，通过图解方式进行汇总，并按其相互亲和性归纳整理这些资料，使问题明确起来，求得统一认识，以利于解决的一种方法。 亲和图的核心是头脑风暴法，是根据结果去找原因。
6)多标准决策分析： 是借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术。
（5）群体决策技术： 是为达成某种期望结果而对多个未来行动方案进行评估。 群体决策技术可用来开发产品需求，以及对产品需求进行归类和优先排序。
（6）问卷调查： 是指通过设计书面问题，向为数众多的受访者快速收集信息。
（7）观察： 直接观察个人在各自的环境中如何开展工作和实施流程。
（8）原型法： 是一种根据干系人初步需求，利用产品开发工具，快速建立一个产品模型展示给干系人，在此基础上与干系人交流，最终实现干系人需求的产品快速幵发的方法。
（9）标杆对照： 将实际或计划的做法与其他类似组织的做法（如流程、操作过程等）进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对照所采用的“类似组织”可以是内部组织，也可以是外部组织。
（10）系统交互图： 是对产品范围的可视化描述，显示系统（过程、设备、信息系统等）与参与者（用户、独立于本系统之外的其他系统）之间的交互方式。 系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者。
（11）文件分析： 就是通过分析现有文档，识别与需求相关的信息来挖掘需求。 可供分析的文档很多，包括商业计划、营销文档、协议、招投标文件、建议邀请书、业务流程、逻辑数据模型、业务规则库、应用软件文档、用例文档、其他需求文档、问题日志、政策、程序和法规文件等。
4.收集需求过程的主要输出有需求文件和需求跟踪矩阵。 需求文件描述各种单一的需求将如何满足与项目相关的业务需求。
5.需求文件的内容包括（但不限于）： ①业务需求；②干系人需求；③解决方案需求；④项目需求；⑤过渡需求；⑥与需求有关的假设条件、依赖关系和制约因素。
6.需求管理包括在产品开发过程中维持需求一致性和精确性的所有活动，包括控制需求基线，保持项目计划与需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪基线中需求的状态。
7.可跟踪性是项目需求的一个重要特征，需求跟踪是将单个需求和其他元素之间的依赖关系和逻辑联系建立跟踪，这些元素包括各种类型的需求、业务规则、系统组件及帮助文件等。可验证性是需求的最基本特性。
8.每个配置项的需求到其涉及的产品（或构件）需求都要具有双向可跟踪性。 所谓双向跟踪，包括正向跟踪和反向跟踪，正向跟踪是指检查需求文件中的每个需求是否都能在后继工作产品（成果）中找到对应点； 反向跟踪也称为逆向跟踪，是指检查设计文档、产品构件、测试文档等工作成果是否都能在需求文件中找到出处。 具体来说，需求跟踪涉及五种类型，如图 5-2 所示。

9.箭头表示需求跟踪能力联系链，它能跟踪需求使用的整个周期，即从需求建议到交付的全过程。
10.从用户原始需求可向前追溯到需求文件，这样就能区分出项目过程中或项目结束后由于变更受到影响的需求，也确保了需求文件中包括所有用户需求。 同样，可以从需求文件回溯到相应的用户原始需求，确认每个需求的出处。
11.由于在项目实施过程中，产品需求转变为设计和测试等实现元素，所以通过定义单个需求和特定的产品元素之间的联系链，可以从需求文件追溯到产品元素。 这种联系链使项目团队成员知道每个需求对应的产品元素，从而确保产品元素满足每个需求。 第四类联系链是从产品元素回溯到需求文件，使项目团队成员知道每个产品元素存在的原因。 如果不能将设计元素或测试案例回溯到一个需求文件，就可能出现镀金行为。 当然，如果某个孤立的产品元素表明了一个正当的功能，则说明需求文件漏掉了一项需求。
12.第五类联系链是需求文件之间的跟踪，这种跟踪便于更好地处理各种需求之间的逻辑相关性，检查需求分解中可能出现的错误或遗漏。
13.表示需求和其他产品元素之间的联系链的最普遍方式是使用需求跟踪（能力）矩阵，需求跟踪矩阵是将产品需求从其来源连接到能满足需求的可交付成果的一种表格，如表 5-2 所示。

14.应在需求跟踪矩阵中记录每个需求的相关属性，这些属性有助于明确每个需求的关键信息。 需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（如进行中、已取消、已推迟、新增加、已批准、已分配、已完成等）和状态日期。 另外，为了确保干系人满意，可能需要增加一些补充属性，如稳定性、复杂性、验收标准等。
输入、输出、工具
输入
1.项目章程
2.范围管理计划
范围管理计划要对下列工作的管理过程做出规定： 1.如何制定项目范围说明书 2.如何根据范围说明书创建WBS 3.如何维护和批准WBS 4.如何确认和正式验收已完成的项目可交付成果 5.如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相连
3.需求管理计划
需求管理计划的内容 1.如何规划、跟踪和汇报各种需求活动 2.需求管理需要使用的资源 3.培训计划 4.项目干系人参与需求管理的策略 5.判断项目范围与需求不一致的准则和纠正程序
4.干系人管理计划
5.干系人登记册
工具与技术
1.访谈（5）
通过与干系人直接交谈，来获取信息的正式或非正式方法
2.焦点小组（６）
召集预定的干系人和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度的一种启发式技术
3.引导式研讨会（７）
把主要的跨职能干系人召集在一起，通过集中讨论来定义产品需求的一种启发式技术(JAD和QFD) 跨职能
4.群体创新技术（头脑风暴、思维导图、亲和图、多标准决策分析）（８）
用于在干系人群体中激发创意的技术，包括：头脑风暴法、名义小组技术(排序)、概念/思维导图(关联)、亲和图(同类)、多标准决策分析
5.群体决策技术（一致同意（德尔菲）、大多数、相对多数、独裁）（９）
对多个备选方案进行评估的技术，用于生成产品需求并进行分类和优先级排序
6.问卷调查（１０）
设计一系列书面问题，向众多受访者快收集信息
7.观察（１１）
直接观看个人在各自的环境中如何执行工作（或任务）和实施流程的一种技术
8.原型法（１２）
在实际制造预期产品之前，先造出其实用模型，并据此征求对需求的早期反馈的一种方法 渐近明细
9.标杆对照（１３）
将实际或计划的实践（如流程和操作过程）与其他可比组织的实践进行对照，以便识别最佳实践、形成改进意见，并为绩效考核提供依据
10.系统交互图（１４）
对产品范围的可视化描绘，显示业务系统（过程、设备、计算机系统等）及其与人和其他系统（行动者）之间的交互方式。
11.文件分析（１５）
通过分析现有文档，识别与需求相关的信息的一种启发式技术
输出
1.需求文件（业务/干系人/解决方案/项目）
2.需求跟踪矩阵
1）业务需求、机会目的和目标 2）项目目标 3）范围描述/WBS可交付成果 4）产品设计 5）产品开发 6）测试策略和测试场景 7）高层级需求到详细需求
9、定义范围
制定项目和产品详细描述
1.定义范围是制定项目和产品详细描述的过程，其主要作用是明确所收集的需求中哪些包含在项目范围内，哪些排除在项目范围外，从而明确产品、服务或成果的边界。 由于在收集需求的过程中识别出的所有需求未必都包含在项目中，所以定义范围过程就要从需求文件中选取最终的项目需要，然后制定出关于项目及其产品、服务或成果的详细描述。
2.产品分析是一种有效的工具。 通常针对产品提问并回答，形成对将要开发的产品的用途、特征和其他方面的描述。
3.备选方案生成是一种用来指定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法。
4.作为定义范围过程的主要成果，项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。 项目范围说明书记录了整个范围，包括项目范围和产品范围，详细描述项目的可交付成果，以及为提交这些可交付成果而必须开展的工作。
5. 项目范围说明书包括如下内容：
（1）产品范围描述。
（2）验收标准。 定义可交付成果通过验收前必须满足的一系列条件，以及验收的过程。
（3）可交付成果。
（4）项目的除外责任。 通常需要识别出什么是被排除在项目之外的。 明确说明哪些内容不属于项目范围，有助于管理干系人的期望。
（5）制约因素。 列出并说明与项目范围有关且限制项目团队选择的具体项目制约因素。
（6）假设条件。
6. 项目范围说明书的主要作用： ①确定范围；②沟通基础；③规划和控制依据；④变更基础；⑤规划基础。
输入、输出、工具
输入
1.项目章程
2.范围管理计划
3.需求文件
4.组织过程资产
工具与技术
1.专家判断（１）
基于某应用领域、知识领域、学科和行业等的专业知识而做出的，关于当前活动的合理判断。这些专业知识可来自具有专业学历、知识、技能、经验或培训经历的任何小组或个人 (也叫德尔菲法) (1)贯穿项目始终 (2)质量管理3过程没有
2.产品分析（１６）
针对产品提问并回答，形成对将要生产的产品的用途、特征和其他方面的描述(包括:产品分解、系统分析、需求分析、系统工程、价值工程和价值分析)
3.备选方案生成（１７）
一种用来制定尽可能多的可选方案的技术，目的在于识别执行项目工作的不同方法。(包括:头脑风暴、横向思维、备选方案分析)
4.引导式研讨会（７）
把主要的跨职能干系人召集在一起，通过集中讨论来定义产品需求的一种启发式技术(JAD和QFD) 跨职能
输出
1.项目范围说明书
项目范围说明书的内容 1.产品范围描述 2.验收标准 3.可交付成果 4.项目的除外责任（排除在项目之外的） 5.制约因素 6.假设条件 项目范围说明书的作用 1.确定范围 2.沟通基础 3.规划和控制依据 4.变更基础 5.规划基础
2.项目文件更新(干系人登记册、需求文件、需求跟踪矩阵)
10、创建WBS
把项目可交付成果和项目工作分解成较小的、更易于管 理的组成部分的过程 WBS内容：1.里程碑 2.工作包 3.控制账户 4.规划包 5.WBS词典 WBS工具： 1.分解： 1）分解的原则：功能或者技术原则、组织结构、系统或者子系统 1.项目生命周期的各阶段作为分解的第二层，产品和可交付成果在第三层 2.主要可交付成果作为第二层 3.整合可能由项目外部组织来实施的各种组件作为外包工作的一部分，卖方需指定想要的合同WBS 2）工作过程：编制高层工作—分配管理员职责-分解工作分解结构-分配指着-编写项目范围说明书-审批工作分解结构-批准的工作分解结构 3）注意事项： 1.WBS必须面向可交付成果 2.WBS必须符合项目范围 3.WBS底层支持计划和控制 4.WBS有且只能有一个人负责WBS的元素 5.WBS的指导而不是原则，控制在4-6层，超过6层应分解为子项目 6.WBS应包括项目管理工作 7.WBS编制需要所有干系人的参与 8.WBS并非一成不变 WBS的作用： 1）明确说明项目范围 2）清晰定义项目边界 3）为各自独立单元分派人员 4）针对独立单元进行进度、成本和资源需求的估算 5）为计划、预算、进度安排和费用控制奠定共同基础 6）将项目工作和财物账目联系起来 7）确定工作内容和工作顺序 8）有助于防止范围蔓延 WBS词典的内容：账户编码标识、工作描述、假设条件和制约因素、负责人或组织单元、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等
1.创建WBS是将项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程，其主要作用是对所要交付的内容提供一个结构化的视图。
2.里程碑标志着某个可交付成果或者阶段的正式完成。 重要的检查点是里程碑、重要的里程碑是基线。
3.工作包是位于WBS每条分支最底层的可交付成果或项目工作组成部分，工作包应该非常具体，以便承担者能明确自己的任务、努力的目标和承担的责任。 工作包的大小需要遵循 8/80 原则。
4．控制账户是一种管理控制点，是 WBS某个层次上的要素，既可以是工作包，也可以是比工作包更高层次的一个要素。 如果是后一种情况，一个控制账户中就包括若干个工作包，但一个工 作包仅属于一个控制账户。 项目管理团队在控制账户上考核项目的执行情况，即在控制账户的相应要素下，将项目执行情况与计划情况进行比较，以便评价执行情况好坏，并发现与纠正偏差。
5.规划包是指在控制账户之下，工作内容已知但尚缺详细进度活动的 WBS 组成部分。 是在控制账户之下、工作包之上的WBS要素，是暂时用来做计划的。 随着情况的逐渐清晰，规划包最终将被分解成工作包及相应的具体活动。
6.WBS词典，在制作WBS的过程中，要给WBS的每个部分赋予一个账户编码标识符，它们是成本、进度和资源使用信息汇总的层次结构。 需要生成一些配套的文件，这些文件需要和WBS配套使用，称为WBS词典。 WBS词典也称为WBS词汇表，它是描述 WBS 各组成部分的文件。
7．创建WBS过程的工具与技术主要有分解和专家判断，要将整个项目工作分解为工作包，通常需要开展以下活动：
（1）识别和分析可交付成果及相关工作。
（2）确定 WBS的结构和编排方法。
（3）自上而下逐层细化分解。
（4）为WBS组件制定和分配标识编码。
（5）核实可交付成果分解的程度是恰当的。
8. 分解的原则。
（1） 功能或者技术原则。 在创建WBS时，需要考虑将不同人员的工作分开。
（2） 组织结构。 对于职能型的项目组织而言，WBS也要适应项目的组织结构形式。
（3）系统或者子系统。 总的系统划分为几个主要的子系统，然后对每个子系统再进行分解。
9.在进行WBS分解时，可以有如下三种方式：
（1）将项目生命周期的各阶段作为分解的第二层。
（2）主要可交付成果作为分解的第二层。
（3） 子项目作为分解的第二层。
10.WBS不是某个项目团队成员的责任，应该由全体项目团队成员、用户和项目干系人共同完成和一致确认。
11.较常用的WBS表示形式主要有分级的树型结构（组织结构图式）和表格形式（列表式）。 树型结构图的WBS层次清晰，直观性和结构性强，但不容易修改，对大型复杂项目很难表示出项目的全貌，适用于中小型项目； 表格形式的直观性比较差，但能够反映出项目的所有工作要素，适用于大型项目。
12.在分解的过程中，应该注意以下八个方面。
（1）WBS必须是面向可交付成果的。 项目的目标是提供产品或服务，仅仅是一连串特别的活动。
（2） WBS 必须符合项目的范围。 WBS必须包括也仅包括为了完成项目的可交付成果的活动。
（3）WBS的底层应该支持计划和控制。 WBS是项目管理计划和项目范围之间的桥梁，WBS的底层不但要支持项目管理计划，还要让管理层能够监视和控制项目的进度和预算。
（4）WBS中的元素必须有人负责，而且只由一个人负责，尽管实际上可能需要多人参与。
（5） WBS的指导。 作为指导而不是原则，WBS应控制在4〜6层。 当然，大项目可以超过6 层。
（6）WBS应包括项目管理工作，也要包括分包出去的工作。
（7）WBS的编制需要所有（主要）项目干系人的参与，需要项目团队成员的参与。
（8）WBS并非是一成不变的，完成了 WBS 工作后，仍然有可能需要对WBS 进行修改。
13.当一个项目的WBS分解完成后，项目干系人对完成的WBS应该给予确认，并对此达成共识。 WBS的目的和用途主要体现在以下八个方面。
（1）明确和准确说明项目范围，项目团队成员能够清楚地理解任务的性质和需要努力的方向。
（2）清楚地定义项目的边界。
（3）为各独立单元分派人员，规定这些人员的职责，可以确定完成项目所需的技术和人力资源。
（4）针对独立单元，进行时间、成本和资源需求量的估算，提高估算的准确性。
（5）为计划、预算、进度安排和费用控制奠定共同基础，确定项目进度和控制的基准。
（6）将项目工作和项目的财务账目联系起来。
（7）确定工作内容和工作顺序，将项目分解成具体的工作任务，就可以按照工作任务的逻辑顺序来实施项目。 WBS可以使用图形化的方式来查看工作内容，任何人都能够清楚地辨别项目的阶段、工作单元，并根据实际情况进行调节和控制。
（8） 有助于防止需求蔓延。
输入、输出、工具
输入
1.范围管理计划
范围管理计划要对下列工作的管理过程做出规定： 1.如何制定项目范围说明书 2.如何根据范围说明书创建WBS 3.如何维护和批准WBS 4.如何确认和正式验收已完成的项目可交付成果 5.如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相连
2.项目范围说明书
项目范围说明书的内容 1.产品范围描述 2.验收标准 3.可交付成果 4.项目的除外责任（排除在项目之外的） 5.制约因素 6.假设条件 项目范围说明书的作用 1.确定范围 2.沟通基础 3.规划和控制依据 4.变更基础 5.规划基础
3.需求文件
4.事业环境因素
5.组织过程资产
工具与技术
1.分解（１８）
把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。
２.专家判断（１）
基于某应用领域、知识领域、学科和行业等的专业知识而做出的，关于当前活动的合理判断。这些专业知识可来自具有专业学历、知识、技能、经验或培训经历的任何小组或个人 (也叫德尔菲法) (1)贯穿项目始终 (2)质量管理3过程没有
输出
1.范围基准（经过审批的范围说明书、工作分解结构WBS和相应的WBS词典）
WBS内容：1.里程碑 2.工作包 3.控制账户 4.规划包 5.WBS词典 WBS工具： 1.分解： 1）分解的原则：功能或者技术原则、组织结构、系统或者子系统 1.项目生命周期的各阶段作为分解的第二层，产品和可交付成果在第三层 2.主要可交付成果作为第二层 3.整合可能由项目外部组织来实施的各种组件作为外包工作的一部分，卖方需指定想要的合同WBS 2）工作过程：编制高层工作—分配管理员职责-分解工作分解结构-分配指着-编写项目范围说明书-审批工作分解结构-批准的工作分解结构 3）注意事项： 1.WBS必须面向可交付成果 2.WBS必须符合项目范围 3.WBS底层支持计划和控制 4.WBS有且只能有一个人负责WBS的元素 5.WBS的指导而不是原则，控制在4-6层，超过6层应分解为子项目 6.WBS应包括项目管理工作 7.WBS编制需要所有干系人的参与 8.WBS并非一成不变 WBS的作用： 1）明确说明项目范围 2）清晰定义项目边界 3）为各自独立单元分派人员 4）针对独立单元进行进度、成本和资源需求的估算 5）为计划、预算、进度安排和费用控制奠定共同基础 6）将项目工作和财物账目联系起来 7）确定工作内容和工作顺序 8）有助于防止范围蔓延 WBS词典的内容：账户编码标识、工作描述、假设条件和制约因素、负责人或组织单元、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等
2.项目文件更新（需求文件）
11、确认范围
正式验收项目己完成的可交付成果的过程
1.确认范围是正式验收项目已完成的可交付成果的过程，其主要作用是使验收过程具有客观性，同时，通过验收每个可交付成果，提高最终产品、服务或成果获得验收的可能性。 确认范围包括与客户或发起人一起审查可交付成果，确保可交付成果已圆满完成，并获得客户或发起人的正式验收。
2.确认范围的主要工具与技术是检查和群体决策技术。 检査也称为审查、评审、审计、走查、巡检、测试等。
3.确认范围应该贯穿项目的始终，一般步骤如下：
（1）确定需要进行范围确认的时间。
（2）识别范围确认需要哪些投入。
（3）确定范围正式被接受的标准和要素。
（4）确定范围确认会议的组织步骤。
（5） 组织范围确认会议。
通常情况下，在确认范围前，项目团队需要先进行质量控制工作。 例如，在确认软件项目的范围之前，需要进行系统测试等工作，以确保确认工作的顺利完成。
4.项目干系人进行范围确认时，一般需要检查以下六个方面的问题：
（1）可交付成果是否是确定的、可确认的。
（2）每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件。
（3）是否有明确的质量标准。
（4）审核和承诺是否有清晰的表达。
（5）项目范围是否覆盖了需要完成的产品或服务进行的所有活动，有没有遗漏或者错误。
（6）项目范围的风险是否太高，管理层是否能够降低可预见的风险发生时对项目的冲击。
5.确认范围与核实产品： 核实产品是针对产品是否完成，在项目（或阶段）结束时由发起人或客户来验证，强调产品是否完整； 确认范围是针对项目可交付成果，由客户或发起人在阶段末确认验收的过程。
6. 确认范围与质量控制的不同之处。
（1）确认范围主要强调可交付成果获得客户或发起人的接受； 质量控制强调可交付成果的正确性，并符合为其制定的具体质量要求（质量标准）。
（2）质量控制一般在确认范围前进行，也可同时进行； 确认范围一般在阶段末尾进行，而质量控制并不一定在阶段末进行。
（3）质量控制属内部检查，由执行组织的相应质量部门实施； 确认范围则是由外部干系人（客户或发起人）对项目可交付成果进行检查验收。
7. 确认范围与项目收尾的不同之处。
（1）虽然确认范围与项目收尾工作都在阶段末进行，但确认范围强调的是核实与接受可交付成果，而项目收尾强调的是结束项目（或阶段）所要做的流程性工作。
（2）确认范围与项目收尾都有验收工作，确认范围强调验收项目可交付成果，项目收尾强调验收产品。
输入、输出、工具
输入
1.项目管理计划
2.需求文件
3.需求跟踪矩阵
4.工作绩效数据
5.确认的可交付成果
工具与技术
1.检查（102）（审查、产品评审、审计、走查、巡查）
检查工作产品，以确定它是否符合书面标准
２.群体决策技术（一致同意（德尔菲）、大多数、相对多数、独裁）（９）
对多个备选方案进行评估的技术，用于生成产品需求并进行分类和优先级排序
输出
1.变更请求
2.工作绩效信息
3.验收的可交付成果
4.项目文件更新
12、控制范围
监督项目和产品的范围状态、管理范围基准变更的过程
1.控制范围是监督项目和产品的范围状态、管理范围基准变更的过程，其主要作用是在整个项目期间保持对范围基准的维护。
2. 范围变更的原因。
（1）政府政策的问题。
（2）项目范围的计划编制不周密详细，有一定的错误或遗漏。
（3）市场上出现了或是设计人员提出了新技术、新手段或新方案。
（4）项目执行组织本身发生变化。
（5）客户对项目、项目产品或服务的要求发生变化。
3. 范围变更控制的主要工作。
（1）影响导致范围变更的因素，并尽量使这些因素向有利的方面发展。
（2）判断范围变更是否已经发生。
（3）范围变更发生时管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理。
输入、输出、工具
输入
1.项目管理计划
2.需求文件
3.需求跟踪矩阵
4.工作绩效数据
5.组织过程资产
工具与技术
1.偏差分析（１０３）
确定实际绩效与基准的差异程度及原因的一种技术
输出
1.变更请求
2.工作绩效信息
3.项目文件更新
4.项目管理计划更新（范围基准更新、其他基准）
5.组织过程资产更新（造成偏差的原因，所选的措施和理由，得到的经验教训）
一.整体管理
6过程: 章 计 指，监 变更 收尾 整体管理的基本任务：为了按照实施组织确定的程序实现项目目标，将项目管理过程组中需要的各个过程有效形成整体。 项目整合管理包括为识别、定义、组合、统一和协调各项目管理过程组的各个过程和活动而开展的过程与活动。 三个不同层面发生的整合：过程层面、认知层面和背景层面。 项目整合管理包括进行以下选择： 资源分配； 平衡竞争性需求； 研究各种备选方法； 为实现项目目标而裁剪过程； 管理各个项目管理知识领域之间的依赖关系。 项目章程的内容： 1.项目目的或批准项目的原因 2.可测量的项目目标和相关的成功标准 3.项目的总体要求 4.概括性的项目描述 5.项目的主要风险 6.总体里程碑进度计划 7.总体预算 8.项目审批要求（用什么标准评价项目成功，由谁对项目成功下结论，由谁来签署项目结束） 9.委派的项目经理及其职责和职权 10.发起人或其他批准项目章程的人员的姓名和职权 项目管理计划的内容(各管理过程的计划)： 1.项目名称 2.项目背景 3.项目范围管理计划，范围基准 4.项目进度管理计划，进度基准 5.项目成本管理计划，成本基准 6.项目质量管理计划 7.项目人力资源计划 8.项目沟通计划 9.项目风险计划，风险等级册 1）技术风险 2）经营风险 3）管理风险 4）市场风险 10.项目采购计划 事业环境因素： 是指围绕项目或能影响项目成败的任何内外部环境因素。这些因素来自任何或所有项目参与单位。事业环境因素可能提高或限制项目管理的灵活性，并可能对项目结果产生积极或消极影响。它们是大多数规划过程的输入。 事业环境因素包括但不限于： 1.组织文化、结构和流程 2.政府或行业标准 3.基础设施 4.现有人力资源状况 5.人事管理制度 6.公司的工作授权系统 7.市场条件 8.干系人风险承受力 9.政治氛围 10.组织已有的沟通渠道 11.商业数据库 12.项目管理信息系统    整体管理领域输入、输出、工具和技术表如表 4-1 所示。 
计算题
信息系统项目管理师教程（第3版）
第1章 信息化和信息系统
第2章 信息系统项目管理基础 145
第3章 项目立项管理 179
第4章 项目整体管理 209
4.1 项目整体管理概述 209
4.2 制定项目章程 210
4.2.1 制定项目章程过程 211
4.2.2 制定项目章程的依据 212
4.2.3 专家判断 215
4.2.4 项目选择方法 215
4.2.5 项目启动会议 218
4.2.6 项目目标 219
4.2.7 引导技术 221
4.3 制订项目管理计划 221
4.3.1 项目管理计划 221
4.3.2 制订项目管理计划过程 225
4.3.3 项目管理信息系统 226
4.4 指导与管理项目执行 227
4.4.1 指导与管理项目执行的依据 229
4.4.2 指导与管理项目执行的工具与技术 229
4.4.3 指导与管理项目执行的成果 230
4.5 监控项目工作 231
4.5.1 监控项目工作的依据 232
4.5.2 监控项目工作的工具与技术 233
4.5.3 实施项目工作的成果 233
4.6 实施整体变更控制 234
4.6.1 整体变更控制的依据 235
4.6.2 整体变更控制的工具与技术 236
4.6.3 整体变更控制的成果 236
4.7 结束项目或阶段 237
4.7.1 结束项目或阶段的依据 237
4.7.2 结束项目或阶段的工具与技术 238
4.7.3 结束项目或阶段的输出 238
4.8 本章练习 239
第5章 项目范围管理 242
5.1 范围管理概述 242
5.1.1 产品范围与项目范围 242
5.1.2 范围管理的重要性 243
5.1.3 范围管理的过程 243
5.2 规划范围管理 245
5.2.1 范围管理计划 245
5.2.2 需求管理计划 246
5.3 收集需求 247
5.3.1 需求的分类 247
5.3.2 收集需求的工具与技术 248
5.3.3 需求文件 253
5.3.4 需求跟踪 254
5.4 定义范围 256
5.4.1 定义范围的工具与技术 257
5.4.2 项目范围说明书 258
5.5 创建工作分解结构（WBS） 259
5.5.1 WBS的层次 259
5.5.2 分解 261
5.5.3 WBS的作用 265
5.6 确认范围 265
5.6.1 确认范围概述 266
5.6.2 干系人关注点 266
5.6.3 几个术语的比较 267
5.7 控制范围 268
5.8 本章练习 269
第6章 项目进度管理 273
6.1 概述 273
6.1.1 项目进度管理含义 273
6.1.2 项目进度管理的作用 273
6.2 项目进度管理过程 274
6.2.1 规划进度管理 274
6.2.2 定义活动 276
6.2.3 排列活动顺序 277
6.2.4 估算活动资源 278
6.2.5 估算活动持续时间 280
6.2.6 制订进度计划 282
6.2.7 控制进度 289
6.3 项目进度管理的技术和工具 291
6.3.1 工作量和工期估计 291
6.3.2 项目活动排列顺序的技术和工具 294
6.3.3 制订项目进度计划的技术和工具 297
6.3.4 项目进度计划调整方法 305
6.4 案例例题 306
6.5 本章练习 308
第7章 项目成本管理 311
7.1 概述 311
7.1.1 项目成本概念及其构成 311
7.1.2 项目成本管理作用和意义 311
7.1.3 项目成本管理的重要性 311
7.1.4 项目成本失控原因 312
7.1.5 相关术语 313
7.2 项目成本管理过程 314
7.2.1 规划成本 315
7.2.2 估算成本 316
7.2.3 制订预算 320
7.2.4 控制成本 323
7.3 项目成本管理的技术和工具 325
7.3.1 成本分析技术 325
7.3.2 成本管理技术 327
7.4 本章练习 332
第8章 项目质量管理 334
8.1 质量管理基础 334
8.1.1 质量与项目质量 334
8.1.2 质量管理 335
8.1.3 质量管理标准体系 335
8.2 项目质量管理过程 338
8.2.1 规划质量管理 339
8.2.2 实施质量保证 341
8.2.3 控制质量 342
8.3 项目质量管理的技术和工具 344
8.3.1 规划阶段的技术 344
8.3.2 执行阶段的技术 346
8.4 案例例题 350
8.5 本章练习 351
第9章 项目人力资源管理 353
9.1 项目人力资源管理概念 353
9.1.1 项目团队 353
9.1.2 项目管理团队 353
9.1.3 领导和管理 354
9.1.4 冲突和竞争 354
9.2 项目人力资源管理过程 355
9.2.1 规划人力资源管理 355
9.2.2 组建项目团队 359
9.2.3 建设项目团队 362
9.2.4 管理项目团队 365
9.3 项目人力资源管理工具 368
9.3.1 虚拟团队 368
9.3.2 集中办公 368
9.3.3 团队发展阶段 369
9.3.4 人际关系技能 369
9.3.5 权力 370
9.3.6 冲突管理 371
9.3.7 激励理论 372
9.3.8 马斯洛需求层次理论 372
9.3.9 赫茨伯格双因素理论 374
9.3.10 X理论和Y理论 375
9.3.11 期望理论 376
9.4 项目人力资源管理文件 377
9.4.1 人力资源管理计划 377
9.4.2 角色和职责 377
9.4.3 项目组织图 379
9.4.4 人员配备管理计划 379
9.4.5 团队绩效评价 380
9.5 项目人力资源管理案例 381
9.5.1 典型案例一 381
9.5.2 典型案例二 382
9.6 本章练习 383
第10章 项目沟通管理和干系人管理 388
10.1 项目沟通管理基础 388
10.1.1 项目沟通管理的重要性 388
10.1.2 项目沟通管理相关理论 388
10.2 项目沟通管理过程 391
10.2.1 规划沟通管理 391
10.2.2 管理沟通 393
10.2.3 控制沟通 395
10.3 项目沟通管理的技术和工具 396
10.4 项目干系人管理基础 399
10.4.1 项目干系人的重要性 399
10.4.2 项目干系人管理的主要内容 399
10.4.3 项目干系人的管理依据 399
10.5 项目干系人管理过程 400
10.5.1 识别干系人 400
10.5.2 规划干系人管理 401
10.5.3 管理干系人 402
10.5.4 控制干系人参与 404
10.6 项目干系人管理的技术和工具 405
10.7 本单日练习 407
第11章 项目风险管理 409
11.1 项目风险管理概述 409
11.1.1 项目风险定义 409
11.1.2 风险的属性 410
11.1.3 风险的分类 411
11.1.4 风险成本及其负担 413
11.1.5 项目风险管理过程 414
11.1.6 项目风险管理在项目管理中的地位与作用 415
11.2 规划风险管理 416
11.2.1 规划风险管理的依据 417
11.2.2 规划风险管理的工具与技术 417
11.2.3 规划风险管理的成果 418
11.3 识别风险 420
11.3.1 风险识別的依据 421
11.3.2 风险识别的工具与技术 422
11.3.3 识别风险的成果 423
11.4 实施定性风险分析 424
11.4.1 实施定性风险分析的依据 424
11.4.2 实施定性风险分析的工具与技术 425
11.4.3 实施定性风险分析的成果 427
11.5 实施定量风险分析 428
11.5.1 实施定量风险分析的依据 429
11.5.2 实施定量风险分析的工具与技术 429
11.5.3 实施定量风险分析的成果 432
11.6 规划风险应对 433
11.6.1 规划风险应对的依据 433
11.6.2 规划风险应对的工具与技术 434
11.6.3 规划风险应对的成果 436
11.7 控制风险 437
11.7.1 控制风险的依据 437
11.7.2 控制风险的工具与技术 438
11.7.3 控制风险的成果 439
11.8 风险管理示例 440
11.9 本章练习 442
第12章 项目采购管理 444
12.1 概述 444
12.2 战略合作管理 444
12.2.1 供应商战略合作伙伴关系的概念 445
12.2.2 建立供应商战略合作伙伴关系的意义 445
12.2.3 供应商战略合作伙伴关系的构建 445
12.2.4 战略合作协议审批、签署 447
12.2.5 供应商战略合作伙伴关系的管理 447
12.2.6 合作伙伴关系评价 448
12.3 采购管理过程 448
12.3.1 规划采购 450
12.3.2 实施采购 455
12.3.3 控制采购 458
12.3.4 结束采购 462
12.4 采购管理技术和工具 463
12.4.1 采购管理方法和技术的应用 463
12.4.2 采购管理信息系统 468
12.4.3 招投标 468
12.5 案例例题 473
12.6 本章练习 474
第13章 项目合同管理 476
13.1 合同管理相关基础概念 476
13.1.1 合同的类型 476
13.1.2 合同的内容 481
13.2 合同管理过程 482
13.2.1 合同的签订管理 482
13.2.2 合同的履行管理 483
13.2.3 合同的变更管理 484
13.2.4 合同的档案管理 484
13.2.5 合同违约索赔管理 484
13.3 本章练习 487
第14章 信息文档管理与配置管理 490
14.1 信息系统项目文档及其管理 490
14.1.1 信息系统项目相关信息（文档） 490
14.1.2 信息系统项目文档管理的规划和方法 491
14.2 配置管理 492
14.2.1 配置管理的概念 492
14.2.2 配置管理的目标和方针 497
14.2.3 日常配置管理活动 498
14.3 文档管理、配置管理工具 502
14.3.1 工具综述 502
14.3.2 SVN 503
14.3.3 CC 503
14.3.4 GIT 504
14.4 本章练习 505
第15章 知识管理 507
15.1 知识和知识管理的概念 507
15.1.1 知识与知识管理 507
15.1.2 项目知识管理 509
15.2 知识管理常用的方法和工具 510
15.2.1 显性知识的管理 510
15.2.2 隐性知识的管理 511
15.2.3 知识管理的工具 513
15.2.4 学习型组织 513
15.3 知识产权保护 516
15.3.1 著作权法 516
15.3.2 计算机软件保护条例 518
15.3.3 商标法 519
15.3.4 专利法 520
15.3.5 不正当竞争法 521
15.3.6 项目管理中的知识产权问题 522
15.4 本章练习 523
第16章 项目变更管理 529
16.1 项目变更管理的基本概念 529
16.1.1 项目变更产生的原因 529
16.1.2 项目变更分类 530
16.1.3 项目变更的含义 530
16.2 项目变更管理原则 530
16.3 变更管理组织机构与工作程序 531
16.3.1 组织机构 531
16.3.2 工作程序 531
16.4 项目变更管理的工作内容 533
16.4.1 严格控制项目变更申请的提交 533
16.4.2 变更控制 533
16.4.3 变更管理与其他项目管理要素的关系 534
16.5 版本发布和回退计划 534
16.5.1 软件版本发布前的准备 534
16.5.2 版本发布应急回退方案 535
16.5.3 版本发布和回退实施过程总结 535
16.6 本章练习 535
第17章 战略管理 538
17.1 组织战略管理 538
17.1.1 战略与战略管理 538
17.1.2 组织战略的主要内容 539
17.1.3 战略实施过程分解 539
17.2 组织战略类型和层次 541
17.2.1 组织战略类型 541
17.2.2 组织战略层次 545
17.3 组织战略目标分解 546
17.3.1 组织战略目标分解概念 546
17.3.2 组织战略与项目管理 547
17.4 本章练习 549
第18章 组织级项目管理 551
18.1 组织级项目管理概述 551
18.2 组织级项目管理对组织战略的支持 551
18.3 组织级项目管理内容 552
18.4 组织级项目管理成熟度模型 553
18.5 本章练习 554
第19章 流程管理 556
19.1 流程管理基础 556
19.2 流程分析、设计、实施与评估 558
19.2.1 业务流程分析 558
19.2.2 业务流程设计 561
19.2.3 业务流程实施 565
19.2.4 业务流程评估 567
19.3 流程重构与改进 568
19.3.1 BPR概述 569
19.3.2 BPR的实施 570
19.3.3 基于BPR的信息系统规划 572
19.3.4 业务流程持续优化 573
19.4 项目管理流程的管理和优化 574
19.4.1 项目管理流程的优化 574
19.4.2 敏捷项目管理 576
19.5 本章练习 578
第20章 项目集管理 584
20.1 项目集管理概述 584
20.1.1 项目集管理标准 584
20.1.2 各种角色和职责界定 584
20.1.3 项目集管理 585
20.2 项目集管理过程 586
20.2.1 评估项目集与组织战略一致性 586
20.2.2 项目集愿景和计划 587
20.2.3 项目集路线图 587
20.3 项目集治理 588
20.3.1 项目集治理的主要内容 588
20.3.2 项目集指导委员会 589
20.3.3 项目集指导委员会职责 590
20.3.4 项目集筹资 590
20.3.5 建立项目集治理计划 590
20.3.6 批准项目集绩效方法与计划 591
20.3.7 项目集组件治理 592
20.3.8 支持项目集治理的其他活动 592
20.4 项目集生命周期管理 594
20.4.1 项目集生命周期划分 594
20.4.2 项目集定义阶段 594
20.4.3 项目集收益交付阶段 596
20.4.4 项目集收尾阶段 597
20.5 项目集管理过程域 597
20.5.1 项目集管理绩效域 597
20.5.2 项目集管理支持过程 598
20.6 本章练习 598
第21章 项目组合管理 601
21.1 项目组合管理概述 601
21.1.1 项目组合 601
21.1.2 项目组合、项目集和项目之间的关系 602
21.2 项目组合管理 603
21.2.1 项目组合管理与组织级项目管理关系 603
21.2.2 项目组合管理与组织战略 604
21.2.3 商业价值 605
21.3 项目组合组件 606
21.3.1 项目集管理 606
21.3.2 项目管理 607
21.3.3 日常运作管理 607
21.3.4 项目组合治理 607
21.4 项目组合管理过程实施 608
21.4.1 项目组合管理过程实施概述 608
21.4.2 评估项目组合管理过程的当前状态 608
21.4.3 定义项目组合管理的愿景和计划 609
21.4.4 实施项目组合管理过程 610
21.4.5 改进项目组合管理过程 610
21.4.6 项目组合管理生命周期 611
21.5 项目组合治理 611
21.6 项目组合管理过程组 612
21.6.1 项目组合管理过程组 612
21.6.2 定义过程组 613
21.6.3 调整过程组 613
21.6.4 授权与控制过程组 613
21.6.5 项目组合管理过程的相互作用 613
21.7 项目组合风险管理 614
21.7.1 制订项目组合风险管理计划 617
21.7.2 管理项目组合风险 622
21.8 本章练习 628
第22章 信息系统安全管理 631
22.1 信息系统安全策略 631
22.1.1 信息系统安全策略的概念与内容 631
22.1.2 建立安全策略需要处理好的关系 632
22.1.3 信息系统安全策略设计原则 635
22.1.4 信息系统安全方案 636
22.2 信息安全系统工程 637
22.2.1 信息安全系统工程概述 637
22.2.2 信息安全系统 639
22.2.3 信息安全系统架构体系 643
22.2.4 信息安全系统工程基 础 645
22.2.5 信息安全系统工程体系结 构 647
22.3 PKI公开密钥基础设施 655
22.3.1 公钥基础设施（PKI）基本概念 655
22.3.2 数字证书及其生命周期 660
22.3.3 信任模型 664
22.3.4 应用模式 668
22.4 PMI权限（授权）管理基础设施 670
22.4.1 PMI与PKI的区別 671
22.4.2 属性证书定义 672
22.4.3 访问控制 673
22.4.4 基于角色的访问控制 675
22.4.5 PMI支撑体系 676
22.4.6 PMI实施 680
22.5 信息安全审计 681
22.5.1 安全审计概念 681
22.5.2 建立安全审计系统 684
22.5.3 分布式审计系统 689
第23章 信息系统综合测试与管理 693
23.1 测试基础 693
23.1.1 软件测试模型 693
23.1.2 软件测试类型 701
23.2 软件测试技术 737
23.2.1 黑盒测试法 737
23.2.2 白盒测试法 762
23.3 信息系统测试管理 767
23.3.1 测试管理概述 767
23.3.2 测试管理内容 767
23.3.3 测试监控管理 768
23.3.4 配置管理 769
23.3.5 测试风险管理 769
23.3.6 测试人员绩效考核 770
23.4 本章练习 776
第24章 项目管理成熟度模型 780
24.1 项目管理成熟度模型概述 780
24.2 OPM3 781
24.2.1 组织级项目管理成熟度模型OPM3概述 781
24.2.2 OPM3基本概念 788
24.2.3 组织级项目管理成熟度模型（OPM3） 794
24.3 CMMI 811
24.3.1 关于过程改进 811
24.3.2 关于能力成熟度模型集成 812
24.3.3 CMMI过程域 814
24.3.4 CMMI表示法与级別 819
24.3.5 CMMI评估方法与过程改进 826
24.4 本章练习 828
第25章 量化的项目管理 831
25.1 量化的项目管理概述 831
25.2 量化的项目管理过程 832
25.2.1 准备量化管理 832
25.2.2 量化的管理项目 833
25.3 量化的项目管理过程指标 834
25.4 项目度量方法 838
25.5 量化的项目管理工具 843
25.6 本章练习 844
第26章 知识产权与标准规范 847
26.1 合同法 847
26.1.1 合同的订立 847
26.1.2 合同的效力 849
26.1.3 合同的履行 850
26.1.4 合同的变更和转让 852
26.1.5 合同的权利义务终止 852
26.1.6 违约责任 854
26.1.7 其他规定 855
26.2 招投标法 855
26.2.1 招标 855
26.2.2 投标 857
26.2.3 评标 858
26.2.4 法律责任 859
26.3 著 作权法 860
26.4 政府采购法 862
26.4.1 政府采购当事人 863
26.4.2 政府采购方式 864
26.4.3 政府采购程序 864
26.4.4 政府采购合同 866
26.4.5 质疑与投拆 867
26.4.6 法律责任 867
26.5 软件工程国家标准 869
26.5.1 标准化基础知识 869
26.5.2 基础标准 871
26.5.3 生存周期管理标准 874
26.5.4 文档化标准 875
26.5.5 质量与测试标准 878
26.6 本章练习 880
第27章 管理科学基础知识 884
27.1 数学建模基础知识 884
27.2 图论 886
27.2.1 最小生成树 886
27.2.2 最短路径 888
27.2.3 网络与最大流量 890
27.3 决策论 893
27.3.1 决策的分类与模型 893
27.3.2 不确定型决策 894
27.3.3 灵敏度分析 896
27.4 线性规划 897
27.5 动态规划 900
27.6 本章练习 903
第28章 项目管理过程实践和案例分析 911
28.1 项目管理过程进化之路 911
28.1.1 初始状态 911
28.1.2 改进1：规范立项标准、跟踪执行状态、审批结项依据 912
28.1.3 改进2：阶段评审、偏差控制 913
28.1.4 改进3：通过过程审计规范内部过程 913
28.1.5 改进4：增强过程控制力，提高运行的准确度 914
28.1.6 持续改进：不断通过过程优化和新工具/方法提高效率 915
28.2 基于PMBOK的项目管理过程实践 916
28.2.1 SMCI过程改进模型 916
28.2.2 僵化、优化和固化 918
28.2.3 过程改进项目化 921
28.2.4 项目管理过程裁剪方法 924
28.2.5 管理最佳实践 927
28.3 —体化项目管理过程实践 930
28.3.1 一体化的背景 930
28.3.2 —体化的目标 931
28.3.3 阶段工作流程图 931
28.3.4 —体化管理休系 933
28.3.5 与ISO、CMMI、PMBOK之间的关系 935
28.4 案例分析：真实环境下的项目管理 936
28.4.1 项目背景 936
28.4.2 项目启动 937
28.4.3 遭遇困难 937
28.4.4 项目经理石涛 938
28.4.5 项目骨干韩立 939
28.4.6 案例解析 940
参考文献 946
三、进度管理
项目进度管理知识，主要涉及项目进度管理的 7 个过程：规划进度管理、定义活动、排列活动顺序、估算活动资源、估算活动持续时间、制订进度计划、控制进度等内容。 进度管理领域输入、输出、工具和技术表如表 6-1 所示。  
四、成本管理
成本管理领域输入、输出、工具和技术表如表 7-1 所示。 
五、质量管理
质量管理领域输入、输出、工具和技术表如表 8-1 所示。 
六、人力资源管理
团队发挥阶段： 1.形成阶段 2.震荡阶段 3.规范阶段 4.发挥阶段 5.解散阶段
七、沟通管理
项目沟通管理是确保及时、正确地产生、收集、分发、储存和最终处理项目信息所需的过程 沟通渠道： 1）个人沟通渠道（面对面、电话、邮件） 2）非个人沟通渠道（主要媒体、氛围、活动） 组织的沟通渠道： 1）正式沟通渠道（传达文件、召开会议、上下级之间的定期的情报交换；团体所组织的参观访问、技术交流、市场调查） 2）非正式沟通渠道（交换看法、朋友聚会、传播谣言、小道消息） 非正式沟通事先预知模型：5个特点 高度的非正式沟通：利用何种场合，通过各种方式，排除各种干扰来保持他们之间经常不断的信息交流，从而在一个团队、一个企业中形成一个巨大的、不拘形式的、开放的信息沟通系统。优点：节省时间、避免正式场合的拘束和谨慎感，在轻松的氛围下解决长年累月难以解决的问题，减少团体内人际关系的摩擦 沟通技巧： 1.赞美对方 2.移情入境 3.轻松幽默 4.袒胸露怀 5.求同存异 6.深入浅出 7.聆听中的技巧 8.使用目光接触和对视 9.展现赞许性的表示 10.避免分心的举动或手势 11.适时合理地提问 12.正确有效地复述 13.避免随便打断对方 14.尽量做到多说少听 15.使听者与说者的角色顺利转换 表述中的技巧： 1.预先准备思路和提纲 2.及时调整和修订编码 3.及时合理的征询意见 4.避免过度表现自己 5.尽量言简意赅
八、风险管理
九、采购管理
十、干系人管理
项目管理五大过程
一张图总结PMBOK所有知识点 项目管理过程包含五大项目管理过程组和十大项目管理知识领域。 五大项目管理过程组：启动，规划，执行，监控，收尾。 十大项目管理知识领域：整合管理，范围管理，时间管理，成本管理，质量管理，人力资源管理，沟通管理，风险管理，采购管理，干系人管理。 熟悉了这个框架， 心中就有了PMBOK！  五大过程组的关系 启动，规划，监控，执行，收尾这五大过程组构成了项目管理生命周期，他们之间有清晰的，相互依赖与相互作用关系。在项目完成之前，往往需要反复实施各过程组及其过程。 值得注意的是，规划过程组和执行过程组是相互影响相互作用的，而监控过程组贯穿了整个项目管理生命周期。  https://zhuanlan.zhihu.com/p/27174144
启动
启动过程组（Initiating Process Group）需要做些什么？ 关键词：定义初步范围（项目边界），授权项目开始，识别内外部干系人，选定项目经理。 - 制定项目章程：一般由项目发起人起草，正式授权项目，任命项目经理，定义初步的项目范围（项目边界），落实初步的财务资源。 - 识别干系人：识别干系人，并分析和记录他们的相关信息的过程。这些信息包括他们的利益、参与度、相互依赖、影响力及对项目成功的潜在影响等。过程的主要作用是，帮助项目经理建立对各个干系人或干系人群体的适度关注。 
规划
规划过程组（Planning Process Group）需要做些什么？ 关键词：反复进行，滚动式规划；明确项目范围，为实现项目目标制定行动方案（即制定项目管理计划）。 - 项目范围管理领域：规划范围管理--->收集需求--->定义范围--->创建WBS 这里重点说一下WBS。WBS（Work Breakdown Structure）工作分解结构，是对全部工作范围的一个层级分解。创建WBS，是把项目可交付成功和项目工作分解成较小的，更易于管理的组件的过程 主要是为了对所要交付的内容提供一个结构化的视图，输出项目的范围基准。  如果没有WBS，就无法制定进度，成本，风险和人员计划等。编制WBS不仅是其他项目规划工作的基础，也是整个项目实施的基础。分解规则遵循100%分解原则，即包含所有项目工作，不多也不少，且以可交付成果为导向。 - 项目时间管理领域：规划进度管理--->定义活动--->排列活动顺序---->估算活动资源--->估算活动持续时间--->制定进度计划 项目进度计划一般用三种图来表示：里程碑图，横道图（甘特图），项目进度网络图（如下）。制定进度计划用到的主要方法是：关键路径法和关键链法，以及资源优化技术。关键路径是进度计划中总工期最长的那条路径，决定这项目完工的最短工期。  - 项目成本管理领域：规划成本管理---->估算成本--->制定预算 估算成本的常用方法有：专家判断，类比估算，参数估算，三点估算，除非分析，自下而上估算，质量成本，储备分析等。自下而上的估算需要参照上面提到的WBS；储备分析需要在项目预算中设置应急储备和管理储备来应对风险事件。  - 项目风险管理领域：规划风险管理--->识别风险---->实施定性风险分析--->实施定量风险分析--->规划风险应对 识别风险过程结束后，会输出风险登记册，用来记录与追踪所有风险。随着项目的进展，风险等级侧会不断更新。定性风险分析是评估已识别风险的概率和影响，对风险进行优先级排序，并重点关注高优先级的风险。定量风险分析是分析重大风险对项目整体目标影响的程度，需要借助建模技术。 - 项目其他领域：规划质量管理，规划人力资源管理，规划沟通管理，规划人力资源管理，规划采购管理，规划干系人管理。 总结：项目的规划过程组就是规划各个领域的管理计划， 综合成一份总的“项目管理计划”，包括所有子管理计划和三项基准（范围基准，时间基准，成本基准）
执行
执行过程组（Executing Process Group）需要做些什么？ 关键词：执行计划，并产生可交付成果；引发变更请求，并执行经过批准的变更；更新项目管理计划或建立新的基准。 - 项目人力资源管理领域：组建项目团队--->建设项目团队--->管理项目团队； 在管理项目团队部分，重点是管理冲突。PMI任务合理的冲突是有益的，只要有界面，冲突不可避免 冲突的来源主要是：资源稀缺与优先级顺序。推崇用合作/解决（collaborate / Problem Solve）来解决冲突。冲突当事人采用合作的态度以及开放式对话达成共识和承诺。紧急情况下需要使用强制/命令（Force/Direct）的方式解决冲突，以免错过时机，拖延而影响项目。 - 项目干系人管理领域：管理干系人参与 管理干系人参与是在整个项目生命周期中，与干系人进行沟通和协作，以满足其需要与期望，解决实际出现的问题，并促进干系人合理参与项目活动的过程。管理干系人参与的主要作用是帮助项目经理提升来自干系人的支持，并把干系人的抵制降到最低，从而显著提高项目成功的机会。 - 项目质量管理领域：实施质量保证 实施质量保证主要是为了确保采用合理的质量标准和操作定义，以及促进质量过程改进，有常用的7种质量管理和控制工具。  - 项目采购管理领域：实施采购 实施采购是获取卖方应答、选择卖方并授予合同的过程。这个过程的主要作用是，通过达成协议，使内部和外部干系人的期望协调一致。 - 项目沟通管理领域：管理沟通 管理沟通是根据沟通管理计划，生成、收集、分发、储存、检索及最终处置项目信息的过程。这个过程的主要作用是，促进项目干系人之间实现有效率且有效果的沟通。
监控
监控过程组（Monitoring and Controlling Process Group）需要做些什么？ 关键词：跟踪项目绩效，识别与项目管理计划的偏差；识别必要的变更，并启动相应变更程序。 - 项目范围管理领域：确认范围-->控制范围 确认范围是指客户或发起人正式验收可交付成果；控制范围是指在整个项目期间保持对范围基准的维护，监控，管理范围变更。 - 其他领域：控制进度，控制成本，控制质量，控制采购，控制沟通，控制风险，控制采购。 控制成本中一个重要的概念叫挣值管理（EVM），即在既定的范围下追求进度和成本绩效的综合最优。EV表示实际完成工作量的预算价值，PV表示计划完成工作量的预算价值，AC表示标识实际完成工作量的成本。用这三个值来综合衡量项目绩效，并对未来的项目绩效做出预测。  控制质量主要是关注可交付成果是否正确以及是否满足质量要求，比较注重正确性。 关于可交付成果从产生到最终被客户验收，会经历这样的过程：执行过程组-->可交付成果-->控制质量-->核实的可交付成果-->确认范围-->验收的可交付成果。 控制沟通的主要作用是，在整个项目生命周期中确保所有沟通参与者之间的信息流动的最优化。 控制风险是在整个项目中实施风险应对计划、跟踪已识别风险、监督残余风险、识别新风险，以及评估风险过程有效性的过程。
收尾
收尾过程组（Closing Process Group）需要做些什么？ 关键词：正式结束项目或阶段或合同责任，结束采购。 另外，收尾过程组也用于正式处理项目提前结束的情形。提前结束的项目可能包括：中止的项目、取消的项目或有严重问题的项目。在特定情况下，如果合同无法正式关闭（因索赔、终止条款等原因），或者需要向其他部门转移某些活动，可能需要安排和落实具体的交接手续。 收尾过程组可能需要进行以下活动： - 进行项目后评价或阶段结束评价； - 记录经验教训； - 对组织过程资产进行适当更新； - 将所有相关项目文件在项目管理信息系统中归档，以便作为历史数据使用； - 结束所有采购活动，确保所有相关协议的完结； - 对团队成员进行评估，释放项目资源。
准备工作
PMBOK的特点 PMBOK并不是项目管理方面的万能书，在学习之前我们了解PMBOK的特点： - PMBOK收录了项目管理知识体系中被普遍认可为良好做法的那一部分，大多时候适用于大多项目 - 只针对通用的项目管理知识，不针对任何具体行业 - 只针对单一项目管理，不针对项目集和项目组合 - 是一份指南，不是具体的方法论 几个重要的基本概念 在开始快速学习前，我们先了解几个重要的基本概念。 1. 什么是项目？ PMBOK中把项目定义为“为了创造独特的产品、服务或成果而进行的临时性工作”。 项目有三大特点：临时性，独特性，渐进明细性。“渐进明细性”可解释为项目目标从方向性大目标到可测量的小目标，产品范围和项目范围从粗略到详细，项目计划从控制性计划到具体操作。简言之，就是随着项目的开展，项目的目标、范围、计划等慢慢变得细致明确。 另外，注意把项目与运营区分开来。项目需要有明确的开始时间和结束时间，即项目的临时性。如果是常规的重复的持续不断的工作，则属于运营工作的范畴，比如举办亚运会。 2.什么是项目干系人？ 项目干系人是指能影响项目决策，活动或结果的个人，群体或组织，以及会受或自认为会受项目决策，活动或结果影响的，个人，群体或组织。简言之，就是会影响项目，以及会受到项目（潜在）影响的人群。  PMBOK强调了干系人管理的重要性。因为干系人之间不同的期望或利益会在项目中引发冲突，可能对项目造成消极影响；且不同干系人对项目的影响和责任是随着项目生命周期进展而变化的，这就要求项目经理对干系人作出持续性的管理。PMBOK定义项目经理的重要职责之一为：管理项目干系人的期望+平衡干系人的不同利益。 3.什么是组织过程资产？ 组织过程资产是执行组织所特有并使用的计划、流程、政策、程序和知识库，可能还包括完整的进度计划、风险数据和挣值数据。组织过程资产可分成两大类：流程与程序，共享知识库（经验教训和历史信息）。 在项目全过程中，项目团队成员通常有责任对组织过程资产进行持续的更新和增补。组织过程资产是大部分规划过程的输入。 4.什么是事业环境因素？ 事业环境因素是指项目团队不能控制的，将对项目产生影响、限制或指令作用的各种条件，可能提高或限制项目管理的灵活性，并可能对项目结果产生积极或消极的影响。 从性质或类型上讲，事业环境因素是多种多样的，包括（但不限于）： 组织文化、政府或行业标准、基础设施、现有人力资源状况、人事管理制度、市场条件、商业数据库和项目管理信息系统等。事业环境因素也是大多数规划过程的输入。