TEORIA DE PROCESO UNIFICADO

El proceso unificado es una versin libre y abierta (no propietaria) del proceso iterativo e incremental de ingeniera de software.

Universidad de Oriente
Universidad De Oriente Ncleo de Anzotegui Escuela de Ingeniera y Ciencias Aplicadas Departamento de Computacin y Sistemas Ctedra: Aplicacin y Auditoria de Sistemas de Informacin

TEORIA DE PROCESO UNIFICADO HOTEL ESCUELA SPLENDIDCHEF

Prof.: Ing. Siso Felysol Realizado Por: Atique Vera C.I.: 17.537.930 Curi Miguel C.I.: 19.840.346 Delgado Raniel C.I.: 18.766.480 Perero Julio C.I.: 20.374.717 Quiaro Karely C.I.: 20.875.234 Vargas Miguel C.I.: 19.717. 034 Yeguez Yeniret C.I.: 17.734.853 Seccin: 20 PUERTO LA CRUZ, JUNIO 2013

Universidad de Oriente
NDICE

Contenido
INTRODUCCIN.............................................................................................................................3 PROCESO UNIFICADO .................................................................................................................5 VENTAJAS Y DESVENTAJAS DEL PROCESO UNIFICADO .................................................5 VENTAJAS ...................................................................................................................................5 DESVENTAJAS ...........................................................................................................................6 CARACTERSTICAS GENERALES DEL PROCESO UNIFICADO .........................................7 CICLO DE VIDA INCREMENTAL E ITERATIVA .......................................................................................9 VENTAJAS DEL MODELO ITERATIVO POR INCREMENTOS. .......................................12 ORGANIZACIN DE DISCIPLINAS SEGN PU .....................................................................13 FASES DEL PROCESO UNIFICADO ........................................................................................14 FASE 1. INICIO..........................................................................................................................14 FASE 2. ELABORACIN. ........................................................................................................15 FASE 3. CONSTRUCCIN. ....................................................................................................17 FASE 4. TRANSICIN. ............................................................................................................18 FLUJOS DE TRABAJO (O WORKFLOWS) DEL PROCESO. ................................................19 ARTEFACTOS ...............................................................................................................................23 ARTEFACTOS TCNICOS: ....................................................................................................24 MODELOS......................................................................................................................................25 VISTAS ...........................................................................................................................................26 CONCLUSIN ...............................................................................................................................27

Universidad de Oriente

INTRODUCCIN
La metodologa para representar las abstracciones de datos empleadas es la metodologa orientada a objetos MOO y en especial el lenguaje modelado unificado UML donde se emplean diagramas de clases y otros diagramas. La metodologa orientada a objetos ha derivado de las metodologas anteriores a sta, es utilizada en todo tipo de aplicacin desde animacin grfica hasta los sistemas expertos. Cuando analizamos un sistema creamos un modelo que representa un aspecto de la realidad que nos interesa. Cuando el anlisis lo realizamos en OO, estamos modelando el mundo en trminos de tipos de objetos y su interaccin entre ellos. Los modelos que se construyen con OO reflejan la realidad de un modo ms natural que los obtenidos con los otros sistemas tradicionales, ya que la realidad est formada por objetos y eventos que cambian el estado de dichos objetos. Por ello cuando el mundo real cambia, el software OO es ms fcil de cambiar, siendo el coste de mantenimiento ms econmico. El lenguaje para especificar y diagramar en el UP es UML, por lo cual puede apoyarse en cualquier herramienta que soporte UML. (PU) Proceso Unificado, es un marco de desarrollo de Software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura por ser interactivo e incremental. El refinamiento ms conocido y documentado del Proceso Unificado es el Proceso Unificado Rational o simplemente RUP.

Universidad de Oriente
El proceso unificado, se encarga de realizar la construccin de un producto, que permite poner en prctica la planificacin estratgica para la construccin de productos de software, lo que implica la adecuada administracin de los requerimientos y de los riesgos a los que est expuesto el sistema. Adems, permite integrar diversas actividades para el desarrollo de software e incrementar la calidad del mismo.

