5

The Rise of RAD and Its Application in the Tech Industry

 1 year ago
source link: https://dzone.com/articles/the-rise-of-rad-and-its-application-in-the-tech-in
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

The Rise of RAD and Its Application in the Tech Industry

In a bid to make software development much more cost-effective and time-efficient, RAD, or rapid application development, was proposed in the 1980s.

by

CORE ·

Jul. 08, 22 · Agile Zone · Analysis

Software development wasn’t always so fluid and efficient. The early beginnings of software development took months to prepare for and even more months in the development process, much like traditional engineering. Developers would come up with a plan that took laborious months and software architects would work directly with end users in order to come up with functional designs before defining them in spec sheets. If their clients didn’t like what the option they were presented with, it was back to the drawing board and developers would have to yet again start from scratch, taking even years to produce something that their clients first requested. Aside from opportunity cost, the expenditure to fund such undertakings were astronomical. 

In a bid to make software development much more cost-effective and time-efficient, RAD, or rapid application development, was proposed in the 1980s. The idea was that software development should be treated as a malleable and intuitive process, rather than something rigid as constructing a building. Instead of focusing on costly planning, RAD emphasized rapid prototyping.

The pioneers, Barry Boehm and James Martin, among others, designed their respective development models such as the Spiral Model and the James Martin RAD model. James’ model went on to inspire Agile development. 

Varying RAD Methodologies Have Similar Practices

Instead of being extremely detailed with their vision, RAD focuses on developing around a loose set of requirements. Change is seen as inevitable and there is no room for stubbornness. Developers and clients have to work together in a seamless process to develop an application that meets their needs in an effective manner. It is very much like creating art. Sometimes you might have an inspiration for a certain pose using specific colors, but as you go along and flesh out the drawing, you discover that the pose requires to be tweaked, or that another color would be more aesthetically pleasing. 

Instead of holding developers against a firm set of expectations, RAD allows for creativity in a sense. Once the vision comes together, it is time for prototyping and the usual RAD process requires developers to submit a prototype that can demonstrate what the final product may look like or feel like. It might be filled with dead links or empty pathways, but it gives the client a clear idea of what the developer is creating. 

After the client offers feedback on how the application can be further improved, or if any additional tweaks are needed, the developer will take all the feedback he has accrued and apply it to the final product. Sometimes, end users also come into play, which is when you might see beta testing, where the product is usually given to end users for free in exchange for their feedback. 

If the software does not meet the client’s vision, the developer will have to revert back to designing the software. Sometimes, the fault doesn’t just lie with the developer. The client may also realize that their idea works better on paper, so it is up to the two to come up with something that is more intuitive or concise. 

Once the client has approved the prototype, developers will then be able to move on to finalizing their product. This is where developers start to connect the dots and flesh out the product, doing everything that they can in order to submit a final product. 

You can look at a website like Guide to Iceland and come up with extremely different itineraries and travel advice articles, but when it comes to software development, specifically, those that utilize RAD, you’ll find that the processes or phases are more or less the same.

While RAD May Sound Advantageous, There Are Disadvantages As Well

RAD is definitely less time-consuming than traditional waterfall approaches, but it isn’t appropriate for huge corporations that do not have effective communication. A smaller team of developers will most likely benefit from RAD practices, but any organization that requires inter-team communication may delay production rather than enhance it. 

Another problem with RAD is that developers are much more likely to design a product that satisfies the client but does not meet the needs of end users. For example, Facebook as a social media network is successful as it offers features in line with human nature. We are social creatures that enjoy attention and connectivity. However, if today Facebook focused more on marketing than its human-centered design, it may never have taken off the way it did. If a business owner wanted to create Facebook solely for marketing purposes, the initial allure of the networking site would be lost as developers strive to develop a site that aligns with their client’s vision. 

Some projects definitely require traditional waterfall methodology, such as any software that is mission-critical, such as flight control, life-saving monitoring software, and so on. For the consumer-oriented market, however, RAD is not only the most obvious choice — it is simply a better one. 


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK