U2. Ciclos de vida de la ingeniería de software

No existe ninguna metodología para hacer frente con éxito a cualquier proyecto de desarrollo de software. Toda metodología debe ser adaptada al contexto del proyecto.

Históricamente las metodologías clásicas han tratado de abordar la mayor cantidad de situaciones de contexto del proyecto, exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en proyectos pequeños y con requisitos muy cambiantes. Las metodologías ágiles ofrecen una solución casi a medida para una gran cantidad de proyectos que tienen estas características. Una de las cualidades más destacables en las metodologías ágiles es su sencillez, tanto en su aprendizaje como en su aplicación, reduciendo así los costes de implementación en un equipo de desarrollo. Esto ha llevado hacia un interés creciente en las metodología ágiles. Sin embargo hay que tener presente que están dirigidas a equipos pequeños o medianos (pero existen alternativas como LeSS), el entorno físico debe ser un ambiente que permita la comunicación y colaboración entre todos los miembros del equipo, y debe hacerse uso de tecnologías que tengan un ciclo rápido de retroalimentación.

Algunos Modelos de ingeniería de software

Modelo en cascada

Es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software de forma que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior. El modelo en cascada es un proceso de desarrollo secuencial en el que el desarrollo se ve fluyendo hacia abajo sobre las fases que componen el ciclo de vida. Fases:

• Especificación de requisitos
• Diseño
• Construcción
• Integración
• Pruebas
• Instalación
• Mantenimiento

Modelo en V

Éste modelo se desarrolló para terminar con algunos de los problemas que se vieron en el enfoque de cascada. El modelo en V dice que las pruebas necesitan empezarse lo más pronto posible en el ciclo de vida, y que hay una variedad de actividades que se han de desarrollar antes del fin de la fase de codificación. Se ilustra cómo las actividades de prueba (verificacion y validacion) se pueden integrar en cada fase del ciclo de vida.

El modelo en V describe las actividades y resultados que han de ser producidos durante el desarrollo del producto. La parte izquierda de la V representa la descomposición de los requisitos y la creación de las especificaciones del sistema; el lado derecho representa la integración de partes y su verificación.

Modelo en espiral

El desarrollo en espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985. Las actividades se conforman en un espiral, cada bucle representa un conjunto de actividades que no están fijas a priori, sino que las siguientes se eligen en función del análisis de riesgos, comenzando por el bucle anterior. El modelo tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas de desarrollo, se opta por la de riesgos más asumibles y se hace un ciclo de la espiral. Si el cliente requiere seguir haciendo mejoras, se repite el análisis de alternativas y riesgos, y se hace otro ciclo de la espiral.

ISO/IEC 12207

Esta norma define un modelo de ciclo de vida como un marco de referencia común, con una terminología bien definida a la que puede hacer referencia la industria del software. Contiene procesos, actividades y tareas para aplicar durante la adquisición de software, y durante el suministro, desarrollo, operación y mantenimiento de los productos de software.

Esta norma agrupa las actividades que pueden llevarse a cabo durante el ciclo de vida del software en cinco procesos principales (adquisición, suministro, desarrollo, operación, mantenimiento), ocho procesos de apoyo (documentación, gestión de la configuración, aseguramiento de la calidad, verificación, validación, revisión conjunta, auditoria, resolución de problemas), y cuatro proceso organizativos (gestión, infraestructura, mejora, recursos humanos). Cada proceso está dividido en actividades, y cada actividad en tareas.

Modelo evolucionario

También conocido como desarrollo rápido de aplicaciones ( Rapid Application Development, RAD), se basa tradicionalmente en el uso de prototipos. Un prototipo de software se considera como un medio para especificar los requisitos y un enlace de comunicación entre el usuario final y el diseñador, lo que reduce el riesgo de carecer de requerimientos iniciales completos y estables.

Alguna creencias del modelo evolucionario son:

• Se entrega temprano parte de un sistema, aunque no estén completos todos los requerimientos.
• Se permite entregar parte del sistema como herramienta para la generación de requerimientos faltantes.
• Se obtienen beneficios para el sistema mediante entregas iniciales, mientras las entregas posteriores están en desarrollo.