Documento Final - Isi - Valda 1

UNIVERSIDAD PRIVADA DEL VALLE
FACULTAD DE INFORMÁTICA Y ELECTRÓNICA

CARRERA DE INGENIERÍA DE SISTEMAS INFORMÁTICOS
SISTEMA DE INFORMACIÓN WEB APLICANDO REDES

NEURONALES RECURRENTES LSTM PARA INCREMENTAR
LA EFICIENCIA DE LA DIFUSIÓN INFORMATIVA
Caso: Departamento de Prensa de Radio Compañera
PROYECTO DE GRADO PARA OPTAR AL

TÍTULO DE LICENCIATURA EN INGENIERÍA
DE SISTEMAS INFORMÁTICOS
POSTULANTE: GUSTAVO FABRICIO VALDA DORADO

TUTOR: ING. MARCO ANTONIO AVENDAÑO AJATA
La Paz – Bolivia
2023
DEDICATORIA
A mis padres, este proyecto es una forma de responder
todo el esfuerzo que hicieron por mí y para que pueda
estudiar, espero que los llene de orgullo.
AGRADECIMIENTO
Agradecerle a Dios, a mis padres que hicieron un gran
esfuerzo para que pueda estudiar y ser un futuro
profesional, a mi hermana que me apoyo en todo momento
y a mi tutor, un excelente docente que me guío a lo largo de
la realización de este proyecto.
RESUMEN
El periodismo es considerado como el puente entre la información y la población. El
periodismo es de suma importancia para la vida de las personas, puesto que sin este la
gente desconocería de los sucesos más importantes y recientes dejando de vivir de forma
actualizada.
En el departamento de prensa de la radiodifusora boliviana Radio Compañera existe una

problemática identificada como baja eficiencia de la difusión informativa cuantificada a
partir de una fórmula matemática, para resolver esta problemática se propone un sistema
en el que se aplique tanto tecnologías web como ayuda de inteligencia artificial para
asistir a los reporteros del medio y atender a las causas del problema para de está forma
incrementar la eficiencia en la difusión de noticias.
La solución presentada en el siguiente proyecto consta de un sistema web desarrollado

en el framework de Angular, dos API Rest creadas en Node JS y Python respectivamente,
conexión con web sockets para una comunicación en tiempo real entre reporteros y jefes
de prensa, una base de datos en PostgreSQL, conexión directa con la página web de
Radio Compañera y una red neuronal recurrente LSTM desarrollada en TensorFlow y
entrenada utilizando un conjunto de datos compuesto por más de 40000 noticias
nacionales recopiladas mediante técnicas de web scraping. Todo con la finalidad de
brindar a reporteros y jefes de prensa un ambiente en el que puedan redactar, almacenar,
ordenar, publicar y revisar sus noticias atendiendo a las causas de la problemática.
Luego de la implementación del proyecto se llega a la conclusión de que se incremento

exitosamente la eficiencia de la difusión informativa en Radio Compañera, además de
haber desarrollado satisfactoriamente la solución presentada.
ABSTRACT
The journalism is considered as a bridge between the population and the information.
Journalism is extremely important for the lives of people because without it they would
not know what the most important and recent events are, ceasing to live in an updated
way.
In the press department of the Bolivian radio station Radio Compañera there is a
problem identified as low efficiency of informative diffusion quantified from a
mathematical formula, to solve this problem a system is proposed in which both web
technologies and artificial intelligence help are applied to assist the reporters of the
medium and attend to the causes of the problem to increase the efficiency in the
diffusion of news.
The solution presented in the following project consists of a web system developed in
the Angular framework, two Rest APIs created in Node JS and Python respectively,
connection with web sockets for real-time communication between reporters and press
officers, a database in PostgreSQL, direct connection to the Radio Compañera website
and an LSTM recurrent neural network developed in TensorFlow and trained using a
data set made up of more than 40,000 national news collected using web scraping
techniques. All with the purpose of providing reporters and press officers with an
environment in which they can write, store, order, publish and review their news,
considering the causes of the problem.
After the implementation of the project, it is concluded that the efficiency of information
diffusion in Radio Compañera was successfully increased, and the solution presented
was satisfactorily developed.
ÍNDICE DE CONTENIDO
CAPÍTULO I
MARCO INTRODUCTORIO
1.1. INTRODUCCIÓN .................................................................................................. 1
1.2. PLANTEAMIENTO DEL PROBLEMA ................................................................... 2
1.2.1. IDENTIFICACIÓN DEL PROBLEMA .............................................................. 2
1.2.2. FORMULACIÓN DEL PROBLEMA ................................................................ 4
1.3. JUSTIFICACIÓN .................................................................................................. 4
1.3.1. JUSTIFICACIÓN TÉCNICA............................................................................ 4
1.3.2. JUSTIFICACIÓN ECONÓMICA ..................................................................... 4
1.3.3. JUSTIFICACIÓN SOCIAL .............................................................................. 5
1.4. OBJETIVOS ......................................................................................................... 6
1.4.1. OBJETIVO GENERAL ................................................................................... 6
1.4.2. OBJETIVOS ESPECÍFICOS .......................................................................... 6
1.5. ALCANCES Y LÍMITES ........................................................................................ 6
1.5.1. ALCANCES .................................................................................................... 6
1.5.2. LÍMITES ......................................................................................................... 7
1.6. METODOLOGÍA ................................................................................................... 7
1.6.1. TIPO DE ESTUDIO ........................................................................................ 7
1.6.2. MÉTODOS ..................................................................................................... 8
1.6.3. TÉCNICAS ..................................................................................................... 8
CAPÍTULO II
MARCO CONCEPTUAL
2.1. ESTADO DEL ARTE ............................................................................................ 8
2.1.1. SITUACIÓN ACTUAL DE LA EMPRESA ....................................................... 8
2.1.2. SITUACIÓN DE LA EMPRESA CON EL SISTEMA ....................................... 8
2.1.3. MEJORA CON LA IMPLEMENTACIÓN DEL PROYECTO ............................ 9
2.2. MARCO CONCEPTUAL ........................................................................................ 9
2.2.1. EFICIENCIA ................................................................................................... 9
2.2.2. MANIFIESTO ÁGIL ...................................................................................... 10
2.2.3. DESARROLLO ÁGIL DE SOFTWARE ......................................................... 11
2.2.4. FRAMEWORK XP........................................................................................ 12
2.2.4.1. Principios del framework XP ................................................................................. 12
2.2.4.2. Valores del framework XP ..................................................................................... 13
2.2.4.3. Prácticas del framework XP .................................................................................. 13
2.2.4.4. Artefactos del framework XP................................................................................. 14
2.2.4.5. Fases del framework XP ....................................................................................... 16
2.2.4.6. Otros artefactoS .................................................................................................... 18
2.2.5. PROCESO KDD........................................................................................... 19
2.2.5.1. Fases del proceso KDD ........................................................................................ 20
2.2.6. MACHINE LEARNING ................................................................................. 22
2.2.6.1. Redes neuronales ................................................................................................. 22
2.2.6.2. Redes neuronales recurrentes.............................................................................. 24
2.2.6.3. Redes neuronales recurrentes LSTM ................................................................... 25
2.2.6.4. Diseño de una red neuronal .................................................................................. 27
2.2.6.5. Evaluación de una red neuronal ........................................................................... 29
2.2.6.6. Keras ..................................................................................................................... 30
2.2.7. BASE DE DATOS ........................................................................................ 30
2.2.7.1. Lenguaje estructurado de consultas (SQL) .......................................................... 31
2.2.7.2. Base de datos relacional o SQL ........................................................................... 32
2.2.7.3. Diagramas modelo relacional ............................................................................... 33
2.2.8. INGENIERÍA WEB ....................................................................................... 35
2.2.8.1. Internet................................................................................................................... 35
2.2.8.2. Protocolos de internet ........................................................................................... 36
2.2.8.3. URL........................................................................................................................ 37
2.2.8.4. Lenguaje hipertexto de texto (HTML) ................................................................... 38
2.2.8.5. Javascript .............................................................................................................. 38
2.2.8.6. Aplicación web....................................................................................................... 40
2.2.8.7. Framework de desarrollo web ............................................................................... 40
2.2.8.8. Servidor web.......................................................................................................... 40
2.2.8.9. Rest API................................................................................................................. 42
2.2.8.10. Web scrapping..................................................................................................... 42
2.2.8.11. Web socket .......................................................................................................... 43
2.2.8.12. Sistemas de gestión de contenido ...................................................................... 44
2.2.9. LENGUAJE UNIFICADO DE MODELADO UML .......................................... 44
2.2.9.1. Diagramas de casos de uso ................................................................................. 45
2.2.9.2. Diagrama de actividad .......................................................................................... 46
2.2.9.3. Diagramas de clase............................................................................................... 48
2.2.9.4. Diagrama de máquina de estados ........................................................................ 49
2.2.9.5. Diagrama de componentes ................................................................................... 51
2.2.10. ESTIMACIÓN DE COSTOS DEL SOFTWARE .......................................... 52
2.2.10.1. Cocomo ii............................................................................................................. 52
2.2.10.2. Estimación del esfuerzo ...................................................................................... 53
2.2.10.3. Modelo de composición de aplicación ................................................................ 53
2.2.10.4. Modelo de diseño temprano ............................................................................... 54
2.2.10.5. Modelo post-arquitectura .................................................................................... 55
2.2.11. SEGURIDAD DEL SISTEMA ..................................................................... 55
2.2.11.1. Métodos de encriptación ..................................................................................... 56
2.2.11.2. Json Web Token .................................................................................................. 56
2.2.11.3. Guardián de rutas ................................................................................................ 57
2.2.11.4. Inyecciones SQL ................................................................................................. 57
2.2.11.5. Object relational model........................................................................................ 57
2.2.11.6. Joi ........................................................................................................................ 58
2.2.12. CALIDAD DE SOFTWARE......................................................................... 58
2.2.12.1. Definición según ISO/IEC 25010 ........................................................................ 58
2.2.12.2. Pruebas de software ........................................................................................... 60
2.2.13. METODOLOGÍA DEL PROYECTO ............................................................ 62
2.2.13.1. DESCRIPCIÓN DE LA METODOLOGÍA ............................................................ 63
2.3. MARCO REFERENCIAL ...................................................................................... 65
2.4. MARCO INSTITUCIONAL.................................................................................... 71
CAPÍTULO III
INGENIERÍA DEL PROYECTO
3.1. SOLUCIÓN PRESENTADA ................................................................................. 69
3.2. PLANIFICACIÓN DEL DESARROLLO ................................................................. 69
3.3. ANÁLISIS DE LA SITUACIÓN ACTUAL .............................................................. 71
3.3.1. SITUACIÓN ACTUAL................................................................................... 71
3.3.2. SITUACIÓN ESPERADA ............................................................................. 73
3.5. PLANIFICACIÓN.................................................................................................. 74
3.6. ITERACIONES ..................................................................................................... 76
3.6.1. PRIMERA ITERACIÓN ................................................................................ 76
3.6.1.1. Selección ............................................................................................................... 77
3.6.1.2. Preprocesamiento ................................................................................................. 79
3.6.1.3. Transformación ...................................................................................................... 82
3.6.1.4. Minería de datos .................................................................................................... 83
3.6.1.5. Evaluación ............................................................................................................. 86
3.6.1.6. Conclusiones de la iteración ................................................................................. 87
3.6.2. SEGUNDA ITERACIÓN ............................................................................... 87
3.6.2.1. Diseño.................................................................................................................... 87
3.6.2.2. Codificación ........................................................................................................... 89
3.6.2.3. Pruebas ................................................................................................................. 99
3.6.2.4. Conclusiones de la iteración ................................................................................. 99
3.6.3. TERCERA ITERACIÓN................................................................................ 99
3.6.3.1. Diseño.................................................................................................................... 99
3.6.3.2. Codificación ......................................................................................................... 101
3.6.3.3. Pruebas ................................................................................................................110
3.6.3.4. Conclusiones de la iteración ................................................................................ 111
3.6.4. CUARTA ITERACIÓN ................................................................................ 111
3.6.4.1. Diseño................................................................................................................... 111
3.6.4.2. Codificación ..........................................................................................................112
3.6.4.3. Pruebas ................................................................................................................118
3.6.4.4. Conclusiones de la iteración ................................................................................118
3.6.5. QUINTA ITERACIÓN ................................................................................. 119
3.6.5.1. Diseño...................................................................................................................119
3.6.5.2. Codificación ......................................................................................................... 120
3.6.5.3. Pruebas ............................................................................................................... 136
3.6.5.4. Conclusiones de la iteración ............................................................................... 137
3.6.6. SEXTA ITERACIÓN ................................................................................... 137
3.6.6.1. Diseño.................................................................................................................. 137
3.6.6.2. Codificación ......................................................................................................... 139
3.6.6.3. Pruebas ............................................................................................................... 150
3.6.6.4. Conclusiones de la iteración ............................................................................... 151
3.7. PRUEBAS INTEGRALES .................................................................................. 151
3.7.1. PRUEBAS DE ACEPTACIÓN .................................................................... 151
3.7.2. CRITERIOS DE CALIDAD DE SOFTWARE .............................................. 152
3.7.3. DEMOSTRACIÓN DEL INCREMENTO DE LA EFICIENCIA ..................... 154
3.8. ESTIMACIÓN DE COSTOS DE SOFTWARE .................................................... 156
3.8.1. COCOMO II ............................................................................................... 156
3.8.2. COSTOS OPERATIVOS ............................................................................ 158
CONCLUSIONES ....................................................................................................... 160
RECOMENDACIONES ............................................................................................... 161
REFERENCIAS BIBLIOGRÁFICAS ........................................................................... 162
GLOSARIO DE TÉRMINOS ....................................................................................... 165
APENDICES
ANEXOS
ÍNDICE DE FIGURAS
Figura N° 2.1 Manifiesto por el desarrollo ágil de software ............................................ 11
Figura N° 2.2 Fases de XP........................................................................................... 17
Figura N° 2.3 Product backlog, release plan e sprint backlog........................................ 19
Figura N° 2.4 Pasos que componen a KDD .................................................................. 20
Figura N° 2.5 Neuronas RNN ........................................................................................ 25
Figura N° 2.6 Ejemplo de grafica de una red neuronal .................................................. 29
Figura N° 2.7 Modelo entidad relación de una base de datos. ...................................... 33
Figura N° 2.8 Tipos de relación en diagramas modelo relacional .................................. 34
Figura N° 2.9 Ejemplo de diagrama entidad relación .................................................... 35
Figura N° 2.10 Ejemplo de JSON .................................................................................. 39
Figura N° 2.11 Arquitectura REST ................................................................................ 41
Figura N° 2.12 Ejemplo de caso de uso de inicio de sesión .......................................... 46
Figura N° 2.13 Ejemplo diagrama de actividades para servir una taza de café ............. 47
Figura N° 2.14 Ejemplo diagrama de actividades separado por roles ........................... 48
Figura N° 2.15 Clase UML ............................................................................................ 49
Figura N° 2.16 Maneras de definir estados ................................................................... 50
Figura N° 2.17 Ejemplo de diagrama de máquina de estados ....................................... 51
Figura N° 2.18 Ejemplo de diagrama de paquetes ........................................................ 52
Figura N° 2.19 Modelo calidad producto ISO/IEC 25010 ............................................... 59
Figura N° 2.20 Diagrama de actividades de la metodología propuesta ......................... 62
Figura N° 2.21 Ciclo de Compromiso – Reflexión ......................................................... 67
Figura N° 2.22 Organigrama de Radio Compañera ....................................................... 72
Figura N° 3.1 Diagrama actividades para la publicación de una noticia ........................ 71
Figura N° 3.2 Diagrama actividades de publicación de noticias mejorado ..................... 73
Figura N° 3.3 Resultados de peticiones GET ................................................................ 78
Figura N° 3.4 Páginas a utilizar para recolectar datos ................................................... 78
Figura N° 3.5 Diagrama de componentes para el Web Scraping .................................. 79
Figura N° 3.6 Diagrama de actividades del sistema de web scraping ........................... 80
Figura N° 3.7 Grafica de la cantidad de noticias por categoría pre-limpieza.................. 81
Figura N° 3.8 Grafica de la distribución de noticias por categoría pre-limpieza ............. 81
Figura N° 3.9 Grafica de la cantidad de noticias luego de la limpieza ........................... 82
Figura N° 3.10 Grafica de la distribución de noticias luego de la limpieza ..................... 83
Figura N° 3.11 Diseño de la red neuronal recurrente LSTM .......................................... 85
Figura N° 3.12 Evolución del accuracy score en función a las épocas .......................... 86
Figura N° 3.13 Model loss para clasificación de texto ................................................... 87
Figura N° 3.14 Diagrama de casos de uso de manejo de noticias ................................ 90
Figura N° 3.15 Mockup de creación/edición de noticias ................................................ 91
Figura N° 3.16 Mockup de listado de noticias ............................................................... 92
Figura N° 3.17 Primera versión del modelo relacional de la base de datos ................... 93
Figura N° 3.18 Diagrama de clases primera versión ..................................................... 93
Figura N° 3.19 Pantalla de creación/modificación de noticias ....................................... 96
Figura N° 3.20 Interfaz de listado de noticias ................................................................ 96
Figura N° 3.21 Diagrama de casos de uso de manejo de archivos multimedia ........... 101
Figura N° 3.22 Mockup de crear nueva carpeta .......................................................... 102
Figura N° 3.23 Mockup de previsualización de archivos ............................................. 103
Figura N° 3.24 Mockup de la funcionalidad manejo de archivos multimedia ............... 104
Figura N° 3.25 Diagrama de componentes del manejo de archivos ............................ 105
Figura N° 3.26 Interfaz de creación/modificación de carpetas ..................................... 106
Figura N° 3.27 Interfaz de la funcionalidad manejo de archivos multimedia ................ 106
Figura N° 3.28 Pantalla de previsualización de archivos ............................................. 107
Figura N° 3.29 Pantalla de agregar medios ................................................................. 108
Figura N° 3.30 Clase ServiciosNoticias ....................................................................... 114
Figura N° 3.31 Código de la funcionalidad de publicar en Wordpress ......................... 114
Figura N° 3.32 Implementación en código de editar noticias en Wordpress ................ 115
Figura N° 3.33 Implementación en código de deshabilitar noticia ............................... 116
Figura N° 3.34 Diagrama de casos de uso de tareas en las noticias ........................... 121
Figura N° 3.35 Mockup lista de tareas ........................................................................ 122
Figura N° 3.36 Mockup de notificaciones a los reporteros ........................................... 123
Figura N° 3.37 Mockup de notificaciones a los jefes de prensa................................... 124
Figura N° 3.38 Mockup de creación de tareas ............................................................ 125
Figura N° 3.39 Mockup de lista de tareas asignadas .................................................. 126
Figura N° 3.40 Diagrama relacional de la base de datos segundo incremento ............ 127
Figura N° 3.41 Diagrama de clases segundo incremento ............................................ 128
Figura N° 3.42 Diagrama de máquina de estados para los WebSockets .................... 130
Figura N° 3.43 Implementación de los estados conexión y escuchar eventos ............. 131
Figura N° 3.44 Funciones para emitir eventos ............................................................ 132
Figura N° 3.45 Código de crear noticia ....................................................................... 132
Figura N° 3.46 Interfaz de lista de tareas .................................................................... 133
Figura N° 3.47 Interfaz de notificaciones de tareas nuevas ......................................... 134
Figura N° 3.48 Interfaz de notificaciones de publicaciones o modificaciones .............. 134
Figura N° 3.49 Interfaz de asignación de tareas.......................................................... 135
Figura N° 3.50 Interfaz de lista de tareas asignadas ................................................... 135
Figura N° 3.51 Diagrama de casos de uso de creación de cuentas ............................ 139
Figura N° 3.52 Mockup listado de cuentas .................................................................. 140
Figura N° 3.53 Mockup creación de cuenta de usuario ............................................... 141
Figura N° 3.54 Mockup login de usuario...................................................................... 142
Figura N° 3.55 Ejemplo de JWT .................................................................................. 143
Figura N° 3.56 Código de guardianes de rutas lado cliente ......................................... 144
Figura N° 3.57 Archivo de rutas de la aplicación ......................................................... 145
Figura N° 3.58 Guardian de rutas en servidor ............................................................. 146
Figura N° 3.59 Mensaje de error en el servidor por JWT invalido ................................ 146
Figura N° 3.60 Interfaz de lista de usuarios registrados .............................................. 147
Figura N° 3.61 Interfaz de creación - modificación de cuentas de usuario .................. 147
Figura N° 3.62 Interfaz de login de usuario ................................................................. 148
Figura N° 3.63 Arqutectura de la API REST en NodeJS ............................................. 154
Figura N° 3.64 Arquitectura de la API REST en Flask ................................................. 154
ÍNDICE DE CUADROS
Cuadro N° 2.1 Ejemplo de historia de usuario ............................................................... 15

Cuadro N° 2.2 Ejemplo de historia ténica ...................................................................... 16
Cuadro N° 2.3 Ejemplos de consultas SQL ................................................................... 31
Cuadro N° 2.4 Productividad para el modelo de composición de aplicación ................. 53
Cuadro N° 2.5 Ejemplo de prueba de caja negra .......................................................... 60
Cuadro N° 2.6 Ejemplo prueba de acpetación .............................................................. 61
Cuadro N° 3.1 Planeación del proyecto ........................................................................ 69
Cuadro N° 3.2 Descripción de las actividades en el diagrama. ..................................... 72
Cuadro N° 3.3 Descripción de las actividades en el diagrama ...................................... 74
Cuadro N° 3.4 Product backlog ..................................................................................... 75
Cuadro N° 3.5 Release plan.......................................................................................... 76
Cuadro N° 3.6 Historía técnica #1 ................................................................................. 77
Cuadro N° 3.7 Sprint backlog iteración 2....................................................................... 88
Cuadro N° 3.8 Hisoria de usuario #1 ............................................................................. 88
Cuadro N° 3.9 Métodos de la ruta noticias .................................................................... 94
Cuadro N° 3.10 Métodos de la ruta noticias, segunda API ............................................ 95
Cuadro N° 3.11 Prueba de caja negra #1...................................................................... 97
Cuadro N° 3.14 Pruebas de aceptación #1 ................................................................... 99
Cuadro N° 3.15 Sprint backlog iteración 3................................................................... 100
Cuadro N° 3.16 Historia de usuario #2 ........................................................................ 100
Cuadro N° 3.17 Métodos de la ruta reporteros, primera API ....................................... 105
Cuadro N° 3.18 Prueba de caja negra #4.................................................................... 108
Cuadro N° 3.21 Pruebas de aceptación #2 ................................................................. 110
Cuadro N° 3.24 Métodos de la ruta wordpress ............................................................ 113
Cuadro N° 3.35 Rutas para la creación y modificación de usuarios ............................ 142
Cuadro N° 3.36 Prueba de caja negra #10 .................................................................. 149
Cuadro N° 3.37 Prueba de caja negra #11 .................................................................. 149
Cuadro N° 3.38 Prueba de caja negra # 12 ................................................................. 150
Cuadro N° 3.40 Pruebas de aceptación de la totalidad del sistema ............................ 152
ÍNDICE DE TABLAS
Tabla N° 3.1 Constantes según el modo ..................................................................... 156
Tabla N° 3.2 Líneas de código empleadas .................................................................. 156
Tabla N° 3.3 Factor multiplicador ................................................................................ 157
CAPÍTULO I
MARCO INTRODUCTORIO
1
CAPÍTULO I
MARCO INTRODUCTORIO
1.1. INTRODUCCIÓN
La inteligencia artificial es una tecnología que en la última década se ha posicionado

como una de las ramas de las ciencias de la computación más relevantes actualmente
siendo aplicada en prácticamente todas las áreas, desde medicina hasta ingeniería
pasando por las bellas artes, la inteligencia artificial se aplica en todos lados.
En cambio, el periodismo es algo que siempre estuvo presente en nuestras vidas al ser
el puente que conecta la información con la población para que esta pueda vivir
informada.
En la actualidad, diversos países como China o Estados Unidos han ido experimentando
con maneras de aplicar inteligencia artificial en las áreas periodísticas obteniendo
resultados bastante interesantes al lograr crear máquinas con la capacidad de
automatizar en su totalidad la tarea de los periodistas de recolectar datos mediante
entrevistas para producir notas informativas. Sin embargo, todavía queda mucha
investigación que realizar para poder llegar a una etapa de periodismo digital
completamente automatizado guiado por inteligencias artificiales.
Esto nos lleva al presente proyecto que pretende desarrollar un sistema que aplique
técnicas de inteligencia de artificial para la identificación y clasificación de notas
informativas en un ámbito nacional tomando como caso de estudio el departamento de
prensa de la radiodifusora paceña Radio Compañera, teniendo como meta ayudar al
medio a incrementar su eficiencia de la difusión informativa y pueda ayudarles a
consolidarse como medio informativo.
2
1.2. PLANTEAMIENTO DEL PROBLEMA
1.2.1. IDENTIFICACIÓN DEL PROBLEMA
Dentro del departamento de prensa de Radio Compañera se identifican causas que llevan
a problemas con la eficiencia1 de la difusión informativa.
Por la parte de las herramientas, se tiene que estas son muy poco prácticas como ser
grupos de WhatsApp para tener constancia de quién creó la noticia y que los jefes de
prensa puedan revisarlas.
Dentro de su ambiente, se cuenta con un único equipo en el que se centraliza toda su

información, si dicho equipo fallara se perderían todas las notas de los reporteros,
además que es el único punto al cual los periodistas pueden acceder para subir sus
noticias a la página, puesto que son ellos mismos los encargados de publicar sus notas.
En el apartado de personas, los reporteros están en movimiento constante y con

itinerarios apretados, puesto que en su profesión el tiempo es de suma importancia.
Cualquier pérdida de tiempo puede significar perder la primicia de la nota.
Por parte de los métodos, los reporteros deben de transcribir manualmente las notas en
la computadora que se encuentra dentro del edificio de la radio para poder subirla a la
página web del medio. Finalmente, las notas se almacenan en carpetas dentro de una
única máquina, por lo que el manejo de notas informativas es deficiente.
Todo esto contribuye a que tenga baja eficiencia de difusión informativa, respaldada por
el resultado del cálculo de la siguiente fórmula que cuantifica la eficiencia:
𝑅𝑒𝑠𝑢𝑙𝑡𝑎𝑑𝑜𝑠 𝑎𝑙𝑐𝑎𝑛𝑧𝑎𝑑𝑜𝑠 𝑅𝑒𝑠𝑢𝑙𝑡𝑎𝑑𝑜𝑠 𝑝𝑟𝑒𝑣𝑖𝑠𝑡𝑜𝑠

( ∗ 𝑇𝑖𝑒𝑚𝑝𝑜 𝑒𝑚𝑝𝑙𝑒𝑎𝑑𝑜) / ( ∗ 𝑇𝑖𝑒𝑚𝑝𝑜 𝑝𝑟𝑒𝑣𝑖𝑠𝑡𝑜)
𝐶𝑜𝑠𝑡𝑒 𝑎𝑐𝑡𝑖𝑣𝑖𝑑𝑎𝑑 𝐶𝑜𝑠𝑡𝑒𝑠 𝑝𝑟𝑒𝑣𝑖𝑠𝑡𝑜𝑠
Al calcular la formula se considera que los valores por debajo de 1 indican un proceso
ineficiente. Si el valor es igual a 1, el proceso se considera eficiente y si es mayor a 1, se
considera muy eficiente.
1
“Capacidad de lograr los resultados deseados con el mínimo posible de recursos.” Consultar punto
2.2.1.
3
Se procede a realizar el cálculo de la fórmula.
Días = 30.
Tiempo = 30.
Cantidad de reporteros = 10.
Cantidad de noticias al día por reportero = 5.
Cantidad de noticias por día = cantidad de reporteros*noticias por reportero = 5 * 10 = 50.
Resultados alcanzados = días * cantidad de noticias por día = 30 * 50 = 1500.
Coste actividad = 2.5 * resultados alcanzados = 3750.
Tiempo empleado = tiempo * resultados alcanzados = 30 * 1500 = 45000.
Resultados previstos = 1875 (El valor de resultados alcanzados más un 25% de la mejora
prevista).
Costes previstos = 2812.5 (El valor de coste de actividad menos un 25% de la mejora
prevista).
Tiempo previsto = 33750 (El valor de tiempo empleado menos un 25% de la mejora
prevista.)
Remplazando los valores y calculando:
1500 1875
( ∗ 45000) / ( ∗ 33750) = 0.8
3750 2812.5
Al realizar el cálculo de la fórmula es importante reconocer que este se hace con respecto
al tiempo que le tarda a un reportero de Radio Compañera el publicar una nota informativa
siendo este el parámetro más importante de la fórmula.
Finalmente, a parte del tiempo no se tomará otro parámetro para el cálculo de la formula
puesto que es en base a este que se medirá la eficiencia de la difusión informativa.
Con estás aclaraciones, se llega obtener un valor de 0.8, este valor según indica la
fórmula demuestra que la difusión de notas informativas en el departamento de prensa
de Radio Compañera es baja.
Se expone de forma gráfica el problema mediante un diagrama causa-efecto (Ishikawa).

