CLIENTE

1. Proceso Unificado (UP)Un proceso de desarrollo de software es como un conjunto de actividades que permiten transformar las necesidades de un usuario en un sistema de software. Al referirnos con el trmino usuario nos representa personas o algo (como ser la interaccin con otros sistemas).

El proceso unificado est basado en componentes (parte fsica y reemplazable de un sistema) interconectados a travs de interfaces (son las operaciones que definen el servicio de un componente o una clase) claramente definidas. Se utiliza el Lenguaje Unificado de Modelado UML para especificar y documentar un sistema.

Dicho proceso est dirigido por los casos de uso, permiten definir las necesidades de los usuarios representando los requisitos funcionales -Qu debe hacer el sistema?-. Es una porcin de funcionalidad del sistema que proporciona un resultado importante al usuario. Una vez que han sido detectados podemos definir el modelo de casos de uso, y sobre la base de ellos se contina especificando el desarrollo del software.

Se crean una serie de modelos de diseo e implementacin que procesa cada uno de los casos de uso, estos modelos son examinados para que consoliden al modelo de los casos de uso que define la funcionalidad del sistema.

A su vez cuando el modelo de implementacin es probado debe corroborar que se implementan correctamente cada caso de uso. Podemos observar que los casos de uso definen el comienzo de la especificacin del sistema como as tambin la comprobacin del mismo.

Los casos de uso no se desarrollan aisladamente y algunos de ellos (los candidatos) son utilizados para guiar la especificacin de la arquitectura del sistema, y a su vez la arquitectura influye en la seleccin de los casos de uso. Por lo tanto la arquitectura como los casos de uso se modifica a medida que avanza el ciclo de desarrollo.

La arquitectura permite visualizar una imagen completa del sistema antes de que comience su construccin, describiendo diferentes vistas e incluyendo los diferentes aspectos estticos y dinmicos del sistema.

La misma se ve afectada por muchos factores como ser: la plataforma en la que tiene que funcionar el software (sistema operativo, gestin de base de datos, protocolo de comunicacin, etc.), tambin deber tenerse en cuenta los bloques de reutilizacin con los que se dispone (interfaces grficas, libreras adquiridas, etc.), sistemas heredados, y requisitos no funcionales (rendimiento, fiabilidad, seguridad, acceso, etc.). Estos aspectos determinan que los casos de uso y la arquitectura evolucionan paralelamente.

La arquitectura debe centrase sobre la compresin general de los casos de uso claves, abarcan entre un 5% a un 10% del total de todos los casos de uso, los cuales constituyen las funciones fundamentales del sistema. Los casos de usos claves, se utilizan para no desvirtuarse de los detalles ms significativos y suprimir aquellos que por el momento son irrelevantes.

Al principio la arquitectura no especifica casos de uso sino que manifiesta la plataforma. Posteriormente se especifican los casos de uso claves y por cada uno de ellos se especifica en detalle y en trminos de subsistemas (agrupacin de clases o de otros subsistemas), clases y componentes. A medida que los casos de uso se especifican y maduran, se descubre ms de la arquitectura. Este proceso contina hasta que se considere que la arquitectura es estable.

Para comprender y constatar un trabajo es prctico dividirlo en partes ms pequeas o mini-proyectos. Cada mini-proyecto es una iteracin refleja los pasos a realizar resultando un incremento en el crecimiento del producto. Las iteraciones deben ser seleccionadas y ejecutadas en forma planificada.

Cada iteracin seleccionar un grupo de casos de uso que extienden la utilidad del producto desarrollado, analizando los riesgos ms importantes. Se comienza con los casos de uso y se contina con el flujo de trabajo (modelo de negocio, requisitos, (anlisis y diseo), implementacin, prueba y despliegue).

En la iteracin se crea un diseo utilizando la arquitectura seleccionada como gua, implementando el diseo mediante componentes, y verificando que los componentes satisfagan los casos de uso.

El desarrollo iterativo e incremental controlado reduce el costo de los riesgos, ya que los costos de un solo incremento son menores que los costos que se ocasionan del producto entero. Mediante la identificacin de los riesgos en fases tempranas del desarrollo. Permite tambin que se trabaje de manera ms eficiente debido a que se obtienen resultados claros a corto plazo y por medio de ellos se clarifican las necesidades de los usuarios, las cuales no pueden ser definidas completamente desde el principio.

1.1. Ciclo de vida del proceso unificado

El proceso unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Cada ciclo concluye con una versin del sistema a desarrollar y consta de cuatro fases: inicio, elaboracin, construccin y transicin y cada fase a su vez se subdivide en iteraciones y cada iteracin realiza un flujo de trabajo. Cada fase termina con un hito, punto en el que deben tomarse importantes decisiones de negocio, ya que se deben tomar decisiones cruciales de continuar o no el proyecto, y decidir sobre la planificacin, presupuesto y requisitos del mismo.

Planificacin de fasesSi bien, cada fase no tiene identificado un tiempo y esfuerzo exacto, porque vara segn las caractersticas propias del proyecto, del equipo de desarrollo, las restricciones impuestas por el usuario, etc. Se puede considerar para un proyecto, un ciclo de desarrollo tpico segn la siguiente tabla:

InicioElaboracinConstruccinTransicin

Esfuerzo~5 %20 %65 %10%

Prog. Horarios10 %30 %50 %10%

Teniendo esta tabla como referencia uno puede realizar un clculo estimativo de los recursos necesarios para llevar a cabo un proyecto de mediana envergadura. Debemos mencionar que un ciclo de desarrollo es una pasada por todas fases.

Breve descripcin de las fases

En la fase de inicio se desarrolla una descripcin del producto final y se presenta el anlisis de negocio para el producto. Analizar, Cules son las principales funciones del sistema para los usuarios ms importantes?, Cmo podra ser la arquitectura del sistema?, Cul es el plan de proyecto y cunto costar desarrollar el producto?

En la fase de elaboracin se especifican en detalle la mayora de los casos de uso del producto y se disea la arquitectura el sistema. La arquitectura se expresa en forma de vistas de todos los modelos del sistema, los cuales juntos representan al sistema entero. Se realizan los casos de uso ms significativos que se identificaron en la fase de inicio y como resultado se obtiene la lnea base, esqueleto del sistema con poco desarrollo de software, de la arquitectura. Al final de esta fase nos encontramos en posicin de planificar las actividades y estimar los recursos necesarios para el desarrollo del sistema.

En la fase de construccin se crea el producto incrementando el software al esqueleto. En esta fase la lnea base de la arquitectura crece hasta convertirse en el sistema desarrollado. Al final de esta fase el sistema contiene todos los casos de uso que se han acordado entre la direccin y el cliente. Analizar, Cubre el producto las necesidades de algunos usuarios de manera suficiente como para hacer la entrega?

En la fase de transicin cubre el perodo de prueba y el producto se convierte en una versin beta. En esta versin un nmero reducido de usuarios con experiencia prueban e informan los defectos y deficiencias. Los defectos se dividen en dos categoras los que tienen suficiente impactos para justificar una versin incrementada delta y los que pueden corregirse en la siguiente versin.

El proceso UP se basa en tres ideas bsicas (casos de uso, arquitectura, y el desarrollo iterativo e incremental). Para poder hacer que estas ideas funcionen se necesita un proceso polifactico: que tenga en cuenta ciclos, fases, flujos de trabajo, gestin de riesgos, control de calidad, gestin de proyecto y control de configuracin.

1.2. Personas

UP define la palabra trabajador al puesto a ser asignado a una persona o equipo, requiriendo responsabilidad y habilidades para realizar determinadas actividades, el trmino de rol se utiliza para determinar los papeles que cumple un trabajador. Un trabajador puede participar en varios flujos de trabajo y puede asumir un rol diferente en cada uno de ellos siendo responsable de un conjunto de actividades. Un trabajador no es un cargo concreto dentro de una em presa.

Las herramientas empleadas para realizar un trabajo deben ser las adecuadas, no slo deben ayudar a los trabajadores a llevar a cabo sus propias tareas sino tambin deben poder aislar toda informacin que no sea relevante.

Una persona puede ser varios trabajadores dentro de un proyecto. Las aptitudes requeridas por algunos trabajadores pueden conseguirse mediante formacin (especificador de casos de uso), mientras que otras slo pueden obtenerse por medio de la experiencia (arquitecto).

Especificador deIngeniero deIngeniero de Pruebas

Casos de UsoComponentesde Integracin

JuanGuillermo

1.3. El producto

El producto hace referencia al sistema entero, y no slo al cdigo que se entrega. Denominamos sistemas a todos los artefactos necesarios para poder representarlo en una forma compresible para las mquinas, los trabajadores y los interesados.

Artefacto se denomina a cualquier tipo de informacin creada, producida, cambiada o utilizada por los trabajadores en el desarrollo del sistema. En UML son los diagramas y su texto anexado, los bocetos de la interfaz de usuario y los prototipos (primer molde de algo), los componentes, los planes de prueba y los procedimientos de prueba.

Existen dos tipos de artefactos: los de ingeniera creados en las distintas fases del proceso UP. Y los de gestin (anlisis de negocios, plan de desarrollo, y plan de asignacin de recursos).

El tipo de artefacto ms utilizado por UML es el modelo y cada trabajar necesita una perspectiva diferente del conjunto de modelos. Representamos estos conceptos en las diferentes grficas.

ArquitectoIngeniero de Prueba

Jefe de ProyectoDiseadores

AnalistasUsuariosUn modelo es una abstraccin del sistema que especifica un punto de vista en un nivel de abstraccin (especificacin, diseo, etc.). Es una abstraccin autocontenida ya que un usuario de un modelo no necesita ms informacin de otros modelos para interpretarlo. Los usuarios saben que suceder cuando se dispare un evento, ocurrencia de un estmulo que puede ejecutar una transicin de estados, descrito en el modelo.

Cuando modelamos un sistema tambin deberamos tener en cuenta los elementos relevantes de su entorno. Los cuales son definidos como actores, representan los tipos de usuarios que colaboran con el sistema internos y externos.

Los trabajadores que modelan los requisitos funcionales, no se preocupan de cmo es el sistema por dentro, si analizan lo que pueden hacer los usuarios con l sistema por medio de los casos de uso y los actores. Los trabajadores que modelan el diseo piensan en elementos estructurales como subsistemas y clases, piensan en cmo estos elementos funcionan en un contexto dado y como colaboran para proporcionar los casos de uso.

Las dos son interpretaciones diferentes pero mutuamente consistentes de lo que har el sistema para responder a los diferentes estmulos externos provenientes de los actores. Son diferentes debido a que estn pensados para ser utilizados por diferentes trabajadores con diferentes tareas y objetivos. El modelo de casos de uso es una vista externa del sistema que captura los usos del sistema y el modelo de diseo es una vista interna que representa la construccin del sistema.

El modelo de anlisis tambin puede contener diagramas de actividad y todo aquello que nos permita especificar el sistema desde una perspectiva conceptual. El modelo de diseo puede contener ms cosas, como diagramas de estados o diagramas de interaccin, tambin contiene colaboraciones (una sociedad de clases, interfaces y otros elementos que trabajan juntos para proporcionar un comportamiento cooperativo). Cada subsistema puede ser contenedor de construcciones similares implicando la existencia una jerarqua de elementos en este modelo.

Un sistema contiene todas las relaciones, conexin semntica entre elementos, y restricciones entre elementos incluidos en diferentes modelos. Por lo tanto un sistema no es slo una coleccin de sus modelos sino que contiene tambin las relaciones entre ellos. Esta relacin en UML es llamada dependencia de traza o traza.

Las relaciones de traza entre elementos en modelos distintos no aaden informacin semntica sirven para ayudar a comprender los modelos relacionados, simplemente los conectan. La posibilidad de crear trazas es muy importante en el desarrollo de software por razones como la comprensibilidad y la propagacin de cambios.

1.4. Los procesos

Describimos un proceso como el trmino de flujo de trabajo, donde el mismo es un conjunto de actividades. No se obtiene por medio de la divisin del proceso en subprocesos ms pequeos que interactan, ni se utilizar diagramas de flujos tradicionales para describir cmo descomponemos el proceso en partes ms pequeas.

Por el contrario primero identificaremos los distintos trabajadores participantes en el proceso. Despus identificamos los artefactos que necesitamos crear durante el proceso para cada tipo de trabajador. Una vez que los hemos identificados, podemos describir como fluye el proceso a travs de los diferentes trabajadores, y cmo ellos crean y utilizan los artefactos de los dems.

A partir de este momento podemos identificar fcilmente las actividades que estos trabajadores deben realizar cuando se activan.

Un flujo de trabajo es un estereotipo, permite la creacin de nuevos tipos de bloques de construccin derivados de otros existentes pero que no son especficos a un problema particular. Esto implica que los trabajadores y los artefactos que participan en un flujo de trabajo pueden participar en otros flujos de trabajo. Representacin del flujo de trabajo de los requisitos.

AnalistaIdentificar ActoresEstructurar el Modelo de

y Casos de UsoCasos de Uso

ArquitectoPriorizar Casos de Uso

EspecificadorDetallar un Caso de Usode Casos de Uso

Diseador deEsbozar Interfaz de Usuario

Interfaz

Negocio

Requisitos

Anlisis

Diseo

Implementacin

Prueba

Despliegue

1.5. Proceso dirigido por casos de uso

El objetivo de UP es guiar a los desarrolladores en la implementacin y distribucin de eficientes sistemas que se ajustan a las necesidades de los usuarios. La eficiencia se mide en trminos de coste, calidad y tiempo de desarrollo.

Entender y comprender las necesidades del cliente no es tarea fcil. Por ello es necesario que tengamos algn modo de capturar estas necesidades y poder fcilmente transmitirlas a todas las personas implicadas en el proyecto. Despus deberemos disear una implementacin funcional que se ajuste a estas necesidades. Por ltimo, deberemos verificar como las necesidades del cliente se han cumplido mediante la prueba del sistema.

Los casos de uso han sido adoptados casi universalmente para la captura de requisitos de sistemas software en general, y de sistemas basados en componentes (parte fsica y reemplazable de un sistema que se ajusta a un conjunto de interfaces). Dirigiendo al proceso de desarrollo de sistemas en su totalidad

Un caso de uso es una secuencia de acciones que el sistema lleva a cabo para ofrecer algn resultado de valor para un actor. El modelo de casos de uso est compuesto por todos los actores y todos los casos de uso de un sistema.

Durante el anlisis y diseo, el modelo de casos de uso se transforma en un modelo de diseo a travs de un modelo de anlisis. Estos dos ltimos modelos son estructuras compuestas por clasificadores, mecanismo que describe las caractersticas estructurales y de comportamiento (actores, clases, interfaces, tipos de datos, componentes y nodos), y por un conjunto de realizaciones de casos de uso para describir cmo esa estructura realiza los casos de uso.1.6. Planificacin y Evaluacin

La planificacin es necesaria a lo largo de todo el ciclo de desarrollo, se antepone a los cinco flujos de trabajo realizados en cada iteracin correspondiente a cada fase del desarrollo y posteriormente se realiza la evaluacin de ellos.

Antes de ponernos a planear es necesario saber qu es lo que tenemos que hacer. Otro aspecto clave de la planificacin es la administracin de riesgos, se deber realizar la captura de los casos de uso e identificar y mitigar los riesgos por cada uno de ellos.

Un plan no estar completo sin la estimacin de recursos que est requerir y, por ltimo, tambin debe llevarse a cabo la evaluacin de la ejecucin de cada iteracin en cada fase.

Se dividir el trabajo en partes ms pequeas y comprensible. En fases y en cada una de ellas en iteraciones. Dentro de cada iteracin el proyecto deber esforzarse en alcanzar un equilibrio entre las secuencias de actividades que se ejecutan a lo largo de la iteracin, asignndoles una prioridad y sincronizndolas con facilidad.

En las primeras iteraciones trabajamos con riesgos crticos, casos de uso fundamentales, cuestiones arquitectnicas, la eleccin del entorno de desarrollo, todas las cuestiones orientaciones a la investigacin. Mientras que en las ltimas iteraciones trabajamos en actividades orientadas al desarrollo, como la implementacin y la prueba, problemas de evaluacin del rendimiento y el despliegue del sistema. El relacionar todas estas actividades entre s es una cuestin de equilibrio bastante delicada.

La secuencia a realizar en una planificacin:

La interaccin con clientes en requisitos nuevos.

La preparacin de una oferta para los clientes.

La comprensin del contexto de un sistema creando un modelo de negocio.

La planificacin y administracin de un proyecto.

El establecimiento y administracin de un entorno de desarrollo, es decir, el proceso y las herramientas.

La administracin de riesgos.

La instalacin de un producto en su lugar de destino.

Utilizamos un ejemplo de un Laboratorio, gua de este curso, relevando la concepcin del negocio en Minuta 1.1.1.doc y el primer relevamiento realizado al departamento de depsito en Minuta 1.2.1.doc. Se ejemplifica el seguimiento de estos procesos en un (proyect) y se planifica el tiempo de la instalacin para la plataforma del sistema. Por ltimo se detalla la arquitectura y el equipamiento bsico empleando el diagrama de emplazamiento (Deployment view).

Este ejemplo es meramente utilizado para que el alumno pueda conceptualizar los temas estudiados, pero, no significa que deba basarse en l para desarrollar sus prcticas profesionales. Tambin si el alumno lo desea podr practicar con el sector de produccin el cual cuenta un solo relevamiento realizado Minuta 1.3.1.doc.1.7. Ejemplificacin

Minuta 1.1.1.doc

El primer nmero contiene 1 se utiliza para la versin del producto, el segundo nmero contiene 1 indicando el laboratorio en general y el tercer nmero contiene 1 para relacionarlo con la iteracin del documento Word.Define el objetivo del producto y como se desarrollar.

Arquitectura 1.1.1.doc

El primer nmero contiene 1 se utiliza para la versin del producto, el segundo nmero contiene 1 indicando el laboratorio en general y el tercer nmero contiene 1 para relacionarlo con la iteracin del documento Word.

Especifica cmo estar constituida dicha arquitectura. Laboratorio 1.1.1.eaEl primer nmero contiene 1 se utiliza para la versin del producto, el segundo nmero contiene 1 indicando el laboratorio en general y el tercer nmero contiene 1 para relacionarlo con la iteracin del grfico Enterprise Architect.

El Enterprise Architect (EA) crea por defecto un primer paquete y un modelo de casos de uso con el nombre (Use Case Model) y los cambiamos por (Modelo Caso Uso ), adems contiene dos paquetes (Actors y Primary Use Cases) los cuales se eliminan desapareciendo automticamente del modelo de casos de uso como as tambin se eliminan todas sus notas.

Dentro del modelo de casos de uso (Modelo Caso Uso ) se crea un nuevo paquete denominado (Laboratorio ) el cual es ilustrado en el modelo de casos de uso (Modelo Caso Uso ). El (Laboratorio ) contiene diferentes paquetes para representar a los diferentes departamentos del Laboratorio (Compras , Control Calidad , Depsito y Produccin ) y estos departamentos utilizan algunos artefactos de documentacin agrupados en el paquete (Artefacto ). El total de estos cinco paquetes son graficados en el modelo de casos de uso (Laboratorio ).

El modelo de casos de uso (Artefacto ) contiene la definicin de los elementos generales para la construccin del modelo de casos de uso del negocio utilizamos el paquete con su respectivo modelo de casos de uso denominado (Actor ) con todos los actores del negocio encontrados hasta el momento.El modelos de caso de uso de negocio (Depsito ) muestra el primer grfico de estos casos hallados en la (Minuta 1.2.1). Se identificaron tres casos de uso de negocio para realizar la gestin de depsito: recepcionar materia prima, entregar materia prima aprobada y recepcionar producto terminado.Los paquetes (Compras , Control Calidad y Produccin ) no se desarrollan en este curso, pero del paquete produccin se ha entregado la (Minuta 1.3.1) la cual describe el relevamiento del sector para que el alumno pueda desarrollarse tomando si as lo desea este curso como ejemplo.Se incorpora un nuevo modelo de despliegue y automticamente crea un paquete y modelo de despliegue llamados (Deployment Model) y los cambiamos por (Modelo Despliegue), adems crea tres paquetes por defecto (Nodes, Artifacts, y Topology) cambiados por (Nodo, Artefacto y Topologa) y cada uno de ellos contiene su respectivo modelo de despliegue los cuales tambin son cambiados. Internamente creamos otro paquete y se crea automticamente su modelo de despliegue llamados (Arquitectura). El paquete (Arquitectura) es graficado en el modelo de despliegue (Modelo Despliegue).Al paquete (Arquitectura) le movimos tres paquetes por defecto (Nodo, Artefacto y Topologa) ilustrados en el modelo de despliegue (Arquitectura).El modelo de despliegue denominado (Nodo) contiene en su interior el diagrama de la estructura de hardware del Laboratorio organizado en tres paquetes y tres modelos de despliegue por defecto (Clients, Devices y Servers) cambiados por (Cliente, Dispositivo y Servidor) y cada uno de ellos contiene los elementos del diagrama de hardware. Minuta 1.2.1.doc

El primer nmero contiene 1 se utiliza para la versin del producto, el segundo nmero contiene 2 indicando el departamento de depsito y el tercer nmero contiene 1 para relacionarlo con la iteracin del documento Word.

Define el objetivo del departamento de depsito y su funcionalidad.

Planificacin 1.1.1.mpp

El primer nmero contiene 1 se utiliza para la versin del producto, el segundo nmero contiene 1 indicando el laboratorio en general y el tercer nmero contiene 1 para relacionarlo con la iteracin del grfico Proyect.

Se registra el tiempo incurrido de cada actividad realizada hasta el momento permitiendo poder estimar las prximas tareas a desarrollar por el equipo para cumplir con el producto.

Sistema

EMBED Word.Picture.8

Modelo de Casos de Uso de Negocio

Modelo de Casos de Uso

Modelo de Prueba

Modelo de Anlisis

Modelo de Diseo

Modelo de Implementacin

Modelo de Despliegue

Diseo de SistemasPgina 4 de 11UTN

_1116426245.doc