SlideShare ist ein Scribd-Unternehmen logo
1 von 35
¿Qué es RUP?
Es un proceso de ingeniería de software, que hace
una propuesta orientada por disciplinas para
lograr las tareas y responsabilidades de una
organización que desarrolla software.
Su meta principal es asegurar la producción deasegurar la producción de
software de alta calidadsoftware de alta calidad que cumpla con las
necesidades de los usuarios, con una planeación y
presupuesto predecible.
¿Para quién es RUP?
 Diseñado para
 Profesionales en el desarrollo de software
 Interesados en productos de software
 Profesionales en la ingeniería y
administración de procesos de software
 Estos participantes se involucran con
RUP cumpliendo roles
¿Por qué usar RUP?
 Porque:
 Provee un entorno de proceso de desarrollo
configurable, basado en estándares
 Permite tener claro y accesible el proceso de
desarrollo que se sigue
 Permite ser configurado a las necesidades de la
organización y del proyecto
 Provee a cada participante con la parte del
proceso que le compete directamente, filtrando
el resto
Características
 Dirigido por Casos de Uso
 Los casos de uso son los artefactos primarios para
establecer el comportamiento deseado del sistema
 Centrado en la Arquitectura
 La arquitectura es utilizada para conceptualizar,
construir, administrar y evolucionar el sistema en
desarrollo
 Iterativo e Incremental
 Maneja una serie de entregas ejecutables
 Integra continuamente la arquitectura para producir
nuevas versiones mejoradas
Características (2)
 Conceptualmente amplio y diverso
 Enfoque orientado a objetos
 En evolución continua
 Adaptable
 Repetible
 Permite mediciones
 Estimación de costos y tiempo, nivel de avance,
etc.
Conceptos
Ciclo de vida
Diagrama General de RUPDiagrama General de RUP
En la representación gráfica del
Modelo…
Eje horizontal: representa el tiempo y muestra los
aspectos del ciclo de vida del proceso. Es el
aspecto dinámicoaspecto dinámico del proceso a través de las
fases, iteraciones y productos intermedios.
Eje vertical: representa las disciplinas que agrupan
actividades por su naturaleza. Aspecto estáticoAspecto estático
del proceso a través de componentes, disciplinas,
actividades, flujos de trabajo, artefactos y roles.
Ciclo de Vida de RUP
En cuanto a tiempo el ciclo de vida de RUP se
descompone en 4 FASES secuenciales, cada cual
concluye con un producto intermedio.
Al terminar cada fase se realiza una evaluación
para determinar si se ha cumplido o no con los
objetivos de la misma.
Las fases son: Inicio (Inception), Elaboración,
Construcción y Transición.
Fases de Ciclo de VidaFases de Ciclo de Vida
Inicio Elaboración Construcción Transición
Esfuerzo 5% 20% 65% 10%
Tiempo 10% 30% 50% 10%
Inicio (Inception)Inicio (Inception)
El objetivo general de esta fase es establecer unestablecer un
acuerdo entre todos los interesados acerca de losacuerdo entre todos los interesados acerca de los
objetivos del proyectoobjetivos del proyecto.
Es significativamente importante para el desarrollo de
nuevo software, ya que se asegura de identificar losse asegura de identificar los
riesgos relacionados con el negocio yriesgos relacionados con el negocio y
requerimientosrequerimientos.
Para proyectos de mejora de software existente, esta
fase es más breve y se centra en asegurar la viabilidad
de desarrollar el proyecto.
ElaboraciónElaboración
El objetivo en esta fase es establecer laestablecer la
arquitectura base del sistemaarquitectura base del sistema para
proveer bases estables para el esfuerzo de
diseño e implementación en la siguiente
fase.
La arquitectura debe abarcar todas las
consideraciones de mayor importancia de
los requerimientos y una evaluación del
riesgo.
ConstrucciónConstrucción
El objetivo de la fase de construcción es clarificar losclarificar los
requerimientos faltantes y completar el desarrollo delrequerimientos faltantes y completar el desarrollo del
sistemasistema basados en la arquitectura base.
Vista de cierta forma esta fase es un proceso de
manufactura, en el cual el énfasis se torna hacia la
administración de recursos y control de la operaciones
para optimizar costos, tiempo y calidad.
TransiciónTransición
Esta fase se enfoca en asegurar que el software estéasegurar que el software esté
disponible para sus usuariosdisponible para sus usuarios.
Se puede subdividir en varias iteraciones, además incluye
pruebas del producto para poder hacer el entregable del
mismo, así como realizar ajuste menores de acuerdo a
ajuste menores propuestos por el usuario.
En este punto, la retroalimentación de los usuarios se
centra en depurar el producto, configuraciones, instalación
y aspectos sobre utilización.
DisciplinasDisciplinas
Una disciplina es una colección dees una colección de
actividades relacionadas con un áreaactividades relacionadas con un área
de atención dentro de todo elde atención dentro de todo el
proyecto.proyecto.
El grupo de actividades que se
encuentran dentro de una disciplina
principalmente son una ayuda para
entender el proyecto desde la perspectiva
clásica de cascada.
Disciplinas
 Son un conjunto de actividades
relacionadas con un área especifica dentro
del proyecto.
 Están inspiradas en las etapas de un proceso
de desarrollo en cascada
 Es una secuencia parcialmente ordenada de
