筛选合适的评估人选
在任何评估过程中，筛选合适的评估人选第一步也是最重要的一步。你需要始终明确的是由合适的人选，而并不一定是最重要的人选，来负责运作分析与评估。 除了正式的评估技术与知识，该人选同时还应当具备该项目的商业领域知识与项目所用的技术知识。一个非技术人员永远都不会明白一个构架约束或技术抉择在真正的开发过程中的含义是什么。
考虑项目建议采用的技术，框架和工具的可用性
Java EE项目可以选择不同的框架与工具，每一种框架都有自己的功能，限制以及学习曲线。 这些因素带来的影响在项目进入开发阶段后非常显著。 在准备一个评估的时候，应当完成初级阶段的调查并找出这些选择对项目的适用性以及影响，在团队目前以及将来的培训中需要适应这些选择。
考虑与 外部/第三方 系统的集成
在软件应用中，外部系统集成是一个千变万化并经常被低估的部分。 更经常的事，在需求文档中仅仅有一行陈述，系统应当使用现存的系统和API 发送/接受 数据。 这部分尤其需要被小心的验证确认， 基于系统细节和通讯协议的复杂性，很多后续的工作需要被计算在内。 如果和外部系统的通信细节“how and when”在作评估的时候不具备的话，这一部分在评估则只能作为设想处理，并且应当被列为在底层设计完成后需要被再评估的部分。请记住，在现实世界中，没有即插即用。
考虑现存的企业构件
大多数组织已经有现成的信息系统的基础构造，一部分可以复用的企业构件是可以并被授权使用在新系统中的。 为了一致性，兼容性，以及节约等不同的原因，客户总是促进兼容。但是，重要的是需要注意到为了达到这种要求，评估中应当包括了解这些构件的设计，和验证它们在新系统中的可行性需要作出的努力。
举个例子， 一个客户可能已经有了用户验证和授权框架，而需要集成到新系统中去。这种情况就存在潜在的“运行时的惊奇”（一般指运行过程中出现错误）。原因是新的业务要求并不是由已经存在的框架来实现的，而且很可能需要某些增强。另外，如果框架的某些功能与限制在评估时还没有具备，那么这必须作为假定记入文档。
考虑已存在的构架标准
考虑现存的标准是另一个在评估经常被忽视的方面，而且对工作造成显著影响， 如果现行标准已经具备的话很多额外工作是可以避免的。 但另一个方面，标准同样可以在实际的设计与实施过程中带来很多限制。 举个例子， 一个简单的要求，获得企业的金融信息并显示在屏幕上，可以简单的在屏幕上增加一个文本区来实现。但是，如果客户已经有了文档服务器来管理整个应用中客户的金融信息就完全是另一回事了。 这样你需要和文档服务器建立通讯协议，exception处理和其他标准。这是一个相当大的工作。 你应该在评估中把构架标准和业务要求放到同等重要的地位。
考虑实际的测试工作量
随着自动测试工具与框架的发展，实际测试工作量已经与学校里古老的创建和执行单元测试的情况大不相同。比如说，如果要求创建和运行JUnit测试案例， 和传统的单元测试方法不同，额外的开发时间和学习曲线是可能的。因此，测试评估中测试的处理方式需要清楚的表明以避免任何分歧。
考虑互相依赖的并行开
发当多个互相依赖的应用在被同时并行开发的时候，情况就更多变了。如果应用依赖于于正在进行的开发， 都需要被标明。每次的交流都应当验证目前的可行性，特别注意给其他开发项目的风险概要。比如，一个应用必须显示用户的信用详细资料，而这个需要同调用企业API通过外部系统获得，但这个企业APIs正在由另一个团队开发，这个API应该在你开发项目的时候处于完成并可用的状态。使用基本的API调用来测试应用然后再用实际调用来替代比直接用实际调用一步到位需要更多的时间，评估应当将这些依赖所产生的影响清楚并专业的标明。
使用 部分-全部 的处理方法
古话说“分而治之”，在软件评估中同样也是这样。将工作分成小块然后对每个小块列出要完成的步骤。这样对每个步骤评估的综合将会比把整个项目当作一个整体来评估精确的多。
结论
今天的IT行业，是按时保质完成产品的激烈竞争，准确的评估是至关重要的。经常被忽略的项目细节，会对评估造成显著的影响。文章中谈到的几点应该与已经成熟的评估技术综合应用，来最大限度消减评估错误的可能。
