• Author / Uploaded
• api-454596176

Citation preview

UNIVERSIDAD MARIANO GALVEZ DE GUATEMALA CAMPUS DE HUEHUETENANGO INGENIERÍA EN SISTEMAS Y CIENCIAS DE LA COMPUTACIÓN ANALISIS DE SISTEMAS FRANCISCO RAUL MORALES

IMPLEMENTACIÓN DE UN SISTEMA INTELEGENTE PARA EL CONTROL DE INFORMACION DEL CAIMI DEL MUNICIPIO DE CUILCO, DEPARTAMENTO DE HUEHUETENANGO.

Integrantes FRANCISCO JAVIER LÓPEZ MÉNDEZ VENANCIO CRUZ MATEO BALTAZAR PAULO LEONARDO ALVARADO GRANADOS JESUS MARIANO MENDEZ NOLASCO JONATHAN JOEL CARDONA CHAVEZ

No. de Carné 0904-16-4016 0904-16-6103 0904-16-17105 0904-16-3956 0904-16-3641

DESCRIPCIÓN La implementación de tecnología en la mayoría de los sectores productivos y sociales se ha vuelto una tendencia ya que esta práctica facilita, automatiza procesos y con ello se mejora la rapidez para alcanzar los objetivos deseados. Tal es el caso del Sector de la Salud Pública; este sector es uno de los más importantes y fundamentales de los sectores ya que todos los seres humanos necesitamos alguna vez visitar a un médico o ir a un Sanatorio Publico, pero lamentablemente estos establecimientos por ser de carácter Público no cuentan con una buena atención, ya que carecen de un Sistema Inteligente para el control de información, por lo cual este proyecto va encaminado a la realización de un Sistema de Control de Información para el CAIMI del Municipio de Cuilco, Huehuetenango; ya que dicho centro no cuenta con ningún tipo de sistema relacionado al que se desea elaborar. En dicho centro se carece de muchos elementos fundamentales para la atención de las personas que necesiten ser atendidas. Esto es porque no se cuenta con un sistema que sea capaz de almacenar toda la información para poder demostrar que el centro necesita ya sea más personal, insumos, y todas las cosas de las cuales se necesita día con día en la atención de las personas. OBJETIVO GENERAL: El objetivo primordial del proyecto es realizar, diseñar e implementar un sistema encaminado al control, y recolección de información orientado al Sector Salud Pública, específicamente en el CAIMI del Municipio de Cuilco, Huehuetenango, que sea capaz de almacenar información de los pacientes que son atendidos en la sala de emergencia, pediatría y odontología. OBJETIVOS ESPECIFICOS: 

Realizar un análisis sobre todas las deficiencias de la atención a los ciudadanos que llegan diariamente a solicitar algún servicio de la entidad.



Utilizar toda la información obtenida para la elaboración y diseño de un sistema de información a implementar.



Elaborar un modelo de base de datos relacional que se acomode a los requerimientos de almacenamiento y manipulación de datos de información de la institución del CAIMI del Municipio de Cuilco, Huehuetenango.



Realizar el diseño de una interfaz gráfica amigable y cómoda para el usuario que le permita interactuar con el sistema de forma fácil e intuitiva.

ALCANCE 

El sistema permitirá realizar la autenticación y autorización de los usuarios a las distintas formas y funcionalidades que serán proporcionadas por el sistema.



El sistema permitirá el ingreso de datos de pacientes que se encuentren en la sala de espera, proporcionando un documento donde se encuentre dicha información que posteriormente será utilizada por el Médico que lo atenderá.



El sistema permitirá realizar citas de los pacientes con los médicos con días de anticipación el cual generará un documento impreso de carácter de contraseña para ingresar a la cita.



El sistema será capaz de poder determinar si un Médico se encuentra disponible o está atendiendo una cita o un paciente, con ello se mejorará la atención a los pacientes.



El sistema brindará la información de los medicamentos que se encuentran en bodega para poder brindarles de manera gratuita a los pacientes.



El sistema permitirá brindar información sobre las referencias que emiten hacia la cabecera departamental, aunado a ello la información de los vehículos que deberá ser actualizada diariamente por los pilotos de turno.

INDICE INTRODUCCIÓN: ............................................................................................................................ 1 1.

CAPÍTULO 1: Generalidades ............................................................................................... 2 1.1.

Definición de Problema ................................................................................................ 2

1.2.

Marco Conceptual .......................................................................................................... 2

1.2.1.

Implementación ...................................................................................................... 3

1.2.2.

Sistema ..................................................................................................................... 3

1.2.3.

Inteligencia ............................................................................................................... 3

1.2.4.

Control....................................................................................................................... 4

1.2.5.

Información .............................................................................................................. 4

1.3.

Plan del Proyecto ........................................................................................................... 4 Metodología y Procedimiento ............................................................................. 5

1.1.1. 1.1.1.1. 1.1.2.

Riesgos de Proyecto. ............................................................................................ 7

1.1.3.

Plan de Respuesta ante riesgos. ........................................................................ 8

1.4. 2.

Descripción y sustentación de la solución. .......................................................... 10

CAPÍTULO 2: 2.1.

ANÁLISIS .......................................................................... 12

Definición de la metodología de solución ............................................................. 12

2.1.1.

Proceso Unificado Racional (RUP) .................................................................. 12

2.1.2.

Proceso Unificado Ágil (AUP) ........................................................................... 13

2.1.3.

SCRUM .................................................................................................................... 14

2.1.3.

Elección de la metodología ............................................................................... 15 Requerimientos funcionales ................................................................................. 17

2.2. 2.2.1. 2.3.

Consideraciones sobre el sistema .................................................................. 23

Análisis de la solución ................................................................................................ 24

2.3.1.

3.

Grupo del Proceso de Iniciación .................................................................... 5

Asignación de funciones a hardware y software ............................................. 26

2.3.2.

Restricción de costo y tiempo .......................................................................... 27

2.3.3.

Definición del sistema ......................................................................................... 27

CAPITULO 3 ........................................................................................................................... 29 3.1 Arquitectura de la solución............................................................................................. 29 3.1.1. Representación de la arquitectura ....................................................................... 29 3.1.2. Evaluación................................................................................................................... 30 3.1.2. Arquitectura orientada hacia la presentación Web .......................................... 31

3.1.3. Diseño de la arquitectura de la solución ............................................................ 34 3.1.4. Vista Lógica ................................................................................................................ 37 3.1.5. Vista de Despliegue .................................................................................................. 38 3.1.6. Diagrama de clases de diseño ............................................................................... 39 3.1.7. Diagrama de base de datos .................................................................................... 43 3.1.8. Diagramas de secuencia ......................................................................................... 43 3.2.1. Estándar de Interfaz Gráfica ................................................................................... 44 4.

CAPÍTULO 4: 4.1.

Construcción ................................................................................................................. 48

4.1.1.

Lenguaje de programación ................................................................................ 48

4.1.2.

Arquitectura utilizada .......................................................................................... 49

4.1.6.

Otras herramientas y librerías .......................................................................... 49

4.2.

5.

CONSTRUCCIÓN .................................................................... 48

Pruebas ........................................................................................................................... 50

4.2.1.

Estrategia de Pruebas ......................................................................................... 50

4.2.2.

Tipos de Pruebas.................................................................................................. 50

4.2.3.

Catálogo de pruebas ........................................................................................... 52

4.2.4.

Reporte de ejecución de pruebas .................................................................... 52

CAPITULO 5: Observaciones, conclusiones y recomendaciones: ......................... 53 5.1.

Observaciones .............................................................................................................. 53

5.2.

Conclusiones................................................................................................................. 54

5.3.

Recomendaciones y Políticas de Actualización .................................................. 54

5.4.

Anexo: Fotografías del Grupo .................................................................................. 55

Bibliografía ..................................................................................................................................... 56 Glosario........................................................................................................................................... 57

INTRODUCCIÓN:

La finalidad primordial del proyecto es proporcionar una solución a la problemática que se vive diariamente en el Sector de Salud Pública, ya que la atención que se brinda en los hospitales, sanatorios, centros de salud pública; es muy precaria, y carece de muchos servicios que se deberían prestar a los ciudadanos.

Por lo cual este proyecto va encaminado a la elaboración, diseño e implementación de un Sistema de Control de Información que permitirá minorizar todas las deficiencias de la atención de los ciudadanos en el Sector Salud Pública, en el CAIMI del municipio de Cuilco, Huehuetenango.

El municipio de Cuilco presenta una alta carencia de calidad de atención a los Ciudadanos por lo cual este proyecto va enfocado a mejorar de alguna manera la atención médica a los habitantes de dicho municipio.

Uno de los objetivos es minimizar el deterioro de los vehículos que se utilizan para el traslado de pacientes, ya que es uno de los factores que mas se ven afectados en este sector ya que muchos de los empleados no le dan el cuidado necesario y aunado a ello dichos vehículos se utilizan para fines personales; lo cual se minimizará con la implementación de dicho sistema ya que cada ves que los vehículos sean utilizados deberá actualizarse la información de los vehículos. Esto aumentará un mejor control en dicho aspecto.

Otra de las finalidades es minimizar la preferencia a los amigos y familiares de los empleados, ya que todos los pacientes serán atendidos de forma simultánea en base a la hora que hayan llegado, ya que es otro factor que también afecta la atención de los pacientes. También permitirá establecer prioridades en atender primero a un paciente que venga de lejos y sea de emergencia.

1

1. CAPÍTULO 1: Generalidades 1.1.

Definición de Problema

Con el surgimiento de nuevas y mejores herramientas en tecnologías de información orientadas a la automatización de procesos, actividades y el cumplimiento de los objetivos en las organizaciones públicas y privadas, en la actualidad éstas se consideran en todo ámbito un factor de cambio determinante para el mejoramiento y desarrollo de las actividades del sector salud. Los hospitales vienen integrando estas herramientas de apoyo para los trabajadores para poder suplir tareas establecidas.

Por otra parte, el hospital de CAIMI (en sus siglas Centro de Atención Materno Infantil) actualmente cuenta con una herramienta de informática la cual no está en funcionamiento por falta de conocimiento de la misma, también porque no cumple con las demandas de dicho hospital, con esta problemática este dicho hospital debe registrar pacientes de una forma trabajosa y tardada como lo es registrándolo en un libro de actas y así también para todo tipo de actividades que deben quedar registradas para un control del hospital, este es un gran inconveniente ya que no solo es tardado sino que también cuando se necesite ingresar varios pacientes al mismo tiempo no podrá por el método que tienen para ingresar sus registros, agregándole la inseguridad del mismo ya que con este método se corre el riesgo de que puedan alterar los datos de algún registro, la eliminación del mismo o peor aún la desaparición de todos los registros. 1.2.

Marco Conceptual El marco conceptual “está compuesto de referencias a sucesos y situaciones y pertinentes, a resultados de investigación, incluye, por tanto, un marco de antecedentes, definiciones, supuestos, etc.” (Ortiz, 2011, p.4)

2

