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 . [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 varios beneficios: el diseñador e implementador del software puede obtener comentarios valiosos de los usuarios en las primeras etapas del proyecto. El cliente y el contratista pueden comparar si el software creado coincide con la especificación del software , según la cual se construye el programa de software. También le permite al ingeniero de software tener una idea de la precisión de las estimaciones iniciales del proyecto y de si los plazos y los hitos propuestos se pueden cumplir con éxito. El grado de exhaustividad y las técnicas utilizadas en la creación de prototipos han estado en desarrollo y debate desde su propuesta a principios de los años 1970. [2]
El propósito de un prototipo es permitir a los usuarios del software evaluar las propuestas de los desarrolladores para el diseño del producto final probándolas, en lugar de tener que interpretar y evaluar el diseño basándose en descripciones. La creación de prototipos de software proporciona una comprensión de las funciones del software y de las posibles amenazas o problemas. [3] La creación de prototipos también puede ser utilizada por los usuarios finales para describir y probar requisitos que no han sido considerados, 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 las décadas de 1960 y 1970, en el que primero se construía todo el programa y luego se solucionaba cualquier inconsistencia 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 necesaria ] El enfoque monolítico ha sido denominado la técnica de "Matar al dragón (software)", ya que supone que el diseñador y desarrollador del software es un único héroe que tiene que matar a todo el 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 la creación de prototipos es uno de los puntos que señala Frederick P. Brooks 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 encima de la velocidad y la eficiencia. El sistema NYU Ada/ED 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 necesaria ]
Nielsen resume las diversas dimensiones de los prototipos en su libro Usability Engineering :
Un término común para un prototipo de interfaz de usuario es 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:
Un prototipo vertical es una elaboración completa mejorada de un único subsistema o función. Es útil para obtener requisitos detallados para una función determinada, con los siguientes beneficios:
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: la creación de prototipos desechables y la creación de prototipos evolutivos.
También llamado creación de prototipos cerrados. La creación de prototipos rápidos o desechables se refiere a la creación de un modelo que eventualmente será descartado 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 de trabajo 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 creación rápida de prototipos.
La razón más obvia para utilizar prototipos desechables es que se pueden hacer rápidamente. Si los usuarios pueden obtener comentarios rápidos sobre sus requisitos, podrán perfeccionarlos en las primeras etapas del desarrollo del software. Realizar cambios en las primeras etapas del ciclo de vida de desarrollo es extremadamente rentable ya que en ese momento no hay nada que rehacer. Si se cambia un proyecto después de haber realizado una cantidad considerable de trabajo, los pequeños cambios podrían requerir grandes esfuerzos para implementarse, ya que los sistemas de software tienen muchas dependencias. La velocidad es crucial a la hora de implementar un prototipo desechable, ya que con un presupuesto limitado de tiempo y dinero se puede gastar poco en un prototipo que será desechado.
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 él, es mucho más fácil comprender cómo funcionará el sistema.
Los prototipos se pueden clasificar según la fidelidad con la que se parecen 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 la creación de prototipos en papel . El prototipo está realizado con papel y lápiz, de modo que imita la función del producto real, pero no se parece en nada a él. Otro método para crear fácilmente prototipos desechables de alta fidelidad es utilizar un GUI Builder y crear un clic ficticio , un prototipo que se parece al sistema de objetivos, pero que no proporciona ninguna funcionalidad.
El uso de guiones gráficos , animaciones o dibujos no es exactamente lo mismo que la creación de prototipos desechables, pero ciertamente pertenece a la misma familia. Estas son implementaciones no funcionales pero muestran cómo se verá 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:
La creación de prototipos evolutivos (también conocidos como prototipos de placa de pruebas ) es bastante diferente de la creación de prototipos desechables. El objetivo principal al utilizar prototipos evolutivos es construir un prototipo muy robusto de manera estructurada y perfeccionarlo 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 requisitos adicionales.
Cuando se desarrolla un sistema utilizando prototipos evolutivos, el sistema se refina y reconstruye continuamente.
Esta técnica permite al equipo de desarrollo agregar funciones o realizar cambios que no se pudieron concebir durante la fase de requisitos y diseño.
Los prototipos evolutivos tienen la ventaja sobre los prototipos desechables de que son sistemas funcionales. Aunque es posible que no tengan todas las funciones que los usuarios han planeado, se pueden utilizar de forma provisional hasta que se entregue el sistema final.
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.
El producto final se construye como prototipos separados. Al final, los distintos prototipos se fusionan en un diseño global. Con la ayuda de la creación de prototipos incrementales, se reduce la brecha de tiempo entre el usuario y el desarrollador de software.
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 están programadas y son completamente funcionales utilizando una capa de servicios simulada. En la tercera fase se implementan los servicios.
El uso de prototipos en el desarrollo de software tiene muchas ventajas: algunas tangibles, otras abstractas. [13]
Reducción de tiempo y costos : la creación de prototipos puede mejorar la calidad de los requisitos y especificaciones proporcionadas a los desarrolladores. Debido a que la implementación de los cambios cuesta exponencialmente más, ya que se detectan más adelante en el desarrollo, la determinación temprana de lo que el usuario realmente quiere puede resultar en un software más rápido y menos costoso. [8]
Participación mejorada y mayor 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 faltas 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 miembro del equipo de desarrollo, una mayor interacción puede dar como resultado un producto final con 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 de 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 y difíciles de mantener . Además, dado que un prototipo tiene una funcionalidad limitada, es posible que no se escale bien si se utiliza como base para un producto final, lo que puede pasar desapercibido si los desarrolladores están demasiado concentrados en construir un prototipo como modelo.
Confusión del usuario entre prototipo y sistema terminado : Los usuarios pueden comenzar a pensar que un prototipo, destinado a ser desechado, es en realidad un sistema final que simplemente necesita ser terminado o pulido. (Por ejemplo, a menudo no son conscientes del esfuerzo necesario para agregar características 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 desempeño del sistema final cuando esto no es así. la intención de los desarrolladores. Los usuarios también pueden apegarse a 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 funciones propuestas se incluyan en el sistema final, esto puede generar conflictos.
Malentendido por parte de los desarrolladores de los objetivos de los usuarios : los desarrolladores pueden asumir que los usuarios comparten sus objetivos (por ejemplo, entregar la funcionalidad principal 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 diferente) sin que se les haya dicho que esta característica exige codificación adicional y, a menudo, requiere más hardware para manejar accesos adicionales a la base de datos. Los usuarios pueden creer que pueden exigir auditorías en todos los campos, mientras que los desarrolladores pueden pensar que esto es una característica inadecuada porque han hecho suposiciones sobre el alcance de los requisitos del usuario. Si el desarrollador se ha comprometido a realizar 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 no implementar los requisitos.
Apego del desarrollador al prototipo: los desarrolladores también pueden apegarse a los prototipos que han dedicado mucho 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).
Tiempo excesivo de desarrollo del prototipo : una propiedad clave de 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 demasiado complejo. Cuando el prototipo se desecha, los requisitos desarrollados con precisión que proporciona pueden no producir un aumento suficiente en la productividad para compensar el tiempo dedicado a desarrollar el prototipo. Los usuarios pueden quedarse atrapados en debates sobre los detalles del prototipo, retrasando al equipo de desarrollo y retrasando el producto final.
Gasto de implementación de prototipos : los costos iniciales para crear un equipo de desarrollo centrado en la creación de prototipos pueden ser elevados. Muchas empresas cuentan con metodologías de desarrollo y cambiarlas puede significar volver a capacitarse, reequiparse o ambas cosas. Muchas empresas tienden a empezar a crear prototipos sin molestarse en volver a capacitar a sus trabajadores tanto como deberían.
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.
Los sistemas con poca interacción del usuario, como el 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 los beneficios potenciales que podría proporcionar la creación de prototipos son demasiado pequeños. [7]
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 herramienta para la ingeniería iterativa de requisitos del usuario y el diseño de interfaces hombre-computadora". [8]
El Método de Desarrollo de Sistemas Dinámicos (DSDM) [15] es un marco para ofrecer soluciones empresariales que depende en gran medida de la creación de prototipos como técnica central y está aprobado por la norma ISO 9001 . Amplía las definiciones más entendidas de prototipo. Según DSDM, el prototipo puede ser un diagrama, un proceso de negocio o incluso un sistema puesto en producción. Los prototipos de DSDM están destinados a ser incrementales y evolucionar desde formas simples hasta formas más completas.
Los prototipos DSDM a veces pueden ser desechables o evolutivos . Los prototipos evolutivos pueden evolucionar horizontalmente (en amplitud y luego en profundidad) o verticalmente (cada sección se construye en detalle con iteraciones adicionales que detallan las secciones posteriores). Los prototipos evolutivos pueden eventualmente evolucionar hasta convertirse en sistemas finales.
Las cuatro categorías de prototipos recomendadas por DSDM son:
El ciclo de vida DSDM de un prototipo es:
Alan Davis propuso la creación de prototipos operativos como una forma de integrar los prototipos desechables y evolutivos con el desarrollo de sistemas convencionales. "Ofrece lo mejor de los mundos del desarrollo rápido y sucio y convencional de una manera sensata. Los diseñadores desarrollan sólo características bien comprendidas en la construcción de la línea base evolutiva, mientras utilizan prototipos desechables 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 intentan combinar los dos enfoques. Su idea es participar en una metodología de creación de prototipos evolutivos y crear prototipos rápidamente de las características del sistema después de cada evolución.
La metodología específica sigue estos pasos: [9]
Obviamente, una clave para este método es tener prototipos bien capacitados disponibles para visitar 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.
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 adaptarse al entorno específico en el que se implementó.
La base de Systemscraft, a diferencia de los prototipos evolutivos, es crear un sistema funcional a partir de los requisitos iniciales y desarrollarlo en una serie de revisiones. Systemscraft pone gran énfasis en el uso del análisis tradicional durante todo el desarrollo del sistema.
El Desarrollo Rápido Evolutivo (ERD) [16] fue desarrollado por el Software Productivity Consortium, un agente de integración y desarrollo 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).
Para obtener comentarios de los clientes/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 solidifiquen las decisiones de diseño/implementación. Se ponen a disposición versiones frecuentes (por ejemplo, betas ) para proporcionar información sobre cómo el sistema podría satisfacer mejor las necesidades de los usuarios y clientes. Esto asegura 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 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 utilizar múltiples 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 cambien.
El proceso ERD está estructurado para utilizar funcionalidad demostrada en lugar de productos de papel como una forma para que las partes interesadas comuniquen sus necesidades y expectativas. Para lograr este objetivo de entrega rápida es fundamental el uso del método " timebox ". Los cuadros de tiempo son períodos de tiempo fijos en los que se deben realizar tareas específicas (por ejemplo, desarrollar un conjunto de funciones). En lugar de permitir que el tiempo se expanda para satisfacer un conjunto vago de objetivos, el tiempo se fija (tanto en términos de semanas calendario como de horas-persona) y se define un conjunto de objetivos que de manera realista pueden alcanzarse dentro de estas limitaciones. Para evitar que el desarrollo degenere en un " camino aleatorio ", se definen planes a largo plazo 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 de largo plazo.
Una vez que se establece una arquitectura, el software se integra y prueba diariamente. Esto permite al equipo evaluar el progreso de manera objetiva e identificar problemas potenciales rápidamente. Dado que se integran pequeñas cantidades del sistema al mismo tiempo, diagnosticar y eliminar el defecto es rápido. Se pueden realizar demostraciones de usuarios con poca antelación, ya que el sistema generalmente está listo para funcionar en todo momento.
El uso eficiente 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 porque 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 las grandes organizaciones. También se están desarrollando herramientas orientadas a objetos como LYMB desde el 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 web siguen ganando popularidad, también lo hacen las herramientas para crear prototipos de dichas aplicaciones. Marcos como Bootstrap , Foundation y AngularJS proporcionan las herramientas necesarias para estructurar rápidamente una prueba de concepto . Estos marcos suelen consistir en un conjunto de controles, interacciones y pautas de diseño que permiten a los desarrolladores crear rápidamente prototipos de aplicaciones web.
Los programas de generación de pantallas también se utilizan comúnmente y permiten a los creadores de prototipos mostrar los sistemas del usuario que no funcionan, pero muestran 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 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.
Una nueva clase de software llamado software de simulación o definición de aplicaciones permite a los usuarios crear rápidamente simulaciones animadas y livianas de otro programa de computadora, sin escribir código . El software de simulación de aplicaciones permite a los usuarios técnicos y 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 estructuras alámbricas ) basadas en texto o dibujos, de bajo riesgo, pero limitadas , y los prototipos basados en código, que consumen mucho tiempo y son de alto riesgo , lo que permite profesionales del software para validar los requisitos y las opciones de diseño desde el principio, antes de que comience el desarrollo. Al hacerlo, los riesgos y costos asociados con las implementaciones de software se pueden reducir drásticamente. [17]
Para simular aplicaciones también se puede utilizar software que simule programas de software del mundo real para capacitación, demostración y atención al cliente basados en computadora , como software de screencasting , 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 integrado para representar, construir y ejecutar rápidamente modelos de aspectos críticos de sistemas complejos". [18]
La Fuerza Aérea de los Estados Unidos utiliza actualmente el entorno de ingeniería de requisitos para desarrollar sistemas. Es:
REE se compone de tres partes. La primera, llamada proto, es una herramienta CASE diseñada específicamente para admitir la creación rápida de prototipos. La segunda parte se llama 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 pretende ser fácil de usar.
Rome Laboratory, el desarrollador de REE, pretendía respaldar su metodología de recopilación de requisitos internos. Su método tiene tres partes principales:
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, la simulación, la creación de prototipos de interfaz de usuario, la asignación de requisitos a arquitecturas de hardware y la generación de código..." [19 ] 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, utilizando 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 producir una claridad más temprana o mayor 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 objetivo.
PSDL es un prototipo de lenguaje de descripción para describir software en tiempo real. [20] El conjunto de herramientas asociado es CAPS (Sistema de creación de prototipos asistido por computadora). [21] 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 introduciendo 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 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 implementaciones eficientes rápidamente y brinda soporte para una rápida evolución de requisitos y diseños. [22]