UNIVERSIDAD CATÓLICA

LOS ANGELES DE CHIMBOTE

FACULTAD DE INGENIERÍAS

ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS

PRÁCTICAS PROFESIONALES I

TRABAJO FINAL

DOCENTE: Ing. Arnaldo Gonzales

ALUMNO: Fausto Danilo Esthela Espinoza

SEDE: AREQUIPA

PERÚ 2011
 Introducción
El presente proyecto teórico práctico de prácticas pres profesionales esta denominado
“SISTEMA INFORMÁTICO PARA LA ADMINISTRACIÓN Y CONTROL DE ANÁLISIS CLÍNICO PARA
PACIENTES” para la empresa Laboratorio Clínico Exacta Lab.

Este trabajo nace por la importancia de realizar un adecuado registro, seguimiento y ubicación
de los análisis clínicos de los pacientes que utilizan los servicios de Exacta Lab, ya que permitirá
un registro, ubicación inmediata, oportuna y confiable; logrando que los trabajadores de Exacta
Lab puedan mejor el servicio al público en este caso los pacientes y mejorar su imagen
empresarial.

En el área de recepción es donde el paciente es atendido, la empresa cuenta con un sistema de

escritorio desarrollado en Visual Fox Pro, la recepcionista ingresa los datos del paciente así como
los resultados de sus análisis para luego imprimirlos y estos darle al paciente. Este último muchas
veces quiere que lo resultados se les envíe a su email, la recepcionista escanea la hoja de
resultados para luego enviárselo vía email. Otro problema es que la empresa se expandió y
cuenta con 2 sucursales más y en cada una cuenta pacientes que se repiten entre las sucursales
y la oficina principal, para esto las recepcionistas en cada oficina vuelven a registrar al mismo
paciente para tener sus datos de los análisis clínicos, es así que la base de datos es diferente en
cada sucursal y en la oficina central, la empresa no tiene datos fiables y limpios en su base de
datos.

Es este malestar, y la necesidad expuesta anteriormente, los motivos por los que se ha creído
conveniente preparar y presentar el presente proyecto, con la finalidad de mejorar la
administración y control de análisis clínicos para los pacientes de Exacta Lab.

Con el presente trabajo, se pretende contribuir a solucionar los problemas de registro,

ubicación, impresión de los resultados de los análisis clínicos de pacientes de la empresa.

El Sistema de Administración y Control de Análisis Clínicos para Pacientes, será realizado en vía
web con software libre, lo que mejorara el proceso actual que se viene realizando, ya con la
conexión a Internet, la empresa tendrá acceso a su sistema desde cualquier computador
conectado a Internet para administrar y controlar los análisis clínicos, para esto se utilizará una
sola base de datos, realizarán el registro, búsqueda e impresión de los resultados, así como
enviar un email al paciente con los resultados de su análisis sin tener que escanear ningún
documento.
El Sistema Informático, está orientado a implementarse en la oficina central y las sucursales de
la empresa Exacta Lab. Las ventajas más resaltantes, que se obtendrán con la implementación
de este sistema, podemos mencionar:
 Registro de forma inmediata de los datos del paciente, así como su ubicación confiable y
oportuna de cualquier análisis realizado.
 Control de los resultados de los análisis.
 Historial de análisis realizados.
 Seguridad en el ingreso al sistema.
 Mejorar la atención y la imagen empresarial.

Es importante tener en cuenta, que en el presente proyecto se consideran procesos de registro,

búsqueda y consultas novedosas e innovadoras así como la presentación del sistema.

El proyecto Sistema Informático para la Administración y Control de Análisis Clínicos para

Pacientes, se ha diseñado para que trabaje con Software Libre en su totalidad tomando forma
de páginas Web 2.0, de los cuales se eliminará totalmente el costo de licenciamiento.

Este proyecto teórico práctico, pretende ser un aporte informático y está orientado al
aprovechamiento inmediato de las herramientas de software con las cuales actualmente
contamos y, en acorde con los planeamientos estratégicos de la Universidad Los Ángeles de
Chimbote brindará una sólida base en la toma de decisiones.
 RESUMEN

El presente proyecto teórico práctico de prácticas pres profesionales esta denominado

“SISTEMA INFORMÁTICO PARA LA ADMINISTRACIÓN Y CONTROL DE ANÁLISIS CLÍNICO PARA
PACIENTES” utilizando software libre en su totalidad, se realiza como resultado de un análisis
de la situación actual de la empresa en mención; tal es así que se ha permitido conocer que
cuentan con un sistema de escritorio, para lo cual la empresa necesita un sistema informático
que este implementado en Internet, ya que cuentan con 2 sucursales y desea manejar la
información entre la oficina central y sus sucursales.

Por tal motivo se ha desarrollo el presente estudio que implica las etapas de Análisis, Diseño y
la presentación de algunos prototipos a fin de sustentar y demostrar técnicamente la viabilidad
de la implantación de un Sistema Informático para la Administración y Control de Análisis
Clínicos para la empresa Exacta Lab.

El presente estudio se documenta en cinco capítulos, los mismos que brevemente se describen
a continuación:

En el capítulo I, denominado: Aspectos Generales, se define la Institución a evaluar, teniendo en

cuenta la información detalla de su Ubicación Geográfica, Base Legal de su creación, Áreas que
comprende, Funciones de principales áreas; así mismo su Historia y Evolución para concluir con
los servicios que presta. Esta información permitirá analizar y conocer los órganos y personas
involucradas en el proceso de recepción de datos y resultados de los análisis clínicos de los
pacientes, con lo cual posteriormente permitirá identificar los requerimientos del sistema.

En el capítulo II, denominado: Análisis del Sistema Actual, se especifica la fase de Recopilación
de la Información, la formulación del problema, descripción de los procesos o actividades que
se realizan en el sistema actual y finalmente se concluye identificando los requerimientos.

En el capítulo III, denominado: Análisis y Diseño del Sistema Propuesto, se explica primeramente
las metodologías más usadas en la actualidad, comparación entre el análisis y diseño orientado
a objetos y análisis y diseño estructurado. Asimismo se realiza la fundamentación de la selección
de la metodología UML y se indica software libre que se utilizará para el modelamiento.

En este capítulo de igual forma se realiza la explicación de la etapa de análisis, definiendo los
requisitos, detallando los casos esenciales de uso, diagramas de caso de uso, modelo conceptual,
diagramas de secuencia y diagramas de actividades. En la etapa de diseño se explica el tema de
los casos reales de uso, diagramas de clase; la implementación de las bases de datos y las
interfaces.

En el capítulo IV, denominado: Prototipos del sistema, se trata de fundamentar el uso de los
prototipos de sistemas antes de la implantación, se presentan prototipos de algunos procesos
del sistema propuesto y se concluye explicando la seguridad del sistema.

En el capítulo V, denominado: Evaluación Económica del Proyecto, se realizan el desarrollo de

los Estudios de Viabilidad y Costes – Beneficios, a fin de determinar la o no viabilidad de la
implantación del Sistema Informático para la Administración y Control de Análisis Clínicos para
Pacientes.

Finalmente, se detalla un glosario de términos a fin de que se pueda entender algunos términos
usados en el presente estudio.
Objetivo General
 Determinar e implementar un Sistema Informático para la Administración y Control de
Análisis Clínicos para Pacientes del laboratorio clínico Exacta Lab, utilizando software
libre como herramientas tanto para el análisis, diseño y algunos prototipos de interfaz.
Objetivos Específicos
 Realizar un trabajo de recopilación necesaria, mediante el método de entrevista a los
