Creación de prototipos de software

Activity of creating prototypes of software applications

Para otros usos, consulte Programación basada en prototipos .

Desarrollo de software
Actividades centrales Actividades principales Procesos Requisitos Diseño Ingenieria Construcción Pruebas Depuración Despliegue Mantenimiento
Paradigmas y modelos Ágil Sala limpia Incremental Creación de prototipos Espiral Modelo V Cascada
Metodologías y marcos TEA DevOps PADRE DSDM FDD IID Kanban Lean SD Menos MDD MSF PSP RAD RUP A salvo Melé SEMAT TSP Abrir ARRIBA XP
Disciplinas de apoyo Gestión de la configuración Documentación Aseguramiento de la calidad del software Gestión de proyectos Experiencia de usuario
Practicas ATDD BDD CCO CI CD DDD PÁGINAS SBE Ponerse de pie TDD
Herramientas Compilador Depurador Perfilador Diseñador de GUI Modelado IDE Automatización de construcción Automatización de lanzamientos Infraestructura como código Pruebas
Estándares y cuerpos de conocimiento BABOK CMMI Estándares IEEE ISO 9001 Normas ISO / IEC PMBOK SWEBOK ITIL IREB
Glosarios Inteligencia artificial Ciencias de la Computación Ingeniería eléctrica y electrónica
Contornos Esquema del desarrollo de software
v t mi

La creación de prototipos de software es la actividad de crear prototipos de aplicaciones de software, es decir, versiones incompletas del programa de software que se está desarrollando. Es una actividad que puede ocurrir en el desarrollo de software y es comparable a la creación de prototipos como se conoce en otros campos, como la ingeniería mecánica o la fabricación .

Por lo general, un prototipo simula solo algunos aspectos del producto final y puede ser completamente diferente del mismo.

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.^[1]

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.^[2] 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.^[3] 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]} 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.^[4] It was implemented in SETL with the intent of producing an executable semantic model for the Ada language, emphasizing clarity of design and user interface over speed and efficiency. The NYU Ada/ED system was the first validated Ada implementation, certified on April 11, 1983.^[5]

Outline

El proceso de creación de prototipos incluye los siguientes pasos: ^{[ cita requerida ]}

1. Identificar los requisitos básicos

   Determine los requisitos básicos, incluida la información de entrada y salida deseada. Los detalles, como la seguridad, normalmente se pueden ignorar.

2. Desarrollar prototipo inicial

   Se desarrolla el prototipo inicial que incluye solo interfaces de usuario. (Ver prototipo horizontal , a continuación)

3. Revisar

   Los clientes, incluidos los usuarios finales, examinan el prototipo y brindan comentarios sobre posibles adiciones o cambios.

4. Revisar y mejorar el prototipo

   Con los comentarios se pueden mejorar tanto las especificaciones como el prototipo. Puede ser necesario negociar sobre lo que está dentro del alcance del contrato / producto. Si se introducen cambios, es posible que sea necesario repetir los pasos n. ° 3 y n. ° 4.

Dimensiones

Nielsen resume las diversas dimensiones de los prototipos en su libro Ingeniería de usabilidad :

Prototipo horizontal

Un término común para un prototipo de interfaz de usuario es el prototipo horizontal . Proporciona una visión amplia de todo un sistema o subsistema, centrándose en la interacción del usuario más que en la funcionalidad del sistema de bajo nivel, como el acceso a la base de datos. Los prototipos horizontales son útiles para:

• Confirmación de los requisitos de la interfaz de usuario y el alcance del sistema.
• Versión de demostración del sistema para obtener la aceptación de la empresa,
• Desarrolle estimaciones preliminares de tiempo, costo y esfuerzo de desarrollo.

Prototipo vertical

Un prototipo vertical es una elaboración completa mejorada de un solo subsistema o función. Es útil para obtener requisitos detallados para una función determinada, con los siguientes beneficios:

• Diseño de base de datos de refinamiento ,
• Obtener información sobre los volúmenes de datos y las necesidades de la interfaz del sistema, para el dimensionamiento de la red y la ingeniería de rendimiento.
• Aclare los requisitos complejos profundizando en la funcionalidad real del sistema.

