• No se han encontrado resultados

Diseño y Desarrollo de la Solución de Software de Gestión de Espacios Físicos en la Universidad Distrital

N/A
N/A
Info
Descargar
Protected

Academic year: 2020

Share "Diseño y Desarrollo de la Solución de Software de Gestión de Espacios Físicos en la Universidad Distrital"

Copied!
54
0
0

Cargando.... (Ver texto completo ahora)

Descargar ahora ( 54 página )

Texto completo

(1)DISEÑO​ ​Y​ ​DESARROLLO​ ​DE​ ​ ​LA SOLUCIÓN​ ​DE​ ​SOFTWARE​ ​DE GESTIÓN​ ​DE​ ​ESPACIOS​ ​FÍSICOS​ ​EN LA​ ​UNIVERSIDAD​ ​DISTRITAL. Javier​ ​Sebastián​ ​Reyes​ ​Mogollón, [email protected]. UNIVERSIDAD​ ​DISTRITAL​ ​FRANCISCO​ ​JOSÉ​ ​DE​ ​CALDAS FACULTAD​ ​DE​ ​INGENIERÍA INGENIERÍA​ ​DE​ ​SISTEMAS Bogotá​ ​D.C,​ ​2017.

(2) 1.

(3) DISEÑO​ ​Y​ ​DESARROLLO​ ​DE​ ​ ​LA SOLUCIÓN​ ​DE​ ​SOFTWARE​ ​DE GESTIÓN​ ​DE​ ​ESPACIOS​ ​FÍSICOS​ ​EN LA​ ​UNIVERSIDAD​ ​DISTRITAL. Trabajo​ ​de​ ​grado​ ​presentado​ ​para​ ​optar​ ​por​ ​el​ ​título​ ​de: INGENIERO​ ​DE​ ​SISTEMAS. Director​ ​Interno: Alejandro​ ​Daza Director​ ​Externo: John​ ​Castellanos Revisor: José​ ​Álvarez. UNIVERSIDAD​ ​DISTRITAL​ ​FRANCISCO​ ​JOSÉ​ ​DE​ ​CALDAS FACULTAD​ ​DE​ ​INGENIERÍA INGENIERÍA​ ​DE​ ​SISTEMAS Bogotá​ ​D.C,​ ​2017 2.

(4) 3.

(5) TABLA​ ​DE​ ​CONTENIDO. INTRODUCCIÓN. 9. CAPÍTULO​ ​1.​ ​PLANTEAMIENTO​ ​DEL​ ​PROBLEMA. 11. CAPÍTULO​ ​2.​ ​OBJETIVOS. 12. 2.1.​ ​Objetivo​ ​general. 12. 2.2.​ ​Objetivos​ ​específicos. 12. CAPÍTULO​ ​3.​ ​JUSTIFICACIÓN. 13. CAPÍTULO​ ​4.​ ​MARCO​ ​REFERENCIAL. 14. 4.1​ ​Oficina​ ​Asesora​ ​de​ ​Planeación​ ​y​ ​Control. 14. CAPÍTULO​ ​5.​ ​MARCO​ ​TEÓRICO. 16. 5.1​ ​El​ ​Kanban. 16. 5.2​ ​Api​ ​Rest. 20. 5.3​ ​Selenium. 22. 5.3.1​ ​Definición. 22. 5.3.2​ ​Características. 23. 5.3.3​ ​Ventajas. 23. 5.4​ ​JMeter. 23. 5.4.1​ ​Definición. 23. CAPÍTULO​ ​6.​ ​ALCANCES​ ​Y​ ​LIMITACIONES. 25. CAPÍTULO​ ​7.​ ​METODOLOGÍA. 26. CAPÍTULO​ ​8.​ ​RECURSOS. 30. CAPÍTULO​ ​9.​ ​PRESUPUESTO. 32. CAPÍTULO​ ​10.​ ​CRONOGRAMA. 33. CAPÍTULO​ ​11.​ ​DESARROLLO. 34. CAPÍTULO​ ​12.​ ​TRABAJOS​ ​FUTUROS. 52. CONCLUSIONES. 53. BIBLIOGRAFÍA. 54. 4.

(6) LISTA​ ​DE​ ​FIGURAS 5-1: Bermejo, Marcos(2010), ilustracion https://www.exabyteinformatica.com. Gestión. 5-2: ​Bermejo, Marcos(2010), ilustración https://www.exabyteinformatica.com. Flujo. equipo. de. según. trabajo. vs. Kanban,recuperado. de. Prioridad,recuperado. de. 6-1: Oficina Asesora de Sistemas, Arquitectura de referencia, ilustración recuperada de: https://tuleap.udistrital.edu.co 6-2: Oficina Asesora de sistemas,Herramientas utilizadas en componentes de la arquitectura de referencia,​ ​ilustración​ ​recuperada​ ​de:​ ​https://tuleap.udistrital.edu.co 10-1:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Cronograma​ ​del​ ​proyecto.. 11-1​:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Tableros​ ​metodología​ ​KANBAN. Tomado​ ​de:​ ​https://tuleap.udistrital.edu.co/plugins/agiledashboard/?group_id=161 11-2:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Diagrama​ ​macro​ ​de​ ​asignar​ ​dependencia 11-3:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Diagrama​ ​detallado​ ​de​ ​asignar​ ​dependencia 11-4:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Registro​ ​dependencia​ ​version​ ​1. 11-5:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Registro​ ​dependencia​ ​version​ ​2. 11-6:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Consultar​ ​dependencia​ ​version​ ​1. 11-7:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Consultar​ ​dependencia​ ​version​ ​2. 11-8:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Recuperar​ ​dependencia​ ​version​ ​1. 11-9:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Recuperar​ ​dependencia​ ​version​ ​2. 11-10:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Registrar​ ​edificio​ ​version​ ​1. 11-11:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Registrar​ ​edificio​ ​version​ ​2. 11-12:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Consultar​ ​edificio​ ​version​ ​2. 11-13:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Consultar​ ​edificio​ ​version​ ​2 11-14:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Recuperar​ ​edificio​ ​version​ ​1. 11-15:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Recuperar​ ​edificio​ ​version​ ​2. 11-16:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Registrar​ ​Espacio​ ​Físico​ ​version​ ​1. 11-17:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Registrar​ ​Espacio​ ​Físico​ ​version​ ​1. 11-18:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Consultar​ ​Espacio​ ​Físico​ ​version​ ​1. 11-19:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Consultar​ ​Espacio​ ​Físico​ ​version​ ​2. 11-20:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Consultar​ ​Espacio​ ​Físico​ ​version​ ​1. 11-21:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Consultar​ ​Espacio​ ​Físico​ ​version​ ​2 11-22:​ ​REGISTRO​ ​SEDE​ ​VERSIÓN​ ​2. 5.

(7) 11-23:​ ​CONSULTAR​ ​SEDE​ ​VERSIÓN​ ​1 11-24:​ ​CONSULTAR​ ​SEDE​ ​VERSIÓN​ ​2 11-25:​ ​RECUPERAR​ ​SEDE​ ​VERSIÓN​ ​1 11-26:​ ​RECUPERAR​ ​SEDE​ ​VERSIÓN​ ​2 11-27:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Arquitectura​ ​de​ ​información​ ​para​ ​OIKOS. 11-28:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Modelo​ ​de​ ​datos​ ​OIKOS. 11-29:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Espacio​ ​físico. 11-30:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Tipo​ ​uso. 11-31:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Tipo​ ​uso​ ​espacio​ ​físico. 11-32:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Tipo​ ​espacio​ ​físico. 11-33:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Espacio​ ​físico​ ​padre. 11-34:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Dependencia. 11-35:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Dependencia​ ​padre.. 6.

(8) LISTA​ ​DE​ ​TABLAS 8-1.​ ​Recursos​ ​del​ ​proyecto. 9-1.​ ​Presupuesto​ ​del​ ​proyecto. 11-1:​ ​Descripción​ ​entidad​ ​espacio_fisico. 11-2:​ ​Descripción​ ​entidad​ ​tipo_uso. 11-3:​ ​Descripción​ ​entidad​ ​tipo_uso_espacio_fisico. 11-4:​ ​Descripción​ ​entidad​ ​tipo_espacio_fisico. 11-5:​ ​Descripción​ ​entidad​ ​espacio_fisico_padre 11-6:​ ​Descripción​ ​entidad​ ​dependencia. 11-7:​ ​Descripción​ ​entidad​ ​dependencia​ ​padre.. 7.

