SMALL PROJECTS:
Despite the heavy engagement that is usually tied with prototyping, all forms of archetypes serve as a substantial factor in small projects. Indeed, the prototyping process in itself renders a conservative work-flow wherein less coding and man-hours are involved. A study involving multiple student groups, consisting of 2-3 people for each group, sought to compare the effectiveness of prototyping as compared to specification. [1] One of the cardinal observations in the study was the difference in product size and effort between the prototyping and specifying groups. [1]
In spite of being tasked with the same software development goals, the prototyping groups engineered products that averaged 40 percent smaller than their specifying counterparts with an average 45 percent less effort and the same performance levels. [1] The difference in effort translated as 325 average person-hours among the prototyping groups to the average 584 person-hours generated by the specifying groups. [1] The prototyping groups also spent slightly less programming effort, 30 percent against the specification groups 37 percent effort used towards programming. [1] The prototyping groups achieved this conservative work-flow in spite of the fact that they primarily used the otherwise more work-intensive evolutionary method. Prototypes among the groups were between 40-60 percent of the final product’s size. [1]
While the study manages to exemplify the feasibility as well as the benefits of prototyping in smaller projects, there were drawbacks observed. The reduced design and development led to proportionally more testing and fixing of the product. [1] As well, the prototyping groups’ products had more difficult interface integration via less coherent design and lack of interface specifications. The authors of the study suggested these problems would only get worse as a project increased in size. [1] This suggestion leans on the already inherent truth that larger projects are more prone to failure. Parallel to this truth is the aspect that problems associated with prototyping could get worse as project size increases. [8][22] However, prototyping has the potential to alleviate rather than exacerbate issues with larger projects. From an contrary perspective, smaller projects involve less risk during the execution of prototyping due to a less-ingrained need for documentation and control management brought on by the use of fewer resources within a modular setting.
Unlike the inclusiveness of large projects, small projects will focus primarily on one type of methodology type over the course of its life-span. Even as evolutionary prototyping serves as a viable option within smaller projects, the tendency is for smaller projects to implement the throwaway methodology. Throwaway prototyping, which has been heavily linked with rapid prototyping, is inherent to quick and cheap model design. [20] It is typical that smaller projects would have the tendency to employ “quick and dirty” archetypes that serve express demands. [20] The commonality of these throwaways is of the horizontal and low-fidelity variety. Vice versa within large projects, throwaway methodology would typically lean towards vertical prototypes of higher fidelity, usually as a complement to an evolutionary prototype.
That isn’t to say that throwaway prototypes are not used in a vertical and functional manner within smaller projects. As per the independent video gaming industry, such prototypes are important to small design teams. For instance, a primary method of the independent “indie” gaming industry is to create numerous functional but one-off games that work towards a final product. [6] The code isn’t kept but the ideas build on top of each other. The development of ideas is a given within an industry that depends even more heavily on creativity. Iterative expendable prototypes help achieve that and more within the confines of a small project. Indie game “World of Goo” was made by one person in less than a week, after employing such a prototyping method. The game hit the milestone of 100,000 units sold within months of its release. [6]
Jonathan Blow, an indie developer who has implemented a mix of horizontal and vertical throwaways, evokes this cognitive development. Speaking of his prototype ‘Oracle Billiards,’ which served as the precedent to his successful game “Braid,” he quoted, “It didn’t do what I wanted, but I got a feeling out of it that I never got out of any game I ever played before.” [5][7] That feeling in itself served as the progenitor to the critically-acclaimed and financially successful “Braid.” [5] The general aspect of success through failure in prototyping is fully exemplified through the throwaway method, and that aspect has larger meaning within small software development projects. ‘Oracle Billiards’ was a vertical prototype of higher fidelity that tested functionality in one area. Despite being thrown into oblivion, that one prototype helped to inspire the core part of Blow’s breakout game. [5][7]
The synthesis between small project prototyping and failure lends to the tendency of low-fidelity and orientation variability within smaller projects. Basically there is more of a focus on the number of the iterations rather than the quality of the iterations a la the concept of rapid prototyping. The smaller budget and fewer developers are more likely to lean on these quick, cheap prototypes that consist of either a vertical or horizontal orientation.
LARGE PROJECTS:
Prototyping is an essential if not underutilized tool within large software development projects. Unlike small software development projects there is a somewhat more intrinsic need for prototyping within larger endeavors. Whereas small software projects are more likely to employ a larger proportion of one prototyping method, large projects more consistently use a combination of prototyping methods over the course of a product’s development. [9] A large project may see small, low-fidelity models of both a vertical and horizontal nature used as disposable templates early on, then transition to work on an extensive evolutionary prototype accompanied by more throwaway archetypes albeit of higher fidelity.
The implementation of prototypes in large projects carries advantages in determining user requirements and better understanding new technology specifications, but also has the potential to back-fire if not properly executed as per warnings from issues discovered in small project prototyping. [22] This back-fire potential elaborates the large gap in risks in prototyping between small and large projects. By extension, technical proficiency among developers and heavy engagement by project management is a must when prototyping in large projects. [2] If not for these prerequisites, the project would encounter significant testing and maintenance costs with an otherwise unstable system. Advantages typical of prototyping might be absent and the overall project may be submitted towards complete failure. [22]
However, if these prerequisites are met, a lot of risk and uncertainty common to large projects in general can be avoided. [3] With proper management of the prototyping process, non-prototyping issues common of large projects can be avoided. This is tied to the element of user requirement definition and product complexity usually being more difficult as the project size increases. [8][22] These are two elements that are primarily tackled by the prototyping process. [8] A project carried out by the Budget Analysis Division of the Congressional Budget Office helped remedy previous problems they had with their database management system with a properly managed prototyping process. [13] Where traditional development means failed, a modular prototyping approach succeeded in helping the design team handle an otherwise large project. [13]
The higher level of maintenance serves to explain why large projects typically lean on more than one type of prototyping technique. [9] Main complications typically occur with evolutionary prototyping. [3] As such most large projects will implement throwaway prototyping intermittently of both vertical and horizontal orientations. In regard to user requirements determination, Stephen Andriole recommends using both methods as filters. Initially the throwaway methodology would be used to refine preset requirements, and then the evolutionary method is used to find unknown requirements that would be added on. [20] Going a step further, some large projects are now beginning to implement operational prototyping which layers a series of planned disposable prototypes over top an evolutionary baseline. In other words, it’s a more deliberate combination of prototyping techniques.
While there are a few examples, its innovative nature has left it largely under used. One example of operational prototyping was the Prototype Ocean Surveillance Terminal (POST) developed by BTG, Inc. for the U.S. Navy. [9] Faced with the unique challenge of creating a system that would process raw identification and location data from half a dozen sites, BTG initially implemented a series of throwaway prototypes. As they encountered instability with the prototypes as well as issues processing them at numerous sites, the need arose for a central evolutionary prototype. [9]
They then converged the various prototypes into a successful prototype of “operational” design. It would go on to precede a productive system that served the US Navy during the 1990 Gulf War. [9] Key to the system’s success was the evolutionary prototype not only serving as a progenitor to the actual system but also a crux to the throwaway prototypes used in the software development. An example of an evolutionary prototype working as a baseline was also reported by an engineer of a large manufacturing firm to have overlapped requirements, design, and coding tasks which greatly increased productivity. [3] While operational prototyping is a non-officiated concept not widely in use, it does provide context to the almost necessary inclusiveness of prototyping methods within larger projects. [9]
This inclusiveness also overlaps large project development’s use of both vertical and horizontal prototypes. The functionality of prototype orientation is practically ubiquitous as it serves as one of the few factors linking small and large software development projects. One slight difference in orientation is that large projects are more likely to have vertical and horizontal prototypes of higher fidelity. [10]
From a perspective of fidelity, large projects seem more likely to transition from low to high fidelity over the course of the project. This aspect runs parallel to typical development of evolutionary prototype systems. Throwaway prototypes used within larger projects will also be of higher fidelity as they explore key components of more complex products. That isn’t to say that low-fidelity prototypes will not have a common role in large projects as they are cheap and essential tools in user interaction.
Another element that differentiates large projects from small projects, is the bigger role of communication found within the former. While a prototype’s capacity to benefit communication in a project is unique from its size, the very need for that capacity has a more primary role within large projects. The increased complexity of the product to be designed and the increased number of personnel usually associated with large projects presents a situation of weaker communication that isn’t as readily handled by traditional design methods.
The ability of a prototype to work as a communication conduit can not only help serve as a focal point for other elements within the project but also help varying teams involved better communicate. [15][16] The prototypes ability to speak visually helps to accomplish these different levels of communication. In small projects there is already considerable focus with the smaller work parameters and personnel. As such there is a weaker need for prototyping as a communication tool in small projects.
Exemplary to prototyping as a communication tool in large projects is the software development for the IBM Infoprint 4100 printer, which involved a multidisciplinary team consisting of developers, usability engineers, customer support personnel, testers, and graphic artists. [15] Not only did the prototype allow for these various groups to coordinate with each other effectively, but also handle turnover in the design team. [15] Issues faced by this turnover, which capitulated prior to the documentation stage of the software development, were averted when the new developers were able to quickly educate themselves via the prototype and carry out the necessary documentation. [15] The prototype of the Infoprint 4100 also allowed for easier communication between the personnel of different nationalities via the visual representation. [15]
[1] Boehm, Barry W., Terence E. Gray, and Thomas Seewaldt. "Prototyping Versus Specifying: A Multiproject Experiment." IEEE Transactions on Software Engineering SE-10.3 (1984): 290-303. Print.
[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.
[5] Carless, Simon. "GDC: Prototyping for Indie Developers." Gamasutra. UBM Technology, 6 Mar. 2007. Web. 15 Oct. 2013. <http://www.gamasutra.com/view/news/103968/GDC_Prototyping_for_Indie_Developers.php>.
[6] Gray, Kyle, and Kyle Gabler. "How to Prototype a Game in Under 7 Days." Gamasutra. UBM Technology, 26 Oct. 2005. Web. 17 Oct. 2013. <http://www.gamasutra.com/view/feature/2438/how_to_prototype_a_game_in_under_7_.php>.
[7] "Jonathan Blow." Giant Bomb. CBS Interactive Inc., n.d. Web. 03 Nov. 2013. <http://www.giantbomb.com/jonathan-blow/3040-89596/>.
[8] Hardgrave, Bill C., Rick L. Wilson, and Ken Eastman. "Toward a Contingency Model for Selecting an Information System Prototyping Strategy." Journal of Management Information Systems 16.2 (1999): 113-36. ProQuest. Web. 14 Nov. 2013.
[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.
[13] Jenkins, C. Wesley. “Application Prototyping: A Case Study.” ACM Sigmetrics Performance Evaluation Review. 10.1 (1981): 21-27. Print.
[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.
[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
[22] Stephens, M.; Bates, P., "Controlling prototyping and evolutionary development," Rapid System Prototyping, (1993): 164-185. doi: 10.1109/IWRSP.1993.263184