Universidad de Oriente

PROCESO UNIFICADO
El proceso unificado (UP, o Unified Development Process) es una versin libre y abierta (no propietaria) del proceso iterativo e incremental de ingeniera de software propuesto por Jacobson, Booch y Rumbaugh (los tres amigos) en su libro El proceso unificado de desarrollo de software, publicado por AddissonWesley en 1999. El lenguaje para especificar y diagramar en el UP es UML, por lo cual puede apoyarse en cualquier herramienta que soporte UML. El Proceso Unificado (UP, Unified Process) combina prcticas

comnmente aceptadas como "buenas prcticas", tales como el ciclo de vida iterativo y desarrollo dirigido por el riesgo, en una descripcin consistente y bien documentada. Un proceso es orientado por el riesgo cuando intenta identificar y definir estrategias para enfrentar los riesgos ms graves del proyecto, resolviendo primero los puntos ms difciles, elaborando planes de contingencia y tratando de anticipar las dificultades.

VENTAJAS Y DESVENTAJAS DEL PROCESO UNIFICADO

VENTAJAS 1. Mediante este proceso de desarrollo de software hay varias oportunidades para revisar el sistema a desarrollar hasta quesea correcto. Se pueden encontrar errores y corregirlos. 2. Adaptabilidad del desarrollo a nuevos requisitos o nuevos cambios.

Universidad de Oriente
3. Se define una arquitectura slida en etapas tempranas del desarrollo. La arquitectura de un sistema se define como un conjunto de componentes y las interacciones entre ellas. De este modo este tipo de ciclo de vida debe ser ampliable, por lo que el sistema es robusto y tiene facilidad de mantenimiento. 4. En cada momento hay una versin del sistema funcionando que se modifica segn las necesidades y deseos del cliente. 5. Progreso visible en las primeras etapas 6. Reducir la redundancia e incrementa la productividad, un software bien diseado evita la duplicidad del cdigo con lo cual se obtiene un software robusto. 7. Fcil ejecucin del proceso de elaboracin del sistema software, ya que describen como est estructurado el sistema desde diferentes perspectivas orientadas a los diferentes involucrados en un proyecto 8. El proceso es comprensible 9. La metodologa de PU es ms adaptable para proyectos de largo plazo DESVENTAJAS 1. El mtodo de PU requiere costos de dedicacin altos por lo que no es conveniente usarlo en procesos de un proyecto pequeo. 2. Si el proceso no se aplica bien desde el inicio el PU se puede volver muy grande y difcil, tanto para aprender como para administrar 3. Una cantidad sustancial de tiempo se gasta en tratar de adecuar el PU a cada proyecto. Aqu, tambin, se corre el riesgo de volverse un esclavo del proceso y perder de vista la razn del proceso 4. Es un proceso pesado 5. Se basa mucho en la documentacin

Universidad de Oriente
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. Propone una descomposicin incremental del problema a travs de refinamientos sucesivos y una produccin incremental de la solucin, a travs de la realizacin de varios ciclos. Esta filosofa es lgica cuando se aplica a sistemas grandes ya que no se puede abarcar todo a la vez.

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. En etapas iniciales se desarrollan las funcionalidades con mayor riesgo y las de mayor complejidad. De este modo se mejoran las posibilidades de xito del proyecto.

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. La arquitectura del software para el sistema en desarrollo se define al principio y gua su desarrollo. Propone la definicin de una arquitectura robusta, lo que facilita el desarrollo del sistema en paralelo, aumentando las posibilidades de

Universidad de Oriente
reutilizacin de componentes y el mantenimiento del sistema. El diseo arquitectnico aporta una base slida sobre la que planificar y gestionar el desarrollo software basado en componentes. Al basarse en la definicin de una arquitectura clara y sencilla, el PU sirve de marco comn para toda una familia de procesos y que puede acomodarse a distintas situaciones. Para ello, el PU da las guas para configurar el proceso de modo que se adapte a cada situacin.

