DISEÑO Y DESARROLLO DEL SOFTWARE MATIS “MODELO DE A TENCION INTEGRAL SISTEMATIZADA” PARA LA UNIDAD DE TECNOLOGI A

INFORMATICA DE COOMEVA

MARIO ANDRÉS RAMÍREZ NAVARRO DIEGO FERNANDO GARCÉS IBÁÑEZ

UNIVERSIDAD AUTÓNOMA DE OCCIDENTE FACULTAD DE INGENIERÍA

DEPARTAMENTO DE CIENCIAS DE LA INFORMACIÓN PROGRAMA INGENIERÍA INFORMÁTICA

SANTIAGO DE CALI 2008

2

DISEÑO Y DESARROLLO DEL SOFTWARE MATIS “MODELO DE A TENCION INTEGRAL SISTEMATIZADA” PARA LA UNIDAD DE TECNOLOGI A

INFORMATICA DE COOMEVA

MARIO ANDRÉS RAMÍREZ NAVARRO DIEGO FERNANDO GARCÉS IBAÑEZ

Pasantía para optar al título de Ingeniero Informát ico

Director MIGUEL JOSÉ NAVAS JAIME

Ingeniero de Sistemas

UNIVERSIDAD AUTÓNOMA DE OCCIDENTE FACULTAD DE INGENIERÍA

DEPARTAMENTO DE CIENCIAS DE LA INFORMACIÓN PROGRAMA INGENIERÍA INFORMÁTICA

SANTIAGO DE CALI 2008

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 Industrial

MIGUEL JOSÉ NAVAS JAIME Director

Santiago de Cali, 26 de Julio de 2008

4

CONTENIDO

Pág.

GLOSARIO 8 RESUMEN 10 INTRODUCCIÓN 11 1. PLANTEAMIENTO DEL PROBLEMA

13

2. MARCO TEÓRICO

15

3. ANTECEDENTES

18

4. OBJETIVOS

19

5. JUSTIFICACION

20

6. METODOLOGÍA

21

7. DESARROLLO DEL PROYECTO

22

8. ANALISIS DE IMPACTO DE ADMISIONES Y PROGRAMACION

28

9. CRONOGRAMA DE ACTIVIDADES

38

10. PRESUPUESTO

39

11. CONCLUSIONES

40

BIBLIOGRAFÍA

41

5

LISTA DE TABLAS Pág.

Tabla 1. Recurso Humano 39 Tabla 2. Recursos Varios 39 Tabla 3. Presupuesto General 39 Tabla 4. Análisis de Impacto 28

6

LISTA DE GRAFICOS

Pág. Grafico 1: Estructura de carpetas que se utiliza pa ra realizar las aplicaciones en PHP.

23

Grafico 2: Arquitectura de PHP desarrollada por la UTI 25 Grafico 3: Plataformas de Construcción del Aplicati vo 26

7

LISTA DE ANEXOS

ANEXO A. ver archivo adjunto Anexo A ANEXO B. ver archivo adjunto Anexo B

8

GLOSARIO

PHP (ACRÔNIMO DE “PHP: HYPERTEXT PREPROCESSOR”): es un lenguaje de programación muy potente que, junto con HTML, permite crear sitios web dinámicos. Php se instala en el servidor y funciona con versiones de Apache, Microsoft IIS, Netscape Enterprise Server y otros. La forma de usar php es insertando código php dentro del código HTML de un sitio web. Cuando un cliente (cualquier persona en la web) visita la página web que contiene éste código, el servidor lo ejecuta y el cliente sólo recibe el resultado. Su ejecución, es por tanto en el servidor, a diferencia de otros lenguajes de programación que se ejecutan en el navegador. Php permite la conexión a numerosas bases de datos, incluyendo MySQL, Oracle, ODBC, etc. Y puede ser ejecutado en la mayoría de los sistemas operativos (Windows, Mac OS, Linux, Unix).

ORACLE: es manejador de base de datos relacional que hace uso de los recursos del sistema informático en todas las arquitecturas de hardware, para garantizar su aprovechamiento al máximo en ambientes cargados de información. Fabricado por Oracle Corporation. Se considera a Oracle como uno de los sistemas de bases de datos más completos, destacando su: • Soporte de transacciones. • Estabilidad. • Escalabilidad. • Es Multiplataforma. PL/SQL: lenguaje de programación embebido en Oracle y PostgreSQL. El PL/SQL soporta todas las consultas y manipulación de datos que se usan en SQL, pero incluye nuevas características: • El manejo de variables. • Estructuras modulares. • Estructuras de control de flujo y toma de decisiones. • Control de excepciones. El lenguaje PL/SQL está incorporado en:

9

• Servidor de la base de datos. • Herramientas de Oracle (Forms, Reports,...).

En un entorno de base de datos los programadores pueden construir bloques PL/SQL para utilizarlos como procedimientos o funciones, o bien pueden escribir estos bloques como parte de scripts SQL*Plus. Los programas o paquetes de PL/SQL se pueden almacenar en la base de datos como otro objeto, y todos los usuarios que estén autorizados tienen acceso a estos paquetes. Los programas se ejecutan en el servidor para ahorrar recursos a los clientes.

10

RESUMEN

El proyecto planteado en este documento, consiste en el desarrollo de un software encargado de automatizar todos los procesos operativos de la empresa Hospital en Casa S.A. (Empresa perteneciente a Coomeva), buscando agilizar las actividades realizadas por ésta, eliminando procesos generados por la forma manual en la que opera hoy en día, reduciendo las cargas operativas de sus colaboradores y permitiendo generar información confiable y oportuna para sus clientes internos y externos, dejando registros de todos los cambios a través del tiempo.

La tecnología está basada en una arquitectura Web que pueda administrar los procesos en tiempo real desde diferentes puestos de trabajo, comunicándose entre sí mediante una red local e internet.

Además este proyecto proveerá el apoyo de proceso de fusión de la empresa con Medellín y se podrá operar desde cualquier lugar del país convirtiéndose en una herramienta de manejo nacional.

11

INTRODUCCION

En la actualidad las aplicaciones informáticas han evolucionado de manera extraordinaria con relación a otros estudios; en menos de un siglo hemos pasado de aplicaciones locales estacionadas en cada PC, ha aplicaciones cliente servidor estacionadas en un computador central y accedidas a él remotamente a través de intranet ó Internet. El presente proyecto consiste en el diseño y desarrollo de un software encargado de automatizar todos los procesos operativos de la empresa Hospital en Casa S.A. (Empresa perteneciente a Coomeva), buscando agilizar las actividades realizadas por ésta, eliminando procesos generados por la forma manual en la que opera hoy en día; reduciendo las cargas operativas de sus colaboradores y permitiendo generar información confiable y oportuna para sus clientes internos y externos, dejando registros de todos los cambios a través del tiempo. En la industria médica también se usan las aplicaciones cliente servidor con sus accesos remotos, sin embargo las operaciones médicas, las urgencias hospitalarias y las diligencias a domicilio (ambulancias, consultas, etc.) presentan situaciones específicas más difíciles de parametrizar. Por lo que el proyecto contempla el estudio desde la óptica médica, tal que por medio de entrevistas, a las personas encargadas de manejar este tipo de procesos, permita clasificar las operaciones más comunes de esta industria. Además este proyecto proveerá el apoyo de proceso de fusión de la empresa con Medellín y se podrá operar desde cualquier lugar del país convirtiéndose en una herramienta de manejo nacional. La UTI∗ (Unidad de Tecnología Informática), filial de Coomeva, es quien se encarga del desarrollo de aplicaciones, soporte y estudios de los diferentes proyectos informáticos que desarrolla el grupo de empresas que conforman Coomeva. Es así como la UTI, se encarga del desarrollo de la etapa de análisis y metodología del presente proyecto. Las etapas de construcción y de pruebas del software se realiza por las empresas, Geniar Web S.A y Finding Solutions, contratadas por la UTI.

∗ Unidad Tecnología Informática, una de las empresas pertenecientes a Coomeva. Aunque las empresas de Coomeva tienen sus divisiones de informática, esta empresa es la encargada de realizar o gestionar todos los proyectos informáticos relacionados con las empresas de Coomeva.

12

Geniar Web S.A, inició servicios en 2006; y ofrece desde entonces servicios especializados para la alineación y aplicación de tecnología informática y de inteligencia de negocios. Finding Solutions, es una empresa radicada en Parquesoft que se encarga de realizar labores de testeo y evaluación de aplicaciones en sus fases finales antes de pasar a producción. Se pretende entonces lograr la planeación y construcción de un software capaz de cumplir con las expectativas de los clientes finales; mediante un trabajo que realizado en conjunto con las empresas desarrolladoras permita finalmente el éxito del proyecto.

13

1. PLANTEAMIENTO DEL PROBLEMA

Las empresas hoy en día están descubriendo que la información de éstas, son el activo más importante de la organización y Hospital en Casa, así lo entiende. Es por ello que reconoce los errores que se estaban presentando por el mal manejo de todos sus procesos de información, para esto busca una solución tanto eficaz como eficiente a los conflictos enfrentados.

Hospital en Casa, almacena toda su información en tablas de Excel y papelería concernientes a las mismas, en archivadores que ocupan un gran volumen. Con el transcurso del tiempo, esta labor se ha convertido en un trabajo difícil de ejecutar, ya que es necesario realizar visitas o establecer comunicación con los usuarios y entidades para actualizar los datos y cumplir con todos sus compromisos. La UTI se encarga de presentar una solución inicial a la empresa, así como la de realizar los documentos de requerimientos funcionales y no funcionales, mapas de prueba, casos de uso, diseño de interfaz, modelo de datos, modelo de negocio y el análisis de impacto, es decir la fase inicial de construcción del proyecto. La segunda fase de desarrollo del proyecto es la fase de construcción del software, la cual de acuerdo a los documentos proporcionados por la UTI, es la etapa del manejo algorítmico y programático del proyecto MATIS. Esta fase es subcontratada a través de otra empresa, la cual presenta una solución que no da cumplimiento a los requerimientos planteados inicialmente por la UTI en la primera fase. Esto provocó grandes atrasos del proyecto, obligando finalmente que la UTI replanteara el proyecto y presentara una nueva convocatoria para la contratación de una nueva empresa; en esta ocasión Geniar Web S.A. es la encargada. Estos problemas traen como consecuencia que la aplicación MATIS, tenga que iniciar su desarrollo casi desde cero, siguiendo nuevos requerimientos supervisados directamente por la UTI. Se pretende soportar las operaciones de Hospital en Casa S.A. a través de procesos sistematizados organizados en módulos. Actualmente se han modificado totalmente los módulos de Facturación y Tesorería. Estos módulos son de vital importancia para la organización y son los que Geniar Web considera útiles para hallar la mejor solución a los conflictos que en la actualidad se están presentando.

14

Algunos de los interrogantes que se plantean son: ¿Será factible la incursión en este tipo de modalidad de aplicaciones Web, para empresas con finalidades medicas?, ¿La implementación de una plataforma Web Hospitalaria es económicamente viable?, ¿Se adaptaran todos los usuarios a este tipo de tecnología?

15

2. MARCO TEÓRICO

El uso de sistemas de información facilita el desempeño funcional de las empresas, el presente proyecto pretende desarrollar una aplicación que administre y gestione dichos sistemas de información. La tecnología está basada en una arquitectura Web que pueda administrar los procesos en tiempo real desde diferentes puestos de trabajo, comunicándose entre si mediante una red local.

Para la realización de este proyecto la Unidad de Tecnología Informática (UTI), encarga a la empresa Geniar Web S.A. del análisis y desarrollo de los requerimientos y casos de usos que previamente fueron obtenidos. Para esto se basan en el estándar de desarrollo de PL/SQL y PHP. El estándar de desarrollo de PL/SQL y PHP es una herramienta fundamental de la UTI, que permite junto con la metodología de desarrollo, garantizar la calidad de sus productos, el trabajo productivo y la distribución del conocimiento tecnológico a todos los analistas de sistemas que la conforman. Este proyecto retomará la experiencia alcanzada durante los últimos años en el desarrollo de Software en COOMEVA S.A. y permitirá establecer las normas para identificar, mantener y solucionar aspectos técnicos de las aplicaciones, de manera eficiente y eficaz. Para el Análisis del sistema, la Unidad de Tecnología Informática (UTI) preparó una entrevista detallada conforme a resolver los planteamientos que permiten construir las ideas que dieran forma al proyecto, basados en los detalles obtenidos se recogieron los requerimientos básicos para soportar el proyecto, así de acuerdo con las respuestas obtenidas en la entrevista se establecieron reuniones con los clientes para definir los detalles de la aplicación. Con la información obtenida se da paso a un proceso denominado Ingeniería de Requerimientos donde son clasificados, validados y examinados minuciosamente dependiendo del alcance y los objetivos planteados. El modelo de Ingeniería de Software que se decide utilizar para el desarrollo de este proyecto es el Modelo en Espiral ya que permite ir avanzando en el proceso mientras se definen los objetivos en un ciclo creciente llegando de manera inmediata a la planificación para luego establecer el desarrollo con sus respectivas pruebas y finalmente hacer un análisis de riesgos que evalúe su integridad.

16

En el momento de querer reforzar en un aspecto dentro del ciclo se puede hacer simplemente identificando los aspectos que lo conforman como la estructura del sistema, la funcionalidad de sus componentes y por supuesto la adaptación al medio en que se manejará. Es importante aclarar que este método permite un desarrollo mucho más flexible pero la estabilidad del mismo depende del correcto planteamiento de los requerimientos ya que si no están bien definidos puede ocasionar ciclos interminables originando así inconsistencia durante los procesos de análisis y diseño. Al definir los requerimientos del sistema y decidir cual es el modelo adecuado, se establecen los casos de uso, los cuales corresponden a las opciones o funcionalidades del software, donde los usuarios accederán para su manejo y donde se definen que usuarios o actores tendrán accesibilidad a las opciones establecidas, se crea un diagrama denominado diagrama de casos de uso, el cual permite señalar que usuarios accederán a determinadas opciones del software. Para describir en forma detallada la estructura funcional de la aplicación, es necesario realizar una secuencia de pasos para cada caso de uso donde se describen las acciones realizadas por el usuario al acceder a este, con el fin de brindar una comprensión detallada de cada función definiendo las acciones, mensajes, restricciones y caminos alternos presentes en cada opción del software. Definir correctamente los casos de uso con su respectiva especificación, permite que se le dé al sistema una estructura, para ello es necesario crear un diagrama para cada caso de uso, denominado diagrama de clase, donde utilizando un análisis orientado a objetos se establecen los componentes que lo conforman junto con las relaciones entre cada elemento el cual se estructura como una clase que lógicamente posee atributos específicos y algunos con métodos que establecen su ejecución. El estándar de desarrollo creado por Coomeva no contempla el uso de diagramas para el desarrollo de los casos de uso. Ahora, ya con la definición del análisis del sistema, se inicia la etapa de realización de su respectivo diseño, para ello es necesario contar un una estructura bien definida. Ahora como ya se conoce la estructura de la aplicación se puede realizar el diseño de la base de datos (Modelo Entidad/Relación) cuyo modelo esta basado en los diagramas de clases y se establece en forma de entes y relaciones cuyo fin es definir el almacenamiento y el control de la información dentro de la aplicación. El Sistema Gestor de Base de Datos que se utilizará en este proyecto es Oracle 9i ya que es el que se maneja en el servidor donde se implementará la aplicación, para ello hay que convertir el (MER) Modelo Entidad Relación nombrado anteriormente a un conjunto de instrucciones en el lenguaje SQL, además en este gestor se va ha llevar ha cabo la lógica del negocio a través de funciones y procedimientos almacenados en PL/SQL, para proceder a crear el enlace que

17

interpreta el acceso a la base de datos por parte de la aplicación denominado ODBC. El lenguaje de programación escogido para el desarrollo es PHP el cual da la posibilidad de crear una aplicación Web dinámica y fácil de mantener. La implementación de la aplicación se hará directamente en Coomeva para poder tener acceso a los datos y al cliente más fácilmente. Las pruebas tanto de caja blanca como caja negra que se realizaran, tendrán como fin evaluar la integridad y funcionalidad del sistema corrigiendo aquellos detalles que llevan a un manejo incorrecto de los datos, una ejecución insuficiente o una deficiente comprensión de la información que se quiera acceder.

18

3. ANTECEDENTES Hospital en Casa es una empresa de servicios de salud domiciliarios con un equipo interdisciplinario de profesionales y técnicos debidamente capacitados y entrenados, respaldados con la tecnología e insumos necesarios, brindando con calidad, calidez y oportunidad atención medica de rehabilitación y de enfermería confiable en la comodidad y el amor del hogar de los pacientes, contribuyendo así a su pronta recuperación.

Su nacimiento se remonta al año 1997 como Cuidado Hospitalario Domiciliario Home Care, que en 2004 cambia su razón social a Hospital en Casa S.A.

Bajo el liderazgo gerencial de el Dr. Fabián Osorio, existe un equipo humano conformado por 270 personas entre personal asistencial y administrativo.

Cuando una enfermedad le permite al paciente recuperarse en casa, le exige una larga permanencia intra-hospitalaria o cuidados especiales, es por esto que a través de esta empresa se cuenta con el recurso humano y el respaldo tecnológico que hacen posible el tratamiento en el hogar.

La empresa Hospital en Casa maneja actualmente sus procesos médicos, contables, financieros y operacionales de manera manual a través de hojas de Excel y archivos manuales, lo cual deja una información no muy confiable la cual causa problemas y malos entendidos en la empresa, además esta propensa ha errores y ha malas interpretaciones tanto de los usuarios como de los beneficiarios de la empresa. Hospital en Casa S.A. vio la necesidad de sistematizar sus procesos para la solución a estos problemas. Debido a la naturaleza de esta empresa y del modelo de negocio no existen aplicaciones en el mercado tanto a nivel nacional como internacional que cumplan con todas las especificaciones que el proyecto MATIS cubre según Hospital en Casa S.A. En este caso este proyecto sería el primero en satisfacer las necesidades de las empresas prestadoras de servicios de salud domiciliarios en cuanto a la sistematización de sus procesos.

19

4. OBJETIVOS

4.1. OBJETIVO GENERAL

Analizar y desarrollar un sistema de información para la Unidad de Tecnología Informática de Coomeva, tal que permita la automatización de los procesos operativos de Hospital en Casa S.A.

4.2. OBJETIVOS ESPECIFICOS

• Realizar el análisis de los requerimientos y casos de uso de los módulos de facturación y tesorería.

• Impactar los requerimientos para que cumplan con las especificaciones y objetivos planteados por parte de los analistas y el cliente.

• Implementar los casos de usos desarrollados después de la fase de revisión, utilizando los lenguajes de programación previamente seleccionados por la UTI.

• Corregir las posibles no conformidades que se presenten en el desarrollo de los casos de uso.

20

5. JUSTIFICACION

Con la elaboración de este proyecto, se mejoraran los movimientos actuales de la empresa haciendo estos más ágiles, con información segura y con una mayor precisión ya que se automatizara el proceso de registro, mantenimiento y funcionamiento legal, laboral y financiero así: En el proceso de registro se van ha desarrollar las actividades y los procesos en internet directamente, esto significa que las validaciones financieras y legales de los clientes serán casi automáticas agilizando el proceso poder ofrecer los servicios con mayor rapidez. En el proceso de mantenimiento ya que la lógica de negocio de la aplicación se maneja a través de la base de datos y esta maneja unos procedimientos automáticos que liberan memoria en el servidor y agilizan el tiempo de respuesta hacia la aplicación, además debe ejecutar todos los procesos financieros en un proceso nocturno para ejecutar las transacciones y demás movimientos que transcurrieron en el día laboral durante la noche donde la aplicación no este tan congestionada. En el funcionamiento legal porque todas las operaciones y actividades de la aplicación están debidamente soportadas y validadas según los requerimientos de la UTI, por ende se manejaran los pagos de impuestos y cartera con mas fiabilidad de que son datos verídicos y soportados por los procesos legales vigentes ha la fecha. En el funcionamiento laboral puesto que todos los movimientos de los empleados y usuarios de la herramienta siguen un proceso de auditoria en el cual se evalúa su desempeño durante las horas laborales, así se pueden medir fortalezas y debilidades en el personal para tener más claridad al hacer operaciones que los afecten. En el funcionamiento financiero porque todos los movimientos que involucren manejos de activos se manejan a través de la aplicación dándonos una perspectiva global de las transacciones de la empresa evitando problemas de desfalcos ó descuadres y mejorando la calidad de servicio hacia el cliente final que podrá manejar todas sus transacciones con mayor rapidez y confianza. Este proyecto significa un salto hacia el siguiente nivel en el manejo de aplicaciones de salud, brindando soporte, agilidad, confiabilidad y sobretodo calidad de servicio.

21

6. METODOLOGÍA

Para el desarrollo del proyecto se tienen como base el levantamiento de requerimientos y casos de uso hechos previamente por la UTI, encargados de esta parte del proceso.

La primera etapa arranca con el análisis y conocimiento del negocio, como funciona Hospital en Casa S.A. y cuales son los procedimientos y módulos que poseen. Lo más importante como integrantes de Geniar Web S.A. es entender el modelo de negocio para poder hacer una evaluación detallada del proyecto en si.

En la segunda etapa del proyecto se analizarán los requerimientos levantados por la UTI. Ellos han elaborado los casos de uso correspondientes a los requerimientos. En esta etapa se evaluarán los casos de uso para su posterior puesta en desarrollo. El proyecto se basará en el estándar de desarrollo de Coomeva, donde los diagramas no serán necesarios, pero en caso tal de tener que modificar alguno de los requerimientos, será necesario utilizar un formato de impacto de requerimientos. En este documento serán recopilados todos los cambios realizados por requerimiento. La tercera etapa será la etapa de desarrollo, utilizando los lenguajes de programación PHP y PL/SQL, se empezará a construir las funcionalidades definidas en los requerimientos y casos de usos. En la cuarta y última etapa se solucionaran las posibles no conformidades que se presenten en el desarrollo de los casos de uso. Finalmente, la empresa Finding Solutions S.A. contratada por Coomeva será la encargada de realizar las pruebas respectivas a la aplicación.

22

7. DESARROLLO DEL PROYECTO Se inicia la primera etapa del proyecto con un análisis del negocio. Se realizaron varias charlas y se observaron varios videos en los cuales se explicó el funcionamiento operativo de Hospital en Casa S.A y cómo iba a afectar el uso de este nuevo aplicativo a la organización. Ya que el funcionamiento de este tipo de empresas es muy complejo, por lo que esto tomó varios días para lograr el entendimiento del negocio y así dar paso a la siguiente etapa. En la segunda etapa se hace una evaluación de los requerimientos y casos de uso de los módulos asignados (Facturación y Tesorería). Se revisaron cada uno de los requerimientos y fueron evaluados tal que los casos de uso creados estuvieran de acuerdo con las funcionalidades expuestas en los requerimientos (ver Anexo A y B ). Esto arrojó algunas incompatibilidades, lo cual obligó a generar actas conocidas como análisis de impacto. En este tipo de actas se generan los cambios que se consideren necesarios por el analista, tanto en los requerimientos como en los casos de uso, cuando al hacer un análisis de este tipo de documentos con el usuario faltan funcionalidades o especificaciones. El módulo de Facturación fue el que más análisis de impacto generó ya que cuando la empresa Geniar Web entró a ser parte del proyecto, este tenía más de un año de atraso. Esto obligó a hacer una revisión más exhaustiva de los requerimientos ya levantados, lo que evidenció varios cambios que eran necesarios en las funcionalidades requeridas (ver Anexo B ). Estos cambios son evaluados por los demás analistas y el coordinador del proyecto y para ser aprobados y pasar a ser desarrollados. Para iniciar la tercera etapa (Desarrollo) se tuvo en cuenta el estándar de programación de carrera que había sido igualmente desarrollado por la UTI, el cual se conformará de varias carpetas las cuales tenían un significado por cada una; dichos significados se muestran a continuación:

23

Grafico 1. Estructura de carpetas que se utiliza pa ra realizar las aplicaciones en PHP.

Model: Son las clases en PHP que se conectan con la base de datos e invocan los procedimientos almacenados donde se realiza la lógica del negocio. WEB: Es la carpeta donde se manejan las paginas HTML y los archivos java script cada una en una subcarpeta aparte. CVS: Esta carpeta es creada por el controlador de versiones de Coomeva, y nos proporcionan las versiones de todos los archivos que se encuentran ubicados en el proyecto en estos momentos, esta carpeta se encuentra en todas las subcarpetas del proyecto. PHP: Es la carpeta donde se encuentran la estructura de clases de en el lenguaje PHP, esa estructura fue desarrollada por la UTI y cada subcarpeta tiene un significado en especial: • Vista: En esta carpeta se manejan las clases PHP que operan las paginas HTML y en estas clases se invocan las acciones que se comunican con los modelos para consultar la base de datos.

• Acción: Tienen 2 funciones en especial, son las encargadas de la comunicación a través del facesconfig (Archivo de configuración en el cual se manejan las páginas y la comunicación entre ellas) y también se conectan con los modelos para invocar los procedimientos que van a modificar la base de datos.

24

• Control: Es el encargado de un poco lógica que se realiza sobre la aplicación y no sobre la base de datos, como validar valores y establecer reglas de negocio sobre el aplicativo evitan conectarse muy seguidamente a la base de datos.

• Form: Son clases encargadas de hacer validaciones antes o cambios en las páginas al realizar una operación sobre la base de datos, generalmente son utilizados cuando tocaba editar código HTML en el código php.

• Remote: Son clases que simulan la función de los controles, pero estos se usan cuando era necesario hacer un cambio en la pagina sin editar código HTML en php y era necesario hacer un submit o una recarga de la pagina, estas clases no recargan toda la pagina sino que solo lo que necesitamos. Estas funciones son las que se usaban antes del AJAX. BD: Es la carpeta donde se manejan todos y cada uno de los scripts de la base de datos y su jerarquía que corresponde al esquema de programación desarrollado por Coomeva, este es: • API (Interfaz de Programación de Aplicaciones): son procedimientos almacenados que conectan al aplicativo php con otro procedimiento llamado SNP en la base de datos encargado de realizar la modificación. • SNP (Solución de Negocios Proceso): son procedimientos almacenados que realizan los cambios en la base de datos a través de las CB. • CB (Compuerta Básica): son procedimientos almacenados los cuales son uno por tabla y hacen las operaciones básicas sobre cada tabla (adicionar, eliminar, modificar y consultar). • SND (Solución de Negocios Datos): son los procedimientos encargados de las consultas en la base de datos, estos generalmente se utilizan para realizar consultas que se deben mostrar en pantalla o que son necesitadas por los SNP para realizar validaciones ú operaciones en la base de datos de acuerdo a la lógica de negocio. (Estos últimos son los únicos que no son accedidos desde un API sino directamente de la clase modelo de PHP). Common: En esta carpeta se encuentran las librerías de smart y para el manejo de la memoria caché, las librerías de Adodb para conectarse e invocar procedimientos en la base de datos, las librerías de JSON para el manejo de AJAX y otras librerías como para manejo de archivos pdf o PHP. Config: se manejan dos archivos muy importantes, el save config que es donde están especificados los datos para conectarse a la base de datos y el facesconfig

25

el archivo de configuración encargado de manejar todas las acciones de la aplicación. Esta es la estructura básica del esquema de desarrollo en PHP desarrollado por la UTI. Grafico 2. Arquitectura de PHP desarrollada por la UTI

En este grafico se observan los posibles flujos de datos entre clases en el aplicativo, además que después de llegar al control pueden haber 2 posibles cursos: • Cuando la operación es Modificar, Eliminar ó Insertar información sobre la base de datos, se invoca una acción y esta invoca una función en el modelo que se conecta aun API de la base de datos y este a un SNP que hace las operaciones a través de las compuertas básicas y algunos SND.

• Cuando se va a consultar en la base de datos y estos se necesitan en una clase de PHP para realizar validaciones en el control, este se conecta al modelo y

26

este directamente a un SND que hace la consulta sin necesidad de ir a través de un API. También en el desarrollo del aplicativo se maneja un esquema de trabajo en el cual los gerentes de proyecto se reúnen con los coordinadores de la UTI y presentan un informe del desarrollo realizado en el momento y se establecen los tiempos de desarrollo por módulo, además se manejan tres plataformas de programación del aplicativo: Grafico 3. Plataformas de Construcción del Aplicati vo

• La plataforma de Desarrollo: en esta es donde se inician los desarrollos y se construye el aplicativo de acuerdo a los requerimientos y casos de uso planteados por la UTI.

• El análisis y diseño, en esta fase se entabla comunicación con el servidor de desarrollo a través de un controlador de versiones llamado CVS evitando que dos desarrolladores trabajen en una clase al mismo tiempo. • Plataforma de pruebas: Aquí se trasladan las clases del servidor de desarrollo al servidor de pruebas, el cual es realizado por la UTI; la empresa Finding Solutions S.A realiza las pruebas del aplicativo conectándose al servidor a través de Internet Explorer y reportando las no conformidades al equipo de desarrollo a través de los mapas de pruebas. • Plataforma de Producción: Al terminar las pruebas del aplicativo en el servidor de pruebas y ser evaluadas con cero no conformidades, la UTI pasa las clases del servidor de pruebas al servidor de producción, donde al terminar el aplicativo será accedido por los usuarios de Hospital en Casa a través del Internet Explorer conectándose a Internet ó la red interna de Cometa.

27

Cabe mencionar que cada plataforma tiene una base de datos distinta con datos distintos para no trabajar con datos basura sobre cada base de datos. El primer modulo fue el de Tesorería en el cual se desarrollan 45 de los 74 casos de uso generados para este módulo. Como el nivel de desarrollo no era tan avanzado, se desarrollaron los casos de uso con un nivel de complejidad medio, siempre respaldados por el coordinador de Geniar Web S.A. y siempre teniendo en cuenta el uso de estándar de desarrollo de Coomeva para la realización de los módulos. Se desarrolló el módulo de Facturación, al inicio de este modulo ya se contaba con mayores habilidades de desarrollo por lo que la responsabilidad pasó a casos de uso con complejidad más alta para su desarrollo. Se realizaron 25 de los 37 casos de uso de este módulo.

Al finalizar la etapa de desarrollo de los módulos asignados, se inicio la última etapa del proyecto de pruebas por parte de la empresa Finding Solutions S.A. Esta empresa se encargo de realizar las pruebas de la aplicación. Al hacerse esta revisión se fueron encontrando no conformidades las cuales eran reportadas en unas actas llamadas Mapa de Pruebas, los cuales contenían cada una de las pruebas realizadas a la funcionalidad desarrollada según el requerimiento. Las no conformidades reportadas podían ser de varios tipos: • Funcionales: Estas eran reportadas cuando la funcionalidad desarrollada no cumplía, según la prueba, con lo solicitado con el requerimiento.

• Presentación: Estas eran reportadas cuando en la interfaz grafica se observaban errores de ortografía los cuales debían ser corregidos.

• Mejora: Estas eran reportadas como su nombre lo indican como posibles mejoras que la empresa Finding Solutions S.A observaba. Estas no eran tan críticas como las anteriores y pasaban a ser discutidas por los coordinadores del proyecto.

Al final, se garantizó la calidad de la aplicación y fue certificada por la empresa responsable de hacer este proceso.

28

8. ANALISIS DE IMPACTO DE ADMISIONES Y PROGRAMACIO N Tabla 4. Análisis de impacto Proyecto: Matis RQMATIS20070410_602-Facturacion al Dia C.U CUMATIS20070515_201-Generar facturacion al dia Cambio

Tipo Descripción del Cambio Unidades relacionadas H ora

Entrega

PL/sql • Crear las funciones snd que devuelven los precios y costos en la programación. Nota : las consultas ya están hechas, pero están dentro del mismo snp como cursores explícitos. Por eso hay que pasarlas a Hoc_Sndbusicomfacturacion ademas de esto se han realizado cambios en la ubicación de proveedores y prestadores, por efectos de la agenda. Entonces hay que corregir los select. Nota : Validar que el modelo de liquidacion ya este listo. Antes de aplicar los cambios. Preguntar a Lily Arevalo.

Hoc_SnpLiquidateAdmission. pr_LiquidateAdmission.

3 4

PL/Sql • Crear una función que devuelva el valor total que debe

Hoc_Sndbusicomfacturacion

2 4

29

pagar el paciente en una admisión tipo paciente/entidad. Debe devolver el valor de todos los copagos+cuotas moderadoras + excedentes. En una admisión. Nota : ya existen los select como cursores explicitos, ubicarlos en la funcion. • Llamarla getSumPayPatient(codadmision) Ubicarla en : Hoc_Sndbusicomfacturacion

Hoc_SnpLiquidateAdmissi.pr_ pr_GenerateInvoiceByDay

Pl/Sql • Adicionar manejo de resoluciones x sucursal a la facturación. Nota : toda entidad que factura a través de un sistema tiene que pedir autorización para la numeración de sus facturas a la DIAN. • Se debe crear una tabla donde se registre las resoluciones x sucursal. adionando los campos no. resolución, rango aprobación, prefijo, fecha de expedición, etc. (Ver c.u.). (consultar con carlos si se utiliza la tabla de numeración) Nota : Esta tabla se llenara por el modulo de parametrizacion. • Crear una función llamada getDianAuthorization que devuelva los datos de la resolución (ver contrato)

Hoc_Sndbusicomfacturacion Hoc_SnpLiquidateAdmission. pr_LiquidateAdmission Hoc_SnpLiquidateAdmission. pr_GenerateInvoiceByDay

12

30

• Adicionar validación que verifique que el numero de la factura esta dentro del rango de aprobación autorizado por la DIAN en la resolución. • Adicionar campo de prefijo en la cabecera de la factura. Este prefijo estará en la tabla de resoluciones. (Confirmar con Carlos esto en el modelo).

PL/sql • Manejo de retenciones. Dice el requerimiento : “Esto es regulado por el estado y corresponde a un(os) porcentaje(s) de descuento por cada uno de los ietm prestados. El sistema debe calcular las retenciones con base en lo parametrizado por cada entidad y sucursal. Las retenciones dependen de las caracteristicas del cliente y del valor de la factura” Nota: Actualmente no hay soporte para esta funcionalidad. • Definir si la parametrizacion se realizara por item. O por tipos de items. (yo lo veo mas sencillo por item) Preguntar a Carlos que dijo el Contador respecto a las retenciones, esto había quedado pendiente. • Crear funcion que pasando un item el devuelva el % de retencion aplicable al item. Según tabla de parametrizacion. • Agregar la funcion en Hoc_SnpLiquidateAdmissio para

8

31

conseguir los % de retencion de cada item facturado. • Adicionar el calculo del total de retencion para la factura. Nota: Esto se hace con todas los tipos de facturas. Nota : Validar con carlos como quedara esto en el modelo.

C.U Aplicado a todos los casos de uso de generación de facturas. PL/sql • Adicionar función que

registre los detalles de los ítems facturados. Con los datos según modelo de datos. • La cabecera tendrá por cada tipo de factura un detalle. (medicamento alto costo, posquirúrgico, pagos paciente, pagos entidad/particulares) Ese detalle es el que hay que llenar al registrar la factura. (Ver casos de uso).

Hoc_SnpLiquidateAdmission

9 12

C.U CUMATIS20070514_195-Generar factura Particulares Pl/sql PENDIENTE DE RESPUESTA

DE CORREOS.

RQMATIS20070425_628-Reliquidacion de facturas CUMATIS20070516_204-Reliquidar factura Pl/sql • Crear el snp y api para

ejecutar la accion de reliquidar la factura de acuerdo al caso de uso. Este api, realmente llamara a los snp de regeneracion de facturas. • Crear el snp y api para el registro de la traza de

5 8

32

reliquidación de facturas. Según caso de uso.

Present- • Crear tpl, accion y vista, modelo donde al usuario se le permita consultar todas las facturas generadas que no hayan sido impresas. Y permitirle seleccionar una para reliquidar.

9 8

Todos los casos de uso de regeneracion de facturas (ej. CUMATIS20070516_205-Regenerar facturas de entidad reliquidadas)

• Se debe crear un proceso que en el momento de la generacion de las facturas pueda ejecutarse para tambien regenerar las facturas que fueron reliquidadas. Este proceso, debe verificar las facturas reliquidadas (en la traza de reliquidaciones) y regenerar sus facturas nuevamente. Ver casos de uso. La idea es crear un solo snp para la regeneracion de cualquier tipo de factura. Para el registro de los datos de la factura según el tipo, se pueden utilizar los mismos de la generacion de la factura.

10

12

RQMATIS20070425_629-Anulacion de facturas c.u CUMATIS20070516_211-Anular factura PL/sql • Crear snp /api para el

procedmiento de anulacion de la factura según el caso de uso. Nota:No hay nada de esto hecho.

5 6

33

Presenta. • Crear el tpl, vista y demas elementos para presentar una pantalla donde el usuario se le permita consultar las facturas generadas e impresas y que pueden ser anuladas. • Crear accion que llame al api de anulacion de fa tura.

5 8

RQMATIS20070426_510-Actualizacion del PLM (nota : de esto no hay nada realizado) C.U CUMATIS20070517_212-Actualizar PLM PL/sql • Crear snp /api para la

actualizacion del plm de un medicamento. Basado en las reglas definidas en el c.u.

5 6

Present. • Crear una pantalla donde el usuario pueda buscar un medicamento y actualizarle el PLM.

7 8

c.U CUMATIS20070517_213-Programar Fechas de actualizacion del PLM Pl/sql • Crear snp/api que permita

registrar y actualizar las fechas anuales para la actualizacion del plm. Ver caso de uso.

3 6

Present. • Crear pantalla donde se le permita al usuario ingresar las fechas anuales donde se debe actauizar los plm. Se le debe dar facilidades al usuario para ingresar los datos de las fechas. Y replicarlas, de tal manera que no las tenga que volver a digitar.

6 6

C.U CUMATIS20070517_215-Consultar Facturas afectadas X cambio en PLM

PL/Sql • Crear snd que devuelva todas las facturas afectadas por un cambio del plm en un medicamento. Ver caso de uso.

4 6

34

Present • Mostrar un pantalla donde el usuario pueda consultar todas las facturas afectadas por el cambio del plm de cualquier medicmaento

6 6

C.U CUMATIS20070517_216-Actualizar Precio de la tarifa Medicamento Pl/sql • Crear snp que actualice el

precio de la tarifa automáticamente de las tarifas de medicamentos que sufrieron cambios en el plm.

5 6

C.U CUMATIS20070517_217-Reliquidar Admisiones por PLM Pl/sql • Crear el snp que reliquide

las admisions que sufrieron cambios por plm. Ver requerimiento. • Utilizar las funciones de generar fcturaras para la relquidacion. Solo hay que hacer la parte de reliquidación , pero no generacion.

9 12

RQMATIS20070410_626-Generacion ordenes de impresion Pl/sql CUMATIS20070515_202-Generar orden de impresion PL/Sql • Modificar la función generar

orden de impresión. Agregándole los nuevos campos.

Hoc_SnpOrderPrintInvoce 3 6

Present • Crear una pantalla que se llame a traves de una accion del menú de facturación, y que le permita al usuario de perfil auxiliar de facturación, emitir ordenes de impresión de facturas aun no impresas. Se le debe permitir al usuario ingresar rangos de facturas a emitirles ordenes. Ya se cuentran las acciones, el tpl hay que modificar la presentación.

6 6

35

Ver requierimiento y caso de uso.

RQMATIS20070410_627-Impresion de facturas C.U. CUMATIS20070516_203-Imprimir factura Present Reparar los inconvenientes

ocasionados en las consultas por los cambios del modelo de facturas.

4 6

RQMATIS20070413_017-Notificacion Cierre Periodo Facturacio c.U CUMATIS20070508_325-Notificacion Cierre Periodo Facturacion PL/SQL • Crear la notificación. Esta

no existe. Para ello utilizar los snps de envios de mensajes ya construidos y las funciones de generacion de destinatarios ya construidos. Consultar con Lily o jose luis.

4 4

RQMATIS20070413_607-Generacion Cuentas X Cobrar. C.U CUMATIS20070508_321-Generar Cuentas X Cobrar Evento y

paquete Pl/sql • Restringir las cuentas de

cobro de evento y paquete. • Generar RIPS para las cuentas de cobro de evento y paquete Nota : consultar con lily

4 8

C.U. CUMATIS20070508_328-Generar Cuentas X Cobrar Capitacion • Se debe modificar la

creacion de cuentas de cobro para que haga cuentas de cobro solo para una factura de capitación • Se debe modificar la creacion de facturas de capitacion para relacionar las admisiones con esta factura, o definir como se va a relacionar

10

12

36

