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––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: , 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 ., 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