Agile Software Development And Rapid Application Development

Published Date: 02 Nov 2017

Agile development methodologies and Rapid Application Development have achieved acceptance in the software development industry. This research report examines the impact of Agile Methods and Rapid Application Development and describes the strengths and weaknesses of both methodologies.

Introduction

In this modern software industry the changes are very frequent to any software product. Most software companies nowadays aim to produce valuable software in short timke period with minimal cost within unstable and changing environment. In this rapid era, users become ever more demanding, business opportunities come and go, new laws and regulations appear, and technologies develop and so on. Traditional development methodologies are inappropriate to meet the rapidly changing requirements and short product cycles demanded by business. Agile software development and Rapid Application Development have been developed with the aim to deliver software faster and to ensure that the software meets changing requirements of customers.

Success of a software system is the degree to which it meets the customer's requirements. Broadly speaking, Requirements engineering is a traditional software engineering process to discover goal, by identifying stakeholders and their needs, and documenting these in a form that it is open to analysis, communication, and implementation. Fredrick Brooks describes why requirements are so important: "The hardest part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all of the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later" (Fredrick Brooks 1995).

Agile Methods

In comparison to traditional software processes, agile development is less document-centric and more code-oriented. Agile methods are not process oriented but people oriented. Agile methods rely on people’s expertise, competency and direct collaboration. Some of the methods in this family are:

Extreme Programming (XP): XP is based on values of simplicity, communication, feedback, and courage. XP uses story cards for requirement elicitation. A user story is a description of a software feature that provides information about business value to the customer. Customers have to think about what they expect the system to do before story cards are written. This process can be seen as brainstorming. Based on these estimates and the time available, customers prioritize stories to be addressed in the next iteration. XP focus on writing tests before coding. Acceptance tests are defined by the customer and used to validate the completion of a story card. XP is based on frequent small increments/releases. This can be compared with requirements review and with evolutionary prototyping.

Scrum: Scrum focuses on how a team should work together to produce quality work in a changing environment. All requirements regarded as necessary or useful for the product are listed in the product backlog. It contains a prioritized list of all features, enhancements, and bugs. The product backlog can be compared with an incomplete and changing requirements document containing information needed for development. For each sprint, the highest priority tasks from the backlog are moved to the sprint backlog. No changes are allowed to the sprint backlog during the. At the end of a Sprint a sprint review meeting is held that demonstrates the new functionality to the customer and solicits feedback. This meeting can be compared to requirements review and a presentation of an evolutionary prototype to the customer.

Feature Driven Development (FDD): FDD is a short iteration process for software development focusing on the design and building phase instead of covering the entire software development process. In the first phase, the overall domain model is developed by domain experts and developers. The overall model consists of class diagrams with classes, relationships, methods, and attributes. The methods express functionality and are the base for building a feature list. A feature in FDD is a client-valued function. The items of the feature list are prioritized by the team. The feature list is reviewed by domain members. FDD proposes a weekly30-minute meeting in which the status of the features is discussed and a report about the meeting is written. Reporting can roughly be compared with requirements tracking.

Dynamic Systems Development Method (DSDM): DSDM provides a framework for rapid application development. The first two phases of DSDM are the feasibility study and the business study. During these two phases the base requirements are elicited. Further requirements are elicited during the development process. DSDM does not insist on certain techniques. Thus, any RE technique can be used during the development process.

Adaptive Software Development (ASD): ASD provides framework for the iterative development of large, complex systems. The method encourages incremental, iterative development with constant prototyping where each cycle ends with a customer focus group review. During the review meetings a working application is explored. The results of the meetings are documented change requests. Although AS explicitly refers to JAD sessions it does not propose schedules for holding JAD. [1]

Process of Agile Software Development

Starts with a kick-off meeting

The known requirements are understood and prioritized. The development is plan is drawn accordingly.

Relative complexity of each requirement is estimated

Sufficient design using simple diagrams is done

Test Driven Development (TDD) approach may be used. TDD emphases on "writing test first and then writing code to pass the test". It can help in avoiding over-coding.

Development is done, sometimes in pairs, with lot of team interaction. Ownership of code is shared when pair programming is done.

The code is tested more frequently. Sometime a dedicated "Continuous Integration" Server/Software may be used to ease the integration testing of the code.

Depending on the feedback received, the code is refractor. Refactoring does not impact the external behaviour of the application but the internal structure may be changed to provide better design, maintainability. Some ways of refactoring may be add interface, use super class, move the class etc.

The iteration life cycle stages are illustrated below:

Agile Process Iteration

When to use Agile and when don’t

USE Agile When:

Functionality is split-able

Customer is available

Requirements are flexible

It is really time –constrained

Is team skilled enough

Don’t USE Agile When:

Functionality is not split-able

Customer is not available

Requirements are not flexible

Team is not skilled enough [2]

Rapid Application Development

Rapid application development (RAD) is a system development methodology that employs joint application design (to obtain user input), prototyping, computer aided software engineering (CASE) technology, application generators, and similar tools to expedite the design process.

Initially suggested by James Martin, this methodology gained support during the 1980s because of the wide availability of such powerful computer software as fourth-generation languages, application generators, and CASE tools, and the need to develop information systems more quickly. The primary objectives include high quality, fast development and low cost. [4]

Strength and weaknesses of RAD

Rapid application development promotes fast, efficient, accurate program development and delivery. Compared to other methodologies, RAD generally improves user/designer communication, user cooperation, and user commitment, and promotes better documentation. Because rapid application development adopts prototyping and joint application design, RAD inherits their strengths and their weaknesses. More specifically, RAD is not suitable for mathematical or computationally oriented applications. Because rapid application development stresses speed, quality indicators such as consistency, standardization, reusability and reliability are easily overlooked. [4]

When RAD works and when it doesn't

RAD TENDS TO WORK WHEN

The application will be run standalone.

Major use can be made of pre existing class libraries (APIs).

Performance is not critical.

Reliability is not critical.

System can be split into several independent modules.

The required technology is more than a year old.

RAD TENDS TO FAIL WHEN

Application must interoperate with existing programs.

Few plug-in components are available.

Optimal performance is required.

Product development can't take advantage of high-end IS tools.

RAD methods are used to build operating systems and computer games, where reliability and performance required too high.

The product is mission- or life-critical.

Conclusion

Agile should be implemented in projects of all sizes from small to large.

Agile should be adopted as a methodology in all projects as it is best suited to software development activities today.

Agile method awareness should be created across the organization.

Agile trainings should be conducted for the teams which are going to practice it in their projects.

RAD should be implemented in small projects where timelines are short.

RAD can be implemented only if customer is available for full participation.