Common Elements of RAD

RAD emerged back in the late 1980s as a response to the growing frustrations of customers who needed IT solutions delivered in shorter timeframes than were possible with the mainstream development techniques of the time. RAD methods made the promise of not only reducing time to market but also costing less than traditional methods and delivering higher quality software that better met the business requirements [Reilly, 1995].

The formation of RAD was an ad hoc process, with many IT companies promoting their own interpretations of what constituted a rapid application development approach. RAD therefore lacks a single unifying process that gives an exact definition for the term. Nevertheless, several techniques and practices are acknowledged as being common elements of a rapid development approach.

Timebox Development

Timeboxing is a primary RAD technique that has development conducted over a fixed duration. This timeline of the project is immutable, and the functionality of the application is tailored to fit within the boundaries of the timebox. The objective for the project team is to produce a working system at the end of the timebox. Functionality is removed from the system if the team is struggling to meet this objective. Essentially, the timebox practice seeks to fit the application to the schedule rather than formulating a schedule to fit the application [McConnell, 1996].

Timebox development encourages the customer to prioritize requirements, thereby enabling the development team to focus on the early delivery of functionality critical to the application.

Limits risk.

The customer receives a working application in a short timeframe, albeit with limited functionality. This avoids the risk common in typically mainstream development practices whereby a fully featured application is delivered in a big-bang approach. Such approaches risk failing to deliver any functionality come the end of the schedule.

Avoids overengineering.

Team members are allowed no time to design for imaginary future requirements. Consequently, all design work must address only the functionality that is to be delivered at the end of the schedule.

Energizes the development team.

An aggressive schedule focuses the attention of the team on the immediate needs of the application.

If employed correctly, the practice makes for a dynamic, pressure-cooker environment on which many development teams thrive. In the right environment, the energy and enthusiasm generated by the team for the project can result in very high productivity gains.

Chapter 3, Embracing Adaptive Methods, examines the importance of timeboxing for conducting iterative development, a software development method that sits at the heart of today's agile development processes.

Domain-Specific Languages

In an effort to reduce the critical path during the construction phase of the project, RAD promotes the use of specialized development languages to increase productivity.

As the name implies, domain-specific languages target a distinct problem domain. They are not general-purpose programming languages like Java, but instead address a specific function. Examples of domain-specific languages include:

• Jython for ad hoc scripting purposes

• SQL for data access code

• Prolog for creating expert systems

• Tcl/Tk for prototyping user interfaces

• JSP for building HTML pages with dynamic content

Jython is covered in Chapter 9, Scripting

Although the subject of alternative languages may seem moot to anyone developing for the J2EE platform, it is possible to combine the power of these domain-specific languages with Java.

Part III looks at the concepts behind a multilanguage development approach and examines how specialized languages can help augment the high-level language constructs Java already provides.

Software Reuse

Software reuse meets two important design aims. First, it results in the development of common modules that are shareable between applications. This aspect of reuse makes possible the assembly of applications from readily available and proven software modules, thereby offering a fast and efficient method of generating systems.

Second, reuse avoids the perils of duplicating code within an application. A software architecture that has functionality duplicated throughout the code base is difficult to change due to the need to affect code changes across multiple parts of the application. This is poor design and leads to systems that are slow to develop and expensive to maintain.

Achieving both of these reuse aims in the design of systems results in substantial benefits:

• Improved productivity

• Higher quality

• Improved software reliability

• Easier maintenance

• Reduced time to market

Software architectures that take advantage of the principles of software reuse provide an increased return on investment and a reduction in the total cost of ownership for the system's owners. However, attaining these benefits requires applying strict software engineering disciplines in the area of software design.

Reuse in software design is difficult to achieve. Over the years, considerable effort has gone into the development of languages and technologies that enable the full benefits of software reuse to be realized. To date, the greatest successes in the area of reuse have come from the practice of object-oriented design. There are two main areas of interest:

• Object-oriented programming for implementing reusable software elements at the code level

• Component-based architectures for building applications from prefabricated software components

Let's briefly consider both of these methods.

Object-Oriented Programming (OOP)

The object-oriented paradigm grew out of the desire to have languages capable of representing real-world objects and as a means of promoting software reuse. OOP languages embody the best techniques for code reuse developed to date and offer the software constructs necessary for building applications from existing software modules.

Java developers will already be familiar with the OOP reuse concepts of composition and inheritance. In addition to these, the advent of J2SE 5.0 adds another string to the Java developer's bow in the form of generics.

Component-Based Architectures

If Java is a language for software reuse, then J2EE is a platform for component reuse. The J2EE platform makes it possible to construct enterprise systems using component-based architectures. A component-based architecture has systems built by integrating established software component.

Chapter 4, Designing for Rapidity, examines component-based architecture options.

Components can span both horizontal and vertical domains in that they can provide both infrastructural and behavioral functionality. Engineers have the option of developing components inhouse or looking to other vendors to purchase shrink-wrapped offerings. In some cases, software development companies may elect to invest in the development of component libraries for a specific domain such as the government sector, financial services, or telecommunications.

Through this strategy, vendors of software development services are able to gain a sizeable competitive advantage. The construction of these component libraries is an important part of investing in an adaptive foundation for development.

Productivity Tools

Sophisticated development tools feature prominently in many of the different approaches to RAD. Selecting the right tool can dramatically increase productivity for virtually any given project task.

In addition to increasing productivity, tools can help simplify the process of developing software, a key concern for J2EE developers. Developing solutions for the J2EE platform is a complex task. J2EE pulls together a myriad of advanced engineering concepts, which includes object-oriented programming, distributed computing, multitiered architectures, and message-oriented middleware. Selecting the right tools can help considerably in dealing with the complexities of the J2EE platform and its enterprise services. Sun's Studio Creator and BEA's WebLogic Workshop are two examples of visual development tools that seek to ease the task of developing solutions for the J2EE platform by offering graphical drag-and-drop environments.

Another item in the RAD developer's toolkit is the integrated CASE tool, or modeling tool. CASE tools were a popular choice on RAD projects, and we assess how these modeling tools can contribute to the rapid development of J2EE applications in Chapter 5, Modeling Software. Later in the book, Chapter 8, Model-Driven Architecture, takes the use of models a step further and looks at how modeling tools that support the model-driven architecture (MDA) paradigm can automatically generate early iterations of working J2EE applications from minimal domain models.

The rapid developer needs to have more than just modeling tools in his or her repertoire. The importance of a fully integrated development environment is discussed in Chapter 13, The Integrated Development Environment, while in Chapter 15, Efficient Quality Assurance, the focus is on the benefits of testing tools.

Rapid Prototyping

Prototyping is arguable the most well known of all the RAD techniques and is ideally suited to a wide range of tasks. The practice is ideally suited for defining end-user requirements and for exploring the viability of suggested software architectures. Consequently, prototyping offers a low-risk approach to software development.

Some of the reasons to incorporate the construction of a prototype into your project schedule include:

• Addressing customer uncertainties

• Validating architectural decisions

• Resolving performance problems

• Capturing customer requirements

• Communicating ideas and intent to the customer

• Proving the choice of technology and platform

• Demonstrating user interfaces and workflows

• Driving out risk

Prototyping is a pivotal RAD technique and is referenced throughout the pages of this book. This next section looks at the different types of prototypes we can build and offers some guidelines for using them effectively.