Mi Proyecto de Bachiller - Edgar Cruz - Informe Completo

UNIVERSIDAD NACIONAL DEL SANTA FACULTAD DE INGENIERÍA

Escuela Académico Profesional de Ingeniería de Sistemas e

Informática

“DESARROLLO DE UN SISTEMA DE INFORMACIÓN PARA LA ATENCIÓN DE PACIENTES EN EL PUESTO DE SALUD SAN

PEDRO - CHIMBOTE”

INFORME DE PRÁCTICAS PRE-PROFESIONALES

PARA OPTAR EL GRADO DE BACHILLER DE SISTEMAS E INFORMÁTICA

ALUMNO: EDGAR ALEXANDER CRUZ HUAMAN ASESOR: Ing. DIANA CECILIA MUÑOZ CASANOVA

NUEVO CHIMBOTE –PERÚ 2005



Informática “DESARROLLO DE UN SISTEMA DE INFORMACIÓN PARA LA

ATENCIÓN DE PACIENTES EN EL PUESTO DE SALUD SAN PEDRO - CHIMBOTE”

INFORME DE PRÁCTICAS PRE-PROFESIONALES PARA OPTAR EL GRADO DE BACHILLER DE

SISTEMAS E INFORMÁTICA Revisada y Aprobada por:

Ing. Diana C. Muñoz Casanova



Informática “DESARROLLO DE UN SISTEMA DE INFORMACIÓN PARA LA

ATENCIÓN DE PACIENTES EN EL PUESTO DE SALUD SAN PEDRO - CHIMBOTE”

INFORME DE PRÁCTICAS PRE-PROFESIONALES PARA OPTAR EL GRADO DE BACHILLER DE

SISTEMAS E INFORMÁTICA

Sustentada y Aprobada por el siguiente jurado:

Ing. Sisto Díaz Tello Presidente

Ing. Hugo Caselli GuismondiSecretario

Ing. Carlos Guerra Flores Integrante

Dedicatoria

A Dios, que siempre me ilumina, me protege y cuida; dándome fuerzas para seguir adelante, conservando la fe y esperanza.

A ¡Mi Madre!!! Sra. Maria Esther Huaman Bacón.

Quien me ha dado su amor y apoyo para seguir adelante.

Y a ¡Mi Padre!!! Sr. Casimiro Cruz

Francisco. Quien me ha inculcado el deseo de superación

bajo cualquier circunstancia así como su amor y apoyo incondicional.

A mis hermanas: Devora Nevenga Cruz Huaman e Ivon Vanesa Cruz Huaman. Por su apoyo. A mi sobrino Aron Chávez Cruz, quien me alegra con su compañía. A mi primo Heli Morillo, quien ha sido un verdadero amigo en las buenas y en las malas.

A mis Amigos y Compañeros: Andrei, Willy, Benicia, Mónica, Deysi, Cesar, Aland, Juan Carlos, Erison, José

Norberto, Javier, Omar, Agusto, Luciano, Richard, Clever, Angélica, Roxana y a todos, quienes nunca dejaron de confiar en mi y por

siempre estar cuando los necesitaba.

i

Agradecimiento

A Dios, Por haberme dado la Vida así como la Sabiduría y las Fuerzas necesarias para alcanzar las metas que me he propuesto,para así proponerme otras.

A mis padres y hermanas, Por su apoyo moral y económico,

comprensión y confianza. Por su esfuerzo y sacrificio diario,

siendo los impulsadores en mí desarrollo y formación profesional. ¡Gracias!!!

A los Docentes: Del Colegio Nacional República Peruana, Academia Euclides, Universidad Nacional del Santa. Quienes me han brindado sus conocimientos para que así yo pueda superarme en la vida, gracias por saber escuchar y ser más que docentes y convertirse en amigos.

A la doctora Margarita Mendo Lagos así comoal personal del Puesto de Salud “San Pedro”, por haberme dado la oportunidad de realizar

mis practicas pre-profesionales en suestablecimiento de Salud así como su apoyo

incondicional.

A Clever Pinedo, un gran amigo y compañero de trabajo. ¡Gracias!!! Por tus consejos y apoyo incondicional.

A Andrei Miranda Bartolomé y Willy Díaz

Valqui. ¡Gracias!!!. Por ser mis mejores amigos y por estar siempre conmigo en las

buenas y las malas. ¡Gracias!!!

ii

Presentación

Señores miembros del jurado:

Haciendo uso del Reglamento General de Grados y Títulos de la Universidad Nacional

del Santa, me permito presentar ante Ustedes el Informe de Prácticas Pre-Profesionales

titulado:

“DESARROLLO DE UN SISTEMA DE INFORMACIÓN PARA LA

ATENCIÓN DE PACIENTES EN EL PUESTO DE SALUD SAN

PEDRO - CHIMBOTE”

Con la finalidad de optar el grado de Bachiller de Sistemas e Informática.

Este trabajo tiene como lugar de aplicación el Puesto de Salud San Pedro, la cual por su

naturaleza, función, antigüedad y tamaño de información (pacientes y sus datos) que

maneja, se ha visto en la necesidad de adquirir un aplicación que le ayude, facilite la

información necesaria en el más mínimo tiempo posible para poder tomar decisiones

adecuadas.

EL AUTOR.

iii

RESÚMEN

“Desarrollo de un Sistema de Información para la atención de pacientes en el

Puesto de Salud San Pedro - Chimbote”

Autor:

CRUZ HUAMAN, Edgar Alexander.

El presente trabajo implicó el Desarrollo de un Sistema para la Atención de Pacientes en

el Puesto de Salud San Pedro, el cual va a contribuir al apoyo del manejo de la

información sobre los pacientes.

El Sistema será aplicado en el área de Admisión del dicho establecimiento de salud. El

Sistema cubre los principales procesos de admisión, los cuales son registrar, modificar,

buscar, realizar consultas para la toma de decisiones en la atención médica.

Para efectos de desarrollo del Sistema se utilizó la Metodología eXtreme Programing

(XP), como desarrollador de aplicaciones se utilizó el lenguaje de programación Power

Builder así como el sistema gestor de base de datos SQL Anywhere.

Como resultado de este trabajo, se llegó a comprobar la veracidad de la hipótesis

planteada, al lograr la aceptación de la automatización por parte del directorio del

Puesto de Salud, dado que cumple con sus fines de controlar, acelerar la información,

así como apoyo el la toma de decisiones.

iv

ABSTRACT

“Development of an Information System in order to attend of patients in the

St. Peter Health Center - Chimbote”

Author:

CRUZ HUAMAN, Edgar Alexander.

The present work implies the Development of a System in order to Pacients' Attention

in the St. Peter Health Center, which goes to contribute to the support of the handling of

the information on the patients.

The System will be applied in Admission's area of the Health Center .The System

covers up the main things admission processes, them as they are to search, to modify, to

search, to accomplish consultations in order to the decision makings in the medical

attention.

In order to develop properties of the System , it was used the eXtreme Programming

Methodology ( XP ), as developer of applications it was used the programming

language Power Builder as well as the managing data system base SQL Anywhere.

This work's result, the hypothesis's veracity presented, gets to check itself to the

achieving the acceptance of the automatization for part of the Health Center's directory,

granted that it complies with its ends of controlling, accelerating the information, as

well as support the decision makings.

v

ÍNDICE GENERAL

CONTENIDO PAG.

DEDICATORIA i

AGRADECIMIENTO ii

PRESENTACIÓN iii

RESUMEN iv

ABSTRACT v

CAPÍTULO I: LA EMPRESA

1.1 Naturaleza 1

1.1.1 Nombre o Razón Social 1

1.1.2 Finalidad 1

1.1.3 Objetivos 1

1.2 Descripción de la Organización 2

1.2.1 Reseña Histórica 2

1.2.2 Base Legal 3

1.2.3 Ubicación Geográfica 3

1.2.4 Estructura Orgánica 4

1.2.5 Organigrama 5

1.2.6 Funciones 6

1.3 Misión 8

1.4 Visión 8

vi

CAPÍTULO II: PLANTEAMIENTO DE LA INVESTIGACIÓN

2.1 Problema 9

2.1.1 Realidad Problemática 9

2.1.2 Análisis de la Realidad Problemática 10

2.1.3 Formulación del Problema 11

2.2 Antecedentes 11

2.3 Justificación 12

2.4 Hipótesis 12

2.5 Objetivos 12

2.5.1 Objetivo General 12

2.5.2 Objetivos Específicos 13

CAPÍTULO III: FUNDAMENTO TEÓRICO

3.1 Marco Conceptual 14

3.1.1 Aplicación 14

3.1.2 Contraseña 14

3.1.3 Formularios 14

3.1.4 Servidor 14

3.2 Marco Teórico 15

3.2.1 Sistemas de Información 15

3.2.2 Arquitectura 16

3.2.3 Metodología Empleada 19

3.2.4 Herramientas Utilizadas 36

vii

CAPÍTULO IV: METODOLOGÍA

4.1 Procedimiento 57

4.1.1 Fases de la Metodología 57

4.2 Tipo de Investigación 60

4.3 Método de Investigación 60

4.4 Diseño de Investigación 61

4.4.1 Variables 61

4.5 Diseño Experimental 62

4.6 Cobertura de Estudio 63

4.6.1 Población 63

4.6.2 Muestra 64

4.7 Técnicas e Instrumentos 64

CAPÍTULO V: DESARROLLO DEL SISTEMA DE ADMISIÓN

5.1 Versiones del Software 65

5.2 Capacitación de Usuarios 66

5.3 Diseño de la Base de Datos 67

5.3.1 Diagrama Entidad Relación Actual 67

5.3.2 Diagrama Entidad Relación a usar 68

5.3.3 Modelo Relacional Actual 69

5.3.4 Modelo Relacional a usar 70

5.4 Diseño del Sistema 71

5.4.1 Prototipo del Sistema 71

5.4.2 Sistema Principal 72

5.4.3 Sistema de Admisión 79

viii

CAPÍTULO VI: RESULTADOS Y DISCUCIÓN

6.1 Demostración de la Hipótesis 96

6.2 Discusión 98

CONCLUSIONES 104

RECOMENDACIONES 105

REFERENCIAS BIBLIOGRÁFICAS 116

ANEXOS 109

ix

ÍNDICE DE FIGURAS

Figura 01: Organigrama del Puesto de Salud “San Pedro” 5

Figura 02: Coste del Cambio Actual 23

Figura 03: Coste del Cambio Propuesto 24

Figura 04: Comparación de Metodologías Tradicionales con XP 35

Figura 05: Servidor de Base de Datos Personal 44

Figura 06: Servidor de Base de Datos de Red 45

Figura 07: Diagrama ER Actual 67

Figura 08: Diagrama ER a Usar 68

Figura 09: Modelo Relacional Actual 69

Figura 10: Modelo Relacional a Usar 70

Figura 11: Prototipo del Sistema 71

Figura 12: Mensaje de Bienvenida 72

Figura 13: Autentificación de Usuario 72

Figura 14: Menú Principal 73

Figura 15: Cambio de Usuario 73

Figura 16: Datos de Usuario 74

Figura 17: Registrar Usuario 74

Figura 18: Cambiar Contraseña 75

Figura 19: Copias de Seguridad 75

Figura 20: Manual de Usuario General 76

Figura 21: Ayuda y Soporte Técnico 77

Figura 22: Accesorios 77

Figura 23: Acerca del Desarrollador 78

x

Figura 24: Ventana Familia 79

Figura 25: Registrar Familia 80

Figura 26: Modificar Datos de Familia 80

Figura 27: Borra Familia 81

Figura 28: Buscar Integrantes de Familia 81

Figura 29: Ventana Pacientes 82

Figura 30: Registrar Nuevo Paciente 83

Figura 31: Modificar Datos del Paciente 84

Figura 32: Borrar Paciente 85

Figura 33: Historia Clínica del Paciente 86

Figura 34: Numero de Personas por Pueblo Agrupadas por Sexo 87

Figura 35: Numero de Personas por Sector Agrupadas pos sexo 88

Figura 36: Pacientes por Fecha de Nacimiento o Defunción 89

Figura 37: Número de Integrantes por Familia según Pueblo 90

Figura 38: Mujeres Gestantes según Fecha 91

Figura 39: Numero de Familias por Pueblo y Sector 92

Figura 40: Relación de Pacientes Asegurados 93

Figura 41: Manual del desarrollador 94

Figura 42: Manual de Usuario – Admisión 95

Figura 43: Número de Respuestas por alternativa 100

xi

INTRODUCCIÓN

La vorágine en el avance tecnológico de la Informática y la necesidad de toda

Institución de contar con Sistemas de Información, que le puedan facilitar el acceso a

los datos en tiempos pequeños, así como mantener un control adecuado de la data para

la toma de decisiones y a la vez permitir la optimización de sus ingresos económicos al

reducir el personal y tiempo en los procesos manuales, a llevado a las organizaciones

empresariales e instituciones de cualquier índole a adquirir sistemas de información.

En la actualidad dentro de toda organización, existe una tendencia a pensar que el uso

de un sistema de información es necesario, suponiendo una innovación en la

administración de la información. Esto no deja de se cierto.

A medida que la Ingeniería del Software evoluciona, junto con ella su producto el

Software asume tareas más complejas, con metodologías en análisis, diseño y desarrollo

cada vez más sencillos; en la perspectiva del desarrollo del software.

Se ofrecen mejores interfaces para el usuario, cada vez atractivos a la vista y fáciles de

manipular haciendo buen uso del sistema informático, ofreciendo gran apoyo en la toma

de decisiones por parte de la directiva, siendo cada vez efectivas y oportunas.

El informe “Desarrollo de un Sistema de Información para la atención de pacientes en el

Puesto de Salud San Pedro - Chimbote”, es la respuesta al estudio de la problemática

actual de dicha organización, que se presenta por la imperiosa necesidad de reducir los

tiempos muertos en la búsqueda de Historias Clínicas pudiendo así generar más

xii

ingresos económicos al poder atender a mas pacientes, controlar el número de Historias

Clínicas, así también ayudar a la toma de decisiones de manera oportuna y segura.

El Capítulo I, detalla los datos Generales de la Institución Médica tales como su razón

social, su ubicación, finalidad, objetivos, estructura y otros puntos.

El Capítulo II, describe el Plan de Proyecto, especificando la Realidad Problemática,

Análisis de la Realidad Problemática, Formulación del Problema, Antecedentes,

Justificación, Hipótesis así como el Objetivo General y Objetivos Específicos.

El Capítulo III, describe el Fundamento Teórico; el cual está dividido en: Marco

Conceptual y Marco Teórico; el Marco Conceptual contiene conceptos básicos sobre

