UNIVERSIDAD NACIONAL DE PIURA

FACULTAD DE INGENIERÍA INDUSTRIAL

PROGRAMA DE ACTUALIZACIÓN PROFESIONAL EN INGENIERÍA INFORMÁTICA XXI-2020

TRABAJO DE INVESTIGACIÓN PRESENTADO PARA OPTAR EL

TÍTULO PROFESIONAL DE INGENIERO INFORMÁTICO

ANÁLISIS COMPARATIVO ENTRE WATERFALL Y DEVOPS EN EL

DESARROLLO DEL MICROSERVICIO “OBTENER DETALLE DE LIBROS
EN TIENDA VIRTUAL”

Presentado por:
Bravo Ramírez, Miguel Angel
Huasasquiche Calmet, Pier Miguel
Ojeda Monzón, Cristha Patricia

Línea de investigación:
Informática, electrónica y telecomunicaciones

Sublínea de investigación:
Computación

PIURA - PERÚ
2020

2
 UNIVERSIDAD NACIONAL DE PIURA
FACULTAD DE INGENIERÍA INDUSTRIAL
ESCUELA PROFESIONAL DE INGENIERÍA INFORMÁTICA

TRABAJO DE INVESTIGACION
“ANÁLISIS COMPARATIVO ENTRE WATERFALL Y DEVOPS EN EL
DESARROLLO DEL MICROSERVICIO “OBTENER DETALLE DE LIBROS
EN TIENDA VIRTUAL””

Presentado por:

Mg. Ing. Jorge Alvarado Tabacchi Br. Bravo Ramírez, Miguel Angel
Asesor Tesista

Br. Huasasquiche Calmet, Pier Miguel Br. Ojeda Monzón, Cristha Patricia
Tesista Tesista

PIURA - 2021
 DECLARACIÓN JURADA
DE ORIGINALIDAD DE TRABAJO DE INVESTIGACIÓN

Yo: BRAVO RAMIREZ MIGUEL ANGEL identificado con DNI N° 73359691, en la

condición de Egresado de la Facultad de Ingeniería Industrial, Escuela Profesional
de Ingeniería Informática y domiciliado en Avenida Angamos 1559, Distrito
Surquillo, Provincia de Lima, Departamento de Lima, Celular: 943824375, Email:
miguel030993@gmail.com.

Yo: HUASASQUICHE CALMET PIER MIGUEL identificado con DNI N° 45919486,

en la condición de Egresado de la Facultad de Ingeniería Industrial, Escuela
Profesional de Ingeniería Informática y domiciliado en Jr. Cuzco 708, Distrito
Catacaos, Provincia de Piura, Departamento de Piura, Celular: 991566122, Email:
piermiguel21@gmail.com.

Yo: CRISTHA PATRICIA OJEDA MONZÓN identificado con DNI N° 46304880, en

la condición de Egresado de la Facultad de Ingeniería Industrial, Escuela
Profesional de Ingeniería Informática y domiciliado en Jr. Montero Rosas 1333 dpto
801 Urb.Santa Beatriz, Distrito Cercado de Lima, Provincia Lima, Departamento de
Lima, Celular: 942465134, Email: crista.f26@gmail.com.

DECLARAMOS BAJO JURAMENTO: que el trabajo de investigación que presento

a la Oficina Central de Investigación (OCIN), es original, no siendo copia parcial ni
total de un trabajo de investigación desarrollado, y/o realizado en el Perú o en el
Extranjero, en caso de resultar falsa la información que proporciono, me sujeto a los
alcances de lo establecido en el Art, Nª411, del código Penal concordante con el
Art. 32ª de la Ley Nª 27444 y Ley del Procedimiento Administrativo General y las
Normas Legales de Protección a los Derechos de Autor.
En fe de lo cual firmo el presente.
Piura,25 de noviembre de 2020

-------------------------------- -------------------------------- -----------------------------

DNI: 73359691 DNI: 45919486 DNI: 46304880

Articulo 411.- El que, en un procedimiento administrativo, hace una falsa declaración en relación a hechos o
circunstancias que le corresponde probar, violando la presunción de veracidad establecida por ley, será reprimido
con pena privativa de libertad no menor de uno ni mayor de 4 años.
Art. 4. Inciso 4.12 del Reglamento del Registro Nacional de Trabajos de Investigación para optar grados académicos
y títulos profesionales –RENATI Resolución de Consejo Directivo Nº 033-2016-SUNEDU/CD.
 UNIVERSIDAD NACIONAL DE PIURA
FACULTAD DE INGENIERIA INDUSTRIAL
ESCUELA PROFESIONAL DE INGENIERIA INFORMATICA

TRABAJO DE INVESTIGACION

“ANÁLISIS COMPARATIVO ENTRE WATERFALL Y DEVOPS EN EL

DESARROLLO DEL MICROSERVICIO “OBTENER DETALLE DE LIBROS
EN TIENDA VIRTUAL””

Línea de Investigación:
INFORMÁTICA, ELECTRÓNICA Y TELECOMUNICACIONES
SUBLINEA: COMPUTACIÓN

APROBADA POR LOS

JURADOS:

_________________________________
Dr. Rigo Félix Requena Flores
PRESIDENTE

____________________________________
Dr. Nestor Javier Zapata Palacios
SECRETARIO

____________________________________
Ing. Luis Alberto Calderón Pinedo
VOCAL
 DEDICATORIA

El presente trabajo lo dedico principalmente a Dios, por ser

el inspirador y darme la fuerza para continuar en este
proceso de obtener uno de los anhelos más deseados.
A mis padres, por su amor, trabajo y sacrificio en todos estos
años, gracias a ustedes he logrado llegar hasta aquí.
A mi hijo, por siempre impulsarme a ser mejor.
A mi novio, por su paciencia y amor incondicional.
A todas las personas que me apoyaron y han hecho que
este trabajo se realice con éxito en especial a aquellos que
nos abrieron las puertas y compartieron sus conocimientos.
 AGRADECIMIENTOS

Quiero expresar mi gratitud a Dios, quien con

su bendición llena siempre mi vida y a toda mi
familia por estar siempre presente.
También quiero agradecer a la Universidad
Nacional de Piura, directivos y profesores por
la organización del Programa de Actualización.
 “Año de la Universalización de la Salud”

Quien suscribe, Ing. Jorge Alvarado Tabacchi con Documento Nacional de Identidad
N°02606057, mediante la presente manifiesto que he leído y revisado de manera
detallada el proyecto de investigación titulado: “ANÁLISIS COMPARATIVO
ENTRE WATERFALL Y DEVOPS EN EL DESARROLLO DEL
MICROSERVICIO “OBTENER DETALLE DE LIBROS EN TIENDA
VIRTUAL””, presentado por el(los) tesista(s) Bach. Bravo Ramirez Miguel Angel
identificado con documento de identidad N° 73359691, Bach. Huasasquiche Calmet
Pier Miguel con documento de identidad N° 45919486, Bach. Ojeda Monzón Cristha
Patricia con documento de identidad N° 46304880, egresados de la carrera
profesional de informática, para optar el título de profesional de Ingeniero
Informático.
En mi condición de asesor, considero que el mencionado proyecto, cumple con lo
establecido en el Reglamento de Tesis para optar el título profesional en la UNP y
recomiendo su ejecución por lo que me comprometo a asesorar hasta la
sustentación y publicación, si fuera el caso.

Piura - Perú, Miércoles, 25 de Noviembre de 2020

____________________________________________________________
Mg. Ing. Jorge Alvarado Tabacchi
Asesor
 ÍNDICE
ÍNDICE DE FIGURAS 10
ÍNDICE DE TABLAS 12
RESUMEN 13
ABSTRACT 14
INTRODUCCIÓN 15
CAPITULO I. ASPECTOS DE LA PROBLEMÁTICA 16
1.1. DESCRIPCIÓN DE LA REALIDAD PROBLEMÁTICA 17
1.2. FORMULACIÓN DEL PROBLEMA DE INVESTIGACIÓN 17
1.3. JUSTIFICACIÓN E IMPORTANCIA DE LA INVESTIGACIÓN 17
1.4. OBJETIVOS 18
1.4.1. Objetivo general 18
1.4.2. Objetivos específicos 18
1.5. DELIMITACIÓN ESPACIAL Y TEMPORAL DE LA INVESTIGACIÓN 18
1.5.1. Delimitación Espacial 18
1.5.2. Delimitación Temporal 18
1.5.3. Delimitación Conceptual 19

CAPITULO II. MARCO TEÓRICO 20

