Using Rational Tools to simplify J2EE-based projects Part 1: Summary

This article demonstrates the series of Rational tools used in distributed, J2EE-based projects.Article(As listed below.

• Part 1: Project Introduction and high-level planning
• Part 1: risk management and demand management
• Part 1: model creation and access control; Requirement Analysis
• Part 1: Refined use cases, production reports, and selection of tools and technologies
• Part 1: architecture and design
• Part 1: Detailed design; early development; Bidirectional Engineering; early Unit Testing
• Part 1: Continue development; early build; Demonstration
• Part 1: unit test policy; function test; GUI test script
• Part 1: system construction and testing; defect tracking; Product Delivery
• Part 1: project completion; Conclusion; Future Work

In this article, we are a fictitious software company lookoff technologies inreceivated. Our customer audiophile speaker design, Inc. (ASDI) hired us to fulfill their initial it needs. For more information, see section 1st.

The last part of this series discusses the few things that need to be done to end the ASDI project. We have passed the acceptance test and the system is now ready to hand over to ASDI (delivery and maintenance ). At the end of this article, we will discuss what we have observed in the project and hope to learn some experiences and lessons from our work in this project.

Part 1 snapshots

The tools and technologies demonstrated in part 1 are as follows: Rational ClearQuest-Tracking and managing problems in the use and maintenance of the original real world Products created or updated: ClearQuest defect Database-Updated to track any new ideas or inappropriate needs identified at this stage

Project delivery

Now it is time to deliver the first stage of the project to the customer (and decide whether there will be a second stage ). We delivered the system to ASDI and helped them install the system on their site. They started testing the system immediately through real-world use, started inputting management and configuration data, and ported their expected "in use" part list to the system. They also try their best to enter orders and generate partial reports. The customer is very happy with the normal operation of the system, and all our work is to maintain the system.

Maintenance

Because our contract involves the work of all parts of the system, there is no formal warranty term. ASDI only raised some new ideas or unsuitable requirements to us. We submitted these questions to the Rational ClearQuest defect database. Because we have not installed the Web interface for Rational ClearQuest, the customer's input is communicated with us through hard copy. Although this process works well for system change requests made during the entire development and analysis phase, it has proved to be a heavy workload in the maintenance phase; our first choice is to allow customers to access our database directly. The second issue was discussed and confirmed by teleconference, while other issues were postponed until we reached an agreement on the scope, impact, and Implementation Plan of project maintenance.

ASDI does not have the infrastructure or resources to maintain the software system itself, so we have retained the development and testing environments in our company. This also makes sense, because if ASDI decides to continue the second stage of development for this project, it will be a waste of time and resources to break down our environment.

We modified the software on our site and delivered the built system to our customers as appropriate. This is a little clumsy, because we still have resources allocated to the project in full time, but in the maintenance of this project, there is not enough work to ensure that the engineering and integration and testing teams work full-time. However, because ASDI does not have the right people, software, or hardware to perform their own maintenance, this arrangement must last for a while.

There is a rough allocation of issues that are submitted to the ClearQuest database during the first phase of maintenance:

• 50% new feature requests
• 40% availability issues, new or changed prompts, messages, menus, and other issues
• 6% unimportant bugs
• 3% requirement Error
• 1% important bugs

Most of the problems are in the "nice appearance" category. For example, a change that makes the application easier to use is not critical. For example, if there is an area on the user interface of the system, the terms in the ASDI business domain are incorrect or the letters are misspelled. Ideally, these issues were picked up during early review, but it was always difficult to pick out all the errors during the first review.

A large number of requests for new features simply reflect that this is an unfinished product-a natural result of displaying the system to users not included in the project from the very beginning. Because the first phase of the project is only a conceptual verification system, our purpose is to verify the functionality of the system, and a lot of work is done around this purpose.

The unimportant bugs left in the system do not have a major conflict with requirements. They are incorrect at the underlying level. These problems include the rounding of imperfect values produced by the system in financial data reports.

We do not have to worry too much about the demand errors. Our analysis work is thorough, but it is important to remember two things:

• The actual situation of ASDI is to evaluate the concept verification system as a real-world system, in addition, we have discovered only a few problems in the implementation of our needs, which is a huge victory for us.
• Most of the Request errors are small and easy to fix. In many cases, updating use cases and related documents is more effective than modifyingCodeIt takes more time.

Stage 2?

There are some discussions about whether and when and how ASDI will continue the second stage of the project. The following are some points of view in the discussion:

• Some operators who use the system do not use computers, and they like to do things in the old way.
• Some operators who like the new system want to use it.
• External B2B interfaces are not very mature, completely automated, or need to be bundled with a variety of platforms. In the current situation, ASDI cannot distribute these libraries and APIs to their customers.
• The first stage is well controlled within the budget, so we are confident to implement the second stage of the project within the time and budget.
• ASDI technical leaders feel that they should complete the second stage, although they do not have enough people to support the job.
• ASDI has migrated all of their data to the first-stage system, and is worried that this work will be repeated in the second-stage version of the project.
• ASDI believes that although there are some things that prove that the project in the second stage can be more efficient than that in the first stage, it may be sufficient to obtain more effectiveness than the old system in the first stage.

When we first plan the first and second phases, we know that we will eventually face this fork in the road. Some of the above problems have become the result of a refined prototype created at the end of the first phase. When you make an expectation in a conceptual verification system, there are still some parts in the system that do not have the productization quality. As mentioned above, the B2B interface provided to ASDI for enterprise batch operations has not been fully implemented yet. Many requirements for new features are recorded in the ClearQuest database and set to wait. User documentation is insufficient, and there are some instructions for task operations that are not clear enough for the operator.

We have pointed out some qualitative evidence that if we continue with the second phase of the project, the output system will be more efficient than the system produced in the first phase. Many features will be added to the second stage-for example, the data input capability is supported through the data input screen integrated with the database, instead of using the command line interface-this will undoubtedly increase the efficiency. At the same time, ASDI's project manager felt that the current system had been greatly improved. When we showed it to the company, we can rename it from a "Beta" version to "Full Version 1 ".

Finally, ASDI agrees that we will continue to assume the role of system maintenance, although ASDI ensures that they will hire at least two full-time support roles (one developer and one tester) from us ), other needed support can be achieved by phone. After ASDI had more data and a clearer understanding of their own financial conditions, they decided to postpone the work for the second stage until a relatively low time.

