PROTOTIPO DE SERVICIO WEB ACCESIBLE QUE FUNCIONE SIN ...

PROTOTIPO DE SERVICIO WEB ACCESIBLE QUE FUNCIONE SIN DEPENDER DE LA TECNOLOGÍA JAWS PARA PERSONAS CON

DISCAPACIDAD VISUAL EN BOGOTÁ

CRISTIAN CAMILO ZAMBRANO LOZADA

BRAYAN NICOLAS ZEA TIBADUIZA

PROGRAMA DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN

FACULTAD DE INGENIERÍA

UNIVERSIDAD CATÓLICA DE COLOMBIA

BOGOTÁ, NOVIEMBRE

2021

1

PROTOTIPO DE SERVICIO WEB ACCESIBLE QUE FUNCIONE SIN DEPENDER DE LA TECNOLOGÍA JAWS PARA PERSONAS CON DISCAPACIDAD VISUAL

EN BOGOTÁ

CRISTIAN CAMILO ZAMBRANO LOZADA

BRAYAN NICOLAS ZEA TIBADUIZA

Trabajo de Grado para optar al título de

INGENIERO DE SISTEMAS Y COMPUTACIÓN

Asesor: Henry Zárate Ceballos Ph.d

PROGRAMA DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN

FACULTAD DE INGENIERÍA

UNIVERSIDAD CATÓLICA DE COLOMBIA

BOGOTÁ, NOVIEMBRE

2021

2

https://creativecommons.org/licenses/by-nc/4.0/deed.es

https://creativecommons.org/licenses/by-nc/4.0/deed.es

3

TABLA DE CONTENIDO

pág.

1. INTRODUCCIÓN 16

2. JUSTIFICACIÓN 18

3. PLANTEAMIENTO DEL PROBLEMA 20

3.1 MATRIZ DE VESTER 22

3.2 ÁRBOL DE PROBLEMAS 23 3.3 PROBLEMA 24 3.4 ALCANCES Y LIMITACIONES 24

3.4.1 Alcances 24 3.4.2 Limitaciones 25

4. OBJETIVOS 26

4.1 ÁRBOL DE OBJETIVOS 26 4.2 OBJETIVO GENERAL 26 4.3 OBJETIVOS ESPECÍFICOS 26

5. MARCOS DE REFERENCIA 28

5.1 MARCO CONCEPTUAL 28

5.1.1 Accesibilidad general 28 5.1.2 Inclusión digital 28

5.1.3 Discapacidad 29 5.1.4 Servicio web 30

5.1.5 Internet 31 5.1.6 Lenguajes de programación 31 5.1.7 Bases de datos 32

5.1.8 Frameworks de desarrollo web 32 5.1.9 Lenguaje Unificado de Modelado 33

5.1.10 Prototipo 34 5.1.11 Arquitectura de microservicios 34 5.1.12 SaaS (Software as a service) 35 5.1.13 Calidad del software 35

5.2 MARCO TEÓRICO 36

5.2.1 Accesibilidad Web 36

5.2.2 Evaluación y pruebas de accesibilidad 38 5.3 MARCO LEGAL 39

6. ESTADO DEL ARTE 43

6.1 ESTRATEGIA DE BÚSQUEDA DOCUMENTAL 43 6.2 ANTECEDENTES DE INVESTIGACIÓN 44

6.2.1 Accesibilidad web 44 6.2.2 Desarrollo de una página web accesible 46

4

6.2.3 Probar una aplicación web accesible 48 6.3 DESARROLLOS PREVIOS 49 6.3.1 JAWS 49 6.3.2 NonVisual Desktop Access 49 6.3.3 Lector de pantalla Orca 50

6.3.4 Lector de pantalla Supernova 50 6.3.5 Sistema de acceso To Go 51 6.3.6 Sistema de acceso independiente 51 6.3.7 Thunder 52 6.3.8 Braille Note 52

6.3.9 Blazie 53

6.3.10 KNFB Reader 53

6.3.11 Tap Tap See 54 6.4 ESPECIFICACIÓN DE PALABRAS CLAVE 54

6.4.1 Accesibilidad 54 6.4.2 Servicio Web 54

6.4.3 Desarrollo de software 55 6.4.4 Deterioro visual 55

7. METODOLOGÍA 56

7.1 METODOLOGÍA PROPUESTA 56 7.2 TIPO DE INVESTIGACIÓN 57

7.3 NIVEL DE INVESTIGACIÓN 57

7.4 METODOLOGÍA COMPLEMENTARIA SCRUM 58

7.5 INTEGRACIÓN PARCIAL DE METODOLOGÍA SCRUM 59 7.5.1 Roles 60

7.5.2 Reunión retrospectiva (Sprint retrospective) 61 7.5.3 Pila de Producto (Product Backlog) 61 7.6 TÉCNICAS E INSTRUMENTOS 62

7.6.1 Técnicas 62

7.6.2 Instrumentos 62 7.7 HERRAMIENTAS DE DESARROLLO 62 7.7.1 Lenguaje de programación 62 7.7.2 Frameworks 63 7.7.3 API de narración Web Speech API 65

7.7.4 Lenguaje de marcado 65 7.7.5 Plataformas de despliegue 67

7.7.6 Control de versiones 68 7.7.7 Pruebas 68

8. CARÁCTER NOVEDOSO DEL PROYECTO 70

9. CRONOGRAMA DE ACTIVIDADES 71

10. PRODUCTOS A ENTREGAR 72

5

11. INSTALACIONES Y EQUIPO REQUERIDO 73

12. PRESUPUESTO DEL TRABAJO 74

12.1 COSTOS DE PERSONAL 74 12.2 COSTOS DE MATERIALES Y HERRAMIENTAS 74 12.3 COSTOS DE VIAJES 74

12.4 COSTOS TOTALES 75

13. ESTRATEGIAS DE COMUNICACIÓN Y DIVULGACIÓN 76

14. DESARROLLO DEL PROTOTIPO 77

14.1 FASE DE DISEÑO 77

14.1.1 Requerimientos 77 14.1.2 SCRUM Backlog – Historias de usuario 78

14.1.3 Casos de uso 80 14.1.4 Arquitectura 82 14.1.5 Lógica de procedimientos 84

14.1.6 Clases 86 14.1.7 Entidades y relaciones 88

14.2 FASE DE DESARROLLO 90 14.2.1 Instalación y configuración de herramientas 90 14.2.2 Construcción de Dockerfile y docker-compose 93

14.2.3 Estructura general del código 97 14.2.4 Construcción de base de datos 104

14.3 FASE DE PRUEBAS 109 14.3.1 Creación del plan de pruebas 109

14.3.2 Construcción de scripts de prueba 116 14.3.3 Ejecución de scripts 117

14.3.4 Pruebas de accesibilidad 118 14.3.5 Resultado del plan de pruebas 123 14.3.6 Aceptación o rechazo del prototipo según pruebas 124

15. RESULTADOS 125

15.1 RESULTADOS DEL PRIMER OBJETIVO ESPECIFICO 125 15.2 RESULTADOS DEL SEGUNDO OBJETIVO ESPECIFICO 125 15.3 RESULTADOS DEL TERCER OBJETIVO ESPECIFICO 125

15.4 RESULTADOS DEL CUARTO OBJETIVO ESPECIFICO 133

16. CONCLUSIONES 134

17. TRABAJO FUTURO 135

18. BIBLIOGRAFÍA 136

ANEXOS 145

1.1 CÓDIGO FUENTE 145 1.2 VIDEO DEMOSTRATIVO 145

6

1.3 MANUAL DE USUARIO 145 1.3.1 Introducción 145 1.3.2 Instalación de Docker en Windows y Linux 146 1.3.3 Bajar el repositorio desde GitLab 150 1.3.4 Poner en marcha los contenedores 151

1.3.5 Navegar por el módulo noAccesible 154 1.3.6 Navegar por el módulo Accesible del prototipo 156 1.3.7 Realizar una inserción de hoja de vida en la base de datos 157 1.3.8 Administrar la base de datos Postgres 158 1.3.9 Detener los contenedores 161

1.3.10 Solución de problemas comunes 162

1.4 MANUAL TÉCNICO 162

1.4.1 Introducción 162 1.4.2 Requisitos mínimos 162

1.4.3 Licencia de software 163 1.4.4 Alcance actual y objetivo del prototipo 163

1.4.5 Archivos de configuración 163 1.4.6 Estructura de construcción de interfaces gráficas 166 1.4.7 Descripción de redes Docker internas 169

1.4.8 Descripción de entry-points para persistencia 171 1.4.9 Diccionario de datos 172

1.4.10 Recomendaciones finales de desarrollo y mantenimiento 173 1.5 SCRIPTS DE CASOS DE PRUEBA 174

7

INDICE DE FIGURAS

pág.

Figura 1. Clasificación de premisas 23 Figura 2. Árbol de problemas 24 Figura 3. Árbol de objetivos 26 Figura 4. Documentos por año 43 Figura 5. Documentos por autor 44 Figura 6. Software JAWS 49 Figura 7. Software nonVisual Desktop Access 50 Figura 8. Lector Orca 50 Figura 9. Lector Supernova 50 Figura 10. Sistema de Acceso To go 51 Figura 11. Software sistema de acceso independiente 52 Figura 12. Thunder 52 Figura 13. Dispositivo Braille Note 53 Figura 14. Software Blazie 53 Figura 15. Software KNFB Reader 54 Figura 16. Tap Tap see 54 Figura 17. Metodología de trabajo 56 Figura 18. Metodología SCRUM 59 Figura 19. Ejemplo de la estructura de un documento web en XHTML y HTML5 66 Figura 20. Taxonomía de términos de Docker y conceptos 67 Figura 21. Propuesta novedosa 70 Figura 22. Estrategia de divulgación 76 Figura 23. Caso de uso: Página principal 81 Figura 24. Caso de uso: Página accesible 82 Figura 25. Arquitectura del prototipo 83 Figura 26. Diagrama de secuencia: Interacción entre módulos 85 Figura 27. Diagrama de clases 87 Figura 28. Diagrama entidad-relación 89 Figura 29. Página oficial de Python 3.9.6 90 Figura 30. Verificación de versión de Python 91 Figura 31. Página oficial Django 3.2.6 91 Figura 32. Verificación de versión de Django 92 Figura 33. Página oficial de Docker 92 Figura 34. Verificación de versión de Docker 93 Figura 35. Repositorio en GitLab 93 Figura 36. Estructura de Dockerfile 93 Figura 37. Estructura de docker-compose 95 Figura 38. Estructura de red Docker y entry-point 96 Figura 39. Estructura de requirements 97 Figura 40. Estructura general del código 98 Figura 41. Estructura de config 98

8

Figura 42. Estructura general de docker_django 99 Figura 43. Estructura general de manage.py 100 Figura 44. Estructura general de ProyectoVision 101 Figura 45. Estructura general del script de narración 102 Figura 46. Estructura general de los html 103 Figura 47. Estructura de datos generada desde models.py 105 Figura 48. Estructura de datos, vista desde pgadmin 106 Figura 49. Estructura general de recolección de datos en Views.py 107 Figura 50. Operación: Inserción de datos 108 Figura 51. Resultado de script 001 117 Figura 52. Resultado de script 002 117 Figura 53. Resultado de script 003 118 Figura 54. Resultado de script 004 118 Figura 55. Prueba de accesibilidad en módulo noAccesible 119 Figura 56. Prueba de accesibilidad en el módulo Accesible 120 Figura 57. Prueba de contraste del botón accesible 121 Figura 58. Prueba de accesibilidad en formulario de módulo noAccesible 122 Figura 59. Prueba de accesibilidad en formulario de módulo Accesible 123 Figura 60. Módulos desarrollados 126 Figura 61. Formulario desarrollado 127 Figura 62. Contenedores construidos 128 Figura 63. Interfaz “inicio” modulo “noAccesible” parte superior 128 Figura 64. Interfaz “inicio” modulo “noAccesible” parte inferior 129 Figura 65. Interfaz "inicio" modulo “Accesible” 129 Figura 66. Interfaz "elinstituto" módulo “noAccesible” 130 Figura 67. Interfaz "blog" módulo “noAccesible” 130 Figura 68. Interfaz "blog" módulo “Accesible” 131 Figura 69. Interfaz "atencion" modulo “noAccesible” 131 Figura 70. Interfaz "atencion" modulo “Accesible” 132 Figura 71. Interfaz "participa" modulo “noAccesible” 132 Figura 72. Interfaz "participa” modulo "Accesible" 133

9

INDICE DE TABLAS

pág.

Tabla 1. Premisas de Vester 22

Tabla 2. Normativa y regulaciones 40

Tabla 3. Metodología DRM 58

Tabla 4. Definición de roles SCRUM 60

Tabla 5. Medición de desempeño sobre atributos para peticiones directas 63

Tabla 6. Comparación de frameworks por atributos 64

Tabla 7. Cronograma de actividades 71

Tabla 8. Productos a entregar 72

Tabla 9. Instalaciones y equipo requerido 73

Tabla 10. Costos de personal 74

Tabla 11. Costos de materiales 74

Tabla 12. Costos de Viajes 74

Tabla 13. Costos totales 75

Tabla 14. Listado de requerimientos no funcionales 77

Tabla 15. Listado de requerimientos funcionales 78

Tabla 16. Product Goal 79

Tabla 17. Product Backlog – Historias de usuario 79

Tabla 18. Plan de pruebas 109

Tabla 19. Caso de prueba 001 110




Tabla 23. Resultados del plan de pruebas 123

10

INDICE DE ANEXOS pág.

145

146

147

147

148

149

150

150

151

151

152

152

153

153

154

155

155

156

156

157

158

159

160

161

162

164

165

166

167

168

169

170

171

172

173

Anexo A. Contribuciones a código fuente Anexo B. Descarga de Docker Desktop para Windows Anexo C. Configuraciones de instalador de Docker Desktop Anexo D. Desempaquetado de Docker Desktop Anexo E. Docker Desktop inicializándose Anexo F. Docker Desktop preparado Anexo G. Disponibilidad de Docker en Linux Anexo H. Verificar instalación de Docker en Linux Anexo I. Descarga de repositorio desde GitLab Anexo J. Repositorio en disco duro Anexo K. Carpeta del prototipo Anexo L. Menú contextual Anexo M. Comando docker-compose up en ejecución Anexo N. Comprobación de creación de contenedores Anexo O. Inicio del módulo noAcessible Anexo P. Página “elinstituto” del módulo noAccesible Anexo Q. Página “formulario” del módulo noAccesible Anexo R. Ubicación del botón accesible Anexo S. Página “elinstituto” del módulo Accesible Anexo T. Resultado de las operaciones de migración Anexo U. Ubicación del botón validar para para insertar datos Anexo V. Interfaz pgAdmin por el puerto 8080 Anexo W. Opción de conexión a servidor de base de datos Anexo X. Configurar la conexión al servidor de base de datos Anexo Y. Comando "docker-compose down” en ejecución Anexo Z. Estructura de local.conf Anexo AA. Conexión a base de datos desde Django Anexo AB. Panel de administración Django Anexo AC. Estructura general de interfaces en módulo no Accesible Anexo AD. Estructura general de interfaces en módulo Accesible Anexo AE. Footer unificado en ambos módulos Anexo AF. Estructura de redes en Docker Anexo AG. Configuración de entry-points en contenedores Anexo AH. Configuración de volúmenes Anexo AI. Diccionario de datos Anexo AJ. Herramientas recomendadas 174

11

AGRADECIMIENTOS

Expresamos nuestro agradecimiento al doctor Henry Zárate Ceballos, asesor de la presente tesis por su apoyo constante y diligente desde los comienzos del presente trabajo, gracias a su apoyo, conocimientos y guía profesional se logró ir perfeccionando esta idea hasta los resultados logrados de los cuales nos sentimos muy orgullosos.

Agradecemos de la misma forma a la Universidad Católica de Colombia, en especial a su cuerpo docente por brindarnos los conocimientos, herramientas, así como la oportunidad de hacer de esta nuestra alma mater, la cual honraremos en nuestro ejercicio profesional como ingenieros de sistemas y computación.

También agradecemos a nuestras familias, quienes depositaron su confianza, tiempo y recursos para nuestra formación académica, convirtiéndose en aquella sinergia invaluable y maravillosa para impulsar nuestros sueños y metas, logrando contribuir a nuestro futuro y calidad de vida.

12

DEDICATORIA

La presente tesis la dedicamos a todas las personas que nos acompañaron en este recorrido ya que gracias a sus contribuciones logramos ser mejores versiones de nosotros mismos, la dedicamos a profesores desde primero a último semestre a quienes debemos nuestro conocimiento, a nuestros familiares que nos acompañaron permanentemente como soporte fundamental, a nuestros compañeros quienes nos enriquecieron con diversas experiencias, y a todas aquellas personas que pese a dificultades como una pandemia no escatimaron en esfuerzos para continuar contribuyendo a nuestra educación.

13

NOTA DE ACEPTACIÓN

_________________________________

_________________________________

_________________________________

_________________________________

Jurado

_________________________________

Jurado

_________________________________

Henry Zárate Ceballos

Asesor

Bogotá, noviembre 10 del 2021

14

RESUMEN

En el marco de las “Pautas de accesibilidad al contenido web (WCAG)”, las cuales son un conjunto de directrices o normas que debemos seguir para la elaboración de sitios web con accesibilidad impulsadas por el World Wide Web Consortium (W3C), el comité internacional más importante dedicado a desarrollar estándares y pautas en la web, esta investigación se centra y tiene como objetivo el desarrollo de un prototipo de servicio web accesible que funcione sin depender de la tecnología JAWS para personas con discapacidad visual en Bogotá. Para este propósito se construye y describe una metodología propia basada en la metodología de investigación en diseño (DRM) considerándose que el nivel de la investigación es de estudio prescriptivo, a su vez esta se combina con una adaptación de la metodología SCRUM para facilitar las labores de desarrollo y documentación. Los resultados indican la factibilidad del desarrollo de servicios web a partir de prototipos de carácter accesible enfocados en población con discapacidad visual en Bogotá mediante la aplicación de técnicas establecidas dentro del diseño de software, la aplicación de atributos de calidad y pruebas. En conclusión, para contribuir a la mejora de la calidad de vida de personas con discapacidad visual en Bogotá se evidencia que es posible y necesaria la utilización de las tecnologías de la información con un enfoque inclusivo.

Palabras Claves:

Accesibilidad, servicio web, desarrollo de software, deterioro visual, WCAG.

15

ABSTRACT

In the context of the "Web content accessibility guidelines (WCAG)" which are a set of guidelines or norms that we must follow for the elaboration of websites with accessibility promoted by the World Wide Web Consortium (W3C), the most important international committee dedicated to developing standards and guidelines on the web, this research focuses and aims at the development of an accessible web service prototype that works without depending on JAWS technology for visually impaired people in Bogotá. For that purpose, an own methodology based on the design research methodology (DRM) is built and described, considering that the level of the research is a prescriptive study, at the same time this is combined with an adaptation of the SCRUM methodology to facilitate the work of development and documentation. The results indicate the feasibility of developing web services from accessible prototypes focused on the visually impaired population in Bogotá through the application of established techniques within software design, the application of quality attributes and tests. In conclusion, in order to contribute to the improvement of the quality of life of people with visual disabilities in Bogotá, it is evident that the use of information technologies with an inclusive approach is possible and necessary.

Keywords:

Accessibility, web service, software development, visual impairment, WCAG.

16

1. INTRODUCCIÓN

La discapacidad visual y la ceguera se encuentran en los primeros de los tipos más comunes de discapacidad humana en el mundo, y actualmente se definen por cinco tipos de discapacidad visual. La modificación del término "baja visión" incluye errores de refracción como la causa fundamental de la discapacidad visual y amplía la etiología y el campo de visión de diagnóstico. Los cambios epidemiológicos modernos han cambiado la causa de la discapacidad visual en los adultos y explicaron que la discapacidad visual y la ceguera en los adultos son las causas más comunes de enfermedades adquiridas, no infecciosas o progresivas, acompañadas de múltiples factores de riesgo y sistemas físicos Las enfermedades sexuales tienen la capacidad de producir una variedad de discapacidades y varios defectos oculares.1

Por motivos técnicos, la accesibilidad ha avanzado mucho, aunque muchas veces, por diversas variables, muchas personas con limitación visual no pueden acceder a ellos. La tecnología más utilizada para beneficiar a las personas con limitación visual en nuestro país incluye JAWS, que es un software que permite a las personas con discapacidad visual utilizar una computadora. Las personas con discapacidad visual ingresan a Internet a través de un diseño universal basado en texto, sin imágenes ni elementos móviles, y para acceder a un teléfono móvil, utilizan el programa predeterminado provisto en el teléfono inteligente, que puede expresar palabras con texto o comandos de voz2.

En el país y también suscitado por pandemia de COVID-19 uno de los retos más grandes ha sido garantizar la educación inclusiva en la virtualidad, así lo ha declarado Carlos Parra Dussan, director General del Instituto Nacional para Ciegos 3, quien recalca la importancia que tiene la Biblioteca Virtual para Ciegos que provee el INCI sin embargo resalta que debido a falta de aprobación de aprobación de diversos proyectos de ley la Biblioteca no contiene la capacidad de obras que podría tener.

Con la llegada del nuevo milenio, la rápida expansión de las tecnologías, y la integración de las mismas en las vidas cotidianas de las personas, la población con limitaciones en la capacidad visual empezaron a quedar relegadas y es por ello que en años recientes se han enfocado esfuerzos en el desarrollo de tecnologías para

1 SUAREZ, Juan Camilo. Discapacidad visual y ceguera en el adulto: Adult visual impairment and blindness. Medellin: vol 30, 2011. 2 INCLUYEME. Todo lo que necesitas saber sobre discapacidad visual. [En línea]. [16 de febrero de 2017]. Disponible en: https://www.incluyeme.com/todo-lo-que-necesitas-saber-sobre-discapacidad-visual/ 3 PARDO, Monica. "Las personas con discapacidad visual siguen siendo invisibles en Colombia". [En línea]. [06 de abril de 2021]. Disponible en: https://www.semana.com/contenidos-editoriales/la-ceguera-no-es-una-barrera/articulo/las-personas-con-discapacidad-visual-siguen-siendo-invisibles-en-colombia/202028/

17

permitir el acceso a la información como ayudas ópticas, lectores autónomos u otros proyectos más ambiciosos como PIRAmIDE que busca convertir al teléfono en una especie de sexto sentido4.

La limitación en la capacidad visual afecta la interacción de estas personas con muchas de las herramientas tecnológicas que podrían impactar y mejorar su calidad de vida en ámbitos tan importantes como los son el aprendizaje y la comunicación, o actividades como puede ser simplemente disfrutar del entretenimiento digital, enel campo laboral la situación en Colombia es más dramática, según datos del Instituto Nacional para Ciegos cerca del 80% de la población con discapacidad se encuentra en el desempleo.5

Por su parte el DANE en su censo poblacional 2018 reportó 1.948.332 personas con discapacidad visual, cifra que se acerca al 7.1% de la población colombiana6 por lo que desde la ingeniería de sistemas se deberían impulsar proyectos que estén enfocados a la mejora de la calidad de vida de dicha población.

Una propuesta de un prototipo de servicio web que se encuentre alineado con las pautas de accesibilidad al contenido web (WCAG), siguiendo un debido proceso de diseño de software, con atributos de calidad y pruebas podría tener un impacto positivo sobre la calidad de vida de las personas con discapacidad visual en Bogotá, facilitándoles el acceso y uso de la información en especial la que reside en la web, esto también puede contribuir a que mediante la adquisición de nuevos conocimientos se les aporte a una mejor inclusión en el mercado laboral y podría poner el foco de empresas dedicadas al desarrollo de software en la accesibilidad de sus productos.

4 MUÑOZ, José. “Las TIC y la discapacidad visual.” [En línea]. [17 de marzo de 2021]. Disponible en: https://ruc.udc.es/dspace/bitstream/handle/2183/13227/CC-127_art_18.pdf?sequence=1&isAllowed=y 5 MELO, Tania. "Cerca del 80% de personas con discapacidad no encuentran empleo en Colombia". [En línea]. [25 de marzo de 2021]. Disponible en: https://www.rcnradio.com/economia/cerca-del-80-de-personas-con-discapacidad-no-encuentran-empleo-en-colombia 6 INSTITUTO NACIONAL PARA CIEGOS. Los ciegos en el Censo 2018. Edición 106. Bogotá. INCIDigital, 2018.Disponible en https://www.inci.gov.co/blog/los-ciegos-en-el-censo-2018

18

2. JUSTIFICACIÓN

En 2011, una revisión sistemática de datos realizada durante 20 años (1990-2018) y explicada por Arias7, se encontró que la prevalencia de personas con discapacidad visual se acercaba a los 223 millones, distribuidos entre 32.4 millones de personas ciegas y 191 millones de personas con baja visión. Las cifras actuales de la OMS muestran que la prevalencia mundial de discapacidad visual es de 253 millones, de los cuales 217 millones tienen baja visión y 36 millones son ciegos. En Colombia, según datos oficiales del Censo Nacional de 2017, la prevalencia general de discapacidad visual (desde la perspectiva de restricciones permanentes, a pesar de usar anteojos o anteojos) es del 2,72% (aproximadamente 1,121,129 personas), lo que representa el 43,4% de los habitantes de Colombia. En otras palabras, en Colombia, la barrera más común entre la población discapacitada es la discapacidad visual. En general, la causa más común de discapacidad visual que ocasiona baja visión o ceguera suele ser por motivos oftalmológicos. En América Latina, según el informe oficial del plan Visión 2020 en 2018, las principales causas de mala visión en personas mayores de 50 años son cataratas (40-76%), errores refractivos (18-50%) y causas relacionadas de la región posterior. segmento (2-23%)8.

El proyecto se encuentra justificado al estar alineado con diferentes planes y programas promovidos por el estado colombiano. El actual Plan Nacional de Desarrollo 2018-2022 plantea el “Pacto por la inclusión de todas las personas con discapacidad” y su vez indica que las barreras de inclusión de las personas con discapacidad se remueven con coordinación y acciones decididas por parte de diversos sectores, a su vez se reconoce que tener una discapacidad como lo es la discapacidad visual “implica una desventaja en términos de inclusión y goce efectivo de derechos” es por ello que enfoca esfuerzos para avanzar en la adecuación de las condiciones de accesibilidad universal que incluye a los sistemas y las TIC. 9

Con el desarrollo de este proyecto, se está contribuyendo al proyecto presentado por el ministerio de las TIC denominado ConVerTIC que busca mejorar la inclusión social y cultural de las personas con discapacidad mediante la masificación de software como JAWS y Zoom Text mejorando así el uso de los dispositivos informáticos y el fácil acceso a las personas con discapacidad visual.10

7 ARIAS, Johana; LLANO, Yuliana; ASTUDILLO, Esai; SUAREZ, Juan. Caracterización clínica y etiología de baja visión y ceguera en una población adulta con discapacidad visual. Ciudad de México: Revista Mexicana de Oftalmología, 2020. 202p. 8 Ibid. 9 DEPARTAMENTO NACIONAL DE PLANEACIÓN. PLAN NACIONAL DE DESARROLLO 2018-2022: Pacto por Colombia, pacto por la equidad: PACTO POR LA INCLUSIÓN DE TODAS LAS PERSONAS CON DISCAPACIDAD. Bogotá D.C: Imprenta Nacional de Colombia, 2019. 1111p. 10 MINISTERIO DE TECNOLOGÍAS DE LA INFORMACIÓN Y LAS COMUNICACIONES. ConVerTIC. [En línea]. [2013]. Disponible en: https://convertic.gov.co/641/w3-propertyvalue-36246.html

