Modelos de Ciclo de Vida en el Desarrollo de Software

Modelo de Ciclo de Vida en Cascada

El modelo en cascada sigue una secuencia estricta de fases:

1. Requisitos
2. Diseño
3. Construcción
4. Pruebas
5. Mantenimiento

La cascada se caracteriza por su secuencialidad en las fases. El sistema se entrega completo al final del proyecto. El estado del proyecto es visible en todo momento. Este modelo asume que los requisitos son estables durante todo el proceso.

Los límites entre fases son muy rígidos y esto puede provocar que los errores se propaguen fácilmente.

Es el modelo más antiguo. En este modelo, el concepto de fase se mantiene. En los modelos antiguos, las actividades no se limitaban a una fase, sino que tenían lugar en varias de ellas, avanzando mediante iteraciones.

Ciclo de Vida Iterativo

Es un proceso de desarrollo de software creado en respuesta a las debilidades del modelo tradicional de cascada.

Este modelo de desarrollo es un conjunto de tareas agrupadas en pequeñas etapas repetitivas (iteraciones). Es uno de los más utilizados, ya que se relaciona con estrategias de desarrollo del software y una programación extrema, siendo empleado en metodologías diversas.

El análisis de cada iteración permite identificar puntos de mejora que se pueden incorporar en las iteraciones posteriores.

La gestión de riesgos es más precisa. Al iniciar la planificación, se dispone de una visión de los riesgos a los que se enfrenta el equipo en cada iteración.

Los procesos cíclicos aportan un margen de flexibilidad extra.

Ventajas del Desarrollo Iterativo

1. En cada iteración se pueden comprobar los avances y el beneficio que reporta.
2. El riesgo que se asume es pequeño. Si hay algún impedimento, se puede solventar en la siguiente iteración.
3. El gap entre lo planeado y lo ejecutado se minimiza con la sucesión de las pequeñas iteraciones.
4. La complejidad del proyecto se diluye en partes pequeñas y menos complejas.
5. El conocimiento sobre el producto es creciente y progresivo, sin necesidad de tener una visión detallada de cada parte al principio del desarrollo.

Debilidades del Desarrollo Iterativo

1. Implica tener un cliente involucrado durante todo el desarrollo.
2. La relación con el cliente debe basarse en principios éticos y una colaboración mutua.
3. Infunde gran responsabilidad en el equipo de desarrollo.
4. En el desarrollo del producto, los requerimientos previamente definidos y cerrados pueden cambiar notablemente.

Ciclo de Vida en Espiral

Es una combinación del ciclo de vida en cascada y el modelo iterativo.

Las fases por las que pasa cada ciclo de la espiral son:

• Planificación: Se determinan los objetivos y el alcance del ciclo. Con cada iteración, se incrementará el tamaño del software y su funcionalidad.
• Análisis de Riesgo: Se evalúa todo aquello que pueda afectar al proyecto. Para ello, se diseñan los prototipos que deberán ser validados en el ciclo.
• Implementación: Se desarrolla y valida el software, el cual está relacionado y condicionado con el análisis de riesgos anterior.
• Evaluación: Antes de pasar a la siguiente iteración, se debe analizar si los riesgos detectados anteriormente ya se solucionaron. Esta fase sirve para determinar el avance del proyecto.

Ventajas del Modelo en Espiral

• Los factores de riesgos son reducidos.
• El desarrollo es iterativo y se pueden incorporar funcionalidades progresivamente.

Inconvenientes del Modelo en Espiral

• La duración de la ejecución no es concreta.
• Fallos en el análisis de riesgos podrían influir negativamente a todo el proyecto.

Fundamentos de la Ingeniería de Requisitos

Factores que Influyen en los Requisitos

• Complejidad del problema a resolver.
• Factores relacionados con el cliente.
• Dificultades de comunicación.
• Existencia de requisitos ocultos.

Tipos de Requisitos

Requisitos Funcionales

Definen las funciones, servicios o tareas a llevar a cabo. Son, en general, más fácilmente verificables.

Requisitos No Funcionales

Definen los aspectos técnicos que debe incluir el sistema desarrollado.

• Restricciones: Limitaciones a las que se enfrentan los desarrolladores del sistema (Ej: el sistema operativo del entorno del usuario).
• Calidades: Características que importan a los clientes y usuarios, relevantes para su satisfacción con el sistema final (rendimiento, fiabilidad o disponibilidad del sistema). En general, son más difíciles de validar.

Clasificación de Requisitos No Funcionales

• Requisitos del Producto: Detallan limitaciones o comportamientos exigidos al producto resultante del desarrollo (Ej: Cantidad de memoria requerida, velocidad de respuesta en operaciones interactivas).
• Requisitos de la Organización: Relacionados con las normativas de funcionamiento de la organización que lleva a cabo el desarrollo, sus procedimientos y políticas (Ej: Estándares de desarrollo, documentación a entregar junto con el producto, plazos de entrega).
• Requisitos Externos: Cubren aspectos externos al sistema y a su proceso de desarrollo (Ej: Interoperabilidad con otros sistemas, requisitos legales).

