PROPUESTA PROYECTO Yesid Jimenez David Sotelo Final

1
PROPUESTA DE DESARROLLO DE UNA APLICACIÓN MÓVIL PARA LA

VISUALIZACIÓN DE INFORMACIÓN DE LAS CITAS MÉDICAS DE UN
PACIENTE EN UNA EPS
David Sotelo Rosales

Cod: 66161040
Yesid Jiménez
Cod; 66161001
UNIVERSIDAD LIBRE SEDE BOSQUE POPULAR

FACULTAD DE INGENIERIA
INGENIERIA DE SISTEMAS
BOGOTA D.C
2018
t
2
TABLA DE CONTENIDO
Contenido
1 AMBITO DEL PROYECTO ....................................................................... 5

1.1 PLANTEAMIENTO DEL PROBLEMA .............................................. 5
1.2 DESCRIPCION DEL PROBLEMA ..................................................... 5
1.3 REFERENCIAS CON SISTEMAS EXISTENTES ............................. 6
1.4 FORMULACIÓN DEL PROBLEMA .................................................. 6
2 OBJETIVOS ................................................................................................ 6
3 ALCANCE ................................................................................................... 7
4 FACTIBILIDAD.......................................................................................... 7
5 JUSTIFICACION ........................................................................................ 8
6 MARCO REFERENCIAL ........................................................................... 8
6.1 MARCO TEORICO .............................................................................. 8
6.2 MARCO CONCEPTUAL ................................................................... 14
6.3 MARCO LEGAL ................................................................................ 14
7 DISEÑO METODOLOGICO.................................................................... 17
7.1 HIPOTESIS ......................................................................................... 17
7.2 ETRATEGIA METODOLOGICA ..... Error! Bookmark not defined.
1 ANTECEDENTES .................................................................................... 19
2 MISION ..................................................................................................... 19
3 VISION ...................................................................................................... 20
4 OBJETIVOS DE LA EMPRESA Y DEL AREA ..................................... 20
5 OBJETIVO GENERAL ............................................................................. 20
6 OBJETIVOS ESPECIFICOS .................................................................... 20
7 ESTRUCTURA ORGANIZACIONAL .................................................... 21
8 DIAGRAMA FUNCIONAL O DE PROCESOS ...................................... 22
3
9 INFORMACION Y DIAGNOSTICO SITUACIONAL DE

INFORMATICA .............................................................................................. 23
1 FASE DE INICIO ...................................................................................... 24
1.1 ORGANIZACIÓN DEL EQUIPO DEL PROYECTO
(ESTRUCTURA DEL EQUIPO, ASIGNACION DE TAREAS) ............... 24
1.2 PLANIFICACION DEL PROYECTO ............................................... 25
1.3 GESTION DE RIESGO ...................................................................... 28
1.4 CRONOGRAMA DE DESARROLLO .............................................. 30
1.5 DETERMINACION DE REQUERIMIENTOS
(ESPECIOFICACIONES DEL SISTEMA) ................................................. 31
Definiciones, acrónimos y abreviaturas ........................................................ 31
Referencias .................................................................................................... 31
1.5.1 REQUETIMIENTOS FUNCIONALES ....................................... 35
1.5.2 REQUERIMEINTOS NO FUNCIONALES ................................ 38
1.5.3 MODELO DE REQUERIMIENTOS (REQUISITOS) DEL
SISTEMA 41
1.5.4 IDENTIFICASION DE ACTORES, CASOS DE USO Y
OBJETOS................................................................................................... 41
1.5.5 MODELO DE CASOS DE USO (DCU: ACTORES Y CU) ....... 49
2 FASE DE ELABORACION ...................................................................... 51
2.1 MODELO DEL NEGOCIO O AREAS .............................................. 51
2.2 Modelo de datos (Diagrama de clases, jerarquías, atributos y
operaciones) .................................................................................................. 52
2.3 Diccionario de clases ........................................................................... 56
2.4 Diagrama de Secuencia de información .............................................. 58
3 FASE DE CONSTRUCCIÓN ................................................................... 62
3.1 MODELO ENTIDAD RELACION .................................................... 62
3.2 modelo de funcional ............................................................................ 63
4
MODELO ARQUITECTURA CAPAS DE LA APLICACION ................. 64

3.3 MODELO DE INFRAESTRUCTURA .............................................. 66
3.4 DISEÑO DEL SISTEMA.................................................................... 67
3.4.1 DEFINICION DEL LENGUAJE DE PROGRAMACION .......... 67
4 CONCLUSIONES ..................................................................................... 67
5 RECOMENDACIONES ............................................................................ 68
5
I. ASPECTOS PRELIMINARES
Conformación del grupo de Trabajo
Nombre David Sotelo Rosales

Rol Coordinador del proyecto y Analista.
Nombre Yesid Jiménez

Rol Analista y Diseñador.
1 AMBITO DEL PROYECTO
1.1 PLANTEAMIENTO DEL PROBLEMA
En la actualidad el software utilizado por la entidad prestadora de servicio de

salud Medicol es bastante obsoleto a la hora de asignar citas médicas a los
usuarios de dicha entidad ya que los métodos tradicionales de esta entidad son vía
telefónica o presencialmente en sus oficinas, esto ha causado que los usuarios no
cuenten con un sistema efectivo y eficiente para la solicitud de información y
reservación de una cita médica generando congestión y malestar de los mismo ya
que diariamente en la entidad Medicol se solicitan 1001 citas diarias de las cuales
solo son asignadas 302 de manera efectiva.
1.2 DESCRIPCION DEL PROBLEMA
Los problemas identificados en la EPS Medicol son los siguientes:
1. Dificultad con la que un paciente puede pedir una cita médica ya sea general o
especializada principalmente la segunda. Es normal ver casos donde una cita
médica especializada puede durar hasta varios meses para poder ser asignada y
debido al largo tiempo de la asignación tiende a olvidarse y puede ser perdida.
1
Tomado de la información interna de Medicol
2
Tomado de la información interna de Medicol
6
2. Dificultad para transportarse a entidad prestadora de servicio Medicol para

solicitar una cita o para solicitar una cita vía telefónica, más que todo en los
adultos de la tercera edad suele ser un problema bastante común.
3. A la hora de pedir una cita médica vía telefónica el paciente puede durar hasta
horas esperando que le atiendan la llamada y cuando lo hacen muchas veces ni
encuentran disponibilidad para asignar la cita médica.
1.3 REFERENCIAS CON SISTEMAS EXISTENTES
Se observa que otras entidades prestadoras de salud cuentan con problemas a la

hora de prestar el servicio de asignación de citas médicas y la información
correspondiente a esta ya que constantemente se ve la cogestión de pacientes en
las líneas telefónicas o en los centros de salud, tratando de lograr el agendamiento
de una cita médica donde muchas veces no se logra concretar y otras veces si se
logra agendar estas suelen ser para periodos de tiempo bastante amplios.
Un sistema de información por medio de una aplicación móvil es capaz de

optimizar estos procesos de las entidades prestadoras de salud ya que los usuarios
solo tendrían que contar con un dispositivo móvil y acceso a internet para poder
hacer esta petición además que se le podría notificar al paciente que tiene la cita
médica unas horas antes para que esta pueda estar presente en el paciente y así
evitar el olvido y la perdida de estas citas médicas.
1.4 FORMULACIÓN DEL PROBLEMA
¿Se puede Mediante una arquitectura de software mejorar la congestión a la hora

de agendar citas médicas en el centro de salud Médicol para así tener acceso a la
información de las mismas en cualquier momento y lugar?
2 OBJETIVOS
OBJETIVO GENERAL
Proponer una arquitectura de software por medio de una app móvil que permita hacer
un agendamiento de citas médicas en el área de medicina general, optometría,
odontología, buscando así tener acceso de manera rápida y efectiva a las citas médicas
disponibles desde cualquier momento y lugar.
7
OBJETIVOS ESPECIFICOS
 Realizar el análisis de requerimientos para establecer los alcances y

limitaciones del Sistema de Información.
 Seleccionar un modelo de Ingeniería de Software que esté acorde a los
estándares de la arquitectura de un Sistema.
 Proyectar el diseño de la arquitectura de un Sistema de Información móvil,
