This is the last installment of a multiple-part article (as outlined below) that demonstrates using Rational's tools in a distributed, J2EE-based project.

• Part 1: project introduction; high-level planning
• Part 2: detailed planning; risk management; requirements management
• Part 3: Rational Rose model creation and access control; requirements analysis
• Part 4: use-case refinement; report generation; tool and technology selection
• Part 5: architecture and design
• Part 6: detailed design; early development; round-trip engineering; early unit tests
• Part 7: continued development; early builds; demonstrations
• Part 8: strategies for unit testing; function tests; GUI test scripts
• Part 9: system builds and testing; defect tracking; product acceptance
• Part 10: project results; conclusions; future work

The fictional premise of the article is that we're a software company, Lookoff Technologies Incorporated, and our customer, Audiophile Speaker Design, Inc. (ASDI), has hired us to meet their burgeoning IT requirements. For a more detailed introduction to the project, see Part 1.

This final installment describes what little was left to do to close out the ASDI project. Having passed the acceptance tests, the system was now ready for transition to ASDI (delivery and maintenance). This article closes with a discussion of some of the observations we made and lessons we learned while working on the project.

Project Closeout

It was time to close out Phase 1 of the project (and determine whether there would be a Phase 2). We delivered the system to ASDI and helped them set it up at their site. They immediately began testing the system through real-world use, starting with entering administration and configuration data and porting over their parts list in anticipation of going "live." They also tried out entering orders and generating parts reports. The system worked, the customer was happy, and all we had left to address was maintenance.

Maintenance

Because our contract was all level-of-effort work, there was no formal warranty period per se. Instead, ASDI simply raised issues to us as new ideas or inappropriate requirements were identified, and we entered these in the Rational ClearQuest defect database. Since we'd never installed the Web interface to ClearQuest, the customer's input was communicated to us on hardcopy forms. Although this procedure had worked well for system change requests made during the stages of analysis through development, it proved cumbersome during maintenance; we would have preferred the customer to have had direct access to the database. Minor issues were discussed and confirmed via teleconference, while others were deferred until we could meet and agree on the scope, impact, and implementation plan.

ASDI didn't have the infrastructure or resources to maintain the software themselves, so we kept the development and test environment set up at our company's office. This also made sense because it would be a waste of time and resources to disassemble our environment if ASDI then decided to proceed with a Phase 2 development effort for this project.

We fixed the software at our site and delivered builds to the customer as appropriate. This was a somewhat awkward arrangement, since we still had resources assigned to the project part-time but didn't have enough work to keep our engineering and I&T teams engaged on this project maintenance full-time (which would have been more efficient and more easily managed). However, since ASDI didn't have the right people, software, or hardware to perform their own maintenance, this arrangement had to remain in place for a while.

The issues raised in the ClearQuest database during Phase 1 maintenance had roughly the following distribution:

• 50% requests for new features
• 40% usability problems, with requests for new or changed prompts, layout, messages, menus, and so on
• 6% minor bugs
• 3% requirements errors
• 1% major bugs

Most of the issues were in the "nice to have" category, such as changes that would result in a more usable application but weren't critical. For instance, there were places in the user interface where terms specific to ASDI's business domain were incorrect or misspelled. These ideally would have been caught during earlier reviews, but catching all mistakes the first time something is reviewed is always hard.

The large number of requests for new features simply reflected that this was an unfinished product -- a natural consequence of exposing the system to new users who hadn't been deeply involved in the project from the beginning. Since Phase 1 was a proof-of-concept system, we'd been directed to stay close to the statement of work (SOW) for system functionality, and we largely stuck to that scope.

The minor bugs that remained in the system weren't so much contradictions of the requirements as they were low-level details that had been incorrectly implemented. These included faulty rounding on some financial data reported by the system, and searches that didn't perform consistently with blank parameters (empty fields on the search form).

We weren't too concerned about the requirements errors that surfaced. Our analysis effort had been very thorough, but it's important to remember two things:

• The fact that ASDI was evaluating this proof-of-concept system as a real-world system and finding so few flaws in our implementation of requirements was a strong victory for us.
• Most of the requirements errors were small and easy to fix. In many cases, updating the use cases and related documentation took longer than the code fix itself.

Phase 2?

There was some discussion about whether, when, and how ASDI would proceed with a Phase 2 for this project. There were a number of viewpoints on this that were factoring into their decision:

• Some operators using the system weren't comfortable with computers and were happy with the old way of doing things.
• Some operators liked the new system so much that they wanted to use it as is.
• The external B2B interfaces weren't sufficiently mature, fully documented, or bundled for a variety of platforms. ASDI couldn't distribute these libraries and APIs to their customers in their current state.
• Phase 1 had come in just under budget, so we had credibility to execute on time and within budget.
• ASDI's technical lead felt that they should continue with Phase 2 on their own, although he currently had no staff members that could support the initiative.
• ASDI had already ported all their data into the Phase 1 system and was worried that this effort would need to be repeated for the Phase 2 version.
• ASDI thought that, although there was some evidence that the Phase 2 system might be more efficient than Phase 1, the efficiency gains from Phase 1 over their old system might suffice.

When originally planning Phases 1 and 2, we knew we'd eventually hit this fork in the road. It was inevitable that some of the above issues would evolve as the result of creating a polished prototype at the end of Phase 1 rather than simply continuing with the natural iterations of the Rational Unified Process (RUP). As you'd expect in a proof-of-concept system, there were some areas of the system that weren't yet production quality. As mentioned above, the B2B interfaces that were intended to provide ASDI's customers with enterprise batch interfaces weren't fully implemented. Many requests for new features had been tracked in the ClearQuest database and were awaiting action. User documentation was inadequate, leaving the operators with unclear instructions for some tasks.

We pointed out some qualitative evidence we had that the Phase 2 system would be more efficient than Phase 1. Features would be added in Phase 2 -- for example, the ability to enter support data through data entry screens integrated with the database rather than through a command-line interface -- that would undoubtedly mean an even greater increase in efficiency. At the same time, ASDI's project manager for this project felt that the current system was already a huge improvement, so much so that he renamed it from a "beta" to a "full version 1" release when presenting it to the company.

In the end, it was agreed that we'd continue in a maintenance role, although ASDI would guarantee that at least two support roles (one developer and one tester) would be employed from us on a full-time basis, with call-in support from others as needed. They decided to defer action on Phase 2 until a later date, after they had more data and a clearer picture of their own financial situation.

Back to top

Observations

We learned quite a bit from this project, since it was our first exposure to several new technologies. As our first extensive experience with the RUP, it provided us with a number of observations and ideas related to that process.

Customer Relationship

During this project we had a very good relationship with ASDI, which was generally the case for us with our customers. Over the years we've identified that what makes the customer relationship succeed are good communications, visibility into project progress, and a realistic proposal. The only tricky issue with ASDI had been their initial perception that the project should be undertaken according to a strict waterfall-type approach. This is different from how we run projects, and very different from the RUP approach. In the end, we were able to carry out the iterations we felt were necessary, yet present ASDI with what resembled a waterfall structure closely enough to satisfy them.

The customer's vision of project scope changed about a third of the way through the project. Although the change wasn't drastic (see Figure 1), there was a shift from the original SOW. We were able to track the requirements changes with Rational RequisitePro, but they had an impact on the system beyond that.

Figure 1: Change in project scope

The change in scope added some areas of functionality but removed others. The importance of the operator screens increased while the importance of the B2B interfaces decreased, which we felt was a safe and wise decision on ASDI's part. Although we'd been given a mandate (and budget) to implement and test a secure B2B interface, at the same time ASDI realized that their biggest value-for-dollar would be in data integration, Web-based data entry, reports, and order management. Not only would this emphasis help them sell the idea of using the system to its potential users, but it would also provide immediate results (not requiring them to wait for their business partners to adopt the B2B interface).

ASDI's confidence in our team varied over the life of the project. Our very subjective estimate of this is shown in Figure 2, in which the major points on the confidence curve correspond to the numbered items listed below the figure.

Figure 2: Customer confidence

1. Confidence was reasonably high; ASDI awarded us the contract based on our reputation and proposal.
2. Early on in the project, some concern arose over our proposed schedule, our introduction of an unfamiliar notation, and a process that seemed heavy on analysis and design, with construction starting late in the game. It took a considerable amount of explanation and presentation on our part to convince them of the value of our approach.
3. As the prototypes and detailed analysis sessions progressed, ASDI become much more comfortable with our progress. They were also becoming major contributors to the review and analysis process and were clearly valued members of the team. This resulted in more buy-in and increased visibility into project progress, giving them added confidence.
4. Confidence started to wane when we weren't yet in an all-out implementation phase and appeared to be spending too much time on class diagrams, prototypes, scenarios, and so on. Looking at the schedule, ASDI was very concerned that we were almost halfway through the project yet still performing detailed design.
5. The team was hitting peak performance, and ASDI was seeing fast results. We were building software rapidly, our demonstrations were already impressive, and the logic and value in how we'd run the inception and elaboration phases was becoming apparent.
6. As demonstrations increased in frequency and maturity, ASDI continued to be satisfied with the work we were doing. Although some technical hiccups were being encountered along the way, it was clear that there was more than enough time to address defects and the remaining tasks.
7. As ASDI started using the Phase 1 version of the software on their site, they continued to be satisfied with the product. We were easily able to new issues they raised and address them (if appropriate and approved) in our own maintenance and test environment.

