Monografía Tesis

Desarrollo de un sistema de gestión de
equipos e inventarios para los laboratorios de

la Facultad de Ingenierı́a Mecánica,
Electrónica y Biomédica de la Universidad
Antonio Nariño (FIMEB INVENTORY
MANAGEMENT)
Harold Esteban Reyes Lancheros
Universidad Antonio Nariño

Facultad de Ingenierı́a de Sistemas
Bogotá, Colombia
2019
Desarrollo de un sistema de gestión de
equipos e inventarios para los laboratorios de
la Facultad de Ingenierı́a Mecánica,
Electrónica y Biomédica de la Universidad
Antonio Nariño (FIMEB INVENTORY
MANAGEMENT)
Tesis de grado presentada como requisito para optar al tı́tulo de:

Ingeniero de Sistemas y Computación
Director(a):
Ing. Juan Carlos Martı́nez Dı́az
Asesor Metodológico:
Rosalba Cruz Cepeda
Licenciada en Educación
Tipo de Proyecto:
Desarrollo de software
Universidad Antonio Nariño

Facultad de Ingenierı́a de Sistemas
Bogotá, Colombia
2019
DEDICATORIA
Este trabajo de grado esta dedicado a Dios, por

guiarme durante mi formación académica, a mi
familia por su apoyo incondicional, por demostrar-
me que a pesar de las adversidades con unión y fe
siempre habrá una solución. A mi abuela Cecilia
Amaya y a mi mamá Gail Lancheros, que fueron
fundamentales para que logrará estudiar, quienes
siempre confiaron en mi y siempre me apoyaron.
A mi amiga Tania Rodrı́guez por todo su apoyo a
lo largo del desarrollo de este trabajo y por estar
siempre pendiente de mi, por cada consejo y por
toda la ayuda recibida. A la asesora metodológica
Rosalba Cruz, quien me acompaño siempre durante
todo este proceso de elaboración y su ayuda fue
fundamental para la culminación exitosa de este
trabajo, aportándome todo su profesionalismo,
experiencia y disposición.

Agradecimientos
Expreso mi agradecimiento a todas las personas que colaboraron e hicieron posible el desarro-
llo del trabajo de grado. Agradezco a mi director de trabajo de grado Ing. Juan Carlos Martı́nez
Dı́az, por el apoyo brindado durante el proceso de desarrollo y culminación de este trabajo. Agra-
dezco a mi amiga M.Sc. Tania Rodrı́guez Quiñones quien fue mi guı́a en todo momento, por su
dedicación, motivación, esfuerzo, comprensión y sobre todo por el apoyo brindado durante todo el
proceso de desarrollo de este trabajo. Agradezco al Ing. Juan Molina Rojas, por toda la colaboración
y enseñanza durante la elaboración e ingenierı́a del proyecto. Además, a mi asesora metodológica
Rosalba Cruz Cepeda por toda la atención prestada, acompañamiento, apoyo y gran disposición
durante este proceso que me permitió crecer personalmente.
Agradezco a la facultad de Ingenierı́a mecánica, electrónica y biomédica de la Universidad Antonio

Nariño, para quienes se realizó la aplicación web y cuya colaboración fue indispensable.
Y por último, agradezco a mi familia que con su amor, comprensión, apoyo y esfuerzo, me enseñaron
a nunca desistir , a conseguir mis metas y a luchar por mis objetivos.
Índice general
Agradecimientos IV
Lista de figuras VI
Lista de tablas VIII
Resumen 2
Introducción 3
1. PLANTEAMIENTO DEL PROBLEMA 4

1.1. DESCRIPCIÓN DEL PROBLEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. FORMULACIÓN DEL PROBLEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. JUSTIFICACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2. Objetivos Especı́ficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. ALCANCES Y LIMITACIONES DEL PROYECTO . . . . . . . . . . . . . . . . . . 6
1.5.1. Alcances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5.2. Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. MARCO DE REFERENCIA 8
2.1. MARCO TEÓRICO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1. Inventario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2. Teorı́a de Inventarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3. Herramientas de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2. METODOLOGÍA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1. Metodologı́a SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3. ESTADO DE ARTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3. METODOLOGÍA DE DESARROLLO 18
3.1. PROCESOS DEL PROYECTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. FASES A IMPLEMENTAR EN EL PROYECTO . . . . . . . . . . . . . . . . . . . . 19
3.3. SPRINT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.1. Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.2. Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.3. Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.4. Sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
vi Índice general
4. DESARROLLO DEL PROYECTO 21

4.1. DESCRIPCIÓN DE LA APLICACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2. FASE DE INICIACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3. PLANEACIÓN Y ESTIMACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.1. Roles del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.2. Arquitectura y herramientas del sistema . . . . . . . . . . . . . . . . . . . . . 24
4.3.3. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.4. Listado de historias de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.5. Plan de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4. IMPLEMENTACIÓN Y DESARROLLO . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4.1. Sprint 1: Módulo Sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4.2. Modelo relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4.3. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.4. Sprint 2: Módulo Creación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.5. Sprint 3: Módulo Inventarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.4.6. Sprint 4: Módulo Gestión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5. RESULTADOS 100
5.1. PRUEBAS DE CARGA Y STRESS . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.1.1. Resultados y análisis de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.2. PRUEBAS DE COMPATIBILIDAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.3. PRUEBAS DE ACEPTACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6. CONCLUSIONES Y RECOMENDACIONES 107
7. TRABAJO A FUTURO 108
A. ANEXO: Glosario 109
B. ANEXO: ACTA DE ENTREGA FINAL DE LA APLICACIÓN FIMEB INVENTORY

MANAGEMENT 110
C. ANEXO: ACTAS DE ENTREGAS SPRINTS APLICACIÓN FIMEB INVENTORY

MANAGEMENT 112
Bibliografı́a 116
Índice de figuras
2-1. Aplicación web SMARTBIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2-2. Aplicación web SIIGO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2-3. Aplicación web SAP BUSINESS ONE . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2-4. Aplicación STOCK BASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2-5. Aplicación web ALEGRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2-6. Inventario realizado en Excel con pistola lectora de código de barras . . . . . . . . . 15
4-1. Etiqueta historia de usuario creada en Trello . . . . . . . . . . . . . . . . . . . . . . 22

4-2. Flujo de trabajo tablero scrumBoard . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4-3. Modelo vista controlador (MVC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4-4. Caso de uso general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4-5. Mockup pantalla inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4-6. Mockup ingreso estudiante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4-7. Mockup lista usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4-8. Mockup agregar usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4-9. Modelo relacional sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4-10.Caso de uso iniciar sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4-11.Caso de uso crear y editar un usuario . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4-12.Caso de uso cerrar sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4-13.Diagrama de actividad inicio de sesión . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4-14.Diagrama de actividad crear y editar un usuario . . . . . . . . . . . . . . . . . . . . 39
4-15.Diagrama de actividad activar/inactivar un usuario . . . . . . . . . . . . . . . . . . . 40
4-16.Diagrama de actividad cerrar sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4-17.Scrum Board sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4-18.Mockup pantalla tipo elemento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4-19.Mockup agregar tipo elemento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4-20.Mockup agregar elemento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4-21.Modelo relacional sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4-22.Caso de uso crear o editar un elemento . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4-23.Caso de uso añadir comentarios a un elemento . . . . . . . . . . . . . . . . . . . . . 55
4-24.Caso de uso dar de baja un elemento . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4-25.Diagrama de actividad crear y editar un elemento . . . . . . . . . . . . . . . . . . . . 59
4-26.Diagrama de actividad añadir comentarios a un elemento . . . . . . . . . . . . . . . 59
4-27.Diagrama de actividad dar de baja un elemento . . . . . . . . . . . . . . . . . . . . . 59
4-29.Mockup descarga inventario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
viii Índice de figuras

4-31.Caso de uso sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4-32.Diagrama de actividades sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4-34.Mockup elementos disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4-35.Mockup elementos mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4-36.Mockup enviar elemento a mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . 76
4-37.Mockup crear préstamo con elementos . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4-39.Caso de uso descargar hoja de vida elemento . . . . . . . . . . . . . . . . . . . . . . 78
4-40.Caso de uso enviar elemento a mantenimiento . . . . . . . . . . . . . . . . . . . . . . 78
4-41.Caso de uso enviar elemento a disponibles . . . . . . . . . . . . . . . . . . . . . . . . 79
4-42.Caso de uso crear préstamo con elementos . . . . . . . . . . . . . . . . . . . . . . . . 79
4-43.Caso de uso crear reserva con elementos . . . . . . . . . . . . . . . . . . . . . . . . . 79
4-44.Caso de uso confirmar reserva a préstamo . . . . . . . . . . . . . . . . . . . . . . . . 80
4-45.Diagrama de actividad mostrar elementos disponibles . . . . . . . . . . . . . . . . . 86
4-46.Diagrama de actividad mostrar elementos mantenimiento . . . . . . . . . . . . . . . 86
4-47.Diagrama de actividad descargar hoja de vida elemento . . . . . . . . . . . . . . . . 87
4-48.Diagrama de actividad enviar elemento a mantenimiento . . . . . . . . . . . . . . . . 87
4-49.Diagrama de actividad enviar elemento a disponibles . . . . . . . . . . . . . . . . . . 88
4-50.Diagrama de actividad crear préstamo con elementos . . . . . . . . . . . . . . . . . . 89
4-51.Diagrama de actividad crear reserva con elementos . . . . . . . . . . . . . . . . . . . 90
4-52.Diagrama de actividad confirmar reserva a préstamo . . . . . . . . . . . . . . . . . . 90
5-1. Parámetros de JMeter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

5-2. Resultado obtenido con 100 usuarios que ingresan simultáneamente al sistema en
condiciones ideales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
condiciones reales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
B-1. Acta de entrega final de la aplicación FIMEB INVENTORY MANAGEMENT. . . . 111
C-1. Acta de entrega Sprint 1 y 2 de la aplicación FIMEB INVENTORY MANAGEMENT.113

C-2. Acta de entrega Sprint 3 de la aplicación FIMEB INVENTORY MANAGEMENT. . 114
C-3. Acta de entrega Sprint 4 de la aplicación FIMEB INVENTORY MANAGEMENT. . 115
Índice de tablas
2-1. Aplicaciones existentes, ventajas y desventajas . . . . . . . . . . . . . . . . . . . . . 16
4-1. Plantilla Historias Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4-2. Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4-3. Mostrar pantalla inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4-4. Iniciar sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4-5. Ingreso estudiante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4-6. Mostrar pantalla principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4-7. Mostrar pantalla usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4-8. Crear y editar un usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4-9. Activar/Inactivar un usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4-10.Cerrar sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4-11.Caso de uso iniciar sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4-12.Caso de uso crear o editar un usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4-13.Caso de prueba funcional (Mostrar pantalla inicio) . . . . . . . . . . . . . . . . . . . 42
4-14.Caso de prueba funcional (Iniciar sesión) . . . . . . . . . . . . . . . . . . . . . . . . . 43
4-15.Caso de prueba funcional (Ingreso estudiante) . . . . . . . . . . . . . . . . . . . . . . 44
4-16.Caso de prueba funcional (Mostrar pantalla principal) . . . . . . . . . . . . . . . . . 45
4-17.Caso de prueba funcional (Mostrar pantalla usuarios) . . . . . . . . . . . . . . . . . 46
4-18.Caso de prueba funcional (Agregar y editar un usuario) . . . . . . . . . . . . . . . . 47
4-19.Caso de prueba funcional (Activar/Inactivar un usuario) . . . . . . . . . . . . . . . . 48
4-20.Caso de prueba funcional (Cerrar sesión) . . . . . . . . . . . . . . . . . . . . . . . . . 49
4-21.Mostrar pantalla elementos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4-22.Crear y editar un elemento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4-23.Añadir comentarios a un elemento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4-24.Dar de baja un elemento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4-25.Caso de uso crear o editar un elemento . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4-26.Caso de uso añadir comentario a un elemento . . . . . . . . . . . . . . . . . . . . . . 57
4-27.Caso de uso dar de baja un elemento . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4-28.Caso de prueba funcional (mostrar pantalla elementos) . . . . . . . . . . . . . . . . . 61
4-29.Caso de prueba funcional (Crear y editar un elemento) . . . . . . . . . . . . . . . . . 62
4-30.Caso de prueba funcional (Añadir comentarios a un elemento) . . . . . . . . . . . . . 63
4-31.Caso de prueba funcional (Dar de baja un elemento) . . . . . . . . . . . . . . . . . . 64
4-32.Generar inventario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4-33.Descargar inventario PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4-34.Descargar inventario Excel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Índice de tablas 1
4-35.Caso de uso añadir comentario a un elemento . . . . . . . . . . . . . . . . . . . . . . 68

4-36.Caso de prueba funcional (Descargar inventario) . . . . . . . . . . . . . . . . . . . . 70
4-37.Mostrar elementos disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4-38.Mostrar elementos mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4-39.Descargar hoja de vida elemento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4-40.Enviar elemento a mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4-41.Enviar elemento a disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4-42.Crear préstamo con elementos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4-43.Crear reserva con elementos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4-44.Confirmar reserva a préstamo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4-45.Caso de uso descargar hoja de vida elemento . . . . . . . . . . . . . . . . . . . . . . 80
4-46.Caso de uso enviar elemento a mantenimiento . . . . . . . . . . . . . . . . . . . . . . 81
4-47.Caso de uso enviar elemento a disponibles . . . . . . . . . . . . . . . . . . . . . . . . 82
4-48.Caso de uso crear préstamo con elementos . . . . . . . . . . . . . . . . . . . . . . . . 83
4-49.Caso de uso crear reserva con elementos . . . . . . . . . . . . . . . . . . . . . . . . . 84
4-50.Caso de uso confirmar reserva a préstamo . . . . . . . . . . . . . . . . . . . . . . . . 85
4-51.Caso de prueba funcional (Mostrar elementos disponibles) . . . . . . . . . . . . . . . 92
4-52.Caso de prueba funcional (Mostrar elementos mantenimiento) . . . . . . . . . . . . . 93
4-53.Caso de prueba funcional (Descargar hoja de vida elemento) . . . . . . . . . . . . . . 94
4-54.Caso de prueba funcional (Enviar elemento a mantenimiento) . . . . . . . . . . . . . 95
4-55.Caso de prueba funcional (Enviar elemento a disponibles) . . . . . . . . . . . . . . . 96
4-56.Caso de prueba funcional (Crear préstamo con elementos) . . . . . . . . . . . . . . . 97
4-57.Caso de prueba funcional (Crear reserva con elementos) . . . . . . . . . . . . . . . . 98
4-58.Caso de prueba funcional (Confirmar reserva a préstamo) . . . . . . . . . . . . . . . 99
Resumen
El estado actual de los inventarios de la Facultad de Ingenierı́a Mecánica, Electrónica y Biomédica
de la Universidad Antonio Nariño presenta falencias relacionadas con el préstamo de equipos y la
gestión de elementos, los administradores se han encontrado con diferentes dificultades, debido al
tamaño de los laboratorios de la Facultad y la cantidad de elementos que estos poseen. Debido
a esto surge la necesidad de contar con una herramienta que permita organizar la gestión de
equipos e inventarios, para lo que se propone desarrollar un sistema de gestión de información
que sistematice el control de dichos equipos pertenecientes a los laboratorios. Este desarrollo se
verá reflejado por medio de un portal web que pretende centralizar la información, para llevar un
manejo transparente de recursos, que beneficie, con tiempo y ahorro de dinero los procesos internos
de los laboratorios. El presente documento muestra el desarrollo de una aplicación web (FIMEB
INVENTORY MANAGEMENT) para la gestión de equipos y elementos de los laboratorios de
la facultad mencionada como proyecto de trabajo de grado para aspirar al tı́tulo de ingeniero de
sistemas y computación.
Palabras Claves: Gestión de activos, Inventarios, Páginas Web, Sistemas de información, Soft-
ware
Introducción
El inventario es una relación detallada, ordenada y valorada de los elementos que componen el
patrimonio de una empresa, organización o persona en un momento concreto. La dificultad que
representa la correcta administración del inventario tiene que ver con guardar en reserva un artı́cu-
lo para cumplir las fluctuaciones de la demanda. El exceso de existencias de un artı́culo aumenta
el costo del capital y de almacenamiento, y la escasez de existencias detiene la producción y/o
las ventas. Al realizar un inventario, se espera obtener un nivel del mismo que balancee las dos
situaciones extremas minimizando una función de costo apropiada, donde no hagan falta elementos
ni sobren estos [Taha, 2004].
En los laboratorios de la facultad de Ingenierı́a Mecánica, Electrónica y Biomédica de la Universi-

dad Antonio Nariño la gestión de los inventarios, préstamos y elementos aún se realiza sin ayuda
alguna de un sistema de información, debido a que los costos de implementación de un Software
existente son elevados.
La gestión de equipos e inventarios en una institución educativa conlleva al buen funcionamiento

y adecuado manejo de los recursos. Estratégicamente genera beneficios en estudiantes, profesores,
investigadores y demás personal, agilizando el acceso a la información, facilitando los procesos de
aprendizaje. Este trabajo consiste en desarrollar un sistema de gestión de equipos e inventarios que
permita la administración de los laboratorios de la Facultad de Ingenierı́a Mecánica, Electrónica y
Biomédica de la Universidad Antonio Nariño, con el fin de sistematizar la manera actual en que se
lleva a cabo esta gestión. El proyecto será implementado inicialmente en la sede sur de la ciudad
de Bogotá, donde se encuentra el laboratorio principal de la facultad.
Los laboratorios son parte fundamental de la infraestructura y apoyo logı́stico a las actividades
académicas de la facultad, por lo tanto, se registran diferentes elementos y alguno de estos son:
fuentes de poder, generadores de funciones, multı́metros, osciloscopios, computadores, entre otros.
Para el desarrollo del aplicativo web se adaptó la metodologı́a ágil de desarrollo SCRUM como guı́a
para la ejecución de las actividades y construcción del producto del proyecto.
Al implementar el proyecto, se logrará mejorar el proceso actual con el que se lleva a cabo la ges-
tión de los equipos pertenecientes a los laboratorios y el inventario de estos. Además se obtendrá
información precisa y fiable, para que la administración de la facultad en cualquier momento pueda
generar reportes y comprobar el estado actual de los laboratorios.
1. PLANTEAMIENTO DEL PROBLEMA
1.1. DESCRIPCIÓN DEL PROBLEMA

En los laboratorios de la Facultad de Ingenierı́a Mecánica, Electrónica y Biomédica (FIMEB) de la
Universidad Antonio Nariño (UAN), se presentan dificultades a la hora de llevar a cabo la gestión
de equipos y el control de inventarios, debido a que se hacen de forma computarizada pero sin la
ayuda de sistemas de gestión de información. La información de inventario de los diferentes equipos
que tienen en FIMEB es capturada en sistemas no automatizados basados en un registro a través
de un archivo de Excel; el proceso se hace en papel y luego la información capturada es computari-
zada por las personas responsables de realizar el inventario; la manera de realizar los inventarios
no proporciona mucha ayuda para las necesidades que han ido surgiendo conforme los laboratorios
han ido creciendo, convirtiéndose en una tarea muy engorrosa, poco eficiente, sujeta a errores e
inconsistencia de datos en cuanto a revisión contra activos, es decir, las cantidades existentes no
concuerdan con las reportadas. El proceso de préstamo de elementos de los laboratorios también
se lleva de forma manual, se registra cada préstamo realizado a los estudiantes o docentes en un
archivo de Excel que contiene: nombre del usuario de la institución, número de carné, elemento
prestado, fecha de préstamo y fecha de devolución, haciendo que el trabajo sea más extenuante
para los laboratoristas y más demorado en la solicitud de préstamo para los usuarios.
Según el coordinador nacional de laboratorios de FIMEB, no se tiene control de la información

ni del estado exacto de todos los equipos con los que cuentan los laboratorios, inclusive esto ha
ocasionado pérdidas materiales al no saber si un equipo o elemento se encuentra en mantenimiento
o está en préstamo a un miembro de la institución. Es por esta razón que se requiere un sistema
de gestión de equipos e inventarios donde se centralice la información y se pueda acceder fácilmente.
Actualmente haciendo uso de la tecnologı́a se observan numerosas aplicaciones para la administra-

ción de inventarios, tanto móviles como web, las cuales permiten inventariar, buscar y organizar
dichos inventarios. Estas herramientas no satisfacen a plenitud a la administración de FIMEB pues-
to que no cumplen con el requisito principal que es la gestión de equipos (préstamos) y no solo de
inventarios.
1.2. FORMULACIÓN DEL PROBLEMA

La manera actual con la cual se lleva a cabo la gestión de activos fijos, elementos e inventarios
en FIMEB, representa pérdidas tanto de información como materiales, puesto que no se tiene
conocimiento ni control sobre estos con total integridad.
1.3 JUSTIFICACIÓN 5
Desde la ingenierı́a de sistemas se propone el desarrollo de un sistema de gestión de equipos e

inventarios que permita a FIMEB centralizar su información y llevar un manejo transparente de
los recursos, beneficiándolos con tiempo y ahorro de dinero.
1.3. JUSTIFICACIÓN
Teniendo en cuenta las inconsistencias que se presentan en FIMEB relacionadas con los inventarios
en cuanto existencias y prestamos de equipos, se considera relevante el desarrollo e implementación
de un aplicativo web por cuanto beneficia tanto a docentes, como estudiantes y encargados del
laboratorio, disminuyendo tiempos para hacer los prestamos y tramitologı́a, obteniendo reportes
en cualquier momento y trazabilidad de cada elemento del laboratorio.
Darle un adecuado manejo a los recursos con los que cuenta la facultad es pertinente porque per-
mite a corto y mediano plazo agilizar los prestamos, disminuir las perdidas de elementos, además
de darle organización y documentación al proceso de administración de activos fijos.
En cuanto a inventarios a nivel tecnológico existen diversas herramientas que ofrecen apoyo rela-
cionado con organización de elementos, más no con relación a gestión de activos fijos. El aplicativo
propuesto cuenta con un valor agregado relacionado con: disminución de tiempos, agilización de
procesos, optimización de reportes y descarga de cada uno de estos.
Según el coordinador nacional de laboratorios de FIMEB, vieron la oportunidad de trabajar de

forma interdisciplinaria junto a la facultad de Ingenierı́a de Sistemas y por esta razón se buscó
un estudiante que deseara trabajar en articulación con las necesidades de FIMEB. Con la entrega
del proyecto a satisfacción, la facultad de FIMEB será beneficiada, disminuyendo los costos de
implementación de cualquier herramienta existente y mejorando los procesos internos, tanto de
modernización como de aprendizaje.
El desarrollo del sistema de gestión de información permite al estudiante afianzar y poner en

práctica los conocimientos adquiridos a través de la carrera de Ingenierı́a de Sistemas.
1.4. OBJETIVOS
1.4.1. Objetivo General
Desarrollar un aplicativo web para la Facultad de Ingenierı́a Mecánica, Electrónica y Biomédica de
la Universidad Antonio Nariño con el fin de sistematizar la gestión de equipos e inventarios de los
laboratorios de la Facultad.
1.4.2. Objetivos Especı́ficos

Desarrollar un módulo que garantice el control y la gestión de los equipos, que permita la
visualización, creación, edición y préstamo de los equipos de los laboratorios.
6 1 PLANTEAMIENTO DEL PROBLEMA
Permitir la visualización de los equipos que se encuentran en el área de mantenimiento y los

que no están disponibles en determinado momento, por medio de un módulo de consultas.
Desarrollar un módulo que permita llevar a cabo el conteo de elementos de un inventario,

garantizando la sincronización de la información.
Crear un módulo que visualice los inventarios, genere reportes de estos por medio de filtros y
además permita su descarga.
1.5. ALCANCES Y LIMITACIONES DEL PROYECTO

1.5.1. Alcances
El sistema de gestión de equipos e inventarios que se propone desarrollar según el tiempo previsto
de 4 meses tiene como alcances:
La aplicación web contará con los siguientes módulos administrativos:
Módulo que facilite visualizar los equipos disponibles, reservados y los que se encuentran en
calidad de préstamo; en este módulo se podrá gestionar el préstamo de equipos. Adicional-
mente en este módulo, se llevará a cabo la gestión de elementos de los laboratorios (creación,
edición, visualización) de un artı́culo perteneciente a los laboratorios de FIMEB.
Módulo que permitirá visualizar los equipos que se encuentren en mantenimiento.
Módulo para llevar a cabo el conteo de elementos de un inventario, junto a sus caracterı́sticas
y estado, para que cada equipo cuente con una hoja de vida.
Módulo que permitirá visualizar los inventarios realizados, y que permita generar reportes en
formato PDF y XLS, teniendo en cuenta la plantilla utilizada por la Universidad.
Módulo que permitirá la administración de usuarios del sistema (creación de usuarios, per-
misos).
Módulo de inicio de sesión (autenticación) en el cual podrá ingresar un usuario administrativo.
Módulo que visualizarán exclusivamente miembros activos de la facultad (estudiantes, profe-

sores) donde se verán los elementos disponibles de los laboratorios. Este módulo debe permitir
reservar un elemento del laboratorio, llenando un formato de reserva.
Para el desarrollo de la aplicación web las herramientas que se utilizarán son:
Entorno de desarrollo: Asp.Net Core.
Lenguaje de desarrollo: C Sharp (C#).
Bases de datos: MySQL.

1.5 ALCANCES Y LIMITACIONES DEL PROYECTO 7
Las herramientas anteriormente mencionadas son seleccionadas porque son tecnologı́as conocidas
por el estudiante y adecuadas para el desarrollo de aplicaciones web. Tanto el entorno de desarrollo
como el sistema de gestión de base de datos son de código abierto y por lo tanto su licenciamiento
es gratuito.
1.5.2. Limitaciones
El sistema de gestión de equipos e inventarios se lanzará en un plan piloto para los laboratorios
de FIMEB de la sede sur, dependiendo del uso, aplicación de pruebas y el resultado de estas,
será distribuido después por los laboratorios de las diferentes sedes del paı́s.
Se dispone de 4 meses para llevar a cabo el proyecto.

2. MARCO DE REFERENCIA
2.1. MARCO TEÓRICO

2.1.1. Inventario
Un inventario, sea cual sea la naturaleza de lo que contiene o el contexto en el que se esté llevan-
do a cabo, se compone de un listado ordenado de artı́culos pertenecientes a una organización. El
inventario, por tanto, ayuda a la empresa al abastecimiento de sus depósitos y bienes ayudando al
proceso comercial o productivo, y favoreciendo con todo ello la puesta a disposición del producto
al consumidor, sin importar el tamaño de la organización [Fernández, 2018].
El inventario es un instrumento necesario para que las organizaciones puedan gestionar las necesi-
dades de cada una de las existencias o de sus artı́culos, cuándo realizar pedidos a los proveedores
y qué cantidad solicitar, ya que en algunas oportunidades o se pide en exceso un elemento no tan
necesario o en otras en pocas cantidades un elemento que si se requiere. Para que los datos registra-
dos sean fiables y se ajusten a la realidad, se realiza un inventario fı́sico que consiste en contar las
unidades de existencias que, en un momento, la organizacióno tiene en su almacén [Fernández, 2018].
Como toda organización, FIMEB debe llevar un registro de los elementos pertenecientes a los
laboratorios de la facultad, haciendo un inventario fı́sico cada vez que lo requieran. La manera
actual como se gestionan los equipos y los inventarios en los laboratorios de FIMEB, conlleva a que
el proceso deje de ser ordenado, ya que se realizan prestamos de equipos y elementos, alterando la
información registrada.
2.1.2. Teorı́a de Inventarios

2.1.2.1. Tipos de inventarios
En función de los tipos de artı́culos, materiales o productos que pueden ser inventariados, existen
distintas clases de inventarios.
Según el momento:
Inventario inicial: se realiza al comienzo de cada periodo, cada organización define el inicio
de sus periodos y el final de los mismos [Zapata Cortés, 2014].
Inventario final: se realiza al cierre de cierto periodo, para calcular con que elementos quedo
el inventario y que cantidades hay en existencia [Zapata Cortés, 2014].
Según la periodicidad:
2.1 MARCO TEÓRICO 9
Inventario intermitente: es el que se puede efectuar diversas veces durante el transcurso del
año, puede ser mensual, trimestral o como se quiera definir [Zapata Cortés, 2014].
Inventario perpetuo: es una relación directa con la cantidad de elementos existentes en el

inventario, es decir si se retira un elemento, se actualiza la información [Zapata Cortés, 2014].
Según la forma:
Materias primas y componentes: es aquel que se encuentra conformado de aquellos mate-

riales, ya sean sencillas materias primas como piezas, que son necesarias para los procesos
productivos de las organizaciones [Fernández, 2018].
Piezas de repuesto de los equipos y de suministros industriales: los inventarios de las em-
presas, además de estar conformados por materias primas y componentes, también pue-
den estar formados por piezas de repuesto de cualquier elemento y diferentes suministros
[Fernández, 2018].
Productos finalizados: los productos finalizados son aquellos artı́culos que, una vez que han
salido del proceso de producción y pasados por los diferentes controles de calidad, quedan
disponibles para su entrega y despacho [Fernández, 2018].
Según la función:
Inventario fı́sico: se realizan para llevar a cabo el control y conteo de las existencias que se
encuentran en un momento concreto, esto con el fin de hacer coincidir dichas cifras con el
inventario contable que se tiene registrado [Fernández, 2018]. Las ventajas que el inventario
fı́sico aporta a la empresa son:
• Ordenar las existencias de ciertos elementos.
• Cuantificar de forma real las existencias.
• Corregir las diferencias entre los datos registrados y los reales.
• Ofrecer datos reales a la empresa ayudando a la purga de existencias.
Inventario mı́nimo: es la cantidad esencial que se requiere para poder seguir brindando servicio
[Matthew A. Waller, 2017].
Inventario máximo: es la cantidad máxima de elementos que se requieren para no tener más
de lo necesario [Matthew A. Waller, 2017].
Inventario en lı́nea: es el inventario que se hace en la lı́nea de producción, es decir, lo anterior

al inventario de productos terminados [Matthew A. Waller, 2017].
Inventario disponible: son los elementos que se encuentran disponibles [Matthew A. Waller, 2017].
Inventario agregado: este se aplica solo cuando administrar la existencia de un único artı́culo
representa un costo significativo [Muller, 2005].
Inventario en cuarentena: son todos los elementos que deben cumplir con un periodo de
almacenamiento antes de disponer de ellos [Muller, 2005].
10 2 MARCO DE REFERENCIA
Inventario de mercancı́a: es constituido por todos aquellos elementos comprados, que luego
van a ser vendidos sin ser modificados [Muller, 2005].
2.1.3. Herramientas de desarrollo

Para el desarrollo del sistema de gestión de equipos e inventarios se va a hacer uso de ASP.NET
Core, el uso de esta herramienta permite disminuir el tiempo de desarrollo del proyecto y facilita la
construcción de la aplicación, debido a que es una tecnologı́a conocida y utilizada con anterioridad
por el estudiante. El manejo de la base de datos del proyecto se realizará utilizando MySQL ya
que esta herramienta permite de manera ágil y eficiente administrar cantidades significativas de
datos, teniendo en cuenta que el sistema de gestión de equipos e inventarios contará con bastante
información relacionada con los elementos pertenecientes a los laboratorios.
2.1.3.1. ASP.NET CORE
ASP.NET Core es un marco de trabajo de programación gratuito y de código abierto, el cual se

ejecuta en un servidor Web para generar y representar de forma dinámica páginas Web. Las pági-
nas Web ASP.NET Core se pueden solicitar a cualquier explorador ya que representa el marcado
como HTML. Se puede utilizar la misma página para varios exploradores, porque ASP.NET Co-
re representa el marcado adecuado para el explorador que realiza la solicitud. ASP.NET Core es
compatible con los controles móviles de los dispositivos preparados para trabajar en Web como
teléfonos celulares, PC portátiles y asistentes digitales personales [Core, 2019].
2.1.3.2. MySQL
MySQL es un sistema de gestión de bases de datos relacional, este gestor de base datos es de código
abierto y su licenciamiento es gratuito por lo tanto su uso es muy común en entornos de desarrollo.
[MySQL, 2019].
2.2. METODOLOGÍA
2.2.1. Metodologı́a SCRUM
Scrum es una metodologı́a ágil de desarrollo de software. Scrum.org (una de las organizaciones
más importantes en la promoción y perfeccionamiento de Scrum) define Scrum como un framework
(marco de trabajo) para la gestión de productos, proyectos y servicios complejos que facilita un
desarrollo mantenido e incremental [Monte, 2016], por lo cual su uso es apropiado para el desarrollo
de este proyecto.
Las tareas establecidas son implementadas conforme un patrón de proceso llamado Sprint, dentro
de las actividades estructurales. Las actividades estructurales son: requerimientos, análisis, diseño,
evolución y entrega. Según el trabajo que se realiza en un sprint, se permite la adaptación en tiempo
real por parte del equipo de desarrollo [Pressman, 2003].
2.2 METODOLOGÍA 11
La metodologı́a Scrum propone tres roles:
Product Owner: es el enlace entre el cliente y el equipo de desarrollo. Define junto con el
Scrum Master, los criterios de aceptación del proyecto y de cada sprint.[Monte, 2016].
Scrum Master: es el encargado de administrar el proceso, haciendo que se cumplan las reglas
de Scrum[Ken Schwaber, 2016]. Es quien propone, promueve y potencia mejoras sobre el
proceso y sobre el Scrum team [Monte, 2016].
Equipo de desarrollo: son los encargados de desarrollar el proyecto. Se encargan de la entrega

del producto acabado y convenientemente depurado, siguiendo los procesos de aceptación
[Monte, 2016].
En la metodologı́a Scrum se utilizan algunas herramientas importantes:
ScrumBoard: el Scrum board es una herramienta opcional en el estándar Scrum, es la prin-

cipal herramienta visual del estado del sprint para el equipo Scrum. Debe mostrar la situa-
ción del sprint en tiempo real y, por lo tanto, hace falta actualizarlo a cada revisión diaria
[Monte, 2016].
Historias de usuario: son descripciones siempre muy cortas y esquemáticas, que resumen la
necesidad concreta de un usuario al utilizar un producto o servicio, ası́ como la solución que
la satisface.
Las actividades que propone la metodologı́a Scrum son:
Sprint: es la unidad de tiempo que determina un ciclo de desarrollo con Scrum.
Planificación del sprint: sirve para planificar en detalle el sprint. Recoger los requerimientos
y la funcionalidad que se ha de desarrollar, resolver dudas, crear las historias de usuario y
determinar los criterios de aceptación del sprint [Monte, 2016]. Esta actividad se realiza en el
inicio de cada sprint.
Reunión diaria: ha de realizarse siempre en el mismo lugar y a la misma hora, y no ha de durar

más de quince minutos, los miembros hablan sobre el trabajo asignado, dudas y problemas
[Monte, 2016].
Revisión del sprint: el equipo de desarrollo muestra a los usuarios/clientes el incremento de

producto desarrollado, para que puedan hacer una aceptación según los criterios de aceptación
establecidos, y ası́ poder iniciar el sprint siguiente [Monte, 2016].
Retrospectiva del sprint: Se buscan soluciones para las cuestiones aparecidas durante el sprint
que puedan haber sido un freno para la productividad.
Reunión de refinamiento: sirven principalmente para adquirir conocimiento (por ejemplo, por
parte del usuario en forma de requerimientos) o bien para tratar cambios [Monte, 2016].
Un factor clave de Scrum, es la duración de las actividades y las reuniones que siempre son limitadas
en el tiempo; es decir, no se hacen más reuniones de las necesarias, y tienen una duración limitada.
La metodologı́a Scrum se divide en diferentes fases que se llevan a cabo durante el desarrollo de un
proyecto.
Iniciación: se establece cada rol del equipo. Se define la visión del proyecto, y se realiza el
levantamiento de información pertinente [Monte, 2016].
Planeación y estimación: luego de la fase inicial, procede estimar las actividades y tareas a
realizar durante el desarrollo del proyecto. Se enlistan los requisitos a desarrollar, se le da
prioridad a los requisitos que requieren desarrollo inmediato. En esta fase se seleccionan las
herramientas a utilizar durante el proyecto y se definen los estándares de aceptación, se define
la fecha de entrega de los respectivos requerimientos. [Kniberg et al., 2010].
Implementación: tiene como objetivo llevar a cabo las diferentes tareas y actividades nece-
sarias para la creación del producto. Se incluye entregables, reuniones y retroalimentación
donde se revisa y se ajusta periódicamente los ı́tems entregables del product Backlog, hasta
que el producto sea aceptado y listo para su distribución [Sutherland, 1996].
Revisión: se revisan los resultados obtenidos y el trabajo realizado, se busca un plan de

mejoramiento de las prácticas y métodos que se utilizaron en la realización del proyecto de
ser necesario [SCRUMstudy, 2016].
Cierre: por último, en esta fase el producto desarrollado es preparado para su entrega, con el
material de capacitación correspondiente.
2.3. ESTADO DE ARTE

En el mercado actualmente existen programas que permiten llevar a cabo el control y proceso de
inventarios. Existen tanto aplicativos móviles que ya permiten hacer esto como también páginas
web. El mercado ofrece toda clase de herramientas informáticas, desde gratuitas para las pequeñas
empresas hasta complejos sistemas para las grandes compañı́as, pasando por diferentes tipos de
licenciamiento, como código abierto sin costo de licencia, hasta los productos licenciados con altos
costos de licencia e implementación, los que también están sujetos a contratos de soporte y ac-
tualización. Algunas aplicaciones web dan la oportunidad de ser utilizadas durante un periodo de
prueba, para luego decidir si pagarla o no.
Estas aplicaciones web permiten a los usuarios u organizaciones, gestionar inventarios, crear ele-
mentos a un inventario e inventariar. También poseen herramientas de contabilidad, contralorı́a y
logı́stica. Por lo general el precio de las aplicaciones aumenta con respecto al tamaño de la empresa.
SMARTBIT: el usuario ingresa los elementos del inventario, ya sea uno por uno o importando
una plantilla de Excel la cual contenga la referencia del elemento, el código de barras, la descripción,
las caracterı́sticas (precio de compra, precio de venta, entre otros). La aplicación permite analizar
2.3 ESTADO DE ARTE 13
ventas, márgenes, estados financieros, precios de venta, precios de compra, ı́ndices de rotación de
inventario y cumplimiento de metas. Al ser una herramienta tan sofisticada y de gran tamaño la
principal desventaja es su elevado costo. (Ver figura 2-1) [SMARTBIT, 2018].
Figura 2-1.: Aplicación web SMARTBIT
Fuente: tomado de [SMARTBIT, 2018]
SIIGO: agrupa inventarios de forma ágil, permite conocer la rotación de los productos y genera
informes personalizados con la información que requiere el usuario en tiempo real. También permite
agregar cada elemento perteneciente al inventario. A diferencia del anterior, este permite integrar
automáticamente todos los elementos pertenecientes al inventario automáticamente con las ventas,
el problema es que está pensado solo para negocios, por lo tanto se centra en las ventas y los
reportes sobre éstas. (Ver figura 2-2) [SIIGO, 2018]. En FIMEB esta herramienta no sirve, ya que
el principal requerimiento es la gestión de equipos.
Figura 2-2.: Aplicación web SIIGO
Fuente: tomado de [SIIGO, 2018]
SAP BUSINESS ONE: permite obtener información precisa sobre los envı́os entrantes y sa-
lientes, el inventario y la ubicación de artı́culos pertenecientes al inventario. Permite modificar
en tiempo real la cantidad de elementos existentes. Es una aplicación pensada para empresas de
logı́stica de tamaño grande, su costo es uno de los más elevados del mercado. (Ver figura 2-3)
[SAP BUSINESS ONE, 2018]. Está desarrollada en ABAP un lenguaje de cuarta generación, pro-
piedad de SAP que utilizan en la mayorı́a de sus productos. Por lo tanto esta aplicación web no es
la adecuada para FIMEB ya que la función principal es la logı́stica y no se adapta a las necesidades,
además su costo de adaptación es casi inalcanzable para cualquier institución educativa.
Figura 2-3.: Aplicación web SAP BUSINESS ONE
Fuente: tomado de [SAP BUSINESS ONE, 2018]
STOCK BASE: es una aplicación de escritorio que permite llevar a cabo la gestión de inventarios.
Aunque no es una aplicación web, se considera pertinente hablar sobre esta, debido a que es gratuita,
está desarrollada en Visual Objects y Microsoft C++. Con la diferencia de que está pensada
netamente para empresas pequeñas e inventarios de poco volumen, por lo tanto no es posible hacer
uso de esta en los laboratorios de FIMEB. (Ver figura 2-4) [STOCK BASE, 2014].
Figura 2-4.: Aplicación STOCK BASE
Fuente: tomado de [STOCK BASE, 2014]
ALEGRA: esta aplicación web permite llevar a cabo la gestión de inventarios y la facturación
electrónica en empresas medianas. También cuenta con herramientas de contabilidad las cuales
permiten tener registros e informes en tiempo real. Al igual que las anteriores también permite
exportar reportes. (Ver figura 2-5) [ALEGRA, 2018]. Al contar con facturación electrónica, el costo
es muy elevado y no cubre a plenitud las necesidades de FIMEB. Ésta herramienta además cuenta
con una aplicación móvil para manejar temas relacionados con la facturación electrónica.
Figura 2-5.: Aplicación web ALEGRA
Fuente: tomado de [ALEGRA, 2018]
PISTOLA LECTORA DE CÓDIGOS DE BARRAS: en algunas empresas los inventarios se

llevan a cabo mediante el uso de pistolas lectoras de códigos de barras conectadas a un computador
portátil, las cuales escanean el código y lo llevan a un archivo de Excel el cual debe ser abierto
manualmente antes de empezar con el inventario. Al escanear cada elemento y tener su código de
barras en cada fila, se deben agregar los datos de este en las columnas correspondientes, algunos de
los datos son: la cantidad, la descripción, la unidad de medida y la referencia. Al ser computarizada
se pierde tiempo y hace que la labor sea extensa, además esta sujeto a pérdidas de información
ya que todo se guarda en un archivo Excel. (Ver figura 2-6). Implementar este método, resultarı́a
muy costoso, debido que para llevarlo a cabo con plenitud es necesario hacer uso de varias pistolas
lectoras de códigos de barras, por el tamaño de los laboratorios con una sola no es suficiente.
Figura 2-6.: Inventario realizado en Excel con pistola lectora de código de barras
Fuente: elaboración propia
Se presenta la tabla 2-1 con los diferentes sistemas mencionados para diferenciar los productos
nacionales e internacionales, junto a sus ventajas y desventajas. Siendo la columna “O” el origen
de la aplicación (N: Nacional, I: Internacional) y la columna “A”: la aplicabilidad en los laboratorios
de FIMEB. En la última fila se encuentra FIMEB INVENTORY MANAGEMENT.
Tabla 2-1.: Aplicaciones existentes, ventajas y desventajas

O
APLICACIÓN A VENTAJAS DESVENTAJAS
N I
* Añadir elementos
inventario
* Elevado costo
* Ver en una lista los
SMARTBIT X NO * Uso empresa
elementos
de ventas
* Importar listas
formato excel
* Uso empresa
inventario
de ventas
SIIGO X NO * Ver en una lista los
* Solo muestra
elementos
reportes de ventas
* Generar reportes
* Aplicación más
* Elevado costo
SAP BUSINESS completa del mercado
X NO * Uso empresa
ONE y con más funcionali-
multinacional
dades
* Añadir elementos * Aplicación de
inventario escritorio
STOCK BASE X NO
* Ver en una lista los * Uso empresa
elementos pequeña
inventario * Elevado costo
* Ver en una lista los * Uso empresa
ALEGRA X NO elementos mediana
* Facturación * Funcionalidades
electrónica innecesarias
* Aplicación móvil
inventario
* Uso institución
* Ver en una lista los
educativa
elementos
*No permite importar
* Descargar hoja de
FIMEB INVENTORY lista de elementos
X SI vida de un elemento
MANAGEMENT en ningún formato
* Gestionar equipos
* No cuenta con opciones
pertenecientes a un
para generar reportes y
laboratorio
estadı́sticas
* Acceso desde
cualquier dispositivo

Con el estudio realizado se apreciaron algunos aplicativos existentes y sus principales caracterı́sti-
cas, se identifica que en el campo de inventarios existen diversas herramientas para llevarlos a cabo,
pero ninguna cumple a plenitud lo requerido por FIMEB, que es la gestión de equipos adicional a
los inventarios. Aún ası́ implementar o comprar una herramienta existente tiene un valor muy ele-
vado y las que no son costosas están diseñadas especı́ficamente para empresas de tamaño reducido.
Teniendo en cuenta que los laboratorios de FIMEB tienen un gran tamaño y diversos elementos, el
presente proyecto pretende cumplir a plenitud las necesidades de los laboratorios de la facultad.
En cuanto al desarrollo del sistema de gestión de equipos y elementos propuesto, como punto de
innovación frente a los sistemas existentes es la opción de llevar un registro personalizado sobre
cada elemento existente en un laboratorio y ası́ descargar una hoja de vida vinculada a cada uno
de estos, donde se listan los diferentes mantenimientos realizados al elemento, los repuestos que
fueron instalados y una breve descripción del proceso realizado.
3. METODOLOGÍA DE DESARROLLO
Para llevar a cabo el proyecto con éxito y tener un funcionamiento idóneo, se adaptará Scrum como
herramienta metodológica. Scrum es conocida por el estudiante y se ha optado por hacer uso de
esta metodologı́a porque permite disminuir el tiempo de elaboración del proyecto, además permite
correcciones a corto tiempo para realizar ajustes a los requerimientos de forma rápida.
Para el proyecto se definen los siguientes roles:
Product Owner: este rol lo cubrirá el coordinador de laboratorios de FIMEB, en representación

de la facultad.
Equipo de desarrollo: en este caso el estudiante quien realiza las actividades de implementación
y creación de los requisitos establecidos del proyecto.
Tester: el desarrollador realiza pruebas unitarias del sistema y verifica el funcionamiento de

los requerimientos.
Scrum Master: director del proyecto quién será el encargado de orientar al desarrollador por
medio de retroalimentaciones, asegurando que se lleve a cabo la implementación en el proyecto
la metodologı́a Scrum.
Al implementar esta metodologı́a en el desarrollo del proyecto se obtienen algunos beneficios, como
lo son:
Comunicación frecuente con el cliente (Product Owner), lo que permite tener un mayor ali-
neamiento.
Flexibilidad y adaptación en cuanto a las necesidades del cliente, que permite realizar cambios
en el Software.
Se mejora la calidad del Software por la constante revisión.
3.1. PROCESOS DEL PROYECTO

Los integrantes del equipo evalúan el sprint, con el fin de definir las tareas a realizar en un deter-
minado tiempo.
Las reuniones que se llevarón a cabo en el desarrollo del proyecto son:
Planeación del sprint: se harán reuniones semanales donde se detallarán los requerimientos,
se definirán los sprints, las fechas de entregables y las herramientas que se van a utilizar en
la aplicación.
3.2 FASES A IMPLEMENTAR EN EL PROYECTO 19
Reunión Semanal: se realizarán reuniones de 1 hora una vez por semana.
Refinamiento del backlog: si el equipo tiene dudas se solicita al product owner una reunión
para resolver inquietudes.
Revisión del sprint: se realizará la reunión entre el Scrum Master y en este caso, el desarro-
llador.
Retrospectiva: se llevará a cabo una reunión una vez al mes, donde se involucra todo el grupo
de trabajo, en donde se analizará básicamente que quedo bien o mal y qué falencias ocurrieron
durante el proceso del sprint.
3.2. FASES A IMPLEMENTAR EN EL PROYECTO

Inicio: se harán reuniones con todos los miembros del proyecto, donde se hace el levantamiento
de la información, para la identificación de requisitos.
Planeación y estimación: se hará un plan de trabajo que involucra actividades y tareas que
se llevarán a cabo. Se definirá la arquitectura y los recursos a utilizar para el desarrollo del
sistema de gestión de equipos e inventarios, como también el tiempo estimado en cada fase.
Implementación y desarrollo: se hará un listado de las tareas y actividades que van a hacer
parte del sprint backlog en reuniones que empezarán al comienzo de cada sprint. Al concluir
cada sprint se procede a realizar pruebas unitarias, funcionales y de integración. Al finalizar
se realizará una reunión donde se hace retroalimentación, revisiones y ajustes del proceso.
Revisión: se realizarán pruebas unitarias de cada módulo, luego pruebas de integración de todo
el sistema, se llevarán a cabo pruebas de stress haciendo múltiples peticiones y se analizarán
los resultados obtenidos con el fin de cumplir los requisitos planteados inicialmente.
Cierre: se hace la entrega del sistema de gestión de equipos e inventarios y el documento de

la tesis, manual de usuario y manual técnico.
3.3. SPRINT
El desarrollo del proyecto se va a dividir en 4 sprints, donde se realizarán las diferentes actividades
establecidas, con el objetivo de culminar con éxito la elaboración del trabajo propuesto.
3.3.1. Sprint 1
Módulo de inicio de sesión:
Autenticación con usuario y contraseña otorgada a un usuario administrativo.
Ingreso de usuarios activos de la facultad al módulo de visualización y reservas.

Módulo de creación de usuarios y permisos:
Usuarios administrativos.
20 3 METODOLOGÍA DE DESARROLLO
3.3.2. Sprint 2
Módulo de creación:
Crear, editar y eliminar elementos pertenecientes a un laboratorio.
3.3.3. Sprint 3
Módulo de inventarios:
Realizar el conteo de elementos a un inventario.
Visualizar los inventarios realizados.
Generar reportes de cada inventario y permitir su descarga.
3.3.4. Sprint 4
Módulo de gestión de equipos y elementos:
Prestar un elemento del laboratorio
Enviar a mantenimiento un elemento.
Ver estado de cada elemento.
Descargar hoja de vida de un elemento.
Añadir un comentario a cada elemento.
Módulo de mantenimiento
Visualizar elementos que se encuentren en esta área.
Cambiar estado de un elemento a disponible.

4. DESARROLLO DEL PROYECTO
En el proceso de desarrollo de la aplicación web FIMEB INVENTORY MANAGEMENT, se adaptó

la metodologı́a ágil Scrum, desarrollando cada una de las fases descritas en el capı́tulo anterior. A
continuación, se describirán cada una estas etapas.
4.1. DESCRIPCIÓN DE LA APLICACIÓN

FIMEB INVENTORY MANAGEMENT es una aplicación web que permite llevar a cabo la gestión
de equipos e inventarios de un laboratorio. Es un desarrollo a medida para los laboratorios de
FIMEB. Los beneficios de utilizar está aplicación es que se va obtener información con trazabilidad
y precisión, con el fin de obtener informes y estatus de los laboratorios en cualquier instante.
4.2. FASE DE INICIACIÓN

Dentro de esta fase se identificaron los actores correspondientes, de acuerdo con los roles de la
metodologı́a:
Product Owner: coordinador de laboratorios de FIMEB, en representación de la facultad.
Equipo de desarrollo (desarrollador, tester): Harold Reyes, representando los dos papeles.
Scrum Master: Ing. Juan Martı́nez.
De acuerdo con la metodologı́a Scrum, el respectivo proceso para el levantamiento de la información

se realizó mediante reuniones semanales entre el Scrum Master y el equipo de trabajo. En la tabla
4-1 se muestra la plantilla que se estableció para llevar a cabo las historias de usuario de los
requerimientos encontrados, según las reuniones que se hicieron con el equipo de trabajo. Los
campos de la tabla se explican a continuación:
Id: número identificador de la historia de usuario.
Usuario: hace referencia a los actores que van a llevar la correspondiente funcionalidad.
Nombre: nombre caracterı́stico el cual describe la funcionalidad a implementar.
Prioridad: es la prioridad que estableció el equipo de trabajo para su respectivo desarrollo.

Está es evaluada en una escala de 1-5, siendo 1 poco importante y 5 muy importante.
Desarrollador: es el encargado de realizar el desarrollo de la historia de usuario.

22 4 DESARROLLO DEL PROYECTO
Descripción: descripción del objetivo de la funcionalidad representando lo que se quiere con-

seguir de esta. Es redactado de acuerdo a lo dicho por el equipo de trabajo en las reuniones.
Resultado: presenta el resultado esperado al haber interactuado con la respectiva funcionali-

dad.
Criterio de aceptación: presenta los criterios con los cuales se validará si la funcionalidad
cumple con lo establecido o no, según los objetivos.
Tabla 4-1.: Plantilla Historias Usuario

Id
Nombre
Prioridad
Sprint
Desarrollador
Usuario
Resultado
Criterios de aceptación
Para manejar el progreso de las historias de usuario y llevar un control sobre el desarrollo de cada
una de estas, se utilizó el tablero de la herramienta Trello (herramienta gratuita). El proceso se
basó en organizar las historias de usuario asignadas durante la elaboración de cada sprint, las fases
se establecieron de la siguiente manera: en progreso, en pruebas, por revisar, y aceptado. A cada
etiqueta asociada a la historia de usuario se definió la información correspondiente a la figura 4-1.
Figura 4-1.: Etiqueta historia de usuario creada en Trello
Cuando se daba inicio al proceso de desarrollo de cada uno de los requerimientos (historias de
4.3 PLANEACIÓN Y ESTIMACIÓN 23
usuario), en el tablero de Trello se indicaba que estaba en progreso, después de haber terminado
con el desarrollo se pasaba la etiqueta al estado de pruebas, si no se encontraba ningún error se
pasaba a revisión y por último se indicaba que habı́a sido aceptada. Si en la fase de pruebas
se encontraba algún error se debı́a pasar nuevamente a progreso para realizar las respectivas
correcciones, como se observa en la figura 4-2, y realizar el proceso de nuevo.
Figura 4-2.: Flujo de trabajo tablero scrumBoard
4.3. PLANEACIÓN Y ESTIMACIÓN
En esta sección se identificaron los roles de la aplicación, se definió la arquitectura del sistema y el
listado de historias de usuario.
4.3.1. Roles del sistema
Usuario final: persona que va a utilizar la aplicación y hacer uso de las múltiples funciones.
Tendrá acceso a los diferentes módulos con los que está cuenta y podrá llevar a cabo la gestión
de equipos y elementos de un laboratorio.
Usuario administrador: persona que va a utilizar la aplicación al igual que un usuario final,
pero con permisos especiales para la configuración y gestión de usuarios (creación, edición de
datos, activación e inactivación).
4.3.2. Arquitectura y herramientas del sistema

Para la implementación de la arquitectura del sistema se utilizó el patrón Modelo Vista Controlador
(MVC), incluido por defecto con el desarrollo de aplicaciones web ASP.NET Core realizando la
correspondiente separación, esto permitió tener de manera independiente el modelo, las vistas y
el controlador, separando la lógica de negocio, lógica del modelo y la lógica de la vista, como se
muestra en la figura 4-3.
Figura 4-3.: Modelo vista controlador (MVC)
Controlador: la capa del controlador gestiona las peticiones de los usuarios, es responsable de
responder la información solicitada con la ayuda tanto del modelo como de la vista.
Modelo: es la capa encargada de los datos, encargada de hacer peticiones enviar y recibir
información (comunicación).
Vista: es la representación visual de los datos, todo lo que tenga que ver con la interfaz gráfica
va aquı́. Es responsable del uso de la información de la cual dispone para producir cualquier
interfaz de presentación de cualquier petición que se presente.
Los requerimientos no funcionales de la aplicación FIMEB INVENTORY MANAGEMENT son:
Interfaz gráfica de fácil interpretación.
Conexión a internet.
4.3.3. Casos de uso
Según el levantamiento que se realizó de los requisitos necesarios para el desarrollo de la aplicación
web, se elaboró un caso de uso general para describir el funcionamiento de la aplicación y las
acciones que pueden llevar a cabo los diferentes actores (administrador, laboratorista y estudiante).
Se realizó un diagrama general teniendo en cuenta que todas las acciones que se pueden realizar
en la aplicación dependen necesariamente de iniciar sesión y estar logueados en el sistema, como se
puede observar en la figura 4-4.
Figura 4-4.: Caso de uso general

4.3.4. Listado de historias de usuario
Según el levantamiento que se realizó de los requisitos necesarios para el desarrollo de la aplicación
web, se elaboró el listado de los correspondientes requerimientos, donde se describe el identificador
asociado, el sprint al que corresponde, el nombre, la prioridad, el tiempo estimado de desarrollo
(se calculó en horas ya que es mas fácil calcular el costo de una hora) y la persona encargada de
realizar la correspondiente funcionalidad. En la tabla 4-2 se puede observar el Product Backlog de
las historias de usuario correspondientes al desarrollo de FIMEB INVENTORY MANAGEMENT,
donde P es la prioridad de cada una y S el respectivo Sprint al que corresponde.
Tabla 4-2.: Product Backlog

TIEMPO
# ID NOMBRE S P DESARROLLADOR
ESTIMADO (h)
1 RQ1 Mostrar pantalla inicio 1 4 16 Harold Reyes
2 RQ2 Iniciar sesión 1 4 20 Harold Reyes
3 RQ3 Ingreso estudiante 1 3 22 Harold Reyes
4 RQ4 Mostrar pantalla principal 1 4 15 Harold Reyes
5 RQ5 Mostrar pantalla usuarios 1 4 15 Harold Reyes
6 RQ6 Crear y editar un usuario 1 4 18 Harold Reyes
7 RQ7 Activar/Inactivar un usuario 1 2 5 Harold Reyes
8 RQ8 Cerrar sesión 1 2 16 Harold Reyes
9 RQ9 Mostrar pantalla elementos 2 4 15 Harold Reyes
10 RQ10 Crear y editar un elemento 2 4 18 Harold Reyes
11 RQ11 Añadir comentarios a un elemento 2 2 12 Harold Reyes
12 RQ12 Dar de baja un elemento 2 3 14 Harold Reyes
13 RQ13 Generar inventario 3 4 16 Harold Reyes
14 RQ14 Descargar inventario PDF 3 4 30 Harold Reyes
15 RQ15 Descargar inventario Excel 3 4 30 Harold Reyes
16 RQ16 Mostrar elementos disponibles 4 5 16 Harold Reyes
17 RQ17 Mostrar elementos mantenimiento 4 5 16 Harold Reyes
18 RQ18 Descargar hoja de vida elemento 4 4 30 Harold Reyes
19 RQ19 Enviar elemento a mantenimiento 4 4 20 Harold Reyes
20 RQ20 Enviar elemento a disponibles 4 4 20 Harold Reyes
21 RQ21 Crear préstamo con elementos 4 5 40 Harold Reyes
22 RQ22 Crear reserva con elementos 4 5 40 Harold Reyes
23 RQ23 Confirmar reserva a préstamo 4 5 40 Harold Reyes

4.3.5. Plan de pruebas

Objetivo: mediante las pruebas se pretende verificar el funcionamiento, comportamiento y criterios
de calidad de la aplicación web FIMEB INVENTORY MANAGEMENTS, según los requerimientos
definidos por el usuario.
Alcance: con las pruebas realizadas se identificaron cada uno de los resultados según correspondı́a.
Las pruebas que se realizaron a la aplicación web FIMEB INVENTORY MANAGEMENT son las
siguientes:
Pruebas funcionales: con estas pruebas se comprobó que el módulo desarrollado funciona de
acuerdo con las especificaciones funcionales y los requerimientos establecidos por el product owner.
Fueron realizadas por el tester a medida que se analizaban cada uno de los módulos.
Pruebas de integración: en las pruebas de integración se validaron los componentes de cada

uno de los módulos, de tal forma que funcionaran adecuadamente en conjunto. Estas pruebas se
realizaron a partir de la creación del segundo módulo en donde se verificó el adecuado funciona-
miento de la aplicación, realizando el correspondiente flujo. Cuando se realizó el desarrollo de los
cuatro módulos (sesión,creación, inventarios y gestión de equipos) de la aplicación web FIMEB IN-
VENTORY MANAGEMENT, se efectuaron nuevamente estas pruebas, en donde se validó que los
cuatro módulos interactuaran correctamente sin presentar alguna inconsistencia o fallo, haciendo
uso de la herramienta Selenium.
Pruebas de aceptación: en las pruebas de aceptación, FIMEB se encargo de colocar a un labo-

ratorista para que revisara la funcionalidad de la aplicación, haciendo uso de ella y realizando las
pruebas funcionales.
Pruebas de carga y rendimiento: se implementaron estas pruebas cuando la aplicación estaba

completamente desarrollada, verificando que la base de datos soporta gran cantidad de datos y
opera con normalidad las diferentes operaciones, para determinar el desempeño de la aplicación
web.
Módulos que requieren probar la efectividad.
Módulo de inventarios.
Módulo de gestión de equipos.
Pruebas de compatibilidad: en las pruebas de compatibilidad, la aplicación se ejecutó desde

diferentes navegadores para comprobar el correcto funcionamiento.
Criterios de aceptación: en cada una de las pruebas mencionadas anteriormente se validó el re-
sultado obtenido, de forma que si se obtenı́a algún error este se podı́a corregir y nuevamente ejecutar
la prueba correspondiente. Al no presentar errores, se concluye que se superaron correctamente las
pruebas.
4.4. IMPLEMENTACIÓN Y DESARROLLO
En esta fase, mediante historias de usuario se definieron las tareas y actividades que se realizaron
por cada sprint, también se presentarón los mockups que conforman cada sprint y proceso de
trabajo realizado en Trello. Además, se realizaron casos de uso para complementar la información
de los sprints y entenderlos de forma adecuada. Se dividió la implementación y desarrollo en 4
sprints, como se habı́a mencionado en capı́tulos anteriores.
4.4.1. Sprint 1: Módulo Sesión
Durante el Sprint 1 se realizó el desarrollo de un módulo de sesión el cual garantiza que los usuarios
de la aplicación web FIMEB INVENTORY MANAGEMENT puedan iniciar sesión y acceder, para
utilizar las diferentes funcionalidades.
4.4.1.1. Requerimientos
Los requerimientos que hicieron parte del sprint 1 (módulo de sesión) se describen en las tablas: 4-3
Mostrar pantalla inicio, 4-4 Iniciar sesión, 4-5 Ingreso estudiante, 4-6 Mostrar pantalla principal,
4-7 Mostrar pantalla usuarios, 4-8 Crear y editar un usuario, 4-9 Activar/Inactivar un usuario y
4-10 Cerrar sesión.
Tabla 4-3.: Mostrar pantalla inicio

Id RQ1
Nombre Mostrar pantalla inicio
Prioridad 4
Sprint 1
Desarrollador Harold Reyes
Usuario Usuario Final
Yo como usuario requiero una pantalla de inicio en la cual el usuario pueda
Descripción
acceder como laboratorista o como miembro activo de la facultad.
Se desarrollará una pantalla de inicio con formulario de ingreso y un botón
Resultado
para miembros activos de la facultad.
Una vez el usuario ingrese la dirección de la aplicación se mostrará la
pantalla de inicio.

4.4 IMPLEMENTACIÓN Y DESARROLLO 29
Tabla 4-4.: Iniciar sesión

Id RQ2
Nombre Iniciar sesión
Prioridad 4
Sprint 1
Yo como usuario quiero poder iniciar sesión en la aplicación web,
Descripción
ingresando los siguientes datos: correo y contraseña.
En la pantalla de inicio se mostrará un formulario pidiendo los dos datos:
Resultado
correo y contraseña.
* Tanto correo como contraseña deben ser obligatorios
* El correo debe estar de la siguiente manera “usuario@dominio”
Criterios de aceptación * Se debe validar los datos ingresados existan
* Si algún dato no coincide se debe mostrar una alerta “Usuario o contraseña
incorrectos”
Tabla 4-5.: Ingreso estudiante

Id RQ3
Nombre Ingreso estudiante
Prioridad 3
Sprint 1
Descripción Yo como usuario requiero poder ingresar como miembro activo de la facultad
En la pantalla de inicio se mostrará un botón que diga “Soy estudiante” y al
Resultado
presionarlo abrirá un formulario donde se escribirá el código del estudiante.
* El código debe ser obligatorio
Criterios de aceptación * Se deben recibir valores alfanuméricos
* Si el código no existe se mostrará una alerta “Código no encontrado”

Tabla 4-6.: Mostrar pantalla principal

Id RQ4
Nombre Mostrar pantalla principal
Prioridad 4
Sprint 1
Yo como usuario quiero poder ingresar a la aplicación luego de haber
Descripción pasado el formulario de sesión. En esta pantalla se deben mostrar las
opciones que tiene la aplicación (menú y módulos)
Se mostrará la pantalla principal y en está los diferentes módulos en un
Resultado
menú en la parte superior.
Una vez se haya iniciado sesión exitosamente, se accederá a la pantalla
principal
Tabla 4-7.: Mostrar pantalla usuarios

Id RQ5
Nombre Mostrar pantalla usuarios
Prioridad 4
Sprint 1
Yo como usuario requiero poder ingresar a la aplicación y tener una lista
Descripción
de usuarios registrados en el sistema, junto a su información
Se mostrará la pantalla de usuarios con el listado de todos los usuarios
Resultado existentes, su información personal. Opción de agregar nuevo usuario
y opción de editar información
Una vez el usuario de clic en el menú principal, seleccionando la opción
de usuarios, debe poder ver los usuarios existentes

Tabla 4-8.: Crear y editar un usuario

Id RQ6
Nombre Crear y editar un usuario
Prioridad 4
Sprint 1
Yo como usuario quiero crear un nuevo usuario que va a poder ingresar
Descripción
a la aplicación y en cualquier momento poder editar su información
En la pantalla de usuarios, se mostrará una opción de agregar, la cual
Resultado
mostrará un formulario solicitando la información del nuevo usuario
* El nuevo usuario debe poder ingresar a la aplicación
* En cualquier momento se debe poder editar la información del usuario
Tabla 4-9.: Activar/Inactivar un usuario

Id RQ7
Nombre Activar/Inactivar un usuario
Prioridad 2
Sprint 1
Yo como usuario, requiero poder inactivar a un usuario en
Descripción
cualquier momento y tener la opción de activarlo.
En la pantalla de editar información, se mostrará una casilla de
Resultado
selección la cual activa e inactiva al usuario
* Un usuario inactivo no puede ingresar a la aplicación
* Al activar un usuario debe poder ingresar de nuevo a la aplicación

Tabla 4-10.: Cerrar sesión

Id RQ8
Nombre Cerrar sesión
Prioridad 2
Sprint 1
Yo como usuario requiero un botón de cerrar sesión en la pantalla principal
Descripción
el cual me saque de la aplicación por motivos de seguridad
En la parte superior de la pantalla principal se colocará un botón para cerrar
Resultado
sesión
Una vez el usuario de clic en cerrar sesión se debe redirigir a la pantalla
de inicio.
4.4.1.2. Mockups
Al ingresar a la aplicación se verá la pantalla de inicio como se muestra en la figura 4-5, en esta
el ı́tem 1 y 2 hacen referencia al formulario de inicio en el que se debe ingresar un usuario y una
contraseña, al dar clic en el ı́tem 3 “Ingresar” se valida la información, de ser correcta se permite el
ingreso a la aplicación. El ı́tem 4 “Soy estudiante” es el ingreso de estudiantes, al dar clic despliega
un formulario como se muestra en la figura 4-6 el cual solicita el código para hacer la respectiva
validación y permitir el ingreso.
Figura 4-5.: Mockup pantalla inicio

En el formulario de ingreso de la figura 4-6, el estudiante debe escribir su código y dar clic en el
ı́tem 1 “Ingresar” o bien puede dar clic en el ı́tem 2 “Cancelar” en caso de no querer ingresar.
Figura 4-6.: Mockup ingreso estudiante
Luego de validar los datos, al ingresar a la aplicación siendo administrador, no estudiante, en la

parte superior se verá un menú. Para ingresar al módulo de usuarios se debe dar clic en “Usuarios”.
Estando en la pantalla de usuarios (figura 4-7) se podrán ver los usuarios existentes, en este caso
laboratoristas, junto a su información personal. Es posible agregar un laboratorista “Usuario”
dando clic en el ı́tem 1 “Agregar” el cual llevará a una pantalla como se muestra en la figura 4-8.
Figura 4-7.: Mockup lista usuarios

Figura 4-8.: Mockup agregar usuario

4.4.2. Modelo relacional
En la figura 4-9 se observa la relación de las tablas del módulo de inicio de sesión, la tabla
adm usuario es donde se guarda la información del usuario, está relacionada con la tabla adm perfil
la cual indica el tipo de usuario (administrador, laboratorista o estudiante); también esta relacio-
nada con la tabla sys estado usuario que indica si un estudiante esta a paz y salvo o si tiene alguna
deuda. En el caso de los otros dos tipos de perfil se tendrá un estado de “no aplica”. La aplica-
ción puede tener diferentes laboratorios, para guardar la información de cada uno se tiene la tabla
adm laboratorio. Por último un laboratorista debe existir en al menos un laboratorio para poder
ingresar; por lo tanto, se utiliza la tabla adm usuario laboratorio para guardar el laboratorio al que
corresponde cada usuario. Se utilizó la notación conocida como pata de gallo para la representación
del modelo relacional.
Figura 4-9.: Modelo relacional sprint 1

4.4.3. Casos de uso
Se puede ver reflejados los diferentes casos de uso: inicio de sesión (figura 4-10, tabla 4-11 ), crear
o editar un usuario (figura 4-11, tabla 4-12) y cerrar sesión (figura 4-12).
Figura 4-10.: Caso de uso iniciar sesión
Figura 4-11.: Caso de uso crear y editar un usuario
Figura 4-12.: Caso de uso cerrar sesión

Tabla 4-11.: Caso de uso iniciar sesión

Id RQ1
Nombre Iniciar sesión
Actor Usuario (Administrador, laboratorista y estudiante)
El sistema permitirá ingresar a la aplicación, validando
Descripción
datos registrados existentes respecto al perfil
Precondición El usuario debe estar registrado en la base de datos
Se debe ingresar a la pantalla principal luego de la
Postcondición
validación exitosa de datos
Usuario Sistema
Flujo básico
1. Ingreso con usuario y
eventos
contraseña al sistema (usuario 2. Valida datos
administrador y laboratorista)
3. Ingreso con código al sistema
4. Valida datos
(usuario estudiante)
Flujo alternativo
Usuario Sistema
eventos
1.1 Ingresa datos incorrectos 2.1 Alerta indicando

Excepciones
3.1 Ingresa código incorrecto 4.1 Alerta indicando
Observaciones Ninguna

Tabla 4-12.: Caso de uso crear o editar un usuario

Id RQ6
Nombre Crear o editar un usuario
Actor Usuario (Administrador)
El sistema permitirá ingresar a la aplicación y registrar
Descripción un nuevo usuario o editar su información en cualquier
momento
Precondición El usuario debe iniciar sesión
Postcondición Se muestra una alerta indicando la gestión con éxito
Usuario Sistema
Flujo básico 1. Ingreso con usuario y
2. Valida datos
eventos contraseña al sistema
3. Seleccionar la opción 4. Se muestra la pantalla
Usuarios de usuarios
5. Se crea o se edita la 6. Registrará con éxito
información del usuario la información
Flujo alternativo Usuario Sistema
eventos
Excepciones
5.1 Correo o código que ya 6.1 Alerta indicando y
existe en el sistema no se guarda la info.

4.4.3.1. Diagrama de actividades
El diagrama de actividades correspondiente al módulo de sesión se muestra en la figura 4-13,

haciendo referencia al inicio de sesión de un usuario administrador (laboratorista) y el ingreso de
un estudiante.
Figura 4-13.: Diagrama de actividad inicio de sesión
En la figura 4-14 se puede ver el diagrama de actividad correspondiente a crear o editar un usuario.
Figura 4-14.: Diagrama de actividad crear y editar un usuario
En la figura 4-15 se puede ver el diagrama de actividad correspondiente a activar o inactivar un

usuario.
Figura 4-15.: Diagrama de actividad activar/inactivar un usuario
En la figura 4-16 se puede ver el diagrama de actividad correspondiente al cierre de sesión.
Figura 4-16.: Diagrama de actividad cerrar sesión

4.4.3.2. Scrum Board
Se crearon las siguientes historias de usuario para el sprint 1 empleando el tablero Trello: Mostrar
pantalla inicio, iniciar sesión, ingresar como estudiante, mostrar pantalla principal y cerrar sesión.
En la figura 4-17 se muestra la actividad de cada requerimiento desde su creación, desarrollo,
verificación y su aprobación.
Figura 4-17.: Scrum Board sprint 1

4.4.3.3. Pruebas funcionales
A continuación se muestran los casos de pruebas funcionales correspondientes al módulo de inicio de

sesión en las siguientes tablas: mostrar pantalla inicio 4-13, iniciar sesión 4-14, ingreso estudiante
4-15, mostrar pantalla principal 4-16, cerrar sesión 4-20 y sus resultados son:
Tabla 4-13.: Caso de prueba funcional (Mostrar pantalla inicio)

Número 1
Nombre caso
Mostrar pantalla inicio Usuario Usuario
de prueba
Estado de
Pasada Sprint 1
la prueba
Desarrollador Harold Reyes Prueba Harold Reyes
Esta prueba permite
validar que se muestra Se debe escribir la dirección
la pantalla de inicio Configuración de donde se encuentra
Descripción
de la aplicación, una de la prueba la aplicación. Se requiere
vez se haya ingresado conexión a Internet.
correctamente la dirección
Flujo de Eventos
Paso Acción Resultados esperados Pasado/Fallido
Ingresar en el navegador la Carga la aplicación y se
1 Pasada
dirección de la aplicación muestra la pantalla de inicio
Excepciones
Escribir la dirección de la
Se muestra en el navegador
1 aplicación y no tener Pasada
el error de conexión
conexión a Internet
Fuente elaboración propia

Tabla 4-14.: Caso de prueba funcional (Iniciar sesión)

Número 2
Nombre caso
Iniciar sesión Usuario Usuario
de prueba
Estado de
Pasada Sprint 1
la prueba
Se validará
Se debe escribir la
que el usuario puede
dirección de donde
ingresar sus datos
Configuración se encuentra la
Descripción y acceder a la
de la prueba aplicación.
aplicación. Los
Se debe tener conexión
datos a ingresar son
a Internet.
correo y contraseña
Flujo de Eventos
Ingresar a la Se muestra la pantalla
1 Pasada
aplicación de inicio
Ingresar los datos de
Ingresa a la aplicación y
correo y contraseña
2 muestra la pantalla Pasada
válidos y seleccionar
principal
la opción Ingresar
Excepciones
Ingresar correo
Se muestra el mensaje
1 sin la estructura Pasada
“Correo no valido”
indicada
Ingresar correo no Se muestra el mensaje
2 Pasada
existente “Usuario no encontrado”
Ingresar contraseña Se muestra el mensaje
3 no
incorrecta “Usuario no encontrado”
4 Dejar campo vacı́o Pasada
“Completa este campo”

Tabla 4-15.: Caso de prueba funcional (Ingreso estudiante)

Número 3
Nombre caso
Ingreso estudiante Usuario Usuario
de prueba
Estado de
Pasada Sprint 1
la prueba
Se debe escribir la
Se validará
que el estudiante
Descripción pueda ingresar su
código y acceder
a la aplicación.
a Internet.
Flujo de Eventos
Seleccionar la opción Se abre una ventana
1 Pasada
Ingresar como estudiante para escribir el código
Ingresa a la aplicación y
Digitar un código
2 muestra la pantalla Pasada
válido
de elementos
Excepciones
Ingresar correo Se muestra el mensaje
1 Pasada
inexistente “Código incorrecto”

Tabla 4-16.: Caso de prueba funcional (Mostrar pantalla principal)

Número 4
Nombre caso Mostrar pantalla
Usuario Usuario
de prueba principal
Estado de
Pasada Sprint 1
la prueba
Esta prueba permite Se debe escribir la
validar que se muestra dirección de donde
la pantalla principal Configuración se encuentra la
Descripción
de la aplicación, una de la prueba aplicación.
vez que un usuario Se debe tener conexión
ingrese a Internet.
Flujo de Eventos
Se accede a la pantalla
1 Ingresar a la aplicación Pasada
de inicio
Escribir datos de ingreso Se accede a la pantalla
2 Pasada
correctos principal

Tabla 4-17.: Caso de prueba funcional (Mostrar pantalla usuarios)

Número 5
Usuario Usuario
de prueba usuarios
Estado de
Pasada Sprint 1
la prueba
Se debe escribir la
Esta prueba permite
validar que se muestra
se encuentra la
la pantalla de usuarios y Configuración
Descripción aplicación.
una lista de usuarios de la prueba
junto a la información
a Internet. Se debe
asociada a cada uno
estar logueado
Flujo de Eventos
Ingresar a la pantalla Se accede a la pantalla
1 Pasada
principal principal
Seleccionar la opción Se accede a la
2 Pasada
Usuarios pantalla de usuarios

Tabla 4-18.: Caso de prueba funcional (Agregar y editar un usuario)

Número 6
Nombre caso Crear y editar
Usuario Usuario
de prueba un usuario
Estado de
Pasada Sprint 1
la prueba
Se debe escribir la
Esta prueba permite dirección de donde
validar que se agrega se encuentra la
Configuración
Descripción exitosamente un aplicación.
de la prueba
usuario nuevo Se debe tener conexión
al sistema a Internet. Se debe
estar logueado
Flujo de Eventos
En la pantalla principal
1 seleccionar la opción Pasada
de usuarios
Usuarios
Se habilita un formulario
Seleccionar la opción
2 solicitando los datos del Pasada
Agregar
nuevo usuario
Ingresar la información
del nuevo usuario y
3 “Se guardo la información Pasada
seleccionar la opción
correctamente”
Guardar
Excepciones

Tabla 4-19.: Caso de prueba funcional (Activar/Inactivar un usuario)

Número 7
Nombre caso Activar/Inactivar
Usuario Usuario
de prueba un usuario
Estado de
Pasada Sprint 1
la prueba
Se debe escribir la
validar que se inactiva se encuentra la
Configuración
Descripción un usuario y que se puede aplicación.
de la prueba
activar en cualquier Se debe tener conexión
momento a Internet. Se debe
estar logueado
Flujo de Eventos
de usuarios
Usuarios
Seleccionar el icono
con la información del
2 con la opción Pasada
usuario y una casilla
Editar información
de activación e inactivación
Desmarcar la casilla
para inactivar el usuario
y seleccionar la opción
correctamente”
Guardar

Tabla 4-20.: Caso de prueba funcional (Cerrar sesión)

Número 8
Nombre caso
Cerrar sesión Usuario Usuario
de prueba
Estado de
Pasada Sprint 1
la prueba
Se debe escribir la
Esta prueba validará
se encuentra la
que el usuario pueda Configuración
cerrar sesión en la de la prueba
aplicación
a Internet. Se debe
estar logueado
Flujo de Eventos
En la pantalla principal Sale de la pantalla
1 seleccionar la opción principal y se va Pasada
Cerrar sesión a la pantalla de inicio
4.4.3.4. Actas de aceptación del Sprint
Debido a diversos compromisos que tienen en FIMEB, junto al Product Owner se estableció realizar
una sola revisión al Sprint 1 y 2, ya que a ellos se les facilitaba más realizar la revisión de esta
manera, mientras que al Sprint 3 y al Sprint 4 por su complejidad, se le realizaron las respectivas
revisiones de manera individual como corresponde de acuerdo a la metodologı́a utilizada. Se adjunta
en anexos el acta de la entregas de cada Sprint (ver anexo C).
4.4.4. Sprint 2: Módulo Creación

Durante el Sprint 2 se realizó el desarrollo de un módulo de creación que permite a los usuarios (ad-
ministrador y laboratorista) de la aplicación web FIMEB INVENTORY MANAGEMENT agregar
los diferentes elementos y equipos pertenecientes a un laboratorio.
Los requerimientos que hicieron parte del sprint 2 (módulo de creación) se describen en las tablas:
4-21 Mostrar pantalla elementos, 4-22 Crear y editar un elemento, 4-23 Añadir comentarios a un
elemento y 4-24 Dar de baja a un elemento.
Tabla 4-21.: Mostrar pantalla elementos

Id RQ9
Nombre Mostrar pantalla elementos
Prioridad 4
Sprint 2
Yo como usuario requiero una pantalla en la cual pueda ver los elementos
Descripción
que pertenecen a un laboratorio
Se mostrará una pantalla en la cual se verán listados los elementos que
Resultado
pertenecen a un laboratorio
Criterios de aceptación Se deben ver todos los elementos que se hayan creado en la aplicación
Tabla 4-22.: Crear y editar un elemento

Id RQ10
Nombre Crear y editar un elemento
Prioridad 4
Sprint 2
Yo como usuario quiero crear un elemento que pertenece al
Descripción
laboratorio y en cualquier momento poder editar su información
Se mostrará un botón en la pantalla de elementos el cual diga agregar,
Resultado
este habilitará un formulario solicitando los datos del elemento
* Se debe poder agregar un elemento
* Se debe llenar todo el formulario

Tabla 4-23.: Añadir comentarios a un elemento

Id RQ11
Nombre Añadir comentarios a un elemento
Prioridad 2
Sprint 2
Yo como usuario necesito agregar un comentario a cualquier elemento
Descripción
existente del laboratorio, para reportar cualquier novedad.
En la pantalla de elementos se mostrará un icono el cual permite agregar
Resultado
el comentario al elemento en un pop-up
Criterios de aceptación El comentario debe ser guardado únicamente en el elemento seleccionado
Tabla 4-24.: Dar de baja un elemento

Id RQ12
Nombre Dar de baja a un elemento
Prioridad 3
Sprint 2
Yo como usuario quiero dar de baja un elemento del laboratorio que ya no
Descripción
funcione.
En la pantalla de elementos se tendrá un icono de inactivación el cual
Resultado
permitirá dar de baja a un elemento y este no volverá a aparecer en disponibles.
Criterios de aceptación El elemento debe aparecer en la lista de elementos de baja.
4.4.4.2. Mockups
Luego de validar los datos de ingreso y estar dentro de la aplicación, un usuario puede agregar un
elemento que pertenezca al laboratorio, pero para agregar un elemento es necesario primero incluir
un tipo elemento. Con tipo elemento nos vamos a referir a una categorı́a a la cual va a pertenecer
cada elemento del laboratorio, esto con fines de conteo y logı́stica. En la figura 4-18 se puede
observar como se van a listar los tipos de elementos existentes en una pantalla, para añadir un tipo
elemento nuevo se debe dar clic en el ı́tem 1 “Agregar” el cual desplegará un formulario como se
muestra en la figura 4-19, si se desea editar la información se podrá al hacer clic en el ı́tem 2, el
cual habilita la edición.
Figura 4-18.: Mockup pantalla tipo elemento
Al estar en la opción de agregar tipo elemento se tendrá un campo de descripción y dos opciones,
ı́tem 1 “Insertar” e ı́tem 2 “Cancelar” como se muestra en la figura 4-19 siendo un proceso rápido
y sencillo.
Figura 4-19.: Mockup agregar tipo elemento

Luego de agregar un tipo elemento, se procede a ir a la pantalla de elementos para agregar un

nuevo elemento perteneciente al laboratorio, en esta pantalla se verá un formulario de registro el
cual solicita el tipo de elemento al que pertenece, el estado en el que va a entrar al laboratorio
(disponible o mantenimiento), la placa, el serial, el modelo, la marca y alguna observación si es
necesario. Al terminar el formulario se tendrán dos opciones que son ı́tem 1 “Guardar” e ı́tem 2
“Cancelar”.
Figura 4-20.: Mockup agregar elemento
4.4.4.3. Modelo relacional
En la figura 4-21 se observa la relación de las tablas de módulo de creación, la tabla adm tipo elemento
guarda los diferentes tipos (categorı́as) de elementos de un laboratorio, se relaciona con la tabla
“principal” o con mayor relevancia de este sprint,la tabla adm elemento que guarda la información
de cada elemento perteneciente a un laboratorio (placa, modelo, serial, marca entre otros), esta se
relaciona con la tabla adm elemento parte la cual contiene partes de un elemento que esta cons-
tituido por diversas partes y también se relaciona con la tabla sys elemento estado que indica el
estado de cada elemento (disponible, mantenimiento, préstamo y de baja).
4.4.4.4. Casos de uso
En el módulo de creación se encuentran los casos de uso de las siguientes funcionalidades: crear
y editar un elemento (ver figura 4-22, tabla 4-25), añadir comentarios a un elemento (ver figura
4-23, 4-26) y dar de baja un elemento (ver figura 4-24, 4-27).
Figura 4-22.: Caso de uso crear o editar un elemento

Figura 4-23.: Caso de uso añadir comentarios a un elemento
Figura 4-24.: Caso de uso dar de baja un elemento

Tabla 4-25.: Caso de uso crear o editar un elemento

Id RQ10
Nombre Crear o editar un elemento
Actor Usuario (Administrador, laboratorista)
Descripción un nuevo elemento o editar su información en cualquier
momento
Precondición El usuario debe iniciar sesión
Usuario Sistema
2. Valida datos
Elementos de elementos
5. Se crea o se edita la 6. Registrará con éxito
información del elemento la información
eventos
Excepciones 1.1 Ingresa datos incorrectos 2.1 Alerta indicando

Tabla 4-26.: Caso de uso añadir comentario a un elemento

Id RQ11
Nombre Añadir comentarios a un elemento
Descripción
a un elemento existente un comentario
Precondición El usuario debe iniciar sesión y el elemento debe existir
Usuario Sistema
2. Valida datos
5. Añadir comentario al 6. Registrará con éxito
elemento seleccionado la información
eventos

Tabla 4-27.: Caso de uso dar de baja un elemento

Id RQ12
Nombre Dar de baja un elemento
El sistema permitirá dar de baja a un elemento
Descripción
existente
Precondición El usuario debe iniciar sesión y el elemento debe existir
Usuario Sistema
2. Valida datos
6. El elemento ya no se
5. Dar de baja al elemento
lista en disponibles
eventos

Los diagramas de actividades correspondientes al módulo de creación de los requerimientos, crear

y editar un elemento (ver figura 4-25), añadir comentarios a un elemento (ver figura 4-26) y dar
de baja un elemento (ver figura 4-27).
Figura 4-25.: Diagrama de actividad crear y editar un elemento
Figura 4-26.: Diagrama de actividad añadir comentarios a un elemento
Figura 4-27.: Diagrama de actividad dar de baja un elemento

Se crearon las siguientes historias de usuario para el sprint 2 empleando el tablero Trello: mostrar
pantalla elementos, crear y editar un elemento, añadir comentarios a un elemento y dar de baja
un elemento. En la figura 4-28 se muestra la actividad de cada requerimiento desde su creación,
desarrollo, verificación y su aprobación.

A continuación se muestran los casos de pruebas funcionales correspondientes al módulo de creación

en las siguientes tablas: mostrar pantalla elementos 4-28, crear y editar un elemento 4-29, Añadir
comentarios a un elemento 4-30, dar de baja un elemento 4-31 y sus resultados son:
Tabla 4-28.: Caso de prueba funcional (mostrar pantalla elementos)

Número 9
Usuario Usuario
de prueba elementos
Estado de
Pasada Sprint 2
la prueba
Se debe escribir la
validar que se muestra se encuentra la
Configuración
Descripción la pantalla de elementos aplicación.
de la prueba
pertenecientes a un Se debe tener conexión
laboratorio a Internet. Se debe
estar logueado
Flujo de Eventos
Se ingresa a la pantalla
de elementos
Elementos

Tabla 4-29.: Caso de prueba funcional (Crear y editar un elemento)

Número 10
Nombre caso Crear y editar
Usuario Usuario
de prueba un elemento
Estado de
Pasada Sprint 2
la prueba
Se debe escribir la
Configuración
de la prueba
elemento nuevo Se debe tener conexión
a un laboratorio a Internet. Se debe
estar logueado
Flujo de Eventos
de elementos
Elementos
2 solicitando los datos del Pasada
Agregar
nuevo elemento
Ingresar la información
del nuevo elemento y
seleccionar la opción
correctamente”
Guardar
Excepciones

Tabla 4-30.: Caso de prueba funcional (Añadir comentarios a un elemento)

Número 11
Nombre caso Añadir comentarios
Usuario Usuario
de prueba a un elemento
Estado de
Pasada Sprint 2
la prueba
Se debe escribir la
Configuración
de la prueba
comentario a un Se debe tener conexión
elemento existente a Internet. Se debe
estar logueado
Flujo de Eventos
de elementos
Elementos
Seleccionar el icono Se abrirá una ventana
2 con la opción para ingresar el Pasada
Añadir comentario comentario
Escribir el comentario Se muestra el mensaje
3 y seleccionar la opción “Se guardo la información Pasada
Guardar correctamente”
Excepciones
Dejar vacı́o el campo Se muestra el mensaje
1 Pasada
del comentario “Completa este campo”

Tabla 4-31.: Caso de prueba funcional (Dar de baja un elemento)

Número 12
Nombre caso Dar de baja
Usuario Usuario
de prueba un elemento
Estado de
Pasada Sprint 2
la prueba
Se debe escribir la
Esta prueba permite
se encuentra la
validar que se da de Configuración
baja un elemento de de la prueba
un laboratorio
a Internet. Se debe
estar logueado
Flujo de Eventos
de elementos
Elementos
Se muestra una ventana
de confirmación
Dar de baja
“Se cambio correcta-
3 Seleccionar la opción Si Pasada
mente el estado del
elemento’
Excepciones
Se cierra la ventana
1 Seleccionar la opción No Pasada
de confirmación
4.4.5. Sprint 3: Módulo Inventarios

Durante el Sprint 3 se realizó el desarrollo de un módulo de inventarios que permite a los usuarios
(administrador y laboratorista) de la aplicación web FIMEB INVENTORY MANAGEMENT des-
cargar el inventario de elementos existentes en formato Excel y PDF. Además, es posible descargar
en formato Excel los elementos disponibles, los que se encuentran en mantenimiento y los que están
en calidad de préstamo.
Los requerimientos que hicieron parte del sprint 3 (módulo de inventarios) se describen en las tablas:
4-32 Generar inventario, 4-33 Descargar inventario PDF y 4-34 Descargar inventario Excel.
Tabla 4-32.: Generar inventario

Id RQ13
Nombre Generar inventario
Prioridad 4
Sprint 3
Yo como usuario requiero generar un inventario con los elementos y equipos
Descripción
actuales del laboratorio, obteniendo reportes confiables en cualquier momento
En la pantalla de elementos se tendrá un icono de inactivación el cual
Resultado permitirá dar de baja a un elemento y este no volverá a aparecer en
disponibles.
Criterios de aceptación El elemento debe aparecer en la lista de elementos de baja.
Tabla 4-33.: Descargar inventario PDF

Id RQ14
Nombre Descargar inventario PDF
Prioridad 4
Sprint 3
Yo como usuario deseo descargar el inventario generado en formato PDF
Descripción
para consultarlo en cualquier momento o enviarlo
En la pantalla de elementos existentes se tendrá un botón el cual va
Resultado
a permitir la descarga del inventario en formato PDF
* Cumplir con la plantilla de la universidad
* Ordenar los elementos

Tabla 4-34.: Descargar inventario Excel

Id RQ15
Nombre Descargar inventario Excel
Prioridad 4
Sprint 3
Yo como usuario deseo descargar el inventario generado en formato
Descripción
Excel para consultarlo en cualquier momento o enviarlo
En la pantalla de elementos existentes se tendrá un botón el cual va
Resultado
a permitir la descarga del inventario en formato Excel
* Ordenar los elementos
4.4.5.2. Mockups
Para navegar por el módulo de inventarios, se debe ingresar a la pantalla de elementos. En la parte
superior se encontrarán dos iconos: uno indicando la descarga en formato Excel (ı́tem 1) y el otro
indicando la descarga en formato PDF (ı́tem 2), tal como se muestra en la figura 4-29.
Figura 4-29.: Mockup descarga inventario

En la figura 4-30 se observa la relación de las tablas de módulo de inventarios, la tabla adm tipo elemento
guarda los diferentes tipos (categorı́as) de elementos de un laboratorio, se relaciona con la tabla
“principal” o con mayor relevancia de este sprint,la tabla adm elemento que guarda la información
de cada elemento perteneciente a un laboratorio (placa, modelo, serial, marca, entre otros) para
luego hacer la descarga del inventario con todos los elementos existentes, esta se relaciona con la
tabla adm elemento parte la cual contiene partes de un elemento que esta constituido por diver-
sas partes y también se relaciona con la tabla sys elemento estado que indica el estado de cada
elemento (disponible, mantenimiento, préstamo y de baja).
Se puede ver reflejado el caso de uso general del módulo de inventarios (figura 4-31, tabla 4-35)
donde se puede encontrar la funcionalidad de descargar un inventario ya sea en formato PDF o en
formato Excel.
Figura 4-31.: Caso de uso sprint 3

Tabla 4-35.: Caso de uso añadir comentario a un elemento

Id RQ14
Nombre Descargar inventario
El sistema permitirá descargar en cualquier
Descripción
instante el inventario de elementos existentes
Precondición El usuario debe iniciar sesión y deben existir elementos
Postcondición Se inicia la descarga del inventario
Usuario Sistema
2. Valida datos
5.Descargar el inventario 6. Inicia la descarga
eventos
El diagrama de actividades correspondiente al módulo de inventarios se muestra en la figura 4-32,

haciendo referencia a la descarga de un inventario.
Figura 4-32.: Diagrama de actividades sprint 3

Se crearon las siguientes historias de usuario para el sprint 3 empleando el tablero Trello: generar
inventario, descargar inventario PDF y descargar inventario Excel. En la figura 4-33 se muestra la
actividad de cada requerimiento desde su creación, desarrollo, verificación y su aprobación.

A continuación se muestra el caso de prueba general para el módulo de inventarios y su respectiva

descarga (tabla 4-36), aunque en este sprint se tienen tres historias de usuario, las tres están
enfocadas a descargar un inventario por lo tanto el proceso va a ser igual para los diferentes
formatos de descarga.
Tabla 4-36.: Caso de prueba funcional (Descargar inventario)

Número 13
Nombre caso
Descargar inventario Usuario Usuario
de prueba
Estado de
Pasada Sprint 3
la prueba
Se debe ingresar al
módulo de elementos.
a Internet. Se debe
que el usuario pueda Configuración
Descripción dar permiso en el
ingresar y descargar de la prueba
navegador para
el inventario
permitir la descarga
Se debe estar
logueado.
Flujo de Eventos
Carga la pantalla con
el listado de elementos
Elementos
con la opción Inicia la descarga del
2 Pasada
correspondiente al inventario
formato de descarga
Excepciones
No tener Se muestra en el navegador
1 Pasada
conexión a Internet el error de conexión
No otorgar permiso
2 No inicia la descarga Pasada
de descarga

4.4.6. Sprint 4: Módulo Gestión

Durante el Sprint 4 se realizó el desarrollo de un módulo de gestión que permite a los usuarios (ad-
ministrador y laboratorista) de la aplicación web FIMEB INVENTORY MANAGEMENT aceptar
reservas, prestar elementos y cambiar el estado de estos (disponibles, mantenimiento).
Los requerimientos que hicieron parte del sprint 4 (módulo de gestión de equipos y elementos) se
describen en las tablas: 4-37 Mostrar elementos disponibles, 4-38 Mostrar elementos mantenimien-
to, 4-39 Descargar hoja de vida elemento, 4-40 Enviar elemento a mantenimiento, 4-41 Enviar
elemento a disponibles, 4-42 Crear préstamo con elementos, 4-43 Crear reserva con elementos y
4-44 Confirmar reserva a préstamo.
Tabla 4-37.: Mostrar elementos disponibles

Id RQ16
Nombre Mostrar elementos disponibles
Prioridad 5
Sprint 4
Yo como usuario necesito ver listados los elementos disponibles del
Descripción
laboratorio para realizar su respectivo préstamo y gestión
Resultado En la pantalla principal se verán los elementos disponibles del laboratorio
Criterios de aceptación Sólo se deben ver los elementos disponibles
Tabla 4-38.: Mostrar elementos mantenimiento

Id RQ17
Nombre Mostrar elementos mantenimiento
Prioridad 5
Sprint 4
Yo como usuario necesito ver listados los elementos que se encuentran
Descripción
en mantenimiento para luego enviarlos a disponibles
En la pantalla principal habrá un combo el cual permitirá traer los
Resultado
elementos que se encuentran en mantenimiento
Criterios de aceptación Sólo se deben ver los elementos en mantenimiento

Tabla 4-39.: Descargar hoja de vida elemento

Id RQ18
Nombre Descargar hoja de vida elemento
Prioridad 4
Sprint 4
Yo como usuario requiero descargar la hoja de vida de cada elemento
Descripción
para saber que mantenimientos se le han realizado
En la pantalla de elementos habrá un icono que permita descargar la
Resultado
hoja de vida
* Ordenar los mantenimientos por fecha
Tabla 4-40.: Enviar elemento a mantenimiento

Id RQ19
Nombre Enviar elemento a mantenimiento
Prioridad 4
Sprint 4
Yo como usuario necesito poder enviar cualquier elemento disponible a
Descripción
mantenimiento para su revisión
En el listado de elementos disponibles habrá un icono el cual permita que se
Resultado
envı́en los elementos a mantenimiento
Criterios de aceptación Se debe preguntar el tipo de mantenimiento (preventivo, correctivo)

Tabla 4-41.: Enviar elemento a disponibles

Id RQ20
Nombre Enviar elemento a disponibles
Prioridad 4
Sprint 4
Yo como usuario necesito poder enviar a disponibles cualquier elemento
Descripción
que haya salido de mantenimiento para hacer uso de este
En el listado de elementos en mantenimiento habrá un icono el cual
Resultado
permita enviar de mantenimiento a disponibles
Criterios de aceptación El elemento debe aparecer en la lista de disponibles
Tabla 4-42.: Crear préstamo con elementos

Id RQ21
Nombre Crear préstamo con elementos
Prioridad 5
Sprint 4
Yo como usuario requiero poder generar un préstamo con diversos
Descripción
elementos para que un estudiante los tome prestados
En el listado de elementos disponibles se tendrá una casilla de selección
para marcar los diferentes elementos que se van a prestar y luego en la
Resultado
parte superior habrá un botón que diga préstamo, el cual al dar clic va a
generar el préstamo llenando un formulario
Criterios de aceptación Los elementos prestados no deberán aparecer en disponibles

Tabla 4-43.: Crear reserva con elementos

Id RQ22
Nombre Crear reserva con elementos
Prioridad 5
Sprint 4
Yo como usuario requiero poder crear una reserva con los elementos
Descripción
disponibles del laboratorio para llegar a solicitarlos y agilizar el proceso
Al ingresar como estudiante se verán listados los elementos disponibles
y una casilla para seleccionar los que desea solicitar en préstamo. En la
Resultado
parte superior habrá un botón que diga reservar y al dar clic se creará
la reserva
Al crear una reserva los elementos deben seguir apareciendo en
disponibles, solo hasta su confirmación pasarán a préstamo
Tabla 4-44.: Confirmar reserva a préstamo

Id RQ23
Nombre Confirmar reserva a préstamo
Prioridad 5
Sprint 4
Yo como usuario requiero poder confirmar o rechazar una reserva de un
Descripción estudiante, teniendo en cuenta los elementos disponibles en el momento
para agilizar el proceso de préstamos de elementos
Se mostrará en una pantalla las reservas realizadas por los estudiantes,
Resultado
cada una con dos iconos siendo las dos opciones, aceptar o rechazar
Al confirmar una reserva los elementos pasarán a préstamo y dejarán de
estar en disponibles.
4.4.6.2. Mockups
Para navegar por el módulo de gestión de equipos y elementos es necesario ir a la pantalla de

elementos como se muestra en la figura 4-34. Al ingresar a la pantalla de elemento se verán listados
los elementos disponibles del laboratorio.
Figura 4-34.: Mockup elementos disponibles
En la pantalla de elementos habrá un combo que permita seleccionar los elementos que deseemos
observar, al elegir “Mantenimiento” se verán listados los elementos que se encuentran en manteni-
miento como se muestra en la figura 4-35.
Figura 4-35.: Mockup elementos mantenimiento

Para enviar un elemento a mantenimiento, estando en la pantalla de elementos es necesario estar

observando los elementos disponibles. Se tendrá un icono que permita enviar el elemento a man-
tenimiento, el cual desplegará un formulario para seleccionar el tipo de mantenimiento como se
muestra en la figura 4-36.
Figura 4-36.: Mockup enviar elemento a mantenimiento
Para crear un préstamo estando en la pantalla de elementos, cada elemento tendrá a su izquierda
una casilla de selección. Se deben seleccionar los elementos que se van a dar en calidad de préstamo
y luego dar clic en la parte superior en la opción “Préstamo” (ı́tem 1) como se muestra en la figura
4-37. Para realizar una reserva el proceso será igual, pero cambia la vista de pantalla ya que el
estudiante únicamente verá los elementos disponibles sin el menú superior.
Figura 4-37.: Mockup crear préstamo con elementos

En el siguiente modelo entidad relación se muestra el sprint 4 (ver figura 4-38). La tabla adm elemento
guarda la información de cada elemento perteneciente a un laboratorio (placa, modelo, serial,
marca, entre otros) la cual se relaciona con la tabla adm tipo elemento haciendo referencia a la
categorı́a a la que pertenece cada elemento y se relaciona con la tabla adm elemento parte que
guarda la información de un elemento que esta conformado por varias partes. También se relaciona
con la tabla sys elemento estado que indica el estado de cada elemento (disponible, mantenimien-
to, préstamo y de baja). La tabla adm mantenimiento contiene la información de los diferentes
mantenimientos realizados a un elemento y el tipo de mantenimiento llevado a cabo, el tipo de
mantenimiento que se le realiza a un elemento se obtiene de la tabla sys tipo mantenimiento. En
la tabla adm prestamo reserva se guardan los préstamos y las reservas generadas, los elementos
solicitados en cada préstamo o reserva se guardan en la tabla adm prestamo reserva elemento.
Los elementos del laboratorio van a estar en constante cambio de estado (disponible, préstamo,
mantenimiento), por eso es necesario llevar un registro de cada cambio de estado, que se guarda
en la tabla log estado elemento. Se pueden ver las diferentes tablas mencionadas en los sprints
anteriores ya que todas son necesarias para el correcto funcionamiento del cuarto sprint.

En el módulo de gestión de equipos y elementos, se encuentran los casos de uso de las siguientes
funcionalidades: descargar hoja de vida elemento (ver figura 4-39, tabla 4-45), enviar elemento a
mantenimiento (ver figura 4-40, tabla 4-46), enviar elemento a disponibles (ver figura 4-41, tabla
4-47), crear préstamo con elementos (ver figura 4-42, tabla 4-48), crear reserva con elementos (ver
figura 4-43, tabla 4-49) y confirmar reserva a préstamo (ver figura 4-44, tabla 4-50).
Figura 4-39.: Caso de uso descargar hoja de vida elemento
Figura 4-40.: Caso de uso enviar elemento a mantenimiento

Figura 4-41.: Caso de uso enviar elemento a disponibles
Figura 4-42.: Caso de uso crear préstamo con elementos
Figura 4-43.: Caso de uso crear reserva con elementos

Figura 4-44.: Caso de uso confirmar reserva a préstamo
Tabla 4-45.: Caso de uso descargar hoja de vida elemento

Id RQ18
Nombre Descargar hoja de vida elemento
El sistema permitirá descargar la hoja de vida de un
Descripción elemento, donde se incluyen todos los mantenimientos
realizados a ese elemento.
Precondición El usuario debe iniciar sesión y debe existir el elemento
Postcondición Se inicia la descarga de la hoja de vida
Usuario Sistema
2. Valida datos
5. Descargar la hoja de vida 6. Inicia la descarga
eventos

Tabla 4-46.: Caso de uso enviar elemento a mantenimiento

Id RQ19
Nombre Enviar elemento a mantenimiento
El sistema permitirá enviar a mantenimiento un
Descripción
elemento.
El usuario debe iniciar sesión y el elemento debe
Precondición
estar listado en disponibles
Se cambia el estado del elemento y se lista en
Postcondición
mantenimiento
Usuario Sistema
2. Valida datos
6. Alerta indicando y se
5. Enviar a mantenimiento
cambia el estado
eventos

Tabla 4-47.: Caso de uso enviar elemento a disponibles

Id RQ20
Nombre Enviar elemento a disponibles
El sistema permitirá enviar a disponibles un
Descripción
elemento, luego de salir de mantenimiento
El usuario debe iniciar sesión y el elemento debe
Precondición
estar listado en mantenimiento
Se cambia el estado del elemento y se lista en
Postcondición
disponibles
Usuario Sistema
2. Valida datos
5. Enviar a disponibles
cambia el estado
eventos

Tabla 4-48.: Caso de uso crear préstamo con elementos

Id RQ21
Nombre Crear préstamo con elementos
El sistema permitirá crear préstamos con elementos
Descripción
existentes del laboratorio
El usuario debe iniciar sesión y se debe seleccionar
Precondición
al menos un elemento
Se cambia el estado de los elementos seleccionados
Postcondición
a préstamo
Usuario Sistema
2. Valida datos
5. Crear el préstamo
cambia el estado
eventos
Excepciones
5.1 No selecciona elementos 6.2 Alerta indicando

Tabla 4-49.: Caso de uso crear reserva con elementos

Id RQ22
Nombre Crear reserva con elementos
Actor Usuario (estudiante)
El sistema permitirá crear reservas con elementos
Descripción
disponibles del laboratorio
El usuario debe iniciar sesión y se debe seleccionar
Precondición
al menos un elemento
Se cambia el estado de los elementos seleccionados
Postcondición
a préstamo
Usuario Sistema
Flujo básico
1. Ingreso con código al
eventos 2. Valida datos
sistema
3. Crear la reserva
cambia el estado
eventos
1.1 Ingresa código incorrecto 2.1 Alerta indicando
Excepciones
3.1 No selecciona elementos 4.1 Alerta indicando

Tabla 4-50.: Caso de uso confirmar reserva a préstamo

Id RQ23
Nombre Confirmar reserva a préstamo
Actor Usuario (administrador, laboratorista)
El sistema permitirá aceptar o rechazar una reserva
Descripción
realizada por algún estudiante
El usuario debe iniciar sesión y ver el listado
Precondición
de reservas
Postcondición Se cambia el estado a préstamo
Usuario Sistema
Flujo básico 1. Ingreso con código al
2. Valida datos
eventos sistema
Préstamos de préstamos
5. Aceptar o rechazar la 6. Cambia el estado y
reserva una alerta indica
Flujo alternativo
Usuario Sistema
eventos
Excepciones 1.1 Ingresa código incorrecto 2.1 Alerta indicando


Los diagramas de actividades correspondientes al módulo de gestión de equipos y elementos de los

requerimientos, mostrar elementos disponibles (ver figura 4-45), mostrar elementos mantenimiento
(ver figura 4-46), descargar hoja de vida elemento (ver figura 4-47), enviar elemento a mante-
nimiento (ver figura 4-48), enviar elemento a disponibles (ver figura 4-49), crear préstamo con
elementos (ver figura 4-50), crear reserva con elementos (ver figura 4-51) y confirmar reserva a
préstamo (ver figura 4-52).
Figura 4-45.: Diagrama de actividad mostrar elementos disponibles
Figura 4-46.: Diagrama de actividad mostrar elementos mantenimiento

Figura 4-47.: Diagrama de actividad descargar hoja de vida elemento
Figura 4-48.: Diagrama de actividad enviar elemento a mantenimiento

Figura 4-49.: Diagrama de actividad enviar elemento a disponibles

Figura 4-50.: Diagrama de actividad crear préstamo con elementos

Figura 4-51.: Diagrama de actividad crear reserva con elementos
Figura 4-52.: Diagrama de actividad confirmar reserva a préstamo

Se crearon las siguientes historias de usuario para el sprint 4 empleando el tablero Trello: mostrar
elementos disponibles, mostrar elementos mantenimiento, descargar hoja de vida elemento, enviar
elemento a mantenimiento, enviar elemento a disponibles, crear préstamo con elementos, crear
reserva con elementos y confirmar reserva a préstamo. En la figura 4-53 se muestra la actividad de
cada requerimiento desde su creación, desarrollo, verificación y su aprobación.
A continuación se muestran los casos de pruebas funcionales correspondientes al módulo de ges-

tión de equipos y elementos en las siguientes tablas: mostrar elementos disponibles 4-51, mostrar
elementos mantenimiento 4-52, descargar hoja de vida elemento 4-53, enviar elemento a manteni-
miento 4-54, enviar elemento a disponibles 4-55, crear préstamo con elementos 4-56, crear reserva
con elementos 4-57, confirmar reserva a préstamo 4-58 y sus resultados son:
Tabla 4-51.: Caso de prueba funcional (Mostrar elementos disponibles)

Número 14
Nombre caso Mostrar elementos
Usuario Usuario
de prueba disponibles
Estado de
Pasada Sprint 4
la prueba
Se debe escribir la
Esta prueba permite
validar que se muestren
se encuentra la
listados de manera Configuración
correcta los elementos de la prueba
disponibles de un
a Internet. Se debe
laboratorio
estar logueado
Flujo de Eventos
de elementos
Elementos
Seleccionar la Se listan los
2 Pasada
opción Disponibles elementos disponibles

Tabla 4-52.: Caso de prueba funcional (Mostrar elementos mantenimiento)

Número 15
Nombre caso Mostrar elementos
Usuario Usuario
de prueba mantenimiento
Estado de
Pasada Sprint 4
la prueba
Esta prueba permite Se debe escribir la
validar que se muestren dirección de donde
listados de manera se encuentra la
Configuración
Descripción correcta los elementos aplicación.
de la prueba
que se encuentran en Se debe tener conexión
mantenimiento de un a Internet. Se debe
laboratorio estar logueado
Flujo de Eventos
de elementos
Elementos
Se listan los
Seleccionar la
2 elementos en Pasada
opción Mantenimiento
mantenimiento

Tabla 4-53.: Caso de prueba funcional (Descargar hoja de vida elemento)

Número 16
Nombre caso Descargar hoja de
Usuario Usuario
de prueba vida elemento
Estado de
Pasada Sprint 4
la prueba
Se debe escribir la
se encuentra la
Esta prueba validará aplicación.
que el usuario pueda Se debe tener conexión
Configuración
Descripción ingresar y descargar la a Internet. Se debe
de la prueba
hoja de vida de un dar permiso en el
elemento navegador para
permitir la descarga.
Se debe estar
logueado.
Flujo de Eventos
de elementos
Elementos
Seleccionar el icono Iniciará la descarga
2 con la opción de la hoja de vida Pasada
Descargar hoja de vida del elemento
Excepciones
No otorgar permiso
1 No inicia la descarga Pasada
de descarga

Tabla 4-54.: Caso de prueba funcional (Enviar elemento a mantenimiento)

Número 17
Nombre caso Enviar elemento
Usuario Usuario
de prueba a mantenimiento
Estado de
Pasada Sprint 4
la prueba
Se debe escribir la
Esta prueba validará dirección de donde
que el usuario pueda Configuración se encuentra la
Descripción
enviar un elemento de la prueba aplicación.
a mantenimiento Se debe tener conexión
a Internet. Estar logueado
Flujo de Eventos
de elementos
Elementos
Seleccionar la Se listan los
2 Pasada
opción Disponibles elementos disponibles
de confirmación
Enviar a mantenimiento
4 Seleccionar Si solicitando el tipo de Pasada
mantenimiento
Seleccionar tipo de Se muestra el mensaje
5 mantenimiento y “Se cambió correctamente Pasada
seleccionar la opción Ok el estado del elemento”
Excepciones
Se cierra la ventana de
1 Seleccionar No Pasada
confirmación
Seleccionar tipo de
Se cierra la ventana
2 mantenimiento y seleccionar Pasada
de selección
la opción Cancelar

Tabla 4-55.: Caso de prueba funcional (Enviar elemento a disponibles)

Número 18
Nombre caso Enviar elemento
Usuario Usuario
de prueba a disponibles
Estado de
Pasada Sprint 4
la prueba
Esta prueba validará Se debe escribir la
que el usuario pueda dirección de donde
enviar un elemento Configuración se encuentra la
Descripción
a disponibles luego de la prueba aplicación.
de pasar por un Se debe tener conexión
mantenimiento a Internet. Estar logueado
Flujo de Eventos
de elementos
Elementos
Se listan los
2 elementos en Pasada
Mantenimiento
mantenimiento
de confirmación
Enviar a disponibles
4 Seleccionar Si “Se cambió correctamente Pasada
el estado del elemento”
Excepciones
Se cierra la ventana de
1 Seleccionar No Pasada
confirmación

Tabla 4-56.: Caso de prueba funcional (Crear préstamo con elementos)

Número 19
Nombre caso Crear préstamo
Usuario Usuario
de prueba con elementos
Estado de
Pasada Sprint 4
la prueba
Se debe escribir la
que el usuario pueda
Descripción crear un préstamo con
diferentes elementos
solicitados
Flujo de Eventos
de elementos
Elementos
Marcar cada casilla
de los elementos que Los elementos quedan
2 Pasada
se quieran agregar al marcados
préstamo
Se muestra ventana
3 con formulario de Pasada
Préstamo
préstamo
Llenar el formulario
con los respectivos Se muestra el mensaje
4 datos para generar un “Se genero el préstamo Pasada
préstamo y dar clic correctamente’
en Guardar
Excepciones
Seleccionar la opción Se cierra la ventana
1 Pasada
Cancelar de formulario
2 Dejar un campo vacı́o Pasada
Seleccionar la opción Se muestra el mensaje
3 Préstamo sin marcar “Debe seleccionar al Pasada
elementos menos un elemento”

Tabla 4-57.: Caso de prueba funcional (Crear reserva con elementos)

Número 20
Nombre caso Crear reserva
Usuario Usuario
de prueba con elementos
Estado de
Pasada Sprint 4
la prueba
Se debe escribir la
Esta prueba validará dirección de donde
que el usuario pueda Configuración se encuentra la
Descripción
crear una reserva con de la prueba aplicación.
diferentes elementos Se debe tener conexión
Flujo de Eventos
Ingresar como Se ingresa a la pantalla
1 Pasada
estudiante de elementos disponibles
Marcar cada casilla
de los elementos que Los elementos quedan
2 Pasada
se quieran agregar a la marcados
reserva
Se muestra ventana
3 con formulario de Pasada
Reserva
reserva
4 datos para generar una “Se genero la reserva Pasada
reserva y seleccionar correctamente”’
la opción Guardar
Excepciones
Seleccionar la opción Se cierra la ventana
1 Pasada
Cancelar de formulario
Seleccionar la opción Se muestra el mensaje
3 Reserva sin marcar “Debe seleccionar al Pasada
elementos menos un elemento”

Tabla 4-58.: Caso de prueba funcional (Confirmar reserva a préstamo)

Número 21
Nombre caso Confirmar reserva
Usuario Usuario
de prueba a préstamo
Estado de
Pasada Sprint 4
la prueba
Se debe escribir la
que el usuario pueda
Descripción confirmar una reserva,
pasando esta a calidad
de préstamo activo
Flujo de Eventos
En la pantalla principal Se ingresa a la pantalla
1 seleccionar la opción de reservas y se ve la Pasada
Préstamos lista de reservas
Se abre ventana con
formulario de préstamo
Confirmar reserva
3 datos para generar un “Préstamo confirmado Pasada
préstamo y seleccionar con éxito”
la opción Guardar
Excepciones
“Reserva rechazada”
Rechazar reserva

5. RESULTADOS
En el anterior capı́tulo se realizaron las pruebas correspondientes a: pruebas funcionales y de inte-

gración. En este capı́tulo se muestran los resultados al realizar las diferentes pruebas (carga y stress,
compatibilidad y aceptación) para la aplicación FIMEB INVETORY MANAGEMENT, evaluando
el rendimiento de la aplicación sometida a múltiples usuarios, simulando diferentes transacciones
realizadas en condiciones ideales con conexión a internet con una velocidad superior a 10 Mbps
y en condiciones reales con conexión a internet de la Universidad Antonio Nariño (sección 5.1);
se evaluó la compatibilidad que tiene FIMEB INVENTORY MANAGEMENT al ejecutarse en
diferentes navegadores, identificando aspectos importantes al momento de realizar el proceso de
cada funcionalidad según cada navegador (sección 5.2) y por último el resultado de las pruebas de
aceptación las que se desarrollaron por parte de los usuarios del sistema, validando cada una de las
funcionalidades de FIMEB INVETORY MANAGEMENT.
5.1. PRUEBAS DE CARGA Y STRESS
El sistema FIMEB INVETORY MANAGEMENT se encuentra alojado en los servicios de Azu-

re, donde se utilizó la herramienta JMeter (ver figura 5-1) para realizar las pruebas de carga y
stress, validando el rendimiento del software. Por medio de JMeter se evaluó el acceso de múltiples
usuarios, tiempos de respuestas de las diferentes solicitudes, porcentaje de errores de las peticiones,
valor medio de respuesta en milisegundos (ms), tiempos de respuesta por petición (ms), entre otros,
de acuerdo a las funcionalidades de la aplicación.
Los pasos realizados se presentan a continuación:
Se estableció un plan de pruebas para la aplicación FIMEB INVETORY MANAGEMENT,

tal como se ven en la figura 5-1.
5.1 PRUEBAS DE CARGA Y STRESS 101
Figura 5-1.: Parámetros de JMeter
Se asignaron los “usuarios de prueba” del sistema, los cuales se definen como “grupo de hilos”.
Para este caso se establecieron tres pruebas con valores de 100, 500 y 1000 usuarios de manera
simultánea. Se escogen estos valores para validar un número aproximado mı́nimo, medio y
máximo de usuarios que puedan usar la aplicación con un perı́odo de subida definido de 60
segundos, lo que indica que los 100, 500 o 1000 usuarios de prueba van a ingresar al sistema
en 60 segundos.
Por último, se establece que los resultados de las pruebas se van a presentar como informe
agregado, siendo una tabla que mostrará la información de los resultados obtenidos según la
cantidad de usuarios que se definieron: 100, 500 o 1000.
5.1.1. Resultados y análisis de pruebas
5.1.1.1. Condiciones ideales (Internet con velocidad superior a 10 Mbps)
Los resultados de las pruebas de carga y stress de la aplicación web FIMEB INVETORY MANAGE-
MENT en condiciones ideales se muestran en las figuras 5-2, 5-3 y 5-4, se observa el resultado de
algunas de las funcionalidades. Además se muestran valores como tiempo invertido en petición por
mili segundos (ms), la mediana (ms), el tiempo mı́nimo invertido por petición (ms), tiempo máximo
invertido por petición (ms), rendimiento que corresponde al número de peticiones procesadas por
segundo, el porcentaje de que falle la funcionalidad. y por último las columnas (Kbytes/segundo)
corresponden a la tasa de rendimientos pero en kilobytes.
102 5 RESULTADOS
Figura 5-2.: Resultado obtenido con 100 usuarios que ingresan simultáneamente al sistema en
condiciones ideales
condiciones ideales
condiciones ideales
Para las prueba con 100 usuarios (ver figura 5-2) que ingresan de manera simultanea a la aplicación
web FIMEB INVETORY MANAGEMENT, se identifica aspectos como: que el tiempo mı́ınimo de
respuesta al realizar una petición es de 218 ms (0.218 segundos), el tiempo máximo es de 531 ms
(0.531 segundos) y un tiempo promedio de 257 ms (0.257 segundos). Indicando que en el mejor
tiempo las peticiones estarán por debajo de 1 segundo y en el peor de los tiempos las peticiones
no superarán más de 1 segundo. En promedio el tiempo de respuesta de las peticiones del usuario,
5.1 PRUEBAS DE CARGA Y STRESS 103
se tardarán menos de 1 segundo, siendo valores de alto rendimiento aceptables ya que los usuarios
podrán realizar uso del aplicativo de forma ágil, sin que se presenten interrupciones o inconvenientes.
Cuando ingresan 500 usuarios (ver figura 5-3) de manera simultánea en la aplicación, se identifica
que el tiempo mı́nimo de respuesta al realizar una petición es de 216 ms (0,216 segundos), el tiem-
po máximo al realizar una petición es de 2443 ms (2.4 segundos) y el tiempo promedio es de 257
ms (0.257 segundos). Con este número de usuarios el tiempo por petición mı́nima se mantiene al
igual que el tiempo promedio, el tiempo máximo aumenta, siendo resultados de alto rendimiento
aceptables ya que estos tiempos no superan más de 2.4 segundos por petición para la cantidad de
usuarios establecidos.
Con el ingreso de 1000 usuarios (ver figura 5-4) de manera simultánea a la aplicación, el sistema
no presenta ningún problema de rendimiento. Se identifica que el tiempo mı́nimo de respuesta al
realizar una petición es de 215 ms (0.215 segundos), el tiempo máximo al realizar una petición es
de 2493 ms (2.4 segundos) y el tiempo promedio es de 260 ms (0.260 segundos). Con este número
de usuarios el tiempo por peticiones se mantiene en el mismo rango de respuesta mencionado en
las pruebas con menos número de usuarios.
De acuerdo a cada una de las pruebas realizadas se identifica que la aplicación funciona de manera
correcta y estable en condiciones ideales.
5.1.1.2. Condiciones reales (Internet Universidad Antonio Nariño)
Se ejecutaron las pruebas planteadas en la sección anterior pero en condiciones reales, ya que
la aplicación va a funcionar con el internet de la Universidad Antonio Nariño. Los resultados
de las pruebas de carga y stress de la aplicación web FIMEB INVETORY MANAGEMENT en
condiciones reales se muestran en las figuras 5-5, 5-6 y 5-7, se observa el resultado de algunas
de las funcionalidades. Además se muestran valores como tiempo invertido en petición por mili
segundos (ms), la mediana (ms), el tiempo mı́nimo invertido por petición (ms), tiempo máximo
invertido por petición (ms), rendimiento que corresponde al núumero de peticiones procesadas por
segundo, el porcentaje de que falle la funcionalidad. y por último las columnas (Kbytes/segundo)
corresponden a la tasa de rendimientos pero en kilobytes.
condiciones reales

104 5 RESULTADOS
condiciones reales
condiciones reales
Para las prueba con 100 usuarios (ver figura 5-5) que ingresan de manera simultanea a la aplicación
web FIMEB INVETORY MANAGEMENT en condiciones reales, se identifica aspectos como: que
el tiempo mı́ınimo de respuesta al realizar una petición es de 238 ms (0.238 segundos), el tiempo
máximo es de 9151 ms (9.151 segundos) y un tiempo promedio de 973 ms (0.973 segundos). Indican-
do que en el mejor tiempo las peticiones seguirán estando por debajo de 1 segundo y en el peor de
los tiempos las peticiones podrán llegar a tardar 9 segundos. En promedio el tiempo de respuesta
de las peticiones del usuario, se tardarán menos de 1 segundo, siendo valores aceptables ya que
los usuarios podrán realizar uso del aplicativo de forma ágil, sin que se presenten interrupciones o
inconvenientes.
Cuando ingresan 500 usuarios (ver figura 5-6) de manera simultánea en la aplicación web en con-
diciones reales, se identifica que el tiempo mı́nimo de respuesta al realizar una petición es de 235
ms (0,235 segundos), el tiempo máximo al realizar una petición es de 603 ms (0.603 segundos)
y el tiempo promedio es de 242 ms (0.257 segundos). Para está prueba se obtuvieron resultados
similares a los realizados con 500 usuarios en condiciones ideales, lo que significa que en condiciones
reales en todo momento la aplicación va a presentar cambios en los tiempos de respuesta.
Con el ingreso de 1000 usuarios (ver figura 5-7) de manera simultánea a la aplicación en condicio-
nes reales, el sistema no presenta ningún problema de rendimiento. Comparando con las mismas
pruebas realizadas en condiciones ideales, el tiempo mı́nimo de respuesta se mantuvo por debajo
5.2 PRUEBAS DE COMPATIBILIDAD 105
de un segundo y el tiempo máximo de respuesta aumento tres segundos nada más.
De acuerdo a cada una de las pruebas realizadas se identifica que la aplicación funciona de manera
correcta y estable en condiciones reales. Es importante aclarar que actualmente en la facultad de
FIMEB, el número de usuarios activos que hacen parte de esta entidad en la sede sur no supera
las 400 personas, lo que hace que el servidor en el cual se realizaron las pruebas mencionadas
anteriormente sea eficiente para el proceso de gestión de equipos y elementos.
5.2. PRUEBAS DE COMPATIBILIDAD

En las pruebas de compatibilidad que se realizaron para la aplicación web FIMEB INVETORY
MANAGEMENT, se ejecutaron las pruebas funcionales de cada uno de los requerimientos, en los
siguientes navegadores, con sus respectivas versiones:
Google Chrome:
• versión 73.0.3683.103
• versión 61.0.3163.113
• versión 60-0.3112.114
Mozilla Firefox:
• versión 66.0.3
Se verificaron todas las funcionalidades de la aplicación y se encontró que:
En los dos navegadores mencionados, la aplicación cumplió a plenitud el funcionamiento de los

diferentes requerimientos, en el navegador de Mozilla Firefox se pudo apreciar un desempeño
fluido y sin algunos retrasos leves que se presentan en Google Chrome poco significantes.
En cuanto a la descarga de archivos, su desempeño es por poco mejor en Google Chrome que
en Mozilla Firefox, funcionando en ambos navegadores sin ningún inconveniente.
Después de haber realizado las respectivas pruebas de compatibilidad se concluye que la aplicación
funciona en los siguientes navegadores:
Google Chrome:
• versión 73.0.3683.103
• versión 61.0.3163.113
• versión 60-0.3112.114
Mozilla Firefox:
106 5 RESULTADOS
5.3. PRUEBAS DE ACEPTACIÓN

Las pruebas de aceptación se realizaron todas por medio de un laboratorista de la Universidad
Antonio Nariño de la sede sur cumpliendo las pruebas para los tres roles existentes en la aplicación
(Administrador, laboratorista y estudiante), en donde se verificó cada uno de los requerimientos de
la aplicación. Se encontraron los siguientes aspectos en los que se recurrió a realizar ajustes:
Al crear un usuario en algunas ocasiones no se guardaba correctamente y la aplicación se

redireccionaba a la pantalla de inicio de sesión.
Al realizar cualquier acción en la aplicación se guardaba con una hora diferente a la real, ya
que se guardaban con la hora del servidor de la base de datos que tenı́a una diferencia de +5
horas.
Algunas alertas tardaban en ser visibles sin saber el estado actual de algún proceso.
Al realizar una nueva revisión por parte del usuario mencionado anteriormente, quedaron las prue-
bas de la aplicación totalmente aceptadas, como es posible observarlo en el “Acta de entrega final
de la aplicación FIMEB INVENTORY MANAGEMENT”, (ver Anexo B).
6. CONCLUSIONES Y RECOMENDACIONES
El desarrollo de la aplicación web FIMEB INVETORY MANAGEMENT para la sistematización
de la gestión de equipos y elementos pertenecientes a los laboratorios de la facultad de Ingenierı́a
mecánica, electrónica y biomédica de la Universidad Antonio Nariño, puede ser de gran apoyo e
importancia para esta facultad ya que permite mejorar los procesos internos, garantizando traza-
bilidad y seguridad en su información.
Según el desarrollo del módulo de inicio de sesión y de usuarios, se concluye que este módulo ga-
rantiza que los usuarios de la aplicación FIMEB INVETORY MANAGEMENT tengan acceso a
las funcionalidades según su rol, donde solamente los usuarios con el rol de administrador podrán
realizar las funciones de: registro de usuarios, edición de información de usuarios, creación y modi-
ficación de elementos pertenecientes a un laboratorio.
Este módulo, además, permite que se lleve a cabo la seguridad de la aplicación, para la validación y
acceso de usuarios o personal externo que quiera ingresar al aplicativo, de manera que no se pueda
ingresar a la aplicación sin estar validado previamente en el sistema ya sea ingresando mediante la
ruta (URL) de las funcionalidades o del menú principal.
Según lo anterior, se garantiza el acceso a la aplicación y cada una de las funcionalidades de acuerdo
al rol de los usuarios.
De acuerdo al desarrollo del módulo de inventarios, se garantiza que los usuarios (administrador
y laboratorista) sean los únicos con posibilidad de descargar en formato PDF y en formato Excel
el listado en elementos pertenecientes al laboratorio, evitando que otras personas tengan acceso a
está información.
La aplicación garantiza que únicamente puedan ingresar al módulo de reservas estudiantes activos
de la institución que estén previamente registrados. Evitando que cualquier otra persona pueda
acceder a la aplicación y ver el listado de elementos disponibles del laboratorio.
De acuerdo al desarrollo de los cuatro módulos y las pruebas realizadas al aplicativo, se garantiza el
funcionamiento adecuado de la aplicación FIMEB INVENTORY MANAGEMENT en condiciones
reales haciendo uso del internet de la Universidad Antonio Nariño, es importante identificar que la
aplicación web está centrada en agilizar los procesos internos de FIMEB en cuanto a la gestión de
equipos y elementos, brindar seguridad y trazabilidad en la información almacenada.
7. TRABAJO A FUTURO
Se espera implementar la aplicación no solo en los laboratorios de la sede sur de la ciudad de Bo-
gotá, con el fin de agilizar y mejorar los procesos internos en las demás sedes existentes.
Desarrollar e integrar con nuevas funcionalidades como: módulo de lockers y guardado de objetos
de estudiantes, módulo de estadı́sticas y reportes (elementos prestados, elementos más solicitados,
elementos que requieren mayor mantenimiento y fechas con mayor solicitud de elementos). Todo
esto con el fin de mejorar la aplicación web.
A. ANEXO: Glosario
Activos: son todos aquellos bienes y derechos de propiedad de la empresa o controlados por ésta
con el que la empresa puede realizar su actividad.
Equipos de laboratorio: conjunto de instrumentos y elementos pertenecientes a un laboratorio,

los cuales facilitan los procesos de aprendizaje, permitiendo llevar lo teórico a la práctica.
Hoja de vida de un equipo: es aquel documento que nos permite determinar la identificación
de un equipo o máquina. A través de este documento se identifican las caracterı́sticas del equipo
además de incluir la información del historial de los mantenimientos que se le han realizado a este
ya sean correctivos o preventivos.
Gestión: el término gestión es utilizado para referirse al conjunto de acciones, o diligencias que
permiten la realización de cualquier actividad o deseo.
Gestión de activos: es la disciplina que busca gestionar todo el ciclo de vida de los activos fı́sicos
de una organización con el fin de maximizar su valor.
Gestión de equipos: garantizar el buen funcionamiento y uso adecuado de los equipos, disposi-
tivos y elementos pertenecientes a una organización.
Página web: información electrónica, que puede ser accedida desde un navegador web.
Sistematización: ordenamiento y clasificación -bajo determinados criterios, relaciones y cate-

gorı́as- de todo tipo de datos. Por ejemplo, la creación de bases de datos.
111
B. ANEXO: ACTA DE ENTREGA FINAL DE LA

APLICACIÓN FIMEB INVENTORY
MANAGEMENT
Figura B-1.: Acta de entrega final de la aplicación FIMEB INVENTORY MANAGEMENT.

113
C. ANEXO: ACTAS DE ENTREGAS SPRINTS

APLICACIÓN FIMEB INVENTORY
MANAGEMENT
Figura C-1.: Acta de entrega Sprint 1 y 2 de la aplicación FIMEB INVENTORY MANAGE-

MENT.

C ANEXO: ACTAS DE ENTREGAS SPRINTS APLICACIÓN FIMEB INVENTORY
114 MANAGEMENT
Figura C-2.: Acta de entrega Sprint 3 de la aplicación FIMEB INVENTORY MANAGEMENT.

115
Figura C-3.: Acta de entrega Sprint 4 de la aplicación FIMEB INVENTORY MANAGEMENT.

Bibliografı́a
[ALEGRA, 2018] ALEGRA (2018). Software Contable en la Nube para Pymes en Colombia -
Alegra. https://www.alegra.com/colombia/.
[Core, 2019] Core, A. (2019). Información general sobre asp.net core.

https://docs.microsoft.com/en-us/aspnet/core/?view=aspnetcore-2.2.
[Fernández, 2018] Fernández, A. C. (2018). Gestión de inventarios. COML0210. IC Editorial.
[Ken Schwaber, 2016] Ken Schwaber, J. S. (2016). Scrum - guı́a definitiva de prácticas ágiles
esenciales de scrum.
[Kniberg et al., 2010] Kniberg, H., Skarin, M., de Mary Poppendieck, P., and Anderson, D. (2010).
Kanban y scrum–obteniendo lo mejor de ambos. C4Media Inc.
[Matthew A. Waller, 2017] Matthew A. Waller, T. L. E. (2017). Administración de inventarios.

Pearson Educacion.
[Monte, 2016] Monte, J. (2016). Implantar scrum con éxito. Barcelona: Editorial UOC.
[Muller, 2005] Muller, M. (2005). Fundamentos de administración de inventarios. Grupo Editorial

Norma.
[MySQL, 2019] MySQL (2019). Mysql. https://www.mysql.com/.
[Pressman, 2003] Pressman, R.S. Martn, R. A. L. (2003). Ingenierı́a del software: un enfoque
práctico. In McGraw-Hill.
[SAP BUSINESS ONE, 2018] SAP BUSINESS ONE, S. (2018). Software erp en la nube para
pequeñas empresas — sap business one. https://www.sap.com/latinamerica/products/business-
one.html.
[SCRUMstudy, 2016] SCRUMstudy (2016). A guide to the scrum body of knowledge (sboktmgui-
de).
[SIIGO, 2018] SIIGO (2018). Gestión de Inventario — Siigo, Software Contable y Administrativo.
https://www.siigo.com/gestion-de-inventario/.
[SMARTBIT, 2018] SMARTBIT (2018). Smartbit erp. http://www.smartbit.systems/es/erp.
[STOCK BASE, 2014] STOCK BASE, S. (2014). Software erp en la nube )) ega futura.
https://www.egafutura.com/.
Bibliografı́a 117
[Sutherland, 1996] Sutherland, J. K. S. (1996). Scrum development process.
[Taha, 2004] Taha, H. A. (2004). Investigación de operaciones. Pearson Educación.
[Zapata Cortés, 2014] Zapata Cortés, J. A. (2014). Fundamentos de la gestión de inventarios.

