DUOC UC - Escuela de Salud Propuesta de Proyecto y Especificación de Requisitos de Software Proyecto: ELECTROSALUD Revisión: [01] 19/11/2018 Planificación y Especificación de Requisitos según estándares; IEEE 830, ISO9000 y PMI. Especificación de Requisitos, estándar de IEEE 830 Contenido FICHA DEL DOCUMENTO .............................................................................................................................. 3 1. INTRODUCCIÓN.................................................................................................................................. 4 1.1. 1.2. 1.3. 1.4. 1.5. 2. DESCRIPCIÓN GENERAL ....................................................................................................................... 7 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 3. PROPÓSITO ....................................................................................................................................... 4 ÁMBITO DEL SISTEMA ....................................................................................................................... 4 DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS ................................................................................ 4 REFERENCIAS ................................................................................................................................... 6 VISIÓN GENERAL DEL DOCUMENTO ................................................................................................. 6 PERSPECTIVA DEL PRODUCTO ......................................................................................................... 7 FUNCIONES DEL PRODUCTO ............................................................................................................ 8 CARACTERÍSTICAS DE LOS USUARIOS ............................................................................................. 9 RESTRICCIONES................................................................................................................................ 9 SUPOSICIONES Y DEPENDENCIAS .................................................................................................. 10 REQUISITOS FUTUROS ................................................................................................................... 11 REQUISITOS ESPECÍFICOS ........................................................................................................ 11 .3.1 REQUISITOS COMUNES DE LAS INTERFACES .................................................................................. 11 3.1.1 Interfaces de usuario........................................................................................................... 11 3.1.2 Interfaces de hardware ....................................................................................................... 12 3.1.3 Interfaces de software......................................................................................................... 12 3.1.4 Interfaces de comunicación ............................................................................................... 12 3.2 REQUISITOS FUNCIONALES............................................................................................................. 12 3.3 REQUISITOS NO FUNCIONALES ....................................................................................................... 13 3.3.1 Requisitos de rendimiento .................................................................................................. 13 3.3.2 Seguridad ............................................................................................................................. 14 3.3.3 Fiabilidad............................................................................................................................... 14 3.3.4 Disponibilidad ....................................................................................................................... 14 3.3.5 Mantenibilidad ...................................................................................................................... 15 3.3.6 Portabilidad ........................................................................................................................... 15 3.4 OTROS REQUISITOS ....................................................................................................................... 15 4. PROPUESTA DE PLANIFICACIÓN ................................................................................................. 15 4.1 DESCRIPCIÓN GENERAL ACERCA DE LA PLANIFICACIÓN ...................................................................... 15 4.1.2 Definición del Equipo de Trabajo .............................................................................................. 15 4.1.3 Definición de Actividades principales del Proyecto ................................................................ 16 4.1.4 Diagrama EDT ............................................................................................................................. 17 4.1.5 Carta Gantt ................................................................................................................................... 18 4.1.6 Resumen Costos del Desarrollo del Proyecto ........................................................................ 18 4.2 PLAN DE CONTROL DE CAMBIO............................................................................................................. 19 5. ANEXOS................................................................................................................................................... 20 5.1 Acta de Proyecto ............................................................................................................................ 20 5.2 Matriz Especificación de Requerimientos ................................................................................... 24 2 Especificación de Requisitos, estándar de IEEE 830 5.3 Diagrama de Casos de Uso General .......................................................................................... 27 5.4 Planilla Casos de Uso .................................................................................................................... 29 5.5 Prototipado de Software ................................................................................................................ 31 5.6 Resultado Análisis de Calidad Diagramas Modelamiento ....................................................... 38 5.7 Resultado Análisis de Calidad Prototipado No funcional del Sistema ................................... 38 5.8 Planilla entregables del Proyecto ................................................................................................. 38 5.9 Matriz de Control de Cambios ...................................................................................................... 38 5.10 Matriz EDT. Planilla Detallada Cálculo de Esfuerzo ............................................................... 39 Ficha del documento Fecha 19/11/2018 Revisión 1 Autor Yuliana Aracena Javiera Rodriguez Modificación Desarrollo de la Propuesta de Proyecto y Especificación de Requisitos de Software Documento validado por las partes en fecha: 19 de noviembre del 2018 Integrantes: Nombre Integrante del Equipo Rol Definido Javiera Rodriguez Jerez Ingeniero de Software Matías Roa Roa Diseñador Jenniffer Astudillo Tapia Responsable de Pruebas y Calidad Yuliana Aracena Pérez Jefe de Proyecto 3 Especificación de Requisitos, estándar de IEEE 830 1. Introducción 1.1. Propósito El siguiente documento tiene como propósito definir las especificaciones de requerimientos de software tanto funcionales como no funcionales para la implementación de una ficha clínica electrónica que registrará y administrará todos los datos y antecedentes clínicos de los usuarios que se atenderán en el Servicio de salud Duoc UC, que será utilizado por los profesionales de salud. 1.2. Ámbito del Sistema La ficha clínica electrónica será un programa de software que funcionará en sistemas operativos de Windows 10, que permitirá el ingreso, registro, consulta y administración de datos clínicos y antecedentes de los usuarios. A través de este software podrán inscribir consultas médicas, inscribir y actualizar datos de los pacientes, agregar motivos de consultas y diagnósticos, consultar horas tomadas con profesionales de salud, consultar datos de los profesionales y personal de salud, adjuntar exámenes médicos, escribir recetas médicas electrónicas, generar estadísticas y reportes. Este sistema no permitirá la abertura de más de 3 fichas clínicas de forma simultánea por el resguardo y seguridad de los datos clínicos y para evitar la sobrecarga del sistema, además se cerrará de sesión automáticamente si no ha sido usado en 10 minutos. 1.3. Definiciones, Acrónimos y Abreviaturas Inscripción de consultas médicas: proceso en el cual el administrador o médico deja registrado las próximas citas médicas de los usuarios. Administrar: Acción de agregar, modificar, eliminar y consultar la información de un usuario. Motivo de consulta: razón por la cual el usuario decide atenderse en el servicio de urgencias. 4 Especificación de Requisitos, estándar de IEEE 830 Diagnóstico: resultado de la atención de salud de los usuarios que permitirá entregar los tratamientos adecuados a ellos. Reporte: organiza y exhibe la información contenida en una base de datos. Receta médica electrónica: módulo de la FCE que permite el registro del nombre, run, servicio del médico, nombre comercial o principio activo, dosis, horario, vía de administración del medicamento, concluyendo con el timbre médico electrónico. FCE: ficha clínica electrónica. Usuario final: persona natural con acceso autorizado para su ingreso a la ficha clínica electrónica. Permiso: parámetro que especifica si su poseedor dispone de acceso a una determinada función del sistema o a una parte de la interfaz de usuario del sistema. Administrador del Sistema: persona encargada de ofrecer el soporte técnico y operativo al sistema, queda a cargo del departamento de informática del servicio de salud. Base de datos: es un conjunto de datos que pertenecen al mismo contexto almacenados sistemáticamente para su posterior uso. Sistema de gestión de base de datos: son un tipo de software muy específico, dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan. Aplicación o software: es un programa informático diseñado para facilitar al usuario la realización de un determinado tipo de trabajo. MySQL: sistema de gestión de base de datos relacional. 5 Especificación de Requisitos, estándar de IEEE 830 1.4. Referencias Documento Planificación y especificación de Referencia IEEE 830, ISO 9000 y PMI requisitos según estándares. Ingeniería del software, un enfoque practico Protocolo de registro, gestión y http://www.academia.edu/download/45525376/Ingenier ia.de.software.enfoque.practico.7ed.Pressman.PDF http://200.72.129.100/calidad/archivo1/Manejo%20Fich manejo de ficha clínica única a%20-%20REG%201.1_v.7.pdf 1.5. Visión General del Documento En el presente documento se encontrará la información acerca de las características del sistema de software, interfaces del usuario, interfaces del sistema, características de los usuarios, descripción de los requerimientos funcionales, no funcionales y del sistema. El documento concluye con las propuestas de planificación del producto entregable, con definición del equipo de trabajo, actividades relacionadas, Carta Gantt y estimado presupuestario del costo del sistema. 6 Especificación de Requisitos, estándar de IEEE 830 2. Descripción General 2.1. Perspectiva del Producto El programa de software de la FCE estará diseñado para trabajar en sistemas operativos Windows 10, siendo de preferencia el primer por la simplicidad de su interfaz gráfica de usuarios. Este producto trabajará de forma independiente, por lo que no dependerá de otros sistemas mayores. Ingreso de información al sistema Acceso de usuarios autorizados Registro de horas médicas Registro de motivos de consultas Diagnósticos, tratamientos y procedimientos del servicio de urgencias Registro de receta médica electrónica Registro de datos del personal de salud Registro de la información Módulo de atención de urgencias Módulo de Farmacias Módulo de consulta de datos del personal Almacenamiento de la Información Servidor que contiene una base de datos que es administrada por el departamento de informática del servicio de salud. La base de datos es invisible para los usuarios Salida de Información Estadísticas y reportes Receta médica electrónica Ficha clínica electrónica visualizada Resumen de atención médica Cierre de sesión de usuarios 7 Especificación de Requisitos, estándar de IEEE 830 2.2. Funciones del Producto a) Inscripción de consultas médicas: proceso en el que quedan registradas las horas médicas de los pacientes. b) Registro de datos de los pacientes: registro de los datos indispensables de los pacientes para el llenado de su ficha clínica electrónica. c) Registro de motivos de consultas: el administrador podrá ingresar los motivos de consultas en el módulo de atenciones de urgencias para su consiguiente admisión. d) Registro de diagnósticos: el médico podrá registrar en el módulo de urgencias u otros servicios médicos los diagnósticos resultantes de las atenciones de los pacientes e) Adjunción de exámenes médicos: se tendrá un módulo especifico de exámenes médicos realizados que quedan registrado en la ficha clínica electrónica de forma única. f) Consultas de horas de atención: proceso en el cual los usuarios finales pueden buscar información sobre las horas agendadas. g) Consultar de datos de los profesionales y personal de salud: proceso en el cual los usuarios finales pueden buscar información sobre datos de los trabajadores del servicio de salud. h) Registro de recetas médicas electrónicas: módulo de la ficha clínica electrónica que permite la generación de una receta médica digital, con una notificación enviada a Farmacia. i) Generación estadísticas y reportes: estos datos son administrados por el departamento de informática para desarrollar posibles soluciones o ajustes del software. 8 Especificación de Requisitos, estándar de IEEE 830 2.3. Características de los Usuarios La interacción con el software contará con acceso de tres tipos de usuarios: Administrador Técnico, Administrador Profesional y Administrador del Sistema: a) Administrador Técnico: corresponde a un tipo de usuario final cuya función en registrar datos que permitan la admisión de los pacientes para su consiguiente atención. Están autorizados a admitir al paciente a urgencias, a agendar horas médicas, consultar horas agendadas y datos del personal, consultar recetas médicas activas. Idealmente debe contar con manejo básico de sistemas Windows. b) Administrador Profesional: usuario que corresponden a profesionales de salud, los cuales pueden registrar diagnósticos, adjuntar exámenes, registrar y autorizar recetas médicas. Debe poseer conocimientos medios de sistemas operativos Windows. c) Administrador del Sistema: Usuario con gran conocimiento en el manejo del sistema con una previa capacitación. Encargado de manejar el sistema con gran responsabilidad sobre los criterios de permisos sobre los usuarios. 2.4. Restricciones a) Políticas de la empresa: la licencia del software es de tipo privativo, debido a que éste es único para el Servicio de salud Duoc UC; en caso de que otra entidad quisiera adquirir este producto, requiere una autorización a los distribuidores. b) Limitaciones del hardware: para la instalación del programa se requiere un computador servidor que soporte MySQL y Java. c) Interfaces con otras aplicaciones: el software es autónomo y no necesita conexiones con otros sistemas. d) Operaciones paralelas: no corresponde a condición del proyecto. 9 Especificación de Requisitos, estándar de IEEE 830 e) Funciones de auditoría: es importante la puesta en marcha y el control de todas las modificaciones al sistema operativo, y en general, de todo el software de base del sistema.es necesario establecer controles y restricciones adecuados para evitar los cambios desautorizados en el software del sistema. f) Funciones de control: el software debe controlar los permisos que tiene cada tipo de usuario para su accesibilidad, de tal forma que pueda acceder la información que le corresponde según su tipo. g) Lenguaje(s) de programación: se accederá a una base de datos MySQL y la aplicación es desarrollada en JAVA. h) Protocolos de comunicación: Todo el material que se realice para el usuario y la aplicación debe de estar en lenguaje español. i) Requisitos de habilidad: el registro de datos clínicos y atenciones en salud y la programación de horas médicas deben estar ajustados a la realidad para que funcione óptimamente. j) Criticidad de la aplicación: para garantizar su funcionamiento el sistema deberá ser sometido a una serie de pruebas para establecer que se encuentra acorde a los requerimientos que se plasman en el documento en tanto a la consistencia de datos como al rendimiento de la aplicación, tales como tiempos de respuesta. k) Consideraciones acerca de la seguridad: cada usuario deberá autenticarse y su acceso verificado de acuerdo con lo que su tipo especifique. Todas las claves de seguridad deberán estar seguras y en su defecto encriptadas en la base de datos para dar una buena seguridad al sistema y su información. 2.5. Suposiciones y Dependencias Debe realizarse una capacitación adecuada y acorde a lo que cada usuario va a realizar. Su capacitación de hará en el momento que sea necesaria y a las personas indicadas. Sólo se trabajará con el software en sistemas operativos Windows 10 Especificación de Requisitos, estándar de IEEE 830 2.6. Requisitos Futuros El software estará habilitado para actualizaciones o mejoras si se presentan. El software podría trabajar con otros sistemas de software compatible para la ampliación del flujo de información entre redes asistenciales. Requisitos Específicos 3. Por medio de la reunión ya realizada con las partes involucradas el cliente expresa que espera que el proyecto cuente con optimizar el tiempo de espera y conexiones con los departamentos de Urgencias, Farmacias y Departamento de Informática. En la institución existen aún ficha de papel las cuales poseen problemas como: Congestión en el ingreso de pacientes. Demora en el llenado de la ficha. Tiempo consumido del personal administrativo. Duplicas de información y recetas médicas. Por esta razón los requisitos específicos con los que debe contar el proyecto son: 3.1 Modernización de las fichas clínicas usadas en los servicios. Informatización del registro clínico Levantamiento de información. Capacitación del personal. Evitar duplicidad de ordenes médicas de exámenes. Requisitos comunes de las interfaces La entrada de los sistemas será de distintos departamentos, la salida ira orientada a un solo sistema. 3.1.1 Interfaces de usuario La interfaz será una amigable con el profesional de salud, el cual estará enfocado a un entendimiento rápido y sencillo, donde solo deberá rellenar casillas. 11 Especificación de Requisitos, estándar de IEEE 830 3.1.2 Interfaces de hardware El software deberá mostrar información al usuario a través de la pantalla del monitor para así poder entregarle una mejor atención a los pacientes. 3.1.3 Interfaces de software El producto poseerá un sistema operativo Windows 10 ya que posee un mejor soporte actualmente. Este sistema permitirá futuras actualizaciones del software. 3.1.4 Interfaces de comunicación La interfaz de comunicación entre el servidor de base de datos MySQL y la aplicación desarrollada en JAVA se lo realiza mediante JDBC. 3.2 Requisitos funcionales 1. Autenticar el ingreso a registro clínico electrónico permitirá al usuario ingresar con un perfil entregado por el sistema para interactuar con ella, ingresando run sin digito verificador con contraseña asignada por el sistema. 2. Ingreso de datos clínicos en módulos de la ficha clínica permite ingresar todos los datos clínicos que el paciente entregan para formar su historial médico. 3. Acceso a receta médica de planilla estándar Corresponde a documento Word en donde se encuentran los datos necesarios para la generación de una receta según las condiciones mínimas necesarias: nombre del médico, RUN, fecha de emisión, medicamento, dosis, horario firma y timbre médico. 4. Impresión de receta médica Luego de la competición de la receta, se imprime para entregar al paciente, con una copia electrónica que llega a la base de datos del servicio de Farmacia. 5. Adjunción de exámenes médicos a ficha clínica Corresponde a un módulo definido en la ficha clínica electrónica en donde se crea carpetas predefinidas de exámenes según su naturaleza. 12 Especificación de Requisitos, estándar de IEEE 830 6. Ingreso de fechas de consultas médicas Módulo que permite el registro de las horas médicas de los pacientes. 7. Acceso y autenticación en ingreso a BBDD del servicio Manejo de la interfaz entre los datos ingresados a nivel usuario y los datos reales almacenados a los cuales el personal de informática sólo tiene acceso. 8. Timbre electrónico del médico Permite la validación de la entrega de los medicamentos. 9. Acceso a historial médico Permite revisar y analizar el historial médico del paciente. 10. Agregar diagnostico Ingresar diagnostico entregado por el médico durante la atención de los pacientes. 11. Generar reportes en salud Genera reportes para los indicadores de salud a nivel nacional. 12. Modificar horario de consultas médicas Permite la modificación, postergación y eliminación de horas médicas. 13. "Log Out" de la ficha clínica Permite el cierre de sesión del usuario evitando su uso por terceros. 3.3 Requisitos no funcionales 1. Manejo de fichas clínicas electrónicas en sistemas operativos Windows Es el sistema operativo adecuado para manejar y manipular el programa de la FCE con seguridad y agilidad. 2. Accesos restringidos a BBDD Sólo personal autorizado puede acceder a este tipo de información. 3.3.1 Requisitos de rendimiento La infraestructura de red, así como sus terminales deben cumplir con normas según la IEEE en la forma de conexión a los equipos, para tener tiempos de respuesta mínimos: 13 Especificación de Requisitos, estándar de IEEE 830 Numero de terminales a manejar: Se contará con un servidor de base de datos en la matriz de la cooperativa. Número de usuarios simultáneos: El número de usuarios que interactuaran simultáneamente con nuestro sistema es de 3 usuarios. Número de transacciones a manejar dentro de ciertos periodos de tiempo: Se estima que se manejará alrededor 100 ingresos de pacientes durante el día, tomando que se realizaran aproximadamente 200 operaciones diarias, como ingresos, salidas de pacientes. El servidor de base de datos deberá tener un respaldo apropiado, así como personal técnico listo para cualquier eventualidad. 3.3.2 Seguridad La seguridad del sistema es por: Uso de contraseñas para cada usuario. Esto permitirá que tengan acceso al sistema solo las personas que tienen autorización. Registros de ingreso al sistema. Creación de roles y asignarlos a cada usuario dependiendo su funcionalidad. 3.3.3 Fiabilidad Es uno de los factores que dará confianza al cliente, para lo cual el sistema está controlando todo tipo de transacción y esta apto a responder todo tipo de incidente. 3.3.4 Disponibilidad El sistema ha sido desarrollado tomando en cuenta las necesidades, requerimientos, reglas, política, misión, objetivos etc. De la cooperativa, por lo que se encuentra disponible el 99% del tiempo. 14 Especificación de Requisitos, estándar de IEEE 830 3.3.5 Mantenibilidad El sistema cuenta con características parametrizables lo que permitirá futuros mantenimientos. Es decir, cada tres meses se va a realizar un mantenimiento preventivo, encargado de hacerlo están los desarrolladores. Se realizará el mantenimiento dos veces sin ningún recargo económico, pasados estas dos revisiones tendrán costos adicionales. 3.3.6 Portabilidad Una de las ventajas de utilizar herramientas y lenguajes basados en software libre estamos garantizando la portabilidad. De esta manera: 99.9% es portable la aplicación por el simple hecho de utilizar el lenguaje y plataforma JAVA. 99% es portable la base de datos MySQL, es decir, Windows puede sostenerlo. 3.4 Otros Requisitos NA 4. Propuesta de Planificación 4.1 Descripción general acerca de la Planificación [Insertar una descripción de cómo se abordará el trabajo en cuanto a los días totales estimados y las personas involucradas en su ejecución, las buenas prácticas y condiciones necesarias a considerar para implementar para su buen término] 4.1.2 Definición del Equipo de Trabajo Nombre Integrante del Equipo Rol Definido Javiera Rodriguez Jerez Ingeniero de Software Matías Roa Roa Diseñador Jenniffer Astudillo Tapia Responsable de Pruebas y Calidad Yuliana Aracena Pérez Jefe del Proyecto 15 Especificación de Requisitos, estándar de IEEE 830 4.1.3 Definición de Actividades principales del Proyecto [Descripción de las Principales fases y actividades que considera nuestra Programación de la Planificación argumentando baj o que estándares y buenas prácticas se basan (Gestión de la planificación PMI e Ingeniería de Software – es sólo enunciarlas] 16 Especificación de Requisitos, estándar de IEEE 830 4.1.4 Diagrama EDT EDT - Planilla Estructura de descomposición de tareas Fase de Análisis y diseño Captura de requerimientos específicos Análisis de requerimientos Diseño de la solución. Modelamientos Propuesta ERS Plan de proyecto Fase de Desarrollo Implementación ambiente de desarrollo Construcción componente 1 Construcción componente 2 Construcción componente 3 Construcción componente 4 Construcción componente 5 Integración del sistema Fase de implementación y cierre Pruebas unitarias componente 1, 2 Pruebas unitarias componente 3, 4 Pruebas unitarias componente 5 Pruebas de integración Migración del sistema a producción Pruebas de integración final Marcha blanca Capacitación Cierre de proyecto DIAS 14 7 2 1 2 5 3 5 3 3 7 5 1 1 1 1 7 3 7 7 0 ROL 1 2 2 1 3 6 ROL 1 1 0 0 0 0 0 4 ROL 1 2 2 2 4 1 3 2 2 0 ROL 2 8 4 2 4 6 ROL 2 2 3 6 6 6 6 6 ROL 2 5 4 4 8 3 4 3 3 0 ROL 3 8 8 8 6 6 ROL 3 2 5 8 6 8 6 8 ROL 3 6 6 6 8 5 4 5 4 0 ROL 4 5 8 8 5 6 ROL 4 2 4 3 4 3 5 6 ROL 4 3 4 3 8 6 4 6 3 0 RO L5 1 1 1 4 6 RO L5 2 2 3 3 4 5 3 RO L5 3 3 3 8 8 4 8 6 0 DICCIONARIO EDT ROL ACTOR ROL 1 ROL 2 ROL 3 ROL 4 ROL 5 NOMBRE ACTOR Gerente de Proyecto Lider de Proyecto Ingeniero de Sotfware Diseñador Resp. Prueba y de calidad 17 Especificación de Requisitos, estándar de IEEE 830 4.1.5 Carta Gantt 4.1.6 Resumen Costos del Desarrollo del Proyecto Costo Se evaluará un monto disponible para el Desarrollo Que el costo del del Sistema como Costo que oscila entre los Desarrollo se encuentre $28.000.000 y los $30.000.000 según la solución entre el rango de monto que se defina como factible. en dinero expresado. 18 Especificación de Requisitos, estándar de IEEE 830 4.2 Plan de Control de Cambio [Se recomienda primero describir los tipos de cambio que se podrán resolver y sus alcances] [Insertar Tabla de Control de Cambios] [ Obs. Insertar Descripción de los aspectos del desarrollo en los que se permitirá aplicar cambios como parte del Desarrollo del Software definiendo sus alcances y limitaciones asociadas. El control de cambios es una actividad paralela al desarrollo del proyecto que responde a eventos que surgen del mismo, sea por requerimientos propios del usuario o por mejoras o correcciones detectadas por el mismo equipo del proyecto. Se describe de manera independiente de las demás fases de la metodología pues puede ser aplicada indistintamente a proyectos en marcha o proyectos ya implementados, y porque es necesario resaltar su importancia y no relegarla como una actividad posterior al desarrollo, sino reconocerla como una actividad que debe estar definida, presente y es crítica desde el inicio del proyecto. Deberá describir que tipo aspectos Funcionalidades y no funcionales se podrán modificar con cambio, en que instancia de proyecto se podrán aplicar y que motivos los validarían para ser aplicables y en qué caso no será posible aplicar cambios. Luego esto se debe complementar con la observación de que en el anexo encontrarán la Planilla de Control de Cambio con los Tipos de Cambio que podrán aplicarse en la cual posteriormente se debe completar la planilla al ejecutarse la instancia. ] 19 Especificación de Requisitos, estándar de IEEE 830 5. Anexos 5.1 Acta de Proyecto Nombre del Proyecto Ficha Clínica Electrónica ELECTROSALUD Cliente Servicio de Salud Duoc UC Stakeholder (Nombre/Cargo) Director del Servicio de Salud Duoc UC Jefe de Proyecto / Integrantes del Equipo Yuliana Aracena Pérez– Jefe del Proyecto Jenniffer Astudillo Tapia – Responsable de Pruebas y Calidad Matías Roa Roa – Diseñador del Sistema Javiera Rodriguez Jerez – Ingeniero de Software Tiempos Asociados (Inicio y Término) Objetivo del Negocio “El objetivo principal de nuestra red de salud es entregar una atención equitativa y de calidad centrada en las personas y sus familias, enfocada en lo preventivo y promocional, es decir, anticipándose a la enfermedad, bajo el Modelo de Salud Integral con enfoque familiar y comunitario” – Servicio de Salud Duoc UC Necesidad Modernizar el servicio de atención de urgencias, optimizando el ingreso de pacientes a través de fichas digitalizadas. Se espera que la ficha de atención y la ficha de solicitud de medicamentos se automaticen a través de un sistema que permita realizar este proceso de manera digital disminuyendo los tiempos del proceso, fortaleciendo el sistema de atención. 20 Especificación de Requisitos, estándar de IEEE 830 Solución Desarrollo de una Ficha Clínica Electrónica única para el servicio de salud en cuestión, que cuente con diferentes módulos para entregar una atención integrada e interconectada a los pacientes que se atiendan con el objetivo de reducir los tiempos del proceso e integrándose a las nuevas tecnologías en salud. Objetivo del Proyecto Informatizar el desarrollo de nuevas fichas clínicas de los pacientes, con la digitalización de fichas ya existentes, a través de la creación de un sistema informático capaz de resguardar, asegurar y manejar los datos clínicos que se generan en el servicio de salud, permitiendo una atención de calidad a los pacientes. Objetivos del Desarrollo Desarrollar e implementar a nivel del PC escritorio un sistema informático íntegramente en JAVA, con una base de datos desarrollada en MySQL, con una interfaz de aplicación de fácil acceso para todos los usuarios del sistema. Descripción de Sistema (Perspectivas del Producto / Funciones / Características de Usuarios) - Sistema de ingreso autenticado con Rut y contraseña asignada por área de informática del servicio de salud. - Software con diferentes módulos y carpetas de acceso de atención especificada e integrada con todos los servicios del establecimiento. - Interconexión de módulo de urgencias y farmacias a través de la generación y envió de receta médica electrónica. - Registro, consultas y modificaciones de horas asignadas según agenda médica. - Registro de motivos de consultas y diagnósticos de las atenciones. - Generación de estadísticas y reportes para indicadores de salud. - Consultas de datos del personal de salud. 21 Especificación de Requisitos, estándar de IEEE 830 Alcances y Restricciones Alcances del Proyecto: El proyecto se llevará a cabo con reuniones definidas en conjunto entre ambas partes y formalizadas en el Carta Gantt del Proyecto. La fecha de inicio del Proyecto se definirá a partir de la firma de contrato por ambas partes. Los plazos acordados para el desarrollo e implementación del sistema partirán de la fecha de inicio de la firma de contrato. Debe existir por parte del Cliente, un Stakeholder que cumpla la función de aportar información de negocio fidedigna para el levantamiento de información. Alcances y Restricciones del Proyecto: - El sistema es de uso único para el servicio de salud que lo contrató. - El sistema es compatible con sistemas mayores para el flujo de información y trabaja de forma independiente. - Una vez que el producto entregable es finalizado, la responsabilidad del sistema cae en manos del encargado del área de Informática del servicio de salud. - El sistema no permite la apertura de más de 3 fichas de forma simultaneas por seguridad y para evitar la sobrecarga del software. - El software es sólo compatible con sistemas operativos de Windows. - El sistema permite la digitalización de fichas clínicas ya existentes, con el objetivo de no perder la información clínica. - Los usuarios del sistema se diferencias según las facultades entregadas por el Administrador del Sistema. - El módulo de Farmacias cuenta con acceso a un vademécum para revisar información farmacológica. - Si el usuario iniciado no utiliza el sistema dentro un periodo de 15 minutos, éste se cerrará de forma automática para la protección de datos sensibles. 22 Especificación de Requisitos, estándar de IEEE 830 Especificaciones Técnicas de Herramientas de Desarrollo JAVA Base de Datos MySQL Tipo de Interfaz de Hardware Computador escritorio con procesador Dual Core de 3,8 GHz con 4 GB de RAM, disco de 500 GB a 7.200 rpm y conexión LAN de 1 Gb/s Monitor screen 17” – 19” Impresora multifunctional HP Officejet Pro 8720 Tipo de Interfaz de Software Windows 10 Tipo de Interfaz de Usuario Interfaz Gráfica de Usuario El software se ejecuta en ventana en Escritorio Windows de forma máxima y mínima 23 Especificación de Requisitos, estándar de IEEE 830 5.2 Matriz Especificación de Requerimientos RF. RF. 1 Nombre Autenticar el Tipo Actores relacionados Funcional Todos los usuarios Descripción Permitirá al usuario ingreso a ingresar con un perfil registro clínico entregado por el sistema electrónico para interactuar con ella, ingresando Rut sin digito verificador con contraseña asignada por el sistema. RF. 2 Ingreso de datos clínicos RF. 3 Funcional Administrador Técnico y Profesional Permite ingresar todos los datos clínicos que el en módulos de paciente entregan para la ficha clínica formar su historial médico. Acceso a receta médica Funcional Administrador Profesional Corresponde a documento Word en donde se de planilla encuentran los datos estándar necesarios para la generación de una receta según las condiciones mínimas necesarias: nombre del médico, RUN, fecha de emisión, medicamento, dosis, horario firma y timbre médico. 24 Especificación de Requisitos, estándar de IEEE 830 RF. 4 Impresión de Funcional Administrador receta Profesional médica Luego de la competición de la receta, se imprime para entregar al paciente, con una copia electrónica que llega a la base de datos del servicio de Farmacia RF. 5 Adjunción de Funcional Administrador exámenes Profesional Corresponde a un módulo definido en la ficha clínica médicos a electrónica en donde se ficha clínica crea carpetas predefinidas de exámenes según su naturaleza. Módulo que consultas registro de médicas médicas de los pacientes. RF. 6 Ingreso de RF. 7 Manejo de FCE en Funcional Administrador Técnico No Todos los usuarios Funcional permite las el horas Es el sistema operativo adecuado para manejar y sistema manipular el programa de operativo las Windows. electrónicas con seguridad fichas clínicas y agilidad. RF. 8 Acceso y autenticación Funcional Administrador del Sistema Manejo de la interfaz entre los datos ingresados a en ingreso a nivel usuario y los datos BBDD del reales almacenados a los servicio cuales el informática personal sólo de tiene acceso. 25 Especificación de Requisitos, estándar de IEEE 830 RF. 9 Acceso No Administrador del restringido a Funcional Sistema electrónico Funcional Administrador Profesional del médico RF.11 Acceso a historial diagnostico Permite la validación de la entrega de los medicamentos. Funcional Administrador Profesional médico RF.12 Agregar puede acceder a este tipo de información. BBDD RF.10 Timbre Sólo personal autorizado Permite revisar y analizar el historial médico del paciente. Funcional Administrador Profesional Ingresar diagnostico entregado por el médico durante la atención de los pacientes. RF.13 Generar reportes en Funcional Administrador del Sistema salud RF.14 Modificar Genera reportes para los indicadores de salud a nivel nacional. Funcional Administrador Técnico Permite la modificación, consultas postergación y eliminación médicas de horas médicas. RF.15 "Log Out" de Funcional Todos los usuarios Permite el cierre de sesión la ficha del usuario evitando su clínica uso por terceros. 26 Especificación de Requisitos, estándar de IEEE 830 5.3 Diagrama de Casos de Uso General 27 Especificación de Requisitos, estándar de IEEE 830 28 Especificación de Requisitos, estándar de IEEE 830 5.4 Planilla Casos de Uso Caso de Uso Caso de Uso n°1 Actores Administrador Profesional Tipo Caso de Uso primario Referencias 1.- Acceso autenticado al sistema 2.- Registro de datos 3.- Acceso a receta médica electrónica 4.- Adjunción de exámenes 5.- Acceso a Historial Médico 6.- Log out de la ficha clínica electrónica Precondición Para el uso óptimo del sistema, éste debe encontrarse en el escritorio para su fácil acceso. Postcondición El sistema podrá ser utilizado por el usuario según sus facultades. Descripción El usuario podrá acceder al sistema para registrar diagnósticos, adjuntar exámenes, registrar y autorizar recetas médicas. Caso de Uso Caso de Uso n°2 Actores Administrador Técnico Tipo Caso de Uso primario Referencias 1.- Acceso autenticado al sistema 2.- Registro de horas médicas 3.- Registro de datos de los pacientes 4.- Consultas al sistema 5.- Log out de la ficha clínica electrónica Precondición Para el uso óptimo del sistema, éste debe encontrarse en el escritorio para su fácil acceso. Postcondición El sistema podrá ser utilizado por el usuario según sus facultades. Descripción El usuario está habilitado admitir al paciente a urgencias, a agendar horas médicas, consultar horas agendadas y datos del personal, consultar recetas médicas activas. 29 Especificación de Requisitos, estándar de IEEE 830 Caso de Uso Caso de Uso n°3 Actores Administrador del Sistema Tipo Caso de Uso primario Referencias 1.- Acceso autenticado al sistema 2.- Administración de BBDD 3.- Administración de usuarios 4.- Log out de la ficha clínica electrónica Precondición Para el uso óptimo del sistema, éste debe encontrarse en el escritorio para su fácil acceso. Postcondición El sistema podrá ser utilizado por el usuario según sus facultades. Descripción El usuario está a cargo de manejar el sistema con gran responsabilidad sobre los criterios de permisos sobre los usuarios. 30 Especificación de Requisitos, estándar de IEEE 830 5.5 Prototipado de Software 31 Especificación de Requisitos, estándar de IEEE 830 32 Especificación de Requisitos, estándar de IEEE 830 33 Especificación de Requisitos, estándar de IEEE 830 34 Especificación de Requisitos, estándar de IEEE 830 35 Especificación de Requisitos, estándar de IEEE 830 36 Especificación de Requisitos, estándar de IEEE 830 37 Especificación de Requisitos, estándar de IEEE 830 5.6 Resultado Análisis de Calidad Diagramas Modelamiento Insertar Resultado del Análisis de Calidad basado en los estándares y la Planilla de Análisis de Calidad de modelado de Software. 5.7 Resultado Análisis de Calidad Prototipado No funcional del Sistema Insertar Resultado del Análisis de Calidad basado en los estándares y la Planilla de Análisis de Calidad de Prototipo de Interfaz de Usuario. 5.8 Planilla entregables del Proyecto PLANTILLA DE ENTREGAGLES ENTREGABLE DEL ANALISIS DESCRIPCION - Captura de Requisitos Análisis de requisitos y descripción - Especificación del sistema Requisitos de datos, hardware y descripción - Plan de Pruebas Funcionalidad del sistema ENTREGABLES DISEÑO - Interfaces, tanto humanos como de Descripción detallada del sistema máquinas ENTREGABLES DE CODIFICACION - Cadenas de ejecución Resultado de las pruebas de cada unidad y programa - 5.9 Matriz de Control de Cambios Versión Causa del Cambio Responsable del Cambio Fecha del Cambio 0100 Versión inicial <Nombre Apellido1 Apellido2> DD/MM/AAAA 38 Especificación de Requisitos, estándar de IEEE 830 5.10 Matriz EDT. Planilla Detallada Cálculo de Esfuerzo ACTIVIDADES Fase de Planificación DIAS JP ING SOFT DI RPYC Kick Off 1 4 4 2 0 Acta de Constitución de proyecto 4 5 5 1 1 Aprobación del Acta 4 5 5 1 1 Definición de requerimientos Generales del proyecto 1 6 6 6 0 Organización del equipo 1 4 4 4 4 Fase de Análisis y diseño ROL 1 ROL 2 ROL 3 ROL 4 Captura de requerimientos específicos 14 8 8 5 2 Análisis de requerimientos 7 4 8 8 2 Diseño de la solución. Modelamientos 2 2 8 8 2 Propuesta ERS 1 4 6 5 4 Plan de proyecto 2 6 6 6 6 Fase de Desarrollo ROL 1 ROL 2 ROL 3 ROL 4 Implementación ambiente de desarrollo 5 2 2 2 2 Construcción componente 1 3 3 5 4 2 Construcción componente 2 5 6 8 3 3 Construcción componente 3 3 6 6 4 3 Construcción componente 4 3 6 8 3 4 Construcción componente 5 7 6 6 5 5 Integración del sistema 5 6 8 6 3 Fase de implementación y cierre ROL 1 ROL 2 ROL 3 ROL 4 Pruebas unitarias componente 1, 2 1 5 6 3 3 Pruebas unitarias componente 3, 4 1 4 6 5 3 Pruebas unitarias componente 5 1 4 6 3 3 Pruebas de integración 1 8 8 8 8 Migración del sistema a producción 7 3 5 6 8 Pruebas de integración final 3 4 4 4 4 Marcha blanca 7 3 5 6 8 Capacitación 7 3 4 3 6 Cierre de proyecto 2 2 2 2 2 SIGLA JP ROL NOMBRE Jefe de Proyecto YULIANA ARACENA FASE PLANIFICACION $ 23.404 $ 2.785.076 $ 18.790 $ 2.799.710 Diseñador MATIAS ROA $ Responsable PYC JENNIFFER ASTUDILLO $ 16.780 $ 13.456 $ 1.896.140 1.197.584 ING SOFT Ing. de Software JAVIERA RODRIGUEZ DI RPYC VALOR HH 39
