ARTEFACTOS
1. Popular entre las empresas.
2. Facilidad de Asignacion de tareas, roles y actividades.
3. Promueve la reusabilidad.
4. Reduce la complejidad del mantenimiento (extensibilidad y facilidad de cambios).
5. Facilita la construcción de prototipos.
- Popular entre las empresas. Es el proceso de desarrollo más general de los existentes actualmente. Es decir, este proceso es de los mas utilizados para el desarrollo del software por la mayoría de las empresas, pues su enfoque es bastante optimo y tiende a ser una metodología viable para la mayoría de estas.
- Facilidad de Asignación de tareas, roles y actividades. Es una forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo, pues lo roles están muy bien definidos, y dictan quien realiza cada actividad, dependiendo del área en el que se desarrollara, de esta manera es bastante útil para definir roles en los proyectos.
- Promueve la reusabilidad. Reutilización. Los roles y distintos pueden ser reutilizados en proyectos futuros, dando como resultado una mejor organización al proyecto y menos utilización de recursos o tiempo, aspectos que se pueden emplear directamente en el proyecto.
- Reduce la complejidad del mantenimiento (extensibilidad y facilidad de cambios). Mantenimiento más sencillo y modificaciones locales. Esta es una ventaja muy importante, pues si el proceso así lo permite es bastante más fácil poder realizar un cambio al proyecto en un futuro, sin generar perdidas o retrasos tan notorios o sobresalientes.
- Facilita la construcción de prototipos. Un proceso de software hecho a la medida para ser publicado y hacerlo accesible para todo el equipo del proyecto. Esto quiere decir que cualquiera que se encuentre trabajando en el proyecto pueda acceder a este con más facilidad, evitando problemas relacionados a este tipo de cuestiones.
1. Por el grado de complejidad puede ser no muy adecuado.
2. En proyectos pequeños, es posible que no se puedan cubrir los costos de dedicación del equipo de profesionales necesarios.
3. Método pesado.
- Por el grado de complejidad puede ser no muy adecuado. Debido a que es un proceso bastante grande y complejo es muy común que no sea el adecuado para cualquier proyecto pequeño (cosa que se explicara en la siguiente desventaja), es por eso que a veces no puede ser el adecuado.
- En proyectos pequeños, es posible que no se puedan cubrir los costos de dedicación del equipo de profesionales necesarios. Al ser una metodología bastante cara y con bastantes requerimientos en cuanto a roles (personales), a veces los costos son muy elevados, dando como resultado una imposibilidad por costear el proyecto.
- Método pesado. En muchos aspectos tiende a ser muy pesado, pues como se explicaba en los puntos anteriores, la complejidad es alta.
DESVENTAJAS
OTROS ROLES
Otros roles.
- Stakeholders
- Revisor
- Coordinación de revisiones
- Revisor técnico
ESPECIALISTAS EN PRUEBAS
Especialista en pruebas.
- Especialista en Pruebas (tester)
- Analista de pruebas
- Diseñador de pruebas
APOYADORES
Apoyo.
- Documentador técnico
- Administrador de sistema
- Especialista en herramientas
- Desarrollador de cursos
- Artista gráfico
DESAROLLADORES
Desarrolladores.
- Arquitecto de software.
- Diseñador
- Diseñador de interfaz de usuario
- Diseñador de cápsulas.
- Diseñador de base de datos.
- Implementador.
- Integrador. Gestores:
- Jefe de configuración.
- Jefe de pruebas
- Jefe de despliegue
- Ingeniero de procesos
- Revisor de gestión del proyecto
- Gestor de pruebas.
ANALISTAS
Analistas.
- Analista de procesos de negocio.
- Diseñador del negocio.
- Analista de sistema.
- Especificador de requisitos.
- Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)
- Pretende implementar las mejores prácticas en Ingeniería de Software
- Desarrollo iterativo
- Administración de requisitos
- Uso de arquitectura basada en componentes
- Control de cambios
- Modelado visual del software
- Verificación de la calidad del software
Despliegue
- Diagrama de despliegue.
- Manual de usuario.
- Manual de instalación y configuración.
Documento Arquitectura que trabaja con las siguientes vistas:
Vista Lógica:
- Diagrama de clases
- Modelo E-R (Si el sistema así lo requiere)
Vista de Implementación:
- Diagrama de Secuencia
- Diagrama de estados
- Diagrama de Colaboración
Vista Conceptual:
Vista física:
- Mapa de comportamiento a nivel del hardware.
Requisitos
- Modelo de Casos de Uso:
- Diagrama de casos de uso.
- Especificación de casos de uso (utilizar una plantilla o formato). Se debe seleccionar sólo los casos de uso de alta prioridad o más importantes para el negocio, del tipo Core.
Análisis y Diseño
- Modelo de Análisis
- Diagrama de Secuencia. Un diagrama por caso de uso, pero sólo para el flujo básico. Se debe seleccionar sólo los casos de uso de alta prioridad o más importantes para el negocio.
- Diagrama de Clases de análisis. Incluye todas las clases de provienen del modelo de dominio pero con atributos y métodos.
- Modelo de datos. Las tablas pueden derivar de las clases del dominio.
- Prototipos de usuario. Son los diseños de interfaz de usuario que serán implementados. -Seleccionar los casos de uso más importantes, del tipo Core.
Implementación
- Programación de las funcionalidades o casos de uso más importantes.
- Casos de Prueba. Aplicar pruebas unitarias a los casos de uso más importantes.
Modelado de Procesos
- Especificación de Requerimientos
- Modelo de Casos de Uso de Negocio:
- Diagrama de Casos de Uso de Negocio.
- Modelo de Análisis del Negocio:
- Diagrama de Actividades (un diagrama por cada proceso).
- Modelo del Dominio. Es un diagrama de clases conceptuales donde cada clase sólo debe tener atributos.
- Documento Visión (contiene necesidades y características).
VENTAJAS
ROLES
Según RUP, un rol es un puesto que puede ser asignado a una persona o conjunto de personas que trabajan juntos en un equipo, y que requiere responsabilidades y habilidades sobre cómo realizar actividades específicas y desarrollar determinados artefactos.
Los miembros de un equipo de proyecto, generalmente cubren varios roles; sin embargo, los roles no son individuales, ellos más bien describen cómo los individuos se comportan en un negocio y qué responsabilidades tienen estos individuos.
En Rup en cada una de sus fases realizan una serie de artefactos para saber mejor la función y estructura de un programa.
En Rup en cada una de sus fases realizan una serie de artefactos para saber mejor la función y estructura de un programa.
- Un artefacto puede ser:
- Un documento: como un Caso de Negocio o un documento de la arquitectura del Software.
- Un modelo: como un modelo de caso de uso.
- Un elemento de un modelo: como una sola clase de todo el Diagrama de Clases.
Cada artefacto sirven para cada paso para la elaboración del programa.s
TRANSICIÓN
Durante esta fase de transición se busca garantizar que el producto este bien preparado para su entrega al usuario. Es una fase que puede tener muchos cambios a la hora de la entrega.
CONSTRUCCIÓN
Durante la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones las cuales se seleccionan algunos Casos de Uso, se define su análisis y después el diseño y se procede a su implantación y sus respectivas pruebas. En esta fase se realiza una serie de cascadas para cada ciclo, se realizan tantas iteraciones hasta que se termine la nueva implementación y el producto este listo para ser enviado al usuario.
ELABORACIÓN
Durante esta fase de elaboración, se centran al desarrollo de los casos de uso tomando como base la de diseño, como lo dice la elaboración lleva una serie de requerimientos una serie de pasos:
- El modelo de la organización.
- El análisis.
- El diseño.
Se van acumulando las actividades y para empezar una parte de implementación mediante desarrollo de la fase de inicio que va a ser orientada a la base de la construcción de todas las especificaciones de la arquitectura del diseño. hasta obtener una diseño bien construido.
INICIO
Durante esta fase de inicio las iteraciones se centran con mayor énfasis en las actividades de modelamiento de la empresa y en sus requerimientos. Esta fase se centra mas en buscar o planear todo lo que la empresa requiera para luego utilizar sus recursos mejorando y dándole una visión de lo que se espera plantear en el proyecto.
FASES
FASES
HERRAMIENTAS.
Estas herramientas se usan para cada fase.
CARACTERISTICAS
El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, de estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo de este proceso).
Enfocarse en la calidad
El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente.
Elevar el nivel de abstracción
Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita que los ingenieros de software vayan directamente de los requisitos a la codificación de software a la medida del cliente, sin saber con certeza qué codificar para satisfacer de la mejor manera los requisitos y sin comenzar desde un principio pensando en la reutilización del código. Un alto nivel de abstracción también permite discusiones sobre diversos niveles y soluciones arquitectónicas. Éstas se pueden acompañar por las representaciones visuales de la arquitectura, por ejemplo con el lenguaje UML.
Colaboración entre equipos
El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc.
Demostrar valor iterativamente
Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados.
Equilibrar prioridades
Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se podrán corregir desacuerdos que surjan en el futuro.
Adaptar el proceso
El proceso deberá adaptarse a las necesidades del cliente ya que es muy importante interactuar con él. Las características propias del proyecto u organización. El tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener en cuenta el alcance del proyecto en un área subformal.
Su objetivo es asegurar la producción de software de alta y de mayor calidad para satisfacer las necesidades de los usuarios que tienen un cumplimiento al final dentro de un limite de tiempo y presupuesto previsible.
El Rational Unified Process o Proceso Unificado de Racional. Es un proceso de ingeniería de software que suministra un enfoque para asignar tareas y responsabilidades dentro de una organización de desarrollo.
La metodología de desarrollo RUP por sus siglas en inglés ó Proceso de Desarrollo Unificado es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.
El Proceso Unificado Racional (Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.
RUP (PROCESO UNIFICADO RACIONAL)
PRINCIPIOS DE DESARROLLO