Observation

We have learned a lot from this project, because this project is our first exploration on several new technologies. As our first broad application of RUP, it provides us with a series of Project observations and ideas on processes.

Customer Relationship

We had a very good relationship with ASDI during this project. After so many years, we have found that good communication, visibility into project progress, and practical proposals can successfully establish good relationships with customers. The only tricky issue with ASDI is that they initially expected that the project should be strictly implemented according to the waterfall development method. This is very different from the way we operate the project, and it is also very different from the RUP method. Finally, we can execute the iterations we think are necessary, and try to show ASDI structures similar to Waterfall methods to meet their needs.

The customer's perspective on the scope of the project changes about 1/3 of the route through the project. Although the change was not strong (see figure 1), it also caused some changes from the initial sow. We can use rational requisitepro to track requirements, but they have an impact on the entire system.

Figure 1:Changes within the project scope

Some functional areas are added to the change in scope, but other functional areas are also deleted. When the importance of B2B interfaces is reduced, and the importance of operator screens is increased, we feel this is a safe and wise decision for ASDI. Although we have been given commands (and budgets) to implement and test a secure B2B interface, at the same time, ASDI realized that the biggest value they spent was data integration, web-based data portals, reports, and order management. This not only emphasizes the idea of helping ASDI sell and use systems to their potential users, but also provides immediate and available results (they are not required to wait for business partners to adopt B2B interfaces ).

ASDI confidence in our team is constantly changing throughout the project cycle. Our very subjective estimation is shown in Figure 2. The main points on the line in the figure correspond to the labeled entries listed in the figure below.

Figure 2:Customer confidence

