0% encontró este documento útil (0 votos)
121 vistas86 páginas

Examen Parcial Proy2

Este documento describe problemas en el proceso de control de terapias y atención a pacientes en una clínica de medicina física. Actualmente el proceso es manual lo que genera demoras, falta de comunicación entre áreas y duplicación de registros. Se requiere automatizar el proceso para mejorar la atención al paciente.
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
121 vistas86 páginas

Examen Parcial Proy2

Este documento describe problemas en el proceso de control de terapias y atención a pacientes en una clínica de medicina física. Actualmente el proceso es manual lo que genera demoras, falta de comunicación entre áreas y duplicación de registros. Se requiere automatizar el proceso para mejorar la atención al paciente.
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd

ESCUELA PROFESIONAL DE INGENIERIA DE COMPUTACION Y SISTEMAS

TRABAJO DE INVESTIGACIÓN

AUTOMATIZACIÓN DEL PROCESO DE CONTROL DE TERAPIAS


PARA LA DISTRIBUCIÓN DE PACIENTES EN AGENTES DE
TRATAMIENTOS EN EL ÁREA DE MEDICINA FÍSICA DE LA
CLÍNICA SAN JUDAS TADEO

ASIGNATURA: PROYECTO II

PRESENTADA POR

BAZALAR CONTRERAS, HECTOR MARTIN

ASTOCONDOR FARRO, HUGO ISMAEL

PROFESOR: ING. RUBÉN GARCIA FARJE

LIMA, PERÚ

2019
ÍNDICE

CAPITULO I. PLANTEAMIENTO DEL PROBLEMA.....................................................................................6


1.1 Descripción de la situación problemática...............................................................................6
1.2 Formulación del problema......................................................................................................9
1.3 Objetivos de la investigación................................................................................................10
1.4 Justificación de la investigación............................................................................................11
1.5. Limitaciones del estudio.......................................................................................................16
CAPITULO II. MARCO TEORICO.............................................................................................................17
2.1 Antecedentes.......................................................................................................................17
2.2 Bases teóricas.......................................................................................................................19
2.3 Definición de términos básicos.............................................................................................27
CAPITULO III. METODOLOGIA...............................................................................................................28
3.1 Diseño metodológico............................................................................................................28
CAPITULO IV. DESARROLLO..................................................................................................................32
4.1 Desarrollo metodológico......................................................................................................32
4.2 Requerimientos – Historias de usuarios...............................................................................35
4.3 Diseño y Desarrollo técnico..................................................................................................44
4.4 Cronograma..........................................................................................................................52
REFERENCIAS BIBLIOGRAFICAS.............................................................................................................53
ANEXOS................................................................................................................................................57
Índice de Figuras
Figura 1. Cronograma del Proyecto.........................................................................................52
Figura 2. Cartón Azul para Terapias – Parte 1........................................................................58
Figura 3. Cartón Azul para Terapias - Parte 2.........................................................................59
Figura 4. Cronograma de Atención por Agente de Tratamiento.............................................60
Figura 5. Compromiso de Pago de Terapias............................................................................61
Figura 6. Análisis de Involucrados..........................................................................................62
Figura 7. Árbol de Problemas..................................................................................................63
Figura 8. Árbol de Objetivos...................................................................................................64
Figura 9. Ishikawa....................................................................................................................65
Figura 10. Proceso de Negocio AS – IS..................................................................................66
Figura 11. Ficha de Proceso de Negocio.................................................................................67
Figura 12. CANVAS................................................................................................................68
Figura 13. Proceso Propuesto TO – BE...................................................................................69
Figura 14. Módulo de Gestión de Terapias TO – BE..............................................................70
Figura 15. Módulo de Control de Terapias TO – BE..............................................................71
Figura 16. Módulo de Evaluación de Terapias TO – BE.........................................................72
Figura 17. Proceso de Atención al Paciente TO – BE.............................................................73
Figura 18. Elementos de Notación...........................................................................................74
Figura 19. Relación de Actores del Sistema............................................................................75
Figura 20. Diagrama de Casos de Uso Estructurado del Sistema............................................76
Figura 21. Elaboración del Backlog Inicial.............................................................................77
Figura 21. Priorización de Casos de Uso del Sistema.............................................................78
Figura 22. Project Charter - IceScrum.................................................................................79
Índice de Tablas
Tabla 1. Detalle y Costo de Hardware.....................................................................................12
Tabla 2. Detalle de Software....................................................................................................13
Tabla 3. Costo de Recursos Humanos.....................................................................................14
Tabla 4. Costo de horas hombre...............................................................................................14
Tabla 5. Costo de Servicio de Terceros...................................................................................15
Tabla 6. Ingreso anual del servicio de atención.......................................................................15
Tabla 8. Roles de SCRUM del proyecto..................................................................................28
CAPITULO I.

PLANTEAMIENTO DEL PROBLEMA

1.1 Descripción de la situación problemática

La labor de la clínica es “Satisfacer con eficiencia, calidad y alto nivel

profesional a las necesidades en el ámbito de la salud de todas aquellas personas que

requieran atención médica.” (Clínica San Judas Tadeo, s.f.).

Según Ramos y Espadín, 2019, p.2 nos indica que “los trastornos

muscoesqueléticos (TME) suponen un 45% de las lesiones profesionales”. Por ello, es

considerado como el trastorno con mayor registro de atención.

Asimismo, Zambrano, V. (2017, p.16) nos comenta que “Tomando en cuenta

que la apreciación que tenga el paciente de la calidad del servicio va a influir para sus

expectativas, este proceso debe tener un constante seguimiento y modificación de la

calidad que (…) ofrece”. Debido a que una buena atención se traduce en la

satisfacción del paciente.

El Instituto Nacional de Estadística e Informática ([INEI], 2018b, p.9)

argumenta que “Una de las principales razones por las que el 23,4% de pacientes no

acude a un establecimiento de salud es la distancia de este y demora en la atención.”.

Siendo la demora en la atención uno de los principales factores que afecta el servicio

del paciente, es necesario evaluar este proceso y examinar que factores dilatan en la

Clínica San Judas Tadeo.

Gracias a la tesis de Grandez Aguilar, J.C. (2017, p.4), entendemos lo siguiente

“Las personas constantemente suelen quejarse por el tiempo que llevan haciendo cola

en los establecimientos de salud, esto se ocasiona en el área de admisión al momento


de realizar la búsqueda y apertura de una historia clínica ya que no todos los

establecimientos cuentan con una herramienta que les facilite dicho procedimiento y

por ello lo realizan de forma manual.” De esta manera, evidenciamos que el tiempo de

espera es dilatado en el proceso que inicia en el área de admisión hasta la apertura de

la historia clínica, lo cual afecta la calidad atención brindada al paciente.

El tener la documentación manualmente perjudica y aumenta el tiempo de

espera tanto a los pacientes como los trabajadores del área. Según Herrera Trujillo, L

(2018) En la empresa se observa un deficiente trabajo en equipo, además de una

deficiente comunicación entre áreas, muchas veces generado por un bajo compromiso

con los objetivos de la empresa y por no tener procesos estandarizados que les den

soporte a (…) la empresa. (p.1).

Asimismo, “las consecuencias que este problema trae para la administración de

pacientes son los siguientes: duplicación de historias clínicas con la misma

identificación de pacientes, riesgos de pérdida de información (historias clínicas),

atraso en la búsqueda, etc.” (La Rosa y Mendoza, 2017, p.12)

Referido a la Historia Clínica Electrónica, según Alvarado Mendoza, M (2017),

p.9 “(…), se reducen los costos de los hospitales por lo tanto reduce los costos para

los pacientes y se pierde menos tiempo en las consultas y seguimiento de los

pacientes, beneficiando tanto al personal de salud como a los pacientes.” Esto quiere

decir que, a menor material o recursos utilizados, como el papel, menor será el costo

para la atención del paciente y para el centro de salud. Según el Instituto Nacional de

Estadística e Informática ([INEI], 2018, p.24) “la fabricación de papel y cartón

ondulado y de envases de papel y cartón aumentó en 17,86%, por producción de

sacos, cajas de cartón, papel corrugado y diversos cartones para el mercado interno.”
No obstante, esto podría evitarse con el uso de computadoras para lograr una

mejor efectividad en el rendimiento de los trabajadores del área respecto al

diagnóstico, seguimiento y tratamiento de los pacientes. (Alvarado Mendoza,

M.C,2017, p.2).
1.2 Formulación del problema

Actualmente la excesiva documentación en el proceso es tedioso. Además, las

demoras en las atenciones causan la necesidad de agilizar las labores del área. Para

esto el problema consiste en la deficiencia del proceso de control de terapias de los

pacientes del área de medicina física de la Clínica San Judas Tadeo. 

1.2.1. Problema General

¿Cómo mitigar las dificultades encontradas en la gestión de distribución

de pacientes en el área de medicina física y rehabilitación de la Clínica San

Judas Tadeo?  

1.2.2. Problemas Específicos

a) ¿De qué manera se espera optimizar el proceso de control de terapias del

área de Medicina Física y Rehabilitación? 

b) ¿Cuál es la importancia de optimizar el proceso de control de terapias del

área de Medicina Física y Rehabilitación? 

c) ¿Cuál es el nivel de participación de la secretaria en el proceso de control

de terapias en el área de medicina física y rehabilitación de la clínica san

judas Tadeo?  

d) ¿De qué manera corroborar el progreso del proceso de control de terapias? 


1.3 Objetivos de la investigación

1.3.1. Objetivo General

El objetivo de la investigación es mejorar el proceso de control de terapias

de los pacientes de medicina física y rehabilitación de la Clínica San Judas

Tadeo para la distribución en los diferentes agentes de tratamientos que se

realizan en el área. 

1.3.2. Objetivos Específicos

 Automatizar el actual proceso de control de terapias del área.  

 Reducir el tiempo en la atención del paciente para la distribución en su

agente de tratamiento a realizarse. 

 Incrementar la comunicación con la secretaria durante el proceso de control

de terapias.

 Realizar y documentar el nuevo proceso automatizado de la metodología

SCRUM para el desarrollo del sistema web. 


1.4 Justificación de la investigación

1.4.1. Importancia de la investigación

El desarrollo de este proyecto está orientado a la automatización de las

actividades manuales del control de terapias, puesto que disminuir las quejas

de los pacientes por la demora en las atenciones para los tratamientos de las

terapias y errores en los cronogramas de los pacientes en el área de medicina

física son de vital importancia, así mismo la elaboración de cronogramas de

terapias de los pacientes, se realizan en cuadernos y el control de las sesiones

de los pacientes toman tiempo en obtener la información, con esto.

El desarrollo del proyecto obtendrá varios beneficios como la

disminución de consumo de papel ayudando la mejora del medio ambiente, la

inexistencia de duplicidad y la obtención de información de los pacientes de

una manera rápida y de manera eficaz, gracias a esto nos ayudará a recibir más

pacientes en menos tiempo. En la presente investigación se definirá la

metodología SCRUM como herramienta para el desarrollo ágil en la

implementación del desarrollo software, teniendo como apoyo la norma

técnica peruana 29110 para tener calidad en el desarrollo y gestión del

proyecto; además de las distintas herramientas de software que ayudaran a la

realización de los sistemas requeridos para la automatización del proceso

propuesto.
1.4.2. Viabilidad de la investigación

1.4.2.1. Viabilidad técnica

Para el desarrollo del proyecto, en el enfoque técnico, se cuenta con

los recursos tecnológicos (Hardware) nos ayudará para que el desarrollo

sea el adecuado, se presentará a continuación en la siguiente tabla:

Tabla 1. Detalle y Costo de Hardware

Herramientas Descripción Detalles Cantidad


Procesador Intel® Core™ Equipo compatible para el
i7-6500U CPU @ 2.50 desarrollo de la aplicación
Laptop ASUS GHz. 16 GB de RAM. 2GB y realización de pruebas. 1
de Video. Disco duro de También, como repositorio
1000 GB. Windows 10 pro. de la documentación.
Procesador Intel® Core™ Equipos virtualizados que
i5-3200U CPU @ 2.50 serán utilizados como
Servidor de
GHz. 16 GB de RAM. 2GB servidores de aplicaciones 1
Aplicaciones
de Video. Disco duro de tanto en testing y
1000 GB. Windows 10 pro. producción.
Procesador Intel® Core™ Equipos virtualizados que
i5-3200U CPU @ 2.50 serán utilizados como
Servidor de Base de
GHz. 16 GB de RAM. 2GB servidores de base de datos 1
Datos
de Video. Disco duro de tanto en testing y
1000 GB. Windows 10 pro. producción.
Elaboración: Los autores

A nivel de desarrollo del sistema la empresa CLINICA SAN

JUDAS TADEO nos otorga los siguientes softwares los cuales son

manejados por el área de Sistemas.

También se requiere el uso de algunos softwares para el desarrollo

del proyecto como muestra la siguiente tabla:


Tabla 2. Detalle de Software

Herramientas Descripción

Frameworks
Framework CSS basado en el diseño responsiva.
Bootstrap

Framework de PHP diseñado para desarrolladores que necesitan un kit de


CodeIgniter herramientas simple y elegante para crear aplicaciones web con todas las
funciones. Nos detalla la arquitectura MVC.
Motor de Base de Datos donde almacenaremos y tomaremos toda la
Microsoft
información de los datos maestros y datos secundarios del sistema
SQL Server
principal.
MySQL Motor de Base de Datos donde almacenaremos toda la información de los
Workbench datos maestros y datos secundarios del sistema.
Herramienta donde se realizará la automatización de los procesos de
SublimeText
gestión de citas y control de terapias.
Bizagi
Herramienta donde se realizará el proceso del negocio y propuesto.
Modeler
Es un servidor web HTTP de código abierto, para plataformas Unix,
Apache
Microsoft Windows, Macintosh y otras.
Paquete de software libre, que consiste principalmente en el sistema de
XAMP gestión de bases de datos MySQL, el servidor web Apache y los intérpretes
para lenguajes de script PHP y Perl.
IBM-
RATIONAL Esta herramienta nos ayudara a modelar las diferentes actividades que
SOFTWARE realizaran los actores del sistema con los diferentes módulos, así
ARCHITECT obteniendo graficas que describan el proceso en sí.
(RSA)
PHP, HTML,
CSS, Frameworks de ayuda en programación orientada ah objetos, listas,
JAVASCRIPT, interacciones entre las páginas web que nos ayudaran a hacerlas más
JQUERY, dinámicas, más rápidas y del agrado del usuario.
AJAX, JSON
Es una herramienta web que nos ayuda a poder realizar la gestión de
SMARTSHEETproyecto ayudándonos a colaborar entre los usuarios registrados
elaborando diagramas de GANT y más.
Herramienta web que nos ayudara en la gestión del proyecto de manera
ICE-SCRUM
ágil y según la metodología de desarrollo SCRUM.
Elaboración: Los autores

1.4.2.2. Viabilidad operativa

Para realizar este proyecto se cuenta con la disponibilidad de tiempo

de las personas involucradas en el desarrollo de este.

Para el desarrollo del proyecto, actualmente se contará con el

siguiente recurso principal, el cual se va a encargar de la gestión y

desarrollo del proyecto.


 Astocóndor Farro, Hugo

 Bazalar Contreras, Héctor

Tabla 3. Costo de Recursos Humanos

RECURSOS HUMANOS
Equipo de Salario S/. % de Mese
Responsable Total
Trabajo Mensual Part. s
Team Scrum -
Bazalar Contreras, Hector S/. 1,000 50% 12 S/.6,000
Analista
Team Scrum -
Bazalar Contreras, Hector S/. 1,000 25% 12 S/.3,000
Programador
Team Scrum -
Bazalar Contreras, Hector S/. 1,000 25% 12 S/.3,000
DBA
Team Scrum -
Astocóndor Farro, Hugo S/. 1,000 50% 12 S/.6,000
Analista
Team Scrum -
Astocóndor Farro, Hugo S/. 1,000 50% 12 S/.6,000
Programador
Scrum Master -
Líder del Mestas, Mario S/. 4,000 20% 12 S/.9,600
Proyecto
S/.28,80
TOTAL
0
Elaboración: Los autores

1.4.2.3. Viabilidad Económica

Para estimar un costo referencial del sistema, este proyecto se

realizará en las instalaciones de la empresa con equipos de la empresa y

utilizando software de licencia gratuita, no se requerirá de inversión inicial,

solo de recursos humanos antes mencionados, también se toman en cuenta

factores como servicios a terceros y salarios de los involucrados.

Tabla 4. Costo de horas hombre

COSTO X COSTO POR SALDO SALDO


ROL TIEMPO
TIEMPO DIA MENSUAL ANUAL

DOCTOR 5H S/ 20.00 S/ 100.00 S/3,000.00 S/36,000.00


SECRETARIA 8H S/ 4.17 S/ 33.33 S/1,000.00 S/12,000.00
TERAPISTA 6H S/ 2.50 S/ 15.00 S/1,500.00 S/18,000.00
TOTAL S/66,000.00
Elaboración: Los autores
Tabla 5. Costo de Servicio de Terceros

COSTO X COSTO COSTO


SERVICIO COSTO X DIA
PROCESO MENSUAL ANUAL
ENERGIA
S/ 2.00 S/ 56.00 S/ 1,456.00 S/17,412.00
ELECTRICA
INTERNET S/ 4.00 S/ 97.07 S/ 2,912.00 S/34,944.00
IMPRESIÓN S/ 0.50 S/ 14.00 S/ 364.00 S/ 4,368.00
TOTAL S/56,724.00
Elaboración: Los autores
Tabla 6. Ingreso anual del servicio de atención

GANANCIAS
COSTO X MENSUAL (1200
SERVICIO DIARIAS (40 ANUAL (14,400)
SERVICIO ATENCIONES)
ATENCIONES)

ATENCION DE
S/ 35.00 S/ 700.00 S/ 21,000.00 S/ 252,000.00
CITAS
ATENCION DE
TERAPIAS (12 S/ 120.00 S/ 2,400.00 S/ 72,000.00 S/ 864,000.00
SESIONES)

TOTAL S/ 1,116,000.00

Elaboración: Los autores

A partir de la implementación del proyecto se busca que la cantidad

de atenciones en el área se incremente entre un 40% a 50%

aproximadamente en un año, para ello la cantidad de citas debe aumentar

1680 y 1800 que, calculando con el precio promedio, estaríamos hablando

de un ingreso de S/. 280,000 para el año 1.


1.5. Limitaciones del estudio

Las limitaciones identificadas para el desarrollo del proyecto son las

siguientes:

 Actualmente el proceso no se encuentra adecuadamente documentado,

pero aun así se lleva a cabo de forma diaria.

 La disponibilidad de la información de los pacientes que se atienden en

el área de medicina física depende del área de archivos, es decir, la

información del área de archivos se circunscribe a la que se recibe en el

área de medicina física de la Clínica San Judas Tadeo.

 Solo podrán entrar las personas que están involucradas directamente

con el área de medicina física y rehabilitación.

 Tiempo de Desarrollo.
CAPITULO II.

MARCO TEORICO

2.1 Antecedentes

Según Loreto Vergara B. (2010, p.282), nos dice en su artículo que “La

especialidad de Medicina Física y rehabilitación, como la conocemos actualmente,

tiene su origen en Estados Unidos, a comienzos del siglo XX, con la figura del médico

Dr. Frank Crucen, graduado en la Jefferson Medical Collage en Filadelfia en 1921.”,

por consiguiente, a lo largo de los años se vio afectado el proceso nos solo por el

cambio tecnológico sino por el crecimiento de los procesos en dicha área.

2.1.1. Antecedentes Nacionales

Según Gutarra C. &Quiroga, R. (2014) en su tesis “Implementación de

un sistema de historias clínicas electrónicas para el centro de salud Perú 3ra

zona” el cual nos relata sobre su investigación que con la implementación del

sistema mejora la calidad de atención del paciente, satisfaciéndolos.

Estandarizando y almacenando información de los pacientes de forma

estructurada evitando duplicidad de información y mejorando la gestión de las

historias clínicas.

Carrión, V. (2015) en su tesis “Desarrollo de una aplicación web basada

en el modelo vista controlador para la gestión de las historias clínicas de los

pacientes en el centro de salud de San Jerónimo” nos cuenta sobre su

investigación que con la implementación del sistema de gestión de historia

clínica optimiza la gestión de las HC de los pacientes y reduce el tiempo de

búsqueda de los expedientes médicos de los pacientes.


Ruiz, G. (2017) en su tesis “Desarrollo e implementación de proceso de

cajas en Clínica Belen-Sanna “nos relata que la implementación del proceso

ayudó a regularizar las cajas, disminuyendo los errores y que ya no se generen

pérdidas de dinero.

2.1.2. Antecedentes Internacionales

Según Albán, J & Fuentes, Y. (2018) en su tesis “Desarrollo de

aplicación web para la gestión de historial médico de pacientes de la clínica

San Miguel”, esta tesis se realizó con el objetivo de sistematizar los datos de

los pacientes que se encuentran en papelas, archivos y reducir la cantidad de

reclamos generados por los pacientes. El sistema tiene una interfaz de rápido

acceso, facilitando la gestión administrativa, obteniendo información confiable

cuando se necesite generar cuadros estadísticos, ayudando en la toma de

decisiones para la mejora de la atención clínica en beneficio de la comunidad.

Pairazaman, L. & Vigo, E. (2017) en su tesis “Sistema de información

web para el mejor control y acceso a las historias clínicas de los pacientes del

centro de salud Jequetepeque” nos cuenta sobre los resultados de la

investigación, el uso del sistema web agiliza los procesos de atención a los

pacientes, obteniendo información actualizada, realiza el registro de HC,

reportes y consultas con mayor rapidez utilizando menor tiempo de respuesta

en el registro de HC.
2.2 Bases teóricas

2.2.1. Medicina Física y Rehabilitación

Según la Unión Europea de Médicos Especialistas (UEMS) nos relata

que la Medicina Física y Rehabilitación es una especialidad médica consciente

de la prevención, diagnóstico, tratamiento y manejo rehabilitador de las

personas con condiciones médicas discapacitantes y comorbilidad (Barca

Fernández, I, 2018, p.24)

2.2.2. Fisioterapia

Según Castillo, C. (2017) “La fisioterapia, también conocida como

rehabilitación funcional, es un programa diseñado para ayudar al paciente a

mejorar o mantener sus capacidades funcionales (por ejemplo, actividades de

la vida diaria). La fisioterapia incluye el desarrollo de la fuerza, flexibilidad y

resistencia, así como el aprendizaje de la biomecánica apropiada (por ejemplo,

la postura) para lograr la estabilidad de la columna y prevenir las lesiones.”

(p.15)

2.2.3. Historia Clínica

Según Villaruel (2015). La historia clínica es un documento con

información médica que se usa para enjuiciar la relación médico - paciente,

aquí se recoge datos importantes para una óptima atención. La información

que contiene la historia clínica puede ser de: tipo asistencial, información

obtenida por medio de exámenes físicos luego de inspeccionar al paciente; de

tipo comentada, preguntando al paciente enfermedades familiares, problemas


de salud anteriores datos de talla y peso; información complementaria como

exámenes de sangre, exámenes de orina, test de alergias de medicinas y

alimentos”. (Chiquilín & Vásquez, 2018, p.41)

2.2.4. Historia Clínica Electrónica

Según Espinoza Ñaña, J (2015) no comenta que la HCE “Es la historia

clínica cuyo registro unificado y personal, multimedia, se encuentra contenido

en una base de datos electrónica, registrada mediante programas de

computación y refrendada con firma digital del profesional tratante.” (p.09)

2.2.5. CIE-10

Según Anso Borda, I. “La CIE-10 es la clasificación de referencia de

todos los países para la notificación de causas de defunción. Son varios los

países que han realizado modificaciones clínicas de la CIE-10 para cubrir sus

respectivas necesidades de información clínico asistencial.” (p.11)

2.2.6. Servicios Web

“Según Barzanallana (2012) Una aplicación web es básicamente una

manera de facilitar el logro de una tarea específica ... en la web, a diferencia de

un sitio web estático que es más bien una herramienta, no menos importante,

para la comunicación… La aplicación web por lo tanto permite al usuario

interactuar directamente contigo y tus datos, todo en forma personalizada, para

llevar a cabo esa tarea específica” (Arias Muñoz, M, 2018, p.28)

2.2.7. PHP

Como lo menciona Arce, A (2018) “PHP es un lenguaje diseñado para

crear contenido HTML. PHP puede ser ejecutado de tres formas: en un

servidor web, a través de la línea de comandos, o mediante un cliente GUI. El


lenguaje puede ejecutarse en prácticamente todos los sistemas operativos

actuales y en múltiples servidores web. Este también soporta una amplia

variedad de bases de datos y cuenta con múltiples librerías para ejecutar

procesos comunes” (p.3)

2.2.8. Microsoft SQL Server

Según Quintanilla, V (2017) SQL Server “Es un sistema para la gestión

de bases de datos producido por Microsoft basado en el modelo relacional. Sus

lenguajes para consultas son T-SQL y ANSI SQL. Microsoft SQL Server

constituye la alternativa de Microsoft a otros potentes sistemas gestores de

bases de datos como son Oracle, PostgreSQL o MySQL.” (p.21)

2.2.9. Framework CodeIgniter

Como lo menciona Álvarez, M (s.f) “Es un programa o aplicación web

desarrollada en PHP para la creación de cualquier tipo de aplicación web bajo

PHP. Es un producto de código libre, libre de uso para cualquier aplicación.

Como cualquier otro framework, CodeIgniter contiene una serie de librerías

que sirven para el desarrollo de aplicaciones web y además propone una

manera de desarrollarlas que debemos seguir para obtener provecho de la

aplicación.” (p.2)

2.2.10. Metodologías Agiles

Según Vergara, R (2015) “El desarrollo ágil de software enfatiza la

colaboración cercana entre el equipo de desarrollo y los expertos del negocio,

comunicación directa y en persona (face to face) 43 evitando la documentación

escrita, entrega de avances desplegables con valor de negocio, equipos


pequeños y organizados, y formas para elaborar el código de tal manera que la

inevitable dependencia y cohesión de los requerimientos no sea un problema.

El término ágil aplicado al desarrollo de software tiene como objetivo esbozar

los valores y principios que deberían permitir a los equipos un desarrollo y la

rápida respuesta a los cambios que pueden surgir a lo largo del proyecto

mucho más veloz que con algún proceso de desarrollo tradicional que están

caracterizados por su rigidez y dirigidos a la documentación que se genera al

finalizar cada actividad desarrollada.” (p.43)

2.2.11. SCRUM

“Según la investigación (Figueroa et al., 2008) sobre Metodologías

Tradicionales vs. Metodologías Ágiles”, Scrum es un proceso ágil y liviano

que sirve para administrar y controlar el desarrollo de software. El desarrollo

