SDLC - Prototyping, RAD Development
Trying to figure out what we use at Brown. I would definitely say that it's RAD. For us, "scope creep" does become a challenge at times.
RAPID APPLICATION DEVELOPMENT (RAD) / PROTOTYPING LIFECYCLE
RAD is, in essence, the “try before you buy” approach to software development. The theory is that end users can produce better feedback when examining a live system, as opposed to working strictly with documentation. RAD-based development cycles have resulted in a lower level of rejection when the application is placed into production, but this success most often comes at the expense of a dramatic overruns in project costs and schedule. The RAD approach was made possible with significant advances in software development environments to allow rapid generation and change of screens and other user interface features. The end user is allowed to work with the screens online, as if in a production environment. This leaves little to the imagination, and a significant number of errors are caught using this process.
The down side to RAD is the propensity of the end user to force scope creep into the development effort. Since it seems so easy for the developer to produce the basic screen, it must be just as easy to add a widget or two. In most RAD lifecycle failures, the end users and developers were caught in an unending cycle of enhancements, with the users asking for more and more and the developers trying
to satisfy them. The participants lost sight of the goal of producing a basic, useful system in favor of the siren song of glittering perfection.
RAPID APPLICATION DEVELOPMENT (RAD) / PROTOTYPING LIFECYCLE
RAD is, in essence, the “try before you buy” approach to software development. The theory is that end users can produce better feedback when examining a live system, as opposed to working strictly with documentation. RAD-based development cycles have resulted in a lower level of rejection when the application is placed into production, but this success most often comes at the expense of a dramatic overruns in project costs and schedule. The RAD approach was made possible with significant advances in software development environments to allow rapid generation and change of screens and other user interface features. The end user is allowed to work with the screens online, as if in a production environment. This leaves little to the imagination, and a significant number of errors are caught using this process.
The down side to RAD is the propensity of the end user to force scope creep into the development effort. Since it seems so easy for the developer to produce the basic screen, it must be just as easy to add a widget or two. In most RAD lifecycle failures, the end users and developers were caught in an unending cycle of enhancements, with the users asking for more and more and the developers trying
to satisfy them. The participants lost sight of the goal of producing a basic, useful system in favor of the siren song of glittering perfection.


Comments