Modelos de Desarrollo

“ASISTENTE DE ENFERMEDADES
CON INTELIGENCIA ARTIFICIAL
Y CIENCIA DE DATOS PARA
GENERAR UNA PROBABILIDAD
CLÍNICA”
“MODELOS DEL DESARROLLO DE SOFTWARE
SCRUM”
INTEGRANTES: REGISTRO:
● Ponce Yepez Lorena Michel 213109999

● Vidal Cespedes Erick Edwing 217055321
GRUPO: 16
MATERIA: Ingeniería de Software II
DOCENTE: Ing. Martinez Canedo Rolando
SANTA CRUZ – BOLIVIA

Contenido
PAPS (PLAN DE ADMINISTRACION DE PROYECTO DE SOFTWARE) ......... 6
1.1 Introducción .................................................................................................. 6
1.2 Propósito del documento .............................................................................. 8
1.3 Descripción del Problema ............................................................................. 9
1.4 Métricas del software .................................................................................... 9
1.4.1 Datos históricos usados en la métrica ..................................................... 9
1.4.2 Métrica orientada al tamaño (MOT) ..................................................... 12
1.4.3 Métrica orientada a la función (MOF) .................................................. 13
1.5 Estimaciones ............................................................................................... 17
1.5.1 Características del proyecto .................................................................. 17
1.6 Ámbito del proyecto ................................................................................... 18
1.6.1 Objetivo del proyecto ............................................................................ 18
1.6.2 Requerimientos principales................................................................... 19
1.6.3 Rendimiento .......................................................................................... 19
1.6.4 Fiabilidad .............................................................................................. 21
1.6.5 Restricciones ......................................................................................... 23
pág. 2
1.6.6 Interfaces extras .................................................................................... 24
1.7 Alcance ....................................................................................................... 24
1.7.1 Alcance de la aplicación móvil ............................................................. 24
1.8 Elementos del Sistema Basado en Computadoras ...................................... 25
1.8.1 Hardware ............................................................................................... 25
1.8.2 Software ................................................................................................ 26
1.8.3 Datos ..................................................................................................... 27
1.8.4 Procesos ................................................................................................ 27
1.8.5 Gente/Usuarios ...................................................................................... 27
1.9 Herramientas de Desarrollo ........................................................................ 27
1.9.1 Software ................................................................................................ 27
1.9.2 Hardware ............................................................................................... 28
1.10 Estimación Costos Basados en Recursos ................................................ 29
1.11 Gestión de Riesgo.................................................................................... 29
1.12 Planificación del Tiempo ........................................................................ 31
1.13 Diagrama de Gantt .................................................................................. 32
MODELOS DEL DESARROLLO DEL SOFTWARE ........................................... 33
pág. 3
PROCESO DE DESARROLLO SCRUM ............................................................... 33
1.1 Personas y roles del proyecto ...................................................................... 33
1.2 Planeación de la Iteración ........................................................................... 34
1.2.1 Selección de Pre-requisitos ................................................................... 34
1.2.2 Selección de Requisitos ........................................................................ 34
1.2.3 Ejecución de Iteración .......................................................................... 35
1.2.4 Lista de Historias de Usuario ................................................................ 37
1.2.5 Sprint Review ....................................................................................... 37
1.2.6 Sprint Retrospective .............................................................................. 37
1.3 Artefacto ..................................................................................................... 38
1.3.1 Product Backlog .................................................................................... 38
1.3.2 Scrum Taskboard .................................................................................. 40
1.4 Incrementos ................................................................................................. 41
1.4.1 Sprint 1 .................................................................................................. 41
1.4.2 Sprint 2 .................................................................................................. 49
1.5 Modelos ...................................................................................................... 55
1.5.1 Modelo de Despliegue .......................................................................... 55
pág. 4
1.5.2 Modelo de Arquitectura ........................................................................ 56
1.5.3 Modelo de Datos ................................................................................... 58
Bibliografía ............................................................................................................... 59
pág. 5
PAPS (PLAN DE ADMINISTRACION DE PROYECTO DE SOFTWARE)
1.1 Introducción
El auge de la tecnología de la información ha brindado numerosos beneficios en
diversas industrias, incluida la atención médica.
Las instituciones de salud y las compañías médicas ahora están cambiando su
enfoque hacia la aplicación de TI a través de sistemas de software de atención médica.
El software de atención médica se refiere a programas «inteligentes» de apoyo a la
decisión médica que ofrecen asistencia, orientación y comentarios en el entorno de la
atención.
Varios hospitales ahora están cambiando a software de registro electrónico de salud
(EHR) para reemplazar el papel. Los departamentos de enfermería ahora utilizan software
de programación de citas para una mejor programación y seguimiento de turnos. El
software de gestión de equipos médicos también se está utilizando para controlar a los
pacientes en la UCI (unidades de cuidados intensivos).
Diagnostico medico
El software de diagnóstico médico permite el intercambio automatizado de
información en tiempo real entre diferentes especialidades médicas. Esta perspectiva es
holística y permite un diagnóstico médico rápido y confiable de enfermedades en el entorno
hospitalario.
pág. 6
En este sistema, los especialistas médicos ingresan información como conceptos
relevantes, hallazgos y posibles procesos de enfermedad para cada paciente.
Por ejemplo, un cardiólogo compartirá su diagnóstico del paciente en función de las
manifestaciones cardiovasculares. Un nefrólogo podría ingresar simultáneamente datos y
un posible diagnóstico basado en los hallazgos renales del paciente. Este sistema, por lo
tanto, fomenta la colaboración entre diferentes campos médicos.
Los ejemplos de programas de software de diagnóstico médico incluyen, entre
otros, un sistema experto basado en la web para el diagnóstico nutricional, el sistema
multiagente de ontología de enfermedades humanas genéricas (GHDO) y el sistema de
diagnóstico holónico para aplicaciones de salud electrónica. Holónico es parecido a
holístico, y habla de sistemas reconfigurables.
Base de datos medica
Las bases de datos médicas, similares a los EHR, permiten a los médicos,
enfermeras y otros profesionales de la salud ingresar los datos de los pacientes en una
plataforma digital. Dichos datos incluirían el historial médico de un paciente,
medicamentos, procedimientos y un curso en las salas.
Quizás la principal diferencia entre un software de base de datos médica y EHR es
que, en las bases de datos médicas, los casos se clasifican de acuerdo con el diagnóstico de
la enfermedad, de modo que existe una base de datos médica específica para diabetes
mellitus, enfermedad coronaria, neumonía, etc.
pág. 7
Este tipo de software médico permite a los médicos hacer referencia a casos
anteriores, tanto para tomar decisiones clínicas más acertadas como para ordenar datos y
eventualmente realizar investigaciones médicas.
Sistema de Citas
El sistema de programación de citas en línea es utilizado actualmente por hospitales,
clínicas y otras instalaciones de atención médica para maximizar la eficiencia del personal
y minimizar el tiempo de espera de los pacientes.
En este sistema, los pacientes se registran iniciando sesión en la plataforma en línea,
en donde se les da un número de cita y un horario.
A través de esto, los pacientes no se alinean en el hospital, lo que reduce el
hacinamiento, mejora la atmósfera del hospital y aumenta los niveles de satisfacción laboral
del personal.
Otras características del sistema de citas en línea incluyen la posibilidad de verificar
la disponibilidad del médico, cancelar la cita y reprogramar la cita.
1.2 Propósito del documento
El propósito de este documento es para explicar las diferentes funcionalidades con
las que cuenta la aplicación móvil, además que se describe el enfoque de desarrollo de
software.
pág. 8
De esta manera, se entrega a los usuarios y programadores que lleguen a encontrarse
con la aplicación, una referencia amplia de consulta, para la interacción con la estructura
principal del proyecto.
1.3 Descripción del Problema
A través de los algoritmos e introducción de datos se puede calcular la probabilidad
de riesgo al contagio que tuvo una persona en varios escenarios. Son maneras orientativas,
ya que no existe ninguna manera que un algoritmo sepa de manera cierta si esa persona
realmente tiene una enfermedad a menos que esa persona realmente se haga una prueba en
laboratorio. Se pueden calcular las probabilidades respecto a datos ingresados como
síntomas que presenta el paciente. Esto permite dar una resolución más clara al paciente de
su riesgo de salud.
1.4 Métricas del software
1.4.1 Datos históricos usados en la métrica
 Ada
 Tonic
 Symptomate
