Metodologia Rup

METODOLOGIA RUP (Rational Unified Process) y LENGUAJE UNIFICADO DE MODELADO (UML)

Tecnicas de Programación

Hans Ricardo Garcia Bedoya

Presentado a:
Ing. Salatiel Toro

Corporación Unificada Nacional de Educación Superior
2012
Tolima

Indice:
I Metodologia RUP
1. Definición………………………………………………………………………..pág. 3
2. Importancia…..………………………………………………………………....pág. 4
3. Ventajas ydesventajas……………………………………………………….pag. 5
4. Ciclo de vida…………………………………………………………………….pág. 6
5. Principales características…………………………………………………...pág. 7
6. Aspectos…………………………………………………………………………pág. 8
7. Artefactos………………………………………………………………………...pág. 9
8. Elementos………………………………………………………………………pág. 10

II UML
2. Definición……………………………………………………………………… pág. 11
2.1 Criticas…………………………………………………………………….pág. 12
2.2 Estandarización…………………………………………………………..pág. 12

1. DEFINICION
Rational Unified Process (RUP)
Es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. Es un conjunto de metodologías adaptables al contexto ynecesidades de cada organización. El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una personapuede desempeñar distintos roles a lo largo del proceso).

2. IMPORTANCIA
El RUP está basado en 6 principios clave que son los siguientes:
Adaptar el proceso
El proceso deberá adaptarse a las necesidades del cliente ya que es muy importante interactuar con él. Las características propias del proyecto u organización. El tamaño del mismo, así como su tipo o las regulaciones que lo condicionen,influirán en su diseño específico. También se deberá tener en cuenta el alcance del proyecto en un área subformal.
Equilibrar prioridades
Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se podrán corregir desacuerdos que surjan en elfuturo.
Demostrar valor iterativamente
Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados
Colaboración entre equipos
El desarrollo de software no lo hace una única persona sino múltiples equipos.Debe haber una comunicación fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc.
Elevar el nivel de abstracción
Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita que los ingenieros de software vayan directamente de los requisitos a lacodificación de software a la medida del cliente, sin saber con certeza qué codificar para satisfacer de la mejor manera los requisitos y sin comenzar desde un principio pensando en la reutilización del código. Un alto nivel de abstracción también permite discusiones sobre diversos niveles y soluciones arquitectónicas. Éstas se pueden acompañar por las representaciones visuales de la arquitectura,por ejemplo con el lenguaje UML.
Enfocarse en la calidad
El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente.

3. Ventajas y desventajas

Ventajas:

• Este modelo es útil cuando el cliente conoce los objetivos generales...