acorde con las necesidades y exigencias requeridas para el sistema.
 Realizar una fase de implementación y pruebas, para validar y verificar el
correcto funcionamiento del Sistema.
3 ALCANCE
La propuesta de desarrollo de una aplicación móvil está orientada a dispositivos

móviles con determinadas especificaciones, una aplicación diseñada para que los
usuarios de esta entidad tengan la posibilidad de solicitar, consultar y cancelar sus
citas médicas.
La aplicación ofrecería el beneficio y la comodidad de que los usuarios desde
cualquier lugar y hora puedan con tan solo unos pasos sencillos agendar su cita
médica de la manera en que más les convenga a estos pacientes.
Los usuarios tienen la capacidad de consultar sus citas asignadas solo con entrar a la
aplicación y poner su documento de identidad y si desea cancelar la cita médica lo
puede hacer, pero con mínimo 5 horas de anterioridad para que esa cita pueda ser
asignada a otro paciente y así logra una mejor optimización.
4 FACTIBILIDAD
Económico: debemos tener en cuenta que el sistema debe ser robusto para así poder
brindar la información de manera eficiente, por esta razón debemos tener en cuenta
su relación con los diferentes sistemas a los cuales debe adaptarse de manera correcta
para su efectivo funcionamiento.
Técnica: el proyecto está basado en un sistema de información, el cual debe dar

respuesta de manera inmediata al usuario permitiéndole así tener acceso a la
información de manera instantánea y este debe cumplir con los requerimientos para
así evitar fallos a la hora de realizar un agendamiento de citas.
8
Operativa: debemos tener en cuenta que se debe contar con los procesos y modelos
para así optimizar el uso de la arquitectura para brindar una información de calidad y
esta debe tener un tiempo de respuesta muy corta.
5 JUSTIFICACION
Justificación tecnológica
El proyecto está pensado para dar la solución TIC a un problema común en todas las
entidades prestadoras de salud ya que se propone el diseño de una aplicación móvil
capaz de suplir etas necesidades tanto de los usuarios de la entidad como la de los que
laboran en ella ya que reduciría costos en nómina y carga laboral.
Esta flexibilidad será cada vez mas importante en el sector de la tecnología ya que
cada vez se están implementando soluciones tecnológicas que resuelvan cualquier
problema de administración y optimización que pueda tener estas entidades.
Justificación social
Las situaciones actuales de la sociedad en general obligan a estas entidades a

desarrollar métodos que puedan mejorar la calidad de vida de las personas, Con este
proyecto se lograra mejorar considerablemente estos aspectos ya que los usuarios no
tendrán que esperar infinidad de tiempo en las líneas telefónicas o hacer colas también
bastante demoradas para lograr el agendamiento de una cita médica.
6 MARCO REFERENCIAL
6.1 MARCO TEORICO
Ley 100 (1.993) 3 el cual es el directo mercado en el que se hará uso del software
“Diseño e Implementación de un sistema de Información para la Asignación de Citas
de Consulta Externa en las áreas de Medicina General, Optometría, odontología” por
la cual se crea el Sistema de Seguridad Social Integral y se dictan otras disposiciones.
3
Reglamentan la prestación del Servicio de Salud Ley 100
9
Art. 155. la Ley 1004 se refiere a los Integrantes del Sistema General de Seguridad
Social en Salud, particularmente en su Numeral 3 describe los Administradores a los
que va dirigido éste sistema así: “Las Instituciones Prestadoras de Servicios de Salud,
públicas, mixtas o privadas”,
siendo ésas últimas, las Instituciones Prestadoras de Servicios de Salud de carácter

privado aquellas a las que se les direcciona el uso del Software de Información para
la Asignación de Citas de Consulta Externa.
Art.156 Ley 1005 En relación a los Usuarios directos del Sistema de Información para
la Asignación de Citas de Consulta Externa en las áreas de Medicina General,
Odontología y optometría, como se elige de lo que se dijo anteriormente, son aquellos
que se encuentren adscritos a la respectiva Entidad Privada prestadora de Servicios
de Salud, sin embargo en el evento en que ésta Institución estuviese prestando
servicios al Estado con ocasión a una relación de índole actual tenemos que podría
tratarse de un Usuario Vinculado al Sistema.
En relación con la necesidad de utilización de un Sistema Eficiente de Asignación de

citas nos permitimos referirnos al contenido del Art. 153 Numeral 9 en lo relacionado
con la Calidad de los servicios de salud, encontrando que entre otros aspectos el
Sistema debe: “Garantizar a los usuarios calidad en la atención oportuna,
personalizada, humanizada, integral, continua y de acuerdo con estándares aceptados
en procedimientos y práctica profesional”, visualizando así como el entre el efectivo
uso de Software objeto de éste estudio y los fundamentos del sistema de Salud
Colombiano existe una directa corresponsabilidad en razón a su objetivo. 6 Se define
como aquello que sirve como medio para definir los requerimientos de los usuarios y
4
5
6
Tomado de “Estrategia de Desarrollo por Prototipos”, 2012, disponible en
http://www.ub.edu.ar/catedras/ingenieria/ing_software/ubftecwwwdfd/mids_web/prototyp/estrdes.htm
10
verificar la factibilidad del diseño del sistema. Básicamente, las razones para emplear
la arquitectura son:
 Aumentar la productividad
 Fácilmente ampliable y modificable.
 Muestra su interfaz y las funcionalidades de entrada-salida más relevantes.
 Redesarrollo planificado
 Entusiasmo de los usuarios respecto a los prototipos
 Aclarar requerimientos de los usuarios.
 Verificar la factibilidad del diseño de un sistema.
 Probar varias suposiciones formuladas por analistas y usuarios.
Adicionalmente, un sistema se caracteriza porque:
 No contienen todas las características o lleva a cabo la totalidad de las funciones
necesarias del sistema final.
Incluye elementos suficientes para permitir dar una idea del funcionamiento y
determinar básicamente las modificaciones necesarias. Por lo tanto, elaborar un
prototipo implica en la elaborar un modelo del sistema, o una parte de él, que se
construye. Tiene como objetivo evaluar mejor los requisitos.
7
Se reglamenta la prestación de servicios de salud y procedimientos quirúrgicos,
donde se establecen entre otros los fundamentos de Equidad, Obligatoriedad,
Protección Integral, Libre Escogencia, Autonomía, Participación, Descentralización,
etc., como factores esenciales de la prestación del Servicio de Salud.
7
11
6.1.1 Arquitectura de Aplicaciones móviles8
Para las aplicaciones móviles, se cuenta básicamente con tres elementos:

 Aplicación central: Almacena los datos enviados por el dispositivo móvil.
 Proceso de sincronización: Consiste en mantener integridad y consistencia de los
datos en las aplicaciones, de manera tal que al enviar algún dato desde el dispositivo,
se valida y se guía hasta la aplicación central, retornando una respuesta. Cabe anotar,
que este proceso puede ser un programa independiente o un módulo o componente de
la aplicación central.
 Aplicación en el dispositivo móvil: Recolecta y envía datos hacia la aplicación
central; en algunos casos, no existirá el proceso de sincronización, por lo que el
dispositivo interpretará formularios por medio de un navegador Web o programa
similar, ubicados en la aplicación central.
6.1.2 Servidor Web9
Definido como una tecnología que contiene programas procesadores de aplicaciones,

los cuales establecen conexión con clientes, cediendo respuestas en determinado
lenguaje o aplicación de estos, lo cual para este caso, funcionan como intermediario
entre la aplicación móvil y la aplicación central. Entre los servidores web más
conocidos, se encuentran:
 Apache Server10: De distribución libre y código abierto, ejecutable en múltiples
sistemas operativos como Windows, Novell, NetWare, Mac OS X, y la familia Unix.
Entre los lenguajes que soporta, se encuentra PHP,
6.1.3 LENGUAJE DE PROGRAMACION
Definido como un conjunto de reglas semánticas y sintaxis que definen los programas
del computador, el cual le entrega instrucciones y, en este caso, parte del proceso de
sincronización. Entre los lenguajes más conocidos, se encuentran:
 Java1811: Tecnología que permite el uso de programas punteros, como juegos,
herramientas y aplicaciones de negocios.
8
Tomado de “COMPUTACIÓN MÓVIL, Principios y técnicas”, Autor: Víctor Viera Balanta, Año de
publicación: 2010, disponible en http://www.acis.org.co/archivosAcis/ComputacionMovilTEcnicasy
Principios.pdf
9
Tomado de Ecured, 2004, disponible en http://www.ecured.cu/index.php/Servidores_Web
10
Tomado de “Definición de Apache”, 2012, disponible en http://www.alegsa.com.ar/Dic/apache.php
11
Tomado de “¿Qué es Java?”, 2012, disponible en http://www.java.com/es/download/faq/whatis_java.xml
12
PHP12: Lenguaje de scripting ampliamente utilizado para diversos propósitos,

adecuado especialmente para desarrollo web y puede ser integrado en páginas HTML.
6.1.4 BASE DE DATOS
Conjunto de información con logística y estructura operacional definida por una

organización, un esquema de consulta y manipulación, y un conjunto de parámetros
que definen y condicionan su seguridad.
 MySQL13: Proporciona un servidor de base de datos SQL, de manera veloz, multi-
hilo, multiusuario y robusto.
PostgreSQL14: Sistema de base de datos relacional de código abierto; puede correr en
sistemas operativos como Linux, UNIX, y Windows.
6.1.5 SISTEMAS OPERATIVOS
Encargado de controlar y coordinar el uso del hardware entre programas de

aplicación y usuarios; en cuanto a dispositivos móviles, se destacan los sistemas
operativos:
 Symbian OS15: Basado en ROM, permite el diseño de aplicaciones multiplataforma.
La mayoría de los componentes están diseñados en C++.
 Android16: Combina el poder de Google y la web, incluye navegadores veloces,
nube de sincronización, multi-tareas, conexión fácil y aplicaciones de dicha página.
 Linux17: Compatible Unix. Se caracteriza por ser un sistema operativo libre e
incluye su código fuente.
12
1 Tomado de “What is PHP?”, 2012, disponible en: http://www.php.net/
13
Tomado de “Definición MySql”, 2012, disponible en http://www.mastermagazine.info/termino/6051.php
14
Tomado de “PostgreSQL”, 2012, disponible en http://www.postgresql.org/about/
15
Tomado de “Introducción a Symbian”, 2012, disponible en http://www.todosymbian.com/secart29.html
16
Tomado de “Android - About”, 2012, disponible en http://www.android.com/about/
17
Tomado de “Sobre Linux”, 2012, disponible en http://www.linux-es.org/sobre_linux
13
 Windows Mobile18: Diseñado para dispositivos móviles y teléfonos inteligentes

(Smartphone). Está basado en el núcleo del sistema operativo Windows CE.
6.1.6 INGENERIA DE SOTFWARE
Aplicación del método científico a la teorización y creación de conocimiento sobre la

propia Ingeniería de Software, dedicándose al estudio de sus actividades y
pretendiendo generar teorías, modelos explicativos o enunciados descriptivos sobre
la práctica de la ingeniería.
6.1.6.1 Diseño en la Ingeniería de Software
19
Proceso para definir la arquitectura, los componentes, los interfaces, y otras
características de un sistema o u componente. También como el resultado de
este proceso. En la fase de diseño, tomando como punto de partida los
requisitos (funcionales y no funcionales), se pretende obtener una descripción
de la mejor “solución software/hardware que dé soporte a dichos requisitos,
teniendo no solamente en cuenta aspectos técnicos, sino también aspectos de
calidad, cose y plazos de desarrollo. Idealmente, se deberían plantear varios
diseños alternativos que cumplan con los requisitos, para posteriormente
hacer una elección de acuerdo a criterios de coste, esfuerzo de desarrollo o de
calidad tales como la facilidad de mantenimiento. Es importante resaltar que
en esta fase de pasa del qué (obtenido en la fase de requisitos) al cómo (que
es el objetivo de la fase de diseño). Ahora bien, el diseño debe ser evaluado
para medir algunos criterios de calidad y comparar alternativas, los cuales son:
 Extensibilidad: Se refiere a la posibilidad de adicionar nuevas
funcionalidades sin requerir cambios significativos en la arquitectura.
 Solidez: Se refiere a la posibilidad de operar bajo presión y la capacidad de
tolerancia de entradas inválidas o inesperadas.
 Fiabilidad: Se refiere a la posibilidad que tiene una función de ser llevada
a cabo en las condiciones deseadas durante determinado tiempo.
18
Tomado de “Windows Phone - Descubrir”, 2012, disponible en
http://www.microsoft.com/windowsphone/eses/default.aspx
19
http://www.ub.edu.ar/catedras/ingenieria/ing_software/ubftecwwwdfd/calidadsw/criterios.htm
14
 Tolerancia a fallos: Se refiere a la posibilidad del sistema de ser robusto y

capaz de recuperarse antes eventos de fallos.
 Compatibilidad: Se refiere a la capacidad de operar con otros sistemas.
 Reusabilidad: Se refiere a la posibilidad de que los componentes capturen
la funcionalidad esperada, con el fin de que se pueda utilizar en otros diseños
con iguales necesidades.
6.2 MARCO CONCEPTUAL
Para tener un entendimiento del alcance de este proyecto es necesario tener una
claridad de las siguientes definiciones:
 Centro medico: Infraestructura donde se atienden sanitariamente a los
pacientes. Lo habitual es que un centro medico cuente con la labor de
médicos clínicos, pediatras, enfermeros y personal administrativo.
 Cita médica: Acuerdo del lugar y tiempo entre el paciente y el centro de
salud, en que se dará asistencia en determinada consulta.
 Odontología: Rama de la salud que se encarga del diagnóstico,
tratamiento y prevención de las enfermedades del aparato
estomatognatico, el cual incluye los dientes, las encías, los maxilares,
entre otros.
 Optometría: Es la rama de la salud encargada del cuidado primario de los
ojos, a través de acciones de prevención, diagnóstico, tratamiento y
corrección de defectos refractivos, acomodativos etc.
 Paciente: Persona que solicita cita médica a una EPS y que es atendida por
un profesional de la salud.
 Aplicación móvil: Programa que se descarga e instala en un dispositivo
móvil de un usuario y es desarrollada para efectuar un conjunto de tareas
de cualquier tipo, facilitando gestiones o actividades.
6.3 MARCO LEGAL
 DECRETO 299 DE 1966: Por el cual se reglamentan actividades relacionadas con

la Salubridad Pública.20
20
Disponible en la página web: http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=2915 36
15
 Ley 35 de 1989: “Sobre Ética del Odontólogo Colombiano”.21
6.3.1 NORMATIVA DE PROTECCIÓN DE DATOS PERSONALES
En Colombia rige la Ley Estatutaria 1581 de 2012, para los temas y disposiciones
generales de protección de datos personales. La Ley de Protección de Datos abarca el
derecho que tienen los ciudadanos a conocer, actualizar y rectificar información
recopilada sobre ellos en bases de datos o archivos registrados por entidades públicas
o privadas. Es necesario recalcar que su cobertura se limita al estado colombiano o
territorios extranjeros siempre y 33 cuando se posean acuerdos o tratados de carácter
internacional que dictaminen su validez; sin embargo, no aplicará principalmente en:
bases de datos o archivos usados en un ámbito personal o doméstico, bases de datos
con información periodística y bases de datos para asuntos de seguridad y cuando se
posean acuerdos o tratados de carácter internacional que dictaminen su validez; sin
embargo, no aplicará principalmente en: bases de datos o archivos usados en un
ámbito personal o doméstico, bases de datos con información periodística y bases de
datos para asuntos de seguridad y defensa22
6.3.2 NORMATIVA DE COMERCIO ELECTRÓNICO
Para poder entender correctamente la ley 527/99 es necesario entender a qué hacen
referencia los términos mensaje de datos y comercio electrónico, por tanto, a
continuación, se definen: Mensaje de datos, es toda información tratada por medios
electrónicos, contempla labores como el envío, recepción, transmisión,
almacenamiento, etc. Al ser por medios electrónicos abarca las comunicaciones del
tipo correo electrónico, ópticos, telefax y todo tipo de comunicaciones que puedan
relacionarse por su naturaleza electrónica. Comercio electrónico, es toda relación
comercial, contractual o no, donde se evidencie algún tipo de suministro o
intercambio de bienes y servicios a partir del empleo de mensajes de datos.23
21
Disponible en la página web:
https://www.minsalud.gov.co/salud/Documents/Observatorio%20Talento%20Humano%20en%20Sa
lud/Odontolog%C3%ADaDecreto%20terminado%20Abril%2017%20de%202013%20para%20entre gar.pdf
22
Disponible en:
https://repository.usta.edu.co/bitstream/handle/11634/4131/Rodr%C3%ADguezjuan2017.pdf?sequence=1
23
Disponible en:
16
6.3.3 NORMATIVA DE CONSUMO
LEY 1480 DE 2011, ESTATUTO DEL CONSUMIDOR Considerar esta normativa

