Especificación de requisitos de software para el sistema ...repobib.ubiobio.cl/jspui/bitstream/123456789/686/1/Parra Urrea, Alfredo.pdf · 2 Resumen Este proyecto se presenta para

1

Universidad del Bío-Bío

Facultad de Ciencias Empresariales

Escuela de Ingeniería Civil Informática

“Especificación de requisitos de software para el sistema de ficha clínica del CECH.”

Alumno: Alfredo Parra Urrea

Profesor guía: Angélica Caro Gutiérrez

Memoria de Grado para optar al título de Ingeniero Civil en Informática.

Universidad del Bío-Bío. Red de Bibliotecas - Chile

2

Resumen

Este proyecto se presenta para dar conformidad a los requisitos exigidos por la Universidad del

Bío-Bío en el proceso de titulación para a la carrera de Ingeniería Civil Informática. El proyecto

se titula “Especificación de requisitos de software para el sistema de ficha clínica del CECH”.

El Centro de Estudios de la Comunicación Humana (CECH), es un centro clínico de la Escuela

de Fonoaudiología de la Universidad del Bío Bío. Se encuentra ubicado en el Campus

Fernando May, Chillán, Provincia de Ñuble en la octava región de Chile. Comenzó su

funcionamiento en 2011, para atender de manera gratuita a la comunidad que presenta

alteraciones fonoaudiológicas y poseen un acceso limitado a esta atención.

En este trabajo, se desea plasmar una elicitación de requisitos para el desarrollo de un

software de ficha clínica. Con el objetivo de describir todas las funcionalidades y necesidades

solicitadas por el cliente, para la posterior elaboración de un sistema informático que

permita llevar el control de la información de los pacientes del CECH, a la vez que nos

permita administrar una agenda electrónica para coordinar atenciones de los pacientes y

además que este sistema, entregué información estadística de las atenciones prestadas en el

centro.

Para realizar el levantamiento de requisitos se utiliza el método VOLERE, el cuál fue

seleccionado, previo a un estudio, entre varias metodologías de elicitación de requisitos de

software.

Los beneficios que se destacan en este informe, son entregar prototipos y la especificación de

cada requerimiento, con tal de facilitar la información a los diseñadores y desarrolladores

que vengan más adelante a construir el software final.


3

Índice General

1 INTRODUCCIÓN .............................................................................................................................. 8

2 DEFINICION DE LA EMPRESA O INSTITUCIÓN ................................................................................. 9

2.1 DESCRIPCIÓN DE LA EMPRESA ........................................................................................................ 9 2.2 DESCRIPCIÓN DEL ÁREA DE ESTUDIO .............................................................................................. 9 2.3 DESCRIPCIÓN DE LA PROBLEMÁTICA .............................................................................................. 9

3 DEFINICIÓN PROYECTO ................................................................................................................ 11

3.1 OBJETIVOS DEL PROYECTO .......................................................................................................... 11 3.1.1 OBJETIVO GENERAL .............................................................................................................................. 11 3.1.2 OBJETIVOS ESPECÍFICOS ........................................................................................................................ 11 3.2 AMBIENTE DE INGENIERÍA DE SOFTWARE ..................................................................................... 11 3.2.1 INGENIERÍA DE REQUISITOS. ................................................................................................................. 11 3.2.2 METODOLOGÍA PARA REALIZAR LA ELICITACIÓN DE REQUISITOS. ........................................................... 13 3.2.3 MÉTODO VOLERE ............................................................................................................................... 15 3.2.4 HERRAMIENTAS Y TECNOLOGÍAS A UTILIZAR ......................................................................................... 20 3.3 DEFINICIONES, SIGLAS Y ABREVIACIONES ..................................................................................... 20

4 ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE ................................................................ 22

4.1 ETAPA: PROYECTO BLASTOFF ..................................................................................................... 22 4.1.1 PROPÓSITO DEL PROYECTO ................................................................................................................... 22 4.1.2 EL CLIENTE. .......................................................................................................................................... 23 4.1.3 USUARIOS DEL PRODUCTO ..................................................................................................................... 23 4.2 RESTRICCIONES OBLIGATORIAS DEL PROYECTO ............................................................................ 23 4.2.1 RESTRICCIONES OBLIGATORIAS. ............................................................................................................ 24 4.2.2 AMBIENTE DE IMPLEMENTACIÓN DEL SISTEMA ACTUAL ........................................................................ 24 4.2.3 RESTRICCIONES CRONOLÓGICAS ............................................................................................................ 24 4.3 ETAPA: CAPTURA DE REQUISITOS. ............................................................................................... 25 4.3.1 ALCANCES DEL PRODUCTO ....................................................................................................................... 25 4.4 ETAPA DE ESCRITURA Y PROTOTIPOS DE REQUISITOS .................................................................... 28 4.4.1 REQUERIMIENTOS FUNCIONALES .......................................................................................................... 29 4.4.2 REQUISITOS NO FUNCIONALES .................................................................................................................. 62 4.4.3 LISTA DE CASOS DE USO DEL PRODUCTO .................................................................................................... 63 4.4.4 MATRIZ RESUMEN DE CASOS DE USO Y REQUERIMIENTOS. ........................................................................... 93 4.5 ETAPA DE CONTROL DE CALIDAD. ...................................................................................................... 94 4.6 ETAPA REVISIÓN DE REQUISITOS. ...................................................................................................... 94

5 ANÁLISIS ...................................................................................................................................... 95

5.1 MODELO DE DATOS CONCEPTUAL ................................................................................................ 95

6 RESUMEN ESFUERZO REQUERIDO ................................................................................................ 97

7 CONCLUSIONES ............................................................................................................................ 98

8 BIBLIOGRAFÍA .............................................................................................................................100

9 ANEXO: PLANIFICACIÓN INICIAL DEL PROYECTO .........................................................................101

10 ANEXO: PROTOCOLOS CECH ......................................................................................................102


4

10.1 PROTOCOLOS CUANTITATIVOS .................................................................................................102 10.1.1 DOMINIO ACE-R-CH ........................................................................................................................ 102 10.1.2 I.T.P.A.............................................................................................................................................. 103 10.1.3 I.D.E.A. ............................................................................................................................................ 103 10.1.4 MINI MENTAL .................................................................................................................................. 104 10.1.5 MOCA .............................................................................................................................................. 104 10.1.6 EVALUACIÓN FONOAUDIOLÓGICA 4 AÑOS A 4 AÑOS 11 MESES .......................................................... 104 10.1.7 EVALUACIÓN FONOAUDIOLÓGICA 5 AÑOS A 6 AÑOS 11 MESES .......................................................... 105 10.1.8 EVALUACIÓN FONOAUDIOLÓGICA 7 AÑOS A 12 AÑOS ........................................................................ 105 10.1.9 PROTOCOLO DE EVALUACIÓN DEL HABLA (RAFAEL GONZÁLEZ) ....................................................... 105 10.1.10 PROTOCOLO DE EVALUACIÓN DEL HABLA ....................................................................................... 106 10.1.11 S.L.A. ............................................................................................................................................. 106 10.1.12 TECAL .......................................................................................................................................... 107 10.1.13 PROTOCOLO TEVI ............................................................................................................................. 107 10.1.14 VALORACIÓN Y PROTOCOLOS TOKEN TEST ..................................................................................... 107 10.1.15 PROTOCOLO DE TEST DE WEPMAN .............................................................................................. 107 10.2 PROTOCOLOS CUALITATIVOS ...................................................................................................108 10.2.1 EVALUACIÓN DISFEMIA INFANTIL ...................................................................................................... 108 10.2.2 PROTOCOLO EVALUACIÓN MIOFUNCIONAL: ....................................................................................... 108 10.2.3 FICHA EVALUACIÓN RIESGO VOCAL .................................................................................................... 108 10.2.4 EVALUACIÓN VOCAL INFANTIL – CAROLA RIVERA ............................................................................. 109 10.2.5 EVALUACIÓN VOCAL INFANTIL, UBB ................................................................................................. 109 10.2.6 EVALUACIÓN CLÍNICA DE LA DEGLUCIÓN ........................................................................................... 109 10.2.7 PAUTA DE EVALUACIÓN PARA TARTAMUDEZ ..................................................................................... 110 10.2.8 PROTOCOLO QVV ............................................................................................................................. 110 10.2.9 PROTOCOLO DE EVALUACIÓN DE LA INSUFICIENCIA VELOFARINGEA ................................................... 110 10.2.10 EVALUACIÓN FONOAUDIOLÓGICA CLÍNICA DE LA DISFAGIA OROFARÍNGEA POST-AVE ....................... 110 10.2.11 Q-CHAT ........................................................................................................................................ 110 10.2.12 SCREENING TEST OF SPANISH GRAMMAR – S. T. S. G. (COMPRENSIVO) ........................................... 111 10.2.13 SCREENING TEST OF SPANISH GRAMMAR – S. T. S. G. (EXPRESIVO) ................................................ 111 10.2.14 S.A.F .............................................................................................................................................. 111 10.2.15 T.A.R ............................................................................................................................................. 111 10.2.16 T.D.P.E.A. ...................................................................................................................................... 112 10.2.17 TEPROSIF .................................................................................................................................... 112

11 ANEXO: DIAGNÓSTICOS DEL CECH ............................................................................................113

11.1 TRASTORNOS DEL LENGUAJE EN EL NIÑO (1-7) ..................................................................................113 11.2 TRASTORNOS DEL LENGUAJE ADULTO (8-12) ....................................................................................114 11.3 TRASTORNOS AUDIOLÓGICOS (13-15) ............................................................................................115 11.4 TRASTORNOS DE LA VOZ (16-19) ...................................................................................................116 11.5 TRASTORNOS DEL HABLA Y LA DEGLUCIÓN (20-35) ...........................................................................117

12 ANEXO: CARTA DE APROBACIÓN DE PROYECTO. ......................................................................118


5

Índice Tablas

Tabla 3. 1: Resumen de Metodologías estudiadas. ....................................................................................................... 14 Tabla 3. 2: Descripción gráfica de la Shell de VOLERE(Robertson & Robertson, 2000). ......................... 18 Tabla 4. 1: Usuarios finales del sistema. ............................................................................................................................. 23 Tabla 4. 2: Requerimiento verificar usuario .................................................................................................................... 30 Tabla 4. 3: Requerimiento crear perfil de usuario. ....................................................................................................... 32 Tabla 4. 4: Requerimiento buscar paciente. ..................................................................................................................... 35 Tabla 4. 5: Requerimiento ingresar nuevo paciente. ................................................................................................... 37 Tabla 4. 6: Requerimiento crear ficha clínica. ................................................................................................................. 39 Tabla 4. 7: Requerimiento adjuntar consentimiento informado. ......................................................................... 44 Tabla 4. 8: requerimiento programa fonoaudiológico. .............................................................................................. 46 Tabla 4. 9: Requerimiento registrar examen. .................................................................................................................. 48 Tabla 4. 10: Requerimiento Generar reporte. ................................................................................................................. 52 Tabla 4. 11: Requerimiento asignar horario a paciente. ............................................................................................ 54 Tabla 4. 12: Requerimiento mostrar agenda horaria del centro........................................................................... 56 Tabla 4. 13: Requerimiento editar registros erróneos. .............................................................................................. 58 Tabla 4. 16: Requerimiento para resguardar la información histórica. ............................................................ 60 Tabla 4. 14: Requerimiento para la visualización del sistema. .............................................................................. 62 Tabla 4. 15: Requerimiento control acceso a estudiantes. ....................................................................................... 62 Tabla 4. 17: Flujo de eventos básicos, login. ..................................................................................................................... 63 Tabla 4. 18: Flujo de eventos básicos, crear usuario. .................................................................................................. 64 Tabla 4. 19: Flujo de eventos básicos, generar reporte. ............................................................................................. 65 Tabla 4. 20: Flujo de eventos básicos, registrar paciente. ......................................................................................... 66 Tabla 4. 21: Flujo de eventos básicos, crear ficha clínica. ......................................................................................... 67 Tabla 4. 22: Flujo de eventos básicos, agregar consentimiento informado. ................................................... 68 Tabla 4. 23: Flujo de eventos básicos, listar y buscar paciente. ............................................................................. 69 Tabla 4. 24: Flujo de eventos básicos, ver ficha paciente. ......................................................................................... 71 Tabla 4. 25: Flujo de eventos básicos, agregar informe fonoaudiológico. ........................................................ 72 Tabla 4. 26: Flujo de eventos básicos, agregar historial a ficha clínica. ............................................................. 74 Tabla 4. 27: Flujo de eventos básicos, ver horario. ....................................................................................................... 75 Tabla 4. 28: Flujo de eventos básicos, reservar horario paciente. ........................................................................ 76 Tabla 4. 29: Flujo de eventos básicos, editar.................................................................................................................... 77 Tabla 4. 30: Flujo de eventos básicos, ver exámenes. ................................................................................................. 78 Tabla 4. 31: Flujo de eventos básicos, ver perfil. ............................................................................................................ 79 Tabla 4. 32: Flujo de eventos básicos, cambiar contraseña. .................................................................................... 79 Tabla 4. 33: Flujo de eventos básicos, realizar examen. ............................................................................................ 80 Tabla 4. 34: Flujo de eventos básicos, reporte agenda. .............................................................................................. 81 Tabla 4. 35: Flujo de eventos básicos, editar usuario. ................................................................................................. 82 Tabla 4. 36: Flujo de eventos básicos, logout. .................................................................................................................. 83 Tabla 4. 37: Flujo de eventos básicos, modificar horario paciente. ..................................................................... 84 Tabla 4. 38: Flujo de eventos básicos, Protocolos cualitativos. .............................................................................. 85 Tabla 4. 39: Flujo de eventos básicos, Protocolos cuantitativos. ........................................................................... 86 Tabla 4. 40: Flujo de eventos básicos, Programa fonoaudiológico....................................................................... 88 Tabla 4. 41: Flujo de eventos básicos, ingresar un objetivo. .................................................................................... 90 Tabla 4. 42: Flujo de eventos básicos, Protocolos cuantitativos. ........................................................................... 91 Tabla 4. 42: Flujo de eventos básicos, Protocolos cuantitativos. ........................................................................... 92 Tabla 4. 43: Tabla matriz de relación casos de uso con requerimientos. ........................................................ 93


6

Tabla 6. 1: Resumen esfuerzo requerido. .......................................................................................................................... 97 Tabla 9. 1: Carta Gantt. .............................................................................................................................................................. 101 Tabla 10. 1: Datos requeridos protocolo: ACE-R-Ch ................................................................................................. 102 Tabla 10. 2: Datos requeridos protocolo: L.T.P.A. ...................................................................................................... 103 Tabla 10. 3: Datos requeridos protocolo: I.D.E.A. ....................................................................................................... 103 Tabla 10. 4: Datos requeridos protocolo: Mini mental. ........................................................................................... 104 Tabla 10. 5: Datos requeridos protocolo: MoCA. ........................................................................................................ 104 Tabla 10. 6: Datos requeridos protocolo: Ev. Fonoaudiológica 4 a 4,11 años. ............................................ 104 Tabla 10. 7: Datos requeridos protocolo: Ev. Fonoaudiológica 5 a 6,11 años. ............................................ 105 Tabla 10. 8: Datos requeridos protocolo: Ev. Fonoaudiológica 7 a 12 años. ............................................... 105 Tabla 10. 9: Datos requeridos protocolo: Ev. Del Habla (Rafael González). ................................................. 105 Tabla 10. 10: Datos requeridos protocolo: Ev. Del Habla....................................................................................... 106 Tabla 10. 11: Datos requeridos protocolo: S.L.A. ........................................................................................................ 106 Tabla 10. 12: Datos requeridos protocolo: TECAL. ................................................................................................... 107 Tabla 10. 13: Datos requeridos protocolo: TEVI. ....................................................................................................... 107 Tabla 10. 14: Datos requeridos protocolo: Valoración y Protocolo Token Test. ....................................... 107 Tabla 10. 15: Datos requeridos protocolo: Test de WEPMAN. ........................................................................... 107 Tabla 10. 16: Datos requeridos protocolo: Ev. Disfamia infantil. ....................................................................... 108 Tabla 10. 17: Datos requeridos protocolo: Ev. Miofuncional. .............................................................................. 108 Tabla 10. 18: Datos requeridos protocolo: Ev. Riesgo vocal................................................................................. 108 Tabla 10. 19: Datos requeridos protocolo: Ev. Vocal Infantil (Carola Rivera). ........................................... 109 Tabla 10. 20: Datos requeridos protocolo: Ev. Vocal Infantil (UBB). ............................................................... 109 Tabla 10. 21: Datos requeridos protocolo: Ev. Clínica de la deglución. .......................................................... 109 Tabla 10. 22: Datos requeridos protocolo: Ev. Tartamudez. ................................................................................ 110 Tabla 10. 23: Datos requeridos protocolo: QVV. ......................................................................................................... 110 Tabla 10. 24: Datos requeridos protocolo: Ev. De la insuficiencia velofaringea. ....................................... 110 Tabla 10. 25: Datos requeridos protocolo: Ev. Fonoaudiológica de la disfagia orofaringea post-ave. ............................................................................................................................................................................................................... 110 Tabla 10. 26: Datos requeridos protocolo: Q-CHAT. ................................................................................................ 110 Tabla 10. 27: Datos requeridos protocolo: S.T.S.G comprensiva. ...................................................................... 111 Tabla 10. 28: Datos requeridos protocolo: S.T.S.G expresivo. ............................................................................. 111 Tabla 10. 29: Datos requeridos protocolo: S.A.F. ........................................................................................................ 111 Tabla 10. 30: Datos requeridos protocolo: T.A.R. ....................................................................................................... 111 Tabla 10. 31: Datos requeridos protocolo: T.D.P.E.A. ............................................................................................... 112 Tabla 10. 32: Datos requeridos protocolo: TEPROSIF. ............................................................................................ 112


