Teisis Lolimarcedeño PDF

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: Ing. Jess Chaparro
Tutor Laboral: Ing. Rosngela Garca
Maturn, Octubre de 2010

NCLEO DE MONAGAS
INGENIERA DE SISTEMAS
COMISIN DE TRABAJOS DE GRADO
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
NCLEO DE MONAGAS
INGENIERA DE SISTEMAS
COMISIN DE TRABAJOS DE GRADO
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
oriente ncleo Monagas, considero que dicho trabajo rene los requerimientos y
mritos suficientes para ser sometido a la evaluacin por parte del jurado examinador.
En la ciudad de Maturn a los diez das del mes de enero de dos mil once
Ing. Jess Chaparro

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

mejor mam, gracias por sus cuidados.
Lolimar D.Cedeo M.
iv
AGRADECIMIENTOS
Mi tesis la dedico a mi padre Jess Arvalo Cedeo (), jams pens que
cuando llegara este momento no estaras aqu, que tristeza, me siento realizada mas
no feliz, pues sin ti la dicha no es completa Slo me conforta saber que ests en el
cielo, en el reino de Dios, donde me cuidas y me proteges. Espero que ests
sumamente feliz y muy orgulloso de m.
T sabes que ests presente aqu, en el lugar donde siempre te encontrar y en
donde siempre puedo pedirte un consejo, un abrazo o una mano, en el centro de mi
corazn
Lolimar D.Cedeo M.
v
NCLEO DE MONAGAS
INGENIERIA DE SISTEMAS
COMISIN DE TRABAJO DE GRADO
Autor: Cedeo M. Lolimar

Tutor Acadmico: Ing. Jess Chaparro
IMPLEMENTACIN DE UN SISTEMA AUTOMATIZADO QUE OPTIMICE LA GESTIN

DE LOS PROCESOS ADMINISTRATIVOS DEL REA SERVICIOS MDICOS DE LA
UNIVERSIDAD DE ORIENTE NCLEO MONAGAS
RESUMEN
El presente trabajo de investigacin tiene como propsito principal implementar un

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

ACTA DE EVALUACIN ................................................................................... iii
DEDICATORIA .................................................................................................... iv
AGRADECIMIENTOS .......................................................................................... v
RESUMEN............................................................................................................. vi
INDICE GENERAL.............................................................................................. vii
LISTA DE FIGURAS ............................................................................................. x
LISTA DE TABLAS .............................................................................................. x
LISTA DE DIAGRAMAS ................................................................................... xiv
INTRODUCCIN .................................................................................................. 1
CAPITULO I........................................................................................................... 3
CONTEXTO ORGANIZACIONAL ...................................................................... 3
1.1. Resea Histrica de la Universidad de Oriente, Ncleo Monagas. ............. 3
1.1.1. Misin ................................................................................................... 3
1.1.2. Visin .................................................................................................... 4
1.2 Centro de Computacin, Universidad de Oriente Ncleo Monagas. ............ 4
1.2.1 Visin. .................................................................................................... 4
1.2.2 Misin. ................................................................................................... 4
1.2.3 Objetivos ................................................................................................ 5
1.2.4 Funciones ............................................................................................... 6
1.2.5 Organigrama........................................................................................... 7
1.3. Servicio Mdico de la Universidad de Oriente ............................................ 7
1.3.1. Objetivo:................................................................................................ 8
1.3.2. Misin: .................................................................................................. 8
1.3.3. Visin: ................................................................................................... 8
1.3.4. Organigrama.......................................................................................... 9
CAPTULO II ....................................................................................................... 10
vii
EL PROBLEMA Y SUS GENERALIDADES..................................................... 10
2.1. Planteamiento del Problema ....................................................................... 10
2.2. Objetivos de la Investigacin ..................................................................... 13
2.2.1. Objetivo General ................................................................................. 13
2.2.2. Objetivos Especficos .......................................................................... 13
2.3. Justificacin de la Investigacin ................................................................ 13
2.4. Alcance de la Investigacin. ...................................................................... 14
2.5. Limitaciones de la investigacin. ............................................................... 14
CAPITULO III ...................................................................................................... 15
MARCO REFERENCIAL .................................................................................... 15
3.1. Antecedentes de la Investigacin ............................................................... 15
3.2. Bases Tericas ............................................................................................ 17
3.2.1 Sistema de Informacin Transaccionales ............................................. 17
3.2.2. El Mtodo Gray Watch ....................................................................... 18
3.2.2.1. Objetivos del mtodo WATCH.................................................... 19
3.2.2.2 Caractersticas del Mtodo WATCH ............................................ 20
3.2.2.3 Componentes del mtodo WATCH .............................................. 25
3.2.3.4 Estructura del mtodo WATCH .................................................... 25
3.2.3 Lenguaje de Modelado Unificado .................................................... 33
3.2.3.1. UML 2.0 ....................................................................................... 34
3.2.3.2 Diagramas UML............................................................................ 34
3.2.3.2.1 Diagrama de caso de uso...........................................................35
3.2.3.2.2 Diagrama de clases. ..................................................................36
3.2.3.2.3 Diagramas de Despliegue .........................................................38
3.2.3.2.4 Diagrama de secuencia. ............................................................39
3.2.3.2.5 Diagrama de actividades. ..........................................................40
3.2.3.2.6 Diagrama de Paquetes ...............................................................41
3.2.3. Tarjetas CRC ....................................................................................... 42
3.2.5. Arquitectura cliente- servidor ............................................................. 42
3.2.6.1 Desarrollo de Software Libre ........................................................ 45
3.2.6. Sistemas de informacin aplicados al sector sanitario ........................ 46
viii
3.2.7. Herramientas de desarrollo. ............................................................. 47
3.2.8. Lenguajes de Programacin ................................................................ 48
3.2.9. Base de Datos MySql .......................................................................... 50
3.2.10. XAMMP............................................................................................ 50
3.2.11. Web Apache ...................................................................................... 51
3.3. Bases Legales ............................................................................................. 51
3.4. Definicin de Trminos.............................................................................. 53
CAPITULO IV ...................................................................................................... 56
MARCO METODOLGICO ............................................................................... 56
4.1. Tipo y Nivel de la Investigacin ................................................................ 56
4.2. Poblacin y Muestra ................................................................................... 57
4.2.1. Poblacin ............................................................................................. 57
4.2.2. Muestra................................................................................................ 57
4.3. Tcnicas e Instrumentos de Recoleccin de Datos. ................................... 58
4.4. Diseo Operativo ....................................................................................... 59
4.5. Cuadro Operativo ....................................................................................... 63
CAPITULO V ....................................................................................................... 65
RESULTADOS ..................................................................................................... 65
5.1 Etapa I. Estudio del Negocio. ...................................................................... 66
5.2 Etapa II. Diseo de la Arquitectura ............. Error! Marcador no definido.
5.3 Etapa III. Construccin del Software. ....................................................... 231
5.4. Etapa IV. Implantacin del sistema ........... Error! Marcador no definido.
5.5 Anlisis Costo Beneficio. ....................................................................... 251
5.5.1 Costos ................................................................................................. 251
5.5.2 Beneficios........................................................................................... 253
CONCLUSIONES .............................................................................................. 257
RECOMENDACIONES ..................................................................................... 259
BIBLIOGRAFA ................................................................................................ 260
ANEXOS ............................................................................................................ 263
ix
LISTA DE FIGURAS
Pp.
Figura 1 Organigrama del Centro de Computacin de la U.D.O Monagas.. .......... 7

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

Tabla 2: Elementos del diagrama de despliegue. .................................................. 39
Tabla 3: Elementos de diagrama de secuencia. ..................................................... 40
Tabla 4: Elementos de diagrama de despliegue. ................................................... 41
Tabla 5: Interesados (stakeholders) del proyecto. ................................................. 73
Tabla 6: identificacin de Interesados del proyecto. ............................................. 74
Tabla 7: Productos que genera la metodologa ................................................... 82
Tabla 8: Caractersticas de ISO-9126 . ................................................................. 87
Tabla 9: Plan de tiempo del proyecto1/4............................................................... 90
Tabla 10: Riesgos a administrar en el proyecto 1/13. ........................................... 94
Tabla 11: Matriz evento vs. Proceso de Negocio. .............................................. 125
Tabla 12: Reglas del Negocio (1/4). ................................................................... 130
Tabla 13: Descripcin de actores 1/10. ............................................................... 134
Tabla 14: Recoleccin de requerimientos iniciales 1/2. ..................................... 136
Tabla 15: Requisitos funcionales del sistema (1/6)............................................. 141
Tabla 16: Requisito no funcionales del sistema (1/2). ........................................ 147
Tabla 17: Curso bsico de eventos para validar usuario. .................................... 158
Tabla 18: Curso alternativo de eventos para validar usuario. ............................. 158
Tabla 19: Curso bsico de eventos para validar usuario 1/2. .............................. 161
Tabla 20: Curso alternos de eventos para validar usuario................................... 162
Tabla 21: Curso bsico de eventos para programar cita. .................................... 165
Tabla 22: Curso alterno de eventos para programar cita..................................... 166
Tabla 23: Curso bsico de eventos para consultar cita. ...................................... 172
Tabla 24: Curso alterno de eventos para consultar cita....................................... 172
Tabla 25: Curso bsico de eventos para elaborar historia mdica ...................... 176
Tabla 26: Curso alterno de eventos para elaborar historia mdica.. ................... 177
Tabla 27: Curso bsico de eventos para crear boleta mdica.............................. 187
Tabla 28: Curso alterno de eventos para crear boleta mdica ............................. 187
Tabla 29: Curso bsico de eventos para emitir rcipe medico. ........................... 193
Tabla 30: Curso alterno de eventos para emitir rcipe medico. .......................... 194
xii
Pp.
Tabla 31: Curso bsico de eventos para el registro de factura. ........................... 199
Tabla 32: Curso alterno de eventos para el registro de factura. .......................... 199
Tabla 33: Curso bsico de eventos para la devolucin de factura. ..................... 200
Tabla 34: Curso bsico de eventos para la consulta de factura. .......................... 209
Tabla 35: Curso alterno de eventos para la consulta de factura. ......................... 209
Tabla 36: Curso bsico de eventos mantenimiento de medicamento. ............... 213
Tabla 37: Curso alterno de eventos mantenimiento de medicamento................. 213
Tabla 38: Curso bsico de eventos para la salida de medicamento. ................... 214
Tabla 39: Curso alterno de eventos para la salida de medicamento. .................. 214
Tabla 40: Curso bsico de eventos generar reporte. .......................................... 224
Tabla 41: Curso alterno de eventos generar reporte............................................ 224
Tabla 42: Tabla de mtrica Adecuidad ISO 9126. ............................................. 228
Tabla 43: Tabla de mtrica Madurez ISO 9126. ................................................ 228
Tabla 44: Tabla de mtrica Entendibilidad ISO 9126......................................... 229
Tabla 45: Tabla de mtrica ISO 9126. Comportamiento en el tiempo .............. 229
Tabla 46: Tabla de mtrica ISO 9126. Conformidad de la Transportabilidad .... 230
Tabla 47: Especificacin de caso de pruebas boleta mdica............................... 244
Tabla 48: Especificacin de caso de pruebas Motivo Despacho. ....................... 245
Tabla 49: Especificacin de caso de pruebas Laboratorio. ................................. 246
Tabla 50: Costos de Materiales (1/2). ................................................................. 252
Tabla 51: Reduccin de tiempo........................................................................... 254
Tabla 52: Disminucin de tiempo en la generacin de reporte. .......................... 255
Tabla 53: Costos de papelera sin el sistema. ...................................................... 255
xiii
LISTA DE DIAGRAMAS
Pp.
Diagrama 1: Diagrama de actividades programar cita mdica. .......................... 109

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

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

Administracin por alcanzar un desempeo ms efectivo, han incrementado el uso de
sistemas automatizados como mecanismos para enfrentar la competitividad de
manera ms eficiente. El manejo de la informacin, a travs de la implantacin de
sistemas automticos viene permitiendo a las organizaciones, el dominio de gran
cantidad de datos en forma centralizada y en lnea. Tales razones explican la gran
demanda y variedad de software o programas informticos que estn dando
respuesta a necesidades particulares, en cuanto a la agilizacin y tramitacin de datos
que, debidamente interpretados puedan ser tiles para extraer conclusiones.
En el campo de los procesos mdicos, los sistemas de informacin estn

jugando un importante papel, como elemento clave para abordar muchos de los retos
que afronta el sector sanitario, realidad que puede insertarse dentro de las
expectativas de la Pasanta realizada en el Servicio Mdico de la Universidad de
Oriente Ncleo Monagas, la cual se plante como objetivo, implementar un sistema
automatizado que optimice la gestin de los procesos administrativos del rea de
servicios mdicos de la universidad de Oriente ncleo Monagas.
Desde esta perspectiva el rea temtica est centrada en un sistema de

informacin transaccional. Para la elaboracin de este proyecto se emple como
metodologa de trabajo, GRAY WATCH por ser un mtodo de desarrollo de software
que abarc todo el ciclo de vida de las aplicaciones; desde el modelado del dominio
de la aplicacin, pasando por la definicin de los requisitos de los usuarios, hasta la
puesta en operacin del sistema. Este mtodo establece las actividades los procesos,
las prcticas, las tcnicas, los estndares, y las herramientas que se deben emplea
para desarrollar los componentes arquitectnicos de la aplicacin e integrarla al
sistema de negocio para el cual es desarrollada.
La metodologa fue sustentada junto a las herramientas de lenguaje de

modelado UML BUSINESS y de sistemas en ambiente Web, WebML, herramientas
que permiten al diseador enfocar todo su esfuerzo en el usuario final por ser un
sistema basado en ellos. Tambin se utiliz la extensin de UML mediante dos
tcnicas no incorporadas: tarjetas CRC para anlisis guiados por la responsabilidad, y
diagramas de Entidad de Relacin (ER) para modelar bases de datos relacionales.
El trabajo est conformado por cinco (5) captulos:
Captulo I: Contiene informacin del contexto organizacional relacionada con

el Servicio Mdico de la Universidad de Oriente Ncleo Monagas, institucin objeto
de estudio. As como tambin, aspectos relacionados con el centro de computacin de
la Universidad de Oriente Ncleo Monagas, institucin donde se realiz la pasanta
de grado detallando su misin, visin, objetivos, estructura organizativa, entre otros.
Captulo II: Este captulo contempla el planteamiento del problema, los

objetivos de la investigacin, la justificacin y el alcance.
Captulo III: Est constituido por los antecedentes que apoyan la investigacin
y las bases tericas que le dan sustento al trabajo investigativo.
Captulo IV: En este captulo se detalla la metodologa que se implement y la

explicacin del trabajo realizado durante el periodo de pasanta.
Captulo V: Recoje los resultados alcanzados, partiendo de la aplicacin de la

propuesta de solucin. Para finalizar, se plantean las conclusiones y las
recomendaciones las cuales constituyen un aporte de investigacin.
2
CAPITULO I
CONTEXTO ORGANIZACIONAL
1.1. Resea Histrica de la Universidad de Oriente, Ncleo Monagas.
El Ncleo de Monagas de la Universidad de Oriente, responde a las necesidades

y tradicin del Estado, en su actividad agrcola, ganadera y petrolera que a travs de
un conjunto de unidades acadmicas, ofrece a una poblacin estudiantil de ms de
15.000 estudiantes las carreras de: Ingeniera: Agronmica, en Produccin Animal,
Petrleo y Sistemas, adems de Licenciatura en: Administracin, Contadura Pblica,
Gerencia de Recursos Humanos y Tecnologa de los Alimentos. Asimismo ofrece
Servicios de Orientacin Bibliotecas, Comedor, Transporte, Proveedura, Librera y
Servicio Mdico-Odontolgico, Ayudas Econmicas, Extensin Cultural, Deportes
y Planes de pasantas para el financiamiento y familiarizacin con el futuro
desempeo profesional.
1.1.1. Misin
La Universidad de Oriente reafirmar su compromiso de ser el centro de

estudio, anlisis y produccin de ideas necesarias para el desarrollo social, econmico
y poltico del Oriente del Pas, capaz de desarrollar mtodos y tecnologa
innovadoras, de asegurar la calidad por medio de los sistemas eficientes de
planificacin, evaluacin y motivacin. La Universidad ser una Institucin cuyo
ambiente estimule la creatividad y productividad de todos sus miembros. As
mismo deber ocupar una posicin de liderazgo en investigacin y logros
acadmicos. Con intencin de situarse en un lugar privilegiado en los sueos de
cada miembro de la Comunidad Universitaria.
1.1.2. Visin
Formar profesionales del ms alto nivel de calidad, profesionales que

atiendan problemas de su particular formacin y competencia, bajo un alto espritu
de solidaridad y compromiso social. Se trata de formar profesionales creativos,
capaces de destacarse en un mercado cada vez ms competitivo con el
mejoramiento de la calidad de vida y con el desarrollo.
Mantener una permanente vinculacin con sus egresados para su actualizacin

constante. As mismo, permanecer en contacto con los sectores sociales y
productivos. Brindar a sus trabajadores tanto, en la parte acadmica, administrativa y
estudiantil las mejores condiciones para que estos encuentren el xito en el
desempeo de sus funciones. Mantener un clima de respeto mutuo, de libertad de
expresin, organizacin, de pluralidad de todas las corrientes de pensamiento, dentro
de un ambiente de responsabilidad y tolerancia a todas las ideas e igualmente estar
vinculada con su entorno.
1.2 Centro de Computacin, Universidad de Oriente Ncleo Monagas.
1.2.1 Visin.
El Centro de Computacin tiene como visin principal ser un centro

competitivo, lder a nivel nacional en todas las reas de nuestro inters, contando con
el apoyo de un personal altamente capacitado en cada una de las secciones que los
componen y estableciendo una plataforma tecnolgica til que satisfaga las
necesidades del sector docente, estudiantil y administrativo de la Universidad de
Oriente Ncleo Monagas.
1.2.2 Misin.
La misin del Centro de Computacin, es la de realizar labores de

investigacin, desarrollo de software, adiestramiento y soporte tcnico en las reas
4
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.
5
1.2.4 Funciones
El Centro de Computacin cumple con las siguientes funciones, a objeto de

alcanzar su respectiva visin y misin:
a. Brindar de forma permanente soporte tcnico a las unidades

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

contabilidad y presupuesto.
c. Desarrollar y mantener los sistemas de informacin orientados al proceso

de automatizacin de la gestin administrativa de la Institucin.
d. Coordinar y supervisar el funcionamiento de las unidades que integren

el Centro de Computacin
e. Distribuir, segn la capacidad productiva, las tareas del personal

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

equipos de computacin, a travs de cursos, charlas y seminarios de
actualizacin y charlas.
g. Prestar asesora en el rea de computacin y Teleinformtica a aquellas

unidades que integran la estructura administrativa y acadmica de la
Universidad de Oriente.
h. Procesa toda la informacin necesaria para el Dpto. de Admisin y

Control de Estudio. As mismo presta todos los servicios necesarios en los
procesos de inscripcin, informes al CNU y estadsticas acadmicas.
i. El Centro puede atender solicitudes de aplicaciones para el anlisis

estadstico de datos generados por las investigaciones que se realizan en el
ncleo.
6
1.2.5 Organigrama
Jefatura
Secretaria
PROGRAMAS Y SECCIN DE APOYO

PROYECTOS
Produccin y Valor agregado Redes Soporte Tcnico Seguridad

desarrollo de
sistemas
Figura 1 Organigrama del Centro de Computacin de la Universidad de Oriente, Ncleo

Monagas. Fuente: Memoria y Cuenta (2009).
1.3. Servicio Mdico de la Universidad de Oriente
La fuente Universidad de Oriente (2010), acota que el Servicio Mdico del

Ncleo Monagas es una Unidad adscrita a la Delegacin de Desarrollo y Bienestar
Estudiantil, la cual se inserta dentro de una estructura organizativa institucional en
consonancia con las expectativas institucionales. Esta delegacin estudia al
educando dentro de su dimensin social con la finalidad de ofrecer diversas vas de
solucin a los problemas que interfieren en su adecuado funcionamiento acadmico y
social.
Desde este ngulo, la salud de sus miembros se constituye en una parte

importante para alcanzar los objetivos de esta casa de estudios en cuanto a mantener
un liderazgo en la investigacin. En correspondencia con ello, el Servicio Mdico
7
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.
8
1.3.4. Organigrama
Decanato del Ncleo Monagas
Coordinacin Coordinacin
Administrativa Acadmica
Secretaria
Delegacin de
Desarrollo Social y
Transporte
Bienestar
Estudiantil
Administracin rea rea de rea de

rea de
Socioeducativa Desarrollo Social Orientacin
Salud
Servicios Mdicos
Medicina Medicina Pediatra Ginecologa Odontologa

General Interna
Figura 2: Organigrama del Servicio Mdico de la Universidad de Oriente, Ncleo

Monagas. Fuente: Universidad de Oriente (2009)
De acuerdo con documentos del Servicio Mdico Odontolgico (2008), el mismo

est conformado por catorce (16) funcionarios, los cuales se detallan a continuacin
precisando el nmero de personas que ocupan cada cargo:
01 jefe de departamento 01 Auxiliar de Registros y Estadsticas
01 jefe de enfermera 01 Higienista Dental
05 Enfermeras 01 Secretaria
06 Mdicos
9
CAPTULO II
EL PROBLEMA Y SUS GENERALIDADES
2.1. Planteamiento del Problema
Para estar a la vanguardia del mundo actual hay que ajustarse al desarrollo y
crecimiento del entorno tecnolgico, como mecanismo de acceso a la informacin
bajo parmetros de rapidez, privacidad, confiabilidad y eficiencia tal que permitan
un desarrollo cnsono dentro de las instituciones y contribuya al desarrollo
nacional. Esta realidad viene siendo asumida por las organizaciones mundiales,
entre ellas, las instituciones de educacin superior, establecimientos generadores y
promotores de conocimiento que asumen la tecnologa, como herramienta para
optimizar sus procesos internos. Desde esta perspectiva la implantacin de
sistemas automatizados se constituyen en una alternativa real y eficiente para
mejorar los resultados de la gestin y un mejor desempeo laboral.
Dentro de este contexto se enmarca, el Servicio Mdico Odontolgico que se

encuentra ubicado en la sede Guaritos de la Universidad de Oriente Ncleo de
Monagas, el cual es un rea orientada a brindar atencin a toda la poblacin que
forma parte de la institucin, en ramas de la medicina tales como: ginecologa,
odontologa, pediatra, medicina general e interna. La puesta en marcha del
Servicio Mdico Odontolgico se ha iniciado con un conjunto de limitaciones, como
lo es la consistente y creciente demanda del los usuarios, situacin que requiere ser
solventada para cubrir las necesidades de salud de los estudiantes, obreros y
empleados y logar una gestin de servicio ms eficiente.
Actualmente todos los procesos administrativos del Servicio Mdico: registro
de usuarios, apertura de historias mdicas, emisin de rcipes para compra de
medicamentos, control de consultas, remisin de pacientes que requieren atencin
especializada y exmenes de laboratorios se llevan a cabo de manera manual, as como
tambin, la relacin de los mismos, a objeto de validar la cancelacin de tales
servicios ante la Delegacin de Presupuestos de dicha institucin, generando un
conjunto de fallas que se expresa en:
Para que el paciente pueda recibir la atencin mdica tienen que invertir gran
cantidad de tiempo asistiendo al Departamento de Admisin y Control de Estudios, en
el caso de los estudiantes a solicitar una constancia de estudio para poder ser atendidos
o en el caso de los obreros y empleados, la Delegacin de personal debe enviar una
orden al servicio mdico. Este hecho, tambin trae como consecuencia, que en muchas
ocasiones por el deficiente control, se atienden pacientes o se suministren
medicamentos a personan que no forman parte de la poblacin universitaria del ncleo
de Monagas.
Las historias mdicas se crean y almacenan en un archivador fsico, dificultando,

en la mayora de los casos, su ubicacin y manipulacin. Esta situacin retrasa el proceso
para atender al paciente, ya que el doctor necesita tener la historia mdica a mano, al
momento de realizar la consulta. Adems, el archivador fsico es de libre acceso porque
se encuentra localizado en un rea de uso comn para todo el personal del servicio
mdico, siendo susceptible a extravos o manipulacin por personas ajenas a 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

Producto WATCH
Modelo de Productos Modelo de Procesos

Modelo de Actores
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
Aplicacin
Producto Producto de Producto de Empresarial
Tcnicos Gestin Soporte
Figura 4: Principales tipos de productos del mtodo Gray Watch. Fuente: autor 2010.
El Modelo de Actores
El Modelo de Actores tiene como objetivos:

a) Identificar los actores o interesados (stakeholders) que estn involucrados en
el desarrollo de aplicaciones empresarial.
26
b) Describir las modalidades de organizacin del equipo de trabajo que
desarrollar los diferentes componentes arquitectnicos de una aplicacin
empresarial
c) Definir los roles y responsabilidades de aquellos actores que integrarn el

equipo de trabajo.
La Figura 5 clasifica, al ms alto nivel de abstraccin, a los actores que participan el

desarrollo de aplicaciones aplicacin empresarial en cuatro grupos diferentes.
Class taxonoma de actores (Stakeholder)
Actor
(Stakehold
er)
Cliente Promoto Desarrolla Usuario

r dor
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 Ingeniera Diseo Diseo de Programacin Pruebas de Entrega de

negocio de requisitos Arquitectnico componentes & la la
Integracin Aplicacin 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
SI del Negocio
NO
Nueva Versin?
Entrega de la
Aplicacin Inicio Ingeniera
de Requisitos
Procesos de
Gestin y
Soporte
Prueba de la Diseo
Aplicacin Arquitectnico
Programacin
& Diseo
Integracin Detallado
Figura 8: Estructura del Modelo de Procesos. Fuente: Autor (2010).
De acuerdo a la estructura del modelo, el proceso de desarrollo de software se

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

decir, la aplicacin se desarrolla mediante la entrega de una o ms versiones de la
32
aplicacin. Cada ciclo de desarrollo produce una nueva versin operativa de la
aplicacin. Una versin es un producto operativo, esto es, ejecutable y que provee
ciertos servicios a sus usuarios. Cada nueva versin la agrega, a la anterior, nuevos
servicios o funciones. Los ciclos de desarrollo se repiten hasta completar al conjunto
total de servicios o funciones que demandan sus usuarios y que estn indicados en la
arquitectura de la aplicacin. El proyecto culmina cuando se entrega la ltima versin
prevista de la aplicacin. Las versiones definen el carcter versionado o cclico del
mtodo.
Cada versin, a su vez, est compuesta de uno o ms incrementos de software.

Un incremento es una pieza de software que ejecuta un conjunto de funciones de la
versin y que es usada, por los usuarios, para: validar las funciones implementadas
por el incremento, familiarizarse con la interfaz grfica de la aplicacin; y/o usarla
para apoyar la ejecucin de procesos de negocio. Los incrementos definen el carcter
incremental del mtodo.
Uno de los procesos de soporte, denominado Verificacin y Validacin

(V&V), se encarga de evaluar cada producto de los procesos tcnicos, a fin de
determinar si el proceso contina hacia el siguiente proceso debe retornarse a un
proceso anterior para corregir defectos en los productos. El carcter iterativo del
mtodo es determinado, en parte, por el proceso V&V.
3.2.3 Lenguaje de Modelado Unificado
El UML (Unified Modeling Language) tiene sus orgenes en la necesidad que

se haba generado en la industria para construir modelos orientados a objetos.Nace en
el ao 1994 por iniciativa de Grady Booch y Jim Rumbaugh paracombinar dos
famosos mtodos: el de Booch y el OMT (Object Modeling Technique). Ms tarde se
les uni Ivar Jacobson, creador del mtodo OOSE (Object-Oriented Software
Engineering). En respuesta a una peticin de OMG (Object Management Group),
para definir un lenguaje y una notacin estndar del lenguaje de construccin de
modelos, en 1997 propusieron el UML como candidato. UML es ante todo un
33
lenguaje, lenguaje que se centra en representacin grfica de un sistema. Es un
lenguaje visual estndar empleado para la especificacin, construccin y
documentacin de software orientado a objetos, por medio de diversos elementos y
procesos que interactan de alguna forma con el software.
3.2.3.1. UML 2.0
sta versin del lenguaje UML incorpora nuevos smbolos que hacen ms fcil el
modelado del comportamiento dinmico del sistema, razn por la cual es usada en el
desarrollo de este proyecto para modelar el diagrama de actividades. Los Diagramas
de Actividades capturan las acciones de una actividad y sus resultados, es decir
muestran el flujo de trabajo desde el punto de inicio hasta el punto final. Su utilidad
en el Modelado de Negocios permite detallar el proceso involucrado en las
actividades del negocio. Pueden ser atribuidas algunas caractersticas como:
a) Enfatizan la secuencia de acciones de una actividad.

b) Modelan el flujo de control y/o el flujo de objetos de una actividad.
3.2.3.2 Diagramas UML
Los diagramas son la representacin grfica de una coleccin de elementos

con sus relaciones, ofreciendo as una vista del sistema a modelar. Para poder
representar de forma correcta un sistema, el lenguaje presenta una amplia variedad de
diagramas para as visualizar el sistema desde diversas perspectivas.
Entre esos diagramas se encuentran:

A. Diagramas de Casos de Uso
B. Diagramas de Clase
C. Diagramas de Secuencias
D. Diagramas de Actividades
E. Diagramas de Paquetes
34
3.2.3.2.1 Diagrama de caso de uso.
Los elementos que pueden aparecer en un diagrama de casos de uso segn lo

cita Ferre, X., et al (2005), son: actores, casos de uso y relaciones entre casos de uso.
A. Un actor es una entidad externa al sistema que realiza algn tipo de interaccin
con el mismo. Se representa mediante una figura humana dibujada con palotes.
Dicha representacin sirve tanto para actores que son personas como para otros
tipos de actores (sistemas, sensores, etc.).
Actor
Figura 9: Actor. Fuente: Autor (2010).
B. Un caso de uso, es una descripcin de la secuencia de interacciones que se

producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a
cabo una tarea en especfico. Se representa mediante una elipse con el nombre
del caso de uso en su interior.
Caso de Uso
Figura 10: Caso de Uso. Fuente: Autor (2010)
C. Las relaciones entre casos de usos pueden ser de extiende; cuando un caso de
uso especializa a otro extendiendo su funcionalidad, de inclusin, cuando un
caso de uso utiliza a otro y de asociacin para comunicar a un actor con otro.
35
Tipo de Relaciones
Asociacin
Include 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 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
Nodo hardware host que se utiliza para desplegar componentes
en el ambiente de produccin.
Los componentes representan todos los tipos de

Componente elementos software que entran en la fabricacin de
aplicaciones informticas.
Interface Las interfaces se utilizan como lazo de unin entre unos

componentes y otros
Tabla 2: Elementos del diagrama de despliegue. Fuente: Autor (2010).
3.2.3.2.4 Diagrama de secuencia.
Un diagrama de secuencia es un tipo de diagrama de interaccin en el cual se

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

Lnea de
Vida Indica que indica el periodo en que estuvo vivo
el objeto durante la secuencia de actividades.
Usuario del Sistema
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
Activacin denota como un rectngulo delgado sobre la
lnea de vida del objeto.
El envo de mensajes entre objetos se denota

Mensaje de mediante una lnea slida dirigida, desde el
un objeto a objeto que emite el mensaje hacia el objeto que
otro lo ejecuta.
Mensaje a un Como su nombre lo indica, es el mensaje que

un objeto se enva a s mismo.
mismo objeto
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
Nodo de actividad
Accin
Primitiva ejecutable de asignacin o computacin.
Nodo de control que indica el inicio de un flujo de

Nodo de Inicio
control cuando una actividad es invocada.
Nodo fin de Nodo de control que indica el fin de todos los flujos
actividad dentro de una actividad. Muestra el fin de la actividad.
Eje de actividad para flujo de control. Conecta dos

Flujo de Control
acciones. Usado para indicar secuencia.
Nodo de
Nodo de control que divide un flujo en dos o ms flujos
Sincronizacin
concurrentes (paralelos)
(fork)
Nodo de
concurrencia
Nodo de control que sincroniza mltiples flujos.
(Join)
Nodo de decisin Nodo de control que selecciona entre dos o ms flujos

de salida.
Tabla 4: Elementos de diagrama de despliegue. Fuente: Autor (2010)
3.2.3.2.6 Diagrama de Paquetes
Un paquete es un mecanismo de agrupamiento empleado para organizar los

elementos modelados en UML y para facilitar el manejo de los modelos de un
sistema. Un paquete tiene un nombre propio, posee elementos de modelado como
diagramas y pueden contener a su vez otros paquetes.
Figura 13: Smbolo de un Paquete. Fuente: Autor (2010).
41
3.2.3. Tarjetas CRC
Aunque no forman parte de UML, otro mecanismo se utiliza algunas veces para
ayudar a asignar responsabilidades e indicar las colaboraciones con otros objetos son
las tarjetas CRC (Clase-Responsabilidad-Colaborador). Kent Beck y Ward
Cunningham fueron quienes promovieron el uso de estas tearjetas y son los
principales responsables de estimular a los diseadores de software a pensar de
manera ms abstractas en trminos de asignacin de responsabilidades y
colaboraciones, tambin del uso de los patrones.Las tarjetas CRC son fichas, una por
cada clase, en las que se escriben brevemente, las responsabilidades de la clase, y una
lista de objetos con los que colabora para llevar a cabo esas responsabilidades. Se
desarrollan normalmente en una sesin de trabajo en grupo pequeo.
Las tarjetas CRC son una tcnica para registrar los resultados de la asignacin
de responsabilidades y asignaciones. La informacin recopilada se puede enriquecer
utilizando diagramas de clases y de interaccin. Lo importante no son las tarjetas o
los diagramas sino tener presente la asignacin de responsabilidades. (Larman, C.,
2002, Pp 229-230).
Figura 14: Tarjeta CRC. Fuente: Autor (2010).
3.2.5. Arquitectura cliente- servidor
La arquitectura bajo el modelo Cliente Servidor de acuerdo con el criterio

de Gutirrez, J. (2005) es un protocolo orientado a conexin. No hay relaciones
maestro/esclavo. Las aplicaciones, sin embargo, utilizan un modelo
cliente/servidor en las comunicaciones. (p.3) En correspondencia con lo anterior el
42
mismo autor define al servidor como: Una aplicacin que ofrece un servicio a
usuarios de Internet; un cliente es el que pide ese servicio. (p.3)
Los usuarios invocan la parte cliente de la aplicacin, que construye una

solicitud para ese servicio y se la enva al servidor de la aplicacin que usa TCP/IP
como transporte. El servidor es como un programa que recibe una solicitud, realiza el
servicio requerido y devuelve los resultados en forma de una respuesta.
Generalmente un servidor puede tratar mltiples peticiones (mltiples clientes) al
mismo tiempo.
Figura 15: El modelo de aplicacin cliente/servidor. Fuente: Autor (2010)
Algunos servidores esperan las solicitudes en puertos bien conocidos de modo que
sus clientes saben a qu zcalo IP deben dirigir sus peticiones. El cliente emplea un
puerto arbitrario para comunicarse. Los clientes que se quieren comunicar con un
servidor que no usa un puerto bien conocido tienen otro mecanismo para saber a qu
puerto dirigirse. Este mecanismo podra usar un servicio de registro como Portmap,
que utiliza un puerto bien conocido.
43
3.2.6. Software libre
El Software Libre es definido por su tipo de licenciamiento, por lo que se

puede llamar software licenciado bajo condiciones libres. Segn Hernndez,
J., (2005):
un software o programa de computacin cuya licencia nos permite

ejercer una serie de libertades:
a. La libertad de ejecutar el programa con cualquier propsito.

b. La libertad de estudiar cmo funciona el programa y adaptarlo
a las necesidades propias (para lo cual es una precondicin el
acceso al cdigo fuente).
c. La libertad de redistribuir copias del programa y de ese modo
ayudar a otros.
d. La libertad de mejorar el programa y liberar esas mejoras al
pblico beneficiando as a toda la comunidad. (p. 17).
El software libre se basa en la cooperacin y la transparencia y garantiza una

serie de libertades a los usuarios. Bajo esta perspectiva el Software Libre slo
exige una cosa, en el caso de la licencia GPL: y ellas es que si el programa
resultante de la modificacin es distribuido, debe hacerse bajo las mismas
condiciones del programa original. Las licencias que contienen esta condicin son
llamadas licencias Copyleft, y su objetivo es evitar que se distribuyan obras
derivadas bajo licencias privativas.
Da Rosa F., y Heinz, F., (2007) corroboran esta apreciacin cuando sostienen
que:
El software libre es propiedad de todos y cada persona en el mundo tiene derecho a

usar el software, modificarlo y copiarlo de la misma manera que los autores de este
mismo. Es un legado de la humanidad que no tiene propietario, de la misma manera que
44
las leyes bsicas de la fsica o las matemticas. No existe un monopolio y no es necesario
pagar peaje por su uso. (p.33).
En tal sentido resulta interesante el hecho de que en los ltimos aos algunos
gobiernos en el mundo, entre ellos, Venezuela, han iniciado el proceso de migracin
hacia el Software Libre, sobre todo en la institucin pblica. Se acota adems que
algunos de estos pases, han adoptado el Software Libre, para ahorrar dinero, otros
lo han hecho por cuestiones de seguridad, otros para ayudar a la creacin de
industrias locales y otros porque el software libre les pertenece.
3.2.6.1 Desarrollo de Software Libre
Las condiciones de licenciamiento de los programas libres permiten la

construccin comunitaria de software. Los desarrolladores de software pueden acudir
a inmensas colecciones de programas y bibliotecas altamente funcionales e
intensamente probadas. Esto reduce el esfuerzo y el riesgo de desarrollo, comparado
con la alternativa de empezar de cero. Usando el modo cooperativo de construccin,
tan esencial al mtodo cientfico, y no se limitan las posibilidades del programa a
lo que pueda ocurrrsele a un grupo pequeo de usuarios.
El valor del software aumenta mientras ms se comparte. El efecto de red

hace que un programa sea ms til, es ms fcil intercambiar informacin,
experiencias y resultados con usuarios del mismo programa. El valor potencial
de los programas libres es mayor que el de los no libres, tanto desde el punto de
vista social como individual: no hay restricciones a la difusin del programa, y
tampoco a su utilizacin. El modelo de negocios del Software Libre no parte de
la produccin pseudo-industrial de programas para vender como producto
terminado, sino en el agregado de valor. Esto posibilita muchos negocios en las
reas de capacitacin, asesoramiento, adaptacin, documentacin, publicacin
de libros, etc.
45
Para desarrolladores de software, el Software Libre ofrece una oportunidad
poderossima para agregar valor mediante la ampliacin incremental de la
funcionalidad de los programas. Cuando un desarrollador quiere satisfacer una
necesidad y est trabajando con este software puede simplemente, agregar la
funcionalidad necesaria al programa ya existente, y cobrar al usuario slo por el
agregado.
Desde esta perspectiva, el proceso resulta econmicamente viable, y

contribuye a un crculo virtuoso: un programa ms funcional es ms tentador
para usuarios potenciales, y mientras ms usuarios tengan un programa, existen
mayores posibilidades de que puedan ser mejorados por otros usuarios
duplicando la funcionalidad del programa y luego agregndole nueva funcin.
(Da Rosa, F., y Heinz, F., 2007, pp. 37-40).
3.2.6. Sistemas de informacin aplicados al sector sanitario
Cuando se plantea la necesidad de poner en prctica la tecnologa para

automatizar los procesos dentro de una unidad o sector sanitario segn Carruz, A., et al
(2003):
La aplicacin no difiere de manera fundamental de las tecnologas que se

aplican para la informatizacin de los procesos de negocio en otros sectores. Son
igualmente aplicables tecnologas como los monitores transaccionales o los
servidores de aplicacin para aplicaciones escalables, los workflow para automatizar
procesos claramente definidos, los EAI (Enterprise Application Integration) para la
interconexin de sistemas, etc. (p. 26 )
En correspondencia con ello, la tecnologa para automatizar es aplicable a cualquier

mbito como herramienta para mejorar de una u otra forma los procesos implcitos
dentro de una gestin. Sin embargo, el mismo autor puntualiza en determinados
elementos cuando plantea que:
46
Solamente es preciso incidir en el factor ya apuntado de que los procesos en el
sector sanitario estn, en muchos casos, poco formalizados, debido a hechos como
la variabilidad de la prctica clnica y al poder de decisin de los mdicos. Es por
ello que se debe ser muy prudente a la hora de introducir tecnologas que
encorseten en exceso los procesos. La informatizacin de los procesos en sanidad
debe ser, en muchos casos, una automatizacin laxa que deposite una parte
importante de la lgica del proceso en los propios profesionales de la salud que son
usuarios del sistema. (p.22)
Ello implica que la automatizacin dentro esta rea, debe darse como un proceso
eficiente, sencillo, centrado en procedimientos elementales, fcilmente
manejables por el personal de salud, de fcil comprensin y que facilite el
conocimiento coadyuvando a la toma de decisiones. En este sentido, resulta
adecuado complementar los sistemas de informacin sanitarios con elementos de
trabajo colaborativos.
3.2.7. Herramientas de desarrollo.
A. Sybase PowerDesigner 12.0.
Sybase es una compaa lder en el desarrollo y expansin de tecnologa

innovadora para la movilizacin de informacin y se ha ganado la confianza de
muchas corporaciones importantes en el mundo, gracias a su habilidad en la
gestin de informacin. Siendo PowerDesigner uno de sus productos, el cual es
una herramienta para el modelamiento de datos y procesos de negocio (Wikipedia,
2008). A travs de esta herramienta, se pueden realizar los diagramas de UML de
manera rpida, realizando as el diseo del sistema y manteniendo la trazabilidad
del mismo
B. Macromedia Dreamweaver 8.
Sybase es una compaa lder en el desarrollo y expansin de tecnologa

innovadora para la movilizacin de informacin y se ha ganado la confianza de
47
muchas corporaciones importantes en el mundo, gracias a su habilidad en la
gestin de informacin. Siendo PowerDesigner uno de sus productos, el cual es
una herramienta para el modelamiento de datos y procesos de negocio (Wikipedia,
2008). A travs de esta herramienta, se pueden realizar los diagramas de UML de
manera rpida, realizando as el diseo del sistema y manteniendo la trazabilidad
del mismo
C. Macromedia Fireworks.
Es una aplicacin verstil en forma de estudio que ofrece un ambiente

eficiente para la creacin rpida de prototipos de sitios Web e interfaces de
usuario, permite crear y editar imgenes de mapa de bits y vectoriales, disear
efectos web, recortar y optimizar elementos grficos, ayudando a resolver los
principales problemas que enfrentan los diseadores grficos y los creadores de
sitios webs.
3.2.8. Lenguajes de Programacin
Un lenguaje de programacin se refiere a cualquier lenguaje artificial que

pueda ser empleado para definir una secuencia de instrucciones para su
procesamiento por una computadora u ordenador. Por lo general, se encuentra
formado por un conjunto de smbolos y reglas de tipo semnticas y sintcticas,
que permiten a los programadores definir de manera precisa acerca de qu datos
debe operar una computadora, cmo estos datos deben ser almacenados o
transmitidos y qu acciones debe tomar ante diferentes eventos.
A. HTML.
HTML significa HyperText Markup Language, que en espaol se traduce a

lenguaje de marcas de hipertexto. Es el lenguaje que ms predomina en la
actualidad para construir pginas Web. Los documentos HTML son ficheros de
texto plano que usan la extensin .htm o .html.
48
Los diferentes prrafos, encabezados, tablas, listas, etc. de un documento
HTML, se sealan intercalando etiquetas, las cuales consisten en instrucciones
breves de comienzo y fin, que tienen como finalidad indicar al navegador como
debe ser mostrado el contenido de dicho documento. El lenguaje HTML puede ser
creado y editado con cualquier editor de textos bsico admita texto sin formato
como por ejemplo el bloc de notas de Windows o Gedit de Linux. Los
procesadores de texto se utilizan para escribir documentos en lenguaje HTML que
posteriormente ser interpretado por el programa navegador correspondiente.
B. PHP.
PHP (Hypertext Pre-processor ), es un lenguaje de alto nivel ejecutado por

diferentes tipos de servidores, que toman el cdigo PHP como entrada, y crean
pginas Web como salida. Posee variables, sentencias, condiciones, bucles y
funciones. Es publicado bajo la PHP license, y la Free Software Foundation
considera este tipo de licencia como software libre. El lenguaje PHP posee la
caracterstica de poder mezclarse con cdigo HTML, es multiplataforma, tiene
capacidad de conexin con la mayora de los manejadores de base de daos que se
emplean actualmente, posee una gran documentacin en su pgina oficial,
destacando que todas sus funciones estn explicadas y ejemplificadas y permite
las tcnicas de la programacin orientada a objetos.
C. JavaScript.
Javascriptt es un lenguaje de programacin interpretado, es decir, que no

requiere ser compilado, utilizado para construir sitios WEB y hacerlos ms
interactivos. Entre sus caractersticas principales, se puede mencionar que es un
lenguaje basado en acciones, que gran parte de la programacin en dicho lenguaje
est centrada en describir objetos, escribir funciones que respondan a
movimientos del mouse, aperturas, utilizacin de teclas, cargas de pginas entre
otros y es soportado por la mayora de los navegadores web. JavaScript naci de
la necesidad de permitir a los autores o creadores de pginas web interactuar con
sus usuarios, es decir crear pginas con una mayor complejidad ya que HTML
49
permite crear pginas estticas mostrando textos con estilos, pero exista la
necesidad de tener mayor interaccin con los usuarios.
3.2.9. Base de Datos MySql
MySQL, tal como define propiamente su parte de su nombre (SQL -

Structured Query Language), es el servidor de bases de datos relacionales ms
comnmente utilizado en GNU/Linux. Fue desarrollado por la empresa MySQL
AB, que cedi las licencias correspondientes al proyecto opensource, por lo que su
rpido desarrollo es causa del empeo de millones de programadores de todo el
mundo.
Al ser un servidor de bases de datos relacionales, MySQL se convierte en

una herramienta veloz en la accesibilidad a los datos introducidos en las distintas
tablas independientes que forman las bases de datos de este lenguaje. MySQL es
actualmente el sistema de bases de datos ms popular de la red. Casi la totalidad
de servicios ofrecidos por nuestra empresa incluyen el soporte para bases de datos
MySQL. Ben Laurie, (p. 568).
3.2.10. XAMMP
Es un servidor independiente de plataforma, software libre, que consiste

principalmente en la base de datos MySQL, el servidor web Apache y los intrpretes
para lenguajes de script: PHP y Perl. El nombre proviene del acrnimo de X (para
cualquiera de los diferentes sistemas operativos), Apache, MySQL, PHP, Perl. El
programa esta liberado bajo la licencia GNU y acta como un servidor web libre,
fcil de usar y capaz de interpretar pginas dinmicas. Actualmente XAMPP est
disponible para Microsoft Windows, GNU/Linux, Solaris, y MacOS X.
XAMPP solamente requiere de un archivo zip, tar, o exe a descargar y ejecutar,

con unas pequeas configuraciones en alguno de sus componentes que el servidor
web necesitar. XAMPP es regularmente actualizado para incorporar las ltimas
50
versiones de Apache/MySQL/PHP y Perl. Tambin incluye otros mdulos como
OpenSSL, y phpMyAdmin. Para instalar XAMPP requiere solamente una pequea
fraccin del tiempo necesario para descargar y configurar programas por separado eso
es todo. Ben Laurie, (p. 568).
3.2.11. Web Apache
Es un software (libre) servidor HTTP de cdigo abierto para plataformas Unix

(BSD, GNU/Linux, etctera), Windows y otras, que implementa el protocolo
HTTP/1.1 y la nocin de sitio virtual. Cuando comenz su desarrollo en 1995 se bas
inicialmente en cdigo del popular NCSA HTTPd 1.3, pero ms tarde fue reescrito
por completo. Su nombre se debe a que originalmente Apache consista solamente en
un conjunto de parches a aplicar al servidor de NCSA. Era, en ingls, a patchy server
(un servidor "parcheado").
El servidor Apache se desarrolla dentro del proyecto HTTP Server (httpd) de la

Apache Software Foundation. Apache presenta entre otras caractersticas mensajes de
error altamente configurables, bases de datos de autenticacin y negociado de
contenido, pero fue criticado por la falta de una interfaz grfica que ayude en su
configuracin.
3.3. Bases Legales
Las bases legales que dan soporte al proyecto en referencia, se encuentras

plasmadas en la:
A. Constitucin de la Repblica Bolivariana de Venezuela (1999)
Artculo 110: El Estado reconocer el inters pblico de la ciencia, la

tecnologa, el conocimiento, la innovacin y sus aplicaciones y los servicios
de informacin necesarios por ser instrumentos fundamentales para el
desarrollo econmico social y poltico del pas, as como para la seguridad y
soberana nacional..
51
Se infiere que todas las iniciativas en funcin de innovar los sistemas de
informacin sern reconocidas como un instrumento para el desarrollo de las
instituciones nacionales y por ende para el desarrollo nacional.
B. Ley Orgnica de la Administracin Pblica ( 2001)
Artculo 12. La actividad de la Administracin Pblica se desarrollar

con base en los principios de economa, celeridad, simplicidad
administrativa, eficacia, objetividad, imparcialidad, honestidad,
transparencia, buena fe y confianza. Asimismo, se efectuar dentro de
parmetros de racionalidad tcnica y jurdica.
La simplificacin de los trmites administrativos ser tarea permanente
de los rganos y entes de la Administracin Pblica.los rganos y
entes de la Administracin Pblica debern utilizar las nuevas
tecnologas que desarrolle la ciencia, tales como los medios
electrnicos, informticos y telemticos, para su organizacin,
funcionamiento y relacin con las personas., as como un
mecanismo de comunicacin electrnica con dichos rganos y entes
disponible para todas las personas va internet.
Tal articulado se ajusta a los objetivos de optimizacin de los procesos

administrativos del Servicio Mdicos de la Universidad de Oriente por cuanto la
misma a pesar de ser un servicio dentro de un ente autnomo no deja de ser un
ente nacional y en tal sentido corresponde acogerse a lo expresado por la ley.
C. Decreto Rango y Fuerza de Ley Orgnica de Ciencia, Tecnologa e Innovacin

en Consejo de Ministros (2002)
Artculo 2.- Las actividades cientficas, tecnolgicas y de

innovacin son de inters pblico y de inters general. Ello indica
que ataen a todos los individuos y entes nacionales.
Artculo 22.- El Ministerio de Ciencia y Tecnologa coordinar las

actividades del Estado que, en el rea de tecnologas de informacin,
fueren programadas. Asumir competencias que en materia de
informtica, ejerca la Oficina Central de Estadstica e Informtica
(OCEI), as como las siguientes:
52
1. Actuar como organismo rector del Ejecutivo Nacional en materia de
tecnologas de informacin.
2. Establecer polticas en torno a la generacin de contenidos en la red,
de los rganos y entes del Estado.
3. Establecer polticas orientadas a resguardar la inviolabilidad del
carcter privado y confidencial de los datos electrnicos obtenidos en
el ejercicio de las funciones de los organismos pblicos.
4. Fomentar y desarrollar acciones conducentes a la adaptacin y
asimilacin de las tecnologas de informacin por la sociedad.
En correspondencia con ambos artculos artculo el presente proyecto se ajusta a las

aspiraciones de la ley por cuanto su desarrollado atiende a los lineamientos establecidos
por la OCEI.
D. Decreto N 3.390 de la Presidencia de la Repblica Bolivariana de Venezuela Gaceta

38.095 del 28/12/2004), sobre uso del Software Libre.
La Administracin Pblica Nacional emplear prioritariamente Software

Libre desarrollado con Estndares Abiertos, en sus sistemas, proyectos y
servicios informticos. A tales fines, todos los rganos y entes de la
Administracin Pblica Nacional iniciarn los procesos de migracin
gradual y progresiva de stos hacia el Software Libre desarrollado con
Estndares Abiertos.
El proyecto en referencia se ajusta a tales requerimientos como alternativa para

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

aprovechando diferentes estndares, convenciones, reglas y procesos, permite
53
integrar una amplia gama de productos y servicios informticos, de manera que
pueden ser utilizados eficazmente dentro de la organizacin. (Vega, E., 2005, p3)
Caso de uso: Es una secuencia de acciones que el sistema lleva a cabo para ofrecer
algn resultado de valor para un actor. Un actor puede ser una persona humana, un
dispositivo de hardware, u otro sistema. Los actores utilizan el sistema interactuando
con los casos de uso. (Jacobson, I., 2000, p.54).
Cliente: Es el que inicia un requerimiento de servicio. El requerimiento inicial puede

convertirse en mltiples requerimientos de trabajo a travs de redes LAN o WAN. La
ubicacin de los datos o de las aplicaciones es totalmente transparente para el cliente.
(Gutirrez, J., 2005, p3)
Business: Negocio.
Implementacin: es la realizacin de una aplicacin, o la ejecucin de un plan, idea,

modelo cientfico, diseo, especificacin, estndar, algoritmo o poltica.En ciencias
de la computacin, una implementacin es la realizacin de una especificacin
tcnica o algoritmos como un programa, componente software, u otro sistema de
cmputo. (Retamozo, P., 2003)
Navegador Web: es una aplicacin software que permite al usuario recuperar y

visualizar documentos de hipertexto, comnmente descritos en HTML, desde
servidores web de todo el mundo a travs de Internet. (Wikipedia, 2008)
Servidor: Es cualquier recurso de cmputo dedicado a responder a los requerimientos

del cliente. Los servidores pueden estar conectados a los clientes a travs de redes
LANs o WANs, para proveer de mltiples servicios a los clientes y ciudadanos tales
como impresin, acceso a bases de datos, fax, procesamiento de imgenes,
etc.(Gutirrez, J., 2005, p3)
54
Sistema de Informacin: Es un conjunto de personas, datos y procedimientos que
funcionan en conjunto. Un sistema de informacin ejecuta tres actividades generales.
En primer trmino recibe datos de fuentes internas o externas a la organizacin como
elementos de entrada. Despus, acta sobre los datos para producir informacin.
Finalmente el sistema produce la informacin para el futuro usuario, que tal vez sea
gerente, administrador o un miembro de la direccin. (Retamozo, P., 2003)
Software de dominio pblico: Es aqul que requiere de licencia y cuyos derechos de

explotacin son para toda la humanidad, porque pertenece a todos por igual.
(Wikipedia, 2008)
Software Libre: Es un software o programa de computacin cuya licencia nos

permite ejercer una serie de libertades. (Wikipedia, 2010)
55
CAPITULO IV
MARCO METODOLGICO
4.1. Tipo y Nivel de la Investigacin
..tipo de Investigacin Interactiva, de la cual Hurtado (2000) expresa que: va

dirigida a modificar situaciones concretas a travs de la aplicacin de proyectos
previamente diseados. (p. 49). La misma atura seala:
Implica la realizacin de acciones por parte del investigador, ya sea solo o

conjuntamente con algn grupo o comunidad, con el propsito de
modificar una situacin o evento. Para llevar a cabo una investigacin
Interactiva es necesario partir de un proceso de indagacin y explicacin,
visualizar posibilidades futuras, planificar un conjunto de actividades o
disear alguna propuesta, y posteriormente llevarla a cabo. (p. 351).
Es evidente que el trabajo que se desarrolla se corresponde con la definicin de

Investigacin Interactiva antes sealado, esto si se toma en cuenta que permitir crear
una solucin, apoyada en el uso de mtodos y herramientas tericamente sustentadas
para modificar una situacin y que la misma se basar en el desarrollo de un diseo
que ser llevado a cabo.
Por el tipo de investigacin, el estudio se ubica dentro de un Nivel Integrativo,

el cual Hurtado (2000), define como aquel que "contempla acciones directas por
parte del investigador, sobre el evento de estudio, estas acciones van dirigidas a
transformar o modificar el evento en algn aspecto" (p. 19).
56
4.2. Poblacin y Muestra
4.2.1. Poblacin
De acuerdo con el criterio Hernndez, R., et al (2006), la poblacin es el

conjunto de todos los casos que concuerdan con una serie de especificaciones .
(p.238). En relacin a lo expuesto este conjunto de elementos pueden ser
personas, casos, objetos, instituciones y otros, se seleccionan de ac uerdo a la
naturaleza del problema y los objetivos de la investigacin.
En efecto, para este estudio la poblacin est constituida por 16

funcionarios relacionados con las actividades administrativas que se realizan
en el Servicio Mdico de la Universidad de Oriente Ncleo Monagas, dado que
son las personas que manejan los procedimientos administrativos y que
conocen la realidad y por lo tanto los requerimientos para elaborar un nuevo
sistema.
4.2.2. Muestra
La muestra es definida como el subgrupo de la poblacin de inters, sobre la

cual se recolectan datos, debiendo esta ser representativa de la poblacin. (Ibdem,
p.236). Ello implica que cuando la muestra es representativa de la poblacin, los
resultados pueden generalizarse a todo el problema en estudio.
En consecuencia, por ser la poblacin un conjunto pequeo, pueden estudiarse

todos los elementos que la componen, segn sus caractersticas particulares. Esta
decisin se basa en el criterio expuesto por Balestrini, M., (2006) (ob, cit), cuando
seala que: Con excepcin de los casos o universos pequeos, es importante
seleccionar sistemticamente en una muestra, cada unidad representativa de la
poblacin, atendiendo a un criterio especfico y en condiciones controladas por el
investigador (p. 138). En caso de esta investigacin la poblacin ser igual a la
muestra, es decir, 16 funcionarios del Servicio Mdico de la Universidad de Oriente
Ncleo Monagas.
57
4.3. Tcnicas e Instrumentos de Recoleccin de Datos.
Para la recoleccin de los datos fue necesario aplicar algunas tcnicas que a
travs de instrumentos permitieran recabar la informacin necesaria para determinar
las caractersticas y requerimientos del desarrollo del sistema en relacin con las
necesidades evidenciadas en los procesos administrativos del Servicio Mdico de la
Universidad de Oriente, Ncleo Monagas.
Arias, F., (2006) en relacin a las tcnicas refiere que Se entender por
tcnica, el procedimiento o forma de recoger los datos (p.68), es decir la tcnica
obedece a una manera o tctica utilizada por el investigador, de acuerdo con la
disciplina o mbito de investigacin, de cual ste se vale para obtener la
informacin. El instrumento es considerado como Cualquier recurso, dispositivo o
formato (en papel o digital), que se utiliza para obtener, registrar o almacenar
informacin (Ibdem, p.69). De esta manera el instrumento viene a constituirse en
una herramienta que concreta los resultados concebidos bajo una tcnica
determinada. En el caso de esta investigacin, tipificada como de campo y
documental, se utilizaron las siguientes tcnicas e instrumentos:
En el primer tipo, es decir, para la investigacin de campo, se utiliz la

tcnica de la observacin y la entrevista no estructurada apoyada en instrumentos
como el diario de campo y la libreta de notas.
La observacin es una tcnica que consiste en visualizar o captar

mediante la vista, en forma sistemtica, cualquier hecho, fenmeno o
situacin que se produzca en la naturaleza o en la sociedad, en
funcin de unos objetivos de investigacin preestablecidos. (Ibdem,
p. 69)
Lo anterior implica que el investigador se constituye en el principal factor
para la captacin de la informacin.
La entrevista, ms que un simple interrogatorio, es una tcnica basada

en el dilogo o conversacin cara a cara, entre el entrevistador y el
entrevistado acerca de un tema previamente determinado, de tal manera
que el entrevistador pueda obtener la informacin requerida. (Ibdem,
p.73)
58
Las preguntas se realizaron de manera libre y espontnea fundamentadas en
dilogos y conversaciones con el personal del servicio mdico.
En el segundo caso, se utiliz la tcnica del anlisis de contenido el cual permiten

medir, ordenar, clasificar, codificar e interpretar el comportamiento de las variables
objeto de estudio. El anlisis facilita llegar a las conclusiones o resultados del estudio;
como instrumento se utilizaron los cuadros de registro diarios aportados por el personal
que labora el Servicio Mdico y los cuales estn relacionados con: pacientes atendidos en
el servicio mdico, clasificacin segn la especialidad y tipo de usuario, nmero de
pacientes atendidos por cada mdico, morbilidad, registro de boletas y de facturas
conformadas. (Ibdem, p.103)
4.4. Diseo Operativo
Para el logro de los objetivos planteados, se utilizar el mtodo GRAY

WATCH, por ser un mtodo de desarrollo de software configurable que se adapta a
travs de los proyectos variados en tamaos y complejidad, que adems, describe que
se debe hacer y cmo se debe desarrollar la aplicacin. Este mtodo establece las
actividades los procesos, las prcticas, las tcnicas, los estndares, y las herramientas
que se deben emplear para desarrollar los componentes arquitectnicos de la
aplicacin e integrarla al sistema de negocio para el cual es desarrollada.
El desarrollo del proyecto abarcar todo el ciclo de vida de las aplicaciones;

desde el modelado del dominio de la aplicacin, pasando por la definicin de los
requisitos de los usuarios, hasta la puesta en operacin del sistema. Adems tambin
se realizarn los procesos de gerencia del proyecto, que se encargan de gerenciar el
desarrollo de la aplicacin, involucran las actividades de constitucin, planificacin,
direccin y control del proyecto. Por su parte, los procesos de soporte complementan
los procesos tcnicos y gerenciales con actividades, tales como: el aseguramiento de
la calidad, la gestin de la configuracin y la gestin de riesgos del proyecto.
El proyecto est dividido en cuatro (4) etapas:
59
Etapa I: Inicio y constitucin del proyecto
En esta primera etapa se hace una revisin del modelado negocio, en este caso
del rea de servicios mdicos de la Universidad de Oriente ncleo Monagas, para
conocer los procesos que realiza el personal que labora en esta rea de trabajo. Luego
de revisar el sistema del negocio se procede a realizar la instanciacin del mtodo
GRAY WATCH, y adaptarla a las caractersticas particulares de la aplicacin y a las
condiciones existentes en el rea de servicios mdicos. Tambin se incluyen las
actividades encargadas de la planificacin del alcance, de tiempos, de gestin de los
riesgos, configuracin del software, aseguramiento de la calidad, otros recursos y
servicios que requiera el desarrollo de la aplicacin. En esta etapa se realiza el
modelado de negocio para realizar el modelado del negocio se estudiar y analizar el
sistema de negocio de: rea de Servicios Mdicos de la universidad de oriente ncleo
Monagas, con el objetivo de comprender los problemas que motivan el desarrollo de
la aplicacin y facilitar la identificacin de las necesidades de informacin que tienen
los futuros usuarios del sistema
Etapa II: Procesos de diseo, de gestin y de soporte
Una vez constituido el proyecto, se da inicio a sus procesos tcnicos

conformados por los procesos de anlisis, diseo e implementacin, en esta segunda
etapa se desarrollan los procesos de anlisis conjuntamente con los procesos de
gestin y de soporte. Los procesos de anlisis cubren la Ingeniera de Requisitos se
va a revisar, analizar, especificar, validar y gestionar los requisitos que se le imponen
a la aplicacin.
Etapa III: Procesos de construccin, de gestin y de soporte
En esta etapa, se continan con los procesos tcnicos relacionados con el

cmo debe ser construido el nuevo sistema, este grupo de procesos est compuesto
por los procesos de diseo arquitectnico y diseo detallado. Las actividades que se
llevarn a cabo en el proceso de diseo arquitectnico comprenden: establecer el
60
conjunto de componentes que integran el sistema, definir los estndares de diseo,
disear la arquitectura del sistema. Todo lo referente a diseo detallado comprende
las actividades del diseo de la interfaz usuario/sistema, diseo de la base de datos del
sistema y especificacin de los componentes arquitectnicos que conformarn el
sistema para que ste satisfaga los requisitos establecidos.
Etapa IV: Procesos de implementacin.
Es la ltima etapa del proyecto y constituye la entrega de la aplicacin

desarrollada. El proceso tcnico de implementacin involucra los procesos
relacionados con la programacin, las pruebas y puesta en operacin del sistema. En
el proceso de programacin e integracin se realiza la codificacin y prueba unitaria
de cada uno de los componentes de software que integran la arquitectura de la
aplicacin, as como la integracin y prueba de estos componentes.
Seguidamente se realizan pruebas de la aplicacin como un todo, incluyendo

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

puesta en produccin del nuevo sistema en su plataforma de operacin. Este proceso
incluye la capacitacin de usuarios, la instalacin del sistema, las pruebas de
61
instalacin y la entrega final del producto. A continuacin se muestra el cuadro
operativo y cronograma de actividades que especifican las fechas y las actividades
que se llevaran a cado en cada una de las etapas del desarrollo del proyecto y que se
han mencionado en esta descripcin del trabajo.
62
4.5. Cuadro Operativo
Etapas Metodologa/ Actividades Productos Generados Objetivos especficos

Herramienta
Adaptar el mtodo GRAY WATCH a las caractersticas particulares y a las
condiciones existentes en el rea de servicios mdicos. Documento de instanciacin
Revisar y conocer las condiciones existentes en el rea de servicios mdicos para el del mtodo.
momento en que se desarrolla la aplicacin.
Describir de manera general el sistema que se va a desarrollar. Documento enunciado del
trabajo del proyecto. 1. Estudiar el modelo de negocio
Establecer la necesidad y el alcance de la aplicacin que se quiere desarrollar. Documento de inicio del del rea de servicios mdicos,
Mtodo Watch proyecto. para obtener una visin del
I
Describir las actividades que componen cada uno de los procesos. sistema a nivel conceptual.
Definir los recursos humanos, tecnolgicos, financieros, fsicos y materiales Plan integral del proyecto.
Anlisis del necesarios para desarrollar las actividades.
sistema Identificar, describir y evaluar los riesgos inherentes a la aplicacin empresarial. Plan de Gestin de Riesgos
Procesos de Describir las actividades para controlar la configuracin del software. Plan de Gestin de la
gestin y configuracin
soporte Plan de gestin de
Establecer, organizar y programar las actividades necesarias para asegurar la calidad Aseguramiento de la Calidad.
del software.
2. Determinar los requisitos del
Estudiar y analizar a profundidad el modelado del negocio, especificar cada uno de Modelo del negocio. sistema funcionales y no
sus procesos. funcionales, fortaleciendo y
complementando el modelo
Aplicar entrevistas no estructuradas al personal del rea de servicios mdicos. actual.
Observacin directa.
Revisar, analizar, describir, especificar y validar cada uno de los requisitos
funcionales y no funcionales del sistema.
Documento de requisitos
Documentar los requisitos funcionales.
Elaborar y refinar los diagramas de caso de uso.
Cuadro operativo 1/2. Fuente: autor (2010).
63
Etapas Metodologa/ Actividades Productos Generados Objetivos especficos
Herramienta
Definir los estndares de diseo de la aplicacin. Documento de diseo
arquitectnico.
Establecer la arquitectura de la aplicacin. 3. Formular la arquitectura que
II debe tener el sistema a desarrollar
Diseo del Mtodo tomando en cuenta los requisitos
sistema Watch Especificar los componentes arquitectnicos que conformarn la aplicacin Documento de diseo funcionales y no funcionales.
UML empresarial para que sta satisfaga los requisitos establecidos. detallado
Procesos de 4. Construir el sistema con base
construccin, Disear la interfaz usuario/sistema. a la arquitectura diseada.
gestin y soporte
Codificar o programar cada uno de los componentes que integran las diferentes
versiones de la aplicacin empresarial. Plan de verificacin y
validacin
III 5. Implementar el sistema, ya
Realizar las pruebas funcionales, no- funcionales y de aceptacin. Plan de pruebas. probado en su plataforma de
Implementacin
del sistema operacin.
Mtodo Verificar cada versin de la aplicacin como un todo y depurar los errores
Watch encontrados. Especificaciones de prueba.
Procesos de UML
implementacin. 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
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 1.0
Autor Fecha Versin Descripcin
Lolimar Cedeo M. 29-8-09 0.90 Versin preliminar como propuesta de desarrollo
Lolimar Cedeo M. 9-10-09 0.91 Correcciones de versin preliminar
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
69
consultas de pacientes.
D. Administracin: configurar los usuarios del sistema y efectuar modificaciones.
E. Validar usuarios: permitir el ingreso de los usuarios finales del sistema.
El sistema realizar validaciones, lo que permita minimizar la duplicacin de

trabajo, contar con un mdulo de administracin que permitir configurar los
usuarios y monitorear los accesos, tendr una base de datos actualizada y segura para
almacenar informacin en cualquier momento, permitir la automatizacin de
procesos para facilitar el flujo de entradas y salidas del sistema, y en l se podr
visualizar e imprimir 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.
70
5. Visin del Negocio
La Universidad de Oriente Ncleo Monagas, Cuenta actualmente con una

poblacin Estudiantil alrededor de 18.000 estudiantes, por ello cuenta con una
Delegacin de Desarrollo estudiantil que estudia al educando dentro de su dimensin
social con la finalidad de ofrecer diversas vas de solucin a los problemas que
interfieren en su adecuado funcionamiento acadmico y social. Dentro de esta
dependencia se encuentra el rea de servicios mdicos-odontolgicos el cual brinda
atencin mdica preventiva .
Actualmente la poblacin universitaria est en constante crecimiento y

dinamismo la cual representa una gran demanda, el rea de servicios mdicos est
constituida por quince (15) funcionarios relacionados con las actividades
administrativas que se realizan en el mismo, estas personas manejan los
procedimientos administrativos y conocen la realidad, por lo tanto, son los indicados
transmitiendo requerimientos necesario para elaborar un nuevo sistema. Los actores
que rigen el curso de las actividades y que modelan el comportamiento del negocio
dentro del rea de servicios mdico se detallan a continuacin precisando el nmero
de personas que ocupan cada cargo:
01 jefe de departamento
01 jefe de enfermera
04 Enfermeras
01 Auxiliar de Registros y Estadsticas
01 Higienista Dental
01 Secretaria 02 Odontlogos
01 Pediatra
06 Mdicos: 01 Internista
01 Medicina General
01 Gineclogo
71
6. Necesidad de Desarrollar el Sistema
La siguiente investigacin se plantea para dar seguimiento al trabajo de grado

realizado por Cabello, M. (2009) titulado: Sistema automatizado basado en
software libre para optimizar los procesos administrativos de los servicios mdicos de la
Universidad de Oriente ncleo Monagas, este trabajo concluy en la fase de
construccin de la metodologa RUP (Proceso Unificado Racional), y no se pudo
lograr la implementacin debido a que el tiempo establecido no fue lo suficiente para
el desarrollo del sistema. Gran parte del su trabajo estuvo basado en mucha
investigacin y documentacin, sin embargo se realizo la codificacin o desarrollo de
algunos mdulos pero no se llego a concretar la funcionabilidad del sistema,
quedando la culminacin de lo propuesto incompleto.
Por las razones expuestas, se hace pertinente retomar el proyecto, culminar la

fase de construccin del sistema, realizar su implementacin y llevarlo a hasta su
culminacin, con la finalidad de poder brindarle al servicio mdico una aplicacin
completa que optimice la totalidad de sus procesos administrativos, desempendose
en un ambiente de trabajo automatizado y organizado.
Actualmente el Servicio Mdico aunque cuenta con los recursos tecnolgicos

que faciliten el desempeo de las labores del personal y no cuenta con el software que
permita controlar cada unos de los procesos administrativos que all se realizan, los
cuales involucran: registro de usuarios del servicio, apertura de historias mdicas,
emisin de rcipes para compra de medicamentos, control de consultas, remisin de
pacientes que requieren atencin especializada u exmenes de laboratorios cuya
respuesta no pueda ser canalizada a travs de los Servicios Mdicos, as como
tambin, llevar la relacin de los mismos, a objeto de validar la cancelacin de tales
servicios ante la Delegacin de Presupuestos de dicha institucin.
72
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
Elaborar el Plan Integral del Proyecto de desarrollo de la aplicacin
empresarial que le sea asignada
Lder del proyecto 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
Analista de negocios sistema de negocios que acta como dominio de la aplicacin.
Descubrir, analizar, especificar y documentar los requisitos de la aplicacin.
Validar, en conjunto con los usuarios, los requisitos establecidos.
Analista de requisitos Gestionar los requisitos.
Especificar requisitos arquitectnicos.
Disear y evaluar la arquitectura de la aplicacin.
Arquitecto de software Especificar cada una de las vistas arquitectnicas.
Diseador de software 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.
Programador 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
Especialista V&V aceptacin de la aplicacin.
Gestor de configuracin de Gestionar los tems producidos durante el desarrollo y controlar los cambios
software 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.
Gestor de calidad Asegurar la calidad del software.
Tabla 5: Interesados (stakeholders) del proyecto. Fuente: Autor (2010)
Definimos qu papel desempea cada interesado (stakeholders) del proyecto:
73
Nombre Responsabilidades
Ing. Rosngela Garcia Lder del proyecto
Ing.Yhuanailys Nuez Responsable General del proyecto

Analista de negocios
Analista de sistemas
Arquitecto de software
Diseador de software
Br. Lolimar Cedeo Programador
Especialista Verificacin & Validacin
Ing. Yhuanailys Nez. Gestor de calidad
Gestor de configuracin de Software
Tabla 6: identificacin de Interesados del proyecto. Fuente: Autor (2010)
8. Restricciones, Costos y Recursos
Restricciones
Los participantes estarn constituidos por personal de la seccin de Programas

y Proyectos del Centro de Computacin de la UDO-Ncleo de Monagas, as como los
responsables del rea de servicios mdicos, y otros participantes que se estimen
convenientes para proporcionar los requisitos y validar el sistema: Responsable de
Proyecto, Lder de Proyecto y Usuarios.
El sistema est siendo desarrollado en la Universidad de Oriente ncleo

Monagas, haciendo uso de la tecnologa de esta casa de estudio, basndose en los
lenguajes de programacin Php 5, Javascript, Java, html. Las restricciones de
infraestructura estarn dentro de requisitos legales o normas, aplicacin de
estndares, requisitos de calidad del producto, tales como: confiabilidad, desempeo,
etc., u otros requisitos de ambiente, tales como: sistema operativo, requisitos de
compatibilidad, etc.
Costos
Los costos de produccin representan la inversin inicial que realiza el

desarrollador o el equipo de trabajo durante la construccin del software, esto
incluye costos de: infraestructura, personal, adiestramientos, cursos o talleres
74
necesarios para la capacitacin del personal involucrado y materiales utilizados.

Entre estos costos tenemos:
A. Costos de equipos y herramientas de trabajo: estos costos se generan por el

hardware y el software utilizado durante el desarrollo del proyecto. Debido a que el
centro de computacin cuenta con el equipo y las herramientas de trabajo que se
utilizara, no se tendr ningn tipo de gasto en relacin a esto.
B. Costos de infraestructura: los costos de infraestructura se determinan a travs de los

gastos generados al contar con un ambiente de trabajo apto para los equipos y por el
mobiliario requerido para cada uno de ellos. El centro de computacin cuenta con
un rea de trabajo apta para los equipos, por lo que no se tendr gastos de
infraestructura.
C. Costos de personal: incluye los sueldos de los empleados cuyos esfuerzos se

encuentran directamente asociados al proyecto. Durante el desarrollo del sistema, se
requiere la participacin de dos (02) empleados del centro de computacin; el jefe
del centro y el jefe de programas y proyectos especiales, cuyos respectivos salarios
sern cancelados por la Universidad, adems del trabajo no remunerado realizado
por el autor en calidad de pasante. Tomando en consideracin que el sueldo
promedio mensual en la Universidad de Oriente es de mil setecientos setenta (1770)
Bs.F., es decir, que un da de trabajo de ocho (8) horas equivale a ochenta y ocho
punto cinco (88. 5) Bs.F., y estimando que los empleados del centro de computacin
trabajaron aproximadamente setenta (70) das o lo que es igual a quinientas sesenta
(560) horas de trabajo, se obtiene un aproximado de seis mil ciento noventa y cinco
(6.195) Bs.F. en costos de personal.
D. Costos de adiestramientos: estos costos se refieren a los generados por las tcnicas
de capacitacin y aprendizaje, como una herramienta para que el personal
involucrado en el proyecto adquiera los conocimientos necesarios que le permitan
75
desarrollar y ampliar aptitudes y actitudes para realizar el trabajo de la manera

correcta. Las tcnicas de capacitacin empleada sern los talleres y cursos de UML,
Power Designer, WATCH, PHP y Macromedia Dreamweaver, dictados por el
personal del Centro de Computacin de la Universidad de Oriente Ncleo Monagas.
E. Costos de materiales que se utilizaran: representan los costos relacionados a la

compra de resmas de papel, carpetas, ganchos de carpetas, cartuchos de tinta para
impresin, libretas de anotaciones, lapiceros entre otros. Recalcando que estos
materiales sern en su mayora suministrados por el propio pasante.
9. Supuestos Ambientales
Adems del analista y del cliente, el ambiente puede implcita o explcitamente

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

investigacin de mercado o modelo de negocio.
B. Se debe implantar un sistema automatizado que abarque la gran demanda poblacional

que tiene la Universidad de Oriente ncleo de Monagas.
C. Se deben conocer los sistemas que se han desarrollado en el ncleo, ya que estos
ayudarn a definir los requerimientos del sistema, para mantenerse competitivo en
76
cuanto a funcionalidad, confiabilidad, durabilidad, mantenimiento y seguridad del

sistema.
D. Se deben dar las condiciones e instalaciones fsicas necesarias para mantener equipos
de computacin dentro del rea de servicios mdicos.
Los requerimientos del sistema estn influenciados directamente por los

usuarios quienes tienen que estar conforme a los estndares y reglamentos tcnicos
dictados por el centro de computacin; ya que es la dependencia que determina las
polticas tcnicas, estndares asociados y los lineamientos que ayudan a asegurar:
consistencia, seguridad, confiabilidad y mantenimiento del sistema.
La influencia cultural debe ser considerada al desarrollar el sistema porque

puede afectar los requerimientos de ste. Muchas personas no se adaptan a los
avances tecnolgicos y mucho menos a utilizarlos para agilizar las actividades
laborales. Es un supuesto creer y confiar que el personal que labora en el rea de los
servicios mdicos har uso pleno del sistema automatizado que se le pretende
implementar.
77

administrativos del rea servicios mdicos de la universidad de oriente ncleo Monagas .
DOCUMENTO PROCESO DE INSTANCIACION DEL MTODO
VERSIN 1.0
Lolimar Cedeo M. 29-8-09 0.90 Versin preliminar como propuesta de
desarrollo
Lolimar Cedeo M. 27-10-09 1.0 versin preliminar
10. Introduccin
Este documento presenta la instanciacin del mtodo, el cual consiste en adaptar

el conjunto de procesos y actividades prescritas por el mtodo, a las caractersticas
particulares del sistema que se va a implementar. Para realizar la adaptacin se toma
en cuenta tanto las condiciones existentes en el ambiente de trabajo como la
complejidad de la aplicacin; es decir, el proceso de ajuste del mtodo considera las
caractersticas del producto que se desea desarrollar y del ambiente organizacional de
implantacin para establecer el equipo de trabajo requerido y el proceso que debe
seguirse.
11. Procesos que se generan en el proyecto
Con el objeto de facilitar su descripcin, estos modelos de procesos se han

organizado en tres grupos (ver figura 16). El grupo de Procesos Tcnicos enmarcan
todas las actividades de ingeniera que estn relacionadas directamente con el ciclo de
desarrollo de las aplicaciones. El grupo de Procesos de Gestin cubre todas las
actividades de gestin de proyectos de software. El grupo de Procesos de Soporte
concentra todas aquellas actividades que son necesarias para apoyar la ejecucin de
los procesos tcnicos y gerenciales. Para el desarrollo del proyecto se van realizar
todos los procesos del mtodo WATCH que se muestran a continuacin:
78
Figura 16: Clasificacin de los procesos del Mtodo WATCH durante el desarrollo del
proyecto. Fuente: autor (2010)
Una vez que los modelos de productos, procesos y actores han sido
instanciados se debe asegurar que el mtodo resultante de la integracin de estos tres
modelos, permitir verdaderamente desarrollar el proyecto. Para ello se debe revisar
la correspondencia entre los conceptos predefinidos en el mtodo y el subconjunto de
conceptos utilizados durante la adaptacin; verificar la consistencia y la coherencia de
las interacciones establecidas entre los diferentes modelos de la adaptacin del
mtodo, asegurar la consistencia entre modelo de producto y de proceso y garantizar
la correspondencia entre actores y actividades del proceso.
79
Para comenzar se verifica la coherencia entre el modelo de productos y el

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

de servicios mdicos que optimice la gestin de los procesos administrativos de la
UDO-Monagas, los procesos tcnicos se van a ejecutar a partir de los procesos de
implementacin, atendiendo a que el proyecto es una continuacin del desarrollo del
sistema; los procesos de implementacin son programacin & integracin, pruebas y
entrega de la aplicacin. Sin embargo para asegurar la consistencia del desarrollo del
sistema es necesario realizar revisiones y verificaciones de los procesos de anlisis
(modelado del negocio, ingeniera de requisitos) y un fortalecimiento de los procesos
de diseo (diseo arquitectnico y diseo detallado).
Los productos del proceso de soporte forman parte del Plan Integral del
Proyecto estos procesos son: Gestin de la configuracin, Gestin de la calidad y
Gestin de riesgos. Del proceso de soporte se van a ejecutar los tres procesos que a
su vez generan los productos que ya hemos instanciado. Del proceso de Gestin de
Riesgos se obtiene el producto plan de gestin de riesgos. El plan de gestin de la
configuracin es el resultado de la ejecucin del proceso de Gestin de la
80
Configuracin del Software. A su vez se realizan los procesos de Aseguramiento de

la calidad del software y de verificacin & validacin los cuales producen el plan de
aseguramiento de la calidad del software.
En la validacin de la instanciacin tambin se debe garantizar la

correspondencia entre actores y actividades del proceso; para los respectivos procesos
de gestin y procesos tcnicos se cuenta con el desarrollador que ejecuta la gestin,
anlisis, diseo y programacin. Para los procesos de soporte el gestor de
configuracin llevar a cabo las actividades inherentes a estos procesos y tambin el
desarrollador quien realiza la gestin de la calidad del software y la gestin de los
riesgos del proyecto. Conjuntamente se cuenta con el comit directivo del proyecto y
el lder del proyecto que forman por completo la organizacin del equipo de trabajo.
12. Productos que se generaran en el proyecto
El modelo de producto identifica y describe los tipos de productos que se pueden

generar durante el desarrollo del proyecto: Implementacin de un sistema
automatizado de servicios mdicos que optimice la gestin de los procesos
administrativos de la Universidad de Oriente ncleo Monagas. Estos tipos de
productos son el resultado parcial o final de la ejecucin de los procesos tcnicos, de
gestin o de soporte.
Para hacer la instanciacin del modelo de productos se elabora una lista de los
productos concretos que se producirn durante el desarrollo del proyecto y describe
las caractersticas particulares del proyecto para automatizar los procesos
administrativos del rea de servicios mdicos de la Universidad de Oriente ncleo
Monagas. El modelo de productos est compuesto por tres tipos de productos:
tcnicos, de soporte y de gestin, a continuacin se muestra la lista de los productos
que se producirn durante todo el proceso de desarrollo del proyecto para la
81
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 y 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
82
tiempo, el mtodo permite distinguir los productos segn el grupo de procesos que los
producen; es decir, hay productos resultantes de los procesos tcnicos o de ingeniera,
otros son resultantes de los procesos de gestin del proyecto y otros de los procesos
de apoyo al proceso de desarrollo:
Producto
WATCH
Producto Intermedio Producto Entregable
Producto Producto de Producto de Aplicacin

Tcnico Gestin Soporte Empresarial
Figura 17: Principales tipos de productos del mtodo WATCH. Fuente: autor (2010)
La instanciacin del modelo de producto da como resultado los productos

concretos que se van a producir durante todo el proceso de desarrollo del sistema del
rea de servicios mdicos UDO-Monagas.
83

administrativos del rea servicios mdicos de la universidad de oriente ncleo Monagas
PLAN INTEGRAL DEL PROYECTO
VERSIN 1.0
Lolimar Cedeo 29-8-09 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
84
respecta a tiempos, riesgos y cambios. Todo proyecto de software es susceptible a

riesgos los cuales si llegan a concretarse afectan los tiempos de ejecucin de las
actividades y producen cambios en el proyecto, por esto los objetivos que se
persiguen con los diferentes planes que se realizan son los siguientes:
1. Asegurar que el desarrollo de la aplicacin sea sistemtico, organizado, eficaz

y eficiente, mediante el empleo de los procesos de planificacin, direccin y
control.
2. Garantizar que la aplicacin se desarrolle a tiempo y siguiendo los estndares

y procedimientos establecidos para asegurar la calidad de la aplicacin.
3. Manejar apropiadamente los riesgos que puedan surgir durante el desarrollo

de la aplicacin y que puedan afectar los objetivos del proyecto.
4. Controlar la configuracin de la aplicacin.
15. Recursos Necesarios
3.1 Recursos Humanos
El equipo de trabajo est representado de la siguiente manera:
Se requiere primeramente del Ing. Rosngela Garca cuya responsabilidad es

de ser el lder del proyecto: es la persona que elabora el Plan Integral del Proyecto de
desarrollo de la aplicacin, presta asistencia tcnica a los miembros del equipo de
desarrollo, dirige y controlar la ejecucin del Plan Integral del Proyecto y es la
responsable general del proyecto ante el centro de computacin de la universidad de
oriente ncleo de Monagas, esta persona valida cada uno de los documentos.
Se requiere de asesoramiento e instrucciones del Ing. Yhuanailys Nez, pues

desempea el papel de gestor de calidad y gestor de configuracin de software en el
proyecto. Es la persona que define los lineamientos a seguir para el desarrollo de las
versiones. Finalmente la elaboracin del proyecto estar a cargo de de la Br. Lolimar
85
Cedeo quien es la persona encargada de la elaboracin del proyecto, desempea

papeles como: Analista de negocios, Analista de sistemas, Arquitecto de software,
diseador de software, programador y especialista en verificacin & validacin de
software.
Recursos Tecnolgicos
Para garantizar un rendimiento adecuado del sistema propuesto es necesario que
los equipos hardware donde se van a instalar y operar el sistema cumplan con los
siguientes requerimientos unidad central de procesamiento (CPU) Pentium IV, se
recomienda 1024 megabyte (MB)/1 GB de memoria RAM, Disco Duro de 160 GB y
Sistema operativo Windows XP. Servidor Apache, PHP, Macromedia Dreamweaver,
Sybase, Power Designer, Editor de Texto y un Navegador Web.
Recursos Materiales
Los miembros de trabajo del proyecto deben contar con resmas de papel tipo
carta, cartuchos de impresin, carpetas, lpices, lapiceros y marcadores, libreta de
anotaciones, CD-ROM, guas didcticas con informacin sobre el mtodo de
desarrollo, material de apoyo y textos varios sobre los procesos y actividades a
desarrollar.
16. Estndares y procedimientos

Normas de calidad:
Norma de calidad ISO-9126:
La ISO, bajo la norma ISO-9126, ha establecido un estndar internacional para la

evaluacin de la calidad de productos de software el cual fue publicado en 1992 con
el nombre de Tecnologa de la informacin de evaluacin de productos de software:
caractersticas de calidad y directrices para su uso, en el cual se establecen las
caractersticas de calidad para productos de software. El estndar ISO-9126 establece
que cualquier componente de la calidad del software puede ser descrito en trminos
86
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..
87
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 e

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.
88
La Administracin Pblica Nacional emplear prioritariamente Software Libre

desarrollado con Estndares Abiertos, en sus sistemas, proyectos y servicios
informticos. A tales fines, todos los rganos y entes de la Administracin
Pblica Nacional iniciarn los procesos de migracin gradual y progresiva de
stos hacia el Software Libre desarrollado con Estndares Abiertos.
Manuales
GRAY WATCH Mtodo de Desarrollo de Software de Aplicaciones Empresariales,

2008 Jons Montilva, Judith Barrios y Milagro Rivero:
Este documento tiene por objetivos describir, en detalle, el mtodo WATCH de

tal manera que los equipos de desarrollo puedan utilizarlo como un patrn
metodolgico que les ayude a definir el proceso especfico de desarrollo de cada
una de las aplicaciones de una empresa.
Modelado de sistemas usando UML 2.0, Jons Montilva e Isabel Besembel:
Es una gua que describe el modelado de sistemas con las notaciones en UML
2.0 y el modelado de sistemas de negocios con UML Bussines. Esta dirigido a
ensear al desarrollador de sistemas como usar este lenguaje en el proceso
desarrollo de software y como modelar los diferentes aspectos que caracterizan a
un sistema de informacin o aplicacin de software.
Ingeniera de requisitos, Jons Montilva, CeiSoft:
Es una gua que detalla las generalidades involucradas en el proceso de

ingeniera de requisitos como la especificacin, documentacin y representacin
usando notaciones en UML 2.0.
89
17. Planes
5.1. PLAN DE GESTIN DE TIEMPO

Este plan establece las actividades necesarias para elaborar el cronograma del
proyecto. Describe tambin, el formato para elaborar el cronograma y los criterios y
supuestos que se deben considerar para programar las actividades del proyecto. Una
vez que el o los cronogramas del proyecto se elaboren, ellos pasan a formar parte del
Plan de Gestin de Tiempos. El objetivo de la planificacin de tiempos es estimar el
tiempo de ejecucin de las actividades del proyecto, a fin de producir el cronograma
que guiar y controlar la ejecucin del proyecto. El cronograma general del proyecto
identifica y organiza las actividades del proyecto en funcin de sus fechas de inicio y
terminacin. A continuacin se muestra el plan de tiempo del proyecto:
Tabla 9: Plan de tiempo del proyecto1/4.
90
Tablas 9: Plan de tiempo del proyecto 2/4.
91
92
5.2 PLAN DE GESTIN DE RIESGO
La Planificacin de la Gestin de Riesgos tiene como objetivo definir las

actividades, recursos, responsabilidades, costos, tiempos que son necesarios para
evaluar y responder a los riesgos del proyecto de servicios mdicos de manera
organizada. El proceso comienza considerando las caractersticas del ambiente de
desarrollo, del proyecto, la experiencia en el dominio y categora de la aplicacin a
desarrollar, las herramientas y recursos requeridos y disponibles, para luego
determinar cules actividades de gestin de riesgos se llevaran a cabo, cuando, en qu
orden y quines sern los responsables.
En este documento se reconoce y listar todos aquellos riesgos que puedan influir
negativamente en el proyecto. El proceso comienza con la definicin de las
caractersticas del proyecto en relacin a complejidad, requisitos, recursos,
experiencia del recurso humano, de manera que se pueda determinar el conjunto de
riesgos potenciales a los que el desarrollo de la aplicacin estar expuesto.
93
Riesgos a administrar:
001 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:
Baja Bajo Moderado Alto Tolerable.

Periodo en el cual puede suceder: Responsable(s):
Durante la elaboracin proyecto. Analista de negocio y de requisitos.
Estrategia de Mitigacin: Para evitar la disminucin en el flujo de la comunicacin se requiere hacer reuniones peridicas:
semanalmente para el rea de servicios mdicos y diariamente para el centro de computacin referentes al proyecto, con el fin de
incrementar al mximo la retroalimentacin.
Tabla 10: Riesgos a administrar en el proyecto 1/13.

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

Baja Bajo Moderado Alto Serio.

Durante la elaboracin proyecto. Analista de sistema.
Estrategia de Mitigacin: Para evitar el incumplimiento de las asignaciones, el participante debe dar a conocer con anticipacin la
no participacin en alguna versin y por consiguiente exponer con aval dicha solicitud.
Tablas 10: Riesgos a administrar en el proyecto 2/13.

Incumplimiento de entrega de documentos corregidos y/o aprobados por parte del centro de computacin.

Organizacional. Prolongacin de la culminacin del proyecto.


Durante la elaboracin proyecto. 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.
94

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

Baja Bajo Moderado Alto Catastrfico.

Despus de implantacin del sistema. Analista de sistema
Estrategia de Mitigacin: apegarse a las normas y exigencias del centro de computacin, entregando documentos con un buen
contenido y sentido de la investigacin.

Resistencia al cambio por parte de los usuarios.
Organizacional. Proyecto cancelado.


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

Incumplimiento del alcance del proyecto en el rea de servicios mdicos debido a que un participante asume muchos roles.

Organizacional. Resistencia al cambio de paradigma de desarrollo de
software.

Durante la elaboracin del proyecto. Responsable general del proyecto.
Estrategia de Mitigacin: Adaptarse al nuevo paradigma de trabajo en la parte de desarrollo de software.
95

Crecimiento no controlado de requerimientos y alcance.
Estimaciones -Requerimientos. Proyecto fuera de calendario y requerimientos.


Durante la elaboracin del proyecto. Analista negocio, requisitos y de sistemas.
Estrategia de Mitigacin: El alcance del proyecto debe ser definido previo a la etapa de operacin. Cualquier nuevo requerimiento
que se constituya en un subsistema no indispensable para los ya previstos, debe considerarse para un nuevo proyecto.

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

Despus de implantar el software. Responsable general del proyecto.
Estrategia de Mitigacin: Definicin de manuales de normas y procedimientos de las funciones del sistema en general y su respectiva
induccin a los usuarios.

Datos de los sistemas actuales no migrados eficientemente.

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

Pruebas funcionales del software. 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.
96

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

Tecnolgico - Estimacin. Software de bajo desempeo y elevacin de la resistencia al
cambio por parte de los usuarios.

Despus de implantar el software. Responsable general del proyecto.
Estrategia de Mitigacin: El gestor de configuracin de software debe evaluar estrictamente las especificaciones de hardware y
software necesarias para la puesta en marcha del nuevo software.

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

Baja Bajo Moderado Alto Tolerable.


Durante la elaboracin del proyecto. Analista de negocio, software y sistema.
Estrategia de Mitigacin: Adiestramiento inmediato a al equipo de desarrollo del proyecto, con el fin de prepararlos y as
puedan cumplir con sus asignaciones.

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.
Cancela el proyecto.
Organizacional.


Durante la elaboracin del proyecto. Responsable general del proyecto.
Estrategia de Mitigacin:
Tratar de llevar la planificacin del proyecto para poder mitigar el efecto de retraso que pudiera ser causado por la situacin
descrita.
97

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

Al no tener los equipos tecnolgicos necesarios, el proyecto
Tecnologa. que ha llevado tiempo y esfuerzo se pierde y solo queda en
documentos.

Una vez finalizado el proyecto. Responsable general del proyecto.
Estrategia de Mitigacin: Realizar solicitudes de los equipos tecnolgicos necesitados con anterioridad, para no poner en riesgo
el proyecto.
5.3 Plan de gestin de configuracin
A lo largo del ciclo de vida del proceso de software, los productos de software
evolucionan. Desde la concepcin del producto y la captura de requisitos inicial hasta
la puesta en produccin del mismo, y posteriormente desde el inicio del
mantenimiento hasta su retiro, se van realizando una serie de cambios, tanto en el
cdigo como en la documentacin asociada. La gestin de configuracin del software
es una disciplina encargada del control de la evolucin de los productos de software.
La gestin de configuracin es el proceso de identificar y definir los

elementos en el sistema, controlando el cambio de estos elementos a lo largo de su
ciclo de vida, registrando y reportando el estado de los elementos y las solicitudes de
cambio, y verificando que los elementos estn completos y que sean los correctos. Su
propsito es: (1) controlar sistemticamente los cambios que puedan producirse en
esa configuracin; (2) mantener la integridad de la configuracin de la aplicacin; y
(3) mantener la trazabilidad de la configuracin a lo largo de todo el desarrollo de la
aplicacin.
Las actividades de gestin de la configuracin identifican todas las actividades

y tareas que se requieren para el manejo de la configuracin del sistema. Estas deben
ser tanto actividades tcnicas como de gestin de configuracin del software, as
98
como las actividades generales del proyecto que tengan implicancia sobre el manejo
de configuracin.
a) Identificacin de la configuracin
Se necesita definir un esquema de identificacin para reflejar la estructura del

producto, esto involucra identificar la estructura y clases de componentes, dando a
cada uno un nombre, una identificacin de versin y una identificacin de
configuracin. Para este proyecto los elementos de configuracin se
correspondern con los entregables definidos en el modelo de productos, aunque
no necesariamente todos los entregables deben ser elementos de configuracin.
b) Control de la configuracin
Se deben controlar los cambios que se le hacen a travs del ciclo de vida,
asegurando que el software sea consistente a travs de la creacin de una lnea
base del producto. Se identifican y registran las solicitudes de cambio, se analiza y
evala los cambios, se aprueba o rechaza la solicitud, se implementa, verifica y
distribuye el elemento de software modificado.
c) Contabilidad del estado de la configuracin
Se debe registrar y reportar el estado de los componentes y solicitudes de

cambio. Se preparan registros de gestin y reportes de estado que muestren el
estado e historia de los elementos de software controlados, incluyendo lneas base.
Al final de cada iteracin se establecer una lnea base (un registro del estado de
cada artefacto, estableciendo una versin por ejemplo 0.90,0.91..), la cual podr
ser modificada slo por una solicitud de cambio aprobada.
d) Gestin y entrega de versiones
Se controla formalmente la actualizacin y distribucin de las versiones

generadas por el proyecto. La gestin de la entrega se encarga de identificar, empacar
99
y entregar los tems y componentes que forman cada versin entregable de la

aplicacin.
5.4 Mantenimiento del plan
El responsable de monitorear el plan es el desarrollador del proyecto,

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

MODELADO DEL NEGOCIO
VERSIN 1.0
Lolimar Cedeo. 29-8-09 0.91 Versin preliminar como propuesta de desarrollo
Lolimar Cedeo. 9-10-09 0.92 Correccin de versin preliminar
Lolimar Cedeo. 27-10-09 1.0 Versin preliminar
18. INTRODUCCIN
Este documento permite revisar y verificar el dominio organizacional donde

operar el sistema. Tiene como propsito realizar un anlisis del modelado de
negocio del sistema a desarrollar; el objetivo es verificar y validar con los usuarios
que el modelo del negocio est representado correctamente y cumple con los procesos
de negocio actuales.
Este documento es una nueva adaptacin al negocio de servicios mdicos de

la universidad de oriente ncleo de Monagas realizado por Cabello, M. (2009) donde
se utilizan nuevas herramientas para modelar, ya que para realizar la implantacin se
debe revisar detalladamente el modelado existente. Es necesario realizar una revisin
y anlisis del modelado del negocio establecido en el proyecto anterior, para
determinar si existen discrepancias entre este modelo y lo que realiza actualmente en
el rea de servicios mdicos.
A travs de entrevistas con el personal se logr verificar que los procesos de

negocio continan siendo los mismos que se especificaron en el proyecto anterior, sin
embargo se manifiesta el aumento de actores, ya que para el momento del desarrollo
del sistema no contaba con la misma cantidad. El aumento de actores no tiene gran
relevancia ya que tiene los mismos roles y responsabilidades que en el sistema de
negocios pasado y por ende en la ejecucin de algunos procesos es la misma.
101
19. REPRESENTACIN DEL MODELADO DEL NEGOCIO
El proyecto anterior estuvo desarrollado bajo el enfoque de la metodologa RUP,

donde el modelado del negocio se estableci a travs de casos de uso de UML, del
cual se tomo informacin por referencia ya que no existen cambios notorios en la
ejecucin de los procesos del rea de servicios mdicos. El nuevo modelo del negocio
se simbolizar mediante UML BUSINESS que es una extensin del lenguaje UML,
que est orientado a procesos de negocio que incorpora nuevos smbolos para
modelar, emplea estereotipos para agregar mayor semntica a los smbolos utilizados,
usa cadena de valor de MICHAEL PORTER para modelar procesos al ms alto nivel
y descomponer cada proceso de la cadena de valor en sub-procesos de ms bajo nivel,
los cuales sern desglosados de manera ms especfica y completa.
20. MODELO DE JERARQUA DE SISTEMA DEL SERVICIOS MDICOS
En esta parte se genera como producto un diagrama de jerarqua de sistema el

cual se muestra en la figura 18: este diagrama representar la jerarqua de los sistemas
de la universidad de oriente ncleo de Monagas con respecto al rea en estudio.
Notacin de Eriksson y Penker para modelar un Proceso de Negocio. El suprasistema
corresponde a la identificacin de la universidad como la cabeza principal del sistema
el cual da origen a cada rea que administra como un todo. El sistema en estudio
corresponde al rea de servicios mdicos una de las reas adscrita al departamento de
desarrollo y bienestar estudiantil, sus sub-procesos son identificados como las
consultas que brinda
102
U.D.O MONAGAS
Suprasistema
Decanato del ncleo
Coordinacin Coordinacin
Administrativa Acadmica
Coordinacin Acadmica
rea
Administracin rea de
Orientacin
Delegacin de
Desarrollo Social y
Bienestar Estudiantil
rea rea de
socioeducativa desarrollo social
Sistema en estudio
rea de salud
Medicina Subsistema
Medicina
Servicios
General Interna
Mdicos
Ginecologa Odontologa
Pediatra
Figura 18: Modelo de Jerarqua de Sistemas de servicios medico. Fuente: autor (2010)
21. MODELADO DE OBJETIVOS
De una manera macro a continuacin se muestra en la figura 19 el diagrama de

objetivos correspondiente a los procesos fundamentales del negocio, diagrama que
es de suma importancia tener definido en el momento de realizar el proceso de
definicin de requisitos del sistema.
103
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>> objetivo>> objetivo>> problema>>

Visin Misin Objetivo Descripcin
Ser un servicio con calidad Brindar atencin medica Lograr la implementacin de un
total donde se promocione preventiva en los niveles de sistema automatizado en el rea de
la medicina preventiva con primarios y secundarios, buscar
vocacin humana, cientfica
servicios mdicos de la universidad
minuciosamente los primeros
y tecnolgica, para alcanzar signos y sntomas de las de oriente- Monagas.
las metas en prevencin enfermedades para evitar su
total de enfermedades evolucin hacia estudios
cardiovascular, metablica, avanzados, el dolor del paciente, el objetivo>>
ocupacional y tumoral. sufrimiento de la familia y la Objetivo Generar
muerte sin escusa posible. El Servicio Mdico del Ncleo Monagas es
una Unidad adscrita a la Delegacin de
Desarrollo y Bienestar Estudiantil, la cual se
Objetivos Operacionales inserta dentro de una estructura organizativa
institucional en consonancia con las
objetivo>> expectativas institucionales.
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>> objetivo>> objetivo>> objetivo>> objetivo>>

Cita medica Historia mdica Boleta mdica Conformacin de Medicamentos
Llevar el control del Permitir llevar por escrito El paciente pueda asistir facturas Suministrar medicina
nmero de pacientes los datos del paciente, a la consulta mdica El paciente puede asistir preventiva y de
atendidos por los motivo de consulta, especializada de doctor a la consulta mdica primeros auxilios.
doctores. diagnostico y evolucin. que no labore dentro del especializada de doctor
servicio mdico. que no labore dentro del
servicio mdico. objetivo>>
Registro de
objetivo>> objetivo>>
objetivo>> Medicamentos
Libro Morbilidad Rcipe Mdico objetivo>>
Registro de boleta Llevar el control de
Llevar el registro de Tener indicaciones Registro de facturas
Mdica la entrada y salida de
pacientes que para la compra de Llevar el control de la
Llevar el control de las medicamento.
presentaron una medicamentos. conformacin de
boletas emitidas en el
enfermad o sntoma facturas.
servicio mdico.
especifico.
Figura 19: Diagrama de objetivos de los procesos fundamentales del rea de servicios
Mdicos usando UML Business. Fuente: autor (2010).
104
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 Historia Boletas Conformacin Solicitud de

Mdica Mdica Mdica de Factura Medicamentos
Actividades Primarias
Infraestructura Medica
Recurso Humano y Material

Actividades de Soporte
Desarrollo Estudiantil
Coordinacion Administrativa
Extencion de Personal
Figura 20: Cadena de valor del negocio usando UML 2.0 V 1.3. Fuente: autor (2010).
105
Las actividades de soporte son todos aquellos que aportan procesos, materiales o espacio
fsico para que se puedan dar todos los procesos del rea de servicios mdico entre estas
tenemos:
Infraestructura Mdica: es necesario tener las instalaciones

Infraestructura
Mdica 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

Recurso Humano tienen la capacidad para poder realizar las actividades dentro del
Y Material 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

Delegacin
de desarrollo
el estudiante en la bsqueda de alternativas de solucin a los
y bienestar problemas que interfieran en su proceso de enseanza-
estudiantil aprendizaje 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

Coordinacin
los procesos administrativos, con la finalidad de lograr una
administrativa 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

Extensin de
Personal
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.
106
4.2 Jerarqua de los Procesos de Negocio
Se establece una jerarqua dentro de cada proceso del rea de servicios mdicos.
Servicios
Nivel 0
Mdicos
Servicios Mdicos
PROCESOS DE NEGOCIO Nivel 1
PN 1.1 PN 1.2 PN 1.3 PN 1.4 PN 1.5
Mdica Mdica Mdicas de Factura Medicamentos
Nivel 2
PN 1.1 Cita Mdica PN 1.2 Historia Mdica PN 1.3 Boletas Mdica PN 1.4 Conformacin de Factura PN 1.5 Solicitud de Medicamento
1.3.1 1.3.2 1.4.1 1.5.1 1.5.2

1.1.1 1.2.1
Creacin de Consulta Externa Validar Informacin
Programar cita Elaboracin de Peticin de Suministro de
Boletas al servicio de Factura
mdica Historia Mdica Medicamentos ante Medicamentos al
Mdicas Mdico. Bienestar Estudiantil Paciente
Figura 21: Jerarqua de los procesos del negocio. Fuente: autor (2010)
107
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.
Objetivo
Regla 2
Actor Programar cita
Para los obreros y empleados es un beneficio
Enfermera mdica al paciente
contemplado en el artculo 19 y 58 del contrato colectivo
<<Controla>> <<Cumple>>
<<Controla>>
Solicitud 1.1.1 Producto

El paciente presenta Programar Cita
identificacin y solicita Programada
el servicio. Se valida Cita Mdica
Paciente informacin.
<<Ejecuta>> <<Crea>>
Actor Consulta
Enfermera 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 1.2 1.3 1.4 1.5 Nivel 1

Cita Mdica
1.1.1 Nivel 2
Programar
Cita Medica
Paciente Enfermera
Solicitar servicio mdico Nivel 3
Presentar identificacin
[NO]
[Estudiante] Usuario
Presenta su carnet o Rechazar Paciente
Valido?
Tipo de una constancia de
estudio firmada y [SI]
paciente?
sellada.
Verificar disponibilidad del doctor

[Obrero y Empleados]
[NO]
Presenta carta de
autorizacin, la cual Doctor
es emitida por el Cancelar cita
departamento de
disponible?
servicio social. [SI]
Programar Cita Medica
Diagrama 1: Diagrama de actividades programar cita mdica. Fuente: autor (2010)
109
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:
Objetivo
Regla 1 El paciente pueda tener historia
Es un bienestar estudiantil, que ofrece la U.D.O. mdica para ser controlada su
Regla 2 Actor
1. Doctor evolucin en una enfermedad,
Para los obreros y empleados es un beneficio contemplado diagnostico o motivo de
en el artculo 19 y 58 del contrato colectivo 2. Enfermera
consulta.
<<Controla>>
Proceso 1.2.1 Producto

Examina y Elaboracin de Se crea historia
efecta un mdica y se puede
diagnostico del Historia Mdica emitir rcipe o
paciente. <<Crea>> referencia
Doctor
<<Ejecuta>>
Registro
Actor Se registra historia mdica
Doctor
Figura 23: Diagrama de procesos: Elaboracin de Historia Mdica. Fuente: autor (2010)
110
Diagrama de actividades del proceso 1.2.1. Elaboracin de Historia Mdica:

Servicios
Mdicos Nivel 0
1. Servicios Mdicos
1.1 1.2 1.3 1.4 1.5 Nivel 1

Cita Mdica Historia Mdica Boletas Mdicas Conformar Factura Solicitud de Medicamentos
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
Objetivo
Es un beneficio estudiantil que ofrece la U.D.O.
Que el paciente asista a
Regla 2
Actor consulta externa al servicio
Para los obreros y empleados es un artculo del
Doctor mdico.
contrato colectivo.
<<Cumple>>
<<Controla>>
<<Controla>>
1.3.1 Producto
Objeto
Elabora una referencia Creacin de La auxiliar de registro
y estadstica elabore la
con las indicaciones para Boleta Mdica boleta medica.
la creacin de boleta.
.
Doctor <<Consulta>
<<Ejecuta>> >
Consulta
Actor Referencia del
Auxiliar de registros y estadsticas 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:

Servicios Nivel 0
Mdicos
Servicios Mdicos
1.1 1.2 1.3 1.4 1.5 Nivel 1

Boletas Mdica
1.3.1 1.3.2
Creacin de Consulta externa al Nivel 2
Boletas Mdicas servicio medico
Doctor Aux. Registro y Estadstica Delegacin de Personal Paciente
Recibe Soporte
Elaborar soporte
[SI]
[Obreros y Doctor
Empleados] contratado?
[NO]
Tipo
Paciente?
Crear boleta mdica
[Estudiante] Registro de boleta mdica
No crear boleta mdica
Se entrega Almacenar Se enva registro

soporte medico copia de boleta de boleta medica Recibir registro de boleta medica
Sella soporte Recibe boleta/soporte
Diagrama 3: Diagrama de actividades del proceso creacin de boleta medica. Fuente:

autor (2010)
113
Proceso 1.3.2. Consulta Externa con Boleta Mdica:
Regla 1
Es un bienestar estudiantil que ofrece la U.D.O Objetivo
Regla 2 Brindarle al paciente
Actor
Para los obreros y empleados es un artculo atencin mdica
Aux. De Registro y Estadstica
del contrato colectivo. especializada.
<<Controla>> <<Controla>> <<Cumple>>
1.3.2
Objeto Consulta Externa
Recibe boleta medica al servicio Medico
de manos del paciente
y diagnostica. Proceso
Doctor Externo Enva el registro a
Doctor Externo <<Ejecuta>> la extensin de
personal con la
Actor especificacin del
Doctor Externo monto de consulta
Figura 25: Diagrama de procesos: Consulta Externa con Boleta Medica. Fuente: autor
(2010)
114
Diagrama de clase del proceso 1.3.2 Consulta Externa al Servicio Mdico.

Servicios
Mdicos
Nivel 0
Servicios Mdicos
1.3 1.4 1.5

Nivel 1
1.1 1.2
Boletas Mdica
1.3.1 1.3.2
Creacin de Consulta externa Nivel 2
Boletas Mdicas al servicio medico
Delegacin de Personal Paciente Medico Externo Servicio Mdico
Recibe boleta mdica o soporte
Examinar al Paciente
Especifica monto de consulta
Enva boleta mdica

original y 2 copias.
Recibir 2 copia de boleta

Recibir boletas original con monto de consulta
con monto de consulta
Recibe copias de
Lleva las copias de la boleta boleta mdica con
al servicio medico monto de consulta
Diagrama 4: Diagrama de actividades del proceso consulta externa al servicio mdico.

Fuente: autor (2010)
115
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 Objetivo
Es un derecho estudiantil Verifica que la informacin
Regla 2 Actor sea fidedigna, y conforma
Para los obreros y empleados es un artculo El jefe del departamento facturas, firmando y
del contrato colectivo sellando la misma.
<<Controla>>
1.4.1 Objeto
Objeto
Validar El paciente recibe
Presenta factura de las facturas
compra de medicinas. Informacin de
Factura. conformadas.
Paciente <<Consulta>>
<<Ejecuta>>
Consulta
Actor Se debe tener el rcipe medico
Paciente suministrado por el doctor del
servicio o por el doctor externo.
Figura 26: Diagrama de procesos: Validar Informacin de Facturas. Autor (2010)
El auxiliar de registros y estadstica registra mensualmente facturas conformadas

