Esc 2 Modelo de Proceso de Desarrollo de Software Tradicionales

“Sistema De Información Para La Gestión De La Salud”
Jean Paul Espinosa Ortiz – CC 1000860009
Andrés Murcia Muñoz - CC 1073322672
John Jairo Preciado – CC 70253364
Obed Bermúdez Jaimes – CC 1007690480
Institución Universitaria Politécnico Grancolombiano
Ingeniería de Software
Febrero 2022
2
Tabla de Contenido
Tabla de Contenido.......................................................................................................... 2
Lista de Tablas................................................................................................................. 5
Lista de Figuras...............................................................................................................6
Introducción..................................................................................................................... 7
Planteamiento del Problema............................................................................................8
Descripción del Problema.............................................................................................8
Justificación.................................................................................................................. 9
Objetivos........................................................................................................................ 11
General....................................................................................................................... 11
Específicos................................................................................................................. 11
Cronograma................................................................................................................... 12
Modelo de Procesos......................................................................................................13
Modelo de Procesos Seleccionado (Modelo en Espiral).............................................13
Modelo de Procesos Descartados..............................................................................13
Modelo en Cascada................................................................................................13
Modelo de Procesos Incremental............................................................................14
Modelo de Procesos por Prototipos........................................................................14
Modelo de Procesos Evolutivo................................................................................15

3
Modelo de Procesos Lineal.....................................................................................15
Metodología Ágil............................................................................................................ 16
Artefactos................................................................................................................... 16
Product backlog:.....................................................................................................17
Sprint backlog:........................................................................................................ 17
Graph Release burn-down......................................................................................17
Graph Sprint burn-down..........................................................................................18
Impediments backlog e incidence backlog (IB).......................................................18
Roles.......................................................................................................................... 19
Product Owner........................................................................................................19
Scrum Master..........................................................................................................19
Developer Team.....................................................................................................19
Requisitos Funcionales y No Funcionales......................................................................21
Requisitos Funcionales...............................................................................................21
Requisitos No Funcionales........................................................................................39
Diagramas y Documentación de Casos de Uso.............................................................41
Diagrama de Casos de Uso........................................................................................41
Documentación de Casos de Uso..............................................................................43
Diagrama de Clases.......................................................................................................65
Bibliografía..................................................................................................................... 67
4
5
Lista de Tablas
Tabla 1 Requisitos Funcionales (RF).............................................................................21
Tabla 2 Requisitos No Funcionales................................................................................39
Tabla 3 Documentación de Casos de Uso.....................................................................44

6
Lista de Figuras
Figura 1 Cronograma.....................................................................................................11
Figura 2 Caso de Uso del Sistema.................................................................................40
Figura 3 Caso de Uso Administrador.............................................................................41
Figura 4 Caso de Uso Cliente........................................................................................41
Figura 5 Diagrama de Clase..........................................................................................65

7
Introducción
Las TICs ofrecen muchos beneficios que contribuyen al mejoramiento de la calidad de
vida, es por eso que con el software se busca es dar solución a un problema específico y
satisfacer las necesidades del Cliente.
En el vivir cotidiano, en la mayoría de las familias hay uno o varios integrantes que
asisten a las entidades de salud, por diversos motivos (citas periódicas, enfermedad repentina,
entre otros) y son muchas veces en las que en su domicilio se encuentran con toda clase de
dudas y preguntas como por ejemplo ¿estos exámenes estarán bien o mal?, ¿mis signos
vitales estarán bien o mal?, y muchos otros interrogantes. Y para brindar solución a este tipo de
necesidad, se creará el software llamado “Sistema de Información para la Gestión de la
Salud” un software que ofrecerá al usuario la posibilidad de llevar diversos controles de su
salud y ofrecerá la interpretación de exámenes de laboratorios más comunes enviado por los
profesionales de la salud.
Este software contara con fiabilidad, eficiencia, y facilidad de mantenimiento y será de
fácil acceso y manipulación por parte de Usuarios, Además ofrecerá privacidad para aquellos
miembros del grupo familiar que así lo requiera al permitir que el Usuario que desee, cree un
usuario con su respectiva contraseña, entre muchas otras funciones que son de beneficio
familiar.
8
Planteamiento del Problema
Descripción del Problema
El cliente actualmente no cuenta con la posibilidad de consultar la información de su
estado de salud y de la familia misma basándose en los síntomas que pueda presentar en el
presente o a futuro sin tener que recurrir a visitar directamente a un médico. Debido a esto el
cliente puede presentar los siguientes inconvenientes: al enfermar puede contagiar a otras
personas en la visita de un médico, recurrir a tomar acciones muy cuestionables para mejorar
su salud basándose en información de la red u otorgada por terceros que no son especialistas,
además de una perdida grande de tiempo en la solicitud de alguna cita.
¿Un sistema de información puede mejorar los procesos en la consulta de estados de
salud para el cliente y su familia basándose en exámenes y seguimientos de condiciones de
salud?
9
Justificación
La realización de este sistema de información busca atenuar falencias que existen con
respecto al acceso a este tipo de software, ya que tendrá un costo muy accesible a la población
de bajos recursos económicos, permitiendo que aquellos que lleguen a utilizarlo, se contagien
de él y decidan recomendarlo a otras personas por el buen beneficio que este les presta.
El sistema de información a desarrollar será un programa que pretende que todas
aquellas personas que consultan periódicamente al médico cuenten con un instrumento de
consulta, y de esta manera será un aporte muy valioso, de tranquilidad para saber cómo
marcha su estado de salud.
El software será una herramienta que podrá ser utilizada como instrumento para
consulta de sus paraclínicos de rutina. Es importante saber que el software contará con:
 Una descripción breve y clara sobre lo consultado.
 Un registro de los accesos, de esta manera cada vez que el usuario ingrese sus datos,
estos se guardarán, lo que le permitirá al cliente hacer una comparación con el registro
anterior.
 Será una herramienta para las personas interesadas en tener conocimiento sobre el
resultado de ciertos datos de salud, como: signos vitales, paraclínicos (hemogramas,
ionogramas, parcial de orina, glicemia, entre otros).

10
 Este software Jamás reemplaza el criterio médico, pero si será de mucha ayuda y
tranquilidad al usuario, ya que le permitirá al usuario, tener una idea de cómo va su
estado de salud.
11
Objetivos
General
Recopilar información para crear un software que permita ofrecer, a los clientes una
consulta confiable sobre algunos datos que cotidianamente son de preocupación, tales como
interpretación de exámenes de laboratorio, glucometrías, signos vitales, entre otros.
Específicos
 Modelar y elaborar un software que permita de una manera sencilla y ágil la consultar datos
de salud
 Identificar procesos que faciliten la recolección de datos que se manejen dentro del proceso
de análisis de requerimientos.
 Utilizar estos procesos de recolección como bases de la información que se maneja dentro
de la herramienta computacional.
 Utilizar este proceso como base para la elaboración de un prototipo.
 A través de esta herramienta agilizar y facilitar el proceso de recolección de información
