RAPID APPLICATION DEVELOPMENT

The objectives of the REQUIREMENTS PLANNING stage are to establish a general understanding of the business problems that surround its development and eventual operation; to become familiar with existing systems and; to identify the business processes that will be supported by the proposed application.

A. In certain situations, a usable 80% solution can be produced in20% of the time that would have been required to produce a totalsolution;

B. In certain situations, the business requirements for a system can;be fully satisfied even if some of its operational requirementsare not satisfied;C. In certain situations, the acceptability of a system can beassessed against the agreed minimum useful set of requirementsrather than all requirements.

PRINCIPLES BEHIND THE DEFINITION

1. To more actively involve system users in the analysis, design, and construction activities;2. To organize systems development into a series of focused intense workshops jointly involving system owners, users, analysts, designers, and builders; 3. To accelerate the requirements analysis and design phases through an iterative construction approach; 4. To reduce the amount of time until the users begin to see a working system.

BASIC IDEAS OF RAD

BAD REASONS FOR USING RAD-to prevent cost overruns to prevent runaway schedules

GOOD REASONS FOR USING RAD-to converge early toward a design acceptable to the customer and feasible for the developers-to limit a project's exposure to the forces of change-to save development time, possibly at the expense of economy orproduct quality

WHY USE RAD?

CHARACTERISTICS OF RAD

A. RAD uses hybrid teams

1. Teams should consist of about 6 people, including bothdevelopers and full-time users of the system plus anyone elsewho has a stake in the requirements.

2. Developers chosen for RAD teams should be multi-talented"renaissance" people who are analysts, designers andprogrammers all rolled into one.

B. RAD uses specialized tools that support1."visual" development2. creation of prototypes3. creation of working prototypes4. multiple languages5. team scheduling6. teamwork and collaboration7. use of reusable components8. use of standard APIs9. version controlD.RAD USES ITERATIVE, EVOLUTIONARY PROTOTYPING1.JAD (Joint Application Development) MEETINGHigh-level end-users and designers meet in a brainstormingsession to generate a rough list of initial requirements.Developers talk and listenCustomers talk and listen

C. RAD USES TIME BOXINGSecondary features are dropped as necessary to stay on schedule.

RAD USES PROTOTYPES -to accelerate requirements analysis and system design.

a smaller-scale ,representative or working model of the users requirements or a proposed design for an information system.This prototype eventually evolves into the final information system in this case of RADBasic Principle: Users know what they want when they see it working.

What is PROTOTYPES?

a nonextendable period of time, usually 60-120 days, by which a a candidate system must be into operations.

What is a timebox?

STAGES IN RADPHASES IN RADREQUIREMENTS PLANNING(Concept Definition Stage)Business modelingUSER DESIGNData modelingCONSTRUCTION Process modelingIMPLEMENTATIONApplication generationTesting and turnover

1. All projects should be scoped and planned. This phase differs from model-driven development(waterfall technique) in that you rarely plan in as much detail. The RAD route (or any other route) is selected in the preliminary investigation phase.2. The problem analysis, requirements analysis, and decision analysis phases of the basic methodology (from Figure 3.50 are consolidated into a single accelerated analysis phase. The requirements statement may include some system models, but not nearly in the same level of detail and rigidity as in the model-driven approach.

PRE-PROJECT ACTIVITIESREQUIREMENTS PLANNINGSTAGES IN RAD NOTES3.After analysis, the RAD approach iterates through a prototyping loop (phases 3-6) until the prototype is considered a candidate system for implementation.

4.Design may use models, but not the extent of a pure model-driven approach. The final design evolves from the subsequent working prototypes.

5.The construction phase is depicted with a larger symbol to indicate the greater time spent constructing the working prototypes.USER DESIGNSTAGES IN RAD NOTESCONSTRUCTION6. Each prototype is initially implemented only to the extent that the users are given the opportunity to experience working with that prototype. The expectation is that users will clarify requirements, identify new requirements, and provide feedback on design (e.g., ease of learning, ease of use) for the next iteration through the design-by-prototyping loop.STAGES IN RAD NOTES7.Analysis is revisited based on user feedback to the prototype. This analysis tends to focus on revising requirements and identifying user concerns with the design. Notice, analysis cycles back to iterative design and the prototyping loop repeats itself.

8.Eventually, a prototype will be deemed worthy of implementation. This version of the system is placed into operation. The next version of the system may continue through the design-by-prototyping loop.STAGES IN RAD NOTESIMPLEMENTATION(Transition)1. Buying may save money compared to building2. Deliverables sometimes easier to port3. Development conducted at a higher level of abstraction4. Early visibility5. Greater flexibility

ADVANTAGES OF RAD

6. Greatly reduced manual coding7. Increased user involvement8. Possibly fewer defects9. Possibly reduced cost10. Shorter development cycles11. Standardized look and feel

1.Buying may not save money compared to building2.Cost of integrated toolset and hardware to run it3. Harder to gauge progress4. Less efficient5. Loss of scientific precision6. May accidentally empower a return to the uncontrolled practicesof the early days of software development7. More defects

DISADVANTAGES

8. Prototype may not scale up, a B-I-G problem9. Reduced features10. Reliance on third-party components may ...sacrifice needed functionalityadd unneeded functionalitycreate legal problems11. Requirements may not converge12. Standardized look and feel13. Successful efforts difficult to repeat14. Unwanted features

MERCI BEAUCOUP!REFERENCES:http://www.cs.bgsu.edu/maner/domains/RAD.htm

http://www.jscgroup.com/rapid-application-development.html