actividades que son realizadas para lograr
un resultado particular, representado en un
conjunto de artefactos.
DISCIPLINAS
Las disciplinas son:
Modelado de Negocios, Requerimientos,
Análisis y Diseño, Implementación,
Pruebas, Transición, Configuración y
Administración del Cambio,
Administración de Proyectos y Ambiente.
Modelado de NegociosModelado de Negocios
Los propósitos que tiene el Modelo de Negocios son:
Entender los problemas que la organización desea
solucionar e identificar mejoras potenciales.
Medir el impacto del cambio organizacional.
Asegurar que clientes, usuarios finales, desarrolladores y
los otros participantes tengan un entendimiento
compartido del problema.
Derivar los requerimientos del sistema de software,
necesarios para dar soporte a los objetivos de la
organización.
Entender como el sistema a ser desarrollado entra dentro
de la organización.
RequerimientosRequerimientos
Esta disciplina tiene el propósito de:
Establecer y mantener un acuerdo con los clientes y los
otros interesados acerca de que debe hacer el sistema.
Proveer a los desarrolladores del sistema de un mejor
entendimiento de los requerimientos del sistema.
Definir los límites (o delimitar) del sistema.
Proveer un base para la planeación de los contenidos
técnicos de las iteraciones.
Proveer una base para la estimación de costo y tiempo
necesarios para desarrollar el sistema.
Definir una interfaz de usuario para el sistema, enfocada
en las necesidades y objetivos del usuario.
Análisis y DiseñoAnálisis y Diseño
El propósito del Análisis y Diseño es:
Transformar los requerimientos a diseños del
sistema.
Desarrollar una arquitectura robusta para el
sistema.
Adaptar el diseño para hacerlo corresponder con
el ambiente de implementación y ajustarla para un
desempeño esperado.
ImplementaciónImplementación
El propósito de la implementación es:
Definir la organización del código, en términos de la
implementación de los subsistemas organizados en capas.
Implementar el diseño de elementos en términos de los
elementos (archivos fuente, binarios, ejecutables y otros)
Probar los componentes desarrollados como unidades.
Integrar los resultados individuales en un sistema
ejecutable.
La disciplina de implementación limita su alcance a como las
clases individuales serán probadas. Las pruebas del sistema
son descritas en futuras disciplinas.
PruebasPruebas
Actúa como un proveedor de servicios a las otras disciplinas
en muchos aspectos. Se enfoca principalmente en la
evaluación y aseguramiento de la calidad del producto,
desarrollado a través de las siguientes prácticas:
Encontrar fallas de calidad en el software y documentarlas.
Recomendar sobre la calidad percibida en el software.
Validar y probar las suposiciones hechas durante el diseño
y la especificación de requerimientos de forma concreta.
Validar que el software trabaja como fue diseñado.
Validar que los requerimientos son implementados
apropiadamente.
TransiciónTransición
Esta disciplina describe las actividades asociadas
con el aseguramiento de la entrega y
disponibilidad del producto de software hacia el
usuario final.
Existe un énfasis en probar el software en el sitio
de desarrollo, realización de pruebas beta del
sistema antes de su entrega final al cliente.
Administración y Configuración del CambioAdministración y Configuración del Cambio
Consiste en controlar los cambios y mantener la
integridad de los productos que incluye el proyecto.
Incluye:
Identificar los elementos configurables.
Restringir los cambios en los elementos configurables.
Auditar los cambios hechos a estos elementos.
Definir y mantener las configuraciones de estos elementos.
Los métodos, procesos y herramientas usadas para proveer
la administración y configuración del cambio pueden ser
consideradas como el sistema de administración de la
configuración.
Administración de ProyectosAdministración de Proyectos
El propósito de la Administración de Proyectos es:
Proveer un marco de trabajo para administrar los
proyectos intensivos de software.
Proveer guías prácticas para la planeación,
soporte, ejecución y monitoreo de proyectos.
Proveer un marco de trabajo para la
administración del riesgo.
AmbienteAmbiente
Se enfoca en las actividades necesarias para
configurar el proceso al proyecto.
Describe las actividades requeridas para
desarrollar las líneas guías de apoyo al proyecto.
El propósito de las actividades de ambiente es
proveer a las organizaciones de desarrollo de
software del ambiente necesario (herramientas y
procesos) que den soporte al equipo de desarrollo.
Disciplinas
 Workflow
 Detalles del
workflow
 Actividades
 Artefactos
 Guías de
aplicación
Roles
 Definen el comportamiento y
responsabilidades de individuos o grupos de
individuos
 Un individuo puede jugar más de un rol
 Son descripciones abstractas de
 Conjuntos de actividades realizadas
 Responsabilidad sobre artefactos
 Ejemplos de roles
 Software Architect
 Architecture Reviewer
Actividades
Una actividad es algo que un rol hace y que provee
un resultado de interés en el contexto del proyecto.
Es una unidad de trabajo que individuos jugando
cierto rol pueden ser llamados a realizar.
Son utilizadas para detallar los workflows.
Toman artefactos como entrada y producen
artefactos (o nuevas versiones) como salida.
Artefactos
Unidades de
información
creadas,
producidas,
cambiadas o
utilizadas en el
proceso de
desarrollo.
¿Cuándo usar RUP?
Alta complejidad técnica
- embebidos, tiempo real, distribuidos, tolerancia a fallas
- alta performance
- personalizado, sin precedentes, re-ingeniería arquitectónica
Baja complejidad técnica
- 4GL, basado en componentes
- re-ingeniería de aplicaciones
Alta complejidad gerencial
- gran escala
- contractual
- muchos stakeholders
Baja complejidad gerencial
- pequeña escala
- informal
- pocos stakeholders
Mayor necesidad de seguir
un proceso definido
¿Cuándo usar RUP? (2)
 RUP puede utilizarse
 En proyectos de nuevos productos de software
 En ciclos de desarrollo subsecuentes
 Consideraciones que alteran cuándo y cómo
usar partes de RUP
 El ciclo de vida del proyecto
 Los objetivos del negocio, la visión, el alcance y
los riesgos
 El tamaño del esfuerzo de desarrollo
Conclusiones
 Es un modelo de proceso de desarrollo de
