Universidad autónoma Gabriel René Moreno

Facultad de ingeniería en ciencias de la computación y

Telecomunicaciones

SOFTWARE PARA EL PROCESOS DE ANALISIS, DIAGNOSTICO Y

SUGERENCIAS A PARTIR DE UN SCANNER DE LABORATORIO
PAPS (Plan de Administración de Proyectos de Software)

INTEGRANTES:
Padilla Yapura José Luis
Avalos Seviche Gerald José
Maldonado Gutiérrez Daniel
Ortiz Serrano Edilson
DOCENTE:
ING. Rolando Martínez

ASIGNATURA
Ingeniería de Software I (INF-422)

FECHA: 06/12/2023
 2
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

CONTENIDO

1. PERFIL ...................................................................................................................................5
1.1. Descripción del problema ...................................................................................................5
2. METRICAS .............................................................................................................................6
2.1. Bip4Cast ............................................................................................................................6
2.1.1. Funcionalidades Importantes .......................................................................................6
2.1.2. Captura de Interfaces...................................................................................................6
2.1.3. Características del Desarrollador .................................................................................7
2.1.4. Aplicación de Métricas Orientado al Tamaño................................................................7
2.1.5. Aplicación de Métricas Orientado a la Función .............................................................7
2.2. MDxApp............................................................................................................................9
2.2.1. Funcionalidades Importantes .......................................................................................9
2.2.2. Captura de Interfaces...................................................................................................9
2.2.3. Características del Desarrollador ...............................................................................10
2.2.4. Aplicación de Métricas Orientado al Tamaño..............................................................10
2.2.5. Aplicación de Métricas Orientado a la Función ...........................................................11
2.3. App Web ML-MT ...........................................................................................................12
2.3.1. Funcionalidades Importantes .....................................................................................12
2.3.2. Captura de Interfaces.................................................................................................12
2.3.3. Características del Desarrollador ...............................................................................13
2.3.4. Aplicación de Métricas Orientado al Tamaño..............................................................13
2.3.5. Aplicación de Métricas Orientado a la Función ...........................................................13
3. DEFINICIONES PARA LA ESTIMACION............................................................................15
3.1. Dimensiones del Proyecto .................................................................................................15
3.1.1. Tamaño .....................................................................................................................15
3.1.2. Complejidad del proyecto...........................................................................................15
3.1.3. Estructuración del Cliente ..........................................................................................15
3.2. Ámbito del Proyecto .........................................................................................................16
3.2.1. Objetivos del proyecto ................................................................................................16
3.2.2. Requerimientos principales ........................................................................................16
3.2.3. Rendimiento ..............................................................................................................17
 3
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

3.2.4. Fiabilidad ..................................................................................................................17

3.2.5. Restricciones .................................................................................................................17
3.2.5.1. Restricciones de Tiempo ..........................................................................................17
3.2.5.2. Restricciones de Alcance ..........................................................................................18
3.2.5.3. Restricciones de Coste .............................................................................................19
3.2.6. Interfaces externas ........................................................................................................20
3.2.6.1. Interacciones con Software ......................................................................................20
3.2.6.2. Interacciones con Personas ......................................................................................20
3.2.6.3. Interacciones con Hardware ....................................................................................20
4. ESTIMACIONES ..................................................................................................................20
4.1. Valor Esperado ............................................................................................................20
3.7.2. Cocomo II..................................................................................................................21
3.7.3. Ecuación del Software ................................................................................................22
3.7.4. Planning Poker ..........................................................................................................23
4. GESTION DE RIESGO .........................................................................................................24
5. PLANIFICACIÓN DEL TIEMPO ..........................................................................................25
5.1. Planificación ....................................................................................................................25
5.2. Diagrama de Gantt...........................................................................................................26
6. TABLA DE RECURSOS ........................................................................................................27
7. ORGANIZACIÓN INTERNA ................................................................................................29
8. MECANISMOS DE SEGUIMIENTO Y CONTROL ...............................................................30
8.1. Revisión Técnica Formal(RTF) .........................................................................................30
9. METODOLOGIA DE DESARROLLO ...................................................................................33
9.1. Tecnologías para el desarrollo del proyecto .......................................................................33
9.1.1. Hardware ..................................................................................................................33
9.1.2. Software ....................................................................................................................34
9.1.3. Proceso de Software ...................................................................................................35
9.1.4. Modelado de Software ................................................................................................35
9.1.5. Puesta en marcha/despliegue ......................................................................................36
9.2. Proceso de Desarrollo de Software ....................................................................................36
9.2.1. Scrum........................................................................................................................36
 4
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

9.2.1.2. Modelos para el desarrollo Scrum ...................................................................................38

10. SPRINT 0.............................................................................................................................41
10.1. Definiciones Iniciales ......................................................................................................41
10.2. Base de Datos .................................................................................................................42
11. SPRINT 1.............................................................................................................................42
11.1. Sprint Planing ................................................................................................................42
11.1.1. Objetivos del Sprint .................................................................................................42
11.1.2. Historias de Usuario .................................................................................................43
11.1.3. Contexto del sistema .................................................................................................45
11.1.4. Sprint Backlog .........................................................................................................45
11.2. Proceso de desarrollo por Historia de Usuario .................................................................47
11.2.1. Diseño......................................................................................................................47
10.3. Sprint Review.................................................................................................................48
10.4. Sprint Retrospective .......................................................................................................49
11. SPRINT 2.............................................................................................................................49
11.1. Sprint Planning ..............................................................................................................49
11.1.1. Objetivos del Sprint .................................................................................................49
11.1.2. Historias de Usuario .................................................................................................50
11.1.3. Contexto del sistema .................................................................................................50
11.1.4. Sprint Backlog .........................................................................................................53
11.2. Proceso de desarrollo por Historia de Usuario .................................................................54
11.2.1. Diseño......................................................................................................................54
11.2.2. Implementación .......................................................... ¡Error! Marcador no definido.
11.2.3. Pruebas ...................................................................... ¡Error! Marcador no definido.
11.3. Sprint Review.................................................................................................................56
11.4. Sprint Retrospective .......................................................................................................57
ANEXOS ...................................................................................................................................58
BIBLIOGRAFIA .......................................................................................................................63
 5
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

1. PERFIL

1.1. Descripción del problema

Introducción al problema
En el ámbito de la atención médica, la interpretación precisa y rápida de los análisis clínicos es
esencial para la toma de decisiones clínicas efectivas. La creciente cantidad de información
médica, a menudo presentada en documentos, plantea desafíos en la eficiencia y precisión del
análisis por parte de los profesionales de la salud, ya que grandes volúmenes de información que
deben ser analizadas representan desafíos en la gestión de su manejo.

Alcance del problema

El problema se centra en la dificultad de analizar con rapidez grandes números de documentos
médicos, ya sea en formato PDF o imágenes, de manera eficiente por ello surge la necesidad de
una herramienta que pueda extraer información relevante de documentos médicos y proporcionar
diagnósticos y sugerencias basadas en el análisis clínico.

Impacto y consecuencias
La falta de una solución efectiva puede resultar en diagnósticos tardíos o imprecisos, afectando
negativamente la calidad de la atención médica. La demora en la interpretación de los resultados
de los análisis clínicos puede tener consecuencias graves para la salud del paciente.

Perspectivas de las partes interesadas

 Médicos, enfermeros y profesionales de la salud que dependen de la interpretación rápida
y precisa de los análisis clínicos.
 Pacientes que buscan un diagnóstico preciso y un tratamiento oportuno.

Contexto externo
Avances en tecnologías de procesamiento de imágenes y procesamiento del lenguaje natural que
podrían ser aplicadas a la interpretación de documentos médicos.

Relevancia del problema

La importancia de contar con un analizador automatizado que mejore la eficiencia y la precisión
en la interpretación de análisis clínicos en el entorno médico actual. Este proyecto busca abordar
la complejidad y la demanda creciente en la interpretación de análisis clínicos mediante el
desarrollo de un analizador que pueda procesar documentos médicos en diversos formatos,
proporcionando diagnósticos precisos y sugerencias clínicas útiles para el personal médico.
 6
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