(9) INTRODUCCIÓN La Universidad Distrital Francisco José de Caldas es un ente autónomo de Educación Superior que se fundó en el año 1948, su misión se centra en las funciones de docencia, investigación y extensión. Dentro de la institución se cuenta con la necesidad de una correcta gestión de procesos donde el software toma un papel relevante ya que permite llevar a cabo actividades imprescindibles que infieren en el funcionamiento y consecución de​ ​resultados​ ​en​ ​la​ ​universidad. La gestión de espacios físicos se dimensiona dentro de la utilidad de poder conocer con qué espacios cuenta la universidad en cuestión de lugares tanto administrativos como académicos en la totalidad de la universidad, para ello es necesario un software donde se puedan registrar espacios con los distintos atributos y entidades que puede tener un modelo acorde​ ​a​ ​las​ ​características​ ​de​ ​la​ ​universidad. Con el fin de realizar mejoras y congruencias de unificación en el proceso de gestión de espacios físicos de la universidad distrital, la Oficina Asesora de Sistema (OAS), en su potestad de crear nuevas soluciones de software para el ente educativo, crea el proyecto denominado “​Solución de software para apoyar el proceso de gestión de espacios físicos de la universidad Distrital​”, realizando un proceso de llamado y selección a estudiantes de últimos semestres que cursan ingeniería de sistemas que deseen participar en el mismo, donde finalmente se cuenta con 9 integrantes divididos en subproyectos correspondientes a: gestión de requerimientos, arquitectura de software y desarrollo de software, a cargo de los​ ​roles​ ​respectivos​ ​de​ ​analistas,​ ​arquitectos​ ​y​ ​desarrolladores. Este proyecto en el que se participará con el rol de Analista y desarrollador, tiene como objetivo analizar, diseñar y construir una solución modular, integral y escalable que permita apoyar los procesos relacionados a la gestión de espacios físicos de la Universidad Distrital soportado en tecnologías libres siguiendo el proceso de desarrollo bajo la metodología Kanban. El Software que maneja la Universidad Distrital para soportar los proceso de la dependencia de planeación para la gestión de espacios físicos muestra como principal problemática la desactualización normal que posee cualquier software y la integrabilidad, no acomodación del​ ​mismo​ ​a​ ​los​ ​procesos​ ​y​ ​procedimientos​ ​de​ ​la​ ​ ​Universidad. El proyecto plantea dotar a la Universidad Distrital Francisco José de Caldas de un sistema de información de la dependencia de planeación que supla las particularidades en el manejo de la información para la gestión de espacios y su articulación con el sistema integrado de información de la universidad, que pueda mantener y adaptar la misma institución y que esté acorde a las nuevas tecnologías de la información y las comunicaciones como los son Web​ ​services.. 8.

(10) Para ello se presenta una propuesta con los módulos que tendrá el sistema, la arquitectura que se manejará y los costos tanto humanos como de infraestructura desde su etapa de concepción hasta la estabilización y puesta total en producción, se aclara que se entregarán periódicamente módulos funcionales del sistema para que entren en funcionamiento de manera​ ​iterativa.. 9.

(11) CAPÍTULO​ ​1.​ ​PLANTEAMIENTO​ ​DEL​ ​PROBLEMA El orden de los espacios físicos de la universidad Distrital se establece con la correcta gestión e información actualizada sobre lo que cuenta la universidad para el desarrollo de sus actividades de la comunidad universitaria, esto contempla espacios físicos de tipo académico como de tipo administrativo, dicha información va relacionada con los recursos que los estudiantes y funcionarios de la universidad pueden acaparar en sus actividades, por ello se hace necesario un software que contemple de manera adaptable, eficaz y eficiente​ ​todos​ ​aquellos​ ​procesos​ ​pertenecientes​ ​a​ ​la​ ​gestión​ ​de​ ​espacios​ ​físicos. Es necesario por parte de los trabajadores de la universidad contar con dicho software que provea información estructurada completa y actualizada sobre los espacios físicos que cuenta la universidad, que satisfaga las necesidades pertinentes, que provea consultas que pueden dar concisa respuesta a los requerimientos de los involucrados, esto con el fin de hacer​ ​los​ ​procesos​ ​más​ ​rápidos​ ​y​ ​eficaces. Debido a que el sistema de información actual fue concebido para manejar la información de forma propia de acuerdo a las necesidades de la dependencia de planeación y no de forma integrada, se han presentados varios problemas con la calidad de la información que maneja. Estos y otros problemas han sido evidenciados en diversas auditorías que se han hecho​ ​al​ ​interior​ ​de​ ​la​ ​Universidad​ ​y​ ​también​ ​por​ ​entes​ ​externos​ ​a​ ​la​ ​misma​ ​institución. ¿Cómo integrar un sistema de información con arquitectura orientada a servicios que se articule con los demás sistemas y permitir la gestión de los espacios físicos académicos y administrativos​ ​por​ ​parte​ ​de​ ​la​ ​dependencia​ ​de​ ​planeación?. El sistema de información para la gestión de espacios físicos es una solución para los requerimientos de la dependencia de planeación que permitirá un mejor acceso a la información de los espacios físicos con los que cuenta la universidad, esto con tecnologías que dan respuesta a las características de un software moderno y eficiente como son los web​ ​services.. 10.

(12) CAPÍTULO​ ​2.​ ​OBJETIVOS 2.1.​ ​Objetivo​ ​general Desarrollar una solución modular, integral y escalable, que permita apoyar los procesos relacionados a la gestión de espacio físicos de la Universidad Distrital, soportado en tecnologías libres de acuerdo a los estándares definidos por la OAS (Oficina Asesora de Sistemas). 2.2.​ ​Objetivos​ ​específicos ●. Establecer mecanismos de acceso, consulta y modificación de datos respecto a los espacios físicos y organigrama institucional de la Universidad Distrital con el fin de optimizar​ ​la​ ​gestión​ ​de​ ​estos.. ●. Definir un modelo de datos único de espacios físicos y organigrama institucional que soporte​ ​los​ ​procesos​ ​de​ ​gestión​ ​de​ ​la​ ​información.. ●. Articular la solución de software con los servicios ya implementados en la OAS, con el​ ​fin​ ​de​ ​integrar​ ​la​ ​información.. ●. Definir un ciclo de pruebas para la solución de software que se enmarque en la consecución​ ​de​ ​la​ ​calidad​ ​del​ ​sistema​ ​a​ ​integrar.. 11.

(13) CAPÍTULO​ ​3.​ ​JUSTIFICACIÓN Debido a que la universidad cuenta con un sistema de espacios físicos antiguo con errores de diseño en el modelo de base de datos, se busca solucionar el problema de la gestión de espacios físicos con un nuevo software utilizando tecnologías modernas, con el fin de elaborar y contemplar las nuevas necesidades de la universidad en cuanto a crecimiento de los​ ​espacios​ ​físicos. El proyecto de gestión de espacios físicos se lleva a cabo de acuerdo al requerimiento de modernización de los sistemas de información actuales; teniendo en cuenta que el antiguo sistema tiene una arquitectura monolítica, que funciona aisladamente y no se integra con todas las herramientas, por tanto al no integrarse con los sistemas actuales de la universidad su funcionamiento se ve limitado y no comparte a nivel de diseño las características deseables de un óptimo sistema de información ya que tiene un diseño de base de datos no normalizado, por tal razón con el nuevo sistema de información se pretende dar una solución de software coherente con las necesidades actuales con tecnologías validadas por la OAS que convergen a una planeación de arquitectura dinámica y​ ​escalable.. 12.

(14) CAPÍTULO​ ​4.​ ​MARCO​ ​REFERENCIAL 4.1​​ ​Oficina​ ​Asesora​ ​de​ ​Planeación​ ​y​ ​Control. La dependencia Oficina Asesora de Planeación y Control tiene como misión: Coordinar y orientar el diseño y la implementación de Políticas, Planes, Programas y Proyectos, brindando métodos, procedimientos y herramientas técnicas que apoyen a la toma de decisiones y permitan responder adecuadamente a los cambios del entorno y el desarrollo de​ ​la​ ​Universidad.. 4.1.1¿Qué​ ​es​ ​la​ ​planeación? En el Plan Estratégico de Desarrollo se materializa los cambios en las relaciones de poder y los recursos (financieros, económicos, culturales y tecnológicos) para consolidar el ser y proyectar​ ​el​ ​devenir​ ​de​ ​la​ ​Universidad.. 4.1.2 ¿Cuáles son las dimensiones del proceso de planeación? 1.. Definición de los fines y los objetivos colectivos de mediano y largo plazo de la universidad: La planeación implica una identificación y definición de una idea de futuro representada a través de objetivos de mediano y largo plazo que recogen los intereses de los diferentes grupos en disputa. Estos objetivos señalan las líneas de la discusión y proyectan los requerimientos y asignación de recursos de la universidad. Los enfoques de prospectiva pueden ser útiles para establecer estos objetivos de mediano y largo plazo, las cuales están influenciadas por los objetivos.. 2.. Distribución de la incertidumbre: La planeación afecta los flujos de información en la comunidad universitaria, es decir, la planeación afecta la disponibilidad de la información, las formas de comunicación, las dependencias encargadas de su flujo y las personas que tienen acceso a ella. En consecuencia, la planeación distribuye la incertidumbre entre las personas de la comunidad universitaria, esta distribución​ ​puede​ ​ser​ ​desigual​ ​o​ ​igualitaria​ ​y​ ​depende​ ​de​ ​la​ ​idea​ ​de​ ​futuro.. 3.. Distribución de las responsabilidades: Otra de las dimensiones sobre las cuales se representa la distribución del poder, está relacionada con las responsabilidades que se establecen en los procesos de planeación. En los procesos​ ​de​ ​planeación​ ​se​ ​redistribuyen​ ​las​ ​cargas​ ​en​ ​la​ ​universidad.. 4.. Cambios en los roles sociales: Los planes crean y altera los roles sociales y las oportunidades de los grupos de interés en la toma de decisiones en la universidad.. 13.

(15) Por ejemplo, la creación de un comité o una nueva dependencia en las universidades​ ​implica​ ​nuevas​ ​funciones,​ ​limitaciones,​ ​posibilidades​ ​y​ ​relaciones.. 4.1.3 Sobre planeación. el. proyecto. educativo. institucional. y. El Proyecto Educativo Institucional (PEI) y los Planes de Desarrollo son dos elementos fundamentales para la gobernanza de las Universidades. En el Proyecto Educativo Institucional se concreta el ser de la Universidad (presente) y la Universidad que quiere ser (futuro)​ ​a​ ​partir​ ​de​ ​su​ ​desarrollo​ ​histórico​ ​(pasado).. 14.

(16) CAPÍTULO​ ​5.​ ​MARCO​ ​TEÓRICO 5.1​ ​El​ ​Kanban 5.1.1​ ​Definición. Kanban (en kanji, donde kan significa "visual", y ban significa "tarjeta" o "tablero") es un concepto de producción justo-a-tiempo (JIT). El kanban es una tarjeta física que se utiliza en el Sistema de Producción de Toyota (TPS - Toyota Production System) para soportar un control productivo descentralizado por demanda (“pull”). Kanban es una herramienta proveniente de la filosofía Lean, de tipo “pull”, lo que significa que los recursos deciden cuándo y cuánto trabajo se comprometen a hacer. Los recursos toman (“pull”) el trabajo cuando están listos, en lugar de tener que recibirlo (“push”) desde el exterior. Al igual que una impresora tira en la página siguiente sólo cuando está lista para imprimir sobre ella. Kanban se basa en la optimización de procesos continuos y empíricos, que se corresponde con el principio de Kaizen Lean. Enfatiza la respuesta al cambio por sobre seguir un plan (generalmente​ ​Kanban​ ​permite​ ​una​ ​respuesta​ ​más​ ​rápida​ ​que​ ​Scrum). El Kanban es un sistema de gestión donde se produce exactamente aquella cantidad de trabajo que el sistema es capaz de asumir. El Kanban es un sistema de gestión del trabajo en curso, que sirve principalmente para asegurar una producción continua y sin sobrecargas en el equipo de producción multimedia. El Kanban es un sistema de gestión donde se produce exactamente aquella cantidad de trabajo que el sistema es capaz de asumir. El Kanban es un sistema de trabajo just in time, lo que significa que evita sobrantes innecesarios de stock, que en la gestión de proyectos multimedia equivale a la inversión innecesaria de tiempo y esfuerzo en lo que no necesitaremos (o simplemente es menos prioritario) y evita sobrecargar al equipo. El Kanban es una aproximación a la gestión del cambio organizativo, no es un proceso de desarrollo de productos multimedia o de gestión de proyectos. El Kanban es una aproximación a la introducción de cambios en el ciclo de vida de desarrollo de productos multimedia o metodología de gestión de proyectos ya existente. Con el Kanban, se empieza con algo en lo que estás ahora mismo en la gestión de nuestro equipo de producción. No hay que empezar de cero en la organización de una empresa para adoptar el Kanban. En la gestión del trabajo en curso con Kanban, se busca un concepto clave como es limitar el trabajo en curso. Está demostrado que, cuanto más trabajo en curso se gestione a la vez, los índices de calidad disminuyen drásticamente. En la producción de proyectos multimedia, aumentar el trabajo en curso implica aumentar la cantidad de errores que este proyecto multimedia tendrá como consecuencia de la poca capacidad de concentración que los desarrolladores podrán dedicar a las tareas. Limitar el WIP implica un aumento considerable de la calidad del software generado en la producción de un proyecto multimedia. Limitar el trabajo en curso mediante la gestión del trabajo con Kanban también tiene una consecuencia importante y es que disminuimos el tiempo de servicio de una tarea desde que entra al sistema hasta que sale. Disminuyendo la cantidad de trabajo en curso, conseguimos que el enfoque en cada una de las tareas sea mayor y que el tiempo dedicado a todas ellas, sumado, sea menor que el empleado en asumirlas todas​ ​de​ ​golpe. 15.

(17) 5.1.2​ ​Funcionamiento​ ​del​ ​kanban Visualiza​ ​el​ ​“Workflow” Divide el trabajo en piezas, y escribe cada una de ellas en tarjetas que se colocan en el tablero (“kanban board”). o Utiliza columnas con nombres para ilustrar dónde se encuentra dentro​ ​del​ ​proceso​ ​o​ ​workflow​ ​cada​ ​ítem​ ​o​ ​tarea. Limita el “WIP” (work in progress) – asigna limites específicos de cuantos items pueden estar​ ​siendo​ ​procesados​ ​a​ ​la​ ​vez​ ​dentro​ ​de​ ​cada​ ​columna​ ​del​ ​workflow. Mide el “Lead Time” (también llamado “Cycle Time”) es el tiempo promedio para completar un item, o sea, que el mismo haya pasado por todas las columnas del workflow hasta llegar al final. El Kanban tiene por objetivo optimizar el proceso para hacer el lead time lo más pequeño​ ​y​ ​predecible​ ​que​ ​se​ ​pueda.. 5.1.3​ ​Aplicación​ ​práctica​ ​del​ ​kanban Para hacer más comprensible la aplicación práctica del Kanban, en este apartado vamos a imaginar un caso típico de la producción de proyectos multimedia, donde tenemos un equipo dedicado a dar servicio de esta clase de productos. En concreto, el servicio que proporciona este equipo se basa en el desarrollo de pequeñas tareas evolutivas de un producto ya instalado en casa del cliente. Nuestro equipo trabaja para diferentes clientes, que tienen contratado un servicio de mantenimiento donde desarrolla estos pequeños plug-ins a medida que los clientes van pidiendo. El equipo está dividido en tres programadores, uno de ellos es analista-programador (el que tiene más experiencia) y un técnico experto en sistemas, este último es el que se dedica a solucionar problemas relacionados con configuraciones de servidor, además de pasar la fase de pruebas y calidad. Supongamos que la realidad actual de este equipo es algo caótica. Están trabajando en varias tareas previstas para el mes que viene, además, día a día apagan varios fuegos debido a errores en desarrollos anteriores y podemos decir que el tiempo dedicado a testear es más bien corto, debido a las constantes tomas para cumplir los tiempos de entrega. Las predicciones y fechas de entrega no sirven, ya que se ven rotas por tareas​ ​más​ ​urgentes​ ​que​ ​les​ ​roban​ ​tiempo.. 5-1:​ ​Bermejo,​ ​Marcos(2010),​ ​ilustracion​ ​Gestión​ ​equipo​ ​según​ ​Kanban,recuperado​ ​de https://www.exabyteinformatica.com. 16.

(18) Entras en este equipo y nos piden gestionarlo. Por suerte, conoces el Kanban y empiezas a aplicarlo. Lo primero que tenemos que hacer en este equipo es representar su realidad actual​ ​de​ ​forma​ ​visual. La forma más habitual de aplicar el Kanban en la producción de productos multimedia es mediante el visual management, es decir, la representación visual del flujo de trabajo mediante​ ​paneles​ ​que​ ​tienen​ ​que​ ​reflejar​ ​la​ ​realidad​ ​del​ ​equipo​ ​en​ ​cada​ ​instante. ●. Tenemos que dar luz a todas las fases por las que pasan las tareas desde que entran​ ​en​ ​el​ ​sistema​ ​hasta​ ​que​ ​salen.. ●. Representar visualmente las tareas que el equipo está llevando a cabo ahora mismo.. ●. Aporta mucha información visual indicar qué miembro del equipo está ejecutando cada​ ​tarea.. Asegurate de que el panel Kanban refleja las fases, las tareas y el equipo. Un panel Kanban típico​ ​se​ ​implementaría​ ​tal​ ​como​ ​se​ ​muestra​ ​en​ ​la​ ​imagen​ ​siguiente:. 5-2:​ ​Bermejo,​ ​Marcos(2010),​ ​ilustración​ ​Flujo​ ​de​ ​trabajo​ ​vs​ ​Prioridad ,recuperado​ ​de​ ​https://www.exabyteinformatica.com. En esta imagen se observa un panel constituido por tres columnas, que representan las diferentes fases por las que una tarea tiene que fluir para ser desarrollada (análisis, desarrollo y puesta en marcha). Cada fase está subdividida en dos estados, que son en curso y lista, para pasar a la siguiente fase; esta división está representada por la línea discontinua de cada fase. El estado en curso significa que el equipo está actualmente trabajando en esta tarea, en esta fase y el estado lista significa que el equipo ya ha acabado el trabajo que tenía que ejecutar en esta fase y la tarea está esperando a que el sistema pueda asumirla para la siguiente fase. Esta división ayuda a localizar atascos en el proceso 17.

(19) de producción, se aprenderá más adelante en el módulo. Las filas podrían ser diferentes proyectos en los que la empresa está trabajando, pero lo más habitual es que las filas indiquen​ ​prioridad,​ ​donde​ ​las​ ​tareas​ ​más​ ​superiores​ ​son​ ​las​ ​más​ ​prioritarias. Separar en cada fase las tareas en el estado en curso y lista ayuda a localizar atascos en el proceso​ ​de​ ​producción​ ​de​ ​productos​ ​multimedia. El panel Kanban tiene que ser estudiado y juzgado en cada iteración para detectar fases que falten o sobren. Nunca hay que adoptar un panel como solución universal. En la gestión del trabajo en curso con Kanban, no existe un único modelo de panel adecuado para todos los equipos ni que cumpla todas las necesidades de la empresa. Un error frecuente de aquellos que empiezan a implantar Kanban en el equipo es intentar adoptar las fases de un modelo de panel externo en la realidad de la producción de su equipo. No se trata de cambiar las fases por otras, sino de estudiarlas, comprenderlas y hacerlas visibles. Cuando se adopta Kanban, el panel tiene que ser construido y mejorado constantemente. En la gestión ágil de proyectos, una de las claves fundamentales es la iteración constante y la mejora a cada iteración. Como buenos agilistas, el panel Kanban tiene que ser estudiado y juzgado en cada iteración para detectar fases que falten o sobren. En el Kanban no existe un único modelo de panel adecuado para todos los equipos ni todas las situaciones. Simplemente​ ​representa​ ​de​ ​forma​ ​fiel​ ​la​ ​producción​ ​del​ ​equipo. Al acabar el primer mes como jefe de proyecto en el equipo del ejemplo presentado en la introducción de este apartado, se tiene un bonito panel Kanban en una de las paredes de la sala donde tenemos representada la realidad de nuestro equipo. El equipo lo mantiene actualizado de forma constante para que realmente represente el estado actual de los proyectos​ ​en​ ​curso. En el panel del ejemplo, tenemos tareas que fluyen de izquierda a derecha de la siguiente manera: • Los dos programadores están actualmente produciendo la funcionalidad de D, E y F en simultáneo. A la vez, el experto de sistemas está testeando en la actualidad la funcionalidad​ ​M. • Mientras tanto, el analista-programador ha hecho el análisis y la estimación de algunas tareas nuevas que les han encomendado, esta estimación es muy importante, puesto que en ella se basa el presupuesto que la empresa hace de las tareas​ ​que​ ​el​ ​equipo​ ​lleva​ ​a​ ​cabo. • A medida que el tiempo va pasando, los dos programadores van desarrollando a buen​ ​ritmo,​ ​tienen​ ​acabados​ ​seis​ ​módulos​ ​y​ ​están​ ​programando​ ​otros. • El experto en sistemas está teniendo problemas, el módulo M no pasa algunos de los requerimientos de calidad de la empresa y solo él sabe cómo se hace, además, tiene problemas para instalar algunas tareas ya terminadas (N) en algunos clientes debido​ ​a​ ​la​ ​configuración​ ​de​ ​sus​ ​servidores 18.

(20) • Solo una tarea ha sido registrada como finalizada en este mes (la tarea O) y, por lo tanto, solo un cliente ha recibido su petición con éxito. El panel Kanban parece que señala el problema clave del equipo: ¿por qué seguimos programando más y más funcionalidades cuando muy pocas salen del sistema? En definitiva: Un porcentaje muy bajo del esfuerzo y tiempo del equipo se está convirtiendo finalmente en ingresos​ ​y​ ​satisfacción​ ​del​ ​cliente.. 5.2​ ​Api​ ​Rest 5.2.1​ ​Definición REST cambió por completo la ingeniería de software a partir del 2000. Este nuevo enfoque de desarrollo de proyectos y servicios web fue definido por Roy Fielding, el padre de la especificación HTTP y uno los referentes internacionales en todo lo relacionado con la Arquitectura de Redes, en su disertación ‘Architectural Styles and the Design of Network-based Software Architectures’. En el campo de las APIs, REST (Representational State Transfer- Transferencia de Estado Representacional) es, a día de hoy, el alfa y omega del​ ​desarrollo​ ​de​ ​servicios​ ​de​ ​aplicaciones. En la actualidad no existe proyecto o aplicación que no disponga de una API REST para la creación de servicios profesionales a partir de ese software. Twitter, YouTube, los sistemas de identificación con Facebook… hay cientos de empresas que generan negocio gracias a REST y las APIs REST. Sin ellas, todo el crecimiento en horizontal sería prácticamente imposible. Esto es así porque REST es el estándar más lógico, eficiente y habitual en la creación​ ​de​ ​APIs​ ​para​ ​servicios​ ​de​ ​Internet. Buscando una definición sencilla, REST es cualquier interfaz entre sistemas que use HTTP para obtener datos o generar operaciones sobre esos datos en todos los formatos posibles, como XML y JSON. Es una alternativa en auge a otros protocolos estándar de intercambio de datos como SOAP (Simple Object Access Protocol), que disponen de una gran capacidad pero también mucha complejidad. A veces es preferible una solución más sencilla​ ​de​ ​manipulación​ ​de​ ​datos​ ​como​ ​REST.. 5.2.2​ ​Características ●. Protocolo cliente/servidor sin estado: cada petición HTTP contiene toda la información necesaria para ejecutarla, lo que permite que ni cliente ni servidor necesiten recordar ningún estado previo para satisfacerla. Aunque esto es así, algunas aplicaciones HTTP incorporan memoria caché. Se configura lo que se conoce como protocolo cliente-caché-servidor sin estado: existe la posibilidad de definir algunas respuestas a peticiones HTTP concretas como cacheables, con el objetivo de que el cliente pueda ejecutar en un futuro la misma respuesta para 19.

(21) peticiones idénticas. De todas formas, que exista la posibilidad no significa que sea lo​ ​más​ ​recomendable. ●. Las operaciones más importantes relacionadas con los datos en cualquier sistema REST y la especificación HTTP son cuatro: POST (crear), GET (leer y consultar), PUT​ ​(editar)​ ​y​ ​DELETE​ ​(eliminar).. ●. Los objetos en REST siempre se manipulan a partir de la URI. Es la URI y ningún otro elemento el identificador único de cada recurso de ese sistema REST. La URI nos facilita acceder a la información para su modificación o borrado, o, por ejemplo, para​ ​compartir​ ​su​ ​ubicación​ ​exacta​ ​con​ ​terceros.. ●. Interfaz uniforme: para la transferencia de datos en un sistema REST, este aplica acciones concretas (POST, GET, PUT y DELETE) sobre los recursos, siempre y cuando estén identificados con una URI. Esto facilita la existencia de una interfaz uniforme​ ​que​ ​sistematiza​ ​el​ ​proceso​ ​con​ ​la​ ​información.. ●. Sistema de capas: arquitectura jerárquica entre los componentes. Cada una de estas​ ​capas​ ​lleva​ ​a​ ​cabo​ ​una​ ​funcionalidad​ ​dentro​ ​del​ ​sistema​ ​REST.. ●. Uso de hipermedios: hipermedia es un término acuñado por Ted Nelson en 1965 y que es una extensión del concepto de hipertexto. Ese concepto llevado al desarrollo de páginas web es lo que permite que el usuario puede navegar por el conjunto de objetos a través de enlaces HTML. En el caso de una API REST, el concepto de hipermedia explica la capacidad de una interfaz de desarrollo de aplicaciones de proporcionar al cliente y al usuario los enlaces adecuados para ejecutar acciones concretas​ ​sobre​ ​los​ ​datos.. ●. Para cualquier API REST es obligatorio disponer del principio HATEOAS (Hypermedia As The Engine Of Application State - Hipermedia Como Motor del Estado de la Aplicación) para ser una verdadera API REST. Este principio es el que define que cada vez que se hace una petición al servidor y éste devuelve una respuesta, parte de la información que contendrá serán los hipervínculos de navegación​ ​asociada​ ​a​ ​otros​ ​recursos​ ​del​ ​cliente.. 5.2.3​ ​Ventajas 1. Separación entre el cliente y el servidor: el protocolo REST separa totalmente la interfaz de usuario del servidor y el almacenamiento de datos. Eso tiene algunas ventajas cuando se hacen desarrollos. Por ejemplo, mejora la portabilidad de la interfaz a otro tipo de plataformas, aumenta la escalabilidad de los proyectos y permite que los distintos componentes de los desarrollos se puedan evolucionar de forma​ ​independiente. 20.

(22) 2. Visibilidad, fiabilidad y escalabilidad. La separación entre cliente y servidor tiene una ventaja evidente y es que cualquier equipo de desarrollo puede escalar el producto sin excesivos problemas. Se puede migrar a otros servidores o realizar todo tipo de cambios en la base de datos, siempre y cuando los datos de cada una de las peticiones se envían de forma correcta. Esta separación facilita tener en servidores distintos el front y el back y eso convierte a las aplicaciones en productos más flexibles​ ​a​ ​la​ ​hora​ ​de​ ​trabajar. 3. La API REST siempre es independiente del tipo de plataformas o lenguajes: la API REST siempre se adapta al tipo de sintaxis o plataformas con las que se estén trabajando, lo que ofrece una gran libertad a la hora de cambiar o probar nuevos entornos dentro del desarrollo. Con una API REST se pueden tener servidores PHP, Java, Python o Node.js. Lo único que es indispensable es que las respuestas a las peticiones se hagan siempre en el lenguaje de intercambio de información usado, normalmente​ ​XML​ ​o​ ​JSON.. 5.3​ ​Selenium 5.3.1​ ​Definición La automatización de pruebas que consiste en utilizar una herramienta de software para ejecutar las pruebas repetibles en contra de la aplicación a ensayar. Para las pruebas de regresión​ ​esta​ ​establece​ ​que​ ​la​ ​capacidad​ ​de​ ​respuesta. Selenium es un entorno de pruebas de software para aplicaciones basadas en la web. Selenium provee una herramienta llamada (Selenium IDE) para crear pruebas sin usar un lenguaje de scripting. Incluye también un ​lenguaje específico de dominio para pruebas para escribir pruebas en un amplio número de lenguajes de programación populares incluyendo Java​, ​C#​, ​Ruby​, ​Groovy​, ​Perl​, ​Php y ​Python​. Las pruebas pueden ejecutarse entonces usando la mayoría de los ​navegadores web modernos en diferentes sistemas operativos como​ ​Windows​,​ ​Linux​​ ​y​ ​OSX​. Es definido también como un conjunto de herramientas de software diferentes, cada uno con un enfoque diferente para el apoyo a la automatización de pruebas. La mayoría de los ingenieros del QA de selenium se centran en uno o dos herramientas que la mayoría satisfacer las necesidades de su proyecto, sin embargo el aprendizaje de todas las herramientas le dará muchas opciones diferentes para abordar diferentes problemas de automatización de pruebas. Todo el conjunto de herramientas se traduce en un amplio conjunto de funciones de prueba dirigidos específicamente a las necesidades de las pruebas de aplicaciones web de todo tipo. Estas operaciones son muy flexibles, lo que permite muchas opciones para la localización de elementos de la interfaz y la comparación de los resultados esperados de la prueba contra el comportamiento de la aplicación real. Una de las características clave de selenium es el apoyo para la ejecución de las pruebas de​ ​uno​ ​en​ ​múltiples​ ​plataformas​ ​de​ ​navegadores.. 21.

(23) 5.3.2​ ​Características El selenium se compone de múltiples herramientas de software, las cuales varían en sus características.. Selenium​ ​2 Es la dirección futura del proyecto y la nueva adición a la caja de herramientas de selenio. Esta nueva herramienta de automatización ofrece todo tipo de características impresionantes, incluyendo una API más coherente y orientado a objetos, así como una respuesta​ ​a​ ​las​ ​limitaciones​ ​de​ ​la​ ​aplicación​ ​de​ ​edad.. 5.3.3​ ​Ventajas La automatización de pruebas tiene ventajas específicas para la mejora de la eficacia a largo plazo de los procesos de prueba de un equipo de software. La automatización de pruebas​ ​es​ ​compatible​ ​con: ● ● ● ● ● ● ●. Pruebas​ ​de​ ​regresión​ ​frecuentes. Una​ ​rápida​ ​retroalimentación​ ​a​ ​los​ ​desarrolladores. Iteraciones​ ​prácticamente​ ​ilimitadas​ ​de​ ​ejecución​ ​de​ ​casos​ ​de​ ​prueba. Soporte​ ​para​ ​Ágil​ ​y​ ​metodologías​ ​de​ ​desarrollo​ ​extremas. Documentación​ ​disciplinado​ ​de​ ​casos​ ​de​ ​prueba. Notificación​ ​de​ ​defectos​ ​personalizado. Encontrar​ ​defectos​ ​pasados​ ​por​ ​alto​ ​por​ ​las​ ​pruebas​ ​manuales.. 5.4​ ​JMeter 5.4.1​ ​Definición Es una aplicación de software de código abierto, una aplicación Java puro 100% diseñado para cargar la conducta funcional de prueba y medida de rendimiento. Fue diseñado originalmente para aplicaciones Web de prueba, pero desde entonces se ha expandido a otras​ ​funciones​ ​de​ ​prueba. Jmeter se puede utilizar para probar el rendimiento tanto en recursos estáticos y dinámicos, aplicaciones​ ​dinámicas​ ​Web. Se puede utilizar para simular una carga pesada en un servidor, grupo de servidores, la red o el objeto a probar su resistencia o para analizar el rendimiento general bajo diferentes tipos​ ​de​ ​carga.. 22.

(24) Jmeter​ ​características​ ​incluyen: ● Capacidad de cargar y pruebas de rendimiento muchos tipos diferentes aplicaciones /​ ​servidor​ ​/​ ​protocolo: ○ Web​ ​-​ ​HTTP,​ ​HTTPS​ ​(Java,​ ​NodeJS,​ ​PHP,​ ​ASP.NET,​ ​...) ○ SOAP​ ​/​ ​REST​ ​Servicios​ ​Web. ○ FTP. ○ Base​ ​de​ ​datos​ ​a​ ​través​ ​de​ ​JDBC. ○ LDAP. ○ Middleware​ ​orientado​ ​a​ ​mensajes​ ​(MOM)​ ​a​ ​través​ ​de​ ​JMS. ○ Correo​ ​-​ ​SMTP​ ​(S),​ ​POP3​ ​(S)​ ​e​ ​IMAP​ ​(S). ○ Comandos​ ​o​ ​scripts​ ​de​ ​shell​ ​nativa. ○ TCP. ○ Objetos​ ​Java. ● ●. ● ● ● ● ● ●. IDE con todas las funciones de prueba que permite Plan de prueba rápida de grabación​ ​(de​ ​navegadores​ ​o​ ​aplicaciones​ ​nativas),​ ​construcción​ ​y​ ​depuración​ ​. El modo de línea de comandos (modo sin cabeza para no GUI /) para cargar de prueba desde cualquier sistema operativo compatible con Java (Linux, Windows, Mac​ ​OS​ ​X,​ ​...). Una​ ​completa​ ​y​ ​el​ ​informe​ ​listo​ ​para​ ​presentar​ ​HTML​ ​dinámico. Fácil de correlación a través de la capacidad para extraer datos de la mayoría de los formatos​ ​de​ ​respuesta​ ​populares,​ ​HTML​​ ​,​ ​JSON​​ ​,​ ​XML​​ ​o​ ​formato​ ​de​ ​cualquier​ ​texto La​ ​portabilidad​ ​completa​ ​y​ ​100%​ ​de​ ​pureza​ ​de​ ​Java. Completa multi-threading marco permite el muestreo simultáneo de muchos hilos y muestreo​ ​simultáneo​ ​de​ ​funciones​ ​diferentes​ ​por​ ​grupos​ ​de​ ​hilos​ ​separados. El almacenamiento en caché y fuera de línea de análisis / Reproducción de resultados​ ​de​ ​la​ ​prueba. Núcleo​ ​altamente​ ​extensible: ○ Samplers​ ​enchufables​ ​permiten​ ​capacidades​ ​de​ ​prueba​ ​ilimitadas. ○ Samplers de secuencias de comandos (idiomas compatible con JSR223 como​ ​Groovy​​ ​y​ ​BeanShell). ○ Varias estadísticas de carga se pueden elegir con temporizadores enchufables. ○ Análisis de datos y visualización plugins permiten una gran extensibilidad, así como​ ​la​ ​personalización. ○ Las funciones pueden ser utilizados para proporcionar la entrada dinámica a una​ ​prueba​ ​o​ ​proporcionar​ ​la​ ​manipulación​ ​de​ ​datos. ○ Integración Continua fácil a través de 3 rd bibliotecas partido de código abierto​ ​para​ ​Maven,​ ​Graddle​ ​y​ ​Jenkins.. 23.

(25) CAPÍTULO​ ​6.​ ​ALCANCES​ ​Y​ ​LIMITACIONES 6.1​ ​Alcances Para el proyecto se pretende desarrollar un sistema propio para la Universidad, que permita ser mantenido y adaptado a las particularidades que la institución tenga, el proyecto contempla todas las etapas del ciclo de vida del desarrollo del software usando la metodología​ ​kanban. Se va a desarrollar un sistema que permita gestionar los espacios físicos administrativos de la universidad y organigrama institucional, permitiendo insertar, modificar y eliminar información de uso propio de la institución, se podrán hacer consultas y revisiones de cómo está​ ​organizada​ ​en​ ​cuestión​ ​de​ ​espacios​ ​físicos​ ​y​ ​organigrama​ ​la​ ​universidad. El desarrollo de este sistema va desde el levantamiento de requerimientos, consecución de modelos, estudios de articulación con otros sistemas de la institución, despliegue en pruebas y las fases necesarias para su correcta consecución con una sólida etapa de pruebas​ ​unitarias. Se llevará a cabo la migración del modelo, generación de servicios REST, clientes estáticos y​ ​basado​ ​en​ ​integración​ ​continua.. 6.2​ ​Limitación Las​ ​limitaciones​ ​del​ ​proyecto​ ​son: ●. Requerimientos​ ​ambiguos​ ​e​ ​información​ ​insuficiente,​ ​desordenada​ ​y​ ​sin​ ​depurar​ ​de los​ ​espacios​ ​físicos​ ​de​ ​la​ ​universidad.. ●. Comunicación​ ​en​ ​espacios​ ​reducidos​ ​con​ ​la​ ​dependencia​ ​de​ ​planeación​ ​y​ ​procesos estructurados​ ​que​ ​afectan​ ​el​ ​tiempo​ ​de​ ​consecución​ ​del​ ​proyecto.. ●. La solución de software estará basada en los lineamientos del software libre dando respuesta​ ​a​ ​políticas​ ​distritales​ ​e​ ​institucionales.. 24.

(26) CAPÍTULO​ ​7.​ ​METODOLOGÍA El nuevo desarrollo al ser orientado a servicios, permite adoptar software de código abierto/libre, bajando el tiempo de desarrollo de las soluciones adoptadas y se integraría a las diferentes soluciones existentes (Terceros, Nómina, Contratación,Almacén, Sistema de Gestión Académica, Gestión Docente, BI) o que se encuentran en desarrollo (SSO) en la Universidad,​ ​de​ ​acuerdo,​ ​a​ ​la​ ​arquitectura​ ​adoptada​ ​por​ ​la​ ​Oficina​ ​Asesora​ ​de​ ​Sistemas. Arquitectura​ ​de​ ​referencia:. 6-1::​ ​Oficina​ ​Asesora​ ​de​ ​sistemas,Arquitectura​ ​de​ ​referencia,​ ​ilustración​ ​recuperada​ ​de: https://tuleap.udistrital.edu.co. 25.

(27) Herramientas​ ​ ​utilizadas​ ​en​ ​los​ ​componentes​ ​de​ ​la​ ​arquitectura​ ​de​ ​referencia:. 6-2:​ ​Oficina​ ​Asesora​ ​de​ ​sistemas,Herramientas​ ​utilizadas​ ​en​ ​componentes​ ​de​ ​la​ ​arquitectura​ ​de referencia,​ ​ilustración​ ​recuperada​ ​de:​ ​https://tuleap.udistrital.edu.co. Teniendo en cuenta el diseño arquitectural así como la metodología a utilizar es seguir un lineamiento​ ​de​ ​acciones​ ​en​ ​cuanto​ ​al​ ​desarrollo​ ​de​ ​la​ ​aplicación​ ​cuyas​ ​características​ ​son: Identificar las oportunidades de reutilización de código: ​esta actividad consiste en identificar módulos de código existente u otros elementos que puedan ser utilizados en el proceso de desarrollo del sistema, lo cual es importante para tener un manejo adecuado del diseño y desarrollo. Se debe tener siempre en consideración elementos de software libre o de propiedad de la institución manteniendo un especial cuidado por el respeto de las normas​ ​y​ ​legislación​ ​relacionada​ ​con​ ​el​ ​derecho​ ​de​ ​autor. La mejor manera de lograr que un equipo encuentre oportunidades de reciclaje es ejercitar buenas prácticas de generación de código y diseño. Entre las consideraciones a tener en cuenta se encuentra que las clases deben ser pequeñas, cohesivas y fáciles de entender para poder ofrecer oportunidades de reutilización. Se deben tener clases separadas cuando se​ ​encuentre​ ​funcionalidad​ ​que​ ​pueda​ ​ser​ ​separada,​ ​entre​ ​otras.. 26.

(28) Cabe recalcar que además del código específico que un realizador está escribiendo para un proyecto específico existen otras fuentes que puede ser reutilizado, como librerías de código internas (propiedad de la institución)​, ​librerías de terceros,Librerías construidas dentro del lenguaje,ejemplos de código de tutoriales, libros, colegas, código de sistemas existentes​, ​productos de software libre (asegurando que se siguen todos los acuerdos de licencia​ ​aplicables). Transformar el diseño en puesta en funcionamiento: ​Es importante utilizar herramientas de modelado sofisticadas que permiten obtener gran cantidad de código fuente directamente de la transformación de los modelos, agregando tareas de programación sobre​ ​el​ ​código​ ​generado​ ​para​ ​completar​ ​la​ ​puesta​ ​en​ ​funcionamiento. Existen varias técnicas para que de forma automática se transforme el diseño en artefactos de​ ​puesta​ ​en​ ​funcionamiento: ●. Se pueden aplicar patrones estándar para generar elementos de puesta en producción y de diseño a partir de artefactos relacionados. Por ejemplo, un patrón de transformación estándar puede ser aplicado sobre tablas de datos para crear clases Java que permiten acceder a tales tablas. Otro ejemplo consiste en utilizar marcos de trabajo tales como el Eclipse Modeling Framework para generar código que almacene datos de acuerdo al modelo y que además cree interfaces de usuario para poblar tales estructuras de datos. Un motor de patrones o de transformación puede ser usado para crear la puesta en funcionamiento, o la puesta en funcionamiento puede ser hecha de forma no automatizada. Los motores de patrones son fáciles de emplear y ofrecen mayor confiabilidad. En todo caso escribir código que implemente un determinado patrón tendrá menos errores que aquel código que implemente técnicas​ ​novedosas​ ​o​ ​diseños​ ​únicos.. ●. Los modelos pueden ser detallados y utilizados para generar una puesta en funcionamiento. Tanto los diagramas de estructura (diagramas de clases y diagramas de paquetes) como los de comportamiento (diagramas de colaboración, diagramas de estado y diagramas de actividades) pueden ser utilizados para generar código ejecutable. Estas versiones generadas podrán ser refinadas de acuerdo​ ​a​ ​las​ ​necesidades.. ●. El diseño debe ser independiente, en varios grados, de la plataforma en la cual se implementa. Modelos de diseño específicos para una plataforma o aún el código ejecutable pueden ser generados si se aplican diferentes reglas de transformación a abstracciones de alto nivel. Este es el enfoque de la Arquitectura Conducida por Modelos​ ​que​ ​propone​ ​el​ ​ ​Object​ ​Management​ ​Group​ ​(OMG).. ●. Modelos específicos para la plataforma pueden ser empleados para generar un marco de trabajo con código incompleto. Este se enriquecerá más adelante (“a mano”) con código no especificado en el diseño o que no haya podido ser transformado.. 27.

(29) En todos los casos algunas abstracciones de diseño (clases, componentes,etc)deben ser detalladas​ ​para​ ​poder​ ​ser​ ​transformadas​ ​en​ ​puesta​ ​en​ ​funcionamiento. Escribir el código fuente: ​Escribir el código fuente para hacer una puesta en funcionamiento que cumpla con el diseño y el comportamiento esperado. teniendo en cuenta​ ​los​ ​siguiente​ ​aspectos: ●. ●. ●. Examinar los requerimientos: como no toda la información de los requerimientos se puede colocar en los modelos, se debe verificar lo que no se cumple en la implementación, para depurar a través de la programación directa Reconstruir el código para mejorar el diseño, por medio de re-adaptación, que es una técnica con la que se mejora la calidad del código a partir de pequeños,​ ​y​ ​seguros​ ​cambios Afine los resultados de implementaciones existentes mejorando el desempeño,​ ​la​ ​interfaz​ ​de​ ​usuario,​ ​la​ ​seguridad​ ​y​ ​otras​ ​áreas​ ​no​ ​funcionales.. Estas consideraciones se deben poner en práctica teniendo en cuenta estándares que describen varias convenciones acerca de cómo escribir el código fuente. Su principal tarea es​ ​asegurar​ ​la​ ​consistencia,​ ​calidad​ ​y​ ​una​ ​puesta​ ​en​ ​funcionamiento​ ​fácil​ ​de​ ​entender. El uso de los estándares para la escritura de código es una de las prácticas más extendidas en la práctica de realización de software y se vuelve imperativa cuando se labora en ámbitos de alta colaboración. Los grupos de desarrollo deben tener una forma estándar para nombrar y dar formato a las cosas de tal manera que el código fuente se pueda entender rápidamente y la propiedad del mismo pueda ser cambiada sin detrimento de la calidad. Idealmente los estándares para la escritura de código debe ser el resultado de un consenso entre​ ​el​ ​equipo​ ​de​ ​trabajo​ ​ya​ ​que​ ​esta​ ​tarea​ ​ayuda​ ​a​ ​la​ ​rápida​ ​adopción​ ​de​ ​los​ ​estándares. Los​ ​estándares​ ​mencionados​ ​pueden​ ​cubrir​ ​áreas​ ​como: ●. Estándares para asignación de nombres: Esto incluye la forma en que se le da nombre a todos los elementos dentro del código. Cuando se cubren elementos de gran​ ​escala​ ​ ​pueden​ ​solapar​ ​los​ ​estándares​ ​de​ ​diseño.. ●. Organización de los archivos: ​Incluye convenciones para colocar nombres a los archivos y cómo éstos deben ser organizados dentro del árbol de directorios del sistema.. ●. Estándares para los comentarios: Poner demasiado énfasis en los comentarios denota una pérdida de confianza en cuanto la calidad del software que se está escribiendo. Además, se tendrá siempre una impresión de que los comentarios están desactualizados. La idea es estandarizar la forma en la cual se comenta el código para soportar la capacidad de soporte y la capacidad de generar documentación​ ​a​ ​partir​ ​del​ ​código. 28.

