Práctica de Laboratorio #1

Materia: Análisis y Diseño de Sistemas

Tema del temario: 1.3.3 Metodologías orientadas a objetos
1.3.3a Object Modeling Technique
1.3.3b Unified Process (UP)
1.3.3c Rational Unified Process (RUP)
Apellido paterno: Balderas
Apellido materno: Aguilera
Nombre(s): Brenda Akari
Boleta del estudiante: 2021630190
Firma del estudiante:
Apellido paterno: Ulloa
Apellido materno: Rodríguez
Nombre(s): Carlos Ignacio
Boleta del estudiante: 2019602047
Firma del estudiante:
Apellido paterno: Luciano
Apellido materno: Hernández
Nombre(s): Jonathan
Boleta del estudiante: 2021630373
Firma del estudiante:
Grupo: 5CM1

Descripción de la práctica:
El estudiante hará una investigación de las metodologías orientadas a objetos: 1.3.3a Object Modeling
Technique, 1.3.3b Unified Process (UP), 1.3.3c Rational Unified Process (RUP), llenando los
siguientes puntos para cada una de las metodologías:

1.3.1 Object Modeling Technique

Descripción concreta de la metodología:

es una metodología para el análisis y diseño de sistemas orientada a objetos. Fue desarrollada por
James Rumbaugh y su equipo en los años 90. La OMT se destaca por ser una de las primeras
metodologías que enfatizó en el modelado orientado a objetos, y ha influenciado el desarrollo de otras
metodologías posteriores, incluyendo el Proceso Unificado (UP) y el Proceso Unificado Racional
(RUP).
Ventajas de la metodología:
 Enfoque Integral: Proporciona un marco completo que abarca análisis, diseño e
implementación.
 Claridad Visual: Facilita la comprensión del sistema a través de diagramas claros y
comprensibles.
 Reutilización de Software: Promueve la identificación de objetos reutilizables, mejorando la
eficiencia.
 Flexibilidad: Se adapta a proyectos de distintos tamaños y complejidades.
 Fomenta el Paradigma Orientado a Objetos: Ayuda a los equipos a implementar principios de
orientación a objetos eficazmente.
Desventajas de la metodología:
  Curva de Aprendizaje: Requiere familiarización con el paradigma orientado a objetos y
técnicas de modelado.
 Complejidad en Proyectos Grandes: Puede volverse compleja en proyectos de gran escala.
 Percepción de Desactualización: Metodologías ágiles y enfoques más recientes pueden parecer
más adaptativos.
 Menor Enfoque en la Interacción con el Usuario: Principalmente centrada en la estructura y
comportamiento interno del sistema.
 Integración con Nuevas Tecnologías: Puede requerir esfuerzos adicionales para adaptarse a
innovaciones tecnológicas.
Diagrama del Ciclo de vida de la metodología:
Para crear un diagrama que represente el ciclo de vida de la Técnica de Modelado de Objetos (OMT),
consideraremos las tres fases principales de esta metodología: análisis, diseño e implementación. El
diagrama ilustrará cómo estas fases se conectan en un flujo secuencial, destacando también los
principales componentes y actividades dentro de cada una.
Descripción del Ciclo de vida de la metodología:
1. Fase de Análisis: Identificación de objetos, construcción de modelos de objetos y definición de
dinámicas y estructuras de datos.
2. Fase de Diseño: Detallamiento de la arquitectura del sistema, diseño de objetos, y elaboración
de modelos dinámicos y funcionales.
3. Fase de Implementación: Codificación basada en el diseño, integración del sistema y pruebas.

Principios de la metodología:
 Orientación a Objetos: La OMT promueve el uso de objetos como la abstracción principal para
modelar tanto la estructura como el comportamiento del sistema. Esto implica encapsular datos
 y comportamientos relacionados dentro de objetos y utilizar conceptos como la herencia y el
polimorfismo para promover la reutilización y la flexibilidad.
 Modelado: La metodología enfatiza la importancia del modelado como herramienta para
comprender, diseñar y comunicar la estructura y el comportamiento del sistema. Los modelos
se utilizan para representar diferentes aspectos del sistema en varias etapas del desarrollo.
 Descomposición: La OMT sugiere descomponer un sistema complejo en componentes más
pequeños y manejables. Esto facilita el manejo de la complejidad al permitir que los
desarrolladores se concentren en partes individuales del sistema a la vez.
 Iteración: Aunque la OMT se presenta como un proceso secuencial, reconoce la importancia de
la iteración. Se espera que los desarrolladores revisen y refinan los modelos a medida que
avanzan en el análisis y diseño, adaptándose a nuevos hallazgos y requisitos.
 Integración: La metodología aboga por la integración de diferentes modelos para proporcionar