19

Por su parte el Plan de Desarrollo Distrital para Bogotá 2020-2024 plantea en su artículo 139 un sinergia y compromiso de la Administración Distrital en los programas, proyectos y planes que contribuyan hacia el goce efectivo de los derechos consagrados constitucionalmente para la población con discapacidad11.

El INCI conocido también como Instituto Nacional para Ciegos. Es una institución de carácter pública que actúa como entidad técnico asesor adscrita al Ministerio de Educación y tiene dentro de sus funciones supervisar y vigilar en coordinación con los ministerios correspondientes el cumplimiento de los planes y programas intersectoriales destinados a propender los derechos de las personas con discapacidad visual.12

El ministerio de salud de Colombia cuenta con el Programa Nacional de Atención Integral en Salud Visual el cual tiene vigencia desde 2016 hasta 2022 y se plantean en sus objetivos garantizar el acceso de la población con discapacidad visual, baja visión y ceguera a intervenciones de habilitación y rehabilitación integral oportuna y de calidad que mejoren su inclusión en la sociedad. 13

Uno de los mayores retos y a su vez una de las situaciones más comunes en la cotidianidad que estas personas con discapacidad visual se enfrentan es a la interpretación de un contenido audiovisual con esto en mente Sara López y Julián Ramírez de la Corporación Universitaria Minuto de Dios condujeron un análisis de efectividad de la audio descripción en este caso para escenas de cine, el análisis se realizó en un grupo conformado por 25 personas en situación de discapacidad visual, miembros de la Unión Nacional de Limitados Visuales en Medellín y concluyeron que la audio descripción es una herramienta que aporta a la integración social de esta población. 14

11 COLOMBIA. CONCEJO DE BOGOTÁ, D.C. Acuerdo No. 761 de 2020 (11, junio, 2020). Por medio del cual se adopta el plan de desarrollo económico, social, ambiental y de obras públicas del Distrito Capital 2020-2024. Imprenta distrital. junio, 2020. p.163. 12 INSTITUTO NACIONAL PARA CIEGOS. Funciones. [En línea]. [06 de abril de 2021]. Disponible en: https://www.inci.gov.co/funciones 13 MINISTERIO DE SALUD. PROGRAMA NACIONAL DE ATENCIÓN INTEGRAL EN SALUD VISUAL 2016-2022: Organización del Programa: Objetivos estratégicos. Bogotá D.C: Biblioteca digital MinSalud, 2016. 66p. 14 LÓPEZ, Sara; RAMÍREZ, Andrés. Análisis de la efectividad de la audiodescripción en el cine para personas en situación de discapacidad visual en la Unión Nacional de Limitados Visuales de la ciudad de Medellín. Trabajo de grado Comunicación Social y Periodismo. Medellín.: Corporación Universitaria Minuto de Dios. Facultad de Ciencias Sociales y Humanas. 56 p.

20

3. PLANTEAMIENTO DEL PROBLEMA

La discapacidad visual y la ceguera se encuentran en los tipos más comunes de

discapacidad humana en el mundo. Las cifras actuales de la OMS muestran que en

el mundo hay al menos mil millones de casos de personas con deterioro en la visión

cercana o distante.15 En Colombia, según datos oficiales del Censo Nacional de

2018 existen más de un millón novecientos mil personas con discapacidad visual,

lo cual es equivalente al 62.17% del total de población con discapacidad visual para

ese periodo, así lo explica Parra director del INCI (Instituto Nacional para Ciegos). 16 En América Latina, según el informe oficial del plan Visión 2020 en 2013, las

principales causas de mala visión en personas mayores de 50 años son cataratas

(40-76%), errores refractivos (18-50%) y causas relacionadas de la región posterior

(2-23%)17.

Teniendo en cuenta estas cifras son numerosos los autores que han resaltado la

importancia de trabajar en el sector de la accesibilidad web para personas con

discapacidad visual, esto ya que mediante el uso de las herramientas tecnológicas

se puede mejorar su calidad de vida en ámbitos tan importantes como los son el

aprendizaje y la comunicación, o actividades como puede ser simplemente disfrutar

del entretenimiento digital.

Realizando una búsqueda documental en bases de datos bibliográficas se encontró

que Ramakrishnan un autor representativo18 ha producido y publicado 24

documentos relacionados con la temática, esto se profundiza en el estado del arte,

siendo uno de los más importantes en la investigación de accesibilidad web

relacionada con la discapacidad visual, quien establece varias pautas y resalta la

importancia de la utilización de las pautas de accesibilidad WCAG para la

construcción de páginas web enfocadas en la población con discapacidad visual.

Por motivos técnicos, la accesibilidad para esta población ha avanzado mucho,

aunque muchas veces, por diversas variables las personas con limitación visual no

pueden acceder a ellos. La tecnología más utilizada para beneficiar a las personas

15 OMS. Ceguera y discapacidad visual. [En línea]. [06 de abril de 2021]. Disponible en: https://www.who.int/es/news-room/fact-sheets/detail/blindness-and-visual-impairment 16 PARRA, Carlos. INCI: Los ciegos en el Censo 2018. [En línea]. [06 de abril de 2021]. Disponible en: https://www.inci.gov.co/blog/los-ciegos-en-el-censo-2018 17 ARIAS, Johana; LLANO, Yuliana; ASTUDILLO, Esai; SUAREZ, Juan. Caracterización clínica y etiología de baja visión y ceguera en una población adulta con discapacidad visual. Ciudad de México: Revista Mexicana de Oftalmología, 2020. 202p. 18 STONY BROOK UNIVERSITY. "I.V. Ramakrishnan". [En línea]. [25 de marzo de 2021]. Disponible en: https://www.cs.stonybrook.edu/people/faculty/IVRamakrishnan

21

con limitación visual en nuestro país incluye JAWS, que es un software que permite

a las personas con discapacidad visual utilizar una computadora y es impulsado por

proyectos públicos como ConVerTIC del MinTIC19, a nivel mundial es el segundo

software más utilizado por personas con discapacidad visual. Las personas con

discapacidad visual una vez instalado el software utilizan el ordenador a través de

un diseño universal basado en texto, sin imágenes ni elementos móviles,

expresando las palabras vía comandos de voz, sin embargo, esto genera

dependencia en un solo software, el cual no sigue las pautas WCAG impulsadas

por el W3C 20 máxima autoridad en internet al no ser integrado a las páginas web,

y no está disponible más allá de las plataformas comunes lo que limita su espectro

de aplicación.

En nuestro país el INCI revela otros aportes tecnológicos para la población con discapacidad visual en el país que podemos resumir así:21

Biblioteca INCI: Es la impresora Braille oficial del país y produce los audiolibros digitales más avanzados. Gracias a la biblioteca del INCI, las personas ciegas y con baja visión pueden leer o descargar el texto contenido en esta herramienta virtual desde cualquier computadora o dispositivo móvil. Se puede acceder a textos en diferentes formatos (doc, pdf, mp3, wav). Por ejemplo, el formato DAISY permite una versátil lectura de libros lo que le permite a Colombia ser el único país hispanohablante de América Latina que produce libros con esta tecnología.

Inciradio: Se plantea como un proyecto de radio participativo para que las personas con discapacidad visual participen en un tema de interés general en la comunidad. Inciradio quiere ser una herramienta para promover la interacción de las personas con limitación visual en el proceso de aprendizaje, la cultura, la salud y el fortalecimiento de la participación ciudadana.

Inci qr es un proyecto tecnológico que busca la generación QR a partir de información escrita que puede estar presente en empaques de alimentos, publicidad, tiquetes de transporte, recibos de pago entre otros.

19 MINISTERIO DE TECNOLOGÍAS DE LA INFORMACIÓN Y LAS COMUNICACIONES. ConVerTIC. [En línea]. [2013]. Disponible en: https://convertic.gov.co/641/w3-propertyvalue-36246.html 20 W3C. Web Content Accessibility Guidelines (WCAG) 2.0. [En línea]. [9 de abril de 2021]. Disponible en: https://www.w3.org/ 21 INSTITUTO NACIONAL PARA CIEGOS. Aplicaciones INCI en la cuarentena. [En línea]. [06 de abril de 2021]. Disponible en: https://www.inci.gov.co/blog/aplicaciones-inci-en-la-cuarentena

22

ConVerTIC es un proyecto del Ministerio de Tecnologías de la Información y las Comunicaciones, por lo que todos los colombianos pueden acceder libremente a su uso, para las personas con discapacidad visual, hay dos programas para destacar:

El software de ampliación Magic Visión le permite aumentar el tamaño de las letras hasta 16 veces y cambiar el contraste de la pantalla para adaptarse a las personas con baja visión. INCI proporciona consejos sobre la descarga y el uso, sin embargo, las principales recomendaciones se centran hacía el software JAWS.

3.1 MATRIZ DE VESTER

Para Castro la matriz de Vester es una herramienta esencial para determinar y enumerar las causas relacionadas a problemas de diversa índole,22 lo que ayuda a delimitar este de mejor forma, es por ello que se construyeron las premisas necesarias y la matriz correspondiente como se muestra a continuación:

Tabla 1. Premisas de Vester

Fuente: Elaboración propia, 2021.

22 CASTRO, Carlos. La Matriz de Vester. [En línea]. [25 de marzo de 2021]. Disponible en: https://es.scribd.com/document/35150680/La-Matriz-de-Vester#scribd

23

Figura 1. Clasificación de premisas


3.2 ÁRBOL DE PROBLEMAS

A partir del análisis de los resultados de la matriz de Vester se construye el árbol de problemas para identificar cual es el problema adecuado para enfocar el proyecto:

24

Figura 2. Árbol de problemas


3.3 PROBLEMA

¿Cuáles son los pasos que debe sugerir una metodología para diseñar y construir

un prototipo de software que pueda ser utilizado por la población con discapacidad

visual de Bogotá, que sea accesible vía web y sin depender de la tecnología

JAWS?

3.4 ALCANCES Y LIMITACIONES

3.4.1 Alcances

Se desarrollará un prototipo de servicio web funcional enfocada en la accesibilidad y la experiencia del usuario para población con discapacidad visual de la ciudad de Bogotá y que permita la interacción con elementos típicos de una página web. Para ello se realizará la documentación correspondiente a el diseño siguiendo las pautas del lenguaje unificado de modelado UML, se definirán requerimientos funcionales y no funcionales adicionalmente se plantea una arquitectura de microservicios, por su parte para el desarrollo se utilizará herramientas que permitan implementar una arquitectura de microservicios, y por último para validar el prototipo se realizará pruebas funcionales de los requerimientos más relevantes para lo que se entregarán test case y resultado.

25

3.4.2 Limitaciones

Las limitaciones que se tienen en cuenta para el desarrollo del prototipo son las que se relacionan a continuación:

3.4.2.1 Limitación espacial

El proyecto propuesto se enfoca en la población con discapacidad visual de la ciudad de Bogotá, sin embargo, para la recolección de información relevante es necesario tener en cuenta fuentes de información tanto nacionales como extranjeras, basado en esta delimitación el prototipo de servicio web se presentará únicamente en idioma español.

3.4.2.2 Limitación temporal

Para el desarrollo del proyecto, comprendiendo documentación y desarrollo del prototipo funcional de la página web se dispone de 16 semanas, las cuales comienzan desde el día 02 de agosto de 2021 hasta el 20 de noviembre de 2021.

3.4.2.3 Limitación del universo

El proyecto está delimitado en el universo poblacional de personas en Bogotá con discapacidad visual y sin condiciones médicas adicionales que dispongan de acceso y conexión a internet.

26

4. OBJETIVOS

4.1 ÁRBOL DE OBJETIVOS

Para el establecimiento de los objetivos se parte de la información obtenida mediante el árbol de problemas y se escriben de forma positiva a manera de acciones que contribuyan a solventar la problemática principal, dando como resultado el siguiente árbol de objetivos:

Figura 3. Árbol de objetivos

Fuente: Elaboración propia

4.2 OBJETIVO GENERAL

Construir un prototipo de servicio web funcional inclusivo mediante la utilización de estándares y técnicas de desarrollo de software para el acceso de usuarios con discapacidad visual (ciudad de Bogotá) sin depender de la tecnología JAWS.

4.3 OBJETIVOS ESPECÍFICOS

● Establecer los requerimientos funcionales y no funcionales mediante el estado

del arte para el desarrollo del prototipo de servicio web inclusivo.

27

● Generar los diagramas de arquitectura de software, requerimientos y pruebas funcionales mediante una metodología de trabajo propia para el apropiado diseño del prototipo de servicio web inclusivo.

● Construir el prototipo de servicio web inclusivo siguiendo los parámetros establecidos en la metodología propuesta para dar cumplimiento al diseño.

● Validar las funciones principales del prototipo de servicio web inclusivo por medio de un escenario de pruebas para comprobar el adecuado funcionamiento del prototipo.

28

5. MARCOS DE REFERENCIA

5.1 MARCO CONCEPTUAL

5.1.1 Accesibilidad general Para la realización del proyecto es importante partir desde la definición más general de accesibilidad, debido a que el proyecto busca realizar un servicio web accesible. En ese sentido la Corporación de Ciudad Accesible 23 define la accesibilidad como el conjunto de características que debe disponer un entorno urbano, edificación, producto, servicio o medio de comunicación para ser utilizado en condiciones de comodidad, seguridad, igualdad y autonomía por todas las personas, incluso por aquellas con capacidades motrices o sensoriales diferentes. Para los ingenieros Claudio Giordani y Diego Leone la accesibilidad “es una característica básica del entorno construido”24, lográndose comprender como aquellos elementos que permiten acciones como la entrada, salida y utilización de casas, comercios, teatros, parques y lugares de trabajo. Añaden además que “la accesibilidad permite a las personas participar en las actividades sociales y económicas para las que se ha concebido el entorno construido”. 5.1.2 Inclusión digital

Uno de los posibles resultados que pueden derivar del proyecto es contribuir a la inclusión digital de la población con discapacidad visual en Bogotá, en ese sentido resulta relevante entonces entender la inclusión digital. Scott Robinson explica que, aunque el concepto puede volverse complejo25 realiza una simplificación del concepto y explica que puede ser comprendido como un conjunto de políticas públicas relacionadas con el desarrollo de capacidades locales, gestión, expansión, provisión de contenidos y desarrollo de redes públicas digitales, cableadas e inalámbricas en cada país y en toda la región. Incluye garantías de privacidad y seguridad que se ejercen de manera justa para todos. Cubre la formación y los incentivos para desarrollar nuevas herramientas (por ejemplo, software de código abierto). Y de la misma forma indica que el avance en inclusión digital no logra ser tan amplio como se quisiera en América Latina.

23 BOUDEGUER, Andrea. Manual de Accesibilidad Universal. Santiago de Chile, 2010. 12p. 24 LEONE, Diego; GIORDANI, Claudio. ACCESIBILIDAD. Buenos Aires.2p. 25 ROBINSON, Scott S. Sobre la inclusión digital. Caracas: Nueva sociedad. 2005. 127p.

29

5.1.3 Discapacidad La discapacidad se vuelve un eje central para el desarrollo de la propuesto ya que hace referencia a la población objetivo de este, por esta razón resulta crucial entender este concepto. El Consejo Nacional del Fomento Educativo definió la discapacidad como “la condición de vida de una persona, adquirida durante su gestación, nacimiento o infancia, que se manifiesta por limitaciones significativas en el funcionamiento intelectual, motriz, sensorial”26 dan a entender también que puede existir afectación en la conducta adaptativa, es decir, en la relación entre familia, escuela y comunidad. 5.1.3.1 Discapacidad visual Existen diferentes tipos de discapacidad, pero la que resulta sustancial definir en la propuesta es específicamente la discapacidad visual. Sobre el particular el Consejo Nacional del Fomento Educativo también definió la discapacidad visual como una “condición que afecta directamente la percepción de imágenes en forma total o parcial” 27. Dándonos a entender que la vista es un sentido que permite identificar a distancia y a un mismo tiempo objetos familiares o aquellos que se presentan por primera vez. Los alumnos con discapacidad visual deben adentrarse a descubrir y construir el mundo por medio de otras sensaciones mucho más parciales, como olores, sabores, sonidos, tacto y quizá imágenes segmentadas de los objetos. El apoyo que reciban en el centro escolar y desde casa influirá de forma importante en esta construcción, pues en la medida que descubran sus posibilidades y sus habilidades podrán elaborar una autoimagen positiva indispensable para su integración escolar y social. 5.1.3.2 Tipos de discapacidad visual La discapacidad visual no es una sola, y resulta valioso detallar los diferentes tipos de discapacidad visual para tener una mejor definición del alcance poblacional al que se enfoca el proyecto.

26 RAMIREZ, Marta. Discapacidad visual: Guía didáctica para la inclusión en educación inicial y básica. México, 2010. 15p. 27 Ibid,16p.

30

Según las categorías de discapacidad visual establecidas por la Organización Mundial de la Salud y explicadas por Escudero28 estas se clasifican según el parámetro de agudeza visual lejana, medicamente AV, de la siguiente manera:

• Discapacidad visual leve o sin discapacidad: Ocurre cuando la medición AV es igual o mayor a 6/18.

• Discapacidad visual moderada: Ocurre cuando la medición AV es menor a 6/18 o mayor a 6/60.

• Discapacidad visual severa: AV menor 6/60 o mayor a 1/60.

• Ceguera con percepción de luz: Ocurre cuando la medición AV es menor a 1/60 y percepción de luz.

• Ceguera sin percepción de luz: Ninguna percepción de luz.

5.1.4 Servicio web Realizar un prototipo de servicio web requiere tener en cuenta su definición, sin embargo, está es dinámica y se ha transformado en el tiempo, un buen referente puede ser considerar las denominaciones que le dan grandes empresas del sector al concepto de servicio web: IBM definió servicio web como aplicaciones audescriptivas, autónomas y modulares

29 que se pueden mezclar y combinar con otros servicios del Web para crear productos innovadores, procesos y cadenas de valor, así lo explica Monica. Microsoft maneja el significado de servicio web como una “unidad de la lógica del negocio que proporciona datos y servicios para otras aplicaciones”30. Añade también que las aplicaciones acceden a los Web services vía protocolos Web como HTTP y SOAP y formatos de datos universales como XML, sin necesidad de preocuparse de cómo cada Web Service es implementado. Los servicios del Web combinan los mejores aspectos del desarrollo basado en componentes y el Web, y son la piedra angular del modelo de programación de Microsoft.Net. En resumen, un servicio web es un componente de software que se comunica con otras aplicaciones mediante la codificación de mensajes en XML y el envío de estos mensajes a través de protocolos estándar de Internet. El servicio web es similar a un sitio web que no tiene una interfaz de usuario y proporciona servicios a las aplicaciones en lugar de al personal. No recibe solicitudes del navegador y devuelve páginas web en respuesta, sino que recibe solicitudes de mensajes en formato XML

28 ESCUDERO, Juan Camilo Suárez. Discapacidad visual y ceguera en el adulto: revisión de tema. Bogotá: Medicina UPB, 2011. 173p. 29 GALLEGOS, Monica. LOS SERVICIOS WEB XML: Introducción a los Servicios Web:ICA -EISIC, 2011. 73p. 30 Ibid.

31

desde la aplicación que realiza la tarea y devuelve un mensaje de respuesta en formato XML. 5.1.5 Internet

Considerar un servicio web conlleva entender el concepto de internet para comprender de mejor manera a lo que se hace referencia. Una de las definiciones más sencillas que se pueden dar sobre internet es la que indica Cobo31 quien lo define como un sistema distribuido de redes interconectadas que permite la comunicación entre hosts mediante la utilización del protocolo TCP/IP.

5.1.6 Lenguajes de programación

Para construir cualquier producto de software se tendrá que de una forma u otra emplear algún lenguaje de programación y a tal efecto resulta fundamental la comprensión de que se trata este concepto. Es un lenguaje formal y estructurado diseñado con la finalidad de establecer un conjunto de instrucciones y procesos para controlar el comportamiento tanto físico como lógico de una máquina. De esa forma lo indica Cobo32 quien además da a entender que su estructura, significado de elementos y expresiones están definidas mediante la utilización de símbolos y reglas sintácticas y semánticas. Teniendo en cuenta ello, el proceso por el cual se escribe, prueba, depura y compila el código de un programa recibe por nombre programación.

5.1.6.1 Clasificación de los lenguajes de alto nivel Uno de los lenguajes que se utiliza en el prototipo es de alto nivel, estos lenguajes resultan más sencillos entender para los seres humanos, estos tienen diversas clasificaciones:

5.1.6.1.1 Lenguajes compilados Cobo indica que es aquel lenguaje en donde el código fuente pasa por un proceso llamado compilación33 generando un código objeto el mismo que se enlaza con otros módulos de código objeto, para finalmente crear un archivo ejecutable. Dicho

31 COBO Angel, PHP y MySql. Tecnologías para el desarrollo de aplicaciones web. Madrid: Editorial Diaz de Santos, 2005. 3p. 32 Ibid. 11p. 33 Ibib, 13p.

32

archivo contiene todas las instrucciones del mismo, pero en el formato entendible por la máquina.

5.1.6.1.2 Lenguajes interpretados

Los leguajes interpretados a diferencia de los compilados como señala Cobo34 tienen una aplicación llamada "intérprete", que se encarga de la traducción. La labor que realiza es codificar el código o las instrucciones para comunicarse, por lo que si llega a una posición en el código donde hay una instrucción de error, el programa continuará ejecutándose, pero habrá podido ejecutar todas las instrucciones o declaraciones anteriores. 5.1.7 Bases de datos

Para el proyecto se utiliza una base de datos como complemento al servicio web es por esta razón que es importante lograr asimilar un concepto de estas. Korth lo define como un lugar físico o digital en donde se almacena el conjunto de datos35 que pertenecen a un mismo contexto, estos son almacenados de forma sistemática para su posterior utilización o consulta. Existen dos tipos de bases de datos las relacionales y las no relacionales, las bases de datos relacionales explican Cabello36 son aquellas en donde los datos son organizados mediante un sistema de tablas que se encuentran interrelacionadas lógicamente, los datos deben ser recuperados o almacenados mediante consultas. Por su parte las bases de datos no relacionales están enfocadas en ofrecer una mayor flexibilidad y adaptarse a modelos más específicos por lo que en términos generales resultan más fáciles de desarrollar y escalar.

5.1.8 Frameworks de desarrollo web

Para la construcción del prototipo de servicio web resulta útil emplear frameworks de desarrollo web, y es desde este punto de vista que resulta ideal comprender este concepto. Según explica Gutierrez el concepto de framework no solo se utiliza en el campo de las aplicaciones web,37 sino también en muchas áreas del desarrollo de sistemas

34 Ibib, 14p. 35 KORTH, Henry; SILBERSCHATZ, Abraham. Fundamentos de bases de datos. Cuarta edición. Madrid: McGraw-Hill, 1993. 17p. 36 CABELLO, Victoria. Introducción a las bases de datos relacionales. Vision Libros, 2010. 20p. 37 GUTIÉRREZ, Javier. ¿Qué es un framework web? [En línea]. [20 de abril de 2021]. Disponible en: http://www.lsi.us.es/~javierj/investigacion_ficheros/Framework.pdf

33

de software. Podemos encontrar frameworks para el desarrollo de aplicaciones médicas, visión artificial, desarrollo de juegos y gran variedad de otros campos. Generalmente, el término se refiere a una estructura de software compuesta de componentes personalizables e intercambiables para desarrollar aplicaciones. En otras palabras, el framework se puede considerar como una aplicación general incompleta y configurable, a la que podemos agregar el contenido final para construir una aplicación específica.

5.1.9 Lenguaje Unificado de Modelado

Para lograr dar cumplimiento a los objetivos del proyecto, especialmente en lo que se refiere a documentación y diagramación, es importante contar con una serie de reglas que permitan la lectura de lo que se quiere transmitir con las diferentes representaciones, UML proporciona un marco para avanzar en esa dirección. El UML (Unified Modeling Language) es una definición oficial de un lenguaje pictórico con símbolos y relaciones comunes que tienen un significado común. Si todos los participantes hablan UML, entonces las imágenes tienen el mismo significado para todos aquellos que las observen.38 UML actualmente es el lenguaje de modelado más famoso para realizar el modelado de software, el cual permite especificar los métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. Este lenguaje de modelado está formado por diferentes tipos de diagramas, aunque los más relevantes se detallan a continuación:

5.1.9.1 Diagramas de casos de uso Los diagramas de casos de uso son responsables principalmente de documentar los macro requisitos del sistema. Los diagramas de casos de uso como la lista de las capacidades que debe proporcionar el sistema.39 está constituido de dos símbolos: el actor y un círculo que representa el caso de uso. 5.1.9.2 Diagramas de actividad Un diagrama de actividades es una herramienta excelente para analizar los problemas que al final el sistema deberá resolver.40 ayuda a detectar qué procesos se siguen para alcanzar un objetivo dentro del software y ayuda a detectar cuales pueden ser sometidos a reingeniería.

38 KIMMEL, Paul. Manual de UML. McGraw-Hill Interamericana, 2002. 1p. 39 Ibid, 17p. 40 Ibid, 81p.

34

5.1.9.3 Diagramas de clase Los diagramas de clases se usan para mostrar las clases de un sistema y las relaciones entre ellas. Una sola clase puede mostrarse en más de un diagrama de clases y no es necesario mostrar todas las clases en un solo diagrama monolítico de clases. 41 el valor que aportan es mostrar las clases y sus relaciones desde varias perspectivas. 5.1.9.4 Diagramas de interacción Existen dos tipos de diagramas de interacción la secuencia y la colaboración. Ambos transmiten la misma información, empleando una perspectiva un poco diferente. Los diagramas de secuencia muestran las clases a lo largo de la parte superior y los mensajes enviados entre esas clases, modelando un solo flujo a través de los objetos del sistema. Los diagramas de colaboración usan las mismas clases y mensajes, pero organizados en una disposición espacial. 42

5.1.10 Prototipo

El principal resultado que busca el proyecto es la construcción de un prototipo, al ser un pilar del proyecto debemos tener claro este concepto. Según explica Angeles-Angeles el prototipo es el primer modelo que se puede utilizar como representación o simulación del producto final,43 este permite verificar el diseño y confirmar que tiene las características específicas recomendadas, sin embargo, para obtener mejores resultados este autor recomienda que se considere ciertas consideraciones y procesos, elementos y otras herramientas útiles para capturar las mejores recomendaciones de productos o servicios.

5.1.11 Arquitectura de microservicios

El prototipo de servicio web se construye utilizando la arquitectura de microservicios, en consecuencia, es de importancia comprender a que se hace referencia al hablar de esta arquitectura. Barrios indica que todavía no existe un consenso sobre la definición de este tipo de arquitecturas ya que solo hasta 2011 se comenzó a hablar de forma estructurada

41 Ibid, 157p. 42 Ibid, 162p. 43 ANGELES-ANGELES, Francisco. Prototipo. Ciudad de México: Con-Ciencia Boletín Científico de la Escuela Preparatoria, 2020, 33p.

35

de la arquitectura de microservicios 44, sin embargo, señala que si se puede realizar la definición mediante el análisis de las características de esta arquitectura los cuales si han sido discutidos en la comunidad académica y que se centran en construir una aplicación como rompa con lo que plantea el sistema monolítico de la unión de tres partes: la parte cliente, la parte encargada del manejo de datos y la parte servidor que contiene la lógica de dominio de la aplicación. El emplear un estilo monolítico en aplicaciones puede tener buenos resultados, sin embargo, el paso del tiempo ha generado que estos modelos tengan cada vez más problemas, de esa forma la arquitectura de microservicios se convierte en una alternativa a los modelos monolíticos en donde se pueden abstraer más de las tres capas clásicas.

5.1.12 SaaS (Software as a service)

El prototipo en un entorno de producción podría desplegarse como un software como servicio y se hace relevante entender este concepto. Este hace referencia a un modelo de distribución comercial dónde las aplicaciones se encuentran alojadas en un proveedor de servicios y acá se ponen a disposición de los usuarios por medio de internet u otra red establecida. SaaS es otra de las grandes arquitecturas orientadas a servicios dónde estás aplicaciones comúnmente interactúan con datos y aplicaciones en distintas variedades teniendo así un amplio contacto entre los mismos entornos de desarrollo y páginas web o plataformas.45 Las SaaS se usan para uso comercial, así estas buscan brindarles a los clientes unos beneficios que el software contiene de forma interna en los servicios ofrecidos y este software como servicio usa una licencia de uso comercial donde su valor puede variar dependiendo los servicios que se ofrezcan.

5.1.13 Calidad del software

El último objetivo específico del proyecto se refiere a validar el prototipo mediante la utilización de pruebas de software que buscan verificar aspectos de la calidad del mismo, resulta notable comprender este concepto. Para la definición de calidad de software podemos tomar dos referentes, el primero es Pressman quien en 1992 la definió como “Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado profesionalmente”.

44 CONTRERAS, Diego. Arquitectura de microservicios. Bogotá: Tecnología Investigación Y Academia, 2018, 37p. 45 SATYANARAYANA, S. "CLOUD COMPUTING: SAAS". [En línea]. [2012]. Disponible en: https://www.academia.edu/21491005/CLOUD_COMPUTING_SAAS

36

Por otra parte, la ISO 8402 indica de manera más breve que es “el conjunto de características de una entidad que le confieren su aptitud para satisfacer las necesidades expresadas y las implícitas” así lo explica Cueva.46

5.2 MARCO TEÓRICO

5.2.1 Accesibilidad Web 5.2.1.1 Diseño de accesibilidad web W3C se refiere al diseño de sitios web accesibles cuando cumplen condiciones como estar bien codificados y diseñados para que en tal sentido la población con discapacidad logre obtener beneficio de los mismos47, haciendo especial referencia que hoy en día muchos portales web no están diseñados de esta manera, lo que se configura en una barrera de accesibilidad. Con esto en mente la W3C plantea pautas de accesibilidad, estas pautas consideran no solo diversas discapacidades, sino también su aplicación. Se dan recomendaciones como ayude a las personas a utilizar mejor el sitio web y su contenido, las personas mayores pueden tener reducida su capacidad de interacción debido a la edad. Del mismo modo, los estándares de accesibilidad web diseñados por W3C se considera disponible para múltiples tecnologías, como navegadores, Pantalla, etc. 5.2.1.2 Estándar W3C La institución de más alta en la jerarquía de Internet responsable de la promoción de Internet. El Consorcio World Wide Web 48 (W3C) especialmente su accesibilidad Comité de trabajo de la Iniciativa de Accesibilidad Web (WAI). En 1999, WAI lanzó la versión 1.0 Su guía para la accesibilidad web. Con el tiempo, se han convertido en referentes Reconocido internacionalmente. En diciembre de 2008, se aprobó WCAG 2.0 Como recomendación oficial. Estas pautas se dividen en tres partes:

• Pautas de accesibilidad al contenido web (WCAG): Para usuarios, el webmaster ayudando a indicar cómo hacer accesible el contenido del sitio web.

• Pautas de accesibilidad para herramientas de creación (ATAG): Para usuarios desarrolladores de software con la finalidad de promover la creación de sitios accesibles.

46 CUEVA, Juan. Calidad del Software. Pamba: Grupo Gidis Universidad Nacional de la Pamba, 1999. 3p. 47 W3C. Introducción a la Accesibilidad Web. [En línea]. [21 de abril de 2021]. Disponible en: https://www.w3.org/WAI/fundamentals/accessibility-intro/es 48 W3C. Web Content Accessibility Guidelines (WCAG) 2.0. [En línea]. [9 de abril de 2021]. Disponible en: https://www.w3.org/

37

• Pautas de accesibilidad del agente de usuario (UAAG): Para usuarios de tipo agente de usuario (navegador, etc.) con la finalidad de que el programa facilite accesibilidad a todos los usuarios que visiten el sitio web.

5.2.1.3 Pautas de accesibilidad al contenido en la web WCAG

La WCAG establece pautas detalladas49, pero pueden ser resumidas de la siguiente manera:

• Pauta 1 "Proporcione alternativas equivalentes para el contenido visual y auditivo".

• Pauta 2 “No se base solo en el color”.

• Pauta 3 "Utilice marcadores y hojas de estilo. Y hágalo apropiadamente".

• Pauta 4 “Utilice el idioma original usado”.

• Pauta 5 “Cree tablas que se transformen correctamente”.

• Pauta 6 “Asegúrese de que las páginas que incorporan nuevas tecnologías se transformen correctamente”.

• Pauta 7 “Asegure al usuario el control sobre los cambios de los contenidos tempo-dependientes”.

• Pauta 8 “Asegure la accesibilidad directa de las interfaces de usuario incrustadas”.

• Pauta 9 “Diseñe para la independencia del dispositivo”.

• Pauta 10 “Utilice soluciones provisionales”.

• Pauta 11 “Utilice las tecnologías y pautas W3C”.

• Pauta 12 “Proporcione información de contexto y orientación”.

• Pauta 13 “Proporcione mecanismos claros de navegación”.

• Pauta 14 “Asegúrese de que los documentos sean claros y simples”.

5.2.1.4 Tecnología de accesibilidad La tecnología de asistencia puede ayudar a las personas con discapacidades a vivir de forma independiente, realizar tareas y participar en actividades comunitarias como actividades para mejorar las perspectivas laborales. Los lectores de pantalla proporcionan una interfaz para presentar información en forma de voz sintetizada o Braille. En segundo lugar, la lupa de pantalla presenta una parte ampliada del contenido de la pantalla para los usuarios con alguna discapacidad visual. Hay muchas aplicaciones de software de código abierto y gratuitas para visualización. Como Reader que se ejecuta en sistemas Mac OS y Linux. En términos de lectores de pantalla, el más popular (fuera de los productos comerciales de JAWS) es Non-Visual Desktop Access (NVDA), que se ejecuta en Windows. Una encuesta de

49 Ibid.

38

WebAIM muestra que el lector de pantalla principal más utilizado es JAWS (50%), seguido de NVDA (18,6%) y VoiceOver (10,3%)50. 5.2.2 Evaluación y pruebas de accesibilidad Al desarrollar o rediseñar un sitio web y al evaluar la accesibilidad al principio de todo el proceso de desarrollo, los problemas de accesibilidad se pueden detectar temprano cuando son más fáciles de resolver. Las técnicas simples (como cambiar la configuración en los motores de búsqueda) pueden determinar si una página web cumple con ciertas pautas de accesibilidad. Para determinar el cumplimiento de los criterios, una evaluación exhaustiva es mucho más complicada. Las herramientas de evaluación se pueden utilizar para ayudarnos a realizar una evaluación de accesibilidad. Sin embargo, no existe una herramienta por sí sola que pueda determinar si un sitio web cumple con las pautas de accesibilidad. Para determinar si se puede acceder al sitio web, se debe realizar una evaluación manual51.

5.2.2.1 Pruebas Automatizadas Para McLellan, las herramientas de prueba automatizadas son muy adecuadas para identificar elementos faltantes que se utilizan en el contexto de accesibilidad, porque tales herramientas pueden probar todo el sitio en un período de tiempo relativamente corto. Las herramientas automatizadas son particularmente buenas para detectar problemas técnicos, como etiquetas ALT faltantes en imágenes, validación de documentos HTML, uso incorrecto de la estructura (es decir, título) y problemas de contraste de color (en texto). Las herramientas automatizadas, si bien son útiles para el diagnóstico de sitios a gran escala, son inciertas en su capacidad para identificar todos los problemas en la red.52 5.2.2.2 Pruebas Manuales En las pruebas manuales, el revisor manual, identificación de expertos revisan las desviaciones y sugerencias para corregir según sea necesario la accesibilidad y calidad del sitio web. También se trata de recopilación de datos Usuario (encuesta, prueba de usuario, Etc.) lo que se debe hacer o Evaluación manual. Los usuarios que utilizan este método tienen un conocimiento sólido de cómo usar WCAG 2.0 para evaluar el contenido web, el diseño web accesible, la tecnología de asistencia y cómo las personas con diferentes discapacidades usan la web. Esto incluye la comprensión de la tecnología web; las barreras de accesibilidad que encuentran las personas con discapacidades; las tecnologías de asistencia y los métodos de

50 MAISAK, Rattanavalee.Op. cit 45p. 51 Ibid, 47 p 52 Ibid, 50 p

39

adaptación utilizados por las personas con discapacidades; y las técnicas, herramientas y métodos de evaluación para identificar las barreras para las personas con discapacidades.53 5.2.2.3 Pruebas Expertas Según el Consorcio World Wide Web 54, "La evaluación integral y eficaz requiere que los evaluadores comprendan las tecnologías de red, las herramientas de evaluación, las barreras experimentadas por las personas con discapacidades, las tecnologías y métodos de asistencia utilizados por las personas con discapacidades y las pautas y tecnologías de accesibilidad". Mientras tanto Law y McKay55 señalaron que la evaluación de la accesibilidad tradicional se centra en las pautas, pero algunas pruebas sugieren que los desarrolladores y programadores deben estar incluidos en el proceso de evaluación de la accesibilidad, porque los programadores son esencialmente personas que desarrollan código para sitios web. Si no comprenden el concepto de accesibilidad, no evaluarán ni corregirán el problema durante el desarrollo. Yesilada, Brajnik y Harper56 descubrieron que la calidad de la evaluación de accesibilidad depende del número real de personas que se consideran "expertos". Además, las evaluaciones de expertos brindan beneficios mucho mayores que las evaluaciones de no expertos. Por ejemplo, dediqué menos tiempo a evaluar Y mejorar la eficiencia, seguridad y confiabilidad del trabajo.

5.3 MARCO LEGAL

En la siguiente tabla se describen las regulaciones y normativas que pueden ser aplicadas, rigen o tienen relación con las actividades y productos elaborados en este trabajo de investigación:

53 Ibid. 51 p 54 Ibid.51 p 55 Ibid.51 p 56 HARPER, Simon; YESILADA Yeliz. Accessibility and Guidelines: Web Accessibility. Mánchester. 2008. 3p.

40

Tabla 2. Normativa y regulaciones

Ley/Norma Entidad Contenido Año

Artículo 13 de la Constitución Política de Colombia57

ASAMBLEA NACIONAL CONSTITUYENTE 1991

“(…) El Estado promoverá las condiciones para que la igualdad sea real y efectiva y adoptará medidas en favor de grupos discriminados o marginados.

El Estado protegerá especialmente a aquellas personas que por su condición económica, física o mental, se encuentren en circunstancia de debilidad manifiesta (…)”

1991

Relación con el proyecto: El artículo 13 de nuestra carta política considera que se debe garantizar una igualdad real para grupos marginados o que por su condición física se encuentren en debilidad manifiesta, esto implícitamente debe llamarnos a contribuir activamente en la construcción de la misma desde las diversas áreas del conocimiento, este precisamente es uno de los pilares desde los que se fundamenta el proyecto.

Ley Estatutaria 1618 de 201358

CONGRESO DE LA REPUBLICA

“Por medio de la cual se establecen las disposiciones para garantizar el pleno ejercicio de los derechos de las personas con discapacidad.”

2013

Relación con el proyecto: Esta ley estatutaria busca garantizar el pleno ejercicio de los derechos de las personas con discapacidad, en su artículo 16 ratifica el derecho de estas personas a la información y las comunicaciones, en su apéndice primero ordena que “El Ministerio de Tecnologías de la Información y las Comunicaciones (TIC) adelantará un proyecto que permita masificar la utilización de software libre de los programas para personas con discapacidad.”, esto resultó

57 COLOMBIA. ASAMBLEA NACIONAL CONSTITUYENTE 1991. Constitución Política de Colombia. En: Gaceta Constitucional No. 116 de 20 de julio de 1991. p. 3. 58 COLOMBIA. CONGRESO DE LA REPÚBLICA. Ley 1618. (27, febrero, 2013). Por medio de la cual se establecen las disposiciones para garantizar el pleno ejercicio de los derechos de las personas con discapacidad. En: Diario Oficial. Febrero, 2013. Nro. 48717. p. 1.

41

en las iniciativas como ConVerTic en el cual en el marco de este proyecto es tenido en cuenta tanto para referencia, como para dar recomendaciones en donde se puede mejorar su aplicación.

Ley 361 de 199759


“Por la cual se establecen mecanismos de integración social de las personas en situación de discapacidad y se dictan otras disposiciones”

1997

Relación con el proyecto: Conocida también como “Ley de discapacidad”, establece obligaciones y responsabilidades para la implementación de políticas, estrategias, planes y medidas que apoyen la integración de las personas con discapacidad a la sociedad; específicamente, el gobierno nacional debe tomar las medidas necesarias a través del MinTIC para proteger los derechos de información de los discapacitados. El proyecto se enfoca en favorecer el acceso a la información en la web por lo que existe una concordancia entre lo expresado en esta y propósito del proyecto.

Ley 1346 de 200960


Por medio de la cual se aprueba la “Convención sobre los Derechos de las personas con Discapacidad”, adoptada por la Asamblea General de la Naciones Unidas el 13 de diciembre de 2006.

2009

Relación con el proyecto: Mediante esta ley se ratificó la Convención sobre los derechos de las personas con discapacidad, esto implica el compromiso de los países que la ratifiquen de realizar o promover la investigación, el desarrollo, promover la disponibilidad y el uso de nuevas tecnologías, incluidas las tecnologías de la información al servicio de personas con discapacidad. Es por ello que probablemente iniciativas como este proyecto puedan recibir promoción por parte del estado contribuyendo a su viabilidad.

59 COLOMBIA. CONGRESO DE LA REPÚBLICA. Ley 361. (07, febrero, 1997). Por la cual se establecen mecanismos de integración social de las personas en situación de discapacidad y se dictan otras disposiciones. En: Diario Oficial. Febrero, 1997. Nro. 42978. p. 1-3. 60 COLOMBIA. CONGRESO DE LA REPÚBLICA. Ley 1346. (31, julio, 2009). Por medio de la cual se aprueba la “Convención sobre los Derechos de las personas con Discapacidad”, adoptada por la Asamblea General de la Naciones Unidas el 13 de diciembre de 2006. En: Diario Oficial. Julio, 2009. Nro. 47427. p. 2.

42

Ley 1680 de 201361


“Por la cual se garantiza a las personas ciegas y con baja visión, el acceso a la información, a las comunicaciones, al conocimiento y a las tecnologías de la información y de las comunicaciones.”

2013

Relación con el proyecto: Esta ley fue emitida para "garantizar el acceso autónomo e independiente de las personas ciegas y con baja visión, a la información, a las comunicaciones, al conocimiento, y a las tecnologías de la información y las comunicaciones, para hacer efectiva su inclusión y plena participación en la sociedad."

En su artículo 6 y 7 se les ordena la adquisición e instalación de un software lector de pantalla, la capacitación a la población y a los servidores públicos, y se asignó la labor de coordinación a cargo del MinTIC, en este marco los softwares escogidos fueron JAWS y ZoomText. Softwares a los cuales se busca generar una alternativa mediante la realización del presente proyecto

Finalmente, en su artículo 14 se aseguraron los recursos para su sostenibilidad en el tiempo: "el Gobierno Nacional realizará las operaciones presupuestales necesarias para el cabal cumplimiento y sostenimiento a largo plazo de lo dispuesto en la presente ley."


61 COLOMBIA. CONGRESO DE LA REPÚBLICA. Ley 1680. (20, noviembre, 2013). Por la cual se garantiza a las personas ciegas y con baja visión, el acceso a la información, a las comunicaciones, al conocimiento y a las tecnologías de la información y de las comunicaciones. En: Diario Oficial. Noviembre, 2013. Nro. 48980. p. 1.

43

6. ESTADO DEL ARTE

6.1 ESTRATEGIA DE BÚSQUEDA DOCUMENTAL

Se construyó la siguiente ecuación de búsqueda con el objetivo de segmentar y recopilar información relevante de bases de datos bibliográficas como parte de la estrategia de búsqueda documental:

TITLE-ABS-KEY ( ( ( web AND accessibility OR accessibility ) AND blind ) )

Al procesar los resultados obtenidos de la aplicación de la ecuación en la base de datos documental Scopus, una de las más relevantes, se pudo construir la siguiente relación entre cantidad de documentos publicados contra la fecha de su publicación:

Figura 4. Documentos por año


Realizando un análisis de los resultados bibliográficos encontramos que desde el año 2007 en interés de la comunidad académica se incrementó, aunque no existen investigaciones suficientes ya que no se cuentan con cientos de publicaciones anuales como si sucede con otras áreas del conocimiento.

44

Figura 5. Documentos por autor


De dichos documentos el autor que más ha contribuido es Ramakrishnan con 24 documentos relacionados producidos y publicados por lo que se convierte en el autor seminal para este proyecto.

6.2 ANTECEDENTES DE INVESTIGACIÓN

Dentro de la búsqueda documental se han encontrado papers de relevancia los

cuales se resumen y relacionan a continuación con su principal aporte investigado:

6.2.1 Accesibilidad web

Antiguamente, a medida que el internet iba creciendo y se estaba generando un

impacto en el desarrollo tecnológico, era de esperarse que estos servicios que

estaban surgiendo también tuvieran un enfoque de inclusión hacia las personas con

discapacidad, es por esto que personas como Angkananon, Wald y Ploadaksorn

recalcan la importancia de la accesibilidad web y afirman que “La Web se creó para

todos, independientemente de la cultura, la tecnología o la capacidad y tiene el

potencial de eliminar barreras sin barreras para las personas con discapacidad si se

45

diseña de manera accesible. El acceso a la información web es un derecho humano

básico”. 62

Según el artículo 25 de la Declaración Universal de Derechos Humanos, una

persona tiene "derecho a la seguridad en caso de desempleo, enfermedad,

discapacidad, viudez, vejez u otra falta de sustento en circunstancias que escapen

a su control" por lo que es un requisito para todos los signatarios de la declaración

como Colombia implementar actividades y programas para asegurar que no haya

discriminación contra las personas con discapacidad como lo sugiere Maisak.63

Debido a lo anterior, en 1999 la W3C (World Wide Web Consortium) desde la

Iniciativa de Accesibilidad Web (WAI) recomendó una serie de pautas denominadas

Las Pautas de accesibilidad al contenido web (WCAG) donde actualmente en su

versión 2.1 cubren una amplia gama de recomendaciones para hacer que el

contenido web sea más accesible.

Para Harper y Yesilada seguir estas pautas hará que el contenido sea más

adecuado para las personas con discapacidad 64, incluidas las indicaciones para

ceguera, baja visión, sordera, pérdida auditiva, movilidad, entre otras. Las

indicaciones son limitadas, y desafortunadamente no pueden satisfacer todas las

necesidades de los usuarios de estas personas discapacitadas. Sin embargo, estas

pautas abordan la accesibilidad del contenido web en computadoras de escritorio,

computadoras portátiles, tabletas y dispositivos móviles por lo cual seguir estas

pautas también hará que el contenido web sea más útil para los usuarios comunes.

Teniendo en cuenta lo anterior, surge un término conocido como eSystems que

Petrie y Bevan lo definen como sistemas especializados para la inclusión de

personas con discapacidades 65, estos incluyen lectores de pantalla para usuarios

ciegos para computadoras y sistemas mejorados y otras alternativos basadas en

computadoras. sistemas de comunicación para personas con discapacidades del

habla y el lenguaje.

62 ANGKANANON, Kewalin; WALD, Mike; PLOADAKSORN, Piyabud. Development and testing of a thai website accessibility evaluation tool. vol 10. Tailandia. 2020. 4901p. 63 MAISAK, Rattanavalee.Op. cit 34p. 64 HARPER, Simon; YESILADA Yeliz. Op. cit 6p. 65 PETRIE, Helen; BEVAN, Nigel. The Evaluation of Accessibility, Usability, and User Experience. vol 10. Londres, 2009. 9p.

46

6.2.2 Desarrollo de una página web accesible

Para el desarrollo de estos nuevos sistemas que permitieran accesibilidad web se

inventaron varios aplicativos que permitiera el acceso a la información de una

página web que claramente tendría que cumplir con las pautas anteriormente

nombradas generando diferentes tipos de patrones de diseño.

Cada patrón en nuestro idioma describe un problema que se encuentra

comúnmente en el diseño de RIA accesibles. Los sitios web deben ser cada vez

más dinámicos y ofrecer a los usuarios experiencias de interacción avanzadas

cercanas a las aplicaciones de escritorio. Sin embargo, plantean varios desafíos de

accesibilidad. Las personas con discapacidad visual, por ejemplo, encuentran

dificultades para enfrentarse con las actualizaciones dinámicas en diferentes áreas

de la página o para administrar widgets interactivos y controles personalizados,

algunos de estas iniciativas para estos desafíos son WCAG y WAI-ARIA.66

El diseño del Portal Web con Patrones de Accesibilidad fue diseñado para la

Inserción Laboral de personas con ceguera, el cual responde a la necesidad de

contar con un espacio amigable en la web, que permita a las personas con

diferentes grados de discapacidad visual (genética o adquirida) la oportunidad para

ingresar información personal, así como su perfil de trabajo en el que puede

desempeñarse la persona con ceguera.67

Para la elaboración de las aplicaciones web accesibles se necesita poseer el texto

que aparece en pantalla, así que Sidick68 considera que fangs es una buena

herramienta de extracción de texto ya que traduce páginas web en texto

representante de lo que dirá el lector de pantalla. Con esta herramienta es muy fácil

verificar el orden de las páginas.

Por otro lado, también se encuentra el desarrollo de Scrapy el cual es un marco

colaborativo y de código abierto para extraer los datos que necesita de los sitios

web. De una forma rápida, sencilla pero ampliable69.

66 FORGLI, Daniela; PROVENZA, Loreadana; BERNAREGGI, Cristian. A Design Pattern Language for Accessible Web Sites. Brescia y Milano, 2014. 67 GUERRERO, Javier; MOCHA-BONILLA, Julio; ZAPATA-MOCHA, Esmeralda; Rios, Sandra. Design of an Accessible Web Portal for the Labor Insertion of people with blindness. IMLC 2019 y AISC 1192. Ambato: Springer Nature Switzerland, 2021 68 SYDIK, Jeremy. Design Accessible web sites: Thirty-six Keys to creating content for all audiences and platforms. Estados Unidos, 2007. 74p. 69 PINA, Alessandro; BAEZ, Marcos y DANIEL, Florian. Bringing Cognitive Augmentation to Web Browsing Accessibility. Milan, 2020. 8p.

47

Y por último una herramienta que permite analizar las páginas para extraer sus

componentes y que Daniel, Pina y Baéz recomiendan es beautiful soup 70 ya que es

una biblioteca de Python para analizar documentos HTML. La biblioteca crea un

árbol que contiene todos los elementos del documento, que se puede utilizar para

extraer información.

También se tiene que tener en cuenta el uso de los navegadores ya que Los

navegadores normalmente usan filtrado de datos, esto impide acceder al contenido

de la página de raíz, por eso Maurel, Días, Routoure y Beust elaboraron un

navegador web llamado tactoweb 71 y este navegador es trabajable en páginas

accesibles ya que es un navegador web multimodal que permite a las personas con

discapacidad visual navegar por el espacio de las páginas web gracias a la

retroalimentación táctil y de audio. ordena y adapta la información basándose en el

análisis de la estructura del árbol del Document Object Model (DOM).

Ya con estos avances en accesibilidad web, se empieza a generar diferentes tipos

de solicitudes para que las personas con discapacidad visual se unan más a este

campo, es así como nace el término de accesibilidad urbana. Fogli y Arenghi

comentan que la accesibilidad urbana plantea un desafío para varias ciudades del

mundo 72. Importantes documentos internacionales, especialmente la Agenda 2030

para el Desarrollo Sostenible de las Naciones Unidas, especialmente los Objetivos

de Desarrollo del Milenio, y la Nueva Agenda Urbana Hábitat III, destacan este

desafío de igual forma. Cualquiera, especialmente los discapacitados, puede

necesitar seguir la ruta más adecuada y favorita (a pie, automóvil privado o

transporte público) mediante un sistema que les ayude para llegar a diferentes

partes de la ciudad. Esto requiere comprender las características de gestión

espacial, de distribución y organizativa de los lugares y servicios de la ciudad.

Y de esto nace también el término de Navegación web conversacional que

básicamente es una interacción de lenguaje natural basada en diálogos con los

sitios web. Daniel, Pina y Baéz 73 especifican que el objetivo de usar este tipo de

sistemas es permitir que los usuarios utilicen el contenido y las funciones accesibles

70 Ibid, 9p. 71 MARUEL,Fabrice; DIAS,Gaël; SAFI, Waseem; ROUTOURE, Jean-Marc Y BEUST, Pierre. Layout Transposition for Non-Visual Navigation of Web Pages by Tactile Feedback on Mobile Devices.Syria,2020. 4p. 72 FOGLI, Daniela; ARENGHI, Alberto; GENTILIN, Fulvio. A universal design approach to wayfinding and navigation. Italia,2019.6p. 73 PINA, Alessandro; BAEZ, Marcos y DANIEL, Florian. Op. cit 5p.

48

a través de las IU renderizadas "hablando con los sitios web" en lugar de utilizar la

IU gráfica con el teclado y el mouse.

Pero no todas las sugerencias van referidas a un sistema que genere una facilidad

mayor en el uso de la voz, también Ivanova y Mitev 74 proponen un teclado accesible

para las prácticas estándar en cuanto a usabilidad. Su esencia radica en garantizar

que, cuando sea posible, el contenido pueda ser controlado por un teclado de

computadora o dispositivo similar con letras y manejo de este en braille.

6.2.3 Probar una aplicación web accesible

Existen distintas aplicaciones que se fueron creando con la finalidad de verificar si

una página cumple con las normas de WCAG para la accesibilidad web.

Es por eso que iniciando las primeras normas con la WAI (Web Accessibility

Initiative), ya había aplicaciones como Bobby 75 que es una herramienta de

evaluación que utiliza las herramientas para evaluar la accesibilidad de las páginas

web frente a los usuarios con discapacidad, realizando acciones como verificar la

presencia de características específicas o sus funciones, aunque no comprueba

