Content deleted Content added
Rescuing 1 sources and tagging 0 as dead.) #IABot (v2.0.9.5 |
|||
| (558 intermediate revisions by more than 100 users not shown) | |||
Line 1:
{{Short description|Concept of software development}}
{{Redirect2|RAD tool|Rapid Application Development Tool|development focused on making graphical user interfaces|graphical user interface builder}}
{{Use dmy dates|date=June 2020}}
{{Software development process}}
'''Rapid application development''' ('''RAD'''), also called '''rapid application building''' ('''RAB'''), is both a general term for [[adaptive software development]] approaches, and the name for [[James Martin (author)|James
RAD is especially well suited for (although not limited to) developing [[software]] that is driven by [[user interface]] [[software requirements|requirements]]. [[Graphical user interface builder]]s are often called rapid application development tools. Other approaches to rapid development include the [[Adaptive software development|adaptive]], [[Agile software development|agile]], [[spiral model|spiral]], and [[Unified Process|unified]] models.
== History ==
Rapid application development was a response to plan-driven [[Waterfall model|waterfall]] processes, developed in the 1970s and 1980s, such as the [[Structured Systems Analysis and Design Method]] (SSADM). One of the problems with these methods is that they were based on a traditional engineering model used to design and build things like bridges and buildings. Software is an inherently different kind of artifact. Software can radically change the entire process used to solve a problem. As a result, knowledge gained from the development process itself can feed back to the requirements and design of the solution.<ref>{{cite book|last=Brooks|first=Fred|title=No Silver Bullet Essence and Accidents of Software Engineering|editor1-last=Kugler|editor1-first=H.J.|series=Information Processing '86|date=1986|publisher=Elsevier Science Publishers B.V (North-Holland)|isbn=0-444-70077-3|url=http://www.sci.brooklyn.cuny.edu/~sklar/teaching/s10/cis20.2/papers/brooks-no-silver-bullet.pdf|access-date=2 July 2014}}</ref> Plan-driven approaches attempt to rigidly define the requirements, the solution, and the plan to implement it, and have a process that discourages changes. RAD approaches, on the other hand, recognize that software development is a knowledge intensive process and provide flexible processes that help take advantage of knowledge gained during the project to improve or adapt the solution.
The first such RAD alternative was developed by [[Barry Boehm]] and was known as the [[spiral model]]. Boehm and other subsequent RAD approaches emphasized developing prototypes as well as or instead of rigorous design specifications. Prototypes had several advantages over traditional specifications:
* Risk reduction. A prototype could test some of the most difficult potential parts of the system early on in the [[software lifecycle|life-cycle]]. This can provide valuable information as to the feasibility of a design and can prevent the team from pursuing solutions that turn out to be too complex or time-consuming to implement. This benefit of finding problems earlier in the life-cycle rather than later was a key benefit of the RAD approach. The earlier a problem can be found the cheaper it is to address.
* Users are better at using and reacting than at creating specifications. In the waterfall model it was common for a user to sign off on a set of requirements but then when presented with an implemented system to suddenly realize that a given design lacked some critical features or was too complex. In general most users give much more useful feedback when they can experience a prototype of the running system rather than abstractly define what that system should be.
* Prototypes can be usable and can evolve into the completed product. One approach used in some RAD methods was to build the system as a series of prototypes that evolve from minimal functionality to moderately useful to the final completed system. The advantage of this besides the two advantages above was that the users could get useful business functionality much earlier in the process.<ref name="dimap.ufrn.br">{{cite journal|last1=Boehm|first1=Barry|title=A Spiral Model of Software Development|journal=IEEE Computer|date=May 1988|url=http://www.dimap.ufrn.br/~jair/ES/artigos/SpiralModelBoehm.pdf|access-date=1 July 2014|doi=10.1109/2.59|s2cid=1781829|archive-url=https://web.archive.org/web/20180329032706/http://www.dimap.ufrn.br/~jair/ES/artigos/SpiralModelBoehm.pdf|archive-date=29 March 2018}}</ref>
Starting with the ideas of [[Barry Boehm]] and others, [[James Martin (author)|James Martin]] developed the rapid application development approach during the 1980s at [[IBM]] and finally formalized it by publishing a book in 1991, ''Rapid Application Development''. This has resulted in some confusion over the term RAD even among IT professionals. It is important to distinguish between RAD as a general alternative to the waterfall model and RAD as the specific method created by Martin. The Martin method was tailored toward knowledge intensive and UI intensive business systems.
These ideas were further developed and improved upon by RAD pioneers like James Kerr and Richard Hunter, who together wrote the seminal book on the subject, Inside RAD,<ref>Kerr, James M.; Hunter, Richard (1993). Inside RAD: How to Build a Fully Functional System in 90 Days or Less. McGraw-Hill. {{ISBN|0-07-034223-7}}.</ref> which followed the journey of a RAD project manager as he drove and refined the RAD Methodology in real-time on an actual RAD project. These practitioners, and those like them, helped RAD gain popularity as an alternative to traditional systems project life cycle approaches.
The RAD approach also matured during the period of peak interest in [[business process re-engineering|business re-engineering]]. The idea of business process re-engineering was to radically rethink core business processes such as sales and customer support with the new capabilities of Information Technology in mind. RAD was often an essential part of larger business re engineering programs. The rapid prototyping approach of RAD was a key tool to help users and analysts "think out of the box" about innovative ways that technology might radically reinvent a core business process.<ref>{{cite book|last1=Drucker|first1=Peter|title=Post-Capitalist Society|date=3 November 2009|publisher=Harper Collins e-books|isbn=978-0887306204|url=https://archive.org/details/postcapitalistso00druc}}</ref><ref>{{cite book|last1=Martin|first1=James|title=Rapid Application Development|date=1991|publisher=Macmillan|isbn=0-02-376775-8|url=https://archive.org/details/rapidapplication00mart}}</ref>
Much of James Martin's comfort with RAD stemmed from [[DuPont (1802–2017)|Dupont]]'s Information Engineering division and its leader Scott Schultz and their respective relationships with John Underwood who headed up a bespoke RAD development company that pioneered many successful RAD projects in Australia and Hong Kong.
Successful projects that included [[ANZ Bank]], [[Lend Lease]], [[BHP]], [[Coca-Cola]] Amatil, [[Alcan]], [[Hong Kong Jockey Club]] and numerous others.
Success that led to both Scott Shultz and James Martin both spending time in Australia with John Underwood to understand the methods and details of why Australia was disproportionately successful in implementing significant mission critical RAD projects.
==James Martin approach==
[[File:RADModel.JPG|320px|thumb|right|Phases in the James Martin approach to RAD]]
The James Martin approach to RAD divides the process into four distinct phases:
# '''Requirements planning phase''' – combines elements of the system planning and systems analysis phases of the [[systems development life cycle]] (SDLC). Users, managers, and IT staff members discuss and agree on [[Business requirements|business needs]], [[Scope (project management)|project scope]], constraints, and system requirements. It ends when the team agrees on the key issues and obtains management authorization to continue.
# '''User design phase''' – during this phase, users interact with [[Systems analyst|systems analysts]] and develop [[Model|models]] and [[Prototype|prototypes]] that represent all system processes, [[Input (computer science)|inputs]], and [[Output (computing)|outputs]]. The RAD groups or subgroups typically use a combination of [[joint application design]] (JAD) techniques and [[CASE tools]] to translate user needs into working models. ''User design'' is a continuous interactive process that allows users to understand, modify, and eventually approve a working model of the system that meets their needs.
# '''Construction phase''' – focuses on program and application development task similar to the SDLC. In RAD, however, users continue to participate and can still suggest changes or improvements as actual screens or reports are developed. Its tasks are programming and application development, [[Computer programming|coding]], [[System integration|unit-integration]] and [[system testing]].
# '''Cutover phase''' – resembles the final tasks in the SDLC implementation phase, including data conversion, testing, changeover to the new system, and user training. Compared with traditional methods, the entire process is compressed. As a result, the new system is built, delivered, and placed in operation much sooner.<ref>{{cite book|last1=Martin|first1=James|title=Rapid Application Development|date=1991|publisher=Macmillan|isbn=0-02-376775-8|pages=[https://archive.org/details/rapidapplication00mart/page/81 81–90]|url=https://archive.org/details/rapidapplication00mart/page/81}}</ref>
== Advantages ==
In modern Information Technology environments, many systems are now built using some degree of Rapid Application Development<ref>{{cite web|url=http://www.gartner.com.br/tecnologias_empresariais/pdfs/brl37l_a3.pdf|title=The Disintegration of AD: Putting it Back Together Again|publisher=gartner.com.br|access-date=2010-04-13|archive-date=14 July 2014|archive-url=https://web.archive.org/web/20140714222107/http://www.gartner.com.br/tecnologias_empresariais/pdfs/brl37l_a3.pdf|url-status=dead}}</ref> (not necessarily the James Martin approach). In addition to Martin's method, [[agile methods]] and the [[Rational Unified Process]] are often used for RAD development.
The purported advantages of RAD include:
* Better quality. By having users interact with evolving prototypes the business functionality from a RAD project can often be much higher than that achieved via a waterfall model. The software can be more [[Usability|usable]] and has a better chance to focus on business problems that are critical to end users rather than technical problems of interest to developers. However, this excludes other categories of what are usually known as [[Non-functional requirement]]s (AKA constraints or quality attributes) including [[Computer security|security]] and [[Porting|portability]].
* Risk control. Although much of the literature on RAD focuses on speed and user involvement a critical feature of RAD done correctly is risk mitigation. It's worth remembering that Boehm initially characterized the spiral model as a risk based approach. A RAD approach can focus in early on the key risk factors and adjust to them based on empirical evidence collected in the early part of the process. E.g., the complexity of prototyping some of the most complex parts of the system.
* More projects completed on time and within budget. By focusing on the development of incremental units the chances for catastrophic failures that have dogged large waterfall projects is reduced. In the Waterfall model it was common to come to a realization after six months or more of analysis and development that required a radical rethinking of the entire system. With RAD this kind of information can be discovered and acted upon earlier in the process.<ref name="dimap.ufrn.br"/><ref>{{cite book|last1=Beck|first1=Kent|title=Extreme Programming Explained|date=2000|publisher=Addison Wesley|isbn=0201616416|pages=[https://archive.org/details/extremeprogrammi00beck/page/3 3–7]|url=https://archive.org/details/extremeprogrammi00beck/page/3}}</ref>
== Disadvantages ==
The purported disadvantages of RAD include:
* The risk of a new approach. For most IT shops RAD was a new approach that required experienced professionals to rethink the way they worked. Humans are virtually always averse to change and any project undertaken with new tools or methods will be more likely to fail the first time simply due to the requirement for the team to learn.
*Lack of emphasis on [[Non-functional requirement]]s, which are often not visible to the end user in normal operation.
* Requires time of scarce resources. One thing virtually all approaches to RAD have in common is that there is much more interaction throughout the entire life-cycle between users and developers. In the waterfall model, users would define requirements and then mostly go away as developers created the system. In RAD users are involved from the beginning and through virtually the entire project. This requires that the business is willing to invest the time of application ___domain experts. The paradox is that the better the expert, the more they are familiar with their ___domain, the more they are required to actually run the business and it may be difficult to convince their supervisors to invest their time. Without such commitments RAD projects will not succeed.
* Less control. One of the advantages of RAD is that it provides a flexible adaptable process. The ideal is to be able to adapt quickly to both problems and opportunities. There is an inevitable trade-off between flexibility and control, more of one means less of the other. If a project (e.g. [[Life-critical system|life-critical software]]) values control more than agility RAD is not appropriate.
* Poor design. The focus on prototypes can be taken too far in some cases resulting in a "hack and test" methodology where developers are constantly making minor changes to individual components and ignoring system architecture issues that could result in a better overall design. This can especially be an issue for methodologies such as Martin's that focus so heavily on the user interface of the system.<ref name="PratImp">{{cite conference
| citeseerx = 10.1.1.100.645
| title = Practical Implications of Rapid Development Methodologies
| first1 = Aurona
| last1 = Gerber
| first2 = Alta
| last2 = Van Der Merwe
| first3 = Ronell
| last3 = Alberts
| date = 16–18 November 2007
| conference = Computer Science and IT Education Conference
| conference-url = http://csited.org/
| book-title = Proceedings of the Computer Science and Information technology Education Conference, CSITEd-2007
| ___location = Mauritius
| pages = 233–245
| isbn = 978-99903-87-47-6
}}</ref>
* Lack of scalability. RAD typically focuses on small to medium-sized project teams. The other issues cited above (less design and control) present special challenges when using a RAD approach for very large scale systems.<ref name="SpecsOnLine">{{cite book
|last = Andrew Begel
|first = Nachiappan Nagappan
|title = First International Symposium on Empirical Software Engineering and Measurement (ESEM 2007)
|chapter = Usage and Perceptions of Agile Software Development in an Industrial Context: An Exploratory Study
|chapter-url=http://research.microsoft.com/pubs/56015/AgileDevatMS-ESEM07.pdf
|date=September 2007
|pages = 255–264
|doi = 10.1109/esem.2007.12
|isbn = 978-0-7695-2886-1
|s2cid = 1941370
}}</ref><ref name="RAD2">{{cite book|doi=10.1109/icse.2003.1201238|chapter=Assessing test-driven development at IBM|title=25th International Conference on Software Engineering, 2003. Proceedings|pages=564–569|year=2003|last1=Maximilien|first1=E.M.|last2=Williams|first2=L.|isbn=0-7695-1877-X|s2cid=16919353}}</ref><ref name="RAD3">{{cite book|doi=10.1007/978-1-4302-0810-5|title=Extreme Programming Refactored: The Case Against XP|year=2003|last1=Stephens|first1=Matt|last2=Rosenberg|first2=Doug|isbn=978-1-59059-096-6|s2cid=29042153|url-access=registration|url=https://archive.org/details/extremeprogrammi00matt}}</ref>
==See also==
Practical concepts to implement RAD:
* [[Graphical user interface builder]], where main software tools for RAD are represented
* [[Fourth-generation programming language]], e.g. [[FileMaker]], [[4th Dimension (software)|4th Dimension]], [[dBase]] and [[Visual FoxPro]]
Other similar concepts:
* [[Flow-based programming]]
* [[Lean software development]]
* [[Platform as a service]]
* [[
* [[No-code development platform]]
== References ==
{{
== Further reading ==
* [[
* {{cite book |last1=Kerr |first1=James M. |last2=Hunter |first2=Richard |year=1993 |title=Inside RAD: How to Build a Fully Functional System in 90 Days or Less |publisher=McGraw-Hill |isbn=0-07-034223-7}}
* Ellen Gottesdiener (1995). "[http://ebgconsulting.com/Pubs/Articles/RAD_Realities_Beyond_the_Hype_Gottesdiener.pdf RAD Realities: Beyond the Hype to How RAD Really Works]" Application Development Trends
* [[
* [[
* Dean Leffingwell (2007). ''Scaling Software Agility: Best Practices for Large Enterprises'', Addison-Wesley Professional, {{ISBN|978-0-321-45819-3}}
*Scott Stiner (2016). Forbes List: "Rapid Application Development (RAD): A Smart, Quick And Valuable Process For Software Developers"
{{Software
{{Computer science}}
[[Category:Software project management]]
[[Category:Software development process]]
[[Category:Programming tools]]
| |||