una vista completa del sistema. Esto incluye la integración de modelos de datos, modelos de
comportamiento y modelos de procesos para asegurar que todas las facetas del sistema estén
adecuadamente representadas y alineadas
 Abstracción: La OMT utiliza la abstracción para gestionar la complejidad, permitiendo a los
diseñadores concentrarse en los aspectos más relevantes de un problema a la vez. Esto se logra
identificando y modelando clases y objetos que representan entidades del mundo real o
conceptos relevantes para el sistema.
 Reutilización: Uno de los objetivos fundamentales de la OMT es promover la reutilización de
componentes de software. Al modelar el sistema de manera que los objetos y clases sean
reutilizables, se puede mejorar la eficiencia del desarrollo y el mantenimiento del sistema.
Roles en la metodología:
 Analista de Sistemas: Responsable de la fase de análisis, identificando los requisitos del
sistema, los objetos y sus interacciones. Este rol requiere una comprensión profunda del
dominio del problema y habilidades para modelar los requisitos de manera abstracta.
 Diseñador de Sistemas: Se encarga del diseño del sistema basándose en los requisitos
identificados. Esto incluye la arquitectura del sistema, el diseño de clases y objetos, y la
definición de las interacciones entre objetos. Los diseñadores deben tener habilidades técnicas
sólidas y una buena comprensión de los principios de diseño orientado a objetos.
 Desarrollador o Programador: Implementa el sistema basándose en el modelo de diseño,
escribiendo el código en el lenguaje de programación elegido. Los desarrolladores deben tener
habilidades técnicas fuertes en programación y comprender los modelos proporcionados por
los analistas y diseñadores.
 Tester o Analista de Calidad: Se encarga de verificar y validar que el sistema implementado
cumpla con los requisitos especificados. Esto incluye la realización de pruebas unitarias, de
integración y de sistema para identificar y corregir errores.
 Gestor de Proyecto: Supervisa el progreso del proyecto, asegurando que se cumplan los plazos,
presupuestos y objetivos. El gestor de proyecto coordina las actividades entre los diferentes
roles y comunica el progreso a los stakeholders.
 Usuario Final: Aunque no participa directamente en el desarrollo, el feedback de los usuarios
finales es crucial para el análisis de requisitos y las pruebas de aceptación. Su participación
ayuda a asegurar que el sistema cumpla con las necesidades reales de los usuarios.
Descripción de las Fases de la metodología:
1. Fase de Análisis
2. Fase de Diseño
3. Fase de Implementación

Fase de la metodología Tareas de la Fase de la Entregables de la Fase de la

metodología metodología
Análisis  Modelo de Objetos:  Modelo de Objetos: Un
Describe la estructura diagrama que muestra
estática del sistema las clases (tipos de
mediante clases y objetos) del sistema, sus
objetos, junto con sus atributos, operaciones
relaciones. (funciones o métodos) y
 Modelo Dinámico: las relaciones entre
Captura el ellas.
comportamiento y las  Modelo Dinámico:
interacciones de los Compuesto por
objetos a lo largo del diagramas de estado que
tiempo, usualmente a describen cómo
través de diagramas de cambian los objetos en
estado y diagramas de el tiempo y diagramas
secuencia. de secuencia o de
 Modelo Funcional: Se colaboración que
centra en los aspectos muestran las
funcionales del sistema, interacciones entre
describiendo los objetos para llevar a
procesos que se llevan a cabo las operaciones del
cabo, sus entradas y sistema.
salidas, y cómo se  Modelo Funcional:
transforman los datos. Incluye diagramas de
flujo de datos que
representan los procesos
del sistema, cómo los
datos fluyen a través de
estos procesos y cómo
se transforman.
Diseño  Diseño de la  Diseño de la
Arquitectura: Define la Arquitectura del
estructura general del Sistema: Un conjunto de
sistema, incluyendo la documentos y
división en sub-sistemas diagramas que describen
o módulos y la la estructura global del
asignación de clases y sistema, incluyendo la
objetos a estos descomposición en
componentes. módulos o componentes
 Diseño de Clases y y sus interacciones.
Objetos: Detalla las  Diseño Detallado de
clases identificadas Clases y Objetos:
durante el análisis, Especificaciones
especificando sus detalladas de cada clase
atributos, operaciones y y objeto identificado
la implementación de durante el análisis,
relaciones como la incluyendo la
herencia. implementación
 Diseño de Interfaz: detallada de sus
Especifica las interfaces atributos, operaciones y
de usuario y de sistema, relaciones.
 definiendo cómo los  Diseño de Interfaz de
usuarios y otros Usuario: Prototipos y
sistemas interactúan con especificaciones de las
el sistema. interfaces de usuario,
 Diseño de Datos y definiendo cómo los