2.1. ANTECEDENTES DE LA INVESTIGACIÓN 21
2.1.1. Internacionales 21
2.1.2. Nacionales 21
2.2. BASES TEÓRICAS 22
2.2.1. Ingeniería de software 22
2.2.2. Metodologías de desarrollo de software 23
2.2.2.1. Waterfall 23
2.2.2.2. DevOps 24
2.2.3. Microservicios 26
2.2.4. Aplicación Web 27
2.3. GLOSARIO DE TÉRMINOS BÁSICOS 27
2.4. HIPÓTESIS 29

CAPITULO III. MARCO METODOLÓGICO 30

3.1. ENFOQUE Y DISEÑO 31
3.1.1. Enfoque 31
3.1.2. Diseño 31
3.2. SUJETO DE LA INVESTIGACIÓN 31
3.3. MÉTODOS Y PROCEDIMIENTOS 31
3.3.1. Aplicación de la metodología Waterfall 31
3.3.2. Aplicación de la metodología DevOps 45
 3.3.3. Análisis de metodologías 56
3.4. ASPECTOS ÉTICOS 60

CAPITULO IV. RESULTADOS Y DISCUSIÓN 61

4.1. RESULTADOS 62
4.2. DISCUSIÓN 63
CONCLUSIONES 64
RECOMENDACIONES 65
REFERENCIAS BIBLIOGRÁFICAS 66
ANEXOS 68
ÍNDICE DE FIGURAS

Figura 1. Esquema metodología Waterfall 23

Figura 2. Ciclo DevOps 25
Figura 3. Patrón básico de arquitectura de Microservicios 26
Figura 4: Modelo de dominio de la base de datos 32
Figura 5: Arquitectura de aplicación web con microservicios 34
Figura 6: Diagrama de secuencia Buscar libros mediante la web 35
Figura 7: Patrón de diseño Modelo - Vista – Controlador 35
Figura 8: Solución del aplicativo en Visual Studio 37
Figura 9: Cliente PgAdmin Postgres Sql 38
Figura 10: Creación del proyecto Apache NetBeans 39
Figura 11: Configuración del microservicio en Apache NetBeans 40
Figura 12: Configuración del microservicio en Apache NetBeans 41
Figura 13: Configuración del microservicio en Apache NetBeans 41
Figura 14: Configuración del microservicio en Apache NetBeans 42
Figura 15: Response del microservicio en Apache NetBeans 42
Figura 16: Log del microservicio 43
Figura 17: Herramienta BitBucket para le versionamiento de código 43
Figura 18: Implementación del framework 46
Figura 19: Dockerización del proyecto 47
Figura 20: Despliegue del proyecto Infrastructure as Code 47
Figura 21: Arquitectura propuesta para DevOps 48
Figura 22: Herramienta Jira de monitoreo de código 49
Figura 23: Herramienta Velocity Chart 50
Figura 24: Herramienta Burndown 50
Figura 25: Herramienta BitBucket de monitoreo 51
Figura 26: Desarrollo de microservicio en Apache NetBeans 51

10
Figura 27: Estructura del proyecto 52
Figura 28: Archivo despliegue de la aplicación 53
Figura 29: Herramienta de monitoreo BitBucket 53
Figura 30: Herramienta de monitoreo “Sprint Boot Admin” 54

11
ÍNDICE DE TABLAS

Tabla 1. Estimación de horas dedicadas 32

Tabla 2. Descripción Caso de Uso: Iniciar aplicación 33
Tabla 3. Descripción Caso de Uso: Mostrar detalle libro 33
Tabla 4. Requerimientos funcionales de la etapa de construcción 36
Tabla 5. Requerimientos no funcionales de la etapa de construcción 36
Tabla 6. Horas reales del proyecto 44
Tabla 7. Tabla de Prioridades 48
Tabla 8. Tabla de Historias de usuario 49
Tabla 9: Horas reales del proyecto 54
Tabla 10. Cuadro comparativo de las metodologías Waterfall y DevOps 60
Tabla 11. Cuadro comparativo de las metodologías 62
Tabla 12. Matriz de consistencia de la operacionalización de las variables 68

12
RESUMEN

El propósito de la investigación fue realizar un cuadro comparativo de las

metodologías Waterfall y DevOps en el desarrollo de un microservicio para la
búsqueda del detalle de libros en una Tienda Virtual. Debido a la pandemia los
negocios locales se han visto obligados a buscar alternativas para potenciar las
ventas electrónicas. En el presente caso se detalla un negocio de venta digital de
libros “Inti Libros” que tiene como proceso principal mostrar a sus posibles clientes
las descripciones y reseñas de los libros de su interés.
La investigación tiene un enfoque cuantitativo y de diseño es no experimental de
tipo transversal ya que cuando el investigador se limita a medir los acontecimientos
sin intervenir en los mismos entonces se desarrolla una investigación no
experimental y se dice que es de tipo transversal porque tiene como propósito
describir variables y analizar su incidencia en un momento dado.
Como resultados, se logró desarrollar el cuadro comparativo identificando los
tiempos de entrega de cada una de las fases de las metodologías donde se tiene
una mejora del 66% utilizando la metodología DevOps. Para el desarrollo se utilizó
Postgres Sql, Visual Studio y Apache NetBeans.
Palabras calve: Microservicio, Venta digital, cuadro comparativo.

13
ABSTRACT

The purpose of this research is to create a comparative table between two

methodologies: Waterfall and DevOps, as we make a development of a
microservice. The main function of this microservice is to search on the details of
books (description, author, editorial, etc) in an e-commerce. Due to the Worldwide
Pandemic, small business are forced to search new alternatives in order to improve
their e-commerce. This case is about a Bookstore e-commerce called “Inti Libros”
that has as main process showing to his possible customers the descriptions and
reviews of the books their customers are searching for.

This research will have a quantitative approach and a non-experimental desing. We

will focus on collecting data without participating in the events. Also, the main
purpose is to describe the variables and their incidence at a certain event.

At the end, you will find a comparative table between the lead time of each phase
from Waterfall and DevOps. As a conclusion, you will find an improvement of 66%
using DevOps instead of Waterfall. For the development of this microservice I
worked with Postgres Sql, Visual Studio y Apache NetBeans.

Keywords: Microservice, E-coomerce, comparative table.

14
INTRODUCCIÓN

Durante los últimos años, se han realizado cambios en el ciclo de desarrollo de

software hacia una forma más ágil y colaborativa de trabajar. Los equipos ágiles se
responsabilizan de la consecución de requerimientos en un conjunto
multidisciplinar, donde la parte de negocio y la parte de desarrollo aparecen
representadas en un solo proyecto.
A diferencia de la metodología tradicional que se vuelve completamente ineficiente
cuando se requiere de un sistema escalable y resiliente, la metodología DevOps
plantea una visión integrada en el desarrollo del software que permite implementar
cambios de manera rápida y segura, garantizando la fiabilidad en las operaciones.
El presente trabajo pretende construir un microservicio para obtener el detalle de
libros en una tienda virtual utilizando para ello herramientas open source
apoyándose en la metodología DevOps y comparándolo con la metodología
tradicional.
El objetivo, por lo tanto, será demostrar que la metodología DevOps puede
ayudarnos con el desarrollo de un microservicio y responder a las necesidades del
negocio reduciendo los tiempos de entrega de software funcional en comparación a
la metodología tradicional y en consecuencia optimizando los recursos.

15
 CAPITULO I.
ASPECTOS DE LA
PROBLEMÁTICA

16
DESCRIPCIÓN DE LA REALIDAD PROBLEMÁTICA.

Debido a la pandemia los negocios locales se han visto obligados a buscar

alternativas para potenciar las ventas electrónicas. En el primer trimestre del
2020, era escaso el número de librerías que contaban con formato e-commerce;
uno de los efectos positivos de la pandemia originado por el covid-19, es la
virtualización de los negocios para seguir vigentes en el mercado. Por otro lado,
hay empresas que ya contaban con venta online, sin embargo, no cuentan con
una plataforma eficiente y/o amigable que les permita maximizar sus ventas.

El acelerado crecimiento obliga a que las aplicaciones y servicios que ofrecen

las empresas sean diseñados con capacidades que soporten accesos
simultáneos y masivos de los usuarios, disponibilidad continua a lo largo del
año, y con mejoras constantes que agreguen funcionalidades pedidas por los
usuarios en cada actualización. Es en este contexto donde la computación en
la nube se volvió una pieza fundamental para el desarrollo de este tipo de
aplicaciones.

La necesidad de implementar nuevas metodologías en el mantenimiento del

aplicativo web surge porque los tiempos de ciclo de ejecución de los pases a
los diferentes ambientes (desarrollo, pruebas y producción) tardan días e
incluso semanas en lugar de horas y/o minutos, adicionalmente no existe un
control de versiones de las configuraciones que desencadena en un ineficiente
control de versiones de los releases.

