The ideal methodology for rapid development is one that is optimal for the development underway. People tend to think of RAD methodologies as being lean and mean, carrying out only those tasks that relate directly to the success of the project.

This definition is valid but needs to be placed in context. A process that fits this criterion for a small project might be completely unsuitable for a large-scale development. Conversely, a method that has proven successful on a large project might prove completely unwieldy and inefficient when used by a smaller team.

A lean and mean approach is required, but we need to qualify the minimalist approach by being sensitive to the needs of the system under development.

In addition to being lightweight, the process adopted should exploit the strengths of the J2EE platform. J2EE solutions use distributed object-oriented technology; hence, the process followed should align with the needs of this type of solution. A process founded on procedural methods, for example, is unlikely to form a favorable complement to a J2EE project.

In order to conform with the central tenet of this book, that RAD projects require the ability to react quickly and effectively to change, the methodology selected also must offer an adaptive approach to software development. Indeed, all of the techniques in this book point toward an adaptive approach, and our choice of methodology should be no different.

Summarizing these points we get the following set of criteria for an ideal RAD methodology:

Let’s consider the different types of methodologies available for enterprise developments.

The number of different software development methodologies available is many and varied. However, after several decades of evolution, development methodologies generally fall into one of two categories: either predictive or adaptive [Fowler, 2000].

Predictive methods seek to draw upon the disciplines of established engineering principles to provide a measure of predictability to the software engineering process. They attempt to quantify the cost, duration, and resource requirements of a system up front, in the early stages of the project, by completing all work relating to requirements definition and design ahead of any actual implementation.

Predictive methods can prove very effective for systems whose requirements remain stable throughout the duration of the project. However, their rigid approach makes them resistant to change. Any refinement of the requirements downstream from the initial analysis phase can lead to costly rework. The process must backtrack in order to accommodate the change within the plan and identify the impact on the project schedule.

In contrast, adaptive methods accept that for most systems, the requirements will change during the course of the project. These methods look to put feedback mechanisms in place that enable changes to be incorporated back into the system with minimal effort and cost.

The classic waterfall lifecycle model personifies the predictive method, while adaptive methods rely on an incremental development approach for flexibility. The next sections cover the suitability of each of these lifecycle models for the rapid development of enterprise systems.

The waterfall model offers a linear approach to software development. Practitioners of the model diligently and methodically step through its distinct phases of analysis, design, coding, and testing.

Figure 3-1 shows the steps of the classic waterfall approach.

Figure 3-1. The waterfall lifecycle model.

The approach is document-driven, with the initial phases focusing on the creation of highly detailed requirements and design documents before any coding work commences. The phases of the waterfall model do not overlap. As the name implies, they cascade one into another.

The model does offer some considerable benefits in lieu of an ad hoc approach to development. It enforces a disciplined method on the project team, ensuring that requirements are duly considered up front at the start of the project and that extensive planning is carried out before resources are committed to the development. To a degree, these are all good software engineering practices because they improve the team’s understanding of the customer’s needs.

Unfortunately, the waterfall lifecycle model also suffers from some inherent weaknesses:

Many of you have examples of projects conducted according to the disciplines of the waterfall model. One such project I worked on early in my career made the inefficiencies of the model abundantly clear, especially when the pressure to deliver intensified.

The project team was developing a shrink-wrapped hydrographic surveying system in C++ (this was in the days before Java). The team was small, but every member was well skilled in the use of the technology and knowledgeable in the practices of object-oriented development.

The team was under considerable pressure to deliver the product. The competition had stolen a lead with the latest release of its software, and the company was in catch-up mode. The project stakeholders were in a state of constant high stress. Every passing day that we didn’t deliver, the competition stole more and more of the market share. On the project, stress levels were high and tempers were short.

We were a dedicated group of developers who were well aware of the concerns of the stakeholders. We wanted to deliver quickly, but we also took pride in our work and wanted to produce a quality product.