Almacenamiento: usuarios interactuarán
Planifica la gestión de la con el sistema.
persistencia de datos,  Diseño de la Estructura
incluyendo esquemas de de Datos y
bases de datos y Almacenamiento:
mecanismos de Definiciones de
almacenamiento. esquemas de base de
datos, archivos y otros
mecanismos de
almacenamiento
necesarios para la
persistencia de datos.
Implementación  Codificación:  Código Fuente: El
Implementación del conjunto de archivos de
diseño en código, código fuente escritos
utilizando las en el lenguaje de
convenciones y programación elegido,
estructuras definidas. implementando las
 Integración: especificaciones del
Combinación de diseño.
diferentes partes o  Documentación del
módulos del sistema y Código: Comentarios
asegurar que funcionen dentro del código y
juntas como un todo documentación externa
coherente. que describe la
 Pruebas: Verificación de estructura del código,
la funcionalidad, las clases, métodos y su
rendimiento y fiabilidad propósito.
del sistema a través de  Sistema Integrado: Una
pruebas unitarias, de versión del sistema
integración, de sistema donde todos los
y de aceptación. componentes y módulos
han sido combinados y
funcionan juntos.
 Reportes de Pruebas:
Documentación de las
pruebas realizadas,
incluyendo pruebas
unitarias, de integración
y de sistema, junto con
los resultados y las
acciones correctivas
tomadas.
 Manual de Usuario y
Documentación
 Técnica: Guías y
manuales que
proporcionan
instrucciones sobre
cómo usar el sistema y
detalles técnicos para
soporte y
mantenimiento.

1.3.2 Unified Process (UP)

Descripción concreta de la metodología:

Es una metodología de desarrollo de software que se caracteriza por ser iterativa, incremental y
centrada en la arquitectura. Diseñada para guiar a los equipos a través del desarrollo de software, UP
integra prácticas de modelado y está fuertemente influenciada por el paradigma de programación
orientada a objetos. Su objetivo es facilitar la producción de software de alta calidad que cumpla con
los requisitos del usuario final de manera eficiente y predecible.
Ventajas de la metodología:
 Código Fuente: El conjunto de archivos de código fuente escritos en el lenguaje de
programación elegido, implementando las especificaciones del diseño.
 Documentación del Código: Comentarios dentro del código y documentación externa que
describe la estructura del código, las clases, métodos y su propósito.
 Sistema Integrado: Una versión del sistema donde todos los componentes y módulos han sido
combinados y funcionan juntos.
 Reportes de Pruebas: Documentación de las pruebas realizadas, incluyendo pruebas unitarias,
de integración y de sistema, junto con los resultados y las acciones correctivas tomadas.
 Manual de Usuario y Documentación Técnica: Guías y manuales que proporcionan
instrucciones sobre cómo usar el sistema y detalles técnicos para soporte y mantenimiento.
Desventajas de la metodología:
 Código Fuente: El conjunto de archivos de código fuente escritos en el lenguaje de
programación elegido, implementando las especificaciones del diseño.
 Documentación del Código: Comentarios dentro del código y documentación externa que
describe la estructura del código, las clases, métodos y su propósito.
 Sistema Integrado: Una versión del sistema donde todos los componentes y módulos han sido
combinados y funcionan juntos.
 Reportes de Pruebas: Documentación de las pruebas realizadas, incluyendo pruebas unitarias,
de integración y de sistema, junto con los resultados y las acciones correctivas tomadas.
 Manual de Usuario y Documentación Técnica: Guías y manuales que proporcionan
instrucciones sobre cómo usar el sistema y detalles técnicos para soporte y mantenimiento.
Diagrama del Ciclo de vida de la metodología:
 Inicio: Definir el alcance del proyecto.
 Elaboración: Desarrollo del plan de proyecto y especificación de requisitos.
 Construcción: Desarrollo e implementación del producto.
 Transición: Entrega del sistema al usuario final y resolución de problemas post-lanzamiento.
Descripción del Ciclo de vida de la metodología:
 Inicio: Esta fase se centra en definir el alcance del proyecto, el caso de negocio, y realizar una
evaluación inicial de los riesgos. Es el momento de establecer las bases del proyecto y obtener
la aprobación para proceder.
 Elaboración: Durante esta fase, se profundiza en el análisis de los requisitos, se define la
arquitectura base del sistema y se mitigan los riesgos más significativos. Se desarrollan
 versiones preliminares del sistema para validar la arquitectura y el entendimiento de los
requisitos.
 Construcción: Aquí es donde se desarrolla el producto completo, se completa el diseño, se
