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

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.

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.

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

88

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

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

1
0

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

11

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

131
313

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

141
4

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

15

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 s er 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

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

Produccin y
desarrollo de
sistemas

Valor agregado

SECCIN DE APOYO

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 Bie nestar
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

Coordinacin
Acadmica

Secretaria

Delegacin de
Desarrollo Social y
Bienestar

Transporte

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
01 Auxiliar de Registros y Estadsticas
departamento
01 Higienista Dental
01 jefe de enfermera
01 Secretaria
05 Enfermeras
06 Mdicos

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 persp ectiva 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 la 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.
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

Modelo de Productos

Producto WATCH

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
Entregable

Producto
Intermedio

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

Cliente

Promoto

Desarrolla

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

Modelado
del Negocio

SI
NO

Entrega de la
Aplicacin

Nueva Versin?
Inicio

Ingeniera
de Requisitos

Procesos de
Gestin y
Soporte
Diseo
Arquitectnico

Prueba de la
Aplicacin

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

(20

10)

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

Include>>

Extends

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

Nodo

Componente

Interface

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.

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

Indica que indica el periodo en que estuvo vivo

el objeto durante la secuencia de actividades.
Usuari o del Si stema

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.

Activacin

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

Smbolo

Descripcin
Nodo de actividad
Primitiva ejecutable de asignacin o computacin.

Accin
Nodo de Inicio

Nodo de control que indica el inicio de un flujo de

control cuando una actividad es invocada.

Nodo fin de
actividad

Nodo de control que indica el fin de todos los flujos

dentro de una actividad. Muestra el fin de la actividad.

Flujo de Control

Eje de actividad para flujo de control. Conecta dos

acciones. Usado para indicar secuencia.

Nodo de
Sincronizacin
(fork)

Nodo de control que divide un flujo en dos o ms flujos

concurrentes (paralelos)

Nodo de
concurrencia
(Join)

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 q ue 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 ofre ce 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 d e 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 Mdi cos 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 apoya da 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

Productos Generados

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.

Documento de instanciacin
del mtodo.

Describir de manera general el sistema que se va a desarrollar.

Mtodo Watch
I Anlisis
del
sistema
Procesos de
gestin y
soporte

Establecer la necesidad y el alcance de la aplicacin que se quiere desarrollar.

Documento enunciado del

trabajo del proyecto.
Documento de inicio del
proyecto.

Describir las actividades que componen cada uno de los procesos.

Definir los recursos humanos, tecnolgicos, financieros, fsicos y materiales
necesarios para desarrollar las actividades.

Plan integral del proyecto.

Identificar, describir y evaluar los riesgos inherentes a la aplicacin empresarial.

Plan de Gestin de Riesgos

Describir las actividades para controlar la configuracin del software.

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.

Modelo del negocio.

y validar cada uno de los requisitos

Documento de requisitos

Documentar los requisitos funcionales.

Elaborar y refinar los diagramas de caso de uso.

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

63

1. Estudiar el modelo de negocio

del rea de servicios mdicos,
para obtener una visin del
sistema a nivel conceptual.

Plan de Gestin de la
configuracin
Plan de gestin de
Aseguramiento de la Calidad.

Aplicar entrevistas no estructuradas al personal del rea de servicios mdicos.

Observacin directa.
Revisar, analizar, describir, especificar
funcionales y no funcionales del sistema.

Objetivos especficos

2. Determinar los requisitos del

sistema funcionales y no
funcionales, fortaleciendo y
complementando el modelo
actual.

Etapas

Metodologa/
Herramienta

Actividades

Productos Generados

Definir los estndares de diseo de la aplicacin.

II Diseo
del
sistema
Procesos de
construccin,
gestin y soporte

Documento de diseo
arquitectnico.

Establecer la arquitectura de la aplicacin.

Mtodo
Watch
UML

Especificar los componentes arquitectnicos que conformarn la aplicacin

empresarial para que sta satisfaga los requisitos establecidos.

Procesos de
implementacin.

Documento de diseo
detallado

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

Mtodo
Watch
UML

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.

Disear la interfaz usuario/sistema.

Codificar o programar cada uno de los componentes que integran las diferentes
versiones de la aplicacin empresarial.

III
Implementacin
del sistema

Objetivos especficos

Verificar cada versin de la aplicacin como un todo y depurar los errores

encontrados.

Plan de verificacin y
validacin
Plan de pruebas.
Especificaciones de prueba.

Realizar las pruebas de instalacin y la capacitacin de usuarios.

Instalar el sistema en los servidores de produccin.

Aplicacin empresarial
operativa versin beta
funcional.

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

64

5. Implementar el sistema, ya
probado en su plataforma de
operacin.

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.

Fecha
29-8-09

Versin
0.90

Lolimar Cedeo M.

9-10-09

0.91

Correcciones de versin preliminar

Lolimar Cedeo M.

27-10-09

0.92

Correcciones de versin preliminar

1.0

Descripcin
Versin preliminar como propuesta de desarrollo

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

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

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
trabajo,

minimizar la duplicacin de

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

reportes necesarios para la agilizacin de los procesos

administrativos.
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.

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
02 Odontlogos
01 Secretaria
01 Pediatra
01 Internista
01 Medicina General
06 Mdicos:
01 Gineclogo

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.

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

Responsabilidades

Analista de negocios

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.

Analista de requisitos

Descubrir, analizar, especificar y documentar los requisitos de la aplicacin.

Validar, en conjunto con los usuarios, los requisitos establecidos.
Gestionar los requisitos.

Lder del proyecto

Arquitecto de software
Diseador de software

Programador

Especialista V&V
Gestor de configuracin de
software

Gestor de calidad

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

Nombre
Ing. Rosngela Garcia

Lder del proyecto

Ing.Yhuanailys Nuez

Responsable General del proyecto

Br. Lolimar Cedeo

Analista de negocios
Analista de sistemas
Arquitecto de software
Diseador de software
Programador
Especialista Verificacin & Validacin
Gestor de calidad
Gestor de configuracin de Software

Ing. Yhuanailys Nez.

Responsabilidades

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

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

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

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.

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
Versin
Descripcin
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
Autor

Fecha
Lolimar Cedeo M. 29-8-09

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:

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.

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

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

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

Producto
1. Documento de Inicio del proyecto

Procesos de Gestin

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,

incrementos

versiones

de

programas
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

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
Tcnico

Producto de
Gestin

Producto Entregable

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.

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

Autor

Fecha
Lolimar Cedeo 29-8-09

VERSIN 1.0
Versin
Descripcin
0.90 Versin preliminar como propuesta de desarrollo

Lolimar Cedeo 9-10-09

0.91

Correcciones de versin preliminar

Lolimar Cedeo 27-10-09

1.0

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

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

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

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

El software es fcil de usar y de aprender?

Eficiencia

Es rpido y minimalista en cuanto al uso de

recursos?

Mantenibilidad

Es fcil de modificar y verificar?

Portatilidad

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..

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,

Tecnologa

Innovacin en Consejo de Ministros

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.

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.

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.

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

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

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.

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

Responsable(s):
Periodo en el cual puede suceder:
Analista de negocio y de requisitos.
Durante la elaboracin proyecto.
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

Responsable(s):
Periodo en el cual puede suceder:
Analista de sistema.
Durante la elaboracin proyecto.
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.

Tipo de riesgo:

Consecuencia:
Prolongacin de la culminacin del proyecto.

Organizacional.
Probabilidad
Bajo
Moderado

Periodo en el cual puede suceder:

Durante la elaboracin proyecto.
Baja

Efectos del Riesgo:

Alto

Serio.

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.

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:

Catastrfico.

Alto

Responsable(s):
Periodo en el cual puede suceder:
Analista de sistema
Despus de implantacin del 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

Baja

Bajo

Probabilidad
Moderado

Consecuencia:
Proyecto cancelado.
Efectos del Riesgo:
Serio.

Alto

Responsable(s):
Periodo en el cual puede suceder:
Responsable general del proyecto.
Despus de implantacin del sistema.
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.

Tipo de riesgo:

Consecuencia:
Resistencia al cambio de paradigma de desarrollo de
software.

Organizacional.

Baja

Bajo

Probabilidad
Moderado

Efectos del Riesgo:

Alto

Serio.

Responsable(s):
Periodo en el cual puede suceder:
Responsable general del proyecto.
Durante la elaboracin 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.

007

Descripcin del Riesgo:

Crecimiento no controlado de requerimientos y alcance.

Tipo de riesgo:

Consecuencia:
Proyecto fuera de calendario y requerimientos.

Estimaciones -Requerimientos.

Probabilidad
Efectos del Riesgo:
Serio.
Moderado
Alto

Responsable(s):
Periodo en el cual puede suceder:
Analista negocio, requisitos y de sistemas.
Durante la elaboracin del proyecto.
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.

Tipo de riesgo:

Consecuencia:
Resistencia al cambio, los usuarios no se familiarizan con el
software y retardan las operaciones automatizadas.

Tecnolgico.

Probabilidad
Efectos del Riesgo:
Serio.
Moderado
Alto

Responsable(s):
Periodo en el cual puede suceder:
Responsable general del proyecto.
Despus de implantar el software.
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.

Tipo de riesgo:

Consecuencia:
Software con datos no reales que inciden en su
desempeo funcional.

Tecnolgico.
Probabilidad
Moderado

Periodo en el cual puede suceder:

Pruebas funcionales del software.
Baja

Bajo

Efectos del Riesgo:

Alto

Serio.

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.

010

Descripcin del Riesgo:

Adecuacin errnea o tarda de la plataforma de produccin del software implantado.

Tipo de riesgo:

Consecuencia:
Software de bajo desempeo y elevacin de la resistencia al
cambio por parte de los usuarios.

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

Efectos del Riesgo:

Serio.

Bajo

Responsable(s):
Responsable general del proyecto.
debe evaluar estrictamente las especificaciones de hardware y

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:

Tolerable.

Alto

Responsable(s):
Periodo en el cual puede suceder:
Analista de negocio, software y sistema.
Durante la elaboracin del proyecto.
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.

Responsable(s):
Periodo en el cual puede suceder:
Responsable general del proyecto.
Durante la elaboracin 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 situaci n
descrita.

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

013

Descripcin del Riesgo:

No implantacin de infraestructura tecnolgica en el rea de servicios mdicos.

Tipo de riesgo:
Tecnologa.
Baja

Bajo

Probabilidad
Moderado

Alto

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.

Responsable(s):
Periodo en el cual puede suceder:
Responsable general del proyecto.
Una vez finalizado el 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

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

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.

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

VERSIN 1.0
Autor
Lolimar Cedeo.
Lolimar Cedeo.
Lolimar Cedeo.

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.

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

U.D.O MONAGAS

Suprasistema
Decanato del ncleo

Coordinacin
Administrativa

Coordinacin
Acadmica

Coordinacin Acadmica

rea
Administracin

rea de
Orientacin
Delegacin de
Desarrollo Social y
Bienestar Estudiantil

rea
socioeducativa

Sistema en estudio

rea de
desarrollo social

rea de salud
Medicina
General

Ginecologa

Medicina

Servicios
Mdicos

Interna

Pediatra

Odontologa

Subsistema

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.

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

Nivel Estratgico

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

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

objetivo>>
Objetivo Generar

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.

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.

Procesos de Negocio
objetivo>>
Cita medica
Llevar el control del
nmero de pacientes
atendidos
por
los
doctores.

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

objetivo>>
Historia mdica
Permitir llevar por escrito
los datos del paciente,
motivo
de
consulta,
diagnostico y evolucin.

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

objetivo>>
Boleta mdica
El paciente pueda asistir
a la consulta mdica
especializada de doctor
que no labore dentro del
servicio mdico.

objetivo>>
Registro de boleta
Mdica
Llevar el control de las
boletas emitidas en el
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.

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

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).

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

Recurso Humano
Y Material

Delegacin
de desarrollo
y bienestar
estudiantil

Coordinacin
administrativa

Extensin de
Personal

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.

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.
Nivel 0
Servicios
Mdicos

Servicios Mdicos
PROCESOS DE NEGOCIO

PN 1.1

Cita
Mdica

PN 1.2

PN 1.3

Historia
Mdica

Nivel 1
PN 1.4

Conformacin
de Factura

Boletas
Mdicas

PN 1.5

Solicitud
Medicamentos

Nivel 2
PN 1.1 Cita Mdica

1.1.1
Programar
mdica

cit

PN 1.2 Historia Mdica

1.2.1
Elaboracin de
Historia Mdica

PN 1.3 Boletas Mdica

1.3.1
Creacin de
Boletas
Mdicas

PN 1.4 Conformacin de Factura

1.3.2
Consulta Extern
al
servici
Mdico.

1.4.1
Validar Informaci
de Factura

PN 1.5 Solicitud de Medicamento

1.5.1
Peticin
d
Medicamentos
an
Bienestar Estudiantil

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

107

1.5.2
Suministro de
Medicamentos al
Paciente

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

Ac t o r
Enfermera

Objetivo
Programar
cita
mdica al paciente

<<Controla>>

<<Cumple>>

<<Controla>>

Paciente

1.1.1
Programar
Cita Mdica

Solicitud
El paciente present
identificacin y solicit
el servicio. Se valid
informacin.
<<Ejecuta>>
Actor
Enfermera

Producto
Cita
Programada

<<Crea>>
Consulta
Se valida informacin de identidad del
paciente y disponibilidad del doctor

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

108

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
paciente?

Presenta su carnet o
una constancia de
estudio firmada y

Usuario

Rechazar Paciente

Valido?
[SI]

sellada.

Verificar disponibilidad del doctor

[Obrero y Empleados]
Presenta
carta
d
autorizacin, la cua
es emitida por e
departamento
d
servicio social.

Doctor

[NO]
Cancelar cita

disponible?
[SI]

Programar Cita Medica

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

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 contemplad
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.

Ac t o r
1. Doctor
2. Enfermera
<<Controla>>

<<Cumple>>

<<Controla>>

Doctor

Proceso
Examina
efecta
u
diagnostico
de
paciente.

1.2.1
Elaboracin de
Historia Mdica

<<Crea>>

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

<<Ejecuta>>
Ac t o r
Doctor

Registro
Se registra historia mdica

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

Fuente: autor (2010)

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 Medicamento

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

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.

Actor
Doctor

Objetivo
Que el paciente asista a
consulta externa al servicio
mdico.

<<Controla>>

<<Cumple>>

<<Controla>>

1.3.1

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

Creacin de
Boleta Mdica

Doctor

<<Ejecuta>>
Ac t o r
Auxiliar de registros y estadsticas

Producto
La auxiliar de registro
y estadstica elabore la
boleta medica.

<<Consulta>
Consulta
Referencia del
doctor.

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

112

Diagrama de actividades del proceso 1.3.1 Creacin de Boletas Mdicas:

Nivel 0

Servicios
Mdicos

Servicios Mdicos

1.2
Historia
Mdica

1.1
Cita
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

Doctor

1.3.2
Consulta externa
servicio medico

Aux. Registro y Estadstica

Nivel 2
al

Delegacin de Personal

Paciente

Recibe Soporte
Elaborar soporte
[Obreros y
Empleados]

[SI]
Doctor
contratado?
[NO]

Tipo
Paciente?

[Estudiante]

Crear boleta mdica

Registro de boleta mdica

No crear boleta mdica

Se
entrega
soporte medico

Se enva registro
Almacenar
copia de boleta de boleta medica

Sella soporte

Recibir registro de boleta medica

Recibe boleta/soporte

Diagrama 3: Diagrama de actividades del proceso creacin de boleta medica. Fuente:

autor (2010)

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.

Ac t o r
Aux. De Registro y Estadstica

<<Controla>>

Objeto
Recibe boleta medica
de manos del paciente
y diagnostica.

<<Controla>>

Objetivo
Brindarle al pacien
atencin
mdi
especializada.

<<Cumple>>

1.3.2

Consulta Externa
al servicio Medico
Doctor Externo

<<Ejecuta>>

Doctor Externo

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)

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

Servicios
Mdicos

Nivel 0

Servicios Mdicos

Nivel 1
1.1
Cita
Mdica

1.2
Historia
Mdica

1.3
Boletas
Mdicas

1.4
Conformacin
de Factura

1.5
Solicitud de
Medicamentos

Boletas Mdica

1.3.1
Creacin de
Boletas Mdicas

Delegacin de Personal

1.3.2
Consulta externa
al servicio medico

Paciente

Nivel 2

Medico Externo

Servicio Mdico

Recibe boleta mdica o soporte

Examinar al Paciente
Especifica monto de consulta

Enva boleta mdic

original y 2 copias.

Recibir boletas original

con monto de consulta

Recibir 2 copia de boleta

con monto de consulta

Lleva las copias de la boleta

al servicio medico

Recibe copias de
boleta mdica con
monto de consulta

Diagrama 4: Diagrama de actividades del proceso consulta externa al servicio mdico.

Fuente: autor (2010)

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.

Actor
El jefe del departamento

<<Controla>>

<<Cumple>>

<<Controla>>

1.4.1

Objeto
Presenta factura d
compra de medicinas.
Paciente

Objeto
El paciente recibe
las
facturas
conformadas.

Validar
Informacin de
Factura.
<<Ejecuta>>

<<Consulta>>
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.

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

Nivel 1

1.5
Solicitud de
Medicamentos

Conformacin de Facturas

Nivel 2

1.4.1
Validar Informacin
de Factura

Paciente Jefe de departamento

Presentar
factura y
Rcipe

Aux. Registro y Estadstica

Extencion de
Personal

Fames

Sindicato

Nivel 3

Verificar informacin

Conformar factura

Registrar factura
[Si]

Enva factura conformada

Empleado?
[No]

[Si]

Estudiante?

Enva factura conformada

[No]
Paciente obrero

Enva factura conformada

Recibir factu
conformada
Recibir factu
conformada
Recibir factu
conformada

Diagrama 5: Diagrama de actividades del proceso validar informacin de facturas.

Fuente: autor (2010)

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

Objetivo
Actor
Jefe de departamento

<<Controla>>

Bienestar
Estudiantil
suministra medicamentos al
servicio mdico.

<<Controla>>

<<Cumple>>
Proceso

Solicitud

Solicita medicamento
de tipo diario
Bienestar Estudiantil.
Doctor

1.5.1
Peticin
de
Medicamentos
ante
Bienestar Estudiantil

<<Solicitud>
Solicitud

Jefa
de
enfermera
elabora carta de solicitud
de medicamentos.

Bienestar Estudianti
suministra
medicamentos.
Enva!

<<Ejecuta>>
Actor
Bienestar Estudiantil

Proceso

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)

Diagrama de actividades del proceso 1.5.1.

Bienestar Estudiantil.
Servicios
Mdicos
1.1
Cita
Mdica

Servicios Mdicos

1.2
Historia
Mdica

1.3
Boletas
Mdicas

Peticin de Medicamentos Ante

Nivel 0

1.4
Conformacin
de Factura

Nivel 1

1.5
Solicitud de
Medicamentos

Solicitud de Medicamentos

1.5.1
Peticin de Medicamentos ant
bienestar estudiantil

Jefe de departamento

Solicita medicamento

Jefe de enfermera
Elaborar
carta de
solicitud

Nivel 2

1.5.2
Suministro de Medicament
al paciente

Bienestar Estudiantil

Enva solicitud

Recibir carta de solicitud

Rechazar solicitud

[No]

Solicitud
Correcta?

Corrige solicitud

[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).

Nivel 3

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

<<Controla>>
Solicitud

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

Objetivo

Ac t o r
Enfermera y
Coordinadora de
Enfermera

El
paciente recibe
medicamentos de tipo
diario.

<<Controla>>

<<Cumple>>

1.5.2
Suministro
de
Medicamento al
Paciente

Servicio

Dar medicamento
al paciente.

Paciente

servicio mdico.

<<Ejecuta>>
Actor
Bienestar Estudiantil

<<Registro>>
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).

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.4
Conformacin
de Factura

1.3
Boletas
Mdicas

Nivel 1

1.5
Solicitud de
Medicamentos

Solicitud de Medicamentos

1.5.1
Peticin y recepcin de
Medicamentos

Paciente

Nivel 2

1.5.2
Suministro de Medicamentos
paciente

Enfermera

Solicita medicamento de tipo diario

Verifica Informacin

Nivel 3

[No]
Por Rcipe?

Registra salidas

[Si]
Muestra rcipe del servic

Suministrar medicament
o

Recibir medicamentos

Diagrama 7: Diagrama de actividades del proceso Suministro de Medicamento al Paciente

Fuente: autor (2010)

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>>
NORM
A
Normas generales
de control interno.
Brindar atencin
dmdico-odontolgica
e 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).

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*

Se Registran

Salida
Medicamento

Puede Solicitar 1*
1*
Tiene Una

Medicamentos

Citas

Se Registran

Libro Morbilidad

Historia Mdica

Puede Emitir

1*

Rcipe Mdico

Puede Generar
1

1*

Facturas

Puede Emitir
1

Boletas Mdicas
1*

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

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:

Centro de Computacin
Seccin de Programas y Proyectos

Cita Mdica
Programar
cita Mdica

Eventos

rea de servicios Mdicos de la Universidad de Oriente Monagas

Procesos del Negocio
Historia
Conformacin de
Boletas Mdicas
Solicitud de Medicamento
Mdica
Factura
Elaboracin de
Consulta externa
Validar
Peticin de
Suministro de
Creacin de
Historia
con boleta
informacin de
medicamento ante
medicamento al
boletas Mdica
consulta
bienestar estudiantil
paciente
Mdica
Mdica

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.

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

Autor

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

Versin 1.0
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

Diagrama de proceso:
Insumo
Modelo de
Negocio

1.
Descubrimiento de
Requisitos

Productos

Dominio
Objetivo
Proceso
Reglas
Actores
Problemas
Lista
preliminar
fundamentales

de

requisito

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.

<<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.

<<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.

Centro de Computacin
Seccin de Programas y Proyectos

Reglas del Negocio:

Cdigo

Nombre

RN-001

Derecho estudiantil

RN-002

RN-003

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

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.

Suministro de Medicina

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.

Fuente

Variacin

Delegacin de desarrollo y
bienestar estudiantil.

Baja

Sindicatos de trabajadoras y
trabajadores de la
universidad de orienteMonagas

-------

Baja

-------

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

Sindicatos de trabajadoras y
trabajadores de la
universidad de orienteMonagas

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

130

Regla del negocio asociada

Baja

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.

Cdigo

Nombre

RN-005

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

RN-006

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

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.

Fuente

Variacin

Regla del negocio asociada

Sindicatos de trabajadoras y
trabajadores de la
universidad de orienteMonagas

Baja

Sindicatos de trabajadoras y
trabajadores de la
universidad de orienteMonagas

Baja

Reposo Mdico

RN-007

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

RN-008

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

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.

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

Sindicatos de trabajadoras y
trabajadores de la
universidad de orienteMonagas

Baja

Sindicatos de trabajadoras y
trabajadores de la
universidad de orienteMonagas

Baja

Cdigo

RN-009

Nombre

Historia medica

Rcipe medico
RN-010

Reposo medico
RN-011

RN-012

Libro Morbilidad Trimestral

Boletas Mdicas
RN-013

Descripcin
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.

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

Fuente
Servicio Mdico.
Monagas 2009

UDO

Servicio Mdico.
Monagas 2009

UDO

Variacin

Regla del negocio

asociada

Alta

Alta

Servicio Mdico.
Monagas 2009

UDO

Servicio mdico.
Monagas 2009

UDO

Servicio Mdico.
Monagas 2009

UDO

Baja

Baja

RN-005

Baja
-

Cdigo

RN-014

RN-015

Nombre

Medicamentos

Conformacin de Facturas

Descripcin

Fuente

Variacin

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

Servicio Mdico. UDO

Monagas 2009.

Baja

RN-003

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.

Regla del negocio

asociada

RN-003

Contrato Colectivo de la
UDO vigente.

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

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

Act-002
Descripcin

Actor Indirecto

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

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 m dica y cr ea soporte para la elaboracin de boletas mdicas.

