Unidad 2

Unidad 2 – Requerimientos del software
●
Contenido
●
Requerimientos
●
Importancia de los requerimientos
●
Impacto en la etapa de requerimientos
●
Rol de los requerimientos
●
Definición IEEE
●
Tipos de requerimientos
Unidad 2 – Requerimientos del software
●
Contenido
●
Ingeniería de requerimientos
●
Fuentes de requerimientos
●
Técnicas de educción de requerimientos
●
Criterios a cumplir por parte de una ERS
●
Estándares disponibles
●
Guías para escribir requerimientos
IS Unidad 2 - Luis Nieto - 2022 2

Requerimientos
●
Requerimientos:
●
Descripción de los servicios que brinda un
sistema, y sus restricciones operativas
●
Reflejan las necesidades de los clientes de un
sistema que ayude a resolver algún problema

Requerimientos
●
Ingeniería de Requerimientos (IR):
●
Proceso que consiste en descubrir, analizar,
documentar y verificar los requerimientos de
un sistema y sus restricciones

Requerimientos
●
Especificación de un requerimiento:
●
Declaración abstracta, de alto nivel, de un
servicio que debe proporcionar el sistema o
una restricción del mismo

Requerimientos
●
Algunos problemas que surgen en la IR se deben
a no separar los niveles de descripción:
●
Requerimientos del usuario: declaraciones
abstractas, en lenguaje natural, de los
servicios que brindará el sistema, y las
restricciones bajo las cuales debe funcionar
●
Requerimientos del sistema: declaraciones
detalladas de las funciones, servicios y
restricciones operativas del sistema

●
Cuanto más tarde se detecta un error, más
cuesta repararlo.
●
El incremento de los costos deriva de la
necesidad de corregir los errores originales y
los que se generan en etapas posteriores


●
Los errores en los requerimientos pueden
detectarse:
●
Las inspecciones resultan muy efectivas

●
Conclusiones:
●
Se cometen muchos errores de requerimientos
●
Muchos errores se detectan tarde
●
Muchos errores pueden detectarse temprano
●
No detectar los errores contribuye al
incremento de costos en el SW

Impacto en la etapa de requerimientos
●
El SW resultante puede no satisfacer a los
usuarios
●
Las interpretaciones múltiples de los
requerimientos pueden causar desacuerdos
●
Es imposible que a través de las pruebas el SW
satisfaga sus requerimientos
●
Puede gastarse tiempo y dinero construyendo un
sistema erróneo

Rol de los requerimientos
●
Acuerdo entre desarrolladores, clientes y usuarios
finales (aspecto contractual)
●
Base para el diseño del SW (minimizar defectos
tanto como sea posible)
●
Soporte para verificación y validación
●
Soporte a la evolución del sistema

Definición IEEE
●
1. Condición o capacidad que necesita el usuario
para resolver un problema o alcanzar un objetivo
●
2. Condición o capacidad que debe satisfacer o
poseer un sistema (o un componente de un
sistema) para satisfacer un contrato, un
estándar, una especificación u otro documento
formalmente impuesto
●
3. Representación documentada de una condición
o capacidad como en 1 o 2

●
Requerimientos Funcionales
●
Declaraciones de los servicios que debe
proporcionar el sistema
●
Cómo debe reaccionar el sistema a entradas
particulares
●
Cómo debe comportarse el sistema en
determinadas situaciones

●
Requerimientos No Funcionales
●
Restricciones sobre los servicios o funciones
ofrecidas por el sistema, tales como
limitaciones de tiempo, restricciones en el
proceso de desarrollo, estándares, etc

●
Requerimientos Funcionales (RF)
●
Dependen del tipo de SW, los usuarios
previstos y el tipo de sistema donde se utiliza
el SW
●
Los RF del usuario pueden ser declaraciones
a alto nivel sobre lo que debería hacer el
sistema
●
Los RF del sistema describen los servicios del
sistema en detalle

●
Ejemplos de RF:
●
“El usuario podrá buscar por todas las BD o
seleccionar un subconjunto de ellas”
●
“A cada orden se le asignará un identificador
único (IDORDEN) que el usuario podrá copiar al
área de almacenamiento permanente de la
cuenta”