1.4.1.1 Ada
Es una app de salud creada por médicos para pensar como un médico. Entrenaron a
Ada durante años, para que puedas tener un pre-diagnóstico en
minutos. Independientemente de lo que te esté molestando, desde dolor de cabeza hasta
pág. 9
alergia, el evaluador de síntomas de Ada puede ayudarte a encontrar respuestas y hacerte
saber si debes ver a un médico.
Características:
 Responde preguntas sencillas acerca de tu salud y tus síntomas, o los de
alguien más.
 La Inteligencia Artificial de Ada evalúa tus respuestas y las compara con su
diccionario médico de miles de condiciones médicas y enfermedades.
 Recibe un informe de evaluación personalizado que te indica qué podría
estar mal y qué hacer después. Informe de evaluación comparte información
relevante con tu médico exportando tu informe como PDF.
Captura de interfaces:
pág. 10
1.4.1.2 Tonic
Es un software que proporciona una asistencia digitales para su todo en torno a la
salud y el bienestar.
Características:
 Obtener una segunda opinión de un médico cuando sea necesario a través de
chat.
 Encontrar los médicos adecuados para todas sus necesidades médicas.
 Reservar una cita al instante con los médicos a su alcance y obtener acceso a
más de 30 médicos del país.
pág. 11
1.4.1.3 Symptomate
Es el verificador de síntomas más avanzado que utiliza inteligencia artificial para
evaluar sus síntomas. Desarrollado y validado por médicos, conoce más de 700 condiciones
médicas y le ayudará a verificar su estado de salud al instante.
1.4.2 Métrica orientada al tamaño (MOT)
 Productividad = KLDC/persona-mes
 Calidad = errores/KLDC
 Documentación = págs. Doc. / KLDC
 Costo = $/KLDC
 Esfuerzo= Gente x Tiempo
Líneas de Código:
pág. 12
PROYECTO KLDC GENTE ESFUERZO(PM) TIEMPO ERRORES DEFECTOS
(EN
MESES)
Ada 7.523 5 30 6 25 10
Tonic 10.945 4 48 12 10 5
Symptomate 8.665,8 3 9 3 2 3
Calidad =
E  D  ; Productividad =
KLDC
KLDC Esfuerzo
PROYECTO CALIDAD PRODUCTIVIDAD

Ada 3.5 0.3333
Tonic 0.986 0.316
Symptomate 0.714 0.777
1.4.3 Métrica orientada a la función (MOF)
Tabla de métricas orientadas a la función
Ada
FACTOR DE PESO
PARÁMETROS DE CUENTA SIMPLE MEDIO COMPLEJO TOTAL
MEDICIÓN
# de entradas de 50 3 4 6 200
usuario
# de salidas de 175 4 5 7 1225
usuario
# de peticiones 30 3 4 6 120
# de archivos 84 7 10 15 12660
# de interfaces 6 5 7 10 42
externas
Cta Total 14247
pág. 13
SIGNIFICATIVO
MODERADO
INCIDENTAL
NO INFLUYE
FACTORES
ESENCIAL
MEDIO
F
1 Comunicaciones de datos X 3
2 Procesamiento distribuido X 4
3 Objetivos de rendimiento X 2
Configuración de uso
4 X 4
intensivo
Tasas de transacción
5 X 3
rápidas
6 Entrada de datos en línea X 5
7 Amigabilidad en el diseño X 0
Actualización de datos en
8 X 5
línea
9 Procesamiento complejo X 2
10 Reusabilidad X 4
11 Facilidad de instalación X 2
12 Facilidad operacional X 0
13 Adaptabilidad X 3
14 Versatilidad X 3
40
PUNTO DE FUNCIÓN (unidad de medida de software)
PF TOTAL = C Total * [0,65 + 0,01 * ∑ 14 𝑖 = 1 𝐹𝑖]
PF TOTAL = 14247* [0,65 + 0,01 * 49] =16241,58
pág. 14
Tonic
FACTOR DE PESO

MEDICIÓN
usuario
# de salidas de 175 4 5 7 1225
usuario
# de archivos 1000 7 10 15 15000
externas
Cta Total 16587
SIGNIFICATIVO
MODERADO
INCIDENTAL
NO INFLUYE
FACTORES
ESENCIAL
MEDIO
F
4 X 3
intensivo
5 X 4
rápidas
8 X 1
línea
10 Reusabilidad X 2
pág. 15
14 Versatilidad X 4
40
PF TOTAL = 16587* [0,65 + 0,01 * 50] =19075,05
Symptomate
FACTOR DE PESO

MEDICIÓN
usuario
# de salidas de 115 4 5 7 805
usuario
# de archivos 874 7 10 15 13110
externas
Cta Total 14095
SIGNIFICATIVO
MODERADO
INCIDENTAL
NO INFLUYE
FACTORES
ESENCIAL
MEDIO
pág. 16
4 X 3
intensivo
5 X 4
rápidas
8 X 5
línea
10 Reusabilidad X 2
14 Versatilidad X 4
45
PF TOTAL = 16587* [0,65 + 0,01 * 50] = 15504,5
1.5 Estimaciones
1.5.1 Características del proyecto
1.5.1.1 Tamaño del proyecto
Para determinar el tamaño del proyecto tendremos como principales indicadores la
cantidad de casos de uso y las KLDC, las cuales son:
pág. 17
 En la parte de la aplicación móvil tenemos una cantidad de 5 casos de uso
para todo el proyecto.
 649,709 KLDC estimadas.
Por lo tanto, concluimos que el tamaño del proyecto es de mediano a grande.
1.5.1.2 Tamaño del proyecto
El equipo está conformado por programadores junior en el desarrollo de
aplicaciones móvil. Por lo tanto, la complejidad del proyecto es media.
1.5.1.3 Estructuración del cliente
El proyecto a desarrollar tiene como cliente a toda persona que necesite un
diagnóstico médico para realizar consultas de las posibles enfermedades de manera segura
y adecuada accesible en su medio de manera simple.
1.6 Ámbito del proyecto
1.6.1 Objetivo del proyecto
1.6.1.1 Objetivo general
Desarrollar un Software para las consultas de enfermedades de paciente de manera
segura y adecuada con la información personal que ingresan.
1.6.1.2 Objetivo especifico
 Implementar los servicios de inteligencia Artificial basada en la nube para
desarrollar software.
pág. 18
 Crear e implementar una base de datos en FireBase que soporte todas las
clases.
 Diseñar una interfaz sencilla y amigable con Flutter para dispositivos
móviles Android y para IOS que registre los datos correctamente.
 Cumplir con los tiempos establecidos en los Sprint del marco de trabajo
SCRUM y C4 para aumentar el rendimiento y minimizar tiempos de trabajo.
1.6.2 Requerimientos principales
 Análisis Estadístico: el software que mediante preguntas que debe responder
el usuario, realizara una estimación para determinar si un usuario tiene
síntomas.
 Historial Clínico: El software después de un análisis de las respuestas de
concluya el usuario realizara un informe clínico para que el usuario pueda
presentar a un médico que quiera para un tratamiento más especializado.
1.6.3 Rendimiento
1.6.3.1 Pruebas de carga
Este es el tipo más sencillo de pruebas de rendimiento. Una prueba de carga se
realiza generalmente para observar el comportamiento de una aplicación bajo una cantidad
de peticiones esperadas. Esta carga puede ser el número esperado de usuarios concurrentes
utilizando la aplicación y que realizan un número específico de transacciones durante el
tiempo que dura la carga. Esta prueba puede mostrar los tiempos de respuesta de todas las
transacciones importantes de la aplicación. Si la base de datos, el servidor de aplicaciones,
pág. 19
etc. también se monitorizan, entonces esta prueba puede mostrar el cuello de botella en la
aplicación.
1.6.3.2 Pruebas de resistencia
Se realizan con el fin de determinar si la aplicación puede mantener la carga
esperada de manera continuada y durante un largo periodo de tiempo. El objetivo principal
de este tipo de pruebas es verificar que no existen fugas de memoria o procesos que pierdan
rendimiento transcurrido un cierto periodo de tiempo. También se hace enviando peticiones
a un sistema en ciertos intervalos de tiempo. Pensando en una ciudad como un sistema
imaginemos que los autos son peticiones y en ciertas horas del día (las horas pico) el
sistema tiene una cantidad de peticiones, pero en otros horarios las peticiones disminuyen.
1.6.3.3 Pruebas de capacidad
Se obtienen los límites de funcionamiento del sistema y los elementos que limitan el
rendimiento dentro de la plataforma.
La correlación de la 'capacidad de prueba' para un buen diseño puede observar al
ver que el código que tiene la cohesión débil, estrecho acoplamiento, la redundancia y la
falta de encapsulación es difícil de probar.
Un menor grado de los resultados de la capacidad de prueba en el aumento de
esfuerzo de la prueba. En casos extremos, la falta de capacidad de prueba puede dificultar
la prueba de las piezas de software o requisitos de software en absoluto.
pág. 20
1.6.4 Fiabilidad
La fiabilidad del software está determinada por el grado de respuesta confiable en el
trabajo en tiempo real. Por lo tanto, se realizarán los procedimientos necesarios para
garantizar que el software funcione de forma correcta siempre.
1.6.4.1 Procedimientos para la estimación de la fiabilidad
El concepto de fiabilidad se ha definido de manera operativa de diferentes formas:
 Fiabilidad de formas paralelas
 Fiabilidad test-retest
 Fiabilidad de consistencia interna
 Fiabilidad entre calificadores o evaluadores
1.6.4.2 Métodos de fiabilidad
1.6.4.2.1 Método: Test-Restest
Está indicado para estimar la fiabilidad de un test del que sólo disponemos una
forma. Consistiría en:
 Administrar el mismo test en dos ocasiones diferentes separadas por cierto
lapso temporal a una misma muestra de sujetos.
Calcular el coeficiente de correlación entre las puntuaciones obtenidas
pág. 21
1.6.4.2.2 Método: pruebas paralelas
Se utiliza cuando se preparan dos versiones del mismo test; los ítems son distintos
en cada test, pero con ambos se pretende medir lo mismo. En este caso el coeficiente de
fiabilidad es la correlación entre las dos formas paralelas, respondidas por los mismos
sujetos.
 Puede interpretarse como un coeficiente o indicador de equivalencia entre
los dos tests: si la correlación es alta, las dos formas del mismo test dan
resultados parecidos, ordenan a los sujetos de manera parecida, ambas
formas son intercambiables. Si la correlación entre las dos formas
(respondidas con días u horas de diferencia) es baja, la conclusión más
razonable no es que los sujetos han cambiado, sino que las dos formas no
están equilibradas en sus contenidos y de alguna manera miden cosas
distintas o con énfasis distintos.
 Una confirmación adicional de que las dos formas son realmente paralelas es
comprobar si la correlación media inter-ítem dentro de cada forma es de
magnitud similar, lo mismo que la correlación de los ítems de una forma con
los de la otra versión.
 Este tipo de fiabilidad, o prueba de equivalencia, es necesario siempre que se
disponga de dos o más versiones del mismo test, y su uso queda en la
práctica restringida a esta circunstancia no frecuente.
pág. 22
1.6.5 Restricciones
1.6.5.1.1 Restricciones técnicas
En nuestro proyecto utilizaremos el proceso de desarrollo:
 Manifiesto para el desarrollo de software ágil Scrum
 Lenguaje de modelado “C4”
 El proyecto será Móvil.
 El proyecto móvil será desarrollado en Flutter.
 Los diagramas de C4 serán implementados en la herramienta Visual Basic
 La documentación del proyecto será documentada en Microsoft Word 2017.
 La base de datos será implementada en Firebase.
 El software se desarrollará en el editor de texto Visual Code.
 Las interfaces del software deberán ser intuitivas para el usuario final.
1.6.5.1.2 Restricciones legales
El software tendrá las restricciones legales que el estado impone en cuanto a la
confidencialidad de las personas en cuanto a los síntomas de salud presenten.
1.6.5.1.3 Restricciones de recursos
Los recursos de tiempo son limitados y no deberá ser mayor a 3 meses (no incluye
tiempo del plan de proyecto).
pág. 23
 Los recursos humanos son 5 personas, pero solo contará con 1 persona que
hará todo el trabajo.
 El sistema debe ser para todo tipo de dispositivo Android.
1.6.6 Interfaces extras
 El software interactuar con API’s de Firebase.
 El software podrá ser utilizado en cualquier disposivo móvil: Android
 La aplicación podrá ser usada en cualquier versión de sistema operativo
Android.
1.7 Alcance
1.7.1 Alcance de la aplicación móvil
El sistema está dividido en 4 modulo, los cuales son:
 Módulo de enfermedades: en este módulo se registran las diferentes
enfermedades que el administrador requiera convenientes con sus diferentes
síntomas ya que el software analizará los datos ingresados por voz.
 Módulo de historial médico: Se visualizará los síntomas que dijo el usuario
con los registros de datos que presentó el usuario al momento de su registro de
datos para que este pueda ser descargado en un histórico médico en pdf para su
futura registro en un centro médico.
 Módulo Análisis De Síntoma: en este módulo se dará un diagnóstico del tipo
de enfermedad y su tratamiento.
pág. 24
 Módulo de Usuario: en este módulo abarca el registro de los usuarios que
utilizaran el siguiente software para los cuales se les pedirá los siguientes datos:
Nombre, Apellido, Edad, Fecha de Nacimiento y Peso.
1.8 Elementos del Sistema Basado en Computadoras
1.8.1 Hardware
1.8.1.1 Servidor
La mayoría de los usuarios cuentan con el siguiente servidor:
 Procesador Intel Core i5-7200U (2.5 GHz Frec. Base hasta 3.10 GHz, 3 MB
cache), séptima generación o superior.
 Memoria RAM de 4GB o superior
 Disco duro de HDD 1 TB
 Unidad de CD-RW / DVD
1.8.1.2 Cliente
El cliente accede al sistema mediante:
 Computadoras de Escritorio.
 Computadoras portátiles.
 Procesador Intel Dual Core 2.5 o superior
 Memoria RAM de 2GB o superior.
pág. 25
1.8.1.3 Métodos De Comunicación
 Red LAN
 Switch
 WIFI para la comunicación inalámbrica de la información
1.8.1.4 Otros Dispositivos
Ninguno
1.8.2 Software
1.8.2.1 Servidor
 Sistema Operativo >= Windows 8.1 de 64 bits.
 Lenguaje de programación Dark, Flutter.
1.8.2.2 Cliente
 Cualquier sistema operativo.
 Un navegador web para PC, sistema operativo Android o IOS.
1.8.2.3 Otro software adicional
 Enterprise Architect.
 Microsoft Office Word 2017.
pág. 26
1.8.3 Datos
1.8.4 Procesos
 Gestionar Paciente
 Gestionar Cita Médica
 Gestionar Enfermedades
 Gestionar Análisis De Síntoma
 Gestionar Especialidad
 Gestionar Historial Clínico
 Gestionar Médico
1.8.5 Gente/Usuarios
Desarrolladores:
 Lorena Michel Ponce Yepez
 Erick Edwing Vidal Cespedes
Usuarios:
La interfaz será capaz de tener en su domicilio a cualquier tipo de usuario.
1.9 Herramientas de Desarrollo
1.9.1 Software
Los elementos que utilizaremos para el desarrollo del software son los siguientes:
Sistema operativos, Sistemas de aplicación, Sistema Gestores de Base de datos.
pág. 27
Sistema operativo
Windows 10 Professional (x64)
Sistemas de Aplicación.
 Android Studio: Este IDE será usado para la implementación de la
aplicación móvil.
 Microsoft Windows Office Professional Plus 2016
Herramienta Case
Enterprise Architect 8.0: que es una herramienta UML (Lenguaje Unificado de
Modelado) que nos servirá para realizar los diferentes Diagramas necesarios en el proceso
de desarrollo del Sistema.
1.9.2 Hardware
En cuanto al hardware para desarrollar el sistema de gestión utilizaremos tres
computadoras portátiles y dos de escritorio que son con las que se cuenta en el equipo de
desarrollo, y que a continuación se describen sus principales características:
HP 15-ac143wm
 Procesador Intel Core i7-7200GHZ
 12 GB de memoria RAM
 Disco duro de 1TB
pág. 28
 Pantalla 17,6”
1.10 Estimación Costos Basados en Recursos
FECHA CANTID PRECIO$ % PRECI PRECIO

RECURSOS
S AD O$ $
Desde Hasta Unitario Depreciación Unit. Total
Neto
Hardware
Computador 09/10/2021 4/01/2022 1 740 25 555 555
Portátil
Disposivo Móvil 09/10/2021 4/01/2022 1 300 50 150 150
Impresora 09/10/2021 4/01/2022 1 50 25 37.5 37.5

Modem 09/10/2021 4/01/2022 1 25 25 18.75 18.75
Software
S.O. 09/10/2021 4/01/2022 1 0 33 0,00 0,00
(Incluido con
computado
ra
portátil)
Architect 09/10/2021 4/01/2022 1 135 30 94.5 94.5
Gente
Analista 09/10/2021 4/01/2022 1 600 0 600 600
Diseñador 09/10/2021 4/01/2022 1 500 0 500 500
Programadores 09/10/2021 4/01/2022 1 400 0 400 400
Infraestructura
Energía Eléctrica 09/10/2021 4/01/2022 35 0 35 105
Servicio de agua 09/10/2021 4/01/2022 15 0 15 45
potable
Internet 09/10/2021 4/01/2022 65 0 65 195
Logística
Mat. Escritorio 09/10/2021 4/01/2022 25 0 25 75
Mat. De limpieza 09/10/2021 4/01/2022 15 0 15 45
Refrigerio 09/10/2021 4/01/2022 42 0 42 126
Total 2946.75
1.11 Gestión de Riesgo
RIESGO %PROB. IMPACTO PLAN DE AVERSIÓN
pág. 29
REDUCIR REDUCIR
PROBABILIDAD IMPACTO
R1: Fallas en el 40 Significativo -Hacer el respectivo -Obtener equipos
hardware o mantenimiento y/o accesorios
software preventivo a los equipos informáticos con
periódicamente. garantía.
-Guardar la Información
con la que está -hacer los
trabajando en los trabajos en
dispositivos. equipos nuevos y
-Realizar las instalaciones
periódicamente copias se encuentren en
de la aplicación en buenas
desarrollo. condiciones.
R2: Perdida de 40 Critico -Realizar las -Almacenar en
información por actualizaciones otros
software mal correspondientes a los dispositivos
intencionado antivirus de los equipos. como USB,
(virus) Disco duro de
reserva,
Nube y que sean
de buena calidad.
R3: 20 Moderado -Emplear metodologías -Trabajar de
Desconocimiento usadas con anterioridad. manera
de la estrategia -Realizar las organizada y
de desarrollo. capacitaciones a los minuciosamente,
desarrolladores en las empleando toda
nuevas tecnologías. la documentación
posible acerca de
las estrategias a
utilizar.
R4: 20 Significativo -Trabajar con -Buscar
Herramientas de herramientas empleadas información y
desarrollo previamente. ayuda en el
desconocido. -Capacitar manejo de la
periódicamente al misma.
personal.
R5: Mala 70 Critico -En el momento de -Contemplar
estimación del realizar la planificación dentro de la
tiempo debido a de tiempos y planificación de
no contemplar actividades, realizar tiempo un tiempo
actividades siguiendo un calendario de demora u
ajenas al en el cual contemple holgura
proyecto. posibles eventualidades asumiendo
y cualquier tipo de
tiempos reales. eventualidad.
pág. 30
1.12 Planificación del Tiempo
Todo proyecto requiere una planificación del tiempo a emplear en las diversas
actividades que se van a llevar a cabo para el cumplimiento del mismo, a través de 2
diagramas se pretende mostrar la distribución de tiempos planificada, primeramente, el
diagrama de Gantt, a través del cual se podrá apreciar el tiempo que se le va a otorgar para
la realización de cada actividad y las actividades que son requisitos para realizar otras
actividades.
En planificación temporal se consideran 2 etapas:
Identificar Actividades
Para desarrollar el software aplicaremos como estrategias el Manifiesto para el
desarrollo de software ágil Scrum.
pág. 31
1.13 Diagrama de Gantt
pág. 32
MODELOS DEL DESARROLLO DEL SOFTWARE
PROCESO DE DESARROLLO SCRUM
1.1 Personas y roles del proyecto
Sprint 1
El Equipo Scrum incluye tres roles: el Product Owner, el Scrum Master y los
miembros del Equipo de Desarrollo.
ROL ENCARGADO TAREAS