7

Índice Figuras

Figura 3. 1: Mapa simplificado del proceso de requisitos de VOLERE. Fuente: (Robertson & Robertson, 2000). .......................................................................................................................................................................... 16 Figura 4. 1 Modelo de Caso de Uso: Estudiante. Fuente: propia del autor. ...................................................... 26 Figura 4. 2: Modelo de Caso de Uso: Administrador. Fuente: propia del autor. ............................................ 27 Figura 4. 3: Modelo de Caso de Uso: Fonoaudiólogo. Fuente: propia del autor. ........................................... 28 Figura 4. 4: Ventana de Inicio de la Aplicación. .............................................................................................................. 31 Figura 4. 5: Ingreso de usuario. ............................................................................................................................................... 33 Figura 4. 6: Lista de Usuarios registrados. ........................................................................................................................ 34 Figura 4. 7: Ventana de lista y búsqueda de pacientes. .............................................................................................. 36 Figura 4. 8: Requerimiento, Ingreso paciente. ................................................................................................................ 38 Figura 4. 9: Ventana Ficha clínica de paciente. ............................................................................................................... 41 Figura 4. 10: Ingreso de historial a paciente. ................................................................................................................... 42 Figura 4. 11: Informes Fonoaudiológicos de pacientes. ............................................................................................. 43 Figura 4. 12: Vista conocimiento informado. ................................................................................................................... 45 Figura 4. 13: Programa fonoaudiológico............................................................................................................................ 47 Figura 4. 14: Exámenes del paciente. ................................................................................................................................... 49 Figura 4. 15: Protocolo Cualitativo. ....................................................................................................................................... 50 Figura 4. 16: Protocolo Cuantitativo. ................................................................................................................................... 51 Figura 4. 17: Pantalla de Reportes. ....................................................................................................................................... 53 Figura 4. 18: Ventana de asignación de horario a paciente ..................................................................................... 55 Figura 4. 19: Horario general del CECH .............................................................................................................................. 57 Figura 4. 20: Ficha clínica visto desde el fonoaudiólogo............................................................................................ 59 Figura 4. 21: Prototipo para realzar cambios de los estados Histórico de pacientes y usuarios. ........ 61 Figura 5. 1: Modelo de datos conceptual. .......................................................................................................................... 96


8

1 INTRODUCCIÓN

La necesidad de utilizar un software para automatizar información dentro de una institución,

cada vez se hace más recurrente. Muchas compañías poco a poco, han comenzado a solicitar

el apoyo de herramientas informáticas, con el objetivo de llevar un control de la información

de forma correcta y precisa. Es por ello que el desarrollo de software ha tomado fuerza en el

último tiempo, así como otras áreas que también se involucran en el largo proceso que

conlleva la realización de un sistema informático, una de esas áreas es la Ingeniería de

Requisitos (IR). La IR nos permite establecer con el cliente, un estudio previo a la ejecución

de un proyecto, en donde se deben analizar las funciones que se deben trabajar, también

observar aquellos aspectos relevantes y fundamentales, para la ejecución exitosa de dicho

proyecto.

El Centro de Estudios de la Comunicación Humana (CECH), es un centro clínico

fonoaudiológico, de la Universidad del Bío Bío. El centro atiende a personas con alteraciones

fonoaudiológicas de manera gratuita. Con el tiempo, el aumento de pacientes y atenciones

que se realizan, han generado la necesidad de contar con un sistema que ayude a controlar el

registro de los pacientes.

En este proyecto, se realizan dos tareas principalmente. Por un lado, se desarrolla una

especificación de requisitos, que cubre las funcionalidades y necesidades solicitadas por el

CECH, para realizar un sistema de ficha clínica. Y por otro lado, se estudian diferentes

metodologías para llevar a cabo una elicitación de requisitos. Con el objetivo de seleccionar

una metodología acorde a las necesidades y condiciones del proyecto, el método escogido

viene a ser la base del desarrollo de este trabajo.

Este documento está estructurado de la siguiente manera: en el capítulo 2, encontramos una

definición y descripción de la empresa. En el capítulo 3, se hace una revisión del proyecto y

sus aspectos generales. En la capítulo 4, podemos ver la especificación de cada uno de los

requerimientos solicitados junto a sus prototipos. En el capítulo 5, vemos un análisis del

problema que se está abordando, mediante un modelado de datos. En el capítulo 6 se ve un

breve resumen del esfuerzo requerido, en el capítulo 7, aparecen las conclusiones.


9

2 DEFINICION DE LA EMPRESA O INSTITUCIÓN

2.1 Descripción de la empresa

Los antecedentes generales de la empresa son:

Nombre: Centro de Estudio de la Comunicación Humana.

Dirección: Av. Andrés Bello s/n.

Rubro: Servicio Sociales y de Salud.

Entorno:

Competencia directa: No posee, el centro es único en la provincia y la competencia

más directa, vienen siendo fonoaudiólogos particulares, pero que no alcanzan a

cubrir la cantidad de atenciones realizadas por la institución.

Cuota de mercado: Dentro de Ñuble, se estima un 5% de pacientes.

El Centro de Estudios de la Comunicación Humana (CECH), es una institución nueva, que

lleva dos años funcionando, por este motivo, aún no cuenta con la definición de una misión,

visión y objetivos del centro. Esto porque aún está en proceso de desarrollo, lo que ha

impedido formular esta información estratégica, que es necesaria.

2.2 Descripción del área de estudio

El CECH, es una clínica de la escuela de fonoaudiología de la Universidad del Bío Bío, fundada

en 2011. En el centro trabajan fonoaudiólogos y estudiantes supervisados por docentes de

la escuela, quienes brindan atención fonoaudiológica gratuita a usuarios de distintas

comunas de Ñuble.

En el Centro se evalúa, diagnostica e interviene los trastornos de la comunicación humana

que se dan en cinco áreas generales: habla, lenguaje, audición, voz y deglución.

2.3 Descripción de la problemática

El CECH, lleva operando desde el año 2011. Con el transcurso del tiempo, se ha visto un

aumento considerable en el número de pacientes, esto implica, mayor flujo de información,


10

lo que ha generado problemas para administrar de manera eficiente los datos de las

personas que se atienden. Con el incremento de pacientes, también se ve afectada el área

administrativa del CECH, porque ellos atienden a las personas de manera gratuita, para

justificar los servicios que entregan, principalmente la atención a pacientes, es necesario

realizar diversos estudios estadísticos sobre los mismos pacientes, por ese motivo, se debe

analizar la información que se ha registrado en el centro: las atenciones, el número de

pacientes existentes, patologías tratadas, ausentismo, entre otras. Por consecuencia, el mayor

número de pacientes, requiere de mayor tiempo para recaudar información, esto a la vez,

significa también, destinar mayor tiempo al análisis de los datos, que permiten generar los

informes estadísticos. Por ello, surge la necesidad de contar con el apoyo de un sistema

informático que ayude a solucionar estos problemas.

El CECH, por el hecho de ser una institución con poca trayectoria, no cuenta con sistemas

informáticos que les sean de ayuda, salvo el uso de la agenda electrónica que proporciona

Google Calendar, mediante su correo electrónico Gmail. Esta permite realizar actualmente la

reserva de horarios a los pacientes del centro de forma coordinada, pero, este es un sistema

externo al centro y en caso de algún error con dicho sistema, el CECH no tiene un control

directo sobre este, para dar solución, se depende de agentes externos, lo que significa un

problema.

Además, cabe mencionar que para el CECH, este proceso es nuevo, no existen precedentes de

otros proyectos similares, lo que da cuenta que no hay registros ni datos que sirvan de

referencia para poner en marcha este trabajo.


11

3 DEFINICIÓN PROYECTO

3.1 Objetivos del proyecto

En esta sección se darán a conocer los objetivos generales y específicos del proyecto.

3.1.1 Objetivo General

Desarrollar una elicitación de requerimientos para la estructuración de un sistema de ficha

clínica para el CECH, que permita gestionar, controlar y entregar resultados pertinentes de

los pacientes.

3.1.2 Objetivos Específicos

Para alcanzar el objetivo general de este proyecto, se debe lograr los siguientes objetivos

específicos:

Identificar la información que el CECH desea administrar y controlar con el

sistema.

Identificar cuáles son los procesos de negocios involucrados.

Buscar dentro de la literatura aquellas metodologías que sirvan para llevar a

cabo una elicitación de requisitos y seleccionar una que se acomode a las

características y necesidades del cliente.

Aplicar la metodología escogida, para poder construir el informe de

requerimientos, de manera que los futuros desarrolladores, puedan aplicar la

información recabada.

3.2 Ambiente de Ingeniería de Software

En esta sección, se presentan y explican los diferentes conceptos que se utilizan para realizar este trabajo.

3.2.1 Ingeniería de Requisitos.

La especificación de requisitos es una tarea importante a la hora de realizar cualquier

proyecto, es una de las primeras etapas por las que debe pasar el proyecto antes de su


12

ejecución, una mala captura de los requisitos puede ser fundamental a la hora de evaluar el

proyecto de exitoso o no.

El detalle de los requisitos debe ser correcto, preciso y no ambiguo, es por ello que nace la

Ingeniería de Requisitos (IR). La IR es para Sommerville: “Un proceso que comprende todas

las actividades requeridas para crear y mantener un documento de requisitos del

sistema”(Sommerville, 2002), por otra parte Loucopoulos y Karakostas definen: “la

Ingeniería de Requisitos, es el proceso de obtención de requisitos a través de un proceso

interactivo y cooperativo de análisis del problema, documentando las observaciones en una

variedad de formatos de representación y verificando la exactitud de lo

comprendido”(Loucopoulos & Karakostas, 1995).

El objetivo principal de la IR es obtener una definición clara estructurada y no ambigua para

las especificaciones correctas que demuestren el funcionamiento de un sistema, con el fin de

evitar errores en el desarrollo de algún proceso(Gallardo Arancibia, 2009).

Dentro de la IR se encuentran varios modelos de procesos, que varían según el área en la

cual se trabaja, estos modelos apuntan a las etapas de cómo llevar a cabo la elicitación de

requisitos. Para el área de Ingeniería de Software, que es el área del desarrollo de este

trabajo, las etapas fundamentales son: Elicitación, Análisis, Especificación, Validación.

Bahamonde y Rossel en (Bahamonde & Rossel, 2003) especifica las distintas etapas como

elementos.

Elicitación: es la etapa donde hay mayor interacción con el usuario y es fundamental

para la extracción de información.

Análisis: es la etapa donde se realiza la definición más técnica de la información

recaba en la etapa anterior, con el objetivo de evitar inconsistencia y ambigüedades.

Especificación: es la definición de los requerimientos con el fin de formalizar el

contenido para que sea conocido por todas las partes involucradas del proyecto.

Validación: es la etapa donde se realiza la confirmación de las etapas anteriores en

conjunto con el usuario.

Existen varios puntos de vista con respecto al desarrollo de estas etapas, entendiéndose que

existen varios modelos de procesos de IR para llevar a cabo las tareas que componen el

proceso.


13

3.2.2 Metodología para realizar la elicitación de requisitos.

En este proyecto la elección de la metodología fue motivo de estudio, dada la necesidad de

encontrar una que se adapte a las necesidades del usuario y a las características de este

proyecto. Las metodologías que se revisaron y analizaron son:

Documentación de Requisitos Centrada en el Usuario (DoRCU).

Bibliotecas.

Análisis de Requisitos Conducentes al Reúso de Artefactos (ANCORA).

Análisis de Requisitos basado en Preguntas (Inquiry Based Requirements Analisys,

IBRA).

Definición de requerimiento basado en puntos de vista (Viewpoint Oriented

Requirements Defintion, VORD).

VOLERE.

A continuación en la tabla 3.1, se muestra un resumen de las características más relevantes

de cada una de ellas.


14

Tabla 3. 1: Resumen de Metodologías estudiadas.

Metodología Descripción Etapas Tipo de metodología

Plantilla Resultados

DoRCU Documentación de Requisitos Centrada en el Usuario (Báez & Brunner, 2001).

Elicitación. Análisis. Especificación. Validación y Certificación.

Iterativa. No posee. Documento Usuario. Documento Técnico.

Biblioteca Usa Técnicas de adquisición de conocimientos, utilizando tablas decisión para capturar relación entre atributos y objetos(Richards, 2000).

Adquisición y conversión de Requisitos. Generación de Conceptos. Comparación de conceptos y detección de conflictos. Negociación. Evaluación.

Iterativa Usuario-Desarrollador.

Tabla de relación entre requisitos y usuario. “Crosstable”.

Documento en lenguaje natural.

ANCORA Análisis de Requisitos Conducentes al Reúso de Artefactos (Sumano, 2002).

Entendimiento del Dominio y contexto de la aplicación. Recolección y aplicación de requisitos. Reutilización de requisitos. Resolución de conflictos, priorización y validación. Cierre.

Cascada iterativa.

Si posee, extensas planillas y diferentes.

Pauta que se entrega al diseñador de software.

IBRA Análisis de Requisitos basados en preguntas(Potts, Takahashi, & Anton, 1994).

Especificación de requisitos, (propuesta) análisis (decisión) evaluación (cambios)

Estructura Cíclica.

Basada en el estándar IEEE.

No debe asociarse a un lenguaje de especificación o estilo de expresión.

VORD Definición de Requisitos Orientada en puntos de vista. Enfocado en puntos de vista del usuario(Kotonya, 1999).

Identificación y estructuración de los puntos de vista. Documentación de los puntos de vista. Análisis y especificación de los requisitos de puntos de vista.

Iterativo. No definida. Documento de la especificación de requisitos.

VOLERE Trabaja para la adquisición y análisis de requisitos usando dos subsistemas Shell y plantilla para requisitos (VOLERE, 2005).

Modelo de trabajo como red asíncrona donde se pueden dar combinaciones de procesos.

Jerarquía de Proceso iterativos.

Planilla de registros de requisitos.

Documentación de requisitos para el usuario.


15

En las metodologías estudiadas se ven identificados los elementos correspondientes al

Modelo de Procesos de Ingeniería de Requisitos para la Ingeniería del Software, donde se

plantea en base a las actividades de elicitación, análisis, especificación y validación de los

requisitos.

Dentro de todas las metodologías, DoRCU e IBRA tienen aspectos interesantes, puesto que

ambas se enfocan principalmente en el usuario, pero se observan puntos en contra, por

ejemplo, DoRCU no presenta una plantilla que estandarice el proceso de captura de

requisitos e IBRA trabaja en base a etapas de manera cíclica de desarrollo, lo que hace difícil

la planificación de los tiempos, porque se desconocen la cantidad de ciclos a realizar. Por otro

lado ANCORA, al ser una metodología en cascada, impide de cierta forma la

retroalimentación con el usuario, además trabaja con reutilización de requisitos, lo que en un

proyecto que está iniciando, no es factible. En tanto, las metodologías Bibliotecas y VORD. La

primera presenta aspectos evaluados como negativos en este estudio, al ocupar

herramientas técnicas que hacen complejas llevarlo a la práctica porque el usuario, no

pertenece al área informática. Por otro lado, la segunda metodología, se enfoca en puntos de

vista del usuario, y como se mencionó anteriormente, el usuario no posee conocimiento del

área informática, por lo que se descartaron estas metodologías.

Por último la metodología VOLERE, es un método que entrega un modelo de aplicación

definido para el desarrollo, contempla a los usuarios como principal agente de interacción

para realizar la elicitación de requisitos, con un formato detallado para realizar el registro de

los requisitos, dado que entrega una Shell y una plantilla para especificar los requisitos. Estas

características, han hecho que VOLERE, sea la metodología seleccionada para realizar el

levantamiento de requisitos para este proyecto.

3.2.3 Método VOLERE

VOLERE es una metodología que apareció por primera vez en el año 1995, desarrollada por

James y Suzanne Robertson. Esta metodología se enfoca en desarrollar las etapas de la

elicitación de requisitos en jerarquía de procesos y el modelo de proceso se focaliza en una

red asíncrona donde se puede desarrollar cualquier proceso, como se presenta en la figura

3.1.


16

Figura 3. 1: Mapa simplificado del proceso de requisitos de VOLERE. Fuente: (Robertson & Robertson, 2000).

Las etapas de este modelo son:

a. Proyecto Blastoff: Denominada como etapa de despegue del proyecto, donde se

realizan las primeras conversaciones con el cliente, para abordar de manera general el

proyecto que se desea llevar a cabo. Se analiza el contexto donde se realizará el proyecto,

los riesgos y los costos iniciales de este.

b. Captura de Requisitos: Esta etapa comienza una vez terminada la etapa Blastoff, y es

aquí donde se capturan los requerimientos y las necesidades de los Stakeholders, se

detallan los casos de usos del negocio asociado, para posteriormente, producir los

requisitos provisionales, en sesiones de lluvias de idea (brainstorming).

c. Etapa Prototipos de Requisitos: en esta etapa, los prototipos provisionales se muestran

gráficamente, dando a conocer los posibles escenarios que se pueden alcanzar.


17

d. Etapa Escritura de Requisitos: Etapa paralela a la generación de prototipos, es la etapa

más compleja, puesto que es donde se debe expresar el requisito solicitado por el

Stakeholder de manera clara y no ambigua. En esta etapa se realiza el uso de las plantillas

ofrecidas por VOLERE.

e. Etapa Control de Calidad: Luego de realizar las etapas de Prototipos y Escritura, se