software
 Es una base para procesos particulares
 El objetivo es asegurar el desarrollo
 De productos de software de alta calidad
 Que satisfagan los requerimientos
 En tiempo y presupuesto predecible
 Permite un vocabulario común entre equipos
de desarrollo

Weitere ähnliche Inhalte

Was ist angesagt?

Modelos y capas de la ingenieria de software
Modelos y capas  de la ingenieria de softwareModelos y capas  de la ingenieria de software
Modelos y capas de la ingenieria de softwarejhonatanalex
 
modelos del proceso del software
 modelos del proceso del software  modelos del proceso del software
modelos del proceso del software Brihany Rossell
 
Diferencias entre scrum y xp
Diferencias entre scrum y xp Diferencias entre scrum y xp
Diferencias entre scrum y xp deborahgal
 
Modelo de desarrollo de software
Modelo de desarrollo de softwareModelo de desarrollo de software
Modelo de desarrollo de softwareYaskelly Yedra
 
Requerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicaciónRequerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicaciónYare LoZada
 
Metodologías de Desarrollo de Software Tradicionales y Emergentes
Metodologías de Desarrollo de Software Tradicionales y EmergentesMetodologías de Desarrollo de Software Tradicionales y Emergentes
Metodologías de Desarrollo de Software Tradicionales y EmergentesMiguel Rodríguez
 
Requerimiento funcional y no funcional
Requerimiento funcional y no funcional Requerimiento funcional y no funcional
Requerimiento funcional y no funcional CristobalFicaV
 
Modelo del dominio
Modelo del dominioModelo del dominio
Modelo del dominioSCMU AQP
 
Modelo de desarrollo concurrente
Modelo de desarrollo concurrenteModelo de desarrollo concurrente
Modelo de desarrollo concurrentesamuel ospino
 
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negociosFundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negociosJosé Antonio Sandoval Acosta
 
Extreme Programming-Fases
Extreme Programming-FasesExtreme Programming-Fases
Extreme Programming-FasesBelghy Chisag
 
Tecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareTecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareJennifer Andrea Cano Guevara
 

Was ist angesagt? (20)

Modelos y capas de la ingenieria de software
Modelos y capas  de la ingenieria de softwareModelos y capas  de la ingenieria de software
Modelos y capas de la ingenieria de software
 
Modelo evolutivo
Modelo evolutivoModelo evolutivo
Modelo evolutivo
 
modelos del proceso del software
 modelos del proceso del software  modelos del proceso del software
modelos del proceso del software
 
Requerimientos del software
Requerimientos del software Requerimientos del software
Requerimientos del software
 
Diferencias entre scrum y xp
Diferencias entre scrum y xp Diferencias entre scrum y xp
Diferencias entre scrum y xp
 
Modelo de desarrollo de software
Modelo de desarrollo de softwareModelo de desarrollo de software
Modelo de desarrollo de software
 
Requerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicaciónRequerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicación
 
Estimación Software por Puntos de Función
Estimación Software por Puntos de FunciónEstimación Software por Puntos de Función
Estimación Software por Puntos de Función
 
Metodologías de Desarrollo de Software Tradicionales y Emergentes
Metodologías de Desarrollo de Software Tradicionales y EmergentesMetodologías de Desarrollo de Software Tradicionales y Emergentes
Metodologías de Desarrollo de Software Tradicionales y Emergentes
 
Requerimiento funcional y no funcional
Requerimiento funcional y no funcional Requerimiento funcional y no funcional
Requerimiento funcional y no funcional
 
Modelo del dominio
Modelo del dominioModelo del dominio
Modelo del dominio
 
Modelo de desarrollo concurrente
Modelo de desarrollo concurrenteModelo de desarrollo concurrente
Modelo de desarrollo concurrente
 
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negociosFundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
 
Metodología Rup
Metodología RupMetodología Rup
Metodología Rup
 
Extreme Programming-Fases
Extreme Programming-FasesExtreme Programming-Fases
Extreme Programming-Fases
 
Modelamiento software
Modelamiento softwareModelamiento software
Modelamiento software
 
Modelo evolutivo
Modelo evolutivoModelo evolutivo
Modelo evolutivo
 
Metodología RUP
Metodología RUPMetodología RUP
Metodología RUP
 
Tecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareTecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto software
 
Metodologia rup
Metodologia rupMetodologia rup
Metodologia rup
 

Andere mochten auch (20)

Rup fase 3-version
Rup fase 3-version Rup fase 3-version
Rup fase 3-version
 
Plan de desarrollo software
Plan de desarrollo softwarePlan de desarrollo software
Plan de desarrollo software
 
Sistema Facturación y Pensiones
Sistema  Facturación y PensionesSistema  Facturación y Pensiones
Sistema Facturación y Pensiones
 
Implementan en metodología RUP
Implementan en metodología RUPImplementan en metodología RUP
Implementan en metodología RUP
 
metodologia rup
metodologia rupmetodologia rup
metodologia rup
 
Principios del RUP
Principios del RUPPrincipios del RUP
Principios del RUP
 
Rup
RupRup
Rup
 
Modelo osi unidad3
Modelo osi unidad3Modelo osi unidad3
Modelo osi unidad3
 
METODOLOGIA RUP
METODOLOGIA RUPMETODOLOGIA RUP
METODOLOGIA RUP
 
Metodologia del rup
Metodologia del rupMetodologia del rup
Metodologia del rup
 
Metodologia rup
Metodologia rupMetodologia rup
Metodologia rup
 
Rup
RupRup
Rup
 
Metodologia msf
Metodologia msfMetodologia msf
Metodologia msf
 
Rup entrega final
Rup entrega finalRup entrega final
Rup entrega final
 
Fases del Proceso Unificado
Fases del Proceso UnificadoFases del Proceso Unificado
Fases del Proceso Unificado
 
