Implementación de Software

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERÚ
FACULTAD DE INGENIERÍA DE SISTEMAS
TESIS
“IMPLEMENTACIÓN DE SOFTWARE PARA EL REGISTRO Y

PROCESAMIENTO DE ATENCIONES DE SALUD EN LAS
ACTIVIDADES DE RESPONSABILIDAD SOCIAL – CASO MINA
CORIHUARMI”
PRESENTADA POR:
MENDOZA RICALDI, LUIS ANGEL.
PARA OPTAR EL TÍTULO PROFESIONAL DE:
INGENIERO DE SISTEMAS
HUANCAYO – PERÚ
2014
ASESOR:
Mg. Richard Mercado Rivas.
ii
AGRADECIMIENTOS:
Deseo expresar muestras de agradecimiento:
A MIS PADRES
Por su ejemplo, amor y apoyo incondicional y constante.
A MI ALMA MATER
Por haber propiciado mi formación profesional.
A MI ASESOR
Por su gran apoyo y por compartir su vasto conocimiento.
A MIS MAESTROS DE LA FIS
Por su dedicación a la enseñanza a mi paso por la Universidad.
A MIS AMIGOS Y COLEGAS DE LA FIS
Por compartir experiencias dentro y fuera de las aulas universitarias
A LA GERENCIA DE RELACIONES COMUNITARIAS MINA CORIHUARMI
Por darme la oportunidad de desarrollar esta tesis desde sus filas.
iii
DEDICATORIA:
A mi familia, mi madre Basilia, mi padre
Luis y mis hermanos; quienes en todo
momento me acompañan en este
transcurrir de la vida.
iv
RESUMEN
La presente tesis titulada “Implementación de Software para el Registro y

Procesamiento de Atenciones de Salud en las Actividades de Responsabilidad Social
– Caso Mina Corihuarmi”, se desarrolla en el ámbito de la actividad minera en el país.
La Mina Corihuarmi desarrolla las actividades de Responsabilidad Social Empresarial
mediante la Oficina de Relaciones Comunitarias que, entre otras, cuenta con un área
de Salud con las especialidades de: Medicina General, Enfermería, Obstetricia y
Odontología; las mismas que prestan sus servicios a la población de la zona de
influencia del proyecto minero de manera gratuita. Las atenciones médicas generan
unos registros físicos que son muy difíciles de procesar por la redundancia de
información y requerir largos periodos de tiempo por no contar con un mecanismo
computarizado. El problema descrito es abarcado con la implementación de un
software para el registro y procesamiento de la información utilizando la metodología
de desarrollo ágil Extreme Programming, y herramientas tecnológicas de desarrollo
de software libre, ya que otros mecanismos computarizados para la mejora de la
situación, como la utilización de herramientas ofimáticas, no resultan del todo
satisfactorias o presentan dificultades operativas. La metodología Extreme
Programming adoptada se enfoca en la satisfacción del usuario, poniendo poco
énfasis a una documentación rigurosa utilizada en otras metodologías, además de
una comunicación constante con el cliente, lo cual hizo que se pueda obtener
información de la organización de primera mano y en todo momento. De esta manera
se logró el desarrollo del software, la escritura del código, modificaciones a la misma
así como las pruebas de aceptación. Después de la implementación del software se
resolvieron los problemas de redundancia de información y se disminuyeron
considerablemente los lapsos de tiempo en el procesamiento y la consolidación de
datos, de este modo quedó demostrado que la alternativa adoptada ofrece una
solución viable al problema planteado.
v
ABSTRACT
The present thesis entitled "Implementation of Software for Recording and Processing
Hospitality Health Activities in Social Responsibility - Case Corihuami Mine" , is
developed in the field of mining activity in the country. Mine Corihuarmi develops its
Enterprise Social Responsibility activities through the Office of Community Relations ,
among others, has an area of Health specialties such as: General Medicine, Nursing,
Midwifery and Dentistry ; providing the same services to the population of the area of
influence of the mining project for free. Medical care creates a lot of physical records
that are very difficult to process due to the information redundancy and require long
periods of time by not having a computerized mechanism. The problem described is
covered with the implementation of a software for recording and processing
information using agile development methodology Extreme Programming, and
technological tools of free software development , because other computerized
mechanisms to improve the situation, as the use of office tools , are not entirely
satisfactory or present operational difficulties. The methodology adopted Extreme
Programming focuses on user satisfaction, placing little emphasis to rigorous
documentation used in other methodologies, furthermore constant communication
with the client, which made the organization of the firsthand information all the time.
Thus software development, code writing, modifications and acceptance testing was
achieved. After implementation of the software problems of information redundancy
were resolved and time lapses in processing and data consolidation were significantly
decreased, so it was demonstrated that the option chosen offers a viable solution to
the problem.
vi
INDICE
Pág.
ASESOR: ii
AGRADECIMIENTOS: iii
DEDICATORIA: iv
RESUMEN v
ABSTRACT vi
ÍNDICE DE FIGURAS ix
ÍNDICE DE TABLAS x
INTRODUCCION 1
CAPÍTULO I 3
GENERALIDADES 3
1.1. PLANTEAMIENTO DEL PROBLEMA 3
1.1.1. Mina Corihuarmi 3
1.1.2. La Problemática 6
1.2. FORMULACION DEL PROBLEMA 8

1.3. OBJETIVO GENERAL 8
1.4. JUSTIFICACIÓN 8
1.5. HIPÓTESIS 9
1.5.1. Hipótesis General 9
1.6. OPERACIONALIZACIÓN DE VARIABLES 9

1.7. DISEÑO METODOLÓGICO 10
1.7.1. TIPO DE INVESTIGACIÓN 10
1.7.2. NIVEL DE LA INVESTIGACIÓN 10
1.8. SISTEMA DE REFERENCIA 11
CAPÍTULO II 12
MARCO DE REFERENCIA 12
2.1. ANTECEDENTES 12
A1. 12
A2. 12
A3. 13
A4. 13
A5. 14
2.2. MARCO TEÓRICO 14

2.2.1. Metodología de Desarrollo Ágil 14
2.2.2. Manifiesto Ágil 15
2.2.3. Costo de los Cambios en Proyectos de Software 16
2.2.4. Extreme Programming (XP) 17
vii
2.2.5. Reglas, Pautas, Normas de un Proyecto Extreme Programming 18
2.2.6. Roles XP 31
2.2.7. Valores de un Proyecto Extreme Programming 32
2.2.8. Sistema Gestor de Base de Datos. 33
2.2.9. Plataforma Tecnológica 35
2.2.10. Modelo Aplicativo 37
2.3. MARCO CONCEPTUAL 38
CAPÍTULO III 40
INTERVENCIÓN METODOLÓGICA 40
3.1. ADMINISTRACIÓN 40
3.2. PLANIFICACION 40
3.2.1. Establecimiento de las Historias de Usuario 41
3.2.2. Planificación de los Lanzamientos 45
3.2.3. Iteraciones 46
3.2.4. Architectural Spike 46
A. Definición de Herramientas y Tecnologías 46
3.3. DISEÑO 47
A. Modelación de la Base De Datos 47
3.4. CODIFICACIÓN 49
A. Implementación en el Sistema Gestor de Base De Datos 49
B. Hibernate 50
C. Mapeo de la Base de Datos 51
D. Creación de Clases 53
E. Diseño de Interfaces de Usuario 53
3.5. RUEBAS Y LANZAMIENTOS 54
CAPITULO IV 63
ANALISIS Y DISCUSIÓN DE RESULTADOS 63

4.1. RESULTADOS DE LA IMPLEMENTACION DEL SOFTWARE 63
4.2. RESULTADOS DEL REGISTRO Y PROCESAMIENTO DE LA ATENCIONES EN
SALUD 64
CONCLUSIONES 67
RECOMENDACIONES 68
REFERENCIAS 69
REFERENCIAS BIBLIOGRÁFICAS 69
REFERENCIAS ELECTRÓNICAS 69
viii
ÍNDICE DE FIGURAS
Pág.
Figura 1.1: Ubicación de la Mina Corihuarmi. 4

Figura 1.2: Estructura Orgánica de la Oficina de Relaciones Comunitarias - Mina Corihuarmi. 6
Figura 2.1: Comparación de costos del cambio usando metodologías tradicionales y método-
logías ágiles en proyectos de software. 16
Figura 2.2: Diagrama de flujo de un proyecto con la metodología Extreme Programming 17
Figura 2.3: Reglas, pautas, normas de un Proyecto Extreme Programming. 18
Figura 2.4: Formato para la elaboración de las Historias de Usuario. 19
Figura 2.5: Iteración Extreme Programming 21
Figura 2.6: Tarjetas CRC 26
Figura 2.7: Propiedad colectiva del código 27
Figura 2.8 Contexto de Hibérnate en una aplicación Java 36
Figura 2.9 Modelo Aplicativo 37
Figura 3.1: Modelo Entidad Relación 47
Figura 3.2: Diagrama del Modelo Relacional de Base de Datos 48
Figura 3.3: Implementación del Modelo Relacional de Base de Datos 49
Figura 3.4: Definición de tablas del modelo relacional 50
Figura 3.5: Configuración de Hibernate 50
Figura 3.6: Mapeo de Base de Datos 52
Figura 3.7: Mapeo de base de datos, implementación de autoincremento 53
Figura 3.8: Codificación de la página de inicio 54
Figura 3.9: Interfaz de la página de inicio 54
Figura 3.10: Página de bienvenida 55
Figura 3.11: Padrón de beneficiarios 55
Figura 3.12: Exportación del padrón de beneficiarios 56
Figura 3.12: Exportación del padrón de beneficiarios 56
Figura 3.14: Selección de beneficiario para nuevo registro de atención 57
Figura 3.15: Detalles de atención 57
Figura 3.16: Inserción de diagnósticos 58
Figura 3.17: Diagnóstico agregado al registro de atención 58
Figura 3.18: Inserción de la medicación 59
Figura 3.19: Medicación agregada al registro de atención 59
Figura 3.20: Inserción de tratamientos 60
Figura 3.21: Historial de atenciones 60
Figura 3.22: Exportación de registros del historial de atenciones 61
Figura 3.23: Consolidado de atenciones 61
Figura 3.24: Consolidado de atenciones 62
ix
ÍNDICE DE TABLAS
Pág.
Tabla 1.1: Características de la información generada por la organización 7

Tabla 1.2: Ventajas y desventajas de las opciones para registro y procesamiento de
la información. 8
Tabla 1.3: Operacionalización de variables 9
Tabla 3.1: Historia de usuario Nº 01 41
Tabla 3.10: Plan de lanzamientos 45
Tabla 3.11: Iteraciones 46
Tabla 4.1: Resultado de la implementación del software 63
Tabla 4.2: Nivel de aceptación del software 64
Tabla 4.3: Resultados del registro y procesamiento de las atenciones de salud 64
Tabla 4.4: Tiempo de obtención y procesamiento de información 65
Tabla 4.5: Redundancia de información 66
Tabla 4.6: Comparación de la situación inicial y final. 66
x
INTRODUCCION
El mundo actual exige la disponibilidad de información en tiempo real para la ayuda en

toma la toma de decisiones en todos los niveles de una organización, entonces es
necesario contar con los mecanismos adecuados para ello. Estos mecanismos son
generalmente soportados en la implementación de Sistemas de Información y
Comunicación, las cuales, dependiendo del giro del negocio pueden solo ser de soporte
hasta formar la parte principal del mismo. La implementación de estos Sistemas de
Información y Comunicación tiene aplicación diversa, casi no encontramos algún campo
en el cual no se haya implementado, motivo por el cual se desarrollaron diversas
maneras, métodos para su la implementación en las organizaciones. Entre estos
encontramos la metodología de desarrollo ágil denominada Extreme Programming o
Programación Extrema la cual nos ayuda a la implementación de estos Sistemas de
Información en un entorno cambiante como el caso de la Oficina de Relaciones
Comunitarias – Mina Corihuarmi en sus atenciones de salud.
La presente tesis se divide en cuatro capítulos, en el capítulo primero denominado:

Generalidades; nos avocaremos a precisar las condiciones que propiciaron la presente
investigación, describiendo la situación problemática en el contexto de las actividades
de Mina Corihuarmi. Se realizará la formulación del problema, el planteamiento de la
hipótesis, se definirán los objetivos y las variables que tendremos en consideración para
validarla.
En el capítulo segundo denominado: Marco Teórico; se realiza la descripción de los

fundamentos, las investigaciones similares, herramientas tecnológicas y paradigmas
que apoyarán la realización de la presente investigación y que nos permitan definir el
modelo aplicativo que regirá su desarrollo.
El capítulo tercero, Intervención Metodológica, muestra la aplicación de los conceptos
descritos en capítulos anteriores lo cual resulta en la consecución del Software o
Sistema de Información para el registro y procesamiento de atenciones de salud en las
actividades de responsabilidad social para la Mina Corihuarmi.
En el capítulo cuarto, Análisis de y Discusión de Resultados se muestra la comparativa

de la situación inicial y la situación después de la intervención metodológica para la
validación de la hipótesis planteada en el capítulo primero en cuanto a la mejora en los
1
tiempos para la obtención de información y la disminución de redundancia de
información.
De este modo se concluye que la investigación abordada mediante la adopción de la

metodología Extreme Programming, las herramientas y plataformas tecnológicas
adoptadas resuelven la situación planteada, también se precisan recomendaciones para
la investigaciones similares.
L.A.M.R.
2
CAPÍTULO I
GENERALIDADES
En el presente capítulo se abarca el planteamiento del problema, los objetivos y los

