Search

The surveyed companies applied hybrid development approaches to specific projects even when company-wide policies for process usage existed. These approaches emerged from the evolution of different work practices and were consistently used regardless of company size or industry sector.

As software organizations try to mitigate operational and technical risk that occurs when using software, there is need to develop a knowledge intensive system to assist team members in mitigating both operational and technical risk. Knowledge mapping in risk mitigation context is in its infancy and has the potential to address both operational and technical risk faced by software organizations. However, as the amount and depth of organizational knowledge increases, it poses some challenges to software organizations. The key challenges for knowledge intensive organizations are how to identify, assimilate, disseminate, and apply these risk knowledge; particularly between different team members in same software development project. Thus this paper proposes a knowledge mapping process model to assist in mitigating risk (operational and technical) that occurs in software organizations. Knowledge mapping is the field within Knowledge Management (KM) that aims to optimize the efficient and effective use of the organization’s knowledge. The mapping process model can support software management teams in measuring and treating risk, thus aiding decision making in software management. Data was collected using semi-structured interview through case study. The interview transcripts were coded and categorized using Nvivo software. Keywords: Knowledge Map, Knowledge Mapping Technique, Risk Mitigation, Software Management, Nvivo

El principal propósito de la investigación ,tiene como objeto desarrollar el estudio para generar estrategias que permitan la interacción de los diversos factores y actores, heterogéneos que influyen en la vigilancia de los sucesos y circunstancias que inciden o modifican la situación de salud de una comunidad, caso de estudio Santander. Por medio del modelo de referencia The Cloud Ecosystem Reference Model se tomaron las etapas fase Preliminar y en la segunda fase de visión de arquitectura orientada a la obtención de requisitos y stakeholders. Para superar este problema, este documento propone una la implementación de la arquitectura de un Ecosistema cloud la cual se evaluó mediante el framework de simulación habientes distribuidos SimGrid. El uso de los ecosistemas cloud en la arquitectura , aplicada a la vigilancia de eventos de salud publica, soportando los problemas de privacidad y protección de datos permite una mejor interacción y acceso seguro de los datos entre los actores, estandarizando y proporcionando el uso e intercambio de los mismos. Lista de Figuras Lista de Tablas 1. Introducción y Objetivos 1 1.1. Planteamiento del Problema y Justificación . . . . . . . . . . . . . . . . 1 1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2.2. Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Estado del Arte 3 2.1. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Grid Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3. Grid Computing en el Mundo . . . . . . . . . . . . . . . . . . . . . . . 3 2.4. Grid computing en Latinoamérica . . . . . . . . . . . . . . . . . . . . . 4 2.5. Grid computing en Colombia . . . . . . . . . . . . . . . . . . . . . . . 5 2.6. Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.7. Tecnologías de La computación . . . . . . . . . . . . . . . . . . . . . . 6 2.7.1. Data centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.7.2. Sistema distribución de archivos . . . . . . . . . . . . . . . . . . 7 2.7.3. framework para aplicaciones distribuidas . . . . . . . . . . . . . 7 2.7.4. Cloud Computing Colombia . . . . . . . . . . . . . . . . . . . . 11 2.7.5. Cloud computing UNAB . . . . . . . . . . . . . . . . . . . . . . 11 2.7.6. Cloud Computing en la Salud . . . . . . . . . . . . . . . . . . . 12 2.8. E-Salud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.8.1. e-Salud (eHealth) . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.8.2. Telemedicina . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.8.3. Tecnología informática en la salud . . . . . . . . . . . . . . . . . 13 2.8.4. Caso de estudio grid computing . . . . . . . . . . . . . . . . . . 17 2.8.5. Cloud cumpiting aplicada a Salud . . . . . . . . . . . . . . . . . 17 2.8.6. Telemedicina en Colombia 18 2.9. Ecosistemas Digitales 18 2.10. Ecosistemas en Salud 18 2.10.1. Ecosistemas Open Source 19 3. Metodología 21 3.1. Metodología 21 3.2. Definición del tipo de investigación 22 3.3. Fases de Proyecto 22 3.3.1. Fase 1 observación y registro de los hechos 22 3.3.2. Fase 2 análisis de lo observado, estableciéndose como consecuencia definiciones claras de cada uno de los conceptos analizados 23 3.3.3. Fase 3 clasificación de los elementos 23 3.3.4. Fase 4 formulación de propuestas derivados del proceso de investigación 23 4. Desarrollo 25 4.1. Sistema de Vigilancia en Salud Publica 25 4.1.1. Fuentes de datos 26 4.1.2. Flujo de la información 26 4.1.3. Recolección de Datos 28 4.1.4. Análisis de datos 29 4.1.5. Investigación e Innovación en Salud Publica 29 4.2. Actores del Sistema 29 4.2.1. Identificación de Actores Clave 30 4.2.2. Restricciones de Acceso de actores 31 4.3. Solución Desarrollada 33 4.3.1. Introducción 33 4.3.2. Visión General 33 4.3.3. Contexto General del Sistema 33 4.3.4. Arquitectura de la Solución 33 4.3.5. Broker 34 4.3.6. Proxy 35 4.3.7. Marketplace 36 4.4. Desarrollo del prototipo basado en el modelo Cloud Computing 39 4.5. Pruebas 40 5. Conclusiones y Trabajos Futuros 43 5.1. Conclusiones 43 5.2. Trabajo Futuro 44 6. Bibliografía 47 Maestría The main purpose of the research is to develop the study to generate strategies that allow the interaction of various factors and actors, heterogeneous that influence the surveillance of events and circumstances that affect or modify the health situation of a community, Santander case study. Through the reference model The Cloud Ecosystem Reference Model, the Preliminary phase and the second phase of the architectural vision were taken, aimed at obtaining requirements and stakeholders. To overcome this problem, this document proposes an implementation of the architecture of a Cloud Ecosystem which was evaluated using the simulation framework of distributed users SimGrid. The use of cloud ecosystems in the architecture, applied to the surveillance of public health events, supporting privacy and data protection problems allows a better interaction and secure access to data between the actors, standardizing and providing the use and exchange thereof.

This document is part of SaaSDK project. This project has been granted by the by the Institut Valencià de Competitivitat Empresarial (IVACE) and the European Regional Development Fund (ERDF). The goal of SaaSDK is the design and implementation of a set of tools, applications and mechanisms to easy the development and management of auto-escaled elastic services. This project is aligned with one of the Instituto Tecnológico de Informática (ITI) researh line focused on elastic software development for the cloud. This manual describes the SDK’s tools designed and implemented in the project and is oriented to elastic software developers., SaaSDK. Project funded by the Valencian Institute of Business Competitiveness (IVACE) and European Union through the European Regional Development Fund (ERDF), within the public grant program adressed to Technological Institutes of the Valencian Community for 2017 with 189.555,60€. File number: IMDEEA/2017/141

Universitat Oberta de Catalunya UOC Maestría

La presente investigación tuvo como objetivo central implementar la metodología B-learning aprovechando las bondades del software libre en el proceso de enseñanza – aprendizaje. El estudio se desarrolló con los estudiantes del grado 10° y 11° de la Institución Educativa Municipal José Félix Jiménez, jornada de la tarde en la asignatura de informática del nivel de educación media. La metodología se inscribió bajo el enfoque mixto de tipo descriptiva, aplicando como técnicas de recolección de la información la observación directa y la revisión documental. La información recolectada permitió establecer cuáles fueron las necesidades y expectativas de formación de la población objeto de estudio, con el fin de que el docente propicie escenarios donde el estudiante se convierta en el protagonista principal y sea él, quien construya sus conocimientos. Asimismo, ayudo al investigador a reconocer cuales fueron las bondades del software libre en el diseño de la metodología B-Learning apoyando al alcance de la visión institucional y de algunas directrices del MEN. La principal conclusión del proyecto fue que el software libre permitió crear escenarios de innovación en los procesos de enseñanza-aprendizaje, al igual que, visualizaron la transversalidad de la herramienta con otras áreas de formación. Universitat Oberta de Catalunya UOC INTRODUCCIÓN 11 1. PROBLEMA 13 1.1 SURGIMIENTO DEL PROBLEMA 13 1.2 FORMULACIÓN DEL PROBLEMA 15 1.3 OBJETIVOS 15 1.3.1 Objetivo general 15 1.3.2 Objetivos específicos 15 1.4 JUSTIFICACIÓN 16 2. MARCO REFERENCIAL 19 2.1. ESTADO DEL ARTE 19 2.1.1 A nivel internacional 19 2.1.2 A nivel nacional 23 2.1.3 A nivel regional 26 2.2. MARCO TEÓRICO 27 2.2.1 Procesos de enseñanza – aprendizaje con TIC 27 2.2.2 La metodología B-learning dentro del proceso de formación 29 2.2.3 Software Libre 31 2.3. MARCO CONCEPTUAL 36 2.3.1 Entorno virtual de aprendizaje (EVA). 36 2.3.2 Ambiente virtual de aprendizaje (AVA). 37 2.3.3 Objeto virtual de aprendizaje (OVA). 40 2.3.4. Enseñanza de la informática. 42 2.4. MARCO LEGAL 44 2.5 MARCO CONTEXTUAL 45 3. MARCO METODOLOGICO 49 3.1. TIPO DE INVESTIGACIÓN 49 3.2. POBLACIÓN Y MUESTRA 50 3.3. TÉCNICAS E INSTRUMENTOS DE RECOLECCIÓN DE INFORMACIÓN 51 3.3.1. Observación directa 51 3.3.2 Revisión documental 51 3.3.3 Encuesta 52 3.4. DESCRIPCIÓN DE ACTIVIDADES 52 4. RESULTADOS DE LA INVESTIGACIÓN 54 4.1. NECESIDADES Y EXPECTATIVAS DE FORMACION 55 4.2. BONDADES DEL SOFWARE LIBRE EN LA IMPLEMENTACION DE LA METODOLOGIA B-learning 61 4.3. DISEÑO E IMPLEMENTACION DE LA METODOLOGÍA B-LEARNING UTILIZANDO EL SOFTWARE LIBRE 65 4.3.1 Diseño 65 4.3.2 Implementación 69 5. CONCLUSIONES 93 6. RECOMENDACIONES 95 REFERENCIAS BIBLIOGRÁFICAS 96 Maestría The main objective of this research was to implement the B-learning methodology, taking advantage of the benefits of free software in the teaching-learning process. The study was developed with the students of the 10th and 11th grade of the José Félix Jiménez Municipal Educational Institution, afternoon session in the computer science subject at the level of secondary education. The methodology was registered under the qualitative approach of descriptive type, applying as techniques of information collection direct observation and documentary review. The information collected allowed establishing what were the needs and training expectations of the population under study, in order that the teacher promotes scenarios where the student becomes the main protagonist, being he, who builds their knowledge. Likewise, the student helped the researcher to recognize the benefits of free software in the design of the B-Learning methodology, supporting the scope of the institutional vision and of some MEN guidelines. The main conclusion of the project was that free software allowed the creation of scenarios of innovation in the teaching-learning processes, as well as, they visualized the transversality of the tool with other training areas.

El desarrollo del presente trabajo se basa en la necesidad que tiene las entidades públicas de contar con un diseño de un curso virtual, para la formación institucional de capacidades de proyectos de inversión pública, bajo la metodología del marco lógico integrada a las áreas e-learning y dinámica de sistemas. Aplicando las metodologías antes mencionadas y apoyadas en herramientas de software libre. La utilización del software libre por parte del Estado colombiano es poca, falta mucho camino por recorrer principalmente por el temor existente de cambiar las plataformas tradicionales. Vale la pena destacar la decisión de la Superintendencia de Servicios Públicos de migrar a software libre. Este proyecto se llevó a cabo con todas las formalidades licitatorias, con resultados de contexto social como es la liberación bajo la licencia GNU/GPL del software de Gestión Documental y de Procesos llamado Orfeo. Por tal razón, el objetivo de crear una propuesta para la creación de un curso virtual enfocado en Software Libre en las entidades públicas, para la formulación de proyectos de inversión. El actual estudio ha logrado identificar las experiencias de universidades europeas con este tipo de cursos en software libre, encontrando así el mejor pensum de estudio-aprendizaje. Además propone la creación de un Aula Virtual que permitirá aplicar la metodología E-learning. En este proyecto se proporciona una solución en la elección de las personas idóneas para ejecutar los proyectos de inversión pública, basados en la metodología marco lógico y la dinámica de sistemas. Perfiles profesionales para llevar a cabo esta tarea, se ha realizado un análisis de diferentes plataformas E-learning y de sus capacidades de extensión. Como resultado de este análisis, se ha determinado que la plataforma claroline es la mejor para desarrollar dicha funcionalidad. Universitat Oberta de Catalunya UOC 1. MARCO DE REFERENCIA 5 1.1 MARCO HISTÓRICO 5 1.2 MARCO CONCEPTUAL 10 1.2.1. Dinámica de Sistemas. 10 1.2.2. Modelamiento 12 2. DISEÑO METODOLÓGICO 14 2.1 MÉTODO DEL MARCO LÓGICO 14 2.2 GESTIÓN DE PROYECTOS DE INVERSIÓN SOCIAL 16 2.3 LA CONTEXTUALIZACIÓN EN LOS PROYECTOS DE INVERSIÓN SOCIAL 17 2.4 MATRIZ DE MARCO LÓGICO CON DINAMICA DE SISTEMAS 18 3. RESULTADOS 23 3.1 DIAGNOSTICO DE NECESIDADES DE FORMACION EN LAS INSTITUCIONES PUBLICAS LOCALES 23 3.1.1 Contextualización 23 3.1.2 Instrumento de recolección de información 24 3.2. DISEÑO DE CONTENIDOS DEL CURSO 26 3.2.1 Introducción al Curso 26 3.2.2 Unidad 1. El Ciclo de Vida de los Proyectos de Inversión Pública 27 3.2.3 UNIDAD 2. REGULACIONES COLOMBIANAS PARA LA GESTIÓN PÚBLICA 34 3.2.4 UNIDAD 3. El Marco Lógico de Proyectos de Inversión Pública 49 3.3. IMPLEMENTACIÓN DEL CURSO DISEÑADO EN LA PLATAFORMA LIBRE CLAROLINE 77 3.3.1 Una plataforma de código abierto 78 3.3.2 Comparación de la plataforma Claroline con la plataforma MOODLE 81 3.3.3 Instalación de Claroline. 84 3.3.2 Manual del estudiante del curso 90 4. CONCLUSIONES 94 5. RECOMENDACIONES 95 6. BIBLIOGRAFÍA 96 Maestría The development of this work is based on the need for public entities to have a virtual course design for the institutional training of public investment projects under the methodology of the logical framework integrated into the e-learning and dynamic areas Of systems. Applying the methodologies mentioned above and supported by free software tools. The use of free software on the part of the Colombian State is little necessary a long way to go mainly due to the existing fear of changing the traditional platforms. It is worth noting the decision of the Superintendent of Public Services to migrate to free software. This project was carried out with all the tendering formalities, with results of social context such as the release under the GNU / GPL license of Documentary and Process Management software called Orfeo. For this reason the objective of creating a proposal for the creation of a virtual course focused on Free Software in the public entities for the formulation of investment projects. The current study has managed to identify the experiences of European universities with this type of courses in free software, thus finding the best study-learning pensum. It also proposes the creation of a Virtual Classroom that will allow the application of the E-learning methodology. This project provides a solution in choosing the right people to execute public investment projects based on the logical framework methodology and system dynamics. To carry out this task, an analysis of different E-learning platforms and their extension capacities has been carried out. As a result of this analysis, it has been determined that the claroline platform is the best to develop such functionality.

Software deficiencies are minimized by utilizing recommended software development and quality assurance practices. However, these recommended practices (i.e., quality practices) become ineffective if software professionals purposefully ignore them. Conducting a systematic literature review (n = 4,838), we discovered that only a small number of previous studies, within software engineering and information systems literature, have investigated the omission of quality practices. These studies explain the omission of quality practices mainly as a result of organizational decisions and trade-offs made under resource constraints or market pressure. However, our study indicates that different aspects of this phenomenon deserve further research. In particular, future research must investigate the conditions triggering the omission of quality practices and the processes through which this phenomenon occurs. Especially, since software development is a human-centric phenomenon, the psychological and behavioral aspects of this process deserve in-depth empirical investigation. In addition, futures research must clarify the social, organizational, and economical consequences of ignoring quality practices. Gaining in-depth theoretically sound and empirically grounded understandings about different aspects of this phenomenon enables research and practice to suggest interventions to overcome this issue.

