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

Í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

Miryan Estela Narváez Vilema, 04/08/21,

¿Cuales??, mejorar la idea


Cuales??? Usar signos de puentuación, las ideas cortas se entienden mejor

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


Según Vaca (2013)

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


Mejorar la idea

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


Cuales??

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


Mejorar la descripción

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.


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


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


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


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.


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


Poner las dos formas que se utiliza

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.


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.


41


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.



ID: HU-04 Nombre Historia: Gestión productos.



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.



ID: HU-05 Nombre Historia: Ingresar productos.



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.


ID: HU-06 Nombre Historia: Modificar productos



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.



ID: HU-07 Nombre Historia: Buscar para el módulo almacén



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.



ID: HU-08 Nombre Historia: Establecer vigencia de producto.



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.



ID: HU-09 Nombre Historia: Reportes para módulo almacén



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.


43

Tabla 17. Historia de usuario 10.HISTORIA DE USUARIO 10

ID: HU-10 Nombre Historia: Crear sesión de usuarios



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.


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

Tesis

Documents

Transcript of Tesis