CAPÍTULO 3

DISEÑO Y DESARROLLO

3.1 Diseño

Los Sistemas de información Gerencial se basan en la administración de los

procesos a partir de otros sistemas o subsistemas. En el caso de los requerimientos

solicitados por el hospital, éste se basó en un primer módulo central llamado

“Osteosíntesis”, como también la configuración y ABC (altas, bajas y consultas) de la

información requerida.

Todo esto fue traducido a una interfaz apoyada con las tecnologías de HTML5

y CSS3.

Gracias a ello se ha podido llevar un diseño responsivo, donde éste se puede ver a

través de cualquier dispositivo que tenga instalado un navegador web y el sistema

“responderá” a la gran variedad de tamaños de pantallas y/o monitores acomodando

cada elemento HTML automáticamente para su visualización correcta. Así el

personal del hospital podrá utilizar el sistema a través de dispositivos móviles como

smartphones y/o tablets sin la necesidad de estar en una computadora. Esto fue

logrado por el uso de las famosas “media queries” de CSS3.

Los colores y la visualización de los elementos están inspirados en la

apariencia que caracteriza al IMSS, como son el color verde institucional y su

logotipo.

Imagen 20. Logotipo de SIGUMAE en modo horizontal

41

Imagen 21. Logotipo de SIGUMAE en modo vertical

3.1.1 Inicio de sesión

Como todo sistema debe de requerir, éste cuenta con el proceso de inicio de sesión

por parte de los empleados del Hospital. Tiene a su vez, la opción de recuperación

de contraseña en caso de olvido.

Imagen 22. Interfaz de inicio de sesión

42

Imagen 23. Interfaz de inicio de sesión en diseño responsivo

3.1.2 Recuperación de contraseña

Ésta interfaz está conformada por un pequeño formulario que el usuario debe de

completar.

Imagen 24. Interfaz de recuperación de contraseña

43

Imagen 25. Interfaz de recuperación de contraseña en diseño responsivo

3.1.3 Alertas

Es de suma importancia para el usuario el conocimiento de la interacción con

el sistema, es por ello la relevancia de uso de alertas; éstas se usarán para que el

usuario sepa que su acción fue tomada y que el sistema haya dado una respuesta,

no importa si fuera exitosa o no.

Imagen 26. Alerta

44

3.1.4 Dashboard

El dashboard es la parte principal del sistema. Cuando el usuario haya iniciado

sesión éste se redirige hacia aquí. Está compuesto por el menú, el nombre del

usuario, como también opciones para cerrar sesión y visitar su perfil.

Imagen 27. Dashboard

45

3.1.5 Menú

Cada elemento del menú tiene submenús de acuerdo con los requerimientos

solicitados por el hospital.

Imagen 28. Submenús del menú Almacén de Osteosíntesis

Imagen 29. Submenús del menú C.E.Y.E.

46

Imagen 30. Submenús del menú Hospitalización

Imagen 31. Submenús del menú Quirófano

47

3.1.6 Interfaces por submódulo

Cada interfaz de los submódulos como hospitalización, quirófano, etc. está

contemplada por los mismos elementos de ABC, donde la muestra de la información

se hace a través de una tabla y el registro como la edición por medio de formularios.

Imagen 32. Interfaz de gestión de cirugías

Imagen 33. Interfaz de programación de cirugías

48

3.1.7 Modales

Un modal en el desarrollo web es una ventana emergente que puede mostrar

tanto una gran cantidad de datos por medio de tablas como simples preguntas hacia

los usuarios ya que el sistema ocupa que decida alguna acción y/o requiera que

introduzca algún tipo de información.

A diferencia de otros métodos, éstos nos dan enormes ventajas ya que se

muestra en la misma página y no es necesario recargar el navegador.

Así la interfaz es más amigable con el usuario, conoce cuál es la información

que se requiere y existe una interacción entre usuario y sistema.

Imagen 34. Modal con los detalles de los sistemas de materiales de osteosíntesis

Imagen 35. Modal donde el sistema requiere una decisión por parte del usuario

49

Imagen 36. Modal donde el sistema requiere información por parte del usuario

3.1.8 Notificaciones

Dentro de los requerimientos del hospital es notificar a los empleados de cada

acción que lleva a cabo con el fin de mantenerlos informados y además sepan si es

necesario que realicen una acción.

Éste requerimiento se implementó en el sistema a través de una notificación y

una página que muestre la lista de todos los mensajes recibidos. Cabe destacar que

todo fue optimizado para que fuera responsivo, ya que en estas situaciones es

posible que los empleados requieran ser informados en casos donde no estén al

alcance de una computadora y éste pueda visualizarlo a través de un dispositivo

móvil.

Imagen 37. El usuario ha recibido una notificación

50

Imagen 38. Lista de las notificaciones recibidas

Imagen 38. Lista de las notificaciones recibidas en diseño responsivo

51

3.2 Desarrollo

Una vez obtenido las interfaces de cada módulo y submódulos se dio paso al

desarrollo.

