Prototipado de software

Un término común para un prototipo de interfaz de usuario es el prototipo horizontal . Este proporciona una visión general de todo un sistema o subsistema, centrándose en la interacción del usuario más 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 aprobación de la empresa.
• Elaborar estimaciones preliminares del tiempo, el coste y el esfuerzo necesarios para el 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 volúmenes de datos y necesidades de interfaz del sistema, para dimensionar la red y realizar ingeniería de rendimiento,
• Aclare los requisitos complejos profundizando en la funcionalidad real del sistema.

También conocido como prototipado cerrado. El prototipado desechable o rápido se refiere a la creación de un modelo que finalmente se descartará en lugar de formar parte del software final. Tras la recopilación preliminar de requisitos, se construye un modelo funcional sencillo del sistema para mostrar visualmente a los usuarios cómo se verían sus requisitos una vez implementados en el sistema final. También es una forma de prototipado rápido.

El prototipado rápido implica la creación de un modelo funcional de diversas partes del sistema en una etapa muy temprana, tras una investigación relativamente breve. El método utilizado para su construcción suele ser bastante informal, siendo el factor más importante la rapidez con la que se proporciona el modelo. Este modelo se convierte entonces en el punto de partida desde el cual los usuarios pueden reevaluar sus expectativas y clarificar sus requisitos. Una vez alcanzado este objetivo, el prototipo se descarta y el sistema se desarrolla formalmente en función de los requisitos identificados. ^{[ 6 ]}

La razón más obvia para usar prototipos desechables es su rapidez. Si los usuarios reciben retroalimentación inmediata sobre sus requisitos, pueden refinarlos al inicio del desarrollo del software. Realizar cambios en las primeras etapas del ciclo de vida del desarrollo es extremadamente rentable, ya que no hay nada que rehacer. Si un proyecto se modifica después de haber avanzado considerablemente, pequeños cambios podrían requerir un gran esfuerzo para su implementación, dado 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, es difícil invertir en un prototipo que se desechará.

Otra ventaja del prototipado desechable es su capacidad para crear interfaces que los usuarios pueden probar. La interfaz de usuario es lo que el usuario percibe del sistema, y ​​al verla frente a él, le resulta mucho más fácil comprender cómo funcionará.

…se afirma que el prototipado rápido revolucionario es una forma más eficaz de abordar los problemas relacionados con los requisitos del usuario y, por lo tanto, una mejora significativa en la productividad general del software. Los requisitos pueden identificarse, simularse y probarse de forma mucho más rápida y económica cuando se ignoran los problemas de evolucionabilidad, 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 los modelos convencionales de desarrollo de software. ^{[ 7 ]}

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 sincronización. Un método para crear un prototipo desechable de baja fidelidad es el prototipado en papel . El prototipo se implementa con papel y lápiz, imitando así la función del producto real, pero sin su apariencia. Otro método para crear fácilmente prototipos desechables de alta fidelidad es usar un creador de interfaces gráficas de usuario (GUI) y crear un prototipo interactivo (click dummy) , que se asemeja al sistema de objetivos, pero no ofrece ninguna funcionalidad.

El uso de storyboards , animatics o dibujos no es exactamente lo mismo que la creación de prototipos desechables, pero sin duda pertenece a la misma categoría. Se trata de implementaciones no funcionales, pero que muestran el aspecto que tendrá el sistema.

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

1. Redactar los requisitos preliminares
2. Diseña el prototipo
3. El usuario experimenta/utiliza el prototipo, especifica nuevos requisitos.
4. Repita si es necesario
5. Redactar los requisitos finales

El prototipado evolutivo (también conocido como prototipado en placa de pruebas ) es muy diferente del prototipado desechable . El objetivo principal del prototipado evolutivo es construir un prototipo robusto de forma estructurada y perfeccionarlo constantemente. Esto se debe a que el prototipo evolutivo, una vez construido, constituye el núcleo del nuevo sistema, y ​​las mejoras y los requisitos adicionales se irán incorporando posteriormente.

Al desarrollar un sistema mediante prototipado evolutivo, el sistema se refina y reconstruye continuamente.

"...el prototipado evolutivo reconoce que no entendemos todos los requisitos y construye solo aquellos que se comprenden bien." ^{[ 8 ]}

Esta técnica permite al equipo de desarrollo añadir funcionalidades o realizar cambios que no se podían prever durante la fase de requisitos y diseño.

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

Los prototipos evolutivos tienen una ventaja sobre los prototipos desechables, ya que son sistemas funcionales. Si bien es posible que no incluyan todas las características previstas por los usuarios, pueden utilizarse de forma provisional hasta la entrega del sistema final.

"No es inusual que en un entorno de creación de prototipos 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." ^{[ 6 ]}

En el prototipado evolutivo, los desarrolladores pueden centrarse en desarrollar las partes del sistema que comprenden, en lugar de trabajar en el desarrollo de un sistema completo.

