Metodología de Desarrollo de

Sistemas.
UML

Docente: Ing. Rosa Almaraz

Contenido.

Introducción.
Metodología.
Explicación de las fases de la Metodología.
UML.
Proceso Unificado.

Docente: Ing. Rosa Almaraz

 Objetivo

Este tema tiene como objetivo, comenzar el aprendizaje de cómo realizar el análisis de un sistema,
además de la obtención y especificación de los requisitos del Sistema. Para ello, se estudiará UML y
las herramientas que se utilizan para la realización de esta etapa, utilizando una metodología.

Docente: Ing. Rosa Almaraz

 Introducción

Un proyecto de desarrollo de software no puede ser abordado de forma directa. Requiere de una
metodología, que nos permita definir los contenidos de cada fase para el desarrollo de un software y
como pasar de una etapa a otra. En este tema comenzamos el estudio de la metodología definida
por Craig Larman, unido al estudio de UML. Misma que establece una serie de actividades que
pueden desarrollarse en cada fase, las cuales pueden adaptarse a las condiciones del proyecto
software que se desea desarrollar.

Docente: Ing. Rosa Almaraz

 Metodología

Como ya estudiamos anteriormente, una metodología no es más que: Un conjunto de

Herramientas, modelos y Técnicas que permiten definir las fases de un proceso de
desarrollo y las reglas para pasar de una fase a otra.

Metodología de Craig Larman

Esta metodología, nace a partir del modelo de procesos descrito en RUP (Rational Unified Process).
Es un método de desarrollo de software iterativo, incremental y dirigido por casos de uso que
permite desarrollar completamente un sistema software partiendo de un prototipo funcional inicial
cuyas funcionalidades se van extendiendo hasta culminar con el desarrollo del sistema. (González,
2017)
La metodología RUP es un proceso muy abierto, adaptativo e incremental dirigido por casos de uso
(en función de las características del proyecto se podía utilizar un ciclo de vida u otro), en el cual se
pueden seguir muchos caminos distintos para desarrollar el software.

Actividades que define la Metodología

1. Planificación y Especificación de Requisitos.

2. Construcción.
3. Instalación.

Cada una de estas actividades, serán explicadas en los próximos temas a estudiar.

Docente: Ing. Rosa Almaraz

Ventajas del uso de esta metodología

✓ No define una metodología estricta

✓ Adopta un enfoque práctico
✓ Incluye los últimos avances en la ingeniería del software.
✓ Aporta soluciones a problemas que anteriores métodos no han podido solucionar.
✓ Modelo iterativo e incremental, es decir, el producto contempla una serie de
funcionalidades, para las cuales se realiza el proceso de desarrollo completo, que se irán
incrementando en sucesivas versiones o iteraciones.
✓ Las iteraciones son como mini proyectos, en cada una de ellas se repite un proceso de
trabajo similar, cada requisito se debe completar en una única iteración incluyendo pruebas
y documentación.
✓ En cada iteración se hace una entrega, a partir de los resultados obtenidos anteriormente, y
se añaden nuevos requisitos y/o se mejoran los que ya fueron completados

Descripción de las etapas de la metodología

1.- Planificación y Especificación de Requisitos

Consiste en realizar el análisis de los requisitos que presenta el usuario las necesidades que debe
satisfacer el producto que se quiere construir.

Pasos a seguir:
1. Definición del Plan Borrador.
2. Informe de Investigación Preliminar.
3. Definir los requisitos.
4. Registrar Términos en el Glosario.
5. Casos de Uso.
6. Arquitectura del Sistema.

Docente: Ing. Rosa Almaraz

2.- Construcción

✓ En esta fase, se construye el sistema.

✓ Etapas a seguir:
1.- Análisis.
2.- Diseño.
3.- Implementación.
4.- Pruebas.

✓ Actividades que se desarrollan

Definir casos de uso esenciales en formato expandido
Definir el Modelo conceptual y refinar el glosario
Definir los Diagramas de Secuencia.
Definir los contratos.
Definir los casos de uso reales.
Definir los diagramas de Colaboración.
Definir los diagramas de Interacción.
Definir el diagrama de Clases de Diseño.

3.- Instalación

En esta fase se instalará el sistema, el usuario dará el visto bueno y se comenzará una nueva
iteración del producto con las funciones añadidas por éste.

Docente: Ing. Rosa Almaraz

 UML, El Lenguaje Unificado de Modelado.

Por mucho tiempo se habló en la industria del software sobre la llamada crisis del software. Las
discusiones de la crisis se basaban a los siguientes aspectos:

1.- Muchos proyectos de software fallan en producir sistemas que cumplen con los requerimientos y
las necesidades de los usuarios.
2.- Los proyectos de desarrollo de software terminan excediendo los presupuestos y los horarios de
tiempo.
3.- Los sistemas se han vuelto cada vez más grandes y distribuidos a través de muchas
computadoras, utilizando la arquitectura Cliente/Servidor.
4.- La necesidad de integrar sistemas complejos en un ambiente distribuido requiere que los
sistemas tengan algunos modelos comunes.

El avance de la programación orientada a objetos, la programación visual y los ambientes de

desarrollo avanzados han ayudado a incrementar la productividad. El costo perpetuo de usar y
soportar muchos lenguajes de modelaje motivó a muchas compañías que producen o usan
tecnología orientada a objetos a endorsar y soportar el desarrollo del Lenguaje de Modelaje
Unificado.

Que es UML
UML es un lenguaje estándar que sirve para escribir los planos de software, con el mismo se puede,
visualizar, especificar construir y documentar todas las partes que componen un sistema con gran
cantidad de software.

El Lenguaje de Modelaje Unificado (el UML) ha sido un intento para resolver algunos de los
problemas descritos anteriormente.

UML es el estándar formal y puede ser también el estándar de facto para construir los modelos
utilizables:
• Seguros: Describen correctamente el sistema a ser construido.
• Consistentes: Las diferentes vistas no expresan cosas que estén en conflictos con otras.
• Fáciles de comunicar a otros.
• Fáciles de cambiar.

Docente: Ing. Rosa Almaraz

• Comprensibles: Tan simple como sea posible, pero no los más simples.

Sigue el enfoque iterativo e incremental, es decir, el producto contempla una serie de

funcionalidades, para las cuales se realiza el proceso de desarrollo completo, que se irán
incrementando en sucesivas versiones o iteraciones.

Surgimiento de UML
Oficialmente surge en Octubre de 1994 al unirse Rumbaugh y Booch en Rational.
Tuvo como objetivo crear un nuevo método, el "Método Unificado," para unir el método de Booch y
el método OMT.
Por el 1995, Ivar Jacobson responsable del método OOSE y Objectory, se unió, y UML fue
expandido para incorporar OOSE.
El trabajo se dirigió fundamentalmente a la creación de un lenguaje de modelaje estándar, que le
llamaron "Lenguaje de Modelaje Unificado.", que pudiera ser utilizado por todos.

Uso de UML
UML puede usarse para modelar desde sistemas de información hasta aplicaciones distribuidas
basadas en WEB, pasando por sistemas empotrados de tiempo real.

Características de UML
Es un lenguaje, porque proporciona un vocabulario y las reglas para utilizarlo, por lo que es sólo una
parte de un método de desarrollo de software.
Es independiente del proceso, aunque para que sea óptimo debe usarse en un proceso dirigido por
casos de uso, centrado en la arquitectura, iterativo e incremental.
Es un lenguaje de modelado lo que significa que el vocabulario y las reglas se utilizan para la
representación conceptual y física del sistema.
Es un lenguaje que nos ayuda a interpretar grandes sistemas, mediante gráficos o mediante texto,
obteniendo modelos explícitos que ayudan a la comunicación durante el desarrollo, ya que, al ser
estándar, los modelos podrán ser interpretados por personas que no participaron en su diseño (e
incluso por herramientas) sin ninguna ambigüedad.
Sirve para especificar modelos concretos, no ambiguos y completos.
No es un lenguaje de programación. A pesar de ello, se puede conectar de manera directa a
lenguajes de programación, tales como Java, C++, o Visual Basic, esto permite lo que se denomina
ingeniería directa (obtener el código fuente partiendo de los modelos) también, es posible
reconstruir un modelo en UML partiendo de la implementación, o sea, ingeniería inversa.

Docente: Ing. Rosa Almaraz

Permite modelar actividades de planificación de proyectos y de sus versiones, expresar requisitos y
las pruebas sobre el sistema, representar todos sus detalles, así como la propia arquitectura.
Mediante estas capacidades se obtiene una documentación que es válida durante todo el ciclo de
vida de un proyecto.
Es un lenguaje estándar “abierto-cerrado”, es posible extender el lenguaje de manera controlada.

UML es un lenguaje para:

 Visualizar.
 Especificar.
 Construir.
 Documentar
Los artefactos de un sistema con gran cantidad de software.

Tiene la capacidad de que permite modelar actividades de planificación, especificar requisitos y las
pruebas del sistema, permite representar todos los detalles y la propia arquitectura. Obteniéndose
también, la documentación. (documentar).

Elementos Básicos de UML

Estructurales
Elementos: Abstracciones de Primer nivel De Comportamiento
De Agrupación
De Notación

1.- Los bloques de construcción De Dependencia

De Asociación
Relaciones: Unen los elementos entre si De Generalización
De Realización

Diagramas: Agrupaciones de Elementos

ELEMENTOS
Son los conceptos utilizados en los diagramas.
Un elemento del modelo es definido con una semántica, una definición formal del elemento
o el significado exacto de lo que representa en un enunciado no ambiguo.
Un elemento del modelo también tiene un elemento de vista correspondiente, el cual es una
representación gráfica del elemento o el símbolo gráfico utilizado para representar al
elemento en los diagramas.
Un elemento puede existir en varios tipos diferentes de diagramas, pero hay reglas para las
cuales los elementos pueden ser mostrados en cada tipo de diagrama.

Docente: Ing. Rosa Almaraz

 En la siguiente figura se muestran algunos ejemplos de elementos del modelo tales como
clase, objeto, estado, caso de uso, nodo, interfaz, paquete, nota, componente, actor, señal, y
estados inicial, final e historia.

RELACIONES:
Las relaciones son también elementos del modelo, y son utilizadas para interconectar
otros elementos del modelo unos a otros. Algunas relaciones diferentes son:
• Asociación: Conecta elementos y enlaza instancias.
• Generalización: También llamada herencia, esto significa que un elemento puede ser la
especialización de otro elemento.
• Dependencia: Muestra que un elemento depende de alguna manera de otro
elemento.
• Agregación: Es una forma de asociación en la cual un elemento contiene otros
elementos.
• Refinamiento: Es una forma de generalización entre un elemento a mayor nivel de detalle
que otro pero que representan lo mismo.

DIAGRAMAS

Que son los diagramas

1. Son gráficos que describen los contenidos de las vistas.
2. Es una parte específica de una vista.
3. Un diagrama puede ser parte de diferentes vistas.
4. Un diagrama en una vista debe ser suficientemente simple para poder ser comunicado.
5. Contiene símbolos gráficos que representan los elementos del modelo del sistema.

Tipos de Diagramas
❖ Diagramas de Casos de Uso:
❖ Son una vista gráfica de algunos o todos los actores, casos de usos, interacciones del
sistema.
❖ Tipos de Diagramas de Casos de Usos:
❖ Diagrama de CU Principal: Es la imagen de la frontera (actores principales)
y la funcionalidad principal del Sistema.
❖ Un diagrama que muestre todos los CU para un actor determinado.
❖ Un Diag. De CU que muestre todos los CU implementados en una iteración.
❖ Un diag. Que muestre un caso de uso y sus relaciones.

Docente: Ing. Rosa Almaraz

❖ Diagramas de Clases.
1. Es un tipo de modelo estático, Describe la estática del sistema.
2. Tiene similitud con el DER, Definen la base para otros diagramas (estados,
colaboración).
3. Son creados para mostrar una imagen o vista de las clases de una vista.
4. Usos típicos:
5. Vista de todas las clases de implementación de un paquete.
6. Vista de la estructura y comportamiento de una o más clases.
7. Vista de una jerarquía de herencia.
8. También pueden ser creados en los casos de uso, contienen una
vista de las clases que participan en el caso de uso.

❖ Diagramas de Objetos.
o Parecido al Diagrama de clases.
o Muestra una serie de objetos, en vez de clases actuales.
o Muestra las instancias de una clase.
o Utiliza la misma notación excepto que los nombres están subrayados, y son
mostradas todas las instancias en una notación.