●
Requerimientos No Funcionales (RNF)
●
Definen propiedades del sistema (fiabilidad,
tiempo de respuesta, requisitos de
almacenamiento) y sus restricciones
(capacidad del dispositivo de E/S, sistemas de
representación)
●
También pueden especificar el uso de una
herramienta CASE en particular, un lenguaje
de programación o método de desarrollo

●
Clasificación de RNF
●
Requerimientos del producto: especifican
cómo debe comportarse el producto entregado
– Requerimientos de eficiencia
●
Requerimientos de rendimiento
●
Requerimientos de espacio
– Requerimientos de usabilidad
– Requerimientos de fiabilidad
– Requerimientos de portabilidad

●
●
Requerimientos organizacionales: son
consecuencia de las políticas y procedimientos
de la organización
– Requerimientos de entrega
– Requerimientos de implementación
– Requerimientos de estandarización

●
●
Requerimientos externos: requerimientos
que surgen de factores externos al sistema y
su proceso de desarrollo
– Requerimientos de interoperabilidad
– Requerimientos éticos
– Requerimientos legales
●
Requerimientos de privacidad
●
Requerimientos de seguridad

●
Ejemplos de RNF:
●
Requerimientos del producto
“Debe ser posible que toda la comunicación
–
entre el APSE y el usuario se exprese en el
juego de caracteres estándar de Ada”
●
Requerimientos organizacionales
– “El proceso de desarrollo y los documentos
de entrega estarán conforme al proceso y
entregables definidos en XYZCo-SP-STAN-95”

Ingeniería de Requerimientos
●
El proceso de IR puede ser descrito en 6 pasos:
●
Identificación de requerimientos
●
Análisis de requerimientos y negociación
●
Especificación de requerimientos
●
Modelizado del sistema
●
Validación de requerimientos
●
Gestión de requerimientos

●
●
Preguntar al cliente, usuarios, expertos en el
dominio
●
Investigar cómo se ajustan los sistemas o
productos a las necesidades del negocio
●
Cómo se utilizará el sistema o producto en el
día a día

●
Lo anterior resulta difícil porque:
– El límite del sistema está mal definido o
detalles técnicos innecesarios confunden
más de lo que aclaran
– Hay dificultades para comunicar las
necesidades por parte de los
clientes/usuarios, se omite información, etc
– Los requerimientos cambian con el tiempo

●
El resultado de la identificación de
requerimientos debería incluir:
– La relación necesidades/características
– Un informe conciso del alcance del sistema
– Una lista de clientes, usuarios y otros
intervinientes que deben participar en la
actividad de obtención de requerimientos

●
El resultado de la identificación de
requerimientos debería incluir:
– Una descripción del entorno técnico
– Una relación de requerimientos y
restricciones aplicables a cada uno
– Un conjunto de escenarios que permitan
profundizar en el uso del sistema
– Cualquier prototipo desarrollado para definir
mejor los requerimientos

●
Análisis y negociación de requerimientos
●
Los requerimientos:
– Se agrupan por categorías
– Se estudia cada uno en relación con el resto
– Se examinan (consistencia, completitud,
ambigüedad)
– Se clasifican en base a las necesidades de
los clientes/usuarios

●
Preguntas al iniciar el análisis:
– ¿Cada requisito es consistente con los
objetivos generales del sistema/producto?
– ¿Tienen todos los requerimientos el nivel
adecuado de abstracción?
– ¿El requisito es necesario o representa una
característica que puede no ser esencial a la
finalidad del sistema?

●
Preguntas al iniciar el análisis:
– ¿Cada requisito está delimitado y sin
ambigüedad?
– ¿Existe un origen para cada requisito?
– ¿Existen requerimientos incompatibles?
– ¿Es posible lograr cada requisito en el
entorno técnico?
– ¿Se puede probar el requisito una vez
implementado?

●
Es común en clientes y usuarios:
– Solicitar más de lo que se puede realizar
– Proponer requerimientos contradictorios
●
Estos conflictos se deben resolver a través de
la negociación (priorización)

●
Especificación de requerimientos: puede
tomar distintas formas:
●
Un documento escrito
●
Un modelo gráfico
●
Un modelo matemático formal
●
Una colección de escenarios de uso
●
Un prototipo
●
Una combinación de lo anterior.

●
Algunos sugieren el uso de una plantilla, para
poder presentar los requerimientos de una
forma más consistente y más comprensible
●
Para grandes sistemas, un documento escrito,
combinado con descripciones en lenguajes
natural y modelos gráficos puede ser la mejor
alternativa

