Modelo RUP

 


DEFINICION DEL MODELO RUP

Es un proceso  que su propósito es crear una propuesta que este orientada a las tareas y responsabilidad sobre un software. Se encarga en asegurar que el software este hecho con una buena calidad. 

Este herramienta es usada por:
  • Profesionales de software
  • Personas interesadas en software 
  • Profesionales en la ingeniería
Es usada para provee un proceso y ayuda a tener claro el proceso. 

CARACTERISTICAS

Dirigidos por casos por uso:

Estos son los artefactos para establecer el comportamiento del sistema.

Centrado en la arquitectura:

Estas son las que usan para conceptualizar, construir, administrar y evolucionar el sistema. 

Iterativo e incremental:

Maneja una serie de entregas e integra continuamente la arquitectura.

Generales:

  • Amplio y diverso
  • Evolución continua 
  • Adaptable
  • Repetible
  • Permite mediciones de datos

CICLO DE VIDA

Se compone de 8 pasos:
  1. Initial planning
  2. Planning
  3. Requirements
  4. Analysis
  5. Design implementation
  6. Test
  7. Evaluation (si es necesaria)
  8. Deployment
El diagrama general se compone de 3 cosas: las fases, el eje horizontal y el eje vertical.

Se divide en 4 fases: Inicio, elaboración, construcción y transición. 

Eje horizontal: Representa el tiempo y sus aspectos.

Eje vertical: Representa las disciplinas. 


inicio o inception

    • EL objetivo general de esta fase es generar y establecer un acuerdo entre todos entre todos los interesados acerca de los objetivos del proyecto.

    • es significativamente importante para el desarrollo de nuevos software, ya que se aseguran de identificar los riesgos relacionados con el negocio y requerimiento.
    • para proyectos de mejoras de software existente, esta fase es mas breve y se centra en asegurar la viabilidad de desararollar el proyecto.





construccion
  • el objetivo de la fase de construccion es clarificar los elementos faltantes y completar el desarrollo del sistema basados en arquitectura de base.
  • vista de cierta forma esta fase es la fase de manufactura, en el cual el enfasis se entorna hacia la administracion de recursos y control de las operaciones para optimizar costos, tiempo y calidad.










































Transicion
  • esta fase se enfoca en asegurar que el software este disponible para sus usuarios.
  • se puede subdividir en varias intersecciones, ademas incluye pruebas del producto para poder hacer el entregable del mismo, asi como realizar ajustes menores de acuerdo a las propuestas del cliente.
  • en este punto, la


  • retroalimenacion de los usarios se centra en depurar los producion, configuraciones e instalacion y aspectos sobre su funcion.



Disciplinas

  • son un conjunto de actividades relacionada a un area en especifico dentro del proyecto.
  • esta inspirada en una etapa de procesos de desarrollo de cascada
  • es una secuancia parcialmente ordenadas de actividades que son realizadas para lograr un resultado, particular representado en un conjunto de artefactos


Las disciplinas son:
  • modelos de negocios.
  • requerimiento.
  • analisis y diseño.
  • implementacion.
  • pruebas.
  • de transicion.
  • configuracion y administracion de cambio.
  • administracion de proyectos y ambientes.
modelado de negocios:
los propositos que tiene un modelado de negocios son;
  • entender el problema que la organizacion desea resolver o identificar mejoras disponibles.
  • medir aspecto del cambio organizacional.
  • asegurar que clientes, usuarios finales, desarrolladores y los otros participantes tengan un entedimiento compratido del problema.
  • derivar los requerimientos del sistema del software, necesarios para dar soportes a los objetivos de la organizacion.
  • entender como el sistema a ser desarrollado entra dentro de la organizacion.



Loa requerimiento tienen el proposito de:
  • establecer y mantener un acuerdo con los clientes y los otros interesados acerca de que se debe de hacer el sistema.
  • promoveer el desarolladores del sistema de un mejor entendimiento de lo requerimientos del sistema.
  • definir los limites del sistema
  • promover un base para la pleaneacion de los contenidos tecnicos de las iteraciones.
  • promoveer un base para la estimacion del costo y tiempo necesarios para desarrollo del sistema.
  • definir una interfaz de usuarios para el sistema, enfocado en las necesidades y objetivos del usuarios.



el propositos del analisis y diseño son:
  • transformar los requerimientos diseños del sistema.
  • desarrollar una arquitectura robusta para el sistema.
  • adaptar el sistema y hacerlo corresponder con el ambiente de implementacion y ajustarlo para un desempeño esperado.




los propositos de implementacion son:
  •  definir organizacion del codigo, en terminis en la inmplementacion de los subsistemas organizados en capas.
  • implementar el diseñoi de los elementos en terminos de los otros elementos (archivos fuentes, binarios, ejecutables y otros)
  • probar los elementos desarrollados como binarios.
  • integrar los sistemas individuales en un sistema ejecutados.


Transición:
  • Esta disciplina describe las actividades asociadas con el aseguramiento de la entrega y disponibilidad del producto de software hacia el usuario final.
  • Existe un énfasis en probar el software en el sitio de desarrollo, realización de pruebas beta del sistema antes de su entrega final al cliente.


Administración y Configuración del Cambio

Consiste en controlar los cambios y mantener la integridad de los productos que incluye el proyecto.
Incluye:
  • Identificar los elementos configurables.
  • Restringir los cambios en los elementos configurables.
  • Auditar los cambios hechos a estos elementos.
  • Definir y mantener las configuraciones de estos elementos.
Los métodos, procesos y herramientas usadas para proveer la administración y configuración del cambio pueden ser consideradas como el sistema de administración de la configuración.

Administración de Proyectos 
El propósito de la Administración de Proyectos es:
  • Proveer un marco de trabajo para administrar los proyectos intensivos de software.
  • Proveer guías prácticas para la planeación, soporte, ejecución y monitoreo de proyectos.
  • Proveer un marco de trabajo para la administración del riesgo.

Ambiente:

  • Se enfoca en las actividades necesarias para configurar el proceso al proyecto.
  • Describe las actividades requeridas para desarrollar las líneas guías de apoyo al proyecto.
  • El propósito de las actividades de ambiente es proveer a las organizaciones de desarrollo de software del ambiente necesario (herramientas y procesos) que den soporte al equipo de desarrollo.


     DISCIPLINAS 
  • Workflow
  • Detalles del workflow
  • Actividades
  • Artefactos
  • Guías de aplicación
ROLES:
  • Definen el comportamiento y responsabilidades de individuos o grupos de individuos
  • Un individuo puede jugar más de un rol
  • Son descripciones abstractas de
  • Conjuntos de actividades realizadas
  • Responsabilidad sobre artefactos 
  • Ejemplos de roles
  • Software Architect
  • Architecture Reviewer


Actividades:
  • Una actividad es algo que un rol hace y que provee un resultado de interés en el contexto del proyecto.
  • Es una unidad de trabajo que individuos jugando cierto rol pueden ser llamados a realizar.
  • Son utilizadas para detallar los workflows.
  • Toman artefactos como entrada y producen artefactos (o nuevas versiones) como salida.


ARTEFACTOS:
Unidades de información creadas, producidas, cambiadas o utilizadas en el proceso de desarrollo.

Los artefactos son en muchos casos análogos al término general "entregables" en otras metodologías de gestión y desarrollo de proyectos, y son el "que" (el producto final ideal) de los procesos.


Los artefactos se usan como entradas por otros trabajadores para desempeñar una actividad, y son el resultado de otras actividades. Algunos ejemplos comunes de artefactos son: 

  • Un modelo, como los modelos de casos de uso, entidad relación o modelo de diseño. 
  • Un elemento de un modelo, como una clase, un caso de uso individual, o un subsistema. 
  • Un documento como un caso de negocios o un documento de arquitectura de software. 
  • Código fuente. 
  • Ejecutables.

¿Cuándo usar RUP?:
Puede utilizar RUP desde el principio de un nuevo proyecto de software, y puede seguir utilizándolo en los ciclos de desarrollo subsiguientes tiempo después de que el proyecto inicial haya terminado. No obstante, la forma de utilizar RUP varía para ajustarse a sus necesidades. 

Mayor necesidad de seguir un proceso definido:

Alta complejidad técnica
  - embebidos, tiempo real, distribuidos, tolerancia a fallas
  - alta performance
  - personalizado, sin precedentes, re-ingeniería arquitectónica

Alta complejidad gerencial
  - gran escala
  - contractual
  - muchos stakeholders

RUP puede utilizarse:
  • En proyectos de nuevos productos de software
  • En ciclos de desarrollo subsecuentes
  • Consideraciones que alteran cuándo y cómo usar partes de RUP
  • El ciclo de vida del proyecto
  • Los objetivos del negocio, la visión, el alcance y los riesgos
  • El tamaño del esfuerzo de desarrollo

CONCLUSIONES:

  • Es un modelo de proceso de desarrollo de software
  • Es una base para procesos particulares
  • El objetivo es asegurar el desarrollo
  • De productos de software de alta calidad
  • Que satisfagan los requerimientos
  • En tiempo y presupuesto predecible
  • Permite un vocabulario común entre equipos de desarrollo






Comments