Please enable JavaScript.
Coggle requires JavaScript to display documents.
Introducción al Rational Unified Process (RUP) - Coggle Diagram
Introducción al Rational Unified Process (RUP)
Historia de RUP
1967
Se crea la metodología ericsson
aproximacion basa en componentes que introdujo el concepto de casos de uso
1987-1995
se funda la compañía Objectory AB y lanza el proceso de desarrollo Objectory.
1995-1997
Creación del Rational Objectory Process (ROP) e integración de UML.
Rational software desarrollo e incorporo diversos elementos para expandir ROP, destacandose el flujo de trabajo conocidoco como modelado del negocio
Caracteristicas Esenciales de RUP
Dirigido por casos de uso
El casos de uso se usa de forma intenciva para capturar requisitos funcionales y guiar el diseñio, implementancion y pruebas
Centrado en la arquitectura
Es una herramienta que se desarrolla, contiene todos los elementos y procesos del software que deberan de ser construidos
Iterativo e incremental
Se divide el proyecto en mini proyectos que permiten ajustes constantes y mejora progresiva del software
Proceso de desarrollo
Fases
Inicio
Es definida el alcance que tendra el proyecto junto con sus planificaciones iniciales
enfasis en actividades modelado del negocio y de requisitos
Elaboracion
Se establece la arquitectura base y se eliminan algunos riesgos
abarcan mas los flujos de trabajo de requerimiento
Construccion
Es desarrollado el producto por medio de una serie de iteraciones
en cada iteracion se selecciona algunos casos de uso en los que se refina su analisis y diseño
Transiicion
Se entrega el producto, se hacen los ajustes finales
Cada fase consiste en varias iteraciones que se encargan de refinar el proceso con las revisiones y desarrollo incremental
Estructura del proceso
Componentes
las disciplinas involucradas, flujos de trabajo, roles y artefactos generados.
Tiempo
se detalla las fases del ciclo de vida del software
elaboracion
construccion
transicion
inicio
Roles
Analistas
Encargador de analizar procesos de negocios , es el especifciador de los requisitos,
Desarrolladores
Encargador de ser el arquitecto del software y diseñador
Gestores
Es el jefe del proyecto, gestiona los proyectos, junto con las pruebas
Apoyo
Encargador de ser el documentador tecnico y administrador de sistemas
Especialista en pruebas
Encargado de asegurar la calidad y funcionamiento del software
Flujos de trabajo
Modelado del negocio
Entender y poder describir la estructura de organizacion y los procesos de negocio
Requisitos
Se establece que debe hacer el sistema
Se lleva a cabo la captura de requisitos tanto funcionales como no funcionales
Análisis y diseño
Se transforman los requisitos a diseño y su arquitectura
Implementación
Se lleva a cabo al codificacion de los componentes de software
Pruebas
Se realizan evaluaciones para detectar errores
Gestion del proyecto
Supervicion del proyecto para que cumpla con requisitos y tiempo
Configuración y Control de Cambios
Mantener la integridad de todos los artefactos que se crean en el proceso
Entorno
Dar soporte al proyecto con las herramientas adecuadas, procesos y metodos
Entrega las herramientas que se van a necesitar en cada momento
Buenas practicas
Gestión de Requisitos
Asegurar que requisitos funcionales , restricciones deben de estar buenos y correctamente documentados
Desarrollo de Software Iterativo
Hacer el software de forma iterativa mediante hitos, se repiten las actividades pero con distinto enfasis
Desarrollo basado en componentes
Al dividir en componentes el software permite que el codigo sea ajustable a medida que se desarrolan sus componentes
Modelado Visual
Se debe usar UML para represtentar de manera grafica el software
UML
Es un lenguaje para visualizar especificar, construir y documetnar los artefactos de un sistema de
software
Verificación continua de la calidad
Se debe de implementar pruebas mientras se desarrolla para mantener la calidad
Gestion de los cambios
Se debede controlar las modificaciones que puedan causar impactos negativos
Tranzabilidad entre artefactos
Los enlaces entre los artefactos que establecen como se generan unos a partir de otros
Modelos y artefactos utilizados
Diagrama de actividad
Representa el flujo del trabajo que se llevara a cabo
Modelado de casos de uso
Se encuetran las funcionalidades que tendra el sistema y los actores
Especificaciones de casos de uso
Se incorporan descripciones detalladas para casos complejos
Modelado de analisis de diseño
Se representa la estructura del sistema con clases y estados
Modelo logico relacional
a partir del digrama de clases y conciderando las clases que necesiten persitencia
Modelo de implementacion
las operaciones de las clases en terminos de componentes de dicha arquitectura