APLICACIÓN MÓVIL PARA LA CLASIFICACIÓN DE PACIENTES A TRAVÉS

DEL PROCESO DE TRIAGE EN EL HOSPITAL EDUARDO ARREDONDO DAZA

SANDRA SAENZ
JORGE TORRES

MARIBEL ROMERO
GESTIÓN DE PROYECTOS TI

UNIVERSIDAD POPULAR DEL CESAR

UPC
VALLEDUPAR
CESAR
2018-2
 PROYECTO DE GESTION DE PROYECTOS DE TI

I. RESUMEN EJECUTIVO

I.1. Empresa o ámbito sobre la cual desarrollarán el proyecto

Hospital Eduardo Arredondo Daza

I.2. Nombre del proyecto

Aplicación móvil para la clasificación de pacientes a través del proceso
de triage en el hospital Eduardo Arredondo Daza

I.3. Descripción de alto nivel del proyecto

En este proyecto se desarrollará una aplicación móvil la cual clasificará
a los pacientes en una de las cinco categorías existentes en el proceso
de triage hospitalario. Cumplirá con la necesidad de realizar la gestión
de pacientes, enfermeras, síntomas, reportes y se mostrará la
clasificación del paciente.

En el registro de síntomas se realiza un listado de todos los síntomas y

dolencias que presente el paciente en la valoración para su clasificación
en cuanto al tiempo de espera para su tratamiento. Estos síntomas se
clasifican en:

Nivel I: Reanimación, la cual su tiempo de atención es de forma

inmediata. La condición clínica del paciente representa un riesgo vital y
necesita maniobras de reanimación por su compromiso ventilatorio,
respiratorio, hemodinámico o neurológico, perdida de miembro u órgano
u otras condiciones que por norma exijan atención inmediata.

Nivel II: Emergencia, la condición clínica del paciente puede

evolucionar hacia un rápido deterioro o a su muerte, o incrementar el
riesgo para la pérdida de un miembro u órgano, por lo tanto, requiere
una atención que no debe superar los treinta (30) minutos.

Nivel III: Urgencia, la condición clínica del paciente requiere de

medidas diagnósticas y terapéuticas en urgencias. Son aquellos
pacientes que necesitan un examen complementario o un tratamiento
rápido, dado que se encuentran estables desde el punto de vista
fisiológico, aunque su situación puede empeorar si no se actúa en (1)
hora.

Nivel IV: Urgencia menor, el paciente presenta condiciones médicas

que no comprometen su estado general, ni representan un riesgo
evidente para la vida o pérdida de miembro u órgano. No obstante,
existen riesgos de complicación o secuelas de la enfermedad o lesión si
 no recibe la atención correspondiente, máximo (2) horas para la
atención.

Nivel V: Sin urgencia, el paciente presenta una condición clínica

relacionada con problemas agudos o crónicos sin evidencia de deterioro
que comprometa el estado general de paciente y no representa un
riesgo evidente para la vida o la funcionalidad de miembro u órgano, un
máximo de (4) horas para ser atendido en urgencias.

I.4. Contexto y problemática existente, en esta parte se debe:

 Identificar el problema
El hospital Eduardo Arredondo daza en urgencias suele aplicarse la
metodología del que primero ingresa al centro hospitalario es el primero
al ser atendido, esto ocasiona congestión y largas filas de espera
principalmente en accidentes múltiples, y esto con lleva que el paciente
se complique y se ponga en riesgo la vida de este; debido a que no se
tiene un orden al momento de determinar la urgencia, simplemente
cuando ya pasa a ser diagnosticado es cuando se llena un formato con
sus datos motivos de la urgencia y se determina en qué nivel de
clasificación esta.

 Examinar los efectos del problema

Con mucha frecuencia el personal médico del servicio de urgencias se
enfrenta al dilema de qué tan rápido debe atenderse una urgencia real
de una sentida. Conocer el sistema de evaluación llamado “triage” y
aplicarlo correctamente puede establecer la diferencia entre una
urgencia y una verdadera emergencia.
Este proyecto se realizará para dar una mejora a la atención al paciente,
mejor organización en las historias clínicas de los pacientes, mayor
facilidad a la enfermera de turno al clasificar la gravedad del paciente.

 Identificar las posibles causas del problema

Al no realizar la aplicación el problema de congestión, mal manejo de la
clasificación de triage llevara a que los pacientes sigan mal sin un
proceso previo para saber su gravedad, también al hacer la clasificación
con solo el saber de la enfermera lleva a equivocaciones que pueden
llevar al paciente a empeorar o a la muerte.

 Definir los objetivos para la solución

General:
I.4.1. Desarrollar una aplicación móvil para la clasificación de
pacientes a través del proceso de triage en el hospital
Eduardo Arredondo Daza.
 Especifico:
