Modelos de ciclo de vida en cascada

Formulados por primera vez por Royce en 1970, los Modelos de ciclo de vida en cascada son secuenciales, basados en las experiencias de otros campos de la ingeniería. También son conocidos como modelos clásicos de ciclo de vida del software.

Las etapas están organizadas de un modo lógico. En general se trata de etapas que generan productos intermedios y cuyo nivel de acercamiento al producto final va creciendo.

Cada etapa incluye una actividad de aceptación para poder pasar a la etapa siguiente. En general, la aceptación se produce sobre la documentación generada en la etapa anterior, los entregables. Por ello, se dice que este modelo de ciclo de vida está dirigido por la documentación. La aceptación debe tener un carácter formal para que el proceso continúe.

Si los entregables de una fase no logran superar el proceso de aceptación, habrá que retroceder en el ciclo de modo que se puedan resolver los problemas encontrados. Desde este punto de vista, el modelo de ciclo de vida en cascada es un modelo iterativo.

El número de etapas varía según el autor que describa el modelo. Puede decirse que el número de fases no es relevante.

En la descripción que se da a continuación se ha utilizado la división en etapas realizada por Roger Pressman.

Fases de modelos de ciclo de vida

Análisis del Sistema
Análisis
Diseño
Codificación
Pruebas
Mantenimiento

La fase de prueba del ciclo de vida donde se prueba el sistema integrado completo supone el último paso de validación del proceso de desarrollo. En este momento se debe demostrar al usuario que el sistema cumple sus requisitos. Pero es importante que la verificación y la validación formen parte de cada una de las fases anteriores del ciclo de vida.

Aunque validación y verificación puedan parecer sinónimos, en realidad suponen diferentes comprobaciones.

  • La verificación comprueba que el producto que se está construyendo cumpla los requisitos.
  • La validación comprueba que las funciones del producto son las que el usuario realmente desea.

También es importante tener en cuenta que, aunque considerar las fases del ciclo de vida como independientes sea útil para la gestión de los proyectos, ésta no es la situación que se produce en la realidad, ya que en la práctica las fases se solapan y realimentan.

Análisis del sistema global

En primer lugar es necesario analizar la totalidad del sistema, que incluye no solamente el software, sino también el hardware, los datos y los recursos humanos.

Es muy importante este planteamiento de sistema, ya que en general el software interacciona con los otros elementos del sistema global.

Por tanto, como resultado de esta fase se obtendrá una definición de los requisitos a nivel del sistema, que serán revisados y aceptados.

Análisis del sistema software

Una vez determinados los requisitos del sistema global, esta fase el análisis consiste en el proceso de recopilación de requisitos centrado especialmente en el software.

Se debe llegar a una comprensión total del software del sistema. En este sentido, es necesario comprender el alcance y ámbito de información del software, así como la función, el rendimiento y las interfaces requeridas.

Los requisitos se deben documentar y revisar con los usuarios del sistema, lo que determina que, en su redacción, se tenga en cuenta que deben ser entendidos tanto por los usuarios, como por el equipo de desarrollo.

Diseño del software

El diseño del software se compondrá en realidad de varios pasos que cubren la definición de cuatro atributos distintos de los programas:

  • Estructura de los datos
  • Arquitectura del software
  • Detalle procedimental
  • Caracterización de la interfaz

En esta fase se deben traducir los requisitos a una representación del software que permita garantizar la calidad requerida antes de que empiece la codificación.

Esta representación se denomina diseño técnico del sistema o especificación de diseño, en función de los autores. Esta documentación de diseño formará parte de la configuración del software.

Codificación

En este paso se traduce el diseño previo en un lenguaje legible para máquina. Si el diseño se ha realizado de forma detallada, la codificación se podrá llevar a cabo mecánicamente.

Pruebas

Cuando ya se ha generado el código se debe probar el programa. Realizando varios tipos de prueba:

Pruebas unitariasSe asegura que cada componente del software funciona correctamente. Pueden ser de dos tipos:

Prueba de la lógica interna: Esta prueba pretende asegurar que se han probado todas las sentencias.

Prueba de las funciones externas: Este tipo de prueba busca la garantía de que los resultados obtenidos son los esperados para cada tipo de entrada.
Pruebas de integraciónEn esta parte se comprueba que no hay problemas de integración de los componentes que forman el software.
Pruebas de sistemaSe verifica que el sistema cubre las funcionalidades previstas.
Pruebas de implantación y aceptaciónEstas pruebas suponen la aceptación final del sistema por los usuarios.