Rup (iteraciones)
Rup (iteraciones)Rup (iteraciones)
Rup (iteraciones)
 
CMMI V1.3
CMMI V1.3CMMI V1.3
CMMI V1.3
 
Diagrama de clases
Diagrama de clasesDiagrama de clases
Diagrama de clases
 
Principios de diseño de la arquitectura del software
Principios de diseño de la arquitectura del softwarePrincipios de diseño de la arquitectura del software
Principios de diseño de la arquitectura del software
 
Metodologías SCRUM + PMBOK
Metodologías SCRUM + PMBOKMetodologías SCRUM + PMBOK
Metodologías SCRUM + PMBOK
 

Ähnlich wie Rup disciplinas (20)

RUP
RUPRUP
RUP
 
metodologia
metodologiametodologia
metodologia
 
Qué+es+ru..
Qué+es+ru..Qué+es+ru..
Qué+es+ru..
 
Rup jenny mallqui
Rup   jenny mallquiRup   jenny mallqui
Rup jenny mallqui
 
Qué es rup
Qué es rupQué es rup
Qué es rup
 
Rup
RupRup
Rup
 
rup
ruprup
rup
 
Quesrup 120217232753-phpapp02
Quesrup 120217232753-phpapp02Quesrup 120217232753-phpapp02
Quesrup 120217232753-phpapp02
 
Clase_iso12207.pptx
Clase_iso12207.pptxClase_iso12207.pptx
Clase_iso12207.pptx
 
Rup
RupRup
Rup
 
Rup
RupRup
Rup
 
Sww clase4
Sww clase4Sww clase4
Sww clase4
 
Sww clase4
Sww clase4Sww clase4
Sww clase4
 
Sww clase4
Sww clase4Sww clase4
Sww clase4
 
Metodologias rup
Metodologias rupMetodologias rup
Metodologias rup
 
Metodologia rup
Metodologia rupMetodologia rup
Metodologia rup
 
Rup entrega final
Rup entrega finalRup entrega final
Rup entrega final
 
Wagneher franck mallma nuñez
Wagneher franck mallma nuñezWagneher franck mallma nuñez
Wagneher franck mallma nuñez
 
Wagneher franck mallma nuñez
Wagneher franck mallma nuñezWagneher franck mallma nuñez
Wagneher franck mallma nuñez
 
Lineas de producto de software y el Metodo watch
Lineas de producto de software y el Metodo watchLineas de producto de software y el Metodo watch
Lineas de producto de software y el Metodo watch
 

Mehr von NELSON RODRIGUEZ

Mehr von NELSON RODRIGUEZ (13)

SISTEMAS DE INFORMACION.ppt
SISTEMAS DE INFORMACION.pptSISTEMAS DE INFORMACION.ppt
SISTEMAS DE INFORMACION.ppt
 
Definicion de conceptos.ppt
Definicion de conceptos.pptDefinicion de conceptos.ppt
Definicion de conceptos.ppt
 
DESARROLLO DE APLICACIONES MOVILES.pptx
DESARROLLO DE APLICACIONES MOVILES.pptxDESARROLLO DE APLICACIONES MOVILES.pptx
DESARROLLO DE APLICACIONES MOVILES.pptx
 
Netiqueta
NetiquetaNetiqueta
Netiqueta
 
Herramientas digitales
Herramientas digitalesHerramientas digitales
Herramientas digitales
 
Ondrive
OndriveOndrive
Ondrive
 
Mapas conceptuales
Mapas conceptualesMapas conceptuales
Mapas conceptuales
 
3eso3.2boletinfunciones
3eso3.2boletinfunciones3eso3.2boletinfunciones
3eso3.2boletinfunciones
 
1. el proceso unificado
1. el proceso unificado1. el proceso unificado
1. el proceso unificado
 
Plandecapacitaciondocente
PlandecapacitaciondocentePlandecapacitaciondocente
Plandecapacitaciondocente
 
2 topologias-y-equipos-de-red
2 topologias-y-equipos-de-red2 topologias-y-equipos-de-red
2 topologias-y-equipos-de-red
 
Algebrabooleana
AlgebrabooleanaAlgebrabooleana
Algebrabooleana
 
Sisinformaciom
SisinformaciomSisinformaciom
Sisinformaciom
 

Kürzlich hochgeladen

historieta materia de ecologías producto
historieta materia de ecologías productohistorieta materia de ecologías producto
historieta materia de ecologías productommartinezmarquez30
 
TEMA 13. LOS GOBIERNOS DEMOCRÁTICOS (1982-2018)
TEMA 13. LOS GOBIERNOS DEMOCRÁTICOS (1982-2018)TEMA 13. LOS GOBIERNOS DEMOCRÁTICOS (1982-2018)
TEMA 13. LOS GOBIERNOS DEMOCRÁTICOS (1982-2018)jlorentemartos
 
El PROGRAMA DE TUTORÍAS PARA EL APRENDIZAJE Y LA FORMACIÓN INTEGRAL PTA/F
El PROGRAMA DE TUTORÍAS PARA EL APRENDIZAJE Y LA FORMACIÓN INTEGRAL PTA/FEl PROGRAMA DE TUTORÍAS PARA EL APRENDIZAJE Y LA FORMACIÓN INTEGRAL PTA/F
El PROGRAMA DE TUTORÍAS PARA EL APRENDIZAJE Y LA FORMACIÓN INTEGRAL PTA/FJulio Lozano
 
Acuerdo 05_04_24 Lineamientos del CTE.pdf
Acuerdo 05_04_24 Lineamientos del CTE.pdfAcuerdo 05_04_24 Lineamientos del CTE.pdf
Acuerdo 05_04_24 Lineamientos del CTE.pdfmiriamguevara21
 
