IT项目管理(第6版) 第5章作业.doc

内联网项目的工作分解结构 1.0 概念 1.1 调查研究 1.2 定义需求 1.2.1 定义员工需求 1.2.2 定义内容需求 1.2.3 定义系统需求 1.2.4 需求确认 1.3 定义具体功能 1.4 制定项目计划 1.4.1 计划确定 1.4.2 模板确定 1.4.3 撰写计划报告 2.0 系统设计 2.1 系统分析 2.2 模块设计 2.3 数据库设计 2.4 美工设计 2.5 撰写设计报告 3.0 系统开发 3.1 数据库开发 3.1.1 程序编写 3.1.2 单元测试 3.2 网页开发 3.2.1 程序编写 3.2.2 单元测试 4.0 推出测试 4.1 集成测试 4.1.1 用户平台测试 4.1.2 管理平台测试 4.2 系统测试 4.3 撰写测试报告 5.0 验收支持 5.1 用户培训 5.2 产品移交 5.3 经验总结 范围核实和需求变更策略 接下来，为了确保项目组所理解的范围目标与客户期望的一致需求变更对项目成败有重要影响，既不能一概拒绝客户的变更要求，也不能一味地迁就客户，所以实施需求变更之前必须做好控制。合同约束需求变更给进销存实施带来的影响是有目共睹，所以在与用户签订合同时，可以增加一些相关条款，如限定用户提出需求变更的时间，规定何种情况的变更可以接受、拒绝或部分接受，还可以规定发生需求变更时必须执行变更管理流程。建立需求变更审批流程有效的需求变更流程应该包括确认变更、评估变更的价值、分析变更对项目的影响，以及提交给双方高层进行评价以确定是否执行变更。变更请求必须有书面材料，当用户发现由于业务变化而引起的需求变更，需要提出书面申请。这样对所有的变更，双方的项目负责人都能做到心里有数。而且用户在递交书面变更申请时比较慎重，一般都在内部经过讨论后进行，这样减少了因用户内部看法不同导致的反复变更。对于零星变更，集中研究、批量处理每周或每两周甚至每月召开一次需求变更专题会议，集中研究处理这些零碎变更事项，主动控制好工作节奏，尽量避免由于处理零碎变更而影响项目运行的总体进度。例如向客户正式提交一份各阶段需求变更的完成计划，注明变更引起的时间、成本、工期的代价和增加的工作量。要求客户配合需求变更计划，确定变更时限，控制变更规模，过时变更不候，离谱的变更不做，保大局弃小变。评估各种需求变更的影响这样即可防止频繁变更，也让客户认识到不是所有的需求都需要变更，更不是所有的需求变更都需要立刻修改。(WBS)，按照系统的生命周期将本项目划分为5个活动，分别是概念、系统设计、系统开发、推出测试、验收支持。对这5个活动进一步分解得到如下30个小活动，经我们团队集体讨论出各小活动之间顺序关系，在紧前活动栏注明序号，估算结果如下： 其中计划的确定和模板的确定是在系统开发之前完成的工作，而整个项目监控和文档管理记录是贯穿于项目的始终的。因此我们在系统分析前增加了计划、模板确定两项活动，而在每项大活动完成时都有文档的撰写一项活动，通过对文档的评审来实现文档管理。项目监控在下表中虽然没有体现出来，但实际履行计划时是在每个小活动中都要进行的。  单元测试 程序编写 单元测试 程序编写 网页开发 数据库开发 系统开发 撰写测试报告 撰写设计报告 美工设计 撰写计划报告 模板确定 计划确定 管理平台测试 用户平台测试 需求确认 定义系统需求 定义内容需求 经验总结 产品移交 用户培训 系统测试 集成测试 数据库设计 模块设计 系统分析 定义具体功能 制定项目计划 定义需求 调查研究 验收支持 推出测试 系统设计 概念 内联网项目 工作分解结构（WBS） 定义员工需求