En el presente caso se detalla un negocio de venta digital de libros “Inti Libros”

que tiene como proceso principal mostrar a sus posibles clientes las
descripciones y reseñas de los libros de su interés.

FORMULACIÓN DEL PROBLEMA DE INVESTIGACIÓN.

¿Qué metodología de desarrollo se puede implementar de forma exitosa en la

elaboración de un microservicio para obtener detalle de libros?

JUSTIFICACIÓN E IMPORTANCIA DE LA INVESTIGACIÓN

La presente investigación pretende descubrir cómo la metodología DevOps que

complementan los métodos pueden ser evaluadas con el fin de proporcionar un
mejor esquema de trabajo para generar valor a los procesos y con ellos a los
negocios en comparación a los métodos tradicionales.

La implantación de la metodología DevOps ha supuesto un avance en los

procesos de desarrollo de software y su implementación. Es cada vez más

17
exigente el “Time to Market” y surge la necesidad de que la calidad y la agilidad
en el Ciclo de vida de Desarrollo de software estén cada vez más unidos, y por
ellos la solución idónea es la automatización de todas las fases de construcción
y testeo del código; o lo que es lo mismo: La integración continua (CI).

Se plantea entonces la pregunta: ¿Qué ventajas comparativas tiene una con

respecto a la otra? ¿En qué situaciones es recomendable usar cada una de
ellas? Se procederá a escoger un marco de trabajo o metodología que se acople
de mejor manera al desarrollo de un microservicio en función de sus
características, por lo tanto, la importancia de la investigación radica en
entender las ventajas y desventajas de cada una de las metodologías
orientadas al desarrollo de un microservicio para mejorar la productividad de los
equipos involucrados en el proceso de implementación de software.

OBJETIVOS

. Objetivo general

Realizar un estudio comparativo de las metodologías de desarrollo

Waterfall y Devops para determinar qué metodología se acopla de mejor
manera para el desarrollo óptimo de un microservicio.

. Objetivos específicos

Precisar en qué medida el proceso de desarrollo basado en DevOps

mejora los tiempos de entrega del microservicio en comparación a
Waterfall.
Definir cómo influye el proceso de desarrollo basado en DevOps en la
optimización de la calidad del proceso en el desarrollo de un microservicio
en comparación a Waterfall.
Analizar la metodología de desarrollo óptimo para la elaboración de un
microservicio.

DELIMITACIÓN ESPACIAL Y TEMPORAL DE LA INVESTIGACIÓN.

1.5.1. Delimitación espacial

Clientes del negocio de venta digital de libros “Inti Libros”.

1.5.2. Delimitación temporal

El presente proyecto de investigación se llevará a cabo desde el mes de

Noviembre hasta Marzo del año 2021 para lo cual se tendrá que recopilar
los datos necesarios para su conclusión.

18
1.5.3. Delimitación conceptual

Para conseguir esta nueva funcionalidad, se utilizaron dos metodologías:

Waterfall y DevOps.

19
MARCO TEÓRICO

20
2.1. ANTECEDENTES DE LA INVESTIGACIÓN.

2.1.1. Internacionales

● Jimenez (2016). Tesis “DevOps, la nueva tendencia en el desarrollo

de sistemas TI, un caso práctico en el análisis de incidencias de
software.”, este proyecto intenta acercar el paradigma DevOps a las
empresas explicando las diferentes áreas en las que interviene e
introduciendo una solución útil en la detección y prevención de
riesgos.
Lo que esta tesis aportará a la presente investigación son las
recomendaciones acerca de la estandarización y automatización de
herramientas, procesos, métodos y pruebas que ofrecen una solución
completa para conseguir los objetivos planteados a medio y largo
plazo en las empresas.

● Zambrano (2017). Tesis “Estudio Comparativo de metodologías de

desarrollo ágil en base al desarrollo de una Aplicación móvil.”, en este
trabajo se analizó las diferentes metodologías en función de las
necesidades para el desarrollo de aplicaciones, en el cual se pudo
evidenciar las características que se debe tener cuenta para que la
implementación de estas sea eficaz y exitosa.
El aporte de esta tesis a nuestra investigación radica en la realización
de tablas comparativas para el análisis de las metodologías de
desarrollo de software.

● Rodríguez, Padilla y Parra (2018). Artículo “Arquitectura basada en

micro-servicios para aplicaciones web.”, este artículo nos comenta
acerca de los problemas que tienen las aplicaciones que actualmente
están diseñadas bajo arquitecturas antiguas.
El artículo nos explica que es necesario el uso de una arquitectura que
permita crear aplicaciones escalables, flexibles, con independencia en
sus funciones.

2.1.2. Nacionales

● Espinoza-Meza (2013). Tesis “Manual para elegir una metodología de

desarrollo de software dentro de un proyecto informático.”, presenta
un marco de trabajo que consiste en dar soporte a los planificadores
en la selección a través de pasos que filtren sucesivamente un grupo
de metodologías hasta hallar la metodología a aplicar.
Esta tesis nos ayuda a considerar los criterios de selección de la mejor

21
 metodología para un proyecto específico, además contiene un
procedimiento central, basado en un estudio comparativo entre
Metodologías tradicionales (Waterfall) y metodologías ágiles, cuyos
pasos son una sucesión de determinaciones y filtros que facilitan la
evaluación y decisión final.

● De la Cruz, Espinoza y Cuba (2018). Artículo “Propuesta de

arquitectura de microservicios, metodología Scrum para una
aplicación móvil de control académico: Caso Escuela Profesional de
Obstetricia de la Universidad Nacional Mayor de San Marcos.”, este
artículo describe la parte de planificación, análisis y diseño del avance
de una tesis de Ingeniería que aún está por concluirse.
El aporte de este artículo a nuestra investigación radica en una
comparación entre los microservicios y SOA así como la revisión
bibliográfica de la metodología Scrum permite la participación activa
de los usuarios y mejor control para el logro de los entregables.

● Godoy, Taype (2015). Tesis “Modelos de Aceptación de Metodologías

de desarrollo de software.”, plantea como objetivos identificar los
factores de impacto en la aceptación de metodologías de desarrollo
de Software para poder establecer una línea base viable para su
ampliación hacia un modelo de aceptación en las empresas.
Esta tesis aporta en la investigación porque presenta una propuesta
de factores de impacto en la selección de metodologías de desarrollo
de software, las cuales fueron agrupadas en 5 grupos: Factores del
individuo, de la metodología, organizacionales, de implementación y
externos.

2.2. BASES TEÓRICAS.

2.2.1. Ingeniería de software

La ingeniería de software es el establecimiento y uso de principios

fundamentales de la ingeniería con objeto de desarrollar en forma
económica software que sea confiable y que trabaje con eficiencia en
máquinas reales. (Pressman, 2010)
La meta de la ingeniería de software moderna es “desarrollar metodologías
que se basen en el concepto de evolución; es decir, el concepto de que
los sistemas de software cambian continuamente, que los nuevos
sistemas de software se desarrollan a partir de los antiguos y que todo
debe operar entre sí y cooperar con cada uno de los demás”.

22
2.2.2. Metodologías de desarrollo de software

La metodología hace referencia al conjunto de procedimientos racionales

utilizados para alcanzar un objetivo que requiera habilidades y
conocimientos específicos.
La metodología es una de las etapas específicas de un trabajo o proyecto
que parte de una posición teórica y conlleva a una selección de técnicas
concretas o métodos acerca del procedimiento para el cumplimiento de los
objetivos. Es el conjunto de métodos que se utilizan en una determinada
actividad con el fin de formalizarla y optimizarla. Determina los pasos a
seguir y cómo realizarlos para finalizar una tarea.

2.2.2.1. Waterfall

Waterfall (“en cascada”) es un sistema de gestión de proyectos en el

que el desarrollo de producto sigue un ciclo secuencial de etapas que
se ejecutan una tras otra. Se asocia habitualmente a entornos
industriales, donde las actividades son más repetitivas y el proceso es
más previsible. Las distintas fases que componen el proyecto,
colocadas una encima de otra, fluyen de arriba hacia abajo, como una
cascada.

Figura 1. Esquema metodología Waterfall

Fuente: (Pressman, 2010)

El modelo de la cascada, a veces llamado ciclo de vida clásico sugiere

un enfoque sistemático y secuencial para el desarrollo del software,
que comienza con la especificación de los requerimientos por parte del
cliente y avanza a través de planeación, modelado, construcción y
despliegue, para concluir con el apoyo del software terminado.

La metodología Waterfall es idónea para proyectos estables, donde

los requisitos son claros y no está previsto que cambien a lo largo del
proceso de desarrollo. También cuando la tecnología a utilizar es
conocida de antemano.