This document is part of SaaSDK project. This project has been granted by the by the Institut Valencià de Competitivitat Empresarial (IVACE) and the European Regional Development Fund (ERDF). The goal of SaaSDK is the design and implementation of a set of tools, applications and mechanisms to easy the development and management of auto-escaled elastic services. This project is aligned with one of the Instituto Tecnológico de Informática (ITI) researh line focused on elastic software development for the cloud. This manual describes the Dashboard web application for managing services deployed in an ECloud stamp., SaaSDK. Project funded by the Valencian Institute of Business Competitiveness (IVACE) and European Union through the European Regional Development Fund (ERDF), within the public grant program adressed to Technological Institutes of the Valencian Community for 2017 with 189.555,60€. File number: IMDEEA/2017/141

This document is part of SaaSDK project. This project has been granted by the by the Institut Valencià de Competitivitat Empresarial (IVACE) and the European Regional Development Fund (ERDF). The goal of SaaSDK is the design and implementation of a set of tools, applications and mechanisms to easy the development and management of auto-escaled elastic services. This project is aligned with one of the Instituto Tecnológico de Informática (ITI) researh line focused on elastic software development for the cloud. This manual describes ECloud components can be developed using TypeScript or Scala., SaaSDK. Project funded by the Valencian Institute of Business Competitiveness (IVACE) and European Union through the European Regional Development Fund (ERDF), within the public grant program adressed to Technological Institutes of the Valencian Community for 2017 with 189.555,60€. File number: IMDEEA/2017/141

SaaSDK (Tools and services for the development and management of software as a service on a PaaS) is a project funded by the Valencian Institute for Business Competitiveness (IVACE) and the European Union through the European Regional Development Fund (ERDF). The general objective of the project is to facilitate the process of software development and management as a service deployed on a PaaS platform to companies in the ICT sector. This document is a report, within the scope of the transfer and promotion of results, that compiles technology newsletters generated in the context of the project that allow the research team involved to be informed about the latest developments that may affect the results of the research., SaaSDK. Project funded by the Valencian Institute of Business Competitiveness (IVACE) and European Union through the European Regional Development Fund (ERDF), within the public grant program adressed to Technological Institutes of the Valencian Community for 2017 with 189.555,60€. File number: IMDEEA/2017/141

This document is part of SaaSDK project. This project has been granted by the by the Institut Valencià de Competitivitat Empresarial (IVACE) and the European Regional Development Fund (ERDF). The goal of SaaSDK is the design and implementation of a set of tools, applications and mechanisms to easy the development and management of auto-escaled elastic services. This project is aligned with one of the Instituto Tecnológico de Informática (ITI) researh line focused on elastic software development for the cloud. This deliverable is part of the PT3 work package "Dissemination", which aims to disseminate the scientific and technical results of the project, once the dissemination strategy has been defined at the beginning of the project, the results of the different dissemination activities carried out continuously have been evaluated. out and adapting the plan according to the results of it, SaaSDK. Project funded by the Valencian Institute of Business Competitiveness (IVACE) and European Union through the European Regional Development Fund (ERDF), within the public grant program adressed to Technological Institutes of the Valencian Community for 2017 with 189.555,60€. File number: IMDEEA/2017/141

A partir de la necesidad que tienen las entidades, en este caso las Instituciones Educativas, por mejorar sus procesos de gestión en las áreas de Tecnología, se hace imperativo explorar un camino para implementar mejores procesos para de esta manera ofrecer mejores servicios. Es así como esta necesidad hace que piense en ITIL, como un código de buenas prácticas dirigidas a alcanzar esa meta. Se formula un diseño para la implementación de ITIL en una Institución de Educación de básica primaria, secundaria y media técnica, en el cual se describe los pasos a seguir en la implementación de ITIL para el mejoramiento en la gestión de inventario e incidentes apoyados con la aplicación de libre acceso GLPI. Las fases definidas en el modelo comprenden las siguientes: 1. Levantamiento de información y definir el estado actual de cómo se realizan las cosas, 2. Diseño, modelado y definición de estructura, 3.Parametrizacion del sistema y pruebas de funcionalidad, 4. Evaluación de lo implementado (percepción del usuario). Con el fin de realizar la validación del diseño propuesto se hizo la implantación en una Institución Educativa real, y de esta manera se pudo evaluar su aplicabilidad. Apoyados en la aplicación GLPI y con conocimientos básicos en ITIL se logra obtener un diseño con lineamientos claros que llevan sin duda al mejoramiento de los procesos en este caso el de Gestión de Activos del Servicio (inventario de TI) y Gestión de Incidencias. Universitat Oberta de Catalunya UOC INTRODUCCIÓN 3 1. PROBLEMÁTICA 6 1.1. DESCRIPCIÓN DEL PROBLEMA 6 1.2. FORMULACIÓN DEL PROBLEMA 7 1.3. JUSTIFICACIÓN 7 1.3.1. Beneficios generales 8 1.3.2. Beneficios para la Institución 8 1.4. OBJETIVOS 9 1.4.1. Objetivo General 9 1.4.2. Objetivos Específicos 9 1.5. MARCO DE REFERENCIA 10 1.5.1. Antecedentes. 10 1.6. MARCO TEÓRICO 17 1.6.1. ITIL 17 1.6.2. XAMPP 30 2. DISEÑO METODOLÓGICO 32 2.1. RESUMEN 32 2.2. CONCEPTOS CLAVE 32 2.3. DESCRIPCIÓN DE ACTIVIDADES 32 2.4. RECURSOS 34 2.4.1. Recursos Humanos 35 2.4.2. Recursos Físicos y Tecnológicos 35 3. ANÁLISIS DE GESTIÓN E INCIDENTES 37 3.1. FASE 1 38 3.2. FASE 2 45 4. IMPLEMENTACIÓN DE GESTIÓN E INCIDENTES 54 4.1. FASE 3 54 4.1.1. Instalación De Xampp 56 4.1.2. Configuración De Xampp 56 4.1.3. Instalación De GLPI 58 4.1.4. Configuración De GLPI 60 4.1.5. Registro De Incidencias En GLPI 65 5. ANÁLISIS, DEL IMPACTO DE GESTIÓN E INCIDENTES 75 5.1. FASE 4 75 6. CONCLUSIONES 82 7. RECOMENDACIONES 84 BIBLIOGRAFÍA 85 ANEXOS 87 Maestría Based on the need for entities, in this case Educational Institutions, to improve their management processes in the areas of Technology, it is imperative to explore a way to implement better processes in order to offer better services. This is how this need makes me think of ITIL as a code of good practices aimed at achieving that goal. A design is formulated for the implementation of ITIL in an Educational Institution of basic primary, secondary and technical secondary, which describes the steps to follow in the implementation of ITIL for the improvement in the management of inventory and incidents supported with the GLPI free access application. The phases defined in the model include the following: 1. Gathering of information and define the current state of how things are done, 2. Design, modeling and definition of structure, 3. Parameterization of the system and functionality tests, 4. Evaluation of what has been implemented (user perception). In order to carry out the validation of the proposed design, it was implemented in a real Educational Institution, and in this way its applicability could be evaluated. Supported by the GLPI application and with basic knowledge in ITIL, it is possible to obtain a design with clear guidelines that undoubtedly lead to the improvement of processes in this case, Service Asset Management (IT inventory) and Incident Management.

El presente trabajo se enmarca en el campo de conocimiento denominado análisis de patrones de puntos que, aunque no es un área de estudio nueva, mantiene su vigencia al permitir analizar diferentes tipos de fenómenos desde una perspectiva espacial por medio de diversos métodos. Entre los métodos de análisis de patrones de puntos existentes se encuentran algunos enfocados en el análisis sobre espacios de redes, definidos como espacios lineales contenidos dentro de los espacios euclidianos en dos dimensiones. Un ejemplo de espacio de redes es el formado por la red vial de una ciudad o región. Sobre estos espacios de redes se pueden realizar análisis de fenómenos como accidentes de tránsito y crímenes. El desarrollo del presente trabajo se divide en dos etapas. La primera etapa se centra en la creación de una herramienta software que implementa dos métodos de análisis de patrones de puntos en espacios de redes, la función K para redes y NetKDE. Junto al proceso de desarrollo de los métodos se cubren temas de apoyo como la manipulación de archivos KML, la revisión y cierre de los nodos de red y la proyección de los puntos de eventos sobre las líneas de una red. La segunda etapa se ocupa de la aplicación de los métodos implementados sobre los datos de accidentes de tránsito ocurridos en las ciudades de Bucaramanga (Colombia) y Barcelona (España) durante el año 2014, y el análisis posterior de los resultados obtenidos RESUMEN 9 INTRODUCCIÓN 10 1. PLANTEAMIENTO DEL PROBLEMA 11 2. ESTADO DEL ARTE 13 2.1. ESPACIOS EUCLIDIANOS DE DOS DIMENSIONES 13 2.2. ESPACIOS DE REDES 14 2.3. HERRAMIENTAS COMPUTACIONALES 15 2.4. ANÁLISIS DE PATRONES DE PUNTOS – PPA 16 2.4.1. Kernel Density Estimator – KDE 17 2.4.2. La Función K 18 2.5. ANÁLISIS DE PATRONES DE PUNTOS EN REDES 21 2.5.1. NetKDE 21 2.5.2. Función K para Redes 23 3. OBJETIVOS 26 3.1. OBJETIVO GENERAL 26 3.2. OBJETIVOS ESPECÍFICOS 26 4. METODOLOGÍA DE LA INVESTIGACIÓN 27 4.1. DEFINICIÓN DE LA ARQUITECTURA DE DESARROLLO DE SOFTWARE 27 4.2. DEFINICIÓN DE CASOS DE USO 28 4.3. DESCRIPCIÓN DE CASOS DE USO 29 4.3.1. Visualizar Datos Geográficos 29 4.3.2. Cargar Archivo de Red 30 4.3.3. Cargar Archivo de Eventos 32 4.3.4. Realizar Cierre de Nodos 35 4.3.5. Realizar Proyección de Puntos 37 4.3.6. Generar Distribuciones Aleatorias de Puntos 39 4.3.7. Calcular Valores de Función K para Redes 41 4.3.8. Calcular Densidades de NetKDE 44 4.4. ALISTAMIENTO DE DATOS 47 5. ANÁLISIS DE RESULTADOS 52 5.1. HALLAZGOS EN LA IMPLEMENTACIÓN DE LA HERRAMIENTA SOFTWARE 52 5.1.1. Módulo de Carga de Archivos 52 5.1.2. Procesos de Normalización de Datos 54 5.1.3. Módulo de Función K para Redes 58 5.1.4. Módulo de NetKDE 60 5.1.5. Módulo de Visualización de Resultados Geográficos 61 5.1.6. Módulo de Creación y Verificación de Base de Datos Relacional Asociada 63 5.2. ANÁLISIS DE RESULTADOS DE LA APLICACIÓN DE LOS MÉTODOS IMPLEMENTADOS 64 5.2.1. Función K para Redes 64 5.2.2. NetKDE 68 6. CONCLUSIONES 75 7. RECOMENDACIONES 79 BIBLIOGRAFÍA 80 ANEXO A. ALGORITMO EN AVENUE PARA LA LOCALIZACIÓN DE DIRECCIONES 83 ANEXO B. MANUAL DE USUARIO 85 B.1. MENÚ CONFIGURACIÓN (CONFIGURATION) 85 B.1.1. Opción Base de datos (Database) 85 B.2. MENÚ CARGA (UPLOAD) 86 B.2.1. Opción cargar archivos de red (Upload network files) 86 B.2.2. Opción cargar archivos de eventos (puntos) [Upload event (point) files] 87 B.3. MENÚ PROCESOS (PROCESSES) 88 B.3.1. Opción Función K para redes (Network K function) 88 B.3.2. Opción NetKDE 91 Maestría The present work is framed in the field of knowledge called point pattern analysis, although it is not a new area of study, it is still valid by allowing the analysis of different phenomena from a spatial perspective using diverse methods. Among the existing point pattern analysis methods there are some focused on the analysis on network spaces, defined as linear spaces contained within the two dimensions Euclidean spaces. An example of network space is the one acquiesced by the road network in a city or region. Over these network spaces there can be made analysis of phenomena such as traffic accidents and crimes. The development of the present work is divided into two stages. The first stage focuses on the creation of a software application that implements two methods of point pattern analysis in network spaces, the network K function and NetKDE. Alongside the method development process, support topics are covered, those topics include manipulating KML files, reviewing and closing network nodes, and projecting event points over network lines. The second stage focuses on the application of the implemented methods on the data of traffic accidents occurred in the cities of Bucaramanga (Colombia) and Barcelona (Spain) during 2014, and the later analysis of the results obtained

The software development industry is dominated by a myriad of small- and medium-sized enterprises (SMEs). The main goal of this chapter is to provide a characterization of SMEs based on previous studies. It also includes an overview of a number of software process models and software process improvement (SPI) models, which are aimed at assisting SMEs in improving the way they develop software. Furthermore, this chapter discusses the extent of SPI approaches published in the literature as a way to understand the particular context and some of the major challenges faced. From there, we propose an approach to integrate software process practices. This proposal is based on the results of our study on this topic carried out in small software companies. It is focused on what small organizations could actually do, more than on what they are currently practicing.

