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. Por ejemplo, si el sistema a construir es un cajero automático, se puede hacer un programa que simule la interacción del usuario con el cajero sin que el programa esté conectado a ninguna base de datos real ni se despache dinero. De esta manera el cliente puede hacerse a la idea de cómo va a funcionar el sistema final sin tener que construirlo, y así discutirlo con el ingeniero de software. Naturalmente, en un prototipo no se simularán todas las funcionalidades del sistema pero, si es necesario, se podrán construir otros a medida que la aplicación se vaya desarrollando (ver más abajo cuáles son las etapas para su utilización)
• 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. Por ejemplo, el modelo podría simular todos los pasos a seguir internamente en el sistema en el acceso a la base de datos de clientes cuando se quiere obtener dinero del cajero, pero sin que realmente se trate de una base de datos real ni de un cliente del banco.
• Un programa real que se adecue en parte al software que se desea desarrollar. Por ejemplo, se puede disponer de una aplicación relacionada con un “cajero automático”, que al presentarla al cliente, permita al analista identificar las necesidades del cliente y por lo tanto los requisitos del software a construir.
Normalmente, el prototipo sirve como mecanismo para identificar los requisitos del software, y su construcción suele llevar las siguientes etapas:
1) 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.
2) Diseño rápido. Centrado en los aspectos del software visible al usuario (por ejemplo, interfaz de usuario, entradas y salidas…).
3) Construcción del prototipo.
4) Evaluación del prototipo. Se realiza por el cliente y usuarios, lo que permitirá concretar y refinar los requisitos del software a desarrollar.
5) 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.
6) 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.
Algunos ingenieros del software abogan por desarrollar rápidamente un prototipo que les permita especificar completamente el sistema y obtener más consistentemente el producto final. Sobre el desarrollo rápido de prototipos, pueden realizarse las siguientes observaciones:
• 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.
Ventajas y desventajas del Modelo de” prototipos”
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
Comentarios
Publicar un comentario