浅析软件项目管理中的需求变更控制.doc
浅析软件项目管理中的需求变更控制 [摘要 ]从计算机系统集成软件开发项目需求变更控制的角度 ,简单分析需求变更产生的原因、需求变更将会对项目产生的影响 ,并结合实践说明如何在实际工作中对软件开发项目的需求变更进行有效控制和管理 ,以减少项目风险 ,使项目顺利交付。 [关键词 ]项目管理 需求变更 控制 软件项目在执行过程的变更 ,特别是需求的变更是最难把握的 ,它也是影响到整个项目成败的关键因素。 一、计算机系统集成软件开发项目需求变更产生的原因 对于软件项目的需求而言 ,产生变更的原因集中在下面几个方面 : 1.用户对系统功能理解的分歧。在进行用户需求调查分析时 ,分析人员的知识、背景、与用户的交流情况等因素会造成系统分析人员和用户在功能理解上的分歧 ,随着项目的进行 ,这种分歧肯定会带来变更。 2.用户业务逻辑发生了变化。用户自身的业务逻辑不太明确 ,特别是处于激烈竞争情况下的用户肯定要随着市场情况的变化 ,随时调整自己的运作来适应这种变化 ,这肯定会对相关的软件产品提出更多的变更要求。 3.用户在试用过程中提出的变更。当用户拿到测试版本可以进行 实际操作时 ,用户一般都会对功能、性能、界面、操作方式等提出新的意见 ,这时变更产生了。 4.技术的升级。技术的升级分为两个方面 ,一方面是随着信息化技术的迅速发展 ,原项目中使用的技术可能变成过时技术 ,需要对原技术进行升级 ;另一个方面是开发方自身对软件版本升级、性能改进、设计修正时产生的变更。从上面可以看出 ,指望软件项目需求能从始至终一成不变是不可能的。 二、计算机系统集成软件开发项目需求变更的影响及管理原则 1.设定项目需求基线。需求基线是需求变更的参照标准 ,每次的变更均应在需求基线的基础上进行。每 次变更评审通过后要重新确定需求基线 ,使其符合需求变更后的状况。 2.严格执行需求变更流程 ,并记录在变更过程中产生的所有文档。 3.成立项目变更控制委员会 (CCB),负责对项目变更进行评估 ,裁定哪些变更需要执行 ,哪些变更应该放弃。变更控制委员会的成员应由项目所涉及到的多方面人同组成 ,应该包括用户方和开发方的决策人员在内。 4.需求变更后 ,受影响的相关软件计划、产品、活动都要进行相应的变更 ,以保持和更新的需求一致。 三、计算机系统集成软件开发项目需求变更的流程 在软件项目需求变更时 ,一般采用 下面的流程进行控制 : 1.申请变更。当项目开发组确认将要产生需求变更时 ,用标准的变更申请表格将用户的每一次变更申请记录存档。 2.变更评估。项目开发组收到用户提交的需求变更申请后 ,应对该变更所带来的影响进行评估。它包括项目的人力、物力、资金、管理、时间、质量、工作负荷等内部因素 ,以及外部因素如资本、用户要求的完工时间、项目负债情况等各个方面的影响。对于一个变更的申请 ,可能会有以下几个可能的评估结果 :(1)在现有资源和时间范围允许的情况下可以采纳该变更。 (2)可以采纳 ,但要延长交付时间。 (3)在现有的 可交付时间内可以采纳 ,但需要额外的资源支持。 (4)可以采纳 ,但需要额外的资源和延长交付时间。 (5)可以采纳 ,但需要采取多次发布策略 ,并排定不同发布时期交付成果的优先次序。这种情况的发生非常频繁 ,项目经理需要权衡将一些重要的工作提前完成 ,而有一些不重要的工作延迟完成。 (6)不能采纳。 3.变更的实施。一旦确定变更后 ,下一步就是分析和选择可行的实施方案。项目的目标、预算、团队以及项目的进度是决定项目成功实施的主要因素。在需求变更时 ,力求在尽可能小的变动幅度内对这些主要的因素进行微调。为了将项目变更的影响降低 到最小 ,一定要认真执行变更的控制流程 ,减小项目风险。 四、实际项目分析 以某学院的信息管理系统软件开发项目为例。该系统包括了学籍管理、排课管理、学生选课、教材管理、学生考勤管理、教学质量管理、考试管理、成绩管理、宿舍管理、财务管理、证明管理、招生管理等子系统。在开发过程中 ,我们对需求变更进行了较严格的管理 ,产品得以按时保质地上线。在该管理信息系统的开发过程中 ,变更的因素有以下几个 :1.由于项目启动时间距离第一个版本的上线时间很近 ,不可能在短时间内将所有的需求都获取到。 2.开发人员有时会对用户的描述理 解不正确 ,或遗漏某些要求 ,所以要对已有的需求进行修改。 3.用户在项目开始的时候 ,大都不是很了解自己到底需要什么 ,等他们使用一段时间管理系统后 ,就会在实际使用中不断发现这样那样的需求。 4.最主要的因素 ,就是该学院成立时间不长 ,且不是采用国内常规的管理方法 ,而要使这些管理方法适合国内的高校管理体制 ,需要有一段磨合期 ,所以学院内部的管理经常变 ,导致系统的相应需求也必须变。变更控制委员会由主管这套系统开发的副院长、项目经理以及配置管理员三个人组成。根据开发的实际情况 ,我们制定了一套变更管理程序 ,就是所有变更都必须以 变更申请书的形式提交给变更控制委员会 ,变更控制委员会评估后 ,出具变更报告 ,然后才交给相关人员做相应处理 ,之后 ,由测试人员对变更后的相关用例进行测试跟踪。一个需求变更申请提交后 ,变更控制委员会对其进行评估 ,如确认进行变更 ,则由我方项目经理出具一份变更报告 ,写明变更事由、提出方、提出时间、变更评估结果。配置管理员将这份变更报告加到配置管理库中存档 ,并分发给变更申请人以及相关系统分析员。系统分析员对之进行分析 ,提交出一份变更列表 ,将该变更所影响到的文档、程序都详细的列出来 ,上交给配置管理员进行存档。然后 ,系统分析 员对列表的中所列出来的文档逐个进行修改 ,再交由编程人员进行相应的代码修改 ,然后提交测试员测试 ,出具测试报告。这些修改的文档、代码以及测试报告都要提交给配置管理员进行存档管理 ,配置管理员还要根据提交情况对变更列表进行相应维护 ,如某项修改完成了 ,就要在它后面打上完结标记。当该变更列表中的所有变更项都完结了 ,配置管理员在变更报告后要加上实际完成时间。这样 ,变更所导致的文档、程序变化就可以在一个可以追溯、可以控制的状态下进行了。减少了遗漏的可能性 ,并便于变更的追踪。由于采取了上述变更控制方法 ,即使该项目的变更比较多 ,但还是能保持开发工作正常有序地进行。 五、结束语 对于软件开发的过程中不可避免的会出现需求变更 ,并且这些变更会发生在项目的整个生命周期里 ,因此变更控制显得尤其重要 ,变更控制的管理好坏对项目成败有重要影响。 参考文献 : [1]陈远 ,项目管理 [M].武汉大学出版社 ,2005. [2]邱菀华等 ,现代项目管理导论 [M].机械工业出版社 ,2002. [3]刘国靖、邓韬 ,21 世纪新项目管理理念、体系、流程、方法、实践 [M].清华大学出版社 ,2003.