Prototipado de software

El prototipado 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 al prototipado tal como se conoce en otros campos, como la ingeniería mecánica o la fabricación . ^[1]

Un prototipo normalmente simula sólo algunos aspectos del producto final y puede ser completamente diferente del mismo.

La creación de prototipos tiene varias ventajas: el diseñador y el implementador del software pueden obtener valiosa retroalimentación de los usuarios al comienzo del proyecto. El cliente y el contratista pueden comparar si el software creado coincide con la especificación de software , según la cual se construye el programa de software. También permite al ingeniero de software tener una idea de la precisión de las estimaciones iniciales del proyecto y si los plazos y los hitos propuestos se pueden cumplir con éxito. El grado de completitud y las técnicas utilizadas en la creación de prototipos han estado en desarrollo y debate desde su propuesta a principios de la década de 1970. ^[2]

El propósito de un prototipo es permitir que los usuarios del software evalúen las propuestas de los desarrolladores para el diseño del producto final probándolas en la práctica, en lugar de tener que interpretar y evaluar el diseño basándose en descripciones. La creación de prototipos de software permite comprender las funciones del software y las posibles amenazas o problemas. ^[3] Los usuarios finales también pueden utilizar la creación de prototipos para describir y demostrar requisitos que no se han tenido en cuenta, y que pueden ser un factor clave en la relación comercial entre los desarrolladores y sus clientes. ^[4] El diseño de interacción , en particular, hace un uso intensivo de la creación de prototipos con ese objetivo.

Este proceso contrasta con el ciclo de desarrollo monolítico de los años 1960 y 1970, en el que primero se creaba el programa completo y luego se solucionaban las inconsistencias entre el diseño y la implementación, lo que conducía a mayores costos de software y estimaciones deficientes de tiempo y costo. ^{[ cita requerida ]} El enfoque monolítico ha sido bautizado como la técnica de "matar al dragón (del software)", ya que supone que el diseñador y desarrollador del software es un héroe único que tiene que matar al dragón solo. La creación de prototipos también puede evitar el gran gasto y la dificultad de tener que cambiar un producto de software terminado.

La práctica de crear prototipos es uno de los puntos que Frederick P. Brooks aborda en su libro de 1975 The Mythical Man-Month y en su artículo del décimo aniversario " No Silver Bullet ".

Un ejemplo temprano de creación de prototipos de software a gran escala fue la implementación del traductor Ada/ED de la Universidad de Nueva York para el lenguaje de programación Ada . ^[5] Se implementó en SETL con la intención de producir un modelo semántico ejecutable para el lenguaje Ada, enfatizando la claridad del diseño y la interfaz de usuario por sobre la velocidad y la eficiencia. El sistema Ada/ED de la Universidad de Nueva York fue la primera implementación validada de Ada, certificada el 11 de abril de 1983. ^[6]

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

1. Identificar requisitos básicos

   Determinar 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 únicamente 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 la retroalimentación se pueden mejorar tanto las especificaciones como el prototipo. Puede ser necesario negociar qué está dentro del alcance del contrato o producto. Si se introducen cambios, puede ser necesario repetir los pasos 3 y 4.

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

Un término común para un prototipo de interfaz de usuario es el de prototipo horizontal . Proporciona una visión amplia de todo un sistema o subsistema, centrándose más en la interacción del usuario que en la funcionalidad de bajo nivel del sistema, 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 del alcance del sistema,
• Versión de demostración del sistema para obtener la aceptación de la empresa.
• Desarrollar estimaciones preliminares de tiempo, costo y esfuerzo de desarrollo.

Un prototipo vertical es una elaboración completa y mejorada de un único 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 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.

El prototipado de software tiene muchas variantes. Sin embargo, todos los métodos se basan de alguna manera en dos formas principales de prototipado: el prototipado desechable y el prototipado evolutivo.

También se denomina prototipado cerrado. El prototipado rápido o desechable se refiere a la creación de un modelo que, con el tiempo, se descartará en lugar de convertirse en parte del software final entregado. Una vez que se logra la recopilación preliminar de requisitos, se construye un modelo funcional simple del sistema para mostrar visualmente a los usuarios cómo se verán sus requisitos cuando se implementen en un sistema terminado. También es una forma de prototipado rápido.