Tipos

La creación de prototipos de software tiene muchas variantes. Sin embargo, todos los métodos se basan de alguna manera en dos formas principales de creación de prototipos: creación de prototipos desechables y creación de prototipos evolutivos.

Prototipos desechables

También se llama creación de prototipos cerrados. La creación de prototipos desechables o rápidos se refiere a la creación de un modelo que eventualmente se descartará en lugar de convertirse en parte del software final entregado. Una vez que se logra la recopilación de requisitos preliminares, se construye un modelo de trabajo simple del sistema para mostrar visualmente a los usuarios cómo pueden verse sus requisitos cuando se implementan en un sistema terminado. También es un prototipo rápido.

La creación rápida de prototipos implica la creación de un modelo funcional de varias partes del sistema en una etapa muy temprana, después de una investigación relativamente corta. El método utilizado para construirlo suele ser bastante informal, siendo el factor más importante la velocidad con la que se proporciona el modelo. El modelo se convierte entonces en el punto de partida desde el cual los usuarios pueden volver a examinar sus expectativas y aclarar sus requisitos. Cuando se ha logrado este objetivo, el modelo prototipo se 'desecha' y el sistema se desarrolla formalmente sobre la base de los requisitos identificados. ^[6]

La razón más obvia para usar prototipos desechables es que se pueden hacer rápidamente. Si los usuarios pueden obtener comentarios rápidos sobre sus requisitos, es posible que puedan perfeccionarlos al principio del desarrollo del software. Hacer cambios al principio del ciclo de vida del desarrollo es extremadamente rentable, ya que no hay nada que rehacer en ese momento. Si se cambia un proyecto después de que se ha realizado una cantidad considerable de trabajo, los pequeños cambios podrían requerir grandes esfuerzos de implementación, ya que los sistemas de software tienen muchas dependencias. La velocidad es crucial en la implementación de un prototipo desechable, ya que con un presupuesto limitado de tiempo y dinero se puede gastar poco en un prototipo que se desechará.

Otro punto fuerte de la creación de prototipos desechables es su capacidad para construir interfaces que los usuarios pueden probar. La interfaz de usuario es lo que el usuario ve como el sistema, y ​​al verla frente a ellos, es mucho más fácil comprender cómo funcionará el sistema.

... se afirma que la creación de prototipos rápida y revolucionaria es una manera más eficaz de tratar los problemas relacionados con los requisitos del usuario y, por lo tanto, una mayor mejora de la productividad del software en general. Los requisitos se pueden identificar, simular y probar de manera mucho más rápida y económica cuando se ignoran los problemas de capacidad de evolución, mantenibilidad y estructura del software. Esto, a su vez, conduce a la especificación precisa de los requisitos y la posterior construcción de un sistema válido y utilizable desde la perspectiva del usuario, a través de modelos de desarrollo de software convencionales. ^[7]

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 non-functional 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:

1. Write preliminary requirements
2. Design the prototype
3. User experiences/uses the prototype, specifies new requirements
4. Repeat if necessary
5. 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."^[8]

Esta técnica permite al equipo de desarrollo agregar funciones o realizar cambios que no pudieron concebirse durante la fase de requisitos y diseño.

Para que un sistema sea útil, debe evolucionar mediante el uso en su entorno operativo previsto. Un producto nunca está "terminado"; siempre está madurando a medida que cambia el entorno de uso ... a menudo tratamos de definir un sistema utilizando nuestro marco de referencia más familiar, donde estamos ahora. Hacemos suposiciones sobre la forma en que se llevará a cabo el negocio y la base tecnológica sobre la que se implementará el negocio. Se promulga un plan para desarrollar la capacidad y, tarde o temprano, se entrega algo parecido al sistema previsto. ^[9]

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."^[6]

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.^[10]

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

La creación de prototipos extremos como proceso de desarrollo se utiliza especialmente para desarrollar aplicaciones web. Básicamente, divide el desarrollo web en tres fases, cada una basada en la anterior. La primera fase es un prototipo estático que consta principalmente de páginas HTML. En la segunda fase, las pantallas se programan y son completamente funcionales mediante una capa de servicios simulados. En la tercera fase, se implementan los servicios.