PRODUCT OWNER Ponce Lorena Gestionar la pila del producto (Product
Backlog).
SCRUM MASTER Vidal Erick - Realizar el seguimiento de los procesos.
- Garantizar el cumplimiento de roles y
responsabilidades.
- Mejorar el trabajo en equipo.
TEAM - Ponce Lorena - Transformar la pila del sprint (Sprint
- Vidal Erick Backlog).
- Responsables de aspectos técnicos.
Sprint 2
ROL ENCARGADO TAREAS

PRODUCT OWNER Vidal Erick Mantenerse accesible a preguntas del Scrum
Master, para el buen funcionamiento del programa.
SCRUM MASTER Lorena Ponce - Consultar al Product Owner sobre ciertas
dudas acerca de ciertas funcionalidades.
- Supervisión y ayuda en la parte de
programación
TEAM - Ponce Lorena - Implementación de Gestionar Historial
- Vidal Erick Médico.
- Implementar Gestionar Medico.
- Implementar Gestionar Análisis de Síntomas.
pág. 33
1.2 Planeación de la Iteración
1.2.1 Selección de Pre-requisitos
Id Nombre De Tarea Duración Comienzo Fin
HU0-1 Recopilación de fuentes de información 1 día 15/10/21 16/10/21
HU0-2 Planteamiento del proyecto 1 días 16/10/21 17/10/21
HU0-3 Metodología 2 horas 18/10/21 18/10/21
HU0-4 Definir la visión de la aplicación 6 horas 19/10/21 19/10/21
HU0-5 Introducción del equipo 1 hora 19/10/21 19/10/21
HU0-6 Designación de roles 2 horas 20/10/21 20/10/21
HU0-7 Definir el plan de desarrollo de la 6 horas 20/10/21 20/10/21

aplicación
HU0-8 Elección de herramientas 1 hora 21/10/21 21/10/21
HU0-9 Diseño de la base de datos 4 horas 21/10/21 21/10/21
HU0-10 Definir el plan de entrega 2 horas 22/10/21 22/10/21
1.2.2 Selección de Requisitos
Id Requisitos Funcionales Prioridad

HU1 GESTIONAR PACIENTE Media
HU2 GESTIONAR CITA MÉDICA Alta
HU3 GESTIONAR ENFERMEDADES Media
HU4 GESTIONAR ANÁLISIS DE SÍNTOMA Alta
HU5 GESTIONAR MÉDICO Media
HU6 GESTIONAR HISTORIAL CLÍNICO Alta
pág. 34
HU7 GESTIONAR ESPECIALIDAD Media
1.2.3 Ejecución de Iteración
Backlog Lista de Tareas Tipo Responsable
HU0-1 Recopilación de fuentes de información Requisitos Ponce Lorena
HU0-2 Planteamiento del proyecto Análisis Ponce Lorena
HU0-3 Metodología Análisis Vidal Erick
HU0-4 Definir la visión de la aplicación Análisis Vidal Erick
HU0-5 Introducción del equipo Preparación Ponce Lorena
HU0-6 Designación de roles Análisis Ponce Lorena
HU0-7 Definir el plan de desarrollo de la aplicación Preparación Vidal Erick
HU0-8 Elección de herramientas Análisis Vidal Erick
HU0-9 Diseño de la base de datos Diseño Vidal Erick
HU0-10 Definir el plan de entrega Análisis Ponce Lorena
HU1-1 Elaborar historia para la gestión de Pacientes Análisis Ponce Lorena
HU1-2 Diseñar interfaz de usuario para Inicio de Diseño Vidal Erick

sesión
HU1-3 Implementación de la historia de usuario Desarrollo Vidal Erick
HU1-4 Revisar el funcionamiento de lo implementado Prueba Vidal Erick
HU2-1 Elaborar historia de usuario para Gestionar Análisis Ponce Lorena

Enfermedades
HU2-2 Diseñar interfaz de usuario para Gestionar Diseño Ponce Lorena
Enfermedades
HU2-3 Implementación de Enfermedades Desarrollo Vidal Erick
pág. 35
HU3-1 Elaborar historia para la Gestión de Historial Análisis Ponce Lorena

Clínico
HU3-2 Diseñar interfaz de usuario para Historial Diseño Ponce Lorena
Médico
HU3-3 Implementación de la historia de Historial Desarrollo Vidal Erick
Médico
HU4-1 Elaborar historia para gestionar Análisis de Análisis Ponce Lorena

Síntomas
HU4-2 Diseñar interfaz de usuario para Ver Análisis Diseño Ponce Lorena
de Síntomas
HU4-3 Implementación de la historia de Ver Análisis Desarrollo Vidal Erick
de Síntomas
HU5-1 Elaborar historia para gestionar Médico Análisis Ponce Lorena
HU5-2 Diseñar interfaz de usuario para Ver Médico Diseño Ponce Lorena
HU5-3 Implementación de la historia de Ver Médico Desarrollo Vidal Erick
HU6-1 Elaborar historia para gestionar Cita Médica Análisis Ponce Lorena
HU6-2 Diseñar interfaz de usuario para Ver Cita Diseño Ponce Lorena
Médica
HU6-3 Implementación de la historia de Ver Cita Desarrollo Vidal Erick
Médica
HU7-1 Elaborar historia para gestionar Especialidad Análisis Ponce Lorena
HU7-2 Diseñar interfaz de usuario para Ver Diseño Ponce Lorena

Especialidad
HU7-3 Implementación de la historia de Ver Desarrollo Vidal Erick
Especialidad
pág. 36
1.2.4 Lista de Historias de Usuario
 Gestionar Paciente
 Gestionar Cita Médica
 Gestionar Enfermedades
 Gestionar Análisis De Síntoma
 Gestionar Especialidad
 Gestionar Historial Clínico
 Gestionar Médico
