管理变更请求.pdf10
所属分类:经营管理
文件大小:817 KB
下载要求:10 学币或VIP
点击下载一旦执行了软件过程评估,我询问项目组成员是如何接受产品的变更需求的,其中一位回答说“无论何时市场代表对B r u c e或S a n d y提出变更要求,他们总是说同意,我们就只好努力去做出来”。他并未正面回答我的问题。不被控制的变更是项目陷入混乱、不能按进度执行或软件质量低劣的共同原因。为了使开发组织能够严格控制软件项目应确保以下事项:
• 应仔细评估已建议的变更。
• 挑选合适的人选对变更做出决定。
• 变更应及时通知所有涉及的人员。
• 项目要按一定的程序来采纳需求变更。
只有项目风险承担者在开发过程中能控制变更,他们才知道将交付什么,哪一项将会导致与目标的差距。对项目越深入了解后,你就越能发现采纳变更需求条件的苛刻。在需求文档中一定要反映项目的变更,需求文档应精确描述要交付的产品,这就是你的原则。要是软件需求文档同产品不一致,那它就毫无用处,甚至就象没有一个软件需求文档来指导开发组开发一样。当你不得不做出变更时,应该按从高级到低级的顺序对被影响的需求文档进行处理。举个例子,一个已建议的变更可能影响一个使用实例和功能需求但不影响任何业务需求。改动高层系统需求能够影响多个软件需求。如果在最低层需求上做出变更,(典型的情况是一个功能性需求),可能会导致需求同上层文档不一致。17.1 控制项目范围的扩展Capers Jones(1 9 9 4)在报告中声称扩展需求对百分之八十的管理信息系统项目和百分之七十的军事软件项目造成风险。扩展需求是指在软件需求基线已经确定后又要增添新的功能或进行较大改动。问题不仅仅是需求变更本身,而是迟到的需求变更会对已进行的工作有较大的影响。要是每个建议的需求都被采纳,对于项目出资者( s p o n s o r)、参与者与客户来说项目将永远也不会完成—事实上,这是不可能的。对许多项目来说,一些需求的改进是合理的且不可避免。业务过程、市场机会、竞争性的产品和软件技术在开发系统期间是可以变更的,管理部门也会决定对项目做出一些调整。在你的项目进度表中应该对必要的需求改动留有余地。若不控制范围的扩展将使我们持续不断地采纳新的功能,而且要不断地调整资源、进度、或质量目标,这样做极其有害。这儿一点小的改动,那儿一点添加,很快项目就不可能按客户预期的进度和预期质量交付使用了。管理范围扩展的第一步就是把新系统的视图、范围、限制文档化并作为业务需求的一部分,正如第6章所描述的。评估每一项建议的需求和特性,将它与项目的视图和范围相比较决定是否应该采纳它。强调客户参与的有效的需求获取方法能够减少遗漏需求的数量,只在做出提交承诺和分配资源后才采纳该需求(Jones 1996a)。控制需求扩展的另一个有效的技术是原型法,这个方法能够给用户提供预览所有可能的实现,以帮助用户与开发者沟通从而准确把握用户的真实需求( Jones 1994)。
上一篇:管理=做不到的事.ppt34
下一篇:管理层收购.doc16
精品资料网 m.cnshu.cn
Copyright © 2004- 粤ICP备10098620号-1
风险管理 应急预案 研发管理 运营管理 内部管理 商业模式 执行力 连锁经营 公司治理 工厂管理 创新管理 家族企业 效率管理 名企案例 企业理念 价值管理 特许经营 瓶颈管理 调查问卷 策划方案 领导力 团队建设 企业变革 企业文化 战略管理 竞争策略 管理知识 危机管理 成本管理 项目管理 发展战略 年度计划 决策管理 企业上市 供应商 组织设计 产品管理 采购管理 品牌管理 企业诊断 企业咨询 商务谈判 物流管理 运作管理 管理制度 行业报告 经营管理 企划方案 MBA 流程管理 目标管理 招标投标 商务礼仪 管理表格 管理技能 管理案例 管理工具 管理手册 职业经理人 商业计划书 董事与股东 可行性报告