Informática, el Marco Teórico contiene teoría sobre los Sistemas de Información,

Arquitectura, la metodología empleada así como el lenguaje de programación y gestor

de base de datos que se utilizó.

EL Capítulo IV, describe la Metodología, en el se incluyen lo que se hizo en cada Fase

de la Metodología XP, el Tipo, Método y Diseño de Investigación, el Diseño

Experimental, la cobertura de estudio y las Técnicas e Instrumentos utilizados.

EL Capítulo V, describe el desarrollo del Sistema de Admisión, en el cual se incluyen

las versiones del software (que se hizo en cada versión y el tiempo que llevo hacerlas),

la capacitación a los usuarios, los diagramas de Entidad Relación y el Modelo

Relacional del sistema, así como las pantallas del sistema.

xiii

El Capítulo VI, describe los Resultados y Discusión, en el este capítulo se verá la

demostración de la hipótesis así como la respectiva discusión.

Finalmente se hace mención de las conclusiones y recomendaciones que surgen del

presente informe de Prácticas Pre-Profesionales.

Para respaldo de este informe, se agrego en la parte final los anexos correspondientes;

en el cual se hace mención: a las características de software y hardware, cuestionarios

para medir la optimización, cuestionarios para pruebas de software, el estudio de

factibilidad y por ultimo algunos reportes que proporciona el Sistema de Admisión.

xiv

“Sistema de Información para la

atención de Pacientes”

Capítulo I.

LA EMPRESA

Sistema de Información para la Atención de Pacientes UNS

LA EMPRESA

1.1 NATURALEZA

1.1.1 Nombre o Razón Social

Puesto de Salud “San Pedro”

1.1.2 Finalidad

Realizar actividades preventivas promocionales.

1.1.3 Objetivos

1.1.3.1 Objetivo General

Favorecer acciones integradoras que contribuyan al desarrollo de la

institución y garantizar una atención médica de calidad, eficiencia, y

eficacia con un bajo presupuesto de atención para la población.

1.1.3.2 Objetivos Específicos

1. Innovar el planeamiento estratégico.

2. Adquirir nuevos equipos y materiales médico - hospitalarios.

3. Crear nuevas fuentes de ingresos económicos.

4. Capacitar al personal para una mayor competitividad y brindar un

mejor servicio al paciente.

5. Obtener el apoyo de los medios de Comunicación social en las

medidas de prevención y educación.

6. Proporcionar a la instalación de los estándares comunitarios y/o

Materno Infantil, normas, manual de procedimientos, etc.; para el

mejor desempeño del personal de Enfermería y de los Asistentes

de Salud.

Edgar Alexander Cruz Huaman 1


7. Implantar un sistema de vigilancia y evaluación que nos garantice

que las actividades, normas y demás se están cumpliendo.

8. Elaborar un plan de acción a seguir para resolver los problemas

y/o conflictos que se puedan presentar.

9. Constituir un Comité de Garantía de Calidad para la implantación

y seguimiento del proyecto en el Departamento de Enfermería y

posteriormente en todos los departamentos de la institución.

1.2 DESCRIPCIÓN DE LA ORGANIZACIÓN

1.2.1 Reseña Histórica

El puesto de Salud “San Pedro” fue creada gracias al Dr. Alan García

Pérez, en su gobierno de 1980 – 1985, ya que fue el mismo el que

promulgó el Decreto Legislativo N° 351 y a la vez se promulgó el decreto

supremo 12-86 en la que se daba a conocer la creación de los puestos de

salud a nivel nacional.

Las autoridades de salud de la localidad de Chimbote, viendo la necesidad

urgente de la comunidad del Asentamiento Humano “San Pedro”

decidieron instalar un Puesto de Salud para el beneficio de las personas de

bajos recursos económicos.

Es así como se creó el Puesto de Salud “San Pedro” un 26 de enero de

1986, según Resolución Directoral N° 2430585, estando como Ministro de

Salud el Dr. David Tejada de Rivero, dependiendo este puesto de salud del

Hospital de Apoyo “La Caleta”, siendo el director Dr. Oswaldo Pérez



Gamboa.

El Puesto de Salud empezó a funcionar el 25 de febrero de 1986 con un

médico, la Dra. Margarita Mendo Lagos y un personal auxiliar.

1.2.2 Base Legal

Constitución Política del Perú.

Directiva N° 005-82 INAP/DNR, Art. 29 D.S. N° 013-2002-SA.

Directiva Nº 01-95-RCH-CTAR/ORPP-OER Norma para la formulación,

aprobación y actualización de los MOF.

Ley 27657- Ley del MINSA, Directiva N° 007-MINSA/OGPE-V. 01

"Directiva para la formulación de documentos normativos de gestión

institucional" aprobado con R. M. N° 371-SA/DM.

R. M. N° 606-2002-SA/DM que aprueba el modelo de ROF de los

hospitales del sector a nivel nacional.

R. E. R. Nº 0289-2Q04- Región Ancash/PRE que aprueba el ROF del

Hospital “La Caleta” - Chimbote.

1.2.3 Ubicación Geográfica

El Puesto de Salud “San Pedro” se encuentra ubicado:

Departamento : Ancash

Provincia : Santa

Distrito : Chimbote

AA.HH. : San Pedro

Calle : Los Ángeles Mz 31



1.2.4 Estructura Orgánica

El Puesto de Salud “San Pedro” tiene la siguiente estructura orgánica:

1.2.4.1 Órgano de dirección

Jefatura posta de salud “san pedro”

1.2.4.2 Órgano de línea final

Servicio de medicina

Servicio de obstetricia

1.2.4.3 Órgano de línea intermedia

Servicio de enfermería

- Área de tópico

Servicio de farmacia

1.2.4.4 Órgano de apoyo

Área de estadística

Área de contabilidad

Área logística

Área personal

Área servicios generales

Área saneamiento ambiental



1.2.5 Organigrama

Figura 01. Organigrama del Puesto de Salud “San Pedro”

JEFATURA P S S P

AREA SERVICIOS

GENERALES

AREA ESTADISTICA

AREA ECONOMIA

AREA LOGISTICA

AREA PERSONAL

AREA SANEAMIENTO

AMBIENTAL

ENFERMERIA

TÓPICO

SERVICIO MEDICINA

OBSTETRICIA FARMACIA

DIRECCIÓN HOSPITAL “LA CALETA”



1.2.6 Funciones

El Puesto de Salud “San Pedro” tiene las siguientes funciones:

1.2.6.1 Órgano de Dirección

Jefatura Posta de Salud “San Pedro”

Dirigir, organizar, asesorar, supervisar y evaluar el funcionamiento

de los servicios de salud.

1.2.6.2 Órgano de Línea Final

Servicio de Medicina

Coordinar con los servicios existentes, para brindar una atención

integral al paciente, familia y comunidad.

Servicio de Obstetricia

Brindar atención obstétrica (Dx. precoz del embarazo, selección

del gestante de alto y bajo riesgo, control prenatal, control

puerperio y R.N.)

1.2.6.3 Órgano de Línea Intermedia

Servicio De Enfermería

Organizar, dirigir, supervisar, evaluar el servicio de enfermería a

su cargo.

Área De Tópico

Brindar atención de salud elemental (cirugía menor, inyectables,

curaciones, control de funciones vitales)



Servicio de Farmacia

Administrar la farmacia SIS MED promoviendo el uso racional

de medicamentos.

1.2.6.4 Órgano de Apoyo

Área de Estadística

Digitar información HIS-MIS, SIEN.

Área de Contabilidad

Organizar, coordinar el sistema de cobranza por servicios de salud

prestado a la comunidad.

Área Logística

Controlar y hacer efectivo el pago por adquisiciones de bienes

necesarios para el establecimiento.

Área Personal

Organizar el sistema de control y asistencia del personal y la

elaboración del informe correspondiente.

Área Servicios Generales

Velar por la integridad del edificio, mobiliario, equipos y

materiales del puesto de salud.

Área Saneamiento Ambiental

Realizar actividades de visita domiciliarias en los diferentes

programas: dengue, malaria, cólera y saneamiento ambiental.



1.3 MISIÓN

Realizar actividades preventivas promociónales mediante información,

educación y comunicación, atención rápida y oportuna empleando fármacos y

tecnología en constante innovación, además de contar con personal calificado

para garantizar la salud y mejora de la calidad de vida de la población.

1.4 VISIÓN

Contribuir al acceso universal y equitativo de la población a los servicios de

salud, descentralizando y modernizando la gestión en el primer nivel de

atención.




Capítulo II.

PLAN DE PROYECTO


PLAN DE PROYECTO

2.1 PROBLEMA

2.1.1 Realidad Problemática

El Puesto de Salud “San Pedro”, es una institución Médica del Estado, que se

dedica a prevenir los diferentes tipos de enfermedades, así como a

promocionar la Salud; el Puesto de Salud en sus inicios tuvo como

jurisdicción al AA.HH “San Pedro” con una capacidad poblacional de 2,000

habitantes, con el transcurrir de los años, la población fue creciendo y fueron

surgiendo otros AA.HHs y Pueblos Jóvenes.

Hoy en día el Puesto de Salud “San Pedro” tiene bajo su Jurisdicción a los

AA.HHs “San Pedro”, “Esperanza Alta”, “Manuel Gonzáles Prada” así como

a los Pueblos Jóvenes “Nueva Generación”, “Villa los Jardines” y “OTROS”;

con un aproximado de 15,000 habitantes.

El puesto de Salud a diario atiende a un promedio de 50 pacientes, dejando

muchos sin atender, esto se debe al gran problema que tiene el personal

médico para encontrar las Historias Clínicas, desperdiciando un tiempo

considerable en dicha búsqueda, así como también el problema que existen

muchos números repetidos de Historias Clínicas y además de no contar con

reportes para la toma de decisiones.

Los AA.HHs y Pueblos Jóvenes, se encuentran divididos en uno o más

sectores y en cada sector se encuentran los paquetes de las familias, en cada

paquete se encuentran los integrantes de dicha familia (Historia Clínica de los

Pacientes).

El proceso de atención es el Siguiente:



El paciente llega al área de admisión solicita un ticket para su atención en las

diferentes servicios de salud (medicina, obstetricia, crecimiento y desarrollo

del niño, laboratorio, farmacia y tópico), el encargado de Admisión, solicita

los datos del paciente, entre estos datos se piden el nombre completo del

paciente, el nombre de la familia, el pueblo y su dirección, para

posteriormente entregarle un ticket. Una vez obtenidos estos datos el

encargado u otro personal busca en el mapa la dirección del paciente para

saber en que sector se encuentra dicho paciente, una vez identificado el sector

el encargado pasa a Historial (lugar donde se encuentran todas las historias

clínicas de los pacientes, las cuales están agrupadas por sector del 1 al 20),

una vez obtenida la historia clínica se le entrega al paciente, este pasa a

Tópico para chequeo de sus funciones vitales y finalmente pasa a consultorio

(medicina, obstetricia, enfermería).

2.1.2 Análisis de la Realidad Problemática

Con el actual proceso que se lleva a cabo en el Puesto de Salud “San Pedro”, el

cual se realiza de forma tradicional para búsqueda de historias clínicas y así la

atención a los pacientes; nos damos cuenta de que el establecimiento de salud

esta perdiendo dinero debido a que no se pueden atender a más pacientes por la

demora en la búsqueda de historias clínicas.

También se puede observar el gran conflicto que se genera al encontrar números

repetidos de historias clínicas, el establecimiento de salud cobra al Seguro

Integral de Salud por la atención de los pacientes asegurados, pero este no le

paga cuando encuentra a pacientes con el mismo número de historia clínica.



Se observa la impotencia que tiene la Dirección así como el personal de dicho

establecimiento de salud al no poder realizar decisiones en cuanto a la salud sin

una ayuda que les respalde.

2.1.3 Formulación del Problema

¿De qué manera la implementación de un Sistema de Información podrá

mejorar el control de historias clínicas, optimizar sus ingresos económicos y

ayudar a la toma de decisiones del Puesto de Salud San Pedro?

2.2 ANTECEDENTES

Dentro de las Instituciones médicas que han implementado un Sistema de

Información para el área de Admisión, podemos mencionar:

• Hospital La Caleta

Ubicación: La Caleta SN.

Descripción: Este Sistema fue hecho en el lenguaje de programación Fox Pro,

este sistema, solo permite registrar a sus pacientes. No brinda ninguna clase de

reportes.

• Policlínico Belén

Ubicación: Av. José Gálvez 1258 - El Progreso

Descripción: Este Sistema fue hecho en el lenguaje de programación Visual

Basic, al igual que el sistema anterior, solo permite registrar a pacientes.



2.3 JUSTIFICACIÓN

• El Desarrollo de un Sistema de Información permitirá controlar el número de

Historias Clínicas de los pacientes del Puesto de Salud San Pedro – Chimbote.

• Permitirá reducir el tiempo muerto que se desperdicia en la búsqueda de historias

clínicas.

• Permitirá generar más ingresos económicos al atender a más pacientes debido a la

velocidad que brindará el Sistema.

• Permitirá tener respaldo en la toma de decisiones a causa de los reportes y

consultas que brinde el Sistema.

• Brindará satisfacción al Paciente al ser atendido más rápido.

2.4 HIPÓTESIS

El Desarrollo de un Sistema de Información mejorará el control de historias

clínicas, optimizará sus ingresos económicos y ayudará a la toma de decisiones

del Puesto de Salud San Pedro.

2.5 OBJETIVOS

2.5.1 Objetivo General

• Desarrollar un Sistema de Información en el Puesto de Salud San Pedro

para un mejor control y toma de decisiones adecuada así como optimizar

sus ingresos económicos.



2.5.2 Objetivos Específicos

• Recopilar toda la información posible, para el desarrollo del Sistema de

Admisión.

• Analizar la situación actual así como los procesos que se desarrollan en el

Puesto de Salud.

• Seleccionar la Plataforma bajo la cual se trabajara así como el Lenguaje de

Programación.

• Implementar la Base de Datos Relacional, en el Gestor de Base de Datos

Adecuado al equipo con el que cuenta.

• Desarrollar la metodología XP(eXtreme Programing) para el desarrollo del

software.

• Diseñar y Codificar el Sistema de Admisión.

• Instalación de las Primeras Versiones del Sistema de Información.

• Comprobar el funcionamiento del Sistema de Información a través de

pruebas constantes y reales.

• Instalación Final del Sistema de Admisión.

• Capacitación del Manejo del Sistema al personal encargado de usarlo.




Capítulo III.

FUNDAMENTO TEÓRICO


FUNDAMENTO TEÓRICO

3.1 MARCO CONCEPTUAL

3.1.1 Aplicación.- Programa o conjunto de programas diseñados para realizar

