If the term rapid application development (RAD) were a Java method, it would have been deprecated long ago. As of the start of the new millennium, RAD had all but disappeared from the vocabulary of most software engineers.
Though the term is slipping from popular use as the hype surrounding RAD projects fades, the demand for rapid development is still as strong now as it was when RAD first emerged on the scene in the late 1980s. Despite tremendous advancements in the field of software engineering, telling statistics indicate the IT industry still struggles to realize the fast-paced demands of the business world.
So, what happened to RAD? If the requirement for RAD is as great now as it was 20 years ago, why is the term losing favor given the advent of Internet time and the accelerating pace of technological innovation?
The answer has more to do with marketing than software engineering. The concepts behind the various RAD methods are still valid, but the terminology has changed as the techniques and practices of RAD have evolved. Instead of talking of rapidity, we now speak in terms of agility.
Although the terminology of RAD is disappearing, its legacy is a set of mature software engineering practices. This chapter introduces the main elements to have come out of the RAD stable and puts them within the context of the practices and techniques this book presents for the purposes of rapid J2EE development. In particular, we focus on the benefits of prototyping, a technique now commonly associated with a fast-paced development approach.
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.
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.
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
Note
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 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.
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.
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.
Note
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.
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.
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:
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.
Prototypes are best undertaken as self-contained units of work with clearly defined objectives. Team sizes should be small, typically numbering no more than two or three people.
As prototypes are not destined for a formal release, many of the necessary standards and procedures that cradle production-level software are not applicable, much to the delight of the development team. This level of freedom makes for an intense development environment that many teams appreciate. Productivity tends to be high as engineers are able to focus on a discrete piece of work without the burden of the usual checks and controls endemic to larger projects.
Despite the benefits, the development of a prototype can sometimes appear as an unnecessary diversion when the pressure is on to deliver the real thing. For projects where time is at a premium, management often prefers to have staff focus on production code rather than diverting resources into the construction of prototypes. However, although the prototype requires upfront effort at the start of the project, its ability to drive out risk, clarify requirements, and validate the architecture enables significant time savings to be made throughout the project. Thus, by using prototyping to identify potential problems at the start of the project, these problems can be addressed early in the process before they snowball into major issues at later stages of the development.
Prototyping therefore offers a diverse range of benefits. Consequently, different types of prototype have evolved depending on their intended use.
Prototyping is an important concept of the IBM Rational Unified Process, which makes extensive use of the technique. The Rational Process defines several factors to consider when making use of prototyping as part of a development project [Kruchten, 2003]. The first of these factors is how prototypes fit into the overall project lifecycle. Here, there are two options:
Throwaway, where the prototype is discarded once its objectives have been met
Evolutionary, where the prototype is continually evolved into a production-level system
The second factor is the intended purpose of the prototype, which gives the type of the prototype. Again, there are two available options:
Behavioral, which demonstrates system behavior and helps capture user requirements
Structural, which validates areas of the system’s architecture
Over the next sections, we look at the purposes and needs of each of the different types of prototype as well as the tools and environment necessary to support their development.
As the name implies, the throwaway prototype, also known as an exploratory prototype, does not have long for this world. Its primary objectives are to validate a solution or to clarify a problem domain. Validation could be the performance of a part of the architecture and clarification could be of the look-and-feel of the user-interface.
Regardless of the purpose of the throwaway, it will be discarded once its objectives have been realized. Because the code from which it is built is not intended to be production level, the throwaway prototype can be assembled at great speed, using whatever tools, languages, and methods prove most expedient.
The evolutionary prototype has far loftier aspirations than does its throwaway counterpart. Here the prototype evolves throughout the life of the project, either gradually or rapidly, into the final system. In this case, the prototype is an integral part of the project lifecycle whereby the prototype is modified incrementally in response to customer feedback through a process of ongoing refactoring. This approach is closely associated with the practice of timebox development.
Since the evolutionary prototype will transform into the eventual system, greater discipline and control is necessary during its development. Unlike the throwaway, essential disciplines such as code style, code reviews, testing, and design documentation must all feature prominently in the prototype’s construction.
Behavioral prototypes, as the name implies, are concerned with what the system does, not how it does it. Typically, behavioral prototypes are built as throwaways.
The behavioral prototype usually targets the user interface and provides a mechanism for discussing ideas and requirements with the customer. Feedback captured from the customer needs to be quickly reflected in the prototype, thereby providing for the rapid transformation of ideas into solid requirements. In achieving this aim, the prototype needs to be constructed using suitable high-level tools and languages in order that the customer can see a fast turnaround of ideas into demonstrable functionality.
The structural prototype’s primary concern is proving the architecture of the system during the early stages of the project. Areas of the architecture that are identified as high risk can be proven using a small prototype before a full-scale development effort is commenced against the architecture.
Unlike behavioral prototypes, structural prototypes tend to be evolutionary instead of throwaway. Having proven a slice of the architecture, the code, rather than being discarded, is more likely to be evolved through refactoring until it is of a production level.
Throwaway and evolutionary prototypes are not incompatible on a project, as they each target different aspects of the project. You could therefore expect to use a behavioral prototype for establishing the system requirements by modeling the user interface and an evolutionary prototype to incrementally advance the architecture. Often, the question is not which prototyping approach to adopt but how best to combine the two.
Many factors impact the decision as to which approach is right for your project. The overheads of the throwaway may not be economically viable for a small project. If the project requirements are well defined, then an evolutionary prototype is probably the best option. If they are likely to be subject to constant change, then a throwaway prototype is the preferred choice in support of a requirements gathering exercise.
It is important that the type of approach be selected prior to commencing work on the final system. Starting with a throwaway and then attempting to convert to an evolutionary approach is unlikely to be successful. Likewise, the converse will result in expensive disposable code. The approach to the prototype governs the way in which the prototype is developed. Tighter quality control is required for evolutionary prototypes. Moreover, evolutionary prototypes have to be written in the language in which the final system will be implemented. In our case, this is Java. However, for the purposes of a throwaway prototype, a scripting language such as Perl, Python, or Tcl may be more applicable.
Finally, if you are going to make use of a specialized prototyping language or toolkit to help build the prototype at high speed, be careful to ensure you are able to reproduce the full functionality demonstrated to the customer in the final system. Even slight differences in the look and feel of the user interface can result in an unhappy customer.
Rapid application development is an approach to developing software that seeks to deliver on-time solutions that meet the needs of the customer.
Approaches to RAD vary, but the commonly accepted version of the process encompasses the key elements of:
An adaptive development approach using timeboxed iterations
Extensive use of prototypes
Sophisticated development tools for improving productivity
Domain-specific and high-level languages
Component-based architectures for assembling robust applications from proven software components
Although the usage of the term RAD is in decline, these key elements of RAD form the basis of today’s leading agile development processes. These new methods build on the promises of RAD, proclaiming to offer accelerated development times, fewer defects, increased customer satisfaction, and a solution for rapidly changing requirements [Boehm, 2003].
The next chapter examines this new breed of software methodologies and looks at the importance of adopting an adaptive approach to software development.
Prototypes don’t have to be developed on the computer. They can instead be constructed using a whiteboard and Post-it notes. For anyone interested in learning the techniques surrounding the use of paper-based prototypes, Carolyn Snyder has written a book on the subject, Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces [Snyder, 2003].
The Robert L. Glass title, Facts and Fallacies of Software Engineering, observes a few home truths with regard to software reuse and the attitude of software engineers to high-end development tools [Glass, 2002]. Interestingly, Glass notes that few of us use them.