12 Metodologías en El Desarrollo de Software

Metodologías en el desarrollo de
software
Autor: Mg. Mauricio Galvez Legua
(mgalvez@uni.edu.pe)
Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 1

Introducción
• Las metodologías para el desarrollo de software las
podemos clasificar en dos grandes grupos:
– Metodologías tradicionales o predictivas:
• Popularmente conocidas como waterfall o plan-driven
o procesos dirigidos por un plan.
• Enfocados en el tiempo y costo estimado.
• El cliente solo participa al inicio del desarrollo del sw.
– Metodologías ágiles o incrementales.
• Enfocados en la flexibilidad y mejora continua.
• El cliente participa en todo el proceso de desarrollo del
sw.

El cliente no especifica
Introducción
adecuadamente lo que
realmente requiere. Producto Final
Producto Final Producto Final
Al cliente se le va
presentando prototipos
de lo que requiere.
Prototipo 1 Prototipo 2 Prototipo 3 Prototipo 4

Metodologías Tradicionales o predictivas
• Las metodologías tradicionales o waterfall o basadas
en procesos dirigidos por un plan se desarrollaron en
ambientes empresariales dominados por los
mainframes, los cuales eran sistemas de cómputo
propietarios y caros.

• Tuvieron su auge en las grandes empresas, en donde
la lógica de negocio no cambiaba frecuentemente y
por ende el software podía ser útil por muchos años
sin casi ninguna modificación.
• Esto ocasionó que los desarrollos de software fueran
muy complejos y especializados y que solo la
empresa que comercializaba los mainframes tenia el
conocimiento para realizar tales desarrollos.

• Se difundió la idea que la forma más adecuada para
lograr un mejor software era:
– Mediante una cuidadosa planeación del proyecto.
– Aseguramiento de calidad formalizada.
– El uso de métodos de análisis y el diseño apoyado por
herramientas CASE (Computer Aided Software
Engineering).
– Procesos de desarrollo de software rigurosos (poca
flexibilidad para los cambios) y controlados (ampliamente
documentado)
• Esto se acentuó aún más con el desarrollo de grandes
sistemas de software de larga duración, como los
sistemas aeroespaciales y gubernamentales.

• En muchos casos los equipos de desarrollo estaban
geográficamente dispersos y la elaboración del
software duraba largos periodos de tiempo.
• Un ejemplo de este tipo de software es el sistema de
control de una aeronave moderna, que podía tardar
hasta diez años desde la especificación inicial hasta la
implementación.
El software aeronáutico incluye las funcionalidades
propias de una solución de gestión, además del
mantenimiento de las aeronaves y cuestiones
ingenieras del sector.

• Estas metodologías son una disciplina que tiene
como base una gestión predictiva.
• Con los requisitos iniciales del proyecto, se configura
un plan adecuado empleando recursos y el tiempo
necesarios.
• Durante la fase de desarrollo se comprueba si hay
desviaciones, si las hay, se definen las medidas a
tomar y se valora cuáles son las variaciones que
puede experimentar la planificación original.

• Un enfoque basado procesos dirigidos por un plan
identifica etapas separadas en el proceso de
software con salidas asociadas a cada etapa.
– Las salidas de una etapa se usan como base para planear la
siguiente actividad del proceso.
– La iteración ocurre dentro de las actividades con
documentos formales usados para comunicarse entre
etapas del proceso.
Documento Documento Documento

1 2 3

“Las metodologías tradicionales, normalmente se
relacionan al modelo cascada simple (waterfall)”
Análisis y
Desarrollo o Pruebas o Despliegue y
definición de Diseño
Implementación Verificación Mantenimiento
requisitos

• Las metodologías tradicionales o basadas en
procesos dirigidos por un plan, incluyen costos
operativos significativos en la planeación, el diseño y
la documentación del sistema.
– En algunos tipos de software, como los sistemas de control
críticos para la seguridad, donde es esencial un análisis
completo del sistema, resulta justificable dichos costos.

Metodologías Tradicionales

Metodologías Tradicionales:
características
• Los requisitos son fundamentales y deben estar bien definidos
al inicio del proyecto.
• Se supone que en el proyecto, no va a surgir ningún tipo de
modificación, por lo tanto no está sujeto a modificaciones.
• Se basa en procesos.
• Gestión predictiva (se sabe de antemano, el tiempo y costo).
• El desarrollo del software se define en fases cuyo conjunto se
denomina “ciclo de vida”.
• Documentación exhaustiva de todo el proyecto. Los proyectos
suelen estar bien documentados.
• Se enfocan en obtener el software en tiempo y coste
establecido.

