RUP

Fase de Inicio

Fase de Elaboración

Fase de Construcción

Fase de Transicion

La disciplina del modelado de negocio

1

• Las organizaciones dependen cada día mas de las tecnologías de información (TI)
• Comprenden la ventaja competitiva del valor añadido por la tecnología
• Entender la estructura y la dinámica de la empresa objetivo (el cliente), los problemas actuales de la organización y las posibles mejoras
• El modelado de negocio explica como describir la visión de una organización en la que se implementara el sistema y como utilizar esta visión como base para describir los procesos funciones y responsabilidades

Requisitos del curso

2

Este curso explica como al llegar peticiones de las partes interesadas y los convierten en un conjunto de requisitos que los productos funcionan dentro del sistema que se construirán y proporcionar los requisitos detallados para lo que es necesario que el sistema.

Análisis y diseño de la disciplina

3

Mostrar como se llevara a cabo el sistema

El objetivo es construir un sistema que:

• Ejecutar en un entorno de ejecución especifica, las tareas y las funciones especificadas en las descripciones de casos de uso
• Satisfacer todas sus necesidades
• Es fácil mantener cuando no son cambios en los requisitos funcionales, los resultados del proyecto en un modelado de análisis y diseño tiene opcionalmente un modelado de análisis.
• El modelo de diseño consta de clases de diseño estructurados en paquetes y subsistemas con interfaces bien definidas

La disciplina de la implementación

4

• Para configurar el código de las organizaciones en términos de subsistemas de aplicación organizados en capas
• Para llevar a cabo las clases y objetos en términos de componentes
• Para probar los componentes desarrollados como unidades
• Incorporar los resultados producidos por los ejecutores individuales

Prueba de la disciplina

5

• Comprobar la interacción entre los objetos
• Comprobar la correcta integración de todos los componentes de software
• Compruebe que todos los requisitos han sido ejecutadas correctamente
• Identificar y asegurar que los defectos se tratan antes de la implementación de software
• Asegúrese de que todos los defectos son corregidos, revisados y cerrados

Implementación

6

El propósito del despliegue es producir lanzamientos de productos exitosos y entregar el software a los usuarios finales.

Los procesos (flujos de trabajo) de implementación y medio ambiente RUP contienen menos detalles que otros flujos de trabajo.

Configuración de la disciplina y de la gestión

La disciplina de la gestión del cambio: en el negocio con RUP abarca tres tratamientos específicos:

Configuración, solicitudes de cambio, y el estado y de medida.

La gestión de configuración

Gestión de la configuración es responsable de la estructuración sistemática de productos. Los artefactos tales como documentos y modelos necesitan estar bajo el control de versiones y estos cambios deben ser visibles.

La gestión del cambio de solicitud

Durante el proceso de desarrollo del sistema con muchos artefactos que existen varias versiones.

El estado y la mediación de la gestión

Las solicitudes de cambio tienen los estados: nuevo, conectado, aprobado, asignado y completo. La solicitud de cambio también tiene atributos como la causa raíz, o la naturaleza (como el incumplimiento y recuperación), prioridad, etc.

Estos estados y atributos

se almacenan en la base de datos para producir informes útiles sobre el progreso del proyecto. Racional también tiene un producto para mantener las solicitudes de cambio llamados ClearQues.

A

Este curso se centra principalmente en los aspectos importantes de un proceso de desarrollo iterativo: La gestión de riesgos: La planificación de un proyecto iterativo a través del ciclo de vida y para una iteración en particular: Y el proceso de seguimiento de un proyecto iterativo, la métrica. Sin embargo, esta disciplina de RUP no pretende cubrir todos los aspectos de la gestión de proyectos.

The code for the topic.

DESARROLLO ITERATIVO

Teniendo en cuenta el tiempo necesario para desarrollar un software grande y sofisticado, no se puede definir el problema y construir software en un solo paso. Los requisitos cambiarán a menudo en el curso del desarrollo del proyecto , debido a las restricciones de la arquitectura , las necesidades del usuario o para una mayor comprensión del problema original.

LA GESTIÓN DE REQUISITOS

RUP sugiere que la administración de requerimientos tiene que seguir las actividades:

1) Análisis de los problemas

2) La comprensión de las necesidades

3) La definición del problema

4) Administrar el alcance del sistema

5) Refinar los ajustes del sistema

6) Los requisitos de gestión del cambio

EL USO DE UNA ARQUITECTURA BASADA EN COMPONENTES

La arquitectura basada en componentes crea un sistema que es fácilmente extensible, intuitiva y fácil de entender y promueve la reutilización de software.

SOFTWARE DE MODELADO VISUAL

Haciendo abstracción de su programación de su código y representarla por medio de bloques de construcción gráficas constituye una forma eficaz de obtener una visión general de una solución.

SOFTWARE DE CONTROL DE CALIDAD

Aseguramiento de la calidad del software es el punto de fallo más común en los proyectos de software, ya que esto es a menudo algo que no se había pensado anteriormente y, a veces es tratado por diferentes equipos.

RUP supone que cada miembro del equipo es responsable de la calidad durante todo el proceso. El proceso se centra en el descubrimiento de el nivel esperado de la calidad y proporciona pruebas en los procesos para medir este nivel.

CONTROL DE CAMBIOS EN EL SOFTWARE

En todos los proyectos de software, los cambios son inevitables. RUP define métodos para controlar, seguir y supervisar estos cambios.