desarrollo del mÓdulo de parametrizaciÓn del … · contexto y que son almacenados de manera...

DESARROLLO DEL MÓDULO DE PARAMETRIZACIÓN DEL SISTEMA SIIS (SISTEMA INTEGRAL DE INFORMACIÓN EN SALUD) DE LA EMPRESA

IPSOFT S.A.

JHONNY RIVERA PIZARRO

2127022

UNIVERSIDAD AUTÓNOMA DE OCCIDENTE FACULTAD DE INGENIERÍA

DEPARTAMENTO DE OPERACIONES Y SISTEMAS PROGRAMA DE INGENIERÍA INFORMÁTICA

SANTIAGO DE CALI 2017

DESARROLLO DEL MÓDULO DE PARAMETRIZACIÓN DEL SISTEMA SIIS

(SISTEMA INTEGRAL DE INFORMACIÓN EN SALUD) DE LA EMPRESA

IPSOFT S.A.

JHONNY RIVERA PIZARRO

Pasantía Institucional para optar por el Titulo de Ingeniero Informático

Director JESÚS ANTONIO LEMOS BENAVIDES

Ingeniero Industrial. Maestría en Ciencias Computacionales

UNIVERSIDAD AUTÓNOMA DE OCCIDENTE FACULTAD DE INGENIERÍA

DEPARTAMENTO DE OPERACIONES Y SISTEMAS PROGRAMA DE INGENIERÍA INFORMÁTICA

SANTIAGO DE CALI 2017

3

Nota de aceptación:

Aprobado por el Comité de Grado

en cumplimiento de los requisitos

exigidos por la Universidad

Autónoma de Occidente para optar

al título de Ingeniero Informático.

Orlando Arboleda

Jurado

Santiago de Cali, 06 de Junio de 2017

4

A mi familia, en especial a mis padres, que con su incondicional apoyo permitieron que pudiera cumplir con el objetivo de convertirme en profesional. A mi hermana, aunque esté lejos, me dio ánimos cuando lo necesitaba, y los consejos precisos cuando me hacían falta. Y sobre todo a DIOS, por estar ahí SIEMPRE, que no me dejó bajar los brazos y que, sin ÉL jamás hubiera podido realizar esta pasantía.

5

AGRADECIMIENTOS

En primer lugar, le doy gracias a DIOS, por brindarme tantas bendiciones, fuerza para seguir luchando por mi sueño de ser profesional, por permitirme vivir la experiencia de realizar la pasantía, y por estar siempre conmigo en este proyecto y los que vienen después de este.

A mis padres, Luis Rivera y Esperanza Pizarro, quienes creyeron en mí y en que podría realizar este proyecto, quienes me acompañaron desde el inicio del proceso académico de formación profesional. Mil gracias por su apoyo.

A mi hermana Nancy Rivera, que desde Bogotá me enviaba su apoyo, sus valiosos consejos.

A mi compañero de estudio y amigo el Ing. José David Guapacha, quien me animó a realizar el proceso de la pasantía como opción de grado, y con quien compartí el proceso de formación profesional.

A mi director de Proyecto, el Ing. Jesús Antonio Lemos, a quien conocí desde que inicié mi formación profesional recién llegado a la universidad. Su valiosa enseñanza como docente me ayudó mucho en mi formación. Gracias por su paciencia como docente y como director de proyecto, por su dedicación para poder lograr la finalización de este proyecto y poder obtener mi título como profesional en ingeniería Informática.

Al Ing. Gustavo Rojas, por permitirme realizar el proceso de la pasantía en la empresa que él gerencia. Gracias por su dedicación, atención, consejos y su experiencia, ayudaron mucho a la realización de este proyecto.

Al Ing. Hugo Manrique, quien con paciencia me ayudó en las primeras etapas del proceso de la pasantía, cuya dedicación me ayudaron a iniciar este proceso.

Al Ing. Steven Ortiz, gracias por aceptar ser el asesor empresarial de la pasantía, por su dedicación, preocupación y sus consejos. Gracias por estar presente en el proceso de la pasante, inicialmente como compañero de IPSOFT S.A y después por ser mi asesor.

Gracias a mis compañeros de IPSOFT S.A, desarrolladores, personal administrativo, implementadores, personal de soporte, en general a todo el equipo de esta maravillosa empresa, por brindarme su apoyo, amistad y

6

asesoría, las cuales fueron fundamentales para el cumplimiento de mi proyecto de grado.

Gracias a todas las personas que, de alguna u otra forma, hicieron posible cumplir con este objetivo. Para ello mis mejores deseos, éxitos y bendiciones.

7

CONTENIDO

Pág.

GLOSARIO 17

RESUMEN 18

INTRODUCCION 19

1. PLANTEAMIENTO DEL PROBLEMA 20

2. JUSTIFICACIÓN 23

3. OBJETIVOS 25

OBJETIVO GENERAL 25 3.1

OBJETIVOS ESPECIFICOS 25 3.2

4. ANTECEDENTES 26

5. MARCO TÉORICO 29

BASES DE DATOS 29 5.1

5.1.1 Modelo Relacional 29

5.1.2 Modelo Entidad Relación (MER) 30

5.1.3 SQL 30

5.1.4 Sistema Gestor de Bases de Datos 31

5.1.5 PhpPGAdmin 31

5.1.6 PostgreSQL 31

SISTEMAS OPERATIVOS 32 5.2

5.2.1 Linux 33

8

HERRAMIENTAS DE MODELADO 33 5.3

5.3.1 Uml: 33

5.3.2 Mantis Bug Tracker 34

LENGUAGES DE PROGRAMACIÓN 34 5.4

5.4.1 HTML 34

5.4.2 PHP 35

5.4.3 JAVASCRIPT 35

LIBRERIAS: 36 5.5

5.5.1 JQUERY 36

5.5.2 XAJAX 36

5.5.3 FPDF 36

5.5.4 ADODB 37

PROGRAMACIÓN ORIENTADA A OBJETOS 37 5.6

MODELO VISTA CONTROLADOR 38 5.7

5.7.1 Modelo 38

5.7.2 Controlador 38

5.7.3 Vista 39

5.7.4 Interacción del Modelo Vista Controlador 39

CALIDAD DE LOS SISTEMAS DE INFORMACIÓN. 39 5.8

5.8.1 Funcionalidad 41

PROCESOS 41 5.9

9

MÓDULOS 42 5.10

6. METODOLOGÍA 44

COMUNICACIÓN 45 6.1

6.1.1 Conociendo la Empresa 46

6.1.2 Conociendo la Infraestructura de IPSOFT S.A 46

6.1.3 Reconocimiento del SIIS 46

6.1.4 Levantamiento de requerimientos 46

PLANEACIÓN 46 6.2

6.2.1 Definición de Procesos 47

6.2.2 Definición de Módulos 47

MODELADO 47 6.3

6.3.1 Análisis 47

6.3.2 Diseño 48

CONSTRUCCIÓN 48 6.4

6.4.1 Implementación o código 49

6.4.2 Pruebas 49

7. DESARROLLO DEL PROYECTO 51

COMUNICACIÓN 51 7.1

7.1.1 Conociendo la Empresa 51

7.1.1.1 Localización de la Empresa 51

10

7.1.1.2 Reseña Histórica. 51

7.1.1.3 Organigrama 54

7.1.1.4 Productos y servicios 54

7.1.2 Conociendo la infraestructura de IPSOFT S.A 56

7.1.2.1 Filosofía de programación 56

7.1.2.2 Procesos Internos. 57

7.1.2.3 Manual del desarrollador 57

7.1.2.4 Proceso de Inducción 57

7.1.3 Reconocimiento del SIIS 58

7.1.4 Levantamiento de Requerimientos 58

7.1.4.1 Especificación de Requerimientos 61

PLANEACIÓN 67 7.2 7.2.1 Definición de Procesos 68

7.2.2 Definición de Módulos 69

MODELADO 71 7.3

7.3.1 Análisis 71

7.3.1.1 Identificación de Actores. 73

7.3.1.2 Diagramas de Casos de Uso 74

7.3.1.3 Arquitectura del Sistema 76

7.3.1.4 Diagramas de Secuencia 79

7.3.2 Diseño 82

11

7.3.2.1 Prototipos. 82

CONSTRUCCIÓN 87 7.4

7.4.1 Implementación o Código. 87

7.4.2 Pruebas. 92

8. RESULTADOS 95

9. CONCLUSIONES 99

10. RECOMENDACIONES 100

BIBLIOGRFIA 101

12

LISTA DE FIGURAS

pág.

Figura 1. Modelo Cliente/Servidor utilizado en PostgrSQL 32

Figura 2. Modelo en Cascada. 44

Figura 3. Modelo Incremental. 44

Figura 4. Organigrama de IPSOFT S.A 54

Figura 5. Productos de IPSOFT S.A 55

Figura 6. Esquema de escritura de requerimientos. 59

Figura 7. Modelo Incremental en los Procesos. 68

Figura 8. Módulos del SIIS. 69

Figura 9. Estructuración de los Módulos Parametrizables. 70

Figura 10. Usuario Administrador. 73

Figura 11. Sistema 73

Figura 12. Diagrama de Casos de Uso, Buscador de Datos del parámetro. 74

Figura 13. Diagrama de Casos de Uso, Resultados de la búsqueda de 75

datos del parámetro. 75

Figura 14. Diagrama de Casos de Uso, Ventana de Adición de Datos

(Registro de nuevos datos). 75

Figura 15. Diagrama de Casos de Uso, Ventana de Modificación de Datos. 76

Figura 16. Modelo Vista Controlador. 77

13

Figura 17. Diagrama de Despliegue del AdminSIIS 78

Figura 18. Diagrama de Secuencia, Buscador de Datos del parámetro. 79

Figura 19. Diagrama de Secuencia, Resultados de la Búsqueda de Datos. 80

Figura 20. Diagrama de Secuencia, Formulario de adicionar datos. 80

Figura 21 Registro de un Nuevo Dato 81

Figura 22. Diagrama de Secuencia. Formulario de Modificación de Datos 82

Figura 23. Pantalla de Búsqueda del módulo. 83

Figura 24. Pantalla de Búsqueda de la opción del parámetro del módulo. 83

Figura 25. Pantalla Parametrización del parametro del módulo. 84

Figura 26. Formulario de Ingreso del parametro. 84

Figura 27. Selección de Empresas y dependencias 86

Figura 28. Menú Principal Procesos del SIIS 86

Figura 29. Menú de Módulos del proceso escogido 86

Figura 30. Pantalla de Parametrización del Módulo 87

Figura 31. Pantalla del formulario de ingreso del Parametro. 87

14

LISTA DE CUADROS

pág.

Cuadro 1: Procesos o servicios del SIIS. 42

Cuadro 2: Tabla de Control de Versiones de Requerimientos. 60

Cuadro 3. Requerimientos que no se repiten. 61

Cuadro 4. Requerimientos que se repiten. 61

Cuadro 5: Requerimiento Funcional 01 62

Cuadro 6: Requerimiento Funcional 02. 62













15









Cuadro 27. Tipo de Usuarios del AdminSIIS. 71

Cuadro 28. Herramientas de Desarrollo. 88

Cuadro 29. Tabla procesos. 91

Cuadro 30. Tabla procesosxmodulo. 91

Cuadro 31. Tabla etnias. 91

Cuadro 32. Tabla parentescos. 91

Cuadro 33. Pruebas a la búsqueda de datos. 92

Cuadro 34. Pruebas al ingreso de nuevo dato. 93

Cuadro 35. Pruebas la modificación del dato. 93

16

LISTA DE ANEXOS

pág.

Anexo A. Diagramas de Casos de Uso 104

Anexo B. Casos de Uso 107

Anexo C. Diagramas de Secuencia 135

Anexo D. Diagrama de Clases 141

17

GLOSARIO

BASE DE DATOS: Es un conjunto de datos que pertenecen a un mismo contexto y que son almacenados de manera sistémica para un uso posterior. Puede decirse que una biblioteca puede ser considerada una base de datos, compuesta en su mayoría por documentos y textos impresos en papel, e indexados para una consulta. En el campo de la informática, las bases de datos están diseñadas y almacenadas en formato digital.

GUI: (Graphic User Interface). Es la interfaz gráfica del usuario de un sistema o aplicación.

INTERFAZ GRÁFICA DE USUARIO: Es una vista de un programa, que interactúa como una interfaz de usuario por medio de imágenes, y objetos gráficos, que representan la información y las acciones que puede realizar en la interfaz. Su uso es proporcionar un entorno visual y sencillo para la comunicación de un usuario con un sistema.

INTERFAZ DE USUARIO: Es el medio por el cual un usuario puede comunicarse con un sistema y comprende todos los puntos de contacto entre el usuario y el sistema.

MÓDULO: En el contexto en que se realiza el presente proyecto, un módulo es un pequeño programa de un programa más grande. Es decir, un pequeño programa que está conectado con otros pequeños programas y que cada uno de ellos realiza una función específica. Al comunicarse e interactuar entre ellos, componen un programa más grande.

SISTEMA DE INFORMACIÓN: Es un conjunto de elementos orientados al tratamiento y administración de datos organizados y que pueden ser utilizados posteriormente. Estos sistemas son construidos para cubrir una necesidad.

SISTEMA DE INFORMACIÓN EN SALUD: Es un sistema de información que está especializado y orientado para tratar información y datos del sector de la salud.

18

RESUMEN

El presente trabajo tuvo como objetivo solucionar una problemática de la Empresa IPSOFT S.A, presente en su sistema de implantación y parametrización de su software IPSOFT SIIS. Por medio de una investigación interna por parte de la empresa, se logra ver la necesidad de ampliar y adaptar la forma en que se realiza dicha parametrización, para evitar la realización de la parametrización directamente en la base de datos, reducir las inconsistencias a la hora de parametrizar por parte del cliente de IPSOFT S.A, facilitar la parametrización, disminuir los costos para dicho proceso, entre otros descritos en este documento.

Al tener conocimiento de esta problemática se procede a realizar el proceso de levantamiento de los requerimientos para desarrollar un módulo de parametrización que permita solucionar la problemática anteriormente descrita. Para ello se utiliza el framework desarrollado por IPSOFT S.A, el Modelo incremental para el desarrollo de software y el UML.

Los resultados de este proyecto, permiten la parametrización de su producto IPSOFT SIIS, por medio de un módulo en el sistema que posee una interfaz gráfica intuitiva y eficaz para el usuario, permitiendo realizar este proceso de manera más ágil.

PALABRAS CLAVE: Parametrización, Sistema de Información, Sistema de Información en Salud, Ingeniería de Software, Bases de Datos en PostgreSQL, pHp, Modelo Vista Controlador.

19

INTRODUCCION

IPSOFT S.A es una empresa colombiana creada en 2004 que se dedica al desarrollo y comercialización de software para el sector de la Salud, para ello, hace una alianza estratégica con varias clínicas reconocidas en la región y con InterSoftware, una compañía de software con experiencia en el sector de la salud, la cual se permite desarrollar su software estrella denominado SIIS. El SIIS, o Sistema Integral de Información en Salud, es un software 100% web para la gestión asistencial (Historia clínica electrónica), administrativa (Inventarios, Citas, Facturación, Caja) y financiera (presupuestos, contabilidad, cxc) de Instituciones que prestan servicios en salud, y que está hecho con herramientas libres.

Liderados por el Ing. Gustavo Rojas, gerente de IPSOFT S.A esta empresa no solo se limita a desarrollar software para la región pacifica, sino que tiene clientes en varias partes del país, inclusive está presente con clientes fuera de Colombia. Algunos de los clientes de IPSOFT S.A más importantes son: Clínica de occidente, Club Noel, Angiografía de Occidente, Clínica los Andes, Clínica Oriente, Nefrouros en Neiva, UCIMED en Pereira, CompuLAB SAS Popayán, Family Home Care en Medellín y Clínica Guayaquil en Ecuador.

Actualmente el SIIS, solo puede ser parametrizado directamente en la base de datos, generando inconvenientes a IPSOFT S.A y a sus clientes tales como el aumento de los costos cuando la empresa va a implantar el aplicativo en el cliente provocado así, el aumento en el tiempo de parametrización, aplicándose también cuando el cliente requiere ingresar nueva información y parámetros, en el momento de que el sistema ya está implantado.

Existen muchas entidades prestadoras de servicios de salud (clínicas, hospitales, laboratorios clínicos, farmacias) y en cada una de ellas poseen información valiosa para sí misma y diferente a la información de su competencia inmediata. Por ello es necesario dar parámetros a esa información para así consolidarla y poder consultarla, modificarla y adicionar más información según sea la necesidad en ese momento, tales como creación de nuevos tipos de documentos, perfiles de usuario, nuevos procesos, inventarios., etc. De no hacerlo así, surgen inconvenientes asociados con el manejo del SIIS, al no poderse adaptar de manera generalizada en todos sus clientes que tienen modelos de negocio particulares.

20

1. PLANTEAMIENTO DEL PROBLEMA

IPSOFT S.A tiene a SIIS (Sistema Integral de Información en Salud), como su producto estrella y la parte más importante en su estrategia de negocios. Cuando empezó su construcción, al momento de su modelamiento con la necesidad de tener corto tiempo para la codificación, pruebas, y de completar el proyecto, tomaron la decisión de omitir la parametrización desde el sistema de información, haciéndose de manera obligatoria que se realice el ingreso de los parámetros por medio de la base de datos directamente, y realizarlo al momento de la implementación. Si se deben hacer modificaciones a esos parámetros o ingresar otros nuevos, también deben realizarse de la misma manera. Luego de su construcción, debido a las necesidades del cliente, se dio prioridad a la construcción de nuevos módulos de forma que suplieran los requerimientos de sus clientes y la actualización del SIIS.

Este sistema está construido bajo un ambiente web y realizado con herramientas de código libre, y cuenta con los siguientes módulos: Gestión asistencial (Historia clínica electrónica), Administrativo (Inventarios, Citas, Facturación, Caja) y Financiero (presupuestos, contabilidad, cxc).

Cada uno de los módulos del sistema puede ser parametrizado guardando la información en las tablas respectivas a cada módulo del sistema. Cada cliente del SIIS, posee información única y valiosa que solo le pertenece a esa entidad en particular, haciendo que cada cliente del SIIS parametrice con información diferente para cada de sus necesidades.

Solamente un módulo del SIIS tiene parcialmente la opción de parametrización por interfaz gráfica de usuario; este módulo es el Administrativo, el cual solo tiene opciones de creación de algunos documentos administrativos tales como: Contratos y Documentos fiscales.

IPSOFT S.A, tomó la decisión de que la parametrización de los módulos del SIIS fuera por medio de código, es decir directamente en la Base de Datos se ingresaran los datos cuando se implanta en el cliente.

Tal inconveniente desencadena en varios problemas cuando se hace la configuración de los parámetros de las tablas maestras de los módulos, la parametrización no solo se realiza cuando se implanta el sistema, es capaz de hacerse cuando el cliente tenga el sistema en funcionamiento dependiendo de cuál sea la necesidad en el momento de hacer la parametrización (creación de nuevos documentos, creación de perfiles, modificación de cargos, factores legales, etc.) puede hacer que al realizar dicha modificación de parámetros o inserción de nuevos, pueda producir errores.

21

El proceso de parametrización puede hacerse con las personas encargadas del departamento de Sistemas del cliente (o el ingeniero de IPSOFT S.A que está implantando el SIIS cuando el departamento de sistemas no puede hacerlo o si no tienen ese departamento). En ciertas ocasiones en que la parametrización genera problemas y errores deben recurrir a soporte técnico de IPSOFT S.A.

Estos errores pueden producirse porque la información no está parametrizada y enlazada a las tablas que se requieren (que en unas tablas esté cierto tipo de información y en otras, que debería estar, no), generando conflictos con otra información.

Cuando el personal de IPSOFT S.A está realizando dicha parametrización se presenta los siguientes problemas.

Demora en la Implantación del SIIS.

Demora en dar la información requerida por el cliente al no tener el sistema parametrizado

Si la información del cliente se parametriza mal, se requiere el departamento de soporte de IPSOFT S.A.

Si el cliente es el que realiza la parametrización.

No se asignan correctamente los permisos

No se generan adecuadamente las liquidaciones.

No se visualiza la información requerida de forma óptima.

Puede llegar a dañar la base de datos al manipularla directamente sin el soporte de IPSOFT. S.A

Errores dependiendo de qué modulo está mal parametrizado

Cuando se ingresa la información y los datos por primera vez en la base de datos hace que el tiempo de instalación del SIIS aumente de 2 a 3 meses, ya que esta parametrización debería realizarse cuando el sistema este implantado.

22

El Tiempo extra que el SIIS no esté en funcionamiento de manera completa hace que el cliente pierda tiempo, dinero y su imagen decaiga porque no está prestando bien su servicio.

El departamento de Soporte Técnico no puede resolver los problemas, dudas sobre el funcionamiento del SIIS ya que continuamente está resolviendo problemas de parametrización.

23

2. JUSTIFICACIÓN

La implementación del SIIS en el cliente no es la óptima generando de manera involuntaria varios factores críticos que han disminuido la calidad del SIIS, tanto en la implementación como en el soporte. De acuerdo con el Departamento de Desarrollo de IPSOFT S.A indica que se presentan problemas a la hora de dicha implementación, ya que el tiempo de implantar el SIIS se extiende demasiado ya que el(los) ingeniero(s) de IPSFOT S.A o del departamento de sistemas del cliente deben parametrizar cada módulo directamente en la base de datos, haciendo el trabajo más dispendioso, además de que cuando se requiera modificar los parámetros ya ingresados en la base de datos del sistema de información o ingresar algún(os) parámetros nuevos, hay que hacerlo en la base de datos directamente, haciendo que algunos (o la mayoría) de problemas de la parametrización por primera vez puedan ocurrir de nuevo.

Además de la implementación, el departamento de soporte de IPSOFT S.A., no puede realizar bien su labor ya que no hay suficientes personas para abordar los problemas de implementación cuando se genera errores y dificultades anteriormente citados en la parametrización, a veces ocupando mucho tiempo de las personas del departamento para poder solucionar dichos problemas. Este departamento tiene como labor atender inquietudes y dar soporte técnico del funcionamiento del sistema de información cuando está correctamente implementado, así fue concebido, pero con la creciente demanda de corrección de errores de parametrización, no pueden realizar la función para la cual fue creado el departamento. Hay que recalcar que no todas las dificultades en la parametrización pueden ser solucionados, en algunos casos no pueden ser solucionados y por ello se ha tenido que parametrizar desde cero el sistema en caso de que el sistema ya esté funcionando, o volver a realizar la implementación cuando se hace por primera vez. Por esto la imagen de IPSOFT S.A decae ya que otros sistemas de información para el sector hospitalario, no presentan estos inconvenientes y pueden hacer que sus clientes prefieran a la competencia al comprar otro Sistema de información o que sus clientes actuales dejen de utilizar el SIIS. Cabe anotar que el principal objetivo de IPSOFT S.A a corto plazo no es la competencia con otros Sistemas de información que presentan un módulo de parametrización, sino que es su objetivo mejorar el servicio que presta el sistema de información al adaptar la forma que se parametriza actualmente, con un módulo con interfaz web desarrollado en el presente proyecto.

El sistema de parametrización web, mejoría el servicio y la imagen del SIIS, y por consiguiente de la empresa IPSOFT S.A, además se reduce el tiempo adicional en la implementación, generando una reducción de los costos adicionales que IPSOFT S.A tendría que asumir; el desplazamiento de sus ingenieros hacia el cliente y el pago extra a los ingenieros por la parametrización.

24

El cliente vería como se reduce el dinero que pierde mientras el sistema está fuera de línea, y evitaría que ese tiempo aumentara mucho más ya que se previene hacer una re-parametrización o una implementación desde cero por un error en la parametrización.

Los beneficios de realizar este sistema de parametrización son los siguientes:

Reducción en el tiempo de implementación del SIIS, ya que sería el mismo cliente quien parametrizarán sus propios datos.

El cliente tendría mayor control y seguridad en su información ya que IPSOFT S.A no conocería ningún tipo de información que el cliente maneja.

El cliente tendría más procesos diferentes ejecutándose de manera simultánea ya que no tendría que detener un módulo mientras se parametriza.

Reducción en el tiempo de parametrización mientras se implementa y cuando el sistema ya está implementado.

El cliente no tendría que estar llamando a soporte técnico de IPSOFT S.A para resolver problemas en parametrización o para que envié un ingeniero a realizarla.

El cliente no dañaría la base de datos ni su estructura, al parametrizar de manera incorrecta, evitando así re-parametrizar de cero o volver a implementarse.

El departamento de soporte técnico solucionaría solo los errores y problemas relacionados al SIIS y no a la parametrización.

El departamento de soporte técnico tendría más tiempo en generar requerimientos cuando los clientes tengan una nueva necesidad.

25

3. OBJETIVOS

OBJETIVO GENERAL 3.1

Desarrollar un módulo de parametrización de las tablas maestras del aplicativo IPSOFT SIIS (Sistema Integral de Información en Salud), para el proceso de gestión de la información con el fin de facilitar el funcionamiento del aplicativo.

OBJETIVOS ESPECIFICOS 3.2

Recolectar y analizar los requerimientos.

Realizar los ajustes necesarios en la base de datos.

Diseñar y construir el sistema de parametrización.

Integrar el sistema de parametrización a un módulo de interface web del SIIS.

Diseñar y ejecutar el plan de pruebas para el sistema de parametrización.

26

4. ANTECEDENTES

¿Qué es la parametrización? Es la personalización de un sistema, es decir la posibilidad que a un sistema de información se le permita modificar aspectos puntuales de su funcionamiento. Cada entidad de salud, tiene su propia información, que es completamente diferente a la de otra entidad, por ejemplo, cada entidad puede manejar medicamentos que otras entidades no utilizan, pueden utilizar diferentes tipos de documentos legales, pueden prestar diferentes tipos de servicios que otras entidades de salud no prestan, pueden generar reportes que otras no utilizan, etc.

Por ello cada entidad de salud, maneja información que es diferente a la de otra por su funcionamiento o por el tipo de entidad que es (porque tienen modelos de negocios particulares). Es por ello que la base de datos del SIIS, solo es entregada con la información que es común para todas las entidades que prestan servicios en salud, es decir, las que son obligatorias por el ministerio de salud de Colombia. Es por ello que este tipo de sistemas de información posea una manera de ingresar dicha información de manera eficiente y que sea fácil de utilizar, de ahí que es fundamental un módulo de parametrización, por ello si un sistema de información de salud no lo tiene, está en desventaja con otros que si lo posean, porque tiene que manejar mucha información particular al cliente.

Desde el año 2004 cuando IPSOFT S.A desarrolla el sistema SIIS, ha tenido 2 acontecimientos con su módulo de parametrización.

SIIS inicia en el año 2004, en el cual no existe forma de parametrizar los datos. La premura en la codificación del código del SIIS, así como la reciente demanda en la resolución de requerimientos de los clientes de IPSOFT S.A (en esa época), hicieron que la decisión tomada fuera lanzar el sistema lo más rápido posible cumpliendo con los requerimientos, pero dejando a un lado ciertos módulos que no eran prioritarios para el cliente.

En el 2007 conforme a lo consignado en el manual del programador, IPSOFT S.A toma la decisión de crear opciones de parametrización en algunos módulos, creando así pequeños opciones de parametrización en 3 módulos concretos para el funcionamiento estructural del aplicativo, es decir para que el sistema reconozca los módulos del SIIS, las historias clínicas, y los documentos básicos de la empresa. Por ello se crean las opciones de parametrización para los documentos principales creándose el módulo Administrador de Documentos, en el cual se crean los documentos básicos de la empresa. Las opciones de dicha parametrización son simples y escasas. Contemplan la creación de algunos documentos orientados a la administración,

27

tales como registro de pagos de papelería, registro de gastos y creación de contratos de empleados. 1

Como el SIIS, es un aplicativo modular, para administrar los módulos existentes se creó el módulo Administrador de módulos, en el cual visualizan los módulos creados en el aplicativo, se registran los módulos nuevos a desarrollar, se crean, modifican, eliminan y administran variables especiales que hacen que ciertos módulos interactúen diferente con ciertas empresas, un módulo en particular, deba comportarse con alguna diferencia de la otra entidad, ej. que una empresa realice movimientos de medicamentos de inventarios entre bodegas con el costo promedio de dicho medicamento, y otra entidad que lo realice con el último precio unitario de dicho medicamento).

Administración de submodulos, es un módulo donde se administra la historia clínica electrónica. Como existen diferentes especialidades, las opciones de la historia clínica varían según la especialización.

A partir del año 2007, IPSOFT S.A, no ha realizado ningún cambio en la parametrización de su sistema.

Existen algunos trabajos que explican formas de parametrizar sus bases de datos, entre ellos esta los siguientes proyectos:

En el 2006, el Dr. Alejandro Rodríguez Villalobos y el Ing. Antonio Vicente Santos Silvestre 2 , presentan un proyecto sobre la importancia de la parametrización de una bodega de datos de un ERP, con el cual mediante un programa creado por ellos, se podría parametrizar una bodega de datos de un ERP sin utilizar el módulo de WMS (Sistema de administración de Bodega de Datos), ya que declaran que dicho modulo se centra más en controlar la parte logística de almacenaje y se enfoca más en las operaciones diarias(recepción de productos, gestión de stocks, niveles de inventario, preparación de pedidos, y salidas de mercancía del almacén) que en la parametrización de la bodega de datos en la empresa.

Las empresas que desarrollan Software para el sector de la salud, son herméticas en la forma en que parametrizan sus sistemas de información. Por lo tanto, no es posible saber que se parametriza en sus sistemas ya que las desarrolladoras de software hacen su sistema de información con su propio diseño, y tiene opciones diferentes a las de su competencia. No es posible

1 IPSOFT S.A. Manual del programador de SIIS. 1 ed. Cali. IPSOFT S.A., 2007. p. 102 2 RODRIGUEZ VILLALOBOS, Alejandro. SANTOS SILVESTRE, Antonio Vicente. La importancia de la parametrización del módulo de gestión de almacén. Proyecto de un constructor visual de almacenes . [EN LINEA] Universidad Pontificia de Valencia. [Consultado el 14 de Abril de 2017.] Disponible en < http://personales.upv.es/arodrigu/idi/almacen.pdf>

28

conseguir esa información en una empresa prestadora de servicios en salud ya que declaran que son información confidencial y que, de no serlo, algunos de esos datos están protegidos por la ley.

Con respecto al ámbito internacional no hay información en internet sobre parametrización de sistemas de información en salud por las condiciones anteriormente descritas.

29

5. MARCO TÉORICO

La propuesta para dar solución a la problemática de IPSOFT S.A, es desarrollar un sistema de parametrización para un sistema de información de salud ya creado previamente por dicha empresa (SIIS), no aplican leyes nacionales, ya que dichas leyes solo aplican para la presentación de la información (reportes) y la demás información presentada en el sistema de información. Las normativas igual que los estándares, y procesos (de construcción del software, leyes impuestas por el gobierno de Colombia al sector de la salud a las entidades que prestan servicios en salud y al software que utilizan) tampoco son escritos ya que estos son de dominio privado de la empresa, así como el manual del programador del SIIS, que es el manual donde están consignados los procesos, conceptos, normativas y estándares que la empresa utiliza para realizar el sistema de información y que son los utilizados para realizar el desarrollo de software que ellos utilizan para su modelo de negocio. También en dicho manual se actualizaría con el sistema de parametrización que se desarrollará y por tanto de llegase a aplicarse dichas normas y estándares, también serían de dominio exclusivo de la empresa IPSOFT S.A.

Se puede mencionar que la empresa IPSOFT S.A, tiene la filosofía de utilizar herramientas de código libre para sus desarrollos, incluyendo los sistemas operativos utilizados en sus equipos, los frameworks y herramientas de programación.

BASES DE DATOS 5.1

5.1.1 Modelo Relacional: Es un modelo en el cual se utiliza un grupo de tablas para hacer la agrupación de los datos y las relaciones entre ellos. Cada tabla está compuesta por columnas, la cual tiene un nombre único, un tipo de dato asociado, una longitud, una o varias restricciones y la posibilidad de que cualquiera de ellas pueda ser la (o las) llaves primarias (atributo que se utilizan para identificar la entidad, es única e irrepetible además se usa para relacionar una o varias tablas). Es un ejemplo de un modelo basado en registros, y estos se denominan así porque la base de datos, está estructurada por medio de registros de un formato fijo de varios tipos. Cada tabla contiene un tipo de registros de un tipo en particular. Cada uno de los registros posee un número fijo de atributos, que son los que se encuentran en las columnas y las filas corresponden a los registros3. El modelo Relacional es el utilizado por las herramientas de desarrollo del SIIS.

3SILBERSCHATZ, Abraham. KORTH, Henry F. Sudarshan, S. Introducción En: Fundamentos de bases de datos. Cuarta Edición. p.6.

30

5.1.2 Modelo Entidad Relación (MER): Es un tipo de modelo de datos de alto nivel el cual está basado en una percepción que se tiene del mundo real, el cual utiliza 2 componentes, las entidades y relaciones. Las entidades pueden ser vistas como “cosas” u “objetos” en el mundo real, como podría ser personas, cada persona puede ser vistas como una entidad, además elementos como cuentas bancarias, teclados, bicicletas, carros, etc. pueden ser consideradas entidades.

Las entidades se describen en la base de datos por un conjunto de atributos que son cualidades o características que puede tener la entidad, ejemplo numero_cuenta y saldo, son atributos de la entidad cuenta bancaria. También se puede decir que nombre_cliente, dirección_cliente, teléfono_cliente, son atributos de la entidad cliente. También en los atributos se utiliza un identificador para diferenciar 2 o más entidades iguales. Si es la entidad cliente, se utiliza el cedula_cliente, que es el número de la identificación de la cedula de ciudadanía que es único en Colombia, es decir 2 que un número no puede existir para 2 personas. Con ello se puede identificar un cliente de otro.

Las relaciones son las asociaciones entre entidades, por ejemplo la relación impositor, asocia a un cliente con cada una de sus cuentas4.

El modelo entidad relación es el modelo que utiliza la base de datos donde está construido el SIIS. Como dicho modelo no puede ser modificado ya que el sistema de información está ya usándolo, el sistema de parametrización debe seguir este modelo para dar solución al problema de IPSOFT S.A.

5.1.3 SQL: Es el lenguaje que más se utiliza en las bases de datos relacionales. Es un lenguaje estándar muy sencillo en el cual el usuario le hace preguntas al servidor y esta contesta según fue hecha la pregunta. Es estándar ya que la mayoría si no es todos los sistemas Gestores de Bases de Datos Relacionales, utilizan este lenguaje.

El lenguaje SQL, es importante ya que con él se hará el manejo de la base de datos. Actualmente para parametrizar se utiliza este lenguaje directamente en la base de datos. El sistema de parametrización es una herramienta que se quiere desarrollar para hacer dicha parametrización buscando que sea fácil de realizar por el usuario y evitar los problemas ya descritos. Para ello se debe utilizar este lenguaje para poder acceder a la base de datos, manipular las tablas, ya sea ingresando información nueva, modificando ya existente, y para crear nuevos parámetros, permisos, etc., que requiera el usuario del sistema de información.

4SILBERSCHATZ, Abraham. KORTH, Henry F. Sudarshan, S. Op.cit.. p.5

31

5.1.4 Sistema Gestor de Bases de Datos5: Un sistema Gestor de Bases de Datos o SGBD, es un conjunto de herramientas especializadas en bases de datos que nos permiten facilitar las operaciones que realizamos en las bases de datos, tales como consulta, uso, actualización. Algunos de esos ejemplos son Oracle 11g, phpMyAdmyn, PostgreSQL, etc.

Un Sistema gestor de base de datos, es esencial para la propuesta. Con ella se ingresan en lenguaje SQL, las instrucciones que se deben realizar para consultar, ingresar, modificar, y eliminar la información que se va a utilizar en la base de datos para hacer la parametrización, además es ahí donde se puede administrar la base de datos donde está construido el SIIS (El proyecto utiliza el SGBD PostgreSQL).

5.1.5 PhpPGAdmin6: Administración pgAdmin es la herramienta Open Source de administración por excelencia para sus bases de datos PostgreSQL. Algunas de sus características son: el soporte completo para UNICODE, edición rápida de consultas y datos multihilo y soporte para todos los tipos de objetos de PostgreSQL.

Esta herramienta es de código libre, es una modificación del PHPMyAdmin, en esencia realizan las mismas funciones solo que esta última está enfocada en gestionar la base de datos MYSQL. Por tal motivo y al ser un gestor de bases de datos para administración por web, es la que la empresa IPSOFT S.A utiliza para gestionar la base de datos del SIIS. Es indispensable su utilización ya que como se mencionó anteriormente con ella se administra la base de datos del sistema de información y además con ella se realizará las secuencias en lenguaje SQL que se necesiten para luego programarlas en el sistema de parametrización.

5.1.6 PostgreSQL7 : Es un sistema gestor de bases de datos relacionales (SGBS) orientado a objetos, siendo el más potente y robusto de todos los que tienen código libre. Este SGBS, utiliza el modelo cliente/servidor y el sistema de multiprocesos para garantizar la estabilidad del sistema, ya que un fallo en algún proceso, no afecta al resto y con ello el sistema seguirá funcionando.

5LÓPEZ MONTALBÁN, Iván. VÁZQUEZ, Manuel de Castro. Gestión de bases de Datos. 2 Ed. España, GARCETA GRUPO EDITORIAL, 2014 p.24-25 6 PhpPGAdmin SourceForge. What is phpPgAdmin?. [EN LINEA] PhpPGAdmin [Consultado el 03 de Febrero de 2017]. Disponible en: < http://phppgadmin.sourceforge.net/doku.php> 7 POSTGRESQL.Sobre PostgreSQL. [EN LINEA] POSTGRESQL. [Consultado el 03 de Febrero de 2017]. Disponible en: < http://www.postgresql.org.es/sobre_postgresql>

32

FIGURA 1. Modelo Cliente/Servidor utilizado en PostgrSQL

FUENTE: POSTGRESQL. Sobre PostgreSQL [EN LINEA]. Noruega. postgresql. [Consultado el Mayo 01 de 2017]. Disponible en Internet: < http://www.postgresql.org.es/sobre_postgresql>

SISTEMAS OPERATIVOS 5.2

La empresa IPSOFT S.A, utiliza LINUX como sistema operativo ya que sigue la filosofía de utilización de código libre, y porque sus servidores y los servidores de sus clientes están instalados este sistema operativo.

33

5.2.1 Linux8: Linux es un sistema operativo libre, es decir nadie es dueño de Linux, se puede conseguir su código fuente y se pueden hacer modificaciones, es gratuito y solo se cobra por el servicio técnico.

En este sistema operativo es donde están instaladas las herramientas de programación que IPSOFT S.A utiliza para su modelo de negocio. No solo están instaladas las herramientas de programación sino las herramientas de diseño, entrega de requerimientos, reporte de errores, y los servidores de IPSOFT S.A. por tanto es útil ya que todo el sistema de parametrización será construido bajo este sistema operativo.

Una de las características de Linux es que está modelado como un sistema operativo tipo UNIX, y desde sus orígenes fue concebido para que fuera un sistema multi-usuario y multi-tarea.

HERRAMIENTAS DE MODELADO 5.3

5.3.1 Uml9: Lenguaje de modelado Unificado, es una forma de modelado que prescribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan. También permite que se pueda visualizar, especificar, construir y documentar los artefactos del sistema. Básicamente el UML hace que el desarrollador pueda visualizar los resultados que puede obtener en su trabajo, mediante diagramas y esquemas estandarizados.

Maneja de forma estándar una semántica clara, precisa que define un significado mediante una notación gráfica, la cual está compuesta de símbolos e iconos que no son más que una sintaxis.

El UML, es una herramienta para diseñar el sistema antes de construirlo. Con ello se realizan los diagramas necesarios para diseñar el sistema de acuerdo con cada uno de los requerimientos que se tienen del proyecto.

8 Debian.org. ¿Qué es GNU/Linux?. [EN LINEA] Debian.org [Consultado el 13 de Marzo de 2017]. Disponible en: < http://www.debian.org/releases/wheezy/mips/ch01s02.html.es> 9 IVAR, Jacobson. BOOCH, Grady. RUMBAUGH, James. El proceso unificado de desarrollo de software. 1 Ed. España: Addison Wesley, 2000. p 407.

34

5.3.2 Mantis Bug Tracker10: Es una aplicación de software libre con soporte multiplataforma, que permite gestionar las incidencias de un proyecto de desarrollo. Es un sistema fácil de usar y adaptable a muchos escenarios, tanto para tickets de soporte, reportes de incidencias técnicas, como bugs para proyectos de software.

Este aplicativo en IPSOFT S.A, permite el modelamiento de los requerimientos mediante los tickets o nuevas incidencias (es aquí donde se redactan los requerimientos y se llena el formato de levantamiento de requerimientos de IPSOFT S.A), que puede ser vistos por cualquier usuario registrado a la red Mantis de IPSOFT S.A, con ello se puede llevar a cabo un seguimiento del requerimiento, asignarle un desarrollador, un supervisor (el encargado de supervisar el desarrollo del requerimiento por parte del desarrollador), entregar el requerimiento cuando está terminado, y devolver el requerimiento cuando la persona encargada por IPSOFT S.A de las pruebas considere que el requerimiento tiene algún fallo.

LENGUAGES DE PROGRAMACIÓN 5.4

5.4.1 HTML11: Es el lenguaje básico del desarrollo web, sin él no existirían las páginas web. Es un lenguaje basado en etiquetas que le da instrucciones al navegador de cómo debe mostrar el “contenido” (palabras, imágenes, audio, video, etc.) y lo separa de la "presentación" (la definición del tipo de contenido y las instrucciones de cómo esos contenidos tienen que mostrarse). Este lenguaje de programación está compuesto de varios tipos de elementos predefinidos que son los que se emplean para que el lenguaje identifique los diferentes tipos de elementos. Estos elementos, contienen una o más etiquetas que contiene o expresan el “contenido”. Dichas etiquetas van escritas entre los símbolos <> encapsuladas y las etiquetas de finalización están precedidas con / dentro de los símbolos anteriormente descritos, y definen el final de un contenido.

Este lenguaje, como es el más básico para el desarrollo web, es obligatorio usarlo para el desarrollo del módulo de parametrización.

10MantisBT Team. About MantisBT. [EN LINEA] MantisBT [Consultado el 2017-05-16] Disponible en < http://www.mantisbt.org/docs/master/en-US/Admin_Guide/Admin_Guide.pdf> 11 Introducción al HTML. Introducción al HTML-Guía de desarrollo. [EN LINEA] developer [Consultado el 12 de Febrero de 2016]. Disponible en: https://developer.mozilla.org/es/docs/Web/Guide/HTML/Introduction_alhtml>

35

5.4.2 PHP12: PHP es el acrónimo de “PHP: Hipertext Procesador” (Procesador de Hipertexto), es un lenguaje de programación de scripting de código abierto que es usado generalmente para el desarrollo web y que puede ser embebido en páginas HTML. Se caracteriza porque es un lenguaje que hace uso del lado del servidor, además de que su aprendizaje es sencillo, ya que su sintaxis es muy parecida a lenguajes de programación como C, JAVA y PERL, haciendo muy fácil su comprensión si se tienen conocimientos es dichos lenguajes. El objetivo de PHP, es que el desarrollador web pueda crear páginas web generadas dinámicas de manera rápida y fácil, aunque con este lenguaje se puede hacer más cosas.

Este es el lenguaje, junto con el HTML con los que está construido el SIIS, por tanto, todos sus módulos deben estar escritos en estos 2 lenguajes, incluyendo el módulo de parametrización.

5.4.3 JAVASCRIPT13: Es un lenguaje de programación para crear páginas web dinámicas, para ello se crea con este lenguaje pequeños “programas”, encargados de realizar algún tipo de acción dentro del ámbito de la página web. Este lenguaje es interpretado, por tanto, no se necesita compilar su código, solamente hace uso del navegador de internet sin necesidad de utilizar procesos intermedios u otros programas para su compilación. Cabe aclarar que este es un lenguaje que hace uso del lado del cliente a diferencia del PHP que es un lenguaje que hace uso del lado del servidor, y que no tiene nada que ver con el lenguaje de programación JAVA.

Al decir que se utiliza para crear páginas web dinámicas, se dice que éstas, contienen animaciones, efectos en el texto, acciones que suceden al pulsar un botón, ventanas con mensajes de aviso al usuario, ejecutar instrucciones como respuesta a las acciones del usuario, entre otras.

Este lenguaje de programación es útil en el proceso del desarrollo del módulo de parametrización, ya que con él se hacen las interacciones que el usuario va a tener con dicho modulo, además de que, con JavaScript, se realiza la comunicación entre el PHP y la librería XAJAX.

12 The Php Group. Manual de PHP [EN LINEA] The Php Group. [Consultado el 10 de Marzo de 2017] Disponible en <http://php.net/manual/es/preface.php> 13 EGUILUZ. Javier Introducción a JavaScript Capítulo 1. Introducción. Que es JavaScript. [En Línea] librosweb [Consultado el 2016-12-02] Disponible en <html://http://librosweb.es/libro/javascript/capitulo_1.html>

36

LIBRERIAS: 5.5

5.5.1 JQUERY14: Es una librería pequeña y rápida de JavaScript. Esta librería permite utilizar mejor el JavaScript, ya que utiliza funciones script que se utilizan de manera frecuente de manera más eficaz y con menos líneas de código que sin utilizar esta librería, por ejemplo, manejo de eventos que se realizan de manera frecuente, animaciones, manejo de AJAX, etc. Cabe destacar que el código utilizado en JQUERY es JavaScript.

Es muy importante, ya que el SIIS maneja muchos métodos que se realizan de manera muy frecuente. Cabe destacar que el framework está construido con scripts de JQUERY para ese tipo de métodos, por tanto, es indispensable utilizar esta librería para esas ocasiones y utilizar JAVASCRIPT “puro” para los métodos que no se utilizan de manera frecuente. 5.5.2 XAJAX15: Es un framework de AJAX para PHP que permite el manejo de AJAX de una manera simple y sencilla para las personas que no son expertas o tienen pocos conocimientos de JavaScript.

Por su versatilidad permite actualizar estilos, clases CSS, interactuar con cualquier atributo de un elemento dentro de un formulario (botones, casillas, listas desplegables.), eventos (onclick, onDblClick, nMouseDown, onchange), permite ejecutar funciones JavaScript, así como ejecutar funciones en pHp, acceder a la base de datos, entre otras, logrando modificar el contenido, el aspecto del formulario o de la página sin necesidad de recargar.

5.5.3 FPDF16: Es una librería de código libre escrita en PHP, que permite generar documentos PDF desde PHP, sin necesidad de utilizar librerías como PDFlib. Su nombre previendo de F que significa Free (Libre) y PDF. Como es una librería de código abierto o libre, se puede utilizar para cualquier propósito y si es necesario se puede realizar modificaciones en su código.

Sus principales características son: Elección de la unidad de medida, de formato y de márgenes, gestión de cabeceras y pies de página además del salto de página y de línea, admisión de imágenes, justificación automática de textos, permite la utilización de diversos tipos de archivos de tipográfica como los Type 1 y TrueType, compresión de páginas, entre otros.

14The jQuery Foundation. WHAT IS JQUERY. [En Línea] The jQuery Foundation. [Consultado el 2016-12-02] Disponible en <http://jquery.com/> 15 IPSOFT S.A. Op. cit p 88. 16 Qué es FPDF? [en linea] FPDF Library. [Consultado el Noviembre 17 de 2016] Disponible en <http://www.fpdf.org/?lang=es>

37

Es importante esta librería, ya que esta está integrada al Framework del SIIS, y su uso, es indispensable, ya que la mayoría de los módulos del Sistema de información, tienen la capacidad de realizar informes. El módulo de parametrización, puede permitir la creación de informes como una de sus opciones.

5.5.4 ADODB17: Es una librería para la abstracción fácil y rápida de una base de datos para PHP. Permite utilizar cualquier base de datos sin que se cambie el código de programación.

No es un sustituto para las extensiones PHP de bases de datos, pero se utilizan con ellas para dar más robustez a la aplicación. Esto significa que dichos controladores de estas extensiones deben ser instalados y configurados para que funcionen correctamente junto con el ADOdb. El SIIS, es un sistema de información que requiere de una base de datos para poder funcionar. Dicho sistema está construido para que se pueda utilizar cualquier base de datos existente además del utilizado por el SIIS que es el PostgreSQL (por ejemplo ORACLE, MYSQL, SQL SERVER). Para ello se necesita que el sistema pueda funcionar con cualquiera de ellas, sin que su código sea modificado, es por ello que se usa la librería ADOdb. Con ella es capaz de cambiar a cualquier base de datos que tenga su misma estructura relacional, es decir, sus mismas tablas, MER, relaciones, restricciones, etc.

PROGRAMACIÓN ORIENTADA A OBJETOS18 5.6

La programación orientada a objetos o POO, es un paradigma de programación el cual está basado en “objetos”. Este paradigma implica la construcción de un modelo de la vida real, y con base a ellos se escribe el programa. Un ejemplo de esto es la definición de objeto. Objeto es una entidad que tiene características, y puede comportarse de determinada manera. Estas características son llamadas Atributos y su comportamiento es el conjunto de cosas que realiza el objeto. Un objeto puede ser una Persona. Una persona tiene atributos, como el color de los ojos, la estatura, el peso, el color del pelo, etc. Una persona tiene un conjunto de cosas que hace, como estudiar, caminar, comer, dormir, etc., así mismo, son los objetos en este paradigma, tienen sus atributos y sus comportamientos. Otros ejemplos de objetos son: un avión, un automóvil, un gato.

17 ADOdb- Database Abstaction Layer for PHP [En Línea] USA. ADOdb [Consultado el Noviembre 17 de 2016] Disponible en <http://adodb.org/dokuwiki/doku.php> 18JOYANES AGUILAR, Luis. Programación Orientada a Objetos. 1 Ed. España, MCGRAW-HILL 1996. p xvii

38

El SIIS está construido en base a este paradigma, por lo tanto, el módulo de parametrización debe estar construido también con el POO.

MODELO VISTA CONTROLADOR19 5.7

El Modelo Vista Controlador es un patrón de diseño de la ingeniería de software que permite separar los datos, la interfaz de usuario y la lógica del control de la aplicación en 3 componentes diferentes. Como es un patrón de diseño y no un lenguaje de programación, puede utilizarse en lenguajes como JAVA, C, PHP, PERL, entre otros.

5.7.1 Modelo: Contiene una representación de los datos que maneja el sistema, y su lógica del negocio. Es responsable de:

Acceder a la capa de almacenamiento de los datos. Se recomienda que sea independiente de dicha capa.

Definir las reglas del negocio (Cómo funciona el sistema).

Llevar un registro de las vistas y los controladores.

Notificar a las vistas de los cambios que se puedan producir por un agente externo si se está en un modelo activo.

5.7.2 Controlador: Responde a eventos (generalmente son acciones que realiza el usuario) y hace peticiones al “modelo” cuando se realiza algún tipo de solicitud sobre la información (editar algún documento, realizar un registro en una base de datos, etc.).

Además, puede enviar órdenes a su “vista” asociada si se realiza un cambio en la forma en que se presenta el “modelo” (desplazamiento o scroll por un documento o por los diferentes registros de una base de datos), por tanto, se puede decir que el “controlador” es el que hace de intermediario entre la “vista” y el “modelo”.

19 A Description of the Model-View-Controller User Interface Paradigm [En Línea] web.archive [Consultado el 2016-12-19] Disponible en <http://web.archive.org/web/20150117044636/http://www.itu.dk/courses/ VOP/E2005/VOP2005E/8_mvc_krasner_and_pope.pdf>

39

5.7.3 Vista: Presenta el “modelo” (la información, y la lógica de negocio) en un formato agradable para el usuario (interfaz gráfica), de forma que él pueda interactuar con dicho “modelo”, por lo tanto, se puede considerar que la información debe presentarse como una salida.

5.7.4 Interacción del Modelo Vista Controlador: Este modelo es importante ya que separa las 3 capas. Pero, aun así, el usuario puede interactuar con las 3 en el sistema.

El usuario interactúa con la interfaz de usuario de alguna forma (ya sea pulsando un botón, un hipervínculo, un a imagen, etc.).

El controlador recibe (por parte de la capa “vista”) la notificación de la acción solicitada por el usuario. Esta capa, gestiona el evento que llega.

El controlador accede al modelo, y lo actualiza, posiblemente haciendo una modificación de forma adecuada a la acción que se solicita por el usuario (por ejemplo, el controlador actualiza el carro de compra del usuario). Los controladores complejos están a menudo estructurados de tal forma que encapsulan las acciones y simplifican su extensión.

El controlador delega a los objetos de la “vista”, la tarea de desplegar la interfaz de usuario. La vista obtiene los datos del modelo para generar la interfaz apropiada para el usuario, donde se muestran los cambios en el modelo (Ejemplo produce un listado del contenido del carro de compra).

La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente.

CALIDAD DE LOS SISTEMAS DE INFORMACIÓN20. 5.8

Cuando se habla de calidad en un sistema de información, puede decirse que puede descomponerse en diferentes factores que contribuyan con la misma. En Wilkin et al. (2003)21, se describe un instrumento multidimensional (denominado QUALIT) capaz de medir la calidad de un sistema de información entregado, en el que se hace diferencia entre la calidad que tiene el sistema y la calidad de la

20 PIATTINI VELTHUIS Mario G, GARCÍA RUBIO Félix O, GARCÍA DE GUZMÁN Ignacio, Pino Francisco J., Calidad de sistemas de información 2a Edición, RAMA, España Alfaomega. 2011, P.76-77 21 WILKIN C, CASTLEMAN T. Development of an Instrument to Evaluate the Quality of Delivered Information System. 2003. In 36th Hawaii International Conference on System Science. Hawaii.

40

información entregada a los stakeholders (sin incluir los manuales de usuario y las pantallas de ayuda), calidad del servicio (proporcionado por el Departamento de Sistemas y el personal de soporte). Los autores, han identificado varias dimensiones, como, por ejemplo, para la calidad del sistema, consideran: funcionalidad, integración, usabilidad, fiabilidad y seguridad.

Como el proyecto actual no consiste en construir un sistema de información, ya que este ya está construido (SIIS), se puede decir que la calidad se aplica al módulo de parametrización y puede reflejar un aumento en la calidad del SIIS.

Con el modelo de las “Cinco P” se puede destacar cómo la calidad de un sistema de información depende de: La calidad de las personas que desarrollan, mantienen y operan el software, así como los directivos, gestores, jefes de proyectos y staff relacionados con el mismo. La calidad de los procesos de los que disponga la organización.

La calidad de la gestión de los proyectos que llevan a cabo.

La calidad de los productos (incluyendo tanto las aplicaciones como datos/información, y adoptando la convención de las normas ISO que engloban los servicios como producto).

La calidad de las plataformas (incluyendo las de telecomunicaciones, hardware y software) que se utilizan para el desarrollo, mantenimiento y operación del software.

Como este módulo apenas se ha finalizado, y por las políticas de IPSOFT S.A de que los ingenieros de implementación y de pruebas realizan pruebas adicionales de acuerdo con el manual de procedimientos interno de IPSOFT S.A, todavía no se ha realizado la integración al aplicativo en producción (es decir, que todavía no se ha liberado una actualización para sus clientes y que no se ha integrado al aplicativo para implantar en los nuevos clientes). Como este proceso NO es competencia para el presente proyecto, no es posible realizar una medición de manera cuantitativa de la calidad del módulo y del sistema de información, hasta que el módulo esté integrado y en funcionamiento al aplicativo de producción y se libere a los clientes. Por lo tanto, se puede estimar como un indicador cualitativo de la calidad el software, utilizando las medidas del modelo de las “Cinco P” anteriormente citadas.

41

5.8.1 Funcionalidad. El sistema SIIS tiene una medida de calidad buena. Con el diseño del módulo de parametrización, se busca incrementar esta medida de calidad. Se puede decir de la medida de calidad actual lo siguiente:

Todos sus módulos funcionan de manera correcta, salvo algunos en los que al realizar la parametrización de manera directa (véase Planteamiento del Problema), se generan inconsistencias y problemas en la información, ya que muchas veces no se parametriza de manera correcta, o se ve afectada la integridad referencial de los datos en la tabla por algún query mal hecho.

Se puede presentar algún tipo de errores en módulos muy específicos del tipo de empresa que esté utilizando, como por ejemplo bio-medicina, medición oftalmológica.

El módulo de parametrización desarrollado en este proyecto hace que la funcionalidad del aplicativo sea robusta y coherente ya que es en el mismo aplicativo donde se realice la parametrización y no utilizando ningún programa externo para modificar la base de datos al realizar la parametrización. Después de que se implante en el SIIS, se espera que la calidad el mismo aumente (para una mayor profundización véase Justificación), ya que:

Que sea el mismo cliente quien parametrice su información.

Que la modificación y la adición de nuevos parámetros no influya en la información ya existente en el sistema, así como otros parámetros.

Que el cliente no requiera del departamento de Soporte de IPSOFT S.A para la parametrización de sus datos.

Que el cliente no requiera el desplazamiento de personal de IPSOFT S.A para la corrección de errores en la parametrización.

PROCESOS 5.9

Son cada uno de los servicios que ofrece el sistema de información para agrupar cada uno de los módulos. Estos servicios no están definidos en el inicio del proyecto, ya que IPSOFT S.A, no ha hecho una lista de ellos. Una vez llegado a la etapa correspondiente donde se identifica los procesos, se les enumera, se listan y se agrupa los módulos en su respectivo proceso, y así se utilizarán en el futuro módulo de parametrización.

42

En el cuadro 1, los procesos están listados con el nombre y el orden que fueron aprobados por IPSOFT S.A.

Cuadro 1: Procesos o servicios del SIIS.

Estructura Empresa Apoyo Diagnósticos Atención al Usuario

Cajas Cirugía Clasificación Cups

Compras Contabilidad Contratación

Consulta Externa Facturación Glosas

Honorarios Hospitalización Inventarios

Permisos Otros Terceros y Proveedores

Tesorería Proceso EPS PYP

MÓDULOS22 5.10

Los módulos son pequeñas partes autónomas del sistema de información, que realizan una función particular. El sistema de información debe realizar muchas tareas para cumplir con la función para lo cual fue creado, los módulos son los encargados de realizar dichas tareas. En el SIIS, algunos de los módulos son independientes de otros, es decir no necesitan a otro módulo para funcionar. Algunos de ellos pueden estar relacionados ya que pueden realizar tareas complementarias entre sí, por ello IPSOFT S.A, a decidido que en el módulo a desarrollar en este proyecto, cada módulo sea asociado a un proceso, esto se lleva a cabo cuando uno o más módulos tienen relación con el proceso al que se va a asociar (por ejemplo, el módulo Impuestos, Activos Fijos, Cuentas X Pagar se asignan al proceso de Contabilidad).

Algunos de los módulos del SIIS:

Impuestos

Activos Fijos

22 IPSOFT S.A Op. cit. p.150.

43

Cuentas x Pagar

Farmacia

Bodegas

Admisiones

Facturación

Cirugía

44

6. METODOLOGÍA

La Metodología utilizada en este proyecto es el Modelo Incremental. Son diferentes las razones por las que se usará esta metodología en la realización de este proyecto. Con esta metodología, se puede dividir un problema en pequeñas partes (incrementos)23.

Figura 2. Modelo en Cascada.

Fuente: PRESSMAN, Roger S. Ingeniería de Software Un Enfoque Práctico. 7 Ed. México: MCGRAW-HILL, 2014. p. 34.

El modelo incremental24, se apoya en el ciclo de vida básico de los proyectos, el cual sigue el modelo en cascada o lineal. Cada incremento, desarrolla las fases del modelo en cascada. Luego de terminar, se produce un incremento y, de nuevo, se inicia el ciclo. Cuando se produce el segundo incremento, los 2 incrementos juntos, se hacen más robustos, y se vuelven mucho más robustos cuando el tercer incremento sea creado, y así hasta el n-ésimo incremento.

Figura 3. Modelo Incremental.

Fuente: PRESSMAN, Roger S. Ingeniería de Software Un Enfoque Práctico. 7 Ed. México: MCGRAW-HILL, 2014. p. 35.

23 TAPIA, Daniel. Proyectos de Desarrollo de software. [EN LINEA] Universidad Autónoma de Madrid. [Consultado el 13 de Marzo de 2017]. Disponible en <http://arantxa.ii.uam.es/~proyectos/teoria/C5_Proyectos%20de%20desarrollo%20software.pdf> 24 PRESSMAN, Roger S. Ingeniería de Software Un Enfoque Práctico. 7 Ed. México: MCGRAW-HILL, 2014.. p. 35.

45

Cuando se hace la evaluación del incremento, se realiza la planeación del siguiente y así sucesivamente. Esta metodología es ideal cuando no existe mucho personal para su implementación. Los cambios son más sencillos de realizar al acotar el tamaño de los incrementos y también se puede depurar cada uno de ellos antes de pasar al siguiente. Luego se analiza los requerimientos de acuerdo con su prioridad, y los más prioritarios se incluyen en los incrementos más tempranos.

Esta metodología nos permite hacer el análisis, diseño, codificación y pruebas de cada parte del sistema de parametrización asociado a cada requerimiento que se obtiene, y cuando esté terminado puede continuar con el siguiente requerimiento. En IPSOFT, utilizan la metodología incremental, pero los incrementos se asocian a requerimientos, es decir cada incremento es la solución a un requerimiento específico. Esto permite gestionar mejor los riesgos del proyecto, hace más fácil probar y depurar cada incremento y además se entregan partes operativas del sistema a IPSOFT S.A

Es de anotar, que el desarrollo de este proyecto, se divide en procesos. Los procesos, son los servicios que el sistema ofrece. Por ejemplo, Hospitalización, Contratación, Contabilidad, Estructura de la Empresa, etc. Cada proceso, contiene uno o varios de los módulos del aplicativo, que es en sí lo que utilizan las empresas. Por ejemplo, Administración de la Empresa, Administración de Documentos, Caja general, Terceros, Proveedores, Cirugía, Historias Clínicas, admisión, etc.

Por la naturaleza del proyecto mencionado anteriormente (procesos), se ha decidido que el modelo incremental que usa IPSOFT S.A, va a desarrollarse con ciertas diferencias, el motivo, es que la mayoría de requerimientos (ver el capítulo Desarrollo del Proyecto), se comparten para los módulos parametrizables del aplicativo. Por tanto, cada elemento que se requiera parametrizar de dicho módulo, será construido con determinados requerimientos. Es por ello que los incrementos, serán cada elemento del módulo mencionado y cuando se junten estos entregables, harán que el módulo sea más robusto y por ello el proceso que lo contiene.

A continuación, se detallan las etapas de la metodología:

COMUNICACIÓN 6.1

Es el punto de partida donde se inicia el proyecto. Como tal, un proyecto tiene un inicio y un fin (ciclo de vida básico de un proyecto). En este inicio se llevan a cabo las primeras tareas del mismo para dar inicio al proceso que en este caso es la construcción del sistema de parametrización. Aparte de dar inicio formalmente al proceso se lleva a cabo una tarea muy importante del mismo.

46

6.1.1 Conociendo la Empresa. Es importante conocer la empresa. Como este proyecto parte de una necesidad, es imperativo conocer primero que es la empresa. A que se dedica, cuáles son sus clientes, que servicios provee, etc.

6.1.2 Conociendo la Infraestructura de IPSOFT S.A. Esta actividad se procede a conocer la estructura de IPSOFT S.A. En ella se espera conocer cuál es forma de trabajo de IPSOFT S.A, sus procesos internos, las dependencias y su estructura física. Para ello IPSOFT S.A proporcionara el manual del programador de SIIS, para conocer de forma teórica (código), como está compuesto el sistema de información junto con sus procesos métricas y estándares. También se estima realizar una inducción al estilo programación que utiliza IPSOFT S.A y de sus herramientas de programación.

6.1.3 Reconocimiento del SIIS. Después de conocer IPSOFT S.A de forma interna, de leer el Manual del programador del SIIS, y de realizar la inducción, se espera conocer cómo funciona el SIIS junto con la base de datos.

Para este reconocimiento IPSOFT S.A tiene unas directrices específicas. El SIIS debe ser conocido como funciona desde la perspectiva del programador es decir la estructura interna del SIIS y de su Base de Datos.

También se realiza este proceso, pero desde la vista de un Usuario Este reconocimiento no es tan profundo como lo haría una capacitación que IPSOFT S.A haría en los clientes, pero es el suficiente para entender que espera el cliente encontrar en el sistema de información.

6.1.4 Levantamiento de requerimientos. En esta fase se capturan los requerimientos del sistema a construir, en él se detallan y se reescriben para que se entiendan mejor.

En esta etapa se espera iniciar el proyecto conociendo los requerimientos que tendrá el sistema de información y cuáles son exactamente las necesidades que deben ser resueltas con el sistema que se va a construir. En IPSOFT S.A se realiza una vez, al inicio del proyecto

PLANEACIÓN 6.2

Luego de levantar los requerimientos y de hacer una escritura de los mismos de forma que se puedan entender, es primordial comenzar a entender cómo vamos a realizar el proyecto. Para ello se debe entender cómo se debe enfocar el proyecto y las necesidades del sistema. Por ello, es fundamental realizar una

47

planeación con base a los procesos y módulos afectados, que requieran ser parametrizados.

6.2.1 Definición de Procesos: Cuando se han realizado los requerimientos, se deben definir los procesos que tiene el SIIS. Actualmente el aplicativo, no tiene identificado los procesos a los que pertenecen los módulos que posee (IPSOFT S.A, no había realizado esta definición de procesos anteriormente), y si se realiza un módulo para parametrizar la información que requieran los módulos del SIIS para funcionar, es muy engorroso solo que aparezcan un listado de módulos y la opción para su parametrización, es por ello que se realiza la identificación de todos los procesos que el aplicativo presta (Estructura de la Empresa, Compras, Contabilidad , Contratación, etc.), para agrupar en cada uno, los módulos que pertenecen a dicho proceso y así sea más ágil y eficaz la parametrización porque ya se sabe de antemano con este esquema que información es la que se requiere parametrizar y hacia dónde va a estar enfocada.

6.2.2 Definición de Módulos: Cuando se tienen listos los procesos, se busca que los módulos del sistema queden agrupados por ellos. Por tanto, se identifican cuáles son los módulos que requieren parametrización, y luego se asocian a los diferentes procesos.

MODELADO 6.3

Luego de iniciar el proyecto, y de realizar la planeación, es clave saber que se va a construir. Para ello no se inicia en una codificación para construir el sistema, sino que primero se busca saber que se debe construir. Para ello se realizan actividades muy importantes. Cuando se modele el requerimiento se construye de acuerdo con el modelo incremental, es decir por incrementos, uno por uno, haciendo que se pueda entregar, sea funcional y que sea materia prima para el siguiente y así el sistema se incremente.

6.3.1 Análisis. En esta fase se hace un análisis de los requerimientos que fueron obtenidos en el levantamiento de requerimientos. Con esto se busca una mejor compresión de ellos y la descripción de los mismos, que haga que sea más fácil de mantener y se pueda hacer una estructuración del nuevo sistema entero.

En el levantamiento de requerimientos se utiliza el lenguaje del cliente, además para el análisis se utiliza una herramienta llamada casos de uso. Con ella podemos hacer el análisis de los requerimientos del cliente.

48

Los casos de uso deben mantenerse independientes unos de otros como sea posible*, los casos de uso deben de hacerse con lenguaje natural**, debe estructurarse cada caso de uso para que forme una especificación de funcionalidad completa e intuitiva25.

El propósito fundamental de este proceso es hacer un análisis de cada uno de los requerimientos, es por eso que podemos hacer una profundización sobre los aspectos más internos del sistema y resolver la interferencia de los casos de uso y demás actores.26

6.3.2 Diseño. En el diseño se hace un modelado del futuro sistema (incluida su arquitectura) para que sean soportados todos los requerimientos. La materia prima fundamental en el diseño es un excelente análisis, con él se da una comprensión detallada de los requerimientos para hacer su diseño y lo más importante se da forma de manera más fiel posible al nuevo sistema imponiendo una estructura en el sistema.

Los objetivos del diseño son:

Adquirir una mejor comprensión de los requerimientos (funcionales, no funcionales), restricciones, interfaces, todo tipo de componentes, arquitectura, software, lenguajes de programación, etc.

Crear una entrada apropiada para los procesos de implementación, haciendo una captura de los requerimientos, interfaces, clases y subsistemas individuales.

Descomponer los trabajos de implementación en partes más manejables para que puedan ser desarrollados por diferentes grupos de desarrollo.27

CONSTRUCCIÓN 6.4

El modelado del proyecto ya está hecho, con ello entendemos perfectamente el sistema y como debería funcionar. Ahora es momento de que el sistema cobre vida.

Con esta etapa se busca construir mediante los lenguajes de programación el sistema de información. Con el análisis y diseño del mismo se puede hacer una 25IVAR, Jacobson. BOOCH, Grady. RUMBAUGH, James. Op. cit. p.166. 26Ibíd., p.166, 169. 27Ibíd.,p.205.

49

construcción más fácil del sistema ya que se sabe que se va a construir y como debería reaccionar frente a diversas situaciones y actores.

Para ello se realizan las siguientes actividades:

6.4.1 Implementación o código. En este proceso traduciremos los resultados del diseño en un lenguaje de programación, es decir implementar en un sistema de componentes como ficheros de código fuente y luego en archivos ejecutables y similares.

Como el sistema fue capturado mediante el diseño, la implementación se remite en hacer que el diseño cobre vida haciendo uso de herramientas las cuales se puede plasmar como un código utilizando lenguajes de programación

Los objetivos de esta etapa son:

Planificar las integraciones del sistema necesarias en cada iteración.

Hacer la distribución del nuevo sistema en componentes ejecutables en nodos en el diagrama de despliegue.

Hacer la implementación de las clases, sistemas, subsistemas descubiertos en el proceso de diseño.

Hacer las pruebas de cada uno de los componentes, integrándolos haciendo su respectiva compilación y luego hacer los enlaces en uno o varios ejecutables28. 6.4.2 Pruebas. En este proceso se hacen las verificaciones del resultado del proceso de implementación, para constatar su pleno funcionamiento respecto a los requerimientos del cliente, con ello se hace una prueba a cada construcción, versiones, construcción final y entregables a terceros. Los objetivos de las pruebas son:

Hacer la planificación de las pruebas de cada iteración y cada componente incluyendo las pruebas de componentes y las pruebas del sistema.

28 IVAR, Jacobson. BOOCH, Grady. RUMBAUGH, James. Op. cit. p.256

50

Hacer el Diseño e implementación de las pruebas describiendo que se debe probar especificando y luego creando los procedimientos los cuales explican cómo se hacen, además de crear si es posible los componentes de pruebas ejecutables para hacer una automatización de las mismas.

Realizar las pruebas y manejar de manera sistemática cada uno de los resultados29.

29IVAR, Jacobson. BOOCH, Grady. RUMBAUGH, James. Op. Cit. p.282.

51

7. DESARROLLO DEL PROYECTO

Este capítulo muestra el proceso que se llevó a cabo para el desarrollo del módulo de parametrización del Sistema SIIS de la empresa IPSOFT S.A. Para dicho desarrollo, se emplean las diferentes etapas definidas en la metodología de desarrollo del Modelo Incremental. Para ello se designa un nombre para el módulo a construir, el cual es AdminSIIS (Administración de SIIS).

En esta sección, se muestra el inicio del proyecto. Como se dijo anteriormente, las siguientes etapas solo suceden una vez, de acuerdo a como la empresa maneja la metodología.

COMUNICACIÓN. 7.1

Esta es la etapa con la que se inicia el proyecto. Se busca conocer la empresa a fondo. Por ello se debe indagar con el asesor empresarial del proyecto para conocer la empresa, su estructura y sus necesidades.

7.1.1 Conociendo la Empresa. Lo primero que se debe conocer es la empresa. Con ello se puede tener un mejor enfoque del proyecto. El objetivo es conocer la empresa en la cual se desarrolla la pasantía.

7.1.1.1 Localización de la Empresa. IPSOFT S.A es una empresa localizada en la ciudad de Santiago de Cali, Valle del Cauca, actualmente se encuentran ubicados en la Calle 8 6-78 en el edificio Portugal, en el 4 piso.

7.1.1.2 Reseña Histórica. La historia de IPSOFT S.A y del SIIS es la siguiente:

En el año 1992 el ingeniero Gustavo Adolfo Rojas en asociación con dos compañeros de la Pontificia Universidad Javeriana, luego de permanecer laborando en grandes empresas de la ciudad por 5 años, funda CONFINES Ltda. Empresa que se dedicaba al desarrollo y comercialización de software, representante de INFORMIX, que realiza una alianza estratégica con INTEGRA S.A del Ecuador para hacer la distribución del software IHOSPITAL en Colombia.

Una vez comienza su labor comercial y con el desconocimiento previo de los temas relacionados al sector de la salud, se enteran que IHOSPITAL, no puede ser aplicado en Colombia tal y como está el aplicativo, debido a que ya estaba vigente la ley 100 que era un modelo muy diferente al ecuatoriano que tenía el antiguo modelo de salud.

52

En 1997, CONFINES es liquidada y el Ing. Rojas funda InterSoftware, una empresa que continua con muchos de los proyectos iniciados por CONFINES. Uno de ellos fue IHOSPITAL. Inmediatamente entre InterSoftware e INTEGRA, desarrollan un acuerdo para la construcción conjunta de un aplicativo que cumpliera con la ley 100, y por ello se contó con una IPS muy pequeña de urgencias de COMFANDI, donde se realizaron las primeras pruebas.

Después de ello, vinieron las verdaderas pruebas de fuego para el IHOSPITAL versión 5.0 (la versión desarrollada para Colombia) en el Hospital Universitario del Valle, la Clínica COMFANDI Tequendama, la Clínica Maranatha de Palmira, la Clínica Fátima de Pasto, la Clínica de Occidente de Tuluá, el Hospital Sagrado Corazón de Jesús en Cartago y el Hospital San José de Buga.

Por supuesto que realizar la implementación de un software en uno de los hospitales más grandes de América Latina como el HUV y una de las clínicas más grandes de Colombia, como la de Occidente de Tuluá ha brindado todo el conocimiento acerca de las mejores prácticas y procesos en una IPS en Colombia, así como por supuesto de la ley en salud.

Hacia el año 2001 InterSoftware comienza a recibir de los potenciales clientes en Colombia y otros países de América Latina la necesidad de tener en el sistema la Historia Clínica Electrónica, ya que IHOSPITAL no tenía módulos para ello.

Durante 6 meses, este grupo se dedicó a ver presentaciones de software y a viajar a algunas ciudades de Colombia e incluso fuera del país, para mirar la oferta de esta clase de software. Al final se decidió que ninguna de las ofertas satisfacía los requerimientos y además no era posible unirlo con IHOSPITAL.

La siguiente decisión por ese entonces fue definir por escrito los requerimientos de las Historias Clínicas para poder abrir un proceso de invitación privada con varios proveedores que permitiera contratar una empresa de software que lo desarrollara ajustándose a los requerimientos dados por el grupo y por supuesto que fuera integrable con IHOSPITAL.

Surge entonces la necesidad de seleccionar el lenguaje de programación en el cual se va a realizar el software, como la primera idea es desarrollarla con el sistema de gestión de bases de datos relacionales INFORMIX, se presentan 3 inconvenientes (En el momento en el cual se está tomando esta decisión, es decir en el segundo semestre de 2002) la compañía INFORMIX fue vendida a IBM, lo cual genera una gran incertidumbre. El segundo problema fue el lenguaje de programación Informix-4GL, ya que no es WEB y el tercero fue que la inversión necesaria en las licencias de INFORMIX tanto para el desarrollo

53

como para la utilización del software en producción era excesiva, superando los USD 150,000 para la cantidad de usuarios que tendrá la clínica.

Los inconvenientes anteriormente mencionados son comunes tanto en la entidad de salud, como para InterSoftware por lo que se llega a la conclusión que es mejor formar un equipo de trabajo entre el personal de la Clínica y de InterSoftware para escoger la herramienta.

Se revisa Java, PHP, Oracle, Websphere (IBM), Rational (IBM), Genexus, Visual Age For Java (IBM), D4GL (Herramienta Colombiana para desarrollar en I4GL y generar el código que opere en WEB), 4JS Development Tools, y otras. Finalmente, y después de considerar como premisas fundamentales que se requería una herramienta 100% Web y de código libre, pero que además se pudiera conseguir en el mercado local mano de obra calificada a costos razonables, se decidió trabajar con PHP y desarrollar sobre base de datos PostgreSQL, con Apache Web Server y Linux como Sistema Operativo. Java se ubicó en segundo lugar, pero el tema de la mano de obra calificada y a bajo costo, inclinó la balanza hacia PHP.

De inmediato se procede a cerrar la negociación para dar inicio al desarrollo, pero la Clínica advierte que dado que ha invertido tiempo y dinero en la definición de requerimientos y que además los mismos constituyen una invaluable información para cualquier compañía de software considera que debe tener participación en la propiedad intelectual, derechos de autor y regalías del producto a desarrollar. Luego de evaluar conjuntamente las diferentes opciones se toma la decisión de crear una nueva compañía en la cual las dos empresas contarían con la misma participación y esa empresa sería la dueña de todos los derechos. Nace entonces el 2 de enero de 2004, IPSOFT S.A.

La empresa recibe como funcionarios a los ingenieros de InterSoftware que por ya siete años venían desarrollando e implantando IHOSPITAL en hospitales y clínicas y suma a ellos personal nuevo, con conocimientos en desarrollo WEB, específicamente en PHP. Se forma entonces un equipo interdisciplinario con el equipo asistencial y el equipo técnico que había trabajado en InterSoftware, más el personal nuevo con formación en desarrollo Web que adelante las fases de Análisis, Diseño y construcción de SIIS (Sistema Integral de Información de Salud). Hacia finales del año 2004, la Clínica de Occidente de Cali, adquiere las acciones que estaban en propiedad de la Clínica de occidente de Tuluá.

La fortaleza que caracteriza a la empresa es el conocimiento de los requerimientos que en general pueden tener las instituciones que prestan servicios de salud y los procesos en que estas instituciones se manejan alrededor de las áreas asistencial, financiera y comercial.

54

Durante el desarrollo del SIIS, y ante la premura de los clientes, IPSOFT S.A, decide que debe acelerar la construcción del sistema, dejó a un lado la construcción de una GUI, para la parametrización de este sistema, enfocándose, en la construcción del aplicativo Web. También pasaron por alto algunos estándares como la usabilidad y alguna funcionalidad optima de algunos módulos.

Luego se toma la decisión de trabajar en conjunto con GIISOFT, el grupo de investigación en Ingeniería de Software de la Universidad Autónoma de Occidente y por más de un año y medio de labor se trabaja para mejorar la organización interna en cuanto al mejoramiento de la aplicación de la ingeniería de Software. Este trabajo de mejoramiento continuo se ha efectuado con el fin de garantizar a los clientes que los procesos de desarrollo bajo los cuales se produce SIIS, cumplen con las prácticas que aseguran el cumplimiento de los requerimientos y la solidez de la aplicación.

7.1.1.3 Organigrama

Figura 4. Organigrama de IPSOFT S.A

Fuente: IPSOFT S.A | SIIS. [EN LINEA] IPSOFT S.A [Consultado el 05 de Mayo de 2017] Disponible en <https://www.ipsoft-sa.com/siis>.

7.1.1.4 Productos y servicios. IPSOFT S.A cuenta con el aplicativo IPSOFT SIIS 30 (Sistema Integral de Información en Salud), el cual es su principal producto. Este aplicativo está orientado a hacer eficiente la gestión 30IPSOFT S.A | SIIS. [EN LINEA] IPSOFT S.A [Consultado el 05 de Mayo de 2017] Disponible en <https://www.ipsoft-sa.com/siis>.

https://www.ipsoft-sa.com/siis

55

administrativa (facturación, cajas, inventarios, citas), asistencial (Historia Clínica electrónica), financiera (presupuestos, cxc, contabilidad) de un Hospital, Clínica o en general cualquier institución de salud en América Latina.

Pero este no es su único producto. SIIS, es un aplicativo que tiene módulos y submodulos para todas las especialidades médicas. Por ello si una empresa en salud se especializa en alguna rama, puede optar por cualquiera de los siguientes productos.

Figura 5. Productos de IPSOFT S.A

Fuente: IPSOFT S.A | PRODUCTOS. [EN LINEA] IPSOFT S.A [Consultado el 05 de Mayo de 2017] Disponible en <https://www.ipsoft-sa.com/pproductos>. Todos los productos de IPSOFT SA, derivan del SIIS, es decir los demás aplicativos, contienen los módulos específicos para la especialidad a la que se dirigen y el SIIS, contiene todos los módulos al ser el aplicativo para entidades de salud en general, por lo tanto una vez creado el AdminSIIS en el aplicativo SIIS, se puede integrar en cualquiera de los otros productos.

