软考-项目范围管理(九)

9.1.1产品范围和项目范围 (P272)

在项目环境中，“范围”这一术语有两种含义:(项目范围包含产品范围，因为要做产品)

产品范围:指某项产品、服务或成果所具有的特征和功能。产品范围的完成情况是根据产品需求来衡量的。“需求”是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。
项目范围:包括产品范围，是为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范里的完成情况是根据项目管理计划来衡量的。

9.2项目范围管理过程 (P272)

9.2.1过程概述

项目范围管理过程包括:

规划范围管理:(一群人一起写一个计划，一个指南) 为了记录如何定义、确认和控制项目范围及产品范围，创建范围咎理计划。
收集需求:(写需求清单记录) 为了实现项目目标确定、记录并管理干系人的需要和需求。
定义范围: (从需求清单里而找到要做的，和排除做不了的) 制定项目和产品详细描述。
创建WBS: (大事化小，小事化了) 交付成果和项目工作分解为较小的、更易于处理的组件。
确认范围: (确认一下收货，就是验收) 正式验收己完成的项目可交付成果。
控制范围: (看看用方有没有耍无赖) 监督项目和产品的范围状态、管理范围基准的变更。

9.3.1输入 (总结归纳子计划的通用输入: 二项事组)

1.项目章程
项目章程记录项目目的、项目概述、假设条件、制约因素以及项目想要实现的高层级的需求。
2.项目管理计划
3.事业环境因素
4.组织过程资产

9.3.2工具与技术

1.专家判断(通用技术、三人行必有我师)
2.数据分析:适用于本过程的数据分析技术是备选方案分析。
3.会议
项目团队可委加项目会议来制订范围管理计划。参会者包括项目经理、项目发起人、选定的项目团队成员、选定的干系人、范围管理各过程的负责人以及其他必要人员

9.3.3输出(区分范围和需求管理计划)

1.范围管理计划
范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。范围管理计划用于指导如下过程和相关工作:
1)制定项目范围说明书;
2)根据详细项目范围说明书创建WBS;
3)确定如何审批和维护范围基准;
4)正式验收已完成的项目可交付成果;
根据项目需要，范围管理计划可以是正式或非正式的，非常详细或高度概括的。
2.需求管理计划
需求管理计划是项目管理计划的组成部分，描述如何分析、记录和管理需求。
需求管理计划的主要内容包括:
1)如何规划、跟踪和报告各种需求活动;
2)配置管理活动，例如，如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限;
3)需求优先级排序过程;
4)测量指标及使用这些指标的理由;
5)反映哪些需求属性将被列入跟踪矩阵等。

项目管理计划
收集需求中使用的项目管理计划组件包括:

范围管理计划:包含如何定义和制定项目范围的信息
需求管理计划:包含如何收集、分析和记录项目需求的信息。
干系人参与计划:从该计划中了解干系人的沟通需求和参与程度，以便评估并适应干系人对需求活动的参与程度。

项目文件
协议:协议会包含项目和产品需求
事业环境因素
组织过程资产

9.4.2工具与技术

1.专家判断(三人行必有我师，你行你上)
2.数据收集
可用于收集需求过程的数据收集技术主要包括:

头脑风暴: 是一种用来产生和收集对项目需求与产品需求的多种创意的技术。
访谈:是通过与干系人直接交谈，来获取信息的正式或非正式的方法。访谈的典型做法是向被访者提出预设和即兴的问题，并记录他们的回答。访谈经常是一个访谈者和一个被访者之间的“一对”谈话，但也可包括多个访谈者或多个被访者。访谈有经验的项目参与者、发起人和其他高管及主题专家，有助于识别和定义所需产品可交付成果的特征和功能。访谈也可用于获取机密信息
焦点小组:是召集预定的干系人和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比“一对一”的访谈更热烈。
问卷调查;是指设计一系列书面问题，向众多受访者快速收集信息。问卷调查方法非常适用于受众多样化，需要快速完成调查，受访者地理位置分散并且适合开展统计分析的情况。
标杆对照:将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较、以便识别最佳实践、形成改进意见，并为绩效考核提供依据。标杆对照所采用的可比组织可以是内部的，也可以是外部的(P279 考1分选题)