Metodologías Tradicionales: ventajas
• La gestión de proyectos en cascada o waterfall
permite:
– Planificar los proyectos con anticipación para evitar la
corrupción del alcance.
– Realizar un “fácil” seguimiento del progreso en las
diferentes fases del proyecto.
– Trabajar en varios proyectos sin estar completamente
dedicado a uno en particular.
– Gestionar las dependencias fácilmente.

Metodologías Tradicionales: desventajas
• Esta metodología también tiene algunas desventajas
que es importante tener en cuenta:
– Puede conducir a un mayor riesgo del proyecto debido a la
falta de flexibilidad.
– Puede provocar la pérdida de información si diferentes
personas trabajan en el proyecto durante las diferentes
fases y no se documenta con claridad.
– Puede provocar errores inesperados si los controles de
calidad se realizan tarde.
– Puede disminuir la satisfacción del cliente por su poca o
nula participación en el proyecto.

“Ley” de Brooks
• Frederick Phillips Brooks, es un
ingeniero de software y científico
de la computación que trabajó en
IBM y dirigió el desarrollo del
sistema operativo OS/360 (uno de
los proyectos de software más
grandes de la historia).

“Ley” de Brooks
• Basado en esa experiencia escribió un libro de
administración de proyectos de ingeniería de
software denominado The Mythical Man-Month:
Essays on Software Engineering (Mítico Hombre-
Mes: Ensayos de ingeniería de Software) en donde
contaba anécdotas del desarrollo del OS/360 y en
donde afirmó su famosa Ley de Brooks:
“Añadir recursos humanos a un proyecto retrasado lo
hace demorarse aún más”

“Ley” de Brooks

Cambio y Complejidad
• En el año 2001, diecisiete personas se reunieron y
crearon lo que conocemos hoy como el Manifiesto
Ágil, el cual sentaría las bases para las metodologías
ágiles que surgirían formalmente después, como
Scrum, XP, DSDM, Crystal, entre otros.

Manifiesto Ágil
• A causa de las metodologías ágiles, que estaban
surgiendo, se definieron los 4 postulados que dan
origen al “Manifiesto Ágil”, el cual propugnaba
“mejores formas de desarrollar software”.

Manifiesto Ágil

Manifiesto Ágil
• Del manifiesto ágil, se desprende doce principios:
1. Nuestra mayor prioridad es satisfacer al cliente mediante la
entrega temprana y continua de software con valor.
2. Aceptamos que los requisitos cambien, incluso en etapas
tardías del desarrollo. Los procesos Ágiles aprovechan el
cambio para proporcionar ventaja competitiva al cliente.
3. Entregamos software funcional frecuentemente, entre dos
semanas y dos meses, con preferencia al periodo de tiempo
más corto posible.
4. Los responsables de negocio y los desarrolladores trabajamos
juntos de forma cotidiana durante todo el proyecto.
5. Los proyectos se desarrollan en torno a individuos motivados.
Hay que darles el entorno y el apoyo que necesitan, y confiarles
la ejecución del trabajo.

Manifiesto Ágil
6. El método más eficiente y efectivo de comunicar información al
equipo de desarrollo y entre sus miembros es la conversación cara a
cara.
7. El software funcionando es la medida principal de progreso.
8. Los procesos Ágiles promueven el desarrollo sostenible. Los
promotores, desarrolladores y usuarios debemos ser capaces de
mantener un ritmo constante de forma indefinida.
9. La atención continua a la excelencia técnica y al buen diseño mejora
la Agilidad.
10. La simplicidad, o el arte de maximizar la cantidad de trabajo no
realizado, es esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos
auto-organizados.
12. A intervalos regulares el equipo reflexiona sobre cómo ser más
efectivo. Esto permite ajustar y perfeccionar su comportamiento en
consecuencia (mejora continua).

• Estas personas encontraron problemas comunes en
la implementación de sus proyectos de software, los
cuales se podían diferenciar de los proyectos
comunes.
• Se llegó a diferenciar los proyectos de software de
otros proyectos en base al nivel de incertidumbre o
complejidad. Por ejemplo: no es lo mismo construir
una carretera, luego de hacerlo mil veces, que
construir un software para resolver un problema
específico y que jamás se ha realizado.

