软件项目需求变更六大原则及应对之道
软件项目需求变更六大原则及应对之道
变化并不是人们最害怕的,最怕的是跟不上变化的步伐。同样,在软件开发过程中需求的变更会给开发带来不确定性,但只要把需求变更作为重点、难点小心加以控制,软件开发的进度、成本和质量也就有了" 安全" 的基础。
需求变更管理的需求
需求变更是因为需求发生变化。根据软件工程思想,需求说明书一般要经过论证,如果在需求说明书经过论证以后,需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减,均属于需求变更。
需求变更的出现主要是因为在项目的需求确定阶段,用户往往不能确切地定义自己需要什么。用户常常以为自己清楚,但实际上他们提出的需求只是依据当前的工作所需,而采用的新设备、新技术通常会改变他们的工作方式; 或者要开发的系统对用户来说也是个未知数,他们以前没有过相关的使用经验。随着开发工作的不断进展,系统开始展现功能的雏形,用户对系统的了解也逐步深入。
于是,他们可能会想到各种新的功能和特色,或对以前提出的要求进行改动。他们了解得越多,新的要求也就越多,需求变更因此不可避免地一次又一次出现。
这时,如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效,抑或不按变更控制流程来管理需求变更,那么很可能造成项目进度拖延、成本不足、人力紧缺,甚至导致整个项目失败。
当然,即使按照需求变更控制流程进行管理,由于受进度、成本等因素的制约,软件质量还是会受到不同程度的影响。但实施严格的软件需求管理会最大限度地控制需求变更给软件质量造成的负面影响,这也正是我们进行需求变更管理的目的所在。
六大原则
实施需求变更管理需要遵循如下原则:
1. 建立需求基线。需求基线是需求变更的依据。在开发过程中,需求确定并经过评审后(用户参与评审) ,可以建立第一个需求基线。此后每次变更并经过评审后,都要重新确定新的
需求基线。
2. 制订简单、有效的变更控制流程,并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时,这个流程具有一定的普遍性,对以后的项目开发和其他项目都有借鉴作用。
3. 成立项目变更控制委员会(CCB)或相关职能的类似组织,负责裁定接受哪些变更。CCB 由目所涉及的多方人员共同组成,应该包括用户方和开发方的决策人员在内。
4. 需求变更一定要先申请然后再评估,最后经过与变更大小相当级别的评审确认。
5. 需求变更后,受影响的软件计划、产品、活动都要进行相应的变更,以保持和更新的需求一致。
6. 妥善保存变更产生的相关文档。
应对之道
需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。如果变更被接受,还要增加实施变更和验证两个步骤,有时还会有取消变更的步骤。变更控制流程如图所示。针对变更控制流程,笔者在实际工作中总结出了软件开发人员在需求变更管理实践中的几点对策:
相互协作 很难想像遭到用户抵制的项目能够成功。在讨论需求时,开发人员与用户应该尽量采取相互理解、相互协作的态度,对能解决的问题尽量解决。即使用户提出了在开发人员看来" 过分" 的要求,也应该仔细分析原因,积极提出可行的替代方案。
充分交流 需求变更管理的过程很大程度上就是用户与开发人员的交流过程。软件开发人员必须学会认真听取用户的要求、考虑和设想,并加以分析和整理。同时,软件开发人员应该向用户说明,进入设计阶段以后,再提出需求变更会给整个开发工作带来什么样的冲击和不良后果。
安排专职人员负责需求变更管理 有时开发任务较重,开发人员容易陷入开发工作中而忽略了与用户的随时沟通,因此需要一名专职的需求变更管理人员负责与用户及时交流。
合同约束 需求变更给软件开发带来的影响有目共睹,所以在与用户签订合同时,可以增加一些相关条款,如限定用户提出需求变更的时间,规定何种情况的变更可以接受、拒绝接受或部分接受,还可以规定发生需求变更时必须执行变更控制流程。
区别对待 随着开发进展,有些用户会不断提出一些在项目组看来确实无法实现或工作量比较大、对项目进度有重大影响的需求。遇到这种情况,开发人员可以向用户说明,项目的启动是以最初的基本需求作为开发前提的,如果大量增加新的需求(虽然用户认为是细化需求,但实际上是增加了工作量的新需求) ,会使项目不能按时完成。
如果用户坚持实施新需求,可以建议用户将新需求按重要和紧迫程度划分档次,作为需求变更评估的一项依据。同时,还要注意控制新需求提出的频率。
选用适当的开发模型 采用建立原型的开发模型比较适合需求不明确的开发项目。开发人员先根据用户对需求的说明建立一个系统原型,再与用户沟通。一般用户看到一些实际的东西后,对需求会有更为详细的解释,开发人员可根据用户的说明进一步完善系统原型。
这个过程重复几次后,系统原型逐渐向最终的用户需求靠拢,从根本上减少需求变更的出现。目前业界较为流行的叠代式开发方法对工期紧迫的项目的需求变更控制很有成效。
用户参与需求评审 作为需求的提出者,用户理所当然是最具权威的发言人之一。实际上,在需求评审过程中,用户往往能提出许多有价值的意见。同时,这也是由用户对需求进行最后确认的机会,可以有效减少需求变更的发生。
相关文章
- 20**年高级项目管理师复习题
- 信息化工程监理规范.第5部分.软件工程监理
- 信息系统监理师教程浓缩版,适合手拿已排版
- 信息系统运行维护管理制度
- 项目管理九大知识领域
- 软件项目外包合同
- 系统集成项目管理的四控.三管.一协调
- 软件项目开发合同范本V1.0
- 软件配置管理规范
高级项目管理师1-基础知识 高级项目管理师复习题 一.项目启动: 1.项目:受时间.费用和质量资源约束 大型项目:战略目标 相关项目和子项目 项目组合:控制.协调和整体最优效果 2.项目管理的目的:项目组合值最大 复杂项目管理:选择 评估 ...
国家电子政务标准化项目工作组文件 文件编号:EGS N304-4 日期:2005年12月15日 标题:"信息化工程监理规范 第5部分:软件工程监理" 来源:"信息化工程监理规范"工作组 内容摘要:&q ...
监理月报的要点:⑴工程进展简况:⑵工程在进度控制, 质量控制, 造价控制和合同, 信息方面的情况:⑶工程变更情况:⑷其他需要报告和记录的重要问题:⑸最小监理工作小结 信息系统工程:是指信息化工程建设中的信息网络系统.信息资源系统.信息应用系 ...
信息系统运行维护管理制度 第一章 总则 一.为规范信息系统的运行维护管理工作,确保信息系统的安全可靠运行,切实提高生产效率和服务质量,使信息系统更好地服务于生产运营和管理,特制订本管理办法. 二.本管理办法适用于及其分支机构的信息系统,各分 ...
项目管理九大知识领域 1.项目范围管理是为了实现项目的目标,对项目的工作内容进行控制的管理过程.它包括范围的界定,范围的规划,范围的调整等. 2.项目时间管理是为了确保项目最终的按时完成的一系列管理过程.它包括具体活动界定,活动排序,时间估 ...
软件项目外包合同 合 同 号: 合同名称: 甲方: 第一条 总则 1) 甲方选择乙方为其开发软件系统,乙方将在甲方规定的时间内,根据甲方要求分段为甲方开发 软件系统. 2) 甲.乙双方经友好协商,根据<中华人民共和国合同法>等有 ...
1.信息化建设普遍存在的主要问题 (1)系统质量不能满足应用的基本需求: (2)工程进度拖后延期: (3)项目资金使用不合理或严重超出预算: (4)项目文档不全甚至严重缺失: (5)在项目实施过程中系统业务需求一变再变: (6)在项目实施过 ...
软件项目开发合同 合 同 号: 合同名称: 甲方: (公司名称) 第一条 总则 1) 甲方选择乙方为其开发软件系统,乙方将在甲方规定的时间内,根据甲方要求分段为甲方开发 软件系统. 2) 甲.乙双方经友好协商,根据<中华人民共和国合同 ...
软件配置管理规范 日期 1999/07/8修订记录修订版本1.00初稿完成. 描述作者审核批准 拟制:审核:批准:部门:部门:部门:日期:日期:日期: 目 录 1.规范概述. . . . . . . . . . . . . . . . . ...