(30) ●. Convenciones para la escritura de código: Aplicación de convenciones específicas​ ​a​ ​nivel​ ​de​ ​código.. ●. Espacio en blanco: ​Aunque algunos autores lo consideran como de menor impacto es un hecho que el manejo adecuado de los espacios en blanco, los saltos de línea, las​ ​sangrías​ ​y​ ​las​ ​líneas​ ​en​ ​blanco​ ​facilitan​ ​la​ ​lectura​ ​del​ ​código.. ●. Evaluar la implementación: ​verificar que el funcionamiento de lo implementado este en concordancia con el propósito por el cual fue fue construido. es un paso fundamental​ ​para​ ​evaluar​ ​la​ ​calidad​ ​del​ ​producto. Esto se dará a medida que se realicen las respectivas pruebas funcionales y no funcionales que permitan tener un acercamiento a la calidad del software implementado en concordancia con las especificaciones del usuario, teniendo en cuenta​ ​que​ ​dichas​ ​pruebas​ ​harán​ ​parte​ ​de​ ​la​ ​gestión​ ​de​ ​cambios​ ​del​ ​proyecto.. ●. Comunicar decisiones importantes: Comunicar rápidamente el impacto de cambios no esperados en el diseño o los requerimientos. Los problemas y restricciones que no se hayan tenido en consideración deben ser comunicados al equipo de desarrollo. El impacto de problemas descubiertos durante la puesta en funcionamiento​ ​deben​ ​ser​ ​incorporados​ ​para​ ​las​ ​decisiones​ ​futuras. Esto se llevará a cabo a través de comunicación continua entre los grupos de trabajo y además cada una de las decisiones deberá ser incluida en los documentos de gestión de cambios para mantener la información registrada y al alcance de todos los​ ​involucrados.. 29.

(31) CAPÍTULO​ ​8.​ ​RECURSOS Se​ ​contempla​ ​en​ ​la​ ​Tabla​ ​1,​ ​los​ ​recursos​ ​que​ ​se​ ​estiman​ ​serán​ ​necesarios​ ​en​ ​el​ ​proceso​ ​de desarrollo​ ​a​ ​la​ ​solución​ ​de​ ​software​ ​mediante​ ​el​ ​rol​ ​desarrollador. Recursos​ ​del​ ​Proyecto. Tipo​ ​de​ ​Recurso. Recurso. Cantidad. Humano. Desarrollador. 2. Infraestructura. Computador. 1. Infraestructura. Control​ ​de​ ​versiones​ ​y avance​ ​del​ ​proyecto​ ​en Tuleap.. 1. Infraestructura. Servidor​ ​de​ ​aplicaciones para​ ​pruebas​ ​y​ ​servidor​ ​de bases​ ​de​ ​datos. 1. Infraestructura. Almacenamiento​ ​disponible en​ ​google​ ​drive​ ​para guardar​ ​documentación. 1​ ​Giga. Tiempo. Meses. 6. 8-1.​ ​Recursos​ ​del​ ​proyecto.. 30.

(32) CAPÍTULO​ ​9.​ ​PRESUPUESTO El presupuesto que se contempla desde el punto de vista del grupo desarrollador se evidencia​ ​en​ ​la​ ​tabla​ ​2,​ ​expresada​ ​de​ ​la​ ​siguiente​ ​manera: Presupuesto​ ​del​ ​proyecto,​ ​rol​ ​desarrollador.. Tipo​ ​de Recurso. Recurso. Cantidad. Tiempo. Valor mensual unitario. Valor cuatrimestral unitario. Valor​ ​total. Humano. Desarrollador. 2. 4​ ​meses. 3.000.000. 12.000.000. 24.000.000. Humano. DBA. 1. 4​ ​meses. 3.000.000. 12.000.000. 12.000.000. Humano. Scrum​ ​master. 1. 4​ ​meses. 3.895.000. 15.580.000. 15.580.000. Humano. Product​ ​owner. 1. 4​ ​meses. 5.000.000. 20.000.000. 20.000.000. Infraestructura. Servidor​ ​de desarrollo. 1. 4​ ​meses. 3.000.000. 12.000.000. 12.000.000. Infraestructura. Servicio​ ​de internet. 2. 4​ ​meses. 100.000. 400.000. 800.000. Infraestructura. Alquiler​ ​de computadores. 2. 4​ ​meses. 200.000. 800.000. 1.600.000. Infraestructura. Servicio​ ​de​ ​luz. 2. 4​ ​meses. 40.000. 160.000. 320.000. Transporte. Transporte. 2. 4​ ​meses. 20.000. 80.000. 160.000. 4​ ​meses. 2.700.000. 10.800.000. 10.800.000. Varios. Imprevistos, Fotocopias.. ​ ​ ​ ​1. Presupuesto​ ​Total:. 96.460.000. 9-1.​ ​Presupuesto​ ​del​ ​proyecto.. 31.

(33) CAPÍTULO​ ​10.​ ​CRONOGRAMA El​ ​siguiente​ ​es​ ​el​ ​cronograma​ ​a​ ​llevar​ ​a​ ​cabo​ ​para​ ​la​ ​realización​ ​del​ ​proyecto:. 10-1:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Cronograma​ ​del​ ​proyecto.. 32.

(34) CAPÍTULO​ ​11.​ ​DESARROLLO 11.1​ ​Desarrollo​ ​metodología​ ​KANBAN De acuerdo a la metodología KANBAN y la herramienta de seguimiento Tuleap, se creó el proyecto de “​Sistema de Espacios Físicos​” en la cual se crearon 4 tableros “Aplicación”, “Base​ ​de​ ​datos”,​ ​“Proyecto”​ ​y​ ​“Kanban​ ​Task”,​ ​como​ ​se​ ​observa​ ​en​ ​la​ ​siguiente​ ​imagen. 11-1:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Tableros​ ​metodología​ ​KANBAN. Tomado​ ​de:​ ​https://tuleap.udistrital.edu.co/plugins/agiledashboard/?group_id=161. De acuerdo a la clasificación de la tarea se iban creando en el tablero correspondiente y se hacía​ ​pasar​ ​la​ ​tarea​ ​por​ ​las​ ​diferentes​ ​fases​ ​que​ ​se​ ​tienen​ ​establecidas​ ​en​ ​la​ ​OAS.. 11.2​ ​Integración​ ​Continua La integración continua es una práctica de desarrollo de software mediante la cual los desarrolladores combinan los cambios en el código en un repositorio central de forma periódica, tras lo cual se ejecutan versiones y pruebas automáticas. La integración continua se refiere en su mayoría a la fase de creación o integración del proceso de publicación de software y conlleva un componente de automatización (p. ej., CI o servicio de versiones) y un componente cultural (p. ej., aprender a integrar con frecuencia). Los objetivos claves de la integración continua consisten en encontrar y arreglar errores con mayor rapidez, mejorar la calidad del software y reducir el tiempo que se tarda en validar y publicar nuevas actualizaciones​ ​de​ ​software. 33.

(35) Anteriormente,​ ​era​ ​común​ ​que​ ​los​ ​desarrolladores​ ​de​ ​un​ ​equipo​ ​trabajasen​ ​aislados​ ​durante un largo periodo de tiempo y combinarán los cambios en la versión maestra una vez que habían completado el trabajo. Este proceso por lotes hacía que la combinación de todos los cambios en el código resultase complicada y llevase mucho tiempo. Esto se agravaba cuando numerosos errores leves se acumulaban durante mucho tiempo sin que se arreglaran. La combinación de estos factores hacía que resultase más difícil proporcionar las​ ​actualizaciones​ ​a​ ​los​ ​clientes​ ​con​ ​rapidez. Con la integración continua, los desarrolladores envían los cambios de forma periódica a un repositorio compartido con un sistema de control de versiones como Git. Antes de cada envío, los desarrolladores pueden elegir ejecutar pruebas de unidad local en el código como medida de verificación adicional antes de la integración. El servicio de integración continua detecta los envíos al repositorio compartido y crea y ejecuta de forma automática pruebas de unidad en los cambios en el código para detectar al instante cualquier error funcional o de​ ​integración.​ ​(​AWS​ ​AMAZON​).. 11.2.1​ ​Integración​ ​Continua​ ​en​ ​la​ ​Oficina​ ​Asesora​ ​de​ ​Sistemas En la oficina asesora de sistemas se definieron algunas herramientas que conforman el ecosistema​ ​de​ ​integración​ ​continua​ ​tales​ ​como:​ ​Jenkins,​ ​Gogs,​ ​github,​ ​travis,​ ​etc. Jenkins gestiona todas las tareas que comprenden propiamente la automatización de despliegues en los diferentes entornos, por ahora Oikos hace sus despliegues en un entorno​ ​de​ ​pruebas​ ​en​ ​una​ ​dirección​ ​local.. 11.3​ ​Diagramas​ ​BPMN Los diagramas fueron realizados con la herramienta estandarizada en la OAS para modelar procesos como lo es Tooling, siguiendo la respectiva documentación del software se procedieron a crear los BPMN correspondientes al manejo que facilitara el aplicativo OIKOS (Espacios​ ​Físicos). Los respectivos diagramas de procesos para representar la forma en cómo se gestionan los espacios físicos y dependencias, además de cómo estas se relacionan entre sí. En el siguiente diagrama se refleja lo correspondiente a cómo se asigna un espacio físico a una dependencia teniendo en cuenta las gestión preestablecida para poder contar con el registro​ ​de​ ​cada​ ​espacio​ ​físico​ ​y​ ​dependencia​ ​respectivamente.. 11-2:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Diagrama​ ​macro​ ​de​ ​asignar​ ​dependencia .. 34.

