软件项目管理中的需求变更控制

1、软件项目管理中的需求变更控制 软件项目在执行过程的变更,特殊是需求的变更是最难把握的,它也是影响到整个项目成败的关键因素。 一、计算机系统集成软件开发项目需求变更产生的原因 对于软件项目的需求而言,产生变更的原因集中在下面几个方面: 1.用户对系统功能理解的分歧。在进行用户需求调查分析时,分析人员的学问、背景、与用户的交流状况等因素会造成系统分析人员和用户在功能理解上的分歧,随着项目的进行,这种分歧确定会带来变更。 2.用户业务规律发生了变化。用户自身的业务规律不太明确,特殊是处于激烈竞争状况下的用户确定要随着市场状况的变化,随时调整自己的运作来适应这种变化,这确定会对相关的软件产品提出更多的

2、变更要求。 3.用户在试用过程中提出的变更。当用户拿到测试版本可以进行实际操作时,用户一般都会对功能、性能、界面、操作方式等提出新的意见,这时变更产生了。 4.技术的升级。技术的升级分为两个方面,一方面是随着信息化技术的快速发展,原项目中使用的技术可能变成过时技术,需要对原技术进行升级;另一个方面是开发方自身对软件版本升级、性能改进、设计修正时产生的变更。从上面可以看出,希望软件项目需求能从始至终一成不变是不可能的。 二、计算机系统集成软件开发项目需求变更的影响及管理原则 1.设定项目需求基线。需求基线是需求变更的参照标准,每次的变更均应在需求基线的基础上进行。每次变更评审通过后要重新确定需求

3、基线,使其符合需求变更后的状况。 2.严格执行需求变更流程,并记录在变更过程中产生的全部文档。 3.成立项目变更掌握委员会(ccb),负责对项目变更进行评估,裁定哪些变更需要执行,哪些变更应当放弃。变更掌握委员会的成员应由项目所涉及到的多方面人同组成,应当包括用户方和开发方的决策人员在内。 4.需求变更后,受影响的相关软件计划、产品、活动都要进行相应的变更,以保持和更新的需求全都。 三、计算机系统集成软件开发项目需求变更的流程 在软件项目需求变更时,一般采用下面的流程进行掌握: 1.申请变更。当项目开发组确认将要产生需求变更时,用标准的变更申请表格将用户的每一次变更申请记录存档。 2.变更评估

4、。项目开发组收到用户提交的需求变更申请后,应对该变更所带来的影响进行评估。它包括项目的人力、物力、资金、管理、时间、质量、工作负荷等内部因素,以及外部因素如资本、用户要求的完工时间、项目负债状况等各个方面的影响。对于一个变更的申请,可能会有以下几个可能的评估结果:(1)在现有资源和时间范围允许的状况下可以接受该变更。(2)可以接受,但要延长交付时间。(3)在现有的可交付时间内可以接受,但需要额外的资源支持。(4)可以接受,但需要额外的资源和延长交付时间。(5)可以接受,但需要采取多次发布策略,并排定不同发布时期交付成果的优先次序。这种状况的发生特别频繁,项目经理需要权衡将一些重要的工作提前完成

5、,而有一些不重要的工作延迟完成。(6)不能接受。 3.变更的实施。一旦确定变更后,下一步就是分析和选择可行的实施方案。项目的目标、预算、团队以及项目的进度是打算项目成功实施的主要因素。在需求变更时,力求在尽可能小的变动幅度内对这些主要的因素进行微调。为了将项目变更的影响降低到最小,一定要专心执行变更的掌握流程,减小项目风险。 四、实际项目分析 以某学院的信息管理系统软件开发项目为例。该系统包括了学籍管理、排课管理、学生选课、教材管理、学生考勤管理、教学质量管理、考试管理、成果管理、宿舍管理、财务管理、证明管理、招生管理等子系统。在开发过程中,我们对需求变更进行了较严格的管理,产品得以按时保质地

6、上线。在该管理信息系统的开发过程中,变更的因素有以下几个:1.由于项目启动时间距离第一个版本的上线时间很近,不可能在短时间内将全部的需求都获取到。2.开发人员有时会对用户的描述理解不正确,或遗漏某些要求,所以要对已有的需求进行修改。3.用户在项目开头的时候,大都不是很了解自己究竟需要什么,等他们使用一段时间管理系统后,就会在实际使用中不断发觉这样那样的需求。4.最主要的因素,就是该学院成立时间不长,且不是采用国内常规的管理方法,而要使这些管理方法适合国内的高校管理体制,需要有一段磨合期,所以学院内部的管理经常变,导致系统的相应需求也必需变。变更掌握委员会由主管这套系统开发的副院长、项目经理以及

7、配置管理员三个人组成。依据开发的实际状况,我们制定了一套变更管理程序,就是全部变更都必需以变更申请书的形式提交给变更掌握委员会,变更掌握委员会评估后,出具变更报告,然后才交给相关人员做相应处理,之后,由测试人员对变更后的相关用例进行测试跟踪。一个需求变更申请提交后,变更掌握委员会对其进行评估,如确认进行变更,则由我方项目经理出具一份变更报告,写明变更事由、提出方、提出时间、变更评估结果。配置管理员将这份变更报告加到配置管理库中存档,并分发给变更申请人以及相关系统分析员。系统分析员对之进行分析,提交出一份变更列表,将该变更所影响到的文档、程序都具体的列出来,上交给配置管理员进行存档。然后,系统分析员对列表的中所列出来的文档逐个进行修改,再交由编程人员进行相应的代码修改,然后提交测试员测试,出具测试报告。这些修改的文档、代码以及测试报告都要提交给配置管理员进行存档管理,配置管理员还要依据提交状况对变更列表进行相应维护,如某项修改完成了,就要在它后面打上完结标记。当该变更列表中的全部变更项都完结了,配置管理员在变更报告后要加上实际完成时间。这样,变更所导致的文档、程序变化就可以在一个可以追溯、可以掌握的状态下进行了。削减了遗漏的可能性,并便于变更的追踪。由于采取了上述变更掌握