Post on 20-Jul-2022
SISTEMA DE INFORMACIÓN WEB PARA EL CONTROL DE
DATOS PSICOEDUCATIVOS DEL COLEGIO CARLOS CASTRO
SAAVEDRA
ANA MARÍA RAMÍREZ MUÑOZ
UNIVERSIDAD CATÓLICA DE PEREIRA
FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA
INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES
PEREIRA, RISARALDA
2019
SISTEMA DE INFORMACIÓN WEB PARA EL CONTROL DE
DATOS PSICOEDUCATIVOS DEL COLEGIO CARLOS CASTRO
SAAVEDRA
ANA MARÍA RAMÍREZ MUÑOZ
DIRECTOR DE PROYECTO
ANDRÉS FELIPE MONTOYA RIOS
INGENIERO DE SISTEMAS Y TELECOMUNICACIONES
UNIVERSIDAD CATÓLICA DE PEREIRA
FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA
INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES
PEREIRA, RISARALDA
2019
3
TABLA DE CONTENIDO
INTRODUCCIÓN .......................................................................................... 12
1 PLANTEAMIENTO DEL PROBLEMA ..................................................... 14
2 JUSTIFICACIÓN..................................................................................... 15
3 OBJETIVOS ........................................................................................... 17
3.1 OBJETIVO GENERAL ..................................................................... 17
3.2 OBJETIVOS ESPECÍFICOS ............................................................ 17
4 APORTE PRÁCTICO Y TEÓRICO ......................................................... 18
5 MARCO TEÓRICO ................................................................................. 19
5.1 ANTECEDENTES ............................................................................ 19
5.1.1 Diseño e implementación de un sistema de información para la
asignación de citas de consulta externa en las áreas de medicina
general, odontología y psicología. .......................................................... 19
5.1.2 Desarrollo de un sistema web de control de citas, para un
hospital del día. ...................................................................................... 19
5.2 MARCO CONCEPTUAL .................................................................. 20
5.2.1 Psicoeducación ......................................................................... 20
5.2.2 Sistema de Información ............................................................. 20
5.2.3 Software .................................................................................... 21
5.2.4 Requerimientos ......................................................................... 21
5.2.5 Diseño de Software ................................................................... 21
5.2.6 Lenguaje de programación ........................................................ 22
5.2.7 JavaScript ................................................................................. 22
5.2.8 Visual Studio Code .................................................................... 22
5.2.9 Node.js ...................................................................................... 22
5.2.10 Express ..................................................................................... 23
6 MODELO TEÓRICO ............................................................................... 24
6.1 INGENIERÍA DE SOFTWARE ......................................................... 24
6.2 UML (UNIFIED MODELING LANGUAGE) ...................................... 25
4
6.3 METODOLOGÍA EN CASCADA ...................................................... 26
6.4 ARQUITECTURA MODELO VISTA CONTROLADOR .................... 28
7 DESARROLLO DEL PROYECTO .......................................................... 29
7.1 ANÁLISIS Y REQUISITOS .............................................................. 29
7.1.1 Técnicas de elicitación .............................................................. 29
7.1.1.1 Tormenta de ideas ............................................................................................................. 30
7.1.1.2 Prototipo .................................................................................................................................. 31
7.1.2 Diagramas de Caso de Uso ...................................................... 35
7.1.3 Especificación de casos de uso ................................................ 38
7.1.4 Requerimientos ......................................................................... 71
7.2 DISEÑO ........................................................................................... 80
7.2.1 Modelo entidad relación ............................................................ 80
7.2.2 Modelo relacional ...................................................................... 81
7.2.2.1 Diccionario de Datos......................................................................................................... 82
7.2.3 Diagrama de Clases .................................................................. 86
7.2.4 Diagrama de Despliegue ........................................................... 91
7.2.5 Diagrama de Secuencia ............................................................ 93
7.3 DESARROLLO DEL SISTEMA ........................................................ 96
7.3.1 Resultados ................................................................................ 97
7.4 PRUEBAS ...................................................................................... 116
7.4.1 Diseño de caso de pruebas ..................................................... 116
8 RESULTADOS ..................................................................................... 126
9 CONCLUSIONES ................................................................................. 128
10 RECOMENDACIONES ......................................................................... 129
11 BIBLIOGRAFÍA ..................................................................................... 130
12 ANEXOS ............................................................................................... 132
5
TABLA DE ILUSTRACIONES
Ilustración 1. Proceso de Ingeniería de Software.......................................... 24
Ilustración 2. Lluvia de ideas ......................................................................... 30
Ilustración 3. Prototipo de pantalla 01. Pantalla principal .............................. 32
Ilustración 4. Prototipo de pantalla 02: Ingreso al sistema ............................ 32
Ilustración 5. Prototipo de pantalla 03: Perfil del psicoeducador ................... 33
Ilustración 6. Prototipo de pantalla 04: Agentamiento de cita ....................... 33
Ilustración 7. Prototipo de pantalla 05: Historial clínico ................................. 34
Ilustración 8. Prototipo de pantalla 06: Seguimiento ..................................... 34
Ilustración 9. Diagrama de caso de uso 01: Diagrama general .................... 36
Ilustración 10. Diagrama de caso de uso 02: Docente .................................. 37
Ilustración 11. Modelo entidad relación ......................................................... 80
Ilustración 12. Modelo relacional ................................................................... 81
Ilustración 13. Diagrama de clases 01 Alumno ............................................. 87
Ilustración 14. Diagrama de clase 02 Usuario .............................................. 87
Ilustración 15. Diagrama de clase 03 RemisiónInterna ................................. 88
Ilustración 16. Diagrama de clase 04. Compromiso ...................................... 88
Ilustración 17. Diagrama de clase 05. Seguimiento ...................................... 89
Ilustración 18. Diagrama de clase 06. Cita ................................................... 89
Ilustración 19. Diagrama de clase 07. RemisiónExterna ............................... 90
Ilustración 20. Diagrama de clase 08. Historial ............................................. 90
Ilustración 21. Diagrama de despliegue ........................................................ 92
Ilustración 22. Diagrama de secuencia 01: Crear Remisión interna ............. 93
Ilustración 23. Diagrama de secuencia 02: Crear Alumno ............................ 94
Ilustración 24. Diagrama de secuencia 03: Crear Compromiso .................... 95
Ilustración 25. Programas para la implementación ....................................... 96
Ilustración 26. Resultado 01: Vista principal ................................................. 97
Ilustración 27. Resultado 02: Iniciar sesión ................................................... 98
Ilustración 28. Resultado 03: Iniciar sesión sin campos ................................ 98
Ilustración 29. Resultado 04: Iniciar sesión con contraseña errónea ............ 99
Ilustración 30. Resultado 05: Perfil de psicoeducador .................................. 99
Ilustración 31. Resultado 06. Registro de historial clínico ........................... 100
Ilustración 32. Prueba 07: Alumno sin historial ........................................... 102
Ilustración 33. Resultado 8: Consulta de historial clínico ............................ 103
Ilustración 34. Prueba 08: Registro de compromiso ................................... 104
6
Ilustración 35. Prueba 09: Consulta de compromiso ................................... 105
Ilustración 36. Prueba 10: Registro de compromiso ................................... 106
Ilustración 37. Prueba 11: Consulta de seguimiento ................................... 107
Ilustración 38. Prueba 12: Registro de remisiones externa ......................... 108
Ilustración 39. Prueba 13: Consulta de remisión externa ............................ 109
Ilustración 40. Prueba 14: Registro de alumno ........................................... 110
Ilustración 41. Prueba 15: reportes de docentes ........................................ 111
Ilustración 42. Prueba 16: Generar cita ...................................................... 112
Ilustración 43. Prueba 17: Consulta cita ..................................................... 113
Ilustración 44.Prueba 18: Perfil docente ..................................................... 115
Ilustración 45. Acta de finalización del proyecto. ........................................ 132
7
LISTA DE TABLAS
Tabla 1. Especificación de caso de uso 01: Autenticar usuario .................... 38
Tabla 2.Especificacion de caso de uso 02: Gestión de cuentas ................... 39
Tabla 3. Especificación de caso de uso 03: Gestión de cuentas II ............... 40
Tabla 4.Especificacion de caso de uso 04: Gestión de cuentas-modificar ... 41
Tabla 5. Especificación de caso de uso 05: Crear -Generar Historial ........... 42
Tabla 6. Especificación de caso de uso 06: Consultar -Generar Historial .... 43
Tabla 7. Especificación de caso de uso 07: Modificar -Generar Historial ..... 45
Tabla 8. Especificación de caso de uso 08: Crear agendamiento ................ 47
Tabla 9. Especificación de caso de uso 09: Consultar cita ........................... 48
Tabla 10.. Especificación de caso de uso 10: Remitir alumno ...................... 49
Tabla 11. . Especificación de caso de uso 11: Consultar remisión .............. 51
Tabla 12.Especificación de caso de uso 12: Modificar remisiones ............... 52
Tabla 13. Especificación de caso de uso 13: Registrar compromisos .......... 53
Tabla 14. Especificación de caso de uso 14: Consultar compromisos ......... 55
Tabla 15. Especificación de caso de uso 15: Modificar compromiso ............ 56
Tabla 16. Especificación de caso de uso 16: Registrar seguimiento ............ 58
Tabla 17. Especificación de caso de uso 17: Consultar seguimiento ........... 59
Tabla 18. Especificación de caso de uso 18: Modificar seguimiento ............ 60
Tabla 19. . Especificación de caso de uso 19: Remisión externa ................. 62
Tabla 20. Especificación de caso de uso 20: Consultar remisiones externas
...................................................................................................................... 63
Tabla 21. Especificación de caso de uso 21: Modificar remisión externa ..... 65
Tabla 22. Especificación de caso de uso 22: Registrar alumno .................... 66
Tabla 23. Especificación de caso de uso 23: Consultar reportes ................. 68
Tabla 24. Especificación de caso de uso 24: Consultar reportes-docente .... 69
Tabla 25 . Requerimiento 01. Autenticar Usuario ......................................... 72
Tabla 26. Requerimiento 03: Perfil de usuarios ............................................ 72
Tabla 27. Requerimiento 04: Crud de usuario .............................................. 73
Tabla 28. Requerimiento 04: Remisión interna ............................................. 73
Tabla 29. Requerimiento 05: Motivo de remisión .......................................... 74
Tabla 30. Requerimiento 06: Prioridad de cita .............................................. 74
Tabla 31. Requerimiento 07: Agendmiendo .................................................. 75
Tabla 32. Requerimiento 08: Seguimiento del alumno ................................. 75
Tabla 33. Requerimiento 09: Consulta de seguimiento (docente) ................ 76
Tabla 34. Requerimiento 10. Remisión externa ............................................ 76
8
Tabla 35. Requerimiento 11: Compromiso de alumno .................................. 77
Tabla 36. Requerimiento 12: Reportes de docente....................................... 77
Tabla 37. Requerimiento 13: Reportes de motivo ......................................... 78
Tabla 38. Requerimiento 14: Generar historial clínico .................................. 78
Tabla 39. Requerimiento No funcional 1. Disponibilidad ............................... 79
Tabla 40. Diccionario de datos: Tabla usuarios ............................................ 82
Tabla 41. Diccionario de datos: Tabla alumno .............................................. 82
Tabla 42. Diccionario de datos: Tabla remisiones ....................................... 83
Tabla 43. Diccionario de datos: Tabla seguimientos ..................................... 83
Tabla 44. Diccionario de datos: Tabla historial ............................................. 84
Tabla 45. Diccionario de datos: Tabla compromisos .................................... 84
Tabla 46. Diccionario de datos: Tabla citas .................................................. 85
Tabla 47. Diccionario de datos: Tabla remisiones internas ........................... 85
Tabla 48. Prueba 01: Validar campos ......................................................... 117
Tabla 49. Prueba 02: Autenticar usuario invalido........................................ 117
Tabla 50. Prueba 03: Ingreso erróneo al sistema ....................................... 118
Tabla 51. Prueba 04: Ingreso valido al sistema .......................................... 118
Tabla 52. Prueba 05: Registro de usuario erróneo ..................................... 118
Tabla 53. Prueba 06: Registro valido de un nuevo usuario ........................ 119
Tabla 54. Prueba 07: Crear historial con datos validos ............................... 119
Tabla 55. Prueba 08: Agenda de cita .......................................................... 119
Tabla 56. Prueba 09: Validar agenda ......................................................... 120
Tabla 57. Prueba 10: Valida agenda disponible.......................................... 120
Tabla 58. Prueba 11: Validar modificación de historial ............................... 120
Tabla 59. Prueba 12: Validar los campos del historial ................................ 121
Tabla 60. Prueba 13: Validar la consulta de historial .................................. 121
Tabla 61. Prueba 14: Validar consulta de historial erróneo ........................ 121
Tabla 62. Prueba 15: Validar compromiso .................................................. 122
Tabla 63. Prueba 16: Validar registro de compromiso correcto .................. 122
Tabla 64. Prueba 17: Modificar compromiso .............................................. 122
Tabla 65. Prueba 18: Validar registro de seguimiento ................................ 123
Tabla 66. Pruebas 19: Verificar modificación de seguimiento .................... 123
Tabla 67. Prueba 20: Validación de remisión externa ................................. 123
Tabla 68. Prueba 21: Validar modificación de remisión externa ................. 124
Tabla 69. Prueba 22: Valida consulta de reportes-motivo .......................... 124
Tabla 70. Prueba 23: Validar reportes-docente .......................................... 124
Tabla 71. Prueba 24: Verificar reportes sin remisiones .............................. 125
9
ANEXOS
Anexos 1. Carta de finalización................................................................... 132
10
RESUMEN
Este proyecto se enfoca en la realización de un sistema de información web,
que se encarga del registro y control de los datos del departamento
psicoeducativo del colegio Carlos Castro Saavedra, para el desarrollo de
este proyecto, se tomó como referencia la metodología cascada que se
caracteriza por la definición de requerimientos, diseño del software y el del
sistema, implementación y pruebas de unidad , integración y pruebas del
sistema, operación y mantenimiento, dando como resultado un proyecto
ordenado rigurosamente en base al ciclo de vida del software.
Palabras claves: Ingeniería de software, Metodología cascada, MySQL,
Software, UML, JavaScript.
11
ABSTRACT
This project focuses on the realization of a web information system, which is
in charge of the registration and control of the data of the psychoeducational
department of the Carlos Castro Saavedra School, for the development of
this project, the cascade function is taken as a reference. Can by the
definition of the requirements, the design of the software and the system, the
implementation and the tests of unit, the integration and the tests of the
system, the operation and the maintenance, as a result of a project ordered
rigorously in the base of the cycle of software life.
Keywords: Cascade methodology, JavaScript, MySQL, Software, Software
engineering UML
12
INTRODUCCIÓN
La psicoeducación es una disciplina que actúa como apoyo educativo e
informativo para los diferentes trastornos psicológicos que sufren las
personas, este tipo de intervenciones que realiza dicha disciplina incluyen el
apoyo emocional, la resolución de problemas y otras técnicas que influyen de
forma positiva en el mejoramiento continuo de la psicoeducación propia.
Durante la fase académica de la psicoeducación, los profesionales hacen un
proceso de formación que incluye identificar la patología del paciente y así
definir un tratamiento acompañado de seguimientos y controles previos,
estos procesos deben ser almacenados cuidadosamente para tener
constancia y control de cada acompañamiento en caso de que se pueda
presentar algún inconveniente en el lugar donde se esté aplicando dichos
procesos.
Actualmente el colegio Carlos Castro Saavedra CCS cuenta con un
departamento de psicoeducación donde solo hay un profesional en el área
de apoyo psicoeducativo, el profesional realiza las terapias de los alumnos
de forma presencial, basándose en diagnosticar la patología por medio de
dialogo y demás pruebas para después proceder a utilizar técnicas más
apropiadas a su necesidad. Considerando que las terapias se hacen
presenciales requieren de un proceso largo de citación ya que se elaboran
de forma manual para los todos los alumnos que se encuentran registrados
en el colegio, dicha magnitud de alumnos para un solo psicoeducador ha
generado una alta operatividad de información y una exhaustiva remisión al
departamento de psiceducación.
Por lo tanto, se tomó la decisión de desarrollar un sistema de información
web con el propósito de agilizar y controlar los procesos de remisión,
13
citación y registro, incluso permitirá mitigar riesgos de pérdida de información
al controlar los registros por medio de una base de datos.
14
PLANTEAMIENTO DEL PROBLEMA
El Colegio Carlos Castro Saavedra actualmente está conformado por 1
psicoeducador, 40 docentes y 1200 alumnos donde existe un promedio de 10
alumnos remitidos en un (1) día por los docentes al departamento de
psicoeducación, los procesos se realizan de forma manual como por ejemplo,
diligenciar formatos a mano, tabular información en un archivo en Excel,
clasificar los documentos físicos para poder archivarlos, custodiar los
documentos y actualizar la información en el archivo de Excel y Word cada
vez que se cita un nuevo alumno.
Otra problemática que se presenta al realizar el proceso manual es que el
psicoeducador recibe información de diferentes docentes y debe leer todos
los casos para iniciar las citaciones y darle una prioridad alta, media o baja a
cada alumno ya que se generan problemáticas que requieren mayor cuidado
como sospechas de suicidio, abuso sexual, maltrato infantil, entre otras, esto
implica invertir mayor tiempo a la hora de dar prioridad a algún alumno.
Adicionalmente, existe el riesgo de que se presente eventos catastróficos
con algún alumno antes que el psicoeducador pueda revisar el caso
expuesto y pueda dar una prioridad.
También se identificó lo difícil que es consultar la información para su
respectivo seguimiento ya que en los archivo de Excel y Word se tabulan la
información general, quedando en el documento físico los datos al detalle,
esto hace que sea muy difícil tener una trazabilidad de los casos de los
alumnos que han sido remitidos.
15
JUSTIFICACIÓN
La psicoeducación es de gran importancia en la comunidad estudiantil,
entendida como los actores sociales que intervienen en el proceso de
enseñanza-aprendizaje como es la familia del alumno, los profesores,
directivos de la Institución, y el consejo escolar, entre otros., en la cual se
pretende llevar un proceso que pueda beneficiar a toda la comunidad, pues
se debe tener en cuenta que en todo ambiente estudiantil hay escenarios,
situaciones y contextos en el cual los alumnos se desarrollan e interactúan,
introyectando así contextos que afectan el bienestar de toda la comunidad
escolar, familiar y hasta social, esto, puede llevar a ocasionar sucesos no
deseados en la comunidad estudiantil.
Para este proceso se debe realizar una remisión de los alumnos bajo los
parámetros que establece la institución, es decir siendo los docentes,
quienes realizan la remisión ya que son las personas que tienen constante
interacción con el alumno y pueden observar su comportamiento, remitiendo
así a segunda instancia el caso al psicoeducador. El psicoeducador debe
custodiar todas las remisiones que ingresan diariamente, para generar una
prioridad y así asignar la cita a cada alumno. Todos estos procesos generan
gran contenido de información que se registra de manera manual en
formatos tipo Word o Excel.
La forma como se realiza actualmente el proceso genera una problemática
delicada ya que no existe una herramienta que permita priorizar las citas de
los alumnos remitidos, poniendo en riesgo su desarrollo y en algunas
ocasiones puede estar en riesgo su propia vida.
16
Dado lo anterior, el aporte en la mejora del proceso consiste en automatizar
el sistema de información para identificar a tiempo situaciones que ameritan
atención inmediata y prioritaria y con ello ayudar al psicoeducador
responsable del proceso en la mejora en los tiempos de atención y en el
logro de resultados positivos para todos los que intervienen en el proceso.
Adicionalmente esta mejora también ayudará a cumplir con un seguimiento
mucho más ágil, eliminando operatividad por las labores manuales y así
evitar el uso de documentos físicos.
17
OBJETIVOS
1.1 Objetivo General
Desarrollar un sistema de información web para el manejo de datos del
departamento psicoeducativo del Colegio Carlos Castro Saavedra.
1.2 Objetivos Específicos
● Elicitar los requerimientos del departamento psicoeducativo
● Diseñar el sistema de información web
● Implementar el sistema de información de acuerdo al diseño y
requerimientos del cliente
● Realizar las pruebas del sistema de información web
18
APORTE PRÁCTICO Y TEÓRICO
El aporte que brinda la implementación del sistema de información web en el
colegio Carlos castro Saavedra es que permite a los docentes priorizar y
agilizar los procesos de remisión al departamento de psicoeducación ya que
podrán ingresar al aplicativo y realizar las remisión directamente desde
cualquier dispositivo que tenga conexión a internet, con ello, se logrará crear
alertas que permiten mejorar los tiempos de respuesta, haciendo una
priorización de las citas de acuerdo a la complejidad del caso.
Adicional a lo anterior, los alumnos también serán beneficiados con este
proyecto al tener la oportunidad de ser atendidos por el departamento de
psicoeducacion con una ejecución mucho más rápida, ya que cada alumno
requiere de una atención diferente y en algunos casos una
atención prioritaria, la cual si no se procede de una manera oportuna
podría ocasionar acontecimientos graves para la institución al no haber
ejecutado un proceso rápido o efectivo. El actuar a tiempo y de acuerdo a la
prioridad puede prevenir sucesos catastróficos.
19
MARCO TEÓRICO
1.3 ANTECEDENTES
Investigando proyectos que incluyen métodos de análisis y desarrollo de
software basados en asignación de citas, se encontraron proyectos
planteados por diferentes autores que logran ser de utilidad para cumplir con
los objetivos del sistema de información web. Se encontraron los siguientes
proyectos:
1.3.1 Diseño e implementación de un sistema de información para la
asignación de citas de consulta externa en las áreas de medicina
general, odontología y psicología.
Este desarrollo web tiene como objetivo diseñar y desarrollar un Sistema de
Información basada a la prestación de servicios en el área de consulta
externa y principal función es generar el historial clínico de cada paciente que
ingresan al hospital para permitir una atención continua con su respectiva
información almacenada. [1]
La similitud del proyecto con este software se encuentra en los procesos y
módulos de asignación de citas e historial clínico, permitiendo ser de gran
apoyo en el análisis logrando hacer un seguimiento apto para mejorar el
control de información y darle un respectivo orden.
1.3.2 Desarrollo de un sistema web de control de citas, para un hospital del día.
Hoy en día las instituciones manejan cantidades de información exorbitante,
los hospitales y los colegios no se quedan atrás. Estos interactúan con una
gran cantidad de personas diariamente. La seguridad y legitimidad de esta
20
información es esencial en cualquiera de estas instituciones por lo cual hoy
en día es imprescindible que los archivos cuenten con servicios informáticos.
Las historias clínicas que es un documento final que se realiza después de
las consultas médicas no se quedan atrás en la cantidad de información que
generan. El sistema web de control de citas, para un hospital del día sirven
como apoyo para el diseño de los modulo historial clínico y asignación de
citas que requiere el departamento de psicología del colegio C.C.S [2].
1.4 MARCO CONCEPTUAL
1.4.1 Psicoeducación
Hace referencia a la educación o información que se ofrece a las personas
que sufren de un trastorno psicológico, aunque este tipo de intervenciones
psicológicas también incluyen el apoyo emocional, la resolución de
problemas y otras técnicas. A menudo, el entrenamiento psicoeducativo
involucra a los pacientes con esquizofrenia, depresión, ansiedad, psicosis,
desórdenes alimenticios y trastornos de personalidad.
1.4.2 Sistema de Información
Los sistemas de información son un conjunto de componentes
interrelacionados que recolectan, recuperan, procesan almacenan y
distribuyen información para apoyar la toma de decisiones y el control de una
organización. Además de apoyar la toma de decisiones, la coordinación y el
control, los sistemas de información también pueden ayudar a los gerentes y
trabajadores del conocimiento a analizar problemas, visualizar temas
complejos y crear nuevos productos [3].
21
1.4.3 Software
Programas de cómputo y documentación asociada. Los productos de
software se desarrollan para un cliente en particular o para un mercado en
general. El software tiene como naturaleza un papel dual, ya que es un
producto y al mismo tiempo es el vehículo para entregar un producto. En su
forma de producto, brinda el potencial de cómputo incorporado en el
hardware de cómputo o, con más amplitud, una red de computadoras a las
que se accede por medio de un hardware local. Ya sea que resida de un
teléfono móvil u opere en el interior de una computadora central, e software
es un transformador de información- produce, administra, adquiere, modifica,
despliega o transmite información que puede ser tan simple como un solo bit
o tan compleja como una representación con multimedios generada a partir
de datos obtenidos de decenas de fuentes independientes. [4]
1.4.4 Requerimientos
Los requerimientos para un sistema son descripciones de lo que el sistema
debe hacer, el servicio que ofrece y las restricciones en su operación. Tales
requerimientos reflejan las necesidades de los clientes por un sistema que
atienda cierto propósito. Como seria controlar un dispositivo, colocar un
pedido o buscar una información.
1.4.5 Diseño de Software
El diseño de software crea una presentación o modelo de software, pero, a
diferencia del modelo de requerimientos (que se centra en describir los datos
que se necesitan, la función y el comportamiento), el modelado de diseño
proporciona detalles sobre arquitectura del software, estructura de datos,
interfaces y componentes que se necesiten para implementar el sistema. [4]
22
1.4.6 Lenguaje de programación
Un lenguaje de programación es un lenguaje diseñado para realizar procesos
que puede ser llevado a cabo por computadoras. Se pueden usar para crear
programas que controlen el comportamiento lógico y físico de una máquina.
Este se encuentra formado por un conjunto de símbolos y reglas, las cuales
definen su estructura, elementos y expresiones [5]
1.4.7 JavaScript
JavaScript es un lenguaje de programación que permite el script de eventos,
clases y acciones para el desarrollo de aplicaciones Internet entre el cliente y
el usuario. JavaScript permite con nuevos elementos dinámicos ir más allá de
clicar y esperar en una página Web. Los usuarios no leerán únicamente las
páginas sino que además las páginas ahora adquieren un carácter
interactivo. Esta interacción permite cambiar las páginas dentro de una
aplicación: poner botones, cuadros de texto, código para hacer una
calculadora, un editor de texto, un juego, o cualquier otra cosa que pueda
imaginarse [6].
1.4.8 Visual Studio Code
Es un editor de código fuente ligero pero potente que se ejecuta en su
escritorio y está disponible para Windows, macOS y Linux. Viene con soporte
incorporado para JavaScript, TypeScript y Node.js y tiene un rico ecosistema
de extensiones para otros idiomas (como C ++, C #, Java, Python, PHP, Go)
y tiempos de ejecución (como .NET y Unity) [7].
1.4.9 Node.js
Es un entorno de ejecución para JavaScript construido con en el motor de
JavaScript V8 de Chrome. Es una librería y entorno de ejecución de E/S
dirigida por eventos y por lo tanto asíncrona que se ejecuta sobre el
intérprete de JavaScrip. [8]
23
1.4.10 Express
Express, según sus creadores, es un framework de desarrollo de
aplicaciones web minimalista y flexible para Node.js". Está inspirado en
Sinatra, además es robusto, rápido, flexible y muy simple. Entre otras
características, ofrece Router de URL (Get, Post, Put ), facilidades para
motores de plantillas (Jade, EJS, JinJS ) [9].
24
MODELO TEÓRICO
1.5 INGENIERÍA DE SOFTWARE
La ingeniería de software es una tecnología con varias capas. Como se
aprecia en la figura 1.3, cualquier enfoque de ingeniería (incluso la de
software) debe basarse en un compromiso organizacional con la calidad.
Ilustración 1. Proceso de Ingeniería de Software
Fuente: Ingeniería de software un enfoque práctico.7ed. Pressman.
El proceso define una estructura que debe establecerse para la obtención
eficaz de tecnología de ingeniería de software. El proceso de software forma
la base para el control de la administración de proyectos de software, y
establece el contexto en el que se aplican métodos técnicos, se generan
productos del trabajo (modelos, documentos, datos, reportes, formatos, etc.),
se establecen puntos de referencia, se asegura la calidad y se administra el
cambio de manera apropiada.
Los métodos de la ingeniería de software proporcionan la experiencia
técnica para elaborar software. Incluyen un conjunto amplio de tareas, como
comunicación, análisis de los requerimientos, modelación del diseño,
construcción del programa, pruebas y apoyo. Los métodos de la ingeniería
25
de software se basan en un conjunto de principios fundamentales que
gobiernan cada área de la tecnología e incluyen actividades de modelación y
otras técnicas descriptivas.
Las herramientas de la ingeniería de software proporcionan un apoyo
automatizado o semiautomatizado para el proceso y los métodos. Cuando se
integran las herramientas de modo que la información creada por una pueda
ser utilizada por otra, queda establecido un sistema llamado ingeniería de
software asistido por computadora que apoya el desarrollo de software [10].
En la actualidad se puede percibir de una manera concisa, como los
sistemas de información (software) se han vuelto la herramienta más
elemental para el control, administración y supervisión de la información,
logrando así poder tomar decisiones estratégicas en cualquier entidad,
empresa, universidad, etc... Esta dependencia a los Sistemas de información
genera que se incorpore un Software de calidad y compromete a que los
Ingenieros, analistas y desarrolladores adopten un enfoque sistemático y
organizado mediante la Ingeniería de Software.
1.6 UML (UNIFIED MODELING LANGUAGE)
El lenguaje Unificado de Modelado fue creado para forjar un lenguaje de
modelado visual común, semántico y sintácticamente rico para la
arquitectura, el diseño y la implementación de sistema de software
complejos, tanto en estructura como en comportamiento. UML tiene
aplicaciones más allá del desarrollo de software, por. ej., en el flujo de
procesos de la fabricación.
26
Es comparado a los planos usados en otros campos y consiste en diferentes
tipos de diagramas. En general, los diagramas UML describen los límites, la
estructura, el comportamiento del sistema y los objetivos que contiene [11].
Basándose en el diseño de comportamiento y diseño de estructura que
brinda UML mediante los diagramas que ofrece para forjar un diseño
adecuado en la elaboración de un software, se incorporan los siguientes
diagramas: diagrama de casos de uso, diagrama de despliegue, diagrama de
clase y diagrama de secuencia.
1.7 METODOLOGÍA EN CASCADA
El modelo cascada es considerado como el enfoque clásico que ordena
rigurosamente las etapas de ciclo de vida de un desarrollo de software, de tal
forma que el inicio de cada etapa debe esperar la finalización de la etapa
anterior.
En el 2005 Sommerville, propuso que las principales etapas del modelo en
cascada se transforman en 5 actividades fundamentales de desarrollo, las
cuales son:
1. Análisis y definición de requerimientos. Los servicios, restricciones y
metas del sistema se definen a partir de las consultas con los usuarios.
Entonces, se definen en detalle y sirven como una especificación del
sistema.
2. Diseño del sistema y software. El diseño del sistema divide los
requerimientos en sistema hardware o software. Establece una
arquitectura completa del sistema. El diseño del software identifica y
describe las abstracciones fundamentales del sistema de software y sus
relaciones.
27
3. Implementación y prueba de unidades: Durante esta etapa, el diseño del
software se lleva a cabo como un conjunto o unidades de programas. La
prueba de unidades implica verificar que cada una cumpla su
especificación.
4. Integración y prueba del sistema. Los programas o las unidades
individuales de programas se integran y prueban como un sistema
completo para asegurar que se cumplan los requerimientos del software.
Después de las pruebas, el sistema software se entrega al cliente.
5. Funcionamiento y mantenimiento. Por lo general (aunque no
necesariamente), está es la fase más larga del ciclo de vida. El sistema
se instala y se pone en funcionamiento práctico. El mantenimiento implica
corregir errores no descubiertos en las etapas anteriores del ciclo de vida,
mejorar la implementación de las unidades del sistema y resaltar los
servicios del sistema una vez que se descubran nuevos requerimientos
[10].
En principio, el resultado de cada fase es uno o más documentos aprobados
(<firmados>). La siguiente fase no debe empezar hasta que la fase previa
haya finalizado. En la práctica, estas etapas se superponen y proporcionan
información a las otras. Durante el diseño se identifican los requerimientos;
durante el diseño del cogido se encuentran problemas, y así sucesivamente.
El proceso del software no es un modelo lineal simple, sino que implica una
serie de iteraciones de las actividades de desarrollo.
28
1.8 ARQUITECTURA MODELO VISTA CONTROLADOR
Modelo vista controlador MVC es un estilo de arquitectura de software que
separa los datos de una aplicación, la interfaz de usuario, y la lógica de
controles en tres componentes distintos.
El modelo que contiene una representación de los datos que maneja el
sistema, su lógica de negocio y sus mecanismos de persistencia.
La vista, o interfaz de usuario, que componen la información que se envía al
cliente y los mecanismos que interaccionan con este.
El controlador, que actúa como intermediario entre el modelo y la vista,
gestionando el flujo de información entre ellos y las transformaciones para
adaptar los datos a las necesidades de cada uno. [12]
29
DESARROLLO DEL PROYECTO
1.9 ANÁLISIS Y REQUISITOS
Las personas cotidianas que requieren software muchas veces no logran
comprender bien que es lo que quieren que realice el sistema y en otras
ocasiones no saben expresar o definir muy bien sus necesidades, a partir de
allí se desprende la necesidad de realizar una captura adecuada de las
funcionalidades que debe realizar el sistema, para así convertirse en los
requerimientos que serán la base de los objetivos a emplear.
Para poder adquirir la información necesaria y un mejor entendimiento de los
mismos se opta por incluir técnicas de elicitación que concluyan
adecuadamente lo que el usuario desea y así se pueda prescindir
acontecimientos que quizás puedan afectar los procesos de desarrollo e
implementación.
Como primer proceso que se realiza para generar los requerimientos se
vuelve un punto esencial y vital en la construcción el levantamiento de los
requerimientos ya que se debe de tener presente cuales son, porque a partir
de ellos, se realizaran las funciones que tendrá el software.
1.9.1 Técnicas de elicitación
Esta sección muestra la aplicación de dos técnicas de elicitación que se
hicieron junto con el cliente para poder comprender y captar las
funcionalidades que el sistema realiza. A partir del desarrollo de estas
actividades se pudieron concluir los requerimientos del sistema los cuales se
pueden encontrar en la sesión 7.1.4.
A continuación se muestras las técnicas que se implementaron en la
elicitación de los requerimientos.
30
1.9.1.1 Tormenta de ideas
Es una técnica que se basa en reuniones informales con el cliente, cuyo
objetivo es la generación de ideas en un ambiente libre de críticas o juicios.
Como técnica de recopilación de información de requerimientos, la tormenta
de ideas puede ayudar a generar una gran variedad de vistas del problema y
a formularlo de diferentes formas, sobre todo al comienzo del proceso
cuando todavía los requisitos están muy difusos.
Esta técnica se aplicó junto con dos funcionarios del C.C.S, los cuales
fueron: Cristian Fernán Muñoz (psicoeducador) y Luz Arango (rectora), se
realizaron tres reuniones informales donde cada uno expuso el
planteamiento del problema, los procesos que se hacen en el departamento
de psicoeducación y las necesidades deseadas como conclusión.
A partir de esta técnica se pudo recopilar este diagrama:
Ilustración 2. Lluvia de ideas
Fuente: Propia, realizado mediante el programa Canva
31
1.9.1.2 Prototipo
La segunda técnica que se aplicó fueron prototipos o mockups. Según [10],
un prototipo es una visión inicial de un sistema software el cual se usa para
demostrar conceptos, probar opciones de diseño y, generalmente encontrar
más problemas y soluciones posibles.
Los prototipos se emplean para proyectar una representación previa del
diseño del sistema mediante cualquier herramienta (programa, papel,
lápiz…etc.) Donde el cliente pueda trazar las interacciones que tendrán los
usuarios con el sistema.
Los prototipos que se muestran a continuación se realizaron con el
psicoeducador del C.C.S en dos reuniones dentro de la institución, dichos
prototipos no hacen referencia a que serán las verdaderas vistas del sistema,
más bien sirven de apoyo para reunir y comprender lo que el usuario
requiere.
Los siguientes prototipos que se muestran a continuación son las interfaces
que se implementaran en el sistema web, se realizaron a través de la
herramienta Wix la cual proporciona plantillas para el diseño de Blogs
gratuitos.
32
Ilustración 3. Prototipo de pantalla 01. Pantalla principal
Fuente: Propia, realizada mediante la plataforma Wix
Ilustración 4. Prototipo de pantalla 02: Ingreso al sistema
Fuente: Propia, realizada mediante la plataforma Wix
33
Ilustración 5. Prototipo de pantalla 03: Perfil del psicoeducador
Fuente: Propia, realizada mediante la plataforma Wix
Ilustración 6. Prototipo de pantalla 04: Agentamiento de cita
Fuente: Propia, realizada mediante la plataforma Wix
34
Ilustración 7. Prototipo de pantalla 05: Historial clínico
Fuente: Propia, realizada mediante la plataforma Wix
Ilustración 8. Prototipo de pantalla 06: Seguimiento
Fuente: Propia, realizada mediante la plataforma Wix
35
1.9.2 Diagramas de Caso de Uso
Un caso de uso representa las acciones de un sistema y las Interacciones
que tiene con el usuario. El usuario tiene una gran influencia en la
representación de estos, ya que dichos diagramas se basan en mostrar la
relacione entre las funciones del sistema (casos de uso) y del usuario (actor),
el cual varía dependiendo del rol asignado de cada uno.
Los casos de uso son una herramienta valiosa para las que personas del
común puedan entender dichas relaciones. .También se puede considerar
como una técnica eficaz para la obtención de los requerimientos.
Sommerville propone esas descripciones para los conceptos de: actor, caso
de uso.
● Actor: Un actor es una idealización de una persona externa, de un
proceso, o de una cosa que interactúa con un sistema. Un
subsistema, o una clase. Un actor caracteriza las interacciones que
los usuarios exteriores puedan tener con el sistema.
● Caso de uso: Es una entidad coherente de funcionalidad,
externamente visible, proporcionada por una unidad del sistema.
Los diagramas de casos de uso que se muestran a continuación son los
diagramas que se generaron a partir de la recopilación de información con el
cliente.
36
Ilustración 9. Diagrama de caso de uso 01: Diagrama general
Fuente: Elaboración propia, realizada mediante StarUML
37
Ilustración 10. Diagrama de caso de uso 02: Docente
Fuente: Elaboración propia, realizada mediante StarUML
38
1.9.3 Especificación de casos de uso
Tabla 1. Especificación de caso de uso 01: Autenticar usuario
ID EC-1
Nombre (CU) Autenticar usuario
Actor Psicoeducador, docente
Descripción El actor podrá ingresar al sistema en cualquier momento que desee
Precondición El actor debe estar registrado
Flujo normal
Respuesta del Usuario Respuesta del Sistema
1. El sistema muestra la interfaz de ingreso.
2. El actor ingresa el correo electrónico.
3. El actor ingresa la contraseña.
4. El actor oprime el botón “Iniciar”.
5. El sistema hace la validación de los campos de “usuario” y “contraseña”
6.El sistema valida si el usuario se encuentra registrado
Flujo alterno
5. El correo o la contraseña son incorrectos.
5.1 El sistema emite un mensaje “Completa este campo”, dando al usuario la oportunidad de volver al paso 2.
6. El usuario no se encuentra registrado
6.1 El sistema emite un mensaje “El usuario no existe”, dando la oportunidad de volver al paso 2.
Post condición El actor ingresa al sistema satisfactoriamente
Fuente: Material de clase, Ingeniería de Software II (UCP, 2018)
39
Tabla 2.Especificacion de caso de uso 02: Gestión de cuentas
ID EC-2
Nombre (CU) Gestión de cuentas
Actor Psicoeducador
Descripción El actor podrá crear un usuario en cualquier momento.
Precondición El actor debe haber ingresado al sistema (EC-1)
Flujo normal
Respuesta del Usuario Respuesta del Sistema
1+ El sistema muestra la vista principal
2. El actor oprime el botón “Registrar”
3. EL actor oprime el botón “Usuarios”.
4. El sistema se direcciona a la vista de “Registrar usuarios” .
5. El sistema muestra un formato para el registro del usuario.
6. El actor ingresa los datos en los text input del formato.
7. El actor oprime el botón “Registrar”.
8. El sistema valida los campos.
9. El sistema almacena el registro.
Flujo alterno
8.1 No se completan todos los campos.
8.1.1 El sistema muestra un mensaje en pantalla “Completa este campo”.
8.2 El usuario ya se encuentra registrado.
8.2.1 El sistema muestra un mensaje “El usuario ya existe”.
Post condición El sistema muestra un mensaje en pantalla “Se ha registrado el usuario (nombre)”
Fuente: Material de clase, Ingeniería de Software II (UCP, 2018)
40
Tabla 3. Especificación de caso de uso 03: Gestión de cuentas II
ID EC-3
Nombre (CU) Gestión de cuentas
Actor Psicoeducador
Descripción El actor podrá consultar usuarios en cualquier momento.
Precondición 1. El actor debe haber ingresado al sistema (EC-1)
2. El usuario que se modificara debe estar registrado (EC-2)
Flujo normal
Respuesta del Usuario Respuesta del Sistema
1+ El sistema muestra la vista principal.
2. El actor oprime el botón “Consultar”.
3. EL actor oprime el botón “Usuarios”.
4. El sistema se direcciona a la vista de “usuarios.
5. El sistema muestra todos los usuarios que están registrados.
5. El actor digita en el text input el apellido del alumno que desea consultar.
6. El sistema valida los alumnos.
7. El sistema muestra los Usuarios con dicho apellido.
Flujo alterno
6.1 No hay usuarios con ese apellido.
6.1.1 El sistema no muestra ningún usuario.
Post condición El actor visualizar exitosamente los Usuarios.
Fuente: Material de clase, Ingeniería de Software II (UCP, 2018)
41
Tabla 4.Especificacion de caso de uso 04: Gestión de cuentas-modificar
ID EC-4
Nombre (CU) Gestión de cuentas
Actor Psicoeducador
Descripción El actor podrá modificar usuarios en cualquier momento.
Precondición 1. El actor debe haber ingresado al sistema (EC-1)
2. El usuario que se modificara debe estar registrado (EC-2)
Flujo normal
Respuesta del Usuario Respuesta del Sistema
1+ El sistema muestra la vista principal.
2. El actor oprime el botón “Consultar”.
3. El actor oprime el botón “Usuarios”.
4. El sistema se direcciona a la vista de usuarios.
5. El sistema muestra todos los usuarios que están registrados.
6. El actor digita en el text input el apellido del alumno que desea modificar.
7. El sistema valida los alumnos
8. El sistema muestra los usuarios con ese apellido.
9. El actor oprime el botón “Editar.”
10. El sistema muestra la información del Usuario.
11. El actor modifica el campo que
deseé.
12. El actor oprime el botón “Actualizar”.
13. El sistema valida los campos
14. El sistema guarda la modificación
Flujo alterno
42
7. No hay usuarios con ese apellido.
7.1 El sistema no muestra ningún usuario.
13. Falta completar algún campo
13.1 El sistema muestra el mensaje “Complete este campo”
Post condición El sistema muestra un mensaje en pantalla “Se actualizo el usuario (nombre)”
Fuente: Material de clase, Ingeniería de Software II (UCP, 2018)
Tabla 5. Especificación de caso de uso 05: Crear -Generar Historial
ID EC-5
Nombre (CU) Generar Historial
Actor Psicoeducador
Descripción El actor podrá crear historiales clínicos de los alumnos
Precondición 1. El actor debe haber ingresado al sistema (EC-1) 2. El alumno debe estar registrado (EC-2)
Flujo normal
Respuesta del Usuario Respuesta del Sistema
1+ El sistema muestra la vista principal
2. El actor oprime el botón “Registrar”
3. El actor oprime el botón “Historial”.
4. El sistema se direcciona a la vista de “Registrar Historial Clínico”.
5. El sistema muestra un formato.
6.El sistema muestra los alumnos registrados
7. El actor digita en el text input el apellido del alumno que desea registrar el historial.
8. El sistema valida los alumnos con ese apellido
43
9.El sistema muestra los alumnos con ese apellido
10. El actor selecciona en el check-box-input el alumno que desee crearle el historial
11. El actor ingresa los datos en los text input del formato.
12. El actor oprime el botón “Guardar”.
13.El sistema valida que se haya seleccionado un alumno
14. El sistema valida los campos.
15. El sistema almacena el registro.
Flujo alterno
8.1 No existen alumnos con ese apellido
13.1 No se selecciona ningún alumno
13.1.1, El sistema muestra un mensaje en pantalla “Algo ocurrió en la creación del historial clínico”
14.1 No se completan todos los campos.
14.1.1 El sistema muestra un mensaje en pantalla “Completa este campo”.
Post condición Se muestra un mensaje en pantalla “El registro ha sido satisfactorio”.
Fuente: Material de clase, Ingeniería de Software II (UCP, 2018)
Tabla 6. Especificación de caso de uso 06: Consultar -Generar Historial
ID EC-6
Nombre (CU) Generar Historial
Actor Psicoeducador
Descripción El actor podrá consultar historiales clínicos de los alumnos.
44
Precondición 1. El actor debe haber ingresado al sistema (EC-1) 2. El alumno debe estar registrado (EC-2) 3. El alumno que se desea consultar debe tener al
menos 1 historial clínico. (EC-5)
Flujo normal
Respuesta del Usuario Respuesta del Sistema
1+ El sistema muestra la vista principal
2. El actor oprime el botón “Consultar”
3. El actor oprime el botón “Historial”.
4. El sistema se direcciona a la vista de “Buscar historial del alumno”.
5. El sistema muestra los alumnos registrado.
6. El actor ingresa en el text input el apellido del alumno que desee consultar.
7.El sistema valida los alumnos con ese apellido
8. El sistema muestra los alumnos con dicho apellido.
9. El actor selecciona en el check-box-input el alumno que desea consultar.
10.EL actor oprime el botón “Buscar”
11.El sistema valida que se haya seleccionado un alumno
12. El sistema consulta el historial clínico de ese alumno.
13. El sistema muestra en la vista el/los historiales de ese alumno.
Flujo alterno
7.1 No se encuentran alumnos con ese apellido
11.1 No se selecciona ningún alumno
11.1.1 El sistema muestra un mensaje en pantalla “Algo ocurrió en la consulta del historial”.
45
12.1 El alumno no tiene historial clínico.
12.1.2 El sistema muestra un mensaje en pantalla “El alumno no tiene ningún historial”
Post condición Se muestra un mensaje en pantalla “Este es el historial del alumno”.
Fuente: Material de clase, Ingeniería de Software II (UCP, 2018)
Tabla 7. Especificación de caso de uso 07: Modificar -Generar Historial
ID EC-7
Nombre (CU) Generar Historial
Actor Psicoeducador
Descripción El actor podrá modificar historiales clínicos de los alumnos.
Precondición 1. El actor debe haber ingresado al sistema (EC-1) 2. El alumno debe estar registrado (EC-2) 3. El alumno que se desea consultar debe tener al
menos 1 historial clínico. (EC-5)
Flujo normal
Respuesta del Usuario Respuesta del Sistema
1+ El sistema muestra la vista principal
2. El actor oprime el botón “Consultar”
3. E actor oprime el botón “Historial”.
4. El sistema se direcciona a la vista de “Buscar historial del alumno”
5.El sistema muestra los alumnos que están registrados
6. El actor ingresa en el text input el apellido del alumno que desee modificar.
7.El sistema valida los alumnos con ese apellido
8. El sistema muestra los alumnos con dicho apellido.
46
9. El actor selecciona en el check-box-
input el alumno que desea modificar.
10.El actor oprime el botón “Buscar”
11. El sistema valida que se haya seleccionado un alumno
12. El sistema consulta el historial clinico de ese alumno.
13. El sistema muestra en la vista el historial clínico del alumno.
14. El sistema muestra un mensaje en pantalla “Este es el historial del alumno”
15. El actor oprime el botón “Editar”
16. El sistema se direcciona a la vista de “Actualizar Historial clínico”.
17. El actor modifica los campos que desee, menos la identificación del alumno.
18. El actor oprime el botón “Guardar”
19. El sistema valida los campos.
20. El sistema guarda la modificación del historial.
Flujo alterno
7.1 No se encontraron alumnos con ese apellido
11.1 No se selecciona ningún alumno
11.1.2 El sistema muestra un mensaje en pantalla “Algo ocurrió en la consulta del historial”.
12.2 El alumno no tiene historial clínico.
12.2.1 El sistema muestra un mensaje en pantalla “El alumno no tiene ningún historial”
19. No se completan todos los campos
19.1.El sistema muestra un mensaje en pantalla “Completa este campo”.
Post condición Se muestra un mensaje en pantalla El historial se actualizo
47
correctamente”.
Fuente: Material de clase, Ingeniería de Software II (UCP, 2018)
Tabla 8. Especificación de caso de uso 08: Crear agendamiento
ID EC-8
Nombre (CU) Agendar cita
Actor Psicoeducador
Descripción El actor podrá crear un agentamiento de citas para los
alumnos.
Precondición 1. El actor debe haber ingresado al sistema (EC-1)
2. El alumno debe estar registrado (EC-2)
Flujo normal
Respuesta del Usuario Respuesta del Sistema
1+ El sistema muestra la vista principal
2. El actor oprime el botón “Agenda”
3. El actor oprime el botón “Generar cita”.
4. El sistema se direcciona a la vista de “Generar cita” y muestra el formato para registrar la cita.
5. El actor selecciona en el check-box-input el alumno que desea asignarle la cita.
6. El sistema muestra los alumnos con dicho apellido.
7. El actor ingresa en el datetime-local input la fecha y la hora de inicio de la cita.
8. El actor ingresa en el text input de duración, el tiempo en minutos que durara la cita.
9. El actor oprime el botón “Guardar”.
48
10. El sistema valida la fecha y la hora de la cita
11. El sistema valida el campo de duración.
12. El sistema guarda la cita agendada.
Flujo alterno
10.1 No hay disponibilidad en ese día y en esa hora.
10.1.1. El sistema muestra un mensaje en pantalla “En este momento la agenda está ocupada”.
10.2 No se ingresa todos los campos
10.2.1 El sistema muestra un mensaje en pantalla “Debes introducir un valor valido. El campo está incompleto o incluye una fecha no valida”.
11.1 El campo está vacío
11.1.1 El sistema muestra un mensaje en pantalla “Completa este campo”.
Post condición Se muestra un mensaje en pantalla “La cita ha sido agendada”
Fuente: Material de clase, Ingeniería de Software II (UCP, 2018)
Tabla 9. Especificación de caso de uso 09: Consultar cita
ID EC-9
Nombre (CU) Agendar cita
Actor Psicoeducador
Descripción El actor podrá consultar las citas que tiene pendiente.
Precondición 1. El actor debe haber ingresado al sistema (EC-1)
2. El alumno debe estar registrado (EC-2) 3. La cita debe haber sido agendada (EC-8)
Flujo normal
49
Respuesta del Usuario Respuesta del Sistema
1+ El sistema muestra la vista principal
2. El actor oprime el botón “Agenda”
3. El actor oprime el botón “Agenda”.
4. El sistema se direcciona a la vista de “agenda”
Post condición El sistema muestra las citas que han sido agendadas, con la respectiva información de los alumnos, fecha, hora de inicio y hora final.
Fuente: Material de clase, Ingeniería de Software II (UCP, 2018)
Tabla 10.. Especificación de caso de uso 10: Remitir alumno
ID EC-10
Nombre (CU) Remitir alumno
Actor Docente
Descripción El actor podrá remitir los alumnos al psicoeducador.
Precondición 1. El actor debe haber ingresado al sistema (EC-1) 2. El alumno debe estar registrado (EC-2)
Flujo normal
Respuesta del Usuario Respuesta del Sistema
1+ El sistema muestra la vista principal
2. El actor oprime el botón “Registrar”
3. El actor oprime el botón “Remisión”.
4. El sistema se direcciona a la vista de “Registro de Remisiones”
5. El sistema muestra un formato.
6. El sistema muestra los alumnos registrados.
7.El actor ingresa en el check input el
50
apellido del alumno que desea remitir
8. El actor selecciona en el check-box-input el alumno que desea remitir.
9. El actor selecciona en el text input estado, el estado de la remisión (Alto, medio o bajo).
10. El actor selecciona en el text input motivo, el motivo de la remisión (Dificultades comportamentales, dificultades familiares, etc).
11. El actor ingresa en text input descripción, la descripción de la remisión.
12. El actor ingresa en text input estrategia, la estrategia que utilizo.
13. El actor oprime el botón “Remitir Alumno”.
14. El sistema valida los campos.
15. El sistema valida que se haya seleccionado un alumno.
16. El sistema almacena la remisión.
Flujo alterno
14.1 No se completan todos los campos.
14.1.1 El sistema muestra un mensaje en pantalla “Completa este campo”.
15.1 No se selecciona ningún alumno
15.1.1 El sistema muestra un mensaje en pantalla “Algo malo paso al remitir el alumno”
Post condición Se muestra un mensaje en pantalla La remisión se ha registrado”.
Fuente: Material de clase, Ingeniería de Software II (UCP, 2018)
51
Tabla 11. . Especificación de caso de uso 11: Consultar remisión
ID EC-11
Nombre (CU) Remitir alumno
Actor Psicoeducador
Descripción El actor podrá consultar las remisiones internas de los
alumnos.
Precondición 1. El actor debe haber ingresado al sistema (EC-1) 2. El alumno debe estar registrado (EC-2) 3. EL alumno debe haber sido remitido
(EC-10)
Flujo normal
Respuesta del Usuario Respuesta del Sistema
1+ El sistema muestra la vista principal
2. El actor oprime el botón “Registrar”
3. El actor oprime el botón “Remisión”.
4. El sistema se direcciona a la vista de “Registro de Remisiones”
6. El sistema muestra los alumnos registrados.
7.El actor ingresa en el check input el apellido del alumno que desea remitir
8. El actor oprime el botón “Consultar”.
9. El sistema valida que se haya seleccionado un alumno.
10. El sistema consulta la remisión.
Flujo alterno
9.1 No se selecciona ningún alumno
9.1.1 El sistema muestra un mensaje en pantalla “Algo malo paso al remitir el alumno”
10.1 El alumno no tiene remisiones
10.1.1 El sistema muestra un mensaje en pantalla “El alumno no tiene ninguna Remisión”
52
Post condición Se muestra un mensaje en “Estas son las Remisiones del Alumno”
Fuente: Material de clase Ingeniería de Software II (UCP, 2018)
Tabla 12.Especificación de caso de uso 12: Modificar remisiones
ID EC-12
Nombre (CU) Remitir alumno
Actor Docente
Descripción El actor podrá modificar las remisiones internas de los
alumnos.
Precondición 1. El actor debe haber ingresado al sistema (EC-1) 2. El alumno debe estar registrado (EC-2) 3. EL alumno debe haber sido remitido
(EC-10)
Flujo normal
Respuesta del Usuario Respuesta del Sistema
1+ El sistema muestra la vista principal
2. El actor oprime el botón “Registrar”
3. El actor oprime el botón “Remisión”.
4. El sistema se direcciona a la vista de “Registro de Remisiones”
6. El sistema muestra los alumnos registrados.
7.El actor ingresa en el check input el apellido del alumno que desea remitir
8. El actor oprime el botón “Consultar”.
9. El sistema valida que se haya seleccionado un alumno.
10. El sistema consulta la remisión.
11.El actor oprime el botón “Editar”
12.EL sistema direcciona la vista a “Actualización de Remisión”
53
13. EL actor modifica el campo que desee, menos la identificación del alumno.
14. El actor oprime el botón Actualizar
15. El sistema valida los campos.
El sistema guarda la actualización de la Remisión.
Flujo alterno
9.1 No se selecciona ningún alumno
9.1.1 El sistema muestra un mensaje en pantalla “Algo malo paso al remitir el alumno”
10.1 El alumno no tiene remisiones
10.1.1 El sistema muestra un mensaje en pantalla “El alumno no tiene ninguna Remisión”
15. Los campos estan incompletos.
15.1 El sistema muestra un mensaje en pantalla “Completa este campo”.
Post condición Se muestra un mensaje en “Estas son las Remisiones del Alumno”
Fuente: Material de clase Ingeniería de Software II (UCP, 2018)
Tabla 13. Especificación de caso de uso 13: Registrar compromisos
ID EC-13
Nombre (CU) Generar formatos (Compromiso)
Actor Psicoeducador
Descripción El actor podrá registrar compromisos de los alumnos
Precondición 1. El actor debe haber ingresado al sistema (EC-1) 2. El alumno debe estar registrado (EC-2)
Flujo normal
Respuesta del Usuario Respuesta del Sistema
54
1+ El sistema muestra la vista principal
2. El actor oprime el botón “Registrar”
3. El actor oprime el botón “Compromiso”.
4. El sistema se direcciona a la vista de “Registro de Compromisos”
5. El sistema muestra los alumnos registrados.
6. El sistema muestra un formato.
7.El actor ingresa en el check input el apellido del alumno que desea regístrale un compromiso
12. El actor ingresa en text input Asistentes, los asistentes que requiere el compromiso
13. El actor ingresa en text input Lugar, el lugar donde se realiza el compromiso
14. El actor ingresa en text input Descripción, la descripción del compromiso.
15. El actor ingresa en text input Descripción, la descripción del compromiso.
13. El actor oprime el botón “Remitir Tema”, el tema del cormpromiso.
14. El actor oprime el botón “Guardar”
14. El sistema valida los campos.
15. El sistema valida que se haya seleccionado un alumno.
16. El sistema almacena la remisión.
Flujo alterno
14.1 No se completan todos los campos.
14.1.1 El sistema muestra un mensaje en pantalla “Completa este campo”.
15.1 No se selecciona ningún alumno
15.1.1 El sistema muestra un mensaje en
55
pantalla “Algo malo paso al remitir el alumno”
Post condición Se muestra un mensaje en pantalla “El compromiso se ha Registrado.”
Fuente: Material de clase, Ingeniería de Software II (UCP, 2018)
Tabla 14. Especificación de caso de uso 14: Consultar compromisos
ID EC-14
Nombre (CU) Generar formatos (Compromiso)
Actor Psicoeducador.
Descripción El actor podrá consultar compromisos de los alumnos.
Precondición 1. El actor debe haber ingresado al sistema (EC-1) 2. El alumno debe estar registrado (EC-2) 3. EL alumno debe tener un compromiso registrado
(EC-13)
Flujo normal
Respuesta del Usuario Respuesta del Sistema
1+ El sistema muestra la vista principal
2. El actor oprime el botón “Consultar”
3. El actor oprime el botón “Compromiso”.
4. El sistema se direcciona a la vista de “Consultar Compromiso de Alumno”
6. El sistema muestra los alumnos registrados.
7. El actor ingresa en el check input el apellido del alumno que desea consultar.
8. El actor oprime el botón “Consultar”.
9. El sistema valida que se haya seleccionado un alumno.
10. El sistema consulta el compromiso.
56
11. El sistema muestra el compromiso
Flujo alterno
9.1 No se selecciona ningún alumno
9.1.1 El sistema muestra un mensaje en pantalla “Algo malo paso al remitir el alumno”
10.1 El alumno no tiene remisiones
10.1 El sistema muestra un mensaje en pantalla “El alumno no tiene ninguna Remisión”
Post condición Se muestra un mensaje en “Este es el Compromiso del Alumno”
Fuente: Material de clase, Ingeniería de Software II (UCP, 2018)
Tabla 15. Especificación de caso de uso 15: Modificar compromiso
ID EC-15
Nombre (CU) Generar formatos (Compromiso)
Actor Psicoeducador
Descripción El actor podrá modificar compromisos de los alumnos.
Precondición 1. El actor debe haber ingresado al sistema (EC-1) 2. El alumno debe estar registrado (EC-2) 3. EL alumno debe tener un compromiso registrado
(EC-13)
Flujo normal
Respuesta del Usuario Respuesta del Sistema
1+ El sistema muestra la vista principal
2. El actor oprime el botón “Registrar”
3. El actor oprime el botón “Remisión”.
4. El sistema se direcciona a la vista de “Consultar Compromiso de Alumno”
6. El sistema muestra los alumnos registrados.
57
7. El actor ingresa en el check input el apellido del alumno que desea consultar.
8. El actor oprime el botón “Consultar”.
9. El sistema valida que se haya seleccionado un alumno.
10. El sistema consulta el compromiso
11.El sistema muestra los compromisos
12. El actor oprime el botón “Editar”
13. El actor modifica el campo que desee, no podrá modificar la identificación del alumno.
14. El actor oprime el botón “Guardar”
15. El sistema valida los campos.
16. El sistema guarda la modificación.
Flujo alterno
9.1 No se selecciona ningún alumno
9.1.1 El sistema muestra un mensaje en pantalla “Algo malo paso al remitir el alumno”
10.1 El alumno no tiene remisiones
10.1.1 El sistema muestra un mensaje en pantalla “El alumno no tiene ninguna Remisión”
15. Falta completar algún campo
15.1 El sistema muestra en pantalla un mensaje “Completa este campo”.
Post condición Se muestra un mensaje en “El compromiso se ha actualizado correctamente”
Fuente: Material de clase, Ingeniería de Software II (UCP, 2018)
58
Tabla 16. Especificación de caso de uso 16: Registrar seguimiento
ID EC-16
Nombre (CU) Generar formatos
Actor Psicoeducador
Descripción El actor podrá registrar seguimientos de los alumnos.
Precondición 1. El actor debe haber ingresado al sistema (EC-1) 2. El alumno debe estar registrado (EC-2)
Flujo normal
Respuesta del Usuario Respuesta del Sistema
1+ El sistema muestra la vista principal
2. El actor oprime el botón “Registrar”
3. El actor oprime el botón “Seguimiento”.
4. El sistema se direcciona a la vista de “Registro Seguimiento”
5. El sistema muestra los alumnos registrados.
6. El sistema muestra un formato.
7.El actor ingresa en el check input el apellido del alumno que desea regístrale un compromiso
8. El actor ingresa en el text input
Valoracion, la valoración
correspondiente.
9. El actor ingresa en text input
Estrategia, la estrategia
correspondiente.
10. El actor ingresa en text input
Resultado, el resultado
correspondiente.
11. El actor ingresa en text input
Recomendaciones, las
recomendaciones correspondientes.
12. El actor oprime el botón “Guardar”
59
13. El sistema valida los campos.
14. El sistema valida que se haya seleccionado un alumno.
15. El sistema almacena la remisión.
Flujo alterno
13.1 No se completan todos los campos.
13.1.1 El sistema muestra un mensaje en pantalla “Completa este campo”.
14.1 No se selecciona ningún alumno
14.1.1 El sistema muestra un mensaje en pantalla “Algo malo paso al remitir el alumno”
Post condición Se muestra un mensaje en pantalla “Se ha registrado el Seguimiento
Fuente: Material de clase, Ingeniería de Software II (UCP, 2018)
Tabla 17. Especificación de caso de uso 17: Consultar seguimiento
ID EC-17
Nombre (CU) Generar formatos (Seguimiento)
Actor Psicoeducador y Docente
Descripción El actor podrá consultar seguimiento de los alumnos.
Precondición 1. El actor debe haber ingresado al sistema (EC-1) 2. El alumno debe estar registrado (EC-2) 3. EL alumno debe tener un seguimiento registrado
(EC-16)
Flujo normal
Respuesta del Usuario Respuesta del Sistema
1+ El sistema muestra la vista principal
2. El actor oprime el botón “Consultar”
3. El actor oprime el botón
60
“Seguimiento”.
4. El sistema se direcciona a la vista de “Consultar Seguimiento de Alumno”
6. El sistema muestra los alumnos registrados.
7. El actor ingresa en el check input el apellido del alumno que desea consultar.
8. El actor oprime el botón “Consultar”.
9. El sistema valida que se haya seleccionado un alumno.
10. El sistema consulta el seguimiento.
11. El sistema muestra el seguimiento
Flujo alterno
9.1 No se selecciona ningún alumno
9.1.1 El sistema muestra un mensaje en pantalla “Algo malo paso al remitir el alumno”
10.1 El alumno no tiene remisiones
10.1 El sistema muestra un mensaje en pantalla “El alumno no tiene ninguna Remisión”
Post condición Se muestra un mensaje en “Esto son los seguimientos del Alumno”
Fuente: Material de clase, Ingeniería de Software II (UCP, 2018)
Tabla 18. Especificación de caso de uso 18: Modificar seguimiento
ID EC-18
Nombre (CU) Generar formatos (Seguimiento)
Actor Psicoeducador .
Descripción El actor podrá modificar seguimientos de los alumnos.
Precondición 1. El actor debe haber ingresado al sistema (EC-1)
61
2. El alumno debe estar registrado (EC-2) 3. EL alumno debe tener un seguimiento registrado
(EC-16)
Flujo normal
Respuesta del Usuario Respuesta del Sistema
1+ El sistema muestra la vista principal
2. El actor oprime el botón “Consultar”
3. El actor oprime el botón “Seguimiento”.
4. El sistema se direcciona a la vista de “Consultar Compromiso de Alumno”
6. El sistema muestra los alumnos registrados.
7. El actor ingresa en el check input el apellido del alumno que desea consultar.
8. El actor oprime el botón “Consultar”.
9. El sistema valida que se haya seleccionado un alumno.
10. El sistema consulta el seguimiento
11.El sistema muestra los seguimiento
12. El actor oprime el botón “Editar”
13. El actor modifica el campo que desee, no podrá modificar la identificación del alumno.
14. El actor oprime el botón “Guardar”
15. El sistema valida los campos.
16. El sistema guarda la modificación.
Flujo alterno
9.1 No se selecciona ningún alumno
9.1.1 El sistema muestra un mensaje en pantalla “Algo malo paso al remitir el alumno”
10.1 El alumno no tiene remisiones
10.1.1 El sistema muestra un mensaje en pantalla “El alumno no tiene ninguna
62
Remisión”
15. Falta completar algún campo
15.1 El sistema muestra en pantalla un mensaje “Completa este campo”.
Post condición Se muestra un mensaje en “El Seguimiento se actualizo correctamente”.
Fuente: Material de clase, Ingeniería de Software II (UCP, 2018)
Tabla 19. . Especificación de caso de uso 19: Remisión externa
ID EC-19
Nombre (CU) Generar formatos (Remisiones externas)
Actor Psicoeducador
Descripción El actor podrá hacer Remisiones externas a los alumnos.
Precondición 1. El actor debe haber ingresado al sistema (EC-1) 2. El alumno debe estar registrado (EC-2)
Flujo normal
Respuesta del Usuario Respuesta del Sistema
1 El sistema muestra la vista principal
2. El actor oprime el botón “Registrar”
3. El actor oprime el botón “Remisión Externa”.
4. El sistema se direcciona a la vista de “Registro de Remisión Externa”
5. El sistema muestra un formato.
6. El sistema muestra los alumnos registrados.
7.El actor ingresa en el check input el apellido del alumno que desea remitir
8. El actor selecciona en el check-box-
63
input el alumno que desea remitir.
9. El actor selecciona en el text input
Remitido a, a que entidad se remitara el alumno.
10. El actor selecciona en el text input motivo, el motivo de la remisión (Dificultades comportamentales, dificultades familiares, etc).
11. El actor ingresa en text input
Valoración:, la valoración
correspondiente
12. El actor ingresa en text input
Recomendaciones, las recomendaciones correspondientes.
13. El actor oprime el botón “Guardar”.
14. El sistema valida los campos.
15. El sistema valida que se haya seleccionado un alumno.
16. El sistema almacena la remisión.
Flujo alterno
14.1 No se completan todos los campos.
14.1.1 El sistema muestra un mensaje en pantalla “Completa este campo”.
15.1 No se selecciona ningún alumno
15.1.1 El sistema muestra un mensaje en pantalla “Algo malo paso al remitir el alumno”
Post condición Se muestra un mensaje en pantalla La Remisión Externa se ha registrado”.
Fuente: Material de clase, Ingeniería de Software II (UCP, 2018)
Tabla 20. Especificación de caso de uso 20: Consultar remisiones externas
ID EC-20
Nombre (CU) Generar formatos
64
(Seguimiento)
Actor Psicoeducador y Docente
Descripción El actor podrá consultar Remisiones Externas de los alumnos.
Precondición 1. El actor debe haber ingresado al sistema (EC-1) 2. El alumno debe estar registrado (EC-2) 3. El alumno debe tener Remisiones Externas (EC-
19)
Flujo normal
Respuesta del Usuario Respuesta del Sistema
1+ El sistema muestra la vista principal
2. El actor oprime el botón “Consultar”
3. El actor oprime el botón “Remision Externa
4. El sistema se direcciona a la vista de “Consultar de Remisión Externa de Alumno”
6. El sistema muestra los alumnos registrados.
7. El actor ingresa en el check input el apellido del alumno que desea consultar.
8. El actor oprime el botón “Consultar”.
9. El sistema valida que se haya seleccionado un alumno.
10. El sistema consulta el seguimiento.
11. El sistema muestra el seguimiento
Flujo alterno
9.1 No se selecciona ningún alumno
9.1.1 El sistema muestra un mensaje en pantalla “Algo malo paso al remitir el alumno”
10.1 El alumno no tiene remisiones
10.1 El sistema muestra un mensaje en pantalla “El alumno no tiene ninguna Remisión Externa”
65
Post condición Se muestra un mensaje en “Esto son los seguimientos del Alumno”
Fuente: Material de clase, Ingeniería de Software II (UCP, 2018)
Tabla 21. Especificación de caso de uso 21: Modificar remisión externa
ID EC-21
Nombre (CU) Generar formatos (Remisión Externa)
Actor Psicoeducador
Descripción El actor podrá modificar Remisiones Externa de los alumnos.
Precondición 1. El actor debe haber ingresado al sistema (EC-1) 2. El alumno debe estar registrado (EC-2) 3. El alumno debe tener una Remisión Externa (EC-
19)
Flujo normal
Respuesta del Usuario Respuesta del Sistema
1+ El sistema muestra la vista principal
2. El actor oprime el botón “Consultar”
3. El actor oprime el botón “Remisión Externa”.
4. El sistema se direcciona a la vista de “Consultar de Remisión Externa de Alumno”
6. El sistema muestra los alumnos registrados.
7. El actor ingresa en el check input el apellido del alumno que desea consultar.
8. El actor oprime el botón “Consultar”.
9. El sistema valida que se haya seleccionado un alumno.
10. El sistema consulta la remisión externa.
11. El sistema muestra la remisión externa.
66
12. El actor oprime el botón “Editar”
13. El actor modifica el campo que desee, no podrá modificar la identificación del alumno.
14. El actor oprime el botón “Guardar”
15. El sistema valida los campos.
16. El sistema guarda la modificación.
Flujo alterno
9.1 No se selecciona ningún alumno
9.1.1 El sistema muestra un mensaje en pantalla “Algo malo paso al remitir el alumno”
10.1 El alumno no tiene remisiones
10.1.1 El sistema muestra un mensaje en pantalla “El alumno no tiene ninguna Remisión Externa”.
15. Falta completar algún campo
15.1 El sistema muestra en pantalla un mensaje “Completa este campo”.
Post condición Se muestra un mensaje en “La Remisión Externa se actualizo correctamente”.
Fuente: Material de clase, Ingeniería de Software II (UCP, 2018)
Tabla 22. Especificación de caso de uso 22: Registrar alumno
ID EC-22
Nombre (CU) Gestión de cuentas (Registrar alumnos)
Actor Psicoeducador
Descripción El actor podrá Registrar un alumno en cualquier momento.
Precondición 1. El actor debe haber ingresado al sistema (EC-1).
Flujo normal
Respuesta del Usuario Respuesta del Sistema
67
1 El sistema muestra la vista principal
2. El actor oprime el botón “Registrar”
3. El actor oprime el botón “Alumno”.
4. El sistema se direcciona a la vista de “Registro de Alumnos”
5. El sistema muestra un formato.
6. El actor digita en el text input de
Identificación del Alumno, la tarjeta de identidad del alumno.
7. El actor digita en el text input de
Nombre, el nombre del alumno del alumno.
8. El actor digita en el text input de
Apellido, el apellido del alumno.
9. El actor digita en el text input de Grado, el Grado (1-11) del alumno.
10. El actor digita en el text input de
Acudiente, el acudiente del alumno.
11. El actor digita en el text input de
Teléfono del Acudiente, el teléfono del acudiente del alumno.
12. El actor digita en el text input de
Género, el género (masculino, femenino, indefinido) del alumno.
13. El actor digita en el text input de
Dirección, la dirección del alumno.
14. El actor oprime el botón “Guardar”.
14. El sistema valida los campos.
16. El sistema almacena la remisión.
Flujo alterno
14.1 No se completan todos los campos.
14.1.1 El sistema muestra un mensaje en pantalla “Completa este campo”.
14.2 El alumno ya existe
14.2.1 El sistema muestra un mensaje
68
en pantalla “El alumno ya se encuentra registrado”
Post condición Se muestra un mensaje en pantalla “Se ha registrado el usuario”
Fuente: Material de clase, Ingeniería de Software II (UCP, 2018)
Tabla 23. Especificación de caso de uso 23: Consultar reportes
ID EC-23
Nombre (CU) Consultar Reportes (motivo)
Actor Psicoeducador
Descripción El actor podrá consultar reportes acerca de la cantidad de alumnos remitidos por un motivo en específico. .
Precondición 1. El actor debe haber ingresado al sistema (EC-1) 2. El alumno debe estar registrado (EC-2) 3. El alumno tiene que haber sido remitido (EC-10)
Flujo normal
Respuesta del Usuario Respuesta del Sistema
1+ El sistema muestra la vista principal
2. El actor oprime el botón “Reportes”
3. El actor oprime el botón “Motivo”.
4. El sistema se direcciona a la vista de “Buscar Remisión”.
6. El sistema muestra un buscador.
7. El actor ingresa en el text input el motivo que desea consultar.
8. El actor oprime el botón “Consultar”.
9. El sistema valida que se haya seleccionado un motivo.
10. El sistema consulta las remisiones de con dicho motivo.
11.El sistema muestra las remisiones con dicho motivo
69
Flujo alterno
9.1 No se selecciona ningún motivo.
9.1.1 El sistema muestra un mensaje en pantalla “No hay remisiones sobre es emotivo”.
Post condición Se muestra un mensaje en “La cantidad de Remisiones son (#)”.
Fuente: Material de clase, Ingeniería de Software II (UCP, 2018)
Tabla 24. Especificación de caso de uso 24: Consultar reportes-docente
ID EC-24
Nombre (CU) Consultar Reportes (docente)
Actor Psicoeducador
Descripción El actor podrá consultar reportes de la cantidad de remisiones
que hacen los docentes.
Precondición 1. El actor debe haber ingresado al sistema (EC-1) 2. El alumno debe estar registrado (EC-3) 3. El alumno tiene que haber sido remitido (EC-10)
Flujo normal
Respuesta del Usuario Respuesta del Sistema
1+ El sistema muestra la vista principal
2. El actor oprime el botón “Reportes”
3. El actor oprime el botón “Docente”.
4. El sistema se direcciona a la vista de “Buscar Docente”.
6. El sistema muestra los docentes registrados.
7. El actor selecciona en check box input el docente que desea consultar.
8. El actor oprime el botón “Consultar”.
70
9. El sistema valida que se haya seleccionado a un docente.
10. El sistema consulta las remisiones que han realizado dicho docente.
11. El sistema muestra las remisiones que han realizado dicho docente.
Flujo alterno
9.1 No se selecciona ningún motivo.
9.1.1 El sistema muestra un mensaje en pantalla “No hay remisiones sobre es emotivo”.
10. El docente no ha realizado ninguna remisión
10.1 El sistema muestra un mensaje en pantalla “El docente no ha realizado ninguna remisión”.
Post condición Se muestra un mensaje en “La cantidad de Remisiones son: (#)”.
Fuente: Material de clase, Ingeniería de Software II (UCP, 2018)
71
1.9.4 Requerimientos
Los requerimientos permiten concretar las necesidades que tienen el cliente
y permite también definir las funcionalidades que el sistema debe realizar.
Para poder definir los requerimientos se realizó el levantamiento de la
información con dos técnicas de elicitación que se encuentran en el
contenido 7.1, y como resultado se obtuvieron 14 requerimientos funcionales
y 1 no funcional.
Dentro de los campos establecidos en los requerimientos hay dos aspectos
fundamentales a tener en cuenta en el momento de realizar el diseño, estos
aspectos son: Prioridad del requerimiento según el cliente y Prioridad del
requerimiento según el desarrollador.
Prioridad del requerimiento: su función es determinar el grado de importancia
que posee el requerimiento, según el cliente y según el desarrollador.
El grado de prioridad se encuentra categorizado de la siguiente manera.
P1. Prioridad alta:
P2. Prioridad media
P3. Prioridad baja
Actor asignado: corresponde al actor que tiene relación alguna con el
requerimiento.
A1.Actor psicoeducador
A2. Actor Docente
Los requerimientos se pueden ver a continuación.
72
Tabla 25 . Requerimiento 01. Autenticar Usuario
Sistema de Información Web para el Control de Datos Psicoeducativos del Colegio Carlos Castro Saavedra
Identificador RQ-01
Nombre del requerimiento Autenticar usuario
Fecha de levantamiento 24-04-18 Medio por el cual fue recibido
Telefónica
Oral x
Electrónica Tipo de requerimiento Funcional Actor asignado A1
Descripción El usuario debe poder ingresar al sistema en cualquier momento, ingresando correo y contraseña.
Prioridad según el cliente P1 Prioridad según el desarrollador
P1-
Estado Recibido Aprobado En ejecución Entregado
x
Plan de Trabajo
¿Se necesita de personal adicional?
SI No x
Responsable Ana María Ramírez
Fuente: Material de clase Ingeniería de Software II (UCP, 2018)
Tabla 26. Requerimiento 03: Perfil de usuarios
Sistema de Información Web para el Control de Datos Psicoeducativos del Colegio Carlos Castro Saavedra
Identificador RQ-02
Nombre del requerimiento Perfiles de usuarios
Fecha de levantamiento 20-04-18 Medio por el cual fue recibido
Telefónica
Oral x
Electrónica Tipo de requerimiento Funcional Actor asignado A1-A2
Descripción El usuario debe permitir tener dos perfil o roles diferentes, para el psicoeducador y el docente.
Prioridad según el cliente P1 Prioridad según el desarrollador
P1
Estado Recibido Aprobado En ejecución Entregado
x
Plan de Trabajo
¿Se necesita de personal adicional?
SI No x
Responsable Ana María Ramírez
Fuente: Material de clase Ingeniería de Software II (UCP, 2018)
73
Tabla 27. Requerimiento 04: Crud de usuario
Sistema de Información Web para el Control de Datos Psicoeducativos del Colegio Carlos Castro Saavedra
Identificador RQ-03
Nombre del requerimiento Crud de usuarios
Fecha de levantamiento 20-04-18 Medio por el cual fue recibido
Telefónica
Oral x
Electrónica Tipo de requerimiento Funcional Actor asignado A1-A2
Descripción El sistema debe de permitir crear, modificar, y consultar usuarios en cualquier momento.
Prioridad según el cliente P2 Prioridad según el desarrollador
P1
Estado Recibido Aprobado En ejecución Entregado
x
Plan de Trabajo
¿Se necesita de personal adicional?
SI No x
Responsable Ana María Ramírez
Fuente: Material de clase Ingeniería de Software II (UCP, 2018)
Tabla 28. Requerimiento 04: Remisión interna
Sistema de Información Web para el Control de Datos Psicoeducativos del Colegio Carlos Castro Saavedra
Identificador RQ-04
Nombre del requerimiento Remisión de alumnos
Fecha de levantamiento 20-04-18 Medio por el cual fue recibido
Telefónica
Oral x
Electrónica Tipo de requerimiento Funcional Actor asignado A1-A2
Descripción El sistema deberá permitir a los docentes remitir a los alumnos al departamento de psicoeducación
Prioridad según el cliente P1 Prioridad según el desarrollador
P1
Estado Recibido Aprobado En ejecución Entregado
x
Plan de Trabajo
¿Se necesita de personal adicional?
SI No x
Responsable Ana María Ramírez
Fuente: Material de clase Ingeniería de Software II (UCP, 2018)
74
Tabla 29. Requerimiento 05: Motivo de remisión
Sistema de Información Web para el Control de Datos Psicoeducativos del Colegio Carlos Castro Saavedra
Identificador RQ-05
Nombre del requerimiento Motivo de Remisión
Fecha de levantamiento 20-04-18 Medio por el cual fue recibido
Telefónica
Oral x
Electrónica Tipo de requerimiento Funcional Actor asignado A1-A2
Descripción Se debe contar con varios tipos de motivos de remisión para que el docente remita al alumno.
Prioridad según el cliente P1 Prioridad según el desarrollador
P1
Estado Recibido Aprobado En ejecución Entregado
x
Plan de Trabajo
¿Se necesita de personal adicional?
SI No x
Responsable Ana María Ramírez
Fuente: Material de clase Ingeniería de Software II (UCP, 2018)
Tabla 30. Requerimiento 06: Prioridad de cita
Sistema de Información Web para el Control de Datos Psicoeducativos del Colegio Carlos Castro Saavedra
Identificador RQ-06
Nombre del requerimiento Prioridad de Cita
Fecha de levantamiento 20-04-18 Medio por el cual fue recibido
Telefónica
Oral x
Electrónica Tipo de requerimiento Funcional Actor asignado A1-A2
Descripción El sistema deberá de permitir asignar una prioridad (alta, media o baja) a la remisión del alumno.
Prioridad según el cliente P1 Prioridad según el desarrollador
P1
Estado Recibido Aprobado En ejecución Entregado
x
Plan de Trabajo
¿Se necesita de personal adicional?
SI No x
Responsable Ana María Ramírez
Fuente: Material de clase Ingeniería de Software II (UCP, 2018)
75
Tabla 31. Requerimiento 07: Agendmiendo
Sistema de Información Web para el Control de Datos Psicoeducativos del Colegio Carlos Castro Saavedra
Identificador RQ-07
Nombre del requerimiento Agendamiento de cita
Fecha de levantamiento 05-05-18 Medio por el cual fue recibido
Telefónica
Oral x
Electrónica Tipo de requerimiento Funcional Actor asignado A1
Descripción El sistema deberá permitir agendar y consultar citas
Prioridad según el cliente P1 Prioridad según el desarrollador
P1
Estado Recibido Aprobado En ejecución Entregado
x
Plan de Trabajo
¿Se necesita de personal adicional?
SI x No
Responsable Ana María Ramírez
Fuente: Material de clase Ingeniería de Software II (UCP, 2018)
Tabla 32. Requerimiento 08: Seguimiento del alumno
Sistema de Información Web para el Control de Datos Psicoeducativos del Colegio Carlos Castro Saavedra
Identificador RQ-08
Nombre del requerimiento Seguimiento del alumno
Fecha de levantamiento 05-05-18 Medio por el cual fue recibido
Telefónica
Oral x
Electrónica Tipo de requerimiento Funcional Actor asignado A1
Descripción El sistema debe permitir crear, actualizar y consultar formatos para el seguimiento que hace el psicoeducador al alumno.
Prioridad según el cliente P1 Prioridad según el desarrollador
P1-
Estado Recibido Aprobado En ejecución Entregado
x
Plan de Trabajo
¿Se necesita de personal adicional?
SI No x
Responsable Ana María Ramírez
Fuente: Material de clase Ingeniería de Software II (UCP, 2018)
76
Tabla 33. Requerimiento 09: Consulta de seguimiento (docente)
Sistema de Información Web para el Control de Datos Psicoeducativos del Colegio Carlos Castro Saavedra
Identificador RQ-09
Nombre del requerimiento Seguimiento del alumno para docente
Fecha de levantamiento 05-05-18 Medio por el cual fue recibido
Telefónica
Oral x
Electrónica Tipo de requerimiento Funcional Actor asignado A1
Descripción El sistema debe permitir consultar seguimientos de los alumnos que ha remitido al departamento de psicoeducación
Prioridad según el cliente P2 Prioridad según el desarrollador
P2
Estado Recibido Aprobado En ejecución Entregado
x
Plan de Trabajo
¿Se necesita de personal adicional?
SI No x
Responsable Ana María Ramírez
Fuente: Material de clase Ingeniería de Software II (UCP, 2018
Tabla 34. Requerimiento 10. Remisión externa
Sistema de Información Web para el Control de Datos Psicoeducativo del Colegio Carlos Castro Saavedra
Identificador RQ-10
Nombre del requerimiento Remisión Externa
Fecha de levantamiento 10-05-18 Medio por el cual fue recibido
Telefónica
Oral x
Electrónica Tipo de requerimiento Funcional Actor asignado A1
Descripción El sistema deberá permitir crear, consultar y modificar una remisión externa el cual se realiza en algunos casos especiales
Prioridad según el cliente P1 Prioridad según el desarrollador
P1-
Estado Recibido Aprobado En ejecución Entregado
x
Plan de Trabajo
¿Se necesita de personal adicional?
SI No x
Responsable Ana María Ramírez
Fuente: Material de clase Ingeniería de Software II (UCP, 2018)
77
Tabla 35. Requerimiento 11: Compromiso de alumno
Sistema de Información Web para el Control de Datos Psicoeducativo del Colegio Carlos Castro Saavedra
Identificador RQ-11
Nombre del requerimiento Compromiso del alumno
Fecha de levantamiento 10-05-18 Medio por el cual fue recibido
Telefónica
Oral x
Electrónica Tipo de requerimiento Funcional Actor asignado A1
Descripción El sistema deberá permitir crear, consultar y modificar un compromiso que se le realizaran en la cita al alumno.
Prioridad según el cliente P1 Prioridad según el desarrollador
P2
Estado Recibido Aprobado En ejecución Entregado
x
Plan de Trabajo
¿Se necesita de personal adicional?
SI No x
Responsable Ana María Ramírez
Fuente: Material de clase Ingeniería de Software II (UCP, 2018)
Tabla 36. Requerimiento 12: Reportes de docente
Sistema de Información Web para el Control de Datos Psicoeducativo del Colegio Carlos Castro Saavedra
Identificador RQ-12
Nombre del requerimiento Reportes de Docentes
Fecha de levantamiento 10-05-18 Medio por el cual fue recibido
Telefónica
Oral x
Electrónica Tipo de requerimiento Funcional Actor asignado A1
Descripción El sistema deberá generar reportes de cuantas remisiones ha realizado un docente y su respectivo registro.
Prioridad según el cliente P1 Prioridad según el desarrollador
P1
Estado Recibido Aprobado En ejecución Entregado
x
Plan de Trabajo
¿Se necesita de personal adicional?
SI No x
Responsable Ana María Ramírez
Fuente: Material de clase Ingeniería de Software II (UCP, 2018)
78
Tabla 37. Requerimiento 13: Reportes de motivo
Sistema de Información Web para el Control de Datos Psicoeducativo del Colegio Carlos Castro Saavedra
Identificador RQ-13
Nombre del requerimiento Reportes de motivos
Fecha de levantamiento 10-05-18 Medio por el cual fue recibido
Telefónica
Oral x
Electrónica Tipo de requerimiento Funcional Actor asignado A1
Descripción El sistema deberá generar reportes de la cantidad de remisión que han realizado por un dicho motivo.
Prioridad según el cliente P1 Prioridad según el desarrollador
P1
Estado Recibido Aprobado En ejecución Entregado
x
Plan de Trabajo
¿Se necesita de personal adicional?
SI No x
Responsable Ana María Ramírez
Fuente: Material de clase Ingeniería de Software II (UCP, 2018)
Tabla 38. Requerimiento 14: Generar historial clínico
Sistema de Información Web para el Control de Datos Psicoeducativo del Colegio Carlos Castro Saavedra
Identificador RQ-14
Nombre del requerimiento Generar Historiales clínicos
Fecha de levantamiento 10-05-18 Medio por el cual fue recibido
Telefónica
Oral x
Electrónica Tipo de requerimiento Funcional Actor asignado A1
Descripción El sistema deberá permitir crear, consultar y modificar historiales clínicos de los alumnos remitidos al departamento de psicoeducacion
Prioridad según el cliente P1 Prioridad según el desarrollador
P1
Estado Recibido Aprobado En ejecución Entregado
x
Plan de Trabajo
¿Se necesita de personal adicional?
SI No x
Responsable Ana María Ramírez
Fuente: Material de clase Ingeniería de Software II (UCP, 2018)
79
Tabla 39. Requerimiento No funcional 1. Disponibilidad
Sistema de Información Web para el Control de Datos Psicoeducativo del Colegio Carlos Castro Saavedra
Identificador RQNF-01
Nombre del requerimiento Disponibilidad
Fecha de levantamiento 15-05-18 Medio por el cual fue recibido
Telefónica x
Oral
Electrónica Tipo de requerimiento No Funcional Actor asignado A1
Descripción El sistema deberá tener disponibilidad del sistema 24 horas y 7 días de la semana.
Prioridad según el cliente P1 Prioridad según el desarrollador
P1
Estado Recibido Aprobado En ejecución Entregado
x
Plan de Trabajo
¿Se necesita de personal adicional?
SI No x
Responsable Ana María Ramírez
Fuente: Material de clase Ingeniería de Software II (UCP, 2018)
80
1.10 DISEÑO
La fase de diseño tiene la finalidad de representar las diferentes perspectivas
lógicas y físicas del sistema mediante los diagramas que ofrece UML,
igualmente permite definir la estructura lógica que será de apoyo para la
siguiente fase de integración. En esta fase de la metodología se incorporan
algunos diagramas de ellos, los cuales se presentarán a continuación.
1.10.1 Modelo entidad relación
El modelo entidad relación es un diagrama que permite representar las
entidades del sistema de información y sirve para diseñar el esquema de la
base de datos antes de ser desarrollada.
A continuación, se muestra el diagrama construido para el sistema.
Ilustración 11. Modelo entidad relación
Fuente: elaboración propia, realizado mediante StraUML
81
1.10.2 Modelo relacional
Ilustración 12. Modelo relacional
Fuente: Elaboración propia, realizado en el programa StarUML
82
1.10.2.1 Diccionario de Datos
El diccionario de datos que se muestra a continuación permite visualizarse
como un repositorio de la información sobre los datos que van dentro de los
campos y se realizó a partir de del Modelo Entidad Relación.
Tabla 40. Diccionario de datos: Tabla usuarios
Entidad usuario Descripción Tabla en que se almacena los datos personales del
docente
Campo Tipo de
dato
Tamaño Descripción
idUsuario INT 11 Llave primaria de la tabla
nomUsuario VARCHAR 255 Nombre completo del USUARIO
apellidoUsuario VARCHAR 255 Apellidos del docente
telefono VARCHAR 11 Teléfono del usuario
Dirección VARCHAR 255 Dirección del usuario
Correo VARCHAR 255 Correo del usuario para ingresar al sistema
Contraseña VARCHAR 255 Contraseña del usuario para ingresar al sistema
Rol INT 11 Rol de usuario para definir a que perfil ingresar
Fuente: Elaboración propia
Tabla 41. Diccionario de datos: Tabla alumno
Entidad alumnos Descripción Tabla en que se almacenara los datos personales
del alumno
Campo Tipo de
dato
Tamaño Descripción
idAlumno INT 20 Llave primaria de la tabla
nombreAlumno VARCHAR 255 Nombre del alumno
apellidoALumno VARCHAR 255 Apellidos del alumno
Grado INT 11 Grado que cursa el alumno
Acudiente VARCHAR 255 Acudiente del alumno
telAcudiente INTEGER 11 Teléfono del acudiente del alumno
generoPersona VARCHAR 255 Genero del alumno
Dirección VARCHAR 255 Dirección de vivienda del alumno
83
Fuente: Elaboración propia
Tabla 42. Diccionario de datos: Tabla remisiones
Entidad remisionexs Descripción Tabla que almacenara los campos necesarios de la
remisión externa del alumno
Campo Tipo de
dato
Tamaño Descripción
idRemision INT 11 Llave primaria de la tabla
Remitido VARCHAR 255 Campo para reconocer a que entidad va remitido el
alumno
Motivo VARCHAR 255 Motivo de remisión externa
Valoración VARCHAR 255 Valoraciones de la remisión externa
recomendaciones VARCHAR 255 Recomendaciones en la remisión externa
idAlumno INT 11 Llave foránea de la tabla alumno
Fuente: Elaboración propia
Tabla 43. Diccionario de datos: Tabla seguimientos
Entidad seguimiento Descripción Tabla que almacenara el seguimiento clínico que
se le hará al alumno
Campo Tipo de
dato
Tamaño Descripción
idSeguimiento INT 11 Llave primaria de la tabla
Valoración VARCHAR 255 Valoración que se le realiza al alumno
Estrategia VARCHAR 255 Estrategia a utilizar con el alumno
recomendaciones VARCHAR 255 Recomendaciones para el cuidado del alumno
idAlumno INT 11 Llave foránea de la tabla alumnos
Fuente: Elaboración propia
84
Tabla 44. Diccionario de datos: Tabla historial
Entidad historial Descripción Tabla en que se almacena el historial clínico del
alumno
Campo Tipo de
dato
Tamaño Descripción
idHistorials INT 11 Llave primaria de la tabla
dimensionSo VARCHAR 255 Comportamiento y relaciones del alumno con la
sociedad
nombreArchivo VARCHAR 255 Nombre el archivo que se registrara en un archivo
idAlumno INT 11 Llave foránea de la tabla alumnos
Fuente: Elaboración propia
Tabla 45. Diccionario de datos: Tabla compromisos
Entidad compromiso Descripción Tabla en que se almacena los compromisos que
realizara el alumno con el psicoeducador
Campo Tipo de
dato
Tamaño Descripción
idComrpomiso INTEGER 11 Llave primaria de la tabla
Lugar VARCHAR 255 Lugar en que se realiza el compromiso
Tema VARCHAR 255 Tema tratado en el compromiso
Asistentes VARCHAR 255 Personas que estén presentes
Descripción VARCHAR 150 Anexos del compromiso del alumno
idAlumno VARCHAR 20 Llave foránea de la tabla alumnos
Fuente: Elaboración propia
85
Tabla 46. Diccionario de datos: Tabla citas
Relación cita Descripción Tabla en que se almacenan los campos del agentamiento
de la cita
Campo Tipo de
dato
Tamaño Descripción
id INT 11 Llave primaria de la tabla
fechaInicio DATE Fecha en que se asigna la cita
fechaFIn DATE Fecha en que finaliza acaba la cita
idAlumno INT 20 Id del alumno
Fuente: Elaboración propia
Tabla 47. Diccionario de datos: Tabla remisiones internas
Relación remisioninterna Descripción Ta Tabla en que se almacenan las remisiones
internas que hace el docente al psicoeducador
Campo Tipo de dato Tamaño Descripción
idRemision INT 11 Llave primaria de la remisión interna
Estado VARCHAR 255 Estando en que se encuentra el alumno
Motivo VARCHAR 255 Motivo de remisión del alumno
Estrategias VARCHAR 255 Estrategias utilizadas con el alumno anteriormente
idAlumno INT 11 Llave foránea de la tabla Alumnos
nombreArchivo VARCHAR 60 Campo que almacena la dirección del archivo Pdf
Fuente: Elaboración propia
86
1.10.3 Diagrama de Clase
Los diagramas de cases se utilizan para modelar la vista de diseño estático
de un sistema. Esta vista soporta principalmente los tres requisitos
funcionales de un sistema y los servicios que el sistema debe de
proporciónale, los requisitos son: modelar el vocabulario del sistema el cual
consiste en una toma de decisiones de la abstracción lógica, modelar
colaboraciones por lo cual se considera como un conjunto de clases,
interfaces y otros elementos que colaboran para para proporcionar un
comportamiento cooperativo y modelar esquemas lógicos de base de datos,
el cual se puede pensar en un esquema como en un plano para el diseño
conceptual de la base de datos .
Los diagramas de cases son importantes no solo para visualizar, especificar
y documentar modelos estructurales, sino también para construir sistemas
ejecutables.
Los diagramas de clases contienen normalmente los siguientes elementos
Clases
Interfaces
Colaboraciones
Relaciones de dependencia
[15]
A continuación, se muestra los diagramas de clase que se realizaron.
87
Ilustración 13. Diagrama de clases 01 Alumno
Fuente: Realización propia, mediante el programa StarUml.
Ilustración 14. Diagrama de clase 02 Usuario
Fuente: Realización propia, mediante el programa StarUml.
88
Ilustración 15. Diagrama de clase 03 RemisiónInterna
Fuente: Realización propia, mediante el programa StarUml.
Ilustración 16. Diagrama de clase 04. Compromiso
Fuente: Realización propia, mediante el programa StarUml.
89
Ilustración 17. Diagrama de clase 05. Seguimiento
Fuente: Realización propia, mediante el programa StarUml.
Ilustración 18. Diagrama de clase 06. Cita
Fuente: Realización propia, mediante el programa StarUml.
90
Ilustración 19. Diagrama de clase 07. RemisiónExterna
Fuente: Realización propia, mediante el programa StarUml.
Ilustración 20. Diagrama de clase 08. Historial
Fuente: Realización propia, mediante el programa StarUml.
91
1.10.4 Diagrama de Despliegue
Según Pressman [2], el diagrama de despliegue permite mostrar la
arquitectura en tiempo de ejecución del sistema respecto al hardware y
software.
Este se utiliza en el diseño y la implementación. Se pueden distinguir
componentes y nodos, así como las relaciones entre estos.
La arquitectura lógica del diagrama de despliegue es la siguiente:
● Capa lógica de presentación y de aplicación en la computadora del
cliente, en su almacenamiento o en su servidor.
● La presentación en la computadora del cliente, la lógica de
aplicaciones en un servidor de la aplicación y el almacenamiento en
un servidor de los subsistemas se irá realizando de manera distribuida
cada vez más.
A continuación, se presenta el diagrama de despliegue que se realizó para el
sistema de información web.
92
Ilustración 21. Diagrama de despliegue
Fuente: Elaboración propia, realizado mediante el programa Lucy Chart
93
1.10.5 Diagrama de Secuencia
Ilustración 22. Diagrama de secuencia 01: CrearAlumno
Crear Alumno
Fuente: Elaboración propia, realizada en el programa StramUML
94
Ilustración 23. Diagrama de secuencia 02: CrearCompromiso
Fuente: Elaboración propia, realizada en el programa StramUML
95
Ilustración 24. Diagrama de secuencia 03: ActualizarCompromiso
Fuente: Elaboración propia, realizada en el programa StramUML
96
1.11 DESARROLLO DEL SISTEMA
La ejecución del proyecto se realiza después de la fase de diseño del
sistema guiándose por medio de los diagramas de UML. Se efectúa
mediante los siguientes programas que se muestran en la ilustración 25.
Ilustración 25. Programas para la implementación
PROGRAMA
TIPO
DESRIPCIÓN
Visual Studio Code
Editor de texto
Es un entorno en tiempo de ejecución multiplataforma, de código abierto, para la capa del servidor
NodeJs
Entorno de ejecución
Es un entorno de ejecución para JavaScript de código abierto y multiplataforma
Express
Framework
Complemento de nodeJs, que contiene múltiples librerías
JavaScript
Lenguaje de programación
Lenguaje interactivo
Sequelize
OMR framework
Orm de nodeJs permite agilizar el desarrollo que incluye base de datos relacionados como MySQL
Fuente: propia
97
1.11.1 Resultados
A continuación se muestran pantallazos del sistema finalizado en su totalidad
y en estado de ejecución.
En la ilustración 26 muestra que se cumple satisfactoriamente con el RQ-01,
el cual consta de una autenticación de usuario para ingresar al sistema.
Ilustración 26. Resultado 01: Vista principal
Fuente: Elaboración propia
98
Esta prueba permite mostrar el login para autenticar el usuario cumpliendo
con el RQ-01, como se ve en la ilustración 27 se debe ingresar el correo y la
contraseña.
Ilustración 27. Resultado 02: Iniciar sesión
Fuente: Elaboración propia
Esta prueba consiste en demostrar un intento de ingreso al sistema, sin
digitar la contraseña, como se puede notar en la ilustración 28
inmediatamente aparece un mensaje en pantalla.
Ilustración 28. Resultado 03: Iniciar sesión sin campos
Fuente: Elaboración propia
99
Esta prueba consiste en demostrar un intento de ingreso al sistema,
ingresando una contraseña incorrecta, como se puede mostrar en la
ilustración 29 aparece inmediatamente un mensaje en pantalla.
Ilustración 29. Resultado 04: Iniciar sesión con contraseña errónea
Fuente: Elaboración propia
Esta prueba permite mostrar la vista principal del psicoeducador, cumpliendo
con el Requerimiento 02 (RQ-02) , el cual consiste en que el sistema tenga
2 perfiles o roles diferentes. Como se puede ver en la ilustración 30 el
psicoeducador podrá hacer al registro de todos los formatos.
Ilustración 30. Resultado 05: Perfil de psicoeducador
Fuente: Elaboración propia
100
En la ilustración 31 muestra el formato para el registro de un historial clínico
cumplimento con el Requerimiento 14 (RQ-14).
Ilustración 31. Resultado 06. Registro de historial clínico
Fuente: Elaboración propia
101
Ilustración 32. Resultado 06. Registro de historial clínico 2
Fuente: Elaboración propia
102
Ilustración 33.Resultado 06. Registro de historial clínico 3
Esta prueba permite mostrar el intento fallido de una búsqueda al seleccionar
un alumno que no tiene historial clínico. La ilustración muestra como
inmediatamente aparece un mensaje en pantalla.
Ilustración 34. Prueba 07: Alumno sin historial
Fuente: Elaboración propia
103
Esta prueba permite mostrar la búsqueda exitosa de los historiales clínicos
de un alumno, la ilustración muestra como inmediatamente aparece un
mensaje en pantalla y sus respectivos historiales.
Ilustración 35. Resultado 8: Consulta de historial clínico
Fuente: Elaboración propia
Esta prueba consiste en validar que todos los campos deben de estar
completos cuando se guarde el registro de un compromiso como se muestra
en la ilustración.
104
Ilustración 36. Prueba 08: Registro de compromiso
Fuente: Elaboración propia
105
Esta prueba se basa en mostrar la consulta exitosa del compromiso del
alumno, redireccionando a la vista que se muestra en la ilustración junto con
la información del alumno, también muestra un mensaje en pantalla
indicando el compromiso. Cumpliendo con el requerimiento 11 (RQ-11), para
consultar un compromiso.
Ilustración 37. Prueba 09: Consulta de compromiso
.
Fuente: Elaboración propia
106
Esta prueba se basa en mostrar el registro exitoso de un seguimiento por
medio de un mensaje en pantalla como se muestra en la ilustración 36,
cumpliendo con el requerimiento del crear un seguimiento 08 (RQ-08).
Ilustración 38. Prueba 10: Registro de compromiso
Fuente: Elaboración propia
107
Esta prueba se basa en mostrar la consulta exitosa del seguimiento del
alumno, redireccionando a la vista que se muestra en la ilustración junto con
la información del alumno, también muestra un mensaje en pantalla
indicando que estos son los seguimientos. Cumpliendo con las consulta del
requerimiento 08 (RQ-08).
Ilustración 39. Prueba 11: Consulta de seguimiento
Fuente: Elaboración propia
108
Esta prueba se basa en mostrar el registro exitoso de una Remisión externa
por medio de un mensaje en pantalla como se muestra en la ilustración,
también muestra como la vista se direcciona de nuevo al Registro de
Remisiones Externas y el formato lo devuelve vacío. Cumpliendo con el
requerimiento 10 (RQ-10).
Ilustración 40. Prueba 12: Registro de remisiones externa
Fuente: Elaboración propia
109
Esta prueba se basa en mostrar la consulta exitosa de la Remisión Externa
del alumno, redireccionando a la vista que se muestra en la ilustración junto
con la información del alumno, también muestra un mensaje en pantalla
indicando que estos son las Remisiones Externas.
Ilustración 41. Prueba 13: Consulta de remisión externa
Fuente: Elaboración propia
110
Esta prueba consiste en validar que todos los campos deben de estar
completos cuando se guarde el registro de un compromiso como se muestra
en la ilustración.
Ilustración 42. Prueba 14: Registro de alumno
Fuente: Elaboración propia
111
Esta prueba consiste en validar la cantidad de remisiones que ha realizado
un docente, la ilustracion muestra un mensaje en pantalla indicando la
cantidad total de las remision junto con el registro de cada una. Cumpliendo
el requerimiento 12 (RQ-12).
Ilustración 43. Prueba 15: reportes de docentes
Fuente: Elaboración propia
112
Esta prueba se basa en mostrar el registro exitoso de una cita por medio de
un mensaje en pantalla como se muestra en la ilustración, también muestra
como la vista se direcciona de nuevo al Registro de cita y el formato lo
devuelve vacío. Se cumple con el requerimiento 07 (RQ-07)
Ilustración 44. Prueba 16: Generar cita
Fuente: Elaboración propia
113
La ilustración 43 muestra la consulta de las citas asignadas con su respectiva
información, cumpliendo con el requerimiento 07 (RQ-07).
Ilustración 45. Prueba 17: Consulta cita
Fuente: Elaboración propia
Es la ilustración 46 muestra la búsqueda de las remisiones que han sido
realizadas por un motivo en específico, cumpliendo así con el requerimiento
13 (RQ-13).
Ilustración 46. Prueba 18. Reportes por motivos de remisión
Fuente: Elaboración propia
114
Dando continuidad de la ilustración 46, se muestra la remisión que ha sido
realizada por el motivo (dificultades familiares) y se muestra en la ilustración
47 las remisiones realizadas por dicho motivo, también se emite un mensaje
que indica el total en número entero de dicha remisión, que cumple con el
requerimiento 13 (RQ-13).
Ilustración 47. Prueba 18. Reportes por motivos de remisión 2
Fuente: Elaboración propia
115
Esta prueba permite mostrar la vista principal del docente, cumpliendo con
el Requerimiento 02 (RQ-02), el cual consiste en que el sistema tenga 2
perfiles o roles diferente.
Como se puede ver en la ilustración el docente solo podrá registrar
remisiones internas, consultar el seguimiento de los alumnos y actualizar su
contraseña.
Ilustración 48.Prueba 18: Perfil docente
Fuente: Elaboración propia
116
1.12 PRUEBAS
Durante el proceso de integración del sistema, se toman los subsistemas
desarrollados de forma independiente y se conjuntan para crear el sistema
completo. Una vez que los componentes han sido integrados, se procede a
realizar un proceso de pruebas.
Las pruebas del sistema implican integrar dos o más componentes que
implementan funciones del sistema o características para probar el sistema
integrado. En un proceso de desarrollo iterativo, las pruebas del sistema se
ocupan de probar un incremento que va a ser entregado al cliente; en un
proceso en cascada, las pruebas del sistema se ocupan de probar el sistema
completo
1.12.1 Diseño de caso de pruebas
El objeto de del proceso de diseño de caso de prueba es crear un conjunto
de casos de pruebas sean efectivos descubriendo defectos en los programas
y muestren que el sistema satisface sus requerimientos.
Para diseñar un sistema se selecciona una característica del sistema que se
está probando. A continuación, se selecciona un conjunto de entradas que
ejecutan dicha característica, documentadas las salidas esperadas o rangos
de salidas y, donde sea posible, se diseña una prueba automatizada que
prueba que las salidas reales y esperadas son las mismas [10].
Los diseños de casos de pruebas tienen varias aproximaciones que pueden
seguirse para diseñar los casos de pruebas y uno de ellos es denominado
Pruebas basadas en requerimiento. Las pruebas se realizaron al sistema
después de terminar la fase de implementación, se basan en comparar las
funcionalidades de los requerimientos, ejecutando el sistema a partir de la
especificación de los casos de uso.
117
Con el propósito de evaluar el sistema web y determinar si cumple con las
funciones para las cuales fueron diseñados, se desarrollaron pruebas de caja
negra para verificar las entradas, procesamientos y salidas del sistema, y así
validar si el resultado obtenido es que esperado. Los casos de pruebas que
se realizaron son los siguientes
Tabla 48. Prueba 01: Validar campos
RQ 01 CP1
Descripción Verificación en la validación de los campos correo y contraseña, intentado ingresar sin datos en los campos.
Entradas -Ingreso de contraseña -Clic en inicio
Salida esperada Mensaje indicando “Completa este campo”
Salida obtenida Mensaje indicando “Completa este campo”
Error Ninguno
Estado del caso de prueba
Concluido
Fuente: Elaboración propia
Tabla 49. Prueba 02: Autenticar usuario invalido
RQ 01 CP2
Descripción Verificación en la validación de los campos correo y contraseña, intentando ingresar con un correo no registrado.
Entradas -Ingreso de un correo -Ingreso de contraseña -Clic en inicio
Salida esperada Mensaje indicando “Algo salió mal en la búsqueda del usuario”
Salida obtenida Mensaje indicando “Algo salió mal en la búsqueda del usuario”
Error Ninguno
Estado del caso de prueba
Concluido
Fuente: Elaboración propia
118
Tabla 50. Prueba 03: Ingreso erróneo al sistema
Modulo Autentica usuario CP3
Descripción Verificación en el direccionamiento de la vista principal del sistema
Entradas -Ingreso de correo y contraseña -Clic en iniciar
Salida esperada Direccionamiento a vista principal
Salida obtenida Direccionamiento a vista principal
Error Ninguno
Estado del caso de prueba
Corregido
Fuente: Elaboración propia
Tabla 51. Prueba 04: Ingreso valido al sistema
Modulo Autenticar usuario CP4
Descripción Verificación en la validación de los campos usuario y contraseña, ingresando datos válidos.
Entradas correo y contraseña correctos
Salida esperada Direccionamiento a vista principal
Salida obtenida Direccionamiento a vista principal
Error Ninguno
Estado del caso de prueba
Concluido
Fuente: Elaboración propia
Tabla 52. Prueba 05: Registro de usuario erróneo
Modulo Generar cuentas CP5
Descripción Validar el registro de un usuario nuevo al sistema
Entradas -Completar formulario -Clic en Registrar
Salida esperada Mensaje indicando “Se ha registrado el usuario”
Salida obtenida Error en declaración de la variable direccion
Error No se crea la variable dirección en la base de datos
Estado del caso de prueba
Corregido
Fuente: Elaboración propia
119
Tabla 53. Prueba 06: Registro valido de un nuevo usuario
Modulo Generar cuentas CP6
Descripción Validación del registro de un nuevo usuario ingresando campos validos
Entradas -Completar formulario -Clic en Registrar
Salida esperada Mensaje indicando “Se ha registrado el usuario”
Salida obtenida Mensaje indicando “Se ha registrado el usuario”
Error Ninguno
Estado del caso de prueba
Corregido
Fuente: Elaboración propia
Tabla 54. Prueba 07: Crear historial con datos validos
Modulo Generar historial CP7
Descripción Verificación en la creación de un historial, completando todos los campos correctamente
Entradas -Completa formulario -Clic en guardar
Salida esperada Mensaje indicando “El registro ha sido satisfactorio”
Salida obtenida Mensaje indicando “El registro ha sido satisfactorio”
Error Ninguno
Estado del caso de prueba
Concluido
Fuente: Elaboración propia
Tabla 55. Prueba 08: Agenda de cita
Módulo Agendar cita CP8
Descripción Verificación en la validación de la asignación de cita ingresando todos los campos
Entradas -Registro completo del formato -Clic en Generar
Salida esperada Mensaje en pantalla “La cita ha sido agendada”
Salida obtenida Mensaje en pantalla “La cita ha sido agendada”
Error Ninguno
Estado del caso de prueba
Concluido
Fuente: Elaboración propia
120
Tabla 56. Prueba 09: Validar agenda
Módulo Agendar cita CP9
Descripción Validar que la hora y fecha registradas estén disponibles
Entradas Ingreso de fecha y hora ya asignada
Salida esperada Mensaje indicando “En este momento la agenda está ocupada”
Salida obtenida Error en la comparación de la llave primaria (idAlumno)
Error Comparación errónea con la llave primaria
Estado del caso de prueba
Corregido
Fuente: Elaboración propia
Tabla 57. Prueba 10: Valida agenda disponible
Módulo Agendar cita CP10
Descripción Validar que la hora y fecha ingresadas no estén disponibles
Entradas Ingreso de fecha y hora deseada
Salida esperada Mensaje indicando “En este momento la agenda está ocupada”
Salida obtenida Mensaje indicando “En este momento la agenda está ocupada”
Error Ninguno
Estado del caso de prueba
Concluido
Fuente: Elaboración propia
Tabla 58. Prueba 11: Validar modificación de historial
Módulo Crear historial CP11
Descripción Verificación en la validación de los campos: “Dimensión Social”, “Dimensión Escolar “valoración”, actualizando los campos correctamente.
Entradas -Campos modificados -Clic guardar
Salida esperada Mensaje indicando “El historial se actualizo correctamente”
Salida obtenida Mensaje indicando “El historial se actualizo correctamente”
Error Ninguno
Estado del caso de prueba
Concluido
Fuente: Elaboración propia
121
Tabla 59. Prueba 12: Validar los campos del historial
Módulo Crear Historial CP12
Descripción Verificación en la validación de los campos: “Nombre”, “grado”, “ID” , “Dimensión social” , “Dimensión escolar” , “Valoración” y Recomendaciones”, sin completarlos todos
Entradas -Ingreso de casi todos los campos -Clic guardar
Salida esperada Mensaje indicando “Completa todos los campos”
Salida obtenida Mensaje indicando “Completa todos los campos”
Error Ninguno
Estado del caso de prueba
Concluido
Fuente: Elaboración propia
Tabla 60. Prueba 13: Validar la consulta de historial
Módulo Consultar Historial CP13
Descripción Verificación en la validación en la consulta de un historial
Entradas -Selección de alumno -Clic en buscar
Salida esperada Mensaje indicando “Este es el historial del alumno ”
Salida obtenida Mensaje indicando “Este es el historial del alumno ”
Error Ninguno
Estado del caso de prueba
Concluido
Fuente: Elaboración propia
Tabla 61. Prueba 14: Validar consulta de historial erróneo
Módulo Consultar Historial CP14
Descripción Verificación de la consulta de un historial de un alumno que no tiene historial
Entradas -Selección de alumno -Clic en buscar
Salida esperada Mensaje Indicando “El alumno no tiene ningún historial”
Salida obtenida Mensaje Indicando “El alumno no tiene ningún historial”
Error Ninguno
Estado del caso de prueba
Concluido
Fuente: Elaboración propia
122
Tabla 62. Prueba 15: Validar compromiso
Módulo Compromiso CP15
Descripción Verificación en la validación en los campos: “Asistentes”, “Lugar” , “Descripción”, “Tema”, generando un error
Entradas -Registro del formato- -Clic en guardar
Salida esperada Mensaje indicando “El compromiso se ha registrado”
Salida obtenida Mensaje indicando “Algo malo ocurrió al crear el compromiso”
Error Se redirección a una vista diferente
Estado del caso de prueba
Corregido
Fuente: Elaboración propia
Tabla 63. Prueba 16: Validar registro de compromiso correcto
Módulo Compromiso CP16
Descripción Verificación en la validación en los campos: “Asistentes”, “Lugar” , “Descripción”, “Tema”, Almacenando datos válidos en los campos correctamente
Entradas Ingreso de datos en el formato de compromiso
Salida esperada Mensaje indicando “El compromiso se ha registrado”
Salida obtenida Mensaje indicando “El compromiso se ha registrado”
Error Ninguno
Estado del caso de prueba
Concluido
Fuente: Elaboración propia
Tabla 64. Prueba 17: Modificar compromiso
Módulo Compromiso CP17
Descripción Validar la modificación de un compromiso correctamente
Entradas -Modificar campos deseados -Clic en guardar
Salida esperada Mensaje indicando “El compromiso se actualizo correctamente”
Salida obtenida Mensaje indicando “El compromiso se actualizo correctamente”
Error Ninguno
Estado del caso de prueba
Concluido
Fuente: Elaboración propia
123
Tabla 65. Prueba 18: Validar registro de seguimiento
Módulo Seguimiento CP18
Descripción Verificación en el registro de un seguimiento ingresando en los campos: “Valoración”, “Estrategia”, “Resultado”, “Recomendaciones”, correctamente
Entradas -Registro del formato -Clic en guardar
Salida esperada Mensaje indicando “Se ha registrado el seguimiento”
Salida obtenida Mensaje indicando “Se ha registrado el seguimiento”
Error Ninguno
Estado del caso de prueba
Concluido
Fuente: Elaboración propia
Tabla 66. Pruebas 19: Verificar modificación de seguimiento
Módulo Seguimiento CP19
Descripción Verificación en la modificación de un seguimiento ingresando actualizado los campos: “Valoración”, “Estrategia”, “Resultado”, “Recomendaciones”, correctamente.
Entradas -Actualiza campos que desee -Clic en guardar
Salida esperada Mensaje indicando “El seguimiento se actualizo correctamente”
Salida obtenida Mensaje indicando “El seguimiento se actualizo correctamente”
Error Ninguno
Estado del caso de prueba
Concluido
Fuente: Elaboración propia
Tabla 67. Prueba 20: Validación de remisión externa
Módulo Remisión Externa CP20
Descripción Verificación en la validación de los campos: “IPS”, “Motivo de remisión”, “Valoración” y “Recomendaciones” correctamente
Entradas -Registro de formulario -Clic en guardar
Salida esperada Mensaje indicando “La remisión externa se ha registrado”
Salida obtenida Mensaje indicando “La remisión externa se ha registrado”
Error Ninguno
Estado del caso Concluido
124
de prueba
Fuente: Elaboración propia
Tabla 68. Prueba 21: Validar modificación de remisión externa
Módulo Remisión Externa CP21
Descripción Verificación modificación de los campos: “IPS”, “Motivo de remisión”, “Valoración” y “Recomendaciones” correctamente
Entradas -Actualiza campos que desee -Clic en guardar
Salida esperada Mensaje indicando “La remisión ha actualizado correctamente”
Salida obtenida Mensaje indicando “La remisión ha actualizado correctamente”
Error Ninguno
Estado del caso de prueba
Concluido
Fuente: Elaboración propia
Tabla 69. Prueba 22: Valida consulta de reportes-motivo
Módulo Reporte motivo CP22
Descripción Validar que las consultas de los reportes se muestren correctamente
Entradas Solicitud a ingreso de reportes-motivo
Salida esperada Direcciona a la vista de reportes
Salida obtenida Mensaje en pantalla “Algo malo ocurrió al consultar los reportes ”
Error No se llama la variable const
Estado del caso de prueba
Corregido
Fuente: Elaboración propia
Tabla 70. Prueba 23: Validar reportes-docente
Módulo Reporte Docente CP23
Descripción Validar la consulta de los reportes-docente
Entradas Solicitud a ingreso de reportes-docente
Salida esperada Mensaje indicando “La cantidad de remisiones son:”
Salida obtenida Mensaje indicando “La cantidad de remisiones son:”
Error Ninguno
Estado del caso de prueba
Concluido
Fuente: Elaboración propia
125
Tabla 71. Prueba 24: Verificar reportes sin remisiones
Módulo Reporte Motivo CP24
Descripción Verificar que muestre se en pantalla un mensaje cuando no haya reportes de dicho motivo correctamente
Entradas Solicitud a ingreso de reportes-motivo
Salida esperada Mensaje indicando “No hay remisiones con ese motivo”
Salida obtenida Mensaje indicando “No hay remisiones con ese motivo”
Error Ninguno
Estado del caso de prueba
Concluido
Fuente: Elaboración propia
126
RESULTADOS
La Ingeniería de Software como disciplina para la elaboración de proyectos
de software permite incorporar desde técnicas de estimaciones para un
proyecto hasta metodologías para implementar el desarrollo del mismo y así
poder optar por un software de calidad.
La metodología que se integra en este proyecto para el cumplimiento del
mismo, es la metodología en cascada, el cual incluye un modelo de
secuencias que se dividen en cinco etapas. La primera etapa consiste en
realizar un análisis previo de la problemática que se presentaba en el colegio
C.C.S, que se realizó mediante la aplicación de dos técnicas de elicitación
que se realizó junto el cliente, de modo que se encuentran en la sesión 7.1.1,
se realizó los diagramas de casos de uso (sesión 7.1.3), para definir los
requerimientos del sistema con el cliente (7.1.4).
La segunda etapa efectúa el diseño de la estructura lógica y física del
sistema, de manera que se obtienen los siguientes diagramas; diagrama de
clase (sesión 7.2.3); diagrama de despliegue (sesión 7.2.4); diagramas de
secuencia (sesión 7.2.5).
En la etapa de Implementación se procedió a la realización del código del
sistema mediante un stack de programas; Nodejs, JavaScript y Express,
donde se justifica su uso en la 7.3. Este conjunto de programas hacen
posible la ejecución del sistema, de tal forma se puede ver el frontend en la
sesión de
En la fase cuatro se implementan las pruebas del sistema. Las pruebas que
se implementaron fueron prueba de caja negra el cual permitieron validar
solamente las entradas y salidas del sistema a partir de varios diseños de
127
casos de pruebas. Las pruebas se pueden encontrar en la sesión de anexos
5.
En la última fase funcionamiento y mantenimiento, se compra el dominio y el
hosting del sistema, para después subir los archivos e instalar las
dependencias npm de nodeJs y así poner en funcionamiento el sistema y ser
entregado en su finalidad al cliente. Como constancia de la entrega final se
realiza un acta, el cual se encuentra en anexos 8.
Al incorporar esta disciplina en el proyecto se logra cumplir con el desarrollo
del sistema de información web cumpliendo exitosamente con todos los
requerimientos pactados con el cliente. Para ver las pruebas realizadas ir a
Anexos 5.
128
CONCLUSIONES
Posteriormente la implementación de la metodología cascada en la
elaboración del sistema de información web para el control de datos
psicoeducativos logra ser de vital importancia para implicar buenas prácticas
mediante la incorporación de todas sus fases, que juntas logran culminar
satisfactoriamente la implementación del sistema.
El ambiente de ejecución Node.js permitió generar un alto rendimiento y una
mayor optimización al crear herramientas del lado del servidor para así tener
un mayor rendimiento en el llamado de funciones y en el desarrollo como tal.
También permite una interacción con la base de datos mucho más ágil,
mediante el ORM sequelize.
El framework Express al ser flexible y rápido permitió agilizar la fase de
integración de una manera más breve permitiendo agilizar los procesos con
el servidor.
El sistema de información se realiza exitosamente por medio de todas las
herramientas, técnicas y metodologías nombradas anteriormente,
alcanzando la realización completa de todos los requerimientos pactados con
el cliente.
129
RECOMENDACIONES
No dejar de brindar mantenimiento y soporte al sistema web
Se recomienda tener un orden en los archivos del servidor de la
página web
Realizar capacitación del uso del sistema de información web a todos
los que intervienen en el proceso (Psicoorientador, docentes, entre
otros), esto con el fin de crear una cultura de cambio enfocado en
buscar soluciones más eficientes en la detención temprana de
situaciones de riesgo con los estudiantes.
Fomentar en el Psicoeducador y los Docentes el uso del sistema web
a través de dispositivos móviles (celular, computador, tablets), para
que utilicen la herramienta y capturen la información de cada alumno
remitido.
130
BIBLIOGRAFÍA
[1] E. Cantillo Lozano, M. Rueda Gomez y O. J. Fuquene, «Diseño e
implementación del sistema de información para la consulta de citas
externas en las áreas de medicina general, odontología y psicología,»
Bogotá, 2007.
[2] M. A. Aguilera Dagnino, «Desarrollo de un sitema web de controles de
citas, para un hospital del día,» Quito, 2013.
[3] C. K. Laudon y P. J. Laudon, Sistemas de Información Gerencial, 12.a
ed., Pearson, 2012.
[4] «Alegsa,» [En línea]. Available: http://www.alegsa.com.ar/. [Último
acceso: 12 02 2019].
[5] C. COMMONS, «CCM,» [En línea]. Available:
https://es.ccm.net/contents/304-lenguajes-de-programacion. [Último
acceso: 10 03 2019].
[6] «JavaScript,» [En línea]. Available:
http://www.vc.ehu.es/jiwotvim/ISOFT2008-
2009/Teoria/BloqueIV/JavaScript.pdf. [Último acceso: 17 02 2019].
[7] «Visual Studio Code,» [En línea]. Available:
https://code.visualstudio.com/docs. [Último acceso: 20 04 2019].
[8] «NodeJs,» [En línea]. Available: https://nodejs.org/es/docs/. [Último
acceso: 19 04 2019].
[9] J. Núñez, «Solucionex, onsultoría tecnológica,» [En línea]. Available:
https://www.solucionex.com/blog/expressjs-un-framework-para-nodejs.
[Último acceso: 19 04 2019].
[10] S. Ian, Ingenierìa de Software, 7 ma ed., Pearson Addison Wesley, 2005.
131
[11] J. Rumbaugh, I. Jacobson y G. Booch, El Lenguaje Unificado de Modelo.
Manual de Referencia, Addison Wesley, 2000.
[12] U. d. Alicante, «Modelo vista controlador (MVC),» [En línea]. Available:
https://si.ua.es/es/documentacion/asp-net-mvc-3/1-dia/modelo-vista-
controlador-mvc.html. [Último acceso: 03 06 2019].
[13] G. Pantaleon y L. Rinaudo, Ingeniería de Software, Alfaomega, 2015.
[14] J. Schmuller, Aprendiendo UML en 24 horas, Prentice Hall, 2000.
[15] C. Larman, UML y Patrones. Introdución al análisis y diseño orientado a
objetos, Pearson, 2003.
132
ANEXOS
Anexos 1. Carta de finalización
Ilustración 49. Acta de finalización del proyecto.
Fuente: Propia