Desarrollo de un Sistema de Información para el Laboratorio de Tuberculosis del Valle del Cauca (SILAT)

Texto completo

(1)Desarrollo de un Sistema de Información para el Laboratorio de Tuberculosis del Valle del Cauca. (SILAT).. Jhonnier Yair Mosquera Sánchez Oscar Fabián Mejía Calambas.. Universidad Cooperativa de Colombia. Facultad de Ingeniería Programa Ingeniería de Sistemas Santiago de Cali 2017.

(2) Desarrollo de un Sistema de Información para el Laboratorio de Tuberculosis del Valle del Cauca. (SILAT).. Jhonnier Yair Mosquera Sánchez Oscar Fabián Mejía Calambas.. Investigación Dirigida para optar por el título de Ingeniero de Sistemas. Director JHON HAIDE CANO BELTRAN Ingeniero de Sistemas. Universidad Cooperativa de Colombia. Facultad de Ingeniería Programa Ingeniería de Sistemas Santiago de Cali 2017.

(3) CONTENIDO.. RESUMEN. ............................................................................................................ 11 1.. IDENTIFICACIÓN DEL PROBLEMA. ............................................................. 12 1.1. PLANTEAMIENTO DEL PROBLEMA. ...................................................... 12 1.2. ARBOL DEL PROBLEMA. ........................................................................ 13 1.3. FORMULACIÓN DEL PROBLEMA. ......................................................... 13. 2.. JUSTIFICACIÓN. ............................................................................................ 14. 3.. OBJETIVOS.................................................................................................... 16 3.1. Objetivo general. ....................................................................................... 16 3.2. Objetivos específicos. ............................................................................... 16. 4.. MARCO REFERENCIAL. ............................................................................... 17 4.1. MARCO TEÓRICO. .................................................................................. 17 4.1.1. ANTECEDENTES .............................................................................. 17 4.1.2. Método de implementación ................................................................ 18 4.2. MARCO CONCEPTUAL. .......................................................................... 20 4.2.1.. Ingeniería de Software. ......................................................................... 21. 4.2.2. Sistemas de Información. ................................................................... 21 4.2.3. Metodologías Agiles. .......................................................................... 21 4.2.3.1.. SCRUM ........................................................................................... 22. 4.2.3.2.. Lean Development (LD). ................................................................. 25. 4.2.3.3.. XP. .................................................................................................. 25. 4.2.3.4.. Dynamic Systems Development Method (DSDM). ......................... 26. 4.2.4. Definición generalizada de los sistemas de información. ................... 26 4.2.5. Software de laboratorio clínico. .......................................................... 27 5.. METODOLOGIA ............................................................................................. 28 5.1. Metodología de desarrollo. ....................................................................... 28. 6.. ANALISIS........................................................................................................ 31. 7.. DESARROLLO ............................................................................................... 34 7.1. Diagrama de caso de uso extendido. ....................................................... 34 7.2. DIAGRAMA DE HERENCIA DE LOS ACTORES. .................................... 35.

(4) 7.3. SPRINT 1: INGRESO AL SISTEMA. ........................................................ 35 7.3.1. Sprint Backlog para el Sprint 1. .......................................................... 35 7.4. SPRINT 2: INICIAR SESION. ................................................................... 37 7.4.1. Sprint Backlog para el Sprint 2. .......................................................... 37 7.4.2. Caso de uso para el Sprint 2. ............................................................. 37 7.4.3. Diagrama de Secuencia. .................................................................... 39 7.5. SPRINT 3: GESTIÓN DE USUARIOS. ..................................................... 39 7.5.1. Sprint Backlog para el Sprint 3. .......................................................... 39 7.5.2. Caso de uso para el Sprint 3. ............................................................. 42 7.5.3. Diagrama de Secuencia. .................................................................... 44 7.6. SPRINT 4: GESTIÓN DE DEPARTAMENTOS. ....................................... 44 7.6.1. Sprint backlog para el Sprint 4. .......................................................... 44 7.6.2. Caso de uso para el Sprint 4. ............................................................. 46 7.6.3. Diagrama de Secuencia. .................................................................... 48 7.7. SPRINT 5: GESTIÓN DE MUNICIPIOS. .................................................. 48 7.7.1. Sprint backlog para el Sprint 5. .......................................................... 49 7.7.2. Caso de uso para el Sprint 5. ............................................................. 51 7.7.3. Diagrama de Secuencia. .................................................................... 53 7.8. SPRINT 6: GESTIÓN DE EPS. ................................................................ 53 7.8.1. Sprint backlog para el Sprint 6. .......................................................... 53 7.8.2. Caso de uso para el Sprint 6. ............................................................. 55 7.8.3. Diagrama de Secuencia. .................................................................... 57 7.9. SPRINT 7: GESTIÓN DE IPS. .................................................................. 58 7.9.1. Sprint backlog para el Sprint 7. .......................................................... 58 7.9.2. Caso de uso para el Sprint 7. ............................................................. 60 7.9.3. Diagrama de Secuencia. .................................................................... 62 7.10.. SPRINT 8: RECEPCION DE MUESTRAS. ........................................... 62. 7.10.1.. Sprint backlog para el Sprint 8. ....................................................... 62. 7.10.2.. Caso de uso para el Sprint 8........................................................... 63. 7.10.3.. Diagrama de Secuencia. ................................................................. 65. 7.11.. SPRINT 9: RESULTADOS. ................................................................... 65. 7.11.1.. Sprint backlog para el Sprint 9. ....................................................... 65. 7.11.2.. Caso de uso para ingresar GeneXpert. .......................................... 68.

(5) 7.11.3.. Diagrama de Secuencia GeneXpert. .............................................. 69. 7.11.4.. Caso de uso para ingresar GenoType. ........................................... 69. 7.11.5.. Diagrama de Secuencia GenoType. ............................................... 71. 7.11.6.. Caso de uso para ingresar Identificación. ....................................... 71. 7.11.7.. Diagrama de Secuencia Identificación. ........................................... 72. 7.12.. SPRINT 10: CONSULTAS..................................................................... 73. 7.12.1.. Sprint backlog para el Sprint 10. ..................................................... 73. 7.12.2.. Caso de uso para actualizar o modificar ficha de ingreso. .............. 76. 7.12.3.. Diagrama de Secuencia para actualizar o modificar ficha de ingreso. 78. 7.12.4.. Caso de uso para leer ficha de ingreso. ......................................... 78. 7.12.5.. Diagrama de Secuencia para leer ficha de ingreso. ....................... 79. 7.12.6.. Caso de uso para actualizar o modificar resultado GeneXpert. ...... 80. 7.12.7. Diagrama de Secuencia para actualizar o modificar resultado GeneXpert. ..................................................................................................... 82 7.12.8.. Caso de uso para leer resultado GeneXpert. .................................. 82. 7.12.9.. Diagrama de Secuencia para leer resultado GeneXpert. ................ 83. 7.12.10.. Caso de uso para actualizar o modificar resultado GenoType. ... 84. 7.12.11. Diagrama de Secuencia para actualizar o modificar resultado GenoType. 85 7.12.12.. Caso de uso para leer resultado GenoType. ............................... 85. 7.12.13.. Diagrama de Secuencia para leer resultado GenoType. ............. 86. 7.12.14.. Caso de uso para actualizar o modificar resultado Identificación. 87. 7.12.15. Diagrama de secuencia para actualizar o modificar resultado Identificación. .................................................................................................. 88 7.12.16.. Caso de uso para leer resultado Identificación. ........................... 88. 7.12.17.. Diagrama de Secuencia para leer resultado GenoType. ............. 89. 7.13.. SPRINT 11: CERRAR SESION. ............................................................ 90. 7.13.1. 7.14. 8.. Sprint backlog para el Sprint 11. ..................................................... 90. DIAGRAMA ENTIDAD RELACION. ...................................................... 91. PRUEBAS....................................................................................................... 92 8.1. PRUEBA DE CAJA NEGRA ..................................................................... 92 8.2. PRUEBA DE INSTALACIÓN. ................................................................... 99.

(6) 9.. CONCLUSIONES ......................................................................................... 101. RECOMENDACIONES ........................................................................................ 102 10.. BIBLIOGRAFIA. ......................................................................................... 103. ANEXOS .............................................................................................................. 105.

(7) LISTA DE ILUSTRACIONES.. Ilustración 1. Árbol del problema............................................................................ 13 Ilustración 2. Ciclo de vida del patrón MVC ........................................................... 20 Ilustración 3. Scrum framework. Fuente: wearmarketing ....................................... 22 Ilustración 4. Roles en la metodología Scrum. Fuente: www.kzi.mx ...................... 23 Ilustración 5. Diagrama de caso de uso extendido. ............................................... 34 Ilustración 6. Diagrama de herencia de los actores. .............................................. 35 Ilustración 7. Interfaz de bienvenida del sistema. .................................................. 36 Ilustración 8. Diagrama de secuencia iniciar sesión. ............................................. 39 Ilustración 9. Diagrama de secuencia crear usuario. ............................................. 44 Ilustración 10. Diagrama de secuencia crear departamento. ................................. 48 Ilustración 11. Diagrama de secuencia crear municipio. ........................................ 53 Ilustración 12. Diagrama de secuencia crear EPS. ................................................ 57 Ilustración 13. Diagrama de secuencia crear IPS. ................................................. 62 Ilustración 14. Diagrama de secuencia registrar ficha (Recepción). ...................... 65 Ilustración 16. Diagrama de secuencia ingresar resultado GeneXpert. ................. 69 Ilustración 17. Diagrama de secuencia ingresar resultado GenoType. .................. 71 Ilustración 18. Diagrama de secuencia ingresar resultado Identificación. .............. 73 Ilustración 19. Diagrama de secuencia para Actualizar o Modificar ficha de ingreso (Operador). ............................................................................................................ 78 Ilustración 20. Diagrama de secuencia para leer ficha de ingreso (Operador). ..... 80 Ilustración 21. Diagrama de secuencia para Actualizar o Modificar resultado GeneXpert.............................................................................................................. 82 Ilustración 22. Diagrama de secuencia para leer resultado GeneXpert. ................ 83 Ilustración 23. Diagrama de secuencia para Actualizar o Modificar resultado GenoType. ............................................................................................................. 85 Ilustración 24. Diagrama de secuencia para leer resultado GenoType. ................. 86 Ilustración 25. Diagrama de secuencia para Actualizar o Modificar resultado Identificación. ......................................................................................................... 88 Ilustración 26. Diagrama de secuencia para leer resultado GenoType. ................. 89 Ilustración 27. Diagrama Entidad Relación. ........................................................... 91.

(8) LISTA DE TABLAS.. Tabla 1. Notificación de casos de TB ..................................................................... 12 Tabla 2. Diferencias entre metodologías Agiles sobre las metodologías tradicionales. .......................................................................................................... 28 Tabla 3. Grupo de trabajo para el desarrollo de SILAT .......................................... 29 Tabla 4. Definición de requerimientos por el usuario. ............................................ 33 Tabla 5. Perfiles de usuarios y funciones en el sistema. ....................................... 33 Tabla 6. Sprint Backlog para el Sprint 1. ................................................................ 35 Tabla 7. Historia ingreso al sistema ....................................................................... 36 Tabla 8. Sprint Backlog para el sprint 2 ................................................................. 37 Tabla 9.Historia Iniciar sesión ................................................................................ 37 Tabla 10. Caso de uso para el Sprint 2. ................................................................. 38 Tabla 11. Sprint Backlog para el sprint 3. .............................................................. 40 Tabla 12. Historia Crear usuario. ........................................................................... 40 Tabla 13. Historia Editar usuario. ........................................................................... 41 Tabla 14. Historia Eliminar usuario. ....................................................................... 41 Tabla 15. Caso de uso Crear usuario. ................................................................... 42 Tabla 16. Sprint backlog para el sprint 4. ............................................................... 45 Tabla 17. Historia Crear departamento. ................................................................. 45 Tabla 18. Historia Editar departamento. ................................................................ 46 Tabla 19. Historia Eliminar departamento. ............................................................. 46 Tabla 20. Caso de uso para el Sprint 4. ................................................................. 47 Tabla 21. Sprint backlog para el sprint 5. ............................................................... 49 Tabla 22. Historia Crear municipio. ........................................................................ 49 Tabla 23. Historia Editar municipio. ....................................................................... 50 Tabla 24. Historia Eliminar municipio. .................................................................... 51 Tabla 25. Caso de uso para el Sprint 5. ................................................................. 51 Tabla 26. Sprint Backlog para el Sprint 6. .............................................................. 54 Tabla 27. Historia Crear EPS. ................................................................................ 54 Tabla 28. Historia Editar EPS. ............................................................................... 55 Tabla 29. Historia Eliminar EPS. ............................................................................ 55 Tabla 30. Caso de uso para el Sprint 6. ................................................................. 56 Tabla 31. Sprint backlog para el Sprint 7. .............................................................. 58 Tabla 32. Historia Crear IPS. ................................................................................. 59 Tabla 33. Historia Editar IPS. ................................................................................. 59 Tabla 34. Historia Eliminar IPS. ............................................................................. 60 Tabla 35. Caso de uso para el Sprint 7. ................................................................. 60 Tabla 36. Sprint Backlog para el Sprint 8. .............................................................. 62.

(9) Tabla 37. Historia Ingreso de la muestra. .............................................................. 63 Tabla 38. Caso de uso para el Sprint 8. ................................................................. 64 Tabla 39. Sprint backlog para el Sprint 9. .............................................................. 66 Tabla 40. Historia Crear GeneXpert....................................................................... 66 Tabla 41. Historia Crear GenoType. ...................................................................... 67 Tabla 42. Historia Crear Identificación. .................................................................. 67 Tabla 43. Caso de uso para ingresar GeneXpert................................................... 68 Tabla 44. Caso de uso para ingreso GenoType .................................................... 70 Tabla 45. Caso de uso para ingresar Identificación. .............................................. 72 Tabla 46. Sprint Backlog para el sprint 10. ............................................................ 73 Tabla 47. Historia Filtrar datos. .............................................................................. 74 Tabla 48. Editar ficha de ingreso de la muestra. .................................................... 75 Tabla 49. Historia Detallar ficha de ingreso de la muestra. .................................... 75 Tabla 50. Historia Descargar ficha de ingreso de la muestra................................. 76 Tabla 51. Caso de uso para actualizar o modificar ficha de ingreso ...................... 77 Tabla 52. Caso de uso para leer ficha de ingreso.................................................. 79 Tabla 53. Caso de uso para actualizar o modificar resultado GeneXpert. ............. 81 Tabla 54. Caso de uso para leer resultado GeneXpert. ......................................... 83 Tabla 55. Caso de uso para actualizar o Modificar Resultado GenoType. ............ 84 Tabla 56. Caso de uso para leer Resultado GenoType. ........................................ 86 Tabla 57. Caso de uso para actualizar o modificar resultado Identificación. ......... 87 Tabla 58. Caso de uso para leer resultado de Identificación. ................................ 89 Tabla 59. Sprint backlog para Sprint. ..................................................................... 90 Tabla 60. Historia Salir del sistema........................................................................ 90 Tabla 61. Prueba interfaz Gestión de usuarios (Nuevo Usuario). .......................... 92 Tabla 62. Prueba interfaz Gestión de usuarios (Editar Usuario). ........................... 92 Tabla 63. Prueba interfaz Gestión de usuarios (Eliminar Usuario). ....................... 93 Tabla 64. Prueba interfaz Gestión de usuarios (Nuevo Departamento). ................ 93 Tabla 65. Prueba interfaz Gestión de usuarios (Editar Departamento). ................. 93 Tabla 66. Prueba interfaz Gestión de usuarios (Eliminar Departamento). ............. 94 Tabla 67. Prueba interfaz Gestión de usuarios (Nuevo Municipio). ....................... 94 Tabla 68. Prueba interfaz Gestión de usuarios (Editar Municipio). ........................ 94 Tabla 69. Prueba interfaz Gestión de usuarios (Eliminar Municipio). ..................... 94 Tabla 70. Prueba interfaz Gestión de usuarios (Nueva EPS). ............................... 95 Tabla 71. Prueba interfaz Gestión de usuarios (Editar EPS). ................................ 95 Tabla 72. Prueba interfaz Gestión de usuarios (Eliminar EPS).............................. 95 Tabla 73. Prueba interfaz Gestión de usuarios (Nueva IPS). ................................ 96 Tabla 74. Prueba interfaz Gestión de usuarios (Editar IPS). ................................. 96 Tabla 75. Prueba interfaz Gestión de usuarios (Eliminar IPS). .............................. 96 Tabla 76. Prueba interfaz Recepción de Muestras. ............................................... 97 Tabla 77. Prueba para validar edad del paciente a registrar. ................................ 97 Tabla 78. Prueba interfaz Resultado (GeneXpert). ................................................ 97 Tabla 79. Prueba interfaz Resultado (GenoType).................................................. 98 Tabla 80. Prueba interfaz Resultado (Identificación). ............................................ 98 Tabla 81. Prueba interfaz Consulta (filtrar fichas). ................................................. 98.

(10) Tabla 82. Prueba interfaz Consulta (Ver ficha de ingreso). ................................... 99 Tabla 83. Prueba interfaz Consulta (Descargar ficha de ingreso).......................... 99.

(11) RESUMEN. La gestión y administración de datos es parte fundamental de una institución, por esta razón los sistemas de información se han posicionado como métodos de implementación, gestión y almacenamiento, esto se debe a que los servicios que un sistema de información brinda; optimiza tiempos en gestión y procesamiento de datos, certifica que los datos almacenados estén seguros, presenta alta disponibilidad de la información y se adapta la lógica de procesos de cualquier institución. En el presente documento se abordó el desarrollo de una investigación bajo los modelos de la ingeniería de software. Este con el fin de llevar a cabo la implementación de un sistema de información que optimice la forma de registro, procesamiento y almacenamiento de información para el área de tuberculosis del laboratorio de salud pública. La metodología usada para el desarrollo de este sistema (Metodología SCRUM), se parametriza bajo los modelos de metodología ágil, teniendo en cuenta que con estos modelos se garantiza cumplir con los requisitos del usuario final..

(12) 1. IDENTIFICACIÓN DEL PROBLEMA. 1.1.. PLANTEAMIENTO DEL PROBLEMA.. El Laboratorio de Salud pública Departamental (LSPD) es una institución dedicada a la recolección de muestras biológicas que afectan los habitantes o el medio ambiente del Departamento del Valle del Cauca, con esto se expresa que en el instituto se lleva a cabo una labor muy importante para el control de plagas y enfermedades, obteniendo un registro continuo de cualquier tipo de agente contaminante que afecte esta zona del país. En un informe realizado por el Instituto Nacional de Salud (INS) se denota como la tuberculosis (TB) en el país tiene una gran incidencia, en este mismo informe se puede observar como el Valle del Cauca está posicionado como la sexta zona con mayor cantidad de casos, donde los casos de TB que se presentan en ésta región supera los 700 y la incidencias por cada 100.000 habitantes es del 17,3% ver (Tabla 1) , debido a que se presenta ésta situación en el país, el área de tuberculosis actualmente realiza una gestión de información de gran magnitud y de alto valor en pro de evitar que los casos de TB sigan en aumento, teniendo en cuenta la labor que lleva a cabo ésta área, es de gran importancia que el proceso de gestión de información para cada prueba presentada cumpla su ciclo de investigación sin alteraciones o errores, debido a que depende de estos registros poder prevenir el aumento en los casos. Tabla 1. Notificación de casos de tuberculosis según formas por entidad territorial de residencia, Colombia, a semana epidemiológica 31 (02 de ago.- 08 de ago.) de 2015. Entidad territorial de residencia. N.º de casos nuevos de. Incidencia por N.º de casos 100 000 nuevos. tuberculosis pulmonar. habitantes de tuberculosis TB Extra pulmonar pulmonar. Incidencia por. Total. Casos 100 000 nuevos habitantes de TB Extra pulmonar 4,3 1297. Incidencia por 100 000 habitantes. Antioquia. 1017. 15,8. 280. Barranquilla. 285. 23,4. 34. 2,8. 319. 26,2. Bogotá. 364. 4,6. 208. 2,6. 572. 7,3. Cauca. 90. 6,5. 40. 2,9. 130. 9,4. Nariño. 78. 4,5. 24. 1,4. 102. 5,8. Valle Del Cauca. 798. 17,3. 157. 3,4. 955. 20,7. Tabla 1. Notificación de casos de TB Fuente: Sivigila, Instituto Nacional de Salud. Colombia.. 12. 20,1.

(13) En el área de TB del LSPD se gestiona una gran cantidad de información de cada uno de los casos que se investigan, debido a esto se necesita que la forma en que se realiza el registro, procesamiento, seguimiento y generación de resultados de los casos sea efectiva brindando integridad en la información, por esta razón el área de tecnología del LSPD identificó que la manera en que se realiza la gestión de información: genera reproceso lo que conlleva a demoras para la evaluación de cada caso, incongruencias en la toma de datos y no existe seguridad en la información lo que causa que los resultados que se registren puedan ser alterados. 1.2.. ARBOL DEL PROBLEMA.. Ilustración 1. Árbol del problema.. 1.3.. FORMULACIÓN DEL PROBLEMA.. ¿De qué manera un sistema de información permite estandarizar (automatizar) los procesos de gestión de datos en las pruebas que llegan al área de Tuberculosis del Laboratorio de Salud Pública Departamental?. 13.

(14) 2. JUSTIFICACIÓN. La cantidad de datos equivalentes a muestras y resultados de diagnósticos que se procesan en el Laboratorio de Salud Pública Departamental proveniente de los distintos laboratorios de la red pública y privada de los 42 municipios del departamento del Valle del Cauca, solamente en el área de Tuberculosis es suficientemente grande para exigir la digitalización de los procesos que se llevan a cabo con las pruebas que se reciben, y de igual manera a la automatización de estos procesos analíticos. Debido a esto se ve en la necesidad de contar con un sistema de información que permita la correcta administración de las pruebas que le son entregados por todos los laboratorios de la red. El tener un sistema de información que cumpla con los alcances requeridos (integración con otros sistemas, seguridad de los datos, fácil utilización para el personal, entre otros) en la actualidad y con un correcto funcionamiento, permitirá un ágil procesamiento de información de pacientes o casos los cuales envían los laboratorios, y así conjuntamente tener una base de datos para un correcto control de los casos y la obtención de estadísticas. Está comprobado que laboratorios que en la actualidad manejen sus procesos de forma manual tienden a una gran cantidad de errores y una demora relativa a la hora de concebir y entregar análisis por parte de bacteriólogos encargados. “Los sistemas de información de laboratorios clínicos, constituyen hoy en día una herramienta indispensable y critica para la actividad de los laboratorios clínicos.”1 Teniendo en cuenta la situación que se presenta en el LSPD, en colaboración con la ingeniera de sistemas perteneciente a esta entidad se revisa el sistema de gestión de información actual y las fallas que presenta en sus funciones, tales como: concurrencia de errores en los registros, falta de permisos de usuarios para control de cambios, campos con ingreso de valores indeterminados, interfaces de informes de registros sin validaciones, con este análisis se determina la creación de un nuevo software que cumpla con la función de captura, procesamiento, trasmisión de datos y generación de informes, además de incluir un ingreso de usuarios con lo que permitirá dar control al accesos de la información en los registros del área de tuberculosis. Los bacteriólogos encargados son conscientes de que el aplicativo no solamente les ayudará a consolidar la información de manera oportuna y hacer los reportes debidos, sino que también les permitirá consultar historiales y así observar. 1[citado. el 1 julio del 2016]Disponible en. <http://datateca.unad.edu.co/contenidos/15001/Telesalud/leccin_41__sistema_de_laboratorio_clini co.html >. 14.

(15) diferentes variables que se puedan presentar de un resultado en un caso determinado. Adicionalmente se permitirá que usuarios de la Secretaria de Salud departamental y a usuarios de la red de Laboratorios públicos y privados, puedan realizar consultas de casos vía online, ya que se trabaja solamente de modo local.. 15.

(16) 3. OBJETIVOS. 3.1.. Objetivo general.. Desarrollar un sistema de información que permita la captura, procesamiento, transmisión y generación de informes, relacionados con los datos obtenidos de cada prueba que llega al área de Tuberculosis del Laboratorio de Salud Pública Departamental.. 3.2.. Objetivos específicos.. •. Analizar el proceso del levantamiento de requerimientos en la recepción de las pruebas en el área de Micobacterias.. •. Modelar los informes de seguimiento para los casos excepcionales que requieren un análisis continuo y además de cada caso registrado en el área de tuberculosis.. •. Desarrollar un proceso de registro estadístico para llevar control de la información.. •. Realizar pruebas y retroalimentación de resultados con la Red de Laboratorios Departamental (RLD).. 16.

(17) 4. MARCO REFERENCIAL. Antes de comenzar el análisis y diseño del sistema de información, es necesario tener claro algunos conceptos que se tendrán en cuenta en este proyecto.. 4.1.. MARCO TEÓRICO. 4.1.1. ANTECEDENTES. (Vasquez Rodriguez & Palacio Baena, 2009), en el trabajo de grado para optar al título de Especialista en Gerencia de proyectos, realizaron un estudio de factibilidad para la creación de un software que soportara la atención de los pacientes en los laboratorios clínicos de la ciudad de Medellín. Se resalta la importancia de un software para un laboratorio clínico sin importar el grado de complejidad, debido a que el servicio de atención para el paciente es mejorado. Este se encargaría de soportar procesos en recepción, procesamiento y análisis de exámenes, a la vez que lleve el control de registro de pruebas y resultados obtenidos de una manera oportuna, eficiente y confiable.. (Naranjo, 2015), en el trabajo de titulación como ingeniero en sistemas informáticos, diseño un sistema informático de registro, seguimiento y control de exámenes del laboratorio clínico “LAB D”. Resalta la importancia de la aplicación de sistemas de informáticos en el área de laboratorio clínico, ya que esto brinda controles necesarios a todos, y conducirá de una forma eficiente y permite alcanzar estándares de calidad y competitividad que exigen los servicios clínicos.. De igual manera, (Suarez Meza, 2013), en su trabajo de grado para obtener el título de ingeniero telemático, diseño e implemento un desarrollo web de historias clínicas digitales para la facultad de ciencias de la salud de la universidad católica de Manizales, explica el valor que ha adquirido la información o los datos y la necesidad de que el manejo de esta sea rápido y precisión en su ejecución, al igual que la seguridad e integridad de los datos. Y culmina diciendo que la implementación de sistemas de información en el campo de la medicina o cualquier otro campo del conocimiento o trabajo, mejora las condiciones de este y la seguridad de los pacientes.. 17.

(18) (Castillo Vargas, 2014), en su trabajo de grado Análisis, Diseño y Programación de un software para el registro y control del historial de los pacientes de CEMAD LTDA. Habla sobre el orden y concordancia de los documentos, sus secuencias, disponibilidad y prontitud a la hora de acceder, editar o revisar datos o información, es en la actualidad la prioridad de grandes o pequeñas empresas, y explica que el área de la salud no es la excepción. 4.1.2. Método de implementación La arquitectura más utilizada a la hora de implementar sistemas de servicios en ambiente web es la de cliente/servidor, por lo que normalmente las tareas son divididas para realizar un desarrollo paralelo en ambas partes, destinando tecnologías específicas para cada uno, partiendo de este concepto encontramos lo que hoy se denomina BACKEND y FRONTEND , siendo el BAKCEND la parte de desarrollo para el servidor donde se interactúa con la base de datos, y FRONTEND la parte de desarrollo para el cliente, o en la forma que se le presentara la información extraída del servidor en el navegador web. El uso y apropiación de esta arquitectura de desarrollo ha desencadenado la aparición de una cantidad considerable de framework de trabajos especializados en cada uno de estos métodos (tanto para el desarrollo backend, como para el frontend). El uso de framework para el desarrollo de aplicaciones es totalmente opcional, se puede seguir realizando un desarrollo de la manera que se desee, pero el uso de estos en ocasiones nos es de utilidad para acelerar los procesos de desarrollo, lo cual es muy bueno. Por lo general la mayoría de los framework destinados al desarrollo web están implementados siguiendo el patrón de desarrollo MVC (Modelo, Vista, Controlador). El motivo por el cual se escogió el desarrollo de la aplicación mediante el uso de un framework fue la necesidad de terminar en cierto tiempo una aplicación de un tamaño considerable, y el lenguaje PHP porque así estaba estipulado por los interesados en el software. Ya sabiendo la necesidad de utilizar un framework para el desarrollo y el lenguaje en el cual este debería estar escrito, pudimos delimitar la búsqueda de un framework acorde a nuestras expectativas. Realizando un filtro inicial entre la decena de framework PHP que encontramos en el mercado, se escogieron tres candidatos debido a su popularidad y valoración en el ámbito comercial, de los cuales deberíamos quedarnos con uno.. 18.

(19) LARAVEL. Este framework maneja una sintaxis expresiva, elegante, con el objetivo de eliminar molestias en el desarrollo web, facilita las tareas comunes, como es el caso de la autenticación, el enrutamiento, y cacheo. Cuenta con su propio motor de plantillas lo cual nos ahorra ciertas líneas innecesarias y aligerando por consiguiente la producción y desempeño de la aplicación a desarrollar. CODEIGNITER CodeIgniter cuenta con un amplio acceso a librerías para tareas comúnmente necesarias, así como una interfaz sencilla y una estructura lógica para el acceso a estas bibliotecas. Este Framework usa el enfoque controlador de MVC, que permite una gran separación entre la lógica y la presentación, especialmente útil para los proyectos en los que los diseñadores están trabajando en los archivos de plantilla.. SYMFONY Symfony cuenta con un amplio conjunto de componentes de gran reutilización, así como una metodología clara para ayudarle a trabajar de forma eficiente y eficaz en las tareas más complejas. Muchos otros framework basan su estructura utilizando elementos de symfony para mantenerse. Tiene una comunidad muy activa que no cesa en aportar ideas o código al desarrollo de novedades o mejoras de cara a futuras actualizaciones. El framework que elegimos para realizar el desarrollo de nuestra aplicación web fue LARAVEL, debido a su facilidad de aprendizaje y uso. Además, es actualizado constantemente y tiene una comunidad muy activa, posee una buena documentación con contenido claro y completo, usa las tecnologías modernas del lenguaje PHP y su ecosistema. LARAVEL tiene una gran aceptación actualmente para la construcción de aplicaciones web, el objetivo del patrón de arquitectura de software MVC es separar la lógica de la aplicación de la lógica de la vista de la aplicación haciendo uso de 3 componentes (Vistas, Modelos, Controladores). Para entender cómo funciona este patrón de arquitectura de software veamos cómo funciona en una aplicación de ambiente web.. 19.

(20) Ilustración 2. Ciclo de vida del patrón MVC. Resumamos los conceptos de los 3 componentes del patrón de diseño. MODELO. Es donde se guarda todo el negocio de la lógica de la aplicación. Este es el encargado de los datos, generalmente consulta a base de datos. Actualizaciones, búsqueda entre otras funciones van localizadas en esta parte, el modelo. CONTROLADOR. Recibe los datos del usuario y se encarga de solicitar los datos al modelo y comunicárselos a la vista. Estos aíslan la logia de los modelos con la de la interfaz o vista de una aplicación. VISTA. Esta es la representación visual de los datos, la parte de interfaz gráfica. Todo lo que el usuario puede ver va guardado en la vista, en ocasiones lo que se le es presentado al usuario es la combinación de varias vistas en una sola petición.. 4.2.. MARCO CONCEPTUAL.. La investigación aplicada conlleva el constituir un conocimiento para el desarrollo de métodos, y lo que se pretende es poner en práctica los conocimientos adquiridos en cursos de ingeniería aplicada durante el transcurso de la formación académica, entre estos podemos nombrar algunos como algoritmia, programación, bases de datos, análisis de sistema, diseño de sistemas, ingeniería de software, etc. Se considera que el proyecto se encuentra en el campo de tipo de investigación en desarrollo, el cual se encuentra definido en el manual Frascati, ya que se tiene como. 20.

(21) intensión realizar un desarrollo basándonos en conocimientos adquiridos mediante investigaciones y experiencias prácticas y así considerablemente mejorar un servicio.. 4.2.1. Ingeniería de Software. “Disciplina o área de la informática que ofrece métodos y técnicas para desarrollar y mantener software de calidad. Esta ingeniería trata con áreas muy diversas de la informática y de las ciencias de la computación, tales como construcción de compiladores, sistemas operativos, o desarrollos Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de sistema informático, los cuales puedan ser aplicados en cualquier área”2.. 4.2.2. Sistemas de Información. “Un sistema es un conjunto de componentes que interaccionan entre sí para lograr un objetivo común. Cabe aclarar que se pueden encontrar una gran variedad de sistemas, en su mayoría se representan a través de modelos formados por cinco bloques básicos: elementos de entrada, elementos de salida, sección de transformación, mecanismos de control y objetivos”3. Existen diversas definiciones de sistema, algo que no se puede decir en cuanto sistema de información se refiere. Actualmente, la expresión sistema de información se utiliza de forma común y habitual en las organizaciones; sin embargo, se pueden encontrar tantas definiciones como escuelas o autores del tema. Pero basándonos en la definición anteriormente dada a sistema, se podría realizar una aproximación definiendo sistemas de información como un conjunto de componentes que interactúan entre sí para lograr un objetivo común. 4.2.3. Metodologías Agiles.. 2. PRESSMAN, Roger. Ingeniería de Software: Un Enfoque Práctico. McGraw-Hill. 2003.. 3. FERNANDEZ A, Vicenç. Desarrollo de sistemas de información: una metodología basada en el modelo. Universitat. Politécnica. De Catalunya, Mar 1, 2010.. 21.

(22) Cada Metodología tiene características y hace hincapié en algunos aspectos específicos, a continuación, se resumen algunas metodologías. 4.2.3.1.. SCRUM. “Define un marco para la gestión de proyectos, que se ha utilizado con éxito durante los últimos 10 años. Está especialmente indicada para proyectos con un rápido cambio de requisitos. Sus principales características se pueden resumir en dos. El desarrollo de software se realiza mediante iteraciones, denominadas Sprints. El resultado de cada Sprint un incremento ejecutable que se muestra al cliente. La segunda característica importante son las reuniones a lo largo proyecto” 4.Los incrementos que corresponden a cada Sprint deben garantizar que se cumpla con los requisitos iniciales definidas por los interesados en el proyecto. Se debe establecer un listado de tareas como guía para definir unos puntos de entregas de forma que se tiene una planificación definida desde el momento de partida de un proyecto, con este listado de tareas se definen reuniones diarias que sirven como métodos para verificar y organizar la forma de trabajo, además de validar el incremento del producto al realizar cada entrega(Sprint). En la siguiente ilustración se observa el marco de trabajo Scrum:. Ilustración 3. Scrum framework. Fuente: wearmarketing. Un Sprint se puede constituir entre una a cuatros semanas, en este tiempo el Development Team Members (equipo) esta dedicados a la construcción del. 4. SCHWABER, Ken., SUTHERLAND, Jeff. BEEDLE, Mike. Agile Software Development with SCRUM. Prentice Hall. 2001.. 22.

(23) producto solicitado por el Product Owner (Dueño de producto) este es desarrollado a través del artefacto Product Backlog (Pila de producto). Cada vez que se finaliza un Sprint se realiza la entrega de un incremento, el plan de la siguiente iteración y la revisión respectiva de la iteración que se finalizó. La metodología Scrum presenta un equipo con su respetivo rol dentro de la creación de un producto como lo muestra la siguiente ilustración:. Ilustración 4. Roles en la metodología Scrum. Fuente: www.kzi.mx. El Product Owner (Dueño del producto), tiene como rol decidir en base al Product Backlog como se debe realizar el proyecto, dentro de sus habilidades está el dar apoyo y velar para que el desarrollo de las tareas sea de una forma correcta, de esta forma garantiza que en cada Sprint estén listas las historias de usuario, además debe tener disponibilidad de tiempo para asistir a las reuniones Sprint Planning donde se definen los contenidos de los Sprint a trabajar, con el fin de poder atender todas las dudas y consultas de parte del equipo de desarrollo. El Scrum Master (Coordinador del equipo Scrum), tienen con función guiar a el equipo de trabajo para llevar a cabo los procesos de Scrum, debe vigilar que se lleve un buen ritmo de trabajo y que se evidencie la aceptación del producto final por parte del Product Owner.. El Development Team Member, (Miembro del Equipo de Desarrollo) es el equipo encargado de toda la construcción del producto cumpliendo con la planeación que 23.

(24) se definió para cada Sprint, dentro de las personas que integran el equipo se encuentra el encargado de realizar ingeniería del requerimiento, el encargado de diseñar la solución, al que le delegan la función de construir el diseño y finalmente el que realiza las pruebas sobre el producto, este equipo de desarrollo es encargado de definir el estimado de tareas de acuerdo al Product Backlog y los miembros que tengan en sus equipos, además el equipo de desarrollo deben definir el listado de prioridades para las entregas en los Sprints. Para el Framework de Scrum se tienen los siguientes artefactos: Un Product Backlog (Pila de producto), este artefacto define la lista de tareas donde están ya están constituidas las prioridades con las que se planea llevar a cabo los puntos definidos en la lista. Este listado se crea a partir de las ideas que se generan por parte de los interesados en el proyecto, este listado es usado por parte del equipo de desarrollo con el fin de construir el producto. Sprint Backlog (Pila de Sprint), este artefacto define un listado de tareas similar al que se define en el Product Backlog, simplemente que para este solo se tendrá en cuanta las tareas que se ejecutaran para la entrega de un Sprint. El Product Increment (Incremento de producto), se obtiene cada que se entrega un Sprint en este se debe encontrar el Definition of Done (Definición de Hecho), con esta definición se valida que el Sprint entregado garantiza el cumplimiento del Sprint con calidad. El Definition Done, es similar a una lista de chequeos donde se valida que el listado de tareas para ese Sprint que se revisa cumpla con todo lo que se esperaba en ese Sprint. Para la metodología Scrum es importante la verificación y validación de sus procesos por lo que usa métodos de reuniones con diferentes funcionalidades como se muestra a continuación: Luego de realizar el primer levantamiento Product Backlog se llevará a cabo una actividad denominada Product Backlog Refinement de forma que se puede realizar ajustes de forma permanente durante todo el proyecto. Se lleva a cabo una reunión entre los tres roles principales que integran el proyecto (los Development Team Members, Scrum Master, Product Owner) denominada Sprint Planning esta se realiza cada que se realiza la entrega de un Sprint con la función de debatir y determinar cómo se definirá el siguiente Sprint. En esta reunión el Equipo Scrum debe responder a los siguientes interrogantes: ▪ ▪. ¿Qué trabajo será realizado en el siguiente Sprint? ¿Cómo se realizará el trabajo?. 24.

(25) Daily Scrum (Scrum Diario), esta actividad se lleva a cabo con el fin de evaluar si se está cumpliendo o quizá el equipo de trabajo está teniendo dificultades este se mide por medio de los siguientes interrogantes: ▪ ▪ ▪. ¿Qué has logrado desde el último Scrum Diario? ¿Qué piensas lograr desde ahora hasta el próximo Scrum Diario? ¿Qué te impide avanzar?. Cada vez finaliza un Sprint se realiza una actividad denominada Sprint Review donde su función es que los interesados en el proyecto den sus opiniones sobre el Product Increment entregado y saber si se tienen nuevas ideas o funcionalidades, en caso de ser así es probable que se deba estimar nuevas fechas para la finalización del proyecto Para mejorar la productividad tanto en el equipo como la calidad del producto se realiza una actividad denominada Sprint Retrospective (Retrospectiva del Sprint), esta actividad con el fin de verificar tanto las relaciones del equipo de trabajo, como de las herramientas y la forma de trabajo esto en búsqueda de mejorar y llenar optimizar las actitudes de todo el equipo de trabajo. 4.2.3.2.. Lean Development (LD).. “Definida por Bob Charette’s a partir de su experiencia en proyectos con la industria japonesa del automóvil en los años 80 y utilizada en numerosos proyectos de telecomunicaciones en Europa. En LD, los cambios se consideran riesgos, pero si se manejan adecuadamente se pueden convertir en oportunidades que mejoren la productividad del cliente. Su principal característica es introducir un mecanismo para implementar dichos cambios”5. 4.2.3.3.. XP.. “Es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las. 5. POPPENDIECK, Mary., POPPENDIECK, Tom. Lean Software Development: An Agile Toolkit. Addison Wesley. 2003.. 25.

(26) soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico”6.. 4.2.3.4.. Dynamic Systems Development Method (DSDM).. “Define el marco para desarrollar un proceso de producción de software. Nace en 1994 con el objetivo el objetivo de crear una metodología RAD unificada. Sus principales características son: es un proceso iterativo e incremental y el equipo de desarrollo y el usuario trabajan juntos. Propone cinco fases: estudio viabilidad, estudio del negocio, modelado funcional, diseño y construcción, y finalmente implementación. Las tres últimas son iterativas, además de existir realimentación a todas las fases”7.. 4.2.4. Definición generalizada de los sistemas de información. Conjunto de componentes interrelacionados que recolectan (o recuperan), procesan, almacenan y distribuyen información para apoyar la toma de decisiones y el control de una organización. De igual manera los sistemas de información ayudan a gerentes y trabajadores a analizar problemas, a visualizar asuntos complejos y a crear productos nuevos. Estos pueden ser formal e informal, pueden estar basados en ordenadores (o en tecnología de la información "Tics"), y en sistemas de información en el que se utiliza papel y lápiz. Los sistemas formales de información son aquellos que están apoyados en definiciones fijas y aceptadas de datos y procedimientos, y que operan en conformidad con reglas predefinidas. Por el contrario, los sistemas informales de información se basan en reglas de comportamiento no establecidas.. 6. BECK, Kent. Extreme Programming Explaned. Embrace Change. Pearson Education. 1999.. 7. Stapleton, Jennifer. CONSTABLE, Peter. DSDM Dynamic Systems Development Method: The Method in Practice. Addison Wesley. 1997.. 26.

(27) 4.2.5. Software de laboratorio clínico. “Un software de laboratorio clínico, tiene como objetivo principal, organizar, controlar, fortalecer, mejorar la calidad, automatizar, etc., la información en los laboratorios clínicos”8.. 8. [citado el 09 de julio del 2016] Disponible en < http://barretosoftware.com/portafolio/baxlabsoftware/. >. 27.

(28) 5. METODOLOGIA La información se recolecto pertinente para el desarrollo del sistema de información mediante visitas y entrevistas primeramente con la ingeniera encargada de los sistemas tecnológicos del Laboratorio de Salud Pública Departamental “Complejo De Servicios De Salud Pública Aníbal Patiño Rodríguez”. A continuación, se analizó cuidadosamente la información. Seguido de hizo el análisis y diseño para el desarrollo del sistema de información.. 5.1.. Metodología de desarrollo.. Por el perfilamiento del proyecto SILAT, se identificó inicialmente que para llevar acabo el desarrollo del sistema se tenía que hacer una revisión sobre las diferentes metodologías, con esto se estableció una tabla comparativa que sirvió para confirmar el uso de las metodologías Agiles sobre las metodologías tradicionales (Tabla 2). Métodos Agiles de desarrollo de software Grupos que los integran menos de 10 personas Los usuarios son más participativos en el desarrollo del proyecto principios Activos ante cualquier solicitud de cambios De gran importación para los momentos de exposición de cambios Planeación asistida en colaboración del usuario Diseños simples Transferencia del conocimiento. Métodos Tradicionales de desarrollo de software Grupos grandes y distribuidos Asistencia únicamente reuniones extraordinarias Normativas Resistente a cambios. mediante. Uso total de documentación durante el desarrollo del proyecto Planeación aislada Diseños con documentación integral y absoluta Desarrollos individuales. Tabla 2. Diferencias entre metodologías Agiles sobre las metodologías tradicionales.. Para el desarrollo del sistema de información del área de TB del LSPD, se hizo uso de la metodología de desarrollo Scrum, con esta metodología se disminuyó el riesgo de reproceso, ya que su enfoque se basa en avances a medida que se constituyen entregas, esto se pudo notar en los momentos que se tenían iteraciones con los. 28.

(29) usuarios de la aplicación, con ellos se revisaban los prototipos del software y así se identificaron errores y se proponían mejoras. Por la metodología Scrum la interacción con los usuarios seria de mayor colaboración, con esto el primer momento para la metodología fue la identificación de los STAKEHOLDER (Tabla 3) STAKEHOLDER Kattia Cortés Ingeniera de sistemas del Laboratorio de Salud Publica Lina Claudia Taborda Recepción de correspondencia y muestras Dra. María Beatriz Olaya González Coordinación del Laboratorio de Salud Pública Departamental Fernanda Ortiz Bacterióloga del área Micobacterias. Cristina Urquijo. Bacterióloga del área Micobacterias. Lina Valencia. Bacterióloga del área Micobacterias. GESTORES Y DESARROLLADORES Jhonnier Yair Mosquera Estudiante asignado al proyecto SILAT Oscar Fabián Mejía Estudiante asignado al proyecto SILAT Tabla 3. Grupo de trabajo para el desarrollo de SILAT. Con la metodología de desarrollo Scrum se llevó a cabo un concepto de buenas prácticas para trabajar colaborativamente en equipo, con este método se obtuvieron mejores resultados en el proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipo altamente productivo. En el proceso de desarrollo de la aplicación se realizaron entregas parciales y regulares de la aplicación SILAT. Por la metodología Scrum el proyecto se ejecutó mediante iteraciones, normalmente cada 2 semanas. Cada iteración arrojaba un resultado completo, en avance en el aplicativo SILAT, con las características necesarias para entregarlo a los usuarios del Laboratorio, cuando fuera solicitado. Los ciclos de actividades se llevaron a cabo en el siguiente orden: •. Planificación de la iteración. Se realiza el primer día de la iteración y consta de dos partes: a) Selección de requisitos. En el proceso de desarrollo del proyecto SILAT se definieron los requerimientos por parte de los usuarios del Laboratorio,. 29.

(30) en el momento de realizar el levantamiento de los requerimientos se definió con el grupo de trabajo las prioridades para desarrollo del proyecto. b) Planificación de la iteración. Se concertaron fechas de tiempos de 2 horas con los usuarios interesados en el desarrollo del proyecto, en los que se realizaba la revisión de las tareas pendientes y los compromisos para las fechas estipuladas, se revisaban avances y validaban opciones de mejora, todo este tipo de iteraciones se registraban por medio de acta definidas por el grupo del Laboratorio, las fechas se definieron de acuerdo a los espacios disponibles de los interesados por el proyecto con el fin de no interrumpir los espacios que tuvieran gran impacto en sus labores prioritarias. •. Ejecución de la iteración. Para el desarrollo del proyecto se tenían reuniones entre el grupo de desarrollo diariamente, revisando con prioridad los temas en los que se observaran riesgos, prioridades y validación, de igual forma se tenían presente los compromisos y definiciones pendientes de tal forma que se pudiera tomar medidas para prevenir que los riesgos se convirtieran en fallas con los compromisos ya establecidos con los usuarios del proyecto.. •. Inspección y adaptación. La reunión de revisión de la iteración es realizada en el último día de la iteración. Tiene dos partes: a) Demostración. Esta revisión se llevó a cabo con todos los usuarios interesados en el proyecto, se realizaron pruebas y validaciones de funcionamiento, seguridad y validación, con el fin de que el proyecto esté cumpliendo el listado de requerimientos establecidos inicialmente, con esta revisión se realizaron las ultimas sugerencias para definir las ultimas mejoras y así se realizó una valoración sobre el prototipo final cumpliendo con las expectativas del usuario. b) Retrospectiva. Entre el grupo de desarrollo se tomó en cuenta los tiempos usados y el trabajo realizado, identificando cada uno de los casos en que los que se visualizó un riesgo no se atendió con prioridad las consecuencias en tiempo perdido, también se identificó la dependencia que se extiende al no definir una prioridad de forma adecuada, todo eso se tomó como lecciones aprendidas para optimizar los procesos de desarrollo de proyectos.. 30.

(31) 6. ANALISIS 6.1.. Descripción del sistema anterior. El Laboratorio de Salud Pública recibía las muestras recolectadas por cada una de las entidades del Valle del Cauca que pertenecen a la red de Laboratorios, los gestores o auxiliares del Laboratorio realizaban el registro de estas muestras en las Fichas de ingreso, de acuerdo a esa información realizaban la clasificación de estas muestras por la estructura que está definida por el Laboratorio, para aquellos casos que es requerido hacer una revisión por el área de Tuberculosis sería remitida a ella. En el momento que las muestras eran remitidas a el área de Tuberculosis, se realizaba una revisión por medio de una base de datos local y administrada desde un archivo de formato Excel, esto con el fin de validar si el paciente que se relaciona a la muestra ya había sido remitido, si era un paciente nuevo o cuál ha sido la evolución de este paciente según los datos obtenidos por los exámenes para el área. Luego de que se realizaba la revisión de las muestras en primera instancia se realizaba una asignación de exámenes, con los que se evalúan vulnerabilidad o resistencia a ciertos fármacos, este tipo de información se realizaba de forma reiterativa de acuerdo al tipo de evaluación que se estaban realizando, esta información se registraba en una ficha físicas para resultados de exámenes, estas fichas se guardaban en archivos pues es el insumo para realizar estudios estadísticos que se reportan trimestral ante Instituto Nacional de Salud sobre la situación actual y los riesgos que se están teniendo por estos tipos de bacterias. Registro de las muestras ante el Laboratorio Registro de Muestras para el área de Tuberculosis. Registro de exámenes y resultados de pruebas de Laboratorio. Diagrama 1de proceso actual de registros de información. 31. Consolidado de registros históricos.

(32) Teniendo en cuenta que este tipo de registros de las muestras en el Laboratorio se realizaban de forma física en fichas definidas y estructuradas por el Instituto Nacional de Salud, se tiene un control inicial que sirve como un método de llevar registros consecutivos, con información y definiciones sobre a qué área se debe remitir, sin embargo, este control no es de mayor eficiencia para la consolidación, validación y tiempos de ejecución de los registros. El sistema anterior se compone de 4 funcionarios que interactuaban en cada uno de los procesos de registros, son roles completamente diferentes y con funciones afines a la parte especifica en el proceso en que realiza la ejecución de su tarea. Por esta razón se hace necesario que el sistema es multiusuarios.. 6.2.. Definición de requerimientos por el usuario. Dentro del proceso de desarrollo del sistema se realizó la recolección de la información y requerimientos por medio de actas informativas donde quedaba registrada la necesidad que tenía el laboratorio, esta información se registraba con ayuda de los auxiliares del laboratorio y los Bacteriólogos directamente implicados con el registro, valoración y consolidación de muestras. Con esto se pudo identificar los requerimientos y quedaron plasmado de la siguiente forma R1. R2. R3. R4. R5. R6. Requerimientos Funcionales Se requiere un sistema de información que realice el registro, almacenamiento, procesamiento y consolidación de las muestras que llegan al área de tuberculosis en el Laboratorio de Salud Pública. Se requiere un sistema de información que maneje los perfiles de usuarios que ingresan, modifican y administran la muestra de laboratorio Se requiere un sistema de información que fije las plantillas de registros tal como se suministran por el INS. Se requiere un sistema de información que valide que los campos que sean registrados por los usuarios tengan relación y no se puedan realizar registros inadecuados o inconsistentes. Se requiere un sistema de información que capture los registros y los almacene en la base de datos del Laboratorio de forma en que se pueda consultar para realizar; ajustes y validaciones por parte de los funcionarios del Laboratorio de Tuberculosis. Se requiere un sistema de información que realice un consolidado de los registros estadísticos de manera. 32.

(33) R1. trimestral, para los informes que se realizan en el laboratorio. Se requiere un sistema de información genere los informes de resultados de las pruebas registradas por el Laboratorio de Tuberculosis Requerimientos no funcionales El sistema de información debe ser de fácil uso y. R2. El sistema de información Debe ser multiusuarios. R7. R3. La base de datos debe ser desarrollada en MySQL Tabla 4. Definición de requerimientos por el usuario.. Para la implementación del sistema de información del Laboratorio de Tuberculosis, se evaluó la mejor forma para cumplir con los requerimientos que por parte de Laboratorio necesitaba entre estos el método que cumplía el método(SCRUM) esto se determina debido a que por disposición tanto del grupo de desarrollo como de los usuarios del Laboratorio simplificaría en tiempos en el levantamiento de información, diseño y ejecución; con esto se busca tener una retroalimentación en las etapas del desarrollo del sistema de información y evitar reproceso al momento de realizar la implementación. Inicialmente se definieron los usuarios que van a realizar uso del sistema de información para determinar cuál sería el rol y los privilegios dentro del sistema estos se encuentran relacionados a continuación: Usuarios. Funciones en SILAT Administrar roles y perfiles, permisos de usuarios y autenticaciones. Administrador Consultas (funcionarios de otras áreas) Laboratoristas-Operador (Bacteriólogos del área) Recepcionistas. Consultar Consultar, crear, modificar, eliminar Consultar, crear, modificar. Tabla 5. Perfiles de usuarios y funciones en el sistema.. 33.

(34) 7. DESARROLLO 7.1.. Diagrama de caso de uso extendido.. Ilustración 5. Diagrama de caso de uso extendido.. 34.

(35) 7.2.. DIAGRAMA DE HERENCIA DE LOS ACTORES.. Ilustración 6. Diagrama de herencia de los actores.. 7.3.. SPRINT 1: INGRESO AL SISTEMA.. En el sprint planning se determinó que el primer sprint tendría como tareas la realización del ingreso al sistema. El desarrollo de esta primera tarea no tuvo problema alguno durante su desarrollo, y se terminó en el tiempo acordado por las partes (8 días). En el Sprint Backlog que se muestra a continuación se verán los resultados obtenidos en el primer sprint. 7.3.1. Sprint Backlog para el Sprint 1. Sprint. F. Inicial. F. Final. Responsable. Duración. 1. 29/08/2016. 06/09/2016. Desarrollador encargado. 8 días. ID 1. HISTORIA Ingresar al sistema. Estado Completado. Tabla 6. Sprint Backlog para el Sprint 1.. 35.

(36) A continuación, se muestra la interfaz que se obtuvo para el ingreso al Sistema.. Ilustración 7. Interfaz de bienvenida del sistema.. En la siguiente tabla se explica detalladamente la imagen. SILAT Historia Nombre: ID:. 1. Rol:. Ingresar al sistema Sprint:. 1. Puntos de historia. 3. Como un usuario. Fecha:. 29/08/2016. Prioridad:. Alta. Descripción: Como un usuario se necesita ingresar al sistema con la intención de usarlo. Procedimiento: El usuario debe digitar el dominio que se le fue asignado al aplicativo. Una vez digitado el dominio de la aplicación SILAT y haberle dado ir o intro este lo redireccionará a la siguiente pantalla de bienvenida. Observaciones: Para la dirección de cabecera HTTP se sugirió la siguiente: silat.app. Tabla 7. Historia ingreso al sistema. 36.

