调查：软件开发过程中工作量（成本）都是如何分布的？

看了此贴，想起一句话“屁股决定脑袋”

呵呵，讨论得越来越偏题了... 希望更多有PM经验的朋友们来投投票...

软件的生命周期并非到生产结束系统上线后就结束了，所以生产成本只是所有成本的一部分，软件上线后期的维护成本是相当惊人的，遗憾的是大部分PM和客户都没有意识到这一点。他们关注的是软件生产过程中业务功能的实现，而忽视非功能性需求和服务质量的需求。
非功能性需求和服务质量需求事关软件的运维成本，占到整个成本的50%以上，直接影响到客户满意度和客户关系的维系。太多的项目在上线后两年内被替换，因为人们发现，用了xxx系统后，每天都像热锅上的蚂蚁。一个业务需求的变更，哪怕是微小的局部变东，如果在生产阶段没有前瞻性，没有良好的设计，后期的运维将是非常痛苦的，琐碎的小改动，日积月累，加上人员的变动，使系统无法维系下去。
这体现在PM和客户在“战略和战术”两方面的欠缺，欠缺前瞻性的眼光，欠缺过硬的技术。当然，他们也有共识，项目当政绩来做，上线后向上邀功，拿到大部门项目款完事

说得好，所以在软件研发过程中对于质量和可扩展性、对需求变化的响应能力的要求是很高的。不过事实上很多项目对现在的需求都不满足，一上线以后直接出现问题或者用不起来。这是我们现在面对的严重问题。

PM本人，事实上不只是只对某个项目的某次生产过程负责，大部分情况下，只要还在公司做的话，基本上以前所负责的项目其责任仍然会沿袭下来，后面的维护和服务都会产生费用，成为项目成本的一部分。不过某些情况下，这一部分费用被转换到了服务费用中去了。发生这些情况，项目是部分失败的。

总之，在前期进行足够的调研/需求/设计，完全是有必要的。我所了解的项目中，很少有真正成功满意的项目，可能正因为很多时间放在了具体实现上，而不是构建这个概念思维系统上。

我估算一下我们目前的情况：
A 30%
B 70%

也许我们期待的应该是
A 50%
B 50%
?

在《人月神话》中作者提到了自己的经验法则是：
1/3计划、1/6编码、1/4构建测试和早期系统测试、1/4系统测试。

工作量分布情况需要视实际项目而定，新项目所需要的设计时间总是要高于比较熟悉的项目的设计时间，但总的说来还是要保证有充足的设计时间，否则越到后续环节，问题的爆发越会成指数级别增长。
项目的时间管理中有叫做PSP和TSP的东西，它们可以帮助进行项目时间管理分析和经验积累，我觉得经验这个东西还是从自己做的项目中来得实在，LZ不妨可以使用这个看看，也许不久之后，这些数据就可以回答你的问题了。

计划、调研、分析、设计、编码、测试都是生产过程中的环节，成本应该包括过程中的所有环节产生的成本，而产出物应该包括各个环节的产出物，具体成本分布率须根据不同的项目（新/旧、熟悉/不熟悉等因素）、不同的软件开发过程而定。

个人认为<<人月神话>>等文中提到的分布率，只是个参考依据罢了。

上面是一点点不成熟的意见，不知当讲否！

看来目前大家都没有特别去收集数据.... 给个经验值吧？

我也没有特意去收集数据，但是总感觉我们花在编码之外的时间其实很多的，但是又经常跟编码掺和在一起，跟维护掺和在一起。

编码只是软件的冰山一角（尤其对于企业应用软件），不过很多程序员没意识到这个问题。
A 70%
B 30%

为什么能力强的要当救火队员？我始终想不明白，我想尽办法都好象走不出救火队员这个角色。
A 60%
B 40%

不错，有功就成，javahands@hotmail.com  有时间加我msn 一块聊天