项管（九）——项目范围管理

·里程碑：在每个分解单元中都存在可交付的成果和里程碑。里程碑标志着某个可交付成果或者阶段的正式完成。里程碑和可交付成果紧密联系在一起，但并不是一个事物。可交付成果可能包括报告、原型、成果和最终产品。而里程碑则关注于是否完成。

·工作包：位于WBS每条分支的最底层的可交付成果或项目工作组成部分。工作包的大小应该是8-80个小时能够完成。

·控制帐户：简称CA，是一种管理控制点，是工作包的规划基础。在该控制点上，把范围、成本和进度加以整合，并把它们与挣值相比较，以测量绩效。控制帐户设置在工作分解结构的特定管理节点上。每一个控制帐户都可以包括一个或多个工作包，但是每一个工作包只能属于一个控制帐户。

·规划包：在控制帐户之下（工作包之上），工作内容已知但尚缺详细进度活动的WBS组成部分。规划包是暂时用来做计划的。随着情况的逐渐清晰，规划包最终将被分解成工作包以及相应的具体活动。

·WBS词典：制作WBS过程中，要给WBS的每个部分一个帐户编码，它们是成本、进度和资源使用信息汇总的层次结构。需要生成一些配置文件，这些文件要和WBS配合使用，称为WBS词典，也称为WBS词汇表，WBS词典可能包括：帐户编码、工作描述、假设条件、制约因素、负责人或组织单元、进度里程碑、相关的进度活动、所需要的资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等。

·创建WBS分解的原则：1、功能或技术原则；2、组织结构原则；3、系统和子系统原则；

·WBS表示形式主要有树型结构和表格形式，树形结构图的WBS层次清晰、直观性和结构性强，但不容易修改，对大的复杂的项目很难表示出项目的全貌；表格形的直观性较差，但能够反映出项目所有的工作要素。也有『鱼骨式的』，但不常用。

·创建WBS的分解过程中应该注意8个方面： 

1、WBS必须是面向可交付成果的；

2、WBS必须符合项目的范围；

3、WBS底层应支持计划和控制；

4、WBS中的元素必须有人负责；

5、WBS一个工作单元只能从属于某个上层单元，避免交叉重属；

6、WBS应该包括项目管理工作，也要包括分包出去的工作；

7、WBS的编制需要所有（主要）项目干系人的参与；

8、WBS并非是一层不变的。

·确认范围：是正式验收项目已完成的可交付成果的过程；

·软件需求工程的活动分为五个独立阶段：

1、需求获取：通过与用户交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求；

2、需求建模：为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义；

3、形成需求规格：生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约；

4、需求验证：以需求规格说明书为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性，包含有效性检查，一致性检查，可行性检查和确认可验证性；

5、需求管理：支持系统的需求演进，如需求变化和可跟踪性问题；

·需求管理的需求状态：

1、已建议：该需求已被有权提出需求的人建议；

2、已批准：该需求已被分析，估计了其对项目余下部分的影响（包括成本和对项目其余部分的干扰），已用一个确定的产品版本号或创建编号分配到相关的基线中，软件开发团队已同意实现该项需求；

3、已实现：已实现需求代码的设计、编写和单元测试；

4、已验证：使用选择的方法已验证了实现的需求，例如测试和检测，审查该需求跟踪与测试用例相符。该需求现在被认为完成。

5、已删除：计划的需求已从基线中删除，但包括一个原因说明和做出删除决定的人员；

·物料清单：用于描述生产一个产品所需的实际部件、组件和构件的分级层次表格；

项目的范围基准：被批准的详细的项目范围说明书和与之相关的WBS及WBS字典作为项目的范围基准，并在整个项目的生命周期内对之进行监控、核实和确认；

·范围变更的主要内容：

1、影响导致范围变更的因素，并尽量使这些因素向有利的方面发展；

2、判断范围变更是否已经发生；

3、范围变更发生时管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理；

·确认范围与质量控制区别：

1、确认范围强调可交付成果获得客户或发起人的接受；质量控制强调可交付成果的正确性，并符合为其制定的具体质量要求；

2、质量控制一般在确认范围之前进行，也可以同时进行；确认范围一般在阶段末尾进行；

3、质量控制属内部检查；确认范围则是由外部干系人对项目可交付成果进行检查验收；