Proceso de Gestión de Requisitos

Obtención

Objetivo: Establecer las fronteras del futuro sistema.

Acciones a llevar a cabo:

1. Determinar las fuentes de información de las que se obtendrán los requisitos.
2. Establecer las técnicas de obtención de requisitos a utilizar (Ej: Entrevista y cuestionarios, prototipos, escenarios, sistemas existentes, tormentas de ideas, etc.).

Análisis

Objetivo: Descubrir las tareas que deben llevarse a cabo para examinar los requisitos, delimitarlos y definir exactamente cada uno.

Acciones a llevar a cabo:

1. Detectar y resolver conflictos entre requisitos.
2. Delimitar el software y establecer con qué elementos externos interactúa.
3. Elaborar los requisitos del sistema para obtener, a partir de ellos, los requisitos del software a desarrollar.

Este proceso enlaza la definición de alto nivel del sistema desde la perspectiva del usuario –externa–, con el diseño del software que permitirá implementar dicho sistema –interna–.

Visión simplista: el proceso consiste exclusivamente en realizar un modelo conceptual de los requisitos. Sin embargo, el modelado es importante, pero no es la única tarea:

• Clasificación de los requisitos.
• Diseño de la arquitectura del sistema y situación de requisitos en la misma.
• Toma de decisiones de compromiso en los casos de conflictos entre varios requisitos (negociación).

Especificación

Objetivo: Describir completamente los requisitos del sistema a desarrollar.

Implica con frecuencia la construcción de un modelo (o varios) del sistema a construir desde el punto de vista de los usuarios del sistema, que incluya los requisitos obtenidos.

De manera generalizada, los requisitos se plasman en un documento denominado Especificación de Requisitos del Software (SRS).

• Importancia: Documento contractual.

En proyectos complejos, se suelen manejar 3 documentos:

• Documento de definición del sistema.
• Documento de requisitos del sistema.
• Especificación de requisitos del software (SRS).

Modelado de los Requisitos

Parte de la especificación.

En un modelado conceptual, cada entidad se corresponde de manera unívoca con un objeto en el mundo real. A menudo se plasman en modelos visuales.

Para crear estos modelos es necesario un lenguaje y un conjunto de reglas que establezcan cómo se han de usar los elementos del lenguaje (Ej: casos de uso, diagramas de clases de análisis UML, diagramas Entidad-Relación, notaciones formales).

Validación

Objetivo: Examinar si los documentos de requisitos definen el software que los usuarios esperan y no otro.

Un grupo de revisores con representación de los actores más significativos cumplimenta una tabla con sus análisis.

• Objetivo: Buscar errores y contradicciones en los requisitos, descripciones poco claras y desviaciones de las prácticas estándar.

Gestión del Proceso de Requisitos

Seguimiento + Métricas + Herramientas de gestión

Seguimiento: Hace menos probable que el sistema final tenga inconsistencias por culpa de cambios realizados sin un control exhaustivo.

Los requisitos evolucionan iterativamente hasta alcanzar un nivel de calidad y detalle suficiente que permita iniciar los trabajos de diseño de las funcionalidades que les dan soporte.

Para facilitar la comprensión completa de todos los aspectos asociados con los requisitos, han de definirse líneas base. Una línea base es un conjunto de requisitos que deberá contener una entrega del producto.

Seguimiento de los Requisitos

Matriz de seguimiento: Tabla donde se relacionan dos documentos, los cuales pertenecen probablemente a etapas distintas del desarrollo.

• Su utilización más frecuente es seguir la pista de los requisitos a lo largo de todo el desarrollo.
• Fundamentalmente en diseño, plan de pruebas y casos de prueba.
• Hace corresponder los requisitos con los componentes software que los implementarán, y especialmente con los casos de prueba.

Métricas de Requisitos

Es posible tomar medidas de los requisitos software que indiquen el alcance del proyecto, su crecimiento potencial, su estabilidad y progreso. Las medidas de requisitos son únicas: caracterizan el espacio del problema. Otras medidas del desarrollo caracterizan el espacio de la solución.

Herramientas de Requisitos

El tamaño y complejidad de los desarrollos ha convertido el uso de herramientas en algo esencial.

Las herramientas de gestión de requisitos:

• Facilitan un modo de seguimiento de los cambios que se producen durante el ciclo de vida del proyecto.
• Permiten automatizar algunas de las tareas relacionadas con los cambios y el seguimiento de requisitos (Ej: identificación, medición).
• Mejoran la productividad y la calidad en el desarrollo.