You are on page 1of 4

El Proceso Unificado de Desarrollo de Software (RUP

)
Introducción
El Proceso Unificado es un proceso de software genérico que puede ser utilizado para una gran cantidad de tipos de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes tamaños de proyectos. Provee un enfoque disciplinado en la asignación de tareas y resposa ilidades dentro de una organización de desarrollo. !u meta es asegurar la producción de software de muy alta calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario y presupuesto predeci le. El Proceso Unificado tiene dos dimensiones "#igura $%& • • Un e'e (orizontal que representa el tiempo y muestra los aspectos del ciclo de vida del proceso a lo largo de su desenvolvimiento Un e'e vertical que representa las disciplinas, las cuales agrupan actividades de una manera lógica de acuerdo a su naturaleza.

)a primera dimensión representa el aspecto dinámico del proceso conforme se va desarrollando, se e*presa en términos de fases, iteraciones e (itos "milestones%. )a segunda dimensión representa el aspecto estático del proceso& cómo es descrito en términos de componentes del proceso, disciplinas, actividades, flu'os de tra a'o, artefactos y roles.

)os casos de uso capturan los requerimientos funcionales. -e (ec(o. En este conte*to. fueron desarrollados a la par. El Proceso Unificado es dirigido por casos de uso Un sistema de software se crea para servir a sus usuarios.a con el sistema por desarrollar. Por lo tanto. El Proceso Unificado usa el )engua'e de . lo que significa que el sistema en construcción está (ec(o de componentes de software interconectados por medio de interfaces ien definidas "well+defined interfaces%. sino a otros sistemas. El término usuario se refiere no solamente a los usuarios (umanos. para construir un sistema e*itoso se de e conocer qué es lo que quieren y necesitan los usuarios prospectos. el término usuario representa algo o alguien que interact. )os aspectos distintivos del Proceso Unificado están capturados en tres conceptos clave& dirigido por casos de uso "use+case driven%.nico al Proceso Unificado. Esto es lo que (ace . /odos los .#igura $ El Proceso Unificado se asa en componentes "component+ ased%.odelado Unificado "U. U.) es una parte integral del Proceso Unificado. centrado en la arquitectura "arc(itecture+ centric%. Un caso de uso es una pieza en la funcionalidad del sistema que le da al usuario un resultado de valor.)% en la preparación de todos los planos del sistema. iterativo e incremental.

!imilarmente. el cual a su vez viene con la e*periencia. sistemas legados. la arquitectura en un sistema de software es descrita como diferentes vistas del sistema que está siendo construido. no son elegidos de manera aislada. )a arquitectura surge de las necesidades de la empresa. plomer3a. servicios. tam ién está influenciada por muc(os otros factores. )a arquitectura es la vista del diseño completo con las caracter3sticas más importantes (ec(as más visi les y de'ando los detalles de lado. fle*i ilidad en los cam ios futuros "resilience% y reuso. Es un pro lema del 8(uevo y la gallina9. el valor de la arquitectura depende del personal asignado a esta tarea. En este caso función corresponde a los casos de uso y forma a la arquitectura. dirigen el proceso de desarrollo. esto es. Esto le permite al constructor ver una radiograf3a completa antes de empezar a construir. consideraciones de instalación. 4. acomodarse en la arquitectura.n y cuando los casos de uso dirigen el proceso. el proceso ayuda al arquitecto a enfocarse en las metas correctas. !in em argo. El edificio se mira desde diferentes puntos de vista& estructura. esto es. Uno sólo de los dos no es suficiente. la disponi lidad de componentes reutiliza les. Por otra parte. Por lo tanto. !in em argo. Por una parte. los casos de uso de en. El Proceso Unificado está centrado en la arquitectura El papel del arquitecto de sistemas es similar en naturaleza al papel que el arquitecto desempeña en la construcción de edificios. cuando son realizados. requerimientos no funcionales "e'.casos de uso 'untos constituyen el modelo de casos de uso el cual descri e la funcionalidad completa del sistema. desempeño. nos fuerzan a pensar en términos del valor a los usuarios y no solamente en términos de las funciones que ser3a ueno que tuviera. y tal y como están refle'adas en los casos de uso. E*iste la necesidad de intercalar entre casos de uso y arquitectura. la arquitectura . Estas dos fuerzas de en estar alanceadas para o tener un producto e*itoso. tam ién dirigen su diseño. 07ómo se relacionan los casos de uso con la arquitectura2 7ada producto tiene función y forma. los casos de uso no son solamente una (erramienta para especificar los requerimientos del sistema. !in em argo. confia ilidad%. etc. !on desarrollados a la par con la arquitectura del sistema. tales como claridad "understanda ility%. 6a que lo importante depende en parte del criterio. Este modelo reemplaza la tradicional especificación funcional del sistema. los casos de uso dirigen la arquitectura del sistema y la arquitectura del sistema influencia la elección de los casos de uso. tales como la plataforma de software en la que se e'ecutará. implementación y prue as. electricidad. al arquitectura del sistema y los casos de uso maduran conforme avanza el ciclo de vida. El concepto de arquitectura de software involucra los aspectos estáticos y dinámicos más significativos del sistema. Una especificación funcional tradicional se concentra en responder la pregunta& 01ué se supone que el sistema de e (acer2 )a estrategia de casos de uso puede ser definida agregando tres pala ras al final de la pregunta& 0por cada usuario2 Estas tres pala ras tienen una implicación importante. tal y como las interpretan los usuarios y otros sta5e(olders.

Para ser más efectivo. la iteración trata con un grupo de casos de uso que en con'unto e*tienden la usa ilidad del producto. 7ada mini+proyecto es una iteración que finaliza en un incremento. El Proceso Unificado es Iterativo e Incremental -esarrollar un producto de software comercial es una tarea enorme que puede continuar por varios meses o años. esto es. )as iteraciones sucesivas construyen los artefactos del desarrollo a partir del estado en el que fueron de'ados en la iteración anterior. )os desarrolladores asan su selección de qué van a implementar en una iteración en dos factores. de en ser seleccionadas y llevadas a ca o de una manera planeada. las iteraciones de en estar controladas. 7uando la iteración no cumple con sus metas. implementan el diseño en componentes y verifican que los componentes satisfacen los casos de uso.a con la siguiente iteración. En la realidad. )as iteraciones se refieren a pasos en el flu'o de tra a'o. !i una iteración cumple sus metas : y usualmente lo (ace : el desarrollo contin. la iteración trata con los riesgos más importantes. En cada iteración. crean el diseño usando la arquitectura como gu3a. los desarrolladores identifican y especifican los casos de uso relevantes. . am os arquitectura y casos de uso de en evolucionar en paralelo. los desarrolladores de en revisar sus decisiones previas y pro ar un nuevo enfoque. !egundo.de e proveer espacio para la realización de todos los casos de uso. Primero. (oy y en el futuro. Es práctico dividir el tra a'o en pequeños pedazos o mini+proyectos. los incrementos se refieren a crecimiento en el producto.