To achieve both aims, we decided, called for a formal disciplined approach. The biggest consumer of time on the project was rework. If we could reduce the amount of rework, we could reduce our time to market.

Working on the premise that documents are cheap, while skillfully crafted object-oriented code is expensive, we put the following process in place based on our knowledge of the software engineering best practices of the day.

The approach seemed both sound and diligent. Having the product specialists accept the requirements specification meant the development team could focus on implementing the exact functionality requested. Unfortunately, things didn’t progress as smoothly as anticipated.

One of my main tasks was the design and implementation of the system’s real-time navigational displays. The purpose of one particular display was to provide the helmsman with a visual cue as to whether the vessel was maintaining the correct course. After creating a functional specification for the navigational display, work began on the implementation.

Weeks later, the display was complete and a new version of the software was released to the product specialists for formal testing. At this point the problems started.

The product specialists were not happy. Yes, they agreed the helmsman’s display met the original requirements, and no, they could not find any defects. However, it was not what they wanted.

Seeing the display in action, they realized requirements had been missed that meant the display would prove unusable for navigation out on the water. They also didn’t like the flat, two-dimensional look of the display and suggested something more three-dimensional. Why hadn’t they said so at the time?

This feedback was very frustrating. I had worked extra hours to get the job done on time and to make sure the display’s behavior was exactly as the product specialists had requested. From my perspective, I had achieved my goal yet had failed to deliver functionality that met their needs.

To avoid repeating the problem a second time, I took a different approach. First, I ignored the requirements document, instead taking a day to restructure the code so it roughly incorporated some of the changes. This next version was far from production quality but demonstrated some of the main new ideas. I went back to the product group with the new version, explaining that the software was not stable and was only a rough prototype. They liked the revamped display but suggested some further changes.

Over the course of the next week, I went through the cyclic process of revising and demonstrating the display. Quite soon, the display evolved to the point where the requirements were agreed and effort then went into bringing the software up to a production level.

Once the final version was ready, the product group documented the display’s functionality as part of the user guide, leaving me free to get on with the next system feature.

From the experience, I learned a few things:

Despite all of this, a heroic team effort won through and the project was a success. The architecture we produced for the system proved a stable platform and served as the basis for other profitable products. In the end, we came through, but the questions arose: Is there a better way, and could we have got to market any sooner?

The answer is yes, and we could see the key to successful future projects lay in the application of an approach that allowed us to factor in feedback from the product specialists at every step of the development process. For that, we needed to ditch our waterfall variant in favor of something along adaptive lines. To do that required turning to an iterative approach to development.

These next sections highlight the benefits of iterative development.

The benefits of iterative development make the approach a central practice for all adaptive methods. In the next sections, we look at two types of adaptive methods. Each follows an incremental, iterative approach to software development: the IBM Rational Unified Process and the agile methodology Extreme Programming (XP).

We know that a successful system meets the needs of its end users. To achieve this goal, IT staff must work closely with the business domain experts to elicit the requirements that will ultimately drive the development effort. The interaction between business representatives and members from the project team is a critical success factor for ensuring all relevant requirements are both understood and captured correctly. Achieving this objective is a challenge, since both parties approach the engagement with very different mindsets and viewpoints. The end users focus on business concerns, while the IT staff likely thinks in terms of system design and architecture.

The question becomes, “How do we capture requirements in a form that is understandable to both the business domain experts and the IT-focused software engineers?” One of the most successful methods to date of achieving this is to develop a set of use cases.

Use cases describe what the system should do from the end user’s perspective. They are text-based documents, as opposed to diagrams, that step through the flow of a set of closely related business scenarios. Each use case represents a functional slice of the system and describes how actors interact with the system in order to execute the use case.

An actor is defined as something external to the system, usually a person, who interacts with the system. The use case itself is a series of actions a system performs for the actor.

Here is an example of the structure of a typical use case:

Templates for use cases vary, with publications on the subject each presenting slight variations on a common theme. The structure of the use case shown represents the elements commonly found in use-case templates. You may wish to tailor this template to suit the needs of your own project.

The most important part of a use-case document is the flow of events section:. This describes the interplay between actors and system for a given scenario in a concise, natural language form.

Let’s look at an example of a use case that details the flow of events for a customer who enters the office of a travel company to reserve seats on a suitable flight. Table 3-1 shows an example of the complete use case.

The plain language of use cases, which is both business- and technology-neutral, makes them ideal for communicating system behavior to both end users and developers. Use cases are important in RUP because they provide a common thread through many activities, particularly in the area of linking requirements to design. They also serve to focus the design, implementation, and testing efforts around a central set of requirements, which form the core of the system.

Use cases are organized by producing a use-case model. A use-case model is a UML diagram that graphically illustrates how the different use cases and actors interact. Models are useful for gaining an understanding of the relationships that exist between each use case and actor. However, the true value of use cases is in the text of the use case itself, not the diagram in the model.

Ivar Jacobson initially proposed the concept of use cases. As Jacobson’s Objectory is one of the foundation methodologies on which the RUP framework is built, it is not surprising that use cases are one of the driving forces of the process.

Although they are an important part of the process, use cases are not confined to object-oriented development and have enjoyed widespread acceptance in all manner of projects. They are an excellent technique for capturing and understanding customer requirements and are worth considering for inclusion in any methodology.

We next examine how the RUP framework centers on the use of iterations throughout the project lifecycle.

The process prescribes an iterative approach to development with timeboxed iterations. Here, all iterations occur over a fixed duration but have a variable scope.

A RUP iteration focuses on a subset of the system’s use cases. Within a typical iteration, the selected use cases are elaborated and a design is evolved followed by implementation and testing. The objective of each iteration is a functioning system. Should it appear that this objective will not be achieved, then the scope is reduced in preference to extending the timeboxed duration of the iteration or bringing more people on to the project.

The exact content of an iteration is dependent upon the particular phase of RUP within which the planned iteration is being conducted. Let’s examine the different phases of a RUP project cycle.

Conventional waterfall-based processes are broken down into phases according to specific software engineering activities, with phase names denoting the associated activity. We therefore commonly have requirements, analysis and design, implementation, and testing. Only a single type of activity is undertaken in each of these phases. For example, during the requirements phase, only work relating to the gathering, analysis, and documenting of requirements is performed. Absolutely no design, coding, or testing work is undertaken as part of this early phase.

RUP projects are also divided into the four discrete phases. These are inception, elaboration, construction, and transition. Unlike in the waterfall model, these phases are not aligned by activity but instead demark the achievement of a major project milestone. Phases within the process include a number of iterations, with each iteration serving to advance the project toward the phase milestone. As an iteration is a complete mini-waterfall project, we can expect to see the general activities of requirements, analysis and design, implementation, and testing being undertaken in each phase.

A common failing in implementing the RUP is to mistakenly associate these four phases with the four phases of the classic waterfall lifecycle. This is a fact Philippe Kruchten, one of the creators of RUP, went to great pains to point out with his fellow authors in the article, “How to Fail with the Rational Unified Process: Seven Steps to Pain and Suffering” [Larman, 2002].

Please note:

Here are the four phases of a RUP project and a brief description of the work undertaken in each phase:

A discipline represents an area of work. Disciplines are undertaken in each iteration, although the degree to which each discipline is practiced depends on the current project phase. There are nine different disciplines:

The amount of effort required in each discipline varies as the project traverses through the four different phases over time. Iterations in inception and elaboration phases will be heavy on the business modeling and requirements management disciplines. Later in the project, during the transition phase, effort in these disciplines will have trailed off but may still play a minor part in later iterations.

The RUP framework provides all the elements necessary for building a comprehensive project around the different disciplines. For each discipline, RUP defines a set of roles, activities, artifacts, and workflows that represent the core elements of the lifecycle model. Each of these elements is an answer to the questions of who, how, what, and when.

