Rapid Application Development ( RAD )

Basic Principle

Key objective is for fast development. Attempts to reduce inherent project risk by breaking a project into smaller segments and making them iterative. Aims to produce high quality systems quickly. Key emphasis is on fulfilling the business need. Project control involves prioritizing development. This is called RAD because reusable components can be integrated for quick development.

  1. Business modelling – This means the business details are identified firstly using hierarchies.
  2. Data modelling – The information gathered in the business modelling phase is reviewed and analyzed to form sets of data objects vital for the business.
  3. Process modelling – Process modelling means identifying the flow of processes using diagrams like flow charts.
  4. Application generation – The coding part is done using IDE’s and other tools.
  5. Testing and turnover – Testing time is reduced since pre-tested reusable component usage.

Strengths

  1. Uses minimal planning since the development should be faster.
  2. This approach tends to produce systems at a lower cost.
  3. Engenders a greater level of commitment from stakeholders.
  4. Concentrates on essential system elements from user viewpoint.
  5. Produces a tighter fit between user requirements and system specifications.
  6. Generally, produces a dramatic savings in time.
  7. Defining delivery deadlines.
  8. Includes Join Application Development. (JAD)
  9. Standard System analysis and design techniques can be fitted.
  10. Business focus.
  11. Saves human effort.

 

Weaknesses

  1. RAD requires sufficient human resources to create the right model.
  2. Lower overall system quality since sometimes the projects become no competitive.
  3. Danger of misalignment of developed system with the business due to missing information.
  4. Project may end up with more requirements than needed.
  5. Potential for feature creep where more features are added to the system over the course of development.
  6. Potential for inconsistent designs within systems.
  7. Potential for violation of programming standards related to inconsistent naming conventions.
  8. Difficulty with module reuse for future systems.
  9. Potential for designed system to lack scalability.
  10. Potential for lack of attention to later system administration needs built into system.
  11. High cost of commitment on the part of key user personnel.
  12. Formal reviews are more difficult to implement.
  13. Tendency for difficult problems to be pushed to the future to demonstrate early success to management.
  14. Well-defined interfaces are required.
  15. Formal audits are difficult.

Situations where most appropriate

  1. Project is of small-to-medium scale.
  2. Project scope is focused, where the correct requirements are in hand.
  3. Application is highly interactive.
  4. Users possess detailed knowledge of the application area.
  5. Requirements of the system are unknown.
  6. Team members are skilled both socially and in terms of business.
  7. Team composition is stable.
  8. Project is of short duration.
  9. Business objectives are well defined.
  10. Application has a clearly defined user group.
  11. Requirements of the system are uncertain.
  12. Technological or engineering excellence is of lesser importance.
  13. Business objectives are narrow.
  14. Application is not computationally complex.
  15. Project largely comprises analysis of the data.
  16. Effective project control is definitely available.
  17. Developers are skilled in the use of advanced tools.
  18. Technical architecture is clearly defined.
  19. Key technical components are in place.
  20. Technical requirements are reasonable.
  21. Development team is empowered to make design decisions.

Situations where least appropriate

  1. Very large projects.
  2. Real-time systems since these systems should be carefully planned.
  3. Computationally complex systems.
  4. Infrastructure projects.
  5. Safety critical systems.
  6. Project scope is broad.
  7. Applications in which the functional requirements have to be fully specified before any programs are written.
  8. Many people must be involved in the decisions on the project.
  9. The project team is large.
  10. When user resource is lacking.

Resources :

SELECTING A DEVELOPMENT APPROACH. (2005). 3rd ed. [ebook] Centers for Medicare and Medicaid Services, pp.1-10. Available at: https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Downloads/SelectingDevelopmentApproach.pdf [Accessed 6 Feb. 2017].

Ghahrai, A. (2008). Rapid Application Development Model. [image] Available at: http://www.testingexcellence.com/rapid-application-development-rad/ [Accessed 7 Feb. 2017].

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s