This is the seventh 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 Part 7 installment focuses on the builds and demonstrations that we carried out as development continued. These topics are covered only lightly in the Rational Unified Process (RUP) because they.re so dependent on the nature of the particular project. How and when you integrate and demonstrate your system depends on your customer, project size, and project risks.
| Part 7 Snapshot |
|
Tools and technologies demonstrated in Part 7:
Artifacts created or updated:
|
Demonstrations During Elaboration and Construction
Demonstrations took place at several points in the ASDI project, but especially during the RUP elaboration and construction phases. Whereas builds are a normal part of the iterative process, integrating separately developed components and serving as mini-milestones for tracking progress, demonstrations tend to have more specific goals. On our project, these goals varied depending on where we were in the progress of the project, and they in turn determined the precise nature of the demonstration and its audience. Demonstrations could be based on builds or not (for example, they could be faked screenshots) and could be either internal to the company or shown externally to the customer.
During the elaboration phase, demonstrations had the following goals:
- Show results of off-the-shelf (OTS) software evaluations.
- Walk through user interface mockups, showing sketches of key screens and sometimes showing workflow using facades.
- Manage customer expectations through very early demonstrations of the evolving product.
- Reduce architectural risks.
- Solicit analysis feedback.
During the construction phase, demonstrations had these goals:
- Provide the customer with insight into the team.s progress.
- Ease subsystem integration by identifying problems with the interfaces early on in the phase.
- Avoid "big bang" integration and delivery at the end.
- Boost morale by allowing the team to see progress through meetings supplemented by one or more subsystem demonstrations.
In addition, early demonstrations served as practice runs for formal builds later directed by the integration and test team, which involved testing against all requirements, having complete build documentation, and so on.
Internal Versus External Demonstrations
Internal team demonstrations naturally took less time and effort than external demonstrations. Whenever we showed the software to the customer, we wanted to avoid any glitches that would detract from the demonstration, whereas this wasn.t as important for internal-only review.
Internal demonstrations were usually performed late in the week, preferably late Friday afternoon as a bit of a break for the team. We.d gather in the demonstration area, where one or more of the teams working on a particular subsystem or thread would discuss their progress, show their work to date, and talk about any problems they.d encountered. Discussions would inevitably ensue regarding solutions, good ideas, and consistency problems spotted by other team members. These demonstrations required very little preparation -- perhaps just a clean build and a quick run-through to make sure things were working acceptably. The demonstrations rarely ran smoothly, but we didn.t see that as a problem, since we knew that polishing them further would mean additional preparation and testing effort.
External demonstrations had an added level of formality. Because we wanted to maintain the customer.s confidence and not waste their time, we followed these guidelines:
- Communicate the goals of the demonstration up front, using some form of agenda as well as other guidance.
- Prepare a clean, sensible set of test data.
- Rebuild the schema and code base, preferably from versioned threads in the source repository.
- Generate scripts for the demonstration.
- Carry out a practice run with the team lead in the demonstration room.
- Make sure all engineering team members discontinue using any shared resources (especially common data and tables stored in the DB2 database) during the demonstration.
- Keep the demonstration to one hour, with up to two additional hours for feedback and discussion.
These precautions might seem like overkill, but we found that a poorly prepared customer demonstration yielded little value and was a poor use of our time and budget.
Table 1 lists the rough plan we followed for builds and demonstrations during the elaboration and construction phases of the ASDI project. The number of these might appear to be excessive, and for some projects it would be; however, note that:
- Many of our demonstrations could be combined or could take place in parallel with other meetings.
- Some of the builds were necessary to prepare for demonstrations (as opposed to being entirely separate efforts).
- Many of our subsystem builds and partial system builds were "mini-builds" in the sense that they were extremely informal and took very little of our time.
| RUP phase | Nature of build or demonstration | Frequency | Timing |
| Elaboration | Tool evaluation prototypes | Once | Before delivery of OTS product evaluation |
| User interface mockups | Twice for each GUI use case | Early in use-case analysis activities and later in the elaboration phase | |
| Architecture prototypes | Once, to satisfy performance concerns | Before delivery of the software architecture document (SAD) | |
| Construction | User interface facades | Twice, two weeks apart | Early in the construction phase |
| Design prototypes | Once | A few weeks after delivery of the SAD | |
| Component demonstrations | Weekly | Starting very early in the construction phase | |
| Subsystem builds | Weekly | Starting 1 to 2 weeks into the construction phase | |
| Subsystem demonstrations and partial system builds | Biweekly | Starting 3 to 4 weeks into the construction phase | |
| Full system builds and system demonstrations | Monthly | Starting 4 to 6 weeks into the construction phase |
| Table 1: Build and demonstration plan |
There are a number of ways to run demonstrations. These may seem like fairly obvious events, but there are some novel approaches that can increase their value.
Joint Application Development (JAD)
Joint Application Development (JAD) basically involves gathering all project stakeholders in a room for very focused and intense brainstorming activities, typically including some sort of demonstration. We tried JAD a couple of times on our project but found that it was difficult and yielded mixed results. Many of the references we checked (two of which are listed later under "Related Resources") emphasize how important it is that the JAD mediator -- also called the facilitator -- be highly skilled, and in hindsight we feel we could have done better in this area.
On our project, JAD meant gathering ASDI subject-matter experts (SMEs), ASDI.s IT lead, our senior engineers, and project managers from both sides. We focused our discussions on requirements and user interface design (although not at the same time). Before a JAD session, we.d provide an agenda, from which the facilitator would direct the meeting. A lot of discussion took place, and many high-level diagrams were drawn on a whiteboard. (We used a digital whiteboard that could save and print diagrams drawn on it, which was a wonderful timesaver.) We also had a member of our engineering team take minutes, recording any notes that supported the diagrams.
We tried JAD at two stages in the project: during early elaboration for actor and use-case requirements; and during later elaboration for user application workflow and design (primarily user interface design). We.ll turn to the latter stage for our example here.
At this second JAD meeting, our developer who was the most talented in the areas of JSP and HTML sat at a computer with some early user interface mockups based on use-case analysis and notes. Allocating 15 minutes per screen, we brainstormed with the entire audience on the specific appearance and overall look and feel of the screens, the functions they demonstrated, and the navigation through the Web-accessible system. As suggestions were made, we tried them out on the spot. We had mixed results, and learned these lessons in the process:
- It was tough for the developer at the computer to keep up with significant changes that were being suggested. We needed to use a special rapid-prototyping tool, limit the scope of suggestions, or have multiple developers implement changes in parallel.
- The facilitator had to be very skillful in directing the flow of the meeting: technical enough to follow the discussions, but extroverted enough to keep everyone at ease and direct the discussion without coming across as too aggressive.
- The facilitator shouldn.t have been responsible for tracking time. Instead, another individual should have focused on holding each task to its allocated schedule. If something was running over, it should have been deferred to another day.
- The JAD sessions required a delicate balance between protecting scope and schedule and encouraging feedback and enhancement ideas.
We found that having simple show-and-tell demonstrations was the most effective and easily managed approach. Unlike dealing with issues in real time at JAD sessions, having small demonstrations separated by a week or so gave us time to think about the impact of requests and come up with solutions to identified problems. Granted, if we.d had additional JAD training we might have been able to compress the several show-and-tell demonstrations into one or two JAD sessions; the efficiency of having everyone collaborating in the same room would have saved a significant amount of time in our schedule.
Customer Hands-On Opportunities
As the construction phase progressed, our system got to the point where the customer could start to play with it. As shown in Table 1 , system demonstrations started four to six weeks into the construction phase. During these demonstrations, we allowed ASDI to use the system directly. Not only did this give them a greater feeling of involvement, but it also provided us with feedback that we wouldn.t have received otherwise. As the system matured, ASDI spent more and more time on it, effectively giving us free testing effort and the opportunity to fix some problems early in the product.s development. There are, however, a few risks associated with giving the customer free access to an immature system:
- If the system is reasonably polished on the outside (that is, in its the user interface), the customer might assume that the work is nearly complete.
- If the system is rough on the outside (for example, lacking error handling and stability), the customer might become nervous about the team.s progress.
- There could be a tendency to cram, say, six versions worth of features into a version 1 product, just to please the customer.
We had to continually remind ASDI, as they played around with early system versions, that we were creating only a Phase 1 proof of concept, and that "nice to have" noncritical features would have to be deferred. However, we made sure all their suggestions were recorded, since many of their ideas were very good and would be worth revisiting in any follow-on work. In general, ASDI understood the intent and limitations of the hands-on opportunities we offered them, so the above risks were not a significant issue for us.
The team spent some time debating the merits of creating facades as opposed to using an evolving product for early demonstrations. A facade is typically a product that.s fake behind the scenes and is implemented as quickly and cheaply as possible -- just enough effort to get the point across. On the other hand, using the evolving product requires investing more design and implementation effort into the early versions.
We actually tried both of these approaches during Phase 1 of the ASDI project, in the context of analyzing the user workflow for an administration graphical user interface. Table 2 compares the results.
| Demonstration aspect | Facades | Early versions |
| Development tool used | Microsoft FrontPage | JSP/Text editor |
| Preparation time before first demonstration | 3 days | 1.5 weeks |
| Ability to communicate workflow/GUI to customer | Good | Good |
| Ability to convey a look and feel similar to final product | Fair | Good |
| Speed of changing demonstration in response to requests and suggestions | Very fast | Slow to medium fast |
| Opportunity for reuse after demonstration | Poor | Fair |
| Training time | Short | Short (since the team was already trained in JSP) |
| Ease of integration with back-end servlets and database | Poor to fair |
| Table 2: Demonstrating a UI with facades vs. early code versions |
We used facades for demonstrations very early in the inception and elaboration phases. Although these were often throwaway demonstrations, we felt that the investment was well spent. FrontPage worked for us because at that point we weren.t hindered by the difficulty of integrating with Java servlets and the database, since we didn.t yet have any schema or components to which they could connect. Since our use of FrontPage in this project, FrontPage 2002.s database integration has improved to the point where we could even use it to display test data from the schema if we needed to in future projects.
We moved to an iterative coding cycle using JSP and servlets once the design started to stabilize. There was little value in writing throwaway Java code in the early part of the project (during inception and early elaboration), since at that time we weren.t even sure we were going to go with JSP and servlets, let alone Java. Using FrontPage was faster and easier, and it kept us from making any implicit technology decisions.
Starting to have builds early in the construction phase irons out problems that much sooner, and having frequent builds helps keep everyone in sync. Finding the right balance between too many and too few builds was important on the ASDI project. The frequency we chose had to take into consideration project complexity, vacation schedules, team skills, customer availability (for external demonstrations), and dependencies between components and subsystems.
Our subsystem builds integrated separately developed components and sometimes led to demonstrations. We didn.t insist on demonstrations of all our subsystem builds; rather, the team lead would do an internal build -- usually weekly, per the build schedule -- just to make sure the pieces were coming together. This synchronized everybody on the subsystem team, since, for example, they.d all have to use the same schema for the build. When the team lead did choose to demonstrate the integrated subsystem internally, it was shown at the end-of-week team meeting, giving the team a sense of accomplishment upon seeing how their part of the system had improved.
The team lead was efficient at setting up these demonstrations. The whole team knew to start fixing up their code on Friday morning to be ready for the integration effort. The build typically started early in the afternoon, allowing an hour or two for small fixes and discussions if any issues arose from the integration. The team lead would extract all code from the source repository after making sure all recently updated code had been checked in.
Our CM tool was a stumbling block in this project. We chose not to go with Rational ClearCase as our CM approach, but rather with the CM capabilities in a freely available CVS (Concurrent Versioning System) tool. CM is a critical part of software management, and in hindsight we wish we.d devoted more time to the selection, integration, and direction of use for our CM tool. Our not going with an integrated solution meant that:
- The team was less likely to check files in and out on a regular basis.
- Data was lost due to misconfiguration.
- Changes couldn.t easily be associated with integration and test (I&T) issues or software change requests.
- Team efficiency was reduced through adoption of a clunky CVS tool.
We decided that if we won the Phase 2 part of this contract, we were going to evaluate ClearCase as an addition to our Rational tool suite.
System builds, in which some or all of currently developed subsystems were integrated into one build, had the same benefits and goals as subsystem builds, except that:
- System builds took more preparation effort, had a bigger impact on the team, and were a bigger source of distraction for us.
- They often revealed a larger number of problems, and more serious problems that threatened the project.s success.
- They started later in the construction phase, because we needed a sufficient number of subsystems to justify the integration effort.
- Full system builds eventually involved the I&T team.
The engineering team did the first two trial runs of the full system build unassisted by the I&T team. These initial builds were painful: we had problems with our configuration management; some details at the subsystem interface level had been missed; and some subsystems were slightly behind schedule. The I&T team joined as an observer on the second trial run, and started to own the integration effort with the next system build after that. This made for a smooth transfer of responsibility and knowledge to the I&T team, without wasting their time in the first two (very rough) builds.
It was important for the engineering team, and later the I&T team, to have a clear idea of what was involved in each build; otherwise, the builds would be slow to execute and end up wasting the team.s time. In fact, we understood the iterative build process and the goals of each integration effort very well and were able to perform the builds cost-effectively.
Our frequent builds and internal demonstrations were going smoothly in general; however, the coordination of remote builds required some additional attention from the project engineer. Schedules for remotely developed subsystems often slipped, even with a capable team at the remote site, because they didn.t have access to the same resources that the core engineering team did.
Our customer demonstrations had been very successful. We were confident we had a clear picture of the customer requirements early in the construction phase, and the customer had a clear idea of the product we were building. There were few (if any) false expectations, and few surprises during the eventual delivery of the product.
Now that system builds were starting to take place, we.d soon be stepping up our testing efforts. We planned to use Rational.s testing tools to help with this. We needed to make sure all functions of the ASDI system were being performed properly and to test our Web application.s performance under load. These activities would also increase the I&T team.s familiarity with the system and ramp them up on the testing tools.
Our builds and demonstrations didn.t add any new risks beyond those that were already present in the course of developing the system; in fact, discovering and fixing problems early helped mitigate risks. We continued to feel strong schedule pressure, however, and we knew construction would have to proceed at an aggressive pace. We were already late in drafting up our functional test specifications. The RUP recommends starting these earlier in the project, and we were now under pressure because we.d delayed this activity.
- "Joint Application Development (JAD) for Requirements Collection and Management" by Alan Cline (Carolla Development, Inc. whitepaper)
- "Joint Application Development (JAD) -- What do you really want?" by the University of Texas at Austin
Steven Franklin has an extensive background in software design, architecture, and engineering process, which he usually applies to large, distributed information management and command and control systems. He's been using Rational tools since 1997, and his primary areas of interest include XML, J2EE, wireless, and software engineering methodologies. Steven can be reached via e-mail.
Table of contents
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
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