• El cambio y la complejidad es una forma útil de
analizar y determinar la mejor forma de desarrollar
software:

• Las diferentes zonas proporcionan un medio simple
para categorizar las condiciones para el desarrollo de
un software:
– Las metodologías ágiles surgieron con el fin de gestionar la
dimensión del cambio, por lo que su aplicación esta en las
zonas uno y dos.
– Las metodologías tradicionales son apropiadas para la
gestión de programas de desarrollo complejos a gran
escala, por lo que se adaptan bien a las zonas uno y tres,
donde la baja volatilidad del cambio permite una
planificación más detallada.

• En el caso del cuadrante uno, donde el cambio y la
complejidad son bajos se puede elegir cualquier
metodología.
• El problema esta en la zona cuatro, en donde una
combinación de metodologías puede ser la solución.

Metodologías Ágiles o incremental
• Actualmente las empresas operan en un entorno
global que cambia rápidamente y por ello deben
responder frente a nuevas oportunidades y
mercados así como al surgimiento de productos y
servicios competitivos.
• Tecnologías como la globalización, el internet y las
telecomunicaciones han propiciado estos cambios.

• El software, que es parte importante en todas las
áreas de una empresa, debe tener capacidad de
desarrollarse y adaptarse rápidamente a estos
entornos cambiantes.
• Actualmente el desarrollo y la entrega rápida son por
lo general el requerimiento fundamental de los
sistemas de software.

• Actualmente, muchas empresas están dispuestas a
negociar en nivel de calidad del software y el
compromiso con los requerimientos, para obtener
con mayor rapidez la implementación que necesitan
del software.

• Debido a que las empresas operan en entornos
cambiantes, a menudo es prácticamente imposible
derivar un conjunto completo de requerimientos
para el desarrollo del software.
• Los procesos de desarrollo de software que buscan
especificar por completo los requerimientos y luego
diseñar, construir y probar el sistema, no están
orientados al desarrollo rápido de software.

• En las metodologías ágiles, el software no se
desarrolla como una sola unidad, sino como una serie
de incrementos (sprints), y cada uno de ellos incluye
nuevas funcionalidad del sistema.
Análisis y
Desarrollo o Pruebas o Despliegue y
definición de Diseño
Implementación Verificación Mantenimiento
requisitos

• Las metodologías ágiles se basan en ciclos de vida de
software incremental, donde rara vez se trabaja por
“adelantado” una solución completa del problema.

• Se avanza en una serie de pasos hacia una solución y
se retrocede cuando se detecta que se cometieron
errores o ante nuevos cambios por parte del usuario.
• Esto permite reducir los costos y facilita la realización
de cambios en el software conforme éste se va
desarrollando.

• Involucran a los clientes en el proceso de desarrollo
para lograr una rápida retroalimentación sobre los
requerimientos cambiantes.
La participación del cliente es fundamental.
• Minimizan la cantidad de documentación con el uso
de comunicaciones informales, en vez de reuniones
formales con documentos escritos.

• Las metodologías ágiles son más efectivas cuando el
sistema logra diseñarse con un pequeño equipo
asignado que se comunique de manera informal.

• Las metodologías ágiles proporcionan una visión más
dinámica que las metodologías tradicionales.
• Su característica principal es que permiten cambios
en los requisitos en cualquier fase del desarrollo; es
más, esos cambios son bienvenidos.

• La máxima prioridad es la satisfacción del cliente, por
lo cual se le debe estar entregando resultados
evaluables de forma continua con los que se va
midiendo el progreso del proyecto.
• Es importante que tanto el cliente, usuario y los
desarrolladores trabajen juntos durante el desarrollo
del proyecto, por lo que el cliente debe tener
disponibilidad para ello.

• La característica nueva que aportan estas
metodologías es reconocer a las personas como el
principal valor para que un proyecto consiga
terminarse de forma correcta.
“El factor más importante en el desarrollo de software
no son las técnicas ni las herramientas que emplean los
programadores, sino la calidad de los programadores.”
(Robert. L. Class).

• Podemos deducir que las metodologías ágiles a
diferencia de las metodologías tradicionales son más
adecuadas cuando el entorno presenta una cierta
incertidumbre o es cambiante.

• Los equipos de las metodologías ágiles deben auto-
organizarse entre ellos, reunirse y reflexionar
frecuentemente sobre cómo ser más eficaces y
mejorar la calidad técnica. En este sentido, el
compromiso del equipo de proyecto debe ser fuerte.

