Avoid common errors in Java EE project evaluations

Error | project Summary：

Software development project evaluation is a critical and challenging step in the software development cycle, which is the basis for planning, scheduling, personnel, and other related steps. The underestimation of the project can lead to tight schedules, highly stressful working conditions, unforeseen resource shortages, low quality, and delays in project implementation, to the maximum extent possible to disrupt the customer's business and the company's credibility; An assessment with too much irrational bubbles can also lead to inefficient resource waste and mistrust between customers and companies. Evaluating enterprise Java Projects because technology updates have become a challenge, this article provides a few perspectives on what to consider when evaluating an enterprise Java project

If you are a project manager for an important software project, your budget has run out, the pressure on the software is approaching, and the CIO is tired of delays and, more importantly, your team has been exhausted by long hours of work and unreasonable progress. Does all this sound familiar? This article investigates common errors in project evaluations that can lead to this dilemma and makes recommendations for improvement.

Some of these arguments are not relevant to technology and apply to any software project, and their common feature is to improve project evaluation in different ways.

　　 screening suitable candidates for evaluation

In any assessment process, the selection of suitable candidates is also the most important step. You need to always be clear that the right person, not necessarily the most important person, is responsible for operational analysis and evaluation. In addition to formal assessment techniques and knowledge, the candidate should also have the knowledge of the business area of the project and the technical knowledge used in the project. A non-technical person will never understand what the meaning of a framework constraint or technology choice is in the real development process.

　　 Consider the availability of the technology, framework, and tools that the project proposes to use

Java EE projects can choose different frameworks and tools, each with its own functionality, constraints, and learning curve. The impact of these factors is significant after the project enters the development phase. In preparing an assessment, the initial phase of the survey should be completed and the applicability and impact of these options to the project should be identified, and these choices need to be adapted to the team's current and future training.

　　 consider 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 statements in the requirements document, and the system should send/receive data using existing systems and APIs. In particular, this section needs to be carefully validated to confirm that, based on the complexity of system details and communication protocols, many subsequent tasks need to be counted. If the communication details of the external system are not available at the time of the assessment, this part of the evaluation can only be considered as a scenario and should be listed as a part of the process that needs to be reassessed after the design is completed. Remember, in the real world, there is no Plug and play.

　　 Consider the existing enterprise artifacts

Most organizations already have the infrastructure of off-the-shelf information systems, and some reusable enterprise artifacts can and are authorized to be used in new systems. Customers are always promoting compatibility for different reasons, such as consistency, compatibility, and frugality. However, it is important to note that in order to meet this requirement, the assessment should include an understanding of the design of these components and of the efforts required to verify their viability in the new system.

For example, a customer might already have a user authentication and authorization framework that needs to be integrated into the new system. There is a potential "run-time surprise" (generally referred to as an error during the run). The reason is that new business requirements are not implemented by existing frameworks, and that some enhancements are likely to be required. In addition, if some of the framework's features and limitations are not available at the time of evaluation, this must be documented as an assumption.

　　 consider existing architectural standards

The consideration of existing standards is another aspect that is often overlooked and has a significant impact on the job, and many additional work can be avoided if existing standards are already in place. But another aspect, the standard also can in the actual design and the implementation process to bring many restrictions. For example, a simple request to obtain financial information from the enterprise and display on the screen, you can simply add a text area on the screen to achieve. However, if the customer already has a document server to manage the financial information of the customers throughout the application, it is quite another matter. This way you need to establish communication protocols with the document server, exception processing and other standards. It's a pretty big job. You should put the architectural standards and business requirements on an equal footing in the assessment.

　　 consider the actual test effort

With the development of automated testing tools and frameworks, the actual test workload has been very different from the old building and execution unit tests in schools. For example, if you require the creation and running of junit test cases, the additional development time and learning curve is possible, unlike traditional unit test methods. Therefore, the way the test is handled in the test evaluation needs to be clearly demonstrated to avoid any differences.

　　 consider the parallel development of interdependence

When multiple interdependent applications are developed concurrently, the situation becomes more variable. If applications are dependent on ongoing development, they need to be identified. Each communication should validate the current feasibility, paying special attention to the risk profile of other development projects. For example, an application must display the user's credit details, which need to be obtained from an external system with the calling Enterprise API, but the enterprise APIs are being developed by another team, which should be in a state of completion and availability when you develop the project. Using the basic API to test the application and then use the actual call to replace it requires more time than directly using the actual invoke one-step, the assessment should be clearly and professionally marked by the impact of these dependencies.

　　 use part-all of the processing method

In ancient words, "divide and conquer" is the same in software evaluation. Divide the work into small chunks and then list the steps to complete for each small block. The synthesis of each step evaluation will be more accurate than the whole project as a whole.

　　 Conclusions

Today's IT industry is on time to finish the product of fierce competition, accurate assessment is critical. Project details that are often overlooked can have a significant impact on the assessment. The points mentioned in the article should be integrated with the already mature assessment techniques to minimize the possibility of error assessment.