Planning is a key part of RUP, which encourages the production of two types of plan: a coarse-grained phase plan and a series of detailed iteration plans.

The phase plan is a single plan that spans the duration of the entire project from inception to transition. This high-level plan defines the anticipated dates for the major project milestones, the required project resources, and scheduled dates for each of the planned iterations.

The phase plan is created early in the project during the inception phase. Detailed planning is reserved for the iteration plan, which, like traditional management plans, allocates tasks to individuals and specifies minor milestone dates and project review points. Milestone dates within the iteration plan are made with an expectation of accuracy, as the estimates are made for near-term deadlines as opposed to the long-term forecasts of the phase plan. Toward the end of the iteration, the plan is concluded and work on the plan for the next iteration commences. Thus, in RUP it is common to have two iteration plans: one plan for tracking progress to schedule in the current iteration and a second plan that is under construction for the upcoming iteration.

Two of the most frequently asked questions regarding planning for iterative processes relate to how iterations should be structured throughout the project and what should be the length of an individual iteration.

For structuring the iterations within the project, Philippe Kruchten gives some guidance in an article on planning iterative projects [Kruchten, 2002]. For very simple projects, Kruchten suggests a single iteration for each of the four phases:

Where a large project with many unknowns in terms of both problem domain and technology is under development, Kruchten advises the following structure between the phases:

The length of a timebox for a single iteration is governed by the size of the project team. Extremely large projects with hundreds of people involved require careful coordination in order to maintain momentum for the project. This coordination effort soaks up time and tends to lead to longer iterations. Smaller teams can work to iterations with shorter durations.

Ideally, iterations should be short and focused, running to weeks rather than months. Iterations of two to five weeks work well if the team size allows it. Where longer iterations are unavoidable, then consider setting minor milestones within the timeframe of the iteration. This helps keep the team focused on delivery and prevents risks from creeping back into the project. These minor milestones also help in tracking longer iteration plans.

Enterprise J2EE developments and RUP fit well together. The way in which enterprise projects are conducted can vary greatly based on both the customer and the development team involved. Thanks to the extensive range of elements RUP provides, the process can tailor to suit most situations.

The size and scope of enterprise developments varies immensely, ranging from teams with only a handful of developers to projects comprised of hundreds of people spread across geographically distant locations. The RUP framework supports both extremes and can meet the needs of small, adaptive style projects while also providing the high-ceremony artifacts necessary for developments conducted on a much grander scale.

Although RUP supports a lightweight adaptive approach, this is not the nature of the majority of enterprise-level developments. Traditionally, such projects are highly contractual, requiring upfront fixed-price quotes for agreed-upon levels of functionality. This type of engagement is the forte of RUP. Placing great importance on early prototype and investigation work helps to drive out the risks involved in this type of project.

Another factor in adopting RUP is the current trend for offshore development. Regardless of whether you favor this contentious practice, it has become a part of the IT industry. The extensive range of artifacts RUP defines makes it possible to conduct large projects with distributed development teams spread across the world. Here, elements of the process provide a common technical vocabulary between teams of different cultures and backgrounds, allowing them to work effectively and collaboratively on a system.

Furthermore, practitioners of best practice processes such as RUP are also able to convey a high degree of professionalism. When organizations are selecting software vendors, an important criterion is often their adopted development methodology. Companies with development teams who demonstrate a knowledge and investment in an established lifecycle model are more likely to win business than those companies who see little value in such methods.

RUP is not without its downsides. A major issue is the amount of time and effort that must be invested in knowledge and education of the process framework. The extensive nature of the framework means this investment is often considerable, as becoming expert in the use of the process requires both training and practical experience. Ensuring all team members receive sufficient upfront training before embarking on any project is an important part of developing an adaptive foundation within a company in order to facilitate rapid development methods.

If taking RUP on board is viewed as being too expensive, an alternative is to adopt the practices of a lightweight agile methodology. We look at the benefits of these methods next.

The RUP framework comes with an abundance of disciplines, activities, artifacts, and roles, any of which you may choose to incorporate in your project. XP is more concise and is essentially comprised of 12 basic practices, each of which you must follow in order to exploit the full benefits of the process.

These practices, or rules, of XP align with the key activities of planning, designing, coding, and testing. Each practice is undertaken in accordance with the XP values of simplicity, communication, feedback, and courage, which permeate the entire process.

Let’s begin with the 12 practices that make up XP:

The 12 practices complement one another to the extent that to omit a single practice could cause the whole process to unravel. For example, simple design requires refactoring to remove unnecessary complexity; refactoring relies on the testing practice to guard against unintended changes in system behavior. XP therefore requires discipline from the team in ensuring all practices are employed on the project.

The practices of XP lay down the rules for how developers work on an XP project. To understand how an XP project is conducted, we need to look at the activities of XP.

Planning is a critical activity on any project, more so if the project is following an adaptive method. These methods require decisions on the direction of the project to be made at every step, and in close consultation with the customer, if the project is to be carefully steered toward a successful conclusion.

Planning on an XP project is a continuous activity driven by the feedback from both customers and developers. Like RUP, planning in XP occurs on two levels. The first level is the broad project plan, or release plan using XP terminology. This defines the overall structure for the project and gauges the number of iterations necessary to complete the system.

The second level of planning is the detailed iteration plan. This covers just a single iteration. Iterations in XP run for approximately two weeks, and the content of an iteration is decided upon based on the customer’s prioritized requirements and estimates from the developers for each requirement. A release is made at the conclusion of an iteration, as dictated by the practice of small releases.

Throughout the iteration, teams should look to integrate their work on a regular basis, as specified by the continuous integration practice. This avoids the danger of costly integration problems caused by last-minute integration efforts.

XP iterations are timeboxed, so discussion is required with the customer to determine which requirements must be included within the allocated timeframe. The need to collaborate closely with the customer in all aspects of the project, including its planning, gives rise to the XP practice of having an onsite customer.

Where RUP iterations are driven by use cases, XP iterations are planned around user stories. The function of an XP user story is similar to that of a use case but is considerably simpler and shorter, usually running to just a few sentences. The iteration evolves the story, but the “written” story remains in its original terse form. Like use cases, user stories also drive other project tasks, with acceptance tests being written for the stories provided.

Figure 3-3 illustrates how user stories drive iterations within XP.

Figure 3-3. User stories and the XP iteration lifecycle.

In addition to release and iteration planning, XP teams look to hold short, standup meetings at the start of each day to lay out the tasks for the day, arrange pair-programming teams, and discuss any issues that may have arisen since the last meeting.

Design is one of the most contentious areas of XP, as according to the main practices, followers of XP do not appear to do any design work. In contrast, RUP capitalizes on its links with the UML and uses modeling as the main design activity.

XP has no place for models, stating only that design should be kept simple, as per the simple design practice. This is enforced by the refactoring practice, which looks to remove complexity at every opportunity. Furthermore, all members of the team should have a common understanding, or metaphor, as to what the system is and how it works.

As for formal design processes, the original C3 project used Class, Responsibilities, and Collaboration (CRC) cards for running design sessions, and this technique has proven popular with some XP teams.

If the subject of design on XP projects is contentious, then the practice of pair programming, whereby two developers share a single machine, is positively explosive.

The arguments against pair programming are twofold. First, management becomes nervous about the productivity implications of having two developers constrained by the bottleneck of just one machine. Second, developers become almost territorial over a task they have taken responsibility for, and they have a tendency to feel threatened at the thought of having anyone closely scrutinizing their work. Frequently, developers cite the need for quiet time in order to fully focus on a problem, claiming the need to be “in the zone” in order to overcome technical development challenges.

