Simplify J2EE-based projects by using Rational Tools: Part 1

Steven Franklin
Software designers and Process experts
March 2004

This is composed of multipleArticleA series of articles about how to develop a software project by applying the Rational Unified Process (RUP) and other rational tools at a tight time and budget. The first part of the article contains high-level plans and requirements.

Raional's development tool suite supports two-way engineering (RTE), distributed and collaborative development, highly iterative development cycles, and more features. The first part of this series composed of multiple articles will show you the role of the rational tool and show that you can simplify the distributed J2EE by using the rational tool (Java 2 platform, enterprise Edition) project. We will look at a fictitious project that will be a single project, develop with high-level plans and requirements, and transition to various stages of the Rational Unified Process (RUP. This article assumes that you have a certain understanding of the RUP; if you do not understand the RUP, you can view the related resources listed at the end of the article.

For the sake of simplicity, we do not want to complete the necessary iterations in the RUP, but only show the features of the tools used at each stage of the project. We will follow our small sample project to complete its first major build, as shown below:

• Understand the concept of RUP and the use of Rational tools, and apply them to respond to challenges from remote development, tight schedules, and limited budgets
• Use rational technology to achieve end-to-end traceability and demand management
• Integrates Rational tools in the J2EE project to complete automated testing, Bidirectional Engineering, and geographic distributionCodeInspection and quality assurance (QA)
• The integration of rational technology and J2EE tools provides final solutions, especially for applications such as J2EE, relational databases such as DB2 or Oracle, and Java integrated development environments.

Each article in this series has a similar organizational structure. Each article starts with a road sign. Just like the following, each link is connected to the relevant article section.

• Part 1: Project Introduction; high-level plan
• Part 1: risk management and demand management Part 1: model creation and access control; Requirement Analysis

-->

• Part 1: model creation and access control; Requirement Analysis Part 1: detailed use cases; Generate Reports; selection of tools and technologies

-->

• Part 1: detailed use cases, generate reports, and select tools and technologies Part 1: architecture and design

-->

• Part 1: architecture and design Part 1: Detailed design; early development; Bidirectional Engineering; early unit test

-->

• Part 1: detailed design, early development, Bidirectional Engineering, early Unit Testing Part 1: continuous development; early build; Demonstration

-->

• Part 1: Continue development; early build; Demonstration Part 1: unit test policy; function test; GUI test script

-->

• Part 1: unit test policy; function test; GUI test script Part 1: system construction and testing; defect tracking; product delivery

-->

• Part 1: system construction and testing; defect tracking; Product Delivery Part 1: project completion; Conclusion; Future Work

-->

• Part 1: project completion; Conclusion; Future Work

Part 1 Snapshot

Tools and technologies in Part 1: Rational Unified Process (RUP)-Used for high-level project planning Generated or updated work product: Gantt Chart-It is created for project management purposes and is measured as a baseline for time progress and project budget execution.

Example
The virtual hypothesis in this article is that we are a software company named lookoff technologies inconfigurated. Our company's main business is in IT systems, including integration, support, and development. Our headquarters is in Toronto and there are some small offices in Canada. Because our analysis and development teams are very close to a large number of multinational customers, the structure of this company allows us to concentrate our experts (typical back-end development and project management) in a very good way ).

Assume that another virtual company, audiophile speaker design, Inc. (ASDI), is located near New Brunswick. ASDI was just a small company engaged in speaker manufacturing and design. It mainly developed customized speaker solutions for individual users. With the increasing popularity of ASDI, they developed more mainstream speaker product lines and supplied products to users and e-stores in Canada and North America.

The technical facilities of ASDI cannot meet their growth needs. They have difficulty in managing orders, planning production materials, tracking part of requirements and managing shipping. More importantly, ASDI customers complain about their lack of browsing availability and delivery process capabilities.

ASDI realized that the transformation from paper and workbooks to automated asset management systems was accompanied by risks. ASDI decided to deliver all their IT needs to lookoff. The main reason they choose us is our good reputation and close to their company (easy to support ).

Note that although the sample project is fictional, it's based on my personal experiences, observation of other projects, and knowledge I 've acquired through excellent books such as those listed under note: although the sample project is fictitious, it is based on my personal experience, observations on other projects, and I use some excellent books (such as related resources listed at the end of the article) knowledge obtained.

Lead to high-level requirements
Like many small non-IT companies, ASDI is aware of their problems, but they are not very clear about what their needs look like. Their original working status is only two pages long, and is a mixture of contract, function, and programming requirements. We sat down with them to discuss each of their needs. Here we are most interested in contract and programming, as discussed below:

Contract Problems
The customer (ASDI) wants us to sign a company fixed price (FFP) contract worth $1.1 million (CDN) and the software system should be delivered within 10 months according to the contract. It is impossible for us to sign this contract without a clear demand vision. This brings too many risks to us and may be unfair to our customers. can we determine if their technical needs will be met. We started our first meeting to discuss the power of iteration and incremental software development over sequential ("waterfall") development.

The key features of the RUP we emphasize on our customers include:

• Iterative engineering to reduce risks and aggregate correct solutions
• Use existing tools, technologies, and developed products to minimize costs and enhance quality.
• Manage and control changes
• Give the customer an understanding of the Product
• Create high-quality products

The customer is still very concerned about the short term of Software Delivery. Through some discussions, we successfully showed that the customer should have a sufficient understanding of the progress of the project from the beginning to the end of the project. They also want the project budget to be paid in stages and require us to fulfill some of our obligations when implementing the project. Therefore, the project plan is divided into two phases:

• Phase 1-Create a "concept Verification" version for the system. The customer will pay our fees based on the working hours, but within the first-stage pre-selection.
• Phase 2-Create a product version of the system and pay for it according to FFP.

For phase 1, the customer requested a 250 k cdn ceiling, and we felt that this budget was sufficient for us to create the demo version of the first prototype system. We created a dry feature diagram of 1. We marked this point in four months to generate a demo version, and reviewed it with the customer to ensure that it was roughly synchronized with the first phase schedule at least. (Then we checked the time schedule more closely with them)

Figure 1:Phase 1 features

(Click to enlarge)

The figure in Figure 1 is created with Microsoft Visio, but you can easily use Microsoft Project or some similar software tools to plan your project. The main purpose of this chart is to reach an agreement on the time advances and milestones, and establish a layer chart of the work breakdown structure (WBS, each item in the work breakdown structure can be tracked, estimated, and executed.

Programming Problems
ASDI is an ISO certified company that believes heavily in documentation, continuous milestones, and extensive quality control. They are not a very technical company and they have their own ideas in the process. One of the major challenges we face when working with them is finding a process and a set of deliverables that make them satisfied without compromising our team's work. They held several meetings and stressed the need for a large number of thorough and detailed documents. Furthermore, their milestones are sequential, and their idea is that each task must end before the next task begins. Their understanding of the process makes it a great challenge for us to apply the RUP in the most likely way.

Although ASDI agrees that we use iterative and incremental development (based on the RUP) methods, they seem not interested in this method. They want to get the following:

• Fixed milestones:
  • System Requirement check (SRR), preliminary design check (PDR), and key design check (CDR)
  • Demo versions of the two software
  • Factory Acceptance Testing (FATS) and customer acceptance testing (CATS)

We simply inserted these milestones into our Process (1 ).

• A formal requirement document, a design manual, and acceptance testing document. These object-oriented symbols based on the RUP method are brand new, and ASDI is not very concerned about all of them at work, however, ASDI agrees to maintain a high level of description of their delivery work products so that we can meet the work products expected by ASDI. We feel that using Rational Tools to generate required documents will not cause great obstacles to our processes, and we can successfully deliver information to our customers. Specifically, rational soda makes it easier for us to generate documents from models.

ASDI also plans to hire an IT manager to contact us and maintain and manage the completed projects. We need a role such as ASDI to join the project. This person should be a technical authority for the project. Unfortunately, this IT Manager (emerging for the company) lacks the knowledge of customer operations, just as in our team.

Summary
We made some very good progress in a series of initial meetings with our customers. ASDI's expectation for delivery products and time advances is somewhat flexible and allows us to develop using the RUP-based approach. We have achieved a general time progress structure for the project and established a good relationship with the customer. Through discussions with customers, we identify some risks, which are then used to prioritize tasks and manage projects.

Plan the future
One of the top priorities we should take is to work with the customer to establish the project vision from the customer's current working situation (SOW. We have gained a rough understanding of the customer's needs, but we still need to analyze the specific work we need to do.

We must also refine our time schedule and start the initial phase of our probe as soon as possible. During phase 1, to ensure that a solution is cost-effective and meets customer needs, we must find out how to meet customer needs. As mentioned by the customer, the main factor in deciding whether to move the project to the 2nd stage is the maintenance of the final system and the cost of the system architecture software/hardware.

All in all, what we should do in the previous weeks includes:

• Enter the project requirements in rational requisitepro.
• Refine the time schedule for phase 1
• After a successful design check, create a project plan to show you how to plan the transition to stage 2nd.
• Develop detailed execution plans to mitigate identified risks

Major Risks
The start weeks of the project are critical to establishing effective customer relationships and maintaining the project in the correct and appropriate technical direction. We don't have much time to find the desired technology and integrate it into our team because the project progress the customer expects is very fast.

We believe that we must establish a problematic database, and we can put forward action entries, problems, and risks in a centralized way. By publishing this information to the Internet, you can monitor project information, whether in a centralized office or remote development team. If necessary, even remote workers can track and update project risks.

Resources

• Rational uniied process: introduction, Version 2The author, Philip kruchten (Addison-Wesley, 2000), provides a great introduction to RUP. More detailed information can be found in the RUP product.
• Rapid development: tame crazy project progressAuthor Steve McConnell (Microsoft Press, 1996 ).
• Mythical man-month, anniversary edition: Software Engineering ProseAuthor: Frederick P. Brooks, Jr. (Addison-Wesley, 1995 ).
• Death March: the complete software developer's Guide to creating Ving "Mission Impossible" ProjectsBy Edward Yourdon (Prentice Hall PTR, 1999 ).

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 via email.