❖ Diagramas de Secuencia.
1. Muestra una Colaboración Dinámica entre una serie de objetos.
2. Muestra una secuencia de mensajes enviados entre objetos, algo que
sucederá en un punto específico de la ejecución de un sistema.
3. Consiste en una serie de objetos.
4. Para enfatizar la secuencia.
❖ Diagramas de Actividades.
▪ Muestra el flujo secuencial de las actividades.
▪ Puede ser utilizado para describir las actividades realizadas en una
operación.
▪ Puede usarse para describir otros diagramas:
▪ Casos de usos.
▪ Iteración.
▪ Estados.

❖ Diagramas de Colaboración.
5. Muestra una Colaboración Dinámica.
6. Muestra los Objetos y sus Relaciones.

Docente: Ing. Rosa Almaraz

 7. Para Enfatizar el Contexto.

❖ Diagramas de Estado.
➢ Muestra todos los estados posibles que los objetos de la clase pueden tener.
➢ Muestra qué eventos causan un cambio de estado.
➢ No son dibujados para todas las clases, sólo aquellas que tienen estados
bien definidos.
➢ Pueden ser dibujados para el sistema en su totalidad.
➢ Complementan la descripción de una clase.

❖ Diagramas de Componentes.
❖ Diagramas de Implementación.

2.- Las reglas: Dictan pautas para la realización de asociaciones entre objetos, son reglas
semánticas, que afectan a los nombres, a la visibilidad, a la integridad y a la ejecución.

3.- Mecanismos: Proporcionan comentarios extra, información o semántica acerca de un elemento

del modelo. Se utilizan en los diagramas.
Mecanismos comunes: Sirven para que cada persona o entidad adapte el lenguaje a sus
necesidades, dentro del marco ordenado y siguiente las reglas para que no se pierda la semántica
propia de UML. Entre estos mecanismos se tienen:
Especificaciones: Una explicación textual de la sintaxis y semántica de los bloques de
construcción. Los elementos del modelo tienen propiedades que guardan datos sobre el
elemento. Una propiedad es definida con un nombre y un valor llamado valor agregado, el
cual es de un tipo especificado, por ejemplo integer o string. Hay una serie de funciones
predefinidas tales como Documentación, Responsabilidad, Persistencia, y Concurrencia.
Las propiedades son utilizadas para agregar especificaciones sobre instancias de elementos
que son normalmente mostrados en el diagrama. Una clase típicamente es descrita de
manera informal listando las responsabilidades y capacidades de la clase. Este tipo de
especificación no es normalmente mostrada en el diagrama por sí mismo, pero está
disponible en una herramienta usualmente accesada haciendo doble click sobre el elemento
que despliega una ventana con todas las propiedades.
✓ Adornos: Son elementos secundarios que proporcionan más nivel de detalle. Sirven para
dotar a los modelos de más semántica.
o Los adornos gráficos pueden ser incorporados a los elementos del modelo en los
diagramas. Un ejemplo de adorno es la técnica utilizada para separar tipo de una

Docente: Ing. Rosa Almaraz

 instancia.
o Cuando un elemento representa un tipo, su nombre es mostrado en negrillas.
Cuando el mismo elemento representa una instancia del tipo, su nombre es
subrayado y puede especificar el nombre de la instancia, así como el nombre del
tipo. Un rectángulo de clase, con el nombre en negrillas representa una clase, y el
mismo nombre subrayado representa un objeto.
o Lo mismo se aplica a los nodos, donde el símbolo del nodo puede ser un tipo, en
negrillas, tal como Impresora, o bien, una instancia del tipo, tal como Impresora
HP SMP. Otros adornos son la especificación de la multiplicidad de las relaciones,
donde la multiplicidad es un número o un rango que indica cuántas instancias de
tipos conectados pueden contenerse en la relación. Los adornos son escritos cerca
del elemento a los cuales agregan información. Todos los adornos son descritos en
conjunción con la descripción del elemento que ellos afectan.

✓ Notas: No todo puede ser definido en un lenguaje de modelaje, no importa cuán extenso
sea el lenguaje. Para permitir agregar información al modelo que de otra manera no puede
ser representada, UML proporciona las notas. Una nota puede ser puesta en cualquier lugar
del diagrama, y puede contener cualquier tipo de información. Su tipo de información es
una cadena que no puede ser interpretada por el UML. La nota es agregada típicamente a
algún elemento en el diagrama con alguna línea punteada que especifica cuál elemento está
siendo explicado o detallado, junto con la información en la nota.
o Una nota contiene cualquier información adicional, tales como comentarios simples
o Una nota contiene a menudo comentarios y preguntas del modelador como un
recordatorio para resolver un dilema más tarde.
o Las notas pueden tener también estereotipos que describen el tipo de nota.