para la creación del Software.
 Profundizar los conocimientos en las necesidades de los clientes, en pro de mejorar el
software a futuro.
 Hacer uso de los instrumentos de Recolección de Datos, para la realización del proyecto.
 Buscar datos que nos permita la obtención de una información confiable.
 Facilitar el acceso de la información, al escogerse el instrumento de Recolección de Datos
correcto.
 Ofrecer confiabilidad e integridad del proyecto, al encontrarse datos correctos.
 Permitir que los mejoramientos realizados al software “Sistemas de Información para la
Gestión de la Salud” sean realizados de forma oportuna.
12
Cronograma
Figura 1 Cronograma
13
Modelo de Procesos
Modelo de Procesos Seleccionado (Modelo en Espiral)
El “Sistema de Información para la Gestión de la Salud” es un proyecto pequeño,
pero se escoge este modelo porque es una combinación de los modelos de proceso en
cascada, modelo de proceso incremental, modelo de proceso por prototipos y en todas las
fases se estará analizando y corrigiendo los posibles riesgos que se puedan presentar y
siempre el Cliente estará enterado de como marcha el proyecto y podrá sugerir a tiempo
cambios que desea se le realicen al software. Lo que al final permitirá un producto que cumple
con las expectativas que el Cliente esperaba.
Modelo de Procesos Descartados
Modelo en Cascada
Se descarta el modelo en cascada debido a ser un modelo de procesos bastante
ambiguo en el cual requiere de una revisión muy estricta en las diferentes etapas; al
presentarse un error en cualquier etapa genera un reproceso, puede provocar el fracaso del
proyecto al no poder retomar etapas si el proyecto está bastante avanzado y mas si el proyecto
es grande, generando así sobrecostos e inconformidades con el cliente.

14
Modelo de Procesos Incremental
A pesar de que se puedan acortar lo tiempos de entrega y permite el retorno de
versiones del proyecto en caso de una falla, se descarta el modelo de procesos incremental por
la difícil estimación de costos al requerir de una gran planeación tanto administrativa como
técnica. Además, el cliente no se encuentra constantemente disponible para mostrar los
avances del proyecto.
Modelo de Procesos por Prototipos
El modelo de procesos por prototipos pese a tener la opción de desarrollar prototipos
desde el inicio de las etapas para que el cliente pueda familiarizarse con el producto, esto
puede conllevar a generarse una gran cantidad de iteraciones que puede generar un proceso
lento en el desarrollo del proyecto al desconocer el tiempo que toma cada gestión por iteración,
asimismo dificulta controlar las expectativas del cliente al mostrar simplemente versiones no
funcionales del producto.

15
Modelo de Procesos Evolutivo
Al igual que el modelo de procesos por prototipos el modelo de procesos evolutivo
cuenta con una serie de iteraciones que pueden ser mostradas al cliente, sin embargo, tiene la
falencia de que por cada iteración se debe crear un manual de uso generando el avance lento
en la entrega del proyecto, agregando que la primera iteración puede plantear los mismos
problemas de un modelo de procesos lineal o secuencial.
Modelo de Procesos Lineal
Al igual que el modelo de procesos de cascada, este modelo al mínimo error puede
provocar el fracaso del proyecto, esto debido a que requiere tener unas bases sólidas en el
análisis y planeación del proyecto ya que no es posible iniciar una fase hasta que esté
aprobada la fase anterior (errores que se presenten en las fases iniciales ya provoca problemas
en las fases posteriores), las remediaciones son muy costosas, al tener este modelo se debe
tener un margen de error a 0 aunque el proyecto sea grande o pequeño.

16
Metodología Ágil
Elegimos la metodología scrum ya que es una de las más utilizadas actualmente, así
mismo nos da no solo un panorama completo y de baja complejidad en el desarrollo de
proyectos, al entregar productos funcionales de manera incremental, hace que la satisfacción
de los clientes aumente.
El marco de trabajo de scrum está bien documentado y hace que los equipos de trabajo
opten por preferir las buenas prácticas allí plasmadas, puesto no solamente se lleva
seguimiento a las tareas o necesidades que el cliente nos expone, sino que se pueden resolver
situaciones que no están contempladas o que sus tiempos de solución sean extensos.
En este punto nos preguntamos ¿en cuál plantilla o formato ejecuto el scrum? La
respuesta es sencilla, lo puedes ejecutar desde una hoja de cálculo o apoyarse en
herramientas web que hoy en día podemos utilizar como jira, esta es intuitiva y que podemos
apoyarnos para el seguimiento y asignación de tareas a nuestro equipo.
Artefactos
Los artefactos son todos aquellos elementos que nos garantiza la transparencia y el
registro de toda información fundamental de la metodología de scrum, estos nos afirman la
calidad y productividad de cualquier proyecto.

17
Product backlog:
Es la principal fuente de información sobre el producto de Scrum (Una lista) esta lista
contiene todos los requerimientos que necesitamos para implementar el producto, la lista es lo
que obtenemos del trabajo por parte del Product Owner, este se escribe en idioma del cliente y
se compone de historia de usuarios, cada historia se complementa cada vez que se necesita
información. El PO es el encargado de que los usuarios proporcionen suficiente información útil
y de priorizarla.
Sprint backlog:
Es una lista de funcionalidades que provienen del product backlog que se incorpora en
la parte del Sprint. Su propósito es mantener la transparencia dentro del desarrollo,
actualizando durante toda la iteración a través de los daily Scrums. Nos permite visualizar
durante cada Sprint, observar que está terminado, que no ha empezado a desarrollarse, en
cuales se está trabajando.
Graph Release burn-down

18
El release burn-down es responsabilidad del PO. Con este gráfico el PO puede ver la
evolución del proyecto y tomar medidas a cada sprint review. Es un gráfico de trabajo
pendiente de cada Sprint a lo largo del tiempo que muestra la velocidad a la que se están
completando los objetivos, requisitos, o historias de usuarios. La línea correspondiente a la
velocidad del equipo muestra el número de story points que el equipo ha resuelto en cada
sprint. En el eje (X) visualizamos los sprint y en el eje (Y) los story points resueltos.
Graph Sprint burn-down
El sprint burn-down es responsabilidad del SM. Este gráfico se mantiene actualizado
gracias a la consulta diaria del Scrum board. Y permite al SM conocer la evolución del sprint en
curso. Este grafico nos muestra la valoración de las horas en las que se realizó cada una de las
tareas.
Este grafico tambien nos da a conocer la suma de horas que se van realizando y
cambian del estado pendiente. En el eje (X) observamos los dias que estan compuestos por el
Sprint y en el eje (Y) las horas invertidas.
Impediments backlog e incidence backlog (IB)
El impediments backlog es una lista que nos da a conocer los problemas que nos sirve
de registro para que el scrum master le pueda brindar soluciones estos problemas son de difícil
solución porque sobrepasan la capacidad de resolución del propio equipo. La incidence backlog
19
es una lista de problemas referente a los sprint, cualquier cambio no previsto es registrado en
esta lista para brindar solución en sprint retrospective estos son más fáciles de solucionar.
Roles
Product Owner
Es el encargado de optimizar y maximizar el valor del producto, siendo la persona
encargada de gestionar el flujo de valor del producto a través del Product Backlog. Es el
interlocutor entre el Scrum Master y el mismo cliente para cumplir con las necesidades del
cliente. Product Owner: Jean Paul Espinosa Ortiz.
Scrum Master
Se encarga de gestionar el proceso Scrum y ayudar a eliminar impedimentos que
puedan afectar a la entrega del proyecto. Además, se encarga de las labores de formación,
coaching y de facilitar reuniones y eventos si es necesario. Scrum Master: Andrés Murcia
Muñoz.
Developer Team
20
Son los encargados de desarrollar el proyecto, auto organizándose y auto
gestionándose para conseguir entregar un incremento de software al final del ciclo de
desarrollo. Son los encargados del desarrollo del sistema de información. Developer Team:
Jean Paul Espinosa Ortiz, Andrés Murcia Muñoz, John Jairo Preciado,Obed Bermúdez Jaimes.
21
Requisitos Funcionales y No Funcionales
Requisitos Funcionales
Tabla 1 Requisitos Funcionales (RF)
Código Nombre Fecha Grado