(Ver apéndice A).
También se hace un respaldo de la problemática mediante una entrevista realizada con

un jefe de prensa del medio. (Ver apéndice B).
4
1.2.2. FORMULACIÓN DEL PROBLEMA
¿Cómo incrementar la eficiencia de la difusión informativa en el departamento de prensa

de Radio Compañera?
1.3. JUSTIFICACIÓN
1.3.1. JUSTIFICACIÓN TÉCNICA
El departamento de prensa del medio no cuenta con ningún tipo de sistema informático,
base de datos o aplicación que asista con el manejo de notas informativas. Toda esta
información se maneja de manera manual y la organización, persistencia e integridad de
esta depende totalmente de los reporteros dueños de los reportajes.
Por parte del personal, se tiene que en el departamento de prensa de Radio Compañera
los reporteros, si bien no son expertos en el manejo de sistemas informáticos o
pertenecen al área de ingeniería en sistemas, sí conocen y hacen uso de una herramienta
CMS (Sistema de gestión de contenidos) como lo es Wordpress, para publicar sus notas
en la página web del medio, por lo que los reporteros cuentan con experiencia en el
manejo de sistemas web. Además de contar con cierto grado de conocimiento en el
manejo de aplicaciones móviles.
Puesto que dentro del departamento de prensa de Radio Compañera no se cuenta con
ningún sistema que apoye a la organización/gestión de las notas informativas y se tiene
reporteros con experiencia en el manejo de sistemas web que el departamento de prensa
del medio está interesado en adquirir una herramienta que sirva de apoyo para la gestión
de los reportajes provenientes de los reporteros, para de esa manera incrementar la
eficiencia de la difusión informativa.
1.3.2. JUSTIFICACIÓN ECONÓMICA
Durante el proceso de desarrollo del sistema no habrá costo para Radio Compañera, esto
dado que las herramientas que se emplearán para generar la aplicación web son open
source y gratuitas.
La estimación de coste de desarrollo del software se hará mediante el uso del modelo
Cocomo II, sin embargo, este será un costo asumido por el postulante.
5
El coste de la puesta en producción del sistema será asumido por Radio Compañera,
puesto que para garantizar tanto la eficiencia, la seguridad y la disponibilidad del sistema,
este deberá ser almacenado en servicios de la nube que son de pago. Sin embargo,
Radio Compañera es un medio de radio difusión que cuenta con ingresos propios y
auspicios comerciales siendo una radiodifusora en capacidad de asumir los gastos que
tendría la subida a servicios en la nube del sistema.
Con el sistema ya implementado se piensa mejorar la eficiencia de la difusión informativa

dentro del departamento de prensa del medio, para conseguir esto, es necesario mejorar
la gestión de la información que generan los reporteros, automatizando varios procesos
manuales que se desarrollan. Disminuyendo de esta forma tanto el esfuerzo que hacen
los reporteros al tratar con sus notas informativas como el tiempo que tardan en revisar,
modificar, clasificar y publicar noticias en la página web del medio.
Finalmente, al reducir los tiempos de publicación de notas informativas, se generará más

interés del público general por Radio Compañera, resultando en mayores ingresos
económicos para el medio.
1.3.3. JUSTIFICACIÓN SOCIAL
El proyecto implementará herramientas poco comunes dentro del área del periodismo,
siendo beneficio para múltiples áreas periodísticas, incluyendo medios televisivos,
intercomunicadoras, periódicos, en general medios en donde se trabaje con notas
informativas.
También se generará un impacto positivo en la sociedad al mejorar la difusión de

información, puesto que las personas tendrían acceso a la información de manera más
oportuna.
Por último, se tendrá un impacto positivo en la vida de los trabajadores del departamento
de prensa de Radio Compañera, puesto que podrán trabajar de manera más organizada,
ahorrando tiempo, esfuerzo y dinero al no tener que regresar a las oficinas del medio de
manera muy constante, además de mejorarse el seguimiento del trabajo que desarrollen.
6
1.4. OBJETIVOS
1.4.1. OBJETIVO GENERAL
Desarrollar un sistema de información web aplicando redes neuronales recurrentes LSTM

para incrementar la eficiencia de la difusión informativa en el departamento de prensa de
Radio Compañera.
1.4.2. OBJETIVOS ESPECÍFICOS
• Recopilar noticias mediante técnicas de web scraping2 para crear un conjunto de

datos con un gran volumen de información compuesto de notas informativas de
forma rápida e integra3 a partir de información existente en páginas web.
• Desarrollar una red neuronal recurrente de tipo LSTM para que una vez entrenada
pueda clasificar las notas informativas.
• Crear la base de datos partiendo del esquema relacional para almacenar y
garantizar la persistencia, integridad2, seguridad y disponibilidad4 de los datos en
el sistema.
• Desarrollar incrementos funcionales del sistema mediante iteraciones para validar
que cumplan los requisitos del cliente.
• Realizar una prueba de aceptación de la totalidad del sistema para obtener la
conformidad del cliente.
1.5. ALCANCES Y LÍMITES
1.5.1. ALCANCES
• El desarrollo de una aplicación web.

• La implementación de los roles: jefe de prensa y periodista.
• La implementación del módulo de publicación de noticias.
2
En español: raspado web. Consultar punto 2.2.9.11.
3
Los datos deben ser completos y precisos. Los datos deben mantenerse sin cambios desde el momento
en que son ingresados hasta el momento en que son solicitados.
4
Los datos deben de ser accesibles cuando se requieran donde se requieran.
7
• El desarrollo de un subsistema de procesado de lenguaje natural y clasificación de

notas informativas.
• La implementación de un módulo de notificaciones de acciones en el sistema.
• La implementación de un módulo de asignación de tareas a los reporteros.
1.5.2. LÍMITES
• Las palabras serán el único criterio para clasificar las notas informativas.
• El sistema no indicará si una noticia es apta para publicación.
• El sistema solo generará las categorías: Política, social, economía, seguridad,
deportes, internacional y ciencia.
• El sistema no hará seguimiento de una nota publicada que fue compartida en redes
sociales.
• El sistema no indicará el rendimiento de una noticia ya publicada en la página web
de Radio Compañera.
• El sistema no hará publicaciones en las redes sociales de Radio Compañera.
• La red neuronal implementada en el sistema no contará con aprendizaje continuo 5.
• El sistema no contemplará ningún tipo de reporte más haya de estadísticas básicas
de los reporteros.
1.6. METODOLOGÍA
1.6.1. TIPO DE ESTUDIO
Descriptivo, dado que “Los estudios descriptivos pretenden especificar las propiedades,
características y perfiles de personas, grupos, comunidades, procesos, objetos o
cualquier otro fenómeno que se someta a un análisis. Es decir, miden o recolectan datos
y reportan información sobre diversos conceptos, variables, aspectos, dimensiones o
componentes del fenómeno o problema a investigar.” (Hernández, Mendoza, 2018)
5
El modelo de machine learning continúa aprendiendo una vez ya terminado su entrenamiento.
8
El uso de una estrategia descriptiva resulta apropiado para el proyecto ya que permitirá
obtener información precisa sobre los procesos y variables involucradas en la difusión
informativa, lo cual será fundamental para evaluar la eficiencia del sistema y tomar
decisiones informadas en la mejora continua del departamento de prensa.
1.6.2. MÉTODOS
Los métodos de investigación a usar serán lógicos y empíricos.
Por la parte de métodos lógicos se optará por un enfoque inductivo por partir de una
observación dirigida a muchos casos particulares para analizar su comportamiento.
Además de, incluir el enfoque lógico deductivo que parte de los datos generales para
deducir suposiciones.
Por parte de los métodos empíricos se usará principalmente el método de la observación

al departamento de prensa de Radio Compañera para registrar el comportamiento del
objeto en cuestión para luego describirlo y analizarlo.
1.6.3. TÉCNICAS
Dentro de las técnicas a utilizarse se harán uso de entrevistas con los jefes de prensa en
el medio, además de recurrir a la observación para tener un mejor entendimiento sobre
cómo es la realidad del departamento de prensa de Radio Compañera.
CAPÍTULO II
MARCO CONCEPTUAL
8
CAPÍTULO II
MARCO CONCEPTUAL
2.1. ESTADO DEL ARTE
2.1.1. SITUACIÓN ACTUAL DE LA EMPRESA
Dentro del departamento de prensa de Radio Compañera no se cuenta con ningún tipo
de sistema o base de datos en donde se puedan almacenar las notas informativas de los
reporteros, todo se resguarda en una única computadora. Además, las notas se
comparten para revisión mediante grupos de WhatsApp, es así como la organización
dentro del departamento es deficiente, puesto que el seguimiento a las notas es pobre,
la recuperación de las mismas posterior a su uso es muy complejo, el proceso de revisión
mediante herramientas como WhatsApp poco conveniente, se usa una única
computadora para la publicación de notas en la página web y en general se tiene una
dependencia muy alta de una única computadora, si esta fallase se perdería una cantidad
considerable de información. Todos los puntos mencionados conllevaran a que se tenga
poca eficiencia con la difusión de noticias.
2.1.2. SITUACIÓN DE LA EMPRESA CON EL SISTEMA
Con la implementación de un sistema de información que mejoré la difusión de notas

informativas, el departamento de prensa mejoraría su organización, pudiendo llevar un
mejor control sobre las notas publicadas, su información dejaría de ser compartida por
todos y desaparecería la dependencia de un único computador, además se asegurar la
prevalencia de notas que les sean importantes junto con una forma de encontrarlas
mucho más sencilla. El proceso de revisión de notas para su publicación por parte de los
jefes de prensa se vería facilitada y mejorada con una retroalimentación mucho más
rápida sobre sus reportajes a los periodistas. Finalmente, desaparecía la necesidad de
regresar hasta la radio por parte de los reporteros para poder hacer la publicación de sus
notas, ahorrándose tanto el tiempo de regresar al edificio del medio como el de
transcripción de la nota en términos de su página web. De manera cuantitativa se
demostraría que el sistema mejorará la eficiencia de la difusión informativa mediante el
cálculo de la fórmula:
9

2.1.3. MEJORA CON LA IMPLEMENTACIÓN DEL PROYECTO
En general el departamento de prensa de Radio Compañera mejoraría su manejo de

noticias y con este, la eficiencia de la difusión de estas dentro del medio se vería
aumentada.
2.2. MARCO CONCEPTUAL
2.2.1. EFICIENCIA
En la página de la Real Academia Española se define el termino eficiencia como:

“Capacidad de lograr los resultados deseados con el mínimo posible de recursos.”
(https://dle.rae.es/eficiencia, 2022).
La importancia de la eficiencia radica en que esta busca mejorar el proceso para optimizar
resultados, por ende, si la eficiencia es baja, existen problemas con los procesos lo que
termina en resultados deficientes. La eficiencia de los procesos debe de ser una de las
metas principales para cualquier organización dado que una alta eficiencia se traduce
como productividad favorable para el negocio y esto concluye en mayores ganancias y
menos costes para la organización.
Dentro del contexto de este proyecto se trabajará con la palabra eficiencia en función al
tiempo empleado para una actividad, en este caso, la difusión de notas informativas. Por
ende, al mencionar el termino baja eficiencia haremos referencia a como los tiempos de
difusión son altos.
Una baja eficiencia con respecto al tiempo de publicación para un medio de radiodifusión
como lo es Radio Compañera puede traducirse como perdidas monetarias y de estatus
como medio noticioso lo cual resulta como un gran problema para el medio.
En el contexto de este proyecto, para medir la eficiencia se trabajará con la siguiente

fórmula:

10
La fórmula cuantifica la eficiencia dando como resultado un valor numérico, en caso de

que dicho valor sea menor a 1 indica que el proceso es ineficiente, en caso de ser igual
a 1 indicará que el proceso es eficiente y en caso de ser mayor a 1 indicará que el proceso
es muy eficiente.
Se procede a explicar cada uno de sus parámetros en base al proyecto actual.
Resultados alcanzados: Cantidad de noticias publicadas en total en un intervalo de

tiempo.
Coste actividad: El coste monetario de la actividad en total en el mismo intervalo de

tiempo, para el casto actual es difícil cuantificar con exactitud este campo así que se
recurre a estimar.
Tiempo empleado: El tiempo que consume en total toda la actividad mencionada en un

intervalo.
Resultados previstos: El valor de resultados previstos más un 25% de la mejora

considerada.
Los costes y tiempos previstos serán los parámetros ya mencionados menos un

determinado porcentaje, 25% para este caso.
2.2.2. MANIFIESTO ÁGIL
El manifiesto ágil son los principios sobre los que se basan los métodos alternativos a los
tradicionales. El manifiesto ágil nace en febrero de 2001 cuando el creador de Extreme
Programming, Kent Beck reúne a diferentes críticos de modelos de mejora de software
basados en procesos para discutir técnicas y formas de desarrollar software, en dicha
reunión aparece el término “Métodos ágiles” en referencia a los métodos alternos a los
tradicionales.
Los asistentes a dicha reunión resumen los principios sobre los que los métodos
alternativos o ágiles deben estar basados, dichos principios se pueden leer en la siguiente
figura.
11
Figura N° 2.1
Manifiesto por el desarrollo ágil de software
Fuente: Manifiesto por el Desarrollo Ágil de Software, 2022.
2.2.3. DESARROLLO ÁGIL DE SOFTWARE
Kate Brush mediante un post en la página web ComputerWeekly.com define el desarrollo

ágil de software de la siguiente manera: “El desarrollo de software ágil es un tipo de
metodología de desarrollo que anticipa la necesidad de flexibilidad y aplica un nivel de
pragmatismo a la entrega del producto terminado. El desarrollo de software ágil requiere
un cambio cultural en muchas empresas porque se centra en la entrega limpia de piezas
individuales o partes del software y no en la aplicación completa.” (Kate Brush, 2022).
A diferencia del desarrollo tradicional de software, el desarrollo ágil tiene como enfoque
la calidad del producto y consecuentemente, la satisfacción del cliente. Además de ser
una forma de afrontar un ambiente volátil, altamente cambiante.
El desarrollo ágil de software tiene sus bases cimentadas en lo que es el manifiesto ágil.
12
2.2.4. FRAMEWORK XP
En la página web extremeprogramming.org, Don Wells expone lo siguiente: “La

programación extrema tiene éxito porque hace hincapié en la satisfacción del cliente. En
lugar de entregar todo lo que podría desear en una fecha lejana en el futuro, este proceso
entrega el software que necesita cuando lo necesita.” (Don Wells, 2022).
Extreme Programming(XP) fue originalmente una metodología ágil de desarrollo de

software enfocada en la calidad del producto y satisfacción del cliente. Creada por Kent
Beck en el año 1996 como solución a los problemas que tenían los métodos tradicionales
de desarrollo de software.
En la actualidad, si bien algunas personas aún se refieren a XP como una metodología,

XP ahora es considerado un marco (framework) de desarrollo de software. En el sitio web
agilealliance.org se expresa lo siguiente: “Extreme Programming (XP) es un marco de
desarrollo de software ágil que tiene como objetivo producir software de mayor calidad y
una mayor calidad de vida para el equipo de desarrollo. XP es el más específico de los
marcos ágiles con respecto a las prácticas de ingeniería apropiadas para el desarrollo de
software.” (https://www.agilealliance.org/glossary/xp/, 2022).
Dentro de XP se cuenta con una serie de valores y principios, artefactos, prácticas y fases
que se expondrán a continuación.
2.2.4.1. Principios del framework XP
Los principios de XP comprenden 5 buenas prácticas involucrando al equipo de trabajo,

los procesos y los clientes.
• Planificación incremental. Los requerimientos se toman en historias de usuario,

dichas son negociadas progresivamente con el cliente.
• Entregas pequeñas. Primero, se desarrollará la parte más pequeña que brinde
funcionalidad al sistema, para después ir dando más funcionalidades al sistema.
• Retro alimentación rápida. Los cambios implementados deben de ser validados
lo más antes posible con los clientes.
13
• Abrazar el cambio. Es inevitable que habrá cambios en los requerimientos con el

tiempo, el equipo debe de estar dispuesto a aceptar dichos cambios y trabajar con
ellos.
• Trabajo de calidad. Todo trabajo hecho deberá ser de calidad, asegurándose de
mantener la sencillez del código, la funcionalidad y la satisfacción del cliente.
2.2.4.2. Valores del framework XP
Los valores de XP, al igual que las prácticas, son los 5 listados a continuación.
• Comunicación. Una mala comunicación impide fluir el conocimiento en un equipo.

A menudo, cuando se presenta un problema, ya habrá quien sepa resolverlo, sin
embargo, la falta de comunicación les impedirá compartir la solución o contribuir a
esta.
• Sencillez. Se deben de tomar pasos sencillos hacia el objetivo, mitigando las fallas
que ocurran. De esta forma se incrementará el valor de lo desarrollado.
• Retroalimentación. Dentro de las metodologías de desarrollo tradicionales como
el modelo en cascada (Waterfall) se tiene una retroalimentación muy vaga y muy
a menudo tardía. Sin embargo, dentro de XP, se adopta el cambio y los equipos
de XP se esfuerzan por recibir retroalimentación temprana y constante.
• Valentía. Como Ingeniero en sistemas uno tiene muchas cosas que temer, pero
de la misma manera, muchas oportunidades de mostrar coraje.
• Respeto. Una premisa fundamental de XP es que todos deben de preocuparse
por su trabajo, aun así, no existe cantidad suficiente de excelencia técnica que
salve un proyecto en caso de faltar cuidado y respeto.
2.2.4.3. Prácticas del framework XP
Kent Beck en su libro “Extreme Programing Explained: Embrace Change” (Kent Beck,
2004). Nos explica que dentro XP deberían aplicarse 12 buenas prácticas referentes tanto
a la hora de codificar como a la hora de desarrollar un proyecto. De las 12 prácticas, se
explicarán 2, diseño simple y estándares de programación.
14
• Diseño simple. El diseño simple hace referencia a que se debe mantener la

simplicidad en todo momento durante el desarrollo abarcando tanto la escritura del
código como el desarrollo de las interfaces.
• Estándares de programación. Los estándares de programación tienen como
propósito producir software con un estilo constante, estableciendo un estándar a
la hora de escribir código. Un ejemplo de estándar de programación sería a la hora
de declarar variables, los nombres deben ir con minúsculas y en estilo camello o
camel case, y para las constantes todo el nombre debe ser en mayúsculas.
2.2.4.4. Artefactos del framework XP
En un artículo publicado para una revista de la facultad de ingeniería UNIMINUTO, Oliver

Pérez expresa que en XP se trabajan con los siguientes artefactos: historias de usuario,
tarjetas de tareas para la descarga de documentos, el código, las pruebas unitarias y de
integración y las pruebas de aceptación. De dichos artefactos se generarán 2, siendo
estos las pruebas de aceptación y las historias de usuario.
Historias de usuario
En el libro: Extreme Programming Applied: Playing to Win (Ken Auer, 2002), Kent Beck
comienza a hablar sobre las historias de usuario, describiéndolas como un “antídoto a los
requerimientos” que son “algo obligatorio o de necesidad”. Las historias de usuario como
tal son una forma de describir una funcionalidad proveniente de un requerimiento del
usuario desde su perspectiva, por ende, están escritas de manera informal. Las historias
de usuario deben seguir un formato dado: “Como, quiero…, para…”. Dichas además
están escritas por lo general en tarjetas y contar con criterios de aceptación, siendo estos
una lista de cosas que deben de cumplir para validar que el requerimiento del usuario
este satisfecho.
Se puede apreciar un ejemplo de historia de usuario en la siguiente figura:

15
Cuadro N° 2.1
Ejemplo de historia de usuario
Nombre Eliminar eventos.

Descripción Como visitante de la página
Quiero leer noticias actuales en la página principal
Para que pueda estar informado sobre los acontecimientos
nacionales o internacionales más recientes.
Criterios de - Se mostrarán las 6 noticias más recientes de cada
aceptación categoría en la página principal.
- Cada noticia tendrá imagen de portada, resumen,
categoría y fecha de publicación.
- Al seleccionar la noticia se llevará a otra página con la
nota completa.
Tipo: Historia de usuario.
Prioridad: Media.
Fuente: Elaboración Propia
Historias técnicas
En los proyectos de software habrá ocasiones en donde se pidan por funcionalidades

mucho más técnicas, en cuyo caso una historia de usuario convencional puede que no
sea de mucha ayuda, para estos escenarios existen las historias técnicas. Una historia
técnica, así como una historia de usuario describe una funcionalidad, sin embargo, lo
hará de una manera mucho más técnica. En el libro Historias de usuario – Ingeniería de
Requisitos Ágil, se describe el formato de las historias técnicas como: “Las historias
técnicas se escriben directamente en texto técnico claro y preciso, sin un patrón como
ocurre con las historias de usuario. También tienen criterios de aceptación asociados que
se comprueban en la revisión de sprint por la audiencia técnica correspondiente”.
(Menzinsk, Palacio, Sobrino, & Alvarez, 2022).
En base a la descripción proporcionada, podríamos interpretar una historia técnica de la

siguiente manera:
16
Cuadro N° 2.2
Ejemplo de historia ténica
Nombre Desarrollar una REST API

Descripción Desarrollar una REST API con métodos POST y GET para la
ruta de personas.
Criterios de - La API deberá tener una ruta de personas.
aceptación - La API debe tener dos métodos, POST y GET.
- Debe de existir un middleware que valide los métodos.
- Debe de existe una conexión con una base de datos.
Tipo: Historia técnica.
Prioridad: Alta.
Fuente: Elaboración propia.
Pruebas de aceptación
Dentro del desarrollo de Software las pruebas de aceptación son una forma de validar
que se cumplan las necesidades del cliente. Dentro del contexto de XP, las mismas serán
usadas para validar que las funcionalidades desarrolladas provenientes de las historias
de usuario cumplan con las peticiones de los clientes. Consultar punto 2.2.13.2. para más
información sobre las pruebas de aceptación.
2.2.4.5. Fases del framework XP
Lo que diferencia a XP de un modelo tradicional es que mientras los modelos

tradicionales son lineales, lo que significa que para pasar de una fase a otra es necesario
haber terminado la fase anterior. Si bien esto funciona decentemente cuando los
requerimientos están bien definidos y son fijos, la realidad es que los requerimientos
varían constantemente. Para solventar este problema nacen las metodologías ágiles,
siendo XP una de estas, convirtiendo la linealidad de los modelos tradicionales en ciclos
que se repetirán hasta que se acabe el producto.
Dentro de XP se tendrán 4 principales fases mencionadas en el libro Extreme Programing

Explained: Embrace the change. (Kent Beck, 2004). Dichas fases se aprecian de mejor
manera en la siguiente figura:
17
Figura N° 2.2
Fases de XP
Fase I Planificación
Planificación o planning es la primera fase del ciclo de vida de XP, es donde los clientes
o usuarios conocerán al equipo de desarrollo para identificar los requerimientos en forma
de historias de usuario, pero estás historias de usuario son de forma más general,
haciendo uso únicamente de la estructura del como quiero para. Posteriormente las
historias de usuario se organizarán en iteraciones que cubrirán una pequeña parte de la
funcionalidad o características requeridas. Será la combinación de las iteraciones la que
dará el producto final.
Fase II Iteración
En el desarrollo ágil de software, una iteración es un periodo de tiempo fijo (generalmente

de 2 semanas, pero no más de 1 mes) en el que el equipo de desarrollo debe trabajar
para completar una cantidad de trabajo establecida. Cabe aclarar que el nombre puede
variar según con que se trabaje, por ejemplo, en el marco de trabajo Scrum se les conoce
como sprints.
Fase III Diseño
Diseño o designing es la fase en la que el equipo debe de definir que funcionalidad se

atenderá en la siguiente iteración.
Es durante esta fase que a las historias de usuario seleccionadas se les agregan los
criterios de aceptación y se les da el formato en tarjeta.
Toda iteración debe de comenzar con esta fase.

18
Fase IV Codificación
También llamada fase de desarrollo es la fase más importante del ciclo de vida de XP.
Dentro de XP se le da mayor prioridad al código por sobre las demás tareas en pro de
asegurar que el cliente reciba algo sustancial en valor al final del día.
Durante esta fase se realiza el desarrollo de software, completando las historias de

usuario una por una. Es importante destacar que tipos de pruebas como pruebas
unitarias, caja negra, caja blanca, etc. Se realizan en esta fase al finalizar cada historia
de usuario.
Fase V Pruebas
Es la última fase previa a la entrega de una funcionalidad o volver a iniciar una nueva
iteración. A diferencia de lo que el nombre indica, está fase no se encarga de ver que el
software funciona (dichas pruebas se realizan en la fase de codificación), sino que se
encarga de validar si el software desarrollado es del agrado del cliente, para conseguir
esto se hace uso de pruebas de aceptación con el cliente.
2.2.4.6. Otros artefactoS
Si bien dentro del framework XP existen una variedad de artefactos, lo cierto es que varios
están relacionados con lo que es completamente el apartado de codificación o puntos
técnicos, no tanto a la planificación u organización del proyecto como tal, por eso se
describirán artefactos propios de frameworks diferentes a XP.
Product backlog
El product backlog es un artefacto perteneciente al marco de trabajo Scrum. El sitio oficial

de este lo define como “una lista emergente y ordenada de lo que se necesita para
mejorar el producto. Es la única fuente de trabajo realizada por el Scrum Team”.
(https://www.scrum.org/resources/what-is-a-product-backlog, 2022).
El product backlog contendrá todos los requerimientos del software y pueden estár
ordenados en base al orden en que se irán atendiendo. Cada requerimiento será una
19
historia de usuario, pero esta tendrá unicamente la parte del enunciado (como, quiero
para).
Los requerimientos del product backlog pueden ser divividos en release6s dando como
resultado un release plan. Finalmente cada release también será divido en iteraciones o
sprints en donde los requerimientos serán convertidos en historias de usuario ya
completas, agregando los criterios de aceptación y el formato en fichas. Cada iteración o
sprint abarcará un número de estás. Cabe aclarar que según el resultado de está división
cada iteración o sprint tendrá su propia lista con historias de usuario que atender, a esta
lista se le denomina como sprint backlog.
En la siguiente figura se puede apreciar un product backlog y su respectiva división en

releases y iteraciones o sprints.
Figura N° 2.3
Product backlog, release plan e sprint backlog
2.2.5. PROCESO KDD
Cómo expresan varios autores en un artículo para la revista AI Magazine, KKD es un

proceso de desarrollo para ciencia de datos y machine learning compuesta por 5 pasos
o fases: Selección, preprocesamiento, transformación, minería de datos y evaluación.
6
Entrega final de un paquete de software al haber finalizado múltiples iteraciones.
20
Siendo la misma un proceso secuencial para hallar y explotar patrones dentro de grandes
volúmenes de información. La misma al ser un proceso de software recibe únicamente
entradas y da como resultado salidas.
El proceso se describe de manera gráfica en la siguiente figura.
Figura N° 2.4
Pasos que componen a KDD
Fuente: Fayyad, Piatetsky-Shapiro, & Smyth, 2005.
2.2.5.1. Fases del proceso KDD
Fase I Selección
Durante esta fase se hace la determinación de objetivos que se desean alcanzar, los
mismos deben de ser precisos y medibles. Durante esta fase también se hace la
identificación de las fuentes de datos de donde obtendremos la información.
Son dos los objetivos de esta fase, siendo el primero definir las metas u objetivos a
alcanzar, por ejemplo, se puede especificar que se desea lograr un modelo de machine
learning con la capacidad de detectar enfermedades de la piel. Como segundo objetivo
se tendrá la identificación de las fuentes de datos a usarse para generar un conjunto de
datos.
21
Fase II Preprocesamiento
Ya con las fuentes de datos identificadas, se procede a recolectar datos que serán de
utilidad para alcanzar los objetivos propuestos. Durante esta fase se generará el conjunto
de datos que posteriormente alimentará un modelo de aprendizaje.
El objetivo de la fase de preprocesamiento es obtener un archivo en algún que contenga

todos los datos obtenidos de las fuentes de información previamente establecidas.
También se pueden generar estadísticas sobre el set de datos generado.
Fase III Transformación
Con el conjunto de datos ya armado resultado de una fase previa, se procede a realizar
gráficos estadísticos para tener un mejor entendimiento del comportamiento de los datos
recolectados. También pudiéndose realizar, en caso de que sea posible, un proceso de
reducción de dimensionalidad en los datos.
El objetivo de la fase es limpiar7 todos los datos recolectados para que estos estén listos
para alimentar al modelo de machine learn seleccionado previamente.
Fase IV Minería de datos
También conocida como data mining, es durante esta fase que se seleccionará un modelo
de aprendizaje, ya sea supervisado o no supervisado, que se adapte mejor a la
problemática que se está encarando.
Con el modelo adecuado ya seleccionado, se procede a entrenar el mismo haciendo uso

del set de datos previamente trabajado.
El objetivo de la fase es seleccionar e implementar un modelo de machine learning y

entrenarlo.
7
Remover datos de poca relevancia, campos nulos, valores inválidos, etc.
22
Fase V Validación
Finalmente, se seleccionan métricas como R2-Score8 o Accuracy Score9 para cuantificar

los resultados obtenidos del proceso de minería de datos y si fueron efectivos.
El objetivo de la fase es validar si fue efectivo todo el proceso desarrollado hasta el

momento mediante la aplicación de las métricas ya mencionadas.
2.2.6. MACHINE LEARNING
Según Burkov, en el libro “El libro de Machine Learning en 100 páginas”, se señala que:
“El machine learning es un subcampo de las ciencias de la computación encargado de la
construcción de algoritmos que para poder funcionar dependen de una colección de datos
que describan algún fenómeno. Dichos datos pueden venir de la naturaleza, ser
generados por humanos o generador por otro algoritmo”. (Burkov, 2019).
Dicho de manera sencilla, el machine learning son algoritmos que permiten que las
máquinas aprendan sin ser explícitamente programadas para ello. Esto se hace mediante
la identificación de patrones en un conjunto de datos ya procesado mediante técnicas
estadísticas. De igual manera, un modelo de aprendizaje no será otra cosa más que un
algoritmo con la capacidad de identificar dichos patrones, adaptarse a la información y
realizar predicciones.
El machine learning como tal es bastante extenso y cubre muchos modelos, de entre
ellos los más destacados son las redes neuronales, un conjunto de modelos tan
importantes que caen en su propia categoría como un subconjunto del machine learning
llamados deep learning.
2.2.6.1. Redes neuronales
Como ya se había mencionado, las redes neuronales son tan importantes y variadas que
caen en su propia categoría conocida como deep learning o aprendizaje profundo.
8
Valor estadístico que indica que la efectividad de una línea de regresión.
9
Métrica que indica el rendimiento de un modelo de Machine Learning describiendo el radio de predicciones
correctas sobre las predicciones totales. Consultar punto 2.2.7.4.
23
Dentro del deep learning, una red neuronal es un modelo de machine learning con la
capacidad de aprender técnicamente cualquier cosa, al ser conocidas como
“aproximadores universales de funciones”. Sin embargo, se tiene como desventaja el
hecho de que requieren un gran volumen de información para funcionar, a diferencia de
los modelos clásicos de machine learning. Otra desventaja de las redes neuronales es
que requieren pasar por una etapa de entrenamiento para poder realizar predicciones,
dicha etapa puede llegar a tardar horas o días.
Neuronas
En una red neuronal, una neurona no es más que una función matemática que recibe una
entrada, la procesa y da una salida. Una neurona por si sola solo puede resolver
problemas muy sencillos, sin embargo, al convertir la salida de una neurona en la entrada
de otra se consigue resolver problemas cada vez más complejos.
Muy comúnmente son representadas como círculos vacíos interconectados entre sí

mediante líneas simples.
Funciones de activación
Es una función matemática que será aplicada por la neurona al input que recibe con la
finalidad de generar una salida que vaya de los rangos 0 a 1 para decidir si se activa la
siguiente neurona o no.
Existen muchas funciones de activación que son utilizadas, pero las más comunes son:
ReLu, tangente hiperbólica (tanh), softmax y sigmoide.
Entrenamiento de una red neuronal
Por este punto nos referimos a un momento en el desarrollo de un modelo de deep

learning en donde se procesa la información histórica recopilada para poder hacer
predicciones sobre esta.
Es importante aclarar que los modelos de deep learning realizan su entrenamiento en

épocas. El termino época no es más que una forma de referirse a la cantidad de veces
que el modelo deberá volver a procesar la información
24
Para poder aprender cada modelo de deep learning debe de procesar múltiples veces la
información que se le brinda, esto porque con una sola vez que el modelo procese la
información no será suficiente para poder realizar predicciones adecuadas.
No existe una manera de calcular la cantidad óptima de épocas para una red neuronal
dado que este número depende tanto en la capacidad de procesamiento del ordenador
como del tamaño de la información, su tipo y hasta el mismo diseño de la red. De todas
formas, una buena cantidad de épocas que debe de realizar la red es de 20 a 25 de
manera general.
También hay que aclarar que más épocas no equivale a mejor aprendizaje, puede existir
un momento en donde el modelo simplemente deje de aprender y solo se desperdicie
poder de cómputo.
2.2.6.2. Redes neuronales recurrentes
Ya conociendo las redes neuronales como un modelo “pseudo-universal” por su

capacidad de adaptarte a cualquier problema de machine learning, y ya conociendo sus
desventajas, aún existe un problema no mencionado, las redes neuronales tienen
amnesia, esto se refiere al hecho de que una vez procesado un dato, la red neuronal se
olvida de este para siempre, esto a la hora de tratar con secuencias supone un problema
puesto que en una secuencia el orden es importante y elementos previos al actual
influyen en su resultado. Para tratar este problema aparecen las redes neuronales
recurrentes. Un tipo de red neuronal que trabaja con momentos en el tiempo. Burkov
aclara su uso como y describe una secuencia como: “Las redes neuronales recurrentes
(RNNs) son usadas para etiquetar, clasificar o generar secuencias. Una secuencia es
una matriz, cada fila de esta es un vector de características y el orden de las filas importa”.
La manera de funcionar de una red recurrente es mediante instantes de tiempo, en cada

instante de tiempo T se procesará un dato, dato que luego de ser procesado, será enviado
como entrada a la red neuronal en un instante de tiempo T+1. Se aprecia de forma
general el funcionamiento de una neurona RNN en la siguiente figura.
25
Figura N° 2.5
Neuronas RNN
Sin embargo, las RNN convencionales traen consigo otro problema, si bien estas
implementan de cierta forma una memoria, es una memoria de corto plazo por lo que, al
tratar con secuencias largas, la red pierde efectividad.
2.2.6.3. Redes neuronales recurrentes LSTM
Ya se explicó de forma básica el funcionamiento de una RNN y sobre todo su aplicación

en el tratamiento de secuencias, ahora se expondrá un tipo de red recurrente más común
y útil para trata estos problemas. Las redes neuronales recurrentes LSTM (Long-Short
Term Memory) como su nombre indica, implementan una memoria a largo plazo, memoria
que recordará las características esenciales de datos previos ya procesados en el
instante de tiempo T-n, siendo n un número mucho más grande.
Una red neuronal recurrente LSTM puede estar compuesta por múltiples capas, cada
capa desempeñando una funcionalidad de procesado de la información. Entre las más
comunes se tienen las capas de embeddings, dropout, LSTM, flattening, y capas dense.
Se procede a explicar el funcionamiento y significado de cada capa. Es necesario aclarar
que todas estas no son únicas de una red neuronal de tipo LSTM, pueden ser utilizadas
en otros modelos de aprendizaje profundo.
26
Capa de embedding
La capa de embedding conocida en español como capa de incrustación, es una capa de

una red neuronal encargada de convertir objetos (palabras, audio, vídeo, etc.) en vectores
de números reales de igual tamaño.
Para ser más concisos, se podría poner de ejemplo que a una capa de embedding se le
da como entrada la siguiente oración: “Hola Mundo”, está capa procesaría el texto
recibido y daría como resultado tres vectores (un vector por cada palabra de la oración
incluyendo el espacio en blanco) compuestos por números en rango 0 a 1, cabe señalar
que estos vectores deberán tener el mismo tamaño además de ser únicos, por único
entendiendo que una palabra se traduce en un único vector, dos palabras diferentes no
pueden dar el mismo resultado.
Capa de dropout
Una capa de dropout o por su significado en español: capa de abandono es una capa de
una red neuronal que se encarga de seleccionar aleatoriamente elementos del input que
serán descartados, provocando de esta forma que las neuronas de la siguiente capa no
se activen. Si bien al inicio se menciona que el proceso de descarte es aleatorio lo cierto
es que a medida que se lleve a cabo el entrenamiento, la red neuronal irá seleccionando
los valores a ser descartados mediante procesos estadísticos. Únicamente las primeras
ejecuciones de la capa serán aleatorias.
Las capas de dropout se emplean con la idea de prevenir que algunas neuronas
desarrollen dependencia hacía otra neurona, de esta forma generando overfitting10.
Capa LSTM
Una capa LSTM o por sus siglas Long Short-Term Memory (memoria a corto-largo plazo
en español), es una capa de una red neuronal encargada de memorizar secuencias, esta
capa está compuesta por una única neurona LSTM que memoriza la entrada recibida y
10
En español: sobre ajuste. Problema que pueden desarrollar los modelos de aprendizaje en donde sólo
aprenden a predecir valores específicos en lugar de valores generales.
27
la utiliza para calcular un nuevo resultado a futuro. El tamaño de esta se define en

instantes de tiempo que memorizará.
Capa de flattening
En español: capa de aplanamiento, se encarga de recibir un input en una dimensión

superior y llevarlo a una sola dimensión.
Por citar un ejemplo, si se recibe una matriz que es una estructura en dos dimensiones,
una capa de flattening se encargará de convertirla en un array o vector unidimensional.
Capa dense
También conocidas como capas ocultas o por su traducción, capas densas. Son capas
de una red neuronal compuestas por neuronas tradicionales en donde cada neurona
recibe un único input.
A veces también son llamadas capas totalmente conectadas puesto que todas sus
neuronas se conectan con todas las neuronas de la capa siguiente.
2.2.6.4. Diseño de una red neuronal
Para diseñar una red neuronal no existe una guía que se pueda seguir al píe de letra,
esto debido a que el mismo diseño de la red depende del objetivo que desea cumplir y la
complejidad de este, sin embargo, en el sitio web Interactive Chaos, se definen los 5
siguientes pasos (InteractiveChaos, diciembre 2022):
• Cuántas neuronas debe de tener la capa de entrada.

• Cuántas neuronas debe de tener la capa de salida.
• Cuántas capas ocultas deberemos incluir.
• Cuántas neuronas debe de tener cada capa oculta.
• Qué función de activación deberemos usar en cada capa.
Sin embargo, el sitio web también específica que estos pasos son efectivos para
arquitecturas sencillas, pero para modelos más complejos se deben de tomar más
decisiones, para ello, la autora Lavanya Shukla, en una publicación para el sitio web:
towardsdatascience.com, nos da dos pasos extra que podríamos resumir en:
28
• Definir el número de épocas que utilizaremos para entrenar.

• Especificar cuántas capas de dropout se utilizarán en caso de que se usen.
Tomando como base los pasos de los autores, podríamos generalizar el diseño de una
red neuronal en 7 pasos:
• Definir la cantidad de neuronas para la capa de entrada.

• Definir la cantidad de neuronas que tendrá la capa de salida.
• Definir la cantidad de capas ocultas que se tendrá.
• Definir la cantidad de neuronas que habrá por capa oculta.
• Definir la función de activación de cada capa.
• Definir por cuántas épocas entrenará la red neuronal.
• Definir la cantidad de capas de dropout que se utilizará.
Se hará uso de estos pasos para definir el diseño de la red neuronal. Hay que aclarar
también que, por motivos de orden, al definir cada punto de ser necesario se explicará
capa por capa tal que así:
• Las capas ocultas tendrán como cantidad de neuronas:

- La primera capa dense tendrá 128 neuronas
- La segunda capa dense tendrá 52 neuronas
Para representar gráficamente el modelo, se hará uso de la librería keras. Esta librería
nos proporciona métodos y clases de alto nivel para el diseño de redes neuronales una
de las cuales nos permite ver de manera gráfica la red diseñada, pero este diseño tiende
a contener mucha cantidad de información técnica por cada capa, por ende, se opta por
un diseño mucho más sencillo basado en el diseño original que proporciona la librería,
en este diseño sólo se especifica de forma secuencial el nombre de capa, la cantidad de
neuronas o tamaño de esta y su función de activación.
En la siguiente figura se puede observar un ejemplo de cómo se grafica una red neuronal
utilizando esta propuesta.
29
Figura N° 2.6
Ejemplo de grafica de una red neuronal
2.2.6.5. Evaluación de una red neuronal
Para evaluar una red neuronal se recurren a diversas técnicas estadísticas que
cuantifican el desempeño de la red. Existen muchas métricas de evaluación, pero son 2
las más comunes y confiables para evaluar una red neuronal: accuracy score y model
loss.
Antes de explicar ambas métricas es importante resultar dos puntos. Primero, ambas son,
por decirlo de algún modo, métricas inversas, por ende, se espera que mientras uno
aumente el otro decremente. Segundo, en cada época del entrenamiento se calculan
estos valores y se hace el cálculo sobre dos conjuntos de datos, los datos de
entrenamiento (datos utilizados para entrenar) y los datos de validación (información
nueva para el modelo).
En ambos casos importa más el resultado que da sobre los datos de validación.
30
Accuracy score
En español, porcentaje de precisión. Es una métrica de evaluación de redes neuronales

que consiste en evaluar cuan precisos son los resultados del modelo. Se calcula mediante
la siguiente formula:
𝑃𝑟𝑒𝑑𝑖𝑐𝑐𝑖𝑜𝑛𝑒𝑠 𝑐𝑜𝑟𝑟𝑒𝑐𝑡𝑎𝑠
( ) ∗ 100
𝑃𝑟𝑒𝑑𝑖𝑐𝑐𝑖𝑜𝑛𝑒𝑠 𝑡𝑜𝑡𝑎𝑙𝑒𝑠
El resultado que da es un valor de 0 a 100 que indica el porcentaje de precisión de las

predicciones de la red neuronal.
Como referencia todo valor por debajo del 60% es considerado deficiente y todo valor por
encima del 70% se considera excelente. Sin embargo, los valores muy altos, cercanos o
iguales al 100% podrían indicar un caso de overfitting.
Model loss
Podría traducirse como perdida del modelo. Es un valor que incrementa con cada
predicción fallida y por lo tanto indica cuan pésimo es el desempeño de una red. Si un
modelo es perfecto y nunca se equivoca, entonces el valor de pérdida o loss será de 0,
caso contrario irá incrementando.
Por lo general se considera que los valores de loss por debajo de 1 son buenos, sin
embargo, el rango óptimo está por debajo de 0.5 y cualquier valor por encima de 1.2
indican un desempeño muy pobre por parte de la red.
2.2.6.6. Keras
Keras es una librería que proporciona una interfaz de código sencilla para el lenguaje de
Python, fácil de entender para crear redes neuronales capa por capa incluyendo redes
recurrentes.
2.2.7. BASE DE DATOS
En la página de Internet maestros del web, Damián Pérez Valdés nos describe una base
de datos como: “un ‘almacén’ que nos permite guardar grandes cantidades de
31
información de forma organizada para que luego podamos encontrar y utilizar fácilmente.”
(Damián Pérez Valdés, 2007).
Las bases de datos son un apartado fundamental para el desarrollo de sistemas

informáticas, dado que es en una base de datos donde se almacenará de forma
persistente toda la información que generé el sistema. Como tal las bases de datos
actuales deben de cumplir con los principios ACID (Atomicidad Consistencia Aislamiento
Durabilidad). Para garantizar que la calidad y seguridad de los datos que residen en ellas
a medida que avance el tiempo.
2.2.7.1. Lenguaje estructurado de consultas (SQL)
El SQL es un lenguaje que es usado en su totalidad por las bases de datos de tipo
relacional. SQL como tal no es un lenguaje de programación, es una herramienta que se
usa para manipular datos en las bases de datos.
Dentro de SQL existe el DML (Lenguaje de Manipulación de Datos) dicho nos permite,
cómo su nombre indica, manipular la información que reside en una o más tablas de la
base de datos. Son 4 las operaciones que lo conforman: Selección, inserción, eliminación
y modificación.
También se tiene el DDL (Lenguaje de Definición de Datos) el mismo más que manipular
la información dentro de las tablas de la base de datos, manipula la estructura que tienen
las tablas. Las operaciones que abarca son 3: Crear (Create), Modificar (Alter), Eliminar
(Drop).
Se muestra un par de ejemplos de consultas SQL y su significado en la siguiente tabla:
Cuadro N° 2.3
Ejemplos de consultas SQL
Consulta Significado
SELECT * FROM personas; Obtiene todas las columnas y filas de una
tabla denominada personas.
32
SELECT * FROM personas WHERE Obtendrá todos los campos de la tabla

nombre = ‘Miguel’; personas donde la columna nombre tenga
el valor de Miguel.
CREATE TABLE personas(nombre Crea una tabla con nombre personas con
VARCHAR(50)); una única columna nombre, dicha
columna solo aceptará datos de tipo texto
con un largo máximo de 50 caracteres.
2.2.7.2. Base de datos relacional o SQL
Una base de datos relacional se caracteriza por tener su información estructurada en

tablas que a su vez están compuestas por filas y columnas, además de hacer uso del
lenguaje estructurado de consultas SQL para definir los datos, su estructura y poder
realizar operaciones de selección.
Otro punto importante de las bases de datos relacionales son las mismas relaciones, la
información se almacena en tablas y estás tablas podrán relacionarse con otras tablas
mediante un concepto conocido como llaves primarias y llaves foráneas. Una llave
primaría es un campo único que sirve como identificador de la tabla y actúa como
representante de esa misma tabla cuando se produce una relación. Al pasar de su tabla
de origen a otra mediante una relación, la llave primaría pasa a ser conocida como llave
foránea.
Una forma popular de representar una base de datos relacional es mediante

modelos/diagramas entidad relación. El redactor de un artículo en la página de Internet,
Maestros del Web, Damián Pérez Valdés las describe como: “herramientas para el
modelado de datos de un sistema de información. Estos modelos expresan entidades
relevantes para un sistema de información, sus inter-relaciones y propiedades”. (Valdés,
2007)
En la siguiente figura se puede apreciar un ejemplo de modelo entidad relación.

33
Figura N° 2.7
Modelo entidad relación de una base de datos.
Fuente: http://www.maestrosdelweb.com/que-son-las-bases-de-datos/, 2022.
2.2.7.3. Diagramas modelo relacional
Es un tipo de diagrama que ilustra como las entidades (tablas en la base de datos) se
relacionan entre sí.
Este diagrama sigue una estructura muy parecida a la que manejan los diagramas de
clase en UML a las entidades tener un diseño muy parecido a las clases, sin embargo,
se tiene la diferencia que en las entidades solo se lista los campos que contiene junto
con su tipo de dato y si este es o una clave primaria o clave foránea.
En este tipo de diagrama no existen las mismas relaciones que existen en otros tipos de
diagramas, por ende, no existen relaciones como la herencia. Las tablas se relacionan
mediante líneas simples, de todos modos, existe un detalle crucial, el símbolo en el
extremo de las relaciones indica el tipo de relación que existe entre las entidades.
En la siguiente figura se ilustra los tipos de relación que existen y como se representan.
34
Figura N° 2.8
Tipos de relación en diagramas modelo relacional
Brevemente explicado, la relación uno a uno se denota con una línea simple y representa
que una relación posee un único elemento de otra relación. Por citar un ejemplo: Una
persona puede tener una única información de contacto.
La relación uno a muchos indica que un elemento de una relación puede tener múltiples
elementos de otra relación. Por ejemplo: Un equipo puede tener múltiples personas que
lo conforman.
Finalmente, la relación muchos a muchos, es la menos común e indica que múltiples

elementos de una relación pueden tener múltiples elementos de otra. Cabe resaltar que
cuando se da este caso, la relación debe de romperse creando una tabla extra que tendrá
dos relaciones uno a muchos. Por ejemplo: un equipo puede tener múltiples torneos.
En la siguiente figura se puede apreciar un ejemplo de diagrama modelo relacional

aplicando los tipos de relación que existen.
35
Figura N° 2.9
Ejemplo de diagrama entidad relación
2.2.8. INGENIERÍA WEB
Dentro del apartado de ingeniería web se explicará todo lo relacionado con la parte web
del proyecto, incluyendo herramientas de desarrollo web.
2.2.8.1. Internet
El Internet es un conjunto de redes de computadoras/comunicaciones interconectadas

de forma global para compartir información mediante. Para lograr esto, las redes de
computadoras emplean denominados protocolos de red.
Internet como tal ofrecen varios servicios de comunicación, como servicios de mensajería
o correo electrónico basado en el protocolo SMTP. Pero uno de los servicios más
importantes y consumidos de Internet es la World Wide Web.
36
World Wide Web
La World Wide Web, WWW o simplemente web es un conjunto de protocolos (destacando

HTTP) que permiten consultar de manera remotas archivos de hipertexto. Es responsable
de que seamos capaces de visualizar páginas web provenientes de diferentes orígenes.
2.2.8.2. Protocolos de internet
El sitio web de Kionet Works define un protocolo, en el contexto de redes como:

“estándares y políticas formales, conformados por restricciones, procedimientos y
formatos que definen el intercambio de paquetes de información para lograr la
comunicación entre dos servidores o más dispositivos a través de una red”
(kionetworks.com/blog/data-center/protocolos-de-comunicació-de-redes, septiembre
2022).
Dentro de Internet existen multiples protocolos para lograr una comunicación y los
mismos varian en base al tipo de servicio del que se hable. Entonces, en la Worl Wide
Web también existirán una variedad de protocolos dentro de los cuales el más destacado
es el protocolo HTTP.
Protocolo HTTP
El protocolo de transferencia de hipertexto o HTTP por sus siglas, es el protocolo que

permite la transferencia de de información de archivos de hipertexto.
El sitio web MDN Web Docs se puede encontrar la siguiente definición: “HTTP es un
protocolo de la capa de aplicación para la transmisión de documentos hipermedia, como
HTML”. (developer.mozilla.org/es/docs/Web/HTTP, septiembre 2022).
Métodos de petición HTTP
HTTP también implementa diferentes métodos para indicar una acción sobre un recursos,
dicha acción puede ser obtener, subir, modificar o eliminar un documento en un receptor,
dichos serán denominados métodos de petición o HTTP verbs. Se hace un listado de los
métodos más comunes:
• GET: Solicita un recurso específico, recupera datos.

37
• POST: Envia un recurso en especifíco.

• PUT: Reemplaza todas las representaciones actuales del recurso con la
información enviada.
• DELETE: Borra un recurso en especifíco.
Códigos de estado de respuesta HTTP
Cuando se realiza una petición mediante uno de los métodos de HTTP a un receptor, el
mismo deberá mandar una respuesta al emisiario con un código indicando el estado de
su petición. Los códigos van del 100 al 599 y son agrupados de 100 en 100 de la siguiente
manera:
• Respuestas informátivas (100-199)

• Respuestas satisfactorias (200-299)
• Redirecciones (300-399)
• Errores de los clientes(400-499)
• Errores de los servidores(500-599)
Dentro de estos códigos existen algunos que destacan por lo comunes que son, como
ser el código 200 que indica una petición exitosa o el código 404 que indica cuando un
archivo solicitado por el cliente no pudo ser encontrado por el servidor.
2.2.8.3. URL
Las URL o por sus siglas Universal Resource Locator es una cadena de texto que como
su nombre indica, sirve para acceder a un recurso en Internet. Las URL especifican de
forma exacta el nombre del recurso al que se quiere acceder junto con su dirección exacta
y el formato del archivo.
Las URL están compuestas por el protocolo, nombre de dominio, dirección del archivo,
nombre y formato del archivo. Un ejemplo podría ser la siguiente URL:
http://www.example.com/paginas/manzana.png
Como se puede observar, la url empieza por el protocolo, muy por lo general será http o
su variante con cifrado https, luego de dos puntos y dos barras se específica el nombre
38
del dominio, este puede corresponder a cualquier sitio dentro del Internet, seguido se
tiene el archivo y su dirección, separadas por barras, para este caso se puede observar
que el archivo es una imagen y se encuentra en la carpeta páginas.
2.2.8.4. Lenguaje hipertexto de texto (HTML)
En la página web de desarrolladores de Mozilla se define HTML como: “el componente

más básico de la Web. Define el significado y la estructura del contenido web.”
(developer.mozilla.org/es/docs/Web/HTML, septiembre 2022).
Para definir el contenido de un archivo de hipertexto, HTML trabaja con etiquetas o tags
dichos serán interpretados por un navegdor web y mostraran el contenido. Ejemplos de
estás etiquetas son: <body>, <head>, <p>.
2.2.8.5. Javascript
Ya se conoce lo que es el HTML, una forma de definir la estructura del contenido Web
que luego será mostrado por un navegador web, pero el problema del HTML “puro” es
que solo sirve para generar contenido estático o contenido que nunca cambiará, por ende,
solo sirve para crear páginas web estáticas. Para arreglar esto HTML suele ser
combinado con CSS11 para agregar estilo al contenido y JavaScript para lograr que dicho
contenido pase a ser dinámico.
JavaScript es un lenguaje de programación que se puede aplicar a un documento HTML

para agregar características de interacción dinámica en un sitio web, convirtiéndolas en
aplicaciones web. JavaScript es actualmente el lenguaje de programación estándar
utilizado en sitios web y prácticamente el único lenguaje de programación que HTML usa,
puesto que cualquier otra herramienta en otro lenguaje al final termina convirtiendo todo
en JavaScript.
11
Lenguaje de diseño gráfico para definir y crear la presentación de un documento, muy por lo general, en
HTML.
39
JSON
Un JSON es un formato de texto utilizado para el intercambio de datos. JSON es el

acrónimo para JavaScript Object Notation (Notación de objetos en JavaScript). Recibe
este nombre puesto que el formato que adopta la información dentro del archivo sigue la
misma notación que se usa en JavaScript para crear objetos.
Los JSON son estructuras clave-valor, esto significa que para acceder a un dato es
necesario conocer bajo que clave se encuentra. Las claves son solo una manera de
acceder ubicar los datos, algo así como sus coordenadas, no tiene nada que ver son
seguridad de la información.
En un JSON las claves deben de tener siempre un valor literal definido entre comillas
dobles, en cambio, los valores pueden ser tanto literales, como numéricos u otro tipo de
dato más complejo como ser números decimales, listas de elementos o incluso pueden
ser otros objetos.
Cuando dentro de un JSON existen múltiples JSON se le denomina JSON anidado.
Se observa un ejemplo de un archivo JSON en la siguiente figura.
Figura N° 2.10
Ejemplo de JSON

40
2.2.8.6. Aplicación web
Como se explicó en el punto anterior, una aplicación web será una página web estándar
con características de interacción dinámicas, dicho de otra forma, una página web que le
ofrece al usuario la capacidad de interactuar con sus componentes, cambiando el estado
de estos o alterando la estructura del sitio web a petición del usuario. Hoy en día dentro
de la web la mayoría de los sitios serán aplicaciones web, puesto que ya casi no se usan
las páginas web estáticas.
2.2.8.7. Framework de desarrollo web
Dentro del mundo de la creación de aplicaciones web, se han desarrollado distintas

herramientas para facilitar el trabajo y dentro de las más destacadas se encuentran los
frameworks web siendo estos instrumentos creados con la finalidad de facilitar la creación
de apps web al aportar funcionalidades ya hechas o librerías 12 para facilitar el desarrollo.
Angular
Angular es un framework de desarrollo web desarrollado y mantenido por Google. El

mismo debe su popularidad a la gran cantidad de funcionalidades que aporta y su
concepto de componentes, siendo estos “pequeñas aplicaciones” que pueden ser
reutilizadas en distintas partes de una aplicación más grandes.
Actualmente Angular es uno de los web frameworks más utilizados y bastos que existe.
2.2.8.8. Servidor web
Hasta el momento se ha hablado de la web y el protocolo HTTP para comunicación y las

páginas web, ya sean dinámicas o estáticas, para el usuario (también conocido como
frontend), pero un componente esencial es el concepto de servidor web o también
conocido como backend. Para verlo de cierta forma podemos imaginar una conversación
de teléfono con una operadora, nosotros (usuario) mediante el teléfono (frontend) nos
comunicamos (Internet y sus protocolos) con una operadora (backend), esta operadora
12
Archivos de código en un lenguaje de programación que aportan funcionalidades comunes ya
implementadas.
41
recibirá nuestras peticiones, como que nos diga el número de teléfono de una persona,
consultará con su base de datos y nos dará una respuesta ya sea afirmativa o negativa
mediante el mismo medio por el cual le llego nuestra petición inicial.
En el contexto de la web el proceso es un poco más completo y complejo, pero la metáfora

sirve para entender el rol del servidor o backend en las aplicaciones web, recibir
peticiones provenientes del frontend, procesarlas y regresar una respuesta, está manera
de trabajar también es conocida como arquitectura REST. En la siguiente figura se puede
apreciar de manera más completa la arquitectura.
Figura N° 2.11
Arquitectura REST
Node JS
Node JS es una herramienta diseñada para poder hacer uso de JavaScript en el backend
permitiendo crear un servidor web meramente basado en esta tecnología, implementando
todas las funcionalidades básicas como recibir y responder peticiones, además de
realizar consultas con la base de datos.
Flask
Flask o Python Flask es un framework para desarrollar aplicaciones web en el lenguaje

de programación de Python. Flask también puede ser utilizado para crear un servidor web
completamente basado en Python.
42
2.2.8.9. Rest API
En el sitio web de Red Hat podemos encontrar la siguiente definición de Rest API: “Una
API de REST, o API de RESTful, es una interfaz de programación de aplicaciones (API o
API web) que se ajusta a los límites de la arquitectura REST y permite la interacción con
los servicios web de RESTful.” (redhat.com/es/topics/api/what-is-a-rest-api, 2020).
Cuando hablamos de diseño de aplicaciones web en la actualidad hay que considerar

que la aplicación en su totalidad ya no es una sola ni trabaja en una sola máquina, dicho
de otra forma: la aplicación ya no es un monolito, más bien, son varias aplicaciones, que
se ejecutan sobre diferente hardware haciendo uso de diferente software, que
combiandas forman la aplicación web. Pero como fue mencionado, la totalidad de nuestra
app ahora será compuesta por aplicaciones más pequeñas, entonces bajo ese enfoque,
una API es como el pegamento que será utilizado para unir estás pequeñas partes.
De manera más ténica, una API permitirá que dos aplicaciones que no necesariamente
están creadas bajo las mismas características puedan compartir información. Finalmente
si lo hacen aplicando la arquitectura petición-respuesta REST, tendremos una Rest API.
2.2.8.10. Web scrapping
A veces traducido de forma literal como “raspado web” o ”cosecha web”, el web scraping
es definido por el autor Broucke en el libro “Practical Web Sxraping for Data Science”
como: “la construcción de un agente para descargar, analizar y organizar datos
provenientes de la web de manera automatizada” (Seppe Vanden Broucke, 2018). En
otras palabras, el web scraping es una manera de obtener de forma automática
información que reside en páginas web, esto mediante herramientas disponibles en
algunos lenguajes de programación y el protocolo HTTP.
Para realizar web scraping, primeramente, se parte de obtener la dirección del sitio del
que se desea obtener información. Seguidamente, la herramienta con la que se aplicará
la técnica realizará una petición HTTP al sitio. En caso de que la petición sea exitosa
(código 200), se puede proceder con los demás pasos. Caso contrario, no se podrá
realizar web scraping.
43
Si la petición fue exitosa, la herramienta de web scraping procederá a obtener todo el

código HTML de la página y almacenarlo en memoria. Ya con el código HTML de la
página recuperado, se puede realizar un análisis de este, este paso varía según la
herramienta que se use, puesto que habrá herramientas que faciliten mucho el proceso
y otras que no ofrezcan mucha ayuda para analizar el código obtenido.
Finalmente, se puede filtrar toda la información de la página web que sea de relevancia
para la investigación, generando de esta forma un conjunto de datos de gran volumen
proveniente de un sitio en la web de manera automática y eficaz.
2.2.8.11. Web socket
Dentro de la web existen diferentes formas de comunicación entre elementos que se

encuentran en diferentes ubicaciones, la forma de comunicación entre estos puede variar,
pero por lo general consiste en: enviar mensaje, recibir repuesta, fin de la comunicación.
Visto de otra manera, no existe comunicación de manera continua entre los elementos,
cada que se quiera volver a mandar un mensaje, se tendrá que volver a abrir un canal de
comunicación que durará en lo que dura la petición y la respuesta.
Esta manera de comunicación no es un problema como tal, pero en caso de que exista
una constante e impredecible interacción entre emisor y receptor podría ser problemática.
Para tratar con estos escenarios, se implementan los Web Sockets.
Un Web Socket es una tecnología que proporcionará una comunicación de manera

continua y bidireccional13 entre dos elementos, generando de esta manera un canal que
solo se abrirá una vez y durará todo lo que dura la comunicación.
Este tipo de tecnología puede ser implementar en cualquier arquitectura que trabaje con
un cliente y un servidor además de ser óptima para apps de mensajería o sistemas de
notificaciones en tiempo real.
13
Tanto el emisor como el receptor en la comunicación pueden mandar mensajes.
44
2.2.8.12. Sistemas de gestión de contenido
Un sistema de gestión de contenidos, CMS (Content Manager System) es una

herramienta que permite crear páginas web estáticas a partir de plantillas prediseñadas
para que personas sin conocimientos de programación web puedan manejar sitios.
Muy por lo general los CMS son utilizados para crear blogs o páginas de noticias.
Como ejemplos de CMS tenemos: Wordpress, Joomla o Drupal.
Wordpress
Wordpress es actualmente uno de los CMS más conocidos y utilizados a nivel mundial
para crear páginas web. Definido en su página web como: “Un software de código abierto
que puedes usar para crear fantásticas webs, blogs o aplicaciones.” (Wordpress, 2022).
Este CMS es tan popular que autoproclama que el 43% de las páginas en línea lo utilizan.
Wordpress, al ser de código abierte propone múltiples alternativas para ser controlado
desde agentes externos mediante el uso del protocolo HTTP, a esta característica se le
llama Wordpress Xmlrpc.php. Para poder manejar Wordpress remotamente existe la
librería en el lenguaje de programación de Python denominada wordpress-xmlrpc.
2.2.9. LENGUAJE UNIFICADO DE MODELADO UML
Como su nombre indica, el UML en un lenguaje de modelado de sistemas de software,

lo más importante de este lenguaje es el hecho de ser unificado, significando esto que
debe ser universalmente entendido por cualquier persona con conocimiento del
funcionamiento del lenguaje además de ser independiente del lenguaje de programación
que haya sido utilizado para desarrollar el software a ser modelado. También cabe aclarar
que UML no es exclusivo del desarrollo de software, otras áreas también pueden
emplearlo.
El enfoque principal de UML es el modelado, término que es definido en el libro escrito

por Joyanes y Zahonero programación en C, C++, Java y UML como: “un medio de
capturar ideas, relaciones, decisiones y requerimientos en una notación bien definida que
se puede aplicar a muchos dominios diferentes”. (Aguilar & Zahonero Martínez, 2014).
45
En UML existen variedad de diagramas, cada uno con distintas funcionalidades, por citar
algunos se tiene: diagramas de clase, casos de uso, diagramas de procesos, diagramas
de máquinas de estados y diagramas de paquetes.
2.2.9.1. Diagramas de casos de uso
Es un diagrama de comportamiento de UML.
Sirve para especificar secuencias de acciones, incluyendo variantes, que el sistema

puede ejecutar y que produce un resultado observable para un actor en concreto.
En su notación se tendrá 4 elementos principales:
• El actor: Usuario del sistema ya sea lógico (otro software) o físico (una persona)
que interactúa con el sistema. Es denotado mediante una figura de palo con el
nombre del actor.
• El caso de uso: El proceso que se desarrolla, por citar un ejemplo puede ser: iniciar
sesión. Son denotados como un ovalo con el nombre del caso de uso dentro.
• Asociación de comunicación: Indica que un actor puede ejecutar un caso de uso.
También puede indicar que un caso de uso puede utilizar otro caso de uso. Se
denota como una línea recta.
• Asociación de inclusión: Indica que un caso de uso requiere de otro caso de uso
para ser ejecutado. Se denota como una línea punteada con el termino <include>
escrito encima.
• Asociación de generalización: Indica que un caso de uso es una versión más
general de otro. Se denota como una flecha.
• Asociación de extensión: Indica que un caso de uso puede bloquear la ejecución
de otro caso de uso. Se denota como una línea punteada con el termino <extends>
escrito encima.
• Límite del sistema: Encierra todos los casos de uso indicando que pertenecen a
un sistema. Se denotan como un rectángulo con el nombre del sistema escrito en
la parte superior.
En la siguiente figura se puede observar un ejemplo del caso de uso de inicio de sesión.
46
Figura N° 2.12
Ejemplo de caso de uso de inicio de sesión
2.2.9.2. Diagrama de actividad
Es un diagrama de comportamiento UML.
Sirve para describir el comportamiento interno de una actividad u operación mediante un

flujo de actividades secuenciales.
Dentro de un diagrama de actividades existen 6 elementos principales que aparecerán

en el diagrama siendo estos:
• Nodo de inicio: Denotado por un círculo negro. Indica donde iniciará el flujo de la
actividad.
• Proceso u actividad: Denotado por un rectángulo blanco con un texto en el centro.
Indica la ejecución de la acción descrita en su texto.
47
• Nodo de decisión: Denotado por un rombo. Indica que el flujo tiene dos posibles
caminos, según se cumpla o no la condición el flujo podrá seguir uno u otro camino.
• Concurrencia: Denotado por dos rectángulos negros horizontales o verticales.
Indica que todas las secuencias de actividades dentro de los rectángulos pueden
ser llevadas a cabo al mismo tiempo.
• Terminador: Denotado por un círculo negro más pequeño con una circunferencia
negra un poco más grane que el círculo. Indica el fin del flujo y el fin del diagrama.
Cada elemento descrito se debe de interconectar mediante una flecha que indica el flujo.
En la siguiente figura se observa un ejemplo de este tipo de diagrama para la actividad

de servir una taza de café.
Figura N° 2.13
Ejemplo diagrama de actividades para servir una taza de café
Otra forma de representar este diagrama es separando las actividades según roles como
se observa en la siguiente figura.
48
Figura N° 2.14
Ejemplo diagrama de actividades separado por roles
2.2.9.3. Diagramas de clase
Es un diagrama de estructura UML.
El diagrama describe la estructura de un sistema a partir de las clases, sus atributos y

métodos, además de exponer la relación que existe entre ellas.
El componente principal o más importante en este tipo de diagramas es la clase. Una

clase es una forma de abstraer/representar un ente de la vida real descomponiéndolo en:
qué cosas tiene (atributos) y qué cosas hace (métodos).
En este diagrama una clase se representa como un rectángulo divido en 3 segmentos, el

primero contendrá el título de la clase, el segundo los atributos de la clase y el tercero los
49
métodos de la clase. Sin embargo, tanto los atributos como los métodos pueden ser
obviados.
Finamente al principio de cada atributo o método se puede incluir un signo que indica si
este es público (+) o privado (-). También al final de estos, después de dos puntos, se
puede incluir el tipo de dato del atributo o el tipo de dato que regresa el método si es que
retorna algo.
En la siguiente figura se puede apreciar de qué manera se representa en UML una clase.
Figura N° 2.15
Clase UML
Dentro de un diagrama de clase también pueden existir relaciones entre clases, estás
relaciones son representadas mediante una línea recta que conecta ambas clases e
indican que una clase está relacionada de alguna manera con otra.
2.2.9.4. Diagrama de máquina de estados
Es un diagrama de comportamiento UML.
Sirve para describir el comportamiento de un caso de uso, una clase o un sistema

completo en caso de que estos posean estados o características que se asemejen a una
máquina de estados finitos.
Una máquina de estados finitos es un dispositivo que cuenta con diversos estados que
son activados mediante un activador o disparador que hará que la máquina cambie de
estado. Por poner un ejemplo, una lampara es un aparato con 2 estados, encendido y
apagado, y existe un interruptor que al ser accionado hará que la lámpara cambie de un
estado a otro.
50
Dentro de los diagramas de máquinas de estados existe notación muy semejante a la

existente en los diagramas de actividades, de igual manera, su funcionalidad es
semejante. Los elementos que se repiten son: el nodo de inicio, el nodo de decisión, la
concurrencia y el terminador.
Sin embargo, el elemento más importante dentro de una máquina de estados es el mismo
estado, este puede ser escrito de dos formas, la primera es parecida al proceso es un
diagrama de actividades, un rectángulo con el nombre del estado dentro. La segunda
forma, en cambio, se compone por el nombre del estado que se escribe en la parte
superior del rectángulo y en el centro de este puede ir escrito: “Entry/”, “Do/”, “Exit/”, estas
palabras denotan acciones adicionales que el estado puede ejecutar. Entry/ indica que
se ejecutará una acción cuando se ingresa al estado. Do/ es lo que ejecutará el estado
de forma regular, si solo quiere especificar que hará en Do/ se puede omitir y solo poner
el nombre del estado ocupando todo el rectángulo. Exit/ indica que acción se ejecutará al
cambiar de estado. Al definir un estado no es necesario incluir todas las acciones
adicionales, algunas o todas pueden ser omitidas.
En la siguiente figura se observa de manera gráfica ambas formas de definir un estado.
Figura N° 2.16
Maneras de definir estados
La forma en la que se vaya a definir un estado dependerá de cuan específico el estado

deba ser o si este realizará acciones adicionales.
51
Finalmente, los gatilladores para cambiar de estados se escriben en las mismas flechas
que conectan los estados e incluso un gatillador puede llevar directamente al final del
diagrama.
En la siguiente figura se observa un ejemplo de diagrama de máquina de estados sencillo

para una lámpara.
Figura N° 2.17
Ejemplo de diagrama de máquina de estados
2.2.9.5. Diagrama de componentes
Es un diagrama de estructura UML.
Representa la visión general del sistema, documentando como este se organiza y los
componentes que lo componen además de señalar las dependencias y relaciones que
existen entre estos.
Dentro de un diagrama de componentes existen tres elementos principales.
• El componente, representado como rectángulo con 2 rectángulos paralelos en el

costado izquierdo. Indica un componente del sistema, este puede ser un
subsistema, un módulo o una interfaz de programación.
• Interfaz provista, representada como una línea recta con un círculo en una de las
puntas. Indica que un elemento provee funcionalidad para que otro pueda utilizarla.
52
• Interfaz requerida, presentada como una línea recta con una semi circunferencia
en la punta. Indica que un elemento requiere de otro para funcionar.
Las relaciones entre elementos pueden ser mediante interfaces conectando los extremos
de las interfaces requeridas con las interfaces provistas.
En la siguiente figura se muestra un ejemplo de un diagrama de componentes.
Figura N° 2.18
Ejemplo de diagrama de paquetes
2.2.10. ESTIMACIÓN DE COSTOS DEL SOFTWARE
2.2.10.1. Cocomo ii
Dentro de lo que es la planificación de proyectos, una de las tareas más importantes es

la estimación. Por estimación se entiende: determinar con cierto grado de certeza el
costo, tiempo y esfuerzo necesario para el desarrollo de componentes ya sean de
hardware como software.
En un trabajo, la autora Adriana Gómez describe que COCOMO II está compuesto por 3
modelos denominados como:
• Composición de Aplicación.
• Diseño Temprano.
• Post-Arquitectura.
Dichos modelos se aparecen para poder realizar la estimación de esfuerzo necesario

para completar un proyecto de software.
53
2.2.10.2. Estimación del esfuerzo
El esfuerzo necesario en un proyecto de software, sin importar el modelo que se

empleará, se expresa en una medida denominada meses/persona o PM. Dicha métrica
representa cuantos meses de trabajo (trabajando a tiempo completo) se requieren para
concretar el desarrollo de un proyecto de software.
2.2.10.3. Modelo de composición de aplicación
En este modelo se propone la siguiente fórmula:
𝑃𝑀 = 𝑁𝑂𝑃 / 𝑃𝑅𝑂𝐷
En donde:
NOP (Nuevos Puntos Objeto): Tamaño del nuevo software a desarrollar expresado en
Puntos Objeto. Se calcula mediante la siguiente fórmula.
𝑁𝑂𝑃 = 𝑂𝑃 ⋅ (100 − %𝑟𝑒𝑢𝑠𝑜)/100
OP (Puntos Objeto): Es el tamaño del software a desarrollar expresado en Puntos Objeto.
%reuso Porcentaje de reúso que se espera lograr en el proyecto.
PROD: Representa la productividad promedio. Esta se determina mediante un análisis

de datos de proyecto, para eso se apoya en la siguiente tabla.
Cuadro N° 2.4
Productividad para el modelo de composición de aplicación
Fuente: COCOMO Un modelo de estimación de proyecto de software, 2022.

54
2.2.10.4. Modelo de diseño temprano
Es durante las etapas tempranas de un proyecto de software que se hace uso de este
modelo, cuando se conoce muy poco sobre el tamaño del producto a ser desarrollador,
de la naturaleza de la plataforma, del personal que desarrollará u otros detalles
específicos.
El modelo de Diseño Temprano ajusta el esfuerzo nominal haciendo uso de siete factores
de costo. La fórmula para el cálculo del esfuerzo es la siguiente:
𝑃𝑀𝑒𝑠𝑡𝑖𝑚𝑎𝑑𝑜 = 𝑃𝑀𝑛𝑜𝑚𝑖𝑛𝑎𝑙 ⋅ ∏ 𝐸𝑀𝑖

𝑖=1
𝑃𝑀𝑛𝑜𝑚𝑖𝑛𝑎𝑙 = 𝐴 ⋅ (𝐾𝑆𝐿𝑂𝐶 )𝐵
𝐵 = 1.01 + 0.01 ⋅ ∑ 𝑊𝑗
𝑗=1
Donde:
PMestimado: Esfuerzo nominal ajustado por 7 factores, factores que reflejan otros aspectos
propios del proyecto que afectan al esfuerzo necesario para la ejecución de este.
KSLOC: Tamaño del software a desarrollar expresado en miles de líneas de código

fuente.
A: Constante que captura los efectos lineales sobre el esfuerzo de acuerdo con la
variación del tamaño. Toma un valor de 2.94.
B: Es el factor exponencial es escala, toma en cuenta las características relacionadas

con las economías y deseconomías de escala producidas cuando un proyecto de
software incrementa su tamañao.
EMi: Son los factores de costo que tienen un efecto multiplicativo sobre el esfuerzo,
llamados Multiplicadores de Esfuerzo. Cada factor se puede clasificar en 6 niveles
diferentes que expresan el impacto del multiplicador sobre el esfuerzo de desarrollo. Esta
escala varia desde un nivel Extra-Bajo hasta un nivel Extra Alto. Cada nivel tiene un peso
55
asociado. El peso promedio o nominal es 1.0. Si el factor provoca un efecto nocivo en el

esfuerzo de un proyecto, el valor del multiplicador correspondiente será mayor que 1.0,
caso contrario el multiplicador será inferior a 1.0.
2.2.10.5. Modelo post-arquitectura
Es el modelo de estimación más detallado y se aplica cuando la arquitectura del proyecto

está completamente definida. Este modelo se aplica durante el desarrollo y
mantenimiento de productos de software incluidos en las áreas de Sistemas Integrados,
Infraestructura y Generadores de Aplicaciones.
El esfuerzo nominal se ajustó usando 17 factores multiplicadores de esfuerzo. El mayor

número de multiplicadores permite analizar con más exactitud el conocimiento disponible
en las últimas etapas de desarrollo, ajustando el modelo de tal forma que refleje
finalmente el producto de software bajo desarrollo. La fórmula para el cálculo del esfuerzo
es la siguiente:
17
𝑃𝑀𝑒𝑠𝑡𝑖𝑚𝑎𝑑𝑜 = 𝑃𝑀𝑛𝑜𝑚𝑖𝑛𝑎𝑙 ⋅ ∏ 𝐸𝑀𝑖

𝑖=1
2.2.11. SEGURIDAD DEL SISTEMA
La seguridad de un sistema consta de diferentes formas técnicas para asegurar que la

información que el mismo contiene no sea divulgada, alterada o destruida. Dentro de
seguridad de software existe un concepto conocido como triada de seguridad, está
responde a 3 atributos vitales en seguridad de la información. Dichos atributos son:
• Confidencialidad: La información solo debe ser accedida por personal autorizado.

• Integridad: La información se debe mantenerse sin alteraciones o dicho de otra
forma: desde el momento en que se ingresa la información esta no debe verse
alterada de manera no autorizada hasta el momento en que vuelta a ser requerida.
• Disponibilidad: La información está disponible cuando se necesita como se
necesita.
56
2.2.11.1. Métodos de encriptación
Los métodos de encriptación son usados para proteger información sensible, no

necesariamente en sistemas informáticos. Cuando se encripta información se altera la
misma de manera que sea inentendible tanto para personas como para computadoras,
sin embargo, este proceso de transformación debe poder ser reversible o desencriptado.
Cuando se habla de algoritmos de encriptación existe el concepto de llaves, esto hace

referencia a un dato adicional para poder realizar el proceso de desencriptado.
Existen dos tipos de métodos de encriptación: simétricos y asimétricos. Los simétricos

hacen uso de una única llave para encriptar y desencriptar la información. Los asimétricos
en cambios usan una llave para encriptar y otra llave diferente para desencriptar.
RSA de llave pública
RSA es un algoritmo de cifrado asimétrico, por ende, cuenta con 2 llaves diferentes, una
llave pública (a la que todos tienen acceso) y es utilizada para generar un certificado
digital y una llave privada (llave a los que solo el personal autorizado debe tener acceso)
y utilizada para validar los certificados generados.
2.2.11.2. Json Web Token
En su sitio oficial, los Json Web Token (JWT) son descritos como: “Un estándar abierto
(RFC 7519) que define una forma compacta y autónoma de transmitir información de
forma segura entre las partes como un objeto JSON.” (JWT, 2022). Además de
especificar que los JWT hace uso de RSA para encriptar la información y validarla.
Dentro del contexto del desarrollo web, los JWT son utilizados para realizar certificados
digitales que serán brindados a usuarios del sistema al momento de iniciar sesión en el
mismo. Estos certificados digitales serán enviados al servidor cada que se intente
acceder a una ruta de una API o el sistema del lado del cliente, el servidor validará el
certificado y si es válido, mandará una respuesta positiva permitiendo el acceso, caso
contrario, se le negará el acceso.
57
2.2.11.3. Guardián de rutas
Un guardián de rutas es una funcionalidad que permite o deniega acceso a ciertas rutas
de un sistema en base a una condición. Los guardianes de rutas se combinan con los
Json Web Tokens para que en cada acceso a una nueva ruta se valide el certificado que
tiene el usuario, si la validación falla, se le niega el acceso a la ruta.
2.2.11.4. Inyecciones SQL
Una inyección SQL consiste en ingresar código SQL malicioso en un sistema mediante
cualquier de sus inputs. Este código SQL ingresado será una consulta con varias posibles
finalidades, puede usarse para pedir a la base de datos que muestre toda la información
con la que cuenta, ingresar nuevos usuarios para acceder al sistema sin permiso o incluso
eliminar información.
Los sistemas más vulnerables a este tipo de ataques son los sistemas que realizan sus
consultas SQL simplemente concatenando14 los parámetros15 enviados por el usuario a
una consulta a la base de datos.
2.2.11.5. Object relational model
Por sus siglas, ORM, es una técnica de programación que permite transformación la
información que existe en una base de datos relacional en un conjunto de objetos de un
lenguaje de programación. Hacer uso de un ORM es extremadamente beneficial para los
programadores puesto que permite dejar depender de consultas SQL para acceder a la
información en la base de datos remplazándolas por objetos, se muestra un ejemplo:
Consulta SQL:
SELECT * FROM personas;
Equivalente con un ORM:
print(Personas.getPersonas());
14
Acción de combinar dos o más cadenas de texto.
15
Información que se le puede proporcionar a cualquier función.
58
Los ORM además de ser tan prácticos al reducir las consultas SQL también protegen
un sistema de cualquier tipo de inyección SQL al dejar de hacer uso de consultas
tradicionales.
Existen distintos ORM para cada lenguaje de programación, entre los más populares
tenemos el EntityFramework de Microsoft para el lenguaje de programación C#, otro
ejemplo es la librería Sequelize para NodeJS.
2.2.11.6. Joi
En NodeJs Joi es una librería de validación de modelos. Cuando realizamos peticiones a

una API desarrollada en Node, muy a menudo es necesario enviar información en forma
de objetos JSON, Joi nos permite validar dichos objetos que nos llegan mediante la
definición de esquemas, muy por lo general los esquemas serán exactamente iguales a
los de la base de datos. Realizar está técnica de validación en las APIs es
extremadamente útil desde un punto de vista de seguridad puesto que sirve para validar
que la información que se envié siga un modelo definido, negando el acceso a cualquier
otro tipo de dato, dificultando el intentar acceder al sistema a posibles atacantes.
En caso de que el objeto recibido no cumpla con la validación de Joi este le devolverá al
solicitante (aquel que mando el objeto) un mensaje de error indicando que fallo la petición
y la comunicación terminará.
2.2.12. CALIDAD DE SOFTWARE
2.2.12.1. Definición según ISO/IEC 25010
En el sitio web de la ISO 25000 se define la calidad de un producto software como “el
grado en que dicho producto satisface los requisitos de sus usuarios aportando de esta
manera un valor”. (ISO/IEC 25010, diciembre 2022).
La ISO/IEC 25010 define un modelo de calidad de producto compuesto por ocho

características, en la siguiente figura recuperada del sitio web de la norma expone estás
ocho características.
59
Figura N° 2.19
Modelo calidad producto ISO/IEC 25010
Fuente: ISO/IEC 25010, 2022.
Dentro de las ocho características, se seleccionan dos: mantenibilidad y seguridad, y de

las 2 seleccionadas se explicarán las 2 subcategorías, no repudio y modularidad.
No repudio
Definido en la página web de la ISO/IEC 25010 como: “La capacidad de demostrar las
acciones o eventos que han tenido lugar, de manera que dichas acciones o eventos no
puedan ser repudiados posteriormente.” (ISO/IEC 25010, diciembre 2022)
El no repudio es la capacidad de demostrar la participación de las partes, mediante su

identificación en una comuicación o al realizar cierta acción.
Una forma de garantizar el no repudio es mediante la implementación de mecanismos de

autenticación e identificación.
Modularidad
Definido en la página web de la ISO/IEC 25010 como: “Capacidad de un sistema o

programa de ordenador (compuesto de componentes discretos) que permite que un
cambio en un componente tenga un impacto mínimo en los demás.” (ISO/IEC 25010,
diciembre 2022)
Existen multiples formas de conseguir que un sistema sea modular, la primera es el

trabajo mediante componentes independientes, esto es algo que framworks como
Angular permiten hacer de manera sencilla, y la segunda forma es mediante una
60
arquitectura de software que consista en romper los servicios de la aplicación en servicios

más pequeños independientes unos de otros.
2.2.12.2. Pruebas de software
Las pruebas de software son una parte importante del ciclo de vida del desarrollo de
software. Es mediante pruebas que uno puede asegurar el funcionamiento del sistema,
su rendimiento y también comprobar la satisfacción del usuario.
Existen muchos tipos de pruebas de software, cada uno destinado a comprobar algún
aspecto de un sistema creado. Existen por un lado las pruebas de caja negra y pruebas
unitarias destinadas a comprobar el correcto funcionamiento de un componente, modulo
o trozo de código y por otro lado, existen pruebas de aceptación para validad si lo
desarrollado satisface los requerimientos del usuario.
Pruebas de caja negra
También conocidas como: Blackbox testing muy común mente utilizada para probar una
funcionalidad sin tomar en cuenta su estructura interna, de ahí el nombre caja negra. Las
pruebas de caja negra, junto con las pruebas unitarias son el tipo de pruebas de software
más común que existe puesto que es a través de estas que se puede identificar múltiples
errores en un sistema.
La estructura de una prueba de caja negra básica puede ser observada en el siguiente
ejemplo.
Cuadro N° 2.5
Ejemplo de prueba de caja negra
PRUEBA-01 Iniciar sesión.

Propósito Comprobar que el módulo de inicio de
sesión valide si las credenciales son
incorrectas.
Prerrequisitos Debe de existir un usuario registrado.
Pasos 1. Completar el campo de nombre de
usuario.
61
2. Completar el campo de contraseña

con un valor incorrecto.
3. Seleccionar el botón de ingresar.
Resultado esperado Mensaje de error.
Resultado obtenido El sistema brinda acceso al usuario.
Resultado de la prueba Incorrecto.
Pruebas de aceptación
Son el último tipo de pruebas que debería llevarse a cabo previo al lanzamiento de un
incremento del sistema o el sistema completo (depende la metodología de trabajo). Estas
se encargan de validar si lo desarrollado cumple con los requerimientos y/o necesidades
del cliente.
El desarrollo de una prueba de caja de aceptación es bastante sencillo, bastando con

tener una tabla con tres columnas, una para la funcionalidad desarrollada, otra para el
estado de la prueba (aprobada, reprobada) y otra columna que indique si existen
observaciones. De ser necesario se puede incluir una columna extra indicando el
momento en el que se desarrolló dicha funcionalidad (una iteración, por ejemplo), esto
en caso de que se trate de una prueba de aceptación integral que valide en su totalidad
todo el sistema.
En la siguiente tabla se muestra un ejemplo de prueba de aceptación.
Cuadro N° 2.6
Ejemplo prueba de acpetación
Funcionalidad Estado de la prueba Observaciones

Inicio de sesión. Aprobada. Ninguna.
Módulo de reportes. Reprobada. Los reportes no son claros.
62
2.2.13. METODOLOGÍA DEL PROYECTO
Para el presente proyecto se hará uso de una metodología basada en el framework XP

combinando el proceso KDD descrita en la siguiente figura.
Figura N° 2.20
Diagrama de actividades de la metodología propuesta

63
2.2.13.1. DESCRIPCIÓN DE LA METODOLOGÍA
Se procede a describir la metodología a partir de la figura previamente vista.
Planificación
La fase de planificación o planning será la primera fase de la metodología. Tiene como

objetivo realizar la identificación de los requerimientos y la construcción de un product
backlog y a partir del mismo organizar las historias de usuario en iteraciones generando
un release plan. Cabe aclarar que este product backlog contendrá únicamente la
descripción de la historia de usuario (cómo, quiero, para). Los criterios de aceptación (la
historia toma su formato en ficha) serán agregados al inicio de la iteración.
Como tareas tiene el siguiente listado.
• Identificar las historias de usuario.

• Crear un product backlog.
• Elaborar el release plan.
Los entregables que está fase generarán son los siguientes.
• Product backlog.
• Release plan.
Iteración
Luego de la fase de planificación, se inician las iteraciones, cada iteración repetirá las
mismas fases hasta la finalización del proyecto.
Para la primera iteración, se atenderá exclusivamente el proceso KDD y sus 5 fases.
• Selección. (Se seguirá la fase tal como lo expone el proceso, pero se hará el
agregado de una historia técnica al inicio de la fase para ayudar a definir mejor los
objetivos).
• Preprocesamiento.
• Transformación.
• Minería de datos.
• Evaluación.
64
Para la descripción detallada de cada fase del proceso, referirse al punto 2.2.6, proceso
KDD.
Para el resto de las iteraciones, se seguirán las fases de: diseño, codificación y pruebas.
Diseño
Es la fase con la que iniciarán todas las iteraciones. Tiene como objetivo realizar la
planificación de la iteración.
• Generar las historias de usuario en formato de fichas con criterios de aceptación.

• Descomposición en tareas de cada historia de usuario.
Los entregables que está fase generarán son los siguientes:
• Historias de usuario.
• Sprint backlog.
• Descomposición en tareas de cada historia.
Codificación
Es una fase completamente dedicada al desarrollo de cada historia de usuario descrita

en el sprint backlog. Su objetivo es atender todas las tareas identificadas en la fase previa.
No se hace el listado de tareas de la fase puesto que varía según la fase anterior.
Entre los entregables que está fase podría generar en base a las tareas, están los
siguientes:
• Mockups.
• Diagramas UML.
• Pruebas de software (pruebas de caja negra, unitarias, etc.).
• Documentación de servicios de una API.
65
Pruebas
Es la última fase de cada iteración. Está fase tiene como objetivo validar lo desarrollado
en la iteración con el cliente.
• Realizar pruebas de aceptación con el cliente.
Los entregables que está fase generarán son los siguientes:
• Resultados de las pruebas de aceptación.
Conclusiones de la iteración
Para concluir cada iteración se agregará una fase adicional, la fase de conclusiones.
Durante está breve fase se darán todas las conclusiones derivadas de la finalización de
la iteración.
La fase no cuenta con tareas o entregables más que indicar que se ha conseguido con
la iteración.
Posterior a la finalización de todas las iteraciones, se tendrá una fase adicional

denominada pruebas integrales, acá se validará todo lo referente a calidad de software,
incluyendo criterios de calidad y pruebas de aceptación de la totalidad del sistema.
Finalmente, al concluir con el desarrollo, se llevará a cabo un último punto con la

estimación de costes del sistema.
2.3. MARCO REFERENCIAL
Dentro de este marco referencial se procede a exponer 3 trabajos de grado, tesis, que
fueron desarrolladas por otros estudiantes de a nivel universitario, licenciatura, que sean
semejantes al presente proyecto.
66
Narrativas Periodísticas y Bases de datos: Conflictos, Puntos de Encuentro e

Implicaciones
Autor: Juan Guillermo Tamayo
Bogotá, Colombia – noviembre de 2019
La relevancia de este proyecto nace de entre sus objetivos, siendo uno de ellos: “Servir
de base para estudios o investigaciones con fase de campo, dirigidos a evaluar el impacto
de tecnologías de IA al servicio del periodismo escrito en medios colombianos.” (Tamayo,
2019)
El proyecto trata de evaluar el impacto de la Inteligencia artificial y las formas de

automatización del lenguaje en el periodismo escrito. Primeramente, el papel describe el
posible impacto que la IA pueda llegar a tener a futuro en la creación automatizada de
noticias y la situación actual de esta tecnología en el mundo del periodismo, para luego
pasar a explicar el conflicto existente entre las bases de datos y las narrativas en donde
se explica como las bases de datos al ser medios de almacenamiento y procesamiento
de información por excelencia, se convierten en rival natural de las narrativas.
Luego de explicar el conflicto existente entre narrativas y bases de datos se procede a

hablar sobre como la inteligencia artificial permite la proliferación de interfaces digitales
con la capacidad de comunicarse con humanos y posteriormente entender qué pasa
cuando las máquinas transcienden su estatus de canales de comunicación para
convertirse en fuentes de mensajes.
El punto más importante del trabajo llega en el apartado: “De la sistematización de

información a la inteligencia artificial. De Watson a Watson.” Donde se comenta la historia
de la inteligencia artificial al servicio del texto. Eventualmente se llega al punto donde se
comenta sobre lo que es el Natural Language Processing (Procesamiento del lenguaje
natural) siendo está la rama de la inteligencia artificial que mayor impacto tendrá en el
periodismo y como el “NLG” (Natural Languaje Generator – Generador de lenguaje
natural) es el proceso a través del cual un sistema toma información representada en
términos computacionales y la lleva a un lenguaje humano, además de mencionar que
por definición el punto de partida de NLG es una base de datos. Posteriormente hace
67
mención sobre qué entidades hacen uso de la IA y la NLG siendo las más destacadas:
Associate Press (agencia de noticias en el Reino Unido), Bloomberg (Compañía
estadounidense de asesoría financiera), Washington Post (Periódico de la ciudad capital
de los Estados Unidos), Yahoo! Sports (División de deportes de la plataforma Yahoo!).
Avanzado en el papel se llega al punto Generación de Marcos de narración: Caso Mexica.

Donde narra como en 2001 dos investigadores del laboratorio de Cognición Cibernética
y aprendizaje de la ciencia en la Universidad Nacional Autónoma de México crean un
modelo informático de generación de marcos de narración de historias. El proceso
constaba de dos modos. El modo engagement (compromiso) que genera contenido a
partir de contenidos previos y bajo restricciones retóricas, y el modo reflection (reflexión)
que identifica tensiones entre los personajes de la historia generada y los modifica hasta
tener coherencia.
Los ciclos de los modos se pueden observar en la siguiente figura:
Figura N° 2.21
Ciclo de Compromiso – Reflexión
Fuente: Tamayo, 2019.
Finalmente, se llega a la conclusión de que la aplicación de la IA en áreas del periodismo

es totalmente factible, sin embargo, aún existen limitaciones tecnológicas como el hecho
de que no existe modelo de IA que pueda trabajar sin un previo input humano por la falta
68
de conocimiento suficiente sobre como ocurre un proceso creativo en la mente humana

tal que pueda ser emulado en un motor.
Exploring interactive features in auto-generated articles through article

visualization. (Explorando funciones interactivas en artículos generados
automáticamente a través de visualización de artículos)
Autor: Ali Abdel Rehim
Malmö, Suecia – primavera 2019
Traducido del inglés
El trabajo habla sobre las notas informativas generadas por inteligencia artificial o
periodismo automatizado.
Se comienza hablando sobre como el concepto de periodismo automatizado aún es

nuevo, pero que aun así en años recientes la inteligencia artificial fue mejorando de
manera considerable talque la generación de notas automáticas se ha vuelto más creíble
y como la IA más que reemplazar a los periodistas se convertirá en una herramienta
empleada en un panorama mediático cada vez más complejo e internacional. También
se describe como el proceso que sigue el algoritmo para crear una nota es semejante al
que un periodista usa, por ejemplo, el proceso de brindar datos que usa un reportero es
semejante al Data Mining (Minería de datos) donde el sistema busca por patrones,
conexiones y tiende a identificar eventos interesantes. Después de identificar una historia,
el sistema prioriza las percepciones, osease, qué es de interés periodístico y qué no, el
algoritmo estaría programado para valorar los resultados más que las lesiones en juegos
deportivos. Finalmente, el sistema genera una narrativa antes de publicar una historia.
69
Umělá inteligence v žurnalistice a její využití na příkladech tiskových agentur

Reuters a AP (La inteligencia artificial en el periodismo y su uso en los ejemplos de
Reuters y AP)
Autor: Oliver Jahn
Praga, Chequia – 2019
Traducido del checo
El objetivo de la tesis es presentar una forma nueva de crear y distribuir contenido con
las nuevas herramientas de aprendizaje automático. Cabe mencionar que dentro del
trabajo se menciona mucho “Reuters” y “AP”, Reuters es una organización internacional
de noticias mientras que la AP es una agencia de noticias multinacional sin fines de lucro.
Los primeros 2 puntos de la tesis hablan sobre la inteligencia artificial y su evolución hasta
lo que es hoy en día. Dentro de estos puntos se hace énfasis en como la IA es una
tecnología relativamente nueva dentro del mundo del periodismo y cómo es que
recientemente se está comenzando a explotar en este rubro informativo. Aun así, no es
hasta el tercer punto donde se entra en materia y se comienza a hablar de la IA en el
periodismo como tal. En el punto se menciona sobre como el escritor Alvin Toffler notó el
auge de los sistemas informáticos en la prensa para pasar a hablar sobre periodismo
robótico.
El concepto de periodismo informático, automatizado o robótico surge al considerar el

uso práctico de herramientas de software, hardware y máquinas disponibles para
actividades que hasta entonces requerían de seres humanos, procesos tales como la
recopilación de datos, la vinculación de hechos o siendo más exigentes: la creación de
artículos, por citar ejemplos.
Se expone como la capacidad de las máquinas es suficiente y puede ser trasladada a los
ámbitos de la percepción humana: a través del análisis de datos para aprender todo tipo
de relaciones y en general, descubrir y almacenar información que una persona normal
no tendría que recordar, o simplemente no tendría la capacidad para hacerlo. También
explica como los algoritmos diseñados por el hombre son importantes y como con ellos
70
el robot/máquina puede aprender las reglas básicas válidas y con esto aprender a
detectar el inicio de palabras que riman o reconocer fotografías con un tema en común
en Internet. Procesos que normalmente consumirán mucho esfuerzo a una persona
normal.
Ya en la práctica se menciona como las empresas empezaron a usar estás tecnologías

en sus prácticas regulares, por ejemplo, la empresa multimillonaria Narrative Science fue
una de las primeras organizaciones en generar noticias oficiales escritas por robots, esto
mediante algoritmos conectados a páginas web de estadísticas deportivas para brindar
seguimientos sencillos a juegos de béisbol. Aunque su objetivo específico era desarrollar
un programa con la capacidad de traducir tablas, gráficos y textos analíticos a un lenguaje
sencillo. También menciona como la empresa no es la única que ya implementa estás
tecnologías en el apartado informativo y como empresas en diferentes partes del mundo,
como en China, ya hacen lo mismo.
El documento luego pasa a hablar sobre la organización “Reuters”, describiendo su

historia y su camino hacia la inteligencia artificial. Centrándonos únicamente en el
apartado de la IA en la empresa se comenta como en 2006 Reuters presentó el primer
software automatizado de lectura de noticias para el sector financiero. De entre los varios
proyectos con IA que la empresa desarrolla a lo largo de los años se destaca Reuters TV
en 2015, el proyecto era una plataforma online interactiva que conecta múltiples
dispositivos según las necesidades y gustos del usuario con los servicios de Reuters. Lo
destacado del proyecto era como en base a tus preferencias actuales era capaz de
clasificar noticias y temas que sean de tu agrado. El apartado dedicado a la empresa
Reuters acaba exponiendo sus previsiones para el futuro, en pocas palabras, la empresa
planea seguir haciendo uso de la tecnología de la inteligencia artificial para facilitar tareas
a los empleados o cumplir con trabajos imposibles para humanos, esto sin delimitarse
únicamente al área del periodismo.
Otra agencia que analiza el trabajo es la organización AP, de igual manera que con
Reuters, se describe la historia de AP junto con su camino a los elementos de IA.
En el siglo XXI, así como Reuters, AP fue marcado por el auge de la cibernética,
tecnologías y elementos relacionados con la inteligencia artificial. Así fue como en 2008,
71
AP establece su primer departamento para desarrollar sistemas digitales y facilitar el

trabajo a los periodistas, un preludio al uso de sistemas de inteligencia artificial. En 2013
la empresa los autores de AP se acercaron a los directivos de la empresa con la idea de
que quisieran probar algo nuevo: trabajar con una empresa llamada Automated Insights
que ya había experimentado con la generación robótica de artículos con resultados para
el equipo de béisbol de Cleveland y el servicio de deportes de Yahoo! en general. Para
este proyecto se habría experimentado con inteligencias artificiales que abrían
demostrado su valor, estás pruebas habrían confirmado aspectos importantes como ser
que: el software creó contenido nuevo que los autores de AP no tendrían tiempo de
generar.
Luego de exponer más proyectos de IA que la empresa empezó a generar se llega a

2016 como en Rio de Janeiro durante los juegos olímpicos de verano la agencia AP
desplegaría once cámaras robóticas y con ellas llegaría a obtener tomas sin precedentes
sin tener la necesidad de que alguien las opere física o remotamente.
Luego de exponer el futuro de la empresa con respecto a la IA la tesis concluye con que
la IA está conectada con una parte relativamente grande de las profesiones y su uso está
probado en muchos campos, sin mencionar que, en algunas empresas ya se tiene
implementada como parte de sus operaciones cotidianas. Además de que haber sido de
mucha ayuda en empresas como Reuters o AP.
2.4. MARCO INSTITUCIONAL
Radio compañera es un medio de comunicación radial, multimedia de carácter

informativo con alcance a nivel de radio y nacional a nivel de redes sociales.
La radioemisora tiene la misión de ser parte de su audiencia, brindando alegría y

compartiéndola. Tiene la meta de que su programación entretenga, culturalice, informe,
motive y guíe de una manera sana, divertida e informal a las personas basada en su
filosofía de transmitir buenas noticias con una actitud positiva y motivadora.
La visión de Radio Compañera es dar un servicio con los más altos estándares de calidad
a su audiencia, con un excelente sonido, fidelidad y dando información fresca, real,
72
interesante, entregada con respecto y objetividad. Radio Compañera también busca ser
una herramienta para el aprendizaje para su audiencia.
La jerarquía de la radio se compone por; una dirección general, dirigida por los dueños
de la radio; la gerencia a cargo de un área administrativa contable; el área operativa
compuesta por el departamento de presa compuesto a su vez por: jefes de prensa,
periodista, presentadores. Luego se tiene el área de operaciones en donde está el
personal técnico: operadores, jefes de piso, productores.
En el trabajo de prensa de la radio se tiene a 2 jefes de prensa los cuales tienen bajo su
cargo a los periodistas y pasantes.
En el siguiente organigrama se puede observar cómo funciona la jerarquía de Radio

Compañera.
Figura N° 2.22
Organigrama de Radio Compañera
El trabajo noticioso se divide en 3 adiciones: 8 am, 1pm y 5 pm. La hermenéutica de

trabajo consiste en que los periodistas salen a las calles, los mismos hacen las notas, las
graban para al final regresar a la radio a editarlas, a su vez las notas también deben de
ser enviadas a un WhatsApp para ser redactadas por los pasantes y ser subidas a las
redes sociales. El trabajo al momento se realiza netamente mediante grupos de
WhatsApp, no se cuenta con un sistema de apoyo al departamento de prensa.
CAPÍTULO III
69
CAPÍTULO III
3.1. SOLUCIÓN PRESENTADA
La solución que se plantea para asistir al departamento de prensa de Radio Compañera

es desarrollar un sistema web responsive para incrementar la eficiencia de la difusión
informativa, este mejorará la eficiencia de la difusión informativa aplicando redes
neuronales recurrentes LSTM, además de interactuar con la página web de Radio
Compañera y apoyar con el manejo de notas informativas generadas por los reporteros.
Se expresa de forma gráfica la solución en un esquema. (Ver apéndice D).
3.2. PLANIFICACIÓN DEL DESARROLLO
Para el desarrollo del presente proyecto se hará uso de la metodología propuesta en el

punto 2.2.11 del marco teórico, metodología del proyecto. Se describe de forma resumida
la metodología en la siguiente tabla:
Cuadro N° 3.1
Planeación del proyecto
FASES ITERACIÓN ENTREGABLES
Planificación No pertenece a ninguna - Product backlog.

- Release plan.
Selección Primera - Historias técnicas.
- Objetivo para lograr.
- Identificación de
posibles fuentes de
datos.
Preprocesamiento - Set de datos.

- Figuras
estadísticas.
70
Transformación - Cuadros
estadísticos.
Minería de datos - Diseño del modelo

de aprendizaje
Evaluación - Métricas del

entrenamiento.
Conclusiones de la - Conclusiones de la
iteración iteración.
Diseño Segunda, tercera, cuarta, - Sprint backlog.

- Descomposición en
quinta y sexta iteración
tareas.
Codificación - Pruebas de
software.
Pruebas - Pruebas de
aceptación.
Conclusiones de la - Conclusiones de la
iteración iteración.
Pruebas integrales No pertenece a ninguna - Pruebas de

aceptación finales.
- Demostración de
cumplimiento de
criterios de calidad
- Demostración del
cumplimiento del
objetivo general.
Evaluación de No pertenece a ninguna - Costes del sistema

costos del sistema en BS.
71
- Costos operativos
del sistema.
3.3. ANÁLISIS DE LA SITUACIÓN ACTUAL
3.3.1. SITUACIÓN ACTUAL
Para el análisis de la situación actual se procede a mostrar una tabla con un diagrama de
actividades que describe cómo se realiza la publicación de noticias en el departamento
de prensa de Radio Compañera.
Figura N° 3.1
Diagrama actividades para la publicación de una noticia

72
Cuadro N° 3.2
Descripción de las actividades en el diagrama.
Nro. Actividad Descripción Responsable

1 Ir al lugar del Él reportero llega al lugar del incidente. Reportero.
suceso.
2 Redactar nota Luego de llegar al lugar del suceso, él Reportero.
informativa. reporteo hace un análisis de la situación,
extrae los puntos más importantes y
convierte los datos en una nota
informativa.
3 Entregar nota al Él reportero envía el resultado de su Reportero.
jefe de prensa. trabajo a los jefes de prensa mediante un
grupo de WhatsApp.
4 Revisar nota Un jefe de prensa lee la nota, revisa la Jefe de
informativa. redacción, verifica la ortografía y el prensa.
contenido para dar un veredicto de
aprobación o desaprobación de la nota.
5 Regresar a la Para poder publicar la nota, en todos los Reportero.
radio. casos el reportero deberá regresar a la
radio.
6 Redactar la nota en En caso de que la nota sea aprobada, él Reportero.
formato de la reportero deberá volver a redactar la
página. nota, esta vez en formato de la página,
ajustando su contenido.
7 Publicar la nota en Con el contenido de la nota ya ajustado Reportero.
la página web. al formato de la página web, él reportero
realiza la publicación de la nota en la
página web de Radio Compañera.
73
8 Entregar Él reportero debe sacar captura de la Reportero.

constancia de la noticia publicada en la página web de
publicación. Radio Compañera y enviarla a un jefe de
prensa.
3.3.2. SITUACIÓN ESPERADA
Con la implementación de la solución presentada, se espera que el proceso de

publicación de noticias en el departamento de prensa de Radio Compañera se vea
reducida y simplificada eliminando procesos repetitivos e innecesarios. En la siguiente
figura se adjunta un diagrama de actividades que describe la situación esperada junto
con la tabla de descripción de actividades.
Figura N° 3.2
Diagrama actividades de publicación de noticias mejorado

74
Cuadro N° 3.3
Descripción de las actividades en el diagrama
Nro. Actividad Descripción Responsable

1 Ir al lugar del Él reportero llega al lugar del incidente. Reportero.
suceso.
2 Redactar nota Luego de llegar al lugar del suceso, él Reportero.
informativa. reporteo hace un análisis de la
situación, extrae los puntos más
importantes y convierte los datos en
una nota informativa dentro de la
aplicación.
3 Publicar la nota en Él reportero publica la nota en la página Reportero.
la página web. web de Radio Compañera mediante la
aplicación.
4 Revisar nota Un jefe de prensa lee la nota, revisa la Jefe de
informativa. redacción, verifica la ortografía y el prensa.
contenido.
5 Regresar a la En caso de encontrar observaciones el Jefe de
radio. jefe de prensa procederá a asignar una prensa.
tarea al reportero responsable de la
nota.
6 Atender tareas. En caso de tener tareas el reportero Reportero.
podrá modificar la nota para resolver
las observaciones dadas.
3.5. PLANIFICACIÓN
Identificación de requerimientos
Se procede a mostrar el product backlog en la siguiente tabla.

75
Cuadro N° 3.4
Product backlog
N° Historia de usuario Descripción

1 Clasificación de noticias. Como usuario del sistema quiero que la clasificación
de las noticias sea de manera automática para
mantener un orden sobre mis noticias en el sistema.
2 Manejo de noticias en el Como reportero quiero manejar mis noticias en el
sistema. sistema para tener control sobre mis noticias en el
sistema.
3 Manejo de archivos Como reportero quiero subir y ordenar archivos
multimedia en el multimedia para hacer uso de ellos al crear noticias.
sistema.
4 Conexión con la página Como reportero quiero que las noticias que subo al
web de Radio sistema puedan ser vistas en mi página web para que
Compañera. nuestros usuarios puedan tener acceso a la
información de manera más eficaz.
5 Tareas para los Como jefe de prensa quiero dar retroalimentación a los
reporteros. reporteros sobre sus acciones en el sistema para tener
un mejor control sobre sus acciones.
76
6 Creación de cuentas. Como jefe de prensa quiero crear nuevas cuentas en

el sistema para que nuevos reporteros puedan acceder
al sistema.
Como se explica en la metodología del proyecto (Ver punto 2.2.14), en el product backlog
inicial solo se incluye la descripción de la historia de usuario. Los criterios de aceptación
se agregarán en las fases de diseño de las respectivas iteraciones.
Release plan
Se procede a generar el release plan mediante la asignación de historias de usuario a

diferentes iteraciones en la siguiente tabla.
Cuadro N° 3.5
Release plan
N° Iteración Historia de usuario Fecha

1 Clasificación de noticias. 18/08/22
2 Manejo de noticias en el 01/09/22
sistema.
3 Manejo de archivos 15/09/22
multimedia en el sistema.
4 Conexión con nuestra página 27/09/22
web.
5 Tareas para los reporteros. 11/10/22
6 Creación de cuentas 25/10/22
3.6. ITERACIONES
3.6.1. PRIMERA ITERACIÓN
Al tratarse de la primera iteración se atenderá todas las fases del proceso KDD.
77
3.6.1.1. Selección
Para el desarrollo de la primera iteración, se responderá a la primera y única historia

técnica, a su vez atendiendo al Release Plan. En la siguiente figura se muestra la historia
técnica en su formato en ficha.
Cuadro N° 3.6
Historía técnica #1
Nombre Creación de un modelo de Deep Learning.

Descripción Generar una red neuronal recurrente de tipo LSTM con la
capacidad de clasificar notas informativas.
Criterios de - El modelo debe de clasificar un texto entre 7 posibles
aceptación categorías.
- El modelo debe tener un mínimo de 70% (0.7) de
Accurracy Score.
Tipo: Historia técnica.
Prioridad: Alta.
En base a la historia técnica #1, se procede a definir el objetivo del proceso KDD.
El objetivo será desarrollar una red neuronal recurrente de tipo LSTM con la capacidad
de identificar la categoría de un texto tipo informativo dado entre 7 posibilidades. La
predicción debe alcanzar un Accuracy Score (puntuación de precesión) mayor al 70%.
Para realizar la recolección de datos que conformarán el conjunto de datos necesario

para entrenar la red neuronal es necesario identificar sitios web que cumplan con 2
criterios, el primero es que debe de ser una página de noticias y el segundo y más
importante es que dicha página acepte peticiones GET para retirar el código HTML de
sus sitios web.
Se considera una lista inicial de 9 páginas web de noticias bolivianas y una internacional,
luego se realiza una petición GET a cada uno de los sitios, si da como respuesta un
78
código 200, se podrá usar como fuente de datos. En caso de código 403, no se podrá
utilizar el sitio web.
Se muestra el resultado de las peticiones en la siguiente figura.
Figura N° 3.3
Resultados de peticiones GET
Como se puede apreciar, de los 10 sitios con los que se probó, solo 4 tienen como
resultado un código de éxito en su petición.
En base a la información en la figura anterior, se llega a la conclusión de que se usará

las siguientes páginas para la recolección de datos. Se muestran en la siguiente figura.
Figura N° 3.4
Páginas a utilizar para recolectar datos

79
3.6.1.2. Preprocesamiento
Una vez con las fuentes de datos identificadas, se procede a aplicar el ya mencionado
Web Scraping, para cumplir con esta tarea se desarrolla un sistema compuesto por 5
módulos, un módulo principal, encargado de escribir en el set de datos y 4 submódulos
encargados de obtener las noticias, un módulo por página web, esto es necesario puesto
que cada página es diferente y no se podrá reutilizar módulos. En el siguiente diagrama
de paquetes se puede observar de forma gráfica.
Figura N° 3.5
Diagrama de componentes para el Web Scraping
Como se especificó, cada página web debe tener su propio modulo dado que el código
implementado en estos variará según la página. Aun así, la funcionalidad de cada uno de
los módulos es parecida, pero no igual.
El proceso realizado por cada módulo es bastante extenso y complejo de explicar

textualmente, por esta razón se adjunta un diagrama de actividades que describe la
funcionalidad general de este subsistema.
Cabe aclarar que el diagrama solo muestra 2 de 4 procesos concurrentes por motivos de
simplicidad dado que los 4 procesos son semejantes.
En la siguiente figura se observa el diagrama de actividades que describe el proceso

realizado por los módulos.
80
Figura N° 3.6
Diagrama de actividades del sistema de web scraping

81
De esta forma se logra obtener un conjunto de datos con un volumen de 48700 noticias
y de 5000 a 8000 noticias por categoría.
Cabe aclarar que este proceso de recolección se realizó en cuestión de horas.
Se realizan figuras estadísticas que muestran de mejor manera tanto la distribución de

noticias por categoría cómo la cantidad de noticias por categoría en las siguientes figuras.
Figura N° 3.7
Grafica de la cantidad de noticias por categoría pre-limpieza
Figura N° 3.8
Grafica de la distribución de noticias por categoría pre-limpieza

82
3.6.1.3. Transformación
Para la fase de transformación, se procede a realizar una limpieza del set de datos.
Como primer criterio de limpieza se tendrá eliminar todas las noticias sin categoría o
uncategorized.
El segundo criterio será eliminar todas las noticias con un conteo de palabras considerado
como bajo. Para este caso se considerará como un conteo bajo todas las noticias con
menos de 150 palabras.
El tercer criterio será eliminar noticias que se encuentren repetidas. Definiendo como
repetida una nota que tenga exactamente el mismo título de otra noticia dentro del
conjunto de datos.
Finalmente, no se tendrá un criterio para conteos altos de palabras puesto que no

suponen un problema para el entrenamiento de la red neuronal dado que todas las
noticias que excedan un límite de 150 palabras serán cortadas. Esto no afectará el
resultado del entrenamiento.
Cómo resultado de la limpieza, se obtiene un nuevo set de datos con un volumen de

información inferior. Se muestran las gráficas de cantidad de noticias por categoría y la
distribución de noticias por categoría en las siguientes gráficas.
Figura N° 3.9
Grafica de la cantidad de noticias luego de la limpieza

83
Como se puede observar el volumen total del conjunto de datos luego de la limpieza es
de 44990 noticias, comparando con la figura 21 del punto previo, se evidencia una pérdida
de 3714 noticias o del 7.62% volumen original. Sin embargo, el conteo final de notas
posterior a la limpieza se sigue manteniendo alto, por lo tanto, si bien podría afectar
ligeramente a las métricas finales, esto será por algo tan bajo que no podría afirmarse
que el resultado final se vea enormemente afectado.
Algo que se observa es que luego de la limpieza del conjunto de datos, la distribución de
noticias por categoría se mantiene igual, a pesar de ser menor la cantidad de información,
aún se mantiene el balance.
Se puede observar la distribución de noticias por categoría luego de la limpieza en la

siguiente imagen.
Figura N° 3.10
Grafica de la distribución de noticias luego de la limpieza
3.6.1.4. Minería de datos
Para la minería de datos se selecciona y desarrolla un modelo de aprendizaje, ya sea

supervisado o no supervisado.
84
En este caso desde el planteamiento del objetivo en la fase de selección se tiene claro el
modelo para desarrollar: Una red neuronal recurrente de tipo LSTM.
Ya seleccionado el modelo de aprendizaje se diseña la estructura que este tendrá en

base a los pasos identificados previamente en el punto 2.2.7.4. Diseño de una red
neuronal.
• La cantidad de neuronas en la capa de entrada será de 150, cada input representa

una palabra del texto.
• La cantidad de neuronas en la capa de salida será de 7, una por categoría.
- Se contará con 5 capas ocultas:
o Dos capas dense
o Una capa LSTM
o Una capa de embedding
o Una capa de flattening
- Cantidad de neuronas o entradas por capa:
o La primera capa dense tendrá 512 neuronas.
o La segunda capa dense tendrá 8 neuronas.
o La capa de embedding tendrá 150 entradas.
o La capa LSTM tendrá 150 instantes de tiempo.
o La capa de flattening tendrá 150 entradas y 1600 salidas.
- Cada capa tendrá una función de activación:
o Las 2 capas dense tendrán una función ReLu.
o La capa de embedding tendrá una función ReLu.
o La capa LSTM tendrá una función de tangente hiperbólica tanh.
o La capa de flattening no ocupa función de activación.
- Se entrenará la red neuronal por un total de 25 épocas.
- Se tendrán 3 capas de dropout:
o La primera capa tendrá una entrada de tamaño 150.
o La segunda capa tendrá una entrada de tamaño 512.
o La tercera capa tendrá una entrada de tamaño 8.
Se puede apreciar de forma gráfica en la figura 32 el diseño de la red neuronal.

85
Figura N° 3.11
Diseño de la red neuronal recurrente LSTM

86
3.6.1.5. Evaluación
Ya con el modelo desarrollado y entrenado, la última fase del proceso KDD expone que
se debe probar validar el modelo, para realizar esta validación se hace uso de métricas
cómo ser el accuracy score y el model loss. Si bien la metodología indica técnicas
diferentes, se hará uso de estás métricas por ser las que mejor evalúan un modelo
basado en redes neuronales.
La red neuronal fue entrenada por un total de 25 épocas, cada época teniendo su propio
accuracy Score y model Loss. Para llegar a un resultado óptimo con cada época el
modelo debería incrementar dichas métricas hasta superar el umbral del 0.7 (70%). Se
muestra de forma gráfica la evolución de las métricas en las siguientes figuras.
Figura N° 3.12
Evolución del accuracy score en función a las épocas
Cómo se puede observar, en las primeras épocas el modelo tiene un desempeño pobre,
sin embargo, a medida que avanzan las épocas este va mejorando, especialmente con
los datos de validación hasta alcanzar un valor de 0.73 (73%) de accuracy score con los
datos de validación.
Para la siguiente métrica, el model loss, se espera que a medida que avanzan las épocas,
este vaya descendiendo. La siguiente grafica representa su evolución.
87
Figura N° 3.13
Model loss para clasificación de texto
3.6.1.6. Conclusiones de la iteración
Para la primera iteración se llega a la conclusión de que se ha recopilado noticias

generando un conjunto de datos haciendo uso de web scraping de forma rápida e integra
y posteriormente se ha utilizado dicho conjunto de datos para desarrollar una red neuronal
recurrente de tipo LSTM que ahora cuenta con la capacidad de clasificar notas
informativas, cumpliendo de esta forma los 2 primeros objetivos específicos propuestos
en el punto 1.4.2. Objetivos específicos.
3.6.2. SEGUNDA ITERACIÓN
3.6.2.1. Diseño
Se puede apreciar en la siguiente tabla el sprint backlog para esta iteración.

88
Cuadro N° 3.7
Sprint backlog iteración 2
Objetivo de la iteración Historias de usuario

Desarrollar la funcionalidad Subida de noticias en el
de subir notas informativas sistema.
al sistema.
Se procede a convertir la historia de usuario designada para está iteración en el sprint

backlog en un requerimiento en la siguiente tabla:
Cuadro N° 3.8
Hisoria de usuario #1
Nombre Manejo de noticias en el sistema.

Descripción Como reportero
Quiero manejar mis noticias en el sistema
Para tener control sobre mis noticias en el sistema.
Criterios de - Las noticias se crearán mediante una pantalla de
aceptación creación de noticias.
- Cada noticia tendrá nombre, foto de portada,
contenido, relevancia y lead de la noticia.
- El sistema debe reconocer la categoría de la noticia.
- La casilla de contenido debe permitir modificar el estilo
del texto, tipo de letra, tamaño del texto, color, etc.
- Las noticias deben poder ser editadas después de
guardadas.
- Las noticias deben poder ser eliminadas después de
guardadas.
Prioridad: Alta.
89
Se procede a hacer la descomposición en tareas de la historia de usuario de la siguiente

manera:
T1. Desarrollar el diagrama de casos de uso de la funcionalidad.
T2. Realizar un incremento del diagrama relacional de la base de datos.
T3. Realizar el diagrama de clases a partir del diagrama relacional.
T4. Programar los servicios de la API para la creación y modificación de noticias.
T5. Desarrollar una API separada para la clasificación de noticias.
T6. Desarrollar las interfaces de los módulos identificados en los casos de uso.
T7. Realizar pruebas a las funcionalidades desarrolladas.
Con esto se concluye la planificación de la segunda iteración.
3.6.2.2. Codificación
Se atenderán todas las tareas identificadas durante la fase de diseño.
T1. Desarrollar el diagrama de casos de uso de la funcionalidad
En la figura se aprecia el diagrama de casos de uso para la funcionalidad de manejo de

noticias.
90
Figura N° 3.14
Diagrama de casos de uso de manejo de noticias
Se procede a describir todos los casos de uso identificados en el previo diagrama.
Publicar noticia – Modificar noticia
Mediante un formulario en pantalla los reporteros y jefes de prensa podrán crear o

editar una noticia ingresando el título, contenido y lead de la noticia, además de tener
que seleccionar una foto de portada y la relevancia de la nota.
En la siguiente figura se observa el mockup de este caso de uso, es importante

establecer que la siguiente pantalla servirá tanto para crear como para editar.
91
Figura N° 3.15
Mockup de creación/edición de noticias
Ver noticias publicadas – Deshabilitar noticias
Los reporteros y jefes de prensa podrán ver las noticias que han subido al sistema
mediante una pantalla con un listado de sus notas. Este listado mostrará el título de la
nota, su categoría, fecha de publicación y expiración, además de contar con submenú
de acciones que contendrá el botón para acceder a la pantalla de edición de notas y el
botón para deshabilitar la noticia.
Se aprecia su mockup en la siguiente figura.

92
Figura N° 3.16
Mockup de listado de noticias
T2. Realizar un incremento del diagrama relacional de la base de datos
Para la base de datos se hará uso de un gestor de base de datos relacional, PostgreSQL.
Se crea la primera versión de una base de datos en dicho gestor. Las primeras tablas
identificadas serán la tabla de reportero, noticias y contenido noticia. La tabla de reportero
inicialmente solo tendrá el id de reportero y un campo archivos para almacenar
información sobre las notas que ha creado, la tabla noticias en cambio contará con toda
la información relevante sobre la creación de esta, como fecha de creación, estado, entre
otros. Por último, se tendrá una tabla separada para definir todo el contenido que tendrá
la noticia, está tabla contendrá los campos de la noticia como ser el título, la foto de
portada, su contenido, el lead de la noticia y su categoría además de la id de la noticia
para saber a qué noticia le pertenece que contenido.
Se puede apreciar de forma gráfica la base de datos en el siguiente modelo entidad

relación.
93
Figura N° 3.17
Primera versión del modelo relacional de la base de datos
T3. Realizar el diagrama de clases a partir del diagrama relacional
Del mismo diagrama también se genera un diagrama de clases, diagrama de clases que
será utilizado por el ORM del sistema para convertir las tablas en objetos. En la siguiente
figura se llega a observar.
Figura N° 3.18
Diagrama de clases primera versión

94
T4. Programar los servicios de la API para la creación y modificación de noticias
Para el desarrollo del servicio de publicación de noticias, se genera en una API REST
creada con Node JS un servicio que permita las operaciones CRUD necesarias para el
manejo de noticias en el sistema. Para acceder a estos servicios se hará uso de la ruta
de noticias.
En la siguiente tabla se expone todas las funcionalidades implementadas bajo la ruta ya

especificada junto con el método al que responden y su descripción:
Cuadro N° 3.9
Métodos de la ruta noticias
Ruta Método Descripción

/noticias/ GET Regresa todas las
noticias.
/noticias/{id_noticia} GET Regresa la noticia que
tenga el id enviado como
parámetro.
/noticias/content/all GET Regresa todas las
noticias más su
contenido.
/noticias/content/{id_noticia} GET Regresa una noticia más
su contenido donde el id
de la noticia sea igual al
id enviado.
/noticias/reportero/{id_reportero} GET Regresa todas las
noticias que el reportero
con el id enviado haya
publicado.
/noticias/ POST Publica la noticia
enviada.
95
/noticias/{id_noticia} PATCH Modifica la noticia que

tenga el id enviado.
/noticias/{id_noticia} DELETE Desactiva la noticia con
el ID que se haya
enviado.
T5. Desarrollar una API separada para la clasificación de noticias
Para realizar el desarrollo del proyecto se vuelve una necesidad hacer la implementación
de una segunda API con una única ruta: noticias.
En la siguiente tabla se expone las funcionalidades bajo la ruta en la API.
Cuadro N° 3.10
Métodos de la ruta noticias, segunda API
Ruta Métodos Descripción

/noticias/ POST Recibe una noticia y
regresa la categoría de
esta.
T6. Desarrollar las pantallas descritas en los mockups
Se desarrolla la interfaz de creación de noticias y de listado de notas. El desarrollo puede

ser observado en las siguientes figuras.
96
Figura N° 3.19
Pantalla de creación/modificación de noticias
Figura N° 3.20
Interfaz de listado de noticias

97
T7. Realizar pruebas a las funcionalidades desarrolladas
Ya realizadas todas las funcionalidades de la iteración se cumplirá la última tarea: realizar

pruebas. Para ello se realizan pruebas de caja negra en la interfaz de creación de noticias
desarrollada expuestas en las siguientes tablas.
Cuadro N° 3.11
Prueba de caja negra #1
PRUEBA-01 Crear una noticia con campos vacíos.

Propósito Ver si el módulo cuenta con validaciones
de campos nulos al crear noticias.
Prerrequisitos Por lo menos un campo debe de estar
vacío.
Pasos 1. Introducir datos en título y lead
dejando el contenido en blanco.
2. Seleccionar el botón de crear
noticia.
Resultado esperado Mensaje indicando que se deben de
completar campos.
Resultado obtenido Mensaje indicando que se debe de
completar el cuerpo de la noticia.
Resultado de la prueba Correcto
Cuadro N° 3.12
PRUEBA-02 Crear una noticia con todos los campos

completos.
Propósito Ver si el módulo crea de forma adecuada
las noticias.
Prerrequisitos Todos los campos deben de estar
completos.
98
Pasos 4. Completar todos los campos que se

solicitan.
noticia.
6. Seleccionar el botón de publicar.
Resultado esperado Redirección a otra ventana con la noticia
en ella.
Resultado obtenido Redirección a otra ventana con la noticia
en ella.
Cuadro N° 3.13
PRUEBA-03 Crear una noticia con archivos multimedia

en el cuerpo de esta.
Propósito Ver si el módulo acepta archivos
multimedia en las noticias.
Prerrequisitos El cuerpo de la noticia debe de tener por
lo menos una imagen, video o audio.
Pasos 1. Completar todos los campos que se
solicitan.
2. Seleccionar el botón de agregar
medios.
3. Seleccionar un archivo multimedia.
noticia.
Resultado esperado Redirección a otra ventana con la noticia
en ella.
Resultado obtenido Redirección a otra ventana con la noticia
en ella.
99

3.6.2.3. Pruebas
Para las pruebas de aceptación se validan con el cliente todas las funcionalidades
desarrolladas durante la iteración. Los resultados se muestran en la siguiente tabla.
Cuadro N° 3.14
Pruebas de aceptación #1

Creación de noticias. Aprobada. Ninguna.
Modificación de noticias. Aprobada. Ninguna.
Listado de noticias. Aprobada. El sistema debería indicar
cuantas noticias se publicó
durante el día.
Des habilitación de Aprobada. Ninguna
noticias.
Se llega a la conclusión de que el módulo o funcionalidad de subida de notas al sistema

ha sido desarrollado con éxito.
También se consiguió elaborar un primer incremento o primera versión de lo que sería la

base de datos del sistema partiendo desde su esquema relacional.
3.6.3. TERCERA ITERACIÓN
3.6.3.1. Diseño
Se puede apreciar en la siguiente tabla el sprint backlog para está iteración.

100
Cuadro N° 3.15
Desarrollar una funcionalidad en donde Manejo de archivos multimedia en el

los usuarios puedan subir archivos sistema.
multimedia y ordenarlos en carpetas,
además de almacenar también las
noticias.
La historia de usuario en el sprint backlog es desglosada en un formato tarjeta en la

siguiente figura:
Cuadro N° 3.16
Historia de usuario #2
Nombre Manejo de archivos multimedia en el sistema.

Quiero subir y ordenar archivos multimedia
Para hacer uso de ellos al crear noticias
Criterios de - Se podrá subir archivos multimedia y guardarlos en
aceptación carpetas.
- Cada carpeta podrá contener 1 o más archivos,
noticias u otras carpetas.
- Cada carpeta tendrá un nombre que se podrá
modificar.
- Se podrá eliminar carpetas.
- Los archivos multimedia deberán poder ser utilizados
al momento de crear noticias.
Prioridad: Alta.

101
T1. Desarrollar el diagrama de casos de uso de la funcionalidad.
T2. Desarrollar un diagrama de componentes de la funcionalidad en el lado del cliente.
T3. Implementar un servicio en la primera API para almacenar los archivos.
T4. Desarrollar las pantallas descritas en los mockups.
T5. Realizar la integración con el módulo de crear noticias.
T1. Desarrollar el diagrama de casos de uso de la funcionalidad
En la siguiente figura se aprecia el diagrama de casos de uso para la funcionalidad de

manejo de archivos multimedia.
Figura N° 3.21
Diagrama de casos de uso de manejo de archivos multimedia

102
Se procede a describir todos los casos de uso identificados en el previo diagrama.
Subir archivos
Está funcionalidad le permitirá a un usuario subir cualquier tipo de archivo que sea
multimedia (audios, vídeos, imágenes) mediante un botón que desplegará una pestaña
del sistema operativo y permitirá buscar y seleccionar el archivo. Este caso de uso no
cuenta con un mockup puesto que dependerá del sistema operativo en el cual el
usuario trabaje.
Crear carpetas – Modificar carpetas
Mediante una pequeña ventana modal, el usuario podrá agregar una carpeta a sus
archivos luego de ingresar el nombre que tendrá la misma. En la siguiente figura se
puede observar el mockup del caso de uso.
Figura N° 3.22
Mockup de crear nueva carpeta
Previsualizar archivos
La funcionalidad de previsualizar archivos se refiere a que al momento de seleccionar

un archivo que no sea una carpeta, este abrirá una ventana modal que mostrará el
contenido del archivo, en el caso de las noticias, el contenido, en imágenes, la imagen,
103
así sucesivamente con todos los tipos de archivos multimedia que pueden ser subidos
al sistema.
Se puede observar su mockup en la siguiente figura.
Figura N° 3.23
Mockup de previsualización de archivos
Archivar carpetas
Cuando se archive una carpeta, esta perderá visibilidad y toda noticia que contenga será
lleva a la pestaña de noticias archivadas dentro de la lista de noticias.
Para el desarrollo de la interfaz se trabaja en una pantalla que se asemeja a un explorador

de archivos, con carpetas, imágenes, audios y vídeos, además de las opciones de
agregar carpetas o medios. En la siguiente figura se observa la interfaz desarrollada.
104
En el siguiente mockup se puede observar cómo será el diseño final de toda está
funcionalidad, en dicha pantalla se pueden observar todas las funcionalidades descritas
hasta el momento.
Figura N° 3.24
Mockup de la funcionalidad manejo de archivos multimedia
T2. Desarrollar un diagrama de paquetes de la funcionalidad en el lado del cliente
Para desarrollar la siguiente funcionalidad, es necesario generar ciertos módulos dentro

de la aplicación que contribuyan al desarrollo.
Dicho diagrama refleja cómo funcionará de manera interna del lado del cliente está
funcionalidad a ser desarrollada.
En la siguiente figura se aprecia el diagrama de componentes.

105
Figura N° 3.25
Diagrama de componentes del manejo de archivos
T3. Implementar un servicio en la primera API para almacenar los archivos por cada
usuario
En la API desarrollada en Node Js se crea una nueva ruta: reporteros que será utilizada
para almacenar el esquema bajo el que haya guardado sus archivos. Cabe mencionar
que en el previo incremento de la base de datos se identificó en la tabla de reporteros un
campo: “Archivos” que ahora será utilizado para almacenar su esquema, por ende no es
necesario generar otro incremento de la base de datos.
La siguiente tabla describirá las funcionalidades bajo la nueva ruta en la API.
Cuadro N° 3.17
Métodos de la ruta reporteros, primera API
Ruta Métodos Descripción

/reporteros/archivos POST Almacena en la base de
datos el esquema enviado.
T4. Desarrollar las pantallas descritas en los mockups
En la primera tarea de la iteración, se desarrollaron casos de uso y junto con ellos se

mostraron mockups, se procede a desarrollar las pantallas descritas en los mismos.
106
La primera pantalla será la de crear / modificar carpetas. Se puede observar la pantalla

desarrollada en la siguiente figura:
Figura N° 3.26
Interfaz de creación/modificación de carpetas
La siguiente interfaz reflejará toda la funcionalidad completa.
Figura N° 3.27
Interfaz de la funcionalidad manejo de archivos multimedia

107
Finalmente, al seleccionar el archivo, se podrá previsualizar lo que mostrará la siguiente

pantalla:
Figura N° 3.28
Pantalla de previsualización de archivos
T5. Realizar la integración con el módulo de crear noticias
Para realizar la integración con el módulo de creación de noticias lo primero que se hace
es incluir en el apartado de crear noticias un botón bajo el nombre de: agregar medios, al
seleccionar dicho botón se abrirá de forma modal el explorador de archivo ya desarrollado
solo que está vez solo permitirá seleccionar imágenes, audios o vídeos y navegar entre
carpetas, no tendrá ninguna de las operaciones relacionadas con la creación, eliminación
o modificación de estos. Finalmente, al seleccionar un archivo este será agregado al
apartado de desarrollo de la noticia o cuerpo de la noticia.
También es necesario aclarar que los archivos multimedia agregados al cuerpo de la

noticia podrán ser movidos, eliminados o combinados con el texto ya existente a voluntad
del reportero que esté redactado la nota.
108
Se puede apreciar el diseño de la pantalla en la siguiente figura.
Figura N° 3.29
Pantalla de agregar medios
Para la última tarea, se desarrollan pruebas de caja negra en las funcionalidades

desarrolladas. Los resultados se exponen en las siguientes tablas.
Cuadro N° 3.18
PRUEBA-04 Persistencia de datos.

Propósito Ver si el módulo mantiene la información
de manera persistente.
Prerrequisitos Debe de existir por lo menos un archivo en
el cuaderno.
Pasos 1. Cargar, modificar o eliminar un
archivo ya existente.
109
2. Recargar la página.
Resultado esperado Los cambios se mantienen de forma
persistente.
Resultado obtenido Los cambios se mantienen de forma
persistente.
Cuadro N° 3.19
PRUEBA-05 Intentar subir un tipo de archivo no valido.

de permitir solo archivos multimedia.
Prerrequisitos Ninguno.
Pasos 1. Cargar un archivo en formato txt,
docx, csv, etc.
Resultado esperado Mensaje indicando que el tipo de archivo
es invalido.
Resultado obtenido Mensaje indicando que el tipo de archivo
es invalido.
110
Cuadro N° 3.20
PRUEBA-06 Renombrar un archivo a un nombre ya

existente.
de nombre único.
Prerrequisitos Tener por lo menos un archivo cargado o
una carpeta existente.
Pasos 1. Subir, renombrar o crear un
archivo, carpeta con exactamente
el mismo nombre ya existente.
Resultado esperado Mensaje indicando que el archivo ya
existe.
Resultado obtenido Mensaje indicando que el archivo ya
existe.
3.6.3.3. Pruebas
Finalmente, se concluye con la iteración realizando la validación de todas las

funcionalidades realizadas con el cliente en la siguiente tabla.
Cuadro N° 3.21

Subir archivo. Aprobada. Ninguna.
Crear carpetas. Aprobada. Ninguna.
Eliminar carpetas. Aprobada. Ninguna.
Modificar carpetas. Aprobada. Ninguna.
Integración con el módulo Aprobada. Ninguna.
de crear noticias
111
Se llega a la conclusión de que el módulo o funcionalidad de manejo de archivos

multimedia en el sistema ha sido desarrollado con éxito.
Ahora el sistema cuenta con una funcionalidad semejante a un explorador de archivos de

un sistema operativo el cual puede ser utilizado para incrementar significativamente la
organización de los archivos y noticias de los reporteros en el sistema.
3.6.4. CUARTA ITERACIÓN
3.6.4.1. Diseño
En la siguiente tabla se muestra el sprint backlog para está iteración.
Cuadro N° 3.22

Lograr una integración con un servicio Conexión con la página web de Radio
Wordpress para que se puedan publicar, Compañera.
modificar y deshabilitar noticias desde la
aplicación.
Se procede a convertir la historia de usuario designada para está iteración en el sprint

backlog en su formato en ficha en la siguiente figura:
Cuadro N° 3.23
Nombre Conexión con la página web de Radio Compañera.

Quiero que las noticias que subo al sistema puedan ser
vistas en mi página web
Para que nuestros usuarios puedan tener acceso a la
información de manera más eficaz.
112
Criterios de - Todas las noticias creadas en el sistema se podrán

aceptación publicar en una página web de Wordpress.
- Se podrá hacer la modificación de estás notas desde
el sistema.
- Las notas se podrán deshabilitar desde el sistema.
Prioridad: Alta.
Se realiza la descomposición en tareas de la historia de usuario de la siguiente manera:
T1. Desarrollo de una ruta en la segunda API con las funcionalidades de crear, modificar
y deshabilitar noticias.
T2. Integrar la funcionalidad de crear noticias con la de publicar noticias en WordPress.
T3. Integrar la funcionalidad de modificar noticias con la de editar noticias en WordPress.
T4. Integrar la funcionalidad de deshabilitar o habilitar noticias con la de deshabilitar o

habilitar noticias en WordPress.
T5. Realizar pruebas.
Con esto se concluye la planificación de la cuarta iteración.

113
T1. Desarrollo de una ruta en la segunda API con las funcionalidades de crear,
modificar y deshabilitar noticias
Para realizar la comunicación con alguna página web en WordPress, se vuelve necesario
hacer uso de la segunda API en Python, puesto que las librerías necesarias para realizar
la respectiva comunicación solo están disponibles para este lenguaje.
En la API ya existente se crea una nueva ruta: wordpress que contendrá todas las
funcionalidades necesarias para crear, modificar y deshabilitar noticias.
En la siguiente tabla se exponen todas las funcionalidades implementadas bajo la ruta,

junto con sus métodos y descripción.
Cuadro N° 3.24
Métodos de la ruta wordpress

/wordpress/publicar POST Pública en la página la
noticia enviada.
/wordpress/modificar/{id} PATCH Modifica la noticia con el ID
enviado.
/wordpress/desactivar/{id} PATCH Desactiva la noticia con el
ID enviado.
/wordpress/activar/{id} PATCH Activa la noticia con el ID
enviado.
T2. Integrar la funcionalidad de crear noticias con la de publicar noticias en

Wordpress
Para realizar la integración con de la funcionalidad de crear noticias con la de publicar

únicamente es necesario crear un servicio que consuma la ruta de wordpress/publicar
cada que en el lado del cliente se cree una nueva noticia. Para ello se crea una nueva
clase “ServiciosNoticias” como se puede apreciar en el siguiente diagrama.
114
Figura N° 3.30
Clase ServiciosNoticias
Está clase nos dará todas las funcionalidades necesarias para publicar, modificar,
deshabilitar o habilitar noticias en un sitio Wordpress.
Entonces, como se había mencionado, para poder integrar con la función de crear
noticias, simplemente se llama a la función publishToWordPress de la clase al momento
de crear una noticia como se muestra en la siguiente figura.
Figura N° 3.31
Código de la funcionalidad de publicar en Wordpress
La captura de código pertenece a la función subirNoticia, función que será llamada

cuando se intente cargar una noticia desde la interfaz. Lo primero que hará la función
115
será llamar a otra función llamada generarNoticia función que se encarga de subir la
noticia al sistema y al terminar regresa el cuerpo de la noticia subida más su Id. Luego
de llamar está función y guardar los valores que regresa, se procede a llamar a la función
publishToWordpress enviando el cuerpo de la noticia ya creada. Por último, pregunta si
la función tuvo una respuesta exitosa, en caso de hacerlo agregará los campos
correspondientes a WordPress al campo de la noticia en la base de datos.
T3. Integrar la funcionalidad de modificar noticias con la de editar noticias en

WordPress
De igual manera que con la tarea previa, para integrar la funcionalidad de modificar
noticias simplemente es necesario llamar a la función updateWordpress de la clase
ServiciosNoticias al momento de editar una noticia ya existente. Se puede observar la
implementación en código en la siguiente figura.
Figura N° 3.32
Implementación en código de editar noticias en Wordpress
La función publicarCambios será llamada al momento de actualizar una noticia y como

se puede ver, lo primero que hará será consumir la función updateWordpress modificando
el contenido de la noticia en la página de WordPress.
T4. Integrar la funcionalidad de deshabilitar noticias con la de deshabilitar noticias

en WordPress
Así como con todas las previas tareas para habilitar o deshabilitar una noticia, bastará
con llamar a la función changeStatusWordpress y enviar como parámetro el estado al
que se quiere cambiar, true para habilitar, false para deshabilitar.
La implementación en código se puede ver en la siguiente figura.

116
Figura N° 3.33
Implementación en código de deshabilitar noticia
En la figura solo se muestra la función para deshabilitar noticia, sin embargo, para
habilitar noticia es el mismo código.
Lo primero que hace la función es crear una venta modal que pedirá por confirmación
sobre si el usuario está seguro de que quiere deshabilitar o habilitar una noticia, en caso
de que respondan sí, se llamará a la función para cambiar el estado, modificando de esta
forma su estatus en la página en WordPress.
T5. Realizar pruebas
Ya realizadas todas las funcionalidades de la iteración se cumplirá con la última tarea:

realizar pruebas. Para ello se realizarán pruebas de caja negra sobre las funciones
descritas en la clase ServiciosNoticias. Los resultados se pueden visualizar en las
siguientes tablas
Cuadro N° 3.25
PRUEBA-07 Mandar una noticia con caracteres

Unicode.
Propósito Ver si la función de publicar noticias puede
publicar de forma correcta noticias con
caracteres Unicode.
117
Prerrequisitos El cuerpo o título de la noticia deben de

contener caracteres Unicode.
Pasos 1. Crear una noticia incluyendo
palabras con acentos en el título o
cuerpo.
noticia.
Resultado esperado Noticia publicada en página de Wordpress
mostrando las palabras con acentos de
forma correcta.
Resultado obtenido Noticia publicada en página de Wordpress
mostrando las palabras con acentos de
forma correcta.
Estado de la prueba Correcto
Cuadro N° 3.26
PRUEBA-08 Publicar una noticia con imágenes, vídeos

o audios.
Propósito Comprobar que se puedan crear noticias
incluyendo contenido de tipo multimedia.
Prerrequisitos El cuerpo de la noticia debe de contener al
menos una imagen, vídeo o audio.
Pasos 1. Crear una noticia incluyendo
archivos multimedia en el cuerpo de
la misma.
noticia.
118
Resultado esperado Noticia publicada en página de Wordpress

mostrando los elementos multimedia
enviados.
Resultado obtenido Noticia publicada en página de Wordpress
mostrando los elementos multimedia
enviados.
3.6.4.3. Pruebas
Se concluye la iteración mediante la realización de pruebas de aceptación de las

funcionalidades desarrolladas.
En la siguiente tabla se muestra el resultado de las pruebas.
Cuadro N° 3.27

Publicar noticias. Aprobada. Ninguna.
Modificar noticias. Aprobada. Ninguna.
Deshabilitar noticias. Aprobada. Ninguna.
Habilitar noticias. Aprobada. Ninguna.
Se llega a la conclusión de que ahora el sistema es capaz de integrarse completamente

con una página web en WordPress permitiendo total comunicación entre la aplicación en
desarrollo y el otro sitio web.
Con la conclusión de está iteración todo lo referente a subir noticias en el sistema está
completo, siendo que la primera iteración se encargó en su totalidad de desarrollo una
red neuronal para identificar y clasificar noticias, la segunda iteración dio al usuario la
119
capacidad de subir noticias únicamente al sistema, con la tercera iteración se logró crear
un explorador de archivos para que el usuario pueda subir archivos multimedia al sistema
y luego usarlos en la creación de noticias.
3.6.5. QUINTA ITERACIÓN
3.6.5.1. Diseño
Se puede apreciar en la siguiente tabla el sprint backlog para esta iteración.
Cuadro N° 3.28

Desarrollar un módulo que permita a los Tareas con los reporteros.
jefes de prensa revisar noticias y dejar
comentarios sobre las mismas a los
reporteros en forma de tareas.
La historia de usuario identificada en el sprint backlog es llevada a su formato en ficha en

la siguiente tabla.
Cuadro N° 3.29
Nombre Tareas para los reporteros.

Descripción Como jefe de prensa
Quiero asignar tareas a los reporteros cuando publiquen
noticias
Para dar retroalimentación instantánea sobre la calidad de
sus publicaciones.
Criterios de - Los jefes de prensa recibirán notificaciones de las
aceptación publicaciones o modificaciones de noticias que hagan
los reporteros.
120
- Cada notificación que tengan los jefes de prensa les

permitirá ver la noticia en la página web de Radio
Compañera.
- Cada notificación que tengan los jefes de prensa les
permitirá dejar tareas al reportero sobre la acción en
la notificación.
Prioridad: Media.
Se procede con la descomposición en tareas de la historia de usuario.
T1. Desarrollar un diagrama de casos de uso de la funcionalidad.
T2. Realizar un incremento del diagrama relacional de la base de datos.
T4. Programar los servicios de la API para la creación y modificación de tareas.
T5. Desarrollar los servicios de WebSockets entre la API y el cliente para notificaciones.
T6. Integrar la funcionalidad de crear, modificar, deshabilitar y habilitar noticias y crear

eventos con el de notificaciones.
T7. Desarrollar las interfaces de los módulos identificados en los casos de uso.
Con esto se concluye la planificación de la quinta iteración.
T1. Desarrollar un diagrama de casos de uso de la funcionalidad
En la siguiente figura se observa el diagrama de casos de uso del módulo de tareas en

las noticias.
121
Figura N° 3.34
Diagrama de casos de uso de tareas en las noticias
Se describirá cada caso de uso y se adjuntará su respectivo mockup.
Lista de tareas asignadas – completar tareas
Cada reportero tendrá una pestaña de tareas en donde podrá observar que tareas se le
fueron asignadas, cada noticia tendrá una cantidad de tareas y cada tarea podrá ser
completada al marcar un checkbox y seleccionado un botón de confirmación. También
se podrá filtrar por estado de noticias, mostrando únicamente las que tienen tareas
pendientes.
Se observa el mockup de este caso de uso en la siguiente figura.

122
Figura N° 3.35
Mockup lista de tareas
Notificaciones de tareas nuevas
Los reporteros contarán con un botón en la parte superior derecha de su pantalla, dicho
botón tendrá la forma de una campana con un número encima, cada que se le asigne
una tarea el número sobre el botón incrementará, al seleccionar el botón se desplegará
un menú con una lista de mensajes, cada mensaje indicará una nueva tarea, además
del mensaje se tendrá un botón para ver la tarea, al ser seleccionado se redirija a la
pestaña de lista de tareas con la noticia seleccionada resaltada.
123
En la siguiente figura se puede apreciar el mockup.
Figura N° 3.36
Mockup de notificaciones a los reporteros
Notificaciones de publicaciones o modificaciones
Al igual que los reporteros, los jefes de prensa contarán con un botón en forma de
campana en la parte superior derecha con un número que indica la cantidad de nuevas
notificaciones, al seleccionar un botón se les desplegará un menú con un listado de
notificaciones indicando una acción de un reportero. Cada notificación tendrá 2 botones,
el primero permitirá revisar la noticia en la página web de Wordpress y el segundo abrirá
una ventana modal para asignar tareas al reportero sobre la acción realizada.
Si la pestaña de notificaciones se encuentra abierta al hacer click en cualquier parte fuera

de la pestaña, está se cerrará.
124
En el siguiente mockup se observa el diseño del listado de notificaciones a los jefes de

prensa.
Figura N° 3.37
Mockup de notificaciones a los jefes de prensa
Asignación de tareas
Como se había mencionado, en la lista de notificaciones de los reporteros por cada

notificación se tendrán 2 botones, uno que abrirá otra página web con una noticia en ella
y otro que abrirá una ventana modal, está ventana tendrá todas las tareas creadas
previamente para una noticia, debajo de la lista se tendrá una caja de texto en la que se
podrá poner el contenido de una nueva tarea y debajo de este 2 botones, uno para
agregar la tarea y otro para confirmar la acción. Si se selecciona el botón de agregar
tarea, la tarea descrita en la caja de texto se añadirá a lista que se encuentra más arriba.
125
Cuando se seleccione el botón de confirmar todas las tareas nuevas que fueron puestas
en la lista se le asignarán al reportero.
En la siguiente figura se aprecia el mockup de la pantalla de creación de tareas.
Figura N° 3.38
Mockup de creación de tareas
Lista de tareas asignadas
Cada jefe de prensa tendrá un apartado semejante al de lista de tareas asignadas de los
reporteros, al igual que este último los jefes de prensa tendrán un listado de noticias con
tareas, la diferencia será que cada item de la lista será como el mockup de asignar tareas
en noticia. También se podrá buscar por el ID del reportero para ver que tareas tiene
asignadas y cuales no se completaron.
Al cada item ser como el mockup de asignar tareas es que mediante la entrada en la lista
se podrá usar exactamente las mismas funcionalidades que se plantean en aquella
pantalla, funcionalidades como agregar tarea o quitar tareas no asignadas.
126
Dado que la lista de tareas podría volver realmente extensa con el pasar del tiempo es
que se incluye paginación de la lista donde se podrá cambiar de número de página en la
lista para desplegar tareas asignadas con mayor antigüedad.
En la siguiente figura se puede apreciar el mockup de está funcionalidad.
Figura N° 3.39
Mockup de lista de tareas asignadas
T2. Realizar un incremento del diagrama relacional de la base de datos
Para realizar el incremento del diagrama relacione de la base de dato se identifican 2

nuevas tablas: evento y tarea. Ambas tablas cumplen una funcionalidad semejante sin
127
embargo la tabla eventos es más general y dedicada a cualquier tipo de interacción en el

sistema, en cambio la tabla tarea está dedicada únicamente a tener tareas en ella.
Se puede observar el diagrama relacional de la base de datos con estás tablas agregadas
en la siguiente figura.
Figura N° 3.40
Diagrama relacional de la base de datos segundo incremento
Fuente: (Elaboración propia, octubre 2022)
Como se había mencionado con anterioridad, para que el ORM que se utiliza en el
proyecto pueda funcionar, es necesario realizar un diagrama de clases que se ajuste al
diagrama entidad relación, convirtiendo los elementos que cada tabla contiene en clases
en donde los campos de las tablas se convierten en atributos de la clase y se agregan
métodos que utilizarán las clases.
128
Es necesario aclarar que si bien las relaciones entre tablas propuestas en el diagrama
entidad relación se deben mantener no necesariamente se respetan las mismas reglas
que se siguen en el esquema entidad relación, por ende, el tipo de relación podría verse
alterado en el diagrama.
En la siguiente figura se procede a mostrar el segundo incremento del diagrama de clases

creado a partir del diagrama entidad relación.
Figura N° 3.41
Diagrama de clases segundo incremento
T4. Programar los servicios de la API para la creación y modificación de tareas
Por el lado de la API, para realizar las operaciones básicas en el apartado de tareas se
crea una ruta: tareas. En la siguiente tabla se muestran los métodos y las descripciones
de cada funcionalidad bajo esta ruta creada.
129
Cuadro N° 3.30
Métodos de la ruta tarea

/tareas/ GET Regresa todas las tareas.
/tareas/{id_tarea} GET Regresa la tarea con el id
enviado.
/tareas/reportero/{id_reportero} GET Regresa todas las tareas
asignadas al reportero
con la id enviada.
/tareas/noticias/{id_noticia} GET Regresa todas las
noticias que tiene la
noticia con el id enviado.
/tareas/ POST Crea todas las tareas
enviadas.
/check/ PATCH Cambia el estado de las
tareas a completado para
todas las tareas enviadas.
T5. Desarrollar los servicios de WebSockets entre la API y el cliente para

notificaciones
Como tal resulta complejo explicar o diagramar el funcionamiento de WebSockets en una

aplicación, aun así, dada la naturaleza basada en estados de los WebSockets una buena
forma de representarlos sería con un diagrama de máquina de estados, donde cada
evento que escuchan los sockets es un estado.
En la siguiente figura se puede ver este diagrama de máquina de estados.

130
Figura N° 3.42
Diagrama de máquina de estados para los WebSockets
Como se puede observar en el diagrama todo empieza en el estado conexión, en caso

de que no existan problemas con la conexión se pasará al estado de escuchar eventos,
caso contrario se termina la conexión. Dentro del estado de escuchar eventos pueden
existir varios posibles gatilladores para pasar a uno u otro estado, esto se realiza de
manera concurrente. Cuando desde el cliente se emite un nuevo evento este es
escuchado por el servidor y pasa al estado con el nombre del evento emito desde el
cliente. Ya una vez en el nuevo estado no durará mucho, cada estado se encargará de
cargar información en la base de datos y emitir un evento para informar a demás sockets
escuchando en otros clientes, luego de eso regresará al estado de escuchar eventos.
Finalmente, cuando se produzca el evento de disconnect se terminará la conexión.
Es necesario comprender que este diagrama estará presente tanto en el servidor como
en todos los dispositivos conectados al mismo.
131
T6. Integrar la funcionalidad de crear, modificar, deshabilitar y habilitar noticias y

crear tareas con el de notificaciones
La integración no será compleja puesto que basta con crear funciones de web sockets
que se encarguen de escuchar eventos y sean llamadas cada que se cree o modifique
una noticia.
En la siguiente figura se aprecia la primera implementación de los web sockets.
Figura N° 3.43
Implementación de los estados conexión y escuchar eventos
Como se observa en la figura, existirá un objeto socket y lo primero que hará será emitir
el evento conexión para pasar al estado de escuchar eventos, luego se llamará al método
listen y se le pasará el nombre del evento que escuchará.
Finalmente, para concluir con la integración faltaría la parte de no solo escuchar los
eventos, si no emitir lo eventos para que los demás clientes con la misma implementación
los escuchen.
Para conseguir esto es necesario emitir un evento cada que se realice una de las
acciones descrita en la tarea, para simplificar esto se crean las 2 siguientes funciones.
132
Figura N° 3.44
Funciones para emitir eventos
Como se puede observar en la última figura está la función de registrarEvento que recibirá
un evento, luego registrará el evento en la base de datos y llamará a una función para
mandar este evento a todos los clientes que estén escuchando.
Estás 2 funciones estarán dentro de una clase servicioDeEventos y serán llamadas en

cada una de las funcionalidades que pide la tarea. Para demostrarlo en la siguiente figura
se observa un fragmento del código de crear noticia.
Figura N° 3.45
Código de crear noticia
Como se puede observar en la figura, primero se creará un objeto de tipo evento que
tenga como atributos: el id del reportero que, generado el evento, seguido del tipo de
evento, la criticidad del mismo, una descripción del evento, la fecha en la que sucede el
evento y por último, el id que tendrá la publicación en el servicio de wordpress y el id de
133
la noticia. Seguidamente se llamará a la función registrar evento ya descrita y se pasará

como único parámetro el evento ya creado anteriormente.
De esta forma se consigue realizar una integración de las funcionalidades de crear,

modificar, deshabilitar y habilitar noticias y crear eventos con la funcionalidad de
notificaciones haciendo uso de web sockets.
Cabe aclarar que por la naturaleza de los web sockets cualquier creación o modificación
de una publicación será en tiempo real, por lo que al momento de ocurrir cualquiera de
estos eventos los jefes de prensa serán notificados en ese mismo momento.
T7. Desarrollar las interfaces de los módulos identificados en los casos de uso
En los casos de uso presentados se presentaron 5 mockups, se procede a mostrar las

interfaces ya codificadas de cada uno en las siguientes figuras.
Figura N° 3.46
Interfaz de lista de tareas

134
Figura N° 3.47
Interfaz de notificaciones de tareas nuevas
Figura N° 3.48
Interfaz de notificaciones de publicaciones o modificaciones

135
Figura N° 3.49
Interfaz de asignación de tareas
Figura N° 3.50
Interfaz de lista de tareas asignadas
Se realizan pruebas de caja negra a las funcionalidades desarrolladas y se exponen los

resultados en las siguientes tablas.
136
Cuadro N° 3.31
PRUEBA-09 Intentar crear una tarea con campos

vacíos.
Propósito Comprobar si el input de creación de
tareas cuenta con las validaciones de
campos nulos.
Prerrequisitos El input de creación de tareas debe de
estar vacío.
Pasos 1. Seleccionar el botón de agregar
noticia.
Resultado esperado Ninguna noticia es agregada.
Resultado obtenido Ninguna noticia es agregada.
3.6.5.3. Pruebas
Para concluir con la quinta iteración, se realizan pruebas de aceptación de las

funcionalidades desarrolladas con el cliente. Los resultados se exponen en las siguientes
tablas.
Cuadro N° 3.32

Completar tareas Correcto Ninguna
Lista de tareas asignadas Correcto Ninguna
Notificaciones de nuevas Correcto El tipo de letra de las
tareas notificaciones debería ser
más pequeño.
Asignación de tareas Correcto Ninguna
Lista de tareas creadas Correcto Ninguna
137
Notificaciones de Correcto El tipo de letra de las

publicaciones o notificaciones debería ser
modificaciones. más pequeño.
Se llega a la conclusión de que el módulo o funcionalidad de tareas para los reporteros

ha sido desarrollado con éxito.
Con está iteración también se consiguió terminar con la creación de la base de datos,
entregando en esta iteración la versión final del esquema relacional del cual deriva la
base de datos cumpliendo de esta forma el tercer objetivo específico propuesto en el
punto 1.4.2. Objetivos específicos.
3.6.6. SEXTA ITERACIÓN
3.6.6.1. Diseño
En la siguiente tabla se puede apreciar el sprint backlog para esta iteración.
Cuadro N° 3.33

Desarrollar el módulo de registro de Creación de cuentas.
usuario y un login de usuario.
La historia de usuario identificada en el sprint backlog es llevada a su formato en ficha en

la siguiente tabla.
138
Cuadro N° 3.34
Nombre Creación de cuentas.

Descripción Como jefe de prensa
Quiero crear nuevas cuentas para los reporteros
Para agregar más trabajadores al sistema
Criterios de - Solo los jefes de prensa podrán crear reporteros.
aceptación - Cada reportero tendrá ci, nombre, apellido, sexo, rol y
correo.
- Al crear un reportero se le enviará una contraseña a
su correo.
- El correo enviado con la contraseña deberá tener
estilo más haya de solo indicar la contraseña.
- Las cuentas de reporteros deben poder ser
deshabilitadas.
- Los reporteros podrán acceder al sistema mediante
una pantalla de login
- Las cuentas deshabilitadas no podrán iniciar sesión.
- Las cuentas creadas podrán ser modificadas.
- El campo de CI no podrá ser editado.
Prioridad: Baja.
Se procede con la descomposición en tareas de la historia de usuario.
T1. Desarrollar un diagrama de casos de uso de la funcionalidad.
T2. Programar los servicios de la API para la creación y modificación de usuarios.
T3. Programar un servicio de JSON Web Tokens.
T4. Programar los guardianes de rutas de la aplicación.

139
T5. Desarrollar las interfaces de los mockups identificados en los casos de uso.
T6. Realizar pruebas.
Con esto concluye la planificación de la sexta iteración.
3.6.6.2 Codificación
T1. Desarrollar un diagrama de casos de uso de la funcionalidad
En la siguiente figura se puede observar el diagrama de casos de uso.
Figura N° 3.51
Diagrama de casos de uso de creación de cuentas
Se describirá cada caso de uso y se adjuntará su respectivo mockup, en caso de que un

mockup ocupe múltiples casos de uso, se agruparán.
140
Listado de cuentas
El listado de cuentas será una pestaña que tendrán los jefes de prensa, cada item de la
lista tendrá el ci del reportero, sus nombres y apellidos, su cargo y su estado (si se
encuentra deshabilitada o habilitada) además de tener un menú contextual que al abrirlo
dará las opciones para desactivar o activar un reportero y editar su cuenta. También se
contará con una paginación para poder ver entradas de la lista más antiguas.
El mockup para está funcionalidad se puede observar en la siguiente figura.
Figura N° 3.52
Mockup listado de cuentas
Creación de cuentas de usuario – Modificación de cuentas de usuario
El mockup de está funcionalidad puede verse en la siguiente figura.

141
Figura N° 3.53
Mockup creación de cuenta de usuario
Las funcionalidades de creación de cuenta de usuario y la modificación de estas son

semejantes, al seleccionar ya sea el botón de agregar usuario o el de editar usuario, se
abrirá una pestaña de forma modal con los campos a completar.
En caso de querer modificar un usuario los campos ya estarán completos con la diferencia
de que el ci y sexo no podrán ser modificados. Cuando se seleccione el botón de agregar
usuario saltará una ventana de confirmación y un mensaje indicando que la contraseña
del sistema se mandará al correo electrónico especificado.
Login de usuario
El login de usuario contará con dos inputs pidiendo el ci del reportero y su contraseña y
un botón para ingresar al sistema. En caso de que las credenciales fallen tendrá un
mensaje en la parte superior indicando el error.
Se puede observar el mockup en la siguiente figura.

142
Figura N° 3.54
Mockup login de usuario
T2. Programar los servicios de la API para la creación y modificación de usuarios
Para realizar las operaciones básicas de creación y modificación de usuarios se crea una
ruta: usuarios en la API. En la siguiente tabla se muestran los métodos y las descripciones
de cada funcionalidad bajo esta ruta creada.
Cuadro N° 3.35
Rutas para la creación y modificación de usuarios

/usuarios/ GET Regresa todos los usuarios
registrados.
/usuarios/{id_usuario} GET Retorna el usuario con la id
enviada.
143
/usuarios/ POST Sube el usuario enviado a

la base de datos.
/usuarios/{id_usuario} PATCH Modificar el usuario con la
id enviada.
/usuarios/login POST Logea al usuario enviado.
/usuarios/logout POST Deslogea al usuario
enviado.
/usuarios/validate POST Valida que el token enviado
aun sea válido.
T3. Programar un servicio de JSON Web Tokens
Para utilizar JWT en la aplicación cuando un usuario tenga un login satisfactorio el

servidor generará una cadena de texto cifrada mediante RSA teniendo como clave
pública los datos de autenticación del usuario y como llave privada una cadena de texto
alojada en el servidor.
En la siguiente figura se observa un ejemplo de JWT.
Figura N° 3.55
Ejemplo de JWT
Como se observa, el texto es totalmente inentendible y hasta parece aleatorio, pero oculta
lo que es un JSON con las credenciales de autenticación del usuario. Cada JWT tendrá
un tiempo de expiración de 20 minutos, pasado ese tiempo el token expira y deja de ser
valido.
144
T4. Programar los guardianes de rutas de la aplicación
Se implementará dos guardianes de rutas, uno en las rutas de la aplicación cliente y otra
en las rutas de la primera API.
Para implementar un guardián de rutas en Angular se genera un archivo llamado guard

que contendrá 2 funciones: canActivate y canActivateChild. Las dos funciones cumplirán
exactamente el mismo papel de validar si el token que posee el usuario es válido. En
caso de ser válido, el usuario podrá navegar por las rutas de la aplicación de manera
normal, caso contrario será llevado a la pantalla de login.
En la siguiente figura se muestra el código de los guardianes.
Figura N° 3.56
Código de guardianes de rutas lado cliente
Para implementar ambas funciones dentro de Angular existe un archivo denominado

como routing encargado de todas las rutas en la aplicación, entonces para hacer uso de
145
los guardianes basta con invocarlos en este archivo como se observa en la siguiente
figura.
Figura N° 3.57
Archivo de rutas de la aplicación
El archivo contiene todas las rutas de la aplicación. En la parte inferior se le da el valor

de VigilanteGuard a las claves de canActivate y canActiavteChild esto invocará a las
funciones previamente señaladas cada que se intente cargar una nueva ruta.
Para implementar un guardia en el servidor de igual manera se crea una función:

validateHandler que recibirá un JWT y lo validará, en caso de que la validación falle no
se mostrará la ruta y en su lugar se mostrará el mensaje de acceso denegado. Está
función será llamada cada que se realice una petición a cualquiera de los métodos en
cualquiera de las rutas dentro de la REST API.
La implementación de la función en código se observa en la siguiente figura.

146
Figura N° 3.58
Guardian de rutas en servidor
Está función será llamada cada que se realice una petición al servidor. En la siguiente
figura se muestra que ocurriría en caso de no tener una credencial valida.
Figura N° 3.59
Mensaje de error en el servidor por JWT invalido

147
T5. Desarrollar las interfaces de los mockups identificados en los casos de uso
En los casos de uso se identificaron 3 mockups, se procede a codificar cada uno de ellos.
Figura N° 3.60
Interfaz de lista de usuarios registrados
Figura N° 3.61
Interfaz de creación - modificación de cuentas de usuario

148
Figura N° 3.62
Interfaz de login de usuario
T6. Realizar pruebas
Para la última tarea de la iteración se realizarán pruebas a las funcionalidades

desarrolladas. Se exponen los resultados en las siguientes tablas.
149
Cuadro N° 3.36
PRUEBA-10 Crear un usuario con números en los

apartados de nombres y apellidos.
Propósito Comprobar si los inputs de nombres y
apellidos de usuario cuentan con las
suficientes validaciones.
Prerrequisitos El input de creación de tareas debe de
estar vacío.
Pasos 1. Acceder a la pestaña de creación
de usuario.
2. Completar los campos de nombres
y apellidos con nombres que
contengan números.
3. Seleccionar el botón de crear.
Resultado esperado Se señalan los campos y se indica que
tienen valores inválidos.
Resultado obtenido Se señalan los campos y se indica que
Cuadro N° 3.37
PRUEBA-11 Crear un usuario con campos incompletos

Propósito Comprobar si los inputs de creación de
usuarios tienen validación contra campos
nulos.
Prerrequisitos Por lo menos un input debe de está vacío.
150
Pasos 1. Acceder a la pestaña de creación

de usuario.
2. Completar los campos dejando por
lo menos 1 campo vacío.
3. Seleccionar el botón de crear.
Resultado esperado Se señalan los campos y se indica que
Resultado obtenido Se señalan los campos y se indica que
Cuadro N° 3.38
Prueba de caja negra # 12
PRUEBA-12 Login fallido de usuario.

Propósito Comprobar si el login válida las
credenciales.
Prerrequisitos Todos los campos deben de estar
completos con credenciales incorrectas.
Pasos 1. Acceder a la login.
2. Completar los campos.
3. Seleccionar el botón de ingresar.
Resultado esperado Mensaje indicando credenciales
incorrectas.
Resultado obtenido Mensaje indicando credenciales
incorrectas.
3.6.6.3. Pruebas
Se concluye la iteración realizando pruebas de aceptación de las funcionalidades. Los

resultados se exponen en la siguiente tabla.
151
Cuadro N° 3.39
Funcionalidad Estado Observaciones

Crear cuentas de usuario Aprobado Ninguna
Modificar cuentas de Aprobado Ninguna
usuario
Lista de cuentas de Aprobado Ninguna
usuarios
Login de usuario Aprobado Ninguna
Se llega a la conclusión de que el módulo o funcionalidad de creación de cuenta ha sido

desarrollado con éxito.
Es con está iteración que se concluye el desarrollo del sistema, logrando el cumplimiento
del penúltimo objetivo específico de generar incrementos del sistema web en base a
iteraciones.
3.7. PRUEBAS INTEGRALES
3.7.1. PRUEBAS DE ACEPTACIÓN
Para finalizar con el desarrollo de la aplicación y en una etapa previa a una posible
implementación, se llevará a cabo lo que son las pruebas de aceptación finales con un
jefe de prensa del departamento de prensa de Radio Compañera. Para esto se evalúa la
totalidad del software revisando el resultado de todas las iteraciones. En la siguiente tabla
se muestra el resultado de las pruebas. 3.4.8. pruebas de aceptación, demás pruebas de
calidad.
152
Cuadro N° 3.40
Pruebas de aceptación de la totalidad del sistema
Nro. Iteración Funcionalidad Observaciones

Iteración 1 Clasificación de noticias. La categoría auto generada
debería poder ser cambiada
si así se quisiera.
Iteración 2 Publicación de noticias. La noticia no necesariamente
debe de ser aprobada por el
jefe de prensa para que esta
sea subida a plataforma. La
revisión y correcciones se
pueden hacer después.
Iteración 3 Cuaderno de noticias. Sin observaciones.
Iteración 4 Comunicación con Sin observaciones.
Wordpress.
Iteración 5 Tareas para los No es necesario que se les
reporteros. envíe una notificación a los
jefes de prensa cada que
completen tareas
individuales.
Iteración 6 Creación de cuentas. No debería existir un tiempo
límite que el usuario tenga
dentro del sistema.
También se incluye en el anexo B un informe de conformidad del caso de estudio.
3.7.2. CRITERIOS DE CALIDAD DE SOFTWARE
Son dos los criterios de calidad de software que se utilizaran en base a la ISO/IEC 25010:
no repudio y modularidad.
153
No repudio
Para demostrar el cumplimiento del criterio de no repudio, por un lado, el sistema aplica
mecanismos de autentificación mediante una pantalla de login desarrollada en la sexta y
última iteración (Ver punto 3.4.7.1.) para asegurar que un usuario de la aplicación es
quien asegura ser. Por otro lado, se aplican criterios de identificación al cada usuario del
sistema contar con una credencial única que los identifiqué en el sistema, el carnet de
identidad.
Modularidad
Las API 2 REST programadas a lo largo del proyecto siguen una arquitectura modular
compuesta por servicios, en donde cada ruta llama a un servicio y cada servicio puede
ser considerado un subsistema independiente del resto de la aplicación, por lo cual, si
cualquiera de estos subsistemas fallase, la aplicación continuaría funcionando,
cumpliendo de esa forma el criterio de modularidad.
Es importante recalcar el hecho de que, si bien la aplicación web también funciona de

manera modular, no lo hace a la escala de las APIs REST implementadas dado que es
de suma importancia que, si un servicio de la API falle por algún motivo o se deba realizar
algún cambio a esa funcionalidad, no se detenga todo el servidor inhabilitando el uso total
de la aplicación tanto en lado de cliente como en lado de servidor, con la implementación
de modularidad en las APIs REST si fallase algún servicio o se tuviera que modificar una
parte, la aplicación podría seguir funcionando.
Para demostrar la implementación de este criterio de calidad, en los 2 siguientes

diagramas de componentes se observa la arquitectura final de ambas API REST.
154
Figura N° 3.63
Arqutectura de la API REST en NodeJS
Figura N° 3.64
Arquitectura de la API REST en Flask
3.7.3. DEMOSTRACIÓN DEL INCREMENTO DE LA EFICIENCIA
Finalmente se concluye recalculando la fórmula propuesta en el punto 1.2.1.

Identificación del problema para comprobar si la eficiencia de la difusión informativa se
155
ha visto incrementada. Para esto se considera una mejor de los valores iniciales de un
40%.
Se recuerda que la fórmula para medir la eficiencia es la siguiente:

Antes de realizar el cálculo de la fórmula, se aclara que los resultados iniciales ya fueron
calculados en el punto 1.2.1. Identificación del problema.
Se procede con el cálculo de la fórmula.
Resultados alcanzados inicial = 1500.
Coste actividad inicial = 3750.
Tiempo empleado inicial = 33750.
Resultados alcanzados = 2100 (el valor de resultados alcanzados inicial más la mejora
estimada del sistema del 40%).
Coste actividad = 2250 (el valor del coste actividad inicial menos la mejora estimada del
sistema del 40%).
Tiempo empleado = 27000 (el valor del tiempo inicial menos la mejora estimada del
sistema del 40%).
Resultados previstos = 1875 (El valor de resultados alcanzados inicial más un 25% de la
mejora prevista por Radio Compañera).
Costes previstos = 2812.5 (El valor de coste de actividad inicial menos un 25% de la
mejora prevista por Radio Compañera).
Tiempo previsto = 33750 (El valor de tiempo empleado inicial menos un 25% de la mejora
prevista por Radio Compañera).
Remplazando los valores y calculando:
2100 1875
( ∗ 27000) / ( ∗ 33750) = 1.12
2250 2812.5
156
Comparando con el resultado anterior de 0.8 se puede apreciar como el valor de la

eficiencia incremento hasta llegar a un valor superior a la unidad, indicando no solamente
un aumento de este, sino que también, según la fórmula ahora la difusión informativa en
el departamento de prensa de radio compañera es muy eficiente.
3.8. ESTIMACIÓN DE COSTOS DE SOFTWARE
Ya concluidas todas las iteraciones, se procede a realizar la estimación de costos para

concluir con el proyecto.
3.8.1. COCOMO II
El presente proyecto cuenta con menos de 50000 líneas de código, entonces se hará
uso del modo orgánico según COMO II. Según este modo las constantes tomarán los
siguientes valores:
Tabla N° 3.1
Constantes según el modo
Proyecto a e c d
Software
Orgánico 2,4 1,05 2,5 0,38
Semi-acoplado 3,0 1,12 2,5 0,35
Empotrado 3,6 1,20 2,5 0,32
Fuente: Cocomo II, 2009
Después, en la siguiente tabla se mostrará en la cantidad de líneas de código utilizadas

en base al tipo de lenguaje de programación utilizado.
Tabla N° 3.2
Líneas de código empleadas
Componente Cantidad líneas de código

Aplicación Web 14740
API Node JS 1418
API Python 366
Total líneas de código 16524 LDC
El total de líneas de código ahora deben de expresarse en KLDC, para conseguir esto se
aplica la siguiente operación:
157
𝐾𝐿𝐷𝐶 = 16524/1000
𝐾𝐿𝐷𝐶 = 16.524
Ya con estos datos se puede realizar la primera ecuación de esfuerzo nominal.
𝐸𝑠𝑓𝑢𝑒𝑟𝑧𝑜 = 2.4 ∗ (16.524)1.05[𝑝𝑒𝑟𝑠𝑜𝑛𝑎/𝑚𝑒𝑠]
𝐸𝑠𝑓𝑢𝑒𝑟𝑧𝑜 = 2.04[𝑝𝑒𝑟𝑠𝑜𝑛𝑎/𝑚𝑒𝑠]
Ya con el esfuerzo nominal calculado, se procede a calcular el Factor Multiplicador o FA

considerando distintas características del software, el grupo de desarrollo y las
herramientas utilizadas para el desarrollo. Para poder calcular este valor se recurre a la
siguiente tabla. Los atributos que encajen con el sistema serán resaltados en color.
Tabla N° 3.3
Factor multiplicador
Valor
Atributos
Muy bajo Bajo Nominal Alto Muy alto Extra alto
Atributos de software
Fiabilidad 0,75 0,88 1,00 1,15 1,40
Tamaño de Base de datos 0,94 1,00 1,08 1,16
Complejidad 0,70 0,85 1,00 1,15 1,30 1,65
Atributos de hardware
Restricciones de tiempo de ejecución 1,00 1,11 1,30 1,66
Restricciones de memoria virtual 1,00 1,06 1,21 1,56
Volatilidad de la máquina virtual 0,87 1,00 1,15 1,30
Tiempo de respuesta 0,87 1,00 1,07 1,15
Atributos de personal
Capacidad de análisis 1,46 1,19 1,00 0,86 0,71
Experiencia en la aplicación 1,29 1,13 1,00 0,91 0,82
Calidad de los programadores 1,42 1,17 1,00 0,86 0,70
Experiencia en la máquina virtual 1,21 1,10 1,00 0,90
Experiencia en el lenguaje 1,14 1,07 1,00 0,95
Atributos del proyecto
Técnicas actualizadas de programación 1,24 1,10 1,00 0,91 0,82
Utilización de herramientas de software 1,24 1,10 1,00 0,91 0,83
Restricciones de tiempo de desarrollo 1,22 1,08 1,00 1,04 1,10
Fuente: Cocomo II, 2009
Con dichos valores ya especificados, se procede a calcular FA.
𝐹𝐴 = 0.88 ∗ 1 ∗ 1.15 ∗ 1 ∗ 1 ∗ 1 ∗ 0.87 ∗ 1 ∗ 0.82 ∗ 0.86 ∗ 1 ∗ 0.95 ∗ 0.82 ∗ 0.83 ∗ 1.10

158
𝐹𝐴 = 0.51
Ya con este dato se realiza la segunda ecuación de esfuerzo estimado.

𝐸𝑠𝑓𝑢𝑒𝑟𝑧𝑜 𝐸𝑠𝑡𝑖𝑚𝑎𝑑𝑜 = 2.04 ∗ 0.51[𝑝𝑒𝑟𝑠𝑜𝑛𝑎/𝑚𝑒𝑠]
𝐸𝑠𝑓𝑢𝑒𝑟𝑧𝑜 𝐸𝑠𝑡𝑖𝑚𝑎𝑑𝑜 = 1.0404[𝑝𝑒𝑟𝑠𝑜𝑛𝑎/𝑚𝑒𝑠]
Luego se realiza la tercera ecuación de tiempo de desarrollo.
𝑇𝑖𝑒𝑚𝑝𝑜 = 2.5 ∗ (1.0404)0.38 [𝑚𝑒𝑠𝑒𝑠]
𝑇𝑖𝑒𝑚𝑝𝑜 = 2.53 [𝑚𝑒𝑠𝑒𝑠] 𝑜 3 𝑚𝑒𝑠𝑒𝑠
Se realiza la cuarta ecuación para calcular el número de personas.
𝑃𝑒𝑟𝑠𝑜𝑛𝑎𝑠 = (2.04/2.53)[𝑝𝑒𝑟𝑠𝑜𝑛𝑎𝑠]
𝑃𝑒𝑟𝑠𝑜𝑛𝑎𝑠 = 2.015[𝑝𝑒𝑟𝑠𝑜𝑛𝑎𝑠] 𝑜 2 𝑝𝑒𝑟𝑠𝑜𝑛𝑎𝑠
La cantidad de recurso humano que se requiere para desarrollar el sistema es de 2.015.
Ya con todos los datos obtenidos se puede calcular el coste monetario considerando un
salario mínimo profesional en Bolivia de 3500Bs.
𝑐𝑜𝑠𝑡𝑜𝑀 = 2 ∗ 3500 ∗ 2.53
𝑐𝑜𝑠𝑡𝑜𝑀 = 17710
Entonces se llega a la conclusión de que el costo final del Software es de 17710Bs.
3.8.2. COSTOS OPERATIVOS
Para la parte de costos operativos del sistema se cubrirá el costo que tomará la
implementación del software, realizando la cotización de tanto un dominio bajo el cual
estará la aplicación y el costo de un servicio de hosting que almacenará la aplicación.
Por la parte del dominio web se realiza la cotización del dominio: radiocompanera.net en
la página web: donweb.com y este arroja un resultado de 12.57 dólares al año,
convirtiendo en bolivianos da como resultado 83.83 bolivianos al año por el dominio wen.
Posterior a esto se realiza la cotización del hosting para tanto la aplicación web en
Angular como para las API REST en NodeJS y Flask. El hosting elegido para esto es
Vercel una plataforma de alojamiento de aplicaciones web. Esta ofrece diferentes
soluciones entre gratuitas y personalizadas, sin embargo, la solución que será utilizada
159
será el plan profesional que ofrece hasta 1 terabyte de ancha de banda y 50 gigas de
almacenamiento para múltiples soluciones. Dicha solución tiene un costo de 20 dólares
al mes, por lo que en un año el costo sería de 240 dólares en un año o 1661.69 bolivianos
al año.
La solución cotizada en el servicio de hosting es un servicio PaaS 16 por ende se

encargarán del manejo de la infraestructura y el mantenimiento de esta sin coste
adicional.
Se llega a la conclusión de que los costes operativos serán de 1745.52 bolivianos al año.
16
Plataform as Service (plataforma como servicio) entorno de desarrollo e implementación completo en la
nube.
160
CONCLUSIONES
Como conclusión se menciona que el sistema elaborado incrementó la eficiencia de la
difusión informativa de forma exitosa en el departamento de prensa de Radio Compañera,
además de haber cumplido con los objetivos planteados del proyecto.
• Para realizar la recopilación de noticias que fueron utilizadas para entrenar un

modelo de machine learning se realizaron técnicas de web scraping que
permitieron generar un conjunto de datos con un volumen de información de más
de 40,000 noticias, el web scraping permitió que este proceso fuera rápido e
integro al mantener las noticias recopiladas sin cambios ni alteraciones.
• Durante todas las fases del proceso KDD se seleccionó, diseñó y desarrolló una
red neuronal recurrente de tipo LSTM y durante la fase de validación del mismo
proceso se validó que la red neuronal tenga la capacidad de clasificar notas
informativas al predecir con una precisión mayor al 70% la categoría de la noticia
proporcionada.
• A lo largo del desarrollo del sistema, en cada iteración, se fue desarrollando e
incrementando un esquema relacional a partir del cual se desarrolló una base de
datos hasta su finalización en donde la misma permitió almacenar datos
garantizando persistencia, integridad, seguridad y disponibilidad.
• Todo el proyecto fue realizado a lo largo de 6 iteraciones con una duración de 2
semanas cada una, siendo que en cada iteración se desarrolló un incremento
funcional del sistema, validando que se cumplan con los requisitos del cliente al
final de cada incremento.
• Ya finalizado el proyecto, se realizó una prueba de aceptación de la totalidad de
este con el cliente para finalmente demostrar la satisfacción de este. El resultado
de la prueba integral resultó exitoso, concluyendo que el sistema cuenta con la
conformidad del cliente.
Finalmente, se llega a la conclusión de que todos los objetivos específicos se

cumplieron, por ende, el objetivo general de desarrollar un sistema de información
web aplicando redes neuronales recurrentes LSTM para incrementar la eficiencia de
la difusión informativa en el departamento de prensa de Radio Compañera se cumplió.
161
RECOMENDACIONES
Se recomienda explorar en nuevas técnicas de web scrapping como ser web
crawling para ampliar la gama de páginas web que pueden ser utilizadas para
recopilar notas informativas.
Se recomienda utilizar otras librerías para realizar peticiones HTTP a páginas en las
que se quiera realizar web scrapping como ser urllib3 en Python para prevenir
códigos de error 403.
Se recomienda explorar en otros modelos de deep learning más actuales con la

capacidad de procesar y clasificar secuencias y lenguaje natural como ser redes
transformers.
Investigar en el modelo de lenguaje de Presentación de Codificador Bidireccional de

Transformadores BERT para realizar procesamiento de lenguaje natural aplicando
redes neuronales transformers.
Completar las funcionalidades del sistema para que se adapten mejor a un ambiente
móvil para poder hacer uso de la cámara de los dispositivos y así obtener y difundir
la nota informativa de manera aún más eficaz.
Se recomienda continuar con la investigación sobre periodismo digital partiendo de

las técnicas empleadas en este proyecto con los recursos empleados para poder
avanzar a tecnologías de reconocimiento de texto mucho más complejas adaptadas
al entorno nacional.
162
REFERENCIAS BIBLIOGRÁFICAS
LIBROS
Aguilar, L. J., & Zahonero Martínez, I. (2014). En Programación en C, C++, Java y UML.
México.
Beck, K. (2004). Extreme programming explained: embrace change.
Burkov, A. (2019). The Hundred-Page Machine Learning Book.
Fayyad, U., Piatetsky-Shapiro, G., & Smyth, P. (2005). From Data Mining to Knowledge
Discovery in Databases. AI Magazine Volume 17.
Gómez, A. (2010). Cocomo un modelo de estimación de proyectos de software.
Hernández-Sampieri, R., & Mendoza Torres, C. P. (2018). Metodología de la

investigación: Las rutas cuantitativa, cualitativa y mixta.
Jahn, O. (2019). La inteligencia artificial en el periodismo y su uso en los ejemplos de

Reuters y AP. Pagra, Chequia.
Ken Auer, R. M. (2002). Extreme Programming Applied: Playing to Win. Addison-Wesley.
Menzinsk, A., Palacio, J., Sobrino, M. Á., & Alvarez, R. (2022). Historias de usuario -
Ingenieria de requisitos ágil.
Pérez, O. A. (2011). Cuatro enfoques metodológicos para el desarrollo de Software RUP

- MSF - XP - SCRUM.
Rehim, A. A. (2019). Explorando funciones interactivas en artículos generador

automáticamente a travéz de visualización de artículos. Malmö, Suecia.
Seppe vanden Broucke, B. B. (2018). Practical Web Scraping for Data Science. Best
Practices and Examples with Python. Apress.
Tamayo, J. G. (2019). Narrativas Periodisticas y Bases de datos: Conflictos, Puntos de

Encuentro e Implicaciones. Bogotá, Colombia.
Usama Fayyad, G. P.-S. (1996). From Data Mining to Knowledge Discovery in Databases.
163
PÁGINAS WEB
ISO25000. (2022). ISO/IEC 25010. Obtenido de: https://iso25000.com/index.php/normas-

iso-25000/iso-25010 10/12/22.
Agile Alliance. (2022). Extreme Programming. Obtenido de Agile Alliance:

https://www.agilealliance.org/glossary/xp/ 10/10/22.
Brush, K. Desarrollo de software ágil o Agile. (2022). Obtenido de computerweekly:

https://www.computerweekly.com/es/definicion/Desarrollo-de-software-agil-o-Agile
10/01/22.
Real Academia Española. (2022). Definición de eficiencia RAE. Obtenido de RAE:

https://dle.rae.es/eficiencia 25/10/22.
InteractiveChaos. (2022). Diseño de una red neuronal. Obtenido de InteractiveChaos:

https://interactivechaos.com/es/manual/diseno-de-una-red-neuronal 10/12/22.
JWT. (2022). Introduction to JSON Web Tokens. Obtenido de jwt.io:

https://jwt.io/introduction 29/10/22.
Kionet Works. (2022). Qué son y para qué sirven los protocolos de comunicación de
redes. Obtenido de Kionet Works: https://www.kionetworks.com/blog/data-
center/protocolos-de-comunicación-de-redes 16/10/22.
MDN Web Docs. (2022). HTML: Lenguaje de etiquetas de hipertexto. Obtenido de

https://developer.mozilla.org/es/docs/Web/HTML 16/10/22.
Red Hat. (2022). What is a REST API. Obtenido de Red Hat:

https://www.redhat.com/es/topics/api/what-is-a-rest-api 08/05/22.
Scrum.org. (2022). What is a product backlog. Obtenido de Scrum.org:

https://www.scrum.org/resources/what-is-a-product-backlog 18/10/22.
Valdés, D. P. (2007). Que son las bases de datos. Obtenido de

www.maestrosdelweb.com/que-son-las-bases-de-datos/ 26/10/07.
164
Wells, D. (2022). Extreme Programming: A gentle introduction. Obtenido de

http://www.extremeprogramming.org/ 8/4/22.
Wordpress. (2022). Wordpress. Obtenido de Wordpress: https://es.wordpress.org/

10/12/22.
165
GLOSARIO DE TÉRMINOS
Accuracy Score. Métrica que indica el rendimiento de un modelo de Machine Learning

describiendo el radio de predicciones correctas sobre las predicciones totales.
API. Interfaz entre dos sistemas informáticos utilizada para intercambiar información de
manera segura mediante protocolos de Internet.
Back End. Apartado de una aplicación que los usuarios no ven ni interactúan con. Es la
parte encargada de procesar la información recibida del Front End, conectarse con la
base de datos y en base a ello brindar una respuesta al cliente.
Front End. Apartado de una aplicación que está en plena interacción con el usuario. Se
encarga de recibir datos o información proveniente de los usuarios para ser enviada al
Back End y al recibir una respuesta, mostrarla.
HTML. Lenguaje Marcado de Hipertexto. Lenguaje basado en tags usado universalmente

para elaborar el cuerpo de páginas web.
JavaScript. Lenguaje de programación utilizado para desarrollar páginas web dinámicas

en conjunto con HTML.
PostgresSQL. Gestor de bases de datos relacionales y orientadas a objetos.
Python. Lenguaje de programación de alto nivel enfocado en la legibilidad del código.
Token. Palabras clave o con significado relevante dentro de un texto. Generalmente

llevado a un valor numérico.
Tokenizar. Proceso de dividir una cadena de texto en una lista de tokens.
Validation Loss. Métrica utilizada para medir el rendimiento de un modelo de deep

learning sobre un conjunto de datos de prueba.
APÉNDICES
APÉNDICE A
Diagrama de Ishikawa
Apéndice B
Entrevista con un jefe de prensa de Radio Compañera
¿Por lo general, cuánto tiempo tardan en publicar una nota desde que el reportero
llega a la zona de la noticia?
Desde el hecho hasta que esté en las plataformas aproximadamente 15 minutos, pero
depende de la carga de noticias y la jerarquía que se le da a cada una.
¿Por qué tienen la necesidad de usar grupos de WhatsApp?
Es la forma más inmediata de comunicarnos y subir archivos multimedia, además es

mediante WhatsApp que se guardan algunas noticias y se tiene el respaldo de quién fue
el que la redactó. También se usa para que hagamos la revisión previa a la publicación.
¿Dónde se guarda toda su información?
En una PC que funciona de “Servidor” no está configurado como tal solo es una carpeta
compartida.
¿Cómo hacen la revisión de noticias los jefes de prensa?
Manualmente, se revisa el título, lead, cabecera y desarrollo.
¿Cómo se hace un seguimiento de las notas que publican los reporteros?
Nos mandan capturas de lo publicado y en el caso de notas de audio por correo

electrónico este último sirve también para compartir a otras radios en el interior.
¿Cuentan con algún software que os ayude con su manejo de información?
No.
¿Qué tanta ayuda les ofrece las herramientas que usan actualmente para
almacenar su información?
Solo tener un respaldo si posteriormente necesitamos la nota.

Por lo general, ¿cuánto tiempo conservan una noticia después de publicada?
Las notas que se generan hasta medio día se quedan en el servidor hasta un año, luego
se las borra, las de la tarde no están ahí porque directo se los manda por WhatsApp por
falta de personal y tiempo.
¿Cuán importante es la velocidad de publicación de noticias?
Muy importante, tener primicias nos consolida como referente noticioso.
A menudo, ¿suelen tener problemas buscando noticias ya publicadas dentro de

donde guardan las mismas?
Sí, las codificaciones son las mismas por un tema de tiempo.
¿Cuánto conocimiento tienen los reporteros sobre herramientas informáticas?
No son desconocidos del tema. Cuentan con experiencia en manejo de aplicaciones

sencillas y algo más avanzadas.
¿Cuántos reporteros tienen y pasantes tienen?
Actualmente 4 reporteros y 6 pasantes.
¿Cuántas noticias se les piden por día?
A cada reportero y pasante mínimo 5.
Actualmente, ¿es necesario que regresen a la radio para publicar sus noticias?
Sí, no tenemos otro lugar desde donde podamos publicar.
¿Cuánto tiempo les toma regresar hasta la radio una vez ya obtuvieron sus
noticias?
Varía según cuán lejos vayamos, pero por lo general de 15 a 30 minutos.

APÉNDICE C
Solución presentada
KERAS
ANEXOS
ANEXO A
Carta de aceptación de realización de proyecto
ANEXO B
Informe de conformidad de la empresa
ANEXO C
Aval de tutor

Documento Final - Isi - Valda 1

Cargado por

Información del documento

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

Documento Final - Isi - Valda 1

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD PRIVADA DEL VALLE

FACULTAD DE INFORMÁTICA Y ELECTRÓNICA

SISTEMA DE INFORMACIÓN WEB APLICANDO REDES

Caso: Departamento de Prensa de Radio Compañera

PROYECTO DE GRADO PARA OPTAR AL

POSTULANTE: GUSTAVO FABRICIO VALDA DORADO

En el departamento de prensa de la radiodifusora boliviana Radio Compañera existe una

La solución presentada en el siguiente proyecto consta de un sistema web desarrollado

Luego de la implementación del proyecto se llega a la conclusión de que se incremento

Cuadro N° 2.1 Ejemplo de historia de usuario ............................................................... 15

La inteligencia artificial es una tecnología que en la última década se ha posicionado

1.2. PLANTEAMIENTO DEL PROBLEMA

1.2.1. IDENTIFICACIÓN DEL PROBLEMA

Dentro de su ambiente, se cuenta con un único equipo en el que se centraliza toda su

En el apartado de personas, los reporteros están en movimiento constante y con

𝑅𝑒𝑠𝑢𝑙𝑡𝑎𝑑𝑜𝑠 𝑎𝑙𝑐𝑎𝑛𝑧𝑎𝑑𝑜𝑠 𝑅𝑒𝑠𝑢𝑙𝑡𝑎𝑑𝑜𝑠 𝑝𝑟𝑒𝑣𝑖𝑠𝑡𝑜𝑠

Se procede a realizar el cálculo de la fórmula.

Se expone de forma gráfica el problema mediante un diagrama causa-efecto (Ishikawa).

También se hace un respaldo de la problemática mediante una entrevista realizada con

1.2.2. FORMULACIÓN DEL PROBLEMA

¿Cómo incrementar la eficiencia de la difusión informativa en el departamento de prensa

1.3.1. JUSTIFICACIÓN TÉCNICA

1.3.2. JUSTIFICACIÓN ECONÓMICA

Con el sistema ya implementado se piensa mejorar la eficiencia de la difusión informativa

Finalmente, al reducir los tiempos de publicación de notas informativas, se generará más

1.3.3. JUSTIFICACIÓN SOCIAL

También se generará un impacto positivo en la sociedad al mejorar la difusión de

1.4.1. OBJETIVO GENERAL

Desarrollar un sistema de información web aplicando redes neuronales recurrentes LSTM

1.4.2. OBJETIVOS ESPECÍFICOS

• Recopilar noticias mediante técnicas de web scraping2 para crear un conjunto de

1.5. ALCANCES Y LÍMITES

• El desarrollo de una aplicación web.

• El desarrollo de un subsistema de procesado de lenguaje natural y clasificación de

1.6.1. TIPO DE ESTUDIO

Los métodos de investigación a usar serán lógicos y empíricos.

Por parte de los métodos empíricos se usará principalmente el método de la observación

2.1.1. SITUACIÓN ACTUAL DE LA EMPRESA

2.1.2. SITUACIÓN DE LA EMPRESA CON EL SISTEMA

Con la implementación de un sistema de información que mejoré la difusión de notas

𝑅𝑒𝑠𝑢𝑙𝑡𝑎𝑑𝑜𝑠 𝑎𝑙𝑐𝑎𝑛𝑧𝑎𝑑𝑜𝑠 𝑅𝑒𝑠𝑢𝑙𝑡𝑎𝑑𝑜𝑠 𝑝𝑟𝑒𝑣𝑖𝑠𝑡𝑜𝑠

2.1.3. MEJORA CON LA IMPLEMENTACIÓN DEL PROYECTO

En general el departamento de prensa de Radio Compañera mejoraría su manejo de

2.2. MARCO CONCEPTUAL

En la página de la Real Academia Española se define el termino eficiencia como:

En el contexto de este proyecto, para medir la eficiencia se trabajará con la siguiente

𝑅𝑒𝑠𝑢𝑙𝑡𝑎𝑑𝑜𝑠 𝑎𝑙𝑐𝑎𝑛𝑧𝑎𝑑𝑜𝑠 𝑅𝑒𝑠𝑢𝑙𝑡𝑎𝑑𝑜𝑠 𝑝𝑟𝑒𝑣𝑖𝑠𝑡𝑜𝑠

La fórmula cuantifica la eficiencia dando como resultado un valor numérico, en caso de

Se procede a explicar cada uno de sus parámetros en base al proyecto actual.

Resultados alcanzados: Cantidad de noticias publicadas en total en un intervalo de

Coste actividad: El coste monetario de la actividad en total en el mismo intervalo de

Tiempo empleado: El tiempo que consume en total toda la actividad mencionada en un

Resultados previstos: El valor de resultados previstos más un 25% de la mejora

Los costes y tiempos previstos serán los parámetros ya mencionados menos un

2.2.2. MANIFIESTO ÁGIL

Fuente: Manifiesto por el Desarrollo Ágil de Software, 2022.

2.2.3. DESARROLLO ÁGIL DE SOFTWARE

Kate Brush mediante un post en la página web ComputerWeekly.com define el desarrollo

En la página web extremeprogramming.org, Don Wells expone lo siguiente: “La

Extreme Programming(XP) fue originalmente una metodología ágil de desarrollo de

En la actualidad, si bien algunas personas aún se refieren a XP como una metodología,

2.2.4.1. Principios del framework XP

Los principios de XP comprenden 5 buenas prácticas involucrando al equipo de trabajo,

• Planificación incremental. Los requerimientos se toman en historias de usuario,