explícitamente la sintaxis HTML y además se ha utilizado para evaluar la

accesibilidad y la usabilidad en 25 países incluido Reino Unido.

Lamentablemente al salir las pautas WCAG, Bobby no fue la mejor para

acomodarse a las nuevas normas, por lo tanto, tuvo que ser cerrada en 2008, dando

paso así a aplicativos como Cynthia says donde Sidick indica que para probar

páginas individuales en sitios web Cynthia es la más optima 76 ya que proporciona

comentarios en un formato de informe que identifica errores en el contenido web

relacionados con los estándares de la Sección 508 y las pautas de WCAG para la

accesibilidad web. Aunque indican que no es muy eficiente para sitios web grandes.

Otra herramienta para probar y una de las mejores herramientas para evaluar

aplicaciones accesibles para Sidick77. WAVE puede identificar muchos errores de

accesibilidad y "Pautas de accesibilidad al contenido web" (WCAG), pero también

ayuda en la evaluación manual del contenido web. Nuestra filosofía es centrarnos

74 IVANOVA, Desislava; MITEV, Daniel. Usability strategy and guidelines for building an accessible web portal. ed 1. Bulgaria: AIP Publishing. 2021. 3p. 75 BOWEN, Jonathan. WEB ACCESS TO CULTURAL HERITAGE FOR THE DISABLED. Londres, 2003. 76 SYDIK, Jeremy. Op. cit 73p. 77 SYDIK, Jeremy. Op. cit 75p.

49

en cuestiones que sabemos que afectarán a los usuarios finales, promover la

evaluación manual y educar sobre la accesibilidad web.

6.3 DESARROLLOS PREVIOS

Se realizó también una búsqueda para encontrar que desarrollos previos ya existen en producción que apunten hacía la accesibilidad web, los más relevantes se detallan a continuación:

6.3.1 JAWS

JAWS es un lector de pantalla para los usuarios que posean un tipo de discapacidad visual. 78 Este software se convierte en un compañero el cual le va leyendo la pantalla en voz alta, es compatible con distintas aplicaciones, por esto muchas aplicaciones suelen usarla como un referente el cual les va a brindar características versátiles y opciones para adaptarlas a sus softwares específicos de creación enfocados en nuevas necesidades y preferencias.

Figura 6. Software JAWS

Fuente: Orientatech.Lector de pantallas JAWS for Windows, 2019.

6.3.2 NonVisual Desktop Access

Este software brinda la información por medio de la voz, ya que este posee un sistema de sinterización de voz, así las personas con discapacidad visual pueden guiarse a través de los computadores además que se utiliza también con sistema integrado de braille. Este software solo se puede usar en Windows 79.

78 MORA, Sergio. JAWS. [En línea]. [25 de marzo de 2021]. Disponible en: http://accesibilidadweb.dlsi.ua.es/?menu=jaws 79 NV Access. About NVDA. [En línea]. [25 de marzo de 2021]. Disponible en: https://www.nvaccess.org/about-nvda/

50

Figura 7. Software nonVisual Desktop Access

Fuente: NV Access. NV Access: Empowering lives through non-visual access to technology. St Lucia South, 2021.

6.3.3 Lector de pantalla Orca

Orca es un lector de pantalla gratuito, abierto, flexible y extensible que puede acceder los diferentes entornos del computador a través de voz y braille, aunque una desventaja es que solo está disponible para sistemas Linux y Unix. 80.

Figura 8. Lector Orca

Fuente: GNOME. Tecno Accessible: Orca. Redwood, 2021.

6.3.4 Lector de pantalla Supernova

El lector de pantalla SuperNova fue desarrollado para usuarios con discapacidad visual que usan computadoras, es un lector de pantalla que puede funcionar leyendo pantallas interactivas y comunicándose mediante sistemas integrados de voz o braille fáciles de actualizar 81.

Figura 9. Lector Supernova

80 GNOME. Bienvenido/a a Orca. [En línea]. [25 de marzo de 2021]. Disponible en: https://help.gnome.org/users/orca/stable/introduction.html.es 81 DOLPHIN COMPUTER ACCESS LTD. Magnification and screen reading for Windows. [En línea]. [25 de marzo de 2021]. Disponible en: https://yourdolphin.com/en-gb/products/individuals/families/supernova

51

Fuente: Shuttle Themes. SUPERNOVA MAGNIFIER & SCREEN READER FEATURES. Redwood, 2021.

6.3.5 Sistema de acceso To Go

Serotek cooperó con la Fundación AIRE (La accesibilidad es un derecho) para proporcionar a los usuarios una versión en la web de su lector de pantalla de forma gratuita, para que cualquier computadora con conexión a Internet pueda usarlo. Sin embargo, por falta de la iniciativa de Serotek, este sistema no es tan útil en la navegación web. 82

Figura 10. Sistema de Acceso To go

Fuente: Satogo, System Access to Go. 2021.

6.3.6 Sistema de acceso independiente

El software de acceso al sistema de Serotek puede proporcionar accesibilidad ubicua y proporcionar varias configuraciones para adaptarse a diversos estilos de vida y presupuestos. Si usted es un practicante de rehabilitación vocacional que no está familiarizado o no está familiarizado con las computadoras, System Access es el primer producto que desea presentar. En unos minutos, permitirá que sus estudiantes accedan a Internet, envíen y reciban correos electrónicos, lean y creen documentos y completen formularios. La interfaz intuitiva de Access System y los extensos archivos de ayuda pueden ayudar a los usuarios a aprender las aplicaciones clave que necesitan sin tener que pasar horas en clase aprendiendo a usar sus herramientas auxiliares. Sus estudiantes pronto obtendrán independencia laboral y de estilo de vida. Para la mayoría de las personas, el inicio de sesión es la única herramienta de inicio de sesión necesaria 83.

82 SEROTEK ACCESSIBILITY, ANYWERE; AIR FOUNDATION. System Access to Go. [En línea]. [25 de marzo de 2021]. Disponible en: https://www.satogo.com/en/ 83 PNEUMA SOLUTIONS. Sero: The World’s Largest, Easy-to-Navigate, Social Network and Multi-Media Repository for Blind People on the Web. [En línea]. [25 de marzo de 2021]. Disponible en: https://pneumasolutions.com/products/sero/

52

Figura 11. Software sistema de acceso independiente

Fuente: Compbs, Acceso al sistema, 2021.

6.3.7 Thunder

Es un software de lectura de pantalla de audio gratuito y galardonado para personas con problemas de visión o con problemas de vista. Puede ser perfectamente compatible con Windows 7, Vista o XP. Thunder está disponible en 8 idiomas en todo el mundo.84

Figura 12. Thunder

Fuente: Software.informer. Thunder Screenreader, 2021.

6.3.8 Braille Note

Pertenece a la serie de productos proporcionada por Pulse Data International. Estos incluyen BrailleNote QT, BrailleNote BT, VoiceNoteBT y VocieNoteQT. Todos estos dispositivos se basan en el sistema operativo Windows CE e incluyen módems integrados, puertos de computadora estándar, ranuras PCMCIA tipo II, soporte para servicios de correo electrónico POP3 estándar y Active Synch. Este fue enfocado para que estudiantes puedan enviar y recibir correos electrónicos que incluyan archivos adjuntos con el tomador de notas. Otra característica digna de mención es Active Synch, que permite a los usuarios compartir fácilmente archivos entre el tomador de notas y la computadora.85

84 THE WEBBIE ORGANIZATION. Thunder Screenreader. [En línea]. [25 de marzo de 2021]. Disponible en: https://www.webbie.org.uk/thunder/ 85 HUMANWARE. What is TouchBraille?. [En línea]. [25 de marzo de 2021]. Disponible en: https://www.humanware.com/microsite/bntouch/faq.php#Q5

53

Figura 13. Dispositivo Braille Note

Fuente: Nelowvision. New England Low Vision Bringing and Blindness: Bringing Hope Through Technology, Training & Care, 2021.

6.3.9 Blazie

Incluye un módem incorporado para correo electrónico POP3 y acceso a Internet, una rueda de desplazamiento programable y una tecla de retroceso y teclas enter. La rueda de desplazamiento está diseñada para permitir al usuario desplazarse por línea, oración o párrafo. Tanto BrailleLite Millenium 20 como 40. Ahora vienen con un software llamado ConnectOutloud. Es un producto de Henter Joyce (fabricante de JAWS), que permite el acceso a Internet mediante MS Internet Explorer y el correo electrónico. ConnectOutloud se puede utilizar con servidores de correo electrónico, incluido Microsoft Outlook Express.86

Figura 14. Software Blazie

Fuente: BLAZIE. About Blazie. Our Team and Company Mission, 2021.

6.3.10 KNFB Reader

Simplemente tome una foto del texto impreso y la aplicación lo leerá en voz alta. Se puede configurar para leer diferentes tipos de documentos y puede guiar al usuario a través de comandos de voz y vibración, para que pueda colocar la cámara en la posición correcta al capturar documentos.87

86 BLAZIE. About Blazie. [En línea]. [25 de marzo de 2021]. Disponible en: https://www.blazie.co.uk/site/about 87 NATIONAL FEDERATION OF THE BLIND. KNFB Reader. [En línea]. [25 de marzo de 2021]. Disponible en: https://nfb.org/programs-services/knfb-reader

54

Figura 15. Software KNFB Reader

Fuente: NATIONAL FEDERATION OF THE BLIND. KNFB Reader, 2021.

6.3.11 Tap Tap See

Similar al anterior, pero se puede identificar el objeto. Simplemente tome una foto de la aplicación para describir el tema. La aplicación combina un sistema de reconocimiento automático de imágenes con la ayuda de una persona real que interpreta la imagen. Por ejemplo, se puede usar para encontrar artículos en una habitación que nunca antes se habían visto, averiguar de qué color es una prenda de vestir o poder distinguir una bolsa de café normal de un descafeinado 88.

Figura 16. Tap Tap see

Fuente: CLOUDSIGHT INC. TapTapSee: Assistive Technology for the Blind, 2021.

6.4 ESPECIFICACIÓN DE PALABRAS CLAVE

Dada la aplicación de la estrategia de búsqueda documental, el análisis realizado en los antecedentes de investigación y los desarrollos previos encontrados, podemos establecer las palabras claves para este trabajo, que se relacionan a continuación:

6.4.1 Accesibilidad

Según la norma ISO 25010 89 es el grado en el que un producto o sistema puede ser utilizado por personas con determinadas características y discapacidades.

6.4.2 Servicio Web

88 CLOUDSIGHT INC. TapTapSee: Assistive Technology for the Blind and Visually Impaired. [En línea]. [25 de marzo de 2021]. Disponible en: https://taptapseeapp.com 89 ISO 25000. ISO/IEC 25010. [En línea]. [06 de abril de 2021]. Disponible en: https://iso25000.com/index.php/en/iso-25000-standards/iso-25010.

55

Según un grupo de trabajo de la W3C 90 un servicio web es un sistema de

software diseñado para admitir la interacción interoperable de máquina a máquina

a través de una red, mediante la utilización de diferentes estándares web como

WSDL, SOAP, XML Y HTTP.

6.4.3 Desarrollo de software

Según Raúl Noriega 91 es un proceso que también puede ser llamado “ciclo de vida” o “proceso de software” y que desarrolla una estructura determinada que tiene como objetivo alcanzar una solución de software.

6.4.4 Deterioro visual

La OMS categoriza el deterioro de la visión dentro de la clasificación internacional

de enfermedades y utilizando la medida de la agudeza visual AV determina su

gravedad92.

90 HASS, Hugo. Web Services Glossary. [En línea]. [06 de abril de 2021]. Disponible en: https://iso25000.com/index.php/en/iso-25000-standards/iso-25010. 91 NORIEGA, Raúl. El proceso de desarrollo de software: Proceso de desarrollo de software. Madrid: IT Campus Academy, 2015. 8p. 92 OMS. Ceguera y discapacidad visual. [En línea]. [06 de abril de 2021]. Disponible en: https://www.who.int/es/news-room/fact-sheets/detail/blindness-and-visual-impairment

56

7. METODOLOGÍA

7.1 METODOLOGÍA PROPUESTA

La metodología que se propone para realizar el proyecto es la Metodología Design Research Method (DRM), la cual parte desde la investigación de diseño enfocándose en dos objetivos, por una parte la formulación y validación de modelos y teorías, y por otra parte el desarrollo y validación de los mismos con teorías de apoyo para realizar proyectos de gran calidad, se escoge esta metodología partiendo desde los objetivos específicos ya que estos se pueden correlacionar en los dos objetivos que abarca esta metodología lo que la hace una opción ideal para aplicar.

Por otra parte, haciendo énfasis en el objetivo de construcción del prototipo se plantea una combinación con partes de la metodología SCRUM dada la limitación temporal para el desarrollo del proyecto la cual aporta la utilidad del Sprint 0 donde se entiende el caso del negocio y junto a la combinación de reuniones secuenciales ayuda al rápido desarrollo del proyecto. Teniendo en cuenta lo anterior se plantea la siguiente metodología de trabajo:

Figura 17. Metodología de trabajo


57

El foco principal del prototipo es proveer un servicio web que no dependa de la tecnología JAWS, enfocándose en proveer capacidad de narración auditiva además de evitar elementos visuales de la página como imágenes y textos relevantes, para ello se toma como referencia la página web del INCI donde su apariencia es replicada y además tomara el rol de una página no accesible al no seguir las recomendaciones WGAC, a esta se le integrará un botón el cual permitirá trasladarse a una versión accesible de la página en cuestión y es en donde se podrá interactuar con elementos accesibles.

7.2 TIPO DE INVESTIGACIÓN

Debido a la formulación de este proyecto el tipo de investigación será investigación en diseño, la cual en este contexto podemos entender como una clase de investigación que tiene como objetivo cerrar la brecha entre la teoría y la práctica.

Para ello, este enfoque debe ser ordenado por el diseñador y orientado hacia las necesidades específicas de los antecedentes de la investigación realizada. De esta forma la investigación en diseño es un proceso de interdependencia entre el contexto y el marco teórico, y enfocado en la búsqueda de ideas y prueba de soluciones propuestas.93

7.3 NIVEL DE INVESTIGACIÓN

Dentro de la metodología DRM se consideraría que el nivel de la investigación es un estudio prescriptivo, como se puede observar en esta tabla que recoge los tipos de investigación considerados en esta metodología:

93 LUME, Juan; LAM, Eduardo; YENDO, Rudy; BARRIGA Aránzazu. Guía de investigación en Arte y Diseño.: Methodological Framework. Lima: Pontificia Universidad Católica del Perú, 2019. 14p.

58

Tabla 3. Metodología DRM

Fuente: BLESSING, Luciene; CHAKRABARTI, Amaresh. DRM, a Design Research Methodology: Methodological Framework, 2009. 76p.

El estudio prescriptivo parte de una base de revisión documental realizando un análisis de literatura, a continuación, una comprensión que es realizada a partir del análisis de los datos empíricos y se finaliza con una síntesis que tiene en cuenta la experiencia y lo asumido en la investigación de diseño.94

7.4 METODOLOGÍA COMPLEMENTARIA SCRUM

En un proyecto TI una de las principales características a tener en cuenta es la incertidumbre la cual puede encontrarse en la descripción de necesidades, el alcance, fechas entre otros, Joseph Monte analiza que pueden darse dos aproximaciones clásicas para resolver las incertidumbres,95 de forma predictiva donde puede resolver las incertidumbres antes de comenzar el proyecto y de forma adaptativa donde se puede perfeccionar el proyecto a lo largo del tiempo.

94 BLESSING, Luciene; CHAKRABARTI, Amaresh. DRM, a Design Research Methodology: Methodological Framework. Luxemburgo: Springer Dordrecht Heidelberg London New York, 2009. 76p. 95 GALIANO, Josep. Implantar scrum con éxito: Introducción. Berlin: Editorial UOC, 2016. 13p.

59

Dada la naturaleza del proyecto es conveniente tomar una aproximación predictiva y en dicho caso la metodología SCRUM puede ayudarnos específicamente en la fase de construcción del prototipo, esta metodología está basada en tres pilares:96

• Transparencia: Los aspectos significativos del proceso deben ser conocidospor todos los participantes mediante la utilización de un estándar común.

• Inspección: Los participantes involucrados en el proceso del proyectoevalúan de manera continua los resultados, de forma que las posibles desviaciones que afecten el proyecto son detectadas rápidamente.

• Adaptación: Este pilar permite que la adopción de acciones o planes queayudan a corregir desviaciones en el proyecto sean dadas de forma expedita.

7.5 INTEGRACIÓN PARCIAL DE METODOLOGÍA SCRUM

Se plantea una integración parcial del proyecto con esta metodología específicamente para dar cumplimiento al objetivo de construcción del prototipo ya que teniendo en cuenta también la limitación temporal de 4 meses se requiere alcanzar objetivos rápidamente y utilizar una metodología de desarrollo tradicional resulta poco conveniente al no poderse dar un enfoque predictivo de reducción de riesgos, por otra parte el trabajo se desarrolla de manera conjunta lo que vuelve necesaria la utilización de una metodología que favorezca la comunicación del equipo con enfoque en mejorar la calidad del proyecto.

Figura 18. Metodología SCRUM

Fuente: GALIANO, Josep. Implantar scrum con éxito: Introducción, 2016. 29p.

96 Ibid. Implantar scrum con éxito: Introducción a scrum. 21p.

60

En el anterior diagrama Joseph Monte resume el funcionamiento de la metodología SCRUM97 para el caso de este proyecto la adaptación parcial que se realiza es el Sprint planeado cada dos semanas, es decir un total de 8 sprint, con reuniones de control al término de este tiempo con los roles definidos:

Tabla 4. Definición de roles SCRUM

Rol Encargado

Scrum Master Cristian Camilo Zambrano Lozada

Desarrollador líder y QA Brayan Nicolas Zea Tibaduiza


Como resultado de estas reuniones se espera tener una comunicación constante en forma de equipo de desarrollo donde se describen éxitos y errores parciales, adicionalmente se plantea utilizar y construir el documento de pila de producto también llamado product backlog en donde se tiene un listado completo de las funcionalidades que requiere el prototipo, logrando de esta forma realizar una utilización parcial de la metodología SCRUM junto a DRM.

7.5.1 Roles

Galiano indica que es importante la definición de roles propios de SCRUM, dándonos a entender que muchas veces resulta sencillo identificar los roles del equipo de desarrollo sin embargo no sucede lo mismo con el marco de trabajo 98, es por ello que acá se hace una breve descripción de los roles que se tienen presente en este trabajo de investigación:

7.5.1.1 Scrum Master

El Scrum Master es un facilitador 99 siendo la persona que debe tener una visión global del proyecto, incluyendo tecnología, funciones, etc. Además, cumple funciones de búsqueda de información, pauta el avance conceptual, vigila, promociona y da consejo al equipo además de ser un intermediario frente al product owner haciendo de escudo del equipo frente a presiones externas, es el encargado de acreditar los productos y resultados construidos por el equipo.

97 Ibid, 29 p. 98 Ibid. Una aplicación práctica de Scrum.151p. 99 Ibid, 152 p.

61

7.5.1.2 Desarrollador líder y QA

Es quien juega un rol de liderazgo frente al equipo de desarrollo y el Scrum Master conociendo tanto aspectos técnicos específicos sobre las herramientas y tecnologías utilizadas, así como las posibilidades y alcances del desarrollo, gestionando y acordando los entregables de cada Sprint en términos del producto de software. Además, al tener el rol de calidad también se le confiere la capacidad de crear y evaluar los diferentes escenarios de prueba que permitan tener un mínimo de calidad viable en el software.

7.5.2 Reunión retrospectiva (Sprint retrospective)

Galiano da a entender que en SCRUM más allá de una documentación muy bien diseñada y de alta calidad pensando en formas de contratación lo que busca es darle una mayor importancia a tener actividades que faciliten la comunicación 100 entre las personas involucradas en el equipo.

En este sentido indica que tanto la reunión diaria como la reunión retrospectiva son actividades importantes que tienen como objetivo la mejora continua del equipo de trabajo mediante la coordinación de tareas específicas, con esto en mente es necesario dar cuenta de documentación que permita determinar objetivos de corto plazo que generen un agregado al valor del producto, es por ello que dentro de la metodología se plantea la realización la documentación de las reuniones de retrospectiva realizadas cada dos semanas, evidenciándose los elementos sugeridos por Galindo.

7.5.3 Pila de Producto (Product Backlog)

Como lo describe Galindo el product backlog es la lista de tareas pendientes del producto 101, por lo tanto, es una lista de funciones, productos u operaciones que constituyen el producto que se va a construir. La lista de tareas pendientes del producto está escrita en el idioma del cliente y consta de historias de usuarios, como veremos más adelante. Cada historia se completa y detalla la información necesaria o debida. Debe tener suficiente información para permitir que el equipo calcule elcosto de implementación.

100 Ibid, 145p. 101 Ibid. Roles, artefactos y actividades.55 p.

62

7.6 TÉCNICAS E INSTRUMENTOS

7.6.1 Técnicas

Las principales técnicas que se utilizarán en la investigación son:

● Análisis documental● Experimento

7.6.2 Instrumentos

Los principales instrumentos que serán aplicados en las técnicas son:

● Análisis de contenido● Material experimental

7.7 HERRAMIENTAS DE DESARROLLO

Teniendo en cuenta que uno de los productos de la investigación es un prototipo de servicio web es necesario tener en cuenta las diferentes herramientas y alternativas presentes en el mercado para decidir aquellas que sean las más adecuadas para cumplir con el propósito de la investigación.

7.7.1 Lenguaje de programación

Para el caso de un servicio web el lenguaje de programación lo encontramos principalmente en el backend (lado del servidor) el cual se encarga de procesar la mayoría de solicitudes que estén relacionadas con la lógica del negocio a el manejo o aquellas que también requieran hacer uso de bases de datos.

En el campo del diseño web existen dos lenguajes muy bien posicionados y que en ocasiones se consideran como competencia directa, estos son PHP y Python.

Para lograr tomar una decisión se tuvo en cuenta la investigación realizada por Gazis y Katsiri 102 quienes utilizaron un framework utilizando Python (Flask) y lo compararon contra PHP para el caso de una aplicación web sobre monitoreo del aire con gran cantidad de datos, se compararon varios aspectos sobre un entorno contralado, ejecutando operaciones directas a una base de datos CSV y otra MySQL obteniendo los siguientes resultados:

102 GAZIS, Alexandros; KATSIRI Elefheria. Web Frameworks Metrics and Benchmarks for Data Handling and Visualization: Future work. Xanthi: Department of Electrical and Computer Engineering, 2019. 147p.

63

Tabla 5. Medición de desempeño sobre atributos para peticiones directas

Fuente: GAZIS, Alexandros; KATSIRI Elefheria. Web Frameworks Metrics and Benchmarks for Data Handling and Visualization, 2019. 147p.

Teniendo en cuenta estos datos calculados en unidades de tiempo observamos como en las comparaciones de tiempo de usuario, tiempo de sistema, tiempo de CPU y tiempo de muralla el framework que utilizó Python presenta un mejor desempeño en cuatro de cinco aspectos evaluados manteniendo para el caso presentado el 99% del CPU utilizable.

Basados en estos datos se toma la decisión de optar por Python como lenguaje principal de programación para el back-end del prototipo.

7.7.2 Frameworks

7.7.2.1 Framework back-end

La empresa de desarrollo de aplicaciones Peerbits 103 con presencia en varios países entre ellos Colombia realizó una comparación sobre los que considera los tres mejores framework para desarrollo web Node.js, Laravel y Django 104, resalta varios beneficios de utilizar Django los cuales sintetizamos y resumimos a continuación:

Django permite a los desarrolladores web trabajar de manera simple y ágil implementando la filosofía DRY la cual aboga por no repetir aquello que ya se ha

103 PEERBITS. "Nuestra Historia". [En línea]. [26 de agosto de 2021]. Disponible en: https://www.peerbits.com/our-story.html 104 PEERBITS. "Node.js vs Django vs Laravel: Which is the best back-end web framework in 2021?". [En línea]. [26 de agosto de 2021]. Disponible en: https://www.peerbits.com/blog/nodejs-vs-django-vs-laravel-back-end-web-framework.html

64

hecho, es decir facilita la reutilización del código existente, por otra parte, indican que tiene un énfasis también en la seguridad evitando problemas comunes de seguridad como la inyección a bases de datos y el clickjacking resaltando también que Django implementa constantemente parches de seguridad. Otra de sus bondades es que indican que puede ser utilizado para abordar proyectos de cualquier tamaño indicando que desarrollos importantes como Facebook, Dropbox o Google utilizan este framework en muchos de sus módulos.

Django también permite la sencilla integración de tokens CSRF para la autenticación de formularios donde se envíen datos sensibles, estando también equipado con ORM la cual puede ser usada como una capa de seguridad adicional entre el equipo de desarrollo y datos confidenciales alojados en las bases de datos. Algo que también enfatizan en su análisis es que Django tiene una gran capacidad de escalabilidad y se vuelve muy efectivo para aplicaciones multiplataforma; Respecto a su curva de aprendizaje es el framework que menos tiempo requiere para empezar a trabajar en proyectos pequeños y medianos entre los tres y, por último, aunque no menos importante es que es de código abierto facilitando su utilización plena, por todos los anteriores motivos se decide utilizar Django como framework de back-end.

Para tener una elección más clara de que framework desarrollar se sintetiza la siguiente tabla por atributos:

Tabla 6. Comparación de frameworks por atributos Atributo Node.js Django Laravel

Escalabilidad y rendimiento

Sus características asíncronas y pocos bloqueos permiten a los desarrolladores a administrar múltiples eventos

Cuando la aplicación a diseñar es multiplataforma es ideal Django ya que provee una gran capacidad de escalabilidad y manejo del flujo de trabajo.

No resulta fácil escalar aplicaciones, además de presentar bajo rendimiento al tener varias versiones de la aplicación.

Curva de aprendizaje Se requieren conocimientos previos en JavaScript para tener facilidad de aprendizaje.

Es amigable con el desarrollador ya que sus plantillas son intuitivas, si se tienen conocimientos en Python el aprendizaje es veloz.

Tiene una curva de aprendizaje pronunciada ya que su principal lenguaje PHP requiere de tener en cuenta extensa documentación.

Base del framework Funciona con el motor JavaScript V8 el cual resulta eficiente en aplicaciones web

Funciona siguiendo el modelo, vista, controlador, junto a Python para crear las aplicaciones.

Funciona siguiendo el modelo, vista, controlador, sin embargo, no proporciona soluciones a problemas comunes como el enrutamiento o autenticación.

65

Comunidad Cuenta con 30466 confirmaciones en GitHub.

Cuenta con 28289 confirmaciones en GitHub

Cuenta con 6247 confirmaciones en GitHub.

Seguridad Ofrece una estructura robusta para el código sin embargo a menudo los desarrolladores encuentran algunas lagunas.

Está diseñado para administrar fácilmente vulnerabilidades como los ataques de scripting y da alertas tempranas a los desarrolladores.

Utiliza métodos hash para administrar la seguridad por lo que resulta robusto contra inyecciones SQL y protección de datos privados.


7.7.2.2 Framework front-end

Bootstrap es un framework de front-end que proporciona estilos, herramientas de diseño y un marco de componentes interactivos fáciles de usar, 105 lo que permite a los desarrolladores crear sitios web y aplicaciones visualmente atractivos, ricos en funciones y listos para usar.

Una de las motivaciones más importantes que se tuvo en cuenta a la hora de decidir utilizar este framework es que como ellos mismos lo aseguran 106, es posible que dado un buen uso de esta herramienta debería ser posible crear sitios web y aplicaciones que cumplan con la WCAG 2.1 sección 508 así como estándares y requisitos de accesibilidad similares, siendo esto una característica esencial para este trabajo.

7.7.3 API de narración Web Speech API

La interfaz “Web Speech API” permite incorporar datos de voz dentro de las aplicaciones web 107, una parte de esta es SpeechSynthesis utilizada en este proyecto la cual funciona de forma texto a voz y se vuelve parte esencial del mismo, fue desarrollado por Chris David Mills y otros otorgándole licencia de uso “Creative Commons Zero v1.0 Universal”108, la cual permite su uso privado, modificación, distribución e inclusive su uso comercial.

7.7.4 Lenguaje de marcado

105 BOOTSTRAP. "Introduction". [En línea]. [26 de agosto de 2021]. Disponible en: https://getbootstrap.com/docs/5.1/getting-started/introduction/ 106 BOOTSTRAP. "Accessibility". [En línea]. [26 de agosto de 2021]. Disponible en: https://getbootstrap.com/docs/5.1/getting-started/accessibility/ 107 MDN WEB DOCS. "Web Speech API". [En línea]. [26 de agosto de 2021]. Disponible en: https://developer.mozilla.org/en-US/docs/Web/API/Web_Speech_API 108 GITHUB. "web-speech-api: License". [En línea]. [26 de agosto de 2021]. Disponible en: https://github.com/mdn/web-speech-api/blob/master/LICENSE

66

El lenguaje de marcado que se escoge para el desarrollo de este proyecto es HTML que como lo indica Terán109 resulta útil para proyectos que tengan que hacer manejo de contenidos multimedia en documentos de hipertexto.

También el autor deja claro que HTML no es un lenguaje como Perl, Java o C++ que permite ejecutar instrucciones y realizar operaciones lógicas, sino que este describe la semántica y estructura del documento contenedor, el cual es basado en el estándar DTD SGML110.

Específicamente la versión HTML5 de este lenguaje de marcado ha tenido mejoras en cuanto a su estructura se ha simplificado la semántica como lo ha mostrado Poveda 111 en la siguiente tabla comparativa:

Figura 19. Ejemplo de la estructura de un documento web en XHTML y HTML5

Fuente: POVEDA, Francisco; ORIGEN Y EVOLUCIÓN DE LOS LENGUAJES DE MARCADO: A PROPÓSITO DE XHTML Y HTML5. Trabajo de grado Información

y Comunicación. Murcia.: Universidad de Murcia. Facultad de Comunicación y Documentación. 30 p.

Es por ello que se escoge HTML5 como lenguaje de marcado para optimizar el tiempo de escritura de los documentos que contenga el prototipo.

109 TERÁN, Julián. Manual de Introducción al lenguaje HTML. Formación para el Empleo: ORÍGENES Y EVOLUCIÓN DE HTML. Madrid: Editorial CEP, S.L., 2016. 18p. 110 Ibid. 18 p 111 POVEDA, Francisco; ORIGEN Y EVOLUCIÓN DE LOS LENGUAJES DE MARCADO: A PROPÓSITO DE XHTML Y HTML5. Trabajo de grado Información y Comunicación. Murcia.: Universidad de Murcia. Facultad de Comunicación y Documentación. 30 p.

67

7.7.5 Plataformas de despliegue

Para desplegar los diferentes servicios que componen el prototipo se plantea la utilización de Docker el cual es una herramienta, la cual cuenta con facilidades para la construcción de contenedores partiendo de las instrucciones que se le entreguen mediante un archivo conocido como “Dockerfile”112, en el cual se especifican parámetros de construcción para un contenedor el cual puede actuar como un servicio independiente, adicionalmente como lo muestra Burco y otros autores en la construcción de bigrafos para contenedores en Docker113 aprovechando la utilidad de docker-compose se logra un mayor aprovechamiento de esta herramienta al permitir crearse múltiples contenedores que corren al mismo tiempo mediante la creación de un archivo docker-compose con extensión yaml, facilitando la creación de software bajo la arquitectura de microservicios. La taxonomía general del funcionamiento de Docker, así como una explicación básica de términos y conceptos es resumida en la siguiente figura por Microsoft114:

Figura 20. Taxonomía de términos de Docker y conceptos

112 DOCKER DOCS. "Dockerfile reference". [En línea]. [29 de marzo de 2021]. Disponible en: https://docs.docker.com/engine/reference/builder/ 113 BURCO, Fabio; MICULAN, Marino; PERESSOTTI, Marco. Towards a Formal Model for Composable Container Systems: BIGRAPHS FOR CONTAINERS. Brno: 35th Annual ACM Symposium on Applied Computing, 2020. 174p. 114 MICROSOFT DOCS. "Docker containers, images, and registries". [En línea]. [29 de marzo de 2021]. Disponible en: docs.microsoft.com/en-us/dotnet/architecture/microservices/container-docker-introduction/docker-containers-images-registries

68

Fuente: MICROSOFT DOCS. "Docker containers, images, and registries". [En línea]. [29 de marzo de 2021]. Disponible en: docs.microsoft.com/en-

us/dotnet/architecture/microservices/container-docker-introduction/docker-containers-images-registries

Heroku por otra parte puede ejecutar aplicaciones de gran magnitud ya que esta plataforma alojada en la nube tiene una gran variedad de proveedores de servicios de información, además maneja un componente extra que permite que sea utilizable como una aplicación de desarrollo y permite ejecutar bastantes aplicaciones modernas.115 Esta plataforma fue la escogida como plataforma de despliegue pensando en etapas futuras del proyecto ya que en un entorno de producción maneja un sistema de contenedores el cual permitiría ejecutar de forma estable todos los servicios planteados integrándose a controles remotos entre otras ventajas, adicionalmente al ser una herramienta gratuita se reducirían algunos costos en aquella etapa.

7.7.6 Control de versiones

Para manejar un óptimo control de versiones, la opción escogida es GitLab ya que tiene una facilidad de uso para implementar un control de versiones que permite mantener el control del avance del proyecto, también este sistema permite auto hospedar los repositorios de Git y maneja una licencia MIT lo que hace que sea más sencillo usarlo y manejar los requisitos de propiedad intelectual al necesitarse la mención de los autores para la distribución del código116. Además, este sistema se conecta con facilidad a la plataforma de despliegue mencionada anteriormente.

7.7.7 Pruebas

El aplicativo a desarrollar puede traer a colación dos tipos diferentes de prueba; se necesita realizar pruebas de automatización para determinar el estado del aplicativo y qué fallas puede tener, y además se necesita también realizar pruebas de accesibilidad para obtener el nivel en que se encuentra el aplicativo en temas de las normas requeridas acerca de accesibilidad web, para esto se ha propuesto usar dos aplicativos los cuales son: TestProject para pruebas de automatización y Wave para pruebas de accesibilidad.

TestProject es una herramienta de automatización de pruebas de software de fácil uso que permite grabar y Reproducir con ayuda del sistema los movimientos a ejecutar para realizar una automatización de pruebas bastante amplia con una curva

115 SIVAKUMAR, P; NANDHAKUMAR, M; JAYARAJ, R; KUMARAN, A. Sakthi. "Securing Data and Reducing the Time Traffic Using AES Encryption with Dual Cloud". [En línea]. [29 de marzo de 2019]. Disponible en: https://ieeexplore.ieee.org/abstract/document/8878749 116 HETHEY, Jonathan. GitLab Repository Management: Delve into managing your projects with GitLab, while tailoring it to fit your environment. 1. Birmingham: Packt Publishing Ltd., 2013. 17p.

69

de aprendizaje mínima. Tiene adicionalmente una biblioteca de complementos compartidos para ampliar las capacidades predeterminadas de este sistema, además utiliza diferentes lenguajes de programación y genera un informe completo de toda la elaboración de las pruebas de automatización117. Está herramienta fue escogida para realizar las pruebas de automatización del aplicativo ya que además de ser una herramienta de fácil uso también Es una herramienta en la cual se ha probado en proyectos anteriores y en la cual se ha visto buenos resultados por parte de este programa.

Wave es una herramienta para realizar pruebas de accesibilidad a una página por medio de su URL. Este aplicativo se conoce por ser un conjunto de diferentes herramientas de evaluación de accesibilidad manejadas por las directrices de WCAG 2.0.118 Este aplicativo fue el seleccionado para realizar las pruebas de accesibilidad del servicio web ya que no genera un informe sobre los errores como otras herramientas de pruebas de accesibilidad, sino que arroja por medio de iconos en la misma página web evaluada, los errores, las advertencias y las funcionalidades correctas que tiene el aplicativo que se está evaluando.

117 GIT BOOK. "Welcome to TestProject!". [En línea]. [s.f.]. Disponible en: https://docs.testproject.io/ 118 PIVETTA, Elisa Maria; FLOR, Carla; SATOMI SAITO, Daniela, RIVAS ULBRICHT, Vania. "Analysis of an Automatic Accessibility Evaluator to Validate a Virtual and Authenticated Environment". [En línea]. [2013]. Disponible en: https://dx.doi.org/10.14569/IJACSA.2013.040403.

70

8. CARÁCTER NOVEDOSO DEL PROYECTO

Dado lo relatado en el estado del arte se encuentra por una parte que las soluciones existentes se basan en lectores de pantalla integrados en el sistema operativo, sin embargo, esto no contribuye a que en realidad las páginas web se centren en construir un entorno accesible siguiendo las pautas WGAC emitidas por la W3C, ya que esto tendría un mayor impacto en el alcance de personas con discapacidad visual beneficiadas, ya que al estar estos componentes de accesibilidad integrados en la web, el número de dispositivos que podrían hacer uso de ella es mayor al incluirse dispositivos móviles, tabletas u otros que tengan conexión a internet.

La propuesta novedosa del proyecto se centra en mostrar cómo es posible construir y seguir una metodología que permita construir servicios web que por una parte cumplan con las pautas más importantes de WGAC respecto a accesibilidad y a la vez tenga los beneficios de lectura en voz alta como lo tienen la mayoría de herramientas que ya están en el mercado.

El prototipo emula parte de la página web del INCI añadiendo los elementos de accesibilidad y narración correspondientes con la finalidad de mostrar la importancia de que en páginas que son de utilidad y de acceso recurrente por esta población se agreguen esta clase de elementos, que como bien se resaltaba en los antecedentes de investigación pueden tener un impacto positivo sobre la calidad de vida de las personas con discapacidad visual en Bogotá al facilitarles el acceso y uso de información presente en los entornos web.

Figura 21. Propuesta novedosa


71

9. CRONOGRAMA DE ACTIVIDADES

Para el desarrollo del proyecto se decide construir un cronograma de actividades

para ejecutar el proyecto dentro del tiempo establecido.

Tabla 7. Cronograma de actividades

Actividades Meses

1 2 3 4

Iteraciones OE 1

A1

Iteraciones OE 2

A2

A3

A4

A5

A6

A7

Iteraciones OE 3

A8

Iteraciones OE 4

A9

A10

A11

A12


72

10. PRODUCTOS A ENTREGAR

En la siguiente tabla se definen los productos a entregar como resultado del

desarrollo de este proyecto:

Tabla 8. Productos a entregar Actividad Producto Tiempo de actividad

A1 Revisión documental. Estado del arte de servicios web

accesibles enfocados en

personas con limitación visual.

Una semana.

A2 Establecimiento de los

requerimientos funcionales y no

funcionales del prototipo.

Requerimientos funcionales y no

funcionales IEE 830.

Dos semanas.

A3 Definición de la arquitectura

de software del prototipo.

Diagramas de la arquitectura de

software.

Una semana.

A4 Reunión semanal de revisión

de Sprint

Backlog SCRUM. Seis semanas.

A5 Diseño del prototipo de

servicio web.

Casos de uso y diagramas de

secuencia en UML.

Tres semanas.

A6 Diseño de la estructura

estática del prototipo.

Diagramas de clases en UML. Dos semanas.

A7 Diseño de la estructura de

datos del prototipo.

Diagrama entidad-relación. Dos semanas.

A8 Construcción del prototipo. Código fuente del prototipo. Ocho semanas.

A9 Diseño de escenario de

pruebas para el prototipo.

Plan de pruebas tipo PMO. Dos semanas.

A10 Implementación del plan de

pruebas establecido.

Scripts para cada caso de

prueba.

Una semana.

A11 Ejecución del plan de

pruebas.

Informe de resultados de

pruebas.

Dos semanas.

A12 Documentación detallada. Tesis, manual de usuario y

manual técnico.

Dieciséis semanas.


73

11. INSTALACIONES Y EQUIPO REQUERIDO

El equipo requerido para el proyecto se encuentra descrito a continuación, no se

proyecta utilización de instalaciones físicas:

Tabla 9. Instalaciones y equipo requerido

Equipos requeridos

Tipo Característica Mínimo requerido

Computador

RAM 4 GB

Procesador Intel Core I5

Disco duro 128 GB


74

12. PRESUPUESTO DEL TRABAJO

El presupuesto que se plantea para el desarrollo del proyecto está fundamentado en base a recomendaciones de la German Academy Exchange Service 119 y es el que se describe a continuación:

12.1 COSTOS DE PERSONAL

Tabla 10. Costos de personal

Recurso Humano Valor por 1 mes Valor por 4 meses Tiempo

Estudiantes Pregrado $ 2.210.000 $ 8.840.000 Tiempo Completo Asesor de tesis $ 5.600.000 $ 22.400.000 Horas TOTAL $ 7.810.000 $ 31.240.000


12.2 COSTOS DE MATERIALES Y HERRAMIENTAS

Tabla 11. Costos de materiales

DETALLE DE MATERIALES

Descripción Cantidad Valor unitario TOTAL Estudiante Universidad

Valor Valor Computador 2 $ 2.900.000 $ 5.800.000 $ 5.800.000 Conexión a internet 2 $ 80.000 $ 160.000 $ 160.000 Cables y accesorios $ 350.000 $ 350.000 Papel 2 $ 15.000 $ 30.000 $ 30.000 Software $ 1.101.000 $ 1.101.000 $ 1.101.000 TOTAL $ 7.441.000 $ 0 $ 7.441.000


12.3 COSTOS DE VIAJES

Tabla 12. Costos de Viajes

Costos viajes

Viajes Nacionales $ 0 Otros viajes

Internacionales

$ 0 TOTAL $ 0


119 BECKER, Mathias; SCHÜTT, Brigitta; AMINI, Siawuch. Proposal Writing for International Research Projects: Project considerations. Berlin: Deutscher Akademischer Austauschdienst, 2014. 52p.

75

12.4 COSTOS TOTALES

Tabla 13. Costos totales

Costos totales

Recursos Humanos $ 31.240.000

Matriculas Pregrado $ 9.920.000 Materiales $ 7.441.000

Viajes $ 0

Conferencias y capacitaciones $ 0

TOTAL $ 48.601.000


76

13. ESTRATEGIAS DE COMUNICACIÓN Y DIVULGACIÓN

Para realizar la divulgación y comunicación del proyecto, se plantea que, mediante la utilización de redes sociales, se promueva la creación de imágenes y videos cortos de divulgación de la herramienta, para de esta forma lograr contribuir a impactar nuestro público objetivo, como estrategia adicional se propone que a partir del programa institucional de responsabilidad social de la Universidad Católica de Colombia, se gestione la publicación de enlaces a las redes sociales del prototipo de servicio web en la cual se visualice información general y relevante del prototipo.

Figura 22. Estrategia de divulgación


77

14. DESARROLLO DEL PROTOTIPO

Teniendo en cuenta la metodología planteada se desarrolló el prototipo de servicio web mediante las siguientes fases que se detallan a continuación:

14.1 FASE DE DISEÑO

En la fase de diseño se realiza la planeación sobre cómo se debe construir el prototipo, aportando además la documentación necesaria para que el equipo de desarrollo construya el prototipo según los parámetros establecidos.

14.1.1 Requerimientos

Una vez realizada la investigación que dio como resultado el estado del arte, teniendo además en cuenta las carencias y fortalezas de los desarrollos previos se considera la construcción de los principales requerimientos funcionales y no funcionales del prototipo siguiendo lo establecido según la norma IEEE 830:

14.1.1.1 Requerimientos no funcionales

Este tipo de requerimientos están relacionados directamente como la calidad del software al describir criterios a cumplir más no funcionalidades específicas.

Tabla 14. Listado de requerimientos no funcionales

Identificador Descripción

RNF001 El prototipo presenta una interfaz de usuario sencilla para que sea de fácil manejo a los usuarios del mismo.

RNF002 El prototipo garantiza elementos de accesibilidad en el módulo “Accesible” según principales recomendaciones WGAC.

RNF003 El prototipo ofrece consistencia de datos normalizando la base de datos.

RNF004 El prototipo no puede ocupar más de 2GB de almacenamiento.

RNF005 El prototipo debe estar disponible totalmente en el idioma español.

RNF006 El prototipo y todas sus funcionalidades deben responder en un tiempo no superior a 5 segundos.

RNF007 El prototipo debe contar con un diseño responsive en su visualización de interfaces

RNF008 El prototipo debe ser compatible con navegadores que soporten HTML5, CSS3 y JavaScript


78

Una descripción más detallada de estos requerimientos puede ser encontrada en los anexos.

14.1.1.2 Requerimientos funcionales

Este tipo de requerimientos especifican de forma detallada la funcionalidad del software, enfocándose en establecer precondiciones, secuencia normal de funcionamiento, excepciones y postcondición de dicha funcionalidad.

Tabla 15. Listado de requerimientos funcionales

Identificador Descripción

RF001 El prototipo debe contar con cuatro contenedores de servicios diferenciados: django_app_container, web_container, postgres_container, pgadmin_container

El prototipo debe asignar a cada contenedor un servicio según se describa en

RF001 El prototipo debe mostrar en su contenedor web una interfaz similar a la de la página web del INCI en el módulo “noAccesible” con indicaciones de advertencia para no confundir con la página real.

RF002 El prototipo debe permitir la navegación únicamente entre las páginas dispuestas en la barra de navegación de la página web del INCI.

RF003 El prototipo debe poder ser accedido mediante protocolo HTTP.

RF004 El prototipo debe permitir navegar entre los módulos “noAccesible” y “Accesible” mediante un “botón accesible” presente en todas las páginas.

RF005 El prototipo debe mantener las imágenes y el texto del módulo “noAccesible” en el módulo “Accesible” aplicando las principales recomendaciones WGAC.

RF006 El prototipo debe narrar textos y describir campos de formulario en el módulo “Accesible”

RF007 El prototipo debe implementar un formulario estilo hoja de vida en ambos módulos.

RF008 El prototipo debe almacenar y persistir los datos almacenados en la base de datos.

RF009 El prototipo debe proveer acceso a un usuario administrador al gestor pgadmin conectado a la base de datos.


14.1.2 SCRUM Backlog – Historias de usuario

79

Para dar cumplimiento al desarrollo de los requerimientos planteados se plantea en la metodología propuesta la utilización parcial de SCRUM, dándole relevancia a una de sus herramientas más importantes el cual es el SCRUM Backlog en donde se plasma claramente el objetivo principal del desarrollo, el cual en este contexto recibe el nombre de product goal y adicionalmente se detalla el desarrollo de requerimientos específicos según historias de usuario por sprints, el product goal diseñado para este prototipo es el siguiente:

Tabla 16. Product Goal Especificación de Product Goal Total de

sprints

Construir un prototipo de servicio web funcional inclusivo mediante la utilización de estándares y técnicas de desarrollo de software para el acceso de usuarios con discapacidad visual (ciudad de Bogotá) sin depender de la tecnología JAWS.

8


Del product goal es importante resaltar que la duración de cada sprint es de dos semanas tal y como se planteó en la metodología, complementando el product goal también se diseñó el product backlog el cual es el que se describe a continuación:

Tabla 17. Product Backlog – Historias de usuario Identificador Descripción Esfuerzo Prioridad

HU-001 Como usuario sin discapacidad visual, necesito navegar por los servicios web del INCI mediante interfaz gráfica, con la finalidad de acceder a la información provista en esta.

Bajo 1

HU-002 Como usuario sin discapacidad visual, necesito almacenar información en base de datos. Para utilizar los servicios de persistencia de datos.

Medio 2

HU-003 Como usuario con discapacidad visual, necesito navegar por los servicios web del INCI mediante interfaz gráfica con contrastes WGAC y fuente grande legible, con la finalidad de acceder a la información provista en esta.

Alto 3

HU-004 Como usuario con ceguera, necesito utilizar servicios web mediante interfaz con elementos auditivos de narración, elementos ARIA y parámetros WGAC, con la finalidad de acceder a la información provista en esta.

Alto 4

HU-005 Como usuario con discapacidad visual necesito almacenar información en base de datos. Para utilizar los servicios de persistencia de datos.

Alto 3

HU-006 Como usuario administrador de base de datos necesito acceder a un gestor de base de datos de

Medio 2

80

postgres con la finalidad de realizar labores de mantenibilidad.

Fuente: Elaboración propia, 2021

En este product backlog se tiene en cuenta escalas de medición específicas para la prioridad, estas deben ser entendidas de la siguiente manera:

• Prioridad máxima: Se asigna con el número 4, el desarrollo del requerimientoes crítico y los esfuerzos de desarrollo deben darle prioridad para completarlocon celeridad.

• Prioridad alta: Se asigna con el número 3, el desarrollo de este requerimientoes fundamental para continuar con otros requerimientos básicos por lo quetiene una prioridad de desarrollo elevada.

• Prioridad estándar: Se asigna con el número 2, el desarrollo de esterequerimiento es medio, es importante completarlo para desarrollar con éxitolas diversas funcionalidades, sin embargo, puede ser aplazado porrequerimientos de mayor importancia.

• Prioridad baja: Se asigna con el número 1, el desarrollo de este requerimientono es crítico para el funcionamiento o desarrollo general del prototipo, por loque pueden ser desarrollados de forma no prioritaria.

14.1.3 Casos de uso

Un buen diseño de software también parte de entender como nuestros usuarios finales interactuaran con el software, es por ello que se construyen los siguientes diagramas de casos de uso para detallar dicha interacción:

81

Figura 23. Caso de uso: Página principal


El funcionamiento que posee la página principal consta de tres actores, los cuales son personas sin ningún tipo de discapacidad visual, personas con alguna limitación visual diferente a la ceguera y a las personas ciegas. En el siguiente caso de uso, el actor sin discapacidad puede visualizar el contenido de la página principal con las opciones de acceder a la página accesible o navegar por los módulos del INCI, el segundo actor con limitaciones visuales el cual no llega al grado de ceguera sin percepción de luz, tendrá más facilidad a la hora de acceder a la página accesible por medio del teclado o por visualización y el tercer actor con ceguera total también tendrá únicamente la opción de acceder a la página accesible por medio de un botón con reproducción de voz que será alertado cuando la persona ingrese por el teclado.

82

Figura 24. Caso de uso: Página accesible


El diagrama de casos de uso para la página accesible es similar al anterior con la diferencia de que, para los actores, escucharán el contenido de la página por medio de un asistente de voz, este les permite tanto a las personas sin discapacidad visual como a las personas con discapacidad visual diferente a la ceguera, acceder a los contenidos de la página web accesible con voz al mover el mouse sobre cualquier elemento contenido en la página web y para las personas con ceguera, por medio de la interacción por teclado se irá reproduciendo el contenido de cada elemento seleccionado de la página.

Estos dos diagramas de casos de uso son los más importantes a tener en cuenta ya que especifican la interacción de los diferentes actores con los principales elementos del prototipo.

14.1.4 Arquitectura

Una vez se detallaron los requerimientos a ser tenidos en cuenta en el prototipo se continua el diseño planteando la arquitectura general del prototipo, en donde teniendo en cuenta lo descrito en la metodología se opta por establecer una arquitectura de microservicios soportada mediante contenedores para separar los diferentes servicios, utilizando la herramienta Docker que actúa como SaaS como se muestra en el siguiente diagrama:

83

Figura 25. Arquitectura del prototipo


El diagrama se encuentra dividido en tres partes, la primera sección “Cliente” indica que el cliente que en este caso también tiene el rol de usuario debe tener en su ordenador instalado el software de Docker y Docker Compose, que se encuentran disponibles para los sistemas operativos más usados para ejecutar este prototipo.

Mediante la orden por consola “docker-compose up” se invoca al Docker Daemon el cual lee los archivos Dockerfile y docker-compose.yaml que son construidos durante la fase de desarrollo y que contienen instrucciones para solicitar cuatro imágenes al “Registry” el cual es docker-hub, un repositorio en la nube de Docker en donde se almacenan todas las imágenes disponibles de Docker siendo algunas oficiales y otras creadas por la comunidad, en este caso todas las imágenes solicitadas son oficiales.

Las cuatro imágenes que se solicitan cumplen con diversas funciones:

• python3.9.6: Sobre esta imagen se crea el contenedor“django_app_container” el cual contendrá el framework Django junto a todoel código sobre templates, vistas, url y módulos de la página web con la queel usuario final interactuará.

• nginx:1.13: Esta imagen se solicita con la finalidad de crear el contenedor“web_container” el cual se encargará de actuar como servidor web HTTP

84

dando tramite a las solicitudes de este tipo que se den para el correcto funcionamiento de los servicios web.

• postgres:11.5: Esta imagen se solicita con la finalidad de crear el contenedor“postgres_container” el cual se encargará de actuar como una base de datosde tipo relacional SQL, realizando las labores de persistencia de datos dehoja de vida propuesto en los requerimientos.

• pgadmin4:4.18: Esta imagen se solicita con la finalidad de crear elcontenedor “pgadmin_container” el cual se le incorpora un usuario deadministración y clave con el propósito de que un eventual administrador desistema tenga acceso desde una interfaz a la administración de la base dedatos y realice allí las acciones que sean requeridas.

Una vez se complete la ejecución del comando “docker-compose up” el usuario ya podrá realizar el acceso a todas las funcionalidades del prototipo mediante los siguientes puertos:

(Verificar mediante Docker los puertos de cada contenedor y agregarlos aquí)

14.1.5 Lógica de procedimientos

Una vez planteada la arquitectura se empieza a detallar el comportamiento de los componentes más importantes del prototipo en tiempo de ejecución, a continuación, se relacionará el funcionamiento mediante diagrama de secuencia entre los módulos “No Accesible” y “Accesible”, los cuales son componentes céntricos del diseño, y es allí en donde se establece la funcionalidad de narración:

85

Figura 26. Diagrama de secuencia: Interacción entre módulos


86

Este diagrama muestra como de forma inicial el usuario al acceder al prototipo se encuentra en el módulo No Accesible el cual es una réplica de la página web del INCI con un agregado el cual es un botón el cual lo redirige al módulo Accesible mediante el método InvocarAccesible, una funcionalidad similar se provee en el módulo "Accesible" mediante el método InvocarNoAccesible el cual lo redirecciona al módulo por defecto.

