SlideShare una empresa de Scribd logo

Rational unified process rup

Jonathan Arana
Jonathan Arana
Jonathan AranaGerente General.

Rational unified process rup

1 de 30
Descargar para leer sin conexión
TATIANA
CARDENAS.

PARREÑO

JONATHAN ARANA MORA.
PATRICIO
RAMOS.

METODOLOGÍA RUP

AYERVE
QUÉ ES UN PROCESO?
• UN PROCESO DEFINE QUIÉN ESTÁ HACIENDO QUÉ,
CUÁNDO Y CÓMO PARA LOGRAR UN CIERTO OBJETIVO. EN
LA INGENIERÍA DE SOFTWARE EL OBJETIVO ES
CONSTRUIR UN PRODUCTO DE SOFTWARE Ó MEJORAR
ALGUNO EXISTENTE.
Requerimientos
Nuevos ó Modificados

Proceso de
Ingeniería de
Software

Sistema
Nuevo ó Modificado
EL PROBLEMA
Requerimientos

•Si un proceso es utilizado, equipos
funcionales
diferentes
normalmente
utilizan procesos y lenguajes de
modelación inconsistentes.
•La mayoría de los proyectos de software
utilizan procesos que no están bien
definidos. En su lugar los miembros del
equipo (re)inventan sus propios procesos.

•Los procesos no están apropiadamente
relacionados con herramientas, ó no
están propiamente automatizados.

Proceso

Pruebas
Análisis
Diseño

?

?

?

?
?
?

?

?

Herramienta
RATIONAL UNIFIED PROCESS
(RUP)
• CAPTURA VARIAS DE LAS M
EJO RES PRÁ CA EN
CTI S
EL DESARROLLO MODERNO DE SOFTWARE EN UNA
FORMA QUE ES APLICABLE PARA UN AMPLIO RANGO
DE PROYECTOS Y ORGANIZACIONES.
• ES UNA GUÍA DE CÓMO UTILIZAR DE MANERA
EFECTIVA UM
L.
• PROVEE A CADA MIEMBRO DE UN EQUIPO UN FÁCIL
ACCESO A UNA BASE DE CONOCIMIENTO CON GUÍAS,
PLANTILLAS Y HERRAMIENTAS PARA TODAS LAS
ACTIVIDADES CRÍTICAS DE DESARROLLO.
• CREA Y MANTIENE M DELO S, EN LUGAR DE
O
ENFOCARSE EN LA PRODUCCIÓN DE UNA GRAN
CANTIDAD DE PAPELES DE DOCUMENTACIÓN.
INCREMENTO DE LA
PRODUCTIVIDAD EN EQUIPO

Todos los miembros del equipo comparten
• 1 Base de conocimiento
• 1 Proceso
• 1 Vista de cómo desarrollar software
• 1 Lenguaje de modelamiento (UML)
Administrador
Base de Datos

Ingeniero de
Desempeño

Administrador de
Configuración

Líder de
Proyecto

Analista
Diseñador/
Desarrollador

Pruebas
6 MEJORES PRÁCTICAS
(BEST PRACTICES)
• RUP DESCRIBE COMO UTILIZAR DE FORMA EFECTIVA
PROCEDIMIENTOS COMERCIALES PROBADOS EN EL
DESARROLLO DE SOFTWARE PARA EQUIPOS DE
DESARROLLO DE SOFTWARE, CONOCIDOS COMO
“MEJORES PRÁCTICAS”.
Administración de Requerimientos
Desarrollo
Iterativo

Modelamiento Verificación de
Arquitecturas
Visual
la Calidad
con Componentes
Control de Cambios
Publicidad

Recomendados

Más contenido relacionado

La actualidad más candente

Personal Software Process / Sesion 01
Personal Software Process / Sesion 01Personal Software Process / Sesion 01
Personal Software Process / Sesion 01andres hurtado
 
Sesión 2: Visión General. El proceso del software
Sesión 2: Visión General. El proceso del softwareSesión 2: Visión General. El proceso del software
Sesión 2: Visión General. El proceso del softwareCoesi Consultoria
 
Especializacion karla florez
Especializacion karla florezEspecializacion karla florez
Especializacion karla florezkarlitaflorez
 
Modelos de desarrollo del software
Modelos de desarrollo del softwareModelos de desarrollo del software
Modelos de desarrollo del softwareGenesis Mamani
 