✓ Las divisiones comunes: Permiten dividir los modelos en al menos un par de formas
diferentes, para facilitar la comprensión desde distintos puntos de vistas.
o División entre clases y objeto, (clase es una abstracción y objeto es una
manifestación de esa abstracción).
o División interfaz /implementación; la interfaz presenta un contrato (algo que se va a
cumplir de una determinada manera) mientras que la implementación es la manera
en que se cumple dicho contrato.

Docente: Ing. Rosa Almaraz

Mecanismos de extensibilidad: Sirven para evitar posibles problemas que pueden surgir debido
a la necesidad de poder representar ciertos matices, por esta razón UML incluye los estereotipos,
para poder extender el vocabulario con nuevos bloques de construcción, los valores etiquetados,
para extender las propiedades de bloque y las restricciones, para extender la semántica.

VISTAS:

Que son las vistas.

▪ Muestran diferentes aspectos de los sistemas modelados.
▪ No es un gráfico, es una abstracción que está formada por diferentes diagramas.
▪ Definiendo una serie de vistas, cada una representando un aspecto particular se puede
construir un sistema completo.
▪ Cada vista es descrita en una serie de diagramas.
▪ Los mismos contienen información que enfatiza un aspecto particular del sistema.
▪ Un diagrama puede ser parte de más vistas (traslape).

Tipos de Vistas:
 Vista de Caso de Uso: Muestra la funcionalidad de un sistema como es percibida por los
actores externos.
 Vista Lógica: Muestra cómo es diseñada la funcionalidad del sistema en términos de
estructuras estáticas del sistema y su comportamiento dinámico.
 Vista de Componente: Muestra la organización de los componentes del código.
 Vista de procesos: Muestra la concurrencia en el sistema, resolviendo problemas de
comunicación y sincronización que están presentes en un sistema concurrentes.
 Vista de Despliegue: Muestra el despliegue de un sistema dentro de una arquitectura
física con computadoras y dispositivos llamados nodos.

Donde utilizar UML

• Sistemas de información de empresas
• Bancos y servicios financieros
• Telecomunicaciones
• Trasporte
• Defensa/industria Inter espacial.
• Comercio
• Electrónica médica

Docente: Ing. Rosa Almaraz

 • Ámbito científico
• Servicios distribuidos basados en RED

Diferentes Tipos de sistemas

El objetivo es describir cualquier tipo de sistema, en términos de diagramas orientados a objetos.
Naturalmente, el uso más común es crear modelos de sistemas de software, también es utilizado
para describir sistemas mecánicos sin ningún software o la organización de un negocio. Aquí hay
algunos tipos diferentes de sistemas y sus características más comunes.

• Sistemas de Información: Almacenan, recuperan, transforman y presentan información a los

usuarios. Manejan grandes cantidades de datos con relaciones complejas, los cuales son
almacenados en bases de datos relacionales o de objetos.

• Sistemas Técnicos: Mantienen y controlan equipo técnico tal como procesos de

telecomunicaciones, procesos de sistemas militares o procesos industriales. Deben mantener
las interfaces especiales del equipo y tienen menos software que los sistemas de información.
Los sistemas técnicos son a menudo sistemas de tiempo real.

• Sistemas de Tiempo Real Empotrados: Se ejecutan en un hardware simple empotrado en

cualquier otro equipo tal como un teléfono móvil, un carro, un utensilio del hogar, etc. Esto es
llevado a cabo a través de programación de bajo nivel que requiere soporte de tiempo real.
Estos sistemas a menudo carecen de dispositivos tales como pantalla, disco duro, etc.

• Sistemas Distribuidos: Distribuidos en una serie de máquinas donde los datos son
transferidos fácilmente de una máquina a otra. Requieren de mecanismos de comunicación
sincronizada para asegurar la integridad de los datos y son construidos a menudo sobre
mecanismos de objetos tales como CORBA, COM/DCOM, o Java Beans/ RMI.