debe pasar por la etapa de control de calidad, donde el Stakeholder en conjunto con el

ingeniero de requisitos verifican y validan uno a uno los requerimientos desarrollados

en las etapas anteriores. Sólo evalúa si el requisito cumple con los criterios definidos en

la plantilla. De aprobar el requisito, este queda documentado y especificado, para

avanzar a la siguiente etapa, de lo contrario debe volver a la etapa anterior, para repetir

el ciclo, hasta que el requisito pase el control de calidad.

f. Etapa de Revisión de Requisitos: Esta etapa es donde se revisan los requisitos en

conjunto, esta vez desde el punto administrativo y funcional para el sistema, a diferencia

del control de calidad, en esta etapa se verifica si el requisito especificado es necesario

para el negocio, si los costos de implementación son acordes al requisito y cuánto puede

influir para el sistema la existencia o ausencia del requisito en cuestión.

g. Etapa de Reúso de Requisitos: Esta etapa es previa a la captura de requisitos, acá es

donde se indaga sobre los requisitos utilizados en sistemas anteriores, los cuales nos

puedan servir para el proyecto y que pueden estar ya especificados, con el objeto de no

tener que volver a especificarlos. Claramente, esta etapa no se considera, cuando el

proyecto es nuevo.

h. Etapa de Análisis, Diseño y Construcción: Es la etapa de implementación, donde se

analiza el requisito con tal de crear el diseño pensando siempre en la construcción, para

llevar a cabo el desarrollo de los requisitos, con tal de alcanzar el producto final solicitado

por el cliente.


18

VOLERE además de su modelo posee dos subsistemas para realizar la especificación de

requisitos, la Shell y la Plantilla. La Shell, cuenta con varios componentes que se pueden ver

claramente en la Tabla 3.2, donde se presenta la estructura, formato y una breve descripción

de cada componente.

Tabla 3. 2: Descripción gráfica de la Shell de VOLERE(Robertson & Robertson, 2000).

Número

Requisito:

Se indica el

número

identificador

del requisito.

Tipo

Requerimiento:

Se basa según

el tipo de

requisito de

acuerdo con la

plantilla

Eventos /

Casos de

Uso

Se mencionan

los eventos o

casos de usos

que tienen

relación con el

requerimiento.

Descripción: Se realiza un breve descripción del requerimiento que se desarrollará

Fundamentos: Se presenta los motivos de por qué es necesario realizar.

Autor: Es quién solicita el requerimiento

Criterio: Es el registro que permite realizar una medición de exigencia de tal manera que

sea posible poner a prueba si la solución coincide con el requisito.

Satisfacción

del cliente:

Se hace un registro con una

escala de 1 a 5, donde 1 es muy

insatisfecho y 5 es muy

satisfecho, determina la

satisfacción del cliente

Insatisfacción

del cliente:

Se hace un registro con una

escala de 1 a 5, donde 1 es

poca importancia y 5 es

muy disgustado.

Prioridad: Se realiza un registro donde se

especifica si el requisito es de

prioridad: Alta, Media o Baja.

Conflictos: Se mencionan los otros

requerimientos que pueden

tener conflictos con el

requerimiento que se está

tratando.

Materiales de Soporte: Se registra información de información externa, que permita

desarrollar de mejor forma el requisito

Historia: Se registra la fecha de la creación, modificaciones o cambios que se han hecho en

el requisito.

A continuación se describirán los componentes de la Shell, presentados en la tabla 3.2.


19

Número de Requisito: Es el código identificador único del requisito, con la intención

de tener fácil y rápido acceso al requisito.

Tipo de Requisito: Indica el número según la sección a la que corresponde el

requisito basado en la plantilla.

Evento/Caso de Uso: Es el número del caso de uso o evento con el que se relaciona

el requisito.

Descripción: Se realiza una descripción breve y general del requisito.

Fundamento: Se registran los motivos de porque es importante y necesario realizar

el requisito, con el fin de que las personas que lo vean, entiendan la real importancia

y sentido que tiene el requisito.

Autor: Es el registro de quién o quiénes solicitaron el requisito.

Criterios: Es el ítem que permite definir si el requisito cumple lo solicitado de

manera adecuada.

Satisfacción del Cliente e Insatisfacción del Cliente: Estos campos muestran el estado

del cliente, a la hora de verificar si el requisito se llevó a cabo o no, donde la

satisfacción indica que tan satisfecho quedará el cliente con la implementación del

requisito. Por otra parte el campo de insatisfacción del cliente, indica que sentirá el

cliente si el requisito no se lleva a cabo. Los índices deben ser altos si el requisito es

importante, dado que eso significa que el cliente quedará muy satisfecho por el

desarrollo y quedará muy disgustado si es que no se desarrolla el requisito.

Prioridad: Indica que tan necesario es realizar el requisito para el sistema, con el fin

de saber la importancia que tiene.

Conflictos: Se detallan todos aquellos requisitos que presentan un problema para el

desarrollo del requisito que se está especificando.

Materiales de soporte: Este es un registro de información que apuntan a otros

materiales de información, que sean relevantes para el requisito.

Historia: Se guarda el historial de los cambios efectuados al requisito.

Por otra parte, la planilla de VOLERE se divide en los siguientes puntos:

Guías del Proyecto: se define el propósito del proyecto, definen los clientes,

Stakeholder y los usuarios involucrados en el sistema.

Restricciones del Proyecto: Se describen e identifican las restricciones del proyecto,

centrándose en las de tipo técnico y económico.


20

Requisitos Funcionales: Son los requisitos primordiales del producto y deben ser

medibles por métodos concretos.

Requisitos no funcionales: Son aquellos que poseen propiedades las cuales son

difíciles y complejas de cuantificar.

Aspectos del negocio: Se describen los factores que pueden influir en el desarrollo

del negocio a la hora de lograr el éxito o el fracaso del proyecto.

En este proyecto se realizará una aplicación modificada a la plantilla VOLERE, dado que este

método se utiliza para el desarrollo completo de una aplicación y para este caso sólo se

realizó hasta la etapa de revisión de requisitos, es por ello que se hizo cambios y se

extrajeron aquellas partes que no cumplen con lo que esta etapa solicita. Las etapas que no

fueron consideradas para este trabajo: “reúso de requisitos” y “análisis, diseño y

construcción”, la primera no fue considerada por no existir, ningún sistema previo. La

segunda es porque este proyecto sólo aborda el levantamiento de requerimientos, no el

desarrollo de la aplicación.

3.2.4 Herramientas y tecnologías a utilizar

Balsamiq Mockups: Es un software que permite realizar el esquema de una página

o aplicación, en este caso, se utilizó para desarrollar los prototipos del sistema.

3.3 Definiciones, Siglas y Abreviaciones

Box: Sala, lugar físico donde se atienden los pacientes en el centro, de momento, sólo existen

4 en el CECH.

Crosstable: También se conoce como tabulación cruzada, es una tabla que permite registrar

información, la cual puede ser tabulada y se utiliza para obtener datos estadísticos.

Estudiante: equivalente a interno, en el texto se utilizan ambos conceptos, con el fin de

evitar las redundancias.

Google Calendar: Es una agenda y calendario electrónico desarrollado por Google. Permite

compartir un calendario y así pueden interactuar varios usuarios dentro de este mismo,

además los usuarios pueden editar la información, siempre que tengan los permisos.


21

IEEE: Siglas que significa Institute of Electrical and Electronics Engineers, que corresponde

en español Instituto de Ingenieros en Electricidad y Electrónica.

Instrumento de Evaluación: Se denomina al conjunto de protocolos que se aplican a un

paciente para obtener la evaluación médica de dicho paciente.

Interno: Equivalente a estudiante de la carrera de fonoaudiología, es quien realiza práctica

en el CECH.

Protocolos: Denominación que se da en el CECH, a los procedimientos que permiten

descubrir una patología del paciente, equivalente a un examen médico.

Proyecto Blastoff: Es la primera etapa del proyecto donde se reúnen los desarrolladores,

clientes y usuarios para definir el contexto, propósito del proyecto, los riesgos principales,

estimación inicial de esfuerzo, identificación de los interesados, se definen grupos de trabajo,

etc.

Rotación: Se le denomina al cambio de estudiantes que se realiza en el CECH, cada dos

meses, dado que es el tiempo de práctica que realizan los internos en el centro.

Shell: Se denomina a una interfaz que permite a los usuarios realizar actividades o tareas de

manera más fácil y ordenada.

Stakeholders: “Quienes pueden afectar o son afectados por las actividades de una

empresa”1.

1 Freeman, R. E. (1984). Strategic planning: A stakeholder approach. Boston: Pitman.


22

4 ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE

A continuación, en este capítulo, se presenta el desarrollo de cada etapa que se llevó a cabo

para realizar la elicitación de requisitos.

4.1 Etapa: Proyecto Blastoff

La primera etapa comenzó coordinando una reunión con el cliente, en la cual se habló acerca

de las necesidades y objetivos que se quieren alcanzar con este proyecto, los cuales son, crear

un sistema de ficha clínica para los pacientes del CECH. Luego, se prosiguió a la

estructuración de un plan de trabajo, en donde se acordó realizar reuniones periódicas

semanalmente. En un segundo encuentro, realizado en las dependencias del centro, se

observó la situación actual del centro y se discutió acerca de las actividades que se realizan

en el CECH.

Se deben definir dentro del contexto general, los costos iniciales y los riesgos analizados,

para llevar a cabo este proyecto, dentro de esos términos no encontramos con:

- La necesidad de incorporar equipamiento computacional, ya sean computadores, un

escáner y una impresora.

- Una conexión a una red de internet.

- Un servidor web que permita almacenar la aplicación a desarrollar.

- Este es un proceso nuevo para la empresa, por lo que su implementación puede

generar algún impacto negativo en los usuarios que lo utilizarán.

4.1.1 Propósito del Proyecto

Este proyecto, es una etapa para desarrollar una aplicación web que permita realizar un

sistema de control de ficha clínica para el CECH. Sólo se contempla el levantamiento de

requisitos y la demostración de prototipos del sistema. Para cumplir el propósito, se debe

entregar un documento, con el detalle de las funciones y tareas que debe hacer el sistema, las

que debieron ser solicitadas por el cliente, para que pase posteriormente, a la siguiente

etapa de diseño y desarrollo donde se lleve a cabo la implementación.


23

4.1.2 El Cliente.

En este proyecto, solamente cuenta con un cliente directo, y es con quien se realiza el

desarrollo del levantamiento de requisitos. El profesor de fonoaudiología de la Universidad

del Bío Bío, el Señor Rodolfo Peña Chávez, es él, quien solicita, valida y aprueba los

requerimientos.

4.1.3 Usuarios del producto

Los usuarios del producto final los podemos ver en la Tabla 4.1:

Tabla 4. 1: Usuarios finales del sistema.

Nombre/Categoría Rol Experiencia

sobre el tema

Experiencia

tecnológica

Prioridad

Administrador Administrar el

funcionamiento del sistema.

Profesional Competente Clave

Fonoaudiólogo Usuario limitado del sistema

con facultad de realizar

ingreso y edición de la

información

correspondiente a sus

permisos.

Profesional Competente Clave

Interno/Estudiante Usuario limitado del sistema

con facultad de realizar

ingreso de la información

correspondiente a sus

permisos.

Competente Competente Clave

4.2 Restricciones Obligatorias del Proyecto

En esta sección se indican las restricciones que debe tener el proyecto, con tal de

proporcionar información suficiente para que los diseñadores tengan presente las

condiciones que se deben cumplir, para satisfacer al cliente.


24

4.2.1 Restricciones Obligatorias.

El software para que sea factible, debe cumplir ciertos requerimientos obligatorios,

solicitados por el cliente. Sin estos requisitos el producto final, será incompleto y no cumplirá

el objetivo, por el cual se está desarrollando.

El producto final debe ser una aplicación web, capaz de almacenar la información completa

de un paciente, esto quiere decir que debe contener los datos personales, datos clínicos,

informes fonoaudiológicos y protocolos aplicados al paciente. Además toda la información

debe ser administrada por personas autorizadas. El objetivo es eliminar la actual ficha

clínica del centro que se trabaja en forma manual.

El producto final debe permitir coordinar la reserva de horas para la atención de los

pacientes. El objetivo es administrar el calendario dejando de lado el uso de sistemas

externos al centro.

El sistema debe entregarnos información automatizada de los pacientes, para obtener datos

estadísticos que permitan crear informes de las actividades realizadas a los pacientes del

centro.

4.2.2 Ambiente de implementación del sistema actual

Esta restricción, indica el ambiente que debe existir para llevar a cabo este proyecto, el

centro debe contar con un computador por box, con conexión a internet, además deben estar

conectados a una impresora y a un escáner, para poder imprimir información o cargarla

mediante un registro tomado desde un escáner.

4.2.3 Restricciones cronológicas

La única restricción, surgida de este tipo, hace referencia a los usuarios registrados como

interno, estos usuarios solamente deben tener acceso al sistema, durante el horario

establecido por el cliente, con el fin de que la información de los pacientes sea vista

solamente en el centro y no fuera de él.


25

4.3 Etapa: Captura de requisitos.

Si bien, la captura de requisitos, comienza desde el primer contacto con el cliente, es en esta

etapa en donde comienza la documentación más detallada de esos requisitos, que se han

abordado de manera general en la etapa anterior.

La etapa se construye, luego de diversas reuniones con el cliente, donde éste realiza el listado

de las necesidades que se solicitan para la construcción del producto final. Junto a esto se

proponen ideas para lograr consensos y comenzar a detallar en el documento los

requerimientos formalmente.

La especificación de estos requisitos se realiza, de conversaciones donde se extraen los

detalles que índica el cliente, para luego desarrollar la escritura en la Shell, siguiendo la

plantilla, en paralelo con el prototipo y los casos de usos referentes a ese requerimiento. De

esta forma se hace un trabajo cíclico con cada requerimiento tratado, como se presenta en el

mapa simplificado de proceso, visto anteriormente (figura 3.1).

4.3.1 Alcances del Producto

Los alcances del producto, se enfoca en el diagrama de casos de uso, de esta forma, conocer la

relación de los usuarios con respecto al producto. También sirve para decidir cuáles de estos

casos de usos son apropiados que se deben desarrollar en la aplicación.


26

A continuación, en la figura 4.1, se presenta el modelo de casos de uso, donde se describen las

funcionalidades del producto para el actor estudiante.

Figura 4. 1 Modelo de Caso de Uso: Estudiante. Fuente: propia del autor.


27

Siguiendo con el esquema, en la figura 4.2, se muestra el modelo de casos de uso, donde se

describen las funcionalidades del producto para el actor administrador.

Figura 4. 2: Modelo de Caso de Uso: Administrador. Fuente: propia del autor.


28

Para finalizar con el diagrama de casos de uso, en la figura 4.3 se presenta el esquema, donde

se describen las funcionalidades del producto para el actor estudiante.

Figura 4. 3: Modelo de Caso de Uso: Fonoaudiólogo. Fuente: propia del autor.

En la figura 4.1, 4.2 y 4.3 se aprecian 3 actores, que fueron descritos en la sección 4.1.3.

4.4 Etapa de escritura y prototipos de requisitos

En esta etapa se desarrolla la escritura de los requisitos basados en la documentación de VOLERE. También se presenta en paralelo al requisito, el prototipo que exprese de manera gráfica el requerimiento que se está desarrollando. Posteriormente, se realiza la descripción de los casos de usos asociados a cada requerimiento, todo este desarrollo siguiendo el proceso cíclico de VOLERE.


29

4.4.1 Requerimientos Funcionales

Los requerimientos funcionales son aquellos que poseen un criterio de aceptación o de

prueba con tal que los clientes puedan comprobar si el requisito se ha cumplido o no.

VOLERE define los requisitos funcionales como: “los sujetos fundamentales o esenciales que

constituyen la médula del producto. Ellos describen lo que el producto tiene que hacer o

cuáles acciones de procesamiento debe tomar”2 .

Ahora veremos los requerimientos funcionales que se registraron utilizando la Shell de

VOLERE y el(los) respectivo(s) prototipo(s) para ejemplificar el requerimiento descrito en la

Shell.

2 James & Suzanne Robertson (2006). Volere. Plantilla de especificación de requisitos. Edición 11.


30

1. Autorizar ingreso a usuario

Tabla 4. 2: Requerimiento verificar usuario

Requerimiento: RF01 Tipo

Requerimiento:

Acceso Eventos /

Casos de Uso

CU01, CU20

Descripción: El sistema verifica, sólo a aquellos usuario que estén registrados.

Fundamentos: La información de los pacientes debe ser protegida para cualquier agente

externo al sistema, por lo que se debe verificar quién ingresa al sistema y saber

quién trabaja la información.

Autor: Rodolfo Peña

Criterio: El usuario al ingresar al sitio, debe identificarse, para ello ingresa su correo

electrónico y su contraseña.

El sistema debe ser capaz de diferenciar el tipo de usuario que está entrando en

el sistema, un usuario no puede poseer dos perfiles de usuario.

El sistema debe avisar si el usuario no ha sido registrado, no ha ingresado algún

campo o los datos ingresados son incorrectos, impidiendo el ingreso al sistema.

El sistema debe dar una opción de reenviar la contraseña al correo de contacto

del usuario, en caso de que el usuario olvido la contraseña.

El sistema debe dar la opción de cerrar la sesión en cualquier momento, si se está

editando alguna información, el sistema debe preguntar si desea cerrar sin

guardar o cancelar la opción de salida de sistema.

Satisfacción del cliente: 5 Insatisfacción de los clientes: 4

Prioridad: Alta Conflictos

Materiales de Soporte

Historia: 23-10-2013


31

A continuación en la figura 4.4, podemos apreciar la Ventana Inicio de la aplicación, esta

ventana permite la opción de identificarse mediante el correo y contraseña, para poder

ingresar al sistema, también muestra un link en caso de que un usuario olvidó la contraseña,

esta es enviada al correo.

Figura 4. 4: Ventana de Inicio de la Aplicación.

Olvido contraseña


32

2. Crear perfil de usuarios

Tabla 4. 3: Requerimiento crear perfil de usuario.

Requerimiento: RF02 Tipo Requerimiento:

Funcional. Eventos / Casos de Uso

CU02, CU19

Descripción: El sistema ofrece al administrador la opción de crear tres perfiles de usuario diferentes.

Fundamentos: El sistema será utilizado para registrar información de pacientes atendidos, el ingreso de dicha información puede ser suministrada al sistema por fonoaudiólogos profesionales, como por estudiantes de fonoaudiología, por ello se requiere hacer diferencias. Además de proteger el sistema de agentes externos.

Autor: Rodolfo Peña. Criterio: El administrador del sistema es el encargado de gestionar las cuentas de usuario,

para ello el administrador debe estar autentificado en el sistema mediante su nombre de usuario y contraseña. El administrador posee las opciones de crear, editar o eliminar un usuario. El administrador puede crear tres tipos diferentes de usuario: un nuevo administrador, un fonoaudiólogo y un estudiante. El administrador al crear un usuario debe seleccionar el tipo de usuario que creará y registrar para cualquiera los siguientes datos:

- Nombres. - Apellido Paterno. - Apellido Materno. - RUN. - Correo electrónico. - Asignar una contraseña por defecto.

Siendo estos campos obligatorios que permitan ingresar un máximo de 32 caracteres, salvo el correo electrónico que por estándar internacional permite 320 caracteres. Por otra parte la única excepción la tiene el estudiante con un campo extra, donde se indique el número entero positivo de la rotación a la que pertenece del CECH. El perfil de administrador, otorga permisos para acceder a toda las funciones del sistema. El perfil estudiante tiene acceso a las funcionalidades que se relacionan con el paciente, pero no puede editar la información ya registrada, sólo puede agregar. Para editar información el estudiante debe informar a un fonoaudiólogo para que realice los cambios. El perfil fonoaudiólogo tiene acceso a las mismas funcionalidades que el estudiante, con la diferencia que estos si pueden editar información almacenada. El sistema debe mostrar todos los usuarios registrados y dar la opción al administrador para corregir algún dato de un usuario, salvo su identificación y su contraseña.

Satisfacción del cliente: 5 Insatisfacción de los clientes: 5 Prioridad: Alta Conflictos: Usuario con dos perfiles. Materiales de Soporte Historia: 23-10-2013


33

A continuación se presentan las pantallas para el perfil de administrador, en la figura 4.5 se

puede ver el ingreso de un nuevo usuario.

Figura 4. 5: Ingreso de usuario.


34

Luego el administrador puede revisar los usuarios registrados, como se ve en la figura 4.6.

Figura 4. 6: Lista de Usuarios registrados.


35

3. Buscar Paciente

Tabla 4. 4: Requerimiento buscar paciente.


Funcional Eventos / Casos de Uso

CU07

Descripción: El sistema permite a los usuarios buscar un paciente. Fundamentos: A medida que aumentan los pacientes, será más compleja la localización dentro

del sistema de éste. Encontrar un paciente de forma automática ayuda a ahorrar tiempo.

Autor: Rodolfo Peña Criterio: Se debe entregar una opción de búsqueda de pacientes, la cual permita acceder a

un usuario registrado, ya sea por su número de RUN, nombre, apellido, número de ficha. De no existir el paciente, se debe indicar que el paciente buscado no se encuentra en los registros. Una vez encontrado, debe permitir el acceso a la ficha clínica de este.

Satisfacción del cliente: 5 Insatisfacción de los clientes: 4 Prioridad: Alta Conflictos No posee Materiales de Soporte Historia: 23-10-2013


36

En la siguiente figura 4.7 se presenta el listado de pacientes que están registrados en CECH,

debe permitir, realizar filtros de estos y una opción para buscar de manera rápida algún

paciente, ya sea por nombre, apellido, Rut o número de Ficha, se supone que la tabla sólo

debe mostrar las coincidencias de la búsqueda.

Figura 4. 7: Ventana de lista y búsqueda de pacientes.


37

4. Ingresar un nuevo paciente

Tabla 4. 5: Requerimiento ingresar nuevo paciente.


funcional Eventos / Casos de Uso

CU04

Descripción: El sistema permite ingresar un nuevo paciente. Fundamentos: La principal función del sistema es automatizar la información de los pacientes,

es por ello que se hace necesario, crear la instancia para agregar nuevos pacientes al sistema.

Autor: Rodolfo Peña. Criterio: El paciente debe ser ingresado por un estudiante (interno) o un fonoaudiólogo

registrado en el sistema. Antecedentes de Identificación, es donde se registran los siguientes datos:

a) Número de ficha: único para el paciente y automático. b) RUN: Rol único nacional del paciente. c) Nombres. d) Apellido Paterno. e) Apellido Materno. f) Fecha de nacimiento. g) Edad de ingreso del paciente al centro. h) Edad actual: calculada a partir de la fecha de nacimiento. i) Procedencia: Lugar del que fue derivado. j) Motivo de Consulta: párrafo que indique el por qué llegó el paciente. k) Dirección: lugar de residencia del paciente. l) Años de estudios. m) Fecha de ingreso: fecha de la primera atención. n) Nombre del Evaluador: registro del interno o fonoaudiólogo que lo

atendió. Los usuarios deben ingresar la información solicitada por el sistema para la creación de un paciente, RUN, Fecha de Nacimiento, edad, edad de ingreso, pueden ser campos en blanco, dado que existen pacientes que desconocen esa información. El resto de los campos deben estar completados.

Satisfacción del cliente: 5 Insatisfacción de los clientes: 5 Prioridad: Alta Conflictos Un paciente cuente con 2

fichas clínicas. Existe la opción de registrar un paciente sin datos personales como RUN, fecha de nacimiento, (bebes recién nacidos, indigentes), y que en una nueva atención lleguen con una identificación y se realice una nueva ficha a una misma persona.

Materiales de Soporte No posee Historia: 23-10-2013


38

En la siguiente figura 4.8, se presenta una pantalla donde el estudiante o fonoaudiólogo

selecciona ingresar un paciente y se muestra el formulario para el ingreso de un nuevo

paciente.

Allí se deben ingresar los datos del paciente, pero la edad actual, la fecha de evaluación y el

número de ficha son datos que debe entregar el sistema de forma automática.

Figura 4. 8: Requerimiento, Ingreso paciente.


39

5. Crear ficha clínica

Tabla 4. 6: Requerimiento crear ficha clínica.



CU05, CU08, CU09, CU10, CU26

Descripción: Crear un ficha clínica única y que este asociada a un único paciente. Fundamentos: El CECH necesita almacenar el historial de actividades que se realizan a un

paciente, de modo que en una futura sesión del paciente, se conozca los tratamientos que ya se le han aplicado.

Autor: Rodolfo Peña. Criterio: Cuando se ingresa un nuevo paciente al sistema, éste de manera automática crea

una nueva ficha clínica, la que se encargará de llevar el registro de cada sesión. En la ficha clínica se debe ingresar uno o varios diagnósticos que se obtienen una vez hecho los exámenes, estos están determinados y poseen un código y nombre. (Ver Anexo 11). Debe permitir visualizar el documento de consentimiento informado, firmado por el paciente, el cual debe ser escaneado y subido al sistema. Si no posee, debe dar la opción de subir el documento al sistema. Debe registrar el día de atención y la hora de inicio de la sesión con el paciente, también la hora y día de la próxima sesión. Se debe permitir realizar una evaluación del paciente para realizar un programa fonoaudiológico. El programa fonoaudiológico, consiste en definir un plan de trabajo para un paciente. Este plan consiste en alcanzar un objetivo general, para ello, este objetivo general, se divide en varios específicos, los cuales están compuestos por objetivos operacionales, que son simplemente tareas a desarrollar con un paciente. Los objetivos operacionales, indican el desarrollo de una terapia y se registrar en el sistema, a través de las sesiones. Se debe mostrar el historial de las sesiones que ha realizado el paciente, dentro de esa muestra se debe contemplar:

- Número de sesión: número (valor entero) que indica la cantidad de sesiones que se han realizado.

- Fecha: se ingresa la fecha (formato fecha) de cuando se realizó el registro. - Objetivos Operacionales: área de texto (1200 caracteres) que permita dos

opciones, una es que permita ingresar un párrafo, tomado de la selección de un objetivo operacional seleccionado y la segunda es, en el caso de que no sea un tratamiento operacional, debe permitir ingresar el valor de: evaluación del paciente.

- Descripción de la(s) actividad(es): cuadro de texto (1200 caracteres) que se presentan las actividades llevadas a cabo por el fonoaudiólogo.

- Logro esperado: es un valor significativo que se desea alcanzar en la sesión de acuerdo al objetivo. Puede ser un porcentaje, un valor dicotómico, entre otros.

- Logro Obtenido: es el valor real, acorde al objetivo planteado. Debe ser consistente con el valor de logro esperado.

- L, D, NL: siglas que significan Logrado (L), en Desarrollo (D), No Logrado (NL) las cuales determinan la calificación que el paciente obtiene en la sesión realizada.


40

- Observaciones: un cuadro de texto (1200 caracteres) donde se registra información adicional a la sesión.

- Interno: muestra el nombre completo del estudiante o fonoaudiólogo quien realizó la sesión.

- Fecha edición: muestra la última fecha (formato fecha) que se ha editado. - Fonoaudiólogo: muestra el nombre completo del fonoaudiólogo que realizó

la edición. - En conjunto con la información antes mencionada, se debe dar la opción

para crear un programa terapéutico, donde se definan los objetivos generales, específicos y operacionales, que se deben aplicar en la terapia del paciente.

- En la ventana de Ficha clínica debe estar la opción para registrar un instrumento de evaluación (protocolo), este debe permitir elegir algún protocolo de los presentados en el anexo 10, para ingresarlos al sistema. Cada nuevo historial que se agregue debe llevar el número de la sesión que le corresponde. Adjunto a toda la ficha clínica, debe tener asociado un informe fonoaudiológico que realizan los estudiantes, los cuales deben subir al sistema y este tiene que poder ser visualizado por los demás usuarios, es necesario que además del informe quede registrado quién lo subió y en qué fecha.

Satisfacción del cliente: 5 Insatisfacción de los clientes: 5 Prioridad: Alta Conflictos No posee Materiales de Soporte Anexo 10 y Anexo 11 Historia: 23-10-2013


41

En la siguiente figura 4.9, se puede ver el prototipo de la ficha clínica de un paciente

seleccionado.

Figura 4. 9: Ventana Ficha clínica de paciente para el estudiante.

La figura 4.9, se puede dividir en dos partes, una que posee información del paciente (parte

superior) y otra sección, que posee un cuadro con pestañas, donde se muestran tablas

dinámicas de información (parte inferior). En la primera parte podemos ver tres opciones,

agregar consentimiento informado, la que nos permite buscar un archivo y almacenarlo en el

sistema. Ingresar uno o varios diagnósticos, asignar o modificar un horario de atención al

paciente.


42

En la segunda parte, se pueden observar una sección de registro que se divide en cuatro

partes: Historial paciente, Programa fonoaudiológico, Instrumentos fonoaudiológicos,

Informe Fonoaudiológico. En historial paciente, nos encontramos con una tabla que indica la

historia clínica del paciente, además nos da la opción de agregar un nuevo historial, el

formulario que se ve en la figura 4.10, se puede acceder desde 2 partes diferentes, el primero

es de manera directa, escogiendo la opción nuevo registro de la figura 4.9, la que nos

indicará que se está realizando una atención evaluativa al paciente, la otra opción es

mediante la selección de un objetivo operacional, que será revisado más adelante.

Figura 4. 10: Ingreso de historial a paciente.


43

Al seleccionar la cuarta pestaña, “Informe fonoaudiológico”, se presenta una nueva tabla que

muestra los informes fonoaudiológicos que se le han realizado al paciente, en esta pestaña,

existe la opción de subir un nuevo informe al paciente, como se muestra en la figura 4.11:

Figura 4. 11: Informes Fonoaudiológicos de pacientes.


44

6. Agregar consentimiento informado a la ficha clínica del paciente.

Tabla 4. 7: Requerimiento adjuntar consentimiento informado.



CU06

Descripción: El sistema permite agregar adjunto a la ficha clínica del paciente, una copia digital del documento de consentimiento informado.

Fundamentos: El consentimiento informado es un contrato que firma el paciente, para que los fonoaudiólogos y estudiantes puedan realizar las terapias bajo el consentimiento del paciente. Puede darse el caso que en la primera sesión no se registre el consentimiento informado, pero en una segunda sesión debe ingresarse a la ficha. Si en una tercera instancia donde el paciente acude por una atención y no posee consentimiento informado el sistema no debe permitir que se tenga acceso a la ficha clínica del paciente, sólo debe permitir adjuntar el consentimiento informado del paciente.

Autor: Rodolfo Peña Criterio: El consentimiento informado es un documento impreso que debe proporcionar

el sistema para que sea firmado por el paciente.

El conocimiento informado debe estar adjunto a un paciente. El sistema debe proporcionar la relación del documento con el paciente de forma directa.

El documento original debe ser escaneado para poder cargarlo en la ficha clínica del paciente en el sistema.

Todo documento informado debe estar asociado a un paciente previamente registrado en el sistema.

Satisfacción del cliente: 5 Insatisfacción de los clientes: 3 Prioridad: Alta Conflictos No contar con el hardware

para escanear el documento y no poder acceder a la ficha clínica del paciente.

Materiales de Soporte Historia: 13-11-2013


45

En la figura 4.12, se visualiza el documento de Consentimiento Informado, con los datos del

paciente y la firma,

Figura 4. 12: Vista conocimiento informado.


46

7. Agregar programa fonoaudiológico a ficha clínica

Tabla 4. 8: requerimiento programa fonoaudiológico.


Requerimiento:

Funcional Eventos /

Casos de Uso

CU24,CU25

Descripción: El sistema permite crear un programa fonoaudiológico.

Fundamentos: Luego de realizar una revisión a un paciente, el estudiante o el fonoaudiólogo

debe crear el programa fonoaudiológico, de esta forma la próxima vez que se

atienda a dicho paciente se sepa qué es lo que está pendiente por hacer y qué es

lo que se realizó


Criterio: El programa cuenta con la descripción de objetivos generales, los cuales se

desarrollan en base a varios objetivos específicos, a su vez los objetivos

específicos, poseen objetivos operacionales, que son aquellos que se realizan en

una atención terapéutica a un paciente, cuando se cumplen todos los objetivos

operacionales el objetivo específico se cumple, una vez realizado todos los

objetivos específicos, el objetivo general está concluido.

Para desarrollar esto, se deben mostrar los objetivos generales, al momento de

seleccionar un objetivo general se desplieguen los objetivos específicos, y luego

al seleccionar un objetivo operacional, nos envíe al ingreso de un nuevo historial

del paciente, para desarrollar dicho objetivo.

A la vez es importante señalar la cantidad de objetivos completados y

pendientes, para controlar cuantas terapias y sesiones hacen falta para alcanzar

dichos objetivos.


Prioridad: Alta Conflictos: No posee.




47

Al seleccionar la segunda pestaña de la ficha clínica, “programa fonoaudiológico”, permite

agregar un objetivo general, luego los objetivos específicos de ese objetivo general que a su

vez contienen uno o varios objetivos operacionales, los cuales permiten seguir la

programación creada para ese paciente y se puede registrar una sesión a partir de la

aplicación de dicho objetivo, en la siguiente figura 4.13, se ve que existe la opción de crear

nuevos objetivos o aplicar estos objetivos.

Figura 4. 13: Programa fonoaudiológico.


48

8. Aplicar instrumento de evaluación

Tabla 4. 9: Requerimiento registrar examen.



CU14, CU17, CU22, CU23

Descripción: El sistema permite registrar la información de un instrumento de evaluación aplicado a un pacientes

Fundamentos: El tratamiento de los pacientes, se basa principalmente en el desarrollo de actividades que permitan avanzar en la recuperación. Los exámenes que se aplican permiten identificar además de una patología, nos permiten controlar la evolución de esta, si hay avances o retrocesos, por ello es importante tener el registro de cada uno que se aplique.

Autor: Rodolfo Peña Criterio: El sistema debe permitir registrar el resultado de un protocolo aplicado a un

paciente. Para ello debe entregarnos información de que protocolos existen y el detalle de estos. Realizado un análisis a los protocolos se pueden obtener dos clasificaciones generalizadas: protocolos cuantitativos y protocolos cualitativos, los primeros son los que se pueden automatizar, debido a que son pruebas que entregan un puntaje una vez finalizado el desarrollo, esto permite obtener un resultado para calcular un diagnóstico, dado las respuestas entregadas por el paciente y por otra parte están los protocolos que sólo requieren de un ingreso de información que analiza el interno o fonoaudiólogo una vez realizado el protocolo. El protocolo cuantitativos consta de:

- Nombre: nominación por la que se conoce el protocolo. - Conclusión: Detalles del desarrollo del protocolo (1200 caracteres). - Observación: Apreciación personal del paciente. (1200 caracteres). - Puntaje total: valor numérico que se obtiene de los pacientes una vez