Resistance to pair programming can be quite extreme, with developers vehemently denouncing the need for the practice. It is well worth reading the article “The Case Against XP”, by Matt Stephens, on the subject of pair programming and XP in general. This amusing article provides an opposing viewpoint to the practices of XP and can be found on the Software Reality site at http://www.softwarereality.com/lifecycle/xp.

If you have tried pair programming, you likely found it mentally exhausting. Having a second developer working with you on a piece of code seems to keep you constantly alert. Common distractions, such as getting up and making coffee or surfing the Web, get pushed to one side with a second pair of eyes on the screen. The excessive mental effort pair programming imposes is probably one of the reasons why XP recommends sticking to a 40-hour week.

The pair-programming practice came into being as an extreme reaction to code reviews. While they may sound like a good practice, code reviews, as they are commonly practiced, are a flawed quality-control process.

Code reviews are often left to the last minute on a project, by which time it is often too late to fix any of the problems identified by the review. Moreover, conducting a thorough review takes time, as the reviewer must form a clear understanding of the developer’s intent and approach. Seldom is enough time set aside to conduct a proper review. Likewise, reviewers often have their own tasks to complete and so frequently fail to invest the necessary effort in the review process.

The XP solution to the problems surrounding code reviews is to have them occurring all the time. Pair programming achieves this, since the developer pair is continually checking the code against both the requirements and the project’s coding standards. Mixing up pairs regularly ensures that no developer flaunts the project standards unnoticed. Furthermore, the practice also links in with collective ownership, as knowledge of the code is spread around the entire team.

Pair programming is making in-roads into mainstream development as more and more companies discover that two heads really are better than one. Some novel approaches are being formed that enable people to more easily work together in pairs. One group at HP undertook a distributed XP project and gave all developers hands-free headsets and desktop sharing software in order that team members could pair program remotely.

Pair programming does have its limitations and is not suitable for all programming tasks. A classic example is research or investigative work. Here, people really do need some quiet time to explore and read. However, if programmers are writing production code, then under XP rules, they should be doing so in pairs.

XP has single-handedly breathed new life into the concept of test-driven development, whereby tests are written ahead of any implementation.

Under XP, all classes in the project should have supporting unit tests. This practice enables refactoring of the code base without the danger of system behavior being impacted.

Unit tests also support the practice of collective ownership of the code. If a programming pair is changing code developed by other members of the team, the supporting unit tests will ensure they can do so without inadvertently destabilizing existing system behavior. The test suite should identify this situation if it occurs.

Upon identifying a defect, the programmer must write a unit test for the problem. This approach guards against the defect creeping back into the system.

Agile methods have gone to great lengths to reaffirm the importance of the individual worker. Early methodologies looked to downplay the role of the individual, seeking to make software development a production-like process, with IT staff undertaking factory-type roles.

Job descriptions in XP are sparse compared to the comprehensive list included under RUP. Nevertheless, this serves to underline the importance of the individual on the project and the significant contribution he or she makes.

True to the nature of the profession, software engineers on an XP project must be multi-skilled. They are expected to take part in the planning, designing, coding, and testing of the system. Thus, XP breaks away from the standard convention of defining specific roles for architects, designers, managers, coders, testers, and the like. XP places greater emphasis on generalists rather than on specialists, so if you’re working on an XP project, expect to get your hands dirty.

Unfortunately, J2EE developments often have a need for specialist skills due to the diverse range of Java-based technologies involved. It is not atypical to find developers who are expert in JSP but have never written an Enterprise JavaBean. Even fewer developers will have been near a J2EE Connector Architecture (JCA) adapter. This can be an issue, especially with the collective ownership practice. Attempting to get the entire development team through the learning curve associated with the intricacies of JCA technology in many cases just isn’t practical. Pair programming is one way of spreading the knowledge, but on complex J2EE systems, it is hard to avoid the need for specialization in a particular J2EE technology. XP does advocate the consultant role, which can help in this area.

The following list provides a brief description of the roles for an XP project, as defined by Kent Beck:

The final role is for the individual who is ultimately responsible for the project. The role involves helping to guide and assist the team through problems, acquiring additional resources as required, and making some of the hard decisions around delivery in consultation with the team.

Now that we’ve covered the main points of an XP development, let’s consider how well suited the process is for the development of a J2EE solution.

XP will be not be a perfect fit for all projects, since certain conditions must be present in order to get maximum benefit from the method. First, a business domain expert is required from the customer to work closely with the development team. This individual must be empowered to make key decisions about the direction and behavior of the system being developed.

The customer is not the only one who must commit to an XP development. Management must also back the approach and be prepared to embark on a project that may have uncertain requirements and no clear deliverables from the outset. This presents the manager with all manner of contractual challenges around price and delivery commitments.

For XP to work, the software engineers assigned to the project must be prepared to adopt its practices faithfully. XP is a disciplined process and requires teams to adhere to all of its practices in order for the process to operate effectively. Developers who don’t want to work in pairs and resent other developers changing their code would be better off placed on other projects—preferably with another company.

Even if all of these conditions are in place, XP is still not a good match for all project types. To quote from Kent Beck’s Extreme Programming Explained [Beck, 1999]:

So, how well does XP gel with a J2EE-based project? Well, XP is technology-neutral. The original C3 project was an object-oriented project developed in Smalltalk, and XP has been used effectively with other programming platforms since then, so the use of the J2EE platform should not be a barrier to adopting XP.

When J2EE projects do find themselves hitting the limitations of XP has more to do with the nature of enterprise development than with the J2EE platform itself. Enterprise developments tend toward large teams, with a current trend toward having split-site development using offshore resources.

XP works best with small teams averaging around 10 people, and with the team members in close proximity. Big team sizes are definitely an issue for XP, as the lightweight process lacks the necessary ceremony to coordinate large numbers of developers. Nevertheless, XP as a process is still evolving, and work is currently ongoing to determine how XP can scale for larger projects.

Another major barrier to the use of XP on enterprise projects is the contractual nature of these developments. A fixed-price quote with clearly defined scope is the norm for an enterprise system. Working to these contractual constraints requires a level of predictability that does not sit well with the low-ceremony approach of XP.

Instead, XP in its current form favors inhouse, collaborative projects. Projects of this type fit the profile for an XP project extremely well. Onsite domain experts are often easily arranged, and as the customer and development team all work for the same company, the contractual requirements are not so stringent. It is possible to operate an XP project with an external customer, but a good relationship must be in place for the process to prove workable.

To conclude, XP and J2EE can work well together, but pick your projects with care. Don’t opt for an excessively lightweight process when the conditions call for something more substantial.

Philippe Kruchten, one the founding fathers of RUP, has openly criticized publications that misrepresent the practices of his process, particularly those that present it as a waterfall model. I’m confident I’ve done his creation justice, but if you want to hear about the process framework from the horse’s mouth, as well as learn more about RUP, then you should read his excellent book, The Rational Unified Process: An Introduction [Kruchten, 2003].

Numerous resources exist for XP, with volumes of material being published on the process. A good starting point is Kent Beck’s original text on the subject, Extreme Programming Explained [Beck, 1999]. A detailed online reference is also available for XP at http://www.extremeprogramming.org.

From my exposure to XP, I was always of the opinion that XP would be unsuitable for split-site development, especially for projects with the bulk of the development work taking place offshore. I may need to revise my opinion, as Martin Fowler has written a thought-provoking article on his experiences using XP with an offshore development shop in Bangalore. The article is available from http://martinfowler.com/articles/agileOffshore.html.

For more information on use cases, Alistair Cockburn has written a number of articles on the subject, which can found at his Web site at http://alistair.cockburn.us. His site also contains an example of a use-case template on which the example in this chapter is based. See http://alistair.cockburn.us/usecases/uctempla.htm.

The site also includes information on Alistair’s agile methodology framework, Crystal.