Centro Editorial Esumer.

Monografía Tesis

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Monografía Tesis

Cargado por

Copyright:

Formatos disponibles

Desarrollo de un sistema de gestión de

equipos e inventarios para los laboratorios de

Harold Esteban Reyes Lancheros

Universidad Antonio Nariño

Harold Esteban Reyes Lancheros

Tesis de grado presentada como requisito para optar al tı́tulo de:

Universidad Antonio Nariño

Este trabajo de grado esta dedicado a Dios, por

Harold Esteban Reyes Lancheros

Agradezco a la facultad de Ingenierı́a mecánica, electrónica y biomédica de la Universidad Antonio

Lista de tablas VIII

1. PLANTEAMIENTO DEL PROBLEMA 4

4. DESARROLLO DEL PROYECTO 21

6. CONCLUSIONES Y RECOMENDACIONES 107

7. TRABAJO A FUTURO 108

A. ANEXO: Glosario 109

B. ANEXO: ACTA DE ENTREGA FINAL DE LA APLICACIÓN FIMEB INVENTORY

C. ANEXO: ACTAS DE ENTREGAS SPRINTS APLICACIÓN FIMEB INVENTORY

2-1. Aplicación web SMARTBIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4-1. Etiqueta historia de usuario creada en Trello . . . . . . . . . . . . . . . . . . . . . . 22

