Requisitos

Proceso Unificado
Captura de Requisitos
Laboratorio de Software
Segundo Semestre 2007
Prof. Angel Augusto Agudelo Z

Catedrático UTP
Facultad de Ingenierías
Ingeniería de Sistemas y Computación
UNIVERSIDAD TECNOLÓGICA DE PEREIRA
1
Angel Augusto Agudelo Z

Ingeniería de Sistemas y Computación Página –2–
Definición
 Según el estándar IEEE-STD-729, un
requerimiento se define como:
1. Una condición o capacidad necesitada por un
usuario para resolver un problema o lograr un
objetivo.
2. Una condición o capacidad que debe ser alcanzada,
o poseída por un sistema o componente del sistema
para satisfacer un contrato, estándar, especificación
u otro
documento formalmente impuesto.
3. Una representación documentada de una condición
o capacidad como en 1 y 2.

Clasificación
 Funcionales: corresponden a los resultados que debe
arrojar el sistema bajo determinadas circunstancias.
 No funcionales: están relacionados con el
rendimiento, seguridad, precisión, manejo de errores y
capacidades para usuarios específicos. Normalmente las
restricciones se
traducen en requerimientos no funcionales.
 Inversos: indican lo que el software "no debe hacer".
Son de mucha importancia en el software de misión
crítica.
 Restricciones de Diseño e Implementación:
corresponden a condiciones impuestas por el usuario
para el diseño y la implementación de la aplicación.

Los Requerimientos deben ser
 Precisos: no deben ser ambiguos.
 Consistentes técnicamente: consigo mismo
y con otros.
 Completos: todo lo necesario debe estar
descrito.
 Trazables: descritos de tal manera que
tengan una única identificación y que se
puedan medir.
 Comparables: es decir, que se puedan
probar.

Los Requerimientos no pueden
 Ruido: datos que sin aportar nueva
información, sólo causan confusión.
 Omisión: no describir algo que si debe
contemplarse.
 Contradicción: el tener dos o más
requerimientos en conflicto entre ellos.
 Ambigüedad: presencia de texto que se
presta para dos o mas interpretaciones.
 Que no sea comparable: un requisito que no
se puede comprobar, debe reescribirse de
forma que tenga una prueba objetiva.

Requerimientos de Usuario
 El propósito es :
 refinar una idea sobre la tarea a realizarse con equipo
computacional,
 hacia una definición de lo que se espera del sistema.
 Los responsables de esta tarea son los analistas.
 Para identificar requisitos hay que entrevistar al
cliente/usuario.
 Se debe usar la experiencia de los ingenieros y personal
clave (cliente/usuario) para ayudar a especificar y
revisar los requisitos.
 Se entrega el URD, el cual es crítico para el resto del
proyecto porque define la base sobre la cual se
aceptará el proyecto.
 Esta fase termina con la aprobación formal del URD por
la actividad de revisión UR/R.
 El URD representa la visión del usuario acerca del
problema a resolver.
Capturar Requerimientos de
Usuario
 Proceso iterativo.
 Se realizan entrevistas con el usuario.
 Se usan cuestionarios.
 Se revisan todos los formularios y sistemas
involucrados.
 Se establecen acuerdos con respecto a los
límites del sistema.

Determinar el Ambiente
Operacional
 Primer paso para definir los requisitos del
software.
 Debe establecerse el escenario en el que
operara el software a desarrollar.
 Es una narrativa que puede apoyarse de
diagramas de contexto o de bloques, que
permita mostrar el uso del sistema en un
ambiente más grande.
 Cosas a revisar en la definición del escenario:
 tipos de máquinas (hardware y software),
 tipos de comunicaciones a usar (teléfono, LAN,
WAN),
 interfaces con otros sistemas (en producción o en
desarrollo).
Plantilla para Especificaciones OO
1. Introducción
1.1 Propósito
1.2 Alcance del Proyecto
1.3 Glosario: Definiciones, Acrónimos y Abreviaciones
1.4 Referencias
1.5 Contenido
2. Descripción General
2.1 Contexto del Producto
2.2 Funciones del Producto
2.3 Características de los Usuarios
2.4 Restricciones
2.5 Dependencias y Supuestos
3. Requerimientos de Interfaces Externas
3.1 Interfaces de Usuario
3.2 Interfaces de Hardware
3.3 Interfaces de Software
3.4 Interfaces de Comunicación

