Especificación de requisitos de software para el sistema...
Transcript of Especificación de requisitos de software para el sistema...
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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,
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
34
Luego el administrador puede revisar los usuarios registrados, como se ve en la figura 4.6.
Figura 4. 6: Lista de Usuarios registrados.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
35
3. Buscar Paciente
Tabla 4. 4: Requerimiento buscar paciente.
Requerimiento: RF03 Tipo Requerimiento:
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
37
4. Ingresar un nuevo paciente
Tabla 4. 5: Requerimiento ingresar nuevo paciente.
Requerimiento: RF04 Tipo Requerimiento:
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
39
5. Crear ficha clínica
Tabla 4. 6: Requerimiento crear ficha clínica.
Requerimiento: RF05 Tipo Requerimiento:
funcional Eventos / Casos de Uso
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
44
6. Agregar consentimiento informado a la ficha clínica del paciente.
Tabla 4. 7: Requerimiento adjuntar consentimiento informado.
Requerimiento: RF06 Tipo Requerimiento:
funcional Eventos / Casos de Uso
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
46
7. Agregar programa fonoaudiológico a ficha clínica
Tabla 4. 8: requerimiento programa fonoaudiológico.
Requerimiento: RF07 Tipo
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ó
Autor: Rodolfo Peña
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.
Satisfacción del cliente: 5 Insatisfacción de los clientes: 3
Prioridad: Alta Conflictos: No posee.
Materiales de Soporte
Historia: 21-11-2013
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
48
8. Aplicar instrumento de evaluación
Tabla 4. 9: Requerimiento registrar examen.
Requerimiento: RF08 Tipo Requerimiento:
Funcional Eventos / Casos de Uso
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
52
9. Generar reporte estadístico
Tabla 4. 10: Requerimiento Generar reporte.
Requerimiento: RF09 Tipo Requerimiento:
Funcional Eventos / Casos de Uso
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.
Materiales de Soporte Historia: 21-11-2013
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
54
10. Coordinar horario
Tabla 4. 11: Requerimiento asignar horario a paciente.
Requerimiento: RF10 Tipo Requerimiento:
Funcional Eventos / Casos de Uso
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.
Materiales de Soporte Historia: 12-11-2013
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
56
11. Mostrar agenda horaria
Tabla 4. 12: Requerimiento mostrar agenda horaria del centro.
Requerimiento: RF11 Tipo Requerimiento:
funcional Eventos / Casos de Uso
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
58
12. Editar ficha clínica
Tabla 4. 13: Requerimiento editar registros erróneos.
Requerimiento: RF12 Tipo
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.
Autor: Rodolfo Peña
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.
Satisfacción del cliente: 5 Insatisfacción de los clientes: 4
Prioridad: Alta Conflictos Se perderá el registro de la
última modificación.
Materiales de Soporte
Historia: 21-11-2013
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
60
13. Control Histórico de fichas y usuarios
Tabla 4. 14: Requerimiento para resguardar la información histórica.
Requerimiento: RF13 Tipo
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.
Autor: Rodolfo Peña
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.
Satisfacción del cliente: 5 Insatisfacción de los clientes: 2
Prioridad: 4 Conflictos
Materiales de Soporte
Historia: 09-01-2014
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Flujo de Eventos Básicos:
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.
Flujo de Eventos Alternativo:
3a. El usuario cancela la operación.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
65
4a. El usuario ya está registrado con el mismo perfil en el sistema. Un usuario puede
ser registrado con diferentes perfiles.
Post-Condiciones: no posee.
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.
Actor Principal: Administrador.
Flujo de Eventos Básicos:
Tabla 4. 19: Flujo de eventos básicos, generar reporte.
Administrador El sistema
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.
Flujo de Eventos Alternativo:
3a. El usuario cancela la operación.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
66
6a. El sistema muestra mensaje de error, por fechas no válidas.
Post-Condiciones: no posee.
4. ID: CU04. Caso de Uso: Registrar paciente.
Descripción: El sistema debe permitir registrar un paciente.
Pre-Condiciones: El usuario debe estar registrado en el sistema.
Actor Principal: Fonoaudiólogo, Estudiantes.
Flujo de Eventos Básicos:
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
Flujo de Eventos Alternativo:
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.
Pre-Condiciones: El usuario debe estar registrado en el sistema.
Actor Principal: Fonoaudiólogo, Estudiante.
Flujo de Eventos Básicos:
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Flujo de Eventos Alternativo:
2a. El usuario cancela la operación.
2a.1. El sistema arroja un mensaje de error, especificando que no se puede cancelar,
dado que no ha terminado el proceso.
Post-Condiciones: no posee.
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.
Actor Principal: Fonoaudiólogo, Estudiante.
Flujo de Eventos Básicos:
Universidad del Bío-Bío. Red de Bibliotecas - Chile
68
Tabla 4. 22: Flujo de eventos básicos, agregar consentimiento informado.
Fonoaudiólogo/Estudiante El sistema
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.
Flujo de Eventos Alternativo:
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.
Post-Condiciones: no posee.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Pre-Condiciones: El usuario debe estar registrado en el sistema.
Actor Principal: Fonoaudiólogo, Estudiante.
Flujo de Eventos Básicos:
Tabla 4. 23: Flujo de eventos básicos, listar y buscar paciente.
Fonoaudiólogo/Estudiante El sistema
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
Flujo de Eventos Alternativo:
3a. El fonoaudiólogo/estudiante cancela la operación.
Post-Condiciones: El sistema debe crear una ficha clínica para el paciente creado.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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 paciente debe estar registrado en el sistema.
- El usuario debe estar registrado en el sistema
Actor Principal: Fonoaudiólogo, Estudiante.
Flujo de Eventos Básicos:
Universidad del Bío-Bío. Red de Bibliotecas - Chile
71
Tabla 4. 24: Flujo de eventos básicos, ver ficha paciente.
Fonoaudiólogo/Estudiante El sistema
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.2. Extiende al caso de uso: CU06.
4.3. Ejecuta el caso de uso: CU21.
4.4. Extiende al caso de uso: CU10.
4.5. Extiende al caso de uso: CU17.
4.6. Extiende al caso de uso: CU09.
Flujo de Eventos Alternativo:
3a.1. El fonoaudiólogo termina el proceso.
Post-Condiciones: no posee.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Flujo de Eventos Básicos:
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
73
Flujo de Eventos Alternativo:
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.
Post-Condiciones: no posee.
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.
Actor Principal: Fonoaudiólogo, Estudiante.
Flujo de Eventos Básicos:
Universidad del Bío-Bío. Red de Bibliotecas - Chile
74
Tabla 4. 26: Flujo de eventos básicos, agregar historial a ficha clínica.
Fonoaudiólogo/Estudiante El sistema
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.
Flujo de Eventos Alternativo:
3a.1. El fonoaudiólogo/estudiante cancela el proceso.
Post-Condiciones: no posee.
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.
Actor Principal: Fonoaudiólogo, Estudiante.
Flujo de Eventos Básicos:
Universidad del Bío-Bío. Red de Bibliotecas - Chile
75
Tabla 4. 27: Flujo de eventos básicos, ver horario.
Fonoaudiólogo/Estudiante El sistema
1. El fonoaudiólogo/estudiante desea
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.
Post-Condiciones: 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.
Flujo de Eventos Básicos:
Universidad del Bío-Bío. Red de Bibliotecas - Chile
76
Tabla 4. 28: Flujo de eventos básicos, reservar horario paciente.
Fonoaudiólogo/Estudiante El sistema
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.
Flujo de Eventos Alternativo:
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.
Flujo de Eventos Básicos:
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Flujo de Eventos Alternativo:
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.
Post-Condiciones: no posee.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Actor Principal: Fonoaudiólogo, Estudiante.
Flujo de Eventos Básicos:
Tabla 4. 30: Flujo de eventos básicos, ver exámenes.
Fonoaudiólogo/Estudiante El sistema
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.
Flujo de Eventos Alternativo:
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.
Post-Condiciones: no posee.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
79
15. ID: CU15. Caso de Uso: Ver perfil.
Descripción: El sistema muestra los datos del usuario registrado en el sistema.
Pre-Condiciones: El usuario debe estar registrado en el sistema.
Actor Principal: Todos.
Flujo de Eventos Básicos:
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.
Post-Condiciones: 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.
Pre-Condiciones: El usuario debe estar registrado en el sistema.
Actor Principal: Todos.
Flujo de Eventos Básicos:
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.
Flujo de Eventos Alternativo:
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Post-Condiciones: no posee.
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.
Pre-Condiciones: El usuario debe estar registrado en el sistema.
Actor Principal: Estudiante, Fonoaudiólogos.
Flujo de Eventos Básicos:
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.
Flujo de Eventos Alternativo:
Universidad del Bío-Bío. Red de Bibliotecas - Chile
81
3a. El usuario cancela la opción.
5a. El usuario cancela la opción.
7a. El usuario cancela la opción.
Post-Condiciones: no posee.
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.
Pre-Condiciones: El usuario debe estar registrado en el sistema.
Actor Principal: Estudiante, Fonoaudiólogos.
Flujo de Eventos Básicos:
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.
Flujo de Eventos Alternativo:
3a. El usuario cancela la operación.
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.
Post-Condiciones: no posee.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Actor Principal: Administrador.
Flujo de Eventos Básicos:
Tabla 4. 35: Flujo de eventos básicos, editar usuario.
Administrador El sistema
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.
Flujo de Eventos Alternativo:
3a. El usuario cancela la operación.
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
83
Post-Condiciones: no posee.
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.
Pre-Condiciones: El usuario debe estar registrado en el sistema.
Actor Principal: Todos.
Flujo de Eventos Básicos:
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.
Flujo de Eventos Alternativo:
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.
Pre-Condiciones: El usuario debe estar registrado en el sistema.
Actor Principal: Fonoaudiólogo, Estudiante.
Flujo de Eventos Básicos:
Universidad del Bío-Bío. Red de Bibliotecas - Chile
84
Tabla 4. 37: Flujo de eventos básicos, modificar horario paciente.
Fonoaudiólogo/Estudiante El sistema
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.
Flujo de Eventos Alternativo:
3a. El usuario cancela la opción.
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.
Post-Condiciones: no posee.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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 estar registrado en el sistema.
- El usuario debe querer realizar un examen.
Actor Principal: Fonoaudiólogo, Estudiante.
Flujo de Eventos Básicos:
Tabla 4. 38: Flujo de eventos básicos, Protocolos cualitativos.
Fonoaudiólogo/Estudiante El sistema
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.
Flujo de Eventos Alternativo:
2a. El usuario cancela la operación
Post-Condiciones: no posee.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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 estar registrado en el sistema.
- El usuario debe querer realizar un examen.
Actor Principal: Fonoaudiólogo, Estudiante.
Flujo de Eventos Básicos:
Tabla 4. 39: Flujo de eventos básicos, Protocolos cuantitativos.
Fonoaudiólogo/Estudiante El sistema
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.
3. El sistema almacena la información
del examen e indica que el examen ha
sido almacenado con éxito.
Flujo de Eventos Alternativo:
2a. El usuario cancela la operación.
Post-Condiciones: no posee.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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 estar registrado en el sistema.
- El usuario debe crear un programa asociado a un paciente.
Actor Principal: Fonoaudiólogo, Estudiante.
Flujo de Eventos Básicos:
Universidad del Bío-Bío. Red de Bibliotecas - Chile
88
Tabla 4. 40: Flujo de eventos básicos, Programa fonoaudiológico.
Fonoaudiólogo/Estudiante El sistema
1. El fonoaudiólogo/estudiante desea
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:
5.1. El usuario selecciona un objetivo
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.
6.2. El sistema abre una ventana e
inicia el caso de uso: CU25.
7. El usuario:
7.1. El usuario selecciona un objetivo
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.
8.2. El sistema abre una ventana e
inicia el caso de uso: CU25.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
89
Flujo de Eventos Alternativo:
1a. El usuario cancela la operación
3a. El usuario cancela la operación
5a. El usuario cancela la operación.
7a. El usuario cancela la operación
Post-Condiciones: no posee.
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 estar registrado en el sistema.
- El usuario debe crear un objetivo relacionado a un programa
fonoaudiológico de un paciente.
Actor Principal: Fonoaudiólogo, Estudiante.
Flujo de Eventos Básicos:
Universidad del Bío-Bío. Red de Bibliotecas - Chile
90
Tabla 4. 41: Flujo de eventos básicos, ingresar un objetivo.
Fonoaudiólogo/Estudiante El sistema
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.
3. El sistema almacena la información
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.
Flujo de Eventos Alternativo:
2a. El usuario cancela la operación.
Post-Condiciones: no posee.
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:
- El usuario debe estar registrado en el sistema.
- El paciente debe estar registrado en el sistema.
Actor Principal: Fonoaudiólogo, Estudiante.
Flujo de Eventos Básicos:
Universidad del Bío-Bío. Red de Bibliotecas - Chile
91
Tabla 4. 42: Flujo de eventos básicos, Protocolos cuantitativos.
Fonoaudiólogo/Estudiante El sistema
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.
Flujo de Eventos Alternativo:
2a. El usuario cancela la operación.
Post-Condiciones: no posee.
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:
- El usuario debe estar registrado en el sistema.
- El paciente debe estar registrado en el sistema.
Actor Principal: Administrador.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
92
Flujo de Eventos Básicos:
Tabla 4. 43: Flujo de eventos básicos, Protocolos cuantitativos.
Administrador El sistema
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.
Flujo de Eventos Alternativo:
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
Post-Condiciones: no posee.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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).
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
96
Figura 5. 1: Modelo de datos conceptual.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
9 Identificación, Elicitación de Requisitos 5 días 9/23/13 9/27/13
10 Análisis de Requisitos 5 días 9/25/13 10/1/13
11 Especificación de Requisitos 10 días 9/30/13 10/11/13
12 Realizar Prototipos 15 días 9/30/13 10/18/13
13 Validación y Negociación de Requisitos 5 días 10/14/13 10/18/13
14 Tercera Iteración 10 días 10/21/13 11/1/13
15 Identificación, Elicitación de Requisitos 3 días 10/21/13 10/23/13
16 Análisis de Requisitos 3 días 10/23/13 10/25/13
17 Especificación de Requisitos 3 días 10/28/13 10/30/13
18 Realizar Prototipos 5 días 10/28/13 11/1/13
19 Validación y Negociación de Requisitos 2 días 10/31/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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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:
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
CATEGORÍA DE RENDIMIENTO PUNTAJE TOTAL
Insuficiente 0- 29 puntos
Suficiente 30- 49 puntos
Bueno 50-68 puntos
Muy Bueno 69-98 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
CATEGORÍA DE RENDIMIENTO PUNTAJE TOTAL
Insuficiente 0- 29 puntos
Suficiente 30- 49 puntos
Bueno 50-68 puntos
Muy Bueno 69-98 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:
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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
Universidad del Bío-Bío. Red de Bibliotecas - Chile
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.
Universidad del Bío-Bío. Red de Bibliotecas - Chile
119
Universidad del Bío-Bío. Red de Bibliotecas - Chile