Tech

Guides

Business Applications ▪ Database Management ▪ Disaster Recovery ▪ Enterprise Servers & Storage ▪ IT Security ▪ Java ▪ Microsoft Office Suite ▪ Network Admin ▪ Open Source ▪ SMB ▪ SOA ▪ Tech Management ▪ Software/Web Development ▪ Windows Server ▪ Wireless Tech

Software/Web Development TechGuides

Five IDEs tested

By David McAmis, Builder AU, Special to ZDNet Asia
Tuesday, October 05, 2004 05:12 PM

Builder AU technical editor, David McAmis tests out five of the most popular IDEs today to see if they live up to the Rapid Application Development (RAD) claim.

It seems like every vendor with a software development tool or platform claims that it can be used for “Rapid Application Development” with little evidence to back it up.

Testing the Tools

		MS Visual Studio.NET Sun Java Studio Creator BEA Web Logic Workshop Borland C# Builder IBM WebSphere Studio Summary

What is RAD?

In addition to being a marketing buzzword, the term RAD is used to describe applications that can be designed and developed within 60-90 days. James Martin first explored the concepts of RAD while working at Dupont in the mid-eighties. It was there that he and Scott Shultz formalized a system of developing applications using a methodology he developed called rapid iterative production prototyping, that used flowcharting to design programs and applications.

Martin is considered to be the father of computer-aided design and his original work has been grown, augmented and expanded into the discipline we currently know as RAD. Over the years, RAD has grown to include a number of basic tenets for what defines a RAD project.

To start, a RAD project is characterized by the use of prototypes. A RAD prototype helps to jump start the design process and can demonstrate the look and feel of the application, as well as cutting down on the time required to gather requirements from users for the initial features and functionality.

The concept is that with a basic set of requirements from users, a developer can quickly build a prototype that the user can interact with and suggest features, enhancements, etc., usually in a workshop setting, as part of joint requirements planning (JRD) or joint application development (JAD) process. So any development tool or platform that is touted as a RAD tool should be able to facilitate taking user requirements from a JRD workshop and quickly creating an application prototype that can be reviewed and modified in a JAD workshop with users.

A good RAD tool should also provide developers with the tools to quickly add and remove features without requiring extensive re-writes, using a component-based architecture. In addition to changing user requirements during the course of a RAD project, most projects are “timeboxed”, meaning that there is a set length of time that has been set for the completion of the project. Any features or functionality that is not able to be delivered within that set time frame are removed or deferred to future release.

A second attribute of applications created using a RAD methodology is that there are a number of developers who may be working on the application at the same time and these developers can fulfill a wide range of roles within their team. For example, you may have a developer who has also created the architecture for the application in question, as well as designing the user interface and the code behind the scenes. This same resource may also be developing the test plans, testing the application, writing documentation, and eventually training users. In a more formal project, these roles may be divided among multiple resources. In a RAD project, time and resource constraints often mean that these roles (and more) must often by undertaken by a single developer. For a IDE to support this facet of RAD, it must be adaptable to the different roles a developer must play and support each of these roles in turn.

In addition to supporting the different roles within a team, a RAD tool must also be able to support the use of third-party components to deliver user requirements. In the debate over build-Vs-buy, developers must be able to buy the components they don’t have the time or inclination to build. For example if a developer is doing both the coding and user interface design for an application, they must be able to integrate components that could cut down the time required for either task (ie, code libraries, UI components, etc.)

Finally and most importantly, the litmus test for applications created using the RAD methodology is their fitness for a particular business purpose. In the normal phases of an application created using the proper software development lifecycle (SDLC), there would be a formal design process, where there are a number of deliverables during the cycle, including formal interviews, detailed design documents, semantic mapping between existing systems, process documentation, etc. that must be delivered.

In a RAD project, the primary question at the end of the project is “Does this application suit the business process for which it was created?” If the answer is yes, then the project is considered a success. To that end, a RAD tool should provide the ability to quickly create an application that solves the business problem at hand. And while there are elements of the SDLC that may be included in a RAD project, this is not a primary concern. For example, with a true RAD tool, the ability to generate a process-flow diagram or database schema is not as important as delivering the functionality required by the business process.