supuestos de la investigación. Se definen los métodos, herramientas y técnicas que se
utilizarán en esta investigación.
1.1. PLANTEAMIENTO DEL PROBLEMA
1.1.1. Mina Corihuarmi

Minera IRL es una empresa que se dedica a la explotación de recursos minerales
con operaciones en país y otros como: Argentina y Chile. La Mina Corihuarmi es
uno de sus proyectos que se vienen desarrollando en la región. La Oficina de
Relaciones Comunitarias es la encargada de llevar a cabo las actividades de
responsabilidad social con las comunidades del área de influencia (directa en
indirecta) que comprende diversas comunidades de la zona del Canipaco como:
Chongos Alto, Pititayo, Huasicancha, Palaco y de la sierra de Lima como: Atcas y
Huantán. Para tal fin la Oficina cuenta con diversas áreas como: Salud, Social,
Pecuario, Sanidad Animal y Social Educativo, las cuales aportan al desarrollo de la
calidad de vida de los pobladores con la prestación de servicios, asistencia técnica
para el desarrollo de sus actividades económicas y el apoyo en el desarrollo de
proyectos productivos autosustentables en las diversas actividades del poblador de
la zona. Las atenciones médicas se desarrollan, ya sea en campañas o de manera
regular y permanente en las diversas comunidades y en las diferentes
especialidades que son Medicina General, Odontología, Enfermería y Obstetricia.
En cada una de estas atenciones se registra los datos de las personas atendidas,
el tratamiento, la medicación, el diagnostico. El área de Sanidad Animal se encarga
3
de brindar asistencia técnica en las actividades ganaderas de las comunidades,
para el mejoramiento de la producción y productividad, El área Forestal es el
encargado de producir especies forestales y frutícolas para la forestación y
reforestación de suelos, además de la implementación de viveros en las
comunidades para introducir a los pobladores en esta actividad económica. El área
Pecuaria se encarga de brindar capacitaciones y asistencia técnica a los pobladores
en la crianza de animales menores, como un programa de seguridad alimentaria. El
área Social y Social Educativo se encarga de promover un ambiente de fraternidad
y colaboración con los pobladores mediante el desarrollo de actividades de apoyo
social y capacitaciones en temas diversos.
A. Ubicación1
En la espectacular cordillera de los Andes, a una altitud de casi 5,000

metros, se encuentra nuestra Mina de Oro Corihuarmi.
El acceso a Corihuarmi es a través de 330 kilómetros en una carretera

principal asfaltada al este de Lima, la capital de Perú, por la división en los
Andes a Yauli, luego al sureste a la ciudad de Huancayo, la capital de la
región Junín. Desde Huancayo se llega a través del altiplano viajando al
suroeste en caminos de grava por 115 kilómetros pasando por las
comunidades de Chupuro y Vista Alegre hasta la mina. En la Figura 1.1
siguiente se muestra la ubicación de Mina Corihuarmi.
Figura 1.1: Ubicación de la Mina Corihuarmi.
Fuente: Minera IRL S.A.

Elaboración: Minera IRL S.A.
1
Ubicación tomada de la pagína web de la empresa Minera IRL S.A. Disponible en: http://www.minera-
irl.com/es/minas/mina-de-oro-corihuarmi/icacion
4
B. Relaciones Comunitarias – Mina Corihuarmi
“Además del rendimiento económico generado por la Mina de Oro

Corihuarmi, estamos muy orgullosos de la notable mejora en la calidad de
vida de las comunidades cercanas originada por la presencia de nuestras
actividades mineras.
Brindamos muchos programas de salud y educación, impulsamos iniciativas

de desarrollo sostenible y patrocinamos eventos culturales y tradicionales.
La mina también brinda cientos de oportunidades de empleo directo y ayudó

a crear diversos pequeños negocios que ahora brindan muchos de los
bienes y servicios de los que dependemos para nuestras operaciones
diarias” 2.
C. Visión de la Organización
“Las comunidades campesinas del área de influencia se verán fortalecidas

con el apoyo técnico en el desarrollo de sus actividades productivas llegando
a un carácter empresarial, que tiendan a mejorar sus niveles de vida y de
ingresos económicos de su población, participando en forma conjunta en las
acciones que desarrollará la Oficina de Relaciones Comunitarias – Mina
Corihuarmi de la Minera IRL S.A.”.
D. Misión de la Organización
“Que la Mina Corihuarmi favorezca a la economía de las comunidades

campesinas ubicadas dentro del área de influencia, y beneficie igualmente
a la economía peruana en términos macroeconómicos, mediante el impulso
e implementación de actividades productivas y socio económicas
sostenibles durante la vida útil de la mina”.
E. Estructura Orgánica
En la figura 1.2, se muestra el Organigrama Estructural de la Oficina de

relaciones Comunitarias - Mina Corihuarmi.
2
Tomado de la página web de Minera IRL S.A. – Mina Corihuarmi. Disponible en: http://www.minera-
irl.com/es/minas/mina-de-oro-corihuarmi/laciones-comunitarias
5
Figura 1.2: Estructura Orgánica de la Oficina de Relaciones Comunitarias - Mina Corihuarmi.
COORDINACIÓN GENERAL
AREA SALUD AREA SOCIO EDUCATIVO AREA PECUARIA AREA SOCIAL
MEDICINA GENERAL FORESTAL
ODONTOLOGIA SANIDAD ANIMAL
ENFERMERIA
OBSTETRICIA
Fuente: Oficina de Relaciones Comunitarias Mina Corihuarmi.

Elaboración: Propia.
1.1.2. La Problemática
La situación problemática que se presenta en la Oficina de Relaciones Comunitarias
– Mina Corihuarmi es que los registros de datos de las actividades de
responsabilidad social de cada área se realizan de manera independiente, esto
hace que los registros sean en muchos casos incongruentes cuando se necesita
realizar informes consolidados, de esta manera se crean registros innecesarios que
hacen la tarea muy tediosa y que hacen que sea muy costosa.
El caso más saltante se da en el área Salud ya que las atenciones que realizan
tienen un registro físico llamado “Registro de Atención” o “Ficha de Atención”3, en
estas se consignan los siguientes datos: Nombres y Apellidos, número de DNI,
edad, comunidad a la cual pertenece el paciente, diagnóstico, medicación,
tratamiento y antecedentes. Inclusive el registro de estos datos no se realiza de
manera estricta y existen variaciones para referirse a cierto diagnóstico dado que
cada profesional especialista lo realiza a su manera (por ejemplo: Rinofaringitis
Aguda y Resfrio Común4, se utiliza dos o más nombres para referirse a un mismo
diagnóstico), lo mismo sucede para con los nombres. La Tabla 1.1 siguiente
muestra las características de la información generada por la organización.
3
Anexos I al IV
4
Anexos V al XV
6
Tabla. 1.1: Características de la información generada por la organización.
DESCRPCION
VALOR APROXIMADO
Consulta de Atenciones 10 minutos.
Consulta de Datos de
15 minutos.
Beneficiarios.
Reporte por grupo etario. 30 minutos.
Reporte de Enfermedades
30 minutos.
atendidas más recurrentes.
Consolidado de Atenciones por

03 horas.
persona.
Consolidado de Atenciones indeterminado
Redundancia 20 %
El tiempo indeterminado para consolidar la información de las atenciones en salud

depende de los costes en los que se incurre, además de afectar la productividad de
los profesionales responsables de las cuatro especialidades.
Se realizan informes mensuales de actividades en las cuales se incluyen el número

de atenciones realizadas, los diagnósticos más recurrentes, la distribución etaria,
etc. Esta actividad mensual requiere de un tiempo que va de dos a tres días, el
mayor inconveniente es la realización de un registro consolidado que haría las
veces de “Historial Médico” ya que resulta muy tedioso agrupar los datos de las
personas por no usar un criterio homogéneo para el registro por las sub áreas y que
no se realizó anteriormente por la complejidad y los costos que implica.
Un caso similar sucede en todas las áreas de la Oficina de Relaciones

Comunitarias, además que se dificulta la realización de un registro consolidado
general que abarque las atenciones y participaciones de las personas en todas las
áreas para cuenta de las actividades de responsabilidad social y de tiempos
prolongados de espera para la búsqueda de registros. En la situación descrita
anteriormente se plantearon solo mecanismos computarizados para el registro y
procesamiento de información, a las cuales se realizó una evaluación de las
ventajas y desventajas que se muestra en la tabla 1.2 siguiente.
7
Tabla. 1.2: Ventajas y desventajas de las opciones para registro y procesamiento de la
información.
Ventajas Desventajas
 No se garantiza la disminución
de la redundancia de
información.
Herramientas
 Inicio inmediato en el
ofimáticas registro y procesamiento de  Requiere conocimientos
información. intermedios o avanzados de
ofimática por parte de todo el
personal.
 Se espera una gran

disminución de la  El registro y procesamiento de
Implementación de redundancia de información se realiza después
información. de iniciado la implementación
software
del software.
 No requiere conocimientos
especializados por parte de
los usuarios finales.
Visto el mayor número de desventajas del uso de las herramientas ofimáticas y la

mayor cantidad de ventajas de la implementación del software, se toma esta última.
1.2. FORMULACION DEL PROBLEMA

¿Cómo influye la implementación de software en el registro y procesamiento de
atenciones de salud en las actividades de responsabilidad social – caso Mina
Corihuarmi?
1.3. OBJETIVO GENERAL

Determinar la influencia de la implementación de software en el registro y
procesamiento de atenciones de salud en las actividades de responsabilidad social
– caso Mina Corihuarmi.
1.4. JUSTIFICACIÓN
1.4.1. Justificación Teórica
En el desarrollo del software es necesario la creación de na Base de Datos que es
básicamente un sistema computarizado cuyo propósito es mantener información y
hacer que se encuentre disponible oportunamente. Esto a su vez constituye una
importante herramienta para el tratamiento de datos, pues permite ordenar los datos
de manera que estén relacionados y estructurados acorde a las especificaciones
que se planteen.
8
La importancia de una base de datos radica en que permite ordenar la información
de tal forma que acelere la búsqueda de la misma, además una base de datos bien
elaborada permite dar servicio a muchas aplicaciones al mismo tiempo, siendo por
esta razón imprescindible en una institución que maneja cantidades considerables
de datos.
Una vez culminado e implementado el proyecto, este beneficiará directamente a los

responsables de la Oficina, teniendo una base de datos actualizada y disponible,
con ayuda del software para administración y respaldo de su información.
1.4.2. Justificación Metodológica

La aplicación de la metodología de desarrollo ágil Extreme Programming, el uso de
las herramientas y la secuencia propuesta para la intervención resuelven el
problema planteado con suficiencia y respaldo de una base de conocimientos
lograda a través de la aplicación de los mismos en otros proyectos.
1.4.3. Justificación Práctica

El proyecto finalizado cumple con solucionar el problema planteado, satisfaciendo
a los usuarios y dotándoles de un mecanismo de interacción con el software de
manera simple, amigable y familiar.
1.5. HIPÓTESIS
1.5.1. Hipótesis General

La implementación de software influye de forma positiva en el registro y
procesamiento de atenciones de salud en las actividades de responsabilidad
social – caso mina Corihuarmi.
1.6. OPERACIONALIZACIÓN DE VARIABLES

En la Tabla 1.3 siguiente se muestra las variables consideradas para la presente
investigación.
Tabla. 1.3: Operacionalización de variables.

Variable Indicador
V. Independiente
 Número de requerimientos
Implementación de Software implementados.
 Nivel de aceptación del
software.
9
V. Dependiente
Registro y procesamiento de  Tiempo de obtención de

atenciones de salud información.
 Nivel de redundancia de datos.
V. Interviniente
Extreme Programming  Tiempo

 Calidad
Fuente: Desarrollo de la investigación.

Esta investigación pretende medir de qué manera influye la implementación de

software en el registro y procesamiento de atenciones de salud en las actividades
de responsabilidad social – caso Mina Corihuarmi, por tal motivo la variable
independiente será definida como la Implementación de Software, de la cual se
necesita obtener información respecto de sus características más importantes que
son: el nivel de aceptación del software y el número de requerimientos
implementados satisfactoriamente; del mismo modo es necesario conocer acerca
de la variable dependiente para poder medir el efecto sobre esta. También es
necesario conocer acerca de la variable interviniente que corresponde a la
utilización de la metodología Extreme Programming, que es la que regirá la
implementación del software.
1.7. DISEÑO METODOLÓGICO
1.7.1. TIPO DE INVESTIGACIÓN

Por la naturaleza de la situación y la propuesta de solución planteada el tipo
de investigación es aplicativa porque se busca la utilización de los
conocimientos adquiridos para observar sus consecuencias prácticas, es decir
medir el efecto de la implementación del software en el registro y
procesamiento de información.
1.7.2. NIVEL DE LA INVESTIGACIÓN

El nivel de investigación será explicativa y descriptiva, explicativa porque se
establecerá la relación de causa y efecto en la intervención a realizar y se
tendrá la posibilidad de verificar los posibles efectos de la implementación del
software en la Oficina de Relaciones Comunitarias – Mina Corihuarmi y
10
descriptiva porque se realizará la identificación de sus características más
sobresalientes.
1.8. SISTEMA DE REFERENCIA

El sistema de referencia lo conforman registros físicos generados por las
atenciones en salud de la Oficina de Relaciones Comunitarias, específicamente
de las especialidades de Medicina General, Obstetricia, Enfermería y Odontología
desde el año 2008 en adelante, fecha desde la cual se viene brindando el servicio.
De lo descrito hasta ahora se puede observar dos características que son de relevancia
y en la cual se ha de intervenir para propiciar una situación que comparativamente sea
mejor a la situación descrita en el planteamiento del problema, las cuales son mejorar
los tiempos de obtención de información y disminuir la redundancia de información
mediante la implementación de un software o sistema informático.
11
CAPÍTULO II
MARCO DE REFERENCIA
El presente capitulo explora los conocimientos necesarios para la consecución de

una solución factible al problema planteado en el capítulo anterior, para lo cual se
inicia con una revisión de trabajos de investigación similares y puedan respaldar la
alternativa adoptada.
2.1. ANTECEDENTES
A1. Universidad Politécnica de Valencia. Desarrollo De Un Sistema De
Gestión de una Empresa de Confecciones (2004). Ejemplo de Desarrollo
de Software Utilizando la Metodología XP.
El proyecto consiste en el desarrollo de un sistema de gestión para una
empresa de confecciones. En dicha gestión de la empresa se incluyen gestión
de pedidos, gestión de clientes (tanto principal como los de temporada),
facturación, gestión de productos, gestión de materias primas, etc. El proyecto
se divide en las siguientes partes: Gestión del Proyecto, Implementación y
Pruebas.
A2. Echeverry Tobón, Luís Miguel, Delgado Carmona, Luz Elena (2007).
Caso práctico de la metodología ágil XP al desarrollo de software.
Universidad Tecnológica de Pereira.
“En el proyecto se plantea realizar una experiencia real en la aplicación de XP
al desarrollo de software con el fin de determinar, para unas circunstancias
específicas, que tan bien se ajusta la metodología. El proceso inició en una
12
revisión bibliográfica de la metodología y otros aspectos relacionados a esta.
A continuación se contactó con un posible cliente al cual se hizo una
presentación de los objetivos iniciales del proyecto. Una vez acorados todos
los detalles se procedió a su ejecución al final del cual se redactó el informe
final documentando la experiencia. El documento cuenta con siete capítulos
distribuidos de la siguiente forma. En el primer capítulo se hace un recorrido
teórico por XP y se esbozan elementos importantes de las metodologías
ágiles. En el segundo capítulo se hace una presentación del proyecto en
términos del entorno que lo rodea, una breve descripción del cliente y el tipo
de negocio para el cual se desarrolló. En los capítulos tercero a sexto se
realizó una comparación entre los enunciados teóricos expuestos en el
capítulo primero y la aplicación que los autores hicieron en la ejecución del
proyecto. Finalmente en el último capítulo se hace una serie de comentarios
relevantes acerca de situaciones especiales que surgieron durante la
ejecución del proyecto. En el recorrido teórico se realiza una introducción
breve de las metodologías ágiles resaltando el manifiesto ágil como su punto
de partida, seguido de una exposición de los principios sobre los cuales se
basa XP. La parte central del documento consta de los capítulos tercero al
sexto correspondiendo a cada una de las fases de desarrollo en XP:
planeación, diseño, codificación y pruebas. En cada uno de estos capítulos se
discute como se aplicaron los aspectos de la correspondiente etapa al
proyecto, así como el resultado obtenido”.
A3. Cruz Acosta Santiago David. Sistema de diagnóstico de líneas

telefónicas de ANDINATEL S.A. (2009). Facultad de Ingeniería de
Sistemas, Escuela Politécnica Nacional, Ecuador.
El proyecto se desarrolla adoptando la metodología Extreme Programming en
una empresa de prestación de servicios de telefonía fija que sufre averías a
nivel operacional que afectan la disponibilidad del servicio, por ende la calidad
de servicio y disminuyen el nivel de satisfacción de los clientes. Los resultados
obtenidos tras la implementación del sistema muestran una gran aceptación
por parte delos usuarios derivados de las características de la metodología,
es decir su enfoque en la satisfacción del cliente.
A4. Mindy Sanchez y Erick Torres. Desarrollo de un Sistema web basado

en ADO.net para el control de la gestión de inscripción y logística de
cursos en la empresa Enfoque Directo Aplicado Consultores (2011).
13
Escuela de Computación, Facultad de Ciencias de la Informática,
Caracas.
La tesis “…se enfoca en la presentación de una aplicación web que servirá
para optimizar el control tanto de la gestión de inscripciones como la logística
de los cursos impartidos por la empresa Enfoque Directo Aplicado
Consultores, C.A. con el objetivo de simplificar sus procesos administrativos y
mejorar la eficiencia del personal al tiempo que se satisfacen sus necesidades
de control y gestión. El desarrollo de este sistema siguió la metodología
conocida como Extreme Programming XP, misma que se compone de cuatro
(4) fases: planificación, diseño, desarrollo y pruebas. En la fase de
planificación se realizó la investigación e identificación de los requerimientos
de la empresa, en esta etapa se llevó a cabo el levantamiento de información
tanto documental y bibliográfica como de campo dentro y fuera de la empresa.
Con la información obtenida, se procede al análisis de la misma, al diseño de
la estructura y al desarrollo del sistema que atenderá los requerimientos de
forma óptima, el desarrollo concluyó con pruebas y ajustes finales al sistema.
En conclusión, cabe destacar que la aplicación desarrollada cubrió las
expectativas de la empresa, y que esta manifestó que realizará las gestiones
administrativas necesarias para procurar los recursos económicos que
requiere a efecto de implementarla en su plataforma tecnológica”.
A5. Paola Plancarte Solórzano. Diseño de un sistema como estrategia

para incrementar el rendimiento académico del alumno: caso Liceo
Anglo Pedagógico. (2011). Instituto Politécnico Nacional, Unidad
Profesional Interdisciplinaria de Ingeniería y Ciencias Sociales y
Administrativas, Mexico.
“…en esta tesis se muestra el desarrollo de la aplicación Web, que proporciona

el apoyo que demandan los profesores y directivos para lograr un óptimo
desempeño de sus actividades, principalmente el incremento en el
rendimiento académico de los alumnos”. La implementación de la aplicación
web se realiza adoptando la metodología Extreme Programming utilizando
plataformas de desarrollo Microsoft.
2.2. MARCO TEÓRICO
2.2.1. Metodología de Desarrollo Ágil

El 17 de febrero de 2001 diecisiete críticos de los modelos de mejora del
desarrollo de software basados en procesos, convocados por Kent Beck,
14
quien había publicado un par de años antes Extreme Programming Explained,
libro en el que exponía una nueva metodología denominada Extreme
Programming, se reunieron en Snowbird, Utah para tratar sobre técnicas y
procesos para desarrollar software. En la reunión se acuñó el término
“Métodos Ágiles” para definir a los métodos que estaban surgiendo como
alternativa a las metodologías formales (CMMI, SPICE) a las que
consideraban excesivamente “pesadas” y rígidas por su carácter normativo y
fuerte dependencia de planificaciones detalladas previas al desarrollo.
Los integrantes de la reunión resumieron los principios sobre los que se basan
los métodos alternativos en cuatro postulados, lo que ha quedado denominado
como Manifiesto Ágil.
2.2.2. Manifiesto Ágil

Los propulsores de las metodologías ágiles firmaron un manifiesto donde se
expresaban las ideas fundamentales del estilo de gestión:
a) Valorar a las personas y su interacción, por encima de los procesos y las

herramientas: procesos de calidad con personas y relaciones mediocres
no darán buenos resultados.
b) Valorar el software que funciona, por encima de la documentación

exhaustiva: la documentación es necesaria dado que permiten la
transferencia del conocimiento, pero su redacción debe limitarse a aquello
que aporte valor directo al producto/servicio.
c) Valorar la colaboración con el cliente, por encima de la negociación

contractual: si bien son necesarios, los contratos no aportan valor a los
productos/servicios. Las metodologías ágiles integran al cliente en el
proyecto y mantienen como objetivo aportar el mayor valor posible en cada
iteración.
d) Valorar la respuesta al cambio, por encima del seguimiento de un plan:

Anticipación y adaptación enfrente de planificación y control.
A partir de los 4 valores básicos se pueden extraer diversos principios que

matizan la filosofía detrás de la gestión ágil:
a) La principal prioridad es satisfacer al cliente mediante entregas tempranas

y continuas de valor: periodos de 15 a 60 días.
b) Los requisitos cambiantes son bienvenidos.

15
c) Integración de los conocedores del negocio en el propio proyecto.
d) La motivación y el talento son aspectos clave, por tanto la confianza y el

apoyo al equipo humano es fundamental.
e) Potenciar las conversaciones en persona por encima de la comunicación

escrita.
El producto funcional (p.ej. software operativo) es la principal medida del

progreso: centrar el interés en el grado de finalización funcional o el tiempo
previsto de finalización, no en el tiempo transcurrido contra el planificado.
2.2.3. Costo de los Cambios en Proyectos de Software

Una de los problemas más críticos en los proyectos de software es el costo en
el que se incurre cuando se tiene que realizar cambios, esto se manifiesta de
manera más notoria cuando se utilizan metodologías tradicionales como: RUP,
UML, etc., en donde los cambios que se realizan en el proyecto es determinante
en el éxito del mismo en la medida que se realice en etapas tempranas del
proyecto, realizar cambios en las etapas finales pueden ocasionar el fracaso
del proyecto. En la siguiente figura se muestra una comparación entre los
costos del cambio que requieren las metodologías tradicionales y las
metodologías ágiles.
Figura 2.1: Comparación de costos del cambio usando metodologías tradicionales

y metodologías ágiles en proyectos de software.
Metodologías
tradicionales
Costo del Cambio
Metodologías
Ágiles
Requerimientos Análisis Diseño Implementación Prueba Producción
Fuente: Internet.
16
Como se aprecia los costos del cambio en las metodologías tradicionales van
incrementándose de manera exponencial a medida que vamos avanzando en
el desarrollo de un proyecto de software, por otro lado las metodologías ágiles
demandan altos costos al inicio del proyecto que luego muestran un
comportamiento de crecimiento asintótico lo cual permite que los costos del
cambio en el proyecto se incrementen de manera moderada a medida que se
avanza en el desarrollo del proyecto.
2.2.4. Extreme Programming (XP)

Extreme Programming es una metodología ágil muy exitosa porque hace
hincapié en la satisfacción del cliente y permite a los desarrolladores
responder con confianza a las necesidades cambiantes de los clientes, incluso
al final del ciclo de vida.
Los programadores extremos en constante comunicación con sus clientes y

colegas programadores. Mantienen su diseño simple y limpio. Reciben
retroalimentación probando su software a partir del primer día. Entregan el
sistema a los clientes tan pronto como sea posible y poner en práctica los
cambios como se sugiere. En la figura 2.2 se muestra el diagrama de fuljo de
un proyecto desarrollado con la metodología Extreme Programming.
Figura 2.2: Diagrama de flujo de un proyecto con la metodología Extreme

Programming
PROYECTO EXTREME PROGRAMMING

Escenarios de prueba
Historias de
Nueva historia de usuario
Usuario
requerimientos Velocidad del proyecto Bugs
Sistema Plan de Última Aprobación

Architectural Metáfora Planeamiento de lanzamientos Pruebas de del cliente Pequeños
Iteración Versión
Spike Lanzamientos aceptación lanzamientos
Estimaciones Estimaciones
Inciertas. Seguras.
Spike
Fuente: Extreme Programming ORG.

17
2.2.5. Reglas, Pautas, Normas de un Proyecto Extreme Programming
La siguiente Figura 2.3 muestra las directrices que se deben seguir en cada
proceso del proyecto utilizando Extreme Programming5.
Figura 2.3: Reglas, pautas, normas de un Proyecto Extreme Programming.
PLANEAMIENTO
 Se escriben las Historias de Usuario.
 El Planeamiento de Lanzamientos crea el
Cronograma de lanzamientos.
 Realizar Pequeños Lanzamientos CODIFICACION
frecuentemente.  El cliente está siempre disponible.
 El Planeamiento de la Iteración inicia cada  El código debe estar escrito de acuerdo a
iteración. estándares.
 Codifica primero las pruebas unitarias.
ADMINISTRACION
 Toda la producción del código es programado
 Brindar al equipo un espacio abierto de trabajo. en pares.
 Establecer un ritmo sostenible.  Instalar una computadora de integración
 Las reuniones a pie inicia cada día. dedicada.
 La velocidad del proyecto es medida.  Usar la propiedad colectiva.
 Mover a la gente.
 Arreglar XP cuando se rompe. PRUEBAS
 Todo el código debe tener pruebas unitarias.
DISEÑO
 Todo el código debe pasar todas la pruebas
 Simplicidad. unitarias antes de poder ser lanzadas..
 Escoger un Sistema Metáfora.  Cuando se encuentra un bug se crean las
 Usar tarjetas CRC para diseñar sesiones. pruebas.
 Crear Spike Solutions para reducir el riesgo.  Las pruebas de aceptación son realizadas
 No se añaden funcionalidades prematuras. frecuentemente y las puntuaciones
 Refactorizar cuando y donde sea posible. publicadas.

A. Planeamiento (Planning)
 Historias de Usuario (User stories)
Las Historias de Usuario tienen el mismo propósito que los Casos de

