Introducción a las metodologías ágiles. Ciclos de vida de desarrollo de Software I

Como continuación del “post” anterior, vamos a destacar las características de los distintos ciclos de vida de desarrollo de Software más destacados. A modo de recordatorio, estos ciclos de vida son:

  • ciclo de vida lineal.
  • ciclo de vida en cascada.
  • ciclo de vida iterativo.
  • ciclo de vida por prototipos.
  • ciclo de vida incremental.
  • ciclo de vida en espiral

En este “post“, como aperitivo, vamos a abordar los tres primeros de la lista. Os animo a introducir vuestros comentarios, que contéis la experiencia que habéis tenido con estos ciclos de vida y cuándo veis útil su utilización.

Antes de comenzar a describir los distintos ciclos de vida, voy a introducir el concepto de ciclo de vida. El ciclo de vida de desarrollo de Software es el conjunto de etapas donde se engloban las distintas actividades a realizar, desde el momento en que surge la idea de crear un nuevo producto software, hasta que el producto deja definitivamente de ser utilizado por el último de sus usuarios, es decir, desde que “nace” hasta que “muere“.

Las etapas de un ciclo de vida de desarrollo de Software se resumen en:

  • Especificación de requisitos. Esta etapa se caracteriza por identificar las necesidades del cliente a nivel funcional y no funcional, de forma que se refleje en detalle las funcionalidades a implementar.
  • Análisis. La etapa de análisis es importante para definir con detalle el conjunto de las funcionalidades del sistema, así como su comportamiento, relaciones entre elementos del sistemas, etc. En general, esta etapa define qué se va a desarrollar.
  • Diseño. La etapa de diseño define en detalle cómo se va a desarrollar el sistema, identificar las entidades de datos (en la base de datos o en sistemas NoSQL), componentes a desarrollar, etc.
  • Implementación. Esta etapa es donde se desarrolla el software definido en la especificación de requisitos, descrito en la fase de análisis y detallado en el diseño.
  • Pruebas. Tras el desarrollo viene el proceso de pruebas donde se verifica el correcto funcionamiento del sistema acorde a lo definido en la etapa de análisis.
  • Validación. Una vez que el sistema pasa la etapa de pruebas, el cliente debe verificar que el sistema cumple las especificaciones de requisitos que describen sus necesidades.
  • Evolución. Esta etapa final del software comienza en el momento que el sistema desarrollado ha sido validado por el cliente y comienza su explotación. Durante esta etapa, los trabajos se centran en la resolución de errores (incidencias) de funcionamiento y en el desarrollo de nuevas funcionalidades detectadas.

Este conjunto de etapas es generalista, de hecho, no todos los ciclos de vida contempla todas las etapas, como por ejemplo, el primer ciclo de vida identificado en nuestra “industria“, el ciclo de vida code & fix. En este caso, los programadores recopilaban los requisitos de los programas que necesitaban los clientes y se ponían a desarrollar de forma no controlada ni gestionada, e iban solventando los errores tanto lógicos como de requisitos sobre la marcha, según iban apareciendo. El proyecto finalizaba cuando se completaban todas las especificaciones, tanto las iniciales como las que surgían por el camino.

Como ventaja de este tipo de ciclo de vida podemos destacar el ahorro en tiempo (y por tanto coste) derivado de las tareas de análisis, planificación, gestión de recursos, documentación. Sin embargo, en contra partida, nos encontramos con que es difícil aplicar este caso cuando se trata de un proyecto complejo. Y además, siendo comprensibles, los clientes actuales requieren mayor control sobre el software desarrollado.

El objetivo de este post no es generar un timeline con los distintos ciclos de vida, aunque considero importante que sepamos de donde partimos, EL CAOS. A partir de aquí, lo importante es identificar las posibilidades con que contamos a la hora de decidir qué tipo utilizar. Por tanto voy a comenzar la descripción de los ciclos de vida enumerados al principio.

Ciclo de vida lineal

