DESARROLLO DE UN SISTEMA DE INFORMACION PARA LA GESTION DE LA

HISTORIA CLINICA DE LOS PACIENTES DE UN CONSULTORIO DE

NUTRICIN Y DIETTICA

DAVID EDUARDO TOLEDO BECERRA

UNIVERSITARIA DE INVESTIGACION Y DESARROLLO

FACULTAD DE INGENIERA
PROGRAMA DE INGENIERA DE SISTEMAS
BUCARAMANGA
201
DESARROLLO DE UN SISTEMA DE INFORMACION PARA LA GESTION DE LA
HISTORIA CLINICA DE LOS PACIENTES DE UN CONSULTORIO DE
NUTRICIN Y DIETTICA

DAVID EDUARDO TOLEDO BECERRA

Ing. DANITH PATRICIA SOLORZANO ESCOBAR.

Directora

UNIVERSITA DE INVESTIGACION Y DESARROLLO

FACULTAD DE INGENIERA
PROGRAMA DE INGENIERA DE SISTEMAS
BUCARAMANGA
2016
 Nota de aceptacin

______________________________
______________________________
______________________________
______________________________
______________________________
______________________________
______________________________
______________________________
______________________________
______________________________

______________________________

Director

______________________________
Jurado

______________________________
Jurado

BUCARAMANGA NOVIEMBRE 2016

Tabla de contenido

1. PLANTEAMIENTO DEL PROBLEMA..................................................................5

2. JUSTIFICACIN................................................................................................... 6

3. ESTADO DEL ARTE............................................................................................. 7

3.1 @CLINIC...............................................................................................................7
3.2 CARE 2X............................................................................................................. 8
3.3 EXPERTOS........................................................................................................... 9
3.4 ENTIDAD INTERESADA........................................................................................ 10

4. OBJETIVOS........................................................................................................ 10
4.1 OBJETIVO GENERAL...........................................................................................10
4.2 OBJETIVOS ESPECFICOS....................................................................................10

5. MARCO REFERENCIAL.....................................................................................11
5.1 METODOLOGA DE DESARROLLO DE SOFTWARE: SCRUM......................................11
5.1.1 CARACTERSTICAS DE SCRUM..........................................................................12
5.2 ARQUITECTURA DE SOFTWARE...........................................................................13
5.2.1 CARACTERSTICAS...........................................................................................13
5.2.2 ARQUITECTURA DEL PROYECTO: MODELO VISTA CONTROLADOR.......................13
5.3 LEVANTAMIENTO DE REQUISITOS.........................................................................15
5.3.1 PROCESO DE ANLISIS JERRQUICO (AHP)......................................................15
5.3.2 CASOS DE USO...............................................................................................16
5.3.3 ENTREVISTAS.................................................................................................. 16
5.3.4 JOINT APPLICATION DESIGN (JAD)...................................................................17
5.3.5. PROTOTIPOS..................................................................................................18
5.4 PRUEBAS DE SOFTWARE....................................................................................19
5.4.1 PRUEBAS FUNCIONALES...................................................................................19
5.4.2 PRUEBAS DE COMPATIBILIDAD..........................................................................21

6. CRONOGRAMA..................................................................................................23

7. PRESUPUESTO..................................................................................................24

8. BIBLIOGRAFA...................................................................................................25
 1. PLANTEAMIENTO DEL PROBLEMA

Actualmente en el consultorio privado de la Dra. Joyce Almeyda no se cuenta con

un sistema de informacin que apoye a la gestin de las historias clnicas de los
pacientes que llegan a consulta de nutricin y diettica o al seguimiento de su
tratamiento ni con el historial de minutas que ya se hayan elaborado.

Algunos de los datos asociados con la historia clnica de los pacientes la Dra
Joyce Almeyda los lleva en herramientas ofimticas como Word y Excel, pero no
son todos los datos ni para todos los pacientes. El resto de informacin se lleva en
carpetas fsicas, los que obliga a designar un espacio fsico para el archivo de los
mismos y la posibilidad de que se extravi informacin.

Desde hace aproximadamente 5 aos la historia clnica ha cambiado es que al

formato de Excel se le han aadido y quitado campos de acuerdo a la necesidad
necesidades que se han venido presentando, tales como aumento en el nmero
de pacientes y seguimiento de pacientes que siguen tratamiento con la doctora
Almeyda.
2. JUSTIFICACIN

El presente proyecto surge ante la inquietud de la dra. Joyce Almeyda sobre el

manejo de la informacin en su consultorio adems que en el ao 2013 entr en
vigencia la ley 1438 de 2011 la cual indica que la historia clnica digital ser de
obligatoria aplicacin en Colombia, lo cual ayudar a que las redes de salud
puedan intercambiar informacin demogrfica, clnica y epidemiolgica entre los
diferentes actores y componentes del sistema de salud.
Con el desarrollo del presente proyecto se podr dar cumplimiento a esta
normatividad en lo cual se elaborar la histrica clnica digital de los pacientes,
esta historia clnica digital tiene sus ventajas que son:
Almacenar datos de manera segura, ya que el almacenamiento digital ayuda a la
conservacin de la informacin mdica de manera segura, pues ya no se
almacenarn los datos y la informacin de los pacientes de manera fsica, se
realizar de manera digital, lo que permitir dar custodia a la informacin del
paciente por medio de copias de seguridad.
Ahorrar tiempo y espacio: Pues el paciente y el mdico tratante no deben
desgastarse llenado la historia clnica cada vez que el paciente se traslada de
entidad de salud, o incluso si el paciente regresa a consulta, no se le tendrn que
preguntar nuevamente sus datos personales como lo son: la fecha y lugar de
nacimiento, tipo de sangre, entre otros.
En lo que a espacio se refiere, ya no se tendr que llevar papeleo ni archivos
fsicos, es decir el paciente no tendr que llevar su carpeta fsica con los datos de
su historia clnica y con los resultados de sus exmenes, pues toda esta
informacin estar cargada en el sistema.
Informacin oportuna y veraz: El paciente podr consultar su propia informacin
en el momento que lo desee y estar enterado de su evolucin, ya que se
desarrollar una interfaz para que el paciente pueda ingresar a la aplicacin,
adems de ver la informacin relacionada con la historia clnica, podr ver su
evolucin al cabo del tiempo, es decir, podr ver qu efecto ha tenido el
tratamiento y el mdico tratante podr llevar una continuidad y supervisin en el
tratamiento aplicado a cada paciente, pues podr ver qu tanto se ha adaptado al
plan alimentario definido .
 3. ESTADO DEL ARTE

A continuacin, se presentan algunas aplicaciones que ayudan en la gestin de los

procesos asociados con las historias clnicas de los pacientes:

3.1 @Clinic1

Clinic es una aplicacin de control y gestin de clnicas, consultas y centros

mdicos, ideal para los profesionales que quieran informatizar su negocio y
disponer de una herramienta que les permita control todo con facilidad.
Con Clinic se puede almacenar y administrar toda la informacin relacionada con:
citas, consultar, datos de los pacientes, fotos, historial mdico, estudios y
diagnsticos de todo tipo, farmacologa, entre otros. 2
Clinic tambin permite llevar el control de los pagos de los clientes, importar
informacin de bases de datos, imprimir cualquier dato o listado, o realizar
cualquier tipo de bsqueda.
Y todo ello, en una aplicacin de manejo sencillo para cualquier usuario, incluso
para aquellos que no estn habituados al uso de computadores. Y es que, adems
de contar con el espaol como idioma predeterminado para mostrar todos los
textos que aparecen en pantalla, en los mens y en las opciones del programa, los
autores de Clinic han llevado a cabo un excelente trabajo a la hora de desarrollar
la interfaz de usuario, consiguiendo que realizar cualquier operacin con el
programa nos resulte un proceso de lo ms cmodo, accesible e intuitivo

Caractersticas principales:
Bajos requerimientos de hardware.
Opera en amplia gama de versiones de Windows.
Personalizable.
Portable.

1 Sitio oficial: http://www.clubrem.es/clinic.htm consultado31/10/2016

2 Tomado de: http://clinic.programas-gratis.net consultado31/10/2016

Imagen tomada de: http://www.identi.li/index.php?topic=4012
consultado31/10/2016

3.2 Care 2X3

Care2x es un sistema de informacin hospitalaria basada en la web. Sirve para

integrar diversos sistemas de informacin (dentro del hospital) en un solo sistema
de informacin. Care2x es un proyecto de cdigo abierto basado en la licencia
GPL, es decir, el software y su cdigo fuente estn libremente disponibles para
todo el mundo.4
3 Sitio oficial: http://www.care2x.org/ consultado31/10/2016

4 Tomado de: http://www.babylon-software.com/definition/Care2x/

consultado31/10/2016
En 2002, el primer Cdigo fue publicado por Elpidio Latorilla. Desde entonces,
desarrollar ms de 100 miembros de ms de 20 pases Care2x. Desde el ao
2004, de Tanzania a una versin especial para los hospitales del frica Oriental,
as como en el trabajo general para los pases del tercer mundo. En este caso
fundamentalmente diferentes mdulos, tales como farmacia, laboratorio y mdulo
de facturacin y almacenamiento de ARV y se extendieron especialmente por
Robert Meggle o rediseados. Mientras tanto, encontrar, sobre la base de este
trabajo, fase piloto activo en Nepal y Brasil.
Care2x consta de cuatro componentes, pero que se pueden instalar por separado.
Sistema de informacin hospitalaria
Prcticas de Sistema de Informacin
Central de datos del servidor
Protocolo de intercambio sanitario (intercambio electrnico de datos)

Imagen tomada de: http://fosstoolkit.iosnasean.net/images/5/5e/Care2x.jpg

consultado31/10/2016
3.3 Expertos

La experta que asesorar el proyecto es la nutricionista y dietista Joyce Almeyda

con T.P. nmero MND 02932

3.4 Entidad interesada

Consultorio privado de la Dra. Joyce Almeyda ubicado en la calle 49 #28-10,

Edificio Galileo, consultorio 305 en la ciudad de Bucaramanga, y Carrera 13 a # 93
24, Edificio Prisma. Consultorio 211
4. OBJETIVOS

4.1 Objetivo General

Disear un sistema de informacin que gestione las historias clnicas y permita

hacer el seguimiento mediante la informacin que contienen estas historias de los
pacientes del consultorio nutricional de la Dra. Joyce Almeyda.

4.2 Objetivos especficos

1. Seleccionar una arquitectura de software que se adapte a los

requerimientos del cliente para el desarrollo del sistema de informacin
propuesto.

2. Disear las interfaces de usuario teniendo en cuenta las mejores prcticas

de usabilidad.

3. Desarrollar el sistema de informacin de historias clnicas utilizando un

lenguaje de programacin de alto nivel.

4. Realizar pruebas de usabilidad y pruebas de integridad de datos a la

aplicacin para la gestin de los pacientes del consultorio de la nutricionista
Joyce Almeyda.
5. MARCO REFERENCIAL

5.1 Metodologa de desarrollo de software: Scrum

El desarrollo gil de software son mtodos de ingeniera del software basados en
el desarrollo iterativo e incremental, donde los requerimientos y soluciones
evolucionan mediante la colaboracin de grupos auto organizados y
multidisciplinarios5. Existen muchos mtodos de desarrollo gil; la mayora
minimiza riesgos desarrollando software en cortos lapsos de tiempo
Scrum es un marco de trabajo para la gestin y desarrollo de software basada en
un proceso iterativo e incremental utilizado comnmente en entornos basados en
el desarrollo gil de software.

Aunque Scrum estaba enfocado a la gestin de procesos de desarrollo de

