Prototyping Elements
Evolutionary Prototyping:
Catapults, whose ancient function as weapon has given way to a modern facilitator in launching fighter jets, has gone through a wide array of variations. These variations were in many ways exemplary of prototypes and prototype methodology. The ancient catapult may very well have been an inadvertent prototype for the launch mechanisms now used by aircraft carriers. Starting from a simple thrower of rocks to a complex airlifting mechanism exemplifies the evolutionary prototyping methodology. Within the limits of software, one may start with a program draft that just barely functions the needs of the end-user to a full-fledged software package containing extraneous features that would have been otherwise costly to add at the project’s close.
Evolutionary prototyping is core to many software development projects as it is a methodology that is seen as being more constructive and less wasteful in generation of the final product. [2] This is based off the evolutionary method building on the same archetype over the course of the same project. [4][14] The evolutionary method has been considered to be imperative in creating either newer products or developments on top of older staples of the company. [4] It gathers information wholly and holistically, allowing for a product to meet the general requirements of the project. [4] In practice, there seems to be a general preference for the evolutionary prototyping method. [14] Of 39 case studies reviewed by V. Gordon and James Bieman, 22 organizations primarily used evolutionary prototyping, whereas 8 organizations used the throwaway method. The remainder of the case studies did not have a preferred method. [3]
The preference for the evolutionary method may be tied with its ability to determine those user requirements that are unknown. Otherwise, it is not a method that is suited for user requirements that are simply ill-defined. [9] In most cases both the user and the developer are mutually confused of what is demanded of the project. [4] Furthermore, it is with its ability to uncover the unknown that determines evolutionary prototyping as a main proponent of software evolution or the continued development and maintenance of a current system. [18] A system developed by the evolutionary method will have documentation and coding that leans towards the further innovation of that system as the organization’s needs for that system changes. [18]
However, the evolutionary technique is more involved and thus more time consuming, requiring more commitment from the company at large. The higher level of involvement can lead to major issues with the product’s final design if quality controls and performance supervision are not in place. [3] Bieman and Gordon’s study further verifies this with a majority of case studies citing more issues with the evolutionary method than the throwaway methodology. [3] The most commonly cited problem with the evolutionary method is the presence of inefficient code still extant within the final product. [9] One example of this situation was a customer advice system built around the evolutionary model. In the middle of the process, the company demoed the product via a demonstrative prototype. The company then built on top of this iteration which ultimately led to numerous redundancies within the system. [16] It also does not serve more specified projects that are concerned with a particular aspect of the software. An alternative yet ultimately complimentary answer is the throwaway prototype methodology.
The evolutionary method is popular with many organizations and yet it is largely problematic. Such issues would otherwise compound with large projects, but its use as a core driver in such projects makes it a key element. It has been shown though, if properly carried out, the evolutionary method is viable within large projects. A study carried out by Sharam Hekmatpour sought to find out if under certain controls the evolutionary technique could be used within a large project. [2] By using an open system architecture and heavy implementation of software tools controlling the documentation process, the evolutionary prototype successfully produced the study’s system which ultimately had a faster than expected processing speed. [2] Upon this study’s findings, it can be noted that the preference for the evolutionary method is not without merit.
Alternatively, the evolutionary method is a practical approach within small projects as well. The fewer resources and lesser complexity involved with such projects, automatically make the evolutionary prototypes viable. The connection between the rapid prototyping technique and small projects, however, render throwaway methods as somewhat more preferable.
Throwaway Prototyping:
Whereas the same archetype is built on over the life-cycle of the project in the evolutionary method, throwaway prototyping simply involves a series of unique iterations focused on a particular aspect of the software. [4] Most commonly, the user requirements is a focus of the throwaway method. [12][4] Within the context of catapults, our user could either be the one firing the catapult or perhaps the one being thrown. Parallel to software development, a program’s final function is usually murky and determining user requirements and design specifications is chaotic. Buskirk and Moroney appropriately notes, “It is far better to hear, ‘That’s not what I wanted,’ when only 5 percent of the coding is done, than after 100 percent of the coding has been completed.” [15] It is generally agreed upon that throwaway prototyping is best suited for validating user requirements that are poorly understood. [14][20][16]
As such, a quick and dirty form of the interface may be created to discover if the user wishes to pull a lever or get vaulted into the nearest lake. After determining the design specifications, the design team would further create more quick iterations of the user interface. These iterations may help test what kind of seating the user may want to have in the catapult or how far they wish to be thrown. In any case, throwaway prototyping allows for more specified testing of software. Indeed, it is often that a company has a mostly complete product that simply needs more elaboration on one of its many parts or the design specifications are the only roadblock in its development. [14]
Throwaway prototyping is also known as exploratory prototyping. Aside from being used to enter undiscovered territory in design specification and user requirements, throwaway prototyping is also a key means of determining project constraints. [20][14] The quick stress-testing of many smaller models, allows a development team to estimate constraints on everything from budget to scheduling before main stages of the project are underway. [20]
It has been argued however that this form of prototyping can add to costs and increase the size of the project. For instance, a bank’s venture into throwaway prototyping resulted in the core systems development team spending anywhere between “75 and 225 hours repeating what had already been done in the prototype” resulting in the projects efforts being between “30 percent and 90 percent redundant.” [11] This may be due to the iterative versus sequential nature of throwaway prototyping.
Much of the redundancy with the throwaway method seems pertinent to vertical prototype testing which covers functional aspects of a system. It is usually in this way that the throwaway method is used within larger projects. Otherwise it has a primary use within small projects in the form of horizontal prototypes testing user requirements. By this means the throwaway technique seems to yield less redundancy and may factor in to why it may be a major element within small projects. [20]
Prototype Orientation:
Beyond the disposability of the prototype, the orientation of its design is also a leading factor in aiding software development teams. The prototype’s functionality versus its front-end interoperability can help solve different issues ranging from specification determination to simply a better understanding of user preferences. Horizontal prototypes typically involve pertinence towards interoperability over function, involving more focus on the user-interface. [15][16] Indeed, some horizontal prototypes are of the “Wizard of Oz” variety comprising of only the illusion of a working system.
They may be slightly more involved consisting of what would be considered a “live” prototype. [19] Such a horizontal prototype would test user interaction on a more immediate basis in coordination with the agile method. [19] An example of this occurred within a case study involving desktop computer company creating a delivery management system. [19] Authors of the study provided an only semi-working system that tested the user-interface. The system worked as a proxy interview process gathering information on user requirements not previously known because the test user was beginning to determine them as they were demoing the system.[19] This exemplifies how horizontal prototyping gains insight of the interface through isolation of that aspect alone.
In contrast, vertical prototypes are highly functional yet usually only involved on a particular subset of the system. [15][16] For instance, a vertical prototype may only be built to test the data flow of the system. Vertical prototypes typically help organizations determine design specifications and other technical aspects of a tested system. [14] Both prototyping methodologies are likely to use either vertical or horizontal orientation.
[17]
Prototype Fidelity:
Another important consideration is the fidelity of the prototype. Prototypes can range from low fidelity, usually composed of paper presentations, to high fidelity models that function much as a final product would. Evolutionary prototypes usually move along the spectrum of fidelity, whereas throwaway prototypes usually consist of a variety of archetypes of differing fidelities. The lower end of the spectrum serves communication in contrast to high fidelity projects serving functional aspects.
Low fidelity is almost synonymous with the aforementioned “Wizard of Oz” approach to prototyping. [10] Akin to the wizard hiding behind a curtain and projecting a false projection of a higher being, a low fidelity prototype may serve as the artifice of a computer system with a “facilitator” working computer like functions in the background. For instance, a project may be testing the user interaction with a system that reacts to hand movements. Rather than an actual system performing the task, someone in the background would control a bare-bones model as it would under the considered functionality whilst reacting to the user’s hand motions. Common to all low fidelity prototypes, this prototype would mainly test user interaction and experience instead of aspects such as functionality. Low fidelity prototypes are also used as part of intra-organizational communication and as a starter prototype for a larger project. [10]
In contrast, high fidelity prototypes are functional systems that closely resemble the final product. [10] As opposed to low fidelity serving communication and observation of user interaction, high fidelity serves functional aspects of development. High fidelity is largely associated with determining design specifications. [10] They are usually either a late version of an evolutionary model which combines elements from either vertical and horizontal orientations or a vertical prototype. The expense associated with high-fidelity grants models of that type a more significant relationship with larger projects. In further connection with large projects, high fidelity has more problems with coding errors and redundancy. [10]
[2] Hekmatpour, S. "Experience with Evolutionary Prototyping in a Large Software Project." ACM SIGSOFT Software Engineering Notes 12.1 (1987): 38-41. Print.
[3] Gordon, V.S., and J.M. Bieman. "Rapid Prototyping: Lessons Learned." IEEE Software 12.1 (1995): 85-95. Print.
[4] Arnowitz, Jonathan, Michael Arent, and Nevin Berger. Effective Prototyping for Software Makers. Amsterdam: Elsevier, 2007. Print.
[9] Davis, Alan M. “Operational Prototyping: A New Development Approach.” IEEE Software (1992): 70-78. Print.
[10] Rudd, Jim, Stern, Ken, Isensee, Scott. “Low vs. High Fidelity Prototyping Debate.” Association for Computing Machinery (1996): 76-85. Print.
[11] Guimaraes, Tor. "Prototyping: orchestrating for success." Datamation 1 Dec. 1987: 101+. Business Insights: Essentials. Web. 18 Oct. 2013.
[12] Granlien, Maren, Pries-Heje, Jan, Baskerville, Richard. “Project Management Strategies for Prototyping Breakdowns.” Proceedings of the 42nd Hawaii International Conference on System Sciences (2009): 1-10. Print.
[14] Budde, R.; Zullighoven, H., "Prototyping revisited," CompEuro '90. Proceedings of the 1990 IEEE International Conference on Computer Systems and Software Engineering , vol., no., pp.418,427, 8-10 May 1990
[15] R. Van Buskirk, and B. W. Moroney. "Extending Prototyping." IBM Systems Journal 42.4 (2003): 613-23. ProQuest. Web.
[16] Kieback, Antoinette, Lichter, Horst, Schneider-Hufschmidt, Matthias, Zullighoven, Heinz. "Prototyping in Industrial Software Projects: Experiences and Assessment." Information Technology & People 6.2,3 (1992): 825-832. Web. 13 Nov. 2013.
[17]
Nielsen, J. (1993) Extract-Chapter 4.8: Prototyping. In Usability Engineering, p.93-101, Academic Press.
[18] Luqi, "Software evolution through rapid prototyping," Computer, vol. 22, no. 5, (1989): 13-25.
[19] Chakraborty, Narayan Ranjan, Subhenur Latif, and Yousuf Mahbubul Islam. "Requirement Elicitation: A "Live" Prototyping Approach." International Journal of Computer Applications 72.13 (2013)ProQuest. Web. 12 Nov. 2013.
[20] Andriole, S.J., "Fast, cheap requirements prototype, or else!" Software, IEEE , vol.11, no.2, pp.85,87, March 1994
doi: 10.1109/52.268964