La analítica de datos masivos ha disparado las iniciativas hacia la implementación de aplicaciones de Big Data en muchas organizaciones de todos los sectores económicos del país. La planeación y despliegue de estrategias comerciales exitosas, procesos adecuados de segmentación de clientes, implementación de políticas de fidelización, gestión del conocimiento y la unificación de la información son algunos de los aspectos más relevantes para empresas que buscan mejorar su desempeño comercial a través de la explotación de su activo más importante – la información-. Los medios impresos, por su naturaleza, son constantemente llamados a implementar herramientas que le permitan mejorar no solo el conocimiento del cliente sino sus procesos de gestión de información. En el presente estudio se hace una revisión de las necesidades de adopción de nuevas fuentes de información en procesos de venta, transformación y unificación de las diferentes fuentes de datos existentes en la empresa, se plantea una arquitectura tecnológica que soporte dichos cambios basada en la implementación de tecnologías Big Data, modelos de procesos de unificación de la información y de ventas, y a su vez se propone un plan de implementación que brinde a Vanguardia Liberal las fortalezas necesarias para afrontar procesos de analítica de datos masivos en el sector de los medios impresos. RESUMEN ............................................................................................................. 13 GLOSARIO ............................................................................................................ 14 INTRODUCCIÓN ................................................................................................... 17 1. MARCO METODOLÓGICO ............................................................................... 18 1.1 Planteamiento del Problema ............................................................................ 18 1.2 Justificación ..................................................................................................... 18 1.3 Pregunta De Investigación ............................................................................... 19 1.4 Objetivos De La Investigación .......................................................................... 19 1.4.1 Objetivo General ........................................................................................... 19 1.4.2 Objetivos Específicos .................................................................................... 20 1.5 Resultados Esperados ..................................................................................... 20 1.6 Metodología ..................................................................................................... 20 1.7 Etapas de la Investigación ............................................................................... 21 1.8 Actividades ....................................................................................................... 21 2. MARCO TEÓRICO ............................................................................................ 26 2.1 Big Data ........................................................................................................... 26 2.1.1 Las 3 “V” ....................................................................................................... 27 2.1.2 Tecnologías Big Data .................................................................................... 28 2.2 Cliente .............................................................................................................. 29 2.3 Estrategia ......................................................................................................... 30 2.4 Segmentación .................................................................................................. 30 2.5 Activos De Información .................................................................................... 31 3. DIAGNÓSTICO DEL ESTADO ACTUAL ........................................................... 33 3.1 Arquitectura ...................................................................................................... 33 3.1.1 Publicidad ..................................................................................................... 33 3.1.2 Circulación .................................................................................................... 34 3.1.3 Administración .............................................................................................. 36 3.1.4 Actores Externos ........................................................................................... 36 8 3.2 Procesos De Venta .......................................................................................... 37 3.2.1 Proceso de venta de publicidad .................................................................... 37 3.2.2 Proceso de Venta en servicio al Cliente ....................................................... 39 3.2.3 Proceso de venta suscripciones ................................................................... 40 3.2.4 Proceso de Validación de la información de los Actores externos ................ 41 4. IDENTIFICACIÓN DE REQUERIMIENTOS....................................................... 44 4.1 Encuesta .......................................................................................................... 44 4.1.1 Instrumento de recolección de la información ............................................... 44 4.2 Resultados ....................................................................................................... 46 4.3 Análisis de los resultados................................................................................. 46 4.4 Conclusiones de los Resultados ...................................................................... 48 5. TECNOLOGIAS BIG DATA ............................................................................... 50 5.1 Principales soluciones tecnológicas de Big Data ............................................. 50 5.2 Tipos de Soluciones Big Data .......................................................................... 54 5.2.1 Distribuciones ............................................................................................... 55 5.2.2 Appliance ...................................................................................................... 55 5.2.3 Cloud ............................................................................................................ 56 5.2.4 Comparación de Soluciones ......................................................................... 56 5.3 Recomendaciones Gartner 2016 ..................................................................... 59 5.3.1 Business Intelligence y Business Analytics ................................................... 59 5.3.2 Almacenamiento y gestión de bases de datos de Analytics ......................... 60 5.4 Evaluación Distribuciones ................................................................................ 61 5.5 Evaluación de Herramientas de Bussiness Intelligence. .................................. 65 5.6 Consideraciones Técnicas. .............................................................................. 69 6. ARQUITECTURA Y MODELOS PROPUESTOS ............................................... 71 6.1 Arquitectura de procesamiento de Big Data propuesta por Krishnan Krish. .... 71 6.2 Arquitectura de Big Data propuesta por Bob Marcus. ...................................... 73 6.3 Arquitectura de Big Data propuesta por Microsoft. .......................................... 75 6.4 Comparación de Arquitecturas Krishnan, Marcus y Microsoft.......................... 77 6.5 Arquitectura Propuesta .................................................................................... 79 6.6 Diagramas de Arquitecturas Propuestas ......................................................... 80 6.6.1 Diagrama de Arquitectura Deseado .............................................................. 81 6.6.2 Diagrama de Arquitectura Realizable ........................................................... 81 6.7 Modelos Propuestos ........................................................................................ 84 6.7.1 Modelo Integrador de Información ................................................................ 85 6.7.2 Modelo de Ventas unificado .......................................................................... 87 7. PLAN DE IMPLEMENTACIÓN .......................................................................... 91 7.1 Actividades ....................................................................................................... 91 7.2 Diagrama de Gantt ........................................................................................... 94 7.3 Discusión viabilidad técnica ............................................................................. 95 8. CONCLUSIONES .............................................................................................. 97 BIBLIOGRAFÍA ...................................................................................................... 99 ANEXOS .............................................................................................................. 109 Maestría Big data analytics has triggered initiatives towards the implementation of Big Data applications in many organizations in all economic sectors of the country. The planning and deployment of successful business strategies, adequate customer segmentation processes, implementation of loyalty policies, knowledge management and the unification of information are some of the most relevant aspects for companies seeking to improve their commercial performance through exploitation of its most important asset - information. Print media, by their nature, are constantly called upon to implement tools that allow them to improve not only customer knowledge but also their information management processes. In this study, a review is made of the needs for the adoption of new information sources in sales processes, transformation and unification of the different data sources existing in the company, a technological architecture that supports said changes based on implementation is proposed. of Big Data technologies, information unification and sales process models, and in turn an implementation plan is proposed that provides Vanguardia Liberal with the necessary strengths to face massive data analytics processes in the printed media sector.

El desarrollo de software bajo el paradigma de Programación Orientada a Objetos está confrontado por un modelo de almacenamiento de datos de tipo relacional ampliamente aceptado por la industria desde hace casi treinta años. Lo anterior, plantea dos escenarios diferentes para modelar la estructura de la información: para almacenarla (base de datos) y/o tenerla en memoria (objetos), lo que conlleva a que los desarrolladores de software traten de mitigar a través de conversiones entre tipos o utilizando herramientas intermedias como el mapeo de objetos relacional, lo cual traen ventajas y desventajas sobre el proceso de desarrollo, el rendimiento de las aplicaciones y la mantenibilidad. Con las consideraciones anteriores, se propuso desarrollar una implementación de software que permitiera almacenar los objetos de la aplicación bajo un motor de almacenamiento no relacional o NoSQL, para lo cual se selecciono MongoDB que gracias a su estructura dinámica de documentos basada en el formato JSON se adapto a las definiciones de los objetos. El formato de documentos (Json) utilizado por el motor de datos MongoDB permitió almacenar los objetos definidos por los usuarios del Framework de tal forma que en una sola entidad se tiene organizada toda información, y no se segmenta como en el modelo de datos relacional, se respeta la definición inicial del objeto modelado, a partir de esta premisa, consideramos que se debe generar en mejoras de rendimiento de acceso a los datos, ya que la información estará ubicada en una misma colección. Universitat Oberta de Catalunya UOC RESUMEN 10 INTRODUCCIÓN 14 1. REVISIÓN BIBLIOGRÁFICA O MARCO TEÓRICO 17 2. PLANTEAMIENTO DEL PROBLEMA Y JUSTIFICACIÓN 29 3. OBJETIVOS PLANTEADOS 34 4. MÉTODO DE INVESTIGACIÓN 35 5. RESULTADOS DE LA INVESTIGACIÓN 37 5.1. Actividades 37 5.4. Funcionamiento del Framework. 42 5.5. Diseño e implementación del Framework 42 5.5.1. Casos de Uso 44 5.5.3. Diagrama de Paquetes 48 5.5.5. Interfaz grafica de usuario 50 6. ANÁLISIS DE LA INFORMACIÓN 57 6.1. Herramientas de tipo mapeo objeto-relacional (ORM) 57 6.2. Conceptos de Bases de Datos NoSQL 61 6.3. Framework desarrollado 63 7. CONCLUSIONES 65 8. RECOMENDACIONES Y TRABAJOS FUTUROS 67 9. REFERENCIAS BIBLIOGRAFICAS 68 Maestría Software development under the Object-Oriented Programming paradigm is confronted by a relational-type data storage model widely accepted by the industry for almost thirty years. The above raises two different scenarios to model the structure of the information: to store it (database) and / or have it in memory (objects), which leads software developers to try to mitigate through conversions between types or using intermediate tools such as relational object mapping, which bring advantages and disadvantages to the development process, application performance and maintainability. With the above considerations, it was proposed to develop a software implementation that would allow the application's objects to be stored under a non-relational or NoSQL storage engine, for which MongoDB was selected that thanks to its dynamic document structure based on the JSON format I adapt to the definitions of the objects. The document format (Json) used by the MongoDB data engine allowed to store the objects defined by the Framework users in such a way that all information is organized in a single entity, and it is not segmented as in the relational data model, The initial definition of the modeled object is respected, based on this premise, we consider that it should be generated in performance improvements for data access, since the information will be located in the same collection.

El presente trabajo de grado se realiza con el fin de aportar al proceso de selección de una herramienta de software libre para la gestión documental en la Universidad de Nariño, mediante la aplicación de un modelo de evaluación, se desarrolló bajo el paradigma cuantitativo, con un enfoque empírico-analítico de tipo descriptivo y propositivo. La población objeto de estudio fueron las Universidades públicas en el sur-occidente colombiano, con un muestreo no probabilístico de tipo intencional, seleccionando a la Universidad de Nariño. Como resultado se logró la caracterización del proceso de gestión documental de la Universidad de Nariño, el diseño de un modelo de evaluación de herramientas de software libre para gestión documental a partir del análisis de los distintos modelos existentes, con el que se evaluó las herramientas de software libre de gestión documental, obteniendo a Alfresco Community como la de mayor favorabilidad, la cual fue validada en un ambiente de pruebas, dónde, se logró identificar que esta herramienta puede apoyar en varias de las actividades propuestas en los procesos de un programa de gestión documental. El trabajo permite concluir que en la Universidad de Nariño no existe definido un programa de gestión documental. Se propone un modelo de evaluación de software libre, que se fundamenta en las características de los modelos más usados. La evaluación de Alfresco, Knowledgetree, Nuxeo, Orfeo y Quipux, presenta a la herramienta Alfresco Community con la de mayor valoración en cuanto a los criterios de evaluación. La herramienta Alfresco Community al ser validada en un ambiente de pruebas obtiene una valoración muy alta para el desarrollo de las actividades de la gestión documental en una Institución de Educación Superior de carácter público. Universitat Oberta de Catalunya UOC INTRODUCCIÓN 13 1. ELEMENTOS DEL PROCESO INVESTIGATIVO 18 1.1 ANTECEDENTES Y ESTADO DEL CONOCIMIENTO 18 1.2 TITULO 28 1.3 PROBLEMA DE INVESTIGACIÓN 29 1.3.1 Descripción del problema. 29 1.3.2 Formulación del problema. 30 1.4 OBJETIVOS 30 1.4.1 Objetivo general. 30 1.4.2 Objetivos específicos 30 1.5 JUSTIFICACIÓN 31 1.6 MARCOS DE REFERENCIA 32 1.6.1 Marco teórico 32 1.6.1.1 Gestión documental. 32 1.6.1.2 Herramientas de soporte a la gestión documental. 35 1.6.1.3 Modelos de evaluación de software 39 1.6.1.4 Modelos de evaluación de calidad software libre. 41 1.7 METODOLOGÍA 48 1.7.1 Paradigma, enfoque y tipo de investigación. 48 1.7.2 Línea de investigación. 48 1.7.3 Población y muestra. 48 1.7.4 Proceso de investigación 49 1.7.5 Operacionalización de variables 50 1.8 PRESUPUESTO 53 1.9 CRONOGRAMA 54 1.10 RESULTADOS ESPERADOS 55 2. RESULTADOS 56 2.1 CARACTERIZAR EL PROCESO DE GESTIÓN DOCUMENTAL DE LA UNIVERSIDAD DE NARIÑO 56 2.1.1 Percepciones de la Gestión Documental. 56 2.1.1.1 Planeación. 56 2.1.1.2 Producción. 58 2.1.1.3 Gestión y trámite. 59 2.1.1.4 Organización. 60 2.1.1.5 Transferencia. 61 2.1.1.6 Disposición de documentos. 62 2.1.1.7 Preservación a largo plazo. 63 2.1.1.8 Valoración. 64 2.1.2 Procedimientos unidad de Archivo y Correspondencia de la Universidad de Nariño. 65 2.2 DISEÑAR UN MODELO DE EVALUACIÓN DE HERRAMIENTAS DE SOFTWARE LIBRE PARA GESTIÓN DOCUMENTAL 67 2.2.1 Análisis de los modelos de evaluación de software libre de primera generación. 69 2.2.1.1 Open Source Maturity Model (OSMM) desarrollado por CapGemini. 69 2.2.1.2 Open Source Maturity Model (OSMM) desarrollado por Bernard Golden de Navicasoft. 72 2.2.1.3 Qualification and Selection of Open Source Software QSOS. 74 2.2.1.4 Open Business Readiness Rating, OpenBRR 77 2.2.2 Análisis de los modelos de evaluación de software libre de segunda generación. 79 2.2.2.1 QUALity of Open Source Software – QualOSS. 79 2.2.2.2 QualiPSo Open Source Maturity Model (OMM). 80 2.2.2.3 Software Quality Observatory for Open Source Software (SQO-OSS) 83 2.2.3 Contraste de los modelos. 84 2.2.4 Modelo propuesto. 88 2.2.4.1 Fase 1 - Planeación: 89 2.2.4.2 Fase 2 - Ejecución: 93 2.2.4.3 Fase 3 - Verificación: 93 2.2.4.4 Fase 4 - Selección: 95 2.3 EVALUAR LAS HERRAMIENTAS DE SOFTWARE LIBRE PARA GESTIÓN DOCUMENTAL, MEDIANTE LA APLICACIÓN DEL MODELO DE EVALUACIÓN PROPUESTO 95 2.3.1 Fase 1 – Planeación. 95 2.3.2 Fase 2 – Ejecución. 99 2.3.3 Fase 3 – Verificación. 99 2.3.3.1 Aceptación / Usabilidad 100 2.3.3.2 Administración 102 2.3.3.3 Comunidad 103 2.3.3.4 Eficiencia 104 2.3.3.5 Entrenamiento (Capacitación/Documentación) 104 2.3.3.6 Integración 105 2.3.3.7 Portabilidad 105 2.3.3.8 Software / Producto 106 2.3.3.9 Especificidad 108 2.3.4 Fase 4 – Selección 110 2.4 VALIDAR LA HERRAMIENTA RECOMENDADA RESULTADO DE LA APLICACIÓN DEL MODELO, EN UN ENTORNO DE PRUEBAS 111 3. CONCLUSIONES 115 4. RECOMENDACIONES 117 BIBLIOGRAFÍA 118 Maestría The present degree work is carried out in order to contribute to the selection process of a free software tool for document management at the University of Nariño, through the application of an evaluation model, it was developed under the quantitative paradigm, with a descriptive and purposeful empirical-analytical approach. The population under study were the public universities in the south-west of Colombia, with an intentional non-probabilistic sampling, selecting the University of Nariño. As a result, the characterization of the document management process of the University of Nariño was achieved, the design of an evaluation model of free software tools for document management based on the analysis of the different existing models, with which the tools of free document management software, obtaining Alfresco Community as the one with the highest favor, which was validated in a test environment, where, it was possible to identify that this tool can support several of the activities proposed in the processes of a management program documentary film. The work allows to conclude that at the University of Nariño there is no defined document management program. A free software evaluation model is proposed, which is based on the characteristics of the most used models. The evaluation of Alfresco, Knowledgetree, Nuxeo, Orfeo and Quipux, presents the Alfresco Community tool with the highest evaluation in terms of evaluation criteria. The Alfresco Community tool, when validated in a test environment, obtains a very high rating for the development of document management activities in a public Higher Education Institution.