2. METRICAS

2.1. Bip4Cast
Aplicación de Android para recopilar datos para su análisis con fines médicos. Su desarrollo se
inició como parte de un proyecto de fin de carrera en la UCM (Universidad Complutense de
Madrid), que se puede encontrar como "Sistema para predecir crisis de trastorno bipolar
mediante el análisis de datos masivos". Esta aplicación móvil se está utilizando en el proyecto
Bip4cast, en el que se están recopilando datos de pacientes del hospital San Juan de Dios con
el objetivo de mejorar el tratamiento del trastorno bipolar, cuyas crisis pueden evitarse mediante
una predicción temprana.

2.1.1. Funcionalidades Importantes

 recopilar datos para su análisis con fines médicos

2.1.2. Captura de Interfaces

Ilustración 1: Interfaz
Fuente (Elaboración Propia)

Ilustración 2: Interfaz
Fuente (Elaboración Propia)
 7
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

2.1.3. Características del Desarrollador

Desarrollo basado en Android: utiliza Android, conocido por su estructura modular y su
comunidad de desarrolladores.
Código abierto: es una aplicación de código abierto, lo que permite a los desarrolladores acceder
y modificar el código fuente.
Comunidad activa: cuenta con una comunidad de desarrolladores activa(github) que brinda soporte
y contribuye al desarrollo continuo.

2.1.4. Aplicación de Métricas Orientado al Tamaño

Proyecto KLDC Costo Tiempo Esfuerzo Pag. Gente Errores Defectos

Doc.
Aplicación 38773 4793 2.13 6.39 140 3 30 19
de
Android
para
recopilar
datos
médicos

𝐸+𝐷
Calidad = 𝐾𝐿𝐷𝐶 = 0.00126370
𝐾𝐿𝐷𝐶
Productividad = 𝐸𝑠𝑓𝑢𝑒𝑟𝑧𝑜 = 6067.76

2.1.5. Aplicación de Métricas Orientado a la Función

Factor de peso
Parámetro de medición Cuenta Simple Medio Complejo Total
Número de entradas de Usuario 24 3 4 6 96
Número de Salidas de Usuario 6 4 5 7 42
Número de peticiones de Usuario 6 3 4 6 18
Número de Archivos 1 7 10 15 7
Número de Interfaces Externas 1 5 7 10 5
Cuenta Total 168

Tabla 2: Tabla de Métricas

Fuente (Elaboración Propia)
 8
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

Factor No influye Incidental Moderado Medio Significativo Esencial fi

0 1 2 3 4 5

1. ¿Requiere el sistema copias de seguridad y X 4

de recuperación fiable?
2. ¿Se requiere de comunicación de datos? X 5
3. ¿Existen funciones de procesamiento X 2
distribuido?
4. ¿Es crítico el rendimiento? X 2
5. Se ejecutará el sistema en un entorno X 3
operativo existente y fuertemente utilizado?
6. ¿Requiere el sistema entrada de datos X 3
interactiva?
7. ¿Requiere la entrada de datos interactiva que X 4
las transacciones de entrada se lleven a cabo
sobre múltiples pantallas u operaciones?
8. ¿Se actualizan los archivos maestros de X 0
forma interactiva?
9. ¿Son complejas las entradas, salidas, X 1
archivos o las peticiones?
10. ¿Es complejo el procesamiento interno? X 1
11. ¿Se ha diseñado el código para ser X 2
reutilizable?
12. ¿Están incluidas en el diseño la conversión X 1
y la instalación?
13. ¿Se ha diseñado el sistema para soportar X 3
múltiples instalaciones en diferentes
organizaciones?
14. ¿Se ha diseñado la aplicación para facilitar X 2
los cambios y para ser fácilmente utilizada por
el usuario?
∑ 33

Tabla 3: Tabla de Métricas de StoryBooks

Fuente (Elaboración Propia)

14

𝑝𝑓 = 𝑐𝑡𝑜𝑡𝑎𝑙 ⋅ [0.65 + 0.01 ⋅ ∑ 𝑓𝑖 ]

𝑖=1
𝑝𝑓 = 164.64
 9
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

2.2. MDxApp
MDxApp es una app que utiliza ChatGPT (un chatbot desarrollado recientemente por Open AI)
como proxy para ayudar a proponer un diagnóstico rápido según la demografía del paciente, un
contexto ambiental reciente, una lista de síntomas recientes y relevantes. observaciones sobre
el estado del paciente y cualquier condición crónica existente seguidas de indicaciones sobre
cualquier tratamiento existente.

2.2.1. Funcionalidades Importantes

 diagnóstico rápido según la demografía del paciente,
 lista de síntomas recientes y relevantes. observaciones sobre el estado del paciente y cualquier condición
crónica existente
 indicaciones sobre cualquier tratamiento existente

2.2.2. Captura de Interfaces

Ilustración 5: Interfaz
Fuente (Elaboración Propia)
 10
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

Ilustración 6: Interfaz
Fuente (Elaboración Propia)

2.2.3. Características del Desarrollador

 la app está basada en Phyton y CSS
 es de código abierto
 cuenta con soporte de mantenimiento proporcionado por la comunidad de GitHub

2.2.4. Aplicación de Métricas Orientado al Tamaño

Proyecto KLDC Costo(euros) Tiempo Esfuerzo Pag. Gente Errores Defectos

Doc.
MDxApp 1854 4000 0.16 0.16 120 1 13 13

Calidad = 0.0140
Productividad = 11587.5
 11
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

2.2.5. Aplicación de Métricas Orientado a la Función

Factor de peso
Parámetro de medición Cuenta Simple Medio Complejo Total
Número de entradas de Usuario 4 3 4 6 12
Número de Salidas de Usuario 5 4 5 7 20
Número de peticiones de Usuario 3 3 4 6 9
Número de Archivos 6 7 10 15 42
Número de Interfaces Externas 1 5 7 10 5
Cuenta Total 77

Tabla 4: Tabla de Métricas

Fuente (Elaboración Propia)

Factor No influye Incidental Moderado Medio Significativo Esencial fi

0 1 2 3 4 5

1. ¿Requiere el sistema copias de seguridad y X 0

de recuperación fiable?

2. ¿Se requiere de comunicación de datos? X 5

3. ¿Existen funciones de procesamiento X 1
distribuido?
4. ¿Es crítico el rendimiento? X 2
5. Se ejecutará el sistema en un entorno X 3
operativo existente y fuertemente utilizado?
6. ¿Requiere el sistema entrada de datos X 5
interactiva?
7. ¿Requiere la entrada de datos interactiva que X 2
las transacciones de entrada se lleven a cabo
sobre múltiples pantallas u operaciones?
8. ¿Se actualizan los archivos maestros de X 4
forma interactiva?
9. ¿Son complejas las entradas, salidas, X 1
archivos o las peticiones?
10. ¿Es complejo el procesamiento interno? X 0
11. ¿Se ha diseñado el código para ser X 2
reutilizable?
 12
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

12. ¿Están incluidas en el diseño la conversión X 2

y la instalación?
13. ¿Se ha diseñado el sistema para soportar X 2
múltiples instalaciones en diferentes
organizaciones?
14. ¿Se ha diseñado la aplicación para facilitar X 1
los cambios y para ser fácilmente utilizada por
el usuario?
∑ 30

Tabla 5: Tabla de Métricas

Fuente (Elaboración Propia)

𝑃𝐹 = 𝑐𝑜𝑛𝑡𝑒𝑜 𝑡𝑜𝑡𝑎𝑙 × [0.65 + 0.01 × ∑(𝐹𝑖)]

𝑃𝐹 = 77 × [0.65 + 0.01 × 30]
𝑃𝐹 = 73

2.3. App Web ML-MT

App web de predicción de enfermedades que usa el concepto de aprendizaje automático, hace
predicciones sobre diversas enfermedades como malaria, neumonía etc.

2.3.1. Funcionalidades Importantes

 predicción de enfermedades usando el aprendizaje automático

2.3.2. Captura de Interfaces

Ilustración 9:
Fuente (Elaboración Propia)
 13
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

2.3.3. Características del Desarrollador

 la app está basada en Phyton, HTML y CSS
 es de código abierto
 cuenta con soporte de mantenimiento proporcionado por la comunidad de GitHub

2.3.4. Aplicación de Métricas Orientado al Tamaño

Proyecto KLDC Costo(euros) Tiempo Esfuerzo Pág. Gente Errores Defectos

Doc.
App 194007 4000 19 57 100 3 7 7
Web
ML-MT

Calidad = 0.00007216
Productividad = 3403.63

2.3.5. Aplicación de Métricas Orientado a la Función

Factor de peso
Parámetro de medición Cuenta Simple Medio Complejo Total
Número de entradas de Usuario 18 3 4 6 72
Número de Salidas de Usuario 145 4 5 7 1015
Número de peticiones de Usuario 15 3 4 6 60
Número de Archivos 36 7 10 15 540
Número de Interfaces Externas 12 5 7 10 120
Cuenta Total 1837

Tabla 6: Tabla de Métricas

Fuente (Elaboración Propia)
 14
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

Factor No influye Incidental Moderado Medio Significativo Esencial fi

0 1 2 3 4 5

1. ¿Requiere el sistema copias de seguridad y X 0

de recuperación fiable?
2. ¿Se requiere de comunicación de datos? X 5
3. ¿Existen funciones de procesamiento X 1
distribuido?
4. ¿Es crítico el rendimiento? X 2
5. Se ejecutará el sistema en un entorno X 1
operativo existente y fuertemente utilizado?
6. ¿Requiere el sistema entrada de datos X 2
interactiva?
7. ¿Requiere la entrada de datos interactiva que X 2
las transacciones de entrada se lleven a cabo
sobre múltiples pantallas u operaciones?
8. ¿Se actualizan los archivos maestros de X 1
forma interactiva?
9. ¿Son complejas las entradas, salidas, X 3
archivos o las peticiones?
10. ¿Es complejo el procesamiento interno? X 3
11. ¿Se ha diseñado el código para ser X 2
reutilizable?
12. ¿Están incluidas en el diseño la conversión X 2
y la instalación?
13. ¿Se ha diseñado el sistema para soportar X 0
múltiples instalaciones en diferentes
organizaciones?
14. ¿Se ha diseñado la aplicación para facilitar X 1
los cambios y para ser fácilmente utilizada por
el usuario?
∑ 24

Tabla 7: Tabla de Métricas

Fuente (Elaboración Propia)

𝑃𝐹 = 𝑐𝑜𝑛𝑡𝑒𝑜 𝑡𝑜𝑡𝑎𝑙 × [0.65 + 0.01 × ∑(𝐹𝑖)]

𝑃𝐹 = 1837 × [0.65 + 0.01 × 24]
𝑃𝐹 = 1635
 15
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

3. DEFINICIONES PARA LA ESTIMACION

3.1. Dimensiones del Proyecto

3.1.1. Tamaño

El tamaño del proyecto estará definido por la cantidad de elementos establecidos en el apartado de
Product Backlog y la cantidad de líneas de código medidas en KLDC.

 El proyecto cuenta con 11 elementos en total según el Product Backlog, el cual se aprecia
en la tabla de product backlog.

 La cantidad de líneas de código del proyecto es de (pendiente) KLDC.

En conclusión, el tamaño del proyecto es mediano.

3.1.2. Complejidad del proyecto

El equipo está conformado por programadores junior que tienen un nivel medio de familiaridad
con el desarrollo en diferentes plataformas e integraciones como inteligencia artificial. Conscientes
de la importancia de ofrecer funcionalidades novedosas en el análisis de documentos médicos,
hemos optado por utilizar tecnologías confiables como "Laravel", que nos permite un manejo
modular y escalable. El equipo está familiarizado con este framework. Sin embargo, las
herramientas y tecnologías asociadas, como JavaScript permiten un uso y aprendizaje más
sencillos.

En sí, la complejidad para el equipo va de media a alta.

3.1.3. Estructuración del Cliente

El proyecto desarrollado tiene como cliente a cualquier individuo que requiera del servicio de
proceso de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio en
consecuencia, los requisitos deben ser bien definidos en búsqueda de obtener y retener la mayor
cantidad de clientes a través del modelo SaaS que es el más apegado a las exigencias del proyecto
en su relación con el cliente.
 16
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

3.2. Ámbito del Proyecto

3.2.1. Objetivos del proyecto

Objetivo General
Desarrollar un sistema de asistencia médica para el análisis, diagnóstico y sugerencias a partir de
un análisis clínico.
Objetivos Específicos
 Identificar los requerimientos del sistema
 Determinar las funcionalidades del sistema mediante análisis de los requerimientos.
 Diseñar la planificación requerida para llevar a cabo el proyecto en el tiempo establecido.
 Diseñar una BD integra, consistente, accesible y segura para el sistema

3.2.2. Requerimientos principales

 Gestionar usuario: se debe poder registrar al usuario del sistema, siendo el usuario
cualquier persona que requiera analizar un documento de análisis clínico.
 Registro e inicio de sesión: los usuarios podrán registrarse en el sistema e iniciar sesión
con sus credenciales.
 Subir archivos: los usuarios podrán elegir entre dos formatos de archivos para poder
iniciar el proceso de análisis, archivos en formato de imagen y en formato pdf.
 Extraer y digitalizar texto de los archivos subidos: cuando los archivos han sido
cargados para su análisis, se extraerá la información en formato de texto digitalizado para
su mejor compresión y procesamiento.
 Interpretar el texto extraído y generar documento de análisis: el proceso del análisis
analizara el texto digitalizado y aplicando la IA retornara un documento en formato de
análisis clínico con los siguientes datos: nombre del paciente, asunto, día, mes, año,
diagnostico, recomendaciones.
 Listar medicación y una descripción del medicamento asociado con el análisis: el
documento de análisis genera una lista de medicamentos con sus descripciones siempre
que el documento original del análisis que es sometido al procesamiento incluya
referencias a medicación del paciente.
 Historial de documentos procesados: se debe poder listar todos los análisis que resultan
del procesamiento de información en una tabla que tenga las siguientes funciones: ver
análisis, eliminar.
 Enviar por correo electrónico el documento de análisis clínico: los documentos
generados por el procesamiento deben poder enviarse por a través de correo electrónico a
terceros.
 Descargar por pdf el análisis clínico: es posible descargar los documentos generados del
análisis en un formato pdf.
 17
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

3.2.3. Rendimiento

El rendimiento del software tiene que ser rápido en el tiempo de respuesta, dado que tendrá
peticiones de usuarios al análisis de documentos médicos (análisis clínicos), donde se debe de
priorizar que la respuesta sea rápida ya que los usuarios al momento de realizar el proceso de
análisis quieren que sus respuestas sean rápidas y no haya fallas en el software.
Base de datos: Se utilizará una base de datos normalizada y optimizada.

Arquitectura: La arquitectura obtada para el sistema será la arquitectura MVC

Algoritmos: Se desarrollarán consultas a la inteligencia artificial eficientes y se hará

uso de componentes externos como API’s y otros.

Interfaz: Se interactuará a través de vistas (input-output) y formularios(input).

3.2.4. Fiabilidad

Por el grado de importancia que tiene la plataforma para sus potenciales clientes se ha determinado
que el grado de fiabilidad que se requiere del mismo es ALTO.
En este sentido, para garantizar la fiabilidad del software se realizarán las siguientes actividades:
 Se utilizará un servicio de hospedaje en la nube confiable que permita la recuperación pronta en
