Artefactos Sugeridos Por El Jurado Evaluador

Artefactos Sugeridos por el Jurado Evaluador:
Metodología RUP:
FLUJO DE CONTROL DE PROCESOS
Modelado del Negocio: Los propósitos que tiene el Modelo de Negocios son:
Entender los problemas que la organización desea solucionar e identificar mejoras
potenciales. Medir el impacto del cambio organizacional. Asegurar que clientes,
usuarios finales, desarrolladores y los otros participantes tengan un entendimiento
compartido del problema. Derivar los requerimientos del sistema de software,
necesarios para dar soporte a los objetivos de la organización. Entender como el
sistema a ser desarrollado entra dentro de la organización.
El modelado del negocio se basa en dos diagramas principales, el modelo de

casos de uso del negocio, el modelo del dominio y los modelos de objetos del
negocio.
Requisitos: Esta disciplina tiene el propósito de: Establecer y mantener un

acuerdo con los clientes y los otros interesados acerca de que debe hacer el
sistema. Proveer a los desarrolladores del sistema de un mejor entendimiento de
los requerimientos del sistema. Definir los límites (o delimitar) del sistema. Proveer
una base para la planeación de los contenidos técnicos de las iteraciones. Proveer
una base para la estimación de costo y tiempo necesarios para desarrollar el
sistema. Definir una interfaz de usuario para el sistema, enfocada en las
necesidades y objetivos del usuario.
Documento Visión, Glosario de términos, Casos de Usos del Sistema con sus
planillas de flujo de eventos y diagrama de actividades con Rational Rose, Gestión
de Requisitos con Requesite Pro. Plan de Riesgo. Gestión y Planificación del
Sistema.
Análisis y Diseño: Transformar los requerimientos a diseños del sistema,

Desarrollar una arquitectura robusta para el sistema, Adaptar el diseño para
hacerlo corresponder con el ambiente de implementación y ajustarla para un
desempeño esperado. Esta disciplina es la encargada de realizar todo los
diagramas tantos de la vista lógica, de implementación, conceptuales y físicos.
Implementación: El propósito de la implementación es: Definir la organización del

código, en términos de la implementación de los subsistemas organizados en
capas. Implementar el diseño de elementos en términos de los elementos
(archivos fuente, binarios, ejecutables y otros). Probar los componentes
desarrollados como unidades. Integrar los resultados individuales en un sistema
ejecutable.
Pruebas: Actúa como un proveedor de servicios a las otras disciplinas en muchos

aspectos. Se enfoca principalmente en la evaluación y aseguramiento de la
calidad del producto, desarrollado a través de las siguientes prácticas: Encontrar
fallas de calidad en el software y documentarlas. Recomendar sobre la calidad
percibida en el software. Validar y probar las suposiciones hechas durante el
diseño y la especificación de requerimientos de forma concreta. Validar que el
software trabaja como fue diseñado. Validar que los requerimientos
Despliegues: Esta disciplina describe las actividades asociadas con el

aseguramiento de la entrega y disponibilidad del producto de software hacia el
usuario final.
FLUJO DE CONTROL DE APOYO
Configuración y Manejo de Cambios: 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.
Administración del Proyecto: 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.
Entorno: 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.
Fase Inicio
Los artefactos o resultados de esta fase deben ser:
 Un documento de visión.
 Un documento de requerimientos.
 Modelo inicial de Casos de Uso.
 Un glosario inicial
 El caso de Negocio.
 Plan del proyecto, mostrando fases e iteraciones.
 Modelo de negocio.
 Las estimaciones de tiempo, costo y riesgo son creíbles.
Fase elaboración
 Un modelo de Casos de Uso completo al menos hasta el 80%:

 Requisitos adicionales que capturan los requisitos no funcionales y
cualquier requisito no asociado con un Caso de Uso específico.
 Descripción de la arquitectura software.
 Un prototipo ejecutable de la arquitectura.
 Plan de desarrollo para el proyecto.
 Un manual de usuario preliminar (opcional).
Fase construcción
Los artefactos o resultados de esta fase deben ser:
 Modelos Completos (Casos de Uso, Análisis, Diseño, Despliegue e

 Implementación).
 Arquitectura íntegra (mantenida y mínimamente actualizada).
 Riesgos Presentados Mitigados.
 Plan del Proyecto para la fase de Transición.
 Manual Inicial de Usuario (con suficiente detalle).
 Prototipo Operacional – beta.
 Caso del Negocio Actualizado.
Fase transición
Los resultados de la fase de transición son:
 Prototipo Operacional.
 Documento de despliegue.
 Plan de pruebas.
 Documentos Legales.
 Caso del Negocio Completo
 Línea de Base del Producto completa y corregida que incluye todos los
modelos del sistema.
 Descripción de la Arquitectura completa y corregida.
 Las iteraciones de esta fase irán dirigidas normalmente a conseguir una
nueva versión.
Inicio
 Documento Visión
 Diagramas de caso de uso
 Especificación de Requisitos
 Diagrama de Requisitos
Elaboració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
 Modelo de dominio
Vista física
 Mapa de comportamiento a nivel de hardware.

 Diseño y desarrollo de casos de uso, o flujos de casos de uso arquitectónicos
 Pruebas de los casos de uso desarrollados, que demuestran que la arquitectura
documentada responde adecuadamente a requerimientos funcionales y no funcionales.
Construcción
 Especificación de requisitos faltantes
 Diseño y desarrollo de casos de uso y/o flujos de acuerdo con la planeación iterativa
 Pruebas de los casos de uso desarrollados, y pruebas de regresión según sea el caso
Transición
 Pruebas finales de aceptación
 Puesta en producción
 Estabilización
Roles de rup
Cada fase en RUP puede descomponerse en iteraciones. Una iteración es un ciclo

de desarrollo completo dando
Como resultado una entrega de producto ejecutable (interna o externa)
El proceso define una serie de roles:
Los roles se distribuyen entre los miembros del proyecto y que definen las tareas
de cada uno y el resultado. Algunos de esos roles son:
Analistas:
 Analista de procesos de negocio.

 Diseñador del negocio.
 Analista de sistema.
 Especificador de requisitos.
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 proyecto
 Jefe de control de cambios.
 Jefe de configuración.
 Jefe de pruebas
 Jefe de despliegue
 Ingeniero de procesos
 Revisor de gestión del proyecto
 Gestor de pruebas.
Apoyo:
 Documentador técnico
 Administrador de sistema
 Especialista en herramientas
 Desarrollador de cursos
 Artista gráfico
Especialista en pruebas:
 Especialista en Pruebas (tester)

 Analista de pruebas
 Diseñador de pruebas
Otros roles:
 Stakeholders.
 Revisor
 Coordinación de revisiones
 Revisor técnico
 Cualquier rol

Artefactos Sugeridos Por El Jurado Evaluador

Cargado por

Copyright:

Formatos disponibles

Artefactos Sugeridos Por El Jurado Evaluador

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Artefactos Sugeridos Por El Jurado Evaluador

Cargado por

Copyright:

Formatos disponibles

Artefactos Sugeridos por el Jurado Evaluador:

FLUJO DE CONTROL DE PROCESOS

El modelado del negocio se basa en dos diagramas principales, el modelo de

Requisitos: Esta disciplina tiene el propósito de: Establecer y mantener un

Análisis y Diseño: Transformar los requerimientos a diseños del sistema,

Implementación: El propósito de la implementación es: Definir la organización del

Pruebas: Actúa como un proveedor de servicios a las otras disciplinas en muchos

Despliegues: Esta disciplina describe las actividades asociadas con el

FLUJO DE CONTROL DE APOYO

Configuración y Manejo de Cambios: Consiste en controlar los cambios y

Incluye: Identificar los elementos configurables. Restringir los cambios en los

Administración del Proyecto: El propósito de la Administración de Proyectos es:

Entorno: Se enfoca en las actividades necesarias para configurar el proceso al

Los artefactos o resultados de esta fase deben ser:

 Un modelo de Casos de Uso completo al menos hasta el 80%:

Los artefactos o resultados de esta fase deben ser:

 Modelos Completos (Casos de Uso, Análisis, Diseño, Despliegue e

 Mapa de comportamiento a nivel de hardware.

Cada fase en RUP puede descomponerse en iteraciones. Una iteración es un ciclo

Como resultado una entrega de producto ejecutable (interna o externa)

El proceso define una serie de roles:

 Analista de procesos de negocio.

 Especialista en Pruebas (tester)

También podría gustarte