1. Requerimientos Funcionales
4.1 Casos de Uso
4.1.1 Caso de Uso 1
4.1.2 Caso de Uso 2
...
4.2 Reportes
4.2.1 Reporte 1
4.2.2 Reporte 2
4.3 Diagramas de Secuencia
4.3.1 Diagrama de Secuencia 1
4.3.2 Diagrama de Secuencia 2
...
4.4 Modelo Conceptual
4.4.1 Descripción
4.4.2 Clase/Objeto1
4.4.3 Clase/Objeto2
...
2. Requerimientos de Rendimiento
3. Restricciones de Diseño

1. Atributos del Sistema
2. Requerimientos Adicionales
3. Anexos
 Modelo Conceptual
 Diagramas Casos de Uso
 Diagramas de Secuencia
 Diagramas de Clase
 Modelo de Datos Lógico
 Diccionario de Datos
 Pantallas del Prototipo
 Descripción de Archivos

Diagramas de Casos de Uso
 Descripción de un conjunto de secuencias de
acciones que ejecuta un sistema produciendo
un resultado de interés para un actor.
 Describen el comportamiento para cada actor
 Instancia de caso de uso
 Se lleva a cabo mediante colaboraciones de
objetos
 Colaboración:
 Define las interacciones que han de producirse entre
los objetos con el fin de que estos puedan
desempeñar su papel.

 Elementos estructurales:
 Relaciones:
 Dependencia: relación semántica donde un cambio
en el elemento independiente puede afectar a la
semántica del elemento dependiente.
Elemento dependiente  Elemento independiente

 Relaciones
 Asociación: enlace que representa conexión entre
objetos
 Realización: relación semántica entre clasificadores,

en la cual un clasificador especifica un contrato que
otro clasificador se compromete a llevar a cabo.

TAREA PRODUCTO (artifact)

Enumerar requisitos Lista de características
candidatos
Entender el contexto Modelo de negocios o
del sistema de dominio
Capturar requisitos Modelo de casos de
funcionales uso
Capturar requisitos no Prototipo
RequisitosIU
funcionales suplementarios o
casos individuales


candidatos
funcionales uso
RequisitosIU
casos individuales

 Modelo del Dominio
 ¿Qué es?
 Tipos de objetos (especificación o entrevistas)
 “Cosas” y eventos
 Diagramas de clases y glosario
 Desarrollar el modelo del dominio
 Técnicas de comunicación
 Solo contexto
 Usar el modelo del dominio
 Al describir los casos de uso
 Conceptos sugieren clases de análisis y diseño

 Modelo de negocio
 ¿Qué es?
 Procesos de negocio
 Cómo se realiza un proceso por un conjunto de
trabajadores que usan unas entidades y unidades de
trabajo
 Desarrollar el modelo de negocio
 Identificar casos de negocio y sus actores
 Desarrollar modelo de objetos de negocio con:
trabajadores, entidades de negocio y unidades de
trabajo
 Usar el modelo de negocio
 Un actor por trabajador
 Identificar sus papeles en distintos casos


candidatos
funcionales uso
RequisitosIU
casos individuales

Captura de Requisitos Funcionales
 Basado en casos de uso
 CU para el actor: forma de utilizar el sistema
 Objetivos:
 Capturar el comportamiento, sin especificar
 Comprensión común
 Validar arquitectura y sistema

1. Identificar actores y casos de uso
2. Priorizar casos de uso
3. Detallar casos de uso
4. Prototipo de IU
5. Estructurar el modelo

1. Identificar actores y casos de uso
 Para:
 Delimitar el sistema
 Actores y funcionalidad
 Glosario
 Pasos:
 Descubrir los actores
 Descubrir los casos de uso
 Describir brevemente cada caso de uso
 Describir el modelo de casos de uso

