大家好，又见面了，我是你们的朋友全栈君。
项目范围对项目的影响是决定性的，它确定了软件项目工作内容的多少。有效的范围管理可以保证项目只做必须做的事情，避免范围蔓延和做无用功，同时也避免不清晰的需求所导致的严重的系统缺陷。
本章内容提要
n 3.1 需求获取
n 3.2 范围定义
n 3.3 创建工作分解结构
n 3.4 范围确认
n 3.5 范围控制
n 3.6 案例分析
3.1 需求获取
n 需求获取工作的任务就是收集项目干系人的需求信息，为定义项目的范围奠定基础。
n 需求获取工作只能通过用户与开发人员之间进行高度的合作和交流才能成功。
n 在软件项目的需求获取活动中，一般要收集以下类别的用户需求：
n （ 1 ）界面需求：描述软件系统的外部特性，即系统如何从外部得到数据输入，如何向外部输出数据。
n （ 2 ）功能需求：列出软件系统必须完成的所有功能。
n （ 3 ）性能需求：响应时间、吞吐量、处理时间、存储空间等方面的限定。
n （ 4 ）质量需求：对安全性、保密性、可靠性、可维护性、可移植性、易用性等方面的要求。
n （ 5 ）资源使用需求：对硬件、支持软件、数据通信接口等方面的要求。
n （ 6 ）软件成本消耗与开发进度需求：即对时间和经济方面的要求。
n （ 7 ）异常处理要求：在运行过程中出现异常情况 ( 如临时性或永久性的资源故障，不合法或超出范围的输入数据、非法操作等 ) 时应采取的行动以及希望显示的信息。
获取需求的常用方法
n （ 1 ）访谈。访谈是通过与干系人直接交谈来获取信息。访谈的典型做法是向被访者提出问题，并记录他们的回答。访谈经常是一个访谈者和一个被访者之间的一对一谈话，但也可包括多个访谈者或多个被访者。访谈有经验的项目参与者、发起人、以及主题专家，有助于识别和定义项目可交付成果的特征和功能。
n （ 2 ）讨论会。讨论会把主要项目干系人召集在一起，通过集中讨论来定义项目需求。讨论会是快速定义跨职能需求和协调干系人差异的重要方法。由于群体互动的特点，被有效引导的讨论会有助于参与者之间建立信任、改善关系、改进沟通，从而有利于干系人达成一致意见。在每次讨论会中，都必须记录所讨论的内容，并在会后加以整理。在会前应提前发给参加人员有关讨论会的议题和内容等材料，以便有所准备。
n （ 3 ）观察用户工作流程。直接观察用户在其实际环境中怎样执行工作是一种行之有效的获取需求方法。当产品使用者难以清晰说明他们的需求时，就特别需要通过观察了解他们的工作细节。通常由观察者从外部来观看业务专家如何执行工作，也可由观察者实际执行一个流程或程序，来体验该流程或程序是如何实施的，以便挖掘隐藏的需求。
n （ 4 ）问卷调查。问卷调查是指设计一系列书面问题，向众多受访者收集信息。当需要调查大量人员的意见时，向被调查人分发调查问卷是一个十分有效的做法。经过仔细考虑写出的书面回答可能比被访者对问题的口头回答更准确。调查者应仔细阅读收回的调查表，然后再有针对性地访问一些用户，以便向他们询问在分析调查表时发现的新问题。
n （ 5 ）快速原型法。快速原型法是指在软件开发的早期快速建立目标软件系统的原型，并据此征求用户对需求的反馈。由于原型是可以操作的，它使得用户可以体验最终产品的模型，而不是仅限于讨论抽象的需求描述，从而可以获得更为准确和清晰的需求。快速原型法需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。在经过足够的反馈循环之后，就可以通过原型获得足够的需求信息。
分析和整理收集到的用户需求
n 对于用户提出的每个需求都要知道“为什么”，并判断用户提出的需求是否有充足的理由。
n 将那种以“如何实现”方式表达的需求转换为“实现什么”的方式。因为需求获取阶段关注“做什么”，而不是“怎么做”。
n 分析由用户需求衍生出的隐含需求，并识别用户没有明确提出来的隐含需求。
3.2 范围定义
n 范围定义就是制定项目和产品的详细描述，从而定义项目的范围。由于在获取需求过程中识别出的所有需求未必都包含在项目中，所以范围定义过程就是从所获取的需求中选取最终的项目需求，然后制定出项目及其产品的详细描述。
n 3.2.1 软件产品范围和项目范围
n 3.2.2 项目范围说明书
3.2.1 软件产品范围和项目范围
n 软件产品是项目的最终交付物，因此软件产品范围是软件项目范围中最重要的一部分。
n 在软件项目中，产品范围通常表现为软件需求规格说明书（ Software Requirements Specification, SRS ）。
SRS的内容
n （ 1 ）功能特征描述。即软件系统向使用者提供什么样的功能。
n （ 2 ）系统接口描述。即描述软件系统与其他软硬件系统之间的接口。在描述系统范围时，明确接口是非常必要的。
n （ 3 ）质量特征描述。主要的质量特征包括性能、可靠性、可移植性、机密性、可维护性等。不同程度的质量要求对项目的工作范围会有很大影响。
项目范围
n 项目范围包含产品范围，同时还包含更广泛的内容，项目中应展开的工作均属于项目范围，例如制定项目计划、编写文档、用户培训等。
3.2.2 项目范围说明书
n 项目范围说明书是范围定义的工作成果，它详细描述了项目的可交付成果，以及为创建这些可交付成果而必须开展的工作。在实际的软件项目中，可能不会出现一份叫做 《 项目范围说明书 》 的文档，但其中的内容可能会被多个文档包含，如 《 项目合同 》 、 《 项目计划 》 、 《 需求规格说明书 》 等。
项目范围说明书的内容
n （ 1 ）产品范围描述。即项目所创造的产品的特性。
n （ 2 ）验收标准。可交付成果通过验收前必须满足的一切条件。
n （ 3 ）可交付成果。在某一过程、阶段或项目完成时，必须产出的可核实的产品和成果。
n （ 4 ）项目的除外责任。通常需要识别出什么是被排除在项目之外的。明确说明哪些内容不属于项目范围，有助于管理项目干系人的期望。
n （ 5 ）制约因素。需要列举并描述与项目范围有关且会影响项目执行的各种内外部制约或限制条件。例如，客户或执行组织事先确定的预算，强制性日期或进度里程碑等。
n （ 6 ）假设条件。在制定计划时，一些未经验证就被视为正确、真实或确定的因素。对假设条件还应描述如果条件不成立，可能造成的潜在影响。
3.3 创建工作分解结构
n 创建工作分解结构就是把项目分解成具有内在联系的、更小、更详细、易于管理、易于控制的组成部分。通过创建工作分解结构，不仅使项目范围更为明确，而且为制定进度计划、成本计划等提供了基础。
n 工作分解结构 （ Work Breakdown Structure, WBS ）是对项目团队为实现项目目标、创建可交付成果而需实施的全部工作范围的层级分解。
WBS的结构
n WBS 组织并定义了整个项目范围，不在 WBS 中包括的工作就不是该项目的工作。
n WBS 是一个分级的树型结构，是对项目由粗到细的分解过程。工作结构每细分一个层次表示对项目元素更细致的描述。
n WBS 最低层次的组件被称为工作包，它是项目中最小的可控单元，它应当由唯一主体负责完成。同时，每个工作包又是一个可控制点，可以进行进度的监督和检查。
WBS的表示类型
创建WBS的方法
根据需求分析的结果和项目的相关要求，分解出WBS。常见的分解方法有三种：
n 类比法
n 自顶向下法
n 自底向上法
(1) 类比法
n 参考类似的已经完成的项目的 WBS 和以前的项目经验，根据当前项目特点做必要的调整，从而得到新项目的 WBS 。
n 一般来说，如果软件组织经常性地在某一行业或某一类产品中重复多个项目，则项目过程的重合度比较高，较适合采用类比法。
n 也可参照人们从大量实践中总结出的 WBS 模板。
WBS模板举例
(2) 自顶向下法
n 把项目从粗粒度的任务逐层细化，得到整个项目的分解结构。
(3) 自底向上法
n 通过将细粒度的工作逐层归纳而得到整个项目 WBS 的方法。
自底向上法
n 参加分解工作的人员根据自己的理解识别项目中的工作，尽可能详细地列出完成项目所涉及的各项具体的工作任务，然后对各项工作任务进行分类整合，归并到一个或者若干个更大的活动中，并构成 WBS 的上一级内容。
n 优点：通过自底向上归纳团队中不同成员的想法，更容易发挥团队的力量。
n 缺点：分解过程的投入太大，会花费较多的时间和成本。
几种任务分解方法的适用性
n 如果软件组织在同一应用领域做过多个类似的项目，则可以使用类比法。
n 自顶向下分解的质量直接决定于分解者对项目的理解，所以要求分解者经验丰富，对项目有深入理解和宏观上的把握。
n 自底向上法适用于那些具有创新性或不太熟悉的项目，更容易发挥团队的力量。
n 对于有些项目来说，可能需要综合应用这三种方法才能得到结构良好的 WBS 。
任务分解的策略
n 创建 WBS 时，对相同的项目存在着不同的分解策略，例如：
n 根据交付物进行分解
n 根据项目阶段进行分解
n 根据系统功能组成进行分解
（1）根据交付物进行分解
n 该策略是根据项目中必须产生的交付物来划分项目中的工作。
n 把项目的主要交付物（如需求规格说明书、概要设计说明书、软件包、测试报告、用户手册等）作为分解的第二层，确定整个 WBS 的架构，然后通过类比、自顶向下或自底向上的方法继续分解。
n 根据交付物逐层分解可以很自然地得到结构良好的 WBS ，不会遗漏项目必需的工作包。
（2）根据项目阶段分解
n 根据项目阶段分解就是首先确定整个项目必须经历的阶段，然后再逐步细化每一阶段工作的细目。
n 这种分解策略是从工程的角度进行项目分解，使 WBS 结构与项目工程过程较为一致。
n 但该策略对使用者的项目工程经验要求较高，项目工程经验不足则较容易遗漏项目中必须的工作包。
按照项目阶段进行分解
（3）按照产品的功能组成分解
对任务分解的要求
在创建WBS时，要注意分解的活动至少要满足四点要求：
n （ 1 ）分解出的工作对于完成上层相应交付物来说是必要且充分的。
n （ 2 ）工作的独立性。即工作一旦开始，就可以在不中断的条件下完成。
n （ 3 ）工作完成度的可判断性。即可以清楚地判断工作是否已经开始，工作完成了多少，以及工作是否完成。
n （ 4 ）工作的交付成果。即明确工作完成后将得到什么样的成果。
任务分解的注意事项
n （ 1 ）项目最底层的工作包要非常具体，任务分解的结果必须有利于责任分配，从而保证各工作包的负责人能够明确自己的具体任务，也便于项目的管理人员对项目的执行情况进行监督和业绩考核。
n （ 2 ）工作分解得越细致，对工作的规划、管理和控制就越有力，但是，过细的分解会造成管理工作的无效耗费，资源使用效率低下，工作实施效率降低。因此 WBS 的层数不宜太多，一般不超过 7 层。
n （ 3 ）对于最底层的工作包，一般要有详细和明确的文字说明，定义任务完成的标准。常常把所有工作包的文字说明汇集到一起，编成一个 WBS 字典（ WBS Dictionary ）。
3.4 范围确认
n 范围确认是指正式验收已完成的项目可交付成果，从而确认项目可交付成果是否可以让项目干系人满意。
n 范围确认工作一般由客户、发起人等关键项目干系人负责。
n 通常在进行范围确认前，项目组需要先进行质量控制工作，如系统测试等工作，以确保范围确认工作的顺利完成。
3.5 范围控制
n 项目范围的变更必然会造成项目进度计划、人员安排、成本等各方面的变化，处理不当则会增加项目风险，甚至造成项目陷入混乱的状态。
n 范围控制就是指监控项目的范围状态，管理范围变更。范围控制的目的是在出现范围变更需求后，管理相关的计划、资源安排以及项目成果，使得项目各部分可以很好地配合在一起，避免变更带来的负面影响。
n 未经控制的产品或项目范围的扩大被称为范围蔓延。变更是不可避免的，为防止范围蔓延，在每个项目上，都必须强制实施某种形式的变更控制。
n 范围控制通过变更控制系统和配置管理系统来完成。当出现范围变更需求时，通常要执行一个严格的变更控制流程。
n 变更实现涉及到配置项的修改，要遵守配置管理规范。
n 在项目初期就建立起完整的变更控制和配置管理的流程可以使项目在有序的变化中不断前进。
3.6 案例分析
n “ 软件缺陷管理和度量系统”的 SRS 和 WBS
本章内容小结
n 了解软件项目的需求分类，理解获取需求的常用方法。
n 了解软件项目产品范围和项目范围的一般内容。
n 理解 WBS 的概念，了解创建 WBS 的常用方法和创建 WBS 时的分解策略。
n 理解软件项目范围确认的任务。
n 理解范围控制的任务以及它与变更控制的关系。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/138786.html原文链接：https://javaforall.cn