trabajadores de recepción quienes son los que ingresan los resultados.
 Normar adecuadamente el registro sistematizado de la información al momento de
ingresar los datos, resultados de los pacientes.
 Modelar el sistema con la metodología UML.
 Diseñar y construir una base de datos íntegra y confiable mediante un sistema de
administración de base de datos utilizando MYSQL.
 Plantear un modelo del sistema informático utilizando el lenguaje de programación de
PHP.
 Evaluar y especificar los requerimientos de hardware y software necesarios para la
instalación e implementación del Sistema.
 Determinar la factibilidad económica del proyecto, mediante un análisis de Costo y
Beneficios.
Objetivos del Sistema
 Automatizar el proceso de registro, búsqueda e impresión de los datos y resultados de
los análisis clínicos para pacientes.
 Implementar un sistema utilizando software libre en su totalidad en el desarrollo del
sistema.
 Diseñar interfaces sencillas, amigables en armonía de color, que no cansen la vista, que
sean totalmente fácil de entender y manipular por cualquier trabajador.
 Brindar seguridad y privacidad en todos sus niveles, tanto en los datos que se registran
como en el acceso.
 Mostrar mediante reportes en pantalla distintas formas de información que se
encuentren en la base de datos, estos reportes por pantalla pueden ser grabados en
archivos digitales para enviarlos por email o imprimirlos.
 CAPITULO I

MARCO TEORICO CONCEPTUAL

1.1 Datos Generales de La Empresa
1.1.1 Ubicación Geográfica

El Laboratorio Clínico Exacta Lab, se encuentra ubicado en el Distrito de Yanahuara,

Provincia de Arequipa, Departamento de Arequipa cuya dirección es la calle Juana
Espinoza 121 Umacollo, teléfono: 250222.

También cuenta con sucursales de toma de muestra en el Distrito del Cercado y José
Luis Bustamante y Rivero en la ciudad de Arequipa.

1.1.2 Base Legal

La Ley 28015 – Ley de promoción y formalización de la micro y pequeña empresa,

en su artículo 2º define a la micro y pequeña empresa como “la unidad económica
constituida por una persona natural o jurídica, bajo cualquier forma de
organización o gestión empresarial contemplada en la legislación vigente, que tiene
como objeto desarrollar actividades de extracción, transformación, producción,
comercialización de bienes o prestación de servicios”

Existen dos modalidades de MYPES: la microempresa y la pequeña empresa, las

cuales son diferenciadas por diferentes entidades en función al número de
trabajadores, monto de ventas anuales, monto en activos fijos. Según Yacsahuache,
las definiciones más acertadas son las siguientes:

La comisión de promoción de la pequeña y microempresa PromPyme del Ministerio

de Trabajo y Promoción del Empleo hace la diferenciación entre micro y pequeña
empresa según el número de trabajadores y en monto de activos fijos – expresado
en unidades impositivas tributarias (UIT). La microempresa es aquella que tiene
entre 1 a 10 trabajadores y un monto de activos fijos de hasta 150 UIT. La pequeña
empresa es aquella que tiene de 1 a 50 trabajadores y un monto de activos entre
150 y 850 UIT.

El Ministerio de Industria, Turismo, Integración y Negociaciones Comerciales

internacionales (MITINCI) diferencia ambas modalidades por el número de
trabajadores y las ventas anuales. La microempresa es aquella que tiene no más de
10 trabajadores y realiza ventas anuales inferiores a las 12 UIT. La pequeña empresa
tiene no más de 20 trabajadores y realiza ventas anuales entre 12 a 25 UIT.
 Por su parte la Superintendencia de Banca y Seguros (SBS) y la Corporación
Financiera de Desarrollo S.A. (COFIDE), hacen una diferenciación entre micro y
pequeña empresa de acuerdo a los montos de sus activos fijos y las ventas anuales
(expresados ambos en dólares americanos). La microempresa es aquella que tiene
activos fijos hasta por US$ 20000 y ventas anuales menores a US$ 40000. La
pequeña empresa tiene activos fijos entre US$ 20000 a US$ 300000 y ventas
anuales entre US$ 40000 a US$ 750000.

1.1.3 Áreas que comprende y sus funciones

La empresa Exacta Lab, comprende las siguientes áreas:
- Recepción: es donde se atiende al público en general donde se da informes y
se registra los datos y resultados de los análisis realizados a pedido por los
médicos de los pacientes.
- Laboratorio: es donde se realizan los análisis clínicos por profesionales en cada
área, este también cuenta con sub áreas de bioseguridad y toma de muestras.
1.2 Historia y evolución
El laboratorio clínico Exacta Lab, es una extensión de la Clínica de Diabetes y Tiroides, quién
esta última es una persona jurídica de derecho privado. El laboratorio inicio sus actividades
en enero del 2008 en la Calle Juana Espinoza 121 Umacollo – Arequipa, para lo cual realizo
convenios con otra clínicas, para realizar los análisis clínicos de sus pacientes, en octubre
del 2008, abrió una sucursal en el distrito del Cercado para la toma de muestras y en Junio
del 2010 otra sucursal en el distrito de José Luis Bustamante y Rivero, esto para facilitar el
acceso a la toma de muestras de sus pacientes, ya que la oficina central era muy lejos para
algunos de ellos.
1.3 Servicios que presta
El Laboratorio Clínico Exacta Lab, presta los siguientes servicios:
- Análisis clínicos en: hematología, bioquímica, inmunología, microbiología, hormonas,
marcadores oncológicos y patología.
- Servicio de vista al hogar del paciente para la toma de muestra.
- Servicio de delivery de los resultados de los análisis clínicos al médico tratante.
 CAPITULO II
ANÁLISIS DEL SISTEMA
ACTUAL
2.1. Acciones Preliminares

2.1.1. Ciclo de Vida de desarrollo del Software

Las iteraciones iniciales de la elaboración se centran en el análisis. Eso contribuye a

obtener una arquitectura estable y sólida y facilita una comprensión en profundidad
de los requisitos. Al término de la fase de elaboración y durante la construcción,
cuando la arquitectura es estable y se comprenden los requisitos, el énfasis pasa en
cambio al diseño y a la implementación.

El propósito y objetivo del análisis debe alcanzarse de algún modo en todo proyecto.
Pero la manera exacta de ver y de emplear el análisis puede diferir de un proyecto
a otro; para lo cual es necesario distinguir tres variantes básicas:

a) El proyecto utiliza un modelo de análisis para describir los resultados del análisis
y mantiene la consistencia de este modelo a lo largo de todo el ciclo de vida del
software.

b) El proyecto utiliza el modelo de análisis para describir los resultados del análisis
pero considera a este modelo como una herramienta transitoria e intermedia –
quizás de más interés en la fase de elaboración -. Cuando el diseño y la
implementación están en marcha durante la fase de la construcción, se deja de
actualizar el análisis. En su lugar cualquier tema de análisis que aún “quede” se
resuelve como parte integrada dentro del trabajo de diseño en el modelo de
diseño resultante.

c) El proyecto no utiliza en absoluto el modelo de análisis para describir los

resultados del análisis. En cambio, el proyecto analiza los requisitos como parte
integrada en la captura de requisitos o en el diseño.

En el primero de los casos, hará falta un mayor formalismo en el modelo de

casos de uso. Esto puede ser justificable si el cliente es de comprender los
resultados. El segundo caso podría complicar el trabajo de diseño sin embargo
esto puede ser justificable si, por ejemplo, los requisitos son muy simples y/o
son bienes conocidos, si es fácil identificar la forma del sistema (incluyendo su
arquitectura), o si los desarrolladores cuentan con una cierta comprensión,
intuitiva pero correcta, de los requisitos, y son capaces de construir un sistema
que los encarne de una manera directa.

Al elegir entre las dos primeras variantes, se debe sopesar las ventajas de mantener
el modelo del análisis con el coste de mantenerlo durante varias iteraciones y
generaciones.

Por tanto se hace necesario realizar un análisis coste/beneficio correcto, y decidir

si es necesario dejar de actualizar el modelo análisis – quizá tan pronto como al final
de la fase de la elaboración – o si, deberíamos conservarlo y mantenerlo durante el
resto de la vida del sistema.
 En cuanto a la tercera variante, es correcto que el proyecto puede o no sólo evitar
el coste de mantener el modelo de análisis, sino también el introducirlo al principio
(incluyendo el coste en tiempo y recursos que consume el formar a los
desarrolladores – y el hacer que tomen experiencia – en el uso del modelo). Sin
embargo, normalmente las ventajas de trabajar con un modelo de análisis por lo
menos al principio del proyecto sobrepasan los costes de emplearlo; por tanto, sólo
deberíamos emplear esta variante en casos excepcionales para sistemas
extraordinariamente simple.

A continuación se ilustra el ciclo de iteraciones:

Iteraciones

2.2. Recopilación de la información

La recopilación de la información tiene por finalidad los requerimientos del sistema, así
también para conocer cómo trabaja y donde es necesario efectuar mejoras sí que existe
alguno.

2.2.1. Revisión documental

Los procesos de registro, ubicación y seguimiento de expedientes en toda

institución ha ido evolucionando notablemente hasta convertirse en la columna
vertebral de ellas, es por este motivo que las empresas hoy día agotan sus esfuerzos
 y realizan fuertes inversiones para mejorar estos procesos a fin de que cada día sean
más eficientes, se realicen en menor tiempo, sean oportunos y confiables.

En esta fase se realizará una evaluación de la trayectoria e historia del sistema así
como los cambios que han sufrido durante su evolución.

2.2.2. Entrevista para obtener requerimientos

Las entrevistas realizadas durante la etapa de recolección de información tienen la

finalidad de determinar las razones que se encuentran detrás del presente trabajo
de investigación.

Es aquí en esta etapa donde se inicia el proceso determinación de los

requerimientos y necesidades de los usuarios para contar con un sistema que
solucione su problemática.

2.2.2.1. Selección de personas a entrevistar

Para seleccionar a las personas a entrevistar, se deben tener en cuenta los

siguientes requisitos:

 Posición jerárquica, en este caso al director o gerente del laboratorio.

 Que tengan inherencia en la toma de decisiones en el planeamiento y
en el diseño de estrategias.
 Que tengan personal a su cargo.
 Que tengan relación directa con el sistema a evaluar y/o a implantar.
 Deseable antigüedad en la organización.

Teniendo en cuenta los requisitos planteados y seleccionados

anteriormente se decidió por entrevistar a las siguientes personas:

a) Dr. Paolo Jiménez Orbegoso – Gerente.

b) Srta. Paola Muñoz Álvarez – Secretaria.
c) Srta. Johanna Madariaga Herrera – Asistente Laboratorio.

2.2.2.2. Diseño de la entrevista

En el cuestionario que se preparó para el desarrollo de las entrevistas, se

plantearon algunas de las siguientes situaciones:

a) Con el sistema automatizado de registro de análisis clínicos para

pacientes, cumplen todas sus expectativas.
b) Con el sistema que utilizan en el laboratorio es en entorno web o
escritorio.
c) Que problemas o inconvenientes en cuanto al sistema y a la empresa
que lo desarrollo.
d) Le gustaría que el sistema funcione en Internet y así usted pueda
ingresar y pedir información desde cualquier computador conectado a
Internet.
e) Escriba los requerimientos que usted necesita, si el laboratorio decide
comprar otro sistema con similares características.

El modelo del cuestionario que se diseñó, el 50% es sobre decisión (SI/NO)

y el otro 50% sobre contestar las preguntas.

Asimismo se ha considerado este diseño a fin de que sea más fácil y practica
su integración para el momento de la evaluación y conclusión.
 CAPITULO III
ANALISIS Y DISEÑO DEL SISTEMA PROPUESTO
3.1. Metodología para el desarrollo del sistema

3.1.1. Análisis y diseño orientado a objetos

El análisis y diseño orientado a objetos constituye una nueva forma de pensar acerca
de problemas empleando modelos que son útiles para comunicarse con expertos
en esta aplicación, modelar empresas, preparar documentación, diseñar programas
y bases de datos.

La esencia del análisis y diseño orientado a objetos es la identificación y organización

de conceptos de dominio de la aplicación, y no de su presentación final en un
lenguaje de programación, es decir, que es un proceso conceptual independiente
de si el lenguaje es orientado a objetos o no.

El uso del análisis y diseño orientado a objetos puede facilitar mucho la creación de
prototipos, y las técnicas de desarrollo evolutivo de software. Los objetos son
inherentes reutilizables, y se puede crear un catálogo de objetos que podemos usar
en sucesivas aplicaciones. De esta forma podemos obtener rápidamente un
prototipo del sistema, que pueda ser evaluado por un cliente, a partir de objetos
analizables, diseñados e implementados en aplicaciones anteriores. Y lo que es más
importante, dada la facultad de reutilización de estos objetos, el prototipo puede ir
evolucionando hacia convertirse en el sistema final, según vamos refinando los
objetos de acuerdo a un proceso de especificación incremental.

En conclusión: “El análisis y diseño orientado a objetos es un proceso continuo

donde no existe una división clara entre el análisis y el diseño, además, está
centrada en un concepto de modelado y no de técnicas de implementación por lo
que es independiente de todo lenguaje de programación hasta las etapas finales”

3.1.2. Descripción de las metodologías más usadas

 METODOLOGÍA OMT

La Técnica de Modelo de Objetos (OMT) fue desarrollada or James Rumbaugh,

es una metodología orientada a objetos muy difundida que se hace cargo de
todo el ciclo de vida del software.

Parte de la idea de utilizar los mismos conceptos y la misma notación a lo largo

de todo el ciclo de vida.

Divide el ciclo de vida del software en cuatro fases consecutivas:

1. Análisis de Objetos: esta fase tiene por finalidad la descripción del problema
en un modelo de análisis.

2. Diseño del Sistema: comprende la arquitectura básica. En esta fase se

tomarán las decisiones estratégicas del diseño.
 3. Diseño de Objetos: es el último paso antes de implementar y sirve para
definir completamente todas las características de los objetos. Se detallan
los tres modelos ya descritos en el análisis de objetos para poder
implementarlo y optimizar la etapa de programación.

4. Implementación: se codifica el diseño en un lenguaje específico.

 METODOLOGÍA UML

Esta metodología surge cuando J. Rumbaugh y G. Booch en el año de 1994 se

unen en una empresa en común (de objetivos y de negocios) Rational Software
Corporación donde unifican sus dos métodos y como fruto de dicha unión
aparece en Octubre de 1995 UML 8.0 (Unified Modeling Language). A finales de
ese mismo año se une al grupo I. Jacobson, creador de OOSE (Object Oriented
Software Engineer) para finalmente conseguir un modelo totalmente unificado.

En el proceso de creación de UML, han participado, no obstante, otras empresas

de gran peso en la industria como Microsoft, Hewlett Packard, Oracle o IBM, así
como grupos de analistas y desarrolladores. UML no define un proceso concreto
que determine las fases de desarrollo de un sistema, las empresas pueden
utilizar UML como el lenguaje para definir sus propios procesos y lo único que
tendrán en común con otras organizaciones que utilicen UML serán los tipos de
diagramas.