1.2.1. Implementación La palabra implementar permite expresar la acción de poner en práctica, medidas y métodos, entre otros, para concretar alguna actividad, plan, o misión, en otras alternativas. El verbo implementar hace referencia a la aplicación de una medida o a la puesta en marcha de una iniciativa. Lo implementado, por lo tanto, está en funcionamiento o en vigencia (Párrafo obtenido

de

Definición

ABC,

Fecha:

octubre.

2012,

URL:

https://www.definicionabc.com/general/implementar.php). 1.2.2. Sistema Un sistema es un conjunto de elementos relacionados entre sí que funciona como un todo. La palabra sistema procede del latín systēma, y este del griego σύστημα (systema), identificado en español como “unión de cosas de manera organizada”. De esta palabra se derivan otras como antisistema o ecosistema. Los elementos que componen un sistema pueden ser variados, como una serie de principios o reglas estructuradas sobre una materia o teoría (Párrafo obtenido de significados.com, Actualizado: 30/01/2019, Url: https://www.significados.com/sistema/). 1.2.3. Inteligencia El término inteligencia proviene del latín intelligentia, que a su vez deriva de inteligere.

Esta

es

una

palabra

compuesta

por

otros

dos

términos: intus (“entre”) y legere (“escoger”). Por lo tanto, el origen etimológico del concepto de inteligencia hace referencia a quien sabe elegir: la inteligencia posibilita la selección de las alternativas más convenientes para la resolución de un problema. De acuerdo a lo descrito en la etimología, un individuo es inteligente cuando es capaz de escoger la mejor opción entre las posibilidades que se presentan a su alcance para resolver un problema (Párrafo obtenido de Definición de Publicado: 2008. Actualizado: 2012, Url: https://definicion.de/inteligencia/).

3

1.2.4. Control EL control puede ser el dominio sobre algo o alguien, una forma de fiscalización,

un mecanismo

para

regular algo

manual

o

sistémicamente o un examen para probar los conocimientos de los alumnos sobre alguna materia. La palabra control deriva del francés antiguo controle que se refería a un registro que lleva un duplicado (Párrafo obtenido de Significados.com, actualizado: 21/02/2017, Url: https://www.significados.com/control/). 1.2.5. Información Como información denominamos al conjunto de datos, ya procesados y ordenados para su comprensión, que aportan nuevos conocimientos a un individuo o sistema sobre un asunto, materia, fenómeno o ente determinado.

La

palabra,

como

tal,

proviene

del

latín informatĭo, informatiōnis, que significa ‘acción y efecto de informar’. La importancia de la información radica en que, con base en esta, podemos solucionar problemas, tomar decisiones o determinar cuál alternativa, de un conjunto de ellas, es la que mejor se adapta a nuestras necesidades. El aprovechamiento que hagamos de la información, en este sentido, es la base racional del conocimiento (Párrafos obtenidos de Significados.com,

actualizado:

16/02/2017,

Url:

https://www.significados.com/informacion/).

1.3.

Plan del Proyecto

El Método a utilizar será el de la Cadena Crítica no solo por ser el más joven de todas las metodologías para la gestión de proyectos propuestas y más sin embargo, es la más aplaudida por sus excelentes resultados en cuanto a la gestión de proyectos. Está especialmente indicado para proyectos complejos por su cualidad de simplificar el seguimiento y controla ejercer. Los aspectos más destacables de esta técnica son:

4



Facilita el establecimiento de prioridades y la toma de decisiones.



Garantiza una efectiva protección de proyecto.



Su funcionamiento se basa en la detección de las actividades que marcan la duración máxima del proyecto, que pasan a ser consideradas como actividades críticas.



Para lograr la eficiencia se reducen los plazos estimados para la consecución de las actividades, según el plan inicial y, en su lugar, se establecen amortiguadores de tiempo que se sitúan en puntos estratégicos.



Pueden distinguirse tres tipos de amortiguadores (de proyecto, de alimentación y de recurso), cada uno de los cuales cuenta con una función de protección distinta, siendo todas ellas complementarias y necesarias.



La forma de controlar el desarrollo del proyecto se reduce a monitorizar la velocidad de consumo de los buffers y tomar las acciones necesarias cuando

convenga.

(Párrafo

obtenido

de

obs-edu.com,

Url:

https://www.obs-edu.com/int/blog-project-management/administracionde-proyectos/las-3-metodologias-para-la-gestion-de-proyectos-que-masse-utilizan )

1.1.1. Metodología y Procedimiento Para la gestión de este proyecto decidimos realizar varios lineamientos para adaptar el análisis lo mejor posible a nuestras necesidades y tener una mejor visión de lo que se requiere en el sistema.

1.1.1.1.

Grupo del Proceso de Iniciación

En este proyecto tenemos el propósito de desarrollar un sistema de ayude a las personas a manejar mejor los datos de una clínica, con esto verificaremos a los interesados y mejores beneficiados para desarrollar el

5

acta de la construcción del proyecto y satisfacer los objetivos y expectativas, de tal forma iniciar el proyecto.

1.1.1.2.

Grupo del Proceso de Planificación

En esta etapa planificaremos el alcance del proyecto, para poder ser lo más realista posible a la hora de utilizar recursos, y así prever la calidad, el costo y el riesgo que podemos controlar con la elaboración y mantenimiento del proyecto. Nos es importante definir las acciones y la modalidad sobre cómo planificar, ejecutar, supervisar, controlar y cerrar, como lo es llevar una documentación de los datos obtenidos acerca de las necesidades y lo que se requiera para el sistema, hacer una descripción detallada del sistema, indicando lo que realizará y lo que no realizará para evitar problemas futuros. Con la descripción del sistema llevaremos a cabo un análisis de los riesgos posibles a incurrir, para especificar las actividades que se realizaran si en dado caso se dieran o la forma en que podremos evitarlos, los cuales se detallarán más adelante.

1.1.1.3.

Grupo del Proceso de Ejecución

Para el control de calidad verificaremos el sistema a través de pruebas, que serán realizadas por el método de prueba y error, de tal forma que podremos asegurarnos de que el producto final sea de buena calidad, intuitivo, y muy amigable con los usuarios finales.

6

Esta es una fase muy importante ya que es aquí donde definimos formalmente la arquitectura del producto, definimos como va a estructurarse y definimos las tecnologías que mejor se adaptan a nuestras necesidades y a las de los usuarios finales. Todos esto se realizará de acuerdo a los lineamientos y técnicas del equipo de trabajo. Utilizaremos metodologías diversas para acomodarnos bien en la planificación del proyecto.

1.1.1.4.

Grupo del Proceso de Seguimiento y Control

Tenemos como propósito supervisar, analizar y controlar los avances que vayan surgiendo en el proyecto, identificando posibles cambios que requiera el sistema de tal forma que podamos satisfacer los objetivos del proyecto. Gestionaremos el control de calidad, por cada cambio realizado, verificando el costo y los riesgos que conllevan los cambios, para poder encontrar las mejores soluciones a nuestros problemas y evitar retrasos.

1.1.1.5.

Grupo del Proceso de Cierre

Formaremos esto con los procesos que involucran la etapa final del proyecto, que incluye una verificación del sistema antes de su entrega.

1.1.2. Riesgos de Proyecto. En secciones previas justificamos las razones por las cuales era imprescindible mantener una correcta gestión de riesgos y planes de acciones para encarar cualquier incidente imprevisto durante el desarrollo del 7

trabajo. A continuación, presentamos una relación de posibles eventos los cuales de presentarse provocarían retrasos o desfases en el normal avance del trabajo. En el PMBOK se define el término riesgo como un evento incierto cuya ocurrencia provoca efectos en los objetivos del proyecto repercutiendo en el alcance, cronograma, costo y calidad (PMI 2008). El riesgo puede ser clasificado como: •

Riesgos técnicos, de calidad y/o rendimiento: Este grupo se encuentra presente durante las actividades de diseño y desarrollo del producto deseado y en donde intervienen aspectos de carácter técnico en su elaboración y control de calidad.

•

Riesgos en la gerencia de proyectos: Son riesgos presentes en parte de los procesos de gestión y dirección llevados a cabo. Su manejo queda bajo la responsabilidad del equipo del proyecto.

•

Riesgos organizacionales: Son riesgos provenientes de la misma organización laboral o profesional a quienes el proyecto y/o producto impacta directa o indirectamente en sus funciones. Para fines de este proyecto este grupo no aplicará para la gestión de riesgos.

•

Riesgos externos: Son riesgos presentes en el ámbito exterior (entorno) de la organización. Para fines de este proyecto este grupo no aplicará para la gestión de riesgos.

1.1.3. Plan de Respuesta ante riesgos. A continuación, presentamos las acciones que están orientadas a velar por una correcta dirección de proyecto respecto al manejo y control de riesgos

8

para minimizar lo mejor posible los efectos negativos que llegaren a causar, y respetar el plan cumpliendo eficazmente los objetivos del proyecto. •

En la etapa de Planificación se invertirá el tiempo razonable en capturar y formalizar correctamente los requerimientos del producto y contrastando las soluciones con opinión de expertos y profesionales quienes juntamente con los usuarios finales avalen el proceso automatizado. Bajo este juicio de expertos los requerimientos no presentarán mayores variantes durante el proceso. Consolidada esta etapa es importante especificar las actividades y tareas a efectuar en el proyecto asegurando la adjudicación de tiempos razonables en función a la naturaleza del riesgo, junto con las acciones a seguir.

•

En la etapa de Ejecución se contarán con los entornos de desarrollo y bibliotecas de la plataforma de programación procurando su mantenimiento y constante actualización vía conexión a Internet. Con el acceso a Internet, los cursos de Platzy, StackOverflow y otros documentos se podrá favorecer el equipo de desarrollo durante la recopilación de conocimiento acelerando la fase de aprendizaje y capacitación en dichas herramientas. La arquitectura será sometida a pruebas durante la implementación a través de casos de uso breves validando la entrada de datos según el mecanismo propuesto por la arquitectura y diseño original. Las labores de codificación irán de la mano con la realización de pruebas para validación de las casuísticas una vez concluida la implementación de cada módulo junto con sus funcionalidades antes de la presentación de las respectivas iteraciones.

•

En la etapa de Seguimiento y Control, específicamente para la administración del cambio se llevará un procedimiento de evaluación y ejecución de cambios en la implementación. Toda solicitud de 9

cambio implicará su contraposición ante el modelo de negocio originalmente conceptualizado y en caso de proceder se ejecutarán las medidas correctivas a nivel de análisis, diseño e implementación.

1.4. Descripción y sustentación de la solución. Como este proyecto está encaminado a la elaboración de un sistema inteligente que pueda ayudar al control de información en el CAIMI del municipio de Cuilco, Huehuetenango. Dicho sistema está basado en las actividades informáticas referentes a el área de medicina, y frente a la problemática en torno a la necesidad de una solución informática para la gestión de los datos en el CAIMI y adaptada a la realidad local, se proponemos la implementación de un sistema de información para el cumplimiento de estos propósitos ofreciendo las funcionalidades claves para flexibilizar la gestión de la información. Se planea utilizar herramientas que permitan solucionar los problemas típicos que se presentan a la hora de manejar grandes cantidades de datos, solucionando así la optimización de las búsquedas de información en las distintas áreas de la institución. Con ello intentamos conseguir que se utilice menos el papel, ya que no es seguro, porque se pueden estropear con el tiempo, ya sea porque se hayan mojado, quemado o perdido, que suele ser muy común en muchos lugares, además que conseguimos reducir el gasto en papel y ayudamos al medio ambiente, a conservar un recurso muy importante. Para utilización del sistema los usuarios podrán almacenar información, leerla y modificarla cuantas veces quieran, dependiendo el usuario que sean, y los permisos que tengan ya que no todas las personas tendrán permitido entrar al sistema, y así solucionamos el problema de la seguridad, ya que existen personas maliciosas que quieran hacerse con la información para uso inadecuado.

10

El sistema podrá generar informes que ayudaran al personal a realizar las tareas que son muy repetitivas y así aumentar su productividad en su trabajo y tener mayor capacidad de operación, para cuando la población crezca y así también realizar estadísticas inteligentes sobre cómo se encuentra el municipio y tomar acciones que ayuden a controlar los problemas que esto puedan generar.

11

2. CAPÍTULO 2:

ANÁLISIS

En el desarrollo de este capítulo generalizamos los conceptos y describiremos la metodología del desarrollo de software aplicada junto con los requerimientos y restricciones identificados en los distintos servicios que realiza el CAIMI del municipio de Cuilco, departamento de Huehuetenango. Dando el análisis de la solución se presentan las evaluaciones de viabilidad técnica y económica, la asignación de funciones a los elementos del producto y la definición del sistema. 2.1. Definición de la metodología de solución A continuación, se presentan las dos metodologías candidatas para el desarrollo de la solución. Posteriormente se exponen las justificaciones respecto a la elección de una de estas propuestas. 2.1.1. Proceso Unificado Racional (RUP) La metodología RUP utiliza el enfoque de la orientación a objetos en su diseño y está diseñado y documentado el uso de la notación UML para ilustrar los procesos en acción. Utiliza técnicas y prácticas probadas comercialmente en los proyectos digitales y software de escritorio. Y que, para la gestión de proyectos, la metodología RUP proporciona una solución disciplinada como las tareas y responsabilidades señaladas dentro de una organización de desarrollo de software. Esta metodología de desarrollo de software basada en un enfoque iterativo con una adecuada adaptación de los cambios durante el proceso de desarrollo, sumada a la correcta gestión de requerimientos incorporando al diseño de software el lenguaje UML, definido como un sistema de modelamiento visual para la representación gráfica de casos de uso, clases de análisis, componentes de software entre otros. Un elemento clave en la concepción de RUP es el aseguramiento de la calidad del software. RUP es, en sí, un producto de software. Es modular y automatizado, y toda su metodología se apoya en varias herramientas de desarrollo integradas y 12

vendidos por IBM a través de sus “Suites racional.” Este método es un proceso propietario de la ingeniería de software creado por Rational Software, adquirida por IBM, ganando un nuevo nombre Irup que ahora es una abreviatura Rational Unified Process y lo que es una marca en el área de software, proporcionando técnicas que deben seguir los miembros del equipo de desarrollo de software con el fin de aumentar su productividad en el proceso de desarrollo. 2.1.2. Proceso Unificado Ágil (AUP) Esta metodología de desarrollo de software evita los tortuosos y burocráticos caminos de las metodologías tradicionales enfocándose en la gente y los resultados. Es un marco de trabajo conceptual de la ingeniería de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en cortos lapsos de tiempo. El software desarrollado en una unidad de tiempo es llamado una iteración, la cual debe durar de una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener un demo al final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto. Los métodos Agiles enfatizan las comunicaciones cara a cara en vez de la documentación. La mayoría de los equipos Agiles están localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento”. La oficina debe incluir revisores, diseñadores de iteración, escritores de documentación y ayuda y directores de proyecto. Los métodos ágiles también enfatizan que el software funcional es la primera medida del progreso. Combinado con la preferencia por las comunicaciones cara a cara,

13

generalmente los métodos ágiles son criticados y tratados como "indisciplinados" por la falta de documentación técnica. 2.1.3. SCRUM Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos. En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad y la productividad son fundamentales. Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable, cuando se necesita capacidad de reacción ante la competencia, cuando la moral de los equipos es baja y la rotación alta, cuando es necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de producto. Ya que en Scrum un proyecto se ejecuta en ciclos temporales cortos y de duración fija iteraciones que normalmente son de 2 semanas, aunque en algunos equipos son de 3 y hasta 4 semanas, límite máximo de feedback de producto real y reflexión. Cada iteración tiene que proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo solicite.

14

2.1.3. Elección de la metodología De acuerdo con los parámetros y las necesidades que va a requerir el sistema se utilizara la metodología de desarrollo Proceso Unificado Ágil (AUP), por estas siguientes razones: La metodología AUP ofrece un amplio marco de buenas prácticas en la fase de construcción de software en búsqueda de la optimización promoviendo medidas como la ejecución de pruebas en paralelo con la programación, así como el manejo de unidades de prueba. Del mismo modo por sus principios derivados de RUP, se constituye como una de las metodologías más aplicadas para el análisis, implementación y documentación de sistemas orientados a objetos. AUP cuenta con actividades de carácter iterativo e incremental y tomando en cuenta las propuestas del paradigma, cambios del producto en paralelo con la codificación, favorecen al logro de un producto software en menor tiempo y bajo una comunicación horizontal en el tratamiento de cambios es decir el equipo de desarrolladores reunido directamente con el cliente o los pacientes, para conocer sus necesidades. En lugar de una comunicación vertical, la solicitud de cambio transmitida a través de una serie de revisiones, usuarios y analistas. Como RUP prioriza a un grado mayor la documentación se opta por un paradigma de trabajo con entregables esenciales y específicos para el entendimiento de la solución final. 2.1.3.1.

Fase de Iniciación

El propósito en esta fase es asimilar los requerimientos esperados de la solución y plasmarlos en la definición y especificación de los casos de uso. Asimismo, como apoyo a los procesos de gestión, se presenta la programación definitiva de las actividades y tareas conforme a la planificación del proyecto como: diagrama de Gantt y WBS junto con la relación de riesgos identificados. Los documentos como el catálogo de requerimientos, las especificaciones de requisitos de software, el 15

cronograma del proyecto, la lista de riesgos, el plan de proyecto y enunciado de alcance se encuentran en observación durante esta fase. 2.1.3.2.

Fase de Elaboración

En esta fase el propósito es construir y probar la arquitectura descrita en el documento de arquitectura del sistema. Entre los entregables requeridos durante esta fase conviene citar el documento de análisis juntamente con el diagrama de clases de análisis y el documento de diseño es decir acompañado del diagrama de clases de diseño. Otras actividades involucradas en esta fase serian:  La Identificación de las necesidades de hardware y software para el proyecto.  La Elaboración del documento de arquitectura del sistema.  La Elaboración del documento de diseño de base de datos.  La Elaboración de estándares de programación e interfaz gráfica.  El Establecimiento de las iteraciones, así como de las especificaciones del plan de pruebas de software.

2.1.3.3.

Fase de Construcción

Siguiendo con las fases, en esta se comprende las labores de codificación y pruebas del producto a partir de las pautas definidas en los documentos de análisis y diseño. Tabla 2.1 Plan de Iteraciones del Proyecto No. De Iteraciones

Descripción

I

Programación y pruebas de las funcionalidades del módulo Seguridad.

II

Programación y pruebas de las funcionalidades del módulo Comunicaciones. 16

III

Programación y pruebas de las funcionalidades del módulo Pacientes.

IV

Programación y pruebas de las funcionalidades del módulo Organización

V

Programación y pruebas de las funcionalidades del módulo Planeamiento.

VI

Programación y pruebas de las funcionalidades del módulo Evaluaciones.

VII

Programación y pruebas de las funcionalidades del módulo Reportes.

2.1.3.4.

Fase de Transición

Esta fase tiene como objetivo principal la puesta del sistema en producción es decir afinando las pruebas integrales, juntamente a la capacitación de los usuarios y conversiones de sistemas en caso existieran. A su vez se completará la documentación final del sistema. Las actividades involucradas son:  Desarrollo de pruebas unitarias y pruebas de integración  Cierre de documentación técnica

2.2. Requerimientos funcionales La presentación de estos requerimientos fue separada por cada módulo identificado en la tabla 2.2. Tabla 2.2 Requerimientos funcionales del sistema MÓDULO PERSONALES DEL CAIMI No. 1

Descripción

Tipo

El sistema posibilitará las consultas y reportes de los Funcional pacientes, los empleados, y toda la información necesaria del CAIMI del municipio de CUILCO, departamento de Huehuetenango. 17

Dif. Pri. 3

2

2

El sistema permitirá el mantenimiento de los Funcional

2

2

1

1

3

3

perfiles de usuario y accesos al sistema. El perfil especifica las acciones permitidas y restringidas durante la navegación por las páginas, para uno o más usuarios. Los accesos considerados por cada página son de sólo lectura, acceso completo o ninguno. 3

El sistema permitirá la asignación del perfil de Funcional usuario a uno o varios usuarios. El sistema permitirá la personalización de accesos al sistema para una cuenta de usuario. El sistema permitirá

cambiar

la

configuración

de

accesos

otorgados previamente a un usuario a través de un perfil, a manera de personalizar sus accesos para eventualidades laborales. 4

El sistema posibilitará al usuario el cambio de su Funcional contraseña de acceso al sistema. Desde el panel de mantenimiento de datos el usuario podrá cambiar la contraseña en caso lo requiera.

MÓDULO COMUNICACIONES No. 1

Descripción

Tipo

El sistema permitirá el envío y recepción de Funcional

Dif. Pri. 2

1

1

1

2

1

información entre los usuarios del sistema, entre algunas citas de los pacientes en el CAIME medicamentos, recetas y entre otros. 2

El sistema permitirá a los Administradores del Funcional CAIMI, ver los reportes y asistencias de pacientes en el centro de salud.

3

El sistema permitirá a los pacientes imprimir o Funcional consultar ya sea sus recetas o citas establecidas. 18

4

El

sistema

posibilitará

a

los

usuarios

y Funcional

3

1

administradores inclusive los mismos pacientes la gestión de alguna cita en el CAIME

MÓDULO PACIENTES No. 1

Descripción

Tipo

El sistema permitirá registrar y actualizar información Funcional

Dif. Pri. 3

1

2

1

Funcional

2

1

El sistema permitirá registrar y actualizar el control Funcional

2

1

del paciente. El sistema permitirá registrar información general del paciente, tanto datos personales propios como los familiares o referencias. 2

El sistema permitirá el mantenimiento de las citas Funcional o asistencias en el CAIMI.

3

El sistema permitirá registrar y actualizar el control de citas al centro de atención.

4

de citas a emergencias de los pacientes.

19

MÓDULO ORGANIZACIÓN No. 1

Descripción El

sistema

permitirá

el

Tipo

mantenimiento

de

la Funcional

Dif. Pri. 3

2

2

1

1

1

1

1

3

2

3

2

Funcional

2

1

El sistema posibilitará la asignación de citas o Funcional

2

1

información de todas las personas que asistirán en el CAIMI, y también la información del personal del CAIMI, como también el gestión y administración de documentos interno y externo. 2

El sistema permitirá el mantenimiento de toda la Funcional información de las personas que asistirán en el CAIMI, y el porque de su asistencia.

3

El

sistema

permitirá

el

mantenimiento

de Funcional

actividades clasificadas por citas o el tipo de visita que se esta realizando. 4

El sistema permitirá el mantenimiento de citas Funcional asignadas por día.

5

El

sistema

indicadores

permitirá de

el

mantenimiento

evaluación.

Los

de Funcional

indicadores

cuantificarán el avance de un objetivo. 6

El sistema permitirá el mantenimiento de objetivos. Funcional Los objetivos consisten en logros puntuales esperados en los pacientes se atendido bien.

7

El sistema permitirá asociar actividades por cada cita, examen, o gestión médica.

8

exámenes a los especiales en el área.

20

MÓDULO PLANEAMIENTO No. 1

Descripción

Tipo

El sistema permitirá el mantenimiento de toda la Funcional

Dif. Pri. 1

1

2

1

1

1

3

1

2

2

información de las personas que visitan el CAIMI. El programa englobará las actividades y tareas según la terapia adecuada y escala de severidad del trastorno padecido por el paciente. 2

El sistema permitirá incorporar algunas gestiones Funcional extras en los tramites internos y externos al momento de mandar algún paciente a otro centro de salud.

3

El sistema permitirá modificar la duración de lo que se Funcional tarda el paciente en el CAIMI.

4

El sistema permitirá el mantenimiento de eventos y Funcional observaciones ocurridas durante la ejecución del programa de salud, por cada paciente.

5

El sistema posibilitará el mantenimiento de recetas. Los documentos no deberán superar los 8MB para su carga y descarga.

21

Funcional

MÓDULO EVALUACIONES No. 1

Descripción

Tipo

El sistema posibilitará la evaluación de los Funcional

Dif. Pri. 2

1

2

1

2

3

3

1

programas de salud de los pacientes. Las cuales estarán organización con la información que tendrá el personal administrativo. 2

El sistema posibilitará la evaluación de los planes de Funcional tareas de los pacientes. Las cuales el personal deberá ser capacitado al momento de manejar el sistema.

3

El sistema permitirá el mantenimiento de evaluaciones Funcional de las citas o exámenes que fueron realizadas días, meses e incluso años atrás.

4

El sistema permitirá a los usuarios externos evaluar Funcional cómo se está llevando el control de todas la información y la gestión de tramites lo que respecta en el área. MÓDULO REPORTES

No. 1

Descripción

Tipo

El sistema emitirá reportes de citas y asistencias Funcional

Dif. Pri. 2

3

1

1

2

3

2

3

de pacientes. 2

El sistema generará el informe de avances y progresos Funcional las citas y asistencias de pacientes.

3

El sistema generará el reporte de todas las citas, el Funcional porque la asistencia del paciente en el CAIMI.

4

La emisión de reportes tendrá como formato único en PDF (Portable Document Format).

22

Funcional

2.2.1. Consideraciones sobre el sistema Para el cumplimiento de estos alcances de la propuesta quedan excluidas las automatizaciones de los procesos en contabilidad, logística, gestión de planillas y recursos humanos en el centro de salud. En contraparte, se respetarán las siguientes restricciones: Validación La información ingresada por teclado es verificada como medida preventiva ante posibles errores en el proceso. Seguridad Acceso al sistema a personas mediante cuentas de usuario y contraseña. En función a los perfiles y accesos se controlará el nivel de visibilidad de la información. Escalabilidad La arquitectura posibilitará la incorporación de nuevas funcionalidades y módulos flexiblemente sin procedimientos drásticos para el desarrollador. Usabilidad Para la familiarización del usuario con el software se requiere una interfaz gráfica ligera e intuitiva sumada a una correcta emisión de avisos de error y advertencia. El usuario iniciará todas las operaciones requeridas. Performance Garantiza un tiempo de acceso no mayor a siete (7) segundos. Como consecuencia de las entrevistas efectuadas y según los requerimientos analizados a partir de la lista de exigencias, se presenta a continuación la descripción de los actores participantes del sistema. Usuario Toda persona con una cuenta y accesos autorizados al sistema.

23

Administrador Realiza funciones tales como administrar cuentas, perfiles de usuario y monitorear el funcionamiento del sistema. La notificación de errores a presentarse con la plataforma es competencia exclusiva de este actor. Usuario Especialista Denominas a este usuario especiales como el DBA, el cual tiene el poder de administrar todo el sistema, ver que el sistema este funcionando correctamente. 2.3. Análisis de la solución Se presenta a continuación el trabajo llevado a cabo durante el análisis del grupo. Nos pudimos darnos cuenta de que el control de todas las informaciones que maneja el CAIMI desde el personal, los tramites internos y externos, hasta todas las personas que llegan. Podemos optimizar todo este control. Identificación de las necesidades de los pacientes

Como principales necesidades establecidas por el personal y las personas que visitan el CAIMI se obtuvieron los siguientes alcances:  El control de todas las informaciones que se está manejando, debido a la gran cantidad de pacientes activos en el CAIMI.  Acceso inmediato a todo información y documentación de salud algún paciente.  Establecimiento de un mecanismo de verificación de la asistencia del personal, a manera de que se puede ver que todo el personal esta cumpliendo bien su deber.  Planificación de algunas actividades o campañas de salud.  Registro de incidencias, emergencias que se tiene durante el día, el mes.  Evaluación de los programas de salud a cada paciente.  Evaluación del desempeño de los personales y la capacidad de poder atender. 24

Estas necesidades indicadas quedan cubiertas por los requerimientos del sistema dada la similitud entre las expectativas de usuarios con las funcionalidades del nuevo sistema. A partir de la lista de exigencias y habiendo identificado las necesidades de los usuarios es factible construir el diagrama de casos de uso y actores.

25

2.3.1. Asignación de funciones a hardware y software Las funciones asignadas al hardware durante el proyecto son:  Como servidor Web, cumplir con el almacenamiento físico de la aplicación Web.  Como servidor de base de datos, cumplir con el almacenamiento físico del servidor de base de datos.  Albergar aplicaciones ofimáticas y herramientas CASE e IDE requeridas para labores de análisis, diseño, construcción y pruebas. Las funciones asignadas al software durante el proyecto son:  Asistir al tesista en las actividades de diagramación, modelamiento y documentación durante las fases de análisis y diseño.  Permitir la codificación óptima y eficiente de los módulos, componentes y funcionalidades de la solución.  Permitir la construcción de la interfaz gráfica de la aplicación vía código HTML o por arrastre de elementos gráficos (drag & drop). En cuanto al producto software, como principales funciones comprometidas se tienen:  Interactuar con los servidores y el computador cliente desde el cual se conecta el usuario.  Cumplir con la ejecución de los procesos de gestión de salud obtenidos a partir de la lista de exigencias de las personas que asisten en el CAIMI. Las funciones asignadas a nivel de base de datos a lo largo del proyecto son:  Almacenar una base de datos única para las operaciones de lectura y escritura.  Permitir el almacenamiento y recuperación de la información necesaria.  Permitir la realización de copias de seguridad de la información albergada en la base de datos. 26

 De ser necesario, admitir las configuraciones de conexión con la base de datos realizadas dentro o fuera del motor de base de datos. Las funciones asignadas a los usuarios durante el transcurso del proyecto son:  Colaborar con el levantamiento de información de los requerimientos.  Ingresar los datos apropiados de acuerdo con los propósitos de cada módulo incorporado a la solución.  Cumplir con las pruebas de software necesarias  Participar

activamente

en

las

reuniones

de

coordinación

e

implantación del sistema. Las funciones asignadas al equipo a lo largo del proyecto son: 

Dirigir, coordinar y ejecutar las actividades técnicas y funcionales.



Gestionar y evaluar cada proceso a manera que se puede implementar un sistema eficiente.

2.3.2. Restricción de costo y tiempo Los integrantes del equipo contamos con los equipos descritos y únicamente se incurren en gastos logísticos y en el personal del proyecto, este costo final no deberá extenderse en más del 15% respecto al costo estimado original, frente a futuras adendas. Por su parte, el cronograma de entregas de tesis representó para el proyecto una restricción en cuanto a tiempos, ocasionando retrasos debido a la obligatoriedad en el cumplimiento de las correcciones solicitadas en los entregables por el asesor. 2.3.3. Definición del sistema Se presenta la definición del sistema a partir del diagrama de clases de análisis involucrando a las entidades principales en el modelamiento del escenario de negocio. Este análisis favorecerá al establecimiento y definición

27

de la arquitectura final junto con las clases de diseño necesarias para su construcción. 2.3.3.1.

Paquete Seguridad

Este paquete reúne las funcionalidades de administración de usuarios como, por ejemplo: LOS CUARTOS, PACIENTES, ENFERMERAS POR PACIENTES, PACIENTES POR DOCTORES. Toda información que involucre con el CAIMI. 2.3.3.2.

Paquete Pacientes

Este paquete reúne las funcionalidades de gestión de información de pacientes y la toma de asistencia a las sesiones y eventos. La clase pacientes es responsable de la integración con el módulo Seguridad en las operaciones de asignación de especialistas en el sistema. 2.3.3.3.

Paquete Comunicaciones

Este paquete permite el envío y recepción de información con los pacientes y hacia los encargados de atender es decir ya sean enfermeros, doctores o especialistas en el área. 2.3.3.4.

Paquete Organización

Este paquete cubre las funcionalidades de mantenimiento de información de las personas que asisten en el centro de Salud, el porqué de su asistencia, así como la gestión de exámenes. Y como principal objetivo es el control de información de todo el personal desde el conserje, chofer, portero, enfermeros, doctores, administradores. 2.3.3.5.

Paquete Evaluaciones

Este paquete reúne las funcionalidades de evaluación de todas las citas, recetas, exámenes de todas las personas que asisten en este centro de Salud. 2.3.3.6.

Paquete Reportes

Este paquete cumple con emitir informes de asistencia, informe, de todo lo que está pasando en el CAIMI del municipio de Cuilco, departamento 28

de Huehuetenango. Desde la cantidad de paciente que se tiene al día, al mes y al año. El tipo de citas, sexo de pacientes, rango de edad de los pacientes. Toda información necesaria que se va a requerir relacionado con el CAIMI. Este sistema Inteligencia posibilitara toda esa información.

3. CAPITULO 3 En este capítulo se describe el diseño de la solución propuesta. La primera parte comprende el diseño en alto nivel de la arquitectura justificando la elección de un patrón arquitectónico. Respecto a la interfaz gráfica, se mencionan los patrones y estándares adoptados para uniformizar el aspecto visual y la interacción con el usuario

3.1 Arquitectura de la solución En esta sección se presenta el diseño a alto nivel y los paradigmas de arquitectura evaluado para la posterior presentación final

3.1.1. Representación de la arquitectura En base a los capítulos anteriores, la arquitectura se orientó a los entornos web bajo este diseño las tareas se ejecutan en el servidor, evitando delegar esta responsabilidad a los equipos de los clientes desde sus navegadores Lo cual asegura la disponibilidad a tiempo completo y desde cualquier equipo fijo o móvil con una conexión a internet. Por lo que el diseño debe garantizar un óptimo aprovechamiento

de

las

capacidades

web

satisfaciendo

los

requisitos

fundamentales. Entre las fortalezas exigidas a la arquitectura se encuentran:  La arquitectura respetara el paradigma de programación orientada a objetos. Esta característica depende del lenguaje de programación utilizado, la propuesta de diseño debe asegurar la manipulación de datos y operaciones de 29

manera encapsulada a través de clases y objetos interrelacionados entre sí por invocaciones a los métodos respectivos. El manejo de cambio en los productos, lograr modificaciones a las características de un número determinado de componentes sin comprometer el funcionamiento del resto de módulos.  La lógica del negocio, la arquitectura trabajara bajo el patrón Modelo de Dominio el cual consta de un conjunto de objetos de negocio representando las entidades en un domino y sus relacione, el modelo representa en forma abstracta el negocio real encapsulando las reglas de negocio y recreando asi un flujo de trabajo habitual conocimiento del mecanismo de persistencia de los datos, delegando esta responsabilidad a otro ámbito.  La arquitectura para el manejo de la capa de datos adoptara el patrón de repositorio. Que encapsula un conjunto de objetos en una base de datos junto con sus operaciones de lectura y escritura, el cual provee un visión mas orientada a objetos en la ccapa de persistencia logrando dos metas, brindar una clara separación y dependencia en un solo sentido

3.1.2. Evaluación En las siguientes secciones se describen dos tendencias arquitectónicas candidatas perfectamente aplicables para el diseño a alto nivel de la aplicación. Ambas propuestas cuentan con el soporte tecnológico para su realización, sin embargo difieren en el modo de comunicación entre los componentes lógicos del sistema.

30

3.1.3. Arquitectura orientada hacia la presentación Web El patrón Modelo – Vista – Controlador (MVC) tiene sus orígenes desde 1979 por una comunidad de usuarios del lenguaje Smalltalk proveniente de los laboratorios de investigación en Xerox. Bajo este diseño el modelo de dominio (de datos y aplicaciones), la presentación y las acciones basadas en la información ingresada por el usuario quedan separados bajo estos tres componentes (Mancini 2003):  Modelo: En este ámbito se gestionan las comunicaciones entre el dominio de datos y dominio de aplicación atendiendo las consultas sobre su estado (realizadas con frecuencia desde la Vista) así como a las instrucciones de cambio de estado (usualmente desde el Controlador).  Vista: Este ámbito maneja la visualización de la información en un formato adecuado para el usuario y su interacción.  Controlador: Este ámbito funciona interpretando las acciones del usuario sea por el teclado o el mouse, informando al modelo y/o a la vista sobre los cambios a realizarse en cada ámbito.

Como uno de los beneficios bajo este diseño destaca el soporte a múltiples vistas de una misma aplicación al mismo tiempo, aprovechando un único modelo de datos. La incorporación de nuevas vistas (por ejemplo, para dispositivos de plataformas diversas) no altera de sobremanera el comportamiento del modelo. En contraparte, adoptando este patrón trae consigo una fuerte dependencia hacia los eventos en la interfaz de usuario, incrementando la complejidad en la programación y control de tales acciones según las reglas de negocio. Asimismo la codificación del modelo debe efectuarse tomando en cuenta la vista, para así evitar escenarios en los cuales un modelo al manejar múltiples cambios en el dominio pudiera sobrecargar a la vista con solicitudes de actualización, en tanto algunas vistas ralentizarían su ejecución quedando inoperativas ante tales sobrecargas. La figura 3.1 grafica las interacciones en el patrón MVC. 31

CONTROLADOR

MODELO

VISTA

3.1.2.2. Arquitectura orientada hacia la implementación Web

El patrón de arquitectura en N-Capas (Mancini 2003) comprende la implementación de la presentación, la lógica de negocio y la base de datos en capas por separado donde N representa el número de capas conformadas en la arquitectura. Los componentes residentes en una determinada capa pueden interactuar con sus pares ubicados en la misma capa o con componentes residentes en capas inferiores. Cada capa podría residir físicamente en ambientes diferentes favoreciendo así a la escalabilidad del software (ver figura 3.2).

Layer N …… Layer j Layer j-1 …… Layer 1 Figura 3.2 Patrón de arquitectura en N-Capas (Macini 2003)

La interacción con las capas inferiores presenta dos enfoques. El enfoque estricto en capas ocurre cuando interactúan una capa (J) y la capa inmediata inferior (J-1). El enfoque flexible ocurre con la interacción entre una capa (capa N) con otras ubicadas en niveles inferiores y en cualquier orden (capas J, J-1, J-3, entre otras). 32

El enfoque flexible ofrece mejoras en eficiencia pues los tiempos de respuesta de las llamadas entre capas son inferiores a diferencia del primer enfoque. No obstante podría presentar conflictos en caso amerite el cambio en el orden de capas, pues no provee el mismo nivel de aislamiento a diferencia del primer enfoque (Mancini 2003).

Debido al acoplamiento y cohesión entre las capas la implementación de cambios recae sobre una parte de la solución, minimizando el impacto hacia otras capas reduciendo así el esfuerzo a invertir en la depuración y corrección de errores. La separación de componentes en capas incrementa la flexibilidad y escalabilidad posibilitando la reutilización de componentes y la ejecución de pruebas unitarias de software. Para fines de performance, la seguridad y accesibilidad de la aplicación Web es altamente valorada. Esto bien se logra distribuyendo la aplicación sobre niveles físicos (hardware) aplicando políticas de seguridad como cortafuegos para determinados componentes, liberando al resto por Internet. Así, la distribución de las capas en niveles físicos favorece al incremento de la tolerancia a fallos y rendimiento de la solución.

Por otro lado, como la interacción de un componente con otro ubicado en niveles inferiores requiere el pase obligatorio por el resto de capas intermedias, se produce una sobrecarga en el tiempo de respuesta en perjuicio de la performance. Este escenario podría evitarse bajo un enfoque relajado sacrificando propiedades como el aislamiento de capas. A su vez, este patrón para una aplicación con funcionalidades sencillas no resulta óptimo dado el nivel de complejidad incorporado. En similar situación, para aplicaciones dependientes de operaciones intensivas con bases de datos su adaptación no es viable.

33

3.1.4. Diseño de la arquitectura de la solución Para la implementación de esta solución se aplicará la arquitectura en N-Capas, debido a su diseño altamente escalable ante la incorporación de nuevos módulos y funcionalidades a futuro. Además posibilita la distribución de componentes (capas) entre varios niveles de hardware, obteniendo mayor seguridad y rendimiento ante numerosas peticiones al servidor Web. Esta arquitectura orientada a objetos no presenta obstáculos para adaptar tanto el patrón de modelo de dominio en la capa de lógica de negocio como el patrón de repositorio en la capa de acceso a datos, cumpliendo así con los lineamientos base de diseño indicados a comienzos del capítulo. La arquitectura queda dividida en cuatro capas descritas a continuación (ver figura 3.3):  Capa de Presentación: Esta capa integra los elementos de la interfaz gráfica y las clases con la lógica del comportamiento de las páginas para su interacción con el usuario. Involucra librerías CSS, JavaScript, Ajax, Flash, páginas maestras y ficheros ASPX y HTML además de contenido audiovisual. Esta capa actúa de forma similar a la Vista en el patrón MVC.  Capa de Aplicación: Esta capa tiene como función delegar las solicitudes de usuario provenientes de la capa previa hacia los módulos y clases correspondientes de la Capa de Lógica de Negocio, sin involucrar la implementación en líneas de código de dicha solicitud. Asimismo actúa como fachada para futuras implementaciones de integración con otros dispositivos, plataformas y sistemas a través de aplicaciones como servicios Web.  Capa de Lógica: Esta capa sigue la línea de trabajo de la entidad Modelo del patrón MVC. Conformada por clases cuyas funciones recaen en la implementación de la lógica de negocio atendiendo el requerimiento de usuario. Interactúa con la capa de base de datos de acuerdo con el tratamiento deseado de la información intercambiada. La codificación de la lógica de negocio sigue el patrón modelo de dominio. 34

 Capa de Acceso a Datos: En esta capa se ubicarán las clases DAO y librerías de conexión encargadas de administrar las operaciones CRUD (Create – Read – Update – Delete) y sentencias SQL a nivel de base de datos. La codificación de esta capa sigue el patrón repositorio.

Interfaz grafica (PEGA_PRES) Interfaz grafica (PEGA_PRES)

Interfaz grafica (PEGA_PRES)

Interfaz grafica (PEGA_PRES)

Interfaz grafica (PEGA_PRES) Interfaz grafica (PEGA_PRES)

Interfaz grafica (PEGA_PRES)

Figura 3.3 Diagrama de componentes de la arquitectura

35

Para el intercambio de información entre las capas tratadas, se hace uso de un conjunto de entidades de negocio (componente PEGA_ENTI), cuyas clases representan el escenario real del negocio. La arquitectura propuesta satisface los requerimientos no funcionales de diseño definidos en el capítulo anterior. La tabla 3.1 refleja cómo esta elección satisface los requerimientos de diseño

Tabla 3.1 Requerimientos de diseño vs. Solución arquitectónica Requerimiento no funcional

Solución propuesta

El sistema será desarrollado con una La

codificación

de

la

Capa

de

interfaz gráfica de usuario basada en Presentación no será controlada por la controles Web

Capa de Lógica, otorgando mayor libertad para incorporar los elementos gráficos y HTML adecuados.

El

sistema

cualquier

será

equipo

accesible de

desde La lógica de la Capa de presentación

trabajo

con residirá en el servidor de aplicaciones

navegadores Web Microsoft Internet Web y por el lado del cliente sólo Explorer (6.0 o superior) y Mozilla observará código HTML compatible con Firefox (2.0 o superior)

los navegadores Web. En caso se requiera ejecutar lógica por el lado del cliente las librerías AJAX de igual forma simplifican esta labor conservando la compatibilidad.

El sistema se ejecutará sobre un El sistema será albergado en el servidor servidor de aplicaciones Web con IIS Express de libre distribución sistema operativo Windows Server 2008 en adelante. El

sistema

administrador PostgreSQL

trabajará de

base

con de

el En la Capa de Acceso a Datos se datos ubicará el componente de conexión a la base de datos deseada, independiente del resto de la aplicación.

36

Entre los objetivos y restricciones aplicables a esta arquitectura destacan:  Validación de información: Para la validación de los datos de entrada y salida se contará con controles desarrollados bajo las librerías Ajax (ubicadas en la Capa de Presentación) y con las reglas impuestas en la Capa de Lógica.  Performance: Para fines de implantación la arquitectura es afín al establecimiento de diferentes niveles físicos (o de hardware) por capa mejorando el rendimiento. Respecto a los clientes navegadores Web, la arquitectura soporta la ejecución de múltiples transacciones desde otras conexiones en simultáneo.

Protección: La autenticación y validación de

acciones al usuario queda a cargo del módulo Seguridad en la Capa de Lógica.  Unicidad: La arquitectura en su Capa de acceso a datos permite la interacción con una base de datos a la vez, canalizando todas las operaciones de lectura y escritura hacia ésta.

3.1.5. Vista Lógica La figura 3.4 representa la vista lógica del software con las cuatro capas descritas, así como los principales componentes encargados de su funcionamiento.

37

Figura 3.4 vista lógica del sistema 3.1.6. Vista de Despliegue A continuación la figura 3.5 grafica la representación de las relaciones entre los nodos físicos y su localización junto con los componentes en hardware y software.

38

Figura .5 diagrama de despliegue

Los nodos indicados en la figura se describen a continuación  Estación cliente: Este nodo representa al navegador Web de la máquina cliente, desde el cual se realiza la conexión al sistema  Servidor Web y de Aplicación: En este nodo residen los archivos del código fuente con la lógica de negocio estructurada en capas.  Servidor de Base de datos: Este nodo contiene el sistema administrador de base de datos. Interactúa con el nodo de servidor Web en su capa de acceso a datos (DAO).

3.1.7. Diagrama de clases de diseño Se muestran a continuación los diagramas de clases de diseño de los módulos Organización, Planeamiento y Evaluaciones. En primer lugar las clases de diseño representan a las entidades de negocio identificadas en la etapa de análisis, con sus atributos y tipos de datos utilizados. En segundo lugar representan a las clases cuyos métodos más importantes tienen a cargo la implementación de la lógica de negocio así como las operaciones de lectura y escritura con la base de datos. Una 39

última clase llamada MasterDAO implementará la conexión entre la base de datos con el modelo de dominio empleado para la persistencia.

Figura 3.6 Diagrama de clases de diseño - Módulo Organización

40

Figura 3.7 Diagrama de clases de diseño - Módulo Planeamiento

41

Figura 3.8 Diagrama de clases de diseño - Módulo Evaluaciones

La explicación del diagrama de clases de diseño se profundiza el Anexo H: Documento de diseño del sistema.

42

3.1.8. Diagrama de base de datos Se presenta a continuación en la figura 3.9 las principales tablas del diagrama de base de datos para las operaciones del sistema.

3.1.8. Diagramas de secuencia

Figura 3.9 Diagrama de base de datos del sistema

3.1.8. Diagramas de secuencia Se presentan a continuación tres diagramas de secuencia correspondientes a los procesos de creación de usuarios, asignación de objetivos a una actividad y toma de asistencia. El propósito es representar gráficamente la interacción entre las capas del software conforme con las acciones del usuario. La relación completa de diagramas se ubica en el Anexo H: Documento de diseño del sistema.

Como muestra el diagrama de secuencia de la figura 3.10 el inicio de la acción ocurre en el formulario de búsqueda de usuarios. El administrador tras seleccionar 43

la creación de un nuevo usuario se dirige a otro formulario y completa la información requerida. De acuerdo con el tipo de usuario (usuario externo o especialista) se crean las instancias de dichas entidades desde la clase Seguridad_LogTyp1 (miembro de la Capa de Lógica) asignando dichas entidades al nuevo usuario. Procede a continuación la asignación de un perfil de seguridad y por último la invocación al método de registro de la clase DAOUsuario (miembro de la Capa de Acceso a Datos). La conclusión satisfactoria o errónea del proceso es transmitida hacia la Capa de Aplicación y Presentación respectivamente, mediante un mensaje junto con el código de usuario.

3.2. Diseño de Interfaz Gráfica En esta sección se exponen los criterios para el diseño de la interfaz gráfica para la implementación de la Capa de Presentación. Posteriormente se describen las restricciones asumidas en el diseño gráfico Web.

3.2.1. Estándar de Interfaz Gráfica Todas las páginas del sistema (con excepción de la interfaz de inicio de sesión) seguirán el patrón gráfico mostrado en la figura 3.13.

Figura 3.13 Patrón de diseño gráfico del sistema

44

 Título de la ventana: El título de la ventana en todo momento albergará los nombres de la institución educativa y del producto.  Encabezado de página: Incorpora el logotipo característico del centro educativo en la parte superior izquierda de la pantalla, sobre la barra lateral de menú.  Nombre de usuario: Durante la sesión activa se mostrará el nombre completo del usuario en la parte superior derecha. Se hará uso de la fuente Arial en doce (12) puntos.  Título de página: Como título de la página en ejecución se visualizará la ruta de acceso seguida por el usuario. Se hará uso de la fuente Arial en catorce (14) puntos.  Fecha de sesión: Ubicada en el extremo izquierdo del título de página se mostrará la fecha del día. La fuente utilizada será Arial en diez (10) puntos.  Barra de botones: Al acceder a cada ítem del menú desplegable se dispone de esta barra para enlazar con otras funcionalidades del módulo (por ejemplo, durante los mantenimientos de las principales entidades).  Barra de menú: La barra de menú desplegable tendrá como ubicación el sector intermedio izquierdo de la pantalla y usará la fuente Arial en once (11) puntos.  Iconos de desconexión: En la parte inferior del menú se ubicará el botón de cierre de sesión de usuario.  Barras de desplazamiento: Para el traslado horizontal y vertical se contará con barras de desplazamiento a lo largo de la página.

45

 Hojas de estilos en cascada (CSS): El manejo de las propiedades de fuente en cajas de textos y etiquetas (tipo de fuente, tamaño y color) recaerá en estos ficheros.

A continuación se muestran los prototipos de las pantallas de inicio de sesión (figura 3.14), búsqueda (figura 3.15) y mantenimiento (figura 3.16) sujetas al patrón de diseño Web descrito.

Figura 3.14 Pantalla de Ingreso al Sistema

Figura 3.15 Pantalla de Búsqueda de Documentos

46

Figura 3.16 Pantalla de Mantenimiento de Programas

47

4. CAPÍTULO 4:

CONSTRUCCIÓN

El presente capítulo tiene como objetivo principal presentar las tecnologías seleccionadas para la implementación de este sistema. La cual tenemos definidos las estrategias, mecánicas y políticas de prueba para su buen funcionamiento. 4.1.

Construcción

En este bloque se hace un resumen de las características de las principales tecnologías, motores y frameworks o estaciones de trabajo empleados en la implementación como el lenguaje de programación, librerías, motor de base de datos entre otros componentes principales que se van a utilizar para el buen funcionamiento de sistema. 4.1.1. Lenguaje de programación Dentro de nuestro desarrollo del sistema inteligentita del centro de salud, CAMI Cuido, Huehuetenango, para que se desarrollo bien necesitamos el uso de una variedad de lenguajes de programación, desde programación de escritorio y su vinculación en la web. Tal razón utilizaremos. 4.1.1.1.

Java Script

Este lenguaje de programación es muy fácil de aprender y te sirve prácticamente

para

todo.

Puedes

desarrollar

aplicaciones

web,

servidores, aplicaciones de escritorio y hasta incluso aplicaciones móviles. 4.1.1.2.

Python

Este lenguaje de programación nos permite programar o desarrollar aplicaciones web, servidores, aplicaciones de escritorio y hasta incluso aplicaciones móviles. Python es el lenguaje más solicitado actualmente. Esto significa que muchas empresas ya han descubierto el potencial del lenguaje y están comenzando a contratar desarrolladores de Python activamente. Dominar Python definitivamente es una buena inversión para tu carrera profesional, este lenguaje no se irá a ninguna parte. 48

4.1.1.3.

Java

Este lenguaje creado por James Gosling de Sun Microsystems de Oracle actualmente ya tiene mucho tiempo en el mercado y aun así se sigue utilizando de manera muy amplia en esta industria. Muchos sistemas se han creado y mantenido con Java y es por eso por lo que existe mucha demanda de desarrolladores Java. Es por eso por lo que existe mucha experiencia y documentación en este lenguaje gracias a su largo trayecto. Java ha sabido evolucionar de la manera adecuada y seguirá siendo un lenguaje con mucha presencia en este mundo tecnológico. Aprender este lenguaje de programación quizás no sea tan fácil como Python o JavaScript debido a su paradigma un poco estricto. Pero dominar este lenguaje te traerá muchos beneficios en tu carrera profesional.

4.1.2. Arquitectura utilizada Desde el punto de vista funcional, se puede definir la computación Cliente/Servidor como una arquitectura distribuida que permite a los usuarios finales obtener acceso a la información en forma transparente aún en entornos multiplataforma. En el modelo cliente servidor, el cliente envía un mensaje solicitando un determinado servicio a un servidor (hace una petición), y este envía uno o varios mensajes con la respuesta (provee el servicio). En un sistema distribuido cada máquina puede cumplir el rol de servidor para algunas tareas y el rol de cliente para otras. FALTA 4.1.3, 4.1.4 y 4.1.5 joel 4.1.6. Otras herramientas y librerías Las herramientas a utilizar La librería Npgsql (Postgresql 2007) es un proveedor (driver) de datos para aplicaciones .NET conectadas a una base de datos en PostgreSQL desarrollado en el lenguaje C# y compatible con la versión 7.X en adelante de dicho motor de base de datos. Asimismo soporta operaciones de persistencia de datos con ADO.NET Entity Framework. Como 49

apoyo a las labores de pruebas de integración y además para establecer un registro global de errores de la aplicación una vez implantada en los centros 88 educativos, se incorporó la librería ELMAH (Google 2009) con la finalidad de conservar por base de datos la relación de errores y excepciones producidos durante las sesiones de los usuarios desde diversos clientes. Por medio de una configuración al archivo WEB.CONFIG de la solución desarrollada bajo ASP.NET, efectúa el envío automático de correos electrónicos (o por notificaciones vía RSS) al administrador sobre las incidencias producidas, con información relativa a la ubicación, fecha, hora y detalle de la excepción producida. 4.2. Pruebas Primero se procederá con la primera prueba que consistirá en ver que tan rápido nos responde el programa a la hora de entrar en el mismo, verificar las transiciones de una ventana a otra, también verificaremos la eficiencia a la hora de la introducción de registros reales.

4.2.1. Estrategia de Pruebas El objetivo primordial de la estrategia de pruebas es demostrar en su totalidad el funcionamiento del software a nivel de eficiencia y eficacia del código y funcionalidad. Es decir, verificar la interacción e integración de los componentes y validar la implementación de todos los requerimientos del producto. 4.2.2. Tipos de Pruebas 4.2.2.1.

Pruebas Unitarias

Estas pruebas de software se dirigen a componentes menores como los módulos de un sistema, probando los caminos de control importantes con el fin de descubrir errores dentro de esta instancia (Dávila 2005). Es así como el equipo logrará identificar los defectos en fases tempranas de codificación sin esperar la realización de pruebas integrales. Las técnicas consideradas son: 50



Pruebas de Caja Blanca: Examinan la estructura de un código fuente según la lógica implementada evaluando la ejecución correcta a nivel de sentencia, estructuras selectivas e iterativas (Dávila 2005). No obstante, este ámbito queda cubierto dentro del marco de pruebas de código a realizarse durante la codificación del producto adoptada como práctica ágil.



Pruebas de Caja Negra: Estas pruebas se realizan sobre las interfaces

gráficas

buscando

comprobar

la

funcionalidad,

comportamiento en la entrada y salida de datos, así como la integridad de la información enviada y recibida.

4.2.2.2.

Pruebas de Integración

Bajo estas pruebas todos los módulos revisados e integrados en diferentes secuencias de procesos y llamadas, son evaluados con el propósito de comprobar la ejecución correcta conforme al proceso de negocio esperado. Un factor clave es la capacidad de identificación de todos los esquemas de llamadas para una buena cobertura de casos de prueba integral. Las pruebas integrales se clasifican en: No incremental: Requiere tener todos los módulos del producto software culminados para así concretar en su conjunto estas pruebas. Incremental: Cada módulo es acoplado a los componentes existentes, así las pruebas futuras no afectarán los avances y correcciones de fases anteriores, en la búsqueda de un software robusto desde el inicio de las pruebas.

51

4.2.3. Catálogo de pruebas Módulo

ID Test

Tipo

Evaluación

EVA-TST-001

Integral

Evaluación

EVA-TST-002

Unitaria

Evaluación

EVA-TST-003

Integral

Planeamiento PLA-TST-043

Unitaria

Planeamiento PLA -TST-063

Unitaria

Seguridad

SEG-TST-012

Unitaria

Seguridad

SEG-TST-013

Unitaria

Seguridad

SEG-TST-014

Unitaria

Descripción Verificar si para la evaluación del programa se despliegan las tareas asociadas Verificar si el sistema no realiza la búsqueda de 92 evaluaciones en caso no se ingrese un código de especialista válido. Verificar si la búsqueda de evaluaciones a especialistas muestra una a más coincidencias o un aviso de error en caso contrario. Verifica si el sistema permite el mantenimiento de un evento en caso ingrese todos los campos obligatorios correctamente (programa, actividad, asunto, detalle). Verifica si aparece la confirmación de la operación de mantenimiento en caso el usuario haya ingresado los valores apropiados y haya insertado dos tareas al plan. Verificar si el usuario no ingrese al sistema utilizando código y contraseña en blanco. Verificar si la contraseña ingresada cumple con las restricciones en cuanto a longitud y contenido. Verificar si el usuario ha modificado correctamente su contraseña.

4.2.4. Reporte de ejecución de pruebas Tras haber puesto en marcha las pruebas unitarias y de integración según el Tipo de Pruebas se presentan en esta sección los resultados obtenidos. En líneas globales se obtuvo un porcentaje mayor al 93% de efectividad: bajo la prueba de Integración contribuye a las prácticas de prueba en desarrollo y documentación fue la que más contribuyó al logro de este resultado. En el desarrollo de pruebas unitarias se obtuvo un porcentaje de éxito del 95.25% como consecuencia de las prácticas de pruebas en paralelo a la programación de los módulos. Para el cumplimiento total de este paquete de 52

pruebas se recurrió a continuas iteraciones para subsanar las falencias ocurridas.

5. CAPITULO 5: Observaciones, conclusiones y recomendaciones:

En este capitulo final está comprendido de las observaciones previamente identificadas y asimiladas aunado a ello las conclusiones y recomendaciones que son pequeñas descripciones de las experiencias que se obtuvieron durante la elaboración del proyecto. 5.1. Observaciones La realización de este proyecto nació de ver la necesidad que existe en los centros de salud denominados CAIMI tanto en personal como en atención a los ciudadanos, ya que hay muchas deficiencias en dicho proceso, se hace esperar demasiado a los pacientes y no se les brinda la importancia necesaria. En la fase del análisis de la problemática se descubrió que todo esto sucede a que dichas entidades no cuentan con un sistema que se encargue de la recopilación de información, tanto de los pacientes como del personal encargado de brindar los servicios con los que debería contar este tipo de instituciones. Otra de las situaciones que surgieron durante esta etapa fue que los vehículos que son utilizados para el traslado de los pacientes se deterioran muy rápido, debido a que los pilotos encargados de la conducción de dichos vehículos no tienen el cuidado suficiente ni la responsabilidad para usarlos de la manera correcta, para lo cual el sistema permitirá ingresar los datos de todos los vehículos aunado a esto el piloto deberá justificar cada ves que el vehículo sea utilizado.

53

5.2. Conclusiones 

Con la elaboración de este proyecto se consiguió la implementación automatizar el control de información de pacientes, vehículos, enfermeras, médicos.



Deberá capacitar a algunos de los empleados para que aprendan a utilizar el sistema ya que muchos de ellos carecen de la habilidad de utilizar una computadora.



El diseño de la interfaz gráfica es fácil e intuitiva de usar para que cualquier usuario sin importar sus habilidades para la computación.



Con esta aplicación, se comprueba que el automatizar los procesos aumenta la efectividad sobre los procesos que se realizan en este tipo de aplicaciones.

5.3. Recomendaciones y Políticas de Actualización 

Se recomienda a cualquier CAIMI que desee implementar este proyecto en su organización que realice capacitaciones periódicas a su personal para aumentar la efectividad del software.



El software no necesitará mayor actualización solo en caso la institución quiera implementar un nuevo modulo o añadir alguna funcionalidad con la que no cuente la aplicación.



Se recomienda a las instituciones que utilicen esta aplicación que tengan una copia de seguridad de todos los archivos importantes, en caso de que alguna computadora se arruine.

54

5.4. Anexo: Fotografías del Grupo

55

Bibliografía



Párrafo obtenido de Definición ABC, Fecha: octubre. 2012, URL: https://www.definicionabc.com/general/implementar.php



Párrafo obtenido de significados.com, Actualizado: 30/01/2019, Url: https://www.significados.com/sistema/



Párrafo obtenido de Definición de Publicado: 2008. Actualizado: 2012, Url: https://definicion.de/inteligencia/



Párrafo obtenido de Significados.com, actualizado: 21/02/2017, Url: https://www.significados.com/control/



Párrafos obtenidos de Significados.com, actualizado: 16/02/2017, Url: https://www.significados.com/informacion/

56

Glosario



Antisistema: Que se opone al sistema político o económico establecido.



Conceptualizar: Formar concepto o idea de algo u organizar en conceptos.



Desfases: Falta de correspondencia o ajuste entre una persona o cosa y otra.



Eficacia: Capacidad para producir el efecto deseado o de ir bien para determinada cosa.



Eficiencia: Capacidad para realizar o cumplir adecuadamente una función.



Etimología: Origen o procedencia de las palabras, que explica su significado y su forma.



Flexibilizar: Hacer que cierta cosa sea flexible o más flexible.



Imprescindible: Que es o se considera tan necesario que no se puede prescindir de él o no se puede dejar de tener en consideración.



Malicioso: Que habla o actúa con intención encubierta para beneficiarse en algo o perjudicar a alguien.

57