El prototipado rápido implica la creación de un modelo funcional de las distintas partes del sistema en una etapa muy temprana, después de una investigación relativamente breve. 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 a partir del cual los usuarios pueden reexaminar sus expectativas y aclarar sus requisitos. Cuando se ha logrado este objetivo, el modelo prototipo se "descarta" y el sistema se desarrolla formalmente en función de los requisitos identificados. ^[7]

La razón más obvia para utilizar prototipos desechables es que se pueden realizar rápidamente. Si los usuarios pueden obtener una respuesta rápida sobre sus requisitos, pueden perfeccionarlos en las primeras fases del desarrollo del software. Realizar cambios en las primeras fases del ciclo de desarrollo es extremadamente rentable, ya que en ese momento no hay nada que rehacer. Si se modifica un proyecto después de que se haya realizado una cantidad considerable de trabajo, los cambios pequeños pueden requerir grandes esfuerzos para implementarse, ya que los sistemas de software tienen muchas dependencias. La velocidad es crucial para implementar un prototipo desechable, ya que con un presupuesto limitado de tiempo y dinero se puede gastar poco en un prototipo que será descartado.

Otra ventaja de los prototipos desechables es su capacidad para construir interfaces que los usuarios pueden probar. La interfaz de usuario es lo que el usuario ve como sistema y, al verla frente a él, es mucho más fácil comprender cómo funcionará el sistema.

…se afirma que el prototipado rápido y revolucionario es una manera más eficaz de abordar las cuestiones relacionadas con los requisitos del usuario y, por lo tanto, una mejora mayor de la productividad general del software. Los requisitos se pueden identificar, simular y probar mucho más rápido y de forma más económica cuando se ignoran los problemas de evolución, mantenibilidad y estructura del software. Esto, a su vez, conduce a la especificación precisa de los requisitos y a 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. ^[8]

Los prototipos se pueden clasificar según la fidelidad con la que se asemejan al producto real en términos de apariencia, interacción y tiempo. Un método para crear un prototipo desechable de baja fidelidad es el prototipado en papel . El prototipo se implementa utilizando papel y lápiz, y por lo tanto imita la función del producto real, pero no se parece en nada a él. Otro método para construir fácilmente prototipos desechables de alta fidelidad es utilizar un generador de GUI y crear un maniquí de clic , un prototipo que se parece al sistema objetivo, pero que no proporciona ninguna funcionalidad.

El uso de storyboards , animaciones o dibujos no es exactamente lo mismo que el prototipado de usar y tirar, pero sin duda pertenece a la misma familia. Se trata de implementaciones no funcionales, pero muestran cómo se verá el sistema.

Resumen: En este enfoque, el prototipo se construye con la idea de que se desechará y el sistema final se construirá desde cero. Los pasos de este enfoque son:

1. Redactar requisitos preliminares
2. Diseñar el prototipo
3. El usuario experimenta/usa el prototipo y especifica nuevos requisitos.
4. Repetir si es necesario
5. Escribe los requisitos finales

El prototipado evolutivo (también conocido como prototipado en placa de pruebas ) es bastante diferente del prototipado desechable. El objetivo principal al utilizar el prototipado evolutivo es construir un prototipo muy sólido de manera estructurada y refinarlo constantemente. La razón de este enfoque es que el prototipo evolutivo, una vez construido, forma el corazón del nuevo sistema, y ​​luego se construirán las mejoras y los requisitos adicionales.

Al desarrollar un sistema mediante prototipos evolutivos, el sistema se perfecciona y reconstruye continuamente.

“…el prototipado evolutivo reconoce que no entendemos todos los requisitos y construye sólo aquellos que se comprenden bien”. ^[9]

Esta técnica permite al equipo de desarrollo agregar características o realizar cambios que no se pudieron concebir durante la fase de requisitos y diseño.

Para que un sistema sea útil, debe evolucionar a través del uso en el 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: dónde estamos ahora. Hacemos suposiciones sobre la forma en que se llevarán a cabo los negocios y la base tecnológica sobre la que se implementarán. Se pone en práctica un plan para desarrollar la capacidad y, tarde o temprano, se entrega algo parecido al sistema previsto. ^[10]

Los prototipos evolutivos tienen la ventaja sobre los prototipos desechables de que son sistemas funcionales. Aunque no tengan todas las características que los usuarios han planeado, se pueden utilizar de manera provisoria hasta que se entregue el sistema final.