23
 El modelo de cascada es el paradigma más antiguo de la ingeniería
de software. Sin embargo, en las últimas tres décadas, las críticas
hechas al modelo han ocasionado que incluso sus defensores más
obstinados cuestionen su eficacia. Entre los problemas que en
ocasiones surgen al aplicar el modelo de cascada se encuentran los
siguientes:

1. Es raro que los proyectos reales sigan el flujo secuencial propuesto

por el modelo. Aunque el modelo lineal acepta repeticiones, lo hace en
forma indirecta. Como resultado, los cambios generan confusión
conforme el equipo del proyecto avanza.

2. A menudo, es difícil para el cliente enunciar en forma explícita todos

los requerimientos. El modelo de cascada necesita que se haga y tiene
dificultades para aceptar la incertidumbre natural que existe al principio
de muchos proyectos.

3. El cliente debe tener paciencia. No se dispondrá de una versión

funcional del (de los) programa(s) hasta que el proyecto esté muy
avanzado. Un error grande sería desastroso si se detectara hasta
revisar el programa en funcionamiento.

El problema que plantea es que, en muchas ocasiones, los clientes no

saben bien lo que quieren hasta que no ven una primera versión del
producto en funcionamiento. Es en ese momento cuando suelen
solicitarse cambios sobre sus peticiones iniciales. Cambios que
suponen incrementos, bien en el tiempo de ejecución o bien del coste
estipulado.

2.2.2.2. DevOps

DevOps fue acuñado en 2009 por Patrick Debois, que se ha convertido

desde entonces en uno de los gurús dentro de la comunidad. El
término se conforma de combinar las palabras "desarrollo" y
"operaciones, del inglés "Development & Operations", y puede servir
como punto de partida para entender qué significa exactamente el
término DevOps.

Esta nueva cultura no es un proceso, una tecnología concreta o un

estándar, sino un conjunto de técnicas, pensamientos, y modelos de
trabajo. También se utiliza el término "movimiento DevOps" cuando se
habla de temas acerca de la adopción de nuevos ratios e indicadores
y tendencias de futuro y "entorno DevOps" para referirse a la estrategia
organizativa que sugiere la cultura DevOps [7].

24
La adopción de DevOps está siendo impulsada por factores tales
como:
1. El uso de los procesos de desarrollo ágiles y otras
metodologías.
2. El incremento de una mayor tasa de versiones en producción
por parte de las unidades interesadas de aplicación y de negocios.
3. Amplia disponibilidad de virtualización y la infraestructura cloud
computing de proveedores internos y externos.
4. Aumento del uso de la automatización del data center y las
herramientas de gestión de configuración.

Aunque la filosofía de DevOps es común y los objetivos siempre son

los mismos, no existe un único modelo de organización de las tareas.
En su lugar, hay varios modelos de uso bastante extendido, además
de otros más específicos, dedicados a áreas concretas de IT en las
que el despliegue tiene algunas particularidades.

Figura 2: Ciclo DevOps

Fuente: ebook-devops

El modelo más común, es el que se representa con la imagen de un

símbolo de infinito dividido en ocho partes. En el mismo, el ciclo se
compone de: Plan (Planificación), Code (Código), Build
(Construcción), Test, Release (Lanzamiento), Deploy (Despliegue),
Operate (Emplear), Measure (Medir) y de nuevo, conexión con Plan,
ya que el desarrollo es, y así se entiende, continuo.

25
2.2.3. Microservicios

Como lo definen James Lewis y Martin Fowler en su artículo:

Microservices, “es una forma particular de diseño de aplicaciones de
software como suites de servicios desplegados independientemente”.

Figura 3: Patrón básico de arquitectura de Microservicios

Fuente: (Mark Richards, 2015)

La arquitectura de Microservicios es un enfoque de desarrollo de una

aplicación como un conjunto de servicios más pequeños, cada uno se
ejecuta en su propio proceso y se exponen, normalmente, a través de
protocolos HTTP mediante APIs REST. Estos servicios están
construidos alrededor de capacidades o funcionalidades de negocio y
con independencia de despliegue a través de un sistema de
automatización. Además, pueden estar escritos en diferentes lenguajes
de programación y utilizar diferentes tecnologías de almacenamiento de
base de datos [3].

El término microservicios no es relativamente nuevo, este estilo

arquitectural fue acuñado por Martin Fowler en un taller de arquitectos
de software como una descripción del nuevo campo que los
participantes estaban explorando. No existe una definición en concreto

26
 para microservicio, sin embargo, una aproximación que la realiza
(Newman, 2015) lo define como: “Pequeños servicios autónomos que
trabajan juntos”.

2.2.4. Aplicación Web

Llamadas “webapps”, esta categoría de software centrado en redes

agrupa una amplia gama de aplicaciones. En su forma más sencilla, las
webapps son poco más que un conjunto de archivos de hipertexto
vinculados que presentan información con uso de texto y gráficas
limitadas. (Pressman, 2010)
Las aplicaciones web son populares debido a lo práctico del navegador
web como cliente ligero, a la independencia del sistema operativo, así
como a la facilidad para actualizar y mantener aplicaciones web sin
distribuir e instalar software a miles de usuarios potenciales.

2.3. GLOSARIO DE TÉRMINOS BÁSICOS

Agile: en términos más generales, la metodología de negocios que hace

hincapié en ciclos cortos, de planificación y desarrollo iterativo para
proporcionar un mejor control, previsibilidad y apoyo a necesidades
cambiantes a medida que los proyectos evolucionan.

Arquitectura Orientada a Servicios: (SOA) es un modelo de arquitectura

que posiciona a los servicios como un mecanismo esencial para poder
incrementar la eficiencia, agilidad y productividad de una empresa.

AWS: Amazon Web Services (AWS) es una subsidiaria de Amazon que

proporciona API y plataformas de computación en la nube bajo demanda a
individuos, empresas y gobiernos, con un sistema de pago por uso medido.

Bitbucket Cloud: es una herramienta de colaboración y alojamiento de

código basada en Git, creada para equipos. Las mejores integraciones de
Jira y Trello de Bitbucket están diseñadas para unir a todo el equipo de
software para ejecutar un proyecto.

Cloud Computing: la computación en la nube, conocida también como

servicios en la nube, informática en la nube, nube de cómputo o simplemente
“la nube”, es un paradigma que permite ofrecer servicios de computación a
través de una red, que usualmente es internet.

27
Docker: es una plataforma abierta para desarrollar, enviar y ejecutar
aplicaciones que permite separar sus aplicaciones de su infraestructura para
que pueda entregar software rápidamente.

E-commerce: comercio por Internet o comercio en línea. Consiste en la

compra y venta de productos o de servicios a través de internet, tales como
redes sociales y otras páginas web.

Entrega continua: es un conjunto de procesos y prácticas que eliminan

gradualmente los desechos de su proceso de producción de software.
Permite una entrega más rápida de la funcionalidad de alta calidad y
establece un bucle rápido y una efectiva retroalimentación entre su empresa
y sus usuarios.

Integración contínua (CI o Continuous Integration): es una práctica de

desarrollo que requiere que los desarrolladores integren código en un
repositorio compartido varias veces al día. Cada registro de entrada es
verificado por una construcción automatizada, permitiendo a los equipos
detectar los problemas a tiempo.

Kubernetes: es una plataforma portable y extensible de código abierto para

administrar cargas de trabajo y servicios que facilita la automatización y la
configuración declarativa.

Pipelines: la arquitectura en pipeline consiste en ir transformando un flujo de

datos en un proceso comprendido por varias fases secuenciales, siendo la
entrada de cada una la salida de la anterior. Es muy común en el desarrollo
de programas para el intérprete de comandos, ya que se pueden conectar
comandos fácilmente con tuberías (pipe).

Scrum: es un proceso en el que se aplican de manera regular un conjunto

de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el
mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a
otras y su selección tiene origen en un estudio de la manera de trabajar de
equipos altamente productivos.

Spring Boot: herramienta que facilita la creación de aplicaciones

independientes basadas en el framework Spring de production-grade que
puede "simplemente ejecutar".

28
2.4. HIPÓTESIS

El estudio comparativo de las metodologías desarrollo Waterfall y Devops

ayudará a determinar qué metodología se acopla de mejor manera para el
desarrollo óptimo de un microservicio para una tienda virtual.

29
 CAPITULO III.
MARCO
METODOLÓGICO.

30
3.1. ENFOQUE Y DISEÑO

3.1.1. Enfoque

Este proyecto está bajo el enfoque cuantitativo ya que los resultados se

obtienen a partir del análisis comparativo.

3.1.2. Diseño

El diseño de investigación es no experimental de tipo transversal ya que

cuando el investigador se limita a medir los acontecimientos sin intervenir
en los mismos entonces se desarrolla una investigación no experimental.
Y se dice que es de tipo transversal porque tiene como propósito describir
variables y analizar su incidencia en un momento dado.

3.2. SUJETO DE LA INVESTIGACIÓN

El sujeto de la investigación es el negocio de venta digital de libros “Inti
Libros”.

3.3. MÉTODOS Y PROCEDIMIENTOS.

3.3.1. Aplicación de la metodología Waterfall

A. Análisis de requerimientos:
En la fase de análisis de requerimientos se enumeran los requisitos
funcionales del proyecto los cuales determinan las funcionan que esperan
que ejecute el sistema.
RE1: El usuario puede realizar la búsqueda de un libro mediante la web
por nombre, autor, editorial.
RE2: El usuario puede consultar desde una PC, Tablet, Móvil los detalles
de los libros que se encuentran en la tienda online “Inti Libros”.
RE3: El usuario podrá visualizar la carátula, nombre, autor, editorial,
reseña, precio y disponibilidad del libro que escoja.
RE4: El negocio puede visualizar los libros más consultados por la web
mediante el log del microservicio.

31
Estimación de las horas dedicadas:
Una vez que se tiene definidos los requerimientos que se van a trabajar
durante el proyecto, se realiza una estimación de horas que se divide en
cinco áreas importantes: análisis, diseño, desarrollo e implementación,
certificación e implementación y cierre.

FASES HORAS DE DEDICACIÓN

ANÁLISIS 14
DISEÑO 10
DESARROLLO 20
CERTIFICACIÓN 15
DESPLIEGUE 15
TOTAL 74 horas

Tabla 1: Estimación de horas dedicadas.

Modelo de dominio de la base de datos

Figura 4: Modelo de dominio de la base de datos

32
Descripción de los casos de uso

Iniciar aplicación
Caso de uso: Iniciar aplicación
Actor principal: Usuario
Pre condiciones: Acceso a internet
Versión: 1
Pasos:
Actor Sistema
1. Abrir aplicación en el navegador
2. Muestra la interfaz
3. Muestra el menú principal
Post condición: Visualizar el inicio de la aplicación

Tabla 2: Descripción Caso de Uso: Iniciar aplicación

Mostrar detalle libro

Caso de uso: Mostrar detalle libro
Actor principal: Usuario
Pre condiciones: Acceso a internet
Versión: 1
Pasos:
Actor Sistema
1. Abrir aplicación en el navegador
2. Muestra la interfaz
3. Realizar búsqueda por nombre,
autor, editorial.
Post condición: Visualizar detalle de libro

Tabla 3: Descripción Caso de Uso: Mostrar detalle libro

33
B. Diseño:
La fase de diseño consiste en el análisis de los modelos y la arquitectura
de la aplicación.

Figura 5: Arquitectura de aplicación web con microservicios

34
Diagrama de secuencia Buscar libros mediante la web:

Figura 6: Diagrama de secuencia Buscar libros mediante la web

C. Desarrollo:
En este caso la arquitectura es un modelo cliente-servidor, donde el cliente
será el dispositivo desde el que se accede a la aplicación, y el servidor
será el servicio en la nube.
La web de Inti Libros utiliza una estructura de diseño MVC (Modelo, Vista,
controlador).

Figura 7: Patrón de diseño Modelo - Vista – Controlador

Fuente: easyappcode.com (Consultada el 30 diciembre 2020)
35
 Tabla 4: Requerimientos funcionales de la etapa de construcción
ID NOMBRE REQ DESCRIPCION HORAS RESPONSABLE
El usuario puede realizar la Construir los módulos
REQ1 búsqueda de un libro del microservicio para 9 Miguel Bravo
mediante la web por nombre, realizar la búsqueda de
autor, editorial. libros.
El usuario puede consultar Implementar la llamada
REQ2 desde una PC, Tablet, Móvil desde la web para 4 Cristha Ojeda
los detalles de los libros que consumir el
se encuentran en la tienda microservicio.
online “Inti Libros”.
El usuario podrá visualizar la Implementar la
REQ3 carátula, nombre, autor, visualización de la 4 Cristha Ojeda
editorial, reseña, precio y respuesta del
disponibilidad del libro que microservicio
escoja.
El negocio puede visualizar Implementar la captura
REQ4 los libros más consultados de log del microservicio. 3 Pier
por la web mediante el log Huasasquiche
del microservicio.
Total 20h

Tabla 5: Requerimientos no funcionales de la etapa de construcción

ID NOMBRE REQ
La consulta del detalle de un libro debe responder al usuario en menos
REQNF1 de 10 segundos.
El sistema debe ser capaz de operar adecuadamente con hasta 10,000
REQNF2 usuarios con sesiones simultáneas.
El sistema debe proporcionar mensajes de error que sean informativos
REQNF3 y orientados a usuario final.
El sistema debe desarrollarse aplicando patrones y recomendaciones
REQNF4 de programación que incrementen la seguridad de los datos de los
clientes.
El sistema debe tener una disponibilidad del 99,99% de las veces en
REQNF5
que un usuario intente accederlo.

36
Estructura MVC del Proyecto en Visual Studio

Figura 8: Solución del aplicativo en Visual Studio

37
Base de datos
El almacenamiento de los datos de la aplicación se utiliza Postgres Sql con
un servidor Centos 7 y el cliente pgAdmin.

Figura 9: Cliente PgAdmin Postgres Sql

38
Creación del microservicio en Apache NetBeans
Al crear el proyecto Spring, se ha seleccionado la categoría “Java with
Maven” y dentro de esta la plantilla “Sprint Boot Initializr Project”. Luego se
muestra un formulario donde se coloca el nombre de la aplicación, el
grupo, tipo de paquete y la versión de Java. En este caso se utilizará Java
8 por ser la versión más estable de Java a la fecha.

Figura 10: Creación del proyecto Apache NetBeans

39
 Figura 11: Configuración del microservicio en Apache NetBeans

Luego de crear y configurar el proyecto en Apache NetBeans, se procede

a añadir paquetes de Java dentro de la estructura del proyecto. Se ha
considerado el paquete Entidades, Controlador y Repositorio.
Para el caso del paquete entidades, se tiene en cuenta la estructura de la
base de datos con la se ha trabajado.
Adicionalmente, se ha escogido las siguientes librerías:
- Lombok: Permite eliminar la creación de código repetitivo.
- Spring web: Se centra en proporcionar infraestructura para la creación
y ejecución de aplicaciones web.
- Spring data JPA: Simplificar la persistencia de datos contra distintos
repositorios.

40
Figura 12: Configuración del microservicio en Apache NetBeans

Figura 13: Configuración del microservicio en Apache NetBeans

41
 Figura 14: Configuración del microservicio en Apache NetBeans

D. Pruebas:
Plan de pruebas
E1: Realizar la búsqueda en el microservicio. R1: El usuario puede realizar
la búsqueda de un libro mediante la web por nombre, autor, editorial.

Figura 15: Response del microservicio en Apache NetBeans

42
E2: Ingresar a la interfaz de “Inti Libros”. R2: El usuario puede consultar
desde una PC, Tablet, Móvil los detalles de los libros que se encuentran
en la tienda online “Inti Libros”.

E3: Realizar la búsqueda mediante la interfaz. R3: El usuario podrá

visualizar la carátula, nombre, autor, editorial, reseña, precio y
disponibilidad del libro que escoja.

E4: Descargar el log del microservicio. R4: El negocio puede visualizar los
libros más consultados por la web mediante el log del microservicio.

Figura 16: Log del microservicio

43
E. Despliegue:
Tabla 6: Horas reales del proyecto
Fases Horas
reales
Análisis 16
Revisión de código 8
Definición de requerimientos funcionales 4
Elaboración de los documentos funcionales y no funcionales 4
Diseño 5
Elaboración de diagramas RUP 5
Desarrollo 30
Preparación de ambientes 2
Desarrollo del Req1: “El usuario puede realizar la búsqueda de 6
un libro mediante la web por nombre, autor, editorial”.
Pruebas unitarias 2
Desarrollo del Req2: “El usuario puede consultar desde una PC, 4
Tablet, Móvil los detalles de los libros que se encuentran en la tienda
online “Inti Libros””.
Pruebas unitarias 2
Desarrollo del Req3: “El usuario podrá visualizar la carátula, 4
nombre, autor, editorial, reseña, precio y disponibilidad del libro que
escoja”.
Pruebas unitarias 2
Desarrollo del Req4: “El negocio puede visualizar los libros más 2
consultados por la web mediante el log del microservicio”.
Pruebas unitarias 1
Pruebas integrales 3
Elaboración de documentos técnicos 2
Certificación 12
Pruebas de la ronda 1 4
Levantamiento de observaciones 2
Pruebas de la ronda 2 4
Congelamiento de fuentes 2
Despliegue 10
Pase a producción 2
Pruebas de ratificación 8
Total 73

44
3.3.2. Aplicación de la metodología DevOps

Esta metodología no es un proceso con un alcance final definido, es algo

iterativo que debe iniciarse con un rediseño de arquitectura, la
identificación de los cuellos de botella y problemas que ocurren
constantemente en nuestro proceso actual buscando la mejor manera de
ejecutar y llevar nuevos requerimientos a producción (o ambientes
cercanos) de la manera más rápida y eficiente posible identificando errores
o fallos de seguridad en etapas tempranas.
A. Rediseño de la Arquitectura:
En esta etapa se han realizado los ajustes necesarios a nivel de
Arquitectura con la finalidad de soportar correctamente la metodología
DevOps.

Los ajustes que se aplicaron también están alineados a solucionar los

siguientes problemas que se nos presentaron en la implementación
basada en Waterfall:

• Versionamiento del código de la aplicación.

En el desarrollo basado en Waterfall se presentó el problema con
las versiones de código y los problemas con la integración de
código fuente.
Se ha habilitado un repositorio de código en Bitbucket con la
finalidad de tener un lugar centralizado de donde consumir el código
de la aplicación y hacia donde versionarlo para que todos los
programadores que están participando se encuentren informados.

Figura 17: Herramienta BitBucket para le versionamiento de código

45
• Framework de pruebas.
La ejecución de las pruebas de forma automática que nos permitan
identificar de manera temprana cualquier error que haya surgido de
algún cambio reciente, nos ayuda a reducir considerablemente los
tiempos de ejecución manual de pruebas y de retrabajo en la
solución de errores que se pudieron evitar.
Se ha habilitado un framework de pruebas unitarias donde los
programadores tendrán la posibilidad de ir alimentándolo y lograr el
mayor número posible de pruebas automatizadas.

Figura 18: Implementación del framework

• Dockerización de los microservicios.

Uno de los obstáculos más grandes que se presentó en el
desarrollo con Waterfall fueron los despliegues lentos y no debido
al procesamiento sino a causa de los cuellos de botellas que
teníamos en el proceso.
Para ayudar a solucionar este problema hemos dockerizado todos
los microservicios y con esto lograr conseguir un despliegue más
rápido en los diferentes ambientes.

46
 Figura 19: Dockerización del proyecto

• Definición de la infraestructura como código.

El despliegue en los diferentes ambientes ha sido un gran problema
en esta implementación, dado que constantemente se nos
presentaron problemas con el aprovisionamiento de servidores y
con las versiones del software necesario para levantar los
microservicios.
Para superar este problema se ha dejado de utilizar infraestructura
física (hardware) para en su lugar empezar a utilizar infraestructura
como código (IAC – Infrastructure as Code).

Figura 20: Despliegue del proyecto Infrastructure as Code

47
La nueva arquitectura implementada es:

Figura 21: Arquitectura propuesta para DevOps

Este nuevo diseño de arquitectura de la aplicación contempla las buenas

prácticas de desarrollo, de pruebas y de despliegue.

B. Plan:
En esta etapa se categorizará el número de prioridad y la estimación de
cada una de las historias de usuarios
Tabla 7. Tabla de Prioridades
Numero Prioridad Complejidad
1 Baja Fácil
2 Media Moderada
3 Alta Complejo
4 Muy alta Muy complejo

48
 Tabla 8. Tabla de Historias de usuario

ID HISTORIA CRITERIO ACEPTACIÓN PRIORIDAD RESPONSABLE

Crear un microservicio El microservicio debe
H1 para visualizar el detalle devolver el detalle del 3 Miguel Bravo
de Libros. libro.
El usuario podrá Implementar la
H2 visualizar la carátula, visualización de la Cristha Ojeda
nombre, autor, editorial, respuesta del 3
stock, reseña, precio y microservicio en la web.
disponibilidad del libro
que escoja.
Total 7h

C. Desarrollo:
Para aplicar correctamente DevOps se necesita también ser ágil en el
desarrollo, por eso se ha utilizado Scrum para cubrir todo lo que
corresponde al desarrollo ágil de software.
Para lograr soportar correctamente la metodología de desarrollo
Scrum, se ha utilizado a Jira Software como herramienta de gestión de
proyectos ágiles:

Figura 22: Herramienta Jira de monitoreo de código

49
Esta herramienta incluso nos permite acceder a gráficos que nos
ayudan a gestionar correctamente el desarrollo de nuevos
microservicios:

Figura 23: Herramienta Velocity Chart para el seguimiento del

proyecto

Figura 24: Herramienta Burndown Chart para el seguimiento del

proyecto

50
 Cada historia que corresponde al desarrollo del microservicio de
consulta será trabajada en una rama de código independiente
(consulta-libros) como se muestra en la imagen:

Figura 25: Herramienta BitBucket de monitoreo

Se debe considerar que para esta investigación se ha tomado de base

parte del proyecto desarrollado en Waterfall, el cual ha sido
refactorizado y acondicionado para soportar el trabajo con repositorios
y sub-repositorios de Bitbucket y además soportar la nueva
arquitectura como código de la aplicación.

Figura 26: Desarrollo de microservicio en Apache NetBeans

51
El microservicio de consulta ha sido desarrollado en el proyecto “books”
como se muestra en la imagen:

Figura 27: Estructura del proyecto

D. Verificación:
Esta etapa se ha logrado automatizar apoyada en el framework de
pruebas unitarias que hemos habilitado para el proyecto.
Dado que cada historia ha sido trabajada en una rama diferente de
código, cuando el desarrollador envía sus cambios al repositorio central
se ejecutan las pruebas unitarias que nos ayudará a identificar los
posibles errores generados en el desarrollo de la nueva funcionalidad.
E. Empaquetado:
El empaquetado también es disparado al momento de que el
desarrollador sube sus cambios al repositorio central pero siempre y
cuando hayan pasado todas las pruebas definidas en el framework de
pruebas unitarias.
F. Despliegue:
Una de las características principales del DevOps es reducir los
tiempos del “Time to Market” y para lograrlo necesitamos que la
infraestructura y la aplicación se pueda desplegar a demanda y sin la
necesidad de intervención humana o alguna dependencia con otras
áreas.

52
 En esta investigación todos los componentes de la aplicación han sido
llevados a infraestructura como código para que con ello se habilite los
despliegue a demanda.

Incluso la base de datos de la aplicación ahora cuenta con una

infraestructura como código:

Figura 28: Archivo despliegue de la aplicación

G. Configuración:
Para evitar el problema común que presenta los archivos de configuración
y valores en duro dentro de la aplicación, se ha habilitado un servidor de
configuración (config-server-repo) que también se encuentra alojado
dentro de Bitbucket con el fin de mantener una correcta gestión de las
versiones en los archivos de configuración.

Figura 29: Herramienta de monitoreo BitBucket

53
H. Monitorización:
Al ser un modelo iterativo es importante estar siempre en este constante
proceso.
Para ayudarnos con esta etapa se ha utilizado “Spring Boot Admin” la cual
es una herramienta que está monitoreando constantemente el estado de
todos nuestros microservicios y que alerta en caso de que alguno de estos
presente errores.

Figura 30: Herramienta de monitoreo “Sprint Boot Admin”

Tiempos reales:
Tabla 9: Horas reales del proyecto

Etapas Horas
reales
Rediseño de la Arquitectura (*) 24
Plan 0.50
Desarrollo 8
Verificación 0.08
Empaquetado 0.08
Despliegue 0.17
Configuración (*) 8
Monitorización (*) 8
Total 48.83

54
Como se puede apreciar el tiempo de implementación es menos que el
que implicaría desarrollar el mismo microservicio con metodología
Waterfall.
Pero hay un punto importante a considerar, las etapas marcadas con (*)
son tiempo que sólo se van a consumir en esta primera vez como parte de
la refactorización; con esto los tiempos netos en la implementación de este
nuevo microservicio sería: 8.83h.

Cabe resaltar que con la implementación de DevOps estamos