Necesidad
RF001 Iniciar sesión Viernes, alto

11 de
marzo
2022
Descripción El sistema permitirá el ingreso del aplicativo a usuarios si se valida

correctamente los datos requeridos (usuario, contraseña).
Regla de
Entradas Fuente Salida Destino
negocio
Nombre de Mockup Ingreso a la plataforma correctamente Base de El cliente

usuario validar datos que desee
usuario ingresar al
Contraseña sistema
deberá estar
previamente
registrado.
Proceso El sistema verifica los campos con la base de datos y remite el usuario al
menú principal del aplicativo según corresponda con el tipo de usuario.
Efecto colateral No se pudo iniciar sesión.

22

Necesidad
RF002 Registrar cliente Viernes, alto

11 de
marzo
2022
Descripción El sistema debe permitir a un administrador registrar clientes.

El sistema debe permitir a un cliente registrarse a sí mismo.
Entradas Fuente Salida Destino Regla de

negocio
Documento Mockup Usuario registrado correctamente Base de Una vez

cliente registrar datos registrado el
cliente cliente le llegara
Nombres Cliente una notificación
Apellidos Cliente al correo
electrónico
Genero Cliente informando del
registro en el
Edad Cliente
sistema.
Correo Cliente
Usuario
Clave
Proceso El sistema valida los campos y los almacena en la base de datos
Efecto colateral No se puede registrar el usuario.

23

Necesidad
RF003 Modificar cliente Viernes, alto

11 de
marzo
2022
Descripción El sistema debe permitir a un administrador modificar la información de

los clientes a excepción de la clave.
El sistema debe permitir a un cliente modificar sus datos personales.

negocio
Documento Mockup Usuario actualizado Base de Una vez

cliente modificar correctamente datos actualizados
cliente los campos,
Nombres Cliente se le
Apellidos Cliente informara al
cliente una
Genero Cliente vez ingrese
al sistema.
Edad Cliente
Correo Cliente
Usuario
Clave
Proceso El sistema valida los campos y los modifica en la base de datos
Efecto colateral No se puede actualizar los datos de este usuario.

24

Necesidad
RF004 Inhabilitar cliente Viernes, alto

11 de
marzo
2022
Descripción El sistema debe permitir a un administrador inhabilitar a un cliente.

negocio
Id Cliente Mockup Usuario inhabilitado correctamente Base de Cliente

inhabilitar datos previamente
cliente registrado.
Proceso El sistema verifica el id del cliente en la base de datos

El sistema cambia el estado del usuario cliente a inhabilitado
Efecto colateral No se puede inhabilitar el cliente.

Necesidad
RF005 Consultar cliente Viernes, alto

11 de
marzo
2022
Descripción El sistema debe permitir a un administrador consultar los datos de los

clientes.
25
El sistema debe permitir a un cliente consultar sus propios datos.

negocio
Id Cliente Mockup Muestra información de los Mockups No aplica

consultar clientes
cliente
Proceso El sistema muestra los datos de los clientes.
Efecto colateral No aplica

Necesidad
RF006 Registrar Familiar Viernes, alto

11 de
marzo
2022
Descripción El sistema debe permitir a un administrador o cliente registrar los datos

de los familiares del cliente.

negocio
Documento Mockup Familiar registrado correctamente Base de Debe existir

Familiar registrar datos un parentesco
familiar con el cliente
Nombres Familiar para registrar
Apellidos Familiar el familiar
Edad
26
Genero
Parentesco
Proceso El sistema valida los datos y los almacena en la base de datos.
Efecto colateral No se puede registrar el familiar

Necesidad
RF007 Modificar Datos del Familiar Viernes, alto

11 de
marzo
2022
Descripción El sistema debe permitir a un administrador o cliente modificar los datos

de los familiares del cliente.

negocio
Documento Mockup Datos del Familiar actualizados Base Una vez

Familiar modificar correctamente de actualizado
familiar datos los
Nombres campos,
Familiar se le
Apellidos informa al
Familiar cliente una
vez
Edad ingrese al
sistema.
Genero
Parentesco
Proceso El sistema valida los datos y los modifica en la base de datos.

27
Efecto colateral No se puede actualizar la información del familiar.

Necesidad
RF008 Eliminar Familiar Viernes, 11 de alto

marzo 2022
Descripció El sistema debe permitir a un administrador o cliente eliminar los datos

n de los familiares del cliente.

negocio
Id_Familiar Mockup Familiar Base de datos Familiar

eliminar eliminado previamente
familiar correctamente registrado
Proceso El sistema verifica la existencia del familiar en la base de datos

El sistema cambia el estado del usuario cliente a inhabilitado
Efecto colateral No se puede eliminar el familiar de la base de datos.

28

Necesidad
RF009 Consultar Familiar Viernes, 11 de alto

marzo 2022
Descripció El sistema debe permitir a un administrador o cliente consultar los datos

n de los familiares del cliente.

negocio
Id_Familiar Mockup Muestra Mockup No aplica

consultar información de
familiar los familiares
Proceso El sistema muestra los datos del familiar

29

Necesidad
RF010 Registrar Condición de Salud Viernes, 11 de alto

marzo 2022
Descripció El sistema debe permitir a un administrador o cliente registrar una

n condición de salud.
Entradas Fuente Salida Destino Regla

de negocio
Condición Mockup Condición Base de datos No aplica

registrar registrada
Observación condición correctamente
Gravedad
Proceso El sistema valida los campos ingresados y los compara con los datos de
condiciones actuales, posteriormente registra una nueva condición
Efecto colateral No se puede registrar la condición.

Necesidad
RF011 Modificar Condición de Salud Viernes, 11 de alto

marzo 2022
Descripció El sistema debe permitir a un administrador o cliente modificar una

n condición de salud.

negocio
Condición Mockup Condición Base de datos La condición debe

modificar modificada estar registrada
Observación
30
Gravedad condición correctamente previamente en el

