软件项目的范围管理浅析

项目管理人员继续教育论文第1页共9页软件项目的范围管理浅析乔玉东－3750902082012年12月27日摘要：范围管理是软件项目管理中的重要一环,项目的范围决定了项目的工作内容，有效的范围管理可以保证项目的顺利实施，避免范围蔓延和做无用功。软件项目的复杂性，决定了项目的范围的不确定，范围变更频繁，更难驾驭。关键词：计算机系统集成项目管理范围管理一，软件项目范围管理概述项目范围对项目的影响是决定性的。项目只有完成项目范围内的全部工作才能结束，一个不明确的项目范围、或者项目干系人对项目范围理解的不一致，都会造成项目的不成功。项目范围的不明确造成的结果是项目范围蔓延；对项目范围理解的不一致的结果是项目成果得不到项目业主的认可。对于软件开发项目来说，需求理解的偏差会造成严重的系统缺陷，需求的不明确会在开发过程中不断的产生新的需求。项目的业主不会接受一个没有满足要求的软件系统，软件开发团队只能不断地对自己的工作进行返工，项目的工期无限延长、项目的范围无限扩大、项目的成本不断超支、项目的产品质量无法控制……根据PMBOK2004定义的项目范围管理，包括五个基本过程：（1）范围规划——制定项目范围管理计划，制定范围控制规程，定义工作分解结构。（2）范围定义——制定项目范围说明书，确定项目的工程量。（3）制作工作分解结构——把项目的可交付成果与项目的工作划分为可控的组成部分，并分步实施。（4）范围核实——对项目的产品进行交付验收。（5）范围控制——严格控制项目的范围变更，防止项目的无限蔓延。对于软件开发这种抽象性很强的项目来说，项目范围的确定是很困难的事情。由于项目的业主和项目开发人员对软件系统的需求不明确，对需求的认知不项目管理人员继续教育论文第2页共9页统一，特别是业主与开发人员由于专业领域不同而造成的沟通障碍，使得开发人员对业主的隐性需求认知困难，这些问题造成的直接结果就是在项目实施过程中，会遇到各种各样的变更。如果不能很好的管理、控制好这些变化，可能造成项目成本超支、项目进度拖延，让项目陷入混乱状态。在软件项目中，软件系统的需求，与项目范围管理有着直接的关系。首先，交付一个可以满足用户需求的软件系统是软件项目中最重要的工作之一。因此，这个软件系统的功能特征就决定了主要的项目范围。整个软件开发过程中包括需求分析、设计、编码、和测试工作，都是这个软件系统的项目范围之一。与工程项目不同，软件开发项目范围中可能包括更多的内容。比如很多软件项目中，交付物中会包括系统功能规格说明书、系统设计说明书、系统使用手册、使用培训等内容。软件项目中，较难把握的部分就是软件系统的范围，或者说是软件系统的功能特性。绝大多数软件项目的需求都有问题，每一个需求问题都带来不明确的项目范围。软件本身的抽象性，使得对软件描述经常会有二义性和模糊性，而据此定义的系统范围也是模糊和不明确的，这也是软件项目中范围难以控制的重要原因。二，范围规划很显然，要想做好项目的范围管理，首先就要有一个管理的规划，通常把这个规划称为项目范围管理计划。软件项目范围规划的工作要点包括四个方面：1，如何确定详细的项目范围。即需要采取什么样的方法、采用什么样的工具和过程来逐步得到详细的项目范围。对于抽象的软件系统项目，确定精确的项目范围不是一件容易的事情，必须要有科学的方法。需求工程拥有一套完整的理论体系，在需求开发方法中有许多成熟获取、分析需求的方法论，如用例分析等，项目经理需要结合具体的项目特点和环境来进行剪裁和取舍，制定出当前定义范围的方法。范围定义的最终结果是项目范围说明书。而软件项目中，是把用户需求或者系统规划说明书作为项目范围说明的主要文档，配合其他的文档共同说明项目的范围。制定范围计划，需要考虑清楚如何综合需求说明书等文档，以清晰且详细地表述项目的需求。2，如何根据详细的项目范围得到WBS项目管理人员继续教育论文第3页共9页在范围管理计划中关注的问题是采用什么样的过程和方法得到WBS。WBS是整个项目团队为完成项目目标，创造项目成果而进行的工作的有层次的结构分解。WBS也表达了完整的项目范围，WBS的层次结构让项目的范围变得更加清晰、更容易管理。3，如何验收已经交付的项目成果随着项目的开展，项目的产品——项目的可交付成果逐渐的完成，对产品的验收就摆在了台面。软件开发项目的产品是抽象的，与工程项目的产品验收的方法也不同。对需求分析、设计文档等验收，通常是组织专家进行评审来验收，而对于开发完成的系统，则采取测试的方法来进行验收。三，软件产品的范围定义软件项目的目标是开发或实施某项软件系统或产品，软件系统的项目范围，也就表现为软件需求规格说明书。软件需求规格说明书一般包括三方面的内容：一，功能特征的描述。功能特征描述是指对系统功能的详细描述，即软件系统应该具有的功能，这些功能是怎么向使用者提供服务的。功能特征的描述对于不同的软件系统，描述的内容也千差万别，但基本的重点描述应该考虑四个部分：（1）功能分层。通过对系统功能特征分层处理，可以让功能特征更清晰，更易于管理和控制。（2）文字描述尽量简洁。对于难以描述，或者需要大篇幅文字说明的功能，充分利用图表的方式来表述，用简洁的语言把问题说清楚。（3）考虑系统状态的变化。软件系统的状态变化较为复杂，同样的功能在不同的系统状态下会呈现不同的特征。这也要求在功能描述时，考虑到系统状态的特点，理清系统状态变化的规律。二，系统接口的描述。随着信息系统的快速发展，软件系统的接口数量也在快速的增长，需要描述系统接口的特征、类型、作用、连接标准等内容，这样便于清晰的划分系统的范围。三，质量特征的描述。系统的质量特征，也要在产品范围中进行定义和描述。主要的质量特征包括：可靠性、可移植性、机密性和完整性。项目管理人员继续教育论文第4页共9页四，范围的控制在软件开发的项目中，项目控制的目的是确保范围的变化处在可控制可跟踪的状态。业界流行的“唯一不变的就是变化”这样的段子，也充分的说明了项目充满了各种各样的变化。当项目发生变化时，也就意味着项目中需要做的工作发生了变化，这必然造成项目的进度计划、人员安排、项目的成本等一系列的变化。如果项目的范围失控，可能使项目陷入混乱，增加项目的风险。为了保证项目能够有条不紊的进行，消除范围变更造成的不利影响，在项目管理中，是通过范围的变更控制系统来完善的。在范围控制过程中，要注意三点：（1）范围控制是必须的，不存在没有变化的项目。为了避免范围变更的盲目性和不确定性，就一定要建立范围变更控制机制。（2）项目范围的变化，并不总是意味着项目工作量的增加，项目范围的变化，也意味着更贴近用户的需求，更适应项目的环境，范围控制要做的是消除变更带来的不良影响。（3）项目范围控制的目的不是阻止变更的发生。项目范围控制的主要任务是，出现范围变更需求时，管理相关的计划、资源安排以及项目成果，使项目的各个部分能很好的配合在一起，消除变更带来的不利影响。项目范围控制主要通过变更控制系统来完成的。在软件项目中，系统需求构成了最主要的系统范围。变更控制系统遵循“请求——评估审批——跟踪”的原则进行的。首先，变更申请人提交变更请求，此后变更控制委员会CCB需要召集相关人员评估变更的范围和可能的结果，并确定是否执行该变更的决定，最后CCB将跟踪变更的执行。在整个变更控制流程中，有四个角色在进行交互：（1）变更申请人：范围需求变更的发起者。（2）变更责任人：任何变更都要落实到具体的工作当中，变更责任人就是变更的执行者。（3）变更控制委员会CCB：CCB是变更控制系统的核心角色，任何变更需求，都必须经过CCB的审核和评估，决定是否执行变更，跟踪变更的过程，评估变更的结果。（4）配置管理员：配置管理员管理系统的配置项。通常情况下，描述系统项目管理人员继续教育论文第5页共9页范围的范围说明书以及项目的产品，都纳入了配置管理的范围，对这些配置项的存取，都必须通过配置管理员完成。五，案例分析案例分析：2011年接到某集团公司的的一个备件管理信息系统的软件开发项目。该公司在2003年实施了SAP的R/3系统ERP系统。2007年，该集团自主开发了一套CMS管理系统。由于该公司规模比较庞大，产品遍布全国，其旗下有三十多个营销子公司，其售后服务网络也遍布全国各个县镇。该公司以前的备件管理一直纳入了R/3系统来管理，运行一直都很稳定。其备件管理的模式是：当用户购买该公司的产品发生故障后，用户拨打该公司的统一服务电话或登录售后服务网站报修，公司客服通过CMS系统受理用户的报修，并根据该用户的的地理位置，将维修服务工单派发到所属分公司；分公司接到CMS的派单后，将工单下派到旗下的特约维修服务站，由特约维修站派技术人员上门去用户家维修。技术人员在用户家中维修产品时，如果需要更换备件，则向所属的分公司请购，而分公司根据各个特约维修服务站的备件需求，统一做出备件请购计划，然后报给集团总部备件管理部，由备件管理部根据各个分公司的需求计划，进行统一采购，派发到各分公司，各分公司再将备件下发到各个下属维修服务站，服务站维修完毕后，登录CMS网站，填写工单信息和耗材物料。集团有一个备件总仓，各分公司也有自己的备件仓库。各特约服务站自己也备有一些常用的耗材。当前备件管理的弊端：（1）备件流转时间长。从用户报修，到备件下到维修站，时间周期最长可达一周，严重影响了用户对该公司产品的信誉。（2）备件调配不均。当分公司向总部备件管理部请购的备件，总仓没货，而其他分公司的备件仓却积存过多，而各分公司之间不能结算备件成本，因此也无法互通有无。（3）管理成本增加。由于各个分公司各有自己的仓库，备件的管理成本高，备件流转周期长。开发SPM的基本需求：当各维修服务站发生备件需求时，登录SPM网站，填写备件需求表，提交需求表到SPM系统中，集团备件管理部根据SPM的需求单从仓库直接通过快递公司发货到给维修服务站。成本核算由备件管理部直接同项目管理人员继续教育论文第6页共9页各分公司结算，分公司再跟各服务站结算。保修期内的备件，费用由分公司承担，保修外的费用，成本由服务站承担，服务站向用户收费收回成本，同时撤销分公司的分仓。该SPM信息系统流程清晰，我作为该项目的负责人，组织项目组人员，对用户的需求进行搜集、整理、归纳，最后形成了项目的软件需求规格说明书。并组织项目组成员对需求规格说明书进行评审，评审通过后，项目组成员就积极投入到项目的开发中。软件工程面对的项目中唯一不变的就是变化。在整个项目开发过程中，遇到过三次比较大的范围变更。（1）要求SPM与CMS对接。由于管理的无序性，造成各服务站通过SPM请购到备件，私自高价出售给别的维修企业的弊端。公司要求服务站请购专用材料，不直接通过SPM，而是通过CMS的派工单，根据派工单的对应的产品填写所需物料，由CMS生成请购单，发送到SPM，再由SPM来给服务站发货，而通用材料继续通过SPM来操作。接到用户的口头需求变更要求后，我作为开发方项目负责人，主观认为这个变更比较简单，也就没有通过CCB系统，直接派程序员去联系CMS系统的原开发主管，要求参与修改CMS的部分代码，使得CMS能够与SPM通讯。让人始料未及的是，CMS是该公司自主开发的系统，没有执行软件开发的一些规程，缺乏完善的开发文档，而且CMS的开发负责人不仅不配合我们的工作，还处处刁难设套，严重影响到了项目进度。在工作中我们也了解到，CMS系统采用了.NET开发平台，数据库采用了SQLServer，而我们开发的SPM系统则采用了J2EE，数据库使用了Oracle数据库，双方对接并不像我们想象的那么简单。由于工期拖后，开发成本上升，而且后续的工作被延误，迫使我立即做出决策，停止两个系统的对接工作，并通知公司双方主管负责人，启动变更控制系统。在变更评审会议上，双方就变更中遇到的问题，变更带来的工期延误以及变更发生的各项成本费用，变更过程中存在的沟通问题，充分进行了论证，并对相关的各项费用、工期计划、沟通责任归属，实施明细都做了进一步明确，并形成一份详细的需求变更文档，双方就达成的变更协议签字盖章，同时下发变