I.4.2. Recopilar información sobre el procedimiento triage
realizado actualmente para la asignación de prioridades en
los pacientes que llegan a urgencias.
I.4.3. Analizar la información obtenida para saber los módulos
a desarrollar.
I.4.4. Diseñar la base de datos para el almacenamiento de los
módulos de la aplicación.
I.4.5. Diseñar el software con los módulos pertinentes para la
aplicación móvil.
I.4.6. Desarrollar la base de datos para el almacenamiento de
los módulos de la aplicación.
I.4.7. Desarrollar los módulos pacientes, síntomas,
enfermera, prioridad y reportes.

 Formular acciones para solucionar el problema

Crear una aplicación para que las enfermeras, cuando se presente un
paciente tomen sus datos personales, síntomas que presenta y se le
dará a conocer el nivel de clasificación y el tiempo de espera máximo
para ser atendido.
Por otro lado, el administrador podrá tener la capacidad de ingresar los
nombres de los síntomas con su nivel de prioridad y mirar los reportes
de la aplicación.

 Configurar alternativas viables y pertinentes

Las enfermeras que atienden a los pacientes deben poder reconocer
más fácilmente los niveles de clasificación del triage y los síntomas
asociados a ellos para poder dar un mejor entendimiento al paciente de
los que tiene y lo que puede esperar.

I.5. Justificación
Con mucha frecuencia el personal médico del servicio de urgencias se
enfrenta al dilema de qué tan rápido debe atenderse una urgencia real
de una sentida. Conocer el sistema de evaluación llamado “triage” y
aplicarlo correctamente puede establecer la diferencia entre una
urgencia y una verdadera emergencia.

Se deben memorizar ambos conceptos ya que, a pesar de ser similares,

se diferencian en el grado de urgencia vital, es decir, en el daño que
puede causar a la vida y la función.

La urgencia es un problema que independientemente de la causa y de la

gravedad, va a necesitar una atención médica. Pero debido a que su
 evolución es lenta y no siempre mortal su atención no requiere
necesariamente que sea inmediata. Sin embargo, durante la vigilancia
periódica no debe extenderse a más de 6 horas.

La emergencia es, en cambio, toda situación en la que esté en peligro la

vida del paciente o de alguno de sus órganos. En este caso la atención
debe ser inmediata, sin tardarse más de 1 hora. Después de este tiempo
el riesgo de complicaciones mortales se dispara de manera
significativa.” (Rivas M. Manual de Urgencias. 3ra edición. Editorial
Panamericana, Madrid 2013).

Este proceso permite unir la medicina y la ingeniería de sistemas puesto

que facilita la automatización del procedimiento triage, que permite
capturar los datos de los pacientes y acceder a la información de una
forma eficiente y eficaz.

Este proyecto se realizará para dar una mejora a la atención al paciente,

mejor organización en las historias clínicas de los pacientes, mayor
facilidad a la enfermera de turno al clasificar la gravedad del paciente.

Las ventajas que para el hospital genera sistematizar el triage son

muchas ya que con la sistematización del proceso puede eliminar todas
las falencias que tienen como muy lento el proceso, la congestión en la
sala, los pacientes no tendrían que esperar mucho tiempo,
implementando esta aplicación tendrían un sistema que les permita un
registro de enfermeras las cuales con un usuario y contraseña
ingresaran al aplicativo, registrar los datos de los pacientes que ingresan
a urgencias, tener un listado de síntomas para escoger cual(es) tiene el
paciente para que el aplicativo los verifique y muestre cual es la
clasificación dentro del triage y el tiempo en que más o menos tardarían
en atender al paciente todo esto de una manera rápida y eficaz en
tiempo real.

I.6. Identificación de proyectos similares

• INTERNACIONAL
Título: SATS mobile triage
Autor: The Open Medicine Project

Para ayudar a las enfermeras a realizar correctamente los cálculos de

triage, The Open Medicine Project ha trabajado con varias instituciones
y expertos para desarrollar una aplicación móvil que permita a las
enfermeras realizar con precisión y eficiencia la escala de Triage de
Sudáfrica. El sistema está diseñado de manera muy sencilla y hace que
los pacientes de triage sean increíblemente fáciles. Sus módulos son
 signos de emergencia, clasificación, condiciones, procedimientos, centro
de salud.

• NACIONAL
Título: TAPPi: triage aplicación
Autor: Luisa Álvarez Valencia Andrés Pinedo Gutiérrez Paula Alejandra
Rocha Sabogal

Este proyecto fue desarrollado por estudiantes de la Universidad

javeriana, tiene como finalidad optimizar el proceso de Triage es la
técnica empleada para priorizar los pacientes que ingresan a la sala de
urgencias. Estas clasificaciones están basadas en revisar los signos
vitales, la escala de dolor y otros índices para realizar dicha priorización.
Las mediciones permiten identificar rápidamente los pacientes en
situación de riesgo vital y asegurar la priorización otorgando a los
pacientes un tiempo de espera máximo, sin embargo, esta situación no
se ve reflejada en la realidad nacional. Los módulos que presenta son
los siguientes: Ingresar síntomas, números de emergencia, cuentas,
historial.

I.7. Recursos requeridos

 Personal de trabajo
 Base de datos
 Servidor
 Computador
 Programas para realizar el software
 Dispositivo Android

II. FASE DE INICIO

II.1. Acta de constitución del proyecto

Título del proyecto

Aplicación móvil para la clasificación de pacientes a través del proceso de

triage en el hospital Eduardo Arredondo daza

Descripción del producto del proyecto

En el proyecto se desarrollará una Aplicación móvil para la clasificación de

pacientes a través del proceso de triage en el hospital Eduardo Arredondo
daza que cumplirá con la necesidad que presenta el proceso de triage para
optimizar el tiempo de atención de los pacientes en urgencia con máxima
seguridad en la decisión.

Sabemos que, en los servicios de Urgencias, la atención del paciente en el

tiempo adecuado es clave. La aplicación móvil en proceso de triage
permitirá la clasificación y priorización de pacientes en el servicio de
Urgencias en el menor tiempo posible de acuerdo a su clasificación.

Mejorará la coordinación del equipo clínico con la ayuda de un método

basado en la priorización de pacientes y organiza los recursos del hospital
en base a la demanda real del servicio.

La ampliación móvil en el proceso de triage, nos permite ubicar

adecuadamente a los pacientes en la Unidad correspondiente.

La aplicación contara con el registro de los datos del cliente. Contará con
los módulos de paciente, síntomas, usuario, reportes.

Con los siguientes elementos:

 Aplicación móvil ágil y fácil de usar

 Aplicación móvil que se puedan utilizar en dispositivos de diferentes
tamaños.
 Clasificación de paciente dependiendo la gravedad

Los principales entregables son:

 Descripción resumida del sistema y sus características.

 Buscar los requisitos
 Especificación del sistema
 Diseño de diagramas del sistema
 Diagramas de los programas.
 Documentos del diseño final del sistema y de cada programa.
 Plan de pruebas del sistema.
 Reporte de los resultados de las pruebas.
 Plan de contingencia a caídas del sistema y recuperación por medio
de la base de datos.

Restricciones del Proyecto

La aplicación móvil de este proyecto se terminará cuando se cumplan
con las siguientes condiciones:
 Una vez la aplicación web se encuentre funcionando en línea,
habiéndose cumplido con todos los objetivos propuesto dentro de
alcance de proyecto.
 Garantía: Cualquier servicio dentro del proyecto presentado
en la propuesta, garantiza que los trabajos serán realizados
de una manera correcta y con las descripciones en este
documento.
 Soporte: Culminado el proyecto y el sistema puesto en
marcha, se explicarán detalladamente a cada miembro de la
empresa, las dudas que se les presente sin ningún costo
durante 15 días hábiles.

II.2. Organización del proyecto (Estructura, descripción y responsabilidades)

NOMBRE CARGO RESPONSABILIDAD

José Brito Jefe del hospital Director del hospital
Carlos Paredes gerente del proyecto Dirige el proyecto
Encargado de la fase
Analista
Graciela Garcés de análisis
Encargado de la fase
Diseñador
Marcela cuadrados de diseño
Encargado de la BD del
Administrador de BD
Juan Saucedo proyecto
Encargado de la fase
desarrollador
Mario Pérez de desarrollo
Encargado de las
Tester
Javier Trujillo pruebas del software
Encargado de instalar
Instalador el software en las
Daniel Romero plataformas necesarias
Encargado del
Mantenimiento mantenimiento después
Santiago Araque de la instalación
Luz Marina Díaz CIO
Área de recursos
Plantilla de personal
Carolina molina humano
Cesar Caicedo Área financiera Nomina
Información sobre el
Asesora de salud proceso de triage y el
María torres hospital
Interesado en el
patrocinador proyecto y dará la
Lorena Suarez financiación
II.3. Enunciado de alto nivel del alcance del proyecto
Se desarrollará una aplicación móvil para la clasificación de pacientes a
través del proceso de triage en el Hospital Eduardo Arredondo Daza, el
cual constará con la gestión de los módulos necesarios para la
aplicación móvil: paciente, usuario, síntomas, reportes.

Lo que los módulos de la aplicación móvil realizaran:

• Análisis de procesos.
• Instalación y configuración de la aplicación.
• Diseño de aplicación móvil
• Configuración del proceso de triage de acuerdo con la necesidad del
hospital.
• Registro de datos de (nombre del paciente, enfermera de turno,
descripción de síntomas, clasificación, nivel de urgencia).

II.4. Definición de los objetivos del proyecto (Principal y específicos)

Objetivo General

Desarrollar una Aplicación móvil para la clasificación de pacientes a

través del proceso de triage en el hospital Eduardo Arredondo daza

Objetivos Específicos

 Recopilar información sobre el procedimiento triage realizado

actualmente para la asignación de prioridades en los pacientes que
llegan a urgencias.
 Analizar la información obtenida para saber los módulos a
desarrollar.
 Diseñar la base de datos para el almacenamiento de los módulos
de la aplicación.
 Diseñar el software con los módulos pertinentes para la aplicación
móvil.
 Desarrollar la base de datos para el almacenamiento de los
módulos de la aplicación.
 Desarrollar los módulos pacientes, síntomas, enfermera, prioridad
y reportes.

II.5. Riesgos iniciales del proyecto

  La interfaz gráfica del sistema de información no es del gusto del cliente.
 La cantidad del personal necesaria para realizar el sistema de
información es limitada.
 El cliente aumenta el requisito del sistema de información.
 Perdida de algún integrante del equipo de trabajo que es clave para el
proyecto.
 Poca experiencia con la tecnología.
 Que no sea del agrado de los usuarios o del gerente.
 Que algún requisito sea paso por alto.
 Oposición comunicativa entre compañeros.

II.6. Análisis de los interesados

 Identificación de los interesados (Internos y externos)

Interesados Internos Interesados Externo

A. Patrocinador / Gerente B. Paciente

C. Jefe Del Área De Triage D. Otros Hospitales
E. Gerente Del Proyecto F. Empresas Desarrolladoras
G. Socios
H. Enfermeros

 Aplicar las Matrices de impacto

 Análisis de los interesados

Interesados Desconocedor(1) Reticente(2) Neutral(3) Partidario(4) Líder(5)

Actual
Líder del proyecto
Deseado
Gerente o
patrocinador Actual Deseado
paciente Actual Deseado
Otras Hospitales No Deseado
Jefe del área de Actual
triage Deseado

 Matriz de análisis de los interesados

II.7. Estudio de viabilidad del proyecto

Viabilidad Técnica
Los recursos necesarios o materiales para el buen funcionamiento de la
aplicación o prestación de servicios en las instalaciones:
• Equipos para desarrollar
• Licencias de software del lenguaje de programación
• Base de datos MySql, los registros e historial de paciente
• Servicios hosting o servidores

Viabilidad operativa
El sistema es necesario por el personal para un manejo más rápido de
la sala de urgencias. Luego de instalarse el sistema debe comenzar a
operar inmediatamente en los dispositivos que tengan descargada la
aplicación. Sistema de fácil manejo para los usuarios, mantenerlo
amigable y comprensible para los operadores

Viabilidad Económica

El proyecto tiene un presupuesto aprobado en la propuesta del Hospital

que son los siguientes:

Descripción Costo
Equipo de Trabajo $ 21’780.000
Gerente 22.000 * 35 h * 6 m $ 4’620.000
Total del presupuesto $ 26.400.000

Todo cambio en el presupuesto deberá ser aprobado previamente por

las dos organizaciones encargadas.

Viabilidad Operacional

Carlos paredes
Responsable del Proyecto verificando las siguientes actividades:
• Validar los entregables del Proyecto y los resultados.
• Asignar la actividad al personal que considere oportuno
• Realizar la disponibilidad de recursos de la organización para el
gerente.
• Comunicar los avances del Proyecto al equipo de trabajo.
• Participar en la planificación del Proyecto, colaborando con el Jefe de
Proyecto
III. FASE DE PLANIFICACION
III.1. Análisis del alcance del proyecto
III.1.1. Enunciado del trabajo del proyecto
 Objetivo del proyecto (que, cuando y cuanto)

Con este proyecto se desarrollará una aplicación móvil para la

clasificación de pacientes a través del proceso de triage en el
Hospital Eduardo Arredondo Daza, el cual constará con la gestión de
los módulos necesarios para la aplicación móvil: paciente, usuario,
síntomas, reportes. El proyecto se debe realizar en un plazo de 6
meses y su costo de ejecución no debe ser superior a 26.400.000
pesos.

 Entregables

 Lista de requisitos
 Especificación del sistema
 Descripción resumida del sistema propuesto y sus
características.
 Diseño de diagramas del sistema
 Diagramas del programa.
 Estándares de programación y diseño de programas
 Documento del diseño final del sistema y de cada programa.
 Desarrollo de la base de datos.
 Desarrollo del software.
 Resultado de las pruebas de cada modulo
 Plan de pruebas del sistema.
 Informe y Reporte de los resultados de las pruebas.
 Manuales del software
 Plan de contingencia a caídas del sistema y recuperación por
medio de la base de datos.
 Plan de revisión para después de la instalación
 Informe de la instalación
 Listado de fallos detectados en el sistema
 Listado de mejoras solicitadas por el usuario
 Documento de revisión final y entrega.

 Fechas importantes (hitos): se espera iniciar el 11 septiembre

  Lista de requisitos 17 septiembre
 Especificación del sistema. 24 septiembre
 Descripción resumida del sistema propuesto y sus
características. 1 octubre
 Diseño de diagramas del sistema. 15 octubre
 Diagramas del programa. 22 octubre
 Estándares de programación y diseño de programas. 29
octubre
 Documento del diseño final del sistema y de cada programa. 5
noviembre
 Desarrollo de la base de datos. 3 diciembre
 Desarrollo del software. 31 diciembre
 Resultado de las pruebas de cada módulo. 7 enero
 Plan de pruebas del sistema. 14 enero
 Informe y Reporte de los resultados de las pruebas. 21 enero
 Manuales del software. 28 enero
 Plan de contingencia a caídas del sistema y recuperación por
medio de la base de datos. 4 febrero
 Plan de revisión para después de la instalación. 11 febrero
 Informe de la instalación. 18 febrero
 Listado de fallos detectados en el sistema. 25 febrero
 Listado de mejoras solicitadas por el usuario. 4 marzo
 Documento de revisión final y entrega. 11 marzo

 Requerimientos técnicos
 Base de datos
 Servidor
 Computador
 Programas para realizar el software
 Dispositivo Android

 Límites y exclusiones

 este proyecto se terminará una vez la aplicación móvil se

encuentre funcionando en línea, habiéndose cumplido con todos
los objetivos propuesto dentro de alcance de proyecto.
 Cualquier servicio dentro del proyecto presentado en la
propuesta, garantiza que los trabajos serán realizados de una
manera correcta y con las descripciones en este documento.
 Culminado el proyecto y el sistema puesto en marcha, se
explicarán detalladamente a cada miembro de la empresa, las
 dudas que se les presente sin ningún costo durante 15 días
hábiles.
 El costo de implementar nuevos requisitos se le cargara al cliente
aparte del monto acordado anteriormente.

III.1.2. Identificación y descripción de los requisitos

- Requisitos funcionales:

numero requerimiento descripción prioridad

La enfermera
El sistema deberá registrar los datos del
RF1 podrá registrar 5
paciente para tener un control de estos
paciente

El sistema deberá registrar a los

La enfermera empleados que usaran el software para
RF2 5
podrá registrarse tener un usuario y contraseña para
ingresar al aplicativo

La enfermera El sistema permitirá el registro de

RF3 podrá registrar síntomas para que el paciente diga sus 4
síntomas dolencias y verificar su clasificación.

El sistema permitirá un listado de los

Tener un listado
RF4 síntomas donde solo seleccionaran los 5
de síntomas
que el paciente tenga.

El sistema después de recoger los datos

Procesar la del paciente y escoger los síntomas
información para presentados por este debe obtener el
RF5 la clasificación y nivel de clasificación del triage en el que 4
almacenar en la se encuentra y almacenar todo esto en
base de datos la base de datos junto con su historial
clínico.

Reportes por El sistema mostrara graficas que

RF6 clasificación de tendrán el progreso de la clasificación 3
triage de Triage ya sea por día o por mes.

- Requisitos no funcionales:
  un PC con memoria y espacio en disco para almacenar la base
de datos.
 Seguridad de los equipos de computo
 Nivel alto de procesamiento de los datos almacenados
 El sistema debe ser fácil de entender para el usuario.
 El sistema debe permitir abrir la sesión.
 El sistema debe permitir cerrar la sesión.
 El sistema deberá tener una gama de colores de medicina.

III.1.3. Definición del alcance del proyecto

La aplicación móvil TRIAGE tiene como objetivo construir un software
para la clasificación de pacientes a través del proceso de triage en el
Hospital Eduardo Arredondo Daza, el cual constará con la gestión de los
módulos necesarios para la aplicación móvil: paciente, usuario,
síntomas, reportes. Lo que los módulos de la aplicación móvil realizaran:
 Análisis de procesos.
 Instalación y configuración de la aplicación.
 Diseño de aplicación móvil
 Configuración del proceso de triage de acuerdo con la necesidad
del hospital.
 Registro de datos de (nombre del paciente, enfermera de turno,
descripción de síntomas, clasificación, nivel de urgencia).

III.1.4. Elaboración del EDT (Estructura de desglose del trabajo)

III.1.5. Diccionario de la EDT

Enunciado Lista de requisitos