1. High confidence; ASDI grants us peace of mind based on our fame and proposal.
2. In the early stages of the project, some worries emerged as the proposed schedule went on, as we introduced unfamiliar symbols, and the process of seemingly heavy work on analysis and design. We have made a lot of explanations and statements to convince them that our approach is valuable.
3. ASDI became more satisfied with our progress as prototype and detailed analysis meetings progressed. They have also become a major contributor to the review and analysis process and are undoubtedly valuable members of the team. This leads to more purchases and increased visibility into the project progress, and increased ASDI confidence.
4. When we are still not in the implementation phase and spend a lot of time on class diagrams, prototypes, scenarios, and so on, ASDI's confidence has declined. Looking at the time schedule, ASDI is very worried that we will spend half of the time, but we are still designing it in detail.
5. The team started to enter the efficient product stage and ASDI saw quick results. We quickly built the software, and our demo was already impressive, and the logic and value of how we perform the initial and refined phases seem more apparent.
6. When the frequency and maturity of the demo increase, ASDI continues to be satisfied with our work. Although we encountered some technical difficulties in the process, it is obvious that we have enough time to solve the defects and the remaining tasks.
7. When ASDI began to use the first-phase system version on their site, they continued to be satisfied with the product. We can easily solve their new problems in our own maintenance and testing environments.

Process

Our previous project draws on some incremental and iterative content in the RUP, but this project is the first large-scale implementation of the RUP. We didn't completely copy the content of the RUP, because we wanted to avoid the risk of "Process Work" caused by too many new steps by the project team.

Rational tools can help us understand the rational, and the online rational documents are also very valuable. The rational documentation provides us with superior policy advice on every step of the process of implementing the RUP, and the guidance of the RUP tool also helps us understand how every rational tool should be applied.

One of the strengths of RUP is its focus on risk reduction. Iterative Methods, early prototypes, demos, and a large number of customers involved in the merger, all of which can help reduce project risks. We feel that the risk of our project is consistent with the path shown in Figure 3 (the corresponding label entries are listed below ). Note that this graph is not a graph, justRecognizedRisk label. Obviously, a project has the greatest risk at the beginning, because the unknown is always ahead. At the beginning of the project, you rarely know what is all the risks of the project.

Figure 3:Project risks

1. Project risks are the greatest at the beginning of the project. Until we have a good working relationship with our customers, the core technologies we recognize can validate our estimates, and we are still exposed to many risks that can damage our projects.
2. Through this, we work closely with ASDI, whose worries about the process have been mitigated to a great extent, and we have created multiple early prototypes, these prototypes guide us in the Technical Selection of the system architecture.
3. When ASDI's technical leaders started pushing an object-oriented database solution, we expressed concern about the introduction of this new technology. Further prototypes help us persuade ASDI and we are confident that relational databases are the safest path.
4. Additional design, architecture, and early development can help reduce risks. We have a clear technical solution with more reliable estimates and time plans that we feel can be completed.
5. Some new technical problems have hindered our progress. These problems are low-level. They only affect the estimation at the class and module level, and do not harm any overall clue or subsystem.
6. There are clear routes for the remaining parts of the construction phase, because the technical solution is obviously reasonable and the progress is also accelerated. At this time, we performed the customer's acceptance test, and there were very few problems in the acceptance test. ASDI also expressed satisfaction with the product.

Technology and tools

All technologies selected for the architecture are implemented as expected. Early prototypes in the initial and refined phases helped us to confirm the selection of these technologies and gave us a good start in training, API familiarity and development.

In retrospect, we are glad that we have taken the path to using the IBM DB2 database. When we face the pressure from ASDI to introduce object-oriented databases into the architecture, we carefully evaluate and compare an optional solution, it also demonstrates that object-oriented databases are not safe enough, or there are better options for products.

The ratioanl tool provides a series of benefits for us to do things in the old way. We may be able to deliver products that meet the requirements in the old way under the same budget. In the first phase, we compared the system improvements in three ways: availability, quality, and performance.