Process

Previous projects of ours had incorporated some incremental and iterative aspects of the RUP, but this project was our first effort at implementing the bulk of the RUP. We didn't follow it to the letter because we wanted to avoid the risk of "process shock" to the project team through too many new steps.

Rational's tools complemented our understanding of the RUP very well, and the online RUP documentation was invaluable. The documentation provided us with excellent strategy recommendations at each step along the way, and the RUP's tool mentors helped us understand how each Rational tool could and should be applied.

A strong benefit of the RUP was its focus on mitigating risk. The iterative approach, combined with early prototypes, demonstrations, and heavy customer involvement, all helped reduce project risk. We felt that our project risk followed the path shown in Figure 3 (again, with corresponding numbered items below). Note that this figure doesn't graph only the number of identified risks. Obviously, a project is riskiest at the start, because of the unknowns that lie ahead; you rarely know what all the risks are at the start of a project.

Figure 3: Project risk

1. Project risk was highest at the start. Until we formed a good working relationship with the customer, identified our core technologies, and were able to validate our estimates, we were still exposed to many risks that could damage the project.
2. By this point, we were working closely with ASDI, their concerns over process had largely been addressed, and we'd created most of our early prototypes that led to our selection of core technologies for the architecture.
3. When ASDI's technical lead started pushing for an OODB solution, we were concerned by this introduction of a new technology. Further prototypes helped us convince ASDI and ourselves that a relational database was probably the safest route.
4. Additional design and architecture, along with early development, helped reduce risk. We had a clean technical solution, more reliable estimates, and a schedule that (although tight) we felt would get us to the end.
5. Partway through the construction phase, some new technical problems were impeding our progress somewhat. These were all low-level; they only affected estimates at the class and module level and didn't jeopardize any entire thread or subsystem.
6. For the remainder of the construction phase, it was clear sailing, since the technical solution was obviously robust and progress was fast. By the time we ran the customer acceptance tests, there was very little question that ASDI would be happy with the product.

Technologies and Tools

The technologies selected for the architecture all performed as anticipated. Early prototypes during the inception and elaboration phases helped us confirm these choices and gave us a good head start on training, API familiarization, and development.

In hindsight, we were glad we took the route of going with the IBM DB2 database. When faced with pressure from ASDI to introduce an OODB into the architecture, we carried out a careful evaluation and comparison of the alternatives and were able to demonstrate that an OODB was in fact not a safer or better choice for this project.

Rational's tools provided a number of benefits over our old way of doing things. To be honest, we probably would have been able to deliver a requirements-compliant product to the customer under the same budget by doing things "the old way." The improvements in our Phase 1 system compared to how it would have turned out under our old methods fell into three areas: usability, quality, and performance.

• The system was more usable because ASDI had been closely involved in many iterations and builds of the systems. Frequent demonstrations, a rich analysis phase, and involvement from our usability expert all contributed to the ease of use in the final system. The fact that the operators were able to use it without adequate online documentation or manuals was impressive.
• The system was of higher quality than previous systems we'd delivered. Not only was our defect rate lower, but the architecture and design were superior. Through careful, iterative evolution of the architecture and design, we'd caught a number of issues early on in the project that normally would have been caught during implementation and changed by the developers on the fly. We now consider the design phase to be a valuable form of prototyping and risk mitigation, and we won't be so quick to skip to the implementation phase. Using round-trip engineering to ensure synchronization between the design and code was also very useful.
• The system performed more consistently and reliably than our previous products. Not only did having efficient inception and elaboration phases leave more budget for testing the system, but our design succeeded better at building a robust system. Because our data modeling efforts within Rose underwent intense review, even our schema was designed for efficiency as well as accuracy. We had properly isolated the data access layer, simplifying the optimization of queries (which had sometimes snuck into the business logic on previous projects). Finally, we benefited tremendously from Rational's testing tools. Rational Quantify enabled us to pinpoint bottlenecks, while Robot and SiteLoad enabled us to test software under peak loads to ensure that the system could respond to worst-case conditions.

