Avoid Common Errors in Java EE Project Evaluation

Consider the often overlooked factors to evaluate your software project more accurately

Abstract:
Software development project evaluation is a key and challenging step in the software development cycle. It is the basis for planning, progress, personnel, and other related steps. Underestimating a project will lead to a tight schedule, a highly stressful working environment, unexpected resource shortage, low quality, project implementation delays, and other risks, it can damage the customer's business and the company's reputation to the maximum extent. On the other hand, the evaluation with too many unreasonable bubbles will also lead to waste of inefficient resources and lead to distrust between the customer and the company. The evaluation of Enterprise Java projects has become a challenge because of the technical updates. This article provides several perspectives on the issues that should be considered when evaluating Enterprise Java projects.

If you are a project manager for an important software project, the budget provided by the senior management has been used up, and the Business pressure on the software is approaching day by day, and CIOs are tired of delaying the process, even worse, your team has been exhausted by long work and unreasonable progress. Does it sound familiar? This article investigates common errors that may cause such difficulties in project evaluation and provides suggestions for improvement.
Some of these arguments have nothing to do with technology and apply to any software project. Their common feature is to improve project evaluation in different ways.

Copyright Disclaimer: Any website authorized by matrix must retain the following author information and links for reprinting.
Author: Chandan; alexsun (author's blog: http://blog.matrix.org.cn/page/alexsun)
Original article: http://www.matrix.org.cn/resource/article/44/44432_Java+EE.html
Keywords: Java EE; Project

Select appropriate candidates for evaluation
In any evaluation process, the first step is also the most important step. what you need to always be clear about is that appropriate candidates, not necessarily the most important ones, are responsible for operational analysis and evaluation. in addition to formal evaluation techniques and knowledge, the candidate should also have the business field knowledge of the project and the technical knowledge used by the project. A non-technical person will never understand what a framework constraint or technical choice means in a real development process.

Consider the availability of technologies, frameworks, and tools recommended for the project
Java EE projects can select different frameworks and tools. Each framework has its own functions, limitations, and learning curves. the effects of these factors are significant after the project enters the development stage. when preparing an evaluation, you should complete the Preliminary Phase Investigation and find out the applicability and impact of these options on the project. These options should be adapted to the current and future training of the team.

Integration with external/third-party systems
In software applications, external system integration is an ever-changing and often underestimated part. more often, there is only one line of statement in the requirement document. The system should use the existing system and API to send/receive data. in particular, this part requires careful verification and validation. Based on the complexity of system details and communication protocols, a lot of subsequent work needs to be included. if the communication details "How and when" with external systems are not available during the evaluation, this part of the evaluation can only be processed as an assumption, it should be listed as the part that needs to be re-evaluated after the underlying design is completed. remember, in the real world, there is no plug-and-play.

Consider existing enterprise components
Most organizations already have basic structures of ready-made information systems. Some reusable enterprise components can be used and authorized in new systems. for consistency, compatibility, and savings, the customer always promotes compatibility. however, it is important to note that in order to meet such requirements, the evaluation should include efforts to understand the design of these components and to verify their feasibility in the new system.

For example, a customer may already have a user authentication and authorization framework, but needs to be integrated into the new system. in this case, there is a potential "surprise during running" (usually an error occurs during running ). The reason is that the new business requirements are not implemented by an existing framework, and some enhancements may be required. In addition, if some functions and limitations of the framework are not available at the time of evaluation, this must be assumed to be documented.

Consider existing architecture standards
Considering that the existing standards are another area that is often ignored in the evaluation and have a significant impact on the work, if the current standards are already available, a lot of additional work can be avoided. but on the other hand, standards can also bring a lot of restrictions in the actual design and implementation process. for example, if you want to obtain financial information of an enterprise and display it on the screen, you can simply add a terminal area on the screen. however, if the customer already has a document server to manage the customer's financial information in the entire application, it is completely another thing. in this way, you need to establish communication protocols, exception handling, and other standards with the document server. this is a big job. you should put architecture standards and business requirements at the same important position in the evaluation.

Consider the actual test workload
With the development of automated testing tools and frameworks, the actual testing workload is much different from that of the oldest unit tests created and executed in schools. For example, if you want to create and run JUnit test cases, and the traditional unit test method is different, additional development time and learning curve are possible. Therefore, the processing methods tested in the test evaluation need to be clearly indicated to avoid any divergence.

Consider mutually dependent parallel development
When multiple mutually dependent applications are concurrently developed, the situation changes. If the application depends on ongoing development, it must be marked. The current feasibility should be verified during each communication. Pay special attention to the risk summary for other development projects. For example, an application must display the user's credit details, which must be obtained by calling an enterprise API through an external system. However, this enterprise APIS is being developed by another team, this API should be completed and available during your development project. It takes more time to use basic API calls to test the application and then use actual calls to replace it, the evaluation should clearly and professionally indicate the impact of these dependencies.

Use part-All Handling Methods
In the old saying, "divide and conquer" is the same in software evaluation. Divide the work into small parts and then list the steps to be completed for each small part. In this way, the overall evaluation of each step will be more accurate than the overall evaluation of the entire project.

Conclusion
In today's IT industry, fierce competition for products is completed on time and quality, and accurate evaluation is crucial. Project details that are often ignored will have a significant impact on the evaluation. The points mentioned in this article should be integrated with the mature Evaluation Technology to minimize the possibility of evaluation errors.

About the author
As an e-commerce consultant, Chandan has been working for India's Tata Consulting Service Company for more than five years. He has been closely involved in the evaluation, design, and development of enterprise-level applications based on various large-sized Java EE projects for major customers all over the world, as a member of the entire process of these projects, Chandan analyzed the impact on different stages of the development lifecycle. The author obtained a bachelor's degree in mechanical engineering from Jalgaon Engineering Technology Institute in India.

References:
"Software project estimation" by Kathleen Peters:
Http://www.spc.ca/downloads/resources/estimate/estbasics.pdf
The document "software project estimation" describes in detail four steps of software project evaluation: development project scale evaluation, development project workload evaluation, development project schedule evaluation, and development cost evaluation, the procedures, techniques, and commonly used calculation formulas of each step are discussed.
Matrix: http://www.matrix.org.cn
Javaworld: http://www.Javaworld.com