Etapas, fases y/o procesos que propone la misma.


 Las Fases Comprenden la Primera División del Trabajo.


Un sistema software pasa por varios ciclos de desarrollo a lo largo de su tiempo de vida. Asimismo, cada uno de estos pasos da como resultado una nueva entrega del producto a clientes y usuarios, pudiendo ser, la primera de estas entregas, muy probablemente, la más difícil.
Los desarrolladores dividen el trabajo, algo potencialmente complejo como un todo, en partes mas pequeñas y comprensibles. El primer paso hacia la división del proceso de software consiste en separar las partes en cuatro fases atendiendo al momento en que se realizan: inicio, elaboración, construcción y transición.

1) Fase de Inicio.

            El objetivo principal de esta fase es establecer el análisis del negocio. La fase de inicio no es  un estudio completo del sistema, sino que en ella buscamos  el porcentaje de casos  de uso necesarios  para fundamentar  el análisis del negocio inicial. Para llevar  este análisis seguimos cuatro pasos:

     a. Delimitar el ámbito del sistema propuesto.
     b. Describir  o esbozar  una propuesta de la arquitectura de sistema y en especial aquellas partes del sistema que son nuevas.
     c. Identificar riesgos críticos.
     d. Demostrar a usuarios o clientes potenciales  que el sistema propuesto  es capaz de solventar  sus problemas o de mejorar sus objetivos  de negocio construyendo un propósito.

          Hasta aquí,  se ha realizado una primera versión del análisis del negocio.

  2) La Fase de Elaboración centrada en la Factibilidad.
           
            Esta fase lleva el estudio del sistema propuesto al punto de planificar la fase de construcción con gran precisión. Con estos dos grandes objetivos (la arquitectura y la estimación de costes con gran precisión) el equipo hace lo siguiente:

     a.  Crea una linea base para la arquitectura que cubre la funcionalidad del sistema significativa arquitectónico y las características importantes para las personas involucradas.
     b.  Identifica los riesgos significativos, es decir, los riesgos que podrían perturbar los planes, costes y planificaciones, reduciéndolas a actividades que puedan ser medidas y presupuestadas.
     c.  Especifica  los niveles a alcanzar por los atributos de calidad, como la fiabilidad y los tiempos de respuesta.
     d. Recopila casos de uso para aproximadamente el 80%  de los requisitos funcionales, suficiente para planificar la fase de construcción.
     e. Prepara una  de la planificación  cubierta, personal necesario y de los costes.

 3) La Fase de Construcción Construye el Sistema.

            El objetivo principal de la fase de construcción viene indicado por su tarea fundamental: la capacidad de operación inicial. Entre las actividades de la fase de Construcción tenemos:

     a. La extensión de la identificación , descripción y realización de casos de uso a todos los casos de uso.
     b. La finalización del análisis , del diseño, de la implementación, y de la prueba.
     c. El mantenimiento de la integridad de la arquitectura, modificándola cuando sea necesario.
     e. La monitorización de los riesgos críticos y significativos arrastrados desde las dos primeras fases y su mitigación  si se materializan.

 4) La fase de Transición.

             La fase se inicia  a menudo con la  entrega  de una versión  beta del sistema. Entre las actividades  de la transición se incluyen:

     - Preparar las actividades, así como la preparación del lugar.
     - Aconsejar al cliente  sobre la actualización  del entorno en los que supone que el software va a           funcionar.
     - Preparar los manuales y otros documentos  para la entrega del producto.
     - Ajustar el software para que funcione con los parámetros actuales del entorno  del usuario.
     - Corregir lo defectos encontrados a lo largo de las pruebas realizadas  a la versión beta.
     - Modificar el software al detectar problemas  que no habían sido previstos.

            La fase de transición termina con la entrega del producto final. No obstante, antes de que el equipo del proyecto abandone el mismo, los lideres del equipo llevan a cabo  un estudio del sistema con los siguientes objetivos.

     - Encontrar, discutir, evaluar y registrar las "lecciones aprendidas" para referencias futuras.
     - Registrar asuntos útiles  para la entrega o versión siguiente.





Bibliografía consultada:

     - Jacobson, Booch, Rumgaugh. Año: 2000. "El proceso unificado de desarrollo de Software" - Cap. 12, 13, 14.














Entradas más populares de este blog

Ventajas y desventajas del Proceso Unificado

Empresas que usan esta metodología

Planteo y presentación de un ejercicio práctico sencillo