Esta tesis presenta el diseño de un modelo de arquitectura empresarial para un colegio privado del Floridablanca Santander utilizando un framework de Togaf para plantear un modelo de arquitectura As – Is, ya que la institución no cuenta con un marco referencial referente de arquitectura, con base en este modelo se estudian los procesos institucionales y se seleccionan cuatro procesos que orientados a los objetivos del negocio alineen la institución con el área tecnológica y le ayude a mejorar. Los procesos seleccionados fueron Gobierno escolar, Matriculas, recibos de pensión y registro de notas. Se mostró la adaptabilidad de Togaf utilizando solo las cinco primeras fases del ADM preliminar, Fase A visión de arquitectura, Fase B arquitectura de negocio, Fase C arquitectura de sistema de información datos y aplicaciones, Fase D arquitectura tecnológica, también se plateo la hoja de ruta para la implementación del modelo de arquitectura teniendo en cuenta necesidades de la institución. Durante dichas fases se planteó un modelo de arquitectura To – Be que busca mejorar los proceso seleccionados brindando un mayor apoyo a la institución. Para la elaboración de estas faces se utilizaron diferentes herramientas como UML, Archimete, Bonita y visio. para presentar de forma gráfica cada fase en el modelo de arquitectura As -Is y en el modelo de arquitectura To – Be. 1. ANTECEDENTES 14 2. MARCO CONCEPCTUAL 15 2.1 ESTADO DEL ARTE 15 2.1.1 Historia de la Arquitectura Empresarial 15 2.1.2 Historia de la Educación en Colombia 17 2.2 MARCO CONCEPTUAL 18 2.2.1 Arquitectura Empresarial (EA) 20 2.2.2 Framework 22 2.2.3 Dominios de la Arquitectura Empresarial. 23 2.2.4 The Open Group Architecture Framework (TOGAF) 24 2.2.5 Fases del ADM TOGAF 25 2.2.6 Bussiness Process Model and Notation (BPMN) 29 2.2.7 Ministerio de Educación 29 2.2.8 Secretaria de Educación Departamental 31 2.2.9 Secretaria de Educación Municipal 34 2.2.10 Colegios 36 3. JUSTIFICACION 38 4. OBJETIVOS 39 4.1 OBJETIVO GENERAL 39 4.2 OBJETIVOS ESPECIFICOS 39 5. METODOLOGIA 40 5.1 PRIMER METODO DE ANALISIS 40 5.2 RESULTADOS ESPERADOS 41 5.3 ACTIVIDADES A REALIZAR 41 5.3.1 Objetivo 1 41 5.3.2 Objetivo 2 42 5.3.3 Objetivo 3 42 5.3.4 Objetivo 4 43 6. DESARROLLO 44 7. FASE PRELIMINAR 45 7.1 MODELO ORGANIZACIONAL DE ARQUITECTURA EMPRESARIAL 45 7.1.1 Descripción General 45 7.1.2 Historia 45 7.1.3 Actualidad 46 7.1.4 Organigrama 47 7.1.5 Servicios 47 7.1.6 Misión 48 7.1.7 Visión 48 7.1.8 Mapa de Procesos 49 7.2 ALTO NIVEL EN LA GESTION DEL COMPROMISO 49 7.2.1 Interesados 49 7.3 ACUERDOS DEL ALCANCE 50 7.4 ESTABLECER PRINCIPIOS 50 7.4.1 Principios de Negocio 51 7.4.2 Principios de Datos 53 7.4.3 Principios de Aplicación 54 7.4.4 Principios de Tecnología 56 7.5 ESTRUCTURA DEL GOBIERNO 57 7.5.1 Participantes en el Proyecto 57 7.6 PARTICIPANTES DEL PROYECTO 57 7.7 PERSONALIZACION DEL TOGAF 58 7.7.1 Fase A: La visión de Arquitectura 58 7.7.2 Fase B: Arquitectura de Negocio 59 7.7.3 Fase C: Arquitectura de Sistemas de Información 59 7.7.4 Fase D: Arquitectura de Tecnología 59 8. FASE A: VISION DE ARQUITECTURA 60 8.1 REQUERIMIENTOS DEL NEGOCIO 60 8.2 VISION DE LA ARQUITECTURA 60 8.3 DEFINICIO DE LAS RESTRICCIONES 61 8.4 MATRIZ DE STAKEHOLDERS. 61 8.5 DIAGRAMA CADENA DE VALOR 64 8.6 DIAGRAMA DE CONCEPTO DE LA SOLUCION 64 8.7 PRINCIPIO DE NEGOCIO OBJETIVOS Y MOTIVADORES 64 8.7.1 Principios de Negoio 64 8.7.2 Objetivos de Negocio 65 8.7.3 MOTIVADORES DE NEGOCIO 65 8.8 EVALUAR LAS CAPACIDADES DEL NEGOCIO 66 8.8.1 Escenario de Negocio 1 67 8.8.2 Escenario de Negocio 2 67 8.8.3 Escenario de Negocio 3 68 8.8.4 Escenario de Negocio 4 69 8.9 DEFINICION DE ALCANCE 69 8.9.1 Requerimientos 70 9. FASE B: VISIÓN DE ARQUITECTURA 71 9.1 PRINCIPALES FUNCIONES DEL NEGOCIO 71 9.2 CATALOGOS 74 9.2.1 Catálogo de Procesos 74 9.2.2 Catálogo de la Organización 81 9.2.3 Catálogo Actor 82 9.2.4 Catálogo de Roles 85 9.2.5 Catálogo de Funciones de Negocio 86 9.3 IDENTIFICAR Y DOCUMENTAR LA AQUITECTURA ACTUAL 89 9.3.1 Gobierno Escolar 90 9.3.1.1 Consejo Estudiantil 90 9.3.1.2 Consejo de Padres 100 9.3.1.3 Consejo Académico 107 9.3.1.4. Consejo Directivo 107 9.3.2 Proceso de Matricula 116 9.3.2.1. Entorno Técnico de la Institución 120 9.3.2.2. Identificación del Problema 122 9.3.2.3. Vista del Proceso TO – BE 122 9.3.3 Proceso Entrega Recibos de Pensión 126 9.3.3.1 Entorno Técnico de la Institución 129 9.3.3.2. Identificación del Problema 130 9.3.3.3. Vista del Proceso TO – BE 130 9.3.4 Proceso de Notas 131 9.3.4.1. Entorno Técnico del Problema 134 9.3.4.2. Identificación del Problema 138 9.3.4.3. Vista del Proceso TO – BE 138 9.4 ANALISIS DE BRECHA 144 9.4.1 Análisis de todos los Procesos 145 9.4.2. Proceso Elección Consejo de Estudiantes 146 9.4.3. Proceso Elección Consejo de Padres 148 9.4.4. Proceso Elección Consejo Directivo 149 9.4.5 Proceso de Matricula 151 9.4.6 Proceso de entrega de Recibos de Pensión 153 9.4.7 Proceso de Notas 154 10. FASE C: ARQUITECTURA DEL SISTEMA DE INFORMACIÓN, DATOS Y APLICACIONES 157 10.1. ARQUITECTURA DE DATOS 157 10.1.1. Modelo de Datos AS – IS 157 10.1.2 Modelo de Datos TO – BE 158 10.1.3 Catalogo de Entidades 160 10.1.4. Análisis de la Brecha de Datos 161 10.1.5 Ciclo de Vida de los datos 161 10.1.6. Esquema de Seguridad Datos TO – BE 162 10.1.7. Protección del Código Web 163 10.1.8. Protección de Comunicación TO – BE 163 10.1.9 Roles, Perfiles y Modulos. 164 10.2. ARQUITECTURA DE APLICACIONES 177 10.2.1. Arquitectura de Aplicaciones AS – IS 177 10.2.2 Catalogo de Aplicaciones 177 10.2.3 Catálogos de Componentes TO – BE 179 10.2.3.1. Modelo de Arquitectura TO – BE 179 10.3 ANALISIS DE BRECHA 181 11. FASE D: ARQUITECTURA DE LA TECNOLOGIA 183 11.1 ARQUITECTURA AS – IS 183 11.2 PROPUESTA DE ARQUITECTURA 185 11.3 ANALISIS DE BRECHA 186 12. HOJA DE RUTA 187 CONCLUSIONES 188 REFERENCIAS BIBLIOGRÁFICAS 189 Maestría This thesis presents the design of a business architecture model for a private school in Floridablanca Santander using a framework of Togaf to propose an As - Is architecture model, since the institution does not have a referential frame of reference, based on This model examines the institutional processes and selects four processes that orientate the business objectives to align the institution with the technological area and help it to improve. The processes selected were School Government, Matriculas, pension receipts and record of notes. It was shown the adaptability of Togaf using only the first five phases of the preliminary ADM, Phase A architecture vision, Phase B business architecture, Phase C information system architecture data and applications, Phase D technology architecture, Route for the implementation of the architecture model taking into account the needs of the institution. During these phases, a To - Be architecture model was proposed that seeks to improve the selected processes by providing greater support to the institution. For the elaboration of these faces different tools like UML, Archimete, Bonita and visio were used. To graphically present each phase in the As -Is architecture model and the To-Be architecture model.

Although traceability information is vital to many software engineering activities, agile development approaches rarely use it because of the extra effort required. In this industry case study, the authors report the results of applying their lightweight semiautomated method that integrates traceability into software architecture developed with an agile process like Scrum.

Actualmente en Colombia se han venido adelantando iniciativas y estrategias desde diferentes entes gubernamentales para la mejora de la calidad en la prestación de los servicios a los ciudadanos, estas estrategias están encaminadas a fortalecer ciertos sectores de la sociedad, entre ellos el sector de salud. Un área de especial interés es el desarrollo de iniciativas que tienen como propósito promover sistemas de información de salud más integrados y colaborativos, donde el intercambio de información de pacientes puede no solo mejorar la eficiencia en la prestación del servicio, sino también ayudar a mejorar la calidad de vida de los pacientes y en muchos casos prevenir y evitar errores médicos que pueden resultar en consecuencias lamentables. Resalta entonces que un ecosistema de la prestación de servicios de salud ideal sea un entorno de comunicación y colaboración en tiempo real, donde la interoperabilidad juega un importante papel. En este sentido, debe entenderse la interoperabilidad entre sistemas de información como un conjunto de características técnicas, semánticas y procedimentales que habilitan el intercambio de información entre varios sistemas. Este intercambio debe darse teniendo en cuenta que las partes involucradas reconozcan y utilicen un lenguaje en común acuerdo. Pero si bien la solución son sistemas de información más interconectados e interoperables entre sí, también es cierto que debido a la gran pluralidad de actores en el sistema de salud existen una gran variedad de herramientas y soluciones de tecnología que soportan diferentes procesos de este sector cada uno de ellos utilizando diferentes estándares. Es por esto que las soluciones de interoperabilidad deben propender por herramientas que faciliten la intercomunicación entre sistemas sin que esto implica rediseños que pueden ser costosos y demorados. En este sentido, el siguiente trabajo busca diseñar y desarrollar un modelo arquitectónico de interoperabilidad de historias clínicas que se ajuste a las necesidades del Hospital Universitario de Santander; dicho modelo sustentando por anteriores trabajos y arquitecturas propuestas, pretende utilizar el estándar HL7 para el intercambio de documentos clínicos y una arquitectura de software orientada a servicios, lo cual facilitará la independencia sobre las tecnologías utilizadas y garantizará la capacidad de intercambio con otros sistemas de información de salud. Este modelo permitirá adaptar y construir un esquema arquitectónico que permita la extracción, conversión y habilitación de la información de historias clínicas de los pacientes en un escenario local, haciendo uso de estándares ampliamente validados y utilizados en el sector 1. RESUMEN 11 2. INTRODUCCION 13 3. REVISION BIBLIOGRÁFICA 15 3.1 Antecedentes Historia Clínica Electrónica 15 3.1.1 La historia clínica electrónica en Estados Unidos 15 3.1.2 La historia clínica electrónica en Colombia 21 3.2 Estándares Historia Clínica Electrónica 37 3.2.1 OpenEHR 37 3.2.2 ISO/TC 215 39 3.2.3 HL7 (Health Level Seven) 40 3.2.4 C-CDA o Guías de Implementación para documentos clínicos 47 3.3 Arquitectura Orientada a Servicios 48 3.4 Interoperabilidad 50 3.4.1 Interoperabilidad en Salud 52 3.5 Marco Legal 55 3.5.1 Decreto 1078 de 2015. 55 3.5.2 Ley estatutaria 1581 de 2012 56 3.5.3 Ley 23 de 1981 56 3.5.4 Ley 1419 de 2010. 56 3.5.5 Ley 1438 de 2011. 57 3.5.6 Decreto 2963 de 2012 57 3.5.7 Decreto 2573 de 2014 58 4. MÉTODO DE INVESTIGACIÓN 59 4.1 Objetivos Proyecto 59 4.1.1 General 59 4.1.2 Específicos 59 4.2 Proceso de Arquitectura Empresarial 59 4.2.1 Fase 1: Estrategia de ejercicios de AE 61 4.2.2 Fase 2: Definición de un Ejercicio de AE 61 4.2.3 Fase 3: Ejecución Ejercicio de AE 62 5. RESULTADOS DE LA INVESTIGACIÓN 66 5.1 Fase: Estrategia de Ejercicio de Arquitectura Empresarial 66 5.1.1 Motivadores de negocio 66 5.1.2 Descripción del ejercicio de arquitectura 68 5.2 Fase 2: Definición del ejercicio de Arquitectura Empresarial 69 5.2.1 Determinación del Alcance del Sistema 70 5.2.2 Restricciones del proyecto 71 5.3 Fase 3: Ejecución del ejercicio de Arquitectura Empresarial 72 5.3.1 Fase 3.1 Elaboración de la arquitectura Actual 72 5.3.2 Fase 3.2: Elaboración de la arquitectura Objetivo 81 5.3.3 Fase 3.3: Análisis de Brecha 95 5.3.4 Fase 3.4: Mapa de Ruta 96 5.3.5 Fase 3.5: Evaluación Ejercicio 116 6. CONCLUSIONES 123 7. RECOMENDACIONES Y TRABAJOS FUTUROS 125 8. BIBLIOGRAFÍA 126 9. ANEXOS 130 Maestría Recently in Colombia there is a national interest to promote initiatives and strategies from different government agencies in order to improve the quality related with the services offered to the citizens, these strategies are focused to empower some segments of society, especially the health services one. One area of particular interest is the development of initiatives to strengthen and promote health information systems to be more integrated and collaborative, where the patient’s information exchange might not only be able to improve the service efficiency, but also his life quality and in many cases it can even help to avoid medical errors. But, even though the solution is to provide information systems more interconnected and interoperable between each other, it is also true that due to the plurality of actors in the health system, there exist several Information Technology solutions that support different kind of processes in every institution, and every one of them could use a different set of standards. In this regard, the following paper seeks to design and develop an architectural model for interoperability between patient records that suits the needs of the University Hospital of Santander; and at the same time, using a Service Oriented Architecture, it aims to implement the HL7 standard for the exchange of clinical documents. This design will consist in adapting and building an architecture scheme that will allow to extract, transform and enable clinical patient’s health records in an international standard that facilitates data sharing between information systems

Partiendo del concepto de Arquitectura Empresarial dado por The Open Group Architecture Framework: “… la arquitectura empresarial se puede definir de dos posibles formas dependiendo del contexto en que se utilice 1) una descripción formal de un sistema o un plan detallado de un sistema a nivel de sus componentes para guiar su implementación; o 2) una estructura de componentes, sus interrelaciones, y los principios y guías que gobiernan su diseño y evolución en el tiempo”. El presente trabajo realiza un primer acercamiento al concepto de Arquitectura Empresarial en el SENA, como una descripción formal o plan detallado de un sistema para guiar su implementación, para eso se toma como base el procedimiento de Ejecución de la Formación, que es el proceso CORE de negocio de la Entidad; como framework de arquitectura Empresarial se utilizó TOGAF 9.1, en especial su metodología de trabajo conocida como ADM (Architecture Development Method); aplicando la fase preliminar, la fase de visión, la fase de Arquitectura de Negocio y la fase de sistemas de Información, está ultima incluye arquitectura de datos y arquitectura de aplicaciones. El trabajo inicia con una revisión sobre el concepto de Arquitectura Empresarial, sobre el framework TOGAF 9.1 y el ADM, así mismo una descripción general del procedimiento de Formación Profesional Integral en el SENA, para luego aplicar las fase descritas en el ADM y sobre los dominios de arquitectura, dando como resultado un estado actual del procedimiento en cada una de las fases conocido como el AS –IS, y generando un estado propuesto conocido como el TO BE, la brecha entre el AS IS y el TO BE da espacio a proyectos futuros o a la implementación de proyectos por parte de la Entidad RESUMEN ..................................................................................................................................................... 10 INTRODUCCION............................................................................................................................................ 11 1. ANTECEDENTES ................................................................................................................................... 13 1.1 ALCANCE......................................................................................................................................... 13 1.2 OBJETIVO GENERAL ........................................................................................................................ 13 1.3 OBJETIVOS ESPECIFICOS .................................................................................................................. 14 1.4 PLANTEAMIENTO DEL PROBLEMA Y JUSTIFICACION ........................................................................ 14 2. MARCO TEORICO ..................................................................................................................................... 15 2.1 DEFINICION DE ARQUITECTURA EMPRESARIAL .................................................................................. 15 2.2 ARQUITECTURA EMPRESARIAL EN COLOMBIA .................................................................................. 18 2.3 DOMINIOS DE ARQUITECTURA PARA EL ESTADO COLOMBIANO ....................................................... 18 2.4 EXPERIENCIAS DE ARQUITECTURA EMPRESARIAL .............................................................................. 20 2.5 PROCESO DE FORMACION PROFESIONAL EN EL SENA ........................................................................ 21 3. MARCO DE REFERENCIA. .......................................................................................................................... 23 3.1 MARCO TOGAF THE OPEN GROUP ..................................................................................................... 23 3.1.1 Dimensiones de TOGAF 9.1 ....................................................................................................... 23 3.2 ARCHITECTURE DEVELOPMENT METHOD .......................................................................................... 25 3.2.1 Visión Preliminar. ........................................................................................................................ 26 3.2.2 Fase A. Visión de la Arquitectura. .............................................................................................. 27 3.2.3 Fase B. Arquitectura de Negocio. .............................................................................................. 27 3.2.4 Fase C. Arquitectura de Sistemas de Información. ..................................................................... 28 3.2.5 Fase D. Arquitectura de Tecnología. .......................................................................................... 28 3.2.6 Fase E. Oportunidades y Soluciones ........................................................................................... 29 3.2.7 Fase F. Planificación de la Migración ......................................................................................... 29 3.2.8 Fase G. Gobierno de la Implementación. ................................................................................... 30 3.2.9 Fase H. Gestión de Cambios. ..................................................................................................... 30 3.2.10 Gestión de Requerimientos...................................................................................................... 30 3.3 MARCO DE REFERENCIA DEL CONTENIDO ARQUITECTÓNICO ............................................................ 31 3.4 NOTACION BPMN .............................................................................................................................. 32 4. ADOPCION DEL MARCO DE REFERENCIA TOGAF EN EL PROCEDIMIENTO DE EJECUCION DE LA FORMACION PROFESIONAL EN EL SENA. ..................................................................................................... 36 4.1 FASE PRELIMINAR .............................................................................................................................. 36 4.1.1 MODELO ORGANIZACIONAL DE ARQUITECTURA EMPRESARIAL. ..................................................... 36 4.1.1.1 Definición de la empresa .......................................................................................................... 36 4.1.1.2 Misión .................................................................................................................................... 37 4.1.1.3 Visión ..................................................................................................................................... 37 4.1.1.4 Estructura Organizacional ...................................................................................................... 37 4.1.1.5 Red de Procesos ..................................................................................................................... 38 4.1.2 MARCO DE REFERENCIA DE ARQUITECTURA ADAPTADO ................................................................ 38 4.1.3 PRINCIPIOS DE ARQUITECTURA ...................................................................................................... 39 4.1.3.1 Principio 1 de negocio: ........................................................................................................... 40 4.1.3.2 Principio 2 de datos. ............................................................................................................... 41 4.1.3.3 Principio 3. De aplicaciones .................................................................................................... 41 4.1.3.4 Principio 4. De tecnología. ...................................................................................................... 42 4.1.4 REPOSITORIO DE ARQUITECTURA ................................................................................................... 42 4.2 FASE A: VISION DE LA ARQUITECTURA ............................................................................................... 43 4.2.1 REQUERIMIENTO DEL NEGOCIO ...................................................................................................... 43 4.2.2 VISION DE LA ARQUITECTURA......................................................................................................... 43 4.2.3 DEFINICION DE RESTRICCIONES ...................................................................................................... 44 4.2.4 MATRIZ DE LOS INTERESADOS ......................................................................................................... 44 4.2.5 DIAGRAMA DE CADENA DE VALOR ................................................................................................. 46 4.2.6 DIAGRAMA DE CONCEPTO DE LA SOLUCION ................................................................................... 46 4.2.7 PRINCIPIOS DE NEGOCIO, OBJETIVOS, Y MOTIVACIONES. ............................................................... 46 4.3 FASE ARQUITECTURA DEL NEGOCIO ................................................................................................... 52 4.3.1 PRINCIPALES FUNCIONES DEL NEGOCIO ..................................................................................................... 52 4.3.1.1 Formación Profesional ............................................................................................................. 52 4.3.1.2 Certificación de Competencias. ................................................................................................ 52 4.3.1.3 Gestión de Empleo y Emprendimiento ...................................................................................... 53 4.3.2 IDENTIFICACIÓN OBJETIVO DEL NEGOCIO ................................................................................................... 53 4.3.3 PROCEDIMIENTO DE GESTIÓN DE LA FORMACIÓN PROFESIONAL INTEGRAL ......................................................... 54 4.3.4 CATÁLOGOS ....................................................................................................................................... 54 4.3.4.1 Catálogo de Metas y Objetivo de Negocio. .............................................................................. 54 4.3.4.2 Catálogo de Procesos. .............................................................................................................. 56 4.3.4.3 Catálogo de Actores y Unidades Organizacionales .................................................................. 58 4.3.4.4 Catálogo de Roles del Negocio ................................................................................................ 60 4.3.4.5 Catálogo de Funciones del Negocio ......................................................................................... 61 4.3.5 VISTA DE PROCESOS ............................................................................................................................. 62 4.3.5.1 Vista procesos AS-IS ................................................................................................................ 62 4.3.5.2 Vista procesos to be ................................................................................................................ 67 4.3.5.3 Análisis de brecha de procesos ................................................................................................ 70 4.4 FASE C: ARQUITECTURA DE SISTEMAS DE INFORMACIÓN, DATOS Y APLICACIONES ............................ 72 4.4.1 ARQUITECTURA DE DATOS ............................................................................................................. 72 4.4.1.1 Modelo de datos AS - IS .......................................................................................................... 72 4.4.1.2 Modelo de datos TO-BE ........................................................................................................... 72 4.4.1.3 Análisis de brechas de los datos. ............................................................................................. 75 4.4.1.4 Catálogo de entidades............................................................................................................ 77 4.4.1.5 Esquema de seguridad de los datos ......................................................................................... 78 4.4.1.6 Ciclo de Vida de los Datos....................................................................................................... 79 4.4.2 ARQUITECTURA DE APLICACIONES ................................................................................................. 80 4.4.2.1 Catálogo de Aplicaciones ........................................................................................................ 80 4.4.2.2 Servicios de Aplicación AS -IS .................................................................................................. 82 4.4.2.3 Servicios de Aplicación TO-BE .................................................................................................. 82 4.4.2.4 Matriz Aplicaciones/Funciones del Negocio ............................................................................ 83 4.4.2.5 Matriz Aplicaciones/Roles ...................................................................................................... 84 4.4.2.6 Catálogo de Componentes/Servicios ...................................................................................... 85 4.5 FASE D: ARQUITECTURA DE TECNOLOGIA. ......................................................................................... 86 CONCLUSIONES........................................................................................................................................ 89 REFERENCIAS.............................................................................................................................................. 91 Maestría Based on the concept of Enterprise Architecture given by The Open Group Architecture Framework: "... enterprise architecture can be defined in two ways depending on the context in which they use 1) a formal description of a system or a detailed plan of a system level of its components to guide their implementation; or 2) a structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time. " This paper makes a first approach to the concept of Enterprise Architecture in SENA, as a formal description or detailed design of a system to guide its implementation plan, that's what the basis is the enforcement procedure of formation, which is the process CORE business of the entity; as TOGAF enterprise architecture framework 9.1 was used, especially its working methodology known as ADM (Architecture Development Method); applying the preliminary phase phase vision, the Business Architecture phase and phase information systems, the latter includes data architecture and application architecture. The work begins with a review of the concept of Enterprise Architecture, on the framework TOGAF 9.1 and the ADM, also a general description of the procedure of Integral Training at SENA, then apply the phase described in the ADM and domains architecture, resulting in a current state of the process in each of the phases known as the AS -IS, and generating a proposed state known as the TO BE, the gap between AS IS and TO BE gives space for future projects or the implementation of projects by the Bank

En este trabajo se propone el modelo de una arquitectura empresarial para la gestión de la información de los proyectos y los productos bajo la norma NTC 5802(Alvarez Toro, Pulido Castillo, Arbelaez Naranjo, & Bazurto Gil, 2015b) para un grupo de investigación, tomando como caso de pruebas el grupo de investigación PRISMA de la Universidad Autónoma de Bucaramanga (UNAB), dada la necesidad de realizar una apropiada gestión de la información de productos de Desarrollo Tecnológico e Innovación que aporte a al toma de decisiones. Se estableció la base de gestión integral para la gestión de proyectos y productos, en conjunto con el diagnóstico del grupo de investigación PRISMA de la UNAB, a partir de la norma NTC 5802 y los objetivos estratégicos institucionales en el desarrollo de la gestión y la innovación, que permitió diseñar un modelo arquitectónico empresarial para la gestión de la información e innovación de proyectos y productos de Desarrollo Tecnológico e innovación y así elaborar una guía metodológica del modelo de gestión de proyectos y productos de Desarrollo Tecnológico e Innovación ((I+D+I)), a partir de la NTC 5802. El modelo arquitectónico permite la visualización de los objetivos estratégicos del grupo junto a la tecnología subyacente, mediante un conjunto de normas y principio, pautas, modelos y estándares, proveen una vista completa de la organización del grupo de investigación PRISMA INTRODUCCION 6 1. ANTECEDENTES 7 2. ESTADO DEL ARTE 10 3. OBJETIVOS 20 3.1 OBJETIVO GENERAL 20 3.2 OBJETIVOS ESPECIFICOS 20 4. PLANTEAMIENTO DEL PROBLEMA Y JUSTIFICACIÓN 21 5. MARCO REFERENCIAL 23 5.1 MARCO CONCEPTUAL 23 5.1.1 Arquitectura Empresarial 23 5.1.2 Análisis de las Arquitecturas Empresariales 24 5.1.3 TOGAF (The Open Group Architecture Framework) 24 5.1.4 ZACHMAN 26 5.1.5 Dominio o Dimensiones de la Arquitectura Empresarial en Colombia (R, 2010) 27 5.1.6 Norma Técnica Colombiana NTC 5802 (Icontec, 2008) 28 5.1.7. Universidad Autónoma de Bucaramanga (Bucaramanga, 2007) 28 5.1.8 Grupo de Investigación PRISMA - “Preservación e Intercambio Digital de Información y Conocimiento“, de la UNAB 29 5.2 MARCO DE REFERENCIA 29 5.2.1 MARCO TOGAF THE OPEN GROUP 29 5.2.2 DIMENSIONES DE TOGAF 9.1 30 5.2.3 ARCHITECTURE DEVELOPMENT METHOD 31 5.3 MARCO DE REFERENCIA DEL CONTENIDO ARQUITECTÓNICO 34 5.3.1 NOTACIÓN BUSINESS PROCESS MODEL AND NOTATION - BPMN 35 6. METODOLOGÍA DE LA INVESTIGACIÓN 41 6.1 TIPO DE INVESTIGACIÓN (Hernández, Fernández Collado, & Bautista, 1997) 41 7. DESARROLLO DEL PROYECTO: OBJETIVO ESPECIFICO 1 43 8. DESARROLLO DEL PROYECTO: OBJETIVO ESPECIFICO 2 46 9. DESARROLLO DEL PROYECTO: OBJETIVO ESPECIFICO 3 49 9.1 MODELO ARQUITECTÓNICO EMPRESARIAL 49 9.1.1 FASE PRELIMINAR 49 9.1.2 FASE A: VISIÓN DE LA ARQUITECTURA 54 9.1.3 FASE B: ARQUITECTURA DEL NEGOCIO 58 9.1.4 FASE C: ARQUITECTURA DEL SISTEMA DE INFORMACIÓN, DATOS Y APLICACIONES 65 9.1.5 FASE D: ARQUITECTURA TECNOLÓGICA 71 10. DESARROLLO DEL PROYECTO: OBJETIVO ESPECIFICO 4 72 11. CONCLUSIONES 73 12. RECOMENDACIONES Y TRABAJOS FUTUROS 74 13. BIBLIOGRAFÍA 75 Maestría This paper proposes the model of an enterprise architecture for the management of the information of the projects and the products under the standard NTC 5802 (Alvarez Toro, Pulido Castillo, Arbelaez Naranjo, & Bazurto Gil, 2015a) for a research group, taking as case of tests the research group PRISMA of the University Autónoma of Bucaramanga (UNAB), given the need to carry out an appropriate management of the information of products of Technological Development and Innovation that contributes to the decision making. The integral management base for the management of projects and products was established, together with the diagnosis of the PRISMA research group of the UNAB, based on the standard NTC 5802 and the institutional strategic objectives in the development of management and innovation , Which allowed the design of an enterprise architectural model for the management of information and innovation of projects and products of Technological Development and innovation and to develop a methodological guide for the project management and technological development and innovation (I + D + I) from NTC 5802. The architectural model allows the visualization of the strategic objectives of the group together with the underlying technology, through a set of rules and principles, guidelines, models and standards, provide a complete view of the organization Of the PRISMA research group

El área de los sistemas de emergencias pre-hospitalarios, esta desatendida, son muy pocos los proyectos relacionados en este sector. Actualmente a través de las tecnologías móviles se pueden apoyar estas áreas, y dar herramientas que permiten un mejor desarrollo de estos procesos para las entidades de salud. Evitando inconformidades en el servicio por parte de los usuarios como, atención inoportuna, tratamientos pre hospitalarios incorrectos causando sobrecostos en el sistema de salud, tutelas, demandas y procesos legales que puedan incurrir por procesos mal ejecutados. Esta tesis se basa en la mejora del proceso de solicitudes y tratamiento pre hospitalario en los sistemas de emergencia en ambulancias. Se realiza un estado del arte en donde describe un panorama general de las tecnologías aplicadas a Mobile health en el área de servicio de emergencia pre hospitalario en los último 5 años, dando una primera aproximación para abordar la problemática planteada en el sistema de solicitudes, siendo para pacientes en estado crónico, que necesiten un cuidado preferencial, así aportando a la mejora en la atención pre-hospitalaria ejecutada en el momento de la emergencia. Se utiliza como base TOGAF para platear el análisis de los procesos de negocio a través del ciclo ADM en las fases preliminar y fase A. A través de las fases B, C y D se plantea una arquitectura orientada a servicios que permita la fácil comunicación entre los sistemas de las entidades de la salud y el usuario paciente a través de una plataforma móvil, en donde el paciente tendrá la capacidad de registrar, informar y conectar de manera inmediata con la entidad de salud, generando una alarma y un llamado a la ambulancia proporcionándole los datos necesarios para que la emergencia sea atendida de manera rápida y eficiente INTRODUCCIÓN .................................................................................................. 9 1. MARCO TEÓRICO ...................................................................................... 11 1.1 ANTECEDENTES .................................................................................... 11 1.2 ESTADO DEL ARTE ................................................................................ 12 1.3 INTEROPERABILIDAD ORGANIZACIONAL ........................................... 15 1.3.1 Arquitectura Empresarial ...................................................................... 15 1.3.2 Arquitectura de Software ...................................................................... 17 1.3.3 Arquitectura de Software Orientada a Servicios SOA .......................... 18 1.3.4 BPM ...................................................................................................... 19 1.4 PLANTEAMIENTO DEL PROBLEMA Y JUSTIFICACIÓN ...................... 20 1.4.1 Pregunta de Investigación .................................................................... 22 1.4.2 Objetivos............................................................................................... 22 1.4.2.1 Objetivo general ................................................................................... 22 1.4.2.2 Objetivos específicos ........................................................................... 22 1.4.3 Significancia ......................................................................................... 22 1.4.3.1 Beneficios que puede generar el proyecto ........................................... 23 1.4.3.2 Impacto ................................................................................................. 24 2. MÉTODO ..................................................................................................... 25 2.1 ACTIVIDADES ......................................................................................... 25 3. RESULTADOS DE LA INVESTIGACIÓN .................................................... 28 3.1 DESCRIPCIÓN DE LA ARQUITECTURA ............................................... 28 3.2 GENERALIDADES................................................................................... 28 3.2.1 Descripción del problema ..................................................................... 28 3.2.2 Descripción del sistema ....................................................................... 29 3.2.3 Stakeholders ........................................................................................ 30 3.3 MOTIVADORES DEL NEGOCIO ............................................................. 31 3.3.1 Motivadores .......................................................................................... 31 3.3.2 Restricciones de negocio ..................................................................... 34 3.4 CONTEXTO DEL NEGOCIO ................................................................... 34 3.4.1 Procesos de negocio ............................................................................ 35 3.4.2 Casos de uso del sistema .................................................................... 36 3.5 REQUERIMIENTOS DE CALIDAD .......................................................... 37 3.5.1 Atributos de calidad .............................................................................. 37 3.5.1.1 Interoperabilidad ................................................................................... 37 3.5.1.2 Disponibilidad ....................................................................................... 38 3.5.1.3 Escenarios de calidad para la disponibilidad ....................................... 38 3.5.2 Seguridad ............................................................................................. 40 3.5.3 Rendimiento ......................................................................................... 40 3.6 VISTAS ARQUITECTÓNICAS ................................................................. 40 3.6.1 Punto de vista por capas ...................................................................... 41 3.6.1.1 Arquitectura de negocio ....................................................................... 42 3.6.1.2 Arquitectura de sistemas de información y datos ................................. 42 3.6.1.3 Arquitectura tecnológica ....................................................................... 43 3.6.2 Vista de realización de servicios .......................................................... 43 3.7 EVALUACIÓN Y EXPERIMENTACIÓN ................................................... 44 3.7.1 Evaluación con el método The Architecture Tradeoff Analysis Method. 44 3.7.2 Prototipo de Software ........................................................................... 45 4. LIMITACIONES ........................................................................................... 54 5. CONCLUSIONES ........................................................................................ 55 6. TRABAJO A FUTURO ................................................................................. 57 7. RECOMENDACIONES ................................................................................ 58 8. ANEXOS ...................................................................................................... 59 9. BIBLIOGRAFÍA ............................................................................................ 62 Maestría The area of the pre-hospital emergency systems, this neglected, are very few projects related in this sector. Currently through the mobile technologies can support these areas, and provide tools that allow a better development of these processes for health entities. Avoiding nonconformities in the service by users such as untimely care, incorrect prehospital treatments causing cost overruns in the health system, lawsuits and legal processes that may incur by poorly executed processes. This thesis is based on the improvement of the process of applications and prehospital treatment in ambulance emergency systems. A state of the art is made describing an overview of the technologies applied to Mobile health in the area of prehospital emergency service in the last 5 years, giving a first approximation to address the problematic raised in the request system, being For patients in chronic condition, who need a preferential care, thus contributing to the improvement in pre-hospital care performed at the time of the emergency. The TOGAF method is used to plumb the analysis of the business processes through the ADM cycle in the preliminary and phase A phases. Through phases B, C and D a service oriented architecture is proposed that allows the easy communication between Systems of health entities and the patient user through a mobile platform. The patient will have the ability to immediately record, inform and connect with the health entity, generating an alarm and a call to the ambulance providing the necessary data so that the emergency is attended quickly and efficiently