Metodologías Ágiles o incremental:
características
• Rápida, específica y dinámica.
• Estimula las actitudes y estructuras del equipo, pues
hace más fácil la comunicación.
• Considera al cliente como parte del equipo de
desarrollo.
• Las entregas son rápidas y continuas.
• Su estructura se adecua al cambio.

Metodologías Ágiles: ventajas
• La metodología ágil permite:
– Adaptarse rápidamente a los cambios inesperados.
– Centrarse en la satisfacción del cliente.
– Lograr una gran motivación intrínseca al centrarse en el
trabajo en equipo y la participación de los miembros.

Metodologías Ágiles: desventajas
• Toda la flexibilidad inherente a la metodología ágil
puede:
– Aumentar la corrupción del alcance y el presupuesto del
proyecto de forma inesperada.
– Dificultar la interacción con los clientes si no se tiene el
tiempo o la disponibilidad necesaria.
– Hacer difícil a los equipos virtuales prosperar en entornos
ágiles.
– Al centrarse exclusivamente en el proceso de sprint, el
equipo no podrá trabajar en otros proyectos.

Comparación entre Tradicional y Ágil
Sprint



Tipos de Metodologías Ágiles
• Actualmente existen varios tipos de metodologías
ágiles como:
– Scrum
– XP o Programación extrema
– Kanban
– Etc.

Metodologías Ágiles: Scrum
• Consiste en trabajar por iteraciones o también
llamados “sprints”, que suelen durar normalmente
una semana.
– Durante este periodo, se ejecutan las actividades
necesarias según el requerimiento planteado para esa
semana.
– Cada día se van teniendo reuniones donde comprobar lo
que se va haciendo y resolver los problemas que se
presenten.

Metodologías Ágiles: Scrum
• Se trata de ir ajustando los resultados y
respondiendo a las exigencias reales y exactas del
cliente.

Metodologías Ágiles: XP
• Esta metodología XP (Extreme Programming), se
caracteriza por brindar una flexible adaptabilidad a
cualquier modificación o cambios de los requisitos en
cualquier fase del proyecto, con la finalidad, de
ofrecer a los clientes “lo que quieren y cuando lo
quieren”.
Pensando bien,
lo que quiero es
un submarino !!!

• Se aplica a proyectos muy complejos con un nivel
muy elevado de incertidumbre. El criterio abarca la
adaptación constante de los procesos hasta que
alcanzan el resultado deseado.
• Estos proyectos incluyen muchos cambios y es
normal que los equipos cambien de estrategias de
una semana a la siguiente.

• Para aplicar la gestión extrema de proyectos hay que
tener una amplia flexibilidad. Es uno de los motivos
por el cual los sprints debe ser cortos, como máximo
durar unas pocas semanas.
• La metodología XP ofrece la posibilidad de realizar
cambios con mucha frecuencia, de abordar prácticas
de prueba y error para resolver problemas, y de
implementar muchas iteraciones para la
autocorrección.

• El enfoque de la XP
mantiene como
fundamento cinco valores
principales: simplicidad,
comunicación,
retroalimentación,
valentía o coraje y
respeto.

• El proceso de la XP se basa en cuatro actividades
estructurales principales: planeación, diseño,
codificación y pruebas.

Metodologías Ágiles: Kanban
• Se centra en la planificación adaptativa, la entrega
temprana y la mejora continua.
• Su objetivo es gestionar de manera general cómo se
van completando las tareas en un proceso de
desarrollo de software.

• Kanban es una palabra japonesa que significa
“tarjetas visuales” (Kan es “visual” y Ban “tarjeta”).

• Se basa en una serie de principios que la diferencian
del resto de metodologías conocidas como ágiles:
– Calidad garantizada: Todo lo que se hace debe salir bien a
la primera, no hay margen de error. De aquí a que en
Kanban no se premie la rapidez, sino la calidad final de las
tareas realizadas. Esto se basa en el hecho que muchas
veces cuesta más arreglarlo que hacerlo bien a la primera.

