ch3 信息系统项目的范围管理.ppt

3 信息系统项目的范围管理 3.1 信息系统项目的范围 3.2 范围规划 3.3 范围定义 3.4 制作工作分解结构 WBS 3.5 范围确认 3.6 范围控制 3.1 信息系统项目的范围 在实践中，项目的“需求蔓延”是信息系统项目失败最常见的原因之一，信息系统项目往往在信息系统项目启动、计划、执行甚至收尾时不断加入新功能，无论是客户的要求还是项目实现人员对新技术的试验，都可能导致信息系统项目范围的失控，从而使信息系统项目在时间、资源和质量上都受到严重的影响。 3.1 信息系统项目的范围 项目的范围:项目范围指为了成功地实现项目目标所必须完成的、全部且最少的工作 项目范围包含两类： 产品范围Product Scope 信息系统产品或者服务所应该包含的功能 根据产品的需求确定产品范围的完成情况 项目范围Project Scope 项目范围是指为了能够交付信息系统项目所必须要做的工作 根据项目计划来确定项目范围的完成情况 项目范围管理定义 定义和控制项目包括什么与不包括什么的过程 3.1 信息系统项目的范围 范围管理的重要性 我们至少要做什么？ --需求不清晰是很多IT项目失败的主要原因 --需求不清晰导致估计不准确，估计不准确导致项目的实际运行状况与计划偏差很多 从源头把握范围的准确 --项目干系人必须在项目要产出什么样的产品方面达成共识，也要在如何生产这些产品方面达成一定的共识 3.2 项目范围规划 制定项目范围管理计划，记载如何确定、核实与控制项目范围以及如何制定与定义工作分解结构(WBS)。 3.2 项目范围规划 项目范围管理计划的内容有: 根据项目初步范围说明书编制详细项目范围说明书的一个过程； 能够根据详细的项目范围说明书制作工作分解结构， 并确定如何维持与批准该工作分解结构的一个过程； 规定如何正式核实与验收项目已完成可交付成果的一个过程; 控制详细项目范围说明书变更请求处理方式的一个过程。 该过程同整体变更控制过程有直接联系。 3.3 项目范围定义 制定详细的项目范围说明书，作为将来项目决策的根据。 范围定义是指将项目主要可交付成果细分成较小的、更容易管理的部分。 范围定义最重要的任务是详细定义项目范围边界 项目小组应该把工作时间和资源放在范围边界之内 工作分解结构 WBS 工作分解的过程 将一个项目分解为更多的工作细目或者子项目，使项目变得更小、更易管理、更易操作。 WBS 面向可交付成果的。 Work packages（工作包） WBS的最低层次的可交付成果 WBS的分解原则 对项目的各项活动按实施过程，产品开发周期或活动性质等分类。 在分解任务的过程中不必考虑工作进行的顺序。 不同的项目分解的层次不同，不必强求结构对称。 把工作分解到能以可靠的工作量估计为止。 在确定最低一级的具体工作时，应能分配给某个或某几个人具体负责。 工作分解结构的表示形式---树形图 工作分解结构的表示形式---缩进图 工作分解结构 工作编号 工作名称 负责人 资源描述 1.1.0 系统分析 ? ? 1.1.1 需求分析 ? ? 1.1.2 方案设计 ? ? 1.2.0 系统设计 ? ? 1.2.1 网络系统设计 ? ? 1.2.2 数据库设计 ? ? 1.3.0 系统开发 ? ? 1.3.1 软件开发 ? ? …… …… ? ? 工作分解结构的创建方法 类比 自上而下法（系统思考法） 发散归纳法 （头脑风暴法） 模板参照法 任务结构分解(WBS)步骤 得到范围说明书或工作说明书 召集有关人员，集体讨论所有主要项目工作，确定项目确定分解方法 分解项目工作。尽量利用项目分解模板。 画出WBS层次结构图。WBS较高层次上的工作可以定义为子项目或子生命周期阶段 将主要项目可交付成果细分为更小的、易于管理的工作包。 验证分解的正确性，如果发现较低层的工作项没有必要，则修改组成部分 建立ＷＢＳ编号 随着其他活动的进行，不断的对WBS进行更新或修正，直到覆盖所有工作。 分解标准 生存期 功能组成 分解标准应统一 学生管理 按照生命期分解 规划 需求 设计 编码 测试 提交 按照产品组成分解 1.1????????招生管理 1.2?????????分班管理 1.3?????????学生档案管理 1.4?????????学生成绩管理 分解标准应统一 不能同时使用两种标准进行分解 招生管理 ?分班管理 ?学生档案管理 学生成绩管理 规划 需求 设计 编码 测试 提交 检验分解结果的标准 最底层的要素是否是实现目标的充分必要条件 最底层要素是否有重复的 每个要素是否清晰完整定义 最底层要素是否有定义清晰的责任人,是否可以进行成本估算和进度安排 George and