Effective requirements management and enabling tools are critical for successfully developing and maintaining services and products. The identification and selection of an appropriate requirements management tool can be a costly, time-consuming, and error-prone undertaking especially in the context of software product line requirements management, requiring the tools to support both product and platform development activities that often involve geographically distributed, collaborating, and competing stakeholders. Criteria lists have been developed to facilitate the selection. This research (1) creates an evaluation framework to review the applicability of the lists for the selection of requirements management tools supporting distributed collaboration and software product line requirements management and (2) leverages the framework to perform the evaluation. The lists are found to provide little support for evaluating the tools from the viewpoints of distributed collaboration and software product line requirements management. Future research is needed to create a more comprehensive list addressing these viewpoints. peerReviewed

El mundo de la programación está tratando de evolucionar en todos los aspectos, sin embargo, uno de los temas en los que no se ha profundizado mucho en esta evolución es en el segmento de la comunicación entre los sistemas; este documento ofrece una visión diferente y alternativa a la comunicación tradicional, dejando la responsabilidad de realizar cualquier reproceso a una plataforma independiente dedicada exclusivamente a esto. El presente documento da una idea general de cómo desarrollar un prototipo de dicha plataforma, utilizando como referente principal la metodología RUP tomando el tiempo como principal preocupación del problema planteado, orientando las pruebas realizadas a someter a consideración esta variable principalmente, por lo que se estableció una prueba de tiempo estándar de tres horas en la que durante el mismo tiempo se probo la conexión punto a punto o sistema a sistema, procesando de esta forma 29.386 peticiones y por otro lado se hizo la prueba en donde en medio de los sistemas esta la plataforma propuesta, procesando 54.944 peticiones. De dichas pruebas se desprenden que este tipo de plataformas permiten hacer más efi ciente el uso de recursos ya que permitió procesar un número mayor de peticiones en el mismo periodo de tiempo que el que se hace a través de una confi guración tradicional o punto a punto con un rendimiento adicional de un 86%, evitando así que los sistemas que hacen las peticiones tuvieran que estar pendientes del reproceso de las peticiones fallidas, es decir, que no deberán implementar un esquema de control de errores, ya que la plataforma se convierte en el intermediario que realizaría este proceso; de igual manera esta plataforma es capaz de realizar un proceso de encolamiento de peticiones y respuestas cuando uno de los sistemas en características de rendimiento es mejor que otro. Esta plataforma puede reemplazar la etapa de análisis e implementación de los mecanismos de reprocesamiento de peticiones fallidas de los cronogramas de trabajo de los sistemas nacientes, permitiendo aprovechar el tiempo valioso en actividades que brinden una mejor calidad en lugar establecer a menudo mecanismos cada vez mas complejos para abordar esta problemática INDICE DE TABLAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 INDICE DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 INTRODUCCI ON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1 PLANTEAMIENTO DEL PROBLEMA . . . . . . . . . . . . . . . . . . . . 10 2 ESTADO DEL ARTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1 QU E ES UN WEB SERVICE . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1.1 El modelo de web services . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 RATIONAL UNIFIED PROCESS (RUP) . . . . . . . . . . . . . . . . . . . 12 2.3 COMUNICACI ON ASINCR ONICA Y SINCR ONICA . . . . . . . . . . . . . 13 2.3.1 Comunicaci on asincr onica . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.2 Comunicaci on sincr onica . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4 WEB SERVICES ASINCR ONICOS . . . . . . . . . . . . . . . . . . . . . . 13 2.5 CIFRADO ASIM ETRICO . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3 OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1 GENERAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2 ESPEC IFICOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4 METODOLOG IA DE LA INVESTIGACI ON . . . . . . . . . . . . . . . . . 16 4.1 PLANEAMIENTO DE LA PLATAFORMA . . . . . . . . . . . . . . . . . . 17 4.1.1 Descripci on General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1.2 Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1.3 Especi caci on del Actor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1.4 Descripci on de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1.5 Din amica de las peticiones . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1.6 Seguridad y con dencialidad . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.2 VISI ON GENERAL DEL SISTEMA . . . . . . . . . . . . . . . . . . . . . . 23 4.3 CUANTIFICACI ON DE LA CAPACIDAD DE PROCESAMIENTO . . . . . . 24 4.4 TIEMPO PROMEDIO DE PROCESAMIENTO POR PETICI ON . . . . . . 25 4.5 SECUENCIA DE LA PETICI ON . . . . . . . . . . . . . . . . . . . . . . . 25 5 RESULTADOS Y AN ALISIS DE LOS RESULTADOS . . . . . . . . . . . . 27 5.1 PREPARACI ON DEL ESCENARIO . . . . . . . . . . . . . . . . . . . . . . 27 5.2 CONFIGURACION FISICA DEL EXPERIMENTO . . . . . . . . . . . . . . 28 5.3 ESQUEMA DE EXPERIMENTOS . . . . . . . . . . . . . . . . . . . . . . 30 5.3.1 Experimentos realizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.3.2 Experimento N um. 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.3.3 Experimento N um. 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.3.4 Comparaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.3.5 Estado de los objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.4 POSIBLES APLICACIONES . . . . . . . . . . . . . . . . . . . . . . . . . 35 6 CONCLUSIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7 RECOMENDACIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 BIBLIOGRAF IA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Maestría The world of programming is trying to evolve in all aspects, however, one of the topics that has not been explored much in depth in this evolution is in the segment of communication between systems; this document offers an overview different and alternative to traditional communication, leaving the responsibility of carrying out any reprocessing to an independent platform dedicated exclusively to this. This document gives a general idea of ​​how to develop a prototype of said platform, using the RUP methodology as the main reference, taking time as the main concern of the problem posed, guiding the tests carried out to submit this variable for consideration mainly, for which reason it was established a standard three-hour time trial in which during the same time the point-to-point or system-to-system connection, thus processing 29,386 requests and on the other hand, the test was carried out where the proposed platform is in the middle of the systems, processing 54,944 requests. These tests show that this type of platform makes it possible to make the use of resources more efficient since it allowed a greater number of requests to be processed in the same period of time than that made through a traditional configuration. or point-to-point with an additional performance of 86%, thus avoiding that the systems that make the requests have to be aware of the reprocessing of failed requests, that is, they should not implement an error control scheme, since that the platform becomes the intermediary that would carry out this process; in the same way, this platform is capable of carrying out a queuing process of requests and responses when one of the systems in performance characteristics is better than another. This platform can replace the stage of analysis and implementation of the reprocessing mechanisms of failed requests of the work schedules of the nascent systems, allowing to take advantage of the valuable time in activities that provide better quality instead of establishing increasingly complex mechanisms. to address this problem

El presente documento dará a conocer al lector, la importancia de aplicar los estándares de Auditoria y aseguramiento planteados por la IFAC. De igual forma, se dará un acercamiento a la implementación del sistema ODITI, desarrollado bajo el concepto de Software como Servicios (SaaS), orientado a las necesidades y normas que afecten las actividades en el proceso de auditoría. Así mismo el documento orientara al lector, sobre el funcionamiento del sistema ODITI, dando a conocer los estándares implementados en las diferentes fases del proceso de Auditoría Financiera. El Software de Auditoria Financiera Oditi, permitirá la participación activa de los usuarios de las MyPymes, parametrizando el sistema de acuerdo a las actividades y controles de la organización. Para lograr lo anterior, Oditi promueve el desarrollo de auditorías a las MiPymes obteniendo resultados más seguros, confiables y económicos, que permitan implementar nuevas tecnologías para la satisfacción de crecientes necesidades en el ámbito de la seguridad en los procesos que se realizan en las diferentes entidades INTRODUCCIÓN 11 1. PLANTEAMIENTO DEL PROBLEMA 12 1.1. ANTECEDENTES 12 1.2. PLANTEAMIENTO DEL PROBLEMA 13 1.3. PREGUNTA DE INVESTIGACIÓN 13 1.4. JUSTIFICACIÓN 14 1.5. OBJETIVOS 14 1.5.1. OBJETIVO GENERAL 14 1.5.2. OBJETIVOS ESPECIFICOS 15 1.6. ALCANCE 15 1.7. LIMITACIONES 15 2. MARCO TÉORICO 16 2.1. AUDITORIA 16 2.1.1. DEFINICIÓN DE AUDITORIA 16 2.2.2. NORMAS Y PROCEDIMIENTOS DE AUDITORIA 16 2.2. AUDITORIA FINANCIERA 17 2.3. NORMAS INTERNACIONALES DE AUDITORIA 18 ETAPA 1: CONOCIMIENTO DEL CLIENTE Y ACEPTACIÓN DEL ENCARGO DE AUDITORÍA 18 2.3.1. NIA 210: ACUERDO EN LAS CONDICIONES EN LOS COMPROMISOS DE AUDITORÍA. 18 2.3.2. NIA 240: RESPONSABILIDAD DEL AUDITOR EN RELACIÓN CON EL FRAUDE EN UNA AUDITORÍA DE ESTADOS FINANCIEROS. ASPECTOS CLAVE 19 2.3.3. NIA 250: CONSIDERACIÓN DE LEYES Y REGULACIONES EN UNA AUDITORÍA DE ESTADOS FINANCIEROS 19 2.3.4 NIA 260: COMUNICACIÓN CON LOS ENCARGADOS DEL GOBIERNO CORPORATIVO. 20 ETAPA 2: PLANEACIÓN DEL TRABAJO DE AUDITORÍA Y EVALUACIÓN DE RIESGOS 20 PLANEACIÓN DE LA AUDITORIA 20 2.3.5. NIA 300. PLANIFICACIÓN DE LA AUDITORÍA DE ESTADOS FINANCIEROS. 20 2.3.6. NIA 320: IMPORTANCIA RELATIVA O MATERIALIDAD EN LA PLANIFICACIÓN Y EJECUCIÓN DE LA AUDITORÍA 20 2.3.7. NIA 315: RESPONSABILIDAD DEL AUDITOR PARA IDENTIFICAR Y VALORAR RIESGOS 21 2.3.8. NIA 265: RESPONSABILIDAD QUE TIENE EL AUDITOR DE COMUNICAR ADECUADAMENTE 21 ETAPA 3: RESPUESTA DE AUDITORÍA AL RIESGO Y EJECUCIÓN DEL TRABAJO DE AUDITORÍA 21 2.3.9. NIA 330: RESPONSABILIDAD DEL AUDITOR DE DISEÑAR E IMPLEMENTAR RESPUESTAS 21 2.3.10. NIA 450: RESPONSABILIDAD DEL AUDITOR DE EVALUAR EL EFECTO DE LAS INCORRECCIONES IDENTIFICADAS 22 2.3.11. NIA 230 - RESPONSABILIDAD DEL AUDITOR EN LA PREPARACIÓN DE LA DOCUMENTACIÓN 22 2.3.12 NIA 500: EVIDENCIA EN LA AUDITORÍA 22 2.3.13. NIA 501: EVIDENCIA DE AUDITORIA – CONSIDERACIONES ESPECÍFICAS PARA DETERMINADAS ÁREAS 22 2.3.14. NIA 505. CONFIRMACIONES EXTERNAS 22 2.3.15. NIA 520. PROCEDIMIENTOS ANALITICOS 23 2.3.16. NIA 530. MUESTREO DE AUDITORIA 23 2.3.17. NIA 540. AUDITORÍA DE ESTIMACIONES CONTABLES INCLUIDAS LAS DE VALOR RAZONABLE, Y DE LA INFORMACIÓN RELACIONADA CON REVELAR. 23 2.3.18. NIA 570. AUDITORIA A EMPRESA EN FUNCIONAMIENTO. 23 2.3.19. NIA 610. UTILIZACIÓN DEL TRABAJO DE LOS AUDITORES INTERNOS. 23 2.3.20. NIA 620. UTILIZACIÓN DEL TRABAJO DE UN EXPERTO 24 ETAPA 4: CONCLUSIÓN DE LA AUDITORÍA, REPORTES Y OPINIÓN DEL AUDITOR 24 2.3.21. NIA 700. FORMACIÓN DE UNA OPINIÓN Y DICTAMEN SOBRE LOS ESTADOS FINANCIEROS. 24 2.3.22. NIA 705. MODIFICACIONES A LA OPINIÓN EN EL DICTAMEN DEL AUDITOR INDEPENDIENTE. 24 2.3.23. NIA 706. PÁRRAFOS DE ÉNFASIS Y PÁRRAFOS SOBRE OTRAS CUESTIONES EN EL INFORME EMITIDOS POR UN AUDITOR INDEPENDIENTE. 25 2.3.24. NIA 710. INFORMACIÓN COMPARATIVA – CIFRAS CORRESPONDIENTES DE PERÍODOS ANTERIORES Y ESTADOS FINANCIEROS COMPARATIVOS. 25 2.3.25. NIA 720. RESPONSABILIDAD DEL AUDITOR CON RESPECTO A OTRA INFORMACIÓN INCLUIDA EN LOS DOCUMENTOS QUE CONTIENEN LOS ESTADOS FINANCIEROS AUDITADOS. 25 2.4. SISTEMAS DE INFORMACIÓN 26 2.5. SOFTWARE AS A SERVICE (SAAS) 26 3. MARCO METODOLOGICO 27 3.1. DISEÑO DE LA INVESTIGACIÓN 27 3.2. ACTIVIDADES 28 3.3. TÉCNICAS E INSTRUMENTOS DE RECOLECCIÓN DE LOS DATOS 29 4. DESARROLLO DEL SISTEMA 30 4.1. CARACTERISTICAS TECNOLOGICAS REQUERIDAS 30 4.1.2. Componentes del cliente 30 4.1.3. Componentes de la parte del servidor 31 4.2. CASOS DE USOS 32 4.2.1. INTRODUCCIÓN 32 4.2.2. PROPÓSITO DEL DOCUMENTO 32 4.2.3. PERSPECTIVA GENERAL DE APLICACIÓN 32 4.3 DISEÑO DEL APLICATIVO 35 4.3.1. AGRUPACIÓN DE FUNCIONALIDADES EN PAQUETES O MÓDULOS 35 4.3.2. ARQUITECTURA DE LA INFORMACIÓN 35 5. RESULTADOS DE LA INVESTIGACIÓN 37 5.1. GENERALIDADES DE ODITI 37 5.1.1. SECCIONES ODITI 37 5.2. MÓDULOS DE ODITI 39 5.2.1. Opciones del Módulo Parametrización 40 5.2.2. Opciones del Módulo Preauditoria 41 5.2.3. Opciones del Módulo de Riesgos 42 5.2.4. Opciones del Módulo de Control 42 5.2.5. Opciones del Módulo de Ejecución 42 5.3. ARTICULO DE INVESTIGACIÓN 43 6. RECOMENDACIONES Y TRABAJO FUTUROS 44 7. CONCLUSIONES 45 BIBLIOGRAFÍA 46 ANEXOS 47 Maestría This document will inform the reader, the importance of implementing standards Audit and assurance posed by the IFAC. Similarly, will be an approach to the implementation of ODITI system, developed under the concept of Software as a Service (SaaS), oriented to the needs and regulations affecting activities in the audit process. Likewise, the document would guide the reader on the functioning of the system ODITI, publicizing the standards implemented in different phases of Financial Audit. Financial Audit Software Oditi allow the active participation of users in MSMEs, parameterizing the system according to the activities and organizational controls. To achieve this, Oditi promotes the development of audits MSMEs getting more safe, reliable and economic performance, allowing implement new technologies to satisfy growing needs in the field of security in the processes taking place in the different entities