EL PU est dirigido por los casos de uso. Esto es as porque el PU pone gran nfasis en la construccin de sistemas basados en la comprensin de cmo se va a utilizar ese sistema. As, los casos de uso y los escenarios se usan para guiar el flujo de procesos, desde la definicin de los requisitos hasta las pruebas.

El PU es un proceso adaptable a los distintos tipos de desarrollo y se puede configurar dependiendo de las necesidades de cada proyecto (desde los ms sencillos a los ms complejos).

Control continuo de la calidad. El PU propone llevar un adecuado control de calidad y una adecuada gestin de riesgos. Ambos conceptos estn incluidos en el propio proceso, formando parte de sus actividades.

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. A medida que se va conociendo ms el problema, los diagramas se hacen ms precisos (en cada iteracin) para ampliarlos despus (incremento). El proceso se repite hasta asegurarse que los

Universidad de Oriente
diagramas realizados son una expresin exacta del sistema de informacin a desarrollar.

CICLO DE VIDA INCREMENTAL E ITERATIVA

Como se ha dicho, el PU es incremental e iterativo. El modelo de ciclo de vida iterativo y por incremento de Jacobson, Rumbaugh y Booch consta de 4 incrementos y de las actividades a realizar en cada uno de ellos, que varan en carga de trabajo segn el incremento en el que se est. Las fases del proceso unificado se denominan incrementos (tambin fases incrementales) en el ciclo de vida iterativo e incremental. Reciben los siguientes nombres: Fase de inicio o iniciacin (o incremento 1). Consiste en establecer la planificacin del proyecto. Elaboracin (o incremento 2). Se establece un plan para el proyecto y se define la arquitectura del sistema. Construccin o desarrollo del sistema (o incremento 3). Transicin (o incremento 4). O implantacin y entrega del sistema desarrollado a los usuarios finales. Las fases 1 y 2 de este ciclo de vida suponen la realizacin de las actividades de desarrollo de un proyecto. Las fases 3 y 4 suponen la construccin y el paso a la produccin del desarrollo realizado. Aunque la teora dice que el nmero de incrementos puede variar, desde 3 incrementos hasta 16, la prctica parece indicar que 4 es el nmero de incrementos adecuado. En los siguientes apartados se describen los distintos incrementos o fases y los elementos derivados de cada uno.

Universidad de Oriente
Cada paso realizado en el proceso unificado se puede enmarcar en una de las 4 fases y en uno de los 5 procesos de trabajo bsicos. El desarrollo iterativo: de un modo general se puede decir que ste es un mtodo de construccin de software cuyo ciclo de vida est compuesto por un conjunto de iteraciones que tienen como objetivo integrar versiones de software. Cada iteracin se considera un subproyecto que genera productos software ms documentacin asociada. De este modo se tienen puntos de verificacin y control, induciendo un proceso continuo de pruebas. Una iteracin: es una secuencia de actividades (o flujos de trabajo) que se realizan dentro de un plan establecido, que pretende realizar una parte de la funcionalidad del proyecto. Los principales flujos de trabajo son: especificacin de requisitos, anlisis y diseo, pruebas, y gestin del proyecto. En las figuras 1 y 2 se muestran la relacin entre estas actividades (o flujos de trabajo) y las fases incrementales. En lo referente al PU, se sigue un proceso iterativo en el sentido en que cada fase o incremento hay varias iteraciones. Una iteracin en el PU representa un ciclo de desarrollo completo, desde la captura de requisitos en la fase de anlisis hasta la implementacin y prueba, que produce como resultado la entrega de una versin (interna o externa) del proyecto ejecutable. Esta versin es un subconjunto del producto final que se va detallando en cada iteracin. Cada iteracin pasa a travs de varios flujos de trabajo, en distintas proporciones, dependiendo de la fase en que se encuentre. En cada iteracin se obtienen versiones mejoradas del sistema. Cada iteracin contina hasta que sean suficientemente satisfactorios los distintos flujos de trabajo. Luego se pasa a la siguiente iteracin perfeccionndolos y profundizando en ellos.