terminado la aplicación del protocolo. - Diagnóstico: valor obtenido según el puntaje total obtenido. - Descripción: Breve descripción relevante del protocolo. - Fecha: cuando se aplicó el protocolo.

El protocolo cualitativo sólo contiene: Nombre, fecha, descripción, observaciones y conclusiones. Estos mantienen la misma estructura que los cuantitativos, salvo que los datos ingresados, son netamente de apreciación del usuario quien está registrando los datos. En el anexo 10, se especifica detalladamente el nombre y la información que se debe recoger de cada protocolo.

Satisfacción del cliente: 5 Insatisfacción de los clientes: 3 Prioridad: Alta Conflictos Existen protocolos que

requieren la edad para calcular un diagnóstico, como existe la posibilidad de ingresar pacientes si este dato, habrán problemas.

Materiales de Soporte Ver anexo 10. Historia: 21-11-2013


49

Relacionada con la ficha clínica, en la tercera pestaña nos encontramos con los protocolos, en

esta sección se registran los resultados de los protocolos una vez aplicado a un paciente,

figura 4.14.

Figura 4. 14: Exámenes del paciente.


50

De manera generalizada se puede visualizar el formulario para un protocolo de tipo

cualitativo, como se ve en la figura 4.15.

Figura 4. 15: Protocolo Cualitativo.


51

En la figura 4.16. Se aprecia el formulario para registrar un protocolo cuantitativo, a

diferencia de la anterior, esta requiere de más información, para registrar el puntaje

obtenido después de haber aplicado un protocolo y el sistema con la información entregada

debe dar una respuesta.

Figura 4. 16: Protocolo Cuantitativo.


52

9. Generar reporte estadístico

Tabla 4. 10: Requerimiento Generar reporte.



CU03

Descripción: El sistema debe entregar información de las atenciones que se realizan en el CECH.

Fundamentos: El CECH ofrece servicios de forma gratuita, por lo que requieren el desarrollo de información estadística que les permita justificar su labor.

Autor: Rodolfo Peña Criterio: El sistema debe entregar un reporte estadístico anual, mensual y/o diario, con

información relevante para el centro, además de gráficos que sirvan de apoyo visual a la interpretación de los datos. Los datos requeridos para analizar son:

- Número de usuarios atendidos: cantidad de pacientes de los que se tiene registro.

- Número de atenciones realizadas: cantidad total de atenciones que se realizan según el rango de fecha.

- Grupo etario atendido: se presenta un gráfico de barra, donde se utiliza la información propuesta por el Departamento de Estadísticas e informaciones en Salud, que entrega un lista con rango de edades y se debe indicar la cantidad de personas que hay dentro de ese rango de edad.

- Sectores de Residencia involucrados: en una gráfico circular, donde se registra cuantos pacientes hay por las comunas de la provincia.

- Número de pacientes por Diagnóstico: gráfico de barra, que muestra por cada diagnóstico, la cantidad de pacientes que sufren dicha patología.

- Número de atenciones por diagnóstico: gráfico de barra que muestra cuantas atenciones se han realizado de las patologías, dentro del rango de la fecha.

- Lugar de derivación de los pacientes: gráfico circular, con cuantos pacientes han sido derivados bajo el mismo motivo.

- Tipo de terapia realizada: Gráfico de barra con la información de cuantas evaluaciones y tratamientos se han realizado dentro del rango de fecha.

- Ausentismo de pacientes: número de inasistencias de pacientes. - Pacientes atendidos por fonoaudiólogo o interno: gráfico de barra

que indica cantidad de atenciones de cada interno y fonoaudiólogo. Satisfacción del cliente: 5 Insatisfacción de los clientes: 5 Prioridad: Alta Conflictos Falta estandarizar algunos

campos, como el Lugar de derivación. Esto dificulta el procesamiento de la información.



53

El administrador puede generar reportes, la idea es generar una pantalla que entregue los

resultados, pero que también de la opción para registrar las conclusiones percibidas por

administrador, por ello se define la ventana con la opción de observación, como se ve en la

figura 4.17.

Figura 4. 17: Pantalla de Reportes.


54

10. Coordinar horario

Tabla 4. 11: Requerimiento asignar horario a paciente.



CU10, CU11

Descripción: El sistema coordina la atención de los pacientes en conjunto a la disposición de los internos, fonoaudiólogos y la disposición de box del centro.

Fundamentos: Llevar la calendarización de la atención que se realiza a los pacientes permite coordinación y una mejor atención, dado que no se perderán horas y cada paciente recibirá su debida atención.

Autor: Rodolfo Peña Criterio: El sistema debe contar con un calendario que permita el registro de las horas de

los pacientes para la próxima sesión. Se dan tres posibles casos para entregar un horario de atención:

a) El paciente solicita una hora de atención por primera vez y es atendido de forma inmediata por el fonoaudiólogo o interno que recibió al paciente, luego se registra en la agenda una fecha, hora y box para la próxima sesión.

b) El paciente solicita una hora por primera vez, pero no se puede atender de manera inmediata, el fonoaudiólogo o interno verifica su disponibilidad, de tener cupos, le asigna una fecha, hora y box. De no tener disponibilidad, busca un cupo de otro estudiante o fonoaudiólogo y le asigna fecha, hora y box.

c) El paciente está registrado y se le agenda una nueva sesión dando fecha, hora y box, todo a través de su ficha clínica.

Este calendario debe mostrar las horas que están reservadas y los cupos disponibles de cada interno y fonoaudiólogo del centro.

Satisfacción del cliente: 4 Insatisfacción de los clientes: 2 Prioridad: Alta Conflictos Cuando se trate de ingresar un

horario ocupado, el sistema debe ser capaz de avisar que no se puede realizar la reserva de horario.



55

El usuario puede agendar una hora a un paciente registrado para la próxima sesión, como se

ve en la figura 4.18. En el caso de atención por primera vez, el paciente debe ser ingresado al

sistema y a partir de ahí asignar un horario de atención.

Figura 4. 18: Ventana de asignación de horario a paciente


56

11. Mostrar agenda horaria

Tabla 4. 12: Requerimiento mostrar agenda horaria del centro.



CU11, CU12, CU18, CU21

Descripción: El sistema permite mostrar la agenda completa del centro. Fundamentos: El centro debe atender a los pacientes, para ellos es importante poder saber que

fonoaudiólogo o estudiante tiene disponible una hora para asignarle a un paciente que solicite atención.

Autor: Rodolfo Peña Criterio: El sistema debe presentar un horario semanal, con la agenda diaria de cada box.

El CECH cuenta con cuatro box, por lo que sólo se podrán realizar cuatro atenciones a la misma hora y en un mismo día. Se estima en promedio que la atención a un paciente es de 45 minutos, por lo que se debe registrar en la agenda un paciente cada 45 minutos. El sistema debe desplegar una tabla donde se indique la fecha, el box y en las filas se indique la hora correspondiente a la atención, el paciente que será atendido y el fonoaudiólogo o interno que atenderá a ese paciente, así también mostrar los bloques disponibles para asignar un nuevo horario. Además debe permitir poder imprimir dicho calendario. Se debe dar la opción al interno o fonoaudiólogo de modificar una hora que tiene reservada, ya que existe la posibilidad de que un paciente cancele la hora.

Satisfacción del cliente: 5 Insatisfacción de los clientes: 3 Prioridad: Alta Conflictos: No posee. Materiales de Soporte: Historia: 30-10-2013


57

Cuando ocurre el caso de que el paciente no posee ficha clínica se debe verificar el horario del

CECH, como se ve en la figura 4.19. Para destinar el paciente a un Interno o Fonoaudiólogo

que pueda atender e ingresar al paciente.

Figura 4. 19: Horario general del CECH


58

12. Editar ficha clínica

Tabla 4. 13: Requerimiento editar registros erróneos.


Requerimiento:

Funcional Eventos /

Casos de Uso

CU15, CU16

Descripción: El sistema debe permitir a los usuarios registrados como fonoaudiólogos editar

información almacenada en el sistema.

Fundamentos: En el CECH mayoritariamente trabajan estudiantes en práctica, estos pueden

ingresar información errónea, la que debe ser corregida, para no perder el

control de quien modifica cambios en la información de un paciente, sólo un

usuario con perfil de fonoaudiólogo puede realizar un cambio.


Criterio: El sistema debe permitir realizar cambios a todos los registros que acceda un

estudiante, estas modificaciones que realiza el fonoaudiólogo debe registrar la

última fecha y la identificación de quién realizó el cambio. Esta facultad se aplica

en el ingreso de un historial médico de un paciente, el diagnóstico de un paciente,

los datos personales de un paciente, los resultados de un examen.


Prioridad: Alta Conflictos Se perderá el registro de la

última modificación.




59

Si comparamos la figura 4.9, que es la ficha clínica vista por el estudiante, con la figura 4.18.

En la figura 4.18, se aprecian nuevos botones editar diagnóstico, editar historial. Botones que

el estudiante no posee. Esto con el fin de resguardar la información de los pacientes.

Figura 4. 20: Ficha clínica visto desde el perfil fonoaudiólogo.


60

13. Control Histórico de fichas y usuarios

Tabla 4. 14: Requerimiento para resguardar la información histórica.


Requerimiento:

Funcional/

Seguridad

Eventos /

Casos de Uso

CU27

Descripción: El sistema debe permitir un estado para que la información de un paciente y de

un Usuarios en particular, pueda ser restringida en el sistema.

Fundamentos: Los pacientes irán aumentando mediante el pasar de los años, habrá nuevas

fichas clínicas, así como también quedarán fichas obsoletas de pacientes que ya

no se atienden. Para resguardar la información de aquellos pacientes que

dejaron el centro y su ficha quedó sin uso, es necesario indicar un estado del

paciente, con el fin de que la información de ese paciente, sólo sea utilizada con el

fin de tener el registro. Así mismo pasaran varios Usuarios, fonoaudiólogos e

internos, los cuales, una vez que hayan terminado su participación en el CECH,

deben quedar bloqueados para acceder el sistema.


Criterio: El sistema, permite al administrador buscar y seleccionar un paciente y da la

opción de cambiar el estado de activo a pasivo o viceversa, de manera que la

ficha clínica sólo pueda ser visualizada por el resto de los usuarios, sólo si el

paciente es activo.

También, el sistema permite al administrador, buscar y seleccionar un usuario

(fonoaudiólogo o interno) y cambiar el estado asociado a ese usuario, de activo a

inactivo o viceversa.


Prioridad: 4 Conflictos



Este requerimiento viene a cubrir la necesidad de asegurar aquella información de paciente

que no estén activos, de igual forma pasa con los usuarios del centro. En la figura 4.21, se

visualiza el caso de que el administrador desee dejar inactivo un usuario o si quiere reactivar


61

uno que se encuentre fuera de la actividad. Al seleccionar en la pestaña de paciente, deben

ser similares los campos y permite realizar el mismo procedimiento.

Figura 4. 21: Prototipo para realzar cambios de los estados Histórico de pacientes y usuarios.


62

4.4.2 Requisitos No funcionales

1. Visualizar aplicación.

Tabla 4. 15: Requerimiento para la visualización del sistema.

Requerimiento: NF01 Tipo Requerimiento:

Apariencia Eventos / Casos de Uso

Descripción: El sistema debe llevar una combinación de colores, basado en el manual de comunicación corporativa de la Universidad del Bío Bío (UBB).

Fundamentos: El CECH, es una institución perteneciente a la Universidad del Bío Bío, por ello se sugiere que el diseño cumpla con las normas.

Autor: Rodolfo Peña Criterio: Se pide una propuesta de la aplicación con la combinación de colores acorde a las

normas gráficas y conceptuales de la UBB. Además se debe considerar los logos de la escuela de fonoaudiología y del propio CECH.

Satisfacción del cliente: 3 Insatisfacción de los clientes: 3 Prioridad: Media Conflictos Materiales de Soporte http://www.ubiobio.cl/mcc/index.html Historia: 13-11-2013

2. Control acceso de internos.

Tabla 4. 16: Requerimiento control acceso a estudiantes.

Requerimiento: NF02 Tipo Requerimiento:

Seguridad Eventos / Casos de Uso

Descripción: El sistema debe permitir a los usuarios registrados como estudiantes (internos), que pueden ingresar al sistema, sólo en el horario que trabaja el CECH.

Fundamentos: Existe la posibilidad de que el estudiante pueda acceder a la aplicación en otro horario y utilizar información de los pacientes, acción que no está permitida.

Autor: Rodolfo Peña Criterio: Se pide que el sistema sólo permita ingresar a los estudiantes mientras estos

estén en el centro. Para desarrollar esto, la aplicación debe dar acceso a los estudiantes, durante el horario de atención de pacientes que posee el CECH.

Satisfacción del cliente: 5 Insatisfacción de los clientes: 5 Prioridad: Alta Conflictos Materiales de Soporte Historia: 13-11-2013


63

4.4.3 Lista de Casos de Uso del Producto

En la sección 4.3.1, alcances del producto, se presentaron tres figuras, correspondientes a los

diagramas de casos de uso. Estos casos de usos muestran de manera gráfica la relación

existente entre las funciones del sistema y los actores. A continuación se realizará la

descripción de cada caso de uso presentado en aquellos esquemas, con tal de detallar, la

función que cumple cada uno, dentro del sistema.

1. ID: CU01. Caso de Uso: Login.

Descripción: El sistema debe controlar el acceso de los usuarios registrados y los que

no lo están.

Pre-Condiciones: no posee.

Actor Principal: Administrador, Estudiantes, Fonoaudiólogos.

Flujo de Eventos Básicos:

Tabla 4. 17: Flujo de eventos básicos, login.

Administrador/Estudiante/Fonoaudiólogo El sistema

1. El usuario registrado decide ingresar al

sistema.

2. El sistema muestra los campos

necesarios para validar, Rut y

contraseña.

3. El usuario registrado ingresa sus datos,

en los campos correspondientes.

4. El sistema valida los campos

introducidos por el usuario.

5. El usuario ingresa al sistema. 6. El sistema muestra la pantalla de

inicio.

Flujo de Eventos Alternativo:

1. El usuario no se ha registrado, debe contactar al administrador.

3a. El usuario olvidó contraseña, debe solicitarla mediante opción de olvidar

contraseña.

4a. No existe usuario, contraseña incorrecta o el usuario olvidó contraseña.


64

4a.1. El sistema avisa al usuario con un mensaje de error si la contraseña o

el usuario son erróneos.

4a.2. El sistema reenvía una nueva contraseña al correo del usuario

almacenado en el sistema, si el usuario lo solicita.

Post-Condiciones: no posee.

2. ID: CU02. Caso de Uso: Crear usuario.

Descripción: El sistema debe entregar la opción al administrador para crear más

usuarios.

Pre-Condiciones: El usuario debe estar registrado en el sistema e ingresar con perfil

de administrador.

Actor Principal: Administrador.


Tabla 4. 18: Flujo de eventos básicos, crear usuario.

Administrador El sistema

1. El administrador decide registrar un

nuevo usuario

2. El sistema muestra las opciones de

crear tres tipos de usuarios

diferentes, un nuevo administrador,

un fonoaudiólogo, un estudiante

(interno) presentando los campos que

deben ser llenados para registrar un

nuevo usuario.

3. El administrador selecciona el tipo de

usuario e ingresa los datos del nuevo

usuario solicitados por el sistema, en los

campos correspondientes.

4. El sistema crea el nuevo usuario,

además de asignar una contraseña por

defecto.


3a. El usuario cancela la operación.


65

4a. El usuario ya está registrado con el mismo perfil en el sistema. Un usuario puede

ser registrado con diferentes perfiles.


3. ID: CU03. Caso de Uso: Generar reportes.

Descripción: El sistema da la opción de generar reportes estadísticos.

Pre-Condiciones: El usuario debe estar registrado en el sistema.



Tabla 4. 19: Flujo de eventos básicos, generar reporte.


1. El administrador quiere obtener un

reporte.

2. El sistema presenta la opción de

generar reporte dado un rango, dado

un mes, año y día.

3. El administrador selecciona:

3.1. Generar reporte con rango de

fecha.

3.2. Generar reporte del día, mes o

año actual.

4. El sistema solicita:

4.1. una fecha de inicio y una fecha

de fin, para realizar el reporte

dado el rango definido por esas

fechas.

4.2. Genera el reporte del día, mes o

año actual. Y accede al flujo 7.

5. El usuario:

5.1. Ingresa las fechas en los campos

requeridos.

6. El sistema genera el reporte dentro del

rango solicitado.

7. El administrador puede seleccionar:

7.1. Guardar el documento en el

computador.

7.2. Imprimir el documento.




66

6a. El sistema muestra mensaje de error, por fechas no válidas.


4. ID: CU04. Caso de Uso: Registrar paciente.

Descripción: El sistema debe permitir registrar un paciente.


Actor Principal: Fonoaudiólogo, Estudiantes.


Tabla 4. 20: Flujo de eventos básicos, registrar paciente.

Fonoaudiólogo/Estudiante Sistema

1. El fonoaudiólogo/estudiante quiere

ingresar un paciente.

2. El sistema muestra los campos

necesarios para registrar un nuevo

paciente.

3. El fonoaudiólogo/estudiante ingresa los

datos del nuevo paciente que solicita el

sistema.

4. El sistema crea el nuevo paciente, este

caso de uso incluye, caso de uso: Crear

ficha clínica


3a. El fonoaudiólogo/estudiante cancela la operación.

4a. El sistema despliega un mensaje si el usuario que se está creando ya existe.

Post-Condiciones: El sistema debe crear una ficha clínica para el paciente creado.

5. ID: CU05. Caso de Uso: Crear ficha clínica.

