UNIVERSIDAD TECNOLGICA DE LOS ANDES FILIAL CUSCO CARRERA PROFESIONAL DE INGENIERIA DE SISTEMAS E INFORMATICA

INFORME DEL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE PUDS

ASIGNATURA: INGENIERIA DE SOFTWARE DOCENTE: ING. CARLOS VILLAGARCIA RIVERA ALUMNO: EDWIN MIJAIL ALARCON HUANACO

Cusco Per 2012

1. HISTORIA DEL PUDS.

La Ingeniera del Software nace como una disciplina para aplicar los principios, tcnicas y herramientas de desarrollo de software (Metodologa). Surgi porque todos los desarrolladores en la dcada de los 80, realizaban el software de forma artstica, es decir utilizando mtodos y tcnicas adhoc donde la experiencia (el ensayo-error) era el camino a seguir. Este enfoque produjo grandes y exitosos 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 probados en la experiencia para producir de forma inequvoca productos que corran eficientemente y se ejecuten sobre mquinas reales. En la dcada de los 70 surgieron una gran variedad de metologistas y metodologas entre ellos Yourdon y demarco cuyas investigaciones se basaban en los principios de 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 de cincuenta metodologas. Es as que los desarrolladores de software quedaron muy confundidos sin saber cul era la metodologa ms adecuada para elaborar sus proyectos. En un esfuerzo para estandarizar 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 estudios con una semntica y Notacin Para lograr compatibilidad en el anlisis y diseo orientado 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 proceso 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.

EVOLUCION DEL PUDS.

El proceso unificado est equilibrado por ser el producto final de tres dcadas de desarrollo y uso prctico. Su desarrollo como producto sigue un camino desde el Proceso Objectory (1987), pasando por el Proceso Objectory de Rational (1997) hasta el Proceso Unificado Rational (1998). Su desarrollo ha recibido influencias de muchas fuentes. Sin embargo describiremos la influencia sobre el producto de los mtodos de Ericsson y de Rational, as como el de varias otras fuentes.
Proceso Unificado de Rational 5.0

Proceso Objectory de Rational 4.1

Proceso Objectory Rational 1.0-3.8 1987-1995

Mtodo de Ericsson
Como primer paso hacia el alumbramiento del desarrollo del proceso unificado. Nos remontaremos a 1967 para esbozar los logros de Ericsson [14], [15], [16]. Ericsson modelaba el sistema

entero como un conjunto de bloques interconectados (en UML, se los conoce como subsistemas y se implementan mediante componentes). Despus, ensamblaba los bloques de ms bajo nivel en subsistemas de ms alto nivel, para hacer el sistema ms manejable. Identificando los bloques estudiando los casos de negocio hoy conocidos como caso de uso-. Sus actividades de diseo producan un conjunto de diagramas de bloques, simplificados en que solo mostraban las asociaciones que se utilizaban para comunicaciones. El primer producto del trabajo de las actividades de diseo era una descripcin de arquitectura software. Se basaba en la comprensin de los requisitos ms crticos, y describa brevemente cada bloque y su agrupamiento en subsistemas. Un conjunto de diagramas de bloques describan a los bloques y a sus interconexiones. Sobre las interconexiones se comunicaban seales, un tipo de mensaje. La descripcin de la arquitectura software y la biblioteca de mensajes eran los documentos fundamentales que guiaban el trabajo de desarrollo. En esencia, el mtodo que utilizaban era el que hoy conocemos como desarrollo basado en componentes. Ivar Jacobson fue el creador de este mtodo de desarrollo.

El lenguaje de descripcin y especificacin

El estndar publicado en 1976 por la CCITT el organismo internacional para la estandarizacin del rea de las telecomunicaciones del lenguaje de especificacin y descripcin (SDL) influencio significativamente en el mtodo de Ericsson, especificaba al sistema como el conjunto de bloques, que se comunicaban con mensajes llamados seales, cada bloque tena un conjunto de procesos. Los procesos posean instancia al igual como en POO; SDL ser sustituido por UML, que se estandariz en 1997.

Objectory
En 1987 Ivar Jacobson dejo Ericsson y fundo OBJECTORY AB en Estocolmo, desarrollando OBJECTORY (abreviatura de Object Factory =fabrica de objetos), extendiendo su uso en otras industrias adems de las telecomunicaciones, y en otros pases aparte de Suiza.

Aunque el concepto de caso de uso haba estado presente en el trabajo de Ericsson., (se presento en la conferencia OOPSLA de 1987), se haba desarrollado una tcnica de representacin, es decir los casos de uso que dirigan el desarrollo se hicieron ms claros. Los flujos de trabajo sucesivos se representaron en una serie de modelos requisitos-casos de uso, anlisis, diseo, implementacin y prueba. Un modelo es una perspectiva del sistema.las relaciones entre los modelos de esta serie eran importantes para los desarrolladores como forma de hacer el seguimiento de una caracterstica de un extremo a otro de la serie de modelo El desarrollo del proceso Objectory contino en una serie de versiones, desde Objectory1.0 en 1988, Objectory 3.8 en 1995. El producto Objectory llego a hacer visto como un sistema y poda llegarse a desarrollar una mejor versin a partir de una anterior e hizo ms fcil el ajustarlo para cubrir necesidades especficas de diferentes organizaciones de desarrollo.

