Post on 28-Jun-2022
ANALIZAR Y DISEÑAR UN PROTOTIPO NO FUNCIONAL TIPO SOFTWARE
PARA LA GESTIÓN ADECUADA DE LA INFORMACIÓN EN UN CENTRO DE
ATENCIÓN PSICOLÓGICA - CASO CAPSI DE LA UNIVERSIDAD CATÓLICA
DE PEREIRA
GONZALO ANDRÉS GARCÍA VÁSQUEZ
UNIVERSIDAD CATÓLICA DE PEREIRA
FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA
PROGRAMA DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES
RESIDENCIA EN LÍNEA E INVESTIGACIÓN.
PEREIRA
2016
ANALIZAR Y DISEÑAR UNA SOLUCIÓN TIPO SOFTWARE PARA LA
GESTIÓN ADECUADA DE LA INFORMACIÓN EN UN CENTRO DE
ATENCIÓN PSICOLÓGICA - CASO CAPSI DE LA UNIVERSIDAD CATÓLICA
DE PEREIRA
GONZALO ANDRÉS GARCÍA VÁSQUEZ
INFORME DE RESIDENCIA EN LÍNEA E INVESTIGACIÓN.
LUIS EDUARDO PELÁEZ VALENCIA INVESTIGADOR PRINCIPAL Glll, ASESOR
UNIVERSIDAD CATÓLICA DE PEREIRA
FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA
PROGRAMA DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES
RESIDENCIA EN LÍNEA E INVESTIGACIÓN.
PEREIRA
2016
Tabla de contenido
SÍNTESIS..................................................................................................................................... 8
INTRODUCCIÓN ........................................................................................................................ 9
1. ANTECEDENTES ............................................................................................................ 10
2. SITUACIÓN PROBLEMÁTICA ....................................................................................... 11
3. DESCRIPCIÓN DEL PROBLEMA ................................................................................. 12
4. OBJETO DE ESTUDIO ................................................................................................... 13
4.1 OBJETIVO GENERAL ............................................................................................. 13
4.2 OBJETIVOS ESPECÍFICOS .................................................................................. 13
5. MARCO TEÓRICO ........................................................................................................... 13
6. METODOLOGÍA SEGUIDA PARA EL DESARROLLO DEL PROYECTO ............. 17
7. DESARROLLO DEL PROYECTO ................................................................................. 21
7.1 MODELO DE DATOS ................................................................................................... 21
7.1.2 EL PROBLEMA ....................................................................................................... 22
7.1.3 MODELO CONCEPTUAL. ...................................................................................... 23
7.1.4 MODELO ENTIDAD RELACIÓN ................................................................... 24
7.1.5 VISUALIZACIÓN DEL MODELO RELACIONAL ......................................... 24
7.1.6 MODELO RELACIONAL: METADATOS ...................................................... 26
7.1.7 MODELO RELACIONAL: REGISTROS (TUPLAS) .................................... 31
7.1.8 DICCIONARIO DE DATOS. ............................................................................ 33
7.2 MODELO DE PROCESOS ..................................................................................... 40
7.3 DIAGRAMA DE ACTIVIDADES ............................................................................. 53
7.4 DIAGRAMA DE CLASES ........................................................................................ 68
7.5DIAGRAMA DE ESTADOS ........................................................................................... 75
7.6 MODELO DE INTERFAZ. ....................................................................................... 77
8. PRESENTACIÓN Y ANÁLISIS DE LOS RESULTADOS OBTENIDOS .................. 92
9. RESULTADOS OBTENIDOS DESDE LA INVESTIGACIÓN FORMATIVA ............ 92
9.1 RESULTADOS OBTENIDOS DESDE EL DESARROLLO METODOLÓGICO
93
9.2 RESULTADOS OBTENIDOS PARA EL CAPSI .................................................. 94
9.3 CONCLUSIONES Y RECOMENDACIONES ....................................................... 95
10. BIBLIOGRAFÍA ............................................................................................................. 98
Tabla de Ilustraciones
Ilustración 1. Ciclo de vida de un Software ...................................................... 19
Ilustración 2: Ciclo de vida tipo Sashimi ........................................................... 19
Ilustración 3. Grafica Modelo conceptual CAPSI .............................................. 23
Ilustración 4. Modelo Entidad- Relación ........................................................... 24
Ilustración 5: Modelo Relacional Transformación 1 .......................................... 25
Ilustración 6: Modelo transformación 2 ............................................................. 25
Ilustración 7: Modelo Relacional Transformación 3 .......................................... 26
Ilustración 8: Diagrama de caso de uso 0.0 ..................................................... 40
Ilustración 9: Diagrama de caso de uso: Gestión de usuarios ......................... 41
Ilustración 10: Diagrama de caso de uso: consulta de usuarios....................... 43
Ilustración 11: Diagrama de caso de uso: Gestión de pacientes ...................... 44
Ilustración 12: Diagrama de caso de uso: Consultar paciente ......................... 46
Ilustración 13Diagrama de caso de uso: Gestión de citas ................................ 47
Ilustración 14: Diagrama de caso de uso: Consultar citas ................................ 48
Ilustración 15Diagrama de caso de uso: informar cita ...................................... 50
Ilustración 16: Diagrama de caso de uso: Cita ................................................. 51
Ilustración 17: Diagrama de Actividades 1.1: Crear usuario ............................. 53
Ilustración 18: Diagrama de Actividades 1.2: Consulta de usuarios ................. 54
Ilustración 19: Diagrama de Actividades 1.3: Actualizar usuarios .................... 55
Ilustración 20: Diagrama de Actividades 1.4: Eliminar usuarios ....................... 56
Ilustración 21: Diagrama de Actividades 2.1: Crear citas ................................. 57
Ilustración 22: Diagrama de Actividades 2.2: consultar citas ........................... 58
Ilustración 23: Diagrama de Actividades 2.3: Actualizar citas .......................... 59
Ilustración 24: Diagrama de Actividades 2.4: cancelar cita .............................. 60
Ilustración 25: Diagrama de Actividades 3.1: Confirmar datos ......................... 61
Ilustración 26: Diagrama de Actividades 3.2: Informar cita .............................. 62
Ilustración 27: Diagrama de Actividades 4.1: Crear paciente ........................... 63
Ilustración 28: Diagrama de Actividades 4.2: Consulta paciente ...................... 64
Ilustración 29: Diagrama de Actividades 4.3: actualizar paciente..................... 65
Ilustración 30: Diagrama de Actividades 4.4: eliminar paciente ....................... 66
Ilustración 31: Diagrama de Actividades General ............................................. 67
Ilustración 32: Diagrama de clases .................................................................. 68
Ilustración 33: Diagrama de Estados: citas ...................................................... 75
Ilustración 34: Diagrama de Estados: Paciente ................................................ 75
Ilustración 35: Diagrama de Estado: psicólogo ................................................ 76
Ilustración 36: Diagrama de Estados: Usuarios................................................ 76
Ilustración 37: Prototipo inicio de sesión. ......................................................... 77
Ilustración 38: Prototipo Creación de usuario ................................................... 78
Ilustración 39: Prototipo Consulta de usuario ................................................... 80
Ilustración 40: Prototipo: Creación de pacientes .............................................. 82
Ilustración 41: Prototipo: Consulta de paciente ................................................ 84
Ilustración 42: Prototipo: Creación de citas ...................................................... 86
Ilustración 43: Prototipo: consulta de cita ......................................................... 87
Ilustración 44: Prototipo: Confirmar Datos Paciente ......................................... 89
Ilustración 45: Prototipo: Informar cita .............................................................. 90
Lista de Tablas
Tabla 1: Modelo Relacional: Metadatos (psicólogos) ....................................... 26
Tabla 2: Modelo Relacional: Metadatos (pacientes) ......................................... 27
Tabla 3: Modelo Relacional: Metadatos (usuarios) .......................................... 27
Tabla 4: Modelo Relacional: Metadatos (citas)................................................. 28
Tabla 5: Modelo Relacional: Metadatos (Gestiona) .......................................... 29
Tabla 6: Modelo Relacional: Metadatos (Citas del psicólogo) .......................... 29
Tabla 7: Modelo Relacional: Metadatos (Solicita) ............................................ 30
Tabla 8: Modelo Relacional: Metadatos (Programa) ........................................ 30
Tabla 9: Modelo relacional: Registros (Tuplas: usuarios) ................................. 31
Tabla 10: Modelo relacional: Registros (Tuplas: Psicólogo) ............................. 31
Tabla 11: Modelo relacional: Registros (Tuplas: Paciente) .............................. 32
Tabla 12: Modelo relacional: Registros (Tuplas: citas) ..................................... 32
Tabla 13: Modelo relacional: Registros (Tuplas: Gestiona) .............................. 32
Tabla 14: Modelo relacional: Registros (Tuplas: Citas del psicólogo) .............. 33
Tabla 15: Modelo relacional: Registros (Tuplas: solicita) ................................. 33
Tabla 16: Modelo relacional: Registros (Tuplas: programa) ............................. 33
Tabla 17: Diccionario de datos (Psicólogo) ...................................................... 34
Tabla 18: Definición diccionario de datos (Psicólogo) ...................................... 34
Tabla 19: Diccionario de datos (Paciente) ........................................................ 35
Tabla 20: definición diccionario de datos (Paciente) ........................................ 35
Tabla 21: Diccionario de datos (usuarios) ........................................................ 36
Tabla 22: definición Diccionario de datos (Paciente) ........................................ 36
Tabla 23: Diccionario de datos (citas) .............................................................. 37
Tabla 24: Definición Diccionario de datos (citas) .............................................. 37
Tabla 25: Diccionario de datos (Gestiona) ....................................................... 38
Tabla 26: Definición Diccionario de datos (gestiona) ....................................... 38
Tabla 27: Diccionario de datos (citas del psicólogo) ........................................ 38
Tabla 28: definición Diccionario de datos (citas del psicólogo) ........................ 38
Tabla 29: Diccionario de datos (programa) ...................................................... 39
Tabla 30: definición Diccionario de datos (Programa) ...................................... 39
Tabla 31: Diccionario de datos (Solicita) .......................................................... 39
Tabla 32: definición Diccionario de datos (solicita) ........................................... 39
Tabla 33: Documentación Diagrama de Caso de uso 0.0 ................................ 40
Tabla 34: Documentación Diagrama de caso de uso: Gestión de usuarios ..... 42
Tabla 35: Documentacion Diagrama de caso de uso: Consulta de usuarios ... 43
Tabla 36: Documentación Diagrama de caso de uso: Gestión de pacientes ... 45
Tabla 37: Documentación Diagrama de caso de uso: Consultar paciente ....... 46
Tabla 38: Documentación Diagrama de caso de uso: Gestión de citas ........... 47
Tabla 39: Documentación Diagrama de caso de uso: Consultar citas ............. 49
Tabla 40: Documentación Diagrama de caso de uso: informar cita ................. 50
Tabla 41: Documentación Diagrama de caso de uso: cita ............................... 51
Tabla 42: Documentación Diagrama de clases (Psicólogo) ............................. 68
Tabla 43: Documentación Diagrama de clases (paciente) ............................... 69
Tabla 44: Documentación Diagrama de clases (usuario) ................................. 70
Tabla 45: Documentación Diagrama de clases (citas) ..................................... 71
Tabla 46: Documentación Diagrama de clases (Gestiona) .............................. 72
Tabla 47: Documentación Diagrama de clases (citas del Psicólogo) ............... 73
Tabla 48: Documentación Diagrama de clases (solicita) .................................. 73
Tabla 49: Documentación Diagrama de clases (Programa) ............................. 74
8
SÍNTESIS
Con este trabajo se pretende resaltar la
importancia de reconocer y adoptar
buenas prácticas en la solución a
problemáticas de objeto computacional.
En este caso se aborda una problemática
específica del CAPSI (Centro de Atención
Psicológico) relacionada con uno de los
procesos que se llevan a cabo con la
asignación de citas.
Se describe el problema y se desarrolla
metodológicamente cruzando dos
coordenadas conceptuales: los modelos
(conceptual, lógico y físico) y los procesos
por capas.
DESCRIPTORES:
Ingeniería de software, Modelo
conceptual, modelo lógico, modelo físico,
modelo de tres capas.
This paper aims to highlight the
importance of recognizing and
adopting good practices in the
solution of computational object
problems. In this case, a specific
problem of the CAPSI (Psychological
Attention Center) related to one of the
processes that are carried out with the
assignment of appointments is
addressed.
The problem is described and
developed methodologically by
crossing two conceptual coordinates:
the models (conceptual, logical and
physical) and the processes by layers.
DESCRIPTORS:
Software engineering, conceptual
model, logical model, physical model,
three-layer model.
SINTÉSIS
ABSTRACT
9
INTRODUCCIÓN
Frecuentemente los controles que realizan las instituciones al servicio de la salud
son muy minuciosos, esto lleva a que se utilicen métodos convencionales para
la gestión de la información que se obtiene de manera física. En la actualidad
con las tecnologías de la información y comunicación (TIC), se puede realizar
soluciones los cuales mecanicen los procedimientos que se realizan en estas
instituciones para el mejoramiento que se presta al usuario.
La facultad De Ciencias Sociales y Humanas de la Universidad Católica de
Pereira, cumple funciones de proyección social, encaminando sus acciones
hacia la atención de población en situación de vulnerabilidad social por
condiciones de pobreza o desigualdad. El Centro de Atención Psicológico tiene
como objetivo general responder a la comunidad con calidad y eficiencia en el
campo de la salud mental, con servicios de atención, promoción y asesoría
especializada en el área de psicología clínica, educativa y organizacional.
Para el mundo de los sistemas, la ingeniería de software ha permitido que se
pueda comprender todos los aspectos de producción de software desde las
etapas iniciales de la especificación del sistema hasta el mantenimiento de este
después de que se utiliza, adoptando un enfoque sistemático y organizado en su
trabajo, ya que es la forma más efectiva de producir software de alta calidad.
Es por esto que desde la ingeniera de software se ha abordado la problemática
que se tiene en el centro Atención Psicológico (CAPSI) para poder dar solución
a uno de los procesos que se lleva a cabo en dicha entidad, el proceso de citas
que actualmente se lleva de forma inadecuada y que genera afectaciones entre
las tareas cotidianas que llevan los psicólogos, usuarios y pacientes del centro
de atención psicológico, dentro de este trabajo se pretende abordar este proceso
y su necesidad abarcando inicialmente la correcta definición de los
requerimientos que surgen en el CAPSI, para la posterior creación del modelo
de procesos, modelo de interfaz y modelo datos que permitirán que las
especificaciones se cumplan de una forma adecuada.
10
1. ANTECEDENTES
En el año 2010 se llevó acabo el desarrollo del software CAPSOFT para dar
solución a una problemática que se presentaba en el interior del CAPSI (centro
de atención psicológico) con la realización de las historias clínicas. En la
actualidad, la problemática ha trascendido de la mera gestión y administración
de toda la información relacionada con el Centro de atención psicológica.
De Igual forma se consultaron diferentes Universidades de la ciudad de Pereira,
los resultados que se obtuvieron de estas consultas fueron que para el año que
está en curso (2016) la Universidad tecnológica de Pereira se encuentra en el
proceso de construcción de una plataforma llamada “Software de la salud” con
el propósito de digitalizar el servicio de atención psicológico que presta a sus
estudiantes. Por otra parte tanto la universidad Libre de Pereira y Universidad
Andina llevan sus registros mediante bases de datos o archivos generados
mediante un programa informático. Y por último la universidad Remington de
Pereira realiza un breve estudio a sus estudiantes para posteriormente remitirlos
a las diferentes EPS de la ciudad.
11
2. SITUACIÓN PROBLEMÁTICA
Mediante los procesos que se llevan a cabo en el Centro de Atención Psicológica
de la Universidad Católica de Pereira, se han detectado problemas importantes
en la forma que actualmente se realizan los registros de la información que se
maneja internamente en la institución. La problemática es la inadecuada gestión
de toda la información relacionada con el Centro de Atención Psicológica.
Uno de los procesos que se llevan a cabo son las citas, las cuales son asignadas
mediante la secretaria del centro de atención psicológico. Cuando se va ejecutar
el proceso de asignar, cancelar o modificar una cita sucede que los datos no
tienen ningún respaldo ya que se maneja de forma escrita o mediante un editor
de texto del computador. Lo cual pone en riesgo la información, ya que si esta
se llega a perder, tanto el usuario como el psicólogo no podrán cumplir su cita y
esto genera problemas en las actividades que se realizan en el CAPSI. De igual
forma al no tener la información de forma digital y disponible en cualquier
momento se generan sub-procesos, entre pacientes y psicólogos los cuales
tienen que acudir a la secretaria para poder tener claro su citas asignadas .
En cuanto a la cancelación de citas en ocasiones, cuando un consultante llama
a cancelar simplemente se borra del registro donde se tienen escritas las citas
dificultando su sistematización. Es importante tener en cuenta que dicha
sistematización se realiza de forma manual, siendo información esencial para los
registros requeridos para elaborar los informes de gestiones periódicas.
12
3. DESCRIPCIÓN DEL PROBLEMA
Todos los procesos y registros de los usuarios que se llevan a cabo en el CAPSI
son realizados manualmente, entre ellos se encuentra el proceso de citas el cual
se genera de una forma inadecuada el cual puede afectar a los pacientes y
psicólogos en las actividades comunes que se llevan allí.
13
4. OBJETO DE ESTUDIO
El objeto de estudio es la ingeniería del software aplicada a los sistemas de
información para la gestión adecuada de la información en Centros de Atención
Psicológica o Afines, en este informe se aplicará el ciclo y metodología de un
software para que el programa dé solución a uno de los procesos de información
que se requieren en el CAPSI.
4.1 OBJETIVO GENERAL
Diseñar un prototipo no funcional para la gestión de la información relacionada
con el CAPSI (Centro de Atención Psicológico.)
4.2 OBJETIVOS ESPECÍFICOS
- Establecer los requerimientos del problema según los Directivos del CAPSI
(Centro de Atención Psicológica).
- Representar y analizar los requerimientos de la posible solución.
- Analizar y diseñar la estructura y comportamiento del software del centro de
Atención Psicológico.
- Aplicar la solución del diseño mediante la implementación de unos de los
procesos priorizados en los requerimientos
5. MARCO TEÓRICO
Como se puede observar a continuación en el marco contextual, hoy en día todo
lo correspondiente a procedimientos clínicos se encuentra normalizado, pero no
14
se puede ignorar un fenómeno que es cada día más real en nuestra sociedad de
la información, y es la digitalización de los datos. Para desarrollar este proyecto
se hace necesario tener claros unos conceptos de términos apropiados que se
van a manejar en este proyecto.
El CAPSI es el Centro de Atención Psicológica de la UCP, funciona como una
IPS con Objeto social diferente, orienta su atención a la población en general,
pero focaliza en la infancia y la adolescencia como población vulnerable. (Nieto &
Iodice, 2015). Actualmente se destaca la necesidad de precisar una metodología
para poder dar solución a uno de las problemáticas que se tienen en el CAPSI.
Llegar a entender las necesidades de un problema puede ser una de las
dificultades más grandes que se presenten en el desarrollo de un proyecto y es
por esto que (Pressman, 2010) considera que los requerimientos “llevarán a la
comprensión de cuál será el efecto que tendrá el software en el negocio, qué es
lo que quiere el cliente y cómo interactuarán los usuarios finales con el software.”
(pag.101). De esta manera se podrá garantizar que el software pueda cumplir
con las expectativas y necesidades planteadas en un principio.
A partir del levantamiento de los requerimientos se da inicio al proceso de
modelado a nivel de datos donde se comienza con el modelo conceptual que de
acuerdo con (Silberachatz, 2002) permitirá entender “El nivel más bajo de
abstracción que describe cómo se almacenan realmente los datos” (pag. 4). al
respecto se destaca que con este modelo se parte para describir el problema y
el correcto entendimiento del mismo por todas las partes. Es de gran importancia
que el diseño del el modelo conceptual sea el ideal porque de no ser así se
presentarían problemas de redundancia o incompletitud de información.
Luego de contar con la situación problema definida y con la a comprensión del
mismo se definen posibles entidades que intervienen dentro del sistema las
cuales cuentan con más de un atributo y se relacionan mediante el modelo
entidad-relación (E-R), el cual es definido por (Silberschatz, 2006) “El modelo de
datos entidad-relación (E-R) se basa en una percepción del mundo real que
consiste en una colección de objetos básicos, denominados entidades, y de las
15
relaciones entre ellos. Una entidad es una “cosa” u “objeto” del mundo real que
es distinguible de otros objetos.” (pag. 171). A través de este modelo se trazan
las relaciones entre las entidades seleccionadas para el sistema, es importante
que el modelo E-R se le aplique las formas normales para de esta forma
garantizar por lo menos que el sistema cumple con la atomización de datos, el
poder evitar la dependencia multivariada y la dependencia transitiva.
A partir de allí se construye el modelo relacional. (Silberschatz, 2006) define este
modelo como “una colección de tablas para representar tanto los datos como sus
relaciones.” (Pag. 29). Al respecto se destaca la importancia de este modelo
porque de allí surgen modelos relacionales a nivel de Metadatos, Registros
(Tuplas) y Diccionario de datos.
A nivel de modelado de procesos se requiere obtener la relación, roles y
actividades que cumplen los actores que interactúan y/o hacen parte del sistema,
para esto es necesario tomar base del lenguaje del modelado unificado (UML) el
cual es definido por (Pressman, 2010) como “un lenguaje estándar para escribir
diseños de software. El UML puede usarse para visualizar, especificar, construir
y documentar los artefactos de un sistema de software intensivo” para este
proyecto es de gran importancia manejar diagramas UML (Pag. 725) porque es
de gran ayuda a la hora de desarrollar el software ya que manejan un lenguaje
unificado de fácil comprensión permitiendo su fácil implementación.
El lenguaje del modelado unificado está compuesto por diferentes tipos de
diagramas que a la vez cumplen con una función específica, para el sistema
planteado se tuvieron en cuenta los siguientes, el diagrama de casos de usos
cumple con la función de “ayudar a determinar la funcionalidad y características
del software desde la perspectiva del usuario.” (Pressman, 2010) es de gran
importancia para el software porque por medio de este diagrama se podrá
identificar los actores que intervienen en el mismo y los roles o funcionalidades
que cumplen en el sistema.
Después de identificar los actores y sus funciones dentro del sistema pasamos
a establecer las actividades que se realizan dentro del mismo y esto lo
16
planteamos mediante el diagrama de actividades el cual se define como “el
comportamiento dinámico de un sistema o de parte de un sistema a través del
flujo de control entre acciones que realiza el sistema.” (Pressman, 2010) este
diagrama es de gran utilidad ya que representa un nodo acción el cual permite
observar las tareas realizadas por el sistema y de esta manera poder llevar un
flujo de control sobre las acciones.
Por otra parte el Diagrama de Estados permitirá observar el estado de un objeto
y sus diferentes variables según la necesidad del momento, (Pressman, 2010) lo
define como “Un diagrama de estado UML modela los estados de un objeto, las
acciones que se realizan dependiendo de dichos estados y las transiciones entre
los estados del objeto.” La relevancia que representa este diagrama en el
sistema es que permite visualizar el flujo básico verificando las variables y los
estados en los que se encuentran según el funcionamiento que se lleve en el
momento.
Roger S. Pressman (Pressman, 2010) indica que el diagrama de clases “aporta una
visión estática o de estructura de un sistema, sin mostrar la naturaleza dinámica
de las comunicaciones entre los objetos de las clases.” Es importante para el
sistema que el diagrama de clases tenga un diseño correcto en cuanto a sus
atributos, operaciones, relaciones y asociaciones por que dará eficiencia al poder
contrastarlo contra el modelo E-R del concepto de datos.
Dentro de los diferentes modelos de programación se eligió el modelo de tres
capas, esto facilita el proceso ya que el objetivo principal del modelo de capas
es la separación de conceptos desde la lógica de los objetivos de negocio hasta
el diseño y su implementación. (Sommerville, 2013) define este modelo como
“una arquitectura que organiza un sistema en capas donde cada una proporciona
un conjunto de servicios, cada capa se define como una maquina abstracta cuyo
lenguaje se define por los servicios proporcionados” (Pág 227). De allí la
importancia de que cuando se está diseñando un sistema mediante este modelo,
la interfaz y los datos se percibe de forma independiente.
17
Para tener una visión clara sobre el modelo de capas es necesario conocer su
composición, (Sommerville, 2013) indica que está compuesto por la capa de
presentación “está se relaciona con la presentación de la información del usuario
y con toda la interacción con él.” (Pág 245).
Otra de las capas es la capa de negocio, es importante porque es aquí donde se
establecen las reglas, requerimientos y demás elementos propios de las
condiciones y características de los procesos y la aplicación. Después de esta
capa se encuentra. La capa de datos “está relacionada con todas las
operaciones sobre los datos en términos de almacenamiento y manipulación”
(Sommerville, 2013) (Pág 245). Es aquí donde se comienza a desarrollar el
sistema a nivel de datos por eso su gran importancia. Por último se resalta como
desde el modelo capas de logra identificar a partir de que capa se llega a
relacionar con el modelo de datos a nivel del modelo conceptual, modelo lógico,
modelo Físico.
6. METODOLOGÍA SEGUIDA PARA EL DESARROLLO DEL
PROYECTO
De acuerdo a la revista (usr.code, 2010) en la década pasada existían técnicas que
permitían que los proyectos se realizaran de forma ágil pero sin ningún proceso
de planificación, consistía en el levantamiento de requerimientos sobre el
18
programa o producto de software que se quería construir y a continuación de
obtener estas necesidades se comenzaba a codificar sin contemplar ningún
modo o tipo de estrategia, y esto llevaba a que los errores que surgieran se
fueran corrigiendo sobre la codificación realizada permitiendo no gastar recursos
en análisis, planificación, gestión de recursos y documentación. Con el tiempo
los sistemas fueron tomando una magnitud mayor y esto género que la técnica
de codificar y corregir (code & fix) quedara inservible.
Al crecer la complejidad de los programas a desarrollar, surgió la necesidad de
optar por diferentes metodologías que permitieran la gestión y administración de
un proyecto, para llevarlo con altas posibilidades de éxito. Estas opciones
permiten poder tomar un gran proyecto y dividirlo en pequeñas etapas, y de esta
manera seguir procesos sistemáticos para poder idear, implementar y mantener
un producto de software desde que surge la necesidad de construirlo hasta que
se cumple con el objetivo por el cual fue desarrollado.
Existen diferentes modelos de ciclo de vida de un software, su objetivo es el
poder establecer una serie de metas, tareas y actividades a cumplir,
principalmente tiene cinco etapas que claramente se diferencian (inicio,
planificación, implementación, puesta en producción, control en producción) las
cuales permiten tener un control sobre cada uno de los procesos que se trabajen
durante el desarrollo del software.
19
Ilustración 1. Ciclo de vida de un Software
Después de realizar una investigación sobre cada uno de los diferentes tipos de
ciclo de vida de un software se optó por tomar en base el ciclo de vida tipo
sashimi, el cual permitirá que cada una de las etapas se pueda retroalimentar
implícitamente en el modelo, esto permite ventajas al brindar una mayor calidad
con respecto al producto final y es precisamente las mismas retroalimentaciones
en el modelo que nos permite trabajar con el modelo de tres capas ahorrando
recursos.
Ilustración 2: Ciclo de vida tipo Sashimi
20
Para la orientación que precisa la estructura interna del prototipo, se centrará en
tres aspectos: modelo de datos, modelo de procesos, modelo de interfaz los
cuales se trabajarán en contraste a la programación de tres capas, esto facilita
los procesos ya que el objetivo principal del modelo de capas es la separación
de conceptos desde la lógica de los objetivos de negocio hasta el diseño y su
implementación. Por eso, cuando se está diseñando un sistema bajo esta óptica,
la interfaz se percibe de manera independiente a los datos. Esto también permite
entregar el trabajo por personas o por equipos de trabajo alrededor de un
proyecto de software.
Es necesario que para que un sistema cumpla con las especificaciones, se
realice un levantamiento de requerimientos para poder definir cada una de las
necesidades que se tiene para que se obtenga lo ideal, luego de tener claros
cada uno de estos puntos se comienza a crear un conjunto de escenarios que
identifiquen una línea de utilización para el sistema que va a ser construido.
A nivel de modelo de procesos lo que se busca es una descripción simplificada
de un proceso del software que presenta una visión de ese proceso. Estos
modelos pueden incluir actividades que son parte de los procesos y productos
de software y el papel de las personas involucradas en la ingeniería del software.
Dentro del modelo de procesos encontramos.
- Diagramas de casos de uso.
- Diagramas de actividades.
- Diagrama de clases.
- Diagrama de estados.
El modelo de datos que comprende los sistemas de software utiliza bases de
datos de información de gran tamaño. En algunos casos, esta base de datos es
independiente del sistema software. En otros, se crea para el sistema que se
está desarrollando. Una parte importante del modelado de sistemas es la
definición de la forma lógica de los datos procesados por el sistema. Estos se
denominan a menudo modelos de datos. Dentro del modelo de datos se
encuentra
21
- Modelo conceptual.
- Modelo entidad-relación
- Modelo de clases
- Modelo relacional
- Modelo relacional: Metadatos
- Modelo relacional: Registros (Tuplas)
- Diccionario de datos.
En el modelo de interfaz se realizó una investigación acerca de las metodologías
que se podrían aplicar para trabajar la interfaz, los resultados fueron:
Se pudo evidenciar que, más que una metodología existen técnicas para
realizar la interfaz de un programa.
Se indago con personal de la universidad Católica de Pereira y se pudo
concluir que estas técnicas llevan estrategias como lo es, reunirse con el
cliente y juntos se comienza a plasmar mediante dibujos el objetivo al que se
quiere llegar.
Otra técnica conocida en la del Mago de oz, la cual consiste en que el
desarrollador de la interfaz dibuja cada componente del programa y en el
momento de reunirse con el cliente, emulan mediante el paso de las hojas
como sería el flujo del programa.
En la empresa LUCASIAN LABS se investigó cual era la técnica que se llevan
en este lugar para realizar una interfaz, básicamente consiste en que allí
cuentan con Ingenieros de Requerimientos ubicados en la ciudad de Bogotá
los cuales se encargan de hacer el levantamiento de las necesidades del el
cliente, y en el momento que ya se encuentra todo definido, se procede a
realizar prototipos por medio de mockups.
7. DESARROLLO DEL PROYECTO
7.1 MODELO DE DATOS
22
En este Modelo se encuentra establecido la forma lógica en cómo los datos
serán procesados por el sistema. A continuación se desarrollara el contenido
correspondiente al modelo de datos.
7.1.2 EL PROBLEMA
Se requiere para el centro de atención Psicológico (CAPSI) de la universidad
católica de Pereira un prototipo donde se gestionara las citas de los estudiantes
de la universidad o de personas externas que lo requiera. Las citas se podrán
solicitar ya se presencial o telefónicamente la cual será atendida por la persona
encargada o secretaria del centro de atención. El prototipo debe permitir agregar,
editar y eliminar citas, de igual manera debe permitir a los psicólogos o
practicantes consultar sus citas asignadas y permitir en caso tal, el poder
modificar horarios de citas.
Posibles entidades.
- Psicólogo.
- Citas
- Secretaria
- Paciente
- Software
- CAPSI
23
7.1.3 MODELO CONCEPTUAL.
Ilustración 3. Grafica Modelo conceptual CAPSI
24
7.1.4 MODELO ENTIDAD RELACIÓN
Ilustración 4. Modelo Entidad- Relación
25
7.1.5 VISUALIZACIÓN DEL MODELO RELACIONAL
Ilustración 5: Modelo Relacional Transformación 1
Ilustración 6: Modelo transformación 2
26
Ilustración 7: Modelo Relacional Transformación 3
7.1.6 MODELO RELACIONAL: METADATOS
Tabla 1: Modelo Relacional: Metadatos (psicólogos)
Autor: Gonzalo Andrés García Vásquez.
Sistema:
“Analizar y diseñar un prototipo no funcional tipo software
para la gestión adecuada de la Información en un Centro
de Atención Psicológica - Caso CAPSI de la Universidad
Católica de Pereira”
Relación: Psicólogos.
Atributo Tipo Longitud Descripción
Tarjeta profesional TEXTO 20 Tarjeta profesional psicólogo
Nombre 1 TEXTO 26 Nombre 1 psicólogo
Nombre 2 TEXTO 26 Nombre 2 psicólogo
Apellido 1 TEXTO 26 Apellido 1 psicólogo
27
Apellido 2 TEXTO 26 Apellido 2 psicólogo
Teléfono 1 TEXTO 10 Teléfono 1 psicólogo
Teléfono 2 TEXTO 10 Teléfono 2 psicólogo
Cod_psicologo TEXTO 5 Código del psicólogo
Dirección. TEXTO 40 Dirección del psicólogo
Tabla 2: Modelo Relacional: Metadatos (pacientes)
Autor: Gonzalo Andrés García Vásquez.
Sistema:
“Analizar y diseñar un prototipo no funcional tipo software
para la gestión adecuada de la Información en un Centro
de Atención Psicológica - Caso CAPSI de la Universidad
Católica de Pereira”
Relación: Paciente
Atributo Tipo Longitud Descripción
Nombre 1 TEXTO 26 Nombre 1 paciente
Nombre 2 TEXTO 26 Nombre 2 paciente
Apellido 1 TEXTO 26 Apellido 1 paciente
Apellido 2 TEXTO 26 Apellido 2 paciente
Teléfono 1 TEXTO 10 Teléfono 1 paciente
Teléfono 2 TEXTO 10 Teléfono 2 paciente
Cod_paciente TEXTO 5 Código del paciente
Dirección. TEXTO 40 Dirección del paciente
Tabla 3: Modelo Relacional: Metadatos (usuarios)
Autor: Gonzalo Andrés García Vásquez.
28
Sistema:
“Analizar y diseñar un prototipo no funcional tipo software para
la gestión adecuada de la Información en un Centro de
Atención Psicológica - Caso CAPSI de la Universidad Católica
de Pereira”
Relación: usuario
Atributo Tipo Longitud Descripción
Nombre 1 TEXTO 26 Nombre 1 usuario
Nombre 2 TEXTO 26 Nombre 2 usuario
Apellido 1 TEXTO 26 Apellido 1 usuario
Apellido 2 TEXTO 26 Apellido 2 usuario
Teléfono 1 TEXTO 10 Teléfono 1 usuario
Teléfono 2 TEXTO 10 Teléfono 2 usuario
Cod_usuario TEXTO 5 Código del usuario
Dirección. TEXTO 40 Dirección del usuario
Tabla 4: Modelo Relacional: Metadatos (citas)
Autor: Gonzalo Andrés García Vásquez.
Sistema:
“Analizar y diseñar un prototipo no funcional tipo software para la gestión adecuada de la Información en un Centro de Atención Psicológica - Caso CAPSI de la Universidad Católica de Pereira”
Relación: Citas
Atributo Tipo Longitud Descripción
Fecha_cita FECHA 26 Fecha de la cita
Fecha_creacion FECHA 26 Fecha de la creación de la cita
29
Hora_cita TEXTO 26 Hora de la cita
Código_paciente TEXTO 26 Código del paciente
Código_usuario TEXTO 10 Código de la secretaria
Código_citas TEXTO 10 Código de las citas
Cod_psicologo TEXTO 5 Código del psicólogo
Tabla 5: Modelo Relacional: Metadatos (Gestiona)
Autor: Gonzalo Andrés García Vásquez.
Sistema:
“Analizar y diseñar un prototipo no funcional tipo software para la gestión adecuada de la Información en un Centro de Atención Psicológica - Caso CAPSI de la Universidad Católica de Pereira”
Relación: Gestiona (Psicologos_Usuarios)
Atributo Tipo Longitud Descripción
Codigo_usuario TEXTO 26 Código del usuario
Codigo_Psicologo TEXTO 10 Código del paciente
Tabla 6: Modelo Relacional: Metadatos (Citas del psicólogo)
Autor: Gonzalo Andrés García Vásquez.
Sistema: “Analizar y diseñar un prototipo no funcional tipo software para la gestión adecuada de la Información en un Centro
30
de Atención Psicológica - Caso CAPSI de la Universidad Católica de Pereira”
Relación: Citas del psicólogo (Psicologos_citas)
Atributo Tipo Longitud Descripción
Codigo_citas TEXTO 10 Código de las citas
Codigo_Psicologo TEXTO 5 Código del psicólogo
Tabla 7: Modelo Relacional: Metadatos (Solicita)
Autor: Gonzalo Andrés García Vásquez.
Sistema:
“Analizar y diseñar un prototipo no funcional tipo software para la gestión adecuada de la Información en un Centro de Atención Psicológica - Caso CAPSI de la Universidad Católica de Pereira”
Relación: Solicita (Pacientes_citas)
Atributo Tipo Longitud Descripción
Codigo_citas TEXTO 10 Código de las citas
Codigo_pacientes TEXTO 26 Código del paciente
Tabla 8: Modelo Relacional: Metadatos (Programa)
Autor: Gonzalo Andrés García Vásquez.
Sistema: “Analizar y diseñar un prototipo no funcional tipo software para la gestión adecuada de la Información en un Centro
31
de Atención Psicológica - Caso CAPSI de la Universidad Católica de Pereira”
Relación: Programa (Usuarios_citas)
Atributo Tipo Longitud Descripción
Codigo_citas TEXTO 10 Código de las citas
Codigo_usuarios TEXTO 26 Código del usuario
7.1.7 MODELO RELACIONAL: REGISTROS (TUPLAS)
Tabla 9: Modelo relacional: Registros (Tuplas: usuarios)
Tabla 10: Modelo relacional: Registros (Tuplas: Psicólogo)
32
Tabla 11: Modelo relacional: Registros (Tuplas: Paciente)
Tabla 12: Modelo relacional: Registros (Tuplas: citas)
Tabla 13: Modelo relacional: Registros (Tuplas: Gestiona)
33
Tabla 14: Modelo relacional: Registros (Tuplas: Citas del psicólogo)
Tabla 15: Modelo relacional: Registros (Tuplas: solicita)
Tabla 16: Modelo relacional: Registros (Tuplas: programa)
7.1.8 DICCIONARIO DE DATOS.
Gestión Citas= Psicólogo + paciente + usuario+ citas + Gestiona
Psicólogo= Tarjeta profesional + Nombre 1 + {Nombre 2} + Apellido 1 +
{Apellido 2} + Teléfono 1 + {Teléfono 2} + cod_psicologo + Dirección.
34
Tabla 17: Diccionario de datos (Psicólogo)
Tabla 18: Definición diccionario de datos (Psicólogo)
Paciente = Nombre 1 + {Nombre 2} + Apellido 1 + {Apellido 2} + Teléfono 1 +
{Teléfono 2} + cod_paciente + Dirección.
35
Tabla 19: Diccionario de datos (Paciente)
Tabla 20: definición diccionario de datos (Paciente)
Usuarios = Nombre 1 + {Nombre 2} + Apellido 1 + {Apellido 2} + Teléfono 1 +
{Teléfono 2} + cod_usuario + Dirección.
36
Tabla 21: Diccionario de datos (usuarios)
Tabla 22: definición Diccionario de datos (Paciente)
Citas = Nombre 1 + {Nombre 2} + Apellido 1 + {Apellido 2} + Teléfono 1 +
{Teléfono 2} + cod_cita + Dirección.
37
Tabla 23: Diccionario de datos (citas)
Tabla 24: Definición Diccionario de datos (citas)
Gestiona = cod_Psicologo + cod_usuario
38
Tabla 25: Diccionario de datos (Gestiona)
Tabla 26: Definición Diccionario de datos (gestiona)
Citas del Psicólogo = cod_Psicologo + cod_cita
Tabla 27: Diccionario de datos (citas del psicólogo)
Tabla 28: definición Diccionario de datos (citas del psicólogo)
39
Programa = cod_usuarios + cod_cita
Tabla 29: Diccionario de datos (programa)
Tabla 30: definición Diccionario de datos (Programa)
Solicita = cod_pacientes+ cod_cita
Tabla 31: Diccionario de datos (Solicita)
Tabla 32: definición Diccionario de datos (solicita)
40
7.2 MODELO DE PROCESOS
Ilustración 8: Diagrama de caso de uso 0.0
Tabla 33: Documentación Diagrama de Caso de uso 0.0
ID DCU 0
Nombre Gestión de usuarios, Gestión de pacientes, Gestión de citas, Generación de
información
Descripción El psicólogo o usuario por medio de una interfaz inicia sesión bajo su perfil y
puede ingresar a los modelos (Gestión de Usuarios, Gestión de citas, Generación
de información)
Autor Gonzalo Andrés García Vásquez.
Fecha creación 04/06/2016 Fecha última modificación 23/08/2016
Actores Psicólogos, usuarios
Precondiciones El psicólogo o usuarios, deben iniciar sesión con su cuenta propia para poder
acceder al sistema
41
Poscondiciones Dependiendo al modelo que el psicólogo o usuario elija se accederá al caso de
uso DCU 1.0 ( Gestión de Usuarios), DCU 2.0 (Gestión de citas), o (Generación
de información) DCU 3.0
Flujo normal de eventos
1. El psicólogo o usuarios Inician sesión 2. El psicólogo o usuarios acceden en el módulo requerido 3. Según el modulo seleccionado siguen los casos de uso DCU 1.0, DCU 2.0 ó DCU 3.0
Flujos alterno
1. Ninguno
Excepciones
1. Ninguno
Anotaciones: Ninguna
Ilustración 9: Diagrama de caso de uso: Gestión de usuarios
42
Tabla 34: Documentación Diagrama de caso de uso: Gestión de usuarios
ID DCU 1.0
Nombre Gestor de usuarios
Descripción El psicólogo inician sesión, al seleccionar el modulo Gestor de usuarios, se
cargara los sub-módulos (crear, eliminar, actualizar y consultar un usuario)
Autor Gonzalo Andrés García Vásquez.
Fecha creación 04/06/2016 Fecha última modificación 23/08/2016
Actores Psicólogos, usuarios
Precondiciones El psicólogo, deben iniciar sesión con su cuenta propia para poder acceder al
sistema, luego debe ingresar por gestionar usuarios para poder eliminar, crear,
actualizar y consultar usuarios.
Poscondiciones -El psicólogo Solo podrán eliminar, crear, actualizar y consultar pacientes en el
momento que se dé identifique que aún no está registrado
Flujo normal de eventos
1. El psicólogo crean usuarios 2. Si se elige el sub-modulo consultar usuarios sigue el caso de uso DCU 1.1
Flujos alternos
Ninguna
Excepciones
3. El usuarios ya está registrado a. Los usuarios ya pueden gestionar pacientes y asignar citas en el sistema.
Anotaciones: Ninguna
43
Ilustración 10: Diagrama de caso de uso: consulta de usuarios
Tabla 35: Documentacion Diagrama de caso de uso: Consulta de usuarios
ID DCU 1.1
Nombre Consultar usuarios.
Descripción El psicólogo inicia sesión, al seleccionar el modulo Gestor de usuarios, se cargara
los sub-módulos (crear, eliminar, actualizar y consultar un usuario), allí podrá
ingresar al sub-modulo consultar que a la vez incluye los sub-módulos eliminar y
Actualizar, ya que estos últimos dependen del sub-modulo consultar para
poderse efectuar.
Autor Gonzalo Andrés García Vásquez.
Fecha creación 04/06/2016 Fecha última modificación 23/08/2016
Actores Psicólogos
Precondiciones El psicólogo debe iniciar sesión con su cuenta propia para poder acceder al
sistema, luego debe ingresar por gestionar usuarios para poder Consultar un
usuario, eliminar o actualizar
44
Ilustración 11: Diagrama de caso de uso: Gestión de pacientes
Poscondiciones -Para poder eliminar o actualizar un usuario se debe realizar primero la consulta
del Registro del usuario
Flujo normal de eventos
1. El psicólogo consulta usuarios 2. El psicólogo Actualiza usuarios 3. El psicólogo Elimina usuarios
Flujos alternos
- Cada vez que se consulta, elimine o edite un usuario el sistema mostrara en pantalla un mensaje confirmando el correcto proceso
Excepciones
- Error “ El actor sólo puede actualizar un usuario sí se tiene un registro seleccionado” - Error “ El actor sólo puede eliminar un usuario sí se tiene un registro seleccionado”
Anotaciones: ninguna
45
Tabla 36: Documentación Diagrama de caso de uso: Gestión de pacientes
ID DCU 4.0
Nombre Gestor de pacientes
Descripción El psicólogo y usuarios inician sesión, al seleccionar el modulo Gestor de
usuarios, se cargara los sub-módulos (crear, eliminar, actualizar y consultar un
usuario)
Autor Gonzalo Andrés García Vásquez.
Fecha creación 04/06/2016 Fecha última modificación 23/08/2016
Actores Psicólogos, usuarios
Precondiciones El psicólogo o usuarios, deben iniciar sesión con su cuenta propia para poder
acceder al sistema, luego debe ingresar por gestionar usuarios para poder
eliminar, crear, actualizar y consultar usuarios.
Poscondiciones -El psicólogo y usuarios Solo podrán eliminar, crear, actualizar y consultar
pacientes en el momento que se dé identifique que aún no está registrado
Flujo normal de eventos
1. El psicólogo y s usuarios crean usuarios 2. Si se elige el sub-modulo consultar usuarios sigue el caso de uso DCU 1.1
Flujos alternos
Ninguna
Excepciones
3. El paciente ya está registrado a. El paciente ya puede gestionar su cita sin realizar la gestión de usuarios.
Anotaciones: Ninguna
46
Ilustración 12: Diagrama de caso de uso: Consultar paciente
Tabla 37: Documentación Diagrama de caso de uso: Consultar paciente
ID DCU 4.1
Nombre Consultar pacientes.
Descripción El psicólogo o usuarios inicia sesión, al seleccionar el modulo Gestor de
pacientes, se cargara los sub-módulos (crear, eliminar, actualizar y consultar un
usuario), allí podrá ingresar al sub-modulo consultar que a la vez incluye los sub-
módulos eliminar y Actualizar, ya que estos últimos dependen del sub-modulo
consultar para poderse efectuar.
Autor Gonzalo Andrés García Vásquez.
Fecha creación 04/06/2016 Fecha última modificación 23/08/2016
Actores Psicólogos
Precondiciones El psicólogo o suarios debe iniciar sesión con su cuenta propia para poder
acceder al sistema, luego debe ingresar por gestionar pacientes para poder
Consultar un usuario, eliminar o actualizar
Poscondiciones -Para poder eliminar o actualizar un usuario se debe realizar primero la consulta
del Registro del usuario
Flujo normal de eventos
4. El psicólogo o usuarios consultan pacientes 5. El psicólogo o usuarios Actualizan pacientes 6. El psicólogo pacientes Elimina pacientes
47
Ilustración 13Diagrama de caso de uso: Gestión de citas
Tabla 38: Documentación Diagrama de caso de uso: Gestión de citas
Flujos alternos
- Cada vez que se consulta, elimine o edite un paciente el sistema mostrara en pantalla un mensaje confirmando el correcto proceso
Excepciones
- Error “ El actor sólo puede actualizar un usuario sí se tiene un registro seleccionado” - Error “ El actor sólo puede eliminar un usuario sí se tiene un registro seleccionado”
Anotaciones: ninguna
ID DCU 2.0
Nombre Gestor de citas
Descripción El psicólogo y usuarios inician sesión, al seleccionar el modulo Gestor de citas, se
cargara los sub-módulos (crear, consultar, actualizar y cancelar una cita)
48
Ilustración 14: Diagrama de caso de uso: Consultar citas
Autor Gonzalo Andrés García Vásquez.
Fecha creación 04/06/2016 Fecha última modificación 23/08/2016
Actores Psicólogos, usuarios
Precondiciones El psicólogo o usuarios, deben iniciar sesión con su cuenta propia para poder
acceder al sistema, luego debe ingresar por gestionar citas para poder cancelar,
crear, actualizar o consultar citas.
Poscondiciones -El psicólogo y usuarios Solo podrán cancelar, crear, actualizar y consultar
pacientes en el momento que se dé identifique que aún no está registrado
Flujo normal de eventos
1. La secretaria crea citas 2. Si se elige el sub-modulo consultar citas sigue el caso de uso DCU 2.1
Flujos alternos
Ninguna
Excepciones
3. La cita ya está registrada a. El paciente ya puede gestionar su cita sin realizar la gestión de usuarios.
Anotaciones: Ninguna
49
Tabla 39: Documentación Diagrama de caso de uso: Consultar citas
ID DCU 2.1
Nombre Consultas citas
Descripción El psicólogo y usuarios inician sesión, al seleccionar el modulo Gestor de citas, se
cargara los sub-módulos (crear, eliminar, actualizar o consultar una cita), allí se
podrá ingresar al sub-modulo consultar que a la vez incluye los sub-módulos
cancelar y Actualizar citas, ya que estos últimos dependen del sub-modulo
consultar citas para poderse efectuar.
Autor Gonzalo Andrés García Vásquez.
Fecha creación 04/06/2016 Fecha última modificación 23/08/2016
Actores Psicólogos, usuarios
Precondiciones El psicólogo o usuarios , deben iniciar sesión con su cuenta propia para poder
acceder al sistema, luego debe ingresar por gestionar citas para poder cancelar,
actualizar o consultar citas.
Poscondiciones -Para poder eliminar o actualizar un usuario se debe realizar primero la consulta
del Registro del usuario
Flujo normal de eventos
7. El psicólogo y usuarios consultan citas 8. El psicólogo y usuarios Actualizan citas 9. El psicólogo y usuarios cancelan citas
Flujos alternos
- Cada vez que se Actualice, cancele o edite una cita el sistema mostrara en pantalla que el proceso se realizó correctamente
Excepciones
- Error “ El actor sólo puede actualizar una cita sí se tiene un registro seleccionado” - Error “ El actor sólo puede cancelar una cita sí se tiene un registro seleccionado”
Anotaciones: ninguna
50
Ilustración 15Diagrama de caso de uso: informar cita
Tabla 40: Documentación Diagrama de caso de uso: informar cita
ID DCU 3.0
Nombre Generación de información
Descripción Los usuarios inician sesión, al seleccionar el modulo Genera información, se
cargara los sub-módulos (Confirmar datos, Informar), allí se podrá ingresar al sub-
modulo confirmar datos, para informar acerca de una cita se hará mediante el
envío de correo, mensaje o impresión de la cita.
Autor Gonzalo Andrés García Vásquez.
Fecha creación 04/06/2016 Fecha última modificación 26/08/2016
Actores Secretarias, usuarios
Precondiciones Los usuarios debe iniciar sesión con su cuenta propia para poder acceder al
sistema, luego debe ingresar por gestionar información para poder confirmar
datos de usuario o informar acerca de una cita
Poscondiciones - los usuarios Solo podrán confirmar datos
Flujo normal de eventos
1. Los usuarios confirma datos
51
Ilustración 16: Diagrama de caso de uso: Cita
Tabla 41: Documentación Diagrama de caso de uso: cita
2. Los usuarios informa sobre la cita 3. Si se elige el sub-modulo informar cita, sigue el caso de uso 3.1
Flujos alternos
Ninguna
Excepciones
a. ninguna
Anotaciones: Ninguna
ID DCU 3.1
Nombre Informar cita.
Descripción Los usuarios inician sesión, al seleccionar el modulo generación de información,
se cargara el sub-módulo informar cita, allí se debe consultar la información
sobre la cita e informar a través de los diferentes medios
52
Autor Gonzalo Andrés García Vásquez.
Fecha creación 04/06/2016 Fecha última modificación 23/08/2016
Actores usuarios
Precondiciones Los usuarios deben iniciar sesión con su cuenta propia para poder acceder al
sistema, luego debe ingresar por gestión de información para poder generar la
información de la cita
Poscondiciones -Para poder Generar la información de una cita se debe realizar primero la
consulta del Registro del usuario.
Flujo normal de eventos
10. los usuarios genera información acerca de la cita. 11. Esta información es dada a través de los diferentes medios (Correo electrónico, mensaje,
impresión)
Flujos alternos
- ninguno
Excepciones
- Error “ El actor sólo puede generar información de una cita, sí se tiene un registro seleccionado”
Anotaciones: ninguna
53
7.3 DIAGRAMA DE ACTIVIDADES
Ilustración 17: Diagrama de Actividades 1.1: Crear usuario
54
Ilustración 18: Diagrama de Actividades 1.2: Consulta de usuarios
55
Ilustración 19: Diagrama de Actividades 1.3: Actualizar usuarios
56
Ilustración 20: Diagrama de Actividades 1.4: Eliminar usuarios
57
Ilustración 21: Diagrama de Actividades 2.1: Crear citas
58
Ilustración 22: Diagrama de Actividades 2.2: consultar citas
59
Ilustración 23: Diagrama de Actividades 2.3: Actualizar citas
60
Ilustración 24: Diagrama de Actividades 2.4: cancelar cita
61
Ilustración 25: Diagrama de Actividades 3.1: Confirmar datos
62
Ilustración 26: Diagrama de Actividades 3.2: Informar cita
63
Ilustración 27: Diagrama de Actividades 4.1: Crear paciente
64
Ilustración 28: Diagrama de Actividades 4.2: Consulta paciente
65
Ilustración 29: Diagrama de Actividades 4.3: actualizar paciente
66
Ilustración 30: Diagrama de Actividades 4.4: eliminar paciente
67
Ilustración 31: Diagrama de Actividades General
68
7.4 DIAGRAMA DE CLASES
Ilustración 32: Diagrama de clases
Tabla 42: Documentación Diagrama de clases (Psicólogo)
Autor: Gonzalo Andrés García Vásquez.
Sistema:
“Analizar y diseñar un prototipo no funcional tipo software
para la gestión adecuada de la Información en un Centro
de Atención Psicológica - Caso CAPSI de la Universidad
Católica de Pereira”
Relación: Psicólogos.
Atributo Tipo Longitud Descripción
Tarjeta profesional TEXTO 20 Tarjeta profesional psicólogo
69
Nombre 1 TEXTO 26 Nombre 1 psicólogo
Nombre 2 TEXTO 26 Nombre 2 psicólogo
Apellido 1 TEXTO 26 Apellido 1 psicólogo
Apellido 2 TEXTO 26 Apellido 2 psicólogo
Teléfono 1 TEXTO 10 Teléfono 1 psicólogo
Teléfono 2 TEXTO 10 Teléfono 2 psicólogo
Cod_psicologo TEXTO 5 Código del psicólogo
Dirección. TEXTO 40 Dirección del psicólogo
Operaciones Tipo
Actualiza TEXTO
Elimina TEXTO
Modifica TEXTO
Tabla 43: Documentación Diagrama de clases (paciente)
Autor: Gonzalo Andrés García Vásquez.
Sistema:
“Analizar y diseñar un prototipo no funcional tipo software
para la gestión adecuada de la Información en un Centro
de Atención Psicológica - Caso CAPSI de la Universidad
Católica de Pereira”
Relación: Paciente
Atributo Tipo Longitud Descripción
Nombre 1 TEXTO 26 Nombre 1 paciente
Nombre 2 TEXTO 26 Nombre 2 paciente
Apellido 1 TEXTO 26 Apellido 1 paciente
70
Apellido 2 TEXTO 26 Apellido 2 paciente
Teléfono 1 TEXTO 10 Teléfono 1 paciente
Teléfono 2 TEXTO 10 Teléfono 2 paciente
Cod_paciente TEXTO 5 Código del paciente
Dirección. TEXTO 40 Dirección del paciente
Operaciones Tipo
Actualiza TEXTO
Elimina TEXTO
Modifica TEXTO
Tabla 44: Documentación Diagrama de clases (usuario)
Autor: Gonzalo Andrés García Vásquez.
Sistema:
“Analizar y diseñar un prototipo no funcional tipo software para
la gestión adecuada de la Información en un Centro de
Atención Psicológica - Caso CAPSI de la Universidad Católica
de Pereira”
Relación: usuario
Atributo Tipo Longitud Descripción
Nombre 1 TEXTO 26 Nombre 1 usuario
Nombre 2 TEXTO 26 Nombre 2 usuario
Apellido 1 TEXTO 26 Apellido 1 usuario
Apellido 2 TEXTO 26 Apellido 2 usuario
71
Teléfono 1 TEXTO 10 Teléfono 1 usuario
Teléfono 2 TEXTO 10 Teléfono 2 usuario
Cod_usuario TEXTO 5 Código del usuario
Dirección. TEXTO 40 Dirección del usuario
Operaciones Tipo
Actualiza TEXTO
Elimina TEXTO
Crea TEXTO
Tabla 45: Documentación Diagrama de clases (citas)
Autor: Gonzalo Andrés García Vásquez.
Sistema:
“Analizar y diseñar un prototipo no funcional tipo software para la gestión adecuada de la Información en un Centro de Atención Psicológica - Caso CAPSI de la Universidad Católica de Pereira”
Relación: Citas
Atributo Tipo Longitud Descripción
Fecha_cita FECHA 26 Fecha de la cita
Fecha_creacion FECHA 26 Fecha de la creación de la cita
Hora_cita TEXTO 26 Hora de la cita
Código_paciente TEXTO 26 Código del paciente
72
Código_usuario TEXTO 10 Código de la secretaria
Código_citas TEXTO 10 Código de las citas
Cod_psicologo TEXTO 5 Código del psicólogo
Operaciones Tipo
Actualiza TEXTO
Cancela TEXTO
Crea TEXTO
Consulta TEXTO
Tabla 46: Documentación Diagrama de clases (Gestiona)
Autor: Gonzalo Andrés García Vásquez.
Sistema:
“Analizar y diseñar un prototipo no funcional tipo software para la gestión adecuada de la Información en un Centro de Atención Psicológica - Caso CAPSI de la Universidad Católica de Pereira”
Relación: Gestiona (Psicologos_Usuarios)
Atributo Tipo Longitud Descripción
Codigo_usuario TEXTO 26 Código del usuario
Codigo_Psicologo TEXTO 10 Código del paciente
73
Tabla 47: Documentación Diagrama de clases (citas del Psicólogo)
Autor: Gonzalo Andrés García Vásquez.
Sistema:
“Analizar y diseñar un prototipo no funcional tipo software para la gestión adecuada de la Información en un Centro de Atención Psicológica - Caso CAPSI de la Universidad Católica de Pereira”
Relación: Citas del psicólogo (Psicologos_citas)
Atributo Tipo Longitud Descripción
Codigo_citas TEXTO 10 Código de las citas
Codigo_Psicologo TEXTO 5 Código del psicólogo
Tabla 48: Documentación Diagrama de clases (solicita)
Autor: Gonzalo Andrés García Vásquez.
Sistema:
“Analizar y diseñar un prototipo no funcional tipo software para la gestión adecuada de la Información en un Centro de Atención Psicológica - Caso CAPSI de la Universidad Católica de Pereira”
Relación: Solicita (Pacientes_citas)
Atributo Tipo Longitud Descripción
Codigo_citas TEXTO 10 Código de las citas
Codigo_pacientes TEXTO 26 Código del paciente
74
Tabla 49: Documentación Diagrama de clases (Programa)
Autor: Gonzalo Andrés García Vásquez.
Sistema:
“Analizar y diseñar un prototipo no funcional tipo software para la gestión adecuada de la Información en un Centro de Atención Psicológica - Caso CAPSI de la Universidad Católica de Pereira”
Relación: Programa (Usuarios_citas)
Atributo Tipo Longitud Descripción
Codigo_citas TEXTO 10 Código de las citas
Codigo_usuarios TEXTO 26 Código del usuario
75
7.5DIAGRAMA DE ESTADOS
Ilustración 33: Diagrama de Estados: citas
Ilustración 34: Diagrama de Estados: Paciente
76
Ilustración 35: Diagrama de Estado: psicólogo
Ilustración 36: Diagrama de Estados: Usuarios
Usuarios
77
7.6 MODELO DE INTERFAZ.
Con base a la investigación realizada se procede a realizar los prototipos de la
interfaz y su respectiva documentación, basados en la información que se
encuentra en el modelo de datos del software del CAPSI.
Ilustración 37: Prototipo inicio de sesión.
Usuario: comboBox (Se selecciona un perfil para iniciar sesión) el comboBox es
una lista desplegable la cual contiene las opciones de: 1- Secretaria, 2-Psicologo
Contraseña: Text input (Se ingresa la contraseña alfanumérica para el inicio de
sesión correcto)
Aceptar: Button (Es el botón por el cual se acepta que los datos ingresados son
correctos)
78
Cancelar: Button (Es el botón por el cual se cancelar el inicio de sesión)
Olvido su contraseña: Link (Mediante este link se podrá acceder para
restablecer la contraseña de usuario)
Ilustración 38: Prototipo Creación de usuario
Cada vez que se inicie sesión se cargara las diferentes opciones para navegar
a través del software, al ingresar en creación de usuarios se cargara un
formulario para realizar dicha creación.
Primer Nombre: Text input (Se ingresa el primer nombre del usuario)
Segundo Nombre: Text input (Se ingresa el segundo nombre del usuario)
Primer Apellido: Text input (Se ingresa el primer Apellido del usuario)
Segundo Apellido: Text input (Se ingresa el segundo Apellido del usuario)
79
Tipo de documento: ComboBox (Permite la selección del tipo de documento
del usuario) contiene cuatro opciones: 1. C.C, 2. T.I, 3. P.A 4. C.E
Numero de documento: Text input (Se ingresa el número de documento del
usuario)
Dirección: Text input (Se ingresa la dirección del usuario)
Número de Teléfono: Text input (Se ingresa el teléfono del usuario)
Número de celular: Text input (Se ingresa el celular del usuario)
Fecha de creación: Date chooser (Se ingresa la fecha en la que el usuario es
creado)
Aceptar: Button (Es el botón por el cual se acepta que los datos ingresados son
correctos y se puede crear el usuario)
Cancelar: Button (Es el botón por el cual se cancela la creación de un usuario)
Cerrar sesión: Button (Es el botón por el cual se cierra la sesión del perfil que
este activo)
Relación De interfaz Diagramas
Creación de usuarios DCU 1.0, DA 1.1, DC, DE
80
Ilustración 39: Prototipo Consulta de usuario
Para la Consulta de un usuario se podrá realizara mediante dos criterios de
búsqueda la primera es el código y/o cedula del usuario y la segunda se puede
realizar por la fecha de creación de usuarios, si la consulta es de un usuario
valido automáticamente cargara los registros o datos de la persona solicitante.
Tipo de documento: ComboBox (Permite la selección del tipo de documento
del usuario) contiene cuatro opciones: 1. C.C, 2. T.I, 3. P.A 4. C.E
Numero de documento: Text input (Se ingresa el número de documento del
usuario)
Fecha de creación: Date chooser (Se ingresa la fecha en la que el usuario es
creado como criterio de búsqueda)
Nombres: Text output (Muestra en pantalla los Nombres del usuario)
Apellidos: Text output (Muestra en pantalla los Apellidos del usuario)
Número de identificación: Text output (Muestra en pantalla el código del
usuario)
81
Dirección: Text output (Muestra en pantalla la dirección del usuario)
Teléfono Text output (Muestra en pantalla el teléfono del usuario)
Fecha de creación: Date chooser (Muestra en pantalla la fecha en la que el
usuario fue creado)
Checkbox: Checkbox (permite seleccionar registros para posteriormente
editarlos o eliminarlos)
Consultar: Button (Es el botón por el cual se puede consultar los datos de un
usuario en un registro)
Editar: Button (Es el botón por el cual se puede editar los datos de un usuario
en un registro)
Eliminar: Button (Es el botón por el cual se puede eliminar registros de usuarios
en un registro)
Aceptar: Button (Es el botón por el cual se acepta que los datos consultados son
los correctos)
Cancelar: Button (Es el botón por el cual se cancela la consulta del usuario)
Cerrar sesión: Button (Es el botón por el cual se cierra la sesión del perfil que
este activo)
Relación De interfaz Diagramas
Consulta de usuario DCU 1.1, DA 1.1, DA 1.2, DA 1.3, DA
1.4, DC, DE
82
Ilustración 40: Prototipo: Creación de pacientes
Cada vez que se inicie sesión se cargara las diferentes opciones para navegar
a través del software, al ingresar en Gestión de pacientes se podrá crear un
paciente.
Primer Nombre: Text input (Se ingresa el primer nombre del paciente)
Segundo Nombre: Text input (Se ingresa el segundo nombre del paciente)
Primer Apellido: Text input (Se ingresa el primer Apellido del paciente)
Segundo Apellido: Text input (Se ingresa el segundo Apellido del paciente)
83
Tipo de documento: ComboBox (Permite la selección del tipo de documento
del paciente) contiene cuatro opciones: 1. C.C, 2. T.I, 3. P.A 4. C.E
Número de identificación: Text input (Se ingresa el número de documento del
paciente)
Sexo: ComboBox (Permite la selección del sexo del paciente) contiene dos
opciones: 1. Masculino, 2. Femenino
Dirección: Text input (Se ingresa la dirección del paciente)
Correo: Text input (Se ingresa el correo electrónico del paciente)
Teléfono: Text input (Se ingresa el teléfono del paciente)
Fecha de creación: Date chooser (Se ingresa la fecha en la que el paciente fue
creado)
Número de Teléfono: Text input (Se ingresa el teléfono del paciente)
Número de celular: Text input (Se ingresa el celular del usuario)
Aceptar: Button (Es el botón por el cual se acepta que los datos ingresados son
correctos y se puede crear el paciente)
Cancelar: Button (Es el botón por el cual se cancela la creación de un paciente)
Cerrar sesión: Button (Es el botón por el cual se cierra la sesión del perfil que
este activo)
Relación De interfaz Diagramas
Creación de paciente DCU 4.0, DA 4.1, DC, DE
84
Ilustración 41: Prototipo: Consulta de paciente
Para la Consulta de un paciente se podrá realizara mediante dos criterios de
búsqueda la primera es el código y/o cedula del paciente y la segunda se puede
realizar por la fecha de creación de pacientes, si la consulta es de un usuario
valido automáticamente cargara los registros o datos de la persona solicitante.
Tipo de documento: ComboBox (Permite la selección del tipo de documento
del paciente) contiene cuatro opciones: 1. C.C, 2. T.I, 3. P.A 4. C.E
Numero de documento: Text input (Se ingresa el número de documento del
paciente)
Fecha de creación: Date chooser (Se ingresa la fecha en la que el paciente es
creado como criterio de búsqueda)
85
Nombres: Text output (Muestra en pantalla los Nombres del paciente)
Apellidos: Text output (Muestra en pantalla los Apellidos del paciente)
Número de identificación: Text output (Muestra en pantalla el código del
paciente)
Dirección: Text output (Muestra en pantalla la dirección del paciente)
Teléfono: Text output (Muestra en pantalla el teléfono del paciente)
Correo: Text output (Muestra en pantalla el correo del paciente)
Fecha de creación: Date chooser (Muestra en pantalla la fecha en la que el
usuario fue creado)
Checkbox: Checkbox (permite seleccionar registros para posteriormente
editarlos o eliminarlos)
Consultar: Button (Es el botón por el cual se puede consultar los datos de los
pacientes en un registro)
Editar: Button (Es el botón por el cual se puede editar los datos de pacientes en
un registro)
Eliminar: Button (Es el botón por el cual se puede eliminar registros de pacientes
en un registro)
Cerrar sesión: Button (Es el botón por el cual se cierra la sesión del perfil que
este activo)
Relación De interfaz Diagramas
Consulta de paciente DCU 4.1, DA 4.2, DA 4.3, DA 4.4, DC,
DE
86
Ilustración 42: Prototipo: Creación de citas
Cada vez que se inicie sesión se cargara las diferentes opciones para navegar
a través del software, al ingresar en creación de citas se cargara un formulario
para realizar dicha creación.
Código Cita: Text input (Se Ingresa el código de la cita)
Fecha de creación: Data chooser (Se elige la fecha en la cual se crea la cita)
Código Paciente: Text input (Se Ingresa el código del usuario para asignarle la
cita)
Fecha de la cita: Data chooser (Se elige la fechar en la cual será la cita)
Hora: Text input (Se Ingresa la hora de la cita)
Código usuario: Text input (Se Ingresa el código de la secretaria la cual creo la
cita)
87
Código psicólogo: Text input (Se Ingresa el código de la del psicólogo el cual
atenderá la cita)
Aceptar: Button (Es el botón por el cual se acepta que los datos de la cita fue
creada exitosamente)
Cancelar: Button (Es el botón por el cual se cancela la creación de la cita)
Cerrar sesión: Button (Es el botón por el cual se cierra la sesión del perfil que
este activo)
Relación De interfaz Diagramas
Creación de citas DCU 2.0, DA 2.1, DC, DE
Ilustración 43: Prototipo: consulta de cita
88
Para la Consulta de una cita se podrá realizara mediante dos criterios de
búsqueda la primera es el código y/o cedula de la cita y la segunda se puede
realizar por la fecha de creación de la cita, si la consulta es de un usuario valido
automáticamente cargara los registros o datos de la persona solicitante.
Código Cita: Text input (Se Consulta mediante el código de cita)
Código Usuario: Text output (Carga el código para la consulta)
Fecha: Data chooser (carga la fecha en la cual se creó la cita)
Fecha de la cita: Data chooser (carga la fecha en la que quedo definida la cita)
Hora: Text output (carga la hora en que se creó la cita)
Código Secretaria: Text output (Carga el código de la secretaria que creo la
cita
Código psicólogo: Text input (Carga el código del psicólogo al que s ele
asigno la cita)
Consultar: Button (Es el botón por el cual se puede consultar los datos de las
citas en un registro)
Editar: Button (Es el botón por el cual se puede editar los datos de una cita en
un registro)
Eliminar: Button (Es el botón por el cual se puede eliminar registros de citas en
un registro)
Cerrar sesión: Button (Es el botón por el cual se cierra la sesión del perfil que
este activo)
Relación De interfaz Diagramas
Consulta de citas DCU 2.1, DA 2.2, DA 2.3, DA 2.4, DC,
DE
89
Ilustración 44: Prototipo: Confirmar Datos Paciente
Para la Confirmación de usuario se realizara mediante la consulta del código
del paciente y si la búsqueda es válida se procede a confirmar que los datos
sean correctos.
Nombres: Text output (Muestra en pantalla los nombres del paciente)
Apellidos: Text output (Muestra en pantalla los apellidos del paciente)
Número de identificación: Text output (Muestra en pantalla el código del
paciente)
Dirección: Text output (Muestra en pantalla la dirección del paciente)
Correo: Text output (Muestra en pantalla el correo electronico del paciente)
Teléfono Text output (Muestra en pantalla el teléfono del paciente)
Editar: Button (Es el botón por el cual se puede editar los datos de un paciente
en un registro)
90
Confirmar: Button (Es el botón por el cual se acepta que los datos confirmados
son correctos
Cerrar sesión: Button (Es el botón por el cual se cierra la sesión del perfil que
este activo)
Relación De interfaz Diagramas
Confirmación de información DCU 3.0, DA 3.1,DC, DE
Ilustración 45: Prototipo: Informar cita
Para Generar información sobre una cita, se debe primer confirmar los datos del
paciente y si la búsqueda es válida se procede a darle la información al paciente
mediante el medio que se indique.
Segundo Nombre: Text output (Se confirma el segundo nombre del usuario)
Primer Apellido: Text output (Se confirma el primer Apellido del usuario)
Fecha de la cita: Data chooser (carga la fecha en la que quedo definida la cita)
91
Hora: Text output (carga la hora en que se creó la cita)
Nombre del usuario: Text output (Carga el Nombre de la secretaria que creo la
cita.
Nombre psicólogo: Text input (Carga el código del psicólogo al que se le asignó
la cita)
Mensaje: Button (Con este botón se informara acerca de la cita mediante un
mensaje)
Correo: Button (Con este botón se informara acerca de la cita mediante un
Correo)
Imprimir: Button (Con este botón se informara acerca de la cita mediante una
impresión)
Cancelar: Button (Es el botón por el cual se cancela la generación de
inforamcion)
Cerrar sesión: Button (Es el botón por el cual se cierra la sesión del perfil que
este activo)
Relación De interfaz Diagramas
Generación de información DCU 3.1, DA 3.2, DC, DE
92
8. PRESENTACIÓN Y ANÁLISIS DE LOS RESULTADOS OBTENIDOS
La universidad debe cumplir con su misión y su nota característica de ser
investigativa de ser científica, la investigación formativa para que alcance su
misión en el programa de enseñanza aprendizaje debe estar integrada y
desprenderse de la capacidad de investigación y de la experiencia científica al
interior de la institución. El concepto de investigación formativa adquiere sentido
y relevancia en los pregrados e incluso en los niveles de especialización, dado
que se requiere la formación de competencias para emplear el método científico
y la capacidad de preguntar como el sistema de aprendizaje y de
autoconstrucción más adecuado.
La investigación formativa se usa para referirse a la capacidad que deben
adquirir los estudiantes y profesores para emplear los métodos de investigación
como estrategia de enseñanza aprendizaje. Se emplea en el sistema educativo
y en particular en las universidades como recurso didáctico (aunque ella misma
logra trascender lo didáctico), le permite al estudiante hacer la reconstrucción de
los saberes por medio de la formulación de preguntas y elaboración de referentes
teóricos para ampliar la apropiación adecuada de contenidos disciplinares. (Jaime
Montoya Ferrer,Luis Eduardo Peláez Valencia, 2013)
9. RESULTADOS OBTENIDOS DESDE LA INVESTIGACIÓN
FORMATIVA
Desde lo pedagógico surge el interrogante en el problema docencia, aquí el
aprendizaje es expositivo dirigido por el maestro y el contenido o un aprendizaje
por descubrimiento basado en el alumno y en la construcción del conocimiento.
En cuanto al problema docencia como su nombre lo dice es dirigido por el
docente en 90% de la clase y de los contenidos, aquí el aprendizaje se da por
recepción del conocimiento, el aprendizaje se logró a largo alcance, porque se
hace con lógica y con contenidos organizados que son preparados por el
93
docente. Estos contenidos los recibe el estudiante y el docente debe tener un
amplio domino del tema a trabajar con el alumno.
Desde la investigación formativa se obtuvieron grandes resultados porque a
través de este proceso el estudiante reconstruyó y apropió de una manera activa
los conocimientos, tomando una situación problema y colocándola en un
contexto educativo. Con el acompañamiento de un docente investigador se
formularon preguntas, objetivos, metodologías y soluciones para responder de
una forma adecuada a la problemática y poder cumplir los objetivos de
aprendizaje que se trazaron en el principio.
Con esta metodología se creó una formación permanente de investigación que
creo un saber pedagógico, el cual ha sido documentado, validado y escrito.
9.1 RESULTADOS OBTENIDOS DESDE EL DESARROLLO
METODOLÓGICO
Se considera que el diseño es la parte más importante de un proyecto, el cual
abarca un conjunto de estructuras formales y no formales, tener un buen diseño
de investigación implica tener una investigación de calidad y resultados de
calidad que puedan impactar en la sociedad y en el mundo de la investigación.
Dentro del proyecto de software fue importante definir una metodología a seguir,
ya que de esta forma se pudo obtener grandes ventajas en el proceso de
investigación y construcción del proyecto, lo que se buscó con la metodología
aplicada es el detalle, corrección y control en cada etapa del desarrollo del
programa y de esta manera se pudo obtener un producto correcto y libre de
errores.
Todo partió de realizar el correcto levantamiento de los requerimientos que se
tenían por parte del cliente (CAPSI) esta fase tiene una gran importancia porque
es allí donde se define las entradas, salidas y reacciones a diferentes situaciones
del software a desarrollar y es fundamental para poder aumentar las garantías
de éxito del proyecto.
94
En esta etapa los prototipos cumplen una gran función, porque a partir de la
construcción de los mismos se utilizaron para verificar que los requerimientos
establecidos por los usuarios estuvieran correctamente incluidos, a partir de los
prototipos se pudo observar los comportamientos del software además de evitar
problemas posteriores de tiempo y esfuerzo.
A nivel de modelos se trabajó bajo los parámetros de procesos y datos,
permitiendo definir a través del modelo de procesos las actividades y actores que
cumplen e interactúan con un rol dentro del software, estos se encuentran
definidos mediante diagramas de casos de usos, diagramas de actividades,
diagrama de estados y diagrama de clases. En el modelo de datos se encuentra
la definición de la forma lógica de los datos procesados por el sistema, este
modelo debió contar con los requerimientos y la situación problema bien
definidos para su correcto desarrollo. Se elaboró bajo los siguientes conceptos:
modelo conceptual, modelo entidad-relación, modelo de clases, modelo
relacional, modelo relacional: Metadatos, modelo relacional: Registros (Tuplas)
y diccionario de datos.
9.2 RESULTADOS OBTENIDOS PARA EL CAPSI
Para él profesor del Centro de atención Psicológica (Iodice, 2016) Lo primero que
se está brindando al CAPSI es la posibilidad de sistematizar la información
logrando tener un estándar de almacenamiento de los datos, aquí es
fundamental que no se viera soló desde el proceso de creación de una base de
datos, sino desde la sistematización de la información clínica o de la salud, este
aspecto se considera muy importante y valioso, producido por la creación de este
software, porque al tener informaciones estandarizadas permiten hacer toda
una serie de inferencias sobre la población que pasa por el CAPSI.
Tener conocimiento sobre la población que es atendida en el CAPSI permite
planificar intervenciones basadas en la investigación, por ejemplo a lo largo de
un año, pasan por el CAPSI una población infantil que se aproximan a las mil
personas, si se tuviera la posibilidad de intervenir en estas mil personas y
95
poderlas describir y caracterizarlas a nivel poblacional sería un gran logro. Y es
por medio de estas investigaciones que estas soluciones son objetivas, reales y
aplicables.
A partir de la culminación de este proyecto el CAPSI contara con toda la
investigación que se realizó para dar solución al proceso de citas, el cual se
desarrolla en el interior de sus instalaciones, además contara con la debida
metodología que se aplicó para garantizar el éxito de las necesidades que se
plantearon desde un principio, abordando la situación problemática de una forma
profesional y dando solución mediante modelos que permitirán que el desarrollo
del prototipo final se pueda codificar correctamente.
9.3 CONCLUSIONES Y RECOMENDACIONES
96
La metodología estructurada que se desarrolló dentro en el proyecto permitió
tomar el modelo (Conceptual, lógico y físico) del sistema, para trabajar cada
uno en pequeños módulos de manera individual y de una forma coherente y
así finalmente poder unir los resultados para obtener el prototipo que permitirá
definir el funcionamiento del proceso de asignación de citas en el CAPSI de
la UCP.
Desde la Ingeniería de Software, se hace necesario reconocer que abordar el
Desarrollo con la implementación ordenada y sistemática de buenas prácticas,
necesariamente llevará a obtener un proceso más apropiado por parte de los
participantes y un producto de mejor calidad que satisfaga las necesidades.
Se le da altura a un proceso de gestión y desarrollo que tradicionalmente ha
sufrido estigmas por su manera distraída e indiferente con la que ha sido
abordado
A través de la construcción del prototipo se pudo verificar que los
requerimientos establecidos están correctamente incluidos, de allí parte la
importancia de definir de una forma adecuada desde el inicio del proyecto los
requerimientos tal cual como lo describe (Pressman, 2010) quien considera que
los requerimientos “llevarán a la comprensión de cuál será el efecto que tendrá
el software en el negocio, qué es lo que quiere el cliente y cómo interactuarán
los usuarios finales con el software.” (pag.101). y así poder observar los
comportamientos del software evitando problemas posteriores de tiempo y
esfuerzo.
Para el CAPSI es importante poder fomentar la interdisciplinariedad entre
carreras, por ejemplo la comunicación que debe existir entre la psicología y la
ingeniería; para la psicología es importante poder contar con el soporte de la
ingeniería para optimizar su procedimientos y así poder prestar una mejor
atención a sus usuarios, para ello es relevante que los procesos de
investigación internos de la UCP sean también vinculados a las diferentes
problemáticas que enfrentan diariamente algunas áreas como el Centro de
97
Atención Psicológico de la universidad por no contar con metodologías de
sistematización adecuados de la información.
Respecto a los resultados logrados y los conceptos trabajados durante el
desarrollo del proyecto, se logra consolidar todo un proceso de información el
cual servirá de soporte para la que la línea de formación investigativa de
estudiantes de la UCP del área de sistemas, pueda dar continuidad al trabajo
y hacerlo real.
Desde la dirección del CAPSI se recomienda dar continuidad, donde se
garantice el seguimiento del proyecto vinculando nuevos estudiantes para el
desarrollo de las fases posteriores y así generar un producto final.
98
10. BIBLIOGRAFÍA
GÁLVEZ BOTERO, J. G., & CÓRDOBA RAMÍREZ, J. (2009). CAPSOFT (Centro
de Atención Psicológica Software). SISTEMA DE INFORMACIÓN PARA LA
GESTIÓN DE LA INFORMACIÓN, 1-20.
Hospital Universitario San Ignacio. (24 de 06 de 2010). Hospital Universitario San
Ignacio. Recuperado el 24 de 10 de 2015, de
http://www.husi.org.co/visitantes-y-pacientes/historia-clinica
IEEE. (2010). Guia al cuerpo de conocimiento d ela ingenieria. SWEBOK.
Iodice, R. (12 de 11 de 2016). Resultado obtenidos para el CAPSI. (G. A. Vasquez,
Entrevistador)
Jaime Montoya Ferrer,Luis Eduardo Peláez Valencia. (2013). Investigación
Formativa e Investigación en Sentido Estricto: una Reflexión para
Diferenciar su Aplicación en Instituciones de Educación Superior-. Pereira:
Entre Ciencia e Ingeniería.
Karl Wiegers, J. B. (2013). Software Requirements. Washington: Microsoft Press.
Kendall, K. E. (2005). Analisis y diseño de sistemas. Juarez: person Education.
Microsoft. (24 de 03 de 2007). Office. Recuperado el 24 de 10 de 2015, de
https://support.office.com/es-mx/article/Conceptos-b%C3%A1sicos-sobre-
bases-de-datos-a849ac16-07c7-4a31-9948-3c8c94a7c204
Microsoft. (28 de 3 de 2012). TechNet. Recuperado el 21 de 10 de 2015, de
https://social.technet.microsoft.com/forums/es-ES/7dc2cf80-a6ad-4271-
b4db-a1e3edb946fb/-que-es-la-ingenieria-software-
Nieto, L., & Iodice, R. (2015). Centro de Atención Psicológica CAPSI. PEREIRA.
Pressman, R. S. (2010). Ingenieria del Software. Mexico: McGraw- HILL.
Semm, J. A. (1992). Analisis y Diseño de sistemas de información. Mexico:
McGRAW-HILL.
Silberschatz, A. (2006). FUNDAMENTOS DE BASES DE DATOS. McGRAW-HILL.
SOMMERVILLE, I. (2005). INGENIERIA DEL SOFTWARE. madrid: PEARSON
EDUCATION, S.A.
usr.code. (2010). Ciclo de vida del software. usr.code, 3-22.
Weitzenfeld, A. (2002). Ingenieria de Software Orientada a objetos. Exico: ITAM.