During the last decade the structure of the consumer electronics industry has been changing profoundly. Current consumer electronics products are built using components from a large variety of specialized firms, whereas previously each product was developed by a single, vertically integrated company. Taking a software development perspective, we analyze the transition in the consumer electronics industry using case studies from digital televisions and mobile phones. We introduce a model consisting of five industry structure types and describe the forces that govern the transition between types and we describe the consequences for software architectures.We conclude that, at this point in time, software supply chains are the dominant industry structure for developing consumer electronics products. This is because the modularization of the architecture is limited, due to the lack of industry-wide standards and because resource constrained devices require variants of supplied software that are optimized for different hardware configurations. Due to these characteristics open ecosystems have not been widely adopted. The model and forces can serve the decision making process for individual companies that consider the transition to a different type of industry structure as well as provide a framework for researchers studying the software-intensive industries. (C) 2011 Elsevier Inc. All rights reserved.

El trastorno por déficit de atención e hiperactividad se caracteriza por dificultades en la atención, fallas en las funciones ejecutorias superiores y comportamiento hiperactivo y/o impulsivo, alterando los procesos cognitivos, conductuales y emocionales que dificultad la adaptación social del infante, que puede continuar hasta la adolescencia y la vida adulta. Tiene una prevalencia que oscila entre el 5 al 20% según el país, y tiene un alto impacto social por las dificultades que genera en el individuo, su familia, su vida escolar o laboral y en el sistema de salud. Por ello se hace prioritario buscar estrategias novedosas que faciliten el abordaje integral. Una arquitectura orientada a servicios facilita a los diferentes actores involucrados con los pacientes con TDAH acompañar la evolución clínica y mejorar el registro de estos casos, la flexibilidad que ofrece SOA permite la adaptabilidad a cada caso individual que representa cada paciente. El seguimiento, control y transformación de mensajes permite la interoperabilidad entre plataformas que posean los diferentes actores y aplicar normas de seguridad y protección de datos. Una arquitectura orientada a servicios no es publicar una serie de servicios, es implementar servicios reutilizables, alineados y que aporten al negocio; por tal razón se deben conocer las estructuras y semánticas del SGSSS y de la atención y manejo del TDAH, para identificar los casos de uso de negocio que son descritos con la arquitectura de negocio y sus escenarios se especifican con BPMN. Luego de conocer el modelo de negocio de la atención integral del TDAH se procede a identificar los servicios para clasificarlos y componer servicios con otros. Universitat Oberta de Catalunya UOC RESUMEN ..................................................................................................................................... 8 INTRODUCCIÓN ........................................................................................................................ 12 1. PLANTEAMIENTO DEL PROBLEMA Y JUSTIFICACIÓN .......................................... 13 2. OBJETIVOS ........................................................................................................................ 15 2.1. Objetivo General ......................................................................................................... 15 2.2. Objetivos Específicos ................................................................................................. 15 3. MARCO CONCEPTUAL .................................................................................................. 16 3.1. Trastorno por Déficit de Atención e Hiperactividad ............................................... 16 3.2. Arquitectura de Software ........................................................................................... 21 4. HISTORIA NATURAL DEL TDAH ................................................................................... 27 4.1. Historia natural y social de la enfermedad ............................................................. 27 4.2. Caracterización de la historia natural y social del TDAH ..................................... 30 5. ARQUITECTURA ORIENTADA A SERVICIOS ............................................................ 39 5.1. Conceptos .................................................................................................................... 39 5.2. Beneficios .................................................................................................................... 47 5.3. Características de la Infraestructura Orientada a Servicios (SOI) y Computación en la Nube ....................................................................................................... 51 5.4. Estrategia de Diseño .................................................................................................. 53 6. DESCRIPCIÓN ARQUITECTÓNICA .............................................................................. 56 6.1. Arquitectura de Referencia ....................................................................................... 56 6.2. Arquitectura del Negocio ........................................................................................... 60 6.3. Información Semántica y de Contexto .................................................................. 116 6.4. Identificación de Servicios ....................................................................................... 130 6.5. Especificación y Realización de Servicios ............................................................ 137 6.6. Capa de Componentes de Servicio ....................................................................... 145 6.7. Capa de Sistemas Operativos ................................................................................ 148 6.8. Implementación de la Solución Orientada a Servicios ....................................... 150 7. EVALUACIÓN DE LA ARQUITECTURA ...................................................................... 151 7.1. Líneas de Negocio.................................................................................................... 152 CONCLUSIONES ..................................................................................................................... 158 BIBLIOGRAFÍA ......................................................................................................................... 159 Maestría Attention deficit hyperactivity disorder is characterized by difficulties in attention, failure in higher executive functions, and hyperactive and / or impulsive behavior, altering cognitive, behavioral and emotional processes that hinder the infant's social adaptation, which can continue until adolescence and adult life. It has a prevalence that ranges from 5 to 20% depending on the country, and has a high social impact due to the difficulties it generates in the individual, their family, their school or work life and in the health system. Therefore, it is a priority to seek novel strategies that facilitate the comprehensive approach. A service-oriented architecture makes it easier for the different actors involved with ADHD patients to monitor the clinical evolution and improve the registry of these cases, the flexibility offered by SOA allows adaptability to each individual case that each patient represents. The monitoring, control and transformation of messages allows interoperability between platforms owned by the different actors and the application of security and data protection standards. A service-oriented architecture is not publishing a series of services, it is implementing reusable, aligned services that contribute to the business; For this reason, the structures and semantics of the SGSSS and the care and management of ADHD must be known, to identify the business use cases that are described with the business architecture and their scenarios are specified with BPMN. After learning about the business model of comprehensive ADHD care, we proceed to identify the services to classify them and compose services with others.

Software development is a complex socio-technical activity, with the result that software development organisations need to establish and maintain robust software development processes. While much debate exists regarding the effectiveness of various software development approaches, no single approach is perfectly suited to all settings and no setting is unchanging. The capability to adapt the software process is therefore essential to sustaining an optimal software process. We designed an exploratory study to concurrently examine software process adaptive capability and organisational performance in 15 software development organisations, finding that companies with greater software process adaptive capability are shown to also experience greater business success. While our exploratory study of the complex relationship between these phenomena is limited in some respects, the findings indicate that software process adaptive capability may be worthy of further integration into software process engineering techniques. Software process adaptive capability may be an important organisational strength when deriving competitive advantage, and those responsible for the creation and evolution of software process models and methodologies may want to focus some of their future efforts in this area.

Las peticiones, quejas, reclamos, solicitudes y felicitaciones (P.Q.R.S.F.) son fundamentales en el sistema de gestión de calidad de las organizaciones al punto de convertirse en canal de comunicación formal entre actores del negocio aprovechando sistemas de información que las implementan y las administran. Sin embargo las dinámicas económicas contemporáneas impulsadas por la globalización invitan a repensar las P.Q.R.S.F. como un sistema que involucre activamente a los actores de la gestión de la calidad para responder a la necesidad de innovación permanente que tienen las organizaciones que quieran mantenerse vigentes en los mercados. Esta investigación propone el diseño de una aplicación prototipo no funcional para la gestión de P.Q.R.S.F, con la proyección de interfaces y administración necesarias que permitan a los actores implicados interactuar colaborativamente para proponer soluciones. Es importante destacar que como parte fundamental del proceso se involucra al cliente en la posible solución. Universitat Oberta de Catalunya UOC INTRODUCCIÓN 1 1. ESTADO DEL ARTE 2 1.1 Revisión Bibliografíca 2 1.2 Generalidades de las P.Q.R.S.F. 3 1.3 Las P.Q.R.S.F. en la gestión de la calidad: ISO 9004, 10002. 4 1.4 Las mejores prácticas para gestionar Incidencias y solicitudes – ITIL V3. 7 1.5 Marco legal de las P.Q.R.S.F. 8 1.6 El flujo de una P.Q.R.S.F. 11 1.7 ¿Qué es la cocreación? 14 1.7.1 Caso de éxito de cocreación 14 1.7.2 La cocreación en la administración pública 16 1.7.3 Limitaciones de la co-creación. 17 1.7.4 Metodologías generales de cocreación. 18 1.8 Software libre 22 1.9 ¿Por qué una propuesta basada en software libre? 22 1.10 Metodologías de Desarrollo de Software. 26 1.11 Técnica a Utilizar para especificación del Sistema. 29 1.12 ¿Qué es el benchmarking? 31 1.13 Planteamiento y justificación del problema. 34 1.14 Pregunta de investigación 37 1.15 Hipótesis 37 1.16 Objetivo General 37 2. MÉTODO DE INVESTIGACIÓN 38 3. BENCHMARKING 39 3.1 Metodología del benchmarking 40 3.1.1 Elección de aplicaciones a examinar. 42 3.1.2 Estudio de las aplicaciones. 57 3.1.3 Propuesta de innovación. 66 4. DISEÑO DEL PROTOTIPO 68 5. EVALUACIÓN DE LA INNOVACIÓN. 95 5.1 Contexto de la evaluación 95 5.2 Metodología de evaluación 95 5.3 Indicadores de evaluación 96 5.4 Indicadores de resultados 97 5.4.1 Logros 97 5.4.2 Funcionalidad 98 5.4.3 Impacto 99 5.5 Conclusión de la evaluación 99 6. RECOMENDACIONES Y TRABAJOS FUTUROS 101 7. CONCLUSIONES 102 8. ANEXO 1: EVALUACION DE INNOVACION GECOS-P.Q.R.S.F. 103 9. ANEXO 2: RESUMEN HOJA DE VIDA EXPERTO. 111 10. BIBLIOGRAFIA 112 Maestría Requests, complaints, claims, requests and congratulations (P.Q.R.S.F.) are fundamental in the quality management system of organizations to the point of becoming a formal communication channel between business actors taking advantage of information systems that implement and administer them. However, contemporary economic dynamics driven by globalization invite us to rethink the P.Q.R.S.F. as a system that actively involves quality management actors to respond to the need for permanent innovation that organizations that want to stay current in the markets have. This research proposes the design of a non-functional prototype application for the management of P.Q.R.S.F., with the projection of interfaces and necessary administration that allow the involved actors to interact collaboratively to propose solutions. It is important to note that as a fundamental part of the process, the client is involved in the possible solution.

El presente trabajo tuvo como objetivo principal realizar la evaluación del uso del Software Libre en la enseñanza de los conceptos básicos de la Programación de Computadores, para identificar una estrategia alternativa en el proceso enseñanza-aprendizaje. Para dar cumplimiento a este objetivo trazado, se hizo necesario identificar las herramientas de Software Libre usadas en la enseñanza de los conceptos básicos de la Programación de Computadores, se realizó una evaluación comparativa de cinco herramientas, mediante una metodología de comparación aplicando el método de suma ponderada y se seleccionó Alice que fue el entorno de programación que obtuvo los mejores resultados en la evaluación comparativa. Se procedió a identificar las estrategias usadas en la enseñanza de los conceptos básicos de la Programación de Computadores, usando Alice y se diseñó un modelo de enseñanza de la programación orientada a objetos a ser implementado, a través de prácticas con un grupo experimental de estudiantes de la asignatura algoritmos y programación de la Escuela de Ingeniería de Sistemas y Computación de la Universidad Pedagógica y Tecnológica de Colombia, durante el primer semestre del año 2015. Posteriormente y con el propósito de evaluar el grado de aporte Alice y la estrategia de enseñanza en el proceso de aprendizaje de los estudiantes, se diseñó una encuesta para aplicarla con el grupo experimental, por otra parte se diseñó y aplicó un cuestionario final a los cinco grupos de la asignatura, para evaluar el nivel de aprendizaje de los contenidos programáticos de la asignatura, los mejores resultados se presentaron en el grupo experimental. Universitat Oberta de Catalunya UOC LISTA DE TABLAS 8 LISTA DE FIGURAS 9 LISTA DE ANEXOS DIGITALES 10 GLOSARIO 11 INTRODUCCIÓN 12 1 DEFINICIÓN DEL PROBLEMA 14 1.1 ANTECEDENTES 14 1.1.1 Referentes a nivel internacional. 14 1.1.2 Referentes a nivel nacional. 15 1.2 DESCRIPCIÓN 16 1.3 FORMULACIÓN 16 1.4 HIPÓTESIS 17 1.5 ALCANCE Y LIMITACIONES 17 2 JUSTIFICACIÓN 18 3 OBJETIVOS 19 3.1 OBJETIVO GENERAL 19 3.2 OBJETIVOS ESPECÍFICOS 19 4 MARCO REFERENCIAL 20 4.1 MARCO CONCEPTUAL 20 4.2 MARCO TEÓRICO 21 4.2.1 Estructuras de programación. 21 4.2.1.4 Patrón de Arquitectura Modelo-Vista-Controlador (MVC). 22 5 MARCO METODOLÓGICO 26 5.1 TIPO DE INVESTIGACIÓN 26 5.2 DESCRIPCIÓN DEL MÉTODO DE INVESTIGACIÓN 26 5.2.1 Selección de la población. 27 5.2.2 Técnicas usadas para la recopilación de datos. 28 5.2.3 Proceso de análisis de resultados. 28 5.2.4 Herramientas informáticas utilizadas. 29 6 RESULTADOS 30 6.1 FASE I: REVISIÓN DE LA LITERATURA SOBRE EL USO DEL SOFTWARE LIBRE EN LA ENSEÑANZA DE LOS CONCEPTOS BÁSICOS DE LA PROGRAMACIÓN DE COMPUTADORES. 30 6.2 FASE II: IMPLEMENTACIÓN DE UNA ESTRATEGIA ORIENTADA A LA ENSEÑANZA DE LOS CONCEPTOS BÁSICOS DE LA PROGRAMACIÓN Y LA ORIENTACIÓN A OBJETOS 48 6.2.1 Identificación de las estrategias. 49 6.2.2 Determinación de una estrategia para enseñar los conceptos básicos de la Programación de Computadores. 50 6.2.3 Diseño e implementación de las prácticas para enseñar los conceptos básicos de programación, a través de la herramienta seleccionada. 55 6.3 EVALUACIÓN DE LA IMPLEMENTACIÓN DE LA ESTRATEGIA 67 7 CONCLUSIONES 77 8 REFERENCIAS Y BIBLIOGRAFIA 79 Maestría The main objective of this work was to evaluate the use of Free Software in teaching the basic concepts of Computer Programming, to identify an alternative strategy in the teaching-learning process. To comply with this objective, it was necessary to identify the Free Software tools used in teaching the basic concepts of Computer Programming, a comparative evaluation of five tools was carried out, through a comparison methodology applying the sum method Weighted and Alice was selected, which was the programming environment that obtained the best results in the comparative evaluation. We proceeded to identify the strategies used in teaching the basic concepts of Computer Programming, using Alice and a teaching model of object-oriented programming was designed to be implemented, through practices with an experimental group of students from the subject algorithms and programming of the School of Systems Engineering and Computation of the Pedagogical and Technological University of Colombia, during the first semester of 2015. Subsequently and with the purpose of evaluating the degree of Alice contribution and the teaching strategy in the students' learning process, a survey was designed to be applied with the experimental group, on the other hand, a final questionnaire was designed and applied to the five Groups of the subject, to evaluate the level of learning of the programmatic contents of the subject, the best results were presented in the experimental group.

