El proceso unificado

El proceso unificado (PU) es un intento encaminado a reunir los mejores rasgos y caractersticas de modelos de procesos de software, pero los caracteriza de manera que implementa muchos de los mejores principios del desarrollo gil de software. El proceso unificado reconoce la importancia de la comunicacin con el cliente y los mtodos encaminados a describir el punto de vista del cliente con respecto a un sistema (por ejemplo, el caso de uso). El PU enfatiza el importante papel de la arquitectura de software, y ayuda al arquitecto a enfocarse en las metas correctas, como el entendimiento, el ajuste a los cambios futuros y la reutilizacin. Sugiere un flujo de proceso iterativo e incremental y que proporciona el sentido evolutivo esencial en el desarrollo del software moderno

Fases del proceso unificado

Se han analizado cinco actividades genricas del marco de trabajo y se ha explicado que stas se pueden aplicar para describir cualquier modelo de proceso del software. El proceso unificado no es la excepcin.

Inicio
La fase de inicio del PU abarca la comunicacin con el cliente y las actividades de planeacin. Al colaborar con los clientes y usuarios finales se identifican los requisitos de negocios para el software, se propone una arquitectura aproximada para el sistema y se desarrolla un plan para la naturaleza iterativa e incremental del sistema subsiguiente. Los requisitos fundamentales de negocios se describen a travs de un conjunto preliminar de casos de uso que describen cules caractersticas y funciones son deseables para cada clase importante de usuarios. En general, un caso de uso describe una secuencia de acciones que desarrolla un actor cuando ste interacta con el software. Los casos de uso ayudan a identificar el mbito del proyecto y proporcionan una base para la planeacin de ste. En este punto, la arquitectura no es ms que un esquema tentativo de los subsistemas ms importantes y de las funciones y caractersticas que los forman. Despus, la arquitectura se refinar y expandir en un conjunto de modelos que representarn visiones diferentes del sistema. La planeacin identifica recursos, evala los riesgos importantes, define un itinerario y establece una base para las fases que se aplicarn conforme se desarrolle el incremento del software.

Elaboracin
La fase de elaboracin abarca la comunicacin con el cliente y las actividades de modelado del modelo genrico del proceso. La elaboracin refina y expande los casos de uso preliminares que se desarrollaron como una parte de la fase de inicio; adems, expande la representacin arquitectnica para incluir cinco visiones diferentes del software: el modelo de caso de uso, el modelo de anlisis, el modelo de diseo, el modelo de implementacin y el modelo de despliegue. En algunos casos, la elaboracin crea una lnea de base arquitectnica ejecutable que representa un sistema ejecutable con su primer corte. La lnea de base arquitectnica demuestra la viabilidad de la arquitectura, pero no proporciona todas las caractersticas y funciones necesarias para utilizar el sistema. Adems, el plan revisa de manera cuidadosa al

trmino de la fase de elaboracin para asegurar que el mbito, los riesgos y los datos entregados an son razonables. Las modificaciones al plan se deben hacer en este momento.

Construccin
La fase de construccin del PU es idntica a la actividad de construccin definida para el proceso genrico del software. Si se utiliza el modelo arquitectnico como entrada, la fase de construccin desarrolla o adquiere los componentes del software que harn que cada caso de uso sea operativo para los usuarios finales. Lograr esto requiere que los modelos de anlisis y diseo iniciados durante la fase de elaboracin se completen para reflejar la versin final del incremento del software. Todas las caractersticas y funciones necesarias y requeridas del incremento del software se implementan en cdigo fuente. Conforme los componentes estn en proceso de implementacin, se disean y ejecutan pruebas de unidad para cada uno de ellos. Adems, se realizan las actividades de integracin. Los casos de uso se utilizan para derivar un conjunto de pruebas de aceptacin que se ejecutan antes del inicio de la siguiente fase del PU.

Transicin
La fase de transicin del PU abarca las ltimas etapas de la actividad genrica de construccin y la primera parte de la actividad genrica de despliegue. El software se entrega a los usuarios finales para realizar pruebas beta y la retroalimentacin del usuario reporta tanto defectos como cambios necesarios. Adems, el equipo de software crea la informacin de soporte necesaria para el lanzamiento. Al final de la fase de transicin, el incremento de software se convierte en un lanzamiento de software utilizable.

