You are on page 1of 8

Navigati on

Overview BASD RAD Agile ORM Model-driven development

RAD (Rapid Application Development)


Home Interactions RAD

Rapid Application Development (RAD) and Novulo


This article describes the Rapid Application Development software engineering methodology and its interaction with Novulo. It lists the advantages of combining RADs iterative prototyping with Novulo's application design method while discussing how to avoid the common pitfalls related to the short iteration cycle and extensive prototyping.

Introducing Rapid Application Development


RAD is a term introduced in 1991 by James Martin1 to describe a software development methodology that involves short iterations and relies partially on prototyping to complete specification requirements. In recent years, the acronym has been used in a broader sense to encompass a set of techniques (such as the use of frameworks) aimed at accelerating application development. RAD is often used in situations where time constraints force an approach in which faster application development is given priority over full functionality and performance.

Goal and advantages


As the name implies, Rapid Application Development focuses on accelerating software systems development. However, RAD was created as a response to non-Agile processes for software engineering, such as the Structured Systems Analysis and Design Method and other Waterfall models. The iterations and prototyping create opportunities to meet changing requirements during the development phase while uncovering requirements that were not specified during the initial requirements analysis. A successful RAD strategy is aimed at gaining the following advantages:

Faster application development

Improved quality (According to RAD, quality is defined as both the degree to which a delivered application meets the needs of users as well as the degree to which a delivered system has low maintenance costs)

How it works
Rapid Application Development is not appropriate for all projects. The methodology works best for projects where the scope is small or work can be broken down into manageable chunks. Along these lines, project teams must also be small preferably two to six people and must have experience with all technologies that are to be used. Business objectives will need to be well defined before the project can begin, so projects that use RAD should not have a broad or poorly defined scope. Furthermore, in order to keep the project within a short time frame, decisions must be able to be made quickly, making it imperative that there are very few client decision makers (preferably only one), and they must be clearly identified up front.

Prototyping
One of the key aspects of RAD is constructing prototypes for the purpose of jumpstarting design and fleshing out user requirements. The objective of prototyping is to build a feature-light version of the finished product in as short an amount of time as possible, preferably in just days. The initial prototype serves as a proof of concept for the client, but more importantly serves as a talking point and tool for refining requirements. Developing prototypes is where CASE (Computer Aided Software Engineering) plays an important role. The creation of prototypes may seem to be an odd choice in a strategy aimed at speeding up development. However, the use of a development platform that focuses on capturing requirements, converting them to a data model, converting the data model to a database, and generating code can actually save precious time. CASE tools were popular in the late 80s and early 90s, but as technology has changed (and COBOL has become obsolete) few tools take total advantage of the full potential of CASE tool technology.

Iterations
Developing applications using iterations means releasing increasingly functional versions of an application in short development cycles. Each release is discussed with the client in order to review requirements for the next iteration. These iterations can typically take between one day and three weeks, depending on the specific type of RAD methodology applied to the project.

Time boxing
Time boxing is the process of selecting features to be released in future iterations in order to complete the current version in a short amount of time. The importance of this step is not to be underestimated. Without proper and strict time boxing the length of iteration cycles will grow, minimizing the benefits of RAD and increasing the risk of feature creep3.

Project management
Active and involved project management is vital to mitigate the risks of lengthened development cycles, client misunderstandings, and missed deadlines. Due to the short iterations, management must be focused on clearing any

obstacles that exist on the business end and guaranteeing the active involvement of the client in prototyping, writing test cases, and performing unit testing.

Technology
When RAD was first conceived it was deemed important to utilize tools incorporating the latest technologies to speed development. This is no less true today; the choice of technology to implement a project with is a significant factor in maximizing the benefits of RAD. As the industry combines best practices from different strategies, new technologies evolve that allow faster prototyping, better modeling, or frameworks that are more feature-complete.

RAD vs. Waterfall


In the 1970s and 1980s, several sequential software engineering processes were developed that regarded application development as flowing steadily downward through the different phases of the development process. The first description of such a waterfall model is often cited in an article published in 1970 by Winston W. Royce2. However, in this article, Royce presented the model as an example of a flawed, non-working approach. "Waterfall" has in later years become a common term to criticize traditional software development practices. The problem with most waterfall models is the fact that it relies on a methodical requirements analysis phase alone to identify all critical requirements for the application. There is ample evidence that projects using a waterfall approach often fail to provide a useable end product; because projects often exceed their deadlines, the product either fails to meet all requirements or the requirements change during the protracted development phase. There have been many responses to this problem from the 1980s to today, but almost all of those responses focus on the idea of developing systems in a short timeframe with small teams of highly skilled and motivated staff. It is the iteration step that solves the problems inherent to the inflexible approach of traditional software development.