solucionando muchos escenarios y problemas comunes que ocurren en
Waterfall.
Aquí algunos ejemplos:
• En Waterfall ocurre que se utiliza un método rudimentario para
guardar el código en una carpeta y entonces se pasa el código a un
programador y se le pasa el mismo código a otro programador, lo
que termina ocurriendo es que se van a pisar el uno con el otro,
quizás uno hace cambios en un archivo, el otro hace otro tipo de
cambios en el mismo archivo con lo cual ¿cómo fusionamos las dos
versiones?
Ahora con DevOps ocurre que el repositorio de código está en un
servidor, el programador “uno“ y el programador “dos“ pueden
trabajar sobre el mismo código, aunque sobre ese mismo código,
empiecen a trabajar en funciones distintas.
• Un desarrollo de software basado en Waterfall por lo general se
ajusta para proyectos en los cuales se tiene muy bien definido el
alcance y las funcionalidades deseadas por el cliente.
Pero en el contexto actual un buen porcentaje de empresas están
luchando por ser competitivas y ágiles, lo cual las obliga a iniciar un
desarrollo que muchas veces no se conoce el alcance total y que
puede cambiar según las necesidades del mercado.
• En DevOps ya no se tiene la necesidad de esperar al especialista
de infraestructura para que realice los despliegues, dado que ya se
está trabajando bajo infraestructura como código que se
autoconstruye al momento de ejecutar el pipeline de despliegue.
• En Waterfall ocurre muy seguido la detección tardía de errores que
se producen a raíz de nuevos desarrollos.
Esta situación en DevOps ha sido solucionada con la incorporación
de las pruebas unitarias que nos ayudan a detectar errores en
desarrollo y no permitir que lleguen hasta producción.

55
3.3.3. Análisis de metodologías

En el presente trabajo de investigación, los criterios a comparar se han

tenido en cuenta de acuerdo a las principales particularidades de ambas
metodologías, en las cuales se puedan establecer relaciones de
semejanza y contraste.
Estos criterios se han reunido en tres grupos destinados a facilitar el
estudio:

A. Procesos.

a. Predicción – Agilidad.

Waterfall es una metodología predictiva. Se elabora la

planificación al inicio del proyecto, debido a la estabilidad y poca
incertidumbre de las variables y del entorno del proyecto.
Devops es una metodología empírica. Dadas las características
inestables del proyecto, necesita reaccionar frente a cambios,
por tanto, su planificación es continua e incremental.

b. Frecuencia de flujos de trabajo.

Waterfall pretende que los flujos de trabajo se desarrollen

permanentemente durante todo el ciclo de vida del software.
Cada fase generalmente comienza a medida que termina la
anterior. A lo largo del desarrollo, varios miembros del equipo
pueden participar o continuar con otros trabajos.
En DevOps, los flujos son desarrollados continuamente, lo que
resulta en un rápido flujo de trabajo planificado, es decir, altas
tasas de despliegue sin causar caos e interrumpir otros servicios.

c. Definición de prácticas, roles y tareas.

i. Prácticas

En Waterfall, las prácticas se orientan al desarrollo de

software teniendo como punto de partida una definición
inicial de requerimientos completa y a partir de ella una
generación secuencial de modelos.
En DevOps, se resaltan las prácticas de autogestión y
autoorganización, por lo tanto, aumenta la confiabilidad,
la estabilidad, la resistencia y seguridad del entorno de
producción.

56
 ii. Roles y tareas

En Waterfall se tienen roles definidos jerárquicamente,

encontrándonos al jefe de proyectos como máxima
autoridad y, por debajo, a los analistas,
desarrolladores, testers, QA, entre otros. Una persona
puede ejecutar varios roles, y un rol puede ser
compartido por varias personas.
La clave de DevOps es una mayor colaboración entre
ingeniería y operaciones. Eso significa repensar los
roles de desarrollo y operaciones existentes y
reorientarlos en torno a la entrega continua de
software, desde las ideas y el desarrollo hasta la
producción y el mantenimiento.

d. Definición de entregables.

i. Cantidad y complejidad de artefactos.

En Waterfall, se utiliza una gran variedad de artefactos

intermedios antes de llegar al software final. Los
principales son modelos complejos y profundamente
detallados que reúnen las necesidades de los clientes.
En DevOps, se prefiere la comunicación cara a cara
entre los miembros del equipo, reduciéndose
drásticamente la cantidad de artefactos intermedios.
Los artefactos se limitan a sencillas historias de usuario
y otras herramientas de seguimiento.

ii. Propiedad de artefactos.

La metodología Waterfall asigna a cada rol artefactos

bajo su responsabilidad. La propiedad de cada
entregable recae sobre el rol, quien tiene la potestad,
capacidad y habilidades para crearlos o modificarlos.
En DevOps los únicos artefactos asignados son los de
planeamiento, requerimientos o historias de usuario y
las entregas. El grupo de funcionalidades a desarrollar
en la iteración se dividen, con la finalidad de asignar
tareas.

57
B. Personas.

a. Equipo de trabajo.

i. Número de integrantes.

Waterfall no fija un determinado número de miembros,

pero sí refiere que es una metodología diseñada para
manejar proyectos con equipos de trabajo grandes.
Esto se puede constatar en los múltiples roles que
requieren una cierta especialización, aparte del número
de artefactos que recaen bajo su responsabilidad. Esto
no quiere decir que grupos pequeños no puedan
ponerlo en práctica, pero deberán adaptar el proceso a
las necesidades del grupo.
DevOps es una metodología ágil aplicada más allá del
equipo de software, por lo tanto, suelen tener equipos
de trabajo reducido que sugiere que el número de
integrantes sea 2 integrantes de gestión y 7 +/- 2 de
desarrollo.

ii. Comunicación entre integrantes.

Waterfall trata las comunicaciones entre miembros de

manera indirecta. Establece como únicos puntos de
retroalimentación, las reuniones en la planificación, los
hitos o alguna reunión adicional formal. Las
interacciones establecidas son las transferencias de
información por medio de artefactos.
Bajo un modelo de DevOps, los equipos de desarrollo
y operaciones ya no están “aislados”. Los dos equipos
se fusionan en uno solo, donde los ingenieros trabajan
en todo el ciclo de vida de la aplicación, desde el
desarrollo y las pruebas hasta la implementación y las
operaciones, y desarrollan una variedad de habilidades
no limitadas a una única función.

iii. Cambio de integrantes.

En Waterfall, un cambio de integrantes en el proyecto,

o que el proyecto sea retomado por un equipo distinto
al inicial, no debería afectar el curso del ciclo de vida
de manera dramática. Se posee la documentación y

58
 artefactos necesarios para continuar con el rumbo del
desarrollo.
En DevOps, se corre el riesgo que se pierda
conocimiento importante de las personas con
propiedad exclusiva sobre artefactos o entregables, y
por tanto mayores costos por capacitación.

b. Clientes
i. Participación en el proyecto.

En Waterfall, el rol de cliente representa a la empresa.

Con el cliente se acuerda el contrato, la planificación, a
la que se consulta el giro del negocio y los
requerimientos, y con la que se aprueba el
cumplimento de los objetivos en los hitos. Los usuarios
participan en el levantamiento de información para
definir requerimientos, en la evaluación de hitos, y en
la ejecución de pruebas de usuario y distribución.
DevOps requiere que los equipos de desarrollo y
operaciones se comuniquen con frecuencia y aborden
su trabajo con empatía hacia sus compañeros de
equipo. Los desarrolladores trabajan en estrecha
colaboración con los equipos de operaciones de TI
para agilizar el diseño, las pruebas y el lanzamiento de
los sistemas de software, sin comprometer la
confiabilidad.

C. Organización y proyectos.

a. Criticidad de proyectos

Waterfall, es una metodología que en su totalidad ha sido creada

para proyectos de criticidad alta, dada la cantidad de flujos, roles,
actividades, y artefactos que define. Sin embargo, también se
puede ajustar a proyectos de otros niveles.
DevOps es similarmente escalable en cualquier organización y
aborda proyectos de diferente envergadura.

b. Manejo de contratos.

En Waterfall se definen completamente los objetivos,

planificación y requerimientos al inicio del proyecto, los contratos
utilizados son los de costo-fijo. En este tipo de contratos se

59
 dividen las responsabilidades entre el cliente y el equipo de
desarrollo, con respecto al proyecto y al resultado final. Incidirá
de manera positiva en la calidad final de producto que la
innovación, incertidumbre del entorno e inestabilidad de los
requisitos sean bajos.
En DevOps los índices de innovación, incertidumbre e
inestabilidad son altos, se requiere reacción frente al cambio que
los contratos fijos no podrían proporcionar.

Tabla 10. Cuadro comparativo de las metodologías Waterfall y DevOps

Características para el
desarrollo de microservicios Waterfall DevOps

1. Identificación de Enfocado en las necesidades Enfocado en las necesidades