Ejemplo: Cajero Automático
 Lista de Requisitos Candidatos
 FUNCIONES BÁSICAS
1. El usuario podrá consultar el saldo de su cuenta
2. Si el usuario intenta sacar una cantidad que supera el saldo
de su cuenta, el cajero le avisará de que no es posible sacar
esa cantidad
3. Si el usuario intenta sacar una cantidad que supera el límite
diario, el cajero le avisará de que no es posible y volverá a
solicitar una cantidad
4. El cliente del banco podrá hacer una transferencia a otra
cuenta
...
 REQUISITOS NO FUNCIONALES
1. Fácil de usar
2. Tiempo de respuesta inferior a 30 seg.
...

 Casos de Uso. Descripción Inicial
Caso de Uso: Sacar dinero
Actores: Cliente (iniciador)
Tipo: ??
Descripción: El caso de uso comienza con la identificación del
usuario. El cliente usa el caso de uso para acceder
a su cuenta. El caso de uso le devuelve el dinero
solicitado, un aviso de que no tiene saldo o de que
ha excedido el límite diario.
Caso de Uso: Consultar saldo

Actores: Cliente
Tipo: ??
Descripción: El caso de uso comienza con la identificación del
usuario. El usuario consulta el saldo de su cuenta.

1. Priorizar los casos de uso
 Visión de la arquitectura
 Casos de uso a desarrollar en las primeras
iteraciones
 Casos de uso significativos

1. Detallar casos de uso
 Objetivo: flujo de sucesos (o eventos):
 Cómo comienza y termina el caso de uso
 Cómo interactúa con los actores
 Objetos que se intercambian
 Veremos:
 Cómo estructurar la descripción de un CU
 Qué incluir en una descripción de un CU
 Cómo formalizar la descripción del CU
 Antes...

Diagramas de Estado
 Un diagrama de estados representa un
elemento como una máquina de estados finita
 Un diagrama de estado, representa la vida de
un único elemento
 Consta de: Estados, Transiciones, Eventos y
Actividades
 Permite visualizar el comportamiento
(dinámico) de un elemento

Diagramas de Estados
 Elementos
 Estado: situación en la vida de un elemento durante
la cual se satisface alguna condición, se realiza
alguna actividad o se espera algún suceso
 Inicial, Intermedio, Final
 Transición: relación entre dos estados que indica
que un elemento que esté en un primer estado
realizará ciertas acciones y entrará en el segundo
estado cuando se produzca un suceso especificado y
se satisfacen las condiciones indicadas
 Suceso o evento: especificación de algún
acontecimiento que ocupa espacio y tiempo. Es la
aparición de un estímulo que puede disparar la
transición de un estado a otro

Diagramas de Estado

Diagramas de Estado
 Actividad: ejecución no atómica en curso,
dentro de una máquina de estados. Lo que se
hace en el estado
 do: operación que toma un tiempo en el estado.
Puede interrumpirse por un suceso, externo o
interno, o terminar en transición automática
 Acción: computación atómica ejecutable que
produce un cambio de estado del modelo o
devuelve algún valor (deben ser operaciones
de la clase)
 entry: instantáneamente a la entrada del estado
 exit: instantáneamente a la salida del estado
 eventos
Diagramas de Estado
 La acción se considera instantánea
 Ejemplos:

Capturar Requisitos Funcionales
1. Detallar casos de uso (cont.)
 Cómo estructurar un CU
 Camino básico: “normal”
 Alternativas:
 El actor puede elegir diferentes caminos
 Si está implicado más de un actor, las acciones de uno
pueden influir el camino de otro
 El sistema detecta entradas erróneas
 Algunos recursos funcionan mal
 Gráficamente: diagrama de transición de estados

 Qué incluir (descripción textual)
 Estado inicial como precondición (condiciones previas)
 Cómo y cuándo comienza el caso de uso
 Orden de acciones (flujo de sucesos)
 Cómo y cuándo termina el caso de uso
 Estados finales como postcondiciones (cond. posteriores)
 Caminos no permitidos
 Descripción caminos alternativos (incluida o no con el c.
básico)
 Interacción del sistema con los actores y cambios que
