项目各个过程的时间把握
比如，一个项目的总投入时间为90天。
那么，编码、单体测试、代码检查、评价等各个过程分别应该占多少天比较合理。
有没有相关的公式之类的？
或介绍相关知识的书籍？
最好发个链接 ，谢谢
[解决办法]
具体问题具体分析
[解决办法]
你们公司没有历史数据可以供参考吗？
没有的话就多问问公司的老人，他们拍脑袋还是比较准的，综合几个人拍脑袋的结果应该会靠谱一点
一家之言仅供参考
祝你成功
[解决办法]
今天正好别人问我有没有《人月神话》这本书，我正好有就发了别人电子版，顺便看了一下当时看的时候做的一些笔记，发现有写内容对楼主有帮助。
在时间进度中，顺序限制所造成的影响，没有哪个部分比单元调试和系统测试所受到
的牵涉更彻底。而且，要求的时间依赖于所遇到的错误、缺陷数量以及捕捉它们的程度。理
论上，缺陷的数量应该为零。但是，由于我们的乐观主义，通常实际出现的缺陷数量比预料
的要多得多。因此，系统测试进度的安排常常是编程中最不合理的部分。
对于软件任务的进度安排，以下是我使用了很多年的经验法则：
1/3 计划
1/6 编码
- 10 -
1/4 构件测试和早期系统测试
1/4 系统测试，所有的构件已完成
在许多重要的方面，它与传统的进度安排方法不同：
1. 分配给计划的时间比寻常的多。即便如此，仍不足以产生详细和稳定的计划规格说
明，也不足以容纳对全新技术的研究和摸索。
2. 对所完成代码的调试和测试，投入近一半的时间，比平常的安排多很多。
3. 容易估计的部分，即编码，仅仅分配了六分之一的时间。
通过对传统项目进度安排的研究，我发现很少项目允许为测试分配一半的时间，但大
多数项目的测试实际上是花费了进度中一半的时间。它们中的许多项目，在系统测试之前还
2
能保持进度。或者说，除了系统测试，进度基本能保证 。
特别需要指出的是，不为系统测试安排足够的时间简直就是一场灾难。因为延迟发生
在项目快完成的时候。直到项目的发布日期，才有人发现进度上的问题。因此，坏消息没有
任何预兆，很晚才出现在客户和项目经理面前。
另外，此时此刻的延迟具有不寻常的、严重的财务和心理上的反应。在此之前，项目
已经配置了充足的人员，每天的人力成本也已经达到了最大的限度。更重要的是，当软件用
来支持其他的商业活动（计算机硬件到货，新设备、服务上线等等）时，这些活动延误出现
即将发布前，那么将付出相当高的商业代价。
实际上，上述的二次成本远远高于其他开销。因此，在早期进度策划时，允许充分的
系统测试时间是非常重要的。
[解决办法]
软件开发过程的工作量和时间的分配没有固定的比例
一般是
需求：20%，设计 30%，开发 20% 测试 30%
不过根据具体情况，如果项目组强人比较多设计的比例可以少点！
[解决办法]
你的时间都出来了，看来要倒排工期了，那些比例其实都是大公司的经验 ，但各个
公司的环境和开发能力不一样，你可以参考，你自己根据项目的进展时时估计，把时辰的问题随时报告给你的老板，不然项目
达不成目标全部都是你的问题，你可以在项目进行过程中说明自己的地困难，到最后项目达不成目标你可以拿一些数据来说明你的难处
不然最后你就要承担全部责任了
[解决办法]
需求一定要早截止，一点点的加需求，项目就要一天天的延期或者稳定性就很难保证
90天的话就是
15天的时间需求
20天设计
10天编码
10天UT
剩下的ST
[解决办法]
个人觉得，一个项目最终的质量是受到三方面限制的， 时间仅仅是其中的一个，投入和项目范围是其他2个因素。三个因素成三角形，中心就是项目最终的质量。
往往很多项目的总时间都是被预定的，那么就要投入和项目范围了， 如果投入很大，而范围相对小，最后的时间久能够保证。
对于楼主来说，就要项目初始的投入多大，已经期望的项目范围，知道这2个因素，才能好估算时间