Content deleted Content added
Unconstructive edit - Undid revision 1039247648 by 2405:201:A401:FAF5:4C70:B413:DA07:880F (talk) |
m Reverted 1 edit by 2400:9800:6E1:CD7C:1:0:2C41:A7F8 (talk) to last revision by KH-1 |
||
| (19 intermediate revisions by 17 users not shown) | |||
Line 15:
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==
Line 23:
#: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 33:
[[Jakob Nielsen (usability consultant)|Nielsen]] summarizes the various dimensions of prototypes in his book ''[[Usability Engineering]]'':
===
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 low-level system functionality, such as database access. Horizontal prototypes are useful for:
Line 102:
'''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.<ref name=Overmyer/>
'''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.<ref name=Crinnion1991p18/> 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 [[___domain (software engineering)|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 user's desire for look, feel and performance.
==Disadvantages==
Line 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 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."<ref name="AcostaBurnsRzepkaSidoran1994">Dr. Ramon Acosta, Carla Burns, William Rzepka, and James Sidoran. Applying Rapid Prototyping Techniques in the Requirements Engineering Environment. IEEE, 1994. [https://web.archive.org/web/19990421115836/http://www.stsc.hill.af.mil/CrossTalk/1994/oct/xt94d10g.html]</ref>
Requirements Engineering Environment is currently used by the United States Air Force to develop systems. It is:
Line 224:
===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==
| |||