"No es inusual en un entorno de creación de prototipos que el usuario ponga en práctica un prototipo inicial mientras espera una versión más desarrollada... El usuario puede decidir que un sistema 'defectuoso' es mejor que ningún sistema en absoluto". ^[7]

En la creación de prototipos evolutivos, los desarrolladores pueden concentrarse en desarrollar partes del sistema que entienden en lugar de trabajar en el desarrollo de un sistema completo.

Para minimizar el riesgo, el desarrollador no implementa características que no se comprenden bien. El sistema parcial se envía a los sitios del cliente. A medida que los usuarios trabajan con el sistema, detectan oportunidades para nuevas características y envían solicitudes de estas características a los desarrolladores. Luego, los desarrolladores toman estas solicitudes de mejora junto con las suyas y utilizan prácticas de gestión de configuración sólidas para cambiar la especificación de requisitos de software, actualizar el diseño, recodificar y volver a probar. ^[11]

El producto final se construye en forma de prototipos separados. Al final, los prototipos separados se fusionan en un diseño general. Con la ayuda del prototipado incremental, se reduce la brecha de tiempo entre el usuario y el desarrollador del software.

El prototipado extremo 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 funcionan completamente utilizando 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 hacia los servicios que no sean su contrato". ^[12]

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

Reducción de tiempo y costes : la creación de prototipos puede mejorar la calidad de los requisitos y especificaciones que se proporcionan a los desarrolladores. Dado que los cambios cuestan exponencialmente más de implementar, ya que se detectan más tarde en el desarrollo, la determinación temprana de lo que el usuario realmente quiere puede dar como resultado un software más rápido y menos costoso. ^[8]

Mayor y mejorada participación del usuario : la creación de prototipos requiere la participación del usuario y les permite ver e interactuar con un prototipo, lo que les permite proporcionar comentarios y especificaciones mejores y más completos. ^[7] La ​​presencia del prototipo siendo examinado por el usuario evita muchos malentendidos y errores de comunicación que ocurren cuando cada parte cree que la otra entiende lo que dijo. Dado que los usuarios conocen el dominio del problema mejor que cualquier persona del equipo de desarrollo, una mayor interacción puede dar como resultado un producto final que tiene una mayor calidad tangible e intangible. Es más probable que el producto final satisfaga el deseo del usuario en cuanto a apariencia, sensación y rendimiento.

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

Análisis insuficiente : centrarse en un prototipo limitado puede distraer a los desarrolladores y no permitirles analizar adecuadamente el proyecto completo. Esto puede llevar a pasar por alto mejores soluciones, preparar especificaciones incompletas o convertir 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 pueda escalar bien si 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.

Confusión de los usuarios entre prototipo y sistema terminado : los usuarios pueden empezar a pensar que un prototipo, que está destinado a ser desechado, es en realidad un sistema final que sólo necesita ser terminado o pulido. (Por ejemplo, a menudo no son conscientes del esfuerzo necesario para agregar funciones de seguridad y verificación de errores que un prototipo puede no tener). Esto puede llevarlos a esperar que el prototipo modele con precisión el rendimiento del sistema final cuando esa no es la intención de los desarrolladores. Los usuarios también pueden apegarse a las características que se incluyeron en un prototipo para su consideración y luego se eliminaron de la especificación para un sistema final. Si los usuarios pueden exigir que todas las características propuestas se incluyan en el sistema final, esto puede generar conflictos.

Desconocimiento por parte de los desarrolladores de los objetivos de los usuarios : los desarrolladores pueden suponer que los usuarios comparten sus objetivos (por ejemplo, entregar la funcionalidad básica a tiempo y dentro del presupuesto), sin comprender cuestiones comerciales más amplias. Por ejemplo, los representantes de los usuarios que asisten a eventos de software empresarial (por ejemplo, PeopleSoft ) pueden haber visto demostraciones de "auditoría de transacciones" (donde los cambios se registran y se muestran en una vista de cuadrícula de diferencias) sin que se les haya dicho que esta característica exige codificación adicional y, a menudo, requiere más hardware para gestionar accesos adicionales a la base de datos. Los usuarios pueden creer que pueden exigir auditoría en todos los campos, mientras que los desarrolladores pueden pensar que se trata de una ampliación de las características porque han hecho suposiciones sobre el alcance de los requisitos de los usuarios. Si el desarrollador se ha comprometido a entregar antes de que se revisaran los requisitos de los usuarios, los desarrolladores están entre la espada y la pared, en particular si la administración de usuarios obtiene alguna ventaja de su fracaso en la implementación de los requisitos.