Descripción Esta actividad se encarga de recolectar
todas las necesidades a resolver por medio
de la aplicación, con que propiedades o
restricciones determinadas de forma precisa
deba satisfacer la aplicación.
Duración 2 semanas
Responsable Analista del software

Enunciado Especificación del sistema

Descripción Esta actividad consiste en revisar las
especificaciones funcional del sistema en
requerimiento de la entidad hospitalaria
Duración 1 semana
Responsable Analista del software

Enunciado Modelo de caso de uso

Descripción Aquí se diseñan las actividades y procesos
 que se deberán realizar en los diferentes
módulos a desarrollar dentro del sistema.
Duración 1 semana
Responsable Analista

Enunciado Diagrama de clase

Descripción Para describir de manera estática la
estructura de la aplicación, para mostrar sus
atributos, operaciones y relaciones.
Duración 1 semana
Responsable analista

Enunciado Resumen ejecutivo de la empresa

Descripción Se hace una planificación con la empresa y
los beneficios que va obtener, se establecen
las estrategias o pasos para atender a los
pacientes para un mejor servicio.
Duración 1 semana
Responsable Analista de la aplicación

Enunciado Diseño del diagrama del sistema

Descripción Se hacen todos los diseños funcionales
para el sistema, en estos los casos de uso y
el diseño del sistema.
Duración 1 semana
Responsable Diseñador

Enunciado Diagrama del sistema

Descripción Se hace el diseño funcional que ya se
estableció en las especificaciones
funcionales
Duración 1 semana
Responsable Líder de diseño

Enunciado Diseño de la aplicación

Descripción Se hace el diseño funcional que ya se
estableció en el diagrama del sistema.
Duración 2 semana
Responsable

Enunciado Diseño de la base de datos

Descripción Se tienen un encuentra el conjunto de
actividades que va realizar la aplicación,
 para incluir el modelo y esquema
Actividades
Duración 2 semana
Responsable Diseñador de BD

Enunciado Documentación del diseño final

Descripción Informe que se establece la estructura de
datos, la arquitectura general de la
aplicación representada de interfaz y
algoritmos y se desarrolla lo que se hiso en
el diseño técnico del sistema, la
funcionalidad del sistema
Duración 1 semana
Responsable Analista y diseñador

Enunciado Base de datos

Descripción Ya especificada la estructuración de la
información que se desea mantener en la
base de datos con sus respetivo indicadores
Duración 3 semana
Responsable Diseñador y analista

Enunciado software
Descripción Se procede a realizar todas
especificaciones en la parte del diseño y se
llevara a cabo el desarrollo de la aplicación
móvil para el producto final.
Duración 4 semana
Responsable programador

Enunciado Plan de prueba del sistema

Descripción Se hacen las pruebas en última parte del
desarrollo del sistema se verifican y se
hacen correcciones, donde se juntan todos
los módulos corregidos de la aplicación
móvil que se encuentre en un estado óptimo
cumpliendo todos los requerimientos.
Duración 2 semana
Responsable Programador

Enunciado Reporte de los resultado de las pruebas

Descripción En esta fase se procede a reportar las
realizaciones de las pruebas específicas de
la aplicación, donde se va observar la
correcta funcionalidad de la aplicación
móvil.
 Duración 1 semana
Responsable

Enunciado Plan de contingencia a caída del sistema

Descripción Evaluando factores de riesgo para contener
una respuesta inmediata para resolver
alguna contingencia que se presente en la
aplicación.
Duración 1 semana
Responsable El líder del proyecto

III.2. Estimación de los recursos – Tiempo

III.2.1. Definición de las Actividades.

Actividades Descripción Duración Precedentes

A Lista de requisitos 1 --
B Especificación del sistema 1 --
C Descripción resumida del sistema 1 A,B
propuesto y sus características.
D Diseño de diagramas del sistema 2 C
E Diagramas del programa. 2 C
F Estándares de programación y 1 C
diseño de programas
G Documento del diseño final del 1 D,E,F
sistema y de cada programa.
H Desarrollo de la base de datos. 4 G
I Desarrollo del software. 4 H
J Resultado de las pruebas de cada 1 I
modulo
K Plan de pruebas del sistema. 1 J
L Informe y Reporte de los resultados 1 K
de las pruebas.
M Manuales del software 1 L
N Plan de contingencia a caídas del 1 M
sistema y recuperación por BD
O Plan de revisión para después de la 1 N
instalación
P Informe de la instalación 1 O
Q Listado de fallos detectados en el 1 P
sistema
R Listado de mejoras solicitadas por el 1 Q
usuario
 S Documento de revisión final y 1 R
entrega.

III.2.2. Determinación de la Secuencia de las Actividades

 Diagrama de precedencia

III.2.3. Estimación de los Recursos de las Actividades.

 Duración de las Actividades
Actividad Duración Fecha Fecha Fin Responsable Entregable
(semanas) Inicio 2018 2019
A 1 11 17 Analista Lista de requisitos
septiembre septiembre
B 1 18 24 Analista Especificación del sistema
septiembre septiembre
C 1 25 1 octubre Analista Descripción resumida del
septiembre sistema propuesto y sus
características.
D 2 2 octubre 15 octubre Diseñador Diseño de diagramas del
sistema
E 2 16 octubre 22 octubre Diseñador Diagramas del programa.
F 1 23 octubre 29 octubre Diseñador Estándares de
programación y diseño de
programas
G 1 30 octubre 5 Diseñador Documento del diseño final
noviembre del sistema y de cada
programa.
H 4 6 noviembre 3 Desarrollador Desarrollo de la base de
diciembre datos.
I 4 4 diciembre 31 Desarrollador Desarrollo del software.
diciembre
J 1 1 enero 7 enero Desarrollador Resultado de las pruebas
de cada modulo
K 1 8 enero 14 enero Tester Plan de pruebas del
sistema.
L 1 15 enero 21 enero Tester Informe y Reporte de los
resultados de las pruebas.
M 1 22 enero 28 enero Tester Manuales del software
N 1 29 4 febrero instalador Plan de contingencia a
caídas del sistema y
recuperación por BD
O 1 5 febrero 11 febrero Instalador Plan de revisión para
después de la instalación
P 1 12 febrero 18 febrero Instalador Informe de la instalación
Q 1 19 febrero 25 febrero Mantenimiento Listado de fallos
detectados en el sistema
R 1 26 febrero 4 marzo Mantenimiento Listado de mejoras
solicitadas por el usuario
S 1 5 marzo 11 marzo Jefe Documento de revisión
final y entrega.

1. Construcción del Cronograma (en la herramienta)

 Diagrama Pert

 Diagrama de Gantt

3.3. Estimación de recursos – Costos ***

Estimar costos

CARGO COSTO
gerente del proyecto $
Analista $
Diseñador $
Administrador de BD $
desarrollador $
Tester $
Instalador $
Mantenimiento $
CIO $
Área de recursos
$
humano
Área financiera $
TOTAL DEL COSTO $

Determinar Presupuesto
 3.4. Elaboración plan de recursos humanos ***
Organización del proyecto – organigrama (Equipo de trabajo del
proyecto)

Matriz RAM de asignación de responsabilidades

Actividades Descripción
A Lista de requisitos
B Especificación del sistema
C Descripción resumida del sistema propuesto y sus
características.
D Diseño de diagramas del sistema
E Diagramas del programa.
F Estándares de programación y diseño de programas
G Documento del diseño final del sistema y de cada programa.
H Desarrollo de la base de datos.
I Desarrollo del software.
J Resultado de las pruebas de cada modulo
K Plan de pruebas del sistema.
L Informe y Reporte de los resultados de las pruebas.
M Manuales del software
N Plan de contingencia a caídas del sistema y recuperación por BD
O Plan de revisión para después de la instalación
P Informe de la instalación
Q Listado de fallos detectados en el sistema
R Listado de mejoras solicitadas por el usuario
S Documento de revisión final y entrega.

A B C D E F G H I J K L M N O P Q R S
ANÁLISIS RE RE RE
DISEÑO RE RE RE RE
DESARROLLO RE RE RE R R R R R R
PRUEBAS E E E
INSTALACION E E E
MANTENIMIENTO Y RE RE RE
ENTREGA

Matriz RACI de roles y responsabilidades

 NOMBRE ROL
A Jefe del hospital
B CIO
C Patrocinador
D Gerente del proyecto
E Asesora de salud
F desarrollador
G Administrador de BD
H Analista
I Diseñador
J Tester
K instalador
L mantenimiento
M Área de recursos humano
N Área financiera

A B C D E F G H I J K L M N
ANALISIS A A I R, C - - R C - - - C C
A
DISEÑO - A - R,I C - - C R - - - C C
DESARROLLO - - - R.I - R R - - - - - - -
PRUEBAS - - - R.I - - - - - R - - - -
INSTALACION - - R.I - - - - - - R - - -
MANTENIMIENTO I,A I I R, I - - - - - - R - -
A

A- APRUEBA R - RESPONSABLE C - CONSULTA I - INFORMA

3.5. Gestión riesgos ***

Identificación de los riesgos

Evaluación de los riesgos

*** Utilizar las plantillas de pmoinformatica o los anexos del libro de

proyectos
IV. APLICACIÓN DE PROYECTOS CON LA METODOLOGÍA SCRUM
4.1. Inicio
 Visión del producto
PARA HOSPITAL EDUARDO ARREDONDO QUIEN tiene la necesidad de
automatizar el proceso de triage EL producto moviltriage QUE ES UN/A
aplicación móvil QUE permite la clasificación de pacientes a través del
proceso de triage A DIFERENCIA DE otros hospitales que lo realizan de
manera manual NUESTRO PRODUCTO Permite automatización en el
proceso de triage a distancia desde el momento de ser atendido en la
ambulancia.

 Formación del equipo Scrum

NOMBRE CARGO ROL

José Brito Jefe del hospital Product owner
Carlos Paredes gerente del proyecto Scrum master
Graciela Garcés Analista
Marcela cuadrados Diseñador
Juan Saucedo Administrador de BD
Mario Pérez desarrollador Equipo de trabajo
Javier Trujillo Tester
Daniel Romero Instalador
Santiago Araque Mantenimiento
Luz Marina Díaz CIO
Área de recursos
Carolina molina humano Cuerpo de asesores
Cesar Caicedo Área financiera
María torres Asesora de salud
Lorena Suarez patrocinador socio

 Definición del producto

Historia de Usuario
Número:
Usuario: cliente
HU001
Nombre historia: Gestión de pacientes
Prioridad en negocio: Alta
Programador responsable: Mario Pérez
Descripción: como cliente quiero la especificación del registro, consulta,
eliminación y modificación de paciente (datos personales y antecedentes), para
tener un informe de todos los pacientes que ingresen al hospital.
Observaciones:
 Se debe almacenar de ellos su cedula, nombres, apellidos, dirección, fecha
de nacimiento, edad, tipo de afiliación, estado civil, ocupación, fecha y hora
de ingreso, dirección, teléfono, consulta inicial, re consulta, nivel
 socioeconómico, nivel educativo sexo, EPS y motivo de consulta.

 Los pacientes deben estar afiliados, si no están no se debe poder

ingresarlos.

Historia de Usuario
Número:
Usuario: cliente
HU002
Nombre historia: Historial clínico
Prioridad en negocio: Medio
Programador responsable: Mario Pérez
Descripción:
Como cliente quiero almacenar el historial clínico del paciente, para obtener un
registro del diagnóstico, síntomas y antecedentes y de esta forma tener mayor
claridad de la evolución del estado de salud del paciente.
Observaciones:
• De estas se debe registrar el id historial clínico, la fecha en que asiste a la
consulta la prioridad del Triage asignada, nombre del paciente y
descripción del motivo de la urgencia.

Historia de Usuario
Número:
Usuario: cliente
HU003
Nombre historia: Gestión de síntomas
Prioridad en negocio: Alta
Programador responsable: Mario Pérez
Descripción: como cliente quiero la verificación, registro, consulta, eliminación y
modificación de los síntomas del paciente , para así saber que prioridad tiene
dicho síntoma y hacer su respectiva clasificación
Observaciones:
 Todos los pacientes deben tener registrado un síntoma

Historia de Usuario
Número:
Usuario: cliente
HU004
Nombre historia: Verificación de prioridades
Prioridad en negocio: Alta
Programador responsable: Mario Pérez
Descripción:
Como cliente quiero verificar la prioridad teniendo en cuenta el nivel de los
síntomas, para tener la clasificación del paciente mediante el proceso Triage.
Observaciones:
 El proceso de prioridades se divide en 5 niveles (Nivel I: Reanimación
(rojo), Nivel II Emergencia (naranja), Nivel III Urgencia (amarillo), Nivel IV
Urgencia menor (verde), Nivel V Sin urgencia (azul)).

Historia de Usuario
Número:
Usuario: cliente
HU005
Nombre historia: Reporte de clasificación de Triage
Prioridad en negocio: Medio
Programador responsable: Mario Pérez
Descripción:
Como cliente quiero tener reportes sobre la clasificación de Triage, para saber la
estadística de cuantos pacientes se clasifican según el nivel de Triage.
Observaciones:
 Este proceso mostrara estadísticas de la clasificación de Triage.
 Pacientes atendidos por EPS
 Generar informes

 Definición de la pila de producto

Identificador Historia de tarea prioridad estado

de la tarea usuario
Gestión Registro
pacientes
Gestión Actualización
pacientes
Gestión Listado
pacientes
Gestión Registro
enfermeras
Gestión Actualización
enfermeras
Gestión Listado
enfermeras
Gestión Registro
síntomas
Gestión Actualización
síntomas
Gestión Listado
síntomas
Historial
clínico
 Historial
clínico
Verificación de
prioridades
reportes

4.2. Planificación
 Planeación del Sprint
 Creación de tareas
 Estimación de tareas
 Creación de la lista de pendientes del sprint

V. CONCLUSIONES
VI. BIBLIOGRAFIA