en libro para control y registro de las mismas. Se le cancela a estudiantes los
siguientes reembolsos (50% En Medicinas y Frmacos, 70% Mdico Especialista,
70% Exmenes de Laboratorios, 25-70 100% Ayuda para lentes (Dependiendo el
caso), 70% Tratamiento de Conducto .Toda factura por compra de medicamentos
debe tener un rcipe emitido por un mdico y sus respectivos datos.
116
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 Nivel 0
Mdicos
Servicios Mdicos
1.1 1.2 1.3 1.4 1.5 Nivel 1

Conformacin de Facturas
1.4.1 Nivel 2
Validar Informacin
de Factura
Extencion de
Paciente Jefe de departamento Aux. Registro y Estadstica Fames Sindicato
Personal
Nivel 3
Presentar
factura y Verificar informacin
Rcipe
Conformar factura Registrar factura
[Si] Recibir factura

Empleado? Enva factura conformada conformada
[No]
Recibir factura
[Si]
conformada
Estudiante? Enva factura conformada
[No] Recibir factura

conformada
Paciente obrero Enva factura conformada
Diagrama 5: Diagrama de actividades del proceso validar informacin de facturas.

117
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 Objetivo
Es un bienestar estudiantil que ofrece la U.D.O Bienestar Estudiantil
Regla 2 Actor suministra medicamentos al
Para los obreros y empleados es un artculo Jefe de departamento servicio mdico.
del contrato colectivo
Proceso
Bienestar Estudiantil
Solicitud 1.5.1 suministra
Solicita medicamentos Peticin de medicamentos.
de tipo diario a Medicamentos ante
Bienestar Estudiantil. Bienestar Estudiantil Enva!
Doctor <<Solicitud> <<Ejecuta>> Proceso

> El servicio mdico
Solicitud Actor recibe y hace nota de
Jefa de enfermera Bienestar Estudiantil recepcin de
elabora carta de solicitud medicamento.
de medicamentos.
Figura 27: Diagrama de procesos: Peticin de Medicamentos ante Bienestar Estudiantil.

118
Diagrama de actividades del proceso 1.5.1. Peticin de Medicamentos Ante

Bienestar Estudiantil.
Servicios
Mdicos
Nivel 0
Servicios Mdicos
1.1 1.2 1.3 1.4 1.5 Nivel 1

Solicitud de Medicamentos
1.5.1 1.5.2
Peticin de Medicamentos ante Suministro de Medicamentos Nivel 2
bienestar estudiantil al paciente
Jefe de departamento Jefe de enfermera Bienestar Estudiantil
Elaborar Nivel 3
carta de
Solicita medicamento solicitud Enva solicitud Recibir carta de solicitud
[No]
Solicitud
Corrige solicitud Rechazar solicitud Correcta?
[SI]
Suministrar Medicamento
Realizar Nota de Recepcin
Registrar entradas
Enva nota de recepcin Recibir nota de Recepcin
Diagrama 6: Diagrama de actividades del proceso Peticin de Medicamentos ante

Bienestar Estudiantil. Fuente: autor (2010).
119
Se desglosa o explota el proceso 1.5.2 Suministro de Medicamento al Paciente.
Regla 1 Actor
Es un bienestar estudiantil que ofrece a la U.D.O Enfermera y Objetivo
Regla 2 Coordinadora de El paciente recibe
Para los obreros y empleados es un artculo del Enfermera medicamentos de tipo
contrato colectivo diario.
.
1.5.2 Servicio
Solicitud Suministro de
Hace la peticin Dar medicamento
Medicamento al al paciente.
de un medicamento Paciente
de tipo bsico, o
Paciente muestra rcipe del
servicio mdico. <<Ejecuta>> <<Registro>>
Registro
Actor
La salida de medicamentos genera
Bienestar Estudiantil un registro de salida. Este registro
de salidas incluye nombre del
medicamento, nombre del paciente
y cedula de identidad.
Figura 28: Diagrama de procesos: Suministro de Medicamento al Paciente Fuente: autor

(2010).
120
Diagrama de actividades para el proceso 1.5.2 Suministro de Medicamento al

Paciente.
Servicios
Medicamentos
Servicios Mdicos
1.1 1.2 1.3 1.4 1.5 Nivel 1

Solicitud de Medicamentos
1.5.1 1.5.2 Nivel 2

Peticin y recepcin de Suministro de Medicamentos al
Medicamentos paciente
Paciente Enfermera
Solicita medicamento de tipo diario Nivel 3

Verifica Informacin
[No]
Por Rcipe? Registra salidas
[Si]
Suministrar medicamento
Muestra rcipe del servicio
medico
Recibir medicamentos
Diagrama 7: Diagrama de actividades del proceso Suministro de Medicamento al Paciente

121
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>> <<Regla>> <<Regla>>

NORMA OTROS LEY
Normas generales Estrategias Es un beneficio para el estudiante, el cual
de control interno. Polticas se establece en el departamento de
desarrollo y bienestar estudiantil.
Brindar atencin Promover un
mdico-odontolgica ambiente que Clausula 19. PRIMEROS AUXILIOS.
de carcter preventivo estimule la Contrato colectivo de trabajo 1986-1988
a la comunidad creatividad y universidad de oriente pg. 24
universitaria productividad de
todos sus miembros. Clausula 58.ATENCION MDICA Y
MEDICINAS. Contrato colectivo de
trabajo 1986-1988 universidad de oriente
pg. 49
Figura 29: Modelo de Reglas del servicio mdico de la universidad de oriente ncleo de
Monagas. Fuente: autor (2010).
122
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:
Se le puede suministrar Se Registran

Paciente * Medicamentos
1
Salida de
1* Medicamento
1
*
1*
Puede Solicitar
1*
Citas Se Registran 1
Tiene Una * Libro Morbilidad
1
Historia Mdica Puede Emitir Rcipe Mdico Puede Generar

1*
1 1 1* Facturas
Puede Emitir
1
Boletas Mdicas
1*
Diagrama 8: Diagrama de modelado de objetos del negocio. Fuente: autor (2010)
123
25. MODELADO DE EVENTOS
Los Eventos del Negocio son hechos cuya ocurrencia dispara la ejecucin
inmediata de un conjunto de acciones asociadas a los procesos del negocio. Esta
ocurrencia puede causar alteraciones sobre los estados de los Objetos de Negocios
como resultado de las acciones realizadas en ese instante; un evento puede provocar
la ejecucin en secuencia o no de un conjunto de acciones en distintos procesos del
negocio.
Los Eventos del Negocio necesitan ser identificados y especificados de manera

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

Procesos del Negocio
Historia Conformacin de
Cita Mdica Boletas Mdicas Solicitud de Medicamento
Mdica Factura
Elaboracin de Consulta externa Validar Peticin de Suministro de
Programar Creacin de
Eventos Historia con boleta informacin de medicamento ante medicamento al
cita Mdica boletas Mdica
Mdica Mdica consulta bienestar estudiantil paciente
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

DOCUMENTO DE DEFINICION DE REQUISITOS
Versin 1.0
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 Productos
1. Dominio
Modelo de Descubrimiento de
Negocio Objetivo
Requisitos Proceso
Reglas
Actores
Problemas
Lista preliminar de requisitos
fundamentales
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 P-2 P-3

Descubrimiento de Anlisis de Especificacin de
requisitos requisitos. requisitos.
<<Proceso>>
P-1.1 P-1.2 P-1.3

Entendimiento del Organizacin del Recoleccin de
dominio. conocimiento. requisitos.
Diagrama 10: Jerarqua de los proceso del descubrimiento de requisitos. Autor: 2010.
127
<<Proceso>>
P-1 P-2 P-3

<<Proceso>>
P-1.1 P-1.2 P-1.3

<<Proceso>>
P-1.1.1 P-1.1.2 P-1.1.3 P-1.1.4

Anlisis del Anlisis de los Anlisis de sistemas Revisin
dominio de la procesos del existentes. bibliogrfica del
aplicacin. negocio. dominio.
Diagrama 11: .Jerarqua de los proceso de entendimiento del dominio. Autor: 2010.
<<Proceso>>
P-1 P-2 P-3

<<Proceso>>
P-1.1 P-1.2 P-1.3

dominio. conocimiento.
requisitos.
<<Proceso>>
P-1.2.1 P-1.2.2
Filtracin del Organizacin del
conocimiento del material recolectado.
dominio.
Diagrama 12: Jerarqua de los proceso de organizacin del conocimiento. Autor: 2010.
128
<<Proceso>>
P-1 P-2 P-3

requisitos requisitos.
requisitos.
<<Proceso>>
P-1.1 P-1.2 P-1.3

<<Proceso>>
P-1.3.1 P-1.3.2 P-1.3.3

Identificacin de los Recopilacin de Recopilacin
interesados en el requisitos de los de requisitos del
sistema. interesados. dominio.
Diagrama 13: Jerarqua de los proceso de recoleccin de requisitos. Autor: 2010.
129
Reglas del Negocio:

Cdigo Nombre Descripcin Fuente Variacin Regla del negocio asociada
Todo estudiante de esta casa de estudio se encuentra en
RN-001 Derecho estudiantil pleno derecho de utilizar su servicio mdico, pues es un Delegacin de desarrollo y -------
beneficio que se le brinda para su pleno desarrollo bienestar estudiantil. Baja
estudiantil.
Los trabajadores (empleados/obreros) al servicio de la

Clausula 19. PRIMEROS U.D.O., que por naturaleza de trabajo estn expuestos a Sindicatos de trabajadoras y Baja -------
AUXILIOS. Contrato colectivo de radiaciones o intoxicaciones, ser atendidos en el centro trabajadores de la
RN-002 trabajo 1986-1988 universidad de de servicios medico de la universidad, a fin de universidad de oriente-
oriente pg. 24 brindarles los primeros auxilios o referirlos a otros Monagas
centros asistenciales, en caso de ser necesario.
Clausula 58.ATENCION La U.D.O se obliga aprestar servicio mdico -------

MDICA Y MEDICINAS. quirrgico, hospitalizacin, ortopedia, prtesis, Sindicatos de trabajadoras y
RN-003 Contrato colectivo de trabajo 1986- esterilizacin y suministro de medicinas a los trabajadores de la Baja
1988 universidad de oriente pg. 49 trabajadores que le prestan servicios en aquellas zonas universidad de oriente-
no cubiertas por el seguro social obligatorio. Monagas
Suministro de Medicina
El trabajador (empleado
Los servicios y suministros de medicinas se har /obrero) de la universidad de
Clausula 58.ATENCION extensivo al cnyuge o en su defecto a la persona con oriente tiene consigo una carga
MDICA Y MEDICINAS. que haga vida marital, as como sus hijos solteros, Sindicatos de trabajadoras y familiar, la cual con solo
RN-004 Contrato colectivo de trabajo 1986- legtimos, reconocidos o adoptivos hasta dieciocho (18) trabajadores de la Baja presentar identificacin del
1988 universidad de oriente pg. 49 aos de edad, los padres , abuelos y hermanos menores universidad de oriente- trabajador puede utilizar el
que estn en bajo la proteccin directa del trabajador . Monagas servicio mdico.
Carga familiar Esta obligacin cesar, cuando el instituto venezolano
de los seguros sociales preste tales servicios, dichos El estudiante no goza del
servicios sern suministrados conforme a la regulacin beneficio de carga familiar, pues
que la U.D.O., dicte al efecto. al presentar su identificacin
solo la persona identificada
como estudiante puede utilizar el
servicio mdico.
Tabla 12: Reglas del Negocio (1/4). Fuente: Autor 2010.
130
Cdigo Nombre Descripcin Fuente Variacin Regla del negocio asociada

Cuando un trabajador requiera de reposo o juicio
RN-005 Clausula 58.ATENCION medico de la U.D.O, esta se obliga a pagar el salario Sindicatos de trabajadoras y Baja -
MDICA Y MEDICINAS. bsico completo durante el tiempo que dure el reposo trabajadores de la
Contrato colectivo de trabajo 1986- ordenado por el mdico hasta cincuenta y dos (52) universidad de oriente-
1988 universidad de oriente pg. 49 semanas, siempre que el mdico ordene un reposo Monagas
superior a los tres (3) das, en caso de emergencia,
Reposo Mdico 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
Clausula 58.ATENCION zona, la U.D.O., se obliga a pagar los tres (3) primeros Sindicatos de trabajadoras y Baja -
MDICA Y MEDICINAS. das que el seguro no page, siempre que este no pague trabajadores de la
RN-006 Contrato colectivo de trabajo 1986- el cuarto (4) da, igualmente pagara el complemento del universidad de oriente-
1988 universidad de oriente pg. 49 salario bsico, durante el lapso que dure el reposo Monagas
ordenado por el mdico del seguro social obligatorio.
Reposo Mdico
Cuando un trabajador haya cumplido con las cincuenta
Clausula 58.ATENCION y dos (52) semanas de reposo y la enfermedad de la
MDICA Y MEDICINAS. cual padece es de naturaleza incurable, que lo Sindicatos de trabajadoras y -
RN-007 Contrato colectivo de trabajo 1986- imposibilite para continuar en el trabajo, la U.D.O., le trabajadores de la Baja
1988 universidad de oriente pg. 49 considera un reposo de hasta cincuenta y dos (52) universidad de oriente-
semanas ms a juicio de mdico, y vencido este lapso la Monagas
Reposo Mdico 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
Clausula 58.ATENCION mismo amparados por el presente contrato, sea enviado -
MDICA Y MEDICINAS. por enfermedad, previa justificacin del servicio
Contrato colectivo de trabajo 1986- mdico de la universidad, a cualquier sitio de la Sindicatos de trabajadoras y
RN-008 1988 universidad de oriente pg. 49 republica o del exterior, la universidad conviene en trabajadores de la Baja
otorgarle los pasajes de ida y vuelta, as como los gastos universidad de oriente-
Viticos mdicos que el tratamiento genere; as mismo se har Monagas
extensivo al acompaante, los gastos de pasaje areos o
su equivalente nicamente.
Tabla 12: Reglas del Negocio (2/4). Fuente: Autor 2010
131
Cdigo Nombre Descripcin Fuente Variacin Regla del negocio

asociada
Debe crearse una carpeta con la historia mdica del Servicio Mdico. UDO Alta -
RN-009 Historia medica paciente. Si se trata de asistencia mdica de tipo bsica, la Monagas 2009
enfermera puede examinar al paciente, sin necesidad de
elaborar una historia mdica
El rcipe es de tipo corriente, conteniendo campos tales
Rcipe medico como: informacin (logo de la U.D.O, datos del Servicio Mdico. UDO -
paciente), sper inscripcin (letra RP, que significa tome Monagas 2009
RN-010 usted), inscripcin (nombre genrico o comercial del Alta
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

Reposo medico un reposo medico al paciente (Condicin alta). Si el
RN-011 paciente lo requiere (solo obreros y empleados), el Jefe de Servicio Mdico. UDO Baja RN-005
Departamento puede crear un informe con la condicin y Monagas 2009
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.
RN-012 Libro Morbilidad Trimestral Se tiene que hacer un libro de morbilidad trimestral dentro
del rea de servicios mdicos que incluya el nmero total Servicio mdico. UDO -
de pacientes que presentaron una enfermedad o sntoma Monagas 2009 Baja
especfico.
Las boletas mdicas deben emitirse solo a obreros, Servicio Mdico. UDO Baja
Boletas Mdicas empleados y a la carga familiar de los mismos, que se Monagas 2009
RN-013 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.
132
Cdigo Nombre Descripcin Fuente Variacin Regla del negocio

asociada
La enfermera tiene que registra salidas de medicamentos Servicio Mdico. UDO Baja
Medicamentos al paciente, este registro de salidas incluye nombre del Monagas 2009 RN-003
RN-014 medicamento, nombre del paciente y cedula de identidad.
El medicamento es de tipo diario.
Solo se conforman facturas de obreros y empleados con la

totalidad de su costo y a estudiantes dentro de los Servicio Mdico. UDO Baja RN-003
siguientes reembolsos (50% En Medicinas y Frmacos, Monagas 2009.
RN-015 Conformacin de Facturas 70% Mdico Especialista, 70% Exmenes de Laboratorios
25-70 100% Ayuda para lentes (Dependiendo el Contrato Colectivo de la
caso),70% Servicio Odontlogo Tratamiento de UDO vigente.
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.
RN-016 Conformacin de Facturas Las facturas solo sern conformadas durante un lapso de 1 Servicio Mdico. UDO Alta RN-003
mes, si no se presenta la factura durante dicha fecha no se Monagas 2009.
conformaran facturas.
RN-017 Conformacin de Facturas Nos se conformaran facturas ni consultas externas que Servicio Mdico. UDO Baja -
sean realizadas por mdicos sistmicos. De igual manera Monagas 2009.
todo aquello referente a esttica personal.
133
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 Paciente
Descripcin Este representa a la persona que solicita y hace uso del servicio mdico.
Smbolo
Paciente
Actor Indirecto
Tabla 13: Descripcin de actores 1/10. Fuente: Autor 2010.

Act-002 Enfermera
Este representa a la persona que programar cita mdica (Recibir y anotar a los pacientes), asiste al mdico
Descripcin 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

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

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

Act-005 Jefe de Departamento

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

Descripcin Este representa la dependencia que elaborar y entregar boletas para servicio de laboratorio y
especialidades mdicas, registra boletas mdicas y lleva un control de facturas.
Smbolo Actor Directo

Auxiliar de Registro y Estadstica
Act-007 Medico externo o Medico no Contratado

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

Medico Externo o Medico no Contratado
Act-008 Extensin de Delegacin de Personal

Descripcin Este representa a la dependencia que recibe el registro de boletas mdicas, recibe informe de viticos o de
condicin del paciente y recibe facturas conformadas.
Smbolo Actor Indirecto

Extensin de Delegacin de Personal
135
Act-009 Bienestar Estudiantil

Descripcin Este representa a la dependencia que recibe solicitudes de medicamentos, suministra el medicamento y
rechazar solicitudes.
Smbolo
Bienestar Estudiantil Actor Indirecto
Act-010 Coordinacin Administrativa

Descripcin Este representa a la dependencia que recibe libro de morbilidad trimestralmente y recibe reporte de
enfermera.
Smbolo
Coordinacin Administrativa Actor Indirecto
Act-011 Secretaria
Descripcin Este representa a la persona que elaborar comunicaciones, enva comunicaciones, lleva archivo de
correspondencia emitida o recibida y transcribe informes mdicos.
Smbolo
Actor Indirecto
Secretaria
28. Recoleccin de Requerimientos Iniciales
cdigo Descripcin del Actor Proceso de Regla del Medio

Requerimiento Negocio Negocio
Conocer identificacin del
R-001 usuario Enfermera PN 1.1 RN-008 En lnea
Programar una cita
R-002 mdica Enfermera PN 1.1 RN-008 En lnea
Modificar, eliminar y -
R-003 consultar una cita mdica Enfermera PN 1.1 En lnea
Crear una historia mdica
R-004 al paciente Doctor PN 1.2 RN-009 En lnea
Modificar, eliminar y
R-005 consultar una historia Doctor PN 1.2 - En lnea
Tabla 14: Recoleccin de requerimientos iniciales 1/2. Fuente: Autor 2010
136
cdigo Descripcin del Actor Proceso de Regla del Medio

Requerimiento Negocio Negocio
Jefe del
R-006 Registrar una boleta Departamento PN 1.3 RN-013 En lnea
mdica
Imprimir una boleta Jefe del
R-007 mdica Departamento PN 1.3 - Impreso
R-008 Emitir Rcipe mdico Doctor PN 1.1 RN-010 Impreso

Jefe del
R-009 Registrar una Departamento PN 1.4 RN-014 En lnea
conformacin facturas
Jefe de
R-010 Controlar entrada y Enfermera PN 1.5 RN-013 En lnea
salida de medicamento
Jefe del - En lnea e
R-011 Generar Reporte de todos departamento - impreso
los procesos
Debe existir un registro -
R-012 actualizado de la Jefe del - En lnea
poblacin de usuarios del Departamento
servicio medico
Tabla 14: Recoleccin de requerimientos iniciales. Fuente: Autor 2010
29. Anlisis de Requisitos
Mediante el anlisis de los requisitos se describen los servicios y las restricciones

operativas que debe proporcionar el sistema que se pretende implantar en el rea de
servicios mdicos. Para esto es necesario se debe hacer una separacin entre los
niveles de descripcin: Requisitos de usuario y Requisitos de sistema.
Los requisitos funcionales determinan la funcionalidad del sistema es decir lo

que el sistema deber hacer involucrando todo lo referente a su comportamiento, su
iteracin con los usuarios, su dominio de aplicacin (negocio), y respuesta a eventos.
Los tipos de requisitos funcionales a utilizar para el sistema se especifican a

continuacin:
137
Se expresan desde la perspectiva de la

Requisitos empresa: describen por que la empresa o
Requisitos dados por:
Centro de computacin
de Negocio cliente desea desarrollar el sistema.
de la U.D.O
Contiene tambin objetivos, metas o
necesidades que la empresa desea alcanzar
con el uso del sistema.
Se expresan desde la perspectiva del

Requisitos usuario: describen las necesidades que los Requisitos dados por:
usuarios tienen y las tareas que los usuarios Personal del servicio
del usuario realizan con la aplicacin. Expresan lo que Mdico-Odontolgico.
el usuario ser capaz de hacer con el
sistema.

Requisitos sistema que contiene la aplicacin: son Requisitos dados por:
del Sistema requisitos de alto nivel para productos que Centro de computacin
tienen componentes de hardware y de la U.D.O
software.

Requisitos de desarrollador: describen los servicios que Requisitos dados por:
Comportamiento el sistema presta a todos sus usuarios Pasante Lolimar Cedeo
directos. Expresa lo que hace el sistema
bajo ciertos estmulos o eventos.
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 Especifican el comportamiento del

producto. Ejemplos: rapidez de la Requisitos dados por:
de Producto ejecucin, capacidad de memoria, Desarrollador
fiabilidad, etc.
Derivan de polticas y procedimientos

existentes en la organizacin del
cliente y del desarrollador. Ejemplos:
Requisitos Estndares de procesos, mtodos de Requisitos dados por:
organizacionales diseo, lenguajes Centro de computacin
de programacin, mtodos de entrega, de la U.D.O
etc.
138
Se derivan de factores externos al

Requisitos dados por:
Requisitos sistema y a sus procesos de desarrollo.
Personas que
Ejemplos: Requisitos de
Externos interoperatividad, legislativos, ticos, manipularan el software
etc.
Perspectiva del producto: El sistema ser desarrollado para gestionar la integracin

de los Sub-Sistemas de citas, facturas, historias mdicas, de farmacia y de generacin
de reportes, la perspectiva es que sea un sistema de informacin confiable
permitiendo credibilidad por parte de la comunidad universitaria, trabajadores y el
gobierno central y a travs de su implementacin se espera que el producto sea
totalmente funcional.
Funciones del producto: Este sistema permitir a la universidad de oriente ncleo de

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

personal del rea de servicios mdicos de la Universidad de Oriente del ncleo
Monagas, el personal est constituido por mdicos y enfermeras que no tienen
experiencias en el manejo de las computadoras y aplicaciones web, por lo tanto el
139
sistema deber construirse pensando en estos usuarios inexpertos en manejo de

sistemas de informacin.
Suposiciones y dependencias: Los usuarios utilizan plataformas heterogneas en

cuanto a sistemas operativos y herramientas de productividad.
En este apartado se presentan los requisitos funcionales y no funcionales que

debern ser satisfechos por el sistema. Todos los requisitos aqu expuestos son
esenciales, es decir, no sera aceptable un sistema que no satisfaga alguno de los
requisitos aqu presentados.
Los requisitos funcionales se refieren a los servicios que el sistema le

proporcionar al personal de servicios mdicos, por lo que describen lo que el sistema
deber hacer. A continuacin se presenta la lista de los requisitos funcionales del
sistema automatizado de los procesos administrativos del rea servicios mdicos de la
universidad de oriente ncleo Monagas, clasificndolos en requisitos de negocio, de
usuario, de sistema y de comportamiento segn la clasificacin de Wiegers, 2003.
Requisitos Funcionales:
El punto inicial en el desarrollo de un software es la descripcin de los

requerimientos funcionales del sistema, los cuales moldean las funcionalidades que
demandan los futuros usuarios de la aplicacin. Los requerimientos funcionales
describen al sistema en trminos de entrada-salida, mientras que los no-funcionales,
en trminos de cualidades deseables del sistema.
A continuacin se enumeran los requisitos funcionales que se han establecido

para el Sistema que se pretende implantar en el rea de servicios mdicos:
140
cdigo Descripcin del Requisito Usuario Proceso de Regla del Tipo de Requisito Medio
Negocio Negocio
El sistema debe tener la opcin de validar el usuario y administrar usuario. Administrador - - En lnea
RF-001 De Comportamiento
El sistema de informacin deber mostrar un mensaje de autentificacin fallida cada vez que - -
RF-002 el nombre de usuario o claves sean invlidas. Administrador De Comportamiento En lnea
- -
RF-003 El sistema debe tener la opcin de editar, agregar o eliminar usuario. Administrador De Comportamiento En lnea
- -
RF-004 El sistema se bloquea despus de tres intentos fallidos de login. Administrador De Sistema En lnea
- -
RF-005 El sistema se bloquea despus de 20 minutos sin actividad. Administrador De Comportamiento En lnea
El sistema muestra el men de acuerdo al nivel de acceso que tiene asignado el usuario -
RF-006 logueado. Administrador - De Sistema En lnea
Se quiere que el sistema posea un men principal con mdulos en los cuales se pueda
RF-007 realizar los principales procesos del servicio mdico y en ellos se pueda consultar, actualizar, Administrador - - De Comportamiento En lnea
modificar y/o eliminar datos.
El sistema tiene que mostrar un men para programar citas mdicas y consultar las ya 1.1
RF-008 programadas. Enfermera cita medica - De Comportamiento En lnea
En el men de citas medicas el mdulo de datos personales deben ser manejados los
RF-009 siguientes campos: Enfermera 1.1 -
Apellidos, nombres, cdula, tipo de paciente, especialidad de consulta, nombre del doctor, cita medica De Comportamiento En lnea
fecha de consulta y turno de consulta.
RF-010 El sistema debe arrojar un mensaje cuando la citas sea programada o no. 1.1 - En lnea
Enfermera cita medica De Comportamiento
El sistema debe manejar la opcin de de programar nuevamente un cita mdica en caso de -
RF-011 que no se pueda programar la misma con las opciones seleccionadas por el paciente o cuando Enfermera 1.1 De Comportamiento En lnea
el doctor no est disponible. cita medica
RF-012 El sistema debe arrojar el listado de paciente que han programado cita en una determinada 1.1 - En lnea
fecha, para modificar o eliminar paciente si es necesario y as llevar el control de la consulta. Enfermera cita medica De Comportamiento
RF-013 Se quiere que el sistema pueda agregar la carga familiar de un paciente (obrero o empleado). 1.1 -
Enfermera cita medica De Comportamiento En lnea
Tabla 15: Requisitos funcionales del sistema (1/6). Fuente: Autor 2010.
141
cdigo Descripcin del Requisito Actor Proceso de Regla del Tipo de Medio
Negocio Negocio Requisito
Se quiere que el sistema pueda permitir que el paciente pueda programar ms de una cita 1.1
RF-014 mdica. Enfermera Cita Medica - De Comportamiento En lnea
El sistema tiene que mostrar un men de historias medicas-odontolgicas para la elaboracin
RF-015 de historias mdicas y la bsqueda de historias asociadas a un paciente de paciente. Doctor 1.2 RN-009 De Comportamiento En lnea
Historia medica
Cuando el doctor ingrese al men historia mdica debe aparecer el listado de los pacientes
RF-016 con la cita para esa fecha y la opcin de atender paciente sin programar cita. Doctor 1.2 RN-009 De Comportamiento En lnea
Historia medica
En el men de nueva consulta mdica el mdulo de datos personales deben ser manejados
RF-017 por lo siguientes: 1.2
Datos generales del paciente (nombre, cedula, fecha de nacimiento) y datos especficos del Doctor Historia medica RN-004,009 De Comportamiento En lnea
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
RF-018 a que se quiere crear (odontolgica, medicina general o interna, ginecologa, pediatra etc.), 1.2
la cual al seleccionar aparezcan con datos de correspondiente a cada una de ella para que el Doctor Historia medica RN-009 De Comportamiento En lnea
paciente pueda llenar.
Se quiere que el sistema en la historia de un paciente muestre el historial de consultas y los
RF-019 datos permanentes del paciente (vicios, tratamientos permanentes, enfermedades terminales Doctor 1.2 RN-009 De Comportamiento En lnea
o infectocontagiosa VIH). Historia medica
El modulo de historia medicas tiene que generar un nmero de historia secuencial
RF-020 automticamente. Doctor 1.2 RN-009 De Comportamiento En lnea
Historia medica
El sistema tiene que ir generando automticamente el registro de todas las consultas hechas a
RF-021 los pacientes y su diagnostico para registrarlo en morbilidad. Doctor 1.2 RN-009,012 De Comportamiento En lnea
Historia medica
El sistema tiene que tener la opcin de bsqueda de cualquier historia medicas en el
RF-022 momento que el usuario as lo quiera. Jefe del 1.2 RN-009 De Comportamiento En lnea
Departamento Historia medica
Cuando ya la historia mdica sea llenada y guardada, el sistema automticamente debe
RF-024 mostrar la opcin de emitir rcipe o referencia para boleta medica. Doctor 1.2 RN-009,013 De Comportamiento En lnea
Historia medica
RF-025 El sistema debe guardar los registros de historias por fechas. Aux. Registro 1.2 RN-009 De Comportamiento En lnea
y Estadstica Historia medica
142
cdigo Descripcin del Requisito Actor Proceso de Regla del Tipo de Requisito Medio
Negocio Negocio
El sistema debe mostrar la opcin de emitir rcipe para que se muestren las indicaciones al 1.2
RF-026 paciente del tratamiento a seguir. Doctor Historia medica RN-009 De Comportamiento En lnea
El sistema debera cargar un medicamento que se encuentre en la farmacia del servicio 1.2
RF-027 mdico, si es el que el doctor receta al paciente. Doctor Historia medica RN-003,009 De Comportamiento En lnea
Todos los medicamentos tienen que tener en el sistema una fecha de vencimiento. Para no 1.2
RF-028 suministrar en el rcipe un medicamento vencido. Doctor Historia medica RN-003,009 De Comportamiento En lnea
Los rcipes deben tener los formatos establecidos en el servicio mdico donde se manejen
RF-029 campos como: Rcipe, indicaciones, connotacin emergencia, nombre del paciente, fecha de Doctor 1.2 RN-009,010 De Comportamiento En lnea
consulta. Historia medica
El sistema debe tener la opcin de buscar rcipes emitidos durante una fecha determinada. Aux. Registro 1.2 De Comportamiento
RF-030 y Estadstica Historia medica RN-009,010 En lnea
Si un paciente a asistido a consultas que se le ha dado rcipe el sistema debe presentar el 1.2
RF-031 historial Doctor Historia medica RN-009,010 De Comportamiento En lnea
Se debe generar un nmero secuencial de rcipes mdicos. Jefe del 1.2
RF-032 Departamento Historia medica RN-010 De Comportamiento En lnea
El sistema debe mostrar la opcin de emitir una referencia para poder realizarle una boleta
RF-033 mdica al paciente. La cual debe poseer datos como: nombre del paciente, c.i, doctor que Doctor 1.2 RN-013 De Comportamiento En lnea
emite referencia y doctor al cual ser emitido. Historia medica
El sistema debe tener un men de boleta medica para poder referir pacientes a mdicos Aux. 1.3
RF-034 externos al servicio. Registro y Boleta medica RN-013 De Comportamiento En lnea
Estadstica
El sistema debe llevar un registro automtico de cada una de las boletas que se emitan en el Jefe del 1.3
RF-035 servicio mdico Departamento Boleta medica RN-013 De Comportamiento En lnea
El sistema debe generar un numero secuencial de boletas medicas automticamente. Jefe del 1.3
RF-036 Departamento Boleta medica RN-013 De Comportamiento En lnea
El sistema debe mostrar un formulario de la boleta medica donde se contemplen los Aux. 1.3
RF-037 siguientes campos: Tipo de consulta, doctor (doctor por honorario o por servicio), Registro y Boleta medica RN-013 De Comportamiento En lnea
laboratorio. Estadstica
La boleta que emita el sistema tiene que mostrar: Si el doctor no tiene contrato de servicios Jefe del 1.3 En lnea
RF-038 con la institucin, por favor indicar el valor de los honorarios o viticos Departamento Boleta medica RN-008,013 De Comportamiento Impreso
Jefe del 1.2
RF-039 El sistema debe generar formato para crear un reposo medico. Departamento Historia medica RN-005,011 De Comportamiento En lnea
143
Negocio Negocio
Si la boleta medica corresponde a un laboratorio, la boleta que emita el sistema debe Aux. Registro 1.3
RF-040 especificar: laboratorio, exmenes a realizar y observaciones correspondientes. y Estadstica Boleta medica RN-013 De Comportamiento En lnea
Si un paciente a asistido a consultas que se le ha emitido una boleta el sistema debe Aux. Registro 1.3
RF-041 presentar el historial. y Estadstica Boleta medica RN-013 De Comportamiento En lnea
Cuando se emita una boleta el sistema de cargar la especialidad del doctor que se le ha Aux. Registro 1.3
RF-042 emitido la boleta. y Estadstica Boleta medica RN-013 De Comportamiento En lnea
El sistema debe guardar los registros de boletas medicas por fechas. Aux. Registro 1.3
RF-043 y Estadstica Boleta medica RN-013 De Comportamiento En lnea
El sistema debe tener la opcin de buscar boletas medicas emitidas durante una fecha Aux. Registro 1.3
RF-044 determinada. y Estadstica Boleta medica RN-013 De Comportamiento En lnea
Jefe del 1.4
RF-045 El sistema tiene que mostrar un men para la conformacin de las facturas. Departamento Conformacin de RN-015,016 De Comportamiento En lnea
facturas
El sistema tiene que llevar el registro, y enumeracin de las facturas que sean Jefe del 1.4
RF-046 conformadas, almacenan los datos relacionados a cada una de las facturas. Departamento Conformacin de RN-015,016 De Comportamiento En lnea
facturas
El men de conformacin de facturas debe presentar los procesos de: 1.4
RF-047 Realizar registro de una nueva factura, visualizar el status de una factura y devolucin Jefe del Conformacin de RN-015,016 De Comportamiento En lnea
de una factura. Departamento facturas
Cuando se cree un nuevo registro de factura el mdulo de datos personales deben ser 1.4
RF-048 manejados los siguientes campos: Cedula, tipo de paciente (obrero, empleado o Jefe del Conformacin de RN-015,016 De Comportamiento En lnea
estudiante) y tipo de factura (si es por medicamento o por atencin especializada) Departamento facturas
Si la factura que se quiere registrar es por medicamentos el mdulo de los datos debe 1.4
RF-049 ser manejados los siguientes campos: Se debe reflejar el mdico (interno externo) Jefe del Conformacin de RN-015,016 De Comportamiento En lnea
que origino la compra, el numero del rcipe que origino la compra y valor de la Departamento facturas
factura.
Jefe del 1.4
RF-050 El sistema debe mostrar el rcipe que emiti la compra automticamente. Departamento Conformacin de RN-015,016 De Comportamiento En lnea
facturas
Si la factura que se quiere registrar es por atencin especializada el mdulo de los
RF-051 datos debe ser manejados los siguientes campos: Jefe del 1.4 RN-015,016 De Comportamiento En lnea
Se debe reflejar el mdico (interno externo) que origino la boleta, especialidad del Departamento Conformacin de
facturas
mdico y valor de la consulta.
144
Negocio Negocio
En el sistema debe mostrar las de facturas generada por un paciente: Jefe del 1.4
RF-052 Si es procesada por medicamento, procesadas por atencin especializada. Departamento Conformacin de RN-015,016 De Comportamiento En lnea
facturas
Cuando una factura ya este registrada, el sistema debe indicarlo. Jefe del 1.4
RF-053 Departamento Conformacin de RN-015,016 De Comportamiento En lnea
facturas
El sistema debe mostrar el curso de una factura: Jefe del 1.4
RF-054 Si la factura fue conformada, si ya fue enviada a su departamento correspondiente. Departamento Conformacin de RN-015,016 De Comportamiento En lnea
facturas
El sistema tiene que mostrar un men con todo lo relativo a medicamentos, para Jefe de 1.5 RN-003,014
RF-055 realizar las actividades relacionadas con este. enfermera Solicitud de De Comportamiento En lnea
Medicamentos
En el men de medicamentos se tiene que hacer el mantenimiento de medicinas que Jefe de 1.5
RF-056 estn en el servicio mdico, tanto medicamento que entre como los que salgan. enfermera Solicitud de RN-003,014 De Comportamiento En lnea
Medicamentos
Para el mantenimiento de medicamento se tienen que manejar campos como: Jefe de 1.5
RF-057 nombre del medicamento, presentacin, cantidad y fecha de vencimiento enfermera Solicitud de RN-003,014 De Comportamiento En lnea
Medicamentos
En el men de mantenimiento de medicamento, cuando se quiera ingresar un Jefe de 1.5
RF-058 medicamento nuevo se debe manejar datos como: nombre, presentacin, cantidad y enfermera Solicitud de RN-003,014 De Comportamiento En lnea
fecha de vencimiento. Medicamentos
El men de medicamento debe permitir salidas eventuales, donde se introduzca el Jefe de 1.5
RF-059 nombre del medicamento a salir, la cantidad y su respectiva fecha de vencimiento. enfermera Solicitud de RN-003,014 De Comportamiento En lnea
Medicamentos
El sistema tiene que pedir datos del paciente y motivo de despacho cuando salga un Jefe de 1.5
RF-060 medicamento por una salida eventual (dolor de cabeza, fiebre, gripe, etc) enfermera Solicitud de RN-003,014 De Comportamiento En lnea
Medicamentos
El men de medicamento debe tener la opcin de podre mostrar todos los Jefe de 1.5
RF-061 medicamentos que salen por rcipe medico. enfermera Solicitud de RN-003,014 De Comportamiento En lnea
Medicamentos
Cuando un medicamento salga por rcipe medico, se beben mostrar datos como: 1.5
RF-062 numero de rcipe que cargo medicamento, nombre del paciente y cantidad de Doctor Solicitud de RN-003,014 De Comportamiento En lnea
medicamento a despachar. Medicamentos
El sistema que va a disear debe tener un men para generar reporte segn quiera el Aux. Registro
RF-063 usuario. y Estadstica. - - De Comportamiento En lnea
145
Negocio Negocio
Cuando el sistema genere reporte de salidas de medicamentos debe mostrar varios Aux. Registro y
RF-064 criterios de bsqueda al usuario como: buscarlo por cedula de paciente, por nombre Estadstica - - De Comportamiento En lnea
de medicamento o con un criterio de fechas.
Cuando el sistema genere reporte de de boletas emitidas debe mostrar varios criterios Aux. Registro y
RF-065 de bsqueda al usuario como: tipo de boleta emitida (para laboratorio, para medico Estadstica - - De Comportamiento En lnea
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 Aux. Registro y
RF-066 mdico debe mostrar varios criterios de bsqueda al usuario como: tipo de rcipe, Estadstica y - - De Comportamiento En lnea
rcipe asociado a un doctor especfico o con un criterio de fechas. jefe del
departamento.
Cuando el sistema genere un reporte de citas que se han emitido en el servicio Aux. Registro y
RF-067 mdico debe mostrar varios criterios de bsqueda al usuario como: tipo de citas Estadstica y - - De Comportamiento En lnea
(atendidas y programadas), citas asociado a un doctor especfico o con un criterio de jefe del
fechas. departamento.
Cuando el sistema genere un reporte de facturas conformadas que se han emitido en el
RF-068 servicio mdico debe mostrar varios criterios de bsqueda al usuario como: cedula de Aux. Registro y - -
un paciente o con un criterio de fechas. Estadstica y De Comportamiento En lnea
jefe del
departamento.
Cuando el sistema genere un reporte de morbilidad que se han emitido en el servicio Aux. Registro y
RF-069 mdico debe mostrar varios criterios de bsqueda al usuario como: por motivo de Estadstica y - -
consulta, por especialidad, por intervalos de edades, por tipo de paciente o con un jefe del De Comportamiento En lnea
criterio de fechas. departamento.
Aux. Registro y
RF-070 Todos los reportes deben tener la opcin de imprimirse. Estadstica y - -
jefe del De Comportamiento En lnea
departamento.
Jefe del 1.2
RF-071 El sistema debe mostrar va web el formato para llenar el informe mdico apaciente. departamento. Historia Medica RN-006,007 De Comportamiento En lnea
Tabla 15: Requisitos funcionales del sistema (6/6). Fuente: Autor 2010..
146
Requisitos No Funcionales del Sistema

cdigo Descripcin del Requisito Usuario Proceso de Regla de Tipo de Medio
Negocio Negocio Requisito
La interfaz del sistema deber ser implementada como una aplicacin web. Todo los
RNF-001 Usuarios - - De Producto En lnea
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 Todo los - - Externo En lnea
RNF-002 envindole un mensaje para que introduzca nuevamente sus datos. Usuarios
Cada usuario del sistema tendr asignado un determinado perfil, usado para activar los Todo los
RNF-003 servicios u opciones que l pueda realizar dentro del sistema. Usuarios - - De Producto En lnea
El sistema deber tener una interfaz grfica sencilla y amigable, basada en mens, ventanas, Todo los
RNF-004 listas desplegables y botones de accin. Usuarios - - Organizacional En lnea
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
RNF-005 se garantizara que el cdigo HTML generado pueda ser interpretado por cualquier de los Desarrollador - - Organizacional -
navegadores comerciales existentes en el mercado.
RNF-006 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 -
El sistema debe utilizar los servicios de la red interna de la UDO (para establecer
RNF-008 comunicacin entre los clientes, el servidor web y el manejador de base de datos. Desarrollador - - Organizacional -
La organizacin, manipulacin, consulta y almacenamiento de los datos estar bajo la
RNF-009 responsabilidad del sistema manejador de base de datos relacional de Sybase MSQL Desarrollador - - Organizacional -
RNF-010 El sistema es una aplicacin web bajo una plataforma XAMPP: apache, MySQL, PHP. Desarrollador - - Organizacional -
Tabla 16: Requisito no funcionales del sistema (1/2). Fuente: Autor 2010.
147
Requisitos No Funcionales del Sistema

cdigo Descripcin del Requisito Usuario Proceso Regla de Tipo de Medio
Negocio Requisito
El sistema debe ser capaz de ejecutarse en la configuracin estndar de los equipos de
RNF-011 cliente de la universidad. Desarrollador - - Organizacional -
El sistema debe tener rapidez y rendimiento de respuesta.

RNF-012 Desarrollador - - De Producto -
La aplicacin debe mantener los estilos (colores, tipos de letra, etc.) establecidos por el
RNF-013 centro de computacin. Desarrollador - - Organizacional -
La interfaz se implementara con HTML simple sin marcos o aplets java. - - -
RNF-015 Desarrollador De Producto
La computadora tiene que contar con un procesador de su poder suficiente para ejecutar el - - -
RNF-016 sistema y una memoria suficiente para almacenar los grandes volmenes de informacin. Desarrollador Externos
El sistema no debe revelar ninguna informacin que se sea utilizada por terceros, solo los -
RNF-017 usuarios del sistema. Desarrollador - - Externos
RNF-018 El sistema debe imprimir los reporte y citas que el usuario necesite. Desarrollador - - De Producto -
Tabla 16: Requisitos no funcionales del sistema (2/2). Fuente: Autor 2010.
148
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
Calidad Interna 9126-3
9126-1 Calidad Externa 9126-2
Calidad en Uso
9126-4
Figura 30: CALIDAD Y MEDICIN DE ISO. Coral Calero, Ismael Caballero, M

ngeles Moraga, Manuel Serrano (2008/2009).
ISO 9126-3: Mtricas Internas de la Calidad del Producto de Software Mtricas

Internas
Aplican a un producto de software no ejecutable.

Aplican durante las etapas de su desarrollo.
Permiten medir la calidad de los entregables intermedios.
Permiten predecir la calidad del producto final.
Permiten al usuario iniciar acciones correctivas temprano en el ciclo de
desarrollo.
El modelo de calidad establecido en la primera parte del estndar, ISO 9126-3,

clasifica la calidad del software en un conjunto estructurado de caractersticas y sus
caractersticas de la siguiente manera:
150
Mtricas de Funcionalidad
1. Adecuacin: Capacidad del producto software para proporcionar un
conjunto apropiado de funciones para tareas y objetivos de usuario
especificados.
2. Exactitud: Capacidad del producto software para proporcionar los
resultados o efectos correctos o acordados, con el grado necesario de
precisin.
3. Interoperabilidad: Capacidad del producto software para interactuar
con uno o ms sistemas especificados.
4. Seguridad: Capacidad del producto software para proteger informacin
y datos de manera que las personas o sistemas no autorizados no
puedan leerlos o modificarlos, al tiempo que no se deniega el acceso a
las personas o sistemas autorizados.
5. Conformidad de la funcionalidad: Capacidad del producto software
para adherirse a normas, convenciones o regulaciones en leyes y
prescripciones similares relacionadas con funcionalidad.
Mtricas de Fiabilidad
1. Madurez: Capacidad del producto software para evitar fallar como

resultado de fallos en el software.
2. Tolerancia a fallos: Capacidad del software para mantener un nivel
especificado de prestaciones en caso de fallos software o de infringir
sus interfaces especificados.
3. Capacidad de recuperacin: Capacidad del producto software para
reestablecer un nivel de prestaciones especificado y de recuperar los
datos directamente afectados en caso de fallo.
4. Cumplimiento de la fiabilidad: Capacidad del producto software para
adherirse a normas, convenciones o regulaciones relacionadas con al
fiabilidad.
151
Mtricas de Usabilidad
1. Entendibilidad: Capacidad del producto software que permite al

usuario entender si el software es adecuado y cmo puede ser usado
para unas tareas o condiciones de uso particulares.
2. Aprendibilidad: Capacidad del producto software que permite al
usuario aprender sobre su aplicacin.
3. Operatibilidad: Capacidad del producto software que permite al
usuario operarlo y controlarlo.
4. Atractivo: Capacidad del producto software para ser atractivo al
usuario.
5. Conformidad de la usabilidad: Capacidad del producto software para
adherirse a normas, convenciones, guas de estilo o regulaciones
relacionadas con la usabilidad.
Mtricas de Eficiencia
1. Comportamiento en el tiempo: Capacidad del producto software para

proporcionar tiempos de respuesta, tiempos de proceso y potencia
apropiados, bajo condiciones determinadas.
2. Utilizacin de recursos: Capacidad del producto software para usar
las cantidades y tipos de recursos adecuados cuando el software lleva
a cabo su funcin bajo condiciones determinadas.
3. Conformidad de la eficiencia: Capacidad del producto software para
adherirse a normas o convenciones relacionadas con la eficiencia.
Mantenibilidad
1. Analizabilidad: Es la capacidad del producto software para serle
diagnosticadas deficiencias o causas de los fallos en el software, o
para identificar las partes que han de ser modificadas.
152
2. Cambiabilidad: Capacidad del producto software que permite que una

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

Un conjunto de atributos que Un conjunto de atributos Un conjunto de atributos Conjunto de atributos Conjunto de atributos Conjunto de atributos
se relacionan con la existencia relacionados con la capacidad relacionados con el relacionados con la relacionados con la relacionados con la
de un conjunto de funciones y del software de mantener su esfuerzo necesitado para el relacin entre el nivel de facilidad de extender, capacidad de un
sus propiedades especficas. nivel de prestacin bajo uso, y en la valoracin desempeo del software
modificar o corregir sistema software para
Las funciones son aquellas que condiciones establecidas individual de tal uso, por un y la cantidad de recursos
establecido o implicado necesitados bajo errores en un sistema ser transferido desde
satisfacen lo indicado o durante un perodo de tiempo software. una plataforma a otra.
implica necesidades. establecido. conjunto de usuarios. condiciones establecidas.
1. Adecuidad 1. Madurez 1. Entendibilidad 1. Comportamiento 1. Analizabilidad 1. Adaptabilidad

2. Exactidud 2. Tolerancia a fallos 2. Aprendibilidad en el tiempo 2. Cambiabilidad 2. Instalabilidad
3. Interoperabilidad 3. Recuperabilidad 3. Operatibilidad 2. Utilizacin de 3. Estabilidad 3. Coexistencia
4. Seguridad 4. Conformidad de la 4. Atractivo recursos 4. Examinabilidad 4. Remplazabilidad
5. Conformidad de la fiabilidad 5. Conformidad de la 3. Conformidad de la 5. Conformidad de 5. Conformidad de la
funcionalidad usabilidad eficiencia la mantenibilidad transportabilidad
Adecuidad Madurez Entendibilidad Comportamiento en el Tiempo Cambiabilidad Conformidad de la

Transportabilidad
Figura 31: Modelo de calidad interna y externa para el rea de servicios mdicos. Fuente: autor 2010
154
UNUVERSISDAD DE ORIENTE
NUCLEO MONAGASCE
CENNTRO DE COMPUTACION
TODOS LOS DERECHOS RESERVADOS
5.2 ETAPA II
PROCESOS DE DISEO, GESTIN Y
SOPORTE.

DOCUMENTO DE ESPECIFICACION DE REQUISITOS DE SOFTWARE
Versin 0.90
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
Jefe de Enfermeria Enfermera
Elaborar Historias Mdicas <<Include>>
Mdico General <<Include>>

Especilista
Pediatra
Emitir Recipe Mdico Autenticar Usuario
<<Include>>
Odontologo
Mdico
<<Include>>
Emitir Boletas Mdicas

Internista
Ginecologo
<<Include>>
Higienista Dental
Conformar Facturas
Aux.de Registro y Estadistica <<Include>>
Jefe de Departamento
Suministro de Medicamentos
Figura 32: Caso de uso general del sistema. Fuente: autor (2010).
A continuacin se detallara el curso tpico de eventos y flujos alternativos,

entre el usuario y la respuesta que se genera todos los procesos el sistema. Aqu se
pueden visualizar los diagramas de secuencia y diagrama de clase que rigen la
construccin del sistema, as como tambin, el prototipo de las pantallas
relacionadas al caso de uso. Estos diagramas de casos de uso comprenden la
funcionalidad del sistema, como se comportan los procesos, como se interacta
con el entorno grafico para el correcto funcionamiento. Tambin se describe
mantenimientos y administracin del sistema
157
Caso de Uso Validar usuario CU-001

Autor Lolimar Cedeo M. Fecha 7-12-09 Versin 0.91
1. 1.Doctor 4. Jefe de enfermera
Actores 2. 2.Enfermeras 5. Auxiliar de registros y estadsticas
3. 3.Jefe del Departamento 6. Secretaria
Tipo Primario- Esencial
Referencias Documento Definicin de Requisitos
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 El usuario ingresa su nombre de usuario
y su contrasea
2 El usuario tilda administrador
3 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 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.
5 Si se trata del administrador, el sistema carga las opciones de administrador.
Tabla 18: Curso alternativo de eventos para validar usuario. Fuente: auto 2010
Comentarios
1 Requisito ms importante del sistema, ya que restringe el uso del
sistema solo a usuarios predeterminados.
Usuario del Sistema
158
Diagrama de Secuencia
W:ValidarUsuario Usuario NiveldeAcceso ModUsu PagUsu Modulos Paginas
Usuario del Sistema
Ingresar Nombre de Usuario
Ingresar Contrasea
Presionar " Ingresar"
T ilda Abministrador
Enviar login
ValidarNombreUsuario ( )
ValidarContrasea ( )
Si Resp=false
Usuario NO valido Procesar
Si Resp=true
Procesar Modulos
CargaModulosUsuario ( )
Procesa CargaModulo ( )
Verifica
CargaUsuario( )
Procesa
Mostrar Pantalla de Inicio CargarPagina ( )
Diagrama 15: Diagrama de secuencia validar usuario. Fuente: auto 2010.
159
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 Administrar Usuarios CU-002

Actores 1. Administrador del Sistema.
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.
Validar Usuario
<<Include>>
Administar Usuarios
Administardor del Sistema
Diagrama 16: Diagrama de caso de uso de administrar usuario. Fuente: auto 2010
Propsito
Establecer perfiles a cada usuario del sistema.
Resumen
Permitir ingresar, modificar y eliminas usuarios.
Curso Normal (Bsico):

1 Este caso de uso inicia cuando el El sistema abre nueva ventana y muestra
2
administrador del sistema las opciones de administracin (Nuevo,
selecciona del men principal la Modificar, Eliminar, Salir).
opcin Administrar Usuarios. 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
161
Curso Normal (Bsico):

3.4
El sistema registra nuevo usuario.
3.5
El sistema muestra un mensaje en pantalla
avisando que el usuario se ha creado
correctamente.
4 Buscar Usuario. 4.1 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 Editar Usuario. 5.1 El sistema abre ventana, busca el 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 Eliminar Usuario. 6.1 El sistema muestra un mensaje de
El Administrador selecciona un confirmacin para eliminar el usuario.
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.
Tabla 19: Curso bsico de eventos para validar usuario 2/2. Fuente: auto 2010
Cursos Alternos
1a En caso de que el administrador quiera volver a la pantalla anterior sin guardar los
datos del nuevo usuario, entonces presiona el botn Retornar.
1b En caso de que los datos introducidos del usuario sean invlidos o que el nombre
de usuario introducido ya exista, el sistema enva un mensaje para que el usuario
verifique la informacin.
Tabla 20: Curso alternos de eventos para validar usuario. Fuente: auto 2010
Comentarios
1
Caso de uso que permite ingresar, modificar y eliminas usuarios.
Usuario del Sistema
162
W:M enuAdm i ni stardor W:Usuari o Usuari o Ni vel deAcceso
Adm i ni strador del Si stem a
Sel ecci onar Adm i ni strar Usuari o
Abre Ventana ( )
Busca Usuari o
BuscarUsuari o ( )
M uestra Li sta de Usuari os
Preci ona Boton "Nuevo"

Abre Ventana ( )
Carga Form ul ari o
Cam bi a ventana CargaNi vel deAcceso( )
Busca Ni vel de Acceso
Crear Nuevo BuscaNi vel deAcceso ( )

Usuari o
M uestra Form ul ari o CargaForm ul ari o ( )
Ll ena Datos de Usuari o a Crear

Preci ona Boton "Agregar" Procesa
Si Resp=fal se
Resp=Val i dar( )
Datos i nval i dos o ya exi ste el nom dre usuari o
Si Resp=true
Usuari o creado exi tosam ente Insertar( )
AbreVentana ( )
M uestra pantal l a anteri or
Presi ona Boton "Retornar"

Retornar
M uestra pantal l a anteri or AbreVentana( )
Ll ena cam po de busqueda
Buscar Usuari o Presi ona Boton "Fi l trar" Busca usuari os de acuerdo a cadena de caracteres tecl ados
M uestra l i sta de usuari os de acuerdo a l a cadena tecl ada BuscarUsuari o( )
Sel ecci ona usuari o de l a l i sta
Presi ona Boton"M odi ca"
AbreVentana( )
Cam bi a ventana Carga form ul ari o con datos de usuari o
BuscaUsuari o(codUsuari o)
CargarT i poUsuari o( )
Edi tar Usuari o Busca ni vel de acceso CargaNi vel deAcceso ( )
M uestra form ul ari o con datos de usuari o Cargaform ul ari o( )
Edi tar datos del usuari o
Presi ona Boton " M odi fi car" Procesa
Usuari o actual i zado exi tosam ente Actual i za( )
M uestra pantal l a anteri or

AbreVentana( )
Presi ona Boton " Sal i r" AbreVentana( )

Sal i r
M uestra Pantl l a de M enu Pri nci pal
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 Programar Cita Mdica CU-003

Actores Enfermeras.
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.
Validar Usuario
<<Include>>
Programar Cita Mdica
Usuario del Sistema

Diagrama 18: Diagrama de caso de uso Programar Cita Mdica. Fuente: auto 2010
Propsito
Permitir a los usuarios programar citas mdicas a los pacientes.
Resumen
En ste caso de uso se describe el proceso para programar citas mdicas.se puede
realizar la programacin de una cita con un doctor especifico, una especialidad y a un
turno determinado.

1 Este caso de uso comienza cuando el 2 El sistema muestra la pantalla para realizar la
usuario selecciona la opcin programacin de la cita.
Programar cita del men principal.
3 Ingresa cedula de identidad del 4 El sistema muestra datos del paciente.
paciente.
5 El usuario selecciona especialidad. 6 El sistema asocia especialidad a doctores.
Tabla 21: Curso bsico de eventos para programar cita. Fuente: auto 2010
165

7 El sistema muestra men desplegable con los
nombres de los doctores.
8 El usuario selecciona nombre del
doctor
9 El usuario selecciona fecha de
consulta.
10 El usuario selecciona el turno de
consulta.
11 El usuario presiona botn 12 El sistema valida paciente.
Consultar.
13 El sistema verifica disponibilidad del doctor.
(Considerando turno seleccionado y la fecha)
14 El sistema muestra informacin sobre el
paciente (Datos Generales)
15 El sistema muestra informacin de la cita
segn lo programado (Turno, especialidad y
doctor)
16 El usuario presiona el botn 17 El sistema verifica que no se ha excedido el
Programar cita nmero de citas por da
18 El sistema identifica la cita con el status
Programada
19 El sistema guarda cita programada.
El mensaje certifica que la cita ha sido
programada. En caso de programar otra cita,
20 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 Se programa la cita con el doctor, especialidad y en el turno seleccionado por el paciente.
2
Usuario del Sistema
Se crea un listado con los nombres de los pacientes que han programado citas
3
Usuario del Sistema
El sistema muestra opciones para citas en caso de que no se pueda programar la misma
con las opciones seleccionadas por el paciente
Usuario del Sistema
166
Diagrama de Clases de Programar Cita Medica
Paciente
+ cd_pac : int
Cita + tipo_pac : int
+ sexo : String
+ id : int + cert : String 0..* Parentesco
+ id_paciente : int + edad : int + cod_parent : int
+ especialidad : String + nombres : String + descripcion : String
+ doctor : String + apellidos : String
+ fecha : Date + fec_nac : Date
+ turno : String 1..*
+ ecivil : String
+ estado : String + correo : String 1
+ cod_parent : int TipoPaciente
+ ProgramarCita() ()
+ Eliminar () + MostrarDatos () + codigo : int
+ Mostrar () + VerificarTipoPaciente () + descripciontipopaciente : String
+ Actualizar () + BuscarTipoPaciente () + mostar ()
+ Consultar () + ValidarUsuario ()
+ Modificar () + MostrarUsuario ()
+ BuscarPaciente ()
+ BuscarPacienteF ()
1
Especialidad
Doctor - id : int 0..*
1 - nomdre : String
+ id : String
+ nomdre : int + Nuevo ()
CargaFamiliar
+ apellido : String + Modificar ()
+ cedula : String + Mostar () + nomdre : String
+ especilidad : int + Actualizar () + apellido : String
+ tipo : int + cedulafam : String
+ horario : int + cod_paren : int
+ correo : String
+ Nuevo () TipoDoctores - cert : int
+ Eliminar () 1 + id : int + sexo : String
+ Modificar ()
+ descripcion : String + edad : int
+ Mostar ()
+ Nuevo () + fecha_nac : Date
+ Modificar () + MostarDatos ()
+ Eliminar ()
+ Mostar ()
Horario
+ id : int Turno
+ dia : int
1 + id : int
+ turno : int
+ doctor : int - descripcion : String
+ Mostar () + mostrarturno ()
+ Editar ()
+ Guardar ()
Diagrama 19: diagrama de clase programar cita. Fuente: auto 2010
167
Diagrama de Secuencia Programar Cita

:
W:ValidarPaciente w:citas Citas Paciente Doctor Especialidad Horario
Usuario del Sistema
Seleccionar programar cita
Ingresar cedula de identidad del paciente Procesar

CargaPaciente( )
Mostrar Pantallas Para Programar cita
Seleccionar especialidad Procesa

cargaEspecilidad( )
Activa
Muestra Nomdre de doctores CargaDoctores( )

Seleccionar doctor
Seleccionar turno Procesa disponibilidad
Muestra turno de doctor CargaTurno( )
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
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
170
Caso de Uso Consultar Citas Programadas CU-004

Doctor
Actores Jefe del departamento
Enfermeras.
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.
Programar Cita
<<Include>>
<<Include>> Validar Usuario
Consultar Citas Programadas
Usuario del Sistema

Diagrama 21: Diagrama de caso de uso consultar cita. Fuente: auto 2010
Propsito
Permitir al usuario consultar las citas que han sido programadas.
Resumen
En ste caso de uso se describe el proceso para consultar citas mdicas ya programadas
y se puede realizar modificaciones.
171

1 El usuario selecciona la opcin 2 El sistema muestra la pantalla para
Consultar Citas del men de realizar consultas de citas programadas.
citas.
3 El usuario selecciona la fecha. 4 El sistema busca citas en la fecha
seleccionada.
5 El sistema muestra las citas programadas
de acuerdo a la bsqueda.
6 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
2
Usuario del Sistema Al momento de suspender una consulta se puede elimina muchas citas al
mismo tiempo.
3
Usuario del Sistema
2 Se puede editar una cita sin modificar el mdico tratante
Usuario del Sistema

4 El paciente tiene que presentar su cedula o su constancia de estudio para
2
poder solicitar algn dato en el departamento.
Usuario del Sistema
172
W:ConsultarCita Citas
Usuario del Sistema
Seleccionar fecha
Consultar Citas
Programadas Procesa
Presionar "Consultar Citas"
Muestra Resultados BuscaCita( )
Seleccionar Editar Procesar

Mostar pantalla para editar datos Carga( )
Modificar
Edita turno de la consulta
Edita Fecha
Precionael boton "Guardar" Procesa
GuardarCitas ( )
Eliminar Seleccionar "Eliminar" Procesar
Mostrar mensaje de aviso EliminarCita ( )
Diagrama 22: Diagrama de secuencia consultar cita. Fuente: Autor 2010.
173
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
175
Caso de Uso Elaborar Historia Medica CU-005

1. Doctor.
Actores 2. Jefe del departamento.
3. Enfermeras.
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.
Elaborar Historia
Usuario del Sistema

Diagrama 23: Diagrama de caso de uso elaborar historia mdica. Fuente: auto 2010
Propsito
Registrar historias medico-odontolgicas mediante el acceso y utilizacin del sistema.
Resumen
En ste caso de uso se describe el proceso para la elaboracin de una historia. Este
proceso permite manipular de manera ordenada y llevar un control de las historias de
los pacientes

1 El caso de uso comienza cuando el 2 El sistema muestra pantalla con el listado de
usuario selecciona la opcin Crear pacientes del da, segn el orden en que han
Nueva Historia, en el men programado las citas.
Historias Med.-Odont.
3 El usuario marca la casilla del paciente
que desea atender.
4 El usuario presiona el botn Aceptar. 5 El sistema captura seleccin.
6
El sistema busca datos generales del paciente.
Tabla 25: Curso bsico de eventos para elaborar historia mdica. Fuente: auto 2010
176
Curso Normal (Bsico) continuacin

8 El sistema muestra formulario de captura de
informacin relacionada a datos especficos del
paciente
9 El usuario ingresa la informacin
solicitada en el formulario.
10 El usuario presiona la opcin 11 El sistema valida los datos.
Guardar.
12 El sistema guarda los datos.
13 El sistema muestra el formulario de datos del

paciente completado y men con los tipos de
historia.
14 El usuario selecciona el tipo de historia 15 El sistema muestra formulario correspondiente al
que se desea crear. tipo de historia seleccionada con su respectivo
nmero de historia.
15.1 Cuando se trata de la primera consulta, se deben
ingresar los datos permanentes del tipo de historia
y los datos de la consulta del da.
15.2 Cuando el paciente ha tenido previas consultas en
la especialidad, solo se deben llenar los datos de la
consulta del da. Los datos permanentes ya
aparecern cargados, al igual que un historial con
los datos de las ultimas 10 consultas, ordenados
por fecha a partir de la fecha ms reciente.
16 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,
3 ingresar su cedula de identidad para generar consulta. Se realiza una validacin del paciente y se
presiona el botn Aceptar
Cuando el usuario ingresa la informacin solicitada en el formulario correspondiente al tipo de
10 historia seleccionada. Si algn dato obligatoria est vaco, el sistema lo indica y le permite al
usuario efectuar la correccin.
10 Cuando el usuario presiona el botn Guardar en cualquier parte, si surge algn error en la
grabacin, el sistema informa y muestra la pantalla de captura de datos nuevamente.
Tabla 26: Curso alterno de eventos para elaborar historia mdica. Fuente: auto 2010.
Comentarios
1
El usuario del sistema podr elaborar historias mdicas de pacientes. El sistema debe
validar para que se genere un nmero de historia secuencial automticamente, se muestre el
formulario de la historia mdica, y se pueda observar el historial de consultas.
Usuario del Sistema
177
Diagrama de Clases
HistoriaGenerarInterna
+ id : int
+ id_doctor : int
+ id_dp_general_interno : int
+ motivo_consulta : String
+ enfermedad_actual : String
+ diagnostico : String
+ tratamiento_pac : String
+ tension_arterial : String
DatosPermentesGenerarInterna + peso : String
+ id : int + pulso : String
+ id_dp : int 1 + temperatura : String
+ telefono : String + talla : String
+ antecedentes : String + frecuencia_resp : String
+ habitos_psicobiologico : String + observaciones : String
DatosPermanentesGinecologica + periodo_tiempo : String + fecha : Date
HistoriaGinecologica
+ inscripcion : String + InsertarDatos ()
ControlColoscopio + id : int
+ id : int + indicacion : String + MostarDatos ()
+ id_historia : int
+ id : int + id_ginecologica : int + fecha : Date + GuardarDatos ()
+ antecedentes_c_o : String
+ id_dp : int + id_doctor : int + MostrarDatosPermanentes ()
+ antecedentes_g : String
+ id_doctor : int 1 + motivo_consulta : String + GuardarDatosPermanentes ()
+ fecha : Date + efermedad_actual : String 1 + MostrarDatosPermanentes ()
+ aa : String + alimentacion : String + GuardarDatosPermanentes ()
+ lugol : String + t_paciente : String 1..* DatosPermanentesPediatrica
+ nomdre : String + d_evolucion : String 1..*
+ id : int
+ estado : String + fecha : Date
+ id_dp : int HistoriaPediatrica
+ Guardar () + InsertarDatos () + id_doctor : int
+ Mostar () + MostarDatos () Historias + edad : int 1 + id : int
+ Insertar () + GuardarDatos () 1..* + sexo : String + id_dp_pediatrica : int
+ id : int + id_doctor : int
+ cedula : String + nomdrem : String
+ edadm : int + t_arterial : Date
+ tipo : String + temperatura : String
+ ocupacionm : String
+ VerificarHistoria () + nombrep : String + peso : String
+ insertarHistoriaVacia () + edadp : String + talla : String
+ insertarHistoriaLlena () + ocupacionp : String + pulso : String
+ mostrarDatos () + a_perinatales : String + f_respiratoria : String
+ GuardarDatosPermanentes () + complicacion : String + f_cardiaca : String
+ InsertarDatosPermanentes () + alimentacion : String + a_general : String
+ medicamentos : String + orl : String
+ a_personales : String + cardiopulmonar : String
+ a_psicomotor : String + abdomen : String
+ denticion : String + extremidades : String
1..* + a_familiar : String
Puede ser: + neurologo : String
+ fecha : Date
+ fecha : Date
DatosPermanentesOdontologica + MuestraDatos ()
+ MostrarDatosPermanentes ()
+ id : int + GuardarDatosPermanentes () + InsertarDatos ()
+ id_doctor : int + GuardarDatos ()
+ id_historia : int + GuardarEsquemaImunuzacion ()
+ direccion : String + MostarEsquemaImunuzacion ()
0..* VacunaDosis
+ telefono : String + VerificarEsquemaImunuzacion ()
Tiene
+ referencias : String + id_dp_pediatrica : int
+ edad : String Dentadura + id_vacuna : int
+ e_general : String 1 + + id_dosis : int
id : int + fecha : Date
+ piso_boca : String
+ id_dp : int
+ carrillo : String
+ id_posicion_dent : int PosicionDentadura
+ lengua : String
+ fechaq : Date
+ paladar : String 1..* + id : int
+ descripcion : String
+ encias : String + lado : String 1..*
+ tratamiento : String
+ protesis : String + posicion : String 1..*
+ observacion : String Vacunas
+ t_relizado : String + numero : int Dosis
+ fecha : Date + MostrarDentadura () - id : int
+ GuardarDentadura () - nomdre : String - id : int
+ MostarDatosPermantes ()
+ ActualizarDentadura () - nombre : String
+ ActulizarHistoriaLlena () + Insertar ()
+ ComprobarDentadura () + Insertar ()
+ BuscarIDDientes () + Guardar ()
+ Guaradar ()
+ Mostar ()
Diagrama 24: Diagrama de clase elaborar historia Mdica. Fuente: auto 2010
178
Citas W:HistoriaMedica Paciente HistoriasMedicas DatosPermanentesDeHistoria Historia
Usuario del Sistema
Mostrar pacientes del dia
Seleccionar paciente
Presionar "Aceptar" Procesar
CapturarPaciente( )
Activar
CargaTipoDeHistoria( )
Crear Historia Muestar formulario de historia con datos del paciente caragdo CargarFormulario ( )
Medica Ingresar datos en el formulario
Presionar "Guardar" Procesar

CargaFormulario( )
GuardarDatos ( )
Muestra Mensaje "Se ha Creado Historia Medica" GeneraNumerodeHistoria( )
Incresar datos de consulta Activa datos de consulta

Procesa
CargaDatosdeConsulta( )
GuardaDatosdeConsulta( )
Muestra pantalla para relizar busqueda
Consultar Historia Introdusca C.I sin programar cita Procesa C.I

Medica
CargaPaciente( )
Activa
Mestra historia del paciente CargaHistoriaMedica( )
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
181
PANTALLAS
Pantalla 5/8. Historia Mdica Ginecolgica
182
PANTALLAS
Pantalla 6/8. Historia Mdica Odontolgica
183
PANTALLAS
Pantalla 7/8. Historia Mdica Peditrica
184
PANTALLAS
Pantalla 8/8. Historia Mdica General O Interna
185
Caso de Uso Registrar Boleta Mdica CU-006

1. Doctor.
3. Aux. Registro y Estadstica
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.
Validar Usuario
<<Includede>>
Registrar Boleta
Usuario del Sistema

Diagrama 26: Diagrama de caso de uso crear boleta Mdica. Fuente: auto 2010
Propsito
Llevar un registro de cada una de las boletas medicas que se emiten en el servicio
mdico de la universidad.
Resumen
En ste caso de uso se describe el proceso para la creacin y registro de boletas

medicas. El sistema debe validar y llevar un registro de las mismas, donde se genere un
nmero de boleta automtico, se muestre el formulario de la boleta mdica y se tenga
un registro de las boletas emitidas.
186

1 El caso de uso comienza cuando el sistema
muestra pantalla principal de boletas mdicas.
2 El usuario hace clic en Crear 2.1 El sistema captura la seleccin.
nueva boleta.
2.2 El sistema muestra pantalla de captura de
datos.
2.3 El usuario selecciona tipo de 2.4 El sistema muestra men con los nombre de
doctor. los doctores de acuerdo al tipo de doctor
seleccionado.
2.5 El usuario selecciona el nombre del 2.6 El sistema muestra men con las
doctor. especialidades asociadas al doctor.
2.7 El usuario selecciona especialidad.
2.8 El usuario presiona el botn 2.9 El sistema guarda datos de la boleta mdica.
Guardar.
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
2 paciente (Almacena Boleta)
2.1 El sistema muestra registro de la boleta con
3 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.9informa y regresa a la pantalla de captura de datos.
Cuando el usuario seleccione una fecha en el Historial de Boletas Mdicas, si el
3 paciente no cuenta con un historial de boletas mdicas, se muestra un mensaje de
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.
Usuario del Sistema
187
Diagrama de Clases
Boleta
BoletaPaciente
+ id : int Laboratorio
+ id_boleta : int
+ servicio : String
+ cd_pac : String + id : int
+ detalles : String 1
+ id : int + nombre : String
+ observaciones : String
1 + mostrar () + rif : String
+ fecha : Date
+ cd_pac : String + buscar () + Mostrar ()
+ guardar () + Buscar ()
+ Crear ()
+ Guardar ()
+ Eliminar ()
+ Consultar ()
Doctores
+ id : int
+ nombre : String
+ apellido : String
+ cedula : String
+ especilidad : String
+ horario : String
+ tipo : int
+ Nuevo ()
+ Modificar ()
+ Actualizar ()
+ Mostar ()
+ Eliminar ()
Diagrama 27: Diagrama de clase crear boleta Medica. Fuente: auto 2010
188
W: Boleta Medica Boleta BoletaPaciente Dotores Especialidad Laboratorio
Usuario del Sistema
Seleccionar "Nueva Boleta" Procesar seleccin
Mostrar formulario CapturarSeleccion ( )
Boleta de Seleccionar tipo de consulta Procesar

Consulta Medica CargaDoctores ( )
Mostrar nombres de doctores del tipo seleccionado
Externa
Selecciona doctor Procesa
Mostrar la especialida asociada al doctor CargarEspecialidad ( )
Seleciona Especialidad
Crear Boleta
Medica Introduce T ipo de consulta Procesa
Mostrar nombre de laboratorio seleccionado CargaLaboratorio( )

Boleta de Selecciona Laboratorio
Laboratorio
Seleciona Examenes
Introduce Observaciones
Presionar "Guardar" Procesa

validaBoletaPaciente( )
Activa GenerarNumeroDeBoleta ( )
ValidaDatos( )
AlmacenaBoleta ( )
Imprimir Boleta
Seleccionar "Imprimir" Procesar Impresin
Boleta Impresa
Introduce Nmero de boletas Procesar

Consultar Activa ValidaDatos( )
Boleta
BuscarBoletaMedica ( )
Mostra boleta
Diagrama 28: Diagrama de secuencia crear boleta Medica. Fuente: auto 2010
189
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
191
PANTALLAS
Pantalla 5/6. Boleta Mdica Para Imprimir
Pantalla 6/6. Buscar Boleta Mdica
192
Caso de Uso Emitir Rcipe Mdico CU-007

1. Doctor.
3. Enfermeras.
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
Elaborar Historias Mdicas
<<Include>>
Condicion= Requiere Tratamiento
Punto de Extension= Verificar Historia
Emitir Recipe Medico
Usuario del Sistema
Diagrama 29: Diagrama de caso de uso emitir rcipe medico. Fuente: auto 2010
Propsito
Emitir rcipes mdicos a travs del sistema.
Resumen
En ste caso de uso se describe el proceso para la emisin de un rcipe mdico. Se establecer un formato
nico de rcipes mdicos y se llevar un registro de los rcipes emitidos

1El sistema muestra pantalla principal de
rcipes mdicos.
2 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)
3 El usuario hace clic en Cargar medicamento 3.1 El sistema muestra motor de bsqueda de
de farmacia. medicamento.
3.2 El usuario ingresa el nombre del medicamento.
3.4 El usuario presiona Buscar 3.5 El sistema busca el medicamento.
3.6 El sistema muestra el resultado de la
bsqueda
3.7 El usuario ingresa la cantidad del medicamento
que desea agregar al rcipe.
3.8 El usuario marca la casilla Agregar a rcipe
Tabla 29: Curso bsico de eventos para emitir rcipe medico. Fuente: auto 2010
193
Curso Normal (Bsico) continuacin

El usuario presiona el botn El sistema carga el nombre del medicamento
3.9 Aceptar 3.10 seleccionado, presentacin y cantidad en la seccin
denominada Rp. del formulario del rcipe medico.
4 El usuario selecciona la opcin
Emitir Rcipe comun.
El usuario ingresa informacin en Rp.
4.1 e indicaciones.
El usuario presiona el botn Emitir 6 El sistema guarda los datos.
5 Rcipe Medico
El sistema muestra el rcipe medico con opcin de
7 impresin.
Para realizar la bsqueda de un rcipe El sistema muestra los rcipes medico creado en la
8 El usuario selecciona una fecha en el 9 fecha seleccionada.
Historial de Rcipes Mdicos.
Tabla 28: Curso bsico de eventos para emitir rcipe medico. Fuente: auto 2010
Cursos Alternos
Cuando se quiera cargar otro medicamento de farmacia, se debe hacer clic en Cargar otro
3 medicamento de farmacia y el sistema muestra motor de bsqueda de medicamento
continuando con el flujo de eventos.
Cuando el sistema busca el medicamento, y no se cuenta con el medicamento buscado, el sistema
3.6 emite un mensaje notificando que el medicamento no se encuentra disponible.
Cuando el usuario ingresa la cantidad del medicamento que desea agregar al rcipe, si la cantidad
3.7 ingresada no se encuentra disponible, el sistema emite un mensaje notificando al usuario sobre el
caso. Le permite seleccionar otra cantidad.
Cuando el usuario aprieta el botn Emitir Rcipe Medico, si la emisin del rcipe se debe a una
5 emergencia, el usuario puede seleccionar la casilla de verificacin Emergencia. En este caso, el
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.
Usuario del Sistema
Diagrama de Clases
Recipe
DetallesRecipe
+ iddoctor : int
+ numrecipe : int
+ numero : int
+ rp : String
+ indicaciones : String 1..*
+ cant : int
+ fecha : Date
+ id : int
+ paciente : String
+ estatus : String + Mostrar ()
+ Mostar Recipe ()
+ Mostar Recipes ()
+ Eliminar ()
+ Crear ()
Diagrama 30: Diagrama de clase emitir rcipe medico. Fuente: autor 2010
194
W:Reci pe Medi co Medi camentos Reci pe Detal l esReci pe Hi stori aMedi ca
Usuari o del Si stema Impresora
Mostrar pantal l a pri nci pal de reci pes medi cos
Sel ecci onar "Crear Reci pe" Procesar Sel ecci on
Mostrar formul ari o de reci pe medi co CapturarSel ecci on ( )
Hacer cl i c en cargar medi camento de farmaci a Procesar
CapturarSel ecci on ( )
Mostrar motor de busqueda
Crear Reci pe Ingresar nombre del medi camento

Cargando Medi camento de
Farmaci a
Presi onar "Buscar" Procesar Busqueda
Mostrar resul tado de medi camentos BuscarMedi camento ( )
Ingresar Canti dad
Marcar casi l l a "Agregar a reci pe"
Presi onar "Aceptar" Procesar

Crear Nuevo CargaNomdreyPresentaci on( )
Reci pe
Envi ar nombre y presentaci on del medi camento
GuardaMedi camento( )
Mostrar formul aci on con secci on de Rp. compl etada GuardarDetal l esReci pe( )
Ingresar Indi caci ones
Ingresar Rp. e i ndi caci ones
Presi onar "Emi ti r Reci pe" Procesar
Val i darDatos ( )
Crear Reci pe Comn
GenerarNumero ( )
GuardarDatos ( )
Asoci ar a
Mostrar reci pe compl etado Al macenarReci pe ( )
Sel ecci onar "Impri mi r" Proceso Impri mi r
Impri mi r
Reci pe Reci pe Impreso
Consul tas Sel ecci onar fecha Procesar

Reci pe
MostrarResul tado BuscarReci peMedi co ( )
Diagrama 31: Diagrama de secuencia emitir rcipe medico. Fuente: autor 2010.
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
197
Caso de Uso Conformar Factura CU-008

Actores
2. Jefe del departamento.
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.
Factura Por Atencion Mdica Especilizada
<<Extiende>>
Factura Por Medicamento
Condicion = Soporte Valido Registro Factura <<Extiende>>

Punto de Extensin = Validar Soporte
<<Extiende>>
<<Include>>
Validar Usuario
Conformar Facturas
Validar Soporte
Usuario del Sistema
<<Extiende>>
Registrar Devolucin de Factura
Condicion = Soporte no valido/ Error en factura

Punto de Extensin = Validar Soporte
Diagrama 32: Caso de uso Conformar Factura. Fuente: Autor 2010
Propsito
Llevar un registro de las facturas que se conforman en el servicio mdico de la U.D.O
Resumen
En ste caso de uso se describe el proceso para la conformacin y devolucin de
facturas.
198
Curso Normal (Bsico) Para el Registro de Factura

El usuario selecciona la opcin El sistema muestra un formulario donde se
1 Nueva factura en el men de 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
5 correspondiente. muestra en la pantalla.
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.
8.4 rcipe fue originado en 1
departamento de servicios mdicos
el usuario hace clic en el botn
Ver Rcipe.
Si el rcipe fue originado por un medico
8.4. externo el sistema muestra un formulario
2 para cargar dichos datos.
El usuario llena los campos de la El sistema carga todos los campos y realiza
8.5 fecha que se realizo la compra y su 8.6 el registro de factura por medicamento.
costo.
El usuario selecciona que el tipo de El sistema muestra los datos a llenar para
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
9.2 correspondientes. 9.3 el registro de factura por atencin mdica
particular.
El sistema asigna los registros de facturas al
10 status facturas PROCESADO para ser
conformadas.
Tabla 31: Curso bsico de eventos para el registro de factura. Fuente: auto 2010
Cursos Alternos Para el Registro de Factura

Solo se hace la validacin de rcipes mdicos que se conformen en un plazo no mayor a
6.4 30 das posteriores a su emisin. Si el sistema no la carga es porque ha caducado o no
existe origen de factura.
6.6 Si surge algn error en la grabacin de un registro de factura el sistema lo informa y
7.3 regresa a la pantalla de captura de datos.
Cuando se trate de un mdico particular el sistema muestra la opcin de ingresar su
7.2 nombre y cargar su especialidad.
Tabla 32: Curso alterno de eventos para el registro de factura. Fuente: auto 2010
199
Curso Normal (Bsico) Para Devolucin de Factura
1 El usuario selecciona Status 2 El sistema muestra la pantalla para que

de Factura del men principal el usuario seleccin que tipo de status
en conformar factura. desee conformar o devolver.
El usuario selecciona que tipo El sistema muestra el listado de las
3 de factura (Por medicamento o 3 facturas registrada en espera para ambos
por atencin mdica tipo de factura.
especializada).
4 El usuario conforma factura y
presiona Conformar.
5 El usuario selecciona la factura 6 El sistema arroja una pantalla donde le
a devolver. pide al usuario la exposicin de motivo
por el cual se est devolviendo la
factura.
7 El usuario ingresa exposicin 7 El sistema registra una devolucin de
motivos y presiona factura.
Guardar.
8 El sistema cambia el estatus de factura
de procesada a devuelta
.
Tabla 33: Curso bsico de eventos para la devolucin de factura. Fuente: auto 2010
Comentarios
1
Permitir el registro y control de las facturas que han sido conformadas.
Usuario del Sistema

2
El usuario podr almacenar los datos relacionados a la conformacin
de facturas
Se muestre el formulario para el registro de facturas
Usuario del Sistema
conformadas y para registrar devoluciones.
Se almacenen todos los registros realizados.
Se tenga informacin de las facturas que han sido
conformadas por un determinado paciente.
Se pueda visualizar el status de una determinada
factura.
Cambiar el Status de una factura.
200
Diagrama de Clases
TipoPaciente
+ cd_pac : int
+ tipo_pac : int
+ sexo : String
+ nomdres : String
+ apellidos : String
+ fec_nac : Date
+ ecivil : String
+ correo : String
+ cert : int
+ edad : int
+ cod_parent : int
+ Mostar ()
+ VerificarTipoPaciente ()
+ BuscarTipoPaciente ()
+ ValidarUsuario ()
+ MostrarUsuario ()
+ BuscarPaciente ()
+ BuscarPacienteF ()
1..*
TipoDoctor
+ id : int
Facturas
+ desripcion : String
+ Id : int 0..* + Nuevo ()
+ Cedula : String + Modificar ()
+ TipoPaciente : int + Mostrar ()
+ TipoMedico : int + Eliminar ()
+ TipoDoctor : String
+ Especilidad : int EstadoFactura
+ Ffactura : Date 1
+ estatus : float + id : int
+ nomdre : String
+ MostrarRecipe ()
+ Crear () + Modificar ()
+ Buscar () + Mostrar ()
FacturaMedicamento FacturaAtencionParticular
+ Id : int + Id : int
+ cedula : String + cedula : String
+ tipodoctor : int + tipopaciente : int
+ tipopaciente : int + ffecha : Date
+ fecha : Date + estatus : String
+ estatus : String + medico : String
+ medico : String + especialidad : String
+ especialidad : String + valor : String
+ valor : String + serial : String
+ serial : String + observaciones : String
+ observaciones : String + Mostrar ()
+ nrecipe : int
+ Mostrar ()
Diagrama 33: Diagrama de clase. Conformar Factura. Fuente: Autor 2010
201
Diagrama de Secuencia para el Registro de Factura

W:BuscarPaciente RegistroFacturas Doctores EspecialidadDoctor Especialidad Paciente Recipe
Usuario del Sistema
Seleccionar " Nuevo Registro" Procesar
CapturarSeleccion ( )
Ingresar cedula de identidad del paciente Activa
Muestra pantalla de nuevo registro con los datos del paciente Cargar Paciente ( )
Seleccione tipo de Factura "Medicamento" Procesa
Mostar T ipo de Doctores CargaT ipoDoctores( )
Seleccione el tipo de medico que origino la compra Procesa
Mostar nombre de doctores CargaNombres ( )
Seleccione nomdre del doctor Procesar
Cargar Especialidad ( )
Mostrar Especilidad
Ingresar numero de recipe Procesar
Mostrar recipe Cargar Recipe ( )

Por "Medicamentos"
Ingresar datos de la factura
Presionar " Guardar" Procesar

ValidarPaciente ( )
Procesa
CargaDatos( ) BuscarRecipe ( )
Mostrar mensaje de factura procesada GuardarRegistro ( )
Seleccion tipo de factura "Atencion Medica Particular" Seleccion tipo de factura "Atencion Medica Particular"
Procesar
Mostar Nombre FiltrarT ipo ( )
Ingrese nombre del Doctor Procesar
Mostrar Nombres CargarEspecialidad ( )
Ingresar serial de Factura
Por "Atencin Medica Ingresar Fecha factura

Particular"
Ingresar costo de factura
Precionar" Guardar" Procesar
Activa ValidarPaciente ( )
GuardarRegistro ( )
Mostrar mensaje de notificacin GuardarStatus ( )
Diagrama 34: Diagrama de secuencia registro de factura. Fuente: Autor 2010
202
Pantallas de Registro de Factura
Pantalla 1/4. Seleccin de Nueva Factura
Pantalla 2/4. Seleccin de Factura Medicamento

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

P
Pantalla 4/4. Factura Registrada
204
Diagrama de Secuencia para la Devolucin de Factura
W:Facturas Facturas Paci ente
Usuari o del Si stema
Sel ecci onar "Devol uci n de Factura" Procesar
Mostrar Pantal l a de Devol uci on de Facutura CapturarSel ecci on ( )

Regi strar Devol uci n de
Factura Ingresar cedul a de i denti dad del paci ente Procesar
Mostrar paci ente CargarPaci ente ( )
Sel ecci onar facturas "Conformadas por Medi camento" Procesar

Cargar Sel ecci on ( )
Mostar Sel ecci on
Sel eci onar Factura Procesar
Mostar Formul ari o Cargar Formul ari o

Regi strar Devol uci n de
Factura Por Ingresar observaci ones
Medi camento
Presi onar "Aceptarr" Procesar
Val i dar Regi stro ( )
Noti fi ca que l os Resul tados han si do Guardados Asi gnarStatus ( )
Sel eci onar Facturas Por "Atenci on Mdi ca Parti cul ar" Procesar
Mostar Sel ecci on Cargar Sel ecci on ( )

Sel eci onar Factura
Regi strar Devol uci n de Pul sar "Aceptar" Procesar

Factura Por Atenci on
Mdi ca Parti cul ar Val i dar Regi stro ( )
Noti fi car que l os Resul tados han si do Guardados Asi gnar Stats ( )
Diagrama 35: Diagrama de secuencia devolucin de factura. Fuente: Autor 2010.
205
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
207
Caso de Uso Consultar Factura CU-010

Actores
2. Jefe del departamento.
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.
Validar Usuario
<<Include>>
Consultar Facturas Facturas Procesando
Usuario del Sistema <<Include>>
Registro de Facturas
Facturas Conformadas
Facturas Devueltas
Diagrama 36: Diagrama. Caso de uso Consultar Factura. Fuente: Autor 2010
Propsito
Permitir al usuario consultar las facturas y su respectivo status.
Resumen
En ste caso de uso se describe el proceso para consultar el status de una facturas
conformada o devueltas
208
Curso Normal (Bsico) consultar Factura

El usuario selecciona del men El sistema muestra un formulario para el
1 principal Factura la opcin 2 ingreso de la cedula del paciente a
Consultar Factura. consultar.
El usuario introduce la cedula a
3 consultar.
El usuario hace clic en la El sistema carga los datos del paciente
4 cedula correspondiente. 5 en la pantalla consultar facturas y
muestra las opciones de factura a
consultar.
El usuario selecciona la opcin El sistema despliega en pantalla las
6 de factura por 6.1 facturas del paciente por medicamentos
Medicamentos. y el status de ellas.
El usuario selecciona la opcin El sistema despliega en pantalla las
7 factura por Atencin Mdica 7.1 facturas del paciente por medicamentos
Particular. y el status de ellas.
8 El usuario presiona atrs. 9 El sistema regresa a la pantalla principal

de consultar facturas.
Tabla 34: Curso bsico de eventos para la consulta de factura. Fuente: auto 2010
Cursos Alternos Para consulta de Factura
6.1 Si no se encuentra ninguna factura asociada al paciente, el sistema lo informa en

7.1 un mensaje de alerta indicando.
Tabla 35: Curso alterno de eventos para la consulta de factura. Fuente: auto 2010
Comentarios
1
Se puede consultar cual es el status de una factura, para un determinado
paciente.
Usuario del Sistema
209
Diagrama de Secuencia para el consulta de Factura
W:Facturas Facturas Paciente
Usuario del Sistema

Seleciona"Consultar Factura" Procesar
Mostrar pantalla para realizar busqueda CapturaSeleccion ( )
Ingresar cedula de identidad del paciente
Presionar "Buscar" Procesar cedula de identidad
Mostrar Paciente CargaPaciente( )
Por "Atencion Seleccionar factura por "Atencion Medica Particular" Procesar

Medica Particular"
Mostar factura CargafacturadeAtencion Medica Particular( )
Seleccionar factura por "Medicamento" Procesa

Por "Medicamento"
Muestra Factura CargafacturadeMedicamento( )
Diagrama 37: Diagrama. Secuencia Consultar Factura. Fuente: Autor 2010.
210
Pantallas de Consultar Factura
Pantalla 1/3. Seleccin Consultar Factura

P
Pantalla 2/3. Consultar Factura Por Medicamentos

P
211
Caso de Uso Control de Medicamento CU-011

Doctor
Actores
Enfermeras
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
Realizar Mantenimiento de Medicamento
Condicion =Actualizar medicamento

Punto de Extension = Verificar tipo de control
<< Extiende>>
Validar Usuario
Controlar Medicamentos << Include>>
Verificar tipo de control
Usuario del Sistema
<< Extiende>>
Registrar Salida Eventual

Condicion = Suministrar medicamento
Punto de Extension = Verificar tipo de control
Registrar Salida
Verificar tipo de
salida
Registrar Salida por Recipe
Diagrama 38: Diagrama. Caso de uso Control de medicamento. Fuente: Autor 2010
Propsito
Llevar un registro de los medicamentos con los que cuenta el servicio mdico.
Resumen
En ste caso de uso se describe el proceso para el control de la salida de algn medicamento de farmacia.
212
Curso Normal (Bsico) Para el Mantenimiento de Medicamento

1 El usuario selecciona la opcin 2 El sistema muestra pantalla de
Mantenimiento de mantenimiento de medicinas.
Medicinas men principal de
Medicamento
3 El usuario ingresa el nombre del
medicamento que desea
consultar
4 El usuario presiona el botn 5 El sistema realiza bsqueda del
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
Aceptar medicamento.
8 Modificar Medicamento 8.1 El sistema muestra pantalla con
El usuario marca la opcin formulario para ingresar medicamento
Modificar Medicamento. existente.
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
6
medicamento (Nombre, presentacin, cantidad y fecha de vencimiento). Una vez
llenado el formulario, el usuario debe presionar el botn aceptar y se actualiza
el medicamento.
Tabla 37: Curso alterno de eventos mantenimiento de medicamento. Fuente: auto 2010
213
Curso Normal (Bsico) Para la Salida de Medicamento

El usuario selecciona la opcin El sistema muestra un formulario donde se
1 REGISTRAR SALIDA 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
correspondiente. eventual de medicamento con los datos del
paciente.
El usuario ingresa el nombre del El sistema carga la lista con los nombres de
2.2 medicamento a consultar. 2.3 los medicamentos existente con el nombre
que usuario ingreso.
El usuario selecciona el El sistema carga y muestra una pantalla con
2.4 medicamento y presiona el botn 2.5 el medicamento a despachar para que el
Aceptar usuario seleccione cantidad y motivo de
despacho.
El usuario selecciona cantidad , El sistema carga seleccin y notifica la
2.6 motivo de despacho y presiona el 2.7 salida del medicamento.
botn Aceptar
El usuario hace clic en el botn El sistema muestra un formulario donde se
3 REGISTRAR SALIDA 3.1 debe ingresar la cedula del Paciente.
RCIPE
3.2 El usuario hace clic en la cedula 3.3 El sistema carga los datos del paciente y
correspondiente. muestra los registros de rcipes asociados al
paciente.
El usuario selecciona el rcipe a El sistema muestra el rcipe para dar
3.4 despachar VER RECIPE 3.5 constancia que la informacin sea correcta.
El usuario presiona el botn El sistema registra salida por rcipe notifica
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 Con este proceso se puede mantener un control de los medicamentos que se
despachan y a que paciente se lo suministran.
Usuario del Sistema
214
Diagrama de Clases
Medicamento SalidaMedicamento
+ num : int
+ id : int
+ nombre : String 1 + cedula : String
+ presentacion : String + medicamento : int
+ cant : int
+ fecha : Date
+ fecha_v : Date
+ crear ()
+ Crear ()
+ Modificar ()
+ Eliminar () 1..*
MotivoDespacho
1..*
+ id : int
+ nomdre : String
+ Crear ()
+ Modificar ()
Recipe + Eliminar ()
+ numero : int
+ indicaciones : String
+ fecha : Date
+ paciente : String
+ estatus : String
+ doctor : int
+ MostrarRecipe ()
+ MostrarRecipes ()
+ Eliminar ()
Diagrama 39: Diagrama de clase Control de Medicamento. Fuente: Autor 2010
215
Diagrama de Secuencia para el Mantenimiento de Medicamento

W:Farm aci a M edi cam entos
Usuari o del Si stem a
Sel ecci onar "M anteni m i ento de M edi cam entos" Procesar
CapturarSel ecci on ( )
Buscar M ostrar pantal l a para el m anteni m i ento de m edi cam entos
M edi cam ento
Ingresar Nom bre del M edi cam ento
Presi onar "Buscar" Procesar Busqueda

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

El i m i nar
M edi cam ento M ostrar pantal l a pri nci pal de control de m edi cam entos El i m i naM edi cam ento( )
Presi onar el boton "M odi fi carr" Procesar

M ostrar pantal l a para m odi fi car m edi cam entos CargaDatosDeM edi cam ento( )
Ingresa Canti dad
M odi fi car
Ingresa Fecha de venci m i ento
Presi onar "Aceptar" Procesa

M ostrar pantal l a pri nci pal de control de m edi cam entos GuardaM odi fi caci on( )
Diagrama 40: Diagrama. Secuencia de mantenimiento de medicamento. Fuente: Autor 2010
216
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
218
Diagrama de Secuencia para la salida de Medicamento
W:Medicamentos Medicamento Paciente Recipe
Usuario del Sistema
Seleccionar "Registrar Salida Eventual" Procesar
Mostrar pantalla para realizar busqueda CapturarSeleccion ( )
Registrar Salida
Eventual
CargarPaciente ( )
Mostrar datos de paciente en la pantalla de " salida eventual"
Ingresar nomdre del medicamento Procesar
Muestra pantalla con seleccion de medicamento CargarMedicamento ( )

Pulsar " Aceptar" Procesar
Mostra pantalla " REGISTRO DE SALIDA" CargaSalidaDeMedicamento( )
Seleccionar "Registrar Salida Por Recipe" Procesar
CargarSeleccion ( )
Mostrar pantalla para realizar busqueda
Registrar salida por
recipe
CargarDatosdePaciente ( )
Procesa
Mostrar Recipes del Paciente CargaRrecipedelPaciente ( )
Seleccionar Recipe
Procesar
Muestra Recipe lleno CargarMedicamentosdeRecipe ( )
Presionar "Aceptar" Procesar
Mostar pantalla "salida por Recipe" ValidarRegistro ( )
Diagrama 41: Diagrama. Secuencia salida de medicamento. Fuente: Autor 2010
219
Pantallas de Salida de Medicamento
Pantalla 1/6.Registar Salida eventual de Medicamento

Rcipe
Pantalla 2/6.Buscar Medicamento
220
Pantalla 3/6.Agregar Medicamento de Farmacia
Pantalla 4/6.Registar Salida de Medicamento Por Rcipe
221
Pantalla 5/6.Despachar Medicamentos de Rcipe
Pantalla 6/6.Verificar Medicamentos Rcipe
222
Caso de Uso Generar Reportes CU-012

Jefe del departamento.
Actores
Aux. Registro y Estadstica
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.
Validar Usuario
<<Include>>
Generar Reporte
Usuario del Sistema
Diagrama 42: Diagrama. Caso de uso generar reporte. Fuente: Autor 2010
Propsito
Generar reportes a los usuarios. Estos reportes mostraran el resumen de un determinado

proceso en un intervalo de fechas definido por el usuario.
Resumen
En ste caso de uso se describe el proceso para generar un reporte.
223

El caso de uso comienza cuando El sistema captura la seleccin
1 el usuario selecciona la opcin 2
Generar Reportes
3 El sistema muestra pantalla para
seleccionar el tipo de reporte.
El usuario selecciona el tipo de El sistema despliega tabla con el criterio
reporte. (Facturas Conformadas, de bsqueda.
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 botnEl sistema efecta la bsqueda de acuerdo
7 Generar Reporte. 8 a lo seleccionado.
9 El sistema muestra el registro.
Presionar el botn Imprimir El sistema imprime reporte
10 Reporte 11
Tabla 40: Curso bsico de eventos generar reporte. Fuente: auto 2010
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
Usuario del Sistema
sobre su gestin.
224
W: Reportes Bol eta Doctores Reci pe Facturas M edi cam ento Ci tas
Usuari o del Si stem a Im presora
Sel ecci onar reporte de bol eta m edi ca

M uestra sel ecci on
Sel ecci onar servi ci o
Reporte de
bol etas m edi cas M arcar "Asoci ar Paci ente"
em i ti das
Ingresar cedul a de Identi dad del paci ente
Sel ecci onar fecha y presi onar el boton "Generar Reporte" Procesar
EfectuarBusqueda ( )
M ostrar resul tado de bol etas segun cri teri o de busqueda
Sel ecci onar reporte de reci pe m edi co
M uestra sel ecci on

M arcar "Asoci ar Doctor" Procesar
Reporte de Reci pes M ostrar nom bres de doctores CargarNom bres ( )
Em i ti dos
M arcar "Asoci ar al Paci ente"
Sel ecci onar fecha y presi onar "Generar Reporte" Procesar
M ostrar resul tado de reci pes EfectuarBusqueda ( )
Sel ecci onar reporte de facturas conform adas
M ostrarSel ecci on ( )
Reporte de facturas
conform adas Sel ecci ona ti po de Factura Procesa
Acti va ti po de factura CargaT i podeFactura( )
Presi onar el boton "Generar Reporte" Procesar
M ostrar resul tado de facturas conform adas EfectuarBusqueda ( )
Sel ecci onar reporte de m edi cam entos sum i ni ni strados

Reporte Sal i da de
m edi cam entos Ingresar nom bre del M edi cam ento
El egi r cri teri o de busqueda

Presi onar el boton "Generar Reporte" Acti var
M ostrar resul tado de m edi cam entos sum i ni strados EfectuarBusqueda( )
Sel ecci onar reporte de ci tas
Reporte de Ci tas Sel ecci onar ti po de ci ta
M arcar "Asoci ar Doctor" Procesar

M ostrar nom bres de doctores CargarNom bres( )
Sel ecci onar Doctor
Sel ecci onar fecha y presi onar "Generar Reporte" Procesar
M ostrar resul tado de Ci tas EfectuarBusqueda ( )
Procesar Im presi on
Im pri m i r reporte Presi onar "Im pri m i r Reporte"
Diagrama 43: Diagrama. Secuencia generar reporte. Fuente: Autor 200.
225
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
227
32. Requisitos Suplementarios (No funcionales)
En esta parte se desarrollan las mtricas de calidad ya antes definidas en el

documento de definicin de requisitos no funcionales para el sistema, estas mtricas
proporcionan una indicacin de cmo se ajusta el software a los requisitos implcitos
y explcitos definidos por el cliente. A continuacin se mide:
1.ADECUIDAD Establecemos esta mtrica al sistema para medir cualitativamente la capacidad

del producto software para proporcionar un conjunto apropiado de funciones
para tareas y objetivos de usuario especificados.
Nombre: Completitud de implementacin Propsito: Qu tan completa est la implementacin funcional.

funcional
Mtodo de aplicacin: Contar las funciones faltantes detectadas en la evaluacin y comparar con el nmero de funciones
descritas en la especificacin de requisitos. Con versin 1.0 del documento DER (Documento Especificacin de
Requisitos) se obtuvo el siguiente resultado:
Se concretaron todos los procesos definidos por 11 casos de uso.
No existe funcin faltante de ms de 70 exigidas y recolectada por requisitos funcionales y no funcionales.
Medicin frmula: Solucin: Interpretacin:
X = 1 - A/B X = 1 - A/B 0 <= X <= 1
A = nmero de funciones faltantes X = 1 - 0/70 Entre ms cercano a 1, ms completa.
B = nmero de funciones descritas en la especificacin X=1
de requisitos
Fuente de Medicin: Audiencia:
La validacin fue dada por el Gestor de configuracin Desarrolladores del centro de computacin de la universidad
de Software, Analista de sistemas, Arquitecto de de oriente ncleo Monagas.
software y la revisin conjunta del Responsable Generar
del Proyecto.
Tabla 42: tabla de mtrica Adecuidad ISO 9126. Fuente: auto 2010
2.MADUREZ Establecemos esta mtrica al sistema para medir cualitativamente la capacidad

del producto software para proporcionar un conjunto apropiado de funciones para
tareas y objetivos de usuario especificados.
Nombre: Suficiencia de las pruebas Propsito: Cuntos de los casos de prueba necesarios estn cubiertos
por el plan de pruebas.
Mtodo de aplicacin: Desde el desarrollo del software hasta la implantacin fue cubierta por todas las pruebas
necesarias o exigidas por del mtodo WATCH donde se aplica el Plan de verificacin y Validacin correspondientes a
las pruebas de procesos.
A todos los procesos se le realizaron pruebas.
Solo 1 caso de uso ms 2 mantenimientos del sistema se tomaron como ejemplo para el plan de pruebas
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
La validacin fue dada por el Gestor de configuracin Desarrolladores del centro de computacin de la universidad
de Software, Analista de sistemas, Arquitecto de de oriente ncleo Monagas.
software y la revisin conjunta del Responsable Generar
del Proyecto.
Tabla 43: tabla de mtrica Madurez ISO 9126. Fuente: auto 2010
228
3.ENTENDIBILIDAD Capacidad que tiene el producto de software que le permita al usuario

entender si el software es adecuado y como puede ser usado para una tarea
o condicin de uso particular.
Nombre: Funciones evidentes 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.
X = A/B X = A/B 0 <= X <= 1
A = nmero de funciones (o tipos de funciones) evidentes al X = 11/15 Entre ms cercano a 1,
usuario X = 0,733333 mejor.
B = total de funciones (o tipos de funciones)
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 Capacidad del producto de software para proporcionar tiempo de respuesta,

EN EL TIEMPO tiempo de procesos y potencia, bajo condiciones determinadas
Nombre: Tiempo de respuesta Propsito: Cul es el tiempo estimado para completar

una tarea.
Mtodo de aplicacin: Evaluar la eficiencia de las llamadas al SO y a la aplicacin.

Estimar el tiempo de respuesta basado en ello. Puede medirse:
Todo o partes de las especificaciones de diseo.

Producto completo durante la fase de pruebas.
Solo a 1 proceso se le medir el tiempo de respuesta. PROGRAMAR CITA MEDICA.
X = tiempo (calculado o simulado) X = 1 seg. Entre ms corto, mejor.

Tabla 45: tabla de mtrica ISO 9126. Comportamiento en el tiempo Fuente: auto 2010
229
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.
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.
Tabla 45: tabla de mtrica C ISO 9126. Cambiabilidad .
6. CONFORMIDAD DE LA Capacidad del producto software para adherirse a normas o

TRANSPORTABILIDAD 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.
X = A/B X=0 0 <= X <= 1
A = nmero de artculos implementados de conformidad Entre ms cercano a 1, ms
B = total de artculos que requieren conformidad completa.
Tabla 46: tabla de mtrica C ISO 9126. Conformidad de la Transportabilidad
230
NUCLEO MONAGASCE
TODOS LOS DERECHOS RESERVADO
5.3 ETAPA III

PROCESO DE CONSTRUCCIN,
GESTIN Y SOPORTE

DOCUMENTO DISEO ARQUITECTNICO Y DETALLADO
Versin 1.0
Lolimar Cedeo 28-11-09 1.0 Versin preliminar
1. 1. Introduccion
1. Introduccin
El Diseo Arquitectnico produce la estructura de la aplicacin representada
como una arquitectura de software que muestra los componentes de la aplicacin,
sus conectores y las restricciones arquitectnicas. El Diseo Detallado describe
cmo se debe implementar cada uno de estos componentes arquitectnicos. Este
documento contiene las especificaciones de diseo arquitectnico y detallado de
del sistema para asegurarse que cumplir con todos los requisitos acordados y
satisface las necesidades del cliente para poner en produccin la aplicacin.
2. 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
PaguinasModulos
Usuario - cod_pag : int
- descripcion : int PaguinasUsuario
+ nombre : String Modulos
- url : int - cod_usu : int
+ apellido : String - cod_mod : int 1..* - cod_mod : int - cod_pag : int
+ cedula : int ModulosUsuarios - descripcion : String - cod_tipo : int - id : int
+ usuario : String
- cod_usu : int - Eliminar () - Eliminar ()
+ nivel : int 1..* - Eliminar ()
- cod_mod : int + Insertar () + Insertar ()
+ clave : String 1..* + Insertar ()
- id : int + Actualizar () + Actualizar ()
+ cod_usu : int NivelDeAcceso
+ direcion : String - eliminar () + Editar () + Editar ()
1 + nivel : int 1..*
+ email : String + ingresar ()
+ descripcion : String
+ cod_sta : int
+ telefono : String - eliminar ()
+ ingresar ()
- Validar ()
- Insertar ()
- Eliminar ()
+ Mostar ()
+ Actulizar ()
Diagrama 44: Diagrama de clase usuario. Fuente: Autor 2010
233
Modelo de Clases de Procesos
Diagrama 45: Diagrama de clase de procesos. Fuente: Autor 2010
2.2.2 Tarjetas CRC

Las tarjetas CRC son muy tiles para observar la relacin entre cada una de
las clases que conforman el modelo de clases y las responsabilidades de cada una de
ellas.Como una extensin informal a UML, la tcnica de las tarjetas CRC se puede
usar para guiar el sistema a travs de anlisis guiados por la responsabilidad. Esta
tcnica define las responsabilidades y colaboraciones de cada clase a travs de todos
los escenarios. Las clases se examinan, se filtran y se refinan en base a sus
responsabilidades con respecto al sistema, y las clases con las que necesitan colaborar
para completar sus responsabilidades.
A continuacin se muestran las tarjetas CRC de las clases principales del
modelo de Clases:
234
Nombre de la Clase Citas

Responsabilidades Clases Colaboradoras
Crear la cita de pacientes
Almacenar la cita de pacientes Doctor
Consultar la cita de pacientes Especialidad
Programar la cita con un doctor en Paciente
una especialidad y en un horario
Identificar la cita con un status
Figura 34: Tarjeta CRC Citas. Fuente: Autor (2010).
Nombre de la Clase Paciente

Validar paciente Parentesco
Cargar datos generales de los TipoPaciente
pacientes. CargaFamiliar
Figura 35: Tarjeta CRC Paciente. Fuente: Autor (2010).
Nombre de la Clase Medicamento

Almacenar registro Paciente
Consultar SalidaMedicamento
Mostrar motivo de despacho MotivoDespacho
Buscar rcipe medico Recipe
Figura 36: Tarjeta CRC Medicamento. Fuente: Autor (2010).
Nombre de la Clase Historia

Crear y almacenar un tipo de historia Paciente
Consultar historia medica DpGeneraloInterna
Almacenar consultas medicas HGeneraroInterna
Mostrar datos generales del paciente
Figura 37: Tarjeta CRC Historia. Fuente: Autor ( 2010).
235
Nombre de la Clase Facturas

Crear registro de factura Paciente
Consultar registro de factura FacturaAtencionEspecilizada
Identificar el status de la factura FacturaMedicamento
Identificar doctor y especialidad EstadoFactura
Cargar doctores TipoDoctor
Buscar rcipe medico
Figura 38: Tarjeta CRC Facturas. Fuente: Autor (2010).
Nombre de la Clase Boletas

Crear y almacenar boleta medica BoletaPaciente
Consultar boleta medica Doctores
Cargar doctores externos Especilidad
Cargar laboratorios Laboratorios
Cargar servicios
Procesar impresin de boleta
Crear historial de boletas
Figura 39: Tarjeta CRC Boleta. Fuente: Autor (2010).
Nombre de la Clase Recipe
Crear y almacenar rcipe medico Paciente
Consultar rcipe medico DetallesRecipe
Cargar medicamentos
Procesar impresin de rcipe
Identificar status del rcipe
Figura 40: Tarjeta CRC Rcipe. Fuente: Autor (2008).
Nombre de la Clase DpHistoria
Cargar tipo de historia DpGeneralInterna
DpOdontologica
DpGinecologiaObstetricia
DpPediatria
Figura 41: Tarjeta CRC DPHistoria. Fuente: Autor (2008).
236
1.3. Modelo Vista de Despliegue
Es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para

modelar el hardware utilizado en las implementaciones de sistemas y las relaciones
entre sus componentes. Los elementos usados por este tipo de diagrama son nodos
(representados como un prisma), componentes (representados como una caja
rectangular con dos protuberancias del lado izquierdo) y asociaciones. El protocolo
de comunicacin utilizado para relacionar los distintos nodos fue el protocolo de
seguridad HTTPS (Hypertext Transfer Protocol Secure), el cual utiliza un cifrado
basado en el SSL (Secure Socket Layers), creando un canal para enviar/recibir
informacin.
Usuarios del Servicio Medico <HTTPS>
EXPLORADOR WEB
SERVICIO WED
<HTTPS>
<HTTPS>
SISTEMA WED
SISTEMA DEL SERVICIO MEDICO
<HTTPS>
SERVIDOR DE BASE DE DATOS ORACLE 10 GB
MANEJADOR DE BASE DE DATOS ORACLE 10 GB
BASE DE DATOS
Diagrama 46: Modelo de Vista de Despliegue. Fuente: Autor (2008).
237
2. Diseo de la base de Datos
1.1 Diseo conceptual de Usuarios
Modulos
ModulosUsuarios cod_mod Integer
cod_usu Integer Association_30 descripcion Variable characters (254)
cod_mod Integer
NivelDeAcceso Association_29 id Integer
nivel Integer
descripcion Variable characters (254)
Association_31
(D)
Association_28
PaguinasModulos
Usuario cod_pag Integer PaguinasUsuario
nombre Variable characters (254) descripcion Integer
url Integer cod_usu Integer
apellido Variable characters (254)
cod_mod Integer Association_38 cod_pag Integer
cedula Integer
cod_tipo Integer id Integer
usuario Variable characters (254)
nivel Integer
clave Variable characters (254)
cod_usu Integer
direcion Variable characters (254)
email Variable characters (254)
cod_sta Integer
telefono Variable characters (254)
Diagrama 47: Diseo conceptual de Usuarios. Fuente: Autor (2010)
1.2 Diseo conceptual de procesos
Diagrama 48: Diseo conceptual de Procesos de sitema. Fuente: Autor (2010)
238
1.3 Diseo Relacional De Usuario
Usuario
nombre varchar(254)
apellido varchar(254)
cedula integer
usuario varchar(254)
nivel integer
clave varchar(254)
cod_usu integer
direcion varchar(254)
email varchar(254)
cod_sta integer PaguinasModulos
telefono varchar(254) cod_pag integer
Modulos descripcion integer
FK_PAGUINAS_ASSOCIATI_MODULOS url integer
FK_USUARIO_ASSOCIATI_NIVELDEA cod_mod integer cod_mod integer
descripcion varchar(254) cod_tipo integer
NivelDeAcceso FK_MODULOSU_ASSOCIATI_NIVELDEA
nivel integer
descripcion varchar(254) FK_PAGUINAS_ASSOCIATI_PAGUINAS
FK_MODULOS_ASSOCIATI_MODULOSU
PaguinasUsuario
ModulosUsuarios cod_usu integer
cod_usu integer cod_pag integer
cod_mod integer id integer
id integer
Diagrama 49: Diseo relacional de Usuario. Fuente: Autor (2010)
1.4 Diseo Relacional de Procesos de sistema
Diagrama 50: Diseo Relacional de Procesos de sistema. Fuente: Autor (2010)
239
1.5 Diseo Fsico de la base de datos de Usuario
Diagrama 51: Diseo Fsico de la base de datos de Usuario. Fuente: Autor (2010)
1.6 Diseo Fsico de la base de datos de los Procesos de sistema
Diagrama 52: Diseo Fsico de la base de datos de Procesos. Fuente: Autor (2010
240
NUCLEO MONAGAS
TODOS LOS DERECHOS RESERVADO
5.4 ETAPA IV.

IMPLANTACIN DEL SISTEMA

DOCUMENTO INPLANTACION DE SOFTWARE
VERSIN 0.90
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 & Pruebas de la Entrega de la

Integracin Aplicacin Aplicacin
Programacin & Integracin (P&I) consiste en:

1. Elaborar, codificar o adaptar cada uno de los
componentes que integran las diferentes versiones
de la aplicacin empresarial.
2. Probar cada componente como una unidad.
3. Integrar estos componentes de acuerdo a la
arquitectura diseada.
4. Probar la integracin de estos componentes.
Pruebas de la Aplicacin (PA) consiste en verificar cada versin de la

aplicacin como un todo y depurar los errores encontrados, a fin de
asegurar que ella cumple con todos los requisitos especificados en el
Documento de Requisitos. Las pruebas se realizan a tres niveles:
1. Nivel de unidad, en el cual cada componente de software es
probado separadamente.
2. Nivel de integracin, en el cual se prueba la integracin de los
componentes y sus interacciones.
3. Nivel del sistema, en el cual una versin de la aplicacin se prueba
como un todo. Las pruebas de unidad y de integracin tienen lugar
durante el proceso de Programacin & Integracin; mientras que las
pruebas de sistema se realizan en el proceso de Pruebas de la
Aplicacin.
Entrega de la Aplicacin (EA) es el proceso tcnico final del

desarrollo de la aplicacin empresarial; en el cual, se realizan las
actividades necesarias para poner cada una de sus versiones en
operacin (produccin) y entregarla formalmente a sus usuarios.
A continuacin las especificaciones de los casos de pruebas aplicadas al sistema

desarrollado para el rea de servicios mdicos:
243
01
Especificacin de
Caso de Prueba Boleta Medica
Crear boleta
Descripcin Este artefacto abarca el conjunto de pruebas Buscar boletas
realizadas sobre el proceso de sistema Pruebas La prueba se realizara partiendo
Emitir Boleta Medica. Efectuadas del formulario de entrada de la
aplicacin.
1.Crear Boleta
Descripcin Se ingresa al sistema bajo la opcin de usuario y en el men de la aplicacin se ingresa a crear
boleta.
Condiciones de Ejecucin La nica condicin es que el usuario est registrado en el sistema para poder
acceder al mismo y el sistema mostrar la interfaz de boletas con sus respectivas
opciones (Nueva boleta,buscar).
Entrada Se introduce el nombre de usuario en el 7 Se secciona de un alista desplegable el tipo de
1 campo nombre de usuario. consulta por: Doctor Por Servicios
Se introduce la contrasea campo clave de 8 Se secciona de un alista desplegable el tipo de
2 acceso. servicio: Gustavo Brazon
3 Pulsar el botn Ingresar. 9 El sistema carga y muestra su especialidad
El sistema muestra en pantalla un campo vaco
4 Se introduce C.I del paciente. 10 para ingresa observaciones de la boleta.
Se posiciona el cursor del Mouse en la
5 opcin Ingresar. 11 Pulsamos Guardar.
6 Se posiciona el cursor del Mouse en la El sistema enva mensaje de notificacin y
opcin Crear Nueva Boleta. 12 regresa a la pantalla anterior para crear o
buscar una boleta si se quiere.
Resultado Esperado El sistema crea una boleta Medica correctamente.
Evaluacin de la Prueba Prueba superada con xito
2.Buscar Boletas
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
Condiciones de Ejecucin acceder al mismo.
Entrada 1 Se introduce el nombre de usuario en el 5 Se introduce en un campo el numero de boleta.
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
Evaluacin de la Prueba Prueba superada con xito.
Observacin: el sistema al crear una boleta asigna automticamente un numero de boleta.
Tabla 47: Especificacin de caso de pruebas boleta mdica. Fuente: autor 2010.
244
Especificacin de 02
Caso de Prueba
Administracin Motivo de Despacho
Este artefacto abarca el Crear Motivo despacho

Descripcin conjunto de pruebas realizadas Editar Motivo despacho
sobre el mantenimiento Pruebas La prueba se realizara partiendo del
Motivo de Despacho. Efectuadas 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.
Entrada Se introduce el nombre de usuario en el 7 Seleccionamos Motivo de Despacho
1 campo nombre de usuario.
2 Se introduce la contrasea campo clave 8 El sistema muestra pantalla de administracin
de acceso. de motivo de despacho
3 Pulsar el botn Ingresar. 9 Se hace clic en Agregar Nuevo Motivo de
Despacho.
El sistema permite el ingreso al sistema El sistema muestra pantalla para ingresar
4 con los privilegios de usuario. 10 nuevo motivo de despacho.
Seleccionamos Realizar Se ingresa el nombre del motivo de despacho
5 Mantenimiento en el men 11 y Pulsamos Registrar.
mantenimiento.
El sistema muestra una lista de los El sistema muestra mensaje de que el motivo
6 mantenimientos disponibles. 12 de despacha ha sido registrado.
Resultado Esperado El sistema crea un nuevo motivo de despacho.
2. Editar Motivo Despacho
Descripcin El sistema mostrar la interfaz de mantenimiento correspondiente a Motivo de
despacho con sus respectivas opciones (Agregar Nuevo, Modificar).
Condiciones de La nica condicin es que el administrador est registrado en el sistema
Ejecucin para poder acceder al mismo
Entrada 1 Se introduce el nombre de usuario en el 7 Seleccionamos Motivo de Despacho.
2 Se introduce la contrasea campo clave de 8 El sistema muestra pantalla de
acceso. administracin de motivo de despacho
3 Pulsar el botn Ingresar. 9 Se busca de motivo de despacho y se hace
clip en editar.
4 El sistema permite el ingreso al sistema con Se muestra pantalla para realizar
los privilegios de usuario. 10 modificaciones.
5 Seleccionamos Realizar Mantenimiento Presionamos Guardar
en el men mantenimiento. 11
6 El sistema muestra una lista de los El sistema emite un mensaje de que el
mantenimientos disponibles. 12 motivo de despacho ha sido actualizado.
Resultado Esperado El sistema modifica el motivo de despacho seleccionado.
Observacin: El motivo despacho se realiza para sacar un medicamento del departamento.
Tabla 48: Especificacin de caso de pruebas Motivo Despacho. Fuente: autor 2010
245
Especificacin de 03
Caso de Prueba Administrar Laboratorio
Agregar Laboratorio
Descripcin Este artefacto abarca el conjunto de Modificar Laboratorio
pruebas realizadas sobre el Pruebas La prueba se realizara
mantenimiento Laboratorios. Efectuadas 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).
Entrada Se introduce el nombre de usuario en el 7 Seleccionamos Laboratorio
1 campo nombre de usuario.
2 Se introduce la contrasea campo clave de 8 El sistema muestra pantalla de administracin
acceso. de laboratorio
3 Pulsar el botn Ingresar. 9 Se hace clic en Agregar Nuevo Laboratorio.
El sistema permite el ingreso al sistema El sistema muestra pantalla para ingresar
4 con los privilegios de usuario. 10 nuevo Laboratorio.
Seleccionamos Realizar Mantenimiento Se ingresa el nombre del Laboratorio y
5 en el men mantenimiento. 11 Pulsamos Registrar.
El sistema muestra una lista de los El sistema muestra mensaje de que el
6 mantenimientos disponibles. 12 Laboratorio ha sido registrado.
Resultado Esperado El sistema ingresa un Laboratorio.
2. Editar Laboratorio
Se ingresa a Mantenimiento, posteriormente se selecciona la opcin Laboratorios
Descripcin y el sistema mostrar la interfaz de mantenimiento correspondiente a Laboratorio
con sus respectivas opciones (Agregar Nuevo, Modificar).
Entrada 1 Se introduce el nombre de usuario en el 7 Seleccionamos Laboratorio.
2 Se introduce la contrasea campo clave de 8 El sistema muestra pantalla de administracin
acceso. de Laboratorio
3 Pulsar el botn Ingresar. 9 Se busca Laboratorio y se hace clip en editar.
4 El sistema permite el ingreso al sistema con Se muestra pantalla para realizar
los privilegios de usuario. 1 modificaciones.
0
5 Seleccionamos Realizar Mantenimiento Presionamos Guardar
en el men mantenimiento. 1
1
6 El sistema muestra una lista de los El sistema emite un mensaje de que el
mantenimientos disponibles. 1 Laboratorio ha sido actualizado.
2
Resultado Esperado El sistema modifica el Laboratorio seleccionado.
Tabla 49: Especificacin de caso de pruebas Laboratorio. Fuente: autor 2010
246
Responsables de las Pruebas de la Aplicacin
Las pruebas correspondientes de los procesos fueron realizadas y cubiertas al

finalizar la aplicacin por todos los interesados (stakeholders) del proyecto, bajo las
polticas y estndares de calidad del centro de computacin de la universidad de
oriente ncleo de Monagas. El proceso de evaluacin estuvo a cargo del responsable
general del proyecto Ing. Rosangela Garcia Jefe del departamento y de todo su equipo
de desarrolladores quienes conforman un equipo multidisciplinario en lo que a
desarrollo de software se refiere. La validacin de las versiones en los casos de
pruebas fueron dadas por la Ing. Yhuanailys Nez a quien es Gestor de calidad y
Gestor de configuracin de Software.
Entrega de la Aplicacin
El proceso tcnico final del desarrollo de la aplicacin empresarial fue

concluido con la entrega de la aplicacin al Dr. Trino Cabello Jefe del departamento
del Servicio Mdico odontolgico de la universidad de oriente ncleo de Monagas.
La aplicacin fue instalada de manera local en una extensin del servicio mdico
ubicada en la sede de Juanico. Esperando la incorporacin de la sede Guaritos.
Capacitacin de los usuarios
A los usuarios de la aplicacin se le dio la capacitacin necesaria para

manipular de manera correcta los procesos del sistema, la capacitacin fue
suministrada por la pasante Lolimar Cedeo desarrolladora de la aplicacin, quien
diseo un manual de usuario para que sirviese gua. Se hiso entrega del manual al
momento de entregar la aplicacin y se puede mostrar en el anexo de este trabajo.
247

DOCUMENTO GLOSARIO
VERSIN 0.90
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
oriente ncleo Monagas, as como sus respectivas definiciones:
Actor: un actor es aquella entidad externa, bien sea una persona o sistema, que interacta
con el sistema. Hay que tener en cuenta que un usuario puede acceder al sistema como
distintos actores. Es un rol que un usuario juega con respecto al sistema.
Automatizacin: Es la tecnologa utilizada para realizar procesos o procedimientos sin la

ayuda de las personas.
Boleta mdica: planilla para efectuar servicios asistenciales externos a la institucin,

incluye los datos del doctor, la identificacin del paciente, la fecha y el monto total de la
consulta.
Casos de Uso: Es una tcnica para capturar requisitos potenciales de un nuevo sistema o
una actualizacin de software. Cada caso de uso proporciona uno o ms escenarios que
indican cmo debera interactuar el sistema con el usuario o con otro sistema para conseguir
un objetivo especfico.
248
Confiabilidad: Es la ausencia de acceso no autorizado a la informacin.
Coordinacin administrativa: es una dependencia con lnea de mando directa del decanato
del ncleo, cuya funcin es controlar y regular el flujo de caja de la Universidad de Oriente.
Digitar: Incorporar datos a la computadora utilizando el teclado.
Dependencia: Unidades que conforman a la Institucin.
Desempeo: Es el grado en el cual un sistema o componente cumple con sus funciones

designadas, dentro de ciertas restricciones dadas, como velocidad, exactitud o uso de
memoria.
Disponibilidad: Cualidad de disponible. Cantidad disponible.
Enfermera: Es la profesin de titulacin universitaria de la persona que se dedica al

cuidado integral del individuo, la familia y la comunidad en todas las etapas del ciclo vital y
en sus procesos de desarrollo.
Escenario: Un conjunto de variables que para una situacin poseen un nivel de valor y un
grado de ocurrencia.
Frmaco: Sustancia orgnica o inorgnica, natural o sinttica, capaz de producir en el

organismo vivo cambios anatmicos o funcionales.
Funcionalidad: se valora evaluando el conjunto de caractersticas y capacidades del

programa, la generalidad de las funciones entregadas y la seguridad del sistema global.
Historia clnica: documento mdico legal donde queda registrada toda la relacin del
personal sanitario con el paciente, todos los actos y actividades mdico-sanitarias realizados
con l y todos los datos relativos a su salud, que se elabora con la finalidad de facilitar su
asistencia, desde su nacimiento hasta su muerte, y que puede ser utilizada por todos los
centros sanitarios donde el paciente acuda.
Linux: Versin de libre distribucin (gratis) del sistema operativo Unix, desarrollada
inicialmente por Linus Torvalds, y mejorada gracias a las contribuciones de programadores
de todo el mundo.
Medicamentos: Sustancia que se administra con fines curativos o preventivos de una

enfermedad.
Medicina: ciencia que estudia el cuerpo humano, sus enfermedades y curacin.
Medico: Persona que se halla legalmente autorizada para ejercer la medicina.
Modulo: es un componente autocontrolado de un sistema, el cual posee una interfaz bien

definida hacia otros componentes; algo es modular si es construido de manera tal que se
facilite su ensamblaje, acomodamiento flexible y reparacin de sus componentes.
Morbilidad: Nmero de personas afectadas por una enfermedad en un periodo de tiempo.
Navegador: Aplicacin que facilita el acceso de los usuarios a las pginas de Internet.
249
Optimizar: buscar la mejor manera de realizar una actividad.

Oracle: es un sistema de gestin de base de datos relacional fabricado por Oracle
Corporation.
Procedimiento administrativo: es la realizacin de una serie de labores en forma orgnica

y guardando una sucesin cronolgica en la manera de realizar esas labores.
Proceso: es un conjunto de actividades o eventos que se realizan o suceden con un

determinado fin.
Presupuesto: este departamento tiene como misin planificar revisar y controlar la

asignacin presupuestaria de los distintos proyectos, tantos acadmicos como
administrativos.
Rcipe mdico: es una importante transaccin teraputica entre el mdico y su paciente.

Representa un resumen del diagnstico, pronstico y tratamiento de la enfermedad del
paciente realizado por el mdico. Resume en un trozo de papel la capacidad diagnstica y la
experiencia teraputica del mdico, con instrucciones para aliviar o restablecer la salud del
enfermo.
Salud: es el logro del ms alto nivel de bienestar fsico, mental, social y de capacidad de
funcionamiento que permitan los factores sociales en los que viven inmersos el individuo y
la colectividad.
Servidor: Una computadora que aloja informacin disponible para los usuarios (llamado
clientes) en Internet o cualquier otro tipo de red.
Servicio: son actividades identificables, intangibles y perecederas que son el resultado de

esfuerzos humanos o mecnicos que producen un hecho, un desempeo o un esfuerzo que
implican generalmente la participacin del cliente y que no es posible poseer fsicamente, ni
transportarlos o almacenarlo.
Software libre: es la denominacin del software que respeta la libertad de los usuarios y
por tanto, una vez obtenido, puede ser usado, copiado, estudiado, modificado y redistribuido
libremente.
Stakeholder: Cualquier persona interesada en, afectada por y/o implicada con el
funcionamiento del sistema software.
Tramitacin: Serie de trmites prescritos para un asunto, o de los seguidos en l.
Usabilidad: Capacidad de un sistema o de una aplicacin de ser usado fcil o

eficientemente.
250
5.5 Anlisis Costo Beneficio.
El anlisis costo-beneficio es una tcnica que pretende determinar la

conveniencia de un proyecto mediante la enumeracin y valoracin en trminos
monetarios de todos los costos y beneficios derivados de dicho proyecto. En otras
palabras, esta tcnica proporciona una medida de la rentabilidad del proyecto, a travs
de la comparacin de los costos en que se incurren por la realizacin del proyecto con
los beneficios que se esperan obtener del mismo. Este anlisis se lleva a cabo para
justificar econmicamente el desarrollo de este proyecto, adems de determinar los
beneficios tangibles e intangibles que se generan.
5.5.1 Costos
A continuacin se detallan los costos que fueron necesarios para llevar a cabo
el desarrollo del proyecto y lograr la construccin del sistema Web para el rea de
servicios mdicos odontolgicos de la Universidad de Oriente Ncleo Monagas:
Costos de Personal
En estos costos se incorporan los salarios devengados por el personal

involucrado en el desarrollo del proyecto. En el caso del desarrollo del sistema para el
rea de servicios mdicos, la persona que participa en su realizacin es el autor en
calidad de pasante, por lo que la Universidad de Oriente Ncleo Monagas no incurre
en ningn gasto de este tipo.
Costos de Equipos y Herramientas
Son los costos relacionados con la adquisicin de los equipos hardware y

software necesarios para llevar a cabo el desarrollo del sistema. En este caso no fue
necesario realizar este tipo de gasto ya que el Centro de Computacin de la
Universidad de Oriente Ncleo de Monagas contaba con los equipos y herramientas
de trabajo requeridos.
251
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 Costo
Costos de Equipos y Herramientas de trabajo 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
252
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 Valor (Bs. F.)
Papel tipo carta (7 resmas x 50 Bs.F.) 350 Bs. F.
Papel tipo oficio ( 2 resmas x 40) 80 Bs. F.
Dispositivo USB (Pendrive) 170 Bs. F.
CD-ROM (10 unidades x 5 Bs. F.) 50 Bs. F
Cartuchos de tinta de impresin ( 6 x 100 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.
253
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

Tarea Sistema
Sistema Actual Beneficios
Pasado
Generar historia
0.6 h/h 0.1 h/h 0.5 h/h
Peditrica.
Tabla 51: Reduccin de tiempo.
B. Disminucin de tiempo en la generacin de reportes: Con la utilizacin del

sistema automatizado se reduce el tiempo en generar reportes de todos los
procesos que se llevan a cobo en el rea de servicios mdicos. Actualmente la
auxiliar de registro y estadstica tarda en elaborar estos reportes de 1 a 2 das
de trabajo de oficina en un total de 14 horas hombres (h/h) como aproximado.
En cambio, con el sistema solo se requieren de 0.05 h/h para generar estos
reportes, logrndose por lo tanto mayor agilidad en la materializacin y
agilizacin de los mismos. A continuacin se muestra en el siguiente cuadro
la diferencia que existe al implantarse el sistema.
254
Horas Hombres empleadas

Tarea Sistema
Sistema Actual Beneficios
Pasado
Generar Reportes 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:
Costo de resmas de Papel

Cant. Sistema Sistema
Cant.Papel Beneficios
Evento Papel Pasado Actual
Crear historias
8
medicas en un 400 Bsf ---- ---- 400 Bsf
Resmas
el ao.
Crear boletas
8
medicas en un 400 Bsf 3 Resmas 150 Bsf 250 Bsf
Resmas
ao.
Tabla 53: Costos de papelera sin el sistema.
D. Reduccin del tiempo de respuesta debido a un procesamiento ms rpido de

la informacin.
E. Se mantiene una conexin persistente con la base de datos.
F. Control en la emisin de documentos.
G. Mayor control en los gastos generados a travs del servicio mdico.
255
H. Asignacin de un presupuesto ajustado a los gastos que se originan en el

Servicio Mdico.
I. Tomar decisiones acertadas acerca del personal mdico que debe trabajar por
honorarios y por servicios.
Beneficios Intangibles
Los beneficios intangibles son aquellos beneficios asociados a una mejora que
por su naturaleza son muy difciles de cuantificar, pero de los que, indiscutiblemente,
la organizacin se ve beneficiada al llevar a cabo el desarrollo del proyecto. Estos
beneficios son los siguientes:
A. Mayor privacidad de la informacin

B. Manejo de informacin Confiable.
C. Aumentar la satisfaccin del cliente y de los pacientes del servicio mdico en
cuanto a la asistencia prestada.
D. Mayor organizacin funcional.
E. Mejoras en el desempeo del personal y mayor bienestar en el empleo debido
al uso de herramientas modernas para apoyar el funcionamiento del negocio.
F. Aumento en la calidad del servicio.
G. Facilidad en la elaboracin de reportes.
H. Motivacin del personal al utilizar herramientas modernas que le permitan
eliminar tareas rutinarias o tediosas.
I. Mejor imagen de la universidad al implementar nuevas tecnologas
256
CONCLUSIONES
1. La comunicacin con el cliente represent una clave fundamental para poder

validar los requisitos y cumplir con sus necesidades o requerimientos. La
comunicacin se da a partir de cada una de las iteraciones a lo largo del
proceso de desarrollo.
2. Disear la aplicacin, utilizando la herramienta de modelado de sistemas

UML, permiti tener una visin detallada del mismo, en funcin de los
diferentes diagramas realizados.
3. La metodologa GRAY WATCH , result ser una tcnica favorable en el

proceso de desarrollo de software, brindando una serie de tcnicas y
procedimientos que ayudaron a desarrollar la aplicacin y cumplir con los
objetivos planteados.
4. A pesar de considerar la flexibilidad del sistema, es decir, que pueda ser

adaptado a cambios; en el futuro podra ser necesario la incorporacin de
nuevos mdulos o cambios en los formularios, dependiendo de la evolucin
del servicio mdico en cuanto a la atencin y especialistas.
5. El sistema le permite al personal que labora en el servicio mdico de la

universidad, llevar un control y seguimiento de las historias medicas de los
pacientes, registros de la boletas y rcipes emitidos, as como tambin de la
entrada y salidas de medicamentos de uso comn, conformacin de facturas y
validacin de pacientes para la programacin de citas medicas.
257
6. La utilizacin de herramientas, resultan de gran ayuda para el proceso de
desarrollo de software, facilitando la labor de muchas tareas e impactando de
manera positiva en el tiempo.
7. No existe una forma nica de modelar sistemas, todo depende de la

perspectiva del analista y del grado de detalle que desee implementar para
dicha labor.
8. El desarrollo de un sistema de informacin, no hace referencia exclusivamente

a la tarea de codificacin, se refiere a una serie de pasos o procedimientos
para la creacin de un producto, incluyendo tambin aspectos como el
modelado del negocio y las tareas de anlisis y diseo.
258
RECOMENDACIONES
1. Acondicionar el rea de servicios mdicos para la instalacin de las

computadoras y cualquier otro tipo de requerimiento necesario para la
implantacin del sistema.
2. Integrar el sistema del rea de servicios mdicos, con el sub.-sistema de

control de estudios y con el de servicio social para poder realizar la
validacin de los estudiantes, obreros y empleados, as como de su respectiva
carga familiar.
3. Seguir implantando sistemas automatizados en la Universidad de Oriente

ncleo Monagas y no desarrollar proyectos de software que cuyo alcance
finalice en la fase de diseo.
4. Seguir utilizando la metodologa GRAY WATCH para el proceso de

desarrollo de software en la Universidad, ya que usa las mejores prcticas de
ingeniera de software y gestin de proyectos. En la actualidad los mejores
mtodos para desarrollar aplicaciones empresariales son los interactivo e
incrementales pues dan los mejores resultado.
5. Implementar polticas de seguridad para garantizar el resguardo de los datos.
6. Fortalecer la plataforma tecnolgica del ncleo para que todas las reas
involucradas tengan acceso a la red, dado que el sistema propuesto es una
aplicacin Web.
7. Vincular el sistema desarrollado con el subsistema de compra para utilizar

informacin requerida de las rdenes de compra en los procesos de registro de
entrada de insumos mdicos a la farmacia.
259
BIBLIOGRAFA
ARIAS, F. (2006). El proyecto de investigacin: Introduccin a la metodologa

cientfica. (5 ed.) Caracas - Venezuela: Episteme.
BALESTRINI ACUA, M. (2002). Cmo se Elabora el Proyecto de Investigacin.

(6a. ed.). Caracas: BL Consultores Asociados.
CASTRO, M. (2003). El proyecto de investigacin y su esquema de elaboracin.

(2.ed.). Caracas: Uyapal.
BALESTRINI, MIRIAM (2006) Cmo se elabora el Proyecto de investigacin.

Quinta Edicin. Editorial Consultores Asociados. Caracas
BARRIENTOS, ENRQUEZ (2005). El desarrollo de sistemas de informacin

empleando el lenguaje de modelado unificado UML. Documento en lnea.
Disponible en http://www.monografias.com/trabajos16/lenguaje-modelado-
unificado/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.

Teisis Lolimarcedeño PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Teisis Lolimarcedeño PDF

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD DE ORIENTE

IMPLEMENTACIN DE UN SISTEMA AUTOMATIZADO QUE

Br. Lolimar D. Cedeo M.

Maturn, Octubre de 2010

En mi carcter de Asesor Laboral del trabajo presentado por el Bachiller

Ing. Rosngela Garca

En mi carcter de Asesor Acadmico del trabajo presentado por el Bachiller

Ing. Jess Chaparro

A mis abuelos quienes fueron y sern La Raz y el Tronco", el mejor pap y la

Autor: Cedeo M. Lolimar

IMPLEMENTACIN DE UN SISTEMA AUTOMATIZADO QUE OPTIMICE LA GESTIN

El presente trabajo de investigacin tiene como propsito principal implementar un

Palabras Claves: Modelado, Sistema, Servidor, Servicios Mdicos.

ACTA DE EVALUACIN .................................................................................... ii

Figura 1 Organigrama del Centro de Computacin de la U.D.O Monagas.. .......... 7

Tabla 1: Relacin entre clases. .............................................................................. 38

Diagrama 1: Diagrama de actividades programar cita mdica. .......................... 109

Diagrama 31: Diagrama de secuencia emitir rcipe medico. .............................. 195

La continua evolucin de la tecnologa informtica y el creciente inters de la

En el campo de los procesos mdicos, los sistemas de informacin estn

Desde esta perspectiva el rea temtica est centrada en un sistema de

La metodologa fue sustentada junto a las herramientas de lenguaje de

El trabajo est conformado por cinco (5) captulos:

Captulo I: Contiene informacin del contexto organizacional relacionada con

Captulo II: Este captulo contempla el planteamiento del problema, los

Captulo IV: En este captulo se detalla la metodologa que se implement y la

Captulo V: Recoje los resultados alcanzados, partiendo de la aplicacin de la

1.1. Resea Histrica de la Universidad de Oriente, Ncleo Monagas.

El Ncleo de Monagas de la Universidad de Oriente, responde a las necesidades

La Universidad de Oriente reafirmar su compromiso de ser el centro de

Formar profesionales del ms alto nivel de calidad, profesionales que

Mantener una permanente vinculacin con sus egresados para su actualizacin

1.2 Centro de Computacin, Universidad de Oriente Ncleo Monagas.

El Centro de Computacin tiene como visin principal ser un centro

La misin del Centro de Computacin, es la de realizar labores de

Los objetivos del Centro de Computacin de la Universidad de Oriente Ncleo

a. Disear y desarrollar aplicaciones con fines didcticos y administrativos.

b. Asesorar a las autoridades universitarias del ncleo sobre las innovaciones

c. Generar conocimientos en las diversas reas de la computacin y sistemas

d. Ofrecer servicios a la comunidad local y regional en los rubros de anlisis,

e. Coordinar la aplicacin de servicios informticos a otras unidades

f. Desarrollar los sistemas de informacin que permitan la automatizacin de

g. Capacitar el recurso humano de la institucin con la finalidad de asegurar

h. Evaluar y controlar la plataforma operativa del Centro de Computacin.

El Centro de Computacin cumple con las siguientes funciones, a objeto de

a. Brindar de forma permanente soporte tcnico a las unidades

b. Procesar lo relacionado con la nmina de pago, el rea de

c. Desarrollar y mantener los sistemas de informacin orientados al proceso

d. Coordinar y supervisar el funcionamiento de las unidades que integren

e. Distribuir, segn la capacidad productiva, las tareas del personal

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

g. Prestar asesora en el rea de computacin y Teleinformtica a aquellas

h. Procesa toda la informacin necesaria para el Dpto. de Admisin y

i. El Centro puede atender solicitudes de aplicaciones para el anlisis

PROGRAMAS Y SECCIN DE APOYO

Produccin y Valor agregado Redes Soporte Tcnico Seguridad

Figura 1 Organigrama del Centro de Computacin de la Universidad de Oriente, Ncleo

1.3. Servicio Mdico de la Universidad de Oriente

La fuente Universidad de Oriente (2010), acota que el Servicio Mdico del

Desde este ngulo, la salud de sus miembros se constituye en una parte

Brindar atencin mdico - odontolgica de carcter preventivo a la

La misin del Servicio Mdico es brindar atencin mdica preventiva en los

El Servicio Mdico tiene como visin los siguientes aspectos: