下列关于需求变更影响分析的做法中,( )是错误的。

admin2015-05-21  27

问题 下列关于需求变更影响分析的做法中,(    )是错误的。

选项 A、需求主管人员把需求变更的优先级分为5级
B、建立一个需求决策数据库,根据数据库内容指导变更决策
C、没有代价或不影响进度的变更可直接实施
D、变更分析流程需考虑:涉及问题核对、影响软件元素核对、评估变更工时、评估工作值总和、任务顺序、变更对路径的影响、对进度成本的影响、优先级等

答案C

解析 变更控制的目的并不是控制变更的发生,而是对变更进行管理,确保变更有序进行。对于软件开发项目来说,发生变更的环节比较多,因此变更控制显得格外重要。
    项目中引起变更的因素有两个:一是来自外部的变更要求,如客户要求修改工作范围和需求等;二是开发过程内部的变更要求,如为解决测试中发现的一些错误而修改源码甚至设计。比较而言,最难处理的是来自外部的需求变更,因为IT项目需求变更的概率大,引发的工作量也大(特别是到项目的后期)。
变更控制不能仅在过程中靠流程控制,有效的方法是在事前明确定义。事前控制的一种方法是在项目开始前明确定义,否则“变化”也无从谈起。另一种方法是评审,特别是对需求进行评审,这往往是项目成败的关键。需求评审的目的不仅是“确认”,更重要的是找出不正确的地方并进行修改,使其尽量接近“真实”需求。另外,需求通过正式评审后应作为重要基线,从此之后即开始对需求变更进行控制。
    按照现代项目管理的概念,一个项目的生命周期分为启动、实施、收尾三个过程。需求变更的控制不应该只是项目实施过程考虑的事情,而是要分布在整个项目生命周期的全过程。为了将项目变更的影响降低到最小,就需要采用综合变更控制方法。综合变更控制主要内容有找出影响项目变更的因素、判断项目变更范围是否已经发生等。
    进行综合变更控制的主要依据是项目计划、变更请求和提供了项目执行状况信息的绩效报告。
    1.项目启动阶段的变更预防
    对于任何项目,变更都无可避免,也无从逃避,只能积极应对,这应该是从项目启动的需求分析阶段就开始了。对一个需求分析做得很好的项目来说,基准文件定义的范围越详细清晰,用户跟项目经理扯皮的幌子就越少。如果需求没做好,基准文件里的范围含糊不清,被客户抓住空子,往往要付出许多无谓的牺牲。如果需求做得好,文档清晰且又有客户签字,那么后期客户提出的变更就超出了合同范围,需要另外收费。这个时候千万不能手软,这并非要刻意赚取客户的钱财,而是不能让客户养成经常变更的习惯,否则后患无穷。相对于需求来说,WBS、风险管理、计划进度都是次要的,只要需求做好了就会一帆风顺。
    2.项目实施阶段的需求变更
    成功项目和失败项目的区别就在于项目的整个过程是否是可控的。项目经理应该树立一个理念——“需求变更是必然的、可控的、有益的”。项目实施阶段的变更控制需要做的是分析变更请求,评估变更可能带来的风险和修改基准文件。控制需求渐变需要注意以下几点:
    需求一定要与投入有联系,如果需求变更的成本由开发方来承担,则项目需求的变更就成为必然了。所以,在项目的开始,无论是开发方还是出资方都要明确这一条:需求变,软件开发的投入也要变。
    需求的变更要经过出资者的认可,这样才会对需求的变更有成本的概念,能够慎重地对待需求的变更。
    小的需求变更也要经过正规的需求管理流程,否则会积少成多。在实践中,人们往往不愿意为小的需求变更去执行正规的需求管理过程,认为降低了开发效率,浪费了时间。但正是由于这种观念才使需求逐渐变为不可控,最终导致项目的失败。
    精确的需求与范围定义并不会阻止需求的变更。并非对需求定义得越细,就越能避免需求的渐变,这是两个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的,并非需求写细了,它就不会变化了。
  3.项目收尾阶段的总结
  事实上,项目总结工作应作为现有项目或将来项目持续改进工作的一项重要内容,同时也可以作为对项目合同、设计方案内容与目标的确认和验证。项目总结工作包括项目中事先识别的风险和没有预料到而发生的变更等风险的应对措施的分析和总结,也包括项目中发生的变更和项目中发生问题的分析统计的总结。
    没有代价或不影响进度的变更可直接实施是错误的。
转载请注明原文地址:https://kaotiyun.com/show/S0GZ777K
0

相关试题推荐
最新回复(0)