funciones directamente para el usuario. Las aplicaciones necesitan de un

sistema operativo para poder funcionar. Existen varios tipos de aplicaciones:

procesadores de texto, base de datos, hojas de cálculo, correo electrónico, etc.

3.1.2 Contraseña.- Combinación secreta de caracteres que permiten al usuario

acceder a un determinado archivo, computadora, programa, pagina Web, o

servicio de línea. El objetivo de la contraseña es evitar el acceso a usuarios no

autorizados.

3.1.3 Formularios.- Conjunto de campos (espacios) para introducir datos en una

aplicación. Un formulario permite a los usuarios escribir información. La cual

va a ser almacenada y procesada para obtener resultados.

3.1.4 Servidor.- Computadora, dispositivo o programa que distribuye los recursos

dentro de una red proveyendo la información requerida por los usuarios.



3.2 MARCO TEÓRICO

3.2.1 Sistemas de Información

3.2.1.1 Ciclo de Vida de los Sistemas de información

El concepto de ciclo de vida de un sistema información es medular en

las investigaciones de sistemas. Durante su desarrollo, cada sistema se

mueve a través de varias fases de un ciclo de vida, después del cual

sólo funciona por varios años con un mínimo mantenimiento. El

sistema se deteriora gradualmente hasta el punto en que cesa de

funcionar por completo y se comienza un nuevo ciclo de vida con el

desarrollo de un nuevo sistema. Los autores sobre sistema de

información ilustran el ciclo de vida con diferentes números de fases.

Los ciclos de vida de los sistemas varían en gran manera en términos

de longitud, pero por lo regular el ciclo de vida de un sistema de

información está en el rango 3 a 8 años.

3.2.1.2 Tipos y Usos de los Sistemas de Información

Los sistemas de información cumplen tres objetivos básicos:

Automatizar los procesos operativos.

Proporcionar información que sirva como apoyo al proceso de

toma de decisiones organizacionales.

Lograr ventajas competitivas a través de su implantación y uso.

Los sistemas de información que logran la automatización de procesos

operativos dentro de una organización, son llamados frecuentemente

Sistemas Transaccionales, ya que su función primordial consiste en

procesar transacciones tales como pagos, cobros, entradas, salidas y



sus controles. Por otra parte, los sistemas de información que apoyan

el proceso de toma de decisiones son llamados Sistemas de Soporte a

la Toma de Decisiones.

El tercer tipo de sistemas, de acuerdo con su uso y objetivo, es el de

los Sistemas Estratégicos, los cuales se desarrollan en las

organizaciones con el fin de lograr ventajas competitivas, a través del

uso de la tecnología de información. Por último se considera un cuarto

tipo de Sistemas de Información denominado Sistemas Personales de

Información, enfocado a incrementar la productividad de los

usuarios.

3.2.1.3 Metodología para el Desarrollo de Sistemas

La metodología del desarrollo de sistemas es el camino que siguen los

analistas de sistemas para realizar su trabajo. Se emplea el término

genérico de analista de sistemas para describir a la persona que tiene la

responsabilidad principal de conjuntar los componentes estructurales,

dándoles forma y sustancia en conformidad con las fuerza del diseño

para construir sistemas de información exitosos.

3.2.2 Arquitectura

3.2.2.1 ¿Qué es una Arquitectura?

Una arquitectura es un conjunto de componentes funcionales que

aprovechando diferentes estándares, convenciones, reglas y procesos,

permite integrar una amplia gama, de productos y servicios



informáticos, de manera que pueden ser utilizados, eficazmente dentro

de la organización.

3.2.2.2 Arquitectura Cliente/Servidor

Es la tecnología que proporciona al usuario final el acceso

transparente, a las aplicaciones, datos, servicios de cómputo, o

cualquier otro recurso del grupo de trabajo y/o, a través de la

organización, en múltiples plataformas. El modelo soporta un medio

ambiente distribuido en el cual los requerimientos de servicio hechos

por estaciones de trabajo inteligentes o “clientes” resultan en un

trabajo realizado por otros computadores llamados servidores.

Cliente/Servidor son entidades lógicas independientes que operan en

conjunto a través de una red para realizar una tarea. Los sistemas

cliente/servidor poseen las siguientes características distintivas.

Servicio: Cliente/Servidor es fundamentalmente una relación entre

procesos ejecutados entre apartados distintivos.

Recursos compartidos: Un servidor puede atender a muchos clientes

al mismo tiempo y regular su acceso a recursos compartidos.

Protocolos asimétricos entre cliente y servidor: Se establece una

relación de muchos a uno, son siempre los clientes los que inician el

dialogo al solicitar un servidor.



Transparencia de ubicación: El servidor es un proceso que puede

residir en el mismo apartado que el cliente o un apartado distinto a lo

largo de la red.

Mezcla e igualdad: El software ideal del cliente/servidor es

independiente del hardware o de las plataformas de software del

Sistema Operativo.

Intercambios basados en mensajes: Clientes y servidores son

sistemas holgadamente acoplados que interactúan a través de un

mecanismo de transmisión de mensajes.

Integridad: El código del servidor y los datos del servidor se

concentran centralmente lo que resulta un mantenimiento de menor

costo y en la protección de la integridad de los datos compartidos.



3.2.3 Metodología Empleada

3.2.3.1 Introducción a Extreme Programing (XP)

La Mayoría de los programadores habla solo de: lenguajes de

programación, técnicas de programación, entornos de desarrollo,

editores de recursos.

Pero se les pasa por alto cuestiones sumamente importantes como es la

INGENIRÍA DEL SOFTWARE, que es la manera en que debemos de

hacer nuestro software.

Actualmente todas aquellas empresas que desarrollan software han de

moverse en un entorno altamente competitivo habiéndose visto

obligados a reducir el “Time-to-Market” de sus aplicaciones

manteniéndose las mismas exigencias de calidad por parte de sus

clientes. Este panorama parece estar ceñido con los procesos o normas

de calidad implantados en las empresas que en muchas ocasiones, se

acaba retrasando la salida al mercado del producto final.

Por este motivo muchas empresas relegan fases relacionadas con la

calidad del software al plano meramente administrativo o incluso

lleguen a obviarlas, apremiadas por las presiones del cliente o del

mercado.

Frente a esta situación, surge: la metodología eXtreme Programing

(XP), la cual pretende que el desarrollo de un proyecto de software,

sea un desarrollo ágil, aunque disciplinado, y aporte soluciones



sencillas. XP tiene un enfoque adaptativo, en que la planificación del

proyecto progresa a medida que surgen cambios.

3.2.3.2 Problemas del Desarrollo del Software

Son los siguientes:

Retraso en la Planificación: Llegada la fecha de entrega el

software no esta disponible.

Sistemas deteriorados: El software se a creado pero después de

unos años el coste de su mantenimiento es tan complicado que

definitivamente se abandona su producción,

Tasa de defectos: El software se pone en producción pero los

defectos son tantos que nadie lo usa.

Requisitos mal comprendidos: El software no resuelve los

requisitos planificados inicialmente.

Cambios de negocio: El problema que resolvía nuestro software

ha cambia y nuestro software no se ha adaptado.

Falsa riqueza: El software hace muchas cosas técnicamente

interesantes y divertidas, pero no resuelve el problema de nuestro

cliente ni hace que este gane más dinero.

Cambios de personal: Después de unos años de trabajo, los

programadores empiezan a odiar el proyecto y lo abandonan.

XP trata de evitar estos riesgos en el desarrollo del software



3.2.3.3 ¿Qué es la Metodología XP?

eXtreme Programing, nace como una disciplina de desarrollo de

software hace aproximadamente 8 años.

Su autor es Kent Beck, programador que ha trabajado en muchas

empresas y que actualmente se encuentra como programador en una

prestigiosa empresa automovilística DaimlerChrysler.

XP, se basa en la SIMPLICIDAD, LA COMUNICACIÓN y EL

RECICLADO CONTINUO DE CÓDIGO, para algunos no es más que

aplicar una pura lógica.

XP, es una nueva disciplina para el desarrollo del Software, que ha

irrumpido recientemente en el maremágnum de métodos, técnicas y

metodologías existentes. Se trata de una metodología “ligera“ en

contraposición con las metodologías “pesadas” como Métrica.

3.2.3.4 Metodología XP

XP se basa en observar que es lo que hace que el desarrollo de un

programa sea rápido o lento.

XP es una Metodología impórtate por dos razones:

Primero y Principal, porque constituye un método de control para

las actividades de desarrollo de software. Que se han convertido en

métodos operativos estándares.

Segundo, es una de las pocas y nuevas metodologías ligeras

desarrolladas para reducir el coste del software



3.2.3.5 Objetivos de XP

La Satisfacción del Cliente

Esta metodología trata de dar al Cliente el Software que necesita y

cuando lo necesita. Por lo que se debe de responder muy rápido a

las necesidades del cliente, incluso cuando los cambios sean al final

de la programación.

Potenciar al Máximo el Trabajo en Grupo

Tanto los Jefes de Proyecto, los Clientes y Desarrolladores, son

parte del Equipo y están involucrados en el Desarrollo del Software.

3.2.3.6 Principios de XP

Los principios claves a través de los cuales se fundamenta la

metodología XP son:

Acortar los Ciclos de Desarrollo.

Involucrar al Cliente desde el principio hasta el final de cada Ciclo.

Las técnicas de trabajo que proporciona XP consiguen minimizar el

impacto que los cambios suponen en un proyecto de desarrollo del

software.

Acortar los ciclos de desarrollo y reforzar la comunicación con el

cliente permiten:

Centrarse cada vez en un muy problema concreto y en el momento

justo.



Solucionarlo de manera consensuada, inmediata, y no arrastrarlo a

lo largo del proyecto.

Comenzar cada nuevo ciclo de desarrollo sobre una versión

intermedia contrastada, verificada y aceptada por el cliente.

3.2.3.7 Las Cuatro Variables

XP define cuatro variables para proyectos de software: coste, tiempo,

calidad y ámbito.

Beck propone que solo tres puedan ser establecidas por las fuerzas

externas (Jefe de Proyecto y Cliente), mientras la cuarta les compete a

los programadores, la cual debe estar en función de las tres primeras.

3.2.3.8 El Coste del Cambio

Una de las suposiciones en la industria del software es que el coste de

los cambios en un programa crece exponencialmente con el tiempo.

Figura N° 02 Coste del Cambio Actual



XP, propone que si el sistema que empleas hace que el coste del

software aumente con el tiempo, se debe de actuar de forma diferente

a como lo hacemos.

XP, pretende que esta curva sea la contraria a través de la combinación

de buenas prácticas de programación (simplicidad del código y test

continuos de evaluación) y tecnología adecuada.

Figura N° 03 Coste del Cambio Propuesto

La programación Orientada a Objetos (POO), es una tecnología clave

para el mantenimiento del software. Esto no quiere decir no se pueda

tener flexibilidad sin programar orientado a objetos.

Programar Orientado a Objetos reduce el Coste del Cambio.

3.2.3.9 Los Cuatro Valores

Una de las cosas que los programadores deben tener muy claro es que

en el ciclo de vida del desarrollo de un proyecto de software los

cambios van a aparecer, tal así que cambiaran los requisitos, las reglas

del negocio, el personal, la tecnología, etc. Por lo tanto el problema no



es el cambio en si, si no la incapacidad de enfrentarnos a estos

cambios.

XP presenta estos cuatro valores:

Comunicación

La mayoría de los equipos de desarrollo de software han tenido

problemas por falta de comunicación, por no comentar un cambio

critico en el diseño, por no comentar lo que se piensa al Cliente y

por muchos otros factores.

XP ayuda mediante sus prácticas a fomentar la comunicaron.

Sencillez

Todo Desarrollador siempre debería de hacerse esta pregunta.

¿Qué es lo más simple que pueda funcionar?

La sencillez no es fácil, requiere de tiempo y esfuerzo.

XP, nos propone a hacer mas de lo que debemos: “Ya que estoy

tocando esta clase voy a añadirle un par de métodos mas para poder

visualizar los mensajes en colores”.

XP, nos dice que cuando algo no esta en los requisitos, puede que

mañana los necesite.

XP nos enseña a apostar, apuesta por hacer una cosa más sencilla

hoy y pagar mas mañana, si es necesario, que hacer cosas

complicadas hoy y no utilizarlas después.



La sencillez y la comunicación se complementan, cuando mas

simple es tu sistema, menos tienes que comunicar de el.

Retroalimentación

XP nos propone decir la siguiente frase:

“No me preguntes a mi, pregúntale al Sistema”, la cual es la primera

clave de la retroalimentación, por medio de pruebas funcionales a

nuestro software este nos mantendrá informado del grado de

fiabilidad de nuestro Sistema.

Los Clientes y las Personas que escriben pruebas tienen una

retroalimentación real del Sistema.

La retroalimentación actúa junto con la sencillez y la comunicación,

cuanto mayor retroalimentación más fácil es la comunicación.

Cuanto mas simple un Sistema mas fácil de probar.

Valentía

XP nos dice que debemos de asumir retos, ser valientes ante los

problemas y afrontarlos.

3.2.3.10 Las Cuatro Actividades Básicas

¿Qué tareas debemos de llevar a cabo para desarrollar un buen

software?

Codificar

La codificación es la única actividad de la que no se puede

prescindir. Sin código fuente no hay programa.



En una programación XP, el código expresa tu interpretación del

problema, así podemos utilizar el código para comunicar, para hacer

mías las ideas de los demás, y por tanto para aprender y mejorar.

Hacer Pruebas

XP nos dice que las características del software que no puedan ser

demostradas mediante pruebas simplemente no existen.

Las Pruebas permiten saber si lo que implementamos es realmente

lo que pensábamos que implementamos.

Las Pruebas nos indican que nuestro trabajo funciona.

Cuando no se puede pensar en ninguna prueba que pudiese originar

un fallo en nuestro sistema entonces se podrá decir que hemos

acabado por completo.

XP nos enseña a no hacer una prueba ver que funcione y salir

corriendo, nos enseña a que debemos de pensar todas las posibles

pruebas para nuestro código.

XP nos dice que las pruebas deben de ser sensatas y valientes.

Escuchar

Se debe de tener en cuenta que los Programadores no lo conocen

todo, y sobre todo muchas cosas que las personas del negocio

piensan que son interesantes.

XP nos enseña a escuchar a nuestros clientes cuales son los

problemas de su negocio, debemos de tener escucha activa

explicando lo que es fácil y difícil de obtener.



Diseñar

El Diseño crea una estructura que organiza la lógica del Sistema.

XP, nos dice que los diseños deben de ser sencillos y que si alguna

parte del sistema es de desarrollo compleja debemos de dividirla en

varias partes.

Conclusión: Tenemos que codificar porque sin código no hay

programas, tenemos que hacer pruebas porque sin pruebas no sabes si

lo que hemos implementado es lo correcto, tenemos que escuchar,

porque si no escuchamos no sabemos que codificar ni probar y

tenemos que diseñar para poder codificar, probar y escuchar

indefinidamente.

3.2.3.11 Fases de La Metodología XP

Las normas básicas de XP giran en torno a las cuatro fases

principales del desarrollo: planificación, diseño, programación y

comprobación. En todas estas fases, XP insiste en que un

representante del cliente debe formar parte del equipo de desarrollo a

tiempo completo. Eso no significa que el representante del cliente

tenga que trabajar todo el tiempo con el equipo, pero en lo que XP es

inflexible es en que algún representante del cliente esté en todas las

reuniones del equipo (en las ocasiones en que no es físicamente

posible, tendrá que asignarse a alguien del equipo el cometido de

apoderado del cliente). En XP, a un equipo competente, motivado y

equilibrado se le denomina equipo completo. La integración y la



interacción del equipo completo es clave en prácticamente todos los

aspectos de XP.

A) Planificación. La planificación de un proyecto XP se centra en

las historias de usuario, que son la versión de XP de lo que solían

llamarse requisitos. En el auténtico estilo XP, la verborrea se

intercambia por definiciones concisas y sin rodeos sobre lo que se

tiene que hacer. Las historias de usuario son cortas (de entre 25 y

50 palabras), dan un objetivo principal al proyecto, proporcionan

metas y sientan las bases para hacer estimaciones (con una

participación muy importante del representante del cliente).

Utilizando una estrategia del tipo "divide y vencerás", XP razona

que si una historia de usuario (especificación) no puede

describirse en 50 palabras, es demasiado larga y ha de convertirse

en más de una. Las historias de usuario también sirven para crear

pruebas de aceptación. Tras determinar qué hay que hacer, XP

obliga a que, antes de ponerse a escribir código, se determinen los

indicadores que nos servirán para determinar el éxito (¡definidos

por todo el equipo!) de esa historia de usuario. Descubrirá que

XP también utiliza el concepto de éxito cuantificable de otras

formas.

Las historias de usuario dividen el proyecto en iteraciones. A

partir de estas iteraciones se harán versiones bien acotadas y

frecuentes del proyecto. A diferencia del modelo en cascada, al

proceso se le darán muchas vueltas de manivela ya que cada vez



que se crea una historia de usuario nueva, el proceso vuelve a

empezar.

Aunque no se menciona explícitamente, uno de los objetivos de

las historias de usuario y de las pruebas de aceptación es "no

llevarse sorpresas". El equipo de desarrollo y el representante del

cliente incorporado en el equipo están implicados tanto en la

planificación como en la determinación de los medios para saber

cuándo se ha entregado lo que se había previsto. Es muy sutil,

pero al facultar al cliente para que escriba tanto las historias de

usuario como las pruebas de aceptación, está eliminando, o por lo

menos minimizando, la posibilidad de que el cliente le cuele

como quien no quiere la cosa unas cuantas especificaciones

nuevas. (Si la mayoría de los programadores consiguieran tener

claro esto antes de escribir una sola línea de código, iríamos por

delante en el partido).

B. Diseño. Uno de los valores principales del diseño de XP es

"conservar la simplicidad". Un proyecto conducido por esta

metodología se lleva a cabo a base de iteraciones a lo largo de

todo el ciclo del proyecto. Por lo tanto, una forma de simplificar

las cosas es posponiendo la complejidad. En el modelo de

cascada, los diseñadores del proyecto estaban obligados a

planificar cualquier contingencia por adelantado (los ciclos

iterativos no formaban parte del modelo en cascada). En XP, se

sugiere que se diseñe e instale solamente lo que es necesario para



hacer avanzar la jugada y posponer tanta complejidad como se

pueda a otra iteración. Insistir en la simplicidad no significa que

lo que haga no sea inherentemente complejo; es simplemente que

la intención de XP es seleccionar la forma más sencilla de hacer

el trabajo.

En la mayoría de los proyectos de programación, al equipo de

programación se le encargan desafíos con los que no están

totalmente familiarizados. Para evitar que desafíos interminables

desbaraten el proyecto, XP ofrece un pico para esas

circunstancias. Un pico sería parecido a lo que solemos llamar

"prueba de concepto" donde un grupo de programadores hace

frente a una parte especialmente problemática o desconocida del

proyecto, mientras los demás miembros del equipo siguen

trabajando en el resto del proyecto.

Otro concepto importante de XP es la "refactorización" del

código. La "refactorización" del código es el proceso de depurar

u optimizar el código sin cambiar su comportamiento. La

"refactorización" nos obliga a examinar el código después de que

funcione (realmente no necesita dos subrutinas, o leer el archivo

dos veces, ni esas variables intermedias, ¿a qué no?). XP nos

hace aplicar la "refactorización" obstinadamente dónde y siempre

que se pueda; forma parte de los procesos que hacen que las

cosas sean más sencillas.



C) Programación. XP tiene varias rutinas de programación, algunas

de las cuales son muy predecibles. Por ejemplo, utilizar

estándares previamente acordados y posponer la optimización (es

decir, primero hacer el trabajo y luego hacerlo funcionar deprisa)

no son ideas demasiado revolucionarias. Pero XP incide de una

forma especialmente extrema en ello. XP obliga a programar por

parejas. Esta rutina no solo significa la revisión del código por un

compañero; frente a cada ordenador debe haber dos sillas,

ocupadas por un "piloto" y un "navegante". ¡Siempre! Con

frecuencia se cambian las funciones, así como de compañero.

Este es quizás uno de los aspectos más difíciles de cumplir de XP

para la mayoría de los departamentos de informática. Pero Beck

insiste en que dos programadores en un solo ordenador son tan

productivos como dos programadores en dos ordenadores... y que

los niveles de calidad y productividad son mucho mayores.

XP también obliga a escribir pruebas de unidad antes que el

código, lo que refleja la propensión de XP a crear indicadores en

el sistema. Aunque se utilizan pruebas en la fase de

comprobación, se escriben antes (o al mismo tiempo) que el

código que se va a comprobar. Las pruebas de unidad se escriben

como parte integral del proyecto y se ejecutan en cada ciclo

iterativo conforme se añaden más funciones. No se puede

continuar hasta que se pasan todas las pruebas. Las pruebas de

unidad sin duda ayudan a garantizar la calidad del código, pero

también ayudan a impedir que se cuelen sigilosamente otras



funciones; al escribir la prueba antes que el código, éste se

escribe para superar la prueba y no para incluir otra virguería que

se le acaba de ocurrir.

XP es dogmático por lo que hace a la regla de que el equipo de

programación no haga horas extras. XP afirma que las horas

extras consumen la vida de la gente y que si para llevar adelante

un proyecto se necesitan horas extras, de todas formas se

entregará tarde, de modo que las horas extras no son la solución

del problema.

D) Comprobación. XP demanda pruebas de unidad para todo el

código y que éste supere todas esas pruebas. No hay sustitutos ni

atajos. En los lenguajes Java y .NET existen bibliotecas y

productos pensados para desarrollar pruebas de unidad. Para ILE

RPG y RPG/400 no debería ser demasiado difícil crear las suyas

propias. Naturalmente, el gran obstáculo para esta intrépida

estrategia de comprobación son los plazos de entrega que se

vislumbran en el horizonte. Sin embargo, no sea corto de miras y

piense en la comprobación solamente como un molesto trabajo

monótono. Durante la duración del proyecto, las comprobaciones

automáticas son los mejores indicadores para encontrar y

eliminar errores de programación. XP justifica unas

comprobaciones tan rigurosas aún con más vehemencia: "cuanto

más difícil es escribir una comprobación, más necesaria es,

puesto que mayores serán sus beneficios". Además, recuerde que



esta comprobación no es uno de los últimos pasos del proyecto;

es un paso que se ha de dar constantemente a lo largo de todas las

versiones del proyecto.

3.2.3.12 Críticas:

XP tiene muchas criticas, por parte de aquellos programadores

apegados al código, piensan que ellos son los mejores conocedores

de las herramientas y lenguajes que utilizan y que si no lo entiendes

es por que no sabes lo suficiente.

Dicen que XP, solo puede funcionar con programadores muy

buenos, que puedan hacer un buen diseño, sencillo y fácilmente

extensible.

XP es mas una filosofía de trabajo que una metodología.

XP esta diseñado para grupos de pequeños programadores.

3.2.3.13 Comparación con Metodologías Tradicionales

XP ha causado gran revuelo en la comunidad de la Ingeniería del

Software.

Las metodologías tradicionales imponen un proceso disciplinario

para tratar de hacer el trabajo predecible, eficiente y planificado.

Estos están orientados a documentos y se vuelven demasiado

burocráticos e ineficientes.



Figura N° 04 Comparación de Metodologías Tradicionales con XP

XP es más liviana y ágil y están orientadas más a las personas que a

los procesos.

XP supone:

Las personas son claves en los procesos de desarrollo.

Los programadores son profesionales no necesitan supervisión.

Los procesos se aceptan y se adecuan, no se imponen.

Desarrolladores y gerentes, comparten el liderazgo del proyecto.

El trabajo de los desarrolladores con las personas que conocen el

negocio es regular, no puntual.

3.2.3.14 Respaldo:

XP tiene aproximadamente 8 años de vida pero cuenta con un gran

respaldo por parte de grandes empresas como: Ford,

DaimlerChrysler, First Union National Bank -USA-, etc. Que lo

que buscan en definitiva es la reducción de coste.



3.2.4 Herramientas Utilizadas

3.2.4.1 Power Builder

Introducción

Power Builder es un tipo de programación orientada a objetos. El

ambiente de desarrollo que trabaja el Power Builder es grafica.

Power Builder proporciona todas las herramientas que se necesita

para construir aplicaciones empresariales, como la entrada de datos,

contabilidad y los sistemas industriales.

Aplicaciones Multiusuario

Las aplicaciones de Power Builder pueden ser aplicaciones de

multiusuario o de Cliente/Servidor que se trabaja en forma grafica y

que pueden acceder a las bases de datos del servidor. Una

aplicación cliente/servidor tradicional es una colección de ventanas

que contienen mandos con que los usuarios puedan actuar

recíprocamente.

También se puede construir aplicaciones multiusuario con Power

Builder. Una aplicación multiusuario (distribuido) posee

normalmente una aplicación de cliente, que hará uso de los servicios

de una aplicación del servidor.

Las Aplicaciones de Internet

Se puede utilizar aplicaciones Web Based en Power Builder. Una

aplicación Web-Based puede crearse originalmente para Internet o



puede realizarse en una aplicación de Power Builder existente que

va hacer extendida a la Internet.

El desarrollo de la Cross-Platform (Plataforma de Cruz)

Power Builder apoya el desarrollo en Cross-Platform y su

despliegue. Se puede desarrollar una paliación que usa Power

Builder bajo Windows y puede desplegar la misma aplicación sin

ningún cambio en UNIX. Se puede tener un equipo de Cross-

Platform de diseñadores, incluso, algunos que usan Windows y

algunos usando UNIX, desarrollando la misma aplicación al mismo

tiempo. Ellos pueden compartir objetos de Power Builder usados en

la aplicación libremente, porque los objetos son los mismos por las

plataformas de la informática diferentes, que son apoyados por el

Power Builder.

Las aplicaciones

En Power Builder se trabaja siempre en el contexto de una

aplicación. Cuando se crea una aplicación, se nombra el objeto de la

aplicación y se especifica una biblioteca de la aplicación para el

objeto y los otros objetos que creara.

Los Objetos

La aplicación es una colección de objetos de Power Builder.

Conforme se trabaja el la aplicación podrá ir creando nuevos

objetos y abrir los existentes para seguir trabajando.



Painters

Usted construye los objetos en su aplicación que usa editores del

objeto llamados painters. Power Builder mantiene al painter cada

tipo de objeto.

Usted construye una ventana en el painter de la Ventana. Allí se

define las propiedades de la ventana, agrega los mandos como los

botones y luego revisa los mandos y codifica la ventana y sus

mandos para trabajar como su aplicación lo requiere

Las Bibliotecas

Los objetos que se crean se guardan en una o más bibliotecas

(Archivo PBL) asociado con la aplicación. Cuando se ejecuta la

aplicación, Power Builder recupera los objetos de la Biblioteca.

Power Script

PowerScript, es el idioma de Power Builder. Las escrituras

consisten en órdenes de PowerScript, funciones, y declaraciones

que realizan el proceso en la contestación a un evento.

PowerScript proporciona un surtido rico de funciones incorporadas

que pueden actuar en varios componentes de la aplicación.

Power Builder 10.0

La más nueva versión de la herramienta de desarrollo del favorito

4GL RAD de los markets. Permite a los desarrolladores construir

rápidamente y fácilmente los usos conducidos, los datos que los



negocios necesitan para conseguir el trabajo hecho. La versión más

última se embala por completo de nuevas características para

construir los tipos de usos que los negocios necesiten hoy.

Ventajas:

• Costes reducidos - Simplifica grandemente el desarrollo y

el despliegue de los usos conducidos de los datos del nivel

de la empresa. Permite conseguir sus proyectos hechos

más rápidamente.

• Versátil – Permite construir la tela, el tablero del

escritorio y los usos donde quiera que se encuentren sus

usuarios. La herramienta proporciona datos conducidos, la

solución para el tablero del escritorio, tela del desarrollo

del uso, y distribución a usuarios.

• Alta productividad – Permite conseguir el trabajo hecho,

rápido. Construcción de los usos intensivos de los datos

para que funcione su negocio sobre solamente horas o

días, con la codificación mínima.

• Reducción al mínimo del riesgo - La tecnología ha sido

probada, por centenares de millares de desarrolladores,

ellos se asegura de que usted está trabajando con un

producto tan solidó como la roca.

• Desarrollo de las velocidades - El RAD 4GL IDE con

centenares de funciones y de características incorporadas

reduce la cantidad de codificación requerida.



• Alza el funcionamiento de su empresa - Con la ayuda

para el NET y la integración con las plataformas de JÈE,

PowerBuilder es la única herramienta que consigue el

trabajo hecho más rápidamente que cualquier otro.

Características de las Ediciones de PowerBuilder

La tabla siguiente identifica las características principales

disponibles en la empresa, el profesional, y las ediciones de

escritorio de PowerBuilder 10



Tabla N° 01 Características de PowerBuilder

PowerBuilderFeature Empresa Profesional Tablero del escritorio

Plug-in de PowerDesigner sí no no Kit nativo del desarrollo del software del interfaz de PowerBuilder