dentro de las importantes a la hora de crear y gestionar aplicaciones móviles se debe
a que todo usuario de plataformas tecnológicas tiene derechos como consumidor, por
tanto, se debe tener en cuenta que hay una serie de pautas que los desarrolladores y
publicadores deben respetar como lo son: brindar información clara que permita
elegir los servicios que se desean adquirir, proteger a los infantes según los aspectos
plasmados en el código de infancia y adolescencia dado que un dispositivo móvil es
objeto de uso tanto por adultos como niños, entre otras consideraciones importantes
que no se deben pasar por alto. Sabiendo esto, es oportuno hacer referencia a los
principales derechos y deberes que la norma establece para consumidores y
usuarios.24
6.3.4 CONSIDERACIONES BASICAS DEL TRATAMIENTO DE LOS

DATOS PERSONALES
Cuando se hace referencia al tratamiento de datos, se habla de aquellas operaciones

aplicables a datos personales, por ejemplo: su recolección, almacenamiento, uso,
circulación o supresión. Para ello, es necesario tener en cuenta que todo tratamiento
de datos debe realizarse legítimamente, con el consentimiento previo del titular, por
tanto, la información debe ser verídica, exacta, comprobable y comprensible.
Igualmente, el titular de los datos puede solicitar en cualquier momento que
información se tiene sobre él, ya sea del responsable del tratamiento (quien decida
sobre la base de datos) o del encargado (persona quien realiza tratamiento de datos
personales por cuenta del responsable). Así mismo, es necesario resaltar que todo
dato personal, salvo que constituya información pública, no puede estar publicado en
medios de comunicación o divulgación masivos. Más aún, el responsable o encargado
del tratamiento de información debe asegurar por todos los medios seguridad de la
información a fin de evitar adulteración, perdida, consulta, accesos no autorizados o
fraudulentos a ella25
24 24
Disponible en:
25
Disponible en:
17
6.3.5 INFORMACION AL USUARIO
Una gran parte de las aplicaciones móviles pueden ser consideradas como “servicios
de la sociedad de la información”, aunque solamente sea por la publicidad que
contienen. Por eso es que hay que cumplir con las obligaciones que la legislación
implica para estos servicios. La principal obligación más fácil de cumplir en este
sentido sea la de informar a los usuarios de los aspectos marcados por la ley, lo que
puede hacerse a través de textos de las condiciones legales, o en secciones
comúnmente denominadas “acerca de” o “quiénes somos”.26
7 DISEÑO METODOLOGICO
7.1 HIPOTESIS
Si se diseña esta aplicación móvil para la generación de citas médicas acorde a

las necesidades de la EPS esta podrá disminuir considerablemente la congestión
de los usuarios en esta entidad que se presentan exclusivamente a solicitar una
cita médica, así como la congestión en las líneas telefónicas dando una mejor
calidad de vida a los pacientes de esa EPS y de la misma manera disminuyendo
costos administrativos de la entidad.
Esto también disminuirá considerablemente las citas médicas que se pierden por
inasistencia del paciente ya que se podrá cancelar y asignará a otro que la necesite
en este momento.
7.2 ESTRATEGIA METODOLOGICA
La metodología requerida para este proyecto tiene un enfoque analítico

descriptiva ya que con la información recogida de los estudios se trata de resolver
un problema planteado, la creación de y el uso de una aplicación web como
sistema de información para la asignación de citas médicas en el área general.
Así de esta manera esta metodología utiliza una serie de instrumentos
metodológicos que son relevantes para obtener y comprobar los datos
considerados pertinentes a los objetivos de la investigación.
26
Disponible en https://www.yeeply.com/blog/decalogo-de-buenas-practicas-aspectos-legales-de-las-
aplicaciones-moviles/
18
Exige que se compruebe y de igual forma se verifique el hecho o fenómeno que

se estudia mediante la confrontación empírica, esto ayuda a plantear soluciones
mediante la indagación o búsqueda a situaciones o casos particulares.
Para llevar a cabo la propuesta de diseño de esta aplicación móvil llevaremos a

cabo los siguientes pasos:
1. Identificar las necesidades a la que están expuestas las personas con el

sistema de salud actual.
2. Definir tecnologías y componentes idóneos para asegurar la factibilidad
3. Identificar los métodos convencionales para el control que se lleva sobre las
citas médicas de un paciente. Adicionalmente, se requiere un estudio sobre el
funcionamiento de cada una de las metodologías encontradas.
4. consolidar la información en una base de datos.
a) Identificar parámetros relevantes de una historia clínica.
b) Creación de la base de datos con los campos necesarios a la hora de generar
un diagnóstico clínico.
c) Validación con un profesional en la materia, con el fin de realizar ajustes
pertinentes de la base de datos
5. Toda la información almacenada, debe ser visualizada en una interfaz que
posibilite la lectura de los datos y manipulación de ella.
a) Definir el lenguaje de programación en el cual se va implementar la

interfaz.
b) Delimitar los datos que se van a presentarse en dicha interfaz.
6. Realizar pruebas en pacientes reales para identificar la factibilidad del

prototipo final.
7. Implementación de prototipo final.
19
II. DEFINICIÓN DE LA ORGANIZACIÓN OBJETO DEL

TRABAJO
1 ANTECEDENTES
1991: Medicol nace como empresa de Medicina Prepagada en Bogotá.
1991 - 1994: Se abrieron sedes en Barranquilla, Medellín, Cali, Pereira e Ibagué.
1994: En Diciembre Medicol es autorizada para funcionar como Entidad Promotora de

Salud (EPS).
1996: Se autoriza a Medicol para que opere como Administradora de Régimen

Subsidiado (ARS).
1997 - Hasta la actualidad: Hasta abril de 1997 se ofrecieron los servicios de medicina
prepagada. Desde entonces Medicol se ha dedicado exclusivamente a la prestación del
Plan Obligatorio de Salud (POS).
Se abren sedes en el resto del país, teniendo además presencia hoy en: Cartagena,
Bucaramanga, Valledupar, Santa Marta, Villavicencio, Montería, Girardot, Sincelejo y
Palmira.
2 MISION
En Medicol promovemos la afiliación al sistema de salud y gestionamos los riesgos

de nuestros protegidos mediante la promoción, prevención, recuperación de la salud
y la prestación de servicios integrales con calidad. Contribuyendo de esta manera al
bienestar y desarrollo del país, generando sostenibilidad empresarial.
20
3 VISION
En el 2020 seremos reconocidos por la alta satisfacción de nuestros protegidos, por

la excelencia en la gestión del riesgo y por la cultura de servicio
humanizado y seguro.
4 OBJETIVOS DE LA EMPRESA Y DEL AREA
5 OBJETIVO GENERAL
Garantizar la atención en salud de calidad de todos nuestro cotizantes siempre

manteniendo la salubridad establecida por diferentes entidades reguladoras del
estado y ofreciendo a los mejores profesionales de la salud.
6 OBJETIVOS ESPECIFICOS
 Afectar positivamente a la sociedad civil en el ámbito de la salubridad.

 Beneficiar a la población en condiciones de vulnerabilidad de nuestro
país, a través de programas de asistencia básica en salud.
 Generar un proceso de acompañamiento a las comunidades beneficiadas
con los programas que se lleven a cabo.
 Liderar las prácticas de Responsabilidad Social Empresarial en los
campos social y medioambiental.
 Intervenir positivamente con nuestras acciones en los procesos de paz
que se desarrollan en Colombia
21
7 ESTRUCTURA ORGANIZACIONAL
A continuación, se muestra una imagen con la estructura organizacional de la eps

Medicol
Figura 1 organigrama de la EPS Medicol

22
8 DIAGRAMA FUNCIONAL O DE PROCESOS

A continuación, se muestra el diagrama funcional o de procesos de la EPS Medicol:
Figura 2 diagrama funcional o de procesos

23
9 INFORMACION Y DIAGNOSTICO SITUACIONAL DE

INFORMATICA
En cuanto al diagnóstico situacional de informática la EPS cuenta con un área TI

donde se encarga de dar diferentes soluciones a los problemas de la entidad. Pero
esta EPS no cuenta con un sistema de información de agendamiento de citas
médicas por una aplicación móvil ya que el área TI no ha podido implementar este
sistema por falta de desarrolladores de software.
Por consiguiente, la empresa destinara unos recursos a este proyecto para poder
cumplir los objetivos que se plantea y que la visión de la misma sea todo un éxito.
24
III. PROCESO INGENIERIL DEL PROYECTO
1 FASE DE INICIO
1.1 ORGANIZACIÓN DEL EQUIPO DEL PROYECTO (ESTRUCTURA

DEL EQUIPO, ASIGNACION DE TAREAS)
ESTRUCTURA DEL EQUIPO

El principal activo de este proyecto será el personal, pues no necesita de la fabricación de
ninguna pieza sino solo el desarrollo del software por lo cual se requerirá de tres ingenieros.
Dos ingenieros de software con orientación a los dispositivos móviles y un ingeniero en
sistemas computacionales con un posgrado en redes.
Estos tres ingenieros conformaran un nuevo departamento en TI servicios móviles. El
ingeniero en sistemas Computacionales con posgrado en redes seria el director del
departamento y los ingenieros en software con orientación a dispositivos móviles serian
subalternos de este. El organigrama será:
25
1.2 PLANIFICACION DEL PROYECTO
MEJORAMIENTO DE LA CALIDA DE SERVICIO DE LA EPS

MEDICOL
Este proyecto inicialmente se realizará en una entidad prestadora de

servicio llamada Medicol la cual se encuentra ubicado en el sector de
chapinero en la dirección calle 59 # 15 -36.
DEPENDENICA RESPONSABLE
Empresa responsable Medicol.
RESPONSABLES DEL PROYECTO
 Ingeniero desarrollador Yesid Jiménez

 Ingeniero desarrollador y director de proyecto David Sotelo
 Ingeniero desarrollador: Aun no contratado.
DURACION DEL PROYECTO

140 días calendario
Inicio: 25 de julio de 2018
Finalización: 25 de noviembre del 2018
DEFINICION DEL PROYECTO
Para cumplir con los objetivos.
 Identificar las necesidades a la que están expuestas las personas con
el sistema de salud actual.
 Creación de una base de datos con los campos necesarios a la hora de
generar un diagnóstico clínico.
 Validación con un profesional en la materia, con el fin de realizar
ajustes pertinentes de la base de datos.
 Definir el lenguaje de programación en el cual se va a implementar la
interfaz.
 Delimitar datos que se presentaran en dicha interfaz.
 Realizar pruebas reales en pacientes reales para identificar la
factibilidad del prototipo final.
A continuación, se muestra un diagrama general del prototipo inicial del proyecto:
26
METODOLOGIA DE EVALUACION Y CONTROL DE CALIDAD:
Evaluación anual de los siguientes aspectos:

 Evaluación del sistema en general. Comprenderá la evaluación del impacto, uso y
relevancia de la aplicación móvil por parte de los pacientes de la EPS.
 Evaluación del proyecto. Comprenderá la evaluación del logro de los objetivos
trazados durante la implementación del proyecto.
27
COSTOS DE PRODUCCION
A continuación, se presentara una tabla con los gastos necesarios para la implementación de
todo el proyecto en la EPS Medicol.
COSTOS DE PRODUCCION
COSTOS
COSTOS FIJOS $(PESOS) VARIABLES $(PESOS)
$
Salarios 10.926.583 Servidores 51.419.214
Servicio de luz Equipos de
eléctrica 1.606.850 oficina 5.061.579
Mantenimiento 321.370 Computadores 13.015.489

Licencia de Rack para
software 4.338.496 servidores 2.570.961
Equipos de
instalación 4.820.551
Aplicación Móvil 4.820.551
Promoción 7.230.827
TOTAL COSTOS $ TOTAL COSTOS
FIJOS 17.193.299 VARIABLES 88.939.172
$
COSTO TOAL DE PRODUCCION 106.132.471
Tabla 1
28
1.3 GESTION DE RIESGO
En la siguiente matriz se describe la gestión de riesgos de la EPS Medicol, en

esta matriz se muestran los datos recolectados para la toma de decisiones.
Categoría Probabilidad Impacto Estrategias

(riesgo)
Requerimientos 70% 4 Realizar entrevistas a los usuarios
de Médicol para la toma de
requerimientos fuente primaria
Agendamiento 10% 2 Satisfacer las necesidades de los

oportuno de citas usuarios brindándole la solución al
agendamiento de las citas medicas
Gestión 30% 3 Se deben tener en cuenta

planeación las fechas establecidas
para que estas sean
cumplidas a cabalidad
Presupuesto 15% 2 Se deben contar con los

recursos suficientes para
lograr los objetivos
Se tiene un dinero disponible por
si ocurre alguna inesperada
eventualidad
Impacto 30% 4 La arquitectura del sistema

debe soportar cualquier
tipo de entorno,
brindándole así al usuario
una mejor experiencia sin
contratiempos
29
Talento humano 18% 3 El personal debe estar muy bien

preparado para abordar alguna
situación inesperada
Diseño 50% 4 El diseño va ligado con el

cliente para que esté
familiarizado con el
entorno
Implementación 25% 2
Tener la documentación sobre la
plataforma, y brindar un soporte
cuando sea requerido
Interfaz 20% 5 La vista del cliente debe ser un

entorno sencillo, fácil de manejar,
con una buena presentación
Seguimiento 20% 5 Se hace un seguimiento a la

arquitectura y se hará el
mantenimiento correspondiente
Matriz 1 Gestion de riesgos

30
1.4 CRONOGRAMA DE DESARROLLO
En base el siguiente cronograma respetando las semanas y las fechas propuestas

estaremos realizando la implementación del proyecto:
Matriz 2 cronogramas desarrollo proyecto

31
1.5 DETERMINACION DE REQUERIMIENTOS (ESPECIFICACIONES

DEL SISTEMA)
Definiciones, acrónimos y abreviaturas

Nombre Descripción
RF Requerimiento Funcional
RNF Requerimiento No Funcional
Referencias
Título del Documento Referencia

Standard IEEE 830 - 1998 IEEE
Objetivos del negocio

En la siguiente tabla se muestran los objetivos del negocio ayudándonos así
mejorar la factibilidad de la eps medicol
Id Descripción del objetivo del negocio
Objetivo 1 Mejorar los tiempos de respuesta en
la asignación de las citas medicas
Objetivo 2 Recolectar información que nos
permite optimizar los tiempos de
atención a los usuarios de la eps
Objetivo 3 Proporcionar a los usuarios de la eps
mecanismos para que estas tengan
una óptima atención en el momento
de agendar una cita medica
Objetivo 4 Incrementar sistemas de información
para relacionar a los usuarios con el
sistema
32
Requerimientos del Sistema

En la siguiente table de muestran los requerimientos los cuales tienen su
relación con los objetivos del negocio
Id Descripción Prioridad Objetivos del
negocio
Requerimiento 1 El sistema debe Alta Objetivo 1
permitir realizar
una asignación
de una cita
medica
Requerimiento 2 Realizar la Alta Objetivo 2
asignación de
manera efectiva y
oportuna en
tiempos de
respuesta rápida
Requerimiento 3 Realizar Alta Objetivo 3
consultas de las
citas médicas que
se tienen
asignadas con su
respectiva
información
Requerimiento 4 La asignación de Alta Objetivo 3
las citas médicas
debe estar
disponible en
todos los
horarios
Requerimientos empresariales
Funcionales del negocio Funcionales primarios Funcionales

del usuario secundarios del usuario
Mejorar en un 50% los El sistema permite la Acceder al sistema
tiempos de respuesta en realización de Información de citas
medicas
33
la asignación de citas asignación de una cita Posibilidad de cancelar

médicas. médica. cita
Información del doctor
Lograr un incremento Optimización de los Acceder al sistema
en un 40% de usuarios tiempos de asignación Información de citas
inscritos en la eps de las citas medicas medicas
Posibilidad de cancelar
cita
Optimizar los recursos Solicitar cita médica Acceder al sistema
gastados por el personal por medio de una Información de citas
asignado citas medicas aplicación móvil. medicas
Posibilidad de cancelar
cita
Requerimientos atributos de calidad

Funcionalidad Completitud funcional La información sobre
las citas médicas debe
estar disponible a los
usuarios las 24 horas al
día
Funcionalidad Corrección funcional El sistema debe generar
a los usuarios un
reporte de las citas
médicas que tiene en un
futuro y las citas
médicas que se han
cancelado, así como las
inasistencias
Funcionalidad Pertinencia funcional Para tener acceso a las
citas médicas de
mamera oportuna de
necesita que el sistema
esté funcionando de
manera correcta
ofreciendo así un
34
servicio de calidad a la
hora de realizar la
agendacion de las citas
medicas
Funcionalidad Idoneidad funcional Tener la adecuación
pertinente para tener
una buena relación
entre el sistema y los
clientes
Requerimientos atributos de calidad

Desempeño Comportamiento El sistema debe estar en
temporal la capacidad de dar
respuesta rápida cuando
los usuarios realicen la
agendacion de las citas
médicas, el sistema
debe garantizar que el
98% de sus tareas
asignadas se cumplen
plenamente.
Desempeño Utilización de los De acuerdo con las
recursos estimaciones hechas
previamente, el sistema
cumple con las
necesidades de los
usuarios, sin tener
ningún problema con su
funcionalidad
Desempeño Capacidad El sistema está en la
capacidad de adecuarse
a los diferentes
entornos donde se
requiera, adicional a
este el sistema soporta
los pacientes que la eps
tenga y tiene una
35
adaptabilidad para
adición de estos
Compatibilidad Coexistencia El sistema maneja de
manera independiente
la base de datos de los
usuarios trabajando así
de manera óptima como
app y puede funcionar
con la página web de la
eps
Compatibilidad Interoperabilidad El sistema puede
funcionar
perfectamente sin
afectar a alguna otra
plataforma que maneje
la eps por su
independencia
1.5.1 REQUETIMIENTOS FUNCIONALES
La plataforma por desarrollar deberá cumplir los requerimientos indicados a continuación:

Identificación RF01
del
requerimiento:
Nombre del Ingresando a la Aplicación.
Requerimiento:
Características: Registrar usuarios
Descripción del Validar el usuario y contraseña, para permitir su acceso a la
requerimiento: aplicación.
Requerimiento  RNF01 - Interfaz
NO funcional:  RNF02 – leguaje de programación
 RNF03– bases de datos
 RNF04 - optimización
 RNF05 - Seguridad en información
 RNF06 - Mantenimiento
 RNF07 - Permisos de acceso
Prioridad del requerimiento: Alta
36
del
requerimiento:
Nombre del Agregando Doctor.
Requerimiento:
Características: Adiciona a la base de datos la
información de los doctores que
prestarán el servicio.
Descripción del Validar el doctor, para permitir su acceso a la asignación de la cita.
requerimiento:
del
requerimiento:
Nombre del Modificando doctor.
Requerimiento:
Características: Adiciona a la base de datos la
información de los doctores que
prestarán el servicio.
requerimiento:
37
del
requerimiento:
Nombre del Inhabilitando doctor.
Requerimiento:
Características: Cambia el estado del doctor de activo a inactivo para cancelar su
acceso al sistema.
requerimiento:
del
requerimiento:
Nombre del Consultando doctor.
Requerimiento:
Características: Verifica si el doctor está disponible
Descripción del Muestra toda la información del doctor almacenada en la base de
requerimiento: datos del sistema.
38
del
requerimiento:
Nombre del Registrando parametrización del
Requerimiento: sistema.
Características: Verifica la disponibilidad en el sistema
Descripción del Registra la información de las tablas de Tipo de servicio,
requerimiento: Procedimiento, días no hábiles.
del
requerimiento:
Nombre del Actualizando parametrización del sistema.
Requerimiento:
Características: Realizar las actualizaciones pertinentes
Descripción del Actualiza la información de las tablas de Estado, Tipo de servicio,
requerimiento: Sexo, Ciudad, Estrato, Tipo de documento, Cargo, Procedimiento,
Procedimiento_Mov, Festivos, Turnos, Especialidades.
 RNF04 – bases de datos
1.5.2 REQUERIMEINTOS NO FUNCIONALES

Los requerimientos no funcionales son visibles para los usuarios, pero no están
directamente implicados directamente, son importantes para el funcionamiento del sistema.
Identificación RNF01
del
requerimiento:
39
Nombre del Interfaz del sistema.

Requerimiento:
Características: El sistema presentara una interfaz de usuario sencilla para que sea
de fácil manejo a los usuarios del sistema.
Descripción del El sistema debe tener una interfaz de uso atractiva y amigable.
requerimiento: Debe ser fácil de usar, La interfaz del sistema deberá ser
implementada como una aplicación web basada en menús,
Ventanas, listas desplegables y botones de acción.
del
requerimiento:
Nombre del Lenguaje de programación
Requerimiento:
Características: El lenguaje debe ser implementado en java
Descripción del Es importante a la hora de especificar la operatividad para llegar al
requerimiento: desarrollo de la aplicación.
Prioridad del requerimiento: Medio
del
requerimiento:
Nombre del Bases de datos
Requerimiento:
Características: El Sistema funcionará bajo un entorno de la comunicación entre los
módulos del sistema se realizará mediante bases de datos y la
aplicación.
Descripción del La interfaz de usuario debe ajustarse a los módulos del sistema que
requerimiento: se realizará mediante bases de datos relacionadas.
del
requerimiento:
Nombre del Optimización
Requerimiento:
Características: El sistema deberá de tener una interfaz de los módulos, teniendo en
cuenta las características de la web de la empresa.
Descripción del La aplicación se visualizará por medio de una pantalla donde el
requerimiento: usuario tendrá a su disposición menús, botones, mensajes
informativos, mensajes de error, y formularios para el ingreso,
40
modificación, actualización y eliminación de datos para obtener

información de todo el sistema.
del
requerimiento:
Nombre del Seguridad en información
Requerimiento:
Características: El sistema garantizara a los usuarios una seguridad en cuanto a la
información que se procede en el sistema.
Descripción del Garantizar un sistema de identificación por medio de un usuario y
requerimiento: contraseña, como medida adicional se debe tener una jerarquía de
roles para que cada uno de los usuarios pueda tener acceso solo a
partes específicas del software.
del
requerimiento:
Nombre del Mantenimiento
Requerimiento:
Características: El sistema debe garantizar un mantenimiento óptimo.
Descripción del El sistema deberá ser diseñado para que su mantenimiento sea fácil,
requerimiento: y de esta manera pueda ser ampliado y corregido en caso de ser
necesario.
del
requerimiento:
Nombre del Permisos de acceso
Requerimiento:
Características: El sistema debe controlar permisos para cada usuario
Descripción del El sistema debe controlar los permisos que tiene cada usuario para
requerimiento: su accesibilidad de una manera correcta, de tal forma que pueda
acceder la información que le corresponde de acuerdo a su rol. Debe
tener controles adecuados para la validación de datos, de igual
manera la programación de las actividades específicas
41
1.5.3 MODELO DE REQUERIMIENTOS (REQUISITOS) DEL

SISTEMA
1.5.4 IDENTIFICASION DE ACTORES, CASOS DE USO Y

OBJETOS
Identificación de actores:
Los actores son las entidades externas del sistema que están involucrados con el
funcionamiento de este. Estimula el sistema con eventos de entrada o recibe algo de él. Los
actores están representados por el papel que desempeñan en el caso: Cliente, técnico u otro.
Los actores representan roles que interpretan personas, u otros sistemas cuando el sistema
está en uso.
Tipo de usuario Administrador

Formación IT en Informática
Actividades Control y manejo del sistema en general
Gestionar la información de los usuarios
Hacer copias de seguridad del sistema
Tipo de usuario Doctor

Formación Profesional de la salud
Tipo de usuario Usuarios de la eps

Formación Usuario
Casos de uso:
42
El caso de uso que describe la secuencia de eventos de un actor u agente externo

que utiliza un sistema para completar un proceso. Los casos de uso son historias
o casos de utilización de un sistema, sino que ejemplifican e incluyen tácticamente
los requerimientos en las historias que estos llevan a cabo.
Descripción caso de uso ingresar a la aplicación

En la siguiente tabla de describe el caso de uso del doctor ayudándonos a comperder mejor
el flujo que este realiza en la app
43
Descripción caso de uso agregando doctor

En la siguiente tabla de describe el caso de uso del doctor ayudándonos a comprender
mejor el flujo que se debe realizar para modificar el doctor en la plataforma
44
Descripción caso de uso agregando doctor

45
Descripción caso de uso inhabilitando doctor

46
Descripción caso de uso consultando doctor

47
48
Descripción caso de uso parametrización del sistema

49
1.5.5 MODELO DE CASOS DE USO (DCU: ACTORES Y CU)

Para el modelamiento de los casos de uso usamos starUml el cual nos permite tener mejor
un mejor entorno del modelamiento de los casos de uso
Estos casos de uso tienen el propósito de servir como una referencia rápida al lector de este
documento para entender la simbología utilizada en cada uno de estos diagramas. A
continuación, se anexan los diagramas de diseño de los casos de uso.
Caso de uso del doctor en el sistema
Caso de uso usuario en el sistema

50
Caso de uso usuario del sistema

51
2 FASE DE ELABORACION
2.1 MODELO DEL NEGOCIO O AREAS

Modelo de negocio de nuestra empresa es un modelo para la creación e
oportunidades a todo tipo de personas de la sociedad desde ingenieros
hasta técnicos y tecnólogos, La idea es la incorporación y creación de una
empresa que emplee personas de múltiples disciplinas para así apoyar al
empleo y promover el desarrollo profesional, Aquí radica el valor social
de nuestra empresa central que es promover el uso de tecnologías para
impulsar de manera positiva la industria de Colombia y ser pioneros en
nuevas tecnologías de tal forma que mantengamos un estándar de alta
calidad en nuestra area de trabajo professional.
Entregamos a la sociedad ingenieros y profesionales más capaces con
nuevas habilidades y valores éticos para la sociedad ofrecemos crecimiento
a nuevos jóvenes interesados en el área de tecnología, Ofrecemos auxilio y
ayuda a personas sin experiencia para darle el impulso inicial a los jóvenes
ingenieros, Este es el valor de nuestra empresa en el contexto social una
empresa que trata de darle prioridad a retribuir socialmente a los
ciudadanos
52
2.2 Modelo de datos (Diagrama de clases, jerarquías, atributos y operaciones)

Un modelo de datos es un lenguaje orientado a describir una Base de
Datos, combina las características del modelo de datos orientado a objetos
y el modelo de datos relacional. Típicamente un Modelo de Datos permite
describir:
Las estructuras de datos de la base: El tipo de los datos que hay en la base
y la forma en que se relacionan.
Las restricciones de integridad: Un conjunto de condiciones que deben

cumplir los datos para reflejar correctamente la realidad deseada.
Operaciones de manipulación de los datos: típicamente, operaciones de

agregado, borrado, modificación y recuperación de los datos de la base.
Otro enfoque es pensar que un modelo de datos permite describir los
elementos de la realidad que intervienen en un problema dado y la forma en
que se relacionan esos elementos entre sí.
53
Figura modelo de datos
Diagrama de Clases
Un diagrama de clases en UML es presentado aquí, para mostrar las clases de

diseño de software que colaboran en la realización del caso de uso. Este diagrama
muestra la especificación de las clases software que intervienen en este caso de
uso, presentando sus atributos, métodos, asociaciones, interfaces y operaciones,
navegabilidad y dependencias.
54
Figura diagrama de clases
Diagrama de jerarquía
Un diagrama de clases en UML es presentado aquí, para mostrar la jerarquía de

diseño de software que colaboran en la realización del caso de uso. Este diagrama
muestra la especificación de las clases software que intervienen en este caso de
uso, presentando sus atributos, métodos, asociaciones, interfaces y operaciones,
navegabilidad y dependencias.
55
56
2.3 Diccionario de clases
Esta sección presenta un listado organizado de todas las estructuras de

almacenamiento de la base de datos. Describiendo cada una de las tablas que la
componen y sus campos asociados. Adicionalmente, cada campo es identificado
por un nombre de dato, descripción, tipo de dato, longitud y el posible dominio de
valores que podrá tomar.
Agendiamiento de cityas medicas

Nombre de la tabla: agendamiento de citas
Función: realiza el agendamiento de citas médicas los usuarios de la eps medicol
Atributos Description Tipo Tam Tag Dependencies Óp Ejemplo
Cod Nombre del doctor VARCHAR 30 PK Doc
estupiñan
Desc Código del paciente INT 4 X 13
57
Diccionario de clases “CITA” Esta tabla contiene información de detalles de
las citas médicas odontológicas asignadas por el usuario con rol Paciente.
Diccionario de clases : “DISPONIBILIDAD_CITA” Esta tabla contiene

información de disponilidad de las citas médicas odontológicas habilitadas por
el usuario con rol Admin, para ser asignadas por el usuario con rol Paciente.
Diccionario de clases “HORARIO” Esta tabla contiene información

relacionada al horario (fecha y hora) de citas odontológicas.
58
2.4 Diagrama de Secuencia de información
Diagrama de secuencia Modulo ingresar a la aplicación

Verificación de usuarios
El siguiente diagrama de secuencia nos muestra como se debe ingresar a la
plataforma
59
Figura Diagrama de Secuencia

60
Cambio de contraseñas usuarios

El siguiente diagrama de secuencia nos muestra la validación por parte de
los usuarios de la eps medicol
Figura Diagrama de Secuencia Cambio contraseña de Usuarios

Consulta de disponibilidad de citas medicas
El siguiente diagrama de secuencia nos ayuda a entender la disponibilidad
de las citas medicas de la eps medicol
Figura Diagrama de Secuencia Eliminación de Usuarios

61
Diagrama de secuencia Inicio de Sesión
Figura Diagrama de Secuencia Inicio de sesión

Diagrama de secuencia agendamiento de citas medicas
Figura Diagrama de Secuencia agendamiento de citas

62
3 FASE DE CONSTRUCCIÓN
3.1 MODELO ENTIDAD RELACION
Es una herramienta para el modelado de datos que permite representar las entidades
relevantes de un sistema de información, así como sus interrelaciones y propiedades. esta
concepción fue diseñada por Peter chen.
Diagrama modelo entidad relación

63
3.2 modelo de funcional
(descomposición modular-modelo aplicación) (definición del módulos e identificación de

responsabilidades de c/u módulos)
A continuación, se especifica el modelo funcional.

64
MODELO ARQUITECTURA CAPAS DE LA APLICACION
El siguiente diagrama muestra las diferentes capas de la empresa de desarrollo de software

que se implementara en la EPS medicol para la asignación de citas médicas.
<<CAPA>> <<CAPA>
PRESENTA >
CION SERVICIO
S WEB
<<CAPA
>>
NEGOCI
O
<<CAP <<CAPA>
A>> >
DATOS INTEGRA
CION
65
MODELO DE CAPAS Y RESPONSABILIDADES
A continuación, se especifica los módulos de las capas con las responsabilidades. Esta
tabla nos ayuda a entender como integramos las diferentes capas.
Elementos Responsabilidad Propietario

Capa de presentación Integra todos los Lenguaje= java
componentes Framework =spring
encargados de recibir boot, angular,
interacción por parte JavaScript
del usuario y mostrarle
resultados
Capa de servicios web Exponer servicios web Lenguaje= java
para soportar la Framework =spring
integración de sistemas boot, spring data
externos
Capa de negocio Engloba componentes Lenguaje= java
de coordinación que se Framework =spring
encargan de llevar a boot
cabo la ejecución de
los casos de uso del
sistema
Capa de datos Engloba componentes Lenguaje= java
encargados de Framework =spring
almacenar objetos en boot, hibérnate
una base de datos,
ocultando el resto de la
aplicación el hecho de
que se trata de una base
de datos relacional
Capa de integración Permite la integración Protocolo REST
con sistemas externos
por ejemplo sistema de
solicitud de citas
medicas
Modelo de capas y responsabilidades
66
Diagrama de recuros
Hecho por autores
3.3 MODELO DE INFRAESTRUCTURA
(disponibilidad y ubicación de HW, interacción y protocolos de

comunicación).
La aplicación se desarrollara bajo los lenguajes de programación Java Script, Java y
frameworks como Spring Boot, soportando un acceso a base de datos SQL Server 2000 . La
capa de negocio esta usada por servicios tanto sus interfaces y sus implementaciones las
cuales se encargaran de realizar las respectivas operaciones con la información y comunicar
el backend con el frontend, y por ultimo la capa de datos está conformada por procesos
almacenados en SQL los cuales tendrán entradas y salidas referente a listas o incluso tablas
completas, últimamente la capa de integración se encarga de poder comunicar los datos
67
generados de nuestra aplicación con cualquier API aplicación terciaria esto se llevara a cabo
en un servidor FTP que tendrá archivos XML
3.4 DISEÑO DEL SISTEMA
3.4.1 DEFINICION DEL LENGUAJE DE PROGRAMACION
La razón por la que se escogió como principal lenguaje de programación JAVA

es por su paradigma orientado a objetos lo que nos ayuda a mantener programas
de gran tamaño además de que es el lenguaje mas usado del mundo por su gran
cantidad de librerías y foros donde casi cualquier duda se puede resolver
fácilmente, también es un lenguaje multiplataforma y es totalmente gratis.
4 CONCLUSIONES
El diseño del prototipo de aplicación para la administración de citas médicas por pacientes
de entidades de salud odontológica obedece al estudio y explicación del funcionamiento de
registro, autenticación y roles de usuarios propios del sistema.
La estructura modular del prototipo, y el diseño de la base de datos corresponde, en contexto,
a los módulos de Consulta, asignación, aplazamiento y cancelación de citas médicas
odontológicas definidas por la operacionalizad del modelo
68
Se adaptaron factores de calidad de software al ambiente móvil, entregando un diseño de

prototipo de aplicación que muestra un producto que cumple con los requerimientos
definidos para ser programable, funcional y mantenible.
5 RECOMENDACIONES
El diseño del prototipo de aplicación para dispositivos móviles fue realizado abarcando los
principales módulos para administración de citas médicas odontológicas (“Consulta”,
“Asignación”, “Aplazamiento” y “Cancelación”); sin embargo, cabe mencionar que es
posible considerar ampliar el alcance de la aplicación e involucrar aún más componentes y
soluciones para el usuario del dispositivo móvil. Es por esto, que es posible recomendar la
inclusión de algunos aspectos, tales como la accesibilidad de la aplicación, de tal manera
que sea mínima la limitación que tenga un usuario para involucrarse con ésta. De igual
manera, se podría considerar incluir datos informativos para el usuario como más detalles
del profesional encargado de atender la cita médica odontológica, tales como fotografía o
número de contacto.
Por último, se recomienda que en caso de ser implementado el diseño del prototipo de
aplicación plasmado previamente, se tengan en cuenta metodologías para el desarrollo de la
aplicación de dispositivos móviles, al igual que sean incluidos más factores de calidad
siguiendo un modelo definido, con el fin de asegurar un producto software capaz de suplir
las necesidades de los usuarios y dar valor agregado a los servicios prestados por entidades
de salud en cuanto a la administración de citas.

PROPUESTA PROYECTO Yesid Jimenez David Sotelo Final

Загружено:

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

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

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

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

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

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

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

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

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

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

PROPUESTA PROYECTO Yesid Jimenez David Sotelo Final

Загружено:

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

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

1

PROPUESTA DE DESARROLLO DE UNA APLICACIÓN MÓVIL PARA LA

David Sotelo Rosales

UNIVERSIDAD LIBRE SEDE BOSQUE POPULAR

1 AMBITO DEL PROYECTO ....................................................................... 5

9 INFORMACION Y DIAGNOSTICO SITUACIONAL DE

MODELO ARQUITECTURA CAPAS DE LA APLICACION ................. 64

Conformación del grupo de Trabajo

Nombre David Sotelo Rosales

Nombre Yesid Jiménez

1 AMBITO DEL PROYECTO

1.1 PLANTEAMIENTO DEL PROBLEMA

En la actualidad el software utilizado por la entidad prestadora de servicio de

1.2 DESCRIPCION DEL PROBLEMA

Los problemas identificados en la EPS Medicol son los siguientes:

2. Dificultad para transportarse a entidad prestadora de servicio Medicol para

1.3 REFERENCIAS CON SISTEMAS EXISTENTES

Se observa que otras entidades prestadoras de salud cuentan con problemas a la

Un sistema de información por medio de una aplicación móvil es capaz de

1.4 FORMULACIÓN DEL PROBLEMA

¿Se puede Mediante una arquitectura de software mejorar la congestión a la hora

 Realizar el análisis de requerimientos para establecer los alcances y

La propuesta de desarrollo de una aplicación móvil está orientada a dispositivos

Técnica: el proyecto está basado en un sistema de información, el cual debe dar

Las situaciones actuales de la sociedad en general obligan a estas entidades a

6.1 MARCO TEORICO

siendo ésas últimas, las Instituciones Prestadoras de Servicios de Salud de carácter

En relación con la necesidad de utilización de un Sistema Eficiente de Asignación de

6.1.1 Arquitectura de Aplicaciones móviles8

Para las aplicaciones móviles, se cuenta básicamente con tres elementos:

6.1.2 Servidor Web9

Definido como una tecnología que contiene programas procesadores de aplicaciones,

6.1.3 LENGUAJE DE PROGRAMACION

PHP12: Lenguaje de scripting ampliamente utilizado para diversos propósitos,

6.1.4 BASE DE DATOS

Conjunto de información con logística y estructura operacional definida por una

6.1.5 SISTEMAS OPERATIVOS

Encargado de controlar y coordinar el uso del hardware entre programas de

 Windows Mobile18: Diseñado para dispositivos móviles y teléfonos inteligentes

6.1.6 INGENERIA DE SOTFWARE

Aplicación del método científico a la teorización y creación de conocimiento sobre la

6.1.6.1 Diseño en la Ingeniería de Software

 Tolerancia a fallos: Se refiere a la posibilidad del sistema de ser robusto y

6.2 MARCO CONCEPTUAL

6.3 MARCO LEGAL

 DECRETO 299 DE 1966: Por el cual se reglamentan actividades relacionadas con

 Ley 35 de 1989: “Sobre Ética del Odontólogo Colombiano”.21

6.3.1 NORMATIVA DE PROTECCIÓN DE DATOS PERSONALES

6.3.2 NORMATIVA DE COMERCIO ELECTRÓNICO

6.3.3 NORMATIVA DE CONSUMO

LEY 1480 DE 2011, ESTATUTO DEL CONSUMIDOR Considerar esta normativa

6.3.4 CONSIDERACIONES BASICAS DEL TRATAMIENTO DE LOS

Cuando se hace referencia al tratamiento de datos, se habla de aquellas operaciones

6.3.5 INFORMACION AL USUARIO

Si se diseña esta aplicación móvil para la generación de citas médicas acorde a

7.2 ESTRATEGIA METODOLOGICA

La metodología requerida para este proyecto tiene un enfoque analítico

Exige que se compruebe y de igual forma se verifique el hecho o fenómeno que

Para llevar a cabo la propuesta de diseño de esta aplicación móvil llevaremos a

1. Identificar las necesidades a la que están expuestas las personas con el

a) Definir el lenguaje de programación en el cual se va implementar la

6. Realizar pruebas en pacientes reales para identificar la factibilidad del

II. DEFINICIÓN DE LA ORGANIZACIÓN OBJETO DEL

1991: Medicol nace como empresa de Medicina Prepagada en Bogotá.