Qu es el proceso unificado?

El Proceso Unificado es un proceso de desarrollo de software. Por lo que un proceso de desarrollo de software es un conjunto de actividades necesarias para transformar los requerimientos del usuario en un sistema de software.

Esta dirigido por casos de uso, centrado en la arquitectura y es iterativo e incremental. El refinamiento ms conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP.

El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos especficos.

Caractersticas generales del Proceso Unificado

Soporta tcnicas orientadas a objeto, por lo que se basa en los conceptos de clase y objeto y las relaciones entre ellos, usando UML como notacin comn.

Es una metodologa que sigue un proceso iterativo e incremental.

El PU est dirigido por el riesgo. Esta es una de las caractersticas fundamentales de este modelo, y propone identificar, afrontar y resolver los elementos de riesgo lo ms pronto posible.

Se utilizan modelos grficos de representacin ms que documentacin, en particular se usan diagramas UML que son representaciones expresivas y pueden aplicarse durante todo el desarrollo.
El PU est centrado en la arquitectura software. EL PU est dirigido por los casos de uso.

Control continuo de la calidad. La filosofa del Proceso Unificado es empezar a trabajar en el desarrollo con un conocimiento relativo del problema, a partir de l se hacen los primeros diagramas.

FASES DEL PROCESO UNIFICADO

FASE 1. INICIO. FASE 2. ELABORACION. FASE 3. CONSTRUCCION. FASE 4. TRANSICIN.

FASE 1. INICIO.

Tiene como objetivo determinar si se merece la pena desarrollar el sistema en estudio (estudiar su viabilidad). Por lo tanto, durante esta fase se establecen los objetivos del proyecto, se realiza su la planificacin y se determina su alcance. Al hacer la planificacin hay que considerar: los criterios de xito del proyecto; hacer una adecuada estimacin de recursos; hacer una evaluacin del riesgo; y definir un plan de trabajo, identificando los diversos hitos del proyecto.

FASE 2. ELABORACION.

Se establece una base arquitectnica slida para el sistema sobre la que se asentar la fase de construccin. Las decisiones sobre la arquitectura del sistema se deben tomar considerando el proyecto de un modo global. Esto supone describir los requisitos fundamentales del sistema y de mayor peso identificados en fases anteriores. Tambin se tendr que hacer una evaluacin de los riesgos. Para verificar que la arquitectura implementa un sistema (prototipo de la arquitectura) que demuestre las posibilidades de la arquitectura y ejecute los casos de uso ms significativos.

Sus objetivos se pueden enumerar de la siguiente manera: 1. Analizar el dominio del problema: esto supone refinar los requisitos iniciales (expresados en el diagrama de casos de uso). Se realiza dentro del flujo de trabajo de requisitos. 2. Eliminar (o resolver) los elementos de ms alto riesgo del proyecto: es decir, refinar sus prioridades. Se realiza dentro del flujo de trabajo de anlisis. 3. Desarrollar el plan de trabajo para el proyecto

FASE 3. CONSTRUCCION.

En esta fase se desarrolla iterativamente y de modo incremental un producto completo preparado para la siguiente fase. Esto supone describir los restantes objetivos, los criterios de aceptacin, y refinado del diseo. Se completan la implementacin y las pruebas. Se describen los requisitos no desarrollados antes y se completa el desarrollo del sistema basndose en la arquitectura definida.

FASE 4. TRANSICIN.

Se aseguran que los requisitos se han cumplido y que el software est disponible para los usuarios finales. Por eso esta fase est dirigida por la retroalimentacin de los usuarios, a partir de la informacin que se deduzca de la versin beta del sistema en funcionamiento. Para ello: Se corrigen los fallos que hubiera para lo cual se realizan las pruebas. Se determinan los elementos que deban ajustarse (problemas no detectados, refinamiento y mejora de algunas caractersticas) con un desarrollo adicional.

Se actualiza la documentacin correspondiente.

Se deben descubrir anteriormente. riesgos no detectados