Sesion3 Gestion de Proyectos Software
Sesion3  Gestion de Proyectos SoftwareSesion3  Gestion de Proyectos Software
Sesion3 Gestion de Proyectos SoftwareOscar López
 
Ing 162-show.fin
Ing 162-show.finIng 162-show.fin
Ing 162-show.finalbj1in
 
Proceso Del Software
Proceso Del SoftwareProceso Del Software
Proceso Del Softwareleo_ruth
 
Ads1 2014 apu2008-ss_jujuy-clase2
Ads1 2014 apu2008-ss_jujuy-clase2Ads1 2014 apu2008-ss_jujuy-clase2
Ads1 2014 apu2008-ss_jujuy-clase2Diego Rios
 
Modelos de Procesos del Software Grupo 1
 Modelos de Procesos del Software Grupo 1 Modelos de Procesos del Software Grupo 1
Modelos de Procesos del Software Grupo 1ニコ コンドン
 
Proceso del software una visión general
Proceso del software una visión generalProceso del software una visión general
Proceso del software una visión generalRuth Hidalgo Tene
 
Seleccion de tecnicas de ingenieria de software
Seleccion de tecnicas de ingenieria de softwareSeleccion de tecnicas de ingenieria de software
Seleccion de tecnicas de ingenieria de softwareIngris Argueta
 

La actualidad más candente (19)

Personal Software Process / Sesion 01
Personal Software Process / Sesion 01Personal Software Process / Sesion 01
Personal Software Process / Sesion 01
 
Exposicion de ingenieria
Exposicion de ingenieriaExposicion de ingenieria
Exposicion de ingenieria
 
Sesión 2: Visión General. El proceso del software
Sesión 2: Visión General. El proceso del softwareSesión 2: Visión General. El proceso del software
Sesión 2: Visión General. El proceso del software
 
Rup jenny mallqui
Rup   jenny mallquiRup   jenny mallqui
Rup jenny mallqui
 
Especializacion karla florez
Especializacion karla florezEspecializacion karla florez
Especializacion karla florez
 
Patrones de Proceso BPM
Patrones de Proceso BPMPatrones de Proceso BPM
Patrones de Proceso BPM
 
Modelos de desarrollo del software
Modelos de desarrollo del softwareModelos de desarrollo del software
Modelos de desarrollo del software
 
Sesion3 Gestion de Proyectos Software
Sesion3  Gestion de Proyectos SoftwareSesion3  Gestion de Proyectos Software
Sesion3 Gestion de Proyectos Software
 
Ing 162-show.fin
Ing 162-show.finIng 162-show.fin
Ing 162-show.fin
 
Fases del Modelo PSP
Fases del Modelo PSPFases del Modelo PSP
Fases del Modelo PSP
 
Is.exp.3.323734
Is.exp.3.323734Is.exp.3.323734
Is.exp.3.323734
 
Proceso Del Software
Proceso Del SoftwareProceso Del Software
Proceso Del Software
 
Ads1 2014 apu2008-ss_jujuy-clase2
Ads1 2014 apu2008-ss_jujuy-clase2Ads1 2014 apu2008-ss_jujuy-clase2
Ads1 2014 apu2008-ss_jujuy-clase2
 
Modelos de Procesos del Software Grupo 1
 Modelos de Procesos del Software Grupo 1 Modelos de Procesos del Software Grupo 1
Modelos de Procesos del Software Grupo 1
 
Paradigmas
ParadigmasParadigmas
Paradigmas
 
Qué+es+ru..
Qué+es+ru..Qué+es+ru..
Qué+es+ru..
 
Proceso del software una visión general
Proceso del software una visión generalProceso del software una visión general
Proceso del software una visión general
 
Seleccion de tecnicas de ingenieria de software
Seleccion de tecnicas de ingenieria de softwareSeleccion de tecnicas de ingenieria de software
Seleccion de tecnicas de ingenieria de software
 
Clase1
Clase1Clase1
Clase1
 

Similar a Rational unified process rup

Modelos de los ciclos de vida
Modelos de los ciclos de vidaModelos de los ciclos de vida
Modelos de los ciclos de vidaKenneth Zamora
 
Herramientas y entornos de implementacion de software
Herramientas y entornos de implementacion de softwareHerramientas y entornos de implementacion de software
Herramientas y entornos de implementacion de softwareMiguel Sanchez
 