Traditional development vs. Rapid Application Development

RAD methodologies

Over the years, many different forms of RAD have arisen, each with their own techniques and focuses. The following is a short list of popular methodologies and their main goals:

Agile - Minimizing "feature creep" through short intervals and mini-increment releases. Extreme programming Lowering cost of change though quick "spirals" and "on-the-fly" design. Programmers are required to work in pairs.

Joint Application Development (JAD) Involving the customer in the design and development phases using collaborative workshops (JAD sessions)

Lean Development (LD) Creation of minimalist solutions and delivering less functionality but in a shorter amount of time (80% today is better than 100% tomorrow)

Scrum Improvement in productivity through teams with daily measurement of progress, daily meetings (called the scrum), and focus on prioritizing work items. Scrum iterations are called sprints and are controlled by a "scrum master."

Risks
Since Rapid Application Development is an iterative and incremental process, there are certain risks to using RAD. It can lead to a succession of prototypes that never results in a satisfactory end product. The risks in RAD as opposed to "waterfall" development are related to the fact that RAD does not rely on a single requirements analysis phase.

Feature creep
Feature creep (also known as Scope creep or sometimes referred to as kitchen sink syndrome) is the term most commonly used when referring to the rapid increase of required features in a product after a project start. It is the most common source of cost and schedule overruns that can endanger or even terminate projects and products. Apple's abandoned Copland operating system is an example of a project terminated by feature creep. Avoiding feature creep requires involved project management and a willingness from both the client and the project management team to stick to the RAD development cycles.

Reduced features
Due to timeboxing, where features are pushed off to later versions in favor of delivering an application in a short time frame, RAD may produce applications that are less full-featured than traditionally developed applications. The choice of technology used to implement the project plays an important role in the "feature-richness" of the end result. A robust and complete framework can provide the application with the extra functionality needed to ensure a highquality and full-featured system.

Popularity
The software industry has seen a change in development strategy, shifting from session-based client / server development to sessionless collaborative development. This, coupled with the growing utilization of open source frameworks and products in core commercial development, has rekindled interest in RAD methodologies for many developers.

All forms of RAD have the potential for providing a good framework for faster product development with improved code quality, but successful implementation and benefits often hinge on project type, schedule, software release cycle, and corporate culture. In recent years, Agile/Scrum (commonly used together) and Extreme Programming have received a lot of attention. One interesting commonality between the two approaches is the belief that code quality 3 plays a key role in both the maintainability and the continued application of RAD without loss of development speed in future iterations.

RAD and the Novulo development platform


Rapid application development has three key concepts: Prototyping, iterations, and timeboxing. How can these concepts be implemented using the Novulo platform and in what way does Novulo reduce the common risks associated with RAD?

Visualize, design, generate: Prototyping deLuxe


The software industry recognizes the benefits of using prototypes to increase business alignment and customer satisfaction through a better understanding of the client's needs. There are many CASE tools that utilize code generation to support prototyping, but most fail to offer a practical design interface or simply create code artifacts that still require extensive programming before a prototype is created. The following is a list of criteria commonly used to qualify/disqualify software (in particular code generators) as a RAD platform and their relation to Novulo: 1. Supports existing technologies, architectures, and best practices Novulo utilizes some of the most reliable and popular technologies for data management, interface controls, and even programming environments. Novulo seamlessly integrates the best and latest technologies available. 2. Produces enterprise level code (i.e. n-tier code4) With Novulo, the generated application features logically separate layers for presentation, application processing, and data management. Each of these layers can potentially be interchanged for another layer of the same logical structure. This way, the same application can be generated using an alternative presentation layer, changing look and feel while data management and application processing remain the same. 3. Generates prototype applications without having to write a line of code (do not accept a code generator that does not at least attempt to generate a presentation layer code) Most generators are designed to create (minimal) data management or business logic code, but fail to create a presentation layer. The reason for this is that these generators use textual models that do not contain any information about desired interface components. If a presentation layer is generated, it is unlikely that this layer will not need coding to live up to the demands of the customer. The application model in the Novulo Architect contains the visual elements used to build the interface as well as business logic and data structure. This means that the Novulo generator can effortlessly create a fully functional interface, resulting in a more complete prototype.