producen
 Uso de objetos, valores y recursos del sistema
 Qué hace el sistema. Separar responsabilidades. “el
sistema...”
 Requisitos especiales
 Validar los casos de uso
 Para casos de uso sencillos es suficiente texto
 Casos de uso complejos: necesitan estructuración y
técnicas visuales
 Formalismos: diagramas de
 transición de estados
 actividad
 interacción

Diagramas de Estado
 Diagrama de estados para un caso de uso:
modificar datos alumno

Caso de Uso “Sacar dinero”
 Flujo de Eventos
ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA
1. Este caso de uso empieza 1. Pide la clave de identificación
cuando un cliente introduce
una tarjeta en el cajero
1. Introduce la clave 1. Comprueba la clave
1. Presenta las opciones de

operaciones disponibles
1. Selecciona la opción de 1. Pide la cantidad a retirar
reintegro
1. Introduce la cantidad 1. Produce la petición y da el
requerida dinero solicitado
2. Genera un recibo
1. Recoge el dinero
2. Recoge el recibo y termina el
caso de uso


1. Selecciona la opción de 1. Pide la cantidad a retirar
reintegro
1. Introduce la cantidad 1. Produce la petición y da el
requerida dinero solicitado
2. Genera un recibo
1. Recoge el dinero
caso de uso

Caso de Uso “Validar usuario”

CAMINOS ALTERNATIVOS
Evento 3. El cliente cancela la transacción
Evento 4. La clave no es válida y se reinicia el caso de
uso. Si ocurre tres veces se cancela la transacción y se
bloquea la tarjeta
¡¡HAY QUE DEFINIR ESTOS DOS FLUJOS DE

EVENTOS!!
1. Este caso de uso empieza 1. Pide la cantidad a retirar
cuando se han presentado las
opciones de operaciones
disponibles. Selecciona la
opción de reintegro
1. Introduce la cantidad 1. Procesa la petición y da el
requerida dinero solicitado.
2. Genera un recibo.
1. Recoge el dinero
CU

 CAMINOS ALTERNATIVOS
 Evento 4: La cantidad solicitada supera el saldo. Se indica el
error y se cancela la operación.
 Evento 4: La cantidad solicitada supera el límite diario. Se
indica el error y se vuelve a pedir otra cantidad.
 Evento 4: En el cajero no hay dinero.
¡¡HAY QUE DEFINIR ESTOS TRES FLUJOS DE

EVENTOS!!
 Podríamos definir diagramas de estados
 Requisito no funcional asociado al caso de uso Sacar
dinero: El tiempo de respuesta para un cliente debe ser
<30 sg en el 90% de los casos

Caso de Uso “Validar usuario”

1. Prototipo de IU
 A partir de las descripciones de los casos de uso.
 Pasos:
 Diseño lógico: qué necesita cada actor de la interfaz
para que se pueda ejecutar el caso de uso
 Descripción y construcción del prototipo ejecutable
pero acciones nulas (validación y depuración)

1. Estructurar el modelo de casos de uso
 Identificar funcionalidad compartida
 Generalizaciones
 Identificar funcionalidad adicional y opcional
 extend
 Identificar otras relaciones
 include

 Relaciones

 Relaciones




candidatos
funcionales uso
RequisitosIU
casos individuales

Curso Virtual
 Un sistema que ofrece cursos virtuales permite que
tanto profesores como alumnos accedan al sistema.
Existen una serie de operaciones comunes que ambos
pueden realizar como son asistir al foro y comunicarse a
través del chat. En cualquier caso, tanto profesores
como alumnos deberán loguearse en el sistema antes
de poder acceder al curso.
 Obligatoriamente, un alumno deberá haberse