Para minimizar el riesgo, el desarrollador no implementa funcionalidades que no se comprenden bien. El sistema parcial se envía a las instalaciones del cliente. A medida que los usuarios trabajan con el sistema, detectan oportunidades para nuevas funcionalidades y las solicitan a los desarrolladores. Estos, junto con las suyas, toman en cuenta estas solicitudes de mejora y utilizan buenas prácticas de gestión de la configuración para modificar la especificación de requisitos del software, actualizar el diseño, recodificar y volver a probar. ^{[ 10 ]}

El producto final se construye mediante prototipos independientes. Al final, estos prototipos se integran en un diseño general. Gracias al prototipado incremental, se reduce el tiempo de espera entre el usuario y el desarrollador del software.

El prototipado extremo, como proceso de desarrollo, se utiliza especialmente para el desarrollo de aplicaciones web. Básicamente, divide el desarrollo web en tres fases, cada una basada en la anterior. La primera fase consiste en un prototipo estático compuesto principalmente por páginas HTML. En la segunda fase, las pantallas se programan y se vuelven completamente funcionales mediante una capa de servicios simulada. En la tercera fase, se implementan los servicios.

"El proceso se denomina 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 más allá de su contrato." ^{[ 11 ]}

El Método de Desarrollo de Sistemas Dinámicos (DSDM) ^{[ 14 ]} es un marco para la entrega de soluciones empresariales que se basa en gran medida en la creación de prototipos como técnica fundamental, y cuenta con la certificación ISO 9001. Amplía la mayoría de las definiciones conocidas de prototipo. Según DSDM, el prototipo puede ser un diagrama, un proceso empresarial o incluso un sistema puesto en producción. Los prototipos DSDM están diseñados para ser incrementales, evolucionando desde formas simples hacia otras más completas.

Los prototipos DSDM pueden ser desechables o evolutivos . Los prototipos evolutivos pueden evolucionar 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 llegar a 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 van a automatizar.
• Prototipos de usabilidad : se utilizan para definir, refinar y demostrar la usabilidad, la accesibilidad, el aspecto y la sensación del diseño de la interfaz de usuario.
• Prototipos de rendimiento y capacidad : se utilizan para definir, demostrar y predecir cómo se comportará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 el siguiente:

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

Alan Davis propuso el prototipado operacional como una forma de integrar el prototipado desechable y el prototipado evolutivo con el desarrollo de sistemas convencional. «Ofrece lo mejor de ambos mundos, el del desarrollo rápido y sencillo y el del desarrollo convencional, de una manera sensata. Los diseñadores desarrollan solo las características bien comprendidas al construir la base evolutiva, mientras que utilizan el prototipado desechable para experimentar con las características menos comprendidas». ^{[ 8 ]}

Davis opina que intentar "adaptar la calidad a un prototipo rápido" no es el método adecuado para combinar ambos enfoques. Su idea consiste en emplear una metodología de prototipado evolutivo y prototipar rápidamente las características del sistema tras cada evolución.

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

• Se construye un prototipo evolutivo y se convierte en una base utilizando estrategias de desarrollo convencionales, especificando e implementando únicamente los requisitos que se comprenden bien.
• Se envían copias del diseño base a varios clientes junto con un creador de prototipos capacitado.
• En cada sitio, el creador del prototipo observa al usuario frente al sistema.
• Siempre que el usuario encuentra un problema o piensa en una nueva función o requisito, el creador del prototipo lo registra. Esto libera al usuario de tener que registrar el problema y le permite seguir 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 cambios no son efectivos, el creador del prototipo los elimina.
• Si al usuario le gustan los cambios, el creador del prototipo redacta solicitudes de mejora de funciones y las remite al equipo de desarrollo.
• El equipo de desarrollo, con las solicitudes de cambio de todos los sitios en mano, produce un nuevo prototipo evolutivo utilizando métodos convencionales.

Obviamente, un aspecto clave de este método es contar con prototipadores bien capacitados que puedan visitar las instalaciones de los usuarios. La metodología de prototipado operativo ofrece muchas ventajas en sistemas complejos con pocos requisitos definidos de antemano.

El desarrollo de sistemas evolutivos es una clase de metodologías que intentan implementar formalmente el prototipado evolutivo. 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 debía modificarse y adaptarse al entorno específico en el que se implementara.

Systemscraft no fue diseñado como un enfoque rígido de "manual de instrucciones" para el proceso de desarrollo. Ahora se reconoce generalmente que una buena metodología debe ser lo suficientemente flexible como para adaptarse a todo tipo de entornos y situaciones... ^{[ 6 ]}

La metodología Systemscraft, similar al prototipado evolutivo, se basa en crear un sistema funcional a partir de los requisitos iniciales y desarrollarlo mediante una serie de revisiones. Systemscraft hace especial hincapié en el uso del análisis tradicional a lo largo de todo el desarrollo del sistema.

El Desarrollo Rápido Evolutivo (ERD) ^{[ 15 ]} fue desarrollado por el 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 el diseño entidad-relación (DER) es 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. La arquitectura evolutiva, que representa una clase de soluciones, resalta 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 de profesionales que integran disciplinas de ingeniería de software y sistemas, trabajando en múltiples proyectos, a menudo en paralelo y de corta duración, con interacción frecuente con el cliente.

La clave del éxito de los proyectos basados ​​en ERD reside en 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 permiten una rápida reacción a los cambios en las tecnologías, el mercado o los requisitos del cliente. ^{[ 9 ]}

Para obtener la opinión de los clientes/usuarios, se realizan reuniones frecuentes, tanto programadas como improvisadas, con las partes interesadas. Se llevan a cabo demostraciones de las capacidades del sistema para recabar comentarios antes de tomar decisiones definitivas sobre el diseño y la implementación. Se publican actualizaciones frecuentes (por ejemplo, versiones beta ) para que el sistema pueda comprender mejor cómo satisfacer las necesidades de los usuarios y clientes. Esto garantiza que el sistema evolucione para satisfacer las necesidades actuales de los usuarios.

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, capacidad 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 para guiar el desarrollo de más de una instancia del sistema. Permite el uso de múltiples componentes de aplicación para implementar los servicios. Asimismo, se identifica y establece un conjunto básico de funcionalidades que probablemente no cambien.

El proceso ERD está estructurado para utilizar la funcionalidad demostrada en lugar de documentos en papel como medio para que las partes interesadas comuniquen sus necesidades y expectativas. Un elemento central para lograr una entrega rápida es el uso del método de " plazas de tiempo ". Las placas de tiempo son períodos fijos en los que se deben realizar tareas específicas (por ejemplo, desarrollar un conjunto de funcionalidades). En lugar de permitir que el tiempo se extienda para satisfacer un conjunto vago de objetivos, el tiempo es fijo (tanto en semanas calendario como en horas-persona) y se define un conjunto de objetivos que se pueden alcanzar de manera realista dentro de estas limitaciones. Para evitar que el desarrollo se convierta en un " paseo aleatorio ", se definen planes a largo plazo que guían 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 establecida la arquitectura, el software se integra y prueba diariamente. Esto permite al equipo evaluar el progreso de forma objetiva e identificar rápidamente posibles problemas. Dado que se integran pequeñas partes del sistema a la vez, el diagnóstico y la corrección de los defectos son rápidos. Se pueden realizar demostraciones para usuarios con poca antelación, ya que el sistema suele estar listo para su uso en todo momento.

Los programas generadores de pantallas también son de uso común y permiten a los creadores de prototipos mostrar a los usuarios sistemas que aún no funcionan, pero que ilustran el posible aspecto de las pantallas. El desarrollo de interfaces hombre-máquina puede ser, en ocasiones, la parte crucial del proceso de desarrollo, ya que para los usuarios la interfaz es, en esencia, el sistema.

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

Una nueva clase de software, denominada software de definición o simulación de aplicaciones, permite a los usuarios crear rápidamente simulaciones ligeras y animadas de otro programa informático sin necesidad de escribir código . Este software permite tanto a usuarios 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 los prototipos (o wireframes ) basados ​​en texto o dibujos, de bajo riesgo pero limitados (a veces denominados prototipado en papel ), y los prototipos basados ​​en código , que consumen mucho tiempo y conllevan un alto riesgo. Esto permite a los profesionales del software validar los requisitos y las decisiones de diseño en una fase temprana, antes de que comience el desarrollo. De este modo, se pueden reducir drásticamente los riesgos y los costes asociados a las implementaciones de software. ^{[ 16 ]}

Para simular aplicaciones, también se puede utilizar software que simule programas informáticos reales para la formación , demostración y atención al cliente basadas en ordenador , como por ejemplo software de grabación de pantalla, ya que estas á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." ^{[ 17 ]}

El Entorno de Ingeniería de Requisitos es utilizado actualmente por la Fuerza Aérea de los Estados Unidos para desarrollar sistemas. Es:

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

REE se compone de tres partes. La primera, llamada proto, es una herramienta CASE diseñada específicamente para el prototipado rápido. La segunda parte se denomina Sistema de Prototipado Rápido de Interfaz (RIP), que es un conjunto de herramientas que facilitan la creación de interfaces de usuario. La tercera parte de REE es una interfaz gráfica para RIP y proto, diseñada para ser fácil de usar.

Rome Laboratory, el desarrollador de REE, pretendía que este sistema sirviera de apoyo a su metodología interna de recopilación de requisitos. 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 la coherencia.
• Análisis que demuestra que las necesidades de los diversos usuarios, consideradas 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. ^{[ 17 ]}

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..." ^{[ 18 ]} Este sistema se denomina Estación de trabajo de ingeniería de requisitos avanzada o AREW.

La definición no relacional de datos (por ejemplo, mediante Caché o modelos asociativos) puede contribuir a que la creación de prototipos por parte 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 generar una mayor claridad en los requisitos del negocio, aunque no garantiza específicamente que dichos 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. ^{[ 19 ]} El conjunto de herramientas asociado es CAPS (Computer Aided Prototyping System). ^{[ 20 ]} La creación de prototipos de sistemas de software con requisitos estrictos de 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 cronogramas en tiempo real asociados, monitorear las restricciones de tiempo durante la ejecución del prototipo y simular la ejecución en tiempo real proporcional con respecto a 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 ]}