sí no no

Desarrollo de la blanco de JSP sí no no Desarrollo de la blanco de la tela sí no no Desarrollo de cliente de EJB sí no no Servicios de la tela para los clientes de PowerScript

sí no no

Servicios de la tela para los clientes de JSP

sí no no

Servicios de XML (modelo del objeto del documento de PowerBuilder)

sí no no

Tela DataWindow sí no no Desarrollo y despliegue componentes de EAServer

sí no no

Desarrollo componente y despliegue de COM/COM+

sí no no

Interfaz del SCC para el control de la fuente

sí sí no

Utilidad de OrcaScript sí sí sí Ayuda de ODBC Acceso

Completo Acceso

Completo Bases de datos De escritorio Solamente

Ayuda de XML en el DataWindow sí sí sí DataWindow ahorra como pdf sí sí sí Servidor adaptante dondequiera para el desarrollo

sí sí sí

Del Servidor Edición Runtime De escritorio Adaptante Dondequiera

sí sí sí

Ayuda almacenada del procedimiento sí sí no Ayuda de ADO.NET sí no no Ayuda de JDBC sí no no Ayuda OLE del DB sí no no Conductores nativos del DBMS sí no no InfoMaker sí no no Caja de herramientas De la Traducción

sí no no

Embalador Runtime sí no no Biblioteca de PBCryptography sí no no Monitor Del Recurso sí sí sí



3.2.4.2 SQL Anywhere

Introducción

SQL Anywhere Studio es un completo paquete que provee manejo

de datos y sincronización empresarial para permitir el rápido

desarrollo y despliegue de soluciones e-Business distribuidas.

Optimizado para grupos de trabajo, laptops y dispositivos

"handheld", SQL Anywhere Studio extiende el alcance de la

información del e-Business corporativo hacia cualquier lugar donde

ocurran transacciones del negocio.

SyBase es el editor de SQL Anywhere Studio, un gestor de datos

que aporta una solución de sincronización adaptada a las pequeñas y

medianas empresas, de tal manera que uno pueda acceder desde

cualquier lugar y momento a toda la información corporativa que

necesite, con soporte para un gran número de estándares y

plataformas y, especialmente indicado en el caso de las bases de

datos móviles, embebidas y las aplicaciones basadas en Web; la

solución para usuarios móviles.

SQL Anywhere Studio es un exhaustivo paquete de herramientas de

gestión de datos para la empresa, con avanzadas opciones de

sincronización y administración adaptados al desarrollo de

soluciones en un entorno móvil y distribuido, como por ejemplo su

soporte XML, servicios Web, servidor de sincronización, tecnología

.NET, funcionalidades SQLX, servidor http y soporte SOAP, etc.

Optimizado para grandes bases de datos, ofrece un rendimiento

óptimo, con la posibilidad de realizar peticiones complejas con



mayor seguridad. A nivel de usuabilidad, ofrece un entorno de

desarrollo sencillo, que facilita su manejo y cubre las necesidades

de toda clase de negocios. En definitiva, SQL Anywhere Studio es

una solución de difusión de información empresarial a dispositivos

móviles e inalámbricos de la más completa, flexible y robusta

actualmente disponible.

Diferencias entre el Servidor Personal y el Servidor de Red de

Adaptive Server Anywhere

Las bases de datos de Adaptive Server Anywhere (ASA) se

almacenan en archivos de disco. El servidor de bases de datos ASA

es la pieza de software que maneja la base de datos. Hay dos

versiones del servidor de base de datos: el Servidor de Bases de

Datos Personal (o Personal Database Server) y el Servidor de Bases

de Datos de Red (o Network Database Server). Ambas versiones

comparten funcionalidad común de base de datos pero ofrecen

distintas capacidades en sus servicios de red. También, ambas

versiones pueden participar en un sistema de replicación de ASA en

el cual las modificaciones a los datos son aplicadas a los datos

correspondientes en otras bases de datos. Cabe anotar que las

aplicaciones desarrolladas sobre el servidor personal trabajan sin

modificaciones sobre el servidor de red, haciendo que el servidor

personal sea ideal para ambientes de desarrollo.



El motor de procesamiento de requerimientos es idéntico en los dos

servidores: cada uno soporta exactamente el mismo SQL y

exactamente las mismas características de base de datos.

El Servidor de Bases de Datos Personal (Personal Database

Server)

El servidor personal se provee para uso monousuario, en una

misma máquina. El servidor personal opera como una tarea del

sistema operativo en un computador de usuario y soporta hasta

10 conexiones concurrentes y puede recibir requerimientos para

recuperación, actualización, y otras operaciones desde

aplicaciones cliente en la misma máquina, como se muestra en

el siguiente diagrama:

Figura N° 05 Servidor de Base de Datos Personal

El servidor personal es invocado usando los siguientes

Ejecutables:

Plataformas Windows (95/98/XP/Me/NT/2000): dbeng8.exe



Plataformas basadas en UNIX: dbeng8

El Servidor de Bases de Datos de Red (Network Dabase Server)

El servidor de red está orientado a uso multiusuario y soporta

comunicaciones cliente-servidor a través de una red. Recibe

requerimientos para recuperación, actualización y otras

operaciones a través de una red desde aplicaciones cliente, como

se muestra en el siguiente diagrama:

Figura N° 06 Servidor de Base de Datos de Red

Las aplicaciones cliente pueden residir en máquinas distintas a

la máquina en la que reside el servidor de red. El número de

clientes que se pueden conectar a un servidor de red está

determinado por las licencias de ASA, así como de la capacidad

disponible de su red y de su hardware servidor. Una vez un

cliente está conectado al servidor de bases de datos, se le

permite un número ilimitado de conexiones a la base de datos.



El servidor de red se invoca usando los siguientes ejecutables:

Plataformas Windows (95/98/XP/Me/NT/2000): dbsrv8.exe

Plataformas basadas en UNIX: dbsrv8

Novell NetWare: dbsrv8.nlm

Las bases de datos personal y de red tienen el mismo motor de

procesamiento de requerimientos. Las diferencias entre los dos

servidores son en la parte de red, licenciamiento y opciones de

configuración, y pueden ser resumidas así:



Tabla N° 02 Diferencias entre las Bases de Datos Personal y de Red

Personal Server Network Server

Soporte al protocolo de red No Si

Número máximo de conexiones 10 Determinado por el

licenciamiento

Número máximo de CPUs 2 Ilimitado

Opción –ga: descargar base de datos después de la última desconexión

La base de datos se descarga y el servidor se baja después de la última desconexión

La base de datos se descarga después de la última desconexión

Opción -gd: permiso requerido para arrancar la base de datos

Definida en ALL por defecto

Definida en DBA por defecto

Opción -gk: permiso requerido para parar la base de datos usando el utilitario DBSTOP

Definida en ALL por defecto


Opción -gl: permiso requerido para cargar datos usando LOAD TABLE o para bajar datos usando UNLOAD TABLE o UNLOAD

Definida en ALL por defecto para plataformas diferentes a UNIX

Definida en DBA para plataformas UNIX


Opción -gn: Número de requerimientos que la base de datos puede manejar a la vez

10 por defecto 20 por defecto



Consideraciones para Ejecutar Backups y Validaciones en

Adaptive Server Anywhere

Dentro de las nuevas posibilidades administrativas que Adaptive

Server Anywhere (ASA) incluye desde la versión 7.0, las utilidades

DbBackup y DbValid pueden ser ejecutadas mientras ASA está

corriendo.

Utilidad de Validación - DbValid

Con la utilidad de validación desde línea de comando DbValid, se

pueden validar los índices y las llaves sobre algunas o todas las

tablas de una base de datos. Esta utilidad verifica la tabla

completa, y confirma que cada una de las filas se encuentra en los

índices asociados. Esta utilidad es equivalente a la instrucción

vlidate table sobre cada tabla.

Sintaxis:

dbvalid [ opciones ] [ nombre-objeto,... ]



Tabla N° 03 Validación de la Base de Datos

nombre-objeto :

El nombre de una tabla ó el nombre de un índice (si la opción -i es usada) que desea ser validado

opciones : -c "keyword=value; ..." : Parámetros de conexión a la base de datos

-o nombre-archivo: Archivo de log de la ejecución de la validación

-f : Valida tablas haciendo un chequeo total (full check)

-fd :Valida la data de las tablas (data check)

-fi : Valida los índices de las tablas (index check)

-I : Cada nombre-objeto es un índice

-q : Modo silencioso — no imprime mensajes

-t : Cada nombre-objecto es una tabla

Ejemplo:

La siguiente instrucción valida la base de datos de ejemplo

asademo.db, conectándose a ASA con el usuario DBA y

contraseña SQL:

D:\> dbvalid -c "uid=DBA;pwd=SQL;dbf=

c:\asa\asademo.db"

Utilidad de Backup - DbBackup

DbBackup permite generar copias de respaldo para una base

de datos en ASA. Se manejan copias de respaldo totales ó

copias del log de transacciones (backup incremental).

Antes de tomar un backup con DbBackup es importante saber

que cuando una base de datos ASA se cierra (shutdown), los



archivos de la misma mantienen un copia actual y completa de

todos los datos existentes en la base de datos. Cuando una base

de datos está en ejecución, los archivos generalmente no

reflejan el estado actual inmediato de los movimientos que

sobre ella se efectúan. El único momento en el que se puede

garantizar que la base en ejecución está completa y

actualizada es cuando un checkpoint toma lugar en la base de

datos. Al momento de un checkpoint, la información contenida

en el caché de la base de datos se escribe a disco. El servidor

ASA efectúa un checkpoint en alguna de las siguientes

condiciones:

• Como parte de la operación de shutdown de la base de datos.

• Cuando la cantidad de tiempo transcurrido desde el último

checkpoint excede el valor configurado en la variable

CHECKPOINT_TIME

• Cuando desde una conexión se invoca explícitamente la

instrucción checkpoint.

Sintáxis:

dbbackup [ opciones ] [ directorio ] archivo



Tabla N° 04 Backup de la Base de Datos

opciones : -c "keyword=value; ..." : Parámetros de conexión a la base.

-d : Efectúa backup únicamente del archivo main de la base de datos.

-l nombre_archivo : (Live Backup) Backup en caliente del log de transacciones.

-n : Cambia el nombre al backup del log de transacciones.

-o nombre_archivo: Escribe un archivo de salida con el log de la operación.

-q : Modo Silencioso: no imprime mensajes.

-r : Renombra e inicializar un nuevo archivo de log de transacciones para la base de datos a la que se le efectúa el backup.

-t : Hace backup únicamente del log de transacciones.

-w : Hace backup únicamente del write file.

-x : Borra y reinicializa el log de transacciones.

-xo : Borra y reinicializa el log de transacciones sin hacer backup.

-y : Reemplaza archivos sin efectuar confirmación.



Si no se utilizan ninguna de las opciones -d, -t, -w, todos los

archivos de bases de datos son respaldados.

La opción Live backup (-l) se desarrolló con el fin de habilitar

un ambiente secundario que puede ser puesto en marcha

rápidamente en el evento de una caída o falla del servidor. Un

live backup se mantiene en ejecución mientras el servidor de

base de datos también lo haga. Cuando el servidor tiene un

problema y cae, el live backup acaba, dejando un backup del

log de transacciones intacto para poder ser usado en un

ambiente secundario en corto tiempo.

Ejemplo:

Un archivo por lotes que puede implementar para efectuar una

copia de respaldo. Dicho ejemplo valida y hace el backup de la

base, si ocurre un error el proceso se detiene.

@echo off

cls

rem if %1. == . goto usage

echo Validando Base de Datos

dbvalid -f -q -c "eng=mydb;dbn=mydb_db;uid=dba;pwd=sql"

if errorlevel 0 goto backupdb

echo ===============================

echo Error Code - %errorlevel%



echo Error en la validación - no se completó el backup

echo ===============================

goto stayopen

:backupdb

echo Creando Backup

dbbackup -x -y -q -c

"eng=mydb;dbn=mydb_db;uid=dba;pwd=sql"

"d:\backupfiles\mydb”

if errorlevel 0 goto done

echo ===============================

echo Error Code - %errorlevel%

echo Error in DB backup - no backup completed

echo ===============================

goto stayopen :done

exit

:usage

echo -

echo usage:

echo backit {backup directory}

echo -

:stayopen



Migración de las Aplicaciones de Microsoft Access a Sql

Anywhere sin sacrificar la interfaz de usuario de la Aplicación

Muchas veces existen problemas con las constantes reparaciones a

los datos y dificultades al conectar múltiples usuarios a Microsoft

Access, usted puede pasarse a SQL Anywhere Studio para obtener

el rendimiento y funcionalidad que le hace falta, sin tener que

rescribir sus aplicaciones Access.

A medida que su grupo de trabajo crece, usted necesita un

repositorio de datos que pueda acomodar los crecientes

requerimientos de confiabilidad y accesibilidad de los datos. SQL

Anywhere Studio provee las más poderosas características

disponibles en un DBMS escalable, de bajo consumo de recursos, y

verdaderamente cliente/servidor. Además, ya que nuestra base de

datos, líder en la industria, corre tras las escenas de su aplicación,

sus usuarios podrán mantener la interfaz a la cual están

acostumbrados.

El Utilitario de Migración de SQL Anywhere para MS Access (SQL

Anywhere for MS Access Utility) es un programa que migra

bases de datos con tecnología Microsoft JET a bases de datos

Adaptive Server Anywhere, incluido en SQL Anywhere Studio.



Levantamiento de Múltiples bases de datos con Adaptive Server

Anywhere

Arrancando el Servidor de Bases de Datos

Cuando arranca el servidor de bases de datos, se debe incluir todos

los nombres de los archivos de bases de datos en la línea de

comandos. También debe especificar explícitamente el nombre de

motor de bases de datos con la opción –n.

La sintaxis general de la línea de comandos del servidor es la

siguiente:

ejecutable [ opciones-de-servidor ] [ archivo-base-de-datos [

opciones-base-de-datos ], ... ]

Ejemplos:

1. Usando el servidor personal:

DBENG8.EXE -n mi_servidor c:\path\data1.db -n db1

c:\path\data2.db -n db2

2. Usando el servidor de red:

DBSRV8.EXE -n mi_servidor c:\path\data1.db -n db1


Estos comandos arrancan el servidor de bases de datos con el

nombre mi_servidor. A las bases de datos c:\path\data1.db y



c:\path\data2.db se les asignan los alias db1 y db2,

respectivamente.

Arrancando el Servidor de Bases de Datos con un Archivo de

Parámetros

También se puede crear un archivo que contenga los parámetros que

desea pasar al ejecutable del servidor de bases de datos. Por

