Shulou(Shulou.com)06/02 Report--

How to avoid common mistakes in Java project evaluation, I believe that many inexperienced people are at a loss about this. Therefore, this paper summarizes the causes and solutions of the problems. Through this article, I hope you can solve this problem.

Software development project evaluation is a key and challenging step in the software development cycle, and it is the basis of planning, schedule, personnel and other related steps. Project underestimation will lead to tight schedule, highly stressful working environment, unexpected resource shortage, low quality, project implementation delay and other risks, which can first damage the customer's business and the company's reputation; on the other hand, evaluation with too many unreasonable bubbles can also lead to inefficient waste of resources and mistrust between customers and companies. The evaluation of enterprise Java project has become a difficult problem because of the update of technology. This paper provides the problems that should be considered when evaluating enterprise Java project through several aspects.

If you are the project manager of an important software project, the budget given to you by the top management has been used up, the pressure of the business on the software is approaching day by day, and CIO is tired of delays, and what's more, your team has been exhausted by long hours and unreasonable schedule. Does all this sound familiar? This article investigates common mistakes in project evaluation that can lead to this dilemma and makes recommendations for improvement.

Some of these arguments have nothing to do with technology and are applicable to any software project, and their common feature is to improve project evaluation in different ways.

Select suitable candidates for Java project evaluation

Screening the right person for evaluation is also the most important step in any evaluation process. You need to always make it 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 business domain knowledge of the project and the technical knowledge used in the project. A non-technical person will never understand what an architectural constraint or technical choice means in the real development process.

Consider the availability of the technologies, frameworks and tools proposed by the project

Java EE projects can choose different frameworks and tools, each with its own functions, limitations, and learning curves. The impact of these factors is very significant after the project enters the development stage. When preparing an assessment, you should complete the preliminary survey and find out the applicability and impact of these choices on the project, and need to adapt to these choices in 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 undervalued part. More often, there is only one line in the requirements document, and the system should use the existing system and API to send / receive data. In particular, this part needs to be carefully verified and confirmed, and a lot of follow-up work needs to be taken into account based on the complexity of system details and communication protocols. If the details of communication with the external system "how and when" are not available during the evaluation, this part can only be treated as an assumption and should be listed as the part that needs to be re-evaluated after the completion of the underlying design. Remember, in the real world, there is no plug and play.

Consider existing enterprise components

Most organizations already have a ready-made infrastructure of information systems, and some enterprise components that can be reused can be used and authorized in the new system. Customers always promote compatibility for different reasons such as consistency, compatibility, and savings. However, it is important to note that in order to meet this requirement, the assessment 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 that needs to be integrated into the new system. In this case, there is a potential "runtime surprise" (usually an error occurs during the run). The reason is that the new business requirements are not implemented by an existing framework and are likely to require some enhancements. In addition, if some of the features and limitations of the framework are not available at the time of evaluation, this must be documented as an assumption.

Consider existing architectural standards

Considering existing standards is another aspect that is often overlooked in evaluation and has a significant impact on work, and a lot of extra work can be avoided if existing standards are already in place. But on the other hand, standards can also bring a lot of restrictions in the actual design and implementation process. For example, a simple requirement to obtain the financial information of an enterprise and display it on the screen can be achieved by simply adding a text area to the screen. However, if the customer already has a document server to manage the customer's financial information throughout the application, it is quite another matter. This way you need to establish communication protocols, exception processing and other standards with the document server. This is quite a big job. You should give equal importance to architectural standards and business requirements in your evaluation.

Consider the actual test workload

With the development of automated testing tools and frameworks, the actual test workload has been very different from the old school situation of creating and executing unit tests. For example, if you are required to create and run JUnit test cases, unlike traditional unit testing methods, additional development time and learning curve are possible. Therefore, the handling of tests in test evaluation needs to be clearly stated to avoid any differences.

Consider interdependent parallel development

The situation is even more changeable when multiple interdependent applications are developed in parallel at the same time. If the application depends on ongoing development, it needs to be marked. Each communication should verify the current feasibility, paying special attention to the risk profile given to other development projects. For example, an application must display the user's credit details, and this needs to be obtained through an external system with the call to the enterprise API, but the enterprise APIs is being developed by another team, and the API should be completed and available when you develop the project. It takes more time to test the application with a basic API call and then replace it with an actual call than directly with the actual call, and the evaluation should clearly and professionally identify the impact of these dependencies.

Use partial-all processing methods

As the old saying goes, "divide and rule", the same is true in software evaluation. Divide the work into small pieces and list the steps to be completed for each piece. In this way, the synthesis of the evaluation of each step will be much more accurate than that of the whole project as a whole.

After reading the above, do you know how to avoid common mistakes in Java project evaluation? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.