4-30.Modelo relacional sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5-1. Parámetros de JMeter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

B-1. Acta de entrega final de la aplicación FIMEB INVENTORY MANAGEMENT. . . . 111

C-1. Acta de entrega Sprint 1 y 2 de la aplicación FIMEB INVENTORY MANAGEMENT.113

2-1. Aplicaciones existentes, ventajas y desventajas . . . . . . . . . . . . . . . . . . . . . 16

4-1. Plantilla Historias Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4-35.Caso de uso añadir comentario a un elemento . . . . . . . . . . . . . . . . . . . . . . 68

En los laboratorios de la facultad de Ingenierı́a Mecánica, Electrónica y Biomédica de la Universi-

La gestión de equipos e inventarios en una institución educativa conlleva al buen funcionamiento

1.1. DESCRIPCIÓN DEL PROBLEMA

Según el coordinador nacional de laboratorios de FIMEB, no se tiene control de la información

Actualmente haciendo uso de la tecnologı́a se observan numerosas aplicaciones para la administra-

1.2. FORMULACIÓN DEL PROBLEMA

Desde la ingenierı́a de sistemas se propone el desarrollo de un sistema de gestión de equipos e

Según el coordinador nacional de laboratorios de FIMEB, vieron la oportunidad de trabajar de

El desarrollo del sistema de gestión de información permite al estudiante afianzar y poner en