Produccin
La fase de produccin del PU coincide con la actividad de despliegue del proceso genrico. Durante esta fase se monitorea el uso subsiguiente del software, se proporciona el soporte para el ambiente operativo (infraestructura) y se reciben y evalan los informes de defectos y los requerimientos de cambios. Es probable que mientras se realizan las fases de construccin, transicin y produccin ya se hayan iniciado los trabajos para el siguiente incremento del software. Esto significa que las cinco fases del PU no suceden en una secuencia, sino en una concurrencia por etapas. A lo largo de las fases de PU se distribuye un flujo de trabajo de ingeniera del software. En el contexto del PU, un flujo de trabajo es anlogo a un conjunto de tareas. Esto es, un flujo de trabajo identifica las tareas necesarias para completar una accin importante de ingeniera del software y los productos de trabajo que se producen como consecuencia de la realizacin exitosa de tareas. Se debe destacar que no todas las tareas identificadas para un flujo de trabajo del PU se realizan para cualquier proyecto de software. El equipo debe adaptar el proceso para satisfacer sus necesidades.

Productos de trabajo del proceso unificado

INICIO:
Durante la fase de inicio, el propsito es establecer una vision general para el proyecto, identificar un conjunto de requisitos de negocios, formar un caso de uso de negocios para el software y definir los riesgos del proyecto y del negocio que pudieran representar un obstculo para el xito. Desde el punto de vista del ingeniero de software, el producto ms importante generado durante la etapa de inicio es el modelo de caso de uso: una coleccin de casos de uso que describen la forma en que actores externos interactan con el sistema y obtienen valor a partir de ste. En esencia, el modelo de casos de uso es una coleccin de escenarios de uso con plantillas estandarizadas que implican caractersticas y funciones del software mediante la descripcin de una serie de condiciones previas, un flujo de eventos o un escenario, y un conjunto de condiciones exteriores para la interaccin representada. En un inicio los casos de uso describen requisitos al nivel del dominio de negocios. Sin embargo, el modelo de casos de uso se refina y elabora conforme cada fase del PU se ejecuta y sirve como una entrada importante para la creacin de productos de trabajo subsecuentes. Durante la fase de inicio slo se completa entre el 10% y 20% de los casos de uso. Despus de la elaboracin, se ha creado entre un 80% y 90 % del modelo. Productos de trabajo de INICIO: Documento de la visin Modelo inicial de caso de uso Glosario inicial del proyecto Caso inicial de negocio Evaluacin inicial del riesgo Plan de proyecto, fases e iteraciones Modelo del negocio si es necesario Uno o ms prototipos

Elaboracin:
La fase de elaboracin produce un conjunto de productos de trabajo que elabora requisitos, as como descripcin arquitectnica y un diseo preliminar. Cuando el ingeniero de software inicia con el anlisis orientado a objetos, el objetivo primordial es definir un conjunto de clases de anlisis que describan en forma adecuada el comportamiento del sistema. El modelo de anlisis del PU es un producto de trabajo que se desarrolla como consecuencia de esta actividad. Los paquetes de clases y anlisis definidos como una parte del modelo de anlisis se refinan despus en un modelo de diseo, el cual identifica clases de diseo, subsistemas y las interfaces entre los subsistemas. Los modelos de anlisis y diseo expanden y refinan una representacin evolutiva de la arquitectura de software. Adems, en la fase de elaboracin se revisan los riesgos y el plan de proyecto para asegurar que cada uno de ellos conserve su validez.

Productos de trabajo de elaboracin: Modelo de casos de uso Requisitos suplementarios, se incluyen los no funcionales Modelo de anlisis Descripcin de la arquitectura del software Prototipo arquitectnico ejecutable Modelo de diseo preliminar Lista revisada de riesgos Plan de proyecto que incluye: plan de iteracin, flujos de trabajo adaptados, fundamentos, productos tcnicos del trabajo, manual preliminar de usuario.

Construccin
La fase de construccin produce un modelo de implementacin que traduce las clases de diseo en componentes de software que se construirn para ejecutar el sistema y un modelo de despliegue convierte los componentes en el ambiente fsico de computacin. Por ltimo, un modelo de prueba describe las pruebas empleadas para asegurar que los casos de uso se reflejen de manera apropiada en el software que se ha construido. Productos de trabajo de Construccin: Modelo del diseo Componentes del software Incremento integrado del software Plan y procedimiento de pruebas Casos de prueba Documentacin del soporte, manual de usuarios, manuales de instalacin, descripcin del incremento actual.