Descripción: El sistema crea y asocia una ficha clínica a un paciente.


Actor Principal: Fonoaudiólogo, Estudiante.



67

Tabla 4. 21: Flujo de eventos básicos, crear ficha clínica.

Fonoaudiólogo/Estudiante El sistema

1. El sistema crea la ficha clínica a partir

de un paciente registrado.

2. El fonoaudiólogo ingresa los datos

solicitados por la nueva ficha clínica.

3. El sistema guarda los datos.



2a.1. El sistema arroja un mensaje de error, especificando que no se puede cancelar,

dado que no ha terminado el proceso.


6. ID: CU06. Caso de Uso: Agregar consentimiento informado.

Descripción: El sistema debe permitir subir en formato digital el conocimiento

informado de un paciente, este es un documento firmado por el paciente el cual

otorga a los fonoaudiólogo trabajar bajo ciertas normas que conoce el paciente.

Pre-Condiciones:

- El usuario debe estar registrado en el sistema.

- El paciente debe estar registrado en el sistema.




68

Tabla 4. 22: Flujo de eventos básicos, agregar consentimiento informado.


1. El fonoaudiólogo/estudiante desea

adjuntar el documento digitalizado a la

ficha clínica, para ello selecciona el

paciente, luego la ficha clínica y

selecciona adjuntar consentimiento

informado.

2. El sistema despliega una ventana de

búsqueda de archivos, la que permite

buscar dentro de los dispositivos de

almacenamiento (disco duro, CD, DVD

o memoria externa), aquel archivo del

documento informado en formato

digital.

3. El fonoaudiólogo/estudiante busca el

archivo en el dispositivo donde está

almacenado el documento de

conocimiento informado, lo selecciona

para subirlo al sistema.

4. El sistema despliega que el archivo ha

sido subido exitosamente. Despliega una

opción de visualización.


2a. El sistema ya cuenta con un registro de consentimiento informado. El sistema

consulta si desea sobrescribir el documento.

2a.1. El usuario selecciona que desea sobrescribir. El sistema envía al flujo

3.

2a.2. El usuario selecciona que no desea sobrescribir. El sistema envía al

flujo 3a.

3a. El fonoaudiólogo/estudiante cancela la opción.

4a. El archivo no válido. El sistema muestra un error.

4a.1. El archivo no posee el formato indicado.

4a.2. El archivo excede el tamaño establecido.



69

7. ID: CU07. Caso de Uso: Listar y buscar pacientes.

Descripción: El sistema debe permitir ver un listado de pacientes además de

realizar filtros de búsquedas para los pacientes.




Tabla 4. 23: Flujo de eventos básicos, listar y buscar paciente.


1. El fonoaudiólogo/estudiante necesita

visualizar uno o varios pacientes.

2. El sistema despliega por pantalla un

listado de todos los pacientes

registrados.

3. El fonoaudiólogo/estudiante puede:

3.1. Seleccionar un paciente.

3.2. Buscar un paciente.

3.3. Filtrar los datos de un paciente.

4. El sistema actúa según la opción elegida

por el usuario:

4.1. Si es seleccionado un paciente el

sistema debe direccionar a una

página con el perfil del paciente.

4.2. El sistema busca un paciente

determinado, por Rut o Apellido

Paterno, y en el listado de

pacientes solamente se

muestran aquellos resultados

que coinciden con la búsqueda.

4.3. Las filas del listado se ordenan

de acorde al filtro utilizado


3a. El fonoaudiólogo/estudiante cancela la operación.

Post-Condiciones: El sistema debe crear una ficha clínica para el paciente creado.


70

8. ID: CU08. Caso de Uso: Ver ficha paciente.

Descripción: El sistema muestra un perfil del paciente, con datos personales y

clínicos.

Pre-Condiciones:


- El usuario debe estar registrado en el sistema




71

Tabla 4. 24: Flujo de eventos básicos, ver ficha paciente.


1. El fonoaudiólogo/estudiante busca o

selecciona un paciente y desea ver los

antecedentes clínicos del paciente

2. El sistema despliega un perfil del

paciente, con los datos personales y el

historial médico. Además de entregar

varias opciones.

2.1. Agregar diagnóstico.

2.2. Agregar Consentimiento

informado.

2.3. Reservar Hora.

2.4. Agregar Historial a Ficha Clínica

2.5. Aplicar instrumentos de

evaluación

2.6. Agregar informe

fonoaudiológico.

3. El fonoaudiólogo/estudiante selecciona

una opción:

3.1. Agregar diagnóstico.

3.2. Agregar Consentimiento

informado.

3.3. Reservar Horario

3.4. Agregar nuevo historial al

paciente.

3.5. Aplicar instrumentos de

evaluación.

3.6. Agregar informe

fonoaudiológico.

4. El sistema responde según la opción del

fonoaudiólogo/estudiante.

4.1. Extiende al caso de uso: CU26.


4.3. Ejecuta el caso de uso: CU21.





3a.1. El fonoaudiólogo termina el proceso.



72

9. ID: CU09. Caso de Uso: Agregar informe fonoaudiológico.

Descripción: El sistema debe permitir subir en formato digital el informe

fonoaudiológico de un paciente, este es un documento creado por los estudiantes,

dado un estudia a un paciente.

Pre-Condiciones: El paciente al que se adjunta el informe fonoaudiológico debe

estar registrado en el sistema.

Actor Principal: Estudiante, Fonoaudiólogo.


Tabla 4. 25: Flujo de eventos básicos, agregar informe fonoaudiológico.

Estudiante/Fonoaudiólogo El sistema

1. El estudiante/fonoaudiólogo debe

adjuntar el documento digitalizado a la

ficha clínica, para ello selecciona el

paciente, luego la ficha clínica y

selecciona adjuntar informe

fonoaudiológico.

2. El sistema realiza dos acciones.

2.1. Primero muestra un listado con

los informes anteriores de otros

estudiantes, que han hecho un

informe fonoaudiológico al

mismo paciente, para que

puedan ser visualizados.

2.2. El sistema ofrece un botón que

despliega una ventana de

búsqueda de archivo, para que

se ubicado en archivo digital.

3. El estudiante/fonoaudiólogo tiene dos

opciones:

3.1. El estudiante puede seleccionar

un archivo previo del listado

para visualizar.

3.2. Busca en la dirección donde está

almacenado el documento del

informe fonoaudiológico, lo

selecciona para subirlo al

sistema.

4. El sistema:

4.1. El sistema abre y muestra el

documento seleccionado.

4.2. El sistema despliega que el

archivo ha sido subido

exitosamente. Agrega el nuevo

archivo al resto de los archivos

previos que han sido subidos. Y

despliega la opción de

visualización.


73


3a. El estudiante/fonoaudiólogo cancela la opción.

4.2a. El archivo no válido. El sistema muestra un error.

4.2a.1. El archivo no posee el formato indicado.

4.2a.2. El archivo excede el tamaño establecido.


10. ID: CU10. Caso de Uso: Agregar historial a ficha clínica.

Descripción: El sistema presenta la opción de Agregar historial a la ficha clínica de

un paciente seleccionado, a partir del registro diario que se le hace a dicho

paciente.

Pre-Condiciones: El paciente debe estar registrado en el sistema.




74

Tabla 4. 26: Flujo de eventos básicos, agregar historial a ficha clínica.


1. El fonoaudiólogo/estudiante busca o

selecciona un paciente y requiere:

1.1. Agregar una revisión a la ficha

clínica de ese paciente.

1.2. Aplicar un procedimiento

terapéutico al paciente.

2. El sistema crea una fila dentro de la

tabla del historial, que permita

ingresar los datos para realizar un

registro diario del paciente.

2.1. Si es una revisión, el campo de

objetivo operacional debe

quedar vacío.

2.2. Si se trata de un procedimiento

terapéutico, el campo de

objetivo operacional, debe

mostrar una lista con los

objetivos operacionales

pendientes, del programa

terapéutico.

3. El fonoaudiólogo/estudiante completa

los campos requeridos por el sistema y

guarda el registro diario del paciente.

4. El sistema almacena la información y

direcciona a la página del paciente.


3a.1. El fonoaudiólogo/estudiante cancela el proceso.


11. ID: CU11. Caso de Uso: Ver horario.

Descripción: El sistema muestra una tabla con el horario de una semana

seleccionada de todos los estudiantes y fonoaudiólogos del centro.

Pre-Condiciones: no posee.




75

Tabla 4. 27: Flujo de eventos básicos, ver horario.



revisar la disponibilidad de horarios del

centro.

1.1. El fonoaudiólogo/estudiante

puede ver el horario general del

CECH.

1.2. El fonoaudiólogo/estudiante

puede ver solamente su horario

2. El sistema presenta:

2.1. Solicita una determinada fecha

de inicio y una de fin, luego

muestra por cada día, la

disponibilidad horaria del

centro, las horas reservadas y en

que box fue registrada dicha

hora, además del paciente y

fonoaudiólogo que la reservo.

2.2. El sistema muestra el horario del

fonoaudiólogo/estudiante.

Flujo de Eventos Alternativo: no posee.


12. ID: CU12. Caso de Uso: Reservar horario paciente.

Descripción: El sistema permite seleccionar un paciente, para que se le asigne una

reserva de horario de atención

Pre-Condiciones: Los usuarios deben estar registrados en el sistema.

Actor Principal: Fonoaudiólogo, Estudiantes.



76

Tabla 4. 28: Flujo de eventos básicos, reservar horario paciente.


1. El Fonoaudiólogo/Estudiante decide

realizar una reserva para un paciente.

2. El sistema muestra el horario de la

semana, día, horas y salas disponibles,

además muestra las horas reservadas,

el fonoaudiólogo o estudiante que la

reservó y el paciente a quien se le

reservo. Además solicita una fecha

para realizar una nueva reservación.

3. El usuario, selecciona un box y una hora

disponible del horario en la semana o

selecciona una nueva semana para

reservar el horario.

4. El sistema registra la reserva de

horario y queda a la vista para el resto

de los usuarios.


3a. El usuario seleccionó un box ocupado.

3b. El usuario seleccionó un paciente que ya tenía un horario asignado ese día.

3c. El usuario selecciono un horario que estaba ocupado

4a. Para todos los flujos alternativos que se de en 3, el sistema debe avisar que no

puede registrar la hora al paciente, indicando el motivo del error si es por box,

paciente u horario.

Post-Condiciones: No posee

13. ID: CU13. Caso de Uso: Editar ficha clínica.

Descripción: El sistema permite editar alguna información incorrecta de un

paciente.

Pre-Condiciones: Debe existir un paciente para editar la información.

Actor Principal: Fonoaudiólogo.



77

Tabla 4. 29: Flujo de eventos básicos, editar.

Fonoaudiólogo El sistema

1. El fonoaudiólogo desea editar ficha

clínica:

1.1. Ficha de un paciente.

1.2. Exámenes de un paciente.

1.3. La reserva de horario de un

paciente.

2. El sistema permite:

2.1. Modificar la información

registrada de un paciente en la

ficha clínica.

2.2. Realizar alguna corrección en

algún examen tomado a un

paciente.

2.3. Cambiar la reserva horaria de un

paciente

3. El fonoaudiólogo/estudiante selecciona

una opción.

4. El sistema muestra un formulario con

los campos completos acordes a la

selección, permitiendo modificar

dichos campos y la opción de guardar

dichos cambios.

5. El usuario guarda los cambios. 6. El sistema informa que se han

guardado los cambios correctamente

y registra que usuario realizó los

cambios.


3a. El fonoaudiólogo/estudiante cancela la opción

5a. El usuario no guarda los cambios, el sistema no sufre modificación.

6a. El sistema no guardó los cambios, faltan datos.



78

14. ID: CU14. Caso de Uso: Ver exámenes.

Descripción: El sistema ofrece una opción para visualizar los exámenes de un

paciente determinado.

Pre-Condiciones: El usuario debe estar registrado en el Sistema.



Tabla 4. 30: Flujo de eventos básicos, ver exámenes.


1. El fonoaudiólogo/estudiante:

1.1. Selecciona un paciente de la lista

de pacientes

1.2. Busca un paciente por su RUN,

número de ficha o Nombre

2. El sistema:

2.1. Despliega una lista con los

exámenes del paciente

seleccionado.

2.2. El sistema busca el paciente y

despliega el listado de los

exámenes del paciente.

3. El fonoaudiólogo visualiza los exámenes

realizados y puede ver detalles del

examen.

4. El sistema muestra el detalle del examen

que se desea visualizar.


2a.2. el sistema no encuentra al paciente, informa al usuario y lo direcciona al flujo

1.

2b.2 el sistema encuentra más de un resultado para la búsqueda por nombre,

solicita al usuario que seleccione uno de los encontrados, direccionando al flujo 1.

3a. El fonoaudiólogo cancela el proceso.



79

15. ID: CU15. Caso de Uso: Ver perfil.

Descripción: El sistema muestra los datos del usuario registrado en el sistema.


Actor Principal: Todos.


Tabla 4. 31: Flujo de eventos básicos, ver perfil.

Usuarios El sistema

1. El usuario desea verificar los datos

de su cuenta.

2. El sistema muestra todos los datos

registrados del usuario, excepto la

contraseña. Además la opción de

cambiar contraseña actual

3. El usuario desea cambiar la contraseña. 4. El Sistema envía al usuario a una

página de cambio de contraseña.

Flujo de Eventos Alternativo: no posee.


16. ID: CU16. Caso de Uso: Cambiar contraseña.

Descripción: El sistema permite a los usuarios cambiar su contraseña de ingreso.




Tabla 4. 32: Flujo de eventos básicos, cambiar contraseña.

Usuarios El sistema

1. El usuario accede a cambiar su

contraseña.

2. El sistema muestra los campos para

realizar el cambio, solicitando la

contraseña actual, y la nueva

contraseña.

3. El usuario ingresa la información

solicitada por el sistema y guarda.

4. El Sistema notifica que la contraseña

ha sido cambiada con éxito.



80

4a. Error en el cambio de contraseña:

4a.1. La contraseña ingresada no es válida.

4a.2. La nueva contraseña no cumple los requisitos solicitados.


17. ID: CU17. Caso de Uso: Realizar examen.

Descripción: El sistema permite a los estudiantes o fonoaudiólogos a registrar el

resultado de los exámenes aplicados al paciente.


Actor Principal: Estudiante, Fonoaudiólogos.


Tabla 4. 33: Flujo de eventos básicos, realizar examen.

Usuarios El sistema

1. El Estudiante/Fonoaudiólogo desea

realizar un examen.

2. El sistema hace un registro de la fecha

y muestra una lista con los exámenes

clasificados en:

2.1. Protocolos cuantitativos.

2.2. Protocolos cualitativos

3. El usuario selecciona un tipo de

protocolo y luego busca el que desea

aplicar.

4. El sistema almacena el tipo de

examen seleccionado y según la

selección incluye a los casos de uso:

4.1. Protocolos cualitativos (CU23).

4.2. Protocolos cuantitativos (CU22).

5. El usuario realiza lo solicitado por los

casos de usos que están incluidos.

6. El sistema presenta un campo donde

se pueden agregar observaciones al

protocolo. Además da la opción para

guardar la información

7. El usuario guarda la información. 8. El sistema informa que se ha

guardado correctamente.



81

3a. El usuario cancela la opción.




18. ID: CU18. Caso de Uso: Reporte Horario.

Descripción: El sistema permite obtener un reporte del horario de atención del

CECH dentro de una fecha solicitada.


Actor Principal: Estudiante, Fonoaudiólogos.


Tabla 4. 34: Flujo de eventos básicos, reporte agenda.

Usuarios El sistema

1. El Estudiante/Fonoaudiólogo desea

obtener un reporte del horario de

atención.

2. Ofrece a partir de la inclusión del caso

de uso: Ver Horario, una opción para

exportar a un archivo el horario

generado.

3. El usuario acepta y ahora puede

imprimir el archivo o almacenarlo.

4. El Sistema genera un reporte con los

horarios de atención definidos dentro

de las fechas solicitadas.



4a. La fecha no es válida:

4a.1.La fecha no existe o tiene un formato erróneo.

4a.2. La fecha de inicio es después de la fecha de término.



82

19. ID: CU19. Caso de Uso: Editar usuario.

Descripción: El sistema permite cambiar la información de un usuario registrado,

salvo la contraseña de ese usuario.

Pre-Condiciones: El usuario debe estar registrado en el sistema y contar con perfil

de administrador.



Tabla 4. 35: Flujo de eventos básicos, editar usuario.


1. El administrador desea cambiar

información de un usuario.

2. El sistema muestra una lista con

usuarios, además ofrece buscar un

usuario por su RUN.

3. El usuario selecciona un paciente de la

lista o realiza una búsqueda.

4. El Sistema:

4.1. Carga los datos del paciente

seleccionado.

4.2. El sistema busca al paciente

solicitado y carga los datos.

5. El administrador puede realizar

cambios en la información del usuario

seleccionado o buscado y guardar.

6. El sistema almacena la información,

avisa que los cambios han sido

guardados.



4a.2. El sistema no encontró al usuario buscado y envía al administrador al flujo 3.

5a. El administrador debe corregir la búsqueda para un usuario válido y vuelve al

flujo 4.

6a. El sistema no guarda los datos, el usuario ingresó mal algún dato. Debe

especificar que dato es erróneo y ejemplificar como debe ser ingresado. Direcciona

al flujo 5.


83


20. ID: CU020. Caso de Uso: Logout.

Descripción: El sistema debe entregar la opción a los usuarios que estén dentro del

sistema, para cerrar su sesión.




Tabla 4. 36: Flujo de eventos básicos, logout.

Usuarios El sistema

1. El sistema muestra a los usuarios que

ingresaron al sistema, la opción para

cerrar sesión.

2. El usuario decide cerrar sesión. 3. El sistema cierra la sesión y direcciona

a la página de inicio del sistema.


4a. El Sistema tiene un formulario abierto y no puede cerrar la sesión, muestra un

mensaje que indique al usuario a finalizar el formulario.

Post-Condiciones: Una vez cerrada la sesión el usuario no puede volver a entrar,

mientras no ingrese los datos solicitados por el caso de uso login.

21. ID: CU021. Caso de Uso: Modificar horario paciente.

Descripción: El sistema debe permitir cambiar la hora de un paciente o eliminarla.





84

Tabla 4. 37: Flujo de eventos básicos, modificar horario paciente.


1. El usuario desea realizar un

cambio de horario de un paciente.

2. El sistema muestra dos opciones:

2.1. Eliminar Hora.

2.2. Cambiar Hora.

3. El usuario debe escoger una

opción:

4. El sistema actuará de acuerdo a la

opción seleccionada:

4.1. El sistema elimina el registro de la

hora reservada y muestra un

mensaje informando que ha sido

eliminada. Fin de este flujo.

4.2. El sistema presenta un campo que

solicita una fecha, otro campo que

solicita una nueva hora y un

campo donde solicita el box.

5.2. Ingresa los datos solicitados por el

sistema.

6.2. El sistema almacena el nuevo día, hora

y sala para la nuevo horario de

atención del paciente.



5.2a. El usuario cancela la opción.

6.2a. El sistema no puede realizar el cambio de horario, existe un conflicto con la

fecha, hora o sala del nuevo registro.



85

22. ID: CU022. Caso de Uso: Protocolos Cualitativos.

Descripción: Este caso de uso proviene del caso de uso CU17. El sistema debe

permitir registrar los protocolos del anexo 10.2, que sólo registren información

cualitativa.

Pre-Condiciones:


- El usuario debe querer realizar un examen.



Tabla 4. 38: Flujo de eventos básicos, Protocolos cualitativos.


1. El sistema despliega los siguientes

campos: Descripción y conclusión.

Además indica el nombre del examen

que se está realizando y da lo opción

de guardar.

2. El usuario ingresa una descripción

y una conclusión del examen que

realizó, luego guarda.

3. El sistema almacena la información

del examen e indica que el examen ha

sido almacenado con éxito.


2a. El usuario cancela la operación



86

23. ID: CU023. Caso de Uso: Protocolos Cuantitativos.

Descripción: Este caso de uso proviene del caso de uso CU17. El sistema debe

permitir ingresar información de los protocolos aplicados del anexo 10.1, y dada

esa información nos entregue algún resultado.

Pre-Condiciones:


- El usuario debe querer realizar un examen.



Tabla 4. 39: Flujo de eventos básicos, Protocolos cuantitativos.


1. El sistema despliega los siguientes

campos: Puntaje total y conclusión.

Además indica el nombre del

protocolo que se está realizando, y

genera una diagnóstico a partir del

puntaje ingresado, además da lo

opción de guardar.

2. El usuario ingresa una descripción

y un puntaje total del protocolo

aplicado, luego guarda.


del examen e indica que el examen ha

sido almacenado con éxito.





87

24. ID: CU024. Caso de Uso: Programa Fonoaudiológico.

Descripción: El sistema debe permitir ingresar un programa fonoaudiológico,

donde se plantean objetivos generales del tratamiento, luego para cada objetivo

general se detalla los objetivos específicos y estos a la vez poseen varios objetivos

operacionales.

Pre-Condiciones:


- El usuario debe crear un programa asociado a un paciente.




88

Tabla 4. 40: Flujo de eventos básicos, Programa fonoaudiológico.



crear un programa fonoaudiológico a

un paciente determinado y selecciona

en la ficha del paciente, programa

fonoaudiológico.

2. El sistema :

2.1. Despliega una lista con los

objetivos generales y da la opción

para seleccionar uno.

2.2. El sistema ofrece la opción de

crear un nuevo objetivo general.

3. El usuario:

3.1. El usuario selecciona un objetivo

general.

3.2. El usuario decide ingresar un

nuevo objetivo general.

4. El sistema:

4.1. El sistema presenta un listado

con los objetivos específicos

asociados al objetivo general

seleccionado.

4.2. El sistema abre una ventana e

incluye el caso de uso: CU25.

5. El usuario:


específico.

5.2. El usuario decide ingresar un

nuevo objetivo específico, para el

objetivo general seleccionado

previamente.

6. El sistema:

6.1. Despliega una nueva tabla con los

objetivos operacionales, cuáles

de estos están completados y

cuáles están pendientes, asignado

al objetivo específico

seleccionado.


inicia el caso de uso: CU25.

7. El usuario:


operacional que este pendiente y

puede aplicar el objetivo.

7.2. El usuario desea ingresar un

nuevo objetivo operacional, para

le objetivo específico

seleccionado.

8. El sistema:

8.1. El sistema direcciona a la

creación de un nuevo historial

del paciente, CU10, registrando

el objetivo operacional en el

campo con el mismo nombre.


inicia el caso de uso: CU25.


89







25. ID: CU025. Caso de Uso: Ingresar un objetivo.

Descripción: El sistema debe permitir ingresar objetivos ya sea generales,

específicos y operacionales.

Pre-Condiciones:


- El usuario debe crear un objetivo relacionado a un programa

fonoaudiológico de un paciente.




90

Tabla 4. 41: Flujo de eventos básicos, ingresar un objetivo.


1. El sistema despliega un formulario

con el campo para ingresar la

descripción del objetivo. Además debe

entregar el número correspondiente

del objetivo.

2. El usuario ingresa una descripción del

objetivo.


del objetivo, si es un objetivo

operacional, lo guarda referenciando

una objetivo específico. Si es un

objetivo específico, este se almacena

referenciando a un objetivo general y

el objetivo general se referencia a un

paciente.




26. ID: CU026. Caso de Uso: Registrar diagnóstico.

Descripción: El sistema debe permitir el registro de uno o varios diagnósticos para

un paciente.

Pre-Condiciones:






91



1. El usuario, requiere ingresar un nuevo

diagnóstico a un paciente.

2. El sistema presenta una tabla con el

código y nombre del diagnóstico,

además quién lo diagnosticó y en qué

fecha. Además el sistema ofrece

agregar un nuevo diagnóstico.

3. El usuario selecciona agregar

diagnóstico.

4. El sistema despliega un formulario

con el listado de todos los

diagnósticos.

5. El usuario selecciona el diagnóstico

del paciente.

6. El sistema almacena y muestra la

tabla actualizada con todos los

diagnósticos del paciente.




27. ID: CU027. Caso de Uso: Administrar Registros de usuarios y pacientes.

Descripción: El sistema debe permitir buscar un paciente o usuario registrado y da

la opción de cambiar el estado de la persona buscada.

Pre-Condiciones:





92




1. El administrador requiere cambiar el

estado de un paciente o usuario del

centro.

2. El sistema presenta dos pestañas:

2.1. Usuario.

2.2. Paciente.

3. El usuario selecciona una de las

pestaña. Siendo por defecto la de

usuario.

4. El sistema presenta una opción para

que el usuario decida el filtro para

buscar.

5. El usuario selecciona un filtro e

ingresa el dato que desea buscar

6. El sistema despliega un listado con las

coincidencias de la búsqueda y

muestra la opción para cambiar el

estado de la búsqueda.

7. El usuario cambia el estado de la

persona buscada.

8. El sistema informa que los cambios

han sido almacenados correctamente.


3. El usuario cancela la operación.

4. El sistema no encontró coincidencias.

5. El usuario cancela la operación

7. El usuario cancela la operación



93

4.4.4 Matriz resumen de Casos de uso y Requerimientos.

A continuación se presenta una matriz donde se muestra en las columnas los requerimientos

anteriormente desarrollados y en las filas se presentarán los casos de uso, con el fin de

indicar la relación de los casos de uso en los requerimientos.

Tabla 4. 44: Tabla matriz de relación casos de uso con requerimientos.

RF 01

RF 02

RF 03

RF 04

RF 05

RF 06

RF 07

RF 08

RF 09

RF 10

RF 11

RF 12

RF 13

NF 01

NF 02

CU01 X CU02 X CU03 X CU04 X CU05 X CU06 X CU07 X CU08 X CU09 X CU10 X X CU11 X X CU12 X CU14 X CU15 X CU16 X CU17 X CU18 X CU19 X CU20 X CU21 X CU22 X CU23 X CU24 X CU25 X CU26 X CU27 X


94

4.5 Etapa de Control de Calidad.

Esta etapa se desarrolló en conjunto con el cliente, aquí se presentan cada prototipo de

manera detallada, junto con la definición del requisito. El cliente, aprueba aquellos requisitos,

con los que estaba conforme, hacía sugerencias y también intervenía en el desarrollo,

solicitando modificaciones para aquellos requerimientos que no cumplen con las verdaderas

necesidades del centro o que simplemente no abarcaban toda la necesidad que solicita el

CECH.

Aprobado el requisito, los documentos quedan listos para pasar a la siguiente etapa de

revisión.

4.6 Etapa Revisión de requisitos.

El cliente revisó todos los requisitos en conjunto, para ver si cumplen las expectativas y

necesidades solicitadas, además de cerciorarse de que no haga falta nada. Cabe mencionar

que al trabajar con un solo cliente, facilitó la revisión, ya que al momento de realizar el

control, desde ya, se iban realizando correcciones pertinentes y al momento de asociar todas

las funcionalidades requeridas, ya existía una idea del usuario acerca del funcionamiento.

Los riesgos para este proyecto van asociados al futuro incierto que tienen las siguientes

etapas de análisis, diseño y construcción, debido a que está es sólo una primera etapa del

proyecto, correspondiente a la elicitación de requerimientos.

Por otro lado los costos significativos del proyecto se enfocan en la necesidad de

infraestructura y equipos computacionales para poder utilizar el producto una vez que esté

finalizado.

A modo de comprobar esta información, el Cliente emitió una carta de aprobación a todos los

requerimientos desarrollados a lo largo de este informe. (Ver Anexo 12).


95

5 ANÁLISIS

5.1 Modelo de Datos Conceptual

El modelo de datos conceptual es un esquema que permite describir gráficamente los

requerimientos recopilados y como estos se relacionan entre sí. En la figura 5.1, se aprecia el

esquema obtenido después de realizar el estudio. Este esquema es un modelo entidad

relación que ayuda a los futuros desarrolladores a visualizar la información que el sistema

necesita para trabajar.


96

Figura 5. 1: Modelo de datos conceptual.


97

6 RESUMEN ESFUERZO REQUERIDO

En este capítulo, se presenta la cantidad de horas destinadas (aproximadamente) a cada fase

de este proyecto, en la tabla 6.1 se aprecia el detalle.

Tabla 6. 1: Resumen esfuerzo requerido.

Actividades/Fases N° de Horas

Definición del Método de Trabajo 12 horas.

Requisitos 80 horas.

Prototipos 48 horas.

Análisis y Diseño 28 horas.

Documentación 70 horas.

Total 238 horas.


98

7 CONCLUSIONES

Realizar este trabajo, fue con el objetivo de hacer una captura de requisitos que plasme todos

los requerimientos necesarios para el desarrollo de un software, que permita gestionar la

información de los pacientes del Centro Fonoaudiológico CECH.

Para llevar a cabo este trabajo, fue necesario revisar varias metodologías de ingeniería de

requisitos. Una vez estudiadas las metodologías se prosiguió a realizar una selección, mediante

un análisis que contempló aspectos como las etapas de trabajo, los resultados que entrega, las

herramientas que posee, entre otras cualidades, para definir una metodología que permita

hacer una elicitación de requisitos acorde con las características del cliente. Producto de ese

estudio se definió trabajar con la metodología VOLERE. La metodología VOLERE, posee una

trayectoria de varios años, pero lo más importante son las etapas del proceso de requisitos y

las herramientas que entrega mediante su Shell y su plantilla, estos permiten realizar un

documento con la información estructurada y con la aprobación del cliente, la cual es un

respaldo que permite solucionar los errores al instante de ser detectados y no cuando los

programadores comienzan a desarrollar la aplicación.

Durante todo este proyecto, el trabajo fue desarrollado de acuerdo a la estructura de la

metodología antes mencionada, mediante una serie de reuniones periódicas con el cliente se

obtuvo toda la información reflejada en este documento. Estas reuniones permitieron, sin

lugar a duda, una comunicación con el cliente que generó una retroalimentación para ambas

partes, dado que ambos compartimos un área nueva, así como para mí fue, el área de

fonoaudiología, para el cliente lo fue la informática. La falta de experiencia de ambas partes, en

esta clase de proyectos, puede implicar que hayan puntos que no se hayan considerados y que

al momento del desarrollo de la aplicación sean necesarios discutir, si fuese de esa forma, las

personas que continúen este proyecto, deben consultar al cliente las dudas que tengan al

respecto, él es quien debe decidir cualquier cambio que requiera este documento.

También se debe considerar, que dentro de los posibles cambios y mejoras que se pueden

aplicar en este proyecto, está la opción de modificar algunos prototipos de acorde a las

circunstancias del desarrollo, siempre y cuando la funcionalidad no se vea afectada y el cliente

apruebe la decisión.


99

Del ámbito académico, debo mencionar aquellos cursos que me permitieron realizar este

proyecto, fueron asignaturas que están relacionadas con la ingeniería de software y

metodología de la investigación, ya que me entregaron los conocimientos para realizar una

buena recopilación de información y el desarrollo de los requerimientos, por otro lado la

realización de la práctica profesional en un centro hospitalario, facilita la comprensión de los

procesos llevado a cabo en el CECH. Las diferentes asignaturas de talleres de desarrollo de

proyecto informáticos fueron fundamentales para el desarrollo de prototipos, dada la

experiencia que aquello aporta, la que me permitió plantear ideas y evaluar si las solicitudes

del cliente son pertinentes o no y de esa manera dar justificación acorde a las dudas.

Desde el punto de vista personal, significa el término de una etapa como estudiante de la

Universidad del Bío Bío, además es el comienzo de un nuevo ciclo, lleno de desafíos

profesionales y personales. También existe una satisfacción de haber logrado este gran desafío,

finalizar el proceso de estudio, es algo que en muchas ocasiones se vio difícil y lleno de

incertidumbre.

Para terminar, quiero decir que los objetivos planteados en un principio se han alcanzado

satisfactoriamente y espero que este trabajo pueda servir como una herramienta para aquellos

que deseen continuar este proyecto en la etapa de desarrollo, así también a aquellos que

desean investigar sobre la ingeniería de requisitos y para los que requieran realizar o tener

una noción de lo que es una elicitación de requisitos.


100

8 BIBLIOGRAFÍA

Báez, M. G., & Brunner, S. I. B. (2001). Metodología DoRCU para la Ingeniería de Requerimientos. Paper

presented at the WER.

Bahamonde, J. M., & Rossel, R. (2003). Un Acercamiento a la Ingenierıa de Requerimientos.

Gallardo Arancibia, J. A. (2009). Metodología para la definición de requisitos en proyectos de data

mining (er-dm). Universidad Politécnica de Madrid.

Kotonya, G. (1999). Practical experience with viewpoint-oriented requirements specification.

Requirements engineering, 4(3), 115-133.

Loucopoulos, P., & Karakostas, V. (1995). System requirements engineering: McGraw-Hill, Inc.

Potts, C., Takahashi, K., & Anton, A. I. (1994). Inquiry-based requirements analysis. Software, IEEE,

11(2), 21-32.

Richards, D. (2000). A process model for requirements elicitation. Paper presented at the Proceedings

of The 11th Australasian Conference on Information Systems, Brisbane, Australia.

Robertson, J., & Robertson, S. (2000). Volere: Requirements specification template: Technical Report

Edition 6.1, Atlantic Systems Guild.

Sommerville, I. (2002). Ingeniería de Software, 6ta (6a Edición ed.): Ed. Addison Wesley,.

Sumano, M. d. l. Á. (2002). Método para el Análisis de Requerimientos de Software con enfoque

conjunto psicológico, social y lingüístico conducente al reuso. Instituto Politécnico Nacional,

Centro de Investigación en Computación, Laboratorio de Tecnología de Software, México, DF.

VOLERE. (2005). http://www.volere.uk/ Retrieved 10-10-2013, 2013


http://www.volere.uk/

101

9 ANEXO: PLANIFICACIÓN INICIAL DEL PROYECTO

A continuación se presenta la Carta Gantt donde se establecen las iteraciones y actividades

desarrolladas.

Tabla 9. 1: Carta Gantt.

Id Nombre Duración Comienzo Fin

1 Reunión Usuario, Definición de Metodología a

Usar 6 días 8/26/13 9/2/13

2 Primera Iteración 15 días 9/2/13 9/20/13

3 Identificación, Elicitación de Requisitos 4 días 9/2/13 9/5/13

4 Análisis de Requisitos 4 días 9/5/13 9/10/13

5 Especificación de Requisitos 6 días 9/9/13 9/16/13

6 Realizar Prototipos 10 días 9/9/13 9/20/13

7 Validación y Negociación de Requisitos 4 días 9/17/13 9/20/13

8 Segunda Iteración 20 días 9/23/13 10/18/13






14 Tercera Iteración 10 días 10/21/13 11/1/13






20 Creación de Prototipos 10 días 11/4/13 11/15/13

21 Revisión y Ajustes 10 días 11/4/13 11/15/13

22 Documentación 60 días 8/26/13 11/15/13


102

10 ANEXO: PROTOCOLOS CECH