(36) Para conocer a un grado de detalle alto los subprocesos que suceden en los procesos Gestionar Espacio Físico y ​Gestionar Dependencia, ​se crea el subproceso que se lleva a cabo en cada uno de estos, con el fin de tener claro el procedimiento al “​Asignar Dependencia​”,​ ​tal​ ​y​ ​como​ ​se​ ​muestra​ ​en​ ​el​ ​siguiente​ ​diagrama.. 11-3:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Diagrama​ ​detallado​ ​de​ ​asignar​ ​dependencia. Los BPMN fueron revisados y avalados en las constantes revisiones llevadas a cabo con los arquitectos del proyecto, quienes en momentos determinados sugirieron modificaciones y cambios​ ​con​ ​respecto​ ​a​ ​los​ ​BPMN​ ​diseñados​ ​en​ ​el​ ​transcurso​ ​del​ ​proyecto.. 11.4​ ​Diseño​ ​de​ ​Mockups En la Oficina Asesora De Sistemas se realizaban los mockups en la herramienta Pencil, la cual estaba establecida anteriormente y en las cuales se diseñaron los primeros mockups que suplieron las necesidades del sistema de acuerdo a lo analizado, por tal razón se realizaron las diversas versiones de mockups en las cuales se evidencian las modificaciones de las interfaces del Sistema de Gestión de Espacios Físicos de la Universidad Distrital Francisco José de Caldas de la versión 1 y 2 de los mockups, adicionalmente​ ​las​ ​variaciones​ ​en​ ​cada​ ​uno​ ​de​ ​los​ ​respectivos​ ​formularios. 11.4.1​ ​MOCKUPS​ ​DE​ ​DEPENDENCIA. ​​​​​​​​​​​​​​​​​​​​​. 11-4:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Registro​ ​dependencia​ ​version​ ​1.. 35.

(37) 11-5:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Registro​ ​dependencia​ ​version​ ​2.. En la versión 1 hay un formulario que se compone de dos campos: CÓDIGO DEPENDENCIA- NOMBRE DEPENDENCIA. Mientras que en la versión 2 se ha reemplazado el Código dependencia por: TELÉFONO DEPENDENCIA Y DEPENDENCIA PADRE.. 11-6:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Consultar​ ​dependencia​ ​version​ ​1.. 11-7:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Consultar​ ​dependencia​ ​version​ ​2.. En ésta instancia se puede identificar que la versión 1 cuenta con un motor de búsqueda de la dependencia, en la cual están las siguientes opciones: CÓDIGO DE DEPENDENCIA, NOMBRE DE DEPENDENCIA, DEPENDENCIA PADRE, MODIFICAR Y ELIMINAR. En la 36.

(38) versión 2 sin embargo cambia el código de dependencia por el TELEFÓNO DE DEPENDENCIA.. 11-8:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Recuperar​ ​dependencia​ ​version​ ​1.. 11-9:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Recuperar​ ​dependencia​ ​version​ ​2.. En la versión 1 la recuperación de la dependencia arroja una serie de datos éstos son: CÓDIGO DE DEPENDENCIA, NOMBRE DE DEPENDENCIA, DEPENDENCIA PADRE Y OPCIÓN A RESTAURAR. Mientras que en la versión 2 cambia el código de dependencia por: TELEFÓNO DE DEPENDENCIA, adicionalmente se elimina la opción; dependencia padre​ ​de​ ​la​ ​versión​ ​1.. 37.

(39) 11.4.1​ ​MOCKUPS​ ​DE​ ​EDIFICIO. 11-10:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Registrar​ ​edificio​ ​version​ ​1.. 11-11:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Registrar​ ​edificio​ ​version​ ​2.. Se mantienen formularios iguales en la versión 1 y 2, ya que no se necesitaron o surgieron cambios​ ​en​ ​el​ ​transcurso.. 38.

(40) 11-12:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Consultar​ ​edificio​ ​version​ ​2.. 11-13:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Consultar​ ​edificio​ ​version​ ​2.. En​ ​ésta​ ​instancia​ ​se​ ​mantienen​ ​formularios​ ​iguales​ ​en​ ​ambas​ ​versiones.. 11-14:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Recuperar​ ​edificio​ ​version​ ​1.. 39.

(41) 11-15:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Recuperar​ ​edificio​ ​version​ ​2.. La versión 1 muestra una información previa del edificio a recuperar, los cuales son: NOMBRE EDIFICIO, FACULTAD Y DIRECCIÓN. Sin embargo la versión 2 tiene adicional a la​ ​versión​ ​1:​ ​SEDE. 11.4.1​ ​MOCKUPS​ ​DE​ ​ESPACIOS​ ​FÍSICOS. 11-16:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Registrar​ ​Espacio​ ​Físico​ ​version​ ​1.. 11-17:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Registrar​ ​Espacio​ ​Físico​ ​version​ ​1.. 40.

(42) En ésta instancia la versión 1 cuenta con los siguientes campos: NOMBRE ESPACIO FÍSICO, CÓDIGO, TIPO, FACULTAD, SEDE, DEPENDENCIA Y ESTADO. Por otra parte la versión 2 varía, pues se reemplaza código por EDIFICIO, facultad por ÁREA y sede por CONEXIÓN​ ​A​ ​INTERNET.. 11-18:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Consultar​ ​Espacio​ ​Físico​ ​version​ ​1.. 11-19:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Consultar​ ​Espacio​ ​Físico​ ​version​ ​2.. En la versión 1 están los siguientes datos​: NOMBRE ESPACIO, CÓDIGO, TIPO,. FACULTAD y opción de ELIMINAR. Sin embargo la versión 2 cambia los siguientes datos: código por FACULTAD, tipo por SEDE, facultad por DIRECCIÓN y adicionalmente​ ​tiene​ ​una​ ​opción​ ​de​ ​MODIFICAR.. 41.

(43) 11-20:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Consultar​ ​Espacio​ ​Físico​ ​version​ ​1.. 11-21:​ ​Reyes,​ ​Javier,​ ​(2017)​ ​Consultar​ ​Espacio​ ​Físico​ ​version​ ​2.. En la versión 1 se encuentran los siguientes datos: NOMBRE ESPACIO, CÓDIGO, TIPO y la opción de RESTAURAR. Sin embargo en la versión 2 se modifican los siguientes datos: código​ ​por​ ​FACULTAD​ ​y​ ​tipo​ ​por​ ​SEDE,​ ​adicionalmente​ ​se​ ​anexa:​ ​DIRECCIÓN. 11.4.1​ ​MOCKUPS​ ​DE​ ​SEDE. 11-22:​ ​ ​REGISTRO​ ​SEDE​ ​VERSIÓN​ ​2. 42.

(44) El formulario de la versión 1 varía totalmente con la versión 2 simplificandose éste último, la versión 1 posee: NOMBRE SEDE, ABREVIATURA SEDE, DIRECCIÓN, LATITUD, LONGITUD y ESTADO, sin embargo la versión 2 contiene: NOMBRE SEDE, SEDE y ESTADO.. 11-23:CONSULTAR​ ​SEDE​ ​VERSIÓN​ ​1. 11-24:​ ​ ​CONSULTAR​ ​SEDE​ ​VERSIÓN​ ​2. El formulario de consulta de sede varía en los siguientes datos, en la versión 1 están: NOMBRE SEDE, DIRECCIÓN, ABREVIATURA SEDE, MODIFICAR y ELIMINAR. Sin embargo​ ​en​ ​la​ ​versión​ ​2​ ​se​ ​suprimen​ ​DIRECCIÓN​ ​y​ ​ABREVIATURA​ ​SEDE​ ​por​ ​ESTADO.. 43.

(45) 11-25:​ ​RECUPERAR​ ​SEDE​ ​VERSIÓN​ ​1. 11-26:​ ​RECUPERAR​ ​SEDE​ ​VERSIÓN​ ​2. En éste último formulario aparecen los siguientes datos en la versión 1: NOMBRE SEDE, DIRECCIÓN, ABREVIATURA SEDE sin embargo en la versión 2 se resume a: NOMBRE SEDE,​ ​ESTADO. Cabe destacar que los mockups se fueron refinando de acuerdo a los estándares que se establecieron en la Oficina Asesora de Sistemas (OAS), en cuanto a estilos y nombramiento de variables utilizadas en los controladores de cada módulo, creando así un aplicativo con los lineamientos implantados y que permitiera interactuar de mejor manera con los demás sistemas, logrando así integración entre los sistemas que tiene a cargo la Oficina Asesora de​ ​Sistemas.. 44.

Referencias

Descargar ahora ( PDF - 54 página - 1.69 MB )

Outline

11.3 ​ ​ Diagramas ​ ​ BPMN

Documento similar

Y DE LA LINDA CLAMONDA, HIJA DEL REY DE TOSCAM

E Clamades andaua sienpre sobre el caua- 11o de madera, y en poco tienpo fue tan lexos, que el no sabia en donde estaña; pero el tomo muy gran esfuergo en si, y pensó yendo assi

Introducción

Where possible, the EU IG and more specifically the data fields and associated business rules present in Chapter 2 –Data elements for the electronic submission of information

Capítulo 1

The 'On-boarding of users to Substance, Product, Organisation and Referentials (SPOR) data services' document must be considered the reference guidance, as this document includes the

Capítulo 2

In medicinal products containing more than one manufactured item (e.g., contraceptive having different strengths and fixed dose combination as part of the same medicinal

Capítulo 7

Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in

Anexo I

Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in

Capítulo 8

This section provides guidance with examples on encoding medicinal product packaging information, together with the relationship between Pack Size, Package Item (container)

Anexo

Package Item (Container) Type : Vial (100000073563) Quantity Operator: equal to (100000000049) Package Item (Container) Quantity : 1 Material : Glass type I (200000003204)