Concepto
En contraste con la Ingeniería de Software de la década de los 70, que dio respuesta a proyectos grandes pero con requisitos estables, la Ingeniería de Software de los 80 reaccionó a las complicaciones resultantes de encontrarse con requisitos poco claros y dinámicos, dando lugar a la “construcción de prototipos”. El modelo de ciclo de vida de prototipos fue propuesto por Gomaa en 1984.
Un prototipo es un mecanismo para identificar los requisitos del software. La construcción de prototipos es un proceso que facilita al ingeniero de software el desarrollo de la aplicación. El prototipo suele tomar una de las tres formas siguientes • Un modelo en papel o en computadora que describe la interacción hombre-máquina, de forma que facilite al usuario la comprensión de su funcionamiento. • Un modelo que implementa una función requerida importante. Es el mismo caso que anteriormente pero sin centrarse en la interacción hombre-máquina. • Un programa real que se adecue en parte al software que se desea desarrollar. |
Etapas de construcción de prototipo
- Recolección de requisitos. El ingeniero de software y el cliente definen los objetivos globales del software, y aquéllos más específicos que se desean destacar con el prototipo.
- Diseño rápido. Centrado en los aspectos del software visible al usuario (por ejemplo, interfaz de usuario, entradas y salidas…).
- Construcción del prototipo.
- Evaluación del prototipo. Se realiza por el cliente y usuarios, lo que permitirá concretar y refinar los requisitos del software a desarrollar.
- Refinamiento del prototipo. Se produce un proceso iterativo en el que el prototipo es refinado para que satisfaga las necesidades del cliente, al tiempo que facilita al ingeniero de software un mejor conocimiento del sistema.
- Producto. En la mayoría de los casos este sistema refinado (piloto) hay que desecharlo y hacer uno nuevo. Por ello, el desarrollo de un prototipo se debe planificar con el acuerdo expreso del cliente.
Observaciones sobre el desarrollo rápido de prototipos
• Un prototipo rápido es básicamente una técnica de análisis que permite completar el conjunto de requisitos funcionales de un sistema software.
• Lo deseable es evolucionar el prototipo hasta obtener el producto final, en lugar de deshacerlo y construir un producto final nuevo. Este deseo es válido si del prototipo se puede obtener dicho producto (lo que no suele ser fácil), y su coste es inferior a su reconstrucción. Incluso, se podría recomendar utilizar aquellas técnicas que permitan evolucionar un prototipo hasta el producto final.
• Cualquier aplicación nueva que el ingeniero de software sospeche que su funcionalidad puede presentar el riesgo de no ser aceptable para el usuario o si la interfaz de usuario es importante para el éxito de la aplicación, es una aplicación fuertemente candidata para que se desarrolle un rápido prototipo.
• En un proyecto de prototipo bien planificado, aproximadamente el 50% del esfuerzo de desarrollo, desde su inicio hasta la aprobación final de su funcionalidad, es la contribución del usuario. Los equipos de prototipo están compuestos típicamente por la mitad de usuarios y la otra mitad de desarrolladores software.
• Es habitual tener que tirar la primera versión de cualquier sistema que se desarrolle por primera vez. Por ello, es aconsejable que la primera demostración de un prototipo rápido sea intencionalmente imperfecta, de forma que sea barato de producir y muy fácil de modificar, para que se pueda garantizar que el sistema final que se suministra se ajuste mejor a los requisitos del usuario.
• El prototipo rápido es una solución que “evita el riesgo” en lugar de una solución de riesgo. Así, el prototipo rápido no introduce nuevos riesgos políticos o económicos al proceso de desarrollo de software, sino que reduce significativamente varios factores de riesgo asociados con su desarrollo, como los que se han señalado anteriormente.
• El prototipo rápido es un método normal para el desarrollo de nuevas aplicaciones y llegará a ser más y más evidente que el prototipo rápido produce mejores sistemas y con costes más bajos.
• Lo deseable es evolucionar el prototipo hasta obtener el producto final, en lugar de deshacerlo y construir un producto final nuevo. Este deseo es válido si del prototipo se puede obtener dicho producto (lo que no suele ser fácil), y su coste es inferior a su reconstrucción. Incluso, se podría recomendar utilizar aquellas técnicas que permitan evolucionar un prototipo hasta el producto final.
• Cualquier aplicación nueva que el ingeniero de software sospeche que su funcionalidad puede presentar el riesgo de no ser aceptable para el usuario o si la interfaz de usuario es importante para el éxito de la aplicación, es una aplicación fuertemente candidata para que se desarrolle un rápido prototipo.
• En un proyecto de prototipo bien planificado, aproximadamente el 50% del esfuerzo de desarrollo, desde su inicio hasta la aprobación final de su funcionalidad, es la contribución del usuario. Los equipos de prototipo están compuestos típicamente por la mitad de usuarios y la otra mitad de desarrolladores software.
• Es habitual tener que tirar la primera versión de cualquier sistema que se desarrolle por primera vez. Por ello, es aconsejable que la primera demostración de un prototipo rápido sea intencionalmente imperfecta, de forma que sea barato de producir y muy fácil de modificar, para que se pueda garantizar que el sistema final que se suministra se ajuste mejor a los requisitos del usuario.
• El prototipo rápido es una solución que “evita el riesgo” en lugar de una solución de riesgo. Así, el prototipo rápido no introduce nuevos riesgos políticos o económicos al proceso de desarrollo de software, sino que reduce significativamente varios factores de riesgo asociados con su desarrollo, como los que se han señalado anteriormente.
• El prototipo rápido es un método normal para el desarrollo de nuevas aplicaciones y llegará a ser más y más evidente que el prototipo rápido produce mejores sistemas y con costes más bajos.
Ventajas• Permite la construcción del sistema con requisitos poco claros o cambiantes
• El cliente recibe una versión del sistema en muy poco tiempo, por lo que lo puede evaluar, probar e, incluso, empezar a utilizarlo • Se pueden introducir cambios en las funcionalidades del sistema en cualquier momento • Involucra al usuario en la evaluación de la interfaz de usuario • Se reduce el riesgo y la incertidumbre sobre el desarrollo • Genera signos visibles de progreso, que se utilizan cuando existe una demanda en la velocidad del desarrollo • Permite entender bien el problema antes de la implementación final |
Desventajas• El cliente puede quedar convencido con las primeras versiones y, quizás, no vea la necesidad de completar el sistema o rediseñarlo con la calidad necesaria
• Requiere trabajo del cliente para evaluar los distintos prototipos y traducirlo en nuevos requisitos • Requiere un tiempo adicional para definir adecuadamente el sistema • No se sabe exactamente cuánto será el tiempo de desarrollo ni cuantos prototipos se tienen que desarrollar • Si un prototipo fracasa, el coste del proyecto puede resultar muy caro. |