sistema.
Proceso El sistema valida los campos ingresados y posteriormente se modifica

los
datos de la condición.
Efecto colateral No se puede actualizar los datos de la condición de salud.

Necesidad
RF012 Inhabilitar Condición de Salud Viernes, 11 de alto

marzo 2022
Descripció El sistema debe permitir a un administrador inhabilitar una condición de

n salud.

negocio
Id Condición Mockup Condición Base de datos La condición debe

inhabilitar inhabilitada estar registrada
condición correctamente previamente en el
sistema.
Proceso El sistema modifica el estado de la condición de salud a “inhabilitado”.
Efecto colateral No se puede inhabilitar la condición de salud.

31

Necesidad
RF013 Consultar Condición de Salud Viernes, 11 de alto

marzo 2022
Descripció El sistema debe permitir a un administrador o un cliente consultar las

n diferentes condiciones de salud.

de negocio
Id Condición Mockup Muestra Mockups No aplica

consultar información de las
condición condiciones
registradas
Proceso El sistema muestra todas las condiciones de salud almacenadas en la

base de datos, incluyendo las inhabilitadas.

Necesidad
RF014 Asignar Condición de Salud Viernes, 11 de alto

marzo 2022
Descripció El sistema debe permitir a un administrador asignar una condición de

n salud a un cliente.
El sistema debe permitir a un cliente asignar su condición de salud.

negocio
32
Id Condición Mockup Condición de Base de datos La condición de

asignar salud asignada salud y el cliente
Id Cliente condición correctamente debe estar
registrado en el
sistema.
Proceso El sistema asigna una condición de salud a un cliente.
Efecto colateral No se puede asignar la condición de salud al cliente.

Necesidad
RF015 Registrar Resultados de Viernes, 11 de alto

Exámenes marzo 2022
Descripción El sistema debe permitir a un administrador o cliente registrar un

examen de laboratorio.

negocio
Examen de Mockup Examen de Base de El sistema envía

Laboratorio registrar laboratorio datos una notificación al
examen registrado correo del cliente
Medico correctamente mencionando el
Fecha Examen registro del
resultado del
Observación examen.
Documento
Id Cliente
Proceso El sistema registra un nuevo examen de laboratorio.
Efecto colateral No se puede registrar el resultado del examen de laboratorio.

33

Necesidad
RF016 Modificar Resultado Examen Viernes, 11 de alto

marzo 2022
Descripción El sistema debe permitir a un administrador o cliente modificar una

condición de salud.

negocio
Examen de Mockup Examen de Base de datos El examen de

Laboratorio modificar laboratorio laboratorio debe
examen modificado estar registrado
Medico correctamente previamente en el
Fecha Examen sistema.
Observación
Documento
Id Cliente
Proceso El sistema valida los campos ingresados y posteriormente se modifica

los
datos del resultado del examen de laboratorio.
Efecto colateral No se puede actualizar los datos del resultado del examen de
laboratorio.

34
Necesidad
RF017 Consultar Resultado Examen Viernes, 11 de alto

marzo 2022
Descripción El sistema debe permitir a un administrador consultar los resultados de los

exámenes de laboratorio de los clientes.
El sistema debe permitir al cliente consultar sus resultados de exámenes de
laboratorio.

negocio
Id Examen Mockup Muestra información de los Mockups No aplica

consultar exámenes de laboratorio
examen registrados
Proceso El sistema muestra todos los resultados de los exámenes de laboratorio

almacenadas en la base de datos.
Efecto No aplica
colateral

Necesidad
RF018 Gestionar Indicadores de Salud Viernes, 11 de alto

marzo 2022
Descripció El sistema debe permitir a un administrador registrar, modificar o

n consultar indicadores de salud de los clientes.
El sistema debe permitir al cliente registrar, modificar o consultar sus
indicadores de salud.
35

negocio
Id indicador Mockup Indicador Base de Al registrar o

gestionar gestionado datos y modificar el
Id Cliente indicador correctamente Mockups indicador de salud
Indicador este será notificado
al cliente vía correo
Observación electrónico.
Proceso El sistema valida los campos ingresados y posteriormente los registra en

la base de datos.
Efecto colateral No se puede gestionar la información correspondiente.

Necesidad
RF019 Gestionar Control Profesional Viernes, 11 de alto

marzo 2022
Descripción El sistema debe permitir a un administrador registrar, modificar o

consultar el control profesional de los clientes.
controles profesionales.

negocio
Id Control Mockup Control con el Base de datos Al registrar o

gestionar profesional y mockups modificar un
Id Cliente control gestionado control este será
Nombre correctamente notificado al cliente
profesional vía correo
electrónico.
36
Profesión
Fecha Control
Observaciones
Proceso El sistema valida los campos ingresados y posteriormente los registra

en la base de datos.

Necesidad
RF020 Gestionar Seguimientos Viernes, 11 de alto

marzo 2022
Descripción El sistema debe permitir a un administrador registrar, modificar o

consultar los seguimientos de los clientes.
seguimientos.

negocio
Id Seguimiento Mockup Seguimiento Base de Al registrar o

gestionar gestionado datos y modificar un
Id Cliente seguimiento correctamente Mockups seguimiento este
Condición será notificado al
cliente vía correo
Fecha electrónico.
Seguimiento
Tratamiento
Observación
Proceso El sistema valida los campos ingresados y posteriormente los registra en

la base de datos.
37

Necesidad
RF021 Generar Reportes Viernes, 11 de alto

marzo 2022
Descripción El sistema debe permitir a un administrador o cliente generar un reporte

correspondiente a resultados de exámenes de laboratorio, indicadores
de salud, seguimientos a condiciones e información general de los
clientes. El cliente solo puede ver información personal y no ajena.

de negocio
Id Cliente Mockup Genera un reporte Base de No aplica

generar correspondiente a la datos y
Fecha reportes información filtrada Mockups
Indicadores
Exámenes
Seguimientos
Proceso El sistema genera un reporte con la información filtrada por el usuario.

Necesidad
RF022 Cerrar Sesión Viernes, 11 de alto

marzo 2022
38
Descripció El sistema debe permitir a todos los usuarios cerrar la sesión.

n

de negocio
Mockup Muestra el login Mockup No aplica

cerrar sesión para ingresar al
sistema
Proceso El sistema genera redirige al usuario al inicio de sesión.