Esta metodología ofrece los siguientes diagramas en los cuales se puede

modelar sistemas.

- Diagrama de estructura estática

 Diagramas de caso de uso: representa un conjunto de casos de uso, actores
y sus relaciones. Vista de caso de uso estática para organizar y modelar el
comportamiento del sistema.
Diagrama de clases: para modelar la estructura estática de las clases del
sistema
Diagrama de objetos: para modelar la estructura estática de los objetos del
sistema.

- Diagramas dinámicos

Diagramas de secuencia: para modelar el paso de mensajes entre objetos

Diagramas de colaboración: para modelar interacciones entre objetos
Diagramas de estado: representa la secuencia de estados por los que pasa
un caso de uso o un objeto a lo largo de su vida, indicando que eventos hacen
que pase de un estado a otro y cuáles son las respuestas y acciones que
genera.

Teniendo en cuenta el estándar UML no define un proceso de desarrollo específico,

tan solo se trata de una notación.

En este estudio de tesis se sigue el método propuesto por Craig Larman que se
ajusta a un ciclo de vida iterativo e incremental dirigido por casos de uso.

Un proceso de desarrollo es el que se ocupa de plantear como se realiza el análisis,

diseño y como se relacionan los productos de ambos, entonces la construcción de
sistemas de software va a poder ser planificadle y repetible y la probabilidad de
obtener un sistema de mejor calidad al final del proceso aumenta
considerablemente. Este proceso define una serie de actividades que pueden
realizarse en cada fase, las cuales deben de adaptarse según las condiciones del
proyecto que se esté llevando a cabo. Se ha escogido seguir este proceso debido a
que aplican los últimos avances en Ingeniería de Software y que adopta un enfoque
eminentemente práctico.

Las tres fases al nivel más alto son los siguientes:

Planificación
Planificación y Construcción de Prototipos.

Construcción
La creación del sistema. Las fases dentro de esta etapa son las siguientes:

Análisis
Se analiza el problema a resolver desde la perspectiva de los trabajadores y de las
entidades externas que van a solicitar los servicios del sistema.

Diseño
 El sistema se especifica en detalle, describiendo como va a funcionar internamente
para satisfacer lo especificado en el análisis.

Implementación
Se lleva lo especificado y detallado en el diseño a un lenguaje o herramienta de
programación.

Pruebas
Se lleva a cabo una serie de pruebas para corroborar que el sistema funciona
correctamente y que satisface las necesidades especificadas en etapa de
planificación.

Instalación
Esta etapa se refiere a la puesta en funcionamiento del sistema en el entorno de
uso previsto.

La mayor parte del esfuerzo y del tiempo en un proyecto de desarrollo se dedica a

la etapa de construcción. Esta etapa se lleva a cabo tomando en cada iteración un
subconjunto de los requisitos que llevados a través del análisis y diseño hasta la
implementación y pruebas permitirá que el sistema vaya creciendo
incrementalmente en cada ciclo.

Este proceso es ilustrado gráficamente en la figura que se muestra a continuación:

Planificación Construcción Instalación

Ciclo de desarrollo Nº 1 Ciclo de desarrollo Nº 2 Ciclo de desarrollo Nº n

Refinar plan Análisis Diseño Implementar Pruebas

DESARROLLO INTERACTIVO EN LA CONSTRUCCIÓN

Análisis

En la fase de análisis de un ciclo de desarrollo se investiga el problema sobre los

conceptos relacionados con el subconjunto de casos de uso que se esté tratando.
Se intenta llegar a una buena comprensión del problema por parte del equipo de
desarrollo, sin entrar como va a ser la solución en cuanto a detalles de la
implementación.

3.1.3. Comparación entre el análisis y diseño orientado a objetos y el análisis y diseño

estructurado
 Es importante tener el concepto básico y claro de las diferencias que se establece
en lo estructurado y en lo orientado a objetos, es por este motivo que se muestra a
continuación y cuadro donde se podrá visualizar las diferencias que existen entre
ambos.

Análisis y Diseño Análisis y Diseño

ESTRUCTURADO
El Análisis y diseño estructurado se basa
fundamentalmente en la descomposición
funcional del sistema que queremos
construir.
Esta descomposición funcional requiere
traducir el dominio del problema en una
serie de funciones y sub funciones. Lo que
puede parecer la forma más directa de
implementar un objetivo deseado, pero el
sistema resultante puede ser demasiado
frágil.
Los cambios en los requisitos afectan
notablemente a la funcionalidad del sistema,
por lo que afectan mucho al software
desarrollado, por lo que puede ser necesaria
una importante reestructuración.
ORIENTADO A OBJETOS
El Análisis y diseño orientado a objetos
buscan ante todo descomponer un espacio
de problema por objetos y esto permita
analizar mejor el dominio del problema.
El concepto orientado a objetos es más
simple y permite una mejor comunicación
entre el analista y el experto en el dominio
del problema (es decir el usuario).
Las evoluciones de los requisitos afectan en
mucha menor medida a los objetos que
componen o manejan el sistema, que son
mucho más estables.

3.1.4. Fundamentos para la selección de la metodología UML

UML ha sido desarrollado con el propósito de ser útil para modelar diferentes
sistemas de información, técnicos (telecomunicaciones, industria), y no sólo es útil
para la programación sino también para modelar negocios, es decir, los procesos y
procedimientos que establecen el funcionamiento de una empresa. Por lo tanto
existe suficiente razón para que pueda ser utilizado en la mayoría de los proyectos
de software.

UML en su versión 1.0 fue propuesto y aprobado por OMG (Object Management
Group) en noviembre de 1997.

El Lenguaje Unificado de Modelado (UML) es una metodología que tiene como

objetivo conseguir un Modelo Unificado, abierto que siga evolucionando en
conjunto y no por separado tal como estaba ocurriendo hasta ese entonces
comprensible por el hombre, utilizable por la máquina y fundamentalmente con la
capacidad de unificar las perspectivas de diferentes sistemas. Asimismo está dirigido
por los casos de uso, centrado en la arquitectura y es iterativo e incrementa, permite
guiar a los desarrolladores en la implementación y distribución eficiente de sistemas
que se ajusten a las necesidades de los clientes y usuarios.

Además, prescribe un conjunto de notaciones y diagramas estándar para modelar

sistemas orientados a objetos y describe la semántica esencial de los que estos
diagramas y símbolos significan.
3.1.5. Software a utilizar para el Modela miento

Se ha seleccionado el software libre POSEIDON FOR UML, para efectos del presente
proyecto.

POSEIDON FOR UML, es una herramienta general para modelar cualquier clase de
sistema que precise programación orientada a objetos incluso sistemas que no
tengan nada que ver con software.

Un modelo UML puede ser bastante complejo en su desarrollo. Diferentes aspectos

de la información disponible son importantes para diferentes personas y en
diferentes momentos. POSEIDON FORM UML ofrece diferentes maneras de navegar
entre los elementos del modelo.

Entre las principales ventajas de POSEIDON FOR UML podemos mencionar:

 Totalmente implementado en Java, independiente de la plataforma.

 Soporta todos los diagramas de UML.
 Guarda en formato compatible con UML 2.0 Diagram Interchange Standard.
 Soporte para XMI 1.2, formato estándar de almacenado.
 XMI 1.0, 1.1 y 1.2 son admitidos.
 Exporta los diagramas como gif, ps, eps y svg.
 Soporte para los formatos jpeg y png para JDK 1.4.
 Copy/cut/paste en la herramienta.
 Drag and drop en la herramienta.
 Internacionalización para inglés, alemán, ruso, francés, español, y chino.
 Generación de código Java.
 Fácil instalación de actualizaciones mediante Java Web Start.
 Totalmente liviano para trabajar
 No requiere equipo de última tecnología para trabajar
 Sin Costo alguno totalmente libre utilizando la edición CE que ofrece 3 meses
gratuitos, tiempo suficiente para el modela miento.

3.2. Análisis

3.2.1. Definir requisitos

Es la descripción de necesidades o aspiraciones respecto a un producto. Al

determinar los requisitos se utilizan diversas fuentes tales como entrevistas,
cuestionarios, entre otros, información que se puede traducir en un formato a
seguir para la especificación de los requisitos. Este formato de especificación de
requisitos no está definido en UML, pero incluye este punto para resaltar esta
actividad que es un paso clave en la creación de software.

3.2.2. Casos esenciales de uso

Un caso de uso es un documento narrativo que describe la secuencia de eventos

de un actor (agente externo) que usa un sistema para completar un proceso.
 Dados estos se clasifican en casos de uso de alto nivel y casos de uso de uso
expandidos; primero se ha iniciado por describir los casos de uso de alto nivel
para lograr un rápido entendimiento de los procesos principales.

A continuación se describen los casos de uso del sistema propuesto:

Tabla III.1

Caso de uso: Registrar Pacientes

Actores: Recepcionista y paciente.
Tipo: Primario
Descripción:
- El paciente presenta la hoja de los análisis que tiene que realizarse a la
recepcionista.
- La recepcionista recibe la hoja de análisis y registra al paciente.
- Se crea un código único del paciente para su posterior identificación.

Tabla III.2

Caso de uso: Registrar Médicos

Actores: Recepcionista.
Tipo: Primario
Descripción:
- La recepcionista ingresa los datos de los médicos que emiten la hoja de
análisis otorgado por el paciente y lo registra.
- Se crea un código único para cada médico para su posterior identificación.

Tabla III.3

Caso de uso: Registrar Tipo de examen

Actores: Recepcionista.
Tipo: Primario
Descripción:
- La recepcionista registra los tipos de examen que realiza el laboratorio en
los análisis clínicos.

Tabla III.4

Caso de uso: Registrar examen – análisis

Actores: Recepcionista.
Tipo: Primario
Descripción:
- La recepcionista registra los exámenes que realiza el laboratorio.
- Una vez registrado el examen ingresa los parámetros de cada examen.

Tabla III.5

Caso de uso: Solicitar examen

Actores: Recepcionista.
Tipo: Primario
Descripción:
 - La recepcionista busca al paciente y médico, elije los exámenes a realizar
para el paciente.
- Ingresa los resultados de los exámenes realizados.
- La recepcionista registra la solicitud del examen.

Tabla III.6

Caso de uso: Consulta histórica

Actores: Recepcionista y paciente.
Tipo: Primario
Descripción:
- La recepcionista busca los datos del paciente.
- Visualiza todos los análisis del paciente realizados hasta el momento.
- La recepcionista puede imprimir los análisis elegidos.

Tabla III.7

Caso de uso: Registrar comisión

Actores: Recepcionista.
Tipo: Primario
Descripción:
- La recepcionista busca los datos del médico para su comisión por análisis.
- Visualiza los pacientes de cada médico atendidos durante el mes y elige
paciente por paciente.
- Ingresa la cantidad de análisis y el total de los análisis de cada paciente y lo
registra.
- La recepcionista puede imprimir el reporte por comisión que corresponde
para cada paciente.

Tabla III.8

Caso de uso: Ingresar al sistema

Actores: Usuarios
Tipo: Primario
Descripción:
- El usuario ingresa sus datos como login y password para ingresar al sistema.
- Una vez dentro del sistema el usuario puede realizar todos los movimientos
que realiza el sistema.

3.2.3. Crear el diagrama de casos de uso

El siguiente gráfico describe el Sistema de Administración y Control de Análisis

Clínicos para Pacientes.

3.2.4. Crear el modelo conceptual

El modelo conceptual es el diagrama de estructura estática de UML que permite

una representación de conceptos del mundo real, no de componentes de
software.
3.2.5. Diagrama de secuencia del sistema

Los diagramas de secuencia reflejan el comportamiento.

3.2.6. Diagrama de actividades
3.3.2. Diagrama de Clases
 3.3.3. Diagrama de relaciones

3.4. Implementación de la Base de Datos

3.4.1. Concepto de base de Datos

Se define una base de datos como una colección de datos

interrelacionados y almacenados juntos sin redundancia perjudicial e
innecesaria para servir a múltiples aplicaciones.

 Los datos deberán ser almacenados de manera tal que:

 Sean independientes de los programas que los usan
 Presenten un enfoque común y controlado para agregar nuevos
datos, actualizarlos o eliminarlos.
 Su estructura sirva de fundamento al desarrollo de nuevas
aplicaciones.

Entre las ventajas más importantes de una base de datos podemos

resaltar:

 Consistencia de datos.
 Compartimiento de datos.
 Seguridad de datos.
 Integridad de datos.
 Independencia de datos: un cambio en los datos no implica cambio
en los programas o viceversa.
  Cumplimiento de ciertas normas: restricciones de seguridad, accesos
de los usuarios a los datos y operaciones sobre los datos.
 Mayor estandarización
 Otras ventajas: mejor gestión eficiente de almacenamiento.

3.4.2. Conversión del diagrama de clase a una Base de Datos

Los actuales diseños orientados a trabajar bajo Web en intranet o Internet

son eficientes, coherentes y menos proclives a los problemas de
actualización que aquejan a muchas otras técnicas de diseño de bases
de datos.

En realidad el software libre de administración de datos como MySQL ha

ganado bastante popularidad por lo que cada día se han incrementado
sus ventajas en lo tocante a funcionalidad y flexibilidad y además está
ganando cada día más usuarios.

MySQL, es un software libre totalmente amigable y sin costo alguno.

Permite implementar bases de datos desde diseñadores de bases; en el
caso específico de este proyecto hemos utilizado como diseñador de
bases de datos y diagramas de clases, diagramas de datos y relaciones
MYSQL-FRONT en su versión libre.

MySQL es un sistema de administración de bases de datos relacional

(RDBMS) se trata de un programa capaz de almacenar una enorme
cantidad de datos de gran variedad y de distribuirlos para cubrir la
necesidad de cualquier tipo de organización, desde pequeños
establecimientos comerciales a grandes empresas y organismos
administrativos. MySQL compite con sistemas RDBMS propietarios
conocidos como Oracle, SQL Server y DB2. 1

Utilizando el MYSQL-FRONT en su versión libre, podemos implementar

el diseño de la base de datos.

3.4.3. Transformación del diagrama de clases en modelos de tablas

Esta sección se centra únicamente en la transformación de clases a

tablas, donde se aplicará las reglas de correspondencia porque el
modelado de objetos no introduce nada nuevo en este sentido. La
conversión será la misma para las tablas derivadas de objetos de
correspondencia a las que se derivan de enfoque tradicional.

A continuación se hará una breve referencia para mostrar las reglas de

correspondencia que se ha basado para las relaciones:

Correspondencia entre clases y tablas

Toda clase se corresponde con una o más tablas; de igual manera que
una clase tiene atributos, esos atributos pasan a ser atributos de la tabla,
añadiendo el ID del objeto y detalles como partes de la formulación del
modelo de tablas, especificando que atributos pueden o no ser nulos y
asignando un dominio a cada atributo.

Correspondencia entre Asociaciones y Tablas

En términos generales, una asociación puede o no corresponderse con

una tabla ya que esto depende del tipo y multiplicidad de la asociación y;
del criterio de quien diseña la base de datos.

Puede presentarse el caso de asociaciones de Uno-a-muchos con una

clave externa en la tabla para la clase “muchos”

También puede presentarse la asociación de muchos-a-muchos,

extraídas del diagrama de clases.

La asociación muchos-a-muchos siempre se corresponde con una tabla

concreta, satisfaciendo así la tercera forma normal.

Las claves primarias tanto la para las clases relacionadas como para los
atributos de enlace pasan a ser atributos de la tabla de asociación.

Correspondencia de las generalizaciones a Tablas

Esta correspondencia se basa en las clases con herencia simple, sin

embargo la correspondencia consiste en eliminar la tabla de superclase
y los atributos de la superclase se duplican para cada subclase, esto le
permite eliminar la navegación de superclase a subclases y así acelerar
el proceso, manteniendo la tercera forma normal.
3.4.4. Modelo Conceptual

3.4.4.1. Ciclo de vida de la base de datos

La primera etapa de un diseño de Base de Datos es el diseño

del modelo conceptual, en la cual se construye el esquema de
información que se maneja en el área documentaria,
finalmente obtener una representación a través de los
diagramas.

Las bases de datos son unos de los componentes principales

de un Sistema informático; por lo que el ciclo de vida de un
sistema de información está inmerso directamente al ciclo de
vida de la base de datos sobre la que operará.

A continuación se mencionan las etapas que implican el ciclo

de la base de datos:

1. Planificación de la Base de Datos

2. Definición del Sistema, especificando el ámbito y los
límites del uso y aplicación de la base de datos.
3. Diseño de la Base de Datos
4. Implementación
5. Mantenimiento.

El Modelo de Datos es el enfoque utilizado para describir y

representar las características y relaciones entre datos, dentro
de la base de datos.

El Modelo Entidad – Relación (E/R), es un modelo de datos

compuesto por objetos llamados entidades y relaciones entre
ellos; es el modelo utilizado en el proceso de diseño y
desarrollo de la Base de Datos del Sistema Administración y
Control de Análisis Clínicos para Pacientes.

Es importante comprender que en un nivel más cercano en la

implementación el Modelo nos permite representar los datos
y las relaciones entre los datos mediante un conjunto de
tablas que posteriormente construirán la estructura de la base
de datos.
 Como principal elemento gráfico del modelado de
información, se tiene el Diagrama Entidad-Relación, el cual
está compuesto de las entidades y sus relaciones.

Es importante reconocer las entidades usadas por el sistema

para diseñar el diagrama Entidad / Relación. Para este
proyecto al realizar la primera normalización se obtiene
además las siguientes entidades:

- Pacientes.
- Médicos.
- Usuarios.
- Movimientos.
- DMovimientos.
- Categorías.
- Examen.
- PExamen.
- Caja.

3.4.5. Técnicas de normalización

La normalización simplifica el diseño de una base de datos a través de la

búsqueda de la mejor estructuración de las entidades involucradas.

La normalización es el proceso mediante el cual se transforman datos

complejos a un conjunto de estructuras de datos más pequeñas, que
además de ser más simples y más estables, son más fáciles de mantener

La Normalización se adoptó porque el viejo estilo de poner todos los

datos en un solo lugar, como un archivo o tabla de la base de datos, era
ineficiente y conducía a errores de lógica cuando se trataba de manipular
los datos.

Al modelar y crear una base datos es importante evitar puntos que crean
confusión, duplicación de información y; por ende un mal funcionamiento
y exploración de la información.

Es importante observar que la normalización nos permitirá:

1. La recuperación sencilla de datos

2. Simplificar el mantenimiento de los datos. Se entiende la inserción,
eliminación, modificaciones)
3. Minimiza el tiempo / costo para reorganizar los datos cuando se
requieran implementar nuevas aplicaciones, módulos, etc.
4. Elimina la información redundante y que muchas veces se registra en
forma repetitiva.
5. Reduce el tamaño de la base de datos
6. Permite una mejor organización estructural en el diseño e
implementación.

Existen cuatro Formas de Normalización, las mismas que se describen

brevemente:

Primera Forma de Normalización (1FN)

Un conjunto de relaciones esta en 1FN, si todos los atributos presentes

en éstas son atómicos, es decir que cada campo debe de tener un único
valor indivisible. Las relaciones de las entidades principales presentadas
se encuentran en primera forma normal.

En consecuencia establece que las columnas repetidas deben eliminarse

y colocarse en tablas separadas.

Segunda Forma de Normalización (2FN)

Se trabaja solo con aquellas relaciones que contienen dependencias

funcionales.

En consecuencia, establece que todas las dependencias parciales se

deben eliminar y separar dentro de sus propias tablas. Una dependencia
parcial es un término que describe a aquellos datos que no dependen de
la clave de la tabla para identificarlos.

Tercer Forma de Normalización (3FN)

La tercera y última forma de normalización establece que hay que

eliminar y separar cualquier dato que no sea clave. Es decir el valor de
esta columna debe depender de la clave. Todos los valores deben
identificarse únicamente por la clave.
 Cuarta Forma Normal

Una tabla está en cuarta forma normal si y sólo si para cualquier

combinación clave – campo no existen valores duplicados.

3.4.6. Modelado Lógico

La Arquitectura de Base de Datos, se divide en tres niveles: el nivel

externo, conceptual e interno.

En la gráfica que se muestra a continuación se puede observar estos tres

niveles:

A continuación se describe el concepto de cada uno de los niveles:

Nivel Interno: es el nivel más bajo de abstracción y define como se

almacena la información en el soporte físico.

Nivel Conceptual: es el nivel medio de abstracción, se trata de la

representación de los datos del sistema de de Administración y Control
de Análisis Clínicos para Pacientes, incluye la definición de datos y la
relación existente entre ellos.

Nivel externo: es el nivel de mayor abstracción, se refiere a las

diferentes necesidades o requerimientos con respecto a la base de datos
por parte de los usuarios.

El modelo de arquitectura de base de datos, permite establecer el

principio de independencia de los datos; esta independencia puede ser
lógica y física.
3.4.7. Modelado Físico

Una vez que se han definido las entidades, sus relaciones y sus atributos
o características podemos centrarnos en los requerimientos de datos
para cada entidad.

Se desarrollará un diagrama de estructura de datos a partir del modelo

conceptual y del modelo lógico planteado y, sobre todo basándose en las
técnicas de normalización indicadas.

Los componentes básicos que se visualizarán en los diagramas o

diseños de estructura de datos son las entidades, atributos, apuntadores
atributos y apuntadores lógicos.

Los apuntadores atributos enlazan dos entidades mediante la

información común usualmente un atributo llave en uno y, un atributo en
el otro.

Los apuntadores lógicos identifican las relaciones entre las entidades;

sirven para obtener acceso inmediato a la información en una entidad.

Los atributos llave pueden ser de dos tipos: las llaves primarias (Primary
Key) y las llaves foráneas (Foreing Key).

Con el software que se ha utilizado para el presente proyecto se podrá

observar las entidades, los campos o atributos junto con el tipo de dato
así mismo los atributos llave.
Tabla TBCaja

TBCategorias
Tabla TBdmovimientos

Tabla TBexamenes
Tabla TBmedicos

Tabla TBMovimientos
Tabla TBPacientes

Tabla TBparametrosexamen
Tabla TBUsuarios
 MODELADO DE TABLAS EN HTML GENERADO POR MYSQL-FRONT
Base de Datos: bdexactalab
Tabla: tbcaja
Índices:
Nombre Tipo
Índice principal IdCaja

Campos:
Nombre Tipo NULL Por defecto Extras Comentario
IdCaja int(11) auto_increment
IdMovimiento int(11) '0'
IdCategoria int(11) '0'
Cantidad int(11) '0'
Total decimal(10,2) '0.00'

Tabla: tbcategorias
Índices:
Nombre Tipo
Índice principal IdCategoria

Campos:
Nombre Tipo NULL Por defecto Extras Comentario
IdCategoria int(11) auto_increment
Nombre varchar(30) ''
Estado char(1) '1'

Tabla: tbdmovimientos
Índices:
Nombre Tipo
Índice principal IdDMovimiento

Campos:
Nombre Tipo NULL Por defecto Extras Comentario
IdDMovimiento int(11) auto_increment
IdMovimiento int(11) '0'
IdExamen int(11) '0'
IdPExamen int(11) '0'
Resultado varchar(100) NULL ''
RangoOp text

Tabla: tbexamenes
Índices:
Nombre Tipo
Índice principal IdExamen

Campos:
Nombre Tipo NULL Por defecto Extras Comentario
IdExamen int(11) auto_increment
IdCategoria int(11) '0'
Nombre varchar(50) ''
Metodo varchar(50) ''
Estado char(1) '1'
Tabla: tbmedicos
Índices:
Nombre Tipo
Índice principal IdMedico

Campos:
Nombre Tipo NULL Por defecto Extras Comentario
IdMedico int(11) auto_increment
Nombres varchar(30) ''
Apellidos varchar(30) ''
Especialidad varchar(50) NULL NULL
Colegio varchar(20) NULL NULL
Direccion varchar(50) NULL NULL
Telefonos varchar(30) NULL NULL
Estado char(1) '1'

Tabla: tbmovimientos
Índices:
Nombre Tipo
Índice principal IdMovimiento

Campos:
Nombre Tipo NULL Por defecto Extras Comentario
IdMovimiento int(11) auto_increment
IdPaciente int(11) '0'
IdMedico int(11) '0'
IdUsuario int(11) '0'
FechaMuestra date '0000-00-00'
FechaHoy date '0000-00-00'
FUR date '0000-00-00'
Comision char(1) 'N'

Tabla: tbpacientes
Índices:
Nombre Tipo
Índice principal IdPaciente

Campos:
Nombre Tipo NULL Por defecto Extras Comentario
IdPaciente int(11) auto_increment
Nombres varchar(30) ''
Apellidos varchar(30) ''
Sexo char(1) ''
Direccion varchar(120) NULL NULL
FechaNacimiento date NULL NULL
Telefonos varchar(100) NULL NULL
Email varchar(50) NULL NULL
Estado char(1) '1'
Tabla: tbparametroexamenes
Índices:
Nombre Tipo
Índice principal IdParametroExamen

Campos:
Nombre Tipo NULL Por defecto Extras Comentario
IdParametroExamen int(11) auto_increment
IdExamen int(11) '0'
Parametro varchar(100) ''
Rango text
Unidad varchar(20) ''
Estado char(1) '1'

Tabla: tbusuarios
Índices:
Nombre Tipo
Índice principal IdUsuario

Campos:
Nombre Tipo NULL Por defecto Extras Comentario
IdUsuario int(11) auto_increment
Nombres varchar(50) NULL NULL
Apellidos varchar(50) NULL NULL
Email varchar(50) ''
Password varchar(20) ''
Tipo char(1) ''
Estado char(1) ''
CAPITULO IV
INTERFACES
4. Diseño de las interfaces

4.1. Finalidad de las interfaces del sistema

Cuando uno usa una herramienta, o accede e interactúa con un sistema, suele haber
“algo” entre uno mismo y el objeto de la interacción.

En un auto, ese “algo” son los pedales y el tablero. En una puerta, es el picaporte. En
una máquina expendedora o un ascensor, los botones. En una computadora
(atención, que no me refiero a un producto informático sino una computadora), el
teclado, el monitor, el mouse, y otros periféricos.

Este “algo” nos informa qué acciones son posibles, el estado actual del objeto y los
cambios producidos, y nos permite actuar con o sobre el sistema o la herramienta.

Ese “algo”, que es a la vez un límite y un espacio común entre ambas partes, es la
interfaz.

En el caso de productos informáticos, la interfaz no es sólo el programa o lo que se ve

en la pantalla. Desde el momento que el usuario abre la caja(1), comienza a
interactuar con el producto y por lo tanto, comienza su experiencia.

A veces, tenemos que tener en cuenta elementos que en sentido estricto, no

pertenecen a nuestro producto, por ejemplo, la configuración previa a la instalación.
Tengan en cuenta, que aunque esto sea estrictamente cierto, para el usuario no es
importante.

4.1.1. Diseño de las interfaces

El diseño de interfaces es una disciplina que estudia y trata de poner en

práctica procesos orientados a construir la interfaz más usable posible, dadas
ciertas condiciones de entorno.

El entorno dentro del cual se inscribe el diseño de una interfaz y la medida de

su usabilidad, está dado por tres factores:

1. Una persona.
2. Una tarea.
3. Un contexto.

El diseño de interfaces pertenece a un campo mayor del conocimiento

humano, de origen altamente interdisciplinario, llamado Human Computer
Interaction.
 4.1.2. Proceso de desarrollo de interfaces

4.1.2.1. Diseño de interfaces

El diseño iterativo de interfaces es un proceso independiente de las

técnicas utilizadas para llevarlo a cabo.

Actualmente, el proceso del desarrollo de una interfaz se concibe

como un ciclo que consta de 4 etapas, en varios niveles:

1. Diseño
2. Implementación
3. Medición
4. Evaluación

4.1.2.2. El proceso de diseño

Además de la recursividad, otra característica del enfoque actual del

diseño de interfaces es que involucra no sólo a los especialistas en
usabilidad o diseño, sino a todo el equipo de desarrollo.

4.2. Interfaces de los principales procesos

INTERFAZ LOGIN DE USUARIO

INTERFAZ PRINCIPAL DE USUARIO

INTERFAZ REGISTRAR PACIENTES

 INTERFAZ REGISTRAR MÉDICOS

INTERFAZ REGISTRO TIPO EXAMEN

INTERFAZ REGISTRAR EXAMEN

INTERFAZ SOLICITUD DE EXAMEN
 REPORTE DE ANÁLISIS CLÍNICOS

REPORTE IMPRESIÓN DE SOBRE

INTERFAZ ENVIAR EMAIL ADJUNTO DE SU EXAMEN AL PACIENTE

INTERFAZ REPORTE DE COMISIONES

 REPORTE COMISIÓN MÉDICO

INTERFAZ REALIZAR BACKUP DE LA BASE DE DATOS

INTERFAZ REGISTRAR COMISIÓN MÉDICO
 CAPITULO V
EVALUACION ECONOMICA DEL
PROYECTO
5.1. Estudio de viabilidad

Si bien es cierto que el factor económico es imprescindible para evaluar la viabilidad

del cualquier proyecto se deben de tener en cuenta además el aspecto tecnológico y
operacional.

5.1.1. Viabilidad tecnológica

La viabilidad tecnológica determina si el sistema de trámite documentario es

viable tecnológicamente, es decir si existen herramientas tecnológicas y equipos
que hagan posible su implementación.

Por este motivo se realizó una evaluación física a las sucursales del laboratorio
EXACTA LAB, y se concluyó que cuenta con un total de 4 computadoras que
continuación se detallan:

Lugar Equipo computo

- Oficina Central 02
- Sucursal de la Av. La Paz 02
- Sucursal de la Av. EEUU 01
Total 04

Se puede apreciar que el laboratorio Exacta Lab cuenta con equipos necesarios
para implementar el sistema realizado.

En consecuencia se puede afirmar que el proyecto SI TIENE VIABILIDAD

TECNOLÓGICA.

5.1.2. Viabilidad operacional

La viabilidad operacional consiste en analizar si se cuenta o no con el personal y

las instalaciones que permitan el buen funcionamiento y operatividad del
sistema de Administración y Control de Análisis Clínicos para Pacientes.

En cuanto al personal necesario para poner en funcionamiento el sistema, es

suficiente con el que cuenta el laboratorio clínico.

La infraestructura física con las que cuenta actualmente son suficientes.

En consecuencia se puede afirmar que el proyecto SI TIENE VIABILIDAD

OPERACIONAL.

5.1.3. Viabilidad económica

La viabilidad económica determina si el valor económico del proyecto es menor

que el beneficio producido por la implantación del sistema.

La viabilidad económica también considera si la inversión necesaria puede ser

asumida por el laboratorio para contribuir en el logro de sus metas y objetivos.
 La pregunta a responder es si vale la pena invertir el dinero en el proyecto
propuesto y si la utilidad o el beneficio a obtener es considerable.

Este estudio de viabilidad económica se orientará básicamente en realizar una

evaluación y una comparación de dinero de los gastos de implementación en
dos plataformas diferentes ya que no se podrá evaluar ni considerar
equipamiento porque la universidad tiene equipos y no requiere de gastos en
este rubro, esta comparación se realizará luego de unos cálculos del proceso
que se denomina análisis de costes– beneficios.

5.2. Análisis de Costes y Beneficios

El objetivo es conseguir una lista de todo lo que se requiere para implementar el

Sistema de Administración y Control de Análisis Clínicos para Pacientes.

5.2.1. Costes de implantación

Es necesario realizar un análisis serio y responsable de los costes de

implantación del Sistema de Administración y Control de Análisis Clínicos para
Pacientes, que involucre todo el conjunto integral de los gastos que implica.

Para efectos de la implantación es necesario recordar que este sistema

funcionará en 4 equipos (5.1.1. Viabilidad Tecnológica) por lo tanto algunos de
los cálculos a realizar tomaran en cuenta esta cantidad.

Los costes que serán tomados para la implantación del Sistema Administración
y Control de Análisis Clínicos para Pacientes se basarán en software libre:

Costo de Servidor en Internet

Servidor en Internet Costo anual (S/.)
- Alquiler de dominio y hosting de 100.00
200 MB y 3000 MB de
transferencia.
Total 100.00

Costo de Software utilizado

Cantidad Software Total
01 MYSQL Administrador de Base de 0.00
Datos
01 PHP Lenguaje de Programación. 0.00
01 AJAX y Javascript 0.00
01 Poseidon for UML 0.00
01 MYSQL-FRONT (Versión Libre) 0.00
TOTAL 0.00
 Costo del desarrollo del software

Este monto lo constituye el monto fijado por el personal especialista en el

desarrollo de sistemas.

Costo de personal

Cantidad Personal Tiempo (meses) Costo S/. Total S/.

1 Analista 3 800.00 2,400.00
1 Programador 3 800.00 2,400.00
Total 4,800.00

Costo de Software

Descripción Costo x Lic. S/. Total S/.

Windows XP SP3 300.00 300.00
Lenguaje Programación PHP, 0.00 0.00
AJAX, JAVASCRIPT
Gestor de BD MYSQL 0.00 0.00
Total 300.00

Costo de servicios

Descripción Tiempo (meses) Costo S/. Total S/.

Luz 3 55.00 165.00
Agua 3 12.00 36.00
Total 201.00

COSTO TOTAL DE IMPLANTACIÓN: S/. 5401.00

5.2.2. Beneficios de implantación

Luego del presente estudio y luego de concluir que es importante su

implementación podemos mencionar los beneficios más importantes que se
lograrían:

 El Sistema de Administración y Control de Análisis Clínicos para Pacientes

brindará tanto a los trabajadores como a los pacientes información
oportuna, segura, actualizada y confiable.

 Contribuir a la eficiencia y eficacia del proceso de administración y control

de análisis clínicos.

 Se automatizará el registro, seguimiento y ubicación de los resultados de

los pacientes del laboratorio.
  Ahorrará tiempo para acceder a la información.

 Contar con un historial de los análisis realizados a los pacientes.

 Se mejorará notablemente la atención al paciente y por ende mejorará la

imagen institucional.

 Otros beneficios como: reducción de tasas de error, reducción de pérdidas

de información, reducción de tareas y procesos manuales (menor costo).

5.2.3. Determinación de la ejecución del proyecto

Luego del análisis de coste – beneficio que hemos descrito anteriormente

podemos concluir que los beneficios que se van a obtener versus la inversión
que significa la implantación son muchos mayores y satisfacen las necesidades
de la institución acorde con sus políticas, visión y misión.

Por lo tanto la implantación del Sistema Administración y Control de Análisis

Clínicos para Pacientes utilizando SOFTWARE LIBRE ES VIABLE
ECONOMICAMENTE.
 CONCLUSIONES

 La operatividad de la aplicación web, está basado en las Web 2.0 y Web 3.0, es bastante
amigable para el usuario final, porque presenta pantallas agradables a la vista, que evitan el
cansancio visual.

 El desarrollo de la aplicación web, mediante la programación orientada a objetos y

programación en tres capas, ahorra el tiempo en la codificación, detectando errores de una
forma más fácil y un mejor mantenimiento.

 La programación orientada a objetos y de tres capas, permite la reutilización y el ahorro de

líneas de código de la aplicación web.

 La utilización de le tecnología AJAX, reduce al mínimo el consumo de ancho de banda del

servidor.
 RECOMENDACIONES

 Para poder utilizar la aplicación web, los usuarios finales, necesitan tener conocimientos
básicos de ofimática e Internet para su operatividad.

 Para un futuro implementar esta aplicación web en Silverlight, ya que esta tecnología
permite trabajar como en escritorio pero está conectado a Internet, así el usuario final ya
no tendrá que hacer uso de los navegadores que muchos problemas en la compatibilidad.

 Implementar un módulo de control de asistencia de personal por medio de la huella digital,

siempre y cuando la aplicación web esté implementado en Silverlight.
 BIBLIOGRAFÍA

 WELLING, Luke y THOMSON, Laura. Desarrollo Web con PHP. 2da Edición 2005.
Editorial Grupo Anaya S.A.
 CABEZAS GRANADO, Luis Miguel. Manual Imprescindible de PHP 5. 1era Edición
2004. Editorial Grupo Anaya S.A.
 WIKIPEDIA. Programación en Capas.
http://es.wikipedia.org/wiki/Programacion_n_por_capas
 APRENDAGRATIS. Fundamentos de Programación en Capas.

http://www.aprendagratis.com/fundamentos-programacion-capas.html
 ANEXO

Figura Nº 1: Código de la clase paciente

Figura Nº 2: Código del patrón Singleton

Figura Nº 3: Código del patrón Factory

 Figura Nº 4: Código del modulo paciente, uso de patrón Factory y Singleton

Figura Nº 5: Código de Javascript creando el Objeto AJAX para registrar al Paciente

Figura Nº 6: Estructura proyecto de Exacta Lab