Metodologiarup 100914104343-phpapp02
Metodologiarup 100914104343-phpapp02Metodologiarup 100914104343-phpapp02
Metodologiarup 100914104343-phpapp02deyvis usan
 
16416960 modelo-cascada-espiralincremental
16416960 modelo-cascada-espiralincremental16416960 modelo-cascada-espiralincremental
16416960 modelo-cascada-espiralincrementalzaggy88
 
Clase 2 - Construccion de los SI.ppt
Clase 2 - Construccion de los SI.pptClase 2 - Construccion de los SI.ppt
Clase 2 - Construccion de los SI.pptrogergrefa1
 
Software Development Life Cycle
Software Development Life CycleSoftware Development Life Cycle
Software Development Life CycleRoxanaSantander4
 
Método cascada
Método cascadaMétodo cascada
Método cascadamariacebu
 
Método cascada
Método cascadaMétodo cascada
Método cascadamariacebu
 
Desarrollo de Software Guiado por Pruebas
Desarrollo de Software Guiado por PruebasDesarrollo de Software Guiado por Pruebas
Desarrollo de Software Guiado por Pruebas.. ..
 

Similar a Rational unified process rup (20)

Disciplina de desarrollo rup
Disciplina de desarrollo rupDisciplina de desarrollo rup
Disciplina de desarrollo rup
 
Rup.pptx
Rup.pptxRup.pptx
Rup.pptx
 
Metodologia rup
Metodologia rupMetodologia rup
Metodologia rup
 
Metodologia rup
Metodologia rupMetodologia rup
Metodologia rup
 
Metodologia rup
Metodologia rupMetodologia rup
Metodologia rup
 
Espoch
EspochEspoch
Espoch
 
Modelos de los ciclos de vida
Modelos de los ciclos de vidaModelos de los ciclos de vida
Modelos de los ciclos de vida
 
rup
ruprup
rup
 
Modelo evolutivo
Modelo evolutivoModelo evolutivo
Modelo evolutivo
 
Herramientas y entornos de implementacion de software
Herramientas y entornos de implementacion de softwareHerramientas y entornos de implementacion de software
Herramientas y entornos de implementacion de software
 
Taller 3.
Taller 3.Taller 3.
Taller 3.
 
Metodologiarup 100914104343-phpapp02
Metodologiarup 100914104343-phpapp02Metodologiarup 100914104343-phpapp02
Metodologiarup 100914104343-phpapp02
 
Metodo watch
Metodo watchMetodo watch
Metodo watch
 
Metodo watch
Metodo watchMetodo watch
Metodo watch
 
16416960 modelo-cascada-espiralincremental
16416960 modelo-cascada-espiralincremental16416960 modelo-cascada-espiralincremental
16416960 modelo-cascada-espiralincremental
 
Clase 2 - Construccion de los SI.ppt
Clase 2 - Construccion de los SI.pptClase 2 - Construccion de los SI.ppt
Clase 2 - Construccion de los SI.ppt
 
Software Development Life Cycle
Software Development Life CycleSoftware Development Life Cycle
Software Development Life Cycle
 
Método cascada
Método cascadaMétodo cascada
Método cascada
 
Método cascada
Método cascadaMétodo cascada
Método cascada
 
Desarrollo de Software Guiado por Pruebas
Desarrollo de Software Guiado por PruebasDesarrollo de Software Guiado por Pruebas
Desarrollo de Software Guiado por Pruebas
 