Smbolo
Doctor

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

134

Actor Directo

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 l ibro 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 vitico s, 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
especiali dades mdicas, registra boletas mdicas y lleva un control de facturas.

Actor Directo

Smbolo
Auxiliar de Registro y Estadstica

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

Act-007
Descripcin

Smbolo

Medico externo o Medico no Contratado

Este representa a la persona que recibir boletas mdicas y presta servicio mdico al paciente.

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
condici n del paciente y recibe facturas conformadas.

Smbolo

Actor Indirecto
Extensin de Delegacin de Personal

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

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

Coordinacin Administrativa

Descripcin

Este representa a la dependencia que recibe libro de morbilidad trimestralmente y recibe reporte de
enferm era.

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
dencia emi
correspon
tida o recibida y transcribe informes mdicos.

Smbolo
Actor Indirecto

Secretaria

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

28. Recoleccin de Requerimientos Iniciales

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

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

Regla del
Negocio

Medio

Enfermera

PN 1.1

RN-008

En lnea

Enfermera

PN 1.1

RN-008
-

En lnea

Enfermera

PN 1.1

Doctor

PN 1.2

RN-009

En lnea

Doctor

PN 1.2

En lnea

En lnea

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

cdigo

Descripcin del
Requerimiento

R-006
R-007

Registrar una boleta

mdica
Imprimir una boleta
mdica

R-008

Emitir Rcipe mdico

R-009

Registrar una
conformacin facturas

R-010

Controlar entrada y
salida de medicamento

Actor

Proceso de
Negocio

Regla del
Negocio

Medio

Jefe del
Departamento

PN 1.3

RN-013

En lnea

Jefe del
Departamento

PN 1.3

Impreso

PN 1.1

RN-010

Impreso

PN 1.4

RN-014

En lnea

PN 1.5

RN-013

En lnea

En lnea e
impreso

Doctor
Jefe del
Departamento
Jefe de
Enfermera

Jefe del
departamento
Generar Reporte de todos
los procesos
Debe existir un registro
actualizado de la
R-012
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:

Requisitos
de Negocio

Requisitos
del usuario

Requisitos
del Sistema

Requisitos
d
Comportamiento

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.

Requisitos dados por:

Centro de computacin
de la U.D.O

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:

Personal del servicio
Mdico-Odontolgico.

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

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

Requisitos
organizacionales

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
por:
Centro de dados
computacin
de la U.D.O

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

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:

Centro de Computacin
Seccin de Programas y Proyectos
cdigo

Descripcin del Requisito

Usuario

Proceso de
Negocio

Regla del
Negocio

El sistema debe tener la opcin de validar el usuario y administrar usuario.

Administrador

RF-002

El sistema de informacin deber mostrar un mensaje de autentificacin fallida cada vez que
el nombre de usuario o claves sean invlidas.

Administrador

RF-003

El sistema debe tener la opcin de editar, agregar o eliminar usuario.

Administrador

RF-004

El sistema se bloquea despus de tres intentos fallidos de login.

Administrador

RF-005

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.

Administrador

RF-007

RF-008
RF-009
RF-010
RF-011
RF-012
RF-013

Medio
En lnea

De Comportamiento

RF-001

RF-006

Tipo de Requisito

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).

De Comportamiento

En lnea

De Comportamiento

En lnea

De Sistema

En lnea

De Comportamiento

En lnea

De Sistema

En lnea

Administrador

Administrador

De Comportamiento

En lnea

Enfermera

1.1
cita medica

De Comportamiento

En lnea

De Comportamiento

En lnea

Enfermera

Enfermera

1.1
cita medica

1.1
cita medica

De Comportamiento

En lnea

Enfermera

1.1
cita medica

De Comportamiento

1.1
cita medica

Enfermera

1.1
cita medica

Enfermera

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

141

En lnea
En lnea

De Comportamiento

De Comportamiento

En lnea

cdigo

Descripcin del Requisito

RF-015

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.

RF-016

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.

RF-014

RF-020

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.

RF-021

El sistema tiene que ir generando automticamente el registro de todas las consultas hechas a
los pacientes y su diagnostico para registrarlo en morbilidad.

RF-022

El sistema tiene que tener la opcin de bsqueda de cualquier historia medicas en el

momento que el usuario as lo quiera.

RF-024

Cuando ya la historia mdica sea llenada y guardada, el sistema automticamente debe

mostrar la opcin de emitir rcipe o referencia para boleta medica.

RF-025

El sistema debe guardar los registros de historias por fechas.

RF-017

RF-018

RF-019

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

Actor
Enfermera

Proceso de
Negocio

Regla del
Negocio

Tipo de
Requisito

Medio

1.1
Cita Medica

De Comportamiento

En lnea

Doctor

1.2
Historia medica

RN-009

De Comportamiento

En lnea

Doctor

1.2
Historia medica

RN-009

De Comportamiento

En lnea

Doctor

1.2
Historia medica RN-004,009

De Comportamiento

En lnea

Doctor

1.2
Historia medica

RN-009

De Comportamiento

En lnea

Doctor

1.2
Historia medica

RN-009

De Comportamiento

En lnea

Doctor

1.2
Historia medica

RN-009

De Comportamiento

En lnea

Doctor

1.2
Historia medica

RN-009,012

De Comportamiento

En lnea

Jefe del
Departamento

1.2
Historia medica

RN-009

De Comportamiento

En lnea

Doctor

1.2
Historia medica

RN-009,013

De Comportamiento

En lnea

Aux. Registro
y Estadstica

1.2
Historia medica

RN-009

De Comportamiento

En lnea

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

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.

RF-030
RF-031

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.

RF-032
RF-033
RF-034
RF-035

Actor

RF-036

Regla del
Negocio

Tipo de Requisito

Medio

RN-009

De Comportamiento

En lnea

Doctor

1.2
Historia medica
1.2
Historia medica

RN-003,009

De Comportamiento

En lnea

Doctor

1.2
Historia medica

RN-003,009

De Comportamiento

En lnea

RN-009,010

De Comportamiento

En lnea

Doctor

Doctor

1.2
Historia medica

Aux. Registro
y Estadstica

1.2
Historia medica

Doctor
Jefe del
Departamento

1.2
Historia medica
1.2
Historia medica

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.

Proceso de
Negocio

De Comportamiento
RN-009,010

En lnea

RN-009,010

De Comportamiento

En lnea

RN-010

De Comportamiento

En lnea

RN-013

De Comportamiento

En lnea

Doctor

1.2
Historia medica

Aux.
Registro y
Estadstica

1.3
Boleta medica

RN-013

De Comportamiento

En lnea

Jefe del
Departamento

1.3
Boleta medica

RN-013

De Comportamiento

En lnea

Jefe del
Departamento

1.3
Boleta medica

RN-013

De Comportamiento

En lnea

Aux.
Registro y
Estadstica

1.3
Boleta medica

RN-013

De Comportamiento

En lnea

RF-038

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

Jefe del
Departamento

1.3
Boleta medica

RN-008,013

De Comportamiento

En lnea
Impreso

RF-039

El sistema debe generar formato para crear un reposo medico.

Jefe del
Departamento

1.2
Historia medica

RN-005,011

De Comportamiento

En lnea

RF-037

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

cdigo
RF-040
RF-041
RF-042

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.

RF-043
RF-044

El sistema debe tener la opcin de buscar boletas medicas emitidas durante una fecha
determinada.

RF-045

El sistema tiene que mostrar un men para la conformacin de las facturas.

RF-046

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.

RF-047
RF-048
RF-049

RF-050
RF-051

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

Tipo de Requisito

Medio

RN-013

De Comportamiento

En lnea

RN-013

De Comportamiento

En lnea

RN-013

De Comportamiento

En lnea

RN-013

De Comportamiento

En lnea

RN-013

De Comportamiento

En lnea

RN-015,016

De Comportamiento

En lnea

RN-015,016

De Comportamiento

En lnea

RN-015,016

De Comportamiento

En lnea

Conformacin de
Jefe del
facturas
Departamento

RN-015,016

De Comportamiento

En lnea

Conformacin de
Jefe del
facturas
Departamento

RN-015,016

De Comportamiento

En lnea

RN-015,016

De Comportamiento

En lnea

RN-015,016

De Comportamiento

En lnea

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

1.4

1.4
Jefe del
Departamento Conformacin de
facturas

1.4
Jefe del
Departamento Conformacin de

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

facturas

cdigo
RF-052

Descripcin del Requisito

Actor

Medio

RN-015,016

De Comportamiento

En lnea

Cuando una factura ya este registrada, el sistema debe indicarlo.

Jefe del
Departamento

RN-015,016

De Comportamiento

En lnea

RN-015,016

De Comportamiento

En lnea

De Comportamiento

En lnea

RN-003,014

De Comportamiento

En lnea

RN-003,014

De Comportamiento

En lnea

RN-003,014

De Comportamiento

En lnea

RN-003,014

De Comportamiento

En lnea

RN-003,014

De Comportamiento

En lnea

RN-003,014

De Comportamiento

En lnea

RN-003,014

De Comportamiento

En lnea

De Comportamiento

En lnea

El sistema debe mostrar el curso de una factura:

Si la factura fue conformada, si ya fue enviada a su departamento correspondiente.

RF-055

El sistema tiene que mostrar un men con todo lo relativo a medicamentos, para
realizar las actividades relacionadas con este.

Jefe de
enfermera

RF-056

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.

Jefe de
enfermera

RF-057

Para el mantenimiento de medicamento se tienen que manejar campos como:

nombre del medicamento, presentacin, cantidad y fecha de vencimiento

Jefe de
enfermera
Jefe de
enfermera

RF-059

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.

RF-060

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)

Jefe de
enfermera

RF-061

El men de medicamento debe tener la opcin de podre mostrar todos los

medicamentos que salen por rcipe medico.

Jefe de
enfermera

RF-063

Tipo de Requisito

1.4
Jefe del
Departamento Conformacin de

RF-054

RF-062

Regla del
Negocio

En el sistema debe mostrar las de facturas generada por un paciente:

Si es procesada por medicamento, procesadas por atencin especializada.

RF-053

RF-058

Proceso de
Negocio

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.

Jefe del
Departamento

Jefe de
enfermera

Doctor
Aux. Registro
y Estadstica.

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

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
-

RN-003,014

cdigo
RF-064
RF-065

RF-066

RF-067

RF-068

RF-069

RF-070

RF-071

Descripcin del Requisito

Actor

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.
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.

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

Proceso de
Negocio

Regla del
Negocio

Tipo de Requisito

Medio

Aux. Registro y
Estadstica

De Comportamiento

En lnea

Aux. Registro y
Estadstica

De Comportamiento

En lnea

De Comportamiento

En lnea

De Comportamiento

En lnea

De Comportamiento

En lnea

De Comportamiento

En lnea

De Comportamiento

En lnea

De Comportamiento

En lnea

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

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

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

Requisitos No Funcionales del Sistema

cdigo
RNF-001

Descripcin del Requisito

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

Usuario

Proceso de
Negocio

Regla de
Negocio

Externo

En lnea

Todo los
Usuarios

De Producto

En lnea

Todo los
Usuarios

Tipo de
Requisito
De Producto

Medio
En lnea

RNF-003

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.

RNF-004

El sistema deber tener una interfaz grfica sencilla y amigable, basada en mens, ventanas,
listas desplegables y botones de accin.

Todo los
Usuarios

Organizacional

En lnea

RNF-005

Desarrollador

Organizacional

RNF-006

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.

Desarrollador

De Producto

RNF-007

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

Desarrollador

De Producto

Desarrollador

Organizacional

Desarrollador

Organizacional

Desarrollador

Organizacional

RNF-002

RNF-009

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-010

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

RNF-008

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

Todo los
Usuarios

Requisitos No Funcionales del Sistema

cdigo

RNF-011

Descripcin del Requisito

El sistema debe ser capaz de ejecutarse en la configuracin estndar de los equipos de

cliente de la universidad.

Usuario

Proceso

Regla de
Negocio

Tipo de
Requisito

Medio

Desarrollador

Organizacional

Desarrollador

De Producto

Desarrollador

Organizacional

El sistema debe tener rapidez y rendimiento de respuesta.

RNF-012
RNF-013

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.

RNF-015
RNF-016
RNF-017
RNF-018

Desarrollador

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.

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

De Producto

Desarrollador

Externos
-

Desarrollador

Externos

Desarrollador

De Producto

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

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

9126-1

Calidad Interna

9126-3

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:

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.

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.

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:

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.

1.
2.
3.
4.
5.

Adecuidad
Exactidud
Interoperabilidad
Seguridad
Conformidad de la
funcionalidad

Adecuidad

1.
2.
3.
4.

Fiabilidad

Usabilidad

Eficiencia

Mantenibilidad

Transportabilidad

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.

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.

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

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

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

Madurez
Tolerancia a fallos
Recuperabilidad
Conformidad de la
fiabilidad

Madurez

1.
2.
3.
4.
5.

Entendibilidad
Aprendibilidad
Operatibilidad
Atractivo
Conformidad de la
usabilidad

Entendibilidad

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

Comportamiento en el Tiempo

1.
2.
3.
4.
5.

Analizabilidad
Cambiabilidad
Estabilidad
Examinabilidad
Conformidad de
la mantenibilidad

Cambiabilidad

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

154

1.
2.
3.
4.
5.

Adaptabilidad
Instalabilidad
Coexistencia
Remplazabilidad
Conformidad de la
transportabilidad

Conformidad de
Transportabilidad

la

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

Servicio Mdico U.D.O Monagas

Programar Cita Mdica

Enfermera
Jefe de Enfermeria

Elaborar Historias Mdicas

<<Include>>

<<Include>>

Mdico General
Especilista
Pediatra

Emitir Recipe Mdico

Autenticar Usuario

<<Include>>
Odontologo

<<Include>>

Mdico
Emitir Boletas Mdicas

Internista

<<Include>>
Ginecologo
Higienista Dental
Aux.de Registro y Estadistica

Conformar Facturas

<<Include>>

Jefe de Departamento
Suministro de Medicamento

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

Validar usuario

Caso de Uso
Autor

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
Actores
3.Jefe del Departamento
6. Secretaria
Primario- Esencial
Tipo
Documento Definicin de Requisitos
Referencias
Pre -condicin El usuario introduzca su login y su clave y pulse ingresar
Pos -condicin Entrada de usuario al sistema.
Diagrama de Caso de Uso
Validar Usuario
Usuario del Sistema

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 usuari

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.

Centro de Computacin
Seccin de Programas y Proyectos
Diagrama de Secuencia
W:V a l i da rUsua ri o

Usuar io

Niv eldeAcceso

Mo dUsu

P agUsu

Mo dulo s

P agin as

Us uario del Sis tema

Ingresar Nombre de Usuario
Ingresar Cont rasea
P resionar " Ingresar"
T ilda Abminist rador
Enviar login

ValidarNombreUsuario ( )

ValidarCont rasea ( )
Si Resp=fal se

P rocesar

Usuari o NO val i do
Si Resp=true

P rocesar Modulos
CargaModulosUsuario (
) P rocesa

CargaModulo ( )

Veri fi
ca

CargaUsuario( )
P rocesa
Most rar P ant alla de Inicio

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

159

CargarP agina ( )

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

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
<<Incl ude>>

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 2
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.
Tabla 19: Curso bsico de eventos para validar usuario 1/2. Fuente: auto 2010

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
4 Buscar Usuario.
El sistema busca usuarios de acuerdo a los
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.
confirmacin para eliminar el usuario.
El Administrador selecciona un
usuario de la lista y presiona el
botn Eliminar.
6.2 El usuario confirma eliminacin. 6.3 El
sistema
elimina
el
usuario
seleccionado.
6.4 El sistema enva un mensaje indicando
que el usuario ha sido eliminado
exitosamente.
7 El
usuario
administrador 7.1 Para terminar con el proceso, el sistema
presiona el botn Salir.
abre y muestra el men principal.
3.4
3.5

Tabla 19: Curso bsico de eventos para validar usuario 2/2. Fuente: auto 2010

Cursos Alternos
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.
1a

Tabla 20: Curso alternos de eventos para validar usuario. Fuente: auto 2010

Comentarios
1

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

Centro de Computacin
Seccin de Programas y Proyectos
Diagrama de Secuencia
W: M e n u A d m i n i st a rd o r

W: Usu a ri o

Usu a ri o

Ni ve l d e A cce so

A d m i n i stra d o r d e l S i ste m a

S e l e cci o n a r A d m i n i stra r Usu a ri o

A b re V e n ta n a ( )

B u sca Usu a ri
o
M u e st ra L i sta
os

B u sca rUsu a ri o ( )

d e Usu a ri

A b re V e n ta n a ( )
P re ci o n a B o to n " Nu e
vo "

Ca rg a Fo rm u l a ri
o

Ca m b i a ve n ta n
a

Ca rg a Ni ve l d e A cce so ( )
B u sca
so

Cre a r Nu e vo
Usu a ri
o

M u e st ra Fo rm u l a
ri o

Ni ve l d e A cce
B u sca Ni ve l d e A cce so
)

Ca rg a Ni ve l d e A cce so
)

Ca rg a Fo rm u l a ri o ( )

L l e n a Da to s d e Usu a ri o a Cre
ar

P re ci o n a B o to n " A g re g a r"

P ro ce sa
S i Re sp =fa l se

Re sp =V a l i d a r( )

Da to s i n va l i d o s o ya e xi st e

e l n o m d re u su a ri o

In se rta r( )
S i Re sp =tru e
Usu a ri o cre a d o e xi to sa m e n te

A b re V e n ta n a ( )
M u e st ra p a n ta l l a a n te ri o r

A b re V e n ta n a ( )
P re si o n a B o to n " Re to rn a r"

Re to rn a
r

M u e st ra p a n ta l l a a n te
ri o r

L l e n a ca m p o d e b u sq u e d a
B u sca r Usu a ri
o

B u sca rUsu a ri o ( )
P re si o n a B o to n " Fi l tra r"

B u sca u su a ri o s d e a cu e rd o a ca d e n a d e ca ra cte re s te cl a d o s
M u e stra

l i sta

d e u su a ri o s d e a cu e rd o a l a ca d e n a te cl a d a

S e l e cci o n a u su a ri o d e l a l
i sta
P re si o n a B o to n " M o d i ca "
A b re V e n ta n a ( )
Ca m b i a ve n ta n a
su a ri o

Ca rg a fo rm u l a ri o co n d a to s d e u

B u sca Usu a ri o (co d Usu a ri o )

M u e st ra fo rm u l a ri o co n d a to s d e u su
a ri o
E d i ta r Usu a ri
o

Ca rg a rT i p o Usu a ri o ( )
B u sca n i ve l d e a cce
so
Ca rg a fo rm u l a ri o ( )

E d i ta r d a to s d e l u su a ri o
P re si o n a B o to n " M o d i f i ca r"

P ro ce sa
Usu a ri o a ctu a l i za d o e xi to sa m e
n te

M u e st ra p a n ta l l a a n te ri o r
A b re V e n ta n a ( )

Sal i r

P re si o n a B o to n " S a l
i r"

A b re V e n ta n a ( )
M u e st ra P a n t l l a d e M e n u P ri n ci p a l

A ctu a l i za ( )

Diagrama
17:

diagrama de
secuencia

administrar usuario. Fuente: auto 2010

163

Pantallas

Pantalla 1/2. Validar usuario Administrador

Pantalla 1/2. Pantalla Administrador del sistema

164

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

<<Incl ude>>

P rogramar Cit a 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.
3
Ingresa cedula de identidad del 4
paciente.
5
El usuario selecciona especialidad.
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

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

16

El usuario presiona
Programar cita

el

botn 17
18
19

20

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.

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
ri o del Si st2em
a

ri o del Si st3em
a

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
mis con las opciones seleccionadas por el paciente

Diagrama de Clases de Programar Cita Medica

Paci ente
+ cd_pac
: i nt
+ ti po_pac
: i nt
+ sexo
: Stri ng
+ cert
: Stri ng
+ edad
: i nt
+ nombres
: Stri ng
+ apel l i dos
: Stri ng
+ fec_nac
: Date
+ eci vi l
: Stri ng
+ correo
: Stri ng
+ cod_parent : i nt

Ci ta
+
+
+
+
+
+
+

id
: i nt
i d_paci ente : i nt
especi al i dad : Stri ng
doctor
: Stri ng
fecha
: Date
turno
: Stri ng
estado
: Stri ng

+
+
+
+
+

ProgramarCi ta() ()
El i mi nar ()
Mostrar ()
Actual i zar ()
Consul tar ()

1..*

()

+ Modi fi car ()

+
+
+
+

0..*

Parentesco
+ cod_parent : i nt
+ descri pci on : Stri ng

T i poPaci ente
+ codi go
: i nt
+ descri pci onti popaci ente : Stri ng

MostrarDatos ()
Veri fi carT i poPaci ente ()
BuscarT i poPaci ente ()
Val i darUsuari o

+ mostar ()

+ MostrarUsuari o
()
+ BuscarPaci ente ()
+ BuscarPaci enteF ()

Especi al i dad

Doctor
+ id
+ nomdre
+ apel l i do
+ cedul a

: Stri ng
: i nt

- id
: i nt
- nomdre : Stri ng
+ Nuevo ()
ar
+ Modi fi car ()
+ Mostar ()
ng

: Stri ng
: Stri ng

+ especi l i dad : i nt
+ ti po

: i nt

+ horari o

: i nt

+ Modi fi car ()
+ Mostar ()

CargaFami l i
+ nomdre

: Stri

+ apel l i do

+ Actual i zar ()
Stri ng

+ cedul afam : Stri

ng
+ cod_paren : i
nt

+ Nuevo ()
+ El i mi nar ()

0..*

T i poDoctores
ng
1

+ correo

: Stri

:i

cert

nt
+ id

: i nt
ng
+ descri pci on : Stri ng
nt
+ Nuevo ()
+ Modi fi car ()
+ El i mi nar
()
+ Mostar ()

+ sexo

: Stri

+ edad

:i

+ fecha_nac : Date
+ MostarDatos ()

1
Horari o

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

Centro de Computacin
Seccin de Programas y Proyectos
Diagrama de Secuencia Programar Cita
:
W:Val i darPaci ente

w:ci tas

Ci t a s

Paci ente

Do c t o r
da d

Espe ci al i

Horari o

Usuario del Sistema

Seleccionar programar cita
Ingresar cedula de identidad del paciente

Procesar

CargaPaciente( )

Mostrar Pantallas Para Programar cita

Seleccionar especialidad

Procesa

Muestra Nomdre de doctores

cargaEspecilidad( )
Activa

CargaDoctores( )

Seleccionar doctor
Procesa disponibilidad

Seleccionar turno

Muestra turno de doctor

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

CargaTurno( )

Pantallas Programar Cita

Pantalla 1/4. Selecciona Programar Cita Mdica

Pantalla 2/4. Validar Paciente

169

Pantallas Programar Cita

Pantalla 3/4. Programar Cita Medica

Pantalla 4/4. Cita Programada

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.

Curso Normal (Bsico)

El usuario selecciona la opcin 2
1
Consultar Citas del men de
citas.
3
El usuario selecciona la fecha. 4
5

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
ri o del Si
ste2m a

ri o del Si
ste3m a

ri o del Si
ste4m a

ri o del Si stem a

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.

Centro de Computacin
Seccin de Programas y Proyectos
Diagrama de Secuencia
W: Con su l t a rCi t a

Ci t a s

Usuari o del Si stem a

Sel ecci onar fecha
Consul tar Ci
tas
Program adas

Procesa
Presi onar "Consul tar Ci
tas"

M uestra Resul
tados

Sel ecci onar Edi

tar

Procesar
M ostar pantal l a para edi tar
datos

M odi fi
car

BuscaCi ta( )

Carga( )

Edi ta turno de l a consul

ta
Edi ta Fecha
Preci onael boton "Guardar"
Procesa

El i m i
nar

GuardarCi tas ( )

Procesar

Sel ecci onar "El i m i nar"

M ostrar m ensaj e de avi

so

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

173

El i m i narCi ta ( )

PANTALLAS

Pantalla 1/4. Selecciona Consultar Cita Programadas

Pantalla 1/4. Consulta de Cita Programadas

174

PANTALLAS

Pantalla 1/4. Modificar Cita Programadas

Pantalla 1/4. Eliminar Cita Programadas

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 Hist oria

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.
3
El usuario marca la casilla del paciente
que desea atender.
4
El usuario presiona el botn Aceptar. 5
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

Curso Normal (Bsico) continuacin

8
9
10

El usuario ingresa la informacin

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

El sistema muestra formulario de captura de

informacin relacionada a datos especficos del
paciente
El sistema valida los datos.
El sistema guarda los datos.

13

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
tipo de historia seleccionada con su respectivo
que se desea crear.
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.
18
El sistema guarda datos.
19
El sistema muestra el formulario completado.

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.

ri o del Si stem a

Diagrama de Clases

HistoriaGenerarInterna

DatosPermentesGenerarInterna

ControlColoscopio
+ id
: int
+ id_dp
: int
+ id_doctor : int
+ fecha
: Date
+ aa
: String
+ lugol
: String
+ nomdre : String
+ estado : String
+ Guardar ()
+ Mostar ()
+ Insertar ()

HistoriaGinecologica

+
+
+
+
+
+
+
+
+

id
id_ginecologica
id_doctor
motivo_consulta
efermedad_actual
alimentacion
t_paciente
d_evolucion
fecha

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

: int
: int
: int
: String
: String 1
: String
: String
: String
: Date

+ id
: int
+ id_dp
: int
+ telefono
: String
+ antecedentes
: String
+ habitos_psicobiologico : String
+ periodo_tiempo
: String

DatosPermanentesGinecologica
+
+
+
+

id
id_historia
antecedentes_c_o
antecedentes_g

+ inscripcion
+ indicacion
+ fecha

: int
: int
: String
: String

: String
: String
: Date

+ id
: int
+ id_doctor
: int
+ id_dp_general_interno : int
+ motivo_consulta
: String
+ enfermedad_actual
: String
+ diagnostico
: String
+ tratamiento_pac
: String
+ tension_arterial
: String
+ peso
: String
+ pulso
: String
: String
1 + temperatura
+ talla
: String
+ frecuencia_resp
: String
+ observaciones
: String
+ fecha
: Date
+ InsertarDatos ()
+ MostarDatos ()
+ GuardarDatos ()

+ MostrarDatosPermanentes ()
+ GuardarDatosPermanentes ()

+ MostrarDatosPermanentes ()
+ GuardarDatosPermanentes ()

1..*
1..*

DatosPermanentesPediatrica

+ id
: int
+ id_dp
: int
HistoriaPediatrica
+ id_doctor
: int
: int
Historias
1 + id
+ edad
: int
+ id_dp_pediatrica : int
1..* + sexo
: String
+ id
: int
+ id_doctor
: int
+ nomdrem
: String
+ cedula : String
+ t_arterial
: Date
+ edadm
: int
+ tipo : String
+ temperatura
: String
+ ocupacionm : String
+ peso
: String
+ VerificarHistoria ()
+ nombrep
: String
+ talla
: String
+ insertarHistoriaVacia ()
+ edadp
: String
+ pulso
: String
+ insertarHistoriaLlena ()
+ ocupacionp : String
+ f_respiratoria
: String
+ mostrarDatos ()
+ a_perinatales : String
+ f_cardiaca
: String
+ GuardarDatosPermanentes ()
+ complicacion : String
+
a_general
:
String
+ InsertarDatosPermanentes ()
+ alimentacion : String
+ orl
: String
+ medicamentos : String
+
cardiopulmonar
: String
+ a_personales : String
+ abdomen
: String
+ a_psicomotor : String
+ extremidades
: String
+ denticion
: String
+ neurologo
: String
1..*
+ a_familiar
: StringPuede ser:
+ fecha
: Date
+ fecha
: Date
DatosPermanentesOdontologica
+ MuestraDatos ()
+ MostrarDatosPermanentes ()
+
InsertarDatos
()
+ id
: int
+ GuardarDatosPermanentes ()
+ GuardarDatos ()
+ id_doctor : int
+ GuardarEsquemaImunuzacion ()
+ id_historia : int
+ MostarEsquemaImunuzacion ()
+ direccion : String
+ VerificarEsquemaImunuzacion ()
+ telefono : String
+ referencias : String
Tiene
+ edad
: String
Dentadura
+ e_general : String
1 + id
: int
+ piso_boca : String
+ id_dp
: int
+ carrillo
: String
+ id_posicion_dent : int
PosicionDentadura
+ lengua
: String
+ fechaq
: Date
+ paladar : String
: int
1..* + id
+ descripcion
: String
+ encias
: String
+ lado
: String
+ tratamiento
: String
+ protesis : String
+ posicion : String
+ observacion
: String
+ t_relizado : String
+ numero : int
+ MostrarDentadura ()
+ fecha
: Date
+ GuardarDentadura ()
+ MostarDatosPermantes ()
+ ActualizarDentadura ()
+ ActulizarHistoriaLlena ()
+ ComprobarDentadura ()
+ BuscarIDDientes ()

0..*

VacunaDosis
+
+
+
+

id_dp_pediatrica
id_vacuna
id_dosis
fecha

: int
: int
: int
: Date

1..*

1..*

Vacunas
- id
: int
- nomdre : String
+ Insertar ()
+ Guardar ()

Dosis
- id
: int
- nombre : String

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

+ Insertar ()
+ Guaradar ()
+ Mostar ()

Centro de Computacin
Seccin de Programas y Proyectos
Diagrama de Secuencia
Ci ta s

W: Hi sto ri a M ed i ca

Pa ci en t e

Hi sto ri a sM ed i ca s

Da t o sP e rm anen te sDe Hi sto ri a

H i s t o ri a

Usuari o del Si stema

Mostrar paci entes dell dii a
Sell ecci onar paci ente
Presii onar "Aceptar"

Procesar
CapturarPaci ente( )
Actii var
CargaT ii poDeHii storii a( )

Crear Hi stori
a
Medi ca

Ingresar datos en ell formull arii

o

Muestar formull arii o de hii storii a con datos dell paci ente
caragdo

Presii onar
"Guardar"

CargarFormull arii o
()
CargaFormull arii o( )

Procesar

GuardarDatos ( )
GeneraNumerodeHii storii a( )
Muestra Mensajj e "Se ha Creado Hii storii a Medii ca"

Incresar datos de consull ta

Procesa

Actii va datos de consull

ta

CargaDatosdeConsull ta( )

GuardaDatosdeConsull ta( )

Consul tar Hi stori

a
Medi ca

Muestra pantall ll a para rell ii zar busqueda

Introdusca C.I sii n programar ci ta
C.I

Procesa
CargaPaci ente( )
Actii va

Mestra hii storii a dell paci ente

CargaHii storii aMedii ca( )

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

179

PANTALLAS

Pantalla 1/8. Selecciona Crear Historia Mdica

Pantalla 2/8. Selecciona Historia Mdica

180

PANTALLAS

Pantalla 4/6. Historia Mdica Odontolgica

Pantalla 3/8. Selecciona el Paciente para atender

Pantalla 4/8. Historial de Consulta Mdica

PANTALLAS

Pantalla 5/8. Historia Mdica Ginecolgica

PANTALLAS

Pantalla 6/8. Historia Mdica Odontolgica

PANTALLAS

Pantalla 7/8. Historia Mdica Peditrica

PANTALLAS

Pantalla 8/8. Historia Mdica General O Interna

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.

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
doctor.

2.5

El usuario selecciona el nombre del 2.6

doctor.
El usuario selecciona especialidad.

El sistema muestra men con

especialidades asociadas al doctor.

El usuario
Guardar.

El sistema guarda datos de la boleta mdica.

2.7
2.8

selecciona

presiona

tipo de 2.4

el

botn 2.9

El sistema muestra men con los nombre de

los doctores de acuerdo al tipo de doctor
seleccionado.
las

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
2.9 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
Comentarios
1

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

Diagrama de Clases

BoletaPaciente

Boleta
+ id

: int

+
+
+
+
+

: String
: String
: String
: Date
: String

servicio
detalles
observaciones
fecha
cd_pac

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

Laboratorio
+ id_boleta : int
+ cd_pac : String
+ id
: int
1 + mostrar ()
+ buscar ()
+ guardar ()

+ id
: int
+ nombre : String
+ rif
: String
+ Mostrar ()
+ Buscar ()
+ Guardar ()

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

Centro de Computacin
Seccin de Programas y Proyectos
Diagrama de Secuencia
W: B o l e t a M ed i ca
e ta

B o l e t a P a ci
en t e

Bo l

Do t o re s

E spe ci a l i
da d

Labo ra t o ri o

Usua ri o del Si stem a

Sel ecci onar "Nueva Bol e ta"

Pro cesa r sel ecci n

CapturarSel ecci on ( )

M ostrar form ul ari o

Bol e ta de
Consul ta M edi
ca Externa

Sel ecci onar ti po de consul

ta

Sel ecci ona doctor

Procesa

CargarEspeci al i dad ( )

M ostrar l a especi al i da asoci ada al

doctor

Sel eci o na Especi al i dad

Crear Bol eta

M edi ca

Carg aDoctores ( )

Procesar
M ostrar nom bres de doctores del ti po sel ecci
onad o

In trod uce T i po de consul ta

Procesa
M ostrar no m b re d e l aboratori o sel ecci onado

Bol eta de
Laboratori o

Sel ecci ona Laboratori o

Sel eci ona Exam enes

In tro duce Observaci ones

Procesa
Presi onar "Gua rdar"

val i daBol etaPaci ente( )

Acti va

Gene rarNum eroDeBol eta (

)

Val i daDatos(
)
Al m acenaBol eta ( )

Im pri m i r Bol
eta

Sel ecci ona r "Im pri m i r"

Procesar Im presi n

Bol eta Im presa

Consul tar
Bol eta

In trod uce Nm e ro d e bol

etas

Procesar

Acti va

Val i da Datos( )

BuscarBol etaM edi ca (

)
M ostra bol
eta

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

189

CargaLaboratori o( )

PANTALLAS

Pantalla 1/6. Selecciona Crear Boleta Medica

Pantalla 2/6. Crear Boleta Mdica

190

PANTALLAS

Pantalla 3/6. Crear Boleta Para Consulta Externa

Pantalla 4/6. Crear Boleta Para Exmenes de Laboratorio

PANTALLAS

Pantalla 5/6. Boleta Mdica Para Imprimir

Pantalla 6/6. Buscar Boleta Mdica

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
El aborar Hi stori as Mdi cas

<<Incl ude>>
Condi ci on= Requi ere T ratami
ento
Punto de Extensi on= Veri fi car Hi stori
a
Emi ti r Reci pe Medi co

Usuari o del Si stema

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
de farmacia.
medicamento.
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

Curso Normal (Bsico) continuacin

El usuario presiona el
Aceptar
3.9
4
4.1
5

botn

El sistema carga el nombre del medicamento

3.10 seleccionado, presentacin y cantidad en la seccin
denominada Rp. del formulario del rcipe medico.

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

Para realizar la bsqueda de un rcipe

El usuario selecciona una fecha en el 9
Historial de Rcipes Mdicos.

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.

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.
9
Cuando el sistema muestra pantalla principal de rcipes mdicos, si no han creado rcipes en
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.

Diagrama de Clases
Reci pe
+
+
+
+
+
+

i ddoctor
: i nt
numero
: i nt
i ndi caci ones : Stri ng
fecha
: Date
paci ente
: Stri ng
estatus
: Stri ng

+
+
+
+

Mostar Reci pe ()
Mostar Reci pes ()
El i mi nar ()
Crear ()

Detal l esReci pe

1..*

+
+
+
+

numreci pe
rp
cant
id

: i nt
: Stri ng
: i nt
: i nt

+ Mostrar ()

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

Centro de Computacin
Seccin de Programas y Proyectos
Diagrama de Secuencia

M ed i ca m
en t o s

W:Re ci p e M ed i co

Re ci p e

De ta l l e sRe ci
pe

Hi sto ri a M ed i ca

Impresora
Usuari o de l Si stem a

M ostra r pantall ll a prii nci p all de reci pe s m edii cos

Procesar Sell ecci
on

Sell ecci on ar "Crea r Reci pe "

CapturarSell ecci on ( )

M ostra r form ull arii o de reci p e m

edii co

CapturarSell ecci on ( )
Hacer cl ii c en ca rga r m edii cam en to de farm
aci a

Procesar
M o strar m otor de busqued a

Ingresar nom b re de ll m edii cam ento

Cre ar Reci pe Carg a n d o M
edi cam en to de Farm aci a

Presii ona r "Bu scar"

Pro ce sa r Busqued a
BuscarM edii cam en to ( )
M ostra r resull tad o de m edii cam entos

Ing re sa r Cantii dad

M a rcar casii ll ll a "Ag reg ar a reci
pe"
CargaNom dreyPresentaci on ( )
Presii o nar "Ace ptar"
Procesar

Cre ar Nuevo
Reci pe

Envi ar no m bre y presentaci on d ell m edii cam

ento

GuardaM ed ii cam en to( )

Gua rda rDeta ll ll esReci

M ostra r form ull aci o n co n secci on d e Rp . com pll

etad a

p e( )
Ingresar Indii caci on es

In gresar Rp. e ii ndii caci on es

Presii o nar "Em ii tii r Reci p e"
Procesar

Vall ii da rDa tos ( )

Cre ar Reci p e Com n

Gen erarNum e ro ( )

Gu ard arDato s ( )
Asoci ar a

M ostra r reci pe com pll etado

Sell ecci on ar "Im prii m ii r"

Proce so Im prii m ii r
Reci pe Im preso

Im pri m i r
Reci pe

Consul tas
Reci pe

Sell ecci on ar fecha

Procesar

BuscarReci peM edii co ( )

M ostrarResull tado

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

All m acen arReci p e ( )

195

PANTALLAS

Pantalla 1/4. Emitir Rcipe despus de consulta

Pantalla 2/4. Emitir Rcipe con indicaciones normal

196

PANTALLAS

Pantalla 3/4. Cargar Medicamento de Farmacia

Pantalla 3/4. Bsqueda de Rcipe

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 Atenci on Mdi ca Especi l i zada

<<Exti ende>>
<<Exti ende>>

Factura Por Medi camento

Regi stro
Factura

Condi ci on = Soporte Val i

do
Punto de Extensi n = Val i dar Soporte
<<Exti ende>>

Conformar Facturas

<<Incl ude>>

Val i dar Usuari o

Val i dar Soporte

Usuari o del Si
stema

Regi strar Devol uci n de Factura

<<Exti ende>>

Condi ci on = Soporte no val i do/ Error en

factura
Punto de Extensi n = Val i dar 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.

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
1
2 debe ingresar la cedula del Paciente.
facturas.
El usuario ingresa la cedula del 4
3 paciente.
El usuario hace clic en la cedula 6 El sistema carga los datos del paciente y los
muestra en la pantalla.
5 correspondiente.
7 El sistema carga los tipos de registros.
8 El usuario selecciona que el tipo de
El sistema despliega los datos a llenar para
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
fecha
que
se
realizo
la
compra
y
su
8.5
8.6 el registro de factura por medicamento.
costo.
El usuario selecciona que el tipo de
El sistema muestra los datos a llenar para
9 factura a conformar por Atencin 9.1 factura por atencin mdica particular.
Medica Particular.
El usuario introduce los datos
El sistema carga todos los campos y realiza
correspondientes.
9.2
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

Curso Normal (Bsico) Para Devolucin de Factura

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.

3
4
5

El usuario ingresa exposicin 7

motivos
y
presiona
Guardar.
8

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.

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.

ri o del Si stem a

ri o del Si stem a

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.

Diagrama de Clases

T i poPaci ente
: i nt
+ cd_pac
: i nt
+ ti po_pac
: Stri ng
+ sexo
: Stri ng
+ nomdres
: Stri ng
+ apel l i dos
: Date
+ fec_nac
: Stri ng
+ eci vi l
: Stri ng
+ correo
: i nt
+ cert
: i nt
+ edad
: i nt
+ cod_parent
+ Mostar ()
+
+
+
+
+
+

Veri fi carT i poPaci ente ()

BuscarT i poPaci ente ()
Val i darUsuari o ()
MostrarUsuari o ()
BuscarPaci ente ()
BuscarPaci enteF ()
1..*

T i poDoctor
+ id

: i nt

Facturas
+ Id
+ Cedul a
+ T i poPaci
ente
+ T i poMedi co
+ T i poDoctor
+ Especi l i dad
+ Ffactura
+ estatus

:
:
:
:
:
:
:

i nt
Stri ng
i nt
i nt
Stri ng
i nt
Date

+ desri pci on : Stri ng

0..*

+
+
+
+
1

: fl oat

+ MostrarReci pe
()
+ Crear ()
+ Buscar ()

FacturaMedi camento
: i nt
+ Id
: Stri ng
+ cedul a
: i nt
+ ti podoctor
: i nt
+ ti popaci
: Date
ente
: Stri ng
+ fecha
: Stri ng
+ estatus
: Stri ng
+ medi co
: Stri ng
+ especi al i
: Stri ng
dad

Nuevo ()
Modi fi car
() Mostrar ()
El i mi nar
()

EstadoFactura

+
+
+
+

id
: i nt
nomdre : Stri ng
Modi fi car ()
Mostrar ()

FacturaAtenci onParti cul ar

+ Id
: i nt
+ cedul a
: Stri ng
+ ti popaci ente : i nt
+ ffecha
: Date
+ estatus
: Stri ng
+ medi co
: Stri ng
+ especi al i dad : Stri ng
+ val or
: Stri ng
+ seri al
: Stri ng
+ observaci ones : Stri ng

+ val or
+ seri al
+ observaci ones : Stri ng
+ nreci pe
: i nt

+ Mostrar ()

+ Mostrar ()

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

Centro de Computacin
Seccin de Programas y Proyectos
Diagrama de Secuencia para el Registro de Factura
W: B u sca rP a ci e n t e
da d Do ct o r

Reg i st ro Fa ct u ra s

Do c t o re s

E spe ci a l i
da d

E spe ci a l i

P a ci en t e

Re ci p e

Usuari o d el Si stem a
Sell ecci ona r " Nuevo Regii
stro"

Procesar

Actii va
Captu ra rSell ecci o n (
)

Ing re sa r cedull a de ii de ntii d ad de ll pa ci

ente

M u estra pantall ll a d e nu evo regii stro con ll os da tos de ll paci en te

Cargar Paci e nte ( )

CargaT ii p o Do ctore s( )

Pro cesa

Sell ecci o ne tii po d e Factura "M edii cam

ento"

M ostar T ii p o de
Doctores
CargaNom b res ( )
Sell ecci on e ell tii p o de m edii co que orii gii n o ll a
com pra

Proce sa
M ostar nom b re de doctores
Ca rg ar Especi all ii da d
()

Procesar
Sell ecci on e nom dre dell
doctor

M ostra r Especi ll ii
dad

Procesar
Ca rg ar Reci p e ( )

M ostra r reci pe

Po r "M edi cam

entos"

In gresar num ero d e reci pe

Procesar
Ing re sa r dato s de ll a
factura

Vall ii darPaci e nte (

)

Presii ona r " Guardar"

Proce sa

Ca rg aDato s( )
GuardarRegii stro ( )
M o strar m ensajj e de factura procesada

Sell ecci on tii p o de fa ctu ra "Atenci on M edii ca Partii cull ar"

Sell ecci o n tii po d e factura "Atenci o n M edii ca
S
Partii cull ar"

Procesar

Fii ll trarT ii po ( )

M ostar Nom bre

In grese nom b re d ell

Doctor

CargarEspeci all ii d a d ( )

Procesar
M ostra r Nom bres

Po r "Atenci n M edi ca
Parti cul ar"

In gresar serii all de

Factura
In gresar Fecha factura
Procesar

Ingresar co sto de factura

Preci on ar" Guardar"

Actii va

GuardarRegii stro (
)
GuardarSta tus ( )
M o strar m ensajj e de notii fii caci n

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

Vall ii darPaci e nte ( )

BuscarReci p e ( )

202

Pantallas de Registro de Factura

Pantalla 1/4. Seleccin de Nueva Factura

Pantalla 2/4. Seleccin de Factura Medicamento

2032
03

Pantallas de Registro de Factura

Pantalla 3/4. Seleccin de Factura Atencin Mdica Particular

Pantalla 4/4. Factura Registrada

Centro de Computacin
Seccin de Programas y Proyectos
Diagrama de Secuencia para la Devolucin de Factura
W: Fa ct u ra s

Fa ct u ra s

Pa ci en te

Usuari o del Si stem a

Sel ecci onar "Devol uci n de Factura"

Regi stra r Devol uci n

de
Factura

Procesar
M ostrar Pantal l a de Devol uci on de
Facutura

Ingre sar cedul a de i denti da d del paci

ente

CapturarSel ecci on (
)

Procesar

CargarPaci en te ( )

M ostrar paci
en te

Sel ecci onar facturas "Conform ada s po r M edi cam

ento"

Sel eci onar Factura

Procesar

Procesar
Regi strar Devol uci n
de
Factura Por
M edi cam ento

Ingre sar observaci

ones

Cargar Sel ecci on ( )

M ostar Sel ecci

on
Cargar Form ul ari
o

M ostar Form ul ari

o

Presi onar "Aceptarr"

Procesar

Val i dar Regi stro (

) Asi gnarStatus ( )

Noti fi ca que l os Resul tad os ha n si do

Guardados

Sel eci onar Facturas Por "Aten ci on M di ca Parti cul

ar"

Sel eci onar Factura

Regi stra r Devol uci n

de Factura Por Atenci
on M di ca Parti cul ar

Pul sar
"Aceptar"

Procesar

Cargar Sel ecci on ( )

M ostar Sel ecci

on

Procesar

Val i dar Regi stro ( )

Asi gna r Stats ( )

Noti fi car qu e l os Resul tados ha n si do
Gua rdados

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

205

Pantallas de Devolucin de Factura

Pantalla 1/4. Seleccin de Status Factura

Pantalla 2/4. Conformar Factura

206

Pantallas de Devolucin de Factura

Pantalla 3/4. Conformar Factura

Pantalla 3/4. Devolucin de Factura

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

Val i dar Usuari o

<<Incl ude>>
Consul tar Facturas
Usuari o del Si
stema

Facturas Procesando
<<Incl ude>>

Regi stro de Facturas

Facturas Conformadas

Facturas Devuel tas

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

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.

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.

ri o del Si stem a

Centro de Computacin
Seccin de Programas y Proyectos
Diagrama de Secuencia para el consulta de Factura
W:Fa ctu ra s

Fa ctu ra s

P a ci en te

Usuario del Sistema

Seleciona"Consultar Factura"

Procesar
Mostrar pantalla para realizar busqueda

Ingresar cedula de identidad del paciente

Presionar "Buscar"

CapturaSeleccion ( )

Procesar cedula de identidad

CargaPaciente( )

Mostrar Paciente

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

Procesar

CargafacturadeAtencion Medica Particular( )

Mostar factura

Seleccionar factura por "Medicamento"

Procesa

Por "Medicamento"

CargafacturadeMedicamento( )

Muestra Factura

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

210

Pantallas de Consultar Factura

Pantalla 1/3. Seleccin Consultar Factura

Pantalla 2/3. Consultar Factura Por Medicamentos

211

Caso de Uso
Autor

Control de Medicamento
CU-011
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 principal
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

Real i zar Manteni mi ento de Medi camento

Condi ci on =Actual i zar medi
camento
Punto de Extensi on = Veri fi car ti po de
control

<< Exti ende>>

Control ar Medi
camentos
Usuari o del Si
stema

<< Incl ude>>

Val i dar Usuari o

Veri fi car ti po de
control

<< Exti ende>>

Regi strar Sal i da Eventual

Condi ci on = Sumi ni strar medi

camento
Punto de Extensi on = Veri fi car ti po de
control

Regi strar Sal i

da
Veri fi car ti po
de sal i da
Regi strar Sal i da por Reci pe

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.

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
5
6
El sistema muestra resultado de la
bsqueda con opciones de actualizacin
7
Agregar Medicamento
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
medicamento.
Aceptar
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.
9
Eliminar Medicamento
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

Curso Normal (Bsico) Para la Salida de Medicamento

El usuario selecciona la opcin
El sistema muestra un formulario donde se
REGISTRAR
SALIDA
1
1 debe ingresar la cedula del Paciente.
EVENTUAL del men principal
de Medicamentos
2 El usuario hace clic en la cedula 2.1 El sistema muestra pantalla de salida
eventual de medicamento con los datos del
correspondiente.
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
medicamento
y
presiona
el
botn
2.4
2.5 el medicamento a despachar para que el
usuario seleccione cantidad y motivo de
Aceptar
despacho.
El usuario selecciona cantidad ,
El sistema carga seleccin y notifica la
motivo
de
despacho
y
presiona
el
2.6
2.7 salida del medicamento.
botn Aceptar
El usuario hace clic en el botn
El sistema muestra un formulario donde se
SALIDA 3.1 debe ingresar la cedula del Paciente.
3 REGISTRAR
RCIPE
3.2 El usuario hace clic en la cedula 3.3 El sistema carga los datos del paciente y
muestra los registros de rcipes asociados al
correspondiente.
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
3.6 Aceptar
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

ri o del Si stem a

Con este proceso se puede mantener un control de los medicamentos qu

despachan y a que paciente se lo suministran.

Diagrama de Clases

SalidaMedicamento

Medicamento
+
+
+
+
+

num
nombre
presentacion
cant
fecha_v

: int
: String
: String
: int
: Date

Recipe
+
+
+
+
+
+

numero
indicaciones
fecha
paciente
estatus
doctor

: int
: String
: Date
: String
: String
: int

id
cedula
medicamento
fecha

: int
: String
: int
: Date

+ crear ()

+ Crear ()
+ Modificar ()
+ Eliminar ()
1..*

+
+
+
+

1..*
MotivoDespacho
+ id
: int
+ nomdre : String
+ Crear ()
+ Modificar ()
+ Eliminar ()

+ MostrarRecipe ()
+ MostrarRecipes ()
+ Eliminar ()
Diagrama 39: Diagrama de clase Control de Medicamento. Fuente: Autor 2010

Centro de Computacin
Seccin de Programas y Proyectos
Diagrama de Secuencia para el Mantenimiento de Medicamento
W: Fa rm a ci a

M ed i ca m en t o s

Usuari o de l Si stem a
Sel ecci ona r "M anteni m i en to d e M edi cam
entos"

Procesar
M o strar pantal l a pa ra e l m anteni m i en to d e m edi cam
entos

Buscar
M edi cam ento

CapturarSel ecci o n ( )

In gre sa r Nom b re de l M ed i cam

ento

Presi on a r " Bu sca r"

Pro ce sa r Busqueda

BuscarM ed i cam en to ( )

M o strar resul tados

M a rca r l a opci o n " Ag re ga r Nu e vo M ed i cam

en to" Presi o nar "Aceptar"

Procesar
M ostra r form ul ari o pa ra i ng re sa r m edi cam en to exi
stente

CapturarSel ecci on ( )

In gre sa r Canti dad

Ag rega r nuevo
m edi cam
ento

Ing re sa r Fe ch a d e Venci m i
ento
Presi ona r "Guardar"

El i m i
na r
M edi cam ento

M a rca r l a opci o n "El i m i n a r"

Procesa
M u estra m ensaj e e n pantal l a d e M edi cam e nto
Agregado

Procesar

GuardarNuevoM edi cam en to( )

El i m i naM ed i cam en to( )

M ostra r pantal l a pri nci pa l d e con tro l d e m edi cam

entos

Presi ona r el b oton "M odi fi ca rr"

Procesar

Ca rga Da to sDe M ed i cam en to(

)

M ostra r pantal l a p ara m od i fi ca r m edi cam entos

M odi fi
car

Ing re sa Canti dad

Ing re sa Fe ch a d e venci m i
ento
Presi ona r "Aceptar"

Procesa
M o strar pantal l a pri nci pal d e contro l d e m edi cam
en tos

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

Gua rda M odi fi caci on ( )

216

Pantallas de Mantenimiento de Medicamento

Pantalla 1/4. Seleccin mantenimiento de Medicamento

Pantalla 2/4. Bsqueda de Medicamento

217

Pantallas de Mantenimiento de Medicamento

Pantalla 3/4. Ingresar Medicamento Nuevo

Pantalla 4/4.Modificar Medicamento Existente

Centro de Computacin
Seccin de Programas y Proyectos
Diagrama de Secuencia para la salida de Medicamento
W:M ed i cam en to s
en to

M ed i ca m

Pa ci en te

Re ci p e

Usuari o del Si stema

Sel ecci onar "Regi strar Sal i da
Eventual "

Procesar
CapturarSel ecci on ( )
Mostrar pantal l a para real i zar busqueda

Regi strar Sal i

da
Eventual

Ingresar cedul a de i denti dad del paci

ente

Procesar
CargarPaci ente ( )
Mostrar datos de paci ente en l a pantal l a de " sal i da
eventual "
Procesar

Ingresar nomdre del medi

camento
Muestra pantal l a con sel ecci on de medi
camento
Pul sar " Aceptar"

CargarMedi camento ( )

Procesar
CargaSal i daDeMedi camento( )

Mostra pantal l a " REGIST RO DE SALIDA"

Sel ecci onar "Regi strar Sal i da Por Reci

pe"

CargarSel ecci on ( )

Procesar
Mostrar pantal l a para real i zar
busqueda

Regi strar sal i da

por reci pe

Ingresar cedul a de i denti dad del paci ente

Procesar

CargarDatosdePaci ente (
) Procesa

Mostrar Reci pes del Paci

ente
Sel ecci onar Reci pe

Procesar
Muestra Reci pe l l
eno

Presi onar "Aceptar"

CargaRreci pedel Paci ente ( )

Procesar

CargarMedi camentosdeReci pe (
)

Mostar pantal l a "sal i da por Reci

pe"

Diagrama 41: Diagrama. Secuencia salida de medicamento. Fuente: Autor 2010

Val i darRegi stro ( )

219

Pantallas de Salida de Medicamento

Pantalla 1/6.Registar Salida

eventual de Medicamento

Pantalla 2/6.Buscar Medicamento

220

Pantallas de Salida de Medicamento

Pantalla 3/6.Agregar Medicamento de Farmacia

Pantalla 4/6.Registar Salida de Medicamento Por Rcipe

Pantallas de Salida de Medicamento

Pantalla 5/6.Despachar Medicamentos de Rcipe

Pantalla 6/6.Verificar Medicamentos Rcipe

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

Val i dar Usuari o

<<Incl ude>>

Generar Reporte

Usuari o del Si stema

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.

Curso Normal (Bsico)

El caso de uso comienza cuando
1 el usuario selecciona la opcin 2
Generar Reportes
3
El usuario selecciona el tipo de
reporte. (Facturas Conformadas,
Citas,
Rcipes,
Emitidos
4 Boletas, Emitidas Registro de 5
Salida de Medicamento.)
El usuario seleccionar el criterio
6 bajo el cual efectuar la bsqueda
El usuario presiona el botn
7 Generar Reporte.
8
9
Presionar el botn Imprimir
10 Reporte
11

El sistema captura la seleccin

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

a lo seleccionado.
El sistema muestra el registro.
El sistema imprime reporte

Tabla 40: Curso bsico de eventos generar reporte. Fuente: auto 2010

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 Este caso de uso permite brindarles a los usuarios el acceso a los
reportes que genera el sistema, presentndoles informacin relevante
a
sobre su gestin.

ri o del Si stem

Centro de Computacin
Seccin de Programas y Proyectos
Diagrama de Secuencia

Bo l e
ta

Do ct o re
s

Re ci p e

Fa ct u ra s

M e d i ca m e n t o

Ci t a s

W: R e p o r t e s
Im p re so ra
Usu a ri o d e l S i ste
ma

Se l e cci o n a r re p o rte d e b o l e t a m e d
i ca

Se l e cci o n a r se rvi ci
o
Re p o rte d e
b o l e ta s m e d i
ca s e m i ti d
as

M u e st ra se l e cci o n

"

M a rca r " Aso ci a r Pa ci e n

te "
In g re sa r ce d u l a d e Id e n ti d a d d e l p a ci e
n te

Se l e cci o n a r fe ch a y p re si o n a r e l b o to n " Ge n e ra r Re p
o rte "

Pro ce sa
r

Efe ctu a rBu sq u e d a ( )

M o stra r re su l ta d o d e b o l e ta s se g u n cri te ri o d e b u sq u e d a

Se l e cci o n a r re p o rte d e re ci p e m e d i co
M u e st ra se l e cci o n
M a rca r " Aso ci a r Do cto r"

Pro ce sa r

Re p o rte d e Re ci p e
s
Em i ti d o s

Ca rg a rNo m b re s ( )

M o stra r n o m b re s d e d o cto
re s
M a rca r " Aso ci a r a l Pa ci e n te "
Efe ctu a rBu sq u e d a ( )
Se l e cci o n a r fe ch a y p re si o n a r " Ge n e ra r Re p o rte "

Pro ce sa r
M o stra r re su l ta d o d e re ci p e s

Se l e cci o n a r re p o rte d e fa ctu ra s co n fo rm a d a s

In g re sa r ce d u l a d e Id e n ti d a d d e l p a ci e
n te
Re p o rte d e fa ctu
ra s co n fo rm a d
as

M o stra rSe l e cci o n (

)

Se l e cci o n a ti p o d e Fa ctu
ra

Pro ce sa
Ca rg a T i p o d e Fa ctu ra ( )
Acti va ti p o d e fa ctu
ra

Pro ce sa r

Pre si o n a r e l b o to n " Ge n e ra r Re p o rte "

Efe ctu a rBu sq u e d a ( )

M o stra r re su l ta d o d e fa ctu ra s co n fo rm a d a s

Se l e cci o n a r re p o rte d e m e d i ca m e n to s su m i n i n i stra d o s

M o stra rSe l e cci o n (
)
Re p o rte Sa l i d a d
e m e d i ca m e n
to s

In g re sa r ce d u l a d e Id e n ti d a d d e l p a ci e
n te
In g re sa r n o m b re d e l M e d i ca m e
n to
E l e g i r cri te ri o d e b u sq u e
da
M o stra r re su l ta d o d e m e d i ca m e n to s su m i n i
stra d o s

Pre si o n a r e l b o to n " Ge n e ra r Re p o rte "

Acti va r

Se l e cci o n a r re p o rte d e ci ta s
Se l e cci o n a r ti p o d e ci
ta
Re p o rte d e Ci ta
s

M a rca r " Aso ci a r Do cto

r"

Se l e cci o n a r Do cto
r
Se l e cci o n a r fe ch a y p re si o n a r " Ge n e ra r Re p
o rte "

Efe ctu a rBu sq u e d a ( )

M o stra rSe l e cci o n ( )

Ca rg a rNo m b re
Pro ce sa
r

s( ) Pro ce

M o stra r n o m b re s d e d o cto
re s
sa r

M o stra r re su l ta d o d e Ci ta s
Efe ctu a rBu sq u e d a ( )

Pre si o n a r " Im p ri m i r Re p o
rte "

Pro ce sa r Im p re si o
n

Im p ri m i r re p o
rte

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

PANTALLAS

Pantalla 4/4. Reporte de Medicamentos Suministrados

Pantalla 3/4. Seleccionar Criterios de Bsqueda

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.
X=1
B = nmero de funciones descritas en la especificacin
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

3.ENTENDIBILIDAD

Nombre: Funciones evidentes

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.

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
Entre ms cercano a 1,
X = 11/15
usuario
mejor.
X = 0,733333
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
4. COMPORTAMIENTO
EN EL TIEMPO
Nombre: Tiempo de respuesta

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.

Mtodo de aplicacin: Evaluar la eficiencia de las