software, puede ser utilizado en equipos de mantenimiento de software, o en una
aproximacin de gestin de programas: Scrum de Scrums.

5.1.1 Caractersticas de Scrum

Imagen tomada de:

https://www.mountaingoatsoftware.com/uploads/blog/ScrumMediumLabelled.png
consultada 31/10/2016
5 Tomado de: http://www.2r0consulting.com/scrum-desarrollo-agil-de-software/
consultado 31/10/2016
Scrum es un modelo de referencia que define un conjunto de prcticas y roles, y
que puede tomarse como punto de partida para definir el proceso de desarrollo
que se ejecutar durante un proyecto6. Los roles principales en Scrum son el
ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de
proyecto, el ProductOwner, que representa a los stakeholders (interesados
externos o internos), y el Team que incluye a los desarrolladores.

Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es
definida por el equipo), el equipo crea un incremento de software potencialmente
entregable (utilizable). El conjunto de caractersticas que forma parte de cada
sprint viene del ProductBacklog, que es un conjunto de requisitos de alto nivel
priorizados que definen el trabajo a realizar. Los elementos del ProductBacklog
que forman parte del sprint se determinan durante la reunin de Sprint Planning

5.2 Arquitectura de Software

La arquitectura de software se refiere a la estructuracin del sistema que se crea
en etapas tempranas del desarrollo. Esta estructuracin representa un diseo de
alto nivel del sistema que tiene dos propsitos primarios: 7
satisfacer los atributos de calidad (desempeo, seguridad, modificabilidad)
servir como gua en el desarrollo.

La arquitectura de software es de especial importancia ya que la manera en que

se estructura un sistema tiene un impacto directo sobre la capacidad de este para
satisfacer lo que se conoce como los atributos de calidad del sistema

5.2.1 Caractersticas
La arquitectura de software forma la columna vertebral para construir un sistema
de software, es en gran medida responsable de permitir o no ciertos atributos de

6 Tomado de: http://www.northware.mx/wp-

content/uploads/2013/04/Desarrollo-cascada-vs-Desarrollo-Agile.pdf consultado
31/10/2016

7 Tomado de: https://sg.com.mx/revista/27/arquitectura-

software#.WAFbjpMrJE4
calidad del sistema entre los que se destacan la confiabilidad y el rendimiento del
software8.
Adems, es un modelo abstracto reutilizable que puede transferirse de un sistema
a otro y que representa un medio de comunicacin y discusin entre participantes
del proyecto, permitiendo as la interaccin e intercambio entre los desarrolladores
con el objetivo final de establecer el intercambio de conocimientos y puntos de
vista entre ellos.
5.2.2 Arquitectura del proyecto: Modelo Vista Controlador
Este proyecto se desarrollar utilizando la arquitectura Modelo Vista Controlador,
en el lenguaje Java Enterprise Edition, la cual es una plataforma para el desarrollo
de aplicaciones cliente servidor. Algunos beneficios de utilizar Java son:
transparencia de la ubicacin, visin orientada a objetos de la base de datos,
manejo transaccional, seguridad, alta disponibilidad y portabilidad (Navarro, 2010).
Java Enterprise Edition, define un conjunto de estndares que habilita soluciones
para el manejo y desarrollo de aplicaciones multicapa que son centralizadas en el
servidor, su fin es ser utilizado principalmente en el desarrollo de aplicaciones
empresariales ya que sus especificaciones y funcionalidades son orientadas a
negocios (Rodrguez, Gonzlez Moreno, & Murillas Herrera, 2008).
El paradigma MVC9, es un diseo conocido de separacin de la lgica de interfaz
y la lgica de negocio mediante la introduccin de una capa llamada controlador,
de esta forma una aplicacin se divide en tres capas (Puebla Hernndez & Garca
Dopico, 2009):
El modelo es el responsable de los datos de la aplicacin y la ejecucin de la
lgica de negocio.
La vista es la responsable de mostrar los datos a los usuarios y presentar los
elementos de interfaz necesarios para que interacten con el sistema.
El controlador es el intermediario entre el modelo y la vista.
En esta arquitectura los beans representan los datos, los servlets gestionan las
peticiones de los clientes, reenvan las peticiones a las pginas JSP, y las pginas
JSP acceden a los beans de resultados (Pavn Mestras, 2013).
Una aplicacin Java se entrega en un archivo JAR (Java Archive), un archivo de
archivos WAR (Web) o un archivo EAR (Enterprise Archive). Un archivo WAR o
EAR es un estndar JAR (.jar) con una extensin .war o .ear. Utilizando JAR,
8 Tomado de: https://www.ecured.cu/Arquitectura_de_software#Caracter.C3.ADsticas

9 Por sus siglas, Modelo Vista Controlador

WAR, y archivos EAR y los mdulos permiten montar un nmero de diferentes
aplicaciones Java EE utilizando algunos de los mismos componentes. No se
necesita ninguna codificacin adicional; es slo una cuestin de montaje (o
embalaje) varios mdulos Java EE en JAR Java EE, WAR, o archivos EAR.
Un archivo EAR contiene mdulos Java y, opcionalmente, los descriptores de
despliegue. Un descriptor de despliegue, un documento XML con una extensin
.xml, se describe la configuracin de despliegue de una aplicacin, un mdulo o un
componente. Dado que la informacin de descriptor de despliegue es declarativa,
que se puede cambiar sin la necesidad de modificar el cdigo fuente. En tiempo
de ejecucin, el servidor Java EE lee el descriptor de despliegue y acta sobre la
aplicacin, mdulo o componente en consecuencia.
Un mdulo Java consta de uno o ms componentes de Java para el mismo tipo de
envase y, opcionalmente, un componente descriptor de despliegue de ese tipo. Un
bean enterprise descriptor de despliegue del mdulo, por ejemplo, declara
atributos de transaccin y las autorizaciones de seguridad para un bean
enterprise. Un mdulo Java puede implementarse como un mdulo independiente.
Mdulos Java EE son de los siguientes tipos:
Mdulos EJB, que contienen los archivos de clases de beans de empresa y,
opcionalmente, un descriptor de despliegue EJB. Mdulos EJB son empaquetados
como ficheros JAR con una extensin .jar.
Mdulos Web, que contienen archivos de servlets de clase, los archivos web,
archivos de clase de apoyo, archivos de imgenes y HTML, y, opcionalmente, un
descriptor de despliegue de aplicaciones Web. Mdulos Web se empaquetan
como archivos JAR con una extensin .war (archivo web).
Mdulos de cliente de aplicacin, que contienen los archivos de clase y,
opcionalmente, un descriptor de despliegue del cliente de aplicacin. Mdulos de
cliente de aplicaciones se empaquetan como archivos JAR con una extensin .jar.
Mdulos de adaptador de recursos, que contienen todas las interfaces de Java,
clases, bibliotecas nativas, y, opcionalmente, un descriptor de implementacin del
adaptador de recursos. Juntos, estos implementan la arquitectura del conector (ver
Java EE Connector Architecture) para un estudio de impacto ambiental en
particular. Mdulos adaptadores de recursos son empaquetados como ficheros
JAR con una (archivo adaptador de recursos) extensin .rar.

En el proyecto se va a utilizar la Metodologa de desarrollo de software: Scrum

 1. Seleccin de los requisitos: se hace una lista priorizada en lo que va a
necesitar para guardar las informaciones de los clientes como datos
personales, la historia clnica que lleva en el tratamiento de las dietas, el
peso al inicio y al final del proceso.

2. Planificacin de la iteracin: Se elabora las tareas solicitada por la

doctora Joyce Almeida por medios de mdulos para satisfacer sus
necesidades con la informacin de cada paciente con su respectiva dieta y
proceso de perder peso

3. Demostracin: Se hace los mdulos que necesita la dra Joyce Almeida

para la informacin de los pacientes con su respectiva dieta y proceso a
largo y corto plazo dependiendo de la actitud del paciente, adems se har
modulo tambin para el paciente para que entre al sistema y verifique como
vas su proceso de peso y su buena alimentacin que est llevando a cabo

4. Retrospectiva: Se analiza si los mdulos que se hizo para la dra Joyce

Almeida de guardar los datos de los pacientes que est llevando en el
proceso de la nutricin y prdida de peso en los pacientes, se verifica el
modulo del paciente si l puede entrar al sistema y verificar el proceso das,
meses y aos segn dure la dieta que le ponga la doctora, verificar si el
paciente puede ver por medio del sistema cual es la dieta le ha asignado o
le ha cambiado segn su avance.

5.3 Levantamiento de Requisitos

El levantamiento de requerimientos es una etapa esencial en el inicio de todo
proyecto de desarrollo de sistema de informacin y debe de realizarse
efectivamente para poder incrementar la probabilidad de xito del proyecto 10
Muchos profesionistas no realizan correctamente esta fase porque no tienen el
conocimiento adecuado para realizarlo, o porque en sus empresas no hay
10 Tomado de; http://es.slideshare.net/RevistaSG/webinar-levantamiento-
reqsv1
procesos o guas que los apoyen en realizarlas, o porque sencillamente no ven la
necesidad de realizarlo
Existen las siguientes tcnicas de Levantamiento de Requerimientos:

5.3.1 Proceso de anlisis Jerrquico (AHP)

Fue desarrollado por Thomas Saaty, y est diseado para resolver problemas
complejos de criterios mltiples. El proceso requiere que quien toma las
decisiones proporcione evaluaciones subjetivas respecto a la importancia relativa
de cada uno de los criterios y que despus especifique su preferencia con
respecto a cada una de las alternativas de decisin y para cada criterio. El
resultado del AHP es una jerarquizacin con prioridades que muestran la
preferencia global para cada una de las alternativas de decisin 11
En un ambiente de certidumbre, el AHP proporciona la posibilidad de incluir datos
cuantitativos relativos a las alternativas de decisin, la ventaja del AHP consiste en
que adicionalmente permite incorporar aspectos cualitativos que suelen quedarse
fuera del anlisis debido a su complejidad para ser medidos, pero que pueden ser
relevantes en algunos casos.
El AHP, mediante la construccin de un modelo jerrquico, permite de una manera
eficiente y grfica organizar la informacin respecto de un problema,
descomponerla y analizarla por partes, visualizar los efectos de cambios en los
niveles y sintetizar.

5.3.2 Casos de Uso12

Los casos de uso se han convertido en la tcnica ms utilizada a nivel mundial
para el levantamiento y la comunicacin clara y eficiente de los requisitos (mejor
conocidos como requerimientos) para el desarrollo de sistemas.

Los casos de uso son parte del Lenguaje Unificado de Modelado (UML), que es
el estndar ms importante y ms ampliamente reconocido para la especificacin,
diagramacin y documentacin de software de calidad. El UML es un estndar
abierto (es decir, que no es propiedad de una empresa en particular), y es
11 Tomado de:
http://sisbib.unmsm.edu.pe/bibvirtualdata/tesis/basic/toskano_hg/cap3.pdf

12 https://monivela.wordpress.com/requerimientos/tecnicas-de-levantamiento-
de-requerimientos/
administrado por el Object Management Group (OMG) con el acuerdo y
participacin de prcticamente todas las principales organizaciones dedicadas al
desarrollo de software.

5.3.3 Entrevistas
Segn [Pressman , 2006], las entrevistas que se realizan al inicio del proyecto
deben contener preguntas libres de contexto divididas en tres conjuntos de
preguntas. Estas preguntas ayudan a iniciar la conversacin esencial para la
obtencin exitosa. Sin embargo, la sesin de preguntas y respuestas se debe usar
slo para los primeros encuentros.
El primer conjunto de preguntas se enfoca en los usuarios, otros interesados,
metas generales y en los beneficios medibles de una implementacin exitosa.

Algunos ejemplos de estas preguntas son:

Quin usar el sistema?
Cul ser el beneficio de la solucin propuesta?
Hay otra solucin posible (que no sea automatizar)?

El segundo conjunto de preguntas permite comprender mejor el problema y que

los usuarios expresen sus percepciones sobre una solucin. Algunos ejemplos de
estas preguntas son:

Cmo sera un buen resultado generado por una solucin exitosa?

Cules problemas podran surgir con la solucin propuesta?
Puede describir el ambiente en el que se usar la solucin?
Qu aspectos especiales de desempeo o restricciones afectarn la forma en
que se busque la solucin?

El tercer conjunto de preguntas se enfoca en la efectividad de la entrevista en s.

Algunos ejemplos de estas preguntas son:
Es Usted la persona adecuada para contestar las preguntas?
 Alguien ms puede proporcionar informacin adicional?
Existe informacin adicional que desee aportar?

5.3.4 Joint Application Design (JAD)

Es un proceso usado en el rea del ciclo de vida de prototipo del mtodo de
desarrollo de sistemas dinmicos (DSDM) para reunir requerimientos en el
desarrollo de nuevos sistemas de informacin para una compaa. El proceso JAD
tambin incluye enfoques para la mejora en la participacin de los usuarios,
agilizar el desarrollo, y mejorar la calidad de las especificaciones. 13
Consiste en un taller donde los trabajadores del conocimiento y los especialistas
en tecnologas de informacin se renen, algunas veces durante varios das, para
definir y revisar los requerimientos de negocio para el sistema. Los asistentes
incluyen oficiales de administracin de alto nivel, quienes se aseguran de que el
producto provea los reportes y la informacin requerida al final. Esto acta como
un proceso de administracin que permite que los departamentos de Servicios
de Informacin Corporativa trabajen ms eficientemente con los usuarios en un
marco de tiempo ms reducido.
A travs de los talleres JAD los trabajadores del conocimiento y los Especialistas
en Tecnologas de Informacin pueden resolver cualquier dificultad o diferencias
entre las posturas referentes al nuevo Sistema de Informacin. El taller sigue una
detallada agenda para lograr garantizar que todas las incertidumbres entre los
grupos sean cubiertas y para ayudar a prevenir cualquier falla en la comunicacin.
Estas fallas de comunicacin pueden provocar repercusiones mucho ms serias si
no se identifican a tiempo. Al final, este proceso resultar en un nuevo Sistema de
Informacin viable y orientado tanto a diseadores como a usuarios.
Aunque el diseo JAD es mundialmente aclamado, se sabe poco sobre su
efectividad en la prctica. De acuerdo al Journal os Systems and Software, un
estudio de campo fue realizado en tres organizaciones usando prcticas JAD para
determinar cmo resulta un sistema de desarrollo influenciado por JAD. El
resultado del estudio sugiere que las organizaciones lograron modestas mejoras
en los desarrollos de sistemas usando el mtodo JAD. El uso de JAD fue ms
efectivo en pequeos y claramente enfocados proyectos y menos efectivo en
proyectos largos y complejos

13 Tomado de: https://es.wikipedia.org/wiki/Joint_Application_Design

5.3.5. Prototipos
Los prototipos y los modelos son mecanismos excelentes para presentar ideas a
los usuarios porque ellos pueden ver inmediatamente algunos aspectos claves del
sistema. Mostrar los Prototipos puede provocar que el usuario brinde un mayor
nmero de requerimientos o cambie de idea acerca de los requerimientos
existentes depurndolos.

Los prototipos tambin pueden ilustrar como la solucin podra funcionar o

dar a los usuarios un vistazo de lo que podran hacer con el sistema. Muchos ms
requerimientos salen a la vista cuando el usuario puede comprobar los que estn
proponiendo.

Una presentacin puede incluir un grupo de diapositivas, un concepto elaborado

por un artista o un diseador, una representacin o una animacin que
brinde a los usuarios una visin de las posibilidades del sistema.
Cuando se creen prototipos de software se puede hacer una maqueta
compuesta por pantallazos enfatizando que no existe cdigo asociado y que el
sistema an no ha sido especificado, diseado o desarrollado.
Estos prototipos tienen como objetivo fomentar que los usuarios
mencionen requerimientos que faltan, no se supone que se est vendiendo una
idea o un producto. Es decir, se debe centrar la presentacin en determinar lo
que realmente se requiere del sistema.
Ver un prototipo que, invariablemente tiene problemas, en algn sentido
puede ser un estmulo para que los usuarios comiencen a decir lo que
necesitan. Si ellos expresan demasiados problemas con el prototipo es seal de
que se est logrando el cometido ya que cada problema puede
conducir a un nuevo requerimiento

Despus de tener consolidados los requerimientos del sistema se debe proceder

a comunicarle al personal de desarrolladores para darles a entender cules son
las necesidades del cliente, adems se pueden utilizar diferentes medios para
lograr este objetivo; uno podra ser el documento IEEE-830. 14

14 Tomado de: http://levantamientoderequerimientos.blogspot.com.co/

El rol clave de los requerimientos es mostrar a los desarrolladores y usuarios que
se necesita de un sistema, proveer los requerimientos forma parte de un lenguaje
que todos comprenden, ya que todos estn involucrados, incluyendo los clientes.

De los problemas ms comunes en el levantamiento de requerimientos se tienen:

No son siempre obvios y tienen muchas fuentes.

No son siempre fciles de expresar en palabras.
Hay muchos tipos diferentes a distintos niveles de detalle.
El nmero puede llegar a ser inmanejable.
Estn relacionados a otros en una variedad de formas.
Hay muchos interesados y partes responsables.

Los altos costos por culpa de los errores en los requerimientos son

Costos de reparar errores en los requerimientos superan en ms de 10 veces a

otros errores.
Errores de requerimientos comprenden encima del 40% de todos los errores de
un proyecto de software.
Pequeas reducciones en el nmero de errores de requerimientos rinden
grandes dividendos al evitar costos de re-trabajo y das de retraso.

5.4 Pruebas de Software

En el desarrollo del presente proyecto, se aplicarn las siguientes pruebas de
software:

5.4.1 Pruebas de usabilidad

Es la medida de la facilidad de uso de un producto o servicio, tpicamente una
aplicacin de software y hardware. Se encarga de todo lo que influya en el xito y
la satisfaccin del usuario.

En el proyecto se elabora con mdulos que sea intuitivos fcil de explicarle a la

dra Joyce Almeida y a los pacientes que ingresa al sistema, se va hacer fcil de
usar que no tenga grado de dificultad para ingresar y manejar el sistema la dra
Joyce Almeida. Se har prueba para saber si al entrar al sistema los mdulos
presenta algn problema digitando y guardando informacin de los pacientes que
se ingresa al sistema.
6. Cronograma
7. Presupuesto
8. BIBLIOGRAFA
Apache Foundation (2003).Apache HTTP Server Version 2.0 Documentation.
http://httpd.apache.org/docs-2.0/: Apache Foundation.

Bequet, H. (2001). Professional Java SOAP.WroxPress. Java Server

Pages.OReilly.

Bowen, R.; Lopez Ridruejo, D.; Liska, A. (2002).Apache Administrators

Flanagan, D. (2001). JavaScript: The Definitive Guide. OReilly. Java in a Nutshell,

4th Edition.OReilly.

SENN, James A. (1992) Anlisis y Diseo de Sistemas de Informacin.

SegundaEdicin. Editorial McGrawHill.Mxico .

CRCAMO SEPLVEDA, Jos; Base de Datos Relacionales: Un enfoque prct ico

de diseo. Universidad Industrial de Santander. 1994

PRESSMAN, Roger S ; ingeniera del software. Un enfoque prctico. McGraw Hill

5ta edicin, Madrid Espaa 2002