信息系统项目管理师（2022年）—— 重点内容：项目范围管理（5）
验收的可交付成果，属于项目范围管理中(确认范围 )过程的输出。
确认范围的输出主要包括：(1)验收的可交付成果；(2)变更请求；(3)工作绩效信息；(4)项目文件更新。
----
群体创新技术(Group Creativity Technique)是指可以组织一些群体活动来识别项目和产品需求，群体创新技术包括头脑风暴法、名义小组技术、德尔菲技术、概念/思维导图、亲和图和多标准决策分析等。
---
在项目范围管理中，企业管理层主要关注( 项目范围投入产出的合理性)。
项目范围管理就是要做范围内的事，而且只做范围内的事，既不少做也不多做。如果少做，会影响项目既定功能的实现；如果多做，又会造成资源浪费。具体来说，项目范围管理需要做以下三个方面的工作：
(1)明确项目边界，即明确哪些工作是包括在项目范围之内的，哪些工作是不包括在项目范围之内的。
(2)对项目执行工作进行监控，确保所有该做的工作都做了，而且没有多做。对不包括在项目范围内的额外工作说“不”，杜绝做额外工作。
(3)防止项目范围发生蔓延。范围蔓延是指未对时间、成本和资源做相应调整，未经控制的产品或项目范围的扩大。
完成项目工作范围是为了实现项目目标，那么如何有效地、全部地完成项目范围内的每项工作，这是每个项目经理必须思考的问题，而企业管理层主要关注的是项目范围投入产出的合理性。
---
( )is the process of formalizing acceptance of the completed project deliverables.The key benefit of this process is that it brings objectivity to the acceptance process and increases the probability of final product , service , or result acceptance by validating each deliverable.
Validate scope
Define scope
Control scope
Collect requirement
( ) 是正式验收竣工项目的过程可交付成果这个过程的主要好处是它使验收过程更加客观，并通过验证每个可交付成果来增加最终产品、服务或结果验收的概率。
( ) A. 验证范围 B. 范围确认 C. 控制范围 D .收集要求
---
质量功能部署(Quality Function Deployment，QFD)将 软件需求 分为常规需求、( 期望需求 )和意外需求。
---
项目小组正在对项目需求变化数量、变化频率以及变化方式等进行 评估 ，该工作属于(变更管理计划 )的管理范畴
范围管理计划是项目或项目集管理计划的组成部分，描述将如何定义、制订、监督、控制和确认项目范围。由于范围管理计划描述如何管理项目范围，项目范围怎样变化才能与项目要求相一致等问题，所以它也应该对怎样变化、变化频率如何，以及变化了多少等项目范围预期的稳定性进行评估。范围管理计划也应该包括对变化范围怎样确定，变化应归为哪—类等问题的清楚描述。
---
使用结构化SA方法进行需求分析，其建立的模型的核心是数据字典，围绕这个核心，有三个层次的模型，分别是数据模型、功能模型和行为模型(也称为状态模型)。在实际工作中，一般使用实体联系图(E-R图)表示数据模型，用数据流图(Data Flow Diagram,DFD)表示功能模型，用状态转换图( State Transform Diagram, STD) 表示行为模型。
---
确认范围的输入包括：项目管理计划、需求文件、需求跟踪矩阵、确认的可交付成果（不是验收可交付的成果）、工作绩效数据 。
---
本题考查收集需求过程的工具方法，参考第三版教程P227
1.焦点小组
焦点小组将预先选定的干系人和主题专家集中在一-起，了解他们对所提议产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。
2.名义小组技术.
名义小组技术(Nominal Group Technique)通过投票来排列最有用的创意，以便进行进一步的头脑风暴或优先排序。 名义小组技术是头脑风暴法的深化应用，是更加结构化的头脑风暴法，其一般过程如下。
●首先，将全体参与者分成多个“名义”上的小组，由每个小组开展讨论。 小组讨论结束后，主持人依次向每位参与者询问，请每人提出一个创意。这种询问可以进行很多轮，直至得到足够数量的创意。
●最后，请全体参与者对所有创意进行评审和排序。也可以由名义小组先提出一些较 大的创意类别，再将这些创意类别提交给全体参与者作为头脑风暴的基础。与一般的头脑风暴法相比， 名义小组技术可以使那些不善言辞的参与者也能充分发表自己的意见。
3.引导式研讨会
通过邀请主要的跨职能干系人一起参加会议，引导式研讨会(Facilitated Workshop)对产品需求进行集中讨论与定义。研讨会是快速定义跨职能需求和协调干系人差异的重要技术。由于群体互动的特点，被有效引导的研讨会有助于建立信任、促进关系、改善沟通，从而有利于参加者达成一致意见。 该技术的另一-个好处是，能够比单项会议更快地发现和解决问题。
4.头脑风暴法
头脑风暴(BrainStorming, BS) 法又称为智力激励法、自由思考法或集思广益法，是用来产生和收集对项目需求与产品需求的多种创意的一一种技术。头脑风暴法分为直接头脑风暴法(通常简称为头脑风暴法)和质疑头脑风暴法(也称为反头脑风暴法)。前者是在专家群体决策时尽可能激发创造性，产生尽可能多的设想的方法，后者则是对前者提出的设想、方案逐一质疑，分析其现实可行性的方法。
---
确认范围与质量控制的不同之处在于:
1、确认范围主要强调可交付成果获得客户或发起人的接受;质量控制强调可交付成果的正确性，并符合为其制定的具体质量要求(质量标准)。
2、质量控制一般在确认范围前进行，也可同时进行;确认范围一般在阶段末尾进行，而质量控制并不一定在阶段未进行。
3、质量控制属内部检查，由执行组织的相应质量部门实施;确认范围则是由外部干系人(客户或发起人)对项目可交付成果进行检查验收。
---
The( )is a hierarchical decomposition of the total scope of work to be Carried out by the project team to accomplish the project objectives and create the required deliverables.
project scope statement
work package
WBS
project scope plan
()是项目团队为完成项目目标和创建所需的可交付成果而进行的总体工作范围的层次分解。
project scope statement 项目范围说明书
work package 工作包
WBS 工作分解结构
project scope plan 项目范围计划
---
WBS必须符合项目范围
---
1、控制范围(Control Scope)是监督项目和产品的范围状态、管理范围基准变更的过程，其主要作用是在整个项目期间保持对范围基准的维护。对项目范围进行控制，就必 须确保所有请求的变更、推荐的纠正措施或预防措施都经过实施整体变更控制过程的处 理。在变更实际发生时，也要采用范围控制过程来管理这些变更。 2.范围变更的原因；造成项目范围变更的主要原因是项目外部环境发生了变化，例如： 政府政策的问题。（D选项） 项目范围的计划编制不周密详细，有一定的错误或遗漏。 市场上出现了或是设计人员提出了新技术、新手段或新方案。 项目执行组织本身发生变化。（B选项） 客户对项目、项目产品或服务的要求发生变化。3、未经控制的产品或项目范围的扩大(未对时间、成本和资源做相应调整)称为范围蔓延。在信息系统集成项目中，变更是不可避免的，控制范围过程依赖于范围变更控制系统，范围变更控制是指对有关项目范围的变更实施控制，审批项目范围变更的一系列过程，包括书面文件、跟踪系统和授权变更所必须的批准级别。 选项A、范围变更控制系统是控制范围的一种有效的方式；
---
项目范围管理包括确保项目成功所需的全部工作过程，范围管理过程按顺序应为收集需求——定义范围——创建工作分解结构（WBS）——核实范围——控制范围（最后得到有效的控制）。
---
此题考察的是WBS.必须掌握.高频考点
在项目范围管理过程中，最常用，也是必须要熟悉的工作分解方法是工作分解结构WBS, 是面向可交付物的项目元素的层次分解，它组织并定义了整个项目范围。WBS是一个详细的项目范围说明的表示法，详细描述了项目所要完成的工作。WBS的组成元素有助于项目干系人检查项目的最终产品。WBS的最低层元素是能够被评估的、安排进度的和被跟踪的。项目作结构分解对项目管理有着重要的意义：
(1)通过工作结构分解，把项目范围分解开来，使项目相关人员对项目一目了然，能够使项目的概况和组成明确、清晰、透明、具体，使项目管理者和项目主要干系人都能通过WBS把握项目、了解和控制项目过程。
(2) 保证了项目结构的系统性和完整性。
(3) 通过工作结构分解，可以建立完整的项目保证体系。
(4) 项目工作结构分解能够明确项目相关各方的工作界面，便于责任划分和落实。
(5) 最终工作分解结构可以直接作为进度计划和控制的工具。
(6) 为建立项目信息沟通系统提供依据，便于把握信息重点。
(7) 是项目各项计划和控制措施制定的基础和主要依据。
工作结构分解应把握的原则有：
(1) 在各层次上保持项目的完整性，避免遗漏必要的组成部分。
(2) —个工作单元只能从属于某个上层单元，避免交叉从属。
(3) 工作单元应能分开不同责任者和不同工作内容。
(4) 便于项目管理计划、控制的管理需要。
(5) 最低层工作应该具有可比性，是可管理的，可定量检查的。
(6) 应包括项目管理工作，包括分包出去的工作。
---
项目范围在项目的早期被描述出来，并且随着项目的进展变得更加详细。
---
某软件开发项目在项目的最后阶段发现对某个需求的理解与客户不一致，产生该问题最可能的原因是(需求验证 )工作不完善。
此题考察的是需求管理，必须掌握，高频考点
需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。需求开发的过程有4个主要活动：
(1) 需求获取。积极地与用户进行交流，捕捉、分析和修正用户对目标系统的需求，并提炼出符合解决问题的用户需求，产生《用户需求说明书》。
(2) 需求分析。需求分析的目的是对各种需求信息进行分析并抽象描述，为目标系统建立一个概念模型。
(3) 需求定义。需求定义的目标是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《需求规格说明书》。
(4) 需求验证。需求验证是指开发方和用户共同对需求文档评审，经双方对需求达成共识后做出书面承诺，使需求文档具有商业合同效果。
因此，在项目的最后阶段发现对某个需求的理解与客户不一致，产生该问题最可能的原因是需求验证工作不完善，双方没有对需求达成正确共识。
---
范围控制涉及以下内容：影响范围变更的因素，确保所有被请求的变更按照项目整体变更控制处理，范围变更发生时管理实际的变更。范围控制与其他控制过程完全结合。未控制的变更经常被看作范围溢出。变更应当被视作不可避免的，因此要颁布一些类型的变更控制过程。
不涉及：确定范围变更是否已经发生
---
---
本题中项目范围发生了变更，承建单位依据建设方的要求进行了范围变更管理。其管理步骤应包括提交范围变更申请、对范围变更影响进行分析并交CCB审批、执行变更、对范围变更进行验证、干系人沟通并确认、归档。其中“执 行变更”即执行IT服务管理知识培训，“对范围变更进行验证” 一实际上就是对培训效果进行验证。
(1) 如果项目组成员不了解范围变更申请的写法，可以对范围变更请求的描述以及分析方法等进行培训，即培训范围变更请求；
(2) 对培训效果进行验证的方法，可以是安排一次考试，以测验分数,同时让学员签到，即学员签到表；
(3) 对培训效果进行验证的准则应该是批准后的培训方法与策略，故新批准的培训工作方案是正确答案。
---
答案：产品需求
WBS工作分解至少可以按照三种方式分解，第一是按照可交付物分解，第二是按照项目生命周期分解，第三是按照项目管理工作分解。在创建工作分解结构时，应该把握一些基本原则，其中的一个原则是同一层次上的活动应该釆用相同的分解方式。
由题干中的图例可知，在“确定需求”这一活动下的子活动是按照生命周期分解的，在需求获取中，首先获得总体需求，再进一步获得产品需求。
---
范围，管理的主要流程和内容有：
①编制范围管理计划：规定如何定义、检验、控制范围，以及如何创建WBS;计划可以是独立的也可以合并在项目管理计划中。
②范围定义：给出项目和产品的详细描述，主要围绕各阶段的交付信息。
③创建WBS:将可交付成果和项目工作分解为更小更易于管理的单元。
WBS不能直接用来指导项目实施，还需要活动定义、活动排序等工作，产生项目进度计划、成本预算、质量要求后方可开展项目活动。
---
项目管理中变更是极其普遍的现象，对变更要进行管理。项目范围的核心是产品范围，因此，产品的需求发生变化其实就是一种范围变更。需求的核心是客户的需求，无论需求识别还是需求变更都要让客户参与。
范围管理是整体管理的一部分，变更流程可统一设计，统一管理，因此没必要必须把范围变更与整体变更区分开来。
---
双向跟踪性是指需求和产品之间能进行双向跟踪，它有助于确定是否所有的来源都完全得到处理，是否所有的低层需求都可以跟踪到有效的来源。
---
检验WBS是否定义完全、项目的所有任务是否都被完全分解主要依据以下标准：
1每个任务的状态和完成情况是可以量化的
2明确定义了每个任务的开始和结束
3每个任务都有一个可交付成果
4工期易于估算且在可接受期限内
5容易估算成本
6各项任务是独立的
7各项任务能被描述的。
不包括：是否明确了变更申请
---
范围确认是有关工作结果的可接受问题，质量控制是有关工作结果是否满足质量需求的问题，范围确认与质量控制不同，质量控制通常是在范围确认之前进行，这两个过程也可以并行执行，范围确认的输入和质量控制输入都包括项目分解结构字典。
---
某项目经理张先生在确定项目范围过程中，已得到项目章程、工作说明书、企业环境因素和组织过程资产等信息，他立刻组织项目团队管理人员，并聘请有关专家，采用项目管理信息系统、项目管理方法论等工具，确定项目需要完成的工作，在上述工作结束后，相应的输出是( 项目范围说明书)。
范围定义的输出主要是项目范围说明书
---
---
关于项目范围确认及有关活动，以下说法错误的是( )。
A 可以通过检查来实现范围的确认
B 检查包括测量、测试、检验等活动
C 范围确认的目的就是形成项目范围说明书（答案：范围定义成果是形成详细项目范围说明书）
D 检查也可被称为审查、产品评审和走查
范围确认(scopeverification)是指干系人对于整个项目范围的正式验收。这份验收通常通过客户审查实现，并在关键可交付成果上签字。要形成正式的项目范围验收，项目组必须就项目产品和过程建立清晰的记录，从而可以评价这个项目是否正确地令人满意的完成了。为了最小化范围变更，进行一个良好的项目范围确认是至关重要的。
范围定义成果是形成详细项目范围说明书。
---
项目范围说明书是项目文档中最重要的文件之一。它进一步并且正式明确了项目所应该产生的成果和项目可交付的特征，并在此基础上进一步明确和规定了项目利益相关者之间希望达成共识的项目范围，为未来项目的决策提供一个管理基线。
---
WBS的基本定义：以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。
取消了由张工管理的视频游戏项目的需求定义文件和范围说明。现在公司要求将该项目成果变成可在个人电视及计算机上玩的交互式游戏，至少需要修改项目既定的由WBS定义的范围。
---
大项目的WBS只要到子项目就可以，对于子项目就需要进行进一步的细化到工作包
---
WBS词典是在创建工作分解结构的过程中编制的，是工作分解结构的支持性文件， 用来对工作分解结构中的控制账户和工作包做详细解释。解释的详细程度可以根据具体需要加以确定。控制账户是工作分解结构中的要素，是项目经理对项目的管理控制点，即针对控制账户的要素对项目的执行情况进行检查与考核。可以把工作包作为控制账户，也可以把更高层的要素作为控制账户。
WBS词典包括编码、工作包描述(内容)、成本预算、时间安排、质量标准或要求、责任人或部门或外部单位(委托项目)、资源配置情况、其他属性等。
要完成这个管理信息系统，需要收集这15个项目所有工作的相关信息，这些信息构成了工作分解结构(WBS)词典。
---
需求基线定义：团队成员已经承诺将在某一特定产品版本中实现的功能性和非功能性需求的一组集合。经评审批准，这些文档就定义了开发工作的需求基线，这个基线在客户和开发人员之间就构筑了计划产品功能需求和非功能需求的一个约定。
完成(需求验证 )过程后将确定需求基线
需求开发包括需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。需求工程的活动划分为以下5个独立的阶段：
(1)需求获取：通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求；
(2)需求建模：为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义；
(3)形成需求规格：生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约；
(4)需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型等途径， 分析需求规格的正确性和可行性；
(5)需求管理：支持系统的需求演进，如需求变化和可跟踪性问题完成需求验证过程后将确定需求基线。
---
在软件项目中，(做好需求追溯 )是确保需求不在开发过程中“丢失”的一个有效措施。
需求追溯评估需求变更的影响范围。安CMMI的要求包括追溯能力垂直与水平追溯能力。
需求回溯，是回头看、回顾的意思。
---
创建工作分解结构是项目范围管理的重要内容，该项活动的输出包括工作分解结构(WBS)、WBS字典、变更申请、范围管理计划(更新)和( )。
A 范围基线
B 项目章程
C 绩效报告
D 工作说明书
工作分解结构(WorkBreakdownStructure，WBS)跟因数分解是一个原理，就是把一个项目，按一定的原则分解，项目分解成任务，任务再分解成一项项工作，再把一项项工作分配到每个人的日常活动中，直到分解不下去为止。即：项目→任务→工作日常活动工作分解结构以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围，每下降一层代表对项目工作的更详细定义。WBS总是处于计划过程的中心，也是制订进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。WBS同时也是控制项目变更的重要基础。项目范围是由WBS定义的，所以WBS也是一个项目的综合工具。
WBS字典：是在创建工作分解结构的过程中编制的，是工作分解结构的支持性文件，用来对工作分解结构中的控制账户和工作包做详细解释。解释的详细程度可以根据具体需要而定。控制账户是工作分解结构中的要素，是项目经理对项目的管理控制点， 即针对控制账户的要素对项目的执行情况进行检查与考核。可以把工作包作为控制账户， 也可以把更高层的要素作为控制账户。
项目范围基线是批准的详细项目范围说明书与对应的工作分解结构和工作分解结构词汇表。
项目章程是正式批准项目的文件。任何一个项目，都是由一个或多个原因而被批准的，这些原因包括市场需求、营运需要、客户要求、技术进步、法律要求和社会需要等。
主管部门必须作出批准或不批准某个项目并且颁发项目章程的决策，决策主要基于项目对于项目所有人和赞助人的价值和吸引力。而其前提则是可行性研究的审查和通过。
绩效报告指搜集和传播绩效信息，向利害关系者提供资源如何用于实现项目目标的信息。绩效报告通常应当提供有关范围、进度、成本与质量的信息。
工作说明书是对项目所要提供的产品或服务的叙述性的描述。对内部项目而言，项目发起者或投资人基于业务需求，或产品或服务的需求提出工作说明书。对外部项目而 言，工作说明书作为投标文档的一部分从客户那里得到，如：邀标书，投标的信息，或作为合同的一部分得到。
工作说明书作为组织重要的文件之一，是指用书面形式对组织中各类岗位(职位) 的工作性质、工作任务、责任、权限、工作内容和方法、工作环境和条件，以及本职务任职人资格条件所作的统一要求(书面记录)。它应该说明任职者应做些什么、如何去做和在什么样的条件下履行其职责。一个名符其实的工作说明书必须包括该项工作区别于其他工作的信息，提供有关工作是什么，为什么做，怎样做以及在哪里做的清晰描述。
因此，创建工作分解结构的输出包括工作分解结构(WBS)、WBS字典、变更申请、 范围管理计划(更新)和范围基线。
---
控制账户是一种管理控制点。在该控制点上，把范围、成本和进度加以整合，并把它们与挣值相比较，以测量绩效。控制账户设置在工作分解结构中的特定管理节点上。 每一个控制账户都可以包括一个或多个工作包，但是每一个工作包只能属于一个控制账户。
---
控制账户(简称CA)，是一种管理控制点，是工作包的规划基础。在该控制点上，把范围、成本和进度加以整合，并把它们与挣值相比较，以测量绩效。控制账户设置在工作分解结构中的特定管理节点上。每一个控制账户都可以包括一个或多个工作包，但是每一个工作包只能属于一个控制账户。
基线(Baseline)。基线是软件文档或源码(或其他产出物)的一个稳定版本，它是进一步开发的基础。所以，当基线形成后，项目负责SCM的人需要通知相关人员基线已经形成，.并且哪儿可以找到这基线了的版本。这个过程可被认为内部的发邗。至于对外的正式发布，更是应当从基线了的版本中发布。
基线是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线，参与项目的开发人员将基线所代表的各版本的目录和文件填入他们的工作区。随着工作的进展，基线将合并自从上次建立基线以来开发人员已经交付的工作。变更一旦并入基线，开发人员就采用新的基线，以与项目中的变更保持同步。调整基线将把集成工作区中的文件并入开发工作区。
WBS词典是在创建工作分解结构的过程中编制的，是工作分解结构的支持性文件，用来对工作分解结构中的控制账户和工作包做详细解释。解释的详细程度可以根据具体需要加以确定。控制账户是工作分解结构中的要素，是项目经理对项目的管理控制点，即针对控制账户的要素对项目的执行情况进行检查与考核。可以把工作包作为控制账户， 也可以把更高层的要素作为控制账户。
---
项目范围的管理也就是对项目应该包括什么和不应该包括什么进行相应的定义和控制。它包括用以保证项目能按要求的范围完成所涉及的所有过程，包括：确定项目的需求、定义规划项目的范围、范围管理的实施、范围的变更控制管理以及范围核实等。
创建工作分解结构是项目范围管理的一个过程。
其定义为：把项目可交付成果和项目工作分解为较小的、更易于管理的组成部分的过程。由此可见工作分解结构示意可交付成果为导向的工作分解层次。
输入：项目范围说明书(定义范围的输出)、需求文件(收集需求的输出)、组织过程资产。
工具：分解，采用自上而下的逐层细化的分解方式，最小分解到工作包的层次。工作分解结构形式有多种：①以项目生命周期的各阶段作为第一层。②把主要可交付成果作为分解的第一层。③按子项目进行第一层分解。
不同的可交付成果可分解到不同的层次，由于信息不明确，对于远期的可交付成果或者子项目无法分解，通常要等这些信息足够明确后，才能分解到相应细节，这叫做滚动式规划。
输出：工作分解结构工作分结构词典范围基准项目文件(更新)。
创建工作分解结构的最后工作是为工作包建立控制账户，并根据“账户编码”分明配标志号。每个控制账户都可以包括一个或者多个工作包、但是每个工作包只能属于一个控制账户。控制账户是一种管理控制点，该控制点上，把范围、成本和进度加以整合，并把它们与挣值相比较，以测量绩效。
核实范围：核实产品是否在范围内。首先要通过(需求跟踪矩阵)去保持客户联系，确定产品范围有没变，确保(需求文档)最新后，用它去核实“确认过质量的产品”(确 认的可交付成果)的范围，核实没有问题就可以验收这个产品(验收的可交付成果)，有问题就产生一个(变更请求)。注意在核实和控制过程还是用需求文件，而没有用范围说 明书，因为相对需求文件，范围说明书比较粗略。
控制范围：控制工作是否在范围内。首先还是要通过(需求跟踪矩阵)去保持客户联系，确定工作范围有没变，确保(需求文档)更新到最新，既然是控制工作本身，那就要用到每日收集的工作状况(工作绩效信息)，去对照(需求文档)得到工作做出的效果如何(项目绩效测量结果)，有问题就产生一个(变更请求)。注意在核实和控制过程 还是用需求文件，而没有用范围说明书，因为相对需求文件，范围说明书比较粗略。
核实范围应该在创建工作分解结构之后。
---
可以把需求工程的活动划分为以下5个独立的阶段：
需求获取：通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求；
需求建模：为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义；
形成需求规格：生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约；
需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性，包含有效性检查，一致性检查，可行性检查和确认可验证性；
需求管理：支持系统的需求演进，如需求变化和可跟踪性问题。
---
---
需求跟踪有两种方式：
(1)正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。
(2)逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。
如果不能把设计元素、代码段，或测试回溯到一个需求，你可能有一个“画蛇添足的程序”。然而，若这些孤立的元素表明了一个正当的功能，则说明需求规格说明书漏掉了一项需求。
---
项目经理在进行大项目的WBS分解时，( )是错误的。
A 按照项目的组织结构编制树形结构的WBS
B 按照项目的产品结构编制列表式的WBS
C 按照项目的生命周期编制鱼刺图式WBS
D 按照项目风险分解结构编制树形结构的WBS
风险分解结构列出了一个典型项目中可能发生的风险分类和风险子分类。不同的RBS适用于不同类型的项目和组织。这种方法的一个好处是提醒风险识别人员风险产生的原因是多种多样的。
WBS的分解可以采用多种方式进行，包括：
•按产品的物理结构分解。
•按产品或项目的功能分解。
•按照实施过程分解。
•按照项目的地域分布分解。
•按照项目的各个目标分解。
•按部门分解。
•按职能分解。
---
( )不属于对需求描述的精确性要求。
A 能确认需求
B 能验证需求的实现
C 能估算需求的成本
D 能评估需求变更的影响
能确认需求、能验证需求的实现属于对需求描述的精确性要求。“估算需求的成本”本身描述不是很清楚，如果是估算，就不属于精确性要求。但需求变更的影响很难精确 地确定。
---
变更请求的提出可以是书面形式或口头形式，也可以是直接方式或间接方式。变更要求的提出可以是来自外部的，也可以是来自内部的，可以是自愿的也可以是被迫的.
---
项目经理向干系人说明项目范围时，应以( 项目范围说明书)为依据。
项目范围确认是以项目范围说明书、WBS和WBS词典为主。项目范围说明书是项目范围的基础。WBS是面向结果的，以最终可交付成果为基础，包含项目的所有活动。在向项目干系人说明项目范围时，要以项目范围说明书(详细)为依据。
---
资源计划矩阵也称资源矩阵，它是项目工作分解结构的直接产品，即根据具体工作分解结构情况来对资源进行分析、汇总。资源计划矩阵能够清晰表示WBS的结果，解决WBS中无法解决的问题。
活动清单是包括全部项目的计划活动。
物料清单(Bill of Materials，BOM)是描述企业产品组成的技术文件，是用于记录加工一个产品所需的子部件的一个列表。在加工制造式行业，它表明了产品的总装件、分装件、组件、部件、零件、直到原材料之间的结构关系，以及所需的数量。
---
以下关于项目范围管理的叙述中，( )是不正确的。
A 一般项目目标的设定标准可用一个单词SMART来表达
B 项目目标开始是出现在初步项目范围说明书里，后来被定义并最终归结到项目范围说明书里
C 范围定义过程给出了项目和产品的详细描述，并把结果写进详细的项目范围说明书
D 范围确认也被称为范围核实，它的目的是核实工作结果的正确与否，应该贯穿项目始终
解析：范围确认是有关工作结果的可接受问题，质量控制的目的才是核实工作结果的正确与否
---
按照参考教程中的描述，客户需要可向前追溯到需求，确保需求规格说明书包括所有客户的需求。同样，可以从需求回溯到客户需求，确认每个软件需求的源头。从需求向产品的追溯，可知道每个需求对应的产品部件，从而确保每个需求都得到满足，从产品部件回溯到需求，可知道每个产品部件存在的原因。
需求跟踪包括编制每个需求同系统元素之间的联系文档。这些元素包括别的需求、体系结构、其他设计部件、源代码模块、测试、帮助文件、文档等。
客户需要可向前追溯到需求，确保需求规格说明书包括所有客户的需求。同样，可以从需求回溯到客户需求，确认每个软件需求的源头。从需求向产品的追溯，可知道每个需求对应的产品部件，从而确保每个需求都得到满足，从产品部件回溯到需求，可知道每个产品部件存在的原因。
逆向需求跟踪检查设计文档、代码、测试用例等工作产品是否都能在《需求规格说明书》中找到出处。
---
根据参考教材，指导和管理项目执行过程需要项目经理和项目团队执行多项行动来执行项目管理计划以完成项目范围说明书中所定义的工作。这些行动可以是：
(1) 执行活动以完成项目或阶段的目标。
(2) 付出努力和支出资金以完成项目或阶段目标。
(3) 配置人员，进行培训，管理已分配到项目或阶段中的项目团队成员。
(4) 获得报价、投标、出价或提交方案书。
(5) 从潜在的供应商中选择合适的供应商。
(6) 获取、管理和使用包括原料、工具、设备和设施在内的资源。
(7) 实施计划的方法和标准。
(8) 创建、验证和确认项目或阶段的可交付物。
(9) 管理风险和实施风险响应活动。
(10) 管理供应商。
(11) 使已批准的变更适应于项目的范围、计划和环境。
(12) 建立和管理项目组内部和外部的项目通信渠道。
(13) 收集项目或阶段数据并汇报成本、进度、技术、质量的进展和状态信息以便于预测。
(14) 收集和记录经验教训并实施已批准的过程改进活动。
---
答案：①②④⑤
每个WBS元素应只从属一个母层次的WBS元素，避免交叉从属。
---
本考题考查的知识点为WBS、OBS、RBS等基础知识。
风险分解结构(RBS)：以层次结构的方式对已识别的风险进行组织，通常是按照风险类别进行划分的。
物料清单(BOM)：描述了生产一个产品所需的实际部件、组件和构件的分级层次表格。
组织分解结构(OBS)：描述了执行组织的层次结构，以便把工作包同执行组织单元相关联。
涉及到成员(人员)：自然是选择组织分解结构OBS。
资源分解结构(RBS)：是另一种层次结构图，它用来分解项目中各种类型的资源,可以作为组织机构图与职位描述的一种方式。
---
以下关于需求跟踪的叙述中，不正确的是：( )。
A 需求跟踪是为了确认需求，并保证需求被实现
B 需求跟踪可以改善产品质量
C 需求跟踪可以降低维护成本
D 需求跟踪能力矩阵用于表示需求和别的系统元素之间的联系链
需求跟踪是指跟踪一个需求使用期限的全过程，需求跟踪包括编制每个需求同系统元素之间的联系文档，这些元素包括其他类型的需求，体系结构，其他设计部件，源代码模块，测试，帮助文件等。需求跟踪为我们提供了由需求到产品实现整个过程范围的明确查阅的能力。
---
WBS最底层的工作单元被称为工作包。以下关于工作包的叙述中，正确的是( )。
A 可依据工作包来确定进度安排、成本估算等工作
B 工作包可以非常具体，也可以很粗略，视项目情况而定
C 如果项目规模很大，也可以将其分解为子项目，这时子项目可以认为是一个工作包
D 工作包的规模应该较小，可以在40小时之内完成
本题考查知识点工作包。
工作包是定义工作范围、定义项目组织、设定项目产品的质量和规格、估算和控制费用、估算时间周期和安排进度的基础。
业内一般把一个人2周能干完的工作称为一个工作包或把一个人80小时能干完的工作称为一个工作包。工作包的详细程度取决于项目的规模和复杂程度。
大型项目的WBS要首先分解为子项目，然后由各子项目进一步分解出自己的WBS。
---
在进行项目需求管理时，某需求的状态描述是“该需求已被分析，估计了其对项目余下部分的影响，已用一个明确的产品版本号或创建编号分配到相关的基线中，软件开发团队已同意实现该需求，则这个需求状态值是( )。
A 已建议
B 已验证
C 已实现
D 已批准
---
获取需求的办法包括问卷调查，会议讨论，获取原型；决策分析通常是在用在规划风险应对的时候，或者做项目可行性研究的时候。
---
项目范围说明书是对项目的定义。制定的项目范围说明书(初步)列出了项目及其相关的产品和服务的特性和边界，以及范围控制和接受的方法。项目范围说明书包括：项目和范围的目标、产品或服务的需求和特性、项目的边界、产品接受标准、项目约束条件、项目假设、最初的项目组织、最初定义的风险、进度里程碑、费用估算的量级要求、项目配置管理的需求、已批准的需要。
不包括：项目计划网络图
---
基准、基线、基准线，说的是同一回事。
范围基准是经过批准的范围说明书、工作分解结构(WBS)和相应的WBS词典，只有通过正式的变更控制程序才能进行变更，它被用作比较的基础。
---
某公司中标一个企业信息化系统开发项目，合同中该项目包括:人事系统、OA系统和生产系统。下图为项目经理制作的WBS，此处项目经理违反了关于WBS的(一个工作单元只能从属于某个上层单元 )原则。
题干图示不同的子系统下都有员工培训，违反了一个工作单元只能从属于某一个上层单元的分解原则
---
( )不属于范围变更控制的工作。
A 确定影响导致范围变更的因素，并尽量使这些因素向有利的方面发展
B 判断范围变更是否已经发生
C 管理范围变更，确保所有被请求变更按照项目整体变更控制过程处理
D 确定范围正式被接受的标准和要素
控制范围的活动包括：①影响导致范围变更的因素，并尽量使这些因素向有利的方面发展；②判断范围变更是否己经发生；③范围变更发生时管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理。确定范围正式被接受的标准和要素属于范围确认的活动。
---
Validate Scope is the process of formalizing acceptance of the completed ( ).
A project deliverables
B WBS
C activities
D milestones
确认范围是正式验收完成(项目可交付成果)的过程
project deliverables 项目交付成果
WBS 工作分解结构
activities 活动
milestones里程碑
---
( )is a document generated by the creating WBS process that support the WBS，which provides more detailed descriptions of the components in the WBS.
A The project charter
B The project scope statement
C The WBS dictionary
D The activity list
(WBS 词典)是由创建WBS过程生成的支持WBS的文档，WBS提供了对WBS中组件的更详细描述。
The project charter 项目章程
The project scope statement 项目范围说明书
The WBS dictionary WBS词典
The activity list 活动清单
---
在分解中应该注意到WBS是将项目的产品或服务、组织和过程这三种不同的结构综合项目分解结构的过程，逐层分解项目或者其主要交付成果的过程，实际上也是分派角色和职责的过程。具体来说，在分解的过程中，应该注意以下8个方面。 (1)WBS必须是面向可交付成果的。 (2) WBS必须符合项目的范围。 (3) WBS的底层应该支持计划和控制。 (4) WBS中的元素必须有人负责，而且只由一个人负责，尽管实际上可能需要多个人参与。 (5) WBS的指导。作为指导而不是原则，WBS应控制在4～6层。 (6) WBS应包括项目管理工作(因为管理是项目具体工作的一部分)，也要包括分包出去的工作。 (7) WBS的编制需要所有(主要)项目干系人的参与，需要项目团队成员的参与。 (8) WBS并非是一成不变的。
---
( )属于控制范围的活动。
A 与客户仔细讨论项目范围说明书，并请客户签字（属于范围确认）
B 当客户提出新的需求时，说服用户放弃新的需求（不合理）
C 确认项目范围是否覆盖了需要完成的产品或服务进行的所有活动
D 确认每项工作是否有明确的质量标准（属于质量控制）
---
( )includes the processes required to ensure that the project includes all the work required , and only the work required , to compete the project successfully . managing the project scope is primarily concerned with defining and controlling what is not included in the project.
A Create scope
B Project stakeholder management
C Preject scope management
D Project cost management
(项目范围管理)包括确保项目包括所有需要的工作以及只有所需的工作才能成功竞争项目所需的过程。管理项目范围主要涉及定义和控制未包含在项目中的项目。
Create scope 创建范围 Project stakeholder management 项目干系人管理 Preject scope management 项目范围管理 Project cost management 项目成本管理
---
需求管理包括在产品开发过程中维持需求一致性和精确性的所有活动；从测试用例和测试报告可得描述中追踪到用户原始需求的过程是反向追踪；需求跟踪矩阵中可以体现测试策略和测试场景的跟踪结果。
---
某公司决定在现有公文处理系统的基础上，新开发一个移动端APP，便于大家远程办公。项目经理召开工作会议，就工作分解结构提出了如下建议，其中( )是不妥的。
A 项目组所有人员都要参与，任务分解的层次控制在4至6层之间
B 对目前尚不清楚具体活动的模块可以使用规划包进行分解
C 项目干系人对完成的WBS给予确认，并达成共识
D 项目经理负责项目WBS分解，外包商负责外包合同WBS的分解
解析；WBS不是某个项目团队成员的责任，应该由全体项目团队成员、用户和项目干系人共同完成和一致确认。
---
( )是控制范围常用的工具和技术。
A 引导式研讨会
B 产品分析
C 偏差分析
D 标杆对照
解析：偏差分析是控制范围常用的工具和技术
---
(第2空)The ( ) process differs from the ( ) process in that the former is primarily concerned with acceptance of the deliverables, while the latter is primarily concerned with correctness of the deliverables.
A Perform Quality Assurance
B Validate Scope
C Control Quality
D Define Scope
() 过程与() 过程的不同之处在千前者主要关注可交付物的接受，而后者主要关注交付物的正确性。—— 质量控制
---
信息系统项目管理师（2022年）—— 重点内容：项目范围管理（5）相关推荐
- 软考高级信息系统项目管理师系列之三十一：项目变更管理
软考高级信息系统项目管理师系列之三十一:项目变更管理 一.项目变更管理内容 二.项目变更管理基本概念 1.项目变更管理定义 2.项目变更产生的原因 3.项目变更的分类 三.项目变更管理的原则和工作流程 ...
- 【信息系统项目管理师】第五章 项目范围管理（考点汇总篇）
[信息系统项目管理师]第五章 项目范围管理(考点汇总篇) ■考点分析与预测 项目范围管理一般上午考察3分,需求是龙头,是做项目管理的基础.没有需求就不能确定项目的范围,没有范围,项目就无从谈起,此部分 ...
- 软考高级信息系统项目管理师系列之九：项目范围管理
软考高级信息系统项目管理师系列之九:项目范围管理 一.范围管理输入.输出.工具和技术表 二.范围管理概述 三.规划范围管理 四.收集需求 1.收集需求: 2.需求分类 3.收集需求的工具与技术 4.收 ...
- 信息系统项目管理师---第十二章 项目采购管理
信息系统项目管理师-第十二章项目采购管理 采购管理过程说明: •规划采购管理:决定采购什么,何时采购.还包括制定采购 SOW,评价标准等 •实施采购.从潜在的供应商处获取适当的信息.报价.投标书或建议 ...
- 软考高级信息系统项目管理师系列之四十一：项目组合管理
软考高级信息系统项目管理师系列之四十一:项目组合管理 一.项目组合管理内容 二.项目组合管理基础概述 1.项目组合定义及相关知识图 2.项目组合.项目集和项目之间的关系 3.项目组合模块具备的特征 三 ...
- 【信息系统项目管理师】第12章-项目采购管理 知识点详细整理
个人资料,仅供学习使用 教程:信息系统项目管理师(第3版) 修改时间--2021年10月5日 00:46:49 参考资料: 信息系统项目管理师(第3版) 题目书(2021下半年)--马军 本文包括: ...
- 【信息系统项目管理师】第5章-项目范围管理 知识点详细整理
个人资料,仅供学习使用 教程:信息系统项目管理师(第3版) 修改时间--2021年10月1日 09:37:47 参考资料: 信息系统项目管理师(第3版) 题目书(2021下半年)--马军 本文包括: ...
- 【信息系统项目管理师】第4章-项目整体管理 知识点详细整理
个人资料,仅供学习使用 教程:信息系统项目管理师(第3版) 修改时间--2021年10月1日 08:51:54 参考资料: 信息系统项目管理师(第3版) 题目书(2021下半年)--马军 本文包括: ...
- 信息系统项目管理师-第5章：项目范围管理-重点汇总
一.范围管理概述 1.项目范围管理(Scope Management): 做范围内的事,而且只做范围内的事,既不少做也不多做,如果少做,会影响项目既定功能的实现:如果多做,会造成资源浪费 2.项目范围 ...
- 【信息系统项目管理师】第十一章 项目风险管理（考点汇总篇）
[信息系统项目管理师]第十一章 项目风险管理(考点汇总篇) 考点分析与预测 风险管理一般上午考察三分,风险管理也比较重要,在案例分析中出现的问题也比较多,风险在下午案例分析中仅考过一次.靠案例的几率小 ...
最新文章
- 职称计算机word模拟题,2015职称计算机考试Word2003模拟题及答案
- void*与int互转
- python知识：如何从图片的四周扩大一些尺寸
- 【深度学习】你心目中 idea 最惊艳的深度学习领域论文是哪篇？
- php运行socket服务器,PHP_php简单socket服务器客户端代码实例，本篇文章分享一个简单的socket - phpStudy...
- 机器人编程语言学习哪门最好？5大热门编程语言推荐
- CentOS系列启动流程和内核原理（5系列，6系列，7系列）
- 跟我一起学Redis之五种基本类型及其应用场景举例(干了6个小时)
- 定制适用于ARM平台的Ubuntu rootfs（根文件系统）
- Markdown 编辑器使用
- linux 文件读写锁,linux下的简单文件读写锁的操作
- Web API 2 对于 Content-Length 要求严格
- CDH5.14.0 安装失败，无法接受agent发出的检测信号
- PHP Class各种方法和类的使用
- xlsx表格怎么筛选重复数据_在Excel中怎样筛选以及删除重复的数据呢？
- vite 设置启动Network 为本地ip
- 智能型手机中的音频设计（转）
- vue.config.js 跨域配置
- python必备源代码-资源推荐｜347个Python开发经典资源推荐（42类）
- 干货 | 利用京东云Web应用防火墙实现Web入侵防护