UNIVERSIDAD NACIONAL DEL CALLAO FACULTAD DE INGENIERÍA INDUSTRIAL Y DE SISTEMAS ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS IMPLEMENTACIÓN DE UNA PLATAFORMA WEB PARA LA CONSERVACIÓN DE LA LENGUA QUECHUA TESIS PARA OPTAR EL TÍTULO PROFESIONAL DE INGENIERO DE SISTEMAS Autor: BACHILLER MELGAREJO VERGARA, NELSI BELLY Callao, Diciembre, 2017 PERÚ DEDICATORIA Con mucho cariño a mis padres por ser el pilar fundamental en todo lo que soy y he logrado gracias a su incondicional apoyo. Todo este trabajo ha sido posible gracias a ellos. AGRADECIMIENTO A mis padres por estar siempre a mi lado incondicionalmente, y a mi asesora Mg. Sally Torres Alvarado por su apoyo. ÍNDICE RESUMEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 INTRODUCCIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 I PLANTEAMIENTO DE LA INVESTIGACIÓN 11 1.1 Identificación del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2 fórmulación del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.2.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.2.2 Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.3 Objetivos de la investigación . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.3.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.3.2 Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.4 Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.4.1 Por su impacto tecnológico . . . . . . . . . . . . . . . . . . . . . . . . 13 1.4.2 Por su impacto social . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.4.3 Por su impacto ambiental . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.4.4 Por su impacto económico . . . . . . . . . . . . . . . . . . . . . . . . 14 1.4.5 Por su impacto cultural . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.5 Importancia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 II MARCO TEÓRICO 16 2.1 Antecedentes de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2 Marco conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2.1 El idioma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2.2 La lengua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2.3 El dialecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2.4 El Quechua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2.5 Página web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2.6 Página Web 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2.7 Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.2.8 RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 1 2.2.9 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2.10 Plataformas de Repositorios . . . . . . . . . . . . . . . . . . . . . . . 31 III VARIABLES E HIPÓTESIS 34 3.1 Variables de la investigación . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.1.1 Variable dependiente . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.1.2 Variable independiente . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.2 Operacionalización de variables . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.3 Hipótesis de la investigación . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.3.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.3.2 Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 IV METODOLOGÍA 36 4.1 Tipo de investigación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.2 Diseño de la investigación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3 Población y muestra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.4 Técnicas e instrumentos de recolección de datos . . . . . . . . . . . . . . . . . 39 4.4.1 Técnicas de muestreo . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.4.2 Recopilación de datos . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.4.3 Procesamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.5 Procedimientos de recolección de datos . . . . . . . . . . . . . . . . . . . . . 40 4.6 Procesamiento estadístico y análisis de datos . . . . . . . . . . . . . . . . . . . 40 V RESULTADOS 42 5.1 Desarrollo del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.1.1 Fase de Inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.1.2 Fase de Elaboración . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.1.3 Fase de construcción . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.1.4 Fase de transición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.2 Repositorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.2.1 Uso de repositorios . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 VI DISCUSIÓN DE RESULTADOS 94 6.1 Constratación de hipótesis con los resultados . . . . . . . . . . . . . . . . . . 94 6.2 Contrastación de resultados con otros estudios similares . . . . . . . . . . . . . 95 VII CONCLUSIONES 97 7.1 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 VIII RECOMENDACIONES 99 8.1 Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 2 REFERENCIAS 101 Anexos 102 A Matriz de consistencia 103 3 Índice de tablas 3.1 OPERACIONALIZACIÓN DE LAS VARIABLES DE ESTUDIO . . . . . . . 35 4.1 CANTIDAD DE QUECHUAHABLANTES DE LA VARIEDAD CHANKA Y COLLAO DEL PERÚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.2 DATOS PARA EL CÁLCULO DE LA MUESTRA . . . . . . . . . . . . . . . 39 5.1 REQUERIMIENTOS NO FUNCIONALES . . . . . . . . . . . . . . . . . . . 50 5.2 REQUERIMIENTOS FUNCIONALES . . . . . . . . . . . . . . . . . . . . . 52 5.3 REQUERIMIENTOS NO FUNCIONALES . . . . . . . . . . . . . . . . . . . 54 5.4 VALIDAR CUENTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.5 RECUPERAR CONTRASEÑA . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.6 LOGIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.7 GRABAR AUDIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.8 TRANSCRIBIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.9 VER ARCHIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.10 DESCARGAR ARCHIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.11 INFRAESTRUCTURA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.12 DISEÑO FRONT-END . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.13 ORGANIZACIÓN Y CONTROL DEL CONTENIDO . . . . . . . . . . . . . 85 5.14 CONTENT DISCOVERY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.15 HERRAMIENTAS DE PUBLICACIÓN . . . . . . . . . . . . . . . . . . . . . 89 5.16 INFORMES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.17 MULTIMEDIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.18 FUNCIONES Y NOTIFICACIONES SOCIALES . . . . . . . . . . . . . . . . 91 5.19 INTEROPERABILIDAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.20 AUTENTICACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.21 ACCESIBILIDAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.22 PRESERVACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 6.1 VALIDACIÓN DE DATOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 4 Índice de figuras 5.1 DIAGRAMA DE CASOS DE USO DEL NEGOCIO . . . . . . . . . . . . . . 44 5.2 GRABAR AUDIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.3 TRANSCRIBIR AUDIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.4 SUBIR ARCHIVO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.5 BUSCAR ARCHIVO Y DESCARGAR ARCHIVO . . . . . . . . . . . . . . . 48 5.6 DIAGRAMA DE CASO DE USO GENERAL . . . . . . . . . . . . . . . . . 53 5.7 ANÁLISIS DE LA ARQUITECTURA DEL SISTEMA . . . . . . . . . . . . . 62 5.8 DIAGRAMA DE CLASES DEL ANÁLISIS CREAR CUENTA . . . . . . . . 63 5.9 DIAGRAMA DE CLASES DEL ANÁLISIS VALIDAR CUENTA . . . . . . . 63 5.10 DIAGRAMA DE CLASES DEL ANÁLISIS RECUPERAR CONTRASEÑA . 64 5.11 DIAGRAMA DE CLASES DEL ANÁLISIS LOGIN . . . . . . . . . . . . . . 64 5.12 DIAGRAMA DE CLASES DEL ANÁLISIS GRABAR AUDIO . . . . . . . . 65 5.13 DIAGRAMA DE CLASES DEL ANÁLISIS TRANSCRIBIR . . . . . . . . . 65 5.14 DIAGRAMA DE CLASES DEL ANÁLISIS SUBIR ARCHIVOS . . . . . . . 66 5.15 DIAGRAMA DE CLASES DEL ANÁLISIS BUSCAR Y DESCARGAR . . . 67 5.16 DOMINIO DE CLASES ENTIDAD . . . . . . . . . . . . . . . . . . . . . . . 68 5.17 DISEÑO DE LA ARQUITECTURA . . . . . . . . . . . . . . . . . . . . . . . 70 5.18 MODELO CONCEPTUAL DE DATOS . . . . . . . . . . . . . . . . . . . . . 71 5.19 MODELO LÓGICO DE DATOS . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.20 MODELO FÍSICO DE DATOS . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.21 DIAGRAMA DE COMPONENTES . . . . . . . . . . . . . . . . . . . . . . . 74 5.22 DIAGRAMA DE DESPLIEGUE . . . . . . . . . . . . . . . . . . . . . . . . . 75 5.23 SERVICIO WEB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 5.24 BASE DE DATOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 5.25 LOGIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.26 GRABACIÓN DE VOZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.27 FORMULARIO DE REGISTRO DE CUENTA . . . . . . . . . . . . . . . . . 80 5.28 CORREO DE CONFIRMACIÓN DE CUENTA . . . . . . . . . . . . . . . . . 81 5.29 FORMULARIO DE RECUPERACIÓN DE CUENTA . . . . . . . . . . . . . 81 5.30 FORMULARIO DE LOGIN . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5 5.31 GRABACIÓN DE VOZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.32 BUSCAR ARCHIVO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 6 RESUMEN En el Censo Nacional de Población y Vivienda de 1940, dieron como resultados que 7 millones de peruanos hablaban quechua, las cuales dos de cada tres peruanos hacían uso de la lengua quechua. Según el censo del año 2007 realizado por el Instituto Nacional de Estadísticas e Informática, 3.3 millones de peruanos hablan el quechua, siendo así que uno de cada nueve pe- ruanos puede hablar el lenguaje quechua Los datos mostrados hacen referencia a la disminución de quechua hablantes en el Perú, esta realidad muestra que hay una tendencia a la disminución con los años, esto se debe a diversos factores, tales como las distintas reformas políticas y a aspectos económicos demográficos. En los últimos años, los distintos gobiernos han realizado reformas políticas para mantener el uso de la lengua quechua, debido a que está en peligro de extinción, por esa razón se debe poner como prioridad la preservación de la lengua quechua en el territorio peruano. El objetivo principal de la investigación es conservar el uso de la lengua quechua en el Perú a través de una plataforma web. El primer objetivo de este trabajo de investigación se logró a través de la construcción de una plataforma web y el repositorio Dspace la cual nos ayudará a almacenar información sobre la lengua Quechua. Palabras claves: Quechua, Plataforma web, Dspace, Repositorio 7 ABSTRACT In the 1940 National Population and Housing Census, it was found that 7 million Peruvians spoke Quechua, which two out of every three Peruvians used the Quechua language. According to the 2007 census carried out by the National Institute of Statistics and Informatics, 3.3 million Peruvians speak Quechua, while one in nine Peruvians can speak the Quechua language. The data shown refer to the decrease of Quechua speakers in the Quechua language. Peru, this reality shows that there is a tendency to decrease over the years, this is due to various factors, such as the different political reforms and demographic economic aspects. In recent years, different governments have made political reforms to maintain the use of the Quechua language, because it is in danger of extinction, for that reason the preservation of the Quechua language in the Peruvian territory should be a priority. The main objective of the research is to preserve the use of the Quechua language in Peru through a web platform. The first objective of this research work was achieved through the construction of a web platform and the Dspace repository which will help us store information about the Quechua language. Keywords: Quechua, Web Platform, Dspace, Repository 8 INTRODUCCIÓN La cultura y la lengua van de la mano, una cultura se transmite a través de la lengua, es así que una la lengua no solo sirve para comunicarnos sino también para poder recepcionar y seguir transmitiendo la cultura de nuestros antepasados a las siguientes generaciones. En la actualidad aún existen aproximadamente 6,000 lenguas en el mundo, muchas de estas en vías de extinción debido a la poca documentación, a la falta de nuevos materiales y reformas en políticas lingüísticas[GRAAF et al., 2003]. La extinción de muchas lenguas tiene distintas causas de las cuales, Según Michael Krauss el 90% de las lenguas desaparecerían en este siglo, también algunos lingüistas indican que se perderá el 50% de las lenguas en el mundo de las 6,000 que existen actualmente. En América Latina se habla 420 lenguas, se calcula que el 10% de la población es indígena. Un 26% de las lenguas indígenas América Latina se encuentran en peligro de extinción. El quechua es hablada en siete países: Argentina, Bolivia, Brasil, Colombia, Chile, Ecuador y Perú[INFANCIA, 2009], siendo el Perú el país de la región con mayor cantidad de habitantes de habla quechua[INFANCIA and BILIGUIE, 2009]. 9 En el Perú 3’360,331 personas hablan el quechua (Censo 2007) siendo la segunda lengua más hablada, en Lima Metropolitana 6.7% de la población (520,440) tiene como lengua materna una lengua andina1. 1https://www.inei.gob.pe/ 10 Capítulo I PLANTEAMIENTO DE LA INVESTIGACIÓN 1.1 Identificación del problema En el Censo Nacional de Población y Vivienda de 1940, dieron como resultados que 7 millones de peruanos hablaban quechua, las cuales dos de cada tres peruanos hacían uso de la lengua quechua[CASTILLO et al., 2008]. Según el censo del año 2007 realizado por el Instituto Na- cional de Estadísticas e Informática1, 3.3 millones de peruanos hablan el quechua, siendo así que uno de cada nueve peruanos puede hablar el lenguaje quechua[CASTILLO et al., 2008]. Los datos mostrados hacen referencia a la disminución de quechua hablantes en el Perú, está realidad muestra que hay una tendencia a la disminución con los años, esto se debe a diver- sos factores, tales como las distintas reformas políticas[PATRICIA et al., 2013] y a aspectos económicos demográficos[AGUILAR, 2015]. 1INEI - https://www.inei.gob.pe/ 11 En los últimos años, los distintos gobiernos han realizado reformas políticas para mantener el uso de la lengua quechua[CAVERO, 2013], debido a que esta en peligro de extinción, por esa razón se debe poner como prioridad la preservación de la lengua quechua en el territorio peruano. 1.2 fórmulación del problema 1.2.1 General ¿Se podrá con la implementación de una plataforma web conservar archivos multimedia de la lengua Quechua? 1.2.2 Específicos a) ¿Se podrá integrar una página web, herramientas de recolección y un repositorio institu- cional para almacenar la mayor cantidad de datos sobre el quechua? b) ¿Se podrá almacenar el mayor contenido referente a la lengua quechua en una repositorio institucional? 1.3 Objetivos de la investigación 1.3.1 General Conservar el uso de la lengua quechua en el Perú a través de una plataforma web. 12 1.3.2 Específicos a) Analizar y diseñar la integración de una plataforma web para la conservación de contenido referente al quechua. b) Implementar un repositorio institucional que almacene contenido referente a la lengua quechua. 1.4 Justificación El presente proyecto de investigación, se justifica en función de los siguientes argumentos: 1.4.1 Por su impacto tecnológico Permitirá crear un grupo de trabajo debidamente capacitado para profundizar en la mejora de la plataforma, así como en la búsqueda de mejores forma de tener acceso a todo un idioma. 1.4.2 Por su impacto social Los resultados de dicho proyecto generarán una base sobre cual es posible construir diversas aplicaciones para que el idioma quechua en el caso más favorable quede fuera de peligro de extinción. 1.4.3 Por su impacto ambiental Existe un vínculo entre el lenguaje y el conocimiento tradicional en relación con la biodiversi- dad. Las comunidades han elaborado complejos sistemas de clasificación para el mundo nat- ural, la cual se refleja en nombres indígenas y tradiciones orales que podrían perderse cuando 13 se desplacen a otro idioma, por tal motivo la proliferación de la lengua quechua cumple un rol importante en el impacto ambiental. 1.4.4 Por su impacto económico La plataforma no solo brindará información sobre el idioma quechua, sino se propone integrar todo tipo de medio de comunicación (escribo, visual y audiovisual) de habla quechua para aumentar la difusión de la misma. 1.4.5 Por su impacto cultural La tecnología une el mundo de muchas maneras, la plataforma albergará el corpus de la lengua quechua de manera que las diferentes generaciones tendrán acceso a la información y así preser- var por muchas generaciones. El gran contenido de información sobre el quechua será transmitida de forma rápida a través de Internet, por ello tendrán mayor cobertura las distintas culturas andinas de habla quechua. 1.5 Importancia Una lengua conlleva el significado de una cultura, y todo lo referente a su historia, por tal mo- tivo, todas las lenguas en el mundo son importantes y deben prevalecer a lo largo del tiempo. La lengua quechua que contiene todo la riqueza cultural del imperio inca, siendo una de las más importantes culturas en América del sur, se encuentra en vía de extinción, y por tal motivo debemos frenarlo. 14 El prevalecer la lengua quechua tiene una gran importancia ya que tiene un impacto social enorme en la cultura actual peruana y en algunos países que tienen pobladores quechua hablantes, ya que si se extinguiera se perdería la historia, la cultura, la ciencia, etc; generada por esta her- mosa lengua. 15 Capítulo II MARCO TEÓRICO 2.1 Antecedentes de estudio EL 2002 fue presentado en la Universidad de Texas en Austin, Estados Unidos, el artículo The Archive of the Indigenous Languages of Latin America: Goals and Visions por Johnson, Heidi and Dwyer y Arienne[Johnson and Dwyer, 2002]. El artículo presenta una visión general de los objetivos y las visiones del Archivo de los Id- iomas Indígenas de América Latina en la Universidad de Texas en Austin. El archivo es un repositorio digital de recursos de idiomas multimedia con una interfaz basada en web. Cuyo objetivo principal del archivo es preservar las grabaciones del discurso natural en lenguas en peligro, también están comprometemos a servir a usuarios apoyando actividades que buscan mejorar la comprensión y la apreciación de estos idiomas, y promover su supervivencia. En agosto del 2015 fue presentado en Ciencias de la Información del Instituto de Información 16 Científica y Tecnológica La Habana, Cuba, el artículo Diseño e implementación de un Sis- tema Integral para la Gestión de Archivos de la Universidad Autónoma de San Luis Potosí (México) por Luis Rivera, Julio Rivera, Isnardo Reducindo y Miguel Olvera[RIVERA et al., 2015]. El artículo presenta la experiencia de la Escuela de Ciencias de la Información de la Universi- dad Autónoma de San Luis Potosí, México, en el tema de desarrollo de sistemas de informa- ción, al describir la estructura, diseño e implementación del Sistema Integral para la Gestión de Archivos. Dicho sistema representa una herramienta de apoyo en actividades de gestión de información como las labores de tratamiento, búsqueda, almacenamiento y recuperación de información dentro de las organizaciones públicas. La primera versión del sistema desarrol- lado fue puesta en marcha para sistematizar el Archivo del H. Congreso del Estado de San Luis Potosí, con resultados satisfactorios. La experiencia de este trabajo representa un punto de partida hacia la generación de proyectos integrales en materia de archivos en México. Esta investigación ayudó a conocer la arquitectura que debe llevar un sistema para la gestión de la información[RIVERA et al., 2015]. También se consultó el trabajo presentado en junio del 2001 en Virtual Educa Madrid, España, el artículo Generador Inteligente de Documentos de Formación por Guillermo Barrutieta Anduiza[ANDUIZA, 2001]. El artículo se enmarca en la generación automática e inteligente de documentos que se adapten a las necesidades de los usuarios. El prototipo que se presentó cuenta como fuente para la gen- eración de un corpus etiquetado en XML donde las etiquetas o metadatos explicitan la estructura del discurso de acuerdo con la teoría de análisis del discurso propuesta por W. C. Mann y S. 17 A. Thompson denominada RST. Esta investigación ayudó a comprender la tecnología a utilizar para la creación de un sistema inteligente y la teoría de análisis que presenta[ANDUIZA, 2001]. También se consultó el trabajo presentado en 2011 la Oficina Ejecutiva de Información y Documentación Científica. Oficina General de Información y Sistemas. Instituto Nacional de Salud. Lima, Perú, el artículo Propuesta de Desarrollo de una Plataforma de Gestión del Conocimiento en Salud Pública: Dengue y virus del Ébola por Silvia Huaillani, Edgar Oré, Graciela Rengifo[HUAILLANI et al., 2011]. El presente artículo se desarrolló en el marco de las plataformas virtuales para la gestión del conocimiento. En particular, se presenta una propuesta de requerimiento, diseño e imple- mentación de dos plataformas de gestión del conocimiento en salud pública: Dengue y virus del Ébola para el Instituto Nacional de Salud de Lima-Perú. La implementación de las platafor- mas de gestión del conocimiento en salud pública permitirá gestionar, compartir y transferir conocimientos explícitos a fin de que los investigadores, a través de un solo portal, accedan a información científica y de literatura gris local, regional e internacional y puedan disponer de la mejor evidencia para el sustento de sus investigaciones y toma de decisiones. Esta investigación ayudó a comprender la arquitectura para el diseño del sistema de gestión del conocimiento.[HUAILLANI et al., 2011]. En diciembre del 2014, la Universidad Tecnológica de Peréira publicó el artículo Implementación de SCRUM en el diseño del Proyecto del Trabajo Final de Aplicación por Sonia Mariño, Pe- dro Alfonzo[MARIÑO and ALFONZO, 2014]. 18 En esta investigación presentó un marco de trabajo basado en las prácticas de SCRUM, apli- cado para gestionar el diseño de las distintas versiones del proyecto del Trabajo Final de Apli- cación, documento que explicita un producto tecnológico a desarrollar para la titulación de grado. En la propuesta se aplica SCRUM desde la concepción de la idea, en el proceso de elaboración del proyecto y finalizando con su presentación para su aprobación formal. Esta investigación ayudó a comprender cómo se utiliza la metodología SCRUM en un producto tecnológico[MARIÑO and ALFONZO, 2014]. 2.2 Marco conceptual En este capítulo se muestra los conceptos necesarios y el desarrollo de ellos para poder abordar el tema de investigación tratado. 2.2.1 El idioma Es el lenguaje propio de un grupo humano. Suele aplicarse esta denominación a los hablados por una nación, especialmente a los modernos, o al esperanto o cualquier otro pretendido «idioma universal». El término idioma alterna con el de lengua, referido a las lenguas vivas, es decir, a las lenguas nacionales modernas. «El término ‘idioma’ equivale a lengua y, en ocasiones, a lenguaje. Se emplea con mayor frecuencia al hablar de las lenguas extranjeras, como en el enunciado 1.» 1http://www.hispanoteca.eu/ 19 2.2.2 La lengua Sistema de signos orales que utiliza una comunidad para expresarse. «Debemos entender por lengua el sistema lingüístico organizado en estructura funcional propia y peculiar, sistema que sirve de instrumento de expresión y de comunicación directa entre los individuos de una co- munidad lingüística. Precisando el concepto, conviene observar que puede no darse exacta coincidencia entre comunidad lingüística y comunidad político-social y que el dominio geográ- fico de una lengua no coincida con la extensión territorial dominada por un poder político o nación. De hecho, esa falta de acomodación es lo más común. Por ello, de las necesidades político-administrativas brota el concepto de idioma o lengua oficial de una nación o país2. 2.2.3 El dialecto Los dialectos son las variantes o modalidades regionales de una lengua. Tales variantes no afectan a la unidad del sistema3. 2.2.4 El Quechua La palabra quechua proviene del término Inca, (qheswa) que significa “el hablar del valle”. Representa el cuarto dialecto más hablado en América, el cual fue utilizado durante el Imperio inca, realizándose durante el siglo XV, permitiéndose extenderse desde el sur de Colombia hasta el norte de argentina. La lengua quechua es procedente de los andes centrales con prolonga- ciones por toda Sudamérica, el número de personas que hablan este dialecto está estimado entre los ocho a diez millones. Este dialecto presenta una morfología cohesiva, con raíces regulares y una colección amplia de sufijos provechosos que posibilitan la creación de nuevas palabras de 2http://www.hispanoteca.eu/ 3http://www.hispanoteca.eu/ 20 forma natural4. 2.2.5 Página web Una Página Web es un documento electrónico que forma parte de la WWW (World Wide Web) generalmente construido en el lenguaje HTML (Hyper Text Markup Language o Lenguaje de Marcado de Hipertexto) o en XHTML (Extensible Hyper Text Markup Language o Lenguaje de Marcado de Hipertexto Extensible). Este documento puede contener enlaces (característica del hypertext) que nos direcciona a otra Página Web cuando se efectúa el clic sobre él. Para visualizar una Página Web es necesario el uso de un Browser o navegador. Una Página Web puede estar alojada en un ordenador local o en un ordenador remoto. Al servidor donde esté alojada la Página Web se le denomina Servidor Web. El Servidor Web atiende las peticiones de Páginas Web utilizando el protocolo HTTP (HyperText Transfer Pro- tocol); del lado del cliente es el Browser o navegador el que recibe y muestra las Páginas Web utilizando el mismo protocolo. Otra característica importante es que una Página Web puede ser estática (su contenido siempre es el mismo) o dinámica (su contenido se construye a partir de la información introducida por el usuario). Elementos de una página web En una página web puede contener textos, imágenes, vídeos, audios, gif, hipervínculos (enlaces a otras páginas), meta tags (palabras claves incluidas en el HTML para ser encontrada), CSS (Cascading Styles Sheets) estilos para controlar aspecto de la web. 4http://conceptodefinicion.de/quechua// 21 2.2.6 Página Web 2.0 Lo que se denomina Web 2.0 hace referencia a todo un conjunto de aplicaciones que han surgido en los últimos años de la Web que han conseguido que sea mucho más fácil que cualquiera pueda ser a la vez consumidor y generador de contenidos web. Esto es así porque esas aplicaciones son normalmente gratuitas y muy fáciles de utilizar (nor- malmente fórmularios), lo que permite que todos seamos capaces de publicar en la web con- tenidos en formatos varios con sólo disponer de acceso a la red. Como bien dice Aníbal de la Torre "Internet ha pasado de ser un espacio de lectura a ser de lectura-escritura". Una característica destacable de las aplicaciones de la Web 2.0 es que permiten la recuperación de la información mediante la asignación de etiquetas (tags) y el acceso a la información de forma sistemática mediante la suscripción por RSS (lo que se denomina sindicación). Todas estas aplicaciones se interconectan de múltiples formas, o bien sirven para varias cosas, o bien se gestionan desde una misma cuenta, etc. Pero, para aclararnos, este conjunto de apli- caciones las podemos clasificar en 5 subconjuntos: • Aplicaciones que permiten generar contenidos (muchas veces online) en distintos for- matos: audio, vídeo, presentaciones, páginas web, documentos, etc • Aplicaciones que permiten editar, publicar, compartir y/o almacenar contenidos (ej. Blogs, Wikis, Google pages, Google docs, Flicker, YouTube, etc.). • Aplicaciones que permiten compartir y recuperar información: marcadores sociales (ej. Delicious, Meneame, etc.). 22 • Aplicaciones que permiten la participación en redes sociales (ej. Myspace, Facebook, SecondLife, etc.). • Aplicaciones que permiten el mantenimiento de espacios privados personales con una gestión ágil y directamente desde la web (ej. Gmail, Yahoo, etc.). 2.2.7 Web Service El término Web Services describe una forma estandarizada de integrar aplicaciones WEB medi- ante el uso de XML, SOAP, WSDL y UDDI sobre los protocolos de la Internet. XML es usado para describir los datos, SOAP se ocupa para la transferencia de los datos, WSDL se emplea para describir los servicios disponibles y UDDI se ocupa para conocer cuáles son los servicios disponibles. Uno de los usos principales es permitir la comunicación entre las empresas y entre las empresas y sus clientes. Los Web Services permiten a las organizaciones intercambiar datos sin necesidad de conocer los detalles de sus respectivos Sistemas de Información. A diferencia de los modelos Cliente/Servidor, tales como un servidor de páginas Web, los Web Services no proveen al usuario una interfaz gráfica (GUI). En vez de ello, los Web Services comparten la lógica del negocio, los datos y los procesos, por medio de una interfaz de progra- mas a través de la red. Es decir conectan programas, por tanto son programas que no interactúan directamente con los usuarios. Los desarrolladores pueden por consiguiente agregar a los Web Services la interfaz para usuarios, por ejemplo mediante una página Web o un programa eje- cutable, tal de entregarle a los usuarios un funcionalidad específica que provee un determinado Web Service. Los Web Services permiten a distintas aplicaciones, de diferentes orígenes, comunicarse en- 23 tre ellos sin necesidad de escribir programas costosos, esto porque la comunicación se hace con XML. Los Web Services no están ligados a ningún Sistema Operativo o Lenguaje de Progra- mación. Por ejemplo, un programa escrito en Java puede conversar con otro escrito en Pearl; Aplicaciones Windows puede conversar con aplicaciones Unix. Por otra parte los Web Services no necesitan usar browsers (Explorer) ni el lenguaje de especificación HTML. El modelo de computación distribuida de los Web Services permite la comunicación de apli- cación a aplicación. Por ejemplo, la aplicación que procesa las órdenes de compra se puede comunicar con el sistema de inventarios, tal que este último le puede informar a la aplicación de compras cuáles ítems deben comprarse por estar bajo su nivel mínimo. Dado el nivel in- tegración que proveen para las aplicaciones, Los Web Services han crecido en popularidad y han comenzado a mejorar los procesos de negocios. De hecho, algunos postulan que los Web Services están generando la próxima evolución de la Web. • Tecnología Web Services: Los Web Services están construidos con varias tecnologías que trabajan conjuntamente con los estándares que están emergiendo para asegurar la se- guridad y operatividad, de modo de hacer realidad que el uso combinado de varios Web Services, independiente de la o las empresas que los proveen, este garantizado. A contin- uación se describen brevemente los estándares que están ocupando los Web Services. • XML: Abreviación de Extensible Markup Language. El XML es una especificación de- sarrollada .Permite a los desarrolladores crear sus propios tags, que les permiten habilitar definiciones, transmisiones, validaciones, e interpretación de los datos entre aplicaciones y entre organizaciones. • SOAP: Abreviación de Simple Object Access Protocol, es un protocolo de mensajería 24 construido en XML que se usa para codificar información de los requerimientos de los Web Services y para responder los mensajes antes de enviarlos por la red. Los mensajes SOAP son independientes de los sistemas operativos y pueden ser transportados por los protocolos que funcionan en la Internet, como ser: SMTP, MIME y HTTP. • WSDL: Abreviación de Web Services Description Language, es un lenguaje especificado en XML que se ocupa para definir los Web Service como colecciones de punto de co- municación capaces de intercambiar mensajes. El WSDL es parte integral de UDDI y parte del registro global de XML, en otras palabras es un estándar de uso público (no se requiere pagar licencias ni royalties para usarlo). • UDDI: Abreviación de Universal Description, Discovery and Integration. Es un directorio distribuido que opera en la Web que permite a las empresas publicar sus Web Services, para que otras empresas conozcan y utilicen los Web Services que publican, opera de manera análoga a las páginas amarillas. 2.2.8 RUP El Proceso Unificado Racional, Rational Unified Process en inglés, y sus siglas RUP, es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, con- stituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino que trata de un conjunto de metodologías adaptables al contexto y necesidades de cada organización, donde el software es organizado como una colección de unidades atómicas lla- mados objetos, constituidos por datos y funciones, que interactúan entre sí. 25 RUP es un proceso para el desarrollo de un proyecto de un software que define claramente quien, cómo, cuándo y qué debe hacerse en el proyecto. Fases de desarrollo del software a) Fase de inicio Se hace un plan de fases, donde se identifican los principales casos de uso y se identifi- can los riesgos. Se concreta la idea, la visión del producto, como se enmarca en el negocio, el alcance del proyecto. El objetivo en esta etapa es determinar la visión del proyecto. • Modelo de negocio: En esta fase el equipo se familiarizará más al funcionamiento de la empresa, sobre conocer sus procesos. • Requisitos: En esta línea los requisitos son el contrato que se debe cumplir, de modo que los usuarios finales tienen que comprender y aceptar los requisitos que especifique- mos. b) Fase de elaboración Se realiza el plan de proyecto, donde se completan los casos de uso y se mitigan los riesgos. Planificar las actividades necesarias y los recursos requeridos, especificando las caracterís- ticas y el diseño de la arquitectura. En esta etapa el objetivo es determinar la arquitectura Óptima. • Análisis y Diseño: En esta actividad se especifican los requerimientos y se describen sobre cómo se van a implementar en el sistema. 26 c) Fase de construcción Se basa en la elaboración de un producto totalmente operativo y en la elaboración del man- ual de usuario. Construir el producto, la arquitectura y los planes, hasta que el producto está listo para ser enviado a la comunidad de usuarios. En esta etapa el objetivo es llevar a obtener la capacidad operacional inicial. • Implementación: Se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y demás. El resultado final es un sistema ejecutable. • Pruebas: Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos desarrollando, pero no para aceptar o rechazar el producto al final del proceso de desarrollo, sino que debe ir integrado en todo el ciclo de vida. d) Etapa de transición El objetivo es llegar a obtener el Release del proyecto. Se realiza la instalación del pro- ducto en el cliente y se procede al entrenamiento de los usuarios. Realizar la transición del producto a los usuarios, lo cual incluye: manufactura, envío, entrenamiento, soporte y man- tenimiento del producto, hasta que el cliente quede satisfecho, por tanto en esta fase suelen ocurrir cambios. • Despliegue: Esta actividad tiene como objetivo producir con éxito distribuciones del producto y distribuirlo a los usuarios. 27 2.2.9 UML UML significa "Unified Modeling Language": Lenguaje de Modelado o Modelamiento Unifi- cado. El Lenguaje de Modelado Unificado es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos a un sistema de software bajo desarrollo, así como para modelado de negocios y otros sistemas no software. Puede ser utilizado con cualquier metodología, a lo largo del proceso de desarrollo de soft- ware, en cualquier plataforma tecnológica de implementación (Unix, Windows etc.). Es un sistema notacional (que, entre otras cosas, incluye el significado de sus notaciones) des- tinado a los sistemas de modelado que utilizan conceptos orientados a objetos. Características de UML • UML es una especificación de notación orientada a objetos. Se basa en las anteriores especificaciones BOOCH, RUMBAUGH y COAD-YOURDON. Divide cada proyecto en un número de diagramas que representan las diferentes vistas del proyecto. Estos diagramas juntos son los que representa la arquitectura del proyecto. • UML permite describir un sistema en diferentes niveles de abstracción, simplificando la complejidad sin perder información, para que tanto usuarios, líderes y desarrolladores puedan comprender claramente las características de la aplicación. • UML se quiere convertir en un lenguaje estándar con el que sea posible modelar todos los componentes del proceso de desarrollo de aplicaciones. Sin embargo, hay que tener en cuenta un aspecto importante del modelo: no pretende definir un modelo estándar de 28 desarrollo, sino únicamente un lenguaje de modelado. Otros métodos de modelaje como OMT (Object Modeling Technique) o Booch sí definen procesos concretos. En UML los procesos de desarrollo son diferentes según los distintos dominios de trabajo; no puede ser el mismo el proceso para crear una aplicación en tiempo real, que el proceso de desarrollo de una aplicación orientada a gestión, por poner un ejemplo. • El método del UML recomienda utilizar los procesos que otras metodologías tienen definidos. Diagramas UML En todos los ámbitos de la ingeniería se construyen modelos, en realidad, simplificaciones de la realidad, para comprender mejor el sistema que vamos a desarrollar: los arquitectos utilizan y construyen planos (modelos) de los edificios,los grandes diseñadores de coches preparan mod- elos en sistemas CAD/CAM con todos los detalles y los ingenieros de software deberían igual- mente construir modelos de los sistemas software. • Diagrama de Casos de Uso: Modela la funcionalidad del sistema agrupándola en descrip- ciones de acciones ejecutadas por un sistema para obtener un resultado. Se utiliza para entender el uso del sistema .Muestra el conjunto de casos de uso y actores (un actor puede ser tanto un sistema como una persona) y sus relaciones: es decir, muestra quien puede hacer qué y las relaciones que existen entre acciones (casos de uso). Son muy importantes para modelar y organizar el comportamiento del sistema. • Diagrama de Clases: Muestra las clases (descripciones de objetos que comparten carac- terísticas comunes) que componen el sistema y cómo se relacionan entre sí. 29 • Diagrama de Objetos: Muestra una serie de objetos (instancias de las clases) y sus rela- ciones. A diferencia de los diagramas anteriores, estos diagramas se enfocan en la per- spectiva de casos reales o prototipos. Es un diagrama de instancias de las clases mostradas en el diagrama de clases. • Diagrama de Secuencia: Enfatiza la interacción entre los objetos y los mensajes que intercambian entre sí junto con el orden temporal de los mismos. • Diagrama de Colaboración: Muestra la interacción entre los objetos resaltando la organi- zación estructural de los objetos en lugar del orden de los mensajes intercambiados. El diagrama de secuencia y el diagrama de colaboración: muestran a los diferentes objetos y las relaciones que pueden tener entre ellos, los mensajes que se envían entre ellos. Son dos diagramas diferentes, que se puede pasar de uno a otro sin pérdida de información, pero que nos dan puntos de vista diferentes del sistema. En resumen, cualquiera de los dos es un Diagrama de Interacción. • Diagrama de Estados: Se utiliza para analizar los cambios de estado de los objetos. Mues- tra los estados, eventos, transiciones y actividades de los diferentes objetos. Son útiles en sistemas que reaccionen a eventos. • Diagrama de Actividades:Es un caso especial del diagrama de estados, simplifica el dia- grama de estados modelando el comportamiento mediante flujos de actividades. Muestra el flujo entre los objetos. Se utilizan para modelar el funcionamiento del sistema y el flujo de control entre objetos. • Diagrama de Componentes: Muestra la organización y las dependencias entre un conjunto de componentes. Se usan para agrupar clases en componentes o módulos. 30 • Diagrama de Despliegue o implementación: Muestra los dispositivos que se encuentran en un sistema y su distribución en el mismo. Se utiliza para identificar Sistemas de Coop- eración: Durante el proceso de desarrollo el equipo averiguará de qué sistemas dependerá el nuevo sistema y que otros sistemas dependerán de él. 2.2.10 Plataformas de Repositorios Una plataforma de repositorio es una aplicación diseñado para capturar, almacenar, ordenar, conservar y redistribuir la información digital en diferentes formatos, actualmente organiza- ciones e instituciones a nivel mundial lo usan. Plataformas de software de Repositorios: Existen plataformas de software de repositorios de propiedad y de software gratuito de código abierto siendo en su mayoría de código abierto, estas plataformas son desarrollados por Univer- sidades y/o en conjunto con instituciones, a continuación hacemos mención a algunas: • Archiment • Bepress • CDSware • CONTENTdm • Digital common • Dspace 31 • EPrints • Fedora • Grenstone • Isadora • Open Repository Dspace DSpace es el software de código abierto, sin fines de lucro y comerciales que crean repositorios digitales abiertos y completamente personalizable para adaptarse a las necesidades de cualquier organización. DSpace conserva y permite el acceso fácil y abierto a todo tipo de contenido digital, incluyendo texto, imágenes, imágenes en movimiento, mpegs, audios, vídeos y conjuntos de datos. Y con una comunidad cada vez mayor de desarrolladores, comprometidos con la expansión y mejora continua del software, cada instalación de DSpace se beneficia de la siguiente.5 a) Acceso online a sus activos digitales La presentación online de su contenido en un árbol organizada de la comunidad y de las colecciones es una característica principal de DSpace. Los usuarios pueden acceder a las páginas de los elementos individuales, estos son descripciones de metadatos junto con los archivos disponibles para descargar. 5http://www.dspace.org/introducing 32 • Búsqueda de texto completo DSpace puede procesar contenido basado texto cargado para la búsqueda de texto com- pleto. Esto significa que no sólo los metadatos que usted proporcione para un archivo determinado podrá buscarse, pero todos sus contenidos serán indexados. Esto permite a los usuarios buscar palabras clave específicas que sólo aparecen en el contenido real y no en la descripción. • Navigation DSpace A los usuarios a encontrar su camino a contenido relevante en un número de man- eras, incluyendo: la búsqueda de una o más palabras clave en los metadatos o ex- trae texto completo navegación facetada por cualquier campo proporcionado en la de- scripción del artículo. La búsqueda es un componente esencial del descubrimiento en DSpace. Los usuarios’ expectativas de un motor de búsqueda es bastante alto, por lo que una meta para DSpace es suministrar tantas funciones de búsqueda como sea posible. DSpace’s de indexación y búsqueda de módulo tiene una API muy simple que permite indexar contenido nuevo, regenerando el índice Y realizar búsquedas en todo el cuerpo, de una comunidad o colección. Detrás de la API Java freeware motor de búsqueda. Lucene nos envió la búsqueda, detener la extracción de word, derivado, y Lucene la capacidad para agregar gradualmente nuevo contenido indizado sin re- generar todo el índice. Los índices de búsqueda Lucene específicos son configurables que permitan a las instituciones para personalizar qué campos de metadatos DSpace están indexados. 33 Capítulo III VARIABLES E HIPÓTESIS 3.1 Variables de la investigación 3.1.1 Variable dependiente La variable dependiente es la conservación del uso de la lengua Quechua 3.1.2 Variable independiente La variable independiente refiere a la implementación de una plataforma web 34 3.2 Operacionalización de variables TABLA 3.1: OPERACIONALIZACIÓN DE LAS VARIABLES DE ESTUDIO Variable Dimensión Indicador VI: Implementación de una plataforma web Plataforma web -Lenguaje de programación -Estándares de programación -Gestión del conocimiento - Repositorio VD: Conservación de archivos multi- media referente a la lengua quechua Archivos multi- media (audio y texto) -Cantidad de visitas -Cantidad de audios -Cantidad de transcripciones 3.3 Hipótesis de la investigación 3.3.1 General Mediante la implementación de una plataforma web se logrará conservar archivos multimedia referente a la lengua quechua. 3.3.2 Específicos a) Mediante la integración de una página web, herramientas de recolección y un repositorio institucional se logrará almacenar la mayor cantidad de archivos multimedia. b) Mediante la implementación de un repositorio institucional se logrará almacenar archivos multimedia de la lengua quechua. 35 Capítulo IV METODOLOGÍA 4.1 Tipo de investigación El tipo de investigación de esta tesis de acuerdo con su orientación, es aplicada porque se aplicará un conocimiento ya existente para solucionar un problema práctico, de acuerdo con su contrastación es cuasi experimental debido a que no se tiene un control efectivo de las variables de selección al no poder asignar aleatoriamente a los participantes para los estudios. 4.2 Diseño de la investigación Para el desarrollo de este proyecto se realizó las siguientes etapas: a) Definición de los objetivos de la plataforma web Se comenzará haciendo preguntas concretas a las que debía dar respuesta la plataforma web. Es importante indicar solamente cuestiones fundamentales ya que tratar de abordar prob- lemas colaterales puede complicar innecesariamente la plataforma web. Posteriormente se 36 elaboró un pequeño esquema con el tipo de conclusiones que se esperaba obtener en el pos- terior análisis de datos. Finalmente, la lista de objetivos se fue puliendo a medida que se iban ejecutando las etapas del diseño de la plataforma. b) Identificación de las posibles fuentes de variación Se hizo una lista de las posibles fuentes de variación del problema, distinguiendo aquellas que, a priori, podían generar una mayor variabilidad, distinguiendo dos tipos: • Factores de tratamiento: cuyo efecto es de particular interés para la elaboración de la plataforma web. • Factores “nuisance”: que aunque no son de interés directo, se contemplan en el diseño para reducir la variabilidad no planificada c) Especificación de las medidas a realizar (la “respuesta”) y el procedimiento Se establecieron las Variables respuestas o variables de interés y se recogieron los datos necesarios para cuantificar dichas variables, que naturalmente, están condicionadas por los objetivos de la elaboración de la plataforma web. d) Diseño y Ejecución de la plataforma web Se diseñará una plataforma web, la cual se realizará con las mejores tecnologías actuales y se pondrá puesta en marcha de la plataforma web para el lenguaje Quechua basado en estándares de programación. e) Revisiones y Posibles modificaciones Finalmente, se realizarán los distintos cambios tras la revisión del modelo adoptado y de los problemas detectados en la marcha a producción. 37 4.3 Población y muestra La población lo conforman las personas quechuahablantes de la variedad chanca y collado del sur del Perú. TABLA 4.1: CANTIDAD DE QUECHUAHABLANTES DE LA VARIEDAD CHANKA Y COLLAO DEL PERÚ Variedad de quechua Valor Chanka 850 000 Collao 1 115 000 Total de quechuahablantes 1 961 500 A continuación se muestra la fórmula utilizada para calcular la cantidad de la muestra. n = N ∗ Z2 a ∗ p ∗ q d2 ∗ (N − 1) + Z2 a ∗ p ∗ q (4.1) Donde: N = Total de la población Z = Nivel de confianza p = Probabilidad de éxito q = Probabilidad de fracaso d = Precisión Los datos para calcular la muestra son los siguientes: 38 TABLA 4.2: DATOS PARA EL CÁLCULO DE LA MUESTRA Descripción Valor Total de población 1 961 500 Nivel de confianza 1.96 Probabilidad de éxito 0.85 Probabilidad de fracaso 0.15 Precisión 0.15 El valor de la muestra obtenida utilizando la fórmula 4.1 es 206182. 4.4 Técnicas e instrumentos de recolección de datos Se utilizarán diferentes técnicas estadísticas para cuantificar las variables en todo el proceso de investigación de la tesis. 4.4.1 Técnicas de muestreo • Estadística 4.4.2 Recopilación de datos • Revisión de visitas a la plataforma web • Revisión de aporte a la plataforma web 4.4.3 Procesamiento • Estadística descriptiva • Estadística inferencial 39 4.5 Procedimientos de recolección de datos La plataforma web tendrá un contador de visitas, la cual contará la cantidad de personas que ingresaron a la web, así mismo, tendrá un contador por aportación de la página web, ya sea subiendo información o descargando información que solo se podrá realizar teniendo una cuenta en el intranet de la plataforma web. 4.6 Procesamiento estadístico y análisis de datos Se procederán a contar la cantidad de visitas a la plataforma web ya sea por cualquier de sus vistas informativas, asi como al ingreso del intranet, con el fin de obtener los indicadores de- seados para este estudio. El conteo de ingreso a la plataforma web nos brinda la información de la cantidad de per- sonas que presentan algún interés o desean informarse sobre la lengua quechua. El conteo de ingreso a la intranet nos brinda la información de la cantidad de personas que se involucran de forma directa con el desarrollo y el cultivo de la lengua quechua. El índice de personas que se involucran de forma directa con las personas que solo desean informarse mostrará el impacto que tiene la plataforma web al cultivo de la lengua quechua, ya que si el total de personas que ingresan al intranet se acerca a la cantidad de personas que ingresan a la plataforma web demostraría que la plataforma web tiene un gran impacto en el desarrollo de la lengua quechua. 40 Indicador de influencia de la plataforma web El indicador de influencia de la plataforma web se medirá de la siguiente forma: I = CA CV (4.2) Donde I = indicador de influencia, CA = cantidad de aportantes y CI = cantidad de visitantes. 41 Capítulo V RESULTADOS En el presente capítulo vamos a mostrar la solución propuesta para evitar la extinción de la lengua Quechua mediante una plataforma web. 5.1 Desarrollo del sistema El sistema se desarrolló usando RUP (Rational Unified Process) como metodología de de- sarrollo de software y UML (Lenguaje Unificado de Modelado) como herramienta de Mod- elamiento. 5.1.1 Fase de Inicio a) Modelamiento de negocio Se realizó dentro de la primera fase de la metodología RUP - Fase de Inicio, la cual requirió el conocimiento preciso de lo que actualmente se hace en los procesos que serán considera- dos en el nuevo sistema. 42 Las herramientas que se utilizaron en esta etapa son: diagrama de caso de uso de negocios y flujo gramas. • Modelo de casos de uso del negocio En esta sección se determinó a los actores de negocio, cada uno de los procesos identi- ficados puede ser un casos de uso del negocio. Para desarrollar el diagrama de casos de uso del negocio se estudió los estereotipos de casos de uso y el de Actor del negocio. – Diagrama de casos de uso del negocio El diagrama de casos de uso del negocio contempla dos escenarios y cinco actores externos al negocio 43 FIGURA 5.1: DIAGRAMA DE CASOS DE USO DEL NEGOCIO – Diagrama de actividad de los procesos de negocio ∗ Grabar audio 44 FIGURA 5.2: GRABAR AUDIO ∗ Transcribir audio 45 FIGURA 5.3: TRANSCRIBIR AUDIO ∗ Subir archivo 46 FIGURA 5.4: SUBIR ARCHIVO ∗ Buscar archivo y Descargar archivo 47 FIGURA 5.5: BUSCAR ARCHIVO Y DESCARGAR ARCHIVO 48 b) Modelamiento de Requerimientos En el modelado de requerimientos se describe los requerimientos funcionales y no fun- cionales los cuales nos brindan las condiciones o capacidades que debe cumplir el sistema. • Identificación de requerimientos funcionales y no funcionales – Requerimiento no funcionales Los requerimientos que se describe nos brindarán las características que debe cumplir el sistema propuesto. 49 TABLA 5.1: REQUERIMIENTOS NO FUNCIONALES Tipo Descripción Desempeño -Garantizar el desempeño del sistema a todos los usuarios. La información almacenada podrá ser consultada y actual- izada permanente y simultáneamente, sin que se afecte el tiempo de respuesta. -El sistema debe estar en capacidad de dar respuesta al ac- ceso de los usuarios y a los procesos con tiempo de re- spuesta aceptable y uniforme. Disponibilidad -El sistema estará disponible las 24 horas al Día Escalabilidad -El sistema debe ser construido sobre la base de un desar- rollo evolutivo e incremental, de manera tal que nuevas fun- cionalidades y requerimientos relacionados puedan ser in- corporados afectando el código existente de la menor man- era posible; para ello deben incorporarse aspectos de reuti- lización de componentes. -El sistema debe estar en capacidad de permitir en el futuro el desarrollo de nuevas funcionalidades, modificar o elimi- nar funcionalidades después de su construcción y puesta en marcha inicial. Facilidad de Uso e Ingreso de In- formación -El sistema debe ser de fácil uso por parte de los usuarios. -El sistema no debe permitir el cierre de una operación hasta que todos sus procesos, subprocesos y tareas relacionados, hayan sido terminados y cerrados satisfactoriamente. -El sistema debe presentar mensajes de error que permitan al usuario identificar el tipo de error y comunicarse con el administrador del sistema. Facilidad para las Pruebas -El sistema debe contar con facilidades para la identifi- cación de la localización de los errores durante la etapa de pruebas y de operación posterior. Flexibilidad -El sistema debe ser diseñado y construido con los mayores niveles de flexibilidad en cuanto a la parametrización de los tipos de datos. Mantenibilidad -Todo el sistema deberá estar completamente documentado, cada uno de los componentes de software que forman parte de la solución propuesta deberán estar debidamente docu- mentados tanto en el código fuente como en los manuales de administración y de usuario. -El sistema debe estar en capacidad de permitir en el futuro su fácil mantenimiento con respecto a los posibles errores que se puedan presentar. 50 Tipo Descripción Seguridad -El acceso al Sistema debe estar restringido por el uso de claves asignadas a cada uno de los usuarios. Sólo podrán ingresar al Sistema las personas que estén registradas, es- tos usuarios serán clasificados en varios tipos de usuarios (o roles) con acceso a las opciones de trabajo definidas para cada rol. -El control de acceso implementado debe permitir asignar los perfiles para cada uno de los roles identificados. -Respecto a la confidencialidad, el sistema debe estar en capacidad de rechazar accesos o modificaciones indebidos (no autorizados) a la información y proveer los servicios re- queridos por los usuarios legítimos del sistema. -El sistema deberá contar con mecanismos que permitan el registro de actividades con identificación de los usuarios que los realizaron. -El sistema debe contar con pistas de auditoría de las ac- tividades que se realizan sobre el sistema con niveles razon- ables para su reconstrucción e identificación de los hechos. Validación de In- formación -El sistema debe validar automáticamente la información contenida en los fórmularios de ingreso. En el proceso de validación de la información, se deben tener en cuenta as- pectos tales como obligatoriedad de campos, longitud de caracteres permitida por campo, manejo de tipos de datos, etc. – Requerimiento funcionales 51 TABLA 5.2: REQUERIMIENTOS FUNCIONALES ID Requerimientos Descripción Prioridad REQ-01 Crear cuenta Permite al usuario registrarse, con la cual podrá acceder a los archivos para reproducir, descargar, grabar, transcribir entre otras. alta REQ-02 Validar Cuenta Permite al usuario verificar su reg- istro alta REQ-03 Recuperar con- traseña Permite al usuario recuperar su con- traseña alta REQ-04 Login Permite al usuario iniciar sesión en el portal alta REQ-05 Buscar archivos Permite al usuario ver archivos en diferentes formatos y reproducir alta REQ-06 Grabar audio Permite al usuario grabar audio alta REQ-07 transcripción de audios el usuario podrá realizar transcrip- ción del audio alta REQ-08 Descargar archivo Permite al usuario descargar los diferentes archivos almacenados alta • Diagrama de caso de uso del sistema En este punto se documentará el comportamiento del sistema desde el punto de vista del usuario los cuales son los requerimientos funcionales del sistema. – Diagrama de caso de uso general 52 FIGURA 5.6: DIAGRAMA DE CASO DE USO GENERAL • Especificaciones de casos de uso del sistema Se detalla ordenadamente todos los casos de usos del sistema partiendo de la premisa que ya se identificaron los actores y que estén claramente definidos todos los flujos tanto básicos como alternos. – Crear Cuenta 53 TABLA 5.3: REQUERIMIENTOS NO FUNCIONALES Caso de Uso Crear Cuenta Descripción El proceso para registrar un nuevo usuario se realizará desde siminchikkunarayku. Actores Usuarios, colaboradores, administradores Flujo Básico El proceso para registrar un nuevo usuario se realizará desde siminchikkunarayku ingresando a través del botón “Regís- trate”. Una vez presionado el botón nos mostrará una ven- tana emergente la cual nos solicitará completar una serie de campos para registrar al usuario. (a) El sistema requiere que el actor introduzca los sigu- ientes campos Los campos marcados con (*) son obli- gatorios: nombre (*), apellidos (*), email (*), teléfono, país (*), región(*), contraseña (*) y que acepte los Tér- minos y condiciones. (b) Una vez ingresado los campos se aceptará los términos y condiciones y a su vez le permitirá decidir si desea recibir información sobre eventos y novedades. Contraseña(contendrá 8 caracteres como mínimo) (a) El sistema valida los datos ingresados y verifica que el usuario no exista en la base de datos. (b) El sistema registra al usuario en la base de datos y Una vez registrado se le envía por email una confirmación al usuario para que luego sea activado su cuenta. Flujos Alterna- tivos 1 Datos inválidos Sí, en el Flujo Básico, el usuario introduce algunos cam- pos inválidos, el sistema muestra un mensaje de error. El usuario puede elegir entre volver al principio, o cancelar el registro. Flujos Alterna- tivos 2 Existe un usuario registrado en la base de datos Sí, ya existe un usuario asociado a la cuenta, el sis- tema muestra el mensaje "La cuenta ya fue asociada a un usuario". El actor puede elegir entre volver al principio, o cancelar el registro. 54 Caso de Uso Crear Cuenta Precondiciones Ninguno Post-condiciones Si el caso de uso se ha realizado correctamente, ahora el usuario recibirá un correo electrónico. Puntos de Ex- tensión De haber realizado correctamente el registro, el usuario tiene que revisar su correo electrónico para activar su cuenta. – Validar Cuenta TABLA 5.4: VALIDAR CUENTA Caso de Uso Validar Cuenta Descripción Permite al usuario activar su cuenta Actores Usuarios Flujo Básico El proceso para activar la cuenta del usuario inicia cuando accede a su correo electrónico en donde hará clic en el link que se le envió, el usuario accede al link. (a) El sistema verifica que el código de verificación exista y procede a cambiar de estado a activo la usuario. Flujos Alterna- tivos 1 códigos de activación no existen Sí, en el Flujo Básico, no existe el código de activación, el sistema redirige al usuario a la página de inicio del portal. Flujos Alterna- tivos 2 códigos de activación no existen Sí, en el Flujo Básico, no existe el código de activación, el sistema redirige al usuario a la página de inicio del portal. Precondiciones El usuario debe estar registrado en el sistema antes de que inicie el caso de uso y tener su código de verificación. Post-condiciones De haber realizado correctamente la activación, ahora el usuario tiene que revisar su correo electrónico para ver que su cuenta se haya creado correctamente Puntos de Ex- tensión Ninguno – Recuperar Contraseña 55 TABLA 5.5: RECUPERAR CONTRASEÑA Caso de Uso Recuperar Contraseña Descripción Permite al usuario poder obtener otra contraseña, en el caso que se le haya olvidado. Actores Usuarios, administradores Flujo Básico El proceso para que el usuario recupere su contraseña comienza. Dando clic al botón “Ingresar”, y el usuario debe darle clic al link “¿ Has olvidado tu contraseña?". (a) El sistema le muestrará otra ventana emergente en donde el actor tendrá que ingresar su correo electrónico (User). (b) El usuario ingresará su correo electrónico y dará clic al botón “enviar”. (c) El sistema creará un código de reseteo para cambiar la contraseña al usuario y procede a enviar un correo elec- trónico con el código de reseteo. (d) El sistema muestra el mensaje "Se le envió un email, revise su correo para seguir con el proceso de cambio de contraseña”. (e) El usuario se dirigirá a su correo electrónico y le dará clic al link enviado con el código de reseteo. (f) El sistema validará el código de reseteo y le mostrará una ventana emergente en el cual podrá ingresar su nueva contraseña. (g) El usuario ingresará su nueva contraseña y le dará clic al botón enviar. (h) El sistema validará si la contraseña cumple con los 8 caracteres como mínimo. (i) El sistema mostrará un mensaje “su contraseña fue cambiada correctamente” Flujos Alterna- tivos 1 códigos de reseteo no existente Sí, en el Flujo Básico, no existe el código de activación, el sistema muestra un mensaje de error. Precondiciones El usuario debe estar registrado en el sistema antes de que inicie el caso de uso y tener su código de reseteo. Post-condiciones De haberse realizado correctamente, ahora el usuario puede iniciar sesión con su nueva contraseña. Puntos de Ex- tensión Ninguno 56 – Login TABLA 5.6: LOGIN Caso de Uso Login Descripción Este caso le permite al usuario iniciar sesión. Actores Usuarios, Siminchikkunarayku Flujo Básico El proceso para acceder a la cuenta del usuario se re- alizará desde Siminchikkunarayku ingresando a través del botón “corpus” o “repositorio”. Al presionar el botón le mostrará una ventana emergente la cual solicitará los datos de “usuario” y “password” del usuario. (a) El sistema valida el nombre y contraseña proporciona- dos, los datos ingresados serán validados y si los datos existen el sistema inicia la sesión del usuario en el sis- tema. Flujos Alterna- tivos 1 Usuario y/o Contraseña Inválidos Sí, en el Flujo Básico, el usuario introduce un usuario y/o contraseña inválido, el sistema muestra un mensaje de error. El usuario puede elegir entre volver al principio del Flujo Básico, o cancelar la autentificación, momento en que el caso de uso termina. Flujo Alterna- tivo 2 La cuenta no existe en el sistema Sí, en el Flujo Básico, no existe la cuenta en la base de datos, el sistema muestra el mensaje "Ha ocurrido un in- conveniente. No se encuentra registrado". Precondiciones El usuario debe estar registrado en el sistema antes de que inicie el caso de uso. Post-condiciones Si el caso de uso se ha realizado correctamente, ahora el usuario ha iniciado sesión en el sistema. Sí no es así, el estado del sistema no se modificaSi el caso de uso se ha realizado correctamente, ahora el actor ha iniciado sesión en el sistema. Sí no es así, el estado del sistema no se modifica Puntos de Ex- tensión Ninguno 57 – Grabar Audio TABLA 5.7: GRABAR AUDIO Caso de Uso Grabar Audio Descripción Este caso le permite al usuario grabar audio. Actores Usuarios, Siminchikkunarayku Flujo Básico El proceso para que el usuario pueda grabar audio inicia desde Siminchikkunarayku ingresando a través del botón “corpus”. Al presionar el botón mostrará una ventana la cual solicitará los datos de “usuario” y “password” del usuario. (a) En esta vista el usuario dará clic al botón “Grabar Voz”. (b) En sistema muestra una lista de instrucciones para poder realizar la correcta grabación como se muestra a continuación. ∗ Lea el texto marcado en verde. Si tiene dudas de la pronunciación, antes de grabar escuche la locución, para eso pulse el botón . ubicado inmediatamente de- bajo del texto. ∗ Para iniciar pulse el botón GRABAR y para terminar pulse el botón FINALIZAR. ∗ Puede enviar 1 a 1 los audios, o en grupo. (c) Cuando el usuario desea salir, en el lado izquierdo se- lecciona "cerrar sesión". Flujos Alterna- tivos 1 Usuario no acepta las condiciones Sí, en el Flujo Básico, el usuario no acepta las condiciones no podrá realizar las grabaciones, por ende el caso de uso termina. Precondiciones El usuario debe estar registrado en el sistema antes de que inicie el caso de uso. Post-condiciones Ninguno Puntos de Ex- tensión Ninguno – Transcribir 58 TABLA 5.8: TRANSCRIBIR Caso de Uso Transcribir Descripción Este caso le permite al usuario transcribir audio. Actores Usuarios, Siminchikkunarayku Flujo Básico El proceso para que el usuario pueda grabar audio inicia desde Siminchikkunarayku ingresando a través del botón “corpus”. Al presionar el botón mostrará una ventana la cual solicitará los datos de “usuario” y “password” del usuario. (a) En esta vista el usuario dará clic al botón “Transcribir”. (b) En sistema muestra una lista de instrucciones para poder realizar la correcta grabación como se muestra a continuación. ∗ Lea el texto marcado en verde. Si tiene dudas de la pronunciación, antes de grabar escuche la locución, para eso pulse el botón . ubicado inmediatamente de- bajo del texto. ∗ Para iniciar pulse el botón GRABAR y para terminar pulse el botón FINALIZAR. ∗ Puede enviar 1 a 1 los audios, o en grupo. (c) Cuando el usuario desea salir, en el lado izquierdo se- lecciona "cerrar sesión". Flujos Alterna- tivos 1 Usuario no acepta las condiciones Sí, en el Flujo Básico, el usuario no acepta las condiciones no podrá realizar las grabaciones, por ende el caso de uso termina. Precondiciones El usuario debe estar registrado en el sistema antes de que inicie el caso de uso. Post-condiciones Ninguno Puntos de Ex- tensión Ninguno – Ver Archivos 59 TABLA 5.9: VER ARCHIVOS Caso de Uso Ver Archivos Descripción Este caso le permite al usuario ver todos los archivos sobre el Quechua como audios, textos, vídeos, etc. Actores Usuarios, Siminchikkunarayku Flujo Básico El proceso para ver los archivos inicia en la vista princi- pal de Siminchikkunarayku inicia haciendo clic el botón "repositorio". (a) El usuario ya dentro de la vista del repositorio del Quechua podrá visualizar y reproducir los archivos al- macenados. (b) el usuario da clic al nombre del archivo que desea visu- alizar el detalle. Flujos Alterna- tivos 1 Precondiciones Ninguno Post-condiciones Ninguno Puntos de Ex- tensión Ninguno – Descargar Archivos 60 TABLA 5.10: DESCARGAR ARCHIVOS Caso de Uso Descargar Archivos Descripción Este caso le permite al usuario buscar y descargar archivos almacenados. Actores Usuarios, Siminchikkunarayku Flujo Básico El proceso para descargar archivos inicia en la vista "repos- itorio". (a) El usuario busca archivo deseado. ∗ El sistema imprime los resultados. (b) El usuario da clic al nombre del archivo visualizar el detalle. (c) El sistema muestra datos detallados del archivo. (d) Usuario selecciona uno o varios archivos para descar- gar. (e) El archivo se descargará una vez seleccionado "Descar- gar" Flujos Alterna- tivos 1 Precondiciones El usuario debe estar registrado en el sistema y debe iniciar sesión para poder descargar archivos. Post-condiciones Ninguno Puntos de Ex- tensión Ninguno 5.1.2 Fase de Elaboración a) Análisis de sistemas En el análisis de sistemas se determinó los objetivos y límites del sistema, así como el análisis de la arquitectura del sistema y las directrices que permitan alcanzar los objetivos propuestos. • Análisis de la arquitectura del sistema 61 Se explica el análisis a alto nivel de la arquitectura de sistemas propuesto para el proyecto. FIGURA 5.7: ANÁLISIS DE LA ARQUITECTURA DEL SISTEMA • Análisis de casos de uso del sistema El Análisis de casos de uso del sistema ofrecerá una visión conceptual precisa y unifi- cada de alternativas para la implementación del sistema. Este modelo crece incremen- talmente conforme se analizan más casos de uso, de manera que el sistema se construye como una estructura de clases de análisis y relaciones entre dichas clases. – Diagrama de clases de análisis Para el sistema se muestran en el Diagrama de Clase de Análisis donde se encuen- tran las clases de análisis identificadas y se pueden observar las clases de interfaz respectivas. Las clases de control de cada interfaz interactúan con una o varias clases de entidad para ingresar o registrar los datos, o para solicitar alguna infor- mación determinada. ∗ Diagrama de clases del análisis Crear Cuenta 62 FIGURA 5.8: DIAGRAMA DE CLASES DEL ANÁLISIS CREAR CUENTA ∗ Diagrama de clases del análisis Validar Cuenta FIGURA 5.9: DIAGRAMA DE CLASES DEL ANÁLISIS VALIDAR CUENTA ∗ Diagrama de clases del análisis Recuperar Contraseña 63 FIGURA 5.10: DIAGRAMA DE CLASES DEL ANÁLISIS RECUPERAR CONTRASEÑA ∗ Diagrama de clases del análisis Login FIGURA 5.11: DIAGRAMA DE CLASES DEL ANÁLISIS LOGIN ∗ Diagrama de clases del análisis Grabar Audio 64 FIGURA 5.12: DIAGRAMA DE CLASES DEL ANÁLISIS GRABAR AUDIO ∗ Diagrama de clases del análisis Transcribir FIGURA 5.13: DIAGRAMA DE CLASES DEL ANÁLISIS TRANSCRIBIR ∗ Diagrama de clases del análisis subir archivos 65 FIGURA 5.14: DIAGRAMA DE CLASES DEL ANÁLISIS SUBIR ARCHIVOS ∗ Diagrama de clases del análisis Buscar y Descargar archivos 66 FIGURA 5.15: DIAGRAMA DE CLASES DEL ANÁLISIS BUSCAR Y DESCARGAR • Dominio de clases entidad 67 FIGURA 5.16: DOMINIO DE CLASES ENTIDAD b) Diseño de sistema En esta sección debe contar con una descripción detallada con el objetivo de cumplir con los requisitos descritos en el capítulo anterior y se debe establecer la estructura del software de toda la aplicación que se está diseñando, a través de la realización del modelo de diseño del sistema propuesto, el diseño de la base de datos, el diseño de la interfaz de usuario, representar las diferentes operaciones y actividades que realizará el sistema como las rela- ciones existentes entre ellas. El diseño deberá implementar todos los requisitos explícitos del modelado de análisis. • Diseño de la arquitectura 68 La arquitectura está orientada a entornos Web. Bajo este diseño las tareas se ejecutan por el lado del servidor, evitando delegar tales responsabilidades hacia las máquinas clientes desde los navegadores. Es así como el diseño debe garantizar un óptimo aprovechamiento de las capacidades propias de los sistemas Web satisfaciendo ade- cuadamente los requisitos no funcionales del producto. Entre las fortalezas exigidas a la arquitectura se encuentra que la arquitectura respetará el paradigma de programación orientado a objetos. Esta característica si bien depende del lenguaje de programación utilizado, la propuesta de diseño debe asegurar la manipulación de los datos y opera- ciones de manera encapsulada a través de clases y objetos interrelacionados entre sí por invocaciones a los métodos respectivos. El manejo de cambios en el producto se logra modificando las características de un número determinado de componentes sin com- prometer el funcionamiento del resto de módulos La arquitectura seleccionada para el sistema es una arquitectura basada en 3 capas con el patrón de arquitectura MVC (Modelo Vista Controlador) es un patrón que define la organización independiente del Modelo (Objetos de Negocio), la Vista (interfaz con el usuario u otro sistema) y el Controlador (controlador del workflow de la aplicación). 69 FIGURA 5.17: DISEÑO DE LA ARQUITECTURA • Modelado de datos – Modelo conceptual de datos 70 FIGURA 5.18: MODELO CONCEPTUAL DE DATOS – Modelo lógico de datos 71 FIGURA 5.19: MODELO LÓGICO DE DATOS – Modelo físico de datos 72 FIGURA 5.20: MODELO FÍSICO DE DATOS 5.1.3 Fase de construcción a) Implementación del sistema 73 • Diagrama de componentes FIGURA 5.21: DIAGRAMA DE COMPONENTES • Diagrama de despliegue 74 FIGURA 5.22: DIAGRAMA DE DESPLIEGUE • Codificación de requerimientos funcionales Se programó en python 3.7 utilizando Django framework,la cual es un un framework de código abierto para desarrollo aplicaciones web y servicios web con python. 75 FIGURA 5.23: SERVICIO WEB 76 FIGURA 5.24: BASE DE DATOS 77 FIGURA 5.25: LOGIN 78 FIGURA 5.26: GRABACIÓN DE VOZ 5.1.4 Fase de transición Esta fase contempla el traslado del sistema al servidor de aplicación y de base de datos y la verificación que el sistema este completo. a) Pruebas de sistema En esta fase de verifico cada uno de los casos de uso para ver su comportamiento en un entorno de producción • Modelo de casos de uso de pruebas del sistema – Crear cuenta 79 FIGURA 5.27: FORMULARIO DE REGISTRO DE CUENTA – Validar 80 FIGURA 5.28: CORREO DE CONFIRMACIÓN DE CUENTA – Recuperar contraseña FIGURA 5.29: FORMULARIO DE RECUPERACIÓN DE CUENTA 81 – Login FIGURA 5.30: FORMULARIO DE LOGIN – Modulo de grabación de voz FIGURA 5.31: GRABACIÓN DE VOZ 82 – Modulo de buscar archivo FIGURA 5.32: BUSCAR ARCHIVO 5.2 Repositorio 5.2.1 Uso de repositorios Actualmente diferentes instituciones, grupos de investigación usan diferentes plataformas de software de repositorios para poder almacenar información en diferentes formatos. Comparación de herramientas Se hará un estudio comparativo sobre algunas de estas infraestructuras para poder albergar y mostrar en toda su amplitud en los diferentes formatos como audios, vídeos, imágenes, textos, papers, y otros archivos sobre el Quechua. Para albergar el Quechua buscamos que el software de repositorio nos permita almacenar principalmente audio, texto y video para que las personas puedan interactuar con ellas. 83 Infraestrucctura En esta sección se ven las opciones de instalación, alojamiento y atención al cliente, las carac- terísticas fundamentales de las plataformas de repositorio. TABLA 5.11: INFRAESTRUCTURA Infraestructura Digital Commons DSpace EPrints Fedora Isadora Solución de Hosted Si Si Si Si Si Solución de insta- lación localmente de software - Si Si Si Si Atención al cliente/- soporte comunitario Atención al cliente: Email, celular, recursos y soporte co- munitario Soporte co- munitario Sopote co- munitario Soporte co- munitario Soporte co- munitario Estructura de reposi- torio flexible Si Limitado Si Limitado Si Simple and Qual- ified DublinCore Metadata Si Si Simple Dublin COre only Si Si Metadatos personal- izados Si Si Si Si Si Fuente abierta/ Propiedad Propietario Fuente abierta Fuente abierta Fuente abierta Fuente abierta Actualizaciones automáticas del sistema Si - - - - Versión de plataforma estable actual 7.6 3.2 3.3.11 3.6.2 6.x- 13.1.xand7.x- 1.1 Configuraciones de administrador Si Si Si Si Si Admite roles de usuario estándar Si Si Si Si Si 84 TABLA 5.12: DISEÑO FRONT-END Diseño Front-end Digital Commons DSpace EPrints Fedora Isadora Front-end integrado Si Si Si - Si servicio completo de diseño front-end Si - - - - Diseño de reposito- rio personalizable Si Si Si Si Si Diseño de publica- ciones personaliz- ables Si: Revistas y Conferen- cias - - - - Diseño optimizado para dispositivos móviles Si - - - Si Páginas web HTML5 Si - - - - TABLA 5.13: ORGANIZACIÓN Y CONTROL DEL CONTENIDO Organización y control del con- tenido Digital Commons DSpace EPrints Fedora Isadora Publicación de ac- ceso abierto Si Si Si Si Si Controles de acceso Si:Rango de IP, usuario y nombre de dominio Si: Rango de IP y usuario Si: Usuario y solicite una copia Si:XACML personaliz- able Si: Rango de IP, usuario y XACML personaliz- able Auto-lift Embargo Support Si Servicios adicionales disponibles Servicios adicionales disponibles - - Gestión de suscrip- ción de publicación Si - - - - Publicación Comu- nitaria Si Si Si Si Si Serie / Publicación de la Colección Si Si Si Si Si 85 Organización y control del con- tenido Digital Commons DSpace EPrints Fedora Isadora Publicación de la re- vista Si - - - - Publicación de ETD Si - - - - Publicación del libro Si - - - - Publicación de con- ferencia y evento Si - - - - Galería de imágenes Si - - - - Admite tipos de archivos estándar (PDF, MS Word, RTF, etc.) Si Si Si Si Si Organización flexi- ble de documentos Si - Si Si Si Metadatos personal- izables en páginas de artículos Si Si Si Si Si PDF Viewer en la página del artículo Si Servicios adicionales disponibles La vista pre- via de PDF coloca el cursor sobre el disponible Servicios adicionales disponibles Servicios adicionales disponibles Archivos suplemen- tarios / adicionales del artículo Si - Si - - Estampado person- alizado de la página de portada Si - - - - Licencia Creative Commons Si Si Si Servicios adicionales disponibles Servicios adicionales disponibles 86 TABLA 5.14: CONTENT DISCOVERY Content Discovery Digital Commons DSpace EPrints Fedora Isadora Motor de búsqueda integrado Si Si Si Si Búsqueda avanzada con facetas Si Si Si Si Si Indexación de búsqueda de texto completo Si Si Si Si Si Opciones de nave- gación disciplina, comunidad, publicación, año de pub- licación, tipo de docu- mento, autor e institución comunidades y colec- ciones, fecha de publi- cación, autor, tí- tulo, tema y tipo de documento departamento, tema, año colecciones y facetas de búsqueda colecciones y facetas de búsqueda Navegación gráfica de contenido Imagen, icono, geolocal- ización y navegación de rueda de disciplina Servicios adicionales disponibles Imagen - Imagen e Icono Herramientas de ge- olocalización Si: Inte- gración con google maps - Si: Ex- portación de Google Maps - Servicios adicionales disponibles Optimización de motores de búsqueda si Limitado Si - Servicios adicionales disponibles Indexado en Google Scholar Si Si Si - Servicios adicionales disponibles DOI y URLs persis- tentes Si: DOI y URL persis- tentes Si: Manejo de sistema Si: DOI sI: Identi- ficadores persistentes Si: Identi- ficadores persistentes 87 Content Discovery Digital Commons DSpace EPrints Fedora Isadora DOI y URLs persis- tentes Si: DOI y URL persis- tentes Si: Manejo de sistema Si: DOI sI: Identi- ficadores persistentes Si: Identi- ficadores persistentes Citation Export Si: Zotero, Endnote, and Ref- Works Si: Soporte de COINS BibTeX, refer, End- note, and additional bibliog- raphy managers Si: Soporte de COINS Si: Soporte de COINS Integración de Link Resolver Si Si Si Si Servicios adicionales disponibles 88 TABLA 5.15: HERRAMIENTAS DE PUBLICACIÓN Herramientas de publicación Digital Commons DSpace EPrints Fedora Isadora Herramientas in- tegradas de revisión por pares Si - - - - Permisos del editor de diario basado en roles Si - - - - Flujos de trabajo de publicación flexible Si Limitado Si Si Si fórmularios de envío personalizables Si Si Si Si Si Conversión au- tomática de archivos de texto completo a PDF Si Si - - - Conservar metadatos y re- visiones de texto completo Si - Si Si Si Importación de batch Si: Her- ramientas de im- portación XML y Microsoft Excel Si: Her- ramienta de im- portación bibliográ- fica y formato de archivo simple Si: Bib- TeX, XML y com- plementos adicionales disponibles Si: Im- portación XML Si Revisión de batch Si Si - - - Herramientas de recolección au- tomática Si - - - - 89 TABLA 5.16: INFORMES Informes Digital Commons DSpace EPrints Fedora Isadora Informes del editor Si Servicios adicionales disponibles Servicios adicionales disponibles Servicios adicionales disponibles Servicios adicionales disponibles Informes de uso / descarga Si Si Servicios adicionales disponibles Servicios adicionales disponibles Si Informes de los stakeholder Si - - Servicios adicionales disponibles - Informes de autor Si - - - Servicios adicionales disponibles Integración de Google Analytics Si Servicios adicionales disponibles Si - Si TABLA 5.17: MULTIMEDIA Multimedia Digital Commons DSpace EPrints Fedora Isadora Streaming Multime- dia Si Servicios adicionales disponibles - Servicios adicionales disponibles paquete de solución disponible Imágenes Si Si Si Si Si Presentaciones Si Servicios adicionales disponibles Si Servicios adicionales disponibles Si Audio Si Si Si Si paquete de solución disponible Video Si Si Si Si paquete de solución disponible 90 TABLA 5.18: FUNCIONES Y NOTIFICACIONES SOCIALES Funciones y notifi- caciones sociales Digital Commons DSpace EPrints Fedora Isadora Seguimiento Si - - - - Compartir Si Servicios adicionales disponibles Servicios adicionales disponibles Servicios adicionales disponibles Servicios adicionales disponibles RSS Si Si Si Si Si Bookmark Si - Si Servicios adicionales disponibles Si publicaciones y lista de correos de autores Si - - - - Comentarios del lec- tor Servicios adicionales disponibles - - - Si Búsquedas guardadas Si - Si - - TABLA 5.19: INTEROPERABILIDAD Interoperabilidad Digital Commons DSpace EPrints Fedora Isadora Harvesting (OAI- PMH) Si Si Si Si Si Red de repositorios de plataforma Si:Yes: Digital Commons Network - - - - Integration with Dis- covery Platforms Si Si Si Si Si Integración con páginas de perfil de investigación Si - - - Servicios adicionales disponibles 91 TABLA 5.20: AUTENTICACIÓN Autenticación Digital Commons DSpace EPrints Fedora Isadora LDAP Si Si Si Si Si CAS Si Si Si Si Si Cuentas del sistema Si Si Si Si Si Shibboleth - Si Si Si Si TABLA 5.21: ACCESIBILIDAD Accesibilidad Digital Commons DSpace EPrints Fedora Isadora VPAT Statement Si - Si - Section 508 Compli- ant Si - - - - WCAG (Pautas de accesibilidad al con- tenido web) Si - - - - 92 TABLA 5.22: PRESERVACIÓN Preservación Digital Commons DSpace EPrints Fedora Isadora Content Back Up Si: en- trega de contenido trimestral basada en XML Si: copia de seguridad de los paquetes de información de archivo Si: ex- portación de XML Si Si: ex- portación de XML LOCKSS- compliant Si Servicios adicionales disponibles - Servicios adicionales disponibles - Formato de herramientas y servicios de migración Si Las herramien- tas de riesgos de migración de formato in- tegrado ofrecen consejos de for- mato para los administradores Administrado por institu- ción Administrado por institu- ción Administrado por institu- ción Componentes de un sistema Repositorio Los componentes principales de un repositorio están compuestas por: • Interfaz para añadir contenido al sistema. • Interfaz para buscar contenido. • Base de datos para almacenar contenido. • Interfaz administrativa para apoyar la gestión de las colecciones y las actuaciones de conservación. • Integración con otros sistemas. 93 Capítulo VI DISCUSIÓN DE RESULTADOS En este capítulo se discute y analiza el resultado obtenido por la plataforma web. El resultado es evaluado en función a la cantidad de visitas y aportaciones de los usuarios en la plataforma web que llamamos Siminchikkunarayku. 6.1 Constratación de hipótesis con los resultados Se integró una página web, herramientas de recolección y un repositorio institucional la plataforma Para la validación del índice de influencia de la plataforma web, se usó como entradas el total de visitas realizadas, el total de los visitantes que aportaron (transcripciones, audios y vídeos) a continuación se muestra la tabla de resultado. TABLA 6.1: VALIDACIÓN DE DATOS Tipo de usuario Mes 1 Mes 2 Mes 3 Total Porcentaje Visitantes 50541 82452 200141 333134 90.7% Aportantes 5241 6109 23029 34794 9.3% Total 55782 88561 223170 367513 100% 94 En la tabla 6.1 se puede mostrar que el 90.7% de usuarios solo visitaron la plataforma web y el 9.3% de usuarios accedieron a la plataforma web y realizaron diferentes actividades, como subir archivos (audios, vídeos, papers, etc.) o descargar. El índice de influencia es de I = 9.3 la cual es un resultado óptimo de influencia de la plataforma web. 6.2 Contrastación de resultados con otros estudios similares El resultado de influencia obtenida a partir de la construcción de la plataforma web muestra que el 9.3% que visitaron la plataforma realizaron una contribución (subir audios, vídeos, pa- pers, etc). Los resultados obtenidos por Johnson y otros en el artículo The Archive of the Indigenous Languages of Latin America: Goals and Visions obtuvieron un gran impacto en la preservación de las lenguas nativas de América con la utilización de un repositorio que gestione de forma óptima distintos tipos de datos y que alcanza una influencia del 35% por contribuir con la mayor cantidad de lenguas nativas de América, también Luis Rivera y otros en el artículo Diseño e implementación de un Sistema Integral para la Gestión de Archivos de la Universidad Autónoma de San Luis Potosí obtuvieron una influencia de 12.1% con su plataforma de para la gestión de Archivos utilizando DSpace como repositorio. El trabajo presentado por Silvia Huaillani y otros en el artículo Propuesta de Desarrollo de una Plataforma de Gestión del Conocimiento en Salud Pública: Dengue y virus del Ébola obtuvo un 1.3% de influencia utilizando una plataforma de gestión de archivo pero con capaci- dad limitada o ajustada a sus actividades. 95 La propuesta de la construcción de una plataforma web que incluya un gestor de contenido como DSpace no solo resulta una opción viable sino que también tiene una mayor apertura a otro tipo de acciones (estadísticas, análisis de datos, etc) que incremente la influencia para obtener mayor cantidad de datos para la preservación de las lenguas nativas en América. 96 Capítulo VII CONCLUSIONES 7.1 Conclusiones a) En la actualidad, la documentación de idiomas se ha convertido en un campo de debate para los interdisciplinarios que involucran a los lingüistas de corpus junto con los desarrolladores de software. Este trabajo de tesis ha cumplido con los objetivos planteados, se integró una página web, herramientas de recolección y un repositorio institucional. La plataforma web Siminchikku- narayku que se encuendonde los usuarios pueden grabar sus voces utilizando la herramienta HUQARIQ, transcribir audio o acceder al repositorio QULLQA, así como mostrar infor- mación relevante relacionada al quechua, como radios, escritores, artistas, comunidades, eventos y noticias sobre quechua. b) QULLQA fue desarrollado usando el software Dspace donde nos permite almacenar y or- ganizar el corpus de las lenguas nativas, comenzando con el idioma quechua. Alberga SIM- INCHIK, 97 horas de lengua quechua espontánea y el correspondiente texto transcrito para 97 los dialectos Chanca y Collao de las regiones del sur del Perú. En quechua. c) La plataforma web para el almacenamiento de información de la lengua Quechua obtuvo un valor porcentual de 9.3% de índice de influencia. 98 Capítulo VIII RECOMENDACIONES 8.1 Recomendaciones a) Es posible aplicar este tipo de plataformas web para la recuperación de lenguas en vías de extinción. b) Es posible utilizar esta investigación para futuras investigaciones sobre repositorios para diferentes lenguas, especialmente para lenguas en vías de extinción. c) Se recomienda utilizar repositorios de código abierto como el Dspace para albergar difer- entes tipos de información, que además cuenta con una comunidad activa, ello implica que el software de repositorio se encuentra en constante actualización y mejora. d) Se recomienda alimentar el repositorio de la plataforma web con información relacionada del idioma Quechua, con el fin el de tener el mas grande repositorio sobre la lengua Quechua. 99 REFERENCIAS [AGUILAR, 2015] AGUILAR, A. S. (2015). Migraciones internas en el perú. Organización Internacional para las Migraciones. [ANDUIZA, 2001] ANDUIZA, G. B. (2001). Generador inteligente de documentos de forma- ción. Virtual Educa Madrid. [CASTILLO et al., 2008] CASTILLO, J. D., QUISPE, R., SÁNCHEZ, A., RAMÍREZ, R., and FLORES, G. M. (2008). Perú: Crecimiento y distribución de la población, 2007. Instituto Nacional de Estadística e Informática. [CAVERO, 2013] CAVERO, H. C. (2013). Proyecto de ley de aprendizaje obligatorio del quechua y el aymara en las universidades del país. Congreso de la República. [GRAAF et al., 2003] GRAAF, T. D., GRINEVALD, C., KRAUSS, M., MIYAOKA, O., OSTLER, N., SAKIYAMA, O., VILLALÓN, M. E., and YAMAMOTO, A. Y. (2003). Vi- talidad y peligro de desaparición de las lenguas. Organización de las Naciones Unidas para la Educación, la Ciencia y la Cultura. [HUAILLANI et al., 2011] HUAILLANI, S. D. R., ORÉ, E., and RENGIFO, G. (2011). Prop- uesta de desarrollo de una plataforma de gestión del conocimiento en salud pública: Dengue y virus del Ébola. Instituto Nacional de Salud. 100 [INFANCIA, 2009] INFANCIA, F. D. L. N. U. P. L. (2009). Datos rápidos de los pueblos indígenas en américa latina. Fondo de las Naciones Unidas para la Infancia. [INFANCIA and BILIGUIE, 2009] INFANCIA, F. D. L. N. U. P. L. and BILIGUIE, E. P. D. F. E. E. I. (2009). Atlas sociolingüístico de pueblos indígenas en américa latina. Fondo de las Naciones Unidas para la Infancia. [Johnson and Dwyer, 2002] Johnson, H. and Dwyer, A. (2002). Customizing the imdi meta- data schema for endangered languages. In Proceedings of The International Conference on Language Resources and Evaluation. [MARIÑO and ALFONZO, 2014] MARIÑO, S. and ALFONZO, P. (2014). Implementación de scrum en el diseño del proyecto del trabajo final de aplicación. Scientia et Technica. [PATRICIA et al., 2013] PATRICIA, E., VEGAS, J., BOLAÑOS, F., BURGA, E., GRÁNDEZ, M., MUJICA, R., SULLÓN, K., HUAMANCAYO, E., MORI, M., and CARBAJAL, V. (2013). Documento nacional de lenguas originarias del perú. Ministerio de Educación. [RIVERA et al., 2015] RIVERA, L., RIVERA, J., REDUCINDO, I., and OLVERA, M. (2015). Diseño e implementación de un sistema integral para la gestión de archivos de la universidad autónoma de san luis potosí (méxico). Ciencias de la Información. 101 Anexos 102 103 Anexos A Matriz de consistencia Problema Objetivos Hipótesis Metodología Población Problema general: ¿Se podrá con la implementación de una plataforma web conservar archivos mul- timedia de la lengua Quechua? Objetivo general: Conservar el uso de la lengua quechua en el Perú a través de una plataforma web. General: Mediante la imple- mentación de una plataforma web se logrará conservar archivos multimedia referente a la lengua quechua. Tipo de investigación: El tipo de in- vestigación es aplicada porque se aplicará un conocimiento ya existente para solucionar un problema práctico, y cuasi experimental debido a que no se tiene un control efectivo de las variables de selección al no poder asignar aleatoriamente a los participantes para los estudios. Población: La población lo conforman todos los peru- anos quechua hablantes, siendo un número total de 2643955 104 Problemas específicos: -¿Se podrá inte- grar una página web, herramien- tas de recolección y un repositorio institucional para almacenar la mayor cantidad de datos sobre el quechua? -¿Se podrá alma- cenar el mayor contenido refer- ente a la lengua quechua en una repositorio institucional? Objetivos específicos: -Análisis y diseño de una plataforma web para la con- servación de contenido refer- ente al quechua. -Implementar un repositorio institucional que almacene contenido refer- ente a la lengua quechua. Específicos: -Mediante la integración de una página web, her- ramientas de recolección y un repositorio institucional se logrará almacenar la mayor cantidad de archivos mul- timedia. -Mediante la imple- mentación de un repositorio institucional se logrará almacenar archivos mul- timedia de la lengua quechua. Diseño de la investigación: El desarrollo de la tesis tiene las siguientes etapas: -Definición de los objetivos de la plataforma web Identificación de las posi- bles fuentes de variación Especificación de las medidas a realizar y el procedimiento Diseño y eje- cución de la plataforma web Revisión y posibles modifi- caciones Muestra: El valor de la muestra obtenida uti- lizando la fórmula 4.1 es 367513 105