matriculado en el sistema para poder acceder a él. Así
además los profesores podrán consultar los alumnos
matriculados en cualquiera de los cursos. Los alumnos
podrán modificar sus datos.
 Los profesores podrán colgar el material docente del
curso a través de la aplicación. Los alumnos de este
modo, podrán acceder a consultar las lecciones.
Además asociado a cada lección podrán consultar la
bibliografía asociada, descargarse los apuntes y realizar
los tests asociados al temario. También podrán,
opcionalmente, recomendar dichas lecciones a otros
alumnos matriculados.
Ejemplo: Curso Virtual

Ejemplo: Punto de Venta
 Lista de requisitos candidatos
 FUNCIONES BÁSICAS
 R1.1. Grabar la venta actual (productos comprados por el
cliente)
 R1.2. Calcular el total de la venta actual incluidos los
impuestos
 R1.3. Capturar información del producto usando el código de
barras o tecleando el código del producto.
 R1.4. Reducir la cantidad en inventario cuando se realice la
venta
 R1.5. Registrar ventas realizadas
 R1.6. El dependiente debe iniciar una sesión con identificador
y clave para usar el sistema
 R1.7. Dar un mecanismo de almacenamiento
 R1.8. Dar mecanismos de comunicación con otros procesos y
sistemas
 R1.9. Mostrar descripción y precio del producto almacenado
 NO
Angel FUNCIONAL
Augusto Agudelo Z5 seg, color
 Lista de requisitos candidatos
 FUNCIONES DE PAGO
 R2.1. Manejar pagos en metálico, tomar cantidad ofrecida y
calcular el cambio
 R2.2. Manejar pagos con tarjeta, capturar información de la
tarjeta con un lector o manualmente y autorizar el pago vía
modem.
 OTRAS FUNCIONES
 R3.1. Es necesario dar de alta dependientes nuevos en el
puesto de venta y dar de baja aquellos que dejan el puesto de
venta.
 R3.2. El puesto de venta es encendido y apagado cada día por
el encargado de la sección, que comprueba que el puesto
funciona correctamente y comprueba la fecha y la hora
 REQUISITOS NO FUNCIONALES
 Fácil de usar, Tiempo de respuesta corto, Plataforma, Precio al
público
 Interfaz (gráfica, con colores, ventanas, facilitar navegación
por teclado,…)

Caso de Uso “Acceder al sistema”
 El actor rellena los campos del DNI y 1. El sistema comprueba que el formato
clave (la clase se la dió la de ambos campos es el adecuado; es
Universidad) en una pantalla que le ha decir, que el DNI es un string de 8
presentado el sistema y pulsa el botón dígitos y que la clave es una
de enviar secuencia de 4 dígitos
1. El sistema verifica que la clave
tecleada se corresponde con el DNI
tecleado; es decir, que la clave es la
correcta para ese DNI.
1. El sistema verifica que la fecha actual
es la que le corresponde al actor para
matricularse.
1. El sistema comprueba que el actor no
adeuda ningún importe a la
Universidad
Caminos alternativos:
Evento 1: el actor cancela la operación
Evento 2: existe error en el formato del DNI y/o de la clave
Evento 3: existe error en la clave
Evento 4: la fecha actual no es la asignada al actor para
matricularse
Evento 5: el actor es moroso
Caso de Uso “Acceder al sistema”

CheckList
 Contenido de los Requerimientos
1. ¿Se ha especificado el objetivo del Sistema?
2. ¿Se han especificado todas las entradas del sistema incluyendo
su fuente, precisión, rango de valores y frecuencia?
3. ¿Se han especificado todas las salidas del sistema incluyendo su
destino, precisión, rango de valores y frecuencia y formato?
4. ¿Se ha construido el modelo lógico de datos?
5. ¿Se han identificado los dominios del modelo de datos? ¿Se han
identificado los parámetros del sistema?
6. ¿Se ha construido el mapa de navegación? ¿Se ha descrito cada
página del mapa de navegación?
7. ¿Se han especificado todos los reportes del sistema?
8. ¿Se ha definido el tipo de administración que requiere el sistema?
9. ¿Se han especificado todas las interfaces externas de hardware y
software?
10. ¿Se ha especificado el tiempo de respuesta, desde el punto de
vista del usuario, para todas las operaciones que lo requieren?
11. ¿Se ha especificado toda la funcionalidad que debe satisfacer el
sistema?