ejemplo, usted podría crear el archivo mi_servidor.cfg con las

siguientes líneas:



Luego se podría arrancar el servidor de bases de datos usando la

siguiente sintaxis:

DBSRV8.EXE -n mi_servidor @mi_servidor.cfg

Usar un archivo de parámetros puede ser particularmente útil al

cargar el NLM de Adaptive Server Anywhere bajo sistema

operativo Novell Netware.




Capitulo IV.

METODOLOGÍA


METODOLOGÍA

4.1 PROCEDIMIENTO

4.1.1 Fases de la Metodología:

4.1.1.1 Planificación:

• Historias de Usuario

- Controlar el Número de Historias Clínicas, evitando que halla

pacientes con el mismo número de historia.

- Reducir el tiempo de Búsqueda de Historias Clínicas, pues de

esta manera se reduciría los tiempos muertos y podría atender a

más pacientes.

- Apoyar a la toma de decisiones, el sistema debe de brindar

reportes estadísticos para poder tomar decisiones correctas así

como poder realizar consultas que puedan surgir.

- Facilidad de uso del Sistema, de tal manera que sean pocos los

pasos que deba realizar el cliente para poder manejar el sistema,

así como también la estética de la aplicación debe ser la más

adecuada.

- Uso de accesorios, que el sistema debe de brindar para mayor

comodidad.

- Registrar, Eliminar, Actualizar, Buscar, la data.

- Capacitación sobre el uso del Sistema a los usuarios.



• Release Planning

Tabla N° 05 Release Planing Prioridad Historia de Usuario Versión Tiempo

(Fecha) 1 Diseño de la Base de

Datos, Pantallas para ingreso y salida de la data. (*)

1 al 6 13/07/05 al

30/07/05

2 Registrar, Eliminar, Actualizar, Buscar, la data.

6 al14 13/07/05 al

31/08/05 3 Controlar el Número de

Historias Clínicas. 6 al 14 01/08/05

al 31/08/05

4 Reducir el tiempo de Búsqueda de Historias Clínicas.

6 al 14 01/08/05 al

31/08/05 5 Apoyar a la toma de

decisiones. 15 al 17 01/09/05

al 10/09/05

6 Uso de accesorios, así como la facilidad de uso del Sistema

18 12/09/05 al

14/09/05 7 Capacitación sobre el

uso del Sistema a los usuarios.

1al 20 16/07/05 al

21/09/05

Otro de los parámetros que se toma en cuenta en el “Release

Planing”, es el número de desarrolladores que se encargaran de

realizar cada historia de usuario; en nuestro caso debido a que el

sistema es pequeño lo realizan el desarrollador conjuntamente con

el representante de la Institución Médica.

(*) No forma parte de las historias de usuario.



4.1.1.2 Diseño:

Para el Diseño, se pidió las opiniones de los usuarios para así poder

hacer un diseño lo mas sencillo posible, de tal manera que los usuarios

se familiaricen en menos de 5 minutos con el sistema.

También se recurrió a tomar los diseños de algunos proyectos hechos,

los cuales se encuentran en el Internet.

Juntando: las sugerencias del los usuarios, diseños de proyectos

hechos y la experiencia y aportación del desarrollador se realizaron las

pantallas con una gran originalidad, de tal manera que los usuarios

pudieran acceder a la información que necesitaban desde cualquier

punto de la Aplicación.

4.1.1.3 Programación:

Se hace referencia a la programación en pareja, la cual estuvo

conformada por el Desarrollador y el Representante del

Establecimiento, pues mientras el desarrollador implementaba las

historias de usuario (requerimientos) el Representante iba haciendo las

sugerencias respectivas así como aportaciones para mejorar el sistema.

Se realizaron Pruebas de Unidad antes que el mismo código, para

garantizar la calidad del coligó.

4.1.1.4 Comprobación:

En esta parte se verificó que nuestro código superara todas las pruebas

de unidad, y de esta manera poder los errores de programación. Esta



comprobación se hizo constantemente a lo largo de todas las versiones

del proyecto.

4.2 TIPO DE INVESTIGACIÓN

Aplicada y Experimental.

4.3 MÉTODO DE INVESTIGACIÓN

Inductivo – Deductivo.

El método en que me basare para llegar a la veracidad de la hipótesis será a través

de encuestas, entrevista personal y observación (Método Inductivo - Deductivo);

dichas encuestas estarán conformadas por preguntas de cómo se realiza el proceso

de atención a los pacientes en el Puesto de Salud San Pedro. Esta encuesta estará

aplicada al área de admisión así como a las áreas de atención médica (medicina,

obstetricia y enfermería) antes de la aplicación del Sistema de Admisión.

Posteriormente se realizara cuestionarios con preguntas acerca del desenvolvimiento

del software. Estos cuestionarios serán aplicados a las diferentes áreas del Puesto de

Salud después de la instalación del Sistema.

Estos cuestionarios servirán para medir la automatización que se logrará con el uso

del Sistema de Admisión, como también servirán para ver si la interfaz del sistema

es amigable.

Se debe de tener en cuenta que como se esta trabajando bajo la Metodología XP,

estas entrevistas serán constantemente, pues el personal del puesto de salud forma

parte del equipo de desarrollo.



Una vez que se hayan aplicado las encuestas y los cuestionarios, se podrá evaluar

los resultados obtenidos antes y después de la aplicación del Sistema de Admisión y

verificar si la hipótesis formulada se cumple.

4.4 DISEÑO DE INVESTIGACIÓN

4.4.1 Variables

Dada la naturaleza del problema la variable dependiente tendrá que ser

caracterizada, para lo cual se realiza la operacionalización de la hipótesis de

investigación, tal como se muestra a continuación.

4.1.1.1 Variable Independiente (X):

X = Desarrollo de un Sistema de Información.

4.1.1.2Variables Dependientes (Y, W, Z):

• Y = Control de Historias Clínicas.

Indicadores:

y1 = Reducción de los tiempos muertos en la búsqueda de historias

clínicas.

y2 = Evitar la redundancia del número de Historias Clínicas.

y3 = Reducción del espacio utilizado para almacenar historias

clínicas impresas. [1]

• W = Optimización de Ingresos Económicos.

Indicadores:

w1 = Mas atenciones.



w2 = Reducción de gastos en la compra de papel para la impresión.

[1]

• Z = Ayuda a la Toma de Decisiones.

Indicadores:

z1 = Confiabilidad en las decisiones a tomar.

[1] Estos indicadores se demostrar en un futuro pues el establecimiento a un no

cuenta con más PCs

4.5 DISEÑO EXPERIMENTAL

De la Hipótesis se establece que para mejorar el control de historias clínicas,

optimizar los ingresos económicos y ayudar a la toma de decisiones en el Puesto de

Salud San Pedro, se debe de demostrar que:

• Se reducirá el tiempo muerto que se origina el la búsqueda de historias

clínicas.

• Evitara la duplicación del número de historias clínicas.

• Se atenderá a más pacientes debido al ahorro de tiempo.

Donde:

X : Variable Independiente.

Y, W, Z : Variables Dependientes.

Y (y1, y2) X W (w1) Z (z1)



y1, y2 : Indicadores de Y.

w1 : Indicador de W.

z1 : Indicador de Z.

Dada la naturaleza de la hipótesis, el diseño a aplicar al proyecto es: Series

Cronológicas de un solo Grupo.

Este grupo estará conformado por usuarios de las áreas de: Jefatura, Atención

Medica, Admisión.

A estas áreas se le aplicaran varias Pre-Pruebas, después se le aplica el tratamiento

experimental y finalmente varias Post-Pruebas. El diseño podría diagramarse de la

siguiente manera.

D

4.6 COBERTU

4.6.1 Poblac

Puesto

Edgar Alexander

G O1 O2 O3 X O4 O5 O6

onde:

G : Grupos

O1, O2, O3 : Pre-Pruebas.

X : Variable Independiente.

O4, O5, O6 : Post-Pruebas.

RA DE ESTUDIO

ión:

de Salud San Pedro - Chimbote

Cruz Huaman 63


4.6.2 Muestra:

Para medir los indicadores de las variables dependientes se utiliza un

cuestionario (Ver Anexo B), aplicándolo a la muestra selectiva de los grupos

seleccionados (Personal de Admisión, Tópico y Jefatura).

4.7 TÉCNICAS E INSTRUMENTOS

Tabla Nº 06 TÉCNICAS INSTRUMENTOS

• Observacion. • Encuestas. • Cuestionarios. • Investigación Bibliográfica.

• Fichas de Observacion. • Fichas de Encuestas. • Fichas de Cuestionarios. • Fichas Bibliográficas.




Capitulo V.

DESARROLLO DEL SISTEMA DE ADMISIÓN


DESARROLLO DEL SISTEMA DE ADMISION

5.1 VERSIONES DEL SOFTWARE

El equipo de desarrollo, en las reuniones que se tuvo, se plateó y se aprobó que la

entrega de las versiones del Sistema se haría 2 veces a la semana (días de entrega

miércoles y sábado), guardando un margen de un día por cualquier inconveniente

que surgiera.

La fecha de inicio para el desarrollo del Sistema de Admisión fue: 13/07/2005,

entregándose la primera versión el 16/07/2005.

En el proceso de desarrollo de las versiones la base de datos se modifico 2 veces.

• Versiones del 1 al 5 (del 13/07/05 al 30/07/05)

Elaboración de la Base de Datos; diseño de las pantallas para registrar la data así

como para su recuperación; colores, fondos, imágenes, logos con los que debería

contar; el tamaño y tipo de letra que debería tener.

• Versiones del 6 al 14 (01/08/05 al 31/08/05)

Proporciona solo el ingreso de la data (registro de los pueblos y asentamientos

humanos con sus respectivos sectores, así como de las familias y sus

integrantes), ofreciendo también las modificaciones (actualización) y

eliminación de la data correspondiente.


Nos brinda la posibilidad de hacer consultas así como proporciona los reportes

que se requerían para una buena toma de decisiones.




• Versión 18 (del 12/09/05 al 14/09/05)

Aquí se agregó los accesorios, así como el mejoramiento de las pantallas, para

que el usuario tenga mayor facilidad al ingresar la data así como al hacer las

consultas y brindar los reportes requeridos.


En estas últimas versiones se trato de mejorar el código.

En cada versión se aplicaron pruebas correspondientes, estas pruebas fueron hechas

con datos reales y en presencia de todos los miembros del equipo de desarrollo.

5.2 CAPACITACIÓN DE USUARIOS:

El equipo de desarrollo el cual estaba formado por:

• Desarrollador (Edgar. Alexander Cruz Huaman)

• Jefe de admisión (Cléver Pinedo Orue)

• Apoyo (Jefe del Puesto de Salud, Encargada de Tópico)

Estuvo en constante interacción con el Sistema, tal es así que en cada versión se le capacitaba.


5.3 DISEÑO DE LA BASE DE DATOS

5.3.1) Diagrama Entidad Relación (ER) actual

NO ASEGURADOASEGURADO

PACIENTE cod_paciente cod_familia nombres_paciente apellido_paterno apellido_materno sexo fecha_nacimiento tipo parentesco fecha_inscrip_paciestado

Figura N° 07 Diagrama ER Actual

FAMILIA

cod_familia cod_sector nombre_familia fecha_inscripcion jiron_calle mz lte

SECTOR

c cod_pu

od_sectoreblo

nombre_sector

PUEBLO

c nombre_p

od_sectorueblo

( 1 , n )

PERTENECE

VIVE ( 1 , n )

PERTENECE ( 1 , n )

( 1 , 1 )

( 1 , 1 )

( 1 , 1 )



5.3.2) Diagrama Entidad Relación (ER) a usar

NO ASEGURADOASEGURADO

PACIENTE cod_paciente cod_familia nombres_paciente apellido_paterno apellido_materno sexo fecha_nacimiento tipo parentesco fecha_inscrip_paciestado

FAMILIA

cod_familia cod_sector nombre_familia fecha_inscripcion jiron_calle mz lte

PUEBLO

nombre_

cod_sector pueblo

PERTENECE

VIVE

PERTENECE

( 1 , n )

( 1 , 1 )

( 1 , 1 )

( 1 , n )

( 1 , 1 )

( 1 , n )

ATENCION

cod_atencion cod_paciente fecha_atencion pa fr peso temp talla diagnostico fecha_cita observaciones

VACUNA

cod_vacuna nombre_vacuna cod_paciente

cod_vacuna fecha_vacuna num_dosis observacion num_dias_llega

RECIBE

( 1 , n ) ( 1 , n )

( 1 , n )

APLICA SECTOR

c cod_pu

od_sectoreblo

nombre_sector

Figura N° 08 Diagrama ER a Usar

( 1 , 1 )



6.3.3) Modelo Relacional Actual

Figura Nº 09 Modelo Relacional Actual



5.3.4) Modelo Relacional a Usar

Figura N° 10 Modelo Relacional a Usar




Figura N° 11 Prototipo del Sistema

5.4.1 Prototipo del Sistema

5.4 DISEÑO


5.4.2 Sistema Principal

Figura N° 12 Mensaje de Bienvenida

Figura N° 13 Autentificación de Usuario



Figura N° 14 Menú Principal

Figura N° 15 Cambio de Usuario



Figura N° 16 Datos de Usuario

Figura N° Cambio de Contraseña de Usuario

Figura N° 17 Registrar Usuario




Figura N° 19 Copias de Seguridad

Figura N° 18 Cambiar Contraseña



Figura N° 20 Manual de Usuario General


Figura N° 21 Ayuda y Soporte Técnico

Figura N° Acerca del Desarrollador

Figura N° 22 Accesorios




Figura N° 23 Acerca del Desarrollador



Figura N° 24 Ventana Familia

5.4.3 Sistema de Admisión


Figura N° 25 Registrar Familia

Figura N° 26 Modificar Datos de Familia




Figura N° 28 Buscar Integrantes de Familia

Figura N° 27 Borrar Familia



Figura N°29 Ventana Pacientes



Figura N° 30 Registrar Nuevo Paciente



Modificar Datos del Paciente

Figura N° 31 Modificar Datos del Paciente


Figura N° 32 Borrar Paciente



Figura N° 33 Historia Clínica del Paciente



Figura N° 34 Número de Personas por Pueblo agrupadas por sexo



Figura N° 35 Número de Personas por Sector agrupadas por sexo



Figura N° 36 Pacientes por Fecha de Nacimiento o Defunción



Figura N° 37 Número de Integrantes por Familia según Pueblo



Figura N° 38 Mujeres Gestantes según Fecha



Figura N° 39 Número de Familias por Pueblo y Sector



Figura N° 40 Relación de Pacientes Asegurados



Figura N° 41 Manual del Desarrollador



Figura N° 42 Manual de Usuario - Admisión




Capitulo VI.

RESULTADOS Y DISCUSIÓN


RESULTADOS Y DISCUSIÓN

6.1 DEMOSTRACIÓN DE LA HIPÓTESIS:

Para medir los indicadores de las variables dependientes obtenidos anteriormente

(Ver Capitulo IV), se utilizo un cuestionario (Ver Anexo B), aplicándolo a la

muestra de usuarios seleccionados.

El resultado de la aplicación del cuestionario se muestra a continuación.

Tabla N° 07: Resultados de la Aplicación del Cuestionario.

PREGUNTAS AREA

P1 P2 P3 P4 P5 P6 P7

PJE

ADMISIÓN 3 3 2 3 2 3 2 18

MEDICINA 3 2 2 2 1 3 2 15

ENFERMERÍA 3 3 2 2 1 1 1 13

PROMEDIO 15.3

El rango de puntuaciones se muestra a continuación

10.5 Promedio 15.3

Automatización

21

+

0

-



El promedio de las repuestas obtenidas es de 15.3 y nos indica un buen nivel de

automatización teniendo en cuenta que el sistema recién empieza a trabajar, con el pasar

del tiempo el nivel de automatización aumentará y por ende se tiene la aceptación en los

usuarios; pero el promedio por si solo no es suficiente, se debe probar que es

estadísticamente significativo. Esto se logrará a través de la prueba t de Student, tal y

como sigue a continuación:

Prueba de Hipótesis Estadística para probar la significancia del Promedio.

1) Planteamiento:

H0 : µ <= 10.5; El Sistema no automatiza los principales procesos de admisión.

Ha : µ > 10.5; El Sistema si automatiza los principales procesos de admisión.

2) Nivel de Confianza (95%)

α = 5% (margen de error)

3) Regiones de aceptación y de rechazo

Si t0 <= t(0.95,3) entonces H0 se acepta. Para esto t0 <= 2.353. En caso contrario

H0 se rechaza y se acepta Ha es decir t0 > 2.353.

4) Cálculos:

N = 3; X = 15.3; µ = 10.5



Calculamos la desviación típica. S = 2.51

Entonces t0 = 3.3265

5) Conclusión:

Como t0 > 2.353 H0 se rechaza y se acepta Ha; por lo tanto el sistema si logra

mejorar el control de historias clínicas, ayudando a la toma de decisiones y con

el transcurrir del tiempo mejorará sus ingresos económicos. Esta afirmación

tiene un margen de error del 5%.

La prueba de hipotesis, usando la distribución t de Stundent, ha demostrado que

el promedio de puntuación encontrado es estadisticamente significativo, con lo

cual se ha demostrado que la hipotesis de investigación es válida.

6.2 DISCUSIÓN:

El problema que el presente trabajo de investigación pretende solucionar es el

siguiente: “¿En que medida a través de la Implementación de un Sistema de

Información se mejorará el control de historias clínicas, optimizará sus ingresos

económicos y ayudará a la toma de decisiones del Puesto de Salud San Pedro?”,

para dar solución al problema se planteó la siguiente hipótesis:

El Desarrollo de un Sistema de Información mejorará el control de historias

clínicas, optimizará sus ingresos económicos y ayudará a la toma de decisiones

del Puesto de Salud San Pedro.



Para poder demostrar la hipótesis se caracterizó a las variables dependientes de

acuerdo a lo siguiente:

Y = Control de Historias Clínicas.

Indicadores:

y1 = Reducción de los tiempos muertos en la búsqueda de historias

clínicas.

y2 = Evitar la duplicación del número de Historias Clínicas.

y3 = Reducción del espacio utilizado para almacenar historias clínicas

impresas. [1]

W = Optimización de Ingresos Económicos.

Indicadores:

w1 = Más atenciones.

w2 = Reducción de gastos en la compra de papel para la impresión. [1]

Z = Ayuda a la Toma de Decisiones.

z1 = Confiabilidad en las decisiones a tomar.

Luego de aplicar el cuestionario (Ver Anexo B) para determinar el nivel de

aceptación de los indicadores se obtuvo el siguiente resultado tal como los muestra

el gráfico siguiente:



Numero de Respuestas por Alternativa

0

0.5

1

1.5

2

2.5

3

3.5

1 2 3 4 5 6 7

Preguntas

N°

de U

suar

ios

Alt1(0) Alt2(1) Alt3(2) Alt4(3)

Figura N° 43 Total de respuestas por alternativa

En todas las preguntas se obtuvo respuestas de aceptación significante es decir las

respuestas están distribuidas entre las Alternativas “4”, “3” y “2”, no tenemos

ninguna respuesta negativa y sabiendo que estas restas respuestas mejorarán con el

transcurrir del tiempo, pues aún se esta registrando a los pacientes.

Para lograr un nivel de aceptación en los resultados generales de la encuesta la

puntuación general oscila entre un mínimo de 0 y un máximo de 21, obteniendo los

siguientes intervalos.

[0 - 7] : No hay aceptación

[8 - 14] : Aceptación Regular

[15 - 21] : Alta Aceptación.



El resultado es 15.3, el cual se encuentra en un rango de valores de alta aceptación,

sin embargo la medida de estos rangos es 10.5 (se obtiene de (30+0)/2).

De la aplicación del cuestionario podemos afirmar lo siguiente:

Pregunta 1:

El Sistema demuestra que en cuanto a la velocidad de búsqueda de historias clínicas

de pacientes ha mejorado notablemente en cuanto a la forma manual que se estaba

realizando (La reducción ha ido de los (5 – 30 min.) a los (5 – 15 seg.)).

Pregunta 2:

Se puede observar que la disponibilidad de las historias clínicas es a tiempo,

disminuyendo así el tiempo muerto que se tenía anteriormente, la disponibilidad

será en su totalidad al instante cuando el sistema empiece a trabajar en red

(Cliente/Servidor).

Pregunta 3:

En cuanto a la velocidad de obtener información acerca de un paciente es rápida,

pues el sistema brinda la posibilidad de obtener la información desde cualquier parte

donde se encuentre en el mismo sistema, pues el manejo del mismo tiene muchas

opciones con tan solo pocas ventanas.

Pregunta 4:

Se observa que la duplicación de historias clínicas se ha eliminado, pues es este

punto uno de los más importantes o más solicitados por el establecimiento de salud

ya que el central de quienes dependen se les solicitó que eliminaran las historias

clínicas duplicadas.



Pregunta 5:

En cuanto al número de atenciones por el momento se ha mantenido y esto es

debido a que el sistema aún no esta trabajando al 100% porque aun se esta pasando

la información de los archivos al sistema, con el transcurrir de los días el número de

atenciones se pronostica que aumentará.

Pregunta 6:

Uno de los puntos fuertes que tiene el sistema son sus reportes y consultas pues

podemos ver de la encuesta que la seguridad en cuanto a la toma de decisiones ha

mejorado notablemente pues se cuenta con el respaldo estadístico que brinda el

sistema.

Pregunta 7:

En cuanto a la satisfacción del paciente recién empieza a aumentar pues con las

3000 historias clínicas que se han registrado hasta la fecha les a permito que su

atención de alguna manera sea más rápida.

Con estos resultados obtenidos de la aplicación del cuestionario (anexo B), se puede

observar que los indicadores son favorables en cuanto al proceso que se realiza en

admisión en la actualidad.

• Reducción de los tiempos muertos en la búsqueda de historias clínica.

Esto es debido a la velocidad que brinda una computadora

• Eliminación de la duplicación del número de historias clínicas.

Esto es debido a que el Sistema es quien asigna y controla este número no

dejando oportunidad a la duplicación.



• Más atenciones.

Este poco a poco se esta dando hasta que se tengan a todos los pacientes

registrados.

• Confiabilidad en las decisiones a tomar.

Pues cuenta con el respaldo estadístico que brinda el sistema pudiendo hacer

las consultas que se necesiten de una manera sencilla y rápida.

Con estos resultados obtenidos y con la demostración de la veracidad de la

hipótesis realizada mediante una prueba de t de Student, podemos afirmar que

nuestra hipótesis de investigación es valida.




CONCLUSIONES Y RECOMENDACIONES


CONCLUSIONES

1. Se logró definir la situación problemática de los procesos involucrados en el

área de admisión y por ende en las áreas de atención medica.

2. Se logró identificar los principales procesos que se realizan en el área de

admisión.

3. Se auditó al equipo con que contaba y bajo este se selecciono la plataforma así

como el lenguaje de programación sobre el cual se trabajaría y el sistema gestor

de base de datos que utilizaría.

4. Se aplicó la Metodología XP para el desarrollo del proyecto, la cual facilito el

trabajo pudiéndose concluir en el tiempo previsto.

5. Se pudo desarrollar el Sistema de Admisión de manera satisfactoria.

6. Se realizó las pruebas al Sistema, aplicándose los cuestionarios que se indica en

el anexo B y C obteniéndose resultados satisfactorios.

7. Se demostró a través de la prueba estadística que el Sistema cumple su objetivo

de controlar las historias clínicas, apoyar a la toma de decisiones y en su futuro

al incremento de ingresos económicos del Puesto de Salud San Pedro.

8. Se capacitó a personal que utilizaría el sistema, quedando este conforme con las

facilidades que brindaba el sistema.



RECOMENDACIONES

1. Se recomienda adquirir más equipo hardware para que la automatización sea la

más eficiente, pudiendo así ahorrar en archivadores, papel, etc. Y haciendo más

óptimo el flujo de información. Pues esta PCs trabajarían en Red.

2. Como se esta trabajando bajo la metodología XP, el Sistema puede crecer y se

recomienda una capacitación constante a los usuarios para evitar los posibles

errores.

3. La instalación de un equipo UPS en caso de cortes de energía, ya que el Sistema

depende de esto.

4. Se recomienda leer los manuales ante cualquier duda que se presente.



BIBLIOGRAFÍA

Libros:

• Roger S. Presuman, “Ingeniería del Software – Un enfoque practico”, Quinta

Edición - Madrid 2001. Editorial Mc. Graw Hill.

• Silberschatz – Korth – Sudarshan, “Fundamentos de Bases de Datos”, Cuarta

Edición.

• Juan José Castañeda León, “Power Builder 9.0 Fulla DataBase”, Editorial

Megabyte.

• Luís Eduardo Ramírez, “Desarrollando con Power Builder 8.0”, Editorial

Macro

Publicaciones Electrónicas

Gestores de Bases de Datos, más conocidas:

• http://www.pcm.gob.pe/portal_pngei/publicaciones/tecnicas/lib5017/msoft09.htm

El Analista de Sistemas: Grupo de Estudios AS –

• http://members.xoom.com/analista/portada.htm

Power Designer

• http://www.sybase.com/products/powerdesigner

• http://translate.google.com/translate?hl=es&sl=en&u=http://www.sybase.com/pro

ducts/developmentintegration/powerbuilder&prev=/search%3Fq%3Dpower%2Bb

uilder%26hl%3Des%26lr%3D



• http://powerbuilder.codeXchange.sybase.com.

SYBASE

• www.sybase.com.

• http://sybooks.sybase.com/pb.html.

Metodología XP

• http://www.programacionextrema.org/cgi-bin/wiki.pl?ProgramacionExtrema

Algunas referencias importantes en inglés:

• WardCunningham http://c2.com/cgi/wiki?ExtremeProgramming.

• http://www.extremeprogramming.org/

• http://www.xprogramming.com/

• http://xp123.com/

• http://www.industriallogic.com/xp/index.html

• http://groups.yahoo.com/group/extremeprogramming

• http://www.jera.com/techinfo/xpfaq.html

• http://www.objectmentor.com/home

• http://ootips.org/xp.html

Sitios en Europa

• http://www.xp.be/

• http://www.ot2003.org/

• http://www.agilemovement.it/



Sitios en Ibero América

• http://www.programacionextrema.org/

• http://www.xispe.com.br/

• http://www.agile-spain.com/

• http://www.programacion.com/

• http://www.agile-paraguay.org/

Eventos internacionales importantes:

• http://www.xp2006.org/

• http://www.xpuniverse.com/home

• http://www.xispe.com.br/evento2004/index.html

• http://www.angelfire.com/dc/marcodorantes

Otras direcciones:

• http://www.extremeprogramming.org/

• http://www.xprogramming.com/xpmag/whatisxp.htm

• http://www.xprogramming.com/what_is_xp.htm

• http://oness.sourceforge.net/docbook/resources.html#AgileManifesto

• http://www.informatizate.net/articulos/metodologias_de_desarrollo_de_software_

07062004.html

• http://es.tldp.org/Presentaciones/200211hispalinux/ferrer/robles-ferrer-ponencia-

hispalinux-2002.pdf

• http://www.programacion.com/blogs/84_metricas_web/archive/526_fundamentos

_de_extreme_programming_parte_ii.html

• http://punto-informatico.it/servizi/ps.asp?i=31526&r=PI




ANEXOS


ANEXO A

CARACTERISTICAS DEL HARDWARE Y SOFWARE

Para realizar la auditoria de la PC se utilizo el Software Berlarc Advisor 5.0. A) Hardware

System Model

VIA Technologies, Inc. VT82C694X

Processor a

Main Circuit Board

1000 megahertz Intel Pentium III 32 kilobyte primary memory cache 256 kilobyte secondary memory cache

Board: 694X-686A Bus Clock: 133 megahertz BIOS: Award Software International, Inc. 6.00 PG 02/12/2001

Drives

Memory Modules

128 Megabytes Installed Memory 128 Megabyte Module Size - 1 Installed 3 Memory Sockets are Empty

Local Drive Volumen

c: (on drive 0) 20.01 GB 8.52 GB free d: (on drive 0) 20.00 GB 16.41 GB free

Network Drives

40.01 Gigabytes Usable Hard Drive Capacity 24.93 Gigabytes Hard Drive Free Space CREATIVE CD5233E-N [CD-ROM drive] 3.5" format removeable media [Floppy drive] MAXTOR 4K040H2 (40.04 GB) [Hard drive] -- drive 0

Controllers

Printers

N one detected Display

Canal IDE principal [Controller] Canal IDE secundario [Controller] Controladora IDE principal de bus VIA [Controller] SiS 5598/6326 [Display adapter]

SiS 5598/6326 [Display adapter] Bus Adapters Multimedia

None detected Audio WDM Crystal SoundFusion(TM) CS4281

Communications

Other Devices

Minipuerto WAN (IP) Minipuerto WAN (IP) - Minipuerto del administrador de paquetes Minipuerto WAN (L2TP) Minipuerto WAN (PPPOE) Minipuerto WAN (PPTP)

Concentrador raíz USB Concentrador raíz USB Controlador de host universal USB VIA Rev 5 o posterior Controlador de host universal USB VIA Rev 5 o posterior



B) Software

Operating System

Windows XP Professional, Service Pack 2

Software Licenses

Microsoft - Internet Explorer 55274-649-9930016-23675 Microsoft - Office Professional Edition 2003 73961-640-0000106-57286 Microsoft - Windows XP Professional 55274-649-9930016-23675

Software Versions

A0000330 * Adobe Acrobat Reader Version 5.0.0.0* Ahead Software AG Karlsbad Germany Phone: ++49-7248-911-800 Fax: ++49-7248-911-888 e-mail: [email protected] - LANGUAGE_English2 Version 5, 5, 9, 9* Ahead Software AG - InfoTool Application Version 1, 2, 0, 0* ahead software gmbh, karlsbad - Cover Designer Version 2, 2, 1, 6* Belarc Advisor and BelLive - Belarc's Content Personalization with Privacy Version 5.0m* Cinematronics - 3D Pinball Version 5.1.2600.2180* Desinstalar PER Antivirus Version 9.3.01* Erik Deppe - DriveSpeed Application Version 1, 5, 0, 0* Erik Deppe - Nero CD Speed Application Version 1, 0, 0, 0* iAnywhere Solutions, Inc. - Adaptive Server Anywhere Version 9.0.1.1873* Instituto Nacional de Salud - Sistema Informatico del Estado Nutricional Version 1.00* Microsoft - PDMan98 Version 6.00.8169* Microsoft Clip Organizer Version 11.0.5510* Microsoft Corporation - Dependency Walker Version 1.0* Microsoft Corporation - Messenger Version 4.7.3000* Microsoft Corporation - Office Source Engine Version 11.0.5525* Microsoft Corporation - OLEViewer Version 2.1* Microsoft Corporation - VB 6 API Declaration Loader Version 6.00.8169* Microsoft Corporation - Windows Movie Maker Version 2.1.4026.0* Microsoft Corporation - Windows® NetMeeting® Version 3.01* Microsoft Corporation - Zone.com Version 1.2.626.1* Microsoft Object Linking and Embedding Client Test for Windows Version 1.01.000* Microsoft Object Linking and Embedding Server Test for Windows Version 1.01.000* Microsoft Office 2003 Version 11.0.5510* Microsoft Office 2003 Version 11.0.5529* Microsoft Office 2003 Version 11.0.5604* Microsoft Office 2003 Version 11.0.5612* Microsoft Office 2003 Version 11.0.5614* Microsoft Office Document Imaging Version 11.0.1897.0* Microsoft Office InfoPath Version 11.0.5510* Microsoft® Developer Studio Version 6.0.000* Ministerio de Salud - Aplicativo Funciones Obstétricas y Neonatales Version 1.01* Módulo de usuarios Version 2000.0.0* Módulo exportación Version 2000.0.0* Módulo Integridad Version 2.0.0* Módulo Utilitarios Version 2000.0.0* Nullsoft - Winamp Version 2.77* PER Antivirus Version 9, 4, 0, 0* Reproductor de Windows Media de Microsoft(R) Version 9.00.00.3250* Servicios Internet de Microsoft® Version 6.1.33.0* SIP2000 (intranets) Version 2000.0.1405* Sistema operativo Microsoft(R) Windows (R) 2000 Version 5.50.4134.600*



Sistema operativo Microsoft® Windows® Version 5.1.2600.2180* Sistema operativo Microsoft® Windows® Version 6.00.2900.2180* Sybase - StandAlone Translation Toolkit Version 10,0,0,4510* Sybase - Translation Toolkit Version 10,0,0,4510* Sybase Central Version 4.3.0.2244* Sybase Inc. - InfoMaker * Sybase Inc. - PowerBuilder * Sybase Inc. - PowerBuilder/InfoMaker * Sybase, Inc. - PowerBuilder Enterprise Series Version 1,0,0,1* WinampAgent * WinRAR



ANEXO B

DISEÑO DEL CUESTIONARIO PARA MEDIR LA

AUTOMATIZACIÓN

1. La velocidad en la Búsqueda de Historias Clínicas se ha:

0) Reducido 1) Mantenido

2) Aumentado 3) Mejorado Notablemente

2. La disponibilidad de las Historia Clínicas es:

0) Muy Lenta 1) Con retrazo

2) A Tiempo 3) Al Instante.

3. La Velocidad de obtener información acerca de una persona es:

0) Muy Lenta 1) Lenta

2) Rápida 3) Muy Rápida

4. La duplicación de Historias Clínicas ha:

0) Aumentado 1) Mantenido

2) Reducido 3) Eliminado

5. El numero de atenciones ha:





6. La seguridad en cuanto a la toma de decisiones se ha:



7. La satisfacción del paciente al ser atendido mas rápido ha:


2) Aumentado 3) Aumentado Notablemente



ANEXO C

DISEÑO DEL CUESTIONARIO PARA PRUEBAS DEL

SOFTWARE

1. El manejo de las opciones del sistema es:

0) Muy Difícil 1) Difícil

2) Entendible 3) Muy Fácil

2. El manejo de la ventana de registro, búsqueda, modificacion y eliminacion es:



3. La información mostrada en la ventana registro es:

0) Faltan Datos 1) A medias

2) Necesaria 3) Completa

4. La búsqueda de los pacientes y sus datos es:

0) Muy lenta 1) Lenta

2) Rápida 3) Muy Rápida

5. La modificacion de los datos de los pacientes causa:

0) Muchos Problemas 1) Pocos Problemas

3) No Causa Problemas

6. El ingreso de usuarios al Sistema es:



0) Pésimo 1) Regular

2) Bueno 3) Excelente

7. Los accesorios que brinda el sistema tienen una utilidad de:

0) 0 – 5 1) 6 - 10

2) 11 - 15 3) 16 – 20

8. Las consultas son:



9. Los Reportes que brinda el sistema son:

0) Insuficientes 1) No se Entienden

1) Necesarios 3) Completos

10. Que calificación merece el sistema según su desempeño:

0) 0 – 5 1) 6 - 10

2) 11 - 15 3) 16 – 20



ANEXO D

ESTUDIO DE FACTIBILIDAD

A) Factibilidad Operativa:

Es evaluada tomando los siguientes criterios:

Existe el respaldo necesario por parte del personal que labora en el Puesto de

Salud, para que este proyecto se lleve a cabo; y durante el desarrollo de cada una

de las etapas, se me brindo la información requerida, así mismo su confianza y

apoyo de forma incondicional que fueron sustanciales al momento de la

realización de este proyecto.

El Sistema de Información que se propone, ayudará a tener un mejor control de

la información requerida por parte de los trabajadores del puesto de salud,

controlará el número de historia clínica y número de familia evitando que se

repitan, agilizará el proceso de búsqueda de historias clínicas y por ende podrá

optimizar los ingresos económicos al poder a tender a más pacientes, apoyará a

la toma de decisiones por parte de la dirección del puesto de salud y además de

satisfacción tanto del personal que labora y los pacientes al ser atendidos de una

manera más rápida.

En cuanto a la disponibilidad de tiempo para realizar las actividades del proyecto

que se dan a diario se cuenta con lo suficiente, facilitando así la labor que se esta

realizando.

También es factible la capacitación del personal, pues forma parte del equipo de

desarrollo y esta constantemente interactuando con cada una de las versiones

instaladas.



Concluyendo de esta manera que el proyecto es factible operacionalmente.

B) Factibilidad Técnica

Para la elaboración de este proyecto, se requiere de medios técnicos: por lo cual

se utilizó los siguientes equipos de hardware y herramientas de software.

Hardware Requerido Descripción Mínima 1 Computadora Como mínimo debe de contar con las

siguientes características: • Procesador Pentium III 600 Hhz. • Memoria 128 MB. • Disco Duro 20 GB.

1 Impresora Matricial o inyección (opcional) Observación:

- Se cuenta con una computadora, con características mayores a las indicadas en la celda anterior.

- Con una impresora Matricial platillera. Software

Requerido Versión del

Software Descripción

Microsoft Windows

XP, 2000 o 2003

Es un software que se ejecuta en un equipo y controla los programas y hardware de la PC. Herramienta necesaria para la ejecución de los demás sw. Disponible por el Desarrollador.

Power Builder 9.0 o 10.0 Lenguaje de programación visual y orientado a objetos, necesario para construir el sistema propuesto y que estuvo disponible por el Desarrollador.

SQL Anywhere 8.0 o 9.0 Gestor de Base de Datos, herramienta necesaria para construir para construir la base de datos disponible por parte del Desarrollador.

Observación: Con la utilización de estos software y con las técnicas y herramientas de ingeniería del software se ha desarrollado el Sistema propuesto.

Debido a que el Puesto de Salud cuenta con el equipo hardware que sobre pasa a

los requerimientos mínimos para soportar la aplicación. Por tanto luego de

realizar este análisis, se concluye que el proyecto es factible técnicamente.



C) Factibilidad Económica

Comprende los costos asociados al Sistema de Información para la atención de

pacientes del Puesto de Salud San Pedro – Chimbote y los beneficios tangibles e

intangibles que se obtendrán.

C.1 Costos:

C.1.1 Costos del Software

Estos son los costos asociados al desarrollo del software y se clasifican

en:

1. Hardware

2. Software

3. Recursos Humanos

4. Servicios

5. Materiales

1. Hardware

Para llevar a cabo el desarrollo del sistema se requiere el uso de

una computadora.

Cálculo Total de Horas Uso de la PC.

Costos de Hardware: 61 (días) * 8 (horas) * 1 (persona) = 488

Tabla Nº 03 COSTOS DE HARDWARE Costo de Energía Eléctrica S/. 181.58

488 horas * 0.3721 Costo Total Hardware S/. 181.58



2. Software

Así mismo, para llevar a cabo el desarrollo del proyecto, se

requiere las siguientes herramientas de software:

Tabla Nº 03 COSTO DE SOFTWARE Microsoft Windows XP $ 560.00 S/. 1803.20Power Builder y SQL Anywhere (Paquete)

$ 5000.00 S/. 16100.00

Microsoft Office XP $309.63 S/. 995.95SUB - TOTAL $1219.63 S/. 18899.15

3. Recursos Humanos

Tabla Nº 04 COSTOS DE RECURSOS HUMANOS Un Desarrollador de Software por las 12 horas de trabajo al día.

S/. 2400.00

1200 * 2 mesesSUB - TOTAL S/. 2400.00

Cabe recalcar que el sueldo promedio de un desarrollador de

software en Chimbote es de S/. 800 nuevos soles al mes por 8

horas de trabajo diarias de trabajo.

Se tomo como tipo de cambio del dólar el valor de S/.3.22

4. Servicios

Tabla Nº 05 COSTOS DE SERVICIOS Movilidad S/. 0.00Internet S/. 10.00Fotocopias S/. 1.00Mantenimiento de la PC S/. 50.00

SUB - TOTAL S/. 61.00



5. Materiales

Tabla Nº 06 COSTOS DE MATERIALES 1 Millar de papel Boon (*) S/. 0.002 Lapiceros (*) S/. 0.001 Caja de Disquetes 2hb IBM (*) S/. 0.001 CD-RW 80 min/700mb – 4x S/. 5.001 Cinta para impresora S/. 15.00

SUB - TOTAL S/. 20.00

(*) Tienen valor cero, debido a que el establecimiento de salud

contaba con estos materiales y los proporciono gratuitamente.

Tabla Nº 07 CONSOLIDADO DE COSTOS Costos de Hardware S/. 181.58Costos de Software S/. 18899.15Costos de Recursos Humanos S/. 2400.00Costos de Servicios S/. 61.00Costos de Materiales S/. 20.00

SUB - TOTAL S/. 21561.73

C.2 Beneficios del Sistema Propuesto:

Los beneficios obtenidos con el Sistema de Información, responden sobre todo a

la necesidad que tiene el Puesto de Salud San Pedro de controlar el numero de

historias clínicas, reducción en el tiempo de búsqueda de historias, apoyo a la

toma de decisiones, atención a más pacientes lo cual conllevaría a optimizar su

fuente de ingreso.

C.2.1 Beneficios Tangibles

La siguiente lista es un resumen de los beneficios tangibles que se

obtendrán con la realización del proyecto.



- Tiempo

El tiempo que dedican los trabajadores de admisión y del puesto de

salud en general a buscar las historias clínicas de los pacientes, se vera

reducido al mínimo ya que la computadora lo buscara por el

Ahorro de tiempo para la toma de decisiones pues podrán hacerlo de

una manera más rápida y segura.

- Eficiencia

Los datos de los pacientes serán actualizables y modificables.

C.2.2 Beneficios Intangibles

- Mejora la atención de los usuarios.

- Ayuda a cumplir con los objetivos y metas propuestas con eficiencia y

efectividad.

- Permite tener un oportuno acceso a la información.

- Aumenta la Imagen Institucional del Puesto de Salud San Pedro –

Chimbote.

C.3 Recuperación del Costo:

C.3.1 Manifestación de la Dirección del Puesto de Salud

El señor Cléver Pinedo Orue, manifiesta que:

• El Puesto de Salud deja de atender a un promedio de 5 pacientes al día,

debido a las causas que se mencionaron anteriormente.

• La consulta normal cuesta S/. 2.50.

• Se estima que por los pacientes que no se atienden, se pierde dinero

adicional a la consulta, pues estos pacientes también requieren otros



servicios como: medicina, laboratorio, etc. Este monto haciende a un

promedio de S/. 500.00 al año.

De lo anterior se concluye:

• Pérdida en Consulta al año: S/. 2.50 * 5 pacientes * 300 días.

Pérdida en Consulta al año = S/. 3 750.00

• Pérdida en otros servicios al año: S/. 500.00

• Pérdida Total al Año: S/. 4 250.00

Por lo tanto, si el Puesto de Salud compra las licencias de software y los

gastos que conllevo realizar el Sistema de Admisión, recuperaría sus gastos

en el periodo de:

.0733.500.2504./73.56121./ años

SS

PérdidadeCostolicenciasdeCostosAñosdeNúmero ===

La dirección del Puesto de Salud ha manifestado que es imposible que se

compre las licencias de software, así que optará por no comprarlas, pero si

puede cubrir los demás gastos. Entonces la nueva recuperación de sus

gastos sería en el periodo de:

.6264.000.2504./58.6622./ años

SS

PérdidadeCostolicenciasSinCostosAñosdeNúmero ===

Lo que implica que el Puesto de Salud recuperaría los gastos en menos de 8

meses.

Conclusión:

Por tanto luego de realizar este análisis, se concluye que el proyecto es

factible económicamente.


Mi Proyecto de Bachiller - Edgar Cruz - Informe Completo

Documents