Apego de los desarrolladores a los prototipos: los desarrolladores también pueden apegarse a los prototipos en cuya producción han invertido mucho esfuerzo; 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ía utilizar el prototipado descartable, en lugar del prototipado evolutivo).

Tiempo de desarrollo excesivo del prototipo : una característica clave del prototipado es el hecho de que se supone que debe realizarse rápidamente. Si los desarrolladores pierden de vista este hecho, es muy probable que intenten desarrollar un prototipo que sea demasiado complejo. Cuando se desecha el prototipo, los requisitos desarrollados con precisión que proporciona pueden no producir un aumento suficiente en la productividad para compensar el tiempo empleado en desarrollar el prototipo. Los usuarios pueden quedar atrapados en debates sobre los detalles del prototipo, lo que retrasa al equipo de desarrollo y el producto final.

Gastos de implementación de prototipos : los costes iniciales para formar un equipo de desarrollo centrado en el prototipado pueden ser elevados. Muchas empresas cuentan con metodologías de desarrollo y cambiarlas puede implicar volver a capacitar, reequipar o ambas cosas. Muchas empresas tienden a comenzar a crear prototipos sin molestarse en capacitar a sus trabajadores tanto como deberían.

Un problema común con la adopción de tecnología de creación de prototipos son las altas expectativas de productividad y el esfuerzo insuficiente detrás de la curva de aprendizaje. Además de la capacitación para el uso de una técnica de creación de prototipos, existe una necesidad que a menudo se pasa por alto de desarrollar una estructura subyacente específica para la empresa y el proyecto que respalde la tecnología. Cuando se omite esta estructura subyacente, a menudo puede resultar en una menor productividad. ^[14]

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

Se ha descubierto que la creación de prototipos es muy eficaz 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. ^[7]

Los sistemas con poca interacción del usuario, como los sistemas de procesamiento por lotes o los sistemas que principalmente 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 posibles ganancias que podría proporcionar la creación de prototipos son demasiado pequeñas. ^[7]

La creación de prototipos es especialmente útil para diseñar buenas interfaces entre humanos y computadoras . "Uno de los usos más productivos de la creación rápida de prototipos hasta la fecha ha sido como herramienta para la ingeniería iterativa de requisitos de usuario y el diseño de interfaces entre humanos y computadoras". ^[8]

El método de desarrollo de sistemas dinámicos (DSDM) ^[15] 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 la norma ISO 9001. Amplía las definiciones más conocidas de prototipo. Según el DSDM, el prototipo puede ser un diagrama, un proceso comercial o incluso un sistema puesto en producción. Los prototipos DSDM están pensados ​​para ser incrementales, evolucionando desde formas simples a formas más completas.

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

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

• Prototipos empresariales : se utilizan para diseñar y demostrar los procesos empresariales que se están automatizando.
• Prototipos de usabilidad : se utilizan para definir, refinar y demostrar la usabilidad, la accesibilidad, la apariencia y el funcionamiento 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. Acordar un plan
3. Crear el prototipo
4. Revisar el prototipo

Alan Davis propuso el prototipado operativo como una forma de integrar el prototipado desechable y evolutivo con el desarrollo de sistemas convencionales. "Ofrece lo mejor de ambos mundos, el desarrollo rápido y el desarrollo convencional, de una manera sensata. Los diseñadores desarrollan sólo características bien entendidas al construir la línea base evolutiva, mientras que utilizan el prototipado desechable para experimentar con las características poco entendidas". ^[9]

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

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

• Se construye un prototipo evolutivo y se convierte en una línea base utilizando estrategias de desarrollo convencionales, especificando e implementando solo los requisitos que se entienden bien.
• Se envían copias de la línea base a varios sitios de clientes junto con un prototipo capacitado.
• En cada sitio, el creador de prototipos observa al usuario en el sistema.
• Cada vez que el usuario encuentra un problema o piensa en una nueva característica o requisito, el creador de prototipos lo registra. Esto libera al usuario de tener que registrar el problema y le permite continuar trabajando.
• Una vez finalizada la sesión del usuario, el creador del prototipo construye un prototipo desechable sobre el sistema base.
• El usuario ahora utiliza el nuevo sistema y lo evalúa. Si los nuevos cambios no surten efecto, el creador de prototipos los elimina.
• Si al usuario le gustan los cambios, el creador de prototipos escribe solicitudes de mejora de funciones y las envía al equipo de desarrollo.
• El equipo de desarrollo, con las solicitudes de cambio en mano de todos los sitios, produce luego un nuevo prototipo evolutivo utilizando métodos convencionales.