●
La especificación del sistema (ERS) es el
producto final sobre los requerimientos del
sistema:
– Describe la función y características de un
sistema y las restricciones que gobiernan su
desarrollo
– Delimita cada elemento del sistema
– Describe la información (datos y control) que
entra y sale del sistema

●
Modelado del sistema
●
Se construyen modelos del sistema para:
– Poder evaluar sus componentes y relaciones
entre sí
– Determinar cómo están reflejados los
requerimientos
– Valorar como se ha concebido la estética en
el sistema

●
●
La validación examina las especificaciones
para asegurar que todos los requerimientos
han sido establecidos sin ambigüedad, sin
inconsistencias, sin omisiones, que los errores
detectados han sido corregidos, y que el
resultado del trabajo se ajusta a los estándares
establecidos para el proceso, el proyecto y el
producto

●
El primer mecanismo para validar los
requerimientos es la Revisión Técnica Formal
(RTF)
●
A medida que se desarrolla la especificación
del sistema se realizan muchas RTFs

●
También se pueden emplear cuestionarios:
– ¿Está el requisito claramente definido?
– ¿Puede interpretarse mal?
– ¿Está identificado el origen del requisito (por
ejemplo: persona, norma, documento)?
– ¿El requisito está delimitado en términos
cuantitativos?

●
También se pueden emplear cuestionarios:
– ¿Qué otros requerimientos hacen referencia
al requisito estudiado?
– ¿El requisito incumple alguna restricción
definida?
– ¿El requisito es verificable? Si es así, ¿Se
pueden efectuar pruebas para verificar el
requisito?
– ¿Se puede hacer una traza del requisito?

●
●
Los requerimientos del sistema cambian a lo
largo de la vida del sistema
●
La gestión de requerimientos ayuda al equipo
a:
– Identificar
– Controlar
– Seguir los requerimientos y los cambios

●
La gestión de requerimientos comienza con la
identificación:
– A cada requisito se le asigna un identificador
único
●
Luego se hará el seguimiento de los
requerimientos, para lo cual se podrán emplear
matrices de seguimiento (de características, de
orígenes, de dependencias, de subsistemas, de
interfaces, etc)

●
Libros y manuales: útiles para obtener
conocimientos básicos del dominio
●
Documentación formal: documentos que
contienen políticas y procedimientos, estándares,
normas y regulaciones, leyes de un dominio
●
Documentación informal: notas manuscritas,
memos internos, ayudas de trabajo, etc

●
Presentaciones: material para formación
●
Publicaciones especializadas: versiones más
actualizadas de los conocimientos del dominio
del problema

●
Investigación: resultados de las investigaciones
que se estén llevando a cabo
●
Visitas: llevadas a cabo en los lugares de trabajo
para observar el proceso de resolución de
problemas
●
Humanos: son las fuentes de conocimiento
imprescindibles de donde se obtiene la mayor
parte de los conocimientos
●
Estudio de documentación
●
Manuales, libros u otra forma escrita. Resulta
conveniente contar con un experto que:
– Explique la terminología usada
– Proporcione detalles omitidos en los
documentos
●
El tiempo de análisis es menor que el de otras
técnicas

●
Entrevistas
●
La entrevista es el método más común y
familiar para obtener requerimientos
●
Consiste en la interacción de un analista con
un usuario/experto del dominio para extraer
sus conocimientos

●
Cada entrevista debe:
– Ser identificada de manera única
– Detallar fecha, hora y lugar de realización
– Detallar personas involucradas
– Detallar duración
– Detallar resumen del tema tratado

●
Entrevista abierta (no estructurada): el
analista plantea preguntas al usuario:
●
¿Qué es lo que espera que el producto haga?
●
¿Cómo resuelve actualmente los problemas?
●
¿Cuáles son las personas involucradas?
●
¿Quién va a utilizar la solución?
●
¿Puede mostrar el entorno donde se resolverá
el problema?

●
Entrevista abierta (no estructurada):
●
Ventaja: genera rápidamente gran cantidad
de conocimiento sobre la terminología y
componentes principales de un dominio
●
Desventaja: muy consumidora de tiempo y no
sirve para refinar las versiones iniciales de un
sistema