El mtodo de Rational
Rational Software Corporation compr Objectory AB a finales de 1995. Las dos contribuciones ms importantes al proceso fueron el nfasis en la arquitectura y en el desarrollo iterativo. Tena una representacin de la arquitectura de 4 vistas: vista lgica, vista de procesos, vista fsica y vista de desarrollo, mas una vista adicional que ilustraba las primeras cuatro vistas mediante casos de uso o escenarios. La idea de idea de tener un conjunto de vistas, en lugar de tratar de meter todo en un nico tipo de diagrama, las vistas mltiples permitieron encontrar, tanto usuarios, desarrolladores, lo que necesitaban para sus diferentes objetivos. El desarrollo iterativo tena un mtodo de 4 fases (comienzo, elaboracin, construccin y transicin) para estructurar mejor y controlar el proceso durante las iteraciones. Booch tambin estuvo presente en los inicios de Rational en 1996. Para que un proyecto OO tenga xito, debe aplicarse un proceso iterativo e incremental

El proceso Objectory de Rational 1995-1997

Objectory 3.8 demuestra que se puede crear y modelar un proceso de desarrollo de software como si fuese un producto, haba identificado un conjunto de modelos que documentaban el resultado

del proyecto, en reas de modelado de casos de uso, anlisis y diseo bien desarrollado pero tena reas como la implementacin y pruebas que no lo estaban. Por ello se aadieron la experiencia y prcticas de Rational para formar Objectory de Rational 4.1 y se aadieron la fase iterativa controlada, se desarrollo una definicin precisa de la arquitectura. Se desarroll una definicin precisa de la arquitectura, considerada como la parte ms significativa de la organizacin del sistema. Se ampli el desarrollo iterativo, pasando de ser un concepto relativamente general a ser un mtodo dirigido por los riesgos que se consideraba la arquitectura en primer lugar. En estos momentos UML estaba en desarrollo y se incorporo como el Lenguaje de modelado del Proceso de Objectory de Rational (Rational Objectory Process, ROP).

El lenguaje unificado de modelado

Graddy Booch autor del mtodo Booch y James Rumbaugh desarrollador principal de OMT (Object Modelling Technique), en 1994 se incorporaron a Rational y unificaron sus mtodos, en coordinacin con muchos clientes de Rational, pblico la versin 0.8 en Octubre de 1995 del Mtodo Unificado. Luego se incorporo Ivar Jacobson a Rational. Los tres publicaron la versin 0.9 del Lenguaje Unificado de Modelado, luego con el esfuerzo de otras metodologas y empresas como IBM, HP y Microsoft lograron la estandarizacin. El Object Management Group public como estndar la versin 1.1 del Lenguaje Unificado de Modelo

El Proceso Unificado de Rational

Rational compro o se fusiono a otras empresas y fabricantes de herramientas y su experiencia el rea de procesos se ampliaron, se ampli con un nuevo flujo de trabajo para el modelado de negocio para obtener requisitos. Tambin se extendi con diseo de interfaces de usuario dirigido por los casos de uso. Cada una de ellas aportaron con sus experiencias en esta nueva fusin.

En 1998 el Proceso Objectory de Rational se haba convertido en un proceso hecho y derecho, capaz de soportar el ciclo de vida del

desarrollo en su totalidad. En junio Rational publico su versin, El proceso unificado de Rational 5.0, a disposicin del pblico. Diagramas de UML Para Booch, Rambaugh y Jacobson. Los distintos diagramas que se pretenden obtener de un sistema mediante UML son: Diagramas de casos de uso. Diagramas de clases. Diagramas de comportamiento o interaccin. Entre ellos: Diagramas de estado. Diagramas de actividad. Diagramas de secuencia. Diagramas de colaboracin. Diagramas de implementacin. Diagrama de componente. Diagrama de plataforma.

Diagramas de casos de uso.

Un caso de uso es una secuencia de operaciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interaccin con los usuarios y otros sistemas. Un actor es una entidad externa al sistema que se modela y que puede interactuar con l. Un ejemplo de actor puede ser un usuario o cualquier otro sistema.

Diag. Casos de uso Afiliar y Autorizar Usuario

Diagramas de Clases.
Muestra un conjunto de elementos del modelo que son estticos, como las clases y los tipos, junto con sus contenidos y las relaciones que se establecen entre ellos.

Diagramas de interaccin o comportamiento.

Muestran las interacciones entre objetos ocurridas en un escenario (parte) del sistema. Hay varios tipos:

Diagramas de secuencia: modelan las interacciones entre un conjunto de objetos, ordenadas segn el instante en que tienen lugar.

Diag secuencia Afiliar autorizar Usuario

 Diagramas de colaboracin: muestran la interaccin entre varios objetos y los enlaces que existen entre ellos. Diag colaboracion Afiliar autorizar Usuario

Diagramas de actividad: son similares a los diagramas de flujo de otras metodologas Orientadas a Objetos.

Diag actividad Afiliar autorizar Usuario

Diagramas de estado: representan la secuencia de estados por los que un objeto o una interaccin entre objetos pasa durante su tiempo de vida en respuesta a los eventos recibidos.

Diagramas de componentes.
Muestran las dependencias entre los distintos componentes

software, incluyendo componentes de cdigo fuente, binarios y ejecutables. Un componente es un fragmento de cdigo software que se utiliza para mostrar dependencias en tiempo de compilacin o en tiempo de ejecucin.