软件变更控制—控制成本溢出

Posted testor

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了软件变更控制—控制成本溢出相关的知识,希望对你有一定的参考价值。

       技术分享图片
       软件生命周期中,软件修复成本金字塔,越往下修改成本越大。
  需求阶段发现需求变更代价最小,其他由小到大依次是设计阶段 ,编码阶段,测试阶段,当到达用户测试阶段和维护阶段时,此时修改代码的代价是原来的5-20倍以上,所以这就是需求阶段就与用户沟通,给他们看原型评审,进行需求确认的意义,减少风险,节约成本。
  10月份XXX系统进行需求变更,增加了香港的需求后,新功能做完了,改出来上百个bug,按照经验个人认为是由于在系统测试阶段才进行修改代码的代价。建议以后的项目,必须增加需求确认环节,需求肯定会变,但我们要管理和控制它,让它在一个可控范围内。比如黑龙江就应该在作出原型,画完流程图后与用户确认,这样才能减少我们的成本超标风险。
  <b "="">举例:
  比如需求1和需求2在一开始就开发,它们各自的成本是5人/天,一次性开发是10人/天。
  由于需求2一开始并未提出,项目组只开发了需求1,进入测试阶段后,发现需求2也要开发,此时需求2的成本按照软件工程理论翻倍5-20倍,假设为5*5=25,那么总成本可能为30人/天。
       想了解更多关于测试方面的文章,请前往51Testing软件测试网(http://www.51testing.com)哈~
 

以上是关于软件变更控制—控制成本溢出的主要内容,如果未能解决你的问题,请参考以下文章

Scrum中的变更控制

版本控制

版本控制 gitlab

信息系统项目管理师项目变更管理

gitlab部署

需求变更管理