RAPID APPLICATION DEVELOPMENT

© 1997 by Walter Maner (unless otherwise noted)
May be reproduced only for non-commercial educational purposes.

The outline below requires Netscape/Microsoft browsers, version 3.x or later, for correct viewing.

Revised March 15, 1997
  1. Back Top Next
    PICTURE
  2. Back Top Next
    DEFINITION
    a software development process that allows usable systems to be built
    in as little as 60-90 days, often with some compromises
  3. Back Top Next
    PRINCIPLES BEHIND THE DEFINITION
    1. In certain situations, a usable 80% solution can be produced in
      20% of the time that would have been required to produce a total
      solution.
    2. In certain situations, the business requirements for a system can
      be fully satisfied even if some of its operational requirements
      are not satisfied.
    3. In certain situations, the acceptability of a system can be
      assessed against the agreed minimum useful set of requirements
      rather than all requirements.
  4. Back Top Next
    PROBLEMS ADDRESSED BY RAD
    1. With conventional methods, there is a long delay before the
      customer gets to see any results.
    2. With conventional methods, development can take so long that the
      customer's business has fundamentally changed by the time the
      system is ready for use.
    3. With conventional methods, there is nothing until 100% of the
      process is finished, then 100% of the software is delivered.
  5. Back Top Next
    WHY USE RAD?
    1. BAD REASONS FOR USING RAD
      1. to prevent cost overruns
        (RAD needs a team already disciplined in cost management)
      2. to prevent runaway schedules
        (RAD needs a team already disciplined in time management)
    2. GOOD REASONS FOR USING RAD
      1. to converge early toward a design acceptable to the customer
        and feasible for the developers
      2. to limit a project's exposure to the forces of change
      3. to save development time, possibly at the expense of economy or
        product quality
  6. Back Top Next
    SCHEDULE versus ECONOMY versus PRODUCT QUALITY
    1. Tradeoffs determine the pace of development.
      1. Efficient Development
        balances economy, schedule, and quality
        1. Schedule -- faster than average
        2. Economy -- costs less than average
        3. Product -- better than average quality
      2. Sensible RAD
        tilts away from economy and quality toward fastest schedule
        1. Schedule -- much faster than average
        2. Economy -- costs a little less than average
        3. Product -- a little better than average quality
      3. All-out RAD
        "code like hell"
        1. Schedule -- fastest possible
        2. Economy -- costs more than average
        3. Product -- worse than average quality
    2. For RAD, something other than schedule must be negotiable.
      1. RAD has a fair chance of success if the customer will negotiate
        either economy or quality
      2. RAD has a better chance for success if the customer will
        negotiate both economy and quality
      3. NOTE: Negotiating quality does NOT mean accepting a higher
        defect rate. It means accepting a product that is less usable,
        less fully-featured, or less efficient.
    3. So, with RAD, one or more of the following goals may be
      unachievable.
      1. the fewest possible defects
        (because developers may not have the legal right to modify the
        source for some plug-in components)
      2. the highest possible level of customer satisfaction
        (because secondary requirements may be sacrificed to stay on
        schedule)
      3. the lowest development costs
        (because buying reusable components may cost more than
        building)
  7. Back Top Next
    ABBREVIATED HISTORY OF RAD
    1. Barry Boehm (spiral model) --->
    2. Tom Gilb (evolutionary life cycle) --->
    3. Scott Shultz (RIPP, rapid iterative productive prototyping) --->
    4. James Martin (RAD, circa 1991)
  8. Back Top Next
    CHARACTERISTICS OF RAD
    1. RAD USES HYBRID TEAMS
      1. Teams should consist of about 6 people, including both
        developers and full-time users of the system plus anyone else
        who has a stake in the requirements.
      2. Developers chosen for RAD teams should be multi-talented
        "renaissance" people who are analysts, designers and
        programmers all rolled into one.
    2. RAD USES SPECIALIZED TOOLS THAT SUPPORT ...
      1. "visual" development
      2. creation of fake prototypes (pure simulations)
      3. creation of working prototypes
      4. multiple languages
      5. team scheduling
      6. teamwork and collaboration
      7. use of reusable components
      8. use of standard APIs
      9. version control
        (because lots of versions will be generated)
    3. RAD USES "TIMEBOXING"
      Secondary features are dropped as necessary to stay on schedule.
    4. RAD USES ITERATIVE, EVOLUTIONARY PROTOTYPING
      1. JAD (Joint Application Development) MEETING
        High-level end-users and designers meet in a brainstorming
        session to generate a rough list of initial requirements.
        1. Developers talk and listen
        2. Customers talk and listen
      2. ITERATE UNTIL DONE
        1. Developers build / evolve prototype based on current
          requirements.
        2. Designers review the prototype.
        3. Customers try out the prototype, evolve their requirements.
        4. FOCUS GROUP meeting
          Customers and developers meet to review product together,
          refine requirements, generate change requests.
          • Developers listen.
          • Customers talk.
        5. Requirements and change requests are "timeboxed".
          • Changes that cannot be accommodated within existing
            timeboxes are eliminated.
          • If necessary to stay "in the box," secondary requirements
            are dropped.
      3. NOTES
        1. Iterations require between 1 day and 3 weeks.
        2. At some stage, exploratory prototypes may evolve into
          operational prototypes.
        3. Focus Group Sessions
          • last about 2 hours
          • are led by an experienced facilitator, who keeps the
            group "on focus"
            • by having clear goals regarding the kind of
              information that needs to be elicited
            • by preparing an issue-oriented agenda in advance of
              the meeting
            • by ensuring that adequate discussion is directed
              toward each issue
            • by ensuring everyone has an adequate opportunity to
              participate
          • are followed by a report from the facilitator
  9. Back Top Next
    IMPORTANT RAD CONSTRAINTS
    From Sun and other sources
    1. "Fitness for a business purpose" must be the criterion for
      acceptance of deliverables.
    2. All constituencies that can impact application requirements must
      have representation on the development team throughout the
      process.
    3. Customers, developers and management must accept informal
      deliverables.
      1. Paper prototypes rather than full-scale systems
      2. Notes from user workshops rather than formal requirements
        documents
      3. Notes from designers' meetings rather than formal design
        documents
      4. PRINCIPLE: Create the minimum documentation necessary to
        facilitate future development and maintenance.
    4. Development teams must be empowered to make some decisions
      traditionally left to management.
    5. End-to-end timescale must be 6 months or less.
    6. Iteration must be used in such a way that the development process
      converges toward an acceptable business solution.
    7. Prototyping must incorporate evolving requirements quickly, in
      real time, and gain consensus early.
    8. There must be a "buy before build" bias.
  10. Back Top Next
    WHEN RAD WORKS AND WHEN IT DOESN'T
    1. RAD TENDS TO WORK WHEN
      1. The application will be run standalone.
      2. Major use can be made of preexisting class libraries (APIs).
      3. Performance is not critical.
      4. Product distribution will be narrow (in-house or vertical
        market).
      5. Project scope (macro-schedule) is constrained.
      6. Reliability is not critical.
      7. System can be split into several independent modules.
      8. The product is aimed at a highly specialized IS (information
        systems) market.
      9. The project has strong micro-schedule constraints (timeboxes).
      10. The required technology is more than a year old.
    2. RAD TENDS TO FAIL WHEN ...
      1. Application must interoperate with existing programs.
      2. Few plug-in components are available.
      3. Optimal performance is required.
      4. Product development can't take advantage of high-end IS tools
        (e.g., 4GLs).
      5. Product distribution will be wide (horizontal or mass market).
      6. RAD becomes QADAD (Quick And Dirty Application Development).
      7. RAD methods are used to build operating systems (reliability
        target too high for RAD), computer games (performance target
        too high for RAD).
      8. Technical risks are high due to use of "bleeding" edge
        technology.
      9. The product is mission- or life-critical.
      10. The system cannot be modularized (defeats parallelism).
  11. Back Top Next
    EVALUATION OF RAD
    1. ADVANTAGES OF RAD
      1. Buying may save money compared to building
      2. Deliverables sometimes easier to port
        (because they make greater use of high-level abstractions,
        scripts, intermediate code)
      3. Development conducted at a higher level of abstraction
        (because RAD tools operate at that level)
      4. Early visibility
        (because of prototyping)
      5. Greater flexibility
        (because developers can redesign almost at will)
      6. Greatly reduced manual coding
        (because of wizards, code generators, code reuse)
      7. Increased user involvement
        (because they are represented on the team at all times)
      8. Possibly fewer defects
        (because CASE tools may generate much of the code)
      9. Possibly reduced cost
        (because time is money, also because of reuse)
      10. Shorter development cycles
        (because development tilts toward schedule and away from
        economy and quality)
      11. Standardized look and feel
        (because APIs and other reusable components give a consistent
        appearance)
    2. DISADVANTAGES
      1. Buying may not save money compared to building
      2. Cost of integrated toolset and hardware to run it
      3. Harder to gauge progress
        (because there are no classic milestones)
      4. Less efficient
        (because code isn't hand crafted)
      5. Loss of scientific precision
        (because no formal methods are used)
      6. May accidentally empower a return to the uncontrolled practices
        of the early days of software development
      7. More defects
        (because of the "code-like-hell" syndrome)
      8. Prototype may not scale up, a B-I-G problem
      9. Reduced features
        (because of timeboxing, software reuse)
      10. Reliance on third-party components may ...
        1. sacrifice needed functionality
        2. add unneeded functionality
        3. create legal problems
      11. Requirements may not converge
        (because the interests of customers and developers may diverge
        from one iteration to the next)
      12. Standardized look and feel (undistinguished, lackluster
        appearance)
      13. Successful efforts difficult to repeat
        (no two projects evolve the same way)
      14. Unwanted features
        (through reuse of existing components)
  12. Back Top Next
    SUMMARY
    From Sun
    "In order to ensure high responsiveness, projects are designed with
    fixed timescales, sacrificing functionality if necessary. This
    allows the development team to focus on the pieces of functionality
    that have the highest business value, and deliver that functionality
    rapidly. Change is often the reason for delays in application
    development. In long linear development processes, changes in
    functionality requirements or project scope, particularly after a lot
    of time has been invested in planning, design, development and
    testing, cause many months to be lost and significant expense to be
    incurred for redesigning and redevelopment. RAD combats scope and
    requirements creep by limiting the project's exposure to change --
    shortening the development cycle and limiting the cost of change by
    incorporating it up-front before large investments are made in
    development and testing."
StudyWeb