Abstract

As software continues to be developed at a mind-boggling speed, it’s important to step back, and look at how it’s created. Two emerging and popular development methods of the modern age are the rapid application development (RAD) and the agile software development methodologies. This paper compares these methodologies and presents specific areas were these methodologies would be suitable.

Introduction

The rapid application development and agile methodologies were both created as responses to the perceived limitations of structured traditional management techniques like the waterfall model. But, rapid application development was the first engineering methodology to identify the underlying differences between software engineering and conventional engineering. With conventional engineering projects like mechanical systems, huge physical plants or bridges, engineers cannot start building them and then change their minds halfway through. In contrast, software development projects are transient. So, engineers can change their minds if needed. RAD and agile models exploit this by welcoming changes in requirements even late into the development process.

Rapid Application Development

Although contrived back in the 1980s, the use of rapid application development (RAD) is currently proliferating and used as an expediting methodology for digital transformation in 2018 and beyond. During the 1970s, software engineering projects followed the waterfall model, a traditional engineering process, which is similar to the methodology applied to building bridges and huge physical plants. In this methodology, software architects work together with the stakeholders who requested for the software to draft functional requirements, then spend countless hours interpreting them in specifications sheets. Development begins only after all the specifications were completed. Then, after months or sometimes years of development, the stakeholders and end users of the software get their first look at the completed software product. If it failed to meet the expected results of the stakeholders, the engineers would rewrite the existing source code to meet expectations, which in turn increases the delivery time and costs. (Pike, 2018)

During the 1980s, software engineers Barry Boehm and James Martin realized the inherent flaw in this approach, the waterfall methodology. From their perspective, unlike inflexible resources like bridges, software was changeable and they advocated that software development projects needed to exploit this attribute. Consequently, the rapid application development methodology, depicted in Figure 1, was introduced in 1991 by James Martin. (Wikipedians, 2013)

Figure 1: The Rapid Application Development model

2.1.   Advantages of Rapid Application Development

The intrinsic nature of RAD permits adaptability to changing customer requirements throughout the development cycle. Consequently, the following are the benefits for using RAD:

Shorter delivery time and Lower cost: By consistently presenting working pieces of the product to stakeholders during the prototyping phase, shown in figure 1, it is highly probable that the final delivery of the product will be acceptable to the stakeholders and end users on the first time delivery. Also, since the engineering team starts creating working prototypes right after the requirements phase, there is a regular delivery to show to the stakeholders within a short time span. Consequently, this saves time and lowers the cost on resources.

Higher Satisfaction: By having the customer always there at every step of the process as prototypes are delivered frequently, the client becomes more confident about the final delivery. Also, the development team is constantly getting immediate feedback which allows them to quickly address any changes that need to be made before the prototypes are added to the completed product. As a result, both the client and the development team are satisfied. (Pike, 2018)

2.2.   Disadvantages of Rapid Application Development

While RAD facilitates a shorter delivery time and a higher satisfaction for both the clients and the developers, RAD is not perfect and has its own drawbacks including:

Scale: While a small team of developers can readily adapt to changing requirements from the client, it will be very challenging to keep a large, distributed team on the same page since inter-communication between the smaller teams will begin to slow down and disorganize the direction of the project. (Idesis, 2017)

Commitment: The recurring cycle of prototypes in RAD demands developers and clients to commit to regular feedback assessment and feedback meetings, which may seem overwhelming.

Interface-focus: Since RAD is prototype intensive, clients may justify the quality of the product by what they can interact with, and normally what they interact with is a charade of the expected result. Therefore, there’s a risk that some best practices are ignored by developers on the back-end to expedite development of the front end. (Pike, 2018)

Agile Methodology

Created in February 2001 by 17 software developers, agile recognizes that software projects are fundamentally unpredictable and that there are likely to be changes over the course of the project. These changes, be it market changes or feature changes as the product comes to life will need to be addressed. As shown in figure 2, agile welcomes this volatility by breaking down projects into small chunks called sprints, to facilitate prioritization and allowing engineers to add or drop features during the project.

Figure 2: Agile Methodology

3.1.   Advantages of Agile Methodology

Agile methods stress efficiency and practicality over heavy-weight process overhead and documentation. Advantages of the agile methodology include:

Speed to market: Documentation in agile is short and to the point. This cuts down the time spent on heavyweight documentation allowing agile teams to a get working deliverable to the client in a short time.

Risk management: Incremental software delivery to the client helps identify issues and feature deficits early in the process. Through feedbacks received from the stakeholders and end users, project managers are quickly informed about potential risks which can addressed earlier in the development process.

Customer satisfaction: Since customers are consistently involved throughout the entire project, improvements can be made to the working software based on customer feedback. Consequently, customers receive a high quality final product guaranteeing the customer’s satisfaction as the entire software is developed based on the requirements taken from customer.

3.2.   Disadvantages of Agile Methodology

Though the agile model is revolutionary and offers a different approach to the traditional waterfall model, there are various limitations which include:

Lack of documentation: Although less documentation saves time in the development process, this can be a big disadvantage for new developers joining the team at the later stage since it will be difficult to understand the actual method followed to develop the software.

Possible process derailment and time-wasting: The agile methodology heavily depends on customer interaction. Therefore, it is probable that the development process goes out of the track when the customer is not clear about product features and requirements. As a result, a huge amount of time and resources may be wasted in the process leading to an increase in development cost and delivery time.

Conclusion

In conclusion, although RAD and the agile methodologies share similar values, with regards to flexibility, shorter delivery time, and high customer interaction and satisfaction, RAD is primarily focused on prototypes while agile is mostly focused on breaking down the project into features which are then delivered in various sprints over the development cycle. Based on the discussed advantages and disadvantages of RAD and agile methodologies, RAD is mostly suitable for projects with preferably six or fewer highly skilled developers, where prototypes are allowed within very tight deadlines. On the other hand, the agile methodology is generally suitable for projects with ideally twenty or less developers, where incremental feature delivery is the main focus.

References