PentaSoft - Plan de Proyecto
64 Pages • 14,132 Words • PDF • 2.5 MB
Uploaded at 2021-09-24 13:07
This document was submitted by our user and they confirm that they have the consent to share it. Assuming that you are writer or own the copyright of this document, report to us by using this DMCA report button.
Universidad Nacional de General Sarmiento Tecnicatura Superior en Informática Licenciatura en Sistemas
23-6-2017
LABORATORIO DE CONSTRUCCION DE SOFTWARE PROYECTO: SI SALUD
Docentes: o o o o
Ing. Lucas Guaycochea. Lic. Javier Godoy Lic. Agustina De Napoli TSI Ivo Arcolini
Integrantes: o o o o o
Córdoba, Luciano D´urbano, Matías Pesado, Gonzalo Pompilio, Maximiliano Tacchini, Lautaro
Compañía: PentaSoft
Índice Descripción del proyecto………….…………………………………………..1 Equipo De Trabajo………………….…………………………………………1 Metodología………………………….………………………………………..2 Arquitectura…………………………………………………………………...2 Alcance………………………………………………………………………..5 Listado De Requerimientos…………………………………………………...8 Casos de Uso…………………………………………………………………15 WBS………………………………………………………………………….25 Diccionario WBS…………………………………………………………….32 Plan de Versiones…………………………………………………………….40 Estimaciones……………………………………………….…………………41 Documento de Riesgos…………………………………………………...…..56 Administración de Cambios...………………………….……………….........59 Administración de Testing..…………..………………………………...........61
Descripción del Proyecto Se solicita la realización de un software a medida para el Hospital Privado "Sí Salud" SRL, el cual lleva a cabo la gestión de sus pacientes, sus turnos, sus internaciones y las diferentes prestaciones que los mismos pueden realizarse en dicho hospital. Se deberá realizar un sistema de software que sustente la operatoria diaria realizada por los trabajadores del hospital. El hospital cuenta con varios sectores. En cada uno de ellos se llevan a cabo diferentes actividades. Por un lado, existe un sector de recepción en donde las personas se anuncian, ya sea por un turno que pidieron previamente o por una urgencia. Existe, también, un sector en donde los técnicos/profesionales atienden a sus pacientes en sus consultorios, aplicando las prácticas correspondientes. Por ejemplo, una consulta médica o una extracción de sangre. Por último, se tiene un área específica para las internaciones, donde los pacientes quedan internados durante un lapso de tiempo determinado. Las personas que asisten al hospital pueden tener una obra social o una prepaga que cubra las prácticas que desean realizarse o pueden ir de manera particular, pagando ellos mismos todos los costos. El sistema debe mantener una historia clínica de los pacientes, de forma que pueda ser consultada por los profesionales en todo momento y permita observar las consultas y diagnósticos previos de las distintas especialidades. Además, debe poder visualizarse claramente las patologías críticas o antecedentes relevantes de un paciente (Por ejemplo: asma, diabetes, operación de vesícula, etc.) A su vez, el hospital cuenta con dos depósitos en donde se guardan los insumos (medicamentos y materiales) que el hospital necesita. Uno de los dos depósitos es controlado por un sistema de refrigeración ya que existen algunos medicamentos que necesitan de una temperatura determinada mientras que otros medicamentos no lo requieren por lo que pueden ser guardados en un depósito común (a temperatura ambiente). Se desea que el sistema permita administrar el control de stock y los contactos con los proveedores y además pueda monitorear el sistema de refrigeración para emitir un alerta en caso de que la temperatura no se encuentre en el rango deseado. Por último, se quiere que el sistema permita realizar las facturaciones ocasionales a los pacientes particulares o por aquellas prácticas no cubiertas por su obra social o prepaga, y las facturaciones mensuales a las obras sociales para cobrarles los montos por las prestaciones otorgadas a sus afiliados. Además, se debe poder hacer la liquidación a cada profesional a partir de la cantidad de pacientes atendidos y las prácticas realizadas.
Equipo de Trabajo El equipo de trabajo se compone de 5 personas, 3 desarrolladores con un líder de desarrollo, un tester que también cumple la función de analista funcional y el jefe de proyecto.
1
●
Roles: ○
Córdoba, Luciano: Desarrollador.
○
D´urbano, Matías: Líder de Desarrollo, Desarrollador.
○
Pesado, Gonzalo: Tester, Analista Funcional.
○
Pompilio, Maximiliano: Desarrollador.
○
Tacchini, Lautaro: Jefe de Proyecto.
El principal objetivo de la distribución de roles de trabajo es lograr una mayor eficiencia en la distribución de las tareas a realizar.
Metodología La metodología que decidimos utilizar para la realización del proyecto es APF ya que consideramos que una metodología iterativo incremental es la que mejor se adapta a nuestra forma de trabajo y a las características del proyecto. Vamos a utilizar las fases de iteración que sugiere APF. Sin embargo, no vamos a utilizar todos los documentos formales que sugieren como por ejemplo el RBS. En el version scope vamos a definir el alcance del sistema utilizando la condición de satisfacción del usuario y se planificará la iteración a realizar. Luego en el cycle plan realizamos toda la parte relacionada con la planificación del proyecto (Requerimientos, Casos de Uso, WBS, etc). En el cycle build llevaremos a cabo las tareas de desarrollo y el client checkpoint estará relacionado con la reunión formal con el cliente donde evaluamos todo el trabajo realizado en la iteración. Por último se revisan los cambios que deben realizarse en el proyecto en cuanto a documentación y a código, y se vuelve a iterar.
Arquitectura El objetivo de este documento es el de mostrar cómo es la interacción entre las clases que componen nuestro sistema. Antes que nada, aclaramos que este diagrama fue realizado partiendo el sistema en 3 capas: Capa de presentación, Capa lógica y la capa de persistencia, dentro de las mismas irán las clases que estén integradas en cada capa según corresponda, las diferencias entre las capas serán las siguientes:
Capa de presentación: En esta capa irán las clases que sirvan como conexión entre el usuario y el sistema, dentro de las mismas veremos las interfaces gráficas junto con sus controladores ya que seguimos una estructura “MVC”.
Capa lógica: En esta capa irán las clases encargadas de realizar las operaciones del sistema o “core” de datos. Las mismas serán clases que realizarán toda la lógica de las operaciones.
2
Capa de persistencia: En esta capa irán las clases encargadas de persistir los datos necesarios. En esta misma usaremos el patrón de diseño DAO para cada uno de los objetos que nos interese persistir. Los DAOS constan de una implementación específica para conectarse al motor de bases de datos MySQL.
En el siguiente diagrama se muestra la interacción entre todos los módulos que componen nuestro sistema, y evidencia la división de las tres capas.
3
4
Usuarios Del Sistema A continuación detallaremos, los usuarios con los que contará nuestro sistema: ○ Administrador del sistema: Personal encargado de la administración de usuarios del sistema. ○ Médicos: Profesionales que trabajan dentro del hospital atendiendo pacientes (trabajan con las historias clínicas y con los pacientes). ○ Personal Administrativo: Personal encargado de la gestión administrativa del hospital (sueldos, personal, cobros). ○ Personal de Depósito: Personal encargado de la gestión de stock, y el monitoreo de los depósitos. ○ Personal de Internación: Personal que realiza las internaciones a los pacientes y realiza un seguimiento de las mismas. ○ Personal de Recepción: Personal encargado de recibir a los pacientes y gestionar los turnos. ○ SuperUsuario: Usuario general que podrá acceder a todas las secciones del sistema (por ejemplo: dueño del hospital).
Alcance Definimos el alcance con la condición de satisfacción de usuario relacionado con los requerimientos del sistema.
Funcionalidad
Responsabilidad del sistema
No contemplado por el sistema
Gestión de usuarios
El único usuario capaz de gestionar otros usuarios será el administrador del sistema, El mismo podrá crear, modificar y eliminar cualquier usuario (Inclusive otros administradores).
El sistema no permitirá crear el administrador del sistema primario, que será el que luego cree a todos los usuarios del sistema, el 1er administrador del sistema será creado por defecto y sus datos de logueo serán entregados al cliente, luego el mismo podrá crear otros administradores o demás usuarios desde la cuenta de administrador. Cuándo se quiere eliminar un usuario en el sistema, el mismo no es eliminado de la base de datos ya que puede haber datos ligados al mismo, el sistema ocultara el usuario para que no se puedan realizar operaciones con él.
5
Login de usuarios
Se poseerá un login que permite a todo El sistema no contemplara loggins de usuario realizar sus tareas en el sistema. pacientes, las operaciones con los mismos serán realizadas mediante el personal de secretaría, de internación y el superusuario.
Gestión de historias clínicas
Los médicos solo pueden asignar nuevas El sistema no permitirá modificar ni entradas a la historia clínica de un eliminar entradas correspondientes a una paciente. historia clínica de un paciente.
El médico deberá tener en pantalla la historia clínica del paciente una vez atendido y ahí podrá agregar la entrada a la historia clínica del paciente. Gestión de turnos
El personal de secretaría y el superusuario podrán gestionar los turnos, tanto la creación, modificación y cancelación de los mismos. El personal de secretaría y el superusuario podrá seleccionar una fecha para asignar un turno y el mismo mostrará los horarios disponibles de cada médico. El personal de secretaría y el superusuario podrán dar de alta pacientes en la lista de espera y se mostrarán en una pantalla donde se vea en tiempo real los pacientes. NOTA: Con “tiempo real” nos referimos a que se deberá actualizar la pantalla del médico cada vez que su secretaria agregue una persona a la lista de espera. Para recordar el turno al paciente, el sistema le enviara un mail el día anterior recordando el turno. Se debe poder agregar un horario restringido para enviar los mails.
Gestión de internaciones
Si llega a pasar que luego de la consulta con el médico, el paciente necesite intervención, la misma será solicitada por el paciente directamente en internaciones, utilizando algún mecanismo de comunicación entre el médico y el personal de internaciones (que puede ser por ejemplo una orden
El sistema llevará un registro de las internaciones que se realicen en el hospital. Nuestro sistema solo se encargará de verificar si las habitaciones se encuentran disponibles o no para ser ocupadas por un paciente. Solo se podrá visualizar en nuestro sistema si las habitaciones están ocupadas o libres, no
6
firmada de internación).
Gestión de Stock
realizará sugerencias de ningún tipo una habitación. Las habitaciones son seleccionadas de acuerdo al criterio del personal de internación.
El sistema permitirá al Personal de El sistema no gestionara si el stock está depósito y al Superusuario gestionar el físicamente en el depósito, esto lo stock. deberá controlar el personal de depósito, se supone que el personal de depósito controlara el pedido y registrará que dicho pedido llegó con éxito. El sistema no enviará ningún tipo de alerta si existe bajo stock.
Gestión de órdenes de compra
El personal de depósito y el superusuario pueden crear órdenes de compra cuando lo crean necesario. Para las mismas se deben detallar los artículos correspondientes al pedido y enviar el pedido vía mail al proveedor, el sistema además deberá permitir buscar e imprimir dichas órdenes para agilizar sus tareas.
El sistema no almacenará los tickets de las órdenes de compra, en cambio, se podrán buscar, seleccionar la que deseamos para volverla a imprimir.
Impresiones
El sistema se encargará de imprimir tickets, liquidaciones de sueldo, listas de pacientes, liquidaciones para obras sociales y solicitudes de compra.
El sistema no almacenará documentos que se imprimieron. Los datos de los mismos podrán ser buscados y podrán volverse a imprimirlo si es necesario.
Gestión de obras sociales
El sistema debería tener un registro de las prácticas autorizadas por las obras sociales, estas mismas deberán estar disponibles para modificar en todo momento y la persona autorizada para esto es el administrador / secretaria. El sistema deberá detectar las prácticas que están cubiertas a la obra social a la hora de un turno enviando un mensaje a la secretaria si alguna de las prácticas no está cubierta por la obra social.
Debido a los posibles cambios en los precios de los artículos, el sistema no calculará el costo de las órdenes de compra, el monto total debe ser asignado luego de la respuesta del proveedor por el personal de depósito.
Con respecto a las prácticas que necesiten autorización de la obra social, el sistema no ayudará al paciente con la gestión de la misma, se supone que es un problema entre el paciente y su prestadora del servicio por ende no nos compete. La validación de la misma la debería hacer el personal de recepción,
7
una vez que el personal de recepción valide la autorización, podrá asignar la autorización presentada a cada paciente según las prácticas que deba hacerse. Sistema de refrigeración
El sistema se encargará de controlar El sistema no se encargará de realizar mediciones de temperatura de la cámara dicha medición, La misma será medida refrigerada, enviando alertas en caso de por un sistema externo. que la temperatura este en un valor no habitual.
Contabilidad
Con respecto al cobro de los médicos, el sistema les calculara el mismo teniendo en cuenta el salario básico del mismo junto con las prácticas que realizaron. Con respecto a las prácticas, el sistema calculará el monto que se lleve el medico por las prácticas realizadas (dependiendo del porcentaje destinado para el médico en cada práctica). El sistema deberá gestionar un listado de cuánto cobran de básico cada médico y además cuánto cobran por una consulta.
Gestión de practicas
Las prácticas deben tener al menos un profesional que las realice, pueden ser varios tipos de profesional por cada práctica. Al momento de crear la práctica se deben elegir los médicos que participen de la misma, estos deben cumplir la cantidad de especialistas necesaria para la práctica.
El sistema no contemplara las ganancias o pérdidas del hospital, con esto queremos decir que no lleva una contabilidad de la misma, consideramos que esto lo deberá realizar el personal administrativo. El sistema proveerá todas las herramientas necesarias para dicha labor tales como: órdenes de compra (costo), liquidaciones de sueldo (costo), cobro de prácticas (ingresos). Consideramos que para llevar una contabilidad seria se deben tener en cuenta diversos factores que inciden en ella y no son vistos por el sistema.
Requerimientos ●
Listado de Requerimientos del sistema
●
Notación: Numeramos los requerimientos Funcionales por un lado, y los Requerimientos no funcionales por otro. Clasificamos cada requerimiento como Esencial (E), Importante (I), Deseable (D).
●
RFE1: Los pacientes deben tener una historia clínica registrada en el sistema. _Detalle: ○
Se deben registrar todas las consultas de los pacientes en la historia clínica.
8
○
En la historia clínica se debe incluir los diagnósticos previos de las distintas especialidades.
○
En la historia clínica se debe poder visualizar fácilmente las patologías críticas o antecedentes relevantes del paciente.
○
En el reporte de la historia clínica se mostrarán primero las patologías críticas o antecedentes relevantes del paciente.
●
RFE2: Los médicos deben poder consultar las historias clínicas de sus pacientes en todo momento. _Detalle: ○
Cuando el medico consulte las historias clínicas se deben resaltar los datos relevantes del paciente.
●
RFE3: Los médicos deben poder ingresar nuevos datos en la historia clínica de sus pacientes. _Detalle: ○
El médico, luego de realizar la consulta, ingresa en la historia clínica los detalles de la nueva consulta y los diagnósticos pertinentes junto con la fecha de consulta.
●
RFE4: El personal de depósitos debe poder visualizar los insumos que se presentan en el hospital. _Detalle:
●
○
Se lleva un registro de los materiales y medicamentos que se disponen en el hospital.
○
El sistema cuenta con dos depósitos (uno común y otro con refrigeración).
RFI5: El personal de depósito deberá poder realizar órdenes de compra. _Detalle:
●
○
Una orden de compra tiene un código, artículo y cantidad de artículos.
○
Una vez creada se enviará por mail al proveedor.
RFI6: El personal de depósito debe poder visualizar el stock del hospital el cual es administrado por el sistema. _Detalle: ○
Con stock nos referimos a los insumos del hospital.
○
Se debe mostrar el stock total del hospital.
○
El sistema debe permitir visualizar de manera individual todos los insumos que se encuentran en stock.
○
Los insumos deben poder filtrarse por sus distintas categorías.
9
●
RFI7: El personal de depósito debe tener la capacidad de registrar el ingreso de stock. _Detalle: ○
El stock se registra con: nombre, código, proveedor, si requiere receta y si necesita estar refrigerado.
●
RFI8: El egreso de stock se debe ser registrado por el personal de depósito cuando se hace uso del stock del hospital. _Detalle ○
Los egresos pueden ser por insumos del hospital y/o por la utilización de los mismos por el mismo personal del hospital.
●
RFI9: El personal de depósito debe tener la capacidad de agregar, quitar o modificar la lista de proveedores. _Detalle: ○
El sistema debe tener un listado de los proveedores del hospital.
○
El listado debe poder ser editado por el personal de depósito.
○
Cuando se desee contactarse con un proveedor se deben mostrar los datos correspondientes al proveedor.
○
El proveedor se registra en el sistema con un CUIT, un nombre, una dirección, un teléfono y un mail para contactarlo.
●
RFD10: El sistema debe monitorear el sistema de refrigeración. _Detalle: ○
Nuestro sistema se debe comunicar con el sistema de refrigeración, el cual controla la temperatura del depósito con refrigeración, para llevar un seguimiento de la temperatura.
●
RFD11: Se deben poder emitir alertas desde el sistema. _Detalle: ○
El sistema emitirá una alerta si el sistema de refrigeración informa que el depósito excedió la temperatura límite.
●
RFE12: El personal de recepción debe poder emitir facturaciones ocasionales. _Detalle: ○
Se emite facturas ocasionales a los pacientes particulares.
10
○
Se emite facturas ocasionales a los pacientes que deben realizar prácticas que no son cubiertas por sus obras sociales o prepagas.
●
RFE13: El personal de administración debe tener la capacidad de emitir facturaciones mensuales. _Detalle: ○
Las facturaciones mensuales se realizar a las obras sociales para cobrar los montos respectivos a las prestaciones otorgadas a sus afiliados.
●
RFE14: Los médicos deben tener su liquidación mensual generada automáticamente por el sistema. _Detalle: ○
La liquidación mensual se realiza a partir de la cantidad de pacientes atendidos y las prácticas realizadas.
●
RFE15: El personal de recepción podrá realizar el proceso de otorgamiento de turnos. _Detalle: ○
El personal de recepción podrá ingresar la fecha sobre la cual se desea otorgar el turno, cuando se selecciona la fecha se pueden visualizar los turnos ya tomados y los turnos libres para esa fecha. Luego el personal de recepción podrá seleccionar una lista de todas las especialidades, al seleccionar la especialidad se abrirá una lista con todos los médicos. Para completar la operación el personal de recepción, seleccionando un horario e indicando el nombre del paciente, otorga el horario y pasa a estar ocupado. Esta operación es registrada en el sistema.
○
Al haber realizado el otorgamiento del turno se imprime un comprobante con los datos: el nombre de paciente junto con su, la fecha y horario del turno, y el médico que corresponde al turno.
○ ●
Se deben poder filtrar los turnos por fecha por hora.
RFD16: El sistema debe tener la capacidad de realizar notificaciones vía mail. _Detalle: ○
El sistema debe enviar un recordatorio vía mail a cada paciente un día antes del turno registrado en el sistema.
○
En caso que se haya cancelado un turno por parte de un médico, se debe enviar un mail al paciente informando la cancelación de su turno y la asignación de su nuevo turno.
11
○
En caso de que se cree una solicitud de compra, la misma debe ser enviada vía mail al email personal del proveedor, se debe detallar en la solicitud la lista de artículos, con sus códigos, junto con las cantidades de cada uno, subtotal y total de toda la orden.
●
RFE17: El personal de recepción debe tener la capacidad de cancelar un turno a través del sistema. _Detalle: ○
El paciente puede solicitar cancelar un turno o cambiarlo de día, y el personal de recepción llevará a cabo esa acción.
●
RFE18: El personal de recepción debe poder cancelar los rangos horarios de un determinado médico. _Detalle: ○
Si el médico cancela su día o algún rango de los horarios el sistema automáticamente debe cancelar los turnos asociados a los horarios cancelados.
○
El sistema asignará automáticamente un nuevo turno al paciente que será informado vía mail. Si el paciente no puede cumplir con ese turno podrá solicitar uno nuevo.
●
RFE19: Se debe generar un listado de pacientes que se encuentren en una lista de espera correspondiente a cada doctor y que se hayan anunciado ante el personal de recepción. _Detalle: ○
El personal de recepción ingresa al sistema los pacientes que ya fueron anunciados y que tienen la autorización correspondiente aprobada.
○
El personal de recepción debe tener la capacidad de imprimir el listado de turnos que tiene un médico particular en la fecha correspondiente.
●
RFD20: Los médicos deben poder visualizar los pacientes que tienen un turno para ese día. _Detalle: ○
El médico podrá visualizar en una pantalla todos los pacientes que deba atender en el día correspondiente.
○
Se visualizan tanto los pacientes que ya se encuentran en la sala de espera y están listos para ser atendidos como los pacientes que no se hayan anunciado aún.
○ ●
Se indica en pantalla si un paciente ya se ha anunciado o no.
RFE21: El personal de recepción debe poder ingresar las autorizaciones de las obras sociales en el sistema. _Detalle
12
○
Junto con la autorización se ingresan los datos del paciente, su diagnóstico, el médico solicitante, la fecha de autorización y las prácticas a realizarse con su correspondiente nombre, código y cantidad de sesiones a realizar.
●
RFI22: Se deberá administrar las sesiones pendientes de cada paciente con sus correspondientes autorizaciones. _Detalle: ○
El sistema tendrá un registro de las sesiones totales autorizadas que tiene cada paciente y a medida que el paciente vaya realizando las sesiones el sistema automáticamente irá descontando las sesiones usadas.
●
○
Si las sesiones no están autorizadas no pueden realizarse.
○
Puede haber sesiones o prácticas que no requieran autorización.
RFE23: El personal de internación debe poder ingresar al sistema los pacientes que deban ser internados en el hospital. _Detalle: ○
Se debe poder visualizar el listado de pacientes esperando internación.
○
Se deben asociar las autorizaciones correspondientes a la internación de cada paciente.
○
El sistema debe informar si una habitación se encuentra disponible o no.
○
Los pacientes de internación se registran como un paciente común que se va a realizar una práctica más con la diferencia que requiere internación.
●
RFI24: El personal de internación deberá poder realizar operaciones de gestión de habitaciones. _Detalle: ○
Cuando se realiza una internación el sistema registra un ingreso y la habitación pasa a estar ocupada.
○
Cuando una internación finaliza el sistema registra un egreso y la habitación pasa a estar libre.
○
El personal de internación también podrá registrar el pasaje de un paciente de una habitación a otra en caso de que sea necesario.
○
El personal de internación debe poder reservar una habitación previendo la fecha de internación tentativa de un paciente. Cuando se reserva una habitación, se registra fecha de ingreso tentativa y fecha de egreso tentativa.
●
RFE25: Se debe llevar un registro de todas las internaciones activas en el hospital.
13
_Detalle: ○
Se deberá asociar al paciente con la práctica a realizar que amerite la internación junto con las autorizaciones correspondientes que le competan.
○
Se asociará una fecha de egreso tentativa.
○
Cada internación tendrá los datos del paciente, el diagnóstico correspondientes, la fecha de ingreso, la habitación en la que está hospedado y una observación.
○
Cuando se realiza una internación el sistema registra una fecha de ingreso y la fecha es adjuntada a los datos del paciente.
○
Cuando el paciente egresa del hospital se registra el egreso en el sistema junto con la fecha real de egreso, el motivo, una descripción y el diagnóstico final.
○
Se debe registrar la fecha de internación y las prestaciones adicionales que se realicen durante la internación.
●
RFI26: El personal de internación podrá imprimir el detalle de la internación de un paciente. _Detalle ○
En el detalle de la internación se incluye el monto a pagar en caso de que sea particular o las prácticas realizadas sobre el paciente que no estén cubiertas por su prepaga u obra social, y los datos de internación del paciente.
●
RFI27: El personal de administración deberá tener la capacidad de actualizar mensualmente, los importes de las prácticas médicas que se les lleva a cabo a los pacientes. _Detalle ○
En una planilla se guardan los códigos, las descripciones, el nombre y el precio de cada práctica que realiza el hospital. El personal administrativo tendrá permiso para actualizar esta planilla.
○
Se debe llevar un registro de las nomenclaturas de las prácticas realizadas por el hospital.
○
En el registro se incluye código, descripción, importe y un estado si están autorizadas o no.
○
Se debe tener un importador de prácticas que importe las nomenclaturas desde un formato conveniente.
●
RFE28: Se deben poder registrar a los pacientes en el sistema. _Detalle: ○
Los pacientes son registrados con nombre, DNI, numero de afiliado (obra social o prepaga), su plan y nombre de prepaga, un contacto y un número de emergencia.
14
●
RFI29: El Súper Usuario debe tener acceso a todos los datos del sistema. _Detalle: ○
El Súper Usuario es creado por el administrador de usuarios y tiene acceso a todas las pantallas del sistema sin restricciones, con sus funcionalidades incluidas.
●
RFI30: Se debe contar con un sistema de Login para identificar a cada usuario. _Detalle: ○
Se deben registrar al personal administrativo, al personal de depósito, al personal de recepción y a los médicos.
○ ●
Contamos con un administrador general que asigna permisos a los usuarios.
RFI31: El administrador del sistema deberá tener la capacidad de crear cuentas para los distintos usuarios del sistema. _Detalle: ○
Inicialmente el sistema otorgará la cantidad de cuentas de administrador que sean necesarias.
○ ●
El administrador crea cuentas de usuario con nombre de usuario y contraseña.
RFD32: Los administradores deben poder realizar en cualquier momento un backup de la base de datos. _Detalle: ○
El backup realizado debe exportarse en un formato adecuado para poder identificarlo y guardarlo.
○
El sistema debe poder incorporar bases de datos generadas a partir del mismo sistema en el formato definido.
Casos De Uso
15
16
17
Cartillas Casos de Uso ● Realizamos cartillas únicamente de los casos de uso más importantes del sistema.
Caso de Uso: CU1 - Otorgando turno Actor: Personal de recepción Descripción: El personal de recepción otorga un turno a un paciente. Requerimientos asociados: RFE15 Precondición: El personal de recepción debe estar autenticado. Postcondición: El turno es otorgado al paciente y se emite un comprobante. Curso normal
Alternativas
1. .El personal de recepción le
pide al sistema asignar turno a paciente 2. El sistema muestra el formulario correspondiente (req 12: Detalle) y el personal de recepción lo completa.
2.1 No hay ningun medico disponible para esa especialidad, el sistema muestra un aviso notificando esto. Ir a Fin Caso de Uso
3. Se selecciona un médico y se muestran los horarios disponibles correspondientes al médico seleccionado.
3.1 El médico seleccionado no posee horarios disponibles. Ir paso 2.
4. El sistema registra el turno e imprime comprobante con los datos del turno. Fin Caso de uso. Detalle: Un turno está compuesto por un código, día y horario, paciente, médico e importe. Se deben poder filtrar los turnos por fecha y horario.
18
Caso de Uso: CU2 - Cancelando Turno Actor: Personal de recepción Descripción: El personal de recepción registra el turno de un paciente. Requerimientos asociados: RFE17 Precondición: El turno tiene que estar registrado y debe ser posterior a la fecha actual. Postcondición: El turno no se encuentra registrado Curso normal 1.El sistema muestra los turnos registrados 2.El personal de recepción selecciona el turno a cancelar 3. El sistema envía un mail al paciente, Usa CU16 4. El sistema borra el registro de turno Fin Caso de uso.
Caso de Uso: CU7 - Colocando paciente en lista de espera Actor: Personal de recepción Descripción: Se ingresan los pacientes a la lista de espera Requerimientos asociados: RFE19 Precondición: El turno del paciente tuvo que ser abonado previamente o tiene que estar cubierto por la prepaga/obra social. Deben estar presentadas las correspondientes autorizaciones para la práctica o consulta Postcondición: El turno es otorgado y el paciente pasa a estar en la lista de espera.
19
Curso normal
Alternativas
1. Se selecciona el turno al que el paciente se vino a anunciar 2. Si todo está correcto el paciente está ahora en la lista de espera
2.1 Si el paciente o no tiene las autorizaciones correspondientes, o no tiene pago el turno, entonces se notifica al usuario(recepcionista) y no se puede proceder . Ir Fin Caso de Uso
Fin Caso de uso. Detalle: Una vez en la lista de espera, el paciente aparecerá en la lista del doctor de pacientes en espera.
Caso de Uso: CU5 - Consultando pacientes. Actor: Personal de recepción. Descripción: El personal de recepción consulta los pacientes anunciados encuentran en lista de espera.
que se
Requerimientos asociados: RFE19 Precondición: El personal de recepción debe estar autenticado Postcondición: Curso normal
Alternativas
1. El personal de recepción solicita consultar los pacientes anunciados en lista de espera
1.1 Sino se ha anunciado ningún paciente hasta el momento se muestra un error en pantantalla. Ir a fin caso de uso.
2. El sistema muestra aquellos pacientes que la recepcionista haya indicado como anunciado. 3. La recepcionista imprimir lista.
pide
20
Fin Caso de uso.
Caso de Uso: CU25 - Consultando historia clínica Actor: Médico Descripción: El médico visualiza la historia clínica de un paciente en particular. Requerimientos asociados: RFE1 - RFE2 Precondición: El Médico debe estar autenticado en el sistema. Postcondición: Información de la historia clínica Curso normal
Alternativas
1.El médico le pide al sistema consultar historia clínica 2. El médico selecciona paciente 3. El sistema muestra un reporte con la historia clínica del paciente.
3.1 el sistema le indica al médico No tiene historia clínica.
Fin Caso de uso.
Caso de Uso: CU12 - Comunicando con servicio externo de mails. Actor: Servidor Externo de emails Descripción: El sistema envía una petición al servicio de mail para enviar el mensaje que corresponda. Requerimientos asociados: RFD16 Precondición: Se realiza una acción que implique enviar un mail. Postcondición: El mail es enviado.
21
Curso normal
Alternativas
1. Nuestro sistema solicita enviar un mail. 2. El sistema envía el pedido al servidor
2.1 Si el servidor no se encuentra disponible el sistema guarda el pedido de envió y volverá a solicitar cada 10 minutos.
3. El servidor confirma la recepción del pedido de envío al sistema.
Fin Caso de uso.
Caso de Uso: CU22 - Emitiendo facturación mensual Actor: Personal administrativo Descripción: El personal administrativo realiza las facturaciones mensuales a las obras sociales y/o prepagas que deban cubrir los gastos en sus pacientes que realizaron prácticas en el hospital. Requerimientos asociados: RFE13 Precondición: El personal administrativo debe estar autenticado Postcondición: Se emite la facturación mensual. Curso normal 1. El personal administrativo solicita la realización de la facturación mensual. 2. El sistema calcula el total que va a facturar a cada obra social o prepaga y lo almacena. 3. Se genera un reporte que permite observar las facturaciones de todas las obras sociales, mostrando el total. Fin Caso de uso. Detalle: Para calcular cuánto se le va a cobrar a cada obra social, se suman todos los importes de todas las prácticas realizadas a pacientes afiliados.
22
Caso de Uso: CU24 - Realizando liquidación del personal. Actor: Personal administrativo. Descripción: El personal administrativo realiza la liquidación de sueldo de todos los médicos del hospital. Requerimientos asociados: RFE14 Precondición: El personal administrativo debe estar autenticado Postcondición: Se realiza la liquidación de sueldo. Curso normal 1. El personal administrativo solicita realizar la liquidación de sueldo. 2. El sistema calcula el total del sueldo de cada profesional. 3. Se genera un reporte para que permite observar las liquidaciones de todos los profesionales y que permita ver el total. Fin Caso de uso. Detalle: Para calcular la paga de cada profesional se tiene en cuenta el sueldo de ese profesional, y se le suma por cada práctica un porcentaje definido por el sistema.
Caso de Uso: CU13 - Realizando orden de compra Actor: Personal de depósito. Descripción: El personal de depósito realiza una orden de compra a un proveedor para conseguir insumos. Requerimientos asociados: RFI5 Precondición: El personal de depósito debe estar autenticado Postcondición: Se emite una orden de compra al proveedor. Usa CU12. Curso normal
Alternativas
23
1. Se selecciona un proveedor. 2. Se ingresa un ítem a esta orden de compra, que consiste de producto y cantidad y precio x cantidad. 3. Se confirma la orden de compra, el sistema la almacena, imprime la orden y también la envía por email al proveedor.
3.1 Se desea cancelar la orden de compra. Ir a Fin Caso de Uso
4. Se envía un mail al proveedor para solicitar el producto. Usa CU12. Fin Caso de uso.
Caso de Uso: CU15 - Registrando ingreso de stock Actor: Personal de depósito Descripción: El personal de depósito ingresa el entrante de una orden de compra Requerimientos asociados: RFI6 Precondición: El personal de depósito debe estar autenticado. Postcondición: El stock correspondiente es registrado en el sistema. Curso normal 1. El personal de depósito selecciona una orden de compra y la confirma 2. El sistema actualiza el stock del insumo ingresante Fin Caso de uso. Detalle: En caso de que los insumos lleguen incompletos se toman los insumos que llegaron y se realiza un nuevo pedido con los insumos faltantes.
24
WBS
25
26
27
28
29
30
31
Diccionario de la WBS CODIGO DE PAQUETE DE TRABAJO
NOMBRE DE PAQUETE DE TRABAJO
DESCRIPCION DE TAREAS
RESPONSABLES
ESTIMACION (HORAS)
556
1.0
Si Salud
Desarrollo completo del sistema Si Salud
Lautaro Tacchini Gonzalo Pesado Matías D´urbano Luciano Cordoba Maximiliano Pompilio
1.1
Planificación
Tareas que involucran la planificación de tareas previas al desarrollo del sistema.
Lautaro Tacchini
48
1.1.1
Alcance
Se elabora el alcance total del proyecto.
Lautaro Tacchini
6
1.1.2
Requerimientos
Se detallan los requerimientos con los cuales debe cumplir nuestro sistema.
Lautaro Tacchini
6
1.1.3
WBS
Se realiza el diagrama WBS para organizar las tareas a realizar dentro del proyecto.
Lautaro Tacchini
6
1.1.4
Diccionario WBS
Se detallan cada una de las tareas de la WBS en un documento.
Lautaro Tacchini
6
1.1.5
Asignación de Roles
Se asignan los roles estrategícos a cada uno de los recursos.
Lautaro Tacchini
3
1.1.6
Casos de Uso
Se elabora el diagrama de casos de uso de nuestro sistema.
Lautaro Tacchini
7
1.1.7
Riesgos
Se realiza un plan de riesgos que decide cuales son los riegos que se asumen y de que manera.
Gonzalo Pesado Lautaro Tacchini
4
1.1.8
Funcionalidades
Analisis sobre las funcionalidades que debe cumplir nuestro sistema y cual es el alcance.
Gonzalo Pesado
6
1.1.9
Control de Cambios
Se previenen los cambios que puede llegar a sufrir el sistema.
Gonzalo Pesado
4
1.2
Gestión de Entregas
Reniónes formales con el cliente.
Lautaro Tacchini
27
1.2.1
Control de Avances
Analisis de avance del proyecto.
Lautaro Tacchini
6
1.2.1.1
Informe de avances
Redacción del informe de avances.
Lautaro Tacchini
3
1.2.1.2
Minuta
Redacción de la minuta en donde se especifica lo hablado en la reunión formal.
Lautaro Tacchini
3
1.2.1.3
Actualización de Documentación
Se actualiza la documentación de acuerdo a los establecido en la reunión formal.
Lautaro Tacchini
5
32
1.2.2
Demo
Elaboración de una demo del producto para la reunión formal.
Matias D´urbano
8
1.2.3
Reunión con Gestión de Proyectos
Reunión formal con la gente de gestión de proyectos.
Lautaro Tacchini
2
1.3
Control de Calidad
Tareas relacionadas con el control de calidad del producto.
Gonzalo Pesado
16
1.3.1
Testing
Realización de las pruebas establecidas para verificar que el sistema cumpla adecuadamente con las funcionalidades pautadas.
Gonzalo Pesado
16
1.3.1.1
Evolución de Pruebas
Elaboración del documento que evalua la cant. de bugs corregidos y la cant. de bugs encontrados.
Gonzalo Pesado
4
1.3.1.2
Casos de Pruebas
Se realiza el documento de casos de prueba para testear.
Gonzalo Pesado
6
1.3.1.3
Actualización de Documentación
Se relizan modificaciónes a los documentos del proyecto según corresponda añadiendo los detalles que sean especificados por el equipo o por el cliente.
Gonzalo Pesado
6
1.4
GUI Doctor
Todas las interfaces gráficas relacionadas con los doctores del hospital.
Matias D´urbano
22
1.4.1
UI Doctor
Pantalla del médico
Matias D´urbano
22
1.4.1.1
Administración historia clínica
Pantalla que muestra las historia clinica y da la opción de agregar nuevos datos.
Matias D´urbano
6
1.4.1.2
Visualización Historia clínica
Pantalla que muestra unicamente la historia Clínica.
Matias D´urbano
6
1.4.1.3
Administración horario Laboral
Pantalla para administrar el horario Laboral del medico y que permita cancelar horarios.
Matias D´urbano
6
1.4.1.4
Form Logueo
Formulario para que el médico se loguee al sistema. Con su matricula y su contraseña correspondiente.
Matias D´urbano
4
1.4.2
GUIS Personal
Pantallas del personal del hospital.
Luciano Cordoba
55
1.4.2.1
UI Personal de Recepción
Pantalla del personal de recepción.
Luciano Cordoba
18
1.4.2.1.1
Gestión de Turnos
Pantalla para ingresar, cancelar y cambiar turnos.
Luciano Cordoba
6
1.4.2.1.2
Gestión de Obras Sociales
Pantalla para ingresar, modificar y eliminar obras sociales.
Luciano Cordoba
1.4.2.1.3
Administración de Sesiones
Pantalla para administrar las sesiones correspondientes que debe realizarse cada paciente de acuerdo a las prácticas del hospital.
Luciano Cordoba
6 6
1.4.2.2
UI Personal de Internación
Pantallas para el personal de Internación
Luciano Cordoba
8
1.4.2.2.1
Administración de Pacientes
Pantalla para regístrar ingresos y egresos de pacientes.
Luciano Cordoba
4
1.4.2.2.2
Control de habitaciones
Pantalla para gestionar los cambios en las habitaciones del hospital.
Luciano Cordoba
1.4.2.3
UI Personal de Deposito
Pantallas para el personal de Depositos.
Maximiliano Pompilio
4 16
33
1.4.2.3.1
Control de Stock
Pantallas para registrar ingreso, egreso de stock.
Maximiliano Pompilio
4
1.4.2.3.2
Administración de Proveedores
Pantallas para registrar alta, modificar y borrar proveedores.
Maximiliano Pompilio
1.4.2.3.3
Compra de Articulo
Pantalla para registrar la compra de articulos.
Maximiliano Pompilio
1.4.2.4
Form Logueo
Formulario para que el personal del hospital se loguee al sistema. Con un nombre de Usuario del personal y una contraseña.
Matias D´urbano
Pantallas para realizar las tareas del personal administrativo.
Matias D´urbano
10
4 8
3
1.4.2.5
UI personal Administrativo
1.4.2.5.1
Gestión de nomenclaturas
Pantalla para poder editar la tabla de nomenclaturas.
Matias D´urbano
4
1.4.2.5.2
Control de contabilidad
Pantalla para administrar la contabilidad. (Liquidación, impersión de facturas).
Matias D´urbano
6
1.5
Modulo Super Usuario
Modulo encargado de la creación de un super usuario capaz de visualizar todas las pantallas.
Luciano Cordoba
1.5.1
Permisos de Visualización
Lógica relacionada a los permisos de visualización a los que tendrá acceso el superusuario.
Luciano Cordoba
1.5.1.1
Modulo Doctores
Conexión de pantalla del superusuario con la pantalla de Doctores.
Luciano Cordoba
1.5.1.2
Modulo Personal de Recepción
Conexión de pantalla del superusuario con la pantalla del personal de Recepción.
Luciano Cordoba
1.5.1.3
Modulo Personal de Administración
Conexión de pantalla del superusuario con el personal de Administración.
Luciano Cordoba
1.5.1.4
Modulo Personal de Internación
Conexión de pantalla del superusuario con la pantalla de internación.
Luciano Cordoba
1.5.1.5
Modulo Personal de Deposito
Conexión de pantalla del superusuario con la pantalla del personal de Deposito.
Luciano Cordoba
1.5.1.6
Modulo Personal Administrativo
Conexión de pantalla del superusuario con la pantalla del personal administrativo.
Luciano Cordoba
1.5.2
Gestion de Personal
Logica que implica Darle permisos de edición de personal al superusuario.
Luciano Cordoba
1.5.2.1
Agregar
Otorgamiento de permisos para agregar personal.
Luciano Cordoba
4
1.5.2.2
Borrar
Otorgamiento de permisos para borrar personal.
Luciano Cordoba
4
1.5.2.3
Modificar
Otorgamiento de permisos para modificar personal.
Luciano Cordoba
4
1.6
Modulo Personal de Recepción
Tareas que involucran el desarrollo de las funcionalidades que debe desempeñar el personal de Recepción.
Luciano Cordoba
Desarrollo de la parte lógica necesaria para gestionar turnos.
Luciano Cordoba
1.6.1
Gestión de Turnos
30 18 3 3 3 3 3 3 12
22 14
34
1.6.1.1
Asignar Turno
Desarrollo de lógica para poder asginar un nuevo turno.
Luciano Cordoba
8
1.6.1.2
Cancelar Turno
Desarrollo de lógica para poder cancelar un turno.
Luciano Cordoba
6
1.6.2
Gestión de Obras Sociales
Desarrollo de la parte lógica necesaria para gestionar las obras sociales en el sistema.
Luciano Cordoba
1.6.2.1
Agregar Obra social
Desarrollo de la Lógica necesaria para agregar una nueva Obra Social.
Luciano Cordoba
1.6.2.2
Borrar Obra Social
Desarrollo de la Lógica necesaria para eliminar una obra social.
Luciano Cordoba
1.7
Modulo Doctor
Lógica encargada de todas las funcionalidades que nuestro sistema le debe brindar al médico.
Matías D´urbano
42
1.7.1
Visualizacion
Módulo que incluye los elementos que debe poder visualizar un Médico en nuestro sistema.
Matías D´urbano
12
1.7.1.1
Historia clinica
Desrrollo de la lógica de visualización de historias clínicas
Matías D´urbano
6
1.7.1.2
Pacientes
Visualización de el listado de pacientes
Matías D´urbano
6
1.7.2
Administracion historias clinicas
Funcionalidad orientada a la gestión de las historias clínicas dentro del sistema.
Matías D´urbano
14
1.7.2.1
Ingresar historia clinica
Lógica relacionada con el ingreso de nuevos datos a una historia clínica.
Matías D´urbano
8
1.7.2.2
Form historia clinica
Creación de una nueva historia clínica.
Matías D´urbano
6
1.7.3
Gestion horario laboral
Funcionalidad encargada del manejo de los horarios del médico.
Matías D´urbano
16
1.7.3.1
Cancelar Horarios
Lógica de cancelación de horarios.
Matías D´urbano
10
1.7.3.2
Agregar horario
Lógica de agregar un nuevo horario.
Matías D´urbano
6
1.8
Modulo personal de internacion
Logica del personal encargado de internaciones y control de habitaciones.
Luciano Cordoba
26
1.8.1
Administracion de paciente
Control de ingreso y egreso de pacientes.
Luciano Cordoba
20
1.8.1.1
Agregar paciente
Ingreso de paciente a internacion.
Luciano Cordoba
6
1.8.1.2
Form ingreso de paciente
Formulario para ingreso de pacientes.
Luciano Cordoba
4
1.8.1.3
Egreso de paciente
Egreso de pacientes de internacion.
Luciano Cordoba
6
1.8.1.4
Imprimir
Imprime registro de paciente
Luciano Cordoba
4
1.8.2
Visualizacion
Lógica que implica los datos a visualizar por el personal de internación.
Luciano Cordoba
6
1.8.2.1
Visualizacion pacientes en espera
Visualizacion de pacientes que esperan ser internados.
Luciano Cordoba
6
1.9
Modulo personal de deposito
Logica del personal de deposito.
Maximiliano Pompilio
34
1.9.1
Ingreso articulo
Ingreso de articulos al sistema.
Maximiliano Pompilio
6
8 4 4
35
1.9.2
Egreso de articulo
Egreso de articulos del sistema.
Maximiliano Pompilio
8
1.9.3
Compra de articulo
Comprar articulos necesarios a proveedores.
Maximiliano Pompilio
8
1.9.3.1
Form compra
Formulario de compra.
Maximiliano Pompilio
4
1.9.4
Administracion de proveedor
Control de ingreso de proveedores a los que comprar articulos
Maximiliano Pompilio
12
1.9.4.1
Agregar proveedor
Registrar proveedor al cual comprar articulo
Maximiliano Pompilio
6
1.9.4.2
Formulario proveedor
Formulario de regristro de proveedores
Maximiliano Pompilio
6
1.10
Modulo personal adminitrativo
Logica que se encarga de facturaciones y liquiaciones y de agregar nomenclaturas
Maximiliano Pompilio
54
1.10.1
Administrar nomenclaturas
Administracion tecnicas utilizada para tratamiento de enfermedades.
Maximiliano Pompilio
10
1.10.1.1
Agregar nomenclatura
Agregar al sistema tecnica/nomenclatura.
Maximiliano Pompilio
6
1.10.1.2
Form agregar
Formulario para agregar nomenclatura.
Maximiliano Pompilio
4
1.10.2
Modulo contabilidad
Logica que se encarga de facturaciones y liquiaciones.
Maximiliano Pompilio
26
1.10.2.1
Facturacion Facturaciones mensuales y ocacionales.
Maximiliano Pompilio
16
Maximiliano Pompilio
8
Maximiliano Pompilio
8
Maximiliano Pompilio
10
1.10.2.1.1
Facturacion ocacional
Facturacion realizada a pacientes particulares que su obra social no lo cubre.
1.10.2.1.2
Facturacion mensual
Facturacion realizada a obras sociales para cobrar los montos respectivos a las prestaciones otorgadas a sus afiliados.
1.10.2.2 1.10.2.3
Liquidacion
Liquidacion realizada mensualmente a partir de la cantidad de pacientes atendidos y las prácticas realizadas.
Importes de practicas
Costo de practicas.
Maximiliano Pompilio
8
1.11
Control de stock
Control que permite tener certeza de la disponibilidad de articulos en el sistema
Maximiliano Pompilio
16
1.11.1
Control insumos
Insumos que presenta el hospital
Maximiliano Pompilio
16
1.11.1.1
Ingreso
Ingreso que se hace al verificar que los insumos llegaron al deposito
Maximiliano Pompilio
8
1.11.1.2
Egreso
Egreso de insumos utilizados en distintas situaciones del hospital
Maximiliano Pompilio
8
1.12
Control de pacientes
Control de los pacientes que se encuentra en el hospital
Matías D´urbano
43
36
1.12.1
Asignacion de turnos
Asignar turno a paciente con un doctor
Matías D´urbano
8
1.12.2
Visualizacion
Visualizaciones
Matías D´urbano
14
1.12.2.1
Doctores
Visualizacion de doctores trabajando en el hospital
Matías D´urbano
6
1.12.2.2
Horarios
Visualizacion de horarios de trabajo donde los doctores no atienden a algun paciente
Matías D´urbano
8
1.12.3
Listado de pacientes
Listado de pacientes correspondiente a un doctor en particular
Matías D´urbano
6
1.12.3.1
Imprimir
Posibilidad de imprimir listado de pacientes o turnos.
Matías D´urbano
6
1.12.4
Administracion de sesiones
Control de un calendario de sesiones de pacientes
Matías D´urbano
15
1.12.4.1
Agregar sesiones pendientes
Agregar cantidad de sesiones a realizar a un paciente
Matías D´urbano
7
1.12.4.2
Confirmar ingreso a sesion pendiente
Confirmarcion de ingreso a sesion a un paciente
Matías D´urbano
5
1.12.4.3
Form
Formulario para agregar sesion a un paciente
Matías D´urbano
3
1.13
Gestionador de personal
Agregar borrar o modificar personal que trabajaran con el sistema.
Luciano Cordoba
1.13.1
Agregar
Agregar persona que usara el sistema
Luciano Cordoba
4
1.13.2
Borrar
borrar persona que usara el sistema
Luciano Cordoba
4
1.13.3
Modificar
Modificar el personal que usara el sistema
Luciano Cordoba
4
1.13.4
Formulario Agregar
Formulario para agregar personal
Luciano Cordoba
4
1.14
Control de habitaciones
Control que permite tener certeza de la disponibilidad de camas en el hospital
Luciano Cordoba
28
1.14.1
Gestionador de habitaciones
Agregar borrar o modificar las habitaciones que conforman el hospital
Luciano Cordoba
18
1.14.1.1
Agregar
Agregar habitacion que se usara en el hospital
Luciano Cordoba
4
1.14.1.2
Borrar
Borrar habitacion que se usara en el hospital
Luciano Cordoba
4
1.14.1.3
Modificar
Modificar habitacion que se usara en el hospital
Luciano Cordoba
6
1.14.1.4
Formulario
Formulario para agregar las habitaciones
Luciano Cordoba
4
1.14.2
Asignacion
Desarrollo de la logica para poder asignar camas a los pacientes dentro del sistema
Maximiliano Pompilio
10
1.14.2.1
Paciente
Asignar a un paciente del sistema una cama disponible
Maximiliano Pompilio
6
1.14.2.2
Disponibilidad
Comprobar la disponibilidad de las camas para asignarcelas a un paciente
Maximiliano Pompilio
4
1.15
Control de avisos
Control de los avisos internos y externos del sistema
Maximiliano Pompilio
16
1.15.1
Emitir aviso
Generacion de pantallas de cuadro de texto dentro del sistema
Maximiliano Pompilio
8
16
37
1.15.2
Envio de mail
Aviso relacionado a la cancelacion de un turno
Maximiliano Pompilio
8
1.16
Control de monitoreo
Control de monitoreo del sistema de Refrigeración
Matías D´urbano
10
1.16.1
Monitoreo de camara de refrigeracion
Conexión con el sistema de monitoreo de la camara de regrigeración.
Matias D´urbano
10
1.17
Base de datos
Base de datos del sistema
Matias D´urbano
56
1.17.1
Tablas
Tablas del sistema
Matias D´urbano
40
1.17.1.1
Tabla personal de recepcion
Tabla que contiene al personal de recepcion del sistema
Matias D´urbano
4
1.17.1.2
Tabla personal de internacion
Tabla que contiene al personal de internacion del sistema
Matias D´urbano
4
1.17.1.3
Tabla doctores
Tabla que contiene a los doctores del sistema
Matias D´urbano
4
1.17.1.4
Tabla paciente
Tabla que contiene a los pacientes del sistema
Maximiliano Pompilio
4
1.17.1.5
Tabla turnos
Tabla que contiene los turnos del sistema
Maximiliano Pompilio
4
1.17.1.6
Tabla proveedores
Tabla que contiene a los proveedores del sistema
Maximiliano Pompilio
4
1.17.1.7
Personal de deposito
Tabla que contiene al personal de depositos del sistema
Luciano Cordoba
4
1.17.1.8
Habitaciones
Tabla que contiene las habitaciones dentro del sistema
Luciano Cordoba
4
1.17.1.9
Sesiones
Tabla que contiene a las seciones del sistema
Luciano Cordoba
4
1.17.1.10
Personal de administracion
Tabla que contiene al personal de administracion
Luciano Cordoba
4
1.17.2
Back-Up
Copia de seguridad de la base de datos del sistema
Maximiliano Pompilio
16
1.17.2.1
Exportar
Almacenamiento de la base de datos del sistema en un archivo .sql
Maximiliano Pompilio
8
1.17.2.2
Importar
Creacion de la base de datos del sistema mediante un archivo .sql
Maximiliano Pompilio
8
1.18
Administracion y control del proyecto
El equipo de trabajo se reune a debatir como se esta llevando acabo el proyecto y que correcciones realizar
Lautaro Tacchini
18
1.18.1
Reunion de avances
El equipo de trabajo se reune para realizar una revision del avance del proyecto.
Lautaro Tacchini
3
1.18.2
Informe de avances
Se redacta un informe de avances de acuerdo a lo charlado en la reunión formal.
Lautaro Tacchini
3
1.18.3
Preparacion de reuniones
Planificación de las reuniones entre los integrandes del equipo de trabajo.
Lautaro Tacchini
4
1.18.4
Control de cambios
Elaboración del documento de control de cambios.
Lautaro Tacchini
8
1.19
Capacitacion
Tiempo consumido en el aprendizage de nuevas hermanientas o con poco conocimiento
Lautaro Tacchini
7
1.19.1
Maven
Herramienta utilizada en la gestion y construccion de software
Lautaro Tacchini
3
38
1.19.2
Sistema de monitoreo de camara de refrisgeracion
Sistema dedicado constantemete a controlar el estado de la camara de refrisgeracion
Lautaro Tacchini
4
1.20
Dieseño general del sistema
Se lleva acabo los diagramas correspondientes del sistema
Lautaro Tacchini Matías D´urbano
8
1.21
Manual
Documento en el cual se explica como utilizar correctamente el sistema
Matías D´urbano
7
1.22
Estabilizacion
Etapa dedicada a la correccion de bugs del sistema
Gonzalo Pesado
10
1.22.1
Liberacion
Etapa en la cual se presentara el proyecto completo al cliente
Gonzalo Pesado
10
39
Plan de Versiones
Plan de Versiones
RF2
RF3
RF4
RF5
Requerimientos
Sección Gestión Turnos
RFE15 - RFE17 - RFE18 RFE21 - RFI22
Sección Historias Clínicas
RFE1 - RFE2
Sección Médico
RFE3 - RFE19 - RFD20
Sección Pacientes
RFE28
Sección Stock
RFI7 - RFI8
Sección Prácticas
RFI27
Sección Personal Internaciónes
RFE23 - RFI24 - RFE25 RFI26
Sección Personal de Depositos
RFE4 - RFI5 - RFI6
Sección Proveedores
RFI9
Sección Orden de Compra
RFI5
Liquidaciones de Sueldo
RFE14
Sección Sistema de Refrigeración
RFD10
Log in
RFI29 - RFI30 - RFI31
Sección Listado de Pacientes
RFE19
Backup
RFD32
E-Mail
RFD16
Sección Alertas
RFD8 - RFD11
Reportes
RFE12 - RFE13 - RFI26 Sección Cambios
40
Trazabilidad Id Req. Tipo Req.
1
2
3
4
RFE
RFE
RFE
RFE
Esfuerzo Esfuerzo WBS Req.
Requerimientos
Id WBS
Nombre padre - hijo WBS
Los pacientes deben tener una historia clínica registrada en el sistema.
1.7.2
Modulo Doctor - Administración de Historias Clínicas
6
1.7.1.2
Modulo Doctor - Pacientes
3
1.4.1.1
UI Doctor - Administración de historias clínicas
6
1.4.1.2
UI Doctor - Visualización de historias clínicas y pacientes
6
1.7.1.1
Visualización - Historia Clínica
6
1.17.1.3
Tablas - Tabla Doctores
4
1.4.2.4
GUIS Personal - Form Logueo
3
1.7.2.1
Adminitración de Historias Clínicas Ingresar historia clínica
8
1.17.1.3
Tablas - Tabla Doctores
4
1.7.2.2
Adminitración de Historias Clínicas Form Historia Clínica
6
1.4.2.3.1
UI Personal Deposito - Control de Stock
4
1.17.1.7
Tablas - Personal de Deposito
4
1.11.1
Control de Stock - Control Insumos
16
1.4.2.3.3
UI personal Deposito - Compra de Articulo
8
1.9.3
Modulo Personal de Deposito Compra de Articulo
8
1.17.1.7
Tablas - Personal de Deposito
4
1.17.1.7
Tablas - Personal de Deposito
4
1.4.2.3.1
UI Personal Deposito - Control de Stock
4
Los médicos deben poder consultar las historias clínicas de sus pacientes en todo momento.
Los médicos deben poder ingresar nuevos datos en la historia clínica de sus pacientes.
El personal de depositós debe poder visualizar los insumos que se presentan en el hospital.
RFI
El personal de depósito deberá poder realizar ordenes de compra.
6
RFI
El personal de depósito debe poder visualizar el stock del hospital el cual es administrado por el sistema.
7
RFI
El personal de depósito debe tener la capacidad de registrar el ingreso de stock.
1.4.2.3.1
UI Personal Deposito - Control de Stock
4
1.11.1.1
Control de Insumos - Ingreso
8
El egreso de stock se debe registrar automáticamente cuando se realiza una internación en la cual se utilizan medicamentos.
1.4.2.3.1
UI Personal Deposito - Control de Stock
4
1.11.1.2
Control de Insumos - Egreso
8
1.4.2.3.2
UI Personal Deposito Administración de Proveedor
4
1.9.4
Modulo Personal de Deposito Administración de Proveedor
12
1.17.1.6
Tablas - Tabla Proveedores
4
1.17.1.7
Tablas - Personal de Deposito
4
5
8
9
RFI
RFI
El personal de depósito debe tener la capacidad de agregar, quitar o modificar la lista de proveedores.
9
25
18
24
20
8
12
12
24
41
10
RFD
El sistema debe monitorear el sistema de refrigeración.
1.16.1
11
RFD
Se deben poder emitir alertas desde el sistema.
12
13
14
15
16
17
18
19
20
21
RFE
RFE
RFE
El personal de recepción debe poder emitir facturaciones ocasionales.
El personal de administración debe tener la capacidad de emitir facturaciones mensuales.
Los médicos deben tener su liquidación mensual generada automáticamente por el sistema.
RFE
El personal de recepción podrá realizar el proceso de otorgamiento de turnos.
RFD
El sistema debe tener la capacidad de realizar notificaciones vía mail.
RFE
El personal de recepción debe tener la capacidad de cancelar un turno a través del sistema.
RFE
RFE
RFD
RFE
El personal de recepción debe poder cancelar los rangos horarios de un determinado médico.
Se debe generar un listado de pacientes que se encuentren en una lista de espera correspondiente a cada doctor y que se hayan anunciado ante el personal de recepción.
Los médicos deben poder visualizar los pacientes que tienen un turno para ese día.
El personal de recepción debe poder ingresar las autorizaciones de las obras sociales en el sistema.
Control de monitoreo - Monitoreo de camaras de refrigeracion
10
10
1.15.1
Control de Avisos - Emitir Aviso
8
8
1.4.2.1.1
UI Personal de Recepción - Gestión de Turnos
6
1.4.2.4
GUIS Personal - Form Logueo
3
1.6.1.1
Gestión de Turnos - Asignar turno
8
1.10.2.1.1
Facturación - Facturación ocacional
8
1.4.2.5.2
UI Personal Administrativo - Gestión de Contabilidad
6
1.10.2.1.2
Facturación - Facturación Mensual
8
1.4.2.5.2
UI Personal Administrativo - Control de Contabilidad
6
1.10.2.2
Control de Contabilidad Liquidación
10
1.4.2.1.1
UI Personal de Recepción - Gestión de Turnos
6
1.6.1.1
Gestión de Turnos - Asignar turno
8
1.17.1.5
Tablas - Tabla Turnos
4
1.15.2
Control de Avisos - Envio de mail
8
1.4.2.1.1
UI Personal de Recepción - Gestión de Turnos
6
1.6.1.2
Gestión de Turnos - Cancelar Turno
6
1.17.1.5
Tablas - Tabla Turnos
4
1.4.2.1.1
UI Personal de Recepción - Gestión de Turnos
6
1.6.1.2
Gestión de Turnos - Cancelar Turno
6
1.17.1.5
Tablas - Tabla Turnos
4
1.4.1.2
UI Doctor- Visualización de historia clínica y Pacientes
6
1.7.1.2
Visualización - Pacientes
6
1.4.1.2
UI Doctor - Visualización de historias clínicas y pacientes.
6
1.4.2.1.1
UI Personal de Recepción - Gestión de Turnos
6
1.6.1.1
Gestión de Turnos - Asignar turno
8
1.7.1.2
Visualización - Pacientes
6
1.12.3
Control de Pacientes - Listado de Pacientes
6
1.4.2.1.2
UI Personal de Recepción - Gestión de obras sociales
6
25
14
16
18
4
16
16
12
32
14
42
21
22
23
24
RFE
RFI
RFE
RFI
El personal de recepción debe poder ingresar las autorizaciones de las obras sociales en el sistema. Se deberá administrar las sesiones pendientes de cada paciente con sus correspondientes autorizaciones.
El personal de internación debe poder ingresar al sistema los pacientes que deban ser internados en el hospital.
El personal de internación deberá poder realizar operaciones de gestión de habitaciones.
14
1.6.2
Módulo Personal de Recepción Gestión de obras sociales
8
1.12.4
Control de pacientes Administrador de sesiones
15
1.4.2.2.1
UI personal de Internación Administración de pacientes
4
1.8.1.1
Administración de Pacientes Agregar Paciente
6
1.8.1.2
Form Ingreso de Paciente
4
1.17.1.4
Tablas - Tabla Paciente
4
1.4.2.2.2
Ui personal de Internación - Control de Habitaciones
4
1.14.1
Control de habitaciones Gestionador de habitaciones
16
1.14.2
Control de habitaciones Asignacion
8
15
18
28
25
RFE
Se debe llevar un registro de todas las internaciones activas en el hospital.
1.17.1.4
Tablas - Tabla Paciente
4
2
26
RFI
El personal de internación podrá imprimir el detalle de la internación de un paciente.
1.8.1.4
Modulo personal de internación Imprimir
4
4
1.4.2.5.1
UI Personal administrativo - Gestion de nomenclaturas
4
RFI
El personal de administración deberá tener la capacidad de actualizar mensualmente, los importes de las prácticas médicas que se les lleva a cabo a los pacientes.
1.10.2.3
Control de Contabilidad - Importes Prácticas
8
1.8.1.1
Modulo personal de internacion Administracion de paciente Agregar paciente
6
1.8.1.2
Modulo personal de internacion Administracion de paciente - Form ingreso de paciente
4
1.8.1.3
Modulo personal de internacion Administracion de paciente - Egreso de paciente
6
1.12.1
Control de pacientes - Asignacion de turnos
8
1.17.1.4
Base de datos - Tablas - Tabla paciente
4
1.4.2.2.1
UI Personal de internacion Administracion de pacientes
4
1.5
Modulo SuperUsuario
30
1.4.1.4
GUI Doctor - Form Logueo
4
1.4.2.4
GUIS Personal - Form Logueo
3
1.13.1
Gestionador de personal - Agregar
4
1.13.2
Gestionador de personal - Modificar
4
27
28
RFE
Se deben poder registrar a los pacientes en el sistema.
29
RFI
El Súper Usuario debe tener acceso a todos los datos del sistema.
30
RFI
Se debe contar con un sistema de Login para identificar a cada usuario.
RFI
El administrador del sistema deberá tener la capacidad de crear cuentas para los distintos usuarios del sistema.
31
12
32
MIRAR COMENTARIO QUE DEJE ANTES DE IMPRIMIR
30 7
16
43
31
32
RFI
RFD
El administrador del sistema deberá tener la capacidad de crear cuentas para los distintos usuarios del sistema. Los administradores deben poder realizar en cualquier momento un backup de la base de datos.
1.13.3
Gestionador de personal - Borrar
4
1.13.4
Gestionador de personal Formulario agregar
4
1.17.2
Bases de Datos - Backup
16
16
16
44
Calendario Semanal Calendario Semanal Responsable
Luciano Cordoba
Horas por semana
RF2
Horas por semana
Gonzalo Pesado
Horas por semana
HS
Semana 1
HS
Semana 2
1.6.1.1 Asignar un turno
8
1.4.1.1 Administración Historia Clínica
1.6.1.2 Cancelar un turno
6
1.4.1.2 Visualización Historia Clínica
1.6.2.1 Agregar Obra Social
4
1.4.1.3 Administración Horario Laboral
1.6.2.2 Borrar Obra Social
4 1.7.2.1 Ingresar una historia clínica 8
22 1.2.2 Demo
Matías D´urbano
RF3
1.12.1 Asignación de turnos 8 1.12.2.1 Doctores
6
1.17.1.3 Tabla Doctores
4
26
1.12.2.2 Horarios
HS
6 1.4.2.2.1 Administración de Pacientes 4
1.4.2.2.2 Control de Habitaciones
4
6
1.8.2.1 Visualización de pacientes en espera
6
1.14.1.3 Modificar Habitación
6
6
1.8.1.1 Agregar Paciente
6
16
10
8 1.17.1.1 Tabla Personal de Recepción 4
1.4.2.2.2 Control de Contabilidad
6
1.17.1.7 Personal de Desposito
4
1.7.3.1 Cancelar Horarios
10
1.17.1.2 Tabla Personal de Internación
4
1.7.3.2 Agregar Horarios
6
1.4.2.5.1 Gestión de Nomenclaturas
4
1.14.1.1 Agregar Habitación
4
1.14.1.2 Borrar Habitación
4
20
24
1.1.7 Riesgos
4
1.1.8 Funcionalidades
6
1.1.9 Cambios
4
1.12.4.1 Administración de Sesiones Pendientes
7
1.1.9 Cambios
1.3.1.1 Evolucion de la prueba
4
1.12.4.3 Formulario de ingreso a sesión pendiente
3
1.3.1.1 Evolucion de la prueba
1.3.1.3 Actualizacion de documentacion
3
1.7.1.2 Pacientes
6
21
HS
Semana 2
26
8
Semana 1
1.3.1.2 Casos de prueba
22
6
10
1.1.7 Riesgos
4
1.3.1.2 Casos de prueba
6
1.1.8 Funcionalidades
6
1.3.1.3 Actualizacion de documentacion
6
18
4 1.14.2.2 Disponibilidad (Control Hab)
4
4
16
45
Maximiliano Pompilio
1.17.1.4 Tabla pacientes (BD)
4
1.10.2.1.1 Facturacion ocacional
8
1.4.2.3.1 Control de stock (GUI)
4
1.11.1.1 Ingreso (Stock)
8
1.17.1.5 Tabla turnos (BD)
4
1.10.2.1.2 Facturacion mensual
8
1.9.1 Ingreso (Personal Deposito)
6
1.11.1.2 Egreso (Stock)
8
1.10.1.1 Agregar nomenclatura
6
1.10.2.3 Importes de practicas
8
1.9.2 Egreso (Personal Deposito)
8
1.10.1.2 Form Agregar (Nomenclatura)
4
1.7.2.2 From Historia Clínica 6 Horas por semana
Lautaro Tacchini
24
16
1.19.1 Capacitación Maven
3
1.18.3 Preparacion de reuniones
4
1.2.3 Reunión con Gestión de Proyectos
2
1.18.4 Control de cambios
8
1.20 Diseño General del Sistema
10
1.18.4 Control de cambios
8
1.18.2 Informe de avances
3
1.18.3 Preparacion de reuniones
4
1.18.1 Reunion de avances
3
1.19.2 Capacitación Sistema de monitoreo de Capas de refrigeración
4
1.2.1.1 Minuta
3
1.14.2.1 Paciente (Control Hab)
6
1.18.2 Informe de avances
3 1.7.2.1 Ingresar una historia clínica 8
1.2.1.3 Actualización de Documentación
5
1.14.1.4 Formulario Habitación
4
1.8.1.2 Form Ingreso Paciente
4
1.12.4.2 Confirmar ingreso a 5 sesión pendiente Horas por semana
18
24
24
21
24
18
Calendario Semanal Responsable
RF4
RF5
46
Responsable
Luciano Cordoba
Horas por semana
Matías D´urbano
Horas por semana
Gonzalo Pesado
Horas por semana
Maximiliano Pompilio
Semana 1
HS
Semana 2
HS
Semana 1
HS
Semana 2
HS
1.13.1 Agregar Personal
4
1.5.1.1 SuperUsuario Modulo Doctores
3
1.17.2.1 Exportar (Back up)
8
1.22.1 Liberación
10
1.13.2 Borrar Personal
4
1.5.1.2 SuperUsuario Modulo Personal de Recepción
3
1.17.2.2 Importar (Back up)
8
1.13.3 Modificar Personal
4
1.5.1.3 SuperUsuario Modulo Personal de Administración
3
1.13.4 Formulario Agregar Personal
4
1.5.1.4 SuperUsuario Modulo Personal de Internación
3
16
12
Tiempo Dedicado a Cambios Finales 10
20
16
1.4.1.4 Form Logueo
4
1.5.1.5 SuperUsuario Modulo Personal de Deposito
3
1.12.3.1 Listado de Pacientes Imprimir
6
1..4.2.4 Form Logueo
3
1.5.1.6 SuperUsuario MOdulo Personal Administrativo
3
1.21 Manual
7
1.10.2.2 Liquidacion (Mensual a medicos)
10
17
1.16.1 Monitoreo de la camara de 10 Refrigeración
16
1.22.1 Liberación
10
Tiempo Dedicado a Cambios Finales 10
13
20
1.1.7 Riesgos
4
1.3.1.2 Casos de prueba
6
1.1.7 Riesgos
4
1.3.1.2 Casos de prueba
6
1.1.8 Funcionalidades
6
1.3.1.3 Actualizacion de documentacion
6
1.1.8 Funcionalidades
6
1.3.1.3 Actualizacion de documentacion
6
1.1.9 Cambios
4
1.1.9 Cambios
4
1.3.1.1 Evolucion de la prueba
4
1.3.1.1 Evolucion de la prueba
4
1.3.1.1 Evolucion de la prueba
4
1.22.1 Libreación
10
18
18
12
1.4.2.3.2 Administracion de proveedores (GUI)
4
1.17.1.6 Tabla proveedores (BD)
4
1.4.2.3.3 Compra de articulo (GUI) 8 1.9.3.1 Form compra (Personal Deposito)
4
26
1.15.2 Envio de mail (avisos)
8
1.15.1 Emitir aviso
8
1.22.1 Liberación
10
Tiempo Dedicado a Cambios Finales 10
47
Maximiliano Pompilio
Horas por semana
Lautaro Tacchini
Horas por semana
1.9.4.1 Agregar proveedor (Personal Deposito)
6
1.9.4.2 Form proveedor (Personal Deposito)
6
20
Tiempo Dedicado a Cambios Finales 10
12
16
20
1.2.3 Reunión con Gestión de Proyectos
2
1.5.2.1 SuperUsuario Agregar Usuarios
4
1.2.3 Reunión con Gestión de Proyectos
2
1.18.4 Control de cambios
8
1.18.2 Informe de avances
3
1.5.2.2 SuperUsuario Borrar Usuarios
4
1.18.2 Informe de avances
3
1.22.1 Libreación
10
1.2.1.1 Minuta
3
1.5.2.3 SuperUsuario Modificar Usuarios
4
1.2.1.1 Minuta
3
1.2.1.3 Actualización de Documentación
5
1.18.4 Control de cambios
8
1.2.1.3 Actualización de Documentación
5
1.18.3 Preparacion de reuniones
4
1.18.3 Preparacion de reuniones
4
17
20
17
18
48
Calendario
Calendario Fecha
RF
ID Req
Requerimientos
Peso
RFE
1
Los pacientes deben tener una historia clínica registrada en el sistema.
2
RFE
2
Los médicos deben poder consultar las historias clínicas de sus pacientes en todo momento.
5
RFE
3
Los médicos deben poder ingresar nuevos datos en la historia clínica de sus pacientes.
4
RFE
15
El personal de recepción podrá realizar el proceso de otorgamiento de turnos.
4
RFE
17
El personal de recepción debe tener la capacidad de cancelar un turno a través del sistema.
4
RFD
20
Los médicos deben poder visualizar los pacientes que tienen un turno para ese día.
5
RFE
21
El personal de recepción debe poder ingresar las autorizaciones de las obras sociales en el sistema.
3
RFI
22
Se deberá administrar las sesiones pendientes de cada paciente con sus correspondientes autorizaciones.
3
RFI
27
El personal de administración deberá tener la capacidad de Importar los importes de las prácticas médicas que se les lleva a cabo a los pacientes.
3
RFE
28
Se deben poder registrar a los pacientes en el sistema
5
RFD
16
El sistema debe enviar un recordatorio vía mail a cada paciente un día antes del turno registrado en el sistema. En caso que se haya cancelado un turno por parte de un médico, se debe enviar un mail al paciente informando la cancelación de su turno y la asignación de su nuevo turno.
4
RFE
18
El personal de recepción debe poder cancelar los rangos horarios de un determinado médico.
4
RFD
19
Se debe generar un listado de pacientes que se encuentren en una lista de espera correspondiente a cada doctor y que se hayan anunciado ante el personal de recepción.
3
RFE
23
El personal de internación debe poder ingresar al sistema los pacientes que deban ser internados en el hospital.
4
RFI
24
El personal de internación deberá poder realizar operaciones de gestión de habitaciones.
3
RFE
25
Se debe llevar un registro de todas las internaciones activas en el hospital.
1
RFI
27
El personal de administración deberá tener la capacidad de actualizar mensualmente, los importes de las prácticas médicas que se les lleva a cabo a los pacientes.
3
RFI
31
El administrador del sistema deberá tener la capacidad de crear cuentas para los distintos usuarios del sistema.
4
RFD
10
El sistema debe monitorear el sistema de refrigeración
2
RFD
11
Se deben poder emitir alertas desde el sistema.
1
8/5
22/5
Peso de Hito
38
26
49
5/6
23/6
El personal de recepción debe poder emitir facturaciones ocasionales.
RFE
12
RFE
14
Los médicos deben tener su liquidación mensual generada automáticamente por el sistema.
4
RFI
26
El personal de internación podrá imprimir el detalle de la internación de un paciente.
1
RFI
29
El Súper Usuario debe tener acceso a todos los datos del sistema.
5
RFI
30
Se debe contar con un sistema de Login para identificar a cada usuario.
1
RFD
32
Los administradores deben poder realizar en cualquier momento un backup de la base de datos.
4
RFE
4
El personal de depósitos debe poder visualizar los insumos que se presentan en el hospital.
5
RFI
5
El personal de depósito deberá poder realizar ordenes de compra.
5
RFI
6
El personal de depósito debe poder visualizar el stock del hospital el cual es administrado por el sistema.
2
RFI
7
El personal de depósito debe tener la capacidad de registrar el ingreso de stock.
3
RFI
8
El egreso de stock se debe registrar automáticamente cuando se realiza una internación en la cual se utilizan medicamentos.
3
RFI
9
El personal de depósito debe tener la capacidad de agregar, quitar o modificar la lista de proveedores.
5
RFD
16
En caso de que se cree una solicitud de compra, la misma debe ser enviada vía mail al email personal del proveedor.
4
Total
5
23
27
114
50
Funcionalidad Completa Id Req.
Tipo Req.
1
RFE
2
3
4
5
RFE
RFE
RFE
RFI
6
RFI
7
RFI
8
9
RFI
RFI
Requerimientos Los pacientes deben tener una historia clínica registrada en el sistema.
Los médicos deben poder consultar las historias clínicas de sus pacientes en todo momento.
Los médicos deben poder ingresar nuevos datos en la historia clínica de sus pacientes.
El personal de depositós debe poder visualizar los insumos que se presentan en el hospital. El personal de depósito deberá poder realizar ordenes de compra. El personal de depósito debe poder visualizar el stock del hospital el cual es administrado por el sistema. El personal de depósito debe tener la capacidad de registrar el ingreso de stock. El egreso de stock se debe registrar automáticamente cuando se realiza una internación en la cual se utilizan medicamentos.
El personal de depósito debe tener la capacidad de agregar, quitar o modificar la lista de proveedores.
Esfuerzo Esfuerzo Peso WBS Req.
Id WBS
Nombre padre - hijo WBS
1.7.2
Modulo Doctor - Administración de Historias Clínicas
6
1.7.1.2
Modulo Doctor - Pacientes
3
1.4.1.1
UI Doctor - Administración de historias clínicas
6
1.4.1.2
UI Doctor - Visualización de historias clínicas y pacientes
6
1.7.1.1
Visualización - Historia Clínica
6
1.17.1.3
Tablas - Tabla Doctores
4
1.4.2.4
GUIS Personal - Form Logueo
3
1.7.2.1
Adminitración de Historias Clínicas - Ingresar historia clínica
8
1.17.1.3
Tablas - Tabla Doctores
4
1.7.2.2
Adminitración de Historias Clínicas - Form Historia Clínica
6
1.4.2.3.1
UI Personal Deposito - Control de Stock
4
1.17.1.7
Tablas - Personal de Deposito
4
1.11.1
Control de Stock - Control Insumos
16
1.4.2.3.3
UI personal Deposito - Compra de Articulo
8
1.9.3
Modulo Personal de Deposito - Compra de Articulo
8
1.17.1.7
Tablas - Personal de Deposito
4
1.17.1.7
Tablas - Personal de Deposito
4
1.4.2.3.1
UI Personal Deposito - Control de Stock
4
1.4.2.3.1
UI Personal Deposito - Control de Stock
4
1.11.1.1
Control de Insumos - Ingreso
8
1.4.2.3.1
UI Personal Deposito - Control de Stock
4
1.11.1.2
Control de Insumos - Egreso
8
1.4.2.3.2
UI Personal Deposito - Administración de Proveedor
4
1.9.4
Modulo Personal de Deposito - Administración de Proveedor
12
9
2
25
5
18
4
24
5
20
5
8
2
12
3
12
3
24
5
51
9
RFI
El personal de depósito debe tener la capacidad de agregar, quitar o modificar la lista de proveedores.
1.17.1.6
Tablas - Tabla Proveedores
4
1.17.1.7
Tablas - Personal de Deposito
4
24
5
10
RFD
El sistema debe monitorear el sistema de refrigeración.
1.16.1
Control de monitoreo - Monitoreo de camaras de refrigeracion
10
10
2
11
RFD
Se deben poder emitir alertas desde el sistema.
1.15.1
Control de Avisos - Emitir Aviso
8
8
1
1.4.2.1.1
UI Personal de Recepción - Gestión de Turnos
6
1.4.2.4
GUIS Personal - Form Logueo
3
1.6.1.1
Gestión de Turnos - Asignar turno
8
25
5
1.10.2.1.1
Facturación - Facturación ocacional
8 14
3
16
4
18
4
8
4
16
4
16
4
12
3
32
5
12
RFE
El personal de recepción debe poder emitir facturaciones ocasionales.
13
RFE
El personal de administración debe tener la capacidad de emitir facturaciones mensuales.
1.4.2.5.2
UI Personal Administrativo - Gestión de Contabilidad
6
1.4.2.5.2
Facturación - Facturación Mensual
8
14
RFE
Los médicos deben tener su liquidación mensual generada automáticamente por el sistema.
1.4.2.5.2
UI Personal Administrativo - Control de Contabilidad
6
1.10.2.2
Control de Contabilidad - Liquidación
10
1.4.2.1.1
UI Personal de Recepción - Gestión de Turnos
6
RFE
El personal de recepción podrá realizar el proceso de otorgamiento de turnos.
1.6.1.1
Gestión de Turnos - Asignar turno
8
1.17.1.5
Tablas - Tabla Turnos
4
1.15.2
Control de Avisos - Envio de mail
6
1.4.2.1.1
UI Personal de Recepción - Gestión de Turnos
6
1.6.1.2
Gestión de Turnos - Cancelar Turno
6
1.17.1.5
Tablas - Tabla Turnos
4
1.4.2.1.1
UI Personal de Recepción - Gestión de Turnos
6
1.6.1.2
Gestión de Turnos - Cancelar Turno
6
1.17.1.5
Tablas - Tabla Turnos
4
1.4.1.2
UI Doctor- Visualización de historia clínica y Pacientes
6
1.7.1.2
Visualización - Pacientes
6
15
16
17
18
19
20
RFD
El sistema debe tener la capacidad de realizar notificaciones vía mail.
RFE
El personal de recepción debe tener la capacidad de cancelar un turno a través del sistema.
RFE
El personal de recepción debe poder cancelar los rangos horarios de un determinado médico.
RFE
Se debe generar un listado de pacientes que se encuentren en una lista de espera correspondiente a cada doctor y que se hayan anunciado ante el personal de recepción.
RFD
Los médicos deben poder visualizar los pacientes que tienen un turno para ese día.
1.4.1.2
UI Doctor - Visualización de historias clínicas y pacientes.
6
1.4.2.1.1
UI Personal de Recepción - Gestión de Turnos
6
1.6.1.1
Gestión de Turnos - Asignar turno
8
1.7.1.2
Visualización - Pacientes
6
52
20
RFD
Los médicos deben poder visualizar los pacientes que tienen un turno para ese día. 1.12.3
21
RFE
22
RFI
23
24
RFE
RFI
El personal de recepción debe poder ingresar las autorizaciones de las obras sociales en el sistema. Se deberá administrar las sesiones pendientes de cada paciente con sus correspondientes autorizaciones.
El personal de internación debe poder ingresar al sistema los pacientes que deban ser internados en el hospital.
El personal de internación deberá poder realizar operaciones de gestión de habitaciones.
Control de Pacientes - Listado de Pacientes
6
1.4.2.1.2
UI Personal de Recepción - Gestión de obras sociales
6
1.6.2
Módulo Personal de Recepción - Gestión de obras sociales
8
1.12.4
Control de pacientes - Administrador de sesiones
15
1.4.2.2.1
UI personal de Internación - Administración de pacientes
4
1.8.1.1
Administración de Pacientes - Agregar Paciente
6
1.8.1.2
Form Ingreso de Paciente
4
1.17.1.4
Tablas - Tabla Paciente
4
1.4.2.2.2
Ui personal de Internación - Control de Habitaciones
4
1.14.1
Control de habitaciones - Gestionador de habitaciones
16
1.14.2
Control de habitaciones - Asignacion
8
32
5
14
3
15
3
18
4
28
5
25
RFE
Se debe llevar un registro de todas las internaciones activas en el hospital.
1.17.1.4
Tablas - Tabla Paciente
4
2
1
26
RFI
El personal de internación podrá imprimir el detalle de la internación de un paciente.
1.8.1.4
Modulo personal de internación - Imprimir
4
4
1
1.4.2.5.1
UI Personal administrativo - Gestion de nomenclaturas
4
RFI
El personal de administración deberá tener la capacidad de actualizar mensualmente, los importes de las prácticas médicas que se les lleva a cabo a los pacientes.
12
3
32
5
27
28
RFE
Se deben poder registrar a los pacientes en el sistema.
1.10.2.3
Control de Contabilidad - Importes Prácticas
8
1.8.1.1
Modulo personal de internacion - Administracion de paciente - Agregar paciente
6
1.8.1.2
Modulo personal de internacion - Administracion de paciente - Form ingreso de paciente
4
1.8.1.3
Modulo personal de internacion - Administracion de paciente - Egreso de paciente
6
1.12.1
Control de pacientes - Asignacion de turnos
8
1.17.1.4
Base de datos - Tablas - Tabla paciente
4
1.4.2.2.1
UI Personal de internacion - Administracion de pacientes
4
53
29
RFI
El Súper Usuario debe tener acceso a todos los datos del sistema.
30
RFI
Se debe contar con un sistema de Login para identificar a cada usuario.
RFI
El administrador del sistema deberá tener la capacidad de crear cuentas para los distintos usuarios del sistema.
31
32
RFD
Entregas RF2 RF3 RF4 RF5
Los administradores deben poder realizar en cualquier momento un backup de la base de datos.
1.5
Modulo SuperUsuario
30
1.4.1.4
GUI Doctor - Form Logueo
4
1.4.2.4
GUIS Personal - Form Logueo
3
1.13.1
Gestionador de personal - Agregar
4
1.13.2
Gestionador de personal - Modificar
4
1.13.3
Gestionador de personal - Borrar
4
1.13.4
Gestionador de personal - Formulario agregar
4
1.17.2
Bases de Datos - Backup
16
30
5
7
1
16
4
16
4
Max Min (hs) (hs)
Semanas
Baseline
25 de Abril - 2 de Mayo
17,92%
1
1
5
2 de Mayo - 9 de Mayo
35,84%
2
6
10
Peso
9 de Mayo - 16 de Mayo
43,58%
3
11
15
16 de Mayo - 23 de Mayo
52,83%
4
16
20
23 de Mayo - 30 de Mayo
64,52%
5
21
25
30 de Mayo - 6 de Junio
74,35%
6 de Junio - 13 de Junio
87,17%
13 de Junio - 23 de Junio
100%
54
55
Administración de Riesgos Para identificar los riesgos que se presentan en el proyecto, inicialmente se realizará un análisis inicial de riesgos al inicio del proyecto y se identificaran los riesgos que se presentan. Una vez completa la lista inicial de riesgos, se procederá a calcular la probabilidad de ocurrencia de cada riesgo, su impacto en el proyecto y su nivel de exposición como resultado de multiplicar los valores de ocurrencia e impacto. La forma de clasificación a cada riesgo será la siguiente: Probabilidad Alta Media Baja
Impacto Alta Media Baja
Alta Media Baja
Definición de exposiciones Alta Media 9 6 6 4 3 2
3 2 1
3 2 1
Baja 3 2 1
Una vez definida la exposición a cada riesgo, de la lista total de riesgos, se seleccionarán aquellos 5 (TOP 5) que tengan mayor exposición y se les llevarán a cabo sus correspondientes acciones de mitigación y acciones de contingencia. Por último, se calculará el riesgo total de del proyecto y se anotará y actualizará de manera constante en cada reunión formal.
Forma de trabajo: ●
Se dedicará un tiempo a la evaluación de los riesgos en cada ciclo de desarrollo, de esta evaluación se actualiza la planilla de riesgos con nuevos riesgos si los hubiere o actualizando los valores de probabilidad y impacto de los mismos si hubieran cambiado.
●
Luego de cada evaluación se volverá a definir el TOP 5.
●
Se trabajará en realizar planes de mitigación y contingencia de los riesgos conformados en este TOP 5. No se evaluaran los demás debido a que puede llegar a ser una lista muy larga y muy costosa de analizar. Si ya existen planes de mitigación o contingencia para alguno de ellos, se pensara en cómo mejorarlos.
56
Listado de Riesgos Inicial Descripcion
No cumplir con los hitos
Severidad/I Exposicion Probabilidad mpacto del de ocurrencia al riesgo riesgo 3
3
9
3
3
9
2
3
6
Rearmado de Diseño
2
3
6
Reacción tardia en la toma de decisiones importantes
2
2
4
Omitir el uso de una herramienta de desarrollo beneficiable
2
2
4
2
2
4
2 1
2 3
4 3
Accidentes
1
3
3
Miembro del equipo con sobrecarga horaria
3
2
6
1 2 Riesgo Total
2 60
El cliente solicita cambios criticos y el equipo determina que deben ser llevados a cabo Los requerimientos no se han definido de manera correcta
La curva de aprendizage de la nueva herramienta es mas larga de lo esperado Se añaden requerimientos extras Enfermedades
Baja motivacion
57
TOP 5 - Riesgos
Descripcion No cumplir con los hitos
El cliente solicita cambios criticos y el equipo determina que deben ser llevados a cabo
Probabilidad Severidad/ de Impacto Exposicion ocurrencia del riesgo al riesgo 3
3
3
3
9
9
Responsable Acciones para mitigarlo Contingencia Se realiza una estimación inicial que permita Se reevaluara el calendario para completar con adapatar el tiempo de trabajo en caso de que no se las actividades no realizadas para la fecha llegue a cumplir con un hito. prevista. Reveer el documento de alcance con el cliente en cada reunion formal para asi lograr una vision conjunta de las caracteristicas del sistema.
Se negociara con el cliente aquellos cambios propuestos de manera tal que no impacten en gran medida con el diseño y desarrollo del proyecto.
Lautaro Tacchini / Gonzalo Pesado
Se acordara con el cliente aquellos requerimientos faltantes o que no hayan sido bien detallados.
Gonzalo Pesado
Los requerimientos no se han definido de manera correcta
2
3
6
Dedicar un tiempo a reveer requerimientos del sistema, tratar de aclarar con el cliente las funcionalidades que espera del sistema y ver si los requerimientos plasman esa realidad.
Rearmado de Diseño
2
3
6
Elaboracion de prototipos del sistema para validacion del usuario.
Evaluar una 2da alternativa de diseño.
Realizar una estimación inicial planeada para administrar adecuadamente los rangos de horarios de trabajo de cada miembro.
Redistribuir las tareas que sobrecargan a un miembro hacia otro miembros que tengan menos carga horaria o que se encuentren disponibles para relevar a su compañero.
Miembro del equipo con sobrecarga horaria
3
2
6
Lautaro Tacchini
Gonzalo Pesado Lautaro Tacchini
58
Administración de Cambios Para la documentación y gestión de cambios utilizaremos la siguiente plantilla: Fecha Resumen aparición
Detalle
Impacto Beneficio Análisis Validación
Fecha Fecha aprobación conclusión
Los valores de dicha planilla serán: ●
Fecha Aparición: Fecha en la que se propuso el cambio.
●
Resumen: Se detalla brevemente en qué consiste el cambio, lo utilizamos para identificar rápidamente el cambio.
●
Detalle: Se detalla el cambio para luego ser analizado por el equipo de trabajo y evaluar los detalles del cambio y cómo poder realizarlo.
●
Impacto: Cuánto impacta el cambio en el proyecto. Utilizaremos la siguiente escala ○
Alto = Es un cambio que por diversos motivos será muy laborioso de trabajar y a su vez puede conllevar a futuros problemas al implementarlo.
○
Medio = Es un cambio que si bien no desestabiliza el proyecto, su implementación traerá un costo considerable para implementar.
○
Bajo = Es un cambio que no afectara la estructura del proyecto, además su implementación no debería traer costos considerables de implementación.
●
Beneficio: Que tanto beneficia al usuario la implementación de dicho cambio, utilizamos la siguiente escala: ○
Alto = Grandes beneficios para el sistema al aplicarlos.
○
Medio = Cambios útiles para el sistema.
○
Bajo = Cambios poco significativos para el sistema.
●
Análisis: Detalla los pasos necesarios para aplicar el cambio.
●
Validación: Detalla si el cambio va a ser aplicado o no.
●
Fecha aprobación : Fecha en la que se aprueba el cambio
●
Fecha de conclusión: Fecha en la que el cambio ya está implementado en el sistema.
59
Forma de trabajo: ●
Los cambios serán relevados en cada reunión formal, de ese relevamiento se registraran en la planilla de cambios.
●
Durante el ciclo posterior al registro del cambio se analizará el cambio para determinar si el cambio se acepta o se rechaza.
●
En la próxima reunión formal, ya una vez analizado el cambio podrán ocurrir 2 escenarios: ○
Se negociará con el cliente sobre las condiciones de aceptación del cambio
○
Se explica al cliente porque no debe aceptarse el cambio y se negocia si el cambio debería ser re-evaluado.
60
Administración de Testing ●
El procedimiento para la elaboración de la documentación de test se basará en los siguientes pasos:
1) Elaboración y mantenimiento de planilla de bugs: En la misma consiste en un registro de los bugs del sistema. La misma consiste en: ○
BUG-ID: Identificador del bug, consiste en un número único referente al bug, si llega a ser un bug recurrente (bug resuelto previamente que reapareció) se agregara una R por cada aparición del mismo.
○
Categoría: Categoría del bug en cuestión, puede ser: i)
Crítico: Bug que impide la realización de una funcionalidad en cuestión, están relacionados con los criterios de aceptación de las pruebas.
ii)
Importante: Bug que dificulta la realización de la funcionalidad en cuestión. Por ej.: Ausencia de mensaje o mensaje poco descriptivo en la validación de un campo de un formulario.
iii)
Leve: Bugs referidos a pequeños desperfectos del sistema. Por ej.: Error ortográfico en algún mensaje, Texto en botones escondido, Errores visuales que provengan de la interfaz, etc.
○
Ciclo de aparición: Número de ciclo de la 1ra aparición del bug.
○
Fecha: Fecha exacta de aparición del bug
○
Descripción: Detalles sobre el bug, el mismo deberá proveer la suficiente información para poder ser resuelto.
○
Clases involucradas: Se detallan las clases involucradas en dicho bug.
○
Estado: Estado actual del bug, los estados pueden ser. i)
Abierto: Todavía no se asignaron recursos para que se arregle dicho bug
ii)
En corrección: Se asignaron recursos para resolver el bug.
iii)
Pendiente de aprobación: Se está esperando una aprobación del bug después de haber estado en corrección.
iv) ○
Corregido: El bug ya se encuentra solucionado.
Responsable: Responsable del seguimiento del bug. Ciclo de
BUG-ID Categoría aparición Fecha
Clases Descripción
involucradas
Fecha de Estado
corrección
Responsable
61
2) Registro semanal de bugs: Planilla que brindará soporte al indicador de evolución de la prueba, la misma consiste en: ○
Ciclo: Ciclo perteneciente a la revisión.
○
Rango de fechas: Rango de fechas de donde se basa la revisión
○
Bugs abiertos: Bugs incorporados a la planilla de bugs entre esas fechas
○
Bugs cerrados: Bugs solucionados entre esas fechas.
○
Pendientes: Bugs provenientes de fechas anteriores que todavía no se solucionaron.
Forma de trabajo: Con respecto con el trabajo en cada ciclo: ●
Se desarrollaran los casos de prueba pertinentes a las funcionalidades que se entregarán en dicha versión.
●
Se evaluará la planilla de bugs para saber sobre que bugs se debería trabajar en este ciclo.
●
Se realizará un mínimo 1 “prueba completa” por semana para aportar datos concisos al documento de testing. Con “pruebas completas” nos referimos a la realización de todas las pruebas posibles de realizar (que no posean dependencias todavía insatisfechas) del sistema. Los bugs pueden ser reportados por los mismos desarrolladores, para estos casos el tester realizará el mismo proceso de negocio en busca de un posible bug.
●
Semanalmente se completará el registro semanal de bugs. En el mismo se detallarán los bugs abiertos y cerrados a lo largo de la semana.
●
Se actualizarán los indicadores de evolución de la prueba teniendo en cuenta el registro semanal de bugs.
Con respecto a la validación de testing: ●
Una vez que desarrollo libere el código para la validación de testing, se ejecutarán los procesos de negocio pertenecientes a la funcionalidad a validar. ○
Para esto se ejecutarán TODAS las pruebas pertinentes a dicha funcionalidad, las mismas están detalladas en la planilla de pruebas.
○
Si en la ejecución de las mismas alguna de ellas se encuentra “desaprobada” (por lo tanto no cumple con los criterios de aceptación de la misma) la funcionalidad NO será validada por testing.
○
Si una funcionalidad se encuentra desaprobada por testing, se priorizará la corrección de los bugs críticos referidos a dicha funcionalidad. Una vez resuelto el último bug crítico, se volverá a evaluar la funcionalidad para ver si se validara.
○
Si se realizan cambios importantes en alguna funcionalidad que ya previamente validada, se volverá a realizar el proceso de validación.
62
23-6-2017
LABORATORIO DE CONSTRUCCION DE SOFTWARE PROYECTO: SI SALUD
Docentes: o o o o
Ing. Lucas Guaycochea. Lic. Javier Godoy Lic. Agustina De Napoli TSI Ivo Arcolini
Integrantes: o o o o o
Córdoba, Luciano D´urbano, Matías Pesado, Gonzalo Pompilio, Maximiliano Tacchini, Lautaro
Compañía: PentaSoft
Índice Descripción del proyecto………….…………………………………………..1 Equipo De Trabajo………………….…………………………………………1 Metodología………………………….………………………………………..2 Arquitectura…………………………………………………………………...2 Alcance………………………………………………………………………..5 Listado De Requerimientos…………………………………………………...8 Casos de Uso…………………………………………………………………15 WBS………………………………………………………………………….25 Diccionario WBS…………………………………………………………….32 Plan de Versiones…………………………………………………………….40 Estimaciones……………………………………………….…………………41 Documento de Riesgos…………………………………………………...…..56 Administración de Cambios...………………………….……………….........59 Administración de Testing..…………..………………………………...........61
Descripción del Proyecto Se solicita la realización de un software a medida para el Hospital Privado "Sí Salud" SRL, el cual lleva a cabo la gestión de sus pacientes, sus turnos, sus internaciones y las diferentes prestaciones que los mismos pueden realizarse en dicho hospital. Se deberá realizar un sistema de software que sustente la operatoria diaria realizada por los trabajadores del hospital. El hospital cuenta con varios sectores. En cada uno de ellos se llevan a cabo diferentes actividades. Por un lado, existe un sector de recepción en donde las personas se anuncian, ya sea por un turno que pidieron previamente o por una urgencia. Existe, también, un sector en donde los técnicos/profesionales atienden a sus pacientes en sus consultorios, aplicando las prácticas correspondientes. Por ejemplo, una consulta médica o una extracción de sangre. Por último, se tiene un área específica para las internaciones, donde los pacientes quedan internados durante un lapso de tiempo determinado. Las personas que asisten al hospital pueden tener una obra social o una prepaga que cubra las prácticas que desean realizarse o pueden ir de manera particular, pagando ellos mismos todos los costos. El sistema debe mantener una historia clínica de los pacientes, de forma que pueda ser consultada por los profesionales en todo momento y permita observar las consultas y diagnósticos previos de las distintas especialidades. Además, debe poder visualizarse claramente las patologías críticas o antecedentes relevantes de un paciente (Por ejemplo: asma, diabetes, operación de vesícula, etc.) A su vez, el hospital cuenta con dos depósitos en donde se guardan los insumos (medicamentos y materiales) que el hospital necesita. Uno de los dos depósitos es controlado por un sistema de refrigeración ya que existen algunos medicamentos que necesitan de una temperatura determinada mientras que otros medicamentos no lo requieren por lo que pueden ser guardados en un depósito común (a temperatura ambiente). Se desea que el sistema permita administrar el control de stock y los contactos con los proveedores y además pueda monitorear el sistema de refrigeración para emitir un alerta en caso de que la temperatura no se encuentre en el rango deseado. Por último, se quiere que el sistema permita realizar las facturaciones ocasionales a los pacientes particulares o por aquellas prácticas no cubiertas por su obra social o prepaga, y las facturaciones mensuales a las obras sociales para cobrarles los montos por las prestaciones otorgadas a sus afiliados. Además, se debe poder hacer la liquidación a cada profesional a partir de la cantidad de pacientes atendidos y las prácticas realizadas.
Equipo de Trabajo El equipo de trabajo se compone de 5 personas, 3 desarrolladores con un líder de desarrollo, un tester que también cumple la función de analista funcional y el jefe de proyecto.
1
●
Roles: ○
Córdoba, Luciano: Desarrollador.
○
D´urbano, Matías: Líder de Desarrollo, Desarrollador.
○
Pesado, Gonzalo: Tester, Analista Funcional.
○
Pompilio, Maximiliano: Desarrollador.
○
Tacchini, Lautaro: Jefe de Proyecto.
El principal objetivo de la distribución de roles de trabajo es lograr una mayor eficiencia en la distribución de las tareas a realizar.
Metodología La metodología que decidimos utilizar para la realización del proyecto es APF ya que consideramos que una metodología iterativo incremental es la que mejor se adapta a nuestra forma de trabajo y a las características del proyecto. Vamos a utilizar las fases de iteración que sugiere APF. Sin embargo, no vamos a utilizar todos los documentos formales que sugieren como por ejemplo el RBS. En el version scope vamos a definir el alcance del sistema utilizando la condición de satisfacción del usuario y se planificará la iteración a realizar. Luego en el cycle plan realizamos toda la parte relacionada con la planificación del proyecto (Requerimientos, Casos de Uso, WBS, etc). En el cycle build llevaremos a cabo las tareas de desarrollo y el client checkpoint estará relacionado con la reunión formal con el cliente donde evaluamos todo el trabajo realizado en la iteración. Por último se revisan los cambios que deben realizarse en el proyecto en cuanto a documentación y a código, y se vuelve a iterar.
Arquitectura El objetivo de este documento es el de mostrar cómo es la interacción entre las clases que componen nuestro sistema. Antes que nada, aclaramos que este diagrama fue realizado partiendo el sistema en 3 capas: Capa de presentación, Capa lógica y la capa de persistencia, dentro de las mismas irán las clases que estén integradas en cada capa según corresponda, las diferencias entre las capas serán las siguientes:
Capa de presentación: En esta capa irán las clases que sirvan como conexión entre el usuario y el sistema, dentro de las mismas veremos las interfaces gráficas junto con sus controladores ya que seguimos una estructura “MVC”.
Capa lógica: En esta capa irán las clases encargadas de realizar las operaciones del sistema o “core” de datos. Las mismas serán clases que realizarán toda la lógica de las operaciones.
2
Capa de persistencia: En esta capa irán las clases encargadas de persistir los datos necesarios. En esta misma usaremos el patrón de diseño DAO para cada uno de los objetos que nos interese persistir. Los DAOS constan de una implementación específica para conectarse al motor de bases de datos MySQL.
En el siguiente diagrama se muestra la interacción entre todos los módulos que componen nuestro sistema, y evidencia la división de las tres capas.
3
4
Usuarios Del Sistema A continuación detallaremos, los usuarios con los que contará nuestro sistema: ○ Administrador del sistema: Personal encargado de la administración de usuarios del sistema. ○ Médicos: Profesionales que trabajan dentro del hospital atendiendo pacientes (trabajan con las historias clínicas y con los pacientes). ○ Personal Administrativo: Personal encargado de la gestión administrativa del hospital (sueldos, personal, cobros). ○ Personal de Depósito: Personal encargado de la gestión de stock, y el monitoreo de los depósitos. ○ Personal de Internación: Personal que realiza las internaciones a los pacientes y realiza un seguimiento de las mismas. ○ Personal de Recepción: Personal encargado de recibir a los pacientes y gestionar los turnos. ○ SuperUsuario: Usuario general que podrá acceder a todas las secciones del sistema (por ejemplo: dueño del hospital).
Alcance Definimos el alcance con la condición de satisfacción de usuario relacionado con los requerimientos del sistema.
Funcionalidad
Responsabilidad del sistema
No contemplado por el sistema
Gestión de usuarios
El único usuario capaz de gestionar otros usuarios será el administrador del sistema, El mismo podrá crear, modificar y eliminar cualquier usuario (Inclusive otros administradores).
El sistema no permitirá crear el administrador del sistema primario, que será el que luego cree a todos los usuarios del sistema, el 1er administrador del sistema será creado por defecto y sus datos de logueo serán entregados al cliente, luego el mismo podrá crear otros administradores o demás usuarios desde la cuenta de administrador. Cuándo se quiere eliminar un usuario en el sistema, el mismo no es eliminado de la base de datos ya que puede haber datos ligados al mismo, el sistema ocultara el usuario para que no se puedan realizar operaciones con él.
5
Login de usuarios
Se poseerá un login que permite a todo El sistema no contemplara loggins de usuario realizar sus tareas en el sistema. pacientes, las operaciones con los mismos serán realizadas mediante el personal de secretaría, de internación y el superusuario.
Gestión de historias clínicas
Los médicos solo pueden asignar nuevas El sistema no permitirá modificar ni entradas a la historia clínica de un eliminar entradas correspondientes a una paciente. historia clínica de un paciente.
El médico deberá tener en pantalla la historia clínica del paciente una vez atendido y ahí podrá agregar la entrada a la historia clínica del paciente. Gestión de turnos
El personal de secretaría y el superusuario podrán gestionar los turnos, tanto la creación, modificación y cancelación de los mismos. El personal de secretaría y el superusuario podrá seleccionar una fecha para asignar un turno y el mismo mostrará los horarios disponibles de cada médico. El personal de secretaría y el superusuario podrán dar de alta pacientes en la lista de espera y se mostrarán en una pantalla donde se vea en tiempo real los pacientes. NOTA: Con “tiempo real” nos referimos a que se deberá actualizar la pantalla del médico cada vez que su secretaria agregue una persona a la lista de espera. Para recordar el turno al paciente, el sistema le enviara un mail el día anterior recordando el turno. Se debe poder agregar un horario restringido para enviar los mails.
Gestión de internaciones
Si llega a pasar que luego de la consulta con el médico, el paciente necesite intervención, la misma será solicitada por el paciente directamente en internaciones, utilizando algún mecanismo de comunicación entre el médico y el personal de internaciones (que puede ser por ejemplo una orden
El sistema llevará un registro de las internaciones que se realicen en el hospital. Nuestro sistema solo se encargará de verificar si las habitaciones se encuentran disponibles o no para ser ocupadas por un paciente. Solo se podrá visualizar en nuestro sistema si las habitaciones están ocupadas o libres, no
6
firmada de internación).
Gestión de Stock
realizará sugerencias de ningún tipo una habitación. Las habitaciones son seleccionadas de acuerdo al criterio del personal de internación.
El sistema permitirá al Personal de El sistema no gestionara si el stock está depósito y al Superusuario gestionar el físicamente en el depósito, esto lo stock. deberá controlar el personal de depósito, se supone que el personal de depósito controlara el pedido y registrará que dicho pedido llegó con éxito. El sistema no enviará ningún tipo de alerta si existe bajo stock.
Gestión de órdenes de compra
El personal de depósito y el superusuario pueden crear órdenes de compra cuando lo crean necesario. Para las mismas se deben detallar los artículos correspondientes al pedido y enviar el pedido vía mail al proveedor, el sistema además deberá permitir buscar e imprimir dichas órdenes para agilizar sus tareas.
El sistema no almacenará los tickets de las órdenes de compra, en cambio, se podrán buscar, seleccionar la que deseamos para volverla a imprimir.
Impresiones
El sistema se encargará de imprimir tickets, liquidaciones de sueldo, listas de pacientes, liquidaciones para obras sociales y solicitudes de compra.
El sistema no almacenará documentos que se imprimieron. Los datos de los mismos podrán ser buscados y podrán volverse a imprimirlo si es necesario.
Gestión de obras sociales
El sistema debería tener un registro de las prácticas autorizadas por las obras sociales, estas mismas deberán estar disponibles para modificar en todo momento y la persona autorizada para esto es el administrador / secretaria. El sistema deberá detectar las prácticas que están cubiertas a la obra social a la hora de un turno enviando un mensaje a la secretaria si alguna de las prácticas no está cubierta por la obra social.
Debido a los posibles cambios en los precios de los artículos, el sistema no calculará el costo de las órdenes de compra, el monto total debe ser asignado luego de la respuesta del proveedor por el personal de depósito.
Con respecto a las prácticas que necesiten autorización de la obra social, el sistema no ayudará al paciente con la gestión de la misma, se supone que es un problema entre el paciente y su prestadora del servicio por ende no nos compete. La validación de la misma la debería hacer el personal de recepción,
7
una vez que el personal de recepción valide la autorización, podrá asignar la autorización presentada a cada paciente según las prácticas que deba hacerse. Sistema de refrigeración
El sistema se encargará de controlar El sistema no se encargará de realizar mediciones de temperatura de la cámara dicha medición, La misma será medida refrigerada, enviando alertas en caso de por un sistema externo. que la temperatura este en un valor no habitual.
Contabilidad
Con respecto al cobro de los médicos, el sistema les calculara el mismo teniendo en cuenta el salario básico del mismo junto con las prácticas que realizaron. Con respecto a las prácticas, el sistema calculará el monto que se lleve el medico por las prácticas realizadas (dependiendo del porcentaje destinado para el médico en cada práctica). El sistema deberá gestionar un listado de cuánto cobran de básico cada médico y además cuánto cobran por una consulta.
Gestión de practicas
Las prácticas deben tener al menos un profesional que las realice, pueden ser varios tipos de profesional por cada práctica. Al momento de crear la práctica se deben elegir los médicos que participen de la misma, estos deben cumplir la cantidad de especialistas necesaria para la práctica.
El sistema no contemplara las ganancias o pérdidas del hospital, con esto queremos decir que no lleva una contabilidad de la misma, consideramos que esto lo deberá realizar el personal administrativo. El sistema proveerá todas las herramientas necesarias para dicha labor tales como: órdenes de compra (costo), liquidaciones de sueldo (costo), cobro de prácticas (ingresos). Consideramos que para llevar una contabilidad seria se deben tener en cuenta diversos factores que inciden en ella y no son vistos por el sistema.
Requerimientos ●
Listado de Requerimientos del sistema
●
Notación: Numeramos los requerimientos Funcionales por un lado, y los Requerimientos no funcionales por otro. Clasificamos cada requerimiento como Esencial (E), Importante (I), Deseable (D).
●
RFE1: Los pacientes deben tener una historia clínica registrada en el sistema. _Detalle: ○
Se deben registrar todas las consultas de los pacientes en la historia clínica.
8
○
En la historia clínica se debe incluir los diagnósticos previos de las distintas especialidades.
○
En la historia clínica se debe poder visualizar fácilmente las patologías críticas o antecedentes relevantes del paciente.
○
En el reporte de la historia clínica se mostrarán primero las patologías críticas o antecedentes relevantes del paciente.
●
RFE2: Los médicos deben poder consultar las historias clínicas de sus pacientes en todo momento. _Detalle: ○
Cuando el medico consulte las historias clínicas se deben resaltar los datos relevantes del paciente.
●
RFE3: Los médicos deben poder ingresar nuevos datos en la historia clínica de sus pacientes. _Detalle: ○
El médico, luego de realizar la consulta, ingresa en la historia clínica los detalles de la nueva consulta y los diagnósticos pertinentes junto con la fecha de consulta.
●
RFE4: El personal de depósitos debe poder visualizar los insumos que se presentan en el hospital. _Detalle:
●
○
Se lleva un registro de los materiales y medicamentos que se disponen en el hospital.
○
El sistema cuenta con dos depósitos (uno común y otro con refrigeración).
RFI5: El personal de depósito deberá poder realizar órdenes de compra. _Detalle:
●
○
Una orden de compra tiene un código, artículo y cantidad de artículos.
○
Una vez creada se enviará por mail al proveedor.
RFI6: El personal de depósito debe poder visualizar el stock del hospital el cual es administrado por el sistema. _Detalle: ○
Con stock nos referimos a los insumos del hospital.
○
Se debe mostrar el stock total del hospital.
○
El sistema debe permitir visualizar de manera individual todos los insumos que se encuentran en stock.
○
Los insumos deben poder filtrarse por sus distintas categorías.
9
●
RFI7: El personal de depósito debe tener la capacidad de registrar el ingreso de stock. _Detalle: ○
El stock se registra con: nombre, código, proveedor, si requiere receta y si necesita estar refrigerado.
●
RFI8: El egreso de stock se debe ser registrado por el personal de depósito cuando se hace uso del stock del hospital. _Detalle ○
Los egresos pueden ser por insumos del hospital y/o por la utilización de los mismos por el mismo personal del hospital.
●
RFI9: El personal de depósito debe tener la capacidad de agregar, quitar o modificar la lista de proveedores. _Detalle: ○
El sistema debe tener un listado de los proveedores del hospital.
○
El listado debe poder ser editado por el personal de depósito.
○
Cuando se desee contactarse con un proveedor se deben mostrar los datos correspondientes al proveedor.
○
El proveedor se registra en el sistema con un CUIT, un nombre, una dirección, un teléfono y un mail para contactarlo.
●
RFD10: El sistema debe monitorear el sistema de refrigeración. _Detalle: ○
Nuestro sistema se debe comunicar con el sistema de refrigeración, el cual controla la temperatura del depósito con refrigeración, para llevar un seguimiento de la temperatura.
●
RFD11: Se deben poder emitir alertas desde el sistema. _Detalle: ○
El sistema emitirá una alerta si el sistema de refrigeración informa que el depósito excedió la temperatura límite.
●
RFE12: El personal de recepción debe poder emitir facturaciones ocasionales. _Detalle: ○
Se emite facturas ocasionales a los pacientes particulares.
10
○
Se emite facturas ocasionales a los pacientes que deben realizar prácticas que no son cubiertas por sus obras sociales o prepagas.
●
RFE13: El personal de administración debe tener la capacidad de emitir facturaciones mensuales. _Detalle: ○
Las facturaciones mensuales se realizar a las obras sociales para cobrar los montos respectivos a las prestaciones otorgadas a sus afiliados.
●
RFE14: Los médicos deben tener su liquidación mensual generada automáticamente por el sistema. _Detalle: ○
La liquidación mensual se realiza a partir de la cantidad de pacientes atendidos y las prácticas realizadas.
●
RFE15: El personal de recepción podrá realizar el proceso de otorgamiento de turnos. _Detalle: ○
El personal de recepción podrá ingresar la fecha sobre la cual se desea otorgar el turno, cuando se selecciona la fecha se pueden visualizar los turnos ya tomados y los turnos libres para esa fecha. Luego el personal de recepción podrá seleccionar una lista de todas las especialidades, al seleccionar la especialidad se abrirá una lista con todos los médicos. Para completar la operación el personal de recepción, seleccionando un horario e indicando el nombre del paciente, otorga el horario y pasa a estar ocupado. Esta operación es registrada en el sistema.
○
Al haber realizado el otorgamiento del turno se imprime un comprobante con los datos: el nombre de paciente junto con su, la fecha y horario del turno, y el médico que corresponde al turno.
○ ●
Se deben poder filtrar los turnos por fecha por hora.
RFD16: El sistema debe tener la capacidad de realizar notificaciones vía mail. _Detalle: ○
El sistema debe enviar un recordatorio vía mail a cada paciente un día antes del turno registrado en el sistema.
○
En caso que se haya cancelado un turno por parte de un médico, se debe enviar un mail al paciente informando la cancelación de su turno y la asignación de su nuevo turno.
11
○
En caso de que se cree una solicitud de compra, la misma debe ser enviada vía mail al email personal del proveedor, se debe detallar en la solicitud la lista de artículos, con sus códigos, junto con las cantidades de cada uno, subtotal y total de toda la orden.
●
RFE17: El personal de recepción debe tener la capacidad de cancelar un turno a través del sistema. _Detalle: ○
El paciente puede solicitar cancelar un turno o cambiarlo de día, y el personal de recepción llevará a cabo esa acción.
●
RFE18: El personal de recepción debe poder cancelar los rangos horarios de un determinado médico. _Detalle: ○
Si el médico cancela su día o algún rango de los horarios el sistema automáticamente debe cancelar los turnos asociados a los horarios cancelados.
○
El sistema asignará automáticamente un nuevo turno al paciente que será informado vía mail. Si el paciente no puede cumplir con ese turno podrá solicitar uno nuevo.
●
RFE19: Se debe generar un listado de pacientes que se encuentren en una lista de espera correspondiente a cada doctor y que se hayan anunciado ante el personal de recepción. _Detalle: ○
El personal de recepción ingresa al sistema los pacientes que ya fueron anunciados y que tienen la autorización correspondiente aprobada.
○
El personal de recepción debe tener la capacidad de imprimir el listado de turnos que tiene un médico particular en la fecha correspondiente.
●
RFD20: Los médicos deben poder visualizar los pacientes que tienen un turno para ese día. _Detalle: ○
El médico podrá visualizar en una pantalla todos los pacientes que deba atender en el día correspondiente.
○
Se visualizan tanto los pacientes que ya se encuentran en la sala de espera y están listos para ser atendidos como los pacientes que no se hayan anunciado aún.
○ ●
Se indica en pantalla si un paciente ya se ha anunciado o no.
RFE21: El personal de recepción debe poder ingresar las autorizaciones de las obras sociales en el sistema. _Detalle
12
○
Junto con la autorización se ingresan los datos del paciente, su diagnóstico, el médico solicitante, la fecha de autorización y las prácticas a realizarse con su correspondiente nombre, código y cantidad de sesiones a realizar.
●
RFI22: Se deberá administrar las sesiones pendientes de cada paciente con sus correspondientes autorizaciones. _Detalle: ○
El sistema tendrá un registro de las sesiones totales autorizadas que tiene cada paciente y a medida que el paciente vaya realizando las sesiones el sistema automáticamente irá descontando las sesiones usadas.
●
○
Si las sesiones no están autorizadas no pueden realizarse.
○
Puede haber sesiones o prácticas que no requieran autorización.
RFE23: El personal de internación debe poder ingresar al sistema los pacientes que deban ser internados en el hospital. _Detalle: ○
Se debe poder visualizar el listado de pacientes esperando internación.
○
Se deben asociar las autorizaciones correspondientes a la internación de cada paciente.
○
El sistema debe informar si una habitación se encuentra disponible o no.
○
Los pacientes de internación se registran como un paciente común que se va a realizar una práctica más con la diferencia que requiere internación.
●
RFI24: El personal de internación deberá poder realizar operaciones de gestión de habitaciones. _Detalle: ○
Cuando se realiza una internación el sistema registra un ingreso y la habitación pasa a estar ocupada.
○
Cuando una internación finaliza el sistema registra un egreso y la habitación pasa a estar libre.
○
El personal de internación también podrá registrar el pasaje de un paciente de una habitación a otra en caso de que sea necesario.
○
El personal de internación debe poder reservar una habitación previendo la fecha de internación tentativa de un paciente. Cuando se reserva una habitación, se registra fecha de ingreso tentativa y fecha de egreso tentativa.
●
RFE25: Se debe llevar un registro de todas las internaciones activas en el hospital.
13
_Detalle: ○
Se deberá asociar al paciente con la práctica a realizar que amerite la internación junto con las autorizaciones correspondientes que le competan.
○
Se asociará una fecha de egreso tentativa.
○
Cada internación tendrá los datos del paciente, el diagnóstico correspondientes, la fecha de ingreso, la habitación en la que está hospedado y una observación.
○
Cuando se realiza una internación el sistema registra una fecha de ingreso y la fecha es adjuntada a los datos del paciente.
○
Cuando el paciente egresa del hospital se registra el egreso en el sistema junto con la fecha real de egreso, el motivo, una descripción y el diagnóstico final.
○
Se debe registrar la fecha de internación y las prestaciones adicionales que se realicen durante la internación.
●
RFI26: El personal de internación podrá imprimir el detalle de la internación de un paciente. _Detalle ○
En el detalle de la internación se incluye el monto a pagar en caso de que sea particular o las prácticas realizadas sobre el paciente que no estén cubiertas por su prepaga u obra social, y los datos de internación del paciente.
●
RFI27: El personal de administración deberá tener la capacidad de actualizar mensualmente, los importes de las prácticas médicas que se les lleva a cabo a los pacientes. _Detalle ○
En una planilla se guardan los códigos, las descripciones, el nombre y el precio de cada práctica que realiza el hospital. El personal administrativo tendrá permiso para actualizar esta planilla.
○
Se debe llevar un registro de las nomenclaturas de las prácticas realizadas por el hospital.
○
En el registro se incluye código, descripción, importe y un estado si están autorizadas o no.
○
Se debe tener un importador de prácticas que importe las nomenclaturas desde un formato conveniente.
●
RFE28: Se deben poder registrar a los pacientes en el sistema. _Detalle: ○
Los pacientes son registrados con nombre, DNI, numero de afiliado (obra social o prepaga), su plan y nombre de prepaga, un contacto y un número de emergencia.
14
●
RFI29: El Súper Usuario debe tener acceso a todos los datos del sistema. _Detalle: ○
El Súper Usuario es creado por el administrador de usuarios y tiene acceso a todas las pantallas del sistema sin restricciones, con sus funcionalidades incluidas.
●
RFI30: Se debe contar con un sistema de Login para identificar a cada usuario. _Detalle: ○
Se deben registrar al personal administrativo, al personal de depósito, al personal de recepción y a los médicos.
○ ●
Contamos con un administrador general que asigna permisos a los usuarios.
RFI31: El administrador del sistema deberá tener la capacidad de crear cuentas para los distintos usuarios del sistema. _Detalle: ○
Inicialmente el sistema otorgará la cantidad de cuentas de administrador que sean necesarias.
○ ●
El administrador crea cuentas de usuario con nombre de usuario y contraseña.
RFD32: Los administradores deben poder realizar en cualquier momento un backup de la base de datos. _Detalle: ○
El backup realizado debe exportarse en un formato adecuado para poder identificarlo y guardarlo.
○
El sistema debe poder incorporar bases de datos generadas a partir del mismo sistema en el formato definido.
Casos De Uso
15
16
17
Cartillas Casos de Uso ● Realizamos cartillas únicamente de los casos de uso más importantes del sistema.
Caso de Uso: CU1 - Otorgando turno Actor: Personal de recepción Descripción: El personal de recepción otorga un turno a un paciente. Requerimientos asociados: RFE15 Precondición: El personal de recepción debe estar autenticado. Postcondición: El turno es otorgado al paciente y se emite un comprobante. Curso normal
Alternativas
1. .El personal de recepción le
pide al sistema asignar turno a paciente 2. El sistema muestra el formulario correspondiente (req 12: Detalle) y el personal de recepción lo completa.
2.1 No hay ningun medico disponible para esa especialidad, el sistema muestra un aviso notificando esto. Ir a Fin Caso de Uso
3. Se selecciona un médico y se muestran los horarios disponibles correspondientes al médico seleccionado.
3.1 El médico seleccionado no posee horarios disponibles. Ir paso 2.
4. El sistema registra el turno e imprime comprobante con los datos del turno. Fin Caso de uso. Detalle: Un turno está compuesto por un código, día y horario, paciente, médico e importe. Se deben poder filtrar los turnos por fecha y horario.
18
Caso de Uso: CU2 - Cancelando Turno Actor: Personal de recepción Descripción: El personal de recepción registra el turno de un paciente. Requerimientos asociados: RFE17 Precondición: El turno tiene que estar registrado y debe ser posterior a la fecha actual. Postcondición: El turno no se encuentra registrado Curso normal 1.El sistema muestra los turnos registrados 2.El personal de recepción selecciona el turno a cancelar 3. El sistema envía un mail al paciente, Usa CU16 4. El sistema borra el registro de turno Fin Caso de uso.
Caso de Uso: CU7 - Colocando paciente en lista de espera Actor: Personal de recepción Descripción: Se ingresan los pacientes a la lista de espera Requerimientos asociados: RFE19 Precondición: El turno del paciente tuvo que ser abonado previamente o tiene que estar cubierto por la prepaga/obra social. Deben estar presentadas las correspondientes autorizaciones para la práctica o consulta Postcondición: El turno es otorgado y el paciente pasa a estar en la lista de espera.
19
Curso normal
Alternativas
1. Se selecciona el turno al que el paciente se vino a anunciar 2. Si todo está correcto el paciente está ahora en la lista de espera
2.1 Si el paciente o no tiene las autorizaciones correspondientes, o no tiene pago el turno, entonces se notifica al usuario(recepcionista) y no se puede proceder . Ir Fin Caso de Uso
Fin Caso de uso. Detalle: Una vez en la lista de espera, el paciente aparecerá en la lista del doctor de pacientes en espera.
Caso de Uso: CU5 - Consultando pacientes. Actor: Personal de recepción. Descripción: El personal de recepción consulta los pacientes anunciados encuentran en lista de espera.
que se
Requerimientos asociados: RFE19 Precondición: El personal de recepción debe estar autenticado Postcondición: Curso normal
Alternativas
1. El personal de recepción solicita consultar los pacientes anunciados en lista de espera
1.1 Sino se ha anunciado ningún paciente hasta el momento se muestra un error en pantantalla. Ir a fin caso de uso.
2. El sistema muestra aquellos pacientes que la recepcionista haya indicado como anunciado. 3. La recepcionista imprimir lista.
pide
20
Fin Caso de uso.
Caso de Uso: CU25 - Consultando historia clínica Actor: Médico Descripción: El médico visualiza la historia clínica de un paciente en particular. Requerimientos asociados: RFE1 - RFE2 Precondición: El Médico debe estar autenticado en el sistema. Postcondición: Información de la historia clínica Curso normal
Alternativas
1.El médico le pide al sistema consultar historia clínica 2. El médico selecciona paciente 3. El sistema muestra un reporte con la historia clínica del paciente.
3.1 el sistema le indica al médico No tiene historia clínica.
Fin Caso de uso.
Caso de Uso: CU12 - Comunicando con servicio externo de mails. Actor: Servidor Externo de emails Descripción: El sistema envía una petición al servicio de mail para enviar el mensaje que corresponda. Requerimientos asociados: RFD16 Precondición: Se realiza una acción que implique enviar un mail. Postcondición: El mail es enviado.
21
Curso normal
Alternativas
1. Nuestro sistema solicita enviar un mail. 2. El sistema envía el pedido al servidor
2.1 Si el servidor no se encuentra disponible el sistema guarda el pedido de envió y volverá a solicitar cada 10 minutos.
3. El servidor confirma la recepción del pedido de envío al sistema.
Fin Caso de uso.
Caso de Uso: CU22 - Emitiendo facturación mensual Actor: Personal administrativo Descripción: El personal administrativo realiza las facturaciones mensuales a las obras sociales y/o prepagas que deban cubrir los gastos en sus pacientes que realizaron prácticas en el hospital. Requerimientos asociados: RFE13 Precondición: El personal administrativo debe estar autenticado Postcondición: Se emite la facturación mensual. Curso normal 1. El personal administrativo solicita la realización de la facturación mensual. 2. El sistema calcula el total que va a facturar a cada obra social o prepaga y lo almacena. 3. Se genera un reporte que permite observar las facturaciones de todas las obras sociales, mostrando el total. Fin Caso de uso. Detalle: Para calcular cuánto se le va a cobrar a cada obra social, se suman todos los importes de todas las prácticas realizadas a pacientes afiliados.
22
Caso de Uso: CU24 - Realizando liquidación del personal. Actor: Personal administrativo. Descripción: El personal administrativo realiza la liquidación de sueldo de todos los médicos del hospital. Requerimientos asociados: RFE14 Precondición: El personal administrativo debe estar autenticado Postcondición: Se realiza la liquidación de sueldo. Curso normal 1. El personal administrativo solicita realizar la liquidación de sueldo. 2. El sistema calcula el total del sueldo de cada profesional. 3. Se genera un reporte para que permite observar las liquidaciones de todos los profesionales y que permita ver el total. Fin Caso de uso. Detalle: Para calcular la paga de cada profesional se tiene en cuenta el sueldo de ese profesional, y se le suma por cada práctica un porcentaje definido por el sistema.
Caso de Uso: CU13 - Realizando orden de compra Actor: Personal de depósito. Descripción: El personal de depósito realiza una orden de compra a un proveedor para conseguir insumos. Requerimientos asociados: RFI5 Precondición: El personal de depósito debe estar autenticado Postcondición: Se emite una orden de compra al proveedor. Usa CU12. Curso normal
Alternativas
23
1. Se selecciona un proveedor. 2. Se ingresa un ítem a esta orden de compra, que consiste de producto y cantidad y precio x cantidad. 3. Se confirma la orden de compra, el sistema la almacena, imprime la orden y también la envía por email al proveedor.
3.1 Se desea cancelar la orden de compra. Ir a Fin Caso de Uso
4. Se envía un mail al proveedor para solicitar el producto. Usa CU12. Fin Caso de uso.
Caso de Uso: CU15 - Registrando ingreso de stock Actor: Personal de depósito Descripción: El personal de depósito ingresa el entrante de una orden de compra Requerimientos asociados: RFI6 Precondición: El personal de depósito debe estar autenticado. Postcondición: El stock correspondiente es registrado en el sistema. Curso normal 1. El personal de depósito selecciona una orden de compra y la confirma 2. El sistema actualiza el stock del insumo ingresante Fin Caso de uso. Detalle: En caso de que los insumos lleguen incompletos se toman los insumos que llegaron y se realiza un nuevo pedido con los insumos faltantes.
24
WBS
25
26
27
28
29
30
31
Diccionario de la WBS CODIGO DE PAQUETE DE TRABAJO
NOMBRE DE PAQUETE DE TRABAJO
DESCRIPCION DE TAREAS
RESPONSABLES
ESTIMACION (HORAS)
556
1.0
Si Salud
Desarrollo completo del sistema Si Salud
Lautaro Tacchini Gonzalo Pesado Matías D´urbano Luciano Cordoba Maximiliano Pompilio
1.1
Planificación
Tareas que involucran la planificación de tareas previas al desarrollo del sistema.
Lautaro Tacchini
48
1.1.1
Alcance
Se elabora el alcance total del proyecto.
Lautaro Tacchini
6
1.1.2
Requerimientos
Se detallan los requerimientos con los cuales debe cumplir nuestro sistema.
Lautaro Tacchini
6
1.1.3
WBS
Se realiza el diagrama WBS para organizar las tareas a realizar dentro del proyecto.
Lautaro Tacchini
6
1.1.4
Diccionario WBS
Se detallan cada una de las tareas de la WBS en un documento.
Lautaro Tacchini
6
1.1.5
Asignación de Roles
Se asignan los roles estrategícos a cada uno de los recursos.
Lautaro Tacchini
3
1.1.6
Casos de Uso
Se elabora el diagrama de casos de uso de nuestro sistema.
Lautaro Tacchini
7
1.1.7
Riesgos
Se realiza un plan de riesgos que decide cuales son los riegos que se asumen y de que manera.
Gonzalo Pesado Lautaro Tacchini
4
1.1.8
Funcionalidades
Analisis sobre las funcionalidades que debe cumplir nuestro sistema y cual es el alcance.
Gonzalo Pesado
6
1.1.9
Control de Cambios
Se previenen los cambios que puede llegar a sufrir el sistema.
Gonzalo Pesado
4
1.2
Gestión de Entregas
Reniónes formales con el cliente.
Lautaro Tacchini
27
1.2.1
Control de Avances
Analisis de avance del proyecto.
Lautaro Tacchini
6
1.2.1.1
Informe de avances
Redacción del informe de avances.
Lautaro Tacchini
3
1.2.1.2
Minuta
Redacción de la minuta en donde se especifica lo hablado en la reunión formal.
Lautaro Tacchini
3
1.2.1.3
Actualización de Documentación
Se actualiza la documentación de acuerdo a los establecido en la reunión formal.
Lautaro Tacchini
5
32
1.2.2
Demo
Elaboración de una demo del producto para la reunión formal.
Matias D´urbano
8
1.2.3
Reunión con Gestión de Proyectos
Reunión formal con la gente de gestión de proyectos.
Lautaro Tacchini
2
1.3
Control de Calidad
Tareas relacionadas con el control de calidad del producto.
Gonzalo Pesado
16
1.3.1
Testing
Realización de las pruebas establecidas para verificar que el sistema cumpla adecuadamente con las funcionalidades pautadas.
Gonzalo Pesado
16
1.3.1.1
Evolución de Pruebas
Elaboración del documento que evalua la cant. de bugs corregidos y la cant. de bugs encontrados.
Gonzalo Pesado
4
1.3.1.2
Casos de Pruebas
Se realiza el documento de casos de prueba para testear.
Gonzalo Pesado
6
1.3.1.3
Actualización de Documentación
Se relizan modificaciónes a los documentos del proyecto según corresponda añadiendo los detalles que sean especificados por el equipo o por el cliente.
Gonzalo Pesado
6
1.4
GUI Doctor
Todas las interfaces gráficas relacionadas con los doctores del hospital.
Matias D´urbano
22
1.4.1
UI Doctor
Pantalla del médico
Matias D´urbano
22
1.4.1.1
Administración historia clínica
Pantalla que muestra las historia clinica y da la opción de agregar nuevos datos.
Matias D´urbano
6
1.4.1.2
Visualización Historia clínica
Pantalla que muestra unicamente la historia Clínica.
Matias D´urbano
6
1.4.1.3
Administración horario Laboral
Pantalla para administrar el horario Laboral del medico y que permita cancelar horarios.
Matias D´urbano
6
1.4.1.4
Form Logueo
Formulario para que el médico se loguee al sistema. Con su matricula y su contraseña correspondiente.
Matias D´urbano
4
1.4.2
GUIS Personal
Pantallas del personal del hospital.
Luciano Cordoba
55
1.4.2.1
UI Personal de Recepción
Pantalla del personal de recepción.
Luciano Cordoba
18
1.4.2.1.1
Gestión de Turnos
Pantalla para ingresar, cancelar y cambiar turnos.
Luciano Cordoba
6
1.4.2.1.2
Gestión de Obras Sociales
Pantalla para ingresar, modificar y eliminar obras sociales.
Luciano Cordoba
1.4.2.1.3
Administración de Sesiones
Pantalla para administrar las sesiones correspondientes que debe realizarse cada paciente de acuerdo a las prácticas del hospital.
Luciano Cordoba
6 6
1.4.2.2
UI Personal de Internación
Pantallas para el personal de Internación
Luciano Cordoba
8
1.4.2.2.1
Administración de Pacientes
Pantalla para regístrar ingresos y egresos de pacientes.
Luciano Cordoba
4
1.4.2.2.2
Control de habitaciones
Pantalla para gestionar los cambios en las habitaciones del hospital.
Luciano Cordoba
1.4.2.3
UI Personal de Deposito
Pantallas para el personal de Depositos.
Maximiliano Pompilio
4 16
33
1.4.2.3.1
Control de Stock
Pantallas para registrar ingreso, egreso de stock.
Maximiliano Pompilio
4
1.4.2.3.2
Administración de Proveedores
Pantallas para registrar alta, modificar y borrar proveedores.
Maximiliano Pompilio
1.4.2.3.3
Compra de Articulo
Pantalla para registrar la compra de articulos.
Maximiliano Pompilio
1.4.2.4
Form Logueo
Formulario para que el personal del hospital se loguee al sistema. Con un nombre de Usuario del personal y una contraseña.
Matias D´urbano
Pantallas para realizar las tareas del personal administrativo.
Matias D´urbano
10
4 8
3
1.4.2.5
UI personal Administrativo
1.4.2.5.1
Gestión de nomenclaturas
Pantalla para poder editar la tabla de nomenclaturas.
Matias D´urbano
4
1.4.2.5.2
Control de contabilidad
Pantalla para administrar la contabilidad. (Liquidación, impersión de facturas).
Matias D´urbano
6
1.5
Modulo Super Usuario
Modulo encargado de la creación de un super usuario capaz de visualizar todas las pantallas.
Luciano Cordoba
1.5.1
Permisos de Visualización
Lógica relacionada a los permisos de visualización a los que tendrá acceso el superusuario.
Luciano Cordoba
1.5.1.1
Modulo Doctores
Conexión de pantalla del superusuario con la pantalla de Doctores.
Luciano Cordoba
1.5.1.2
Modulo Personal de Recepción
Conexión de pantalla del superusuario con la pantalla del personal de Recepción.
Luciano Cordoba
1.5.1.3
Modulo Personal de Administración
Conexión de pantalla del superusuario con el personal de Administración.
Luciano Cordoba
1.5.1.4
Modulo Personal de Internación
Conexión de pantalla del superusuario con la pantalla de internación.
Luciano Cordoba
1.5.1.5
Modulo Personal de Deposito
Conexión de pantalla del superusuario con la pantalla del personal de Deposito.
Luciano Cordoba
1.5.1.6
Modulo Personal Administrativo
Conexión de pantalla del superusuario con la pantalla del personal administrativo.
Luciano Cordoba
1.5.2
Gestion de Personal
Logica que implica Darle permisos de edición de personal al superusuario.
Luciano Cordoba
1.5.2.1
Agregar
Otorgamiento de permisos para agregar personal.
Luciano Cordoba
4
1.5.2.2
Borrar
Otorgamiento de permisos para borrar personal.
Luciano Cordoba
4
1.5.2.3
Modificar
Otorgamiento de permisos para modificar personal.
Luciano Cordoba
4
1.6
Modulo Personal de Recepción
Tareas que involucran el desarrollo de las funcionalidades que debe desempeñar el personal de Recepción.
Luciano Cordoba
Desarrollo de la parte lógica necesaria para gestionar turnos.
Luciano Cordoba
1.6.1
Gestión de Turnos
30 18 3 3 3 3 3 3 12
22 14
34
1.6.1.1
Asignar Turno
Desarrollo de lógica para poder asginar un nuevo turno.
Luciano Cordoba
8
1.6.1.2
Cancelar Turno
Desarrollo de lógica para poder cancelar un turno.
Luciano Cordoba
6
1.6.2
Gestión de Obras Sociales
Desarrollo de la parte lógica necesaria para gestionar las obras sociales en el sistema.
Luciano Cordoba
1.6.2.1
Agregar Obra social
Desarrollo de la Lógica necesaria para agregar una nueva Obra Social.
Luciano Cordoba
1.6.2.2
Borrar Obra Social
Desarrollo de la Lógica necesaria para eliminar una obra social.
Luciano Cordoba
1.7
Modulo Doctor
Lógica encargada de todas las funcionalidades que nuestro sistema le debe brindar al médico.
Matías D´urbano
42
1.7.1
Visualizacion
Módulo que incluye los elementos que debe poder visualizar un Médico en nuestro sistema.
Matías D´urbano
12
1.7.1.1
Historia clinica
Desrrollo de la lógica de visualización de historias clínicas
Matías D´urbano
6
1.7.1.2
Pacientes
Visualización de el listado de pacientes
Matías D´urbano
6
1.7.2
Administracion historias clinicas
Funcionalidad orientada a la gestión de las historias clínicas dentro del sistema.
Matías D´urbano
14
1.7.2.1
Ingresar historia clinica
Lógica relacionada con el ingreso de nuevos datos a una historia clínica.
Matías D´urbano
8
1.7.2.2
Form historia clinica
Creación de una nueva historia clínica.
Matías D´urbano
6
1.7.3
Gestion horario laboral
Funcionalidad encargada del manejo de los horarios del médico.
Matías D´urbano
16
1.7.3.1
Cancelar Horarios
Lógica de cancelación de horarios.
Matías D´urbano
10
1.7.3.2
Agregar horario
Lógica de agregar un nuevo horario.
Matías D´urbano
6
1.8
Modulo personal de internacion
Logica del personal encargado de internaciones y control de habitaciones.
Luciano Cordoba
26
1.8.1
Administracion de paciente
Control de ingreso y egreso de pacientes.
Luciano Cordoba
20
1.8.1.1
Agregar paciente
Ingreso de paciente a internacion.
Luciano Cordoba
6
1.8.1.2
Form ingreso de paciente
Formulario para ingreso de pacientes.
Luciano Cordoba
4
1.8.1.3
Egreso de paciente
Egreso de pacientes de internacion.
Luciano Cordoba
6
1.8.1.4
Imprimir
Imprime registro de paciente
Luciano Cordoba
4
1.8.2
Visualizacion
Lógica que implica los datos a visualizar por el personal de internación.
Luciano Cordoba
6
1.8.2.1
Visualizacion pacientes en espera
Visualizacion de pacientes que esperan ser internados.
Luciano Cordoba
6
1.9
Modulo personal de deposito
Logica del personal de deposito.
Maximiliano Pompilio
34
1.9.1
Ingreso articulo
Ingreso de articulos al sistema.
Maximiliano Pompilio
6
8 4 4
35
1.9.2
Egreso de articulo
Egreso de articulos del sistema.
Maximiliano Pompilio
8
1.9.3
Compra de articulo
Comprar articulos necesarios a proveedores.
Maximiliano Pompilio
8
1.9.3.1
Form compra
Formulario de compra.
Maximiliano Pompilio
4
1.9.4
Administracion de proveedor
Control de ingreso de proveedores a los que comprar articulos
Maximiliano Pompilio
12
1.9.4.1
Agregar proveedor
Registrar proveedor al cual comprar articulo
Maximiliano Pompilio
6
1.9.4.2
Formulario proveedor
Formulario de regristro de proveedores
Maximiliano Pompilio
6
1.10
Modulo personal adminitrativo
Logica que se encarga de facturaciones y liquiaciones y de agregar nomenclaturas
Maximiliano Pompilio
54
1.10.1
Administrar nomenclaturas
Administracion tecnicas utilizada para tratamiento de enfermedades.
Maximiliano Pompilio
10
1.10.1.1
Agregar nomenclatura
Agregar al sistema tecnica/nomenclatura.
Maximiliano Pompilio
6
1.10.1.2
Form agregar
Formulario para agregar nomenclatura.
Maximiliano Pompilio
4
1.10.2
Modulo contabilidad
Logica que se encarga de facturaciones y liquiaciones.
Maximiliano Pompilio
26
1.10.2.1
Facturacion Facturaciones mensuales y ocacionales.
Maximiliano Pompilio
16
Maximiliano Pompilio
8
Maximiliano Pompilio
8
Maximiliano Pompilio
10
1.10.2.1.1
Facturacion ocacional
Facturacion realizada a pacientes particulares que su obra social no lo cubre.
1.10.2.1.2
Facturacion mensual
Facturacion realizada a obras sociales para cobrar los montos respectivos a las prestaciones otorgadas a sus afiliados.
1.10.2.2 1.10.2.3
Liquidacion
Liquidacion realizada mensualmente a partir de la cantidad de pacientes atendidos y las prácticas realizadas.
Importes de practicas
Costo de practicas.
Maximiliano Pompilio
8
1.11
Control de stock
Control que permite tener certeza de la disponibilidad de articulos en el sistema
Maximiliano Pompilio
16
1.11.1
Control insumos
Insumos que presenta el hospital
Maximiliano Pompilio
16
1.11.1.1
Ingreso
Ingreso que se hace al verificar que los insumos llegaron al deposito
Maximiliano Pompilio
8
1.11.1.2
Egreso
Egreso de insumos utilizados en distintas situaciones del hospital
Maximiliano Pompilio
8
1.12
Control de pacientes
Control de los pacientes que se encuentra en el hospital
Matías D´urbano
43
36
1.12.1
Asignacion de turnos
Asignar turno a paciente con un doctor
Matías D´urbano
8
1.12.2
Visualizacion
Visualizaciones
Matías D´urbano
14
1.12.2.1
Doctores
Visualizacion de doctores trabajando en el hospital
Matías D´urbano
6
1.12.2.2
Horarios
Visualizacion de horarios de trabajo donde los doctores no atienden a algun paciente
Matías D´urbano
8
1.12.3
Listado de pacientes
Listado de pacientes correspondiente a un doctor en particular
Matías D´urbano
6
1.12.3.1
Imprimir
Posibilidad de imprimir listado de pacientes o turnos.
Matías D´urbano
6
1.12.4
Administracion de sesiones
Control de un calendario de sesiones de pacientes
Matías D´urbano
15
1.12.4.1
Agregar sesiones pendientes
Agregar cantidad de sesiones a realizar a un paciente
Matías D´urbano
7
1.12.4.2
Confirmar ingreso a sesion pendiente
Confirmarcion de ingreso a sesion a un paciente
Matías D´urbano
5
1.12.4.3
Form
Formulario para agregar sesion a un paciente
Matías D´urbano
3
1.13
Gestionador de personal
Agregar borrar o modificar personal que trabajaran con el sistema.
Luciano Cordoba
1.13.1
Agregar
Agregar persona que usara el sistema
Luciano Cordoba
4
1.13.2
Borrar
borrar persona que usara el sistema
Luciano Cordoba
4
1.13.3
Modificar
Modificar el personal que usara el sistema
Luciano Cordoba
4
1.13.4
Formulario Agregar
Formulario para agregar personal
Luciano Cordoba
4
1.14
Control de habitaciones
Control que permite tener certeza de la disponibilidad de camas en el hospital
Luciano Cordoba
28
1.14.1
Gestionador de habitaciones
Agregar borrar o modificar las habitaciones que conforman el hospital
Luciano Cordoba
18
1.14.1.1
Agregar
Agregar habitacion que se usara en el hospital
Luciano Cordoba
4
1.14.1.2
Borrar
Borrar habitacion que se usara en el hospital
Luciano Cordoba
4
1.14.1.3
Modificar
Modificar habitacion que se usara en el hospital
Luciano Cordoba
6
1.14.1.4
Formulario
Formulario para agregar las habitaciones
Luciano Cordoba
4
1.14.2
Asignacion
Desarrollo de la logica para poder asignar camas a los pacientes dentro del sistema
Maximiliano Pompilio
10
1.14.2.1
Paciente
Asignar a un paciente del sistema una cama disponible
Maximiliano Pompilio
6
1.14.2.2
Disponibilidad
Comprobar la disponibilidad de las camas para asignarcelas a un paciente
Maximiliano Pompilio
4
1.15
Control de avisos
Control de los avisos internos y externos del sistema
Maximiliano Pompilio
16
1.15.1
Emitir aviso
Generacion de pantallas de cuadro de texto dentro del sistema
Maximiliano Pompilio
8
16
37
1.15.2
Envio de mail
Aviso relacionado a la cancelacion de un turno
Maximiliano Pompilio
8
1.16
Control de monitoreo
Control de monitoreo del sistema de Refrigeración
Matías D´urbano
10
1.16.1
Monitoreo de camara de refrigeracion
Conexión con el sistema de monitoreo de la camara de regrigeración.
Matias D´urbano
10
1.17
Base de datos
Base de datos del sistema
Matias D´urbano
56
1.17.1
Tablas
Tablas del sistema
Matias D´urbano
40
1.17.1.1
Tabla personal de recepcion
Tabla que contiene al personal de recepcion del sistema
Matias D´urbano
4
1.17.1.2
Tabla personal de internacion
Tabla que contiene al personal de internacion del sistema
Matias D´urbano
4
1.17.1.3
Tabla doctores
Tabla que contiene a los doctores del sistema
Matias D´urbano
4
1.17.1.4
Tabla paciente
Tabla que contiene a los pacientes del sistema
Maximiliano Pompilio
4
1.17.1.5
Tabla turnos
Tabla que contiene los turnos del sistema
Maximiliano Pompilio
4
1.17.1.6
Tabla proveedores
Tabla que contiene a los proveedores del sistema
Maximiliano Pompilio
4
1.17.1.7
Personal de deposito
Tabla que contiene al personal de depositos del sistema
Luciano Cordoba
4
1.17.1.8
Habitaciones
Tabla que contiene las habitaciones dentro del sistema
Luciano Cordoba
4
1.17.1.9
Sesiones
Tabla que contiene a las seciones del sistema
Luciano Cordoba
4
1.17.1.10
Personal de administracion
Tabla que contiene al personal de administracion
Luciano Cordoba
4
1.17.2
Back-Up
Copia de seguridad de la base de datos del sistema
Maximiliano Pompilio
16
1.17.2.1
Exportar
Almacenamiento de la base de datos del sistema en un archivo .sql
Maximiliano Pompilio
8
1.17.2.2
Importar
Creacion de la base de datos del sistema mediante un archivo .sql
Maximiliano Pompilio
8
1.18
Administracion y control del proyecto
El equipo de trabajo se reune a debatir como se esta llevando acabo el proyecto y que correcciones realizar
Lautaro Tacchini
18
1.18.1
Reunion de avances
El equipo de trabajo se reune para realizar una revision del avance del proyecto.
Lautaro Tacchini
3
1.18.2
Informe de avances
Se redacta un informe de avances de acuerdo a lo charlado en la reunión formal.
Lautaro Tacchini
3
1.18.3
Preparacion de reuniones
Planificación de las reuniones entre los integrandes del equipo de trabajo.
Lautaro Tacchini
4
1.18.4
Control de cambios
Elaboración del documento de control de cambios.
Lautaro Tacchini
8
1.19
Capacitacion
Tiempo consumido en el aprendizage de nuevas hermanientas o con poco conocimiento
Lautaro Tacchini
7
1.19.1
Maven
Herramienta utilizada en la gestion y construccion de software
Lautaro Tacchini
3
38
1.19.2
Sistema de monitoreo de camara de refrisgeracion
Sistema dedicado constantemete a controlar el estado de la camara de refrisgeracion
Lautaro Tacchini
4
1.20
Dieseño general del sistema
Se lleva acabo los diagramas correspondientes del sistema
Lautaro Tacchini Matías D´urbano
8
1.21
Manual
Documento en el cual se explica como utilizar correctamente el sistema
Matías D´urbano
7
1.22
Estabilizacion
Etapa dedicada a la correccion de bugs del sistema
Gonzalo Pesado
10
1.22.1
Liberacion
Etapa en la cual se presentara el proyecto completo al cliente
Gonzalo Pesado
10
39
Plan de Versiones
Plan de Versiones
RF2
RF3
RF4
RF5
Requerimientos
Sección Gestión Turnos
RFE15 - RFE17 - RFE18 RFE21 - RFI22
Sección Historias Clínicas
RFE1 - RFE2
Sección Médico
RFE3 - RFE19 - RFD20
Sección Pacientes
RFE28
Sección Stock
RFI7 - RFI8
Sección Prácticas
RFI27
Sección Personal Internaciónes
RFE23 - RFI24 - RFE25 RFI26
Sección Personal de Depositos
RFE4 - RFI5 - RFI6
Sección Proveedores
RFI9
Sección Orden de Compra
RFI5
Liquidaciones de Sueldo
RFE14
Sección Sistema de Refrigeración
RFD10
Log in
RFI29 - RFI30 - RFI31
Sección Listado de Pacientes
RFE19
Backup
RFD32
RFD16
Sección Alertas
RFD8 - RFD11
Reportes
RFE12 - RFE13 - RFI26 Sección Cambios
40
Trazabilidad Id Req. Tipo Req.
1
2
3
4
RFE
RFE
RFE
RFE
Esfuerzo Esfuerzo WBS Req.
Requerimientos
Id WBS
Nombre padre - hijo WBS
Los pacientes deben tener una historia clínica registrada en el sistema.
1.7.2
Modulo Doctor - Administración de Historias Clínicas
6
1.7.1.2
Modulo Doctor - Pacientes
3
1.4.1.1
UI Doctor - Administración de historias clínicas
6
1.4.1.2
UI Doctor - Visualización de historias clínicas y pacientes
6
1.7.1.1
Visualización - Historia Clínica
6
1.17.1.3
Tablas - Tabla Doctores
4
1.4.2.4
GUIS Personal - Form Logueo
3
1.7.2.1
Adminitración de Historias Clínicas Ingresar historia clínica
8
1.17.1.3
Tablas - Tabla Doctores
4
1.7.2.2
Adminitración de Historias Clínicas Form Historia Clínica
6
1.4.2.3.1
UI Personal Deposito - Control de Stock
4
1.17.1.7
Tablas - Personal de Deposito
4
1.11.1
Control de Stock - Control Insumos
16
1.4.2.3.3
UI personal Deposito - Compra de Articulo
8
1.9.3
Modulo Personal de Deposito Compra de Articulo
8
1.17.1.7
Tablas - Personal de Deposito
4
1.17.1.7
Tablas - Personal de Deposito
4
1.4.2.3.1
UI Personal Deposito - Control de Stock
4
Los médicos deben poder consultar las historias clínicas de sus pacientes en todo momento.
Los médicos deben poder ingresar nuevos datos en la historia clínica de sus pacientes.
El personal de depositós debe poder visualizar los insumos que se presentan en el hospital.
RFI
El personal de depósito deberá poder realizar ordenes de compra.
6
RFI
El personal de depósito debe poder visualizar el stock del hospital el cual es administrado por el sistema.
7
RFI
El personal de depósito debe tener la capacidad de registrar el ingreso de stock.
1.4.2.3.1
UI Personal Deposito - Control de Stock
4
1.11.1.1
Control de Insumos - Ingreso
8
El egreso de stock se debe registrar automáticamente cuando se realiza una internación en la cual se utilizan medicamentos.
1.4.2.3.1
UI Personal Deposito - Control de Stock
4
1.11.1.2
Control de Insumos - Egreso
8
1.4.2.3.2
UI Personal Deposito Administración de Proveedor
4
1.9.4
Modulo Personal de Deposito Administración de Proveedor
12
1.17.1.6
Tablas - Tabla Proveedores
4
1.17.1.7
Tablas - Personal de Deposito
4
5
8
9
RFI
RFI
El personal de depósito debe tener la capacidad de agregar, quitar o modificar la lista de proveedores.
9
25
18
24
20
8
12
12
24
41
10
RFD
El sistema debe monitorear el sistema de refrigeración.
1.16.1
11
RFD
Se deben poder emitir alertas desde el sistema.
12
13
14
15
16
17
18
19
20
21
RFE
RFE
RFE
El personal de recepción debe poder emitir facturaciones ocasionales.
El personal de administración debe tener la capacidad de emitir facturaciones mensuales.
Los médicos deben tener su liquidación mensual generada automáticamente por el sistema.
RFE
El personal de recepción podrá realizar el proceso de otorgamiento de turnos.
RFD
El sistema debe tener la capacidad de realizar notificaciones vía mail.
RFE
El personal de recepción debe tener la capacidad de cancelar un turno a través del sistema.
RFE
RFE
RFD
RFE
El personal de recepción debe poder cancelar los rangos horarios de un determinado médico.
Se debe generar un listado de pacientes que se encuentren en una lista de espera correspondiente a cada doctor y que se hayan anunciado ante el personal de recepción.
Los médicos deben poder visualizar los pacientes que tienen un turno para ese día.
El personal de recepción debe poder ingresar las autorizaciones de las obras sociales en el sistema.
Control de monitoreo - Monitoreo de camaras de refrigeracion
10
10
1.15.1
Control de Avisos - Emitir Aviso
8
8
1.4.2.1.1
UI Personal de Recepción - Gestión de Turnos
6
1.4.2.4
GUIS Personal - Form Logueo
3
1.6.1.1
Gestión de Turnos - Asignar turno
8
1.10.2.1.1
Facturación - Facturación ocacional
8
1.4.2.5.2
UI Personal Administrativo - Gestión de Contabilidad
6
1.10.2.1.2
Facturación - Facturación Mensual
8
1.4.2.5.2
UI Personal Administrativo - Control de Contabilidad
6
1.10.2.2
Control de Contabilidad Liquidación
10
1.4.2.1.1
UI Personal de Recepción - Gestión de Turnos
6
1.6.1.1
Gestión de Turnos - Asignar turno
8
1.17.1.5
Tablas - Tabla Turnos
4
1.15.2
Control de Avisos - Envio de mail
8
1.4.2.1.1
UI Personal de Recepción - Gestión de Turnos
6
1.6.1.2
Gestión de Turnos - Cancelar Turno
6
1.17.1.5
Tablas - Tabla Turnos
4
1.4.2.1.1
UI Personal de Recepción - Gestión de Turnos
6
1.6.1.2
Gestión de Turnos - Cancelar Turno
6
1.17.1.5
Tablas - Tabla Turnos
4
1.4.1.2
UI Doctor- Visualización de historia clínica y Pacientes
6
1.7.1.2
Visualización - Pacientes
6
1.4.1.2
UI Doctor - Visualización de historias clínicas y pacientes.
6
1.4.2.1.1
UI Personal de Recepción - Gestión de Turnos
6
1.6.1.1
Gestión de Turnos - Asignar turno
8
1.7.1.2
Visualización - Pacientes
6
1.12.3
Control de Pacientes - Listado de Pacientes
6
1.4.2.1.2
UI Personal de Recepción - Gestión de obras sociales
6
25
14
16
18
4
16
16
12
32
14
42
21
22
23
24
RFE
RFI
RFE
RFI
El personal de recepción debe poder ingresar las autorizaciones de las obras sociales en el sistema. Se deberá administrar las sesiones pendientes de cada paciente con sus correspondientes autorizaciones.
El personal de internación debe poder ingresar al sistema los pacientes que deban ser internados en el hospital.
El personal de internación deberá poder realizar operaciones de gestión de habitaciones.
14
1.6.2
Módulo Personal de Recepción Gestión de obras sociales
8
1.12.4
Control de pacientes Administrador de sesiones
15
1.4.2.2.1
UI personal de Internación Administración de pacientes
4
1.8.1.1
Administración de Pacientes Agregar Paciente
6
1.8.1.2
Form Ingreso de Paciente
4
1.17.1.4
Tablas - Tabla Paciente
4
1.4.2.2.2
Ui personal de Internación - Control de Habitaciones
4
1.14.1
Control de habitaciones Gestionador de habitaciones
16
1.14.2
Control de habitaciones Asignacion
8
15
18
28
25
RFE
Se debe llevar un registro de todas las internaciones activas en el hospital.
1.17.1.4
Tablas - Tabla Paciente
4
2
26
RFI
El personal de internación podrá imprimir el detalle de la internación de un paciente.
1.8.1.4
Modulo personal de internación Imprimir
4
4
1.4.2.5.1
UI Personal administrativo - Gestion de nomenclaturas
4
RFI
El personal de administración deberá tener la capacidad de actualizar mensualmente, los importes de las prácticas médicas que se les lleva a cabo a los pacientes.
1.10.2.3
Control de Contabilidad - Importes Prácticas
8
1.8.1.1
Modulo personal de internacion Administracion de paciente Agregar paciente
6
1.8.1.2
Modulo personal de internacion Administracion de paciente - Form ingreso de paciente
4
1.8.1.3
Modulo personal de internacion Administracion de paciente - Egreso de paciente
6
1.12.1
Control de pacientes - Asignacion de turnos
8
1.17.1.4
Base de datos - Tablas - Tabla paciente
4
1.4.2.2.1
UI Personal de internacion Administracion de pacientes
4
1.5
Modulo SuperUsuario
30
1.4.1.4
GUI Doctor - Form Logueo
4
1.4.2.4
GUIS Personal - Form Logueo
3
1.13.1
Gestionador de personal - Agregar
4
1.13.2
Gestionador de personal - Modificar
4
27
28
RFE
Se deben poder registrar a los pacientes en el sistema.
29
RFI
El Súper Usuario debe tener acceso a todos los datos del sistema.
30
RFI
Se debe contar con un sistema de Login para identificar a cada usuario.
RFI
El administrador del sistema deberá tener la capacidad de crear cuentas para los distintos usuarios del sistema.
31
12
32
MIRAR COMENTARIO QUE DEJE ANTES DE IMPRIMIR
30 7
16
43
31
32
RFI
RFD
El administrador del sistema deberá tener la capacidad de crear cuentas para los distintos usuarios del sistema. Los administradores deben poder realizar en cualquier momento un backup de la base de datos.
1.13.3
Gestionador de personal - Borrar
4
1.13.4
Gestionador de personal Formulario agregar
4
1.17.2
Bases de Datos - Backup
16
16
16
44
Calendario Semanal Calendario Semanal Responsable
Luciano Cordoba
Horas por semana
RF2
Horas por semana
Gonzalo Pesado
Horas por semana
HS
Semana 1
HS
Semana 2
1.6.1.1 Asignar un turno
8
1.4.1.1 Administración Historia Clínica
1.6.1.2 Cancelar un turno
6
1.4.1.2 Visualización Historia Clínica
1.6.2.1 Agregar Obra Social
4
1.4.1.3 Administración Horario Laboral
1.6.2.2 Borrar Obra Social
4 1.7.2.1 Ingresar una historia clínica 8
22 1.2.2 Demo
Matías D´urbano
RF3
1.12.1 Asignación de turnos 8 1.12.2.1 Doctores
6
1.17.1.3 Tabla Doctores
4
26
1.12.2.2 Horarios
HS
6 1.4.2.2.1 Administración de Pacientes 4
1.4.2.2.2 Control de Habitaciones
4
6
1.8.2.1 Visualización de pacientes en espera
6
1.14.1.3 Modificar Habitación
6
6
1.8.1.1 Agregar Paciente
6
16
10
8 1.17.1.1 Tabla Personal de Recepción 4
1.4.2.2.2 Control de Contabilidad
6
1.17.1.7 Personal de Desposito
4
1.7.3.1 Cancelar Horarios
10
1.17.1.2 Tabla Personal de Internación
4
1.7.3.2 Agregar Horarios
6
1.4.2.5.1 Gestión de Nomenclaturas
4
1.14.1.1 Agregar Habitación
4
1.14.1.2 Borrar Habitación
4
20
24
1.1.7 Riesgos
4
1.1.8 Funcionalidades
6
1.1.9 Cambios
4
1.12.4.1 Administración de Sesiones Pendientes
7
1.1.9 Cambios
1.3.1.1 Evolucion de la prueba
4
1.12.4.3 Formulario de ingreso a sesión pendiente
3
1.3.1.1 Evolucion de la prueba
1.3.1.3 Actualizacion de documentacion
3
1.7.1.2 Pacientes
6
21
HS
Semana 2
26
8
Semana 1
1.3.1.2 Casos de prueba
22
6
10
1.1.7 Riesgos
4
1.3.1.2 Casos de prueba
6
1.1.8 Funcionalidades
6
1.3.1.3 Actualizacion de documentacion
6
18
4 1.14.2.2 Disponibilidad (Control Hab)
4
4
16
45
Maximiliano Pompilio
1.17.1.4 Tabla pacientes (BD)
4
1.10.2.1.1 Facturacion ocacional
8
1.4.2.3.1 Control de stock (GUI)
4
1.11.1.1 Ingreso (Stock)
8
1.17.1.5 Tabla turnos (BD)
4
1.10.2.1.2 Facturacion mensual
8
1.9.1 Ingreso (Personal Deposito)
6
1.11.1.2 Egreso (Stock)
8
1.10.1.1 Agregar nomenclatura
6
1.10.2.3 Importes de practicas
8
1.9.2 Egreso (Personal Deposito)
8
1.10.1.2 Form Agregar (Nomenclatura)
4
1.7.2.2 From Historia Clínica 6 Horas por semana
Lautaro Tacchini
24
16
1.19.1 Capacitación Maven
3
1.18.3 Preparacion de reuniones
4
1.2.3 Reunión con Gestión de Proyectos
2
1.18.4 Control de cambios
8
1.20 Diseño General del Sistema
10
1.18.4 Control de cambios
8
1.18.2 Informe de avances
3
1.18.3 Preparacion de reuniones
4
1.18.1 Reunion de avances
3
1.19.2 Capacitación Sistema de monitoreo de Capas de refrigeración
4
1.2.1.1 Minuta
3
1.14.2.1 Paciente (Control Hab)
6
1.18.2 Informe de avances
3 1.7.2.1 Ingresar una historia clínica 8
1.2.1.3 Actualización de Documentación
5
1.14.1.4 Formulario Habitación
4
1.8.1.2 Form Ingreso Paciente
4
1.12.4.2 Confirmar ingreso a 5 sesión pendiente Horas por semana
18
24
24
21
24
18
Calendario Semanal Responsable
RF4
RF5
46
Responsable
Luciano Cordoba
Horas por semana
Matías D´urbano
Horas por semana
Gonzalo Pesado
Horas por semana
Maximiliano Pompilio
Semana 1
HS
Semana 2
HS
Semana 1
HS
Semana 2
HS
1.13.1 Agregar Personal
4
1.5.1.1 SuperUsuario Modulo Doctores
3
1.17.2.1 Exportar (Back up)
8
1.22.1 Liberación
10
1.13.2 Borrar Personal
4
1.5.1.2 SuperUsuario Modulo Personal de Recepción
3
1.17.2.2 Importar (Back up)
8
1.13.3 Modificar Personal
4
1.5.1.3 SuperUsuario Modulo Personal de Administración
3
1.13.4 Formulario Agregar Personal
4
1.5.1.4 SuperUsuario Modulo Personal de Internación
3
16
12
Tiempo Dedicado a Cambios Finales 10
20
16
1.4.1.4 Form Logueo
4
1.5.1.5 SuperUsuario Modulo Personal de Deposito
3
1.12.3.1 Listado de Pacientes Imprimir
6
1..4.2.4 Form Logueo
3
1.5.1.6 SuperUsuario MOdulo Personal Administrativo
3
1.21 Manual
7
1.10.2.2 Liquidacion (Mensual a medicos)
10
17
1.16.1 Monitoreo de la camara de 10 Refrigeración
16
1.22.1 Liberación
10
Tiempo Dedicado a Cambios Finales 10
13
20
1.1.7 Riesgos
4
1.3.1.2 Casos de prueba
6
1.1.7 Riesgos
4
1.3.1.2 Casos de prueba
6
1.1.8 Funcionalidades
6
1.3.1.3 Actualizacion de documentacion
6
1.1.8 Funcionalidades
6
1.3.1.3 Actualizacion de documentacion
6
1.1.9 Cambios
4
1.1.9 Cambios
4
1.3.1.1 Evolucion de la prueba
4
1.3.1.1 Evolucion de la prueba
4
1.3.1.1 Evolucion de la prueba
4
1.22.1 Libreación
10
18
18
12
1.4.2.3.2 Administracion de proveedores (GUI)
4
1.17.1.6 Tabla proveedores (BD)
4
1.4.2.3.3 Compra de articulo (GUI) 8 1.9.3.1 Form compra (Personal Deposito)
4
26
1.15.2 Envio de mail (avisos)
8
1.15.1 Emitir aviso
8
1.22.1 Liberación
10
Tiempo Dedicado a Cambios Finales 10
47
Maximiliano Pompilio
Horas por semana
Lautaro Tacchini
Horas por semana
1.9.4.1 Agregar proveedor (Personal Deposito)
6
1.9.4.2 Form proveedor (Personal Deposito)
6
20
Tiempo Dedicado a Cambios Finales 10
12
16
20
1.2.3 Reunión con Gestión de Proyectos
2
1.5.2.1 SuperUsuario Agregar Usuarios
4
1.2.3 Reunión con Gestión de Proyectos
2
1.18.4 Control de cambios
8
1.18.2 Informe de avances
3
1.5.2.2 SuperUsuario Borrar Usuarios
4
1.18.2 Informe de avances
3
1.22.1 Libreación
10
1.2.1.1 Minuta
3
1.5.2.3 SuperUsuario Modificar Usuarios
4
1.2.1.1 Minuta
3
1.2.1.3 Actualización de Documentación
5
1.18.4 Control de cambios
8
1.2.1.3 Actualización de Documentación
5
1.18.3 Preparacion de reuniones
4
1.18.3 Preparacion de reuniones
4
17
20
17
18
48
Calendario
Calendario Fecha
RF
ID Req
Requerimientos
Peso
RFE
1
Los pacientes deben tener una historia clínica registrada en el sistema.
2
RFE
2
Los médicos deben poder consultar las historias clínicas de sus pacientes en todo momento.
5
RFE
3
Los médicos deben poder ingresar nuevos datos en la historia clínica de sus pacientes.
4
RFE
15
El personal de recepción podrá realizar el proceso de otorgamiento de turnos.
4
RFE
17
El personal de recepción debe tener la capacidad de cancelar un turno a través del sistema.
4
RFD
20
Los médicos deben poder visualizar los pacientes que tienen un turno para ese día.
5
RFE
21
El personal de recepción debe poder ingresar las autorizaciones de las obras sociales en el sistema.
3
RFI
22
Se deberá administrar las sesiones pendientes de cada paciente con sus correspondientes autorizaciones.
3
RFI
27
El personal de administración deberá tener la capacidad de Importar los importes de las prácticas médicas que se les lleva a cabo a los pacientes.
3
RFE
28
Se deben poder registrar a los pacientes en el sistema
5
RFD
16
El sistema debe enviar un recordatorio vía mail a cada paciente un día antes del turno registrado en el sistema. En caso que se haya cancelado un turno por parte de un médico, se debe enviar un mail al paciente informando la cancelación de su turno y la asignación de su nuevo turno.
4
RFE
18
El personal de recepción debe poder cancelar los rangos horarios de un determinado médico.
4
RFD
19
Se debe generar un listado de pacientes que se encuentren en una lista de espera correspondiente a cada doctor y que se hayan anunciado ante el personal de recepción.
3
RFE
23
El personal de internación debe poder ingresar al sistema los pacientes que deban ser internados en el hospital.
4
RFI
24
El personal de internación deberá poder realizar operaciones de gestión de habitaciones.
3
RFE
25
Se debe llevar un registro de todas las internaciones activas en el hospital.
1
RFI
27
El personal de administración deberá tener la capacidad de actualizar mensualmente, los importes de las prácticas médicas que se les lleva a cabo a los pacientes.
3
RFI
31
El administrador del sistema deberá tener la capacidad de crear cuentas para los distintos usuarios del sistema.
4
RFD
10
El sistema debe monitorear el sistema de refrigeración
2
RFD
11
Se deben poder emitir alertas desde el sistema.
1
8/5
22/5
Peso de Hito
38
26
49
5/6
23/6
El personal de recepción debe poder emitir facturaciones ocasionales.
RFE
12
RFE
14
Los médicos deben tener su liquidación mensual generada automáticamente por el sistema.
4
RFI
26
El personal de internación podrá imprimir el detalle de la internación de un paciente.
1
RFI
29
El Súper Usuario debe tener acceso a todos los datos del sistema.
5
RFI
30
Se debe contar con un sistema de Login para identificar a cada usuario.
1
RFD
32
Los administradores deben poder realizar en cualquier momento un backup de la base de datos.
4
RFE
4
El personal de depósitos debe poder visualizar los insumos que se presentan en el hospital.
5
RFI
5
El personal de depósito deberá poder realizar ordenes de compra.
5
RFI
6
El personal de depósito debe poder visualizar el stock del hospital el cual es administrado por el sistema.
2
RFI
7
El personal de depósito debe tener la capacidad de registrar el ingreso de stock.
3
RFI
8
El egreso de stock se debe registrar automáticamente cuando se realiza una internación en la cual se utilizan medicamentos.
3
RFI
9
El personal de depósito debe tener la capacidad de agregar, quitar o modificar la lista de proveedores.
5
RFD
16
En caso de que se cree una solicitud de compra, la misma debe ser enviada vía mail al email personal del proveedor.
4
Total
5
23
27
114
50
Funcionalidad Completa Id Req.
Tipo Req.
1
RFE
2
3
4
5
RFE
RFE
RFE
RFI
6
RFI
7
RFI
8
9
RFI
RFI
Requerimientos Los pacientes deben tener una historia clínica registrada en el sistema.
Los médicos deben poder consultar las historias clínicas de sus pacientes en todo momento.
Los médicos deben poder ingresar nuevos datos en la historia clínica de sus pacientes.
El personal de depositós debe poder visualizar los insumos que se presentan en el hospital. El personal de depósito deberá poder realizar ordenes de compra. El personal de depósito debe poder visualizar el stock del hospital el cual es administrado por el sistema. El personal de depósito debe tener la capacidad de registrar el ingreso de stock. El egreso de stock se debe registrar automáticamente cuando se realiza una internación en la cual se utilizan medicamentos.
El personal de depósito debe tener la capacidad de agregar, quitar o modificar la lista de proveedores.
Esfuerzo Esfuerzo Peso WBS Req.
Id WBS
Nombre padre - hijo WBS
1.7.2
Modulo Doctor - Administración de Historias Clínicas
6
1.7.1.2
Modulo Doctor - Pacientes
3
1.4.1.1
UI Doctor - Administración de historias clínicas
6
1.4.1.2
UI Doctor - Visualización de historias clínicas y pacientes
6
1.7.1.1
Visualización - Historia Clínica
6
1.17.1.3
Tablas - Tabla Doctores
4
1.4.2.4
GUIS Personal - Form Logueo
3
1.7.2.1
Adminitración de Historias Clínicas - Ingresar historia clínica
8
1.17.1.3
Tablas - Tabla Doctores
4
1.7.2.2
Adminitración de Historias Clínicas - Form Historia Clínica
6
1.4.2.3.1
UI Personal Deposito - Control de Stock
4
1.17.1.7
Tablas - Personal de Deposito
4
1.11.1
Control de Stock - Control Insumos
16
1.4.2.3.3
UI personal Deposito - Compra de Articulo
8
1.9.3
Modulo Personal de Deposito - Compra de Articulo
8
1.17.1.7
Tablas - Personal de Deposito
4
1.17.1.7
Tablas - Personal de Deposito
4
1.4.2.3.1
UI Personal Deposito - Control de Stock
4
1.4.2.3.1
UI Personal Deposito - Control de Stock
4
1.11.1.1
Control de Insumos - Ingreso
8
1.4.2.3.1
UI Personal Deposito - Control de Stock
4
1.11.1.2
Control de Insumos - Egreso
8
1.4.2.3.2
UI Personal Deposito - Administración de Proveedor
4
1.9.4
Modulo Personal de Deposito - Administración de Proveedor
12
9
2
25
5
18
4
24
5
20
5
8
2
12
3
12
3
24
5
51
9
RFI
El personal de depósito debe tener la capacidad de agregar, quitar o modificar la lista de proveedores.
1.17.1.6
Tablas - Tabla Proveedores
4
1.17.1.7
Tablas - Personal de Deposito
4
24
5
10
RFD
El sistema debe monitorear el sistema de refrigeración.
1.16.1
Control de monitoreo - Monitoreo de camaras de refrigeracion
10
10
2
11
RFD
Se deben poder emitir alertas desde el sistema.
1.15.1
Control de Avisos - Emitir Aviso
8
8
1
1.4.2.1.1
UI Personal de Recepción - Gestión de Turnos
6
1.4.2.4
GUIS Personal - Form Logueo
3
1.6.1.1
Gestión de Turnos - Asignar turno
8
25
5
1.10.2.1.1
Facturación - Facturación ocacional
8 14
3
16
4
18
4
8
4
16
4
16
4
12
3
32
5
12
RFE
El personal de recepción debe poder emitir facturaciones ocasionales.
13
RFE
El personal de administración debe tener la capacidad de emitir facturaciones mensuales.
1.4.2.5.2
UI Personal Administrativo - Gestión de Contabilidad
6
1.4.2.5.2
Facturación - Facturación Mensual
8
14
RFE
Los médicos deben tener su liquidación mensual generada automáticamente por el sistema.
1.4.2.5.2
UI Personal Administrativo - Control de Contabilidad
6
1.10.2.2
Control de Contabilidad - Liquidación
10
1.4.2.1.1
UI Personal de Recepción - Gestión de Turnos
6
RFE
El personal de recepción podrá realizar el proceso de otorgamiento de turnos.
1.6.1.1
Gestión de Turnos - Asignar turno
8
1.17.1.5
Tablas - Tabla Turnos
4
1.15.2
Control de Avisos - Envio de mail
6
1.4.2.1.1
UI Personal de Recepción - Gestión de Turnos
6
1.6.1.2
Gestión de Turnos - Cancelar Turno
6
1.17.1.5
Tablas - Tabla Turnos
4
1.4.2.1.1
UI Personal de Recepción - Gestión de Turnos
6
1.6.1.2
Gestión de Turnos - Cancelar Turno
6
1.17.1.5
Tablas - Tabla Turnos
4
1.4.1.2
UI Doctor- Visualización de historia clínica y Pacientes
6
1.7.1.2
Visualización - Pacientes
6
15
16
17
18
19
20
RFD
El sistema debe tener la capacidad de realizar notificaciones vía mail.
RFE
El personal de recepción debe tener la capacidad de cancelar un turno a través del sistema.
RFE
El personal de recepción debe poder cancelar los rangos horarios de un determinado médico.
RFE
Se debe generar un listado de pacientes que se encuentren en una lista de espera correspondiente a cada doctor y que se hayan anunciado ante el personal de recepción.
RFD
Los médicos deben poder visualizar los pacientes que tienen un turno para ese día.
1.4.1.2
UI Doctor - Visualización de historias clínicas y pacientes.
6
1.4.2.1.1
UI Personal de Recepción - Gestión de Turnos
6
1.6.1.1
Gestión de Turnos - Asignar turno
8
1.7.1.2
Visualización - Pacientes
6
52
20
RFD
Los médicos deben poder visualizar los pacientes que tienen un turno para ese día. 1.12.3
21
RFE
22
RFI
23
24
RFE
RFI
El personal de recepción debe poder ingresar las autorizaciones de las obras sociales en el sistema. Se deberá administrar las sesiones pendientes de cada paciente con sus correspondientes autorizaciones.
El personal de internación debe poder ingresar al sistema los pacientes que deban ser internados en el hospital.
El personal de internación deberá poder realizar operaciones de gestión de habitaciones.
Control de Pacientes - Listado de Pacientes
6
1.4.2.1.2
UI Personal de Recepción - Gestión de obras sociales
6
1.6.2
Módulo Personal de Recepción - Gestión de obras sociales
8
1.12.4
Control de pacientes - Administrador de sesiones
15
1.4.2.2.1
UI personal de Internación - Administración de pacientes
4
1.8.1.1
Administración de Pacientes - Agregar Paciente
6
1.8.1.2
Form Ingreso de Paciente
4
1.17.1.4
Tablas - Tabla Paciente
4
1.4.2.2.2
Ui personal de Internación - Control de Habitaciones
4
1.14.1
Control de habitaciones - Gestionador de habitaciones
16
1.14.2
Control de habitaciones - Asignacion
8
32
5
14
3
15
3
18
4
28
5
25
RFE
Se debe llevar un registro de todas las internaciones activas en el hospital.
1.17.1.4
Tablas - Tabla Paciente
4
2
1
26
RFI
El personal de internación podrá imprimir el detalle de la internación de un paciente.
1.8.1.4
Modulo personal de internación - Imprimir
4
4
1
1.4.2.5.1
UI Personal administrativo - Gestion de nomenclaturas
4
RFI
El personal de administración deberá tener la capacidad de actualizar mensualmente, los importes de las prácticas médicas que se les lleva a cabo a los pacientes.
12
3
32
5
27
28
RFE
Se deben poder registrar a los pacientes en el sistema.
1.10.2.3
Control de Contabilidad - Importes Prácticas
8
1.8.1.1
Modulo personal de internacion - Administracion de paciente - Agregar paciente
6
1.8.1.2
Modulo personal de internacion - Administracion de paciente - Form ingreso de paciente
4
1.8.1.3
Modulo personal de internacion - Administracion de paciente - Egreso de paciente
6
1.12.1
Control de pacientes - Asignacion de turnos
8
1.17.1.4
Base de datos - Tablas - Tabla paciente
4
1.4.2.2.1
UI Personal de internacion - Administracion de pacientes
4
53
29
RFI
El Súper Usuario debe tener acceso a todos los datos del sistema.
30
RFI
Se debe contar con un sistema de Login para identificar a cada usuario.
RFI
El administrador del sistema deberá tener la capacidad de crear cuentas para los distintos usuarios del sistema.
31
32
RFD
Entregas RF2 RF3 RF4 RF5
Los administradores deben poder realizar en cualquier momento un backup de la base de datos.
1.5
Modulo SuperUsuario
30
1.4.1.4
GUI Doctor - Form Logueo
4
1.4.2.4
GUIS Personal - Form Logueo
3
1.13.1
Gestionador de personal - Agregar
4
1.13.2
Gestionador de personal - Modificar
4
1.13.3
Gestionador de personal - Borrar
4
1.13.4
Gestionador de personal - Formulario agregar
4
1.17.2
Bases de Datos - Backup
16
30
5
7
1
16
4
16
4
Max Min (hs) (hs)
Semanas
Baseline
25 de Abril - 2 de Mayo
17,92%
1
1
5
2 de Mayo - 9 de Mayo
35,84%
2
6
10
Peso
9 de Mayo - 16 de Mayo
43,58%
3
11
15
16 de Mayo - 23 de Mayo
52,83%
4
16
20
23 de Mayo - 30 de Mayo
64,52%
5
21
25
30 de Mayo - 6 de Junio
74,35%
6 de Junio - 13 de Junio
87,17%
13 de Junio - 23 de Junio
100%
54
55
Administración de Riesgos Para identificar los riesgos que se presentan en el proyecto, inicialmente se realizará un análisis inicial de riesgos al inicio del proyecto y se identificaran los riesgos que se presentan. Una vez completa la lista inicial de riesgos, se procederá a calcular la probabilidad de ocurrencia de cada riesgo, su impacto en el proyecto y su nivel de exposición como resultado de multiplicar los valores de ocurrencia e impacto. La forma de clasificación a cada riesgo será la siguiente: Probabilidad Alta Media Baja
Impacto Alta Media Baja
Alta Media Baja
Definición de exposiciones Alta Media 9 6 6 4 3 2
3 2 1
3 2 1
Baja 3 2 1
Una vez definida la exposición a cada riesgo, de la lista total de riesgos, se seleccionarán aquellos 5 (TOP 5) que tengan mayor exposición y se les llevarán a cabo sus correspondientes acciones de mitigación y acciones de contingencia. Por último, se calculará el riesgo total de del proyecto y se anotará y actualizará de manera constante en cada reunión formal.
Forma de trabajo: ●
Se dedicará un tiempo a la evaluación de los riesgos en cada ciclo de desarrollo, de esta evaluación se actualiza la planilla de riesgos con nuevos riesgos si los hubiere o actualizando los valores de probabilidad y impacto de los mismos si hubieran cambiado.
●
Luego de cada evaluación se volverá a definir el TOP 5.
●
Se trabajará en realizar planes de mitigación y contingencia de los riesgos conformados en este TOP 5. No se evaluaran los demás debido a que puede llegar a ser una lista muy larga y muy costosa de analizar. Si ya existen planes de mitigación o contingencia para alguno de ellos, se pensara en cómo mejorarlos.
56
Listado de Riesgos Inicial Descripcion
No cumplir con los hitos
Severidad/I Exposicion Probabilidad mpacto del de ocurrencia al riesgo riesgo 3
3
9
3
3
9
2
3
6
Rearmado de Diseño
2
3
6
Reacción tardia en la toma de decisiones importantes
2
2
4
Omitir el uso de una herramienta de desarrollo beneficiable
2
2
4
2
2
4
2 1
2 3
4 3
Accidentes
1
3
3
Miembro del equipo con sobrecarga horaria
3
2
6
1 2 Riesgo Total
2 60
El cliente solicita cambios criticos y el equipo determina que deben ser llevados a cabo Los requerimientos no se han definido de manera correcta
La curva de aprendizage de la nueva herramienta es mas larga de lo esperado Se añaden requerimientos extras Enfermedades
Baja motivacion
57
TOP 5 - Riesgos
Descripcion No cumplir con los hitos
El cliente solicita cambios criticos y el equipo determina que deben ser llevados a cabo
Probabilidad Severidad/ de Impacto Exposicion ocurrencia del riesgo al riesgo 3
3
3
3
9
9
Responsable Acciones para mitigarlo Contingencia Se realiza una estimación inicial que permita Se reevaluara el calendario para completar con adapatar el tiempo de trabajo en caso de que no se las actividades no realizadas para la fecha llegue a cumplir con un hito. prevista. Reveer el documento de alcance con el cliente en cada reunion formal para asi lograr una vision conjunta de las caracteristicas del sistema.
Se negociara con el cliente aquellos cambios propuestos de manera tal que no impacten en gran medida con el diseño y desarrollo del proyecto.
Lautaro Tacchini / Gonzalo Pesado
Se acordara con el cliente aquellos requerimientos faltantes o que no hayan sido bien detallados.
Gonzalo Pesado
Los requerimientos no se han definido de manera correcta
2
3
6
Dedicar un tiempo a reveer requerimientos del sistema, tratar de aclarar con el cliente las funcionalidades que espera del sistema y ver si los requerimientos plasman esa realidad.
Rearmado de Diseño
2
3
6
Elaboracion de prototipos del sistema para validacion del usuario.
Evaluar una 2da alternativa de diseño.
Realizar una estimación inicial planeada para administrar adecuadamente los rangos de horarios de trabajo de cada miembro.
Redistribuir las tareas que sobrecargan a un miembro hacia otro miembros que tengan menos carga horaria o que se encuentren disponibles para relevar a su compañero.
Miembro del equipo con sobrecarga horaria
3
2
6
Lautaro Tacchini
Gonzalo Pesado Lautaro Tacchini
58
Administración de Cambios Para la documentación y gestión de cambios utilizaremos la siguiente plantilla: Fecha Resumen aparición
Detalle
Impacto Beneficio Análisis Validación
Fecha Fecha aprobación conclusión
Los valores de dicha planilla serán: ●
Fecha Aparición: Fecha en la que se propuso el cambio.
●
Resumen: Se detalla brevemente en qué consiste el cambio, lo utilizamos para identificar rápidamente el cambio.
●
Detalle: Se detalla el cambio para luego ser analizado por el equipo de trabajo y evaluar los detalles del cambio y cómo poder realizarlo.
●
Impacto: Cuánto impacta el cambio en el proyecto. Utilizaremos la siguiente escala ○
Alto = Es un cambio que por diversos motivos será muy laborioso de trabajar y a su vez puede conllevar a futuros problemas al implementarlo.
○
Medio = Es un cambio que si bien no desestabiliza el proyecto, su implementación traerá un costo considerable para implementar.
○
Bajo = Es un cambio que no afectara la estructura del proyecto, además su implementación no debería traer costos considerables de implementación.
●
Beneficio: Que tanto beneficia al usuario la implementación de dicho cambio, utilizamos la siguiente escala: ○
Alto = Grandes beneficios para el sistema al aplicarlos.
○
Medio = Cambios útiles para el sistema.
○
Bajo = Cambios poco significativos para el sistema.
●
Análisis: Detalla los pasos necesarios para aplicar el cambio.
●
Validación: Detalla si el cambio va a ser aplicado o no.
●
Fecha aprobación : Fecha en la que se aprueba el cambio
●
Fecha de conclusión: Fecha en la que el cambio ya está implementado en el sistema.
59
Forma de trabajo: ●
Los cambios serán relevados en cada reunión formal, de ese relevamiento se registraran en la planilla de cambios.
●
Durante el ciclo posterior al registro del cambio se analizará el cambio para determinar si el cambio se acepta o se rechaza.
●
En la próxima reunión formal, ya una vez analizado el cambio podrán ocurrir 2 escenarios: ○
Se negociará con el cliente sobre las condiciones de aceptación del cambio
○
Se explica al cliente porque no debe aceptarse el cambio y se negocia si el cambio debería ser re-evaluado.
60
Administración de Testing ●
El procedimiento para la elaboración de la documentación de test se basará en los siguientes pasos:
1) Elaboración y mantenimiento de planilla de bugs: En la misma consiste en un registro de los bugs del sistema. La misma consiste en: ○
BUG-ID: Identificador del bug, consiste en un número único referente al bug, si llega a ser un bug recurrente (bug resuelto previamente que reapareció) se agregara una R por cada aparición del mismo.
○
Categoría: Categoría del bug en cuestión, puede ser: i)
Crítico: Bug que impide la realización de una funcionalidad en cuestión, están relacionados con los criterios de aceptación de las pruebas.
ii)
Importante: Bug que dificulta la realización de la funcionalidad en cuestión. Por ej.: Ausencia de mensaje o mensaje poco descriptivo en la validación de un campo de un formulario.
iii)
Leve: Bugs referidos a pequeños desperfectos del sistema. Por ej.: Error ortográfico en algún mensaje, Texto en botones escondido, Errores visuales que provengan de la interfaz, etc.
○
Ciclo de aparición: Número de ciclo de la 1ra aparición del bug.
○
Fecha: Fecha exacta de aparición del bug
○
Descripción: Detalles sobre el bug, el mismo deberá proveer la suficiente información para poder ser resuelto.
○
Clases involucradas: Se detallan las clases involucradas en dicho bug.
○
Estado: Estado actual del bug, los estados pueden ser. i)
Abierto: Todavía no se asignaron recursos para que se arregle dicho bug
ii)
En corrección: Se asignaron recursos para resolver el bug.
iii)
Pendiente de aprobación: Se está esperando una aprobación del bug después de haber estado en corrección.
iv) ○
Corregido: El bug ya se encuentra solucionado.
Responsable: Responsable del seguimiento del bug. Ciclo de
BUG-ID Categoría aparición Fecha
Clases Descripción
involucradas
Fecha de Estado
corrección
Responsable
61
2) Registro semanal de bugs: Planilla que brindará soporte al indicador de evolución de la prueba, la misma consiste en: ○
Ciclo: Ciclo perteneciente a la revisión.
○
Rango de fechas: Rango de fechas de donde se basa la revisión
○
Bugs abiertos: Bugs incorporados a la planilla de bugs entre esas fechas
○
Bugs cerrados: Bugs solucionados entre esas fechas.
○
Pendientes: Bugs provenientes de fechas anteriores que todavía no se solucionaron.
Forma de trabajo: Con respecto con el trabajo en cada ciclo: ●
Se desarrollaran los casos de prueba pertinentes a las funcionalidades que se entregarán en dicha versión.
●
Se evaluará la planilla de bugs para saber sobre que bugs se debería trabajar en este ciclo.
●
Se realizará un mínimo 1 “prueba completa” por semana para aportar datos concisos al documento de testing. Con “pruebas completas” nos referimos a la realización de todas las pruebas posibles de realizar (que no posean dependencias todavía insatisfechas) del sistema. Los bugs pueden ser reportados por los mismos desarrolladores, para estos casos el tester realizará el mismo proceso de negocio en busca de un posible bug.
●
Semanalmente se completará el registro semanal de bugs. En el mismo se detallarán los bugs abiertos y cerrados a lo largo de la semana.
●
Se actualizarán los indicadores de evolución de la prueba teniendo en cuenta el registro semanal de bugs.
Con respecto a la validación de testing: ●
Una vez que desarrollo libere el código para la validación de testing, se ejecutarán los procesos de negocio pertenecientes a la funcionalidad a validar. ○
Para esto se ejecutarán TODAS las pruebas pertinentes a dicha funcionalidad, las mismas están detalladas en la planilla de pruebas.
○
Si en la ejecución de las mismas alguna de ellas se encuentra “desaprobada” (por lo tanto no cumple con los criterios de aceptación de la misma) la funcionalidad NO será validada por testing.
○
Si una funcionalidad se encuentra desaprobada por testing, se priorizará la corrección de los bugs críticos referidos a dicha funcionalidad. Una vez resuelto el último bug crítico, se volverá a evaluar la funcionalidad para ver si se validara.
○
Si se realizan cambios importantes en alguna funcionalidad que ya previamente validada, se volverá a realizar el proceso de validación.
62
Related documents
PentaSoft - Plan de Proyecto
64 Pages • 14,132 Words • PDF • 2.5 MB
Proyecto de Comprensión Lectora
10 Pages • 3,376 Words • PDF • 912.3 KB
Plan de Clases Sociales
5 Pages • 1,270 Words • PDF • 752 KB
plan de estudios medicina
1 Pages • 396 Words • PDF • 162.1 KB
Plan de Área Humanidades
427 Pages • 67,315 Words • PDF • 3.1 MB
Proyecto de lectura Caperucita Roja
15 Pages • 2,039 Words • PDF • 11 MB
investigacion de Tabulación para proyecto
3 Pages • 531 Words • PDF • 144.3 KB
Mas sobre Proyecto sentido
15 Pages • 5,100 Words • PDF • 264.9 KB
5 motivaciones del proyecto
70 Pages • 4,152 Words • PDF • 2.9 MB
Programa Plan de inventarios
19 Pages • 3,024 Words • PDF • 1 MB
Plan de Mercadeo CCMA
103 Pages • 3,948 Words • PDF • 3.6 MB
Separata - Antepryecto y Proyecto
4 Pages • 10 Words • PDF • 3.3 MB