UNIVERSIDAD DE ORIENTE NCLEO DE MONAGAS INGENIERIA DE SISTEMAS COMISIN DE TRABAJO DE GRADO MATURN / MONAGAS / VENEZUELA

IMPLEMENTACIN DE UN SISTEMA AUTOMATIZADO QUE OPTIMICE LA GESTIN DE LOS PROCESOS ADMINISTRATIVOS DEL REA SERVICIOS MDICOS DE LA UNIVERSIDAD DE ORIENTE NCLEO MONAGAS
Informe de Pasantas de Grado presentado ante la Comisin de Trabajos de Grado, como requisito para optar al ttulo de Ingeniero en Sistemas.

Br. Lolimar D. Cedeo M. C.I: 18.273.157 Tutor Acadmico: Tutor Laboral: Maturn, Octubre de 2010 Ing. Jess Chaparro Ing. Rosngela Garca

UNIVERSIDAD DE ORIENTE NCLEO DE MONAGAS INGENIERA DE SISTEMAS COMISIN DE TRABAJOS DE GRADO MATURN / MONAGAS / VENEZUELA

ACTA DE EVALUACIN

En mi carcter de Asesor Laboral del trabajo presentado por el Bachiller Cedeo Mendoza Lolimar De Los ngeles portadora de la cdula de identidad nmero: 18.247.157, para optar al grado acadmico de Ingeniero de Sistemas, Titulado: Implementacin de un sistema automatizado que optimice la gestin de los procesos administrativos del rea servicios mdicos de la universidad de oriente ncleo Monagas considero que dicho trabajo rene los requerimientos y mritos suficientes para ser sometido a la evaluacin por parte del jurado examinador.

En la ciudad de Maturn a los diez das del mes de enero de dos mil once.

Ing. Rosngela Garca C.I. 8.977.359

ii

UNIVERSIDAD DE ORIENTE NCLEO DE MONAGAS INGENIERA DE SISTEMAS COMISIN DE TRABAJOS DE GRADO MATURN / MONAGAS / VENEZUELA

ACTA DE EVALUACIN

En mi carcter de Asesor Acadmico del trabajo presentado por el Bachiller Cedeo Mendoza Lolimar De Los ngeles portadora de la cdula de identidad nmero: 18.247.157, para optar al grado acadmico de Ingeniero de Sistemas, Titulado: Implementacin de un sistema automatizado que optimice la gestin de los procesos administrativos del rea servicios mdicos de la universidad de oriente ncleo Monagas, considero que dicho trabajo rene los requerimientos y mritos suficientes para ser sometido a la evaluacin por parte del jurado examinador.

En la ciudad de Maturn a los diez das del mes de enero de dos mil once

Ing. Jess Chaparro C.I. 4.526.369

iii

DEDICATORIA

Camin con paso firme y constante, con profunda fe, y absoluta conviccin de que alcanzara mi meta ms preciada; hoy que al fin puedo vivirla y trazarme muchas ms quiero expresar mi agradecimiento primeramente a Dios por darme vida y salud para vivir este momento. Gracias Seor por llenar mi vida de tantas bendiciones!. Gran motivo me inspira a dedicar y agradecer a todos quienes me ayudaron: A mi mam con quien cuento para todo logro y siempre deposita en mi toda la confianza y el amor para hacer ms placentero y hermoso el camino. A mis abuelos quienes fueron y sern La Raz y el Tronco", el mejor pap y la mejor mam, gracias por sus cuidados.

Lolimar D.Cedeo M.

iv

AGRADECIMIENTOS

Mi tesis la dedico a mi padre Jess Arvalo Cedeo (), jams pens que cuando llegara este momento no estaras aqu, que tristeza, me siento realizada mas no feliz, pues sin ti la dicha no es completa Slo me conforta saber que ests en el cielo, en el reino de Dios, donde me cuidas y me proteges. Espero que ests sumamente feliz y muy orgulloso de m. T sabes que ests presente aqu, en el lugar donde siempre te encontrar y en donde siempre puedo pedirte un consejo, un abrazo o una mano, en el centro de mi corazn

Lolimar D.Cedeo M.

UNIVERSIDAD DE ORIENTE NCLEO DE MONAGAS INGENIERIA DE SISTEMAS COMISIN DE TRABAJO DE GRADO MATURN / MONAGAS / VENEZUELA

Autor: Cedeo M. Lolimar Tutor Acadmico: Ing. Jess Chaparro

IMPLEMENTACIN DE UN SISTEMA AUTOMATIZADO QUE OPTIMICE LA GESTIN DE LOS PROCESOS ADMINISTRATIVOS DEL REA SERVICIOS MDICOS DE LA UNIVERSIDAD DE ORIENTE NCLEO MONAGAS

RESUMEN
El presente trabajo de investigacin tiene como propsito principal implementar un sistema automatizado que optimice la gestin de los procesos administrativos del rea servicios mdicos de la Universidad de Oriente Ncleo Monagas. Este software permite controlar cada uno de los procesos administrativos que all se realizan, los cuales involucran: registro de usuarios, creacin de citas medicas, apertura de historias mdicas, emisin de rcipes para compra de medicamentos, control de consultas, salida y entrada de medicamento, remisin de pacientes que requieren atencin especializada y exmenes de laboratorios, con este sistema se automatizaron los procesos operativos y se suministr una plataforma de informacin necesaria para la toma de decisiones aportando informacin precisa y adecuada que contribuye a minimizar los riesgos y generar procesos ms eficaces en funcin de las necesidades del servicio que se presta. Dicho trabajo sigui un tipo de investigacin interactiva, con un nivel integrativo, la cual permite crear una solucin, apoyada en el uso de mtodos y herramientas tericamente sustentadas para modificar una situacin; la tcnica de anlisis de datos utilizada fue la de anlisis de contenido. Con el objetivo de lograr adaptar las mejores estrategias y herramientas de uso actual para el desarrollo de software se utiliz la metodologa GRAY WATCH y la herramienta de modelado UML BUSINESS extensin de UML. Para la creacin del software se utilizo el servidor XAMPP de plataforma software libre que consiste en la base de datos MySQL, el servidor Web Apache y los intrpretes para lenguajes de script: PHP y Perl., bajo un leguaje de programacin orientado a objeto. Palabras Claves: Modelado, Sistema, Servidor, Servicios Mdicos.

vi

INDICE GENERAL ACTA DE EVALUACIN .................................................................................... ii ACTA DE EVALUACIN ................................................................................... iii DEDICATORIA .................................................................................................... iv AGRADECIMIENTOS .......................................................................................... v RESUMEN............................................................................................................. vi INDICE GENERAL.............................................................................................. vii LISTA DE FIGURAS ............................................................................................. x LISTA DE TABLAS .............................................................................................. x LISTA DE DIAGRAMAS ................................................................................... xiv INTRODUCCIN .................................................................................................. 1 CAPITULO I........................................................................................................... 3 CONTEXTO ORGANIZACIONAL ...................................................................... 3 1.1. Resea Histrica de la Universidad de Oriente, Ncleo Monagas. ............. 3 1.1.1. Misin ................................................................................................... 3 1.1.2. Visin .................................................................................................... 4 1.2 Centro de Computacin, Universidad de Oriente Ncleo Monagas. ............ 4 1.2.1 Visin. .................................................................................................... 4 1.2.2 Misin. ................................................................................................... 4 1.2.3 Objetivos ................................................................................................ 5 1.2.4 Funciones ............................................................................................... 6 1.2.5 Organigrama........................................................................................... 7 1.3. Servicio Mdico de la Universidad de Oriente ............................................ 7 1.3.1. Objetivo:................................................................................................ 8 1.3.2. Misin: .................................................................................................. 8 1.3.3. Visin: ................................................................................................... 8 1.3.4. Organigrama.......................................................................................... 9 CAPTULO II ....................................................................................................... 10

vii

EL PROBLEMA Y SUS GENERALIDADES..................................................... 10 2.1. Planteamiento del Problema ....................................................................... 10 2.2. Objetivos de la Investigacin ..................................................................... 13 2.2.1. Objetivo General ................................................................................. 13 2.2.2. Objetivos Especficos .......................................................................... 13 2.3. Justificacin de la Investigacin ................................................................ 13 2.4. Alcance de la Investigacin. ...................................................................... 14 2.5. Limitaciones de la investigacin. ............................................................... 14 CAPITULO III ...................................................................................................... 15 MARCO REFERENCIAL .................................................................................... 15 3.1. Antecedentes de la Investigacin ............................................................... 15 3.2. Bases Tericas ............................................................................................ 17 3.2.1 Sistema de Informacin Transaccionales ............................................. 17 3.2.2. El Mtodo Gray Watch ....................................................................... 18 3.2.2.1. Objetivos del mtodo WATCH.................................................... 19 3.2.2.2 Caractersticas del Mtodo WATCH ............................................ 20 3.2.2.3 Componentes del mtodo WATCH .............................................. 25 3.2.3.4 Estructura del mtodo WATCH .................................................... 25 3.2.3 Lenguaje de Modelado Unificado .................................................... 33 3.2.3.1. UML 2.0 ....................................................................................... 34 3.2.3.2 Diagramas UML............................................................................ 34 3.2.3.2.1 Diagrama de caso de uso...........................................................35 3.2.3.2.2 Diagrama de clases. ..................................................................36 3.2.3.2.3 Diagramas de Despliegue .........................................................38 3.2.3.2.4 Diagrama de secuencia. ............................................................39 3.2.3.2.5 Diagrama de actividades. ..........................................................40 3.2.3.2.6 Diagrama de Paquetes ...............................................................41 3.2.3. Tarjetas CRC ....................................................................................... 42 3.2.5. Arquitectura cliente- servidor ............................................................. 42 3.2.6.1 Desarrollo de Software Libre ........................................................ 45 3.2.6. Sistemas de informacin aplicados al sector sanitario ........................ 46

viii

3.2.7. Herramientas de desarrollo. ............................................................. 47 3.2.8. Lenguajes de Programacin ................................................................ 48 3.2.9. Base de Datos MySql .......................................................................... 50 3.2.10. XAMMP............................................................................................ 50 3.2.11. Web Apache ...................................................................................... 51 3.3. Bases Legales ............................................................................................. 51 3.4. Definicin de Trminos.............................................................................. 53 CAPITULO IV ...................................................................................................... 56 MARCO METODOLGICO ............................................................................... 56 4.1. Tipo y Nivel de la Investigacin ................................................................ 56 4.2. Poblacin y Muestra ................................................................................... 57 4.2.1. Poblacin ............................................................................................. 57 4.2.2. Muestra................................................................................................ 57 4.3. Tcnicas e Instrumentos de Recoleccin de Datos. ................................... 58 4.4. Diseo Operativo ....................................................................................... 59 4.5. Cuadro Operativo ....................................................................................... 63 CAPITULO V ....................................................................................................... 65 RESULTADOS ..................................................................................................... 65 5.1 Etapa I. Estudio del Negocio. ...................................................................... 66 5.2 Etapa II. Diseo de la Arquitectura ............. Error! Marcador no definido. 5.3 Etapa III. Construccin del Software. ....................................................... 231 5.4. Etapa IV. Implantacin del sistema ........... Error! Marcador no definido. 5.5 Anlisis Costo Beneficio. ....................................................................... 251 5.5.1 Costos ................................................................................................. 251 5.5.2 Beneficios........................................................................................... 253 CONCLUSIONES .............................................................................................. 257 RECOMENDACIONES ..................................................................................... 259 BIBLIOGRAFA ................................................................................................ 260 ANEXOS ............................................................................................................ 263

ix

LISTA DE FIGURAS Pp. Figura 1 Organigrama del Centro de Computacin de la U.D.O Monagas.. .......... 7 Figura 2: Organigrama del Servicio Mdico de la U.D.O, Ncleo Monagas. ........ 9 Figura 3: Componentes del mtodo Gray Watch. Fuente: autor 2010. ................. 25 Figura 4; Principales tipos de productos del mtodo Gray Watch. ....................... 26 Figura 5: Clasificacin de los actores. Fuente: autor 2010. .................................. 27 Figura 6: Cadena de valor de Procesos del mtodo WATCH............................... 28 Figura 7: Procesos del mtodo WATCH. ............................................................ 28 Figura 8: Estructura del Modelo de Procesos. ...................................................... 32 Figura 9: Actor.. .................................................................................................... 35 Figura 10: Caso de Uso. ........................................................................................ 35 Figura 11: Tipos de Relaciones. ............................................................................ 36 Figura 12: Representacin de una Clase.. ............................................................. 36 Figura 13: Smbolo de un Paquete. ....................................................................... 41 Figura 14: Tarjeta CRC. ........................................................................................ 42 Figura 15: El modelo de aplicacin cliente/servidor. ........................................... 43 Figura 16: Clasificacin de los procesos del Mtodo WATCH............................ 79 Figura 17: Principales tipos de productos del mtodo WATCH. ......................... 83 Figura 18: Modelo de Jerarqua de Sistemas de servicios medico...................... 103 Figura 19: Diagrama de objetivos. ...................................................................... 104 Figura 20: Cadena de valor del negocio usando UML 2.0 V 1.3........................ 105 Figura 21: Jerarqua de los procesos del negocio .............................................. 107 Figura 22: Diagrama de procesos: Programar Cita. ............................................ 108 Figura 23: Diagrama de procesos: Elaboracin de Historia Mdica................... 110 Figura 24: Diagrama de procesos: Creacin de Boleta Medica. ........................ 112 Figura 25: Diagrama de procesos: Consulta Externa con Boleta Medica. ......... 114 Figura 26: Diagrama de procesos: Validar Informacin de Factura116 Figura 27: Diagrama de procesos: Peticin de Medicamentos .......................... 118 Figura 28: Diagrama de procesos: Suministro de Medicamento al Paciente. ..... 120 Figura 29: Modelo de Reglas del servicio mdico de la U.D.O Monagas. ......... 122 Figura 30: Calidad y Medicin de ISO.. ............................................................. 150

Pp. Figura 31: Modelo de calidad interna y externa del rea de servicios mdicos. . 154 Figura 32: Caso de uso general del sistema.. ...................................................... 157 Figura 33: Arquitectura del sistema.. .................................................................. 232 Figura 34: Tarjeta CRC Citas.............................................................................. 235 Figura 35: Tarjeta CRC Paciente. ....................................................................... 235 Figura 36: Tarjeta CRC Medicamento.. .............................................................. 235 Figura 37: Tarjeta CRC Historia. ........................................................................ 235 Figura 38: Tarjeta CRC Facturas.. ...................................................................... 236 Figura 39: Tarjeta CRC Boleta. .......................................................................... 236 Figura 40: Tarjeta CRC Rcipe.. ......................................................................... 236 Figura 41: Tarjeta CRC DPHistoria. ................................................................... 236

xi

LISTA DE TABLAS Pp. Tabla 1: Relacin entre clases. .............................................................................. 38 Tabla 2: Elementos del diagrama de despliegue. .................................................. 39 Tabla 3: Elementos de diagrama de secuencia. ..................................................... 40 Tabla 4: Elementos de diagrama de despliegue. ................................................... 41 Tabla 5: Interesados (stakeholders) del proyecto. ................................................. 73 Tabla 6: identificacin de Interesados del proyecto. ............................................. 74 Tabla 7: Productos que genera la metodologa ................................................... 82 Tabla 8: Caractersticas de ISO-9126 . ................................................................. 87 Tabla 9: Plan de tiempo del proyecto1/4............................................................... 90 Tabla 10: Riesgos a administrar en el proyecto 1/13. ........................................... 94 Tabla 11: Matriz evento vs. Proceso de Negocio. .............................................. 125 Tabla 12: Reglas del Negocio (1/4). ................................................................... 130 Tabla 13: Descripcin de actores 1/10. ............................................................... 134 Tabla 14: Recoleccin de requerimientos iniciales 1/2. ..................................... 136 Tabla 15: Requisitos funcionales del sistema (1/6)............................................. 141 Tabla 16: Requisito no funcionales del sistema (1/2). ........................................ 147 Tabla 17: Curso bsico de eventos para validar usuario. .................................... 158 Tabla 18: Curso alternativo de eventos para validar usuario. ............................. 158 Tabla 19: Curso bsico de eventos para validar usuario 1/2. .............................. 161 Tabla 20: Curso alternos de eventos para validar usuario................................... 162 Tabla 21: Curso bsico de eventos para programar cita. .................................... 165 Tabla 22: Curso alterno de eventos para programar cita..................................... 166 Tabla 23: Curso bsico de eventos para consultar cita. ...................................... 172 Tabla 24: Curso alterno de eventos para consultar cita....................................... 172 Tabla 25: Curso bsico de eventos para elaborar historia mdica ...................... 176 Tabla 26: Curso alterno de eventos para elaborar historia mdica.. ................... 177 Tabla 27: Curso bsico de eventos para crear boleta mdica.............................. 187 Tabla 28: Curso alterno de eventos para crear boleta mdica ............................. 187 Tabla 29: Curso bsico de eventos para emitir rcipe medico. ........................... 193 Tabla 30: Curso alterno de eventos para emitir rcipe medico. .......................... 194

xii

Pp. Tabla 31: Curso bsico de eventos para el registro de factura. ........................... 199 Tabla 32: Curso alterno de eventos para el registro de factura. .......................... 199 Tabla 33: Curso bsico de eventos para la devolucin de factura. ..................... 200 Tabla 34: Curso bsico de eventos para la consulta de factura. .......................... 209 Tabla 35: Curso alterno de eventos para la consulta de factura. ......................... 209 Tabla 36: Curso bsico de eventos mantenimiento de medicamento. ............... 213 Tabla 37: Curso alterno de eventos mantenimiento de medicamento................. 213 Tabla 38: Curso bsico de eventos para la salida de medicamento. ................... 214 Tabla 39: Curso alterno de eventos para la salida de medicamento. .................. 214 Tabla 40: Curso bsico de eventos generar reporte. .......................................... 224 Tabla 41: Curso alterno de eventos generar reporte............................................ 224 Tabla 42: Tabla de mtrica Adecuidad ISO 9126. ............................................. 228 Tabla 43: Tabla de mtrica Madurez ISO 9126. ................................................ 228 Tabla 44: Tabla de mtrica Entendibilidad ISO 9126......................................... 229 Tabla 45: Tabla de mtrica ISO 9126. Comportamiento en el tiempo .............. 229 Tabla 46: Tabla de mtrica ISO 9126. Conformidad de la Transportabilidad .... 230 Tabla 47: Especificacin de caso de pruebas boleta mdica............................... 244 Tabla 48: Especificacin de caso de pruebas Motivo Despacho. ....................... 245 Tabla 49: Especificacin de caso de pruebas Laboratorio. ................................. 246 Tabla 50: Costos de Materiales (1/2). ................................................................. 252 Tabla 51: Reduccin de tiempo........................................................................... 254 Tabla 52: Disminucin de tiempo en la generacin de reporte. .......................... 255 Tabla 53: Costos de papelera sin el sistema. ...................................................... 255

xiii

LISTA DE DIAGRAMAS Pp. Diagrama 1: Diagrama de actividades programar cita mdica. .......................... 109 Diagrama 2: Diagrama de actividades elaborar historia mdica. ........................ 111 Diagrama 3: Diagrama de actividades del creacin de boleta medica. ............... 113 Diagrama 4: Diagrama de actividades del consulta externa .............................. 115 Diagrama 5: Diagrama de actividades del validar facturas. ............................... 117 Diagrama 6: Diagrama de actividades del Peticin de Medicamentos. ............. 119 Diagrama 7: Diagrama de actividades del Suministro de Medicamento ........... 121 Diagrama 8: Diagrama de modelado de objetos del negocio. ............................. 123 Diagrama 9: Diagrama de proceso del descubrimiento de requisitos. ................ 127 Diagrama 10: Jerarqua de los proceso del descubrimiento de requisitos.. ........ 127 Diagrama 11: Jerarqua de los proceso de entendimiento del dominio. ............. 128 Diagrama 12: Jerarqua de los proceso de organizacin del conocimiento ........ 128 Diagrama 13: Jerarqua de los proceso de recoleccin de requisitos.. ................ 129 Diagrama 14: Diagrama de caso de uso de validar usuario. ............................... 158 Diagrama 15: Diagrama de secuencia validar usuario. ....................................... 159 Diagrama 16: Diagrama de caso de uso de administrar usuario ........................ 161 Diagrama 17: diagrama de secuencia administrar usuario. ................................. 163 Diagrama 18: Diagrama de caso de uso Programar Cita Mdica. ...................... 165 Diagrama 19: diagrama de clase programar cita. ................................................ 167 Diagrama 20: Diagrama de Secuencia Programar Cita....................................... 168 Diagrama 21: Diagrama de caso de uso consultar cita. ...................................... 171 Diagrama 22: Diagrama de secuencia consultar cita. ........................................ 173 Diagrama 23: Diagrama de caso de uso elaborar historia mdica. ..................... 176 Diagrama 24: Diagrama de clase elaborar historia Mdica. .............................. 178 Diagrama 25: Diagrama de secuencia elaborar historia Mdica. ........................ 179 Diagrama 26: Diagrama de caso de uso crear boleta Mdica. ............................ 186 Diagrama 27: Diagrama de clase crear boleta Medica........................................ 188 Diagrama 28: Diagrama de secuencia crear boleta Medica. ............................... 189 Diagrama 29: Diagrama de caso de uso emitir rcipe medico. ........................... 193 Diagrama 30: Diagrama de clase emitir rcipe medico. ..................................... 194

xiv

Pp. Diagrama 31: Diagrama de secuencia emitir rcipe medico. .............................. 195 Diagrama 32: Caso de uso Conformar Factura. .................................................. 198 Diagrama 33: Diagrama de clase. Conformar Factura. ...................................... 201 Diagrama 34: Diagrama de secuencia registro de factura. ................................ 202 Diagrama 35: Diagrama de secuencia devolucin de factura.. ........................... 205 Diagrama 36: Diagrama. Caso de uso Consultar Factura. .................................. 208 Diagrama 37: Diagrama. Secuencia Consultar Factura.. .................................... 210 Diagrama 38: Diagrama. Caso de uso Control de medicamento. ...................... 212 Diagrama 39: Diagrama de clase Control de Medicamento. .............................. 215 Diagrama 40: Diagrama. Secuencia de mantenimiento de medicamento. .......... 216 Diagrama 41: Diagrama. Secuencia salida de medicamento. ............................. 219 Diagrama 42: Diagrama. Caso de uso generar reporte. ...................................... 223 Diagrama 43: Diagrama. Secuencia generar reporte........................................... 225 Diagrama 44: Diagrama de clase usuario............................................................ 233 Diagrama 45: Diagrama de clase de procesos..................................................... 234 Diagrama 46: Modelo de Vista de Despliegue.. ................................................. 237 Diagrama 47: Diseo conceptual de Usuarios. ................................................... 238 Diagrama 48: Diseo conceptual de Procesos de sitema. ................................... 238 Diagrama 49: Diseo relacional de Usuario. ..................................................... 239 Diagrama 50: Diseo Relacional de Procesos de sistema. .................................. 239 Diagrama 51: Diseo Fsico de la base de datos de Usuario. ............................. 240 Diagrama 52: Diseo Fsico de la base de datos de Procesos ............................. 240

xv

INTRODUCCIN

La continua evolucin de la tecnologa informtica y el creciente inters de la Administracin por alcanzar un desempeo ms efectivo, han incrementado el uso de sistemas automatizados como mecanismos para enfrentar la competitividad de manera ms eficiente. El manejo de la informacin, a travs de la implantacin de sistemas automticos viene permitiendo a las organizaciones, el dominio de gran cantidad de datos en forma centralizada y en lnea. Tales razones explican la gran demanda y variedad de software o programas informticos que estn dando

respuesta a necesidades particulares, en cuanto a la agilizacin y tramitacin de datos que, debidamente interpretados puedan ser tiles para extraer conclusiones. En el campo de los procesos mdicos, los sistemas de informacin estn jugando un importante papel, como elemento clave para abordar muchos de los retos que afronta el sector sanitario, realidad que puede insertarse dentro de las expectativas de la Pasanta realizada en el Servicio Mdico de la Universidad de Oriente Ncleo Monagas, la cual se plante como objetivo, implementar un sistema automatizado que optimice la gestin de los procesos administrativos del rea de servicios mdicos de la universidad de Oriente ncleo Monagas. Desde esta perspectiva el rea temtica est centrada en un sistema de informacin transaccional. Para la elaboracin de este proyecto se emple como metodologa de trabajo, GRAY WATCH por ser un mtodo de desarrollo de software que abarc todo el ciclo de vida de las aplicaciones; desde el modelado del dominio de la aplicacin, pasando por la definicin de los requisitos de los usuarios, hasta la puesta en operacin del sistema. Este mtodo establece las actividades los procesos, las prcticas, las tcnicas, los estndares, y las herramientas que se deben emplea

para desarrollar los componentes arquitectnicos de la aplicacin e integrarla al sistema de negocio para el cual es desarrollada. La metodologa fue sustentada junto a las herramientas de lenguaje de modelado UML BUSINESS y de sistemas en ambiente Web, WebML, herramientas que permiten al diseador enfocar todo su esfuerzo en el usuario final por ser un sistema basado en ellos. Tambin se utiliz la extensin de UML mediante dos tcnicas no incorporadas: tarjetas CRC para anlisis guiados por la responsabilidad, y diagramas de Entidad de Relacin (ER) para modelar bases de datos relacionales. El trabajo est conformado por cinco (5) captulos: Captulo I: Contiene informacin del contexto organizacional relacionada con el Servicio Mdico de la Universidad de Oriente Ncleo Monagas, institucin objeto de estudio. As como tambin, aspectos relacionados con el centro de computacin de la Universidad de Oriente Ncleo Monagas, institucin donde se realiz la pasanta de grado detallando su misin, visin, objetivos, estructura organizativa, entre otros. Captulo II: Este captulo contempla el planteamiento del problema, los objetivos de la investigacin, la justificacin y el alcance. Captulo III: Est constituido por los antecedentes que apoyan la investigacin y las bases tericas que le dan sustento al trabajo investigativo. Captulo IV: En este captulo se detalla la metodologa que se implement y la explicacin del trabajo realizado durante el periodo de pasanta. Captulo V: Recoje los resultados alcanzados, partiendo de la aplicacin de la propuesta de solucin. Para finalizar, se plantean las conclusiones y las recomendaciones las cuales constituyen un aporte de investigacin.

CAPITULO I CONTEXTO ORGANIZACIONAL

1.1. Resea Histrica de la Universidad de Oriente, Ncleo Monagas. El Ncleo de Monagas de la Universidad de Oriente, responde a las necesidades y tradicin del Estado, en su actividad agrcola, ganadera y petrolera que a travs de un conjunto de unidades acadmicas, ofrece a una poblacin estudiantil de ms de 15.000 estudiantes las carreras de: Ingeniera: Agronmica, en Produccin Animal, Petrleo y Sistemas, adems de Licenciatura en: Administracin, Contadura Pblica, Gerencia de Recursos Humanos y Tecnologa de los Alimentos. Asimismo ofrece Servicios de Orientacin Bibliotecas, Comedor, Transporte, Proveedura, Librera y Servicio Mdico-Odontolgico, Ayudas Econmicas, Extensin Cultural, Deportes y Planes de pasantas para el financiamiento y familiarizacin con el futuro desempeo profesional. 1.1.1. Misin La Universidad de Oriente reafirmar su compromiso de ser el centro de estudio, anlisis y produccin de ideas necesarias para el desarrollo social, econmico y poltico del Oriente del Pas, capaz de desarrollar mtodos y tecnologa innovadoras, de asegurar la calidad por medio de los sistemas eficientes de planificacin, evaluacin y motivacin. La Universidad ser una Institucin cuyo ambiente estimule la creatividad y productividad de todos sus miembros. As mismo deber ocupar una posicin de liderazgo en investigacin y logros acadmicos. Con intencin de situarse en un lugar privilegiado en los sueos de cada miembro de la Comunidad Universitaria.

1.1.2. Visin Formar profesionales del ms alto nivel de calidad, profesionales que atiendan problemas de su particular formacin y competencia, bajo un alto espritu de solidaridad y compromiso social. Se trata de formar profesionales creativos, capaces de destacarse en un mercado cada vez ms competitivo con el mejoramiento de la calidad de vida y con el desarrollo. Mantener una permanente vinculacin con sus egresados para su actualizacin constante. As mismo, permanecer en contacto con los sectores sociales y productivos. Brindar a sus trabajadores tanto, en la parte acadmica, administrativa y estudiantil las mejores condiciones para que estos encuentren el xito en el desempeo de sus funciones. Mantener un clima de respeto mutuo, de libertad de expresin, organizacin, de pluralidad de todas las corrientes de pensamiento, dentro de un ambiente de responsabilidad y tolerancia a todas las ideas e igualmente estar vinculada con su entorno. 1.2 Centro de Computacin, Universidad de Oriente Ncleo Monagas. 1.2.1 Visin. El Centro de Computacin tiene como visin principal ser un centro competitivo, lder a nivel nacional en todas las reas de nuestro inters, contando con el apoyo de un personal altamente capacitado en cada una de las secciones que los componen y estableciendo una plataforma tecnolgica til que satisfaga las necesidades del sector docente, estudiantil y administrativo de la Universidad de Oriente Ncleo Monagas. 1.2.2 Misin. La misin del Centro de Computacin, es la de realizar labores de investigacin, desarrollo de software, adiestramiento y soporte tcnico en las reas

de computacin e informtica, dirigido a la poblacin docente, estudiantil y administrativa de la Institucin, con extensin de sus servicios a otras organizaciones mediante el diseo, coordinacin y ejecucin de sus labores, para fortalecer las actividades acadmico administrativas y contribuir al desarrollo tecnolgico de la Universidad de Oriente Ncleo Monagas. 1.2.3 Objetivos Los objetivos del Centro de Computacin de la Universidad de Oriente Ncleo Monagas son los siguientes: a. Disear y desarrollar aplicaciones con fines didcticos y administrativos. b. Asesorar a las autoridades universitarias del ncleo sobre las innovaciones tecnolgicas relacionadas con la computacin e informtica y su impacto en la organizacin. c. Generar conocimientos en las diversas reas de la computacin y sistemas mediante proyectos de investigacin. d. Ofrecer servicios a la comunidad local y regional en los rubros de anlisis, diseo y auditoria de sistemas de informacin, redes y adiestramiento de personal. e. Coordinar la aplicacin de servicios informticos a otras unidades organizativas de la Universidad de Oriente. f. Desarrollar los sistemas de informacin que permitan la automatizacin de la gestin administrativa de la Universidad de Oriente Ncleo Monagas. g. Capacitar el recurso humano de la institucin con la finalidad de asegurar el manejo eficiente de los equipos computacionales disponibles en diferentes unidades de la organizacin. h. Evaluar y controlar la plataforma operativa del Centro de Computacin.

1.2.4 Funciones El Centro de Computacin cumple con las siguientes funciones, a objeto de alcanzar su respectiva visin y misin: a. Brindar de forma permanente soporte tcnico a las unidades

administrativas del ncleo Monagas de la Universidad de Oriente. b. Procesar lo relacionado con la nmina de pago, el rea de

contabilidad y presupuesto. c. Desarrollar y mantener los sistemas de informacin orientados al proceso de automatizacin de la gestin administrativa de la Institucin. d. Coordinar y supervisar el funcionamiento de las unidades que integren el Centro de Computacin e. Distribuir, segn la capacidad productiva, las tareas del personal

adscrito al Centro de Computacin. f. Capacitar al personal de la Institucin en el manejo eficiente de los

equipos de computacin, a travs de cursos, charlas y seminarios de actualizacin y charlas. g. Prestar asesora en el rea de computacin y Teleinformtica a aquellas unidades que integran la estructura administrativa y acadmica de la Universidad de Oriente. h. Procesa toda la informacin necesaria para el Dpto. de Admisin y Control de Estudio. As mismo presta todos los servicios necesarios en los procesos de inscripcin, informes al CNU y estadsticas acadmicas. i. El Centro puede atender solicitudes de aplicaciones para el anlisis estadstico de datos generados por las investigaciones que se realizan en el ncleo.

1.2.5 Organigrama

Jefatura

Secretaria

PROGRAMAS Y PROYECTOS

SECCIN DE APOYO

Produccin y desarrollo de sistemas

Valor agregado

Redes

Soporte Tcnico

Seguridad

Figura 1 Organigrama del Centro de Computacin de la Universidad de Oriente, Ncleo Monagas. Fuente: Memoria y Cuenta (2009).

1.3. Servicio Mdico de la Universidad de Oriente La fuente Universidad de Oriente (2010), acota que el Servicio Mdico del Ncleo Monagas es una Unidad adscrita a la Delegacin de Desarrollo y Bienestar Estudiantil, la cual se inserta dentro de una estructura organizativa institucional en consonancia con las expectativas institucionales. Esta delegacin estudia al educando dentro de su dimensin social con la finalidad de ofrecer diversas vas de solucin a los problemas que interfieren en su adecuado funcionamiento acadmico y social. Desde este ngulo, la salud de sus miembros se constituye en una parte importante para alcanzar los objetivos de esta casa de estudios en cuanto a mantener un liderazgo en la investigacin. En correspondencia con ello, el Servicio Mdico

est dirigido a la atencin mdica de estudiantes, obreros y empleados que laboran en dicho ncleo. Este servicio vela por la prevencin de enfermedades manteniendo la vigilancia y control de la salud, dicha actividad sanitaria abarca una evaluacin inicial del estado de salud, unas revisiones peridicas anuales y hasta revisin ante un cambio de puesto de trabajo. 1.3.1. Objetivo: Brindar atencin mdico - odontolgica de carcter preventivo a la comunidad universitaria, con el objeto de promover un ambiente que estimule la creatividad y productividad de todos sus miembros. 1.3.2. Misin: La misin del Servicio Mdico es brindar atencin mdica preventiva en los niveles primario, y secundario. Buscar minuciosamente los primeros signos y sntomas de las enfermedades para evitar, su evolucin hacia estadios avanzados, el dolor del paciente el sufrimiento de la familia, la muerte, sin excusa posible. 1.3.3. Visin: El Servicio Mdico tiene como visin los siguientes aspectos: a. Ser un servicio con calidad total donde se promocione la medicina preventiva con vocacin humana, cientfica y tecnolgica. b. Alcanzar metas de prevencin total en enfermedad cardiovascular, metablica, ocupacional y tumoral.

1.3.4. Organigrama

Decanato del Ncleo Monagas

Coordinacin Administrativa Secretaria

Coordinacin Acadmica

Transporte

Delegacin de Desarrollo Social y Bienestar Estudiantil

Administracin

rea Socioeducativa

rea de Salud

rea de Desarrollo Social

rea de Orientacin

Servicios Mdicos

Medicina General

Medicina Interna

Pediatra

Ginecologa

Odontologa

Figura 2: Organigrama del Servicio Mdico de la Universidad de Oriente, Ncleo Monagas. Fuente: Universidad de Oriente (2009)

De acuerdo con documentos del Servicio Mdico Odontolgico (2008), el mismo est conformado por catorce (16) funcionarios, los cuales se detallan a continuacin precisando el nmero de personas que ocupan cada cargo: 01 jefe de departamento 01 jefe de enfermera 05 Enfermeras 06 Mdicos 9 01 Auxiliar de Registros y Estadsticas 01 Higienista Dental 01 Secretaria

CAPTULO II EL PROBLEMA Y SUS GENERALIDADES

2.1. Planteamiento del Problema Para estar a la vanguardia del mundo actual hay que ajustarse al desarrollo y crecimiento del entorno tecnolgico, como mecanismo de acceso a la informacin bajo parmetros de rapidez, privacidad, confiabilidad y eficiencia tal que permitan un desarrollo cnsono dentro de las instituciones y contribuya al desarrollo nacional. Esta realidad viene siendo asumida por las organizaciones mundiales, entre ellas, las instituciones de educacin superior, establecimientos generadores y promotores de conocimiento que asumen la tecnologa, como herramienta para optimizar sus procesos internos. Desde esta perspectiva la implantacin de sistemas automatizados se constituyen en una alternativa real y eficiente para mejorar los resultados de la gestin y un mejor desempeo laboral. Dentro de este contexto se enmarca, el Servicio Mdico Odontolgico que se encuentra ubicado en la sede Guaritos de la Universidad de Oriente Ncleo de Monagas, el cual es un rea orientada a brindar atencin a toda la poblacin que forma parte de la institucin, en ramas de la medicina tales como: ginecologa, odontologa, pediatra, medicina general e interna. La puesta en marcha del Servicio Mdico Odontolgico se ha iniciado con un conjunto de limitaciones, como lo es la consistente y creciente demanda del los usuarios, situacin que requiere ser solventada para cubrir las necesidades de salud de los estudiantes, obreros y empleados y logar una gestin de servicio ms eficiente.

Actualmente todos los procesos administrativos del Servicio Mdico: registro de usuarios, apertura de historias mdicas, emisin de rcipes para compra de medicamentos, control de consultas, remisin de pacientes que requieren atencin especializada y exmenes de laboratorios se llevan a cabo de manera manual, as como tambin, la relacin de los mismos, a objeto de validar la cancelacin de tales servicios ante la Delegacin de Presupuestos de dicha institucin, generando un conjunto de fallas que se expresa en: Para que el paciente pueda recibir la atencin mdica tienen que invertir gran cantidad de tiempo asistiendo al Departamento de Admisin y Control de Estudios, en el caso de los estudiantes a solicitar una constancia de estudio para poder ser atendidos o en el caso de los obreros y empleados, la Delegacin de personal debe enviar una orden al servicio mdico. Este hecho, tambin trae como consecuencia, que en muchas ocasiones por el deficiente control, se atienden pacientes o se suministren medicamentos a personan que no forman parte de la poblacin universitaria del ncleo de Monagas. Las historias mdicas se crean y almacenan en un archivador fsico, dificultando, en la mayora de los casos, su ubicacin y manipulacin. Esta situacin retrasa el proceso para atender al paciente, ya que el doctor necesita tener la historia mdica a mano, al momento de realizar la consulta. Adems, el archivador fsico es de libre acceso porque se encuentra localizado en un rea de uso comn para todo el personal del servicio mdico, siendo susceptible a extravos o manipulacin por personas ajenas a dependencia. Las estadsticas necesarias para el control y evaluacin del servicio que se presta, las lleva el auxiliar de registro y estadstica con una herramienta ofimtica de procesamiento de texto (Word), debido al gran volumen de pacientes que se atienden por da, esto resulta un proceso lento y genera mucho trabajo emitir conclusiones acerca de la gestin del servicio mdico o contar con informacin que sirva como datos estadsticos. la

11

Las boletas de remisin del paciente a mdicos externos y de exmenes de laboratorio, se llevan por medio de talonarios que es un mecanismo implementado bajo normas del servicio mdico, que en muchos casos son extraviados o tienen enmienda lo cual dificulta el control y la cancelacin de estos servicios. Adems que siempre se presenta problemas al validar las boletas emitidas y de los gastos asociados a la compra de medicamentos por rcipes mdicos. Debido a toda esta problemtica se plantea la siguiente investigacin para dar seguimiento al trabajo de grado realizado por Cabello, M. (2009) titulado: Sistema automatizado basado en software libre para optimizar los procesos administrativos de los servicios mdicos de la universidad de Oriente ncleo Monagas, en este trabajo se determin un alcance hasta la fase de construccin de la metodologa RUP (Proceso Unificado Racional), no llegando a la implementacin. Por las razones expuestas, se hace pertinente retomar el proyecto, culminar la fase de construccin del sistema y realizar su implementacin, con la finalidad de brindarle al servicio mdico una aplicacin completa que optimice la totalidad de sus procesos administrativos. A pesar que se cuenta con una parte del diseo del sistema, fue necesario realizar una revisin, que permitiera verificar y validar cambios;

requeridos para la incorporacin de nuevos mdulos funcionales, con mtricas de calidad y nuevos estndares que manejan mayor privacidad y confiabilidad de la informacin. Para llevar este proyecto a su culminacin se utiliz el mtodo GRAY
WATCH, el cual va a permiti hacer las verificaciones a travs de ciclos versionados

obteniendo las funcionalidades del sistema por versiones y luego llevarlo a ejecucin. La propuesta en referencia, beneficia a todo el personal que labora dentro del rea de Servicios Mdicos lo cual permite agilizar la gestin gerencial de esta rea y aumentar el flujo de pacientes que se atienden diariamente, ya que se trata de un mecanismo que permite la modernizacin y optimizacin de los procesos de una unidad bajo su responsabilidad y acorde a las fundamentos del uso del Software Libre , el cual atiende a los lineamientos estratgicos de las polticas nacionales, en relacin al uso de sistemas de informacin dentro de las instituciones pblicas.

12

2.2. Objetivos de la Investigacin 2.2.1. Objetivo General Implementar un sistema automatizado que optimice la gestin de los procesos administrativos del rea de servicios mdicos de la Universidad de Oriente Ncleo Monagas. 2.2.2. Objetivos Especficos 1. Estudiar el modelo de negocio del rea de servicios mdicos, para obtener una visin del sistema a nivel conceptual. 2. Determinar los requisitos del sistema funcionales y no funcionales, fortaleciendo y complementando el modelo actual. 3. Formular la arquitectura que debe tener el sistema a desarrollar tomando en cuenta los requisitos funcionales y no funcionales. 4. Construir el sistema con base a la arquitectura diseada. 5. Implementar el sistema, ya probado en su plataforma de operacin. 2.3. Justificacin de la Investigacin El presente trabajo se inserta dentro de la lnea de investigacin iniciada por Cabello, M. (2009) La misma le permitir a todo el personal que labora dentro del rea Servicio Mdico contar con un recurso tecnolgico que facilite el desempeo de sus labores. Esta herramienta de automatizacin minimizar la duplicacin de trabajo, contiene una base de datos actualizada para almacenar informacin y permite visualizar e imprimir reportes necesarios para la agilizacin de los todos procesos

administrativos. Este software contribuir y trabajara coordinadamente con todos los sistemas que se desarrollen futuramente en el Ncleo de Monagas, pues contribuye a la bsqueda de un mecanismo automatizado que se comuniquen sincronizadamente todos los procesos de la universidad.

13

2.4. Alcance de la Investigacin. El alcance de la presente investigacin est dado por la implantacin de un sistema automatizado en el rea de Servicios Mdicos para lo cual fue necesario abarcara hasta la etapa implementacin y gestin de soporte implantacin segn la metodologa GRAY WACHT, donde se entregue la aplicacin completa con su manual y capacitacin de los usuarios. 2.5. Limitaciones de la investigacin. El sistema est ubicado en rea Servicios Mdicos la Universidad de Oriente Ncleo de Monagas, es un software que cumple nicamente con las polticas, reglas, especificaciones y requerimientos propia del rea, el cual permite que todos sus mdulos en conjunto no puedan ser adaptados a otro espacio de trabajo. Para que el sistema funcione adecuadamente se necesita una unidad central de procesamiento (CPU) Pentium IV, se recomienda 1024 megabyte (MB)/1 GB de memoria RAM, Disco Duro de 160 GB y Sistema operativo Windows XP. Servidor Apache, PHP y un Navegador Web.

14

CAPITULO III MARCO REFERENCIAL

3.1. Antecedentes de la Investigacin Para abordar los antecedentes que sirvieron de base a la investigacin en referencia, se procedi a la revisin de algunos estudios relacionados con el problema, incorporaron elementos de relevancia. Entre ellos: El Trabajo de Grado realizado por Cabello, M. (2009) titulado: Sistema automatizado basado en software libre para optimizar los procesos administrativos de los servicios mdicos de la universidad de Oriente ncleo Monagas. Dicho trabajo fue efectuado para optar al ttulo de Ingeniero de Sistemas en la Universidad de Oriente y tena como objetivo automatizar los procesos administrativos que se llevan a cabo en el rea de servicios mdicos de la Universidad de Oriente Ncleo Monagas y hace uso de la metodologa de desarrollo RUP. Esta investigacin fue la precursora del presente trabajo que da continuidad al diseo y desarrollo del software ya propuesto. Esta investigacin constituye un referente por cuanto fue la gua de estudio durante el desarrollo del software, ayud a comprender los procesos del rea de servicio mdico, contribuy a representar el nuevo modelo de negocio, la arquitectura del software a implantar, sirvi de soporte para ayudar a establecer el nuevo diseo arquitectnico se ajustara a los nuevos requisitos y objetivos de este trabajo especial de grado. Adems de ser un proyecto basado en los criterios del software libre en Venezuela. Abreu. M. (2007) realiz una investigacin titulada: Modelo de negocios del departamento tcnico de la direccin de servicios generales de la Universidad de los

Andes, este proyecto de grado fue presentado en la Universidad de Los Andes como requisito final para optar al ttulo de Ingeniero de Sistemas y tena como objetivo documentar la situacin del Departamento Tcnico de la Direccin de Servicios Generales de la Universidad de los Andes, para desarrollar un Modelo de Negocios que hiciera posible entender sus elementos claves, planificar su infraestructura informtica, y formalizar sus sistemas y procedimientos. El desarrollo del modelo fue guiado por la Metodologa BMM (Business Modeling Method) de Montilva y Barrios (2003), y representado a travs del lenguaje grfico UML (Unified Modeling Language) y su extensin UML Business propuesta por Eriksson & Penker (2000). Esta investigacin se tomo como orientacin y gua, su aporte ms significativo est relacionado con la formulacin del Modelo de Negocios del rea de servicios mdicos; facilit representar los elementos (procesos, actores, reglas, estructura organizativa, entidades o recursos) que lo conforman. En la misma perspectiva Carruz, A (2003) llev a cabo una investigacin titulada: Automatizacin de procesos en el sector sanitario e historia clnica electrnica. Hospital Universitario de Valladolid, cuyo objetivo fue desarrollar un sistema centrado en los aspectos ms clnicos de los procesos asistenciales de un hospital y en la elaboracin de la historia electrnica. El diseo y desarrollo de la plataforma para la construccin de sistemas de informacin y automatizacin de procesos recoge conocimiento especficamente clnico. El desarrollo del proyecto permiti concluir que la tecnologa de la informacin y la comunicacin (TIC) pueden ayudar en gran medida a mejorar la eficiencia de los procesos asistenciales y administrativos, as como la accesibilidad de la informacin contenida en la historia mdica, manteniendo siempre una visin de futuro que permita que la aplicacin sea una respuesta adecuada a los problemas informativos de continuidad asistencial y que sea una base para llegar al historia unificado de salud, plasmando la iniciativa de contar con una historia nica para cada una de las ramas de la medicina.

16

Se acota la importancia de los sistemas de informacin, puestos en marchas como proyectos automatizados para generar cambios favorables en los procesos, ajustados a los requerimientos de un centro de salud con una visin amplia y futurista que permita las incorporaciones progresivas de nuevos proyectos que fortalezcan el sistema automatizado, dando respuestas a las distintas necesidades que pueden presentarse en esta rea. 3.2. Bases Tericas 3.2.1 Sistema de Informacin Transaccionales Los sistemas de informacin transaccionales segn Pastor, J (2002): Son aquellos sistemas que se encargan de manera especfica de procesar tanto las transacciones de informacin provocadas por las interacciones formales entre el entorno y la organizacin como las transacciones generadas en el seno de la organizacin. (p.11). As mismo el (SIT) procesa las transacciones propias de un proceso

logstico: pedidos, facturas, despachos, rdenes de compra, devoluciones, lista de empaque, pagos, entre otros. Adems los sistemas transaccionales gerencian modelos de reposicin, de compra y de ruteos, todo esto actividad rutinaria de la funcin logstica. De este modo acota entre sus principales caractersticas: a) A travs de stos suelen lograrse ahorros significativos de mano de obra, debido a que automatizan tareas operativas de la organizacin. b) Con frecuencia son el primer tipo de Sistemas de Informacin que se implanta en las organizaciones. Se empieza apoyando las tareas a nivel operativo de la organizacin. c) Son intensivos en entrada y salid de informacin; sus clculos y procesos suelen ser simples y poco sofisticados.

17

d) Tienen la propiedad de ser recolectores de informacin, es decir, a travs de estos sistemas se cargan las grandes bases de informacin para su explotacin posterior. e) Son fciles de justificar ante la direccin general, ya que sus beneficios son visibles y palpables. 3.2.2. El Mtodo Gray Watch Para producir una aplicacin empresarial es necesario disponer de un mtodo de desarrollo del software que est bien definido y documentado. Este mtodo debe establecer las actividades, los procesos, las prcticas, las tcnicas, los estndares y las herramientas que deben emplear para desarrollar los componentes arquitectnicos de una aplicacin empresarial e integrarla al sistema de negocios para el cual ella es desarrollada. El mtodo WATCH es un marco metodolgico que describe los procesos tcnicos, gerenciales y de soporte que deben emplear los equipos de trabajo que tendrn a su cargo el desarrollo de aplicaciones de software empresarial. El mtodo WATCH est fundamentado en las mejores prcticas de la Ingeniera de Software y la Gestin de Proyectos. Cubre todo el ciclo de vida de las aplicaciones; desde el modelado del dominio de la aplicacin, pasando por la definicin de los requisitos de los usuarios, hasta la puesta en operacin de la aplicacin. Este mtodo incluye, tambin, una descripcin de los procesos de gerencia del proyecto que se aplicarn para garantizar que el proyecto se ejecute en el tiempo previsto, dentro del presupuesto acordado y segn los estndares de calidad establecidos. En el diseo de este mtodo se emplearon, como marcos de referencia para la elaboracin de los elementos que integran el mtodo, los siguientes estndares, prcticas y modelos:

18

a. El modelo CMMI-SW (Capability Maturity Model Integration) del Instituto de Ingeniera de Software SEI (CMMI, 2005). b. El cuerpo de conocimientos de la Ingeniera de Software (SWEBOK) de la Sociedad de Computacin de la IEEE. c. El cuerpo de conocimientos PMBOK (Project Management Body of Knowledge) del Instituto de Gestin de Proyectos (PMI, 2000). d. Estndares de desarrollo de software de la Sociedad de Computacin de la IEEE. e. Modelos de procesos de los enfoques de desarrollo de software siguientes: f. Desarrollo guiado por modelos (Model Driven Development) g. Desarrollo guiado por pruebas (Test Driven Development) h. Las mejores prcticas de la Ingeniera de Software (Krutchen, 2000): Desarrollo iterativo, incremental y versionado, Ingeniera de Requisitos Arquitecturas basadas en componentes de software, Uso de lenguajes de modelado visual: UML y UML Business, Gestin integral del proyecto,Verificacin y validacin de la calidad de los productos y procesos y Gestin de la configuracin (control de cambios).

3.2.2.1. Objetivos del mtodo WATCH WATCH es un mtodo que ha sido elaborado expresamente para ser utilizado durante el desarrollo de aplicaciones empresariales, con la finalidad de:

a. Orientar a los equipos de desarrollo acerca de qu deben hacer y cmo deben desarrollar una aplicacin empresarial.

b. Garantizar la uniformidad, consistencia, facilidad de integracin y calidad de los distintos componentes arquitectnicos que integrarn una aplicacin empresarial. 19

c. Gestionar el desarrollo de aplicaciones empresariales como proyectos de ingeniera, siguiendo los estndares de gestin de proyectos ms utilizados en la Industria del d. Software, a fin de garantizar que la aplicacin se entregue a tiempo y dentro del presupuesto acordado con el cliente.

e. Asegurar que en el desarrollo de cada aplicacin empresarial se empleen las mejores prcticas, tcnicas, herramientas, estndares y lenguajes aceptados internacionalmente para producir software de alta calidad. 3.2.2.2 Caractersticas del Mtodo WATCH

Las caractersticas ms relevantes del mtodo WATCH son las siguientes:

A. Est slidamente fundamentado: Posee una base conceptual y metodolgica muy bien sustentada. El mtodo descansa en conceptos bien establecidos que se derivan de la Ingeniera de Software y los Sistemas de Informacin Empresarial. En concreto, el mtodo emplea una arquitectura de dominio de tres capas que define los elementos principales de las aplicaciones empresariales modernas. Metodolgicamente, el modelo ha sido elaborado tomando como referencia modelos de procesos bien conocidos o bien fundamentados, tales como el modelo RUP-Rational Unified Process (Krutchen, 2000) y versiones anteriores del mtodo WATCH (Montilva y Barrios, 2004b).

B. Es estructurado y modular: Posee una clara estructura que facilita su comprensin y utilizacin. Esta estructura separa los tres elementos primordiales de un mtodo: el producto que se quiere elaborar, los actores que lo elaboran y el proceso que siguen los actores para elaborar el producto. Estos tres elementos definen los tres componentes del mtodo WATCH:

20

modelo de productos, modelo de actores y modelo de procesos. Cada uno de ellos posee, a su vez, una estructura claramente visible y acorde al elemento que representa. As, por ejemplo, el modelo de procesos tiene una estructura jerrquica de, al menos, cinco niveles de profundidad: grupos de procesos, procesos, sub-procesos, actividades y tareas.

C. Es de propsito especfico: El mtodo est dirigido al desarrollo de aplicaciones de software en entornos empresariales; es decir, al desarrollo de aplicaciones que apoyan uno o ms sistemas de negocios de una empresa. Esta orientacin concreta y especfica resuelve los problemas que tienen la mayora de los mtodos comerciales y acadmicos existentes, cuya generalidad va en detrimento de su aplicabilidad en software especializado. El mtodo no es apropiado para desarrollar software del sistema (sistemas operativos, utilitarios, middleware, etc.), ni software de programacin (compiladores, editores, entornos de programacin, etc.)

D. Tampoco es til en el desarrollo de software de entretenimiento (videojuegos, herramientas multimedia, etc.). En aplicaciones especializadas, tales como sistemas de informacin geogrfica (GIS), sistemas de control, software educativo y software embebido, el usuario del mtodo debe hacer las adaptaciones pertinentes para ajustar el mtodo al dominio particular de este tipo de aplicaciones.

E. Es flexible y adaptable: Si bien el mtodo est dirigido al desarrollo de aplicaciones especializadas (aplicaciones de software empresarial), sus tres componentes pueden ser adaptados, con relativa facilidad, a otros tipos de productos de software. Esta labor, sin embargo, debe ser hecha por expertos en Ingeniera de Procesos de Software, para asegurar la correcta y efectiva adaptacin a otros tipos de aplicaciones.

21

F. Emplea las mejores prcticas del desarrollo de software: Al igual que otros mtodos bien establecidos, tales como RUP (Krutchen, 2000), XP y OOSE (Jacobson, 1994), el mtodo WATCH emplea prcticas metodolgicas internacionalmente aceptadas y utilizadas en la industria del software, las cuales, al ser aplicadas apropiadamente, contribuyen a resolver muchos de los problemas que, comnmente, se le atribuyen a los proyectos de software. Entre estas prcticas, se destacan las siguientes: i. Desarrollo de software iterativo, incremental y versionado.- WATCH considera el proceso de desarrollo de aplicaciones como un proceso iterativo. Cada iteracin produce un componente o una nueva versin operativa de la aplicacin. ii. Manejo eficiente de los requisitos.- Una mala gestin de los requisitos de una aplicacin es una de las principales causas de problemas en proyectos de desarrollo de software. Para evitar estos problemas, WATCH emplea las mejores prcticas, tcnicas y procesos de la Ingeniera de Requisitos, las cuales facilitan las actividades de identificacin, anlisis, especificacin, validacin y gestin de requisitos. iii. Reutilizacin de activos de software.- El mtodo promueve la reutilizacin de activos de software. Ello reduce costos y aumenta la calidad de los productos de software elaborados usando el mtodo. Entre estos activos estn los siguientes: arquitecturas de dominio, patrones de diseo, componentes de software reutilizables y plantillas de documentos (Ej., plantillas para planes de proyecto, formatos para pruebas de software, estructuras para manuales de uso, etc.). iv. Modelado visual de la aplicacin.- Para desarrollar una aplicacin informtica es indispensable modelar distintos aspectos de ella, en cada una de las etapas o fases de su desarrollo. WATCH emplea lenguajes de modelado grfico o visual ampliamente conocidos, tales como UML 2 (Eriksson et al, 2004) y UML Business (Eriksson and Penker, 2000). Estos lenguajes facilitan la

22

representacin de la aplicacin desde diferentes perspectivas y reducen los problemas de comunicacin que normalmente surgen entre los expertos en Informtica y los usuarios. v. Desarrollo basado en modelos.- Bajo este paradigma, el desarrollo de software es un proceso de transformacin gradual e iterativa de modelos elaborados usando lenguajes de modelado, tales como UML. Cada proceso tcnico del mtodo genera uno o ms modelos en UML 2 y/o UML Business. Estos modelos son transformados, gradualmente, en los procesos siguientes, hasta elaborar el producto final. Por ejemplo, el modelo de objetos de negocio, producido en el proceso de Modelado del Negocio, es transformado durante el proceso de Ingeniera de Requisitos en un modelo de clases de negocio. Este ltimo evoluciona, mediante transformaciones hechas en los procesos de Diseo Arquitectnico y Diseo Detallado, hasta convertirse en el modelo fsico de la base de datos, el cual es empleado durante el proceso de Programacin & Integracin para crear la base de datos de la aplicacin. La ventaja de esta prctica radica en que la transformacin de modelos se puede automatizar usando herramientas de desarrollo de software apropiadas, lo cual reduce significativamente el tiempo de desarrollo.

vi.

Verificacin continua de la calidad de los productos.- WATCH asegura la calidad de la aplicacin, a travs del uso de procesos bien definidos de Aseguramiento de la Calidad y Verificacin & Validacin de software (V&V). Los procesos V&V son aplicados a todos los productos intermedios y finales que se elaboran a lo largo del desarrollo de cada aplicacin.

vii.

Programacin guiada por las pruebas.- Para codificar los componentes de software, el mtodo emplea el enfoque de programacin guiada por las pruebas, la cual consiste en disear y preparar las pruebas de cada componente antes de iniciar su codificacin. De esta manera, la codificacin

23

se hace con la intencin de pasar la prueba, lo cual garantiza una mayor calidad del cdigo producido. La codificacin y la prueba unitaria del componente se hacen paralela y coordinadamente usando herramientas de pruebas automatizadas. viii. Apropiada gestin de cambios.- Los cambios en los requisitos y productos elaborados es una constante en el desarrollo de aplicaciones empresariales. Estos cambios pueden surgir en cualquier fase del desarrollo de una aplicacin, por lo que es necesario controlarlos apropiadamente, a fin de evitar que el proyecto se postergue continua o indefinidamente. WATCH emplea procesos bien definidos de Gestin de Requisitos y Gestin de la Configuracin de Software (SCM) que se encargan de controlar estos cambios. G. Emplea las mejores prcticas y procesos de gestin de proyectos: El mtodo WATCH emplea procesos y prcticas establecidas en el cuerpo de conocimientos de gestin de proyectos PMBOK propuesto por el PMI (2004). Este cuerpo de conocimientos fue usado durante el diseo del mtodo para definir y elaborar los procesos de gestin y parte de los procesos de soporte.

H. Integra los procesos de gestin con los procesos tcnicos y de soporte: WATCH define tres grupos de procesos: tcnicos, de gestin y de soporte. Los procesos tcnicos se relacionan con las actividades de anlisis, diseo, implementacin y pruebas de las aplicaciones. Los procesos de gestin se encargan de gerenciar el desarrollo de cada aplicacin como un proyecto de ingeniera; involucran, por lo tanto, actividades de planificacin,

organizacin, administracin, direccin y control del proyecto. Por su parte, los procesos de soporte complementan los procesos tcnicos y gerenciales con actividades, tales como: el aseguramiento de la calidad, la gestin de la configuracin y la gestin de riesgos del proyecto.

24

3.2.2.3 Componentes del mtodo WATCH El mtodo WATCH est compuesto por tres modelos fundamentales: A. Un modelo de productos que describe los productos intermedios y finales que se generan, mediante el uso del mtodo, durante el desarrollo de una aplicacin empresarial. B. Un modelo de actores que identifica a los actores interesados (stakeholders) en el desarrollo de una aplicacin y describe cmo deben estructurarse los equipos de desarrollo y cules deben ser los roles y responsabilidades de sus integrantes C. Un modelo de procesos que describe detalladamente los procesos tcnicos, gerenciales y de soporte que los equipos de desarrollo debern emplear para elaborar las aplicaciones. 3.2.3.4 Estructura del mtodo WATCH El mtodo WATCH est compuesto por tres modelos que describen los tres elementos claves de todo mtodo: el producto que se quiere elaborar, los actores que lo elaboran y el proceso que los actores deben seguir para elaborar el producto (ver Figura 3).
Class Estructura del Mtodo

Producto WATCH

Modelo de Productos

Modelo de Actores

Modelo de Procesos

Figura 3: Componentes del mtodo Gray Watch. Fuente: autor 2010.

El Modelo de Productos Este modelo identifica y describe los tipos de productos que se deben generar durante el desarrollo de una aplicacin empresarial. Estos tipos de productos se elaboran durante la ejecucin de los procesos tcnicos, de gestin o de soporte, que

25

estn descritos en el Modelo de Procesos del mtodo. La Figura 4 recoge los principales tipos de productos que se deben producir a lo largo del desarrollo de una aplicacin empresarial y los clasifica de acuerdo a los grupos de procesos donde ellos se generan. Los productos intermedios son todos aquellos documentos, modelos, listas, libreras de software, matrices, etc., que se elaboran durante la ejecucin de los procesos tcnicos, de soporte y de gestin y que son necesarios para desarrollar la aplicacin. No son considerados productos finales o entregables, por cuanto no constituyen parte integrante de la aplicacin. Los productos entregables o finales del proyecto son todos aquellos que conforman la aplicacin empresarial propiamente dicha y que son entregados al cliente al final de un ciclo de desarrollo o de todo el proyecto. En este grupo se incluyen todas las versiones de la aplicacin que se elaboran durante la vida del proyecto. Cada versin entregable est compuesta de programas, bases de datos y manuales.
Class Jerarquia de Producto

Producto WATCH

Producto Intermedio

Producto Entregable

Producto Tcnicos

Producto de Gestin

Producto de Soporte

Aplicacin Empresarial

Figura 4: Principales tipos de productos del mtodo Gray Watch. Fuente: autor 2010.

El Modelo de Actores El Modelo de Actores tiene como objetivos: a) Identificar los actores o interesados (stakeholders) que estn involucrados en el desarrollo de aplicaciones empresarial. 26

b) Describir las modalidades de organizacin del equipo de trabajo que desarrollar los diferentes componentes arquitectnicos de una aplicacin empresarial

c) Definir los roles y responsabilidades de aquellos actores que integrarn el equipo de trabajo.

La Figura 5 clasifica, al ms alto nivel de abstraccin, a los actores que participan el desarrollo de aplicaciones aplicacin empresarial en cuatro grupos diferentes.
Class taxonoma de actores (Stakeholder)

Actor (Stakehold er) Cliente Promoto r Desarrolla dor Usuario

Figura 5: Clasificacin de los actores. Fuente: autor 2010.

Los clientes son aquellas personas o unidades organizacionales que contratan el desarrollo de la aplicacin y aportan los recursos financieros necesarios para su desarrollo. Los promotores son aquellas personas o unidades organizacionales que tienen inters en que la aplicacin se desarrolle y, por consiguiente, promueven y apoyan su desarrollo. Los desarrolladores son personas o grupos que participan en la ejecucin de los procesos tcnicos, de gestin y/o soporte del desarrollo de la aplicacin. Los usuarios son todas aquellas personas, unidades organizacionales u organizaciones externas que hacen uso de los servicios que ofrece la aplicacin.

27

El Modelo de Procesos El objetivo de este modelo es describir los procesos tcnicos, de gestin y de soporte que los equipos de trabajo deben emplear para desarrollar una aplicacin empresarial. Estos procesos se organizan en la forma de una cadena de valor, tal como se ilustra en la Figura 6.

Analysis cadena de valor WATCH

Modelo de negocio

Ingeniera de requisitos

Diseo Arquitectnico

Diseo de componentes

Programacin & Integracin

Pruebas de la Aplicacin

Entrega de la Aplicacin

Gestin del proyecto: alcance, tiempo, costo, recursos y contratos Gestin de Riesgo Gestin de Configuracin Gestin de la Calidad

Figura 6: Cadena de valor de Procesos del mtodo WATCH. Fuente: autor 2010.

Estos procesos se clasifican, segn su naturaleza con respecto al proceso de desarrollo de software, en tres grupos: procesos tcnicos, procesos de gestin y procesos de soporte (ver Figura 7).

Modelo de Procesos

Procesos Tcnicos

Procesos de Gestin

Procesos de Soporte

Figura 7: Procesos del mtodo WATCH. Fuente: autor 2010.

28

El grupo de procesos tcnicos se encarga de organizar las actividades tecnolgicas que caracterizan el desarrollo de una aplicacin empresarial cualquiera e incluye los siguientes procesos:

A. Modelado del Negocio.- Agrupa a las actividades encargas de caracterizar y entender el dominio de la aplicacin, es decir, el sistema de negocios para el cual se desarrolla la aplicacin.

B. Ingeniera de Requisitos.- Incluye todas las actividades necesarias para identificar, analizar, especificar, validar y gestionar los requisitos que se le imponen a la aplicacin.

C. Diseo Arquitectnico.- Congrega las actividades necesarias para especificar, disear y documentar la arquitectura de software que debe tener la aplicacin.

D. Diseo de Componentes.- Organiza todas actividades de diseo detallado de los componentes arquitectnicos relacionados con la interfaz grfica de la aplicacin, sus componentes de software, su base de datos y su interaccin con otras aplicaciones.

E. Programacin & Integracin.- Agrupa las actividades de diseo detallado, codificacin y prueba unitaria de cada uno de los componentes de software que integran la arquitectura de la aplicacin, as como las actividades de integracin y prueba de la integracin de estos componentes.

F. Pruebas de la Aplicacin.- Ordena las actividades de pruebas de la aplicacin como un todo, incluyendo las pruebas funcionales, no-funcionales y de aceptacin de la aplicacin.

29

G. Entrega de la Aplicacin.- Estructura el conjunto de actividades que preceden a la puesta en produccin de la aplicacin. Incluye la capacitacin de usuarios, la instalacin de la aplicacin en su plataforma de produccin u operacin, las pruebas de instalacin y la entrega final del producto.

El grupo de procesos de gestin apoya la ejecucin de todos los procesos tcnicos y est relacionado con la gestin del proyecto. Se encarga de administrar el alcance, los tiempos, los costos, los recursos humanos y dems recursos que se requieran para desarrollar la aplicacin. Este grupo incluye los siguientes procesos:

A. Constitucin del Proyecto.- Establece las actividades necesarias para promover, justificar, aprobar e iniciar el proyecto.

B. Planificacin del Proyecto.- Incluye las actividades encargadas de la planificacin del alcance, tiempos, recursos humanos, otros recursos y servicios que requiera el desarrollo de la aplicacin

C. Direccin del Proyecto.- Agrupa las actividades de conformacin del equipo de trabajo, capacitacin del personal que integra estos equipos, administracin de contratos con terceros, coordinacin de la ejecucin de las actividades del proyecto y administracin de los recursos asignados al proyecto, entre otros.

D. Control del Proyecto.- Contiene las actividades necesarias para supervisar y controlar el alcance, tiempos, costos, recursos humanos y dems recursos que han sido asignados al proyecto.

E. Cierre del Proyecto.- Organiza las actividades que se requieren para cerrar administrativa y tcnicamente el proyecto, una vez que concluya el desarrollo completo de la aplicacin.

30

El grupo de procesos de soporte complementan los procesos de gestin y, al igual que estos ltimos, apoyan la ejecucin de todos los procesos tcnicos. Este grupo se relaciona con la calidad, los riegos y la configuracin de la aplicacin. Incluye los siguientes procesos:

1. Gestin de Riesgos.- Agrupa las actividades necesarias para identificar, analizar, planificar respuestas, monitorear y controlar todos aquellos riesgos o eventos que puedan afectar negativamente el proyecto.

2. Gestin de la Configuracin.- Organiza las actividades encargadas del control de los cambios que puedan surgir en la configuracin de la aplicacin, es decir, en los diferentes tems o productos que la integran y que se desarrollan a lo largo del proyecto.

3. Gestin de la Calidad.- Contempla las actividades necesarias para garantizar la calidad de la aplicacin y todos los productos que la integran, as como la calidad del proceso usado para producir estos productos. Este proceso est relacionado con las actividades de Aseguramiento de la Calidad del Software y la Verificacin & Validacin del Software.

El orden en que los procesos del mtodo se ejecutan est inspirado en la metfora del reloj; metfora en la cual el proceso de desarrollo de software es visto como un reloj, cuyo motor son los procesos de gestin y soporte y cuyos diales constituyen los procesos tcnicos. Esta metfora determina la estructura del modelo de procesos (ver Figura 8).

31

Analysis Flujo de Procesos Principales

SI NO

Modelado del Negocio

Nueva Versin?

Entrega de la Aplicacin

Inicio

Ingeniera de Requisitos

Procesos de Gestin y Soporte

Prueba de la Aplicacin Diseo Arquitectnico

Programacin & Integracin

Diseo Detallado

Figura 8: Estructura del Modelo de Procesos. Fuente: Autor (2010).

De acuerdo a la estructura del modelo, el proceso de desarrollo de software se inicia con la constitucin y planificacin del proyecto, la cual es parte de los procesos de gestin. Una vez planificado el proyecto, se da inicio a sus procesos tcnicos mediante la ejecucin del Modelado del Negocio. Se continua, luego, con los procesos de Ingeniera de Requisitos, Diseo Arquitectnico, Diseo Detallado, Programacin & Integracin y Pruebas de la Aplicacin, en el orden indicado por las agujas del reloj; finalizando con la Entrega de la Aplicacin. Como puede observarse, en la figuran n8, el orden de ejecucin es cclico, es decir, la aplicacin se desarrolla mediante la entrega de una o ms versiones de la

32

aplicacin. Cada ciclo de desarrollo produce una nueva versin operativa de la aplicacin. Una versin es un producto operativo, esto es, ejecutable y que provee ciertos servicios a sus usuarios. Cada nueva versin la agrega, a la anterior, nuevos servicios o funciones. Los ciclos de desarrollo se repiten hasta completar al conjunto total de servicios o funciones que demandan sus usuarios y que estn indicados en la arquitectura de la aplicacin. El proyecto culmina cuando se entrega la ltima versin prevista de la aplicacin. Las versiones definen el carcter versionado o cclico del mtodo. Cada versin, a su vez, est compuesta de uno o ms incrementos de software. Un incremento es una pieza de software que ejecuta un conjunto de funciones de la versin y que es usada, por los usuarios, para: validar las funciones implementadas por el incremento, familiarizarse con la interfaz grfica de la aplicacin; y/o usarla para apoyar la ejecucin de procesos de negocio. Los incrementos definen el carcter incremental del mtodo. Uno de los procesos de soporte, denominado Verificacin y Validacin (V&V), se encarga de evaluar cada producto de los procesos tcnicos, a fin de determinar si el proceso contina hacia el siguiente proceso debe retornarse a un proceso anterior para corregir defectos en los productos. El carcter iterativo del mtodo es determinado, en parte, por el proceso V&V. 3.2.3 Lenguaje de Modelado Unificado El UML (Unified Modeling Language) tiene sus orgenes en la necesidad que se haba generado en la industria para construir modelos orientados a objetos.Nace en el ao 1994 por iniciativa de Grady Booch y Jim Rumbaugh paracombinar dos famosos mtodos: el de Booch y el OMT (Object Modeling Technique). Ms tarde se les uni Ivar Jacobson, creador del mtodo OOSE (Object-Oriented Software Engineering). En respuesta a una peticin de OMG (Object Management Group), para definir un lenguaje y una notacin estndar del lenguaje de construccin de modelos, en 1997 propusieron el UML como candidato. UML es ante todo un

33

lenguaje, lenguaje que se centra en representacin grfica de un sistema. Es un lenguaje visual estndar empleado para la especificacin, construccin y documentacin de software orientado a objetos, por medio de diversos elementos y procesos que interactan de alguna forma con el software. 3.2.3.1. UML 2.0 sta versin del lenguaje UML incorpora nuevos smbolos que hacen ms fcil el modelado del comportamiento dinmico del sistema, razn por la cual es usada en el desarrollo de este proyecto para modelar el diagrama de actividades. Los Diagramas de Actividades capturan las acciones de una actividad y sus resultados, es decir muestran el flujo de trabajo desde el punto de inicio hasta el punto final. Su utilidad en el Modelado de Negocios permite detallar el proceso involucrado en las actividades del negocio. Pueden ser atribuidas algunas caractersticas como:

a) Enfatizan la secuencia de acciones de una actividad. b) Modelan el flujo de control y/o el flujo de objetos de una actividad. 3.2.3.2 Diagramas UML Los diagramas son la representacin grfica de una coleccin de elementos con sus relaciones, ofreciendo as una vista del sistema a modelar. Para poder representar de forma correcta un sistema, el lenguaje presenta una amplia variedad de diagramas para as visualizar el sistema desde diversas perspectivas.

Entre esos diagramas se encuentran: A. Diagramas de Casos de Uso B. Diagramas de Clase C. Diagramas de Secuencias D. Diagramas de Actividades E. Diagramas de Paquetes

34

3.2.3.2.1 Diagrama de caso de uso. Los elementos que pueden aparecer en un diagrama de casos de uso segn lo cita Ferre, X., et al (2005), son: actores, casos de uso y relaciones entre casos de uso. A. Un actor es una entidad externa al sistema que realiza algn tipo de interaccin con el mismo. Se representa mediante una figura humana dibujada con palotes. Dicha representacin sirve tanto para actores que son personas como para otros tipos de actores (sistemas, sensores, etc.).

Actor
Figura 9: Actor. Fuente: Autor (2010).

B. Un caso de uso, es una descripcin de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea en especfico. Se representa mediante una elipse con el nombre del caso de uso en su interior.

Caso de Uso

Figura 10: Caso de Uso. Fuente: Autor (2010)

C. Las relaciones entre casos de usos pueden ser de extiende; cuando un caso de uso especializa a otro extendiendo su funcionalidad, de inclusin, cuando un caso de uso utiliza a otro y de asociacin para comunicar a un actor con otro.

35

Tipo de Relaciones Asociacin Include Extends

Include>> Extends>>

Figura 11: Tipos de Relaciones. Fuente: Autor (2010)

3.2.3.2.2 Diagrama de clases. Es un diagrama que muestra la estructura esttica de un modelo, las cosas que existen en trminos de clases, su estructura interna y relaciones entre ellas, es decir las caractersticas de cada una de las clases, interfaces colaboraciones y relaciones de dependencia y generalizacin. Un diagrama de clases est compuesto por los siguientes elementos: Clase: Una clase es un conjunto de objetos que comparten una estructura comn y un comportamiento comn. Nombre de la Clase Atributos Mtodos u Operaciones

Figura 12: Representacin de una Clase. Fuente: Autor (2009).

Los atributos o caractersticas de las clases pueden ser de tres tipos, segn el grado de comunicacin y visibilidad de ellos con el entorno, estos son:

36

Pblicos (+): indican que el atributo ser visible tanto fuera como dentro de la clase, es decir, es accesible desde todos lados. Privados (-): indican que el atributo solo ser accesible desde dentro de la clase (solo sus mtodos lo pueden acceder) Protegidos (#) indica que el atributo no ser accesible desde afuera de la clase, pero si podr ser accesado por mtodos de la clase. Los mtodos u operaciones de una clase son la forma en cmo esta interacta con su entorno, estos pueden tener las caractersticas: Publico (+): indican que el mtodo ser visible tanto fuera como dentro de la clase, es decir, es accesible desde todos lados. Privados (-): indican que el mtodo solo ser accesible desde dentro de la clase (solo otros mtodos de la clase lo pueden acceder) Protegidos (#) indica que el mtodo no ser accesible desde afuera de la clase, pero si podr ser accesado por mtodos de la clase. Segn Bell, D (2007), existen cinco tipos de relaciones diferentes entre clases: dependencia, generalizacin, asociacin, agregacin y composicin: A. Dependencia: Es una relacin de uso, es decir una clase usa a otra, que la necesita para su cometido. Se representa con una flecha discontinua que va desde la clase utilizadora a la clase utilizada. Con la dependencia se muestra que un cambio en la clase utilizada puede afectar el funcionamiento de la clase utilizadora, pero no al contrario.

37

B. Generalizacin: Es un relacin entre un elemento ms general (el padre) y elemento ms especfico (el hijo). El elemento ms especfico es totalmente consistente con el elemento ms general y contiene la informacin adicional, tambin se define como la herencia, donde tenemos una o varias clases padre o superclase o madre, y una clase hija o subclase. Por ejemplo, un animal es un concepto ms general que un gato, un perro o un pjaro. Inversamente, un gato es un concepto ms especfico que un animal. C. Agregacin: Es un tipo especial de asociacin que representa una relacin estructural entre las clases donde el llamado agregado indica el todo y el componente es una parte del mismo. D. Asociacin: Relacin estructural que describe un conjunto de conexiones entre objetos de forma bidireccional. E. Composicin: Es un tipo de agregacin donde la relacin de posesin es tan fuerte como para marcar otro tipo de relacin. Relaciones entre Clases

Tabla 1: Relacin entre clases. Fuente: Autor (2010).

3.2.3.2.3 Diagramas de Despliegue Son aquellos que muestran las relaciones fsicas entre los componentes de software y hardware en el sistema desarrollado, es decir cmo se encuentran y se mueven los componentes y los objetos. En otras palabras, los diagramas de despliegue muestran la configuracin de los elementos de procesamiento en tiempo de ejecucin y los componentes de software, procesos y objetos que residen en ellos.

38

Un Diagrama de Despliegue modela la arquitectura en tiempo de ejecucin de un sistema mostrando la configuracin de los elementos de hardware y mostrando cmo los elementos y artefactos del software se trazan en esos nodos. Elementos del Diagrama de Despliegue
Nombre Smbolo Descripcin Un nodo es un objeto fsico en tiempo de ejecucin que representa un recurso computacional, generalmente con memoria y capacidad de procesamiento. Se utiliza para identificar cualquier servidor, Terminal de trabajo u otro hardware host que se utiliza para desplegar componentes en el ambiente de produccin. Los componentes representan todos los tipos de elementos software que entran en la fabricacin de aplicaciones informticas.

Nodo

Componente

Interface

Las interfaces se utilizan como lazo de unin entre unos componentes y otros

Tabla 2: Elementos del diagrama de despliegue. Fuente: Autor (2010).

3.2.3.2.4 Diagrama de secuencia. Un diagrama de secuencia es un tipo de diagrama de interaccin en el cual se destaca el tiempo: los mensajes entre objetos vienen ordenados explcitamente por el instante en que se envan. Consta de dos ejes. Generalmente, el eje vertical es el eje del tiempo, transcurriendo ste de arriba a abajo. En el otro eje se muestran los objetos que participan en la interaccin, siendo el primero de ellos el actor que inicia la ejecucin de la secuencia modelada. De cada objeto parte una lnea discontinua, llamada lnea de la vida, que representa la vida del objeto durante la interaccin. Si el objeto existe durante toda la interaccin, ste aparecer en el eje horizontal y su lnea llegar hasta el final del diagrama de secuencia. Parr, M (2006). Los mensajes parten de la lnea de vida del objeto que lo enva hasta la lnea de vida del objeto al que va destinado. Cada mensaje lleva un nmero de secuencia creciente con el tiempo y el nombre de la operacin requerida, as como posibles argumentos que pueden utilizarse como valores de entrada y/o salida. Usualmente, no

39

se especifica una graduacin en el eje del tiempo, aunque podra hacerse para interacciones que modelen escenarios en tiempo real. Elementos del Diagrama de Secuencia:
Nombre Smbolo Descripcin

Lnea de Vida
Usuario del Sistema

Indica que indica el periodo en que estuvo vivo el objeto durante la secuencia de actividades.

Activacin

Muestra el periodo de tiempo en el cual el objeto se encuentra desarrollando alguna operacin, bien sea por s mismo o por medio de delegacin a alguno de sus atributos. Se denota como un rectngulo delgado sobre la lnea de vida del objeto.

Mensaje de un objeto a otro

El envo de mensajes entre objetos se denota mediante una lnea slida dirigida, desde el objeto que emite el mensaje hacia el objeto que lo ejecuta.

Mensaje a un mismo objeto

Como su nombre lo indica, es el mensaje que un objeto se enva a s mismo.

Tabla 3: Elementos de diagrama de secuencia. Fuente: Autor (2009)

3.2.3.2.5 Diagrama de actividades. Permiten modelar el comportamiento de un sistema o alguno de sus elementos, mostrando la secuencia de actividades o pasos que tienen lugar para la obtencin de un resultado o la consecucin de un determinado objetivo. Opcionalmente, permite mostrar los flujos de informacin (objetos) producidos como resultado de una actividad y que seran utilizados posiblemente como entrada por la actividad siguiente:

40

Nombre
Accin

Smbolo

Descripcin
Nodo de actividad Primitiva ejecutable de asignacin o computacin. Nodo de control que indica el inicio de un flujo de control cuando una actividad es invocada. Nodo de control que indica el fin de todos los flujos dentro de una actividad. Muestra el fin de la actividad. Eje de actividad para flujo de control. Conecta dos acciones. Usado para indicar secuencia.

Nodo de Inicio

Nodo fin de actividad Flujo de Control

Nodo de Sincronizacin (fork) Nodo de concurrencia (Join)

Nodo de control que divide un flujo en dos o ms flujos concurrentes (paralelos)

Nodo de control que sincroniza mltiples flujos.

Nodo de decisin

Nodo de control que selecciona entre dos o ms flujos de salida.

Tabla 4: Elementos de diagrama de despliegue. Fuente: Autor (2010)

3.2.3.2.6 Diagrama de Paquetes Un paquete es un mecanismo de agrupamiento empleado para organizar los elementos modelados en UML y para facilitar el manejo de los modelos de un sistema. Un paquete tiene un nombre propio, posee elementos de modelado como diagramas y pueden contener a su vez otros paquetes.

Figura 13: Smbolo de un Paquete. Fuente: Autor (2010).

41

3.2.3. Tarjetas CRC Aunque no forman parte de UML, otro mecanismo se utiliza algunas veces para ayudar a asignar responsabilidades e indicar las colaboraciones con otros objetos son las tarjetas CRC (Clase-Responsabilidad-Colaborador). Kent Beck y Ward Cunningham fueron quienes promovieron el uso de estas tearjetas y son los principales responsables de estimular a los diseadores de software a pensar de manera ms abstractas en trminos de asignacin de responsabilidades y colaboraciones, tambin del uso de los patrones.Las tarjetas CRC son fichas, una por cada clase, en las que se escriben brevemente, las responsabilidades de la clase, y una lista de objetos con los que colabora para llevar a cabo esas responsabilidades. Se desarrollan normalmente en una sesin de trabajo en grupo pequeo. Las tarjetas CRC son una tcnica para registrar los resultados de la asignacin de responsabilidades y asignaciones. La informacin recopilada se puede enriquecer utilizando diagramas de clases y de interaccin. Lo importante no son las tarjetas o los diagramas sino tener presente la asignacin de responsabilidades. (Larman, C., 2002, Pp 229-230).

Figura 14: Tarjeta CRC. Fuente: Autor (2010).

3.2.5. Arquitectura cliente- servidor La arquitectura bajo el modelo Cliente Servidor de acuerdo con el criterio de Gutirrez, J. (2005) es un protocolo orientado a conexin. No hay relaciones maestro/esclavo. Las aplicaciones, sin embargo, utilizan un modelo cliente/servidor en las comunicaciones. (p.3) En correspondencia con lo anterior el

42

mismo autor define al servidor como: Una aplicacin que ofrece un servicio a usuarios de Internet; un cliente es el que pide ese servicio. (p.3) Los usuarios invocan la parte cliente de la aplicacin, que construye una solicitud para ese servicio y se la enva al servidor de la aplicacin que usa TCP/IP como transporte. El servidor es como un programa que recibe una solicitud, realiza el servicio requerido y devuelve los resultados en forma de una respuesta. Generalmente un servidor puede tratar mltiples peticiones (mltiples clientes) al mismo tiempo.

Figura 15: El modelo de aplicacin cliente/servidor. Fuente: Autor (2010)

Algunos servidores esperan las solicitudes en puertos bien conocidos de modo que sus clientes saben a qu zcalo IP deben dirigir sus peticiones. El cliente emplea un puerto arbitrario para comunicarse. Los clientes que se quieren comunicar con un servidor que no usa un puerto bien conocido tienen otro mecanismo para saber a qu puerto dirigirse. Este mecanismo podra usar un servicio de registro como Portmap, que utiliza un puerto bien conocido.

43

3.2.6. Software libre El Software Libre es definido por su tipo de licenciamiento, por lo que se puede llamar software licenciado bajo condiciones libres. Segn Hernndez, J., (2005): un software o programa de computacin cuya licencia nos permite ejercer una serie de libertades:

a. La libertad de ejecutar el programa con cualquier propsito. b. La libertad de estudiar cmo funciona el programa y adaptarlo a las necesidades propias (para lo cual es una precondicin el acceso al cdigo fuente). c. La libertad de redistribuir copias del programa y de ese modo ayudar a otros. d. La libertad de mejorar el programa y liberar esas mejoras al pblico beneficiando as a toda la comunidad. (p. 17). El software libre se basa en la cooperacin y la transparencia y garantiza una serie de libertades a los usuarios. Bajo esta perspectiva el Software Libre slo exige una cosa, en el caso de la licencia GPL: y ellas es que si el programa resultante de la modificacin es distribuido, debe hacerse bajo las mismas condiciones del programa original. Las licencias que contienen esta condicin son llamadas licencias Copyleft, y su objetivo es evitar que se distribuyan obras derivadas bajo licencias privativas. Da Rosa F., y Heinz, F., (2007) corroboran esta apreciacin cuando sostienen que: El software libre es propiedad de todos y cada persona en el mundo tiene derecho a usar el software, modificarlo y copiarlo de la misma manera que los autores de este mismo. Es un legado de la humanidad que no tiene propietario, de la misma manera que 44

las leyes bsicas de la fsica o las matemticas. No existe un monopolio y no es necesario pagar peaje por su uso. (p.33). En tal sentido resulta interesante el hecho de que en los ltimos aos algunos gobiernos en el mundo, entre ellos, Venezuela, han iniciado el proceso de migracin hacia el Software Libre, sobre todo en la institucin pblica. Se acota adems que algunos de estos pases, han adoptado el Software Libre, para ahorrar dinero, otros lo han hecho por cuestiones de seguridad, otros para ayudar a la creacin de industrias locales y otros porque el software libre les pertenece. 3.2.6.1 Desarrollo de Software Libre Las condiciones de licenciamiento de los programas libres permiten la construccin comunitaria de software. Los desarrolladores de software pueden acudir a inmensas colecciones de programas y bibliotecas altamente funcionales e

intensamente probadas. Esto reduce el esfuerzo y el riesgo de desarrollo, comparado con la alternativa de empezar de cero. Usando el modo cooperativo de construccin, tan esencial al mtodo cientfico, y no se limitan las posibilidades del programa a lo que pueda ocurrrsele a un grupo pequeo de usuarios. El valor del software aumenta mientras ms se comparte. El efecto de red hace que un programa sea ms til, es ms fcil intercambiar informacin, experiencias y resultados con usuarios del mismo programa. El valor potencial de los programas libres es mayor que el de los no libres, tanto desde el punto de vista social como individual: no hay restricciones a la difusin del programa, y tampoco a su utilizacin. El modelo de negocios del Software Libre no parte de la produccin pseudo-industrial de programas para vender como producto terminado, sino en el agregado de valor. Esto posibilita muchos negocios en las reas de capacitacin, asesoramiento, adaptacin, documentacin, publicacin de libros, etc.

45

Para desarrolladores de software, el Software Libre ofrece una oportunidad poderossima para agregar valor mediante la ampliacin incremental de la funcionalidad de los programas. Cuando un desarrollador quiere satisfacer una necesidad y est trabajando con este software puede simplemente, agregar la funcionalidad necesaria al programa ya existente, y cobrar al usuario slo por el agregado. Desde esta perspectiva, el proceso resulta econmicamente viable, y contribuye a un crculo virtuoso: un programa ms funcional es ms tentador para usuarios potenciales, y mientras ms usuarios tengan un programa, existen mayores posibilidades de que puedan ser mejorados por otros usuarios duplicando la funcionalidad del programa y luego agregndole nueva funcin. (Da Rosa, F., y Heinz, F., 2007, pp. 37-40). 3.2.6. Sistemas de informacin aplicados al sector sanitario Cuando se plantea la necesidad de poner en prctica la tecnologa para automatizar los procesos dentro de una unidad o sector sanitario segn Carruz, A., et al (2003): La aplicacin no difiere de manera fundamental de las tecnologas que se aplican para la informatizacin de los procesos de negocio en otros sectores. Son igualmente aplicables tecnologas como los monitores transaccionales o los servidores de aplicacin para aplicaciones escalables, los workflow para automatizar procesos claramente definidos, los EAI (Enterprise Application Integration) para la interconexin de sistemas, etc. (p. 26 ) En correspondencia con ello, la tecnologa para automatizar es aplicable a cualquier mbito como herramienta para mejorar de una u otra forma los procesos implcitos dentro de una gestin. Sin embargo, el mismo autor puntualiza en determinados elementos cuando plantea que:

46

Solamente es preciso incidir en el factor ya apuntado de que los procesos en el sector sanitario estn, en muchos casos, poco formalizados, debido a hechos como la variabilidad de la prctica clnica y al poder de decisin de los mdicos. Es por ello que se debe ser muy prudente a la hora de introducir tecnologas que encorseten en exceso los procesos. La informatizacin de los procesos en sanidad debe ser, en muchos casos, una automatizacin laxa que deposite una parte importante de la lgica del proceso en los propios profesionales de la salud que son usuarios del sistema. (p.22) Ello implica que la automatizacin dentro esta rea, debe darse como un proceso eficiente, sencillo, centrado en procedimientos elementales, fcilmente

manejables por el personal de salud, de fcil comprensin y que facilite el conocimiento coadyuvando a la toma de decisiones. En este sentido, resulta adecuado complementar los sistemas de informacin sanitarios con elementos de trabajo colaborativos. 3.2.7. Herramientas de desarrollo. A. Sybase PowerDesigner 12.0. Sybase es una compaa lder en el desarrollo y expansin de tecnologa innovadora para la movilizacin de informacin y se ha ganado la confianza de muchas corporaciones importantes en el mundo, gracias a su habilidad en la gestin de informacin. Siendo PowerDesigner uno de sus productos, el cual es una herramienta para el modelamiento de datos y procesos de negocio (Wikipedia, 2008). A travs de esta herramienta, se pueden realizar los diagramas de UML de manera rpida, realizando as el diseo del sistema y manteniendo la trazabilidad del mismo B. Macromedia Dreamweaver 8. Sybase es una compaa lder en el desarrollo y expansin de tecnologa innovadora para la movilizacin de informacin y se ha ganado la confianza de

47

muchas corporaciones importantes en el mundo, gracias a su habilidad en la gestin de informacin. Siendo PowerDesigner uno de sus productos, el cual es una herramienta para el modelamiento de datos y procesos de negocio (Wikipedia, 2008). A travs de esta herramienta, se pueden realizar los diagramas de UML de manera rpida, realizando as el diseo del sistema y manteniendo la trazabilidad del mismo C. Macromedia Fireworks. Es una aplicacin verstil en forma de estudio que ofrece un ambiente eficiente para la creacin rpida de prototipos de sitios Web e interfaces de usuario, permite crear y editar imgenes de mapa de bits y vectoriales, disear efectos web, recortar y optimizar elementos grficos, ayudando a resolver los principales problemas que enfrentan los diseadores grficos y los creadores de sitios webs. 3.2.8. Lenguajes de Programacin Un lenguaje de programacin se refiere a cualquier lenguaje artificial que pueda ser empleado para definir una secuencia de instrucciones para su procesamiento por una computadora u ordenador. Por lo general, se encuentra formado por un conjunto de smbolos y reglas de tipo semnticas y sintcticas, que permiten a los programadores definir de manera precisa acerca de qu datos debe operar una computadora, cmo estos datos deben ser almacenados o transmitidos y qu acciones debe tomar ante diferentes eventos. A. HTML. HTML significa HyperText Markup Language, que en espaol se traduce a lenguaje de marcas de hipertexto. Es el lenguaje que ms predomina en la actualidad para construir pginas Web. Los documentos HTML son ficheros de texto plano que usan la extensin .htm o .html.

48

Los diferentes prrafos, encabezados, tablas, listas, etc. de un documento HTML, se sealan intercalando etiquetas, las cuales consisten en instrucciones breves de comienzo y fin, que tienen como finalidad indicar al navegador como debe ser mostrado el contenido de dicho documento. El lenguaje HTML puede ser creado y editado con cualquier editor de textos bsico admita texto sin formato como por ejemplo el bloc de notas de Windows o Gedit de Linux. Los procesadores de texto se utilizan para escribir documentos en lenguaje HTML que posteriormente ser interpretado por el programa navegador correspondiente. B. PHP. PHP (Hypertext Pre-processor ), es un lenguaje de alto nivel ejecutado por diferentes tipos de servidores, que toman el cdigo PHP como entrada, y crean pginas Web como salida. Posee variables, sentencias, condiciones, bucles y

funciones. Es publicado bajo la PHP license, y la Free Software Foundation considera este tipo de licencia como software libre. El lenguaje PHP posee la caracterstica de poder mezclarse con cdigo HTML, es multiplataforma, tiene capacidad de conexin con la mayora de los manejadores de base de daos que se emplean actualmente, posee una gran documentacin en su pgina oficial, destacando que todas sus funciones estn explicadas y ejemplificadas y permite las tcnicas de la programacin orientada a objetos. C. JavaScript. Javascriptt es un lenguaje de programacin interpretado, es decir, que no requiere ser compilado, utilizado para construir sitios WEB y hacerlos ms interactivos. Entre sus caractersticas principales, se puede mencionar que es un lenguaje basado en acciones, que gran parte de la programacin en dicho lenguaje est centrada en describir objetos, escribir funciones que respondan a movimientos del mouse, aperturas, utilizacin de teclas, cargas de pginas entre otros y es soportado por la mayora de los navegadores web. JavaScript naci de la necesidad de permitir a los autores o creadores de pginas web interactuar con sus usuarios, es decir crear pginas con una mayor complejidad ya que HTML 49

permite crear pginas estticas mostrando textos con estilos, pero exista la necesidad de tener mayor interaccin con los usuarios. 3.2.9. Base de Datos MySql MySQL, tal como define propiamente su parte de su nombre (SQL Structured Query Language), es el servidor de bases de datos relacionales ms comnmente utilizado en GNU/Linux. Fue desarrollado por la empresa MySQL AB, que cedi las licencias correspondientes al proyecto opensource, por lo que su rpido desarrollo es causa del empeo de millones de programadores de todo el mundo. Al ser un servidor de bases de datos relacionales, MySQL se convierte en una herramienta veloz en la accesibilidad a los datos introducidos en las distintas tablas independientes que forman las bases de datos de este lenguaje. MySQL es actualmente el sistema de bases de datos ms popular de la red. Casi la totalidad de servicios ofrecidos por nuestra empresa incluyen el soporte para bases de datos MySQL. Ben Laurie, (p. 568). 3.2.10. XAMMP Es un servidor independiente de plataforma, software libre, que consiste principalmente en la base de datos MySQL, el servidor web Apache y los intrpretes para lenguajes de script: PHP y Perl. El nombre proviene del acrnimo de X (para cualquiera de los diferentes sistemas operativos), Apache, MySQL, PHP, Perl. El programa esta liberado bajo la licencia GNU y acta como un servidor web libre, fcil de usar y capaz de interpretar pginas dinmicas. Actualmente XAMPP est disponible para Microsoft Windows, GNU/Linux, Solaris, y MacOS X. XAMPP solamente requiere de un archivo zip, tar, o exe a descargar y ejecutar, con unas pequeas configuraciones en alguno de sus componentes que el servidor web necesitar. XAMPP es regularmente actualizado para incorporar las ltimas

50

versiones de Apache/MySQL/PHP y Perl. Tambin incluye otros mdulos como OpenSSL, y phpMyAdmin. Para instalar XAMPP requiere solamente una pequea fraccin del tiempo necesario para descargar y configurar programas por separado eso es todo. Ben Laurie, (p. 568). 3.2.11. Web Apache Es un software (libre) servidor HTTP de cdigo abierto para plataformas Unix (BSD, GNU/Linux, etctera), Windows y otras, que implementa el protocolo HTTP/1.1 y la nocin de sitio virtual. Cuando comenz su desarrollo en 1995 se bas inicialmente en cdigo del popular NCSA HTTPd 1.3, pero ms tarde fue reescrito por completo. Su nombre se debe a que originalmente Apache consista solamente en un conjunto de parches a aplicar al servidor de NCSA. Era, en ingls, a patchy server (un servidor "parcheado"). El servidor Apache se desarrolla dentro del proyecto HTTP Server (httpd) de la Apache Software Foundation. Apache presenta entre otras caractersticas mensajes de error altamente configurables, bases de datos de autenticacin y negociado de contenido, pero fue criticado por la falta de una interfaz grfica que ayude en su configuracin. 3.3. Bases Legales Las bases legales que dan soporte al proyecto en referencia, se encuentras plasmadas en la: A. Constitucin de la Repblica Bolivariana de Venezuela (1999) Artculo 110: El Estado reconocer el inters pblico de la ciencia, la tecnologa, el conocimiento, la innovacin y sus aplicaciones y los servicios de informacin necesarios por ser instrumentos fundamentales para el desarrollo econmico social y poltico del pas, as como para la seguridad y soberana nacional..

51

Se infiere que todas las iniciativas en funcin de innovar los sistemas de informacin sern reconocidas como un instrumento para el desarrollo de las instituciones nacionales y por ende para el desarrollo nacional. B. Ley Orgnica de la Administracin Pblica ( 2001) Artculo 12. La actividad de la Administracin Pblica se desarrollar con base en los principios de economa, celeridad, simplicidad administrativa, eficacia, objetividad, imparcialidad, honestidad, transparencia, buena fe y confianza. Asimismo, se efectuar dentro de parmetros de racionalidad tcnica y jurdica. La simplificacin de los trmites administrativos ser tarea permanente de los rganos y entes de la Administracin Pblica.los rganos y entes de la Administracin Pblica debern utilizar las nuevas tecnologas que desarrolle la ciencia, tales como los medios electrnicos, informticos y telemticos, para su organizacin, funcionamiento y relacin con las personas., as como un mecanismo de comunicacin electrnica con dichos rganos y entes disponible para todas las personas va internet. Tal articulado se ajusta a los objetivos de optimizacin de los procesos administrativos del Servicio Mdicos de la Universidad de Oriente por cuanto la misma a pesar de ser un servicio dentro de un ente autnomo no deja de ser un ente nacional y en tal sentido corresponde acogerse a lo expresado por la ley. C. Decreto Rango y Fuerza de Ley Orgnica de Ciencia, Tecnologa e Innovacin en Consejo de Ministros (2002) Artculo 2.- Las actividades cientficas, tecnolgicas y de innovacin son de inters pblico y de inters general. Ello indica que ataen a todos los individuos y entes nacionales. Artculo 22.- El Ministerio de Ciencia y Tecnologa coordinar las actividades del Estado que, en el rea de tecnologas de informacin, fueren programadas. Asumir competencias que en materia de informtica, ejerca la Oficina Central de Estadstica e Informtica (OCEI), as como las siguientes:

52

1. Actuar como organismo rector del Ejecutivo Nacional en materia de tecnologas de informacin. 2. Establecer polticas en torno a la generacin de contenidos en la red, de los rganos y entes del Estado. 3. Establecer polticas orientadas a resguardar la inviolabilidad del carcter privado y confidencial de los datos electrnicos obtenidos en el ejercicio de las funciones de los organismos pblicos. 4. Fomentar y desarrollar acciones conducentes a la adaptacin y asimilacin de las tecnologas de informacin por la sociedad. En correspondencia con ambos artculos artculo el presente proyecto se ajusta a las aspiraciones de la ley por cuanto su desarrollado atiende a los lineamientos establecidos por la OCEI. D. Decreto N 3.390 de la Presidencia de la Repblica Bolivariana de Venezuela Gaceta 38.095 del 28/12/2004), sobre uso del Software Libre. La Administracin Pblica Nacional emplear prioritariamente Software Libre desarrollado con Estndares Abiertos, en sus sistemas, proyectos y servicios informticos. A tales fines, todos los rganos y entes de la Administracin Pblica Nacional iniciarn los procesos de migracin gradual y progresiva de stos hacia el Software Libre desarrollado con Estndares Abiertos.

El proyecto en referencia se ajusta a tales requerimientos como alternativa para incursionar en la migracin hacia el Software Libre dentro del sistema desarrollado para el Servicio Mdico de la Universidad de Oriente, Ncleo Monagas., dentro del marco de los planteamiento formulados por las Naciones Unidas a cuyos parmetros se ajusta Venezuela como parte de una poltica para los pases de Amrica Latina. 3.4. Definicin de Trminos Arquitectura: Una arquitectura es un entramado de componentes funcionales que aprovechando diferentes estndares, convenciones, reglas y procesos, permite

53

integrar una amplia gama de productos y servicios informticos, de manera que pueden ser utilizados eficazmente dentro de la organizacin. (Vega, E., 2005, p3) Caso de uso: Es una secuencia de acciones que el sistema lleva a cabo para ofrecer algn resultado de valor para un actor. Un actor puede ser una persona humana, un dispositivo de hardware, u otro sistema. Los actores utilizan el sistema interactuando con los casos de uso. (Jacobson, I., 2000, p.54). Cliente: Es el que inicia un requerimiento de servicio. El requerimiento inicial puede convertirse en mltiples requerimientos de trabajo a travs de redes LAN o WAN. La ubicacin de los datos o de las aplicaciones es totalmente transparente para el cliente. (Gutirrez, J., 2005, p3) Business: Negocio. Implementacin: es la realizacin de una aplicacin, o la ejecucin de un plan, idea, modelo cientfico, diseo, especificacin, estndar, algoritmo o poltica.En ciencias de la computacin, una implementacin es la realizacin de una especificacin tcnica o algoritmos como un programa, componente software, u otro sistema de cmputo. (Retamozo, P., 2003) Navegador Web: es una aplicacin software que permite al usuario recuperar y visualizar documentos de hipertexto, comnmente descritos en HTML, desde servidores web de todo el mundo a travs de Internet. (Wikipedia, 2008) Servidor: Es cualquier recurso de cmputo dedicado a responder a los requerimientos del cliente. Los servidores pueden estar conectados a los clientes a travs de redes LANs o WANs, para proveer de mltiples servicios a los clientes y ciudadanos tales como impresin, acceso a bases de datos, fax, procesamiento de imgenes, etc.(Gutirrez, J., 2005, p3)

54

Sistema de Informacin: Es un conjunto de personas, datos y procedimientos que funcionan en conjunto. Un sistema de informacin ejecuta tres actividades generales. En primer trmino recibe datos de fuentes internas o externas a la organizacin como elementos de entrada. Despus, acta sobre los datos para producir informacin. Finalmente el sistema produce la informacin para el futuro usuario, que tal vez sea gerente, administrador o un miembro de la direccin. (Retamozo, P., 2003) Software de dominio pblico: Es aqul que requiere de licencia y cuyos derechos de explotacin son para toda la humanidad, porque pertenece a todos por igual. (Wikipedia, 2008) Software Libre: Es un software o programa de computacin cuya licencia nos permite ejercer una serie de libertades. (Wikipedia, 2010)

55

CAPITULO IV MARCO METODOLGICO

4.1. Tipo y Nivel de la Investigacin ..tipo de Investigacin Interactiva, de la cual Hurtado (2000) expresa que: va dirigida a modificar situaciones concretas a travs de la aplicacin de proyectos previamente diseados. (p. 49). La misma atura seala:

Implica la realizacin de acciones por parte del investigador, ya sea solo o conjuntamente con algn grupo o comunidad, con el propsito de modificar una situacin o evento. Para llevar a cabo una investigacin Interactiva es necesario partir de un proceso de indagacin y explicacin, visualizar posibilidades futuras, planificar un conjunto de actividades o disear alguna propuesta, y posteriormente llevarla a cabo. (p. 351).

Es evidente que el trabajo que se desarrolla se corresponde con la definicin de Investigacin Interactiva antes sealado, esto si se toma en cuenta que permitir crear una solucin, apoyada en el uso de mtodos y herramientas tericamente sustentadas para modificar una situacin y que la misma se basar en el desarrollo de un diseo que ser llevado a cabo. Por el tipo de investigacin, el estudio se ubica dentro de un Nivel Integrativo, el cual Hurtado (2000), define como aquel que "contempla acciones directas por parte del investigador, sobre el evento de estudio, estas acciones van dirigidas a transformar o modificar el evento en algn aspecto" (p. 19).

56

4.2. Poblacin y Muestra 4.2.1. Poblacin De acuerdo con el criterio Hernndez, R., et al (2006), la poblacin es el conjunto de todos los casos que concuerdan con una serie de especificaciones . (p.238). En relacin a lo expuesto este conjunto de elementos pueden ser personas, casos, objetos, instituciones y otros, se seleccionan de ac uerdo a la naturaleza del problema y los objetivos de la investigacin. En efecto, para este estudio la poblacin est constituida por 16 funcionarios relacionados con las actividades administrativas que se realizan en el Servicio Mdico de la Universidad de Oriente Ncleo Monagas, dado que son las personas que manejan los procedimientos administrativos y que conocen la realidad y por lo tanto los requerimientos para elaborar un nuevo sistema. 4.2.2. Muestra La muestra es definida como el subgrupo de la poblacin de inters, sobre la cual se recolectan datos, debiendo esta ser representativa de la poblacin. (Ibdem, p.236). Ello implica que cuando la muestra es representativa de la poblacin, los resultados pueden generalizarse a todo el problema en estudio. En consecuencia, por ser la poblacin un conjunto pequeo, pueden estudiarse todos los elementos que la componen, segn sus caractersticas particulares. Esta decisin se basa en el criterio expuesto por Balestrini, M., (2006) (ob, cit), cuando seala que: Con excepcin de los casos o universos pequeos, es importante seleccionar sistemticamente en una muestra, cada unidad representativa de la poblacin, atendiendo a un criterio especfico y en condiciones controladas por el investigador (p. 138). En caso de esta investigacin la poblacin ser igual a la muestra, es decir, 16 funcionarios del Servicio Mdico de la Universidad de Oriente Ncleo Monagas.

57

4.3. Tcnicas e Instrumentos de Recoleccin de Datos. Para la recoleccin de los datos fue necesario aplicar algunas tcnicas que a travs de instrumentos permitieran recabar la informacin necesaria para determinar las caractersticas y requerimientos del desarrollo del sistema en relacin con las necesidades evidenciadas en los procesos administrativos del Servicio Mdico de la Universidad de Oriente, Ncleo Monagas. Arias, F., (2006) en relacin a las tcnicas refiere que Se entender por tcnica, el procedimiento o forma de recoger los datos (p.68), es decir la tcnica obedece a una manera o tctica utilizada por el investigador, de acuerdo con la disciplina o mbito de investigacin, de cual ste se vale para obtener la informacin. El instrumento es considerado como Cualquier recurso, dispositivo o formato (en papel o digital), que se utiliza para obtener, registrar o almacenar informacin (Ibdem, p.69). De esta manera el instrumento viene a constituirse en una herramienta que concreta los resultados concebidos bajo una tcnica determinada. En el caso de esta investigacin, tipificada como de campo y documental, se utilizaron las siguientes tcnicas e instrumentos: En el primer tipo, es decir, para la investigacin de campo, se utiliz la tcnica de la observacin y la entrevista no estructurada apoyada en instrumentos como el diario de campo y la libreta de notas. La observacin es una tcnica que consiste en visualizar o captar mediante la vista, en forma sistemtica, cualquier hecho, fenmeno o situacin que se produzca en la naturaleza o en la sociedad, en funcin de unos objetivos de investigacin preestablecidos. (Ibdem, p. 69) Lo anterior implica que el investigador se constituye en el principal factor para la captacin de la informacin. La entrevista, ms que un simple interrogatorio, es una tcnica basada en el dilogo o conversacin cara a cara, entre el entrevistador y el entrevistado acerca de un tema previamente determinado, de tal manera que el entrevistador pueda obtener la informacin requerida. (Ibdem, p.73)

58

Las preguntas se realizaron de manera libre y espontnea fundamentadas en dilogos y conversaciones con el personal del servicio mdico. En el segundo caso, se utiliz la tcnica del anlisis de contenido el cual permiten medir, ordenar, clasificar, codificar e interpretar el comportamiento de las variables objeto de estudio. El anlisis facilita llegar a las conclusiones o resultados del estudio; como instrumento se utilizaron los cuadros de registro diarios aportados por el personal que labora el Servicio Mdico y los cuales estn relacionados con: pacientes atendidos en el servicio mdico, clasificacin segn la especialidad y tipo de usuario, nmero de pacientes atendidos por cada mdico, morbilidad, registro de boletas y de facturas conformadas. (Ibdem, p.103) 4.4. Diseo Operativo Para el logro de los objetivos planteados, se utilizar el mtodo GRAY WATCH, por ser un mtodo de desarrollo de software configurable que se adapta a travs de los proyectos variados en tamaos y complejidad, que adems, describe que se debe hacer y cmo se debe desarrollar la aplicacin. Este mtodo establece las actividades los procesos, las prcticas, las tcnicas, los estndares, y las herramientas que se deben emplear para desarrollar los componentes arquitectnicos de la

aplicacin e integrarla al sistema de negocio para el cual es desarrollada. El desarrollo del proyecto abarcar todo el ciclo de vida de las aplicaciones; desde el modelado del dominio de la aplicacin, pasando por la definicin de los requisitos de los usuarios, hasta la puesta en operacin del sistema. Adems tambin se realizarn los procesos de gerencia del proyecto, que se encargan de gerenciar el desarrollo de la aplicacin, involucran las actividades de constitucin, planificacin, direccin y control del proyecto. Por su parte, los procesos de soporte complementan los procesos tcnicos y gerenciales con actividades, tales como: el aseguramiento de la calidad, la gestin de la configuracin y la gestin de riesgos del proyecto. El proyecto est dividido en cuatro (4) etapas:

59

Etapa I: Inicio y constitucin del proyecto En esta primera etapa se hace una revisin del modelado negocio, en este caso del rea de servicios mdicos de la Universidad de Oriente ncleo Monagas, para conocer los procesos que realiza el personal que labora en esta rea de trabajo. Luego de revisar el sistema del negocio se procede a realizar la instanciacin del mtodo GRAY WATCH, y adaptarla a las caractersticas particulares de la aplicacin y a las condiciones existentes en el rea de servicios mdicos. Tambin se incluyen las actividades encargadas de la planificacin del alcance, de tiempos, de gestin de los riesgos, configuracin del software, aseguramiento de la calidad, otros recursos y servicios que requiera el desarrollo de la aplicacin. En esta etapa se realiza el modelado de negocio para realizar el modelado del negocio se estudiar y analizar el sistema de negocio de: rea de Servicios Mdicos de la universidad de oriente ncleo Monagas, con el objetivo de comprender los problemas que motivan el desarrollo de la aplicacin y facilitar la identificacin de las necesidades de informacin que tienen los futuros usuarios del sistema Etapa II: Procesos de diseo, de gestin y de soporte Una vez constituido el proyecto, se da inicio a sus procesos tcnicos conformados por los procesos de anlisis, diseo e implementacin, en esta segunda etapa se desarrollan los procesos de anlisis conjuntamente con los procesos de gestin y de soporte. Los procesos de anlisis cubren la Ingeniera de Requisitos se va a revisar, analizar, especificar, validar y gestionar los requisitos que se le imponen a la aplicacin.

Etapa III: Procesos de construccin, de gestin y de soporte

En esta etapa, se continan con los procesos tcnicos relacionados con el cmo debe ser construido el nuevo sistema, este grupo de procesos est compuesto por los procesos de diseo arquitectnico y diseo detallado. Las actividades que se llevarn a cabo en el proceso de diseo arquitectnico comprenden: establecer el

60

conjunto de componentes que integran el sistema, definir los estndares de diseo, disear la arquitectura del sistema. Todo lo referente a diseo detallado comprende las actividades del diseo de la interfaz usuario/sistema, diseo de la base de datos del sistema y especificacin de los componentes arquitectnicos que conformarn el sistema para que ste satisfaga los requisitos establecidos.

Etapa IV: Procesos de implementacin.

Es la ltima etapa del proyecto y constituye la entrega de la aplicacin desarrollada. El proceso tcnico de implementacin involucra los procesos relacionados con la programacin, las pruebas y puesta en operacin del sistema. En el proceso de programacin e integracin se realiza la codificacin y prueba unitaria de cada uno de los componentes de software que integran la arquitectura de la aplicacin, as como la integracin y prueba de estos componentes.

Seguidamente se realizan pruebas de la aplicacin como un todo, incluyendo las pruebas funcionales, no-funcionales y de aceptacin. Durante la ejecucin de los procesos tcnicos de implementacin se elabora el documento del plan de verificacin & validacin(V&V) donde se va a describir las actividades, recursos y tcnicas necesarias para: verificar que cada uno de los productos del desarrollo de la aplicacin empresarial satisfacen los requisitos especificados en el documento de requisitos; y validar que la aplicacin satisface las necesidades de informacin de sus usuarios; y se elabora el documento del plan de pruebas que se deriva del plan V&V y describe las actividades de verificacin y validacin dinmica (pruebas de software), con la finalidad de detectar los errores en cada uno de los programas elaborados en el proceso de Programacin & Integracin.

Finalmente el proyecto culmina con la entrega de la aplicacin, que implica la puesta en produccin del nuevo sistema en su plataforma de operacin. Este proceso incluye la capacitacin de usuarios, la instalacin del sistema, las pruebas de

61

instalacin y la entrega final del producto. A continuacin se muestra el cuadro operativo y cronograma de actividades que especifican las fechas y las actividades que se llevaran a cado en cada una de las etapas del desarrollo del proyecto y que se han mencionado en esta descripcin del trabajo.

62

4.5. Cuadro Operativo

Etapas

Metodologa/ Herramienta

Actividades
Adaptar el mtodo GRAY WATCH a las caractersticas particulares y a las condiciones existentes en el rea de servicios mdicos. Revisar y conocer las condiciones existentes en el rea de servicios mdicos para el momento en que se desarrolla la aplicacin. Describir de manera general el sistema que se va a desarrollar.

Productos Generados
Documento de instanciacin del mtodo. Documento enunciado del trabajo del proyecto. Documento de inicio del proyecto. Plan integral del proyecto. Plan de Gestin de Riesgos Plan de Gestin de la configuracin Plan de gestin de Aseguramiento de la Calidad.

Objetivos especficos

Mtodo Watch I Anlisis del sistema Procesos de gestin y soporte

Establecer la necesidad y el alcance de la aplicacin que se quiere desarrollar. Describir las actividades que componen cada uno de los procesos. Definir los recursos humanos, tecnolgicos, financieros, fsicos y materiales necesarios para desarrollar las actividades. Identificar, describir y evaluar los riesgos inherentes a la aplicacin empresarial. Describir las actividades para controlar la configuracin del software.

1. Estudiar el modelo de negocio del rea de servicios mdicos, para obtener una visin del sistema a nivel conceptual.

Establecer, organizar y programar las actividades necesarias para asegurar la calidad del software.

Estudiar y analizar a profundidad el modelado del negocio, especificar cada uno de sus procesos. Aplicar entrevistas no estructuradas al personal del rea de servicios mdicos. Observacin directa. Revisar, analizar, describir, especificar funcionales y no funcionales del sistema. Documentar los requisitos funcionales. Elaborar y refinar los diagramas de caso de uso.

Modelo del negocio.

2. Determinar los requisitos del sistema funcionales y no funcionales, fortaleciendo y complementando el modelo actual.

y validar cada uno de los requisitos Documento de requisitos

Cuadro operativo 1/2. Fuente: autor (2010).

63

Etapas

Metodologa/ Herramienta

Actividades
Definir los estndares de diseo de la aplicacin. Establecer la arquitectura de la aplicacin.

Productos Generados
Documento de diseo arquitectnico.

Objetivos especficos

II Diseo del sistema Procesos de construccin, gestin y soporte

Mtodo Watch UML

Especificar los componentes arquitectnicos que conformarn la aplicacin empresarial para que sta satisfaga los requisitos establecidos. Disear la interfaz usuario/sistema. Codificar o programar cada uno de los componentes que integran las diferentes versiones de la aplicacin empresarial.

Documento de diseo detallado

3. Formular la arquitectura que debe tener el sistema a desarrollar tomando en cuenta los requisitos funcionales y no funcionales. 4. Construir el sistema con base a la arquitectura diseada.

Plan de verificacin y validacin Plan de pruebas. 5. Implementar el sistema, ya probado en su plataforma de operacin.

III Implementacin del sistema Procesos de implementacin.

Realizar las pruebas funcionales, no- funcionales y de aceptacin.

Mtodo Watch UML

Verificar cada versin de la aplicacin como un todo y depurar los errores encontrados. Realizar las pruebas de instalacin y la capacitacin de usuarios. Instalar el sistema en los servidores de produccin.

Especificaciones de prueba.

Aplicacin empresarial operativa versin beta funcional.

Cuadro operativo 2/2. Fuente: autor (2010).

64

CAPITULO V RESULTADOS
Dando cumplimiento a los objetivos especficos a continuacin se presenta la descripcin de los resultados obtenidos durante el desarrollo del proyecto: Para obtener la visin del sistema a nivel conceptual se estudio a profundidad el modelado de negocio el cual permiti revisar y verificar el dominio organizacional donde operaria el sistema, se simboliz mediante UML BUSINESS 2.0 que es una extensin del lenguaje UML orientado a procesos de negocio donde se incorporaron nuevos smbolos para modelar y emplearon estereotipos que agregan mayor semntica a los smbolos utilizados, para esto se adapto el mtodo GRAY WATCH que hace la planificacin e instanciacin de este proceso de gestin y se determino a las caractersticas particulares y a las condiciones existentes en el rea de servicios mdicos. Con el nuevo modelo de negocio se complemento y fortaleci el modelo ya existente. Se determinaron los requisitos funcionales y no funcionales del sistema elaborando el documento: definicin y especificacin de requisitos de software, los cuales permitieron capturar y analizar los requerimientos del usuario y as establecer y especificar las funcionalidades que tenda el sistema. Para el logro de este objetivo se hiso uso de los Diagramas de casos de uso, los cuales describieron las acciones del sistema desde el punto de vista del usuario, sta fue una herramienta valiosa, ya que es una tcnica de aciertos y errores en la que se obtuvo los requerimientos totales del sistema. Por su parte el desarrollo de la arquitectura del sistema quedo plasmado en el documento de diseo arquitectnico y detallado. Dicho diseo se realizo empleando

diferentes vistas o modelos que muestran aspectos de la arquitectura del sistema; entre estos se mencionan: la vista lgica que muestra las clases, sus relaciones, operaciones y atributos ms importantes, la vista de datos, el modelos conceptual, el modelo fsico, el modelo de base de datos relacional y por ltimo la vista de despliegue, que muestra la parte fsica de la arquitectura. Luego a partir de la arquitectura diseada se procedi a la codificacin de de las funcionalidades del sistema empleando herramientas de programacin y

desarrollo WEB, como el lenguaje HTML, JavaScript, PHP, AJAX, la aplicacin Macromedia Dreamweaver, servidor Web Apache, entre otros. Y seguidamente, se realizaron pruebas a los mdulos programados del software para comprobar el correcto funcionamiento de los mismos. Todo esto con el fin, de cumplir con el penltimo objetivo de la investigacin, es decir, construir el sistema con base a la arquitectura diseada. Finalmente se cumpli con el objetivo final realizando la implementacin en su plataforma de operacin, se verific que las pruebas unitarias unidas fueron capaces de garantizar que cada unidad cumpliera con los requisitos correspondientes,

adems, que el cdigo fue el correcto y cumpli con los estndares de codificacin establecidos. Se verifico, tambin, que la documentacin de uso y mantenimiento fue consistente con la aplicacin. Las pruebas de unidad y de integracin (incluyendo las pruebas funcionales, no funcionales, de aceptacin y de instalacin) garantizaron que la implementacin fue correcta y que ella y sus componentes cumplen con los requisitos establecidos.

UNUVERSIDAD DE ORIENTE NUCLEO MONAGAS CENTRO DE COMPUTACIN TODOS LOS DERECHOS RESERVADOS

5.1 ETAPA I. INICIO Y CONSTITUCIN DEL PROYECTO .PROCESO DE GESTIN

Centro de Computacin Seccin de Programas y Proyectos Implementacin de un sistema automatizado que optimice la gestin de los procesos administrativos del rea servicios mdicos de la universidad de oriente ncleo Monagas.
DOCUMENTO INICIO DEL PROYECTO

VERSIN
Autor Lolimar Cedeo M. Lolimar Cedeo M. Lolimar Cedeo M. Fecha 29-8-09 9-10-09 27-10-09 Versin 0.90 0.91 0.92

1.0

Descripcin Versin preliminar como propuesta de desarrollo Correcciones de versin preliminar Correcciones de versin preliminar

1. Introduccin Este es el primer documento formal del proyecto, el cual justificara econmica y tcnicamente la necesidad de desarrollar una nueva aplicacin empresarial. Su objetivo es explicar la necesidad de desarrollar la aplicacin, para dar respuesta a un conjunto de necesidades de informacin, que tiene una o ms unidades organizacionales de la empresa. Este documento se elabora para decidir si la aplicacin debe desarrollarse, diferirse o es improcedente. Esta decisin determina el inicio, diferimiento o cancelacin del proyecto, por lo tanto orientado a facilitar la toma de decisiones sobre el futuro del proyecto.

2. Objetivos y Alcance del proyecto 2.1 objetivos El objetivo del proyecto es implementar un sistema automatizado que optimice la gestin de los procesos administrativos del rea servicios mdicos de la universidad de oriente ncleo Monagas, y tiene como objetivos especficos: 1. Realizar el estudio de negocio del rea de servicios mdicos. 2. Listar requisitos funcionales y no funcionales del sistema. 3. Disear una nueva arquitectura que debe tener el sistema a desarrollar tomando en cuenta los requisitos funcionales y no funcionales. 4. Construir el sistema con base a la arquitectura diseada. 68

Centro de Computacin Seccin de Programas y Proyectos 5. Implementar el sistema, ya probado en su plataforma de operacin.

2.2 Alcance del Proyecto 2.2.1 Alcance del producto: El Software a desarrollar abarcar a nivel general funcionalidades de procesos para el control mdico: programacin de citas o consultas, historia mdica del paciente, elaboracin de rcipes mdicos, emisin de boletas para atencin especializada y exmenes de laboratorio. As como tambin, contar con un registro de la poblacin de usuarios del servicio, control de medicamentos y control de las facturas conformadas por el servicio mdico para su posterior cancelacin.

2.2.2 Alcance del proyecto: Abarcara hasta la etapa implementacin y gestin de soporte implantacin segn la metodologa GRAY WACHT, donde se entregue la aplicacin completa con su manual y capacitacin de los usuarios.

3. Caractersticas generales de la aplicacin El producto a desarrollar es un software que integre los procesos que se realizan en el rea de servicios mdicos, su funcionamiento ser:

A. Control Mdico: permite llevar un control de los procesos directamente relacionados con el servicio mdico, como la programacin de citas o consultas, elaboracin de historias mdicas, rcipes, emisin de boletas para remitir al paciente a un servicio externo y conformacin de facturas.

B. Control de medicamentos: llevar un control de las entradas y salidas de medicamentos. C. Reportes: visualizacin e impresin de reportes como las historias mdicas o 69

Centro de Computacin Seccin de Programas y Proyectos consultas de pacientes. D. Administracin: configurar los usuarios del sistema y efectuar modificaciones. E. Validar usuarios: permitir el ingreso de los usuarios finales del sistema.

El sistema realizar validaciones, lo que permita

minimizar la duplicacin de

trabajo, contar con un mdulo de administracin que permitir configurar los usuarios y monitorear los accesos, tendr una base de datos actualizada y segura para almacenar informacin en cualquier momento, permitir la automatizacin de procesos para facilitar el flujo de entradas y salidas del sistema, y en l se podr visualizar e imprimir administrativos. reportes necesarios para la agilizacin de los procesos

4. Requisitos inciales Para garantizar el rendimiento adecuado del proyecto a desarrollar y por ende del sistema propuesto es necesario contar con una serie de requisitos, en esta oportunidad se mencionarn los requisitos mnimos para comenzar con el proyecto, destacando que en la medida en que se avance en el desarrollo del mismo estos requisitos aumentaran.En cuanto a requisitos de hardware se debe contar con un computador para el manejo y almacenamiento de la informacin. En lo que respecta a software se requieren programas como: Macromedia Dreamweaver, Sybase, PowerDesigner, Microsoft Project y el servidor Apache.

Entre otros requisitos se encuentra el de proporcionar cursos en el manejo de herramientas tales como: Dreamweaver, PHP, Javascript, HTML, metodologa GRAY
WACHT y UML con la finalidad de capacitar al desarrollador involucrando en el

proyecto. Estos adiestramientos son indispensables para preparar al desarrollador y lograr la culminacin del proyecto en el tiempo establecido.

70

Centro de Computacin Seccin de Programas y Proyectos 5. Visin del Negocio La Universidad de Oriente Ncleo Monagas, Cuenta actualmente con una poblacin Estudiantil alrededor de 18.000 estudiantes, por ello cuenta con una Delegacin de Desarrollo estudiantil que estudia al educando dentro de su dimensin social con la finalidad de ofrecer diversas vas de solucin a los problemas que interfieren en su adecuado funcionamiento acadmico y social. Dentro de esta dependencia se encuentra el rea de servicios mdicos-odontolgicos el cual brinda atencin mdica preventiva . Actualmente la poblacin universitaria est en constante crecimiento y dinamismo la cual representa una gran demanda, el rea de servicios mdicos est constituida por quince (15) funcionarios relacionados con las actividades administrativas que se realizan en el mismo, estas personas manejan los procedimientos administrativos y conocen la realidad, por lo tanto, son los indicados transmitiendo requerimientos necesario para elaborar un nuevo sistema. Los actores que rigen el curso de las actividades y que modelan el comportamiento del negocio dentro del rea de servicios mdico se detallan a continuacin precisando el nmero de personas que ocupan cada cargo: 01 jefe de departamento 01 jefe de enfermera 04 Enfermeras 01 Auxiliar de Registros y Estadsticas 01 Higienista Dental 01 Secretaria 06 Mdicos: 02 Odontlogos 01 Pediatra 01 Internista 01 Medicina General 01 Gineclogo

71

Centro de Computacin Seccin de Programas y Proyectos 6. Necesidad de Desarrollar el Sistema La siguiente investigacin se plantea para dar seguimiento al trabajo de grado realizado por Cabello, M. (2009) titulado: Sistema automatizado basado en software libre para optimizar los procesos administrativos de los servicios mdicos de la Universidad de Oriente ncleo Monagas, este trabajo concluy en la fase de construccin de la metodologa RUP (Proceso Unificado Racional), y no se pudo lograr la implementacin debido a que el tiempo establecido no fue lo suficiente para el desarrollo del sistema. Gran parte del su trabajo estuvo basado en mucha investigacin y documentacin, sin embargo se realizo la codificacin o desarrollo de algunos mdulos pero no se llego a concretar la funcionabilidad del sistema, quedando la culminacin de lo propuesto incompleto. Por las razones expuestas, se hace pertinente retomar el proyecto, culminar la fase de construccin del sistema, realizar su implementacin y llevarlo a hasta su culminacin, con la finalidad de poder brindarle al servicio mdico una aplicacin completa que optimice la totalidad de sus procesos administrativos, desempendose en un ambiente de trabajo automatizado y organizado. Actualmente el Servicio Mdico aunque cuenta con los recursos tecnolgicos que faciliten el desempeo de las labores del personal y no cuenta con el software que permita controlar cada unos de los procesos administrativos que all se realizan, los cuales involucran: registro de usuarios del servicio, apertura de historias mdicas, emisin de rcipes para compra de medicamentos, control de consultas, remisin de pacientes que requieren atencin especializada u exmenes de laboratorios cuya respuesta no pueda ser canalizada a travs de los Servicios Mdicos, as como tambin, llevar la relacin de los mismos, a objeto de validar la cancelacin de tales servicios ante la Delegacin de Presupuestos de dicha institucin.

72

Centro de Computacin Seccin de Programas y Proyectos Esta realidad pone de manifiesto la importancia de implantar un sistema de informacin confiable y eficiente, ello incidir en el logro de importantes mejoras, ya que se automatizarn los procesos operativos y se suministra una plataforma de informacin necesaria para la toma de decisiones aportando informacin precisa y adecuada que contribuya a minimizar los riesgos y generar procesos ms eficaces en funcin de las necesidades del servicio que se presta.

7. Resumen de interesados del proyecto Se describe todos los interesados (stakeholders) del proyecto: Rol
Lder del proyecto

Responsabilidades
Elaborar el Plan Integral del Proyecto de desarrollo de la aplicacin empresarial que le sea asignada Prestar asistencia tcnica a los miembros del equipo de desarrollo. Gestionar los riesgos del proyecto. Dirigir y controlar la ejecucin del Plan Integral del Proyecto. Cerrar administrativa y tcnicamente el proyecto. Modelar el dominio de la aplicacin empresarial. Asegurar que los productos del desarrollo de la aplicacin estn alineados al sistema de negocios que acta como dominio de la aplicacin. Descubrir, analizar, especificar y documentar los requisitos de la aplicacin. Validar, en conjunto con los usuarios, los requisitos establecidos. Gestionar los requisitos. Especificar requisitos arquitectnicos. Disear y evaluar la arquitectura de la aplicacin. Especificar cada una de las vistas arquitectnicas. Disear los detalles de la Interfaz U/S, las Bases de Datos y los Componentes de Software de la aplicacin. Codificar, documentar y probar los componentes de software de la aplicacin. Depurar los componentes que tengan errores. Integrar los componentes de la aplicacin y desplegarlos en la plataforma de ejecucin del proyecto. Elaborar los manuales de instalacin, uso y mantenimiento. Verificar y validar los productos de cada proceso del desarrollo. Disear y ejecutar pruebas de unidad, de integracin, del sistema y de aceptacin de la aplicacin.

Analista de negocios

Analista de requisitos

Arquitecto de software Diseador de software

Programador

Especialista V&V Gestor de configuracin de software

Gestor de calidad

Gestionar los tems producidos durante el desarrollo y controlar los cambios que puedan surgir en cada una de ellos. Gestionar las versiones de la aplicacin. Definir los estndares y procedimientos de aseguramiento de la calidad del software. Asegurar la calidad del software.

Tabla 5: Interesados (stakeholders) del proyecto. Fuente: Autor (2010) Definimos qu papel desempea cada interesado (stakeholders) del proyecto:

73

Centro de Computacin Seccin de Programas y Proyectos

Nombre Ing. Rosngela Garcia Ing.Yhuanailys Nuez Responsabilidades
Lder del proyecto Responsable General del proyecto Analista de negocios Analista de sistemas Arquitecto de software Diseador de software Programador Especialista Verificacin & Validacin Gestor de calidad Gestor de configuracin de Software

Br. Lolimar Cedeo Ing. Yhuanailys Nez.

Tabla 6: identificacin de Interesados del proyecto. Fuente: Autor (2010)

8. Restricciones, Costos y Recursos Restricciones Los participantes estarn constituidos por personal de la seccin de Programas y Proyectos del Centro de Computacin de la UDO-Ncleo de Monagas, as como los responsables del rea de servicios mdicos, y otros participantes que se estimen convenientes para proporcionar los requisitos y validar el sistema: Responsable de Proyecto, Lder de Proyecto y Usuarios. El sistema est siendo desarrollado en la Universidad de Oriente ncleo Monagas, haciendo uso de la tecnologa de esta casa de estudio, basndose en los lenguajes de programacin Php 5, Javascript, Java, html. Las restricciones de infraestructura estarn dentro de requisitos legales o normas, aplicacin de estndares, requisitos de calidad del producto, tales como: confiabilidad, desempeo, etc., u otros requisitos de ambiente, tales como: sistema operativo, requisitos de compatibilidad, etc. Costos Los costos de produccin representan la inversin inicial que realiza el desarrollador o el equipo de trabajo durante la construccin del software, esto incluye costos de: infraestructura, personal, adiestramientos, cursos o talleres

74

Centro de Computacin Seccin de Programas y Proyectos necesarios para la capacitacin del personal involucrado y materiales utilizados. Entre estos costos tenemos: A. Costos de equipos y herramientas de trabajo: estos costos se generan por el hardware y el software utilizado durante el desarrollo del proyecto. Debido a que el centro de computacin cuenta con el equipo y las herramientas de trabajo que se utilizara, no se tendr ningn tipo de gasto en relacin a esto.

B. Costos de infraestructura: los costos de infraestructura se determinan a travs de los gastos generados al contar con un ambiente de trabajo apto para los equipos y por el mobiliario requerido para cada uno de ellos. El centro de computacin cuenta con un rea de trabajo apta para los equipos, por lo que no se tendr gastos de infraestructura. C. Costos de personal: incluye los sueldos de los empleados cuyos esfuerzos se encuentran directamente asociados al proyecto. Durante el desarrollo del sistema, se requiere la participacin de dos (02) empleados del centro de computacin; el jefe del centro y el jefe de programas y proyectos especiales, cuyos respectivos salarios sern cancelados por la Universidad, adems del trabajo no remunerado realizado por el autor en calidad de pasante. Tomando en consideracin que el sueldo promedio mensual en la Universidad de Oriente es de mil setecientos setenta (1770) Bs.F., es decir, que un da de trabajo de ocho (8) horas equivale a ochenta y ocho punto cinco (88. 5) Bs.F., y estimando que los empleados del centro de computacin trabajaron aproximadamente setenta (70) das o lo que es igual a quinientas sesenta (560) horas de trabajo, se obtiene un aproximado de seis mil ciento noventa y cinco (6.195) Bs.F. en costos de personal. D. Costos de adiestramientos: estos costos se refieren a los generados por las tcnicas de capacitacin y aprendizaje, como una herramienta para que el personal

involucrado en el proyecto adquiera los conocimientos necesarios que le permitan

75

Centro de Computacin Seccin de Programas y Proyectos desarrollar y ampliar aptitudes y actitudes para realizar el trabajo de la manera correcta. Las tcnicas de capacitacin empleada sern los talleres y cursos de UML, Power Designer, WATCH, PHP y Macromedia Dreamweaver, dictados por el personal del Centro de Computacin de la Universidad de Oriente Ncleo Monagas. E. Costos de materiales que se utilizaran: representan los costos relacionados a la compra de resmas de papel, carpetas, ganchos de carpetas, cartuchos de tinta para impresin, libretas de anotaciones, lapiceros entre otros. Recalcando que estos materiales sern en su mayora suministrados por el propio pasante.

9. Supuestos Ambientales

Adems del analista y del cliente, el ambiente puede implcita o explcitamente influenciar o poner restricciones en los requerimientos del sistema. El analista debe estar enterado de todo aquello que incida en el correcto funcionamiento de un software. Las influencias ambientales pueden ser clasificadas en categoras traslapadas, como las siguientes: Poltica de mercado, estndares y polticas tcnicas, culturales, organizacionales y fsicas. El proyecto a desarrollar percibe los siguientes supuestos ambientales: A. Se debe cumplir las necesidades o requerimientos del cliente haciendo una investigacin de mercado o modelo de negocio.

B. Se debe implantar un sistema automatizado que abarque la gran demanda poblacional que tiene la Universidad de Oriente ncleo de Monagas.

C. Se deben conocer los sistemas que se han desarrollado en el ncleo, ya que estos ayudarn a definir los requerimientos del sistema, para mantenerse competitivo en

76

Centro de Computacin Seccin de Programas y Proyectos cuanto a funcionalidad, confiabilidad, durabilidad, mantenimiento y seguridad del sistema. D. Se deben dar las condiciones e instalaciones fsicas necesarias para mantener equipos de computacin dentro del rea de servicios mdicos.

Los requerimientos del sistema estn influenciados directamente por los usuarios quienes tienen que estar conforme a los estndares y reglamentos tcnicos dictados por el centro de computacin; ya que es la dependencia que determina las polticas tcnicas, estndares asociados y los lineamientos que ayudan a asegurar: consistencia, seguridad, confiabilidad y mantenimiento del sistema.

La influencia cultural debe ser considerada al desarrollar el sistema porque puede afectar los requerimientos de ste. Muchas personas no se adaptan a los avances tecnolgicos y mucho menos a utilizarlos para agilizar las actividades

laborales. Es un supuesto creer y confiar que el personal que labora en el rea de los servicios mdicos har uso pleno del sistema automatizado que se le pretende implementar.

77

Centro de Computacin Seccin de Programas y Proyectos

Implementacin de un sistema automatizado que optimice la gestin de los procesos administrativos del rea servicios mdicos de la universidad de oriente ncleo Monagas . DOCUMENTO PROCESO DE INSTANCIACION DEL MTODO

VERSIN 1.0 Autor Fecha Versin Descripcin Lolimar Cedeo M. 29-8-09 0.90 Versin preliminar como propuesta de desarrollo Lolimar Cedeo M. 9-10-09 0.91 Correcciones de versin preliminar Lolimar Cedeo M. 27-10-09 1.0 versin preliminar 10. Introduccin Este documento presenta la instanciacin del mtodo, el cual consiste en adaptar el conjunto de procesos y actividades prescritas por el mtodo, a las caractersticas particulares del sistema que se va a implementar. Para realizar la adaptacin se toma en cuenta tanto las condiciones existentes en el ambiente de trabajo como la complejidad de la aplicacin; es decir, el proceso de ajuste del mtodo considera las caractersticas del producto que se desea desarrollar y del ambiente organizacional de implantacin para establecer el equipo de trabajo requerido y el proceso que debe seguirse.

11. Procesos que se generan en el proyecto Con el objeto de facilitar su descripcin, estos modelos de procesos se han organizado en tres grupos (ver figura 16). El grupo de Procesos Tcnicos enmarcan todas las actividades de ingeniera que estn relacionadas directamente con el ciclo de desarrollo de las aplicaciones. El grupo de Procesos de Gestin cubre todas las actividades de gestin de proyectos de software. El grupo de Procesos de Soporte concentra todas aquellas actividades que son necesarias para apoyar la ejecucin de los procesos tcnicos y gerenciales. Para el desarrollo del proyecto se van realizar todos los procesos del mtodo WATCH que se muestran a continuacin:

78

Centro de Computacin Seccin de Programas y Proyectos

Figura 16: Clasificacin de los procesos del Mtodo WATCH durante el desarrollo del proyecto. Fuente: autor (2010)

Una vez que los modelos de productos, procesos y actores han sido instanciados se debe asegurar que el mtodo resultante de la integracin de estos tres modelos, permitir verdaderamente desarrollar el proyecto. Para ello se debe revisar la correspondencia entre los conceptos predefinidos en el mtodo y el subconjunto de conceptos utilizados durante la adaptacin; verificar la consistencia y la coherencia de las interacciones establecidas entre los diferentes modelos de la adaptacin del mtodo, asegurar la consistencia entre modelo de producto y de proceso y garantizar la correspondencia entre actores y actividades del proceso.

79

Centro de Computacin Seccin de Programas y Proyectos Para comenzar se verifica la coherencia entre el modelo de productos y el modelo de procesos; en el proceso de gestin se van a ejecutar los cinco procesos que a su vez generan los productos que ya hemos instanciado. En la constitucin del proyecto se generan los productos: Enunciado del trabajo del proyecto y Documento de inicio del proyecto. Posteriormente para la planificacin es necesario generar el plan integral del proyecto, plan del alcance del proyecto y el plan de tiempos. Los productos entregables son el resultado del proceso de Direccin del proyecto. El proceso de control genera el plan integral del proyecto actualizado el cual permite llevar un control de la ejecucin del proyecto y corregir las desviaciones de lo ejecutado con respecto a lo establecido en el plan integral del proyecto. El ltimo proceso de gestin es el cierre del proyecto que se encarga de dar por finalizado formalmente el proyecto entregando como producto el sistema operativo.

Para el desarrollo del proyecto de Implementacin de un sistema automatizado de servicios mdicos que optimice la gestin de los procesos administrativos de la UDO-Monagas, los procesos tcnicos se van a ejecutar a partir de los procesos de implementacin, atendiendo a que el proyecto es una continuacin del desarrollo del sistema; los procesos de implementacin son programacin & integracin, pruebas y entrega de la aplicacin. Sin embargo para asegurar la consistencia del desarrollo del sistema es necesario realizar revisiones y verificaciones de los procesos de anlisis (modelado del negocio, ingeniera de requisitos) y un fortalecimiento de los procesos de diseo (diseo arquitectnico y diseo detallado).

Los productos del proceso de soporte forman parte del Plan Integral del Proyecto estos procesos son: Gestin de la configuracin, Gestin de la calidad y Gestin de riesgos. Del proceso de soporte se van a ejecutar los tres procesos que a su vez generan los productos que ya hemos instanciado. Del proceso de Gestin de Riesgos se obtiene el producto plan de gestin de riesgos. El plan de gestin de la configuracin es el resultado de la ejecucin del proceso de Gestin de la

80

Centro de Computacin Seccin de Programas y Proyectos Configuracin del Software. A su vez se realizan los procesos de Aseguramiento de la calidad del software y de verificacin & validacin los cuales producen el plan de aseguramiento de la calidad del software.

En la validacin de la instanciacin tambin se debe garantizar la correspondencia entre actores y actividades del proceso; para los respectivos procesos de gestin y procesos tcnicos se cuenta con el desarrollador que ejecuta la gestin, anlisis, diseo y programacin. Para los procesos de soporte el gestor de configuracin llevar a cabo las actividades inherentes a estos procesos y tambin el desarrollador quien realiza la gestin de la calidad del software y la gestin de los riesgos del proyecto. Conjuntamente se cuenta con el comit directivo del proyecto y el lder del proyecto que forman por completo la organizacin del equipo de trabajo.

12. Productos que se generaran en el proyecto El modelo de producto identifica y describe los tipos de productos que se pueden generar durante el desarrollo del proyecto: Implementacin de un sistema automatizado de servicios mdicos que optimice la gestin de los procesos administrativos de la Universidad de Oriente ncleo Monagas. Estos tipos de productos son el resultado parcial o final de la ejecucin de los procesos tcnicos, de gestin o de soporte.

Para hacer la instanciacin del modelo de productos se elabora una lista de los productos concretos que se producirn durante el desarrollo del proyecto y describe las caractersticas particulares del proyecto para automatizar los procesos administrativos del rea de servicios mdicos de la Universidad de Oriente ncleo Monagas. El modelo de productos est compuesto por tres tipos de productos: tcnicos, de soporte y de gestin, a continuacin se muestra la lista de los productos que se producirn durante todo el proceso de desarrollo del proyecto para la 81

Centro de Computacin Seccin de Programas y Proyectos implementacin de un sistema automatizado de servicios mdicos que optimice la gestin de los procesos administrativos de la Universidad de Oriente ncleo Monagas. A continuacin se muestran el tabla 7:

Grupo de procesos Procesos de Gestin

Producto 1. Documento de Inicio del proyecto 2. Proceso de Desarrollo 3. Plan Integral del Proyecto 1. Modelo del anlisis del negocio 2. Documento de Requisitos 3. Documento de Diseo 4. Productos intermedios de programacin: componentes, programas incrementos y versiones de

Procesos Tcnicos

5. Productos de Pruebas: Especificaciones de Diseo de Pruebas, Especificaciones de Casos de Pruebas, Especificaciones de Procedimientos de Pruebas, Reporte de Fallas 6. Aplicacin empresarial: Programas Base de datos Manuales

Forman parte del Plan Integral del Proyecto: Procesos de Soporte 1. Plan de Gestin de Riesgos 2. Plan de Gestin de la Configuracin 3. Plan de Aseguramiento de la Calidad del Software
Tabla 7: Productos que genera la metodologa Grey Watch. Fuente: Autor (2010)

Como se muestra en

la Figura 17 p.81,el mtodo produce dos grandes

categoras de productos, los productos intermedios y los productos finales. Al mismo

82

Centro de Computacin Seccin de Programas y Proyectos tiempo, el mtodo permite distinguir los productos segn el grupo de procesos que los producen; es decir, hay productos resultantes de los procesos tcnicos o de ingeniera, otros son resultantes de los procesos de gestin del proyecto y otros de los procesos de apoyo al proceso de desarrollo:

Producto WATCH

Producto Intermedio

Producto Entregable

Producto Tcnico

Producto de Gestin

Producto de Soporte

Aplicacin Empresarial

Figura 17: Principales tipos de productos del mtodo WATCH. Fuente: autor (2010)

La instanciacin del modelo de producto da como resultado los productos concretos que se van a producir durante todo el proceso de desarrollo del sistema del rea de servicios mdicos UDO-Monagas.

83

Centro de Computacin Seccin de Programas y Proyectos Implementacin de un sistema automatizado que optimice la gestin de los procesos administrativos del rea servicios mdicos de la universidad de oriente ncleo Monagas
PLAN INTEGRAL DEL PROYECTO

VERSIN Autor Fecha

Lolimar Cedeo 29-8-09 Lolimar Cedeo 9-10-09 Lolimar Cedeo 27-10-09

1.0

Versin Descripcin 0.90 Versin preliminar como propuesta de desarrollo 0.91 1.0 Correcciones de versin preliminar Versin preliminar

13. Introduccin

Es el documento ms importante de la gestin del proyecto, por cuanto determina, rige y gua la ejecucin de todos los procesos del desarrollo de la aplicacin. El Plan de Integral del Proyecto (denominado, tambin, Plan del Proyecto) define cmo el proyecto se debe iniciar, planificar, ejecutar, controlar y cerrar. Este documento determinara la ejecucin de todos los procesos del desarrollo del proyecto: Implementacin de un sistema automatizado de servicios mdicos que optimice la gestin de los procesos administrativos de la Universidad de Oriente ncleo Monagas. Se podr establecer los objetivos y alcance de la aplicacin, el proceso tcnico necesario para desarrollar dicha aplicacin, las actividades que componen cada uno de los procesos, el cronograma de ejecucin de estas actividades, y los recursos humanos, tecnolgicos, fsicos y materiales necesarios para desarrollar las actividades. Bajo estas premisas, el estudio en referencia se circunscribir al desarrollo de un sistema de informacin para optimizar los procesos administrativos de Servicios Mdicos, y dentro del contexto de la Universidad de Oriente Ncleo Monagas. 14. Objetivos Con los diferentes planes que ms adelante se detallarn se pretende obtener informacin que se necesita para llevar el proyecto planificado y controlado en lo que

84

Centro de Computacin Seccin de Programas y Proyectos respecta a tiempos, riesgos y cambios. Todo proyecto de software es susceptible a riesgos los cuales si llegan a concretarse afectan los tiempos de ejecucin de las actividades y producen cambios en el proyecto, por esto los objetivos que se persiguen con los diferentes planes que se realizan son los siguientes: 1. Asegurar que el desarrollo de la aplicacin sea sistemtico, organizado, eficaz y eficiente, mediante el empleo de los procesos de planificacin, direccin y control. 2. Garantizar que la aplicacin se desarrolle a tiempo y siguiendo los estndares y procedimientos establecidos para asegurar la calidad de la aplicacin. 3. Manejar apropiadamente los riesgos que puedan surgir durante el desarrollo de la aplicacin y que puedan afectar los objetivos del proyecto. 4. Controlar la configuracin de la aplicacin.

15. Recursos Necesarios 3.1 Recursos Humanos El equipo de trabajo est representado de la siguiente manera: Se requiere primeramente del Ing. Rosngela Garca cuya responsabilidad es de ser el lder del proyecto: es la persona que elabora el Plan Integral del Proyecto de desarrollo de la aplicacin, presta asistencia tcnica a los miembros del equipo de desarrollo, dirige y controlar la ejecucin del Plan Integral del Proyecto y es la responsable general del proyecto ante el centro de computacin de la universidad de oriente ncleo de Monagas, esta persona valida cada uno de los documentos. Se requiere de asesoramiento e instrucciones del Ing. Yhuanailys Nez, pues desempea el papel de gestor de calidad y gestor de configuracin de software en el proyecto. Es la persona que define los lineamientos a seguir para el desarrollo de las versiones. Finalmente la elaboracin del proyecto estar a cargo de de la Br. Lolimar

85

Centro de Computacin Seccin de Programas y Proyectos Cedeo quien es la persona encargada de la elaboracin del proyecto, desempea papeles como: Analista de negocios, Analista de sistemas, Arquitecto de software, diseador de software, programador y especialista en verificacin & validacin de software.

Recursos Tecnolgicos Para garantizar un rendimiento adecuado del sistema propuesto es necesario que los equipos hardware donde se van a instalar y operar el sistema cumplan con los siguientes requerimientos unidad central de procesamiento (CPU) Pentium IV, se recomienda 1024 megabyte (MB)/1 GB de memoria RAM, Disco Duro de 160 GB y Sistema operativo Windows XP. Servidor Apache, PHP, Macromedia Dreamweaver, Sybase, Power Designer, Editor de Texto y un Navegador Web.

Recursos Materiales Los miembros de trabajo del proyecto deben contar con resmas de papel tipo carta, cartuchos de impresin, carpetas, lpices, lapiceros y marcadores, libreta de anotaciones, CD-ROM, guas didcticas con informacin sobre el mtodo de desarrollo, material de apoyo y textos varios sobre los procesos y actividades a desarrollar.

16. Estndares y procedimientos

Normas de calidad:

Norma de calidad ISO-9126: La ISO, bajo la norma ISO-9126, ha establecido un estndar internacional para la evaluacin de la calidad de productos de software el cual fue publicado en 1992 con el nombre de Tecnologa de la informacin de evaluacin de productos de software: caractersticas de calidad y directrices para su uso, en el cual se establecen las caractersticas de calidad para productos de software. El estndar ISO-9126 establece que cualquier componente de la calidad del software puede ser descrito en trminos 86

Centro de Computacin Seccin de Programas y Proyectos de una o ms de seis caractersticas bsicas, las cuales son: funcionalidad, confiabilidad, usabilidad, eficiencia, mantenibilidad y portatilidad; cada una de las cuales se detalla a travs de un conjunto de subcaractersticas que permiten profundizar en la evaluacin de la calidad de productos de software. La tabla n8 denominada Caractersticas ISO-9126 demuestra la pregunta central que atiende cada una de estas caractersticas.
Caractersticas Pregunta central Las funciones y propiedades satisfacen las Funcionalidad necesidades explcitas e implcitas; esto es, el qu . . . ? Confiabilidad Puede mantener el nivel de rendimiento, bajo ciertas condiciones y por cierto tiempo? Usabilidad Eficiencia El software es fcil de usar y de aprender? Es rpido y minimalista en cuanto al uso de recursos? Mantenibilidad Portatilidad Es fcil de modificar y verificar? Es fcil de transferir de un ambiente a otro?

Tabla 8: Caractersticas de ISO-9126 y aspecto que atiende cada una. Fuente: autor (2010). Leyes:

Las bases legales que dan soporte al proyecto en referencia, se encuentras plasmadas en la: A. Constitucin de la Repblica Bolivariana de Venezuela Artculo 110: El Estado reconocer el inters pblico de la ciencia, la tecnologa, el conocimiento, la innovacin y sus aplicaciones y los servicios de informacin necesarios por ser instrumentos

fundamentales para el desarrollo econmico social y poltico del pas, as como para la seguridad y soberana nacional..

87

Centro de Computacin Seccin de Programas y Proyectos B. Ley Orgnica de la Administracin Pblica

Artculo 12. La actividad de la Administracin Pblica se desarrollar con base en los principios de economa, celeridad, simplicidad administrativa, eficacia, objetividad, imparcialidad, honestidad, transparencia, buena fe y confianza. Asimismo, se efectuar dentro de parmetros de racionalidad tcnica y jurdica. La simplificacin de los trmites administrativos ser tarea permanente de los rganos y entes de la Administracin Pblica.los rganos y entes de la Administracin Pblica debern utilizar las nuevas tecnologas que desarrolle la ciencia, tales como los medios electrnicos, informticos y telemticos, para su organizacin, funcionamiento y relacin con las personas

C. Decreto Rango y Fuerza de Ley Orgnica de Ciencia, Innovacin en Consejo de Ministros

Tecnologa

Artculo 2.- Las actividades cientficas, tecnolgicas y de innovacin son de inters pblico y de inters general. Ello indica que ataen a todos los individuos y entes nacionales.

D. Decreto N 3.390 de la Presidencia de la Repblica Bolivariana de Venezuela Gaceta 38.095 del 28/12/2004), sobre uso del Software Libre.

88

Centro de Computacin Seccin de Programas y Proyectos La Administracin Pblica Nacional emplear prioritariamente Software Libre desarrollado con Estndares Abiertos, en sus sistemas, proyectos y servicios informticos. A tales fines, todos los rganos y entes de la Administracin Pblica Nacional iniciarn los procesos de migracin gradual y progresiva de stos hacia el Software Libre desarrollado con Estndares Abiertos. Manuales GRAY WATCH Mtodo de Desarrollo de Software de Aplicaciones Empresariales, 2008 Jons Montilva, Judith Barrios y Milagro Rivero: Este documento tiene por objetivos describir, en detalle, el mtodo WATCH de tal manera que los equipos de desarrollo puedan utilizarlo como un patrn metodolgico que les ayude a definir el proceso especfico de desarrollo de cada una de las aplicaciones de una empresa. Modelado de sistemas usando UML 2.0, Jons Montilva e Isabel Besembel: Es una gua que describe el modelado de sistemas con las notaciones en UML 2.0 y el modelado de sistemas de negocios con UML Bussines. Esta dirigido a ensear al desarrollador de sistemas como usar este lenguaje en el proceso desarrollo de software y como modelar los diferentes aspectos que caracterizan a un sistema de informacin o aplicacin de software. Ingeniera de requisitos, Jons Montilva, CeiSoft: Es una gua que detalla las generalidades involucradas en el proceso de ingeniera de requisitos como la especificacin, documentacin y representacin usando notaciones en UML 2.0.

89

Centro de Computacin Seccin de Programas y Proyectos 17. Planes 5.1. PLAN DE GESTIN DE TIEMPO Este plan establece las actividades necesarias para elaborar el cronograma del proyecto. Describe tambin, el formato para elaborar el cronograma y los criterios y supuestos que se deben considerar para programar las actividades del proyecto. Una vez que el o los cronogramas del proyecto se elaboren, ellos pasan a formar parte del Plan de Gestin de Tiempos. El objetivo de la planificacin de tiempos es estimar el tiempo de ejecucin de las actividades del proyecto, a fin de producir el cronograma que guiar y controlar la ejecucin del proyecto. El cronograma general del proyecto identifica y organiza las actividades del proyecto en funcin de sus fechas de inicio y terminacin. A continuacin se muestra el plan de tiempo del proyecto:

Tabla 9: Plan de tiempo del proyecto1/4.

90

Centro de Computacin Seccin de Programas y Proyectos

Tablas 9: Plan de tiempo del proyecto 2/4. 91

Centro de Computacin Seccin de Programas y Proyectos

Tablas 9: Plan de tiempo del proyecto 3/4.

92

Centro de Computacin Seccin de Programas y Proyectos

Tablas 9: Plan de tiempo del proyecto 4/4.

5.2 PLAN DE GESTIN DE RIESGO

La Planificacin de la Gestin de Riesgos tiene como objetivo definir las actividades, recursos, responsabilidades, costos, tiempos que son necesarios para evaluar y responder a los riesgos del proyecto de servicios mdicos de manera organizada. El proceso comienza considerando las caractersticas del ambiente de desarrollo, del proyecto, la experiencia en el dominio y categora de la aplicacin a desarrollar, las herramientas y recursos requeridos y disponibles, para luego determinar cules actividades de gestin de riesgos se llevaran a cabo, cuando, en qu orden y quines sern los responsables.

En este documento se reconoce y listar todos aquellos riesgos que puedan influir negativamente en el proyecto. El proceso comienza con la definicin de las caractersticas del proyecto en relacin a complejidad, requisitos, recursos, experiencia del recurso humano, de manera que se pueda determinar el conjunto de riesgos potenciales a los que el desarrollo de la aplicacin estar expuesto.

93

Centro de Computacin Seccin de Programas y Proyectos Riesgos a administrar:

Descripcin del Riesgo: Inexistencia de Comunicacin entre el cliente y los involucrados en el proyecto. Tipo de riesgo: Consecuencia: Personal. No contar con informacin para poder desarrollar el proyecto, y desviacin en el cumplimiento de los requerimientos Probabilidad Efectos del Riesgo: Tolerable. Baja Bajo Moderado Alto Periodo en el cual puede suceder: Responsable(s): Durante la elaboracin proyecto. Analista de negocio y de requisitos. Estrategia de Mitigacin: Para evitar la disminucin en el flujo de la comunicacin se requiere hacer reuniones peridicas: semanalmente para el rea de servicios mdicos y diariamente para el centro de computacin referentes al proyecto, con el fin de incrementar al mximo la retroalimentacin.

001

Tabla 10: Riesgos a administrar en el proyecto 1/13.

Descripcin del Riesgo: Incumplimiento de entrega de documentos al centro de computacin, debido a responsabilidades con carga de trabajo fuerte, no relativos al proyecto. Tipo de riesgo: Consecuencia: Personal. Retraso en la elaboracin del proyecto.

002

Probabilidad Efectos del Riesgo: Serio. Moderado Alto Periodo en el cual puede suceder: Responsable(s): Durante la elaboracin proyecto. Analista de sistema. Estrategia de Mitigacin: Para evitar el incumplimiento de las asignaciones, el participante debe dar a conocer con anticipacin la no participacin en alguna versin y por consiguiente exponer con aval dicha solicitud. Baja Bajo

Tablas 10: Riesgos a administrar en el proyecto 2/13.

003
Descripcin del Riesgo: Incumplimiento de entrega de documentos corregidos y/o aprobados por parte del centro de computacin. Organizacional. Probabilidad Bajo Moderado Periodo en el cual puede suceder: Durante la elaboracin proyecto. Baja Consecuencia: Prolongacin de la culminacin del proyecto. Efectos del Riesgo: Alto Serio.

Tipo de riesgo:

Responsable(s): Gestor de configuracin de Software. Gestor de calidad. Estrategia de Mitigacin: El gestor de configuracin de software y gestor de calidad debe apegarse al cumplimiento del cronograma de fechas.

Tablas 10: Riesgos a administrar en el proyecto 3/13.

94

Centro de Computacin Seccin de Programas y Proyectos

Descripcin del Riesgo: La no aprobacin de los artefactos ejecutables durante la construccin y prueba del sistema por parte del centro de computacin. Tipo de riesgo: Consecuencia: Organizacional. Proyecto reprobado o cancelado.

004

Baja

Bajo

Probabilidad Moderado

Efectos del Riesgo: Alto Catastrfico.

Periodo en el cual puede suceder: Responsable(s): Despus de implantacin del sistema. Analista de sistema Estrategia de Mitigacin: apegarse a las normas y exigencias del centro de computacin, entregando documentos con un buen contenido y sentido de la investigacin.

Tablas 10: Riesgos a administrar en el proyecto 4/13.

Descripcin del Riesgo: Resistencia al cambio por parte de los usuarios. Tipo de riesgo: Organizacional.

005

Consecuencia: Proyecto cancelado. Efectos del Riesgo: Alto Serio.

Baja

Bajo

Probabilidad Moderado

Periodo en el cual puede suceder: Responsable(s): Despus de implantacin del sistema. Responsable general del proyecto. Estrategia de Mitigacin: Coordinar una estrategia de comunicacin interna que involucre a los usuarios en las ventajas del nuevo sistema y establecer reuniones, foros y conferencias con la doble finalidad de transmitir el proyecto a los usuarios y recibir la retroalimentacin que permita incorporar cambios que reduzcan la resistencia natural al cambio.

Tablas 10: Riesgos a administrar en el proyecto 5/13.

006

Descripcin del Riesgo: Incumplimiento del alcance del proyecto en el rea de servicios mdicos debido a que un participante asume muchos roles. Organizacional. Probabilidad Moderado Consecuencia: Resistencia al cambio de paradigma de desarrollo de software. Efectos del Riesgo: Alto Serio.

Tipo de riesgo:

Baja

Bajo

Periodo en el cual puede suceder: Responsable(s): Durante la elaboracin del proyecto. Responsable general del proyecto. Estrategia de Mitigacin: Adaptarse al nuevo paradigma de trabajo en la parte de desarrollo de software.

Tablas 10: Riesgos a administrar en el proyecto 6/13.

95

Centro de Computacin Seccin de Programas y Proyectos

007

Descripcin del Riesgo: Crecimiento no controlado de requerimientos y alcance. Estimaciones -Requerimientos. Consecuencia: Proyecto fuera de calendario y requerimientos.

Tipo de riesgo:

Probabilidad Efectos del Riesgo: Serio. Moderado Alto Periodo en el cual puede suceder: Responsable(s): Durante la elaboracin del proyecto. Analista negocio, requisitos y de sistemas. Estrategia de Mitigacin: El alcance del proyecto debe ser definido previo a la etapa de operacin. Cualquier nuevo requerimiento que se constituya en un subsistema no indispensable para los ya previstos, debe considerarse para un nuevo proyecto. Baja Bajo

Tablas 10: Riesgos a administrar en el proyecto 7/13.

008

Descripcin del Riesgo: No adecuacin de las normas y procedimientos a las funciones del nuevo software (no previstas en las actividades que realizaban anteriormente) en el rea de servicios mdicos. Tecnolgico. Consecuencia: Resistencia al cambio, los usuarios no se familiarizan con el software y retardan las operaciones automatizadas.

Tipo de riesgo:

Probabilidad Efectos del Riesgo: Serio. Moderado Alto Periodo en el cual puede suceder: Responsable(s): Despus de implantar el software. Responsable general del proyecto. Estrategia de Mitigacin: Definicin de manuales de normas y procedimientos de las funciones del sistema en general y su respectiva induccin a los usuarios. Baja Bajo

Tablas 10: Riesgos a administrar en el proyecto 8/13.

009

Descripcin del Riesgo: Datos de los sistemas actuales no migrados eficientemente. Tecnolgico. Consecuencia: Software con datos no reales que inciden en su desempeo funcional. Efectos del Riesgo: Alto Serio.

Tipo de riesgo:

Probabilidad Moderado Periodo en el cual puede suceder: Pruebas funcionales del software. Baja Bajo

Responsable(s): Programador. Especialista en Verificacin & Validacin. Estrategia de Mitigacin: Para evitar que esto ocurra, el gestor de configuracin de software debe prever la incorporacin paulatina (a travs de las versiones) de data bsica real en la base de datos. Un modulo funcional debe ejecutarse correctamente, sino debe crearse tantas versiones sean necesarias.

Tablas 10: Riesgos a administrar en el proyecto 9/13.

96

Centro de Computacin Seccin de Programas y Proyectos

010

Descripcin del Riesgo: Adecuacin errnea o tarda de la plataforma de produccin del software implantado. Consecuencia: Software de bajo desempeo y elevacin de la resistencia al cambio por parte de los usuarios. Efectos del Riesgo: Serio. Responsable(s): Responsable general del proyecto. debe evaluar estrictamente las especificaciones de hardware y

Tipo de riesgo: Tecnolgico - Estimacin. Probabilidad Moderado Alto Periodo en el cual puede suceder: Despus de implantar el software. Estrategia de Mitigacin: El gestor de configuracin de software software necesarias para la puesta en marcha del nuevo software. Baja Bajo

Tablas 10: Riesgos a administrar en el proyecto 10/13.

Descripcin del Riesgo: Falta de conocimientos de las herramientas (como PHP, Power Designer, Macromedia, MySQL) de desarrollo por parte del equipo de desarrollo. Tipo de riesgo: Consecuencia: Herramientas. Retardo en la entrega de documentos.

011

Baja

Bajo

Probabilidad Moderado

Efectos del Riesgo: Alto Tolerable.

Periodo en el cual puede suceder: Responsable(s): Durante la elaboracin del proyecto. Analista de negocio, software y sistema. Estrategia de Mitigacin: Adiestramiento inmediato a al equipo de desarrollo del proyecto, con el fin de prepararlos y as puedan cumplir con sus asignaciones.

Tablas 10: Riesgos a administrar en el proyecto 11/13.

Descripcin del Riesgo: Suspensin de actividades medicas-odontolgicas por causas externas a la misma. Problemtica existente en los ncleos tanto a nivel docente, administrativo y estudiantil, como a nivel de presupuesto. Tipo de riesgo: Consecuencia: Cancela el proyecto. Organizacional.

012

Baja

Bajo

Probabilidad Moderado

Efectos del Riesgo: Alto Catastrfico.

Periodo en el cual puede suceder: Responsable(s): Durante la elaboracin del proyecto. Responsable general del proyecto. Estrategia de Mitigacin: Tratar de llevar la planificacin del proyecto para poder mitigar el efecto de retraso que pudiera ser causado por la situacin descrita.

Tablas 10: Riesgos a administrar en el proyecto 12/13.

97

Centro de Computacin Seccin de Programas y Proyectos

013

Descripcin del Riesgo: No implantacin de infraestructura tecnolgica en el rea de servicios mdicos. Consecuencia: Al no tener los equipos tecnolgicos necesarios, el proyecto que ha llevado tiempo y esfuerzo se pierde y solo queda en documentos. Efectos del Riesgo: Catastrfico.

Tipo de riesgo: Tecnologa. Probabilidad Moderado

Baja

Bajo

Alto

Periodo en el cual puede suceder: Responsable(s): Una vez finalizado el proyecto. Responsable general del proyecto. Estrategia de Mitigacin: Realizar solicitudes de los equipos tecnolgicos necesitados con anterioridad, para no poner en riesgo el proyecto.

Tablas 10: Riesgos a administrar en el proyecto 13/13.

5.3 Plan de gestin de configuracin A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepcin del producto y la captura de requisitos inicial hasta la puesta en produccin del mismo, y posteriormente desde el inicio del mantenimiento hasta su retiro, se van realizando una serie de cambios, tanto en el cdigo como en la documentacin asociada. La gestin de configuracin del software es una disciplina encargada del control de la evolucin de los productos de software. La gestin de configuracin es el proceso de identificar y definir los elementos en el sistema, controlando el cambio de estos elementos a lo largo de su ciclo de vida, registrando y reportando el estado de los elementos y las solicitudes de cambio, y verificando que los elementos estn completos y que sean los correctos. Su propsito es: (1) controlar sistemticamente los cambios que puedan producirse en esa configuracin; (2) mantener la integridad de la configuracin de la aplicacin; y (3) mantener la trazabilidad de la configuracin a lo largo de todo el desarrollo de la aplicacin. Las actividades de gestin de la configuracin identifican todas las actividades y tareas que se requieren para el manejo de la configuracin del sistema. Estas deben ser tanto actividades tcnicas como de gestin de configuracin del software, as

98

Centro de Computacin Seccin de Programas y Proyectos como las actividades generales del proyecto que tengan implicancia sobre el manejo de configuracin. a) Identificacin de la configuracin Se necesita definir un esquema de identificacin para reflejar la estructura del producto, esto involucra identificar la estructura y clases de componentes, dando a cada uno un nombre, una identificacin de versin y una identificacin de configuracin. Para este proyecto los elementos de configuracin se

correspondern con los entregables definidos en el modelo de productos, aunque no necesariamente todos los entregables deben ser elementos de configuracin. b) Control de la configuracin Se deben controlar los cambios que se le hacen a travs del ciclo de vida, asegurando que el software sea consistente a travs de la creacin de una lnea base del producto. Se identifican y registran las solicitudes de cambio, se analiza y evala los cambios, se aprueba o rechaza la solicitud, se implementa, verifica y distribuye el elemento de software modificado. c) Contabilidad del estado de la configuracin Se debe registrar y reportar el estado de los componentes y solicitudes de cambio. Se preparan registros de gestin y reportes de estado que muestren el estado e historia de los elementos de software controlados, incluyendo lneas base. Al final de cada iteracin se establecer una lnea base (un registro del estado de cada artefacto, estableciendo una versin por ejemplo 0.90,0.91..), la cual podr ser modificada slo por una solicitud de cambio aprobada. d) Gestin y entrega de versiones Se controla formalmente la actualizacin y distribucin de las versiones generadas por el proyecto. La gestin de la entrega se encarga de identificar, empacar

99

Centro de Computacin Seccin de Programas y Proyectos y entregar los tems y componentes que forman cada versin entregable de la aplicacin.

5.4 Mantenimiento del plan

El responsable de monitorear el plan es el desarrollador del proyecto, quien se encarga de llevar un registro de los artefactos generados y sus versiones. Los cambios sern realizados y comunicados a todo los interesados en el proyecto a travs de las plantillas de solicitud de cambio. Este plan deber ser revisado al inicio de cada iteracin, modificado de acuerdo a lo necesario, aprobado y distribuido al equipo de proyecto.

100

Centro de Computacin Seccin de Programas y Proyectos

Implementacin de un sistema automatizado que optimice la gestin de los procesos administrativos del rea servicios mdicos de la universidad de oriente ncleo Monagas. MODELADO DEL NEGOCIO

Autor Lolimar Cedeo. Lolimar Cedeo. Lolimar Cedeo.

VERSIN 1.0 Fecha Versin Descripcin 29-8-09 0.91 Versin preliminar como propuesta de desarrollo 9-10-09 0.92 Correccin de versin preliminar 27-10-09 1.0 Versin preliminar

18. INTRODUCCIN

Este documento permite revisar y verificar el dominio organizacional donde operar el sistema. Tiene como propsito realizar un anlisis del modelado de negocio del sistema a desarrollar; el objetivo es verificar y validar con los usuarios que el modelo del negocio est representado correctamente y cumple con los procesos de negocio actuales. Este documento es una nueva adaptacin al negocio de servicios mdicos de la universidad de oriente ncleo de Monagas realizado por Cabello, M. (2009) donde se utilizan nuevas herramientas para modelar, ya que para realizar la implantacin se debe revisar detalladamente el modelado existente. Es necesario realizar una revisin y anlisis del modelado del negocio establecido en el proyecto anterior, para determinar si existen discrepancias entre este modelo y lo que realiza actualmente en el rea de servicios mdicos. A travs de entrevistas con el personal se logr verificar que los procesos de negocio continan siendo los mismos que se especificaron en el proyecto anterior, sin embargo se manifiesta el aumento de actores, ya que para el momento del desarrollo del sistema no contaba con la misma cantidad. El aumento de actores no tiene gran relevancia ya que tiene los mismos roles y responsabilidades que en el sistema de negocios pasado y por ende en la ejecucin de algunos procesos es la misma.

101

Centro de Computacin Seccin de Programas y Proyectos 19. REPRESENTACIN DEL MODELADO DEL NEGOCIO El proyecto anterior estuvo desarrollado bajo el enfoque de la metodologa RUP, donde el modelado del negocio se estableci a travs de casos de uso de UML, del cual se tomo informacin por referencia ya que no existen cambios notorios en la ejecucin de los procesos del rea de servicios mdicos. El nuevo modelo del negocio se simbolizar mediante UML BUSINESS que es una extensin del lenguaje UML, que est orientado a procesos de negocio que incorpora nuevos smbolos para modelar, emplea estereotipos para agregar mayor semntica a los smbolos utilizados, usa cadena de valor de MICHAEL PORTER para modelar procesos al ms alto nivel y descomponer cada proceso de la cadena de valor en sub-procesos de ms bajo nivel, los cuales sern desglosados de manera ms especfica y completa.

20. MODELO DE JERARQUA DE SISTEMA DEL SERVICIOS MDICOS

En esta parte se genera como producto un diagrama de jerarqua de sistema el cual se muestra en la figura 18: este diagrama representar la jerarqua de los sistemas de la universidad de oriente ncleo de Monagas con respecto al rea en estudio.
Notacin de Eriksson y Penker para modelar un Proceso de Negocio. El suprasistema

corresponde a la identificacin de la universidad como la cabeza principal del sistema el cual da origen a cada rea que administra como un todo. El sistema en estudio corresponde al rea de servicios mdicos una de las reas adscrita al departamento de desarrollo y bienestar estudiantil, sus sub-procesos son identificados como las consultas que brinda

102

Centro de Computacin Seccin de Programas y Proyectos

U.D.O MONAGAS

Decanato del ncleo

Suprasistema

Coordinacin Administrativa

Coordinacin Acadmica

Coordinacin Acadmica

rea Administracin

rea de Orientacin

Delegacin de Desarrollo Social y Bienestar Estudiantil

rea socioeducativa

rea de desarrollo social

Sistema en estudio
Medicina General

rea de salud Servicios Mdicos

Medicina Interna

Subsistema

Ginecologa Pediatra

Odontologa

Figura 18: Modelo de Jerarqua de Sistemas de servicios medico. Fuente: autor (2010)

21. MODELADO DE OBJETIVOS De una manera macro a continuacin se muestra en la figura 19 el diagrama de objetivos correspondiente a los procesos fundamentales del negocio, diagrama que es de suma importancia tener definido en el momento de realizar el proceso de definicin de requisitos del sistema. 103

Centro de Computacin Seccin de Programas y Proyectos

objetivo Institucional>>
Para la UDO MONAGAS la salud de sus miembros se constituye en una parte importante para alcanzar los objetivos de esta casa de estudios en cuanto a mantener un liderazgo en la investigacin. En correspondencia con ello, el Servicio Mdico est dirigido a la atencin de estudiantes, obreros y empleados que laboran en dicho ncleo.

Objetivos No-Operacionales
objetivo>> Visin Ser un servicio con calidad total donde se promocione la medicina preventiva con vocacin humana, cientfica y tecnolgica, para alcanzar las metas en prevencin total de enfermedades cardiovascular, metablica, ocupacional y tumoral. objetivo>> Misin Brindar atencin medica preventiva en los niveles de primarios y secundarios, buscar minuciosamente los primeros signos y sntomas de las enfermedades para evitar su evolucin hacia estudios avanzados, el dolor del paciente, el sufrimiento de la familia y la muerte sin escusa posible. objetivo>> Objetivo

Nivel Estratgico
problema>> Descripcin Lograr la implementacin de un sistema automatizado en el rea de servicios mdicos de la universidad de oriente- Monagas.

objetivo>> Objetivo Generar

Objetivos Operacionales
objetivo>> Objetivo Especfico Brindar atencin mdico - odontolgica de carcter preventivo a la comunidad universitaria, con el objeto de promover un ambiente que estimule la creatividad y productividad de todos sus miembros.

El Servicio Mdico del Ncleo Monagas es una Unidad adscrita a la Delegacin de Desarrollo y Bienestar Estudiantil, la cual se inserta dentro de una estructura organizativa institucional en consonancia con las expectativas institucionales.

Procesos de Negocio
objetivo>> Cita medica Llevar el control del nmero de pacientes atendidos por los doctores. objetivo>> Historia mdica Permitir llevar por escrito los datos del paciente, motivo de consulta, diagnostico y evolucin. objetivo>> Boleta mdica El paciente pueda asistir a la consulta mdica especializada de doctor que no labore dentro del servicio mdico. objetivo>> Conformacin de facturas El paciente puede asistir a la consulta mdica especializada de doctor que no labore dentro del servicio mdico. objetivo>> Registro de facturas Llevar el control de la conformacin de facturas. objetivo>> Medicamentos Suministrar medicina preventiva y de primeros auxilios. objetivo>> Registro de Medicamentos Llevar el control de la entrada y salida de medicamento.

objetivo>> Libro Morbilidad Llevar el registro de pacientes que presentaron una enfermad o sntoma especifico.

objetivo>> Rcipe Mdico Tener indicaciones para la compra de medicamentos.

objetivo>> Registro de boleta Mdica Llevar el control de las boletas emitidas en el servicio mdico.

Figura 19: Diagrama de objetivos de los procesos fundamentales del rea de servicios Mdicos usando UML Business. Fuente: autor (2010).

104

Centro de Computacin Seccin de Programas y Proyectos

22. MODELO DE PROCESOS DE NEGOCIO Este modelo representa el conjunto de procesos que se realizan en el Sistema de Negocios y que conllevan al logro de los objetivos del mismo. Mediante este modelo se identifican todos los procesos que se llevan a cabo en el area de servicios medicos, la relacin entre ellos y los actores involucrados en el sistema, a fin de comprender como funciona el negocio. 4.1 Cadena de Valor del Negocio Se empleo la cadena de valor de MICHEL PORTER como modelo para analizar las Actividades Primarias (procesos fundamentales o primarios) y las Actividades de Soporte (procesos de apoyo o soporte) del rea de Servicios Medico. Las actividades principales son los cinco (5) procesos que se manejan en esa rea, las cuales permiten que se d la atencin al paciente y se pueda llevar el control de los procesos administrativo. Las actividades de soporte son aquellas que sirven de apoyo para la realizacin de las actividades dentro del rea.

Cita Mdica

Historia Mdica

Boletas Mdica

Conformacin de Factura

Solicitud de Medicamentos
Actividades Primarias

Infraestructura Medica Recurso Humano y Material

Actividades de Soporte

Desarrollo Estudiantil Coordinacion Administrativa Extencion de Personal

Figura 20: Cadena de valor del negocio usando UML 2.0 V 1.3. Fuente: autor (2010).

105

Centro de Computacin Seccin de Programas y Proyectos Las actividades de soporte son todos aquellos que aportan procesos, materiales o espacio fsico para que se puedan dar todos los procesos del rea de servicios mdico entre estas tenemos: Infraestructura Mdica: es necesario tener las instalaciones mdicas adecuadas (sala de espera, consultorios, oficina de direccin y departamento de limpieza) para poder atender la gran demanda de pacientes. Recurso Humano y Material: son indispensables las personas que tienen la capacidad para poder realizar las actividades dentro del rea (mdicos, enfermeras, secretarias etc.), de igual manera se necesita de una buena iluminacin y materiales mdicos (camillas, esterilizadores, estetoscopio, tensimetros etc.) Delegacin de Desarrollo y Bienestar Estudiantil: contribuye con el estudiante en la bsqueda de alternativas de solucin a los problemas que interfieran en su proceso de enseanzaaprendizaje y el servicio mdico es una unidad adscrita a ella, y es la que surte al servicio mdico de medicamentos bsicos. Coordinacin Administrativa: se encarga de la conduccin de los procesos administrativos, con la finalidad de lograr una efectiva distribucin y utilizacin de los recursos, tanto materiales como financieros, administrndolos para el eficiente funcionamiento de los servicios. A esta unidad se le entrega el libro de morbilidad y reporte de enfermera. Extensin de Personal: pertenece a la estructura organizativa de coordinacin administrativa, encargadas de la realizacin de diversos procesos que involucran al personal. A esta unidad se le entrega el registro de las boletas medicas emitidas, facturas conformadas, viticos y condicin de paciente.

Infraestructura Mdica

Recurso Humano Y Material

Delegacin de desarrollo y bienestar estudiantil

Coordinacin administrativa

Extensin de Personal

106

Centro de Computacin Seccin de Programas y Proyectos

4.2 Jerarqua de los Procesos de Negocio Se establece una jerarqua dentro de cada proceso del rea de servicios mdicos. Servicios Mdicos
Nivel 0

Servicios Mdicos
PROCESOS DE NEGOCIO

Nivel 1
PN 1.4 Conformacin de Factura PN 1.5

PN 1.1

PN 1.2

PN 1.3

Cita Mdica

Historia Mdica

Boletas Mdicas

Solicitud Medicamentos

de

Nivel 2
PN 1.1 Cita Mdica PN 1.2 Historia Mdica PN 1.3 Boletas Mdica PN 1.4 Conformacin de Factura PN 1.5 Solicitud de Medicamento

1.1.1 Programar mdica

cita

1.2.1 Elaboracin de Historia Mdica

1.3.1 Creacin de Boletas Mdicas

1.3.2 Consulta Externa al servicio Mdico.

1.4.1 Validar Informacin de Factura

1.5.1 Peticin de Medicamentos ante Bienestar Estudiantil

1.5.2 Suministro de Medicamentos al Paciente

Figura 21: Jerarqua de los procesos del negocio. Fuente: autor (2010)

107

Centro de Computacin Seccin de Programas y Proyectos

CITA MDICA: El proceso 1.1 es el de cita mdica que tiene como propsito llevar el control del nmero de pacientes atendidos por los doctores.

Proceso 1.1.1 Programar Cita Mdica:

Regla 1 Es un bienestar estudiantil, que ofrece la U.D.O. Regla 2 Para los obreros y empleados es un beneficio contemplado en el artculo 19 y 58 del contrato colectivo

Actor Enfermera

Objetivo Programar cita mdica al paciente <<Cumple>>

<<Controla>> <<Controla>> Solicitud El paciente presenta identificacin y solicita el servicio. Se valida informacin. <<Ejecuta>> Actor Enfermera

1.1.1 Programar Cita Mdica

<<Crea>>

Producto Cita Programada

Paciente

Consulta Se valida informacin de identidad del paciente y disponibilidad del doctor

Figura 22: Diagrama de procesos: Programar Cita. Fuente: autor (2010)

108

Centro de Computacin Seccin de Programas y Proyectos

Diagrama de actividades del proceso 1.1.1 programar Cita Mdica:

Servicios Mdicos

Nivel 0

Servicios Mdicos

1.1 Cita Mdica

1.2 Historia Mdica

1.3 Boletas Mdicas

1.4 Conformacin de Factura

1.5 Solicitud de Medicamentos

Nivel 1

Cita Mdica 1.1.1 Programar Cita Medica

Nivel 2

Paciente

Enfermera

Solicitar servicio mdico

Nivel 3

Presentar identificacin [NO] [Estudiante] Tipo de paciente? Presenta su carnet o una constancia de estudio firmada y sellada.

Usuario
Valido? [SI]

Rechazar Paciente

Verificar disponibilidad del doctor

[Obrero y Empleados] Presenta carta de autorizacin, la cual es emitida por el departamento de servicio social. [NO]

Doctor disponible?
[SI]

Cancelar cita

Programar Cita Medica

Diagrama 1: Diagrama de actividades programar cita mdica. Fuente: autor (2010)

109

Centro de Computacin Seccin de Programas y Proyectos

HISTORIA MDICA:

El proceso 1.2 es el de historia mdica que tiene como propsito llevar por escrito los datos del paciente, motivo de consulta, diagnostico y evolucin.

Proceso 1.2.1 Elaboracin de Historia Mdica:

Regla 1 Es un bienestar estudiantil, que ofrece la U.D.O. Regla 2 Para los obreros y empleados es un beneficio contemplado en el artculo 19 y 58 del contrato colectivo Objetivo El paciente pueda tener historia mdica para ser controlada su evolucin en una enfermedad, diagnostico o motivo de consulta.

Actor 1. Doctor 2. Enfermera <<Controla>>

<<Controla>> Proceso Examina y efecta un diagnostico del paciente.

<<Cumple>>

1.2.1 Elaboracin de Historia Mdica

<<Crea>> <<Ejecuta>> Actor Doctor

Doctor

Producto Se crea historia mdica y se puede emitir rcipe o referencia

Registro Se registra historia mdica

Figura 23: Diagrama de procesos: Elaboracin de Historia Mdica.

Fuente: autor (2010)

110

Centro de Computacin Seccin de Programas y Proyectos

Diagrama de actividades del proceso 1.2.1. Elaboracin de Historia Mdica:

Servicios Mdicos

Nivel 0

1. Servicios Mdicos 1.1 Cita Mdica 1.2 Historia Mdica 1.3 Boletas Mdicas 1.4 Conformar Factura 1.5 Solicitud de Medicamentos

Nivel 1

1.2 Historia Mdica 1.2.1 Elaboracin de Historia Mdica

Nivel 2

Diagrama 2: Diagrama de actividades elaborar historia mdica. Fuente: autor (2010)

111

Centro de Computacin Seccin de Programas y Proyectos

BOLETAS MDICAS:

El proceso 1.3 es el de boletas medicas el cual controlar las boletas emitidas por el rea de servicios mdicos.

Proceso 1.3.1. Creacin de Boleta Mdica.

Regla 1 Es un beneficio estudiantil que ofrece la U.D.O. Regla 2 Para los obreros y empleados es un artculo del contrato colectivo. Objetivo Que el paciente asista a consulta externa al servicio mdico. <<Cumple>>

Actor Doctor

<<Controla>>

<<Controla>>

Objeto Elabora una referencia con las indicaciones para la creacin de boleta.
Doctor

1.3.1

Creacin de Boleta Mdica

<<Ejecuta>>

Producto La auxiliar de registro y estadstica elabore la boleta medica. . <<Consulta> > Consulta Referencia del doctor.

Actor Auxiliar de registros y estadsticas

Figura 24: Diagrama de procesos: Creacin de Boleta Medica. Fuente: autor (2010)

112

Centro de Computacin Seccin de Programas y Proyectos

Diagrama de actividades del proceso 1.3.1 Creacin de Boletas Mdicas:

Servicios Mdicos

Nivel 0

Servicios Mdicos

1.1 Cita Mdica

1.2 Historia Mdica

1.3 Boletas Mdicas

1.4 Conformacin de Factura

1.5 Solicitud de Medicamentos

Nivel 1

Boletas Mdica

1.3.1 Creacin de Boletas Mdicas

1.3.2 Consulta externa servicio medico

al

Nivel 2

Doctor

Aux. Registro y Estadstica

Recibe Soporte

Delegacin de Personal

Paciente

Elaborar soporte [SI] [Obreros y Empleados]

Tipo Paciente? Doctor contratado? [NO]

Crear boleta mdica [Estudiante] Registro de boleta mdica

No crear boleta mdica

Se entrega soporte medico Se enva registro Almacenar copia de boleta de boleta medica

Recibir registro de boleta medica

Sella soporte

Recibe boleta/soporte

Diagrama 3: Diagrama de actividades del proceso creacin de boleta medica. Fuente: autor (2010)

113

Centro de Computacin Seccin de Programas y Proyectos

Proceso 1.3.2. Consulta Externa con Boleta Mdica:

Regla 1 Es un bienestar estudiantil que ofrece la U.D.O Regla 2 Para los obreros y empleados es un artculo del contrato colectivo. <<Controla>>

Actor Aux. De Registro y Estadstica <<Controla>>

Objetivo Brindarle al paciente atencin mdica especializada. <<Cumple>>

1.3.2
Objeto Recibe boleta medica de manos del paciente y diagnostica.
Doctor Externo

Consulta Externa al servicio Medico

Doctor Externo

<<Ejecuta>> Actor Doctor Externo

Proceso Enva el registro a la extensin de personal con la especificacin del monto de consulta

Figura 25: Diagrama de procesos: Consulta Externa con Boleta Medica. Fuente: autor (2010)

114

Centro de Computacin Seccin de Programas y Proyectos

Diagrama de clase del proceso 1.3.2 Consulta Externa al Servicio Mdico.

Servicios Mdicos

Nivel 0

Servicios Mdicos

1.1 Cita Mdica

1.2 Historia Mdica

1.3 Boletas Mdicas

1.4 Conformacin de Factura

1.5 Solicitud de Medicamentos

Nivel 1

Boletas Mdica

1.3.1 Creacin de Boletas Mdicas

1.3.2 Consulta externa al servicio medico

Nivel 2

Delegacin de Personal

Paciente

Medico Externo

Servicio Mdico

Recibe boleta mdica o soporte

Examinar al Paciente Especifica monto de consulta

Enva boleta mdica original y 2 copias.

Recibir boletas original con monto de consulta

Recibir 2 copia de boleta con monto de consulta Recibe copias de boleta mdica con monto de consulta

Lleva las copias de la boleta al servicio medico

Diagrama 4: Diagrama de actividades del proceso consulta externa al servicio mdico. Fuente: autor (2010)

115

Centro de Computacin Seccin de Programas y Proyectos

4.2.4 CONFORMACIN DE FACTURA: El proceso 1.4 es el de conformacin de factura el cual permitir controlar y registrar las facturas conformadas por el servicio mdico.

Proceso 1.4.1. Validar Informacin de Factura:

Regla 1 Es un derecho estudiantil Regla 2 Para los obreros y empleados es un artculo del contrato colectivo Objetivo Verifica que la informacin sea fidedigna, y conforma facturas, firmando y sellando la misma. <<Cumple>>

Actor El jefe del departamento <<Controla>>

<<Controla>>

Objeto Presenta factura de compra de medicinas.

Paciente

1.4.1

Validar Informacin de Factura.

Objeto El paciente recibe las facturas conformadas. <<Consulta>>

<<Ejecuta>> Actor Paciente

Consulta Se debe tener el rcipe medico suministrado por el doctor del servicio o por el doctor externo.

Figura 26: Diagrama de procesos: Validar Informacin de Facturas. Autor (2010)

El auxiliar de registros y estadstica registra mensualmente facturas conformadas en libro para control y registro de las mismas. Se le cancela a estudiantes los siguientes reembolsos (50% En Medicinas y Frmacos, 70% Mdico Especialista, 70% Exmenes de Laboratorios, 25-70 100% Ayuda para lentes (Dependiendo el caso), 70% Tratamiento de Conducto .Toda factura por compra de medicamentos debe tener un rcipe emitido por un mdico y sus respectivos datos.

116

Centro de Computacin Seccin de Programas y Proyectos

Si la factura no se acompaa del rcipe original, el departamento mdico elaborara un rcipe. La elaboracin de este rcipe, pasa a ser una consulta mdica, de la cual se desprende una morbilidad que ser registrada en el libro diario. Diagrama de actividad del proceso 1.4.1Validar Informacin de Factura
Servicios Mdicos

Nivel 0

Servicios Mdicos

1.1 Cita Mdica

1.2 Historia Mdica

1.3 Boletas Mdicas

1.4 Conformacin de Factura

1.5 Solicitud de Medicamentos

Nivel 1

Conformacin de Facturas

1.4.1 Validar Informacin de Factura

Nivel 2

Paciente Jefe de departamento

Aux. Registro y Estadstica

Extencion de Personal

Fames

Sindicato

Nivel 3
Presentar factura y Rcipe

Verificar informacin

Conformar factura

Registrar factura
[Si] Recibir factura conformada

Empleado?
[No] [Si]

Enva factura conformada

Recibir factura conformada Enva factura conformada Recibir factura conformada Enva factura conformada

Estudiante?
[No] Paciente obrero

Diagrama 5: Diagrama de actividades del proceso validar informacin de facturas. Fuente: autor (2010)

117

Centro de Computacin Seccin de Programas y Proyectos

4.2.5 SOLICITUD DE MEDICAMENTO: El proceso 1.5 es el de solicitud de medicamento el cual controla las entradas y salidas de medicamentos en el rea de servicios mdicos. Proceso 1.5.1. Peticin de Medicamentos Ante bienestar Estudiantil.

Regla 1 Es un bienestar estudiantil que ofrece la U.D.O Regla 2 Para los obreros y empleados es un artculo del contrato colectivo <<Controla>>

Objetivo Actor Jefe de departamento

Bienestar Estudiantil suministra medicamentos al servicio mdico.

<<Cumple>> Proceso

<<Controla>>

Solicitud

Solicita medicamentos de tipo diario a Bienestar Estudiantil.

Doctor

1.5.1 Peticin de Medicamentos ante Bienestar Estudiantil

<<Ejecuta>> Actor Bienestar Estudiantil

Bienestar Estudiantil suministra medicamentos.

Enva! Proceso

<<Solicitud> > Solicitud

Jefa de enfermera elabora carta de solicitud de medicamentos.

El servicio mdico recibe y hace nota de recepcin de medicamento.

Figura 27: Diagrama de procesos: Peticin de Medicamentos ante Bienestar Estudiantil. Fuente: autor (2010)

118

Centro de Computacin Seccin de Programas y Proyectos

Diagrama de actividades del proceso 1.5.1. Bienestar Estudiantil.

Servicios Mdicos

Peticin de Medicamentos Ante

Nivel 0

Servicios Mdicos

1.1 Cita Mdica

1.2 Historia Mdica

1.3 Boletas Mdicas

1.4 Conformacin de Factura

1.5 Solicitud de Medicamentos

Nivel 1

Solicitud de Medicamentos

1.5.1 Peticin de Medicamentos ante bienestar estudiantil

1.5.2 Suministro de Medicamentos al paciente

Nivel 2

Jefe de departamento

Jefe de enfermera
Elaborar carta de solicitud

Bienestar Estudiantil Nivel 3

Solicita medicamento

Enva solicitud

Recibir carta de solicitud

[No]
Corrige solicitud Rechazar solicitud Solicitud Correcta? [SI] Suministrar Medicamento

Realizar Nota de Recepcin

Registrar entradas

Enva nota de recepcin

Recibir nota de Recepcin

Diagrama 6: Diagrama de actividades del proceso Peticin de Medicamentos ante Bienestar Estudiantil. Fuente: autor (2010).

119

Centro de Computacin Seccin de Programas y Proyectos

Se desglosa o explota el proceso 1.5.2 Suministro de Medicamento al Paciente.

Regla 1 Es un bienestar estudiantil que ofrece a la U.D.O Regla 2 Para los obreros y empleados es un artculo del contrato colectivo

Actor Enfermera y Coordinadora de Enfermera <<Controla>>

Objetivo

El paciente recibe medicamentos de tipo diario.

.
<<Controla>> <<Cumple>>

Solicitud

Paciente

Hace la peticin de un medicamento de tipo bsico, o muestra rcipe del servicio mdico.

1.5.2 Suministro de Medicamento al Paciente

<<Ejecuta>> <<Registro>>

Servicio

Dar medicamento al paciente.

Actor Bienestar Estudiantil

Registro La salida de medicamentos genera un registro de salida. Este registro de salidas incluye nombre del medicamento, nombre del paciente y cedula de identidad.

Figura 28: Diagrama de procesos: Suministro de Medicamento al Paciente Fuente: autor (2010).

120

Centro de Computacin Seccin de Programas y Proyectos

Diagrama de actividades para el proceso 1.5.2 Suministro de Medicamento al Paciente.

Servicios Medicamentos

Servicios Mdicos

1.1 Cita Mdica

1.2 Historia Mdica

1.3 Boletas Mdicas

1.4 Conformacin de Factura

1.5 Solicitud de Medicamentos

Nivel 1

Solicitud de Medicamentos

1.5.1 Peticin y recepcin de Medicamentos

1.5.2 Suministro de Medicamentos al paciente

Nivel 2

Paciente

Enfermera

Solicita medicamento de tipo diario

Nivel 3
Verifica Informacin

[No]
Por Rcipe? Registra salidas

[Si]
Suministrar medicamento Muestra rcipe del servicio medico

Recibir medicamentos

Diagrama 7: Diagrama de actividades del proceso Suministro de Medicamento al Paciente Fuente: autor (2010)

121

Centro de Computacin Seccin de Programas y Proyectos

23. MODELADO DE REGLAS DEL NEGOCIO El modelado de reglas del negocio representa el conjunto de reglas, normas, leyes, reglamentos y estndares de la organizacin implcitas en los procesos de negocio, por cuanto rigen y regulan la ejecucin de las actividades y procesos por parte de los actores del rea de servicios mdicos. En la siguiente Figura se resaltan las reglas de negocio de dicha dependencia universitaria. El rea de servicios mdicos se rige por las normas y estndares establecidos por el departamento de Desarrollo y Bienestar Estudiantil de la Universidad de Oriente.
<<Regla>>

Reglas

<<Regla>>

Regla del Negocio

<<Regla>> NORMA Normas generales de control interno. Brindar atencin mdico-odontolgica de carcter preventivo a la comunidad universitaria

<<Regla>> OTROS Estrategias Polticas Promover un ambiente que estimule la creatividad y productividad de todos sus miembros.

<<Regla>> LEY Es un beneficio para el estudiante, el cual se establece en el departamento de desarrollo y bienestar estudiantil. Clausula 19. PRIMEROS AUXILIOS. Contrato colectivo de trabajo 1986-1988 universidad de oriente pg. 24 Clausula 58.ATENCION MDICA Y MEDICINAS. Contrato colectivo de trabajo 1986-1988 universidad de oriente pg. 49

Figura 29: Modelo de Reglas del servicio mdico de la universidad de oriente ncleo de Monagas. Fuente: autor (2010).

122

Centro de Computacin Seccin de Programas y Proyectos

24. MODELADO DE OBJETOS DEL NEGOCIO La ejecucin de los procesos involucra un conjunto de elementos denominados objetos del negocio. El modelo de objetos es una representacin del conjunto de objetos de negocios, que se crean, modifican, participan y/o fungen como recursos fundamentales en la ejecucin de las actividades asociadas a cada uno de los procesos del negocio. Estos recursos son utilizados tanto a nivel de operaciones bsicas como a nivel de los procesos de toma de decisiones en los diferentes niveles gerenciales de una organizacin o sistema. A continuacin se presenta el Diagrama de que constituye el modelo de objetos de la del rea de servicios mdicos:

Paciente

Se le puede suministrar 1

Medicamentos

Se Registran 1

1*

Salida Medicamento

de

Puede Solicitar

1* 1*

Citas

Se Registran

Tiene Una

*
1

Libro Morbilidad

Historia Mdica

Puede Emitir 1

1*

Rcipe Mdico

Puede Generar 1 1*

Facturas

Puede Emitir 1 1*

Boletas Mdicas

Diagrama 8: Diagrama de modelado de objetos del negocio. Fuente: autor (2010)

123

Centro de Computacin Seccin de Programas y Proyectos

25. MODELADO DE EVENTOS Los Eventos del Negocio son hechos cuya ocurrencia dispara la ejecucin inmediata de un conjunto de acciones asociadas a los procesos del negocio. Esta ocurrencia puede causar alteraciones sobre los estados de los Objetos de Negocios como resultado de las acciones realizadas en ese instante; un evento puede provocar la ejecucin en secuencia o no de un conjunto de acciones en distintos procesos del negocio.

Los Eventos del Negocio necesitan ser identificados y especificados de manera que pueda modelarse tanto sus causas o fuentes de origen como sus efectos o impactos en objetos y procesos del negocio. Los eventos pueden ser: planificados o no, internos originados dentro del mismo sistema o externos cuando provienen del contexto del sistema de negocios. El proceso de Modelado de Eventos es caracterizado por la Matriz evento vs. Proceso de Negocio. En esta matriz se muestra los aspectos fundamentales que puede ser capturado en el modelo de negocio para el el modelo de eventos. ste modelo permite representar el flujo de trabajo que es llevado a cabo cuando ocurre un evento bien sea externo o interno. Los diferentes eventos que fueron identificados dentro del servicio mdico se presentan en la siguiente tabla:

124

Centro de Computacin Seccin de Programas y Proyectos

Cita Mdica Eventos Solicitud de servicio, presentando identificacin. Asistir a la consulta para diagnostico mdico. Asiste a la consulta carga familiar del beneficiario. Se crea y registra historia mdica del paciente. Se registra la consulta en libro de morbilidad trimestral Se genera rcipe mdico en la consulta mdica. Se le puede emitir reposo, haciendo un informe mdico. Se genera boleta mdica para asistir a un especialista. El paciente lleva boleta mdica a consulta externa. El doctor externo lleva boleta mdica y emite diagnostico. El paciente compra medicamento El paciente lleva factura al servicio mdico. El jefe de departamento verifica informacin. El jefe del departamento conforma factura sellndola. El doctor solicita medicamento de tipo diario. El jefe de enfermera elabora carta de solicitud. El jefe de enfermera registra entrada de medicamento. El paciente solicita medicamento de tipo diario. El servicio mdico le suministra medicamento. Programar cita Mdica

Historia Mdica Elaboracin de Historia Mdica

rea de servicios Mdicos de la Universidad de Oriente Monagas Procesos del Negocio Conformacin de Boletas Mdicas Solicitud de Medicamento Factura Consulta externa Validar Peticin de Suministro de Creacin de con boleta informacin de medicamento ante medicamento al boletas Mdica Mdica consulta bienestar estudiantil paciente

Tabla 11: Matriz evento vs. Proceso de Negocio. Fuente: autor (2010)

125

Centro de Computacin Seccin de Programas y Proyectos

Implementacin de un sistema automatizado que optimice la gestin de los procesos administrativos del rea servicios mdicos de la universidad de oriente ncleo Monagas. DOCUMENTO DE DEFINICION DE REQUISITOS

Versin 1.0 Autor Fecha

Lolimar Cedeo 9-11-09 Lolimar Cedeo 27-11-09

Versin Descripcin 0.90 Versin preliminar como propuesta de desarrollo 0.91 Correcciones de versin preliminar

26. Introduccin La definicin de requisitos, consiste en determinar y documentar los requisitos funcionales y no funcionales que los actores del negocio tienen con respecto al sistema que se desea desarrollar. Por ser un proyecto de continuacin la ingeniera de requisitos ya se desarroll, se determinaron y especificaron los requisitos del sistema a travs de las entrevistas con los usuarios, en esta seccin se har una anlisis y validacin de los requisitos a partir del anlisis del modelado del negocio y validando con los usuarios del nuevo sistema. Los requisitos definen: Lo que el sistema debe hacer, la interaccin entre los usuarios y la

aplicacin, las restricciones bajo las cuales el sistema debe operar y los atributos de calidad que el sistema debe satisfacer: seguridad, facilidad de uso, documentacin, utilidad, confiabilidad, etc. Los requisitos se clasifican en dos tipos: funcionales y no funcionales. Los requisitos funcionales establecen los servicios que debe proporcionar el sistema. Los requisitos no-funcionales definen las limitaciones que se le impondrn al diseo del sistema.

27. Descubrimiento de requisitos El Descubrimiento de los Requisitos es el primer proceso de la Ingeniera de Requisitos que tiene como insumo de entrada el Modelo de Negocio y como productos de salida: dominio de jerarqua del sistema, los objetivos del negocio, procesos de negocios (cadena de valor), las reglas de negocio, actores y la lista preliminar de los requisitos funcionales.

126

Centro de Computacin Seccin de Programas y Proyectos Diagrama de proceso:

Insumo Modelo de Negocio 1. Descubrimiento de Requisitos Productos
Dominio Objetivo Proceso Reglas Actores Problemas Lista preliminar fundamentales

de

requisitos

Diagrama 9: Diagrama de proceso del descubrimiento de requisitos. Autor:2010.

Diagrama de jerarqua de los procesos de descubrimiento de requisitos:

1 Descubrimiento de Requisitos

<<Proceso>> Ingeniera de requisitos

P-1 Descubrimiento de requisitos

P-2 Anlisis de requisitos.

P-3 Especificacin de requisitos.

<<Proceso>> Ingeniera de requisitos

P-1.1 Entendimiento del dominio. P-1.2 Organizacin del conocimiento.

P-1.3 Recoleccin de requisitos.

Diagrama 10: Jerarqua de los proceso del descubrimiento de requisitos. Autor: 2010.

127

Centro de Computacin Seccin de Programas y Proyectos

<<Proceso>> Ingeniera de requisitos
P-1 Descubrimiento de requisitos

P-2 Anlisis de requisitos.

P-3 Especificacin de requisitos.

<<Proceso>> Ingeniera de requisitos

P-1.1 Entendimiento del dominio. P-1.2 Organizacin del conocimiento.

P-1.3 Recoleccin de requisitos.

<<Proceso>> Ingeniera de requisitos

P-1.1.1 Anlisis del dominio de la aplicacin. P-1.1.2 Anlisis de los procesos del negocio. P-1.1.3 Anlisis de sistemas existentes. P-1.1.4 Revisin bibliogrfica del dominio.

Diagrama 11: .Jerarqua de los proceso de entendimiento del dominio. Autor: 2010.

<<Proceso>> Ingeniera de requisitos

P-1 Descubrimiento de requisitos

P-2 Anlisis de requisitos.

P-3 Especificacin de requisitos.

<<Proceso>> Ingeniera de requisitos

P-1.1 Entendimiento del dominio. P-1.2 Organizacin del conocimiento.

P-1.3 Recoleccin de requisitos.

<<Proceso>> Ingeniera de requisitos

P-1.2.1 Filtracin del conocimiento del dominio. P-1.2.2 Organizacin del material recolectado.

Diagrama 12: Jerarqua de los proceso de organizacin del conocimiento. Autor: 2010.

128

Centro de Computacin Seccin de Programas y Proyectos

<<Proceso>> Ingeniera de requisitos

P-1 Descubrimiento de requisitos

P-2 Anlisis de requisitos.

P-3 Especificacin de requisitos.

<<Proceso>> Ingeniera de requisitos

P-1.1 Entendimiento del dominio. P-1.2 Organizacin del conocimiento.

P-1.3 Recoleccin de requisitos.

<<Proceso>> Ingeniera de requisitos

P-1.3.1 Identificacin de los interesados en el sistema. P-1.3.2 Recopilacin de requisitos de los interesados. P-1.3.3 Recopilacin de requisitos del dominio.

Diagrama 13: Jerarqua de los proceso de recoleccin de requisitos. Autor: 2010.

129

Centro de Computacin Seccin de Programas y Proyectos

Reglas del Negocio:

Cdigo RN-001 Nombre Derecho estudiantil Descripcin Todo estudiante de esta casa de estudio se encuentra en pleno derecho de utilizar su servicio mdico, pues es un beneficio que se le brinda para su pleno desarrollo estudiantil. Los trabajadores (empleados/obreros) al servicio de la U.D.O., que por naturaleza de trabajo estn expuestos a radiaciones o intoxicaciones, ser atendidos en el centro de servicios medico de la universidad, a fin de brindarles los primeros auxilios o referirlos a otros centros asistenciales, en caso de ser necesario. La U.D.O se obliga aprestar servicio mdico quirrgico, hospitalizacin, ortopedia, prtesis, esterilizacin y suministro de medicinas a los trabajadores que le prestan servicios en aquellas zonas no cubiertas por el seguro social obligatorio. Fuente Delegacin de desarrollo y bienestar estudiantil. Variacin Regla del negocio asociada ------Baja

RN-002

Clausula 19. PRIMEROS AUXILIOS. Contrato colectivo de trabajo 1986-1988 universidad de oriente pg. 24 Clausula 58.ATENCION MDICA Y MEDICINAS. Contrato colectivo de trabajo 19861988 universidad de oriente pg. 49 Suministro de Medicina

Sindicatos de trabajadoras y trabajadores de la universidad de orienteMonagas

Baja

-------

------Sindicatos de trabajadoras y trabajadores de la universidad de orienteMonagas Baja

RN-003

RN-004

Clausula 58.ATENCION MDICA Y MEDICINAS. Contrato colectivo de trabajo 19861988 universidad de oriente pg. 49 Carga familiar

Los servicios y suministros de medicinas se har extensivo al cnyuge o en su defecto a la persona con que haga vida marital, as como sus hijos solteros, legtimos, reconocidos o adoptivos hasta dieciocho (18) aos de edad, los padres , abuelos y hermanos menores que estn en bajo la proteccin directa del trabajador . Esta obligacin cesar, cuando el instituto venezolano de los seguros sociales preste tales servicios, dichos servicios sern suministrados conforme a la regulacin que la U.D.O., dicte al efecto.

Sindicatos de trabajadoras y trabajadores de la universidad de orienteMonagas

Baja

El trabajador (empleado /obrero) de la universidad de oriente tiene consigo una carga familiar, la cual con solo presentar identificacin del trabajador puede utilizar el servicio mdico. El estudiante no goza del beneficio de carga familiar, pues al presentar su identificacin solo la persona identificada como estudiante puede utilizar el servicio mdico.

Tabla 12: Reglas del Negocio (1/4). Fuente: Autor 2010.

130

Centro de Computacin Seccin de Programas y Proyectos

Cdigo RN-005 Nombre Clausula 58.ATENCION MDICA Y MEDICINAS. Contrato colectivo de trabajo 19861988 universidad de oriente pg. 49 Reposo Mdico Descripcin Cuando un trabajador requiera de reposo o juicio medico de la U.D.O, esta se obliga a pagar el salario bsico completo durante el tiempo que dure el reposo ordenado por el mdico hasta cincuenta y dos (52) semanas, siempre que el mdico ordene un reposo superior a los tres (3) das, en caso de emergencia, comprobada por el mdico de la U.D.O., este determinara la procedencia del reposo dado por otro mdico. Cuando se extiende el seguro social obligatorio a dicha zona, la U.D.O., se obliga a pagar los tres (3) primeros das que el seguro no page, siempre que este no pague el cuarto (4) da, igualmente pagara el complemento del salario bsico, durante el lapso que dure el reposo ordenado por el mdico del seguro social obligatorio. Cuando un trabajador haya cumplido con las cincuenta y dos (52) semanas de reposo y la enfermedad de la cual padece es de naturaleza incurable, que lo imposibilite para continuar en el trabajo, la U.D.O., le considera un reposo de hasta cincuenta y dos (52) semanas ms a juicio de mdico, y vencido este lapso la U.D.O., optara por continuar el pago de reposo u otorgarle una pensin de jubilacin, mas las prestaciones que puedan corresponderle. Cuando un obrero u empleado o carga familiar de los mismo amparados por el presente contrato, sea enviado por enfermedad, previa justificacin del servicio mdico de la universidad, a cualquier sitio de la republica o del exterior, la universidad conviene en otorgarle los pasajes de ida y vuelta, as como los gastos mdicos que el tratamiento genere; as mismo se har extensivo al acompaante, los gastos de pasaje areos o su equivalente nicamente. Fuente Sindicatos de trabajadoras y trabajadores de la universidad de orienteMonagas Variacin Baja Regla del negocio asociada -

RN-006

Clausula 58.ATENCION MDICA Y MEDICINAS. Contrato colectivo de trabajo 19861988 universidad de oriente pg. 49 Reposo Mdico Clausula 58.ATENCION MDICA Y MEDICINAS. Contrato colectivo de trabajo 19861988 universidad de oriente pg. 49 Reposo Mdico

Sindicatos de trabajadoras y trabajadores de la universidad de orienteMonagas

Baja

RN-007

Sindicatos de trabajadoras y trabajadores de la universidad de orienteMonagas

Baja

RN-008

Clausula 58.ATENCION MDICA Y MEDICINAS. Contrato colectivo de trabajo 19861988 universidad de oriente pg. 49 Viticos

Sindicatos de trabajadoras y trabajadores de la universidad de orienteMonagas

Baja

Tabla 12: Reglas del Negocio (2/4). Fuente: Autor 2010

131

Centro de Computacin Seccin de Programas y Proyectos

Cdigo Nombre Descripcin Fuente Variacin Regla del negocio asociada -

RN-009

Historia medica

Rcipe medico RN-010

Debe crearse una carpeta con la historia mdica del paciente. Si se trata de asistencia mdica de tipo bsica, la enfermera puede examinar al paciente, sin necesidad de elaborar una historia mdica El rcipe es de tipo corriente, conteniendo campos tales como: informacin (logo de la U.D.O, datos del paciente), sper inscripcin (letra RP, que significa tome usted), inscripcin (nombre genrico o comercial del frmaco, forma farmaceuta, va de administracin y tiempo de tratamiento) e indicaciones (pautas para la administracin correcta del frmaco). El uso de medicamentos prologados debe ir en rcipes solos. Como consecuencia del diagnostico del doctor, se emite un reposo medico al paciente (Condicin alta). Si el paciente lo requiere (solo obreros y empleados), el Jefe de Departamento puede crear un informe con la condicin y diagnostico del mismo. Dicho informe debe ser entregado a Extensin de Delegacin de Personal, por si el paciente amerita de algn cambio relacionado a su trabajo como consecuencia del diagnostico efectuado. Se tiene que hacer un libro de morbilidad trimestral dentro del rea de servicios mdicos que incluya el nmero total de pacientes que presentaron una enfermedad o sntoma especfico. Las boletas mdicas deben emitirse solo a obreros, empleados y a la carga familiar de los mismos, que se encuentre registrada en servicio social. Si el paciente es un estudiante, no se elabora boleta medica. El estudiante, solo recibe el soporte emitido por el doctor.

Servicio Mdico. Monagas 2009

UDO

Alta

Servicio Mdico. Monagas 2009

UDO Alta

Reposo medico RN-011

Servicio Mdico. Monagas 2009

UDO

Baja

RN-005

RN-012

Libro Morbilidad Trimestral

Servicio mdico. Monagas 2009

UDO Baja

Boletas Mdicas RN-013

Servicio Mdico. Monagas 2009

UDO

Baja

Tabla 12: Reglas del Negocio (3/4). Fuente: Autor 2010

132

Centro de Computacin Seccin de Programas y Proyectos

Cdigo Nombre Descripcin Fuente Variacin Regla del negocio asociada

Medicamentos RN-014

La enfermera tiene que registra salidas de medicamentos al paciente, este registro de salidas incluye nombre del medicamento, nombre del paciente y cedula de identidad. El medicamento es de tipo diario.

Servicio Mdico. UDO Monagas 2009

Baja RN-003

RN-015

Conformacin de Facturas

Solo se conforman facturas de obreros y empleados con la totalidad de su costo y a estudiantes dentro de los siguientes reembolsos (50% En Medicinas y Frmacos, 70% Mdico Especialista, 70% Exmenes de Laboratorios 25-70 100% Ayuda para lentes (Dependiendo el caso),70% Servicio Odontlogo Tratamiento de Conducto. Toda factura por compra de medicamentos debe tener un rcipe emitido por un mdico y sus respectivos datos. Las facturas deben ser presentadas en un plazo mximo de un mes para su conformacin.

Servicio Mdico. UDO Monagas 2009. Contrato Colectivo de la UDO vigente.

Baja

RN-003

RN-016

Conformacin de Facturas

Las facturas solo sern conformadas durante un lapso de 1 mes, si no se presenta la factura durante dicha fecha no se conformaran facturas.

Servicio Mdico. UDO Monagas 2009.

Alta

RN-003

RN-017

Conformacin de Facturas

Nos se conformaran facturas ni consultas externas que sean realizadas por mdicos sistmicos. De igual manera todo aquello referente a esttica personal.

Servicio Mdico. UDO Monagas 2009.

Baja

Tabla 12: Reglas del Negocio (4/4). Fuente: Autor 2010

133

Centro de Computacin Seccin de Programas y Proyectos Descripcin de Actores Actores involucrados en el de Desarrollo de la Aplicacin. Este modelo representa el conjunto de actores que participan en la ejecucin de las actividades y procesos del rea de servicios mdicos. Los actores pueden ser miembros o no de la organizacin, mquinas, equipos o sistemas automatizados. Los actores son responsables, bajo la definicin de un rol, de la consecucin de un objetivo operacional especfico. Un actor mediante la ejecucin, coordinacin y/o supervisin de un conjunto de actividades y/o tareas participa activamente en los procesos de negocios. Para definir a los diferentes actores que participan en la ejecucin del conjunto de procesos del rea de servicios mdicos UDO-Monagas, y se identifican de la siguiente manera:
Act-001 Descripcin Paciente Este representa a la persona que solicita y hace uso del servicio mdico.

Smbolo Paciente Actor Indirecto

Tabla 13: Descripcin de actores 1/10. Fuente: Autor 2010.

Act-002 Descripcin Enfermera Este representa a la persona que programar cita mdica (Recibir y anotar a los pacientes), asiste al mdico en la consulta, presta asistencia mdica de tipo bsica, revisa y elaborar historias mdicas, colabora en el inventario de medicinas, entrega un reporte de actividades semanal a la enfermera jefe donde conste el nmero de pacientes atendidos y tratamientos aplicados y controla codificacin de historias mdicas.

Smbolo Actor Directo Enfermera

Tabla 13: Descripcin de actores 2/10. Fuente: Autor 2010.

Act-003 Descripcin Doctor Este representa a la persona que prestar la asistencia mdica, realizar registros en libro de morbilidad, elaborar historia mdica y crea soporte para la elaboracin de boletas mdicas.

Smbolo Doctor Actor Directo

Tabla 13: Descripcin de actores 3/10. Fuente: Autor 2010.

134

Centro de Computacin Seccin de Programas y Proyectos

Act-004 Descripcin Jefe de Enfermera Este representa a la persona que controlar codificacin de historias mdicas, organiza y controla el uso y suministro de materiales y medicamentos, supervisa y conforma la requisicin de medicinas, hace seguimiento y evaluar el funcionamiento del servicio de enfermera, realiza reporte mensual de enfermera y realiza libro de morbilidad trimestral.

Smbolo Jefe de Enfermera Actor Directo

Tabla 13: Descripcin de actores 4/10. Fuente: Autor 2010.

Act-005 Descripcin Jefe de Departamento Este representa a la persona que prestar asistencia mdica, realiza registros en libro de morbilidad, elabora historia mdica, crea soporte para la elaboracin de boletas mdicas, conformar facturas, elabora informes de viticos, elaborar informes de diagnostico y condicin del paciente.

Smbolo Jefe de Departamento Actor Directo

Tabla 13: Descripcin de actores 4/10. Fuente: Autor 2010.

Act-006 Descripcin Auxiliar de Registro y Estadstica Este representa la dependencia que elaborar y entregar boletas para servicio de laboratorio y especialidades mdicas, registra boletas mdicas y lleva un control de facturas.

Smbolo
Auxiliar de Registro y Estadstica

Actor Directo

Tabla 13: Descripcin de actores 5/10. Fuente: Autor 2010.

Act-007 Descripcin

Medico externo o Medico no Contratado Este representa a la persona que recibir boletas mdicas y presta servicio mdico al paciente.

Smbolo Medico Externo o Medico no Contratado

Actor Indirecto

Tabla 13: Descripcin de actores 6/10. Fuente: Autor 2010.

Act-008 Descripcin

Extensin de Delegacin de Personal Este representa a la dependencia que recibe el registro de boletas mdicas, recibe informe de viticos o de condicin del paciente y recibe facturas conformadas.

Smbolo Extensin de Delegacin de Personal

Actor Indirecto

Tabla 13: Descripcin de actores 7/10. Fuente: Autor 2010.

135

Centro de Computacin Seccin de Programas y Proyectos

Act-009 Descripcin

Bienestar Estudiantil Este representa a la dependencia que recibe solicitudes de medicamentos, suministra el medicamento y rechazar solicitudes.

Smbolo Bienestar Estudiantil Actor Indirecto

Tabla 13: Descripcin de actores 8/10. Fuente: Autor 2010.

Act-010 Descripcin

Coordinacin Administrativa Este representa a la dependencia que recibe libro de morbilidad trimestralmente y recibe reporte de enfermera.

Smbolo Coordinacin Administrativa Actor Indirecto

Tabla 13: Descripcin de actores 9/10. Fuente: Autor 2010.

Act-011 Descripcin

Secretaria Este representa a la persona que elaborar comunicaciones, enva comunicaciones, lleva archivo de correspondencia emitida o recibida y transcribe informes mdicos.

Smbolo Secretaria Actor Indirecto

Tabla 13: Descripcin de actores 9/10. Fuente: Autor 2010.

28. Recoleccin de Requerimientos Iniciales

cdigo Descripcin del Requerimiento Conocer identificacin del usuario Programar una cita mdica Modificar, eliminar y consultar una cita mdica Crear una historia mdica al paciente Modificar, eliminar y consultar una historia Actor Proceso de Negocio PN 1.1 PN 1.1 PN 1.1 PN 1.2 PN 1.2 RN-009 Regla del Negocio RN-008 RN-008 Medio

R-001 R-002 R-003 R-004 R-005

Enfermera Enfermera Enfermera Doctor Doctor

En lnea En lnea En lnea En lnea En lnea

Tabla 14: Recoleccin de requerimientos iniciales 1/2. Fuente: Autor 2010

136

Centro de Computacin Seccin de Programas y Proyectos

cdigo

Descripcin del Requerimiento Registrar una boleta mdica Imprimir una boleta mdica Emitir Rcipe mdico Registrar una conformacin facturas Controlar entrada y salida de medicamento

Actor Jefe del Departamento Jefe del Departamento Doctor Jefe del Departamento Jefe de Enfermera

Proceso de Negocio PN 1.3

Regla del Negocio RN-013

Medio

R-006

En lnea

R-007 R-008 R-009

PN 1.3 PN 1.1 PN 1.4

RN-010 RN-014

Impreso Impreso En lnea

R-010

PN 1.5

RN-013 -

En lnea En lnea e impreso

Jefe del Generar Reporte de todos departamento los procesos Debe existir un registro R-012 actualizado de la Jefe del poblacin de usuarios del Departamento servicio medico Tabla 14: Recoleccin de requerimientos iniciales. Fuente: Autor 2010 R-011

En lnea

29. Anlisis de Requisitos Mediante el anlisis de los requisitos se describen los servicios y las restricciones operativas que debe proporcionar el sistema que se pretende implantar en el rea de servicios mdicos. Para esto es necesario se debe hacer una separacin entre los niveles de descripcin: Requisitos de usuario y Requisitos de sistema.

Los requisitos funcionales determinan la funcionalidad del sistema es decir lo que el sistema deber hacer involucrando todo lo referente a su comportamiento, su iteracin con los usuarios, su dominio de aplicacin (negocio), y respuesta a eventos.

Los tipos de requisitos funcionales a utilizar para el sistema se especifican a continuacin:

137

Centro de Computacin Seccin de Programas y Proyectos Requisitos de Negocio

Se expresan desde la perspectiva de la empresa: describen por que la empresa o cliente desea desarrollar el sistema. Contiene tambin objetivos, metas o necesidades que la empresa desea alcanzar con el uso del sistema. Se expresan desde la perspectiva del usuario: describen las necesidades que los usuarios tienen y las tareas que los usuarios realizan con la aplicacin. Expresan lo que el usuario ser capaz de hacer con el sistema. Requisitos dados por: Centro de computacin de la U.D.O

Requisitos del usuario

Requisitos dados por: Personal del servicio Mdico-Odontolgico.

Requisitos del Sistema

Se expresan desde la perspectiva del sistema que contiene la aplicacin: son requisitos de alto nivel para productos que tienen componentes de hardware y software.

Requisitos dados por: Centro de computacin de la U.D.O

Requisitos de Comportamiento

Se expresan desde la perspectiva del desarrollador: describen los servicios que el sistema presta a todos sus usuarios directos. Expresa lo que hace el sistema bajo ciertos estmulos o eventos.

Requisitos dados por: Pasante Lolimar Cedeo

Los requisitos no funcionales especifican criterios que pueden usarse para juzgar la operacin de un sistema en lugar de sus comportamientos especficos, ya que stos corresponden a los requisitos funcionales. Por tanto, se refieren a todos los requisitos que ni describen informacin a guardar, ni funciones a realizar. Los tipos de requisitos no funcionales a utilizar para el sistema, se especifican a continuacin:

Requisitos de Producto

Especifican el comportamiento del producto. Ejemplos: rapidez de la ejecucin, capacidad de memoria, fiabilidad, etc. Derivan de polticas y procedimientos existentes en la organizacin del cliente y del desarrollador. Ejemplos: Estndares de procesos, mtodos de diseo, lenguajes de programacin, mtodos de entrega, etc.

Requisitos dados por: Desarrollador

Requisitos organizacionales

Requisitos dados por: Centro de computacin de la U.D.O

138

Centro de Computacin Seccin de Programas y Proyectos

Requisitos Externos

Se derivan de factores externos al sistema y a sus procesos de desarrollo. Ejemplos: Requisitos de interoperatividad, legislativos, ticos, etc.

Requisitos dados por: Personas que manipularan el software

Perspectiva del producto: El sistema ser desarrollado para gestionar la integracin de los Sub-Sistemas de citas, facturas, historias mdicas, de farmacia y de generacin de reportes, la perspectiva es que sea un sistema de informacin confiable permitiendo credibilidad por parte de la comunidad universitaria, trabajadores y el gobierno central y a travs de su implementacin se espera que el producto sea totalmente funcional.

Funciones del producto: Este sistema permitir a la universidad de oriente ncleo de Monagas, especficamente en el rea de servicios mdicos: reduccin de los costos y tiempos asociados a la realizacin del trabajo que en esa rea se lleva a cabo, garantizar la productividad y eficiencia en los das laborables, incorporacin de herramientas tecnolgicas que permitan satisfacer eficaz y eficientemente las necesidades del servicio mdico-odontolgico, llevar un control de datos de los estudiantes, obreros y empleados para aumentar la velocidad de respuesta, facilidad en la manipulacin de las historias medicas, llevar un control en la generacin de boletas para mdicos externos a la institucin, llevar un control y registro de conformacin de facturas, automatizacin del control de medicamentos, registro y control de datos asociados a los doctores y servicios que presta la institucin.

Caractersticas de los usuarios: El sistema de informacin se desarroll para el personal del rea de servicios mdicos de la Universidad de Oriente del ncleo Monagas, el personal est constituido por mdicos y enfermeras que no tienen experiencias en el manejo de las computadoras y aplicaciones web, por lo tanto el

139

Centro de Computacin Seccin de Programas y Proyectos sistema deber construirse pensando en estos usuarios inexpertos en manejo de sistemas de informacin.

Suposiciones y dependencias: Los usuarios utilizan plataformas heterogneas en cuanto a sistemas operativos y herramientas de productividad.

En este apartado se presentan los requisitos funcionales y no funcionales que debern ser satisfechos por el sistema. Todos los requisitos aqu expuestos son esenciales, es decir, no sera aceptable un sistema que no satisfaga alguno de los requisitos aqu presentados.

Los requisitos funcionales se refieren a los servicios que el sistema le proporcionar al personal de servicios mdicos, por lo que describen lo que el sistema deber hacer. A continuacin se presenta la lista de los requisitos funcionales del sistema automatizado de los procesos administrativos del rea servicios mdicos de la universidad de oriente ncleo Monagas, clasificndolos en requisitos de negocio, de usuario, de sistema y de comportamiento segn la clasificacin de Wiegers, 2003.

Requisitos Funcionales:

El punto inicial en el desarrollo de un software es la descripcin de los requerimientos funcionales del sistema, los cuales moldean las funcionalidades que demandan los futuros usuarios de la aplicacin. Los requerimientos funcionales describen al sistema en trminos de entrada-salida, mientras que los no-funcionales, en trminos de cualidades deseables del sistema. A continuacin se enumeran los requisitos funcionales que se han establecido para el Sistema que se pretende implantar en el rea de servicios mdicos:

140

Centro de Computacin Seccin de Programas y Proyectos

cdigo Descripcin del Requisito El sistema debe tener la opcin de validar el usuario y administrar usuario. RF-001 RF-002 RF-003 RF-004 RF-005 RF-006 RF-007 El sistema de informacin deber mostrar un mensaje de autentificacin fallida cada vez que el nombre de usuario o claves sean invlidas. El sistema debe tener la opcin de editar, agregar o eliminar usuario. El sistema se bloquea despus de tres intentos fallidos de login. El sistema se bloquea despus de 20 minutos sin actividad. El sistema muestra el men de acuerdo al nivel de acceso que tiene asignado el usuario logueado. Se quiere que el sistema posea un men principal con mdulos en los cuales se pueda realizar los principales procesos del servicio mdico y en ellos se pueda consultar, actualizar, modificar y/o eliminar datos. El sistema tiene que mostrar un men para programar citas mdicas y consultar las ya programadas. En el men de citas medicas el mdulo de datos personales deben ser manejados los siguientes campos: Apellidos, nombres, cdula, tipo de paciente, especialidad de consulta, nombre del doctor, fecha de consulta y turno de consulta. El sistema debe arrojar un mensaje cuando la citas sea programada o no. El sistema debe manejar la opcin de de programar nuevamente un cita mdica en caso de que no se pueda programar la misma con las opciones seleccionadas por el paciente o cuando el doctor no est disponible. El sistema debe arrojar el listado de paciente que han programado cita en una determinada fecha, para modificar o eliminar paciente si es necesario y as llevar el control de la consulta. Se quiere que el sistema pueda agregar la carga familiar de un paciente (obrero o empleado).
Enfermera Administrador Administrador Administrador Administrador Administrador Administrador De Sistema De Comportamiento En lnea En lnea De Comportamiento En lnea De Sistema En lnea De Comportamiento En lnea De Comportamiento En lnea

Usuario
Administrador

Proceso de Negocio
-

Regla del Negocio

-

Tipo de Requisito
De Comportamiento

Medio
En lnea

RF-008 RF-009

Enfermera Enfermera

1.1 cita medica 1.1 cita medica 1.1 cita medica 1.1 cita medica 1.1 cita medica 1.1 cita medica

De Comportamiento

En lnea

De Comportamiento De Comportamiento De Comportamiento De Comportamiento De Comportamiento

En lnea En lnea

RF-010 RF-011 RF-012

Enfermera Enfermera

En lnea En lnea

Enfermera

RF-013

En lnea

Tabla 15: Requisitos funcionales del sistema (1/6). Fuente: Autor 2010.

141

Centro de Computacin Seccin de Programas y Proyectos

cdigo Descripcin del Requisito Se quiere que el sistema pueda permitir que el paciente pueda programar ms de una cita mdica. El sistema tiene que mostrar un men de historias medicas-odontolgicas para la elaboracin de historias mdicas y la bsqueda de historias asociadas a un paciente de paciente. Cuando el doctor ingrese al men historia mdica debe aparecer el listado de los pacientes con la cita para esa fecha y la opcin de atender paciente sin programar cita. En el men de nueva consulta mdica el mdulo de datos personales deben ser manejados por lo siguientes: Datos generales del paciente (nombre, cedula, fecha de nacimiento) y datos especficos del paciente (estado civil, direccin actual, telfono etc.) para guardar. En el men de nueva consulta mdica deben existir en campo de la seleccin de la consulta a que se quiere crear (odontolgica, medicina general o interna, ginecologa, pediatra etc.), la cual al seleccionar aparezcan con datos de correspondiente a cada una de ella para que el paciente pueda llenar. Se quiere que el sistema en la historia de un paciente muestre el historial de consultas y los datos permanentes del paciente (vicios, tratamientos permanentes, enfermedades terminales o infectocontagiosa VIH). El modulo de historia medicas tiene que generar un nmero de historia secuencial automticamente. El sistema tiene que ir generando automticamente el registro de todas las consultas hechas a los pacientes y su diagnostico para registrarlo en morbilidad. El sistema tiene que tener la opcin de bsqueda de cualquier historia medicas en el momento que el usuario as lo quiera. Cuando ya la historia mdica sea llenada y guardada, el sistema automticamente debe mostrar la opcin de emitir rcipe o referencia para boleta medica. El sistema debe guardar los registros de historias por fechas. Actor
Enfermera Doctor

Proceso de Negocio
1.1 Cita Medica 1.2 Historia medica 1.2 Historia medica

Regla del Negocio

RN-009

Tipo de Requisito
De Comportamiento De Comportamiento

Medio
En lnea En lnea

RF-014 RF-015 RF-016 RF-017

Doctor

RN-009

De Comportamiento

En lnea

Doctor

1.2 Historia medica RN-004,009

De Comportamiento

En lnea

RF-018

Doctor

1.2 Historia medica

RN-009

De Comportamiento

En lnea

RF-019

Doctor

1.2 Historia medica 1.2 Historia medica 1.2 Historia medica 1.2 Historia medica 1.2 Historia medica 1.2 Historia medica

RN-009

De Comportamiento

En lnea

RF-020 RF-021 RF-022 RF-024 RF-025

Doctor

RN-009

De Comportamiento

En lnea

Doctor

RN-009,012

De Comportamiento

En lnea

Jefe del Departamento Doctor

RN-009

De Comportamiento

En lnea

RN-009,013

De Comportamiento

En lnea

Aux. Registro y Estadstica

RN-009

De Comportamiento

En lnea

Tabla 15: Requisitos funcionales del sistema (2/6). Fuente: Autor 2010.

142

Centro de Computacin Seccin de Programas y Proyectos

cdigo Descripcin del Requisito El sistema debe mostrar la opcin de emitir rcipe para que se muestren las indicaciones al paciente del tratamiento a seguir. El sistema debera cargar un medicamento que se encuentre en la farmacia del servicio mdico, si es el que el doctor receta al paciente. Todos los medicamentos tienen que tener en el sistema una fecha de vencimiento. Para no suministrar en el rcipe un medicamento vencido. Los rcipes deben tener los formatos establecidos en el servicio mdico donde se manejen campos como: Rcipe, indicaciones, connotacin emergencia, nombre del paciente, fecha de consulta. El sistema debe tener la opcin de buscar rcipes emitidos durante una fecha determinada. Si un paciente a asistido a consultas que se le ha dado rcipe el sistema debe presentar el historial Se debe generar un nmero secuencial de rcipes mdicos. El sistema debe mostrar la opcin de emitir una referencia para poder realizarle una boleta mdica al paciente. La cual debe poseer datos como: nombre del paciente, c.i, doctor que emite referencia y doctor al cual ser emitido. El sistema debe tener un men de boleta medica para poder referir pacientes a mdicos externos al servicio. El sistema debe llevar un registro automtico de cada una de las boletas que se emitan en el servicio mdico El sistema debe generar un numero secuencial de boletas medicas automticamente. El sistema debe mostrar un formulario de la boleta medica donde se contemplen los siguientes campos: Tipo de consulta, doctor (doctor por honorario o por servicio), laboratorio. La boleta que emita el sistema tiene que mostrar: Si el doctor no tiene contrato de servicios con la institucin, por favor indicar el valor de los honorarios o viticos El sistema debe generar formato para crear un reposo medico. Actor
Doctor Doctor Doctor Doctor Aux. Registro y Estadstica Doctor Jefe del Departamento Doctor

Proceso de Negocio
1.2 Historia medica 1.2 Historia medica 1.2 Historia medica 1.2 Historia medica 1.2 Historia medica 1.2 Historia medica 1.2 Historia medica 1.2 Historia medica 1.3 Boleta medica 1.3 Boleta medica 1.3 Boleta medica 1.3 Boleta medica 1.3 Boleta medica 1.2 Historia medica

Regla del Negocio

RN-009 RN-003,009 RN-003,009 RN-009,010

Tipo de Requisito
De Comportamiento De Comportamiento De Comportamiento De Comportamiento De Comportamiento

Medio
En lnea En lnea En lnea En lnea

RF-026 RF-027 RF-028 RF-029

RF-030 RF-031 RF-032 RF-033

RN-009,010 RN-009,010 RN-010 RN-013 De Comportamiento De Comportamiento De Comportamiento

En lnea En lnea En lnea En lnea

RF-034

Aux. Registro y Estadstica

Jefe del Departamento Jefe del Departamento

RN-013

De Comportamiento

En lnea

RF-035 RF-036 RF-037

RN-013 RN-013 RN-013

De Comportamiento De Comportamiento De Comportamiento

En lnea En lnea

Aux. Registro y Estadstica

Jefe del Departamento Jefe del Departamento

En lnea En lnea Impreso En lnea

RF-038 RF-039

RN-008,013 RN-005,011

De Comportamiento De Comportamiento

Tabla 15: Requisitos funcionales del sistema (3/6). Fuente: Autor 2010.

143

Centro de Computacin Seccin de Programas y Proyectos

cdigo Descripcin del Requisito Si la boleta medica corresponde a un laboratorio, la boleta que emita el sistema debe especificar: laboratorio, exmenes a realizar y observaciones correspondientes. Si un paciente a asistido a consultas que se le ha emitido una boleta el sistema debe presentar el historial. Cuando se emita una boleta el sistema de cargar la especialidad del doctor que se le ha emitido la boleta. El sistema debe guardar los registros de boletas medicas por fechas. El sistema debe tener la opcin de buscar boletas medicas emitidas durante una fecha determinada. El sistema tiene que mostrar un men para la conformacin de las facturas. El sistema tiene que llevar el registro, y enumeracin de las facturas que sean conformadas, almacenan los datos relacionados a cada una de las facturas. El men de conformacin de facturas debe presentar los procesos de: Realizar registro de una nueva factura, visualizar el status de una factura y devolucin de una factura. Cuando se cree un nuevo registro de factura el mdulo de datos personales deben ser manejados los siguientes campos: Cedula, tipo de paciente (obrero, empleado o estudiante) y tipo de factura (si es por medicamento o por atencin especializada) Si la factura que se quiere registrar es por medicamentos el mdulo de los datos debe ser manejados los siguientes campos: Se debe reflejar el mdico (interno externo) que origino la compra, el numero del rcipe que origino la compra y valor de la factura. El sistema debe mostrar el rcipe que emiti la compra automticamente. Si la factura que se quiere registrar es por atencin especializada el mdulo de los datos debe ser manejados los siguientes campos: Se debe reflejar el mdico (interno externo) que origino la boleta, especialidad del mdico y valor de la consulta. Actor Proceso de Negocio Regla del Negocio
RN-013 RN-013 RN-013 RN-013 RN-013 RN-015,016

Tipo de Requisito
De Comportamiento De Comportamiento De Comportamiento De Comportamiento De Comportamiento De Comportamiento

Medio

RF-040 RF-041 RF-042 RF-043 RF-044 RF-045 RF-046 RF-047

1.3 Aux. Registro Boleta medica y Estadstica 1.3 Aux. Registro Boleta medica y Estadstica 1.3 Aux. Registro Boleta medica y Estadstica 1.3 Aux. Registro Boleta medica y Estadstica 1.3 Aux. Registro Boleta medica y Estadstica 1.4 Jefe del Departamento Conformacin de facturas 1.4 Jefe del Departamento Conformacin de facturas 1.4 Conformacin de Jefe del facturas Departamento 1.4 Conformacin de Jefe del facturas Departamento 1.4 Conformacin de Jefe del facturas Departamento 1.4 Jefe del Departamento Conformacin de facturas 1.4 Jefe del Departamento Conformacin de facturas

En lnea En lnea En lnea En lnea En lnea En lnea En lnea En lnea

RN-015,016

De Comportamiento

RN-015,016

De Comportamiento

RF-048

RN-015,016

De Comportamiento

En lnea

RF-049

RN-015,016

De Comportamiento

En lnea

RF-050 RF-051

RN-015,016

De Comportamiento

En lnea En lnea

RN-015,016

De Comportamiento

Tabla 15: Requisitos funcionales del sistema (4/6). Fuente: Autor 2010.

144

Centro de Computacin Seccin de Programas y Proyectos

cdigo Descripcin del Requisito En el sistema debe mostrar las de facturas generada por un paciente: Si es procesada por medicamento, procesadas por atencin especializada. Cuando una factura ya este registrada, el sistema debe indicarlo. RF-053 RF-054 RF-055 RF-056 RF-057 RF-058 El sistema debe mostrar el curso de una factura: Si la factura fue conformada, si ya fue enviada a su departamento correspondiente. El sistema tiene que mostrar un men con todo lo relativo a medicamentos, para realizar las actividades relacionadas con este. En el men de medicamentos se tiene que hacer el mantenimiento de medicinas que estn en el servicio mdico, tanto medicamento que entre como los que salgan. Para el mantenimiento de medicamento se tienen que manejar campos como: nombre del medicamento, presentacin, cantidad y fecha de vencimiento En el men de mantenimiento de medicamento, cuando se quiera ingresar un medicamento nuevo se debe manejar datos como: nombre, presentacin, cantidad y fecha de vencimiento. El men de medicamento debe permitir salidas eventuales, donde se introduzca el nombre del medicamento a salir, la cantidad y su respectiva fecha de vencimiento. El sistema tiene que pedir datos del paciente y motivo de despacho cuando salga un medicamento por una salida eventual (dolor de cabeza, fiebre, gripe, etc) El men de medicamento debe tener la opcin de podre mostrar todos los medicamentos que salen por rcipe medico. Cuando un medicamento salga por rcipe medico, se beben mostrar datos como: numero de rcipe que cargo medicamento, nombre del paciente y cantidad de medicamento a despachar. El sistema que va a disear debe tener un men para generar reporte segn quiera el usuario. Actor Proceso de Negocio
facturas 1.4 Conformacin de facturas 1.4 Conformacin de facturas 1.5 Solicitud de Medicamentos 1.5 Solicitud de Medicamentos 1.5 Solicitud de Medicamentos 1.5 Solicitud de Medicamentos 1.5 Solicitud Medicamentos 1.5 Solicitud de Medicamentos 1.5 Solicitud de Medicamentos 1.5 Solicitud de Medicamentos -

Regla del Negocio

RN-015,016

Tipo de Requisito
De Comportamiento

Medio

RF-052

1.4 Jefe del Departamento Conformacin de

En lnea En lnea En lnea En lnea En lnea En lnea En lnea

Jefe del Departamento Jefe del Departamento Jefe de enfermera Jefe de enfermera Jefe de enfermera Jefe de enfermera Jefe de enfermera Jefe de enfermera Jefe de enfermera Doctor Aux. Registro y Estadstica.

RN-015,016

De Comportamiento

RN-015,016 RN-003,014

De Comportamiento

De Comportamiento RN-003,014

De Comportamiento De Comportamiento

RN-003,014

RN-003,014

De Comportamiento

RF-059 RF-060 RF-061 RF-062

de RN-003,014

De Comportamiento

En lnea En lnea En lnea En lnea

RN-003,014

De Comportamiento

RN-003,014

De Comportamiento

RN-003,014

De Comportamiento

RF-063

De Comportamiento

En lnea

Tabla 15: Requisitos funcionales del sistema (5/6). Fuente: Autor 2010.

145

Centro de Computacin Seccin de Programas y Proyectos

cdigo Descripcin del Requisito Cuando el sistema genere reporte de salidas de medicamentos debe mostrar varios criterios de bsqueda al usuario como: buscarlo por cedula de paciente, por nombre de medicamento o con un criterio de fechas. Cuando el sistema genere reporte de de boletas emitidas debe mostrar varios criterios de bsqueda al usuario como: tipo de boleta emitida (para laboratorio, para medico por honorario, o por servicio), si es asociada a paciente introducir cedula de paciente o con un criterio de fechas. Cuando el sistema genere un reporte de rcipe que se han emitido en el servicio mdico debe mostrar varios criterios de bsqueda al usuario como: tipo de rcipe, rcipe asociado a un doctor especfico o con un criterio de fechas. Cuando el sistema genere un reporte de citas que se han emitido en el servicio mdico debe mostrar varios criterios de bsqueda al usuario como: tipo de citas (atendidas y programadas), citas asociado a un doctor especfico o con un criterio de fechas. Cuando el sistema genere un reporte de facturas conformadas que se han emitido en el servicio mdico debe mostrar varios criterios de bsqueda al usuario como: cedula de un paciente o con un criterio de fechas. Actor Aux. Registro y Estadstica Aux. Registro y Estadstica Proceso de Negocio
-

Regla del Negocio

-

Tipo de Requisito

Medio

RF-064

De Comportamiento

En lnea

RF-065

De Comportamiento

En lnea

RF-066

RF-067

Aux. Registro y Estadstica y jefe del departamento. Aux. Registro y Estadstica y jefe del departamento.

De Comportamiento

En lnea

De Comportamiento

En lnea

RF-068

RF-069

Cuando el sistema genere un reporte de morbilidad que se han emitido en el servicio mdico debe mostrar varios criterios de bsqueda al usuario como: por motivo de consulta, por especialidad, por intervalos de edades, por tipo de paciente o con un criterio de fechas. Todos los reportes deben tener la opcin de imprimirse.

RF-070

RF-071

El sistema debe mostrar va web el formato para llenar el informe mdico apaciente.

Aux. Registro y Estadstica y jefe del departamento. Aux. Registro y Estadstica y jefe del departamento. Aux. Registro y Estadstica y jefe del departamento. 1.2 Jefe del departamento. Historia Medica RN-006,007

De Comportamiento

En lnea

De Comportamiento

En lnea

De Comportamiento

En lnea

De Comportamiento

En lnea

Tabla 15: Requisitos funcionales del sistema (6/6). Fuente: Autor 2010..

146

Centro de Computacin Seccin de Programas y Proyectos Requisitos No Funcionales del Sistema

cdigo Descripcin del Requisito Usuario Todo los Usuarios Todo los Usuarios Todo los Usuarios Todo los Usuarios Proceso de Negocio Regla de Negocio Tipo de Requisito De Producto Externo Medio

La interfaz del sistema deber ser implementada como una aplicacin web.
RNF-001

En lnea En lnea

RNF-002 RNF-003 RNF-004

Cada usuario que desee ingresar al sistema, deber introducir en la pgina principal un cdigo de usuario y una contrasea, la cual ser validada por el sistema, dndole acceso al sistema o envindole un mensaje para que introduzca nuevamente sus datos. Cada usuario del sistema tendr asignado un determinado perfil, usado para activar los servicios u opciones que l pueda realizar dentro del sistema. El sistema deber tener una interfaz grfica sencilla y amigable, basada en mens, ventanas, listas desplegables y botones de accin. El sistema deber ser desarrollado bajo software libre, utilizando el lenguaje de programacin PHP y utilizar el estndar HTML para el diseo de las pginas web del sistema. De esta forma se garantizara que el cdigo HTML generado pueda ser interpretado por cualquier de los navegadores comerciales existentes en el mercado. El sistema debe basar sus comunicaciones en protocolos estndar de Internet.

De Producto Organizacional

En lnea En lnea

RNF-005 RNF-006 RNF-007

Desarrollador Desarrollador Desarrollador

Organizacional De Producto De Producto

El sistema debe ser diseado segn la arquitectura cliente-servidor.

El sistema debe utilizar los servicios de la red interna de la UDO (para establecer comunicacin entre los clientes, el servidor web y el manejador de base de datos. La organizacin, manipulacin, consulta y almacenamiento de los datos estar bajo la responsabilidad del sistema manejador de base de datos relacional de Sybase MSQL

RNF-008 RNF-009

Desarrollador Desarrollador

Organizacional Organizacional

RNF-010

El sistema es una aplicacin web bajo una plataforma XAMPP: apache, MySQL, PHP.

Desarrollador

Organizacional

Tabla 16: Requisito no funcionales del sistema (1/2). Fuente: Autor 2010.

147

Centro de Computacin Seccin de Programas y Proyectos Requisitos No Funcionales del Sistema

cdigo Descripcin del Requisito Usuario Proceso Regla de Negocio De Producto Desarrollador Desarrollador Desarrollador Externos Externos De Producto Tipo de Requisito Organizacional De Producto Organizacional Medio

RNF-011 RNF-012 RNF-013 RNF-015 RNF-016 RNF-017 RNF-018

El sistema debe ser capaz de ejecutarse en la configuracin estndar de los equipos de cliente de la universidad. El sistema debe tener rapidez y rendimiento de respuesta.

Desarrollador Desarrollador

La aplicacin debe mantener los estilos (colores, tipos de letra, etc.) establecidos por el centro de computacin. La interfaz se implementara con HTML simple sin marcos o aplets java. La computadora tiene que contar con un procesador de su poder suficiente para ejecutar el sistema y una memoria suficiente para almacenar los grandes volmenes de informacin. El sistema no debe revelar ninguna informacin que se sea utilizada por terceros, solo los usuarios del sistema. El sistema debe imprimir los reporte y citas que el usuario necesite.

Desarrollador Desarrollador

Tabla 16: Requisitos no funcionales del sistema (2/2). Fuente: Autor 2010.

148

Centro de Computacin Seccin de Programas y Proyectos

Atributos de calidad: Expresan las calidades o propiedades de calidad que el sistema debe satisfacer. Estos requisitos describen entre otros el rendimiento que la aplicacin debe mostrar, la confiabilidad que debe poseer, la seguridad que debe proveer y la utilidad que debe garantizar. ISO 9126: ISO 9126 es un estndar internacional para la evaluacin del Software. El estndar est dividido en cuatro partes las cuales dirigen, respectivamente, lo siguiente: modelo de calidad, mtricas externas, mtricas internas y calidad en las mtricas de uso. Normas de calidad del producto: Este estndar est pensado para los desarrolladores, adquirentes, personal de aseguramiento de calidad y evaluadores independientes, responsables de especificar y evaluar la calidad del producto software. Por tanto, puede servir para validar la completitud de una definicin de requisitos, identificar requisitos de calidad de software, objetivos de diseo y prueba, criterios de aseguramiento de la calidad, etc. La calidad del software puede evaluarse midiendo los atributos internos (medidas estticas o productos intermedios) o atributos externos (comportamiento del cdigo cuando se ejecuta).

El objetivo no es necesariamente alcanzar una calidad perfecta, sino la necesaria y suficiente para cada contexto de uso a la hora de la entrega y del uso por parte de los usuarios. Es necesario comprender las necesidades reales de los usuarios con tanto detalle como sea posible (requisitos).

149

Centro de Computacin Seccin de Programas y Proyectos Diferentes aspectos de la calidad: Interna: medible a partir de las caractersticas intrnsecas, como el cdigo fuente. Externa: medible en el comportamiento del producto, como en una prueba. En uso: durante la utilizacin efectiva por parte del usuario.

Fase de ISO 9126:

Calidad de Producto

Calidad Interna

9126-3

9126-1

Calidad Externa

9126-2

Calidad en Uso

9126-4

Figura 30: CALIDAD Y MEDICIN DE ISO. Coral Calero, Ismael Caballero, M ngeles Moraga, Manuel Serrano (2008/2009).

ISO 9126-3: Mtricas Internas de la Calidad del Producto de Software Mtricas Internas

Aplican a un producto de software no ejecutable. Aplican durante las etapas de su desarrollo. Permiten medir la calidad de los entregables intermedios. Permiten predecir la calidad del producto final. Permiten al usuario iniciar acciones correctivas temprano en el ciclo de desarrollo.

El modelo de calidad establecido en la primera parte del estndar, ISO 9126-3, clasifica la calidad del software en un conjunto estructurado de caractersticas y sus caractersticas de la siguiente manera:

150

Centro de Computacin Seccin de Programas y Proyectos

Mtricas de Funcionalidad 1. Adecuacin: Capacidad del producto software para proporcionar un conjunto apropiado de funciones para tareas y objetivos de usuario especificados. 2. Exactitud: Capacidad del producto software para proporcionar los resultados o efectos correctos o acordados, con el grado necesario de precisin. 3. Interoperabilidad: Capacidad del producto software para interactuar con uno o ms sistemas especificados. 4. Seguridad: Capacidad del producto software para proteger informacin y datos de manera que las personas o sistemas no autorizados no puedan leerlos o modificarlos, al tiempo que no se deniega el acceso a las personas o sistemas autorizados. 5. Conformidad de la funcionalidad: Capacidad del producto software para adherirse a normas, convenciones o regulaciones en leyes y prescripciones similares relacionadas con funcionalidad. Mtricas de Fiabilidad 1. Madurez: Capacidad del producto software para evitar fallar como resultado de fallos en el software. 2. Tolerancia a fallos: Capacidad del software para mantener un nivel especificado de prestaciones en caso de fallos software o de infringir sus interfaces especificados. 3. Capacidad de recuperacin: Capacidad del producto software para reestablecer un nivel de prestaciones especificado y de recuperar los datos directamente afectados en caso de fallo. 4. Cumplimiento de la fiabilidad: Capacidad del producto software para adherirse a normas, convenciones o regulaciones relacionadas con al fiabilidad.

151

Centro de Computacin Seccin de Programas y Proyectos Mtricas de Usabilidad 1. Entendibilidad: Capacidad del producto software que permite al usuario entender si el software es adecuado y cmo puede ser usado para unas tareas o condiciones de uso particulares. 2. Aprendibilidad: Capacidad del producto software que permite al usuario aprender sobre su aplicacin. 3. Operatibilidad: Capacidad del producto software que permite al usuario operarlo y controlarlo. 4. Atractivo: Capacidad del producto software para ser atractivo al usuario. 5. Conformidad de la usabilidad: Capacidad del producto software para adherirse a normas, convenciones, guas de estilo o regulaciones relacionadas con la usabilidad. Mtricas de Eficiencia 1. Comportamiento en el tiempo: Capacidad del producto software para proporcionar tiempos de respuesta, tiempos de proceso y potencia apropiados, bajo condiciones determinadas. 2. Utilizacin de recursos: Capacidad del producto software para usar las cantidades y tipos de recursos adecuados cuando el software lleva a cabo su funcin bajo condiciones determinadas. 3. Conformidad de la eficiencia: Capacidad del producto software para adherirse a normas o convenciones relacionadas con la eficiencia. Mantenibilidad 1. Analizabilidad: Es la capacidad del producto software para serle diagnosticadas deficiencias o causas de los fallos en el software, o para identificar las partes que han de ser modificadas.

152

Centro de Computacin Seccin de Programas y Proyectos 2. Cambiabilidad: Capacidad del producto software que permite que una determinada modificacin sea implementada. 3. Estabilidad: Capacidad del producto software para evitar efectos inesperados debidos a modificaciones del software 4. Examinabilidad: Capacidad del producto software que permite que el software modificado sea validado. 5. Conformidad de la mantenibilidad: Capacidad del producto software para adherirse a normas o convenciones relacionadas con la mantenibilidad. Portabilidad 1 Adaptabilidad: Capacidad del producto software para ser adaptado a diferentes entornos especificados, sin aplicar acciones o mecanismos distintos de aquellos proporcionados para este propsito por el propio software considerado. 2 Instalabilidad: Capacidad del producto software para ser instalado en un entorno especificado. 3 Coexistencia: Capacidad del producto software para coexistir con otro software independiente, en un entorno comn, compartiendo recursos comunes. 4 Capacidad para reemplazar: Capacidad del producto software para ser usado en lugar de otro producto software, para el mismo propsito, en el mismo entorno. 5 Cumplimiento de la portabilidad: Capacidad del producto software para adherirse a normas o convenciones relacionadas con la portabilidad. A continuacin se muestra el modelo de calidad interna y externa para el rea de servicios mdicos, las cuales fueron escogidas luego del su estudio y sern las utilizadas para medir la calidad del software:

153

Centro de Computacin Seccin de Programas y Proyectos

MODELO DE CALIDAD INTERNA Y EXTERNA PARA EL AREA DE SERVICIOS MEDICOS

Funcionabilidad
Un conjunto de atributos que se relacionan con la existencia de un conjunto de funciones y sus propiedades especficas. Las funciones son aquellas que satisfacen lo indicado o implica necesidades.

Fiabilidad
Un conjunto de atributos relacionados con la capacidad del software de mantener su nivel de prestacin bajo condiciones establecidas durante un perodo de tiempo establecido.

Usabilidad
Un conjunto de atributos relacionados con el esfuerzo necesitado para el uso, y en la valoracin individual de tal uso, por un establecido o implicado conjunto de usuarios.

Eficiencia
Conjunto de atributos relacionados con la relacin entre el nivel de desempeo del software y la cantidad de recursos necesitados bajo condiciones establecidas.

Mantenibilidad
Conjunto de atributos relacionados con la facilidad de extender, modificar o corregir errores en un sistema software.

Transportabilidad
Conjunto de atributos relacionados con la capacidad de un sistema software para ser transferido desde una plataforma a otra.

1. 2. 3. 4. 5.

Adecuidad Exactidud Interoperabilidad Seguridad Conformidad de la funcionalidad

1. 2. 3. 4.

Madurez Tolerancia a fallos Recuperabilidad Conformidad de la fiabilidad

1. 2. 3. 4. 5.

Entendibilidad Aprendibilidad Operatibilidad Atractivo Conformidad de la usabilidad

1. Comportamiento en el tiempo 2. Utilizacin de recursos 3. Conformidad de la eficiencia

1. 2. 3. 4. 5.

Analizabilidad Cambiabilidad Estabilidad Examinabilidad Conformidad de la mantenibilidad

1. 2. 3. 4. 5.

Adaptabilidad Instalabilidad Coexistencia Remplazabilidad Conformidad de la transportabilidad

Adecuidad

Madurez

Entendibilidad

Comportamiento en el Tiempo

Cambiabilidad

Conformidad de Transportabilidad

la

Figura 31: Modelo de calidad interna y externa para el rea de servicios mdicos. Fuente: autor 2010

154

UNUVERSISDAD DE ORIENTE NUCLEO MONAGASCE CENNTRO DE COMPUTACION TODOS LOS DERECHOS RESERVADOS

5.2 ETAPA II
PROCESOS DE DISEO, GESTIN Y SOPORTE.

Centro de Computacin Seccin de Programas y Proyectos Implementacin de un sistema automatizado que optimice la gestin de los procesos administrativos del rea servicios mdicos de la universidad de oriente ncleo Monagas DOCUMENTO DE ESPECIFICACION DE REQUISITOS DE SOFTWARE Versin 0.90 Autor Fecha Versin Descripcin Lolimar Cedeo 28-11-09 0.90 Versin preliminar como propuesta de desarrollo Lolimar Cedeo 23-08-010 0.91 Correcciones de versin preliminar 30. Introduccin Este documento tcnico es producido en el proceso de Ingeniera de Requisitos. Su objetivo es identificar, describir, especificar y documentar cada uno de los requisitos funcionales que la aplicacin empresarial debe satisfacer. El documento persigue dos objetivos complementarios. Por un lado, busca identificar y describir las necesidades de informacin y requisitos funcionales que los usuarios de la aplicacin tienen; y, por otro lado, el documento especfico tcnicamente los requisitos funcionales y no-funcionales se emplearn para disear la aplicacin. 31. Requisitos Especficos En esta parte se hace uso de los Diagramas de casos de uso: los cuales son una descripcin de las acciones de un sistema desde el punto de vista del usuario. Para los desarrolladores del sistema, sta es una herramienta valiosa, ya que es una tcnica de aciertos y errores para obtener los requerimientos del sistema desde el punto de vista del usuario. Esto es importante si la finalidad es crear un sistema que pueda ser utilizado por la gente en general (no slo por expertos en computacin). (Smuller, J. sf, p.75 ). A continuacin se describen las funcionalidades del sistema mediante el caso de uso general del sistema, resultante al proceso estudiado anteriormente modelado del negocio y especificacin de requisitos de software.

156

Centro de Computacin Seccin de Programas y Proyectos

Servicio Mdico U.D.O Monagas
Programar Cita Mdica

Jefe de Enfermeria

Enfermera

Elaborar Historias Mdicas

<<Include>>

Mdico General Especilista Pediatra

Emitir Recipe Mdico

<<Include>>

Autenticar Usuario

<<Include>>
Odontologo

Mdico Internista
Emitir Boletas Mdicas

<<Include>>

Ginecologo Higienista Dental Aux.de Registro y Estadistica

Conformar Facturas

<<Include>>

<<Include>>

Jefe de Departamento
Suministro de Medicamentos

Figura 32: Caso de uso general del sistema. Fuente: autor (2010).

A continuacin se detallara el curso tpico de eventos y flujos alternativos, entre el usuario y la respuesta que se genera todos los procesos el sistema. Aqu se pueden visualizar los diagramas de secuencia y diagrama de clase que rigen la construccin del sistema, as como tambin, el prototipo de las pantallas relacionadas al caso de uso. Estos diagramas de casos de uso comprenden la funcionalidad del sistema, como se comportan los procesos, como se interacta con el entorno grafico para el correcto funcionamiento. Tambin se describe mantenimientos y administracin del sistema

157

Centro de Computacin Seccin de Programas y Proyectos Caso de Uso Autor Actores 1. 2. 3. Validar usuario CU-001 Lolimar Cedeo M. Fecha 7-12-09 Versin 0.91 1.Doctor 4. Jefe de enfermera 2.Enfermeras 5. Auxiliar de registros y estadsticas 3.Jefe del Departamento 6. Secretaria Primario- Esencial Documento Definicin de Requisitos El usuario introduzca su login y su clave y pulse ingresar Entrada de usuario al sistema. Diagrama de Caso de Uso
Validar Usuario Usuario del Sistema

Tipo Referencias Pre -condicin Pos -condicin

Diagrama 14: Diagrama de caso de uso de validar usuario. Fuente: auto 2010

Propsito Validar y administrar los usuarios que harn uso del sistema. Resumen Este caso de uso restringe el acceso de usuarios al sistema, y establece que cada usuario cuente con un nombre de usuario y una clave de acceso al sistema Curso Normal (Bsico)
1 2 3 El usuario ingresa su nombre de usuario y su contrasea El usuario tilda administrador El usuario presiona el botn Ingresar 4 El sistema valida usuario y clave El sistema busca nivel de acceso del usuario. 5 El sistema permite el ingreso del usuario al sistema con su respectivo nivel de acceso. 6 El sistema muestra pantalla principal o de bienvenida y el men en base al perfil.

Tabla 17: Curso bsico de eventos para validar usuario. Fuente: auto 2010

Cursos Alternos
4 5 Si el usuario no es vlido, el sistema emite un mensaje usuario no valido y permite ingresar el nombre de usuario y la clave nuevamente. Si se trata del administrador, el sistema carga las opciones de administrador.

Tabla 18: Curso alternativo de eventos para validar usuario. Fuente: auto 2010

Comentarios
1

Requisito ms importante del sistema, ya que restringe el uso del sistema solo a usuarios predeterminados.

Usuario del Sistema

158

Centro de Computacin Seccin de Programas y Proyectos

Diagrama de Secuencia
W:ValidarUsuario

Usuario

NiveldeAcceso

ModUsu

PagUsu

Modulos

Paginas

Usuario del Sistema

Ingresar Nombre de Usuario Ingresar Contrasea Presionar " Ingresar" T ilda Abministrador Enviar login

ValidarNombreUsuario ( )

ValidarContrasea ( )
Si Resp=false Usuario NO valido

Procesar
Si Resp=true

Procesar Modulos CargaModulosUsuario ( ) Procesa CargaModulo ( )

Verifica

CargaUsuario( ) Procesa Mostrar Pantalla de Inicio CargarPagina ( )

Diagrama 15: Diagrama de secuencia validar usuario. Fuente: auto 2010.

159

Centro de Computacin Seccin de Programas y Proyectos

Pantallas para la validacin de usuarios

Pantalla 1/2. Validar usuario. Fuente: autor 2010

Pantalla 2/2. Men principal usuario doctor .fuente: autor 2010

160

Centro de Computacin Seccin de Programas y Proyectos Caso de Uso Autor Actores Tipo Referencias Administrar Usuarios CU-002

Lolimar Cedeo M. Fecha 7-12-09 Versin 0.91 1. Administrador del Sistema. Primario- Esencial Documento Definicin de Requisitos El usuario ha sido autenticado correctamente en el sistema (Ver Pre -condicin Especificacin de Casos de uso Validar Usuario). Cambios en la cuentas de usuario segn la seleccin (Eliminar, Pos -condicin Modificar o crear nuevo usuario) de los diferentes usuarios del sistema.

Diagrama de Caso de Uso

Validar Usuario
<<Include>>

Administar Usuarios Administardor del Sistema

Diagrama 16: Diagrama de caso de uso de administrar usuario. Fuente: auto 2010

Propsito Establecer perfiles a cada usuario del sistema. Resumen Permitir ingresar, modificar y eliminas usuarios. Curso Normal (Bsico): 1 Este caso de uso inicia cuando el administrador del sistema selecciona del men principal la opcin Administrar Usuarios.

El sistema abre nueva ventana y muestra las opciones de administracin (Nuevo, Modificar, Eliminar, Salir). Tambin, busca los usuarios que han sido creados y los muestra en pantalla. 3 Crear Nuevo Usuario. 3.1 El sistema abre ventana, busca los tipos El administrador del sistema de usuarios y muestra en pantalla el presiona el botn Nuevo para formulario para editar los datos del nuevo crear un nuevo usuario usuario. 3.2 El administrador introduce los 3.3 El sistema valida los datos introducidos. datos del nuevo usuario y presiona botn Agregar. 2
Tabla 19: Curso bsico de eventos para validar usuario 1/2. Fuente: auto 2010

161

Centro de Computacin Seccin de Programas y Proyectos Curso Normal (Bsico): El sistema registra nuevo usuario. El sistema muestra un mensaje en pantalla avisando que el usuario se ha creado correctamente. 4.1 El sistema busca usuarios de acuerdo a los 4 Buscar Usuario. El usuario llena campo de caracteres tecleados y los muestra en bsqueda y presiona botn pantalla. Filtrar. 5.1 El sistema abre ventana, busca el usuario 5 Editar Usuario. El usuario administrador seleccionado, busca los tipos de usuarios selecciona un usuario de la lista y muestra en pantalla el formulario con la y presiona el botn informacin del usuario seleccionado. Modificar. 5.2 El administrador edita los datos 5.3 El sistema actualiza los datos del usuario. del usuario y presiona el botn Modificar. 5.4 El sistema muestra en pantalla un mensaje indicando que los datos han sido actualizados exitosamente. 6.1 El sistema muestra un mensaje de 6 Eliminar Usuario. El Administrador selecciona un confirmacin para eliminar el usuario. usuario de la lista y presiona el botn Eliminar. sistema elimina el usuario 6.2 El usuario confirma eliminacin. 6.3 El seleccionado. 6.4 El sistema enva un mensaje indicando que el usuario ha sido eliminado exitosamente. 7.1 Para terminar con el proceso, el sistema usuario administrador 7 El presiona el botn Salir. abre y muestra el men principal.
Tabla 19: Curso bsico de eventos para validar usuario 2/2. Fuente: auto 2010 3.4 3.5

Cursos Alternos 1a En caso de que el administrador quiera volver a la pantalla anterior sin guardar los datos del nuevo usuario, entonces presiona el botn Retornar. 1b En caso de que los datos introducidos del usuario sean invlidos o que el nombre de usuario introducido ya exista, el sistema enva un mensaje para que el usuario verifique la informacin.
Tabla 20: Curso alternos de eventos para validar usuario. Fuente: auto 2010

Comentarios
1

Caso de uso que permite ingresar, modificar y eliminas usuarios.

Usuario del Sistema

162

Centro de Computacin Seccin de Programas y Proyectos

Diagrama de Secuencia
W:M enuAdm i ni s tardor Adm i ni s trador del Si s tem a W:Us uari o Us uari o Ni vel deAcces o Sel ecci onar Adm i ni s trar Us uari o Abre Ventana ( ) Bus ca Us uari o M ues tra Li s ta de Us uari os Bus carUs uari o ( )

Preci ona Boton "Nuevo" Abre Ventana ( ) Carga Form ul ari o Cam bi a ventana CargaNi vel deAcces o( ) Bus ca Ni vel de Acces o Crear Nuevo Us uari o M ues tra Form ul ari o Ll ena Datos de Us uari o a Crear Preci ona Boton "Agregar" Si Res p=fal s e Datos i nval i dos o ya exi s te el nom dre us uari o Si Res p=true Us uari o creado exi tos am ente AbreVentana ( ) Ins ertar( ) Proces a Res p=Val i dar( ) CargaForm ul ari o ( ) Bus caNi vel deAcces o ( )

M ues tra pantal l a anteri or

Pres ona Boton "Retornar" i Retornar M ues tra pantal l a anteri or AbreVentana( )

Ll ena cam po de bus queda Bus car Us uari o Pres ona Boton "Fi l trar" i Bus ca us uari os de acuerdo a cadena de caracteres tecl ados M ues tra l i s ta de us uari os de acuerdo a l a cadena tecl ada Bus carUs uari o( )

Sel ecci ona us uari o de l a l i s ta Pres ona Boton"M odi ca" i AbreVentana( ) Cam bi a ventana

Carga form ul ari o con datos de us uari o Bus caUs uari o(codUs uari o)

CargarT i poUs uari o( ) CargaNi vel deAcces o ( )

Edi tar Us uari o M ues tra form ul ari o con datos de us uari o

Bus ca ni vel de acces o Cargaform ul ari o( )

Edi tar datos del us uari o Pres ona Boton " M odi fi car" i Proces a Us uari o actual i zado exi tos am ente M ues tra pantal l a anteri or AbreVentana( ) Actual i za( )

Sal i r

Pres ona Boton " Sal i r" i

AbreVentana( ) M ues tra Pantl l a de M enu Pri nci pal

Diagrama 17: diagrama de secuencia administrar usuario. Fuente: auto 2010

163

Centro de Computacin Seccin de Programas y Proyectos

Pantallas

Pantalla 1/2. Validar usuario Administrador

Pantalla 1/2. Pantalla Administrador del sistema

164

Centro de Computacin Seccin de Programas y Proyectos

Caso de Uso Autor Actores Tipo Referencias

Programar Cita Mdica

CU-003

Lolimar Cedeo M. Fecha 7-12-09 Versin 0.91 Enfermeras. Primario- Esencial Documento Definicin de Requisitos Que el usuario se haya validado Pre -condicin Que el usuario haya ingresado al men de programar citas. Programacin de citas medicas. Creacin de un listado con los pacientes que tienen citas Pos -condicin programadas, clasificadas por doctor y en el orden en que las citan han sido programadas. Diagrama de Caso de Uso

Validar Usuario

<<Include>>

Programar Cita Mdica

Usuario del Sistema

Diagrama 18: Diagrama de caso de uso Programar Cita Mdica. Fuente: auto 2010

Propsito Permitir a los usuarios programar citas mdicas a los pacientes. Resumen En ste caso de uso se describe el proceso para programar citas mdicas.se puede realizar la programacin de una cita con un doctor especifico, una especialidad y a un turno determinado.
Curso Normal (Bsico) Este caso de uso comienza cuando el 2 1 usuario selecciona la opcin Programar cita del men principal. Ingresa cedula de identidad del 4 3 paciente. El usuario selecciona especialidad. 5 6

El sistema muestra la pantalla para realizar la programacin de la cita. El sistema muestra datos del paciente. El sistema asocia especialidad a doctores.

Tabla 21: Curso bsico de eventos para programar cita. Fuente: auto 2010

165

Centro de Computacin Seccin de Programas y Proyectos

Curso Normal (Bsico) 7 8 9 10 11 El usuario selecciona nombre del doctor El usuario selecciona fecha de consulta. El usuario selecciona el turno de consulta. El usuario presiona botn 12 Consultar. 13 14 15 El sistema muestra men desplegable con los nombres de los doctores.

El sistema valida paciente. El sistema verifica disponibilidad del doctor. (Considerando turno seleccionado y la fecha) El sistema muestra informacin sobre el paciente (Datos Generales) El sistema muestra informacin de la cita segn lo programado (Turno, especialidad y doctor) El sistema verifica que no se ha excedido el nmero de citas por da El sistema identifica la cita con el status Programada El sistema guarda cita programada. El mensaje certifica que la cita ha sido programada. En caso de programar otra cita, no es necesario ingresar la cedula de identidad del paciente.

16

El usuario presiona Programar cita

el

botn 17 18 19

20

Tabla 21: Curso bsico de eventos para programar cita. Fuente: auto 2010 Cursos Alternos 3 Si el paciente no es vlido, el sistema emite un mensaje al usuario sobre el caso. Si el doctor no se encuentra disponible en la fecha o en el turno seleccionado, el 12 sistema permite que se vuelva a programar la cita. Debido a que se tiene un lmite de consultas por turno, cuando se llega a este 12 lmite, no es posible programar la cita de acuerdo a lo seleccionado. El sistema emite un mensaje informando sobre el caso.
Tabla 22: Curso alterno de eventos para programar cita. Fuente: auto 2010

Comentarios
1
Usuario del Sistema 2

Se programa la cita con el doctor, especialidad y en el turno seleccionado por el paciente. Se crea un listado con los nombres de los pacientes que han programado citas El sistema muestra opciones para citas en caso de que no se pueda programar la misma con las opciones seleccionadas por el paciente

3 Usuario del Sistema

Usuario del Sistema

166

Centro de Computacin Seccin de Programas y Proyectos

Diagrama de Clases de Programar Cita Medica

Paciente + + + + + + + + + + + + + + + + + + cd_pac tipo_pac sexo cert edad nombres apellidos fec_nac ecivil correo cod_parent : : : : : : : : : : : int int String String int String String Date String String int

Cita + + + + + + + + + + + + + id id_paciente especialidad doctor fecha turno estado : : : : : : : int int String String Date String String

0..*

Parentesco + cod_parent : int + descripcion : String

1..*

1 TipoPaciente + codigo : int + descripciontipopaciente : String + mostar ()

ProgramarCita() () Eliminar () Mostrar () Actualizar () Consultar () Modificar ()

MostrarDatos () VerificarTipoPaciente () BuscarTipoPaciente () ValidarUsuario () MostrarUsuario () BuscarPaciente () BuscarPacienteF ()

1 Doctor + + + + + + + + + + + id nomdre apellido cedula especilidad tipo horario Nuevo () Eliminar () Modificar () Mostar () : : : : : : : String int String String int int int 1

Especialidad - id : int - nomdre : String + + + + Nuevo () Modificar () Mostar () Actualizar () 0..*

CargaFamiliar + + + + + + + + nomdre apellido cedulafam cod_paren correo cert sexo edad fecha_nac : : : : : : : : : String String String int String int String int Date

TipoDoctores 1 + id : int + descripcion : String + + + + Nuevo () Modificar () Eliminar () Mostar ()

+ MostarDatos ()

1 Horario + + + + id dia turno doctor : : : : int int int int Turno 1 + id : int - descripcion : String + mostrarturno ()

+ Mostar () + Editar () + Guardar ()

Diagrama 19: diagrama de clase programar cita. Fuente: auto 2010

167

Centro de Computacin Seccin de Programas y Proyectos

Diagrama de Secuencia Programar Cita :

W:ValidarPaciente w:citas Citas Paciente Doctor Especialidad Horario

Usuario del Sistema

Seleccionar programar cita Ingresar cedula de identidad del paciente Procesar CargaPaciente( ) Mostrar Pantallas Para Programar cita

Seleccionar especialidad

Procesa Activa Muestra Nomdre de doctores CargaDoctores( ) Procesa disponibilidad Muestra turno de doctor CargaTurno( ) cargaEspecilidad( )

Seleccionar doctor Seleccionar turno Seleccionar fecha para la consulta Presionar "Programar Citar" Procesa VerificarFecha ( ) VerificaLimite( ) IdentificaStatus( ) GuardaCita( ) Mostrar datos de la cita (Doctor, fecha y turno)

Diagrama 20: Diagrama de Secuencia Programar Cita. Fuente: auto 2010.

168

Centro de Computacin Seccin de Programas y Proyectos

Pantallas Programar Cita

Pantalla 1/4. Selecciona Programar Cita Mdica

Pantalla 2/4. Validar Paciente

169

Centro de Computacin Seccin de Programas y Proyectos

Pantallas Programar Cita

Pantalla 3/4. Programar Cita Medica

Pantalla 4/4. Cita Programada

170

Centro de Computacin Seccin de Programas y Proyectos Caso de Uso Autor Consultar Citas Programadas CU-004

Lolimar Cedeo M. Fecha 7-12-09 Versin 0.91 Doctor Jefe del departamento Actores Enfermeras. Primario- Esencial Tipo Documento Definicin de Requisitos Referencias Que el usuario haya realizado correctamente el login al sistema Pre -condicin Que el usuario haya programado con anterioridad una cita. Que el usuario haya ingresado al men de citas, consultar cita. Pos -condicin Eliminar, consultar o modificar una cita programada.
Diagrama de Caso de Uso

Programar Cita

<<Include>> <<Include>> Validar Usuario

Consultar Citas Programadas

Usuario del Sistema

Diagrama 21: Diagrama de caso de uso consultar cita. Fuente: auto 2010

Propsito Permitir al usuario consultar las citas que han sido programadas.

Resumen En ste caso de uso se describe el proceso para consultar citas mdicas ya programadas y se puede realizar modificaciones.

171

Centro de Computacin Seccin de Programas y Proyectos Curso Normal (Bsico) El usuario selecciona la opcin 2 1 Consultar Citas del men de citas. El usuario selecciona la fecha. 3 4 5 6

El sistema muestra la pantalla para realizar consultas de citas programadas. El sistema busca citas en la fecha seleccionada. El sistema muestra las citas programadas de acuerdo a la bsqueda.

El usuario selecciona Modificar 6.1 Presionar Aceptar. 6.2 El sistema muestra pantalla para modificar los datos de la consulta. 13 El usuario presiona Eliminar El sistema emite un mensaje notificando 13.1 Presionar Aceptar. 13.2 que la cita ha sido eliminada.
Tabla 23: Curso bsico de eventos para consultar cita. Fuente: auto 2010

Cursos Alternos Cuando el sistema busca citas programadas, y no se encuentra programada 5 ninguna cita, el sistema emite un mensaje informando sobre el caso.
Tabla 24: Curso alterno de eventos para consultar cita. Fuente: auto 2010

Comentarios
1

Se puede consultar las citas que han sido programadas, con el fin de: modificar, consultar o eliminar Al momento de suspender una consulta se puede elimina muchas citas al mismo tiempo. Se puede editar una cita sin modificar el mdico tratante El paciente tiene que presentar su cedula o su constancia de estudio para poder solicitar algn dato en el departamento.

2 Usuario del Sistema

Usuario del Sistema 3

2
Usuario del Sistema 4

2
Usuario del Sistema

172

Centro de Computacin Seccin de Programas y Proyectos

Diagrama de Secuencia

W:ConsultarCita Usuario del Sistema

Citas

Seleccionar fecha Consultar Citas Programadas Procesa Muestra Resultados BuscaCita( )

Presionar "Consultar Citas"

Seleccionar Editar Modificar Edita turno de la consulta Edita Fecha Precionael boton "Guardar"

Procesar Mostar pantalla para editar datos Carga( )

Procesa GuardarCitas ( )

Eliminar

Seleccionar "Eliminar"

Procesar Mostrar mensaje de aviso EliminarCita ( )

Diagrama 22: Diagrama de secuencia consultar cita. Fuente: Autor 2010.

173

Centro de Computacin Seccin de Programas y Proyectos

PANTALLAS

Pantalla 1/4. Selecciona Consultar Cita Programadas

Pantalla 1/4. Consulta de Cita Programadas

174

Centro de Computacin Seccin de Programas y Proyectos

PANTALLAS

Pantalla 1/4. Modificar Cita Programadas

Pantalla 1/4. Eliminar Cita Programadas

175

Centro de Computacin Seccin de Programas y Proyectos Caso de Uso Autor Elaborar Historia Medica CU-005

Lolimar Cedeo M. Fecha 7-12-09 Versin 0.91 1. Doctor. 2. Jefe del departamento. Actores 3. Enfermeras. Primario- Esencial Tipo Documento Definicin de Requisitos Referencias 1. Que el usuario haya validado. Pre -condicin Que el usuario haya ingresado al men de historias Med.-Odont. Almacenamiento de datos en la historia mdica del paciente. Pos -condicin Registro de todas las consultas hechas a los pacientes.

Diagrama de Caso de Uso

Elaborar Historia

Usuario del Sistema

Diagrama 23: Diagrama de caso de uso elaborar historia mdica. Fuente: auto 2010

Propsito Registrar historias medico-odontolgicas mediante el acceso y utilizacin del sistema. Resumen En ste caso de uso se describe el proceso para la elaboracin de una historia. Este proceso permite manipular de manera ordenada y llevar un control de las historias de los pacientes
Curso Normal (Bsico) El caso de uso comienza cuando el 2 1 usuario selecciona la opcin Crear Nueva Historia, en el men Historias Med.-Odont. El usuario marca la casilla del paciente 3 que desea atender. El usuario presiona el botn Aceptar. 5 4 6

El sistema muestra pantalla con el listado de pacientes del da, segn el orden en que han programado las citas.

El sistema captura seleccin. El sistema busca datos generales del paciente.

Tabla 25: Curso bsico de eventos para elaborar historia mdica. Fuente: auto 2010

176

Centro de Computacin Seccin de Programas y Proyectos

Curso Normal (Bsico) continuacin 8 El sistema muestra formulario de captura de informacin relacionada a datos especficos del paciente

9 10

El usuario ingresa la informacin solicitada en el formulario. El usuario presiona la opcin 11 Guardar. 12 13

El sistema valida los datos. El sistema guarda los datos.

14

16

El sistema muestra el formulario de datos del paciente completado y men con los tipos de historia. El usuario selecciona el tipo de historia 15 El sistema muestra formulario correspondiente al que se desea crear. tipo de historia seleccionada con su respectivo nmero de historia. 15.1 Cuando se trata de la primera consulta, se deben ingresar los datos permanentes del tipo de historia y los datos de la consulta del da. 15.2 Cuando el paciente ha tenido previas consultas en la especialidad, solo se deben llenar los datos de la consulta del da. Los datos permanentes ya aparecern cargados, al igual que un historial con los datos de las ultimas 10 consultas, ordenados por fecha a partir de la fecha ms reciente. El usuario presiona el botn 17 El sistema valida datos Guardar. El sistema guarda datos. 18 El sistema muestra el formulario completado. 19

Tabla 25: Curso bsico de eventos para elaborar historia mdica. Fuente: auto 2010
Cursos Alternos Cuando el usuario marca la casilla del paciente que desea atender y este no est en el listado, ingresar su cedula de identidad para generar consulta. Se realiza una validacin del paciente y se 3 presiona el botn Aceptar Cuando el usuario ingresa la informacin solicitada en el formulario correspondiente al tipo de 10 historia seleccionada. Si algn dato obligatoria est vaco, el sistema lo indica y le permite al usuario efectuar la correccin. 10 Cuando el usuario presiona el botn Guardar en cualquier parte, si surge algn error en la grabacin, el sistema informa y muestra la pantalla de captura de datos nuevamente.

Tabla 26: Curso alterno de eventos para elaborar historia mdica. Fuente: auto 2010.
Comentarios
1

El usuario del sistema podr elaborar historias mdicas de pacientes. El sistema debe validar para que se genere un nmero de historia secuencial automticamente, se muestre el formulario de la historia mdica, y se pueda observar el historial de consultas.

Usuario del Sistema

177

Centro de Computacin Seccin de Programas y Proyectos

Diagrama de Clases

HistoriaGenerarInterna + + + + + + + + + + + + + + + id id_doctor id_dp_general_interno motivo_consulta enfermedad_actual diagnostico tratamiento_pac tension_arterial peso pulso temperatura talla frecuencia_resp observaciones fecha : int : int : int : String : String : String : String : String : String : String : String : String : String : String : Date

DatosPermentesGenerarInterna + + + + + + + + + id id_dp telefono antecedentes habitos_psicobiologico periodo_tiempo inscripcion indicacion fecha : int : int : String : String : String : String : String : String : Date 1

HistoriaGinecologica ControlColoscopio + + + + + + + + id id_dp id_doctor fecha aa lugol nomdre estado : int : int : int : Date : String : String : String : String + + + + + + + + + id id_ginecologica id_doctor motivo_consulta efermedad_actual alimentacion t_paciente d_evolucion fecha : int : int : int : String : String 1 : String : String : String : Date

DatosPermanentesGinecologica + + + + id id_historia antecedentes_c_o antecedentes_g : int : int : String : String

+ InsertarDatos () + MostarDatos () + GuardarDatos ()

+ MostrarDatosPermanentes () + GuardarDatosPermanentes () 1..*

+ MostrarDatosPermanentes () + GuardarDatosPermanentes () 1..*

DatosPermanentesPediatrica id id_dp id_doctor edad sexo nomdrem edadm ocupacionm nombrep edadp ocupacionp a_perinatales complicacion alimentacion medicamentos a_personales a_psicomotor denticion a_familiar fecha : int : int : int : int : String : String : int : String : String : String : String : String : String : String : String : String : String : String : String ser: Puede : Date HistoriaPediatrica 1 + + + + + + + + + + + + + + + + + + + + + + + id id_dp_pediatrica id_doctor t_arterial temperatura peso talla pulso f_respiratoria f_cardiaca a_general orl cardiopulmonar abdomen extremidades neurologo fecha : int : int : int : Date : String : String : String : String : String : String : String : String : String : String : String : String : Date

+ Guardar () + Mostar () + Insertar ()

+ InsertarDatos () + MostarDatos () + GuardarDatos ()

+ + + + + + + + +

+ + + Historias + 1..* + id : int + cedula : String + tipo : String + VerificarHistoria () + insertarHistoriaVacia () + insertarHistoriaLlena () + mostrarDatos () + GuardarDatosPermanentes () + InsertarDatosPermanentes () + + + + + 1..* + + DatosPermanentesOdontologica + + id : int + + id_doctor : int + id_historia : int + direccion : String + telefono : String + referencias : String + edad : String + e_general : String + piso_boca : String + carrillo : String + lengua : String + paladar : String + encias : String + protesis : String + t_relizado : String + fecha : Date + MostarDatosPermantes () + ActulizarHistoriaLlena ()

MostrarDatosPermanentes () GuardarDatosPermanentes ()

MuestraDatos () InsertarDatos () GuardarDatos () GuardarEsquemaImunuzacion () MostarEsquemaImunuzacion () VerificarEsquemaImunuzacion () Tiene

0..* + + + +

VacunaDosis id_dp_pediatrica id_vacuna id_dosis fecha : int : int : int : Date

Dentadura 1 + + + + + + + + + + + + id id_dp id_posicion_dent fechaq descripcion tratamiento observacion : int : int : int : Date : String : String : String

PosicionDentadura 1..* + + + + id lado posicion numero : int : String : String : int 1..* Vacunas - id : int - nomdre : String + Insertar () + Guardar ()

1..* Dosis - id : int - nombre : String + Insertar () + Guaradar () + Mostar ()

MostrarDentadura () GuardarDentadura () ActualizarDentadura () ComprobarDentadura () BuscarIDDientes ()

Diagrama 24: Diagrama de clase elaborar historia Mdica. Fuente: auto 2010

178

Centro de Computacin Seccin de Programas y Proyectos

Diagrama de Secuencia
Citas Usuario del Sistema Mostrar pacientes del dia Seleccionar paciente Presionar "Aceptar" Procesar CapturarPaciente( ) Activar CargaTipoDeHistoria( ) Crear Historia Medica Muestar formulario de historia con datos del paciente caragdo Ingresar datos en el formulario Presionar "Guardar" Procesar CargaFormulario( ) GuardarDatos ( ) Muestra Mensaje "Se ha Creado Historia Medica" Activa datos de consulta GeneraNumerodeHistoria( ) CargarFormulario ( ) W:HistoriaMedica Paciente HistoriasMedicas DatosPermanentesDeHistoria Historia

Incresar datos de consulta

Procesa CargaDatosdeConsulta( )

GuardaDatosdeConsulta( )

Muestra pantalla para relizar busqueda Consultar Historia Medica Introdusca C.I sin programar cita Procesa C.I CargaPaciente( ) Activa

Mestra historia del paciente

CargaHistoriaMedica( )

Diagrama 25: Diagrama de secuencia elaborar historia Mdica. Fuente: auto 2010

179

Centro de Computacin Seccin de Programas y Proyectos

PANTALLAS

Pantalla 1/8. Selecciona Crear Historia Mdica

Pantalla 2/8. Selecciona Historia Mdica

180

Centro de Computacin Seccin de Programas y Proyectos

PANTALLAS

Pantalla 4/6. Historia Mdica Odontolgica

Pantalla 3/8. Selecciona el Paciente para atender

Pantalla 4/8. Historial de Consulta Mdica

181

Centro de Computacin Seccin de Programas y Proyectos

PANTALLAS

Pantalla 5/8. Historia Mdica Ginecolgica

182

Centro de Computacin Seccin de Programas y Proyectos

PANTALLAS

Pantalla 6/8. Historia Mdica Odontolgica

183

Centro de Computacin Seccin de Programas y Proyectos

PANTALLAS

Pantalla 7/8. Historia Mdica Peditrica

184

Centro de Computacin Seccin de Programas y Proyectos

PANTALLAS

Pantalla 8/8. Historia Mdica General O Interna

185

Centro de Computacin Seccin de Programas y Proyectos

Caso de Uso Autor

Registrar Boleta Mdica

CU-006

Lolimar Cedeo M. Fecha 7-12-09 Versin 0.91 1. Doctor. 2. Jefe del departamento. Actores 3. Aux. Registro y Estadstica Primario- Esencial Tipo Documento Definicin de Requisitos Referencias 1. Que el usuario haya realizado correctamente el login al sistema Pre -condicin 2. Que el usuario haya seleccionado la opcin CREAR BOLETAS en el men BOLETAS Crear un boleta medica. Pos -condicin Creacin de un historial con informacin de las boletas emitidas.
Diagrama de Caso de Uso

Validar Usuario

<<Includede>>
Registrar Boleta

Usuario del Sistema

Diagrama 26: Diagrama de caso de uso crear boleta Mdica. Fuente: auto 2010

Propsito Llevar un registro de cada una de las boletas medicas que se emiten en el servicio mdico de la universidad. Resumen En ste caso de uso se describe el proceso para la creacin y registro de boletas medicas. El sistema debe validar y llevar un registro de las mismas, donde se genere un nmero de boleta automtico, se muestre el formulario de la boleta mdica y se tenga un registro de las boletas emitidas.

186

Centro de Computacin Seccin de Programas y Proyectos

Curso Normal (Bsico) 1 2 El usuario hace clic en Crear 2.1 nueva boleta. 2.2 El caso de uso comienza cuando el sistema muestra pantalla principal de boletas mdicas. El sistema captura la seleccin. El sistema muestra pantalla de captura de datos. 2.3 El usuario selecciona tipo de 2.4 doctor. El sistema muestra men con los nombre de los doctores de acuerdo al tipo de doctor seleccionado. El sistema muestra men con especialidades asociadas al doctor. las

2.5 2.7 2.8

El usuario selecciona el nombre del 2.6 doctor. El usuario selecciona especialidad. El usuario Guardar. presiona el botn 2.9

El sistema guarda datos de la boleta mdica.

2.1 Generar un nmero de boleta. 0 2.1 Guardar datos en el sistema. 1 2.1 El sistema asocia boleta a historia mdica del paciente (Almacena Boleta) 2 2.1 El sistema muestra registro de la boleta con opcin de impresin 3 El usuario seleccione una fecha en 3.1 El sistema muestra la boleta correspondiente a el Historial de Boletas Mdicas la fecha seleccionada. Tabla 27: Curso bsico de eventos para crear boleta mdica. Fuente: auto 2010

Cursos Alternos Si se selecciona la opcin Laboratorio, el sistema mostrar un formulario para 2.3 seleccionar el tipo de examen de laboratorio que se deber realizar el paciente. Cuando se guardan los datos en el sistema., si surge algn error en la grabacin, se informa y regresa a la pantalla de captura de datos. Cuando el usuario seleccione una fecha en el Historial de Boletas Mdicas, si el paciente no cuenta con un historial de boletas mdicas, se muestra un mensaje de 3 Historial Vacio. Por otra parte y debido a que el sistema solo muestra en el cuadro de historial, las ultimas 5 boletas emitidas, se presenta un buscador para seleccionar un intervalo de fechas para boletas emitidas. Tabla 28: Curso alterno de eventos para crear boleta mdica. Fuente: auto 2010

2.9

Comentarios
1
Usuario del Sistema

Con este caso de uso se puede registrar de forma ordenada las boletas medicas emitidas.

187

Centro de Computacin Seccin de Programas y Proyectos

Diagrama de Clases

Boleta + + + + + + id servicio detalles observaciones fecha cd_pac : int : String : String : String : Date : String

BoletaPaciente + id_boleta : int + cd_pac : String + id : int 1 + mostrar () + buscar () + guardar () Laboratorio 1 + id : int + nombre : String + rif : String + Mostrar () + Buscar () + Guardar ()

+ Crear () + Eliminar () + Consultar ()

1 Doctores + + + + + + + + + + + + id nombre apellido cedula especilidad horario tipo Nuevo () Modificar () Actualizar () Mostar () Eliminar () : int : String : String : String : String : String : int

Diagrama 27: Diagrama de clase crear boleta Medica. Fuente: auto 2010

188

Centro de Computacin Seccin de Programas y Proyectos

Diagrama de Secuencia
W: Boleta Medica Usuario del Sistema Boleta BoletaPaciente Dotores Especialidad Laboratorio

Seleccionar "Nueva Boleta"

Procesar seleccin Mostrar formulario CapturarSeleccion ( )

Boleta de Consulta Medica Externa

Seleccionar tipo de consulta

Procesar Mostrar nombres de doctores del tipo seleccionado CargaDoctores ( )

Selecciona doctor

Procesa Mostrar la especialida asociada al doctor CargarEspecialidad ( )

Seleciona Especialidad

Crear Boleta Medica Boleta de Laboratorio

Introduce T ipo de consulta

Procesa Mostrar nombre de laboratorio seleccionado CargaLaboratorio( )

Selecciona Laboratorio Seleciona Examenes

Introduce Observaciones Presionar "Guardar" Procesa validaBoletaPaciente( ) Activa ValidaDatos( ) AlmacenaBoleta ( ) GenerarNumeroDeBoleta ( )

Imprimir Boleta

Seleccionar "Imprimir"

Procesar Impresin Boleta Impresa

Introduce Nmero de boletas Consultar Boleta Mostra boleta

Procesar Activa BuscarBoletaMedica ( ) ValidaDatos( )

Diagrama 28: Diagrama de secuencia crear boleta Medica. Fuente: auto 2010

189

Centro de Computacin Seccin de Programas y Proyectos

PANTALLAS

Pantalla 1/6. Selecciona Crear Boleta Medica

Pantalla 2/6. Crear Boleta Mdica

190

Centro de Computacin Seccin de Programas y Proyectos

PANTALLAS

Pantalla 3/6. Crear Boleta Para Consulta Externa

Pantalla 4/6. Crear Boleta Para Exmenes de Laboratorio

191

Centro de Computacin Seccin de Programas y Proyectos

PANTALLAS

Pantalla 5/6. Boleta Mdica Para Imprimir

Pantalla 6/6. Buscar Boleta Mdica

192

Centro de Computacin Seccin de Programas y Proyectos Caso de Uso Autor Emitir Rcipe Mdico CU-007

Lolimar Cedeo M. Fecha 7-12-09 Versin 0.91 1. Doctor. 2. Jefe del departamento. Actores 3. Enfermeras. Primario- Esencial Tipo Documento Definicin de Requisitos Referencias 1. Que usuario se haya validado. Pre -condicin 2. Que el usuario haya seleccionado la opcin Rcipes Mdicos. Pos -condicin 1.Emitir un rcipe mdico
Diagrama de Caso de Uso
Elaborar Historias Mdicas

<<Include>> Condicion= Requiere Tratamiento Punto de Extension= Verificar Historia Emitir Recipe Medico

Usuario del Sistema

Diagrama 29: Diagrama de caso de uso emitir rcipe medico. Fuente: auto 2010

Propsito
Emitir rcipes mdicos a travs del sistema.

Resumen
En ste caso de uso se describe el proceso para la emisin de un rcipe mdico. Se establecer un formato nico de rcipes mdicos y se llevar un registro de los rcipes emitidos Curso Normal (Bsico) El sistema muestra pantalla principal de rcipes mdicos. El usuario hace clic en el botn Nuevo 2 El sistema muestra formulario Web del Rcipe. En el men Rcipe rcipe medico (Rp. e indicaciones) El usuario hace clic en Cargar medicamento 3.1 El sistema muestra motor de bsqueda de medicamento. de farmacia. El usuario ingresa el nombre del medicamento. El usuario presiona Buscar 3.5 El sistema busca el medicamento. 3.6 El sistema muestra el resultado de la bsqueda El usuario ingresa la cantidad del medicamento que desea agregar al rcipe. El usuario marca la casilla Agregar a rcipe 1

2 3 3.2 3.4

3.7 3.8

Tabla 29: Curso bsico de eventos para emitir rcipe medico. Fuente: auto 2010

193

Centro de Computacin Seccin de Programas y Proyectos

Curso Normal (Bsico) continuacin El usuario presiona el Aceptar 3.9 4 botn El sistema carga el nombre del medicamento 3.10 seleccionado, presentacin y cantidad en la seccin denominada Rp. del formulario del rcipe medico.

4.1 5

El usuario selecciona la opcin Emitir Rcipe comun. El usuario ingresa informacin en Rp. e indicaciones. El usuario presiona el botn Emitir 6 Rcipe Medico 7

El sistema guarda los datos. El sistema muestra el rcipe medico con opcin de impresin. El sistema muestra los rcipes medico creado en la fecha seleccionada.

Para realizar la bsqueda de un rcipe El usuario selecciona una fecha en el 9 Historial de Rcipes Mdicos.

Tabla 28: Curso bsico de eventos para emitir rcipe medico. Fuente: auto 2010
Cursos Alternos Cuando se quiera cargar otro medicamento de farmacia, se debe hacer clic en Cargar otro 3 medicamento de farmacia y el sistema muestra motor de bsqueda de medicamento continuando con el flujo de eventos. Cuando el sistema busca el medicamento, y no se cuenta con el medicamento buscado, el sistema 3.6 emite un mensaje notificando que el medicamento no se encuentra disponible. Cuando el usuario ingresa la cantidad del medicamento que desea agregar al rcipe, si la cantidad 3.7 ingresada no se encuentra disponible, el sistema emite un mensaje notificando al usuario sobre el caso. Le permite seleccionar otra cantidad. Cuando el usuario aprieta el botn Emitir Rcipe Medico, si la emisin del rcipe se debe a una emergencia, el usuario puede seleccionar la casilla de verificacin Emergencia. En este caso, el 5 rcipe en su formato de impresin contiene dicha observacin. Cuando el sistema muestra pantalla principal de rcipes mdicos, si no han creado rcipes en 9 consultas anteriores, el cuadro de historial se presenta vacio.

Tabla 30: Curso alterno de eventos para emitir rcipe medico. Fuente: auto 2010
Comentarios
1

Este caso de uso permite crear un modelo nico y automatizado de rcipes, donde: se genere un nmero secuencial de rcipe medico, se muestre el formulario de rcipe medico, se asocie el rcipe emitido al paciente y se imprime para poder entregrselo al paciente.

Usuario del Sistema

Diagrama de Clases
Recipe + + + + + + + + + + iddoctor numero indicaciones fecha paciente estatus : : : : : : int int String Date String String + + + + DetallesRecipe numrecipe rp cant id : : : : int String int int

1..*

+ Mostrar ()

Mostar Recipe () Mostar Recipes () Eliminar () Crear ()

Diagrama 30: Diagrama de clase emitir rcipe medico. Fuente: autor 2010

194

Centro de Computacin Seccin de Programas y Proyectos

Diagrama de Secuencia
W:Reci pe Medi co Usuari o del Si stema Medi camentos Reci pe Detal l esReci pe Hi stori aMedi ca

Impresora

Mostrar pantal l a pri nci pal de reci pes medi cos Sel ecci onar "Crear Reci pe" Procesar Sel ecci on Mostrar formul ari o de reci pe medi co CapturarSel ecci on ( )

Hacer cl i c en cargar medi camento de farmaci a

Procesar Mostrar motor de busqueda CapturarSel ecci on ( )

Crear Reci pe Cargando Medi camento de Farmaci a

Ingresar nombre del medi camento

Presi onar "Buscar"

Procesar Busqueda Mostrar resul tado de medi camentos BuscarMedi camento ( )

Ingresar Canti dad Marcar casi l l a "Agregar a reci pe" Presi onar "Aceptar" Crear Nuevo Reci pe Procesar CargaNomdreyPresentaci on( ) Envi ar nombre y presentaci on del medi camento GuardaMedi camento( ) Mostrar formul aci on con secci on de Rp. compl etada Ingresar Indi caci ones GuardarDetal l esReci pe( )

Ingresar Rp. e i ndi caci ones Presi onar "Emi ti r Reci pe" Crear Reci pe Comn GenerarNumero ( ) Procesar Val i darDatos ( )

GuardarDatos ( ) Asoci ar a Mostrar reci pe compl etado Al macenarReci pe ( )

Sel ecci onar "Impri mi r" Impri mi r Reci pe

Proceso Impri mi r

Reci pe Impreso

Consul tas Reci pe

Sel ecci onar fecha

Procesar MostrarResul tado BuscarReci peMedi co ( )

Diagrama 31: Diagrama de secuencia emitir rcipe medico. Fuente: autor 2010.

195

Centro de Computacin Seccin de Programas y Proyectos

PANTALLAS

Pantalla 1/4. Emitir Rcipe despus de consulta

Pantalla 2/4. Emitir Rcipe con indicaciones normal

196

Centro de Computacin Seccin de Programas y Proyectos

PANTALLAS

Pantalla 3/4. Cargar Medicamento de Farmacia

Pantalla 3/4. Bsqueda de Rcipe

197

Centro de Computacin Seccin de Programas y Proyectos Caso de Uso Autor Conformar Factura CU-008 Lolimar Cedeo M. Fecha 14-6-10 Versin 0.91 1. Aux. Registro y Estadstica Actores 2. Jefe del departamento. Primario- Esencial Tipo Documento Definicin de Requisitos Referencias Que el paciente presente el soporte correspondiente para poder efectuar la conformacin. Pre -condicin Que el usuario haya realizado correctamente el login al sistema. Que el usuario haya seleccionado la opcin NUEVO REGISTRO dentro de la CONFORMACION DE FACTURA. Conformacin de nueva factura Pos -condicin Notificarle al Paciente su exitoso.
Diagrama de Caso de Uso

Factura Por Atencion Mdica Especilizada

<<Extiende>>

Factura Por Medicamento Condicion = Soporte Valido Punto de Extensin = Validar Soporte <<Extiende>> Registro Factura <<Extiende>>

<<Include>> Conformar Facturas Validar Soporte Usuario del Sistema <<Extiende>>

Validar Usuario

Registrar Devolucin de Factura

Condicion = Soporte no valido/ Error en factura Punto de Extensin = Validar Soporte

Diagrama 32: Caso de uso Conformar Factura. Fuente: Autor 2010

Propsito Llevar un registro de las facturas que se conforman en el servicio mdico de la U.D.O

Resumen En ste caso de uso se describe el proceso para la conformacin y devolucin de facturas.

198

Centro de Computacin Seccin de Programas y Proyectos

Curso Normal (Bsico) Para el Registro de Factura El usuario selecciona la opcin El sistema muestra un formulario donde se Nueva factura en el men de 2 debe ingresar la cedula del Paciente. 1 facturas. El usuario ingresa la cedula del 4 paciente. 3 El usuario hace clic en la cedula 6 El sistema carga los datos del paciente y los correspondiente. muestra en la pantalla. 5 7 El sistema carga los tipos de registros. El usuario selecciona que el tipo de El sistema despliega los datos a llenar para 8 registro es por Medicamento. 8.1 factura por medicamento. El usuario selecciona el tipo 8.2 mdico que origino la compra. El usuario selecciona nombre del 8.3 mdico y su correspondiente especialidad. El sistema carga el numero de El sistema abre una ventana donde muestra rcipe que origino la compra. Si el 8.4. el rcipe para verificar la informacin. fue originado en 1 8.4 rcipe departamento de servicios mdicos el usuario hace clic en el botn Ver Rcipe. Si el rcipe fue originado por un medico 8.4. externo el sistema muestra un formulario 2 para cargar dichos datos. El usuario llena los campos de la El sistema carga todos los campos y realiza 8.5 fecha que se realizo la compra y su 8.6 el registro de factura por medicamento. costo. El usuario selecciona que el tipo de El sistema muestra los datos a llenar para factura a conformar por Atencin 9.1 factura por atencin mdica particular. 9 Medica Particular. El usuario introduce los datos El sistema carga todos los campos y realiza 9.2 correspondientes. 9.3 el registro de factura por atencin mdica particular. El sistema asigna los registros de facturas al 10 status facturas PROCESADO para ser conformadas. Tabla 31: Curso bsico de eventos para el registro de factura. Fuente: auto 2010 Cursos Alternos Para el Registro de Factura Solo se hace la validacin de rcipes mdicos que se conformen en un plazo no mayor a 6.4 30 das posteriores a su emisin. Si el sistema no la carga es porque ha caducado o no existe origen de factura. 6.6 Si surge algn error en la grabacin de un registro de factura el sistema lo informa y 7.3 regresa a la pantalla de captura de datos. Cuando se trate de un mdico particular el sistema muestra la opcin de ingresar su 7.2 nombre y cargar su especialidad. Tabla 32: Curso alterno de eventos para el registro de factura. Fuente: auto 2010

199

Centro de Computacin Seccin de Programas y Proyectos Curso Normal (Bsico) Para Devolucin de Factura 1 El usuario selecciona Status 2 de Factura del men principal en conformar factura. El usuario selecciona que tipo de factura (Por medicamento o 3 por atencin mdica especializada). El usuario conforma factura y presiona Conformar. El usuario selecciona la factura 6 a devolver. El sistema muestra la pantalla para que el usuario seleccin que tipo de status desee conformar o devolver. El sistema muestra el listado de las facturas registrada en espera para ambos tipo de factura.

4 5

El usuario ingresa exposicin 7 motivos y presiona Guardar. 8

El sistema arroja una pantalla donde le pide al usuario la exposicin de motivo por el cual se est devolviendo la factura. El sistema registra una devolucin de factura. El sistema cambia el estatus de factura de procesada a devuelta .

Tabla 33: Curso bsico de eventos para la devolucin de factura. Fuente: auto 2010
Comentarios
1

Permitir el registro y control de las facturas que han sido conformadas.

Usuario del Sistema

Usuario del Sistema

El usuario podr almacenar los datos relacionados a la conformacin de facturas Se muestre el formulario para el registro de facturas conformadas y para registrar devoluciones. Se almacenen todos los registros realizados. Se tenga informacin de las facturas que han sido conformadas por un determinado paciente. Se pueda visualizar el status de una determinada factura.

Cambiar el Status de una factura.

200

Centro de Computacin Seccin de Programas y Proyectos

Diagrama de Clases

TipoPaciente + + + + + + + + + + + + + + + + + + cd_pac tipo_pac sexo nomdres apellidos fec_nac ecivil correo cert edad cod_parent : : : : : : : : : : : int int String String String Date String String int int int

Mostar () VerificarTipoPaciente () BuscarTipoPaciente () ValidarUsuario () MostrarUsuario () BuscarPaciente () BuscarPacienteF ()

1..* Facturas + + + + + + + + Id Cedula TipoPaciente TipoMedico TipoDoctor Especilidad Ffactura estatus : : : : : : : : int String int int String int Date float 0..*

TipoDoctor + id : int + desripcion : String + + + + EstadoFactura 1 + id : int + nomdre : String + Modificar () + Mostrar () Nuevo () Modificar () Mostrar () Eliminar ()

+ MostrarRecipe () + Crear () + Buscar ()

FacturaMedicamento + + + + + + + + + + + + Id cedula tipodoctor tipopaciente fecha estatus medico especialidad valor serial observaciones nrecipe : : : : : : : : : : : : int String int int Date String String String String String String int

FacturaAtencionParticular + + + + + + + + + + Id cedula tipopaciente ffecha estatus medico especialidad valor serial observaciones : : : : : : : : : : int String int Date String String String String String String

+ Mostrar ()

+ Mostrar ()

Diagrama 33: Diagrama de clase. Conformar Factura. Fuente: Autor 2010

201

Centro de Computacin Seccin de Programas y Proyectos

Diagrama de Secuencia para el Registro de Factura
W:BuscarPaciente Usuario del Sistema Seleccionar " Nuevo Registro" Procesar CapturarSeleccion ( ) Ingresar cedula de identidad del paciente Activa Muestra pantalla de nuevo registro con los datos del paciente Cargar Paciente ( ) RegistroFacturas Doctores EspecialidadDoctor Especialidad Paciente Recipe

Seleccione tipo de Factura "Medicamento"

Procesa Mostar T ipo de Doctores CargaT ipoDoctores( )

Seleccione el tipo de medico que origino la compra

Procesa Mostar nombre de doctores CargaNombres ( )

Seleccione nomdre del doctor

Procesar Mostrar Especilidad Cargar Especialidad ( )

Ingresar numero de recipe

Procesar Mostrar recipe Cargar Recipe ( )

Por "Medicamentos" Ingresar datos de la factura

Presionar " Guardar"

Procesar ValidarPaciente ( )

Procesa CargaDatos( )

BuscarRecipe ( )

Mostrar mensaje de factura procesada

GuardarRegistro ( )

Seleccion tipo de factura "Atencion Medica Particular" Seleccion tipo de factura "Atencion Medica Particular"

Procesar Mostar Nombre FiltrarT ipo ( )

Ingrese nombre del Doctor

Procesar Mostrar Nombres CargarEspecialidad ( )

Ingresar serial de Factura Por "Atencin Medica Particular" Ingresar Fecha factura

Ingresar costo de factura Precionar" Guardar" Procesar Activa ValidarPaciente ( )

GuardarRegistro ( ) Mostrar mensaje de notificacin GuardarStatus ( )

Diagrama 34: Diagrama de secuencia registro de factura. Fuente: Autor 2010

202

Centro de Computacin Seccin de Programas y Proyectos

Pantallas de Registro de Factura

Pantalla 1/4. Seleccin de Nueva Factura

Pantalla 2/4. Seleccin de Factura Medicamento P

203

Centro de Computacin Seccin de Programas y Proyectos

Pantallas de Registro de Factura

Pantalla 3/4. Seleccin de Factura Atencin Mdica Particular P

Pantalla 4/4. Factura Registrada

204

Centro de Computacin Seccin de Programas y Proyectos

Diagrama de Secuencia para la Devolucin de Factura

W:Facturas Usuari o del Si stema Sel ecci onar "Devol uci n de Factura" Facturas Paci ente

Procesar Mostrar Pantal l a de Devol uci on de Facutura CapturarSel ecci on ( )

Regi strar Devol uci n de Factura

Ingresar cedul a de i denti dad del paci ente

Procesar Mostrar paci ente CargarPaci ente ( )

Sel ecci onar facturas "Conformadas por Medi camento"

Procesar Cargar Sel ecci on ( ) Mostar Sel ecci on

Sel eci onar Factura

Procesar Mostar Formul ari o Cargar Formul ari o

Regi strar Devol uci n de Factura Por Medi camento

Ingresar observaci ones Presi onar "Aceptarr" Procesar Val i dar Regi stro ( ) Noti fi ca que l os Resul tados han si do Guardados Asi gnarStatus ( )

Sel eci onar Facturas Por "Atenci on Mdi ca Parti cul ar"

Procesar Mostar Sel ecci on Cargar Sel ecci on ( )

Sel eci onar Factura

Regi strar Devol uci n de Factura Por Atenci on Mdi ca Parti cul ar

Pul sar "Aceptar"

Procesar Val i dar Regi stro ( )

Noti fi car que l os Resul tados han si do Guardados

Asi gnar Stats ( )

Diagrama 35: Diagrama de secuencia devolucin de factura. Fuente: Autor 2010.

205

Centro de Computacin Seccin de Programas y Proyectos

Pantallas de Devolucin de Factura

Pantalla 1/4. Seleccin de Status Factura

Pantalla 2/4. Conformar Factura

206

Centro de Computacin Seccin de Programas y Proyectos

Pantallas de Devolucin de Factura

Pantalla 3/4. Conformar Factura

Pantalla 3/4. Devolucin de Factura

207

Centro de Computacin Seccin de Programas y Proyectos Caso de Uso Autor Consultar Factura CU-010 Lolimar Cedeo M. Fecha 14-6-10 Versin 0.91 1. Aux. Registro y Estadstica Actores 2. Jefe del departamento. Primario- Esencial Tipo Documento Definicin de Requisitos Referencias 1. Que el usuario se haya validado correctamente en el sistema. 2. Que el usuario haya seleccionado la opcin Consultar Factura Pre -condicin dentro de Factura en el men principal. 3. Que el usuario tenga un registro de factura Pos -condicin Que el usuario haya consultado sus facturas conformadas o devueltas.
Diagrama de Caso de Uso

Validar Usuario

<<Include>> Facturas Procesando <<Include>>

Consultar Facturas Usuario del Sistema

Registro de Facturas Facturas Conformadas

Facturas Devueltas

Diagrama 36: Diagrama. Caso de uso Consultar Factura. Fuente: Autor 2010

Propsito Permitir al usuario consultar las facturas y su respectivo status. Resumen En ste caso de uso se describe el proceso para consultar el status de una facturas conformada o devueltas

208

Centro de Computacin Seccin de Programas y Proyectos Curso Normal (Bsico) consultar Factura El usuario selecciona del men 1 principal Factura la opcin 2 Consultar Factura. El usuario introduce la cedula a 3 consultar. El usuario hace clic en la 4 cedula correspondiente. 5

El sistema muestra un formulario para el ingreso de la cedula del paciente a consultar.

El sistema carga los datos del paciente en la pantalla consultar facturas y muestra las opciones de factura a consultar. El usuario selecciona la opcin El sistema despliega en pantalla las de factura por 6.1 facturas del paciente por medicamentos y el status de ellas. Medicamentos. El usuario selecciona la opcin El sistema despliega en pantalla las factura por Atencin Mdica 7.1 facturas del paciente por medicamentos y el status de ellas. Particular. El usuario presiona atrs. 9 El sistema regresa a la pantalla principal de consultar facturas.

Tabla 34: Curso bsico de eventos para la consulta de factura. Fuente: auto 2010

Cursos Alternos Para consulta de Factura 6.1 Si no se encuentra ninguna factura asociada al paciente, el sistema lo informa en 7.1 un mensaje de alerta indicando.
Tabla 35: Curso alterno de eventos para la consulta de factura. Fuente: auto 2010
Comentarios
1

Se puede consultar cual es el status de una factura, para un determinado paciente.

Usuario del Sistema

209

Centro de Computacin Seccin de Programas y Proyectos

Diagrama de Secuencia para el consulta de Factura
W:Facturas Usuario del Sistema Seleciona"Consultar Factura" Procesar Mostrar pantalla para realizar busqueda Ingresar cedula de identidad del paciente Presionar "Buscar" Procesar cedula de identidad Mostrar Paciente CargaPaciente( ) CapturaSeleccion ( ) Facturas Paciente

Por "Atencion Seleccionar factura por "Atencion Medica Particular" Medica Particular"

Procesar Mostar factura CargafacturadeAtencion Medica Particular( )

Seleccionar factura por "Medicamento" Por "Medicamento"

Procesa Muestra Factura CargafacturadeMedicamento( )

Diagrama 37: Diagrama. Secuencia Consultar Factura. Fuente: Autor 2010.

210

Centro de Computacin Seccin de Programas y Proyectos

Pantallas de Consultar Factura

Pantalla 1/3. Seleccin Consultar Factura P

Pantalla 2/3. Consultar Factura Por Medicamentos P

211

Centro de Computacin Seccin de Programas y Proyectos Caso de Uso Autor Control de Medicamento Lolimar Cedeo M. Fecha 14-6-10 Versin 0.91 Doctor Actores Enfermeras Primario- Esencial Tipo Documento Definicin de Requisitos Referencias 1.Que el usuario se haya validado correctamente sistema. Pre -condicin 2.Que el usuario haya seleccionado del men Medicamentos y seleccione de su la lista desplegable. Se realizo mantenimiento de medicamentos. Pos -condicin Se registro la salida de un medicamento
Diagrama de Caso de Uso Control de Medicamento

CU-011

principal

Realizar Mantenimiento de Medicamento

Condicion =Actualizar medicamento Punto de Extension = Verificar tipo de control << Extiende>> Validar Usuario Controlar Medicamentos Verificar tipo de control Usuario del Sistema << Include>>

<< Extiende>> Registrar Salida Eventual Condicion = Suministrar medicamento Punto de Extension = Verificar tipo de control

Registrar Salida Verificar tipo de salida Registrar Salida por Recipe

Diagrama 38: Diagrama. Caso de uso Control de medicamento. Fuente: Autor 2010
Propsito Llevar un registro de los medicamentos con los que cuenta el servicio mdico.

Resumen En ste caso de uso se describe el proceso para el control de la salida de algn medicamento de farmacia.

212

Centro de Computacin Seccin de Programas y Proyectos Curso Normal (Bsico) Para el Mantenimiento de Medicamento El usuario selecciona la opcin 2 El sistema muestra pantalla de 1 Mantenimiento de mantenimiento de medicinas. Medicinas men principal de Medicamento El usuario ingresa el nombre del 3 medicamento que desea consultar El usuario presiona el botn 5 El sistema realiza bsqueda del 4 Buscar. medicamento El sistema muestra resultado de la 5 6 bsqueda con opciones de actualizacin Agregar Medicamento 7 7.1 El sistema muestra pantalla para Ingreso El usuario marca la opcin de Medicamento Nuevo. Agregar Medicamento. 7.2 El usuario llena campos y 7.3 El sistema enva un mensaje para indicar presiona que ha sido ingresado un nuevo Aceptar medicamento. Modificar Medicamento 8 8.1 El sistema muestra pantalla con El usuario marca la opcin formulario para ingresar medicamento existente. Modificar Medicamento. 8.2 El usuario ingresa cantidad. 8.3 El usuario ingresa fecha de vencimiento del medicamento 8.4 El usuario presiona el botn Aceptar. Eliminar Medicamento 9 9.1 El sistema elimina medicamento y enva El usuario marca la opcin mensaje de notificacin. Eliminar Medicamento. 9.2 El sistema devuelve a la pantalla inicial.
Tabla 36: Curso bsico de eventos mantenimiento de medicamento. Fuente: auto 2010
Cursos Alternos Para el Mantenimiento de Medicamento

Si se buscar un medicamento y no existe. Se debe seleccionar la opcin Ingresar medicamento nuevo y presionar el botn aceptar. Seguidamente el sistema mostrara el formulario para ingresar la informacin correspondiente al medicamento (Nombre, presentacin, cantidad y fecha de vencimiento). Una vez llenado el formulario, el usuario debe presionar el botn aceptar y se actualiza el medicamento.

Tabla 37: Curso alterno de eventos mantenimiento de medicamento. Fuente: auto 2010

213

Centro de Computacin Seccin de Programas y Proyectos

Curso Normal (Bsico) Para la Salida de Medicamento El usuario selecciona la opcin El sistema muestra un formulario donde se REGISTRAR SALIDA 1 debe ingresar la cedula del Paciente. 1 EVENTUAL del men principal de Medicamentos El usuario hace clic en la cedula 2.1 El sistema muestra pantalla de salida 2 correspondiente. eventual de medicamento con los datos del paciente. El usuario ingresa el nombre del El sistema carga la lista con los nombres de 2.2 medicamento a consultar. 2.3 los medicamentos existente con el nombre que usuario ingreso. El usuario selecciona el El sistema carga y muestra una pantalla con 2.4 medicamento y presiona el botn 2.5 el medicamento a despachar para que el Aceptar usuario seleccione cantidad y motivo de despacho. El usuario selecciona cantidad , El sistema carga seleccin y notifica la motivo de despacho y presiona el 2.7 salida del medicamento. 2.6 botn Aceptar El usuario hace clic en el botn El sistema muestra un formulario donde se REGISTRAR SALIDA 3.1 debe ingresar la cedula del Paciente. 3 RCIPE 3.2 El usuario hace clic en la cedula 3.3 El sistema carga los datos del paciente y correspondiente. muestra los registros de rcipes asociados al paciente. El usuario selecciona el rcipe a El sistema muestra el rcipe para dar 3.4 despachar VER RECIPE 3.5 constancia que la informacin sea correcta. El usuario presiona el botn El sistema registra salida por rcipe notifica Aceptar 3.6 3.7 y lo notifica. Tabla 38: Curso bsico de eventos para la salida de medicamento. Fuente: auto 2010 Cursos Alternos Para Salida de Medicamento Si la cedula de identidad del paciente no es vlida, el sistema emite un aviso y permite 2.3 ingresar nuevamente la cedula de identidad. si no se encuentra el medicamento, el sistema lo indica como registro cero(0)y permite 2.5 realizar una nueva bsqueda El sistema muestra la cantidad de medicamento que existe para un medicamento, si el 2.6 usuario quiere exceder el lmite de este, el sistema indicara que no se puede modificar y no lo registrara. Si el usuario quiere registrar la salida de ms de un medicamento el sistema le muestra la 2.7 opcin de AGREGAR OTRO MEDICAMENTO. Tabla 39: Curso alterno de eventos para la salida de medicamento. Fuente: auto 2010
Comentarios
1

Con este proceso se puede mantener un control de los medicamentos que se despachan y a que paciente se lo suministran.

Usuario del Sistema

214

Centro de Computacin Seccin de Programas y Proyectos

Diagrama de Clases

Medicamento + + + + + num nombre presentacion cant fecha_v : int : String : String : int : Date + + + +

SalidaMedicamento 1 id cedula medicamento fecha : int : String : int : Date

+ Crear () + Modificar () + Eliminar () MotivoDespacho + id : int + nomdre : String + Crear () + Modificar () + Eliminar () : int : String : Date : String : String : int

+ crear ()

1..*

1..*

Recipe + + + + + + numero indicaciones fecha paciente estatus doctor

+ MostrarRecipe () + MostrarRecipes () + Eliminar ()

Diagrama 39: Diagrama de clase Control de Medicamento. Fuente: Autor 2010

215

Centro de Computacin Seccin de Programas y Proyectos

Diagrama de Secuencia para el Mantenimiento de Medicamento
W:Farm aci a Usuari o del Si stem a M edi cam entos

Sel ecci onar "M anteni m i ento de M edi cam entos"

Procesar M ostrar pantal l a para el m anteni m i ento de m edi cam entos CapturarSel ecci on ( )

Buscar M edi cam ento Ingresar Nom bre del M edi cam ento

Presi onar "Buscar"

Procesar Busqueda M ostrar resul tados BuscarM edi cam ento ( )

M arcar l a opci on " Agregar Nuevo M edi cam ento" Presi onar "Aceptar" Procesar M ostrar form ul ari o para i ngresar m edi cam ento exi stente Agregar nuevo m edi cam ento Ingresar Canti dad Ingresar Fecha de Venci m i ento Presi onar "Guardar" Procesa M uestra m ensaj e en pantal l a de M edi cam ento Agregado GuardarNuevoM edi cam ento( ) CapturarSel ecci on ( )

M arcar l a opci on "El i m i nar" El i m i nar M edi cam ento

Procesar M ostrar pantal l a pri nci pal de control de m edi cam entos El i m i naM edi cam ento( )

Presi onar el boton "M odi fi carr"

Procesar M ostrar pantal l a para m odi fi car m edi cam entos CargaDatosDeM edi cam ento( )

M odi fi car

Ingresa Canti dad Ingresa Fecha de venci m i ento Presi onar "Aceptar" Procesa M ostrar pantal l a pri nci pal de control de m edi cam entos GuardaM odi fi caci on( )

Diagrama 40: Diagrama. Secuencia de mantenimiento de medicamento. Fuente: Autor 2010

216

Centro de Computacin Seccin de Programas y Proyectos

Pantallas de Mantenimiento de Medicamento

Pantalla 1/4. Seleccin mantenimiento de Medicamento

Pantalla 2/4. Bsqueda de Medicamento

217

Centro de Computacin Seccin de Programas y Proyectos

Pantallas de Mantenimiento de Medicamento

Pantalla 3/4. Ingresar Medicamento Nuevo

Pantalla 4/4.Modificar Medicamento Existente

218

Centro de Computacin Seccin de Programas y Proyectos

Diagrama de Secuencia para la salida de Medicamento

W:Medicamentos Usuario del Sistema Seleccionar "Registrar Salida Eventual" Procesar Mostrar pantalla para realizar busqueda Registrar Salida Eventual

Medicamento

Paciente

Recipe

CapturarSeleccion ( )

Ingresar cedula de identidad del paciente

Procesar CargarPaciente ( ) Mostrar datos de paciente en la pantalla de " salida eventual"

Ingresar nomdre del medicamento

Procesar Muestra pantalla con seleccion de medicamento CargarMedicamento ( )

Pulsar " Aceptar"

Procesar Mostra pantalla " REGISTRO DE SALIDA" CargaSalidaDeMedicamento( )

Seleccionar "Registrar Salida Por Recipe"

Procesar Mostrar pantalla para realizar busqueda CargarSeleccion ( )

Registrar salida por recipe

Ingresar cedula de identidad del paciente

Procesar CargarDatosdePaciente ( ) Procesa Mostrar Recipes del Paciente CargaRrecipedelPaciente ( )

Seleccionar Recipe

Procesar Muestra Recipe lleno CargarMedicamentosdeRecipe ( ) Procesar Mostar pantalla "salida por Recipe" ValidarRegistro ( )

Presionar "Aceptar"

Diagrama 41: Diagrama. Secuencia salida de medicamento. Fuente: Autor 2010

219

Centro de Computacin Seccin de Programas y Proyectos

Pantallas de Salida de Medicamento

Pantalla 1/6.Registar Salida

eventual de Medicamento

Rcipe

Pantalla 2/6.Buscar Medicamento

220

Centro de Computacin Seccin de Programas y Proyectos

Pantallas de Salida de Medicamento

Pantalla 3/6.Agregar Medicamento de Farmacia

Pantalla 4/6.Registar Salida de Medicamento Por Rcipe

221

Centro de Computacin Seccin de Programas y Proyectos

Pantallas de Salida de Medicamento

Pantalla 5/6.Despachar Medicamentos de Rcipe

Pantalla 6/6.Verificar Medicamentos Rcipe

222

Centro de Computacin Seccin de Programas y Proyectos Caso de Uso Autor Generar Reportes CU-012

Lolimar Cedeo M. Fecha 7-12-09 Versin 0.91 Jefe del departamento. Actores Aux. Registro y Estadstica Primario- Esencial Tipo Documento Definicin de Requisitos Referencias 1. Que el usuario se haya validado correctamente. Pre -condicin 2. Que el usuario haya seleccionado EL REPORTE que desea en el men GENERAR REPORTE. Pos -condicin 1. Generar un reporte de acuerdo a la seleccin del usuario.
Diagrama de Caso de Uso

Validar Usuario

<<Include>>

Generar Reporte

Usuario del Sistema

Diagrama 42: Diagrama. Caso de uso generar reporte. Fuente: Autor 2010
Propsito

Generar reportes a los usuarios. Estos reportes mostraran el resumen de un determinado proceso en un intervalo de fechas definido por el usuario.

Resumen

En ste caso de uso se describe el proceso para generar un reporte.

223

Centro de Computacin Seccin de Programas y Proyectos Curso Normal (Bsico) El caso de uso comienza cuando 1 el usuario selecciona la opcin Generar Reportes

El sistema captura la seleccin 2 3 El sistema muestra pantalla para seleccionar el tipo de reporte. El sistema despliega tabla con el criterio de bsqueda.

El sistema efecta la bsqueda de acuerdo 7 8 a lo seleccionado. 9 El sistema muestra el registro. Presionar el botn Imprimir El sistema imprime reporte 10 Reporte 11
Tabla 40: Curso bsico de eventos generar reporte. Fuente: auto 2010

El usuario selecciona el tipo de reporte. (Facturas Conformadas, Citas, Rcipes, Emitidos Boletas, Emitidas Registro de Salida de Medicamento.) El usuario seleccionar el criterio bajo el cual efectuar la bsqueda El usuario presiona el botn Generar Reporte.

Cursos Alternos Si el sistema efecta la bsqueda de acuerdo a lo seleccionado y no se encuentra 8 ningn registro asociado a la bsqueda, el sistema lo informa y permite realizar una nueva bsqueda. Si solo se desea visualizar el registro sin imprimirlo, el usuario puede presionar el 9 botn Retornar.
Tabla 41: Curso alterno de eventos generar reporte. Fuente: auto 2010

Comentarios
1

Usuario del Sistema

Este caso de uso permite brindarles a los usuarios el acceso a los reportes que genera el sistema, presentndoles informacin relevante sobre su gestin.

224

Centro de Computacin Seccin de Programas y Proyectos

Diagrama de Secuencia
W: Reportes Usuari o del Si stem a Bol eta Doctores Reci pe Facturas M edi cam ento Ci tas Im presora

Sel ecci onar reporte de bol eta m edi ca M uestra sel ecci on Reporte de bol etas m edi cas em i ti das Sel ecci onar servi ci o M arcar "Asoci ar Paci ente" Ingresar cedul a de Identi dad del paci ente Sel ecci onar fecha y presi onar el boton "Generar Reporte" Procesar EfectuarBusqueda ( ) M ostrar resul tado de bol etas segun cri teri o de busqueda

Sel ecci onar reporte de reci pe m edi co M uestra sel ecci on M arcar "Asoci ar Doctor" Reporte de Reci pes Em i ti dos M arcar "Asoci ar al Paci ente" Sel ecci onar fecha y presi onar "Generar Reporte" Procesar M ostrar resul tado de reci pes EfectuarBusqueda ( ) Procesar M ostrar nom bres de doctores CargarNom bres ( )

Sel ecci onar reporte de facturas conform adas M ostrarSel ecci on ( ) Ingresar cedul a de Identi dad del paci ente Reporte de facturas conform adas Sel ecci ona ti po de Factura Procesa Acti va ti po de factura Presi onar el boton "Generar Reporte" Procesar M ostrar resul tado de facturas conform adas EfectuarBusqueda ( ) CargaT i podeFactura( )

Sel ecci onar reporte de m edi cam entos sum i ni ni strados M ostrarSel ecci on ( ) Ingresar cedul a de Identi dad del paci ente Reporte Sal i da de m edi cam entos Ingresar nom bre del M edi cam ento El egi r cri teri o de busqueda Presi onar el boton "Generar Reporte" Acti var M ostrar resul tado de m edi cam entos sum i ni strados Sel ecci onar reporte de ci tas M ostrarSel ecci on ( ) Reporte de Ci tas Sel ecci onar ti po de ci ta M arcar "Asoci ar Doctor" Sel ecci onar Doctor Sel ecci onar fecha y presi onar "Generar Reporte" Procesar M ostrar resul tado de Ci tas EfectuarBusqueda ( ) Procesar M ostrar nom bres de doctores CargarNom bres( ) EfectuarBusqueda( )

Procesar Im presi on Im pri m i r reporte Presi onar "Im pri m i r Reporte"

Diagrama 43: Diagrama. Secuencia generar reporte. Fuente: Autor 200.

225

Centro de Computacin Seccin de Programas y Proyectos

PANTALLAS

Pantalla 2/6. Selecciona Tipo de Reporte

Pantalla 1/6. Selecciona Generar

226

Centro de Computacin Seccin de Programas y Proyectos

PANTALLAS

Pantalla 4/4. Reporte de Medicamentos Suministrados

Pantalla 3/4. Seleccionar Criterios de Bsqueda

227

Centro de Computacin Seccin de Programas y Proyectos 32. Requisitos Suplementarios (No funcionales) En esta parte se desarrollan las mtricas de calidad ya antes definidas en el documento de definicin de requisitos no funcionales para el sistema, estas mtricas proporcionan una indicacin de cmo se ajusta el software a los requisitos implcitos y explcitos definidos por el cliente. A continuacin se mide:

1.ADECUIDAD

Establecemos esta mtrica al sistema para medir cualitativamente la capacidad del producto software para proporcionar un conjunto apropiado de funciones para tareas y objetivos de usuario especificados.

Nombre: Completitud de implementacin Propsito: Qu tan completa est la implementacin funcional. funcional Mtodo de aplicacin: Contar las funciones faltantes detectadas en la evaluacin y comparar con el nmero de funciones descritas en la especificacin de requisitos. Con versin 1.0 del documento DER (Documento Especificacin de Requisitos) se obtuvo el siguiente resultado: Se concretaron todos los procesos definidos por 11 casos de uso. No existe funcin faltante de ms de 70 exigidas y recolectada por requisitos funcionales y no funcionales. Medicin frmula: Solucin: Interpretacin: X = 1 - A/B X = 1 - A/B 0 <= X <= 1 A = nmero de funciones faltantes X = 1 - 0/70 Entre ms cercano a 1, ms completa. B = nmero de funciones descritas en la especificacin X=1 de requisitos Fuente de Medicin: Audiencia: La validacin fue dada por el Gestor de configuracin Desarrolladores del centro de computacin de la universidad de Software, Analista de sistemas, Arquitecto de de oriente ncleo Monagas. software y la revisin conjunta del Responsable Generar del Proyecto.

Tabla 42: tabla de mtrica Adecuidad ISO 9126. Fuente: auto 2010
2.MADUREZ Establecemos esta mtrica al sistema para medir cualitativamente la capacidad del producto software para proporcionar un conjunto apropiado de funciones para tareas y objetivos de usuario especificados.

Nombre: Suficiencia de las pruebas

Propsito: Cuntos de los casos de prueba necesarios estn cubiertos por el plan de pruebas. Mtodo de aplicacin: Desde el desarrollo del software hasta la implantacin fue cubierta por todas las pruebas necesarias o exigidas por del mtodo WATCH donde se aplica el Plan de verificacin y Validacin correspondientes a las pruebas de procesos. A todos los procesos se le realizaron pruebas. Solo 1 caso de uso ms 2 mantenimientos del sistema se tomaron como ejemplo para el plan de pruebas Medicin frmula: Solucin: Interpretacin: X = A/B X = A/B 0 <= X A = nmero de casos de prueba en el plan X = 3/2 Entre X se mayor, mejor la suficiencia. B = nmero de casos de prueba requeridos X = 1,5 Fuente de Medicin: Audiencia: La validacin fue dada por el Gestor de configuracin Desarrolladores del centro de computacin de la universidad de Software, Analista de sistemas, Arquitecto de de oriente ncleo Monagas. software y la revisin conjunta del Responsable Generar del Proyecto.

Tabla 43: tabla de mtrica Madurez ISO 9126. Fuente: auto 2010

228

Centro de Computacin Seccin de Programas y Proyectos

3.ENTENDIBILIDAD Capacidad que tiene el producto de software que le permita al usuario entender si el software es adecuado y como puede ser usado para una tarea o condicin de uso particular. Propsito: Qu proporcin de las funciones del sistema son evidentes al usuario.

Nombre: Funciones evidentes

Mtodo de aplicacin: Contar las funciones evidentes al usuario y comparar con el nmero total de funciones. Las funciones de la aplicacin fueron propuestas por el usuario. Se cuentan con 11 funciones de procesos de sistemas, 4 mantenimiento y 1 anlisis estadsticos de datos. Medicin frmula: Solucin: Interpretacin: X = A/B X = A/B 0 <= X <= 1 A = nmero de funciones (o tipos de funciones) evidentes al X = 11/15 Entre ms cercano a 1, usuario X = 0,733333 mejor. B = total de funciones (o tipos de funciones) Fuente de Medicin: Audiencia: La validacin fue dada por el Gestor de configuracin de Desarrolladores del centro de computacin de la Software, Analista de sistemas, Arquitecto de software y la universidad de oriente ncleo Monagas. revisin conjunta del Responsable Generar del Proyecto.

Tabla 44: tabla de mtrica Entendibilidad ISO 9126. Fuente: auto 2010
Capacidad del producto de software para proporcionar tiempo de respuesta, tiempo de procesos y potencia, bajo condiciones determinadas Propsito: Cul es el tiempo estimado para completar una tarea. llamadas al SO y a la aplicacin.

4. COMPORTAMIENTO EN EL TIEMPO Nombre: Tiempo de respuesta

Mtodo de aplicacin: Evaluar la eficiencia de las Estimar el tiempo de respuesta basado en ello. Puede medirse:

Todo o partes de las especificaciones de diseo. Producto completo durante la fase de pruebas. Solo a 1 proceso se le medir el tiempo de respuesta. PROGRAMAR CITA MEDICA. Medicin frmula: Solucin: Interpretacin: X = tiempo (calculado o simulado) X = 1 seg. Entre ms corto, mejor. Fuente de Medicin: La validacin fue dada por el Gestor de configuracin de Software, Analista de sistemas, Arquitecto de software y la revisin conjunta del Responsable Generar del Proyecto. Audiencia: Desarrolladores del centro de computacin de la universidad de oriente ncleo Monagas.

Tabla 45: tabla de mtrica ISO 9126. Comportamiento en el tiempo Fuente: auto 2010

229

Centro de Computacin Seccin de Programas y Proyectos

5. CAMBIABILIDAD Capacidad del producto de software que permite que una determinada modificacin sea implementada.

Nombre: Registrabilidad de cambios

Propsito: Se registran adecuadamente los cambios a la especificacin y a los mdulos con comentarios en el cdigo?

Mtodo de aplicacin: Registrar la proporcin de informacin sobre cambios a los mdulos: En el men administrador del sistema: a los mdulos se le puede asignar procesos. El cdigo esta comentado para facilitar cambio. Existen 6 mdulos en el sistema. Medicin frmula: Solucin: Interpretacin: X = A/B X = 6/6 0 <= X <= 1 A = nmero de cambios a funciones o mdulos que tienen X=1 Entre ms cercano a 1, ms comentarios confirmados registrable. B = total de funciones o mdulos modificados. 0 indica un control de cambios deficiente o pocos cambios y alta estabilidad. Fuente de Medicin: Audiencia: La validacin fue dada por el Gestor de configuracin de Desarrolladores del centro de computacin de la Software, Analista de sistemas, Arquitecto de software y la universidad de oriente ncleo Monagas. revisin conjunta del Responsable Generar del Proyecto.

Tabla 45: tabla de mtrica C ISO 9126. Cambiabilidad .

6. CONFORMIDAD DE LA TRANSPORTABILIDAD

Capacidad del producto software para adherirse a normas o convenciones relacionadas con la portabilidad
Propsito: Qu tan conforme es la transportabilidad del producto con regulaciones, estndares y convenciones aplicables.

Nombre: Conformidad de transportabilidad

Mtodo de aplicacin: Contar los artculos encontrados que requieren conformidad y comparar con el nmero de artculos en la especificacin que requieren conformidad. La aplicacin fue diseada para el rea de servicios mdicos de la universidad de oriente ncleo Monagas. Su transportabilidad implicara un cambio radical en sus procesos ya que se diseo bajo reglas y polticas del rea que brinda el servicio. Medicin frmula: Solucin: Interpretacin: X = A/B X=0 0 <= X <= 1 A = nmero de artculos implementados de conformidad Entre ms cercano a 1, ms B = total de artculos que requieren conformidad completa. Fuente de Medicin: Audiencia: La validacin fue dada por el Gestor de configuracin de Desarrolladores del centro de computacin de la Software, Analista de sistemas, Arquitecto de software y la universidad de oriente ncleo Monagas. revisin conjunta del Responsable Generar del Proyecto.

Tabla 46: tabla de mtrica C ISO 9126. Conformidad de la Transportabilidad

230

UNUVERSISDAD DE ORIENTE NUCLEO MONAGASCE CENNTRO DE COMPUTACION TODOS LOS DERECHOS RESERVADO

5.3 ETAPA III

PROCESO DE CONSTRUCCIN, GESTIN Y SOPORTE

Centro de Computacin Seccin de Programas y Proyectos Implementacin de un sistema automatizado que optimice la gestin de los procesos administrativos del rea servicios mdicos de la universidad de oriente ncleo Monagas DOCUMENTO DISEO ARQUITECTNICO Y DETALLADO Versin 1.0 Autor Fecha Lolimar Cedeo 28-11-09 1. 1. Introduccion 1. Introduccin El Diseo Arquitectnico produce la estructura de la aplicacin representada como una arquitectura de software que muestra los componentes de la aplicacin, sus conectores y las restricciones arquitectnicas. El Diseo Detallado describe cmo se debe implementar cada uno de estos componentes arquitectnicos. Este documento contiene las especificaciones de diseo arquitectnico y detallado de del sistema para asegurarse que cumplir con todos los requisitos acordados y satisface las necesidades del cliente para poner en produccin la aplicacin. Versin Descripcin 1.0 Versin preliminar

2. 2. Diseo Arquitectnico El producto a desarrollar est definido bajo la siguiente arquitectura:

Figura 33: Arquitectura del sistema. Fuente: autor 2010.

232

Centro de Computacin Seccin de Programas y Proyectos 2.1 Modelo de Vista de Funcionalidad A continuacin se describen las funcionalidades del sistema mediante el caso de uso general del sistema, resultante al proceso estudiado anteriormente modelado del negocio y especificacin de requisitos de software

2.2 Modelo. Vista de Estructural Representa los elementos de diseo ms importantes para la arquitectura del sistema, ya que soporta los requerimientos funcionales del sistema, presenta las clases significativas desde el punto de vista de la arquitectura y describe sus responsabilidades, as como algunas relaciones, operaciones y atributos de gran importancia. Se encuentra representado por el modelo de clases y por las tarjetas CRC. 2.2.1 Modelo de Clases Un diagrama de clases es un tipo de diagrama esttico que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Estos diagramas son el pilar bsico del modelado con UML, siendo utilizados tanto para mostrar lo que el sistema puede hacer, como para mostrar cmo puede ser construido. A continuacin se puede visualizar el modelo de clases del sistema:

Modelo de Clases de Usuarios

PaguinasModulos Usuario + + + + + + + + + + + + + nombre apellido cedula usuario nivel clave cod_usu direcion email cod_sta telefono : : : : : : : : : : : String String int String int String int String String int String Modulos ModulosUsuarios - cod_usu : int - cod_mod : int - id : int 1..* - eliminar () + ingresar () - cod_mod : int - descripcion : String 1..* + + + Eliminar () Insertar () Actualizar () Editar () 1..* + + + cod_pag descripcion url cod_mod cod_tipo Eliminar () Insertar () Actualizar () Editar () : : : : : int int int int int 1..* PaguinasUsuario - cod_usu : int - cod_pag : int - id : int - Eliminar () + Insertar ()

NivelDeAcceso 1 + nivel : int + descripcion : String - eliminar () + ingresar ()

Validar () Insertar () Eliminar () Mostar () Actulizar ()

Diagrama 44: Diagrama de clase usuario. Fuente: Autor 2010

233

Centro de Computacin Seccin de Programas y Proyectos Modelo de Clases de Procesos

Diagrama 45: Diagrama de clase de procesos. Fuente: Autor 2010

2.2.2 Tarjetas CRC Las tarjetas CRC son muy tiles para observar la relacin entre cada una de las clases que conforman el modelo de clases y las responsabilidades de cada una de ellas.Como una extensin informal a UML, la tcnica de las tarjetas CRC se puede usar para guiar el sistema a travs de anlisis guiados por la responsabilidad. Esta tcnica define las responsabilidades y colaboraciones de cada clase a travs de todos los escenarios. Las clases se examinan, se filtran y se refinan en base a sus responsabilidades con respecto al sistema, y las clases con las que necesitan colaborar para completar sus responsabilidades. A continuacin se muestran las tarjetas CRC de las clases principales del modelo de Clases:

234

Centro de Computacin Seccin de Programas y Proyectos Nombre de la Clase Citas Responsabilidades Crear la cita de pacientes Almacenar la cita de pacientes Consultar la cita de pacientes Programar la cita con un doctor en una especialidad y en un horario Identificar la cita con un status

Clases Colaboradoras Doctor Especialidad Paciente

Figura 34: Tarjeta CRC Citas. Fuente: Autor (2010).

Nombre de la Clase Paciente Responsabilidades Validar paciente Cargar datos generales de los pacientes.

Clases Colaboradoras Parentesco TipoPaciente CargaFamiliar

Figura 35: Tarjeta CRC Paciente. Fuente: Autor (2010).

Nombre de la Clase Medicamento Responsabilidades Almacenar registro Consultar Mostrar motivo de despacho Buscar rcipe medico

Clases Colaboradoras Paciente SalidaMedicamento MotivoDespacho Recipe

Figura 36: Tarjeta CRC Medicamento. Fuente: Autor (2010).

Nombre de la Clase Historia Responsabilidades Crear y almacenar un tipo de historia Consultar historia medica Almacenar consultas medicas Mostrar datos generales del paciente

Clases Colaboradoras Paciente DpGeneraloInterna HGeneraroInterna

Figura 37: Tarjeta CRC Historia. Fuente: Autor ( 2010).

235

Centro de Computacin Seccin de Programas y Proyectos Nombre de la Clase Facturas Responsabilidades Crear registro de factura Consultar registro de factura Identificar el status de la factura Identificar doctor y especialidad Cargar doctores Buscar rcipe medico

Clases Colaboradoras Paciente FacturaAtencionEspecilizada FacturaMedicamento EstadoFactura TipoDoctor

Figura 38: Tarjeta CRC Facturas. Fuente: Autor (2010).

Nombre de la Clase Boletas Responsabilidades Crear y almacenar boleta medica Consultar boleta medica Cargar doctores externos Cargar laboratorios Cargar servicios Procesar impresin de boleta Crear historial de boletas Nombre de la Clase Recipe Responsabilidades Crear y almacenar rcipe medico Consultar rcipe medico Cargar medicamentos Procesar impresin de rcipe Identificar status del rcipe Nombre de la Clase DpHistoria Responsabilidades Cargar tipo de historia

Clases Colaboradoras BoletaPaciente Doctores Especilidad Laboratorios

Figura 39: Tarjeta CRC Boleta. Fuente: Autor (2010).

Clases Colaboradoras Paciente DetallesRecipe

Figura 40: Tarjeta CRC Rcipe. Fuente: Autor (2008).

Clases Colaboradoras DpGeneralInterna DpOdontologica DpGinecologiaObstetricia DpPediatria

Figura 41: Tarjeta CRC DPHistoria. Fuente: Autor (2008).

236

Centro de Computacin Seccin de Programas y Proyectos 1.3. Modelo Vista de Despliegue Es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes. Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones. El protocolo de comunicacin utilizado para relacionar los distintos nodos fue el protocolo de seguridad HTTPS (Hypertext Transfer Protocol Secure), el cual utiliza un cifrado basado en el SSL (Secure Socket Layers), creando un canal para enviar/recibir informacin.

Usuarios del Servicio Medico

<HTTPS>

EXPLORADOR WEB

SERVICIO WED

<HTTPS>

<HTTPS>

SISTEMA WED

SISTEMA DEL SERVICIO MEDICO

<HTTPS>

SERVIDOR DE BASE DE DATOS ORACLE 10 GB

MANEJADOR DE BASE DE DATOS ORACLE 10 GB

BASE DE DATOS

Diagrama 46: Modelo de Vista de Despliegue. Fuente: Autor (2008).

237

Centro de Computacin Seccin de Programas y Proyectos 2. Diseo de la base de Datos 1.1 Diseo conceptual de Usuarios
Modulos ModulosUsuarios cod_usu Integer cod_mod Integer id Integer Association_30 cod_mod Integer descripcion Variable characters (254)

NivelDeAcceso nivel Integer descripcion Variable characters (254)

Association_29

Association_31 (D) Association_28 PaguinasModulos Usuario nombre apellido cedula usuario nivel clave cod_usu direcion email cod_sta telefono Variable Variable Integer Variable Integer Variable Integer Variable Variable Integer Variable characters (254) characters (254) characters (254) characters (254) characters (254) characters (254) characters (254) cod_pag descripcion url cod_mod cod_tipo Integer Integer Integer Integer Integer PaguinasUsuario cod_usu Integer cod_pag Integer id Integer

Association_38

Diagrama 47: Diseo conceptual de Usuarios. Fuente: Autor (2010)

1.2 Diseo conceptual de procesos

Diagrama 48: Diseo conceptual de Procesos de sitema. Fuente: Autor (2010)

238

Centro de Computacin Seccin de Programas y Proyectos 1.3 Diseo Relacional De Usuario

Usuario nombre apellido cedula usuario nivel clave cod_usu direcion email cod_sta telefono varchar(254) varchar(254) integer varchar(254) integer varchar(254) integer varchar(254) varchar(254) integer varchar(254) Modulos FK_USUARIO_ASSOCIATI_NIVELDEA cod_mod integer descripcion varchar(254) FK_MODULOSU_ASSOCIATI_NIVELDEA FK_PAGUINAS_ASSOCIATI_PAGUINAS FK_MODULOS_ASSOCIATI_MODULOSU PaguinasUsuario ModulosUsuarios cod_usu integer cod_mod integer id integer cod_usu integer cod_pag integer id integer FK_PAGUINAS_ASSOCIATI_MODULOS

PaguinasModulos cod_pag descripcion url cod_mod cod_tipo integer integer integer integer integer

NivelDeAcceso nivel integer descripcion varchar(254)

Diagrama 49: Diseo relacional de Usuario. Fuente: Autor (2010)

1.4 Diseo Relacional de Procesos de sistema

Diagrama 50: Diseo Relacional de Procesos de sistema. Fuente: Autor (2010)

239

Centro de Computacin Seccin de Programas y Proyectos 1.5 Diseo Fsico de la base de datos de Usuario

Diagrama 51: Diseo Fsico de la base de datos de Usuario. Fuente: Autor (2010)

1.6 Diseo Fsico de la base de datos de los Procesos de sistema

Diagrama 52: Diseo Fsico de la base de datos de Procesos. Fuente: Autor (2010

240

UNUVERSISDAD DE ORIENTE NUCLEO MONAGAS CENNTRO DE COMPUTACION TODOS LOS DERECHOS RESERVADO

5.4 ETAPA IV.

IMPLANTACIN DEL SISTEMA

Centro de Computacin Seccin de Programas y Proyectos

Implementacin de un sistema automatizado que optimice la gestin de los procesos administrativos del rea servicios mdicos de la universidad de oriente ncleo Monagas. DOCUMENTO INPLANTACION DE SOFTWARE VERSIN 0.90 Autor Fecha Versin Descripcin Lolimar Cedeo M. 29-8-09 0.90 Versin preliminar como propuesta de desarrollo 33. Introduccin En este documento se describe los procesos tcnicos de implementacin relacionados con la programacin, pruebas y puesta en operacin de la aplicacin en sus diferentes versiones. Este grupo est compuesto por los procesos de Programacin & Integracin, Pruebas de la Aplicacin y Entrega de la Aplicacin. La Programacin & Integracin se encarga de producir, probar e integrar los componentes arquitectnicos de la aplicacin, en cada una de sus versiones. El proceso de Pruebas de la Aplicacin verifica y valida la aplicacin para asegurarse que cumple con los requisitos especificados y satisface las necesidades de informacin y automatizacin que tienen sus usuarios. La Entrega de la Aplicacin se encarga de poner en operacin (produccin) cada una de las versiones de la aplicacin empresarial. 34. Objetivos de la implantacin El grupo de procesos de implementacin tiene como objetivos generales los siguientes: 1. Producir una versin de la aplicacin de acuerdo a las especificaciones de diseo arquitectnico y detallado elaboradas en los procesos de diseo. 2. Asegurarse que la versin cumple con todos los requisitos acordados y satisface las necesidades del cliente. 3. Poner en produccin la nueva versin en la infraestructura o plataforma de operacin instalada para tal efecto.

242

Centro de Computacin Seccin de Programas y Proyectos

Proceso de Implementacin

Programacin & Integracin

Pruebas de la Aplicacin

Entrega de la Aplicacin

Programacin & Integracin (P&I) consiste en: 1. Elaborar, codificar o adaptar cada uno de los componentes que integran las diferentes versiones de la aplicacin empresarial. 2. Probar cada componente como una unidad. 3. Integrar estos componentes de acuerdo a la arquitectura diseada. 4. Probar la integracin de estos componentes.

Pruebas de la Aplicacin (PA) consiste en verificar cada versin de la aplicacin como un todo y depurar los errores encontrados, a fin de asegurar que ella cumple con todos los requisitos especificados en el Documento de Requisitos. Las pruebas se realizan a tres niveles: 1. Nivel de unidad, en el cual cada componente de software es probado separadamente. 2. Nivel de integracin, en el cual se prueba la integracin de los componentes y sus interacciones. 3. Nivel del sistema, en el cual una versin de la aplicacin se prueba como un todo. Las pruebas de unidad y de integracin tienen lugar durante el proceso de Programacin & Integracin; mientras que las pruebas de sistema se realizan en el proceso de Pruebas de la Aplicacin.

Entrega de la Aplicacin (EA) es el proceso tcnico final del desarrollo de la aplicacin empresarial; en el cual, se realizan las actividades necesarias para poner cada una de sus versiones en operacin (produccin) y entregarla formalmente a sus usuarios.

A continuacin las especificaciones de los casos de pruebas aplicadas al sistema desarrollado para el rea de servicios mdicos:

243

Centro de Computacin Seccin de Programas y Proyectos

Especificacin Caso de Prueba

Descripcin

de
Boleta Medica

01

Este artefacto abarca el conjunto de pruebas realizadas sobre el proceso de sistema Emitir Boleta Medica.

Pruebas Efectuadas

Crear boleta Buscar boletas La prueba se realizara partiendo del formulario de entrada de la aplicacin.

1.Crear Boleta Descripcin Se ingresa al sistema bajo la opcin de usuario y en el men de la aplicacin se ingresa a crear boleta. Condiciones de Ejecucin La nica condicin es que el usuario est registrado en el sistema para poder acceder al mismo y el sistema mostrar la interfaz de boletas con sus respectivas opciones (Nueva boleta,buscar). Entrada Se introduce el nombre de usuario en el 7 Se secciona de un alista desplegable el tipo de 1 campo nombre de usuario. consulta por: Doctor Por Servicios Se introduce la contrasea campo clave de 8 Se secciona de un alista desplegable el tipo de 2 acceso. servicio: Gustavo Brazon 3 Pulsar el botn Ingresar. 9 El sistema carga y muestra su especialidad El sistema muestra en pantalla un campo vaco 4 Se introduce C.I del paciente. 10 para ingresa observaciones de la boleta. Se posiciona el cursor del Mouse en la 5 opcin Ingresar. 11 Pulsamos Guardar. 6 Se posiciona el cursor del Mouse en la El sistema enva mensaje de notificacin y opcin Crear Nueva Boleta. 12 regresa a la pantalla anterior para crear o buscar una boleta si se quiere. Resultado Esperado El sistema crea una boleta Medica correctamente. Evaluacin de la Prueba Prueba superada con xito 2.Buscar Boletas Se ingresa al sistema bajo la opcin de usuario y en el men de la aplicacin se ingresa a Descripcin crear boleta. La nica condicin es que el usuario est registrado en el sistema para poder acceder al mismo. Condiciones de Ejecucin 1 Se introduce el nombre de usuario en el 5 Se introduce en un campo el numero de boleta. Entrada campo nombre de usuario. 2 Se introduce la contrasea campo clave de 6 El sistema muestra boleta. acceso. 3 Pulsar el botn Ingresar. 7 El sistema regresa a la pantalla anterior para crear o buscar una boleta si se quiere. 4 El sistema muestra un campo para ingresar el numero de boleta a buscar. El sistema busca una boleta Medica correctamente Resultado Esperado Prueba superada con xito. Evaluacin de la Prueba Observacin: el sistema al crear una boleta asigna automticamente un numero de boleta.

Tabla 47: Especificacin de caso de pruebas boleta mdica. Fuente: autor 2010.

244

Centro de Computacin Seccin de Programas y Proyectos Especificacin Caso de Prueba de

Administracin Motivo de Despacho
Crear Motivo despacho Editar Motivo despacho La prueba se realizara partiendo del formulario de entrada de la aplicacin.

02

Descripcin

Este artefacto abarca el conjunto de pruebas realizadas sobre el mantenimiento Motivo de Despacho.

Pruebas Efectuadas

1.Crear Motivo Despacho

Se ingresa al sistema bajo la opcin de usuario y en el men de la aplicacin se ingresa a Mantenimiento, posteriormente se selecciona la opcin crear Motivo de Despacho Condiciones de Ejecucin La nica condicin es que el administrador est registrado en el sistema para poder acceder al mismo. Se introduce el nombre de usuario en el 7 Seleccionamos Motivo de Despacho Entrada

Descripcin

1 campo nombre de usuario. 2 Se introduce la contrasea campo clave de acceso. 3 Pulsar el botn Ingresar.

8 9

El sistema permite el ingreso al sistema 4 con los privilegios de usuario. 10 Seleccionamos Realizar 5 Mantenimiento en el men 11 mantenimiento. El sistema muestra una lista de los El sistema muestra mensaje de que el motivo 6 mantenimientos disponibles. 12 de despacha ha sido registrado. Resultado Esperado El sistema crea un nuevo motivo de despacho. Evaluacin de la Prueba Prueba superada con xito

El sistema muestra pantalla de administracin de motivo de despacho Se hace clic en Agregar Nuevo Motivo de Despacho. El sistema muestra pantalla para ingresar nuevo motivo de despacho. Se ingresa el nombre del motivo de despacho y Pulsamos Registrar.

2. Editar Motivo Despacho Descripcin El sistema mostrar la interfaz de mantenimiento correspondiente a Motivo de
despacho con sus respectivas opciones (Agregar Nuevo, Modificar). La nica condicin es que el administrador est registrado en el sistema Condiciones de para poder acceder al mismo Ejecucin Seleccionamos Motivo de Despacho. Entrada 1 Se introduce el nombre de usuario en el 7
2 3 4 5 6 campo nombre de usuario. Se introduce la contrasea campo clave de acceso. Pulsar el botn Ingresar. El sistema permite el ingreso al sistema con los privilegios de usuario. Seleccionamos Realizar Mantenimiento en el men mantenimiento. El sistema muestra una lista de los mantenimientos disponibles. 8 9 El sistema muestra pantalla de administracin de motivo de despacho Se busca de motivo de despacho y se hace clip en editar. Se muestra pantalla para realizar modificaciones. Presionamos Guardar El sistema emite un mensaje de que el motivo de despacho ha sido actualizado.

10 11 12

El sistema modifica el motivo de despacho seleccionado. Resultado Esperado Prueba superada con xito. Evaluacin de la Prueba Observacin: El motivo despacho se realiza para sacar un medicamento del departamento.

Tabla 48: Especificacin de caso de pruebas Motivo Despacho. Fuente: autor 2010

245

Centro de Computacin Seccin de Programas y Proyectos Especificacin Caso de Prueba de

03 Administrar Laboratorio
Agregar Laboratorio Modificar Laboratorio La prueba se realizara partiendo del formulario de entrada de la aplicacin.

Descripcin

Este artefacto abarca el conjunto de pruebas realizadas sobre el mantenimiento Laboratorios.

Pruebas Efectuadas

1.Agregar Laboratorio
Se ingresa al sistema bajo la opcin de usuario y en el men de la aplicacin se ingresa a Mantenimiento, posteriormente se selecciona la opcin Laboratorios y el sistema mostrar la interfaz de mantenimiento correspondiente a Laboratorio con sus respectivas opciones (Agregar Nuevo, Modificar). Condiciones de Ejecucin La nica condicin es que el administrador est registrado en el sistema para poder acceder al mismo. Se introduce el nombre de usuario en el 7 Seleccionamos Laboratorio Entrada

Descripcin

1 campo nombre de usuario. 2 Se introduce la contrasea campo clave de 8 acceso. 3 Pulsar el botn Ingresar. 9 El sistema permite el ingreso al sistema 4 con los privilegios de usuario. 10 Seleccionamos Realizar Mantenimiento 5 en el men mantenimiento. 11 El sistema muestra una lista de los 6 mantenimientos disponibles. 12 Resultado Esperado El sistema ingresa un Laboratorio. Evaluacin de la Prueba Prueba superada con xito

El sistema muestra pantalla de administracin de laboratorio Se hace clic en Agregar Nuevo Laboratorio. El sistema muestra pantalla para ingresar nuevo Laboratorio. Se ingresa el nombre del Laboratorio y Pulsamos Registrar. El sistema muestra mensaje de que el Laboratorio ha sido registrado.

2. Editar Laboratorio
Se ingresa a Mantenimiento, posteriormente se selecciona la opcin Laboratorios y el sistema mostrar la interfaz de mantenimiento correspondiente a Laboratorio con sus respectivas opciones (Agregar Nuevo, Modificar). Condiciones de Ejecucin La nica condicin es que el administrador est registrado en el sistema para poder acceder al mismo. Entrada 1 Se introduce el nombre de usuario en el 7 Seleccionamos Laboratorio.

Descripcin

2 3 4

campo nombre de usuario. Se introduce la contrasea campo clave de acceso. Pulsar el botn Ingresar. El sistema permite el ingreso al sistema con los privilegios de usuario. Seleccionamos Realizar Mantenimiento en el men mantenimiento. El sistema muestra una lista de los mantenimientos disponibles.

8 9 1 0 1 1 1 2

El sistema muestra pantalla de administracin de Laboratorio Se busca Laboratorio y se hace clip en editar. Se muestra pantalla para realizar modificaciones. Presionamos Guardar

El sistema emite un mensaje de que el Laboratorio ha sido actualizado.

El sistema modifica el Laboratorio seleccionado. Resultado Esperado Prueba superada con xito. Evaluacin de la Prueba

Tabla 49: Especificacin de caso de pruebas Laboratorio. Fuente: autor 2010

246

Centro de Computacin Seccin de Programas y Proyectos Responsables de las Pruebas de la Aplicacin Las pruebas correspondientes de los procesos fueron realizadas y cubiertas al finalizar la aplicacin por todos los interesados (stakeholders) del proyecto, bajo las polticas y estndares de calidad del centro de computacin de la universidad de oriente ncleo de Monagas. El proceso de evaluacin estuvo a cargo del responsable general del proyecto Ing. Rosangela Garcia Jefe del departamento y de todo su equipo de desarrolladores quienes conforman un equipo multidisciplinario en lo que a desarrollo de software se refiere. La validacin de las versiones en los casos de pruebas fueron dadas por la Ing. Yhuanailys Nez a quien es Gestor de calidad y Gestor de configuracin de Software.

Entrega de la Aplicacin

El proceso tcnico final del desarrollo de la aplicacin empresarial fue concluido con la entrega de la aplicacin al Dr. Trino Cabello Jefe del departamento del Servicio Mdico odontolgico de la universidad de oriente ncleo de Monagas. La aplicacin fue instalada de manera local en una extensin del servicio mdico ubicada en la sede de Juanico. Esperando la incorporacin de la sede Guaritos.

Capacitacin de los usuarios

A los usuarios de la aplicacin se le dio la capacitacin necesaria para manipular de manera correcta los procesos del sistema, la capacitacin fue suministrada por la pasante Lolimar Cedeo desarrolladora de la aplicacin, quien diseo un manual de usuario para que sirviese gua. Se hiso entrega del manual al momento de entregar la aplicacin y se puede mostrar en el anexo de este trabajo.

247

Centro de Computacin Seccin de Programas y Proyectos Implementacin de un sistema automatizado que optimice la gestin de los procesos administrativos del rea servicios mdicos de la universidad de oriente ncleo Monagas. DOCUMENTO GLOSARIO VERSIN 0.90 Autor Fecha Versin Descripcin Lolimar Cedeo M. 29-8-09 0.90 Versin preliminar como propuesta de desarrollo

1. Organizacin del Glosario

El presente documento est organizado por definiciones de trminos ordenados de forma ascendente segn la ordenacin alfabtica tradicional del espaol, para que el lector pueda entender los diferentes trminos a los que se hace referencia en el presente trabajo. Es importante destacar que este lenguaje informtico es de desarrolladores de software.

2. Definiciones

A continuacin se presentan todos los trminos manejados a lo largo de todo el proyecto de Implementacin de un sistema automatizado que optimice la gestin de los procesos administrativos del rea servicios mdicos de la universidad de oriente ncleo Monagas, as como sus respectivas definiciones:
Actor: un actor es aquella entidad externa, bien sea una persona o sistema, que interacta con el sistema. Hay que tener en cuenta que un usuario puede acceder al sistema como distintos actores. Es un rol que un usuario juega con respecto al sistema. Automatizacin: Es la tecnologa utilizada para realizar procesos o procedimientos sin la ayuda de las personas. Boleta mdica: planilla para efectuar servicios asistenciales externos a la institucin, incluye los datos del doctor, la identificacin del paciente, la fecha y el monto total de la consulta. Casos de Uso: Es una tcnica para capturar requisitos potenciales de un nuevo sistema o una actualizacin de software. Cada caso de uso proporciona uno o ms escenarios que indican cmo debera interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo especfico.

248

Centro de Computacin Seccin de Programas y Proyectos

Confiabilidad: Es la ausencia de acceso no autorizado a la informacin. Coordinacin administrativa: es una dependencia con lnea de mando directa del decanato del ncleo, cuya funcin es controlar y regular el flujo de caja de la Universidad de Oriente. Digitar: Incorporar datos a la computadora utilizando el teclado. Dependencia: Unidades que conforman a la Institucin. Desempeo: Es el grado en el cual un sistema o componente cumple con sus funciones designadas, dentro de ciertas restricciones dadas, como velocidad, exactitud o uso de memoria. Disponibilidad: Cualidad de disponible. Cantidad disponible. Enfermera: Es la profesin de titulacin universitaria de la persona que se dedica al cuidado integral del individuo, la familia y la comunidad en todas las etapas del ciclo vital y en sus procesos de desarrollo. Escenario: Un conjunto de variables que para una situacin poseen un nivel de valor y un grado de ocurrencia. Frmaco: Sustancia orgnica o inorgnica, natural o sinttica, capaz de producir en el organismo vivo cambios anatmicos o funcionales. Funcionalidad: se valora evaluando el conjunto de caractersticas y capacidades del programa, la generalidad de las funciones entregadas y la seguridad del sistema global. Historia clnica: documento mdico legal donde queda registrada toda la relacin del personal sanitario con el paciente, todos los actos y actividades mdico-sanitarias realizados con l y todos los datos relativos a su salud, que se elabora con la finalidad de facilitar su asistencia, desde su nacimiento hasta su muerte, y que puede ser utilizada por todos los centros sanitarios donde el paciente acuda. Linux: Versin de libre distribucin (gratis) del sistema operativo Unix, desarrollada inicialmente por Linus Torvalds, y mejorada gracias a las contribuciones de programadores de todo el mundo. Medicamentos: Sustancia que se administra con fines curativos o preventivos de una enfermedad. Medicina: ciencia que estudia el cuerpo humano, sus enfermedades y curacin. Medico: Persona que se halla legalmente autorizada para ejercer la medicina. Modulo: es un componente autocontrolado de un sistema, el cual posee una interfaz bien definida hacia otros componentes; algo es modular si es construido de manera tal que se facilite su ensamblaje, acomodamiento flexible y reparacin de sus componentes. Morbilidad: Nmero de personas afectadas por una enfermedad en un periodo de tiempo. Navegador: Aplicacin que facilita el acceso de los usuarios a las pginas de Internet.

249

Centro de Computacin Seccin de Programas y Proyectos

Optimizar: buscar la mejor manera de realizar una actividad. Oracle: es un sistema de gestin de base de datos relacional fabricado por Oracle Corporation. Procedimiento administrativo: es la realizacin de una serie de labores en forma orgnica y guardando una sucesin cronolgica en la manera de realizar esas labores. Proceso: es un conjunto de actividades o eventos que se realizan o suceden con un determinado fin. Presupuesto: este departamento tiene como misin planificar revisar y controlar la asignacin presupuestaria de los distintos proyectos, tantos acadmicos como administrativos. Rcipe mdico: es una importante transaccin teraputica entre el mdico y su paciente. Representa un resumen del diagnstico, pronstico y tratamiento de la enfermedad del paciente realizado por el mdico. Resume en un trozo de papel la capacidad diagnstica y la experiencia teraputica del mdico, con instrucciones para aliviar o restablecer la salud del enfermo. Salud: es el logro del ms alto nivel de bienestar fsico, mental, social y de capacidad de funcionamiento que permitan los factores sociales en los que viven inmersos el individuo y la colectividad. Servidor: Una computadora que aloja informacin disponible para los usuarios (llamado clientes) en Internet o cualquier otro tipo de red. Servicio: son actividades identificables, intangibles y perecederas que son el resultado de esfuerzos humanos o mecnicos que producen un hecho, un desempeo o un esfuerzo que implican generalmente la participacin del cliente y que no es posible poseer fsicamente, ni transportarlos o almacenarlo. Software libre: es la denominacin del software que respeta la libertad de los usuarios y por tanto, una vez obtenido, puede ser usado, copiado, estudiado, modificado y redistribuido libremente. Stakeholder: Cualquier persona interesada en, afectada por y/o implicada con el funcionamiento del sistema software. Tramitacin: Serie de trmites prescritos para un asunto, o de los seguidos en l. Usabilidad: Capacidad de un sistema o de una aplicacin de ser usado fcil o eficientemente.

250

Centro de Computacin Seccin de Programas y Proyectos 5.5 Anlisis Costo Beneficio. El anlisis costo-beneficio es una tcnica que pretende determinar la conveniencia de un proyecto mediante la enumeracin y valoracin en trminos monetarios de todos los costos y beneficios derivados de dicho proyecto. En otras palabras, esta tcnica proporciona una medida de la rentabilidad del proyecto, a travs de la comparacin de los costos en que se incurren por la realizacin del proyecto con los beneficios que se esperan obtener del mismo. Este anlisis se lleva a cabo para justificar econmicamente el desarrollo de este proyecto, adems de determinar los beneficios tangibles e intangibles que se generan. 5.5.1 Costos A continuacin se detallan los costos que fueron necesarios para llevar a cabo el desarrollo del proyecto y lograr la construccin del sistema Web para el rea de servicios mdicos odontolgicos de la Universidad de Oriente Ncleo Monagas: Costos de Personal En estos costos se incorporan los salarios devengados por el personal involucrado en el desarrollo del proyecto. En el caso del desarrollo del sistema para el rea de servicios mdicos, la persona que participa en su realizacin es el autor en calidad de pasante, por lo que la Universidad de Oriente Ncleo Monagas no incurre en ningn gasto de este tipo. Costos de Equipos y Herramientas Son los costos relacionados con la adquisicin de los equipos hardware y software necesarios para llevar a cabo el desarrollo del sistema. En este caso no fue necesario realizar este tipo de gasto ya que el Centro de Computacin de la Universidad de Oriente Ncleo de Monagas contaba con los equipos y herramientas de trabajo requeridos.

251

Centro de Computacin Seccin de Programas y Proyectos Costos de Adiestramiento Costos generados por la capacitacin del personal involucrado en el proyecto a travs de cursos, talleres, adiestramientos, entre otros, con la finalidad de proporcionar a los participantes los conocimientos necesarios para llevar a cabo el desarrollo del sistema. Dentro de los talleres y cursos realizados se encuentran la metodologa GRAY WATCH, la herramienta UML, Power Designer, Lenguaje PHP y Macromedia Dreamweaver que fueron dictados por el personal del Centro de Computacin de la Universidad de Oriente Ncleo de Monagas. Costos de Materiales utilizados Representan los costos relacionados con la adquisicin de materiales como resmas de papel necesarias para la documentacin, carpetas, ganchos, cartuchos de tinta para impresora, tner, libreta de anotaciones, lpices, lapiceros, entre otros. Cabe mencionar, que estos materiales fueron financiados por el pasante. En la siguiente tabla se presenta un resumen de los costos del proyecto, detallando cada uno de ellos con sus respectivos valores en bolvares fuertes. Concepto Costos de Equipos y Herramientas de trabajo Hardware Software Total costos de equipos y herramientas: Costos de Infraestructura Sala de trabajo Mobiliario Total costos de infraestructura:
Tabla 50: Costos de Materiales (1/2). Fuente: autor 2010

Costo Valor (Bs. F.) 0 Bs. F 0 Bs. F 0 Bs. F. Valor (Bs. F.) 0 Bs. F. 0 Bs. F. 0 Bs. F.

252

Centro de Computacin Seccin de Programas y Proyectos Concepto Costos de Personal Analista de Sistema Total costos del personal: Costos de Adiestramientos Taller GRAY WATCH Cuso UML Curso de PHP Curso de Macromedia Dreamweaver Total costos de adiestramientos: Costos de Materiales Papel tipo carta (7 resmas x 50 Bs.F.) Papel tipo oficio ( 2 resmas x 40) Dispositivo USB (Pendrive) CD-ROM (10 unidades x 5 Bs. F.) Cartuchos de tinta de impresin ( 6 x 100 Bs.F) Lapiceros (15 unidades x 4 Bs.F.) Carpetas ( 30 unidades x 2.5 Bs. F) Otros Total costos de materiales: Total Costos de Produccin: Tabla 50: Costos de Materiales (1/2). Fuente: autor 2010 5.5.2 Beneficios Los beneficios tienen que ver con las ventajas obtenidas con el sistema desarrollado, destacando que los mismos pueden ser de naturaleza tangible o intangible. Costo Valor (Bs. F.) 0 Bs. F. 0 Bs.F. Valor (Bs. F.) 0 Bs. F. 0 Bs. F. 0 Bs. F. 0 Bs. F. 0 Bs. F. Valor (Bs. F.) 350 Bs. F. 80 Bs. F. 170 Bs. F. 50 Bs. F 600 Bs. F 60 Bs. F 75 Bs. F 400 Bs. F. 1785 Bs. F. 1785 Bs. F.

253

Centro de Computacin Seccin de Programas y Proyectos Beneficios Tangibles Los beneficios tangibles son aquellas ventajas u oportunidades que se pueden cuantificar, y que se obtienen al hacer uso del sistema informtico desarrollado. Son fcilmente cuantificables y medibles en unidades monetarias. Entre estos beneficios se encuentran: A. Reduccin de tiempo en la elaboracin y bsqueda de historias medicas: con anterioridad, las enfermeras utilizaban aproximadamente 0.6 h/h para la bsqueda y elaboracin de una historia mdica. En cambio, con el uso del sistema solo se empleara 0.1 h/h para buscar y llenar una historia. Esta diferencia se puede apreciar claramente en la siguiente tabla: Horas Hombres empleadas Sistema Sistema Actual Beneficios Pasado 0.6 h/h 0.1 h/h 0.5 h/h

Tarea Generar historia Peditrica.

Tabla 51: Reduccin de tiempo.

B. Disminucin de tiempo en la generacin de reportes: Con la utilizacin del sistema automatizado se reduce el tiempo en generar reportes de todos los procesos que se llevan a cobo en el rea de servicios mdicos. Actualmente la auxiliar de registro y estadstica tarda en elaborar estos reportes de 1 a 2 das de trabajo de oficina en un total de 14 horas hombres (h/h) como aproximado. En cambio, con el sistema solo se requieren de 0.05 h/h para generar estos reportes, logrndose por lo tanto mayor agilidad en la materializacin y agilizacin de los mismos. A continuacin se muestra en el siguiente cuadro la diferencia que existe al implantarse el sistema.

254

Centro de Computacin Seccin de Programas y Proyectos Horas Hombres empleadas Sistema Sistema Actual Beneficios Pasado 14 h/h 0.05 h/h 13,95 h/h

Tarea Generar Reportes

Tabla 52: Disminucin de tiempo en la generacin de reporte.

C. Disminucin de Gastos de papelera y fotocopiado: El nmero de pacientes que se atienden anualmente segn cifras del ao 2009, es igual a tres mil setecientos cincuenta y cuatro (3.754), necesitndose al menos una hoja de papel para la historia mdica de cada uno de ellos. Por otra parte, el Servicio Medico emite un promedio de ciento diez (110) boletas mensuales de tres (3) copias cada una, es decir, tres mil novecientos sesenta (3960) anuales. En cambio, con el sistema solo se imprimir 1 boleta. Sumando todo esto y dividiendo entre las quinientas (500) hojas que trae una resma de papel, se tiene que se necesitan aproximadamente diez (16) resmas. Multiplicando el valor obtenido por el precio de una resma de papel, es decir, treinta (50) Bs.F se tiene el siguiente cuadro: Costo de resmas de Papel Sistema Sistema Cant.Papel Pasado Actual 400 Bsf -------

Cant. Evento Papel Crear historias 8 medicas en un Resmas el ao. Crear boletas 8 medicas en un Resmas ao.

Beneficios 400 Bsf

400 Bsf

3 Resmas

150 Bsf

250 Bsf

Tabla 53: Costos de papelera sin el sistema.

D. Reduccin del tiempo de respuesta debido a un procesamiento ms rpido de la informacin. E. Se mantiene una conexin persistente con la base de datos. F. Control en la emisin de documentos. G. Mayor control en los gastos generados a travs del servicio mdico.

255

Centro de Computacin Seccin de Programas y Proyectos H. Asignacin de un presupuesto ajustado a los gastos que se originan en el Servicio Mdico. I. Tomar decisiones acertadas acerca del personal mdico que debe trabajar por honorarios y por servicios. Beneficios Intangibles Los beneficios intangibles son aquellos beneficios asociados a una mejora que por su naturaleza son muy difciles de cuantificar, pero de los que, indiscutiblemente, la organizacin se ve beneficiada al llevar a cabo el desarrollo del proyecto. Estos beneficios son los siguientes: A. Mayor privacidad de la informacin B. Manejo de informacin Confiable. C. Aumentar la satisfaccin del cliente y de los pacientes del servicio mdico en cuanto a la asistencia prestada. D. Mayor organizacin funcional. E. Mejoras en el desempeo del personal y mayor bienestar en el empleo debido al uso de herramientas modernas para apoyar el funcionamiento del negocio. F. Aumento en la calidad del servicio. G. Facilidad en la elaboracin de reportes. H. Motivacin del personal al utilizar herramientas modernas que le permitan eliminar tareas rutinarias o tediosas. I. Mejor imagen de la universidad al implementar nuevas tecnologas

256

CONCLUSIONES
1. La comunicacin con el cliente represent una clave fundamental para poder validar los requisitos y cumplir con sus necesidades o requerimientos. La comunicacin se da a partir de cada una de las iteraciones a lo largo del proceso de desarrollo. 2. Disear la aplicacin, utilizando la herramienta de modelado de sistemas UML, permiti tener una visin detallada del mismo, en funcin de los diferentes diagramas realizados. 3. La metodologa GRAY WATCH , result ser una tcnica favorable en el proceso de desarrollo de software, brindando una serie de tcnicas y procedimientos que ayudaron a desarrollar la aplicacin y cumplir con los objetivos planteados. 4. A pesar de considerar la flexibilidad del sistema, es decir, que pueda ser adaptado a cambios; en el futuro podra ser necesario la incorporacin de nuevos mdulos o cambios en los formularios, dependiendo de la evolucin del servicio mdico en cuanto a la atencin y especialistas. 5. El sistema le permite al personal que labora en el servicio mdico de la universidad, llevar un control y seguimiento de las historias medicas de los pacientes, registros de la boletas y rcipes emitidos, as como tambin de la entrada y salidas de medicamentos de uso comn, conformacin de facturas y validacin de pacientes para la programacin de citas medicas.

257

6. La utilizacin de herramientas, resultan de gran ayuda para el proceso de desarrollo de software, facilitando la labor de muchas tareas e impactando de manera positiva en el tiempo. 7. No existe una forma nica de modelar sistemas, todo depende de la perspectiva del analista y del grado de detalle que desee implementar para dicha labor. 8. El desarrollo de un sistema de informacin, no hace referencia exclusivamente a la tarea de codificacin, se refiere a una serie de pasos o procedimientos para la creacin de un producto, incluyendo tambin aspectos como el modelado del negocio y las tareas de anlisis y diseo.

258

RECOMENDACIONES

1. Acondicionar el rea de servicios mdicos para la instalacin de las computadoras y cualquier otro tipo de requerimiento necesario para la implantacin del sistema. 2. Integrar el sistema del rea de servicios mdicos, con el sub.-sistema de control de estudios y con el de servicio social para poder realizar la

validacin de los estudiantes, obreros y empleados, as como de su respectiva carga familiar. 3. Seguir implantando sistemas automatizados en la Universidad de Oriente ncleo Monagas y no desarrollar proyectos de software que cuyo alcance finalice en la fase de diseo. 4. Seguir utilizando la metodologa GRAY WATCH para el proceso de desarrollo de software en la Universidad, ya que usa las mejores prcticas de ingeniera de software y gestin de proyectos. En la actualidad los mejores mtodos para desarrollar aplicaciones empresariales son los interactivo e incrementales pues dan los mejores resultado. 5. Implementar polticas de seguridad para garantizar el resguardo de los datos. 6. Fortalecer la plataforma tecnolgica del ncleo para que todas las reas involucradas tengan acceso a la red, dado que el sistema propuesto es una aplicacin Web. 7. Vincular el sistema desarrollado con el subsistema de compra para utilizar informacin requerida de las rdenes de compra en los procesos de registro de entrada de insumos mdicos a la farmacia.

259

BIBLIOGRAFA
ARIAS, F. (2006). El proyecto de investigacin: Introduccin a la metodologa cientfica. (5 ed.) Caracas - Venezuela: Episteme. BALESTRINI ACUA, M. (2002). Cmo se Elabora el Proyecto de Investigacin. (6a. ed.). Caracas: BL Consultores Asociados. CASTRO, M. (2003). El proyecto de investigacin y su esquema de elaboracin. (2.ed.). Caracas: Uyapal. BALESTRINI, MIRIAM (2006) Cmo se elabora el Proyecto de investigacin. Quinta Edicin. Editorial Consultores Asociados. Caracas BARRIENTOS, ENRQUEZ (2005). El desarrollo de sistemas de informacin empleando el lenguaje de modelado unificado UML. Documento en lnea. Disponible en http://www.monografias.com/trabajos16/lenguaje-modeladounificado/lenguaje-modelado-unificado.shtml#PRINCIP BARRIENTOS,ALEIDA (2002) Proceso Metodolgico de Auditora Informtica aplicado a la evaluacin y seguimiento de Sistemas de Gestin desarrollados con el estndar de modelado UML, Tesis de Maestra en Ingeniera Informtica, Universidad de Oriente La Habana Cuba Universidad Autnoma Toms Fras, Potos-Bolivia. BELL, DOUGLAS (2007).Diagramas de clases para elaborar sistemas [Documento en lnea]. Disponible en http://www.monografias.com/diagramas de clase/lenguaje-modelado-sistemas. BEN, LAURIE (2005). Software libre, php y mysql .Tecnologas para el desarrollo de aplicaciones web. Ediciones Daz de Santos. Espaa BOOCH, GRADY ET AL (1999). El lenguaje Unificado de Modelado, Primera Edicin, Editorial Addison Wesley,

CARRUEZ, ANTONIO ET AL (2003) Automatizacin de procesos en el sector sanitario e historia clnica electrnica. Hospital Universitario de Valladolid. Espaa. CONSTITUCIN NACIONAL (1999) Repblica Bolivariana de Venezuela. Tomado de Gaceta Oficial N 36.860. Fecha: jueves 30/12/1999. Caracas Venezuela. DA ROSA, FERNANDO Y HEINZ, FEDERICO (2007) Gua Prctica sobre Software Libre, su seleccin y aplicacin local en Amrica Latina y el Caribe. DECRETO N 3.090 DE LA PRESIDENCIA DE LA REPBLICA BOLIVARIANA DE VENEZUELA. Gaceta 38.095 del 28/12/2004), sobre uso del Software Libre ESTRUCTURA ORGANIZATIVA UNIVERSIDAD DE ORIENTE. [Pgina Web en lnea]. Disponible: http://www.udo.edu.ve [Consulta: 2009, Diciembre 07] FERRE GRAU, XAVIER (2009). Desarrollo Orientado a Objetos con UML. [Documento en lnea]. Disponible en:http://74.125.113.132/search?q= cache:_BjUzptjH9UJ:-www.elquintero.net/ContVisit.aspx%3FCat%3D2 %26Id%3D11+.[Consulta: 2010, Mayo 11] GUTIRREZ, JAMES GILDARDO (2009) Definicin arquitectura cliente servidor. [Documento en lnea].. Disponible en C:\Documents and Settings\personal\Mis documentos\Sistemas de Informacin. [Consulta: 2009, Noviembre 23] HERNNDEZ, JORDI (2005) Software libre: tcnicamente viable, econmicamente sostenible y socialmente justa. Primera edicin. Editorial Zero Factory S.L.Barcelona, Espaa HERNNDEZ, R., FERNNDEZ, C. Y BAPTISTA, PILAR (2009). Metodologa de la investigacin. Tercera Segunda Edicin. Editorial McGraw-Hill. Mxico. HURTADO DE BARRERA, J., (2000). Metodologa de la investigacin holstica (2da. ed.) Caracas, Venezuela: Fundacin Sypal JAMES A. SENN (2008), Anlisis y Diseo de Sistemas de Informacin. Editorial Mc Graw Hill. Segunda edicin. Colombia.

LARMAN, C (2002), Tarjetas CRC. [Documento en lnea]. Disponible: http://www.webestilo.com/javascript/js00.phtml [Consulta: 2010, Septiembre 23] MONTILVA C, JONS (2008), Gray Watch. Mtodo de desarrollo de software para aplicaciones empresariales. Mrida -Venezuela MONTILVA C, JONS (2009) Ingeniera de Requisitos. Programa de actualizacin profesional en ingeniera de software. Versin 5.0. Mrida -Venezuela. PARR, MIKE (2006) Diagrama de secuencia. [Documento en lnea]. Disponible: http://www.alegsa.com.ar/Dic/aplicacion%20web.php [Consulta: 2010, Agosto 20] PASTOR, J (2002), Sistemas Transaccionales [Documento en lnea].. Disponible en: http://es.wikipedia.org/wiki/Arquitectura de la informacin [Consulta: 2010, febrero 18] Wikipedia La Enciclopedia Libre, Xampp. [Documento en lnea].. Disponible en:http://es.wikipedia.org/wiki/XAMPP [Consulta: 2009, Junio 18]

ANEXOS

Anexo 1.Vistas del Manual de usuario del sistema.

Anexo 2.Vistas del Manual de usuario del sistema.

Anexo 3.Vistas del Manual de usuario del sistema.