caso de caídas y el escalamiento de recursos veloz, en caso de su agotamiento.
 Se utilizará un servicio de inteligencia artificial de un proveedor confiable, que garantice la
continuidad del servicio.

3.2.5. Restricciones

3.2.5.1. Restricciones de Tiempo

Planificación: Se han definido las metas principales del equipo del proyecto.

Programación: El equipo de gestión del proyecto estableció entre 20 a 30 días para los tres Sprint
que se realizará en torno al marco de trabajo de SCRUM.

Seguimiento: Una vez el proyecto entró en marcha, el Scrum Master y el Product Owner fueron
los encargados de realizar seguimientos cada cierto periodo semanal para establecer un plazo
realista para la finalización del proyecto.
 18
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

Control: En el paso de control, el equipo fue comunicando los resultados de cada Sprint del
proyecto y avance en consecuencia. En el primer y segundo Sprint las cosas marcharon bien, se
analizaron los factores que contribuyeron para ese resultado positivo para que pueda continuar y
reproducirse.

Ilustración 16: Restricciones de Tiempo

Fuente (Elaboración Propia)

3.2.5.2. Restricciones de Alcance

El alcance del proyecto se ha definido de una manera clara y se ha comunicado a todas las partes
interesadas para garantizar que se evite el “Síndrome del lavadero”, término que se usa cuando se
realizan cambios en el alcance a mitad del proyecto, sin los mismos niveles de control. Para tener
el alcance controlado, se ha tomado en cuenta lo siguiente:
 19
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

 Se facilitó la documentación clara del alcance completo del proyecto al principio de este,
incluidos todos los requisitos.

 Se estableció un proceso para gestionar cualquier cambio, de modo que se fueron

realizando cambios se fueron determinando cómo se revisará, se aprobará, se rechazará o
se aplicará (si corresponde) ese cambio.

 Se comunicó el alcance a las partes interesadas de manera clara y periódica.

Ilustración 17: Restricciones de Alcance

Fuente (Elaboración Propia)

3.2.5.3. Restricciones de Coste

El presupuesto del proyecto incluye gastos fijos y variables, incluidos materiales, permisos, mano
de obra y el impacto financiero de los miembros del equipo que trabajaron en el proyecto. Entre
algunas de las formas de calcular el coste de un proyecto

se incluyen:

 Recursos: Se estimará la tasa de coste de los bienes y la mano de obra para los

siguientes puntos:

 Costos del proyecto

 Salarios de los miembros del equipo
 Costos del equipamiento
 20
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

3.2.6. Interfaces externas

3.2.6.1. Interacciones con Software

El sistema no interactúa con otro software.
3.2.6.2. Interacciones con Personas

El usuario puede usar el software para realizar análisis de documentos médicos.

3.2.6.3. Interacciones con Hardware

El software no cuenta con ninguna interacción con algún hardware externo.

4. ESTIMACIONES

4.1. Valor Esperado

PROYECTO KDLC (1 KDLC EQUIVALE APROXIMADAMENTE A

1000LDC)

Optimistas Más probables Pesimista Esperadas

SOFTWARE DE 1.8 38.7 194 58.4
ANALSIS,
DIAGNOSTICO Y
SUGERENCIAS A
PARTIR DE UN
SCANNER DE
LABORATORIO

Aplicando la fórmula de valor esperado:

optimista + 4(mas probable) + 𝑝𝑒𝑠𝑖𝑚𝑖𝑠𝑡𝑎
𝑉𝐸 =
6

1.8 + 4(38.7) + 194

𝑉𝐸 =
6

𝑉𝐸 = 58.433 KLDC
𝑉𝐸 = 58433.33 LDC
 21
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

3.7.2. Cocomo II

FACTOR DE COMPLEJIDAD

TIPO de Objetivo Cuenta Básico Intermedio Avanzado total

Pantalla 12 1 2 3 12

Reporte 2 2 5 8 10

Componentes 38 10 380
3GL

PO(puntos de 12 +10+380 = 402

objeto)

Proporciones de Muy baja baja normal alta muy Alta

Productividad

Experiencia/capacidad X
deldesarrollador

Madurez/capacidad del X
entorno

PROD 4 7 13 25 50

PO = 12+10+380 = 402

PROD = 7+13 = 20

100 -%reusó = 100 – (402/100) *10 = 59.8

(100−%𝑟𝑒𝑢𝑠𝑜) 59.8
𝑁𝑂𝑃 = PO ∗ 100
= 402 ∗ 100 = 240.39

𝑁𝑂𝑃 240.39
𝐸𝑠𝑓𝑢𝑒𝑟𝑧𝑜 𝑒𝑠𝑡𝑖𝑚𝑎𝑑𝑜 = PROD = 20
= 12.01 (cantidad de personas necesarias para llevar a
cabo el proyecto en 1 mes)
 22
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

3.7.3. Ecuación del Software

La ecuación de software asume una distribución específica del esfuerzo a lo largo de la vida de un
proyecto.

Fórmula de la ecuación:

𝐵 0.333 3 1
𝐸 = (LDC ∗ ) ∗ ( 4)
P 𝑡

Donde:

E= Esfuerzo en hombre-año

t = Duración de proyecto en años

B = Factor especial de destrezas, Para programas pequeños B vale 0.16, para programas
intermedios vale 0.28, para programas mayores vale 0.39

P = Parámetro de productividad, para un software de tiempo real, P vale 2.000, para

comunicaciones vale 10.000, para software científico vale 12.000 y para aplicaciones comerciales
de sistemas vale 28000.

Para simplificar el proceso de estimación se sugiere un conjunto de ecuaciones obtenidas de la

ecuación de software.
𝐿𝐷𝐶 0.43
𝑡 = 8.14 ∗ ( ) (donde t se mide en meses)
𝑃

𝐸 = 180 ∗ 𝐵 ∗ 𝑡 3

𝐿𝐷𝐶 = 𝑉𝐸 ∗ 1000 = 58.433*1000 = 58433.33

P = 28000
58433.33 0.43
𝑡 = 8.14 ∗ ( ) = 11.17 meses
28000

t = 11.17 meses = 0.93 años

𝐸 = 180 ∗ 0.16 ∗ (0.93)3 = 23.17 𝑝𝑒𝑟𝑠𝑜𝑛𝑎𝑠 − 𝑚𝑒𝑠

 23
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

3.7.4. Planning Poker

Puntos de Historia – Sprint1

HU Descripción PHU Estado

HU4 UI Inicio de sesión, registro, pantalla principal 2 Hecho

HU5 UI subir archivos 5 Hecho

HU6 UI Análisis de documento 5 Hecho

HU7 UI Documento procesado 2 Hecho

HU8 UI Historial de documentos procesados 2 Hecho

Velocidad estimada 16

Velocidad real 16

Tabla 11: Tabla de Puntos de Historia

Sprint1
Fuente (Elaboración Propia)

Puntos de Historia – Sprint2

HU Descripción PHU Estado

HU9 extraer y digitalizar texto de los archivos subidos 5 Hecho

HU10 interpretar el texto extraído y generar documento de 8 Hecho

análisis

HU11 listar medicación y una descripción del medicamento 3 Hecho

asociado con el análisis

HU12 enviar por correo electrónico el documento de análisis 5 Hecho

clínico
HU13 descargar por pdf el análisis clínico 3 Hecho

Velocidad estimada 24

Velocidad real 24

Tabla 12: Tabla de Puntos de Historia

Sprint2
Fuente (Elaboración Propia)
 24
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

4. GESTION DE RIESGO
Tabla de riesgos
La siguiente tabla muestra los diferentes riesgos que se pueden presentar en el proyecto. El impacto
puede tener alguno de los siguientes valores:
NI = No Influye M = Medio SG = Significativo CR = Critico

Riesgo Probabilid Impacto Reducir probabilidad Reducir impacto