Usuarios Finales. del negocio. de cliente.
2. Comunicación Comunicación baja. Comunicación muy alta.
3. Documentación Documentación alta. Documentación baja.
4. Minimización de impacto Bajo. Alto.
de limitaciones inherentes.
5. Minimización de impacto Bajo. Alto.
de limitaciones de
evolución.
6. Valores o principios Principios orientados a la Principios orientados a
orientados al desarrollo de gestión de proyectos. potenciar el flujo de trabajo.
App.
7. Entrega de la aplicación Tiempos de entrega largos. Tiempos de entrega cortos.
en tiempos cortos.
8. Metodología fácil de Dificultad baja. Dificultad alta.
adoptar
9. Calidad del producto Calidad Media. Calidad Alta.
10. Conciencia del producto Alta. Baja.
en el mercado.

3.4. ASPECTOS ÉTICOS

La información proporcionada por los usuarios que utilicen el sistema, será

de uso único y exclusivo para la aplicación. De tal manera, protegemos la
información bajo cualquier circunstancia.

60
 CAPITULO IV.
RESULTADOS Y
DISCUSIÓN

61
4.1. RESULTADOS

Resultado 1: Mejora de tiempos de entrega

Los resultados obtenidos después de la implementación de las metodologías de

desarrollo de software Waterfall y DevOps se exponen a continuación:

Tabla 11. Cuadro comparativo de las metodologías

Etapa del proyecto Waterfall DevOps Mejora

Plan 21 0.5 98%

Configuración de ambiente 2 8 -300%
Desarrollo 28 8 71%
Pruebas 12 0.16 99%
Puesta en producción 10 8.17 18%
Total (*) 73 24.83 66%

(*) No se considera el tiempo de rediseño de la arquitectura para DevOps.

62
4.2. DISCUSIÓN

Resultado 1: Mejora de tiempos de entrega

Así como en la investigación de Zambrano (2017), se realizó un cuadro comparativo

de las metodologías Waterfall y DevOps y luego de analizar los resultados, se puede
decir que:

En la Tabla 10, la cual muestra el análisis de los tiempos de entrega de cada una
de las fases de las metodologías se tiene una mejora del 66% en la entrega de un
microservicio para la web IntiLibros. Cabe resaltar que en la etapa de Configuración
para DevOps se han considerado 8h, pero sólo será consumido en esta primera vez
como parte de la refactorización mientras que para Waterfall será una tarea que se
realizará en cada proyecto.

63
CONCLUSIONES

1. Se analizaron las metodologías Waterfall y DevOps en función de las

necesidades del desarrollo de microservicios, en el cual se pudo evidenciar
que, por las características del proyecto, la metodología DevOps se ajusta
más para que la implementación de esta sea eficaz y exitosa disminuyendo
los tiempos de entrega.

2. Existe gran cantidad de herramientas importantes que se han introducido

para una adopción efectiva de DevOps con la finalidad de liberar al factor
humano de las tareas repetitivas que tienden al error.

3. La utilización de una metodología de desarrollo de software depende en

muchos casos de las características, requisitos y limitaciones del proyecto,
por lo que se convierte en una referencia para la construcción del proyecto y
no en una receta estricta a seguir.

4. Existe la dificultad de que no hay límites claros en las etapas de la

metodología DevOps, por lo que existe una complejidad al querer compararla
con Waterfall y poder emitir algún criterio sobre su uso.

5. La arquitectura de microservicios presenta independencia, acoplamiento,

cohesión, flexibilidad, despliegue y descubrimiento de servicios, por lo tanto,
la metodología DevOps facilita el desarrollo y sobre todo permite culminar el
proyecto en los plazos establecidos ya que que permite la participación activa
de los usuarios y mejor control para el logro de los entregables, así como una
mejor gestión y organización del proyecto.

64
RECOMENDACIONES

Realizar capacitaciones constantes a los miembros del equipo teniendo en cuenta

que es la comunicación entre los desarrolladores y las personas encargadas de la
operación el mayor desafío de la metodología DevOps.

Se recomienda que el sistema web pueda adaptarse a los cambios de los nuevos
clientes utilizando tecnologías que garanticen la disponibilidad del sistema y la mejor
experiencia de usuario.

65
REFERENCIAS BIBLIOGRÁFICAS

[1] Antón Sebastián Magally Edith (2019). Proceso de Desarrollo de Software

basado en DevOps para las aplicaciones Web de una institución Financiera.
Disponible en:
http://repositorio.upla.edu.pe/bitstream/handle/UPLA/1382/T037_21563381
_T.pdf?sequence=1&isAllowed=y [Fecha de consulta: 23/11/2020]

[2] Bitbucket. [en línea] https://bitbucket.org/product/guides/getting-

started/overview#key-terms-to-know [Fecha de consulta: 11/11/2020]

[3] Docker. [en línea] https://docs.docker.com/get-started/overview/#docker-

architecture [Fecha de consulta: 23/11/2020]

[4] Espinoza, A. (2013). Manual para elegir una metodología de desarrollo de

software dentro de un proyecto informático. [en línea]. (Tesis de pregrado en
Ingeniería Industrial y de Sistemas). Universidad de Piura. Facultad de
Ingeniería. Programa Académico de Ingeniería Industrial y de Sistemas.
Piura, Perú. Disponible en:
https://pirhua.udep.edu.pe/bitstream/handle/11042/2747/ING_521.pdf?sequ
ence=1 [Fecha de consulta: 01/12/2020]

[5] Fredy H. Vera-Rivera, Carlos Mauricio Gaona Cuevas, Hernán Astudillo (2019).
Desarrollo de aplicaciones basadas en microservicios: tendencias y desafíos
de investigación. Disponible en:
https://www.researchgate.net/publication/338582836_Desarrollo_de_aplicac
iones_basadas_en_microservicios_tendencias_y_desafios_de_investigacio
n [Fecha de consulta: 23/11/2020]

[6] Jimenez Marco, Guillermo (2016). DevOps, la nueva tendencia en el desarrollo

de sistemas TI, un caso práctico en el análisis de incidencias de software.
Disponible en: PROJECTE FINAL DE CARRERA DevOps, la nueva
tendencia en el desarrollo de sistemas TI, un caso práctico en el análisis de
incid [Fecha de consulta: 24/11/2020]

[7] Kubernetes. [en línea] https://kubernetes.io/es/docs/concepts/overview/what-is-

kubernetes/ [Fecha de consulta: 24/11/2020]

[8] Macedo Pereira Alejandro (2020). Uso de una arquitectura basada en eventos
como capa de comunicación para microservicios. Disponible en:
http://tesis.pucp.edu.pe/repositorio/bitstream/handle/20.500.12404/16979/M
ACEDO_PEREIRA_ALEJANDRO_USO_UNA_ARQUITECTURA.pdf?sequ
ence=1&isAllowed=y [Fecha de consulta: 22/11/2020]

66
[9] Mark Richards. (2015). Software Architecture Patterns (N° 9781491924242).
O’Reilly Media, Inc.

[10] Rodríguez Ángela Indira, Padilla Jackelyne Ivone, Parra Hugo Alexander.
(2018). Arquitectura basada en micro-servicios para aplicaciones web. [en
linea]. Disponible en:
https://revistas.udistrital.edu.co/index.php/tia/article/download/13364/15929/
[Fecha de consulta: 24/11/2020]

[11] PRESSMAN, R. S. (2010) Ingeniería de software: Un enfoque práctico. Séptima

edición. Editorial McGraw Hill.

[12] Spring Boot. Obtenido de: https://spring.io/projects/spring-boot [Fecha de

consulta: 23/12/2020]

[13] WATERFALL: Metodología “en cascada”. Obtenido de: https://on-

time.es/portal/productividad-colectiva/waterfall-metodologia-en-cascada/
[Fecha de consulta: 01/12/2020]

67
ANEXOS

Tabla 11. Matriz de consistencia de la operacionalización de las variables

VARIABLE DEFINICIÓN DEFINICIÓN DIMENSIONES INDICADORES ITEM

CONCEPTUAL OPERACIONAL
Qué metodología- Comparación en Se realizarán -Mejora en -Porcentaje ¿Cuál es el
tiene mayor los tiempos de comparaciones tiempo del ciclo -Cantidad de porcentaje de
eficacia en el implementación en los tiempos de de desarrollo del errores. mejora en los
desarrollo de un entre Waterfall y implementación microservicio. tiempos y la
microservicio. DevOps. del microservicio -Mejora en la calidad de
Comparación en tanto Waterfall calidad de implementació
la calidad de como en DevOps. desarrollo del n de DevOps
software entre las Se realizarán microservicio. con respecto
metodologías comparaciones a Waterfall?
Waterfall y en la calidad del
DevOps microservicio
tanto Waterfall
como en DevOps

Microservicio Desarrollo del Este microservicio -Microservicio -Funcionalidad

para obtener Microservicio nos permitirá -Usabilidad
detalle de libros “Obtener Detalle obtener el detalle
en una tienda de Libros en de libros en una
virtual. Tienda Virtual” Tienda Virtual

68