Criterios para la selección de un modelo de ciclo de vida de desarrollo de software



Hay distintos modelos de ciclo de vida que son utilizados para el desarrollo de un sistema software, define el orden de las tareas o actividades involucradas, la coordinación entre ellas, su enlace y realimentación. Algunos son mas conocidos y perfectamente estudiados por lo que se sabe sus virtudes y sus carencias. Cada uno es libre de utilizar cualquier tipo ya existente o incluso elaborar uno propio, ya que esto es libre y lo que se va buscando es optimizar el proceso de desarrollo conforme a los requerimientos que se nos piden en el mismo, logrando así desarrollar un programa de mayor calidad.

Los factores que influyen a la hora de elegir un ciclo de vida para resolver un problema son:

  1. Disponibilidad de recursos ya sean económicos, tiempo, equipos, humano, etc.
  2. Entender los requerimientos.
  3. Dominio del problema, si se tiene los conocimientos para dar solución al problema central.
  4. Complejidad y magnitud del proyecto.

Hay distintos tipos de modelos los cuales vamos a enumerar a continuación los mas importantes:


Modelo en cascada:


Si elegimos este modelo implica un previo y absoluto conocimiento de los requisitos. Implica un diseño exacto y sin errores ni probable modificación o evolución ya que no permite retroceder para volver a diseñar. Cualquier cambio implica reiniciar el ciclo completo desde el principio.

Problemas que en ocasiones surgen al aplicar este modelo:

  1. Es raro que los proyectos reales sigan el flujo secuencial propuesto por el modelo. Aunque el modelo lineal acepta repeticiones, lo hace en forma indirecta. Como resultado los cambios generan confusión conforme el equipo del proyecto avanza.
  2. A menudo, es difícil para el cliente enunciar en forma explicita todos los requerimientos. El modelo de la cascada necesita que se haga y tiene dificultades para aceptar la incertidumbre inicial que tienen todos los proyectos.
  3. El cliente tiene que tener paciencia ya que no se le entregara una versión del programa hasta que este esté muy avanzado.

Modelo en V:


Es un modelo similar al modelo en cascada, pero en este caso se agrupan las actividades de análisis en la primera rama de la V y las actividades de la composición en la otra. Tiene muchos módulos que debes comprobar primero por separado y luego al juntarlos. En este modelo ves todo el conjunto no solo lo que estas haciendo.

Comienzas bajando de nivel de abstracción, para a continuación volver a subirlo. Los procesos de verificación se realizan en las zonas de mismo nivel de abstracción.

Modelo de proceso incremental:


Tienen en cuenta la vuelta atrás entre fases del proceso para ir refinándolas, es decir, hacemos un análisis inicial y posteriormente volvemos otra vez al principio para ir añadiéndole cosas.

En este modelo se entrega un primer incremento al usuario y luego se van haciendo nuevas iteraciones hasta finalizarlo.

  1. Planificar los incrementos a dar al usuario.
  2. Dar a cada incremento unos tareas a seguir.
  3. Decidir los principales bloques del programa y saber como conectarlos.

El usuario puede ir viendo si es lo que quiere y poder seguir trabajando. Desde el principio puede ir utilizando el software lo que da la ventaja de que pueda dar su opinión y saber si es realmente lo que buscaba. Los requerimientos entregados se consideran cerrados, a menos que surjan errores. Requiere una participación activa del cliente.

Modelo de prototipado rápido:


Se realizan prototipos cuando no se logra definir lo que quiere el cliente, o el diseño que desea, así rápidamente se sabrá si se trabaja en el camino adecuado. Estos prototipos no pueden llevar mucho esfuerzo ni un gran coste ya que se van a desechar. Los prototipos serán esencialmente fachada, sin realizar las operaciones de manera correcta, incluso en un lenguaje que no sera el que se utilizará posteriormente. Se suele aplicar en métodos como el de cascada.

Modelo de prototipado evolutivo:


Este modelo es similar al modelo de prototipado rápido, pero en este caso el prototipo creado no se desecha, sino que se vuelve a utilizar añadiéndole lo que le falte, volviéndole a entregar al cliente el nuevo prototipo.

Modelo en espiral:


El modelo en espiral se divide en cuatro partes y se pasa por todas en cada una de las iteraciones.

Las partes en las que se divide son las siguientes:

  1. Planificación: Economía, tiempo para realizarlo y los recursos para cada iteracción.
  2. Análisis de riesgos: Evaluar las posibilidades que tenemos y buscar si hay algún software parecido. Identificar posibles riesgos que puedan surgir en un futuro y preparar soluciones.
  3. Ingeniería: Se abordan las tareas propias del proyecto, las actividades estructurales. Es un punto importante ya que incluye todos los pasos anteriores.
  4. Evaluación: Comprobar que todo funciona correctamente y satisface al cliente.

Modelo basado en componentes:


Este modelo se basa en la reutilización de partes de proyectos anteriores, sobre todo de la parte de código fuente, aunque también en diseño, análisis, etc. No tienen porque ser etapas completas, pueden ser partes de estas que las adaptamos a nuestro proyecto.

Puede que los módulos que vayamos a reutilizar no nos sirvan o que tengamos que modificar los mismos pero tenemos la ventaja de que de no ser así no obtendríamos el producto en un tiempo y coste menor.

Modelos de método formal:


Se basa en modelos matemáticos, sobre todo álgebra, para el análisis de requisitos. La ventaja de este modelo es que no da lugar a ambigüedad ya que utilizamos un lenguaje especifico y no un lenguaje natural. No hace falta probarlo introduciendo datos, ya que este directamente se demuestra mediante un proceso de razonamientos que el software esta libre de errores.
Este modelo es valido solo para software de computo no para iteración con el usuario. Suele ser muy complejo por la gran especialización de las matemáticas.

0 comentarios:

Publicar un comentario