Fingeso_Hito 3 implementación_IngCivInf_Usach.pdf

Presentación del Hito 3 (implementación) de Fundamentos de Ingeniería de Software de Ingeniería Civil Informática de la Usach.

1. UNIMED-HITO 3:
IMPLEMENTACIÓNIntegrantes (Grupo [ ]):
Alfonso Palacios
Sus compañeros de
equipo anónimos

2. CONTENIDOS
01
04
02
05
03
06Introducción Enunciado del
proyecto Descripción del
problema Objetivos del
proyecto Situación actual Descripción de la
solución planteada
07Diseño de la solución
08Construcción de la
solución
09Conclusiones
2

3. UNIMED
En esta presentación se busca evidenciar el
trabajo llevado a cabo en el hito 3, tomando en
cuenta la retroalimentación recibida en entregas
anteriores y llevando a cabo la implementación.
¿ DE QUÉ SE HABLARÁ?
3

4. DESCRIPCIÓN DEL PROBLEMA
Respecto a la población que tuvo atención
casi 4 de cada 10 personas manifestaron tener
algún tipo de problema, entre los principales
se encuentra “Problemas para conseguir una
cita medica”
El 61% de la población insatisfecha con la
disponibilidad de servicios de salud de
calidad.
SITUACIÓN ACTUAL
Fuentes:
https://observatorio.ministeriodesarrollosocial.gob.cl/storage/docs/casen/2022/Resultados_Salud_Casen2022.pdf
https://www.cepchile.cl/investigacion/voces-del-cep-02-enero-2024/
4

5. DESCRIPCIÓN DEL PROBLEMA
Los pacientes no tienen
cómo gestionar sus citas
médicas. Así como
también acceder a un
respaldo de sus recetas
u ordenes medicas.
Gestionar datos y
documentos médicos
asociados a los pacientes,
gestionar procesos
logísticos de medicamentos
dentro de farmacia, permitir
la administración de citas
medicas dentro del
establecimiento.PROBLEMA OBJETIVOS
SOLUCIÓN FUTURA
5

6. HITO PROYECTO
GENERALES:
El objetivo general del proyecto es
desarrollar un sistema que incluya una
página web, donde pacientes de un hospital
puedan reservar citas médicas, gestionar
medicamentos y recetas médicas.
Para este hito, se busca la construcción del
sistema web, donde estén implementados dos
casos de usos.
OBJETIVOS
GENERALES:
ESPECIFICOS:
ESPECIFICOS:Levantamiento de requisitos
Asesorar la calidad del software
Diseño de la arquitectura de software
Diseño e implementación de software
Diseño de la interfaz de usuario
Utilizar herramientas para probar el
software
Llevar a cabo labores de administración
del software
Creación de un respositorio para el trabajo en
equipo
Preparación de los entornos de desarrollo en
cada equipo
Creación del proyecto utilizando Springboot
Crear las clases necesarias para la
implementación de acuerdo a la vista lógica
Implementación de casos de uso estipulados
6

7. DESCRIPCIÓN DE LA SOLUCIÓN
Consiste en un sistema web que mejore la gestión
lógica y administrativa de pacientes y citas medicas
dentro del establecimiento de salud para aumentar
la eficiencia en el agendamiento y atenciones de
consultas medicas. Así también, que permita la
gestión de los medicamentos dentro de farmacia,
para permitir un mejor control del stock de fármacos.
SOLUCIÓN:
7

8. DESCRIPCIÓN DE LA SOLUCIÓNEl sistema usará Spring Boot (Java), Vue 3 y
PostgreSQL.
Se podrán hacer pruebas controladas desde
computadores personales.
Se implementarán funciones para los actores según
los requisitos del hito 1 (ajustados en el hito 2).
El sistema ofrecerá un servicio web funcional con
dichas funciones.
El proyecto incluye documentos y diagramas del
proceso de desarrollo.
El sistema se adaptará al contexto de un centro
médico, según lo recogido en entrevistas.
ALCANCES LIMITACIONESEl sistema no se conectará con plataformas de salud como
FONASA o isapres.
No será probado por usuarios reales.
Solo podrá usarse desde un navegador en computadora.
Estará hecho para un único establecimiento, aunque el diseño
considera escalabilidad.
Aunque se mencionó la seguridad, no se priorizará implementar
algoritmos para ella.
El desarrollo tiene recursos y tiempo limitados por tratarse de
un proyecto académico.
No se evaluará el rendimiento con muchos usuarios; solo lo
usarán cuatro estudiantes a la vez.
8

9. Stakeholder Relevancia Código
Médico Alta STK_001
Paciente Alta STK_002
Secretario Alta STK_003
Staff TI Baja STK_004
Farmacéutico Alta STK_005
Administrador del hospital Baja STK_006
STAKEHOLDERS
9

10. Actor Código
Médico ACT_001
Paciente ACT_002
Secretario ACT_003
Staff TI ACT_004
Farmacéutico ACT_005
ACTORES
10

11. 11
MATRIZ CU VS RF

12. ID Nombre Usuario
RF020 Medico genera recetas a pacientes Medico
RF025 Contenido obligatorio en recetas Medico
RF026 Mensajes de error comprensibles
Paciente, médico, Secretario, Staff TI,
Farmacéutico, Administrador de farmacia
RF027 Farmacéutico busca medicamentos Farmacéutico
RF028 Farmacéutico vende medicamentos Farmaceutico
REQUERIMIENTOS FUNCIONALES
12

13. ID Nombre Descripción Categoria
RNF002 Formato de recetas Medicas
Las recetas médicas generadas por el sistema
deben seguir un formato estandarizado que
incluya: Información del paciente (nombre
completo, RUN, edad) y del establecimiento de
salud. Detalles de los medicamentos prescritos
(nombre, dosis, frecuencia) y datos del médico
responsable (nombre completo, especialidad,
firma digital).
Lo anterior con el fin de cumplir con lo
establecido por el Ministerio de Salud de Chile en
el decreto 466, artículo 38. (1985).
Regulación
legal
RNF008
Accesibilidad desde aplicación
web
El sistema debe poder ser accesible por medio de
una aplicación web, esto a través de algún
navegador web de escritorio.
Desarrollo
REQUERIMIENTOS NO FUNCIONALES
13

14. ID Nombre Descripción Categoria
RNF009
Tecnologías para
desarrollar el software
El sistema debe estar desarrollado con las siguientes
tecnologías, cuya versión será verificada en el entorno de
desarrollo y producción:
Spring Boot con Maven versión 3.4.6 y Java versión 17, Node.js
versión LTS 21.7.1, Vue.js versión 3."
Desarrollo
RNF010
Tecnologías para
alojar bases de datos
El sistema debe utilizar como sistema de gestión de base de
datos PostgreSQL, en su versión 16.9, verificado mediante
inspección del motor de base de datos en el entorno de
producción.
Desarrollo
RNF011 Tipo de arquitectura El sistema debe contar con una arquitectura monolitica Desarrollo
RNF012 Datos encriptados
La información guardada en la base de datos debe estar
encriptada utilizando el cifrado
AES-256, procurando la seguridad de los datos sensibles.
Seguridad
REQUERIMIENTOS NO FUNCIONALES
14

15. DISEÑO DE LA SOLUCIÓN
15

16. VISTA ESCENARIOS
16
<<include>><<include>> <<include>><<include>>

17. 17
NARRACIÓN CU_004

18. 18
NARRACIÓN CU_010

19. 19
MATRIZ CU VS
OP

20. VISTA DE PROCESOS - CU_004
20

21. 21
VISTA DE PROCESOS - CU_004 (PARTE 1)

22. 22
VISTA DE PROCESOS - CU_004 (PARTE 2)

23. 23
VISTA DE PROCESOS - CU_010

24. 24
VISTA DE PROCESOS - CU_010
(PARTE 1)

25. 25
VISTA DE PROCESOS - CU_010 (PARTE 2)

26. VISTA DESARROLLO
26

27. VISTA
LÓGICA
27

28. VISTA FÍSICA
28

29. CONSTRUCCIÓN DE LA
SOLUCIÓN
29

30. MVC
30

31. SPRINGBOOT
(3.4.6)
JAVA 17
(JDK)
VUE
(3.5.16)
POSTGRESQL
(16.9)
FRAMEWORK PARA
EL DESARROLLO DE
APLICACIONES
LENGUAJE
ORIENTADO A
OBJETOS
FRAMEWORK PARA
CONSTRUIR
INTERFACES DE
USUARIO
SISTEMA DE
GESTIÓN DE BASES
DE DATOS
RELACIONALES
CONSIDERACIONES DE LA SOLUCIÓN
31

32. INTELLIJ
(21.0.7)
TYPESCRIPT
(5.8.3)
VUETIFY
(3.8.9)
GITHUB
ENTORNO DE
DESARROLLO
INTEGRADO
LENGUAJE DE
PROGRAMACIÓN
BASADO EN
JAVASCRIPT
FRAMEWORK QUE
PROPORCIONA
COMPONENTES
PRECONSTRUIDOS
PLATAFORMA
UTILIZADA PARA EL
CONTROL DE
VERSIONES DEL
PROYECTO
CONSIDERACIONES DE LA SOLUCIÓN
32

33. Corresponden a la
abstracción del
elemento en la
realidad, es decir, las
características y
funciones que puede
llevar a cabo
Utilizados para
encapsular la lógica de
acceso a datos y
establecer una interfaz
para interactuar con la
base de datos
Se define la lógica de
negocio, es decir, las
reglas que rigen la
interacción de la
interfaz de usuario con
la base de datos
Establecen el manejo de
las solicitudes HTTP y
utilizan la lógica negocio
ENTIDADES
REPOSITORIOS SERVICIOS
ELEMENTOS DEL CÓDIGO
33
CONTROLADORES

