Las metodologías tradicionales para software de ingeniería son el ciclo de vida clásico
(“classic life cycle”), la construcción de prototipos (“prototype building”) y el modelo
evolutivo (“evolutive model”). Todas ellas se basan en la definición de una serie de etapas, las cuales son llevadas a cabo en forma secuencial. En la metodología de ciclo de vida clásico, las fases siguen un modelo de cascada. Este enfoque tiende a desdibujar algunos aspectos importantes como la inevitable necesidad de iterar a través de las diferentes tareas involucradas, lo cual lleva a la corrección de errores y la modificación de los requerimientos definidos originalmente.
La metodología de construcción de prototipos consiste en desarrollar un modelo “juguete” de software como una versión de la implementación final. El modelo preliminar se enfoca en ciertos aspectos del sistema de manera tal de satisfacer lo antes posible los requerimientos del usuario con el mínimo costo posible. En este caso, el lazo de realimentación es el refinamiento del prototipo, el cual es creado como una manera de capturar todos los requerimientos del proyecto. Como resultado de esto, las incertidumbres de especificación son notablemente reducidas. Paradójicamente, el prototipo en sí mismo constituye el principal inconveniente de este enfoque, debido a que el usuario lo ve como una versión final, sin darse cuenta de que el modelo “juguete” no incluye ni los algoritmos óptimos ni la posibilidad de realizar un mantenimiento del mismo a mediano y largo plazo. Como resultado, no se dispone, por razones económicas y de plazos de entrega, de tiempo para desarrollar el software definitivo, haciendo que el prototipo incompleto se convierta en el producto final.
La metodología de modelo evolutivo está constituida por cuatro fases que son llevadas a cabo en varias oportunidades, siguiendo un camino en forma de espiral. Estas cuatro etapas son planeamiento, análisis de riesgo, ingeniería y evaluación del usuario. En la etapa de ingeniería, la técnica combina características de las otras dos metodologías, beneficiándose de sus ventajas, que son precisamente que las primeras iteraciones involucran la utilización de prototipos, mientras que la filosofía del ciclo de vida es utilizada para la implementación final.
Metodología de Desarrollo de Software para Ingeniería Apéndice A
135
análisis de riesgo que continuamente monitorea parámetros económicos y de calidad como son el costo, el tiempo de ejecución y el criterio de evaluación de su funcionamiento.
Las metodologías clásicas para desarrollo de software ingenieril no resultan apropiadas para el desarrollo del software llevado a cabo a lo largo de los años. Las metodologías de ciclo de vida y construcción de prototipos tienen las desventajas mencionadas anteriormente. En un principio, el modelo evolutivo podría haber resultado útil para nuestro propósito. No obstante, se observó que era conveniente introducir algunas modificaciones en esta metodología. Se consideró importante introducir los siguientes aspectos:
• La presencia continua del usuario final, quien asiste al programador controlando en todo momento la calidad del producto elimina la necesidad de tener una etapa de análisis de riesgo.
• Debido a que las especificaciones del usuario varían a lo largo del desarrollo del proyecto, resultaba ideal contar con prototipos en cada nivel de evolución.
Teniendo en cuenta los aspectos mencionados anteriormente, se definió una nueva metodología para desarrollo de software (Vazquez y co., 2001), la cual fue aplicada para los desarrollos de software presentados en esta tesis. Dicha metodología contiene los siguientes pasos: planeamiento, ingeniería de software, evaluación del programador y evaluación del usuario. Estos pasos se repiten hasta que se logran obtener el producto final. La figura A.1 muestra un esquema de la metodología propuesta. El significado de los números ubicados dentro de los círculos se encuentra en la tabla A.1.
1 Análisis inicial de requerimientos
2 Desarrollo del prototipo inicial del software
3 Primera evaluación y revisión del los requerimientos basados en el prototipo inicial
4,8,12 Evaluación del usuario
5,9,13 Planeamiento de las mejoras a realizar al prototipo basadas en las evaluaciones del usuario y el desarrollador
6,10,14 Implementación del prototipo 7,11 Evaluación del desarrollador
Apéndice A Metodología de Desarrollo de Software para Ingeniería
Figura A.1. Esquema de la metodología para desarrollo de software aplicada en esta tesis.
La parte fundamental de esta metodología es la etapa de ingeniería. En todos los niveles de evolución del proyecto se construye un prototipo; en este sentido la propuesta difiere del modelo evolutivo, donde la construcción del prototipo se realiza solo en las etapas iniciales. Un prototipo construido de manera temprana implica una implementación parcial o total de las funcionalidades requeridas por el software, por medio de algoritmos y/o estructuras de datos simples, prestando poca atención a su eficiencia. A medida que el proyecto evoluciona, los requerimientos de buena calidad ganan importancia. En la etapa final, cuando todas las funcionalidades fueron implementadas, la principal preocupación es la de realizar el diseño óptimo de algoritmos y estructuras de datos. Queda claro que se mantiene la idea de utilizar un prototipo para reducir las incertidumbres de especificaciones, el cual se utiliza hasta alcanzar la convergencia definitiva del producto. De manera opuesta a lo que sucede en el enfoque clásico, el último prototipo no se descarta, ya que constituye la
Metodología de Desarrollo de Software para Ingeniería Apéndice A
137
Esta metodología es aplicable debido a que el prototipo progresa hacia un software que cumple con los requerimientos de calidad pero que también resulta eficiente, flexible, de fácil mantenimiento y amigable para el usuario. Para evitar una evolución caótica del software, cada iteración de la metodología incluye dos etapas: la evaluación del usuario y la del programador. La evaluación del usuario está enfocada en el análisis de los requerimientos de funcionalidad, mientras que la evaluación del programador consiste en chequear aspectos técnicos, y debe ser incluida dentro de la descripción de la metodología utilizada, de manera tal de asegurar que la calidad del prototipo mejore continuamente. Finalmente, la etapa de planeamiento le da forma al nuevo prototipo sobre la base de los resultados obtenidos en ambas evaluaciones.