避免Java EE项目评估中的常见错误
考虑经常被忽略的因素，更精确的评估你的软件项目
摘要：
软件开发项目评估是软件开发周期中关键又具备挑战性的一步，它是计划，进度，人员以及其他相关步骤的基础。项目低估会带来紧张的进度，高度压力的工作环境，未可预料的资源紧缺，低质量，项目实施延误等风险， 可以最大限度的破坏客户的生意以及公司的信誉；而另一方面，带有过多不合理泡沫的评估也会导致无效率的资源浪费以及引起客户和公司之间的不信任。评估企业Java项目因为技术的更新成了一个难题，本文通过几个方面透视提供了评估企业Java项目时应该考虑的问题
假如你是一个重要软件项目的项目经理，高层给你的预算已经用完，业务对软件的压力一天天临近，而CIO也已经厌烦了一次次的进度推迟，更要命的是， 你的团队已经被长时间的工作和不合理的进度搞的精疲力尽。这一切听起来是不是很耳熟？这篇文章调查了会导致这种困境的项目评估中常见的错误并提出建议进行提高。
其中的部分论点与技术无关，适用任何软件项目，他们的共同特征是通过不同的方式来提高项目评估。
版权声明：任何获得Matrix授权的网站，转载时请务必保留以下作者信息和链接
作者:Chandan; alexsun(作者的blog: http://blog.matrix.org.cn/page/alexsun)
原文: http://www.matrix.org.cn/resource/article/44/44432_Java+EE.html
关键字:Java EE;project
筛选合适的评估人选
在任何评估过程中,筛选合适的评估人选第一步也是最重要的一步.你需要始终明确的是由合适的人选,而并不一定是最重要的人选,来负责运作分析与评估. 除了正式的评估技术与知识,该人选同时还应当具备该项目的商业领域知识与项目所用的技术知识.一个非技术人员永远都不会明白一个构架约束或技术抉择在真正的开发过程中的含义是什么.
考虑项目建议采用的技术,框架和工具的可用性
Java EE项目可以选择不同的框架与工具,每一种框架都有自己的功能,限制以及学习曲线. 这些因素带来的影响在项目进入开发阶段后非常显著. 在准备一个评估的时候,应当完成初级阶段的调查并找出这些选择对项目的适用性以及影响,在团队目前以及将来的培训中需要适应这些选择.
考虑与 外部/第三方 系统的集成
在软件应用中,外部系统集成是一个千变万化并经常被低估的部分. 更经常的事,在需求文档中仅仅有一行陈述,系统应当使用现存的系统和API 发送/接受 数据. 这部分尤其需要被小心的验证确认, 基于系统细节和通讯协议的复杂性,很多后续的工作需要被计算在内. 如果和外部系统的通信细节”how and when”在作评估的时候不具备的话,这一部分在评估则只能作为设想处理,并且应当被列为在底层设计完成后需要被再评估的部分.请记住,在现实世界中,没有即插即用.
考虑现存的企业构件
大多数组织已经有现成的信息系统的基础构造,一部分可以复用的企业构件是可以并被授权使用在新系统中的. 为了一致性,兼容性,以及节约等不同的原因,客户总是促进兼容.但是,重要的是需要注意到为了达到这种要求,评估中应当包括了解这些构件的设计,和验证它们在新系统中的可行性需要作出的努力.
举个例子, 一个客户可能已经有了用户验证和授权框架,而需要集成到新系统中去.这种情况就存在潜在的”运行时的惊奇”（一般指运行过程中出现错误）。原因是新的业务要求并不是由已经存在的框架来实现的，而且很可能需要某些增强。另外，如果框架的某些功能与限制在评估时还没有具备，那么这必须作为假定记入文档。
考虑已存在的构架标准
考虑现存的标准是另一个在评估经常被忽视的方面,而且对工作造成显著影响, 如果现行标准已经具备的话很多额外工作是可以避免的. 但另一个方面,标准同样可以在实际的设计与实施过程中带来很多限制. 举个例子, 一个简单的要求,获得企业的金融信息并显示在屏幕上,可以简单的在屏幕上增加一个文本区来实现.但是,如果客户已经有了文档服务器来管理整个应用中客户的金融信息就完全是另一回事了. 这样你需要和文档服务器建立通讯协议,exception处理和其他标准.这是一个相当大的工作. 你应该在评估中把构架标准和业务要求放到同等重要的地位.
考虑实际的测试工作量
随着自动测试工具与框架的发展，实际测试工作量已经与学校里古老的创建和执行单元测试的情况大不相同。比如说，如果要求创建和运行JUnit测试案例， 和传统的单元测试方法不同，额外的开发时间和学习曲线是可能的。因此，测试评估中测试的处理方式需要清楚的表明以避免任何分歧。
考虑互相依赖的并行开发
当多个互相依赖的应用在被同时并行开发的时候，情况就更多变了。如果应用依赖于于正在进行的开发， 都需要被标明。每次的交流都应当验证目前的可行性，特别注意给其他开发项目的风险概要。比如，一个应用必须显示用户的信用详细资料，而这个需要同调用企业API通过外部系统获得，但这个企业APIs正在由另一个团队开发，这个API应该在你开发项目的时候处于完成并可用的状态。使用基本的API调用来测试应用然后再用实际调用来替代比直接用实际调用一步到位需要更多的时间，评估应当将这些依赖所产生的影响清楚并专业的标明。
使用 部分-全部 的处理方法
古话说“分而治之”，在软件评估中同样也是这样。将工作分成小块然后对每个小块列出要完成的步骤。这样对每个步骤评估的综合将会比把整个项目当作一个整体来评估精确的多。
结论
今天的IT行业，是按时保质完成产品的激烈竞争，准确的评估是至关重要的。经常被忽略的项目细节，会对评估造成显著的影响。文章中谈到的几点应该与已经成熟的评估技术综合应用，来最大限度消减评估错误的可能。
关于作者
Chandan作为电子商务顾问为印度塔塔咨询服务公司工作超过5年，他近距离参与了为遍布世界的大客户评估，设计以及开发各种大中规模Java EE基础上企业级应用，Chandan作为参与这些项目整个过程的一员分析了评估对开发生命周期过程中不同阶段的影响。作者在印度Jalgaon工程技术学院获得机械工程学士学位。
参考资料:
"Software Project Estimation" by Kathleen Peters:
http://www.spc.ca/downloads/resources/estimate/estbasics.pdf
参考资料“Software Project Estimation”一文详细论述了软件项目评估的四个步骤，开发项目规模评估，开发项目工作量评估，开发项目进度表评估以及开发费用评估，并讨论了在各个步骤的流程，技巧以及常用的计算公式。
Matrix: http://www.matrix.org.cn
Javaworld: http://www.Javaworld.com
摘要：
软件开发项目评估是软件开发周期中关键又具备挑战性的一步，它是计划，进度，人员以及其他相关步骤的基础。项目低估会带来紧张的进度，高度压力的工作环境，未可预料的资源紧缺，低质量，项目实施延误等风险， 可以最大限度的破坏客户的生意以及公司的信誉；而另一方面，带有过多不合理泡沫的评估也会导致无效率的资源浪费以及引起客户和公司之间的不信任。评估企业Java项目因为技术的更新成了一个难题，本文通过几个方面透视提供了评估企业Java项目时应该考虑的问题
假如你是一个重要软件项目的项目经理，高层给你的预算已经用完，业务对软件的压力一天天临近，而CIO也已经厌烦了一次次的进度推迟，更要命的是， 你的团队已经被长时间的工作和不合理的进度搞的精疲力尽。这一切听起来是不是很耳熟？这篇文章调查了会导致这种困境的项目评估中常见的错误并提出建议进行提高。
其中的部分论点与技术无关，适用任何软件项目，他们的共同特征是通过不同的方式来提高项目评估。
版权声明：任何获得Matrix授权的网站，转载时请务必保留以下作者信息和链接
作者:Chandan; alexsun(作者的blog: http://blog.matrix.org.cn/page/alexsun)
原文: http://www.matrix.org.cn/resource/article/44/44432_Java+EE.html
关键字:Java EE;project
筛选合适的评估人选
在任何评估过程中,筛选合适的评估人选第一步也是最重要的一步.你需要始终明确的是由合适的人选,而并不一定是最重要的人选,来负责运作分析与评估. 除了正式的评估技术与知识,该人选同时还应当具备该项目的商业领域知识与项目所用的技术知识.一个非技术人员永远都不会明白一个构架约束或技术抉择在真正的开发过程中的含义是什么.
考虑项目建议采用的技术,框架和工具的可用性
Java EE项目可以选择不同的框架与工具,每一种框架都有自己的功能,限制以及学习曲线. 这些因素带来的影响在项目进入开发阶段后非常显著. 在准备一个评估的时候,应当完成初级阶段的调查并找出这些选择对项目的适用性以及影响,在团队目前以及将来的培训中需要适应这些选择.
考虑与 外部/第三方 系统的集成
在软件应用中,外部系统集成是一个千变万化并经常被低估的部分. 更经常的事,在需求文档中仅仅有一行陈述,系统应当使用现存的系统和API 发送/接受 数据. 这部分尤其需要被小心的验证确认, 基于系统细节和通讯协议的复杂性,很多后续的工作需要被计算在内. 如果和外部系统的通信细节”how and when”在作评估的时候不具备的话,这一部分在评估则只能作为设想处理,并且应当被列为在底层设计完成后需要被再评估的部分.请记住,在现实世界中,没有即插即用.
考虑现存的企业构件
大多数组织已经有现成的信息系统的基础构造,一部分可以复用的企业构件是可以并被授权使用在新系统中的. 为了一致性,兼容性,以及节约等不同的原因,客户总是促进兼容.但是,重要的是需要注意到为了达到这种要求,评估中应当包括了解这些构件的设计,和验证它们在新系统中的可行性需要作出的努力.
举个例子, 一个客户可能已经有了用户验证和授权框架,而需要集成到新系统中去.这种情况就存在潜在的”运行时的惊奇”（一般指运行过程中出现错误）。原因是新的业务要求并不是由已经存在的框架来实现的，而且很可能需要某些增强。另外，如果框架的某些功能与限制在评估时还没有具备，那么这必须作为假定记入文档。
考虑已存在的构架标准
考虑现存的标准是另一个在评估经常被忽视的方面,而且对工作造成显著影响, 如果现行标准已经具备的话很多额外工作是可以避免的. 但另一个方面,标准同样可以在实际的设计与实施过程中带来很多限制. 举个例子, 一个简单的要求,获得企业的金融信息并显示在屏幕上,可以简单的在屏幕上增加一个文本区来实现.但是,如果客户已经有了文档服务器来管理整个应用中客户的金融信息就完全是另一回事了. 这样你需要和文档服务器建立通讯协议,exception处理和其他标准.这是一个相当大的工作. 你应该在评估中把构架标准和业务要求放到同等重要的地位.
考虑实际的测试工作量
随着自动测试工具与框架的发展，实际测试工作量已经与学校里古老的创建和执行单元测试的情况大不相同。比如说，如果要求创建和运行JUnit测试案例， 和传统的单元测试方法不同，额外的开发时间和学习曲线是可能的。因此，测试评估中测试的处理方式需要清楚的表明以避免任何分歧。
考虑互相依赖的并行开发
当多个互相依赖的应用在被同时并行开发的时候，情况就更多变了。如果应用依赖于于正在进行的开发， 都需要被标明。每次的交流都应当验证目前的可行性，特别注意给其他开发项目的风险概要。比如，一个应用必须显示用户的信用详细资料，而这个需要同调用企业API通过外部系统获得，但这个企业APIs正在由另一个团队开发，这个API应该在你开发项目的时候处于完成并可用的状态。使用基本的API调用来测试应用然后再用实际调用来替代比直接用实际调用一步到位需要更多的时间，评估应当将这些依赖所产生的影响清楚并专业的标明。
使用 部分-全部 的处理方法
古话说“分而治之”，在软件评估中同样也是这样。将工作分成小块然后对每个小块列出要完成的步骤。这样对每个步骤评估的综合将会比把整个项目当作一个整体来评估精确的多。
结论
今天的IT行业，是按时保质完成产品的激烈竞争，准确的评估是至关重要的。经常被忽略的项目细节，会对评估造成显著的影响。文章中谈到的几点应该与已经成熟的评估技术综合应用，来最大限度消减评估错误的可能。
关于作者
Chandan作为电子商务顾问为印度塔塔咨询服务公司工作超过5年，他近距离参与了为遍布世界的大客户评估，设计以及开发各种大中规模Java EE基础上企业级应用，Chandan作为参与这些项目整个过程的一员分析了评估对开发生命周期过程中不同阶段的影响。作者在印度Jalgaon工程技术学院获得机械工程学士学位。
参考资料:
"Software Project Estimation" by Kathleen Peters:
http://www.spc.ca/downloads/resources/estimate/estbasics.pdf
参考资料“Software Project Estimation”一文详细论述了软件项目评估的四个步骤，开发项目规模评估，开发项目工作量评估，开发项目进度表评估以及开发费用评估，并讨论了在各个步骤的流程，技巧以及常用的计算公式。
Matrix: http://www.matrix.org.cn
Javaworld: http://www.Javaworld.com