Una vez dentro del módulo Accesible se realiza en tiempo de ejecución la creación de Synth una API que facilitará la narración de los diversos elementos del prototipo, adicionalmente mediante Listener se vigilan los eventos mauseover (mover el cursor sobre un elemento), focus (selección de elemento mediante teclado) y mouseout (desplazar el mause fuera de un elemento), de forma tal que al mover el cursor sobre un elemento susceptible de narración o en su defecto señalarlo por teclado se realicen las siguientes acciones: establecer el lenguaje de narración en español, obtener la voz disponible para narrar, pasarle por parámetro el texto a leer y finalmente leer en voz alta. La narración del elemento se repetirá indefinidamente para facilitarle al usuario saber en qué elemento se encuentra en cada momento, por último, cuando ocurra el evento mouseout se detendrá la narración actual con la finalidad de narrar siempre solo el elemento señalado.

14.1.6 Clases

Una vez detallada la lógica de los procedimientos más importantes, se procede al diseño de las entidades u objetos relevantes que conformaran el prototipo web, así como sus interacciones, estos están directamente relacionados también con el framework de trabajo Django junto a elementos propios, este diseño se detalla mediante el siguiente diagrama de clases:

87

Figura 27. Diagrama de clases


Estos objetos se refieren en mayor medida a la forma en cómo se construyen los usuarios en el prototipo, refiriéndose mayormente al tiempo de existencia de las sesiones, en este sentido Session es una clase padre, y AstractBaseSession hereda de esta, estas proveen la funcionalidad de que en caso de ser necesario una sesión expire. Por otra parte LogEntry da la posibilidad de almacenar los errores que pueda generar el objeto User por medio de un logentry, diversos permisos pueden ser asignados a un Usuario mediante AbstactUser en cual por medio de herencia

88

genera los objetos AbstractBaseUser y PermissionsMixin, el primero cuenta con los permisos básicos de operación mientras que el segundo cuenta con permisos reducidos, adicionalmente las relaciones de User con Group, este a su vez con Permission y posteriormente ContentType están pensados para permitir el uso de contenido especifico por parte de un usuario.

14.1.7 Entidades y relaciones

Dentro de los requerimientos y la arquitectura se prevé la utilización de una base de datos en Postgres de tipo SQL relacional, por lo cual se describe a continuación el diseño entidad-relación de dicha base de datos, la cual almacenara para el caso de este prototipo hojas de vida, esta se encuentra normalizada a tercera forma normal para evitar inconsistencias y redundancia:

89

Figura 28. Diagrama entidad-relación


Al aplicarse la tercera forma normal, se puede observar cómo cada entidad tiene su llave primaria PK, así como los demás campos únicamente dependen de esta llave primaria, conformándose en total diez entidades relacionadas para mantener la consistencia de este modelo de datos.

90

De este diagrama también es importante resaltar las tablas adicionales Persona_Empresa_Cargo y Persona_Cualidades, las cuales son necesarias al existir relaciones de muchos a muchos entre las diferentes entidades las cuales contienen campos de tipo llave foránea FK.

14.2 FASE DE DESARROLLO

En la fase de desarrollo se realizan y construyen las funcionalidades del prototipo siguiendo lo establecido en la fase de diseño, siendo la codificación su principal resultado, aspectos importantes de esta se explican a continuación:

14.2.1 Instalación y configuración de herramientas

Para el desarrollo del prototipo se instalan y configuran las herramientas planteadas en la metodología, cabe resaltar la instalación de las siguientes herramientas fundamentales para el proyecto, la primera es Python 3.9.6, una de las versiones más recientes y estables liberada en junio 28 de 2021120.

Figura 29. Página oficial de Python 3.9.6


120 PYTHON. "Python 3.9.6". [En línea]. [13 de octubre 2021]. Disponible en: https://www.python.org/downloads/release/python-396/

91

La correcta instalación del mismo se verifica corriendo el comando “Python --version” en una ventana de línea de comandos, arrojando el resultado que se muestra a continuación:

Figura 30. Verificación de versión de Python


La siguiente herramienta a resaltar es el framework de trabajo Django en su versión 3.2.6 detallado en la metodología, descargado e instalado siguiendo la documentación oficial que proveen sus desarrolladores121:

Figura 31. Página oficial Django 3.2.6


121 DJANGO. "How to get Django". [En línea]. [13 de octubre 2021]. Disponible en: https://www.djangoproject.com/download/

92

La correcta instalación del mismo se verifica corriendo el comando “python -m django --version” en una ventana de línea de comandos, arrojando el resultado que se muestra a continuación:

Figura 32. Verificación de versión de Django


La última herramienta configurada e instalada que merece ser mencionada por su importancia es Docker, la cual se instaló siguiendo la documentación oficial provista en su sitio web122.

Figura 33. Página oficial de Docker


La correcta instalación del mismo se verifica corriendo el comando “docker --version” en una ventana de línea de comandos, arrojando el resultado que se muestra a continuación:

122 DOCKER DOCS. "Get Docker". [En línea]. [13 de octubre 2021]. Disponible en: https://docs.docker.com/get-docker/

93

Figura 34. Verificación de versión de Docker


Para llevar a cabo el control de versiones se instala Git en los ordenadores de los desarrolladores y se crea un repositorio en GitLab: el cual se actualizará a medida que se avanza con los sprint de desarrollo como se muestra a continuación:

Figura 35. Repositorio en GitLab


14.2.2 Construcción de Dockerfile y docker-compose

Una vez todos los desarrolladores cuentan con las herramientas mencionadas anteriormente, se procede con la codificación, en primer lugar, se construyen los archivos Dockerfile y docker-compose.yaml lo cuales tendrán el rol fundamental de construir los contenedores que se convertirán en los servicios propuestos del prototipo, adicionalmente es necesario escribir el archivo requirements.txt el cual contiene el listado de requerimientos a solicitar al registry.

Figura 36. Estructura de Dockerfile


La instrucción FROM solicita la imagen de Python correspondiente al registry para sobre esta comenzar la construcción de los componentes, con la instrucción LABEL se identifica a los desarrolladores o mantenedores del prototipo junto a un correo de contacto, con la instrucción ENV se establece la variable de Python que permite el acceso al buffer, mediante RUN se ejecuta el comando para crear la carpeta “code”

94

que contendrá el código necesario, el siguiente comando COPY copia el código dentro de la carpeta “code”, a continuación el comando RUN instala todos los requerimientos que encuentre en el archivo requeriments.txt, por último CMD envía comandos necesarios para que el contenedor que proveerá el servicio web busque el archivo conf.py e inicialice la aplicación de django por el puerto 8000.

95

Figura 37. Estructura de docker-compose


96

Gracias este archivo se permite la configuración de los cuatro contenedores siendo uno la de base de datos, con nombre postgres_container, el siguiente representa los archivos django y obtiene el nombre django_app_container, el siguiente pone en marcha el contenedor que actuara como servicio web bajo el nombre web_container y por último se crea el contenedor que contendrá el gestor de base de datos pgadmin, mediante la instrucción image se solicita la imagen correspondiente al registry, mediante la instrucción environment se establecen las variables de entorno de cada uno de los contenedores, mediante la instrucción depends_on se establecen las dependencias en los diferentes contenedores de la siguiente manera el contenedor Django espera a que se levante la base de datos primero, de la misma forma el gestor de base de datos espera, al mismo tiempo el contenedor web esperará hasta que el contenedor django este operativo para iniciar su operación

Figura 38. Estructura de red Docker y entry-point


97

En la anterior imagen se muestra la parte final del archivo docker-compose.yaml en donde se configura la red docker para intercomunicar a los contenedores mediante esta red interna configurada con parámetros ipv4 e ipv6, así como también se encuentra la configuración de volúmenes persistentes para evitar la pérdida de datos que se almacenen dentro los archivos estáticos de Django o la base de datos.

A continuación, se procede con la construcción del archivo de requerimientos denominado requeriments.txt por recomendaciones generales en la documentación de Docker de la siguiente manera:

Figura 39. Estructura de requirements


• Mediante este archivo se solicitan cuatro imágenes en versiones específicas:Django en su versión 3.2.6 para coincidir con la versión que manejan losdesarrolladores y el comportamiento sea el mismo al construir el contenedor.

• psycopg2 en su versión 2.8.3 aporta los elementos necesarios para laconstrucción de la base de datos postgre y soporte de sentencias SQL.

• gunicorn en su versión 19.9.0 aporta los elementos necesarios a nginx paraactuar como servidor HTTP con plena integración con Python.

• pgadmin4 en su versión 4.22 aporta los elementos de interfaz gráfica paraconectar y administrar bases de datos postgres.

14.2.3 Estructura general del código

Una vez preparados los archivos que construirán los contenedores en forma de arquitectura de microservicios el énfasis se coloca en la construcción de las configuraciones del servidor web y la aplicación web con los diferentes módulos propuestos en el diseño, la estructura general del código se ve de la siguiente manera:

98

Figura 40. Estructura general del código


La carpeta “.idea” es autogenerada por Intellij IDEA conteniendo archivos xml sobre variables de entorno, el espacio de trabajo y módulos, por su parte la carpeta “config” contiene las configuraciones que debe aplicar nginx a la hora de levantar el contendor web, “docker_django” contiene toda las configuraciones y codificación del sitio web y es llamada así al ser una combinación entre elementos de Django que son puestos en marcha gracias a Docker, por último la carpeta static permite separar eventuales archivos estáticos que requieran persistencia, adicionalmente se encuentran los archivos necesarios de Docker “docker-compose.yaml”, “Dockerfile” y “requirements.txt” los cuales deben ubicarse en la raíz del código.

Figura 41. Estructura de config


La carpeta “config” esta subdividida en dos secciones, una es “gunicorn” la cual contiene un archivo “conf.py” el cual establece workers con la finalidad de proveer en una futura implementación más amplia la posibilidad del balanceo de carga del sistema, la segunda parte es “local.conf” la cual contiene las configuraciones locales

99

con las que se iniciara nginx cuando Docker este construyendo el contenedor ya que se invoca este archivo de configuración desde la línea CMD del Dockerfile.

Figura 42. Estructura general de docker_django


Esta sección del código es muy importante y se divide en dos partes “docker_django” la cual contiene los archivos de configuración mínimos para Django (resaltados en amarillo), en donde es importante resaltar “settings.py” en donde se establecen configuraciones para conexión a base de datos, variables de entorno como rutas relativas, el idioma de la aplicación web la cual se configura en español y las aplicaciones que conforman el proyecto, por su parte “urls.py” define las rutas hacía los diferentes aplicaciones, “wsgi.py” realiza las funciones de Web Server Gateway Interface describiendo la forma en que se debe comunicar la aplicación web con el servidor nginx.

Por último, pero no menos importante en esta sección se encuentra el archivo “manage.py” el cual es el iniciador de toda la aplicación de Django conteniendo la función “main” como se muestra a continuación:

100

Figura 43. Estructura general de manage.py


Se importa las librerías para comunicarse con el sistema operativo “os” y “sys” que en este caso será el sistema operativo presente en el contenedor el cual es Linux Debian, se establece desde el “settings.py” las variables de entorno definidas, mediante el try catch se intenta inicializar la aplicación en caso de fallo se reporta el error en la consola del contenedor.

101

Figura 44. Estructura general de ProyectoVision


En esta sección se encuentran los principales elementos con los que los usuarios pueden interactuar en la página web, “migrations” provee elementos que permiten agilizar los procesos de migración de bases de datos en caso de ser necesarios, mientras que “static” (en amarillo) contiene los archivos persistentes necesarios, allí se colocan los elementos css que contiene las hojas de estilos que utilizan los html soportadas en bootstrap y materialize así como en “js” se colocan los scripts necesarios desarrollados en JavaScript.

Por su parte “templates” se separa en dos módulos creados, por una parte “noAccesible” (en rojo) son los archivos html que emulan la apariencia de la página web del INCI en sus partes más visibles tal cual se encontraba a la hora de realizar esta investigación con elementos diferenciadores clave como mostrar claramente mediante elementos visuales que es una réplica de este sitio construido con fines académicos y la adición de un botón que cumple con las recomendaciones WGAC en cuanto a contraste y que permite trasladarse a la página web correspondiente pero en su versión accesible.

102

El siguiente módulo construido es “Accesible” (en verde), en el cual se construyen archivos html que mantienen el texto, las imágenes y enlaces del módulo “noAccesible”, adicionalmente se añaden los elementos que permiten la narración de texto, elementos e imágenes que se muestran en este módulo.

Es importante resaltar la construcción de “Aformulario.html” y “formulario.html” los cuales son elementos originales en donde se incluyen diversidad de elementos que puede encontrar un usuario en un formulario web como campos para llenar texto, datos numéricos, elementos calendario, de selección múltiple y exclusivos. Este se construye con el fin de diseñar un módulo accesible que permita la interacción efectiva con dichos elementos y a su vez permitir la inserción de datos en un almacenamiento persistente.

Para lograr la finalidad de narración, separando la lógica de procedimientos de las vistas, se realiza en “Alayout.html” la estructura principal del script que permite la narración de elementos de la siguiente manera:

Figura 45. Estructura general del script de narración


La variable global “synth” es declarada representando un objeto de tipo speechSynthesis, adicionalmente se construyen cuatro funciones adicionales para permitir la narración de diferentes tipos de elementos.

La primera función “Hablar” recibe un elemento el cual no muestra en la interfaz un texto o es necesario realizar una descripción de este, estos elementos pueden ser barras de navegación, footers, índices de tablas, elementos de formularios entre

103

otros, la variable “toSpeak” se encarga de obtener el texto dentro del aria-label, es decir una práctica en donde a los elementos se les adjunta una descripción de cómo utilizarlo precisamente para mejorar la accesibilidad del sitio, a continuación “toSpeak.voice” se encarga de seleccionar la voz en español, finalmente “synth.speak” da la orden de lectura en voz alta.

El funcionamiento de las siguientes dos funciones “HablarTexto” y “HablarImagen” es similar, con la diferencia que en la primera función el elemento que se recibe sí cuenta con texto que se muestra en la interfaz y por tanto se lee directamente lo que se visualiza en la pantalla. Por su parte “HablarImagen” recibe los elementos visuales de tipo imagen, busca el atributo “alt” dentro de esta, en donde se encuentra una breve descripción de la imagen y esto es a lo que se le da lectura.

Por último, la función mouseOut hace override de la función con el mismo nombre para indicar que cuando el cursor abandone el elemento se detenga la narración que se estaba llevando a cabo con la finalidad de que el usuario tenga en todo momento la narración acertada del elemento en el que actualmente está enfocado.

Figura 46. Estructura general de los html


Para comprender la estructura general desarrollada dentro de los html, tomemos por ejemplo el código dentro de “Aformulario.html”, por una parte existe la presencia de elementos Django, el cual tiene un lenguaje propio el cual se inserta dentro del html, estos elementos se visualizan en verde lima, se establece una herencia en primer lugar mediante el “extends” con la finalidad de reutilizar código parqa elementos repetitivos como cabeceras o footers, “block content” indica el comienzo del código en html que es diferente, “csrf token” añade una capa de seguridad

104

mínima al comprobar el envío de datos desde un formulario, es posible también utilizar condicionales como se observa en la línea siguiente.

Algunos llamados a las funciones de narración lo encontramos en las líneas resaltadas en morado, en este caso haciendo uso de listeners se tienen en cuenta los movimientos del cursor y sobre que elemento se posiciona este, en base a esta evaluación se hace el llamado a las funciones correspondientes ya sea para ejecutar la narración o para cancelarla, un elemento de accesibilidad queda evidente en la línea resaltada en fucsia el cual es en este caso un elemento aria-label donde se escriben una descripción que ayuda al usuario con discapacidad visual a llenar de una mejor forma el formulario, esta clase de elementos están presentes en todos los html dentro del módulo “Accesible” no solo con los aria-label sino utilizando fuentes grandes y con el contraste mínimo recomendado en WGAC basado en los niveles AA y AAA.

14.2.4 Construcción de base de datos

A partir de lo propuesto en el diagrama de entidad relación, desde models.py en Django se construye el código el cual a la hora de realizar las migraciones dentro del contenedor “django_app_container” construirá la base de datos, el archivo models.py se construyó de la siguiente manera para coincidir con el modelo de datos planteado:

105

Figura 47. Estructura de datos generada desde models.py


106

Si este archivo es llamado por la ejecución de migraciones dentro del contenedor Django esto resultara en la construcción automática de la estructura general de la base de datos tal y como se puede ver en la siguiente imagen dentro de pgadmin:

Figura 48. Estructura de datos, vista desde pgadmin


Por su parte dentro del contenedor de Django, en el archivo “views.py” y teniendo en cuenta el formulario desarrollado para guardar datos de forma persistente en la

107

base de datos se recogen los datos validados en los campos mediante método POST.

Figura 49. Estructura general de recolección de datos en Views.py


Se comprueba la consistencia de los datos mediante comprobaciones lógicas a los datos enviados por POST desde el formulario, si se superan las comprobaciones se realiza la inserción a la base de datos tal y como se muestra a continuación:

108

Figura 50. Operación: Inserción de datos

Fuente: Elaboración propia, 2021. La inserción de datos es específicamente ejecutada por la instrucción “save()” en cual ejecuta la consulta construida dentro de la base de datos, dicha inserción se puede comprobar desde la interfaz del usuario de administración usando el contenedor pgadmin y consultando la sección de databases y a continuación schemas y tablas en donde se pueden consultar los registros.

109

La inserción de datos es específicamente ejecutada por la instrucción “save()” en cual ejecuta la consulta construida dentro de la base de datos, dicha inserción se puede comprobar desde la interfaz del usuario de administración usando el contenedor pgadmin y consultando la sección de databases y a continuación schemas y tablas en donde se pueden consultar los registros.

14.3 FASE DE PRUEBAS

La fase de pruebas ayuda a garantizar que el prototipo construido funciona correctamente para que este cumpla con un alto nivel de calidad. Esta fase toma los elementos planteados en la etapa de diseño, para corroborar que todo funcionamiento planteado se realice en las condiciones descritas para de esta forma verificar que se esté cumpliendo con los requisitos planteados.

14.3.1 Creación del plan de pruebas

Para una correcta ejecución de las pruebas a elaborar, se toma como referencia las historias de usuario presentadas en la fase de diseño, con el objetivo de generar una trazabilidad en los requisitos de los casos de prueba.

14.3.1.1 Trazabilidad de casos de pruebas

Tabla 18. Plan de pruebas

REQUISITOS PROTOTIPO WEB ACCESIBLE VERSION 1

Nombre ID_HU Descripción

Acceder a Información No

accesible HU-001

Como usuario sin discapacidad visual, necesito navegar por los servicios web del INCI mediante interfaz gráfica, con la finalidad de acceder a la información provista en esta.

Almacenar Datos de forma

No accesible HU-002

Como usuario sin discapacidad visual, necesito almacenar información en base de datos. Para utilizar los servicios de persistencia de datos.

Navegar de forma accesible

HU-003

Como usuario con discapacidad visual, necesito navegar por los servicios web del INCI mediante interfaz gráfica con contrastes WGAC y fuente grande legible, con la finalidad de acceder a la información provista en esta.

Navegar con servicios por narrador y

teclado

HU-004

Como usuario con ceguera, necesito utilizar servicios web mediante interfaz con elementos auditivos de narración, elementos ARIA y parámetros WGAC, con la finalidad de acceder a la información provista en esta.

110

Almacenar datos de forma

accesible HU-005

Como usuario con discapacidad visual necesito almacenar información en base de datos. Para utilizar los servicios de persistencia de datos.

Acceder a PostgreSQL

HU-006

Como usuario administrador de base de datos necesito acceder a un gestor de base de datos de PostgreSQL con la finalidad de realizar labores de mantenibilidad.

Visualizar en diseño

responsive RNF007

El prototipo debe contar con un diseño responsive en su visualización de interfaces


14.3.1.2 Definición de casos de prueba

Para la verificación de funcionalidad del sistema, se describieron los siguientes casos de prueba con su respectivo flujo principal.

El primer caso se contempla el evento en el que un usuario sin ningún tipo de discapacidad ingresa al prototipo donde se espera que la navegación funcione de forma correcta por cada una de las secciones y que, a su vez, la sección de formulario inserte los valores en la base de datos al ser diligenciado.

Tabla 19. Caso de prueba 001

El usuario sin discapacidad ingresa al aplicativo para llenar el formulario “Hoja de vida” que proporciona el dispositivo con datos correctos.

CP-001

¿Prueba de despliegue? Si

Descripción:

El sistema debe permitir una correcta navegación a través del menú de navegación, además debe permitir que los usuarios diligencien con datos validos los campos del formulario solicitado e insertar datos en la base de datos.

Prerrequisitos

1. El usuario debe ya tener instalado Docker y todas sus funcionalidades, además de tener los requisitos mínimos de hardware que requiere Docker.

2. El usuario debe ya tener los contenedores en marcha3. Haber ingresado a la interfaz gráfica en el puerto 8000

Pasos:

111

1. Desde la barra de navegación, dirigirse a la sección el instituto2. Dirigirse a la sección blog3. Dirigirse a la sección Formulario4. Diligenciar el formulario5. Pulsar en el botón validar

Campos o Variables:

• Nombres

• Apellidos

• Numero celular

• Numero de cedula

• Fecha de nacimiento

• Correo

• Estado civil

• Sexo

• Cualidades

• Perfil

• Fecha de graduación

• Titulo

• Institución

• Nombre de la empresa

• Fecha en que inició el trabajo

• Fecha en que finalizó el trabajo

• Cargo

• Teléfono

• Nombre referencia

• Apellido referencia

• Cedula referencia

• Teléfono referencia

Valores:

• Valor valido nombres: Esteban Daniel

• Valor valido apellidos: García López

• Numero celular: 3216549875

• Numero de cedula: 4278965

• Fecha de nacimiento: 24/05/2000

• Correo: [email protected]

• Estado civil: Soltero

• Sexo: Masculino

• Cualidades: Atento, Tímido y Respetuoso

• Perfil: Persona con un gran sentido de compañerismo

112

• Fecha de graduación: 25/12/2015

• Título: Bachiller Académico

• Institución: Colegio Nueva Granada

• Nombre de la empresa: Bimbo

• Fecha en que inició el trabajo: 15/05/2020

• Fecha en que finalizó el trabajo: 18/12/2020

• Cargo: Empleado comercial

• Teléfono: 3216549875

• Nombre referencia: Cristian Camilo

• Apellido referencia: Lopez Martinez

• Cedula referencia: 1006549875

• Teléfono referencia: 3216549875

Resultado esperado:

• Alert informando que el registro fue correcto


El siguiente caso de prueba contiene el evento que una persona con discapacidad ingrese al aplicativo y desee ingresar el formulario en la sección correspondiente al modo accesible.


El usuario con discapacidad visual ingresa para llenar el formulario “Hoja de vida” en el módulo accesible del prototipo

CP-002


Descripción:

El sistema debe permitir una correcta navegación a través del menú de navegación, además debe permitir que los usuarios diligencien con datos validos los campos del formulario solicitado e insertar datos en la base de datos.

Prerrequisitos



Pasos:

113

1. Desde la barra de navegación, dirigirse al módulo accesible por medio del

botón con el icono 2. Dirigirse a la sección blog por medio de la interacción con el mouse3. Dirigirse a la sección el instituto por medio de tabulación4. Dirigiste a la sección Formulario5. Diligenciar el formulario por tabulación en el teclado o por interacción conel mouse 6. Pulsar en el botón validar

Campos o Variables:

• Nombres

• Apellidos

• Numero celular

• Numero de cedula

• Fecha de nacimiento

• Correo

• Estado civil

• Sexo

• Cualidades

• Perfil

• Fecha de graduación

• Titulo

• Institución

• Nombre de la empresa

• Fecha en que inició el trabajo

• Fecha en que finalizó el trabajo

• Cargo

• Teléfono

• Nombre referencia

• Apellido referencia

• Cedula referencia

• Teléfono referencia

Valores:

• Valor valido nombres: Esteban Daniel

• Valor valido apellidos: García López

• Numero celular: 3216549875

• Numero de cedula: 4278965

• Fecha de nacimiento: 24/05/2000


114

• Estado civil: Soltero

• Sexo: Masculino

• Cualidades: Atento, Tímido y Respetuoso

• Perfil: Persona con un gran sentido de compañerismo

• Fecha de graduación: 25/12/2015

• Título: Bachiller Académico

• Institución: Colegio Nueva Granada

• Nombre de la empresa: Bimbo

• Fecha en que inició el trabajo: 15/05/2020

• Fecha en que finalizó el trabajo: 18/12/2020

• Cargo: Empleado comercial

• Teléfono: 3216549875

• Nombre referencia: Cristian Camilo

• Apellido referencia: Lopez Martinez

• Cedula referencia: 1006549875

• Teléfono referencia: 3216549875

Resultado esperado:

• Mensaje en color Rojo informando que el formulario fue registrado correctamente


Docker tiene la facilidad de acceder directamente por el puerto 8080 al servidor de pgadmin para acceder a la base de datos del prototipo, por lo tanto, en el siguiente caso de prueba presenta el evento de un administrador accediendo a la base de datos en postreSQL donde puede observar las diferentes tablas que se contienen ahí dentro.


El administrador ingresa exitosamente a la base de datos en PostgreSQL por medio de PgAdmin

CP-003


Descripción:

Un usuario administrador quiere observar el funcionamiento de los datos en la base de datos, donde puede por medio de las credenciales acceder a los datos que se especifican dentro mediante el modelo entidad-relación

115

Prerrequisitos



Pasos:

1. Ingresar el usuario de pgAdmin2. Ingresar la contraseña de pgAdmin3. Acceder al servidor (Crearlo en caso de que no exista)4. Ingresar dirección IP, usuario y contraseña del servidor5. Pulsar en el botón aceptar

Campos o Variables:

• Usuario_pgAdmin

• Contraseña_pgAdmin

• Usuario_servidor

• Contraseña_servidor

• Ip_servidor

Valores:

• Usuario_pgAdmin = ‘[email protected]’

• Contraseña_pgAdmin = ‘secret’

• Usuario_servidor= ‘admin’

• Contraseña_servidor= ‘secret’

• Ip_servidor= ‘192.168.1.3’

Resultado esperado:

• Acceso a la base de datos en postgreSQL


Para este último evento, se tiene a un usuario con el interés de conocer en que entornos se adapta el prototipo, por lo tanto, se quiere realizar la prueba donde se compruebe que el diseño del prototipo es accesible.


El usuario desde el navegador redimensionando la página del

CP-004


116

prototipo para identificar el diseño responsive

Descripción:

El sistema debe permitir un diseño responsive capaz de ser accedido por diversos dispositivos.

Prerrequisitos



Pasos:

1. Minimizar el navegador2. Redimensionar el navegador en formato móvil3. Redimensionar el navegador en distintos formatos

Campos o Variables: No aplica

Valores: No aplica

Resultado esperado:

• Diseño ajustado en cada uno de los formatos


14.3.2 Construcción de scripts de prueba

Como se planteó en la metodología, la herramienta utilizada para la construcción y ejecución de los scripts de este plan de pruebas enfocadas en verificar el correcto funcionamiento del prototipo es TestProject. Esta herramienta nos proporciona todo lo necesario para realizar una adecuada construcción de los scripts para cada una de los casos de prueba propuestos.

117

14.3.3 Ejecución de scripts

Debido a la extensa longitud de parámetros, los scripts completos podrán ser encontrados en un anexo al final de este trabajo de investigación.

