避免JavaEE项目评估中的常见错误

文章作者 100test 发表时间 2007:03:14 16:40:30
来源 100Test.Com百考试题网

摘要：
软件开发项目评估是软件开发周期中关键又具备挑战性的一步，它是计划，进度，人员以及其他相关步骤的基础。项目低估会带来紧张的进度，高度压力的工作环境，未可预料的资源紧缺，低质量，项目实施延误等风险， 可以最大限度的破坏客户的生意以及公司的信誉；而另一方面，带有过多不合理泡沫的评估也会导致无效率的资源浪费以及引起客户和公司之间的不信任。评估企业Java项目因为技术的更新成了一个难题，本文通过几个方面透视提供了评估企业Java项目时应该考虑的问题

假如你是一个重要软件项目的项目经理，高层给你的预算已经用完，业务对软件的压力一天天临近，而CIO也已经厌烦了一次次的进度推迟，更要命的是， 你的团队已经被长时间的工作和不合理的进度搞的精疲力尽。这一切听起来是不是很耳熟？这篇文章调查了会导致这种困境的项目评估中常见的错误并提出建议进行提高。
其中的部分论点与技术无关，适用任何软件项目，他们的共同特征是通过不同的方式来提高项目评估。

筛选合适的评估人选
在任何评估过程中,筛选合适的评估人选第一步也是最重要的一步.你需要始终明确的是由合适的人选,而并不一定是最重要的人选,来负责运作分析与评估. 除了正式的评估技术与知识,该人选同时还应当具备该项目的商业领域知识与项目所用的技术知识.一个非技术人员永远都不会明白一个构架约束或技术抉择在真正的开发过程中的含义是什么.

考虑项目建议采用的技术,框架和工具的可用性
Java EE项目可以选择不同的框架与工具,每一种框架都有自己的功能,限制以及学习曲线. 这些因素带来的影响在项目进入开发阶段后非常显著. 在准备一个评估的时候,应当完成初级阶段的调查并找出这些选择对项目的适用性以及影响,在团队目前以及将来的培训中需要适应这些选择.

考虑与 外部/第三方 系统的集成
在软件应用中,外部系统集成是一个千变万化并经常被低估的部分. 更经常的事,在需求文档中仅仅有一行陈述,系统应当使用现存的系统和API 发送/接受 数据. 这部分尤其需要被小心的验证确认, 基于系统细节和通讯协议的复杂性,很多后续的工作需要被计算在内. 如果和外部系统的通信细节”how and when”在作评估的时候不具备的话,这一部分在评估则只能作为设想处理,并且应当被列为在底层设计完成后需要被再评估的部分.请记住,在现实世界中,没有即插即用.

考虑现存的企业构件
大多数组织已经有现成的信息系统的基础构造,一部分可以复用的企业构件是可以并被授权使用在新系统中的. 为了一致性,兼容性,以及节约等不同的原因,客户总是促进兼容.但是,重要的是需要注意到为了达到这种要求,评估中应当包括了解这些构件的设计,和验证它们在新系统中的可行性需要作出的努力.

举个例子, 一个客户可能已经有了用户验证和授权框架,而需要集成到新系统中去.这种情况就存在潜在的”运行时的惊奇”（一般指运行过程中出现错误）。原因是新的业务要求并不是由已经存在的框架来实现的，而且很可能需要某些增强。另外，如果框架的某些功能与限制在评估时还没有具备，那么这必须作为假定记入文档。