Uso de la metodología UML, pero no son la misma. Se utilizan para
crear las estimaciones de tiempo para la reunión de planificación de
entregas. También se utilizan en lugar de una excesiva
documentación. Las Historias de Usuario son escritas por los clientes
como las cosas que el sistema necesita para hacer por ellos,
evitando el uso de alguna sintaxis o uso de términos tecnológicos
5
Según Don Wells. Disponible en www.extremeprogramming.org
18
específicos. En la Figura 2.4 siguiente se muestra un formato para la
elaboración de las Historias de Usuario.
Figura 2.4: Formato para la elaboración de las Historias de Usuario.
Historia de Usuario
Número: Usuario:
Nombre historia:
Prioridad en negocio: Riesgo en desarrollo:
Puntos estimados: Iteración asignada:

Programador responsable
Descripción:
Observaciones:
 Planificación de Lanzamiento (Release Planning)
Una reunión de planificación de entregas o lanzamientos se utiliza

para crear un Plan de Lanzamiento, que establece el proyecto en
general. El plan de lanzamiento se utiliza para crear planes de
iteración para cada iteración individual.
Es importante para los técnicos para tomar las decisiones técnicas y

gente de negocios para tomar las decisiones de negocio. La
planificación de lanzamiento tiene un conjunto de reglas que permite
a todos los involucrados con el proyecto de tomar sus propias
decisiones. Las reglas definen un método para negociar un
calendario donde todos pueden comprometerse.
La esencia de la reunión de planificación de los lanzamientos para el

equipo de desarrollo es para estimar cada historia de usuario en
términos de semanas de programación ideales. Una semana ideal es
el tiempo que usted se imagina que se necesitaría para poner en
práctica esa historia. El cliente decide qué historia es la más
importante o tiene la más alta prioridad para ser completado.
Historias de usuario se imprimen o escritas en las tarjetas. Junto a

los desarrolladores y los clientes a moverse en torno a las cartas en
una mesa grande para crear un conjunto de historias que se
ejecutarán como el primer (o siguiente) lanzamiento.
19
 Pequeños Lanzamientos (Small Releases)
El equipo de desarrollo necesita liberar o lanzar versiones repetidas

del sistema a los clientes a menudo. Algunos equipos despliegan un
nuevo software en producción todos los días. Por lo menos se tendrá
que obtener el nuevo software en producción cada semana o dos. Al
final de cada iteración habrá probado su funcionamiento y quedado
listo para la producción de software y para demostrar a sus clientes.
La decisión de ponerlo en producción es de ellos.
La reunión de planificación de entregas se utiliza para planificar las

pequeñas unidades de funcionalidad que hacen un buen negocio y
pueden ser liberados en el entorno del cliente al principio del
proyecto. Esto es fundamental para conseguir información valiosa en
el momento de tener un impacto en el desarrollo del sistema. Cuanto
más tiempo espere para introducir una característica importante para
los usuarios del sistema, menos tiempo tendrá que arreglarlo.
 Iteraciones
El desarrollo iterativo agrega agilidad al proceso de desarrollo. Se

aconseja dividir el calendario de desarrollo en más o menos una
docena de repeticiones de 1 a 3 semanas de duración. Una semana
es la mejor opción a pesar de que parece muy corto. Mantener la
longitud de iteración constante durante todo el proyecto es el ritmo
del proyecto. Es esta constante que hace la medición del progreso y
la planificación sencilla y fiable en XP.
Es importante no programare las tareas de programación con

antelación, en lugar de ello tener una reunión de planificación al
principio de cada iteración para planificar lo que se hará. La
Planificación justo a tiempo (Just in) es una manera fácil de estar al
tanto de los requerimientos cambiantes de los usuarios.
También es contraproducente tratar de implementar algo que no está

previsto para una iteración. Habrá un montón de tiempo para
implementar esa funcionalidad cuando se convierte en la historia más
importante en el plan de lanzamiento.
20
Entonces es necesario tomar los plazos de iteración en serio, realizar
el seguimiento del progreso durante una iteración. Si parece que no
va terminar todas las tareas entonces llamar a otra reunión de
planificación de la iteración, re- estimación, y eliminar algunas de las
tareas.
Concentre su esfuerzo en completar las tareas más importantes

elegidos por su cliente, en lugar de tener varias tareas sin terminar
elegidas por los desarrolladores.
En la Figura 2.5 se muestra el esquema XP que guía las iteraciones

realizadas sobre el desarrollo del proyecto.
Figura 2.5: Iteración Extreme Programming.
Iteración
Nueva historia de usuario,

Velocidad del Proyecto
Plan de
Tareas no Aprender y
lanzamiento finalizadas
Historias de usuario comunicar
Nueva
funcionalidad
Siguiente Velocidad del Plan de
proyecto Planeamiento de iteración Última
Iteración Desarrollo
Iteración versión
Reparar bugs
Bugs
Última
Versión

 Planificación de la Iteración (Iteration Planning)
Una reunión de planificación de la iteración se llama al principio de

cada iteración para producir el plan de las tareas de programación
de esa iteración. Cada iteración es de 1 a 3 semanas. Las historias
de usuario son elegidos para esta iteración por el cliente desde el
plan de lanzamiento con el fin de realizar las más valiosas para el
cliente primero. El cliente selecciona las historias de usuario con las
21
estimaciones que se sumarán al total de la velocidad del proyecto a
partir de la última iteración.
Las tareas a desarrollar están escritas en tarjetas como las historias

de usuario. Si bien las historias de usuario se encuentran en el idioma
del cliente, las tareas están en el idioma del programador. Las tareas
duplicadas se pueden eliminar en este punto.
B. ADMINISTRACION (Managing)
 Espacio Abierto Dedicado (Give The Team A Dedicated Open
Workspace)
La comunicación es muy importante para un equipo de programación

extrema (XP). Las rutas de comunicación son vitales para su equipo
y disponer los equipos de cómputo necesarios en un área central del
que nadie es dueño hace la programación en parejas más fácil y
anima a la gente a trabajar juntos con igualdad de valor de sus
contribuciones. Se recomienda disponer unas cuantas mesas
alrededor del perímetro que le da al equipo un lugar para trabajar
solos sin convertirse desconectados del resto del equipo.
Es necesario la inclusión de una amplia zona para las reuniones de

pie diarias para no aislar a alguno de los miembros del equipo. Se
puede adicionar de una mesa de conferencias que le ofrece un hogar
para las discusiones de grupo que se producen de forma espontánea
a lo largo del día. Ser capaz de ver las discusiones anima a la gente
a escuchar o unirse a la discusión.
Adición de tablas blancas para bocetos y notas importantes o

paredes en blanco donde las tarjetas de historia de usuario pueden
ser grabadas añade aún más canales de comunicación. Añadir un
par de grandes cartas dirigidas a la mejora de procesos o el progreso
del proyecto informa al equipo de gestión sin perseguir ellos sobre el
progreso.
 Establecer un Ritmo Sostenible, Medible y Predecible (Set A

Sustainable, Measurable, Predictable Pace)
22
El software incompleto o con errores representa una cantidad
desconocida de esfuerzo futuro, por lo que no se puede medir. Si
parece que el equipo no será capaz de obtener todo las
características al final de la iteración se recomienda realizar una
reunión de planificación de la iteración y re-alcance la iteración para
maximizar su velocidad de proyecto. Incluso si hay sólo un día de
plazo en la iteración es mejor conseguir que todo el equipo se re-
enfoque en una sola tarea completada de muchas otras incompletas.
 Las Reuniones de Pie Inician Cada Dia (A Stand Up

Meeting Starts Each Day.)
En una reunión típica proyecto la mayoría de los asistentes no

contribuyen, pero asisten sólo para escuchar el resultado. Una gran
cantidad de tiempo de desarrollo se desperdicia para obtener una
cantidad trivial de la comunicación.
La comunicación entre todo el equipo es el propósito de la reunión

de pie. La reunión a pie cada mañana se utiliza para comunicar
problemas, soluciones, y promover el enfoque de equipo. Todo el
mundo se pone de pie en un círculo para evitar largas discusiones.
Es más eficaz tener una breve reunión que se requiere de cada uno
para asistir a muchas reuniones con unos pocos desarrolladores
cada una.
 Velocidad del Proyecto ( Project Velocity)
La velocidad de proyecto es una medida de la cantidad de trabajo en

su proyecto. Para medir la velocidad del proyecto sólo tiene que
sumar las estimaciones de los casos de usuario que se terminaron
durante la iteración.
 Mover a la Gente (Move People Around)
Mover a la gente evitar la pérdida de conocimiento y cuellos de

botella. Si sólo hay una persona de su equipo puede trabajar en un
área determinada y esa persona deja o simplemente tiene
demasiadas cosas que hacer, se reducirá el progreso del proyecto.
23
El entrenamiento cruzado es a menudo una consideración
importante en las empresas que intentan evitar islas de
conocimiento, que son tan susceptibles a la pérdida. El movimiento
de personas alrededor de la base de código en combinación con la
programación en parejas hace su entrenamiento cruzado para el
proyecto. En lugar de una persona que lo sabe todo acerca de una
determinada sección de código, cada uno en el equipo sabe mucho
del código de cada sección.
Un equipo es mucho más flexible, si todo el mundo sabe lo suficiente

acerca de todas las partes del sistema para trabajar en él. En lugar
de tener unas pocas personas sobrecargadas de trabajo, mientras
que otros miembros del equipo tienen poco que ver, todo el equipo
puede ser productivo. Cualquier número de desarrolladores se puede
asignar a la parte más urgente del sistema. Todo esto se logra a
través de la programación en parejas y de la propiedad colectiva del
código que se muestra en la Figura 2.7.
 Reparar Xp Cuando se Rompe (Fix Xp When It Breaks)
Reparar el proceso cuando se rompe. Hacer algunos cambios para

su proyecto específico. Seguir las reglas de XP para empezar, pero
esto no impide el cambiar lo que no funciona. Esto no significa que
el equipo puede hacer lo que quieran. Las reglas deben ser seguidas
hasta que el equipo los ha cambiado. Todos los desarrolladores
deben saber exactamente qué esperar el uno del otro, tener un
conjunto de reglas es la única manera de establecer estas
expectativas.
Tener reuniones retrospectivas para hablar de lo que está

funcionando y qué no y encontrar formas de mejorar XP.
C. DISEÑO (DESIGN)
 Simplicidad
Un diseño simple siempre toma menos tiempo para terminar que una
uno complejo. Siempre es más rápido y más barato para reemplazar
el código complejo ahora, que perder mucho más tiempo en él.
24
La simplicidad siempre desafía la medición, ya que es una cualidad
muy subjetiva. La incorporación de una tecnología avanzada puede
simplificar una aplicación y hacer un completo desastre de otro. Se
recomienda las siguientes cuatro cualidades para lograr la
simplicidad: comprobable, comprensible, navegables y explicable.
Comprobable significa que usted puede escribir pruebas unitarias y

pruebas de aceptación para comprobar automáticamente si hay
problemas. Esto afecta el diseño general y el acoplamiento de los
objetos de la aplicación. Se recomienda dividir su sistema en
pequeñas unidades comprobables.
Navegable es la cualidad de ser capaz de encontrar lo que usted

desea cuando usted lo desee. Los buenos nombres le ayudan a
encontrar las cosas. Utilización de polimorfismo, la delegación y la
herencia correctamente ayuda a encontrar las cosas cuando es
necesario.
Comprensible es obvio, pero muy subjetivo. Un equipo que ha estado

trabajando con un sistema de mucho tiempo lo entenderá a pesar de
que a alguien nuevo está completamente desconcertado. Así que yo
también se recomienda el concepto de explicable como una cualidad
que significa que es fácil de mostrar a la gente nueva cómo funciona
todo.
 Sistema Metáfora
El Sistema Metáfora es en sí una metáfora de un diseño simple con

ciertas cualidades. La cualidad más importante es ser capaz de
explicar el diseño del sistema para las personas nuevas sin recurrir
a enormes documentos en ellos. Un diseño debe tener una estructura
que ayuda a las personas nuevas comienzan contribuyendo
rápidamente. La segunda cualidad es un diseño que hace nombrar
las clases y métodos consistentes.
Como se designa el nombre de los objetos es muy importante para

entender el diseño global del sistema y la reutilización de código
también. Ser capaz de adivinar lo que algo podría ser nombrado si
ya existía y estar en lo correcto la mayor parte del tiempo es un gran
25
ahorro de tiempo. Elija un sistema de nombres de los objetos con el
que todo el mundo puede relacionarse.
 Utilizar tarjetas CRC
Utilice las tarjetas de Clase, Responsabilidades y Colaboración

(CRC) para diseñar el sistema en equipo. El mayor valor de las
tarjetas CRC es permitir a la gente apartarse de pensamiento del
modo de procedimientos y más plenamente aprecian la tecnología
de objetos. Tarjetas CRC permiten que equipos enteros de proyectos
para contribuir al diseño. Cuantas más personas que pueden ayudar
a diseñar el sistema mayor es el número de buenas ideas
incorporadas.
Las Tarjetas de CRC se utilizan para representar objetos. La clase

del objeto puede ser escrito en la parte superior de la tarjeta, las
responsabilidades que se enumeran en la parte izquierda, las clases
colaboradoras se listan a la derecha de cada responsabilidad.
Decimos " pueden ser escritos" porque una vez que una sesión de
CRC está en pleno apogeo los participantes por lo general sólo
necesita unas cuantas tarjetas con el nombre de clase y
prácticamente no hay tarjetas escritas a cabo en su totalidad. En la
Figura 2.6 siguiente se muestra un ejemplo de las tarjetas CRC.
Figura 2.6: Tarjetas CRC
Fuente: internet.
26
 Spike Solutions