Mantenimiento

Una vez terminado y entregado, el software sufrirá cambios por alguno de los siguientes motivos, tal y como describe la metodología de desarrollo MÉTRICA V.3:

CorrectivoDurante el funcionamiento se detectan errores que deben ser subsanados.
AdaptativoEl programa debe modificarse en el caso de producirse variaciones en el entorno en que funciona.
EvolutivoEl usuario solicita nuevas funcionalidades del sistema.
PerfectivoSe realizan cambios en el software para mejorar las prestaciones del sistema.

Se trata de las acciones llevadas a cabo para mejorar la calidad interna de los sistemas, en cualquiera de sus aspectos: reestructuración del código, definición más clara del sistema y optimización del rendimiento y eficiencia.

El mantenimiento del software seguirá todos los pasos descritos, pero se aplica al programa ya existente, en lugar de aplicarse a uno nuevo.

¡Aprovechate! Ahora puedes profundizar sobre el tema del artículo, con la promoción Kindle Unlimited de Amazon.

Podrás leer gratis todo lo que quieras, durante ¡30 días!.

Inconvenientes

1. La secuencia que hemos descrito, no siempre se puede aplicar a los proyectos. Muchos proyectos no la siguen. De hecho, hay algunas tareas que podrían realizarse en paralelo, como la codificación y algunas pruebas.

2. La necesidad de disponer de la documentación de una fase para empezar la siguiente puede ser un inconveniente en cierto tipo de proyectos. Un ejemplo de aplicaciones en las que un modelo de ciclo de vida regido por la documentación supone una desventaja son las llamadas aplicaciones interactivas.

Los problemas con modelos orientados a documentos son los siguientes:

  • La dirección de la organización normalmente necesita que se produzcan documentos en momentos determinados para asegurar el progreso del proyecto, pero estos tiempos pueden no coincidir con los tiempos requeridos para terminar una actividad, lo que puede llevar a que se produzcan documentos artificiales.

  • La necesidad de aprobar documentos hace que se restrinjan las iteraciones ya que el coste de volver hacia atrás y adaptar un documento es alto.

    Si se encuentran problemas se adoptan soluciones de compromiso para no tener que modificar los documentos ya entregados.

  • La idea de que un documento, producto de una fase, por definición debe actuar de la fase siguiente, presenta ciertos inconvenientes, ya que supone que el proceso de desarrollo es lineal.

    En cualquier fase del proyecto los ingenieros de software tienen en cuenta tanto los pasos anteriores como los futuros. No tiene sentido, por ejemplo, definir un diseño de software que luego no se va a poder implementar por mucho que cumpla los requerimientos.

    Un proceso basado en documentos, tiende a ocultar información de los desarrolladores, ya que supone que sólo tienen que trabajar en los documentos y esto puede incrementar el coste del software.

  • Se requieren tiempos significativos para revisar y validar los documentos y no suele producirse una transición suave de una fase a otras.

    En la realidad, muy frecuentemente se ignoran los requerimientos de transiciones entre fases y se comienzan las actividades de la fase siguiente, antes de que los documentos de la fase previa hayan sido terminados y aceptados.

3. Para que sea verdaderamente efectivo, el modelo de ciclo de vida en cascada requiere la plena determinación y la congelación de los requisitos al comienzo del desarrollo.

4. El usuario no ve nada hasta el final del ciclo. Esto es así porque no hay productos parciales que se asemejen al producto final y que el usuario pueda revisar y aceptar. De este modo, la validación por parte del usuario no se produce hasta el final del ciclo de vida, siendo ésta una fuente de riesgo.

Mejoras posibles al modelo

Existen diversas mejoras que se han propuesto a lo largo de los años de utilización de este modelo que, como se ha dicho, es el más empleado. Se pueden destacar las siguientes:

  • Uso de herramientas CASE
  • Diseño rápido (prototipos) para validar las especificaciones
  • Diseño en grupo que incluya al usuario
  • Análisis de riesgos
  • Autonomía del jefe de proyecto para pasar de una fase a otra o incluso saltar una fase

En lo que respecta a la codificación y las pruebas, se puede mejorar su secuencia mediante la realización de algunas actividades en paralelo.

Para ello, se puede realizar la codificación por orden de nivel creciente, en primer lugar los módulos de más alto nivel y posteriormente, los de bajo nivel. De este modo podrían realizarse codificación y pruebas en paralelo.

Otras mejoras

  • Reutilización de código ya probado
  • Revisiones de código

Artículos relacionados:

error: Content is protected !!