●
Entrevista estructurada: combina una
observación de tareas habituales con una
entrevista abierta
●
Se planifican las preguntas a plantear al
usuario durante la sesión para un determinado
tema
●
Se usa normalmente en la segunda parte del
proceso de educción de requerimientos

●
Observación de Tareas Habituales (OTH):
observar al usuario trabajar en un problema real
habitual
●
La primera decisión que se debe tomar es
cómo registrar las prestaciones del usuario
(observar, tomar notas, grabar, etc)
●
En la OTH, el analista no interfiere en la
actuación del usuario en la solución de sus
tareas reales cotidianas

●
Observación de Tareas Habituales (OTH):
●
Desventaja: el analista actúa como un
observador pasivo, lo que hace que sea poco
práctica por consideraciones de tiempo

●
Incidentes críticos: se le pide al usuario que
describa casos especialmente interesantes o
difíciles que se le hayan presentado

●
Cuestionarios: entrevista estructurada al
experto a través de cuestionarios
●
Ventaja: forma eficiente de acumular
información (el usuario puede completar el
cuestionario en el ambiente que desee)

●
Correcta
●
Qué representa cada requerimiento
●
Relación con el sistema
●
Corrección y necesidades del usuario

●
No ambigua
●
Interpretación unívoca de los requerimientos
establecidos en ella
●
Ejemplo: “Todos los clientes tienen el mismo
campo de control”

●
Completa
●
Es el atributo más difícil de definir y de
detectar
●
Tomar como principio: "el SW hace sólo lo que
dice la especificación de requerimientos"

●
Verificable
●
Todo requerimiento incluido en la ERS es
“verificable”
●
Un requerimiento es “verificable” si existe un
proceso finito y efectivo en costo con el que
constatar que el sistema a construir satisface
el requerimiento

●
Ejemplos de requerimientos no verificables:
– “El producto debe trabajar bien”
– “El producto debería tener una buena
interfaz”
– “El programa no debe entrar nunca en un
lazo infinito”

●
Ejemplo de requerimientos verificables:
– “A partir de producido el evento X, se
obtendrá la salida del proceso: debe estar
dentro de los 20 segundos el 60% de las
transacciones y dentro de los 30 segundos el
99% de las transacciones”

●
Consistente
●
Ningún subconjunto está en conflicto. Tipos de
inconsistencias:
– Comportamiento conflictivo: 2 partes
especifican de forma diferente y conflictiva
– Términos conflictivos: 2 términos diferentes
se utilizan para definir lo mismo
– Características conflictivas: 2 partes
requieren rasgos contradictorios

●
Comprensible por los consumidores
●
Uso de notaciones formales
●
Primeros lectores de una especificación de
requerimientos
●
No ambigüedad

●
Modificable
●
Cualquier cambio puede hacerse fácilmente,
manteniendo la “completitud” y
consistentemente
●
Requiere tener una organización coherente y
fácil de usar, y no ser redundante

●
Trazabilidad
●
Claridad del origen de cada requerimiento:
facilita referenciar cada requerimiento
individual, lo cual facilita negociar los mismos
●
Técnicas:
– Numeración de párrafos
– Un requerimiento por párrafo
– Identificar cada requerimiento
– Convenciones sintácticas

●
Independiente del diseño
●
No implica una arquitectura específica de SW o
algoritmo
●
No limita a una alternativa de diseño
●
Factibilidad de diseños potenciales

●
En resumen:
●
Todas las características no son accesibles, es
imposible satisfacerlas a todas
●
No existe una especificación de requerimientos
perfecta

Estándares disponibles
●
IEEE/ANSI 830-1998
●
ISO/IEC/IEEE 29148

Estándar IEEE/ANSI 830-1998
●
1. Introducción
●
1.1. Propósito
●
1.2. Alcance
●
1.3. Definiciones, acrónimos y abreviaturas
●
1.4. Referencias
●
1.5. Descripción del resto del documento
●
2. Descripción general
●
2.1. Perspectiva del producto
●
2.2. Funciones del producto
Estándar IEEE/ANSI 830-1998
●
2.3. Características del usuario
●
2.4. Restricciones generales
●
2.5. Supuestos y dependencias
●
3. Requerimientos específicos: incluyen los
requerimientos funcionales, no funcionales y de
interfaz.
●
4. Apéndices
●
5. Índice