Team Productivity

The team had worked together before, so there was already good morale, communications, and collaborative effort among the team members. This allowed them to focus more energy on the project and on learning the new tools.

We found it interesting to track the team's productivity over the course of the project. Although we aren't usually fans of metrics such as statement-lines-of-code (SLOCs), they were certainly interesting in this case (see Error! Reference source not found.). On previous projects, we'd been able to write much more code for the same amount of money; however, on those projects we never could have provided as much functionality for the money. Consequently, our SLOC metrics looked lower even though we had done a much better job. We attribute this to having a cleaner design, better use of off-the-shelf software, and less rework (properly refactoring code and replacing faulty code rather than creating add-ons). The engineering team also felt less schedule pressure and so was able to spend some time refactoring code before code reviews. (Note that the curve in Error! Reference source not found. somewhat resembles the RUP effort profile for implementation throughout the software project.)

Figure 4: Team productivity

1. Early on in the project, there was essentially no activity. We were just starting to set up our basic hardware and didn't even know what tools we were going to be using.
2. We started creating prototypes early in the inception phase to help identify some technologies and software development tools to use. This effort was all throwaway, with none of the resulting code ending up in the final system.
3. As we focused on detailed analysis and early architecture, there was less coding effort, and any coding that was done was thrown away after the desired results had been obtained.
4. Once we hit the elaboration phase, we quickly began having detailed and targeted prototypes, which mitigated technical risks and helped with design decisions. Some of this code survived in the implementation; however, early in the elaboration phase most of the code was thrown away after serving its risk-mitigation purpose.
5. During the construction phase, the engineering team focused on building the system and was performing at top efficiency. They were fully ramped up on the technologies and tools and had a stable specification and interfaces.
6. The engineering team remained largely at peak performance throughout the construction phase. The I&T team took on some of the noncoding effort, which enabled the engineering team to focus on building the system up until close to the end of the construction phase.
7. At the tail end of the construction phase, the engineering team only had to fix defects that showed up in testing and update the remaining build and test documentation. As a result, their coding output dropped significantly, tapering out in the transition phase while maintenance continued at a slow pace.

Back to top

Epilog

This installment wraps up the fictional account of a small J2EE-based project using the RUP and other Rational tools. This account was written to show one of many possible paths a project could take while adopting Rational's tools and processes. This particular path involved keeping things simple, and trying out each technology and tool before committing to it. The team didn't attempt to master the RUP and all of Rational's tools in a single project, but rather adopted the process and tools over time in a steady, disciplined manner.

The project's technologies, team structure, and schedule were very conducive to incorporating the RUP and other tools without impeding progress. Ramp-up on your project may be different, since your combination of technologies may be either more or less effective than the path described in this article. For budgets that can afford them, there are some excellent training options that can help ease the introduction and integration of Rational's tools into a project. You shouldn't go away with the impression that these tools are "silver bullets" that will save your project, but rather that they take a good team and make it better.

Remember that this article wasn't an account of any actual previous project I worked on, although it was based on my experience on actual projects. Some of the new technologies and Rational tools described weren't available yet for many of the projects I've worked on. Also note that I don't agree with many of the decisions that were made in the ASDI project, but I wrote them into the article for the sake of demonstrating and developing different ideas.

I do agree 100% with this conclusion of the article: that formal, modern software engineering tools and processes can bring significant productivity and quality gains to a software project. Although wary of the "silver bullet syndrome," I'm always looking for ways to simplify work. Rational has a number of tools that can do just that, and that integrate nicely together to provide even more value.

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Project Closeout
• Observations
• Epilog
• About the author
• Comments

Next steps from IBM

Rational Application Developer features provide the comprehensive Integrated Development Environment (IDE) used to develop J2EE applications requiring Servlets and JavaServer Pages (JSPs).

---

• Try: Try the free Rational Application Developer, which helps developers quickly design, develop, test, analyze, and deploy high-quality Java, Javaserver pages, and J2EE applications.
• Article: Learn how you can deliver accurate, higher-quality J2EE apps with Rational Application Developer, open source JUnit and JUnitEE test frameworks.
• Tutorial: Build a Facebook application using PHP, the Spring framework, and J2EE.
• Buy: Rational Application Developer

My developerWorks community

Dig deeper into Rational on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers