在IT领域最困难的工作之一就是对一项具体的提议如何评估时间和资源。软件开发尤其如此，甚至比评估一个基础设施项目更难，因为基础设施项目并不能直接地用业务和终端用户群体来处理。软件开发项目的范围经常改变，一直到最终的令人疯狂的产品部署，消耗成本，时间超支，开发人员精疲力竭。那么，如何避免这些常规问题呢？

　　从用例开始

　　正确地评估一个Java项目是艺术和科学的组合。自从Java和J2EE规范为企业类解决方案创建以来，它唯一的意义就是采取一种企业强度的方法来评价项目规模和成本。这意味着在编写一行代码之前做一些预先的分析，可以从基于用例的方法开始。

　　一个用例是用来描述一个系统对于来自一个角色的动作的响应，这个角色通常是一个终端用户。用例很好地映射了用户案例的敏捷产品。这意味着一旦你为一个项目提议识别并分析（文档化）了很多用例，这个项目以性能和功能著称，你就可以创建用户案例，输入到一个 基于敏捷的开发周期中。

　　确保精准的用例

　　在开始写用例的时候，很容易将技术和物理设计假设在一中高水平的功能上结合。下面这些用例供参考：

　　“这个系统允许应用管理员通过设置规则来限制系统负载，这个规则限制用户组的报告执行或者重定向其批处理流的执行。”

　　我们做了数个假设，假设系统不能扩展处理负载，因此必须创建一个功能用来管理假设的限制。一种比较好的途径是编写像下面这样的用例：

　　“这个系统支持200个以上的并发运行的报告，每日最大量为50万个报告。”

　　更为精确的用例以及更少的假设，可以导致更好的用户案例，项目开发时减少变动范围。

　　评估基础

　　一旦开发了用例，项目范围就可以确定，评估就可以开始了。通过评估团队中最慢的那个人开始。一些开发者完成一项任务要比其他人花费更多的时间，但是让开发者评估编码和单元测试任务是最适合他们做的。

　　也要考虑时间，可能从设置开发、测试和产品环境。如果不能提前完成或者在计划活动时完成，这些任务可以吸收很多其他的生产时间。

　　现在就开始推测。没有一个项目评估可以预先准确地知道，但是通过使用下面的评估算法，可以得到一个合理的推测结果：

　　第一步：确定网页、屏幕、数据表、接口和转换的数量是每一个用例的要求。并不是每一个用例都要包含这些。试想每个页面或者屏幕一个或者半个人周，每个接口三个人周，数据表一个人周，转化数据一个人周。通过对象创建的数量评估人周更为精确，但是我们还没有那个数据。

　　第二步：评估每个用例的编码和单元测试。使用步骤一中的结果，你可以轻易地计算出多个用例的基本的评估。例如，一系列用例包含四个页面、两个接口、五个数据表，没有数据转换，评估如下：

• 　　(4 x 1.5) + (2 x 3) + (5 x 1) + (0 x 1) = 17人周或者680个小时。

　　第三步：把步骤二中的结果乘以2.5，就可以为每一个用例的分析和测试算出总和。通过数学运算，我们现在的这个项目需要1700个小时。

　　第四步：为每增加一个开发人员增加20%的估计值。基本估计假设只有一个开发者。通过增加更多的开发者，在团队成员之间就会有沟通和协调的固定开支。我们假设有三个开发者，因此我们需要增加40%（多增加两个人）的估计值。基础评估乘以40%，并将这个数字加到基础评估值上：

• 　　0.4 x 1700 = 680小时
• 　　680 + 1700 = 2380小时

　　第五步：让开发者花一点时间去检查一下最终的评估，看一下是否有意义，在提交评估进行管理之前是否需要改善。

　　总结

　　评估流程被这样描述，交涉你的IT 团队使用基于用例的方法作为这个项目管理流程的一部分。用例通常是Java项目开始评估流程的最佳方法。在使用这种方法的最初评估改进之后，应该在主里程碑交付日期上在检查，从而确保评估仍旧有效。无论使用什么评估方法，实际旅程可能改变。要用不同的人周价值进行实验并调整评估结果。