Transicin
La fase de transicin entrega el incremento de software y evala los productos de trabajo elaborados durante la etapa en que los usuarios finales trabajan con el software. En esta etapa se produce la retroalimentacin proveniente de las pruebas beta y los requerimientos cualitativos de cambio. Productos de trabajo de Transicin: Incremento de software integrado Reportes de las pruebas betas Retroalimentacin general del usuario.

INICIO:
Comunicacin
Antes de que los requisitos del cliente puedan analizarse, modelarse o especificarse, estos deben recopilarse por medio de una actividad de comunicacin (tambin llamada obtencin de requisitos) Para realizar la actividad de comunicacin se presenta a continuacin una serie de tareas que se llevaran a cabo: 1. Identificar al cliente primario y otros participantes 2. Reunirse con el cliente para las preguntas de libre contexto, las cuales definen a. Las necesidades y valores del negocio. b. Las caractersticas y necesidades del usuario final. c. Las salidas visibles que se hayan requerido para el usuario. d. Las restricciones de negocio. 3. Desarrollar un enunciado escrito de una pgina sobre el mbito del proyecto, el cual est sujeto a revisin 4. Revisar el enunciado del mbito con los interesados en el software y ajustarlo segn lo requerido. 5. Colaborar con el cliente y el usuario final para definir: a. Escenarios de uso visible para el cliente con el uso del formato estndar. b. Salidas y entradas resultantes. c. Caractersticas, funciones y comportamientos importantes del software. d. Riesgos de negocios definidos por el cliente. 6. Desarrollar una breve descripcin escrita ( por ejemplo una serie de listas) de escenarios, salidas/entradas, caractersticas/funciones y riesgos. 7. Iterar con el cliente para refinar los escenarios, salidas/entradas, caractersticas/funciones y riesgos. 8. Asignar prioridades definidas por el cliente a cada escenario del usuario, caractersticas, funcin y comportamiento. 9. Revisar toda la informacin recopilada durante la actividad de comunicacin con el cliente y otros participantes, y ajustarla de la forma que se requiera. 10. Prepararse para la actividad de planeacin.

Planeacin
La actividad de comunicacin ayuda a definir sus metas y objetivos generales, sin embargo es distinto a definir un plan para cumplir estos. La actividad de planeacin abarca un conjunto de prcticas tcnicas y de gestin que permiten definir un mapa del camino mientras se viaja a travs de su meta estratgica y objetivos tcticos. Para realizar la actividad de comunicacin se presenta a continuacin una serie de tareas que se llevaran a cabo:

1. 2. 3. 4. 5. 6. 7.

Reevaluar el mbito del proyecto. Evaluar los riesgos. Desarrollar o refinar los escenarios del usuario. Extraer funciones y caractersticas a partir de los escenarios. Definir las funciones y caractersticas tcnicas que forman la infraestructura del software. Agrupar las funciones y caractersticas (escenarios) de acuerdo a la prioridad del cliente. Crear un plan de proyecto con una granularidad gruesa a. Definir el numero proyectado de incrementos de software b. Establecer un calendario general del proyecto c. Establecer las fechas de entrega proyectadas para cada incremento. 8. Crear un plan con granularidad fina para la iteracin actual. a. Definir tareas de trabajo para cada funcin y caracterstica. b. Estimar el esfuerzo para cada tarea de trabajo. c. Asignar responsabilidad para cada tarea de trabajo. d. Definir los productos de trabajo que sern producidos. e. Identificar los mtodos para el aseguramiento de la calidad que se usaran. f. Describir los mtodos para el cambio en la gestin. 9. Rastrear el progreso de manera regular a. Observar las tareas problemticas (por ejemplo el desfase de calendario). b. Hacer los ajustes que se requieran.

ELABORACIN:
Comunicacin
Antes de que los requisitos del cliente puedan analizarse, modelarse o especificarse, estos deben recopilarse por medio de una actividad de comunicacin (tambin llamada obtencin de requisitos) Para realizar la actividad de comunicacin se presenta a continuacin una serie de tareas que se llevaran a cabo: 1. Identificar al cliente primario y otros participantes 2. Reunirse con el cliente para las preguntas de libre contexto, las cuales definen a. Las necesidades y valores del negocio. b. Las caractersticas y necesidades del usuario final. c. Las salidas visibles que se hayan requerido para el usuario. d. Las restricciones de negocio. 3. Desarrollar un enunciado escrito de una pgina sobre el mbito del proyecto, el cual est sujeto a revisin 4. Revisar el enunciado del mbito con los interesados en el software y ajustarlo segn lo requerido.

