Content deleted Content added
Undid revision 971798432 by 111.119.185.51 (talk) |
m Reverted 1 edit by 2400:9800:6E1:CD7C:1:0:2C41:A7F8 (talk) to last revision by KH-1 |
||
| (34 intermediate revisions by 31 users not shown) | |||
Line 1:
{{
{{
{{Software development process}}
'''Software prototyping''' is the activity of creating [[prototype]]s of software applications, i.e., incomplete versions of the [[Software|software program]] being developed. It is an activity that can occur in [[Software development process|software development]] and is comparable to [[prototyping]] as known from other fields, such as [[mechanical engineering]] or [[manufacturing]].
Line 6:
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 [[Program specification|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 [[Milestone (project management)|milestone]]s 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 software's functions and potential threats or issues.<ref>{{Cite web|url=https://www.ingsoftware.com/software-prototyping|title=Software Prototyping - INGSOFTWARE|website=
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.{{Citation needed|date=March 2010}}
▲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 software's functions and potential threats or issues.<ref>{{Cite web|url=https://www.ingsoftware.com/software-prototyping|title=Software Prototyping - INGSOFTWARE|website=www.ingsoftware.com|language=en|access-date=2018-06-27}}</ref> Prototyping can also be used by end users to describe and prove requirements that have not been considered, and that can be a key factor in the commercial relationship between developers and their clients.<ref>Smith MF ''Software Prototyping: Adoption, Practice and Management''. McGraw-Hill, London (1991).</ref> [[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.{{Citation needed|date=March 2010}} 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 Man-Month]]'' and his 10-year anniversary article "[[No Silver Bullet]]".
An early example of large-scale software prototyping was the implementation of NYU's Ada/ED translator for the [[Ada (programming language)|Ada programming language]].<ref>{{cite
==Outline
The process of prototyping involves the following steps
# Identify basic [[requirement]]s
#: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
# Review
#:The customers, including end-users, examine the prototype and provide feedback on potential additions or changes.
Line 30 ⟶ 29:
#: Using the feedback both the specifications and the prototype can be improved. Negotiation about what is within the scope of the contract/product may be necessary. If changes are introduced then a repeat of steps #3 and #4 may be needed.
== Dimensions
[[Jakob Nielsen (usability consultant)|Nielsen]] summarizes the various dimensions of prototypes in his book ''[[Usability Engineering]]'':
Line 48 ⟶ 47:
* Clarify complex requirements by drilling down to actual system functionality.
==Types
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 close-ended prototyping. Throwaway or [[Rapid application development|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 form of 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 re-examine 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.
Line 60 ⟶ 59:
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 requirements-related 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 user's perspective, via conventional software development models.<ref
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 prototypes|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.
Line 78 ⟶ 77:
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 couldn't 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 changes…we often try to define a system using our most familiar frame of reference—where 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 version…The 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 configuration-management practices to change the software-requirements specification, update the design, recode and retest.
===Incremental prototyping===
Line 96 ⟶ 95:
===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
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.
==Disadvantages
Using, or perhaps misusing, prototyping can also have disadvantages.
Line 121 ⟶ 120:
'''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.
==Applicability==
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 [[on-line 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 [[
===Dynamic systems development method===
[[Dynamic Systems Development Method]] (DSDM)
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.
Line 150 ⟶ 149:
===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 quick-and-dirty and conventional-development worlds in a sensible manner. Designers develop only well-understood 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:<ref
*An evolutionary prototype is constructed and made into a baseline using conventional development strategies, specifying and implementing only the requirements that are well understood.
Line 172 ⟶ 171:
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[sic] that a good methodology should be flexible enough to be adjustable to suit all kinds of environment and
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)
: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 artisan-based teams integrating software and systems engineering disciplines working multiple, often parallel short-duration timeboxes with frequent customer interaction.
:Key to the success of the ERD-based 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 customer/user input, frequent scheduled and ad hoc/impromptu meetings with the stakeholders are held. Demonstrations of system capabilities are held to solicit feedback before design/implementation decisions are solidified. Frequent releases (e.g., [[Development stage#Beta|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.
Line 197 ⟶ 196:
===Screen generators, design tools, and software factories===
[[Screen generator|Screen generating programs]] are also commonly used and they enable prototypers to show user's systems that do not function, but show what the screens may look like. Developing [[Human–computer interaction|Human Computer Interfaces]] can sometimes be the critical part of the development effort, since to the users the interface essentially is the system.
[[Software factory|Software factories]] can generate code by combining ready-to-use 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.
Line 204 ⟶ 203:
===Application definition or simulation software===
A new class of software called '''Application definition or simulation software''' enables [[user (computing)|users]] to rapidly build lightweight, [[animation|animated]] [[simulation]]s of another computer program, without writing [[source code|code]]. Application simulation software allows both technical and non-technical users to experience, test, collaborate and validate the simulated program, and provides reports such as [[annotation]]s, [[screenshot]] and [[schematic]]s. As a solution specification technique, Application Simulation falls between low-risk, but limited, text or drawing-based [[mock-up]]s (or [[Website wireframe|wireframe]]s) sometimes called ''paper-based prototyping'', and time-consuming, high-risk code-based [[prototype]]s, 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.<ref>[http://www.cio.com/article/print/28501 How Simulation Software Can Streamline Application Development] {{webarchive|url=https://archive.
To simulate applications one can also use software that simulates real-world software programs for [[computer-based training]], demonstration, and customer support, such as [[screencasting software]] as those areas are closely related.
===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.
Line 220 ⟶ 219:
* 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
===Non-relational environments===
Non-relational definition of data (e.g. using [[Caché (software)|Caché]] or
===PSDL===
PSDL is a prototype description language to describe real-time software.<ref>{{cite journal|last=Luqi|author2=Berzins, Yeh |title=A Prototyping Language for Real-Time Software|journal=IEEE Transactions on Software Engineering|date=October 1988|volume=14|issue=10|pages=1409–1423|doi=10.1109/32.6186|hdl=10945/39162 |s2cid=35348234 |url=https://calhoun.nps.edu/bitstream/10945/39162/1/inc_Luqi_a_prototyping_1988.pdf}}</ref>
The associated tool set is CAPS (Computer Aided Prototyping System).<ref>{{cite journal|last=Luqi|author2=Ketabchi |title=A Computer-Aided Prototyping System|journal=IEEE Software|date=March 1988|volume=5|issue=2|pages=66–72|doi=10.1109/52.2013|hdl=10945/43616 |s2cid=15541544 |hdl-access=free}}</ref>
Prototyping software systems with hard real-time 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 real-time 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.<ref>{{cite journal|last=Luqi|title=Software Evolution through Rapid Prototyping|journal=IEEE Computer|date=May 1989|volume=22|issue=5|pages=13–25|doi=10.1109/2.27953|hdl=10945/43610|s2cid=1809234|url=https://zenodo.org/record/1232144|hdl-access=free}}</ref>
==References==
| |||