Rational unified process rup

  • 2. QUÉ ES UN PROCESO? • UN PROCESO DEFINE QUIÉN ESTÁ HACIENDO QUÉ, CUÁNDO Y CÓMO PARA LOGRAR UN CIERTO OBJETIVO. EN LA INGENIERÍA DE SOFTWARE EL OBJETIVO ES CONSTRUIR UN PRODUCTO DE SOFTWARE Ó MEJORAR ALGUNO EXISTENTE. Requerimientos Nuevos ó Modificados Proceso de Ingeniería de Software Sistema Nuevo ó Modificado
  • 3. EL PROBLEMA Requerimientos •Si un proceso es utilizado, equipos funcionales diferentes normalmente utilizan procesos y lenguajes de modelación inconsistentes. •La mayoría de los proyectos de software utilizan procesos que no están bien definidos. En su lugar los miembros del equipo (re)inventan sus propios procesos. •Los procesos no están apropiadamente relacionados con herramientas, ó no están propiamente automatizados. Proceso Pruebas Análisis Diseño ? ? ? ? ? ? ? ? Herramienta
  • 4. RATIONAL UNIFIED PROCESS (RUP) • CAPTURA VARIAS DE LAS M EJO RES PRÁ CA EN CTI S EL DESARROLLO MODERNO DE SOFTWARE EN UNA FORMA QUE ES APLICABLE PARA UN AMPLIO RANGO DE PROYECTOS Y ORGANIZACIONES. • ES UNA GUÍA DE CÓMO UTILIZAR DE MANERA EFECTIVA UM L. • PROVEE A CADA MIEMBRO DE UN EQUIPO UN FÁCIL ACCESO A UNA BASE DE CONOCIMIENTO CON GUÍAS, PLANTILLAS Y HERRAMIENTAS PARA TODAS LAS ACTIVIDADES CRÍTICAS DE DESARROLLO. • CREA Y MANTIENE M DELO S, EN LUGAR DE O ENFOCARSE EN LA PRODUCCIÓN DE UNA GRAN CANTIDAD DE PAPELES DE DOCUMENTACIÓN.
  • 5. INCREMENTO DE LA PRODUCTIVIDAD EN EQUIPO Todos los miembros del equipo comparten • 1 Base de conocimiento • 1 Proceso • 1 Vista de cómo desarrollar software • 1 Lenguaje de modelamiento (UML) Administrador Base de Datos Ingeniero de Desempeño Administrador de Configuración Líder de Proyecto Analista Diseñador/ Desarrollador Pruebas
  • 6. 6 MEJORES PRÁCTICAS (BEST PRACTICES) • RUP DESCRIBE COMO UTILIZAR DE FORMA EFECTIVA PROCEDIMIENTOS COMERCIALES PROBADOS EN EL DESARROLLO DE SOFTWARE PARA EQUIPOS DE DESARROLLO DE SOFTWARE, CONOCIDOS COMO “MEJORES PRÁCTICAS”. Administración de Requerimientos Desarrollo Iterativo Modelamiento Verificación de Arquitecturas Visual la Calidad con Componentes Control de Cambios
  • 7. DESARROLLO ITERATIVO DE SOFTWARE • DADOS LOS SISTEMAS DE SOFTWARE SOFISTICADOS DE LA ACTUALIDAD, NO ES POSIBLE HACER DE MANERA SECUENCIAL LA DEFINICIÓN COMPLETA DEL PROBLEMA, DISEÑAR LA SOLUCIÓN COMPLETA, CONSTRUIR EL SOFTWARE Y POR ÚLTIMO PROBARLO. • EL DESCUBRIMIENTO DE DEFECTOS EN FASES POSTERIORES DE DISEÑO DAN COMO RESULTADO UN AUMENTO EN LOS COSTOS Y/Ó LA CANCELACIÓN DEL PROYECTO. El tiempo y dinero gastados en la implementación de un diseño fallido, son no recuperables
  • 8. DESARROLLO ITERATIVO Requerimientos Análisis y Diseño Implementación Evaluación Pruebas Cada iteración produce un producto ejecutable
  • 9. CARACTERÍSTICAS DEL DESARROLLO ITERATIVO • PERMITE UN ENTENDIMIENTO INCREMENTAL DEL PROBLEMA A TRAVÉS DE REFINAMIENTOS SUCESIVOS. • HABILITA UNA FÁCIL RETROALIMENTACIÓN DE USUARIO. • METAS ESPECÍFICAS PERMITEN QUE EL EQUIPO DE DESARROLLO MANTENGA SU ATENCIÓN EN PRODUCIR RESULTADOS. • EL PROGRESO ES MEDIDO CONFORME AVANZAN LAS IMPLEMENTACIONES.
  • 10. ADMINISTRACIÓN DE REQUERIMIENTOS • LICITAR, ORGANIZAR, Y DOCUMENTAR LA FUNCIONALIDAD Y RESTRICCIONES REQUERIDAS. • LLEVAR UN REGISTRO Y DOCUMENTACIÓN DE CAMBIOS Y DECISIONES. • LOS REQUERIMIENTOS DE NEGOCIO SON FÁCILMENTE CAPTURADOS Y COMUNICADOS A TRAVÉS DE CASOS DE USO. • LOS CASOS DE USO SON INSTRUMENTOS IMPORTANTES DE PLANEACIÓN. Los casos de uso dirigen el trabajo desde el análisis hasta las pruebas realización influenciado por verifica Modelo de Diseño Modelo de Implementación Modelo de Prueba
  • 11. ARQUITECTURA BASADA EN COMPONENTES • SE ENFOCA EN EL PRONTO DESARROLLO DE UNA ARQUITECTURA EJECUTABLE ROBUSTA. • RESISTENTE AL CAMBIO MEDIANTE EL USO DE INTERFACES BIEN DEFINIDAS. • INTUITIVAMENTE COMPRENSIBLE. • PROMUEVE UN REUSO MÁS EFECTIVO DE SOFTWARE. • ES DERIVADA A PARTIR DE LOS CASOS DE USO MÁS IMPORTANTES.
  • 12. MODELACIÓN VISUAL DE SOFTWARE • CAPTURA LA ESTRUCTURA Y COMPORTAMIENTO DE ARQUITECTURAS Y COMPONENTES. • MUESTRA COMO ENCAJAN DE FORMA CONJUNTA LOS ELEMENTOS DEL SISTEMA. • MANTIENE LA CONSISTENCIA ENTRE UN DISEÑO Y SU IMPLEMENTACIÓN. • PROMUEVE UNA COMUNICACIÓN NO AMBIGUA.
  • 13. VERIFICACIÓN DE LA CALIDAD DEL SOFTWARE • CREA PRUEBAS PARA CADA ESCENARIO (CASOS DE USO) PARA ASEGURAR QUE TODOS LOS REQUERIMIENTOS ESTÁN PROPIAMENTE IMPLEMENTADOS. • VERIFICA LA CALIDAD DEL SOFTWARE CON RESPECTO A LOS REQUERIMIENTOS BASADOS EN LA CONFIABILIDAD, FUNCIONALIDAD, DESEMPEÑO DE LA APLICACIÓN Y DEL SISTEMA. • PRUEBA CADA ITERACIÓN Los problemas del software son de 100 a 1000 veces mas costosos de encontrar y reparar después del desarrollo
  • 14. CONTROL DE CAMBIOS DEL SOFTWARE • CONTROLAR, LLEVAR UN REGISTRO Y MONITOREAR CAMBIOS PARA PERMITIR UN DESARROLLO ITERATIVO. • ESTABLECE ESPACIOS DE TRABAJO SEGUROS PARA CADA DESARROLLADOR • PROVEE AISLAMIENTO DE CAMBIOS HECHOS EN OTROS ESPACIOS DE TRABAJO • CONTROLA TODOS LOS ARTEFACTOS DE SOFTWARE – MODELOS, CÓDIGO, DOCUMENTOS, ETC… Desarrollo en Paralelo Administración de Espacios de Trabajo Integración de Proceso REPORT ALERT Administración de Construcción
  • 15. ESTRUCTURA DE RUP • EL PROCESO PUEDE DESCRIBIRSE EN DOS DIMENSIONES, O A LO LARGO DE DOS EJES: • EL EJE HORIZONTAL REPRESENTA TI PO Y EM MUESTRA EL ASPECTO DINÁMICO DEL PROCESO, EXPRESADO EN TÉRMINOS DE CI CLO S, FA SES, I TERA O N CI ES, Y M ETA S. • EL EJE VERTICAL REPRESENTA EL ASPECTO ESTÁTICO DEL PROCESO; COMO ESTÁ DESCRITO EN TÉRMINOS DE A VI DES, A CTI DA RTEFA CTO S, TRA JA RES Y FLUJO S DE TRA JO . BA DO BA
  • 16. ESTRUCTURA DE RUP CONT. Fases Flujos de Trabajo de Procesos Inicio Elaboración Construcción Transición Modelación de Negocios Requerimientos Análisis y Diseño Contenido Implementación Prueba Desarrollo Flujos de Trabajo de Soporte Admin. Configuración Administración Ambiente Iteración(es) Preliminar Iter. #1 Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iteraciones Iter. #m Iter. #m+1
  • 17. FASES EN RUP • INICIO – DEFINE EL ALCANCE DEL PROYECTO • ELABOR ACIÓN – PLAN DEL PROYECTO, ESPECIFICACIÓN DE CARACTERÍSTICAS, ARQUITECTURA BASE • CONSTR UCCIÓN – CONSTRUIR EL PRODUCTO • TRANSICIÓN – TRANSICIÓN DEL PRODUCTO A LA COMUNIDAD DEL USUARIO Metas Principales Inicio Elaboración Construcción Transición Tiempo
  • 18. FASE DE INICIO • PROPÓSITO • ESTABLECER CASOS DE NEGOCIOS PARA UN NUEVO SISTEMA O PARA ALGUNA ACTUALIZACIÓN IMPORTANTE DE UN SISTEMA EXISTENTE • ESPECIFICAR EL ALCANCE DEL PROYECTO • RESULTADO • UNA VISIÓN GENERAL DE LOS REQUERIMIENTOS DEL PROYECTO, I.E., LOS REQUERIMIENTOS PRINCIPALES • UN MODELO INICIAL DE CASOS DE USO Y MODELO DEL DOMINIO (10-20%) • UN CASO DE NEGOCIOS INICIAL, INCLUYENDO: • EVALUACIÓN INICIAL DE RIESGOS • UNA ESTIMACIÓN DE LOS RECURSOS REQUERIDOS
  • 19. EJEMPLO DE DIAGRAMA DE CASO DE USO DE NEGOCIOS Caso de Negocios: modelar la empresa (como funciona la empresa a la que se le va a desarrollar el software)
  • 20. FASE DE ELABORACIÓN • PROPÓSITO • ANALIZAR EL DOMINIO DEL PROBLEMA • ESTABLECER UNA BUENA ARQUITECTURA • LIDIAR CON LOS ELEMENTOS DE RIESGO MÁS ALTOS DEL PROYECTO • DESARROLLAR UN PLAN COMPRENSIVO MOSTRANDO COMO EL PROYECTO SERÁ COMPLETADO • RESULTADO • UN MODELO DEL DOMINIO Y DE CASOS DE USO 80% COMPLETO • REQUERIMIENTOS SUPLEMENTARIOS QUE CAPTUREN LOS REQUERIMIENTOS NO FUNCIONALES Y CUALESQUIERA REQUERIMIENTOS QUE NO ESTÉN ASOCIADOS CON UN CASO DE USO ESPECÍFICO • UNA LISTA DE RIESGOS REVISADA
  • 21. FASE DE CONSTRUCCIÓN • PROPÓSITO • DESARROLLAR INCREMENTALMENTE PRODUCTO DE SOFTWARE COMPLETO EL CUAL ESTARÁ LISTO PARA SER TRANSFERIDO AL USUARIO • PRODUCTOS • UN MODELO COMPLETO DE DISEÑO Y CASOS DE USO • LIBERACIONES DE PRODUCTOS EJECUTABLES DE FUNCIONALIDAD INCREMENTAL • DOCUMENTACIÓN DE USUARIO • UNA LIBERACIÓN “BETA” DEL PRODUCTO
  • 22. FASE DE TRANSICIÓN • HACER LA TRANSICIÓN FINAL DEL PRODUCTO DE SOFTWARE AL USUARIO • PRODUCTOS • LIBERACIONES EJECUTABLES DE PRODUCTO • “PRUEBAS BETA” PARA VALIDAR EL NUEVO SISTEMA VS. LAS EXPECTACIONES DEL USUARIO • MANUALES DE USUARIO ACTUALIZADOS • DOCUMENTACIÓN DE DESARROLLO ACTUALIZADA • ESTÁ EL USUARIO SATISFECHO? • GASTOS REALES DE LOS RECURSOS VS. GASTOS PREVISTOS  ACEPTABLES?
  • 23. ITERACIONES • CADA FASE EN RUP PUEDE DESCOMPONERSE EN ITERACIONES. UNA I TERA Ó N ES UN CICLO DE CI DESARROLLO COMPLETO DANDO COMO RESULTADO UNA ENTREGA DE PRODUCTO EJECUTABLE (INTERNA O EXTERNA) Liberaciones Inicio Iteración Preliminar Elaboración Construcción Transición Iteración de Iteración de Iteración de Iteración de Iteración de Arquitectura Arquitectura Desarrollo Desarrollo Desarrollo iteraciones internas Iteración de Iteración de Transición Transición externas
  • 24. NOCIÓN DE PROCESO Actividad/Cómo? Trabajador/Quién? Rol que puede ser desempeñado por un individuo o conjunto de individuos en la organización de desarrollo Diseñador responsable de Caso de Uso Paquete de Caso de Uso Describe una unidad de trabajo que puede ser asignada a un trabajador. Diseño de Casos de uso Artefacto/Qué? Pieza de información que es producida, modificada, ó utilizada por un proceso
  • 25. MODELOS Y FLUJOS DE TRABAJO • UNA MERA ENUMERACIÓN DE TODOS LOS TRABAJADORES, ACTIVIDADES Y ARTEFACTOS NO CONSTITUYEN UN PROCESO. SE NECESITA UNA FORMA DE DESCRIBIR SECUENCIAS SIGNIFICATIVAS QUE PRODUZCAN ALGÚN RESULTADO VÁLIDO, Y QUE MUESTRE LA INTERACCIÓN ENTRE TRABAJADORES. • UN FLUJO DE TRA JO ES UNA SECUENCIA DE BA ACTIVIDADES QUE PRODUCEN UN RESULTADO DE VALOR OBSERVABLE. • EN TÉRMINOS DE UML PUEDEN SER EXPRESADOS COMO UN DIAGRAMA DE SECUENCIA, UN DIAGRAMA DE COLABORACIÓN, Ó COMO UN DIAGRAMA DE ACTIVIDAD. • LOS GRUPOS DE TRABAJO AGRUPAN ACTIVIDADES
  • 26. MODELOS Y FLUJOS DE TRABAJO CONT. Cada flujo de trabajo describe como crear y mantener un modelo en particular Modelación de Negocios Modelo de Negocios Flujo de Trabajo de Requerimientos Flujo de Trabajo de Diseño de Análisis realizado por Modelo de Caso de Uso Implementado por Modelo de Diseño Flujo de Trabajo de Implementación Flujo de Trabajo de Prueba verificado por Modelo de Implementación Modelo de Prueba
  • 27. VENTAJAS  REQUIERE CONOCIMIENTOS DEL PROCESO Y DE UML.  PROGRESO  EL USO VISIBLE DE EN LAS ETAPAS ITERACIONES TEMPRANAS. (ACTIVIDADES)  PERMITE EVALUAR TEMPRANAMENTE LOS RIESGOS EN LUGAR DE DESCUBRIR PROBLEMAS EN LA INTEGRACIÓN FINAL DEL SISTEMA  FACILITA LA REUTILIZACIÓN DEL CÓDIGO TENIENDO EN CUENTA QUE SE REALIZAN REVISIONES EN LAS PRIMERAS ITERACIONES LO CUAL ADEMÁS PERMITE QUE SE APRECIEN OPORTUNIDADES DE MEJORAS EN EL DISEÑO.
  • 28. • RUP HA MADURADO CON EL TIEMPO: EL USO • UML HACE QUE EL SOFTWARE SE APEGUE A ESTÁNDARES DE LA INDUSTRIA • ADAPTABLE A LA ORGANIZACIÓN • HERRAMIENTAS DE BUENA IMPLEMENTACIÓN • DEFINE ACTIVIDADES, ROLES Y RESPONSABILIDADES • DESDE JEFE DE PROYECTO HASTA LOS ANALISTAS Y • DESDE DESARROLLADORES Y EQUIPOS DE PRUEBA
  • 29. DESVENTAJAS  POR EL GRADO DE COMPLEJIDAD PUEDE NO RESULTAR MUY ADECUADO.  RUP ES GENERALMENTE MAL APLICADO EN EL ESTILO CASCADA.  SISTEMAS HÍBRIDOS: EN EMPRESAS QUE HAY ORGANISMOS HÍBRIDOS Y NO SON ADÁPTALES A CUALQUIER EMPRESA UML NO ES EFECTIVO.  CARACTERÍSTICAS AVANZADAS LA SINTAXIS DE MODELACIÓN REQUIERE DE NOTACIONES QUE NO POSEEN LOS DESARROLLADORES PROMEDIO.  COSTOSA COMPRAR LAS HERRAMIENTAS Y CAPACITAR AL EQUIPO REQUIERE DE TIEMPO Y CONSULTORÍA.  LIMITACIONES EN CICLO DE VIDA NO LO CONTEMPLA COMPLETO.