Introduction
Software development projects differ from development projects in other fields. The main difference lies in the relatively low or inexistent losses experienced when a software project fails to follow a rigid design process.
Unlike a civil engineering project where all the design work must be completed before moving on site, software development projects are flexible enough to allow developers to carry on design and development at the same time. In other words, software engineers can start working on the final version of software as soon as the requirements are clear, without having to make intricate design decisions in advance.
This flexibility is part of the underlying reasons that led to the development of Rapid Application Development (RAD) as a method of software development. Essentially, RAD allowed software engineers to hasten the process of developing a prototype.
The model would then go through several iterations to improve its functionality until it met all the requirements of the key stakeholders. In this sense, the development of software through RAD ensured that a client had a solution as soon as possible. The project closed once the client was happy with the latest iteration of the software.
One of the main concerns that arose from the use of RAD was that the quality of the software produced did not always meet the quality standards for software projects. It was possible to make structural mistakes in the development of the first version of the software that would limit the functionality that could be built into the system later.
This made quality assurance an important component of RAD. This paper seeks to deal with the question of quality in RAD. Are there lessons and practices that organizations can use to ensure that their RAD projects meet the quality criteria set by clients?
Theoretical Framework
RAD was the result of an attempt to improve the productivity of software design teams. The main castigation against RAD was in the quality of work it produced.
It is imperative to examine the theories that relate to quality management in order to determine whether it is possible to use RAD and at the same time to ensure that a project meets the quality criteria set for it. The theories chosen to provide a background for the study are from the field of Total Quality Management (TQM).
Definition of Software Quality
Software quality may be defined by an accepted standard such as ISO 8402-1986, by user satisfaction, or by “errors and unexpected behavior” in the software. When quality is defined by an accepted standard, the definition usually contains the criteria that the software must attain in order to have a certain level of quality.
This kind of definition is important when designing software for a mass market to satisfy aggregated needs of many clients. For instance, it is the best system for defining the quality of an operating system. The second method of defining software relies on a subjective assessment of the quality of software based on customer satisfaction. This applies when the client orders specific software to meet his unique needs.
The third definition uses defects as the basis for defining quality. This compares well with the Six-Sigma quality management system whose focus is the elimination of defects. In this case, few or no defects mean that the software is of high quality.
Deming’s Theory
Deming developed a comprehensive theory used in TQM. This theory consisted of fourteen points of quality management, the system of profound knowledge, and the Shewhart Cycle. The fourteen points were a set of principles that Deming believed were necessary for the achievement of high quality production.
Secondly, the system of profound knowledge had four aspects someone needed to know in order to achieve high quality production. These areas were the knowledge of a company’s systems and processes, the knowledge of the sources of variation from the planned activities, the knowledge of everything there was to know, and the knowledge of human psychology.
The Shewhart Cycle, also known as Deming’s cycle bore a lot of philosophical similarity to RAD. The cycle had four stages known as plan-do-check-act as shown in figure 1 below. The cycle was iterative and therefore very relevant to RAD, which is also an iterative process. It compared well with the lean system of continuous improvement.
However, the lean system includes a stage know as observation, which occurs between “act” and “plan”. In summary, Deming’s theory recognized that high quality products and processes could result from an iterative process, which is also the basic philosophy governing lean manufacturing processes.
Figure 1: The Shewhart Cycle
Crosby’s Theory
Crosby developed a theory premised on four postulates of quality. According to Crosby, the definition of quality is conformance to requirements. This means that a high quality product is as close as possible to the requirements stated by a client.
The second aspect of Crosby’s theory is that “the system of quality is prevention”. This means that the best way to ensure that there is a high quality product at the end of the production process is to prevention the occurrence of faults. This view is contrary to popular usage of appraisals and inspections to guarantee quality.
The weakness associated with the use of appraisals and inspection in quality management is that they occur too late in the process. If the sources of defects were eliminated early in the process, then less wastage would accrue.
In this sense, Crosby’s theory may clash with RAD because RAD adjusts the output after inspection and testing. This means that Crosby’s theory may slow down the RAD process if the software engineers make it their aim to get everything right the first time.
The third aspect of Crosby’s theory is about zero defects. According to Crosby, members of the organization must know exactly what they need to do to eliminate all wastage associated to defects. Crosby insisted that quality is an absolute concept that cannot accommodate the failure to meet requirements.
In this regard, Crosby discouraged the use of standards such as “accepted quality level” among others. This is because such standard give room for production of goods some products with a lower quality level.
The fourth aspect of Crosby’s theory was the use of the price of non-conformance as the price of quality. The first measure associated with this was the price paid by a manufacturer to prevent lapses in compliance to standards.
The second measure was the price paid by the manufacturer when dealing with faulty products that are released into the market when handling repairs, warranties, and shipping. In the RAD process, the two costs are related to the cost of iterations during the preliminary design, or the iterations occurring after the release of each version of the software.
Joseph Juran’s Theory
The third theory of quality of relevance to this paper is Joseph Juran’s theory. Juran’s theory is based on three aspects of quality generally known as Juran’s Trilogy. These three aspects are quality planning, quality control, and quality improvement. Juran believed that quality required planning from the onset.
If a manufacturer wanted to produce high quality products, then the manufacturer needed to ensure that alongside all production goals, the organization also made quality goals for each of its processes.
Quality control meant that the manufacturer needed to institute the systems required to make quality goals during operations. This meant that it was not sufficient for a manufacturer to make goals at the onset, but rather the manufacturer needed to identify quality goals in the process of production.
Quality improvement meant that the manufacturer needed to find new ways of breaking through to new quality levels. This theory fits in RAD very well because RAD stresses continuous quality improvement, and incremental innovation.
Literature Review
Emergence of RAD
RAD emerged in the 1970s as a solution to the need to respond to urgent demands for software. RAD in its first recognizable form as a software development method was used in New York. The telephone company used it to respond to the demand for software. The only way to meet the demands for software at the time was to develop a design system that had a rapid turnaround.
The two main reasons that led to the development of RAD were fast turnaround and flexibility. Software developers noticed that it took too long to develop software using phased methods. Due to long development durations, software developers frequently found that the requirements of the software changed before the release of the first working version.
The other incentive that led to the development of RAD was that the previous software development processes assumed that all the software requirements were known before the design process started. These realizations gave credence to the need for flexible software development systems.
Critical Success Factors for RAD
The three success factors affecting RAD are as follows. First, the successful application of RAD requires the use of effective methods in the process. The main issues that require attention in the development and use of RAD methodologies include selection of the most effective techniques for specific tasks, collection of information using workshops rather than interviews, and the rapid development of prototypes.
The second success factor in the implementation of RAD is people. RAD projects work best when they involve few and highly skilled people. RAD projects requires cooperative effort. RAD is highly dependent on preexisting skills. This means that when choosing a RAD team, the technical experience of each team member is what counts.
The third success factor in the application of the RAD methodology is management. The first time an organization implements RAD, it usually represents radical change. This requires careful application of change management techniques. At the same time, the management of the organization needs to take into account the motivational needs of the RAD team because RAD projects tend to put a lot of pressure on the members.
Phases of RAD
There is general agreement that RAD consists of four main phases. The first phase is requirements planning. This phase requires the management team to define the needs and the project scope in relation to all the key stakeholders. Since RAD works best with seminars rather than interviews, the best method to use in this phase is brainstorming.
The second phase of RAD is user design. It is also known as the user description phase. This phase involves the development of the actual requirements needed to complete the project. The main output of this phase is a working prototype that meets all demonstrates how the software will meet the needs of the clients.
The third stage of RAD is the construction phase. When the client is satisfied that the prototype meets the project requirements, production commences. Finally, the product moves to the cut-over phase. This phase involves the transfer of the product to the user and conducting training on its application.
Dynamic Systems Development Methods (DSDM)
In order to reduce some of the limitations of RAD, the Dynamic Systems Development Methods (DSDM) came into existence in 1995. The main issue that DSDM wanted to resolve was the quality problems associated with software developed using RAD techniques. The principles of DSDM are as follows. First, DSDM encourages user involvement at every stage of the software design process.
Secondly, the DSDM team must have the power to make decision regarding the design process, and thirdly, the process needs to deliver products frequently. The fourth principle guiding DSDM is that the acceptance criterion for all the products is “fitness for purpose”.
Finally, DSDM incorporates testing in the design process. These five principles seem to agree with lean manufacturing, which requires conformity to high standards in the entire production process. DSDM achieves quality improvement by increasing the testing requirements in the process of prototyping.
Essentially, it ensures that all the design sections meet high quality criteria during production. A criticism against DSDM is that it can increase the time required to produce a prototype because it introduces several testing phases within very small work packages.
Personal Software Process (PSP)
Another methodology developed to resolve the quality concerns associated with RAD is the Personal Software Process (PSP). However, PSP focuses on the software developer. Its role is to give the software developer an opportunity to increase his skill level. PSP works when software developers increase their skills, which in turn leads to an improvement in the quality of the work they produce.
RAD depends on the skills of the developers involved in a specified project. In this sense, when a software company uses PSP to ensure that their developers are improving their skills, the company increases its capacity to developer high quality software using RAD.
Advantages of RAD and Limitations of RAD
The main advantages of RAD are as follows. First RAD makes it possible to involve the client from the onset. This ensures that needs of the client are met. It also provides the designers with an opportunity to get feedback from the client on an ongoing basis. This is invaluable in the process of software development. Secondly, RAD reduces the time needed to design software.
This reduction in cycle time leads to a reduction in the cost of the project. RAD achieves the reduction in software development time by reusing design components. Essentially, RAD is a modular design system that borrows heavily from the experience and expertise of software developers.
The third benefit of RAD is that early prototyping makes it possible to detect mistakes early in the design process. This reduces time and resource wastage spent in correcting mistakes.
The disadvantages or RAD includes the following. First, RAD requires highly skilled professionals for it to work. An organization that wants to employ RAD as a software development technique must invest in high caliber staff.
This can lead to an increase in costs associated with software development. Secondly, quality concerns arise from the use of RAD. The pace of RAD projects makes it difficult to control quality. In many cases, RAD cannot produce very high quality software because there is not time to carry out studies, comparisons, and specific improvement initiatives.
The third disadvantage of RAD is that it often leads to the development of software products that are difficult to maintain. In addition, software developed by RAD tends to lack scalability. This disadvantage can be a strategic disadvantage. RAD is very focused on present needs to the extent that it is very difficult to make strategic considerations during its deployment.
Findings
The main findings from the literature review are as follows. First, RAD requires a definite set of conditions to work. Every organization that wants to use RAD as a software development process must ensure that it creates the conditions necessary for the successful application of the software development process. These conditions include having highly skilled staff in software design.
The members of staff should also be trained in the application of RAD. The organization needs to be very realistic about the quality criteria it should use for the project. Definitions of quality that border on perfection such as the one proposed by Janis can only lead to frustration for the design team. If the organization fails to provide the essential success factors governing the application of RAD, it will not achieve its intended goals.
Based on Crosby’s theory, multiple iterations in RAD can be costly. An important finding that the literature showed was that having many iterations in the design process could become very costly for the organization. According to Crosby’s theory, it is necessary to achieve high standards of uniformity in production in order to be sure that the resultant product meets the quality criteria.
In this regard, Crosby recommends the use of multiple iterations in software design to ensure that the organization achieves the highest quality standards. However, Cosby warns that the iterations must not exceed what is necessary for the attainment of the highest quality standards. In this regard, Crosby advocates for the achievement of high standards as fast as possible.
Starting with highest attainable level of quality is important for RAD. The quality of RAD projects can benefit from planning if the software developers include planning for quality as one of the preliminary designs.
Using Juran’s trilogy, the improvement of quality in RAD projects call for planning for quality. In this sense, Juran was convinced that a RAD project could increase the quality of the product by planning for quality in the early stages.
Quality can be increased by use of DSDM and PSP. The literature reviewed also showed that it is possible to increase the quality of a software product by using DSDM and PSP. The use of DSDM improves software quality by the creation of certain rules that can make it possible for developers to infuse quality management in the software design process.
These stages include involvement of the client in the design process, empowering the RAD team to make decisions, and increasing the number of points where the design team needs to deliver product components. In this sense, DSDM is a set of guidelines that can help an organization to use RAD effectively.
The fifth finding, based on the literature reviewed is that there is a cost and quality tradeoff whenever RAD is used. While RAD can deliver results depending on the needs of the client, it has no system of evaluating the quality of the product in reference to the long-term needs of a client.
In this sense, RAD cannot produce goods that are of good quality because of the rapidity of the process. The tradeoff is between the quality of the product and the price.
Views on the Topic
My views in regards to RAD were too gracious. There is no doubt that RAD is a very innovative approach to software development, and that it has enabled many organizations to carry out projects in remarkable time. My original views of the method were based on high expectations in relation to what an organization can achieve by using RAD.
The reasons why I held these views is that many materials that speak about the method look at it as a high yield approach to software development. This is true as far as quality is not a major concern. After reviewing literature in detail in this project, I now feel that RAD is indeed an important approach to software development, but it is not flawless.
It is clear that quality control is a problem when it comes to RAD. The speed with which RAD proceeds makes it vulnerable to quality lapses. This is the reason theoreticians have developed methods like DSDM and PSP to address the quality shortfalls.
My current view of RAD is that it should be applied only if the organization possesses the critical success factors associated with RAD. This means that if an organization lacks the people to handle RAD projects, or is weak in project management, is should not rush to use RAD. It is first important for the organization to determine whether it has the capacity to handle RAD before attempting to use it as a software development method.
Conclusions
The main conclusions arising from this project are as follows. First, RAD is a useful approach to software development. This comes from the shortcomings of some of the current software design approaches.
In many cases, companies need software solutions prepared quickly to enable them to take advantage of emerging opportunities or to solve certain business problems. Based on this, it is clear that RAD has a place as a software design process, because the model is the only way to resolve some business problems.
The second conclusion from this project is that RAD requires a set of conditions for success. Any organization that lacks these conditions cannot implement RAD successfully.
The conditions include presence of a skilled human resource pool, availability of proper RAD methods applicable in the organization, and the rapid development of prototypes. If an organization lacks these basic conditions, RAD cannot succeed in that organization.
The third conclusion from this project is that RAD as a method has problems relating to quality. The development of software using this method takes place in an environment full of pressure. While the method embraces ideas such as the use of several iterations during prototyping, it is impossible to eliminate all the defects from the system. In this regard, RAD may lead to the creation of a new set of problems.
It is possible to increase the quality of products developed using RAD. The two main methods that came up in the literature review were DSDM and PSP. DSDM tries to infuse quality control in the design process.
It breaks down the total work into small units that allow the developers to run tests and fix problems in the software. PSP on the other hand gives the software developers the opportunity to use RAD projects to develop their skill by learning from previous projects.
Recommendations
In view of all the issues raised in the project, the recommendations offered to any organization planning to use RAD are as follows.
Recognize that the commencement of the use of RAD constitutes change. When adopting RAD as the organizational standard for the development of software projects, it is imperative to present this move as change. Allowing all the people involved to look at RAD, as a change process will make it easier for them to transit.
Pick the initial team carefully. It is very important to pick the original RAD team for your organization very carefully. The experience of the first team will play a significant role in the development of morale for future teams. The first team will also develop the culture that will surround future RAD projects
Appoint teams that have both new and experienced developers. An organization should strive to have teams that include both new and experienced developers. The need to include new developers is to ensure that all developers in the organization learn how to use RAD. This will insure the future of the organization in this area.
Finally, balance speed with quality and cost. Every organization that chooses to use RAD must take care to fulfill the demands of the clients. In this sense, the organization will need to balance the speed of production with the quality and cost of production. RAD is the best way for an organization to develop software quickly. However, the tradeoff between cost and quality can determine whether it is a good approach to RAD.
Reference List
Arson, EW & Gray, CF 2011, Project Management: The Managerial Process, , McGraw Hill International, New York, NY.
Button, K 2010, Transport Economics, Edward Elgar Publishing, Cheltenham, UK.
Case Maker 2000, What is Rapid Application Development”. Web.
Coleman, G & Verbruggen, R 1998, ‘A Quality Software Process for Rapid Application Development’, Software Quality Journal , vol 7, pp. 107-122.
Cullen, J 2011, Multinational Management: A Strategic Approach, 5th edn, Cengage Learning, Mason, OH.
Dalic, T 2007, Globalisation of Marketing Strategies in Light of Segmentation and Cultural Diversity, GRIN Verlag, Norderstedt.
Daughtry, TC & Casselman, GL 2009, Executing Strategy: From Boardroom to Frontline, Capital Books, Herndon, VI.
Davis, FD 1989, ‘Percieved Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology’, MIS Quaterly, vol 13, no. 3, pp. 318-340.
Dixon, DR 1999, ‘The Behavioral Side of Information Technology’, International Journal of Medical Informatics, vol 56, no. 10, pp. 117-123.
Epicor 2011, ‘Talent Management in the Coming Decade: How HRIS can Help’, Workforce Management, 2011, p. 42.
Flannes, S & Levin, G 2005, Essential People Skills for Project Managers, Management Concepts, Vienna, VA.
Gaile-Sarkane, E 2009, ‘Impact of Technology Adoption on Consumer Behavior’, Economics and Management, vol 14, pp. 381-387.
Haddon, L 2004, Information and Communication Technologies in Everyday Life: A Concise Introduction and Research Guide, Berg, New York, NY.
Hill, C & Jones, GR 2009, Strategic Management: An Integrated Approach : Theory, Cengage Learning, Mason OH.
Holmes, D 2005, Communication Theory: Media, Technology, and Society, SAGE, London, UK.
Jeffrey, M & Norton, JF 2006, ‘MCDM, Inc. (A) IT Strategy Sychronization’, Kellog School of Management, pp. 1-9.
Jeyarathmm, M 2008, Strategic Management , Global Media, Mumbai, India.
Jørgensen, M 1999, ‘Software Quality Measurement’, Advances in Engineering Software, vol 30, pp. 907-912.
Kazmi, A 2008, Strategic Managenent and Business Policy, Tata McGraw-Hill, New Delhi.
Kerzner, H 2009, Project Management: A Systems Approach to Planning, Scheduling and Controlling, 10th edn, John Wiley and Sons, Hoboken, NJ.
Kopezak, L & Lee, H 1994, ‘Coordinated Product and Supply Chain Design’, Case Study, pp. 331-404.
Kutsch, E & Hall, M 2010, ‘Deliberate Ignorance in Project Risk Management’, International Journal of Project Management, vol 28, no. 3, pp. 145-155.
Lewis, R, Donaldson-Feilder, E & Tharani, T 2012, ‘Managing for Sustainable Employee Engagement: Developing a Behavioural Framework’, Affinity, vol 2012, no. 1, pp. 1-20.
Lozo, G & Jovanović, S 2012, ‘A Flexible Hybrid Method for IT Project Management’, Journal of Emerging Trends in Computing and Information Sciences, vol 2, no. 7, pp. 1027-1036.
Mahadevan, P 2009, Operations Management: Theory & Practice, Pearson Education India, New Delhi.
Mukherjee, PN 2006, Total Quality Management, PHI Learning Pvt. Ltd, New Delhi.
Phillips, J 2010, IT Project Management, McGraw Hill Professional, New York.
Piderit, SK 2000, ‘Rethinking Resistance and Recognizing Ambivalence: A Multidimensional View of Attitudes Toward an Organizational Change’, Academy of Management Review, vol 25, no. 4, pp. 783-794.
Pratali, P 2003, ‘Strategic Management of Technological Innovations in the Small to Medium Enterprise’, European Journal of Innovation Management, 6(1), pp. 18-31.
RSFH 2010, ‘Quality Improvement Initiatives: Reducing Emergency Room Wait Times’, The Consult, 2010, pp. 3-7.
Sabharwal, S 2008, Software Engineering, New Age International, New Delhi.
Selby, RW 2007, Software Engineering: Barry W. Boehm’s Lifetime Contributions to Software Development, Management, and Research, John Wiley and Sons, New York.
Shelly, GB & Rosenblatt, HJ 2011, Systems Analysis and Design, Cengage Learning, New York, NY.
Sims, RR & Sims, SJ 1995, The Importance of Learning Styles: Understanding the Implications for Learning, Course Design, and Education, Greenwood Publishing Group, Westport, CT.
Stair, RM & Reynolds, GW 2011, Principles of Information Systems, Cengage Learning, New York, NY.
Therin, F 2002, ‘Organizational Learning and Innovation in High-Tech Small Firms’, Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03), IEEE Computer Society, Hawaii.
Weichmann, D 2009, The Impact of Online Music Services on the Music Recording Industry: Opportunities and Challenges, GRIN Verlag, Berlin.
Young, ST 2009, Essentials of Operations Management, Sage Publications Inc, London.
Zell, D 2003, ‘Organizational Change as a Process of Death, Dying, and Rebirth’, Journal of Applied Behavioral Science, vol 39, no. 1, pp. 73-99.
Zokaei, KA, Lovins, HL, Wood, A & Hines, P 2013, Creating a Lean and Green Business System: Techniques for Improving Profits and Sustainability, Productivity Press, Parkway NW.