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

o proyectos especficos. De la misma forma, el Proceso Unificado de Rational, tambin es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto. Resea Histrica del Proceso Unificado de Desarrollo (PUD): El PUD es el resultado de 30 aos de desarrollo y uso prctico. Se puede dividir el transcurso de su desarrollo en tres etapas: desde la publicacin de Objectory Method publicado en 1987 como resultado del xit o del mtodo Ericsson, pasando por el Objectory Rational Process (Desarrollado por IBM Rational entre 1996-1997) hasta el Proceso Unificado de Rational (publicado en 1998).El nombre Proceso Unificado se usa para describir el proceso genrico que incluye aquellos elementos que son comunes a la mayora de los refinamientos existentes. Tambin permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). El Mtodo Ericsson El estudio del origen del PUD, se remonta a 1967, donde la compaa Ericsson modelaba un sistema entero como una serie de bloques interconectados. Los bloques de ms bajo nivel se incorporaban a subsistemas de mayor nivel, con lo que se lograba que el sistema fuera ms manejable. Los bloques, eran identificados estudiando los Casos de Negocio (actuales casos de uso) que se definan con anterioridad. Cada caso de negocio permita detallar los bloques que deban cooperar para llevarlo a cabo. Al tener adjudicada la responsabilidad de cada bloque, se preparaba su especificacin. Las actividades de diseo generaban un conjunto de diagramas de bloques estticos con sus interfaces,

agrupados en subsistemas (su semejante en la actualidad son los diagramas de clases paquetes de UML). El producto primognito de las actividades de diseo radica en la descripcin de la arquitectura de software, la cual consista en la comprensin de los requisitos ms crticos, junto con una breve descripcin de cada bloque y el agrupamiento de ste en subsistemas. Luego, eran representadas en diagramas la descripcin e interconexiones de los bloques. El mtodo era adelantado a su tiempo, ya que los clientes no acostumbraban a que se representaran los productos de software en forma similar a los datos de proyectos de ingeniera. El mtodo Ericsson es esencialmente el que actualmente se conoce como desarrollo basado en componentes. Comprob su efectividad de diseo modular al brindar la posibilidad de instalar cada bloque ejecutable o modificado sobre la marcha de un sistema de telecomunicaciones en ejecucin el 100 por ciento de su tiempo (era sumamente improductivo detener un sistema de tal magnitud simplemente para hacer cambios). Objectory: Ivar Jacobson fue el principal desarrollador de la metodologa empleada en Ericsson. Deja la compaa en 1987 y funda Objectory AB en Estocolmo. Como fruto de 8 aos de trabajo en su compaa, l y sus colaboradores desarrollan un proceso denominado Objectory (Abreviatura de Object Factory en espaol, fbrica de objetos). El empleo de esta metodologa se extendi en diversas industrias adems de las de telecomunicaciones, y en muchos pases aparte de Suecia. Es en Objectory donde se define con su nombre al Caso de Uso, y se desarrolla una tcnica para su representacin. La idea se ampli, y como consecuencia los casos de uso que dirigan el desarrollo se hicieron ms claros, dando pi al origen de la metodologa que gue al desarrollador e informe al usuario. Surgen los flujos de trabajo, representados por una serie de modelos: requisitos-casos de uso, anlisis, diseo, implementacin y prueba. Cada modelo

representaba una perspectiva del sistema, stos permiten al desarrollador realizar una traza sobre un caso de uso a travs de la secuencia de modelos hasta el cdigo fuente cuando surgen problemas (incluso puede volverse hacia atrs). El Lenguaje Unificado de Modelado A principios de los 90, surgi la necesidad de un lenguaje de modelado visual y consistente, que permitiera expresar los resultados de las extensas variedades de metodologas Objeto Orientadas que existan. Por esta razn, Grady Booch, Autor del mtodo Booch y James Rumbaugh, desarrollador principal de OMT (Object Modeling Technique), quienes trabajaban juntos en rational, comenzaron a unificar sus metodologas. El fruto de esta unin es la versin 0.8 del Mtodo Unificado (Unified Modeling Language UML), publicado en Octubre de 1995. Casi en el mismo momento, Ivar Jacobson se incorpora a laborar en Rational y se une para la produccin de la versin 0.9 de UML. El esfuerzo de unin inclua a otros expertos en el rea e involucr empresas como IBM, HP y Microsoft. Luego de pasar por el proceso de estandarizacin el OMT (Object Management Group) publica en noviembre de 1997 la versin estndar de UML 1.1. Mtodo de El Proceso Objectory de Rational: A finales de 1995, Objectory AB es adquirida por Rational Software Corp. Inmediatamente, surge la especial urgencia de unificar los principios bsicos subyacentes en los procesos de desarrollo existentes, y se kopt por unir lo mejor de cada uno. Al momento de fusionarse, Objectory 3.8 haba probado la creacin y modelado de un proceso de produccin de software de manera similar a un producto, dando origen a una arquitectura original de desarrollo y contaba con una serie de modelos que documentaban el resultado del proyecto. Sin embargo, aunque correctamente desarrollado en lo referente a modelado de casos de uso, anlisis y diseo, no se encontraba bien desarrollado en reas como la gestin de

requisitos aparte de los casos de uso, implementacin y pruebas. Es en esta parte, donde entra la experiencia y prctica de Rational, mejorando el proceso y originando Objectory 4.1 en 1997. Entre las mejoras que lo conforman se encuentran el aadir fases de desarrollo y la aproximacin iterativa controlada. Caractersticas Iterativo e Incrementa El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboracin, Construccin y Transicin. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio slo consta de varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que aade o mejora las funcionalidades del sistema en desarrollo. Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clsico o en cascada: Anlisis de requisitos, Diseo, Implementacin y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas vara a lo largo del proyecto. Centrado en la Arquitectura. El Proceso Unificado asume que no existe un modelo nico que cubra todos los aspectos del sistema. Por dicho motivo existen mltiples modelos y vistas que definen la arquitectura de software de un sistema. La analoga con la construccin es clara, cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanera, etc. Enfocado en los riesgos El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos crticos en una etapa temprana del ciclo de vida. Los resultados de cada iteracin, en especial los de la fase de Elaboracin deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero. Fases dentro de un ciclo El desarrollo de un ciclo se realiza a lo largo del tiempo. Segn Booch, Rambaugh y Jacobson, (2000) Cada ciclo se divide a su vez en 4 fases:

 Inicio: es la fase en que se plantea una descripcin del producto final, a partir de una buena idea y se presenta el anlisis de negocio para el producto. Elaboracin: se especifican en detalle la mayora de los casos de uso del producto y se disea la arquitectura del sistema. Construccin: es la fase en que se crea el producto, aadiendo el software terminado a la arquitectura, convirtiendo la lnea base de la arquitectura en el sistema completo. La descripcin evoluciona hasta convertirse en un producto preparado para ser entregado al usuario. Transicin: abarca el perodo en el que el producto es una versin beta, en la cual un reducido nmero de usuarios con experiencia prueba el producto, para informar sus defectos y deficiencias. Para poder realizar el desarrollo de las fases se deben tomar en cuenta los flujos de trabajo (requisitos, anlisis, diseo, implementacin y prueba).

Introduccin

El Proceso Unificado es un proceso de software genrico que puede ser utilizado para una gran cantidad de tipos de sistemas de software, para diferentes reas de aplicacin, diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes tamaos de proyectos. Provee un enfoque disciplinado en la asignacin de tareas y responsabilidades dentro de una organizacin de desarrollo. Su meta es asegurar la produccin de software de muy alta calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario y presupuesto predecible.

Conclusin

Este trabajo pretendi brindar una amplia descripcin del proceso unificado de desarrollo del software, muestra la adquisicin desde una perspectiva, sin embargo explica exactamente como va llevar a acabo dicho proceso ya que son muchos los factores que lo componen y la dinmica de cada transaccin es nica; Los conceptos anteriormente tratados, dirigido por casos de uso, centrado en arquitectura, desarrollo interactivo e incremental son igualmente importantes. La arquitectura provee la estructura sobre la cual guiar el trabajo en interacciones, mientras que los casos de uso definen las metas y dirigen el trabajo en cada interaccin. Remover cualquiera de estos conceptos reducir severamente el valor del Proceso Unificado. Es como una mesa de tres patas, sin alguna de ellas, la mesa se caer.

Bibliografa

1.BARRIENTOS Aleida Proceso Metodolgico de Auditora Informtica aplicado a la evaluacin y seguimiento de Sistemas de Gestin desarrollados con el estndar de modelado UML, Tesis de Maestra en Ingeniera Informtica, Universidad de Oriente La Habana Cuba Universidad Autnoma Toms Fras, Potos-Bolivia, 2002. 2.BOOCH Grady et al. El lenguaje Unificado de Modelado, Primera Edicin, Editorial Addison Wesley, 1999. 3.LARMAN Craig UML y Patrones Una introduccin al Anlisis y Diseo Orientado a Objetos y al Proceso Unificado, Segunda Edicin, Editorial Prentice Hall, 2002. 4.JACOBSON Ivar et al. El Proceso Unificado de Modelado, Primera Edicin, Editorial Addison Wesley, 1999. 5.RUMBAUGH James Modelado y Diseo Orientado a Objetos con OMT, Primera Edicin, Editorial Addison Wesley, 1998

REPUBLICA BOLIVARIANA DE VENEZUELA MINISTERIO DEL PODER POPULAR PARA LA EDUCACIN SUPERIOR PROGRAMA NACIONAL DE FORMACIN SISTEMAS E INFORMTICA ALDEA UNIVERSITARIA BOLIVARIANA EL VENADO

PROCESO UNIFICADO

VIII. Trimestre Seccin U SISTEMA II BR. Julie Lpez. CH.

Prof.: ING. CARLOS BERTI

ABRIL 2012.