1.4.2. Objetivos Especı́ficos

Permitir la visualización de los equipos que se encuentran en el área de mantenimiento y los

Desarrollar un módulo que permita llevar a cabo el conteo de elementos de un inventario,

1.5. ALCANCES Y LIMITACIONES DEL PROYECTO

La aplicación web contará con los siguientes módulos administrativos:

Módulo que permitirá visualizar los equipos que se encuentren en mantenimiento.

Módulo de inicio de sesión (autenticación) en el cual podrá ingresar un usuario administrativo.

Módulo que visualizarán exclusivamente miembros activos de la facultad (estudiantes, profe-

Para el desarrollo de la aplicación web las herramientas que se utilizarán son:

Entorno de desarrollo: Asp.Net Core.

Lenguaje de desarrollo: C Sharp (C#).

Bases de datos: MySQL.

Se dispone de 4 meses para llevar a cabo el proyecto.

2.1. MARCO TEÓRICO

2.1.2. Teorı́a de Inventarios

Inventario perpetuo: es una relación directa con la cantidad de elementos existentes en el

Materias primas y componentes: es aquel que se encuentra conformado de aquellos mate-

Inventario en lı́nea: es el inventario que se hace en la lı́nea de producción, es decir, lo anterior

2.1.3. Herramientas de desarrollo

2.1.3.1. ASP.NET CORE

ASP.NET Core es un marco de trabajo de programación gratuito y de código abierto, el cual se

La metodologı́a Scrum propone tres roles:

Equipo de desarrollo: son los encargados de desarrollar el proyecto. Se encargan de la entrega

En la metodologı́a Scrum se utilizan algunas herramientas importantes:

ScrumBoard: el Scrum board es una herramienta opcional en el estándar Scrum, es la prin-

Las actividades que propone la metodologı́a Scrum son:

Sprint: es la unidad de tiempo que determina un ciclo de desarrollo con Scrum.