• Software de Sistemas: Definen la infraestructura técnica que utiliza otro software. Los
sistemas operativos, bases de datos, e interfaces de usuario realizan operaciones de bajo nivel
en el hardware, mientras presentan interfaces genéricas para ser utilizadas por otro software.

• Sistemas de Negocios: Describen los objetivos, los recursos (humanos, computadoras, etc.),
las reglas (leyes, estrategias del negocio, políticas, etc.), y el trabajo actual en el negocio
(procesos del negocio).

Docente: Ing. Rosa Almaraz

 Es importante enfatizar que la mayoría de los sistemas no encajan limpiamente en una de
estas categorías, pero pertenecen a más de uno de los tipos de sistemas o como una
combinación. Por ejemplo, muchos de los sistemas de información de hoy tienen
requerimientos distribuidos y de tiempo real.

Proceso Unificado

Que es el Proceso Unificado.

Es un proceso de ingeniería de software.
Proporciona una aproximación disciplinada para asignar tareas y responsabilidades dentro de una
organización de desarrollo
Meta: asegurar software de alta calidad, dentro de un tiempo y presupuesto predecible.

Fases del Proceso

Inicio
Elaboración
Construcción
Transición

Características del proceso

Tecnología de Objetos.
Desarrollo conducido por Casos de Usos.
Desarrollo Iterativo Controlado.
Administración de Requerimientos.
Fuerte énfasis en la Arquitectura.
Desarrollo basado en componentes.
Configurabilidad del proceso.

Docente: Ing. Rosa Almaraz

Descripción de las Fases de Proceso Unificado

Inicio:
• Objetivos:
• Razón del negocio
• Alcance del proyecto.
• Que se hace:
• Costos.
• Beneficios.
• Definición de los Casos de Uso del negocio.
• Se determina si se sigue o no con el proyecto.

Elaboración:
▪ Analizar el dominio del problema:
▪ ¿Qué es lo que se va a construir?
▪ ¿Cómo se va a construir?
▪ ¿Qué tecnología se va a utilizar?
▪ Establecer una fundición arquitectónica sólida.
▪ Deben ser tomadas con un entendimiento completo del sistema.
▪ Debe describir la mayor cantidad de casos de usos.
▪ Tomar en cuenta algunas restricciones: requerimientos no
funcionales.
▪ Para verificar la arquitectura: debe implementar un sistema que
demuestre las opciones arquitectónicas y ejecute casos de usos
significativos.
▪ Eliminar los elementos de más alto riesgo del proyecto
▪ Riesgos de requerimientos / Riesgos tecnológicos
▪ Riesgos de habilidades / Riesgos Políticos

1. Que se hace:
2. Se obtienen requerimientos más detallados.
3. Se hace análisis y diseño para de alto nivel, para obtener la arquitectura
base.
4. Se crea el plan para la construcción.
5. Cuando Termina:
6. Cuando se conoce cuanto tiempo demora en realizar cada caso de uso

Docente: Ing. Rosa Almaraz

 7. Cuando ya se han identificado los riesgos significativos.

Construcción
❖ Muchas iteraciones.
❖ En cada iteración se construye software de calidad, probado e integrado.
❖ En cada iteración se hace Análisis, Diseño, Implementación y Pruebas.
❖ Iterativo.
❖ Incremental.
❖ Se desarrolla un producto completamente listo.
❖ Cada iteración es un mini proyecto(Análisis,Diseño, codificación, pruebas e integración)
para los casos de usos asignados a cada iteración.
❖ Dentro de cada iteración puede haber una planificación más detallada.

Transición.
 Pruebas beta.
 Optimización del rendimiento.
 Capacitación del usuario.

Otros conceptos

Ciclo.
• El ciclo de vida de software está dividido en ciclos
• Cada ciclo trabaja en una nueva generación del producto.
• Un ciclo está compuesto por fases:
• Inicio
• Preparación
• Construcción
• Transición.

Hitos.
• Cada fase está construida por hitos, bien definidos.
• Hito: un punto en el tiempo donde ciertas decisiones críticas deben tomarse.
• Cada fase tiene un propósito.

Docente: Ing. Rosa Almaraz

Modelos del Proceso Unificado.
• Modelo de Casos de Usos
• Modelo de Diseño
• Modelo de Implementación
• Modelo de Prueba

Docente: Ing. Rosa Almaraz