Tesis
Transcript of Tesis
UNIVERSIDAD NACIONAL DE CHIMBORAZO
FACULTAD DE INGENIERÍA
CARRERA DE SISTEMAS Y COMPUTACIÓN
“Proyecto de Investigación previo a la obtención del título de Ingeniero en Sistemas y
Computación”
TRABAJO DE TITULACIÓN
METODOLOGÍA TEST DRIVEN DEVELOPMENT APLICADA EN EL DESARROLLO DEL SISTEMA DE CONTROL DE INVENTARIO PARA EL
ALMACÉN ALEJANDRA
Autor(es):
Ronald David Macas Cando
Angel Mauricio Ramos Cepeda
Tutor:
Ing. Miryan Estela Narváez Vilema
Riobamba - Ecuador
2021
ÍNDICE GENERAL
ABSTRACT..............................................................................................................................VII
INTRODUCCION......................................................................................................................8
CAPITULO I............................................................................................................................10
1. PLANTEAMIENTO DEL PROBLEMA.......................................................................10
1.1. Problema y justificación de la investigación...........................................................10
1.2. Objetivos...................................................................................................................11
1.2.1. Objetivo General..............................................................................................11
1.2.2. Objetivos específicos.........................................................................................11
CAPÍTULO II..........................................................................................................................12
2. MARCO TEÓRICO.........................................................................................................12
2.1. Introducción a las pruebas de software..................................................................12
2.2. Tests de desarrollo....................................................................................................13
2.2.1. Test Unitarios....................................................................................................13
2.2.2. Test de integración............................................................................................15
2.2.3. Test del sistema.................................................................................................16
2.3. Test Driven Development (TDD).............................................................................17
2.3.1. Principales características................................................................................18
2.3.2. Beneficios de TDD............................................................................................18
2.3.3. Algoritmo de TDD............................................................................................19
2.3.4. Ciclo Red-Green-Refactor (RGR)...................................................................20
2.4. Scrum........................................................................................................................21
2.4.1. Beneficios y componentes de SCRUM.............................................................22
2.4.2. Equipo de Scrum..............................................................................................22
2.4.3. Ciclo de vida Scrum..........................................................................................23
2.5. Herramientas de desarrollo pasar al marco teórico...............................................23
2.5.1. Java....................................................................................................................23
2.5.2. MySQL..............................................................................................................24
2.5.3. JUnit..................................................................................................................24
CAPÍTULO III.........................................................................................................................26
3. METODOLOGIA............................................................................................................26
3.1. Identificación de las Variables.................................................................................26
3.1.1. Variable independiente....................................................................................26
3.1.2. Variable dependiente........................................................................................26
II
3.2. Tipo de investigación................................................................................................26
3.3. Técnicas de investigación.........................................................................................27
3.4. Operacionalización de variables..............................................................................28
3.5. Desarrollo del sistema de inventarios......................................................................29
3.5.1. Fase de planificación........................................................................................29
3.5.2. Fase de desarrollo.............................................................................................33
3.5.3. Sistema de control de inventarios....................................................................41
3.5.4. Fase de cierre....................................................................................................53
CAPÍTULO IV.........................................................................................................................54
4. RESULTADOS Y DISCUSION......................................................................................54
4.1. Resultados.................................................................................................................54
4.1.1. Uso de JUnit como “framework” para realizar pruebas unitarias...............54
4.2. Discusión...................................................................................................................60
CONCLUSIONES....................................................................................................................61
RECOMENDACIONES..........................................................................................................61
BIBLIOGRAFÍA......................................................................................................................62
ANEXOS...................................................................................................................................67
Anexo 1: Manual de usuario................................................................................................67
Anexo 2: Manual técnico.....................................................................................................67
Anexo 3: Fotografías de las reuniones con los usuarios.....................................................67
Anexo 4: Diccionario de datos.............................................................................................67
Anexo 5: Clases del sistema.................................................................................................67
Anexo 6: Historias de usuario..............................................................................................67
Anexo 7: Pruebas unitarias..................................................................................................67
ÍNDICE FIGURAS
Figura 1. Clasificación de los tests............................................................................................12Figura 2. Algoritmo para realizar pruebas unitarias. Mejorar la calidad del diagrama con fondo tranasparente..............................................................................................................................20Figura 3. Ciclo RGR.................................................................................................................21Figura 4. Ciclo de vida Scrum mejorar la calidad de la figuara.................................................23Figura 5. Arquitectura de la aplicación.....................................................................................34Figura 6. Modelo físico de base de datos..................................................................................35Figura 7. Estructura de la clase categoría..................................................................................36Figura 8. Estructura de la clase Cliente.....................................................................................36Figura 9. Estructura de la clase Compra....................................................................................37Figura 10. Prueba unitaria para el método "agregar productos"................................................38Figura 11. Resultado de la ejecución de las pruebas unitarias...................................................39Figura 12. Refactorización del método Agregar en la clase ProductoDAO...............................39
III
Figura 13. Refactorización de la prueba unitaria.......................................................................40Figura 14. Ejecución de las pruebas unitarias............................................................................40Figura 15. Diagrama de bases de datos.....................................................................................41Figura 16. Distribución de las carpetas del proyecto.................................................................45Figura 17. Contenido del package Acceso a datos....................................................................45Figura 18. Contenido de la clase conexión................................................................................46Figura 19. Clases que conforman el package entidades.............................................................46Figura 20. Código de la clase Cliente........................................................................................47Figura 21. Clases del package dao............................................................................................47Figura 22. Código de la clase ProductoDAO y definición del método Listar productos...........48Figura 23. Clases que conforman el package controlador.........................................................49Figura 24. Clases que conforman el package vista....................................................................49Figura 25. Formulario de acceso al sistema (Login)..................................................................49Figura 26. Menú principal del sistema......................................................................................50Figura 27. Formulario "Gestión de clientes".............................................................................50Figura 28. Módulo "Gestión de productos"...............................................................................51Figura 29. Módulo "Gestión de categorías"...............................................................................51Figura 30. Módulo "Gestión de proveedores"...........................................................................52Figura 31. Formulario "Ventas"................................................................................................52Figura 32. Clases creadas para las pruebas TDD.......................................................................54Figura 33. Declaración del método init.....................................................................................55Figura 34. Definición de la prueba para el método insertar.......................................................55Figura 35. Definición de la prueba “listar todos los productos”................................................56Figura 36. Definición de la prueba "buscar dado el id del producto"........................................56Figura 37. Resultado de la ejecución de las pruebas unitarias...................................................56Figura 38. Código fuente de la prueba listar Clientes................................................................57Figura 39. Código fuente de la prueba unitaria, buscar cliente por su identificador..................57Figura 40. Código fuente del método insertar...........................................................................57Figura 41. Código fuente del test inserción masiva...................................................................58Figura 42. Código fuente del test actualización masiva.............................................................58Figura 43. Test para las búsquedas masivas de clientes............................................................59Figura 44. Salida de la ejecución de las pruebas unitarias a la clase Cliente.............................59Figura 45. Refactorización de las operaciones en la clase Cliente DAO...................................59Figura 46. Resultados de la ejecución de las pruebas unitarias en la case Cliente.....................60
ÍNDICE TABLAS
Tabla 1. Métodos de JUnit para hacer comprobaciones.............................................................13Tabla 2. Matriz de Consistencia................................................................................................26Tabla 3. Personal involucrado en el desarrollo del aplicativo....................................................30Tabla 4. Roles del sistema.........................................................................................................30Tabla 5. Método de estimación T-shirt......................................................................................31Tabla 6. Historias de usuario y técnicas....................................................................................31Tabla 7. Sprint Backlog.............................................................................................................32Tabla 8. Características de los componentes utilizados.............................................................35Tabla 9. Historia usuario 01......................................................................................................42Tabla 10. Historia usuario 02....................................................................................................42Tabla 11. Historia usuario 03....................................................................................................43
IV
Tabla 12. Historia usuario 04....................................................................................................43Tabla 13. Historia usuario 05....................................................................................................43Tabla 14. Historia usuario 06....................................................................................................43Tabla 15. Historia usuario 07....................................................................................................44Tabla 16. Historia usuario 08....................................................................................................44Tabla 17. Historia usuario 09....................................................................................................44Tabla 18. Historia de usuario 10................................................................................................45
V
RESUMEN
En el presente proyecto de investigación se desarrolla una aplicación Desktop ya que
con el continuo desarrollo de las aplicaciones se presentan más a menudo los sistemas
para automatizar los procesos internos de los almacenes o centro comerciales. El
objetivo del presente trabajo es encontrar las ventajas de trabajar con la técnica de
desarrollo guiado por pruebas (TDD) dentro de la construcción de sistemas. Para llevar
a cabo se realizó el análisis, diseño e implementación de una aplicación Desktop basada
en la Metodología SCRUM juntamente con TDD. Para el análisis entre paradigmas del
testing se utilizó las pruebas unitarias y de integración como marco de referencia para la
elaboración de un cuadro comparativo frente a TDD. Los resultados obtenidos muestran
que la técnica de desarrollo guiado por pruebas en colaboración con el framework JUnit
no simplemente abarca el testing de la aplicación, sino que conduce el diseño de esta,
mejorando el modelo de codificación de software. Además, se mantuvo un detalle de
cuando se dio un fallo sobre un test, de esta forma se pudo detectar donde estuvo el
error y corregirlo a tiempo. Además, se muestra la aceptación por parte de los usuarios
que catalogan la aplicación como confiable, disponible y eficaz a la vez para gestionar
los procesos para la administración y control de inventario del almacén Alejandra. Debe
ser 250 palabras y empezar con el tema de investigación
Palabras clave: Metodología TDD, Framework JUnit, Inventario, desarrollo guiado por
pruebas, Metodología SCRUM
VI
ABSTRACT
In this research project, a Desktop application is developed since with the continuous
development of applications, systems to automate the internal processes of warehouses
or shopping centers are presented more often. The objective of this work is to find the
advantages of working with the test-guided development (TDD) technique within the
construction of systems. To carry out the analysis, design and implementation of a
Desktop application based on the SCRUM Methodology was carried out together with
TDD. For the analysis between testing paradigms, unit and integration tests were used
as a frame of reference for the elaboration of a comparative table against TDD. The
results obtained show that the test-guided development technique in collaboration with
the JUnit framework does not simply cover the testing of the application, but also leads
its design, improving the software coding model. In addition, a detail of when a failure
occurred on a test was kept, in this way it was possible to detect where the error was and
correct it in time. In addition, it shows the acceptance by the users who classify the
application as reliable, available and efficient at the same time to manage the processes
for the administration and inventory control of the Alejandra warehouse.
Keywords: TDD methodology, JUnit framework, inventory control, test-driven
development, SCRUM methodology
VII
INTRODUCCION
Uno de los desafíos más grandes es garantizar la calidad de los productos de software y
mejorar la productividad a lo largo del ciclo de vida, desde el comienzo del desarrollo
hasta las etapas de mantenimiento. Este es un reto enorme porque actualmente los
requerimientos son más volátiles que en el pasado, potencialmente se introducen
muchos errores, ocasionando que funcionalidades ya implementadas empiecen a fallar,
aparecen muchas fallas o errores, llamados “Bugs” en la etapa de mantenimiento. (Vaca
et al., 2013)
En varias metodologías de software ya sean las tradicionales y/o ágiles, el equipo
desarrollador primero se preocupa en cómo definir su arquitectura. TDD se trata de una
técnica para que el código tenga una cobertura de tests muy alta, algo que siempre es
deseable, pero es realmente una herramienta de diseño que convierte al programador en
un “oficial de primera”. O, si no les gustan las metáforas, convierte al programador en
desarrollador. (Jurado, 2010) mejorar la idea
Según el autor Bill Caputo (Año) se adopta una posición más sistémica en la práctica de
TDD. La posición es, que al presentar el desarrollo de software como un sistema de
actividades y mostrar cómo TDD encaja con estos otros usos de pruebas para lograr el
objetivo general del sistema (entregar código de alta calidad a tiempo por debajo del
presupuesto según las especificaciones del cliente) es más fácil centrar la atención de las
personas en TDD como diseño, y ayuda a facilitar su aceptación de la noción de que
"Sí, está bien que los programadores escriban pruebas". (Steven et al., 2003)
Se realizará una aplicación de escritorio de control de inventario para el Almacén
Alejandra, para el desarrollo del software se utilizará la metodología de diseño de
software TDD por ser una metodología de desarrollo ágil cuya mayor fortaleza es
escribir la mínima cantidad de código posible para obtener el resultado deseado, el
mismo que será implementado en el framework Junit.
El presente trabajo de investigación está conformado por VI apartados, que se detallan
a continuación: el apartado I presenta la introducción al proyecto de
investigación, el apartado II abarca el planteamiento del problema, en el apartado III se
encuentran los objetivos planteados en el proyecto de investigación, el apartado IV
8
contiene el estado del arte relacionado a la temática, la metodología a utilizar se detalla
en el apartado V y finalmente el presupuesto y cronograma establecido para el proyecto
de investigación se encuentra en el apartado VI. Se repite demasiado las palabras
9
CAPITULO I
1. PLANTEAMIENTO DEL PROBLEMA
1.1. Problema y justificación de la investigación
Debido a la cantidad de productos que tiene el Almacén Alejandra y con la necesidad de
adaptarse hacia un entorno tecnológico, se ve en la necesidad de adquirir un sistema que
automatice las diferentes actividades diarias que se efectúan en la misma. Con la
finalidad de solucionar el problema antes expuesto, se desarrollará el sistema propuesto
mediante el empleo de herramientas de software libre como son: el Framework Junit
que permite desarrollar aplicaciones de escritorio mediante el lenguaje programación
Java y para la persistencia de los datos se empleará el sistema gestor de bases de datos
MySQL, uno de los sistemas más utilizados en el desarrollo de aplicaciones tanto de
escritorio como web.
En los últimos años se han desarrollado un conjunto de frameworks denominados XUnit
que facilitan la elaboración de pruebas unitarias en diferentes lenguajes. JUnit es un
framework de código abierto creado por Erich Gamma y Kent Beck que se utiliza para
escribir y ejecutar los tests de aplicaciones escritas en Java. Este framework se ha
popularizado por la comunidad de Extreme Programming (XP) y es ampliamente
utilizado por los desarrolladores que implementan casos de pruebas unitarias en Java.
En los últimos años, se convirtió en el estándar de facto de los tests unitarios, JUnit
incluye formas para presentar los resultados de las pruebas que pueden ser en modo
texto, gráfico (AWT o Swing). Las pruebas se representan en JUnit como clases Java y
pueden definir cualquier cantidad de métodos públicos de prueba. (Palacios, 2009)
Para guiar la correcta organización del proyecto se utilizará el marco de trabajo
SCRUM conjuntamente con la metodología TDD (Desarrollo guiado por pruebas) la
cual es considerada como una práctica de programación que consiste en escribir primero
las pruebas (generalmente unitarias), después escribir el código fuente que pase la
prueba satisfactoriamente y por último refactorizar el código escrito, consiguiendo con
esto un código más robusto, seguro, mantenible y una mayor rapidez en el desarrollo.
10
El desarrollo del trabajo de investigación consta del control de inventario a través del
framework JUnit, permitiendo refactorizar de mejor manera el código obteniendo
eficiencia de uso. El desarrollo de los tests se los realizará a través de una metodología
ágil denominada TDD, en ella se mostrará las estimaciones efectuadas a partir de un
formato de información proporcionado por la empresa. Se repite la información
La utilización de TDD es para anticipar, identificar y corregir fallas durante la creación
del software, las pruebas deben ser escritas en código, y esto permite que se ejecuten
automáticamente las veces que sea necesario, el solo hecho de ejecutar las pruebas debe
mostrar si la ejecución fue correcta o no, también mantiene la calidad de la arquitectura,
se cambia el diseño sin cambiar la funcionalidad, manteniendo las pruebas. Mejorar la
idea, falta la justificación
1.2. Objetivos
1.2.1. Objetivo General
Aplicar la Metodología TDD (desarrollo orientado por pruebas) en el desarrollo del
sistema de control de inventario para el almacén Alejandra.
1.2.2. Objetivos específicos
Investigar la metodología de desarrollo dirigido por pruebas (TDD) al igual que
el Framework JUnit.
Planificar y aplicar pruebas unitarias Test Driven Development durante el
desarrollo del caso práctico.
Desarrollar el sistema de control de inventario para el Almacén Alejandra
utilizando el código refactorizado en base a la Metodología SCRUM.
11
CAPÍTULO II
2. MARCO TEÓRICO
2.1. Introducción a las pruebas de software
Las pruebas de software son una parte integral del ciclo de vida del desarrollo de
software, constituyen una forma de estar seguro sobre las funcionalidades, el
rendimiento y la experiencia del usuario. Éstas pruebas pueden realizarse manualmente
o a través de procesos automatizados, cuanto antes y más a menudo pueda llevar a cabo
pruebas, más probable es que identifique errores, garantizando que el software ha sido
revisado y auditado a fondo, antes de que esté frente a sus usuarios. Referenciar
Dentro de la ingeniería de software generalmente se distinguen dos tipos de test, los
escritos por desarrolladores y los escritos por el dueño del producto, cabe recalcar que el
dueño del producto es el analista de negocio o bien el propio cliente. Lo ideal y
recomendado es que el desarrollador ayude al cliente a escribir los tests para asegurarse
de que las afirmaciones están totalmente libres de ambigüedad. Referenciar
2.2. Tests de desarrollo
En un test se considerar tres partes fundamentales AAA (por sus siglas en inglés.),
ARRANGE (Preparar), ACT (Actuar), ASSERT (Afirmar).
Parte de la codificación ARRANGE puede estar contenida en el método setUp,
si es común para los test de la clase.
ACT consiste en hacer la llamada al SUT.
ASSERT se hacen sobre el resultado de la ejecución, utilizando validaciones de
estado o validaciones de interacción. Mejorar la descripción y referenciar, buscar
de forma general que hacen
La Tabla 1, muestra los métodos para hacer comprobaciones utilizando el Framework
JUnit.
Tabla 1. Métodos de JUnit para hacer comprobaciones.
Método ASSERT () JUnit DESCRIPCIÓN
assertTrue(expresión) Comprueba que expresión evalúe a true.
assertFalse(expresión) Comprueba que expresión evalúe a false.
12
assertEquals(esperado, real) Comprueba que esperado sea igual a real
Assert Null(Objeto) Comprueba que objeto sea null
Assert NotNull(Objeto) Comprueba que objeto no sea null
AssertSame(Objeto_esperado,
objetivo_real)Comprueba que objeto_esperado y objeto_real sean el mismo objeto
Assert
NotSame(Objeto_esperado,
objetivo real)
Comprueba que el objetivo_esperado no sea el mismo objetivo que el
objetivo_real.
fail() Hace que el test termine con fallo.
Fuente: Elaboración propia.
2.2.1. Test Unitarios
Se encarga específicamente de probar pequeñas partes del software de una manera
independiente, como por ejemplo un modelo.
Se caracterizan por ser: Atómicos, independiente, inocuo, rápido.
Atómico, significa que el test prueba la mínima cantidad de funcionalidad posible. Esto
es, probará un solo comportamiento de un método de una clase. El mismo método
puede presentar distintas respuestas ante distintas entradas o distinto contexto. El test
unitario se ocupará exclusivamente de uno de esos comportamientos, es decir, de un
único camino de ejecución.
A veces, la llamada al método provoca que internamente se invoque a otros métodos;
cuando esto ocurre, decimos que el test tiene menor granularidad, o que es menos fino.
Lo ideal es que los tests unitarios ataquen a métodos lo más planos posibles, es decir,
que prueben lo que es indivisible. La razón es que un test atómico nos evita tener que
usar el depurador para encontrar un defecto en el SUT1, puesto que su causa será muy
evidente.
En la parte práctica, se presentan situaciones donde vale la pena ser menos estrictos con
la atomicidad del test, para evitar abusar de los dobles de prueba.
Utilizar UML para entender de mejor
Independiente, significa que un test no puede depender de otros para producir un
resultado satisfactorio. No puede ser parte de una secuencia de tests que se deba ejecutar
1 System Under Test
13
en un determinado orden. Debe funcionar siempre igual independientemente de que se
ejecuten otros tests o no.
Inocuo, significa que no altera el estado del sistema. Al ejecutarlo una vez, produce
exactamente el mismo resultado que al ejecutarlo veinte veces. No altera la base de
datos, ni envía emails ni crea ficheros, ni los borra. Es como si no se hubiera ejecutado.
Rápido, tiene que ser porque ejecutamos un gran número de tests en pocos minutos y se
ha demostrado que tener que esperar unos cuantos segundos cada rato, resulta muy
improductivo. Un sólo test tendría que ejecutarse en una pequeña fracción de segundo.
La rapidez es tan importante que Kent Beck desarrolló la herramienta “JUnit Max” que
ejecuta los tests desde el IDE Eclipse mientras se continúa escribiendo código, para
evitar dejar de trabajar en código mientras se espera el resultado de la ejecución.
Para conseguir cumplir estos requisitos, un test unitario aísla la parte del SUT que
necesita ejercitar de tal manera que el resto está inactivo durante la ejecución.
Principalmente existen dos formas de validar el resultado de la ejecución del test:
validación del estado y validación de la interacción, o del comportamiento. Utilizar una
descripción más técnica o utilizar diagramas
Los desarrolladores emplean los tests unitarios para asegurarse de que el código
funciona correctamente, al igual que el cliente usa los tests de cliente para asegurarse
que los requisitos de negocio se alcancen como se espera que lo hagan.
2.2.2. Test de integración
Se encargan de probar la integración entre dos o más componentes, para ello pueden
utilizar dependencias, usar datos reales, siempre y cuando no afecte el estado de la
aplicación antes de aplicar dicha prueba.
Típicamente, también se escriben usando herramientas xUnit y tienen un aspecto
parecido a los tests unitarios, sólo que estos pueden romper las reglas. Como su nombre
indica, integración significa que ayuda a unir distintas partes del sistema. Un test de
integración puede escribir y leer de base de datos para comprobar que, efectivamente, la
lógica de negocio entiende datos reales.
14
Es el complemento a los tests unitarios, donde habíamos falseado el acceso a datos para
limitarnos a trabajar con la lógica de manera aislada. Un test de integración podría ser
aquel que ejecuta la capa de negocio y después consulta la base de datos para afirmar
que todo el proceso, desde negocio hacia abajo, fue bien. Son, por tanto, de granularidad
más gruesa y más frágiles que los tests unitarios, con lo que el número de tests de
integración tiende a ser menor que el número de tests unitarios.
Una vez que se ha probado que dos módulos, objetos o capas se integran bien, no es
necesario repetir el test para otra variante de la lógica de negocio; para eso habrá varios
tests unitarios. Aunque los tests de integración pueden saltarse las reglas, por motivos
de productividad es conveniente que traten de ser inocuos y rápidos. Si tiene que
acceder a base de datos, es conveniente que luego la deje como estaba. Por eso, algunos
frameworks para Ruby y Python entre otros, tienen la capacidad de crear una base de
datos temporal antes de ejecutar la batería de tests, que se destruye al terminar las
pruebas.
Como se trata de una herramienta incorporada, también hay quien ejecuta los tests
unitarios creando y destruyendo bases de datos temporales, pero es una práctica que
debe evitarse porque los segundos extra que se necesitan para eso nos hacen perder
concentración. Los tests unitarios deben pertenecer a suites diferentes a los de
integración para poderlos ejecutar por separado. En los próximos capítulos tendremos
ocasión de ver tests de integración en detalle. Poner descripciones técnicas
2.2.3. Test del sistema
Poseen como objetivo principal realizar las pruebas al sistema, ejecutándolo como lo
haría un usuario final, iniciando en la interfaz hasta llegar al guardado de datos.
(Moisés, 2019)
Es el mayor de los tests de integración, ya que integra varias partes del sistema. Se trata
de un test que puede ir, incluso, de extremo a extremo de la aplicación o del sistema. Se
habla de sistema porque es un término más general que aplicación, pero no se refiere a
administración de sistemas, no es que estemos probando el servidor web o el servidor
SMTP aunque, tales servicios, podrían ser una parte de nuestro sistema.
15
Así pues, un test del sistema se ejercita tal cual lo haría el usuario humano, usando los
mismos puntos de entrada (aquí sí es la interfaz gráfica) y llegando a modificar la base
de datos o lo que haya en el otro extremo.
Existen muchas formas de probar un sistema. Supongamos que hemos implementado un
servidor web ligero y queremos validar que, cada vez que alguien accede a una página,
se registra su dirección IP en un fichero de registro (log). Podríamos hacer un script con
algún comando que se conecte a una URL del servidor, al estilo de Wget desde la
misma máquina y después buscar la IP 127.0.0.1 en el fichero de log con Grep. Sirva el
ejemplo para recalcar que no hay una sola herramienta ni forma de escribir tests de
sistema, más bien depende de cada sistema.
Los tests de sistema son muy frágiles en el sentido de que cualquier cambio en
cualquiera de las partes que componen el sistema, puede romperlos. No es
recomendable escribir un gran número de ellos por su fragilidad. Si la cobertura de otros
tipos de tests de granularidad más fina, como por ejemplo los unitarios, es amplia, la
probabilidad de que los errores sólo se detecten con tests de sistema es muy baja.
En un proyecto con TDD, no es productivo escribir tests de sistema para todas las
posibles formas de uso del sistema, ya que esta redundancia se traduce en un aumento
del costo de mantenimiento de los tests. Poner descripciones técnicas
2.3. Test Driven Development (TDD)
Para Haq (2017) TDD es una metodología de diseño e implementación de software
guiado por pruebas, creado a partir de la metodología ágil XP, por tanto, se considera
una técnica de programación de software que consiste en dos procesos prácticas
principales: escribir una prueba y refactorizar el código.
El Desarrollo orientado por pruebas, es una de las metodologías con mayor acogida en
el campo profesional y que continúa expandiéndose debido a sus buenos resultados. La
tendencia actual es integrar TDD independientemente de cualquier metodología ágil o
tradicional y aprovechar los beneficios (deshacer los errores), asegurando una calidad
del producto y protegerse de errores tanto malintencionados como humanos. (Balaguera,
2015).
16
Según (Vaca, y otros, 2013) TDD permite aplicar modelos de calidad, está considerado
como una metodología de diseño que tiene un proceso extenso, por esta razón, para
alcanzar el objetivo TDD se debe crear un hábito en el desarrollador de software, esto
permitirá alcanzar mejores resultados en los procedimientos. Esta técnica busca que el
desarrollador entienda la lógica de negocio como fase inicial antes de iniciar a escribir
cualquier línea de código, sin siquiera tener una idea clara del rumbo que persigue el
proyecto, logrando con esta premisa, obtener código limpio pero que funciona.
La metodología TDD tranquilamente puede ser utilizada en proyectos de diferente
tamaño, ya que un proyecto grande está dividido por varios subproyectos, para efecto
resulta beneficioso trabajar con esta técnica como si fueran proyectos pequeños donde
para lograr este objetivo, tan solo es necesario separar el proyecto en pequeños módulos
que posteriormente serán integrados para realizar las entregas del producto. La
metodología TDD permite optimizar procesos, garantizando una importante mejoría en
el rendimiento del equipo desarrollador, debido a que entrega como resultado final un
producto de software robusto, mantenible y de calidad. Para ejecutar de una manera
correcta la metodología de trabajo TDD, se puede utilizar una metodología de desarrollo
de software ágil como SCRUM o Programación Extrema, resulta muy beneficioso,
debido a que, se puede trabajar correctamente con el listado las tareas que van a ser
utilizadas para dar solución al proyecto. (Ress et al, 2013)
2.3.1. Principales características
Evitar escribir código innecesario, se intenta escribir el mínimo posible, y si el
código pasa una prueba y falla, da una idea de cómo modificar la lista de
requerimientos (tests unitarios) agregando nuevos.
Generar pruebas para cada funcionalidad, hace que el desarrollador confíe en
el código escrito. Esto facilita futuras modificaciones, ya que si se logra asegurar
el paso de todas las pruebas se obtendrá un código que funcione correctamente.
TDD requiere que el desarrollador haga fallar los casos de prueba, se
intenta asegurar el funcionamiento de los casos de prueba y de esta forma pueda
recoger un error.
El desarrollo guiado por pruebas (TDD), puede proporcionar un gran valor
agregado en la creación de software, produciendo aplicaciones de calidad y en
menos tiempo.
17
TDD tiene la capacidad de avanzar en pequeños pasos, permite al
desarrollador centrarse en la tarea actual y hacer que el test pase. Todo el
proyecto se encuentra cubierto de pruebas, aumentado la confianza sobre lo
desarrollado.
Utilizar diagramas o poner una descripción técnica
Diagrama de las características
2.3.2. Beneficios de TDD
Según (Adewole, 2018) cuando TDD se aplica correcta y apropiadamente tiene los
siguientes beneficios:
● Facilita el desarrollo de pruebas.
● Produce aplicaciones de software robustas con menos o ningún error.
● Las pruebas son una documentación en miniatura del código fuente, sirven como
una forma rápida de comprender cómo funciona una parte del código.
● La estructura de una aplicación se puede entender fácilmente a partir de la
prueba, habrá pruebas para todos los objetos, así como pruebas para los métodos
de los objetos, mostrando su uso.
● Ayuda a escribir código elegante con buena abstracción, diseño flexible y
arquitectura.
● El código se puede mantener fácilmente, es legible y tiene pruebas escritas para
validar su comportamiento consistente de manera apropiada.
2.3.3. Algoritmo de TDD
Secuencia de pasos para el ciclo TDD.
1. Escribir una prueba unitaria: Seleccionar una funcionalidad del sistema y escribir
una prueba con un criterio el más simple posible.
2. Ejecutar la prueba y comprobar que la misma falla.
18
3. Escribir código: Escribir una porción de código que brinde solución momentánea a
la prueba unitaria, siendo no necesario que el código se encuentre perfectamente
optimizado.
4. Ejecutar las pruebas: Automatizar las pruebas con el fin de verificar que todas las
pruebas continúen al siguiente paso, de no resultar exitoso, corregir el código hasta
que todo sea satisfactorio.
5. Refactorizar: Mejorar el código con el fin de eliminar código duplicado.
6. Repetir: Iniciar nuevamente con otra prueba unitaria, no obstante, se debe
mencionar que este proceso se repite una y otra vez hasta finalizar el desarrollo del
producto software. (Beck, 2002, p. 11) Poner más técnico
Figura 1. Algoritmo para realizar pruebas unitarias. Mejorar la calidad del diagrama con fondo tranasparente
Fuente: (Ambler, 2019)
2.3.4. Ciclo Red-Green-Refactor (RGR)
Test Driven Development es un proceso que se basa en la repetición de un ciclo de
desarrollo muy corto. Se basa en el primer concepto de extreme programming (XP) que
fomenta el diseño simple con un alto nivel de confianza. El procedimiento que impulsa
este ciclo se llama red-green-refactor. (Farcic & Garcia, 2015)
El ciclo RGR se deriva del algoritmo TDD, siendo usualmente, pero de manera no tan
estricta ejecutado en cada prueba unitaria que haya sido completada. RGR es un proceso
con tres estados:
19
1) Red indica que una vez obtenido el requisito se debe crear una prueba que falle.
2) Green indica dar solución a la prueba creada escribiendo cierta cantidad de
código temporal.
3) Refactor se elimina la duplicidad de código fuente, si existiera. (Cruz &
Vladimir, 2016) poner lo más específico posible
Figura 2. Ciclo RGR.Fuente: (Cruz & Vladimir, 2016, p.46)
Como se muestra en la Figura 3, el estado de la refactorización se constituye en una
actividad que se realiza de manera constante en cada una de las pruebas unitarias
durante el desarrollo del proyecto. La finalidad de los pasos mencionados es, que el
desarrollo está intentando dirigir hacia una arquitectura limpia, independiente de
organismos externos. (Gałęzowski, 2014)
El procedimiento en sí es simple y consta de seis pasos que se repiten una y otra vez.
1. Escribe una prueba
2. Ejecutar todas las pruebas
3. Escribe el código de implementación
4. Ejecuta todas las pruebas
5. Refactorización
6. Ejecuta todas las pruebas. (Farcic & Garcia, 2015)
20
2.4. Scrum
Es una metodología para el desarrollo de software iterativa e incremental, iterativa por
que se ejecuta en bloques temporales cortos y fijos (de no menos de dos semanas),
reciben el nombre de sprints, e incremental en tanto se obtienen funcionalidades del
producto final al terminar cada iteración. (Salazar & Valbuena, 2018)
2.4.1. Beneficios y componentes de SCRUM
Según (Fuentes, 2015) los beneficios y componentes de la metodología Scrum son los
siguientes:
• Comunicación.
• Trabajo en equipo.
• Flexibilidad.
• Proveer un software funcional de manera incremental.
Los componentes de Scrum son:
• Backlog.
• Equipos de desarrollo.
• Sprints.
• Reuniones diarias.
• Reuniones de revisiones.
• Presentación de demos.
2.4.2. Equipo de Scrum
Product Owner: responsable de maximizar el trabajo.
Scrum Máster: el que tiene más contacto con el cliente.
Equipo de desarrollo: encargados de realizar las tareas propuestas por el product
owner.
21
2.4.3. Ciclo de vida Scrum
Figura 3. Ciclo de vida Scrum mejorar la calidad de la figuaraElaborado por: Los autores
2.5. Herramientas de desarrollo pasar al marco teórico
2.5.1. Java
Es un lenguaje de programación de alto nivel orientado a objetos de reciente creación.
Fue desarrollado por la empresa Sun Microsystems a principios de los años 90, y
presentado oficialmente en mayo de 1995 en la conferencia Sun World. (Abenza, 2015)
Es un lenguaje de programación de propósitos generales, se puede utilizar para
desarrollar el mismo tipo de aplicaciones que se programa con otros lenguajes como: C,
VB, PHP, JavaScript o Pascal. (Sznajdleder, 2016)
Tabla 1. Características Java
Característica Descripción
FamiliarFacilita la migración de aquellos desarrolladores ya familiarizados con lenguajes como C o C++.
SencilloPuede tener una curva de aprendizaje dura, el conocer otros lenguajes de programación similares facilita su aprendizaje.
MultiplataformaFue diseñado para ser (WORA), es decir, escribir y compilar una vez en una plataforma y ejecutar en cualquier otra, sin necesidad de modificar el código fuente, ni siquiera de recompilar.
Alto rendimiento No son tan rápidos como los desarrollados con otros lenguajes que se compilan de forma nativa para una plataforma concreta, sin embargo, tampoco son tan lentos como los lenguajes que son exclusivamente
22
interpretativos.
Robusto
Durante la compilación se comprueba la sintaxis y ciertas situaciones que en otros lenguajes no, pudiendo dar resultados inesperados. Posteriormente durante la ejecución se vuelve a dar otras comprobaciones, por lo que resulta un poco robusto el programa.
Orientado a objetosSigue este paradigma de programación, que es el más utilizado en la actualidad.
DistribuidoDispone de una librería de clases que permite la comunicación entre programas ejecutados en ordenadores remotos conectados por red.
ConcurrentePermite el desarrollo de aplicaciones concurrentes o multi-hilo para conseguir un mejor rendimiento (Abenza, 2015).
Fuente: Elaboración propia a partir de Sznajdleder (2016) y Abenza (2015).
2.5.2. MySQL
Es un sistema gestor de bases de datos (SGBD, DBMS por sus siglas en inglés) muy
conocido y ampliamente usado por su simplicidad y notable rendimiento. Aunque
carece de algunas características avanzadas, disponibles en otros SGBD del mercado, es
una opción atractiva tanto para aplicaciones comerciales, como de entretenimiento
precisamente por su facilidad de uso y tiempo reducido de puesta en marcha. Esto y su
libre distribución en Internet bajo licencia GPL le otorgan como beneficios adicionales
(no menos importantes) contar con un alto grado de estabilidad y un rápido desarrollo.
(Casillas, Ginestà, & Pérez, 2014)
Tabla 2. Ventajas y desventajas de MySQL
Ventajas Desventajas
MySQL es de uso libre y gratuito.
Al ser de Software Libre, muchas de las soluciones para las deficiencias del software no están documentados ni presentan documentación oficial.
Software con Licencia GPL. Muchas de sus utilidades tampoco presentan documentación.
Entorno con seguridad y encriptación.No es el más intuitivo de los programas que existen actualmente para todos los tipos de desarrollos.
Fuente: Elaboración propia a partir de Casillas, Ginestà, & Pérez (2014)
2.5.3. JUnit
Es un framework de código abierto, creado y desarrollado por Erich Gamma y Kent
Beck, para la creación de pruebas unitarias en el lenguaje Java. Su propósito es ser una
base para la creación de código de automatización de pruebas. Es muy utilizado para la
práctica de TDD y su mismo modelo se utilizó en la creación de frameworks de prueba
23
para otros lenguajes, siendo estos frameworks referenciados en general como XUnit. No
se entiende muy bien la idea
Algunas características principales de dichos marcos son la ejecución de casos de
prueba y la visualización de resultados de ejecución. (Guerra & Ivo, 2017)
Tabla 3. Anotaciones
Anotación Descripción
@Testpublic voidmethod()
La anotación @Test identifica un método como método de prueba
@Test (expected = Exception.class)
Falla si el método no lanza la excepción nombrada
@Test(timeout=100) Falla si el método tarda más de 100 milisegundos
@Before public void method()
Este método se ejecuta antes de cada prueba. Se utiliza para preparar la prueba. entorno (por ejemplo, leer datos de entrada, inicializar la clase)
@After public void method()
Este método se ejecuta después de cada prueba. Se usa para limpiar la prueba. entorno (por ejemplo, eliminar datos temporales, restaurar valores predeterminados). También puede ahorre memoria limpiando costosas estructuras de memoria.
@BeforeClass public static void method()
Este método se ejecuta una vez, antes del inicio de todas las pruebas. Es usado para realizar actividades que requieren mucho tiempo, por ejemplo, para conectarse a una base de datos. Los métodos marcados con esta anotación deben definirse como estáticos paratrabajar con JUnit.
@AfterClass public static void method()
Este método se ejecuta una vez, una vez finalizadas todas las pruebas. Esta usado para realizar actividades de limpieza, por ejemplo, para desconectarse de una base de datos. Los métodos anotados con esta anotación deben definirse como estáticos para trabajar con JUnit.
@Ignore or @Ignore("Why disabled")
Este método se ejecuta una vez, una vez finalizadas todas las pruebas. Esta usado para realizar actividades de limpieza, por ejemplo, para desconectarse de una base de datos. Los métodos anotados con esta anotación deben definirse como estáticos para trabajar con JUnit.
Fuente: Elaboración propia a partir de Guerra & Ivo (2017).
24
CAPÍTULO III
3. METODOLOGIA
La investigación ha sido abordada desde el enfoque cuantitativo y de tipo de
investigación cuasi experimental. Tiene como atención primordial utilizar la
metodología Test Driven Development, para evaluar la calidad del código de las
operaciones CRUD (Crear, Leer, Actualizar, Eliminar) en la base de datos. El código
debe cumplir con una buena legibilidad, debe estar ausente de duplicaciones,
redundancias y conservar un alto nivel de mantenibilidad. Su principal objetivo es
obtener código limpio que trabaje.
3.1. Identificación de las Variables
3.1.1. Variable independiente
Metodología Test Driven Development.
3.1.2. Variable dependiente
Sistema de gestión y control de inventario.
3.2. Tipo de investigación
El proyecto estará enfocado en una investigación cuantitativa, dado que se trata de
obtener porcentajes de calidad de código a través de la aplicación de la Metodología
Test Driven Development en el framework Junit.
La investigación-acción es un proceso que busca la interpretación a través del uso de la
investigación activa, con la intención de provocar un cambio positivo de orden
tecnológico. Esta definición implica que la investigación-acción obliga a combinar la
teoría con la práctica, así como también se hace necesario el uso de la observación,
participación, planificación y la reflexión. Esta metodología consta de cinco pasos:
1. Diagnóstico: Investigación del Estado del arte, análisis de las buenas prácticas,
técnicas, herramientas y formalismos existentes. Además, el diseño de la
propuesta.
25
2. Planificación de la acción: Determinación de los ajustes y pasos necesarios
para implementar la propuesta metodológica con el caso de estudio.
3. Tomar la acción: Se debe aplicar la propuesta en el proyecto.
4. Evaluación: Se debe evaluar la propuesta con los entregables alcanzados y se
refinará la misma para obtener la primera versión.
5. Especificación del aprendizaje: Se establecerán las conclusiones de acuerdo
con los resultados. Analizar bien la metodología, esta no se aplica a la
investigación
3.3. Técnicas de investigación
Para el desarrollo del trabajo de investigación, se utilizarán 3 técnicas: la observación,
entrevista y análisis documental.
Observación. – permitió identificar los procesos de compra, venta y control de
productos que actualmente maneja el Almacén Alejandra.
La entrevista. – comunicación interpersonal establecida entre los
desarrolladores y el dueño de la empresa, a fin de obtener respuestas verbales a
los interrogantes planteados sobre el problema propuesto, la entrevista estuvo
enfocada en definir requerimientos e identificar el funcionamiento de cada uno
de los procesos.
En el análisis documental. – es un procedimiento sistemático para revisar
documentos dentro de una perspectiva de estudio. El análisis documental estará
enfocado en la revisión de literatura acerca de la metodología TDD.
26
3.4. Operacionalización de variables
Tabla 2. Matriz de ConsistenciaVariable Tipo Descripción Dimensión Indicadores
Metodología Test
Driven
Development.
Independiente
El desarrollo basado en pruebas es
una técnica para crear software de
forma incremental, en pocas
palabras, no se escribe ningún
código de producción sin antes
escribir una prueba unitaria
fallida. (Grenning, 2011)
Metodología
Pruebas Unitarias.
Líneas de código.
JUnit fases:
1. Rojo – pruebas fallidas.
2. Amarillo – refactorización de
código.
3. Verde – pruebas aceptadas.
Sistema de gestión y
control de
inventario.
Dependiente
Es una herramienta de gestión,
empleada para registrar las
cantidades de mercancías
existentes en un negocio, así como
para determinar el costo de los
productos vendidos. (Chile, 2019)
Software Número de módulos generados.
Utilizando el código refactorizado.
Fuente: Elaboración propia.
27
3.5. Desarrollo del sistema de inventarios
En este apartado se describen el desarrollo del sistema de inventarios, los modelos de
ingeniería del software, prototipos, implementación de la metodología de desarrollo orientado
por pruebas (TDD), la construcción de la aplicación y la evaluación de calidad de la
aplicación. Esto suele verse reflejado en la siguiente estructura de apartados.
3.5.1. Fase de planificación
En esta fase se realiza un estimado de las actividades necesarias para desarrollar el aplicativo,
entre las cuales constan: recolección de información, selección de herramientas, pruebas
TDD, implementación del sistema y capacitación de usuarios.
3.5.1.1. Personal involucrado en el proyecto
Utilizando la metodología Scrum se utilizan los siguientes roles:
Scrum Máster es la persona que dirige al grupo de trabajo verificando que los requerimientos
planteados en el proyecto sean cumplidos en su totalidad.
Team se denomina al grupo de trabajo y son las personas que están a cargo de desarrollar el
código del sistema, a su vez, para dar cumplimento deben seguir una planificación y realizar
las historias de usuario de cada funcionalidad que fueron establecidas en cada Sprint. El
usuario es el destinatario final quien solicito el sistema.
Tabla 3. Personal involucrado en el desarrollo del aplicativoRol Persona ContactosProduct Owner Gerente del Almacén Alejandra
Scrum Master Ing. Miryan Estela Narváez VilemaTutor de Tesis
Team Ronald David Macas CandoÁngel Mauricio Ramos Cepeda
Fuente: Elaboración propia.
Roles del sistema
La Tabla 4, describe los tipos de roles para los usuarios.
Tabla 4. Roles del sistemaRol Descripción Responsabilidades
28
Administrador Persona responsable de
administrar sistema.
Gestiona el personal de la empresa,
compras, ventas, administrar el almacén,
realizar el control de productos y generar
informes, reportes gráficos y en formato
pdf.
Vendedor Persona que se encarga
del área de ventas. Gestionar las ventas.
Fuente: Elaboración propia
3.5.1.2. Pila del producto (Product Backlog)
Product Backlog se utiliza para listar las funcionalidades determinadas, en conjunto con el
Product Owner luego de realizar varias reuniones planificadas. Con esta herramienta se logra
dar una estimación y prioridad a los requerimientos planteados de acuerdo con las necesidades
requeridas por el negocio. Esta herramienta utiliza una tarjeta de trabajo conocida como
historia de usuario.
3.5.1.3. Product Backlog
Una vez definido los requerimientos de acuerdo con su prioridad y tomando en cuenta la
complejidad de cada uno, se emplea la especificación de requerimientos, permitiendo
transformar a historias de usuario. En las reuniones efectuadas con el cliente y una vez
finalizado y analizado los resultados se obtuvo treinta y siete requerimientos, de los cuales se
tiene; ocho historias técnicas y veinte nueve historias de usuario. La duración del proyecto
tiene 6 meses desde la primera reunión con el dueño del local hasta llegar a la implantación
del sistema.
En la Tabla 6, se detalla las historias de usuario e historias técnicas utilizadas en desarrollo
del sistema.
Tabla 5. Historias de usuario y técnicas.Código Descripción Esfuerzo
HT-01 Establecer los requerimientos del sistema 18HT-02 Establecer la arquitectura del sistema 18HT-03 Diseño de Estándar de Codificación 6HT-04 Diseño del estándar de interfaz 18
HT-05 Realizar la Base Datos (Modelo entidad relación, lógico, físico, script diccionario de datos) 12
29
HU-01 Ingresar categoría 12HU-02 Modificar categoría 12HU-03 Agregar vigencia de categoría 12HU-04 Gestión productos 12HU-05 Agregar productos 12HU-06 Modificar productos 12HU-07 Buscar para el módulo almacén 12HU-08 Establecer vigencia de producto 12HU-09 Reportes para módulo almacén 12HU-10 Crear sesión de usuarios 18HU-11 Gestionar roles 12HU-12 Asignar funcionalidad de acuerdo con el rol de usuario 12HU-14 Buscar y visualizar usuarios empleados de la empresa 6HU-15 Gestionar proveedores 12HU-16 Gestionar compras a proveedores 12HU-17 Consultar compras por fecha, mes 12HU-18 Buscar proveedores 6HU-19 Historial de precios 6HU-20 Reportes para el módulo proveedores 12HU-21 Gestionar clientes 12HU-22 Gestionar venta 24HU-23 Consultar ventas por día, fecha, mes 12HU-24 Reportes para el módulo ventas 12HU-25 Administrar caja 24Hu-26 Historial de caja 12HU-27 Generar Inventario 24HU-28 Resumen de saldos y movimiento de productos. 30HU-29 Graficas estadísticas de compras y ventas. 30HT-07 Capacitación de usuarios 18HT-08 Documentación final del Sistema 24
Fuente: Elaboración propia.
Con las historias listadas en el Product Backlog, se realiza varias acciones como: ingresar,
modificar, listar, buscar, reportes y visualización de gráficos estadísticos. Todas estas se
encuentran distribuidas en los Sprint.
3.5.1.4. Sprint Backlog
Con el objetivo de establecer un cronograma de actividades del presente proyecto y que
además permita coordinar con el usuario y el personal encargado las fechas de los entregables
del sistema, se realiza una distribución de Sprint teniendo como fecha de inicio 06 de marzo y
fecha de finalización 06 de agosto de 2021, se detallan en la Tabla 7.
30
Tabla 6. Sprint Backlog
ID Descripción FechaInicio
FechaFin Esfuerzo
SPRINT 1 60
HT-01 Establecer los requerimientos del sistema 18
HT-02 Establecer la arquitectura del sistema 18
HT-03 Diseño de Estándar de Codificación 6
HT-04 Diseño del estándar de interfaz 18SPRINT 2 60
HT-05 Realizar la Base Datos (Modelo entidad relación, lógico, físico, script diccionario de datos)
12
HU-01 Ingresar categoría 12HU-02 Modificar categoría 12HU-03 Agregar vigencia de categoría 12HU-04 Gestión productos 12SPRINT 3 60HU-05 Agregar productos 12HU-06 Modificar productos 12HU-07 Buscar para el módulo almacén 12HU-08 Establecer vigencia de producto 12HU-09 Reportes para modulo almacén 12SPRINT 4 60HU-10 Crear sesión de usuarios 18HU-11 Gestionar roles 12
HU-12 Asignar funcionalidad de acuerdo con el rol de usuario 12
HU-13 Activar estado de vigencia de la funcionalidad asignada 12
HU-14 Buscar y visualizar usuarios empleados de la empresa 6
SPRINT 5 60HU-15 Gestionar proveedores 12HU-16 Gestionar compras a proveedores. 12HU-17 Consultar compras por fecha, mes. 12HU-18 Buscar proveedores 6HU-19 Historial de precios 6
HU-20 Reportes para el módulo proveedores 12
SPRINT 6 60HU-21 Gestionar clientes 12HU-22 Gestionar venta 24HU-23 Consultar ventas por día, fecha, mes 12HU-24 Reportes para el módulo ventas 12SPRINT 7 60HU-25 Administrar caja 24HU-26 Historial de caja 12
31
HU-27 Generar Inventario 24SPRINT 8 60
HU-28 Resumen de saldos y movimiento de productos 30
HU-29 Graficas estadísticas de compras y ventas 30
SPRINT 9 60HT-07 Capacitación de usuarios 18HT-08 Documentación final del Sistema 24
Fuente: Elaboración propia.
Cada 10 días laborables se realiza una reunión con el director del proyecto, donde se realiza la
entrega del avance.
3.5.2. Fase de desarrollo
En esta sección se describen las actividades realizadas para el desarrollo del sistema de
inventarios.
3.5.2.1. Arquitectura del sistema
La arquitectura en la cual se desarrolla el sistema de compra y venta se denomina cliente –
servidor, haciendo uso del patrón modelo vista controlador (MVC), además también se utiliza
como motor para almacenar información el gestor MySQL. El patrón MVC tiene como
objetivo separar el código en tres capas diferentes nombradas anteriormente.
Figura 4. Arquitectura de la aplicación.Fuente: Elaboración propia.
32
En la Figura 5, se observa el sistema con una interfaz gráfica mediante la cual el usuario
accede al sistema; el controlador realiza una petición al modelo; el modelo procesa la petición
y devuelve información al controlador. Finalmente, la información se muestra en la vista en
un formato legible para el cliente.
3.5.2.2. Estándar de codificación
Con el objetivo de lograr una forma de programación uniforme, entendible que facilite el
mantenimiento del sistema, se utiliza el estilo de escritura Camel-Case. Notación que usa la
primera palabra en minúscula y las demás en mayúscula.
En la siguiente tabla se describen las características de los componentes a utilizar.
Tabla 7. Características de los componentes utilizados.
Componente Nombre Descripción
Clases categoriaController Nombre de la clase y luego nombre del módulo al que pertenece.
Variables String categoría Tipo de variable y luego asignar un nombre al atributo
Métodos categoriaBuscar () Nombre de la clase seguido del nombre de método.
Fuente: Elaboración propia.
3.5.2.3. Modelo de base de datos
El modelo conceptual del diseño de la base de datos del proyecto define las entidades,
atributos y relaciones que determinan el almacenamiento de la información, se muestra el
modelo en la Figura 6.
33
Figura 5. Modelo físico de base de datos.Fuente: Elaboración propia.
34
3.5.2.4. Diagramas de clases
Es un modelo importante en la ingeniería de software, debido a que, en él, se plasman
las clases, atributos, métodos y relaciones que definen en su totalidad las características
que debe tener las fuentes del proyecto, se presentan las clases con sus respectivos
métodos, en la figura 7.
Figura 6. Estructura de la clase categoría.Fuente: Elaboración propia.
Figura 7. Estructura de la clase Cliente.Fuente: Elaboración propia.
35
Figura 8. Estructura de la clase Compra.Fuente: Elaboración propia.
El modelo permite diseñar un bosquejo claro de las entidades, atributos y métodos con
los que cuenta el sistema. Los métodos que se definen en cada una de las clases, son los
necesarios para un CRUD.
Las clases con sus respectivos métodos se encuentran en el Anexo 5.
3.5.2.5. Pruebas TDD
Especificación del requisito en pruebas unitarias
Una vez definidas las historias de usuario y los diseños del software se proceden a
expresar dichas funciones en códigos de prueba. El Framework JUnit provee la API
necesaria para realizar las pruebas unitarias de cada requisito del software. Cada prueba
permite evaluar si un método dentro de un módulo funciona de forma correcta y
comprobar el comportamiento de los métodos de cada módulo.
Para realizar las pruebas unitarias a las funciones del proyecto, se debe crear la clase de
la entidad a analizar. De acuerdo al proceso de implementación del marco de trabajo
36
TDD la prueba que se implemente en las fuentes del proyecto debe fallar como primer
paso, para luego realizar la refactorización y corregir los inconvenientes presentados.
A continuación, como ejemplo se utiliza la prueba “Agregar productos”, después de lo
cual se detalla cada uno de los pasos, hasta llegar a obtener una correcta ejecución. El
proceso para ejecutar una prueba con la técnica TDD es el siguiente:
a. Escribir una prueba unitaria
Nótese que dentro de la prueba unitaria se incluye la etiqueta @Test y el método
assertEquals los mismos que indican que se está aplicando un test unitario.
Figura 9. Prueba unitaria para el método "agregar productos"Fuente: Elaboración propia.
b. Ejecutar las pruebas
Consiste en ejecutar las pruebas y verificar si pasa o no, el objetivo de TDD es verificar
que las pruebas fallan, en la Figura 10 se aprecia un error el cual debe ser refactorizado.
37
Figura 10. Resultado de la ejecución de las pruebas unitarias.Fuente: Elaboración propia.
c. Refactorización del código
el error se corrige refactorizando agregando las excepciones en la operación agregar de
la clase ProductoDAO, el código refactorizado es el siguiente: mejorar la descripción
Figura 11. Refactorización del método Agregar en la clase ProductoDAO.Fuente: Elaboración propia.
De forma similar se modifica el código de la prueba unitaria, agregando una excepción
y las cláusulas de try y cacth.
38
Figura 12. Refactorización de la prueba unitaria.Fuente: Elaboración propia.
Finalmente, con esas correcciones, el código se ejecuta correctamente.
Figura 13. Ejecución de las pruebas unitarias.Fuente: Elaboración propia.
Al finalizar la implementación de la metodología de desarrollo de software orientado
por pruebas, es importante señalar que para efectos del presente documento solo se
muestran algunos ejemplos de pruebas unitarias, para identificar el proceso que tiene el
marco de trabajo TDD; pero a nivel de proyecto hay más pruebas realizadas, que no
pueden ser agregadas al documento, para así cumplir de esta manera con los requisitos
mínimos que exige la Universidad y no sobre pasar el límite permitido. No poner esta
descripción
El detalle de las pruebas unitarias se aprecia en el Anexo 7.
39
3.5.3. Sistema de control de inventarios
Luego de finalizar las pruebas unitarias y entender por completo el rumbo que persigue
el proyecto, se procede a codificar el software. La metodología TDD precisa en sus
procesos, que al contar con las pruebas unitarias totalmente correctas y organizadas,
dichos códigos son trasladados como funcionalidades de las fuentes finales del
proyecto.
3.5.3.1. Diseño de base de datos
Con el objetivo de mantener los datos organizados, tener mejor manipulación,
almacenar información e integridad en la información que se genera en el almacén
Alejandra, se realizó el diseño de la base de datos. De acuerdo con los requerimientos
obtenidos para el desarrollo del sistema, se puede identificar las entidades, atributos y
sus relaciones. En la figura 15, se muestra el modelo físico.
Figura 14. Diagrama de bases de datos.Fuente: Elaboración propia.
3.5.3.2. Diccionario de datos
El diccionario de datos permite visualizar la nomenclatura de aquellos datos que se van
a utilizar en el sistema que se programa, este denota el nombre, tipo de dato, valores
40
aceptados y clave. En este diccionario se listan los tipos de datos utilizados para cada
entidad proveedor, creada para el funcionamiento del sistema.
La totalidad del diccionario de datos se detallan en el Anexo 4.
3.5.3.3. Historias de usuario
Las historias de usuario representan los requisitos provenientes del Sprint Backlog, cada
una cuenta con un identificador, nombre, descripción y responsable; así como sus tareas
de ingeniería y pruebas de aceptación. Una historia de usuario comprueba el correcto
cumplimiento de una funcionalidad.
Al finalizar el desarrollo del sistema se obtuvo 29 historias de usuario y 8 historias
técnicas. A continuación, se describen las 10 primeras historias de usuario y las demás
se detallan en el Anexo 6.
Todas las historias de usuarios fueron plasmadas tomando en cuenta los requisitos que
caracterizan a un sistema de control de inventarios. Unir esta idea con el párrafo anterior
Tabla 8. Historia usuario 01HISTORIA DE USUARIO 01
ID: HU-01 Nombre Historia: Ingresar categoría.Usuario: Administrador Sprint Asignado: 02 Fecha Inicio: Fecha Fin: Descripción: Como administrador del sistema necesito ingresar en la base de datos las diferentes categorías de los productos.Pruebas de Aceptación:
✓ Mostrar un mensaje de confirmación cuando el registro se ha realizado exitosamente.
Fuente: Elaboración propia.
Tabla 9. Historia usuario 02.HISTORIA DE USUARIO 02
ID: HU-02 Nombre Historia: Modificar categoríaUsuario: Administrador Sprint Asignado: 02 Fecha Inicio: Fecha Fin: Descripción: Como administrador del sistema necesito modificar la información de las categorías almacenadas en la base de datos.Pruebas de Aceptación:
✓ Mostrar un mensaje de confirmación cuando el registro se ha realizado exitosamente.
Fuente: Elaboración propia.
41
Tabla 10. Historia usuario 03.HISTORIA DE USUARIO 03
ID: HU-03 Nombre Historia: Agregar vigencia de categoría
Usuario: Administrador Sprint Asignado: 02
Fecha Inicio: Fecha Fin:
Descripción: Como administrador del sistema necesito ingresar la vigencia de una categoría.
Pruebas de Aceptación: ✓ Mostrar un mensaje de confirmación cuando el registro se ha realizado exitosamente.
Fuente: Elaboración propia.
Tabla 11. Historia usuario 04.HISTORIA DE USUARIO 04
ID: HU-04 Nombre Historia: Gestión productos.
Usuario: Administrador Sprint Asignado: 02
Fecha Inicio: Fecha Fin:
Descripción: Como administrador del sistema necesito un formulario donde pueda gestionar los productos.
Pruebas de Aceptación: ✓ Mostrar un mensaje de confirmación cuando el registro se ha realizado exitosamente.
Fuente: Elaboración propia.
Tabla 12. Historia usuario 05.HISTORIA DE USUARIO 05
ID: HU-05 Nombre Historia: Ingresar productos.
Usuario: Administrador Sprint Asignado: 03
Fecha Inicio: Fecha Fin:
Descripción: Como administrador del sistema necesito ingresar productos especificando todas sus características para poder controlar de cada uno su stock en bodega. Pruebas de Aceptación:
✓ Mostrar un mensaje de confirmación una vez ingresado el producto. Fuente: Elaboración propia.
Tabla 13. Historia usuario 06.HISTORIA DE USUARIO 06
ID: HU-06 Nombre Historia: Modificar productos
Usuario: Administrador Sprint Asignado: 03
Fecha Inicio: Fecha Fin:
42
Descripción: Como administrador del sistema necesito actualizar la información de los productos especificando todas sus características.
Pruebas de Aceptación: ✓ Mostrar un mensaje de confirmación una vez actualizado el producto.
Fuente: Elaboración propia.
Tabla 14. Historia usuario 07.HISTORIA DE USUARIO 07
ID: HU-07 Nombre Historia: Buscar para el módulo almacén
Usuario: Administrador Sprint Asignado: 03
Fecha Inicio: Fecha Fin:
Descripción: Como administrador del sistema necesito un formulario para la realizar búsquedas en el módulo almacén.
Pruebas de Aceptación: ✓ Mostrar un mensaje con el total de registros obtenidos.
Fuente: Elaboración propia.
Tabla 15. Historia usuario 08.HISTORIA DE USUARIO 08
ID: HU-08 Nombre Historia: Establecer vigencia de producto.
Usuario: Administrador Sprint Asignado: 03
Fecha Inicio: Fecha Fin:
Descripción: Como administrador del sistema necesito ingresar la vigencia de los productos.
Pruebas de Aceptación: ✓ Mostrar un mensaje de confirmación una vez ingresado el producto.
Fuente: Elaboración propia.
Tabla 16. Historia usuario 09.HISTORIA DE USUARIO 09
ID: HU-09 Nombre Historia: Reportes para módulo almacén
Usuario: Administrador Sprint Asignado: 02
Fecha Inicio: Fecha Fin:
Descripción: Como administrador del sistema necesito tener reportes de los productos, proveedores y categorías del módulo almacén. Los reportes se pueden descargar en diferentes formatos como PDF, PNG, XML. Pruebas de Aceptación:
✓Se muestra un mensaje de confirmación, posteriormente se presentan los reportes.
Fuente: Elaboración propia.
43
Tabla 17. Historia de usuario 10.HISTORIA DE USUARIO 10
ID: HU-10 Nombre Historia: Crear sesión de usuarios
Usuario: Administrador Sprint Asignado: 02
Fecha Inicio: Fecha Fin:
Descripción: Como usuario del sistema necesito que mi sesión sea capturada mientras dure use la aplicación.
Pruebas de Aceptación: ✓ se muestran los datos del usuario logueado.
Fuente: Elaboración propia.
3.5.3.4. Codificación del software
El software se lo desarrollo utilizando el IDE NetBeans en la versión 8.2 el mismo que
permite crear aplicaciones de Junit. El proyecto tiene la siguiente estructura.
Figura 15. Distribución de las carpetas del proyecto.Fuente: Elaboración propia
Acceso a datos: Contiene las clases que realizan la comunicación hacia el servidor de
base de datos. La Figura 17, muestra las clases incluidas en este paquete.
Figura 16. Contenido del package Acceso a datos.Fuente: Elaboración propia
44
Figura 17. Contenido de la clase conexión.Fuente: Elaboración propia
Desarrollo de la capa modelo, con el fin de organizar el código está capa se dividió en
dos capas: entidades y DAO.
Entidades: este paquete contiene las entidades de la aplicación junto con sus
atributos y métodos de acceso. La Figura 19, muestra las clases incluidas dentro
del package Entidades.
Figura 18. Clases que conforman el package entidades.Fuente: Elaboración propia
45
Figura 19. Código de la clase Cliente.Fuente: Elaboración propia
DAO: contiene las operaciones que se realizan con las entidades, generalmente
incluyen las funciones de CRUD y otras que realizan alguna función específica
solicitada por los usuarios. en la figura 21 se muestran las clases que incluye el
package DAO.
Figura 20. Clases del package dao.Fuente: Elaboración propia
46
Figura 21. Código de la clase ProductoDAO y definición del método Listar productos.Fuente: Elaboración propia
Desarrollo de la capa controlador: En esta capa las diferentes clases que reciben los
eventos desde la vista (formularios) y ejecutan la respectiva acción. El controlador
define el comportamiento de la aplicación. Despacha las peticiones del usuario y
selecciona las vistas de presentación siguiente, basándose en la información introducida
por el usuario y en el resultado de las operaciones realizadas por el modelo. Es decir,
interpreta las entradas del usuario y las mapea en acciones a ser efectuadas por el
modelo.
La figura 23 muestra los diferentes controladores de la aplicación.
47
Figura 22. Clases que conforman el package controlador.Fuente: Elaboración propia
Desarrollo de la capa vista: contiene los formularios que se encargan de acceder a los
datos del modelo, especifica cómo se deben presentar esos datos y actualiza la
presentación de los mismos cuando ocurren cambios en el modelo.
La figura 24, muestra los diferentes controladores de la aplicación.
Figura 23. Clases que conforman el package vista.Fuente: Elaboración propia
A continuación, se presentan algunas vistas del sistema en un entorno de pruebas.
Figura 24. Formulario de acceso al sistema (Login).Fuente: Elaboración propia
48
Figura 25. Menú principal del sistema.Fuente: Elaboración propia
Figura 26. Formulario "Gestión de clientes"Fuente: Elaboración propia
49
Figura 27. Módulo "Gestión de productos"Fuente: Elaboración propia
Figura 28. Módulo "Gestión de categorías"Fuente: Elaboración propia
50
Figura 29. Módulo "Gestión de proveedores"Fuente: Elaboración propia
Figura 30. Formulario "Ventas"Fuente: Elaboración propia
51
3.5.3.5. Manual de Usuario
Es un documento que sirve de guía para el Product Owner, donde se encuentra detallado
paso a paso cada una de las funcionalidades que realiza el aplicativo. Ver el anexo 1.
3.5.4. Fase de cierre
En esta fase se detalla todas las actividades que se realizan para la finalización del
desarrollo del sistema, estableciendo para el mismo el denominado Sprint BurnDown
Chart, el cual consiste en una representación gráfica del trabajo pendiente del proyecto
por hacer a lo largo del tiempo.
52
CAPÍTULO IV
4. RESULTADOS Y DISCUSION
4.1. Resultados
4.1.1. Uso de JUnit como “framework” para realizar pruebas unitarias
Como ya se mencionó en la fundamentación teórica “Test Driven Development” es una
técnica de programación extrema en la cual primero se desarrollan las pruebas unitarias
antes de escribir cualquier línea de código funcional.
Para cada uno de los puntos funcionales del sistema se creó una clase de pruebas en el
cual se implementaron las pruebas unitarias necesarias. En la Figura 32 se muestra el
paralelismo.
Figura 31. Clases creadas para las pruebas TDD.Fuente: Elaboración propia.
Cada clase de prueba contiene una sección para la declaración de variables globales a
usar en toda la clase y contiene una operación definida en su correspondiente clase
DAO, es decir la Implementación de cada uno de los métodos que contienen las pruebas
unitarias para el código funcional
Cabe destacar que para que un método de prueba sea exitoso o no, son usados los
métodos “assert”, tanto para comparar los valores esperados contra los valores reales, o
directamente hacer que el método de prueba falle.
53
4.1.1.1. Pruebas unitarias a la clase Producto
A continuación, se presentan las pruebas definidas en la clase TDDProducto.
Figura 32. Declaración del método init.Fuente: Elaboración propia.
@Before es la anotación que indica que el método adjunto se ejecutará antes cualquier
prueba en la clase. Se utiliza principalmente para configurar algunos objetos necesarios
para la correcta ejecución de las pruebas.
Figura 33. Definición de la prueba para el método insertar.Fuente: Elaboración propia.
@Test es la anotación que indica que el método adjunto es una prueba unitaria. Eso le
permite usar cualquier nombre de método para realizar una prueba.
54
Figura 34. Definición de la prueba “listar todos los productos”.Fuente: Elaboración propia.
Figura 35. Definición de la prueba "buscar dado el id del producto".Fuente: Elaboración propia.
El resultado arrojado por las pruebas tanto exitosas como erróneas se verá de forma
similar a la Figura 37.
Figura 36. Resultado de la ejecución de las pruebas unitarias.Fuente: Elaboración propia.
4.1.1.2. Pruebas unitarias a la clase Cliente
Al igual que la clase Producto se plantearon pruebas unitarias para la clase Cliente con
las operaciones básicas de un CRUD junto con otras operaciones necesarias para
55
determinar el funcionamiento de la aplicación en diferentes escenarios. A continuación,
se presentan las pruebas realizadas y los resultados obtenidos.
Figura 37. Código fuente de la prueba listar Clientes.Fuente: Elaboración propia.
Figura 38. Código fuente de la prueba unitaria, buscar cliente por su identificador.Fuente: Elaboración propia.
Figura 39. Código fuente del método insertar.Fuente: Elaboración propia.
56
con el objetivo de determinar el correcto funcionamiento de la aplicación con respecto a
la inserción, actualización y búsqueda masiva de datos, se implementaron tres pruebas
que ejecutan cada una de las operaciones antes descritas dentro de un ciclo repetitivo.
Figura 40. Código fuente del test inserción masiva.Fuente: Elaboración propia.
Figura 41. Código fuente del test actualización masiva.Fuente: Elaboración propia.
57
Figura 42. Test para las búsquedas masivas de clientes.Fuente: Elaboración propia.
La ejecución de las pruebas definidas para la clase cliente arrojó el siguiente mensaje de
error:
Figura 43. Salida de la ejecución de las pruebas unitarias a la clase Cliente.Fuente: Elaboración propia.
Estos errores se presentan debido a que existen muchas conexiones a la base de datos, la
solución consiste en agregar una línea código para cerrar la conexión a la base de datos
al finalizar cualquier operación.
Figura 44. Refactorización de las operaciones en la clase Cliente DAO.Fuente: Elaboración propia.
Nota: Esta operación se realizó en todas las clases DAO.
Finalizada la refactorización de los métodos definidos en todas las clases DAO del
aplicativo, las pruebas unitarias se ejecutaron correctamente.
58
Figura 45. Resultados de la ejecución de las pruebas unitarias en la case Cliente.Fuente: Elaboración propia.
4.2. Discusión
Después del estudio de la técnica del desarrollo dirigido por pruebas conjuntamente con
el framework JUnit, se ha podido determinar que la técnica no simplemente abarca el
testing de la aplicación, sino que conduce el diseño de la misma, mejorando el
paradigma de desarrollo del software, obteniendo un código de calidad.
El uso de este “framework” permite que los sistemas sean más adaptables al cambio
debido a que es mucho más fácil detectar y aislar las pruebas unitarias realizadas a cada
parte del sistema.
El uso de TDD es difícil en situaciones en las que se requieren pruebas completas de
funcionalidad del sistema, por ejemplo, en el uso de GUI’s, programas que trabajan con
Bases de Datos relacionales y algunos que trabajan en diferentes configuraciones de red.
La primera vez que se usa Scrum, es complicado diseñar código de calidad dentro del
sistema, porque no se conoce las limitaciones y fortalezas que ofrece la metodología. En
este caso Scrum, cuenta con los Sprints. Un sprint es una iteración de actividades que se
desarrolla con el grupo de trabajo, bajo los lineamientos de un conjunto de
requerimientos. De esta forma se escribe una serie de pruebas para dichos requisitos y,
una vez diseñados, se desarrolla el código más sencillo que haga que las pruebas pasen.
De esta manera se asegura que se escribe el código necesario para cubrir dichos
requisitos, a la vez que se cumplen los criterios de aceptación del cliente.
59
CONCLUSIONES
RECOMENDACIONES
60
BIBLIOGRAFÍA
Abenza, P. G. (30 de Junio de 2015). Google Libros. Obtenido de Google Libros: https://books.google.com.ec/books?hl=es&lr=&id=4v8QCgAAQBAJ&oi=fnd&pg=PP1&dq=related:1J5QvpYXGFAJ:scholar.google.com/&ots=le5W2wmZqs&sig=njE8bi8I-f_vXJQcAIykKdm_5Vs&redir_esc=y#v=onepage&q&f=false
Adewole, A. (18 de Mayo de 2018). Google Libros. Obtenido de Google Libros: https://books.google.com.ec/books?id=kF9dDwAAQBAJ&printsec=frontcover&dq=C%23+and+.NET+Core+Test+Driven+Development&hl=es&sa=X&ved=2ahUKEwiZ3-eInrfrAhVJiFkKHa6lAv0Q6AEwAHoECAMQAg#v=onepage&q=C%23%20and%20.NET%20Core%20Test%20Driven%20Development&f=false
Araujo, A. (2007). colibri. Obtenido de colibri: https://www.colibri.udelar.edu.uy/jspui/handle/20.500.12008/3540
Bagwan, S. (12 de Febrero de 2020). SevenMentor Pvt. Ltd. Obtenido de https://www.sevenmentor.com/vmware-vsphere-load-balancing-using-drs-in-vsphere-cluster
Balaguera, Y. D. (2013). Metodologías ágiles en el desarrollo de aplicaciones. Revista de Tecnología, 111-124.
Balaguera, Y. D. (19 de Diciembre de 2015). Revista de Tecnologia. Obtenido de https://revistas.unbosque.edu.co/index.php/RevTec/article/view/1291
Ble, C. (2019). uniwebsidad. Obtenido de uniwebsidad: http://dspace.espoch.edu.ec/bitstream/123456789/13636/1/18T00803.pdf
Casillas, L. A., Ginestà, M. G., & Pérez, Ó. (2014). Bases de datos en MySQL. Universitat oberta de Catalunya.
Castillo, J. A. (20 de diciembre de 2018). Profesional Review. Obtenido de https://www.profesionalreview.com/2018/12/20/vmware-vsphere/
Catrian. (11 de Diciembre de 2013). Catrian. Obtenido de https://www.catrian.com/que-es-el-balanceo-de-carga/
Chalan, M. A. (Agosto de 2015). Universidad Tecnólogica Equinocial. Obtenido de http://repositorio.ute.edu.ec/bitstream/123456789/16842/1/63873_1.pdf
Chile, D. (19 de Agosto de 2019). defontana. Obtenido de defontana: https://www.defontana.com/cl/como-funciona-un-sistema-de-inventario/#:~:text=En%20l%C3%ADneas%20generales%2C%20un%20sistema,costo%20de%20los%20productos%20vendidos.
Cinalli, F. (27 de Septiembre de 2019). Obtenido de OpenWebinars: https://openwebinars.net/blog/que-es-vcenter-server/
computo, I. d. (2017). Interamericana de computo. Obtenido de https://www.incosa.com.uy/blog/que-es-virtualizacion-de-servidores/
61
Deepti Sharma, A. P. (2017). Framework for Achieving Load Balancing in Web Clusters based on Load Factor. International Conference on Computing and Communication Technologies for Smart Nation (IC3TSN), (págs. 327-331). doi:10.1109/IC3TSN.2017.8284500
Elsaid, M. E. (2014). Enabling Long Distance Live Migration with F5 and VMware vMotion. 2014 International Conference on Future Internet of Things and Cloud, (págs. 216-221).
Farcic, V., & Garcia, A. (27 de Agosto de 2015). Google Libros. Obtenido de Google Libros: https://books.google.com.ec/books?hl=es&lr=&id=tRl1CgAAQBAJ&oi=fnd&pg=PP1&dq=test%20driven%20development%20con%20java&ots=mxcPIu6g7-&sig=5t5ABRXWvRcrvrMgpQ70F_3LAo4&fbclid=IwAR1cWAgjFTD7Mjtc-2Kk8J3iQiWlvuRJ5jf1XzknFnzBDuyDFwerPlTsV_k#v=onepage&q&f=false
Fernadez, J. (17 de Junio de 2011). Scribd. Obtenido de https://es.scribd.com/document/58090698/Historia-Vmware
Fernandez, L. (29 de Marzo de 2020). RedesZone. Obtenido de https://www.redeszone.net/tutoriales/servidores/balanceador-carga-load-balancer-que-es-funcionamiento/
Fuentes, J. R. (1 de Diciembre de 2015). Google Libros. Obtenido de Google Libros: https://books.google.com.ec/books?id=TxRpCwAAQBAJ&printsec=frontcover&dq=metodologia+scrum&hl=es&sa=X&ved=2ahUKEwiVzs6XnLnrAhXos1kKHQg0CeIQ6AEwBnoECAkQAg
Gaochao Xu, J. P. (2013). A load balancing model based on cloud partitioning for the public cloud. Tsinghua Science and Technology, 34-39. Obtenido de http://pgembeddedsystems.com/securelogin/upload/project/IEEE/31/PG2013JOO10/A%20Load%20Balancing%20Model%20Based%20on%20Cloud%20Partitioning.pdf
Geek University. (2019). Obtenido de https://geek-university.com/vmware-esxi/what-is-a-datastore/
Giorgi, A. (20 de Noviembre de 2014). Jose Maria Gonzales. Obtenido de https://www.josemariagonzalez.es/vmware-nsx/como-funciona-el-servicio-de-vmware-nsx-edge-load-balancer.html
Grenning, J. W. (2011). Test Driven Development for Embedded C. Pragmatic bookshelf.
Guerra, E., & Ivo, A. (24 de Marzo de 2017). Springer Link. Obtenido de Springer Link: https://link.springer.com/chapter/10.1007/978-3-319-55907-0_7
Juanjo. (06 de Noviembre de 2016). Blog. Obtenido de https://blog.informaticabyte.es/blog/2
Julio Pinilla, T. R. (2018). INTEGRACIÓN DE OPENSTACK Y VMWARE ESXI 5.5 PARA BRINDAR INFRAESTRUCTURA COMO SERVICIO. VIII Simposio de Telecomunicaciones. La habana. Obtenido de http://www.informaticahabana.cu/sites/default/files/ponencias2018/TEL21.pdf
Jurado, C. B. (2010). Diseño Ágil con TDD. España.
62
Kuehn, P. (2016). Energy Efficiency and Performance of Cloud Data Centers - Which Role Can Modeling Play. ACM Digital Library. doi:https://dl.acm.org/doi/abs/10.1145/2940679.2940688
Kun Wu, B. W. (2018). Research on the ESXI Host Renovation Project based on VMware vCenter. Proceedings of the 2018 International Conference on Transportation & Logistics, Information & Communication, Smart City (TLICSC 2018). 161, págs. 400-402. Atlantis Press. doi:https://doi.org/10.2991/tlicsc-18.2018.64
Lemus, I. (10 de Marzo de 2020). Conocimiento Libre. Obtenido de https://conocimientolibre.mx/historia-de-la-virtualizacion/
Levkina, M. (14 de Marzo de 2017). VEEAM. Obtenido de https://www.veeam.com/blog/es-lat/how-to-move-a-vmware-vm-from-one-host-to-another-without-vmware-vmotion.html
Maggie Mashaly, P. K. (2016). Modeling and Analysis of Virtualized Multi-Service Cloud Data Centers with Automatic Server Consolidation and Prescribed Service Level Agreements. 41st IEEE Conference on Local Computer Networks, LCN 2016, (págs. 9-16). Dubai. Obtenido de https://ieeexplore.ieee.org/document/7856132
Maillé Éric, M. R.-F. (2012). VMware vSphere 5 en el seno del datacenter. Barcelona, España: ENI. Obtenido de https://books.google.com.ec/books?id=_N6UwhVHHA0C&printsec=frontcover&dq=Servicios+de+Aplicaciones+de+VMware+vSphere&hl=es&sa=X&ved=2ahUKEwitpIKH1I3uAhVSjlkKHaAfCLgQ6AEwA3oECAIQAg#v=onepage&q=Servicios%20de%20Aplicaciones%20de%20VMware%20vSphere&f=false
Manlove, D. (2013). Algorithmics of matching under preferences. World Scientific. Obtenido de https://www.worldscientific.com/worldscibooks/10.1142/8591
Mariuxi, Z., Jimmy, M., & Fausto, R. (11 de Abril de 2017). Google Libros. Obtenido de Google Libros: https://books.google.com.ec/books?hl=es&lr=&id=5-mkDgAAQBAJ&oi=fnd&pg=PA3&dq=que+es+postgresql&ots=DmHQLXYglT&sig=bNgnYeIZhuqiQOCL6vCNPDvoPCY&redir_esc=y#v=onepage&q=que%20es%20postgresql&f=false
Moisés. (20 de Junio de 2019). CODE HOVEN. Obtenido de CODE HOVEN: https://www.codehoven.com/tdd-test-driven-development/
Morales, A., Lopez, C., & Reyes, L. (5 de Octubre de 2015). Revista Espirales. Obtenido de Revista Espirales: http://revistaespirales.com/index.php/es/article/view/269
Muñoz, A. (2018). Redes Caseras: Virtualizacion de Routers. Obtenido de https://riuma.uma.es/xmlui/bitstream/handle/10630/16539/Virtualizacio%20n.pdf?sequence=1
Palacios, L. F. (2009). Perfiles de testing aplicados. La Plata.
Pérez, B. S. (2015). Cuaderno Pratico de Windows.Sistemas Operativos Monopuestos.Ciclos Formativos de Informatica (Primera ed.). LULU COM. Obtenido de https://books.google.com.ec/books?id=ENC4CgAAQBAJ&pg=PA23&dq=tipos+de+maquinas+virtuales&hl=es-
63
419&sa=X&ved=2ahUKEwiOi-C7zY3uAhWhpFkKHbznCgQQ6AEwA3oECAAQAg#v=onepage&q=tipos%20de%20maquinas%20virtuales&f=false
Quanti. (20 de Julio de 2018). Quanti. Obtenido de https://quanti.com.mx/articulos/que-es-load-balance-o-balance-de-carga/
Raffino, M. E. (23 de Septiembre de 2020). Concepto.de. Obtenido de https://concepto.de/sistema-operativo/
Rakov, M. R. (2017). Universidad San Martin de Porras. Obtenido de https://www.usmp.edu.pe/vision2017/pdf/materiales/VIRTUALIZACION_DE_SERVIDORES_CON_VMWARE.pdf
Rudibel Llanes, R. A. (Marzo de 2020). Plataformas de software libre para la virtualización de servidores en pequeñas y medianas empresas cubanas. Revista Cubana de Ciencias Informáticas, 14, 40-57. Obtenido de http://scielo.sld.cu/pdf/rcci/v14n1/2227-1899-rcci-14-01-40.pdf
Salazar, J., & Valbuena, Y. (31 de Diciembre de 2018). Tecnología Investigación y Academia. Obtenido de Tecnología Investigación y Academia: https://revistas.udistrital.edu.co/index.php/tia/article/view/10496
Segovia, A. J. (17 de Septiembre de 2019). 27001Academy. Obtenido de 27001Academy: https://advisera.com/27001academy/es/que-es-iso-27001/
Shirinbab, S. (2019). PERFORMANCE IMPLICATIONS OF VIRTUALIZATION. Diva. Obtenido de https://www.diva-portal.org/smash/get/diva2:1260339/FULLTEXT02.pdf
Sonar, M. R. (2015). Load balancing in cloud. International Journal of Engineering Research and General Science, 160–167. Obtenido de http://pnrsolution.org/Datacenter/Vol3/Issue3/234.pdf
Steven, F., Kent, B., Bill, C., Tim, M., James, N., & Charlie, P. (2003). Extreme Programming and Agile Processes in Software Engineering. Berlin: Springer.
Subra, J., & Vannieuwenhuyze, A. (Febrero de 2018). Google Libros. Obtenido de Google Libros: https://books.google.com.ec/books?id=TyQuFpGhZ8sC&pg=PA19&dq=fases+de+scrum&hl=es&sa=X&ved=2ahUKEwi588KUn7nrAhXRxlkKHdBLCiIQ6AEwAnoECAIQAg#v=onepage&q=fases%20de%20scrum&f=false
Sznajdleder, P. A. (13 de Diciembre de 2016). Google Libros. Obtenido de Google Libros: https://books.google.com.ec/books?hl=es&lr=&id=WcL2DQAAQBAJ&oi=fnd&pg=PT5&dq=lenguaje+de+programaci%C3%B3n+java&ots=iPBgEDHxN5&sig=8WN0VR0vRuH7Q8WYOeoSyNUXnMg&redir_esc=y#v=onepage&q=lenguaje%20de%20programaci%C3%B3n%20java&f=false
Thiri Thitsar Khaingr, H. Y. (6 de Octubre de 2020). Allocation of Virtual Machine Resources in Server Virtualization Environment. University of Computer Studies (Taunggyi). Obtenido de https://www.ucstgi.edu.mm/storage/2020/10/6.pdf
Tobias Mühlbauer, W. R. (2015). High-Performance Main-Memory Database Systems and Modern Virtualization: Friends or Foes? DanaC'15: Proceedings of the Fourth
64
Workshop on Data analytics in the Cloud, (págs. 1-4). doi:https://doi.org/10.1145/2799562.2799643
Torre, E. G. (2016). Virtualización de un Datacenter. Cartajena. Obtenido de https://repositorio.upct.es/handle/10317/5580
Vaca, P., Maldonado, C., Inchaurrondo, C., Peretti, J., Soledad, M., & Bueno, M. (2013). Test-Driven Development-Una aproximación para entender su utilidad en el proceso de desarrollo de Software. Conaiisi, 2347-0372.
Villar Eugenio, G. (Junio de 2018). Introducción a la virtualización. Obtenido de http://148.202.167.116:8080/xmlui/bitstream/handle/123456789/2273/Introducción%20a%20la%20virtualización.pdf?sequence=1&isAllowed=y
VMware. (2020). VMware. Obtenido de https://www.vmware.com/latam/solutions/virtualization.html#:~:text=Tipos%20de%20virtualización,-Virtualización%20de%20servidores&text=La%20virtualización%20de%20servidores%20permite,eficiencia%20del%20entorno%20de%20TI
Vogel, L. (23 de Julio de 2015). Academia. Obtenido de Academia: http://www.academia.edu/download/38671226/Unit_Testing_with_JUnit_-_Tutorial.pdf
wikipedia.org. (20 de 12 de 2012). Cronologia del desarrollo de la virtualizacion. Obtenido de https://en.wikipedia.org/wiki/Timeline_of_virtualization_development
Wirenet. (17 de Octubre de 2019). Wirenet Chile. Obtenido de https://www.wirenetchile.com/que-es-un-datacenter-virtual/
Стельмах, С. (07 de 09 de 2015). Пять недорогих Open Source-сервисов хранения для предприятий. ItWeek.
65
ANEXOS
Anexo 1: Manual de usuario
Anexo 2: Manual técnico
Anexo 3: Fotografías de las reuniones con los usuarios
Anexo 4: Diccionario de datos
Anexo 5: Clases del sistema
Anexo 6: Historias de usuario
Anexo 7: Pruebas unitarias
66