1.2.5 Sprint Review
Durante el proceso del Sprint 0 se pudo lograr la realización de todos los puntos
que este Sprint requiere.
Se realizó un análisis exhaustivo del Product Backlog, el cual gracias al
compromiso de todo el grupo obtuvimos una lista de Requisitos Funcionales (Historia de
Usuario).
En conclusión, se pudo notar el trabajo en equipo y la rapidez de la metodología.
1.2.6 Sprint Retrospective
Realizando un análisis interno grupal se acordaron los siguientes puntos en común:
- Priorizar las tareas de acuerdo a la habilidad de cada persona.
- Utilizar las diferentes herramientas físicas de la metodología SCRUM
pág. 37
1.3 Artefacto
1.3.1 Product Backlog
pág. 38
DURACION EN DIAS Sprint 1 Sprint 2 Sprint 3 Sprint 4
27 V S D L MM J V S D L MM J V S D L MM J V S D L MM
01-nov
02-nov
03-nov
04-nov
05-nov
06-nov
07-nov
08-nov
09-nov
09-nov
15-oct
16-oct
17-oct
18-oct
19-oct
20-oct
21-oct
22-oct
23-oct
24-oct
25-oct
26-oct
27-oct
28-oct
29-oct
30-oct
31-oct
Tareas Pendientes 10 10 9 8 7 7 7 6 6 6 5 5 4 4 4 4 3 3 3 3 2 2 2 1 1 1 1
Horas de Trabajo 10 9 9 9 9 10 3 4 2 5 3 1 10 8 7 7 6 6 3 2 4 2 3 3 4 2 1
Pila del Sprint
Backlog Lista de Tareas Tipo Estado Responsable ESFUERZO
HU0-1 Recopilación de fuentes de información Requisitos Terminado Lorena Ponce 2
HU0-2 Planteamiento del proyecto Analisis Terminado Erick Vidal 2 2 1
HU0-3 Metodología Analisis Terminado Lorena Ponce 2
HU0-4 Definir la visión de la aplicación Analisis Terminado Erick Vidal 2
HU0-5 Introducción del equipo Preparacion Terminado Lorena Ponce 1
HU0-6 Designación de roles Analisis Terminado Lorena Ponce 2
HU0-7 Definir el plan de desarrollo de la aplicación Preparacion Terminado Lorena Ponce 2
HU0-8 Elección de herramientas Analisis Terminado Erick Vidal 1
HU0-9 Diseño de la base de datos Diseño Terminado Erick Vidal 2
HU0-10 Definir el plan de entrega Analisis Terminado Erick Vidal 2
HU1 Elaborar historia de usuario para Gestionar Paciente Análisis Terminado Lorena Ponce 2
HU1 Diseñar interfaz de usuario para Gestionar Paciente Diseño Terminado Erick Vidal 1 2
HU1 Implementación de la historia de Paciente Desarrollo Terminado Erick Vidal 2 1
HU1 Revisar el funcionamiento de lo implementado Prueba Terminado Lorena Ponce 1 1
HU2 Elaborar historia de usuario para Gestionar Enfermedades Análisis Terminado Erick Vidal 2 1
HU2 Diseñar interfaz de usuario para Gestionar Enfermedades Diseño Terminado Erick Vidal 2 1
HU2 Implementación de la historia de Gestionar Enfermedades Desarrollo Terminado Erick Vidal 2 1 2
HU3 Elaborar historia de usuario para Gestionar Historial Clinico Análisis Terminado Erick Vidal 2 1
HU3 Diseñar interfaz de usuario para Gestionar Historial Clinico Diseño Terminado Erick Vidal 2 1
HU3 Implementación de la historia de Gestionar Historial Clinico Desarrollo Terminado Erick Vidal 2 2 1
HU4 Elaborar historia de usuario para Analisis de Sintomas Análisis Terminado Erick Vidal 4
HU4 Diseñar interfaz de usuario para Gestionar Analisis de Sintomas Diseño Terminado Erick Vidal 2 1
HU4 Implementación de la historia de Gestionar Analisis de Sintomas Desarrollo Terminado Erick Vidal 4 2
HU5 Elaborar historia de usuario para Gestionar Medico Analisis Terminado Erick Vidal 4 2 1
HU5 Diseñar interfaz de usuario para Gestionar Medico Diseño Terminado Erick Vidal 2 1 1
HU5 Implementación de la historia de Gestionar Medico Desarrollo Terminado Erick Vidal 4 4 2
HU5 Revisar el funcionamiento de lo implementado Prueba Terminado Lorena Ponce 2 1 1
HU6 Elaborar historia de usuario para Gestionar Cita Medica Analisis Terminado Erick Vidal 6 4 1
HU6 Diseñar interfaz de usuario para Gestionar Cita Medica Diseño Terminado Erick Vidal 4 2
HU6 Implementación de la historia de Gestionar Cita Medica Desarrollo Terminado Erick Vidal 2 2 1
HU6 Revisar el funcionamiento de lo implementado Prueba Por Hacer Lorena Ponce 1 1
HU7 Elaborar historia de usuario para Gestionar Especialidad Analisis Por Hacer Erick Vidal 4 2 1
HU7 Diseñar interfaz de usuario para Gestionar Especialidad Diseño Por Hacer Erick Vidal 2 1 1
HU7 Implementación de la historia de Gestionar Especialidad Desarrollo Por Hacer Erick Vidal 2 2 1
HU7 Revisar el funcionamiento de lo implementado Prueba Por Hacer Lorena Ponce 1 1 1
pág. 39
1.3.2 Scrum Taskboard
POR HACER HACIENDO TERMINADO
pág. 40
1.4 Incrementos
1.4.1 Sprint 1
1.4.1.1 Historias de usuario
Recopilación de fuentes de información
HISTORIA DE USUARIO
Número: HU0-1 Usuario: Administrador
Nombre de la historia: Recopilación de fuentes de información
Prioridad en negocio: Alta Riesgo en desarrollo: Alta
Responsables: Lorena Ponce
Descripción: Esta funcionalidad nos permitirá crear una idea y tener las bases del proyecto que se
desarrollará.
Condición de satisfacción: Obtener la información necesaria para poder comenzar con el modelado,
diseño e implementación.
Planteamiento del proyecto
HISTORIA DE USUARIO
Nombre de la historia: Planteamiento del proyecto
Prioridad en negocio: Muy alta Riesgo en desarrollo: Media
Responsables: Erick Vidal
Descripción: Esta funcionalidad nos permitirá identificar los puntos más primordiales del proyecto.
Condición de satisfacción: Definir el planteamiento adecuado que cumpla con las necesidades del
Product Owner.
Metodología
pág. 41
HISTORIA DE USUARIO
Nombre de la historia: Metodología
Prioridad en negocio: Muy alta Riesgo en desarrollo: Media
Descripción: Se expondrá la metodología que se aplicará para el desarrollo del proyecto.
Condición de satisfacción: Todos los participantes deben tener conocimiento sobre la metodología
con la cual se trabajará.
Definir la visión de la aplicación
HISTORIA DE USUARIO
Nombre de la historia: Definir la visión de la aplicación
Descripción: Se comienza a definir qué es lo que se va a realizar y el cómo.
Condición de satisfacción: Estos requisitos deben ir satisfaciendo al Product Owner.
Introducción del equipo
HISTORIA DE USUARIO
Nombre de la historia: Introducción del equipo
Prioridad en negocio: Alta Riesgo en desarrollo: Media
Descripción: Esta parte nos permite evaluar al equipo y la forma en cómo se trabajara
Condición de satisfacción: El equipo debe mantener la armonía
Designación de roles
pág. 42
HISTORIA DE USUARIO
Nombre de la historia: Designación de roles
Descripción: Esta funcionalidad nos permitirá asignar los roles dentro del grupo de desarrollo.
Condición de satisfacción: Cada integrante tendrá un rol asignado
Definir el plan de desarrollo
HISTORIA DE USUARIO
Nombre de la historia: Definir el plan de desarrollo de la aplicación
Descripción: Esta funcionalidad comienza a evaluar y estimar los tiempos de duración de las distintas
actividades
Condición de satisfacción: Los tiempos estimados deben ser tratados de cumplir para lograr el
propósito de los mismos
Elección de herramientas
HISTORIA DE USUARIO
Nombre de la historia: Elección de herramientas
Descripción: Esta funcionalidad nos permite la capacitación respecto de la programación con las
herramientas elegidas.
Condición de satisfacción: El equipo debe relacionarse con las herramientas de desarrollo para su
óptima utilización.
pág. 43
Diseño de base de datos
HISTORIA DE USUARIO
Nombre de la historia: Diseño de la base de datos
Descripción: Esta funcionalidad nos lleva al diseño e implementación de la base de datos
Condición de satisfacción: La base de datos debe contemplar en su totalidad todos los aspectos de
cada requisito funcional.
Definir plan de entrega
HISTORIA DE USUARIO
Nombre de la historia: Definir plan de entrega
Descripción: Esta funcionalidad estimará la duración total del desarrollo.
Condición de satisfacción: El equipo debe tratar de cumplir con las fechas estimadas para así sacar
los artefactos antes o en las fechas indicadas.
Gestionar Pacientes
HISTORIA DE USUARIO
Número: HU1-1 Usuario: Paciente
Nombre de la historia: Pacientes
Responsables: Erick Vidal, Lorena Ponce
Descripción: Aquí el paciente podrá ingresar todos sus datos para ser registrado.
pág. 44
Gestionar Enfermedades
HISTORIA DE USUARIO

Nombre de la historia: Enfermedades
Descripción: Aquí el paciente podrá ver las posibles enfermedades que tengas en base a sus síntomas.
pág. 45
pág. 46
1.4.1.2 Pila del sprint 1
DURACION EN DIAS Sprint 1

7 V S D L M M J
15-oct
16-oct
17-oct
18-oct
19-oct
20-oct
21-oct
Tareas Pendientes 10 10 9 8 7 7 7
Horas de Trabajo 8 6 6 7 8 8 2
Pila del Sprint
Backlog Lista de Tareas Tipo Estado Responsable ESFUERZO
HU0-1 Recopilación de fuentes de información Requisitos Terminado Lorena Ponce 2
HU0-2 Planteamiento del proyecto Analisis Terminado Lorena Ponce 2 2 1
HU0-3 Metodología Analisis Terminado Erick Vidal 2
HU0-4 Definir la visión de la aplicación Analisis Terminado Erick Vidal 2
HU0-5 Introducción del equipo Preparacion Terminado Lorena Ponce 1
HU0-6 Designación de roles Analisis Terminado Lorena Ponce 2
HU0-7 Definir el plan de desarrollo de la aplicación Preparacion Terminado Erick Vidal 2
HU0-8 Elección de herramientas Analisis Terminado Lorena Ponce 1
HU0-9 Diseño de la base de datos Diseño Terminado Erick Vidal 2
HU0-10 Definir el plan de entrega Analisis Terminado Lorena Ponce 2
HU1 Elaborar historia de usuario para Gestionar Paciente Análisis Terminado Erick Vidal 2
HU1 Diseñar interfaz de usuario para Gestionar Paciente Diseño Terminado Erick Vidal 1 2
HU1 Implementación de la historia de Paciente Desarrollo Terminado Erick Vidal 2 1
HU2 Elaborar historia de usuario para Gestionar Enfermedades Análisis Terminado Erick Vidal 2 1
HU2 Diseñar interfaz de usuario para Gestionar Enfermedades Diseño Terminado Erick Vidal 2 1
HU2 Implementación de la historia de Gestionar Enfermedades Desarrollo Terminado Erick Vidal 2 1 2
1.4.1.3 Burndown
TAREAS
ID NOMBRE ESTIMADO Dia 1 Dia 2 Dia 3 Dia 4 Dia 5 Dia 6 Dia 7 TOTAL HRS
HU0-1 Recopilación de Fuentes de Información 2 2 2
HU0-2 Planeamiento del Proyecto 5 2 2 1 5
HU0-3 Metodología 2 2 2
HU0-4 Definir la Visión del Sistema 2 2 2
HU0-5 Capacitación del equipo (TEAM) 1 1 1
HU0-6 Designación de roles 2 2 2
HU0-7 Definir el plan de desarrollo del Sistema 2 2 2
HU0-8 Elección de herramientas 1 1 1
HU0-9 Diseño de la base de datos 2 2 2
HU0-10 Definir el plan de entrega 2 2 2
HU1-1 Elaborar historia de usuario para Gestionar Paciente 2 2 2
HU1-2 Diseñar interfaz de usuario para Gestionar Paciente 3 1 2 3
HU1-3 Implementación de la historia de Paciente 3 2 1 3
HU1-4 Revisar el funcionamiento de lo implementado 2 1 1 2
HU3-1 Elaborar historia de usuario para Gestionar Enfermedades 3 2 1 3
HU3-2 Diseñar interfaz de usuario para Gestionar Enfermedades 3 2 1 3
HU3-3 Implementación de la historia de Gestionar Enfermedades 5 2 1 2 5
HU3-4 Revisar el funcionamiento de lo implementado 3 2 1 3
HORAS RESTANTES 45 37 31 25 18 10 2 0
HORAS ESTIMADAS RESTANTES 45 38,57 32,14 25,71 19,29 12,86 6,43 0,00
pág. 47
1.4.1.4 Scrum Task Board Sprint 1
pág. 48
1.4.1.5 Sprint Review
En el Sprint 1, se tuvo mucho acercamiento del Scrum Master hacia el Product
Owner, para poder captar todas las especificaciones necesarias para que el equipo realice
las funcionalidades de manera eficaz y eficiente.
1.4.1.6 Sprint Retrospective
El equipo tuvo varios problemas en la parte de la programación, sin embargo, el
Scrum Master supo darles su tiempo para reforzar aquellos puntos débiles del Equipo de
forma que se trabaje a la par para conseguir terminar las historias de Usuario seleccionadas.
1.4.2 Sprint 2
1.4.2.1 Historias de usuario
Gestionar Historial Clínico
HISTORIA DE USUARIO
Número: HU3-1 Usuario: Médico y Paciente
Nombre de la historia: Historial Clínico
Descripción: En el historial clínico accederá el médico como el paciente, donde estará todos los datos del
paciente como por ejemplo enfermedad, tipo de sangre, etc.
pág. 49
Gestionar Análisis de Síntomas
HISTORIA DE USUARIO

Nombre de la historia: Análisis de Síntomas
Descripción: Aquí utilizaremos un sistemas expertos basado en redes bayesianas para dar una
probabilidad de la enfermedad que tiene el pacientes.
Gestionar Médico
HISTORIA DE USUARIO
Nombre de la historia: Médico
Descripción: El médico registrará los datos del paciente en el historial clínico y también tendrá una lista de
todas las citas médicas de sus pacientes del día.
pág. 50
1.4.2.2 Pila del sprint 2
DURACION EN DIAS Sprint 2

8 L M M J V S D L
23-nov
24-nov
25-nov
26-nov
27-nov
28-nov
29-nov
30-nov
Tareas Pendientes 4 4 4 4 3 3 3 3
Horas de Trabajo 10 8 7 7 6 6 3 2
Pila del Sprint
Backlog Lista de Tareas Tipo Estado Responsable
ESFUERZO
HU3 Elaborar historia de usuario para Gestionar Historial Clinico Análisis Terminado Erick Vidal 4 2 1
HU3 Diseñar interfaz de usuario para Gestionar Historial Clinico Diseño Terminado Lorena Ponce 2 1 1
HU3 Implementación de la historia de Gestionar Historial Clinico Desarrollo Terminado ERick Vidal 4 4 2
HU3 Revisar el funcionamiento de lo implementado Prueba Terminado Lorena Ponce 2 1 1
HU4 Elaborar historia de usuario para Gestionar Analisis de Sintomas Análisis Terminado Erick Vidal 6 4 1
HU4 Diseñar interfaz de usuario para Gestionar Analisis de Sintomas Diseño Terminado Lorena Ponce 4 2
HU4 Implementación de la historia de Gestionar Analisis de Sintomas Desarrollo Terminado Erick Vidal 2 2 1
HU5 Elaborar historia de usuario para Gestionar Medico Análisis Terminado Erick Vidal 6 4 1
HU5 Diseñar interfaz de usuario para Gestionar Medico Diseño Terminado Lorena Ponce 4 2
HU5 Implementación de la historia de Gestionar Medico Desarrollo Terminado Erick Vidal 2 2 1
pág. 51
1.4.2.3 Burndown
TAREAS
ID NOMBRE ESTIMADO Dia 1 Dia 2 Dia 3 Dia 4 Dia 5 TOTAL HRS
HU3 Elaborar historia de usuario para Gestionar Historial Clinico 4 4 4
HU3 Diseñar interfaz de usuario para Gestionar Historial Clinico 3 2 1 3
HU3 Implementación de la historia de Gestionar Historial Clinico 6 4 2 6
HU3 Revisar el funcionamiento de lo implementado 2 1 1 2
HU4 Elaborar historia de usuario para Gestionar Analisis de Sintomas 4 4 4
HU4 Diseñar interfaz de usuario para Gestionar Analisis de Sintomas 3 2 1 3
HU4 Implementación de la historia de Gestionar Analisis de Sintomas 6 4 2 6
HU5 Elaborar historia de usuario para Gestionar Medico 4 4 4
HU5 Diseñar interfaz de usuario para Gestionar Medico 3 2 1 3
HU5 Implementación de la historia de Gestionar Medico 6 4 2 6
HORAS RESTANTES 15 11 9 4 1 0
HORAS ESTIMADAS RESTANTES 15 12,00 9,00 6,00 3,00 0,00
1.4.2.4 Scrum Task Board Sprint 2
pág. 52
1.4.2.5 Sprint Review
El Product Owner pudo ver y realizar pruebas de acuerdo a las especificaciones
dadas por este al Scrum Master, se Observaron varios detalles para el buen desarrollo de las
funcionalidades, los cuales el equipo va solucionando y auto-complementando.
pág. 53
1.4.2.6 Sprint Retrospective
 Problemas o Impedimentos
Hacer últimas reuniones para los últimos detalles.
 Cosas a Mejorar
Incentivar de mejor manera el trabajo en equipo.
pág. 54
1.5 Modelos
1.5.1 Modelo de Despliegue
pág. 55
1.5.2 Modelo de Arquitectura
Diagrama de Contexto
Diagrama de Contenedores
pág. 56
Diagrama de Componentes
pág. 57
1.5.3 Modelo de Datos
Diagrama de Clases
pág. 58
Bibliografía
 El diagnóstico temprano del cáncer salva vidas y reduce los costos de tratamiento.
(2017, February 3). WHO | World Health Organization. Retrieved November 29,
2021, from https://www.who.int/es/news/item/03-02-2017-early-cancer-diagnosis-
saves-lives-cuts-treatment-costs
 En Bolivia el cáncer de mama afecta a 12 mujeres por día. (2020, October 15).
InfoRSE. Retrieved November 29, 2021, from
https://www.inforse.com.bo/2020/10/15/en-bolivia-el-cancer-de-mama-afecta-a-12-
mujeres-por-dia/
 Fernández, A. (2021, June 19). Qué es la Inteligencia Artificial • Definición, ejemplos
y casos de uso. AuraQuantic. Retrieved November 29, 2021, from
https://www.auraquantic.com/es/que-es-la-inteligencia-artificial/
pág. 59

Modelos de Desarrollo

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Modelos de Desarrollo

Cargado por

Copyright:

Formatos disponibles

“ASISTENTE DE ENFERMEDADES

CON INTELIGENCIA ARTIFICIAL

Y CIENCIA DE DATOS PARA

GENERAR UNA PROBABILIDAD

“MODELOS DEL DESARROLLO DE SOFTWARE

● Ponce Yepez Lorena Michel 213109999

MATERIA: Ingeniería de Software II

DOCENTE: Ing. Martinez Canedo Rolando

SANTA CRUZ – BOLIVIA

PAPS (PLAN DE ADMINISTRACION DE PROYECTO DE SOFTWARE) ......... 6

1.1 Introducción .................................................................................................. 6

1.2 Propósito del documento .............................................................................. 8

1.3 Descripción del Problema ............................................................................. 9

1.4 Métricas del software .................................................................................... 9

1.4.1 Datos históricos usados en la métrica ..................................................... 9

1.4.2 Métrica orientada al tamaño (MOT) ..................................................... 12

1.4.3 Métrica orientada a la función (MOF) .................................................. 13

1.5 Estimaciones ............................................................................................... 17

1.5.1 Características del proyecto .................................................................. 17

1.6 Ámbito del proyecto ................................................................................... 18

1.6.1 Objetivo del proyecto ............................................................................ 18

1.6.2 Requerimientos principales................................................................... 19

1.6.3 Rendimiento .......................................................................................... 19

1.6.4 Fiabilidad .............................................................................................. 21

1.6.5 Restricciones ......................................................................................... 23

1.7 Alcance ....................................................................................................... 24

1.7.1 Alcance de la aplicación móvil ............................................................. 24

1.8 Elementos del Sistema Basado en Computadoras ...................................... 25

1.8.1 Hardware ............................................................................................... 25

1.8.2 Software ................................................................................................ 26

1.8.3 Datos ..................................................................................................... 27

1.8.4 Procesos ................................................................................................ 27

1.8.5 Gente/Usuarios ...................................................................................... 27

1.9 Herramientas de Desarrollo ........................................................................ 27

1.9.1 Software ................................................................................................ 27

1.9.2 Hardware ............................................................................................... 28

1.10 Estimación Costos Basados en Recursos ................................................ 29

1.11 Gestión de Riesgo.................................................................................... 29

1.12 Planificación del Tiempo ........................................................................ 31

1.13 Diagrama de Gantt .................................................................................. 32

MODELOS DEL DESARROLLO DEL SOFTWARE ........................................... 33

1.1 Personas y roles del proyecto ...................................................................... 33

1.2 Planeación de la Iteración ........................................................................... 34

1.2.1 Selección de Pre-requisitos ................................................................... 34

1.2.2 Selección de Requisitos ........................................................................ 34

1.2.3 Ejecución de Iteración .......................................................................... 35

1.2.4 Lista de Historias de Usuario ................................................................ 37

1.2.5 Sprint Review ....................................................................................... 37

1.2.6 Sprint Retrospective .............................................................................. 37

1.3 Artefacto ..................................................................................................... 38

1.3.1 Product Backlog .................................................................................... 38

1.3.2 Scrum Taskboard .................................................................................. 40

1.4 Incrementos ................................................................................................. 41

1.4.1 Sprint 1 .................................................................................................. 41

1.4.2 Sprint 2 .................................................................................................. 49

1.5 Modelos ...................................................................................................... 55

1.5.1 Modelo de Despliegue .......................................................................... 55

1.5.3 Modelo de Datos ................................................................................... 58

El auge de la tecnología de la información ha brindado numerosos beneficios en

diversas industrias, incluida la atención médica.

Las instituciones de salud y las compañías médicas ahora están cambiando su

enfoque hacia la aplicación de TI a través de sistemas de software de atención médica.

El software de atención médica se refiere a programas «inteligentes» de apoyo a la

decisión médica que ofrecen asistencia, orientación y comentarios en el entorno de la