implementa el código y se realizan pruebas para asegurar la calidad. Esta fase se caracteriza
por la producción de versiones sucesivas del sistema, cada una más completa que la anterior.
 Transición: En esta última fase, el sistema se despliega en el entorno del usuario final. Se
realizan ajustes basados en la retroalimentación de los usuarios, se asegura que todos los
stakeholders estén satisfechos con el producto final y se lleva a cabo la formación necesaria
para los usuarios y el mantenimiento.

Principios de la metodología:
 Desarrollo iterativo e incremental: El UP enfatiza la importancia de desarrollar software de
manera iterativa, permitiendo revisiones y mejoras a través de sucesivas versiones
incrementales. Esto ayuda a mitigar riesgos desde temprano y asegura que el producto final
cumpla con las necesidades del usuario.
 Uso de casos para capturar requisitos: Los casos de uso son una herramienta central en el UP
para la captura de requisitos funcionales. Ayudan a entender cómo interactuarán los usuarios
con el sistema y sirven como base para el diseño, la implementación y las pruebas.
 Enfoque centrado en la arquitectura: El UP sostiene que es crítico establecer una arquitectura
de sistema robusta y flexible desde las etapas tempranas del desarrollo. Esto asegura que el
sistema pueda manejar cambios y requisitos futuros sin necesidad de rediseños fundamentales.
  Gestión de riesgos proactiva: La identificación y el manejo de riesgos es una actividad
continua en el UP. Se enfatiza la importancia de reconocer, priorizar y mitigar riesgos desde el
inicio del proyecto para evitar sorpresas desagradables más adelante.
 Modelado visual: El UP utiliza el modelado visual, incluyendo diagramas UML (Unified
Modeling Language), como una herramienta clave para la especificación, diseño y
documentación del software. Esto facilita la comunicación entre los miembros del equipo y los
stakeholders, y ayuda a visualizar la estructura y el comportamiento del sistema.
 Calidad desde el principio: El UP promueve la integración de actividades de aseguramiento de
la calidad (como revisiones y pruebas) desde las primeras fases del desarrollo. Esto ayuda a
detectar y corregir problemas tempranamente, mejorando la calidad del producto final.
 Adaptabilidad: Aunque el UP proporciona una estructura para el desarrollo de software,
también reconoce la necesidad de adaptabilidad. Los proyectos pueden personalizar el proceso
según sus necesidades específicas, seleccionando los elementos del UP que mejor se ajusten a
sus requerimientos.
Roles en la metodología:
 Analista de Negocios: Identifica las necesidades del negocio y ayuda a definir el caso de
negocio para el sistema. Trabaja de cerca con los stakeholders para entender sus requisitos y
prioridades.
 Arquitecto de Software: Define la arquitectura del sistema, asegurando que sea robusta,
escalable y mantenible. Este rol es crucial para establecer el esqueleto técnico sobre el cual se
construirá el sistema.
 Desarrollador: Implementa el sistema basándose en los diseños y arquitectura definidos. Los
desarrolladores escriben el código y realizan pruebas unitarias para asegurar que las
funcionalidades cumplan con los requisitos.

 Diseñador: Se encarga de diseñar la solución, traduciendo los requisitos y la arquitectura en un

diseño detallado que los desarrolladores puedan implementar.
 Gestor de Proyecto: Planifica y supervisa el proyecto, asegurando que se cumplan los plazos,
presupuestos y objetivos. Este rol implica la gestión de riesgos, recursos y comunicación entre
el equipo y los stakeholders.
 Tester: Se encarga de la calidad del software, planificando y ejecutando pruebas para
identificar y documentar defectos. Los testers trabajan para asegurar que el sistema cumpla con
los requisitos y sea de alta calidad.
 Gestor de Configuración: Gestiona las versiones del software y controla los cambios en el
código fuente y la documentación, asegurando que el entorno de desarrollo sea estable y
rastreable.
 Especialista en Interfaz de Usuario: Diseña y evalúa las interfaces de usuario, asegurando que
sean intuitivas, accesibles y estéticamente agradables. Este rol es crucial para la experiencia del
usuario final.
 Analista de Sistemas: Ayuda a traducir los requisitos del negocio en soluciones técnicas y en
casos de uso que guiarán el desarrollo. Este rol sirve como un puente entre el equipo de
desarrollo y los stakeholders no técnicos.
Descripción de las Fases de la metodología:
1. Inicio
2. Elaboración
3. Construcción
4. Transición

Fase de la metodología Tareas de la Fase de la Entregables de la Fase de la

metodología metodología
Inicio  Actividades principales:  Documento de Visión:
 Captura de requisitos Define el alcance del
iniciales. proyecto, incluyendo las
 Definición de los casos necesidades del