1.数据分析
可用于收集需求过程的数据分析技术是文件分析。文件分析指审核和评估任何相关的文件信息。在此过程中，文件分析用于通过分析现有文件，识别与需求相关的信息来获取需求，可供分析并有助于获取需求的文件包括:协议;商业计划;业务流程或接口文档;业务规则库;现行流程;市场文献;问题日志;政策和程序、法规文件，如法律、准则、法令等;建议邀请书;用例等
2.人际关系与团队技能
可用于收集需求过程的人际关系与团队技能主要包括:

名义小组技术:是用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。名义小组技术是一种结构化的头脑风暴形式。
观察和交谈:是指直接察看个人在各自的环境中如何执行工作(或任务)和实施流程。当产品使用者难以或不愿清晰说明他们的需求时，特别需要通过观察来了解他们的工作细节。观察也称为“工作跟随”，通常由旁站观察者观察业务专家如何执行工作，但也可以山"参与观察者”来观察，通过实际执行一个流程或程序，来体验该流程或程序是如何实施的，以便挖掘隐藏的需求。
引导: (跨部门)引导与主题研讨会结合使用，把主要干系人召集在一起定义产品需求。研讨会可用于快速定义跨职能需求并协调干系人的需求差异。因为具有群体互动的特点，有效引导的研讨会有助于参与者之间建立信任、改进关系、改善沟通，从而有利于干系人达成一致意见。此外，与分别召开会议相比，研讨会能够更早发现并解决问题。

7.系统交互图
系统交互图是对产品范围的可视化描绘，可以直观显示业务系统(过程、设备、计算机系统等) 及其与人和其他系统(行动者) 之间的交互方式。

8.原型法(建筑机型，3D建机，2D建机)
原型法是指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。原型包括微缩产品、计算机生成的二维和三维模型、实体模型或模拟。因为原型是有形的实物，它使得干系人可以体验最终产品的模型，而不是仅限于讨论抽象的需求措述。原型法支持渐进明细的理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。在经过足够的反馈循环之后，就可以通过原型获得足够的需求信息，从而进入设计或制造阶段。

需求的类别一般包括:

业务需求:整个组织的高层级需要，例如，解决业务问题或抓住业务机会，以及实施项目的原因。
干系人需求:干系人的需要。
解决方案需求: 为满足业务需求和干系人需求，产品、服务或成果必须具备的特性、功能和特征。解决方案需求又进一步分为功能需求和非功能需求:
(1)功能需求:描述产品应具备的功能，例如，产品应该执行的行动、流程、数据和交互:
(2)非功能需求:是对功能需求的补充，是产品正常运行所需的环境条件或质量要求，例如，可靠性、保密性、性能、安全性、服务水平、可支持性、保留或清除等。
过渡和就绪需求; 如数据转换和培训需求。这些需求描述了从“当前状态”过渡到“将来状态”所需的临时能力。
项目需求:项目需要满足的行动、过程或其他条件，例如里程碑日期、合同责任、制约因素等。
质量需求:用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准，例如，测试、认证、确认等。

1.需要检查的问题
项目干系人进行范围确认时，一般需要检查以下6个方面的问题:

可交付成果是否是确定的、可确认的。
每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件，例如，客户的书面认可等
是否有明确的质量标准:可交付成果的交付不但要有明确的标准标志，而且要有是否按照要求完成的标准，可交付成果和其标准之间是否有明确联系。
审核和承诺是否有清晰的表达: 项目发起人必须正式同意项目的边界，项目完成的产品或者服务，以及项目相关的可交付成果。项目团队必须清楚地了解可交付成果是什么。所有的这些表达必须潜晰，并取得一致的同意。
项目范围是否覆盖了需要完成的产品或服务的所有活动，有没有遗漏或错误。
项目范围的风险是否太高:管理层是否能够降低风险发生时对项目的影响。
2.干系人关注点的不同
管理层主要关注项目范围;
客户主要关注产品范围;
项目管理人员主要关注项目制约因责;
项目团队成员主要关注项目范围中自己参与的元素和负责的元素.