搜索
内联网项目的工作分解结构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经验总结范围核实和需求变更策略接下来，为了确保项目组所理解的范围目标与客户期望的一致，共同设计并产出各种可交付成果，我们项目组会与客户密切合作，做好项目的范围核实工作。如图所以，分三个阶段进行第一，当完成范围说明书和需求采集之后，项目组成员和客户会通过会议或邮件等方式围绕系统的功能特性和服务等方面再次进行讨论。把包括产品说明、辅助说明、范围管理计划或特殊要求等文件确定下来，确认可交付成果。第二，在实施阶段中，利用专业化软件测验、检验等一系列活动来判断工作是否在范围以内，辅助项目范围核实管理。第三，当项目完成后，项目组成员和客户一起审查交付的成果，确保系统的正式完成，满足客户的需求，双方在验收书上签字作正式验收。我们都希望通过范围核实，使整个项目不发生太多的变更。但是，项目中出现变更是无法避免的，需求变更对项目成败有重要影响，既不能一概拒绝客户的变更要求，也不能一味地迁就客户，所以实施需求变更之前必须做好控制。为了有效控制需求更变，我们可以按如下几点去做：1、合同约束。需求变更给进销存实施带来的影响是有目共睹，所以在与用户签订合同时，可以增加一些相关条款，如限定用户提出需求变更的时间，规定何种情况的变更可以接受、拒绝或部分接受，还可以规定发生需求变更时必须执行变更管理流程。2、建立需求变更审批流程。明确变更审批环节、审批人员，规范变更流程，防止“无效变更”。有效的需求变更流程应该包括确认变更、评估变更的价值、分析变更对项目的影响，以及提交给双方高层进行评价以确定是否执行变更。变更请求必须有书面材料，当用户发现由于业务变化而引起的需求变更，需要提出书面申请。这样对所有的变更，双方的项目负责人都能做到心里有数。而且用户在递交书面变更申请时比较慎重，一般都在内部经过讨论后进行，这样减少了因用户内部看法不同导致的反复变更。3、对于零星变更，集中研究、批量处理。每周或每两周甚至每月召开一次需求变更专题会议，集中研究处理这些零碎变更事项，主动控制好工作节奏，尽量避免由于处理零碎变更而影响项目运行的总体进度。例如向客户正式提交一份各阶段需求变更的完成计划，注明变更引起的时间、成本、工期的代价和增加的工作量。要求客户配合需求变更计划，确定变更时限，控制变更规模，过时变更不候，离谱的变更不做，保大局弃小变。4、评估各种需求变更的影响。为了控制频繁的需求变更，通过合理沟通，要让客户认识到变更是有代价的，明确客户能否接受需求变更所引起的如进度延迟、费用增加、效率下降等负面后果。这样即可防止频繁变更，也让客户认识到不是所有的需求都需要变更，更不是所有的需求变更都需要立刻修改。5、变更记录上报双方领导。对所有需求变更做好记录，掌握主动权，营造正常的项目执行氛围。第六章根据之前指定的工作分解结构(WBS)，按照系统的生命周期将本项目划分为5个活动，分别是概念、系统设计、系统开发、推出测试、验收支持。对这5个活动进一步分解得到如下30个小活动，经我们团队集体讨论出各小活动之间顺序关系，在紧前活动栏注明序号，估算结果如下：其中计划的确定和模板的确定是在系统开发之前完成的工作，而整个项目监控和文档管理记录是贯穿于项目的始终的。因此我们在系统分析前增加了计划、模板确定两项活动，而在每项大活动完成时都有文档的撰写一项活动，通过对文档的评审来实现文档管理。项目监控在下表中虽然没有体现出来，但实际履行计划时是在每个小活动中都要进行的。定义员工需求工作分解结构（WBS）内联网项目概念系统设计推出测试验收支持调查研究定义需求制定项目计划定义具体功能系统分析模块设计数据库设计集成测试系统测试用户培训产品移交经验总结定义内容需求定义系统需求需求确认用户平台测试管理平台测试计划确定模板确定撰写计划报告美工设计撰写设计报告撰写测试报告系统开发数据库开发网页开发程序编写单元测试程序编写单元测试