Estándar ISO/IEC/IEEE 29148
●
Especifica los procesos requeridos a implementar
por la Ingeniería de Requerimientos durante todo
el ciclo de vida del SW
●
Especifica los ítems de información a producir
mediante la implementación de los procesos
anteriores
●
Especifica los contenidos de los ítems de
información anteriores
●
Brinda guías para el formato de estos ítems de
información

Guías para escribir requisitos
●
Escribir oraciones completas empleando la
gramática, ortografía y puntuación adecuados
●
Mantener frases y párrafos cortos y directos
●
Usar la voz activa ("El sistema deberá hacer algo"
y no "Algo deberá pasar")
●
Emplear consistentemente los términos tal como
se definieron en el glosario (cuidado con los
sinónimos)

●
Transformar un requisito vago, de alto nivel, en
otro con el suficiente detalle como para aclarar y
quitar la ambigüedad
●
Declarar los requisitos de una manera
consistente ("El sistema" o "El usuario")
●
Especificar la condición o acción que causa que el
sistema lleve a cabo el comportamiento
especificado

●
Evitar el empleo de condicionales ("debería",
"podría", etc), ya que no aclaren si la función es
obligatoria
●
Cuando se indica un requisito en la forma "El
usuario podrá...", identificar el agente específico,
siempre que sea posible (por ejemplo "El
comprador podrá...")
●
Utilizar listas, figuras, gráficos y tablas para
presentar la información visualmente

●
“Aceptable”, “adecuada”
●
Definir lo que constituye la aceptabilidad y la
forma en que el sistema puede juzgar esto
●
“En la mayor medida posible”
●
No dejar que los desarrolladores determinen lo
que es factible
●
“Al menos”, “como mínimo”, “no más de”, “no
superior a“
●
Especificar los valores máximo y mínimo
aceptables
●
“Entre”
●
Definir si los bordes están incluidos en el rango
●
“Depende de”
●
Describir la naturaleza de la dependencia

●
“Eficiente”
●
Definir cuan eficientemente el sistema utiliza
los recursos, la rapidez con que realiza
operaciones específicas, o lo fácil que es para
la gente de usar
●
“Rápido”
●
Especificar la velocidad mínima aceptable a la
que el sistema realiza algún tipo de acción

●
“Mejorado”, “mejor”, “más rápido”, “superior”
●
Cuantificar cuán mejor o más rápido constituye
una mejora adecuada en una determinada
área funcional
●
“Incluyendo”, “incluyendo pero no limitado a”, “y
así sucesivamente”, “etc”, “tal como”
●
La lista de temas debe incluir todas las
posibilidades

●
“Maximizar”, “optimizar”, “minimizar”
●
Establecer los valores máximo y mínimo
aceptables de algún parámetro
●
“Normalmente”, “idealmente”
●
Describir el comportamiento del sistema bajo
condiciones anormales o no ideales
●
“Opcionalmente”
●
Clarificar si se trata de una opción del sistema,
una opción del usuario o una opción del
desarrollador
●
“Razonablemente”, “cuando sea necesario”,
“donde sea apropiado”
●
Explicar cómo seguir este criterio
●
“Robusto”
●
Definir cómo tratará las excepciones el
sistema, y cómo responderá a condiciones
operativas inesperadas
●
“Sin fisuras”, “transparente”, “elegante”
●
Traducir las expectativas de los usuarios en
características específicas del producto
●
“Muchos”
●
Definir cuántos
●
“No debería”
●
Tratar de definir los requisitos positivamente,
describiendo lo que hará el sistema
●
“Estado del arte”
●
Definir lo que significa esto
●
“Suficiente”
●
Definir cuánto de algo se considera suficiente
●
Evitar los párrafos largos que contengan
múltiples requisitos
●
No utilizar "y/o" en un requisito, ya que se deja a
la interpretación del lector
●
Escribir los requisitos evitando restringir
innecesariamente el diseño
●
Evitar declarar requisitos de manera redundante

Resumen
●
Requerimientos
●
del usuario
●
del sistema
●
funcionales
●
no funcionales
●

Resumen
●
●
●
Análisis de requerimientos y negociación
●
Especificación de requerimientos
●
Modelizado del sistema
●
●

Resumen
●
●
Libros y manuales
●
Documentación formal
●
Documentación informal
●
Presentaciones
●
Publicaciones especializadas
●
Investigación
●
Visitas
●
Humanos
Resumen
●
●
Estudio de documentación
●
Entrevistas
●
Observación de Tareas Habituales
●
Incidentes críticos
●
Cuestionarios

Resumen
●
●
Correcta
●
No ambigua
●
Completa
●
Verificable
●
Consistente
●
Comprensible por los consumidores
●
Modificable
●
Independiente del diseño
Resumen
●
Estándares disponibles para una ERS
●
IEEE 830
●
IEEE 29148
●

Unidad 2

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

Unidad 2

Cargado por

Copyright:

Formatos disponibles

Unidad 2 – Requerimientos del software

IS Unidad 2 - Luis Nieto - 2022 2

IS Unidad 2 - Luis Nieto - 2022 3

IS Unidad 2 - Luis Nieto - 2022 4

IS Unidad 2 - Luis Nieto - 2022 5

IS Unidad 2 - Luis Nieto - 2022 6

IS Unidad 2 - Luis Nieto - 2022 7

IS Unidad 2 - Luis Nieto - 2022 8

IS Unidad 2 - Luis Nieto - 2022 9

IS Unidad 2 - Luis Nieto - 2022 10

IS Unidad 2 - Luis Nieto - 2022 11

IS Unidad 2 - Luis Nieto - 2022 12

IS Unidad 2 - Luis Nieto - 2022 13

IS Unidad 2 - Luis Nieto - 2022 14

IS Unidad 2 - Luis Nieto - 2022 15

IS Unidad 2 - Luis Nieto - 2022 16

IS Unidad 2 - Luis Nieto - 2022 17

IS Unidad 2 - Luis Nieto - 2022 18

IS Unidad 2 - Luis Nieto - 2022 19

IS Unidad 2 - Luis Nieto - 2022 20

IS Unidad 2 - Luis Nieto - 2022 21

IS Unidad 2 - Luis Nieto - 2022 22

IS Unidad 2 - Luis Nieto - 2022 23

IS Unidad 2 - Luis Nieto - 2022 24

IS Unidad 2 - Luis Nieto - 2022 25

IS Unidad 2 - Luis Nieto - 2022 26

IS Unidad 2 - Luis Nieto - 2022 27

IS Unidad 2 - Luis Nieto - 2022 28

IS Unidad 2 - Luis Nieto - 2022 29

IS Unidad 2 - Luis Nieto - 2022 30

IS Unidad 2 - Luis Nieto - 2022 31

IS Unidad 2 - Luis Nieto - 2022 32

IS Unidad 2 - Luis Nieto - 2022 33

IS Unidad 2 - Luis Nieto - 2022 34

IS Unidad 2 - Luis Nieto - 2022 35

IS Unidad 2 - Luis Nieto - 2022 36

IS Unidad 2 - Luis Nieto - 2022 37

IS Unidad 2 - Luis Nieto - 2022 38

IS Unidad 2 - Luis Nieto - 2022 39

IS Unidad 2 - Luis Nieto - 2022 40

IS Unidad 2 - Luis Nieto - 2022 41

IS Unidad 2 - Luis Nieto - 2022 42

IS Unidad 2 - Luis Nieto - 2022 43

IS Unidad 2 - Luis Nieto - 2022 45

IS Unidad 2 - Luis Nieto - 2022 46

IS Unidad 2 - Luis Nieto - 2022 47

IS Unidad 2 - Luis Nieto - 2022 48

IS Unidad 2 - Luis Nieto - 2022 49

IS Unidad 2 - Luis Nieto - 2022 50

IS Unidad 2 - Luis Nieto - 2022 51

IS Unidad 2 - Luis Nieto - 2022 52

IS Unidad 2 - Luis Nieto - 2022 53

IS Unidad 2 - Luis Nieto - 2022 54

IS Unidad 2 - Luis Nieto - 2022 55

IS Unidad 2 - Luis Nieto - 2022 56

IS Unidad 2 - Luis Nieto - 2022 57

IS Unidad 2 - Luis Nieto - 2022 58

IS Unidad 2 - Luis Nieto - 2022 59

IS Unidad 2 - Luis Nieto - 2022 60

IS Unidad 2 - Luis Nieto - 2022 61

IS Unidad 2 - Luis Nieto - 2022 62

IS Unidad 2 - Luis Nieto - 2022 63