*    Universidad Abierta Interamericana    Ing. Luis Alberto Perdomo    2011
“The Rational Unified Process® is aSoftware Engineering Process. It provides adisciplined approach to assigning tasks andr...
* Mejora en al productividad del equipo: provee  un acceso a una base de  conocimiento, obteniendo un lenguaje  común, pro...
* 1) Desarrollo iterativo del software: permite entender de forma incremental mediante la ejecución de iteraciones que arr...
* 2) Administración de requerimientos: describe cómo obtener, organizar y documentar las funcionalidades requeridas y las ...
* 3) Uso de arquitecturas basadas en componentes: se define componente a un módulo no trivial o subsistemas que cumplen un...
* 4) Modelado visual del software: permite ocultar detalles específicos y evitar escribir código mediante el uso de editor...
* 5) Verificación de la calidad del software: ejecución de pruebas de funcionalidad, performance, tiempos de respuesta. Ve...
* 6) Controles de los cambios del software: cómo controlar, realizar el seguimiento y monitorear los cambios para asegurar...
FasesFlujos de Trabajo de Procesos           Inicio        Elaboración         Construcción             Transición        ...
* Fase 1 (Inicio):  * Visión del proyecto: requerimientos “core”,    funcionalidades y restricciones principales.  * Defin...
* Fase 2 (Elaboración):  * Definición de actores y casos de uso (al menos el    80% ya definido).  * Captura de requerimie...
* Fase 3 (Construcción):  * Producto de software integrado a las plataformas    adecuadas.  * Manuales de usuario.  * Desc...
* Fase 4 (Transición):  * Beta testing para la validación del nuevo sistema    según las expectativas.  * Operación en par...
FasesFlujos de Trabajo de Procesos           Inicio        Elaboración         Construcción             Transición        ...
* Rational Unified Process: best Practices for software development teams* Wikipedia* Sparx UML Tutorial             *
Upcoming SlideShare
Loading in …5
×

Rational unified process (rup)

2,392 views

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,392
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
79
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Rational unified process (rup)

  1. 1. * Universidad Abierta Interamericana Ing. Luis Alberto Perdomo 2011
  2. 2. “The Rational Unified Process® is aSoftware Engineering Process. It provides adisciplined approach to assigning tasks andresponsibilities within a developmentorganization. Its goal is to ensure theproduction of high-quality software that meetsthe needs of its end-users, within a predictableschedule and budget” IBM - Rational *
  3. 3. * Mejora en al productividad del equipo: provee un acceso a una base de conocimiento, obteniendo un lenguaje común, procesos y vistas de cómo desarrollar el software.* Creación y mantenimiento de modelos: representaciones semánticas del sistema en desarrollo (UML + CASE tools).* Define un marco de proceso configurable: es adaptable tanto en equipos grandes como en equipos pequeños. *
  4. 4. * 1) Desarrollo iterativo del software: permite entender de forma incremental mediante la ejecución de iteraciones que arrojan refinamientos que ayudan a crecer al software. Permite enfocarse en los riesgos de la iteración y a su vez producir releases de las cuales se obtiene el feedback del cliente. Ayuda a reajustar estrategias de planeamiento y afrontar cambios en los requerimientos. *
  5. 5. * 2) Administración de requerimientos: describe cómo obtener, organizar y documentar las funcionalidades requeridas y las restricciones, realizar el seguimiento de dichos documentos y facilitar la comunicación de los requerimientos de negocio. La noción de casos de uso proveen una excelente forma de capturar requerimientos funcionales. *
  6. 6. * 3) Uso de arquitecturas basadas en componentes: se define componente a un módulo no trivial o subsistemas que cumplen una función bien definida. Una arquitectura basada en componentes resulta flexible, adaptable a los cambios y promueve la reutilización de elementos de software. Todos los componentes son ensamblados en dicha arquitectura que resulta un componente de infraestructura (ej. Internet, CORBA, REST, etc.) *
  7. 7. * 4) Modelado visual del software: permite ocultar detalles específicos y evitar escribir código mediante el uso de editores basados en abstracciones visuales. Permite una visión de integración y utiliza el estándar industrial conocido como Unified Modeling Language (UML) el cual define una notación para la representación de elementos de software. *
  8. 8. * 5) Verificación de la calidad del software: ejecución de pruebas de funcionalidad, performance, tiempos de respuesta. Verificación de la alineación de las funcionalidades del sistema a los requerimientos de negocio identificados. *
  9. 9. * 6) Controles de los cambios del software: cómo controlar, realizar el seguimiento y monitorear los cambios para asegurar el éxito en el proceso de desarrollo iterativo. Establecer lugares aislados para cada desarrollador y permitir unificar el trabajo del equipo en una única unidad integrada automática mente (merge). *
  10. 10. FasesFlujos de Trabajo de Procesos Inicio Elaboración Construcción Transición Modelación de Negocios Requerimientos Análisis y Diseño Implementación Prueba Implantación Flujos de Trabajo de Soporte Admin. Configuración Admin. de Proyectos Ambiente o Entorno Iteración(es) Iter. Iter. Iter. Iter. Iter. Iter. Iter. Preliminar #1 #2 #n #n+1 #n+2 #m #m+1 Iteraciones *
  11. 11. * Fase 1 (Inicio): * Visión del proyecto: requerimientos “core”, funcionalidades y restricciones principales. * Definición de actores y casos de uso (10-20 %). * Un glosario de términos del dominio. * Análisis inicial de riesgos. * Plan del proyecto, identificando fases e iteraciones. * Modelo de negocio y otros prototipos necesarios. *
  12. 12. * Fase 2 (Elaboración): * Definición de actores y casos de uso (al menos el 80% ya definido). * Captura de requerimientos no funcionales. * Descripción de la arquitectura de software. * Un prototipo ejecutable de la arquitectura. * Plan de desarrollo con evaluaciones y criterios. * Manual de usuario preliminar (opcional). *
  13. 13. * Fase 3 (Construcción): * Producto de software integrado a las plataformas adecuadas. * Manuales de usuario. * Descripción del release actual. *
  14. 14. * Fase 4 (Transición): * Beta testing para la validación del nuevo sistema según las expectativas. * Operación en paralelo con sistemas legacy a reemplazar. * Conversión de bases de datos operacionales. * Entrenamiento de usuarios. * Roll-out del producto a marketing, distribución, etc. *
  15. 15. FasesFlujos de Trabajo de Procesos Inicio Elaboración Construcción Transición Modelación de Negocios Requerimientos Análisis y Diseño Implementación Prueba Implantación Flujos de Trabajo de Soporte Admin. Configuración Admin. de Proyectos Ambiente o Entorno Iteración(es) Iter. Iter. Iter. Iter. Iter. Iter. Iter. Preliminar #1 #2 #n #n+1 #n+2 #m #m+1 Iteraciones *
  16. 16. * Rational Unified Process: best Practices for software development teams* Wikipedia* Sparx UML Tutorial *

×