ad
(1...100%)
R1. Retiro de 80% SG Comunicación  Tener Categorías de
la materia por constante. programadores.
parte de algún Motivación a través de  Adoptar un estándar de
miembro del cooperación en tareas codificación.
equipo individuales.  Usar repositorios
 Adoptar un estándar de
codificación.

R2. Perdida de 12% CR Tener controlador de  Tener un controlador de

código fuente por versiones versiones
falla en hardware
R3. Falla en la 20% SG Leer la  Tener cuentas de
IA utilizada documentación repuesto con crédito
disponible
Estar  Utilizar herramientas
familiarizado para encontrar la
con los posibles solución al error lo más
errores
pronto posible
Estar pendiente
de las noticias
presentes en la
plataforma de la
IA utilizada
R3. Falla en el 30% CR Desplegarlo con  Tener despliegues
despliegue anticipación días secundarios de repuesto
antes de la entrega.

Probar todas las

Funcionalidades.
R5. Problemas de 25% SG Reuniones  En caso de que una tarea
comunicación en el frecuentes donde se no haya si do
equipo dé un avance de cada completada, redistribuir
tarea y se esa tarea para
especifique que le completarla entre todos
toca a cada uno los miembros para
completarla
 25
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

Usar herramientas
como jira
para llevar un
registro de
actividades con
plazos de entrega
R6. Incapacidad de 40% M Usar herramientas  Responsabilidad con
alguno miembro cooperativas y nuestras tareas, en caso
del equipo para explicar lo de que tengamos que
cumplir sus tareas desarrollado de la cubrir algún compañero.
tarea  Tener un entendimiento
del proyecto cada una de
las tareas

Tabla 14: Tabla de Análisis de Riesgo

Fuente (Elaboración Propia)

5. PLANIFICACIÓN DEL TIEMPO

Con el objetivo de realizar el desarrollo del proyecto, se construyó un diagrama de Gantt que
recoja las decisiones de planificación del tiempo que se han determinado. La planificación se
realizó con la herramienta online ClickUp. A continuación, se presenta el mismo.

5.1. Planificación
 26
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

5.2. Diagrama de Gantt

Ilustración 18: Planificación del Tiempo

Fuente (Elaboración Propia)

Preparación:

 Presentación de proyecto como propuesta a desarrollar.

 Preparación de la propuesta del proyecto aceptada por el ingeniero.
 Preparación del entorno de desarrollo con los software y hardware

Capacitación:

 Inteligencia artificial de OpenAI.

 API Rest HTTP de AWS.
 Amazon C3.

Análisis:

 Realizar pruebas de traducción para ver la funcionalidad de IA.

 Realizar pruebas del funcionamiento de las IA con los diferentes prompts
 Realizar pruebas conexión de API REST HTTP entre frontend y backend.
 Últimas pruebas del software.

Diseño:

 Diseñar una interfaz prototipo.

 27
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

Implementación:

 Desarrollar la implementación
 Implementación API REST HTTP para la conexión de Frontend y Backend.

6. TABLA DE RECURSOS
To Prec-
Fecha Disponibilidad Precio %
tal Canti Unit Precio
Recurso Unitari Depre
Me dad Neto Total $
Desde Hasta o$ c.
s $

HARDWARE

11/09/20 06/12/20 800.0

Laptop 2 4 25% 33.33 133.3
23 23 0
11/09/20 06/12/20 950.0
PC de escritorio 2 1 25% 39.58 39.58
23 23 0
11/09/20 06/12/20
Servidor 2 1 46.30 25% 1.93 1.93
23 23

Medio de 11/09/20 06/12/20

2 5 120.00 30% 6 30
comunicacion 23 23

11/09/20 06/12/20
Router 2 1 70.00 25% 2.92 2.92
23 23

SOTFWARE

11/09/20 06/12/20
Sistema operativo 2 1 45.00 20% 1.50 1.5
23 23

Architrc 11/09/20 06/12/20 229

2 1 20% 7.63 7.63
Enterprice 23 23 .00
AWS-comprehed 11/09/20 06/12/20 100
2 1 15.00 2.50 2.5
medical 23 23 %
11/09/20 06/12/20 100
Click up 2 5 5.00 0.83 4.17
23 23 %

INFRAESTRUC
TURA
 28
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

11/09/20 06/12/20
Oficina 2 1 5000 2.5% 125.0 250
23 23
0
11/09/20 06/12/20
Serv. Basiscos 2 1 70.00 100% 70.00 140
23 23
11/09/20 06/12/20
Serv. Internet 2 1 30.00 100% 30.00 60
23 23

PERSONAL

11/09/20 06/12/20 100

Programador 2 1 1000 1000 2000
23 23 %
11/09/20 06/12/20 700.0 100 700.0
Ing. de Pruebas 2 1 1400
23 23 0 % 0
Analista de 11/09/20 06/12/20 800.0 100 800.0
2 1 1600
Sistemas 23 23 0 % 0
11/09/20 06/12/20 100
Ing. Software 2 1 1200 1200 2400
23 23 %
11/09/20 06/12/20 100
Jefe de Proyecto 2 1 1500 1500 3000
23 23 %

LOGISTICA

Material de 11/09/20 06/12/20 500.0

2 5 10% 50.00 500
escritorio 23 23 0
11/09/20 06/12/20 100.0 100 100.0
Refrigerio 2 5 1000
23 23 0 % 0
11/09/20 06/12/20 100.0 100 100.0
Transporte 2 5 1000
23 23 0 % 0
11/09/20 06/12/20 100
Gastos Otros 2 5 50.00 50.00 500
23 23 %
13330. 6271. 14130.
TOTAL
3 11 93
 29
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

7. ORGANIZACIÓN INTERNA
La estructura de equipo que utilizaremos para el desarrollo del software será la Descentralizada
Democrática, ya que la metodología a seguir asigna una tarea a un grupo de trabajo la cual se hace
responsable del cumplimiento de esta tarea. La organización Descentralizada Democrática no tiene
 30
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

un jefe permanente, se nombran coordinadores de tareas a corto plazo. La comunicación entre el

jefe y los miembros es horizontal.

Ilustración 19: Organización Interna

Fuente (Elaboración Propia)

Este tipo de organización se emplea en equipos pequeños y medianos.

8. MECANISMOS DE SEGUIMIENTO Y CONTROL

8.1. Revisión Técnica Formal(RTF)

Nombre completo del proyecto:
Software para el proceso de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio
Revisores:
Padilla Yapura José Luis
Avalos Severiche Gerald José
Maldonado Gutiérrez Daniel
Ortiz Serrano Edilson
Fecha de la RTF: _____05/12/2023_____
 31
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

Material entregado por el equipo a revisar:

Aspecto Preguntas Cumplió No cumplió Observaciones

Los requerimientos están
escritos en un lenguaje no 
técnico y comprensible
para el usuario/cliente?
Requisitos ¿Hay algún requerimiento

que pueda tener más de
Funcionales
una interpretación?
¿Todos los miembros del
equipo comprenden y 
están de acuerdo con los
requerimientos?
¿Se ha desarrollado un

PAPS para el proyecto de
software?
¿Existe un documento
PAPS formal que describa el 
Plan de Aseguramiento de
la Calidad del Software?
¿Está disponible y

accesible para todos los
miembros del equipo?
¿El software se encuentra

en un estado de ejecución
estable y funcional?
¿El software ha pasado
Software en por pruebas exhaustivas y

se ha verificado su
ejecución
funcionamiento
adecuado?
¿Se han abordado y

corregido los errores y
problemas conocidos?
 32
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

Universidad autónoma Gabriel René Moreno

Facultad de ingeniería en ciencias de la computación y
Telecomunicaciones

SOFTWARE PARA EL PROCESOS DE ANALISIS, DIAGNOSTICO Y

SUGERENCIAS A PARTIR DE UN SCANNER DE LABORATORIO
METODOLOGIA DE DESARROLLO

INTEGRANTES:
Padilla Yapura José Luis
Avalos Severiche Gerald José
Maldonado Gutiérrez Daniel
Ortiz Serrano Edilson

DOCENTE:
ING. Rolando Martínez

ASIGNATURA
Ingeniería de Software I (INF-422)

FECHA: 06/12/2023
 33
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

9. METODOLOGIA DE DESARROLLO

9.1. Tecnologías para el desarrollo del proyecto

9.1.1. Hardware
En esta sección se describe el hardware que utilizaremos para el desarrollo e implementación de
la aplicación web.
Herramienta Descripción
Cada uno de los miembros del equipo proveerá su computadora
para desarrollar la aplicación y realizar las pruebas.
Deberá tener los siguientes requisitos para el desarrollo:
 Procesador Intel desde i5 hasta i10 con minimo de 1.5
GHz
 Memoria RAM minimo 4 GB
 Sistema Operativo Windows entre 8 y 10, MacOS entre 9
y 10
Computadoras  Disco Duro de almacenamiento 256 GB

Se utilizará un servidor en la nube para probar el despliegue en el

entorno de producción y distribuir la aplicación.

Servidor
 34
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

9.1.2. Software
En esta sección se describe el hardware que utilizaremos para el desarrollo e implementación de
la aplicación web.
Nombre Descripción

Sistema Operativo

Windows 10 Pro/Home

Lenguaje de Programación

PHP.

Framework

Laravel Version 10.*

Motor de Base de Datos

MySQL Version 8.*

Herramienta CASE para UML

Enterprise Arquitect
 35
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

Sistema de Gestión de Paquetes

Composer 1.9.*

Editor de Código Fuente

Visual Studio Code

9.1.3. Proceso de Software

El marco de trabajo que se optó para el
desarrollo de la aplicación es SCRUM,
siendo el más conveniente para un
desarrollo ágil y abierto a cambios

9.1.4. Modelado de Software

El lenguaje Unificado de Modelado es un
lenguaje de modelado visual para sistemas,
aunque UML está más asociado con
modelar sistemas de software orientados a
objetos, tiene una ampliación mucho más
amplia que esto debido a sus mecanismos
incorporados de extensibilidad.
 36
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

9.1.5. Puesta en marcha/despliegue

Amazon Web Services es una colección de
servicios de computación en la nube que en
conjunto forman una plataforma de
computación en la nube. Este producto
ofrecido por Amazon es un punto de partida
para cualquier desarrollo de software con
miras a futuro ya que se diferencia de los
hostings tradicionales por su escalabilidad y
elasticidad en tiempo real, así como sus
precios dedicados solo al consumo que
realizamos ahorrando bastante dinero en los
emprendimientos emergentes. Usamos los
servicios de Amazon para montar nuestra
aplicación demo.

9.2. Proceso de Desarrollo de Software

9.2.1. Scrum
9.2.1.1. Asignación de roles
La asignación de roles se realizó de acuerdo a la siguiente tabla:

Product Owner
Responsable Características Justificación

Padilla Es una persona responsable y Fue elegida como Product Owner, ya que
Yapura José comprometida con el equipo de Tiene conocimiento sobre los respectivos
Luis desarrollo. módulos, puede facilitar entre los
requisitos funcionales y no funcionales al
momento de añadir en el product
backlog.
 37
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

Equipo de Desarrollo
Responsable Características Justificación
Avalos Es una persona comprometida y Está en el team developer por sus
Severiche colaborativa. conocimientos en el desarrollo de sistemas
Gerald José de software, utilizando herramientas
necesarias para este software a
implementar.
Ortiz Serrano Es una persona responsable, con Pertenece al Team developer, tiene
Edilson iniciativa y participativa. conocimiento de la tecnología de
implementación y aplica sus
conocimientos con las herramientas
requeridas.
Maldonado Es una persona autodidacta, Del team developer por sus capacidades a
Gutierrez colaborativa y responsable con la hora de implementar la solución
Daniel sus tareas. determinada.
Padilla Es participativo, creativo, y Participa al team developer porque es
Yapura José responsable. capaz de realizar las tareas de
Luis programación requeridas.

Scrum Master
Responsable Características Justificación

Ortiz Serrano Como el scrum Master, ya que tiene más

Edilson experiencia en el desarrollo de sistemas,
actualizar sus conocimientos sobre las
herramientas a usar en el proyecto,
Es una persona responsable conoce bien el trabajo de la metodología
con su trabajo y las de Scrum y lo aplica de manera correcta,
reuniones, escucha y ayuda a ayuda de manera equitativa al equipo,
su grupo. tiene buena comunicación y
coordinación con el equipo.
 38
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

Stakeholders
Responsable Características Justificación

Esta persona obtiene el rol de

Ing. Martínez stakeholders ya que es quien propone las
posibles necesidades de negocio de
Canedo Rolando servicio técnico, ya sea para la actualidad
o para un futuro del negocio, esta persona
Antonio comprende y visualiza las necesidades
que el sistema debe cubrir. también nos
propone opiniones respecto a los
requerimientos funcionales y no
funcionales que se pueden añadir o
quitar.

9.2.1.2. Modelos para el desarrollo Scrum

Sprint Planning Meeting

CÓDIGO DESCRIPCIÓN DE LA TAREA TIPO

T0-1 Entrevista con Product Owner Análisis

T0-2 Crear un perfil que explique la finalidad del proyecto Diseño

T0-3 Explicar al Product Owner como funciona la metodología a usar Análisis

T0-4 Explicar al Equipo una definición del problema Análisis

T0-5 Asignación de roles a los miembros del equipo Análisis

Capacitación de los miembros del equipo en las herramientas a

T0-6 utilizar Capacitación

T0-7 Preparación del entorno de desarrollo de programación Preparación

T0-8 Diseñar un modelo de base de Datos Diseño

 39
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

T0-9 Encontrar los casos de Uso funcionales Análisis

T0-10 Elaborar historia de usuario Análisis

T0-11 Diseñar la interfaz Diseño

T0-12 Implementar la historia de usuario Desarrollo

T0-13 Realizar las pruebas necesarias para su implementación Prueba

 40
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

Product Backlog
ID Tareas Estimación Priorid Tipo
ad
1 Planificar reunión de organización 5 hr 5 Planificación
del equipo scrum
2 Determinar y asignar roles para cada 1hr 3 Planificación
participante del escrutinio
S
3 Documentar el perfil de la 6 hr 3 Planificación
P documentación del proyecto
R 4 Comenzar con captura de requisitos. 24 hrs 5 Análisis
I 5 Definir herramientas de 8 hrs 5 Análisis
implementación.
N
6 Instalar y preparar las herramientas 5 hrs 3 Análisis
T de desarrollo e implementar la
estructura del sistema web
7 Diseñar la base de datos 12 hrs 3 Diseño

8 Definir duración del proyecto 5 hrs 5 Diseño

0
9 Hacer Estimaciones 7hrs 5 Análisis

10 Diseñar prototipo 72 hrs 5 Diseño

S HU04 UI Inicio de sesión, registro, pantalla 3h 2 Implementación

principal
P
HU05 UI subir archivos 3h 5 Implementación
R
I HU06 UI Análisis de documento 2h 5 Implementación

N HU07 UI Documento procesado 3h 2 Implementación

T HU08 UI Historial de documentos 4h 2 Implementación
procesados

1
HU09 extraer y digitalizar texto de los 48 h 4 Implementación
archivos subidos
HU10 interpretar el texto extraído y 48 h 4 Implementación
generar documento de análisis
 41
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

S HU11 listar medicación y una descripción 6h 3 Implementación

del medicamento asociado con el
P análisis

R HU12 enviar por correo electrónico el 3h 3 Implementación

documento de análisis clínico
I
N
HU13 descargar por pdf el análisis clínico 4h 4 Implementación
T

2
TOTAL 292 hrs

10. SPRINT 0

10.1. Definiciones Iniciales

Sprint 0 Definiciones Iniciales

ID TAREA
1 Planificar reunión de organización del equipo scrum
2 Determinar y asignar roles para cada participante del
escrutinio
3 Documentar el perfil de la documentación del proyecto
4 Comprender requisitos básicos iniciales.
5 Definir herramientas de implementación.
6 Instalar y preparar las herramientas de desarrollo e
implementar la estructura del sistema web
7 Diseñar la base de datos.
9 Definir duración del proyecto.
9 Hacer estimaciones.
10 Diseñar el prototipo

Tabla 16: Definiciones Iniciales

Fuente (Elaboración Propia)
 42
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

10.2. Base de Datos

11. SPRINT 1
11.1. Sprint Planing
11.1.1. Objetivos del Sprint
Objetivo General
Diseñar e implementar las interfaces de usuario del software.
Objetivos Específicos
 UI Inicio de sesión, registro, pantalla principal
 UI subir archivos
 UI Análisis de documento
 UI Documento procesado
 UI Historial de documentos procesados
 43
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

11.1.2. Historias de Usuario

UI Inicio de sesión, registro, pantalla principal

HU04 Descripción: como usuario debo poder visualizar la página principal de la aplicación y
tener la posibilidad de iniciar sesión en la aplicación con mis credenciales o de
registrarme en caso de no tener una cuenta de usuario.
Prioridad: Estimación: 3 hrs
2
Criterios de Aceptación
 La página principal tiene dos botones ubicados en la esquina superior derecha, que son
“iniciar sesión” y “registrarse” y un botón “Ingresar” centrado en la parte inferior del
formulario.
 El botón de iniciar sesión muestra un formulario con los campos: correo electrónico y
contraseña.
 El botón de registro muestra un formulario de registro de usuarios con los siguientes campos:
nombre, email, contraseña, confirmar contraseña, y un botón “Registrar” centrado en la parte
inferior del formulario.
 La página principal y los dos formularios tiene una imagen de fondo descrita en los
prototipos.
Desarrolladores a Cargo: Padilla Yapura José Luis

UI Subir archivos
HU05 Descripción: como usuario debo poder visualizar la vista de selección del tipo de
archivos que deseo subir para el posterior análisis, esto es o bien un PDF o bien una
imagen.
Prioridad: Estimación: 3 hrs
5
Criterios de Aceptación:
 La vista permite visualizar dos cards alineadas horizontalmente cada card tiene un texto y
una imagen que acompaña la descripción del tipo de archivo que puede elegir el usuario para
subir
 Hay un título centrado en la parte superior de la vista y que dice “elige el formato en que
deseas subir tus archivos”
Desarrolladores a Cargo: Maldonado Gutiérrez Daniel
 44
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

UI Análisis de documento
HU06 Descripción: como usuario luego de seleccionar el tipo de archivo que deseo subir debo
poder visualizar una ventana emergente que lista los archivos que seleccione para su
carga y posterior análisis.
Prioridad: Estimación: 2 hrs
5
Criterios de Aceptación:
 La ventana emergente tiene un título “Lista de archivos”.
 La ventana tiene un checklist por ítem (archivo que se ha cargado para el análisis).
 Cada checklist permite quitar los archivos que no se desean analizar.
 La ventana emergente tiene 2 botones alineados horizontalmente y ubicados en la parte inferior
derecha de la ventana emergente.
 Los botones tienen la función “cancelar” y “comenzar análisis”.

Desarrolladores a Cargo: Avalos Severiche Gerald José

UI Documento procesado
HU07 Descripción: como usuario luego de darle click al botón “comenzar análisis” debo poder
visualizar una vista previa de los archivos cargados para el análisis y su formato
digitalizado.
Prioridad: Estimación: 3 hrs
2
Criterios de Aceptación:
 La vista muestra una división vertical que divide las visualizaciones de los archivos por un
lado y el texto digitalizado que representa a estos archivos por otro.
 Las visualizaciones de los archivos cargados se ubican a izquierda de la división vertical.
 El texto digitalizado se ubica en el lado derecho de la división vertical.
 Debe haber 2 botones alineados horizontalmente y ubicados en la parte inferior derecha de la
vista.
 Los botones tienen la función “cancelar” y “procesar”.
Desarrolladores a Cargo: Ortiz Serrano Edilson
 45
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

UI Historial de documentos procesados

HU08 Descripción: como usuario debo poder visualizar una lista de los análisis que hubiese
procesado.
Prioridad: Estimación: 4 hrs
2
Criterios de Aceptación:
 La vista permite visualizar un listado de los análisis clínicos resultados del procesamiento de
los archivos.
 El formato de la lista es tabular y existe tres columnas: fecha, nombre y acciones
 La columna de acciones tiene 4 botones: documentos asociados, generar pdf, eliminar, y enviar
por correo.
Desarrolladores a Cargo: Ortiz Serrano Edilson

11.1.3. Contexto del sistema

(no hay un diagrama de contexto de esta sección porque solo se tratan de interfaces, no se aborda
lógica de programación).

11.1.4. Sprint Backlog

Sprint Backlog
1 UI Inicio de sesión, registro,
2
pantalla principal
2 UI subir archivos 5
3 UI Análisis de documento 5
4 UI Documento procesado 2
5 UI Historial de documentos
2
procesados
 46
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

Sprint Backlog

Numero de Sprint: 1 Tiempo Programado: 14 días

Fecha Inicio:18/10/2023 Fecha de Finalización: 31/10/2023

Objetivo: Lograr las implementación de las interfaces de usuario del software.

ID Tarea Tipo Estimación Responsable Estado

HU Instalar y configurar el Infraestructura 1 hr Maldonado Completado

proyecto con laravel Gutierrez Daniel
HU4 Implementar inicio de Diseño 3 hrs Padilla Yapura Jose Completado
sesión, registro y pantalla Luis
principal.
HU5 Implementar vista subir Diseño 3 hrs Maldonado Completado
archivos Gutierrez Daniel
HU6 Implementar vista Análisis Diseño 2 hrs Avalos Severiche Completado
de documento Gerald José
HU7 Implementar vista Diseño 3 hrs Ortiz Serrano Completado
Documento procesado Edilson
HU8 Implementar vista Diseño 4 hrs Ortiz Serrano Completado
Historial de documentos Edilson
procesados
 47
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

11.2. Proceso de desarrollo por Historia de Usuario

11.2.1. Diseño
11.2.1.1. Diseño de la Arquitectura
Diagrama de Contenedor

(no hay un diagrama de contenedor de esta sección porque solo se tratan de interfaces, no se

aborda lógica de programación).

Diagrama de Componentes

(no hay un diagrama de componentes de esta sección porque solo se tratan de interfaces, no se

aborda lógica de programación).

11.2.1.2. Diseño de Datos

Diagrama de Modelo de Datos
 48
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

10.3. Sprint Review

Inicio Duración Actividad Sprint Review Descripción Responsable

20:00 15 min Objetivo del Sprint Implementar todas las interfaces de Product Owner
usuario
20:15 25 min Revisión de las  UI Inicio de sesión, registro, Product Owner
interfaces de usuario pantalla principal
 UI subir archivos
 UI Análisis de documento
 UI Documento procesado
 UI Historial de documentos
procesados

20:50 25 min Estado del Sprint Se concluyó todas las tareas para Scrum Master
este sprint dando así porterminado
este sprint
21:30 15 min Demostraciones Los requisitos para el desarrollo de Equipo de
este Sprint, fueron probados y desarrollo
aceptados por los miembros del
equipo, cumpliendo con todas las
funcionalidades establecidas
previamente.
21:45 5 min Conclusiones Se lograron implementar todas las Scrum Master
funcionalidades para el
funcionamiento del sistema.

Tabla 25: Sprint Review

Fuente (Elaboración Propia)
 49
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

11.4. Sprint Retrospective

Después de la reunión, se concluyó que:

• El DevTeam profundice el diseño de interfaces y el manejo de Livewire.

• Organizar mejor cada tarea.

• Validación de datos antes de realizar los commits.

• Mejorar en la responsabilidad de cada issue.

12. SPRINT 2
12.1. Sprint Planning
12.1.1. Objetivos del Sprint
Objetivo General
Implementar las todas funcionalidades(backend) del proyecto.
Objetivos Específicos
 extraer y digitalizar texto de los archivos subidos
 interpretar el texto extraído y generar documento de análisis
 listar medicación y una descripción del medicamento asociado con el análisis
 enviar por correo electrónico el documento de análisis clínico
 descargar por pdf el análisis clínico
 50
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

12.1.2. Historias de Usuario

Extraer y digitalizar texto de los archivos subidos

HU09 Descripción: como usuario debo poder ver en formato digital los archivos cargados
para el análisis.
Prioridad: Estimación: 2 dias
5
Criterios de Aceptación
 generar texto digital a partir de un archivo (pdf o imagen)

Desarrolladores a Cargo: Ortiz Serrano Edilson

Interpretar el texto extraído y generar documento de análisis

HU10 Descripción: como usuario debo poder ver un documento bajo el formato de análisis
clínico resultado del procesamiento.
Prioridad: Estimación: 3 dias
8
Criterios de Aceptación
 el documento bajo el formato de análisis clínico tiene los siguientes datos: nombre del
paciente, asunto, día, mes, año, diagnostico, recomendaciones.
 El documento tiene la opción de ser guardado.
 El documento de análisis requiere recibir un título para ser guardado.
Desarrolladores a Cargo: Ortiz Serrano Edilson
 51
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

Listar medicación y una descripción del medicamento asociado con el análisis

HU11 Descripción: como usuario debo poder ver una lista de medicamentos asociados al
documento de análisis, siempre y cuando estos medicamentos aparezcan referenciados
en los archivos originales de los que procede el documento de análisis.
Prioridad: Estimación: 2 dias
3
Criterios de Aceptación
 Ver lista de medicamentos y sus descripciones.
 Botón de medicamentos situado en la esquina superior derecha.

Desarrolladores a Cargo: Maldonado Gutiérrez Daniel

Enviar por correo electrónico el documento de análisis clínico

HU12 Descripción: como usuario debo poder enviar el documento del análisis vía correo
electrónico.
Prioridad: Estimación: 2 dias
5
Criterios de Aceptación
 Enviar por correo electrónico el documento del análisis en formato pdf.

Desarrolladores a Cargo: Avalos Severiche Gerald José

 52
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

Descargar por pdf el análisis clínico

HU13 Descripción: como usuario debo poder descargar en formato pdf el documento de
análisis clínico generado.
Prioridad: Estimación: 2 dias
3
Criterios de Aceptación
 El formato pdf debe coincidir con el diseño descrito en los prototipos de la sección de anexos

Desarrolladores a Cargo: Avalos Severiche Gerald José

12.1.3. Contexto del sistema

Diagrama de Contexto

Ilustración 28: Diagrama de Contexto

Sprint 2
Fuente (Elaboración Propia)
 53
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

12.1.4. Sprint Backlog

Sprint Backlog

Numero de Sprint: 2 Tiempo Programado: 14 días

Fecha Inicio:22/11/2023 Fecha de Finalización: 06/12/2023

Objetivo: Implementar las todas funcionalidades(backend) del proyecto..

ID Tarea Tipo Estimación Responsable Estado

HU9 extraer y digitalizar texto Infraestructura 2 dias Ortiz Serrano Completado

de los archivos subidos Edilson
HU10 interpretar el texto Implementacion 3 dias Maldonado Completado
extraído y generar Gutierrez Daniel
documento de análisis
HU11 listar medicación y una Implementacion 2 dias Maldonado Completado
descripción del Gutierrez Daniel
medicamento asociado con
el análisis
HU12 enviar por correo Implementacion 2 dias Avalos Severiche Completado
electrónico el documento Gerald José
de análisis clínico
HU13 descargar por pdf el Implementacion 2 dias Ortiz Serrano Completado
análisis clínico Edilson

Tabla 26: Sprint Backlog 2

Fuente (Elaboración Propia)
 54
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

12.2. Proceso de desarrollo por Historia de Usuario

12.2.1. Diseño
12.2.1.1. Diseño de la Arquitectura
Diagrama de Contenedor

Ilustración 29: Diagrama de Contenedor

del Sprint 2
Fuente (Elaboración Propia)
 55
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

Diagrama de Componentes

Ilustración 30: Diagrama de Componentes

del Sprint 2
Fuente (Elaboración Propia)
11.2.1.2. Diseño de Datos
Diagrama de Modelo de Datos

Ilustración 32: Diagrama de Modelo de

Datos del Sprint 2
Fuente (Elaboración Propia)
 56
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

12.3. Sprint Review

Inicio Duración Actividad Sprint Review Descripción Responsable
20:00 15 min Objetivo del Sprint Product Owner
Implementar las todas
funcionalidades(backend) del
proyecto.

20:15 25 min Revisión de las  extraer y digitalizar texto Product Owner

funcionalidades de los archivos subidos
 interpretar el texto extraído
y generar documento de
análisis
 listar medicación y una
descripción del
medicamento asociado con
el análisis
 enviar por correo
electrónico el documento
de análisis clínico
 descargar por pdf el análisis
clínico
20:50 25 min Estado del Sprint Se concluyó todas las tareas para Scrum Master
este sprint dando así porterminado
este sprint
21:30 15 min Demostraciones Los requisitos para el desarrollo de Equipo de
este Sprint, fueron probados y desarrollo
aceptados por los miembros del
equipo, cumpliendo con todas las
funcionalidades establecidas
previamente.
21:45 5 min Conclusiones Se lograron implementar todas las Scrum Master
funcionalidades para el
funcionamiento del sistema.

Tabla 33: Sprint Review 2

Fuente (Elaboración Propia)
 57
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

11.4. Sprint Retrospective

Después de la reunión, se concluyó que:
 Organizar mejor cada tarea.
 Conocimiento de las capacidades del proyecto
 Manejar mejor los tiempos de entrega
 Conocer las capacidades de la IA
 58
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

ANEXOS
Prototipos
Los siguientes prototipos de la aplicación fueron diseñados en Figma, un software open-source
gratuito que funciona como un diseñador de interfaces web y móviles. Si desea ver los diseños
de los prototipos en Figma, visite el siguiente enlace:
https://www.figma.com/file/A6hYWdSwuUM28CuHEnNpG0/Untitled?type=design&node-
id=0%3A1&mode=design&t=AnaXvmmw7xvK9lav-1

Página Principal

Inicio de sesión
 59
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

Registro

Subir archivo (selección de tipo de archivo)

 60
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

Subir archivo (árbol de directorio)

Subir archivo (selección de numero de archivos)

 61
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

Digitalización de archivos

Procesamiento de archivos digitalizados

 62
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

Detección de medicamentos asociados

Historial de archivos procesados

 63
Software de análisis, diagnóstico y sugerencias a partir de un scanner de laboratorio

Perfil de usuario

BIBLIOGRAFIA

 Jain, A. K., & Li, S. Z. (2011). Handbook of face recognition (2nd Ed.). Springer.

 Turk, M., & Pentland, A. (1991). Face recognition using eigenfaces. In Proceedings.
1991 IEEE Computer Society Conference on Computer Vision and Pattern Recognition
 Zhao, W., Chellappa, R., Phillips, P. J., & Rosenfeld, A. (2003). Face recognition: A
literature survey. ACM Computing Surveys (CSUR), 35(4), 399-458.

 Kadir, A. A., & Kamaruddin, L. M. (2013). A comparative study between LBP and Haar-
like features for face detection. In 2013 International Conference on Advanced Computer
Science Applications and Technologies (pp. 57-62). IEEE.

 Conklin, W. A., Davis, R. L., & Williams, D. (2018). Principles of Computer Security:
CompTIA Security+ and Beyond.

 Syngress. (2015). Physical Security Principles.