(37) 7.4.. SPRINT 2: INICIAR SESION. 7.4.1. Sprint Backlog para el Sprint 2. Sprint. F. Inicial. F. Final. Responsable. Duración. 2. 07/09/2016. 15/09/2016. Desarrollador encargado. 8 días. ID 2. HISTORIA. Estado. Iniciar sesión. Completado. Tabla 8. Sprint Backlog para el sprint 2. SILAT Historia Nombre: ID:. 2. Rol:. Iniciar sesión Sprint:. 2. Puntos de historia. 3. Como un usuario. Fecha:. 07/09/2016. Prioridad:. Alta. Descripción: Como un usuario se necesita ingresar al sistema con la intención de usarlo. Procedimiento: El usuario debe seleccionar el botón de la parte superior derecha de la pantalla el cual es el botón de “Inicio de Sesión”. Observaciones: Cabe aclarar que el único usuario que existe es el del Admin, el cual luego deberá crear y asignar usuario y contraseña a cada una de las personas que interactuaran con el sistema. Tabla 9.Historia Iniciar sesión. 7.4.2. Caso de uso para el Sprint 2.. 37.

(38) Iniciador: usuario. Resumen: Este caso de uso es utilizado por cualquiera de los usuarios, para iniciar sesión. Se solicita el usuario y contraseña a través de una interfaz gráfica. Precondiciones: En el sistema debe existir registro del usuario que desea ingresar. Iniciar sesión Usuario. Sistema. 1. Activa la interfaz Iniciar sesión. 2. Presenta la interfaz. 3. Ingresa la información solicitada en cada campo (usuario, contraseña). 4. valida la información ingresada. Tabla 10. Caso de uso para el Sprint 2.. Postcondiciones: El usuario accede a la interfaz principal del sistema. Flujo principal: El actor en este caso de uso es el Usuario que solicita ingreso al sistema. El sistema presenta la interfaz de inicio de sesión, en la cual se piden los datos de acceso (usuario y contraseña), y hace clic en el botón iniciar sesión. Subflujo 1 • •. El sistema verifica que la información ingresada sea la correcta o se encuentre en el sistema. Si los datos son correctos el sistema concede el acceso al sistema.. Flujo de excepciones:  El sistema muestra un mensaje de error si el usuario o la contraseña son incorrectos.. 38.

(39) 7.4.3. Diagrama de Secuencia.. Ilustración 8. Diagrama de secuencia iniciar sesión.. 7.5.. SPRINT 3: GESTIÓN DE USUARIOS.. El administrador podrá crear, editar y eliminar usuarios del sistema al dar clic en el botón “Usuarios”.. 7.5.1. Sprint Backlog para el Sprint 3. Sprint. F. Inicial. F. Final. Responsable. Duración. 3. 16/09/2016. 24/09/2016. Desarrollador encargado. 8 días. ID. HISTORIA. Estado. 3. Crear usuario. Completado. 4. Editar usuario. Completado. 5. Eliminar usuario. Completado. 39.

(40) Release Gestión de usuarios que estarán en el sistema Tabla 11. Sprint Backlog para el sprint 3.. SILAT Historia Nombre: ID:. 3. Rol:. Crear usuario Sprint:. 3. Puntos de historia. 2. Como administrador del sistema. Fecha:. 16/09/2016. Prioridad:. Alta. Descripción: Como administrador del sistema necesita Crear usuario. Procedimiento: El administrador hace clic en el botón “Nuevo usuario” e ingresar al formulario la siguiente información Entidad/Institución, Nombre, Apellidos, Dirección, Teléfono, Celular, Usuario, Correo electrónico, Contraseña y Tipo de usuario. Observaciones: A la hora de crear el usuario hay que tener mucho cuidado con el “tipo de usuario” que se le asigne al usuario, debido a que por petición de los interesados del sistema es manejado mediante rol o tipo de usuarios y así dependiendo del tipo de usuario que se le haya asignado, así mismo podrá ingresar al módulo que le corresponda. Los roles disponibles para los usuarios son (Administrador, Consultor, Recepcionista y Operario). El sistema salvará los cambios cuando el Administrador presione el botón “Registrar”. Tabla 12. Historia Crear usuario.. SILAT Historia Nombre: ID: Rol:. 4. Editar usuario Sprint:. 3. Puntos de historia. Como administrador del sistema. 40. 2. Fecha:. 18/09/2016. Prioridad:. Alta.

(41) Descripción: Como administrador del sistema necesita Editar usuario. Procedimiento: El administrador podrá actualizar o editar los datos de un usuario existente dando clic en el botón con una imagen de lápiz e ingresar al formulario para editar la siguiente información Entidad/Institución, Nombre, Apellidos, Dirección, Teléfono, Celular, Usuario, Correo electrónico y Tipo de usuario. El sistema salvará los cambios cuando el Administrador presione el botón “Editar”. Observaciones: A la hora de editar el usuario hay que tener mucho cuidado con el “tipo de usuario” que se le asigne al usuario, debido a que por petición de los interesados del sistema es manejado mediante rol o tipo de usuarios y así dependiendo del tipo de usuario que se le haya asignado, así mismo podrá ingresar al módulo que le corresponda. Los roles disponibles para los usuarios son (Administrador, Consultor, Recepcionista y Operario). El sistema salvará los cambios cuando el Administrador presione el botón “Editar”. Tabla 13. Historia Editar usuario.. SILAT Historia Nombre: ID:. 5. Rol:. Eliminar usuario Sprint:. 3. Puntos de historia. 2. Como administrador del sistema. Fecha:. 20/09/2016. Prioridad:. Alta. Descripción: Como administrador del sistema necesita Eliminar usuario. Procedimiento: El administrador podrá eliminar los datos de un usuario existente dando clic en el botón con una imagen de reciclaje. Al pulsar el botón con una imagen en forma de caneca de basura o reciclaje se abre un cuadro de dialogo en el cual se pide la confirmación para la eliminación del usuario del sistema. Observaciones: Al intentar eliminar un usuario el sistema muestra un mensaje, preguntando si en realidad se está seguro de eliminar dicho registro. Tabla 14. Historia Eliminar usuario.. 41.

(42) 7.5.2. Caso de uso para el Sprint 3. Iniciador: Administrador del sistema. Resumen: Este caso de uso es utilizado por el administrador del sistema, para ingresar información al sistema de los usuarios que van a usarlo, asignando nombre de usuario y contraseña. Precondiciones: El administrador debe haber ejecutado el caso de uso de iniciar sesión. Crear usuario Administrador del sistema. Sistema. 1. Activa la interfaz Gestión de Usuario. 2. Presenta la interfaz. 3. Selecciona el botón “Usuarios”. 4. Presenta la interfaz de Usuarios. 5. Selecciona el botón “Nuevo Usuarios”. 6. Presenta formulario. 7. Ingresa la información solicitada en cada uno de los campos 8. Almacena la (Entidad/Institución, Nombres, Apellidos, Dirección, Teléfono fijo, teléfono información en la tabla celular, usuario, correo, contraseña, Tipo usuario). usuarios. Tabla 15. Caso de uso Crear usuario.. Postcondiciones: El administrador del sistema puede consultar, actualizar y eliminar la información de los usuarios ingresada en el sistema. Flujo principal: El actor en este caso de uso es el Administrador del sistema quien podrá activar la interfaz Gestión de Usuarios. El administrador podrá crear, editar y eliminar usuarios del sistema al dar clic en el botón Usuarios. Subflujo 1 • • •. El administrador podrá registrar los datos de un nuevo usuario al hacer clic el botón Nuevo usuario. Luego de diligenciar el formulario con los datos del usuario se debe dar clic en el botón registrar para que este sea registrado en la base de datos del sistema. Después de registrar el nuevo usuario el sistema lo redireccionara a la pantalla con el listado de usuarios, y un mensaje informándole que se a registrado el nuevo usuario.. Subflujo 2. 42.