10

Universidad de Oriente

Figura 1. Principales flujos de trabajo

Si B1, B2, B3,son versiones de un sistema obtenidas en iteraciones sucesivas, se tiene que B2 modifica a B1, B3 a B2, y as sucesivamente. En las primeras iteraciones se desarrollan los casos de uso de mayor complejidad y con mayor nivel de riesgo que pueden afectar al xito del proyecto. As, con cada iteracin, los riesgos del proyecto se reducen. Al final de cada iteracin se evalan los resultados del trabajo y se planifica la siguiente.

11

Universidad de Oriente

Figura 2. Iteraciones dentro de un incremento o fase.

VENTAJAS DEL MODELO ITERATIVO POR INCREMENTOS.

Hay varias oportunidades para revisar el sistema en estudio hasta que sea correcto. Se pueden encontrar errores y corregirlos. Adaptabilidad del desarrollo a nuevos requisitos o nuevos cambios. Se define una arquitectura slida en etapas tempranas del desarrollo. La arquitectura de un sistema se define como un conjunto de componentes y las interacciones entre ellas. De este modo este tipo de ciclo de vida debe ser ampliable, por lo que el sistema es robusto, y tiene facilidad de mantenimiento. Se reducen los riesgos.

12

Universidad de Oriente
En cada momento hay una versin del sistema funcionando que se modifica segn las necesidades y deseos del cliente.

ORGANIZACIN DE DISCIPLINAS SEGN PU

El cuadro siguiente representa cada una de las disciplinas utilizadas en el proceso de desarrollo de software y su nivel de participacin en cada una de las fases definidas de PU.

Figura 3. Proceso unificado

Las disciplinas identificadas son modelado de: negocios, requisitos, anlisis, diseo, implementacin y pruebas, como tambin se identifican las disciplinas de apoyo, tales como: configuracin y manejo de proyectos. Todas estas disciplinas son representadas con su correspondiente esfuerzo estimado para cada una de las fases definidas por PU.

13

Universidad de Oriente
FASES DEL PROCESO UNIFICADO
FASE 1. INICIO

El objetivo de esta fase es determinar si merece la pena desarrollar el sistema en estudio (estudiar su viabilidad). Por 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. Flujos de trabajo en esta fase: El desarrollo de esta fase supone empezar por el flujo de trabajo (workflow) de requisitos, en cuyo inicio se debe comprender el dominio del problema y luego, construir el modelo de negocio (cmo la empresa realiza los negocios en ese dominio). En esta fase se realiza tambin el diagrama de casos de usos inicial, dentro del flujo de trabajo de requisitos y del modelo de negocio. Si el sistema es grande tambin se les da una prioridad en funcin del riesgo que suponga su desarrollo, de modo que los que sean crticos se consideren antes. Al final de la fase de inicio se examinan los objetivos del proyecto y se determina si se contina o no. Para ello, es necesario que durante el desarrollo de fase se haya considerado lo siguiente: Estudio de viabilidad del sistema que se va a desarrollar, una estimacin de la duracin del desarrollo y una estimacin de riesgos. Esto se hace tambin durante el flujo de trabajo de requisitos. Adems, una pequea parte del flujo de trabajo de anlisis se realiza tambin en esta fase. En este apartado, se hace el anlisis de los casos de uso crticos, para que pueda empezarse el diseo de la arquitectura.

14

Universidad de Oriente
Durante la fase de inicio, igualmente empieza a desarrollarse el flujo de trabajo de implementacin, aunque no se suele realizar ninguna codificacin. Sin embargo, a veces, se construye un prototipo para probar la viabilidad de parte del sistema propuesto. No es un prototipo rpido construido para asegurar que los requisitos se han determinado con precisin, sino que es ms una maqueta de ingeniera, es decir, un modelo a escala para probar la factibilidad de la construccin. El flujo de trabajo de pruebas comienza casi al principio de esta fase. Su objetivo es asegurar que los requisitos se hayan determinado con precisin. Documentacin obtenida al final de esta fase: La versin inicial del modelo de dominio. La versin inicial del modelo de negocio. La versin inicial del modelo de los artefactos de los requisitos (diagrama de casos de usos). Una versin preliminar de los artefactos del anlisis. Una versin preliminar de la arquitectura. La lista inicial de los riesgos. El plan de trabajo para la fase siguiente. La versin inicial de caso de negocios.

FASE 2. ELABORACIN.

Objetivos de esta fase y flujos de trabajo asociados: El propsito de esta fase es establecer 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

15

Universidad de Oriente
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 la arquitectura se implementa un sistema (prototipo de la arquitectura) que demuestre las posibilidades de la arquitectura y ejecute los casos de uso ms significativos. Los objetivos se pueden enumerar como sigue: 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. Al final de la fase se examinan el alcance y objetivos del sistema, la arquitectura elegida, y la solucin de los riesgos mayores. Igualmente se decide si se pasa a la fase siguiente. Documentacin obtenida al final de esta fase: Modelo de dominio terminado. Modelo de negocio terminado. Los artefactos de los requisitos terminados. Los artefactos de anlisis terminados. Una versin revisada de la arquitectura. La lista revisada y refinada de los riesgos. El plan de administracin del proyecto para el resto de fases. El caso de negocios terminado.

16

Universidad de Oriente
FASE 3. CONSTRUCCIN.

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. Para ello, se describen los requisitos no desarrollados antes y se completa el desarrollo del sistema basndose en la arquitectura definida. Flujos de trabajo en esta fase: El peso de esta fase lo lleva el desarrollo del flujo de trabajo de implementacin y de pruebas. Dentro del flujo de trabajo de implementacin se codifican los distintos mdulos obtenidos en el diseo detallado. A estos mdulos se les aplican las pruebas unitarias (flujo de trabajo de pruebas). Luego los mdulos se compilan y se integran para formar subsistemas a los que se les aplican las pruebas de integracin. Por otra parte los diversos subsistemas que formen el sistema en desarrollo se combinan para formar el sistema completo, al que se le aplican las pruebas de aceptacin. Al final de la fase se obtiene la primera versin operativa y con la calidad suficiente para el sistema desarrollado (a veces se llama versin beta). La carga de trabajo de esta fase la soportan, en su mayora, los programadores y el equipo de control de calidad, aunque los diseadores llevan a cabo el rediseo del sistema. Si se detectara algn fallo que requiera modificaciones en los elementos previos de los flujos de trabajo, los analistas tambin tendran que intervenir para revisar esos elementos o cambiar los requisitos que han provocado el error.

17

Universidad de Oriente
Al final de la fase se decide si todo est preparado para la instalacin del sistema (el software acabado, localizacin del sistema y usuarios preparados).

Documentacin obtenida al final de esta fase: Manual de usuario inicial y otros manuales necesarios. Todos los artefactos (versin beta). La arquitectura terminada La lista de riesgos actualizada. El plan de administracin del proyecto para el resto de fases. El caso de negocios revisado, en caso necesario.

FASE 4. TRANSICIN.

El objetivo de esta fase es asegurar 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 riesgos no detectados anteriormente. Los ajustes que se hagan sern especficos y de corto alcance. Ajustes estructurales mayores debieron haberse resuelto anteriormente en el ciclo de vida y debern documentarse para futuras ampliaciones.

18

Universidad de Oriente
Estando en marcha la versin beta del sistema, se reemplaza por el sistema definitivo que se despliega entre los usuarios. La carga de trabajo de esta fase la soportan los programadores (que hacen los cambios necesarios) y el equipo de control de calidad (que prueba los cambios). Si los fallos que se detecten requieren cambios en los flujos de trabajo de requisitos, del anlisis o del diseo, los analistas tambin tendran que intervenir. Al final de la fase, se decide si se han cumplido los objetivos previstos y se puede determinar si es necesario empezar otro ciclo de desarrollo. Por otra parte, se anotan las lecciones aprendidas, para aplicarlas en prximos desarrollos. Documentacin obtenida al final de esta fase: Todos los artefactos (versin final). Los manuales completos.

FLUJOS DE TRABAJO (O WORKFLOWS) DEL PROCESO.

El PU consta de 9 flujos de trabajo o workflows. En cada incremento o fase incremental se ejecuta parte de estos flujos de trabajo, variando el peso de cada uno de ellos en cada incremento. A) Flujos de trabajo bsico, relativo a los aspectos tcnicos del desarrollo: 1. Modelado de negocio: describe la estructura y la dinmica de la empresa. 2. Requisitos(*) (flujo de trabajo de requisitos): describe el modelo del sistema en funcin de los casos de uso, para extraer los requisitos.

19

Universidad de Oriente
El objetivo del flujo de trabajo de requisitos: es asegurarse que los desarrolladores construyan el sistema correcto, describiendo para ello claramente los objetivos del sistema (qu hay que hacer y qu no). Este flujo de trabajo comienza en el primer incremento y contina generalmente durante el segundo. Al final, cliente y desarrollador se han puesto de acuerdo sobre los objetivos del sistema. Se pueden hacer estimaciones de costo y de tiempo de desarrollo. Igualmente se definir el interfaz de usuario a alto nivel.

3. Anlisis y diseo (*) (flujo de trabajo de anlisis y flujo de trabajo de diseo): describe las diferentes vistas arquitectnicas del sistema, se transforman los requisitos en un diseo para el sistema. Se desarrolla una arquitectura robusta.

El objetivo del flujo de trabajo de anlisis: es que el equipo de desarrollo examine y revise los requisitos, para llegar a comprenderlos y desarrollarlos correctamente. Como la salida del flujo de trabajo de requisitos est expresada de modo que el cliente lo entienda, el flujo de trabajo de anlisis expresa esos requisitos en un lenguaje ms tcnico, aadindose detalles que no son importantes para el cliente (por lo que no se expresaron en el flujo de trabajo de requisitos). Este flujo de trabajo comienza a realizarse al final del primer incremento, y contina aumentando su importancia durante el 2, siendo menor en el 3, y concluye a principio del 4.

El objetivo del flujo de trabajo de diseo: es refinar el flujo de trabajo de anlisis hasta dejarlo en un nivel de detalle comprensible por los programadores. Tambin hay que determinar algunos requisitos que faltaban, como la leccin del lenguaje de programacin, las posibilidades de reutilizacin, portabilidad del sistema, etc.

20

Universidad de Oriente
Comienza a desarrollarse al final del primer incremento, se realiza fundamentalmente entre el 2 y el 3 incremento y contina hasta el principio del 4.

4. Implementacin (*) (flujo de trabajo de implementacin). Define la organizacin del cdigo en trminos de subsistemas. Se transforman los elementos de diseo en elementos de implementacin. Considerando el desarrollo software, se realizan las pruebas unitarias y de integracin.

El objetivo del flujo de trabajo de implementacin: es implantar el sistema. Pero antes, los distintos equipos de implementacin codifican las diversas partes en las que se haya dividido el problema. Cada programador, por su parte, prueba lo que codifica. Tambin hay que hacer las pruebas conjuntas (pruebas del sistema y de integracin). Se desarrolla durante todos los incrementos, sobretodo en el 3, aunque en el primer incremento ya hay algo de implementacin (probablemente un prototipo inicial). 5. Pruebas (*) (flujo de trabajo de pruebas): describe cada prueba, los procedimientos, y las mtricas para la evaluacin de defectos. Su objetivo es encontrar y detectar defectos en el software desarrollado o en desarrollo, y dotarlo de los elementos de calidad requerido. Se validan los requisitos y el diseo.

21

Universidad de Oriente
El responsable de la realizacin del flujo de trabajo de pruebas es el grupo de control de calidad del proyecto. Supone la realizacin de las siguientes tareas: Pruebas de componentes Pruebas unitarias. Al final de cada iteracin realizan las pruebas de integracin. Es decir, se integran varios componentes y se prueban. Hacer las pruebas de conjunto: Es decir, se prueba el producto cuando est todo terminado o lo parece. Pruebas de aceptacin: Se realizan cuando el equipo de desarrollo cree que todo est correcto y acabado, y el sistema se instala en el equipo del cliente. Este por su parte revisa el sistema desarrollado y entregado.

El flujo de trabajo de prueba se empieza a realizar desde el principio (1er incremento) aumentando su importancia al final del ciclo de vida (4 incremento). De cualquier modo, es especialmente interesante al final de cada incremento. 6. Despliegue (flujo de trabajo de despliegue): cubre la configuracin del sistema entregable. B) Flujos de trabajo relativos a los aspectos de administracin y gestin del proyecto: 7. Gestin de configuraciones: controla los cambios y mantiene la integridad de los artefactos del proyecto. 8. Gestin del proyecto: describe estrategias de trabajo en un proceso iterativo. 9. Entorno. Cubre la infraestructura necesaria para desarrollar un sistema.

22

Universidad de Oriente
Los flujos de trabajo con (*) son los ms importantes y los que se consideran fundamentales. Incluso, en la bibliografa en la que se describe el proceso unificado de un modo sencillo y simplificado slo se consideran estos 5 flujos de trabajo fundamentales.

Dentro de cada flujo de trabajo del proceso hay un conjunto de artefactos y actividades relacionadas. Algunos flujos de trabajo del proceso definen conexiones entre los artefactos. Por ejemplo el modelo de casos de uso que se genera durante la captura de requisitos (flujo de trabajo de requisitos) es realizado por el modelo de diseo durante los flujos de trabajo de anlisis y diseo, es implementado por el modelo de implementacin (flujo de trabajo de

implementacin) y es verificado por el modelo de pruebas del flujo de trabajo de pruebas.

ARTEFACTOS
Dentro del proceso unificado de desarrollo se denomina artefacto a todo producto o subproducto del proceso de fabricacin y obtencin del software. Cada actividad del proceso unificado lleva asociados unos artefactos, ya sean requeridos como entradas, o bien generados como salidas. Algunos de estos artefactos se usan como entrada en las actividades siguientes, son recursos de referencia del proyecto o son entregables definidos en el contrato. Al ser incremental el proceso unificado, un artefacto se construye despus de haber pasado por los incrementos en el que se va profundizando. Esto supone un artefacto se construye por piezas (incremento) y cada uno pasa por mltiples versiones (incrementos). As, los requisitos se estudian varias veces (originales y refinados), lo mismo con otros elementos de la dems fases.

23

Universidad de Oriente
ARTEFACTOS TCNICOS:

1. Conjunto de requisitos: Describen QUE debe hacer el sistema. Contiene la informacin que describe lo que debe hacer el sistema. Puede ser: modelo de casos de uso, modelo de requisitos no funcionales, modelo de dominio, modelo de anlisis, y otras cosas como prototipos de interfaz, restricciones legales, etc. 2. Conjunto de diseo: Describe COMO se va a construir el sistema, contiene la informacin necesaria, captura las decisiones de cmo se va a realizar considerando diversas restricciones, de tiempo, presupuesto, aplicaciones existentes, reutilizacin, objetivos de calidad, etc. Esto puede implicar un modelo de diseo, modelo de pruebas, prototipos, arquitecturas