La investigación desarrollada en el presente trabajo de grado presenta una propuesta de arquitectura para la identificación personal por medio de un token de seguridad, a través de dispositivos móviles y haciendo uso de sistemas de gobernanza y sensores de proximidad para generar la firma digital o token correspondiente, con el fin de acceder a los servicios web de instituciones (públicas o privadas) de una manera transparente y segura. La propuesta de arquitectura presentada consta de diversos elementos físicos que se encuentran separados geográficamente. La arquitectura, hace uso de varios sistemas que interactúan entre sí a través de servicios web y sistemas NFC, permitiendo de esta manera que cualquier Entidad (pública o privada) pueda registrarse y registrar los servicios que desea ofrecer a sus usuarios con la tranquilidad de que ellos podrán hacer uso de toda una infraestructura (aplicaciones, sistemas de gobernanza) que les permitirá de una manera casi automática y por su puesto segura, identificarse en el consumo de los servicios ofrecidos. Es importante aclarar que para que la arquitectura se pueda aplicar es necesario que las Entidades subscritas habiliten un adaptador en donde expondrán sus servicios de identificación e implementaran las funcionalidades de recibir las firmas generadas, validarlas utilizando un servicio web propio del sistema e identificarlas para conectar de una manera transparente al usuario con los servicios ofrecidos. Las características de este adaptador y los subprocesos que debe tener en cuenta son descritos y explicados en las memorias del presente trabajo de grado. Para validar la arquitectura propuesta, se diseñó y desarrolló una aplicación para Dispositivos Android que implementa el token de seguridad generado para consumir servicios de una Entidad Educativa y un servicio Web utilizado por la Entidad Educativa con la funcionalidad de validar los tokens y capacidad de identificar el dispositivo y los usuarios que están consumiendo sus servicios, el proceso de validación se describe ampliamente en las memorias del presente trabajo de grado Contenido iii 1 INTRODUCCIÓN 1 2 REVISION BIBLIOGRÁFICA 2 2.1 Plataforma para el acceso a servicios desde dispositivos móviles utilizando parámetros de autenticación basados en SIM Card 2 2.2 Ecosistema para la Creación de Firma Digital Avanzada en Movilidad y Autenticación Mediante Elemento Seguro 3 2.3 Análisis De Un Servicio Bancario Móvil Seguro Utilizando Una Aplicación Instalada En La Tarjeta Sim 3 3 MARCO TEÓRICO 5 3.1 Arquitectura orientada a servicios 5 3.2 Web Services 6 3.3 SOAP 6 3.4 Firma digital 7 3.5 Android 7 3.6 NFC 9 3.7 POO 9 3.8 Php 10 3.9 HTML 11 3.10 Apache 11 3.11 Patrón de diseño Modelo-Vista-Controlador (MVC) 12 3.12 UML 13 3.13 Frameworks 14 3.13.1 Zend Framework 14 3.14 IDE's 15 3.14.1 Netbeans 15 3.15 PostgreSQL 16 3.16 Ajax 16 3.17 Jquery 17 3.18 MD5 18 3.19 JSON 18 4 OBJETIVOS 20 4.1 Objetivo general 20 4.2 Objetivos específicos 20 5 METODOLOGÍA 21 5.1 ACTIVIDADES 21 5.1.1 Ambientación del espacio problema 21 5.1.2 Realización del estudio de Caracterización de Componentes de la Arquitectura 21 5.1.3 Diseño del modelo de arquitectura 22 5.1.4 Formalización y Especificación de Casos de Uso 22 5.1.5 Análisis de requisitos de los Sistemas 22 5.1.6 Análisis y requisitos de Software 22 5.1.7 Diseño detallado 22 5.1.8 Desarrollo de Aplicaciones 23 5.1.9 Verificación del modelo 23 5.1.10 Generación de Documento de Tesis 23 6 RESULTADOS DE LA INVESTIGACIÓN 24 6.1 DEFINICIÓN DEL PROCESO 24 6.1.1 Registro de la Entidad 24 6.1.2 Generación del token en el dispositivo del usuario 27 6.1.3 Consumo de los servicios a través del dispositivo 28 6.2 ARQUITECTURA PROPUESTA 31 6.2.1 Características de la solución 31 6.2.2 Diagrama 32 6.2.3 Elementos 33 6.3 SISTEMA DE INFORMACIÓN PARA GOBIERNO EN LINEA – SIGEL 37 6.3.1 SIGEL BD 37 6.3.2 SIGEL WEB 40 6.3.3 Servicios Web 46 6.3.4 SIGEL APP – Android 51 6.3.5 ADMSIGEL NFC 59 6.4 VALIDACIÓN ARQUITECTURA 64 6.4.1 Registro en el SIGEL WEB 65 6.4.2 Generación del Token 72 6.4.3 Consumo Servicio de Logueo 78 7 CONCLUSIONES 83 8 RECOMENDACIONES Y TRABAJOS FUTUROS 84 9 BIBLIOGRAFÍA Y REFERENCIAS 85 Maestría The research developed in this paper has a proposed architecture for personal identification through a security token, through mobile devices and using governance systems and proximity sensors to generate the digital signature or corresponding token in order to access the web services (public or private) institutions in a transparent and secure manner. The proposed architecture has various physical elements that are separated geographically. The architecture uses multiple systems interacting through web services and NFC systems, allowing any entity (public or private) register and register the services you want to provide users, with the assurance that they can use an infrastructure (applications, systems of governance) that it will allow an almost automatic and safe way, identify them in consumption of services offered It is important to clarify that the architecture only can be applied if the entities subscribed, enable an adapter where exposes their identification services and implements the functionalities of receiving the generated signatures and validate it using a proprietary web service system to connect and identify transparently the user with the services offered. The characteristics of this adapter and the sub process that should be considered are described and explained in the memories of this degree work. To validate the proposed architecture, was designed and developed an application for Android devices that implements the security token generated for consume services of an educational institution and a Web service used by the educational institution with the functionality to validate the tokens and ability to identify the device and users who are consuming services, the validation process is widely described in the memoirs of this paper

Para la elaboración de la propuesta metodológica que permita un estudio de flexibilidad curricular en programas de pregrado, se parte de los fundamentos propuestos por Stafford Bear con su Modelo de Sistema Viable(MSV), con la finalidad de formular la identidad organizacional del programa académico en estudio y posteriormente establecer un diagnóstico de su estructura organizacional, a partir de la identificación de cinco subsistemas definidos como: implementación, coordinación, control, inteligencia y política, además de determinar las necesidades de información a partir de las relaciones establecidas entre los subsistemas identificados; incluido el entorno y finalmente soportar el diseño del prototipo de un sistema de información para la gestión de indicadores que guiará a los usuarios finales en el desarrollo de la metodología que permita estructurar varios estudios de flexibilidad curricular en programas académicos, estableciendo los comparativos necesarios a través del tiempo y siendo un suministro fundamentado para futuras reformas curriculares y soporte a los procesos de Acreditación en Alta Calidad. El sistema en foco es el Programa de Ingeniería de Sistemas de Institución Universitaria Centro de Estudios Superiores María Goretti (I.U. CESMAG) ubicada en la Ciudad de Pasto, Nariño (Colombia). Para el desarrollo del prototipo se hace uso de software libre, el cual se ha convertido en un recurso invaluable para la implementación de soluciones informáticas, obteniendo como resultado una aplicación en entorno web. Universitat Oberta de Catalunya UOC INTRODUCCIÓN 16 1. MARCO TEÓRICO 20 1.1 CURRÍCULO Y FLEXIBILIDAD CURRICULAR 20 1.2 MODELO DE SISTEMA VIABLE 24 1.3 INDICADORES DE GESTIÓN 25 2. METODOLOGÍA 28 2.1 Enfoque metodológico 28 2.2 Variables 28 2.3 Población y muestra 29 2.4 Validez y confiabilidad 29 2.5 Apoyos para el procesamiento de la información 30 3. INCORPORACIÓN DEL MSV AL PROGRAMA ACADÉMICO 31 3.1 Formulación de la identidad de la organización 31 3.1.1 Macrosistema. 31 3.1.2 Misión. 32 3.1.3 Visión. 32 3.1.5 Normatividad. 33 3.1.6 Estructura Interna general. 33 3.1 7 Sistema en foco. 34 3.2 Matriz TASCOI 34 3.3 Desdoblamiento de la complejidad 35 3.4 Modelamiento de las componentes estructurales 37 3.4.1 Sistema 1 del sistema en foco 37 3.4.2 Sistema 2 del sistema en foco 44 3.4.3 Sistema 3* del sistema en foco 47 3.4.4 Sistema 3 del sistema en foco 49 3.4.5 Definición de los canales verticales de mando 51 3.4.6 Sistema 4 del sistema en foco 52 3.4.7 Sistema 5 del sistema en foco 54 3.4.8 Sistema de modelamiento VSMOD® 56 3.5 Diagnóstico Organizacional 57 4. PROPUESTA DE INDICADORES DE GESTIÓN 64 4.1 Indicadores de Entorno 66 4.1.1 Factor: Convenios 66 4.1.2 Factor: Mecanismos de ingreso 67 4.1.3 Factor: Movilidad externa 68 4.1.4 Factor: Oferta 69 4.1.5 Factor: Participación social 70 4.2 Indicadores de Gestión 72 4.2.1 Gestión 72 4.3 Indicadores de Operación 73 4.3.1 Factor: Articulación entre funciones sustantivas 73 4.3.2 Factor: Estructura curricular 75 4.3.3 Factor: Movilidad interna 78 4.3.4 Factor: Pedagogía 78 4.4 Hoja de vida de los indicadores 80 5. IMPLANTACIÓN DEL PROTOTIPO DEL SISTEMA DE INFORMACIÓN 82 5.1 Usuarios del Sistema 82 5.1.1 Usuario Administrador 82 5.1.2 Usuario Coordinador del programa 82 5.1.3 Usuario Actor 83 5.2 Requerimientos funcionales del sistema 83 5.2.1 Módulo Administrador 83 5.2.2 Módulo Coordinador 84 5.2.3 Módulo Actor 85 5.3 Requerimientos no funcionales del sistema 85 5.3.1 Rendimiento 85 5.3.2 Seguridad 85 5.3.3 Persistencia 86 5.3.4 Escalabilidad 86 5.3.4 Transporte 86 5.3.5 Visualización 87 5.4 Reglas 87 5.5 Casos de uso 87 5.5.1 Diagramas de casos de uso 87 5.5.2 Descripción de casos de uso 88 5.6 Modelo de base de datos 94 5.7 Modelo de interfaces 94 6. APLICABILIDAD EN ENTORNOS REALES 98 6.1 Desarrollo de la matriz actor – indicador – instrumentos 98 6.2 Sensibilización del proceso 104 6.3 Aplicación IRD 105 6.4 Recolección evidencias documentales 105 6.5 Análisis de resultados 105 6.5.1 Resultados indicadores de gestión en general 107 CONCLUSIONES 109 RECOMENDACIONES Y TRABAJOS FUTUROS 110 REFERENCIAS 111 Maestría For the elaboration of the methodological proposal that allows a study of curricular flexibility in undergraduate programs, we start from the foundations proposed by Stafford Bear with its Viable System Model (MSV), in order to formulate the organizational identity of the academic program in study and later establish a diagnosis of its organizational structure, based on the identification of five subsystems defined as: implementation, coordination, control, intelligence and policy, in addition to determining the information needs from the relationships established between the identified subsystems; including the environment and finally support the design of the prototype of an information system for the management of indicators that will guide end users in the development of the methodology that allows structuring various studies of curricular flexibility in academic programs, establishing the necessary comparisons through of the time and being a well-founded supply for future curricular reforms and support to the High Quality Accreditation processes. The system in focus is the System Engineering Program of the María Goretti Center for Higher Studies (I.U. CESMAG) located in the City of Pasto, Nariño (Colombia). For the development of the prototype, free software is used, which has become an invaluable resource for the implementation of computer solutions, resulting in an application in a web environment.

En este documento se presentan los resultados de una investigación cuyo propósito fue mejorar el aprendizaje de la Programación Orientada a Objetos proponiendo el diseño y uso de ambientes o escenarios constructivistas de Software Libre en el programa de Licenciatura en Informática de la Universidad de Córdoba-Colombia, específicamente para los estudiantes matriculados en la asignatura de Fundamentos de Programación Grupo A 2014-II. Posterior a la construcción del aplicativo se desarrolló un experimento con dos grupos (experimental y control) basado en prácticas de uso del escenario y en guías de aprendizaje de Greenfoot sugeridas por Michael Kölling. Finalmente se evaluó la incidencia e impacto del material diseñado en el rendimiento académico de los estudiantes, llegando a la conclusión que el escenario “La Ronda del Sinú” contribuye a mejorar la comprensión de los conceptos propios de la POO y a potenciar las habilidades para la resolución de problemas. Universitat Oberta de Catalunya UOC INTRODUCCIÓN 11 1. PLANTEAMIENTO DEL PROBLEMA 12 1.1 DESCRIPCIÓN DEL PROBLEMA 12 2. JUSTIFICACIÓN 15 3. OBJETIVOS 17 4. MARCO REFERENCIAL 18 4.1 ESTADO DEL ARTE 18 4.1.1 LOS PARADIGMAS DE PROGRAMACIÓN 23 4.2 MARCO TEÓRICO 25 4.2.1 LA FILOSOFÍA CONSTRUCTIVISTA 25 4.2.2 AMBIENTES DE APRENDIZAJE CONSTRUCTIVISTAS 26 4.2.3 CARACTERÍSTICAS DEL AMBIENTE DE APRENDIZAJE CONSTRUCTIVISTA 27 4.2.4 HERRAMIENTAS CONSTRUCTIVISTAS APLICADAS A LA ENSEÑANZA DE LA PROGRAMACIÓN 29 4.2.4.1 SCRATCH 29 4.2.4.2 ETOYS 30 4.2.4.3 ALICE 31 4.2.4.4 GREENFOOT 32 4.2.4.5 BLUEJ 33 4.2.4.6 PSEINT 33 5. DISEÑO METODOLÓGICO 35 5.1 TIPO DE INVESTIGACIÓN Y ALCANCE 35 5.2 DISEÑO DE INVESTIGACIÓN 35 5.3 HIPÓTESIS 36 5.4 VARIABLES 36 5.4.1 Variable independiente: 36 5.4.2 Variable dependiente: Rendimiento Académico. 36 5.5 POBLACIÓN Y MUESTRA 36 5.6 INSTRUMENTOS Y TÉCNICAS PARA LA RECOLECCIÓN DE LA INFORMACIÓN 37 6. RESULTADOS Y DISCUSIÓN 38 6.1 PRUEBA DIAGNÓSTICA 39 6.2 EQUIVALENCIA INICIAL DE LOS GRUPOS 43 6.3 IMPACTO DEL ESCENARIO “RONDA DEL SINÚ” EN LA ASIMILACIÓN DE CONCEPTOS DE LA POO 45 6.3.1 ANÁLISIS DE RESULTADOS DE LA PREPRUEBA Y POSTPRUEBA DE FORMA INDEPENDIENTE 51 6.4 DISCUSIÓN 52 7. CONCLUSIONES 54 8. RECOMENDACIONES Y TRABAJOS FUTUROS 56 9. REFERENCIAS Y BIBLIOGRAFÍA 57 Maestría This document presents the results of an investigation whose purpose was to improve the learning of Object-Oriented Programming by proposing the design and use of constructivist environments or scenarios of Free Software in the Bachelor's degree program in Computer Science at the University of Córdoba-Colombia, specifically for students enrolled in the Fundamentals of Programming Group A 2014-II course. After the construction of the application, an experiment was developed with two groups (experimental and control) based on the use of the scenario and on Greenfoot learning guides suggested by Michael Kölling. Finally, the incidence and impact of the designed material on the academic performance of the students was evaluated, reaching the conclusion that the scenario “La Ronda del Sinú” contributes to improving the understanding of the concepts of OOP and enhancing the skills for resolution from problems.