CheckList
 Contenido de los Requerimientos
1. ¿Se ha especificado para cada proceso los datos utilizados
y los datos entregados por el proceso?
2. ¿Se han identificado los usuarios del sistema? ¿Los
usuarios finales?
3. ¿Se han definido los roles del sistema? ¿Se ha
especificado el nivel de seguridad del sistema?
4. ¿Se ha especificado la confiabilidad incluyendo las
secuencias de una caída del software, información vital
protegida, detención de errores y recuperación?
5. ¿Se ha incluido la definición de éxito y fracaso para los
procesos del sistema?
6. ¿Se ha especificado la mantenibilidad del sistema,
incluyendo la capacidad de responder a cambios en el
ambiente de operación, interfaces con otros sistemas,
precisión, rendimiento y otras capacidades predecibles?

CheckList
 Completitud de los Requerimientos
1. ¿En donde la información no está disponible antes
del desarrollo, se han especificado las áreas de
deficiencia?
2. ¿Están los requerimientos completos en el sentido
de que si el sistema satisface los requerimientos,
éste será aceptable?
3. ¿Hay disconformidad acerca de algún
requerimiento? ¿Hay partes imposibles de
implementar o incluidas sólo para satisfacer al
cliente?

CheckList
 Calidad de los Requerimientos
1. ¿Están los requerimientos descritos en lenguaje del usuario? ¿Los
cree así el usuario?
2. ¿Se han validado los requerimientos con el usuario? ¿Con los
demás integrantes del equipo de trabajo?
3. ¿Se han validado los prototipos con el usuario final?
4. ¿Evitan los requerimientos conflictos entre sí?
5. ¿Los requerimientos incorporan aspectos de diseño?
6. ¿Están los requerimientos a un nivel de consistencia adecuado?
¿Debería especificarse en más detalle algún requerimiento?
¿Debería especificarse en menos detalle algún requerimiento?
7. ¿Son los requerimientos lo suficientemente claros como para ser
entregados a un grupo independiente para su codificación y aún
ser comprendidos?
8. ¿Es cada requerimiento relevante para el problema y su solución?
¿Puede rastrearse el origen de cada requerimiento en el
ambiente del problema?
9. ¿Se puede probar cada requerimiento? ¿Será posible para un
grupo independiente de pruebas determinar si un determinado
requerimiento ha sido satisfecho?

CheckList
 Especificación de los Requerimientos
1. ¿Es la especificación modular? ¿Es posible
incorporar / modificar / eliminar información sin
producir grandes transformaciones en la estructura?
2. ¿Existen referencias cruzadas en la especificación?
3. ¿Se ha revisado la ortografía y redacción del
documento?
4. ¿Existe una tabla de contenidos, figuras y/o tablas?


Requisitos

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Requisitos

Загружено:

Авторское право:

Доступные форматы

Proceso Unificado

Prof. Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Elemento dependiente  Elemento independiente

Angel Augusto Agudelo Z

 Realización: relación semántica entre clasificadores,

Angel Augusto Agudelo Z

TAREA PRODUCTO (artifact)

Angel Augusto Agudelo Z

TAREA PRODUCTO (artifact)

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

TAREA PRODUCTO (artifact)

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Caso de Uso: Consultar saldo

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

1. Presenta las opciones de

Angel Augusto Agudelo Z

1. Presenta las opciones de

Angel Augusto Agudelo Z

1. Presenta las opciones de

¡¡HAY QUE DEFINIR ESTOS DOS FLUJOS DE

Angel Augusto Agudelo Z

¡¡HAY QUE DEFINIR ESTOS TRES FLUJOS DE

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

TAREA PRODUCTO (artifact)

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z

Angel Augusto Agudelo Z