White Paper - RAD and Web application methodologies
Ken McCormackSenior Consultant, Palmer 21st Century Media
Introduction
Various academic commentators have noted the apparent lack of a consistent methodology within the Web industry. Coda et al. (1988) noted that “Web site development is usually carried out without following well defined processes”. Lowe (1999) surmised that “Web development is currently in a similar state to that which software development was in 30 years ago.” Only recently have systematic approaches to Web development begun to appear.
There are several reasons for this apparent lack of methodology: commentators are quick to note that the Web industry lacks maturity and that design methods and technology are still evolving. Several recent papers have proposed new methodologies based upon RAD principles (Marquis, 2002; Standing, 2002; Lowe, 1999).
Standing (2002, p. 159) notes that “There is a perception that both the academic and practitioner worlds are in a post-methodology era. This has resulted in the disillusionment with traditional information systems development methodologies.”
However, just as the application of RAD techniques within conventional IS projects give rise to a myriad of mix-and-match methodologies (Cerpa & Verner, 1996; Hardgrave, 1995), the apparent disarray of Web methodologies mean that many commentators fail to identify an almost universal adoption of prototyping and RAD techniques by the Web industry.
This White Paper discusses RAD prototyping techniques, and details the advantages and disadvantages of using this approach as a method of developing Web based systems.
RAD and the traditional SDLC
RAD and prototyping was first proposed by Martin (1991), as an alternative to the traditional SDLC model established in the 1960s. The inherent nature of the SDLC is that it is linear in nature, with each phase having specific outcomes and deliverables that feed important information to successive steps (Hoffer et al., 1999).
The SDLC, developed before the emergence of 4GLs, CASE tools and RDMS, presents a cascaded or ‘waterfall' series of steps, whereby in order to progress it is necessary to sign off on a given phase before moving on. The deliverables produced at each of these milestones include considerable amounts of detailed functional documentation and specification. For this reason, once a milestone has been passed, it is was not feasible to return to an earlier stages to allow for changed circumstances or user requirements.
RAD as an alternative to the SDLC
A central weakness of the SDLC is that the user is unable to present feedback until the project is complete. RAD adopts a collaborative approach, whereby the prototype is used to serve as the functional description of user needs.
The fundamental principal of RAD is to remove fixed milestones from the project by delaying the production of detailed system design documentation and deliverables until user requirements are fully clear. This is done using prototyping: “a small scale version of a complex system in order to acquire critical knowledge required to build a system” (Szekely,1994).
Continual redevelopment and/or evolution of the prototype by the user and the developer means that the project is able to quickly converge upon a more realistic, tangible representation of user needs and requirements, and respond more easily to orders for change.
The ability to treat user requirements as a fluid, dynamic entity means that RAD development is well suited to Web application design, where user needs and commercial environment are often considerably more volatile than met in conventional IS design. Martin (1991) described the aim of RAD as “meeting the true business (or user) requirements as effectively as possible at the time the system comes into operation”.
Evolutionary and throw away prototyping
Crinnion (1992) stated that there are now two forms of prototyping. These are ‘ throw-away', where interfaces are built, evaluated and thrown away ( to be re-programmed in a more efficient environment or programming language), and ‘ evolutionary', where the model is evaluated and refined as part of an iterative or evolutionary process. The prototype ultimately converges into a project deliverable.
This iterative development process, first posited by Boehm (1998), involves the developer and user collaborating on a continual cycle of planning, design, build, testing and feedback.
Fig 1. – Iterative design process (Boehm, 1998). Development through each phase – prototype, Beta and final. |
|
Advantages of RAD in Web application design
Traditionally accepted advantages of RAD include:
- Fast development of core system capabilities
- The ability to identify and repair problems early
Set against the backdrop of the commercial Web industry, these factors can be critical in the success of a project. A frozen specifications list quickly becomes outdated.
- Stronger communication (Cerpa & Verner, 1996)
- Users are empowered, feeding business requirements to development
- Reduced risk, as developers and users monitor tangible progress
- Improved working relationship and trust between developers and clients
The above factors ensure a strong client relationship, as well as a greater likelihood of gaining high levels of acceptance for the system design whole (Hoffer et al, p.32), with user requirements being met to a far higher degree than possible within a SDLC framework.
Traditional factors influencing the choice of RAD
Studies have shown that where the foundations of the traditional SDLC are not present, then this strengthens the case for choosing RAD development (Cerpa & Verner, 1996.)
A clear set of requirements are not available
Lowe (1999) has noted that we still do not fully understand what constitutes an effective Website; there is as yet no universally agreed set of Web quality characteristics. For this reason prototyping is an essential part of Web application design, as it also facilitates a means for user centred design and testing – see ‘The client is not the user', below.
High requirements volatility
The Web is a dynamic medium, and one weakness of the SDLC is its lack of change control. Within the SDLC the cost of fixing errors in previous stages increases exponentially – Boehm, (1981). This is possibly the reason that the conventional SDLC has never been favoured in the Web development industry.
Cost or longer development processes inapplicable
A Web application or e-commerce site typically has a lifecycle of only a few years, therefore long development processes and high budget spends are inappropriate. F ollowing the dot com crash of the early 90's, these are unlikely to be sanctioned.
Weaknesses of the RAD approach
Bourne (1994) identified several weaknesses of the prototyping approach, such as inconsistencies between system models, non-compliance with standards and the lack of reusability of system components.
There are some pitfalls, however, in relation to management. The cyclic, iterative process can mean it is difficult to achieve timely sign-off on important aspects of the project. This can lead to problems in estimation and resource planning, and may also lead to contractual difficulties. Underlined is the importance for an appropriate contractual framework.
A further weakness is that prototyping is extremely user-centric. Project timespan can be increased greatly if client commitment is not forthcoming throughout the entire cycle.
One further important issue is documentation. Without effective provision for delivery of documentation, subsequent maintenance of the system may be more problematic. There is a real risk in RAD that developers are too hard pressed to meet documentary requirements.
Problems unique to Web application design: the client is not the user
A central aim of RAD methodology is to improve the communication between the development team and the user , thereby ensuring that the final product meets user requirements more closely (Martin, 1991). In e-commerce design, however, the end user is not the client, but a distant customer connected via the Internet. A central weakness of requirements analysis via prototyping is therefore that the client must often put themselves in the shoes of the end user. User centred design is a specialist area and the client does not usually have the requisite knowledge to make an effective decision, but will instead act to define requirements tuned to their own subjective needs and opinions.
The impact of modern programming languages, RDMS and CMS systems
The weaknesses traditionally associated with prototyping concern lack of code reusability, non-compliance with standards and inconsistencies between systems models. However, many of these problems arose because of the deficiencies of CASE tools and languages.
It is arguable that, due to the improved power of modern tools such as 4GL's and RDMS's, within a Web application scenario it is now rare that throw-away prototyping is a necessary part of development work. The development of higher performance systems and languages (such the .NET framework) means that performance critical modules can be developed alongside interpreted code.
The recent dominance of RDMS and CMS systems has also meant that much of the raw coding overhead has been removed from Web development, with the current trend being that larger companies are no longer developing within a custom application framework. The backbone of many projects is a CMS deployment (rather than a development) scenario.
|
|
|
|
Case studies - prototyping scenarios
Parallel prototyping
A project is currently being undertaken to build Web-based analysis, testing and reporting systems for a consulting company who provide personality profiling and emotional intelligence testing for blue chip clients. The interaction within the application are complex, incorporating both administrative workflow and testing features, with a variety of levels of user.
Following initial requirements analysis, deployment was to take place within a CMS scenario. Several types of prototype were used alongside one another:
- Visual prototyping - mock-up of creative design in flat image form;
- Paper prototyping – initial design of administrative and user interface forms, developed in collaboration with the client;
- HTML prototyping – non-functional layout of forms and user interface components using HTML.
Paper-based prototypes are mocked up, derived also from the visual prototype. Evolutionary changes are then made to the HTML prototype by the client printing a hard copy from the browser.
Semi-functional prototype – a functional version of each form was then developed directly from the HTML prototype. Back end coding was restricted to CMS deployment, with front-end deployment involving client-side JavaScript coding to fine tune form operation.
The main advantages of using prototypes within this project were that exact user requirements were uncertain, and given the complex nature of the system, it was impossible to pre-define the fine detail of all functionality. The result was a fully featured application that was a perfect fit for user requirements.
Evolutionary prototyping
A recent project was undertaken using prototyping for the production of mobile phone handset emulator/tutorials. The project involved the production of many detailed scenarios incorporating multimedia content. The timescale of the project was also short.
Evolutionary prototyping formed a key aspect of the project, both in terms of user-developer communication, bug tracking and contractual deliverables.
Design - In terms of design and look and feel, the use of a flat image prototype allowed the client to incrementally tailor their specification.
Look and feel - The prototype design was also converted into a functional prototype, building the ‘look and feel'. Prototype development was carried out by the use of a powerful DHTML e-Learning tool, which was also used for the final builds.
Early identification of problems - Prototypes were fundamental in identifying build problems early. For example, emulator scenarios were to be delivered across several platforms and mediums, including the Web, intranet and CD-ROM. Thorough testing on initial prototypes revealed several issues, which where eradicated by making changes to the authoring environment.
Communication - In order to manage the evolution of the prototyping project, all changes took place within a formal communication framework, issues being logged via an intranet-based communication medium. This presents a formal audit trail and issue tracking, supported by detailed written documentation regarding prototype testing.
Prototypes and large organizations - The use of a prototype lends itself well as a communication medium where large teams or organizations are involved. A Web-based prototype can be studied by a far larger sector of the client company, and also comprehended by senior management, not merely those directly involved with the project. For this reason, the use of prototyping lends itself to large team scenarios, where otherwise communication might be a problem.
Conclusion
Commentators have suggested that the underlying reason for the lack of application methodology is that the Web development community in general is not yet sufficiently mature to recognise what makes a truly effective development method (Lowe, 1999; Standing, 2002; Marquis, 2002).
However, a general thread of methodology has long been evident, and this has a very strong basis in RAD, with prototyping techniques used at many stages of the development cycle. Furthermore, the usage of 4GL programming languages mean that Web teams are fully conversant with traditional RAD methods and tools. Re-coding is very rare.
The trend towards deployment of larger Web applications within product-based CMS systems means that there is a further blurring of the distinction between prototype and the final application. In common with methodologies such as proposed by Standing (2002, p.156), the system we deploy and develop must be subject to such constant evolution that it is difficult to see where the prototype ends and the system begins.
Use of prototyping methodologies can motivate clients and lead to excellent results. Communication can be markedly improved, and incremental delivery can lead to a more streamlined, manageable workflow for both client and developer.
RAD us fundamentally suited to the lifecycle of Web application design, and with careful management to overcome traditional weaknesses such as the production of documentation and reliance upon the client to drive the project forwards, the negotiation of an effective project framework is all that is needed for these need not be an issue.
References
Marquis, G.P. 2002, Application of traditional system design techniques to Web site design , Information and Software Technology, 44 (2002) 507-512.
Standing, C. 2002, Methodologies for developing Web Applications , Information and Software Technology 44 (2002) 151-159.
Strauss, R., Hogan, H. 2001, Developing Effective Websites: A Project Manager's Guide , Focal Press, Boston .
Blom, R.E. 2000, Survey of prototyping and RAD tools ,
<http://www.cs.vu.nl/~mmc/mci/content_pages/opdrachtvoorbeelden/R.BLOM/paper.html>
Hoffer, J.A., George, J.F., Valacich, J.S. 1999, Modern Systems Analysis and Design, 2 nd Ed., Aiddison Wesley, Reading MA.
Lowe, D. 1999, Web Development Methodologies: Help or Hindrance? , WebNet Journal, July-Sept 1999 <http://www.aace.org/pubs/Webnet/v1no3/lowe1_3.pdf>
F. Coda, G. Carlo, G. Vigna, G. Franca 1998, Towards a software approach to Web site development , Proceedings of the Ninth International Workshop on Software Specification and Design, IEEE.
Cerpa N., Verner J. 1996, Prototyping: some new results , Information and Software Technology. Vol. 38, December 1996.
Hardgrave B.C., 1995, When to Prototype: decision variables used in industry , Information and Software Technology, 37(2) 113-118.
P. Szekely, 1994, User Interface Prototyping: Tools and Techniques , USC / Information Sciences Institute.
Crinnion J. 1992, Exploitation of the 4GL , Software Development ‘92-Management Track. Blenheim Online, London .
Martin J. 1991, Rapid Application Development, Macmillan Publishing, New York .
Palvia P., Nosek J.T. 1990, An Empirical Evaluation of System Development Methodologies, Information Resources Management Journal Vol. 3. Summer 1990
Boehm, B.W. 1981, Software Engineering Economics , Prentice Hall, Englewood Cliffs, NJ.