Crear soluciones de punta para averiguar las respuestas a difíciles

problemas técnicos o de diseño. Una solución pico es un programa
muy sencillo de explorar posibles soluciones. Construir el pico sólo
aborda el problema objeto de examen y pasar por alto todas las
demás preocupaciones. La mayoría de los picos no son lo
suficientemente buenos para mantener, por lo que se espera
desecharlo. El objetivo es reducir el riesgo de un problema técnico o
de aumentar la fiabilidad de la estimación de una historia de usuario.
Cuando una dificultad técnica amenaza con retrasar el desarrollo

del sistema de poner un par de desarrolladores en el problema
durante una semana o dos, y reducir el riesgo potencial.
 Refactorizar
Usualmente los programadores de computadoras nuestros se

aferran a sus diseños de software mucho después de que se han
convertido en difícil de manejar. Seguimos en utilizar y reutilizar el
código que ya no es fácil de mantener, ya que todavía funciona de
alguna manera y que tienen miedo de modificarlo. Pero ¿es
realmente rentable para hacerlo? Extreme Programming (XP)
mantiene la postura de que no lo es. Cuando eliminamos la
redundancia, eliminar la funcionalidad sin uso, y rejuvenecer los
diseños obsoletos estamos refactorizando. La refactorización se
realiza a lo largo de todo el ciclo de vida del proyecto y ahorra tiempo
y aumenta la calidad.
Entonces es necesario Refactorizar sin temores para mantener el

diseño simple sobre la marcha y para evitar el desorden y la
complejidad innecesaria para mantener su código limpio y conciso
por lo que es más fácil de entender, modificar y ampliar.
D. CODIFICACIÓN (coding)
 El Cliente está siempre presente
Uno de los pocos requisitos de la programación extrema (XP) es

hacer que el cliente esté disponible. No sólo para ayudar al equipo
de desarrollo, sino para ser una parte de ella también. Todas las
27
fases de un proyecto de XP requieren la comunicación con el cliente,
preferiblemente frente a frente (in situ). Lo mejor es simplemente
asignar uno o más clientes al equipo de desarrollo. Es necesario
tener cuidado, sin embargo, porque se pueden tener dificultades
cunado se asignan por parte del cliente a alguien principiante.
Las Historias de Usuario son escritas por el cliente, con los

desarrolladores para ayudar, para permitir que las estimaciones de
tiempo, y asignar prioridades. Los clientes ayudan a asegurar que la
mayor parte de la funcionalidad deseada del sistema está cubierto
por las historias.
 El Código debe estar escrito de acuerdo a estándares
El código debe tener el formato de estándares de codificación

acordados. Los estándares de codificación mantienen el código
consistente y fácil para todo el equipo.
 Codificar primero las pruebas unitarias
Al crear sus pruebas primero, antes del código, le resultará mucho

más fácil y más rápido al desarrollador para crear su código. La
creación de una unidad de prueba ayuda a un desarrollador para
considerar realmente lo que hay que hacer. Si creamos nuestras
pruebas de unidad primero entonces sabremos cuando se ha
terminado, cuando en la unidad a prueba todos las características
pasan.
 Programación en parejas
Todo el código que se enviará a la producción es creada por dos

personas que trabajan juntas en un solo equipo. La programación en
parejas incrementa la calidad del software sin impactar en el tiempo
para la entrega. Es contrario a la intuición, pero 2 personas que
trabajan en un solo equipo agregará tanta funcionalidad como dos
trabajando por separado, excepto que será mucho más alto en
calidad. Con el aumento de la calidad tiene un gran ahorro en
adelante en el proyecto.
28
 Instalar una computadora de Integración dedicada.
Un solo equipo dedicado al lanzamiento secuencial funciona muy

bien cuando el equipo de desarrollo es co - localizado. Este equipo
actúa como una muestra física para controlar la liberación. Los
desarrolladores tienen una fuente para el arbitraje final sobre los
problemas de integración. El ordenador permite a los desarrolladores
para ver cuál es el lanzamiento y cuándo. Cuando el equipo de
lanzamiento está ocupado otros cambios pueden ser lanzados, se
garantiza la estabilidad.
El último conjunto de pruebas de unidad combinada se puede

ejecutar antes de liberarla. Debido a que una sola computadora se
utiliza el conjunto de pruebas está siempre al día. Si las pruebas de
unidad funcionan a 100 % se confirman los cambios, si no logran los
cambios se depuran.
 Usar la Propiedad Colectiva
La Propiedad Colectiva del código anima a todos a contribuir con

nuevas ideas para todos los segmentos del proyecto. Cualquier
desarrollador puede cambiar alguna línea de código para agregar
funcionalidad, corregir los errores, mejorar los diseños o refactorizar.
Una sola persona no se convierte en un cuello de botella para los
cambios. Esto es difícil de entender al principio porque es casi
inconcebible que un equipo entero puede ser responsable del diseño
del sistema. Además la propiedad colectiva del código propicia el
entrenamiento cruzado (Cross training) de este modo se evitan las
denominadas “Islas de conocimiento” que puede demorar el
desarrollo del proyecto por indisposiciones de los miembros del
equipo o en general por problemas externos que afecten a los
miembros. A continuación en la Figura 2.7 se muestra el esquema
de la Propiedad Colectiva del Código para un proyecto XP
desarrollada por Don Wells6.
6
Autor de la página www.extremeprogramming.org
29
Figura 2.7: Propiedad colectiva del código

Elaboración: Estreme Programming ORG.
E. PRUEBAS (Testing)
 Todo el código debe tener pruebas unitarias
Las pruebas unitarias son una de las piedras angulares de la

Programación Extrema (XP). Pero el estilo pruebas unitarias XP es
un poco diferente. En primer lugar se debe crear o descargar un
marco de prueba de unidad para poder crear pruebas unitarias
automatizadas. En segundo lugar se debe probar todas las clases en
el sistema. Métodos getter y setter que normalmente se omiten.
También se crean sus pruebas en primer lugar, antes de que el
código.
 Todo el código pasar todas las pruebas unitarias antes de ser

lanzado.
 Cuando se encuentra un Bug se crea las pruebas
 Las pruebas de aceptación son realizadas frecuentemente y
los puntajes publicados.
Las pruebas de aceptación se crean a partir de historias de usuario.

Durante una iteración las historias de usuarios seleccionados
durante la reunión de planificación de la iteración se traducirán a las
pruebas de aceptación. El cliente especifica escenarios para poner a
30
prueba cuando una historia de usuario se ha implementado
correctamente. Una historia puede tener una o varias pruebas de
aceptación, lo que sea necesario para garantizar las obras de
funcionalidad.
Los clientes son responsables de verificar la exactitud de las pruebas

de aceptación y revisión de resultados de las pruebas para decidir
cuales no pasaron las pruebas y son de mayor prioridad. Las pruebas
de aceptación también se utilizan como pruebas de regresión antes
de una versión de producción.
Una historia de usuario no se considera completa hasta que ha

pasado sus pruebas de aceptación. Esto significa que las nuevas
pruebas de aceptación se deben crear cada iteración o el equipo de
desarrollo se reportarán los avances cero.
2.2.6. Roles XP7

A. Programador
 Pieza básica en desarrollos XP.
 Más responsabilidad que en otros modos de desarrollo.
 Responsable sobre el código.
 Responsable sobre el diseño (refactorización, simplicidad).
 Responsable sobre la integridad del sistema (pruebas).
 Capacidad de comunicación.
B. Cliente
 Pieza básica en desarrollos XP.
 Define especificaciones.
 Influye sin controlar.
 Confía en el grupo de desarrollo.
 Define pruebas funcionales.
C. Encargado de Pruebas
 Apoya al cliente en la preparación/realización de las pruebas
funcionales.
 Ejecuta las pruebas funcionales y publica los resultados.
7
https://sites.google.com/site/xpmetodologia/marco-teorico/roles
31
D. Encargado de Seguimiento (Tracker)
 Recoge, analiza y publica información sobre la marcha del proyecto
sin afectar demasiado el proceso.
 Supervisa el cumplimiento de las estimaciones en cada iteración.
 Informa sobre la marcha de la iteración en curso.
 Controla la marcha de las pruebas funcionales, de los errores
reportados, de las responsabilidades aceptadas y de las pruebas
añadidas por los errores encontrados.
E. Entrenador (Coach)
 Experto en XP.
 Responsable del proceso en su conjunto.
 Identifica las desviaciones y reclama atención sobre las mismas.
 Guía al grupo de forma indirecta (sin dañar su seguridad ni
confianza).
 Interviene directamente si es necesario.
F. Consultor
 Apoya al equipo XP en cuestiones puntuales.
G. Jefe del Proyecto

 Favorece la relación entre usuarios y desarrolladores.
 Cubre las necesidades del equipo XP.
 Asegura que alcanza sus objetivos.
2.2.7. Valores de un Proyecto Extreme Programming

Los Valores originales de la programación extrema son: simplicidad,
comunicación, retroalimentación (feedback), coraje y, últimamente añadido,
respeto que se detallan a continuación:
A. Simplicidad:
La simplicidad es la base de la programación extrema. Se simplifica el
diseño para agilizar el desarrollo y facilitar el mantenimiento. Un diseño
complejo del código junto a sucesivas modificaciones por parte de
diferentes desarrolladores hace que la complejidad aumente
exponencialmente. También se aplica la simplicidad en la
documentación, de esta manera el código debe comentarse en su justa
32
medida, intentando eso sí que el código esté autodocumentado. Para ello
se deben elegir adecuadamente los nombres de las variables, métodos y
clases.
B. Comunicación:
La comunicación se realiza de diferentes formas. Para los programadores
el código comunica mejor cuanto más simple sea. La comunicación con
el cliente es fluida ya que el cliente forma parte del equipo de desarrollo.
El cliente decide qué características tienen prioridad y siempre debe estar
disponible para solucionar dudas.
C. Retroalimentación:
Al estar el cliente integrado en el proyecto, su opinión sobre el estado del
proyecto se conoce en tiempo real. Al realizarse ciclos muy cortos tras
los cuales se muestran resultados, se minimiza el tener que rehacer
partes que no cumplen con los requisitos y ayuda a los programadores a
centrarse en lo que es más importante.
D. Coraje o valentía:
Muchas de las prácticas implican valentía. Una de ellas es siempre
diseñar y programar para hoy y no para mañana. La valentía le permite a
los desarrolladores que se sientan cómodos con reconstruir su código
cuando sea necesario. Esto significa revisar el sistema existente y
modificarlo si con ello los cambios futuros se implementaran más
fácilmente. Otro ejemplo de valentía es saber cuándo desechar un
código.
E. Respeto:
El respeto se manifiesta de varias formas. Los miembros del equipo se
respetan los unos a otros, porque los programadores no pueden realizar
cambios que hacen que las pruebas existentes fallen o que demore el
trabajo de sus compañeros. Los miembros del equipo respetan el trabajo
del resto no haciendo menos a otros, una mejor autoestima en el equipo
y elevando el ritmo de producción en el equipo.
2.2.8. Sistema Gestor de Base de Datos.

En esencia es una agrupación de programas que sirven para definir, construir
y manipular una base de datos la misma que es un contenedor de datos
relacionados que dependiendo de los propósitos brinda información.
33
2.2.8.1. Operaciones Sobre Bases de Datos
A. Definir una Base de Datos:

Consiste en especificar los tipos de datos, estructuras y restricciones para
los datos que se almacenarán.
B. Construir una Base de Datos

Es el proceso de almacenar los datos sobre algún medio de
almacenamiento.
C. Manipular una Base de Datos:

Incluye funciones como consulta, actualización, etc. de bases de datos.
2.2.8.2. Otras funciones de los SGBD.
A. En la manipulación de una base de datos, los SGBD deben incluir un

control de concurrencia, o sea, deben permitir a varios usuarios tener
acceso "simultáneo" a la base de datos. Controlar la concurrencia
implica que si varios usuarios acceden a la base de datos, la
actualización de los datos se haga de forma controlada para que no
haya problemas.
B. Un SGBD también debe encargase de cumplir las reglas

de integridad y redundancias.
C. Otra función importante en un SGBD es su capacidad de

realizar copias de seguridad y de recuperación de datos.
D. Restricción de accesos no autorizados.
E. Suministrar múltiples interfaces de usuario.
F. Representar relaciones complejas entre los datos.
2.2.8.3. Clasificación de los SGBD.
A. De Acuerdo al Modelo de Datos

Esta clasificación está basada en el modelo de datos en que está basado
el SGBD. Los modelos de datos más habituales son:
 Relacional (SGBDR): representa a la base de datos como una
colección de tablas. Estas bases de datos suelen utilizar SQL como
lenguaje de consultas de alto nivel.
34
 Orientado a Objetos: define a la base de datos en términos
de objetos, sus propiedades y sus operaciones. Todos los objetos
que tienen la misma estructura y comportamiento pertenecen a una
clase y las clases de organizan en jerarquías.
 Objeto-Relacional o Relacional Extendido: son los sistemas
relacionales con características de los orientados a objetos.
 Jerárquico: representa los datos como estructuras jerárquicas

de árbol.
B. De Acuerdo al Número de Usuarios

Un SGBD también puede clasificarse por el número de usuario a los que
da servicio:
 Monousuario
 Multiusuario
C. De Acuerdo a su Distribucion Física

También puede clasificarse según el número de sitios en los que está
distribuida la base de datos:
 Centralizado: la base de datos y el software SGBD están

almacenados en un solo sitio (una sola computadora).
 Distribuido (SGBDD): la base de datos y el software SGBD pueden

estar distribuidos en múltiples sitios conectados por una red.
2.2.9. Plataforma Tecnológica

A. Hibernate
Hibernate es una herramienta de Mapeo objeto-relacional para
la plataforma Java que facilita el mapeo de atributos entre una base de
datos relacional tradicional y el modelo de objetos de una aplicación,
mediante archivos declarativos (XML) o anotaciones en los beans de las
entidades que permiten establecer estas relaciones.Hibérnate es software
libre, distribuido bajo los términos de la licencia GNU LGPL.
Como todas las herramientas de su tipo, Hibernate busca solucionar el

problema de la diferencia entre los dos modelos de datos coexistentes en
una aplicación: el usado en la memoria de la computadora (orientación a
objetos) y el usado en las bases de datos (modelo relacional). Para lograr
35
esto permite al desarrollador detallar cómo es su modelo de datos, qué
relaciones existen y qué forma tienen. Con esta información Hibérnate le
permite a la aplicación manipular los datos de la base operando sobre
objetos, con todas las características de la POO. Hibernate convertirá los
datos entre los tipos utilizados por Java y los definidos por SQL. Hibérnate
genera las sentencias SQL y libera al desarrollador del manejo manual de
los datos que resultan de la ejecución de dichas sentencias, manteniendo
la portabilidad entre todos los motores de bases de datos con un ligero
incremento en el tiempo de ejecución.
Hibernate está diseñado para ser flexible en cuanto al esquema de tablas

utilizado, para poder adaptarse a su uso sobre una base de datos ya
existente. En la figura 2.8, se distingue Hibérnate en la entre Aplicación y la
Base de Datos. Se ubica sobre el JDBC controlando las conexiones y las
consultas basadas en el mapeo de los Bean en archivos “.XML” o en las
anotaciones sobre los JavaBeans.
Figura 2.8 Contexto de Hibérnate en una aplicación Java.
Aplicación
(POJO,DAO)
(POJO,DAO)
JavaBeans
JavaBeans
Mapping
file
Database
Hibernate. Hibernate dialetc
properties Hibernate .cfg.xml
JDBC APIs Base de Datos
Fuente: JBoosCommunity
Elaboracion:Propia.
36
2.2.10. Modelo Aplicativo
El modelo aplicativo comprende la secuencia de pasos de la aplicación
metodológica, en la figura 2.9 se muestra el esquema a seguir basados en los
conceptos desarrollados hasta este punto.
Figura 2.9 Modelo Aplicativo.
1 - ADMINISTRACION
3 - DISEÑO
2 - PLANEAMIENTO 4 - CODIFICACION
6 - LANZAMIENTOS
5 - PRUEBAS
Fuente: Proyecto de Investigación.

El modelo aplicativo corresponde a los conceptos desarrollados en el marco de la

metodología Extreme Programming, que es un diagrama general que abarca todas
las fases del proyecto, el cual tiene como inicio la Administración, donde podemos
encontrar las tareas necesarias de coordinación para la dotación del espacio de
trabajo para el equipo en la organización y de supervisión de la aplicación en los
parámetros de la metodología, resguardando que no se aleje el equipo de estos
tomando medidas pertinentes. A continuación la fase de planeamiento en donde se
recogen los requerimientos del software o sistema informático, se establecen los
plazos iniciales de entrega de acuerdo a las estimaciones que se realicen al adoptar
soluciones potencialmente satisfactorias como prototipos. Luego la fase de diseño
en la cual se realizará el modelamiento de la base de datos y las interfaces de
37
usuario y pasar a la fase de codificación en la cual se entregará al cliente la última
versión del software desarrollado, la misma que debe ser contrastado con las
Historias de Usuario inicial. Dependiendo de la aceptación de las versiones del
software desarrollado se realizaran los lanzamientos de las características del
software en caso sea favorable, de lo contrario se corregirán los ¨Bugs¨, lo cual
afectará la velocidad del proyecto y las Historias de Usuario que podrían ser
modificadas y regresamos a la fase de planeamiento para replantear las
características de los requerimientos que hayan sido aceptados.
2.3. MARCO CONCEPTUAL

 Aplicación: Es el nombre que se le da a cierta implementación informática
construida a fin de satisfacer una necesidad o propósito.
 Codificación: La codificación es la acción de escribir instrucciones sobre
determinada herramienta o entorno de programación con el fin de conseguir un
resultado, objetivo o realizar acciones planteadas.
 Funcionalidad. La capacidad del producto de software para proveer las
funciones que satisfacen las necesidades explícitas e implícitas cuando el
software se utiliza bajo condiciones específicas.
 Información: Es un conjunto de datos organizados y procesados que
constituyen un mensaje de tal manera que cambia el conocimiento del sujeto o
sistema que recibe el mensaje.
 Implementación: Es la realización de una especificación técnica o algoritmos
como un programa, componente software, u otro sistema de cómputo.
 Lanzamiento: Es la puesta en producción de una característica o
implementación.
 Metodología: hace referencia al conjunto de procedimientos racionales
utilizados para alcanzar una gama de objetivos que rigen una investigación
científica, una exposición doctrinal o tareas que requieran habilidades,
conocimientos o cuidados específicos.
 Mapeo Objeto-Relacional: Es una técnica de programación para convertir
datos entre el sistema de tipos utilizado en un lenguaje de
programación orientado a objetos y la utilización de una base de datos
relacional, utilizando un motor de persistencia.
 Modelo de datos: Permite describir los elementos de la realidad que intervienen
en un problema dado y la forma en que se relacionan esos elementos entre sí.
 Plataforma: Es un sistema que sirve como base para hacer funcionar
determinados módulos de hardware o de software con los que es compatible.
38
 Requerimientos. Solicitud a funcionalidades que el software en desarrollo
deben satisfacer.
 Retroalimentación: Consiste en tomar información de los resultados de
determinado proceso para usarla en la nueva ejecución del mismo a fin de
ajustar los parámetros internos para lograr el objetivo.
La información respecto a investigaciones a fines desarrollados hasta este punto soportan

con suficiencia la presente investigación por cuanto obtuvieron resultados satisfactorios en
situaciones concretas y de diversa índole. La aplicación de métodos similares en las
diferentes situaciones da cuenta que este tipo de investigaciones y proyectos
implementados están adquiriendo un gran protagonismo como alternativa seria a los
métodos más rigurosos y tradicionales. Otro punto resaltante es la adopción de las
herramientas, plataformas tecnológicas y practicas establecidas ya que cuentan con gran
acogida a todo nivel en el ámbito empresarial, de esta manera es de esperarse que el
resultado de la implementación del software sea de gran aceptación.
39
CAPÍTULO III
INTERVENCIÓN METODOLÓGICA
El presente capitulo trata sobre la aplicación de los conceptos desarrollados en el capítulo

anterior para poder ver los resultados que se obtienen después de haber sido
implementados siguiendo el modelo aplicativo planteado en el capítulo anterior.
3.1. ADMINISTRACIÓN
En esta fase considerara en la presente investigación como la inicial basados en
los conceptos y modelo planteado por Son Wells, se llevan a cabo las siguientes
tareas:
Brindar al equipo de trabajo un espacio abierto en la cual trabajar, que se realizó en

coordinación con el cliente, de esta manera se garantizó que el acceso a los
ambientes y la información necesarios.
Coordinar las reuniones diarias para mantener a todo el equipo y el cliente del
estado en el que se encontraba el proyecto, de esta manera se pudo evitar o
solucionar contratiempos y también establecer el ritmo del proyecto que fuera
adecuado para el proyecto.
Se coordinó con el equipo de trabajo para la movilización de los miembros a fin

cumplir con la propiedad comunitaria del código, realizar el entrenamiento cruzado
y así evitar las islas de conocimiento. También se efectuó la supervisión del
cumplimiento de los parámetros de la metodología Extreme Programming a fin de
corregir falencias que alejara al grupo de trabajo de las directrices establecidas.
3.2. PLANIFICACION
En esta fase se desarrollaron, siguiendo las pautas de un proyecto Extreme
Programming y el modelo aplicativo, las siguientes actividades:
40
3.2.1. Establecimiento de las Historias de Usuario
El proyecto Extreme Programming, se inicia con el establecimiento de las
Historias de Usuario, que se detallan en las tablas siguientes.
Tabla 3.1 Historia de Usuario Nº 01.

Historia de Usuario
Número: 1 Usuario: RESPONSABLE DE MEDICINA GENERAL
Nombre historia: REGISTRO DE PERSONAS
ALTA MEDIA
Puntos estimados: 5 Iteración asignada: 1
Programador responsable:
Descripción: SE DEBE REALIZAR EL REGISTRO DE NUEVOS PACIENTES Y EDICION DE LOS

REGISTROS DE LOS MISMOS, SE ESPECIFICA LOS DATOS PERSONALES COMO:
NOMBRES, APELLIDOS, NUMERO DE DNI, PROCEDENCIA
Observaciones:
Fuente: Desarrollo del proyecto.

Elaboración: Desarrollo del proyecto.
La implementación de la Historia de Usuario Nº 01 y las consecutivas suponen el

modelamiento de la base de datos y la implementación de la base de datos,
creación de clases e interfaces de usuario que se desarrollan más adelante.

Historia de Usuario
Nombre historia: REGISTRO DE NUEVAS ATENCIONES
ALTA MEDIA
Descripción: SE DEBE REALIZAR E REGISTRO DE LA ATENCION DE LA PERSONA

CONSGINANDO LA FECHA DE ATENCION Y LA FUENTE DE VERIFICACION (CODIGO DEL
REGISTRO FISICO)
Observaciones:

41
La tabla 3.2 anterior muestra la Historia de Usuario denominada ¨Registro de
nuevas atenciones¨ que mediante su implementación satisface el registro de nuevas
atenciones de las personas y los detalles generales de la misma.
Historia de Usuario
Nombre historia: LISTADO DE ENFERMEDADES SEGÚN EL CIE 10
ALTA MEDIA
Descripción: SE DEBE TENER A DISPOSICION EL LISTADO DE ENFERMEDADES DEL CIE

10 (CODIGO INTERNACIONAL DE ENFERMEDADES VERSION 10)
Observaciones:

La Historia de Usuario ¨Listado de enfermedades según el CIE 10¨ mostrado en la

tabla anterior 3.3 especifica la implementación en la base de datos del Clasificación
Internacional de Enfermedades elaborado por la Organización Mundial de la Salud
y que se utiliza para fines estadísticos de morbilidad y mortalidad, mediante la cual
se resuelve el problema de consignar con diferentes denominaciones a una misma
enfermedad.

Historia de Usuario
Nombre historia: LISTADO DE TRATAMIENTOS SEGÚN EL CIE 10
ALTA MEDIA
Descripción: SE DEBE TENER A DISPOSICION EL LISTADO DE LOS TRATAMIENTOS DEL

CIE 10 (CODIGO INTERNACIONAL DE ENFERMEDADES VERSION 10)
Observaciones:

42
La Historia de Usuario Nº 4 involucra la implementación correspondiente para poner
a disposición de los usuarios el listado de tratamientos que también están
estandarizados mediante el CIE 10, esto se realizó con el responsable del área a
fin de consignar los tratamientos más comunes a fin de no registrar toda la
información del CIE 10 ya que resulta muy tediosa.
Historia de Usuario
Nombre historia: LISTADO DE MEDICAMENTOS
ALTA MEDIA
Descripción: SE DEBE TENER A DISPOSICION EL LISTADO DE LOS MEDICAMENTOS

EXISTENTES.
Observaciones:

La Historia de Usuario Nº 05 involucra la implementación correspondiente al registro

de las existencias de medicamentos, donde se especifican la presentación,
concentración y el costo unitario.
Historia de Usuario
Nombre historia: HISTORIAL DE ATENCIONES
ALTA MEDIA
Descripción: SE DEBE TENER UN REGISTRO DE LAS ATENCIONES REALIZADAS EN

ORDEN CRONOLOGICO.
Observaciones:

43
La Historia de Usuario mostrada en la tabla 3.6 anterior hace referencia a la
implementación de un listado que muestre en orden cronológico las atenciones
realizadas, en relación con la especialidad del usuario (Medicina General,
Obstetricia, Odontología o Enfermería).

Historia de Usuario
Nombre historia: HISTORIAL MEDICO
ALTA MEDIA
Descripción: SE DEBE OBTENER EL HISTORIAL DE CUALQUIER PERSONA.
Observaciones:

En la tabla 3.7 se establece la Historia de Usuario que deberá cumplir la

implementación del software en cuanto a la obtención del Historial Médico de
cualquier paciente en particular.

Historia de Usuario
Nombre historia: CONSOLIDADO
ALTA MEDIA
Descripción: SE DEBE TENER UN REGISTRO CONSOLIDADO POR ORDEN ALFABETICO DE

LAS PERSONAS ATENDIDAS.
Observaciones:

44
Historia de Usuario
Nombre historia: REPORTE ESTADISTICO
ALTA MEDIA
Descripción: SE DEBE TENER UN REPORTE DE LAS ATENCIONES REALIZADAS POR

DIVERSOS CRITERIOS.
Observaciones:

Las tablas 3.8 y 3.9 establecen los requerimientos para la obtención de los reportes
estadístico y la obtención de reportes dependiendo de diversos criterios como: por
fechas, por procedencia, por sexo, etc.
3.2.2. Planificación de los Lanzamientos

