Apunte de Modelos de Ciclo de Vida (Ingeniería II)

De Cuba-Wiki
Saltar a: navegación, buscar
Back.png Volver a la página de la materia

Waterfall[editar]

El modelo waterfall divide en las siguientes etapas secuenciales. Tiene el problema de que supone que no surgen problemas en las iteraciones, con lo que no se puede volver hacia atrás para arreglar. Problemas detectados tempranamente podrian haber mejorado mucho los tiempos de desarrollo. Ademas, no genera entregables en medio del ciclo, involucrando al usuario solamente al principio y al final.

  • Requerimientos de sistema
  • Requerimientos de soft
  • Analisis
  • Diseño del programa
  • Coding
  • Testing
  • Operations

Una mejora es la de Royce, que propone realizar un análisis previo al diseño, similar a como se trabaja con prototipos. Otra versión es la de sashimi, donde hay overlapping entre las distintas etapas. Waterfall con prototipo genera un prototipo para descartar a partir del diseño y luego comienza el verdadero waterfall, aunque tiene el problema de que el prototipo rara vez se descarta.

Waterfall con subproyectos genera múltiples waterfalls a partir del diseño de arquitectura que luego se juntan en una etapa de testing del sistema. Además considera volver hacia atrás en las etapas.

Modelos Iterativos[editar]

Se busca que el usuario vea algo rápidamente. Se itera sucesivas veces incrementando el producto a cada iteración. Permite detección temprana de problemas y reduce su impacto.

El modelo en espiral de Bohem implica que el desarrollo ha de ser incremental, y se debe comenzar implementando las funciones más riesgosas (no necesariamente las más difíciles).

Otra variante es scrum.

Rational Unified Process[editar]

El RUP no es un proceso sino un process framework adaptable a cada proyecto en particular. Está dirigido por casos de uso, centrado en la arquitectura y la construcción guiada por riesgos. Generalmente se usa UML para modelar y documentar. El objetivo de RUP es desarrollar incrementalmente, verificar la calidad y controlar los cambios.

Se tienen 4 fases distinguidas. Al final de cada fase se tiene un hito principal e hitos secundarios al finalizar cada iteración. Cada hito tiene un entregable asociado para su evaluación.

Las disciplinas organizan las actividades del proyecto. Pueden ser de desarrollo o de gestión. Cada disciplina genera distintos modelos UML. Los artefactos, por otro lado, es cualquier tipo de información generada por el equipo de desarrollo. Así, el proceso queda especificado en términos de workers, activities y artifacts.

Incepción[editar]

Una primera fase de incepción que consta de una única iteración, donde se realiza modelado del negocio y análisis de requerimientos. El objetivo es establecer los requerimientos y el alcance del proyecto. Su hito asociado son los lifecycle objectives.

Sus artefactos principales son los modelos de dominio, análisis, diseño y casos de uso, los planes y prototipos, los atributos de calidad, la visión, etc.

Elaboración[editar]

Luego dos iteraciones de elaboración donde predomina el análisis y diseño, y se comienza con la implementación. Se analiza el dominio del problema, se atacan los principales riesgos y elabora un plan más completo. Los artefactos siguen siendo planes y modelos, y se suman prototipos.

Construcción[editar]

Luego se realizan tantas iteraciones de construcción como sean necesarias, donde predomina la implementación, testing y configuration management, y comienza deployment hacia el final. Junto con transición forman la etapa de producción, a diferencia de las dos anteriores que conformaban la de ingenierría.

Transición[editar]

Por último, se tienen dos iteraciones de transición donde se realiza el deployment, que incluye instalación, configuración, entrenamiento, soporte, mantenimiento, etc. No se debe confundir la transición con los ciclos de pruebas internos de cada una de las demás fases.

Las disciplinas de project management y environment están presentes de manera constante a lo largo de todas las fases del proyecto.