"El proceso se llama Prototipado Extremo para llamar la atención sobre la segunda fase del proceso, donde se desarrolla una interfaz de usuario completamente funcional con muy poca consideración por los servicios que no sean su contrato". ^[11]

Ventajas

El uso de prototipos en el desarrollo de software tiene muchas ventajas: algunas tangibles, otras abstractas. ^[12]

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.^[7]

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.^[6] 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 user's desire for look, feel and performance.

Disadvantages

El uso, o quizás el mal uso, de la creación de prototipos también puede tener desventajas.

Análisis insuficiente : el enfoque en un prototipo limitado puede distraer a los desarrolladores de analizar correctamente el proyecto completo. Esto puede llevar a pasar por alto mejores soluciones, la preparación de especificaciones incompletas o la conversión de prototipos limitados en proyectos finales mal diseñados que son difíciles de mantener . Además, dado que un prototipo tiene una funcionalidad limitada, es posible que no se escale bien si el prototipo se utiliza como base de un producto final, lo que puede pasar desapercibido si los desarrolladores están demasiado concentrados en construir un prototipo como modelo.

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 error-checking 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 (e.g. to deliver core functionality on time and within budget), without understanding wider commercial issues. For example, user representatives attending Enterprise software (e.g. 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 creepporque han hecho suposiciones sobre el alcance de los requisitos del usuario. Si el desarrollador ha comprometido la entrega antes de que se revisaran los requisitos del usuario, los desarrolladores se encuentran entre la espada y la pared, especialmente si la gestión de usuarios obtiene alguna ventaja de su falta de implementación de los requisitos.

Apego del desarrollador al prototipo: los desarrolladores también pueden apegarse a los prototipos en los que han dedicado un gran esfuerzo a producir; esto puede generar problemas, como intentar convertir un prototipo limitado en un sistema final cuando no tiene una arquitectura subyacente adecuada. (Esto puede sugerir que se deberían utilizar prototipos desechables, en lugar de prototipos evolutivos).

Excesivo tiempo de desarrollo del prototipo : una propiedad clave para la creación de prototipos es el hecho de que se supone que debe realizarse rápidamente. Si los desarrolladores pierden de vista este hecho, es muy posible que intenten desarrollar un prototipo que sea demasiado complejo. Cuando se desecha el prototipo, es posible que los requisitos desarrollados con precisión que proporciona no produzcan un aumento suficiente de la productividad para compensar el tiempo invertido en desarrollar el prototipo. Los usuarios pueden quedarse atrapados en debates sobre los detalles del prototipo, lo que retrasa al equipo de desarrollo y retrasa el producto final.

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.^[13]

Aplicabilidad

Se ha argumentado que la creación de prototipos, de una forma u otra, debería utilizarse todo el tiempo. Sin embargo, la creación de prototipos es más beneficiosa en sistemas que tendrán muchas interacciones con los usuarios.

Se ha encontrado que la creación de prototipos es muy efectiva en el análisis y diseño de sistemas en línea , especialmente para el procesamiento de transacciones , donde el uso de diálogos en pantalla es mucho más evidente. Cuanto mayor sea la interacción entre la computadora y el usuario, mayor será el beneficio que se puede obtener al construir un sistema rápido y dejar que el usuario juegue con él. ^[6]

Los sistemas con poca interacción del usuario, como el procesamiento por lotes o los sistemas que en su mayoría realizan cálculos, se benefician poco de la creación de prototipos. A veces, la codificación necesaria para realizar las funciones del sistema puede ser demasiado intensiva y las ganancias potenciales que podría proporcionar la creación de prototipos son demasiado pequeñas. ^[6]

La creación de prototipos es especialmente buena para diseñar buenas interfaces persona-computadora . "Uno de los usos más productivos de la creación rápida de prototipos hasta la fecha ha sido como una herramienta para la ingeniería de requisitos de usuario iterativa y el diseño de la interfaz persona-computadora". ^[7]

Método de desarrollo de sistemas dinámicos

El Método de desarrollo de sistemas dinámicos (DSDM) ^[14] es un marco para la entrega de soluciones comerciales que se basa en gran medida en la creación de prototipos como técnica central, y está aprobado por ISO 9001 . Amplía las definiciones más entendidas de un prototipo. Según DSDM, el prototipo puede ser un diagrama, un proceso empresarial o incluso un sistema puesto en producción. Los prototipos de DSDM están pensados ​​para ser incrementales, evolucionando de formas simples a formas más completas.

Los prototipos de DSDM a veces pueden ser desechables o evolutivos . Los prototipos evolutivos pueden evolucionar horizontalmente (amplitud y luego profundidad) o verticalmente (cada sección se construye en detalle con iteraciones adicionales que detallan las secciones posteriores). Los prototipos evolutivos pueden eventualmente evolucionar a sistemas finales.

Las cuatro categorías de prototipos recomendadas por DSDM son:

• Prototipos comerciales : se utilizan para diseñar y demostrar la automatización de los procesos comerciales.
• Prototipos de usabilidad : se utilizan para definir, refinar y demostrar la usabilidad, accesibilidad, apariencia y apariencia del diseño de la interfaz de usuario.
• Prototipos de rendimiento y capacidad : se utilizan para definir, demostrar y predecir cómo funcionarán los sistemas bajo cargas máximas, así como para demostrar y evaluar otros aspectos no funcionales del sistema (tasas de transacción, volumen de almacenamiento de datos, tiempo de respuesta, etc.)
• Prototipos de capacidad / técnica : se utilizan para desarrollar, demostrar y evaluar un enfoque o concepto de diseño.

El ciclo de vida DSDM de un prototipo es:

1. Identificar prototipo
2. Aceptar un plan
3. Crea el prototipo
4. Revisa el prototipo

Prototipos operativos

Alan Davis propuso la creación de prototipos operativos como una forma de integrar la creación de prototipos desechables y evolutivos con el desarrollo de sistemas convencionales. "Ofrece lo mejor de los mundos de desarrollo rápido y sucio y convencional de una manera sensata. Los diseñadores desarrollan solo características bien entendidas al construir la línea de base evolutiva, mientras usan prototipos desechables para experimentar con las características poco entendidas". ^[8]

La creencia de Davis es que intentar "adaptar la calidad a un prototipo rápido" no es el método correcto cuando se intenta combinar los dos enfoques. Su idea es participar en una metodología de creación de prototipos evolutivos y hacer prototipos rápidamente de las características del sistema después de cada evolución.

La metodología específica sigue estos pasos: ^[8]

• 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 aren't effective, the prototyper removes them.
• Si al usuario le gustan los cambios, el prototipo escribe solicitudes de mejora de características y las reenvía al equipo de desarrollo.
• El equipo de desarrollo, con las solicitudes de cambio en la mano de todos los sitios, luego produce un nuevo prototipo evolutivo utilizando métodos convencionales.

Obviamente, una clave de este método es tener prototipos bien capacitados disponibles para ir a los sitios de los usuarios. La metodología de creación de prototipos operativos tiene muchos beneficios en sistemas que son complejos y tienen pocos requisitos conocidos de antemano.

Desarrollo de sistemas evolutivos

El desarrollo de sistemas evolutivos es una clase de metodologías que intentan implementar formalmente prototipos evolutivos. Un tipo particular, llamado Systemscraft, es descrito por John Crinnion en su libro Evolutionary Systems Development .

Systemscraft se diseñó como una metodología de "prototipo" que debería modificarse y adaptarse para adaptarse al entorno específico en el que se implementó.

Systemscraft no fue diseñado como un enfoque rígido de "libro de cocina" para el proceso de desarrollo. Ahora se reconoce generalmente [sic] que una buena metodología debe ser lo suficientemente flexible como para ser ajustable para adaptarse a todo tipo de entorno y situación ... ^[6]

La base de Systemscraft, al igual que la creación de prototipos evolutivos, es crear un sistema funcional a partir de los requisitos iniciales y desarrollarlo en una serie de revisiones. Systemscraft pone un gran énfasis en el análisis tradicional que se utiliza a lo largo del desarrollo del sistema.

Desarrollo rápido evolutivo

El Desarrollo Rápido Evolutivo (ERD) ^[15] fue desarrollado por Software Productivity Consortium, un agente de desarrollo e integración de tecnología para la Oficina de Tecnología de la Información de la Agencia de Proyectos de Investigación Avanzada de Defensa (DARPA).

Fundamental para ERD es el concepto de componer sistemas de software basados ​​en la reutilización de componentes, el uso de plantillas de software y en una plantilla de arquitectura. La evolución continua de las capacidades del sistema en respuesta rápida a las necesidades cambiantes de los usuarios y la tecnología se destaca por la arquitectura evolutiva, que representa una clase de soluciones. El proceso se centra en el uso de pequeños equipos artesanales que integran disciplinas de ingeniería de sistemas y software que trabajan en múltiples espacios de tiempo de corta duración, a menudo paralelos, con interacción frecuente con el cliente.

La clave para el éxito de los proyectos basados ​​en ERD es el análisis exploratorio paralelo y el desarrollo de características, infraestructuras y componentes con la adopción de tecnologías de vanguardia que permitan una reacción rápida a los cambios en las tecnologías, el mercado o los requisitos de los clientes. ^[9]

Para obtener la opinión del cliente / usuario, se llevan a cabo reuniones frecuentes programadas y ad hoc / improvisadas con las partes interesadas. Se realizan demostraciones de las capacidades del sistema para solicitar comentarios antes de que se solidifiquen las decisiones de diseño / implementación. Los lanzamientos frecuentes (p. Ej., Versiones beta ) están disponibles para su uso a fin de proporcionar información sobre cómo el sistema podría respaldar mejor las necesidades de los usuarios y clientes. Esto asegura que el sistema evolucione para satisfacer las necesidades de los usuarios existentes.

El marco de diseño del sistema se basa en el uso de estándares publicados o de facto existentes. El sistema está organizado para permitir la evolución de un conjunto de capacidades que incluye consideraciones de rendimiento, capacidades y funcionalidad. La arquitectura se define en términos de interfaces abstractas que encapsulan los servicios y su implementación (por ejemplo, aplicaciones COTS). La arquitectura sirve como plantilla que se utilizará para guiar el desarrollo de más de una instancia del sistema. Permite que se utilicen varios componentes de la aplicación para implementar los servicios. También se identifica y establece un conjunto básico de funcionalidades que no es probable que cambie.

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 (e.g., 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 person-hours) and a set of goals is defined that realistically can be achieved within these constraints. To keep development from degenerating into a "random walk, "los planes a largo plazo se definen para guiar las iteraciones. Estos planes proporcionan una visión del sistema general y establecen límites (por ejemplo, restricciones) para el proyecto. Cada iteración dentro del proceso se lleva a cabo en el contexto de estos planes a largo plazo .

Una vez que se establece una arquitectura, el software se integra y se prueba a diario. Esto permite que el equipo evalúe el progreso de manera objetiva e identifique problemas potenciales rápidamente. Dado que se integran pequeñas cantidades del sistema a la vez, el diagnóstico y la eliminación del defecto es rápido. Las demostraciones para los usuarios se pueden realizar con poca antelación ya que el sistema generalmente está listo para ejercitarse en todo momento.

Herramientas

El uso eficiente de la creación de prototipos requiere que una organización tenga las herramientas adecuadas y un personal capacitado para usar esas herramientas. Las herramientas utilizadas en la creación de prototipos pueden variar desde herramientas individuales, como lenguajes de programación de cuarta generación utilizados para la creación rápida de prototipos, hasta complejas herramientas CASE integradas . Los lenguajes de programación visual de cuarta generación como Visual Basic y ColdFusion se utilizan con frecuencia, ya que son baratos, bien conocidos y relativamente fáciles y rápidos de usar. Las herramientas CASE, que respaldan el análisis de requisitos, como el Entorno de ingeniería de requisitos (ver más abajo), a menudo son desarrolladas o seleccionadas por el ejército o por grandes organizaciones. También se están desarrollando herramientas orientadas a objetos como LYMBdel Centro de Investigación y Desarrollo de GE . Los usuarios pueden crear prototipos de elementos de una aplicación ellos mismos en una hoja de cálculo .

A medida que las aplicaciones basadas en la web continúan creciendo en popularidad, también lo han hecho las herramientas para crear prototipos de dichas aplicaciones. Los marcos como Bootstrap , Foundation y AngularJS proporcionan las herramientas necesarias para estructurar rápidamente una prueba de concepto . Por lo general, estos marcos consisten en un conjunto de controles, interacciones y pautas de diseño que permiten a los desarrolladores crear rápidamente prototipos de aplicaciones web.

Generadores de pantallas, herramientas de diseño y fábricas de software

Los programas de generación de pantallas también se utilizan comúnmente y permiten a los prototipos mostrar los sistemas de los usuarios que no funcionan, pero muestran cómo pueden verse las pantallas. El desarrollo de interfaces hombre-computadora a veces puede ser la parte crítica del esfuerzo de desarrollo, ya que para los usuarios, la interfaz es esencialmente el sistema.

Las fábricas de software pueden generar código combinando componentes modulares listos para usar. Esto los hace ideales para aplicaciones de creación de prototipos, ya que este enfoque puede entregar rápidamente programas con el comportamiento deseado, con una cantidad mínima de codificación manual.

Software de simulación o definición de aplicaciones

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 non-technical 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 low-risk, but limited, text or drawing-based mock-ups (or wireframes) sometimes called paper-based prototyping, and time-consuming, high-risk code-based 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.^[16]

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

"El entorno de ingeniería de requisitos (REE), en desarrollo en el laboratorio de Rome desde 1985, proporciona un conjunto de herramientas integrado para representar, construir y ejecutar rápidamente modelos de aspectos críticos de sistemas complejos". ^[17]

La Fuerza Aérea de los Estados Unidos utiliza actualmente el entorno de ingeniería de requisitos para desarrollar sistemas. Es:

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.^[17]

REE se compone de tres partes. El primero, llamado proto, es una herramienta CASE diseñada específicamente para admitir la creación rápida de prototipos. La segunda parte se denomina Sistema de creación de prototipos de interfaz rápida o RIP, que es una colección de herramientas que facilitan la creación de interfaces de usuario. La tercera parte de REE es una interfaz de usuario para RIP y proto que es gráfica y está destinada a ser fácil de usar.

Rome Laboratory, el desarrollador de REE, tenía la intención de respaldar su metodología de recopilación de requisitos internos. Su método tiene tres partes principales:

• Obtención de diversas fuentes (usuarios, interfaces con otros sistemas), especificación y verificación de coherencia.
• Análisis de que las necesidades de los diversos usuarios en su conjunto no entran en conflicto y son técnica y económicamente viables
• Validación de que los requisitos así derivados son un reflejo exacto de las necesidades del usuario. ^[17]

En 1996, Rome Labs contrató Software Productivity Solutions (SPS) para mejorar aún más REE y crear "un REE de calidad comercial que admita la especificación de requisitos, simulación, creación de prototipos de interfaz de usuario, mapeo de requisitos para arquitecturas de hardware y generación de código ..." ^{[18 ]} Este sistema se denomina Estación de trabajo de ingeniería de requisitos avanzados o AREW.

Entornos no relacionales

La definición no relacional de datos (por ejemplo, utilizando Caché o modelos asociativos ) puede ayudar a que la creación de prototipos del usuario final sea más productiva al retrasar o evitar la necesidad de normalizar los datos en cada iteración de una simulación. Esto puede producir una mayor claridad de los requisitos comerciales, aunque no confirma específicamente que los requisitos sean técnica y económicamente viables en el sistema de producción de destino.

PSDL

PSDL es un lenguaje de descripción prototipo para describir software en tiempo real. ^[19] El conjunto de herramientas asociado es CAPS (Sistema de creación de prototipos asistido por computadora). ^[20]La creación de prototipos de sistemas de software con requisitos estrictos en tiempo real es un desafío porque las limitaciones de tiempo introducen dependencias de implementación y hardware. PSDL aborda estos problemas mediante la introducción de abstracciones de control que incluyen restricciones de tiempo declarativas. CAPS utiliza esta información para generar automáticamente código y programas asociados en tiempo real, monitorear las restricciones de tiempo durante la ejecución del prototipo y simular la ejecución en tiempo real proporcional en relación con un conjunto de modelos de hardware parametrizados. También proporciona supuestos predeterminados que permiten la ejecución de descripciones de prototipos incompletas, integra la construcción de prototipos con un repositorio de reutilización de software para realizar rápidamente implementaciones eficientes y brinda soporte para la rápida evolución de requisitos y diseños. ^[21]

Referencias

1. Todd Grimm: La condición humana: una justificación para la creación rápida de prototipos. Tecnologías de compresión de tiempo, vol. 3 no. 3. Accelerated Technologies, Inc. Mayo de 1998. Página 1. [1]
2. "Prototipos de software - INGSOFTWARE" . ingsoftware.com . Consultado el 27 de junio de 2018 .
3. Creación de prototipos de software Smith MF : adopción, práctica y gestión . McGraw-Hill, Londres (1991).
4. Dewar, Robert BK; Fisher Jr., Gerald A .; Schonberg, Edmond; Froelich, Robert; Bryant, Stephen; Goss, Clinton F .; Burke, Michael (noviembre de 1980). "El traductor e intérprete de NYU Ada". Avisos ACM SIGPLAN - Actas del Simposio ACM-SIGPLAN sobre el lenguaje de programación Ada . 15 (11): 194-201. doi : 10.1145 / 948632.948659 . ISBN 0-89791-030-3.
5. SofTech Inc. (11 de abril de 1983). "Informe de resumen de validación del compilador Ada: NYU Ada / ED, versión 19.7 V-001" . Archivado desde el original el 12 de marzo de 2012 . Consultado el 16 de diciembre de 2010 .
6. 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.
7. 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.
8. Alan M. Davis: Operational Prototyping: A new Development Approach. IEEE Software, September 1992. Page 71.
9. Software Productivity Consortium: Evolutionary Rapid Development. SPC document SPC-97057-CMC, version 01.00.04, June 1997. Herndon, Va. Page 6.
10. Davis. Page 72-73. Citing: E. Bersoff and A. Davis, Impacts of Life Cycle Models of Software Configuration Management. Comm. ACM, Aug. 1991, pp. 104–118
11. Komatineni, Satya. "Reshaping IT Project Delivery Through Extreme Prototyping". Archived from the original on 2016-12-06.
12. Adapted from C. Melissa Mcclendon, Larry Regot, Gerri Akers.
13. Joseph E. Urban: Software Prototyping and Requirements Engineering. Rome Laboratory, Rome, NY.
14. Dynamic Systems Development Method Consortium. https://web.archive.org/web/20060209072841/http://na.dsdm.org/
15. Adapted from Software Productivity Consortium. PPS 10–13.
16. How Simulation Software Can Streamline Application Development Archived 2012-07-22 at archive.today
17. Dr. Ramon Acosta, Carla Burns, William Rzepka, and James Sidoran. Applying Rapid Prototyping Techniques in the Requirements Engineering Environment. IEEE, 1994. [2]
18. Software Productivity Solutions, Incorporated. Advanced Requirements Engineering Workstation (AREW). 1996. [3]
19. Luqi; Berzins, Yeh (October 1988). "A Prototyping Language for Real-Time Software" (PDF). IEEE Transactions on Software Engineering. 14 (10): 1409–1423. doi:10.1109/32.6186. hdl:10945/39162.
20. Luqi; Ketabchi (March 1988). "A Computer-Aided Prototyping System". IEEE Software. 5 (2): 66–72. doi:10.1109/52.2013. hdl:10945/43616.
21. Luqi (May 1989). "Software Evolution through Rapid Prototyping". IEEE Computer. 22 (5): 13–25. doi:10.1109/2.27953. hdl:10945/43610.