Luego de haber establecido las Historias de Usuario se realiza la planificación de
lanzamientos o entregas, como resultado de esto se establece el Plan de
Lanzamientos. Luego de haber negociado con el cliente los alcances de cada
Historia de Usuario, es decir haber evaluado los riesgos, las prioridades y realizado
estimaciones basadas en los ¨Spike¨ se establece el plan mostrado en la Tabla 3.10
siguiente.
Tabla 3.10 Plan de Lanzamientos.
ITERACION
N NOMBRE DE HISTORIA
1 2 3
1 REGISTRO DE PERSONAS X
2 REGISTRO DE NUEVAS ATENCIONES X
3 LISTADO DE ENFERMEDADES SEGÚN EL CIE 10 X
4 LISTADO DE TRATAMIENTOS SEGÚN EL CIE 10 X
5 LISTADO DE MEDICACION X
6 HISTORIAL DE ATENCIONES X
7 HISTORIAL MEDICO X
45
8 CONSOLIDADO X
9 REPORTE ESTADISTICO X
3.2.3. Iteraciones
En la tabla 3.11 siguiente se muestra el Plan de Iteraciones que fue elaborado en
coordinación constante con el cliente, entonces se establecieron las iteraciones en
las diez semanas que se estimó para la culminación del proyecto.
Tabla 3.11 Plan de Iteraciones.

ITERACION
HISTORIA
SEMANAS
Nº
1 2 3 4 5 6 7 8 9 10
01
02
1
03
04
05
2 06
07
08
3
09

Las Historias de Usuario fueron agrupadas en las iteraciones dadas de acuerdo a

su complejidad y afinidad en los componentes a desarrollar, es decir un desarrollo
incremental que tiene como base la implementación de los requerimientos iniciales.
3.2.4. Architectural Spike
A. Definición de Herramientas y Tecnologías

Las herramientas y tecnologías usadas fueron las siguientes:
46
 Sistema Gestor de Base de Datos: Se escogió PostgreSQL 9, el cual
nos permite la implementación de una base de datos centralizada,
relacional y multiusuario a través de su herramienta gráfica PgAdmin III.
 Plataforma Java EE: Consta no solo de la utilización del lenguaje de
programación, sino de un conjunto de herramientas tecnológicas que
permiten el desarrollo de aplicaciones cliente-servidor.
 PowerArchitect, software para la diagramación de las base de datos.
 Netbeans 7.1 IDE, es el entorno de desarrollo para tecnologías Java
adoptado.
3.3. DISEÑO
Se tomaron en cuenta y se pusieron en práctica las consideraciones de diseño
propuestas por la metodología
A. Modelación de la Base De Datos

La modelación de la base de datos refleja los requerimientos
funcionales que se ha de atender, es de suma importancia tener un
modelo que pueda cumplir con suficiencia las necesidades planteadas.
a. Modelo Entidad Relación
El modelo entidad relación nos muestra las entidades y sus

relaciones con las demás, estas entidades son objetos del mundo
real distinguibles y definidos por sus atributos, sobre la cual es
necesario almacenar información. En el desarrollo del proyecto este
modelo es el inicial para la implementación en un sistema gestor de
base de datos.
Fig. 3.1: Modelo Entidad Relación.

47
La figura 3.1 muestra el modelo relacional desarrollado de acuerdo a
los requerimientos recibidos, el modelo expresa la interrelación de
los actores del sistema.
b. Modelo Relacional
El modelo relacional es la representación del modelo Entidad

Relación para su implementación sobre un sistema gestor de datos
relacional, por ende está sujeto a restricciones propias de los
modelos relacionales y su implementación a menudo cambia con
respecto al modelo E-R. Además el modelo relacional nos
proporciona detalles en la estructura las tablas de la base de datos,
las relaciones con las demás y los tipos de datos a utilizar.
Dado que la herramienta PgAdmin III utilizada no proporciona una

vista de las tablas y sus interrelaciones, usamos SQL
PowerArchitect que es una herramienta de uso libre para poder ver
el esquema implementado que es muestra en la figura 3.2.
Fig. 3.2: Diagrama del Modelo Lógico de Base de Datos.

48
3.4. CODIFICACIÓN
A. Implementación en el Sistema Gestor de Base De Datos

La implementación en el sistema gestor de base de datos comprende la
creación de las tablas, las columnas, determinación de los tipos de
datos, la restricciones (claves primarias, claves foráneas,
identificadores, etc.) y demás implementaciones características del
gestor de base de datos PostgreSQL como las secuencias.
Para la implementación de la base de datos relacional se empleará

PgAdmin III, una herramienta gráfica de uso libre, en la figura 3.3 se
muestra la implementación de la base de datos correspondiente al
modelamiento que se realizó para el Área de Salud.
Fig. 3.3: Implementación del Modelo Relacional de Base de Datos.

Como se aprecia en la figura anterior, la implementación del modelo

relacional varia respecto a otras porque el sistema gestor PostgreSQL
usa secuencias independientes de las tablas para generar el
autoincremento de los Id o identificadores.
En la figura 3.4 se muestra la definición de la tabla “Atención”, esta

definición se realiza con ayuda de la herramienta gráfica y el resultado
49
final es código SQL que muestra además la implementación de las
restricciones con las demás tablas.
Fig. 3.4: Definición de tablas del modelo relacional.

B. Hibernate
a. Configuración de Hibernate
El paso inicial para el mapeo de la base de datos en la configuración

de Hibernate, el cual lo realizamos mediante el archivo
hibernate.cfg.xml, esto lo hacemos de manera asistida que nos
proporciona el IDE Netbeans 7.1 donde especificamos las
características correspondientes.
Fig. 3.5: Configuración de Hibernate.

50
Como se aprecia en la figura 3.5, en el archivo de configuración
hibernate.cfg.xml se definen las propiedades correspondientes a:
 Dialect: Nos permite identificar que dialecto se utilizará, esto

depende del gestor de base de datos que se esté utilizando, para
nuestro proyecto se usará PostgreSQLDialect en clara relación
con la base de datos PostgreSQL implementada y que nos
proveerá de mecanismos de manipulación de datos particular
para esta base de datos.
 Driver_class: Proporcionamos la dirección del driver a utilizar

dentro de nuestro proyecto, dicho driver es una librería de clases
específica para PostgreSQL, que nos permitirá manipular la
conexión y operaciones con la base de datos usando el lenguaje
Java.
 Url: nos permite identificar la ubicación de la base de datos con

la que se trabajará, utilizando el driver (JDBC), proporcionando el
puerto de conexión y el nombre de la base de datos.
 Username: proporcionamos el nombre usuario con el cual se

realizará la conexión a la base de datos, este nombre de usuario
es definido en el sistema gestor de base de datos.
 Password: proporcionamos la contraseña de seguridad para el

usuario con el cual se realizará la conexión a la base de datos.
 Mapping: en este atributo del archivo de configuración

hibernate.cfg.xml se proporciona el nombre de las tablas
implementadas en el sistema gestor de base de datos, las cuales
usaremos para crear las clases que nos permitan manipularlas
como objetos.
C. Mapeo de la Base de Datos

En el mapeo de la base de datos se crean las clases que refleja la
estructura de la base de datos relacional en clases para manipularlos
registros del mismo como objetos .En las clases además se utilizan
anotaciones, que son líneas de código insertadas en la parte superior
de las clases, precedidas por el símbolo @, que especifican las
características de las tablas, las cuales pueden ser la identificación de
51
la clave principal, foránea, la generación de identificadores
autoincrementables y demás dependiendo de las características del
sistema gestor de base de datos como se muestra en las figuras 3.6 y
3.7.
Fig. 3.6: Mapeo de base de datos.

El mapeo de la base de datos se realiza de manera automática con el IDE

Netbeans 7.1 utilizado, después de definir los archivos de configuración
correspondientes. Las anotaciones utilizadas deben de variar del generado por
el IDE en la manera de obtener del autoincremento para el identificador de las
clases, esto es debido a la peculiaridad del sistema gestor de base de datos
PostgreSQL.
 Clave primaria: en la figura 3.7se muestra la especificación de la clave

primaria de la clase “Atención”, se especifica el nombre de la columna de la
base de datos a la que corresponde.
 Clave foránea: En la figura 3.7 también se muestra la implementación de la

clave foránea, se especifica el tipo de relación y la tabla de la base de datos
a la cual corresponde
 Autoincremento: En la figura 3.8 se muestra la implementación del

autoincremento del identificador para la clase “Persona”, esta
implementación es específica para el gestor de base de datos PostgreSQL,
para ello las anotaciones “@SequenceGenerator” y “@GeneratedValue”
52
nos permitirán establecer cuál es la secuencia de la base de datos que
corresponde al valor del identificador.
Fig. 3.7: Mapeo de base de datos, implementación de autoincremento.

D. Creación de Clases
Se realizó la creación de clases para la interfaz gráfica y para la
implementación de las reglas de negocio, en general las clases en las
cuales se plasman las reglas de negocio se denominan controladores,
y se desarrollaron utilizando el lenguaje Java con el IDE NetBeans 7.1.
E. Diseño de Interfaces de Usuario

El diseño y la codificación de las interfaces de usuario son las que
proporcionarán al usuario final del software las herramientas necesarias
para llevar a cabo sus operaciones. Este diseño de la interfaz se
desarrolló utilizando el diseñador gráfico del IDE Netbeans 7.1, tal como
muestra la figura 3.8.
La figura anterior nos muestra la implementación de las interfaces de usuario, las

interfaces que se usaran son las que les permitan la inserción de datos,
actualización y eliminación de las entidades como: personas, medicamentos,
atenciones, diagnósticos y demás.
 Página de Inicio: El diseño de la página de inicio provee el punto de inicio

para la autenticación de los usuarios en el software desarrollado.
53
Las figuras 3.8 y 3.9 muestran la codificación y la interfaz de la página de
inicio.
Fig. 3.8: Codificación de la Página de Inicio.

3.5. RUEBAS Y LANZAMIENTOS

Luego de realizar la codificación de los requerimientos entramos en la fase de
Pruebas, que al ser satisfactorias se convierten en lanzamientos. A continuación en
las figuras siguientes se muestra el funcionamiento del software implementado.
Fig. 3.9: Interfaz de la Página de Inicio.

54
 Página de Bienvenida: La página de bienvenida ofrece los componentes
necesarios para la inserción actualización y eliminación de registros, en la
figura 3.10 se muestra la interfaz correspondiente.
Fig. 3.10: Página de Bienvenida.

 Padrón de beneficiarios: La página del padrón de beneficiarios permite la

consulta de los datos básico de un beneficiario en particular, además
permite la inserción de nuevos registros, las figuras 3.11, 3.12 y 3.13
muestran la interfaz y la exportación de datos correspondiente.
Fig. 3.11: Padrón de beneficiarios.

55
Fig. 3.12: Exportación del Padrón de beneficiarios.

 Lista CIE 10: La página de interfaz de la codificación CIE (Código

Internacional de Enfermedades) en su versión 10 provee los mecanismos
para realizar consultas e inserción de nuevos registros, puesto que lo que la
lista consta de más de 14 000 registros a un nivel de detalle muy minucioso,
solo se registraron los más recurrentes para evitar sobrecargas. En la figua
3.13 se muestra la página referida.
Fig. 3.13: Exportación del Padrón de beneficiarios.

56
 Nuevo registro de Atención: La página inserción de nuevos registros de
atención provee una interfaz para la búsqueda y selección rápida de los
beneficiarios a atender como muestran las figuras 3.14 y 3.15.
Fig. 3.14: Selección de beneficiario para nuevo registro de atención.

Fig. 3.15: Detalles de la Atención.

57
 Inserción de Diagnósticos, Medicaciones y Tratamientos: Luego del
registro de atención realizado se provee una interfaz para agregar los de
talles de los diagnósticos, medicaciones y tratamientos con su
autocompletado requerido para mayor rapidez y comodidad en el registro,
esto se muestra en las figuras 3.16, 3.17, 3.18, 3.19 y 3.20.
Fig. 3.16: Inserción de Diagnósticos.

Fig. 3.17: Diagnóstico agregado al registro de atención.

58
Se puede apreciar que el registro de los diagnósticos al registro de atención es
muy flexible ya que permite irlo modificando si fuera necesario, una
característica importante es que permite seleccionar los diagnósticos de la lista
CIE 10, la misma que muestra los registros coincidentes con los caracteres
digitados.
Fig. 3.18: Inserción de la Medicación.

Fig. 3.19: Medicación agregada al registro de atención.

59
De la misma manera que la inserción de diagnosticos, la inserción de
medicamentos al recetrio del registro de tencion se realiza de maner simple
seleccionando el medicamento de la lista en donde se muestran las
coincidencias con los caracteres digitados, este proceso es rápido.
Fig. 3.20: Inserción del Tratamiento.

 Historial de Atenciones: El historial de atenciones es una página que

permite la visualización de los registros de atención realizados, también
permite la búsqueda de registros por diversos criterios como: DNI, Nombres
y Comunidad como lo muestra la figura 3.21 y la exportación de los registros
mostrado en la figura 3.22.
Fig. 3.21: Historial de Atenciones.

60
Fig. 3.22: Exportación de registros del Historial de Atenciones.

 Consolidado de Atenciones: El Consolidado de Atenciones provee una

interfaz que permite visualizar las atenciones que reciben los beneficiarios
en las diferentes áreas, esto cuenta como una “Historia Clínica”, esto se
muestra en las figuras 3.23 y 3.24.
Fig. 3.23: Consolidado de Atenciones.