En otras palabras, en el desarrollo web, es el llamado “back end”. Aquí es

donde aprovechamos las herramientas como el framework CodeIgniter, MySQL y

jQuery.

La metodología usada fue HMVC (Hierarchical model–view–controller) gracias

una librería de PHP implementada en CodeIgniter, obteniendo un resultado como en

la siguiente imagen.

Imagen 39. HMVC aplicado en SIGUMAE

52

3.2.1 Base de datos (MySQL)

Sin duda alguna para cualquier sistema de administración es indispensable el uso de

una base de datos. Aquí es donde se guardará toda la información generada y donde

podremos acceder a ella, obteniendo así un respaldo.

MySQL es una buena opción para los sistemas gerenciales ya que usa base

de datos relaciones y además es software libre.

Para la administración directa de la base de dato existe muchas alternativas como:

SQLyog, phpMyAdmin, SQL Buddy, Adminer, entre otros muchos otros.

Como otra ventaja, el servidor local “XAMPP” viene incluido phpMyAdmin, por

lo cual se decidió usar ese.

Imagen 40. phpMyAdmin

53

3.2.2 MYSQLi

Una vez establecida la base de datos es necesario que PHP se conecte a ella para

dar provecho de todas sus funcionalidades.

En PHP existen diferentes formas de lograr eso, entre las más populares son:

mysql, mysqli y PDO. CodeIgniter, como framework es robusto y soportan cada una

ellas. Como se busca un sistema que dé un buen rendimiento se eligió mysqli.

La extensión mysqli, o como a veces se le conoce, la extensión de MySQL

mejorada, se desarrolló para aprovechar las nuevas funcionalidades encontradas en

los sistemas MySQL con versión 4.1.3 o posterior. La extensión mysqli viene incluida

en las versiones PHP 5 y posteriores [18].

La extensión mysqli contiene numerosos beneficios, siendo estas las mejoras

principales respecto a la extensión mysql:

- Interfaz orientada a objetos

- Soporte para Declaraciones Preparadas

- Soporte para Múltiples Declaraciones

- Soporte para Transacciones

- Mejoradas las opciones de depuración

- Soporte para servidor empotrado

Imagen 41. CodeIgniter configurado para que haga uso de mysqli

54

3.2.3 jQuery y AJAX

Una vez obtenido la manera de conectarse a la base de datos, solo hace falta la

forma de hacer peticiones al servidor para que cargue la página con la información

requerida.

Existen diferentes formas de hacer eso, unas de las grandes ventajas de PHP

es que facilita esta tarea ya que puede incrustar datos en los elementos de HTML en

archivos .php, la desventaja de esto es que el usuario necesita recargar la página

para actualizar la información mostrada.

La solución a esto es el uso de AJAX (acrónimo de Asynchronous JavaScript And

XML) pero ¿Qué es?

Es una técnica de desarrollo web para crear aplicaciones interactivas. Estas

aplicaciones se ejecutan en el cliente, es decir, en el navegador de los usuarios

mientras se mantiene la comunicación asíncrona con el servidor en segundo plano.

Con Ajax, se hace posible realizar peticiones al servidor y obtener respuesta

de este en segundo plano (sin necesidad de recargar la página web completa) y usar

esos datos para, a través de JavaScript, modificar los contenidos de la página

creando efectos dinámicos y rápidos [19].

3.2.3.1 Ventajas y desventajas de Ajax

Ventajas

- No es necesario recargar y redibujar la página web completa, con lo que todo

es más rápido.

- El usuario no percibe que haya demoras: está trabajando y al ser las

comunicaciones en segundo plano no hay interrupciones.

- Los pasos que antes podía ser necesario dar cargando varias páginas web

pueden quedar condensados en una sola página que va cambiando gracias a

55

Ajax y a la información recibida del servidor.

Desventajas

- Las páginas creadas dinámicamente mediante peticiones sucesivas AJAX, no

son registradas de forma automática en el historial del navegador, así que

haciendo clic en el botón de "volver" del navegador, el usuario no será

devuelto a un estado anterior de la página, en cambio puede volver a la última

página que visitó. Soluciones incluyen el uso de IFrames invisible para

desencadenar cambios en el historial del navegador y el cambio de la porción