se realiza en forma iterativa e incremental (una iteración es un ciclo corto de

construcción repetitivo). Cada ciclo o iteración termina con una pieza de

software ejecutable que incorpora nueva funcionalidad. Las iteraciones, en

general, tienen una duración entre 2 y 4 semanas. Scrum se utiliza como marco

para otras prácticas de ingeniería de software como RUP o Extreme

Programming. Scrum se focaliza en priorizar el trabajo en función del valor

que tenga para el negocio, maximizando la utilidad de lo que se construye y el

retorno de inversión.” (Babilón, L & Zamorano, C, 2016, p.26)


2.2.12. Elementos del SCRUM

2.2.12.1. Sprint

Según Shojaee, H (s.f.) “El producto se construye de forma incremental

en base a períodos de tiempo cortos, denominados Sprints. Los Sprints

tienen una duración fija y determinada, entre 1 y 4 semanas; mejor cuanto

más cortas, es decir mejor 1 semana que 4. Todos los Sprints tienen la

misma duración a lo largo del proyecto, porque se rigen según el principio

de “timeboxing”: cada elemento tiene un tiempo asignado que termina

cuando acaba este tiempo.” (p.6)

2.2.12.2. Definición de Hecho

Según Shojaee, H (s.f.) “El equipo de trabajo tiene que encontrar una

definición para el concepto de "hecho" -Done-. Cada incremento del

producto debe cumplir dicha definición de "hecho" para darlo por

finalizado, y poder ser entregado. La definición de "hecho" puede aplicar a

requisitos, sprints, releases, entornos... es decir, en cualquier elemento sobre

el que se pueda plantear la cuestión de "¿está finalizado y puede continuar

al paso siguiente del proyecto? “Son las condiciones para considerar el

elemento terminado con éxito”. (p.7)

2.2.12.3. Ciclo de Scrum

Según Shojaee, H (s.f.) “El proyecto se ejecuta en base a sprints, de

duración fija, que se planifican al arrancar cada sprint, con las Daily cada

24 horas. En cada sprint se resuelve o construye el Sprint backlog, que se

integra al final del sprint con el resultado de sprints anteriores,

conformando un producto entregable.” (p.7)


2.2.12.4. Productos

Según Shojaee, H (s.f.) “Incremento de producto: un subconjunto del

producto que puede ser entregado, con componentes integrados, que

funciona. Backlog de producto: la lista de requisitos del producto,

ordenadas por su prioridad. Backlog del Sprint: el plan detallado para el

desarrollo durante el sprint siguiente.” (p.8)

2.2.12.5. Pilares Básicos

Según Shojaee, H (s.f.) “Transparencia: los interesados comparten un

entendimiento común del proyecto, de la visión, y de lo que significa

"hecho". Inspección: a través de los artefactos o entregables (incremento de

producto, backlog de producto y backlog del sprint). Adaptación: a través de

las reuniones en Scrum”. (p.8)

2.2.12.6. Reunión Daily Scrum

Según Shojaee, H (s.f.) “Es una reunión con un timebox de 15 minutos,

donde el equipo de trabajo sincroniza sus actividades y crea el plan para las

siguientes 24 horas. En esta reunión, cada miembro del equipo de trabajo

debe responder a 3 preguntas: ¿Qué hice ayer? ¿Qué haré hoy? ¿Hay algún

impedimento que me evite conseguir mis objetivos hasta mañana?” (p.9)

2.2.12.7. Reunión Sprint Review

Según Shojaee, H (s.f.) “Es la reunión que se mantiene al final de cada

Sprint para inspeccionar el Incremento de Producto, y adaptar el Backlog

del producto si es necesario. Durante el Sprint Review, el equipo de trabajo

muestra al resto de interesados qué se ha conseguido en el sprint” (p.9)


2.2.12.8. Reunión Retrospectiva del Sprint

Según Shojaee, H (s.f.) “Se inspecciona cómo ha ido el sprint, en lo

referente a las personas, sus relaciones, el proceso, y las herramientas. Se

identifican y ordenan los asuntos más importantes, tanto los que fueron

bien, como los que suponen una mejora potencial. Se crea un plan para

implementar las posibles mejores detectadas” (p.9)

2.2.13. Roles del SCRUM

Según Trigas, G (s.f)

“Son las personas que están comprometidas con el proyecto y el proceso

de Scrum.

• Product Owner: Es la persona que toma las decisiones, y es la que

realmente conoce el negocio del cliente y su visión del producto. Se encarga

de escribir las ideas del cliente, las ordena por prioridad y las coloca en el

Product Backlog.

• ScrumMaster: Es el encargado de comprobar que el modelo y la

metodología funciona. Eliminará todos los inconvenientes que hagan que el

proceso no fluya e interactuará con el cliente y con los gestores.

• Equipo De Desarrollo: suele ser un equipo pequeño de unas 5-9

personas y tienen autoridad para organizar y tomar decisiones para conseguir

su objetivo. Está involucrado en la estimación del esfuerzo de las tareas del

Backlog.

Aunque no son parte del proceso de Scrum, es necesario que parte de la

retroalimentación dé la salida del proceso y así poder revisar y planear cada

sprint.
• Usuarios: Es el destinatario final del producto.

• Stakeholders: Las personas a las que el proyecto les producirá un

beneficio. Participan durante las revisiones del Sprint.

• Managers: Toma las decisiones finales participando en la selección de

los objetivos y de los requisitos.” (p.36)

2.2.14. Artefactos Scrum

Según Palacios, J (2015)

“Pila del producto: (product backlog) lista de requisitos de usuario,

que a partir de la visión inicial del producto crece y evoluciona durante

el desarrollo.

Pila del sprint: (sprint backlog) lista de los trabajos que debe realizar

el equipo durante el sprint para generar el incremento previsto.

Incremento: resultado de cada sprint.” (p.22)

2.2.15. Project Charter

Según Oviedo, L (2016)

“El acta de constitución de proyecto o Project Charter es un documento

que formalmente autoriza un proyecto o fase. El acta de constitución

define la razón del proyecto y asigna un gerente de proyectos y su nivel

de autoridad para el proyecto.” (p. 33)


2.3 Definición de términos básicos

2.3.1. Optimizar Procesos Médicos.

“Según Neumann, (2014) la optimización de procesos se logra a través

de la investigación del uso adecuado de los recursos tanto humanos como

materiales. Para ello primero se detectan los procesos “core” en que se

destinan el grueso de los recursos, para luego trazar metas con fin de mejorar

de manera significativa el rendimiento de dichos procesos. Controlar el uso de

los recursos y mejorar el rendimiento de las personas es posible con la

optimización de procesos, finalmente se tiene el objetivo de mejorar el

rendimiento, reducir costos para poder tener procesos más eficientes y

eficaces.” (Muro, F. 2015, p.18)

2.3.2. Importancia de la Rehabilitación Medica.

La rehabilitación médica es importante para reducir el nivel de

discapacidad y refuerza las oportunidades para las personas discapacitadas.

Según la Unión Europea de Médicos Especialistas (UEMS), (2009) “Tratar las

consecuencias de la enfermedad y de los traumatismos, tales como la

espasticidad tras un daño cerebral o medular, significa que no sólo mejorará la

vida de los pacientes, sino que también existirá un beneficio a nivel

económico, mediante la reducción de los gastos debido al tratamiento de

dichas complicaciones. Ello tendrá un efecto directo en el cuidado, en la vida

laboral y en las pensiones “(p.10)


CAPITULO III.

METODOLOGIA

3.1 Diseño metodológico

La metodología de desarrollo ágil seleccionada para la implementación de los

procesos de gestión de citas y control de terapias, la cual identificara las verdaderas

necesidades de los stakeholders, realizar una correcta estimación de los tiempos,

lograr una participación del equipo de trabajo, revisar lo construido contrastando con

el objetivo del sprint para entregar una versión del producto hasta finalmente obtener

lo esperado.

Las fases del desarrollo metodológico ágil SCRUM son:

3.1.1. Fase de inicio

Fase de preparación del proyecto conocida como el sprint 0, es la fase

inicial en la que se intenta comprender el caso de negocio con la finalidad de

tomar decisiones que agreguen valor al producto, identificar los roles claves y

formar equipos.

Tabla 7. Roles de SCRUM del proyecto

Roles Descripción Profesional


Las personas a las que el proyecto les producirá
Stakeholder Doctor, Secretaria, Terapista
un beneficio.
Es la Persona que toma decisiones, y es la que
Product Owner Analistas del Proyecto
realmente conoce el negocio del cliente.
Es el encargado de comprobar que el modelo y la
Scrum Master Jefe del área de Sistemas
metodología funciona.
Tienen la autoridad para organizar y tomar Personas encargadas del desarrollo y
Scrum Team
decisiones para conseguir su objetivo desarrollo de los Sprint
Fuentes: Elaboración propia

Las tareas por realizar en el Sprint 0 son:


 Definir el proyecto.

 Definir la tarea como terminado.

 Definición del Backlog Inicial.

 Definición de Entregables.

3.1.2. Fase de planificación y estimación

Tiene como finalidad realizar una reunión, en la que participaran el

Product Owner, el Scrum Master y el equipo, con la intención de seleccionar

la lista Backlog del producto las funcionalidades sobre la que se va a trabajar,

y que darán valor al producto.

El Product owner tendrá que preparar el Backlog para así poder discutir

en las reuniones donde se dividen en dos partes de 2 horas:

3.1.3. Primera parte de la reunión

 El equipo selecciona los ítems para transformarlos en

entregables.

 El equipo hace sugerencias, el Product owner decidirá si

forma parte del sprint.

 El equipo seleccionara el elemento a implementar, de los

seleccionados por el P.O. para ese Sprint.

3.1.4. Segunda parte de la reunión

 El equipo hace preguntas necesarias que tengan que ver

sobre el Product backlog al Product owner.


 El equipo deberá encontrar la solución adecuada para

transformar la parte adecuada de una funcionalidad

entregable.

3.1.5. Fase de implementación del Sprint

El Desarrollo del Sprint, en esta fase el equipo trabaja para conseguir

un aumento en el producto final, que será productivo para el Product Owner y

los Stakeholders, además se pueden entregar con el menor esfuerzo al

Stakeholders cuando lo solicite.

La duración de un Sprint es más conveniente que dure entre 2 a 4

semana, a lo mucho un mes. Estos intervalos de tiempos son los que se

consideran más apropiados para que el Stakeholders no pierda el interés.

Las reuniones durante la ejecución del Sprint son:

 Reunión de Planificación.

 Reunión Diaria.

 Reunión Revisión del Sprint.

3.1.6. Fase de revisión y retrospectiva

Después del Sprint el equipo de desarrollo debatirá temas relacionados

con el Sprint recientemente finalizado y los cambios que se podrían hacer para

mejorar el próximo sprint y que sea más productivo. Se lleva a cabo el último

día del Sprint y tiene dos partes:

 Revisión (Demostración): El equipo presenta al Stakeholder los

requisitos completados del Sprint, en forma de un aumento del

producto preparado para ser entregado con el mismo esfuerzo


posible. Dependiendo del Resultado mostrado, el cliente realiza

adaptaciones necesarias de manera objetiva, a partir del primer

Sprint, reprogramando el proyecto.

 Retrospectiva: El equipo analiza cómo ha sido su forma de

trabajar y cuáles son los problemas que podrían impedirles

progresar adecuadamente, mejo9rando continuamente su

productividad.

3.1.7. Fase de Lanzamiento

En esta fase se encuentran las típicas actividades de fin de proyecto

como, hacer una versión distribuible, testear, marketing, etc.


CAPITULO IV.

DESARROLLO

4.1 Desarrollo metodológico

4.1.1. IceScrum:

Herramienta de gestión de proyectos Scrum.

Project Charter - IceScrum

Backlog Inicial
Sprint Backlog – Usando IceScrum

Especificaciones no Funcionales

Tipo de Nombre Código Descripción


Requisito
Tiempo de RNF-01 El tiempo de respuesta del sistema para
respuesta operaciones de ingreso o registro de
información deberá ser como máximo 10
segundos de espera
Rendimiento Tiempo de RNF-02 El tiempo promedio al realizar los registros
Transacción de un problema con el hardware debe ser
de forma instantánea al guardar los datos
en la base de datos y poderse comunicar
con el personal de sistemas y validarlos
RNF-03 A cada persona que interactúe con el
Ingresar al sistema se le asignará un usuario del
sistema sistema y una clave, los cuales permitirán
el ingreso de acuerdo con un perfil
seleccionado.
Confiabilidad Cumplimiento RNF-04 El sistema soportará fallas
de
confiabilidad
Precisión RNF-05 El sistema debe mostrar la fecha y hora
de las operaciones realizadas por los
usuarios.
Disponibilidad RNF-06 El sistema estará disponible 24 horas al
diaria Activa día, 7 días a la semana.

Disponibilidad Disponibilidad RNF-07 El sistema estará disponible las 24 horas


24 horas del día para cualquier consulta que
requieran realizar los usuarios.
Usuario RNF-08 Cada usuario tendrá una contraseña única
seguro para que pueda entrar al sistema.

Seguridad Back-up RNF-09 El sistema tendrá un Back-up (copia de


datos) de todo el contenido histórico de
las operaciones.
Sistema RNF-10 El Sistema no puede permitir el cierre de
estable una operación hasta que todos sus
procesos, subprocesos y tareas hayan
concluido satisfactoriamente.
Portabilidad RNF-11 El sistema deberá considerar para su
Portabilidad desarrollo la arquitectura MVC.
Servicio en la RNF-12 El sistema estará en la nube lo que
nube permite transferirse de un lugar a otro.
Interfaz gráfica RNF-13 El sistema debe poseer una interfaz
uniforme gráfica uniforme a través de este
incluyendo pantallas, menús y opciones,
tamaño de las pantallas, color y tipo de
letra.
Diseño RNF-14 El diseño debe realizarse guiado por las
Organizacional características generales, en cuanto a
Mantenibilidad colores organizacional recomendados por
el usuario y disposición de contenidos,
encontradas en el sitio web de la Entidad.
Idioma RNF-15 Las interfaces deben realizarse en idioma
castellano; sin perjuicio de lo cual debe
evitar traducirse la terminología técnica
específica que no posee una traducción
precisa al castellano.
Facilitar uso RNF-16 El Sistema debe ser de fácil uso, muy
comprensible en cuanto al diseño visual
del sistema.
Usabilidad Manejar y RNF-17 El Sistema debe presentar mensaje de
comunicar error que permitan al usuario identificar el
errores tipo de error y comunicarse con el
administrador del sistema.
4.2 Requerimientos – Historias de usuarios

A continuación, se mencionarán las historias de usuario que se llevaron a cabo

para el desarrollo del producto.

 HU - Iniciar Sesión

 HU - Buscar Perfil

 HU - Mantener Perfil

 HU - Buscar Usuario

 HU - Mantener Usuario

 HU - Mantener Terapias

 HU - Buscar Camilla

 HU - Mantener Camilla

 HU - Buscar Agente de Tratamiento

 HU - Mantener Agente de Tratamiento

 HU – Buscar Terapista

 HU – Mantener Terapista

 HU – Buscar Consultorio

 HU – Mantener Consultorio

 HU – Buscar Diagnósticos CIE-10

 HU – Mantener Diagnósticos CIE-10

 HU – Buscar Pacientes

 HU – Mantener Pacientes

 HU – Buscar Doctores
 HU – Mantener Doctores

 HU – Reportar Ingresos en el Área

 HU – Listar Cronograma de Atención a Terapias

 HU – Reportar Atenciones en el Área

 HU – Visualizar Antecedentes en el Área

 HU – Registrar Horarios de Atención

 HU – Tratar Paciente

 HU – Pagar Atención

 HU – Registrar Historia Clínica de Paciente

 HU – Generar Historia Clínica

 HU – Reservar Cita

 HU – Generar Cronograma de Atención

 HU – Atender Pacientes
HU Iniciar Sesión – Usando IceScrum

Prototipo HU Iniciar Sesión


HU Mantener Perfil– Usando IceScrum

Prototipo HU Mantener Perfil


HU Mantener Usuario– Usando IceScrum

Prototipo HU Mantener Usuario


HU Mantener Camilla – Usando IceScrum

Prototipo HU Mantener Camilla


HU Mantener Consultorio – Usando IceScrum

Prototipo HU Mantener Consultorio


HU Mantener Pacientes – Usando IceScrum
Prototipo HU Mantener Pacientes

HU Mantener Personal – Usando IceScrum


Prototipo HU Mantener Personal

4.3 Diseño y Desarrollo técnico

4.3.1. Etapas de la metodología a utilizar

A continuación, se mostrará el modelo físico de la base de datos de la

Clínica San Judas Tadeo.


4.3.2. Pruebas Unitarias

Prueba Unitaria – Iniciar Sesión y Mantener Usuario


Número del caso de descripción de lo pre-
prueba componente que se probara requisitos

<<componente Usuario y
<<CHU - 01>> Usuario y password
1>> password

usuario y
<<componente
<<CHU - 02>> 3 perfiles agregados password de
2>>
los 4 perfiles

<< CHU - 01>>


Datos de Salida
N° Descripcion Tipo de dato entrada Esperada ¿ok? observaciones
Usuario: vista
1 usuario String admin correcta ok ninguna
password: vista
2 password String admin correcta ok ninguna
3 validación String Usuario: vista ok ninguna
admin incorrecta
password:
adminn

<< CHU - 02>>


Datos de Salida
N° Descripcion Tipo de dato entrada Esperada ¿ok? observaciones
Perfil Usuario: ingreso
1 Adminstrador String admin correcto ok ninguna
Perfil Usuario: ingreso
2 Secretaria String secre correcto ok ninguna
3 Perfil Doctor String Usuario: ingreso ok ninguna
doctor correcto

Perfil Usuario: ingreso


4 Terapista String terap correcto ok ninguna

Evidencia Prueba Unitaria

Prueba Unitaria – Mantener Usuarios

Evidencia Prueba Unitaria


Prueba Unitaria –

Evidencia Prueba Unitaria

4.3.3. Plan de Pruebas

Prueba de funcionalidad
CP - INICIAR SESIÓN

COMPORTAMIENTO RESULTADO DE LA
NOMBRE DE OBJETIVO PASOS A REPRODUCIR
ESPERADO PRUEBA
1. Logo e imagen de la
Clínita
2. Campo para ingresar
VERIFICAR PANTALLA 1. Abrir la aplicación "usuario" Aprobado
3. Campo para ingresar
"contraseña"
4. Boton inicio de sesión
1. Ingresar usuario
2. Ingresar contraseña Datos correctos y
VERIFICAR LOGUEO Aprobado
3. Seleccionar en el muestra página de inicio
botón iniciar sesión.
1. Ingresar usuario
2. No ingresar
VERIFICAR MENSAJE SIN Muestra "ingresa tu
contraseña Aprobado
INGRESAR CONTRASEÑA contraseña"
3. Seleccionar en el
botón iniciar sesión.
1. Ingresar mal el usuario
VERIFICAR MENSAJE CON y/o contraseña Muestra "Verifica tus
Aprobado
DATOS INCORRECTOS 2. Seleccionar en iniciar datos"
sesión

CP - MANTENER PERFIL

COMPORTAMIENTO RESULTADO DE LA
NOMBRE DE OBJETIVO PASOS A REPRODUCIR
ESPERADO PRUEBA

1. Muestra mensaje
1. Seleccionar "Agregar"
"Nuevo perfil agregado"
VERIFICAR AGREGAR 2. Completar los campos
Aprobado
NUEVO PERFIL correctamente
3. Botón "Registrar" 2. Se agregará un nuevo
perfil en la DB

1. Selecciona en el icono 1. Muestra mensaje


VERIFICAR MODIFICAR "lápiz" "Perfil Editado"
Aprobado
PERFIL 2.Modifica el campo 2. Se modificará el
3. Botón "Aceptar" campo solicitado

1. Selecciona en el icono
VERIFICAR REGISTRO "lápiz" Muestra "Ingresa los
Aprobado
INCORRECTO 2. No modifica el campo datos"
3. Botón "Aceptar"

1. Selecciona en el icono
VERIFICAR ELIMINAR Muestra "Perfil
"equis" Aprobado
PERFIL Eliminado "
2. Botón "Aceptar"
CP - MANTENER USUARIO

COMPORTAMIENTO RESULTADO DE LA
NOMBRE DE OBJETIVO PASOS A REPRODUCIR
ESPERADO PRUEBA
1. Seleccionar "Agregar" 1. Muestra mensaje
VERIFICAR AGREGAR 2. Completar los campos "Nuevo usuario
Aprobado
NUEVO USUARIO correctamente 2. Se agregará un nuevo
3. Botón "Registrar" usuario en la DB
1. Selecciona en el icono 1. Muestra mensaje
VERIFICAR MODIFICAR "lápiz" "Usuario Editado"
Aprobado
USUARIO 2.Modifica el campo 2. Se modificará el
3. Botón "Aceptar" campo solicitado
1. Selecciona en el icono
VERIFICAR REGISTRO "lápiz" Muestra "Ingresa los
Aprobado
INCORRECTO 2. No modifica el campo datos"
3. Botón "Aceptar"
1. Selecciona en el icono
VERIFICAR ELIMINAR Muestra "Usuario
"equis" Aprobado
USUARIO Eliminado "
2. Botón "Aceptar"

CP - MANTENER TERAPIAS

COMPORTAMIENTO RESULTADO DE LA
NOMBRE DE OBJETIVO PASOS A REPRODUCIR
ESPERADO PRUEBA
1. Seleccionar "Agregar" 1. Muestra mensaje
VERIFICAR AGREGAR 2. Completar los campos "Nuevo terapia
Aprobado
NUEVO TERAPIA correctamente 2. Se agregará una nueva
3. Botón "Registrar" terapia en la DB
1. Selecciona en el icono 1. Muestra mensaje
VERIFICAR MODIFICAR "lápiz" "Terapia Editada"
Aprobado
TERAPIA 2.Modifica el campo 2. Se modificará el
3. Botón "Aceptar" campo solicitado
1. Selecciona en el icono
VERIFICAR REGISTRO "lápiz" Muestra "Ingresa los
Aprobado
INCORRECTO 2. No modifica el campo datos"
3. Botón "Aceptar"
1. Selecciona en el icono
VERIFICAR ELIMINAR Muestra "Terapia
"equis" Aprobado
TERAPIA Eliminada "
2. Botón "Aceptar"
CP - MANTENER CAMILLA

COMPORTAMIENTO RESULTADO DE LA
NOMBRE DE OBJETIVO PASOS A REPRODUCIR
ESPERADO PRUEBA
1. Seleccionar "Agregar" 1. Muestra mensaje
VERIFICAR AGREGAR 2. Completar los campos "Nuevo camilla"
Aprobado
NUEVA CAMILLA correctamente 2. Se agregará una nueva
3. Botón "Registrar" camilla en la DB
1. Selecciona en el icono 1. Muestra mensaje
VERIFICAR MODIFICAR "lápiz" "Camilla Editada"
Aprobado
CAMILLA 2.Modifica el campo 2. Se modificará el
3. Botón "Aceptar" campo solicitado
1. Selecciona en el icono
VERIFICAR REGISTRO "lápiz" Muestra "Ingresa los
Aprobado
INCORRECTO 2. No modifica el campo datos"
3. Botón "Aceptar"
1. Selecciona en el icono
VERIFICAR ELIMINAR Muestra "Camilla
"equis" Aprobado
CAMILLA Eliminada "
2. Botón "Aceptar"

CP - MANTENER CONSULTORIO

COMPORTAMIENTO RESULTADO DE LA
NOMBRE DE OBJETIVO PASOS A REPRODUCIR
ESPERADO PRUEBA
1. Seleccionar "Agregar" 1. Muestra mensaje
VERIFICAR AGREGAR 2. Completar los campos "Nuevo consultorio"
Aprobado
NUEVO CONSULTORIO correctamente 2. Se agregará un nuevo
3. Botón "Registrar" consultorio en la DB
1. Selecciona en el icono 1. Muestra mensaje
VERIFICAR MODIFICAR "lápiz" "consultorio Editado"
Aprobado
CONSULTORIO 2.Modifica el campo 2. Se modificará el
3. Botón "Aceptar" campo solicitado
1. Selecciona en el icono
VERIFICAR REGISTRO "lápiz" Muestra "Ingresa los
Aprobado
INCORRECTO 2. No modifica el campo datos"
3. Botón "Aceptar"
1. Selecciona en el icono
VERIFICAR ELIMINAR Muestra "Consultorio
"equis" Aprobado
CONSULTORIO Eliminado "
2. Botón "Aceptar"
CP - MANTENER PACIENTE

COMPORTAMIENTO RESULTADO DE LA
NOMBRE DE OBJETIVO PASOS A REPRODUCIR
ESPERADO PRUEBA
1. Seleccionar "Agregar" 1. Muestra mensaje
VERIFICAR AGREGAR 2. Completar los campos "Nuevo paciente"
Aprobado
NUEVO PACIENTE correctamente 2. Se agregará un nuevo
3. Botón "Registrar" paciente en la DB
1. Selecciona en el icono 1. Muestra mensaje
VERIFICAR MODIFICAR "lápiz" "Paciente Editado"
Aprobado
PACIENTE 2.Modifica el campo 2. Se modificará el
3. Botón "Aceptar" campo solicitado
1. Selecciona en el icono
VERIFICAR REGISTRO "lápiz" Muestra "Ingresa los
Aprobado
INCORRECTO 2. No modifica el campo datos"
3. Botón "Aceptar"
1. Selecciona en el icono
VERIFICAR ELIMINAR Muestra "Paciente
"equis" Aprobado
PACIENTE Eliminado "
2. Botón "Aceptar"

CP - MANTENER PERSONAL

COMPORTAMIENTO RESULTADO DE LA
NOMBRE DE OBJETIVO PASOS A REPRODUCIR
ESPERADO PRUEBA
1. Seleccionar "Agregar" 1. Muestra mensaje
VERIFICAR AGREGAR 2. Completar los campos "Nuevo personal"
Aprobado
NUEVO PERSONAL correctamente 2. Se agregará un nuevo
3. Botón "Registrar" personal en la DB
1. Selecciona en el icono 1. Muestra mensaje
VERIFICAR MODIFICAR "lápiz" "Personal Editado"
Aprobado
PERSONAL 2.Modifica el campo 2. Se modificará el
3. Botón "Aceptar" campo solicitado
1. Selecciona en el icono
VERIFICAR REGISTRO "lápiz" Muestra "Ingresa los
Aprobado
INCORRECTO 2. No modifica el campo datos"
3. Botón "Aceptar"
1. Selecciona en el icono
VERIFICAR ELIMINAR Muestra "Personal
"equis" Aprobado
PERSONAL Eliminado "
2. Botón "Aceptar"
4.3.4. Arquitectura

Es un Panel de Control basado en Linux, administra servidores web

dedicados al alojamiento de páginas. Actualmente es el panel de control más

utilizado a nivel mundial. CPanel cuenta con varias opciones como, por ejemplo:

 Archivos

 Base de Datos

 Dominios

 Correo Electrónico

 Métrica

 Seguridad

 Software
Fácil de instalar

Compatible con diferentes navegadores

Transferir el sitio web de la empresa de hosting a otro sin problema


4.4 Cronograma
Figura 1. Cronograma del Proyecto

Fuente: Elaboración Propia (Smartsheet)


REFERENCIAS BIBLIOGRAFICAS

Clínica San Judas Tadeo. (s.f.). Recuperado de


http://www.clinicasanjudastadeo.com.pe/nosotros

Ramos, H & Espadín, S (2018) Factores de riesgo en el desarrollo de trastornos


muscoesqueléticos de obreros de una empresa de transporte de Lima – Huacho,
Marzo 2018. Universidad Peruana Cayetano Heredia. Lima, Perú. Recuperado de
http://repositorio.upch.edu.pe/bitstream/handle/upch/3685/Factores_RamosRojas
_Helen.pdf?sequence=1&isAllowed=y

Instituto Nacional de Estadística e Informática (2018), Situación de la Población Adulta


Mayor. Recuperado de https://www.inei.gob.pe/media/MenuRecursivo/boletines/01-
informe-tecnico-n01_adulto-oct-nov-dic2018.pdf

Instituto Nacional de Estadística e Informática (2018), Producción Nacional. Recuperado de


https://www.inei.gob.pe/media/MenuRecursivo/boletines/informe-tecnico-de-
produccion.pdf

Zambrano, V (2017) Grado de calidad de la atención que recibe el paciente por parte del
terapeuta físico en el hospital Pablo Arturo Suarez en diciembre del 2016. Pontificia
Universidad Católica del Ecuador. Quito, Ecuador. Recuperado de
http://repositorio.puce.edu.ec/bitstream/handle/22000/13718/tesis%20final
%20pdf.pdf?sequence=1&isAllowed=y

Grandez Aguilar, J.C. (2017) Sistema informático web para el control de historias clínicas
electrónicas de la red de salud Tupac Amaru. Universidad Cesar Vallejo. Lima, Perú.
Recuperado de
http://repositorio.ucv.edu.pe/bitstream/handle/UCV/1495/Grandez_AJC.pdf?
sequence=1&isAllowed=y
Herrera Trujillo, L.A. (2018) Propuesta de modelo de gestión por procesos para el
cumplimiento oportuno de los pagos a los proveedores de la empresa Robert Bosch
S.A.C. Universidad Ricardo Palma. Lima, Perú. Recuperado de
http://repositorio.urp.edu.pe/bitstream/handle/URP/1659/Tesis-Luis%20Herrera
%206.pdf?sequence=1&isAllowed=y
La Rosa, D & Mendoza, A. (2017). Implementación de un sistema de información para la
administración de pacientes de la Clínica Privada Cínife. Universidad de Ciencias y
Humanidades, Lima, Perú. Recuperado de
http://repositorio.uch.edu.pe/bitstream/handle/uch/97/CD-TISI-019-2017.pdf?
sequence=1&isAllowed=y
Alvarado Mendoza, M. (2017) percepción de los alumnos de pregrado de la historia clínica
electrónica del sistema de gestión clínica docente de la facultad de estomatología de
la Universidad Peruana Cayetano Heredia, Lima-Perú, 2017. Universidad Peruana
Cayetano Heredia, Lima, Perú. Recuperado de
http://repositorio.upch.edu.pe/bitstream/handle/upch/839/Percepcion_AlvaradoMendo
za_Maria.pdf?sequence=3&isAllowed=y
Antecedentes:
Albán, J &Fuentes Y. (2018) Desarrollo de aplicación web para la gestión de historial
médico de pacientes de la clínica. Universidad Politécnica Salesiana, Guayaquil,
Ecuador. Recuperado de
https://dspace.ups.edu.ec/bitstream/123456789/15744/1/UPS-GT002204.pdf
Gutarra, C & Quiroga, R. (2014) implementación de un sistema de historias clínicas
electrónicas para el centro de salud Perú 3ra Zona. Universidad San Marín de
Porres, Lima, Perú. Recuperado de
http://www.repositorioacademico.usmp.edu.pe/bitstream/usmp/1463/3/gutarra_mcr_c
ompleta.pdf
Carrión Abollaneda, V. (2015) Desarrollo de una aplicación web basada en el modelo vista
controlador para la gestión de las historias clínicas de los pacientes en el centro de
salud de San Jerónimo. Universidad Nacional José María Arguedas, Andahuaylas,
Perú. Recuperado de
http://repositorio.unajma.edu.pe/bitstream/handle/123456789/177/10-2015-EPIS-
%20Carrion%20Abollaneda%20Victor-desarrollo%20de%20una%20apliccacion
%20web%20modelo%20vista.pdf?sequence=1&isAllowed=y
Ruíz Yovera, G. (2017) Desarrollo e implementación de proceso de cajas en Clínica Belén-
Sanna. Universidad de Piura. Piura, Perú. Recuperado de
https://pirhua.udep.edu.pe/bitstream/handle/11042/3203/TSP_CyA_011.pdf?
sequence=1&isAllowed=y

Pairazaman, L & Vigo, E. (2017) Sistema de información web para el mejor control y acceso
a las historias clínicas de los pacientes del centro de salud Jequetepeque.
Universidad Nacional de Trujillo, Trujillo, Perú. Recuperado de
http://dspace.unitru.edu.pe/bitstream/handle/UNITRU/9588/PAIRAZAMAN
%20ESTEVES%20Luis%20Alfredo%3b%20VIGO%20ESCALANTE%20Erick
%20Anthony.pdf?sequence=1&isAllowed=y

Bases Teóricas:
Barca Fernández, I. (2018) Impacto de la medicina física y rehabilitación en el pronóstico
funcional de los pacientes con tumor cerebral primario glial. Universidad
Complutense de Madrid, Madrid, España. Recuperado de
https://eprints.ucm.es/47024/1/T39776.pdf
Chuquilin, S &Vásquez H. (2018) Historia clínica electrónica como herramienta de mejora
en calidad de atención en la consulta externa hospital Ocatvio Mongrut, 2015.
Universidad Privada Antonio Guillermo Urrelo, Cajamarca, Perú. Recuperado de
http://repositorio.upagu.edu.pe/bitstream/handle/UPAGU/663/Informe%20Final
%20de%20Tesis.pdf?sequence=1&isAllowed=y
Castillo Hernández, C. (2017) Propuesta de implementación del área de fisioterapia en el
hospital “Dr, Jorge Vides Molina”, estudio realizado en el Hospital Nacional de
Huehuetenango, Guatemala. Universidad Rafael Landívar. Quetzaltenango,
Guatemala. Recuperado de
http://recursosbiblio.url.edu.gt/tesisjcem/2017/09/01/Castillo-Cinthia.pdf

Espinoza Ñaña, J. (2015) Impacto de la medicina física y rehabilitación en el pronóstico


funcional de los pacientes con tumor cerebral primario glial. Universidad San Martin
de Porres, Lima, Perú. Recuperado de
http://www.repositorioacademico.usmp.edu.pe/bitstream/usmp/2079/1/espinoza_jc.pd
f
Anso Borda, I (2018). Manual de codificación CIE-10-ES diagnósticos. Edición 2018.
Recuperado de
https://www.mscbs.gob.es/estadEstudios/estadisticas/normalizacion/CIE10/CIE10ES
_2018_norm_MANUAL_CODIF_DIAG_.pdf
Shojaee, H (s.f.). Metodología Agile y Scrum. Recuperado de
https://agile.structuralia.com/files/Documentacion.pdf

Trigas Gallego, M (s.f.) Metodología Scrum. Recuperado de


http://openaccess.uoc.edu/webapps/o2/bitstream/10609/17885/1/mtrigasTFC0612me
moria.pdf
Palacio, J (2015) Scrum Manager I. Recuperado de
https://www.scrummanager.net/files/scrum_I.pdf
Oviedo Ochoa, L (2015) Modelo de iniciación y planeación de proyectos para la empresa
Chemtreat. Universidad Industrial de Santander, Santander, Colombia. Recuperado de
http://tangara.uis.edu.co/biblioweb/tesis/2016/165182.pdf
Arias Muñoz, M. (2018) Desarrollo de una aplicación web para la mejora del control de
asistencia de personal en la Escuela Tecnológica Superior de la Universidad
Nacional de Piura. Universidad Inca Garcilaso de la Vega, Lima, Perú. Recuperado
de http://repositorio.uigv.edu.pe/bitstream/handle/20.500.11818/2930/TESIS-
MARCO%20ANTONIO%20ARIAS%20MU%C3%91OZ.pdf?
sequence=2&isAllowed=y
Carlos, D & Gamarra, L. (2018) Sistema móvil de gestión de historias clínicas para el centro
médico Los Jardines. Universidad Tecnológica del Perú, Lima, Perú. Recuperado de
http://repositorio.utp.edu.pe/bitstream/UTP/1711/1/Diego%20Carlos_Luis
%20Gamarra_Trabajo%20de%20Investigacion_Bachiller_2018.pdf
Arce, A. (2018) Programación PHP. Recuperado de
https://buildmedia.readthedocs.org/media/pdf/programacion-php/latest/programacion-
php.pdf
Quintanilla Callañaupa, V. (2017) Sistema de gestión de historial clínico para el área de
salud ocupacional de la clínica S.O Tu Salud S.A.C. Universidad Andina del Cusco,
Cusco, Perú. Recuperado de http://repositorio.uandina.edu.pe/bitstream/UAC/999/3/V
%C3%ADctor_Tesis_bachiller_2017.pdf
Álvarez, M. (s.f) Manual de CodeIgniter. Recuperado de
http://roa.ult.edu.cu/bitstream/123456789/3771/1/manual-codeigniter.pdf
Vergara Pérez, R. (2016) Desarrollo de una aplicación móvil para apoyar las supervisiones a
entidades prestadoras de servicio de salud. Universidad Nacional Mayor de San
Marcos, Lima, Perú. Recuperado de
http://cybertesis.unmsm.edu.pe/bitstream/handle/cybertesis/5302/Vergara_pr.pdf?
sequence=1&isAllowed=y
Muro Giurfa, F. (2015) Optimización en el proceso de consulta externa mediante un sistema
web y web móvil de atención medica dinámica con cálculo de riesgo cardiovascular
empleando la formula Framingham. Universidad Ricardo Palma, Lima, Perú.
Recuperado de http://cybertesis.urp.edu.pe/bitstream/urp/1130/1/muro_f.pdf
UEMS (2009) Libro blanco de medicina física y rehabilitación en Europa. España.
Recuperado de http://www.whitebookprm.eu/wp-
content/uploads/2017/01/SPANISH-VERSION-PRM-WHITE-BOOK-.pdf

Smartsheet (2019) Proyecto CSJT-CP con diagrama de Gantt. Recuperado de


https://app.smartsheet.com/sheets/CWwrpX8QvXVqh9c8QrwM75mrg24jHRP27vM
97FJ1
ANEXOS

En esta sección se encuentran anexos que sirven de información

complementaria para los diversos temas tocados en lo capítulos anteriores.

ANEXO 1:
Evidencia 1 - Parte 1

Elaboración: Clínica San Judas Tadeo

Figura 2. Cartón Azul para Terapias – Parte 1

ANEXO 2:
Evidencia 1 – Parte 2

Elaboración: Clínica San Judas Tadeo

Figura 3. Cartón Azul para Terapias - Parte 2


ANEXO 3:

Evidencia 2

Elaboración: Clínica San Judas Tadeo

Figura 4. Cronograma de Atención por Agente de Tratamiento


ANEXO 4:

Evidencia 3

Elaboración: Clínica San Judas Tadeo

Figura 5. Compromiso de Pago de Terapias


ANEXO 5:

Análisis de Involucrados

Elaboración: Autores

Figura 6. Análisis de Involucrados


ANEXO 6:
Árbol de Problemas
Elaboración: Autores

Figura 7. Árbol de Problemas

ANEXO 7:
Árbol de Objetivos
Elaboración: Autores

Figura 8. Árbol de Objetivos

ANEXO 8:
Ishikawa

Elaboración: Autores

Figura 9. Ishikawa
ANEXO 9:

Proceso de Negocio AS – IS

Elaboración: Autores Bizagi Modeler

Figura 10. Proceso de Negocio AS – IS


ANEXO 10:

Ficha de Proceso de Negocio

Elaboración: Autores

Figura 11. Ficha de Proceso de Negocio

ANEXO 11:
Modelo de Negocio

Elaboración: Autores

Figura 12. CANVAS


ANEXO 12:

Proceso Propuesto TO-BE

Elaboración: Autores Bizagi Modeler


Figura 13. Proceso Propuesto TO – BE
ANEXO 13:

Proceso TO-BE Modulo de Gestión de Terapias

Elaboración: Autores Bizagi Modeler

Figura 14. Módulo de Gestión de Terapias TO – BE


ANEXO 14:

Proceso TO-BE Modulo de Control de Terapias

Elaboración: Autores Bizagi Modeler

Figura 15. Módulo de Control de Terapias TO – BE

ANEXO 15:
Proceso TO-BE Modulo de Evaluación de Terapias

Elaboración: Autores usando Bizagi Modeler

Figura 16. Módulo de Evaluación de Terapias TO – BE

ANEXO 16:

Proceso TO-BE Proceso de Atención al Paciente


Elaboración: Autores usando Bizagi Modeler

Figura 17. Proceso de Atención al Paciente TO – BE

ANEXO 17:

Elementos de Notación
Elab

oración: Autores

Figura 18. Elementos de Notación

ANEXO 18:

Relación de Actores
Elaboración: Autores utilizando IBM-RSA

Figura 19. Relación de Actores del Sistema


ANEXO 19:
Diagrama de Casos de Uso Estructurado

Elaboración: Autores utilizando IBM-RSA


Figura 20. Diagrama de Casos de Uso Estructurado del Sistema
ANEXO 20:

Elaboración Del Backlog Inicial

Elaboración: Autores utilizando la herramienta de iceScrum


Figura 21. Elaboración del Backlog Inicial
ANEXO 21:

Priorización de casos de uso del sistema

PRIORIZACION DE CASOS DE USO DEL SISTEMA


AUTOMATIZACIÓN DEL PROCESO DE CONTROL DE TERAPIAS PARA LA DISTRIBUCIÓN DE PACIENTES EN AGENTES DE TRATAMIENTOS EN EL ÁREA DE
MEDICINA FÍSICA DE LA CLÍNICA SAN JUDAS TADEO
0.4 0.3 0.2 0.1
ACTOR CASO DE USO
IMPORTANCIA COMPLEJIDAD RIESGO IMPACTO TOTAL
1 DOCTOR Atender Pacientes 10 10 9 9 9.7
2 SECRETARIA,TERAPISTA Generar Cronograma de Atencion 10 10 9 8 9.6
3 SECRETARIA Reservar Cita 10 9 9 7 9.2
4 SECRETARIA,DOCTOR(EXCLUDE) Generar Historia Clinica 10 8 9 8 9.0
5 DOCTOR(INCLUDE) Registrar Historia Clinica de Paciente 9 8 9 8 8.6
6 SECRETARIA(EXCLUDE) Pagar Atencion 9 8 7 8 8.2
7 TERAPISTA Tratar al Paciente 8 7 7 8 7.5
8 ADMINISTRADOR Registrar Horarios de Atencion 8 7 7 6 7.3
9 SECRETARIA,TERAPISTA Visualizar Antecedentes en el Área 7 7 7 10 7.3
10 SECRETARIA Reportar Atenciones en el Área 9 6 7 5 7.3
11 SECRETARIA,TERAPISTA Listar Cronograma de Atencion a Terapias 8 7 6 6 7.1
12 SECRETARIA Reportar Ingresos en el Área 7 8 6 6 7.0
13 ADMINISTRADOR Mantener Personal 7 7 6 6 6.7
14 ADMINISTRADOR,SECRETARIA(INCLUDE) Buscar Personal 6 7 6 9 6.6
15 ADMINISTRADOR Mantener Pacientes 8 6 5 5 6.5
16 ADMINISTRADOR,SECRETARIA,DOCTOR(INCLUDE) Buscar Pacientes 8 6 5 4 6.4
17 ADMINISTRADOR Mantener Diagnosticos CIE10 8 6 5 4 6.4
18 ADMINISTRADOR,DOCTOR(INCLUDE) Buscar Diagnosticos CIE10 7 7 5 4 6.3
19 ADMINISTRADOR Mantener Consultorio 7 7 5 4 6.3
20 ADMINISTRADOR(INCLUDE) Buscar Consultorio 7 6 5 6 6.2
21 ADMINISTRADOR Mantener Agente de Tratamiento 7 5 5 7 6.0
22 ADMINISTRADOR(INCLUDE) Buscar Agente de Tratamiento 7 5 5 6 5.9
23 ADMINISTRADOR Mantener Camilla 7 5 6 4 5.9
24 ADMINISTRADOR(INCLUDE) Buscar Camilla 7 5 5 5 5.8
25 ADMINISTRADOR Mantener Terapias 7 5 5 5 5.8
26 ADMINISTRADOR Mantener Usuario 7 5 5 4 5.7
27 ADMINISTRADOR(INCLUDE) Buscar Usuario 7 5 5 4 5.7
28 ADMINISTRADOR Mantener Perfil 7 5 4 4 5.5
29 ADMINISTRADOR(INCLUDE) Buscar Perfil 7 4 5 4 5.4
30 USUARIO Iniciar Sesion 6 5 3 6 5.1

Elaboración: Autores
Figura 22. Priorización de Casos de Uso del Sistema
ANEXO 22:

Project Charter

Elaboración: Autores

Figura 23. Project Charter - IceScrum

También podría gustarte