5. Colaborar con el cliente y el usuario final para definir: a. Escenarios de uso visible para el cliente con el uso del formato estndar. b. Salidas y entradas resultantes. c. Caractersticas, funciones y comportamientos importantes del software. d. Riesgos de negocios definidos por el cliente. 6. Desarrollar una breve descripcin escrita ( por ejemplo una serie de listas) de escenarios, salidas/entradas, caractersticas/funciones y riesgos. 7. Iterar con el cliente para refinar los escenarios, salidas/entradas, caractersticas/funciones y riesgos. 8. Asignar prioridades definidas por el cliente a cada escenario del usuario, caractersticas, funcin y comportamiento. 9. Revisar toda la informacin recopilada durante la actividad de comunicacin con el cliente y otros participantes, y ajustarla de la forma que se requiera. 10. Prepararse para la actividad de planeacin.

Modelado
Los modelos se crean para obtener un mejor entendimiento de la entidad real que se construir. Para el caso del software este debe ser capaz de representar la informacin que el software transforma, la arquitectura y las funciones que permiten que ocurra la transformacin, las caractersticas que desean el usuario, y el comportamiento del sistema conforme se realiza la transformacin. En este caso se crearan dos clases de modelos: Los modelos de anlisis: representan los requisitos del cliente al presentar el software en tres dominios diferentes: el dominio de la informacin, el dominio funcional y el dominio del comportamiento. Los modelos de diseos: representan caractersticas del software que ayudan a los profesionales a construirlo de manera efectiva: la arquitectura, la interfaz de usuario, y el detalle a nivel de componentes.

Modelo de anlisis
Para realizar la actividad de modelado de anlisis se presenta a continuacin una serie de tareas que se llevaran a cabo: 1. Revisar los requisitos del negocio, las caractersticas/necesidades del usuario, las salidas visibles para el usuario, las restricciones del negocio, y otros requisitos tcnicos que se hayan determinado durante las actividades de comunicacin con el cliente y de planeacin. 2. Expandir y refinar los escenarios del usuario: a. Definir a todos los actores. b. Representar la forma en que los actores interactan con el software. c. Extraer funciones y caractersticas a partir de los escenarios del usuario.

3.

4.

5.

6.

7.

d. Revisar los escenarios del usuario para verificar que estn completos y su exactitud Modelar el dominio de la informacin: a. Representar todos los objetos importantes de informacin. b. Definir los atributos para cada objeto de informacin c. Representar las relaciones entre los objetos de informacin Modelar el dominio funcional: a. Mostrar la forma en que las funciones modifican los objetos de datos. b. Refinar las funciones para proporcionar los detalles de la elaboracin c. Escribir una narracin del procesamiento que describa cada funcin y subfuncin. d. Revisar los modelos funcionales. Modelar el dominio del comportamiento: a. Identificar los eventos externos que ocasionan cambios en el comportamiento dentro del sistema. b. Identificar los estados que representan cada forma de comportamiento observable desde el exterior. c. Presentar el modo en que un evento lleva al sistema a cambiar de un estado a otro d. Revisar los modelos de comportamiento. Analizar y modelar la interface del usuario: a. Dirigir el anlisis de tareas. b. Crear prototipos de la imagen en pantalla. Revisar todos los modelos en cuanto a que estn completos. Sus consistencias y las omisiones.

Modelado del diseo

Para realizar la actividad de modelado de diseo se presenta a continuacin una serie de tareas que se llevaran a cabo: 1. Utilizar el modelo de anlisis, seleccionar un estilo arquitectnico apropiado para el software. 2. Dividir el modelo de anlisis en subsistemas de diseo y ubicar estos dentro de la arquitectura: a. Tener la certeza de que cada subsistema es coherente en el sentido funcional. b. Disear interfaces de subsistemas. c. Ubicar las clases o funciones de anlisis para cada subsistema. d. Mediante la utilizacin del modelo del dominio de la informacin, disear estructuras de datos apropiadas. 3. Disear la interfaz de usuario: a. Revisar los resultados del anlisis de tarea. b. Especificar la secuencia de accin con base con los escenarios de usuario. c. Crear un modelo de comportamiento de la interfaz. d. Definir los objetos de la interfaz y mecanismos de control.