ejecutables, etc. 3. Conjunto de implementacin: Describe el ensamblado de componentes. Agrupa toda la informacin sobre los elementos software del sistema: cdigo fuente, archivos de configuracin, archivos de datos, componentes software y descripcin de cmo se ensambla el sistema. 4. Conjunto de despliegue: Proporciona todos los datos para la configuracin entregable, e informacin acerca de cmo se empaqueta el software, se distribuye, se instala y se ejecuta en el destino. Otros artefactos: Artefactos de gestin.

24

Universidad de Oriente
MODELOS
Cada flujo de trabajo est relacionado con uno o varios modelos. Hay 9 modelos que representan las decisiones relacionadas con la visualizacin, especificacin, construccin y documentacin de un gran sistema: Modelo de negocio: representa el modelo lgico de la empresa (abstraccin de la organizacin). Modelo de dominio: representa el contexto en el que se incluye el Sistema. Modelo de casos de uso*: representa los requisitos funcionales del sistema M. de anlisis*: representa el diseo de las ideas. M. de diseo*: establece el vocabulario del problema y de su solucin. M. de proceso (opcional): define los mecanismos de concurrencia y sincronizacin del sistema. M. de despliegue*: define la topologa hardware para la ejecucin del sistema. M de implementacin*: define los elementos a ensamblar y el sistema fsico. M de pruebas*: define cmo validar y verificar el sistema. Los ms importantes son los marcados con (*) Los distintos flujos de trabajo dan lugar a diversos modelos que se pueden expresar Es un hecho histrico bien documentado que la actual divisin entre pases con un elevado nivel de vida para el grueso de la poblacin, y pases donde imperan condiciones de vida precarias para la mayora, no exista antes de la mitad del siglo XVIII. A mediados del siglo XIX los ahora llamados pases desarrollados -Inglaterra, Francia, Alemania, Italia y los Estados Unidos, principalmente- haban incrementado sus niveles de vida notablemente. El ritmo de crecimiento de su poblacin, anteriormente estancado, haba crecido significativamente, y la proporcin entre el ingreso per capita medio de estos

25

Universidad de Oriente
pases con respecto al de los no desarrollados era ya de 3:2. Una centuria ms tarde, a mediados del presente siglo, esa diferencia haba alcanzado la proporcin de 5:1, lo cual indicaba que algn fenmeno de extraordinaria trascendencia haba ocurrido en dichos pases durante los dos ltimos siglos, que los haba hecho "adelantarse" tanto con respecto a los dems. Segn Sunkel y Paz: mediante diagramas UML.

VISTAS
Una vista es una proyeccin del modelo. Los diagramas UML proporcionan las vistas de cada modelo. En el proceso unificado la arquitectura de un sistema se captura en forma de 5 vistas que interaccionan entre s: Vista de diseo, de procesos, de despliegue, de implementacin y de casos de uso.

Figura 4. Relacin entre modelos y flujos de trabajo.

26

Universidad de Oriente
CONCLUSIN
El Proceso Unificado (UP, Unified Process) combina prcticas

comnmente aceptadas como "buenas prcticas", tales como el ciclo de vida iterativo y desarrollo dirigido por el riesgo, en una descripcin consistente y bien documentada. Las fases del proceso unificado se denominan incrementos (tambin fases incrementales) en el ciclo de vida iterativo e incremental. Reciben los siguientes nombres: Fase de inicio o iniciacin (o incremento 1). Consiste en establecer la planificacin del proyecto. Elaboracin (o incremento 2). Se establece un plan para el proyecto y se define la arquitectura del sistema. Construccin o desarrollo del sistema (o incremento 3). Transicin (o incremento 4). O implantacin y entrega del sistema desarrollado a los usuarios finales.

Mediante las fases se deben cumplir una serie de requerimientos y al finalizar cada fase una serie de documentacin, la documentacin permite analizar si se puede seguir o no a la siguiente fase.

27