34. Corresponden a los
componentes del
código que encapsulan
la lógica de consulta la
sistema.
Utilizados para
establecer elementos
del Front-End, es decir,
qué mostrar dado cierto
contexto.
Se definen las
conexiones entre vistas,
por lo que el sistema a
dónde ir dada cierta
ruta.
Archivos utilizados para
configurar aspectos
como las sesiones de
los usuarios y
encriptación de
contraseñas.
DTO VIEWS ROUTER
ELEMENTOS DEL CÓDIGO
34
CONFIGURACIÓN

35. 35
EJEMPLO - CITA MÉDICA
ENTIDAD

36. 36
EJEMPLO - CITA MÉDICA
RESPOSITORIO

37. 37
EJEMPLO - CITA MÉDICA
SERVICIO

38. 38
EJEMPLO -
CITA MÉDICA
SERVICIO

39. 39
EJEMPLO
- CITA
MÉDICA
CONTROLADOR

40. 40
EJEMPLO -
CITA
MÉDICA
CONTROLADOR

41. 41
EJEMPLO -
CITA MÉDICA
CONTROLADOR

42. 42
EJEMPLO -
CITA MÉDICA
CONTROLADOR

43. 43
Ejemplo - Cita médica
DTO - Solicitud DTO - Respuesta

44. 44
Ejemplo - Cita
médica
Vista - HTML

45. 45
Ejemplo - Cita
médica
Vista - HTML

46. 46
EJEMPLO - CITA MÉDICA
VISTA - TYPESCRIPTFunción onMounted que
realiza determinadas
operaciones una vez se abra
esta vista

47. 47
RUTAS EN EL ROUTER

48. 48
RUTAS EN EL ROUTER

49. 49
CONFIGURACIÓN
CONFIGURACIÓN DE SEGURIDAD
CONFIGURACIÓN DE LA SESIÓN ACTIVA
Hashing in Action: Understanding bcrypt. (s. f.). Auth0 - Blog. https://auth0.com/blog/hashing-in-action-understanding-bcrypt/

50. CONCLUSIONES OBJETIVOS CUMPLIDOS
50
Se creó un repositorio donde se llevó un
control de las versiones generadas a lo largo
del proceso
Se prepararon los computadores de los
integrantes para desarrollar elementos de la
aplicación
Se inicializó el proyecto usando Springboot
Se generaron clases de acuerdo a lo
estipulado en los diagramas y en lo necesario
para el funcionamiento según la arquitectura
elegida

51. CONCLUSIONES Poco tiempo para la realización del primer
acercamiento de la implementación
✓ Realizar un trabajo eficiente, encontrando
apoyo en el uso de inteligencia artificial para
comprender el código que se puede utilizar
Necesidad de aprender muchas cosas sobre
el desarrollo en poco tiempo
✓ Investigación y apoyo con inteligencias
artificiales
51
COMPLICACIONES

52. FEEDBACK
CONTROL DE
CALIDAD
ALFA
IMPLEMENTAR
MEJORAS
TESTINGPASOS A SEGUIR
52
DOCUMENTACIÓN

53. ¿CÓMO SE PODRÍA DESARROLLAR UN PRODUCTO
DE SOFTWARE EN ESTE CONTEXTO? 53

54. 54
MODELO INCREMENTAL
Necesidad de mejorar el sistema constantemente
Levantamiento de requisitos para necesidad no cubiertas
Se puede entregar una versión usable a la que se le añadirán nuevas funcionalidades en una
siguiente versión

55. Levantamiento de requisitos inicial
Identificar procesos del sistema y de
acuerdo a ello establecer objetivos del
proyecto
Considerando el modelo propuesto,
separar los requisitos por grupos de
acuerdo a prioridad de acuerdo a algún
criterio.
55
DESARROLLO DE SOFTWARE

56. 56
Diseñar diagramas correspondientes a las vistas
del modelo 4+1.
Definir la arquitectura adecuada para el
sistema. Si bien no es posible establecer una
arquitectura sin antes haber llevado a cabo el
análisis, se propone una arquitectura MVC, dado
que admite la presentación de datos
independiente de su tipo. Considerando el
modelo con el cual se va trabajar, es
conveniente tener flexibilidad para cambios.
Diseñar la interfaz de usuario de acuerdo a lo
encontrado en el levantamiento de requisitos y
las estrategias para ello.
DESARROLLO DE SOFTWARE

57. 57
IMPLEMENTACIÓN
Comenzar el desarrollo incremental, donde se tienen los pasos de:
Análisis y refinamiento del incremento
Implementación
Pruebas
Validación Interna
Documentar el sistema y entregarlo, esto incluye por ejemplo un
manual de usuario para cada actor, así como un repositorio con
instrucciones para su ejecución.
Mantenimiento y mejora continua
Iteración del proceso

58. GRACIAS POR
SU ATENCIÓN
58