变更控制流程图
需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。如果变更被接受，还要增加实施变更和验证两个步骤，有时还会有取消变更的步骤。针对变更控制流程，在实际工作中总结出了软件开发人员在需求变更管理实践中的几点对策：优先排序 分批实现 每个需求的重要性是不同的。由于资源或技术条件的限制，会显得“僧多粥少”，因此不可能把所有的需求一次完成。怎么办？把每个需求按照对效益的贡献打个分，排出个优先级来，优先级高的需求先实现，低的到一下版式本实现。由于不断有新的需求进来，有的需求可能永远没有机会被子实现，但不紧，还是要记录下来，并一起参加排序，保证在每个版本发布时重要的需求先得到满足。每个需求的实现是需要花时间的，没人有百分百的把握预估得很清楚，但借鉴过去的经验可以大概估算出人力成本，然后根据开发人员和开发周期得出可用人力投入作为上限。从优先级高的需求中挑，直到挑中的人力成本总和刚刚低于可用投入上限，这样得出的就是需求的录取榜。今后的软件开发规划也会以此为依据，分期分批地在不同的回合中实现。最合理的不一定是优先级最高的，也就是说不一不定是最先考虑的，“经济为本”是指导优先排序的最终原则。
相互协作 很难想像遭到用户抵制的项目能够成功。在讨论需求时，开发人员与用户应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。即使用户提出了在开发人员看来"过分"的要求，也应该仔细分析原因，积极提出可行的替代方案。
充分交流 需求变更管理的过程很大程度上就是用户与开发人员的交流过程。软件开发人员必须学会认真听取用户的要求、考虑和设想，并加以分析和整理。同时，软件开发人员应该向用户说明，进入设计阶段以后，再提出需求变更会给整个开发工作带来什么样的冲击和不良后果。
安排专职人员负责需求变更管理 有时开发任务较重，开发人员容易陷入开发工作中而忽略了与用户的随时沟通，因此需要一名专职的需求变更管理人员负责与用户及时交流。
合同约束 需求变更给软件开发带来的影响有目共睹，所以在与用户签订合同时，可以增加一些相关条款，如限定用户提出需求变更的时间，规定何种情况的变更可以接受、拒绝接受或部分接受，还可以规定发生需求变更时必须执行变更控制流程。
区别对待 随着开发进展，有些用户会不断提出一些在项目组看来确实无法实现或工作量比较大、对项目进度有重大影响的需求。遇到这种情况，开发人员可以向用户说明，项目的启动是以最初的基本需求作为开发前提的，如果大量增加新的需求（虽然用户认为是细化需求，但实际上是增加了工作量的新需求），会使项目不能按时完成。如果用户坚持实施新需求，可以建议用户将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。同时，还要注意控制新需求提出的频率。
选用适当的开发模型 采用建立原型的开发模型比较适合需求不明确的开发项目。开发人员先根据用户对需求的说明建立一个系统原型，再与用户沟通。一般用户看到一些实际的东西后，对需求会有更为详细的解释，开发人员可根据用户的说明进一步完善系统原型。这个过程重复几次后，系统原型逐渐向最终的用户需求靠拢，从根本上减少需求变更的出现。目前业界较为流行的叠代式开发方法对工期紧迫的项目的需求变更控制很有成效。
用户参与需求评审 作为需求的提出者，用户理所当然是最具权威的发言人之一。实际上，在需求评审过程中，用户往往能提出许多有价值的意见。同时，这也是由用户对需求进行最后确认的机会，可以有效减少需求变更的发生。 其实在需求变更控制中，项目组最关键的是两个人，一个是PM，一个是CM 这个变更流程很有问题啊～～不太准确:( :( :(
回复 4# 的帖子
i agree with upper.这个图画得有问题
这个图画得有问题，不太精准，用得图标也不一样，楼主改进:) 一下 问题出在那了 ？ 这流程得改改，不然会误导人哦。。。 收藏资料 回帖赚积分 3ks楼主
页:
[1]