61
Fig. 3.24: Consolidado de Atenciones.

La figura anterior muestra los datos consolidados de las atenciones por persona,
algunos registros parecen no tener los campos completos pero eso se debe a
que no todas las atenciones en las diversas especialidades necesariamente
cumplen con esa característica. Este requerimiento implementado es el que
demandaba mayores costos para realizarla de manera manual o utilizando
herramientas ofimáticas, con el software desarrollado este procedimiento solo
demanda de unos pocos segundos.
De esta manera se finaliza el capítulo de Intervención Metodológica con el desarrollo de

las fases planteadas en el modelo aplicativo en adopción de la metodología Extreme
Programming, com la utilización de herramientas, plataformas tecnológicas. El resultado
fue la implementación del software o sistema informático satisfaciendo los requerimientos
del cliente.
62
CAPITULO IV
ANALISIS Y DISCUSIÓN DE RESULTADOS
En este capítulo se hace una evaluación de los resultados obtenidos con la implementación
de la solución propuesta con respecto a la situación inicial, se hará una comparación para
dar cuenta de las mejoras y el funcionamiento de la propuesta implementada.
4.1. RESULTADOS DE LA IMPLEMENTACION DEL SOFTWARE

Los resultados de la implementación del software, usando las herramientas y
plataformas tecnológicas establecidas en el capítulo anterior empleando la
metodología de desarrollo ágil Extreme Programming arrojan los datos mostrados
en la Tabla 4.1 siguiente.
Fig. 4.1: Resultado de la implementación del software.
Variable Independiente Indicador Valor
 Numero de requisitos 9
Implementación de funcionales
Software implementados.
 Nivel de aceptación del Muy bueno.
software.
En la Tabla 4.2 siguiente se observa el detalle del Nivel de Aceptación del Software
basado en las Historias de Usuario atendidas, las cuales obtuvieron el puntaje
correspondiente por el cliente luego de realizar las pruebas de aceptación.
63
Fig. 4.2: Nivel de aceptación del Software
Nº de
Historia Porcentaje
Puntos Puntos
de de
Estimados Obtenidos
Aceptación
Usuario
01 5 5 100
02 5 5 100
03 5 5 100
04 5 5 100
05 5 5 100
06 8 7 87,5
07 10 9 90
08 10 9 90
09 10 9 90

De la tabla anterior se puede apreciar que del total de puntos estimados en para las
Historias de Usuario implementadas se obtiene un 93.5% en promedio, esto da
cuenta que el nivel de aceptación del software sea muy bueno.
4.2. RESULTADOS DEL REGISTRO Y PROCESAMIENTO DE LA ATENCIONES

EN SALUD
En la Tabla 4.3 se muestra los resultados correspondientes al registro y
procesamiento de las atenciones en salud de la Oficina de Relaciones
Comunitarias - Mina Corihuarmi.
Fig. 4.3: Resultados del registro y procesamiento de las atenciones en el área de salud.
V. Dependiente Indicador Valor
 Tiempo de obtención de
Registro y procesamiento  1 minuto
información.
de atenciones de salud
 Nivel de redundancia de
 Menos de 5%
datos.
64
En la Tabla 4.4 se muestra el detalle del tiempo de obtención de información con
el uso del software y sin él. Podemos notar que el tiempo que toma la consolidación
de la información con el uso del software implementado disminuye radicalmente.
Tabla. 4.4: Tiempo de Obtención y Procesamiento de Información.

TIEMPO REQUERIDO
DESCRIPCION CON USO DEL

SIN SOFTWARE (Valor
aproximado) SOFTWARE
Consulta de Atenciones. 10 minutos. Menos de 01 minutos.
Consulta de Datos de Menos de 01 minutos.

15 minutos.
Beneficiarios.
Reporte por grupo etario. 30 minutos. Menos de 01 minutos.
Reporte de Enfermedades Menos de 01 minutos.

30 minutos.
atendidas más recurrentes.
Consolidado de Atenciones por Menos de 01 minutos.
3 horas.
persona.
Consolidado de Atenciones. Indeterminado. Menos de 02 minutos
Menos de 02 minutos
Registro de Atenciones en el
-- por registro.
software.

Elaboración: Desarrollo del proyecto
En general la consolidación de registros, las búsquedas mejoraron

ostensiblemente, debido al uso del software y la homogenización de los
mecanismos y criterios de registros como el uso del CIE 10, con esto se consigue
que los reportes consolidados sean confiables y muy precisos. La contraparte es
el tiempo que requiere el registro de los datos de atenciones y beneficios en la
base de datos que toma un promedio de 02 minutos, que es un tiempo no muy
considerable tomando en cuenta los beneficios que se obtendrán.
El nivel de redundancia de información también se pudo disminuir como muestra

la Tabla 4.5 siguiente.
65
Tabla. 4.5: Nivel de Redundancia de Información.
PRECISION DEL REGISTRO
DESCRIPCION CON USO DEL

MANUAL SOFTWARE
Menos de 5% de
Redundancia de información 20% de registros registros
de personas redundantes redundantes.

En la situación inicial se tenía una redundancia aproximada de 20% de los datos,

esto es que aproximadamente de cada cien registros se repetían hasta 20 con
variaciones tales como la escritura o número de DNI (a veces las personas
brindaban información incompleta o totalmente falsa), con la implementación del
software esa redundancia disminuyó considerablemente a un aproximado de 5%8
con tendencia a disminuir con el uso del software, aún queda redundancia debido
a factores fuera del alcance del proyecto.
De las tablas 4.3, 4.4 y 4.5 se obtiene la siguiente tabla 4.6 que da cuenta de las
diferencias entre la situación inicial y la situación después de la implementación del
software.
Tabla. 4.6: Comparación de la situación inicial y final.

Situación Inicial (Valor Situación Final (Valor
aproximado) aproximado)
Consulta de
información
50 minutos 01 minuto
Redundancia 20 % 5%

De lo visto anteriormente se puede afirmar que la implementación del software influye de

manera positiva, disminuyendo los tiempos de consulta y disminuyendo el nivel de
redundancia de información, en el registro y procesamiento de información de las
atenciones de salud de la Oficina de Relaciones Comunitarias – Mina Corihuarmi; de esta
manera podemos afirmar que la hipótesis planteada en el capítulo primero es verdadera.
8
Anexo XIX al XXII
66
CONCLUSIONES
1. La implementacion del Software para el Registro y Procesamiento de atenciones de

salud en las actividades de Responsablidad Social de Mina Corihuarmi influye de
manera positiva la situacion inicial al disminuir los tiempos de consulta de información
y disminuir el nivel de redundancia de información.
2. La utilización de la metodología ágil Extreme Programming es efectiva y satisface los

requerimientos de software de Mina Corihuarmi.
67
RECOMENDACIONES
1. Utilización de metodologías ágiles en la implementación de proyectos de software que

no requieran un trabajo de análisis exhaustivo ni documentación rigurosa.
2. Uso de herramientas de mapeo objeto relacional para el almacenamiento de

información en la base de datos.
3. Utilización de herramientas de software libre, ya que proporcionan ventajas económicas

en las organizaciones.
68
REFERENCIAS
REFERENCIAS BIBLIOGRÁFICAS
1. Tamayo y Tamayo, Mario (2003). El Proceso de la Investigación Científica. Cuarta

Edición. Editorial MILUSA. México.
REFERENCIAS ELECTRÓNICAS
1. Don Wells: Extreme Programming:A gentle introduction [en linea].

Disponible en: http://www.extremeprogramming.org
Fecha de acceso 13 de abril2013.
2. JBoss Community: Hibernate Getting Started Guide [ guia en internet].

Disponible en: http://docs.jboss.org/hibernate/orm/4.1/quickstart/en-US/html/
Fecha de acceso 15 de abril 2012.
3. Facultad de Informática, Universidad Politécnica de Valencia. Ejemplo de desarrollo

software utilizando la metodología XP.
Disponible en: http://users.dsic.upv.es/asignaturas/facultad/lsi/ejemploxp/
Fecha de acceso 10 de diciembre 2013.
4. Echeverry Tobón, Luís Miguel, Delgado Carmona, Luz Elena (2007). Caso práctico de
la metodología ágil XP al desarrollo de software. Universidad Tecnológica de Pereira.
Disponible en:
http://recursosbiblioteca.utp.edu.co/dspace/bitstream/11059/794/1/0053E18cp.pdf
69
5. Cruz Acosta Santiago David. Sistema de diagnóstico de líneas telefónicas de Andinatel
S.A. (2009). Facultad de Ingeniería de Sistema s, Escuela Politécnica Nacional,
Ecuador.
Disponible en: http://bibdigital.epn.edu.ec/bitstream/15000/1450/1/CD-2120.pdf
6. Mindy Sánchez y Erick Torres. Desarrollo de un Sistema web basado en ADO.net para
el control de la gestión de inscripción y logística de cursos en la empresa Enfoque
Directo Aplicado Consultores (2011). Escuela de Computación, Facultad de Ciencias
de la Informática, Caracas Venezuela.
Disponible en: http://www.miunespace.une.edu.ve/jspui
7. Paola Plancarte Solórzano. Diseño de un sistema como estrategia para incrementar el

rendimiento académico del alumno: caso Liceo Anglo Pedagógico. (2011). Instituto
Politécnico Nacional, Unidad Profesional Interdisciplinaria de Ingeniería y Ciencias
Sociales y Administrativas, Mexico.
Disponible en:
http://www.repositoriodigital.ipn.mx/handle/123456789/755/browse?value=Plancarte+
Solórzano%2C+Paola&type=author
70

Implementación de Software

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Implementación de Software

Загружено:

Авторское право:

Доступные форматы

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERÚ

FACULTAD DE INGENIERÍA DE SISTEMAS

“IMPLEMENTACIÓN DE SOFTWARE PARA EL REGISTRO Y

MENDOZA RICALDI, LUIS ANGEL.

PARA OPTAR EL TÍTULO PROFESIONAL DE:

Mg. Richard Mercado Rivas.

Deseo expresar muestras de agradecimiento:

Por su ejemplo, amor y apoyo incondicional y constante.

Por haber propiciado mi formación profesional.

Por su gran apoyo y por compartir su vasto conocimiento.

A MIS MAESTROS DE LA FIS

Por su dedicación a la enseñanza a mi paso por la Universidad.

A MIS AMIGOS Y COLEGAS DE LA FIS

Por compartir experiencias dentro y fuera de las aulas universitarias

A LA GERENCIA DE RELACIONES COMUNITARIAS MINA CORIHUARMI

Por darme la oportunidad de desarrollar esta tesis desde sus filas.

La presente tesis titulada “Implementación de Software para el Registro y

1.2. FORMULACION DEL PROBLEMA 8

1.6. OPERACIONALIZACIÓN DE VARIABLES 9

1.8. SISTEMA DE REFERENCIA 11

2.2. MARCO TEÓRICO 14

2.3. MARCO CONCEPTUAL 38

3.5. RUEBAS Y LANZAMIENTOS 54

ANALISIS Y DISCUSIÓN DE RESULTADOS 63

Figura 1.1: Ubicación de la Mina Corihuarmi. 4

Tabla 1.1: Características de la información generada por la organización 7

El mundo actual exige la disponibilidad de información en tiempo real para la ayuda en

La presente tesis se divide en cuatro capítulos, en el capítulo primero denominado:

En el capítulo segundo denominado: Marco Teórico; se realiza la descripción de los

En el capítulo cuarto, Análisis de y Discusión de Resultados se muestra la comparativa

De este modo se concluye que la investigación abordada mediante la adopción de la

En el presente capítulo se abarca el planteamiento del problema, los objetivos y los

1.1. PLANTEAMIENTO DEL PROBLEMA

1.1.1. Mina Corihuarmi

En la espectacular cordillera de los Andes, a una altitud de casi 5,000

El acceso a Corihuarmi es a través de 330 kilómetros en una carretera

Figura 1.1: Ubicación de la Mina Corihuarmi.

Fuente: Minera IRL S.A.

“Además del rendimiento económico generado por la Mina de Oro

Brindamos muchos programas de salud y educación, impulsamos iniciativas

La mina también brinda cientos de oportunidades de empleo directo y ayudó

“Las comunidades campesinas del área de influencia se verán fortalecidas

“Que la Mina Corihuarmi favorezca a la economía de las comunidades

En la figura 1.2, se muestra el Organigrama Estructural de la Oficina de

AREA SALUD AREA SOCIO EDUCATIVO AREA PECUARIA AREA SOCIAL

MEDICINA GENERAL FORESTAL

ODONTOLOGIA SANIDAD ANIMAL

Fuente: Oficina de Relaciones Comunitarias Mina Corihuarmi.

Consulta de Atenciones 10 minutos.

Reporte por grupo etario. 30 minutos.

Consolidado de Atenciones por

Consolidado de Atenciones indeterminado

El tiempo indeterminado para consolidar la información de las atenciones en salud

Se realizan informes mensuales de actividades en las cuales se incluyen el número

Un caso similar sucede en todas las áreas de la Oficina de Relaciones

 Se espera una gran

Visto el mayor número de desventajas del uso de las herramientas ofimáticas y la

1.2. FORMULACION DEL PROBLEMA

1.3. OBJETIVO GENERAL

Una vez culminado e implementado el proyecto, este beneficiará directamente a los

1.4.2. Justificación Metodológica

1.4.3. Justificación Práctica

1.5.1. Hipótesis General

1.6. OPERACIONALIZACIÓN DE VARIABLES