El Proceso Unificado de Desarrollo de Software (RUP)¿Qué es RUP?        Requisitos del Usuario            Proceso de Desar...
Desarrollo iterativo del softwareAdministración de requerimientosUso de arquitecturas basadas en componentesMoldeamiento v...
ContextoCriterios de éxitoPronóstico financieroIdentificación inicial de riesgos.Plan de proyecto.Uno o más prototipos.Hit...
Un prototipo ejecutable de la arquitectura.Lista revisada de riesgos y del caso de negocio.Plan de desarrollo para el rest...
RUP: TransiciónEl objetivo es traspasar el software desarrollado a la comunidad de usuarios.Una vez instalado surgirán nue...
Una actividad es una unidad de trabajo que se asigna a un trabajador.Ejemplo:Crear o modificar un artefactoUna actividad l...
Un elemento del modelo, como una clase o un caso de uso.Un documento tal como el Caso del Negocio o la Arquitectura del So...
riesgos más importantes. Las iteraciones sucesivas construyen los artefactos deldesarrollo a partir del estado en el que f...
Próxima SlideShare
Cargando en…5
×

Rup (trabajo)

720 visualizaciones

Publicado el

0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
720
En SlideShare
0
De insertados
0
Número de insertados
3
Acciones
Compartido
0
Descargas
22
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Rup (trabajo)

  1. 1. El Proceso Unificado de Desarrollo de Software (RUP)¿Qué es RUP? Requisitos del Usuario Proceso de Desarrollo Sistema de Software de SoftwareGráfico: RUPRUP es un proceso de desarrollo de software:Forma disciplinada de asignar tareas y responsabilidades en una empresa dedesarrollo (quién hace qué, cuándo y cómo).Objetivos:Asegurar la producción de software de calidad dentro de plazos y presupuestospredecibles. Dirigido por casos de uso, centrado en la arquitectura, iterativo (mini-proyectos) e incremental (versiones).Es también un producto:Desarrollado y mantenido por Rational.Actualizado constantemente para tener en cuenta las mejores prácticas deacuerdo con la experiencia.Aumenta la productividad de los desarrolladores mediante acceso a:Base de conocimientoPlantillasHerramientasSe centra en la producción y mantenimiento de modelos del sistema más que enproducir documentos.RUP es una guía de cómo usar UML de la forma más efectiva.Las mejores prácticasRUP pretende implementar las mejores prácticas actuales en ingeniería desoftware:
  2. 2. Desarrollo iterativo del softwareAdministración de requerimientosUso de arquitecturas basadas en componentesMoldeamiento visual del softwareVerificación de la calidad del softwareControl de cambiosFases de RUPRUP divide el proceso de desarrollo en ciclos, teniendo un producto al final decada ciclo.Cada ciclo se divide en cuatro Fases:InicioElaboraciónConstrucciónTransiciónCada fase concluye con un hito bien definido donde deben tomarse ciertasdecisiones.RUP: Inicio (Inception)Se establece la oportunidad y alcance el proyecto.Se identifican todas las entidades externas con las que se trata (actores) y sedefine la interacción a un alto nivel de abstracción:Identificar todos los casos de usoDescribir algunos en detalleLa oportunidad del negocio incluye:Criterios de éxitoIdentificación de riesgosEstimación de recursos necesariosPlan de las fases incluyendo hitosProductos:Un documento de visión general:Requerimientos generales del proyectoCaracterísticas principalesRestriccionesModelo inicial de casos de uso (10% a 20 % listos).Glosario.Caso de negocio:
  3. 3. ContextoCriterios de éxitoPronóstico financieroIdentificación inicial de riesgos.Plan de proyecto.Uno o más prototipos.Hito:Las partes interesadas deben acordar el alcance y la estimación de tiempo ycosto.Comprensión de los requerimientos plasmados en casos de uso.RUP: ElaboraciónObjetivos:Analizar el dominio del problemaEstablecer una arquitectura base sólidaDesarrollar un plan de proyectoEliminar los elementos de mayor riesgo para el desarrollo exitoso del proyectoVisión de "una milla de amplitud y una pulgada de profundidad" porque lasdecisiones de arquitectura requieren una visión global del sistema.Productos:Es la parte más crítica del proceso:Al final toda la ingeniería "dura" está hechaSe puede decidir si vale la pena seguir adelanteA partir de aquí la arquitectura, los requerimientos y los planes de desarrollo sonestables.Ya hay menos riesgos y se puede planificar el resto del proyecto con menorincertidumbre.Se construye una arquitectura ejecutable que contemple:Los casos de uso críticosLos riesgos identificadosModelo de casos de uso (80% completo) con descripciones detalladas.Otros requerimientos no funcio-nales o no asociados a casos de uso.Descripción de la Arquitectura del Software.
  4. 4. Un prototipo ejecutable de la arquitectura.Lista revisada de riesgos y del caso de negocio.Plan de desarrollo para el resto del proyecto.Un manual de usuario preliminar.Hito:Condiciones de éxito de la elaboración:¿Es estable la visión del producto?¿Es estable la arquitectura?¿Las pruebas de ejecución demuestran que los riesgos han sido abordados yresueltos?¿Es el plan del proyecto algo realista?¿Están de acuerdo con el plan todas las personas involucradas?RUP: ConstrucciónEn esta fase todas las componentes restantes se desarrollan e incorporan alproducto.Todo es probado en profundidad.El énfasis está en la producción eficiente y no ya en la creación intelectual.Puede hacerse construcción en paralelo, pero esto exige una planificacióndetallada y una arquitectura muy estable.Productos:El producto de software integrado y corriendo en la plataforma adecuada.Manuales de usuario.Una descripción del "release" actual.Hito:Se obtiene un producto Beta que debe decidirse si puede ponerse en ejecución sinmayores riesgos.Condiciones de éxito:¿El producto está maduro y estable para instalarlo en el ambiente del cliente?¿Están los interesados listos para recibirlo?
  5. 5. RUP: TransiciónEl objetivo es traspasar el software desarrollado a la comunidad de usuarios.Una vez instalado surgirán nuevos elementos que implicarán nuevos desarrollos(ciclos).Incluye:Pruebas Beta para validar el producto con las expectativas del clienteEjecución paralela con sistemas antiguosConversión de datosEntrenamiento de usuariosDistribuir el productoObjetivos:Obtener autosuficiencia de parte de los usuarios.Concordancia en los logros del producto de parte de las personas involucradas.Lograr el concenso cuanto antes para liberar el producto al mercado.DefinicionesRolesUn Rol define el comportamiento y las responsabilidades de un individuo.Es como un "sombrero" que la persona usa durante el proyecto:Una persona puede tener varios sombrerosEs el “trabajo” que desempeña en un momento dadoResponsabilidades:Hacer una serie de actividadesSer el responsable de una serie de artefactosActividades
  6. 6. Una actividad es una unidad de trabajo que se asigna a un trabajador.Ejemplo:Crear o modificar un artefactoUna actividad lleva entre un par de horas y un par de días, involucra un solotrabajador y un número pequeño de artefactos.Las actividades se consideran en la planificación y evaluación del progreso delproyecto.Ejemplos:Planificar una iteración - Administrador de proyectoEncontrar actores y casos de uso - AnalistaRevisar el diseño - Revisor de diseñoEjecutar pruebas de performance - Ing. de pruebas de performance Recurso Rol ActividadGráfico de asignación de actividadesArtefactosElementos de información producidos, modificados o usados por el proceso.Son los productos tangibles del proyecto.Son usados por los trabajadores para realizar nuevas actividades y son elresultado de esas actividades.Ejemplos:Un modelo, como el modelo de casos de uso o el modelo de diseño.
  7. 7. Un elemento del modelo, como una clase o un caso de uso.Un documento tal como el Caso del Negocio o la Arquitectura del Software.Código fuente.Código ejecutable.El Proceso Unificado está centrado en la arquitecturaEl papel del arquitecto de sistemas es similar en naturaleza al papel que elarquitecto desempeña en la construcción de edificios. El edificio se mira desdediferentes puntos de vista: estructura, servicios, plomería, electricidad, etc. Esto lepermite al constructor ver una radiografía completa antes de empezar a construir.Similarmente, la arquitectura en un sistema de software es descrita comodiferentes vistas del sistema que está siendo construido.El concepto de arquitectura de software involucra los aspectos estáticos ydinámicos más significativos del sistema. La arquitectura surge de las necesidadesde la empresa, tal y como las interpretan los usuarios y otros stakeholders, y tal ycomo están reflejadas en los casos de uso. Sin embargo, también estáinfluenciada por muchos otros factores, tales como la plataforma de software en laque se ejecutará, la disponiblidad de componentes reutilizables, consideracionesde instalación, sistemas legados, requerimientos no funcionales (ej. desempeño,confiabilidad). La arquitectura es la vista del diseño completo con lascaracterísticas más importantes hechas más visibles y dejando los detalles delado. Ya que lo importante depende en parte del criterio, el cual a su vez viene conla experiencia, el valor de la arquitectura depende del personal asignado a estatarea. Sin embargo, el proceso ayuda al arquitecto a enfocarse en las metascorrectas, tales como claridad (understandability), flexibilidad en los cambiosfuturos (resilience) y reuso.¿Cómo se relacionan los casos de uso con la arquitectura? Cada producto tienefunción y forma. Uno sólo de los dos no es suficiente. Estas dos fuerzas debenestar balanceadas para obtener un producto exitoso. En este caso funcióncorresponde a los casos de uso y forma a la arquitectura. Existe la necesidad deintercalar entre casos de uso y arquitectura. Es un problema del “huevo y lagallina”. Por una parte, los casos de uso deben, cuando son realizados,acomodarse en la arquitectura. Por otra parte, la arquitectura debe proveerespacio para la realización de todos los casos de uso, hoy y en el futuro. En larealidad, ambos arquitectura y casos de uso deben evolucionar en paralelo.El Proceso Unificado es Iterativo e IncrementalDesarrollar un producto de software comercial es una tarea enorme que puedecontinuar por varios meses o años. Es práctico dividir el trabajo en pequeñospedazos o mini-proyectos. Cada mini-proyecto es una iteración que finaliza en unincremento. Las iteraciones se refieren a pasos en el flujo de trabajo, losincrementos se refieren a crecimiento en el producto. Para ser más efectivo, lasiteraciones deben estar controladas, esto es, deben ser seleccionadas y llevadas acabo de una manera planeada.Los desarrolladores basan su selección de qué van a implementar en una iteraciónen dos factores. Primero, la iteración trata con un grupo de casos de uso que enconjunto extienden la usabilidad del producto. Segundo, la iteración trata con los
  8. 8. riesgos más importantes. Las iteraciones sucesivas construyen los artefactos deldesarrollo a partir del estado en el que fueron dejados en la iteración anterior.En cada iteración, los desarrolladores identifican y especifican los casos de usorelevantes, crean el diseño usando la arquitectura como guía, implementan eldiseño en componentes y verifican que los componentes satisfacen los casos deuso. Si una iteración cumple sus metas – y usualmente lo hace – el desarrollocontinúa con la siguiente iteración. Cuando la iteración no cumple con sus metas,los desarrolladores deben revisar sus decisiones previas y probar un nuevoenfoque.ConclusiónLos conceptos anteriormente tratados – dirigido por casos de uso, centrado enarquitectura, desarrollo iterativo e incremental – son igualmente importantes. Laarquitectura provee la estructura sobre la cual guiar el trabajo en iteraciones,mientras que los casos de uso definen las metas y dirigen el trabajo en cadaiteración. Remover cualquiera de estos conceptos reducirá severamente el valordel Proceso Unificado. Es como una mesa de tres patas, sin alguna de ellas, lamesa se caerá

×