Prototipo de aplicación móvil en android para optimizar el uso del tiempo en el reporte de visitas en el proyecto de atención a la primera infancia en condición de vulnerabilidad del Municipio del Tambo Cauca

Texto completo

(1)PROTOTIPO DE APLICACIÓN MÓVIL EN ANDROID PARA OPTIMIZAR EL USO DEL TIEMPO EN EL REPORTE DE VISITAS EN EL PROYECTO DE ATENCIÓN A LA PRIMERA INFANCIA EN CONDICIÓN DE VULNERABILIDAD DEL MUNICIPIO DEL TAMBO - CAUCA. Ing. Carlos Andrés Caicedo Camilo 20182099005 Ing. Leydi Rocı́o Camargo Quintero 20182099006. Mayo 2019.

(2) PROTOTIPO DE APLICACIÓN MÓVIL EN ANDROID PARA OPTIMIZAR EL USO DEL TIEMPO EN EL REPORTE DE VISITAS EN EL PROYECTO DE ATENCIÓN A LA PRIMERA INFANCIA EN CONDICIÓN DE VULNERABILIDAD DEL MUNICIPIO DEL TAMBO - CAUCA. ESPECIALIZACIÓN EN INGENERÍA DE SOFTWARE FACULTAD DE INGENIERÌA Proyecto presentado por: Ing. Carlos Andrés Caicedo Camilo 20182099005 Ing. Leydi Rocı́o Camargo Quintero 20182099006. Mayo 2019.

(3) Índice general Introducción. 8. I. 9. Contextualización de la investigación. 1. Descripción de la investigación 1.1. Planteamiento/Identificación del problema . . . 1.1.1. Formulación del problema . . . . . . . . 1.1.2. Sistematización del problema . . . . . . 1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . 1.2.1. Objetivo general . . . . . . . . . . . . . 1.2.2. Objetivos especı́ficos . . . . . . . . . . . 1.3. Justificación del trabajo/investigación . . . . . 1.4. Hipótesis . . . . . . . . . . . . . . . . . . . . . 1.5. Marco Referencial . . . . . . . . . . . . . . . . 1.5.1. Marco Teórico . . . . . . . . . . . . . . 1.5.2. Marco Conceptual . . . . . . . . . . . . 1.6. Metodologı́a de la investigación . . . . . . . . . 1.6.1. Tipo de estudio . . . . . . . . . . . . . . 1.6.2. Método de investigación . . . . . . . . . 1.6.3. Fuentes y técnicas para la recolección de 1.7. Organización del trabajo de grado . . . . . . . 1.8. Estudio de sistemas previos . . . . . . . . . . .. II. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . la información . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. Desarrollo de la investigación. 2. Arquitectura Empresarial 2.1. Descripción de la organización . . . . . . 2.1.1. Misión . . . . . . . . . . . . . . . 2.1.2. Visión . . . . . . . . . . . . . . . 2.1.3. Polı́tica de Calidad . . . . . . . . 2.2. Vista de Negocio . . . . . . . . . . . . . 2.2.1. Punto de Vista de Organización 3. 10 10 11 11 11 11 12 12 12 13 13 24 24 24 24 26 26 26. 28 . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 29 29 29 30 30 31 31.

(4) ÍNDICE GENERAL 2.2.2. 2.2.3. 2.2.4. 2.2.5. 2.2.6. 2.3. Vista 2.3.1. 2.3.2. 2.3.3. 2.3.4. 2.4. Vista 2.4.1. 2.4.2. 2.4.3. 2.4.4. 2.4.5. 2.4.6. 2.5. Vista 2.5.1. 2.5.2. 2.5.3. 2.5.4. 2.5.5.. 4. Punto de Vista de Cooperación de Actor . . . . . . . . Punto de Vista de Función de Negocio . . . . . . . . . Punto de Vista de Proceso de Negocio . . . . . . . . . Punto de Vista de Cooperación de Proceso de Negocio Punto de Vista de Producto . . . . . . . . . . . . . . . de Aplicación . . . . . . . . . . . . . . . . . . . . . . . . Punto de Vista de comportamiento de la aplicación . . Punto de Vista de Cooperación de Aplicación . . . . . Punto de Vista de Estructura de Aplicación . . . . . . Punto de Vista de Uso de Aplicación . . . . . . . . . . de Tecnologı́a . . . . . . . . . . . . . . . . . . . . . . . . Punto de Vista de Infraestructura . . . . . . . . . . . Punto de Vista de Uso de Infraestructura . . . . . . . Punto de Vista de Organización e Implementación . . Punto de Vista de Estructura de Información . . . . . Punto de Vista de Realización del Servicio . . . . . . . Punto de Vista de Vista de Capas . . . . . . . . . . . Motivacional . . . . . . . . . . . . . . . . . . . . . . . . Punto de Vista de Vista de Stakeholder . . . . . . . . Punto de Vista de Realización de Objetivos . . . . . . Punto de Vista de Contribución . . . . . . . . . . . . . Punto de Vista de Vista de Motivación . . . . . . . . . Punto de Vista de Vista de Proyecto . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. 31 32 32 33 33 34 34 35 35 36 37 37 37 37 38 38 38 39 39 40 40 41 41. 3. Construcción del prototipo 43 3.1. Fase de análisis y diseño . . . . . . . . . . . . . . . . . . . . . . . 43 3.2. Fase de Construcción . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.3. Fase de Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4. Diseño de la base de datos distribuida 54 4.1. Fase de Análisis y Diseño . . . . . . . . . . . . . . . . . . . . . . 54 4.2. Fase de Construcción . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.3. Fase de Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . 57. III. Cierre de la investigación. 58. 5. Resultados y discusión 59 5.1. Resultados y discusión . . . . . . . . . . . . . . . . . . . . . . . . 59 6. Conclusiones 6.1. Verificación, contraste y evaluación 6.2. Sı́ntesis del modelo propuesto . . . 6.3. Aportes originales . . . . . . . . . 6.4. Trabajos o publicaciones derivadas. de los objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 60 60 61 61 61.

(5) ÍNDICE GENERAL. 5. 7. Prospectiva del trabajo de grado 62 7.1. Lı́neas de investigación futuras . . . . . . . . . . . . . . . . . . . 62 7.2. Trabajos de investigación futuros . . . . . . . . . . . . . . . . . . 62 Bibliografı́a. 63. Referencias Web. 64.