de uso más negocio, los
significativos. stakeholders principales,
 Establecimiento de la y una visión general de
viabilidad técnica y las soluciones
financiera. propuestas.
 Estimación Inicial y
Planificación
Preliminar: Un plan
preliminar que incluye
estimaciones de costos,
recursos y tiempos.
 Evaluación de Riesgos
Inicial: Un análisis de
los riesgos potenciales
que podrían afectar el
proyecto.
 Casos de Uso Iniciales:
Un conjunto inicial de
casos de uso o
escenarios que
describen las
interacciones
principales entre los
usuarios y el sistema.
 Modelo de Dominio
Inicial: Una
representación
preliminar de los
conceptos principales y
las relaciones dentro del
área de problema..
Elaboración  Creación de un modelo  Plan de Proyecto
de arquitectura refinado. Refinado: Un plan
 Implementación de detallado que cubre el
algunos componentes alcance del proyecto,
del sistema o prototipos fases, iteraciones,
para validar la recursos y cronograma.
arquitectura.  Modelo de Arquitectura:
 Definición detallada de Documentación de la
los casos de uso y arquitectura del sistema,
requisitos. incluyendo diagramas
 Evaluación y mitigación de arquitectura y
de riesgos. decisiones de diseño
clave.
 Prototipo de
Arquitectura: Un
 prototipo funcional que
valida las decisiones
arquitectónicas.
 Modelo de Casos de
Uso Detallado: Una
elaboración detallada de
los casos de uso,
especificando los flujos
de trabajo del sistema.
 Especificación de
Requisitos de Software
(SRS): Documentación
completa de los
requisitos del sistema.
 Plan de Gestión de
Riesgos: Actualización
del análisis de riesgos
con estrategias de
mitigación para riesgos
identificados.
Construcción  Codificación y  Sistema Funcional: El
desarrollo del software. software desarrollado
 Realización de pruebas completamente, listo
unitarias, de integración para ser probado y
y de sistema. desplegado.
 Preparación de  Manual del Usuario y
manuales de usuario y Documentación: Guías
documentación. y manuales para los
usuarios finales y
administradores del
sistema.
 Resultados de las
Pruebas: Informes
detallados de las
pruebas realizadas,
incluyendo pruebas
unitarias, de integración
y de sistema.
 Plan de Despliegue:
Estrategias y
procedimientos para la
implementación del
sistema en el entorno de
producción.
Transición  Despliegue del software  Sistema Final: La
en el entorno de versión final del
producción. software, después de
 Formación y soporte a realizar todos los ajustes
los usuarios. necesarios.
 Realización de ajustes  Informe de Despliegue:
 basados en la Documentación sobre el
retroalimentación. proceso de despliegue,
 Cierre formal del incluidas las lecciones
proyecto. aprendidas y los
problemas encontrados.
 Formación del Usuario
Final: Materiales y
documentación de
formación para los
usuarios.
 Informe Final del
Proyecto: Un resumen
de todo el proyecto,
incluyendo el
rendimiento frente al
plan original, lecciones
aprendidas, y
recomendaciones para
proyectos futuros.
 Solicitud de Cambios y
Mantenimiento:
Documentación de
cualquier solicitud de
cambio pendiente y plan
de mantenimiento para
el sistema.
 Es importante destacar
que estos entregables
pueden variar
dependiendo de las
necesidades específicas
del proyecto y la
organización. El UP es
adaptable y permite
personalizar la
metodología para
satisfacer los requisitos
particulares del
proyecto.

1.3.3 Rational Unified Process (RUP)

Descripción concreta de la metodología:

Es una metodología de desarrollo de software que proporciona un enfoque disciplinado para asignar
tareas y responsabilidades dentro de una organización de desarrollo. Su objetivo principal es asegurar
la producción de software de alta calidad que cumpla con las necesidades de los usuarios finales dentro
de un cronograma y presupuesto predecibles. RUP es una instancia específica del Proceso Unificado
(UP) y se caracteriza por ser iterativo e incremental, centrado en la arquitectura, y orientado a mitigar
riesgos desde las fases tempranas del desarrollo.
Ventajas de la metodología:
  Enfoque Iterativo e Incremental: RUP permite el desarrollo de software en fases iterativas, lo
que facilita la gestión de cambios y la adaptación a nuevos requisitos, mejorando así la
capacidad de respuesta ante la evolución de las necesidades del proyecto.
 Mitigación de Riesgos: Al identificar y tratar los riesgos desde las fases iniciales, RUP ayuda a
prevenir problemas significativos más adelante en el proyecto, reduciendo la probabilidad de
retrasos o fallos.
 Claridad en Roles y Responsabilidades: RUP define claramente los roles dentro del equipo de
