《软考论文 项目范围管理》由会员分享，可在线阅读，更多相关《软考论文 项目范围管理（4页珍藏版）》请在金锄头文库上搜索。
1、软考论文软考论文: 项目范围管理项目范围管理摘要: 该文章是我参加信息系统项目管理师考试的一篇练习之作,大概用了两个小时时间,仓促的完成该论文的写作,当时还自我感觉良好.对我的文字功底孤芳自赏好一段时间.当参加完考试之后,回头看这篇论文,才发现这篇论文写的有多烂,内容粗制滥造不说,整体上给人感觉不实,有造假的嫌疑.本来不想把这篇论文展示给大家的,但想想,这总算是我的劳动成果,也凝聚着我两个小时的汗水和智慧,因此,特发表出来,还望各位同行不啬赐教,给点批评,督促我继续上进.某企业是一个大型的中外合资企业,旗下 8 个子公司，主要经营手机业务，冰箱洗衣机等白电业务、配套配件生产业务、网络产品业务。
2、企业以冰箱、洗衣机、手机为主营业务，其他的为辅业。总公司主要做业务规划，市场调研，营销，产品开发等工作，子公司则根据总公司下达的生产任务进行组织生产。 2002 年，公司耗时近两年，花巨资打造了一套 ERP 系统，但该 ERP 系统未能满足公司的战略目标和业务目标的要求，现在，除了 ERP 中的物料管理模块还在运行外，其他功能基本被废弃，现在还在使用 1998 年建设的 MRPII 系统。但随着公司规模的不断扩张，业务范围不断拓展，原来的信息系统已经无法再满足企业的目前业务需求，因此，企业急需升级现在的信息系统。2007 年 4 月，我作为承建方合同中的项目经理，组织和实施了该企业的信息系统建
3、设。由于该企业涉及的业务领域比较多，跨行业跨学科，各子公司分布全国各地，销售网络遍布全国各地，信息分布散，功能要求各异，错综复杂，管理困难，所从事的又是科技含量高的行业，对信息的依赖性比较强，加上建设方由于有上次失败的 ERP，对这次的开发工作的工期，成本，质量要求相当苛刻，这些都给项目建设的成功蒙上了阴影，项目的前景面临很大的风险，而项目的范围管理也就成为我作为项目经理的重要工作。项目的范围，是指为了完成具有所规定的特征和功能的产品必须完成的工作。项目的范围管理，包括为完成项目所需要的一系列活动，以确保项目包含且仅仅包含项目所必须完成的工作。首先，我们根据历史数据和初步的项目开发计划，利用模
4、板工具，制定一个范围管理计划。内容包括制定软件开发功能设计规范的过程和方法，创建 WBS 的过程，详细说明已完成的开发结果如何得到正确的确认和认可，以及范围控制管理的一些规程和制度。软件功能范围管理的第一步，就是对软件功能的分析总结，即软件开发的功能需求分析。功能需求是描述一个产品或项目应该做什么，应该提供什么功能，那些功能是必须的，那些功能不属于项目的范围。功能需求分析的不正确，将导致系统涉及的漏洞和错误，保证与用户对需求理解的一致性，可以减少客户对需求进行变更的频度，模糊不清的功能需求只能造成时间，成本的浪费，最终影响项目的目标。在项目实施过程中，我们主要从 8 个方面来考量用户的需求的：
5、业务的需求、使用者的需求、功能需求、性能需求、质量需求、系统需求、非功能需求，以及开发的局限。由于篇幅和时间的限制，本文只对我在项目管理的主要需求分析过程进行论述。我们软件开发企业的市场人员，以及签订软件开发合同的领导，他们对建设方的真正使用方案，在认识上有很大的不同，因此，作为软件开发者，我们首要任务就是获取软件系统中，不同的使用者对信息的不同需求。对于先前失败的 ERP 项目，我们详细的分析了失败的原因，主要是：需求分析不到位，没有能够满足企业高层领导在宏观决策上的信息需求，虽然满足了中层领导的信息需求，但是界面设计粗糙，使得中层领导对开发的软件抱有成见，设计缺乏人性化，缺乏对底层用户的培
6、训，一般工作人员直接抵制使用软件，加上软件在使用过程中，也确实出现了质量问题，这又成了他们抵制新开发的软件的口实，最终导致新开发的软件被废弃，造成公司的巨大损失。由于有前车之鉴，我们加强了对不同层次使用软件的用户分别作需求获取。我们对不同层次的用户采取直接进行访谈，调查表的形式，借助 Rose 软件，以简单，直观的图形化方式，对用户的需求进行描述。对用户的每一需求，我们都建立一个使用方案来描述，对系统解决用户的某一个问题所必须具备的功能，性能，使用方法，具体步骤，使用界面都作了详细的描述。针对用户对软件的质量需求，我们是从软件的可靠性、效率性、安全性、健壮性、可维护性和可测试性几个方面来来进行
7、的。我们从分析建设方现有的系统出发，深入企业内部的各个层次，深入了解用户对软件的各个方面的质量要求，并把这些要求，做到有具体的数值，可量化，可验证。我们经过对建设方的各个方面的需求进行分析和获取，形成了了软件开发需求分析总结书的报告文件，详细地描述了用户在不用方面对软件的要求，然后根据这份报告文件，对用户的需求进行功能设计，最终完成了软件开发功能设计规范。设计规范，详细描述了所开发的软件应该满足用户的应有的功能，定义了开发项目的目标，项目成功的标准，项目的边界，可交付物，进度里程碑，项目的约束条件以及假设条件等。并组织开发方和建设方的客户代表、建设方的主管领导，对软件开发功能设计规范进行评审确
8、认，评审通过的设计规范，将作为合同的附属文件，将指导和规范软件设计开发的所有工作，他是软件开发的纲领性文件。完成需求分析后，我们组织主要开发人员，利用模板，历史开发资料，按照项目的每个阶段的里程碑和阶段开发成果，自顶向下的对开发项目进行分解，把每个阶段的任务分解成便于管理和控制工作包，经过对 WBS 的评审和确认，保证 WBS 的分解是充分和必要的，每个工作包都是独立的，可以单独进行开发和验证，完成后 WBS 后，我们还对每个工作包进行时间的估算和成本的估算，并对每个工作包指派责任人。因为信息系统项目的特点，整个开发过程我们都面临着各种各样的需求变化，这些变化，都直接或间接的影响着项目的目标，
9、处理不当，将会给项目的成功带了很大的风险。为了保证项目的成功，我们建立了一套严格的变更控制制度，针对用户的每一项变更要求，必须提出书面申请，对变更申请，根据不同的变更级别，组织开发团队的主要成员，上级领导，以及建设方的主要代表，对变更进行各方面的评审，如变更的必要性，技术可行性，对项目成本、进度的影响以及已完成或未完成，将要进行的别的任务的影响，根据分析结果来决定是否接受用户的变更要求。而对于特别重大的变更，我们邀请建设方的主管领导作为变更控制中的主要成员参与对变更的评审，由于建设方重要级的领导参与，使得是否批准变更的决定，具有权威性，因此，我们在开发过程中，对于用户合理的，必要的变更，我们积
10、极的与客户进行沟通，满足他们的期望，而对于不合理的，或者没有必要的变更要求，我们坚决给予拒绝。比如，我们的开发工作接近尾声的时候，建设方因企业的战略需要，在印度收购了一家企业，因印度的官方语言是英语，因此要求我们的软件系统必须支持英文版本。针对用户的合理要求，我们邀请了双方的高层领导，以及第三方的专家，参与对变更的评审，把变更对项目的成本，技术，进度等各种影响作了详细的分析和核算后，大家一致决定拒绝变更的要求，并要求我们在项目完成以后，以一个新的项目来实现用户的新要求。由于范围变更管理作的充分，我们不仅规避了项目范围蔓延的风险，还为组织带来了新的开发项目。经过一年半的开发工作，我们按时保质保量
11、的完成了项目的开发工作，由于我们加强了对项目的范围的管理，整个开发成果顺利地通过了用户的验收确认，并在与用户原有的系统并行运行一个月后，目前已经独立运行了近四个月，尚未发现系统有明显的缺陷。鉴于我们总结了用户上次失败的项目，把实现用户不同层次的需求作为项目的重要工作，因而获得了建设方各界的好评。但是，在工作中，我们也发现了很多不足，特别是没有考虑到用户对语言版本的需求，以及西北网络速度局限，造成远程子公司与总公司交换数据时，传输速度低的性能需求，导致子公司对信息系统不满，但经过我们后期对系统的调整，目前，也基本满足了各个子公司的信息需求。-该文是我为了参加计算机技术与软件专业资格（水平）的考试，花了两个小时的时间，写得一篇论文草稿，由于当时仅仅为了练笔，因此，内容还有很多的不足，现在公布出来，希望大家多提提意见。另外，2008 年 12 月 21 日，我参加信息系统项目管理师的考试，已经成功通过考试。也希望该论文能够给继续参加考试朋友一个参考。