Obviamente, una clave de este método es contar con prototipos bien capacitados y disponibles para ir a las instalaciones de los usuarios. La metodología de creación de prototipos operacionales tiene muchos beneficios en sistemas complejos y con pocos requisitos conocidos de antemano.

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

Systemscraft fue diseñado como una metodología “prototipo” que debería modificarse y adaptarse para ajustarse al entorno específico en el que se implementó.

Systemscraft no fue diseñado como un enfoque rígido de "manual de recetas" para el proceso de desarrollo. Hoy en día se reconoce en general que una buena metodología debe ser lo suficientemente flexible como para poder adaptarse a todo tipo de entornos y situaciones... ^[7]

La base de Systemscraft, al igual que el prototipado evolutivo, es crear un sistema funcional a partir de los requisitos iniciales y desarrollarlo en una serie de revisiones. Systemscraft hace mucho hincapié en el uso del análisis tradicional durante todo el desarrollo del sistema.

El Desarrollo Rápido Evolutivo (ERD) ^[16] fue desarrollado por el Consorcio de Productividad de Software, 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).

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

La clave del éxito de los proyectos basados ​​en ERD es el análisis exploratorio paralelo y el desarrollo de características, infraestructuras y componentes junto 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. ^[10]

Para obtener la opinión de los clientes o usuarios, 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 consoliden las decisiones de diseño e implementación. Se publican versiones frecuentes (por ejemplo, versiones beta ) para proporcionar información sobre cómo el sistema podría satisfacer mejor las necesidades de los usuarios y clientes. Esto garantiza que el sistema evolucione para satisfacer las necesidades existentes de los usuarios.

El marco de diseño del sistema se basa en el uso de estándares existentes, ya sean publicados o de facto. El sistema está organizado para permitir la evolución de un conjunto de capacidades que incluye consideraciones sobre el rendimiento, las capacidades y la 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 utilizar múltiples componentes de aplicación para implementar los servicios. También se identifica y establece un conjunto básico de funcionalidades que probablemente no cambien.

El proceso de ERD está estructurado para utilizar funcionalidades demostradas en lugar de productos en papel como una forma para que las partes interesadas comuniquen sus necesidades y expectativas. El uso del método de " caja de tiempo " es central para este objetivo de entrega rápida. Las cajas de tiempo son períodos fijos de tiempo en los que se deben realizar tareas específicas (por ejemplo, desarrollar un conjunto de funcionalidades). En lugar de permitir que el tiempo se expanda para satisfacer un conjunto vago de objetivos, el tiempo es fijo (tanto en términos de semanas calendario como de horas-persona) y se define un conjunto de objetivos que se pueden lograr de manera realista dentro de estas limitaciones. Para evitar que el desarrollo degenere en un " paseo aleatorio ", se definen planes a largo plazo para guiar las iteraciones. Estos planes proporcionan una visión para el 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 al equipo evaluar el progreso de forma objetiva e identificar rápidamente los problemas potenciales. Dado que se integran pequeñas cantidades del sistema a la vez, el diagnóstico y la eliminación del defecto son rápidos. Se pueden realizar demostraciones de usuarios con poca antelación, ya que el sistema suele estar listo para su uso en todo momento.

Para utilizar de forma eficiente la creación de prototipos, es necesario que una organización cuente con las herramientas adecuadas y un personal capacitado para utilizarlas. Las herramientas que se utilizan en la creación de prototipos pueden variar desde herramientas individuales, como los lenguajes de programación de cuarta generación que se utilizan para la creación rápida de prototipos, hasta herramientas CASE integradas y complejas . Los lenguajes de programación visual de cuarta generación , como Visual Basic y ColdFusion, se utilizan con frecuencia porque son baratos, conocidos y relativamente fáciles y rápidos de utilizar. Las herramientas CASE que respaldan el análisis de requisitos, como el entorno de ingeniería de requisitos (véase más abajo), suelen ser desarrolladas o seleccionadas por el ejército o por grandes organizaciones. También se están desarrollando herramientas orientadas a objetos, como LYMB, del Centro de investigación y desarrollo de GE . Los usuarios pueden crear prototipos de elementos de una aplicación por sí mismos en una hoja de cálculo .

