Why Use a Methodology?

A successful software development methodology defines how all of our tools, techniques, and practices combine into a winning formula. The techniques discussed throughout this book are meaningless in isolation unless a process is adopted to bind them into a cohesive development strategy. Indeed, the choice of methodology is a key part of defining an adaptive foundation for enterprise development.

The use of methodologies for software engineering arose out of the need to make the software development process a repeatable and quantifiable activity. Methodologies aim to place a degree of control over a software project, enabling it to be steered toward a successful conclusion through a proven series of steps and actions.

For RAD, we want a process that requires the minimum of administrative control and delivers the most productive method. The question is how much process is enough and how much is too much. Finding the correct answer has significant implications for rapid development.

A J2EE RAD Methodology

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:

Lightweight.

The process must offer the minimum level of ceremony in the context of the size of system under development.

Complementary.

The process must work to exploit the strengths of the development tools and techniques adopted by the team. This relationship is symbiotic, as the tools and techniques should in turn support the chosen methodology.

Adaptive.

To be effective, the process must be able to contend with the emergent nature of business requirements, enabling the project team to change direction as and when the business dictates.

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

Adaptive Versus Predictive Methods

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.