Comparing RAD to the SDLC
In Figure 6.5 you can compare the phases of the SDLC with those detailed for RAD at the beginning of this section. Notice that the ultimate purpose of RAD is to shorten the SDLC and in this way respond more rapidly to dynamic information requirements of organizations. The SDLC takes amore methodical, systematic approach that ensures completeness and accuracy and has as its intention the creation of systems that are well integrated into standard business procedures and culture
In Figure 6.5 you can compare the phases of the SDLC with those detailed for RAD at the beginning of this section. Notice that the ultimate purpose of RAD is to shorten the SDLC and in this way respond more rapidly to dynamic information requirements of organizations. The SDLC takes amore methodical, systematic approach that ensures completeness and accuracy and has as its intention the creation of systems that are well integrated into standard business procedures and culture
 |
| In Figure 6.5 |
The RAD design workshop phase is a departure from the standard SDLC design phases, because RAD software tools are used to generate screens and to exhibit the overall flow of the running of the application. Thus, when users approve this design, they are signing off on a visual model representation, not just a conceptual design represented on paper, as is traditionally the case. The implementation phase of RAD is in many ways less stressful than others, because the users have helped to design the business aspects of the system and are well aware of what changes will take place. There are few surprises, and the change is something that is welcomed. Often when using the SDLC, there is a lengthy time during development and design when analysts are separated from users. During this period, requirements can change and users can be caught off guard if the final product is different than anticipated over many months.
WHEN TO USE RAD. As an analyst, you want to learn as many approaches and tools as possible to facilitate getting your work done in the most appropriate way. Certain applications and systems work will call forth certain methodologies. Consider using RAD when:
1. Your team includes programmers and analysts who are experienced with it; and
2. There are pressing business reasons for speeding up a portion of an application development; or
3. When you are working with a novel ecommerce application and your development team believes that the business can sufficiently benefit over their competitors from being an innovator if this application is among the first to appear on the Web; or
4. When users are sophisticated and highly engaged with the organizational goals of the company.
DISADVANTAGES OF RAD. The difficulties with RAD, as with other types of prototyping, arise because systems analysts try to hurry the project too much. Suppose two carpenters are hired to build two storage sheds for two neighbors. The first carpenter follows the SDLC philosophy, whereas the second follows the RAD philosophy. The first carpenter is systematic, inventorying every tool, lawn mower, and piece of patio furniture to determine the correct size for the shed, designing a blueprint of the shed, and writing specifications for every piece of lumber and hardware. The carpenter builds the shed with little waste and has precise documentation about how the shed was built if anyone wants to build another just like it, repair it, or paint it using the same color. The second carpenter jumps right into the project by estimating the size of the shed, getting a truckload of lumber and hardware, building a frame and discussing it with the owner of the property as modifications are made when certain materials are not available, and making a trip to return the lumber not used. The shed gets built faster, but if a blueprint is not drawn, the
documentation never exists.
WHEN TO USE RAD. As an analyst, you want to learn as many approaches and tools as possible to facilitate getting your work done in the most appropriate way. Certain applications and systems work will call forth certain methodologies. Consider using RAD when:
1. Your team includes programmers and analysts who are experienced with it; and
2. There are pressing business reasons for speeding up a portion of an application development; or
3. When you are working with a novel ecommerce application and your development team believes that the business can sufficiently benefit over their competitors from being an innovator if this application is among the first to appear on the Web; or
4. When users are sophisticated and highly engaged with the organizational goals of the company.
DISADVANTAGES OF RAD. The difficulties with RAD, as with other types of prototyping, arise because systems analysts try to hurry the project too much. Suppose two carpenters are hired to build two storage sheds for two neighbors. The first carpenter follows the SDLC philosophy, whereas the second follows the RAD philosophy. The first carpenter is systematic, inventorying every tool, lawn mower, and piece of patio furniture to determine the correct size for the shed, designing a blueprint of the shed, and writing specifications for every piece of lumber and hardware. The carpenter builds the shed with little waste and has precise documentation about how the shed was built if anyone wants to build another just like it, repair it, or paint it using the same color. The second carpenter jumps right into the project by estimating the size of the shed, getting a truckload of lumber and hardware, building a frame and discussing it with the owner of the property as modifications are made when certain materials are not available, and making a trip to return the lumber not used. The shed gets built faster, but if a blueprint is not drawn, the
documentation never exists.
No comments:
Post a Comment