第4章IT项目范围管理

第4章IT项目范围管理项目范围管理概述4.1项目范围规划与范围定义4.2项目工作分解结构技术4.3项目范围核实与控制4.4学习目标：1．了解做好项目范围管理的意义2．理解并掌握项目范围与范围管理的基本概念3．理解IT项目范围与质量、时间和成本的关系4．掌握工作分解结构技术5．掌握需求管理与范围定义的方法与过程6．理解控制IT项目范围变更的过程4.1项目范围管理概述4.1.1项目范围与范围管理项目范围管理的过程包括以下内容。（1）收集需求。（2）范围定义。（3）创建工作分解结构（WorkBreakdownStructure，WBS）。（4）范围核实。（5）范围变更控制。4.1.2IT项目范围管理的重要性（1）提高费用、时间和资源估算的准确性。（2）确定进行测量和控制的基准。（3）有助于项目分工。4.2项目范围规划与范围定义4.2.1项目范围规划的编制1．编制范围规划的依据（1）环境因素（2）组织过程资产（3）项目章程（4）项目初步范围说明书2．项目范围管理计划4.2.2收集项目需求1．收集需求的依据2．收集需求的工具与技术（1）访谈。（2）焦点小组会议。（3）引导式研讨会。（4）名义小组法。（5）群体决策技术。（6）观察法（7）原型法。3．收集需求的输出业务需求。可跟踪业务目标和项目目标。功能需求，描述业务流程、信息以及与产品的内在联系。非功能性要求，如服务水平、合规性、安全、保障能力等。质量要求。验收标准。体现组织指导原则的业务原则。对组织内部和外部团体的影响。对支持和培训的需求。与需求有关的假设条件和制约因素。4.2.3项目范围定义1．范围定义的依据（1）项目已有的各种文件。（2）项目范围定义中收集的信息。2．范围定义的技术（1）产品分析。（2）备选方案识别技术。（3）专家评定。3．IT项目范围说明书（1）项目目标与项目范围指标。（2）产品描述。（3）项目可交付成果的规定。（4）约束条件。（5）假定。（6）项目配置关系及其管理要求。4.2.4软件项目的需求管理1．定义需求2．需求确认3．建立需求状态状态值定义已建议该需求已被有权提出需求的人建议已批准该需求已被分析，估计了其对项目余下部分的影响，已用一个确定的产品版本号或创建编号分配到相关基线中，开发团队已同意实现该需求已实现已实现需求代码的设计、编写和单元测试已验证使用所选择的方法已验证了实现的需求，如测试和检测，审查该需求跟踪与测试用例相符已删除计划的需求已从基线中删除，但包括一个原因说明和作出决定的人员表4-1需求状态表4．需求评审制订评审计划。需求预审查。召开评审会议。调整需求文档。重审需求文档。5．需求承诺6．需求跟踪正向跟踪。逆向跟踪。跟踪需求的过程包括以下内容。从需求到业务需求、机会、目的和目标。从需求到项目目标。从需求到项目范围/WBS中的可交付成果。从需求到产品设计。从需求到产品开发。从需求到测试策略和测试脚本。从宏观需求到详细需求。7．需求变更控制4.3项目工作分解结构技术4.3.1工作分解结构1．图表形式图4-2工作分解结构图分解层次与结构。WBS编码设计。2．清单形式1．需求分析计划2．流程优化3．编写需求说明书3.1编写需求规格词汇表3.2绘制业务流程3.3抽象业务类3.4建立数据模型3.5将需求分析图示加入规格文档4．需求规格测试5．需求规格确认4.3.2工作分解的过程1．分解的标准基于成果或功能的分解方法，以完成该项目应该交付的成果为导向，确定相关的任务、工作、活动和要素。基于流程的分解方法，以完成该项目所应经历的流程为导向，确定相关的任务、工作、活动和要素。2．分解步骤（1）确认并分解项目的主要要素。（2）确定分解标准。（3）确认分解是否详细，分解结果是否可以作为费用和时间估计的标准，明确责任。（4）确定项目交付成果。（5）验证分解正确性。3．分解结果的检验任务分解后，需要核实分解的正确性。更底层次的细目是否必要和充分？如果不必要或者不充分，这个组成要素就必须重新修改（增加、减少或修改细目）。最底层的工作包是否有重复？如果存在重复现象就应该重新分解。每个细目都有明确的、完整的定义吗？如果不是，这种描述需要修改或补充。是否每个细目可以进行适当的估算？谁能担负起完成这个任务？如果没有，修正是必要的，目的是提供一个充分的管理控制。4．任务分解的注意事项要清楚地认识到，确定项目的分解结构就是将项目的产品或服务、组织、过程这3种不同的结构综合为项目分解结构的过程，也是给项目的组织人员分派各自角色和任务的过程。应注意收集与项目相关的所有信息。项目最底层的工作要具体，而且要完整无缺地分配给项目内外的不同个人或者组织，以便于明确各个工作的具体任务、项目目标和所承担的责任，也便于项目的管理人员对项目的执行情况进行监督和业绩考核。任务分解结果必须有利于责任分配。对于最底层的工作包，一般要有全面、详细和明确的文字说明，并汇集编制成项目工作分解结构词典，用以描述工作包、提供计划编制信息（如进度计划、成本预算和人员安排），以便于在需要时随时查阅。并非工作分解结构中所有的分支都必须分解到同一水平，各分支中的组织原则可能会不同。任务分解的规模和数量因项目而异，先分解大块任务，然后再细分小的任务，最低层是可控和可管理的，避免不必要的过细，最好不要超过7层。按照IT项目的平均规模来说，推荐任务分解时至少分解到一周的工作量（40个小时）。4.4项目范围核实与控制4.4.1项目范围核实确定需要进行范围核实的时间。识别范围核实需要哪些投入。确定正式被接受的标准和要素。确定范围核实会议的组织步骤。组织范围核实会议。4.4.2项目范围控制1．IT项目范围变更的原因分析项目的生命周期。项目的组织。项目经理的素质。2．对范围变化的控制（1）范围变更控制实施的基础和前提。进行工作任务分解。提供项目实施进展报告。提出变更要求。项目管理计划。（2）范围变更控制的工具和技术。范围变更控制系统。偏差分析。补充规划。配置管理系统。3．项目范围变更控制的作用合理调整项目范围。纠偏行动。总结经验教训。4．IT项目范围变更控制过程提交变更请求：变更请求应被记录，并提交给CCB。复审变更请求：在CCB复审会议中对变更请求进行初始复审，以确定是否为有效请求。安排或分配工作：对于确认并批准的变更请求，实施工作分配和安排。进行变更：对需要采取措施的地方确定应采取的具体措施。核实或测试工作版本中的变更。发布工作版本中的变更。估计所采取的纠正措施的效果，如果所采取的纠正措施仍无法获得满意的范围调整，则重复以上步骤。