(6) Índice de figuras 1.1. Colombia - Cauca - El Tambo. Fuente: [9] . . . . . . . . . . . . . 1.2. Representación del Lenguaje Archimate Capa de Negocio Parte 1. Fuente: [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Representación del Lenguaje Archimate Capa de Negocio Parte 2. Fuente: [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4. Representación del Lenguaje Archimate Capa de Aplicación. Fuente: [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5. Representación del Lenguaje Archimate Capa de Infraestructura. Fuente: [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6. Representación del Lenguaje Archimate Capa de Motivación. Fuente: [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7. Ejemplo del formulario empleado en la visita domiciliaria. Fuente: [13] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1. Logo de la Fundación Gimnasio Moderno del Cauca. Fuente: [14] 2.2. Punto de Vista de Organización. Fuente: Autor. Software: Coloso 2.3. Punto de Vista de Cooperación de Actor. Fuente: Autor. Software: Coloso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4. Punto de Vista de Función de Negocio. Fuente: Autor. Software: Coloso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5. Punto de Vista de Proceso de Negocio. Fuente: Autor. Software: Coloso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6. Punto de Vista de Cooperación de Proceso de Negocio. Fuente: Autor. Software: Coloso . . . . . . . . . . . . . . . . . . . . . . . 2.7. Punto de Vista de Producto. Fuente: Autor. Software: Coloso . . 2.8. Punto de Vista de Comportamiento de Aplicación. Fuente: Autor. Software: Coloso . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.9. Punto de Vista de Cooperación de Aplicación. Fuente: Autor. Software: Coloso . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.10. Punto de Vista de Estructura de Aplicación. Fuente: Autor. Software: Coloso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.11. Punto de Vista de Uso de Aplicación. Fuente: Autor. Software: Coloso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.12. Punto de Vista de Infraestructura. Fuente: Autor. Software: Coloso 6. 11 19 20 21 22 23 27 30 31 32 32 33 33 34 34 35 35 36 37.

(7) ÍNDICE DE FIGURAS. 7. 2.13. Punto de Vista de Uso de Infraestructura. Fuente: Autor. Software: Coloso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.14. Punto de Vista de Organización e Implementación. Fuente: Autor. Software: Coloso . . . . . . . . . . . . . . . . . . . . . . . . . 2.15. Punto de Vista de Estructura de Información. Fuente: Autor. Software: Coloso . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.16. Punto de Vista de Realización del Servicio.Fuente: Autor. Software: Coloso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.17. Punto de Vista de Vista de Capas. Fuente: Autor. Software: Coloso 2.18. Punto de Vista de Vista de Stakeholder. Fuente: Autor. Software: Coloso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.19. Punto de Vista de Realización de Objetivos. Fuente: Autor. Software: Coloso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.20. Punto de Vista de Contribución. Fuente: Autor. Software: Coloso 2.21. Punto de Vista de Motivación. Fuente: Autor. Software: Coloso . 2.22. Punto de Vista de Proyecto. Fuente: Autor. Software: Coloso . .. 40 41 41 42. 3.1. Caso de uso N.001: Registrar. Fuente: Autor . . . . . . . . . . 3.2. Caso de uso N.002: Iniciar Sesión. Fuente: Autor . . . . . . . 3.3. Caso de uso N.003: Cerrar Sesión. Fuente: Autor . . . . . . . 3.4. Android Studio. Fuente: [15] . . . . . . . . . . . . . . . . . . . 3.5. Android Studio. Fuente: Autor . . . . . . . . . . . . . . . . . 3.6. Pantalla de autenticación. Fuente: Autor . . . . . . . . . . . . 3.7. Pantalla formulario unidad de servicio. Fuente: Autor . . . . 3.8. Pantalla formulario del niño/niña. Fuente: Autor . . . . . . . 3.9. Pantalla formulario salud. Fuente: Autor . . . . . . . . . . . . 3.10. Pantalla nutrición y medidas antropométricas. Fuente: Autor 3.11. Pantalla mensaje sincronización exitosa. Fuente: Autor . . . . 3.12. Pantalla mensaje sincronización no exitosa. Fuente: Autor . . 3.13. Pantalla mensaje error al sincronizar. Fuente: Autor . . . . .. . . . . . . . . . . . . .. 43 44 44 45 45 46 47 48 49 50 51 52 53. Diagrama de relación base de datos distribuida. Fuente: Autor . Diagrama de entendimiento de las bases de datos. Fuente: Autor Creación de las tablas. Fuente: Autor . . . . . . . . . . . . . . . . Consulta N.1 base de datos distribuida. Fuente: Autor . . . . . . Consulta N.2 base de datos distribuida. Fuente: Autor . . . . . .. 55 56 56 57 57. 4.1. 4.2. 4.3. 4.4. 4.5.. . . . . . . . . . . . . .. 37 38 38 39 39 40.

(8) Introducción La presente investigación propone el uso de las tecnologı́as de la información en los procesos que en la actualidad se hacen de forma manual. Esta propuesta se enfoca en mejorar desde el aspecto de la percepción de tiempo empleado en esas actividades, como lo es el caso de la Fundación Gimnasio Moderno del Cauca, la cual realiza una serie de visitas domiciliarias a la población de la primera infancia en condiciones de vulnerabilidad de las veredas del municipio del Tambo – Cauca, con el propósito de reforzar los modelos de prevención, detección y tratamiento de la violencia doméstica. De manera que, en el desarrollo de estas actividades el Trabajador Social utiliza tiempo de la visita al diligenciamiento de documentos en papel que respaldan las acciones ejecutadas, tiempo que en el ejercicio, deberı́a dedicarse a la atención de los niños. Esto sin duda, es una oportunidad para aplicar las tecnologı́as de la información, mejorando la calidad de las visitas con la percepción del tiempo dedicado entre el reporte de la visita y el cuidado a los usuarios de primera infancia en condición de vulnerabilidad. Por consiguiente la investigación presenta una alternativa de solución a esta problemática con el diseño y construcción de un prototipo de aplicación móvil en Android y la utilización de Base de datos distribuida para el diligenciamiento de la ficha de caracterización socio-familiar durante las visitas domiciliarias.. 8.

(9) Parte I. Contextualización de la investigación. 9.

(10) Capı́tulo 1. Descripción de la investigación 1.1.. Planteamiento/Identificación del problema. El Trabajador Social que visita a la población de la primera infancia en las veredas del Tambo – Cauca, invierte mucho tiempo en diligenciar los formatos para los reportes de las actividades realizadas. Se limita el trabajo con la primera infancia al estar llenando formatos en papel, en ocasiones el profesional se preocupa más por diligenciar los documentos, que atender a la primera infancia, enfocando su trabajo en el formalismo de la visita y no en las activiades con los niños y su familia. En cada una de estas visitas los funcionarios deben diligenciar más de 10 formatos, consumiendo gran parte del tiempo que tienen estipulado por cada visita y esto implica menos tiempo para las actividades que se deben realizar con los niños, niñas y sus familiares, los funcionarios cada 8 dı́as deben radicar fı́sicamente todos los formatos de las visitas realizadas durante ese periodo de tiempo, para que una persona se encargue de ingresar toda esta información al sistema. Esta problemática está afectando el tiempo que se le deberı́a dedicar a cada niño para realizar sus respectivas actividades y también conlleva a un reproceso de funciones que realizan los funcionarios diligenciando formatos y luego ingresarlos al sistema, todo esto se realiza de esta forma por que las visitas se realizan en sector rural donde el acceso a internet es limitado o nulo. De seguir ası́ el programa de visitas domiciliarias gastará más tiempo en la formalización de las sesiones, que en la atención a la primera infancia. Se requiere una alternativa que facilite el trabajo del profesional, optimizando el tiempo de la visita y centralizando la información de este proceso mediante una herramienta como las bases de datos distribuidas. 10.

(11) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN. 11. Figura 1.1: Colombia - Cauca - El Tambo. Fuente: [9]. 1.1.1.. Formulación del problema. ¿De qué manera se puede cambiar la percepción del uso de tiempo para que los funcionarios realicen las respectivas actividades con los niños y sus familiares en cada visita, evitando el reproceso de funciones?. 1.1.2.. Sistematización del problema. ¿Cuáles es la mejor alternativa técnica para diligenciar los formatos? ¿Cuál es la mejor herramienta para sincronizar la información en modelo off-line?. 1.2. 1.2.1.. Objetivos Objetivo general. Diseñar un prototipo de una aplicación móvil para Android la cual funcione off-line, donde los profesionales de la Fundación Gimnasio Moderno del Cauca puedan mejorar la percepción del uso del tiempo empleado en el diligenciamiento del formulario de la visita que realizan a los usuarios de primera infancia, en.

(12) 1.3. JUSTIFICACIÓN DEL TRABAJO/INVESTIGACIÓN. 12. las veredas del municipio del Tambo – Cauca, por medio de las herramientas de tecnologı́a de la información para la sincronización de datos.. 1.2.2.. Objetivos especı́ficos. Construir el modelo de base de datos distribuida que se adapte de mejor forma al funcionamiento off-line, como parte de la solución a la problemática de la optimización del tiempo para mejorar la atención de la población infantil. Generar una interfaz de usuario, con accesos intuitivo y de fácil navegabilidad que cumpla con los requisitos del formulario. Implementar un prototipo que sincronice la información de las visitas a la comunidad infantil para el almacenamiento de los datos recolectados mediante la base de datos distribuida.. 1.3.. Justificación del trabajo/investigación. La presente investigación busca implementar un modelo de sincronización de información entre una base datos local en una aplicación móvil y una base de datos centralizada porque se requiere verificar si al usar las tecnologias de la información puede ayudar a mejorar la percepión del usuario en el tiempo que emplea en el diligenciamiento del formulario. Las bases de datos distribuidas permiten la sincronización de la información entre una base de datos local y una base de datos principal, mediante un datacenter el cual tiene la capacidad para recibir muchas peticiones simultáneas sin lograr afectación como sı́ lo harı́a si las transacciones se realizarán directamente a la base de datos. Para ello se requiere una estructura similar entre las bases de datos a sincronizar la información. El proceso que se está aplicando para la realización de estas visitas, no satisface las necesidades sociales de los niños ya que el tiempo empleado cada vez es menor para las actividades de entendimiento, de manejo de los problemas y de fortalecimiento de los lazos familiares. El reporte de estas actividades tiene gran tendencia a errores de transcripción y que ponen en riesgo la veracidad de la información registrada por cada profesional, teniendo un margen alto de error al generar estadı́sticas que no muestren la realidad del estado de esta población.. 1.4.. Hipótesis. La implementación del prototipo de aplicación móvil para dispositivos Andriod, permite al profesional manejar de mejor forma su tiempo al ser una herramienta aliada para el registro de sus actividades y el uso de base de datos distribuidas permite la sincronización de la información, reduciendo tiempos en la recolección de la información y aumentando la veracidad de los datos recolectados..

(13) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN. 1.5. 1.5.1.. 13. Marco Referencial Marco Teórico. Base de datos distribuida Una base de datos distribuida (BDD) es una colección de datos que pertenecen lógicamente al mismo sistema, pero que están distribuidos sobre diferentes ordenadores de la red. Esta definición enfatiza dos aspectos importantes en una BDD: Distribución: Los datos no residen en el mismo lugar. De este modo se puede distinguir una BDD de una base de datos (BD) centralizada. Correlación lógica: Los datos no residen en el mismo lugar. De este modo se puede distinguir una BDD de una base de datos (BD) centralizada. De este modo se puede distinguir una BDD de un conjunto de BD locales o ficheros residentes en diferentes lugares de una red de ordenadores. En la arquitectura de una BDD se pueden identificar tres capas: vista de usuario, conceptual y fı́sica. En la capa de usuario se encuentran todas las aplicaciones, las pantallas de entrada de cada dato y los reportes requeridos para la empresa para la cual se representa el modelo. En la capa conceptual está el modelo del negocio subyacente, usualmente el modelo entidad-relación. En la capa fı́sica está el modelo fı́sico y la estructura de la base de datos. Desde la perspectiva de una BDD, los usuarios desde la capa de usuario examinan y manipulan los datos como si la base de datos estuviese centralizada en ese nodo. Desde el punto de vista fı́sico la BD está fragmentada y ubicada en diferentes sitios. [1] Entre los beneficios que presentan las bases de datos distribuidas, se encuentran [10]: Los datos son localizados en un lugar más cercano, por tanto, el acceso es más rápido. El procesamiento es rápido debido a que varios nodos intervienen en el procesamiento de una carga de trabajo, nuevos nodos se pueden agregar fácil y rápidamente. La comunicación entre nodos se mejora y existe una autonomı́a e independencia entre los nodos. Los datos se pueden colocar fı́sicamente en el lugar donde se acceden con mayor frecuencia, haciendo que los usuarios tengan control local de los datos con los que interactúan. Esto resulta en una autonomı́a local. Mediante la replicación de información, las bases de datos distribuidas pueden presentar cierto grado de tolerancia a fallas haciendo que el funcionamiento del sistema no dependa de un solo lugar..

(14) 1.5. MARCO REFERENCIAL. 14. La proliferación de RDBMS (Sistema de Gestión de bases de datos Relacionales) y otros sistemas de datos combinados con la necesidad de una vista integrada de los datos, que abarca diferentes departamentos o aplicaciones, llevan al concepto de un sistema de gestión de bases de datos distribuidas (DDBMS). Un DDBMS se puede diseñar con uno de varios enfoques alternativos diferentes. Un DDBMS puede proporcionar una interfaz única y uniforme a los datos contenidos en cualquiera de varias bases de datos RDBMS tradicionales, separadas. Idealmente, las aplicaciones escritas para acceder a DDBMS pueden conectarse a cualquier información controlada por los sistemas de datos integrados por DDBMS, incluso datos administrados dentro de archivos planos o bases de datos no relacionales. Como analizan Rahimi y Haug en /citec3, hay varias alternativas arquitectónicas de DDBMS, pero todas tienen un objetivo común; se esfuerzan por proporcionar cierto grado de apoyo para varios tipos diferentes de transparencia. Por ejemplo, proporcionar transparencia de ubicación significa que la aplicación no necesita conocer ningún detalle de red o implementación para el sistema host subyacente que contiene el conjunto de datos al que necesita acceder para una consulta determinada. La transparencia de la fragmentación significa que el DDBMS proporciona una vista integrada de los datos, incluso cuando el esquema y el contenido subyacente se dividen en varios grupos de filas (fragmentación horizontal), grupos de columnas (fragmentación vertical) o subgrupos basados en ambos tipos de fragmentación (es decir, fragmentación hı́brida). La transparencia de la replicación permite la duplicación de tablas o fragmentos para un mejor rendimiento y el equilibrio de carga de las consultas, al mismo tiempo que garantiza la sincronización del contenido de los datos para las operaciones de escritura. Cuando se utiliza un DDBMS para unir varias bases de datos separadas, no siempre es una solución ideal. Por ejemplo, las aplicaciones OLTP (Procesamiento de Transacciones En Lı́nea - OnLine Transaction Processing) individuales, previamente diseñadas e implementadas para conectarse directamente a los datos subyacentes, todavı́a necesitan realizar operaciones de lectura y escritura en los conjuntos de datos subyacentes. Desafortunadamente, a menudo se considera poco práctico (en función de la vista del valor de la calidad) reescribir estas aplicaciones tradicionales para usar el DDBMS en lugar del acceso directo que usaron originalmente. Debido a situaciones como esta y otras consideraciones, el uso de DDBMS para operaciones de escritura puede ser bastante limitado o incluso imposible. En tal entorno, realizar consultas contra un DDBMS tiene beneficios potenciales; sin embargo, depende de la capacidad de los desarrolladores de DDBMS para integrar los datos de los diferentes sistemas de datos subyacentes. La tarea de integrar estos sistemas puede ser bastante desafiante, o incluso imposible, en función de la calidad de los datos de estos sistemas y la comprensión diferente y, a menudo, incompatible de los conceptos en diferentes aplicaciones. Por lo tanto, la calidad de DDBMS depende de la calidad de los datos de otros sistemas y procesos. Esto significa que el grado de calidad que un DDBMS puede proporcionar razonablemente es a menudo menor que el máximo teórico que el enfoque DDBMS podrı́a proporcionar. [4].

(15) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN. 15. Patrones de desarrollo para aplicaciones móviles El uso de dispositivos móviles computacionales entre las personas tiene gran aceptación, al punto de convertirse en un sector con gran representación a nivel mundial y en constante evolución; es por esto se debe formalizar los procesos, procedimientos y actividades técnicas necesarias para la producción de aplicaciones con calidad, ya sea en ambientes académicos o industriales. Es adecuado considerar que el permanente aumento en el uso de dispositivos móviles requiere el desarrollo aplicaciones que permitan aprovechar mejor este tipo de tecnologı́a. En la actualidad, hay una tendencia en el mercado de aplicaciones, siendo estas apoyo al proceso comercial de grandes compañı́as donde las aplicaciones son ofrecidas para brindar diversas funcionalidades a los usuarios en general. [11] La metodologı́a propuesta para el desarrollo de aplicaciones para móviles se fundamenta en la experiencia de investigaciones previas en aplicaciones móviles, la evaluación del potencial de éxito para servicios de tercera generación denominada 6 M, la ingenierı́a de software educativo con modelado orientado por objetos (ISE-OO), y principalmente en los valores de las metodologı́as ágiles. De las metodologı́as ágiles se heredan los conceptos inmersos en los cuatro postulados o manifiesto ágil [4]. Desarrollar software que funciona más que conseguir buena documentación. La respuesta ante el cambio es más importante que el seguimiento de un plan. Colaboración con el cliente sobre negociación contractual. Individuos e interacciones sobre procesos y herramientas. De la 6 M’s se extrae la concepción de que las aplicaciones móviles deben garantizar el cumplimiento de las necesidades de los usuarios y al mismo tiempo generen ingresos. La 6 M’s debe su nombre a los seis atributos que se miden para evaluar el éxito del servicio propuesto: Movement (Movimiento), Moment (Momento), Me (Yo), Multi-user (Multiusuario), Money (Dinero) y Machines (Máquinas) [5]. La metodologı́a se encuentra enmarcada en cinco fases como se muestra en la figura 1, denominadas: análisis, diseño, desarrollo, pruebas de funcionamiento y entrega. A continuación se describe cada una de las actividades que intervienen en el desarrollo de la propuesta. Análisis En esta fase se analizan las peticiones o requerimientos de las personas o entidad para la cual se desarrolla el servicio móvil “Cliente”, el propósito es definir las caracterı́sticas del mundo o entorno de la aplicación. Se realizan tres tareas: obtener requerimientos, clasificar los requerimientos y personalizar el servicio [12]. Obtener requerimientos: se sugiere hacer una serie de entrevistas al cliente, para que manifieste los sı́ntomas del problema o necesidades que se pretenden solucionar con las tecnologı́as móviles, o simplemente, para que señale las caracterı́sticas que debe tener la aplicación..

(16) 1.5. MARCO REFERENCIAL. 16. Clasificar los requerimientos: una vez identificados los requerimientos que debe tener el software, se procede a clasificarlos. Dichos requerimientos se pueden clasificar en entorno, mundo, funcionales y no funcionales. El entorno se refiere a todo lo que rodea al servicio. Por ejemplo, las caracterı́sticas técnicas del dispositivo móvil del cliente, el sistema operativo subyacente (móvil y servidores), la tecnologı́a utilizada para la transferencia de información, el Sistema Manejador de Base de Datos, Data Base Management System (DBMS), si se requiere, el formato de archivos y, otros módulos tecnológicos utilizados para el servicio. El mundo es la forma cómo interactúan el usuario y la aplicación. Aquı́ se encuentran los requerimientos de la Interfaz Gráfica de Usuario, Graphical User Interface (IGU), la forma en que el software va a generar los datos de salida, el formato de los datos y los demás requerimientos que involucren la comunicación hombre-máquina, considerando la gama tecnológica de los teléfonos móviles de los usuarios a la que va dirigida el servicio. Los requerimientos funcionales son todos aquellos que demandan una función dentro del sistema. Se deben definir claramente cada una de las tareas que debe realizar la aplicación. Los requerimientos no funcionales son la estabilidad, la portabilidad, el rendimiento, el tiempo de salida al mercado y, el costo, entre otros. Personalizar el servicio: adicionalmente se deben analizar aspectos de la cotidianidad del cliente como preferencias, costumbres y particularidades del usuario, con el propósito de garantizar la aceptación del servicio. Diseño El objetivo de esta etapa es plasmar el pensamiento de la solución mediante diagramas o esquemas, considerando la mejor alternativa al integrar aspectos técnicos, funcionales, sociales y económicos. A esta fase se retorna si no se obtiene lo deseado en la etapa prueba de funcionamiento. Se realizan cuatro actividades en esta fase: definir el escenario, estructurar el software, definir tiempos y asignar recursos. Desarrollo El objetivo de esta fase es implementar el diseño en un producto de software. En esta etapa se realizan las siguientes actividades [?]: Codificar: se escribe en el lenguaje de programación seleccionado, cada una de las partes definidas en los diagramas realizados en la etapa de diseño. Pruebas unitarias: se verifica el funcionamiento de la aplicación. En primer lugar, se comprueba la correcta operación de cada elemento desarrollado —objeto, clase, actividad, documento, entre otros— en forma individual; posteriormente, se pone en funcionamiento el conjunto .de elementos, comprobando la interrelación entre ellos. Se ejecuta y se observan los resultados obtenidos, para compararlos con los esperados. Documentar el código: a medida que se codifica y se prueba cada elemento, se redacta la pequeña documentación sobre lo desarrollado..

(17) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN. 17. Codificar ayudas: además del manual de instalación y de usuario, deben existir una serie de ayudas que informen de manera didáctica lo que puede hacer el usuario con la aplicación, estas ayudas deben ser codificadas en el mismo lenguaje de programación e integrada en la interfaz de usuario. Pruebas de funcionamiento El objetivo de esta fase es verificar el funcionamiento de la aplicación en diferentes escenarios y condiciones; para esto se realizan las siguientes tareas [?]: Emulación y simulación: se realizan pruebas simulando el escenario y emulando el dispositivo móvil, explorando todas las utilidades y funciones de la aplicación, introduciendo diferentes datos, inclusive erróneos, para medir la funcionalidad y el nivel de robustez del software. Si se encuentran algunas fallas, se debe regresar a la etapa de codificación en la fase de desarrollo para solucionar los problemas, si las pruebas son satisfactorias se procede a la etapa de pruebas con dispositivos reales. Dispositivos reales: deben hacerse pruebas de campo en equipos reales para medir el desempeño y el rendimiento del aplicativo. Si se encuentran fallas en el tiempo de ejecución, si el software no cumple con los requerimientos especificados, o si el cliente solicita un cambio de última hora, hay que regresar a la fase de diseño para reestructurar y solucionar el inconveniente presentado. Análisis de las 6 M’s: para valorar el potencial de éxito del servicio, se sugiere buscar un grupo de expertos en el campo del desarrollo móvil para que utilicen el método de evaluación de las 6 M’s, y califiquen la presencia de los seis atributos en la aplicación desarrollada Cualquier servicio que brinde un gran valor en cualquiera de las 6 M’s tiene un buen potencial para el éxito como servicio móvil. Si la evaluación de las 6 M’s del servicio es insatisfactoria, se debe rediseñar el servicio fortaleciendo los atributos mencionados. Entrega Terminada la depuración de la aplicación y atendidos todos los requerimientos de última hora del cliente se da por finalizada la aplicación y se procede a la entrega del ejecutable, el código fuente, la documentación y el manual del sistema. [?] Manuales: el objetivo es el entrenamiento; una aplicación móvil debe constar de un manual del sistema donde se indique el proceso de instalación, la atención a posibles fallas en el tiempo de ejecución y, las especificaciones técnicas mı́nimas de hardware y software que requiere el equipo, para el funcionamiento adecuado del aplicativo desarrollado. Distribución: se define el canal de comercialización/instalación de la aplicación..

(18) 1.5. MARCO REFERENCIAL. 18. Base de datos local SQLite SQLite es una base de datos integrada. En lugar de ejecutarse de forma independiente como un proceso independiente, coexiste simbióticamente dentro de la aplicación que sirve, dentro de su espacio de proceso. Su código es entrelazado, o incrustado, como parte del programa que lo aloja. Para un observador externo, nunca serı́a evidente que tal programa tuviera un sistema de gestión de base de datos relacional (RDBMS) a bordo. El programa hará su trabajo y manejarı́a sus datos de alguna manera, sin hacer ningún énfasis de como lo hizo. Pero en el interior, hay un motor de base de datos completo y autónomo en funcionamiento. Una ventaja de tener un servidor de base de datos es que dentro de su programa no se requiere configuración o administración de la red. Tanto el cliente como el servidor se ejecutan juntos en el mismo proceso. Esto reduce la sobrecarga relacionada con las llamadas de red, simplifica la administración de la base de datos y facilita la implementación de su aplicación. Todo lo que necesita está compilado directamente en su programa. Hoy en dı́a, existe una amplia variedad de productos de bases de datos relacionales en el mercado especı́ficamente diseñados para uso integrado, como Sybase SQL Anywhere, InterSystems Caché, Pervasive PSQL, y el motor Jet de Microsoft. Algunos proveedores han actualizado sus bases de datos a gran escala para crear variantes incrustadas. Ejemplos de estos incluyen DB2 Everyplace de IBM, 10g de Oracle y SQL Server Desktop Engine de Microsoft. Las bases de datos de código abierto MySQL y Firebird también ofrecen versiones locales. De todos estos productos, solo dos son de código abierto y no están sujetos a cargos por licencias: Firebird y SQLite. De estos dos restantes, solo uno está diseñado exclusivamente para su uso como una base de datos integrada: SQLite. [6] Arquitectura empresarial La Arquitectura Empresarial se comprende como el diseño y descripción de una empresa o entidad como un sistema en términos de sus componentes, las interrelaciones entre ellos, los principios y guı́as que gobiernan ese diseño y su evolución. Dentro de la descripción de una arquitectura empresarial y bajo el lenguaje de arquitectura empresarial Archimate, se presenta el análisis de la organización desde diferentes capas: Negocio Aplicación Tecnologı́a Motivación Capa de Negocio Es una de las capas más importantes debido a que el lenguaje que se utiliza, permite hablar en términos de las entidades del negocio, por lo que es importante.

(19) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN. 19. distribuir adecuadamente la semántica. Esta capa gira en torno a tres dimensiones de comportamiento: procesos, servicios y producto (centro del negocio). La indagación debe realizarse al modelar esta capa, es convertirla en software. [8]. Figura 1.2: Representación del Lenguaje Archimate Capa de Negocio Parte 1. Fuente: [8].

(20) 1.5. MARCO REFERENCIAL. 20. Figura 1.3: Representación del Lenguaje Archimate Capa de Negocio Parte 2. Fuente: [8] Capa de Aplicación Esta capa permite hablar de componentes de software. Cabe recordar que la arquitectura de software hereda y basa su modelo de las arquitecturas, utilizando el concepto de componente. Basta con saber que se le debe pasar al componente para tener una estructura que garantice el ciclo de vida. Esta capa maneja un lenguaje de descripción de arquitectura en inglés Architecture Description Languaje - ADL, utiliza los siguientes elementos: componentes, interfaces, conectores y restricciones. Esta capa tiene dos dimensiones: la dimensión estructural y la dimensión de comportamiento. Sus conceptos se representan de color azul celeste. [8].

(21) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN. 21. Figura 1.4: Representación del Lenguaje Archimate Capa de Aplicación. Fuente: [8] Capa de Infraestructura Esta capa representa los componentes desde su perspectiva técnica en recursos de hardware. Sus conceptos se simbolizan en color verde. [8].

(22) 1.5. MARCO REFERENCIAL. 22. Figura 1.5: Representación del Lenguaje Archimate Capa de Infraestructura. Fuente: [8].

(23) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN. 23. Capa de Motivación Permite conocer sus conceptos de la organización desde el enfoque de los objetivos organizacionales y las personas involucradas o interesadas, siendo este el factor más importante de la organización. Sus conceptos se representan de color fucsia o morado haciendo alusión a la parte motivacional. [8]. Figura 1.6: Representación del Lenguaje Archimate Capa de Motivación. Fuente: [8].

(24) 1.6. METODOLOGÍA DE LA INVESTIGACIÓN. 1.5.2.. 24. Marco Conceptual. Aplicación móvil o APK Se entiende como un paquete de aplicación de android, que es usado para instalar o tgransportar las aplicaciones desarrolladas para ambientes móviles compatibles con sistema operativo Android. Android Studio Android Studio es un entorno de desarrollo basado en software IntelliJ, anunciado el 16 de mayo de 2013 en la conferencia Google I/O, y reemplazó a Eclipse como el entorno de desarrollo para soluciones sobre el sistema operativo Android. Compatible con entornos de trabajo sobre plataformas Windows 2003, Vista, 7, 8, y 10, tanto plataformas de 32 como de 64 bits, GNU/Linux, Linux con GNOME o KDE y 2 GB de memoria RAM mı́nimo y macOS, desde 10.8.5 en adelante. [7] SQLite SQLite es una base de datos relacional integrada de código abierto. Originalmente lanzado en 2000, fue diseñado para proporcionar una manera conveniente para que las aplicaciones administren datos sin la sobrecarga que a menudo viene con los sistemas de administración de bases de datos relacionales dedicados. SQLite tiene la reputación de ser altamente portátil, fácil de usar, compacta, eficiente y confiable. [6] Ficha de caracterización Socio-Familiar Consiste en formulario de caracterización que el profesional en Trabajo Social emplea durante las visitas de atención domiciliaria. El formulario está compuesto por información de la unidad de servicio, información del usuario (niña/niño), salud, discapacidad, nutrición y medidas antropométricas.. 1.6. 1.6.1.. Metodologı́a de la investigación Tipo de estudio. El tipo de estudio para este proyecto de investigación es de tipo proyectivo, debido a que busca exponer una alternativa para mejorar el proceso actual que emplea el profesional del ICBF para la recolección de la información de sus visitas domiciliarias.. 1.6.2.. Método de investigación. El método de investigación emplear en este proyecto es el deductivo, por medio de la observación de las debilidades del proceso actual de la recolección.

(25) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN. 25. de la información, señalando las acciones de mejorar que pueden implementarse dentro del prototipo como el uso de base de datos distribuidas..

(26) 1.7. ORGANIZACIÓN DEL TRABAJO DE GRADO. 1.6.3.. 26. Fuentes y técnicas para la recolección de la información. Las técnicas de recolección de la información de la investigación son: Entrevista por medio de teleconferencia a un profesional que realiza las visitas de atención domiciliaria. Fuentes Primarias de las fuentes académicas para el uso e implementación de base de datos distribuidas y el desarrollo de aplicaciones móviles para Android. Se entiende como fuentes primarias a las base de datos digitales SCOPUS, IEEE y SCIENCE DIRECT. Fuentes Secundarias en textos, revistas, documentos y prensa, sobre aplicaciones móviles para Android. Se entiende como fuentes de información secundaria el buscardor Google Académico.. 1.7.. Organización del trabajo de grado. El trabajo de investigación formalizado a través del presente documento está constituido por tres (3) capı́tulos, el primero permite la contextualización de la investigación conformado por el planteamiento de la de investigación, los objetivos trazados, la sistematización del problema, la justificación de trabajo, el marco referencial, la metodologı́a de la investigación y el estudio previos. El segundo capı́tulo, aborda el desarrollo de la investigación describiendo el análisis de la organización y su problemática a través de la arquitectura empresarial, seguido de la construcción del prototipo y cerrando con diseño de la base de datos distribuida. Finalmente, el último capı́tulo presenta el cierre de la investigación con los resultados de la prueba, la validación de la hipótesis, las conclusiones y los trabajos futuros.. 1.8.. Estudio de sistemas previos. En los estudios previos del proceso analizado en la problemática del trabajo de investigación, se identificó en la etapa de diseño del prototipo que el Instituto Colombiano del Bienestar Familiar (ICBF), trabaja en conjunto con los profesionales de la Fundación del Gimnasio Moderno del Cauca en las visitas domiciliaras a los niños y sus familiar pertenecientes a la comunidad de la fundación. Para estás visitas los formularios empleados están en formatos del ICBF. Del mismo modo, los formatos diligenciados de forma fı́sica son entregados al área de digitalización para ser ingresados al sistema, esta actividad es ejecutada por digitadores los cuales hacen lectura del formulario y transcriben las repuestas al sistema, de este modo, la información ingresada puede estar sujeta a errores de mecanografı́a, de comprensión de la información escrita y de perdida de.

(27) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN. 27. documentos, ası́ pues, el proceso actual está sujeto a muchas acciones de mejora, de las cuales se exploran dos (2) en este documento, el diseño del prototipo y la sincronización de la información en una base de datos distribuida.. Figura 1.7: Ejemplo del formulario empleado en la visita domiciliaria. Fuente: [13].

(28) Parte II. Desarrollo de la investigación. 28.

(29) Capı́tulo 2. Arquitectura Empresarial 2.1.. Descripción de la organización. La Fundación Gimnasio Moderno del Cauca es una Institución Educativa privada de carácter mixto y sin ánimo de lucro. El concepto de educación sobre el cual gira el proceso de formación está orientado por las normas propuestas por el Ministerio de Educación Nacional con técnicas y avances modernos, tanto en los elementos de trabajo como en teorı́as Pedagógicas y Sociológicas que justifican la denominación MODERNO DEL CAUCA, ubicado en este Departamento y al servicio de su comunidad. Gimnasio, por la actividad fı́sica e intelectual que se despliega: concepción ésta que implica tipos de educación que van desde atención individual del educando hasta el logro de participación activa por parte de la comunidad educativa. El pleno desarrollo de la personalidad del educando se promoverá dentro de ambiente de justicia, paz y libertad donde la ética y valores humanos se conviertan en pilar fundamental del desarrollo cientı́fico, cultural y deportivo, que encausen el proceso educativo hacia la formación de personas dotadas con conciencia reflexiva, critica y social; capaz de asumir implicaciones que genera autentico desarrollo cientı́fico, cultural y deportivo dentro y fuera de su contexto nacional. [14]. 2.1.1.. Misión. Somos una organización, que desde el año 1.983 trabaja con el propósito de brindar servicios de educación con calidad en los niveles de educación inicial, preescolar, básica primaria y secundaria, media académica; en el departamento del Cauca. Nos enmarcamos en valores de fraternidad, espiritualidad, excelencia, liderazgo y crecimiento personal; trabajamos con recursos tecnológicos, pedagógicos y administrativos a cargo de personal cualificado con una filosofı́a orientada hacia procesos de enseñanza y aprendizajes significativos, en ambientes sanos, seguros y armoniosos que hacen del Gimnasista un ser integral 29.

(30) 2.1. DESCRIPCIÓN DE LA ORGANIZACIÓN. 30. competitivo y proactivo, generando impacto positivo en proyectos de vida personal, social, y ambiental comprometidos con la solidaridad y la responsabilidad social. [14]. 2.1.2.. Visión. Seremos en 2021 una organización reconocida en la prestación de servicios educativos de alta calidad, mediante la implementación de los sistemas integrados de gestión, enfocados a la satisfacción de la familia Gimnasista, que nos permitirá convertirnos en un referente nacional. [14]. 2.1.3.. Polı́tica de Calidad. Reconocemos la calidad y la excelencia como parte fundamental de la estrategia de nuestra misión educativa, administrativa y vocacional. La Fundación Gimnasio Moderno del Cauca se compromete a garantizar calidad en sus procesos en el marco de los requerimientos de ley y de los sistemas de gestión requeridos en el camino hacia el fortalecimiento institucional. [14]. Figura 2.1: Logo de la Fundación Gimnasio Moderno del Cauca. Fuente: [14].

(31) CAPÍTULO 2. ARQUITECTURA EMPRESARIAL. 2.2. 2.2.1.. 31. Vista de Negocio Punto de Vista de Organización. En este sentido el punto de vista del negocio se enfoca en la organización interna de la empresa, permite definir e idéntica los actores que interactúan en la aplicación móvil denominada appCaracteriza.. Figura 2.2: Punto de Vista de Organización. Fuente: Autor. Software: Coloso. 2.2.2.. Punto de Vista de Cooperación de Actor. Representa la interacción de los actores con la aplicación y sus interfaces..

(32) 2.2. VISTA DE NEGOCIO. 32. Figura 2.3: Punto de Vista de Cooperación de Actor. Fuente: Autor. Software: Coloso. 2.2.3.. Punto de Vista de Función de Negocio. Describe cada una de las funciones de la solución.. Figura 2.4: Punto de Vista de Función de Negocio. Fuente: Autor. Software: Coloso. 2.2.4.. Punto de Vista de Proceso de Negocio. Análisa el proceso que la aplicación desea implementar a través de las tecnologı́as de la información..

(33) CAPÍTULO 2. ARQUITECTURA EMPRESARIAL. 33. Figura 2.5: Punto de Vista de Proceso de Negocio. Fuente: Autor. Software: Coloso. 2.2.5.. Punto de Vista de Cooperación de Proceso de Negocio. Representa la dependencia que existe entre el proceso del negocio sus actores y las interfaces. Para la investigación tenemos el proceso de Registro de la caracterización del niño y su familia”.. Figura 2.6: Punto de Vista de Cooperación de Proceso de Negocio. Fuente: Autor. Software: Coloso. 2.2.6.. Punto de Vista de Producto. Representa el valor que tiene el proceso que sistematiza la aplicación..

(34) 2.3. VISTA DE APLICACIÓN. 34. Figura 2.7: Punto de Vista de Producto. Fuente: Autor. Software: Coloso. 2.3. 2.3.1.. Vista de Aplicación Punto de Vista de comportamiento de la aplicación. Describe el comportamiento de la aplicación, desde su punto de vista interno describiendo como interactúa sus componentes.. Figura 2.8: Punto de Vista de Comportamiento de Aplicación. Fuente: Autor. Software: Coloso.

(35) CAPÍTULO 2. ARQUITECTURA EMPRESARIAL. 2.3.2.. 35. Punto de Vista de Cooperación de Aplicación. Representa la relación que existe entre los componentes y su estructura.. Figura 2.9: Punto de Vista de Cooperación de Aplicación. Fuente: Autor. Software: Coloso. 2.3.3.. Punto de Vista de Estructura de Aplicación. Representa la interacción con cada uno de sus componentes y sus interfaces.. Figura 2.10: Punto de Vista de Estructura de Aplicación. Fuente: Autor. Software: Coloso.

(36) 2.3. VISTA DE APLICACIÓN. 2.3.4.. 36. Punto de Vista de Uso de Aplicación. Describe el flujo de la información entre las funciones y sus componentes.. Figura 2.11: Punto de Vista de Uso de Aplicación. Fuente: Autor. Software: Coloso.

(37) CAPÍTULO 2. ARQUITECTURA EMPRESARIAL. 2.4. 2.4.1.. 37. Vista de Tecnologı́a Punto de Vista de Infraestructura. Representa el planteamiento de la solución funcional dentro de una infraestructura.. Figura 2.12: Punto de Vista de Infraestructura. Fuente: Autor. Software: Coloso. 2.4.2.. Punto de Vista de Uso de Infraestructura. Describe cada uno de los componentes ubicados dentro de su infraestructura.. Figura 2.13: Punto de Vista de Uso de Infraestructura. Fuente: Autor. Software: Coloso. 2.4.3.. Punto de Vista de Organización e Implementación. Detalla las interfaces describiendo su comportamiento una vez implementados..

(38) 2.4. VISTA DE TECNOLOGÍA. 38. Figura 2.14: Punto de Vista de Organización e Implementación. Fuente: Autor. Software: Coloso. 2.4.4.. Punto de Vista de Estructura de Información. Identifica las estructuras de datos desde su responsabilidad de negocio y su organización lógica.. Figura 2.15: Punto de Vista de Estructura de Información. Fuente: Autor. Software: Coloso. 2.4.5.. Punto de Vista de Realización del Servicio. Representa el proceso con los componentes de negocio, funcionales y de componentes tecnológicos.. 2.4.6.. Punto de Vista de Vista de Capas. Describe a nivel general el proceso de la organización involucrando el alcance funcional, diseño e implementación..

(39) CAPÍTULO 2. ARQUITECTURA EMPRESARIAL. 39. Figura 2.16: Punto de Vista de Realización del Servicio.Fuente: Autor. Software: Coloso. Figura 2.17: Punto de Vista de Vista de Capas. Fuente: Autor. Software: Coloso. 2.5. 2.5.1.. Vista Motivacional Punto de Vista de Vista de Stakeholder. Describe el proceso desde los interesados y sus necesidades..

(40) 2.5. VISTA MOTIVACIONAL. 40. Figura 2.18: Punto de Vista de Vista de Stakeholder. Fuente: Autor. Software: Coloso. 2.5.2.. Punto de Vista de Realización de Objetivos. Representa los requerimientos necesarios para lograr los objetivos del proceso.. Figura 2.19: Punto de Vista de Realización de Objetivos. Fuente: Autor. Software: Coloso. 2.5.3.. Punto de Vista de Contribución. Describe los aspectos que pueden generar influencia positiva o negativa para el logro de los objetivos del proceso..

(41) CAPÍTULO 2. ARQUITECTURA EMPRESARIAL. 41. Figura 2.20: Punto de Vista de Contribución. Fuente: Autor. Software: Coloso. 2.5.4.. Punto de Vista de Vista de Motivación. Describe los aspectos a considerar para lograr los objetivos propuestos dentro de proceso de negocio.. Figura 2.21: Punto de Vista de Motivación. Fuente: Autor. Software: Coloso. 2.5.5.. Punto de Vista de Vista de Proyecto. Representa el proyecto en su totalidad con los actores, la aplicación y el objetivo a lograr..

(42) 2.5. VISTA MOTIVACIONAL. 42. Figura 2.22: Punto de Vista de Proyecto. Fuente: Autor. Software: Coloso.

(43) Capı́tulo 3. Construcción del prototipo 3.1.. Fase de análisis y diseño. Para la fase de análisis y diseño se realizó el levantamiento de requerimientos para las funcionalidades de la aplicación con el fin definir qué sistema se deberı́a construir y cuáles son los requisitos a crear para cumplir la necesidad del prototipo. En general, se necesita autenticación en la aplicación móvil para identificar al administrador del sistema y al trabajador social. Se requiere que la aplicación muestre el formulario para la caracterización conformado por la información de la unidad de servicio, la información del usuario (niña/niño), datos de salud, datos para determinar una discapacidad, nutrición y medidas antropométricas. Finalmente, la aplicación debe garantizar que no en la ausencia de una conexión a internet, la información ingresada se conserve. Inicialmente, se plantean las siguientes descripciones de los casos de uso:. Figura 3.1: Caso de uso N.001: Registrar. Fuente: Autor. 43.

(44) 3.2. FASE DE CONSTRUCCIÓN. 44. Figura 3.2: Caso de uso N.002: Iniciar Sesión. Fuente: Autor. Figura 3.3: Caso de uso N.003: Cerrar Sesión. Fuente: Autor. 3.2.. Fase de Construcción. La aplicación piloto se desarrolló en el IDE Android Studio 3.2.1.0, SDK 25.5.2, para celulares son sistema operativo Android 4.0.3 (IceCreamSandwich) en adelante..

(45) CAPÍTULO 3. CONSTRUCCIÓN DEL PROTOTIPO. 45. Figura 3.4: Android Studio. Fuente: [15]. Se construye la aplicación piloto a través de un APK denominado “appCaracteriza” el cual contiene las funcionalidades de autenticación, diligenciamiento del formulario, sincronización de datos, almacenamiento de datos en la base local SQLite. Para las funcionalidades descritas anteriormente, se desarrollan las vistas correspondientes (layout).. Figura 3.5: Android Studio. Fuente: Autor.

(46) 3.3. FASE DE PRUEBAS. 3.3.. 46. Fase de Pruebas. En la fase de pruebas se generó verificación del funcionamiento de la aplicación con el comportamiento esperado y los flujos alternativos. A continuación se presentan las pantallas de la interfaz gráfica de la appCaracteriza:. Figura 3.6: Pantalla de autenticación. Fuente: Autor.

(47) CAPÍTULO 3. CONSTRUCCIÓN DEL PROTOTIPO. Figura 3.7: Pantalla formulario unidad de servicio. Fuente: Autor. 47.

(48) 3.3. FASE DE PRUEBAS. Figura 3.8: Pantalla formulario del niño/niña. Fuente: Autor. 48.

(49) CAPÍTULO 3. CONSTRUCCIÓN DEL PROTOTIPO. Figura 3.9: Pantalla formulario salud. Fuente: Autor. 49.

(50) 3.3. FASE DE PRUEBAS. 50. Figura 3.10: Pantalla nutrición y medidas antropométricas. Fuente: Autor.

(51) CAPÍTULO 3. CONSTRUCCIÓN DEL PROTOTIPO. Figura 3.11: Pantalla mensaje sincronización exitosa. Fuente: Autor. 51.

(52) 3.3. FASE DE PRUEBAS. Figura 3.12: Pantalla mensaje sincronización no exitosa. Fuente: Autor. 52.

(53) CAPÍTULO 3. CONSTRUCCIÓN DEL PROTOTIPO. Figura 3.13: Pantalla mensaje error al sincronizar. Fuente: Autor. 53.

(54) Capı́tulo 4. Diseño de la base de datos distribuida 4.1.. Fase de Análisis y Diseño. Para la fase de análisis y diseño se realizó el entendimiento a nivel de estructura de datos, planteando las entidades, con base al grupo de información recolectada a través de los formularios, a continuación el esquema:. 54.

(55) CAPÍTULO 4. DISEÑO DE LA BASE DE DATOS DISTRIBUIDA. 55. Figura 4.1: Diagrama de relación base de datos distribuida. Fuente: Autor. 4.2.. Fase de Construcción. La base de datos distribuida se construyó en el motor de base de datos MySQL. La base de datos local se construyó en el motor SQLite. La sincronización se genera a través de un servicio API Rest expuesto en internet:.

(56) 4.2. FASE DE CONSTRUCCIÓN. 56. Figura 4.2: Diagrama de entendimiento de las bases de datos. Fuente: Autor. Figura 4.3: Creación de las tablas. Fuente: Autor.

(57) CAPÍTULO 4. DISEÑO DE LA BASE DE DATOS DISTRIBUIDA. 4.3.. 57. Fase de Pruebas. En la fase de pruebas se generó verificación del funcionamiento y correcto almacenamiento de la información. A continuación se presentan las pantallas de consulta a la base de datos distribuida:. Figura 4.4: Consulta N.1 base de datos distribuida. Fuente: Autor. Figura 4.5: Consulta N.2 base de datos distribuida. Fuente: Autor.

(58) Parte III. Cierre de la investigación. 58.

(59) Capı́tulo 5. Resultados y discusión 5.1.. Resultados y discusión. Efectivamente la herramienta permite sistematizar el proceso de la recolección de la información durante la visita y la entrega de la información para su posterior procesamiento. Si bien, al tener su base de datos local no depende de una conexión a internet siendo este un factor determinante para las zonas geográficas que tiene dificultades en su conexión. El proceso de Registro de la caracterización del niño y su familia”se ejecuta de forma correcta dentro del sistema, facilitando la actividad de la visita en el sentido de diligenciamiento de las respuestas a la entrevista. La presentación de la aplicación desde su aspecto gráfico permite al usuario final, manejarla de forma intuitiva, facilitando su uso. Sin embargo, la actividades que realice en la gestión del cambio de la institución. La recolección de la información en un entorno centralizado facilita el procesamiento de la información sobre los aspectos de salud, nutrición y medidas, aspectos de discapacidad que pueda presentar el niño.. 59.

(60) Capı́tulo 6. Conclusiones 6.1.. Verificación, contraste y evaluación de los objetivos. La caracterización sociofamiliar es una herramienta fundamental para identificar las caracterı́sticas, fortalezas y aspectos mejorar de las familias. Además reconoce el contexto social y la oferta de instituciones locales para la atención integral a la primera infancia. La información recolectada permite conocer las condiciones materiales de vida, y las experiencias y relaciones sociales en las cuales viven los niños de las verredas del Tambo - Cauca, con el fin de hacer aportes para su desarrollo integral. Claramente la aplicación permite al profesional mejorar la percepción del tiempo que emplea durante la entrevista a los niños de la primer infancia y sus familias, sin embargo, la adopción de esta nueva aplicación será un desafı́o para los profesionales ya que el cambio de su dinámica diaria y la resistencia que se tenga a dicho cambio, puede llegar a impactar la aceptación de esta herramienta, siendo este un obstáculo a vencer para la implementación exitosa de esta solución. Desde el punto de vista tecnológico, la aplicación reduce significativamente el tiempo en la sistematización de información recolectada, debido a que desde el principio de la entrevista se logra ingresar la información a un sistema y ası́ se disminuyen los tiempos de digitación por parte de un operario, ya que el sistema es capaz de recibir y organizar los datos para ser entregados al sistema de consolidación y continuar su proceso de caracterización. A través de una herramienta tecnológica como la aplicación desarrollada en este piloto el Trabajador Social realiza una caracterización del niño y su familia, de forma más sencilla que diligenciar en papel el formulario. La aplicación piloto con su funcionalidad off-line garantiza que se conserva la información consignada durante la vista en una zona geográficamente distante y sin acceso a internet. Por consiguiente, una vez conectado a internet el sistema se sincroniza con la base de datos distribuida con el fin de almacenar la información que es empleada para la estructuración planes de desarrollo infantil y familiar de la población 60.

(61) CAPÍTULO 6. CONCLUSIONES. 61. atendida. Al tener una solución que permite hacer una contextualización más rápida sobre la interacción del profesional con los saberes de las familias, la aplicación piloto es una herramienta que ayuda a la consolidación de la información que sirve de insumo al Trabajador Social para la creación de estrategias de trabajo social a las familias con mayor necesidad de apoyo. Al contar con una caracterización más rápidamente procesada por un sistema presenta una oportunidad de ofrecer a la comunidad un mejor servicio. Al tener sistematizada la información de la caracterización sociofamiliar se puede establecer las condiciones sociales y económicas de la población y de las familias que influyen en la estructuración de los servicios sociales que la Fundación Gimnasio Moderno del Cauca ofrece a la comunidad.. 6.2.. Sı́ntesis del modelo propuesto. El trabajo de investigación desarrollado tiene impacto en la comunidad infantil de las veredas del Tambo – Cauca, porque logran participar de gran parte de las actividades estipuladas en las entrevistas de caracterización que aplica el profesional como en el proceso de formalización de las visitas.. 6.3.. Aportes originales. Los aportes originales resultado del trabajo de la investigación son: Desarrollo de una aplicación móvil prototipo para sistema operativo compatible con Android 4.0.3 (IceCreamSandwich) en adelante. Análisis de arquitectura empresarial del proceso en la organización que realiza la caracterización de los niños y sus familias.. 6.4.. Trabajos o publicaciones derivadas. Durante el desarrollo de esta investigación se obtuvo como publicaciones el presente documento, el código fuente del desarrollo de la aplicación móvil y el instalador de la aplicación..

(62) Capı́tulo 7. Prospectiva del trabajo de grado 7.1.. Lı́neas de investigación futuras. Con la información recolectada a través de la aplicación piloto, diseñar un algoritmo que permita generar análisis cualitativo de los efectos negativos de un ambiente problemático en la seguridad y la salud de la población infantil. Con la información recolectada a través de la aplicación piloto, diseñar un algoritmo que permita hacer una caracterización preliminar y dar recomendaciones para mejorar la convivencia de las familias, conforme los datos entregados durante la entrevista.. 7.2.. Trabajos de investigación futuros. Con la información centralizada se puede proponer alianzas con institutos, entidades públicas o privadas que atienda a familias y niños de la primera infancia para llegar a un número más grande de población. Con la base de datos centralizada se puede realizar conexión a través de servicios web que el ICBF exponga para analizar la información recolectada en tiempo real. Incluir en el prototipo de aplicación móvil appCaracteriza la caracterización para ”Mujer Gestante Çomposición y Estructura Familiar”. 2. 62.

(63) Bibliografı́a [1] Hernández González, Anaisa. ”Base de datos distribuida”, Maestrı́a en Informática Aplicada, CEIS, Ciudad de La Habana, marzo, 2005. [2] S. Rahimi, F. S. Haug, I. C. Society, Distributed Database Management Systems: A Practical Approach, 2010. [3] Kerk F. Kee, Jamie C. McCain, ”What is Good Feedback in Big Data Projects for Cyberinfrastructure Diffusion in e-Science?”, Big Data (Big Data) 2018 IEEE International Conference on, pp. 2804-2812, 2018. [4] Beck, K., Beedle, M., Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M. & Thomas, D. (2001). Manifesto for Agile Software Development. Utah: The Agile Alliance. [5] Ahonen, T., Barret, J. & Golding, P. (2002). Services for UMTS, Creating Killer Applications in 3G. West Sussex: John Wiley & Sons. [6] Michael, Owens, “Introducing SQLite”, In: The Definitive Guide to SQLite. pp 1-16., 2006. [7] Hohensee B. Introducción a Android Studio. Incluye proyectos reales y el código fuente, 2014. [8] Castro, Sandro Javier B. ; Martinez, Oscar S. ; Crespo, Rubén G. ; Espada, Jordán P. ; Garcia, Victor Hugo M.: Coloso: A development environment centered process and intent. Pp 1-6. 2012.. 63.

(64) Referencias Web. [9] Wikipedia. El Tambo (Cauca). [en lı́nea] Disponible en: https://es. wikipedia.org/wiki/El_Tambo_(Cauca). [Accedido: 01-may-2019]. [10] AMAYA BALAGUERA, Y. D. Guı́a metodológica ágil, para el desarrollo de aplicaciones móviles “AEGIS-MD”. Revista de Investigaciones de la UNAD, [s. l.], v. 14, n. 1, p. 97–113, 2015. [en lı́nea] Disponible en: http: //search.ebscohost.com.bdigital.udistrital.edu.co:8080/login. aspx?direct=true&db=a9h&AN=120018713&lang=es&site=ehost-live. [Accedido: 15-may-2019]. [11] CANDELA, C. A.; DUQUE, N. B.; SEPÚLVEDA, L. E. Marco de referencia metodológico para un laboratorio dedicado al desarrollo de aplicaciones para dispositivos móviles. Entre Ciencia e Ingenierı́a, [s. l.], v. 9, n. 17, p. 20–24, 2015. [en lı́nea] Disponible en: http: //search.ebscohost.com.bdigital.udistrital.edu.co:8080/login. aspx?direct=true&db=a9h&AN=109152579&lang=es&site=ehost-live. [Accedido: 15-may-2019]. [12] GASCA MANTILLA, M. C.; CAMARGO ARIZA, L. L.; MEDINA DELGADO, B. Metodologı́a para el desarrollo de aplicaciones móviles. Tecnura, [s. l.], v. 18, n. 40, p. 20–35, 2014. [en lı́nea] Disponible en: http: //search.ebscohost.com.bdigital.udistrital.edu.co:8080/login. aspx?direct=true&db=fap&AN=96159026&lang=es&site=ehost-live. [Accedido: 15-may-2019]. [13] Instituto Colombiano de Bienestar Familiar [en lı́nea] Disponible en: https: //www.icbf.gov.co/el-instituto/sistema-integrado-de-gestion/ formato-ficha-caracterizacion-socio-familiar-version. [Accedido: 08-abr-2019]. [14] Fundación Gimnasio Moderno del Cauca [en lı́nea] Disponible en: https: //fgmc.jimdo.com/mi-colegio/nuestra-institucion/. [Accedido: 14sep-2019]. 64.

(65) BIBLIOGRAFÍA. 65. [15] Fundación Gimnasio Moderno del Cauca [en lı́nea] Disponible en: https: //fgmc.jimdo.com/mi-colegio/nuestra-institucion/. [Accedido: 14sep-2018]..

(66)