39
Requisitos No Funcionales
Tabla 2 Requisitos No Funcionales
Código RQNF 001
Usabilidad Será software muy fácil de manipular, con una interfaz
gráfica atractiva y para su instalación no se requiere de
conocimientos de programación.
Eficiencia El software será rápido y liviano que requiere muy pocos
recursos del sistema para su funcionamiento correcto.
Confiabilidad Será un software muy estable, y de manera automática
guardará los datos ingresados para ofrecer mayor confianza
en el usuario.
Portabilidad Solo podrá ser funcional en una plataforma de Windows,
pero es muy fácil de instalar y desinstalar.
Mantenibilidad El software permitirá ser cambiado a otra versión en un
periodo aproximado de dos años, y brindará actualizaciones
nuevas.
Requerimientos Organizacionales
40
Requerimientos de El software será realizado en un tiempo aproximado de seis
Entrega meses.
Requerimientos de El software utilizará como motor de base de datos MySQL y
implementación el lenguaje de programación Python.
CMMI (norma que regula la mejora de procesos de
Requerimientos construcción de software y proyectos de TI) y PSP (norma
estándares que permite estimar el tiempo que se tarda en realizar la
aplicación del software.
Requerimientos Externos
Requerimientos de Será un software que es compatible con las versiones
Interpolaridad iguales o superiores a Windows 7.
Requerimientos Éticos El software iniciara en la versión 0 y no es copia de otros
softwares existentes en el mercado.
Requerimientos de El sistema no revelará los
Privacidad datos personales a otros
Requerimientos Usuarios no autorizados.
Legislativos Requerimientos de El software contará con la
Seguridad posibilidad de crear clave de
acceso para mayor reserva
de los datos ingresados.

41
42
Diagramas y Documentación de Casos de Uso
Diagrama de Casos de Uso
Figura 2 Caso de Uso del Sistema

43
Figura 3 Caso de Uso Administrador
Figura 4 Caso de Uso Cliente

44
Documentación de Casos de Uso
Tabla 3 Documentación de Casos de Uso
CU_Código CU-001 Nombre Iniciar Sesión

Autor Jean Paul Espinosa Ortiz, Andrés Fecha 13/03/2022 Versión 1.0
Murcia Muñoz, John Jairo
Preciado, Obed Bermúdez Jaimes
Actores: Todos los Usuarios
Descripción: El sistema debe permitir al usuario el ingreso del sistema
Precondición: 1. El usuario debe haber iniciado sesión
PostCondición:
Flujo Normal
Actor Usuario Actor Sistema
1. El usuario accede al aplicativo web. 2. El sistema muestra el formulario con los

respectivos datos (usuario y contraseña).
3. El usuario ingresa los datos correspondientes. 4. El sistema valida los datos enviados por el
usuario, los compara en la base de datos y
envía al usuario al menú del sistema
correspondiente.
Flujo Alternativo
Actor Actor Sistema
3.1 El usuario ingresa datos erróneos. 4.1 El sistema no encuentra datos acordes con
los enviados por el usuario en la base de datos
y vuelve al paso 2.
3.2 El usuario deja los campos en blanco. 4.2 El sistema le solicita al usuario llenar los
campos y vuelve al paso 2.
Excepciones E-1 Usuario invalido.

E-2 Información incompleta.
45
CU_Código CU-002 Nombre Registrar cliente

Descripción: El sistema debe permitir a un administrador registrar clientes.
El sistema debe permitir a un cliente registrarse a sí mismo.
PostCondición: 1. Se registra el cliente en la base de datos.

2. El sistema vuelve al inicio de sesión.
Flujo Normal
1. El usuario accede al aplicativo web. 2. El sistema muestra el formulario con los

respectivos datos (usuario y contraseña).
3. El usuario selecciona la opción “Registrarme”. 4. El sistema se redirige a un formulario para la

creación de un nuevo usuario
5. El usuario diligencia el formulario y da clic en 6. El sistema valida y crea el cliente donde

“Registrar”. muestra un mensaje “se registró correctamente
el usuario” y guarda los datos en la base de
datos.
Flujo Alternativo
Actor Actor Sistema
6.1 El sistema encuentra un registro de cliente

con los mismos datos enviados por el usuario y
vuelve al paso 4.
4.2 El sistema hace enterar mediante un aviso al

5.1 El usuario ingresa datos erróneos. usuario que no se pudo realizar la inserción y
vuelve al paso 6.
4.3 El sistema da la opción al usuario de

5.2 El usuario deja los campos en blanco. reingresar los datos.
46
Excepciones E-1 Usuario invalido.

CU_Código CU-003 Nombre Modificar Cliente

Descripción: El sistema debe permitir a un administrador modificar la información de los clientes
a excepción de la clave.
El sistema debe permitir a un cliente modificar sus datos personales.
Precondición: 1. El usuario debe estar previamente logueado.
2. El cliente debe estar registrado en el sistema.
PostCondición: 1. El sistema actualiza los datos del cliente.
2. El sistema vuelve a la información personal del cliente.
Flujo Normal
1. El usuario selecciona la opción “Clientes” (El 2. El sistema muestra una lista general de los
usuario cliente se redirecciona a “Información clientes (para el usuario cliente solo muestra
Personal”). su información personal).
3. El usuario selecciona “Editar información”. 4. El sistema abre un formulario con los datos
previamente vistos.
5. El usuario ingresa los datos del cliente y da clic en 8. El sistema valida y actualiza la información
actualizar. del cliente donde muestra un mensaje “se
actualizó correctamente la información” y
guarda los datos en la base de datos.
Flujo Alternativo
Actor Actor Sistema
y vuelve al paso 4.
47
Excepciones E-1 Datos inválidos.

CU_Código CU-004 Nombre Inhabilitar Cliente

Actores: Administrador
Descripción: El sistema debe permitir a un administrador inhabilitar a un cliente.
Precondición: 1. El administrador debe estar previamente logueado.
2. El usuario cliente debe estar habilitado
PostCondición: 1. El sistema inhabilita el usuario del cliente.
2. El sistema prohíbe al cliente inhabilitado entrar al sistema.
3. El sistema vuelve a la lista de clientes.
Flujo Normal
1. El usuario selecciona la opción “Clientes”. 2. El sistema muestra una lista general de los
clientes.
3. El usuario selecciona “Inhabilitar Cliente”. 4. El sistema, antes de realizar la acción de

inhabilitar, pide confirmar al usuario la acción
mediante un aviso.
5. El usuario confirma la acción presionando la opción 6. El sistema inhabilita el estado del cliente en
“Aceptar”. la base de datos y hace enterar al usuario.
Flujo Alternativo
Actor Actor Sistema
5.1 El usuario cancela la acción de inhabilitar cliente 6.1 El sistema no realiza ningún cambio y
presionando la opción “Volver”. vuelve al paso 2.
48
Excepciones
CU_Código CU-005 Nombre Consultar cliente

Descripción: El sistema debe permitir a un administrador consultar los datos de los clientes.
El sistema debe permitir a un cliente consultar sus propios datos.

PostCondición:
Flujo Normal
1. El usuario selecciona la opción “Clientes” (el 2. El sistema muestra una lista general de los
usuario cliente se redirecciona a “Información usuarios clientes (para el usuario cliente solo
Personal”) se muestra su información personal).
4. El sistema realiza una lista de coincidencias

3. El usuario busca mediante un filtro los clientes y muestra la información de los clientes.
registrados en el sistema.
Flujo Alternativo
Actor Actor Sistema
3.1 El usuario ingresa datos inexistentes. 4.1 El sistema no encuentra registros de

acuerdo con los filtros ingresados y le notifica
al usuario mediante un mensaje.
Excepciones
CU_Código CU-006 Nombre Registrar Familiar

49

Descripción: El sistema debe permitir a un administrador o cliente registrar los datos de los
familiares del cliente.
PostCondición: 1. Se registra el familiar en la base de datos.

2. El sistema vuelve a la lista de familiares.
Flujo Normal
1. El usuario selecciona la opción “Familiares”. 2. El sistema muestra una lista general de

todos los familiares.
3. El usuario selecciona “Agregar Familiar” 4. El sistema abre un formulario.
5. El usuario diligencia el formulario y da clic en 6. El sistema valida y crea el familiar donde

el familiar” y guarda los datos en la base de
datos.
Flujo Alternativo
Actor Actor Sistema
6.1 El sistema encuentra un registro de un

familiar con los mismos datos enviados por el
usuario y vuelve al paso 4.
5.2 El usuario digita erróneamente los campos. 6.2 El sistema hace enterar mediante un aviso
al usuario que no se pudo realizar la inserción
y vuelve al paso 4.
5.3 El usuario deja los campos en blanco. 6.3 El sistema da la opción al usuario de
reingresar los datos.
Excepciones E-1 Familiar existente.

E-2 Datos inválidos.
E-3 Datos incompletos.
50
CU_Código CU-007 Nombre Modificar Datos del Familiar

Descripción: El sistema debe permitir a un administrador o cliente modificar los datos de los
2. El usuario debe tener registros del familiar
PostCondición: 1. El sistema actualiza los datos del familiar.
2. El sistema vuelve a la información personal del cliente.
Flujo Normal
1. El usuario selecciona la opción “Familiares”. 2. El sistema muestra una lista general de los
3. El usuario selecciona “Editar información”.
4. El sistema abre un formulario con los datos
previamente vistos.
5. El usuario ingresa los datos del familiar y da clic en 8. El sistema valida y actualiza la información
actualizar. del cliente donde muestra un mensaje “se
actualizó correctamente la información” y
Flujo Alternativo
Actor Actor Sistema
y vuelve al paso 4.

CU_Código CU-008 Nombre Eliminar Familiar

51

Descripción: El sistema debe permitir a un administrador o cliente eliminar los datos de los
Precondición: 1. El usuario debe estar previamente logueado.
PostCondición:
Flujo Normal
1. El usuario selecciona la opción “Familiares”. 2. El sistema muestra una ventana con la

información general de todos los familiares.
3. El usuario busca mediante un filtro el familiar que 4. El sistema, antes de realizar la acción de
desee eliminar y selecciona la opción “eliminar”. eliminar, pide confirmar al usuario la acción
mediante un aviso.
5. El usuario confirma la acción presionando la opción 6. El sistema elimina el familiar en la base de

“Aceptar”. datos y hace enterar al usuario.
Flujo Alternativo
Actor Actor Sistema
5.1 El usuario cancela la acción de eliminar familiar 6.1 El sistema no realiza ningún cambio y
Excepciones
CU_Código CU-009 Nombre Consultar Familiar

Descripción: El sistema debe permitir a un administrador o cliente consultar los datos de los
52
PostCondición:
Flujo Normal
1. El usuario selecciona la opción “Familiares”. 2. El sistema muestra una lista general de los
familiares.
3. El usuario busca mediante un filtro los familiares 4. El sistema realiza una lista de coincidencias
registrados en el sistema. y muestra la información de los clientes.
Flujo Alternativo
Actor Actor Sistema

Excepciones
CU_Código CU-010 Nombre Registrar Condición de Salud

Descripción: El sistema debe permitir a un administrador o cliente registrar una condición de
salud.
PostCondición: 1. Se registra el cliente en la base de datos.

2. El sistema vuelve a la lista de condiciones de salud del cliente.
Flujo Normal
53
1. El usuario selecciona la opción “Condición”. 2. El sistema muestra una lista general de

todas las condiciones de salud del cliente.
3. El usuario selecciona “Agregar Condición” 4. El sistema abre un formulario.
5. El usuario diligencia el formulario y da clic en 6. El sistema valida y crea el familiar donde

la condición” y guarda los datos en la base de
datos.
Flujo Alternativo
Actor Actor Sistema
6.1 El sistema encuentra un registro de una

condición con los mismos datos enviados por
el usuario y vuelve al paso 4.
y vuelve al paso 4.
Excepciones E-1 Condición existente.

CU_Código CU-011 Nombre Modificar Condición Salud

Descripción: El sistema debe permitir a un administrador o cliente modificar una condición de
salud.
2. El usuario debe tener registros de la condición de salud
PostCondición: 1. El sistema actualiza los datos de la condición de salud.
2. El sistema vuelve a la información de la condición de salud del cliente.
Flujo Normal
54
1. El usuario selecciona la opción “Condición”. 2. El sistema muestra una lista general de la

condición de salud de los clientes.
previamente vistos.
5. El usuario ingresa los datos de la condición de 8. El sistema valida y actualiza la información

salud del cliente y da clic en actualizar. de la condición de salud donde muestra un
mensaje “se actualizó correctamente la
información” y guarda los datos en la base de
datos.
Flujo Alternativo
Actor Actor Sistema
y vuelve al paso 4.

CU_Código CU-012 Nombre Inhabilitar Condición de Salud

Actores: Administrador
Descripción: El sistema debe permitir a un administrador inhabilitar una condición de salud.
Precondición: 1. El administrador debe estar previamente logueado.
2. La condición de salud debe estar habilitada
PostCondición: 1. El sistema inhabilita la condición de salud.
2. El sistema la condición de salud no está habilitada para los clientes.
3. El sistema vuelve a la lista de condiciones de salud de los clientes.
Flujo Normal
55
1. El usuario selecciona la opción “Condición”. 2. El sistema muestra una ventana con la

información general de la condición de salud
de los clientes
3. El usuario busca mediante un filtro la condición de 4. El sistema, antes de realizar la acción de

salud que desee inhabilitar y selecciona la opción inhabilitar, pide confirmar al usuario la acción
“inhabilitar”. mediante un aviso.
5. El usuario confirma la acción presionando la opción 6. El sistema inhabilita la condición de salud

“Aceptar”. del cliente en la base de datos y hace enterar
al usuario.
Flujo Alternativo
Actor Actor Sistema
5.1 El usuario cancela la acción de inhabilitar 6.1 El sistema no realiza ningún cambio y
condición presionando la opción “Volver”. vuelve al paso 2.
Excepciones
CU_Código CU-013 Nombre Consultar Condición de Salud

Descripción: El sistema debe permitir a un administrador o un cliente consultar las diferentes
condiciones de salud.
PostCondición:
Flujo Normal
1. El usuario selecciona la opción “Condición”. 2. El sistema muestra una lista general de las
condiciones de salud.
56
3. El usuario busca mediante un filtro las condiciones 3. El sistema realiza una lista de
de salud registradas en el sistema. coincidencias y muestra la información de
la condición de los clientes.
Flujo Alternativo
Actor Actor Sistema

Excepciones
CU_Código CU-014 Nombre Asignar Condición de Salud

Descripción: El sistema debe permitir a un administrador asignar una condición de salud a un
cliente.
El sistema debe permitir a un cliente asignar su condición de salud.
PostCondición: 1. Se asigna la condición de salud al cliente en la base de datos.

2. El sistema vuelve a la lista de condiciones de salud del cliente.
Flujo Normal
1. El usuario selecciona la opción “Condición”. 2. El sistema muestra una ventana con la

información general de la condición de salud
de los clientes
3. El usuario busca mediante un filtro la condición de 4. El sistema, antes de realizar la acción de

salud que desee asignar y selecciona la opción asignar, pide confirmar al usuario la acción
“asignar”. mediante un aviso.
5. El usuario confirma la acción presionando la opción 6. El sistema asigna la condición de salud al

“Aceptar”. cliente en la base de datos y hace enterar al
57
usuario.
Flujo Alternativo
Actor Actor Sistema
5.1 El usuario cancela la acción de asignar condición 6.1 El sistema no realiza ningún cambio y
Excepciones
CU_Código CU-015 Nombre Registrar Resultados de

Exámenes
Descripción: El sistema debe permitir a un administrador o cliente registrar un examen de
laboratorio.
PostCondición: 1. Se registra el resultado del examen de laboratorio en la base de datos.

2. El sistema vuelve a la lista de familiares.
Flujo Normal
1. El usuario selecciona la opción “Exámenes”. 2. El sistema muestra una lista general de

todos los resultados de los exámenes de
laboratorio.
3. El usuario selecciona “Agregar Examen” 4. El sistema abre un formulario.
5. El usuario diligencia el formulario y da clic en 6. El sistema valida y crea el resultado del

“Registrar”. examen de laboratorio del cliente donde
muestra un mensaje “se registró correctamente
el examen de laboratorio” y guarda los datos
58
Flujo Alternativo
Actor Actor Sistema
y vuelve al paso 4.

CU_Código CU-016 Nombre Modificar Resultado Examen

Descripción: El sistema debe permitir a un administrador o cliente modificar una condición de
salud.
2. El usuario debe tener registros del resultado del examen de laboratorio
PostCondición: 1. El sistema actualiza los datos del resultado del examen de laboratorio.
2. El sistema vuelve a la información los resultados de los exámenes de laboratorio
del cliente.
Flujo Normal
1. El usuario selecciona la opción “Exámenes”. 2. El sistema muestra una lista general de los
previamente vistos.
5. El usuario ingresa los datos del resultado del 8. El sistema valida y actualiza la información
examen de laboratorio del cliente y da clic en del resultado del examen de laboratorio donde
actualizar. muestra un mensaje “se actualizó
correctamente la información” y guarda los
datos en la base de datos.
59
Flujo Alternativo
Actor Actor Sistema
y vuelve al paso 4.

CU_Código CU-017 Nombre Consultar Resultado Examen

Descripción: El sistema debe permitir a un administrador consultar los resultados de los
El sistema debe permitir al cliente consultar sus resultados de exámenes de
laboratorio.
PostCondición:
Flujo Normal
1. El usuario selecciona la opción “Exámenes”. 2. El sistema muestra una lista general de los
resultados de los exámenes de laboratorio.
3. El usuario busca mediante un filtro los resultados 4. El sistema realiza una lista de
de exámenes registrados en el sistema. coincidencias y muestra la información de
los resultados de los exámenes de
laboratorio de los clientes.
Flujo Alternativo
Actor Actor Sistema
60

Excepciones
CU_Código CU-018 Nombre Gestionar Indicadores de Salud

Descripción: El sistema debe permitir a un administrador registrar, modificar o consultar
indicadores de salud de los clientes.
El sistema debe permitir al cliente registrar, modificar o consultar sus indicadores de
salud.
PostCondición: 1. Se almacena la información en la base de datos.

2. El sistema vuelve a la lista de indicadores de salud.
Flujo Normal
1. El usuario selecciona la opción “Indicadores”. 2. El sistema muestra una lista general de

todos los indicadores de salud del cliente.
3.1 El usuario selecciona “Agregar Indicador” 4.1 El sistema abre un formulario.
3.2 El usuario selecciona “Editar Información” 4.2 El sistema abre un formulario con los datos
previamente vistos.
5.1 El usuario diligencia el formulario y da clic en 6.1 El sistema valida y crea el indicador donde
el indicador” y guarda los datos en la base de
datos.
5.2 El usuario diligencia el formulario y da clic en 6.2 El sistema valida y actualiza el indicador
“Actualizar”. donde muestra el mensaje “se actualizó
correctamente el indicador” y guarda los datos
61
Flujo Alternativo
Actor Actor Sistema
6.1.1 El sistema encuentra un registro de un

indicador con los mismos datos enviados por el
usuario y vuelve al paso 4.1.
5.2.1 El usuario digita erróneamente los campos. 6.2.1 El sistema hace enterar mediante un
aviso al usuario que no se pudo realizar la
inserción y vuelve al paso 4.1.
actualización y vuelve al paso 4.2.
Excepciones E-1 Indicador existente.

CU_Código CU-019 Nombre Gestionar Control Profesional

Descripción: El sistema debe permitir a un administrador registrar, modificar o consultar el control
profesional de los clientes.
El sistema debe permitir al cliente registrar, modificar o consultar sus controles
profesionales.

2. El sistema vuelve a la lista de controles profesionales.
Flujo Normal
62
1. El usuario selecciona la opción “Control”. 2. El sistema muestra una lista general de

todos los controles profesionales del cliente.
3.1 El usuario selecciona “Agregar Control” 4.1 El sistema abre un formulario.
previamente vistos.
5.1 El usuario diligencia el formulario y da clic en 6.1 El sistema valida y crea el control donde
el control” y guarda los datos en la base de
datos.
5.2 El usuario diligencia el formulario y da clic en 6.2 El sistema valida y actualiza el indicador
“Actualizar”. donde muestra el mensaje “se actualizó
correctamente el control” y guarda los datos en
la base de datos.
Flujo Alternativo
Actor Actor Sistema
6.1.1 El sistema encuentra un registro de un

control profesional con los mismos datos
enviados por el usuario y vuelve al paso 4.1.
Excepciones E-1 Control existente.

CU_Código CU-020 Nombre Gestionar Seguimientos

63

Descripción: El sistema debe permitir a un administrador registrar, modificar o consultar los
seguimientos de los clientes.
El sistema debe permitir al cliente registrar, modificar o consultar sus seguimientos.

2. El sistema vuelve a la lista de seguimientos.
Flujo Normal
1. El usuario selecciona la opción “Seguimientos”. 2. El sistema muestra una lista general de

todos los seguimientos del cliente.
3.1 El usuario selecciona “Agregar Seguimiento” 4.1 El sistema abre un formulario.
previamente vistos.
5.1 El usuario diligencia el formulario y da clic en 6.1 El sistema valida y crea el seguimiento del
“Registrar”. cliente donde muestra el mensaje “se registró
correctamente el seguimiento” y guarda los
datos en la base de datos.
5.2 El usuario diligencia el formulario y da clic en 6.2 El sistema valida y actualiza el seguimiento
“Actualizar”. del cliente donde muestra el mensaje “se
actualizó correctamente el seguimiento” y
Flujo Alternativo
Actor Actor Sistema
64

CU_Código CU-021 Nombre Generar Reportes

Descripción: El sistema debe permitir a un administrador o cliente generar un reporte
correspondiente a resultados de exámenes de laboratorio, indicadores de salud,
seguimientos a condiciones e información general de los clientes. El cliente solo
puede ver información personal y no ajena.
PostCondición: 1. Genera un reporte de la información filtrada.
Flujo Normal
1. El usuario selecciona la opción “Reportes”. 2. El sistema despliega unos submódulos
3. El usuario selecciona el submódulo de preferencia 4. El sistema muestra una lista general de los
(seguimientos, indicadores de salud, controles resultados del submódulo seleccionado.
profesionales, etc).
5. El usuario busca mediante un filtro los resultados 6. El sistema realiza una lista de coincidencias
del submódulo con los datos registrados en el y muestra la información de los resultados
sistema.
7. El usuario genera el reporte con los datos filtrados. 8. El sistema genera un reporte según el
formato seleccionado por el usuario (CSV,
PDF, Excel, Word, etc.).
Flujo Alternativo
Actor Actor Sistema
65

Excepciones
CU_Código CU-022 Nombre Cerrar Sesión

Descripción: El sistema debe permitirá todos los usuarios cerrar la sesión.
PostCondición:
Flujo Normal
2. El sistema redirige al usuario a la página del

Login.
Flujo Alternativo
Actor Actor Sistema
Excepciones
66
Mockup
Requerimiento 1
Requerimiento 2
67
Requerimiento 3
Requerimiento 4
Requerimiento 5
68
Requerimiento 6
Requerimiento 7
69
Requerimiento 8
Requerimiento 9
70
Requerimiento 10
Requerimiento 11
71
Requerimiento 12
Requerimiento 13
72
Requerimiento 14
Requerimiento 15
73
Requerimiento 16
74
Requerimiento 17
75
Requerimiento 18
76
Requerimiento 19
Requerimiento 20
77
Requerimiento 21
78
Requerimiento 22
79
80
Diagrama de Clases
Figura 5 Diagrama de Clase

81
Bibliografía
atlassian. (s.f.). Scrum. Obtenido de Aprende a utilizar scrum con lo mejor de él:
https://www.atlassian.com/es/agile/scrum
Carreño, E. (29 de Septiembre de 2014). Slideshare. Obtenido de
https://es.slideshare.net/edithcarreno33/modelos-de-software-39682893
Deloitte. (2022). Obtenido de https://www2.deloitte.com/es/es/pages/technology/articles/roles-y-
responsabilidades-scrum.html
Huambachano, J. F. (25 de septiembre de 2017). scrum. Obtenido de ¿Qué es Scrum?:
https://www.scrum.org/resources/blog/que-es-scrum
Sutherland, K. S. (julio de 2016). scrumguides. Obtenido de
https://scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-
Spanish.pdf#zoom=100

Esc 2 Modelo de Proceso de Desarrollo de Software Tradicionales

Cargado por

Información del documento

Descripción original:

Título original

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

Esc 2 Modelo de Proceso de Desarrollo de Software Tradicionales

Cargado por

Copyright:

Formatos disponibles

“Sistema De Información Para La Gestión De La Salud”

Jean Paul Espinosa Ortiz – CC 1000860009

Andrés Murcia Muñoz - CC 1073322672

John Jairo Preciado – CC 70253364

Obed Bermúdez Jaimes – CC 1007690480

Institución Universitaria Politécnico Grancolombiano

Planteamiento del Problema............................................................................................8

Descripción del Problema.............................................................................................8

Modelo de Procesos Seleccionado (Modelo en Espiral).............................................13

Modelo de Procesos Descartados..............................................................................13

Modelo de Procesos Incremental............................................................................14

Modelo de Procesos por Prototipos........................................................................14

Modelo de Procesos Evolutivo................................................................................15

Modelo de Procesos Lineal.....................................................................................15

Graph Release burn-down......................................................................................17

Graph Sprint burn-down..........................................................................................18

Impediments backlog e incidence backlog (IB).......................................................18

Requisitos Funcionales y No Funcionales......................................................................21

Diagramas y Documentación de Casos de Uso.............................................................41

Diagrama de Casos de Uso........................................................................................41

Documentación de Casos de Uso..............................................................................43

Tabla 1 Requisitos Funcionales (RF).............................................................................21

Tabla 2 Requisitos No Funcionales................................................................................39

Tabla 3 Documentación de Casos de Uso.....................................................................44

Figura 2 Caso de Uso del Sistema.................................................................................40

Figura 3 Caso de Uso Administrador.............................................................................41

Figura 4 Caso de Uso Cliente........................................................................................41

Figura 5 Diagrama de Clase..........................................................................................65

Las TICs ofrecen muchos beneficios que contribuyen al mejoramiento de la calidad de

satisfacer las necesidades del Cliente.

necesidad, se creará el software llamado “Sistema de Información para la Gestión de la

Salud” un software que ofrecerá al usuario la posibilidad de llevar diversos controles de su

Este software contara con fiabilidad, eficiencia, y facilidad de mantenimiento y será de

Planteamiento del Problema

Descripción del Problema

El cliente actualmente no cuenta con la posibilidad de consultar la información de su

además de una perdida grande de tiempo en la solicitud de alguna cita.

¿Un sistema de información puede mejorar los procesos en la consulta de estados de

salud para el cliente y su familia basándose en exámenes y seguimientos de condiciones de

El sistema de información a desarrollar será un programa que pretende que todas

aquellas personas que consultan periódicamente al médico cuenten con un instrumento de

marcha su estado de salud.

 Una descripción breve y clara sobre lo consultado.

resultado de ciertos datos de salud, como: signos vitales, paraclínicos (hemogramas,

ionogramas, parcial de orina, glicemia, entre otros).

tranquilidad al usuario, ya que le permitirá al usuario, tener una idea de cómo va su

interpretación de exámenes de laboratorio, glucometrías, signos vitales, entre otros.

Modelo de Procesos Seleccionado (Modelo en Espiral)

El “Sistema de Información para la Gestión de la Salud” es un proyecto pequeño,

con las expectativas que el Cliente esperaba.

Modelo de Procesos Descartados

Se descarta el modelo en cascada debido a ser un modelo de procesos bastante

es grande, generando así sobrecostos e inconformidades con el cliente.

Modelo de Procesos Incremental

A pesar de que se puedan acortar lo tiempos de entrega y permite el retorno de

técnica. Además, el cliente no se encuentra constantemente disponible para mostrar los

avances del proyecto.

Modelo de Procesos por Prototipos

El modelo de procesos por prototipos pese a tener la opción de desarrollar prototipos

funcionales del producto.

Modelo de Procesos Evolutivo

Al igual que el modelo de procesos por prototipos el modelo de procesos evolutivo