Estimar el tiempo de respuesta basado en ello. Puede medirse:

llamadas

al

SO

la

aplicacin.

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

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

Nombre: Conformidad de transportabilidad

Propsito: Qu tan conforme es la transportabilidad del

producto con regulaciones, estndares y convenciones
aplicables.

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
completa.
B = total de artculos que requieren conformidad
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

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

5.3 ETAPA III PROCESO DE

CONSTRUCCIN, GESTIN Y
SOPORTE

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

Versin Descripcin
1.0
Versin preliminar

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.
2. Diseo Arquitectnico
El producto a desarrollar est definido bajo la siguiente arquitectura:

Figura 33: Arquitectura del sistema. Fuente: autor 2010.

232

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
Pagui nasModul os
- cod_pag
Usuari o
+
+
+
+
+
+
+
+
+
+
+

nombre : Stri ng
apel l i do : Stri ng
cedul a
: i nt
usuari o : Stri ng
ni vel
: i nt
cl ave
: Stri ng
cod_usu : i nt
di reci on : Stri ng
emai l
: Stri ng
cod_sta : i nt
tel efono : Stri ng

+
+

Val i dar ()
Insertar ()
El i mi nar ()
Mostar ()
Actul i zar ()

Modul os

- cod_mod

Modul osUsuari os

- descri pci on : Stri

ng

: i nt
- cod_usu

Ni vel DeAcceso
1

+ ni vel
: i nt
+ descri pci on : Stri ng
- el i mi nar ()
+ i ngresar ()

- cod_mod : i nt
- id
1..*

- el i mi nar
()
+ i ngresar
()

: i nt

: i nt

1..*

El i mi nar ()

+ Insertar ()
+ Actual i zar
()
+ Edi tar ()

1..*

: i nt
Pagui nasUsuari o

- descri pci on : i
nt
- url
: i nt
- cod_mod
: i nt
- cod_ti po

- cod_usu : i nt
- cod_pag : i nt

: i nt

- id

: i nt

-() El i mi nar
+ Insertar ()
+ Actual i zar
()
+ Edi tar ()

Diagrama 44: Diagrama de clase usuario. Fuente: Autor 2010

1..*

- El i mi nar ()
+ Insertar ()

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:

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).

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

Clases Colaboradoras
BoletaPaciente
Doctores
Especilidad
Laboratorios

Figura 39: Tarjeta CRC Boleta. Fuente: Autor (2010).

Nombre de la Clase
Recipe
Responsabilidades
Crear y almacenar rcipe medico
Consultar rcipe medico
Cargar medicamentos
Procesar impresin de rcipe
Identificar status del rcipe

Clases Colaboradoras
Paciente
DetallesRecipe

Figura 40: Tarjeta CRC Rcipe. Fuente: Autor (2008).

Nombre de la Clase
DpHistoria
Responsabilidades
Cargar tipo de historia

Clases Colaboradoras
DpGeneralInterna
DpOdontologica
DpGinecologiaObstetricia
DpPediatria

Figura 41: Tarjeta CRC DPHistoria. Fuente: Autor (2008).

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.
<HTTPS>

Usuarios del Servicio Medico

EXPLORADOR WEB

SERVICIO WED

<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).

2. Diseo de la base de Datos

1.1 Diseo conceptual de Usuarios
cod_mod
Modul osUsuari os

cod_usu

ni vel

Ni vel
DeAcceso

Associ ati
on_29

Integer

Modul os
Integer

Associ ati
on_30

descri pci on Vari abl e characters (254)

cod_mod Integer
id
Integer

Integer
descri pci on Vari abl e characters (254)
Associ ati on_31
(D)
Associ ati on_28
Pagui nasModul os
Usuari o
nombre Vari abl e characters
(254)
apel l i do Vari abl e characters
(254)
cedul a Integer
usuari
Vari abl e characters
o ni vel (254) Integer
cl ave
Vari abl e characters
(254)
cod_usu Integer
di reci on Vari abl e characters (254)
emai l
Vari abl e characters (254)
cod_sta Integer
tel efono Vari abl e characters (254)

cod_pag

Integer

descri pci on Integer

url

Integer

cod_mod
cod_ti po

Integer
Integer

Pagui nasUsuari o

Associ ati on_38

cod_usu Integer
cod_pag Integer
id
Integer

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)

1.3 Diseo Relacional De Usuario

Usuari o nombre
varchar(254)
apel l i do varchar(254)
cedul a i nteger
usuari o varchar(254)
ni vel
i nteger
clave
varchar(254
)
cod_usu i nteger
di recion varchar(254)
emai l
varchar(254)
cod_sta i
nteger
tel efono varchar(254)

Pagui nasModul os
cod_pag
Modul os
cod_mod i
nteger
descri pcion varchar(254)

FK_USUARIO_ASSOCIAT
I_NIVELDEA

FK_PAGUINAS_ASSOCIAT
I_MODULOS

i nteger

descri pcion i nteger

url
i nteger
cod_mod i nteger
cod_ti po

i nteger

FK_MODULOSU_ASSOCIAT I_NIVELDEA

Ni vel
DeAcce
ni vel

so i
nteger
FK_PAGUINAS_ASSOCIAT I_PAGUINAS

descri pcion varchar(254)

FK_MODULOS_ASSOCIAT
I_MODULOSU
Modul osUsuari

Pagui nasUsuari
o cod_usu i

os cod_usu i

nteger
cod_pag i nteger

nteger
cod_mod i nteger
id
i nteger

id

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)

i nteger

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

UNUVERSISDAD DE ORIENTE
NUCLEO MONAGAS
CENNTRO DE COMPUTACION
TODOS LOS DERECHOS RESERVADO

5.4 ETAPA IV.

IMPLANTACIN DEL SISTEMA

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

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:

Especificacin
Caso de Prueba
Descripcin

01
Boleta Medica

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
Se ingresa al sistema bajo la opcin de usuario y en el men de la aplicacin se ingresa a crear
Descripcin
boleta.
La nica condicin es que el usuario est registrado en el sistema para poder
Condiciones de Ejecucin
acceder al mismo y el sistema mostrar la interfaz de boletas con sus respectivas
opciones (Nueva boleta,buscar).
Entrada
Se secciona de un alista desplegable el tipo de
Se introduce el nombre de usuario en el 7
consulta por: Doctor Por Servicios
1 campo nombre de usuario.
Se introduce la contrasea campo clave de 8
Se secciona de un alista desplegable el tipo de
servicio: Gustavo Brazon
2 acceso.
3 Pulsar el botn Ingresar.
9
El sistema carga y muestra su especialidad
El sistema muestra en pantalla un campo vaco
para ingresa observaciones de la boleta.
4 Se introduce C.I del paciente.
10
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.
regresa a la pantalla anterior para crear o
12
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
Descripcin
Se ingresa al sistema bajo la opcin de usuario y en el men de la aplicacin se ingresa a
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.
Resultado Esperado
El sistema busca una boleta Medica correctamente
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.

Especificacin
Caso de Prueba

02
Administracin Motivo de Despacho

Este
artefacto
abarca
el
conjunto de pruebas realizadas
sobre
el
mantenimiento Pruebas
Motivo de Despacho.
Efectuadas

Descripcin

Crear Motivo despacho

Editar Motivo despacho
La prueba se realizara partiendo del
formulario de entrada de la
aplicacin.

1.Crear Motivo Despacho

Se ingresa al sistema bajo la opcin de usuario y en el men de la aplicacin se ingresa
Descripcin 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.
Seleccionamos Motivo de Despacho
Se introduce el nombre de usuario en el 7
Entrada
1
2
3

campo nombre de usuario.

Se introduce la contrasea campo clave
de acceso.
Pulsar el botn Ingresar.

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.

El sistema permite el ingreso al sistema

con los privilegios de usuario.
10
Seleccionamos
Realizar
en
el
men 11
5 Mantenimiento
mantenimiento.
El sistema muestra una lista de los
El sistema muestra mensaje de que el motivo
de despacha ha sido registrado.
6 mantenimientos disponibles.
12
Resultado Esperado
El sistema crea un nuevo motivo de despacho.
Evaluacin de la Prueba Prueba superada con xito
4

2. Editar Motivo Despacho

El sistema mostrar la interfaz de mantenimiento correspondiente a Motivo de
Descripcin

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
10

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

11
12

El sistema emite un mensaje de que el

motivo de despacho ha sido actualizado.

El sistema modifica el motivo de despacho seleccionado.

Resultado Esperado
Evaluacin de la Prueba
Prueba superada con xito.
Observacin: El motivo despacho se realiza para sacar un medicamento del departamento.

Tabla 48: Especificacin de caso de pruebas Motivo Despacho. Fuente: autor 2010

Especificacin
Caso de Prueba

Descripcin

03
Administrar Laboratorio

Este artefacto abarca el conjunto de

pruebas
realizadas
sobre
el
mantenimiento Laboratorios.

Pruebas
Efectuadas

Agregar Laboratorio
Modificar Laboratorio La
prueba se realizara
partiendo del formulario de
entrada de la aplicacin.

1.Agregar Laboratorio
Se ingresa al sistema bajo la opcin de usuario y en el men de la aplicacin se
Descripcin 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).
La nica condicin es que el administrador est registrado en el sistema
Condiciones de Ejecucin
para poder acceder al mismo.
Seleccionamos Laboratorio
Se introduce el nombre de usuario en el 7
Entrada
1
2

campo nombre de usuario.

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
Descripcin
con sus respectivas opciones (Agregar Nuevo, Modificar).
La nica condicin es que el administrador est registrado en el sistema
Condiciones de Ejecucin
para poder acceder al mismo.
Entrada 1 Se introduce el nombre de usuario en el 7 Seleccionamos Laboratorio.
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
1
0

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

1
1
1
2

El sistema emite un mensaje de que el

Laboratorio ha sido actualizado.

El sistema modifica el Laboratorio seleccionado.

Resultado Esperado
Evaluacin de la Prueba
Prueba superada con xito.

Tabla 49: Especificacin de caso de pruebas Laboratorio. Fuente: autor 2010

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

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.

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.

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.

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.

2502
50

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.

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

Costo
Valor (Bs. F.)

Hardware

0 Bs. F

Software

0 Bs. F

Total costos de equipos y herramientas:

0 Bs. F.

Costos de Infraestructura

Valor (Bs. F.)

Sala de trabajo

0 Bs. F.

Mobiliario

0 Bs. F.

Total costos de infraestructura:

0 Bs. F.

Tabla 50: Costos de Materiales (1/2). Fuente: autor 2010

Concepto

Costo

Costos de Personal

Valor (Bs. F.)

Analista de Sistema

0 Bs. F.

Total costos del personal:

0 Bs.F.

Costos de Adiestramientos

Valor (Bs. F.)

Taller GRAY WATCH

0 Bs. F.

Cuso UML

0 Bs. F.

Curso de PHP

0 Bs. F.

Curso de Macromedia Dreamweaver

0 Bs. F.

Total costos de adiestramientos:

0 Bs. F.

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)

Valor (Bs. F.)

350 Bs. F.
80 Bs. F.
170 Bs. F.
50 Bs. F
600 Bs. F

Lapiceros (15 unidades x 4 Bs.F.)

60 Bs. F

Carpetas ( 30 unidades x 2.5 Bs. F)

75 Bs. F

Otros

400 Bs. F.

Total costos de materiales:

1785 Bs. F.

Total Costos de Produccin:

1785 Bs. F.

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.

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

Tarea
Generar historia
Peditrica.

0.6 h/h

0.1 h/h

0.5 h/h

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.

Tarea
Generar Reportes

Horas Hombres empleadas

Sistema
Sistema Actual
Beneficios
Pasado
14 h/h
0.05 h/h
13,95 h/h

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:

Cant.
Papel
Evento
Crear historias
8
medicas en un
Resmas
el ao.
Crear boletas
8
medicas en un
Resmas
ao.

Costo de resmas de Papel

Sistema
Sistema
Cant.Papel
Pasado
Actual

Beneficios

400 Bsf

----

----

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.

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

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
control de estudios

del rea de servicios mdicos, con el sub.-sistema de

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.
a
(6 . 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.