EL PROCESO UNIFICADO: DIRIGIDO POR CASOS DE USO, CENTRADO EN LA ARQUITECTURA, ITERATIVO E INCREMENTAL Aspilcueta Rubio Davidson Chirinos Zegarra

Ybeth

Introduccin

La tendencia actual en el software lleva a la construccin de sistemas ms grandes y ms complejos Esto es debido en parte al hecho de que los computadores son ms potentes cada ao, y los usuarios, por tanto, esperan ms de ellos. Esta tendencia tambin se ha visto afectada por el uso creciente de Internet para el intercambio de todo tipo de informacin de texto sin formato a texto con formato, fotos, diagramas y multimedia.

Introduccin

El problema del software se reduce a la dificultad que afrontan los desarrolladores para coordinar las mltiples cadenas de trabajo de un gran proyecto de software. Se necesita un mtodo comn, un proceso que:

Proporcione una gua para ordenar las actividades de un equipo. Dirija las tareas de cada desarrollador por separado y del equipo como un todo. Especifique los artefactos que deben desarrollarse. Ofrezca criterios para el control y la medicin de los productos y actividades

El Proceso Unificado en pocas palabras

En primer lugar, el Proceso Unificado es un proceso de desarrollo de software. Un proceso de desarrollo de software es el conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software. El Proceso Unificado es ms que un simple proceso; es un marco de trabajo genrico que puede especializarse para una gran variedad de sistemas software, para diferentes reas de aplicacin, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaos de proyecto.

El Proceso Unificado en pocas palabras

El Proceso Unificado est basado en componentes formado por componentes software interconectados a travs de interfaces. El Proceso Unificado utiliza el Lenguaje Unificado de Modelado para preparar todos los esquemas de un sistema software.

El Proceso Unificado est dirigido por casos de uso

Un sistema software ve la luz para dar servicio a sus usuarios. Debemos conocer lo que sus futuros usuarios necesitan y desean. El trmino usuario no slo hace referencia a usuarios humanos sino a otros sistemas. Una interaccin de este tipo es un caso de uso. Los casos de uso representan los requisitos funcionales. Los casos de uso no son slo una herramienta para especificar los requisitos de un sistema. Tambin guan el proceso de desarrollo. Los casos de uso se desarrollan a la vez que la arquitectura del sistema y la arquitectura del sistema influye en la seleccin de los casos de uso.

El Proceso Unificado est centrado en la arquitectura

El papel de la arquitectura software es parecido al papel que juega la arquitectura en la construccin de edificios. Los desarrolladores basan la seleccin de lo que se implementar en una iteracin en dos fases:

En cada iteracin, los desarrolladores identifican y especifican los casos de uso relevantes. Para alcanzar el mayor grado de economa en el desarrollo, un equipo de proyecto intentar refaccionar slo las iteraciones requeridas para lograr el objetivo del proyecto. Intentar ordenar las iteraciones en un orden lgico. Uno de los objetivos de la reduccin del riesgo es minimizar los problemas inesperados.

En primer lugar, la iteracin trata un grupo de casos de uso que juntos amplan la utilidad del producto desarrollado hasta ahora. En segundo lugar, la iteracin trata los riesgos ms importan las iteraciones sucesivas se construyen sobre los artefactos de desarrollo tal como quedaron al final de la ltima iteracin.

El Proceso Unificado est centrado en la arquitectura

Son muchos los beneficios de un proceso iterativo controlado:

La iteracin controlada reduce el coste del riesgo a los costes de un solo incremento.

Si los desarrolladores tienen que repetir la iteracin, la organizacin slo pierde el esfuerzo mal empleado de la iteracin, no el valor del producto entero.

El Proceso Unificado est centrado en la arquitectura

La iteracin controlada reduce el riesgo de no sacar al mercado el producto en el calendario previsto.

Identificacin de riesgos en fases tempranas del desarrollo, el tiempo que se gasta en resolverlos se emplea al principio de la planificacin, cuando la gente est menos presionada por cumplir los plazos. En el mtodo "tradicional", en el cual los problemas complicados se revelan por primera vez en la prueba del sistema, el tiempo necesario para resolverlos normalmente es mayor que el tiempo que queda en la planificacin, y casi siempre obliga a retrasar la entrega

El Proceso Unificado est centrado en la arquitectura

La iteracin controlada acelera el ritmo del esfuerzo de desarrollo en su totalidad

Debido a que los desarrolladores trabajan de manera ms eficiente para obtener resultados claros a corto plazo, en lugar de tener un calendario largo, que se prolonga eternamente.

La iteracin controlada reconoce una realidad que a menudo se ignora que las necesidades del usuario y sus correspondientes requisitos no pueden definirse completamente al principio.

Tpicamente, se refinan en iteraciones sucesivas.

El Proceso Unificado est centrado en la arquitectura

Esta forma de operar hace ms fcil la adaptacin a los requisitos cambiantes. Los de desarrollo dirigido por los casos de uso, centrado en la arquitectura, iterativo e incremental son de igual importancia. La arquitectura proporciona la estructura sobre la cual guiar las iteraciones, mientras que los casos de uso definen los objetivos y dirigen el trabajo de cada iteracin.

La 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 producto para los clientes. Cada ciclo consta de cuatro fases:

Donde cada fase se subdivide a su vez en iteraciones, como se ha dicho anteriormente.

Inicio Elaboracin Construccin Transicin.

La vida del Proceso Unificado

La vida del Proceso Unificado

El producto

Cada ciclo produce una nueva versin del sistema, y cada versin es un producto preparado para su entrega. Consta de un cuerpo de cdigo fuente incluido en componentes que puede compilarse y ejecutarse, adems de manuales y otros productos asociados. El producto software debera ser algo ms que el cdigo mquina que se ejecuta. El producto terminado incluye los requisitos, casos de uso, especificaciones no funcionales y casos de prueba. Incluye el modelo de la arquitectura y el modelo visual artefactos modelados con el Lenguaje Unificado de Modelado. Aunque los componentes ejecutables sean los artefactos ms importantes desde la perspectiva del usuario, no son suficientes por s solos. Esto se debe a que el entorno cambia.

El producto

El producto

Un modelo de casos de uso, con todos los casos de uso y su relacin con los usuarios. Un modelo de anlisis, con dos propsitos: refinar los casos de uso con ms detalle y establecer la asignacin inicial de funcionalidad del sistema a un conjunto de objetos que proporcionan el comportamiento. Un modelo de diseo que define:

La estructura esttica del sistema en la forma de subsistemas, clases e interfaces Los casos de uso reflejados como colaboraciones entre los subsistemas, clases, e interfaces.

El producto

Un modelo de implementacin, que incluye componentes (que representan al cdigo fuente) y la correspondencia de las clases con los componentes. Un modelo de despliegue, que define los nodos fsicos (ordenadores) y la correspondencia de los componentes con esos nodos. Un modelo de prueba, que describe los casos de prueba que verifican los casos de uso. Representacin de la arquitectura.

El producto

El sistema tambin debe tener un modelo del dominio o modelo del negocio que describa el contexto del negocio en el que se halla el sistema. Todos estos modelos estn relacionados. Juntos, representan al sistema como un todo. Los elementos de un modelo poseen dependencias de hacia atrs y hacia adelante, mediante enlaces hacia otros modelos.

Por ejemplo, podemos hacer el seguimiento de un caso de uso (en el modelo de casos de uso) hasta una realizacin de caso de uso (en el modelo de diseo) y hasta un caso de prueba (en el modelo de prueba). La trazabilidad facilita la comprensin y el cambio

Fases dentro de un ciclo

Cada ciclo se desarrolla a lo largo del tiempo. Este tiempo, se divide en cuatro fases. A travs de una secuencia de modelos, los implicados visualizan lo que est sucediendo en esas fases.

Cada fase termina con un hito en cual se determina por la disponibilidad de un conjunto de artefactos; es decir, ciertos modelos o documentos han sido desarrollados hasta alcanzar un estado predefinido.

Dentro de cada fase, los directores o los desarrolladores pueden descomponer adicionalmente el trabajo en iteraciones con sus incrementos resultantes.

Fases dentro de un ciclo

Los hitos tienen muchos objetivos donde el ms crtico es que los directores deben tomar ciertas decisiones cruciales antes de que el trabajo pueda continuar con la siguiente fase. Los hitos tambin permiten a la direccin, y a los mismos desarrolladores, controlar el progreso del trabajo segn pasa por esos cuatro puntos clave. Al final, se obtiene un conjunto de datos a partir del seguimiento del tiempo y esfuerzo consumido en cada fase. Estos datos son tiles en la estimacin del tiempo y los recursos humanos para otros proyectos, en la asignacin de los recursos durante el tiempo que dura el proyecto, y en el control del progreso contrastado con las planificaciones.

Fases dentro de un ciclo

Fases dentro de un ciclo

Durante la fase de inicio

Se desarrolla una descripcin del producto final a partir de una buena idea y se presenta el anlisis de negocio para el producto. Esencialmente, esta fase responde a las siguientes preguntas:

Cules son las principales funciones del sistema para sus usuarios ms importantes? Cmo podra ser la arquitectura del sistema? Cul es el plan de proyecto y cunto costar desarrollar el producto?

La respuesta a la primera pregunta se encuentra en un modelo de casos de uso simplificado que contenga los casos de uso ms crticos.

Fases dentro de un ciclo

Durante la fase de elaboracin

Se especifican en detalle la mayora de los casos de uso del producto y se disea la arquitectura del sistema. La relacin entre la arquitectura del sistema y el propio sistema es primordial. La arquitectura se expresa en forma de vistas de todos los modelos del sistema, los cuales juntos representan al sistema entero. Esto implica que hay vistas arquitectnicas de:

Modelo de Modelo de Modelo de Modelo de Modelo de

casos de uso anlisis diseo implementacin despliegue

Durante la fase de elaboracin La vista del modelo de implementacin incluye componentes para probar que la arquitectura es ejecutable. Durante esta fase del desarrollo, se realizan los casos de uso ms crticos que se identificaron en la fase de comienzo. El resultado de esta fase es una lnea base de la arquitectura. Al final de la fase de elaboracin, el director de proyecto est en disposicin de planificar las actividades y estimar los recursos necesarios para terminar el proyecto.

Fases dentro de un ciclo

Durante la fase de construccin

Se crea el producto se aaden los msculos (software terminado) al esqueleto (la arquitectura). En esta fase, la lnea base de la arquitectura crece hasta convertirse en el sistema completo. La descripcin evoluciona hasta convertirse en un producto preparado para ser entregado a la comunidad de usuarios. El grueso de los recursos requeridos se emplea durante esta fase del desarrollo. Sin embargo, la arquitectura del sistema es estable. Al final de esta fase, el producto contiene todos los casos de uso que la direccin y el cliente han acordado para el desarrollo de esta versin. Sin embargo, puede que no est completamente libre de defectos.

Fases dentro de un ciclo

La fase de transicin

Cubre el periodo durante el cual el producto se convierte en versin beta. En la versin beta un nmero reducido de usuarios con experiencia prueba el producto e informa de defectos y deficiencias. Los desarrolladores corrigen los problemas e incorporan algunas de las mejoras sugeridas en una versin general dirigida a la totalidad de la comunidad de usuarios. La fase de transicin conlleva actividades como la fabricacin, formacin del cliente, el proporcionar una lnea de ayuda y asistencia, y la correccin de los defectos que se encuentren tras la entrega. El equipo de mantenimiento suele dividir esos defectos en dos categoras: Los que tienen suficiente impacto en la operacin para justificar una versin incrementada (versin delta) Los que pueden corregirse en la siguiente versin normal.

Un proceso integrado

El Proceso Unificado est basado en componentes. Utiliza el nuevo estndar de modelado visual, el Lenguaje Unificado de Modelado (UML) Se sostiene sobre tres ideas bsicas

Para hacer que estas ideas funcionen, se necesita un proceso polifactico, que tenga en cuenta:

Casos de uso Arquitectura Desarrollo iterativo e incremental. Ciclos Fases flujos de trabajo gestin del riego control de calidad gestin de proyecto control de la configuracin.

Un proceso integrado

El Proceso Unificado ha establecido un marco de trabajo que integra todas esas diferentes facetas. Este marco de trabajo sirve tambin como paraguas bajo el cual los fabricantes de herramientas y los desarrolladores pueden construir herramientas que soporten:

La automatizacin del proceso entero, de cada flujo de trabajo individualmente La construccin de los diferentes modelos La integracin del trabajo a lo largo del ciclo de vida y a travs de todos los modelos.

FIN