T 3045

Vista previa del material en texto

UNIVERSIDAD MAYOR DE SAN ANDRÉS 
FACULTAD DE CIENCIAS PURAS Y NATURALES 
CARRERA DE INFORMATICA 
 
 
 
 
PROYECTO DE GRADO 
 
“SISTEMA WEB DE GESTIÓN DE 
HISTORIALES CLÍNICOS VETERINARIOS” 
CASO: ANIMALES S.O.S. 
 
PARA OPTAR AL TÍTULO DE LICENCIATURA EN INFORMÁTICA 
MENCIÓN: INGENIERIA DE SISTEMAS INFORMÁTICOS 
 
POSTULANTE: VICTOR HUGO TÓRREZ CAMPOS 
TUTOR METODOLOGICO: M. Sc. ALDO RAMIRO VALDEZ ALVARADO 
ASESOR: M. Sc. ELIZABETH GARCÍA ESCALANTE 
 
LA PAZ – BOLIVIA 
2015 
 
 UNIVERSIDAD MAYOR DE SAN ANDRÉS 
 FACULTAD DE CIENCIAS PURAS Y NATURALES 
 CARRERA DE INFORMÁTICA 
 
 
 
 
 
 
 
LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y 
NATURALES PERTENECIENTE A LA UNIVERSIDAD MAYOR DE SAN ANDRÉS 
AUTORIZA EL USO DE LA INFORMACIÓN CONTENIDA EN ESTE 
DOCUMENTO SI LOS PROPÓSITOS SON ESTRICTAMENTE ACADÉMICOS. 
 
 
 
 
 
LICENCIA DE USO 
 
 
 
 
 
El usuario está autorizado a: 
 
a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil. 
b) copiar, almacenar o imprimir si ha de ser de uso exclusivamente personal y privado. 
c) copiar textualmente parte(s) de su contenido mencionando la fuente y/o haciendo la 
referencia correspondiente respetando normas de redacción e investigación. 
 
El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este 
material, sin la autorización correspondiente. 
 
 
 
 
 
TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS 
CONTENIDOS PUBLICADOS EN ESTE SITIO DERIVARA EN EL INICIO DE 
ACCIONES LEGALES CONTEMPLADOS EN LA LEY DE DERECHOS DE AUTOR. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
DEDICATORIA 
A mis padres José Efraín y Marianela, mis hermanas, 
María Antonia, Pamela Iris, Michelle Carmen, mi 
sobrina Rose Marian, mis abuelos, tíos y amigos, 
quienes me brindaron su apoyo incondicional en todo 
momento para alcanzar uno de los objetivos más 
importantes en mi vida. 
 
Con mucho cariño y admiración 
Victor Hugo Tórrez Campos 
 
 
 
 
AGRADECIMIENTO 
A Dios por haberme acompañado y guiado a lo largo de mi carrera, por ser mi fortaleza en 
los momentos de debilidad y por brindarme una vida llena de felicidad. 
Al Docente Tutor Metodológico M.Sc. Aldo Ramiro Valdez Alvarado, por la motivación, 
sus recomendaciones, consejos, material compartido y toda la colaboración brindada. 
A la Docente Asesora M.Sc. Elizabeth García Escalante quien con su profesionalismo y 
experiencia me colaboro en el transcurso de la elaboración del presente proyecto. 
A los docentes de la carrera de informática por todos los conocimientos transmitidos durante 
la etapa de mi formación universitaria 
A la carrera de Informática y la Universidad Mayor de San Andrés por la formación 
profesional dada. 
A Animales S.O.S. por darme la oportunidad, colaboración e información necesaria para la 
realización del presente proyecto 
A mis compañeros de trabajo Andre, Freddy, Gary, Edwin y Erick que me motivaron a seguir 
adelante en los momentos difíciles. 
Finalmente, a mis amigos, por los momentos compartidos a lo largo de estos años, su apoyo 
y cariño. 
 
 
 
 
 
 
 
 
RESPONSABILIDAD DEL AUTOR 
Mediante la presente declaro de manera pública que el proyecto de grado titulado “Sistema 
Web de Gestión de Historiales Clínicos Veterinarios” caso: Animales S.O.S., es de mi autoría 
y no constituye una copia o replica de trabajos similares elaborados con carácter previo. 
Autorizo la publicación de mi propuesta en internet y me comprometo a responder todos los 
cuestionamientos que se desprendan de su lectura 
La Paz, Noviembre del 2015 
 
 
Victor Hugo Torrez Campos 
victorhtc@hotmail.com 
 
 
 
 
 
 
 
 
 
RESUMEN 
Debido a la gran cantidad de información que se maneja, las organizaciones dependen hoy 
más que nunca de herramientas para el procesamiento de datos y toma de decisiones pues 
permiten tener un control efectivo de las actividades, un almacenamiento ordenado de la 
información, claridad en los procesos, confidencialidad y seguridad en los datos. 
El presente proyecto fue desarrollado en Animales S.O.S. una entidad sin fines de lucro 
fundada en 1995, la cual proporciona servicios de atención clínica veterinaria, para los cuales 
se identificaron problemas en los procesos manuales de registro de información, perdida de 
historiales clínicos, fallas humanas en el almacenamiento y transcripción de la información, 
por lo que se desarrolló un Sistema Web de Control de Historiales Clínicos Veterinarios que 
actualmente proporciona una herramientas de refuerzo y control automatizado en las 
actividades de atención clínica veterinaria. 
En las fases análisis, diseño, implementación y pruebas de la aplicación, se utilizó la 
metodología ágil de desarrollo de software XP, complementada con las herramientas de 
modelado web que proporciona WebML. 
El proceso de diagnóstico está diseñado en base al Método clínico y los formularios de 
control fueron modelados en base a los propuestos por la Historia Clínica orientada a 
Problemas (HCOP) 
La calidad del software fue determinada por WebSite QEM una metodología de análisis de 
calidad web basada en la ISO 9126, la cual proporciona estándares de usabilidad, 
funcionalidad, confiabilidad y eficiencia. 
 
Palabras clave: Atención clínica veterinaria, XP, WebML, HCOP 
 
 
 
ABSTRACT 
Due to the large amount of information handled, organizations depend more than ever of 
tools for data processing and decision making as they allow to have effective control of the 
activities, orderly storage of information, clarity of processes, confidentiality and data 
security. 
This project was developed in Animals SOS a nonprofit organization founded in 1995, which 
provides veterinary clinical services, for which problems are identified in manual processes 
for recording information, loss of medical records, human failure in the storage and 
transcribing information, so a Web Control System Veterinary Medical Records currently 
provides reinforcement tools and automated control in veterinary clinical care activities 
developed. 
Agile software development XP was used in the phases analysis, design, implementation and 
testing of the application, supplemented by web modeling tools providing WebML. 
The diagnostic process is designed based on the clinical method and control forms were 
modeled based on those proposed by the Problem Oriented (HCOP) Medical Records. 
Software quality was determined by WebSite QEM methodology for analyzing web quality 
based on ISO 9126, which provides standards for usability, functionality, reliability and 
efficiency. 
 
Keywords : Veterinary Care , XP , WebML , POMR 
 
 
 
 
 
INTRODUCCIÓN 
El presente trabajo describe el desarrollo de un sistema web para la gestión de historiales 
clínicos veterinarios, incorporando en su proceso de la metodología ágil de desarrollo de 
software XP, las fases del método clínico y los modelos de la historia clínica orientada a 
problemas. El trabajo está estructurado en los siguientes capítulos: 
El capítulo 1 hace referencia al contexto de la problemática que se pretende solucionar, 
proyecta los antecedentes, se identifican lo problemas y se definen los objetivos que 
requieren alcanzar al finalizar el trabajo, además de mencionar los alcances, límites y aportes. 
El capítulo 2 describe los métodos, modelos y conceptos fundamentales que deben ser 
considerados para el desarrollo del sistema. 
El capítulo 3 presenta las fases de la metodología aplicada, los requerimientos extraídos, los 
modelos planteados, las interfaces implementadas y las pruebas realizadas en el desarrollo 
del proyecto. 
El capítulo 4 describe el análisis de calidad y seguridad que se realizó al proyecto 
implementado. 
El capítulo 5 proporciona información sobre la valuación de costos, gastosy beneficios que 
surgieron al momento de la implementación del sistema. 
En el capítulo 6 se dan a conocer los resultados, tras concluir el trabajo y se dan algunas 
recomendaciones para otros trabajos. Así también se describe el cumplimiento de los 
objetivos. 
 
 
 
 
 
ÍNDICE GENERAL 
 
 Dedicatoria 
 Agradecimientos 
 Responsabilidad del autor 
 Resumen 
 Abstract 
 Introducción 
CAPÍTULO I: MARCO PRELIMINAR ……………………………………………............1 
CAPÍTULO II: MARCO TEÓRICO.………………………………………………………..9 
CAPÍTULO III: MARCO APLICATIVO …………………………………………………39 
CAPÍTULO IV: CALIDAD Y SEGURIDAD.………………………………………….….81 
CAPÍTULO V: EVALUACIÓN COSTO BENEFICIO ………………………………..…91 
CAPÍTULO VI: MARCO DE CONCLUSIONES Y RECOMENDACIONES………….100 
 Referencias bibliográficas 
 Anexos 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ÍNDICE ESPECÍFICO 
 Dedicatoria 
 Agradecimientos 
 Responsabilidad del autor 
 Resumen 
 Abstract 
 Introducción 
 
CAPÍTULO I: MARCO PRELIMINAR ................................................................................ 1 
1.1. Antecedentes institucionales ....................................................................................... 2 
1.1.1. Proyectos .............................................................................................................. 3 
1.2. Antecedentes proyectos similares ................................................................................ 3 
1.3. Planteamiento del problema ........................................................................................ 4 
1.3.1 Problema central .................................................................................................... 5 
1.3.2. Problemas secundarios ......................................................................................... 5 
1.4. Objetivos ...................................................................................................................... 6 
1.4.1. Objetivo general ................................................................................................... 6 
1.4.2. Objetivos específicos ............................................................................................ 6 
1.5. Justificación ................................................................................................................. 7 
1.5.1. Justificación económica ........................................................................................ 7 
1.5.2. Justificación social ................................................................................................ 7 
1.5.3. Justificación tecnológica....................................................................................... 7 
1.6. Alcances y límites ........................................................................................................ 8 
1.6.1. Alcances ............................................................................................................... 8 
1.6.2. Límites .................................................................................................................. 8 
1.7. Aportes ........................................................................................................................ 8 
CAPÍTULO II: MARCO TEÓRICO ...................................................................................... 9 
2.1. Metodología ágil de desarrollo de software XP .......................................................... 9 
2.1.1. Roles ................................................................................................................... 10 
2.1.2 Fases XP .............................................................................................................. 11 
2.2. WebML ...................................................................................................................... 14 
 
2.2.1. Diagrama de estructura ....................................................................................... 14 
2.2.2. Diagrama de composición .................................................................................. 16 
2.2.3. Diagramas de navegación ................................................................................... 18 
2.3. El patrón MVC .......................................................................................................... 18 
2.4. Método clínico (MC) ................................................................................................. 21 
2.4.1. Etapas o pasos lógicos del método clínico ......................................................... 22 
2.4.2. Características del método clínico ...................................................................... 23 
2.4.3. Método clínico en medicina veterinaria ............................................................. 24 
2.5. Historia clínica orientada a problemas (HCOP) ........................................................ 31 
2.5.1. Problema HCOP ................................................................................................. 32 
2.5.2. Clasificación de problemas ................................................................................. 32 
2.5.3. Estructura de la HCOP ....................................................................................... 33 
2.6. Sanidad animal .......................................................................................................... 37 
2.6.1. Sanidad canina/felina .......................................................................................... 37 
CAPÍTULO III: MARCO APLICATIVO ............................................................................ 39 
3.1. Fase de planificación ................................................................................................. 40 
3.1.1. Clasificación e identificación de roles ................................................................ 40 
3.2.1. Historias de usuario ............................................................................................ 41 
3.1.3. Identificación de tareas de programación ........................................................... 47 
3.1.4. Iteraciones ........................................................................................................... 53 
3.1.5. Plan de entregas (Release Planning) ................................................................... 54 
3.2. Fase de diseño ............................................................................................................ 55 
3.2.1. Tarjetas CRC ...................................................................................................... 55 
3.2.2. Modelo de estructura .......................................................................................... 59 
3.2.4. Diagramas de composición ................................................................................. 60 
3.2.5. Diagrama de navegación .................................................................................... 67 
3.3. Fase de codificación .................................................................................................. 70 
3.3.1. Herramientas de desarrollo ................................................................................. 70 
3.3.2. Implementación de las interfaces de usuario ...................................................... 71 
3.4 Fase de pruebas ........................................................................................................... 79 
 
3.4.1 JUnit .................................................................................................................... 79 
3.4.2. ApacheBench ...................................................................................................... 80 
CAPÍTULO IV: CALIDAD Y SEGURIDAD ..................................................................... 81 
4.1. Elementos de calidad .................................................................................................81 
4.1.1. WebSite QEM .................................................................................................... 81 
4.1.2. Especificación de características de calidad QEM ............................................. 82 
4.1.3. Resultados ........................................................................................................... 89 
4.2. Elementos de seguridad ............................................................................................. 89 
4.2.1. Elementos de seguridad en la aplicación ............................................................ 90 
CAPÍTULO V: EVALUACIÓN COSTO BENEFICIO ...................................................... 91 
5.1. Análisis de costos ...................................................................................................... 91 
5.1.1. COCOMO II ....................................................................................................... 91 
5.1.2. USC COCOMO II .............................................................................................. 94 
5.1.3. Resultados ........................................................................................................... 95 
5.1.4. Costo total del proyecto ...................................................................................... 97 
5.3. Análisis costo beneficio ............................................................................................. 98 
5.3.1. Valor actual neto y Tasa interna de retorno ........................................................ 98 
5.3.2. Costo beneficio total el proyecto ........................................................................ 99 
CAPÍTULO: MARCO DE CONCLUSIONES Y RECOMENDACIONES ..................... 100 
6.1. Conclusiones ............................................................................................................ 100 
6.2. Estado de cumplimiento de los objetivos específicos ............................................. 100 
6.2. Recomendaciones .................................................................................................... 102 
REFERENCIAS 
ANEXOS 
 
 
 
 
 
 
ÍNDICE DE TABLAS: 
MARCO TEÓRICO 
Tabla 2. 1. Clasificación de problemas HCOP .................................................................................. 32 
Tabla 2. 2. Lista de problemas .......................................................................................................... 33 
Tabla 2. 3. Definición SOAP ............................................................................................................ 34 
Tabla 2. 4. Nota subjetiva SOAP ...................................................................................................... 34 
Tabla 2. 5. Objetivo SOAP................................................................................................................ 34 
Tabla 2. 6. Evaluación SOAP ............................................................................................................ 35 
Tabla 2. 7. Plan SOAP ...................................................................................................................... 35 
Tabla 2. 8. Hoja de flujo -Medicación .............................................................................................. 36 
Tabla 2. 9. Hoja de flujo - Controles ................................................................................................. 36 
Tabla 2.10. Hoja de flujo - Educación ............................................................................................. 36 
Tabla 2.11. Enfermedades canino/felinas.......................................................................................... 38 
 
MARCO APLICATIVO 
Tabla 3. 1. Organización del desarrollo Web .................................................................................... 39 
Tabla 3. 2. Descripción de los actores del sistema ............................................................................ 40 
Tabla 3. 3. Historia de usuario – Registro de propietarios ................................................................ 41 
Tabla 3. 4. Historia de usuario – Registro de mascotas .................................................................... 42 
Tabla 3. 5. Historia de usuario – Registro de vacunas ...................................................................... 42 
Tabla 3. 6. Historia de usuario – Registro de atención clínica .......................................................... 43 
Tabla 3. 7. Historia de usuario – Consulta historial clínico .............................................................. 43 
Tabla 3. 8. Historia de usuario – Generación de autorización de cirugía .......................................... 44 
Tabla 3. 9. Historia de usuario - Registro de proveedores ................................................................ 44 
Tabla 3. 10. Historia de usuario - Registro de insumos médicos ...................................................... 45 
Tabla 3. 11. Historia de usuario – Categorización de insumos médicos ........................................... 45 
Tabla 3. 12. Historia de usuario – Reportes inventarios ................................................................... 46 
Tabla 3. 13. Historia de usuario – Reportes cirugías ......................................................................... 46 
Tabla 3. 14. Tarea de programación – Registro de propietarios ....................................................... 47 
Tabla 3. 15. Tarea de programación – Registro de mascotas ............................................................ 48 
Tabla 3. 16. Tarea de programación – Registro de vacunas .............................................................. 48 
Tabla 3. 17. Tarea de programación – Registro de atención clínica ................................................. 49 
Tabla 3. 18. Tarea de programación – Consulta de historial clínico ................................................. 49 
Tabla 3. 19. Tarea de programación – Generación de autorización de cirugía ................................. 50 
Tabla 3. 20. Tarea de programación – Registro de proveedores de insumos médicos ...................... 50 
Tabla 3. 21. Tarea de programación – Registro de insumos médicos ............................................... 51 
Tabla 3. 22. Tarea de programación – Categorización de insumos médicos .................................... 51 
Tabla 3. 23. Tarea de programación – Reportes de inventarios ........................................................ 52 
Tabla 3. 24. Tarea de programación – Reportes de cirugías ............................................................. 52 
Tabla 3. 25. Tabla de planificación de iteraciones en el proyecto .................................................... 53 
Tabla 3. 26. Tabla de planificación de iteraciones en el proyecto .................................................... 54 
 
Tabla 3. 27. Tarjeta CRC - Propietario ............................................................................................. 55 
Tabla 3. 28: Tarjeta CRC –Mascota .................................................................................................. 56 
Tabla 3. 29. Tarjeta CRC – Diagnóstico ........................................................................................... 56 
Tabla 3. 30. Tarjeta CRC - Tratamiento ............................................................................................ 57 
Tabla 3. 31. Tarjeta CRC – Tratamiento Fármaco ............................................................................ 57 
Tabla 3. 32. Tarjeta CRC – Autorización .......................................................................................... 57 
Tabla 3. 33. Tarjeta CRC – Proveedor .............................................................................................. 58 
Tabla 3. 34. Tarjeta CRC – Fármaco ................................................................................................58 
Tabla 3. 35. Tarjeta CRC – Categoría ............................................................................................... 58 
Tabla 3. 36. Especificación de herramientas de desarrollo ............................................................... 70 
Tabla 3. 37. Prueba de estrés mediante ApacheBench ...................................................................... 80 
 
CALIDAD Y SEGURIDAD 
Tabla 4. 1. WebSite QEM: Evaluación de comprensibilidad ............................................................ 82 
Tabla 4. 2. WebSite QEM: Evaluación de mecanismos de ayuda y retroalimentación .................... 83 
Tabla 4. 3. WebSite QEM: Evaluación de aspectos de interfaces y estéticos. .................................. 84 
Tabla 4. 4. WebSite QEM: Evaluación de misceláneas .................................................................... 84 
Tabla 4. 5. WebSite QEM: Evaluación total de usabilidad ............................................................... 85 
Tabla 4. 6. WebSite QEM: Evaluación de aspectos búsqueda y recuperación ................................. 85 
Tabla 4. 7. WebSite QEM: Evaluación de aspectos de navegación y exploración. .......................... 86 
Tabla 4. 8. WebSite QEM: Evaluación de aspectos del dominio orientados al usuario. .................. 86 
Tabla 4. 9. WebSite QEM: Evaluación total de funcionalidad ......................................................... 87 
Tabla 4. 10. WebSite QEM: Evaluación de confiabilidad ................................................................ 87 
Tabla 4. 11. WebSite QEM: Evaluación de performancia ................................................................ 88 
Tabla 4. 12. WebSite QEM: Evaluación de accesibilidad ................................................................ 88 
Tabla 4. 13. WebSite QEM: Evaluación total de eficiencia .............................................................. 89 
Tabla 4. 14. WebSite QEM: Evaluación de calidad total .................................................................. 89 
Tabla 4. 15. WebSite QEM: Elementos de seguridad en la aplicación ............................................. 90 
 
EVALUACIÓN COSTO BENEFICIO 
Tabla 5. 1. Sectorización de aplicaciones en COCOMO II ............................................................... 92 
Tabla 5. 2. Tabla del tamaño del módulo en puntos función ............................................................ 95 
Tabla 5. 3. Tabla estimación de costos USC COCOMO II ............................................................... 96 
Tabla 5. 4. Tabla de resultados USC COCOMO II ........................................................................... 96 
Tabla 5. 5. Costo de elaboración del proyecto .................................................................................. 97 
Tabla 5. 6. Costo total del proyecto .................................................................................................. 97 
Tabla 5. 7: Tabla de interpretación VAN .......................................................................................... 98 
Tabla 5. 8: Tabla VAN-TIR .............................................................................................................. 99 
 
 
 
ÍNDICE DE FIGURAS: 
MARCO TEÓRICO 
Figura 2. 1. Diagrama de estructura .................................................................................................. 15 
Figura 2. 2. Notación grafica WebML para Unidades de datos ........................................................ 16 
Figura 2. 3. Notación grafica WebML para Unidades de multidatos ................................................ 16 
Figura 2. 4. Notación grafica WebML para Unidades índice............................................................ 17 
Figura 2. 5. Notación grafica WebML para Unidad scroller ............................................................. 17 
Figura 2. 6. Notación grafica WebML para Unidad filtro ................................................................. 17 
Figura 2. 7. Notación grafica WebML para Unidad directiva ........................................................... 18 
Figura 2. 8. Lógica clínica ................................................................................................................. 25 
Figura 2. 9. Metodología del diagnóstico .......................................................................................... 26 
Figura 2. 10. Fases del diagnóstico ................................................................................................... 29 
Figura 2. 11. Elementos a evaluar para el pronóstico ....................................................................... 30 
Figura 2. 12. Fases del diagnóstico ................................................................................................... 31 
 
MARCO APLICATIVO 
Figura 3. 1. Clasificación de roles del sistema .................................................................................. 40 
Figura 3. 2. Plan de entregas ............................................................................................................. 54 
Figura 3. 3. Modelo de Estructura mostrando sus entidades y sus Relaciones ................................. 59 
Figura 3. 4. Modelo de composición – Página de inicio ................................................................... 60 
Figura 3. 5. Modelo de composición – Listado de propietarios ........................................................ 60 
Figura 3. 6. Modelo de composición – Información del propietario ................................................. 61 
Figura 3. 7. Modelo de composición – Registro de la mascota ......................................................... 61 
Figura 3. 8. Modelo de composición – Registro de la mascota y propietario ................................... 61 
Figura 3. 9. Modelo de composición – Información general de la mascota ..................................... 62 
Figura 3. 10. Modelo de composición – Listado de proveedores ...................................................... 62 
Figura 3. 11. Modelo de composición – ingreso de medicamentos .................................................. 63 
Figura 3. 12. Modelo de composición - Listado de historiales clínicos ............................................ 63 
Figura 3. 13. Modelo de composición - Registro historial clínico .................................................... 64 
Figura 3. 14. Modelo de composición – Listado de vacunas ............................................................ 65 
Figura 3. 15. Modelo de composición - Registro de vacunas .......................................................... 65 
Figura 3. 16. Modelo de composición – Listado de Autorizaciones ................................................. 65 
Figura 3. 17. Modelo de composición – Registro de autorizaciones................................................. 66 
Figura 3. 18. Modelo de composición – Reporte de ingresos de insumos médicos .......................... 66 
Figura 3. 19. Modelo de composición – Reporte de ingresos de atenciones clínicas ....................... 66 
Figura 3. 20. Diagrama de navegación – Tratamiento clínico de mascotas ...................................... 67 
Figura 3. 21. Diagrama de navegación – Registro de vacunas .......................................................... 67 
Figura 3. 22. Diagrama de navegación – Registro de autorización de cirugía .................................. 68 
Figura 3. 23. Diagrama de navegación – Proceso de adopción albergue .......................................... 68 
Figura 3. 24. Diagrama de navegación – Registro de mascotas en la veterinaria ............................. 69 
 
Figura 3. 25. Diagrama de navegación – Registro de insumos médicos ........................................... 69 
Figura 3. 26. Pantalla – Ingreso al sistema ........................................................................................ 71 
Figura 3. 27. Pantalla – Página de inicio........................................................................................... 71 
Figura 3. 28. Pantalla – Diseño adaptable de la aplicación ............................................................... 72 
Figura 3. 29. Pantalla – Listado de propietarios ................................................................................ 72 
Figura 3. 30. Pantalla – Información del propietario ........................................................................ 73 
Figura 3. 31. Pantalla – Información de la mascota .......................................................................... 73 
Figura 3. 32. Pantalla – Listado de proveedores ............................................................................... 74 
Figura 3. 33. Pantalla – Ingreso de insumos médicos ....................................................................... 74 
Figura 3. 34. Pantalla – Diagnostico de la mascota ........................................................................... 75 
Figura 3. 35. Pantalla – Seguimiento clínico de la mascota .............................................................. 75 
Figura 3. 36. Pantalla – Reporte historial clínico de la mascota ....................................................... 76 
Figura 3. 37. Pantalla - Autorización certificado de cirugía............................................................. 76 
Figura 3. 38. Pantalla – Mascotas en el albergue .............................................................................. 77 
Figura 3. 39. Pantalla – Auditoria de ingresos .................................................................................. 77 
Figura 3. 40. Pantalla – Georeferenciación de los propietarios ......................................................... 78 
Figura 3. 41. Pantalla – Enfermedades atendidas por año ................................................................. 78 
Figura 3. 42. Plugin de Junit para jIdea ............................................................................................. 79 
Figura 3. 43. Prueba Junit aplicada al sistema .................................................................................. 79 
 
 ANÁLISIS DE COSTOS 
Figura 5. 1. Interface de USC COCOMO II...................................................................................... 94 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Capítulo I 
MARCO INTRODUCTORIO 
 
 
 
CAPÍTULO I 
MARCO PRELIMINAR 
 
Hoy en día los sistemas informáticos se han convertido en un factor importante en la vida de las 
personas, los campos de aplicación varían en diferentes rubros como la investigación, 
educación, el comercio y la medicina entre otras, facilitando muchas tareas mejorando el 
desempeño del trabajo que realizan los individuos en la sociedad. 
Debido a la cantidad de información que se maneja, las organizaciones dependen hoy más que 
nunca de herramientas para el procesamiento de datos y toma de decisiones pues permiten tener 
un control efectivo de las actividades, un almacenamiento ordenado de la información, claridad 
en los procesos, confidencialidad y seguridad en los datos. Los sistemas informáticos también 
ponen a su disposición mayor y mejor información, permiten comparar resultados alcanzados, 
proporcionan ventajas competitivas y valor agregado1 (Suares, 2015). 
Animales S.O.S. es una organización sin fines de lucro que en la actualidad cuenta con una gran 
cantidad de operaciones que se realizan por día (Anexo 4), concentrándose de esta manera un 
gran volumen de documentos e ítems, para lo cual se vieron con la necesidad de centralizar toda 
la información para su mejor uso y distribución. En nuestro caso se propone el desarrollo de un 
sistema para la desmaterialización de documentos, tomando en cuenta la implementación de una 
plataforma web. 
El tratamiento de la información es importante para cualquier institución, la historia clínica2 es 
un documento válido desde el punto de vista clínico y legal, que recoge información de tipo 
asistencial, preventivo y social de los pacientes (GERVAS, 2015) imprescindible para el 
desarrollo de las funciones profesionales en los centros médicos, incorporando datos de sus 
 
1 El valor agregado es el valor económico adicional que adquieren los bienes y servicios al ser transformados 
durante el proceso productivo 
2 La historia clínica es un documento médico-legal que surge del contacto entre el profesional de la salud y el 
paciente donde se recoge la información necesaria para la correcta atención de los pacientes. 
 
2 
 
antecedentes personales y familiares, sus hábitos y todo aquello vinculado con su salud, 
asimismo incluye el proceso evolutivo, tratamiento y recuperación. 
El proyecto de grado pretende automatizar los procesos del registro de información en los 
historiales clínicos, para facilitar el uso de la información, y mejorar el desempeño de las tareas, 
proporcionando información de mayor valor que la hecha a mano, aportando datos íntegros, 
ordenados, centralizados, claros, rápidos y seguros permitiendo el seguimiento y control de 
medicamentos e insumos, reduciendo el tiempo invertido en el proceso del manejo de 
información de las mascotas y así dar solución a los problemas que se suscitan, dando 
cumplimiento a los requerimientos de la institución. 
1.1. Antecedentes institucionales 
Animales S.O.S. es una entidad sin fines de lucro fundada en 1995, con la finalidad de velar por 
el bienestar de los animales. Establecida legalmente en Bolivia mediante Resolución Prefectural 
N° 831 de fecha 6 de Diciembre de 1996, la cual resuelve: “Reconocer la Personería Jurídica de 
la Asociación Animales S.O.S.” (Animales S.O.S., 2015) 
Conforma su directiva nacional anualmente, todos estos cargos son ocupados por personas 
sobresalientes y constantes en su trabajo por los animales, ellos son elegidos en Asamblea 
General y no reciben ningún tipo de remuneración económica, también cuenta con un pequeño 
plantel asalariado y varios voluntarios, quienes distribuyen su tiempo libre para colaborar en las 
actividades cotidianas de socorro y ayuda destinada a los animales. (Animales S.O.S., 2015) 
Tiene como visión lograr el bienestar de los animales en general, mediante la acción, educación, 
la creación y el cumplimiento de las leyes (Animales S.O.S., 2015) y como objetivo general, 
brindar atención médica a las mascotas, velando por su bienestar asegurando que el servicio sea 
efectivo. (Animales S.O.S., 2015) 
Sus funciones se agrupan en funciones administrativas, que engloban actividades de todo el 
proceso de organización, dirección, interacción, control y evaluación de actividades, y funciones 
técnicas con las actividades de atención, y consulta de las mascotas. (Animales S.O.S., 2015). 
 
3 
 
El 16 de julio de 2000 en Sesión de Honor del Concejo Municipal de la Ciudad de La Paz se le 
otorgó la distinción Prócer Pedro Domingo Murillo en el grado de Honor Cívico, esta distinción 
se otorga anualmente a personalidades e instituciones sobresalientes por su trabajo y aporte a la 
ciudad de La Paz. (Animales S.O.S., 2015) 
1.1.1. Proyectos 
Actualmente cuenta con una página web en la cual se encuentra información de las actividades, 
la atención veterinaria, su personal administrativo, campañas de adopción, actividades de ayuda, 
visión, logros, normas, contactos, referencias y donaciones. (Animales S.O.S., 2015) 
1.2. Antecedentes proyectos similares 
Existen proyectos en la carrera de Informática de la Universidad Mayor de San Andrés 
relacionados con el uso de historiales clínicos en instituciones médicas y manejo de inventarios 
como ser: 
 Sistema de control de inventario y manejo de historiales clínicos para el centro de salud 
18 de Mayo (Quisbert, 2011), permite manipular historiales clínicos y determina la 
salida de medicamentos de la institución, basado en el ProcesoUnificado de desarrollo 
de software RUP. 
 Sistema de Administración y Control de Historiales Clínicos para los Consultorios 
Clínicos de la UMSA (Lozano, 2014), el cual gestiona, controla y administra historiales 
clínicos basado en la metodología de desarrollo OOHDM 
 Sistema de información de seguimiento y control de historiales clínicos del consultorio 
psicológico del CEMSE (Chipana, 2013), basado en el Lenguaje Unificado de Modelado 
UML 
 Sistema de administración de historiales clínicos, Clínica Sanjinés, facilita las tareas de 
seguimiento y control de los pacientes (Machicao, 2009), basado en el Lenguaje 
Unificado de Modelado UML 
 Historial clínico Hogar de Ciudad del Niño Jesús, controla el tratamiento de la 
información de los historiales clínicos de los pacientes y sus padres (Fernandez, 2005) 
 
4 
 
 Sistema de control de ventas e inventarios para la red de farmacias “Virgen del Carmen” 
(Colque, 2009), gestiona el control de inventarios de la red de farmacias, basado en el 
Proceso Unificado de Desarrollo RUP 
 Sistema de control automatizado de inventarios de insumos médicos y farmacia. 
(Mamani, 2013), gestionan el manejo de inventarios mediante el sistema web 
informático, desarrollado bajo la metodología ágil de desarrollo de software XP 
 Sistema de información automatizado de almacenes y farmacia. Caso: Centro de Salud 
Materno Infantil Villa Nueva Potosí (Mendoza, 2008) 
 Sistema de Información de inventarios para Laboratorios ALCOS S.A. (Blanco, 2013), 
gestiona el manejo de inventarios de los laboratorios mediante la ISO 9126 
 Control de ventas e inventario para el monitoreo de pedidos – caso: Empresa 
distribuidora V.M.C.C. (Cruz, 2013), permite determinar el ingreso y egreso de 
productos en la empresa V.M.C.C. 
Existe una gran variedad de sistemas dedicados al manejo de historiales clínicos en instituciones 
médicas, diferenciándose por las necesidades específicas de las operaciones y manipulación de 
datos. (Mendoza, 2008) 
1.3. Planteamiento del problema 
Animales S.O.S. cuenta con un alberque, en el cual se acogen a diferentes tipos de animales, 
maltratados, abandonados, lesionados y/o enfermos, muchos de ellos son rehabilitados y dados 
en adopción, frecuentemente asume los gastos de los tratamientos, de los medicamentos e 
insumos médicos utilizados, para los cuales no se tiene un seguimiento. Asimismo al ser una 
entidad sin fines de lucro que depende de las donaciones, a menudo aparece en los medios de 
comunicación, en los cuales muestra estadísticas de las atenciones médicas veterinarias 
realizadas, campañas móviles de vacunación y rehabilitación de animales. 
Un problema en la atención veterinaria, es que los propietarios después de realizar la consulta 
para su mascota y recibir el diagnostico, abandonan el tratamiento descontinuando las visitas 
 
5 
 
programadas provocando el deterioro de salud de la mascota e incluso la muerte por descuido y 
falta de seguimiento. 
Debido a la cantidad de consultas médicas veterinarias que se realizan en Animales S.O.S. se 
identificaron problemas en los procesos manuales de registro de información para el archivo de 
datos, como perdida de historiales clínicos, fallas humanas en el almacenamiento y transcripción 
de la información, incluso falta de medidas de salvaguarda. 
Si bien, los procedimientos y técnicas están ya establecidos para los diferentes procesos de 
atención médica veterinaria, actualmente no posee instrumentos específicos que refuercen esta 
actividad por los administradores, médicos veterinarios y colaboradores. 
1.3.1 Problema central 
Teniendo en cuenta estos antecedentes ahora se plantea el siguiente problema ¿De qué manera 
se lleva un control y seguimiento de los antecedentes clínicos de las mascotas asistidas por 
Animales S.O.S.? 
1.3.2. Problemas secundarios 
 Datos de los propietarios y mascotas llenados manualmente, generando duplicidad de 
datos. 
 Ya que no se cuenta con una organización estructurada de los archivos de historiales 
clínicos, se pierden algunos de estos documentos. 
 Abandono de tratamientos clínicos por falta de seguimiento. 
 Posibles errores en el registro de conteo de existencias de insumos médicos. 
 No se genera información histórica para los tratamientos de animales adoptados del 
albergue. 
 Existe demora en el proceso semiautomático de generación de informes periódicos y 
reportes para la difusión de datos en los medios de comunicación. 
 
6 
 
1.4. Objetivos 
1.4.1. Objetivo general 
Desarrollar e implementar un sistema web de historiales clínicos, basado en la metodología ágil 
de desarrollo de software XP, que permita realizar el seguimiento y control de los antecedentes 
clínicos de Animales S.O.S. 
1.4.2. Objetivos específicos 
 Aplicar durante la fase de ejecución del proyecto, la metodología ágil de desarrollo de 
software XP, mediante las etapas de planificación, diseño, codificación y pruebas. 
 Almacenar la información de las mascotas y propietarios en el módulo de matriculación. 
 Organizar la información clínica de las mascotas en el módulo de atención clínica 
veterinaria. 
 Georeferenciar las direcciones aproximadas de los propietarios mediante parámetros de 
localización en el módulo de administración y parametrizacion. 
 Implementar el registro físico valorado de existencias de insumos médicos en el módulo 
de inventarios. 
 Recopilar información sobre los tratamientos y datos de rehabilitación de los animales 
adoptados del albergue. 
 Emisión automatizada de informes periódicos de los historiales clínicos de las mascotas, 
vacunas, propietarios y animales rehabilitados en el módulo de reportes, de una manera 
precisa y amigable para la toma de decisiones y la difusión en los medios de 
comunicación. 
 Emplear tecnologías que utilicen la filosofía de diseño y desarrollo Responsive Web 
Design (RWD)3 
 
3 El diseño web adaptable o adaptativo, es una filosofía de diseño y desarrollo cuyo objetivo es adaptar la 
apariencia de las páginas web al dispositivo que se esté utilizando para visualizarla 
 
7 
 
1.5. Justificación 
1.5.1. Justificación económica 
Desde el punto de vista económico.- Una empresa bien gestionada debe tener analizados sus 
gastos de forma muy detallada y, entender y controlar no sólo cómo estos impactan en su 
negocio, sino cómo se desarrollan con los cambios, para lo cual el sistema generará información 
adicional sobre los gastos realizados en los tratamientos, y complementará la información de las 
compras de insumos médicos y vacunas, lo cual permitirá tener un control más preciso sobre el 
estado económico de Animales S.O.S. 
1.5.2. Justificación social 
Desde el punto de vista social.- Animales S.O.S. es una entidad sin fines de lucro que depende 
de las donaciones y atenciones que realiza, aparece constantemente en los medios de 
comunicación presentando datos de las actividades que realiza, informando sobre los 
tratamientos, gastos realizados, animales rehabilitados y otros. 
El sistema web proporcionará información actualizada sobre las actividades descritas a quienes 
representen a Animales S.O.S. en los medios de comunicación, mediante informes, reportes y 
estadísticas. 
1.5.3. Justificación tecnológica 
Desde el punto de vista tecnológico.- La necesidad creciente de mejorar la calidad de los 
servicios y operaciones está relacionada con el manejo de la información que por medio de 
sistemas informáticos es mejor administrada pues proporciona datos más útiles, automatizando 
los procesos, generando reportes y estadísticas. En este caso se administrarán los historiales 
clínicos con los últimos frameworks4, orientados a la interacción con el usuario e integridad de 
los datos. 
 
4 Framework es una estructura conceptual y tecnológica de soporte definido, normalmentecon artefactos o 
módulos de software concretos, que puede servir de base para la organización y desarrollo de software. 
 
8 
 
1.6. Alcances y límites 
1.6.1. Alcances 
El sistema gestionará los procesos y procedimientos que intervengan en la generación de 
información para los historiales clínicos realizados en la clínica veterinaria de Animales S.O.S., 
como ser el registro, control y seguimiento de: 
 Propietarios. 
 Mascotas. 
 Tratamientos 
 Vacunas 
 Cirugías 
 Insumos médicos. 
Los contenidos estarán disponibles para doctores veterinarios, administrativos, auxiliares y 
propietarios. 
1.6.2. Límites 
 No se tomarán en cuenta procesos y procedimientos de facturación. 
 No se realizará una migración de los historiales clínicos de mascotas fallecidas. 
1.7. Aportes 
Animales S.O.S. se actualizará con el avance tecnológico en el campo de la informática, 
logrando almacenar una gran cantidad de información que estará disponible para la adecuada 
toma de decisiones, organizando la información de los propietarios y proporcionando datos 
sobre los antecedentes clínicos de las mascotas además de su estado evolutivo. 
El actual proyecto provee un instrumento de refuerzo en las actividades de atención clínica de 
las mascotas para los doctores veterinarios, hojas de control de tratamientos a los propietarios, 
un registro de gastos en insumos médicos para los administrativos y reportes sobre actividades 
de la veterinaria a los representantes de Animales S.O.S. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Capítulo II 
MARCO TEÓRICO 
 
 
9 
 
CAPÍTULO II 
MARCO TEÓRICO 
 
2.1. Metodología ágil de desarrollo de software XP 
Una metodología de desarrollo de software se refiere a un marco de trabajo que es usado para 
estructurar, planear y controlar el proceso de desarrollo en sistemas de información. Esta 
metodología es a menudo documentada en algún tipo de documentación formal. Las 
metodologías han evolucionado de manera significativa en las últimas décadas permitiendo así 
el éxito de muchos de los sistemas desarrollados para distintas áreas. (eumed.net, 2014) 
Las metodologías agiles son una serie de técnicas para la gestión de proyectos que han surgido 
como contraposición a los métodos clásicos de gestión. Aunque surgieron en el ámbito del 
desarrollo de software, también han sido exportadas a otro tipo de proyectos. (leanmonitor, 
2005) 
Todas las metodologías que se consideran ágiles cumplen con el manifiesto ágil que es una serie 
de principios que se agrupan en 4 valores: (Beck, 2001) 
 Los individuos y su interacción, por encima de los procesos y las herramientas. 
 El software que funciona, frente a la documentación exhaustiva. 
 La colaboración con el cliente, por encima de la negociación contractual. 
 La respuesta al cambio, por encima del seguimiento de un plan. 
Las metodologías agiles pretenden minimizar el impacto de las tareas que no son totalmente 
imprescindibles para conseguir el objetivo del proyecto, pretenden aumentar la eficiencia de las 
personas involucradas en el proyecto y, como resultado de ello, minimizar el coste. (Beck, 
2001). 
La programación extrema o Xtreme Programming (XP) es una metodología ágil de desarrollo 
de software propuesta en 1999 por Kent Beck, considera que los cambios de requisitos durante 
la elaboración del proyecto son algo natural, deben ser aceptados y tomados como cambios 
 
10 
 
deseables (extremeprogramming.org, 2015). XP como metodología tiene la premisa de que un 
proyecto de software debe adaptarse al cambio, cualquiera sea el estado/fase, en vez de 
esforzarse por conseguir todos los requisitos al principio y tratar de congelar estos una vez el 
proyecto esté en marcha. 
XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, la comunicación 
fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para 
enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos 
imprecisos y muy cambiantes, y donde existe un alto riesgo técnico. (Universidad Union 
Bolivariana, 2015). 
2.1.1. Roles 
Son las funciones o papeles que cumplen todos los participantes en el desarrollo del software, 
XP presenta los siguientes roles 
 Programador: escribe las pruebas unitarias y produce el código del sistema. 
 Cliente: escribe las historias de usuario y las pruebas funcionales para validar su 
implementación. Asigna la prioridad a las historias de usuario y decide cuáles se 
implementan en cada iteración centrándose en aportar el mayor valor de negocio. 
 Tester: ayuda al cliente a escribir las pruebas funcionales. Ejecuta pruebas regularmente, 
difunde los resultados en el equipo y es responsable de las herramientas de soporte. 
 Tracker: es el encargado de seguimiento. Proporciona realimentación al equipo. Debe 
verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, 
comunicando los resultados para mejorar futuras estimaciones. 
 Entrenador (coach): Responsable del proceso global. Guía a los miembros del equipo 
para seguir el proceso correctamente. 
 Consultor: Es un miembro externo del equipo con un conocimiento específico en algún 
tema necesario para el proyecto. Ayuda al equipo a resolver un problema específico. 
 Gestor (Big boss): Es el dueño de la tienda y el vínculo entre clientes y programadores. 
Su labor esencial es la coordinación. 
 
11 
 
2.1.2 Fases XP 
Son las fases o pasos comunes, que deben seguir todos los programadores para el desarrollo de 
la aplicación. 
A) Planificación del Proyecto: en esta fase se investiga el problema que se quiere resolver o el 
sistema que se desea crear, mediante: 
 Historias de usuario: las historias de usuario constan de 3 o 4 líneas escritas por el cliente 
en un lenguaje no técnico sin hacer mucho hincapié en los detalles: no se debe hablar de 
posibles algoritmos para su implementación ni de diseños de base de datos adecuaros, 
son usadas para estimar tiempos de desarrollo de la parte de aplicación que describen. 
(Valverde, 2013) 
También se utilizan en la fase de pruebas para verificar si el programa cumple con lo 
que se especifica en la historia de usuario, el cliente y los desarrolladores se reúnen para 
concretar y detallar lo que tiene que hacer dicha historia. El tiempo ideal para el 
desarrollo de una historia de usuario es entre 1 y 3 semanas (Quijano, 2012). 
 Plan de entregas (Release planning): después de tener ya definidas las historias de 
usuario es necesario crear un plan de publicaciones, en base a las tareas identificadas, 
donde se indiquen las historias de usuario que se crearan para cada versión del programa 
y las fechas en las que se publicaran estas versiones. (Valverde, 2013) 
 Iteraciones: el proyecto se ha de dividir en iteraciones de aproximadamente 3 semanas 
de duración. Al comienzo de cada iteración los clientes deben seleccionar las historias 
de usuario definidas en el "Release planning" que serán implementadas. También se 
seleccionan las historias de usuario que no pasaron el test de aceptación que se realizó 
al terminar la iteración anterior. Estas historias de usuario son divididas en tareas de 
entre 1 y 3 días de duración que se asignarán a los programadores. (Tripod, 2015) 
 Velocidad del proyecto: es una medida que representa la rapidez con la que se desarrolla 
el proyecto; para estimarla basta con contar el número de historias de usuario que se 
pueden implementar en una iteración; de esta forma, se sabrá el cupo de historias que se 
pueden desarrollar en las distintas iteraciones. (Valverde, 2013) 
 
12 
 
 Programación en pareja: la metodología X.P. aconseja la programación en parejas. El 
trabajo en pareja involucra a dos programadores trabajando en el mismo equipo; 
mientras uno codifica haciendo hincapié en la calidad de la función o método queestá 
implementando, el otro analiza si ese método o función es adecuado y está bien diseñado. 
(Tripod, 2015) 
 Reuniones diarias: es necesario que los desarrolladores se reúnan diariamente y 
expongan sus problemas, soluciones e ideas de forma conjunta. (Tripod, 2015) 
B) Diseño: en esta fase se utiliza la información recolectada en la etapa de planificación para 
crear modelos, mediante: 
 Diseños simples: la metodología X.P sugiere que hay que conseguir diseños simples y 
sencillos. Hay que procurar hacerlo todo lo menos complicado posible para conseguir 
un diseño fácilmente entendible e impleméntable que a la larga costará menos tiempo y 
esfuerzo desarrollar. 
 Riesgos: si surgen problemas potenciales durante el diseño, X.P sugiere utilizar una 
pareja de desarrolladores para que investiguen y reduzcan al máximo el riesgo que 
supone ese problema. 
 Funcionalidad extra: nunca se debe añadir funcionalidad extra al programa aunque se 
piense que en un futuro será utilizada. 
 Tarjetas CRC: la utilización de tarjetas CRC (Class-Responsibility-Collaboration) es 
una técnica de diseño orientado a objetos propuesta por Kent Beck (introductor de la 
metodología de programación extrema) y Ward Cunningham. El objetivo de la misma 
es hacer, mediante tarjetas, un inventario de las clases que vamos a necesitar para 
implementar el sistema y la forma en que van a interactuar, de esta forma se pretende 
facilitar el análisis y discusión de las mismas por parte de varios actores del equipo de 
proyecto con el objeto de que el diseño sea lo más simple posible verificando las 
especificaciones del sistema. (JUMP, 2015). 
Estas tarjetas se dividen en tres secciones que contienen la información del nombre de 
la clase, sus responsabilidades y sus colaboradores. A continuación se muestra cómo se 
 
13 
 
distribuye esta información. Una clase es cualquier persona, cosa, evento, concepto, 
pantalla o reporte. Las responsabilidades de una clase son las cosas que conoce y las que 
realizan, sus atributos y métodos. Los colaboradores de una clase son las demás clases 
con las que trabaja en conjunto para llevar a cabo sus responsabilidades. 
C) Codificación: en esta fase se utilizan los modelos creados durante la etapa de diseño para 
crear componentes del sistema, mediante: 
 Programación por pares: requiere que dos programadores participen en un esfuerzo 
combinado de desarrollo en un sitio de trabajo. Mientras que uno codifica las pruebas de 
unidades el otro piensa en la clase que satisfará la prueba. 
 Refactorizar: es mejorar y modificar la estructura y codificación de códigos ya creados 
sin alterar su funcionalidad, supone revisar de nuevo estos códigos para procurar 
optimizar su funcionamiento. Es muy común rehusar códigos ya creados que contienen 
funcionalidades que no serán usadas y diseños obsoletos. Esto es un error porque puede 
generar código completamente inestable y muy mal diseñado; por este motivo, es 
necesario refactorizar cuando se va a utilizar código ya creado. 
 Integración continua: consiste en hacer integraciones automáticas de un proyecto lo más 
a menudo posible para así poder detectar fallos cuanto antes 
D) Pruebas: uno de los pilares de la metodología X.P es el uso de test para comprobar el 
funcionamiento de los códigos que vayamos implementando. En esta fase se asegura que los 
componentes individuales que integran al sistema o producto, cumplen con los requerimientos 
de la especificación creada durante la etapa de diseño, mediante: 
 Pruebas unitarias 
 Pruebas de caja negra 
 Pruebas de caja blanca 
 Pruebas de integración 
 
14 
 
2.2. WebML 
Con la introducción del Internet y de la Web en concreto, se han abierto infinidad de 
posibilidades en cuanto al acceso y uso de información desde cualquier parte del mundo. Con 
los avances en tecnología, cada vez se demandan aplicaciones rápidas, ligeras y robustas que 
permitan ser usadas sin importar ni el lugar, ni el horario. Las aplicaciones Web tienen varias 
ventajas sobre los programas de software tradicionales, como la compatibilidad multiplataforma 
y el acceso concurrente de múltiples usuarios. WebML es un lenguaje de especificación de alto 
nivel, para diseñar aplicaciones Web que usan datos intensivos, que además cubre aspectos 
avanzados de modelado de sitios Web, incluyendo presentación, modelado de usuarios y 
personalización. (Universidad Nacional de Colombia, 2015) 
Es un lenguaje de modelado gráfico utilizado para apoyar las actividades del diseño de sitios 
Web. Provee gráficos, formalismos, especificaciones y diseño de procesos apoyados por 
herramientas gráficas. Define varios tipos de diagramas: de estructura, composición y 
navegación. (Universidad Nacional de Colombia, 2015), provee especificaciones graficas 
involucradas en un completo diseño de los procesos, las cuales son asistidas por herramientas 
visuales de diseño. (Valverde, 2013) 
WebML combina técnicas de modelado entidad relación con UML, se basa en la distribución 
de nodos en los niveles del hipertexto sobre las páginas del nivel de presentación (Universidad 
de Cali, 2015) 
2.2.1. Diagrama de estructura 
En el diagrama de estructura se definen las entidades o contenedores de datos y sus relaciones, 
este diagrama expresa el contenido de un sitio Web en términos de entidades y relaciones 
relevantes. (Universidad Nacional de Colombia, 2015) 
El elemento fundamental del modelo de estructura son las entidades (contenedores de datos) y 
las relaciones (conectores de entidades), las entidades deben tener atributos con un tipo asociado 
 
15 
 
y las relaciones deben tener una cardinalidad5 y un rol asociado. En la Figura 2.1 se muestra un 
ejemplo de un diagrama de estructura, el cual consiste de cuatro entidades y tres relaciones. 
 
Figura 2. 1. Diagrama de estructura 
Fuente: Elaboración propia 
 
El modelo de estructura es compatible con el Modelo Entidad-Relación y con el Diagrama de 
clases UML. Este modelo está formado por los siguientes elementos: 
A) Entidades: son las estructuras básicas del modelo de estructura WebML. Cada entidad se 
asocia a un conjunto de objetos del mundo real cuyas propiedades se describen por atributos. 
Se denotan por un rectángulo con el nombre de la entidad en el tope seguido de una lista de 
atributos (Valverde, 2013) 
B) Atributos: en el modelo de WebML se utilizan los atributos para representar las propiedades 
del mundo real, y que se manejan en el sitio web. Un atributo tiene un tipo, escogido por el 
desarrollador al momento de definir los tipos de WebML. (Valverde, 2013) 
C) Relaciones: las relaciones representan las conexiones semánticas entre las entidades. La 
relación más simple es binaria, a través de la cual se conectan dos entidades. 
Las relaciones que envuelven más de dos entidades son llamadas relaciones n-arias y también 
son soportadas por WebML. (Valverde, 2013) 
 
5 Dado un conjunto de relaciones en el que participan dos o más conjuntos de entidades, la correspondencia de 
cardinalidad indica el número de entidades con las que puede estar relacionada una entidad dada 
 
16 
 
2.2.2. Diagrama de composición 
El propósito del diagrama de composición es definir los nodos que forman parte del hipertexto 
contenido en el sitio Web, es decir, se especifican las páginas y las unidades (elementos 
atómicos de información que deben aparecer en el sitio Web) que componen el sitio Web. 
(Universidad Nacional de Colombia, 2015) 
WebML soporta seis tipos de unidades que son usadas para componer hipertexto: 
A) Unidades de Datos: muestran información sobre un solo objeto, son definidas para 
seleccionar una mezcla de información. Para definir una unidad de datos (figura 2.2.) se requiere 
la indicación del concepto al cual se refiere la unidad y la selección de los atributos de la unidad. 
(Universidad Nacional de Colombia,2015) 
 
Figura 2. 2. Notación grafica WebML para Unidades de datos 
Fuente: Elaboración propia 
B) Unidad Multidatos: muestra información sobre un conjunto de objetos, presenta múltiples 
instancias de una entidad o componente. Una unidad multidatos (figura 2.3) tiene dos partes: el 
contenedor que incluye las instancias que se desean mostrar y la unidad de datos usada para la 
presentación de cada instancia. (Universidad Nacional de Colombia, 2015) 
 
Figura 2. 3. Notación grafica WebML para Unidades de multidatos 
Fuente: Elaboración propia 
 
17 
 
C) Unidad Índice: presenta múltiples instancias de una unidad o componente como una lista, 
esta unidad (figura 2.4) tiene dos partes principales: el contenedor que incluye las instancias que 
se desean mostrar (las instancias deben ser una entidad, una relación o un componente) y los 
atributos usados como clave del índice. (Universidad Nacional de Colombia, 2015) 
 
Figura 2. 4. Notación grafica WebML para Unidades índice 
Fuente: Elaboración propia 
D) Unidad Scroller: provee comandos para desplazarse a través de los objetos en un contenedor. 
Esta unidad (figura 2.5) es normalmente usada junto con una unidad de datos, la cual representa 
el elemento actual visualizado del contenedor. 
 
Figura 2. 5. Notación grafica WebML para Unidad scroller 
Fuente: Elaboración propia 
E) Unidad Filtro: provee campos de entrada para buscar los objetos en un contenedor, esta 
unidad (figura 2.6) es normalmente usada junto con una unidad índice o multidatos, la cual 
muestra los objetos que coinciden con las condiciones de búsqueda. 
 
Figura 2. 6. Notación grafica WebML para Unidad filtro 
Fuente: Elaboración propia 
 
18 
 
F) Unidad Directa: expresa un tipo particular de índice (figura 2.7.), el cual contiene un solo 
objeto asociado a otro objeto por una relación uno a uno. (Universidad Nacional de Colombia, 
2015) 
 
Figura 2. 7. Notación grafica WebML para Unidad directiva 
Fuente: Elaboración propia 
Una página es una abstracción de una región independiente de la pantalla, la cual es tratada 
como un bloque de interfaz independiente. Las páginas deben ser internamente organizadas en 
unidades y/o recursivamente en páginas, para este último las subpáginas de la página 
contenedora son tratadas como bloques de presentación independientes, hay dos formas de 
visualizar las subpáginas: conjuntas (se muestran las subpáginas al mismo tiempo) o disjuntas 
(unas páginas se muestran como alternativas de otras). 
2.2.3. Diagramas de navegación 
El propósito del diagrama de navegación es especificar la forma en la cual las unidades y las 
páginas son conectadas para formar un hipertexto, para esto WebML provee la noción de 
enlaces, de los cuales hay dos tipos: 
2.3. El patrón MVC 
La arquitectura de software es un conjunto de patrones que proporcionan un marco de referencia 
necesario para guiar la construcción de un software, permitiendo a los programadores, analistas 
y todo el conjunto de desarrolladores del software compartir una misma línea de trabajo y cubrir 
todos los objetivos y restricciones de la aplicación. Es considerada el nivel más alto en el diseño 
de la arquitectura de un sistema puesto que establecen la estructura, funcionamiento e 
interacción entre las partes del software. (Ecured, 2015) 
La arquitectura de software forma la columna vertebral para construir un sistema de software, 
es en gran medida responsable de permitir o no ciertos atributos de calidad del sistema entre los 
 
19 
 
que se destacan la confiabilidad y el rendimiento del software. Además es un modelo abstracto 
reutilizable que puede transferirse de un sistema a otro y que representa un medio de 
comunicación y discusión entre participantes del proyecto, permitiendo así la interacción e 
intercambio entre los desarrolladores con el objetivo final de establecer el intercambio de 
conocimientos y puntos de vista entre ellos. (Ecured, 2015) 
Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que separa los datos 
de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. El 
patrón de llamada y retorno MVC, se ve frecuentemente en aplicaciones web, donde la vista es 
la página HTML y el código que provee de datos dinámicos a la página. El modelo es el Sistema 
de Gestión de Base de Datos y la Lógica de negocio, y el controlador es el responsable de recibir 
los eventos de entrada desde la vista. (Ecured, 2015) 
Descripción del patrón: 
 Modelo: esta es la representación específica de la información con la cual el sistema 
opera. En resumen, el modelo se limita a lo relativo de la vista y su controlador 
facilitando las presentaciones visuales complejas. El sistema también puede operar con 
más datos no relativos a la presentación, haciendo uso integrado de otras lógicas de 
negocio y de datos afines con el sistema modelado. (Universidad de Alicante, 2015) 
 Vista: este presenta el modelo en un formato adecuado para interactuar, usualmente la 
interfaz de usuario. (Universidad de Alicante, 2015) 
 Controlador: este responde a eventos, usualmente acciones del usuario, e invoca 
peticiones al modelo y, probablemente, a la vista. (Universidad de Alicante, 2015) 
Muchos de los sistemas informáticos utilizan un Sistema de Gestión de Base de Datos para 
gestionar los datos: en líneas generales del MVC corresponde al modelo. La unión entre capa 
de presentación y capa de negocio conocido en el paradigma de la Programación por capas 
representaría la integración entre Vista y su correspondiente Controlador de eventos y acceso a 
datos, MVC no pretende discriminar entre capa de negocio y capa de presentación pero si 
pretende separar la capa visual gráfica de su correspondiente programación y acceso a datos, 
 
20 
 
algo que mejora el desarrollo y mantenimiento de la Vista y el Controlador en paralelo, ya que 
ambos cumplen ciclos de vida muy distintos entre sí. (Ecured, 2015) 
Aunque se encuentran diferentes implementaciones de MVC, el flujo que sigue el control 
generalmente es el siguiente: 
 El usuario interactúa con la interfaz de usuario de alguna forma. 
 El controlador recibe la notificación de la acción solicitada por el usuario. El controlador 
gestiona el evento que llega, frecuentemente a través de un gestor de eventos 
 El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma 