e. Revisar el diseo de la interfaz y ajustarlo como sea necesario. 4. Conducir el diseo al nivel de componente: a. Especificar todos los algoritmos en un grado relativamente bajo de abstraccin. b. Refinar la interfaz de cada componente. c. Definir las estructuras de datos en el nivel de componente. d. Revisar el diseo en el nivel de componentes. 5. Desarrollar un modelo de despliegue

CONSTRUCCIN
Construccin
La actividad de construccin abarca una serie de tareas de codificacin y realizacin de pruebas que conducen al software operativo a estar listo para entregarlo al cliente o usuario final. La codificacin puede ser: 1. La creacin directa de cdigo fuente en un lenguaje de programacin. 2. La generacin automtica de cdigo fuente al utilizar una representacin intermedia del diseo del componente que ser construido. 3. La generacin automtica de cdigo mediante un lenguaje de programacin de cuarta generacin. Para en este desarrollo se ocupara el lenguaje de Visual C# y SQL 2008 Enterprise (lenguajes de cuarta generacin) con cdigo en parte generado automticamente y en parte por creacin directa para cumplir los requisitos a alcanzar. El enfoque de las pruebas est al nivel de componentes, con frecuencia llamada pruebas de unidad. Los otros niveles de prueba incluyen: 1. Pruebas de integracin (realizadas mientras el sistema est en construccin). 2. Pruebas de validacin las cuales evalan si los requisitos han sido satisfechos para el sistema completo. 3. Pruebas de aceptacin, que realiza el cliente en un esfuerzo encaminado a ejercitar las caractersticas y funciones.

Codificacin
Para realizar la actividad de construccin en la codificacin se presenta a continuacin una serie de tareas que se llevaran a cabo: 1. Construir la infraestructura arquitectnica: a. Revisar el diseo arquitectnico. b. Codificar y probar los componentes que forman la infraestructura arquitectnica. c. Adquirir patrones arquitectnicos reutilizables. d. Probar la infraestructura para asegurar la integridad de la interfaz. 2. Construir un componente del software:

a. Revisar el diseo al nivel de componente b. Crear una serie de pruebas de unidad para el componente c. Codificar las estructuras de datos y la interface del componente. d. Codificar los algoritmos internos y las funciones de procesamientos relacionadas. e. Revisar el cdigo conforme ste se escribe. f. Buscar la exactitud. g. Asegurarse que se han mantenido los estndares de codificacin. h. Asegurarse que el cdigo se documenta a s mismo. 3. Realizar pruebas de unidad al componente: a. Dirigir todas las pruebas de unidad. b. Corregir los errores descubiertos c. Aplicar de nuevo las pruebas de unidad 4. Integrar el componente terminado a la infraestructura arquitectnica.

Pruebas
Para realizar la actividad de construccin en las pruebas se presenta a continuacin una serie de tareas que se llevaran a cabo: 1. Disear pruebas de unidad para cada componente del software: a. Revisar cada prueba de unidad para asegurar una cobertura apropiada b. Dirigir la prueba de unidad c. Corregir los errores descubiertos d. Aplicar de nuevo las pruebas de unidad 2. Desarrollar una estrategia de integracin: a. Establecer el orden y la estrategia que se usara para la integracin b. Definir las construcciones y las pruebas requeridas para ejercitarlas. c. Dirigir pruebas de humo a diario d. Dirigir pruebas de regresin cada vez que sea necesario 3. Desarrollar una estrategia de validacin a. Establecer los criterios de validacin. b. Definir las pruebas requeridas para validar el software 4. Dirigir las pruebas de integracin y validacin a. Corregir los errores descubiertos b. Aplicar de nuevo las pruebas cada vez que sea necesario 5. Dirigir las pruebas con mucho orden a. Realizar las pruebas de recuperacin b. Realizar las pruebas de seguridad c. Realizar las pruebas de tensin d. Realizar las pruebas de desempeo 6. Coordinar con el cliente las pruebas de aceptacin.

