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 No. de Carné

FRANCISCO JAVIER LÓPEZ MÉNDEZ 0904-16-4016
VENANCIO CRUZ MATEO BALTAZAR 0904-16-6103
PAULO LEONARDO ALVARADO GRANADOS 0904-16-17105
JESUS MARIANO MENDEZ NOLASCO 0904-16-3956
JONATHAN JOEL CARDONA CHAVEZ 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
1.1.1. Metodología y Procedimiento ............................................................................. 5
1.1.1.1. Grupo del Proceso de Iniciación .................................................................... 5
1.1.2. Riesgos de Proyecto. ............................................................................................ 7
1.1.3. Plan de Respuesta ante riesgos. ........................................................................ 8
1.4. Descripción y sustentación de la solución. .......................................................... 10
2. CAPÍTULO 2: ANÁLISIS .......................................................................... 12
2.1. 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
2.2. Requerimientos funcionales ................................................................................. 17
2.2.1. Consideraciones sobre el sistema .................................................................. 23
2.3. Análisis de la solución ................................................................................................ 24
2.3.1. 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
3. 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: CONSTRUCCIÓN .................................................................... 48
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. 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
5. 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/administracion-
de-proyectos/las-3-metodologias-para-la-gestion-de-proyectos-que-mas-
se-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. Descripción Tipo Dif. Pri.
1 El sistema posibilitará las consultas y reportes de los Funcional 3 2
pacientes, los empleados, y toda la información
necesaria del CAIMI del municipio de CUILCO,
departamento de Huehuetenango.

17
2 El sistema permitirá el mantenimiento de los Funcional 2 2
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 1 1
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 3 3
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. Descripción Tipo Dif. Pri.
1 El sistema permitirá el envío y recepción de Funcional 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 1 1
CAIMI, ver los reportes y asistencias de pacientes
en el centro de salud.
3 El sistema permitirá a los pacientes imprimir o Funcional 2 1
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. Descripción Tipo Dif. Pri.
1 El sistema permitirá registrar y actualizar información Funcional 3 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 2 1
o asistencias en el CAIMI.

3 El sistema permitirá registrar y actualizar el Funcional 2 1

control de citas al centro de atención.
4 El sistema permitirá registrar y actualizar el control Funcional 2 1
de citas a emergencias de los pacientes.

19
 MÓDULO ORGANIZACIÓN
No. Descripción Tipo Dif. Pri.
1 El sistema permitirá el mantenimiento de la Funcional 3 2
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 2 1
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 1 1
actividades clasificadas por citas o el tipo de visita
que se esta realizando.
4 El sistema permitirá el mantenimiento de citas Funcional 1 1
asignadas por día.
5 El sistema permitirá el mantenimiento de Funcional 3 2
indicadores de evaluación. Los indicadores
cuantificarán el avance de un objetivo.
6 El sistema permitirá el mantenimiento de objetivos. Funcional 3 2
Los objetivos consisten en logros puntuales
esperados en los pacientes se atendido bien.
7 El sistema permitirá asociar actividades por Funcional 2 1
cada cita, examen, o gestión médica.
8 El sistema posibilitará la asignación de citas o Funcional 2 1
exámenes a los especiales en el área.

20
 MÓDULO PLANEAMIENTO
No. Descripción Tipo Dif. Pri.
1 El sistema permitirá el mantenimiento de toda la Funcional 1 1
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 2 1
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 1 1
tarda el paciente en el CAIMI.
4 El sistema permitirá el mantenimiento de eventos y Funcional 3 1
observaciones ocurridas durante la ejecución del
programa de salud, por cada paciente.
5 El sistema posibilitará el mantenimiento de recetas. Funcional 2 2
Los documentos no deberán superar los 8MB para
su carga y descarga.

21
 MÓDULO EVALUACIONES
No. Descripción Tipo Dif. Pri.
1 El sistema posibilitará la evaluación de los Funcional 2 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 2 1
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 2 3
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 3 1
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. Descripción Tipo Dif. Pri.
1 El sistema emitirá reportes de citas y asistencias Funcional 2 3
de pacientes.
2 El sistema generará el informe de avances y progresos Funcional 1 1
las citas y asistencias de pacientes.

3 El sistema generará el reporte de todas las citas, el Funcional 2 3

porque la asistencia del paciente en el CAIMI.
4 La emisión de reportes tendrá como formato único Funcional 2 3
en PDF (Portable Document Format).

22
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 Interfaz grafica

(PEGA_PRES) (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 será accesible desde La lógica de la Capa de presentación
cualquier equipo de 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 trabajará con el En la Capa de Acceso a Datos se
administrador de base de datos ubicará el componente de conexión a la
PostgreSQL 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 Descripción
Evaluación EVA-TST-001 Integral Verificar si para la evaluación del
programa se despliegan las tareas
asociadas
Evaluación EVA-TST-002 Unitaria Verificar si el sistema no realiza la
búsqueda de 92 evaluaciones en caso no
se ingrese un código de especialista
válido.
Evaluación EVA-TST-003 Integral Verificar si la búsqueda de evaluaciones a
especialistas muestra una a más
coincidencias o un aviso de error en caso
contrario.

Planeamiento PLA-TST-043 Unitaria Verifica si el sistema permite el

mantenimiento de un evento en caso
ingrese todos los campos obligatorios
correctamente (programa, actividad,
asunto, detalle).
Planeamiento PLA -TST-063 Unitaria 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.
Seguridad SEG-TST-012 Unitaria Verificar si el usuario no ingrese al sistema
utilizando código y contraseña en blanco.
Seguridad SEG-TST-013 Unitaria Verificar si la contraseña ingresada
cumple con las restricciones en cuanto a
longitud y contenido.
Seguridad SEG-TST-014 Unitaria 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