软题库 移动APP 扫码下载APP 随时随地移动学习 培训课程
当前位置:信管网 >> 综合知识 >> 文章内容
信息系统项目管理:控制项目范围的扩展
来源:信管网 2016年03月01日 【所有评论 分享到微信

上一节:信息系统项目管理:需求变更管理

控制项目范围的扩展

扩展需求是指在软件需求基线已经确定后又要增添新的功能或进行较大改动。问题不仅仅是需求变更本身,而是迟到的需求变更会对已进行的工作有较大的影响。要是每个建议的需求都被采纳,对于项目出资者(sponsor)、参与者与客户来说项目将永远也不会完成—事实上,这是不可能的。
对许多项目来说,一些需求的改进是合理的且不可避免。业务过程、市场机会、竞争性的产品和软件技术在开发系统期间是可以变更的,管理部门也会决定对项目做出一些调整。在项目进度表中应该对必要的需求改动留有余地。若不控制范围的扩展将使我们持续不断地采纳新的功能,而且要不断地调整资源、进度、或质量目标,这样做极其有害。
管理范围扩展的第一步就是把新系统的视图、范围、限制文档化并作为业务需求的一部分。评估每一项建议的需求和特性,将它与项目的视图和范围相比较决定是否应该采纳它。强调客户参与的有效的需求获取方法能够减少遗漏需求的数量,只在做出提交承诺和分配资源后才采纳该需求。控制需求扩展的另一个有效的技术是原型法,这个方法能够给用户提供预览所有可能的实现,以帮助用户与开发者沟通从而准确把握用户的真实需求。
事实上,控制范围的扩展的方法是要敢于说“不”。很多人不喜欢说“不”,开发者只好在各种压力下接受每一项建议的需求。“客户总是对的”,“我们将使客户完全满意”这些话哲理上是正确的,一旦按此办事就要付出代价。忽视代价并不能改变“变更不免费”的事实。我知道一个成功的商业开发公司,它的首席执行官习惯于建议新的特色但开发管理者总是说“现在不行”。“现在不行”比简单地拒绝灵活很多,因为他暗含在后续版本中采纳其特色的希望。把客户提出的所有特色都采纳将会导致错过提交日期,质量的下滑,开发人员的疲劳不堪。尽管客户并不总对,但他们是上帝,所以你应该尽可能在下一版本中满足他们的需求。
在理想的情况下,在开始构造前应该收集到所有新系统的需求,而且在开发中基本上不变更。这就是“瀑布”型软件开发生存期模型的前提,但在实践中,它却不太有效。当然,某种程度上,对特定的版本应该冻结需求,不再变更。然而,很早确定需求却忽视了有时候客户并不知道需要什么的现实,开发人员应该对用户这些需求变更做出响应。为了对付这些实际情况,你需要有根据地采纳变更过程。

上一节:信息系统项目管理:变更控制过程和策略

温馨提示:因考试政策、内容不断变化与调整,信管网网站提供的以上信息仅供参考,如有异议,请以权威部门公布的内容为准!

信管网致力于为广大信管从业人员、爱好者、大学生提供专业、高质量的课程和服务,解决其考试证书、技能提升和就业的需求。

信管网软考课程由信管网依托10年专业软考教研倾力打造,官方教材参编作者和资深讲师坐镇,通过深研历年考试出题规律与最新大纲,深挖核心知识与高频考点,为学员考试保驾护航。面授、直播&录播,多种班型灵活学习,满足不同学员考证需求,降低课程学习难度,使学习效果事半功倍。

发表评论  查看完整评论  

相关内容

推荐文章