la factura de capitacion generada con las admisiones atendidas en este periodo. • Generar RIPS para la cuenta de cobro de capitacion

RQMATIS20070413_609-Generacion Cuentas X Pagar Prestadores c.u CUMATIS20070508_323-Generar Cuentas X Pagar Prestadore • Calcular los pagos a

proveedores de acuerdo al % de recargo segun el horario en que se haya ofrecido. Estos datos los debe devolver la agenda.

8 10

RQMATIS20070413_610-Provisionar Proximo Periodo Facturacion c.u CUMATIS20070508_324-Provisionar Proximo Periodo Facturacio • Calcular la aprovision para

el proximo periodo. • Adicionar los campos de cobro y pago de la aprovision, en la tabla de HOC_CIERRE_FACTURACION

10

14

CUMATIS20070509_329-Consultar la Provision del Periodo Facturacion

Pl/sql • Realizar la consulta de la aprovision para el proximo periodo

8 10

C.U CUMATIS20070509_326-Impresion de Cuentas de Cobro, CUMATIS20070515_347-Imprimir Notas de Facturacio

• Reparar problemas con las consultas. ocasionados por cambios del model.

6 6

CUMATIS20070509_327-Consulta Pagos Proveedores al dia • Crear la consulta, el tpl,

vista y accion y modelo. • Ver caso de uso.

9 12

CUMATIS20070515_346-Generar Notas de Facturacion Presentac • Cambios en la

presentacion.

3 6

37

Consultar con lily. Fuente: José Luis González. Análisis de Impacto, Santiago de Cali. Coomeva 2008.

38

9. CRONOGRAMA DE ACTIVIDADES

Semana 1

Semana 2

Semana 3

Semana 4

Noviembre Diciembre Enero Febrero

Análisis y conocimiento del negocio.

Análisis de los requerimientos levantados por la UTI.

Etapa de desarrollo

Solución de posibles no conformidades.

39

10. PRESUPUESTO

Tabla 1. Recurso Humano Recurso Humano Fuentes

Nombres Valor / hora

No Total de Horas

Valor Total

UAO GENIAR

Mario Ramírez (Estudiante) $ 4.000 265 $ 1.060.000

$ 1.060.000

Diego Fernando Garcés (Estudiante)

$ 4.000 265 $ 1.060.000

$ 1.060.000

Ing. Miguel José Navas Jaime (Director)

$ 55.800 16 $ 892.800

$ 892.800

Ing. Julián Kunzig (Coordinador Proyecto Geniar )

$ 55.800 130 $ 7.254.000

$ 7.254.000

Valor Total del Recurso Humano

$ 10.266.800

$ 892.800 $ 9.374.000

Tabla 2. Recursos Varios Recursos Varios

Cantidad Valor unitario Valor total

Horas en Internet 810 $ 500 $ 405.000

Resmas de Papel 5 $ 10.000 $ 50.000

Cartuchos de Tinta 7 $ 10.000 $ 70.000

Transporte por Persona 2 $ 250.000 $ 500.000

Total $ 1.025.000

Tabla 3. Presupuesto General

Fuentes Presupuesto General UAO GENIAR ESTUDIANTES

Recursos Varios $ 1.025.000 $ 1.025.000

Recurso Humano $ 10.266.800 $ 892.800 $ 9.374.000

Total $ 11.291.800

40

11. CONCLUSIONES El uso de un lenguaje de programación como PHP y PL/SQL garantiza que la aplicación, sin ser demasiado robusta, sea bastante estable y rápida. Gracias al manejo adecuado de una arquitectura, esta aplicación en su totalidad es escalable, lo que permitirá a los usuarios continuar con el crecimiento de esta según los cambios requeridos por el modelo de negocios. Por ser MATIS una aplicación nueva en su tipo de modelo de negocio, puede convertirse en una aplicación estándar para futuras implementaciones de este tipo.

41

BIBLIOGRAFÍA

BOOCH; GRADY; RUMBAUGH; JAMES; JACOBSON y IVAR. El lenguaje Unificado de Modelado. España: Editorial Addison Wesley, 2003. 200 p. CASAMAYOR, Juan Carlos. Base de datos relacionales. 2 ed. España: Editorial Prentice Hall, 2003. p. 80-82. Conceptos y Estructura de Ingeniería de Software [en línea]. Colombia: Monografias 2007. [Consultado 02 de Febrero de 2008]. Disponible en Internet: http://www.monografias.com/trabajos5/inso/inso.shtml GIL / TEJEDOR. Creación de sitios web con php 4. Madrid: Editorial Mc Graw Hill, 2000. 2 ed. 180 p. Manual de Oracle 9i y SQL [en línea]. España: Naturaleza-bo 2006. [Consultado 02 de Febrero de 2008]. Disponible en Internet: http://www.natureza-bo.com/AQUINO/VARIOS/oracleSQL.pdf MOULDING, Peter. PHP 4 Bible. España: Editorial Anaya Multimedia, 2003. 255 p. PRESSMAN, Roger S. Ingeniería del Software, Un enfoque práctico. 5 ed. Madrid: Editorial MacGraw-Hill, 2001. 200 p. PÉREZ, Cesar. Oracle 9i: Servidor de Aplicaciones, Red y Programación, España: Editorial Ra-Ma, 2003. 220 p. Programación en PHP [en línea]. Alemania: php, 2008 [Consultado 03 de Febrero de 2008].. Disponible en Internet: http://www.php.net/ RAMÍREZ, Mary E. Modulo de clase Base de Datos, Ing. Universidad Autónoma de Occidente. Santiago de Cali: Universidad Autónoma de Occidente, 2005. 90 p. STOPFORD, Andrew. Programación php para Windows: guía avanzada. Colombia: Editorial Pearson. Educación De Colombia, 2003. 100 p. SHARI LAWRENCE, Pfleeger. Ingeniería de Software (Teoría y Práctica). Estados Unidos: Editorial University of Maryland. 3 ed. 50 p.

González, José Luis. Análisis de Impacto, Santiago de Cali. Coomeva 2008.