Los protocolos son las herramientas que permiten determinar la condición de un paciente,

existen varios tipos por lo que hacer una estandarización es algo complejo, de igual manera se

logró identificar dos grandes grupos: Cuantitativos y Cualitativos.

Al realizar un protocolo cuantificable, se obtiene un puntaje, que dado un serie de información

se puede obtener un resultado del estado del paciente y están aquellos, cualitativos, que sólo

con la aplicación del protocolo, se puede determinar un diagnóstico del paciente, por

percepción del fonoaudiólogo o interno.

Este anexo se concentra en rescatar los datos relevantes de cada protocolo para que los

desarrolladores puedan hacerse una idea, de que es lo que se desea registrar del protocolo.

10.1 Protocolos cuantitativos

Para estos protocolos se consideró aquellos que entregan un resultado basado en puntaje para

determinar una consecuencia de ese resultado, están aquellos que sólo se registra el puntaje

total y están aquellos que se registra la resolución del protocolo dado el puntaje obtenido.

10.1.1 Dominio ACE-R-Ch

Tabla 10. 1: Datos requeridos protocolo: ACE-R-Ch

Fecha: Puntuaciones máximas

Orientación y Atención 18

Memoria 26

Fluencias Verbales 14

Lenguaje 26

Habilidades Visoespaciales 16

Total ACE-R-Ch 100

Observaciones:

Resultado según calificación: Normal

DCL (deterioro cognitivo

leve)

Demencia

91 a 100 81-90 0-80


103

10.1.2 I.T.P.A.

Tabla 10. 2: Datos requeridos protocolo: L.T.P.A.

Fecha

Perfil de Aptitudes DP (Puntaje)

1. Comprensión auditiva

2. Comprensión visual

Memoria secuencial visomotora

Asociación auditiva

Memoria secuencial auditiva

Asociación visual

Integración Visual

Expresión Verbal

Integración gramatical

Expresión Motora

Integración Auditiva

Observaciones:

10.1.3 I.D.E.A.

Tabla 10. 3: Datos requeridos protocolo: I.D.E.A.

Fecha

Inventario de espectro autista Puntaje Total

Escala: Relación Social

Escala: Comunicación y Lenguaje

Escala: Anticipación/Flexibilidad

Escala: Simbolización

Observaciones:


104

10.1.4 Mini Mental

Tabla 10. 4: Datos requeridos protocolo: Mini mental.

Fecha Tabla de puntaje

Edad edad Básica Medio Superior Universitaria

Puntaje total 18-69 22-25 26-27 28-29 29

Diagnóstico 70-79 21-22 25 27 28

Observaciones 79- 19-20 23-25 25-26 27

10.1.5 MoCA

Tabla 10. 5: Datos requeridos protocolo: MoCA.

Fecha

Edad

Puntaje >26 normal

Resultado

Observación

10.1.6 Evaluación Fonoaudiológica 4 años a 4 años 11 meses

Tabla 10. 6: Datos requeridos protocolo: Ev. Fonoaudiológica 4 a 4,11 años.

Fecha

CATEGORÍA DE RENDIMIENTO PUNTAJE TOTAL

Insuficiente 0- 29 puntos

Suficiente 30- 49 puntos

Bueno 50-68 puntos

Muy Bueno 69-98 puntos

Observaciones


105

10.1.7 Evaluación Fonoaudiológica 5 años a 6 años 11 meses

Tabla 10. 7: Datos requeridos protocolo: Ev. Fonoaudiológica 5 a 6,11 años.

Fecha




Bueno 50-68 puntos


Observaciones

10.1.8 Evaluación Fonoaudiológica 7 años a 12 años

Tabla 10. 8: Datos requeridos protocolo: Ev. Fonoaudiológica 7 a 12 años.

Fecha




Bueno 50-68 puntos


Observaciones

10.1.9 Protocolo de Evaluación del Habla (Rafael González)

Tabla 10. 9: Datos requeridos protocolo: Ev. Del Habla (Rafael González).

Respiración. 5 Definición de puntaje

Fonación. 5 1 Normal

Resonancia. 5 2 Deficiencia Leve

Control Motor Oral y Articulación 5 3 Deficiencia Moderada

Prosodia. 5 4 Deficiencia Moderada a Severa

Inteligibilidad 5 5 Deficiencia Severa

Sensibilidad Oral 5

Fecha

Observaciones

Diagnóstico Fotobiológico

Indicaciones:


106

10.1.10 Protocolo de Evaluación del Habla

Tabla 10. 10: Datos requeridos protocolo: Ev. Del Habla.

Fecha:

Síntesis Puntaje

1. Respiración 5

2. Pofación 5

3. Resonancia 5

4. C. Mot. Oral y Art. 5

5. Prosodia 5

6. Inteligibilidad 5

Total

Disartria Si No Grado L M S

Apraxia del Habla Si No Grado L M S

Apraxia Fonatoria Si No

Apraxia Oral si No Grado L M S

Tipo

Observaciones

10.1.11 S.L.A.

Tabla 10. 11: Datos requeridos protocolo: S.L.A.

Fecha

Subprueba Trastorno Normal

Discriminación de Fonemas 0 - 8 9

Decisión de Palabras 0 - 7 8

Emparejamiento Palabra Hablada- Dibujo 0 - 9 10

Fluidez Verbal Categorial 0 - 9 10

Denominación de Imágenes 0 - 8 9-10

Repetición de Palabras 0 - 7 8

Repetición de No Palabras 0 - 7 8

Observaciones


107

10.1.12 TECAL

Tabla 10. 12: Datos requeridos protocolo: TECAL.

PUNTAJE

INTERPRETACIÓN NORMAL

(X +/- 1 DS)

EN RIESGO

(entre X – 1 DS Y X – 2 DS)

DEFICIENTE

(bajo el X – 2 DS)

TOTAL

VOCABULARIO

(1 – 41)

MORFOLOGÍA

(42 – 89)

SINTAXIS (90 –

101)

Fecha:

Observaciones:

Conclusiones:

10.1.13 Protocolo TEVI

Tabla 10. 13: Datos requeridos protocolo: TEVI.

Fecha Forma Techo Errores Puntaje Obtenido

Observaciones

10.1.14 Valoración y Protocolos Token Test

Tabla 10. 14: Datos requeridos protocolo: Valoración y Protocolo Token Test.

Fecha Edad Puntaje total Percentil Observaciones

10.1.15 Protocolo de Test de WEPMAN

Tabla 10. 15: Datos requeridos protocolo: Test de WEPMAN.

Fecha

Resultado Respuesta correctas * 2,5 %

Edad

Conclusiones

Observaciones


108

10.2 Protocolos Cualitativos

Los protocolos cualitativos y son aquellos que se registra como resultada la apreciación del

fonoaudiólogo o interno al momento de aplicar el protocolo.

10.2.1 Evaluación disfemia infantil

Tabla 10. 16: Datos requeridos protocolo: Ev. Disfamia infantil.

Fecha

Tipo de tartamudez 1. Tónica

2. Clónica

3. Mixta

Severidad 1. Leve (Logra Comunicarse)

2. Moderada (A veces no se le entiende)

3. Severa (No logar emitir la idea)

Observaciones

10.2.2 Protocolo evaluación miofuncional:

Tabla 10. 17: Datos requeridos protocolo: Ev. Miofuncional.

Fecha

Diagnostico fonoestomatognatico:

Plan de tratamiento:

10.2.3 Ficha evaluación riesgo vocal

Tabla 10. 18: Datos requeridos protocolo: Ev. Riesgo vocal.

Fecha

Puntaje Total

Evaluación de resultados

Observaciones


109

10.2.4 Evaluación vocal infantil – Carola Rivera

Tabla 10. 19: Datos requeridos protocolo: Ev. Vocal Infantil (Carola Rivera).

Fecha

Observaciones

Derivaciones

Diagnóstico

10.2.5 Evaluación vocal Infantil, UBB

Tabla 10. 20: Datos requeridos protocolo: Ev. Vocal Infantil (UBB).

Fecha

Cefalización

Sedestación

Marcha

Esfínter vesical Diurno: Logrado (L) / logrado (NL) Nocturno:

Esfínter anal Diurno: Nocturno:

Vocalización

Balbuceo

1° Palabra

Holofrase

1° frase

Enfermedades Importantes:

10.2.6 Evaluación clínica de la deglución

Tabla 10. 21: Datos requeridos protocolo: Ev. Clínica de la deglución.

Fecha:

Observaciones:

Síntesis:

Disfagia Orofaríngea Si No

Posible aspiración Si No

Grado L M S

Plan


110

10.2.7 Pauta de evaluación para Tartamudez

Tabla 10. 22: Datos requeridos protocolo: Ev. Tartamudez.

Fecha

Síntesis

Derivación

10.2.8 Protocolo QVV

Tabla 10. 23: Datos requeridos protocolo: QVV.

Fecha Dominio socio-

emocional

Funcionamiento físico total Observaciones

10.2.9 Protocolo de evaluación de la insuficiencia velofaringea

Tabla 10. 24: Datos requeridos protocolo: Ev. De la insuficiencia velofaringea.

Fecha Puntaje Evaluación Sugerencias Observaciones

10.2.10 Evaluación fonoaudiológica clínica de la disfagia orofaríngea post-ave

Tabla 10. 25: Datos requeridos protocolo: Ev. Fonoaudiológica de la disfagia orofaringea post-ave.

Fecha

Definición de la conducta

Indicaciones

Observaciones

10.2.11 Q-CHAT

Tabla 10. 26: Datos requeridos protocolo: Q-CHAT.

Fecha

Observaciones


111

10.2.12 Screening Test of Spanish Grammar – S. T. S. G. (Comprensivo)

Tabla 10. 27: Datos requeridos protocolo: S.T.S.G comprensiva.

Fecha

Total de Puntos:

Percentil

Rango de Edad:

Conclusiones

Observaciones

10.2.13 Screening Test Of Spanish Grammar – S. T. S. G. (expresivo)

Tabla 10. 28: Datos requeridos protocolo: S.T.S.G expresivo.

Fecha

Total de Puntos:

Percentil

Rango de Edad:

Conclusiones

Observaciones

10.2.14 S.A.F

Tabla 10. 29: Datos requeridos protocolo: S.A.F.

Fecha Resultado Observaciones

10.2.15 T.A.R

Tabla 10. 30: Datos requeridos protocolo: T.A.R.

Fecha

Observaciones

Conclusiones


112

10.2.16 T.D.P.E.A.

Tabla 10. 31: Datos requeridos protocolo: T.D.P.E.A.

Fecha

Observaciones:

Conclusiones:

10.2.17 TEPROSIF

Tabla 10. 32: Datos requeridos protocolo: TEPROSIF.

Fecha

Respuesta Dislalia E. Silábica Sustitución Asimilación Total

Observaciones


113

11 ANEXO: DIAGNÓSTICOS DEL CECH

En este anexo se presenta los diagnósticos que se utilizan en el CECH, estos son estándar y

poseen un código identificador único.

11.1 Trastornos del Lenguaje en el Niño (1-7)

1. Desarrollo Normal del Lenguaje 2. Déficit de Lenguaje

2.1. Fonológico 2.2. Morfosintáctico 2.3. Semántico 2.4. Pragmático

3. Inicio tardío (IT) 4. Retraso en el desarrollo del Lenguaje (RDL) 5. Trastorno especifico del lenguaje (TEL)

5.1. Expresivo (TEL-E) 5.1.1. Rapin Dispraxia verbal 5.1.2. Déficit de programación fonológica 5.1.3. Conti Formulación sintáctica semántica

5.2. Mixto (TEL-ER) 5.2.1. Rapin Agnosia Auditivo Verbal 5.2.2. Déficit fonológico sintáctico 5.2.3. Conti sintáctico fonológico 5.2.4. Gramatical

5.3. Orden superior/Complejo 5.3.1. Rapin Síndrome de déficit léxico sintáctico 5.3.2. Síndrome Semántico Pragmático 5.3.3. Conti Impedimento pragmático puro 5.3.4. Impedimento pragmático plus

6. Trastorno del lenguaje Asociado/Secundario (TL) 6.1. Retardo Mental 6.2. Parálisis Cerebral 6.3. Trastorno Generalizado del Desarrollo 6.4. Síndrome de Down 6.5. Sd. De William 6.6. Sd. Moebius 6.7. Déficit Auditivo.

7. Trastorno Fonológico


114

11.2 Trastornos del Lenguaje Adulto (8-12)

8. Clasificación Clásica de las Afasias 8.1. Afasia Global 8.2. Afasia No Fluente Mixta 8.3. Afasia de Wernicke 8.4. Afasia de Broca 8.5. Afasia de Conducción 8.6. Afasia Anómica 8.7. Afasia Transcortical Motora 8.8. Afasia Transcortical Sensorial 8.9. Afasia Transcortical Mixta

9. Clasificación Cognitiva de las Afasias 9.1. Sordera Verbal Pura 9.2. Sordera para la forma de la palabra 9.3. Sordera para el significado de la palabra 9.4. Agnosia Fonológica 9.5. Disfasia Profunda 9.6. Agnosia Semántica 9.7. Demencia Semántica 9.8. Anomia Pura 9.9. Jergafasia 9.10. Anomia FonológicaTrastorno en el retén fonológico

10. Trastornos de Lectura 10.1. Alexia Pura 10.2. Dislexia Fonológica 10.3. Dislexia Superficial 10.4. Ceguera para el significado de las palabras 10.5. Dislexia de acceso semántico 10.6. Dislexia Profunda

11. Trastornos de la escritura 11.1. Disgrafia Superficial 11.2. Disgrafia Fonológica 11.3. Disgrafia de acceso semántico 11.4. Disgrafia profunda

12. Trastorno Cognitivo Comunicativo 12.1. Secundario a Demencia 12.2. Secundario a TEC


115

11.3 Trastornos Audiológicos (13-15)

13. Normoacusia 14. Hipoacusia

14.1. Conductivas 14.1.1. Leve 14.1.2. Moderada 14.1.3. Severa

14.2. Sensoriales 14.2.1. Leve 14.2.2. Moderada 14.2.3. Severa 14.2.4. Profunda

14.3. Neurales 14.3.1. Leve 14.3.2. Moderada 14.3.3. Severa 14.3.4. Profunda

14.4. Mixtas 14.4.1. Leve 14.4.2. Moderada 14.4.3. Severa 14.4.4. Profunda

14.5. Anacusia o Cofosis 15. Disfunción Tubaria

15.1. Mala 15.2. Regular 15.3. Permeable


116

11.4 Trastornos de la Voz (16-19)

Clasificación según Le Huche 16. Disfonía Disfuncional Simple

16.1. Patrón de tensión muscular (Tipo 1: Trastorno Isométrico Laríngeo, de Morrison) 16.2. Tipo 2: Contracción lateral 16.3. Tipo 3: Contracción supraglótica anteroposterior 16.4. Tipo 4: Afonía/Disfonía de conversión 16.5. Tipo 5: Disfonía psicógena con cuerdas vocales arqueadas 16.6. Tipo 6: Disfonía de transición del adolescente 16.7. Laringitis

17. Disfonía Disfuncional Complicada 17.1. Nódulo 17.2. Pólipo 17.3. Edema 17.4. Edema de Reinke 17.5. Hemorragia submucosa (hematoma cordal) 17.6. Granuloma de Contacto

18. Formas Particulares de Disfonías Disfuncionales 18.1. Ronquera Infantil 18.2. Disodea por inhibición vocal 18.3. Disfonía Espástica 18.4. Alteraciones vocales en la patología psiquiátrica 18.5. Presbifonía 18.6. Trastorno de la muda vocal 18.7. Disfonías de origen endocrino

19. Disfonías de origen orgánico 19.1. Laringitis 19.2. Traumatismos 19.3. Parálisis de cuerda vocal 19.4. Anomalías congénitas (lesiones estructurales mínimas) 19.5. Alteración orgánica extralaríngeas 19.6. Disfonías endocrinas 19.7. Papiloma 19.8. Cáncer Laríngeo 19.9. Quiste 19.10. Laringofísura


117

11.5 Trastornos del Habla y la Deglución (20-35)

20. Dislalia 20.1. Orgánica 20.2. Funcional 20.3. Audiógena

21. Disartria 21.1. Espástica 21.2. Fláccida 21.3. Mixta 21.4. Hipocinética 21.5. Hipercinética 21.6. Atáxica 21.7. Motoneurona Superior 21.8. Unilateral

22. Tartamudez 22.1. Primaria 22.2. Secundaria

23. Apraxia del Habla 24. Dispraxia Verbal 25. Disfagia

25.1. Oral 25.1.1. Leve 25.1.2. Moderada 25.1.3. Severa

25.2. Faríngea 25.2.1. Leve 25.2.2. Moderada 25.2.3. Severa

25.3. Esofágica 25.4. Orofaríngea

25.4.1. Leve 25.4.2. Moderada 25.4.3. Severa

26. Presbifagia 27. Trastorno Succión-Deglución 28. Insuficiencia Velofaríngea 29. Incompetencia Velofaríngea 30. Deglución Atípica 31. Respirador Oral 32. Trastorno de la Alimentación. 33. Taquilalia 34. Bradilalia 35. Farfulleo


118

12 ANEXO: CARTA DE APRO BACIÓN DE PROYECTO.

En la siguiente hoja, se presenta una carta enviada por el Cliente y Coordinador del CECH, Rodolfo Peña, para dar validez a este proceso de elicitación de requisitos.


119


Documents

Especificación de requisitos de software para el sistema ...repobib.ubiobio.cl/jspui/bitstream/123456789/686/1/Parra Urrea, Alfredo.pdf · 2 Resumen Este proyecto se presenta para