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:
- Initial planning
- Planning
- Requirements
- Analysis
- Design implementation
- Test
- Evaluation (si es necesaria)
- 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.
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.
- 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
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.
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
Post a Comment