A medida que las aplicaciones web siguen creciendo en popularidad, también lo hacen 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 . Estos marcos suelen constar de un conjunto de controles, interacciones y pautas de diseño que permiten a los desarrolladores crear prototipos de aplicaciones web rápidamente.

Los programas de generación de pantallas también se utilizan con frecuencia y permiten a los creadores de prototipos mostrar sistemas de usuarios que no funcionan, pero mostrar cómo se verían 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 las hace ideales para crear prototipos de aplicaciones, ya que este enfoque puede generar rápidamente programas con el comportamiento deseado, con una cantidad mínima de codificación manual.

Una nueva clase de software, denominada software de definición de aplicaciones o software de simulación, permite a los usuarios crear rápidamente simulaciones animadas y ligeras de otro programa informático, sin necesidad de escribir código . El software de simulación de aplicaciones permite a los usuarios tanto técnicos como no técnicos experimentar, probar, colaborar y validar el programa simulado, y proporciona informes como anotaciones , capturas de pantalla y esquemas . Como técnica de especificación de soluciones, la simulación de aplicaciones se sitúa entre las maquetas (o wireframes ) basadas en texto o dibujos de bajo riesgo, pero limitadas, a veces denominadas prototipos basados ​​en papel , y los prototipos basados ​​en código, que requieren mucho tiempo y son de alto riesgo , lo que permite a los profesionales del software validar los requisitos y las opciones de diseño desde el principio, antes de que comience el desarrollo. Al hacerlo, se pueden reducir drásticamente los riesgos y los costes asociados a las implementaciones de software. ^[17]

Para simular aplicaciones también se puede utilizar software que simule programas de software del mundo real para capacitación basada en computadora , demostración y soporte al cliente, como software de captura de pantalla , ya que esas áreas están estrechamente relacionadas.

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

En la actualidad, la Fuerza Aérea de los Estados Unidos utiliza el entorno de ingeniería de requisitos para desarrollar sistemas. Es:

Un conjunto integrado de herramientas que permite a los analistas de sistemas construir rápidamente modelos de prototipos funcionales, de interfaz de usuario y de rendimiento de los componentes del sistema. Estas actividades de modelado se realizan para obtener una mayor comprensión de los sistemas complejos y reducir el impacto que las especificaciones de requisitos inexactas tienen en los costos y la programación durante el proceso de desarrollo del sistema. Los modelos se pueden construir fácilmente y en distintos niveles de abstracción o granularidad, según los aspectos de comportamiento específicos del modelo que se esté utilizando. ^[18]

REE se compone de tres partes. La primera, llamada proto, es una herramienta CASE diseñada específicamente para respaldar la creación rápida de prototipos. La segunda parte se llama Rapid Interface Prototyping System 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á diseñada para ser fácil de usar.

El Laboratorio de Roma, el desarrollador de REE, pretendía respaldar su metodología de recopilación de requisitos internos. Su método consta de tres partes principales:

• Obtención de informació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 conjunto no entran en conflicto y son técnica y económicamente viables.
• Validación de que los requisitos así derivados reflejan con precisión las necesidades del usuario. ^[18]

En 1996, Rome Labs contrató a 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, la simulación, la creación de prototipos de interfaz de usuario, el mapeo de requisitos a arquitecturas de hardware y la generación de código..." ^[19] Este sistema se denomina Advanced Requirements Engineering Workstation o AREW.

La definición no relacional de los datos (por ejemplo, mediante Caché o modelos asociativos) puede ayudar a que la creación de prototipos para el 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 generar una mayor claridad de los requisitos comerciales antes, aunque no confirma específicamente que los requisitos sean técnica y económicamente viables en el sistema de producción de destino.

PSDL es un lenguaje de descripción de prototipos para describir software en tiempo real. ^[20] El conjunto de herramientas asociado es CAPS (Computer Aided Prototyping System). ^[21] La creación de prototipos de sistemas de software con requisitos estrictos en tiempo real es un desafío porque las restricciones 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 programaciones en tiempo real asociadas, monitorear 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 suposiciones predeterminadas 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. ^[22]