Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

METODO RUP

No description
by

lorena sanabria

on 30 March 2017

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of METODO RUP

Fue creado por Grady Booch (creador del método Booch), Ivar Jacobson y James Jacobson (Creador de la Técnica de Modelado de Objetos), la misma aparece en Junio de 1998 con el acrónimo RUP
A inicios de 1999 y su funcionamiento se centraba en las personas, los procesos y las herramientas.
Es un conjunto de metodologías
adaptables al contexto y
necesidades de cada organización
QUE ES ?
ARTEFACTOS
METODO RUP
Programación organizada.
Menor taza de errores.
Satisfacción del programador.
Solución de errores de programas
Versiones nuevas
Implementa una forma de trabajo donde se adapte fácilmente a las circunstancias
Es recomendable emplearlo solo en proyectos a corto plazo

VENTAJAS
DESVENTAJAS
Es recomendable emplearlo solo en proyectos a corto plazo.
Altas comisiones en caso de fallar.
Tal vez sea necesario complementarlo con otras metodologias agiles como por ejemplo XP
Por el grado de complejidad puede ser no muy adecuado
En proyectos pequeños, es posible que no se puedan cubrir los costos de dedicación del equipo de profesionales necesario
ROLES
HISTORIA
1995 se anexa el enfoque RATIONAL dando paso a ROP (Rational Objetory Process) que junto a la OMT (Objects Modeling Technique) de Rumbaugh y Booch lo que permitió dar origen a UML, esta herramienta fortaleció mucho mas a ROP en el empleo de caso de usos.
1996 surge ROP 4.1 con la integración de
actividades SQA (Software Quality Assurance, Software de Control de Calidad por sus siglas
en ingles), esto permitía el aseguramiento de
un software de calidad que se adapte a las necesidades del usuario final
Para 1998 se lanza al mercado una fase de prueba, con un UML fortalecido y la integración de los enfoques de la ingeniería de Negocios y la
Ingeniería de Datos a partir de aquí nace RUP, con
los lineamientos y vertientes que hoy día conocemos
Proceso Unificado Racional
Su objetivo es asegurar la producción de software
de alta y de mayor calidad para
satisfacer las necesidades de los usuarios
diagramas de los
casos de uso
, manejo de los
riesgos
y el manejo de la
arquitectura
como tal
ETAPAS
INICIO
Esta fase tiene como propósito definir y acordar el alcance del proyecto con el cliente
identificar los riesgos asociados al proyecto
proponer una visión muy general de la arquitectura de software
producir el plan de las fases
ELABORACION
se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase
se realiza la especificación de los casos de uso seleccionados y el primer análisis del dominio del problema
se diseña la solución preliminar.
DESAROLLO
Es completar la funcionalidad del sistema, para ello se deben clarificar los requerimientos pendientes
administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios
se realizan las mejoras para el proyecto
CIERRE
es asegurar que el software esté disponible para los usuarios finales,
ajustar los errores y defectos encontrados en las pruebas de aceptación
capacitar a los usuarios y proveer el soporte técnico necesario.
Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.
CARACTERISTICAS
Disciplina en la asignación de tareas y responsabilidades
Implementa las mejores practicas de la ingeniería de software
Propone un desarrollo iterativo
Permite la administración de requisitos
Control a los cambios
Ofrece un modelamiento visual del software
Incorpora la validación de calidad del software
INICIO
INICIO
Documento Visión (contiene necesidades y características)

Especificación de Requisitos

Modelo de Análisis del Negocio:

Diagrama de Actividades (un diagrama por cada proceso).
Modelo del Dominio. Es un diagrama de clases conceptuales donde cada clase
sólo debe tener atributos
ELABORACION
ELABORACION
Modelo de Casos de Uso:


Diagrama de casos de uso.

Especificación de casos de uso (utilizar una plantilla o formato). Se debe seleccionar sólo los casos de uso de alta prioridad o más importantes para elnegocio, del tipo Core.
Prototipos de usuario. Son los diseños de interfaz de usuario que serán implementados.Seleccionar los casos de uso más importantes
DESAROLLO
DESARROLLO
Programación de las funcionalidades o casos de uso del tipo administrativo o CRUD.

Se puede documentar los componentes o clases implementadas más importantes
CIERRE
CIERRE
Diagrama de despliegue.

Manual de usuario.

Manual de instalación y configuración
TIEMPOS
EJEMPLO DE INGENIERIA
CONCLUSIONES
Este metodo se pude decir que es uno de los que mas brinda objetivos amplios ya que se puede ir haciendo cambios a las etapas para una optimizacion mejor para su desarrollo y este metodo nos brinda un enfoque mas controlado para la ejecucion.
BIBLIOGRAFIA
http://kelycamacho.blogspot.com.co/p/artefactos.html

https://es.scribd.com/document/50897856/ENTREGABLES-RUP-MODELOS-Y-DIAGRAMAS

http://rupmetodologia.blogspot.com.co/

https://procesosdesoftware.wikispaces.com/METODOLOGIA+RUP

http://adrianarzaroli.blogspot.com.co/2015/11/clase-xi-virtual-metodologia-rup-scrum.html
Full transcript