4.

Uses templates or a technology that allows complete control over outputted code Any element in the application design can be specified to be a "custom element." During code generation, a predefined structure is generated for each element marked as custom, allowing for direct intervention in code at data, logic, or presentation level.

5.

Provides a flexible meta-data mechanism The visual representation itself is a great way to store and retrieve information about application design elements. Using the Architect's process and expression editor, the inner workings of intricate processes and functions become easier to understand. Information for each aspect of the design can be stored on the lowest element level.

6. code.

Can be used throughout the entire development process, and specifically will not overwrite your

If no file exists for an element marked as custom, the generator will create the predefined code for that custom element. The code can then be customized and Novulo will not overwrite it. Since the Architect still allows the custom element to be modified, the generator will create so-called "revision files" if the element is changed. This way, the Architect helps the programmer to manually update code that was marked custom. As you can see from the above list, the unique combination of Novulo's intuitive visual representation, powerful modeling options, fast code generation, and a robust and complete .NET framework provide the opportunity to almost immediately demonstrate the result of a design choice in a generated application.

Novulo helps keep iterations short.


In RAD, after discussing each prototype and establishing requirements for the new iteration, work starts on implementing the features in the current time box. When using Novulo, this work can be done directly after discussing requirements, effectively involving the client in the design. In a few short sessions the design is changed, optional coding can be done and the new prototype (or finished product) is ready. Because of the speed in design and the client involvement, the new prototype will be ready faster and better meet the customer's view of the desired system. Requirements will have changed less because of the short iterations and less future iterations may be needed to reach a complete and satisfactory end product.

Timeboxing
The Novulo Architect contains a built-in Work item tracker, allowing the user to add work items to any element in the system. The work item note can hold information for a programmer (in the case of custom elements) or indicate that further design work is needed at a particular point in the application design. Clever use of this system can help in maintaining a strict timebox system, by prioritizing and listing work items. Each work item related to a feature in the timebox should be finished in that time box and be set to "finished" in the Architect. This way progress within a timebox is instantly visible.

Conclusion

Traditional "straight-forward"development methods are often criticized by software developers for the inflexibility caused by the dependency on a single requirements analysis. Rapid Application Development proposes an approach aimed at better serving the needs of the software market by allowing change using the prototyping, iteration, and timeboxing concepts. In recent years, the focus of RAD has evolved to more practical methods for prototyping, faster iterations through better code generators, and the use of (web-) application frameworks. In spite of its popularity, there are very few software suites that can fully support RAD techniques. Many modeling tools cannot generate code, code generators use impractical models that cannot allow a complete application to be generated and a lot of application frameworks are not suitable for quick prototyping and code generation. Novulo meets all criteria for a RAD capable development environment. It utilizes proven, reliable technologies, produces multi-tier code, generates applications at the push of a button, allows custom coding, includes descriptive representations and can be used throughout the entire development process. Novulo combines the best practices of RAD combined with the biggest advantages of several other technologies in order to provide a versatile and flexible yet reliable platform for your development. The award-winning Novulo technologies can remove the barriers for a successful RAD implementation and grant developers the power, flexibility, and speed needed to take control of the development process.

Notes
1. James Martin published over a hundred books, many of which were best sellers in the IT industry. Martin is frequently called "The Guru of the Information Age." 2. Winston W. Royce is one of the leaders in software development in the second half of the 20th century, he described the waterfall methodology as a flawed example, but did not introduce the name "waterfall" 3. Feature creep is often caused the desire to provide the end-user with a more useful or desirable product, causing cost and schedule overruns. Rigorous change management is sometimes applied to avoid feature creep. 4. A software product is said to be n-tier (or multi-tier) if the application used logically separate layers (or tiers). A typical three-tier application has separate layers for presentation, logic, and data.

Glossary
Iterative prototyping Development technique where a working prototype is created as soon as possible, after which new features are added in each increment. Non-agile processes Traditional development processes, using a straightforward development flow. CASE

Computer Aided Software Design, scientific application of a set of tools and methods in software development, resulting in high-quality, defect-free, and maintainable software products. COBOL Acronym for COmmon Business-Oriented Language, created in 1959. Requirements analysis Determining the needs or conditions to meet for a new or altered product, taking into account the interests of the various stakeholders. Requirements analysis is critical to the success of a development project. Meta-data mechanism Method for entering/storing data describing other data.

Resources
Gantthead RAD Process, online community for IT project managers article

You might also like