El ciclo de vida lineal descomponen todas actividades en etapas separadas que serán realizadas de forma lineal, una detrás de otra. Cada etapa se realiza una sola vez.
Las actividades de cada etapa tienen que ser independientes entre sí. Es importante que no exista retroalimentación entre las etapas, aunque sí deban permitirse pequeñas acciones correctivas.

Ciclo de vida lineal

Desde el punto de vista de la gestión, requiere que se conozca con total detalle las características del software que se desea desarrollar. Es un ciclo de vida excesivamente rígido, que hace necesario disponer de toda la información necesaria antes de comenzar una etapa. Sin embargo, este hecho, minimiza la posibilidad de aparición de errores durante el proceso y reduce al mínimo la necesidad de requerir información del cliente.

El ciclo de vida lineal se utiliza en procesos en los que las actividades están claramente identificadas y no existe probabilidad de cambio en las especificaciones. Sin embargo, no conozco muchos proyectos de este tipo, cada día es más frecuente que el cliente tenga necesidades que impliquen modificar partes del alcance a lo largo del proceso.

Ciclo de vida en cascada

El ciclo de vida en cascada admite iteraciones, al contrario de lo que piensa mucha gente. Sin embargo, es un modelo rígido, poco flexible y con muchas restricciones. A pesar de estas desventajas, este modelo de ciclo de vida a servido de base para otros.

Después de cada etapa, se realiza una o varias revisiones para ver si se puede pasar a la siguiente etapa (cascada puro). Existe una variación del modelo que permite solapar etapas, de forma que se puede avanzar en la siguiente etapa con elementos completamente definidos de la etapa anterior, mientras que se terminan de definir todos los elementos, por ejemplo, mientras que se definen todos los requisitos, es posible comenzar el análisis funcional de los requisitos ya definidos, mientras que se finaliza la anterior fase.

Ciclo de vida en cascada

Una ventaja respecto al ciclo de vida anterior, es que se permite retroalimentación entre las etapas para la resolución de errores o la aclaración de ambigüedades.

La planificación de proyectos basados en este ciclo de vida es sencillo, y está enfocado a proveer un “producto” final de una alta calidad (en teoría), pero es necesario disponer de todos o la mayoría de los requisitos al inicio del proyecto, y la tolerancia a errores es mínima puesto que se detectan en fases tardías y es difícil volver atrás para solucionarlos. Otra desventaja es que no se ven resultados hasta las etapas finales.

Su uso puede ser adecuado en proyectos en los que se dispone de los requisitos al inicio del proceso, y que contenga funcionalidades que se entiendan perfectamente y no sean ambiguas, pues el tiempo necesario para esclarecer dichas funcionalidades o ambigüedades pueden suponer un retraso en el proyecto.

Ciclo de vida iterativo

El ciclo de vida iterativo está basado en el ciclo de vida en cascada y busca reducir el riesgo derivado de la falta de definición o malos entendimientos durante la toma de requisitos.

Este ciclo de vida es la iteración de varios ciclos de vida en cascada, de manera que después de cada iteración se realiza una entrega al cliente del producto mejorado o con mayor funcionalidad. Posteriormente, el cliente evalúa el producto, indicando posibles elementos a corregir y pudiendo proponer mejoras, que serán abordadas en la siguiente iteración. El proceso finalizará cuando se obtenga un producto satisfactorio.

Ciclo de vida iterativo

Como podéis ver este es uno de los principio de Scrum: iteraciones, entregas incrementales, etcétera. Si embargo, Scrum se deshace de los elementos del ciclo de vida de cascada y permite mayor libertad para ajustarse a las necesidades metodológicas reales del proyecto.

About these ads

Acerca de sgnieto

Esto de hablar sobre uno mismo... prefiero que hablemos de T.I. Desde pequeño he preferido y priorizado mi carrera dentro del ámbito de las nuevas tecnologías frente a otro tipo de actividades. No me considero un bicho raro, o "friqui" como muchos denominan a los tecnólogos. Solo soy una persona normal, apasionada por su trabajo y a la que le gusta seguir viendo cómo evoluciona el mundo gracias a las T.I.
Esta entrada fue publicada en Metodologías ágiles y etiquetada , , , , . Guarda el enlace permanente.

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s