OFTALMOSIIS31: Sistema Integral de Información en Salud, que puede ser usado por clínicas o consultorios de Oftalmología, para la atención de pacientes no solo en Oftalmología sino en todas las especializaciones de la salud visual (Retina, Neuroftalmología, córnea, glaucoma, oftalmolopediatria, Oftalmología oncológica, plástica ocular, entre otras. Es un producto específico que cuenta con una historia clínica de oftalmología general, y de sus demás subespecialidades. Al igual que el SIIS, permite manejo de agendas médicas, citas, facturación, contratos, convenios, inventarios, cirugías, apoyos diagnósticos, y en general los módulos básicos para la administración de una clínica oftalmológica, centro de atención de consulta especializada en oftalmología, o consultorio particular de oftalmología.

MEDISIIS32: Es una solución de software que trabaja con la modalidad SaaS-Software As A Service (software como un servicio), para consultorios médicos particulares o grupos de consultorios médicos de cualquier especialidad, que desee automatizar sus procesos de consulta externa. 31 IPSOFT S.A | OFTALMOSIIS. [EN LINEA] ipsoft-sa [Consultado el 05 de Mayo de 2017] Disponible en <https://www.ipsoft-sa.com/copia-de-siis-1>. 32IPSOFT S.A | MEDISIIS. [EN LINEA] ipsoft-sa [Consultado el 05 de Mayo de 2017] Disponible en <https://www.ipsoft-sa.com/medisiis>.

https://www.ipsoft-sa.com/pproductos

https://www.ipsoft-sa.com/copia-de-siis-1

https://www.ipsoft-sa.com/medisiis

56

ODONTOSIIS33: Es un sistema de información integral enfocada a las clínicas y consultorios odonlógicos, que les permiten realizar una prestación ágil del servicio y la automatización de procesos críticos.

FARMASIIS34: Solución de Software para cadenas de farmacias que desean optimizar sus recursos más críticos. Esta aplicación funciona bajo el sistema SaaS-Software, y en esta modalidad, la farmacia o bodega no compra la solución, sino que lo utiliza a través de Internet y paga un valor mensual por su uso y el almacenamiento de los datos en un DataCenter. El centro de FARMASIIS es la dispensación de medicamentos, integrado en la línea con los módulos administrativos en especial almacén, bodegas, facturación y caja.

7.1.2 Conociendo la infraestructura de IPSOFT S.A. Es importante conocer como es la estructura de la empresa, con que equipos cuenta, como es su forma de trabajo, cómo es la manera que se realizan las soluciones de software, sus modelos de programación, su estructura física, etc.

7.1.2.1 Filosofía de programación. Expresado anteriormente, IPSOFT S.A, opta por herramientas libres para su desarrollo. Actualmente utiliza APACHE2, como servidor WEB, MANTIS BUGTRACKER, como la herramienta para la especificación y asignación de requerimientos, PostgreSQL como la base de Datos, phpPgAdmin, como el gestor de base de datos, Notepad++ ó SublimeText3 como editores de código, LibreOffice y WPS Office como herramientas ofimáticas, y Linux como Sistema operativo. Las razones de la utilización de software libre están expuestas en la reseña.

La programación debe ser utilizada con el modelo Vista Controlador (ver marco teórico), además los aplicativos diseñados por IPSOFT S.A, son construidos en el lenguaje pHp con un framework propio construido por la misma empresa.

Su filosofía dicta, que el aplicativo deber ser utilizado por cualquier tipo de usuario, que, aunque no tenga conocimientos técnicos en informática, el sistema sea lo suficientemente intuitivo para que las personas puedan interactuar con el sin dificultad.

Como todo programa es necesario una capacitación, para mostrarle a los usuarios donde están las opciones y como se debe manejarlo, el aplicativo está construido con una interfaz que hace que el usuario no se pierda y sepa en todo momento en que parte del programa esta, en que módulo o en que menú

33IPSOFT S.A | ODONTOSIIS. [EN LINEA] ipsoft-sa [Consultado el 05 de Mayo de 2017] Disponible en <https://www.ipsoft-sa.com/odontosiis>. 34IPSOFT S.A | FARMASIIS. [EN LINEA] ipsoft-sa [Consultado el 05 de Mayo de 2017] Disponible en <https://www.ipsoft-sa.com/farmasiis>.

https://www.ipsoft-sa.com/odontosiis

57

se encuentra. Por tanto, la programación del aplicativo se centra en que debe ser un software robusto, con opciones que mejoren los procesos de las entidades de salud, pero ser lo suficientemente “fácil” de utilizar.

7.1.2.2 Procesos Internos. Al iniciar el proyecto con la empresa, se tuvo una inducción como parte del reconocimiento del modelo de trabajo de IPSOFT S.A. Se explican como son los procesos internos de la compañía, los formatos utilizados (No se pueden describir ya que son de uso exclusivo de IPSOFT S.A y por tanto no se puede revelar en este documento), cual es la forma de trabajo, el reglamento interno (también de uso exclusivo), y la forma de comunicación interna.

7.1.2.3 Manual del desarrollador. Es importante decir, que al ser un framework propio diseñado por la propia IPSOFT S.A, se decidió construir un documento donde se explica el funcionamiento del código del aplicativo SIIS, y por lo tanto de los demás productos de la empresa.

Este es el Manual del programador del SIIS, el documento más importante del aplicativo (para el desarrollador), donde se muestran las funciones más importantes y utilizadas por el framework, la forma como se deben utilizar el modelo vista controlador, el protocolo de creación de los archivos, carpetas, como deben desarrollarse los módulos, como debe utilizar las funciones, métodos, etc. Este documento muestra cómo debe construirse en código y en la interfaz gráfica de usuario los productos de IPSOFT S.A. Por motivos internos de la empresa este documento es de uso privativo de IPSOFT S.A, por lo tanto, no se puede escribir su contenido.

7.1.2.4 Proceso de Inducción. El proceso de inducción inicia con una prueba. Esta es la prueba (aquí la prueba es un examen de ingreso que realiza IPSOFT S.A para evaluar los conocimientos de una persona que quiere ingresar a trabajar a empresa. No se realiza en este caso para ese fin, sino para recordar conceptos de programación, bases de datos y para luego utilizar esas preguntas del examen para crear un módulo de prueba para conocer cómo se realiza la programación en el SIIS) que utiliza la empresa para las entrevistas de trabajo para los desarrolladores, pero para el proyecto se realizó con el fin de recordar conceptos de SQL, modelo entidad relación, y una breve introducción al sistema, ya que las preguntas contenían elementos del aplicativo como unas consultas a la base de datos del SIIS, y algunos procesos del sistema de la salud.

Una vez que se resuelve la prueba, el Asesor Empresarial de IPSOFT S.A, (que sería como el supervisor de la empresa para la pasantía, además de la persona que se ocuparía de ayudar con lo necesario para el desarrollo de la misma), indica que se debe estudiar el Manual del programador del SIIS y

58

que luego de su estudio se comenten las dudas que se tiene con respecto al documento. Acto seguido, se procede a realizar los ítems de la prueba, pero codificándolo en el SIIS, utilizando el framework. Con ello se inicia el proceso de acercamiento al sistema y como debe ser programado. En este proceso se muestra como se debe programar en el SIIS, ya que cuando se termina de realizar el código de la prueba, se muestra la interfaz gráfica y el uso de las librerías (ver marco teórico), y con ello se modifica lo realizado en la prueba con las librerías y el uso de las interfaces gráficas de usuario utilizadas en el sistema.

7.1.3 Reconocimiento del SIIS. Después de la inducción de cómo se debe realizar el código en el SIIS, comienza una inducción del funcionamiento del sistema. Con en esta etapa se muestra cómo funciona el SIIS, a nivel de código, como es la comunicación de los diferentes módulos, como interactúa al sistema con la base de datos, como se activan las notificaciones de los debugs de la base de datos y de las librerías para facilitar la construcción del módulo de este proyecto. Luego se procede a conocer el sistema de información a modo de código, es decir cuál es el código de programación del sistema de información, aquí se explica cómo se deben programar los diferentes módulos, como se realizan los reportes, como se asignan los permisos, como se crea un módulo, como se asocian los menús, etc. Luego de eso, se empieza a conocer desde el lado del cliente, es decir, se inicia el SIIS de forma como lo haría el cliente, y con la ayuda del asesor de la empresa, se comienzan a conocer los aspectos necesarios de cómo funciona el SIIS para la realización de este proyecto (No se aprende a manejar totalmente el sistema ya que para ello se necesitaría una cantidad de tiempo considerable, ya que las capacitaciones de IPSOFT S.A se demoran más de 20 días dependiendo del cliente y de los módulos que el cliente contrate o del producto que compre. Además de que no es competencia de este trabajo saber cómo funciona el SIIS en su totalidad, solo las partes del SIIS, necesarias para el desarrollo del trabajo).

7.1.4 Levantamiento de Requerimientos. Esta actividad permitirá tener una visión clara de las necesidades que debe satisfacer el módulo de parametrización.

Los requerimientos están construidos con las siguientes premisas y fueron escritos en el Formato de Definición de Requerimientos de IPSOFT S.A:

Son de tipo funcional, es decir, no mencionan los módulos, procesos, tablas afectadas para la parametrización, sino que se muestra cómo debe funcionar el módulo que se desarrollará en el presente proyecto. Esto es debido a que la mayoría de los requerimientos en su parte funcional aplican para todos los módulos que requieran parametrización. Además de ello, los módulos y las especificaciones de los mismos, es decir que se debe parametrizar y los

59

campos afectados son exclusivos de la empresa IPSOFT S.A y por ello no se pueden mencionar.

Están listados siguiendo el formato de especificación de requerimientos enumerados en el estándar IEEE 83035, utilizado generalmente en el área de ingeniería de requerimientos.

Los requerimientos poseen una descripción la cual está redactada con la forma de escritura de requerimientos utilizada en IPSOFT S.A36 que utiliza el marco normativo NTC-ISO 9001: 2008.37 para procesos de calidad. La empresa tiene como estándar una sintaxis en la que se debe escribir los requerimientos y es la siguiente:

Figura 6. Esquema de escritura de requerimientos.

[LUGAR, TIEMPO, EVENTO, OBJETO]+ “Debe, deberá, no debe, no deberá”+ [ACCIÓN,

VERBO, SENTENCIA]+ [A QUIÉN, SUJETO]+ [RESULTADO ESPERADO, DESTINO]

Fuente: IPSOFT S.A. Instructivo de Levantamiento de Requerimientos. Versión 01. Cali IPSOFT S.A, 2013. p. 2

Los requerimientos están redactados en orden de funcionalidad, es decir, si voy a parametrizar un módulo va desde el 1 paso que necesito hasta el último para parametrizar determinada opción del módulo.

Los requerimientos indicados en este proyecto son del tipo requerimientos funcionales (en la página anterior se describen porque son funcionales). Los requerimientos no funcionales son exactamente igual a los requerimientos no funcionales de los demás módulos, y por lo tanto los requerimientos no funcionales del SIIS. Por ello, no se mencionan ya que son privativos de IPSOFT S.A.

La nomenclatura de los requerimientos es la siguiente: RF# donde RF significa “Requerimiento” y el carácter # denota el número de secuencia del requerimiento.

35IEEE. Especificación de Requisitos según el estándar de la IEEE 830 [En línea] FDI [Consultado el 10 de Noviembre de 2016]. Disponible en <http://www.fdi.ucm.es/profesor/Gmendez/docs/is0809/ ieee830.pdf>. 36IPSOFT S.A. IPSOFT S.A. Instructivo de Levantamiento de Requerimientos. Versión 01. Cali IPSOFT S.A, 2013.. p.3. 37ICONTEC. NORMA TÉCNICA COLOMBIANA NTC-ISO 9001. Sistemas de gestión de la Calidad. Requisitos. [EN LINEA] ICONTEC. [Consultado el 10 de Noviembre de 2016]. Disponible en <http://www.cecep.edu.co/documentos/calidad/ISO-9001-2008.pdf>.

http://www.fdi.ucm.es/profesor/Gmendez/docs/is0809/ieee830.pdf

http://www.cecep.edu.co/documentos/calidad/ISO-9001-2008.pdf

60

El cuadro 2 muestra un controlador de versiones. Una de las políticas de IPSOFT S.A es que los requerimientos Tienen que ser aprobados antes de realizar cualquier acción con ellos. Por lo tanto, se deben realizar varias versiones, cada una de ellas con requerimientos corregidos de acuerdo a las observaciones del asesor (se muestran 2 personas por el cambio de asesor en el proyecto por parte de la empresa).

Cuadro 2: Tabla de Control de Versiones de Requerimientos.

Fecha Versión Descripción Autor Revisó Aprobó

25/11/2016 1.0 Identificación de requerimientos

Jhonny Rivera

Hugo Manrique No


Jhonny Rivera

Hugo Manrique No


Jhonny Rivera

Hugo Manrique No


Jhonny Rivera

Steven Ortiz Si

En la construcción de los requerimientos, se tuvo en cuenta las opiniones del Asesor Empresarial, el director de implementación, un consultor externo y el Gerente General.

Los requerimientos son mencionados a continuación por medio de tablas. Cada tabla de requerimientos está identificada por un nombre, la nomenclatura mencionada anteriormente y la prioridad asignada de acuerdo con el estudiante que realiza el proyecto y el asesor empresarial. La prioridad de los requerimientos puede ser una de las siguientes:

Inmediata: Es un requerimiento crítico y debe ser desarrollado de manera urgente.

A corto plazo: Son requerimientos que se deben considerar a desarrollar, pero que no tienen el mismo impacto que los de prioridad Inmediata.

Puede esperar: Son requerimientos que pueden ser desarrollados en otras versiones.

Por determinar: Son requerimientos que no se saben si son acordes al proyecto.

61

Lo siguiente es identificar el estado del requerimiento en el que fue registrado. Pueden ser alguno de los siguientes dos estados.

Identificado: Se obtuvo mediante la observación y la conversación entre el estudiante y el asesor de la empresa.

Especificado: Fue detallado directamente por asesor de la empresa o el gerente.

7.1.4.1 Especificación de Requerimientos.

Como fue dicho anteriormente, la funcionalidad hace que dependiendo del requerimiento actué un usuario diferente.

En los Cuadros 3 y 4 se indican los requerimientos clasificados en no repetidos y repetidos.

Cuadro 3. Requerimientos que no se repiten.

ID Req. Título Prioridad Estado

RF01 Módulo AdminSIIS Inmediata Identificado

RF02 Enlace al Módulo Inmediata Especificado

RF03 Validación de Permisos A corto Plazo Identificado

RF04 Seleccionar Empresa A corto Plazo Especificado

RF05 Asignación de Permisos A corto Plazo Identificado

RF06 Menú Principal Inmediata Especificado

RF07 Menú Módulos Inmediata Especificado

RF08 Menú Opciones de Parametrización Inmediata Especificado

Cuadro 4. Requerimientos que se repiten.

ID Req. Título Prioridad Estado

RF09 Permisos del Módulo. Inmediata Especificado

RF10 Menú de Parametrización. A corto plazo Especificado

RF11 Buscador de Datos del parámetro. Inmediata Identificado

RF12 Presentación de Datos existentes. Inmediata Identificado

62

Cuadro 4.(continuación)

RF13 Resultados de la búsqueda de Datos. Inmediata Identificado

RF14 Ventana de parametrización alterna. Inmediata Identificado

RF15 Formulario de adicionar datos. Inmediata Identificado

RF16 Registrar nuevo dato. Inmediata Identificado

RF17 Mensaje registro exitoso. A corto plazo Identificado

RF18 Regresar al buscador de datos. A corto plazo Identificado

RF19 Formulario de Modificación de datos Inmediata Identificado

RF20 Modificación de datos. Inmediata Identificado

RF21 Mensaje de modificación exitoso. A corto plazo Identificado

RF22 Eliminación de datos. Inmediata Identificado

A continuación, se detallan cada uno de los requerimientos en los cuadros 5 al 26 Cuadro 5: Requerimiento Funcional 01

N° Título: Prioridad Estado

RF01 Módulo AdminSIIS. Inmediata Identificado

DESCRIPCIÓN:

El sistema deberá tener un módulo de parametrización permitiendo al usuario

realizar la parametrización de módulos del SIIS.

Cuadro 6: Requerimiento Funcional 02.


RF02 Enlace al Módulo. Inmediata Especificado

DESCRIPCIÓN:

El sistema deberá tener un enlace en el menú principal para la integración del

módulo al sistema de información permitiendo al usuario acceder a él.



RF03 Validación de Permisos. A corto Plazo Identificado

DESCRIPCIÓN:

El sistema deberá realizar una validación de usuario al dar clic en el enlace al

módulo, informándole al usuario si tiene o no permiso de ingreso al módulo.

63



RF04 Seleccionar Empresa. A corto Plazo Especificado

DESCRIPCIÓN:

El sistema deberá permitir la selección de la empresa que está administrando el

usuario, mostrándole un menú con dichas empresas.



RF05 Asignación de Permisos. A corto Plazo Identificado

DESCRIPCIÓN:

El sistema deberá permitir asignar permisos al módulo, por medio del

Administrador de Módulos, mostrando al usuario las opciones de permisos, por

usuario o perfiles.



RF06 Menú Principal. Inmediata Especificado

DESCRIPCIÓN:

El sistema deberá mostrar en pantalla un menú, presentándole al usuario todos los

procesos que puede usar el SIIS.



RF07 Menú Módulos. Inmediata Especificado

DESCRIPCIÓN:

Cuando el usuario de clic en el link del proceso de su elección, el sistema deberá

mostrar en pantalla un menú indicándole al usuario todos los módulos que

pertenecen a ese proceso.



RF08 Menú Opciones de Parametrización. Inmediata Especificado

DESCRIPCIÓN:

Cuando el usuario de clic en el link del proceso de su elección, el sistema deberá

mostrar en pantalla un menú indicándole al usuario todos los módulos que

pertenecen a ese proceso.

64



RF09 Permisos del Módulo. Inmediata Especificado

DESCRIPCIÓN:

El sistema deberá mostrar en pantalla un menú de permisos cuando el módulo los

requiera, mostrándole al usuario las empresas que está administrando los

departamentos, unidades funcionales y centros de operación (si se aplica).



RF10 Menú de Parametrización. A corto plazo Especificado

DESCRIPCIÓN:

El sistema deberá presentar un menú de opciones de parametrización (si el módulo

así lo requiere) donde se muestre cada uno de sus opciones de parametrización.



RF11 Buscador de Datos del parámetro. Inmediata Identificado

DESCRIPCIÓN:

Cuando el usuario hace clic en la opción de parametrizar, el sistema deberá

presentar una nueva ventana mostrando al usuario un buscador con las siguientes

opciones: código, descripción, una opción de búsqueda específica del parámetro si

es necesario, botón de buscar, limpiar datos, un botón para adicionar un nuevo

parámetro y una tabla con los resultados del buscador.



RF12 Presentación de Datos Existentes. Inmediata Identificado

DESCRIPCIÓN:

El sistema deberá presentar en la misma pantalla una vez se ingrese a la opción de

parametrizar sus datos si existen en la tabla, mostrando al usuario las columnas

de la tabla, su información, una opción de modificación dependiendo del

parámetro y de eliminación si es necesaria.

65



RF13 Resultado de la búsqueda de Datos Inmediata Identificado

DESCRIPCIÓN:

El sistema deberá presentar en la misma pantalla los resultados de la búsqueda,

mostrando al usuario las columnas de la tabla, su información, un link de

modificación dependiendo del parámetro y un link de eliminación si es necesario.



RF14 Ventana de parametrización alterna. Inmediata Identificado

DESCRIPCIÓN:

El sistema deberá mostrar en pantalla una ventana de parametrización

personalizada al parámetro cuando dicho parámetro no se ajuste al buscador

convencional de los otros parámetros, mostrando al usuario unas opciones de

ingreso y modificación acorde a su necesidad.



RF15 Formulario de adicionar datos. Inmediata Identificado

DESCRIPCIÓN:

El sistema deberá presentar en pantalla una nueva ventana, mostrando al

usuario un formulario con los datos de las columnas de la tabla de dicho

parámetro junto con sus opciones, un botón de guardar y otro para cancelar.



RF16 Registrar nuevo dato. Inmediata Identificado

DESCRIPCIÓN:

El sistema deberá ingresar un nuevo dato a la tabla del parámetro con la

información almacenada en el formulario cuando el usuario hace clic en el

botón guardar y la información es válida, mostrando un mensaje indicándole

que la información fue registrada con éxito.

66



RF17 Mensaje registro exitoso. A corto plazo Identificado

DESCRIPCIÓN:

El sistema deberá mostrar en pantalla un mensaje cuando no se ingresaron los

datos en la tabla, indicándole al usuario que existe un error y devolviéndolo a

la ventana del formulario para que pueda modificar la información.



RF18 Regresar al buscador de datos. A corto plazo Identificado

DESCRIPCIÓN:

El sistema deberá salir de la pantalla del formulario, cuando el usuario hace clic

en el botón cancelar, mostrando al usuario la pantalla del formulario.



RF19 Formulario de Modificación de datos Inmediata Identificado

DESCRIPCIÓN:

El sistema deberá presentar en pantalla una nueva ventana, mostrando al

usuario un formulario con los datos de las columnas de la tabla de dicho

parámetro junto con la información a modificar, un botón de guardar y otro para

cancelar.



RF20 Modificación de datos. Inmediata Identificado

DESCRIPCIÓN:

El sistema deberá modificar el dato a la tabla del parámetro con la información

almacenada en el formulario cuando el usuario haga clic en el botón guardar y la

información es válida, mostrando un mensaje indicándole que la información fue

modificada con éxito.

67



RF21 Mensaje de modificación exitoso. A corto plazo Identificado

DESCRIPCIÓN:

El sistema deberá mostrar en pantalla un mensaje cuando no se modificaron los

datos en la tabla, indicándole al usuario que existe un error y devolviéndolo a la

ventana del formulario para que pueda modificar la información.



RF22 Eliminación de datos. Inmediata Identificado

DESCRIPCIÓN:

El sistema deberá eliminar un dato del parámetro cuando el usuario de clic en la

opción de eliminar, mostrando un mensaje indicándole que se realizó o no la

eliminación de manera satisfactoria.

PLANEACIÓN 7.2

En esta etapa, es fundamental saber qué es lo que se va a construir y cómo lo vamos a hacer. Es necesario identificar los procesos del aplicativo y los módulos parametrizables que lo contienen, junto con las opciones de parametrización, y las tablas que van a ser afectadas. Se realiza este paso con el fin de planificar como vamos a realizar el desarrollo del proyecto, el tiempo que se puede demorar el desarrollo, cuando se puede iniciar el análisis, y como se va a hacer el diseño del módulo de parametrización.

68

7.2.1 Definición de Procesos. Es importante que se sepa cuáles son los procesos que posee el SIIS. Esto es debido a que se requiere que el módulo de parametrización sea lo más intuitivo posible para los usuarios. Por ello si ven los procesos del SIIS, pueden de manera fácil, entender que se va a parametrizar. Para mejor compresión, se asocia a estos procesos, módulos que estarían alineados con dichos procesos. Un ejemplo puede ser el Proceso Estructura de la Empresa, en el cual estaría el módulo de Administración de Empresas, otro ejemplo de esto sería el proceso de Contratación y sus módulos asociados serían, Administración de Tarifarios, Contratación y Auditores.

Esta asignación se realiza en conjunto con director de implementación de IPSOFT S.A, ya que es el departamento que realiza la implantación del aplicativo en el cliente, y el que actualmente se encarga de la parametrización del mismo.

Figura 7. Modelo Incremental en los Procesos.

En la figura 7 (que es una creación del autor del proyecto y fue aceptada por IPSOFT S.A) los Triángulos coloreados, con las leyendas Pi (i de 1 a n) muestran los procesos del SIIS. El Triángulo blanco con las fichas de rompecabezas, muestra un proceso que apenas está en construcción. Las fichas significan los módulos parametrizables con interfaz gráfica que se acaban de construir en el proceso. Los módulos parametrizables que se les construya la interfaz gráfica, pueden decirse que están listos, y vendrían a ser los incrementos de este proyecto.

En esta parte, se realiza la planeación de cómo se va a realizar el módulo AdminSIIS. Como se acaba de decir, los incrementos son los módulos con su interfaz de parametrización terminada. Si se planea hacer esto, entonces también se debe saber que módulos pertenecen a cada proceso. Es decir, estos módulos con sus opciones de parametrización con interfaz gráfica, son los incrementos del proyecto, entonces son los que hay que darle más énfasis,

69

y con los que se debe realizar los seguimientos, estimaciones y por supuesto los controles.

7.2.2 Definición de Módulos. Este es el núcleo del proyecto, porque es lo que va a resolver este proyecto. Se deben conocer primero los módulos que cuenta el SIIS y como se construye a nivel de código (ya se realizó esto en la inducción).

Es aquí donde está el dolor de cabeza del departamento de implementación, soporte, y de los clientes de IPSOFT S.A, ya que los módulos que requieren parametrización poseen opciones que deben parametrizarse y que no tiene interfaz gráfica.

Primero se debe tener presente como están interactuando a nivel de código y de tablas los módulos del SIIS.

Figura 8. Módulos del SIIS. Fuente: IPSOFT S.A | SIIS. [EN LINEA] ipsoft- [Consultado el 05 Mayo de 2017] Disponible en <https://www.ipsoft-sa.com/siis>. Por lo tanto, hay que identificar cuáles son esos módulos y cuáles son esas opciones y que tablas con las que se deben parametrizar. No todos los módulos necesitan parametrizarse y otros, necesitan datos que se parametrizaron en otros módulos. Por ello es fundamental reconocer cuales son, y que se debe parametrizar de ellos.

El orden de reconocimiento es el siguiente: Se listan los módulos que requieren datos que deben ser parametrizados. Es posible, que 2 o más módulos necesiten de un dato que se requiera

https://www.ipsoft-sa.com/siis

70

parametrizar, pero al compartirlo entre dichos módulos, solo se parametrizarán en uno.

Se realiza la lista de las opciones de parametrización que tiene el módulo y, por último, a esas opciones se buscan las tablas que estén asociadas (en ocasiones una opción de parametrización requiere que se use 2 o más tablas).

En este paso, se debe identificar cual debe ser el orden de parametrización de los módulos, es decir, el orden que utiliza el departamento de implementación para realizar la parametrización del sistema. Ese orden se debe tener en cuenta para crear el diseño posteriormente.

Figura 9. Estructuración de los Módulos Parametrizables.

En la figura 9 (que es una creación del autor del proyecto y fue aceptada por IPSOFT S.A) se muestra cómo se estructura un proceso y sus módulos. El cuadro coloreado de la figura es un proceso del SIIS, dentro están asociados sus módulos parametrizables representados por las fichas de rompecabezas coloreadas con los caracteres Mi (i de 1 a n), como sus módulos parametrizables terminados. También se ve una ficha blanca con bloques grises, dicha ficha representa un módulo parametrizable del SIIS en el que se está realizando la interfaz gráfica de sus opciones de parametrización, los bloques son dichas opciones que ya se les hizo su interfaz. Cuando todas las opciones de dicho módulo tengan su interfaz (en el dibujo seria que los bloques cubran toda la ficha), el módulo ya es parametrizable por interfaz y está listo para ser entregado como un incremento. Esto hace que los módulos “terminados” hagan más robusto el proceso y por lo tanto el módulo AdminSIIS, cumpliendo así con el modelo Incremental.

71

MODELADO. 7.3

En este paso se realiza el modelado del módulo de parametrización con la herramienta UML. Se elige el nombre de AdminSIIS para el módulo, ya que IPSOFT S.A tenía deseos de realizar un módulo que administrara el sistema. Tiene 2 módulos llamados Administración de Módulos, que es el encargado de crear y administrar los módulos existentes y los nuevos (desde aquí se pueden crear nuevos), y Administración de Submodulos, que son los encargados de administrar los módulos de historias clínicas, (también puede crear nuevos). Siguiendo el lineamiento de los nombres para los módulos de administración, se piensa en AdminSIIS (que significa Administración del SIIS) como el nombre para el módulo de Parametrización y que será el módulo central de administración ya que se incluirán los 2 módulos anteriormente citados para que el usuario pueda parametrizar y administrar los módulos en un solo lugar, mejorando la usabilidad del sistema. Este nuevo módulo NO es la unión de los 2 anteriormente citados, la idea es que como los 2 módulos anteriores están enlazados directamente en el menú principal, para no dejar que las nuevas opciones a crear para la parametrización de los módulos, Administración de Módulos, y Administración de Submodulos queden en lugares diferentes, se adicione el enlace de estos 2 módulos dentro del menú del Módulo AdminSIIS.

7.3.1 Análisis: En esta sección, se identifica como se va a realizar el módulo AdminSIIS. Se analizan los requerimientos, las disposiciones que plantea IPSOFT S.A, la infraestructura del framework, y la directriz por parte del gerente de IPSOFT S.A de que la interfaz gráfica de usuario, sea acorde a los demás módulos del SIIS (la misma tipografía, las apariencias de las ventanas, de las tablas de resultados, de los buscadores, de las ventanas emergentes, etc.). Antes que nada, debemos analizar los tipos de usuarios que maneja el SIIS . Cuadro 27. Tipo de Usuarios del AdminSIIS.

Tipos de

Usuario

Clasificación de Usuario

IPSOFT

S.A

CLIENTE ADMINISTRADOR AUDITOR PERFIL SUPERUSUARIO

Usuario Normal NO SI* NO SI SI NO

Usuario

Administrador

NO SI* SI* SI SI NO

Usuario

Desarrollador

SI* NO SI SI SI SI

Usuario

Implementador

SI* NO SI NO NO SI

Usuario SIIS SI SI SI* SI SI SI*

72

Simbología: SI: Puede pertenecer a dicha categoría.

SI*: Pertenece estrictamente a dicha categoría.

NO: No pertenece por ningún motivo a dicha categoría.

IPSOFT S.A: Que pertenece a la casa de software.

Cliente: Que pertenece a la empresa cliente.

Administrador: Que el usuario tiene privilegios de administrador y que puede ser administrador en uno o más módulos. (Un usuario puede ser administrador de un solo módulo o de varios).

Auditor: Que el usuario es responsable de uno o varios contratos.

Perfil: Que al usuario se le pueden aplicar perfiles de usuario.

Superusuario. El usuario maestro que tiene todos los permisos de administrador y en todos los módulos. Por defecto es el usuario SIIS.

En el cuadro 27 se muestran los diferentes tipos de usuarios del AdminSIIS. Se puede apreciar que existen usuarios por parte de IPSOFT S.A y del cliente. Los de IPSOFT S.A, son los que utiliza la empresa creadora de IPSOFT S.A, para desarrollar el Sistema (SIIS y desarrollador para hacer pruebas), Implementador para realizar la implantación en el cliente, y el SIIS, que es el SUPERUSUARIO por defecto. Estos son importantes porque son los que utiliza la empresa para poder realizar las tareas de desarrollo, actualización, pruebas e implantación.

Cuando se menciona en este documento el Usuario Administrador, significa que es un tipo de usuario cualquiera de los que están en el cuadro 27 que pertenece normal o estrictamente a la Clasificación de Usuario Administrador, para IPSOFT S.A y para los usuarios del cliente, por ejemplo un Usuario desarrollador de IPSOFT S.A, no es un usuario Administrador pero puede dársele privilegios de Administrador y seguir siendo desarrollador, ya que, al tener todos los permisos, se facilita la construcción, y manipulación del SIIS, en entorno gráfico, al igual que el implementador cuando realiza la implantación. Se realiza el anterior cuadro porque un usuario administrador

73

puede también ser Auditor, puede tener algún perfil, al igual que el usuario Desarrollador para realizar pruebas o el implementador y se dice así, ya que aunque no se mencione ampliamente todos los tipos y clasificaciones de usuarios en este documento SI es Importante para el código del módulo del presente documento y un ejemplo de ello son los permisos de acceso.

Cabe aclarar que el SIIS, es un aplicativo “multi-empresa”, es decir, una empresa puede estar administrando varias prestadoras de servicios en salud, por ejemplo pueden estar administrando 2 entidades de salud de la misma empresa, y por tanto un usuario puede llamarse igual pero pertenecer a diferentes empresas, es decir, el Usuario SIIS de la entidad de salud A, es diferente al Usuario SIIS de la empresa B aunque ambos sean SUPERUSUARIOS, otro ejemplo es que Pepito Pérez de la entidad 1 puede ser en la entidad A un Administrador, y en la entidad B sea otra persona con el mismo nombre y tener otros privilegios o perfiles.

7.3.1.1 Identificación de Actores.

En las figuras 10 y 11 se listan los actores que interviene en los casos de uso.

Figura 10. Usuario Administrador.

Figura 11. Sistema

74

7.3.1.2 Diagramas de Casos de Uso. Dentro de los requerimientos anteriormente definidos, se eligen para ser mostrados en la presente sección los más representativos, es decir, los requerimientos que hacen parte del núcleo o core del AdminSIIS, y que son los que da más cumplimiento al problema de la parametrización. Los diagramas de casos de uso y sus especificaciones, corresponden a los requerimientos RF11, RF12, RF13, RF15 y RF19. Remitirse al Anexo A para observar todos los Diagramas de Casos de Uso y al Anexo B para sus respectivos Casos de Uso

Figura 12. Diagrama de Casos de Uso, Buscador de Datos del parámetro.

En la figura 12 se muestra el diagrama de caso de uso que representa a los requerimientos RF11 y RF12, donde de manera gráfica se enseña el proceso que realiza el sistema cuando un usuario Administrador da clic en una opción del menú de parametrización. En esta figura se muestra que luego que se da clic en el enlace de la opción de parametrización, el sistema muestra una ventana de parametrización para dicha opción, esta ventana presenta un formulario que contiene un buscador. Dicho buscador es para realizar la búsqueda de los datos de la opción de parametrización escogida. Por ejemplo, se pueden mencionar los estados (Departamentos) de un país, cuando la institución atienda a personas extranjeras (algunas de los clientes de IPSOFT S.A necesitan esta opción).

Se muestra un buscador donde se tienen las opciones de búsqueda (filtros) dependiendo de la opción escogida, en este caso como es estados (Departamentos), se tiene búsqueda por Id del Estado, Nombre del Estado o por País. Como los países están inscritos en una tabla, el sistema realiza una búsqueda para traer todos los países que están registrados en la base de datos (Buscar en Base de Datos opciones de búsqueda del parámetro). Otro ejemplo puede ser que se requiera parametrizar un tipo de documento asociado a un Documento contable general. Igual estos tipos de documentos generales deben ser consultados en la base de datos para poder ponerlos como un filtro de búsqueda. En este formulario se realiza la búsqueda y más abajo se muestran sus resultados. Si existe datos de la opción de parametrización, la muestra de manera inmediata sin realizar ninguna búsqueda (Mostrar Datos de Un Parámetro), es decir, si existen estados (departamentos), los muestra todos

75

con su información, otro ejemplo sería los tipos de documentos, si existen en la base de datos los muestra todos sin realizar ninguna búsqueda.

Figura 13. Diagrama de Casos de Uso, Resultados de la búsqueda de datos del parámetro.

En esta figura, se muestra el diagrama de caso de uso que representa al requerimiento RF13. El usuario Administrador, llena el formulario del buscador y utiliza los filtros de búsqueda de su elección. Cuando envía la búsqueda por medio del botón buscar, en la misma ventana deben mostrarse los resultados junto con el formulario de búsqueda (Mostrar Resultados y Mostrar Buscador). Para hacer la impresión en pantalla de los resultados, se debe realizar dicha búsqueda en la base de datos en la(s) tabla(s) involucradas de acuerdo a la opción de parametrización (Buscar datos en la tabla parámetro).

Figura 14. Diagrama de Casos de Uso, Ventana de Adición de Datos (Registro de nuevos datos).

En la figura 14, se representa el requerimiento RF15, esta es la ventana donde se ingresa o ADICIONA (en este diagrama solo se muestra el formulario no el procedimiento de registro o adición de nuevos datos) por interfaz gráfica (por medio de un formulario de acuerdo a la opción de parametrización) los datos nuevos que se quieran parametrizar. Cuando se da clic en registrar nuevo dato, se muestra una ventana de parametrización (Mostrar Ventana de Adición de Datos) y dicha ventana, muestra el formulario (Crear formulario de Adición).

76

Figura 15. Diagrama de Casos de Uso, Ventana de Modificación de Datos.

La figura 15 representa el requerimiento RF19, si la figura 14 mostraba la forma de ingresar los datos nuevos (la ventana del formulario), la figura 15, muestra cómo se modifica la información de los datos existentes (la ventana del formulario de modificación). Cuando el usuario Administrador da clic en Modificar Dato, aparece en pantalla una ventana para la modificación (Mostrar Ventana Modificación de Datos), en ella se muestra un formulario con los datos a modificar (Crear formulario de Modificación), para ello se busca en la base de datos la información de la opción de parametrización y se muestra junto con el formulario. 7.3.1.3 Arquitectura del Sistema. Es importante conocer la arquitectura del SIIS para poder realizar el módulo de parametrización.

El módulo AdminSIIS, al pertenecer al SIIS, debe ser concebido con la arquitectura que presenta dicho sistema, por lo tanto, es indispensable saber cuál es dicha arquitectura. El MVC (ver marco teórico) o Modelo Vista Controlador, es la piedra angular de la arquitectura del SIIS, por lo tanto, debe serlo para el módulo AdminSIIS, por 2 razones:

Los demás módulos del sistema están construidos con MVC, por lo tanto, hay un estándar para la creación de los módulos que debe seguirse.

Al estar todo el sistema construido en MVC, es necesario que el módulo de parametrización, también este construido de esa forma para que pueda interactuar más fácilmente con los demás módulos y tenga una uniformidad en la construcción con los demás módulos, reportes, etc.

La capa de Vista, debe tener los campos necesarios para la parametrización de los módulos y sus respectivas tablas. Es importante que se parametrice TODOS los campos necesarios, para cada opción y no se deje alguno sin parametrizar por GUI para un módulo. Debe ser claro y en lo posible que sea intuitivo para el usuario, que muestre los resultados, reportes de consultas, la información necesaria y que sea clara.

77

La capa del controlador, debe en todo momento ser trasparente para el usuario, es decir que, aunque el usuario no vea físicamente la capa, pero que este interactuando de manera correcta entre la lógica del negocio, y la capa de presentación. Debe ser eficaz en la realización de la administración de los recursos del SIIS, es decir, debe responder con eficiencia las peticiones de los usuarios, realizar correctamente su trabajo, seleccionar el mejor modo de respuesta a una petición del usuario, etc.

La capa del Modelo, debe interactuar con la capa del controlador. Debe ejecutar las peticiones que involucren a la base de datos, en este caso del Módulo AdminSIIS, debe ser quien ejecute los Querys para ingresar y modificar las opciones de parametrización de los Módulos.

La figura 16 muestra el funcionamiento básico del modelo MVC.

Figura 16. Modelo Vista Controlador.

Fuente: CakePHP. Entendiendo el Modelo Vista Controlador. [EN LINEA] CakePHP. [CONSULTADO EL 2017-02-15] Disponible en <https://book.cakephp.org/2.0/es/cakephpverview/understanding-model-view-controller.html>. También es importante saber de la arquitectura técnica del SIIS, es decir cómo funciona por “debajo”, como se comunica entre sí el sistema.

En la figura 17, se indica la arquitectura del AdminSIIS, necesaria para el módulo de parametrización. Dicha arquitectura descrita en el diagrama de despliegue, refleja lo que requiere el módulo AdminSIIS (AdminSIIS, dentro de “Módulos del Sistema”) para su funcionamiento con respecto a la arquitectura del sistema.

78

Figura 17. Diagrama de Despliegue del AdminSIIS

Cuando el Usuario Administrador necesita utilizar alguna opción del sistema, da clic en la interfaz gráfica (GUI) en el “PC del Usuario”, dicha interfaz gráfica envía la petición al servidor HTML, donde traduce el código de la interfaz gráfica de HTML a PHP que es conque está construido el aplicativo (se recuerda que el pHp es un lenguaje del lado del servidor y lo que se ve en el navegador es una interpretación en HTML del lenguaje pHp). Ahí el Servidor HTML con Apache2 procesa la petición del cliente y se comunica con el SIIS (sistema). En este caso sería la parametrización de un módulo, por lo tanto, el SIIS, recibe la petición en el controlador, que es el encargado de administrar las peticiones y dar respuesta a ellas. Con base a esto, el controlador, envía la petición al Módulo del Sistema AdminSIIS (módulo de parametrización), El módulo AdminSIIS, envía la petición al modelo que es la capa encargada de gestionar en el servidor de base de datos PostgreSQL la petición (consulta, modificación, eliminación).

Después de que se realice la petición, el modelo recibe la respuesta y es enviada al controlador. El controlador genera una “Vista” la GUI en pHp y es devuelta al servidor HTML, este servidor envía al usuario la interfaz gráfica con la respuesta a su petición en formato HTML luego de interpretarlo del pHp y el usuario por medio del “GUI” recibe la respuesta. Cabe destacar que el AdminSIIS, se comunica por medio del controlador con los demás módulos del Sistema.

79

7.3.1.4 Diagramas de Secuencia. A continuación se presentan los diagramas de secuencia de los casos de uso críticos que fueron presentados en las secciones previas. Para ver los restantes por favor remitirse al Anexo C.

La figura 18 se muestra como al entrar en la opción de parametrización tras la elección de la empresa, el sistema busca en la base de datos, los datos para crear los filtros de búsqueda. Por ejemplo, en la opción de Municipios, busca los datos de los países en la base de datos, para mostrarlos cuando se visualice el buscador. También se solicita que busque si existen datos e información registrada en la base de datos de acuerdo a la opción elegida. En este caso tomamos municipios, si hay municipios registrados, los muestre en la misma ventana del buscador. De la misma manera, si no existen dichos datos registrados, en este caso municipios, muestra un mensaje diciendo que no se encuentran los datos, esto para que el usuario entienda porque no se mostraron los datos.

Figura 18. Diagrama de Secuencia, Buscador de Datos del parámetro.

En la figura 19 se muestra como se realiza una búsqueda y posteriormente se muestran sus resultados. En primer lugar, el usuario llena el formulario de búsqueda A veces dicho formulario, contiene filtros adicionales, que al utilizarse uno, activa otro filtro. En el mismo caso mencionado anteriormente, si se utiliza el filtro de los países, el sistema busca los Estados/Departamentos que tiene dicho país escogido. Luego muestra esos estados, para que puedan ser utilizados en la búsqueda. Al utilizar el botón de buscar, el sistema busca en la base de datos conforme a los filtros utilizados y la información que se requiera

80

buscar. SI existen datos que coincidan con el criterio de búsqueda utilizado, muestra los datos, si no, muestra un mensaje diciendo que no existen datos.

Figura 19. Diagrama de Secuencia, Resultados de la Búsqueda de Datos.

En la figura 20 se muestra el proceso como se genera la ventana donde se registra o adiciona nuevos datos. Cuando el usuario hace click en el enlace de Adicionar nuevo dato, se muestra una ventana emergente donde el sistema, busca en la base de datos las opciones necesarias para ingresar que son necesarias a la hora del registo (por ejemplo si se va a registrar una nueva ciudad, se busca en la base de datos todos los paises que esten registrados en la tabla de paises), luego el sistema genera un formulario y lo presenta en pantalla. Figura 20. Diagrama de Secuencia, Formulario de adicionar datos.

81

En la figura 21 se muestra como se realiza el registro de los datos. Cuando el usuario llena el formulario de ingreso de los datos (Figura 20), y despues de que se de clic en la opcion de Registrar Dato, el sistema verifica si los datos que fueron ingresados en el formulario pueden ser ingresados, cuando se realiza la verificación, muesta en pantalla un mensaje si no es posible realizar el registo de los datos y muestra el error. Si se puede realizar el registro, el sistema adiciona los datos en las tablas correspondientes en la base de datos, y muestra un mensaje confirmando el registro de la información. Figura 21 Registro de un Nuevo Dato

En la figura 22 se muestra el formulario donde se realiza el proceso de modificar la información. Cuando se da clic en la opción de modificación de los datos, se muestra una ventana emergente donde busca en la base de datos la información que va a ser modificada de acuerdo al parametro que se quiere cambiar (por ejemplo si se quiere cambiar la información del documento maestro Factura de Venta F4, se busca en las tablas correspondientes la información con su identificador o código en la base de datos en este caso F4). Cuando se realice la búsqueda, se retorna a la ventana emergente y se muestra un formulario con el resultado de esa búsqueda, junto con todas las opciones de ingreso.

82

Figura 22. Diagrama de Secuencia. Formulario de Modificación de Datos

7.3.2 Diseño. Una vez que se realiza el análisis de cómo va a operar el módulo, se requiere que se realice un diseño del mismo. Conforme a los diagramas anteriormente mencionados y a los requerimientos, se procede a realizar el diseño del módulo AdminSIIS.

7.3.2.1 Prototipos.

Lo primero que se hace, es la realización de los prototipos que se realizan en paint y en Word por falta de un software para realizar prototipos. Los prototipos se realizan para ver cómo se verá de manera gráfica el módulo AdminSIIS. Se entregaron 2 prototipos. Las figuras 23 al 26 corresponden al primer prototipo entregado.

83

Figura 23. Pantalla de Búsqueda del módulo.

Figura 24. Pantalla de Búsqueda de la opción del parámetro del módulo.

84

Figura 25. Pantalla Parametrización del parametro del módulo.

Figura 26. Formulario de Ingreso del parametro.

Cuando se presentó este primer prototipo al Asesor de IPSOFT S.A, rechazó esta propuesta, por las siguientes razones:

La manera en que el cliente buscaba el módulo era muy confusa, no mostraba un orden específico de parametrización, además en la forma de acceso a los módulos es decir el buscador, no era una interfaz amigable para el usuario al realizar la parametrización.

Como es un sistema multiempresa no se podía seleccionar la empresa ni las dependencias que tienen, ya que cada módulo si tiene esa opción.

85

Es muy difícil realizar una asignación de permisos a los usuarios.

Luego el asesor indica las siguientes Recomendaciones.

Aunque la pantalla donde se busca los datos de la opción de parametrización está bien, junto con las opciones de registro y modificación, la forma en que se llega a esta opción no es fácil para el usuario.

No se puede seleccionar las empresas que administra el usuario que utiliza el AdminSIIS. Se debe poder escoger la empresa

Solo tiene validación por el módulo AdminSIIS y no por el resto de los módulos.

No se muestra los procesos del Sistema. Se busca que el usuario pueda ver los procesos de una forma que sea intuitiva de comprender. Hay confusión a la hora de seleccionar los módulos en un buscador. Es mejorhacerlo en forma de menú.

No se tiene en cuanta la validación de usuario de perfiles de empresas, departamentos, sedes, etc. en este modelo. Se debe realizar un doble menú de opciones de parametrización. Uno para hacer la validación y otro para escoger las empresas y sus unidades funcionales (Se hace así ya que todavía no está implementado el nuevo modelo de permisos en todos los módulos).

Se debe adicionar el Modulo Administración de Módulos, y Administración de Submodulos, junto con el Administrador de Documentos, como parte del AdminSIIS, para que no estén en 2 partes diferentes. (Son los módulos de parametrización que se mencionan en los antecedentes).

Acatando las recomendaciones anteriores, se procede a la realización del segundo prototipo que es indicado en las figuras 27 a 31, el cual fue aprobado por la empresa.

Primero se realiza un prototipo para la presentación de los procesos del SIIS. Se tomó como imagen para este prototipo el cuadro 1.

86

Figura 27. Selección de Empresas y dependencias

Figura 28. Menú Principal Procesos del SIIS

Figura 29. Menú de Módulos del proceso escogido

87

Figura 30. Pantalla de Parametrización del Módulo

Figura 31. Pantalla del formulario de ingreso del Parametro.

CONSTRUCCIÓN 7.4

7.4.1 Implementación o Código.

Para la realizar el código del AdminSIIS se emplean las siguientes herramientas indicadas en el cuadro 28:

88

Cuadro 28. Herramientas de Desarrollo.

Tipo Descripción

Lenguaje de programación pHp HTML JavaScript

Base de datos PostgreSQL Administrador de Bases de Datos PhpPgAdmin Entrega de Incrementos Mantis Scripts de bases de Datos SQL Editor de Texto Sublime3, Notepad++ Sistema Operativo Linux Chromixium

Librerías

FPDF ADODB XAJAX JQUERY

Es política de IPSOFT S.A que no se puede mostrar el código del módulo. Ni el diagrama de componentes.

El diagrama de clases se puede ver en el anexo D ya que es un diagrama que muestra el módulo AdminSIIS, y los módulos parametrizables con un nombre genérico. NOTA, las clases PHP_ARRAY y PHP_Request, son clases privativas del pHp, por tanto, no se describen sus métodos internos ya que estas clases contienen muchos métodos. Se incluyen porque es necesario que se creen objetos de dichas clases y por eso no están relacionadas con las demás.

Las clases ConectionDB y SIIS_FRAMEWORK_form, son clases exclusivas y privativas del SIIS, por lo tanto, no se muestra su contenido. La primera sirve para interactuar con la base de datos y la segunda es para crear los formularios, por esto se utiliza para crear objetos de esta clase y también es la razón por la cual no interactúa con otras clases.

Lo que se realizó en el proceso de construcción del código se comenta (se dice que se hizo, pero no cómo, ya que eso es privativo de IPSOFT S.A) en los siguientes ítems:

1. Se inicia creando el módulo AdminSIIS en el módulo Administrador de módulos, con ello se registra en la base de datos para que pueda ser reconocido por el SIIS.

89

2. Después de ello se integra el módulo al SIIS, creando un enlace al menú principal mediante el módulo anterior.

3. Una vez se ha realizado la integración, se realiza la autenticación, para ello también se utiliza el módulo AdminSIIS, y se crea los archivos pHp de acuerdo al modelo MVC y la forma de creación de módulos del MANUAL DEL DESARROLLADOR DEL SIIS.

4. Se crea el código para que funcionen los permisos y la selección de empresas y dependencias.

5. Se crea en los diferentes archivos del módulo, la interfaz gráfica del menú de los procesos.

6. Se crea el menú de los módulos y se le asigna un enlace a cada proceso para que dirija a un menú con sus respectivos módulos.

7. Se crea una tabla de procesos en la base de datos para guardar los procesos del Sistema.

8. Se crea una tabla de procesosxmodulo, donde se relacionan módulos con su respectivo proceso.

9. Se Adiciona los enlaces de los módulos Administración de Módulos y Administración de Submodulos a los procesos correspondientes para integrar esas funciones al AdminSIIS.

10. Se crea un link en cada módulo para que redirija a un menú de las opciones que se necesitan parametrizar de él.

11. Se crea el menú de las opciones de parametrización donde redirige el link mencionado en el ítem anterior.

12. Se adiciona el sistema de permisos de cada módulo parametrizable en sus opciones de parametrización.

13 Se crea un menú con los parámetros a ingresar de cada opción de parametrización.

90

14. Se crea la ventana de parametrización del parámetro.

15. Realizan los ajustes en la base de datos, creando tablas, modificando algunas tablas existentes (dependiendo del módulo, opción de parametrización y parámetro) para que se pueda realizar su parametrización.

16. Se crean los buscadores y las ventanas de resultados de los buscadores (si se necesita para el parámetro.

17. Se codifica el buscador.

18. Se crean los scripts en SQL para el buscador.

19. Se crean las ventanas alternas si el parámetro no necesita un buscador.

20. Se codifica la ventana de parametrización

21. Se crean los enlaces para las ventanas de los formularios de Registro de nuevo dato modificación y eliminación (Eliminación es eliminar el dato o cambiar de estado dependiendo del parámetro y de las leyes colombianas sobre la información de la salud cuando se requiera)

22. Se crea la ventana de registro de los datos

23. Se crea el formulario y se codifica

24. Se crea la ventana de modificación del parámetro

25. Se crea el formulario de modificación y se codifica

26. Se crean los scripts SQL para el registro y modificación

27. Se realizan las pruebas

En los cuadros 29 al 32 se listan algunas tablas que se crearon para la parametrización.

91

Cuadro 29. Tabla procesos.

Nombre de la Tabla: procesos Nombre Columna Tipo de Dato (Longitud) Restricción

Id_proceso Integer (Serial) Llave primaria descripción Varchar(50)

Cuadro 30. Tabla procesosxmodulo.

Nombre de la Tabla: procesosxmodulo Nombre Columna Tipo de Dato (Longitud) Restricción

Id_proceso Integer (Serial) Llave primaria Llave foránea( de tabla procesos)

Id_modulo Integer Llave primaria, Llave foránea( de la tabla módulos)

descripción Varchar(50) Cuadro 31. Tabla etnias.

Nombre de la Tabla: etnias Nombre Columna Tipo de Dato (Longitud) Restricción

Id_etnia Integer (Serial) Llave primaria descripción Varchar(15) código_alterno integer fecha_registro Date usuario integer Llave foránea (de

la tabla usuarios) Cuadro 32. Tabla parentescos.

Nombre de la Tabla: parentescos Nombre Columna Tipo de Dato (Longitud) Restricción

Id_parentesco Integer (Serial) Llave primaria descripción Varchar(12) fecha_registro Date usuario integer Llave foránea (de

la tabla usuarios)

92

7.4.2 Pruebas.

Se realizó las pruebas a los componentes de búsqueda de datos de un parámetro de un módulo parametrizable, agregar nuevo dato y nuevo dato. Ver los cuadros 33 al 35

Cuadro 33. Pruebas a la búsqueda de datos.

Prueba Búsqueda De datos del Parámetro

Ingreso Salida Salida Esperada

Ingreso a la pantalla Buscador y resultados existentes del parámetro en la tabla

Se debe mostrar el buscador y resultados existentes del parámetro en la tabla

Selección de un filtro de búsqueda por listbox

Muestra los filtros de Búsqueda consultados en la base de datos

Se deben mostrar los filtros de búsqueda en la tabla correspondiente al filtro

Selección de datos de un listbox que depende de otro filtro.

Muestra los datos en el listbox cuando se utiliza el anterior filtro de búsqueda

Se debe mostrar los datos en el listbox cuando se utiliza el anterior filtro de búsqueda

Formulario de búsqueda Muestra el resultado de la búsqueda, luego de hacerla.

Se debe buscar en la base de datos y mostrar el resultado de la búsqueda

La prueba a la búsqueda de datos fue satisfactoria. El buscador mostró la salida esperada. Los datos almacenados en la tabla del parámetro del módulo escogido fueron visualizados en el área de resultados de la forma que se requería.

93

Cuadro 34. Pruebas al ingreso de nuevo dato.

Prueba Ingreso nuevo dato


Clic en enlace adicionar datos

Formulario de ingreso Formulario de ingreso

Selección de un filtro de ingreso por listbox

Muestra los filtros de ingreso consultados e la base de datos

Se debe mostrar los filtros de ingreso en la tabla correspondiente al filtro

Formulario de ingreso Muestra el resultado de del ingreso, luego de hacerla.

Se debe ingresar en la base de datos y mostrar una confirmación

Formulario de ingreso mal diligenciado

Muestra error en el ingreso

Se debe mostrar un error en el ingreso

La prueba al ingreso de un nuevo dato fue satisfactoria. El formulario de ingreso registra los datos almacenados en él. Se muestra un mensaje de éxito al realizar el registro y se evidencia ya que se observó dichos datos ingresados en la tabla por medio del PhpPgAdmin. También se realizó la prueba ingresando datos erróneos para el formato del formulario, y fue también satisfactoria ya que mostraba el error en los datos diligenciados y no permitió su registro.

Cuadro 35. Pruebas la modificación del dato.

Prueba modificación dato


94

Cuadro 35.(continuación)

Clic en enlace modificar datos

Formulario de modificación

Busca los datos del parámetro en la base de datos


Se debe buscar los datos del parámetro en la base de datos

Selección de un filtro de ingreso por listbox

Muestra los filtros de ingreso consultados e la base de datos

Se debe mostrar los filtros de ingreso en la tabla correspondiente al filtro


Muestra el resultado de del modificación, luego de hacerla.

Se debe modificar en la base de datos y mostrar una confirmación

Formulario de modificación mal diligenciado

Muestra error en la modificación

Se debe mostrar un error en la modificación.

La prueba a la modificación del dato fue satisfactoria. El formulario de modificación, modifica los datos almacenados en él. Se muestra un mensaje de éxito al realizar el registro y se evidencia ya que se observó dichos datos modificados en la tabla por medio del PhpPgAdmin. También se realizó la prueba ingresando datos erróneos para el formato del formulario, y fue también satisfactoria ya que mostraba el error en los datos diligenciados y no permitió su modificación.

Se realizaron las demás pruebas que se registraron en el aplicativo Mantis BugTracker con formatos de IPSOFT S.A. Dichas pruebas fueron satisfactorias y por medio del aplicativo se devolvieron los formatos con la aprobación de los ingenieros de soporte e implementación de la empresa.

95

8. RESULTADOS

Luego de Realizar la codificación y las pruebas, se obtiene un resultado. La interfaz gráfica de usuario del módulo AdminSIIS, está completa. Se ha escogido mostrar algunos pantallazos del resultado final del módulo. Este módulo desarrollado en este proyecto fue integrado al SIIS, por medio del módulo Administración de Módulos, con esto, se puede acceder, desde el menú correspondiente en el aplicativo SIIS, y desde el AdminSIIS, se puede acceder a los permisos de cada uno de los módulos para poder realizar la parametrización (Es decir, si se va a parametrizar el módulo Administrador de Documentos, el AdminSIIS, como está integrado al aplicativo, busca los permisos que tiene el módulo a parametrizar y los utiliza para dar acceso al usuario a parametrizar el módulo).

Lo que se realizó en el proyecto fue realizar un módulo de parametrización, para ello se creó el enlace al menú principal al crear el módulo en el administrador de módulos, integrar el AdminSIIS al sistema con dicho módulo, crear los permisos de acceso, los menús de los procesos y módulos, sus opciones de parametrización y parámetros, sus ventanas de parametrización, sus formularios de registro, modificación y eliminación de parámetros. El proceso puede verse en la sección de Implementación.

Se puede ver en las siguientes figuras que son tomadas del módulo AdminSIIS integrado al sistema de información que son más intuitivas para el usuario y son adicionadas a las presentadas en las figuras 27 al 31 del prototipo 2

Figura 33. Enlace al módulo AdminSIIS (Parametrización General).

96

Figura 34. Menú de Módulos del proceso seleccionado

Figura 35. Opciones de parametrización del Módulo seleccionado

Figura 36. Parámetros de la Opción de parametrización del Módulo

Figura 37. Ventana de Parametrización

97

Figura 38. Formulario de Registro de nuevo dato.

Figura 39. Verificación del ingreso del nuevo dato.

Figura 40. Formulario de modificación de nuevo dato.

98

Figura 41. Verificación de la modificación del dato.

99

9. CONCLUSIONES

Con el proceso de investigación realizado internamente por la empresa es posible determinar las dificultades y necesidades que la empresa tiene en el momento de realizar la implantación en el cliente, y como les afecta a sus clientes en tiempo, dinero que el aplicativo no esté operativo, como le afecta directamente a IPSOFT S.A en tiempo, dinero en su imagen por este problema y como el departamento de soporte se dedica más a resolver problemas de parametrización que a otros problemas asociados al Sistema.

Con el uso de herramientas con GUI para agilizar y automatizar el proceso de parametrización se puede reducir el tiempo para que el aplicativo esté operando, mejore la interacción entre sus módulos, y evitar inconsistencias por errores al parametrizar directamente en la base de datos en los reportes cada vez más importantes para las empresas prestadoras de servicios en salud.

La metodología utilizada en el proyecto, el modelo Incremental, le permite a IPSOFT S.A realizar de manera más ágil el desarrollo de software. Para este proyecto permitió realizar un mejor seguimiento a cada una de las etapas realizadas y con el apoyo del software de gestión de incidencias Mantis BugTracker, el asesor pudo realizar el seguimiento de cada etapa. Además, se pudo acoplar a la forma de trabajo de la empresa.

El desarrollo de este proyecto, logró eliminar los inconvenientes en el proceso de parametrización del aplicativo por parte de los clientes de IPSOFT S.A y en el proceso de implantación de la empresa IPSOFT S.A, logrando estimar una mayor velocidad en ambos procesos y mejorando la imagen de IPSOFT S.A junto con la de su aplicativo.

Mediante el desarrollo de las pruebas, se logró verificar el correcto funcionamiento del módulo y que satisface el cumplimiento de las necesidades de la empresa al parametrizar e implantar el aplicativo en el cliente y de dicho cliente cuando quiera realizar modificaciones o agregar nuevos datos en la parametrización.

100

10. RECOMENDACIONES

Implementar un video manual para que el cliente sepa de una mejor manera como debe realizarse la parametrización por medio del módulo, el orden de parametrización, que significa cada parámetro que necesita los módulos y como debe realizarse.

Adicionar la opción de realizar la parametrización por medio de archivos, ya que, si el cliente pasa de un sistema antiguo al aplicativo SIIS, muchos de los datos se puedan cargar en la base de datos más rápido con esta opción, porque si son tablas que posean millones de registros, se demoraría mucho hacerlo uno por uno, así que se puede pasar los datos del sistema antiguo en archivos planos y con esta opción que se recomienda, registrar esos datos de parametrización se demoraría menos que realizarlos manualmente

Implementar un módulo de auditoria que permita registrar todos los cambios que se realizan en la parametrización, la hora, el usuario y cuál fue la modificación o la inserción de los datos.

101

BIBLIOGRFIA

ADOdb- Database Abstaction Layer for PHP [En Línea] USA. ADOdb [Consultado el Noviembre 17 de 2016] Disponible en http://adodb.org/dokuwiki/doku.php

EGUILUZ. Javier Introducción a JavaScript Capítulo 1. Introducción. Que es JavaScript. [En Línea] librosweb [Consultado el 2016-12-02] Disponible en <html://http://librosweb.es/libro/javascript/capitulo_1.html>

Debian.org. ¿Qué es GNU/Linux?. [EN LINEA] Debian.org [Consultado el 13 de Marzo de 2017]. Disponible en: < http://www.debian.org/releases/wheezy/mips/ch01s02.html.es>

ICONTEC. NORMA TÉCNICA COLOMBIANA NTC-ISO 9001. Sistemas de gestión de la Calidad. Requisitos. [EN LINEA] ICONTEC. [Consultado el 10 de Noviembre de 2016]. Disponible en <http://www.cecep.edu.co/documentos/calidad/ISO-9001-2008.pdf>.

IEEE. Especificación de Requisitos según el estándar de la IEEE 830 [En línea] FDI [Consultado el 10 de Noviembre de 2016]. Disponible en <http://www.fdi.ucm.es/profesor/Gmendez/docs/is0809/ieee830.pdf>.

INSTITUTO COLOMBIANO DE NORMAS TECNICAS Y CERTIFICACIÓN. Documentación. Presentación de Tesis, Trabajos de Grado y otros trabajos de investigación. NTC 1486. Bogotá D.C.: El Instituto. 2008. 42 p.

--------. Referencias Documentales para fuentes de información electrónicas. NTC 4490. Bogotá D.C.: El Instituto. 2008. 42 p.

--------. Referencias Bibliográficas. Contenido, Forma y estructura. NTC 5613. Bogotá D.C.: El Instituto. 2008. 42 p.

IPSOFT S.A. Instructivo para el formato de levantamiento de Requerimientos. En: Instructivo de Levantamiento de Requerimientos. Edición 01. p.3.

--------. Manual del programador de SIIS. 1 ed. Cali. IPSOFT S.A., 2007. 300p.

-------- | FARMASIIS.[EN LINEA] ipsoft [Consultado el 05 de Mayo de 2017] Disponible en <https://www.ipsoft-sa.com/farmasiis>.

http://adodb.org/dokuwiki/doku.php

http://www.debian.org/releases/wheezy/mips/ch01s02.html.es

https://www.ipsoft-sa.com/farmasiis

102

-------- | MEDISIIS.[EN LINEA] ipsoft [Consultado el 05 de Mayo de 2017] Disponible en <https://www.ipsoft-sa.com/medisiis>.

-------- | ODONTOSIIS [EN LINEA] ipsoft [Consultado el 05 de Mayo de 2017] Disponible en <https://www.ipsoft-sa.com/odontosiis>.

-------- | OFTALMOSIIS. [EN LINEA] ipsoft [Consultado el 05 de Mayo de 2017] Disponible en <https://www.ipsoft-sa.com/copia-de-siis-1>.

-------- | SIIS. [EN LINEA] ipsoft [Consultado el 05 de Mayo de 2017] Disponible en <https://www.ipsoft-sa.com/siis>.

IVAR, Jacobson. BOOCH, Grady. RUMBAUGH, James. El proceso unificado de desarrollo de software. 1 Ed. España: Addison Wesley, 2000. 464 p.

JOYANES AGUILAR, Luis. Programación Orientada a Objetos. 1 Ed. España, MCGRAW-HILL 1996. 336 P.

LÓPEZ MONTALBÁN, Iván. VÁZQUEZ, Manuel de Castro. Gestión de bases de Datos. 2 Ed. España, GARCETA GRUPO EDITORIAL, 2014. 304 p.

MantisBT Team. About MantisBT. [EN LINEA] mantisbt [Consultado el 2017-05-16] Disponible en < http://www.mantisbt.org/docs/master/en-US/Admin_Guide/Admin_Guide.pdf>

PhpPGAdmin SourceForge. What is phpPgAdmin? [EN LINEA] phppgadmin [Consultado el 03 de Febrero de 2017]. Disponible en: < http://phppgadmin.sourceforge.net/doku.php>

POSTGRESQL. Sobre PostgreSQL. [EN LINEA] postgresql [Consultado el 03 de Febrero de 2017]. Disponible en: < http://www.postgresql.org.es/sobre_postgresql>

PRESSMAN, Roger S. Ingeniería de Software Un Enfoque Práctico. 7 Ed. México: MCGRAW-HILL, 2014. 736 p.

Qué es FPDF? FPDF Library[en linea] fpdf. [ Consultado el Noviembre 17 de 2016] Disponible en <http://www.fpdf.org/?lang=es>

https://www.ipsoft-sa.com/medisiis

https://www.ipsoft-sa.com/odontosiis

103

RODRIGUEZ VILLALOBOS, Alejandro. SANTOS SILVESTRE, Antonio Vicente. La importancia de la parametrización del módulo de gestión de almacén. Proyecto de un constructor visual de almacenes [EN LINEA] .Universidad Pontificia de Valencia. [Consultado el 14 de Abril de 2017.] Disponible en < http://personales.upv.es/arodrigu/idi/almacen.pdf>

SILBERSCHATZ, Abraham. KORTH, Henry F. Sudarshan, S. Fundamentos de bases de datos. 4 Ed. España, MC Graw Hill, 2002 258p

TAPIA, Daniel. Universidad Autónoma de Madrid. Proyectos de Desarrollo de software. [EN LINEA] arantxa. [Consultado el 13 de Marzo de 2017]. Disponible en http://arantxa.ii.uam.es/~proyectos/teoria/C5_Proyectos%20de%20desarrollo%20software.pdf

The jQuery Foundation. WHAT IS JQUERY. [En Línea] jquery [Consultado el 2016-12-02] Disponible en <http://jquery.com/>

The Php Group. Manual de PHP [EN LINEA] PHP [Consultado el 10 de Marzo de 2017] Disponible en http://php.net/manual/es/preface.php

104

ANEXOS

ANEXO A. DIAGRAMAS DE CASOS DE USO

Este anexo contiene los diagramas de casos de uso.

Diagrama de Casos de Uso 2. Enlace al Módulo.

Diagrama de Casos de Uso 3. Validación de Usuario.

Diagrama de Casos de Uso 4. Menú Principal

Diagrama de Casos de Uso 5. Menú de Módulos.

Diagrama de Casos de Uso 6. Menú de Opciones de Parametrización

105

Diagrama de Casos de Uso 7. Validación de Usuario en Módulo Paramtrizable

Diagrama de Casos de Uso 8. Menú de Parametrización.

Diagrama de Casos de Uso 9. Búscador De datos del Parámetro

Diagrama de Casos de Uso 10. Resultados Buscador de la pantalla del parámetro.

106

Diagrama de Casos de Uso 11. Formulario de Ingreso de Nuevo dato.

Diagrama de Casos de Uso 12 Registro de un nuevo Dato.

Diagrama de Casos de Uso 13 Ventana de modificación de Datos.

Diagrama de Casos de Uso 14 Modificación de datos del parámetro.

107

ANEXO B. CASOS DE USO

En este anexo, se muestra de manera detallada el comportamiento del sistema mediante los casos de uso.

Caso de Uso 01: Ir a Enlace Módulo

Autor: Johnny Rivera Pizarro

Fecha: 10-01-2017

Descripción:

El sistema posee un enlace al módulo.

Actor: Administrador.

Requerimientos:

RF02 Enlace al Módulo.

Pre Condiciones:

El Usuario debe estar Autenticado en el Sistema.

El link del módulo debe estar habilitado para el usuario.

Curso Normal Alternativas

1. El usuario busca el link del módulo

en el menú del SIIS.

1.1 El Usuario no tiene habilitado el link

del módulo. Por tanto, dicho usuario no

puede ingresar. Retorna al paso 1.

Post Condiciones:

El sistema valida el usuario.

Caso de Uso 02: Validar Usuario


Fecha: 10-01-2017

Descripción:

El sistema hace una validación si, el usuario es o no Administrador


108

Requerimientos:

RF03 Validación de Permisos.

Pre Condiciones:

El Usuario debe estar Autenticado en el Sistema


1. El usuario hace clic en el link del

AdminSIIS.

2. El Sistema ingresa búsqueda en la

tabla de Usuarios Administradores

2.1. El Sistema no puede ingresar a la base

de datos ya que la sesión expiró, se

muestra la pantalla principal del SIIS.

Retorna al paso 1.

3. El Sistema valida si el usuario es

Administrador buscando al usuario en

la tabla de usuarios administradores

3.1 El usuario no es administrador. El

sistema muestra en una nueva ventana,

un mensaje que indica que no tiene

permisos para entrar al módulo. Retorna

al paso 1.

4. El Sistema muestra la pantalla del

buscador del módulo AdminSIIS.

Post Condiciones:

El sistema muestra la pantalla del buscador junto con todos los módulos

parametrizables.

Caso de Uso 03: Mostrar Ventana de Selección de Empresas


Fecha: 10-01-2017

Descripción:


Actor: Sistema.

Requerimientos:

109


RF09 Permisos del Módulo

Pre Condiciones:


El usuario debe tener permiso de acceso al módulo AdminSIIS


1. El sistema envía los datos del

usuario a la base de datos para

realizar una consulta de las empresas

que administra y sus dependencias

que tiene permiso en módulo (Ver

paso 1 del caso de uso 04).

2. El Sistema muestra en pantalla las

empresas administradas por el

usuario.

Post Condiciones:

El sistema muestra la pantalla el menú de procesos. Ver Caso de Uso 05

El sistema muestra la pantalla de parametrización Ver Caso de Uso 08

Caso de Uso 04: Buscar Empresas y Dependencias de la empresa


Fecha: 10-01-2017

Descripción:


Actor: Sistema.

Requerimientos:


RF04 Seleccionar Empresa.

Pre Condiciones:

110




1. El sistema envía a la base de datos

la consulta con los datos del usuario

2. El Sistema realiza la consulta de

las empresas y sus dependencias

que tengan permisos.

3. El sistema retorna los resultados

de la consulta (ver paso 2 del caso de

uso 03)

Post Condiciones:

El sistema muestra la pantalla el menú de procesos.

Caso de Uso 05: Visualizar procesos del Sistema


Fecha: 10-01-2017

Descripción:


Actor: Sistema.

Requerimientos:

RF06 Menú Principal.

Pre Condiciones:




1. El sistema muestra el menú de

Procesos del sistema cuando el

111

usuario entre satisfactoriamente al

AdminSIIS

Post Condiciones:

El sistema muestra la pantalla el menú de módulos.

Caso de Uso 06: Visualizar Menú de Módulos


Fecha: 10-01-2017

Descripción:


Actor: Usuario.

Requerimientos:

RF07 Menú Módulos.

Pre Condiciones:




1. El usuario hace clic en el proceso a

parametrizar

2. El Sistema muestra un menú con

los módulos del proceso.

Post Condiciones:

El sistema muestra la pantalla el menú de opciones de parametrización

Caso de Uso 07: Visualizar Menú de Opciones del Parametrización


Fecha: 10-01-2017

112

Descripción:


Actor: Usuario.

Requerimientos:

RF08 Menú Opciones de Parametrización.

Pre Condiciones:




1. El usuario hace clic en el menú a

parametrizar



2.1. Si el módulo tiene el sistema nuevo de

permisos, retorna al Caso de Uso 03 y al

finaliza ese proceso, se dirige al caso de

uso 08.

Post Condiciones:

El sistema muestra la pantalla el buscador de módulos

Caso de Uso 08: Visualizar Menú de Parametrización


Fecha: 10-01-2017

Descripción:


Actor: Usuario.

Requerimientos:

RF10 Menú de Parametrización.

Pre Condiciones:


113



1. El usuario hace clic en el menú a

parametrizar



Post Condiciones:

El sistema muestra la pantalla el buscador de módulos

Caso de Uso 13: Mostrar Pantalla del parámetro.


Fecha: 12-01-2017

Descripción:

El sistema muestra una pantalla con los datos de la tabla del parámetro, con las

opciones de añadir un nuevo dato, modificar los existentes y eliminar.

Actor: Sistema.

Requerimientos:

RF11 Buscador de Datos del parámetro.

RF12 Presentación de Datos existentes.

RF14 Ventana de parametrización alterna.

Pre Condiciones:

El Usuario debe ser Administrador.

La sesión no debe haber terminado.

El Usuario debe haber hecho clic en el link de parametrización del parámetro.

Debe de haber conexión con la base de datos.


1. El sistema crea una tabla con un

buscador. Ver paso 3 del caso de

uso 14.

114

2. El sistema muestra un botón para

el ingreso de un nuevo dato

2.1 El sistema muestra opciones especiales

para los módulos que requieran un

formato de pantalla personalizado.

Retorna al paso 1.

3. El sistema muestra una tabla con

los datos ingresados en la tabla

del parámetro (ver paso 3 del caso

de uso 15 y paso 2 del caso de uso

19).

Post Condiciones:

El sistema muestra usuario las opciones de la pantalla del parámetro.

Caso de Uso 14: Mostrar Buscador.


Fecha: 12-01-2017

Descripción:

El sistema muestra una pantalla con los datos de la tabla del parámetro, con las

opciones de añadir un nuevo dato, modificar los existentes y eliminar.

Actor: Sistema.

Requerimientos:


Pre Condiciones:






1. El sistema recibe el nombre de la

tabla del parámetro.

115

2. El sistema crea una tabla para el

buscador.

3. El sistema presenta en la tabla las

opciones y filtros del buscador.

Ver paso 2 del caso de uso 16.

3.1 El sistema muestra la tabla con las

opciones del buscador cuando no es

necesario un filtro de búsqueda.

Retorna al paso 1.

Post Condiciones:

El sistema muestra el buscador de la pantalla del parámetro.

Caso de Uso 15: Mostrar Datos del parámetro.


Fecha: 12-01-2017

Descripción:

El sistema muestra los datos ya ingresados en la tabla del parámetro.

Actor: Sistema.

Requerimientos:


Pre Condiciones:






1. El sistema busca si existen datos

en la tabla del parámetro. (Ver

paso 1 del caso de uso 17)

2. El sistema captura los datos de la

búsqueda.

2.1 El sistema captura null cuando no

existen datos en la búsqueda. Va al

paso 3.

116

3. El sistema muestra en una tabla

las columnas de la tabla del

parámetro, con sus respectivos

datos, opciones de modificación, y

eliminación.

3.1 El sistema muestra un mensaje

diciendo que no se encontró datos

cuando el resultado de la búsqueda

sea null. Va al paso 3. (Ver paso 3 del

caso de uso 13).

Post Condiciones:

El sistema muestra los datos existentes en la tabla.

Caso de Uso 16: Buscar en Base de Datos opciones de búsqueda del

parámetro.


Fecha: 12-01-2017

Descripción:

El sistema muestra los datos que pueden ser usados como filtros de búsqueda.

Actor: Sistema.

Requerimientos:


Pre Condiciones:


El Sistema debe tener registrados en tablas los módulos.





1. El sistema busca en la tabla del

parámetro datos para realizar un

filtro de búsqueda.

2. El sistema presenta los datos del

filtro.

117

Post Condiciones:

El sistema muestra los datos que son utilizados como filtros de búsqueda.

Caso de Uso 17: Buscar Datos Guardados en la tabla del parámetro.


Fecha: 12-01-2017

Descripción:

El sistema busca en la tabla del parámetro datos existentes.

Actor: Sistema.

Requerimientos:


Pre Condiciones:






1. El sistema busca en la tabla del

parámetro datos para realizar un

filtro de búsqueda.

2. El sistema presenta los datos del

filtro.

Post Condiciones:

El sistema muestra los datos que son utilizados como filtros de búsqueda.

Caso de Uso 18: Llenar formulario de búsqueda.


Fecha: 12-01-2017

118

Descripción:

El usuario, llena el formulario para realizar la búsqueda.


Requerimientos:

Ninguno.

Pre Condiciones:






1. El usuario ingresa los datos de

búsqueda del parámetro de

acuerdo a su criterio.

1.1 El usuario escoge una opción del filtro

inicial para que se despliegue el

buscador de acuerdo a la opción

escocida. Retorna al paso 1.

2. El usuario hace clic en el botón de

buscar.

Post Condiciones:

El sistema muestra los resultados de la búsqueda.

Caso de Uso 19: Mostrar Resultados.


Fecha: 12-01-2017

Descripción:


Actor: Sistema.

Requerimientos:

RF13 Resultados de la búsqueda de Datos.

119

Pre Condiciones:


Deben existir datos ingresados en la tabla.


El usuario debe haber introducido los datos al buscador.

El Usuario debe haber hecho clic en el botón Buscar.



1. El sistema hace una búsqueda con

los datos del buscador (ver paso 2

del caso de uso 20.)

1.1 El sistema muestra todos los datos

existentes en la tabla cuando el

usuario hace clic en el botón limpiar

datos (ver paso 3 del caso de uso 15).

Retorna a 1

2. El sistema muestra en la misma

página el buscador con los datos

ingresados por el usuario (ver

paso 3 del caso de uso 14) y una

tabla con los resultados de la

búsqueda junto con opciones de

modificación, y eliminación (ver


Post Condiciones:

Ninguno

Caso de Uso 20: Buscar datos en la tabla parámetro.


Fecha: 12-01-2017

Descripción:


Actor: Sistema.

120

Requerimientos:


Pre Condiciones:









1. El sistema captura la información

del buscador.


los datos del buscador.

3. El sistema devuelve los datos

obtenidos en la búsqueda.

3.1 El sistema devuelve null cuando no

existen resultados para la búsqueda.

Post Condiciones:


Caso de Uso 21: Limpiar datos del formulario.


Fecha: 12-01-2017

Descripción:

El sistema limpia los datos del formulario y muestra los datos

Actor: Sistema.

Requerimientos:


Pre Condiciones:

121









1. El sistema captura la información

del buscador.


los datos del buscador.

3. El sistema devuelve los datos

obtenidos en la búsqueda.

3.1 El sistema devuelve null cuando no

existen resultados para la búsqueda.

Post Condiciones:

El sistema muestra el buscador sin datos.

Caso de Uso 22: Mostrar ventana Adición de Datos.


Fecha: 12-01-2017

Descripción:

El sistema muestra una ventana con el formulario de ingreso de nuevo dato.

Actor: Sistema.

Requerimientos:

RF15 Formulario de adicionar datos.

Pre Condiciones:




122


El Usuario debe haber hecho clic en el botón de adicionar dato.



1. El sistema crea una ventana

emergente para el ingreso de los

nuevos datos

2. El sistema presenta en una tabla el

formulario de ingreso (ver paso 3 del

caso de uso 23).

Post Condiciones:

El sistema ingresa el dato a la tabla parámetro.

Caso de Uso 23: Crear Formulario de Adición.


Fecha: 12-01-2017

Descripción:

El sistema muestra una ventana con el formulario de ingreso de nuevo dato.

Actor: Sistema.

Requerimientos:

RF15 Formulario de adicionar datos.

Pre Condiciones:








123


formulario.

2. El sistema genera los campos del

formulario con las columnas de la

tabla parámetro correspondiente,

junto con los botones de regresar

a la pantalla anterior y el botón

de registrar nuevo dato.

2.1 El sistema busca en la base de datos

información adicional si el dato a

ingresar la necesita. Va al paso 2.2.

2.2 El sistema crea los campos con la

información adicional recogida en la

base de datos. Va al paso 3.

3. El sistema genera el formulario de

ingreso de nuevo datos, con los

campos anteriormente citados.

Post Condiciones:

El sistema muestra la ventana de adición de datos.

Caso de Uso 24: Llenar Formulario


Fecha: 12-01-2017

Descripción:

Usuario llena el formulario de registro de un nuevo dato.


Requerimientos:

RF15 Registrar nuevo dato.

Pre Condiciones:






El sistema debe haber creado el formulario.


124


1. El usuario llena el formulario con

los datos a ingresar a la tabla

parámetro.

2. El usuario hace clic en el botón

Registrar nuevo dato.

3. El sistema verifica los datos del

formulario (ver paso 2 del caso de

uso 25).

3,1 El sistema muestra un mensaje

indicando que los datos no pueden ser

escritos en la tabla, cuando no se

puedan ingresar dichos datos (ver paso

2.1 del caso de uso 25). Retorna al

paso 1.

Post Condiciones:

El sistema ingresa los datos a la tabla.

Caso de Uso 25: Adicionar Datos.


Fecha: 16-01-2017

Descripción:

El sistema registra el dato en la tabla parámetro.

Actor: Sistema.

Requerimientos:

RF16 Registrar nuevo dato.

RF17 Mensaje de Registro exitoso.

Pre Condiciones:





125

El usuario debe haber ingresado los datos al formulario.




1. El sistema captura los datos del

formulario cuando el usuario hace

clic en el botón de adicionar dato.

1.1 El sistema genera un mensaje de error

indicándole al usuario que no existen

datos ingresados al formulario,

cuando los campos de este estén

vacíos. Retorna a paso 1.

2. El sistema verifica los datos

capturados para ver si es posible

registrarlos en la tabla.

2.1 El sistema genera un mensaje de error

cuando los datos no pueden ser

ingresados. Retorna a 1.

3. El sistema registra los datos en la

tabla.

4. El sistema genera un mensaje

indicándole al usuario como

finalizó el proceso de registro.

Post Condiciones:

El sistema confirma el registro de los datos al usuario.

Caso de Uso 26: Confirmar Adición de Datos.


Fecha: 16-01-2017

Descripción:

El sistema muestra un mensaje confirmando que se registró los datos en la tabla.

Actor: Sistema.

Requerimientos:

RF15 Mensaje de registro exitoso.

126

Pre Condiciones:









1. El sistema captura la respuesta del

registro de los datos.

1.1 El sistema captura como “false” el

registro de los datos, ya sea porque

la sesión finalizó, otro usuario

ingresó al mismo tiempo el mismo

dato y el sistema registro primero

el otro, se perdió la conexión con la

base de datos, u otros problemas.

Va a 2.1.

2. El sistema genera un mensaje de que

indica el éxito en el registro.

2.1 El sistema genera un mensaje que

indica fracasó el registro. Va a 3.

3. El sistema muestra el mensaje en

pantalla.

Post Condiciones:

El sistema retorna a la pantalla del parámetro.

Caso de Uso 27: Mostrar ventana Modificación de datos.


Fecha: 16-01-2017

Descripción:

El sistema muestra una ventana con el formulario de modificación del dato.

Actor: Sistema.

127

Requerimientos:

RF19 Formulario de Modificación de datos.

Pre Condiciones:





El Usuario debe haber hecho clic en el botón de modificar dato.



1. El sistema crea una ventana

emergente para la modificación de

los datos

2. El sistema presenta en una tabla el

formulario de modificación (ver


Post Condiciones:

El sistema modifica el dato en la tabla parámetro.

Caso de Uso 28: Crear Formulario de Modificación.


Fecha: 16-01-2017

Descripción:

El sistema muestra una ventana con el formulario de modificación del dato.

Actor: Sistema.

Requerimientos:


Pre Condiciones:


128




El Usuario debe haber hecho clic en el botón de modificación del dato.




formulario.

2. El sistema genera los campos del

formulario con las columnas de la

tabla parámetro correspondiente,

junto con los botones de regresar

a la pantalla anterior y el botón

de modificación.

2.1 El sistema busca en la base de datos

información adicional si el dato a

modificar la necesita. Va al paso 2.2.

2.2 El sistema crea los campos con la

información adicional recogida en la

base de datos. Va al paso 3.

3. El sistema genera el formulario de

modificación de datos, con los

campos anteriormente citados.

4. El sistema busca en la tabla la

información de ese dato (ver paso

2 del Caso de Uso 30).

5. El sistema llena el formulario con

la información capturada (ver

paso 4 del Caso de Uso 30).

6. El sistema presenta el formulario

con la información del dato a

modificar.

Post Condiciones:

El sistema muestra la ventana de modificación de datos.

Caso de Uso 29: Buscar dato del parámetro en la tabla.

129


Fecha: 16-01-2017

Descripción:

El sistema busca la información del dato en la tabla.

Actor: Sistema.

Requerimientos:


Pre Condiciones:





El Usuario debe haber hecho clic en el botón de modificación del dato.



1. El sistema recibe el identificador del

dato seleccionado.

2. El sistema busca con el identificador

la información del dato en la tabla.

3. El sistema captura esa información.

4. El sistema devuelve la información

capturada.

Post Condiciones:

El sistema muestra la ventana de modificación de datos.

Caso de Uso 30: Modificar datos Formulario


Fecha: 12-01-2017

130

Descripción:

El usuario modifica la información del formulario.


Requerimientos:

RF18 Modificación de Datos.

Pre Condiciones:





El Usuario debe haber hecho clic en el botón de modificar el dato.

El sistema debe haber creado el formulario.



1. El usuario modifica el formulario con

los datos a cambiar en la tabla

parámetro.


modificar dato.

3. El sistema verifica los datos del

formulario (ver paso 2 del caso de

uso 32).

3.1 El sistema muestra un mensaje

indicando que los datos no pueden

ser modificados en la tabla, cuando

no se puedan ingresar dichos datos

(ver paso 2.1 del caso de uso 32).

Retorna al paso 1.

Post Condiciones:

El sistema modifica los datos en la tabla.

Caso de Uso 31: Modificar Datos.


131

Fecha: 16-01-2017

Descripción:

El sistema modifica el dato en la tabla parámetro.

Actor: Sistema.

Requerimientos:

RF18 Modificación de dato.

RF19 Mensaje de modificación exitoso.

Pre Condiciones:





El usuario debe haber modificado los datos al formulario.




1. El sistema captura los datos del

formulario cuando el usuario hace

clic en el botón de modificar dato.

1.1 El sistema genera un mensaje de

error indicándole al usuario que no

existen datos ingresados al

formulario, cuando los campos de

este estén vacíos. Retorna a paso

1.

2. El sistema verifica los datos

capturados para ver si es posible

modificarlos en la tabla.

2.1 El sistema genera un mensaje de

error cuando los datos no pueden

ser modificados. Retorna a 1.

132

3. El sistema registra los cambios de los

datos en la tabla.

3.1 El sistema registra los cambios de

acuerdo a la selección que se

realiza en la tabla resultados de la

búsqueda (o resultados de los

datos ya ingresados en la tabla),

cuando exista en dicha tabla

control para realizar un cambio

específico. En este caso finaliza el

proceso de modificación cuando se

realice los cambios, a espera que se

modifique otro dato.

4. El sistema genera un mensaje

indicándole al usuario como finalizó

el proceso de modificación. (ver paso

3 del caso de uso 26).

Post Condiciones:

El sistema confirma el registro de los cambios de los datos al usuario.

Caso de Uso 32: Confirmar Modificación de Datos.


Fecha: 16-01-2017

Descripción:

El sistema muestra un mensaje confirmando que se modificó los datos en la tabla.

Actor: Sistema.

Requerimientos:

RF19 Mensaje de modificación exitoso.

133

Pre Condiciones:









1. El sistema captura la respuesta del

registro de los datos.

1.1 El sistema captura como “false” el

registro de los datos, ya sea porque

la sesión finalizó, otro usuario

modificó al mismo tiempo el mismo

dato y el sistema modificó primero

el otro, se perdió la conexión con la

base de datos, u otros problemas.

Va a 2.1.

2. El sistema genera un mensaje de que

indica el éxito en el registro de los

cambios.

2.1 El sistema genera un mensaje que

indica fracasó el registro de los

cambios. Va a 3.

3. El sistema muestra el mensaje en

pantalla.

Post Condiciones:

El sistema retorna a la pantalla del parámetro.

Caso de Uso 33: Eliminar Dato.


Fecha: 16-01-2017

Descripción:

El sistema muestra un mensaje confirmando que se modificó los datos en la tabla.

134


Requerimientos:

RF20 Eliminación de Datos.

Pre Condiciones:








eliminar.

2. El sistema elimina el dato en la tabla. 2.1 El sistema modifica el valor de la

columna “Estado” de “Activo” a

“Inactivo” cuando el dato no se

pueda eliminar por cuestiones de

ley o sea un dato que se requiere

para un histórico.

3. El sistema deja de mostrar el dato en

el la tabla de resultados de la

búsqueda y en la tabla de datos ya

almacenados en la tabla.

3.1 El sistema muestra el estado

“inactivo” en la columna “Estado”

de tabla de resultados de la

búsqueda y en la tabla de datos ya

almacenados en la tabla.

Post Condiciones:

El sistema muestra los cambios en la pantalla del parámetro.

135

ANEXO C. DIAGRAMAS DE SECUENCIA

Este anexo contiene los diagramas de secuencia empleados para ilustrar el comportamiento entre el usuario y el sistema.

Diagrama de Secuencia 1. Enlace al AdminSIIS

Diagrama de Secuencia 2. Autenticación

136

Diagrama de Secuencia 3. Seleccionar Empresa en AdminSIIS

Diagrama de Secuencia 4. Asignación de Permisos del AdminSIIS

137

Diagrama de Secuencia 5. Menú de Procesos

Diagrama de Secuencia 6. Menú de Módulos

Diagrama de Secuencia 7. Menú de Opciones de parametrización

Diagrama de Secuencia 8. Permisos del Módulo

138

Diagrama de Secuencia 9. Buscador de Datos del Parámetro.

Diagrama de Secuencia 10. Resultado de la Búsqueda de Datos

139

Diagrama de secuencia 11. Formulario de Adicionar Datos

Diagrama de Secuencia 12. Registro de un nuevo Dato

140

Diagrama de Secuencia 13. Formulario de Modificación de Datos.

Diagrama de Secuencia 14. Modificación de Datos.

141

ANEXO D. DIAGRAMA DE CLASES

En este anexo se muestra la interacción lógica del módulo mediante el diagrama de clases.

desarrollo del mÓdulo de parametrizaciÓn del … · contexto y que son almacenados de manera...

Documents