adecuada a la acción solicitada por el usuario. Los controladores complejos están a 
menudo estructurados usando un patrón de comando que encapsula las acciones y 
simplifica su extensión. 
El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La 
vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se 
reflejan los cambios en el modelo. El modelo no debe tener conocimiento directo sobre la vista. 
Un objeto vista puede registrarse con el modelo y esperar a los cambios, pero aun así el modelo 
en sí mismo sigue sin saber nada de la vista. El controlador no pasa objetos del modelo a la vista 
aunque puede dar la orden a la vista para que se actualice. (Ecured, 2015) 
Muchos sistemas informáticos utilizan un Sistema de Gestión de Base de Datos para gestionar 
los datos que debe utilizar la aplicación, dicha gestión corresponde al modelo. La unión entre 
capa de presentación y capa de negocio conocido en el paradigma de la Programación por capas 
representaría la integración entre la Vista y su correspondiente Controlador de eventos y acceso 
a datos, MVC no pretende discriminar entre capa de negocio y capa de presentación pero si 
pretende separar la capa visual gráfica de su correspondiente programación y acceso a datos, 
algo que mejora el desarrollo y mantenimiento de la Vista y el Controlador en paralelo, ya que 
ambos cumplen ciclos de vida muy distintos entre sí. 
 
21 
 
2.4. Método clínico (MC)El método clínico o proceso del diagnóstico, son los pasos ordenados que todo médico aplica 
en la búsqueda del diagnóstico en sus enfermos individuales, y consisten en: formulación del 
problema, obtención de la información primaria (interrogatorio y examen físico), formular la 
hipótesis, comprobar o negar la hipótesis, exposición de resultados, instituir terapéutica si 
procede o reiniciar proceso y exposición y evaluación de resultados finales (Ecuredd, 2015). En 
muchas enfermedades se conocen las causas, también los avances de la terapéutica6 han 
permitido determinar nuevas regularidades en la respuesta a los medicamentos. Por tanto, el 
estudio de los enfermos permite hacer estas generalizaciones de carácter teórico, que hoy forman 
parte del cuerpo de conocimientos de la Semiología7, la Patología8 y la Clínica. Al tiempo que 
se identificaban estas regularidades que permitían asegurar que varios enfermos tenían una 
misma enfermedad, los médicos observaban que, incluso, se comportaban con expresión 
diferente, por lo que comenzaron a describirse las formas clínicas. Es por eso que la expresión 
clínica y evolutiva es diferente para cada enfermo, aún teniendo la misma afección, y se trata en 
cada caso, de una nueva experiencia de la naturaleza. De estas consideraciones y contradicciones 
dialécticas, de lo que es similar, pero a la vez distinto, surgió la idea de que no existen 
enfermedades sino enfermos, lo que constituye una de las premisas fundamentales del método 
clínico (Selman, 2002). (Ecuredd, 2015) 
Los métodos facilitan la búsqueda de un camino no errático con un plan preestablecido y con 
reglas determinadas y aptas para conducir hacia el fin propuesto (Moreno, 2002). Cada enfermo, 
es una nueva situación y debe ser investigado con el método de la ciencia. El método clínico es 
el método científico aplicado al trabajo con los pacientes y sus etapas serán las mismas 
atendiendo a las peculariedades de cada nueva situación patológica encontrada. (Moreno, 2000) 
 
6 Parte de la medicina que se ocupa de los medios empleados en el tratamiento de las enfermedades y de la forma 
de aplicarlos 
7 Semiología clínica es el cuerpo de conocimientos que se ocupa de cómo identificar las diversas manifestaciones 
patológicas (signos o manifestaciones clínicas objetivas), de cómo buscar estas manifestaciones, de cómo reunirlas 
en síndromes, y de cómo interpretarlas, jerarquizarlas y razonarlas. Gracias a ese cuerpo de conocimiento se puede 
llegar al diagnóstico 
8 La patología humana es la rama de la medicina encargada del estudio de las enfermedades 
 
22 
 
2.4.1. Etapas o pasos lógicos del método clínico 
Las etapas del método clínico son las siguientes: 
A) Formulación del problema: es el enunciado del problema identificado como la pérdida o el 
principal motivo que lleva al enfermo a consultar al médico. Este también puede ser detectado 
por el profesional al precisar un trastorno físico, psíquico o social. (REDVET, 2007) 
B) Información primaria: la búsqueda de la información básica se refiere al desarrollo del 
examen clínico, que está constituido por el interrogatorio (Anamnesis9 remota y actual) y el 
examen físico. Este procedimiento está dirigido y orientado por la experiencia previa del 
profesional que lo desarrolla, así como por los conocimientos que aplica al ponerse al servicio 
del paciente. (REDVET, 2007) 
El examen clínico debe realizarse en forma completa, independientemente que se detalle más el 
problema del sistema dañado. Toda la información debe recogerse en detalle en el expediente 
clínico. Este es el documento más importante para la aplicación del MC y que resulta ser el ideal 
para llegar a la conjetura o hipótesis diagnóstica (Moreno, 1998). 
B) Formulación de la hipótesis: la hipótesis es la impronta diagnóstica o la primera impresión 
susceptible de ser modificada con los elementos de la experiencia médica, los conocimientos y 
la contratación. Es imprescindible que este diagnóstico quede bien definido y se apoye en la 
información recogida con un fundamento real y objetivo de los elementos patológicos que aporta 
el examen clínico. Si la búsqueda de información es deficiente e inexacta, la hipótesis no tendrá 
posibilidad alguna de comprobarse y por consiguiente, los subsiguientes pasos no se 
conseguirán nunca (Bernard, 1976). 
C) Comprobar o negar la hipótesis: este paso se lleva a cabo cuando se observa la evolución del 
enfermo y se realiza un protocolo adecuado y planificado de investigaciones. Estas técnicas 
paraclínicas son también interpretadas por seres humanos que al igual que el médico asistencial, 
 
9 La anamnesis es el término empleado para referirse a los conocimientos y habilidades de la Semiología clínica, 
es decir, para referirse a la información proporcionada por el paciente al profesional sanitario durante una entrevista 
clínica, con el fin de incorporar dicha información en la historia clínica. 
 
23 
 
analizan resultados, observan imágenes, estudian tejidos interpretan lesiones internas en las 
distintas técnicas establecidas. (REDVET, 2007) 
D) Exposición de resultados: el alcance de un diagnóstico definitivo de certeza permite utilizar 
la terapéutica10 en todas sus facetas y muchas veces el uso de la Medicina alternativa permite la 
solución de problemas sin elevar el costo y con la utilización de recursos que siempre han estado 
al alcance de todos aún en las peores condiciones (Yu Chuan, 1995). 
E) Alternativa de solución: si procede, o reiniciar el proceso para recomenzar con nuevas 
estrategias pero siguiendo los mismos pasos. (REDVET, 2007) 
Exposición y evaluación de los resultados finales: Este paso es imprescindible para su 
comunicación al resto de la comunidad laboral o científica de la unidad donde se trabaje. Es 
muy adecuada la discusión de los casos en colectivo, lo mismo que tomar decisiones que para 
notificar los resultados obtenidos en los análisis complementarios y en la evolución después de 
la terapéutica empleada. (REDVET, 2007) 
2.4.2. Características del método clínico 
• La información recogida debe ser real, esencial y necesaria, teniendo en cuenta la ciencia 
semiológica. 
• Los problemas de salud individual deben ser bien identificados. 
• Las hipótesis diagnósticas deben estar bien fundamentadas, así como las interrelaciones 
entre ellas. La causa, la lesión anatómica, la alteración fisiopatológica o pato bioquímica, 
no deben ser descuidadas. 
• El análisis debe incluir el medio externo, manejo, alimentación y sus interrelaciones con 
los problemas clínicos. 
• Deben establecerse los planes de búsquedas de información tecnológica para contrastar 
con la hipótesis planteada para su verificación final. 
 
10 Parte de la medicina que se ocupa de los medios empleados en el tratamiento de las enfermedades y de la forma 
de aplicarlos. 
 
24 
 
• Los exámenes deben ser justificados y valorados en relación con los diagnósticos 
clínicos establecidos. 
• La conducta terapéutica debe ser justificada y valorada constantemente 
• El paciente debe ser informado, cuando sea posible, de su proceso y de las decisiones 
del médico para obtener su conformidad. 
• La evolución debe presentarse exponiendo el pensamiento científico del médico y no ser 
una exposición de datos innecesarios y anecdóticos. 
• El egreso debe ser un resumen de cada problema y las orientaciones brindadas por el 
médico para el futuro cercano o lejano. 
• El médico, si desea que la clínica sea ciencia clínica deberá acostumbrarse a trabajar con 
su método clínico en forma explícita y no oculta. 
• Ellos deben ser registrados pues en algunos casos son olvidados, tergiversados, en 
detrimento de la salud del paciente y la propia medicina. 
2.4.3. Método clínico en medicina veterinaria 
La clínica