desarrollo, asegurando que todos los aspectos del proyecto sean cubiertos por expertos
adecuados, lo que mejora la comunicación y la eficiencia del equipo.
 Enfoque en la Calidad: La metodología promueve la realización de pruebas desde las primeras
etapas del desarrollo, lo que contribuye a la detección temprana de errores y a la mejora
continua de la calidad del software.
 Documentación Detallada: RUP enfatiza la importancia de la documentación en cada fase del
desarrollo, lo que facilita la comprensión del proyecto y la transferencia de conocimientos
dentro del equipo y hacia los stakeholders.
Desventajas de la metodología:
 Complejidad y Sobrecarga de Proceso: La estructura detallada y la documentación requerida
pueden resultar en una sobrecarga de procesos, especialmente en proyectos pequeños o ágiles,
lo que puede llevar a retrasos y aumento en los costos de desarrollo.
 Curva de Aprendizaje: Para equipos no familiarizados con RUP, la curva de aprendizaje puede
ser significativa debido a su complejidad y la amplia gama de artefactos y prácticas que deben
ser comprendidos y aplicados correctamente.
 Requiere Disciplina y Compromiso: La efectividad de RUP depende en gran medida de la
disciplina del equipo para seguir los procesos establecidos y mantener actualizadas las
documentaciones, lo cual puede ser un desafío en entornos menos estructurados.
 Posible Rigidez: Aunque RUP es adaptable, su aplicación en entornos muy dinámicos o en
proyectos que requieren una gran flexibilidad puede ser complicada, lo que limita su utilidad
en ciertos tipos de proyectos ágiles.
 Costo de Implementación: La implementación de RUP puede requerir una inversión inicial
significativa en términos de tiempo y recursos, tanto para la formación del equipo como para la
adaptación de los procesos a las necesidades específicas del proyecto.

Diagrama del Ciclo de vida de la metodología:

1. Cuatro fases principales: Inicio, Elaboración, Construcción y Transición.
2. Iterativo Incremental
3. Actividades clave
4. Flujo entre fases
Descripción del Ciclo de vida de la metodología:
1. Cuatro Fases Principales: El diagrama destaca las cuatro fases principales del ciclo de vida de
RUP:
 Inicio (Inception): Se enfoca en definir el alcance del proyecto, los objetivos de negocio, los
requisitos iniciales, y realizar una evaluación preliminar de riesgos.
 Elaboración (Elaboration): Profundiza en el análisis de requisitos, desarrolla la arquitectura del
sistema, y aborda los riesgos más significativos, asegurando que el proyecto está bien definido
antes de proceder a la construcción.
 Construcción (Construction): Se centra en el desarrollo del producto completo, incluyendo la
codificación, el testing y la preparación para el despliegue.
 Transición (Transition): Implica la entrega del sistema a los usuarios finales, con actividades
como la capacitación de usuarios, el despliegue del sistema en el entorno de producción y la
realización de ajustes basados en la retroalimentación.
 2. Iterativo e Incremental: El diagrama muestra claramente que RUP es iterativo e incremental,
con iteraciones dentro de cada fase. Cada iteración incluye actividades de especificación,
diseño, implementación y pruebas, lo que permite refinamientos sucesivos del producto.
3. Actividades Clave: Para cada fase, el diagrama incluye símbolos y notas que indican las
actividades clave, tales como:
 Definición del alcance y evaluación de riesgos en la fase de Inicio.
 Análisis detallado de requisitos y diseño de la arquitectura en la fase de Elaboración.
 Desarrollo y pruebas del software en la fase de Construcción.
 Despliegue y soporte en la fase de Transición.
4. Flujo entre Fases: Hay flechas que conectan las fases, ilustrando el flujo secuencial a través del
ciclo de vida del proyecto. Sin embargo, estas flechas también permiten cierto retorno a fases
anteriores, reflejando la flexibilidad para revisar y ajustar el proyecto según sea necesario.

5. Símbolos Visuales: El diagrama utiliza símbolos visuales, como engranajes para el desarrollo,
marcas de verificación para las pruebas y un sombrero de graduación para la formación, para
representar las diferentes actividades y entregables en cada fase.

Principios de la metodología:
 Desarrollo Iterativo e Incremental: RUP promueve un enfoque iterativo para el desarrollo de
software, dividiendo el proyecto en ciclos más pequeños que permiten al equipo abordar los
cambios y ajustar el rumbo basándose en la retroalimentación y los aprendizajes obtenidos.
Esto ayuda a mitigar los riesgos tempranamente y mejora la adaptabilidad del proyecto.
  Centrado en la Arquitectura: La definición y el refinamiento de una arquitectura robusta desde
las etapas iniciales del proyecto es fundamental en RUP. Esto asegura que el sistema sea
escalable, reutilizable y fácil de mantener, sirviendo como una columna vertebral sobre la cual
se construye el proyecto.
 Enfoque en los Requisitos del Usuario: RUP enfatiza la importancia de comprender y
documentar claramente los requisitos del usuario desde el principio. Utilizando técnicas como
los casos de uso, RUP facilita la comunicación entre el equipo de desarrollo y los stakeholders,
asegurando que el producto final cumpla con las expectativas del usuario.
 Uso de Modelos Visuales: La modelación visual juega un rol crucial en RUP, proporcionando
una forma de capturar, comunicar y analizar requisitos, diseños y otros aspectos importantes
del sistema. Esto incluye el uso de UML (Lenguaje Unificado de Modelado) para representar
estructuras y comportamientos de manera estándar.
 Verificación de la Calidad: RUP integra actividades de verificación y validación en cada
iteración, incluyendo pruebas, revisiones de diseño y evaluaciones de rendimiento. Esto
asegura la identificación y corrección temprana de defectos, mejorando la calidad del producto
final.
 Gestión de Cambios: Reconociendo que el cambio es una constante en el desarrollo de
software, RUP incorpora prácticas de gestión de cambios para controlar y gestionar las
modificaciones en los requisitos, el diseño y el código de manera eficiente.
 Evaluación Continua de Riesgos: La identificación y el manejo de riesgos es un proceso
continuo en RUP. El enfoque proactivo hacia la gestión de riesgos permite al equipo anticipar
y mitigar problemas potenciales antes de que se conviertan en obstáculos críticos para el
proyecto.
 Adaptabilidad: Aunque RUP proporciona un marco estructurado, también es adaptable a las
necesidades específicas del proyecto y de la organización. Esto permite a los equipos ajustar el
proceso, las técnicas y las herramientas según las particularidades del proyecto y los objetivos
del negocio.
Roles en la metodología:
 Analista de Negocios: Se encarga de identificar las necesidades del negocio y establecer los
requisitos del sistema desde una perspectiva empresarial. Este rol es crucial para asegurar que
el sistema final cumpla con los objetivos y expectativas del negocio.
 Arquitecto del Sistema: Define la arquitectura del sistema, asegurando que sea sólida, escalable
y sostenible. El arquitecto toma decisiones clave sobre la estructura técnica y asegura que el
diseño del sistema soporte los requisitos del negocio.
 Desarrollador: Implementa el sistema basándose en el diseño y la arquitectura definidos. Los
desarrolladores escriben el código, integran los componentes del sistema y realizan pruebas
unitarias.
 Diseñador: Traduce los requisitos y la arquitectura del sistema en un diseño detallado. Este rol
se enfoca en cómo el sistema será construido, incluyendo la selección de patrones de diseño y
la especificación de los componentes y sus interfaces.
 Gestor de Proyecto: Es responsable de la planificación, ejecución y cierre del proyecto. El
gestor de proyecto supervisa el cronograma, el presupuesto, los recursos y los riesgos,
asegurando que el proyecto cumpla con sus objetivos.
 Tester: Diseña y ejecuta pruebas para asegurar que el sistema cumpla con los requisitos y
funcione correctamente. Este rol es fundamental para identificar y solucionar problemas antes
de que el sistema sea desplegado.
 Gestor de Configuración: Maneja las versiones del software y controla los cambios en el
código y la documentación. Este rol es vital para mantener la integridad del sistema a lo largo
del desarrollo.
  Analista de Requisitos: Se centra en recolectar, analizar y especificar los requisitos del sistema.
Este rol asegura que los requisitos sean claros, completos y comprensibles para todos los
miembros del equipo.
 Especialista en Interfaz de Usuario: Diseña y evalúa las interfaces de usuario, asegurando que
sean intuitivas, accesibles y estéticamente agradables. Este rol contribuye a una experiencia de
usuario positiva.
 Integrador del Sistema: Se encarga de integrar los diferentes componentes del sistema y
asegurar que funcionen juntos como un todo coherente.
Descripción de las Fases de la metodología:
1. Inicio
2. Elaboración
3. Construcción
4. Transición

Fase de la metodología Tareas de la Fase de la Entregables de la Fase de la

metodología metodología
Inicio  Desarrollo de una visión  Documento de Visión:
inicial del proyecto. Define el alcance del
 Identificación de los proyecto, objetivos,
stakeholders clave y sus limitaciones, y el caso
necesidades. de negocio.
 Análisis preliminar de  Lista de Riesgos
riesgos. Iniciales: Identificación
 Estimación inicial de de riesgos potenciales al
costos y recursos. inicio del proyecto.
 Definición de un plan de  Caso de Negocio:
proyecto preliminar. Análisis de viabilidad
que incluye
estimaciones de costos y
beneficios.
 Plan de Proyecto Inicial:
Un plan preliminar que
esboza las fases y las
iteraciones del proyecto.
 Modelo de Casos de
Uso Inicial: Un
conjunto inicial de
requisitos del usuario
expresados como casos
de uso.
Elaboración  Desarrollo detallado de  Modelo de Casos de
casos de uso y Uso Refinado:
especificaciones de Desarrollo y
requisitos. refinamiento de los
 Diseño y validación de casos de uso.
la arquitectura del  Modelo de Dominio: Un
sistema. modelo que representa
 Resolución de los los conceptos
riesgos más principales del dominio
significativos. del problema.
  Planificación detallada  Plan de Proyecto
del proyecto y de las Detallado: Incluye un
iteraciones futuras. plan de iteraciones más
detallado y recursos
asignados.
 Especificación de
Arquitectura del
Software: Documento
que describe la
arquitectura del sistema,
incluyendo decisiones
técnicas clave y cómo el
sistema cumplirá con
los requisitos.
 Prototipo de la
Arquitectura: Una
implementación inicial
que valida las
decisiones
arquitectónicas.
 Informe de Evaluación
de Riesgos: Análisis
detallado de riesgos con
estrategias de
mitigación.
Construcción  Implementación de las  Sistema Implementado:
funcionalidades del El software desarrollado
sistema. completamente, listo
 Realización de pruebas para pruebas de
detalladas para asegurar aceptación.
la calidad.  Manual del Usuario y
 Preparación de Documentación del
manuales de usuario y Sistema: Guías para
documentación. usuarios finales y
 Finalización de la administradores del
preparación para el sistema.
despliegue.  Plan de Despliegue:
Estrategias y
procedimientos para
implementar el sistema
en el entorno del
usuario.
 Informe de Pruebas:
Documentación de las
pruebas realizadas,
incluyendo resultados y
problemas identificados.
Transición  Despliegue del sistema  Sistema Final: Versión
en el entorno de final del software, listo
producción. para ser entregado.
  Capacitación de los  Informe de Despliegue:
usuarios finales. Documentación sobre el
 Realización de pruebas proceso de despliegue y
beta para asegurar que cualquier problema
el sistema cumple con encontrado.
las necesidades del  Formación de Usuarios:
usuario. Materiales y sesiones de
 Resolución de formación para usuarios
problemas identificados finales.
durante el despliegue.  Informe de Cierre del
Proyecto: Un resumen
del proyecto,
incluyendo lecciones
aprendidas, evaluación
de cumplimiento de
objetivos y
recomendaciones para el
futuro.
 Solicitud de Cambios y
Mantenimiento Post-
Despliegue:
Documentación de
cualquier problema
pendiente y
planificación para el
mantenimiento futuro.

Conclusiones:
Las metodologías UP (Proceso Unificado), RUP (Proceso Unificado de Rational) y Object Modeling
Technique (OMT) representan enfoques estructurados para el desarrollo de sistemas de software, cada
uno con sus propias características, ventajas y aplicaciones ideales.

 Evolución de Metodologías: Las metodologías han evolucionado de enfoques más rígidos y

centrados en el modelado, como OMT, hacia enfoques iterativos e incrementales que pueden
adaptarse a las necesidades cambiantes del proyecto, como UP y RUP.
 Selección Basada en el Proyecto: La elección entre UP, RUP y OMT (o sus principios)
depende del tamaño del proyecto, la complejidad, los requisitos específicos de la industria y la
familiaridad del equipo de desarrollo con la metodología.
 Importancia del Modelado y la Planificación: A pesar de sus diferencias, todas estas
metodologías reconocen la importancia del modelado detallado y la planificación cuidadosa
para el éxito del desarrollo de software.
 Adaptabilidad y Evolución: La industria del software continúa evolucionando hacia enfoques
que equilibran la rigurosidad y la flexibilidad, adaptando prácticas como las de UP y RUP para
satisfacer las demandas de desarrollo rápido y ágil de hoy en día.

UP, RUP y OMT ofrecen marcos valiosos para entender y manejar el desarrollo de sistemas de
software, cada uno con sus propios puntos fuertes y consideraciones para su aplicación efectiva.

Nota: La práctica que hay que llenarla con los datos de los estudiantes, hay que anexar además el
documento llenado en formato Word (.doc/docx), y PDF (convertir a formato PDF la presente
práctica). La idea de la práctica es que el estudiante haga una investigación y llene cada punto en sus
propias palabras, no se permite hacer copiar y pegar (copy and paste), si es el caso hay que poner la
referencias correspondiente a textos e imágenes en donde corresponda.