开发成本与维护成本

Ale*_*äll 33 maintenance

我试图向我们的销售部门解释开发与维护成本的比例,目前我的主要感觉是我们花费了大约60%的时间进行维护.

我们团队中有些人倾向于销售我们必须建立的定制解决方案,如果销售人员不了解开发的总成本,那么他们将无法以实际价格出售.

另一个"问题"是我们正在扩展我们的服务,并且需要重构一些底层基础设施,以缩短上市时间和其他测量点.

为了建立一个可靠的论点,你对我应该参考什么有什么好的建议吗?为了让他们对问题有一个很好的理解,我应该提出哪些要点?

也许在某些地方我可以指出一些很棒的文字.

Jes*_*her 29

在Robert L. Glass撰写的"软件工程经常被遗忘的基本事实"(IEEE Software May/June 2001中的一篇文章)中,他谈到软件"60/60"规则,即维护通常消耗40%到80%(平均60%的软件成本,然后该增强约占软件维护成本的60%,而纠错约为17%.


Joh*_*ers 15

在行业工作29年后,我可以说维护费用占总成本的60-80%.发展最多为20%.但是,如今大多数公司似乎都没有承认他们最关注的是快速开发并在没有适当估算的情况下设定截止日期.这迫使开发人员转储和转移,这只会使维护更加困难.那么高管们做了什么呢?他们丢弃所有内部软件并购买第三方的东西.那么系统集成的噩梦就会发生,也许4到5年后它们将会变得更好,但是这样做的成本比预先花费时间和第一次做正确的成本要高得多.与此同时,所有经验丰富的老定时器都挂了他们的帽子,一群新的年轻人以"我们可以解决任何问题"的态度进入.而且,我的朋友是他们将要做的很长一段时间.

这就是为什么敏捷最终赢了我,因为瀑布在软件中不起作用.永远不会,也永远不会.这都是关于较小的工作迭代和零件开发.就像亨利福特在1900年向我们展示的......

  • 问题是,你什么时候开始逐步设计汽车发动机?在机械领域,他们并没有真正通过敏捷方法从头开始设计汽车的主要部件(或他们的关系) - 他们只是建立了设计模式(这已经从一个多世纪的内燃机使用中出现),他们可能会使用敏捷原则进行优化,但不会从根本上重新定义.在软件中,基本的重新定义很常见,这就是为什么最大的IT项目(通常设计用于集成较小但功能齐全的零碎解决方案)容易出现故障. (2认同)
  • 他们设计并逐步设计汽车。只是,周期要长得多-由于设计和制造之间的成本分配不同。编写代码等同于设计汽车。编译是虚构。对于软件而言,制造仅花费一吨,而设计则花费一吨。对于汽车而言则相反。因此,软件可接受数百万个重新设计/制造周期,但汽车不可接受。基于类似的推论,整个汽车制造行业可以被同一个项目的一大堆分支所同化,其复杂性可能会更高。 (2认同)

Ham*_*jan 7

研究技术债务的概念.此外,尝试与销售人员一起出去玩.有可能他们不是邪恶或不关心; 他们只是接触过不同的东西,拥有与你不同的技能和兴趣.软技能很重要.最大的错误就是让他们知道"他们不懂计算机".我曾与之合作过的最简单的销售人员是前QA,所以他得到了很多东西.顺便说一下,销售人员的工作就是改变真相并保持这些美元的到来.在不承担太多技术债务和不错过商机的情况下,这是微妙的平衡.