Desarrollo de habilidades del siglo XXI - Práctica Educativa en una Unidad-Ca...
Desarrollo de habilidades del siglo XXI - Práctica Educativa en una Unidad-Ca...Desarrollo de habilidades del siglo XXI - Práctica Educativa en una Unidad-Ca...
Desarrollo de habilidades del siglo XXI - Práctica Educativa en una Unidad-Ca...Carol Andrea Eraso Guerrero
 
IV SES LUN 15 TUTO CUIDO MI MENTE CUIDANDO MI CUERPO YESSENIA 933623393 NUEV...
IV SES LUN 15 TUTO CUIDO MI MENTE CUIDANDO MI CUERPO  YESSENIA 933623393 NUEV...IV SES LUN 15 TUTO CUIDO MI MENTE CUIDANDO MI CUERPO  YESSENIA 933623393 NUEV...
IV SES LUN 15 TUTO CUIDO MI MENTE CUIDANDO MI CUERPO YESSENIA 933623393 NUEV...YobanaZevallosSantil1
 
PRIMER GRADO SOY LECTOR PART1- MD EDUCATIVO.pdf
PRIMER GRADO SOY LECTOR PART1- MD  EDUCATIVO.pdfPRIMER GRADO SOY LECTOR PART1- MD  EDUCATIVO.pdf
PRIMER GRADO SOY LECTOR PART1- MD EDUCATIVO.pdfGabrieldeJesusLopezG
 
Presentación Bloque 3 Actividad 2 transversal.pptx
Presentación Bloque 3 Actividad 2 transversal.pptxPresentación Bloque 3 Actividad 2 transversal.pptx
Presentación Bloque 3 Actividad 2 transversal.pptxRosabel UA
 
Si cuidamos el mundo, tendremos un mundo mejor.
Si cuidamos el mundo, tendremos un mundo mejor.Si cuidamos el mundo, tendremos un mundo mejor.
Si cuidamos el mundo, tendremos un mundo mejor.monthuerta17
 
Secuencia didáctica.DOÑA CLEMENTINA.2024.docx
Secuencia didáctica.DOÑA CLEMENTINA.2024.docxSecuencia didáctica.DOÑA CLEMENTINA.2024.docx
Secuencia didáctica.DOÑA CLEMENTINA.2024.docxNataliaGonzalez619348
 
libro grafismo fonético guía de uso para el lenguaje
libro grafismo fonético guía de uso para el lenguajelibro grafismo fonético guía de uso para el lenguaje
libro grafismo fonético guía de uso para el lenguajeKattyMoran3
 
SISTEMA INMUNE FISIOLOGIA MEDICA UNSL 2024
SISTEMA INMUNE FISIOLOGIA MEDICA UNSL 2024SISTEMA INMUNE FISIOLOGIA MEDICA UNSL 2024
SISTEMA INMUNE FISIOLOGIA MEDICA UNSL 2024gharce
 
ENSEÑAR ACUIDAR EL MEDIO AMBIENTE ES ENSEÑAR A VALORAR LA VIDA.
ENSEÑAR ACUIDAR  EL MEDIO AMBIENTE ES ENSEÑAR A VALORAR LA VIDA.ENSEÑAR ACUIDAR  EL MEDIO AMBIENTE ES ENSEÑAR A VALORAR LA VIDA.
ENSEÑAR ACUIDAR EL MEDIO AMBIENTE ES ENSEÑAR A VALORAR LA VIDA.karlazoegarciagarcia
 
MEDIACIÓN INTERNACIONAL MF 1445 vl45.pdf
MEDIACIÓN INTERNACIONAL MF 1445 vl45.pdfMEDIACIÓN INTERNACIONAL MF 1445 vl45.pdf
MEDIACIÓN INTERNACIONAL MF 1445 vl45.pdfJosé Hecht
 
LOS AMBIENTALISTAS todo por un mundo mejor
LOS AMBIENTALISTAS todo por un mundo mejorLOS AMBIENTALISTAS todo por un mundo mejor
LOS AMBIENTALISTAS todo por un mundo mejormrcrmnrojasgarcia
 
Contextualización y aproximación al objeto de estudio de investigación cualit...
Contextualización y aproximación al objeto de estudio de investigación cualit...Contextualización y aproximación al objeto de estudio de investigación cualit...
Contextualización y aproximación al objeto de estudio de investigación cualit...Angélica Soledad Vega Ramírez
 
Actividad transversal 2-bloque 2. Actualización 2024
Actividad transversal 2-bloque 2. Actualización 2024Actividad transversal 2-bloque 2. Actualización 2024
Actividad transversal 2-bloque 2. Actualización 2024Rosabel UA
 
BITÁCORA DE ESTUDIO DE PROBLEMÁTICA. TUTORÍA V. PDF 2 UNIDAD.pdf
BITÁCORA DE ESTUDIO DE PROBLEMÁTICA. TUTORÍA V. PDF 2 UNIDAD.pdfBITÁCORA DE ESTUDIO DE PROBLEMÁTICA. TUTORÍA V. PDF 2 UNIDAD.pdf
BITÁCORA DE ESTUDIO DE PROBLEMÁTICA. TUTORÍA V. PDF 2 UNIDAD.pdfsolidalilaalvaradoro
 

Kürzlich hochgeladen (20)

historieta materia de ecologías producto
historieta materia de ecologías productohistorieta materia de ecologías producto
historieta materia de ecologías producto
 
TEMA 13. LOS GOBIERNOS DEMOCRÁTICOS (1982-2018)
TEMA 13. LOS GOBIERNOS DEMOCRÁTICOS (1982-2018)TEMA 13. LOS GOBIERNOS DEMOCRÁTICOS (1982-2018)
TEMA 13. LOS GOBIERNOS DEMOCRÁTICOS (1982-2018)
 
El PROGRAMA DE TUTORÍAS PARA EL APRENDIZAJE Y LA FORMACIÓN INTEGRAL PTA/F
El PROGRAMA DE TUTORÍAS PARA EL APRENDIZAJE Y LA FORMACIÓN INTEGRAL PTA/FEl PROGRAMA DE TUTORÍAS PARA EL APRENDIZAJE Y LA FORMACIÓN INTEGRAL PTA/F
El PROGRAMA DE TUTORÍAS PARA EL APRENDIZAJE Y LA FORMACIÓN INTEGRAL PTA/F
 
Acuerdo 05_04_24 Lineamientos del CTE.pdf
Acuerdo 05_04_24 Lineamientos del CTE.pdfAcuerdo 05_04_24 Lineamientos del CTE.pdf
Acuerdo 05_04_24 Lineamientos del CTE.pdf
 
Desarrollo de habilidades del siglo XXI - Práctica Educativa en una Unidad-Ca...
Desarrollo de habilidades del siglo XXI - Práctica Educativa en una Unidad-Ca...Desarrollo de habilidades del siglo XXI - Práctica Educativa en una Unidad-Ca...
Desarrollo de habilidades del siglo XXI - Práctica Educativa en una Unidad-Ca...
 
IV SES LUN 15 TUTO CUIDO MI MENTE CUIDANDO MI CUERPO YESSENIA 933623393 NUEV...
IV SES LUN 15 TUTO CUIDO MI MENTE CUIDANDO MI CUERPO  YESSENIA 933623393 NUEV...IV SES LUN 15 TUTO CUIDO MI MENTE CUIDANDO MI CUERPO  YESSENIA 933623393 NUEV...
IV SES LUN 15 TUTO CUIDO MI MENTE CUIDANDO MI CUERPO YESSENIA 933623393 NUEV...
 
PRIMER GRADO SOY LECTOR PART1- MD EDUCATIVO.pdf
PRIMER GRADO SOY LECTOR PART1- MD  EDUCATIVO.pdfPRIMER GRADO SOY LECTOR PART1- MD  EDUCATIVO.pdf
PRIMER GRADO SOY LECTOR PART1- MD EDUCATIVO.pdf
 
Presentación Bloque 3 Actividad 2 transversal.pptx
Presentación Bloque 3 Actividad 2 transversal.pptxPresentación Bloque 3 Actividad 2 transversal.pptx
Presentación Bloque 3 Actividad 2 transversal.pptx
 
Si cuidamos el mundo, tendremos un mundo mejor.
Si cuidamos el mundo, tendremos un mundo mejor.Si cuidamos el mundo, tendremos un mundo mejor.
Si cuidamos el mundo, tendremos un mundo mejor.
 
Secuencia didáctica.DOÑA CLEMENTINA.2024.docx
Secuencia didáctica.DOÑA CLEMENTINA.2024.docxSecuencia didáctica.DOÑA CLEMENTINA.2024.docx
Secuencia didáctica.DOÑA CLEMENTINA.2024.docx
 
Aedes aegypti + Intro to Coquies EE.pptx
Aedes aegypti + Intro to Coquies EE.pptxAedes aegypti + Intro to Coquies EE.pptx
Aedes aegypti + Intro to Coquies EE.pptx
 
libro grafismo fonético guía de uso para el lenguaje
libro grafismo fonético guía de uso para el lenguajelibro grafismo fonético guía de uso para el lenguaje
libro grafismo fonético guía de uso para el lenguaje
 
SISTEMA INMUNE FISIOLOGIA MEDICA UNSL 2024
SISTEMA INMUNE FISIOLOGIA MEDICA UNSL 2024SISTEMA INMUNE FISIOLOGIA MEDICA UNSL 2024
SISTEMA INMUNE FISIOLOGIA MEDICA UNSL 2024
 
El Bullying.
El Bullying.El Bullying.
El Bullying.
 
ENSEÑAR ACUIDAR EL MEDIO AMBIENTE ES ENSEÑAR A VALORAR LA VIDA.
ENSEÑAR ACUIDAR  EL MEDIO AMBIENTE ES ENSEÑAR A VALORAR LA VIDA.ENSEÑAR ACUIDAR  EL MEDIO AMBIENTE ES ENSEÑAR A VALORAR LA VIDA.
ENSEÑAR ACUIDAR EL MEDIO AMBIENTE ES ENSEÑAR A VALORAR LA VIDA.
 
MEDIACIÓN INTERNACIONAL MF 1445 vl45.pdf
MEDIACIÓN INTERNACIONAL MF 1445 vl45.pdfMEDIACIÓN INTERNACIONAL MF 1445 vl45.pdf
MEDIACIÓN INTERNACIONAL MF 1445 vl45.pdf
 
LOS AMBIENTALISTAS todo por un mundo mejor
LOS AMBIENTALISTAS todo por un mundo mejorLOS AMBIENTALISTAS todo por un mundo mejor
LOS AMBIENTALISTAS todo por un mundo mejor
 
Contextualización y aproximación al objeto de estudio de investigación cualit...
Contextualización y aproximación al objeto de estudio de investigación cualit...Contextualización y aproximación al objeto de estudio de investigación cualit...
Contextualización y aproximación al objeto de estudio de investigación cualit...
 
Actividad transversal 2-bloque 2. Actualización 2024
Actividad transversal 2-bloque 2. Actualización 2024Actividad transversal 2-bloque 2. Actualización 2024
Actividad transversal 2-bloque 2. Actualización 2024
 
BITÁCORA DE ESTUDIO DE PROBLEMÁTICA. TUTORÍA V. PDF 2 UNIDAD.pdf
BITÁCORA DE ESTUDIO DE PROBLEMÁTICA. TUTORÍA V. PDF 2 UNIDAD.pdfBITÁCORA DE ESTUDIO DE PROBLEMÁTICA. TUTORÍA V. PDF 2 UNIDAD.pdf
BITÁCORA DE ESTUDIO DE PROBLEMÁTICA. TUTORÍA V. PDF 2 UNIDAD.pdf
 

Rup disciplinas

  • 1.
  • 2. ¿Qué es RUP? Es un proceso de ingeniería de software, que hace una propuesta orientada por disciplinas para lograr las tareas y responsabilidades de una organización que desarrolla software. Su meta principal es asegurar la producción deasegurar la producción de software de alta calidadsoftware de alta calidad que cumpla con las necesidades de los usuarios, con una planeación y presupuesto predecible.
  • 3. ¿Para quién es RUP?  Diseñado para  Profesionales en el desarrollo de software  Interesados en productos de software  Profesionales en la ingeniería y administración de procesos de software  Estos participantes se involucran con RUP cumpliendo roles
  • 4. ¿Por qué usar RUP?  Porque:  Provee un entorno de proceso de desarrollo configurable, basado en estándares  Permite tener claro y accesible el proceso de desarrollo que se sigue  Permite ser configurado a las necesidades de la organización y del proyecto  Provee a cada participante con la parte del proceso que le compete directamente, filtrando el resto
  • 5. Características  Dirigido por Casos de Uso  Los casos de uso son los artefactos primarios para establecer el comportamiento deseado del sistema  Centrado en la Arquitectura  La arquitectura es utilizada para conceptualizar, construir, administrar y evolucionar el sistema en desarrollo  Iterativo e Incremental  Maneja una serie de entregas ejecutables  Integra continuamente la arquitectura para producir nuevas versiones mejoradas
  • 6. Características (2)  Conceptualmente amplio y diverso  Enfoque orientado a objetos  En evolución continua  Adaptable  Repetible  Permite mediciones  Estimación de costos y tiempo, nivel de avance, etc.
  • 9. Diagrama General de RUPDiagrama General de RUP
  • 10. En la representación gráfica del Modelo… Eje horizontal: representa el tiempo y muestra los aspectos del ciclo de vida del proceso. Es el aspecto dinámicoaspecto dinámico del proceso a través de las fases, iteraciones y productos intermedios. Eje vertical: representa las disciplinas que agrupan actividades por su naturaleza. Aspecto estáticoAspecto estático del proceso a través de componentes, disciplinas, actividades, flujos de trabajo, artefactos y roles.
  • 11. Ciclo de Vida de RUP En cuanto a tiempo el ciclo de vida de RUP se descompone en 4 FASES secuenciales, cada cual concluye con un producto intermedio. Al terminar cada fase se realiza una evaluación para determinar si se ha cumplido o no con los objetivos de la misma. Las fases son: Inicio (Inception), Elaboración, Construcción y Transición.
  • 12. Fases de Ciclo de VidaFases de Ciclo de Vida Inicio Elaboración Construcción Transición Esfuerzo 5% 20% 65% 10% Tiempo 10% 30% 50% 10%
  • 13. Inicio (Inception)Inicio (Inception) El objetivo general de esta fase es establecer unestablecer un acuerdo entre todos los interesados acerca de losacuerdo entre todos los interesados acerca de los objetivos del proyectoobjetivos del proyecto. Es significativamente importante para el desarrollo de nuevo software, ya que se asegura de identificar losse asegura de identificar los riesgos relacionados con el negocio yriesgos relacionados con el negocio y requerimientosrequerimientos. Para proyectos de mejora de software existente, esta fase es más breve y se centra en asegurar la viabilidad de desarrollar el proyecto.
  • 14. ElaboraciónElaboración El objetivo en esta fase es establecer laestablecer la arquitectura base del sistemaarquitectura base del sistema para proveer bases estables para el esfuerzo de diseño e implementación en la siguiente fase. La arquitectura debe abarcar todas las consideraciones de mayor importancia de los requerimientos y una evaluación del riesgo.
  • 15. ConstrucciónConstrucción El objetivo de la fase de construcción es clarificar losclarificar los requerimientos faltantes y completar el desarrollo delrequerimientos faltantes y completar el desarrollo del sistemasistema basados en la arquitectura base. Vista de cierta forma esta fase es un proceso de manufactura, en el cual el énfasis se torna hacia la administración de recursos y control de la operaciones para optimizar costos, tiempo y calidad.
  • 16. TransiciónTransición Esta fase se enfoca en asegurar que el software estéasegurar que el software esté disponible para sus usuariosdisponible para sus usuarios. Se puede subdividir en varias iteraciones, además incluye pruebas del producto para poder hacer el entregable del mismo, así como realizar ajuste menores de acuerdo a ajuste menores propuestos por el usuario. En este punto, la retroalimentación de los usuarios se centra en depurar el producto, configuraciones, instalación y aspectos sobre utilización.
  • 17. DisciplinasDisciplinas Una disciplina es una colección dees una colección de actividades relacionadas con un áreaactividades relacionadas con un área de atención dentro de todo elde atención dentro de todo el proyecto.proyecto. El grupo de actividades que se encuentran dentro de una disciplina principalmente son una ayuda para entender el proyecto desde la perspectiva clásica de cascada.
  • 18. Disciplinas  Son un conjunto de actividades relacionadas con un área especifica dentro del proyecto.  Están inspiradas en las etapas de un proceso de desarrollo en cascada  Es una secuencia parcialmente ordenada de actividades que son realizadas para lograr un resultado particular, representado en un conjunto de artefactos.
  • 19. DISCIPLINAS Las disciplinas son: Modelado de Negocios, Requerimientos, Análisis y Diseño, Implementación, Pruebas, Transición, Configuración y Administración del Cambio, Administración de Proyectos y Ambiente.
  • 20. Modelado de NegociosModelado de Negocios Los propósitos que tiene el Modelo de Negocios son: Entender los problemas que la organización desea solucionar e identificar mejoras potenciales. Medir el impacto del cambio organizacional. Asegurar que clientes, usuarios finales, desarrolladores y los otros participantes tengan un entendimiento compartido del problema. Derivar los requerimientos del sistema de software, necesarios para dar soporte a los objetivos de la organización. Entender como el sistema a ser desarrollado entra dentro de la organización.
  • 21. RequerimientosRequerimientos Esta disciplina tiene el propósito de: Establecer y mantener un acuerdo con los clientes y los otros interesados acerca de que debe hacer el sistema. Proveer a los desarrolladores del sistema de un mejor entendimiento de los requerimientos del sistema. Definir los límites (o delimitar) del sistema. Proveer un base para la planeación de los contenidos técnicos de las iteraciones. Proveer una base para la estimación de costo y tiempo necesarios para desarrollar el sistema. Definir una interfaz de usuario para el sistema, enfocada en las necesidades y objetivos del usuario.
  • 22. Análisis y DiseñoAnálisis y Diseño El propósito del Análisis y Diseño es: Transformar los requerimientos a diseños del sistema. Desarrollar una arquitectura robusta para el sistema. Adaptar el diseño para hacerlo corresponder con el ambiente de implementación y ajustarla para un desempeño esperado.
  • 23. ImplementaciónImplementación El propósito de la implementación es: Definir la organización del código, en términos de la implementación de los subsistemas organizados en capas. Implementar el diseño de elementos en términos de los elementos (archivos fuente, binarios, ejecutables y otros) Probar los componentes desarrollados como unidades. Integrar los resultados individuales en un sistema ejecutable. La disciplina de implementación limita su alcance a como las clases individuales serán probadas. Las pruebas del sistema son descritas en futuras disciplinas.
  • 24. PruebasPruebas Actúa como un proveedor de servicios a las otras disciplinas en muchos aspectos. Se enfoca principalmente en la evaluación y aseguramiento de la calidad del producto, desarrollado a través de las siguientes prácticas: Encontrar fallas de calidad en el software y documentarlas. Recomendar sobre la calidad percibida en el software. Validar y probar las suposiciones hechas durante el diseño y la especificación de requerimientos de forma concreta. Validar que el software trabaja como fue diseñado. Validar que los requerimientos son implementados apropiadamente.
  • 25. TransiciónTransición Esta disciplina describe las actividades asociadas con el aseguramiento de la entrega y disponibilidad del producto de software hacia el usuario final. Existe un énfasis en probar el software en el sitio de desarrollo, realización de pruebas beta del sistema antes de su entrega final al cliente.
  • 26. Administración y Configuración del CambioAdministración y Configuración del Cambio Consiste en controlar los cambios y mantener la integridad de los productos que incluye el proyecto. Incluye: Identificar los elementos configurables. Restringir los cambios en los elementos configurables. Auditar los cambios hechos a estos elementos. Definir y mantener las configuraciones de estos elementos. Los métodos, procesos y herramientas usadas para proveer la administración y configuración del cambio pueden ser consideradas como el sistema de administración de la configuración.
  • 27. Administración de ProyectosAdministración de Proyectos El propósito de la Administración de Proyectos es: Proveer un marco de trabajo para administrar los proyectos intensivos de software. Proveer guías prácticas para la planeación, soporte, ejecución y monitoreo de proyectos. Proveer un marco de trabajo para la administración del riesgo.
  • 28. AmbienteAmbiente Se enfoca en las actividades necesarias para configurar el proceso al proyecto. Describe las actividades requeridas para desarrollar las líneas guías de apoyo al proyecto. El propósito de las actividades de ambiente es proveer a las organizaciones de desarrollo de software del ambiente necesario (herramientas y procesos) que den soporte al equipo de desarrollo.
  • 29. Disciplinas  Workflow  Detalles del workflow  Actividades  Artefactos  Guías de aplicación
  • 30. Roles  Definen el comportamiento y responsabilidades de individuos o grupos de individuos  Un individuo puede jugar más de un rol  Son descripciones abstractas de  Conjuntos de actividades realizadas  Responsabilidad sobre artefactos  Ejemplos de roles  Software Architect  Architecture Reviewer
  • 31. Actividades Una actividad es algo que un rol hace y que provee un resultado de interés en el contexto del proyecto. Es una unidad de trabajo que individuos jugando cierto rol pueden ser llamados a realizar. Son utilizadas para detallar los workflows. Toman artefactos como entrada y producen artefactos (o nuevas versiones) como salida.
  • 33. ¿Cuándo usar RUP? Alta complejidad técnica - embebidos, tiempo real, distribuidos, tolerancia a fallas - alta performance - personalizado, sin precedentes, re-ingeniería arquitectónica Baja complejidad técnica - 4GL, basado en componentes - re-ingeniería de aplicaciones Alta complejidad gerencial - gran escala - contractual - muchos stakeholders Baja complejidad gerencial - pequeña escala - informal - pocos stakeholders Mayor necesidad de seguir un proceso definido
  • 34. ¿Cuándo usar RUP? (2)  RUP puede utilizarse  En proyectos de nuevos productos de software  En ciclos de desarrollo subsecuentes  Consideraciones que alteran cuándo y cómo usar partes de RUP  El ciclo de vida del proyecto  Los objetivos del negocio, la visión, el alcance y los riesgos  El tamaño del esfuerzo de desarrollo
  • 35. Conclusiones  Es un modelo de proceso de desarrollo de software  Es una base para procesos particulares  El objetivo es asegurar el desarrollo  De productos de software de alta calidad  Que satisfagan los requerimientos  En tiempo y presupuesto predecible  Permite un vocabulario común entre equipos de desarrollo