– Reducción del desperdicio: hacer solamente lo justo y
necesario, pero hacerlo bien. Esto supone la reducción de
todo aquello que es superficial o secundario (principio
YAGNI).
– Mejora continua: no es simplemente un método de
gestión, sino también un sistema de mejora en el
desarrollo de proyectos, según los objetivos a alcanzar.
– Flexibilidad: existen tareas pendientes acumuladas
(backlog), sin embargo es posible priorizar aquellas tareas
entrantes según las necesidades del momento (capacidad
de dar respuesta a tareas imprevistas).

Punto comunes entre Scrum y Kanban
• Kanban y Scrum son las dos metodologías ágiles más
comunes. Entre sus “puntos comunes” citamos:
– Ambas motivan a los equipos a adoptar la mejora
continua.
– Ambas son excelentes herramientas de colaboración en
equipo. Propicia el trabajo en equipo.

Diferencias entre Scrum y Kanban
• Scrum es más estricto que Kanban:
– Scrum incluye un conjunto específico de reglas que los
equipos deben seguir, mientras que Kanban se usa más
para visualizar el trabajo.
– Muchos equipos implementan Scrum con un tablero
Kanban, pero en esos casos, la metodología sigue siendo
Scrum, no Kanban.
– Kanban es más que una metodología estricta, es una forma
de visualizar el trabajo.

• Scrum es más restrictivo en tiempo, Kanban es más
flexible:
– Scrum se ejecuta en sprints, que suelen ser ciclos de
trabajo de una o dos semanas. Al final de un sprint, se
tiene un conjunto de tareas terminadas, sin importar
cuáles sean.
– Los tableros Kanban no necesariamente tienen una fecha
de inicio o finalización.

• Las columnas del tablero Kanban se pueden
organizar de diferentes formas:
– Cuando se implementa Scrum, es importante realizar un
seguimiento del trabajo a medida que se avanza por las
diferentes etapas. Sin embargo, en un tablero Kanban que
no se basa en Scrum, las columnas pueden representar
diferentes aspectos de un proyecto como por ejemplo, el
trabajo que se realizará cada mes, las tareas que se
completaron anteriormente, o cualquier otra cosa que se
necesite.

Comparación entre Scrum y Kanban

Combinación Scrum y Kanban
• Para organizar reuniones de actualización diarias
eficaces, planificar sprints y realizar análisis
retrospectivo relevantes, se requiere de un medio
para visualizar el trabajo a través de las diferentes
etapas y para realizar un seguimiento de todo el
trabajo en curso.
– Los tableros Kanban pueden ayudar a abordar el trabajo
pendiente de los sprints y organizar el flujo de trabajo
durante un sprint.

Combinación Scrum y Kanban
• Los equipos que implementan Scrum en tableros
Kanban (a veces denominados tableros Scrum),
suelen crear un tablero nuevo para cada sprint por
dos razones principales:
– Con un nuevo tablero Kanban se puede comenzar “desde
cero”. Esto hace que sea más fácil visualizar el trabajo
nuevo que se debe completarse en cada sprint.
– Seguimiento al trabajo realizado durante cada sprint para
visualizar qué se ha logrado.

Comparación entre Waterfall, Scrum y
Kanban

Metodologías Híbridas
• El éxito de las metodologías ágiles condujo a cierta
integración con las metodologías tradicionales de
desarrollo, basados en el modelado de sistemas.
Ejemplo:
– RUP (Rational Unified Process) o Proceso Racional
Unificado.
• Otra metodología híbrida es Scrumban, la cual es el
combinación de Scrum y Kanban.

Fin !!!
Autor: Mg. Mauricio Galvez Legua

(mgalvez@uni.edu.pe)

12 Metodologías en El Desarrollo de Software

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

12 Metodologías en El Desarrollo de Software

Cargado por

Copyright:

Formatos disponibles

Metodologías en el desarrollo de

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 1

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 2

Producto Final Producto Final

Prototipo 1 Prototipo 2 Prototipo 3 Prototipo 4

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 4

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 5

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 6

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 7

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 8

Documento Documento Documento

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 9

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 10

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 11

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 12

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 13

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 14

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 15

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 16

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 17

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 18

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 19

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 20

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 21

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 22

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 23

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 24

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 25

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 26

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 27

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 28

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 29

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 30

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 31

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 32

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 33

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 34

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 35

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 36

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 37

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 38

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 39

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 40

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 41

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 42

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 43

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 44

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 45

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 46

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 47

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 48

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 49

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 50

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 51

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 52

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 53

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 54

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 55

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 56

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 57

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 58

Autor: Mauricio Galvez Legua (mgalvez@uni.edu.pe) 59