TRANSICIN:
Pruebas
Para realizar la actividad de construccin en las pruebas se presenta a continuacin una serie de tareas que se llevaran a cabo: 7. Disear pruebas de unidad para cada componente del software: a. Revisar cada prueba de unidad para asegurar una cobertura apropiada b. Dirigir la prueba de unidad c. Corregir los errores descubiertos d. Aplicar de nuevo las pruebas de unidad 8. Desarrollar una estrategia de integracin: a. Establecer el orden y la estrategia que se usara para la integracin b. Definir las construcciones y las pruebas requeridas para ejercitarlas. c. Dirigir pruebas de humo a diario d. Dirigir pruebas de regresin cada vez que sea necesario 9. Desarrollar una estrategia de validacin a. Establecer los criterios de validacin. b. Definir las pruebas requeridas para validar el software 10. Dirigir las pruebas de integracin y validacin a. Corregir los errores descubiertos b. Aplicar de nuevo las pruebas cada vez que sea necesario 11. Dirigir las pruebas con mucho orden a. Realizar las pruebas de recuperacin b. Realizar las pruebas de seguridad c. Realizar las pruebas de tensin d. Realizar las pruebas de desempeo 12. Coordinar con el cliente las pruebas de aceptacin.

Despliegue
Esta actividad abarca 3 acciones: 1. Entrega: Cada ciclo de entrega le proporciona al cliente y a los usuarios finales un incremento de software operativo que provee de funciones y caractersticas tiles. 2. Soporte: Cada ciclo de soporte proporciona documentacin y asistencia humana para todas las funciones y caractersticas introducidas durante todos los ciclos de despliegue que se han presentado hasta la fecha. 3. Retroalimentacin: Cada ciclo de retroalimentacin ofrece una gua importante que conduce a modificaciones en las funciones, caractersticas y el enfoque que se toma para el siguiente incremento.

PRODUCCIN
Despliegue
Esta actividad abarca 3 acciones: 4. Entrega: Cada ciclo de entrega le proporciona al cliente y a los usuarios finales un incremento de software operativo que provee de funciones y caractersticas tiles. 5. Soporte: Cada ciclo de soporte proporciona documentacin y asistencia humana para todas las funciones y caractersticas introducidas durante todos los ciclos de despliegue que se han presentado hasta la fecha. 6. Retroalimentacin: Cada ciclo de retroalimentacin ofrece una gua importante que conduce a modificaciones en las funciones, caractersticas y el enfoque que se toma para el siguiente incremento. Para realizar la actividad de despliegue se presenta a continuacin una serie de tareas que se llevaran a cabo: 1. Crear medios de entrega: a. Ensamblar y probar todos los archivos ejecutables. b. Ensamblar y probar todos los archivos de datos. c. Crear y probar toda la documentacin del usuario. d. Implementar las versiones electrnicas (por ejemplo, pdf) e. Implementar los archivos de ayuda en hipertexto f. Implementar una gua para la resolucin de problemas g. Probar los medios de entrega con un grupo pequeo de usuarios representativos 2. Establecer la persona o grupo encargado del soporte humano a. Crear la documentacin o las herramientas de soporte por computadora. b. Establecer mecanismos de contacto c. Establecer mecanismos para la localizacin de problemas d. Establecer mecanismos para el reporte de problemas e. Establecer una base de datos para el reporte de problemas/errores. 3. Establecer mecanismos de retroalimentacin del usuario. a. Definir el proceso de retroalimentacin b. Definir las formas de retroalimentacin c. Establecer la base de datos de retroalimentacin d. Definir el proceso de evaluacin de la retroalimentacin 4. Diseminar los medios de entrega para todos los usuarios. 5. Dirigir las funciones de soporte continuas a. Proporcionar asistencia en la instalacin y el inicio. b. Proporcionar asistencia continua y de resolucin de problemas 6. Recopilar la retroalimentacin del usuario. a. Registrar la retroalimentacin b. Evaluar la retroalimentacin

c. Comunicarse con los usuarios sobre la retroalimentacin

Resumen: El proceso unificado es un proceso de software guiado por los casos de uso, de arquitectura cntrica, iterativo e incremental diseado como un marco para los mtodos y herramientas del UML. El proceso unificado es un modelo incremental en el que se definen cinco fases: 1) una fase de inicio que abarca la comunicacin con el cliente y las actividades de planeacin y destaca el desarrollo y el refinamiento de casos de uso como un modelo primario; 2) una fase de elaboracin que abarca la comunicacin con el cliente y las actividades de modelado con un enfoque en la creacin de modelos de anlisis y diseo, con nfasis en las definiciones de clase y representaciones arquitectnicas; 3) una fase de construccin que refina y despus traduce el modelo de diseo en componentes de software implementados; 4) una fase de transicin que transfiere el software del desarrollador al usuario final para realizar las pruebas beta y obtener la aceptacin; y 5) una fase de produccin en la cual se realiza el monitoreo continuo y el soporte.