gonzalo andrÉs garcÍa vÁsquez

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


Apellido 1 TEXTO 26 Apellido 1 psicólogo

27


Teléfono 1 TEXTO 10 Teléfono 1 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)


Sistema:





Relación: Paciente


Nombre 1 TEXTO 26 Nombre 1 paciente


Apellido 1 TEXTO 26 Apellido 1 paciente


Teléfono 1 TEXTO 10 Teléfono 1 paciente


Cod_paciente TEXTO 5 Código del paciente

Dirección. TEXTO 40 Dirección del paciente

Tabla 3: Modelo Relacional: Metadatos (usuarios)


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


Nombre 1 TEXTO 26 Nombre 1 usuario


Apellido 1 TEXTO 26 Apellido 1 usuario


Teléfono 1 TEXTO 10 Teléfono 1 usuario


Cod_usuario TEXTO 5 Código del usuario

Dirección. TEXTO 40 Dirección del usuario

Tabla 4: Modelo Relacional: Metadatos (citas)


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


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


Tabla 5: Modelo Relacional: Metadatos (Gestiona)


Sistema:


Relación: Gestiona (Psicologos_Usuarios)


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)


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)


Codigo_citas TEXTO 10 Código de las citas

Codigo_Psicologo TEXTO 5 Código del psicólogo

Tabla 7: Modelo Relacional: Metadatos (Solicita)


Sistema:


Relación: Solicita (Pacientes_citas)



Codigo_pacientes TEXTO 26 Código del paciente

Tabla 8: Modelo Relacional: Metadatos (Programa)


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)



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)




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


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.


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.



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


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)





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


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.


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.



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




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”


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





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


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.


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.




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.




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”


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.



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


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


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



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.


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”


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)


Sistema:





Relación: Psicólogos.


Tarjeta profesional TEXTO 20 Tarjeta profesional psicólogo

69








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)


Sistema:





Relación: Paciente





70




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)


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






71



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)


Sistema:


Relación: Citas


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


Operaciones Tipo

Actualiza TEXTO

Cancela TEXTO

Crea TEXTO

Consulta TEXTO

Tabla 46: Documentación Diagrama de clases (Gestiona)


Sistema:


Relación: Gestiona (Psicologos_Usuarios)


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)


Sistema:


Relación: Citas del psicólogo (Psicologos_citas)



Codigo_Psicologo TEXTO 5 Código del psicólogo

Tabla 48: Documentación Diagrama de clases (solicita)


Sistema:


Relación: Solicita (Pacientes_citas)



Codigo_pacientes TEXTO 26 Código del paciente

74

Tabla 49: Documentación Diagrama de clases (Programa)


Sistema:


Relación: Programa (Usuarios_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)


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.


del usuario) contiene cuatro opciones: 1. C.C, 2. T.I, 3. P.A 4. C.E


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)


este activo)


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


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


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)


correctos y se puede crear el paciente)

Cancelar: Button (Es el botón por el cual se cancela la creación de un paciente)


este activo)


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.


del paciente) contiene cuatro opciones: 1. C.C, 2. T.I, 3. P.A 4. C.E


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)


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)


este activo)


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


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)


este activo)


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)


este activo)


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)


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


este activo)


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)


este activo)


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.

gonzalo andrÉs garcÍa vÁsquez

Documents