software prototyping for other uses see prototypebased programming software development core activities processes requirements design engineering construction testing debugging deployment maintenance paradigms and models agile cleanroom incremental prototyping spiral v model waterfall methodologies and frameworks asd devops dad dsdm fdd iid kanban lean sd less mdd msf psp rad rup safe scrum semat tsp up xp supporting disciplines configuration management documentation software quality assurance sqa project management user experience practices atdd bdd cco ci cd ddd pp standup tdd tools compiler debugger profiler gui designer modeling ide build automation release automation infrastructure as code testing standards and bodies of knowledge babok cmmi ieee standards iso 9001 isoiec standards pmbok swebok itil glossaries artificial intelligence computer science electrical and electronics engineering vte software prototyping is the activity of creating prototypes of software applications ie incomplete versions of the software program being developed it is an activity that can occur in software development and is comparable to prototyping as known from other fields such as mechanical engineering or manufacturing a prototype typically simulates only a few aspects of and may be completely different from the final product prototyping has several benefits the software designer and implementer can get valuable feedback from the users early in the project the client and the contractor can compare if the software made matches the software specification according to which the software program is built it also allows the software engineer some insight into the accuracy of initial project estimates and whether the deadlines and milestones proposed can be successfully met the degree of completeness and the techniques used in prototyping have been in development and debate since its proposal in the early 1970s overview the purpose of a prototype is to allow users of the software to evaluate developers proposals for the design of the eventual product by actually trying them out rather than having to interpret and evaluate the design based on descriptions software prototyping provides an understanding of the softwares functions and potential threats or issues interaction design in particular makes heavy use of prototyping with that goal this process is in contrast with the 1960s and 1970s monolithic development cycle of building the entire program first and then working out any inconsistencies between design and implementation which led to higher software costs and poor estimates of time and cost the monolithic approach has been dubbed the slaying the software dragon technique since it assumes that the software designer and developer is a single hero who has to slay the entire dragon alone prototyping can also avoid the great expense and difficulty of having to change a finished software product the practice of prototyping is one of the points frederick p brooks makes in his 1975 book the mythical manmonth and his 10year anniversary article no silver bullet an early example of largescale software prototyping was the implementation of nyus adaed translator for the ada programming language outline of the prototyping process the process of prototyping involves the following steps identify basic requirements determine basic requirements including the input and output information desired details such as security can typically be ignored develop initial prototype the initial prototype is developed that includes only user interfaces see horizontal prototype below review the customers including endusers examine the prototype and provide feedback on potential additions or changes revise and enhance the prototype using the feedback both the specifications and the prototype can be improved negotiation about what is within the scope of the contractproduct may be necessary if changes are introduced then a repeat of steps 3 and 4 may be needed dimensions of prototypes nielsen summarizes the various dimensions of prototypes in his book usability engineering horizontal prototype a common term for a user interface prototype is the horizontal prototype it provides a broad view of an entire system or subsystem focusing on user interaction more than lowlevel system functionality such as database access horizontal prototypes are useful for confirmation of user interface requirements and system scope demonstration version of the system to obtain buyin from the business develop preliminary estimates of development time cost and effort vertical prototype a vertical prototype is an enhanced complete elaboration of a single subsystem or function it is useful for obtaining detailed requirements for a given function with the following benefits refinement database design obtain information on data volumes and system interface needs for network sizing and performance engineering clarify complex requirements by drilling down to actual system functionality types of prototyping software prototyping has many variants however all of the methods are in some way based on two major forms of prototyping throwaway prototyping and evolutionary prototyping throwaway prototyping also called closeended prototyping throwaway or rapid prototyping refers to the creation of a model that will eventually be discarded rather than becoming part of the final delivered software after preliminary requirements gathering is accomplished a simple working model of the system is constructed to visually show the users what their requirements may look like when they are implemented into a finished system it is also a rapid prototyping rapid prototyping involves creating a working model of various parts of the system at a very early stage after a relatively short investigation the method used in building it is usually quite informal the most important factor being the speed with which the model is provided the model then becomes the starting point from which users can reexamine their expectations and clarify their requirements when this goal has been achieved the prototype model is thrown away and the system is formally developed based on the identified requirements the most obvious reason for using throwaway prototyping is that it can be done quickly if the users can get quick feedback on their requirements they may be able to refine them early in the development of the software making changes early in the development lifecycle is extremely cost effective since there is nothing at that point to redo if a project is changed after a considerable amount of work has been done then small changes could require large efforts to implement since software systems have many dependencies speed is crucial in implementing a throwaway prototype since with a limited budget of time and money little can be expended on a prototype that will be discarded another strength of throwaway prototyping is its ability to construct interfaces that the users can test the user interface is what the user sees as the system and by seeing it in front of them it is much easier to grasp how the system will function it is asserted that revolutionary rapid prototyping is a more effective manner in which to deal with user requirementsrelated issues and therefore a greater enhancement to software productivity overall requirements can be identified simulated and tested far more quickly and cheaply when issues of evolvability maintainability and software structure are ignored this in turn leads to the accurate specification of requirements and the subsequent construction of a valid and usable system from the users perspective via conventional software development models prototypes can be classified according to the fidelity with which they resemble the actual product in terms of appearance interaction and timing one method of creating a low fidelity throwaway prototype is paper prototyping the prototype is implemented using paper and pencil and thus mimics the function of the actual product but does not look at all like it another method to easily build high fidelity throwaway prototypes is to use a gui builder and create a click dummy a prototype that looks like the goal system but does not provide any functionality the usage of storyboards animatics or drawings is not exactly the same as throwaway prototyping but certainly falls within the same family these are nonfunctional implementations but show how the system will look summary in this approach the prototype is constructed with the idea that it will be discarded and the final system will be built from scratch the steps in this approach are write preliminary requirements design the prototype user experiencesuses the prototype specifies new requirements repeat if necessary write the final requirements evolutionary prototyping evolutionary prototyping also known as breadboard prototyping is quite different from throwaway prototyping the main goal when using evolutionary prototyping is to build a very robust prototype in a structured manner and constantly refine it the reason for this approach is that the evolutionary prototype when built forms the heart of the new system and the improvements and further requirements will then be built when developing a system using evolutionary prototyping the system is continually refined and rebuilt evolutionary prototyping acknowledges that we do not understand all the requirements and builds only those that are well understood this technique allows the development team to add features or make changes that couldnt be conceived during the requirements and design phase for a system to be useful it must evolve through use in its intended operational environment a product is never done it is always maturing as the usage environment changeswe often try to define a system using our most familiar frame of referencewhere we are now we make assumptions about the way business will be conducted and the technology base on which the business will be implemented a plan is enacted to develop the capability and sooner or later something resembling the envisioned system is delivered evolutionary prototypes have an advantage over throwaway prototypes in that they are functional systems although they may not have all the features the users have planned they may be used on an interim basis until the final system is delivered it is not unusual within a prototyping environment for the user to put an initial prototype to practical use while waiting for a more developed versionthe user may decide that a flawed system is better than no system at all in evolutionary prototyping developers can focus themselves to develop parts of the system that they understand instead of working on developing a whole system to minimize risk the developer does not implement poorly understood features the partial system is sent to customer sites as users work with the system they detect opportunities for new features and give requests for these features to developers developers then take these enhancement requests along with their own and use sound configurationmanagement practices to change the softwarerequirements specification update the design recode and retest incremental prototyping the final product is built as separate prototypes at the end the separate prototypes are merged in an overall design by the help of incremental prototyping the time gap between user and software developer is reduced extreme prototyping extreme prototyping as a development process is used especially for developing web applications basically it breaks down web development into three phases each one based on the preceding one the first phase is a static prototype that consists mainly of html pages in the second phase the screens are programmed and fully functional using a simulated services layer in the third phase the services are implemented the process is called extreme prototyping to draw attention to the second phase of the process where a fully functional ui is developed with very little regard to the services other than their contract advantages of prototyping there are many advantages to using prototyping in software development some tangible some abstract reduced time and costs prototyping can improve the quality of requirements and specifications provided to developers because changes cost exponentially more to implement as they are detected later in development the early determination of what the user really wants can result in faster and less expensive software improved and increased user involvement prototyping requires user involvement and allows them to see and interact with a prototype allowing them to provide better and more complete feedback and specifications the presence of the prototype being examined by the user prevents many misunderstandings and miscommunications that occur when each side believe the other understands what they said since users know the problem domain better than anyone on the development team does increased interaction can result in a final product that has greater tangible and intangible quality the final product is more likely to satisfy the users desire for look feel and performance disadvantages of prototyping using or perhaps misusing prototyping can also have disadvantages insufficient analysis the focus on a limited prototype can distract developers from properly analyzing the complete project this can lead to overlooking better solutions preparation of incomplete specifications or the conversion of limited prototypes into poorly engineered final projects that are hard to maintain further since a prototype is limited in functionality it may not scale well if the prototype is used as the basis of a final deliverable which may not be noticed if developers are too focused on building a prototype as a model user confusion of prototype and finished system users can begin to think that a prototype intended to be thrown away is actually a final system that merely needs to be finished or polished they are for example often unaware of the effort needed to add errorchecking and security features which a prototype may not have this can lead them to expect the prototype to accurately model the performance of the final system when this is not the intent of the developers users can also become attached to features that were included in a prototype for consideration and then removed from the specification for a final system if users are able to require all proposed features be included in the final system this can lead to conflict developer misunderstanding of user objectives developers may assume that users share their objectives eg to deliver core functionality on time and within budget without understanding wider commercial issues for example user representatives attending enterprise software eg peoplesoft events may have seen demonstrations of transaction auditing where changes are logged and displayed in a difference grid view without being told that this feature demands additional coding and often requires more hardware to handle extra database accesses users might believe they can demand auditing on every field whereas developers might think this is feature creep because they have made assumptions about the extent of user requirements if the developer has committed delivery before the user requirements were reviewed developers are between a rock and a hard place particularly if user management derives some advantage from their failure to implement requirements developer attachment to prototype developers can also become attached to prototypes they have spent a great deal of effort producing this can lead to problems such as attempting to convert a limited prototype into a final system when it does not have an appropriate underlying architecture this may suggest that throwaway prototyping rather than evolutionary prototyping should be used excessive development time of the prototype a key property to prototyping is the fact that it is supposed to be done quickly if the developers lose sight of this fact they very well may try to develop a prototype that is too complex when the prototype is thrown away the precisely developed requirements that it provides may not yield a sufficient increase in productivity to make up for the time spent developing the prototype users can become stuck in debates over details of the prototype holding up the development team and delaying the final product expense of implementing prototyping the start up costs for building a development team focused on prototyping may be high many companies have development methodologies in place and changing them can mean retraining retooling or both many companies tend to just begin prototyping without bothering to retrain their workers as much as they should a common problem with adopting prototyping technology is high expectations for productivity with insufficient effort behind the learning curve in addition to training for the use of a prototyping technique there is an often overlooked need for developing corporate and project specific underlying structure to support the technology when this underlying structure is omitted lower productivity can often result best projects to use prototyping it has been argued that prototyping in some form or another should be used all the time however prototyping is most beneficial in systems that will have many interactions with the users it has been found that prototyping is very effective in the analysis and design of online systems especially for transaction processing where the use of screen dialogs is much more in evidence the greater the interaction between the computer and the user the greater the benefit is that can be obtained from building a quick system and letting the user play with it systems with little user interaction such as batch processing or systems that mostly do calculations benefit little from prototyping sometimes the coding needed to perform the system functions may be too intensive and the potential gains that prototyping could provide are too small prototyping is especially good for designing good humancomputer interfaces one of the most productive uses of rapid prototyping to date has been as a tool for iterative user requirements engineering and humancomputer interface design dynamic systems development method dynamic systems development method dsdm is a framework for delivering business solutions that relies heavily upon prototyping as a core technique and is itself iso 9001 approved it expands upon most understood definitions of a prototype according to dsdm the prototype may be a diagram a business process or even a system placed into production dsdm prototypes are intended to be incremental evolving from simple forms into more comprehensive ones dsdm prototypes can sometimes be throwaway or evolutionary evolutionary prototypes may be evolved horizontally breadth then depth or vertically each section is built in detail with additional iterations detailing subsequent sections evolutionary prototypes can eventually evolve into final systems the four categories of prototypes as recommended by dsdm are business prototypes used to design and demonstrates the business processes being automated usability prototypes used to define refine and demonstrate user interface design usability accessibility look and feel performance and capacity prototypes used to define demonstrate and predict how systems will perform under peak loads as well as to demonstrate and evaluate other nonfunctional aspects of the system transaction rates data storage volume response time etc capabilitytechnique prototypes used to develop demonstrate and evaluate a design approach or concept the dsdm lifecycle of a prototype is to identify prototype agree to a plan create the prototype review the prototype operational prototyping operational prototyping was proposed by alan davis as a way to integrate throwaway and evolutionary prototyping with conventional system development it offers the best of both the quickanddirty and conventionaldevelopment worlds in a sensible manner designers develop only wellunderstood features in building the evolutionary baseline while using throwaway prototyping to experiment with the poorly understood features davis belief is that to try to retrofit quality onto a rapid prototype is not the correct method when trying to combine the two approaches his idea is to engage in an evolutionary prototyping methodology and rapidly prototype the features of the system after each evolution the specific methodology follows these steps an evolutionary prototype is constructed and made into a baseline using conventional development strategies specifying and implementing only the requirements that are well understood copies of the baseline are sent to multiple customer sites along with a trained prototyper at each site the prototyper watches the user at the system whenever the user encounters a problem or thinks of a new feature or requirement the prototyper logs it this frees the user from having to record the problem and allows him to continue working after the user session is over the prototyper constructs a throwaway prototype on top of the baseline system the user now uses the new system and evaluates if the new changes arent effective the prototyper removes them if the user likes the changes the prototyper writes featureenhancement requests and forwards them to the development team the development team with the change requests in hand from all the sites then produce a new evolutionary prototype using conventional methods obviously a key to this method is to have well trained prototypers available to go to the user sites the operational prototyping methodology has many benefits in systems that are complex and have few known requirements in advance evolutionary systems development evolutionary systems development is a class of methodologies that attempt to formally implement evolutionary prototyping one particular type called systemscraft is described by john crinnion in his book evolutionary systems development systemscraft was designed as a prototype methodology that should be modified and adapted to fit the specific environment in which it was implemented systemscraft was not designed as a rigid cookbook approach to the development process it is now generally recognised the basis of systemscraft not unlike evolutionary prototyping is to create a working system from the initial requirements and build upon it in a series of revisions systemscraft places heavy emphasis on traditional analysis being used throughout the development of the system evolutionary rapid development evolutionary rapid development erd was developed by the software productivity consortium a technology development and integration agent for the information technology office of the defense advanced research projects agency darpa fundamental to erd is the concept of composing software systems based on the reuse of components the use of software templates and on an architectural template continuous evolution of system capabilities in rapid response to changing user needs and technology is highlighted by the evolvable architecture representing a class of solutions the process focuses on the use of small artisanbased teams integrating software and systems engineering disciplines working multiple often parallel shortduration timeboxes with frequent customer interaction key to the success of the erdbased projects is parallel exploratory analysis and development of features infrastructures and components with and adoption of leading edge technologies enabling the quick reaction to changes in technologies the marketplace or customer requirements to elicit customeruser input frequent scheduled and ad hocimpromptu meetings with the stakeholders are held demonstrations of system capabilities are held to solicit feedback before designimplementation decisions are solidified frequent releases eg betas are made available for use to provide insight into how the system could better support user and customer needs this assures that the system evolves to satisfy existing user needs the design framework for the system is based on using existing published or de facto standards the system is organized to allow for evolving a set of capabilities that includes considerations for performance capacities and functionality the architecture is defined in terms of abstract interfaces that encapsulate the services and their implementation eg cots applications the architecture serves as a template to be used for guiding development of more than a single instance of the system it allows for multiple application components to be used to implement the services a core set of functionality not likely to change is also identified and established the erd process is structured to use demonstrated functionality rather than paper products as a way for stakeholders to communicate their needs and expectations central to this goal of rapid delivery is the use of the timebox method timeboxes are fixed periods of time in which specific tasks eg developing a set of functionality must be performed rather than allowing time to expand to satisfy some vague set of goals the time is fixed both in terms of calendar weeks and personhours and a set of goals is defined that realistically can be achieved within these constraints to keep development from degenerating into a random walk longrange plans are defined to guide the iterations these plans provide a vision for the overall system and set boundaries eg constraints for the project each iteration within the process is conducted in the context of these longrange plans once an architecture is established software is integrated and tested on a daily basis this allows the team to assess progress objectively and identify potential problems quickly since small amounts of the system are integrated at one time diagnosing and removing the defect is rapid user demonstrations can be held at short notice since the system is generally ready to exercise at all times tools efficiently using prototyping requires that an organization have the proper tools and a staff trained to use those tools tools used in prototyping can vary from individual tools such as 4th generation programming languages used for rapid prototyping to complex integrated case tools 4th generation visual programming languages like visual basic and coldfusion are frequently used since they are cheap well known and relatively easy and fast to use case tools supporting requirements analysis like the requirements engineering environment see below are often developed or selected by the military or large organizations object oriented tools are also being developed like lymb from the ge research and development center users may prototype elements of an application themselves in a spreadsheet as webbased applications continue to grow in popularity so too have the tools for prototyping such applications frameworks such as bootstrap foundation and angularjs provide the tools necessary to quickly structure a proof of concept these frameworks typically consist of a set of controls interactions and design guidelines that enable developers to quickly prototype web applications screen generators design tools and software factories screen generating programs are also commonly used and they enable prototypers to show users systems that do not function but show what the screens may look like developing human computer interfaces can sometimes be the critical part of the development effort since to the users the interface essentially is the system software factories can generate code by combining readytouse modular components this makes them ideal for prototyping applications since this approach can quickly deliver programs with the desired behaviour with a minimal amount of manual coding application definition or simulation software a new class of software called application definition or simulation software enables users to rapidly build lightweight animated simulations of another computer program without writing code application simulation software allows both technical and nontechnical users to experience test collaborate and validate the simulated program and provides reports such as annotations screenshot and schematics as a solution specification technique application simulation falls between lowrisk but limited text or drawingbased mockups or wireframes sometimes called paperbased prototyping and timeconsuming highrisk codebased prototypes allowing software professionals to validate requirements and design choices early on before development begins in doing so the risks and costs associated with software implementations can be dramatically reduced to simulate applications one can also use software that simulates realworld software programs for computerbased training demonstration and customer support such as screencasting software as those areas are closely related there are also more specialised tools requirements engineering environment the requirements engineering environment ree under development at rome laboratory since 1985 provides an integrated toolset for rapidly representing building and executing models of critical aspects of complex systems requirements engineering environment is currently used by the united states air force to develop systems it is an integrated set of tools that allows systems analysts to rapidly build functional user interface and performance prototype models of system components these modeling activities are performed to gain a greater understanding of complex systems and lessen the impact that inaccurate requirement specifications have on cost and scheduling during the system development process models can be constructed easily and at varying levels of abstraction or granularity depending on the specific behavioral aspects of the model being exercised ree is composed of three parts the first called proto is a case tool specifically designed to support rapid prototyping the second part is called the rapid interface prototyping system or rip which is a collection of tools that facilitate the creation of user interfaces the third part of ree is a user interface to rip and proto that is graphical and intended to be easy to use rome laboratory the developer of ree intended that to support their internal requirements gathering methodology their method has three main parts elicitation from various sources users interfaces to other systems specification and consistency checking analysis that the needs of diverse users taken together do not conflict and are technically and economically feasible validation that requirements so derived are an accurate reflection of user needs in 1996 rome labs contracted software productivity solutions sps to further enhance ree to create a commercial quality ree that supports requirements specification simulation user interface prototyping mapping of requirements to hardware architectures and code generation this system is named the advanced requirements engineering workstation or arew lymb lymb is an objectoriented development environment aimed at developing applications that require combining graphicsbased user interfaces visualization and rapid prototyping nonrelational environments nonrelational definition of data eg using cach or associative models can help make enduser prototyping more productive by delaying or avoiding the need to normalize data at every iteration of a simulation this may yield earliergreater clarity of business requirements though it does not specifically confirm that requirements are technically and economically feasible in the target production system psdl psdl is a prototype description language to describe realtime software the associated tool set is caps computer aided prototyping system prototyping software systems with hard realtime requirements is challenging because timing constraints introduce implementation and hardware dependencies psdl addresses these issues by introducing control abstractions that include declarative timing constraints caps uses this information to automatically generate code and associated realtime schedules monitor timing constraints during prototype execution and simulate execution in proportional real time relative to a set of parameterized hardware models it also provides default assumptions that enable execution of incomplete prototype descriptions integrates prototype construction with a software reuse repository for rapidly realizing efficient implementations and provides support for rapid evolution of requirements and designs comparison of software prototyping tools notes c melissa mcclendon larry regot gerri akers the analysis and prototyping of effective graphical user interfaces october 1996 da stacy professor university of guelph guelph ontario lecture notes on rapid prototyping august 1997 stephen j andriole information system design principles for the 90s getting it right afcea international press fairfax virginia 1990 page 13 r charette software engineering risk analysis and management mcgraw hill new york 1989 alan m davis operational prototyping a new development approach ieee software september 1992 page 71 todd grimm the human condition a justification for rapid prototyping time compression technologies vol 3 no 3 accelerated technologies inc may 1998 page 1 john crinnion evolutionary systems development a practical guide to the use of prototyping within a structured systems methodology plenum press new york 1991 page 18 s p overmyer revolutionary vs evolutionary rapid prototyping balancing software productivity and hci design concerns center of excellence in command control communications and intelligence c3i george mason university 4400 university drive fairfax virginia software productivity consortium evolutionary rapid development spc document spc97057cmc version 010004 june 1997 herndon va page 6 davis page 7273 citing e bersoff and a davis impacts of life cycle models of software configuration management comm acm aug 1991 pp104118 adapted from c melissa mcclendon larry regot gerri akers adapted from software productivity consortium pps 1013 joseph e urban software prototyping and requirements engineering rome laboratory rome ny paul w parry rapid software prototyping sheffield hallam university sheffield uk dr ramon acosta carla burns william rzepka and james sidoran applying rapid prototyping techniques in the requirements engineering environment ieee 1994 software productivity solutions incorporated advanced requirements engineering workstation arew 1996 from ge research and development httpswebarchiveorgweb20061013220422httpwwwcrdgecomeslcgspfactsheetobjorienindexhtml dynamic systems development method consortium httpswebarchiveorgweb20060209072841httpnadsdmorg alan dix janet finlay gregory d abowd russell beale humancomputer interaction third edition vtesoftware engineeringfields computer programming requirements engineering software deployment software design software maintenance software testing systems analysis formal methods concepts data modeling enterprise architecture functional specification modeling language orthogonality programming paradigm software software archaeology software architecture software configuration management software development methodology software development process software quality software quality assurance software verification and validation structured analysis orientations agile aspectoriented object orientation ontology service orientation sdlc modelsdevelopmental agile eup executable uml incremental model iterative model prototype model rad up scrum spiral model vmodel waterfall model xp other spice cmmi data model er model function model information model metamodeling object model systems model view model languages idef uml usl sysml softwareengineers victor basili kent beck grady booch fred brooks barry boehm peter chen danese cooper ward cunningham tom demarco edsger w dijkstra delores m etter martin fowler adele goldstine margaret hamilton c a r hoare lois haibt mary jean harrold grace hopper watts humphrey michael a jackson ivar jacobson alan kay nancy leveson stephen j mellor bertrand meyer david parnas trygve reenskaug winston w royce james rumbaugh mary shaw peri tarr elaine weyuker niklaus wirth edward yourdon related fields computer science computer engineering project management risk management systems engineering category commons 