de anclaje de la dirección (después de un #).

- Los motores de búsqueda no analizan JavaScript. La información en la página

dinámica no se almacena en los registros del buscador. Exceptuando Google,

que desde el 2011 sí indexa contenido Ajax y JavaScript. Matt Cutts (director

del departamento contra el spam en web de Google) lo confirmó en Twitter:

“Googlebot keeps getting smarter. Now has the ability to execute AJAX/JS to

index some dynamic comments.”

- Hay problemas usando Ajax entre nombres de dominios, a esto se le conoce

como Same Origin Policy o Política del Mismo Origen, lo cual es una medida

de seguridad que puede ser solucionada con Cross-Origin Resource Sharing

(CORS).

- Dependiendo de cómo se desarrolle el sitio web, puedes mejorar o empeorar

la carga en el servidor. Ajax puede ayudar al servidor a evitar la fase de

renderización de HTML, dejándole ese trabajo al cliente, pero también puede

sobrecargar al servidor si se hace varias llamadas a Ajax.

- Es posible que páginas con Ajax no puedan funcionar en teléfonos móviles,

PDA u otros aparatos. Ajax no es compatible con todo el software para

invidentes u otras discapacidades.

Gracias a la librería jQuery todo este proceso puede ser simplificado a unas

cuantas líneas de código enviando solo un objeto de JavaScript con la configuración

deseada.

56

Imagen 42. Esquema de AJAX

Imagen 43. Parte de código JS donde hace uso de $.ajax

57

3.2.4 Seguridad

Como sistema de gran importancia no se puede dejar de lado de seguridad. Además

de métodos utilizados como el uso de usuarios, contraseñas encriptadas, poner

límites de intentos para iniciar sesión existen otros métodos para proveer de mayor

seguridad de un nivel más avanzado.

Una vez más se ha aprovechado la ventaja de usar frameworks de PHP, ya

que nos aportan herramientas para aumentar la seguridad de cual sistema y/o página

web.

CodeIgniter tiene a su disposición metodologías para mitigar los más famosos

y usados ataques web. Éstos son: Inyección SQL, Cross-site scripting y Cross Site

Request Forgery.

3.2.4.1 Inyección SQL

Un ataque de inyección SQL consiste en la inserción o “inyección” de una consulta

SQL a través de los datos de entrada del cliente de la aplicación. Una inyección SQL

éxito exploit puede leer los datos sensibles de la base de datos, modificar datos de

bases de datos (Insertar / Actualizar / Eliminar), ejecutar operaciones de

administración en la base de datos, recuperar el contenido de un archivo

determinado presente en el sistema de archivos DBMS y en algunos casos emitir

comandos al sistema operativo. Ataques de inyección SQL son un tipo de ataque de

inyección, en el que comandos SQL se inyectan en la entrada de datos de plano a fin

de efectuar la ejecución de comandos predefinidos SQL [20].

En la configuración de la base de datos de CodeIgniter hay una opción que

nos permite hacer “scaping”, que es limpiar cada consulta de MySQL y así evitar

dichos ataques.

58

Esta configuración se ejecuta de manera automática dando una mayor

seguridad al sistema.

Imagen 44. La opción “save_queries” nos permite hacer scaping

3.2.4.2 Cross-site scripting (XSS)

XSS es un ataque de inyección de código malicioso para su posterior ejecución que

puede realizarse a sitios web, aplicaciones locales e incluso al propio navegador.

Sucede cuando un usuario mal intencionado envía código malicioso a la aplicación

web y se coloca en forma de un hipervínculo para conducir al usuario a otro sitio

web, mensajería instantánea o un correo electrónico. Así mismo, puede provocar una

negación de servicio [21].

Una vez más CodeIgniter nos ofrece herramientas para mitigar este tipo de

ataques con métodos como xss_clean() pero al ser más complejo y más usado se

optó por usar una librería PHP llamada HTML Purifier totalmente compatible con el

framework.

Esta librería permite eliminar código malicioso (XSS) y validar las etiquetas

HTML que queramos definir como permitidas. También valida el código HTML con el

estándar que nosotros deseemos y realiza las modificaciones necesarias para

"purificarlo".

59

HTML Purifier es gratuito y de código libre. Se trata además de un sistema

altamente personalizable que puede abarcar varios tipos de usos dentro de un sitio

web. Se utiliza generalmente para validar los campos que se reciben desde editores

WYSIWYG o simplemente para validar el código que se muestra en una página web

[22].

60

3.2.4.3 Cross Site Request Forgery

La técnica llamada falsificación de petición en sitios cruzados, proviene de su

nombre en inglés Cross Site Request Forgery (CSRF o XSRF). Este ataque fuerza al

navegador web de su víctima, validado en algún servicio (como por ejemplo correo o

home banking) a enviar una petición a una aplicación web vulnerable.

Esta aplicación se encarga de realizar la acción elegida a través de la víctima,

debido que la actividad maliciosa será procesada en nombre del usuario logueado. Al

contrario de los ataques conocidos como Cross Site Scripting (su traducción sería

ordenes en sitios cruzados – XSS) los cuales explotan la confianza del usuario para

con un sitio particular; el Cross Site Request Forgery explota la confianza que un sitio

web tiene en un usuario particular [23].

CodeIgniter nos ofrece otra serie de herramientas para prevenir este tipo de

ataques con unas sencillas configuraciones.

Imagen 45. CodeIgniter configurado para la protección de CSRF o XSRF

61

Con todo ello se obtiene un sistema altamente protegido por los tipos ataques más

comunes en páginas web.

Imagen 46. Porcentaje de tipo de ataques web

Obteniendo este conjunto de herramientas y configuraciones solo hace falta

desarrollar la lógica de todos los procesos que requiere el hospital.

62