El primer script ejecutado tiene la intención de efectuar el caso de prueba 001, la duración de la ejecución de dicho script fue de un 1 minuto con 18 segundos como se muestra en la siguiente imagen:

Figura 51. Resultado de script 001


El resultado de la prueba resulta ser satisfactorio al completarse sin errores.

El segundo script ejecutado tiene la intención de efectuar el caso de prueba 002, la duración de la ejecución de dicho script fue de 2 minutos con 11 segundos como se muestra en la siguiente imagen:




118

El tercer script ejecutado tiene la intención de efectuar el caso de prueba 003, la duración de la ejecución de dicho script fue de 2 minutos con 52 segundos como se muestra en la siguiente imagen:




El tercer script ejecutado tiene la intención de efectuar el caso de prueba 004, la duración de la ejecución de dicho script fue de 3 minutos con 28 segundos como se muestra en la siguiente imagen:



El resultado de la prueba resulta ser satisfactorio al completarse en su mayor parte sin errores, dando un porcentaje de éxito del 75%.

14.3.4 Pruebas de accesibilidad

Teniendo en cuenta lo propuesto en la metodología de trabajo, especialmente en lo referente herramientas de prueba se determinó la importancia de utilizar un software que permitiera evaluar la accesibilidad web del prototipo haciendo énfasis en verificar si se cumple o no lo dispuesto por las pautas WGAC, en ese sentido se

119

planteó la utilización del software de pruebas WAVE especializado en estos parámetros.

En primer lugar, se somete a prueba la interfaz inicio del módulo noAccesible, las cuales no están pensadas para contener elementos accesibles sino más bien para acercarse tanto como sea posible a la página web real del INCI y comprobar desde allí si las condiciones de accesibilidad mejoran en el módulo Accesible.

Figura 55. Prueba de accesibilidad en módulo noAccesible


La herramienta analiza cada elemento por separado como se logra observar en la imagen y realiza un resumen de lo que encontró, para esta página no se encuentran errores de ejecución ni de contraste, existen 12 alertas que hacen referencia a posibles prácticas que se podrían aplicar, adicionalmente se encontraron 35 características, 38 elementos estructurales y tan solo 7 elementos ARIA, estos elementos son descriptores de elementos especialmente útiles para lectores de pantalla o similares que buscaran estos elementos para complementar su narración. Estos resultados en términos generales nos indican que el diseño de este módulo, aunque cumple con algunos parámetros puede ser mejorado.

A continuación, se somete a la misma prueba la interfaz inicio del módulo Accesible para comparar los resultados:

120

Figura 56. Prueba de accesibilidad en el módulo Accesible


La herramienta analiza cada elemento por separado como se logra observar en la imagen y realiza un resumen de lo que encontró, para esta página no se encuentran errores de ejecución ni de contraste, no existen alertas referentes a buenas prácticas que se podrían aplicar, adicionalmente se encontraron 27 características, 31 elementos estructurales y 100 elementos ARIA, lo cual nos indica que mediante una reorganización y aplicación de recomendaciones WGAC se puede mejorar el nivel de accesibilidad de un sitio web.

Los colores del botón accesible también se colocaron a prueba gracias a otra funcionalidad que aporta está herramienta dando los siguientes resultados:

121

Figura 57. Prueba de contraste del botón accesible


El botón accesible tiene el color de fondo #5A2F00 en hexadecimal y de color de letra o foreground el color #39F33D los cuales en su conjunto según los resultados de la prueba generan una ratio de contraste 7.63 cumpliendo con el estándar AAA.

El formulario diseñado en el módulo noAccesible y en el módulo Accesible también se someten a prueba para verificar los elementos accesibles en cada uno de ellos.

122

Figura 58. Prueba de accesibilidad en formulario de módulo noAccesible


De esta prueba cabe recalcar la gran cantidad de errores que se generan principalmente por labels incompletos o faltantes, este diseño puede ser el que se presenta en muchos sitios web que no están pensados para contener esta clase de descripciones en los elementos ya que se confía en que toda la información debe estar explicita en la interfaz gráfica sin tener en cuenta software de lectura de pantalla u otras alternativas que usan las personas con discapacidad visual.

123

Figura 59. Prueba de accesibilidad en formulario de módulo Accesible


En esta prueba los resultados son mucho mejores respecto al módulo noAccesible, en esta interfaz se reporta el hallazgo de 65 elementos ARIA los cuales si los detallamos en la imagen resultan ser elementos de gran importancia al describir como se espera la interacción con los diferentes elementos, lo cual puede facilitar el diligenciamiento a los usuarios que no puedan depender completamente de la interfaz gráfica.

Los resultados para otras interfaces espejo siguen el mismo patrón en donde se reducen las alertas y errores mientras que aumenta la cantidad de elementos ARIA para el módulo Accesible, esto respalda el desarrollo realizado, mostrándose que la cantidad de elementos accesibles en este módulo es mayor, se cumple con recomendaciones de las pautas WGAC y se añade el valor agregado de la narración.

14.3.5 Resultado del plan de pruebas

A continuación, se resumen los resultados del plan de pruebas efectuado para este prototipo:

Tabla 23. Resultados del plan de pruebas

Id caso de prueba Script Resultado

CP-001 001 100% - Satisfactorio



124



14.3.6 Aceptación o rechazo del prototipo según pruebas

Teniendo en cuenta lo planteado en el plan de pruebas, los porcentajes de éxito en las pruebas funcionales, así como los elementos evaluados en las pruebas de accesibilidad y los resultados finales siendo en ambos escenarios satisfactorios, se decide aprobar la versión 1.0 de este prototipo de servicio web por parte del equipo de pruebas de software al cumplir con los requerimientos diseñados y la funcionalidad propuesta.

125

15. RESULTADOS

Como resultado de la ejecución del proyecto se obtuvieron los siguientes resultados que responden a cada uno de los objetivos específicos planteados, lo cual implica el cumplimiento a su vez del objetivo general planteado, para facilitar la navegación se referencian las secciones correspondientes con una palabra subrayada:

15.1RESULTADOS DEL PRIMER OBJETIVO ESPECIFICO

El primer objetivo específico planteado fue “Establecer los requerimientos funcionales y no funcionales mediante el estado del arte para el desarrollo del prototipo de servicio web inclusivo”.

Los resultados del desarrollo de este objetivo se encuentran en dos secciones del presente documento, en primer lugar, se estableció el ESTADO DEL ARTE comoun capítulo dedicado, subdividido en la descripción de la estrategia de búsqueda documental empleada, los antecedentes de investigación, desarrollos previos y la especificación de las palabras claves, toda esta información ordenada e interpretada resultó en la especificación de los REQUERIMIENTOS.

15.2RESULTADOS DEL SEGUNDO OBJETIVO ESPECIFICO

El segundo objetivo específico planteado fue “Generar los diagramas de arquitectura de software, requerimientos y pruebas funcionales mediante una metodología de trabajo propia para el apropiado diseño del prototipo de servicio web inclusivo”.

Los resultados del desarrollo de este objetivo se evidencian por una parte en la construcción de la METODOLOGÍA PROPUESTA la cual al ser aplicada paso a paso resultó en la generación de los diversos tipos de diagrama UML que están detallados y pueden ser encontrados en la FASE DE DISEÑO.

15.3RESULTADOS DEL TERCER OBJETIVO ESPECIFICO

Como tercer objetivo específico se indica “Construir el prototipo de servicio web inclusivo siguiendo los parámetros establecidos en la metodología propuesta para dar cumplimiento al diseño.”.

Este objetivo se cumplió mediante lo descrito en la FASE DE DESARROLLO,donde se siguió lo establecido en el diseño, de este desarrollo resaltamos en primer lugar la construcción de dos módulos que facilitan la comparación y ponen en

126

evidencia las ventajas de utilizar las pautas WGAC y elementos accesibles en páginas web de interés general, la navegación entre los módulos se realiza mediante el botón accesible construido el cual cumple parámetros de contraste:

Figura 60. Módulos desarrollados


El segundo elemento que resaltamos es la construcción de un formulario, con la finalidad de mostrar los potenciales beneficios que podrían aportar los desarrollos como la narración web en elementos que resultan muy comunes en diferentes webs, estos elementos de accesibilidad le dan la posibilidad al usuario de interactuar con los diversos tipos de campos, obteniendo una descripción clara de cómo puede diligenciar el formulario y logrando generar un registro en la base de datos.

127

Figura 61. Formulario desarrollado


Por último, se resalta la construcción de este prototipo haciendo uso de Docker para alcanzar una arquitectura de microservicios, la cual puede ser constatada mediante

128

la verificación de los cuatro contenedores propuestos en el diseño puestos en marcha y verificados mediante el comando “docker container ls” como se muestra a continuación:

Figura 62. Contenedores construidos


A continuación, se muestran otras interfaces visuales importantes desarrolladas en los dos módulos, debido a la extensión de estas interfaces las imágenes se leen de izquierda a derecha y de arriba a abajo:

Figura 63. Interfaz “inicio” modulo “noAccesible” parte superior


129

Figura 64. Interfaz “inicio” modulo “noAccesible” parte inferior

Fuente: Elaboración propia, 2021. Figura 65. Interfaz "inicio" modulo “Accesible”


130

Figura 66. Interfaz "elinstituto" módulo “noAccesible”


Figura 67. Interfaz "blog" módulo “noAccesible”


131

Figura 68. Interfaz "blog" módulo “Accesible”


Figura 69. Interfaz "atencion" modulo “noAccesible”


132

Figura 70. Interfaz "atencion" modulo “Accesible”

Fuente: Elaboración propia, 2021. Figura 71. Interfaz "participa" modulo “noAccesible”


133

Figura 72. Interfaz "participa” modulo "Accesible"


El resultado completo de este objetivo puede ser evidenciado en el CÓDIGO FUENTE, el cual puede ser revisado mediante el repositorio público en GitLab.

15.4RESULTADOS DEL CUARTO OBJETIVO ESPECIFICO

El cuarto y último objetivo refiere a “Validar las funciones principales del prototipo de servicio web inclusivo por medio de un escenario de pruebas para comprobar el adecuado funcionamiento del prototipo.”

La evidencia del desarrollo puede ser encontrada en la CREACIÓN DEL PLAN DE PRUEBAS, el cual fue seguido para comprobar el correcto funcionamiento de losprincipales módulos del prototipo, los criterios de este como se documenta refieren a la aceptación de este prototipo funcional al cumplir con los criterios mínimos planteados.

134

16. CONCLUSIONES

Del desarrollo de este proyecto podemos indicar que se logró delimitar, describir y seguir los pasos de una metodología personalizada con elementos DRM y SCRUM, la cual partió desde la investigación de antecedentes hacía la construcción de un estado del arte enfocado en soluciones de software para población con discapacidad visual, identificando falencias y fortalezas de los mismos con la finalidad de establecer los parámetros que permitieron diseñar y construir un prototipo de software accesible vía web que no dependiera de la tecnología JAWS.

El diseño realizado permitió establecer los requerimientos tanto funcionales como los no funcionales partiendo de la información recolectada, analizada y descrita, de forma similar la utilización de lenguajes estándares como UML permitió la generación de diagramas de arquitectura de software, clases, entidad-relación entre otros necesarios para el desarrollo del prototipo.

Se logró construir el prototipo gracias a especificar un diseño detallado y a la utilización de herramientas de desarrollo como Django y de despliegue como Docker, junto a librerías y API de acceso libre que facilitaron la construcción el software siguiendo la arquitectura de microservicios planteada.

Las pruebas de software más relevantes se lograron realizar con éxito a causa de la construcción de un plan de pruebas que permitió evaluar tanto elementos de accesibilidad siguiendo las pautas WGAC como también elementos funcionales del prototipo como inserciones a base de datos y pruebas de carga y estrés que fueron superadas de forma satisfactoria.

Como conclusión final resaltamos el aporte que este proyecto aporta al campo de la ingeniería de sistemas y computación, en especial en el área de la accesibilidad web, el cual contribuye a establecer conocimiento sobre los parámetros que pueden seguir propuestas de softwares similares que tengan como objeto mejorar las condiciones de acceso a la información web por parte de la población con discapacidad visual en Bogotá, los cuales pueden adoptar parte de la metodología aquí planteada teniendo en cuenta también las limitaciones del proyecto en cuanto a las herramientas empleadas, el lenguaje local, los recursos que se emplearían para crear una solución integral y las limitaciones legales.

135

17. TRABAJO FUTURO

A manera de continuación del trabajo de esta tesis, y como resulta naturalmente en cualquier proceso de investigación varias líneas de trabajo permanecen abiertas, en las cuales el proyecto puede seguir desarrollándose, algunas de ellas surgen como extensiones que mejorarían el alcance o integralidad del proyecto y otras que surgieron como propuestas interesantes que por alejarse del objeto principal no fueron foco de atención durante el desarrollo del mismo y que se detallan así:

• Aportar elementos de seguridad adicionales al prototipo como las medidasque recomienda la OWASP, organismo sin fines de lucro dedicada a mejorarla seguridad del software123 a través de proyectos de software de códigoabierto liderados por la comunidad y otras iniciativas, debido a que lasmedidas de seguridad actuales son básicas.

• Mejorar el módulo “Accesible” incorporando en lo posible la totalidad de lasrecomendaciones WGAC ya que las aplicadas en el prototipo fueron las quese evaluaron como fundamentales.

• Implementar un sistema dinámico de gestión y entrega de contenidosteniendo en cuenta que estos son elementos presentes en funcionalidadescomo el blog del INCI o la atención a la ciudadanía, considerando que dichaimplementación extendería el alcance del proyecto al ofrecer mayoresfuncionalidades a la población con discapacidad visual.

• Proponer a actores públicos o privados de la escena nacional unacombinación o adaptación de la propuesta para ser integrada como unmódulo accesible a las páginas web que se logren acordar para de estamanera contribuir al acceso de la información web para la población condiscapacidad visual.

• Evaluar el impacto real de la plataforma web a través de encuestas a losusuarios de la misma con la finalidad de garantizar la mantenibilidad,usabilidad y actualización de la misma para que en cada iteración losservicios que este preste sean de mayor calidad.

• Describir de forma más detallada las necesidades e interacciones de lapoblación con discapacidad visual de Bogotá ampliando a partir de lametodología el nivel de la investigación hasta el de estudio descriptivo IIsegún los parámetros DRM, de esta forma sería posible comprender demanera más profunda elementos que posiblemente en este desarrollo nofueron puestos a consideración, esto resultaría en una solución más integral.

123 OWASP Foundation. "Who is the OWASP® Foundation?". [En línea]. [10 de octubre de 2021]. Disponible en: https://owasp.org

136

18. BIBLIOGRAFÍA

ANGELES-ANGELES, Francisco. Prototipo. Ciudad de México: Con-Ciencia Boletín Científico de la Escuela Preparatoria, 2020, 33p.

ANGKANANON, Kewalin; WALD, Mike; PLOADAKSORN, Piyabud. Development and testing of a thai website accessibility evaluation tool. vol 10. Tailandia. 2020. 4901p.

ARIAS, Johana; LLANO, Yuliana; ASTUDILLO, Esai; SUAREZ, Juan. Caracterización clínica y etiología de baja visión y ceguera en una población adulta con discapacidad visual. Ciudad de México: Revista Mexicana de Oftalmología, 2020. 202p.

BECKER, Mathias; SCHÜTT, Brigitta; AMINI, Siawuch. Proposal Writing for International Research Projects: Project considerations. Berlin: Deutscher Akademischer Austauschdienst, 2014. 52p.

BLAZIE. About Blazie. [En línea]. [25 de marzo de 2021]. Disponible en: https://www.blazie.co.uk/site/about

BLESSING, Luciene; CHAKRABARTI, Amaresh. DRM, a Design Research Methodology: Methodological Framework. Luxemburgo: Springer Dordrecht Heidelberg London New York, 2009. 76p.

BOOTSTRAP. "Accessibility". [En línea]. [26 de agosto de 2021]. Disponible en: https://getbootstrap.com/docs/5.1/getting-started/accessibility/

BOOTSTRAP. "Introduction". [En línea]. [26 de agosto de 2021]. Disponible en: https://getbootstrap.com/docs/5.1/getting-started/introduction/

BOUDEGUER, Andrea. Manual de Accesibilidad Universal. Santiago de Chile, 2010. 12p.

BOWEN, Jonathan. WEB ACCESS TO CULTURAL HERITAGE FOR THE DISABLED. Londres, 2003.

BURCO, Fabio; MICULAN, Marino; PERESSOTTI, Marco. Towards a Formal Model for Composable Container Systems: BIGRAPHS FOR CONTAINERS. Brno: 35th Annual ACM Symposium on Applied Computing, 2020. 174p.

CABELLO, Victoria. Introducción a las bases de datos relacionales. Vision Libros, 2010. 20p.

137

CASTRO, Carlos. La Matriz de Vester. [En línea]. [25 de marzo de 2021]. Disponible en: https://es.scribd.com/document/35150680/La-Matriz-de-Vester#scribd

CLOUDSIGHT INC. TapTapSee: Assistive Technology for the Blind and Visually Impaired. [En línea]. [25 de marzo de 2021]. Disponible en: https://taptapseeapp.com

COBO Angel, PHP y MySql. Tecnologías para el desarrollo de aplicaciones web. Madrid: Editorial Diaz de Santos, 2005. 3p.

COLOMBIA. ASAMBLEA NACIONAL CONSTITUYENTE 1991. Constitución Política de Colombia. En: Gaceta Constitucional No. 116 de 20 de julio de 1991. p. 3.

COLOMBIA. CONCEJO DE BOGOTÁ, D.C. Acuerdo No. 761 de 2020 (11, junio, 2020). Por medio del cual se adopta el plan de desarrollo económico, social, ambiental y de obras públicas del Distrito Capital 2020-2024. Imprenta distrital. junio, 2020. p.163.

COLOMBIA. CONGRESO DE LA REPÚBLICA. Ley 1346. (31, julio, 2009). Por medio de la cual se aprueba la “Convención sobre los Derechos de las personas con Discapacidad”, adoptada por la Asamblea General de la Naciones Unidas el 13 de diciembre de 2006. En: Diario Oficial. Julio, 2009. Nro. 47427. p. 2.

COLOMBIA. CONGRESO DE LA REPÚBLICA. Ley 1618. (27, febrero, 2013). Por medio de la cual se establecen las disposiciones para garantizar el pleno ejercicio de los derechos de las personas con discapacidad. En: Diario Oficial. Febrero, 2013. Nro. 48717. p. 1.

COLOMBIA. CONGRESO DE LA REPÚBLICA. Ley 1680. (20, noviembre, 2013). Por la cual se garantiza a las personas ciegas y con baja visión, el acceso a la información, a las comunicaciones, al conocimiento y a las tecnologías de la información y de las comunicaciones. En: Diario Oficial. Noviembre, 2013. Nro. 48980. p. 1.

COLOMBIA. CONGRESO DE LA REPÚBLICA. Ley 361. (07, febrero, 1997). Por la cual se establecen mecanismos de integración social de las personas en situación de discapacidad y se dictan otras disposiciones. En: Diario Oficial. Febrero, 1997. Nro. 42978. p. 1-3.

CONTRERAS, Diego. Arquitectura de microservicios. Bogotá: Tecnología Investigación Y Academia, 2018, 37p.

138

CUEVA, Juan. Calidad del Software. Pamba: Grupo Gidis Universidad Nacional de la Pamba, 1999. 3p.

DEPARTAMENTO NACIONAL DE PLANEACIÓN. PLAN NACIONAL DE DESARROLLO 2018-2022: Pacto por Colombia, pacto por la equidad: PACTO POR LA INCLUSIÓN DE TODAS LAS PERSONAS CON DISCAPACIDAD. Bogotá D.C: Imprenta Nacional de Colombia, 2019. 1111p.

DJANGO. "How to get Django". [En línea]. [13 de octubre 2021]. Disponible en: https://www.djangoproject.com/download/

DOCKER DOCS. "Dockerfile reference". [En línea]. [29 de marzo de 2021]. Disponible en: https://docs.docker.com/engine/reference/builder/

DOCKER DOCS. "Get Docker". [En línea]. [13 de octubre 2021]. Disponible en: https://docs.docker.com/get-docker/

DOLPHIN COMPUTER ACCESS LTD. Magnification and screen reading for Windows. [En línea]. [25 de marzo de 2021]. Disponible en: https://yourdolphin.com/en-gb/products/individuals/families/supernova

ESCUDERO, Juan Camilo Suárez. Discapacidad visual y ceguera en el adulto: revisión de tema. Bogotá: Medicina UPB, 2011. 173p.

FOGLI, Daniela; ARENGHI, Alberto; GENTILIN, Fulvio. A universal design approach to wayfinding and navigation. Italia,2019.6p.

FORGLI, Daniela; PROVENZA, Loreadana; BERNAREGGI, Cristian. A Design Pattern Language for Accessible Web Sites. Brescia y Milano, 2014.

GALIANO, Josep. Implantar scrum con éxito: Introducción. Berlin: Editorial UOC, 2016. 13p.

GALLEGOS, Monica. LOS SERVICIOS WEB XML: Introducción a los Servicios Web:ICA -EISIC, 2011. 73p.

GAZIS, Alexandros; KATSIRI Elefheria. Web Frameworks Metrics and Benchmarks for Data Handling and Visualization: Future work. Xanthi: Department of Electrical and Computer Engineering, 2019. 147p.

GIT BOOK. "Welcome to TestProject!". [En línea]. [s.f.]. Disponible en: https://docs.testproject.io/

139

GITHUB. "web-speech-api: License". [En línea]. [26 de agosto de 2021]. Disponible en: https://github.com/mdn/web-speech-api/blob/master/LICENSE

GNOME. Bienvenido/a Orca. [En línea]. [25 de marzo de 2021]. Disponible en: https://help.gnome.org/users/orca/stable/introduction.html.es

GUERRERO, Javier; MOCHA-BONILLA, Julio; ZAPATA-MOCHA, Esmeralda; Rios, Sandra. Design of an Accessible Web Portal for the Labor Insertion of people with blindness. IMLC 2019 y AISC 1192. Ambato: Springer Nature Switzerland, 2021

GUTIÉRREZ, Javier. ¿Qué es un framework web? [En línea]. [20 de abril de 2021]. Disponible en: http://www.lsi.us.es/~javierj/investigacion_ficheros/Framework.pdf

HARPER, Simon; YESILADA Yeliz. Accessibility and Guidelines: Web Accessibility. Mánchester. 2008. 3p.

HASS, Hugo. Web Services Glossary. [En línea]. [06 de abril de 2021]. Disponible en: https://iso25000.com/index.php/en/iso-25000-standards/iso-25010.

HUMANWARE. What is TouchBraille?. [En línea]. [25 de marzo de 2021]. Disponible en: https://www.humanware.com/microsite/bntouch/faq.php#Q5

INCLUYEME. Todo lo que necesitas saber sobre discapacidad visual. [En línea]. [16 de febrero de 2017]. Disponible en: https://www.incluyeme.com/todo-lo-que-necesitas-saber-sobre-discapacidad-visual/

INSTITUTO NACIONAL PARA CIEGOS. Aplicaciones INCI en la cuarentena. [En línea]. [06 de abril de 2021]. Disponible en: https://www.inci.gov.co/blog/aplicaciones-inci-en-la-cuarentena

INSTITUTO NACIONAL PARA CIEGOS. Funciones. [En línea]. [06 de abril de 2021]. Disponible en: https://www.inci.gov.co/funciones

INSTITUTO NACIONAL PARA CIEGOS. Los ciegos en el Censo 2018. Edición 106. Bogotá. INCIDigital, 2018.Disponible en https://www.inci.gov.co/blog/los-ciegos-en-el-censo-2018

ISO 25000. ISO/IEC 25010. [En línea]. [06 de abril de 2021]. Disponible en: https://iso25000.com/index.php/en/iso-25000-standards/iso-25010.

IVANOVA, Desislava; MITEV, Daniel. Usability strategy and guidelines for building an accessible web portal. ed 1. Bulgaria: AIP Publishing. 2021. 3p.

KIMMEL, Paul. Manual de UML. McGraw-Hill Interamericana, 2002. 1p.

140

KORTH, Henry; SILBERSCHATZ, Abraham. Fundamentos de bases de datos. Cuarta edición. Madrid: McGraw-Hill, 1993. 17p.

LEONE, Diego; GIORDANI, Claudio. ACCESIBILIDAD. Buenos Aires.2p.

LÓPEZ, Sara; RAMÍREZ, Andrés. Análisis de la efectividad de la audiodescripción en el cine para personas en situación de discapacidad visual en la Unión Nacional de Limitados Visuales de la ciudad de Medellín. Trabajo de grado Comunicación Social y Periodismo. Medellín.: Corporación Universitaria Minuto de Dios. Facultad de Ciencias Sociales y Humanas. 56 p.

LUME, Juan; LAM, Eduardo; YENDO, Rudy; BARRIGA Aránzazu. Guía de investigación en Arte y Diseño.: Methodological Framework. Lima: Pontificia Universidad Católica del Perú, 2019. 14p.

HETHEY, Jonathan. GitLab Repository Management: Delve into managing your projects with GitLab, while tailoring it to fit your environment. 1. Birmingham: Packt Publishing Ltd., 2013. 17p.

MAISAK, Rattanavalee.Op. cit 45p.

MARUEL, Fabrice; DIAS,Gaël; SAFI, Waseem; ROUTOURE, Jean-Marc Y BEUST, Pierre. Layout Transposition for Non-Visual Navigation of Web Pages by Tactile Feedback on Mobile Devices.Syria,2020. 4p.

MDN WEB DOCS. "Web Speech API". [En línea]. [26 de agosto de 2021]. Disponible en: https://developer.mozilla.org/en-US/docs/Web/API/Web_Speech_API

MELO, Tania. "Cerca del 80% de personas con discapacidad no encuentran empleo en Colombia". [En línea]. [25 de marzo de 2021]. Disponible en: https://www.rcnradio.com/economia/cerca-del-80-de-personas-con-discapacidad-no-encuentran-empleo-en-colombia

MICROSOFT DOCS. "Docker containers, images, and registries". [En línea]. [29 de marzo de 2021]. Disponible en: docs.microsoft.com/en-us/dotnet/architecture/microservices/container-docker-introduction/docker-containers-images-registries

MINISTERIO DE SALUD. PROGRAMA NACIONAL DE ATENCIÓN INTEGRAL EN SALUD VISUAL 2016-2022: Organización del Programa: Objetivos estratégicos. Bogotá D.C: Biblioteca digital MinSalud, 2016. 66p.

141

MINISTERIO DE TECNOLOGÍAS DE LA INFORMACIÓN Y LAS COMUNICACIONES. ConVerTIC. [En línea]. [2013]. Disponible en: https://convertic.gov.co/641/w3-propertyvalue-36246.html

MORA, Sergio. JAWS. [En línea]. [25 de marzo de 2021]. Disponible en: http://accesibilidadweb.dlsi.ua.es/?menu=jaws

MUÑOZ, José. “Las TIC y la discapacidad visual.” [En línea]. [17 de marzo de 2021]. Disponible en: https://ruc.udc.es/dspace/bitstream/handle/2183/13227/CC-127_art_18.pdf?sequence=1&isAllowed=y

NATIONAL FEDERATION OF THE BLIND. KNFB Reader. [En línea]. [25 de marzo de 2021]. Disponible en: https://nfb.org/programs-services/knfb-reader

NORIEGA, Raúl. El proceso de desarrollo de software: Proceso de desarrollo de software. Madrid: IT Campus Academy, 2015. 8p.

NV Access. About NVDA. [En línea]. [25 de marzo de 2021]. Disponible en: https://www.nvaccess.org/about-nvda/

OMS. Ceguera y discapacidad visual. [En línea]. [06 de abril de 2021]. Disponible en: https://www.who.int/es/news-room/fact-sheets/detail/blindness-and-visual-impairment

OWASP Foundation. "Who is the OWASP® Foundation?". [En línea]. [10 de octubre de 2021]. Disponible en: https://owasp.org

PARDO, Monica. "Las personas con discapacidad visual siguen siendo invisibles en Colombia". [En línea]. [06 de abril de 2021]. Disponible en: https://www.semana.com/contenidos-editoriales/la-ceguera-no-es-una-barrera/articulo/las-personas-con-discapacidad-visual-siguen-siendo-invisibles-en-colombia/202028/

PARRA, Carlos. INCI: Los ciegos en el Censo 2018. [En línea]. [06 de abril de 2021].Disponible en: https://www.inci.gov.co/blog/los-ciegos-en-el-censo-2018

PEERBITS. "Node.js vs Django vs Laravel: Which is the best back-end web framework in 2021?". [En línea]. [26 de agosto de 2021]. Disponible en: https://www.peerbits.com/blog/nodejs-vs-django-vs-laravel-back-end-web-framework.html

PEERBITS. "Nuestra Historia". [En línea]. [26 de agosto de 2021]. Disponible en: https://www.peerbits.com/our-story.html

142

PETRIE, Helen; BEVAN, Nigel. The Evaluation of Accessibility, Usability, and User Experience. vol 10. Londres, 2009. 9p.

PINA, Alessandro; BAEZ, Marcos y DANIEL, Florian. Bringing Cognitive Augmentation to Web Browsing Accessibility. Milan, 2020. 8p.

PIVETTA, Elisa Maria; FLOR, Carla; SATOMI SAITO, Daniela, RIVAS ULBRICHT, Vania. "Analysis of an Automatic Accessibility Evaluator to Validate a Virtual and Authenticated Environment". [En línea]. [2013]. Disponible en: https://dx.doi.org/10.14569/IJACSA.2013.040403.

PNEUMA SOLUTIONS. Sero: The World’s Largest, Easy-to-Navigate, Social Network and Multi-Media Repository for Blind People on the Web. [En línea]. [25 de marzo de 2021]. Disponible en: https://pneumasolutions.com/products/sero/

POVEDA, Francisco; ORIGEN Y EVOLUCIÓN DE LOS LENGUAJES DE MARCADO: A PROPÓSITO DE XHTML Y HTML5. Trabajo de grado Información y Comunicación. Murcia.: Universidad de Murcia. Facultad de Comunicación y Documentación. 30 p.

PYTHON. "Python 3.9.6". [En línea]. [13 de octubre 2021]. Disponible en: https://www.python.org/downloads/release/python-396/

RAMIREZ, Marta. Discapacidad visual: Guía didáctica para la inclusión en educación inicial y básica. México, 2010. 15p.

ROBINSON, Scott S. Sobre la inclusión digital. Caracas: Nueva sociedad. 2005. 127p.

SATYANARAYANA, S. "CLOUD COMPUTING: SAAS". [En línea]. [2012]. Disponible en: https://www.academia.edu/21491005/CLOUD_COMPUTING_SAAS

SEROTEK ACCESSIBILITY, ANYWERE; AIR FOUNDATION. System Access to Go. [En línea]. [25 de marzo de 2021]. Disponible en: https://www.satogo.com/en/

SIVAKUMAR, P; NANDHAKUMAR, M; JAYARAJ, R; KUMARAN, A. Sakthi. "Securing Data and Reducing the Time Traffic Using AES Encryption with Dual Cloud". [En línea]. [29 de marzo de 2019]. Disponible en: https://ieeexplore.ieee.org/abstract/document/8878749

STONY BROOK UNIVERSITY. "I.V. Ramakrishnan". [En línea]. [25 de marzo de 2021]. Disponible en: https://www.cs.stonybrook.edu/people/faculty/IVRamakrishnan

143

SUAREZ, Juan Camilo. Discapacidad visual y ceguera en el adulto: Adult visual impairment and blindness. Medellin: vol 30, 2011.

SYDIK, Jeremy. Design Accessible web sites: Thirty-six Keys to creating content for all audiences and platforms. Estados Unidos, 2007. 74p.

TERÁN, Julián. Manual de Introducción al lenguaje HTML. Formación para el Empleo: ORÍGENES Y EVOLUCIÓN DE HTML. Madrid: Editorial CEP, S.L., 2016. 18p.

THE WEBBIE ORGANIZATION. Thunder Screenreader. [En línea]. [25 de marzo de 2021]. Disponible en: https://www.webbie.org.uk/thunder/

W3C. Introducción a la Accesibilidad Web. [En línea]. [21 de abril de 2021]. Disponible en: https://www.w3.org/WAI/fundamentals/accessibility-intro/es

W3C. Web Content Accessibility Guidelines (WCAG) 2.0. [En línea]. [9 de abril de 2021]. Disponible en: https://www.w3.org/

144

ANEXOS

145

ANEXOS

1.1 CÓDIGO FUENTE

Publicar el código fuente del proyecto en herramientas como GitLab ayuda a la inspección y mejoramiento continuo del prototipo propuesto, es por ello que aquí se provee la URL del repositorio en donde se construyó el código fuente:

• https://gitlab.com/bnzea20/proyecto-de-grado

La construcción del prototipo se hizo de manera concertada y ordenada entre los autores del presente trabajo de investigación de ello da cuenta el resumen de contribuciones generado por GitLab que se anexa a continuación:

Anexo A. Contribuciones a código fuente

Fuente: Elaboración propia, 2021. 1.2 VIDEO DEMOSTRATIVO

Para comprender de mejor forma el funcionamiento del prototipo desarrollado se realizó un video demostrativo, el cual puede ser accedido desde la siguiente URL, la cual pude ser accedida en un navegador que soporte JavaScript y HTML5:

• https://1drv.ms/u/s!Ar25OxFm-Tjoph2OXMwGSqPly9s2?e=JuJbe2

1.3 MANUAL DE USUARIO

1.3.1 Introducción

El presente manual de usuario tiene como objetivo servir como guía de instalación del software requerido, así como la utilización del software por parte de usuarios interesados en hacer uso de este prototipo de servicio web accesible que funciona sin depender de la tecnología JAWS para personas con discapacidad visual en Bogotá.

https://gitlab.com/bnzea20/proyecto-de-grado

https://1drv.ms/u/s!Ar25OxFm-Tjoph2OXMwGSqPly9s2?e=JuJbe2

146

1.3.2 Instalación de Docker en Windows y Linux

Para poder hacer uso de este prototipo es necesario contar con Docker instalado en nuestro ordenador, para lograr esto es recomendable seguir los siguientes pasos en caso de contar con el sistema operativo Windows 10.

• Descargar Docker Desktop desde el sitio web oficial de Docker:docs.docker.com/desktop/windows/install ingresando en el botón “DockerDesktop for Windows” previa lectura de los términos y condiciones parautilizar el software, es importante también realizar lectura de losrequerimientos mínimos de sistema que se indican también en esta página.

Anexo B. Descarga de Docker Desktop para Windows


• Una vez descargado el instalador lo ejecutamos, se nos preguntara sideseamos instalar WSL 2, en caso que no lo tengamos instalado previamentemarcaremos las casillas correspondientes como se muestra a continuación:

docs.docker.com/desktop/windows/install

147

Anexo C. Configuraciones de instalador de Docker Desktop


• Una vez confirmadas las configuraciones, comenzara el proceso de descargae instalación, este proceso puede tardar varios minutos, podemos ver elavance en la interfaz gráfica como se muestra:

Anexo D. Desempaquetado de Docker Desktop


• Una vez más se nos pedirá repasar los términos y condiciones y aceptarlos,una vez realizado esto, Docker Desktop comenzará a cargar los elementosnecesarios como se muestra a continuación:

148

Anexo E. Docker Desktop inicializándose


Docker Desktop habrá cargado correctamente una vez el icono de nuestra interfaz se muestre en verde como se muestra a continuación, es posible que se requiera un reinicio en este paso:

149

Anexo F. Docker Desktop preparado


Para el caso de sistemas operativos Linux el procedimiento se realiza mediante paquetes .deb o .rpm y dependiendo de la distribución tendremos que realizar pasos diferentes, una guía completa de la instalación en Linux la ofrece Docker en este enlace: https://docs.docker.com/engine/install/

https://docs.docker.com/engine/install/

150

Anexo G. Disponibilidad de Docker en Linux


Una vez realizados los pasos necesarios para nuestra distribución Linux podremos ejecutar por consola “docker --version” lo cual en caso de haber realizado la instalación de forma correcta nos devolverá una versión como se muestra:

Anexo H. Verificar instalación de Docker en Linux


1.3.3 Bajar el repositorio desde GitLab

El siguiente paso que realizaremos para ejecutar el prototipo es bajar el repositorio con el código fuente desde GitLab, para ello la forma más sencilla de realizarlo es dirigirse a https://gitlab.com/bnzea20/proyecto-de-grado y desde la esquina superior derecha dar clic en el botón de descarga y escogeremos la opción zip como se muestra:

https://gitlab.com/bnzea20/proyecto-de-grado

151

Anexo I. Descarga de repositorio desde GitLab


Una vez tenemos el archivo .zip procedemos a extraerlo en una ubicación que seleccionemos en nuestro disco duro lo cual nos deberá dejar una carpeta como esta:

Anexo J. Repositorio en disco duro


En este punto ya tendremos el código fuente necesario en nuestro almacenamiento, el siguiente paso es poner en marcha el prototipo.

1.3.4 Poner en marcha los contenedores

Ingresaremos a la carpeta obtenida en el paso anterior y observaremos una estructura como la que se muestra a continuación:

152

Anexo K. Carpeta del prototipo

Fuente. Elaboración propia, 2021.

En un espacio en blanco manteniendo el botón Mayús y dando clic derecho en el mismo momento se despliega un menú contextual en donde seleccionaremos la opción “Abrir la ventana de PowerShell aquí”, una alternativa a esto puede ser navegar hasta la ubicación de la carpeta desde la consola haciendo uso del comando “cd”.

Anexo L. Menú contextual

153

Fuente: Elaboración propia, 2021. Una vez tengamos la ventana de comandos abierta, ejecutaremos el comando “docker-compose up”, de esta forma se empezarán a construir los contenedores del prototipo, este procedimiento puede tardar varios minutos en especial cuando es la primera vez que se ejecuta este comando, la ejecución de este comando debe verse similar a esto:

Anexo M. Comando docker-compose up en ejecución


Después de esperar algunos momentos, comprobaremos si los contenedores ya están preparados para ser utilizados, para ello abrimos otra ventana de PowerShell ya que la ejecución de los contenedores en la primera ventana evita que pueda ser usada, en esta nueva ventana podemos utilizar el comando “docker container ls”, cuando los contenedores estén en marcha debemos obtener un resultado de este comando como el que se muestra a continuación:

Anexo N. Comprobación de creación de contenedores


154

1.3.5 Navegar por el módulo noAccesible

Una vez los contenedores estén corriendo podemos comenzar a explorar el módulo “noAccesible” el cual es una réplica personalizada de la página del INCI, para ello podemos ingresar a nuestro navegador y digitar lo siguiente “localhost:8000/inicio/”, al realizar esto visualizaríamos la interfaz gráfica del inicio tal como se muestra:

Anexo O. Inicio del módulo noAcessible


Podemos entonces navegar por los menús identificando las diferentes imágenes, textos y elementos que componen este módulo y que están rediseñados para facilitar la identificación de la intención de cada módulo, nuestra principal herramienta de navegación en este módulo será la barra de navegación mediante la cual nos podremos desplazar entre las diversas páginas, algunas de estas se presentan a continuación:

155

Anexo P. Página “elinstituto” del módulo noAccesible


Anexo Q. Página “formulario” del módulo noAccesible


156

1.3.6 Navegar por el módulo Accesible del prototipo

Para ingresar al módulo Accesible tenemos que presionar el botón accesible desde el módulo noAccesible, el botón se encuentra en la parte superior de la página, en la siguiente imagen se indica su posición:

Anexo R. Ubicación del botón accesible


De la misma forma podemos entonces navegar por los menús identificando las diferentes imágenes, textos y elementos que componen este módulo prestando atención a los elementos de contraste, las fuentes más amplias y los elementos de narración que podemos activar desplazando el cursor sobre los elementos o navegando por los elementos mediante el botón de tabulación, al igual que en el módulo noAccesible nuestra principal herramienta de navegación será la barra de navegación mediante la cual nos podremos desplazar entre las diversas páginas.

Anexo S. Página “elinstituto” del módulo Accesible


157

1.3.7 Realizar una inserción de hoja de vida en la base de datos

Si queremos realizar una inserción de datos a la base de datos, es necesario que primero preparemos la base de datos, para facilitarnos esta tarea ejecutaremos las migraciones a la base de datos, para ello abriremos nuestro Docker Desktop e ingresaremos al contenedor “django_app_container”, esta operación también la podemos realizar mediante la consola utilizando el comando “docker exec -ti id /bin/bash” remplazándose el id con el id del contenedor que puede ser obtenido ejecutando el comando “docker container ls”.

Allí insertaremos los siguientes comandos en orden: 1. python docker_django/manage.py makemigrations ProyectoVision2. python docker_django/manage.py sqlmigrate ProyectoVision 00013. python docker_django/manage.py migrate

Debemos obtener en la consola una salida similar a la siguiente con confirmaciones “OK”:

Anexo T. Resultado de las operaciones de migración


Una vez realizado esto podemos acceder a “localhost:8000/formulario” o a “localhost:8000/aformulario”, en donde podemos comenzar a diligenciar los campos solicitados, una vez llenados los campos presionamos el botón para insertar la información como se muestra en la imagen:

158

Anexo U. Ubicación del botón validar para para insertar datos


Si la inserción se realiza de forma exitosa recibirá una alerta en la interfaz gráfica indicándole el resultado de la operación.

1.3.8 Administrar la base de datos Postgres

Si desea utilizar las funcionalidades de administración sobre la base de datos postgres deberá ingresar con su navegador a “localhost:8080” lo cual le permitirá ingresar al gestor de base de datos de pgadmin:

159

Anexo V. Interfaz pgAdmin por el puerto 8080


Ingrese al gestor con las siguientes credenciales que están configuradas por defecto:


• Contraseña: secret

Una vez dentro del gestor tendremos que conectarnos al servidor para ello damos clic derecho sobre server y creamos una nueva conexión, esto nos debe desplegar una ventana como la que se muestra a continuación:

160

Anexo W. Opción de conexión a servidor de base de datos


Ingresaremos en la opción server y digitaremos las siguientes credenciales en la ventana de configuración:

• Nombre: docker

• Host: 192.168.1.3

• Database: postgres

• Usuario: admin

• Contraseña: secret

Obteniendo una interfaz como la siguiente:

161

Anexo X. Configurar la conexión al servidor de base de datos


Una vez ingresadas las credenciales tendremos acceso a la base de datos, los registros, allí podremos realizar las operaciones que nos permite pgadmin sobre la base de datos para efectuar tareas de mantenimiento y administración, esta base de datos es persistente y los datos se almacenaran así los contenedores sean detenidos.

1.3.9 Detener los contenedores

Una vez terminada la exploración del prototipo podemos detener los contenedores para terminar la ejecución del prototipo, para ello nos dirigimos a la carpeta raíz del proyecto, manteniendo Mayús y clic derecho podemos abrir una ventana de PowerShell y digitar el siguiente comando “docker compose down” el cual se encargará de detener las redes y contenedores de Docker, el resultado debe ser similar a esto:

162

Anexo Y. Comando "docker-compose down” en ejecución


1.3.10 Solución de problemas comunes

Los problemas más comunes que pueden surgir al intentar ejecutar este prototipo son los que están relacionados con la puesta en marcha de Docker ya que este presenta problemas con el hipervisor de Windows ya que Docker requiere tener acceso exclusivo a la tecnología de virtualización, la solución a estos problemas está siendo discutida por la comunidad de GitHub ya que cada caso tiene sus peculiaridades, recomendamos leer el siguiente foro para encontrar alternativas de solución: github.com/docker/for-win/issues/6772

1.4 MANUAL TÉCNICO

1.4.1 Introducción

El siguiente manual se construye con la finalidad de describir y exponer información necesaria para realizar las labores de mantenimiento y desarrollo del prototipo enfocada en desarrolladores, enfatizándose aspectos técnicos fundamentales del prototipo de servicio web accesible que funciona sin depender de la tecnología JAWS para personas con discapacidad visual en Bogotá.

1.4.2 Requisitos mínimos

En primer lugar, debemos hablar de los requisitos mínimos recomendados para poder modificar el software y realizar tareas de mantenimiento y desarrollo de forma efectiva, los requisitos mínimos de ordenador que se aconsejan son:

• Windows 10 o versiones recientes de Linux compatibles con Docker.

• Procesador con arquitectura de 64 bits.

• 4 GB de RAM.

• Virtualización activa desde la BIOS.

• 2 GB de almacenamiento.

• Navegador con compatibilidad para HTML5 y JavaScript.

• Periféricos: Ratón, bocinas, teclado.

• Conexión a internet de 1MB.

github.com/docker/for-win/issues/6772

163

1.4.3 Licencia de software

Para los desarrolladores o personas que decidan mejorar o continuar con el desarrollo de este proyecto deben tener en cuenta que este trabajo está bajo licencia Creative Commons Atribución-NoComercial 4.0 Internacional (CC BY-NC 4.0), es decir que debe tener presente otorgarles créditos a los autores y no usarlo con fines comerciales.

1.4.4 Alcance actual y objetivo del prototipo

El prototipo actual tiene un alcance limitado el cual se enfocó en lograr desarrollar la arquitectura de microservicios, la creación de algunos HTML con la finalidad de mostrar una comparación entre los módulos noAccesible y Accesible, así mismo se hizo énfasis en desarrollar la totalidad de la red en Docker y la conexión entre contenedores y realizar almacenamiento persistente, sin embargo algunos elementos no alcanzaron a ser desarrollados debido a la limitación temporal con la que se contaba entre ellos quedan pendiente el desarrollo de interfaces web que realmente actúen como un sitio web dinámico actualizándose entradas en el blog INCI por ejemplo o las noticias. En este sentido lo que se busca como objetivo futuro es que el prototipo sea el paso inicial hacía plataformas web que no pierdan funcionalidad, mantengan sus elementos visuales y se adapten a las pautas WGAC integrando la narración de elementos con la finalidad de acercar la inclusión digital a la población con discapacidad visual en Bogotá.

1.4.5 Archivos de configuración

Resulta importante describir algunos de los archivos de configuración que se tienen presente en el proyecto para facilitar las labores de mantenibilidad y actualización del software, el primer archivo de configuración relevante es local.conf ubicado dentro de la carpeta “config” del proyecto, a continuación, se muestra su estructura:

164

Anexo Z. Estructura de local.conf


Este archivo de configuración resulta fundamental en la configuración del servidor nginx, al comienzo del archivo se considera el flujo en “upstream” de la aplicación levantando el servidor de la aplicación por el puerto 8000, el siguiente objeto en el archivo hace referencia a la configuración del servidor, este estará escuchando por el puerto 80 con una dirección IP y mascara específicas, se le indica la locación de los archivos estáticos en el código mediane la instrucción de “location /static/” en donde la ubicación relativa “/code/static/” es definida. Por otra parte, las configuraciones de proxy son definidas más abajo estableciendo instrucciones para permitir la redirección y el manejo de cabeceras.

Otro archivo de configuración que resulta importante describir es el archivo principal de configuración que se encuentra en Django, es decir “settings.py” en especial porque allí se realiza la tarea de conexión a la base de datos desde Django, a continuación, se muestra la estructura de conexión presente en este archivo:

165

Anexo AA. Conexión a base de datos desde Django


El motor de conexión que se utiliza por defecto es django.db.backends.postgresql, con el parámetro NAME se le indica que realice la búsqueda de la base de datos con ese nombre, intentando realizar la conexión usando el usuario admin, la contraseña secret, el host db_postgres por el puerto 5432 del contenedor, estas configuraciones permiten la correcta aplicación de las migraciones a la base de datos y de la inserción de registros.

Es posible que como desarrollador o usuario administrador necesite utilizar un “superusuario” para revisar o modificar las configuraciones internas, para ello se recomienda utilizar el comando “Python manage.py createsuperuser” bien sea dentro del contenedor en ejecución mediante “exec” o enviando estos parámetros mediante la modificación del archivo docker-compose.yaml para facilitar la automatización, el usuario administrador recién creado podrá ingresar a las configuraciones internas de Django mediante la URL “localhost:8000/admin” que deberá ser habilitada previamente en los “templates” y en el archivo “Views.py” ya que por defecto se encuentra eliminada por seguridad, una vez realizado esto tendrá a disposición una interfaz similar a la que se muestra a continuación:

166

Anexo AB. Panel de administración Django


Ingrese con el “superusuario” que acabó de crear, a través de esta herramienta tendrá acceso a diversas herramientas de administración que le permitirán transformar la configuración de Django.

1.4.6 Estructura de construcción de interfaces gráficas

Las interfaces gráficas se construyen teniendo en cuenta una estructura lógica teniendo en cuenta si el módulo es noAccesible o Accesible, la estructura general de las interfaces del módulo noAccesible es la siguiente:

167

Anexo AC. Estructura general de interfaces en módulo no Accesible


En las interfaces presentes en el módulo noAccesible podemos encontrar esta estructura, en naranja podemos identificar la cabecera o área de navegación la cual al estar presente en todas las interfaces se maneja como código reutilizable y se coloca de forma aislada en “layout.html”, resaltado en verde se encuentra el contenido de la página en donde se pueden encontrar variedad de elementos como textos, imágenes, videos, formularios, tablas o sliders, por último en fucsia se encuentra resaltado el botón accesible el cual nos permite la redirección hacía la versión en el módulo Accesible de la misma página.

Por su parte la estructura general de las interfaces presentes en el módulo accesible es la siguiente:

168

Anexo AD. Estructura general de interfaces en módulo Accesible


En las interfaces presentes en el módulo Accesible podemos encontrar esta estructura, en naranja podemos identificar la cabecera o área de navegación la cual al estar presente en todas las interfaces se maneja como código reutilizable y se coloca de forma aislada en “alayout.html” de forma similar al módulo noAccesible, resaltado en verde se encuentra el contenido de la página en donde se pueden encontrar variedad de elementos como textos, imágenes, videos, formularios, tablas o sliders, por último en fucsia se encuentra resaltado el botón accesible el cual nospermite la redirección hacía la versión en el módulo noAccesible de la misma página.

Cabe resaltar que en este módulo las fuentes que se utilizan son significativamente más grandes, se tiene en cuenta el contraste entre el color de la fuente y el fondo en todo momento además de estar presente los elementos de narración con los que no cuenta el módulo noAccesible.

Un elemento de la estructura que se comparte en ambos módulos es el footer que al cumplir con los valores mínimos de contraste que recomiendan las pautas se conservó sin cambios tal como se muestra a continuación:

169

Anexo AE. Footer unificado en ambos módulos


1.4.7 Descripción de redes Docker internas

El prototipo utiliza dos redes de Docker internas “frontend” y “docker-intranet”, las cuales corresponden en este orden para soportar operaciones de frontend y backend, la conexión que mantienen con los contenedores se muestra a continuación:

170

Anexo AF. Estructura de redes en Docker


Se decidió construir esta arquitectura para mantener aislado el funcionamiento de los contenedores que funcionan como backend, dejando solo el contenedor “web_container” como el contenedor con el que interactuaran los usuarios comunes, por parte de los administradores pueden acceder adicionalmente por el puerto 8080 al contenedor pg_admin.

Estos son algunos aspectos técnicos relevantes de estas redes:

Ambas redes utilizan el driver “bridge”, sin embargo, dada la robustes que debe adquirir “docker-intranet” se le asigna la subred IPv4 192.168.1.0 con máscara 24, siendo su Gateway la dirección 192.168.1.1, para el caso de IPv6 se le asigna la subred 2001:3984:3989:: con máscara 24 siendo entonces su Gateway la dirección 2001:3984:3989::1.

171

1.4.8 Descripción de entry-points para persistencia

Los entry-points también conocidos como puntos de anclaje juegan un rol importante en este prototipo ya que permiten realizar persistencia de datos, almacenando estos en un espacio fijo en el disco duro, lo cual contribuye evitar la pérdida de datos y demás información almacenada cuando los contenedores son apagados. En la construcción de este prototipo su configuración se realiza dentro del archivo docker-compose en la totalidad de contenedores, a continuación, se muestra la configuración de estos volúmenes en el archivo docker-compose.yaml.

Anexo AG. Configuración de entry-points en contenedores


Es necesario también añadir al final del archivo docker-compose.yaml la dependencia que indicara los volúmenes a utilizar en términos generales, como se muestra a continuación:

172

Anexo AH. Configuración de volúmenes


1.4.9 Diccionario de datos

Para contribuir a la mantenibilidad de la base de datos, se procede a describir de forma técnica la composición de la misma, para ello se decide construir el siguiente diccionario de datos, el cual contiene información sobre todos los atributos y tablas construidas en la base de datos a partir del modelo entidad-relación. Se describen los atributos nombre, valor por defecto, nulidad, tipo de dato y longitud de dato:

173

Anexo AI. Diccionario de datos


1.4.10 Recomendaciones finales de desarrollo y mantenimiento

Como recomendaciones finales para tener en cuenta para el desarrollo y mantenimiento futuro es el uso de herramientas que potencialmente pueden facilitar y acelerar el desarrollo, la primera herramienta que damos como recomendación es el editor de texto Visual Studio Code debido a su gran capacidad de integración con una gran cantidad de lenguajes de programación además de también lograr integrarse con Docker al contar con las extensiones adecuadas.

La última herramienta que puede ser de utilidad es el IDE Pycharm el cual trabaja de forma nativa con Python y resulta bastante útil a la hora de trabajar con Django,

174

aunque algunas de sus funciones no están disponibles de forma gratuita como el soporte completo en Django, las funciones básicas generan un gran aporte que puede ser aprovechado en desarrollos futuros.

Anexo AJ. Herramientas recomendadas


1.5 SCRIPTS DE CASOS DE PRUEBA

A continuación, se refiere un enlace donde se puede consultar en detalle los cuatro scripts de prueba desarrollados para validar el prototipo ya que por su extensión no fueron detallados a profundidad en la documentación:

• https://1drv.ms/u/s!Ar25OxFm-TjophRmgz81AOGWtnOV?e=HR4Wvr

https://1drv.ms/u/s!Ar25OxFm-TjophRmgz81AOGWtnOV?e=HR4Wvr

PROTOTIPO DE SERVICIO WEB ACCESIBLE QUE FUNCIONE SIN ...

Documents

Transcript of PROTOTIPO DE SERVICIO WEB ACCESIBLE QUE FUNCIONE SIN ...