EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE 1.- Breve Historia del PUDS.

La Ingeniera del Software nace como una disciplina para aplicar los principios, tc nicas y herramientas de desarrollo de software (Metodologa) Surgi porque todos los desarrolladores en la dcada de los 80s, realizaban el softwa re de forma artstica, es decir utilizando mtodos y tcnicas adhoc donde la experienc ia (el ensayo-error) era el camino a seguir. Este enfoque produjo grandes y exit osos productos de programacin pero conforme los proyectos se volvieron ms complejo s, llev a que se produjera software sin calidad, se incumplieran los presupuestos y se incrementara dramticamente los costos de mantenimiento. La solucin propuesta fue aplicar mtodos y principios que han sido utilizados y pro bados en la experiencia para producir de forma inequvoca productos que corran efi cientemente y se ejecuten sobre mquinas reales. En la dcada de los 70 surgieron una gran variedad de metologistas y metodologas en tre ellos Yourdon y demarco cuyas investigaciones se basaban en los principios d e la programacin estructurada. En los 80s y 90s el paradigma estructurado evolucion hacia el paradigma orientado a objetos, en el perodo de 1989 y 1994 se cre la llamada guerra de mtodos dentro de la comunidad orientada a objetos existiendo un incremento de menos de diez a ms d e cincuenta metodologas. Es as que los desarrolladores de software quedaron muy confundidos sin saber cual era la metodologa ms adecuada para elaborar sus proyectos. En un esfuerzo para es tandarizar las notaciones y procesos a utilizar, se conform un consorcio liderado por la empresa Rational y por las principales empresas del Mundo de la industria de la informtica. UML oficialmente se present cuando Rumbaugh, Booch y Jacobson unifican sus estudi os con una semntica y Notacin Para lograr compatibilidad en el anlisis y diseo orien tado a objetos. A travs de la historia se han desarrollado varios modelos de proceso de software (paradigmas de desarrollo) cada uno con sus ventajas, desventajas y utilidad en algunos tipos de proyectos y problemas. Al igual que cualquier notacin, el proces o unificado acta como un modelo que puede adaptarse a cualquier tipo de proyecto y empresa (grandes y pequeas). Las caractersticas del proceso unificado de modelado son: Centrado en los Modelos : Los diagramas son un vehculo de comunicacin ms expresivo que las descripciones en lenguaje natural. 2.-Descripcin del PUDS. El proceso unificado: Dirigido por Casos de Uso, Centrado en la Arquitectura y I terativo e Incremental. 2.1.- Esquema Grafico. Se trata de minimizar el uso de descripciones y especificaciones textuales del s istema. 2.2.- Caractersticas del PUDS. Guiado por lo casos de uso: Los casos de uso son el instrumento para validar la arquitectura del software y extraer los casos de prueba.

Si tenemos definidos bien nuestros casos de uso el resultado ser un producto corr ecto. Centrado en la arquitectura: Define una forma de organizar de las diferentes partes que tenga el software. Lo que se busca es que el software sea flexible(a la hora de realizar cambios). Los modelos son proyecciones del anlisis y el diseo constituye la arquitectura del producto a desarrollar. Iterativo e incremental: Es Iterativo porque cada fase se repite. Incremental porque cada ciclo genera una nueva versin que mejora las funcionalida des del anterior (asta llegar al producto terminado o deseado). 3.- Fases del PUDS. El proceso unificado: Dirigido por Fase de Inicio: Durante la esta fase, se desarrolla una descripcin del producto final a partir de una buena idea y se presenta el anlisis de negocio para el producto. Esencialmen te, 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 cuanto costara desarrollar el producto? La respuesta a la primera pregunta se encuentra en un modelo de casos de uso sim plificado que contenga los casos de uso ms crticos. Cuando lo tengamos, la arquite ctura es provisional, y consiste tpicamente en un simple esbozo que muestra los subsistemas ms importantes . En esta fase, se identifican y priorizan los riesgos ms importantes, se planifi ca en detalle la fase de elaboracin, y se estima el proyecto de manera aproximada . Fase de Elaboracin: Durante esta fase, se especifican en detalle la mayora de los casos de uso del pr oducto y se disea la arquitectura del sistema. La relacin entre la arquitectura de l sistema y el propio sistema es primordial. Una manera simple de expresarlo es decir que la arquitectura es anloga al esqueleto cubierto por la piel pero con mu y poco musculo (el software) entre los huesos y la piel solo lo necesario para p ermitir que el esqueleto haga movimientos bsicos. El sistema es el cuerpo entero con esqueleto, piel y msculos. Por tanto, la arquitectura se expresa en forma de vistas de todos los modelos de l sistema, los cuales juntos representan al sistema entero. Esto significa que h ay vistas arquitectnicas del modelo de casos de uso, del modelo de anlisis, del mo delo de diseo, del modelo de implementacin y del modelo de despliegue. La vista de l modelo de implementacin incluye componentes para probar que la arquitectura es ejecutable. Durante esta fase del desarrollo, se realizan los casos de uso ms crti cos que se identificaron en la fase de comienzo. El resultado de esta fase es un a lnea base de la arquitectura. Al final de la elaboracin, el director del proyecto esta en disposicin de planific ar las actividades y estimar recursos necesarios para terminar el proyecto. Aqu l a cuestin fundamental es: son suficientemente estables los casos de uso, la arquit ectura y el plan, y estn los riesgos suficientemente controlados como para que se amos capaces de comprometernos al desarrollo entero mediante un contrato? Fase de Construccin: Durante esta fase, se crea el producto, se aaden los msculos (software terminado) al esqueleto (la arquitectura). En esta fase, la lnea base de la arquitectura cre ce hasta convertirse en el sistema completo. La descripcin evoluciona hasta conve rtirse en un producto preparado para ser entregado a la comunidad de usuarios. E l grueso de los recursos requeridos se emplea durante esta fase del desarrollo. Sin embargo, la arquitectura del sistema es estable, aunque los

desarrolladores pueden descubrir formas mejores de estructurar el sistema, ya qu e los arquitectos recibirn sugerencias de cambios arquitectnicos de menor importan cia. Al final de esta fase, el producto contiene todos los casos de uso que la direcc in y el cliente han acordado para el desarrollo de esta revisin. Sin embargo, pued e que no esta completamente libre de defectos. Muchos de estos defectos se descu brirn y solucionaran durante la fase de transicin. La pregunta decisiva es: cubre e l producto las necesidades de algunos usuarios de manera suficiente como para un a primera entrega? Fase de Transicin: Esta fase, cubre el periodo durante el cual el producto se convierte en versin be ta. En la versin beta un nmero reducido de usuarios con experiencia prueba el prod ucto e informa de defectos y deficiencias. Los desarrolladores corrigen los prob lemas e incorporan algunas de las mejoras sugeridas en una versin general dirigid as a la totalidad de la comunidad de usuarios. La fase de transicin conlleva acti vidades 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) y los que pueden corregirse en la siguiente versin normal.