• The system is more available because ASDI has been closely involved in many iterations and system building. Frequent demonstrations, rich analysis stages, and the involvement of availability experts contribute to the usability of the final system. In fact, the operator can use the system without online documents or user manuals.
• The system has a higher quality than the system we previously delivered. Not only is our defect rate lower, but our architecture and design are also outstanding. Through careful iterative evaluation of the architecture and design, we found a series of problems in the early stages of the project, and these problems are usually discovered at the implementation stage. We now think that the design stage is a valuable prototype and risk reduction form, and we have not quickly jumped to the implementation stage. It is useful to use Bidirectional Engineering to ensure synchronization between design and code.
• The system is more consistent and reliable than previous products. It is not just an efficient initial and refined phase that leaves more budget for system testing, but our design is more successful in building a robust system. Because our data modeling work in Rose has undergone rigorous review, and even our models are designed to be very efficient and accurate. Data access is layered appropriately to simplify query optimization (data access is sometimes mixed in business logic in previous projects ). In the end, we gained huge benefits from rational testing tools. Rational quanad enables us to identify bottlenecks, and robot and siteload allow us to test software under extremely high loads to ensure that the system responds to the worst condition.

Team productivity

The team has been working together for a long time, so there is good morale, communication and collaboration among team members. This allows them to focus more on projects and learning new tools.

We found it interesting to track the team's productivity during the project process. Although we are not enthusiastic about measurement analysis, for example, code line Statement (slocs), in this example, measurement analysis is indeed very interesting. In our previous project, we were able to write more code with the same amount of money. However, we have never provided so many features for the same amount of money in those projects. Therefore, even if we do better work, our sloc measurement analysis looks lower. This is due to a clearer design, better use of purchased software, and minimal rework. The engineering team also seldom feels the pressure of time, so they can spend some time refactoring the code before the code review.

Figure 4:Team productivity

1. In the early stages of the project, there was essentially no activity. We just started to build our basic hardware and didn't even know what tools we would use.
2. We started to create prototypes early in the initial phase of the project to help us identify some of the technologies and software development tools we use.
3. When we focus on detailed analysis and early architecture, there will be very little coding work, and any written code will be discarded after the desired results are obtained.
4. Once we enter the Refinement phase, we will soon begin to refine and target the prototype, which will help us reduce technical risks and help us make design decisions. Some code can be reused in implementation. However, most code in the early stages of refinement is discarded after serving the purpose of reducing risks.
5. During the build phase, the engineering team focuses on building the system and performing the work most efficiently.
6. During the entire build phase, the engineering team left off a large number of extreme performance tests. The integration and testing teams perform some non-coding work, which enables the engineering team to focus on the build system until the end of the build phase.
7. At the end of the build phase, the engineering team must only modify the defects shown in the tests and updates of the remaining build versions and test documents. Finally, the engineering team's coding work output dropped significantly.

Conclusion

This section summarizes the small, J2EE-based fictional project using RUP and other ratinoal. This series of articles shows one of the many possible paths for a project to use Rational tools and processes. This particular path includes keeping things simple and trying every technology and tool before deciding. The team does not try to master the rational and all rational tools in a separate project, but uses Rational processes and tools in a stable and disciplined manner.

The technology, team structure, and schedule of the project are very beneficial to merge the RUP and other tools without interrupting the progress. The situation in your project may be different, because the merging of the technologies you use may be more efficient or inefficient than described in this article. There are some training opportunities for the budget that can be provided to them to help more easily introduce and integrate ratioanl tools into the project. You shouldn't feel like these tools are the "silver bullet" that can save your project. They just make the team better at work.

Remember that this article is not a description of any actual project we used to work on, although it is based on my experience in actual projects. The new technologies and some rational tools described are still not available for many projects I work on. Note that I disagree with many decisions made in the ASDI project, but I write them into the document to demonstrate and develop different ideas.

I totally agree with the conclusion of this article: formal, modern software engineering tools and processes can bring exceptional productivity and quality to a software project. Despite my vigilance against the silver bullet syndrome, I am still searching for ways to simplify my work. A series of Rational tools can achieve this exactly, and the integration of these tools can even provide more value.

About the author Steven Franklin has a broad background in software design, architecture, and engineering processes. These experiences are often used in large distributed information management and control systems. He has been using Rational tools since 1997 and is primarily interested in XML, J2EE, wireless, and software engineering technologies. You can contact Steven through steve@sfranklin.net.