Documento de Análi Análisis y Diseño del Sistema Informático Informático del Observatorio de Salud de la Municipalidad de Lima Hannes Rodríguez Versión: 10-08-2012
2012
Contenido
Sección: Requerimientos del Sistema ..................................................................................... 3 1.
Alcance del documento: ................................................................................................. 3
2.
Descripción del caso a automatizar ............................................................................... 3
3.
Situación actual ............................................................................................................... 3 Diagrama de Caso de Uso de Negocio ................................................................................ 3 Especificación del Caso de Uso del Negocio ....................................................................... 4 Diagrama de Actividades del Caso Uso de Negocio ........................................................... 5 Diagrama de Clases de Negocio .......................................................................................... 6 Consideraciones acerca de las Fuentes de Información Actuales y Futuras..................... 7 Propuesta de carga de información al sistema .................................................................. 7
4.
Visión del sistema de información................................................................................. 8
5.
Identificación de usuario, roles ..................................................................................... 8
6.
Requerimientos del sistema........................................................................................... 8 Requerimientos funcionales ................................................................................................ 8 Requerimientos No Funcionales ......................................................................................... 9
Sección: Especificaciones Funcionales .................................................................................. 10 7.
Diagrama de Casos de Uso de Sistema ........................................................................ 10
8.
Especificación de Casos de Uso de Sistema (CUS) ..................................................... 11
9.
Diagramas de Secuencia de Análisis ............................................................................ 22
Sección diseño Físico ............................................................................................................. 28 10.
Modelo físico de datos ................................................................................................. 28
11.
Detalles de las entidades del modelo físico de datos ................................................ 29
12.
Aspectos de Tecnología................................................................................................ 31
Glosario de Términos ............................................................................................................. 33 Referencias ............................................................................................................................ 34 Anexos ................................................................................................................................... 35
Página | 2
Sección: Requerimientos del Sistema 1.
Alcance del documento: Este documento contiene los elementos necesarios que servirán de insumo para construir el Sistema Informático del Observatorio de Salud por lo tanto el documento contiene detalles técnicos del modelamiento del sistema como: modelo de análisis del negocio, los requerimientos funcionales y no funcionales del sistema, el modelo de análisis de sistema, las principales interfaces que deben construirse y el modelo de datos. La metodología utilizada para el modelamiento del sistema de información es RUP (Rational Unified Process). Se utilizó notación UML 2.3 por lo tanto el documento contiene diagramas de análisis de negocio, análisis de sistemas realizados con esta notación.
2.
Descripción del caso a automatizar La Subgerencia de Sanidad de la Municipalidad de Lima, a través de su División de Laboratorios Y Prevención Sanitaria, viene utilizando la información sobre casos de muertes violentas remitida por el Instituto de Medicina Legal (IML) e Información de la Oficina de Epidemiología del MINSA. Esta información es remitida principalmente por el IML de forma mensual y ha servido para procesar información estadística que permita conocer las características de las muertes violentas en Lima Metropolitana y esta sirva como uno de los insumos de la actual estrategia “Hora Segura”. Esta estrategia intenta mitigar las muertes violentas provocadas por el consumo de alcohol. La Sub Gerencia de Sanidad, requiere implementar el Sistema Informático Observatorio de Salud, que facilite el almacenamiento de la información especializada a nivel de microdatos y que permita obtener cuadros, gráficas y mapas que sean útiles para el análisis y toma de decisiones.
3.
Situación actual Diagrama de Caso de Uso de Negocio (CUN) El siguiente diagrama de caso de uso de negocio permite visualizar el proceso principal que se realiza para los fines del Observatorio, este es: Procesamiento de la Información para el Observatorio de Salud. Este proceso es el que actualmente se realiza en la División de Laboratorio y Prevención de Zoonosis. El diagrama explica que el proceso de negocio se lleva a cabo para proveer, con indicadores de seguimiento, a los Responsables del Observatorio de Salud (Jefe de División y Sub Gerencia de Sanidad) y a los Miembros de la Mesa de Trabajo del Observatorio de Salud. uc Modelo de Casos de Uso de Negocio
Procesamiento de la información para el Observ atorio de Salud
Responsable de Observ atorio de Salud
Miembro del Observ atorio de Salud
Gráfico Nº 1: Diagrama de Caso de Uso de Negocio (CUN)
Página | 3
Especificación del Caso de Uso del Negocio A continuación se describe las actividades que involucran el CUN: Procesamiento de la Información para el Observatorio de Salud: Actualmente, la Sub Gerencia de Sanidad, a través de su División de Laboratorio y Prevención de Zoonosis, es la oficina responsable de recibir la información remitida por el Instituto de Medicina Legal (IML). El IML remite mensualmente información sobre los casos de muertes violentas y sus características en un archivo de formato EXCEL. La información remitida consta de lo siguiente: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Fecha y hora de ingreso Sexo Edad Distrito domicilio Grado instrucción Estado civil Causa de muerte: Homicidio, Accidente de Tránsito o Suicidio. Distrito de ocurrencia Fecha y hora de accidente Grado de alcoholemia
La persona responsable en la División de Laboratorio, se encarga de procesar esta información obteniendo los siguientes resultados: 1. 2. 3. 4. 5.
Comparativos mensuales de las ocurrencias de muertes violentas: por accidentes de tránsitos, suicidios y homicidios. Gráficas de tendencia de muertes violencia según día de la semana. Muertes violentas según hora del día y presencia del alcohol, por mes. Gráfica de tendencia de muertes violentas según hora del día. Comparativos por mes y año de las muertes violentas: por accidentes de tránsito, suicidios y homicidios según sexo, grupo etáreo, casos con y sin alcohol, lugar de ocurrencia y estado civil.
Estos resultados son utilizados para elaborar un boletín mensual sobre la caracterización de las muertes violentas en Lima Metropolitana. Actualmente este boletín es una iniciativa importante que contiene los resultados del Observatorio para la Salud, pero aún no es un documento reconocido como oficial. Los resultados y el boletín son enviados a la Jefatura de la División de Laboratorio y a la Sub Gerencia de Sanidad, además se espera que está información sea difundida y sirva a otras áreas de la Municipalidad y Entidades que son miembros de la Mesa de Trabajo del Observatorio de Salud de la ML. La Mesa de Trabajo del Observatorio de Salud, podrá realizar el análisis de la información y utilizar los resultados para tomar acciones en beneficio de la población.
Página | 4
Diagrama de Actividades del Caso Uso de Negocio CUN: Procesamiento Actual de la Información para el Observatorio de Salud El siguiente diagrama de secuencia explica de forma gráfica la especificación del caso de uso de negocio Procesamiento de la Información para el Observatorio de Salud: act Act Procesamiento de Informacion Resposable de IML
Especialista de Información
Inicio
Remite información de Muertes Violentas
recibe y almacena la información en una carpeta
Realiza un comparativ o de las tendencias de muertes v iolentas
Obtiene reportes comparativ os en cuadros (tablas)
Excel con Muertes Violentas: Mes 2
Excel con Muertes Violentas: Mes 3
Tablas comparativas de datos: Mes #2-3
Obtiene gráficas de tendencias Graficos de Tendencia: Mes #2-3
Elabora boletín mensual Boletin: Mes #3
Entrega boletin a Jefa de Div isión de Laboratorio
Final
Gráfico Nº 2: Diagrama de Secuencia del Procesamiento de la Información para el Observatorio de Salud
Página | 5
Diagrama de Clases de Negocio El siguiente diagrama de Clases de Negocio, permite visualizar los business entity (en este caso es la información utilizada), que se relacionan con los Business Actor que realizan actividades en el proceso analizado. Este diagrama facilita conocer qué información utiliza el personal que realiza las actividades del proceso. class cls Procesamiento
Envia Responsable de IML
Excel con Muertes Violentas: Mes 2
Envia
Consulta Excel con Muertes Violentas: Mes 3
Recepciona
Especialista de Información
Elabora
Elabora
Tablas comparativas de datos: Mes #2-3
Elabora
Graficos de Tendencia: Mes #2-3
Boletin: Mes #3
Gráfico Nº 3: Diagrama de Clases de Negocio
En el gráfico Nº 3, el Busines Entity: “EXCEL CON MUERTES VIOLENTAS”, tiene la siguiente estructura de datos: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Fecha y hora de ingreso Sexo Edad Distrito domicilio Grado instrucción Estado civil Causa de muerte: Homicidio, Accidente de Tránsito o Suicidio. Distrito de ocurrencia Fecha y hora de accidente Grado de alcoholemia
Página | 6
Consideraciones acerca de las Fuentes de Información Actuales y Futuras El Instituto de Medicina Legal es la fuente de información actualmente activa, ya que remite su información a la Sub Gerencia de Sanidad de forma mensual (ver Gráfico Nº 2) y por lo tanto es la información que se procesa para los fines del Observatorio. La Oficina de Epidemiología del MINSA, ha remitido información en el pasado pero esto no ha sido una constante. En el futuro se espera que las siguientes Instituciones, que forman parte de la Mesa de Trabajo del Observatorio de Salud, remitan periódicamente información: • • • •
El Instituto de Medicina Legal Oficina de Epidemiología del MINSA Policía Nacional del Perú Policía de Tránsito
Propuesta de carga de información al sistema Cada una de las instituciones mantiene y procesa su información utilizando diferentes sistemas informáticos o diferentes métodos de almacenamiento físicos, esta situación lleva a considerar que en una fase inicial, no se debe automatizar la carga de datos desde las Instituciones (fuentes de información) hacia la base de datos principal del Observatorio de Salud. La carga de datos debería realizarse en la Sub Gerencia de Sanidad de la ML, previo un proceso de consistencia realizado por un equipo de especialistas como parte de las actividades del Observatorio de Salud. Toda vez que la Mesa de Trabajo del Observatorio de Salud haya consistenciado la información que se deberá cargar al Sistema Informático, ésta tarea de carga se podrá realizar de dos maneras: a través de una pantalla que permitirá el ingreso de cada registro o a través de una pantalla que facilitará la carga masiva usando una hoja de Excel bajo un formato específico. Para esta parte considero conveniente citar lo siguiente: “A menudo se propone la vinculación de los datos policiales con otras fuentes de datos como medio de elevar la calidad de estos, pero puede que no sea la mejor forma de iniciar la mejora del sistema de base de datos. Vincular con éxito bases de datos existentes puede ser sumamente complicado y difícil. Probablemente resulte más productivo invertir los recursos en otras estrategias. Como primer paso, un subgrupo del grupo de trabajo multisectorial de datos podría reunirse cada cierto tiempo (una vez a la semana, al mes o al trimestre, según el volumen de accidentes graves y mortales) para examinar y comparar datos de diversas fuentes y discutir las posibilidades de establecer mecanismos de vinculación formales. Si no es factible vincular las bases de datos, quizá sí se puedan incluir datos de otras fuentes mediante 1 un mecanismo de ingreso de datos centralizado.”
1
Fuente: Data systems: a road safety manual for decision-makers and practitioners. World Health Organization 2010.
Página | 7
4.
Visión del sistema de información El Sistema Informático del Observatorio de Salud permitirá almacenar y procesar la información remitida en colaboración por instituciones como: • • • • • • •
El Instituto de Medicina Legal. Oficina de Epidemiología del MINSA. Policía Nacional del Perú. Policía de Tránsito del Perú. Gerencia de Educación, Cultura y Deportes de la ML. Gerencia de Transporte Urbano de la ML. Dirección General de Salud de las Personas – MINSA.
El sistema deberá permitir obtener resultados en valores absolutos y porcentuales comparados por periodo, mostrándolos en formatos de tablas de datos, gráficas de tendencia y mapas, que faciliten su interpretación.
5.
Identificación de usuario, roles a) Miembros del Observatorio de Salud, que forman parte de la Mesa de Trabajo del Observatorio de Salud, tales como: Instituto de Medicina Legal, Epidemiología, Policía Nacional del Perú, Policía de Tránsito, Otras Gerencias de la Municipalidad de Lima, DGSP del MINSA, y que serán los responsables de enviar Información para el Observatorio de Salud. b) Responsable del Observatorio de Salud: Jefe de División de Laboratorio y Sub Gerente de Sanidad. c)
6.
Especialista de Información del Observatorio de Salud de la Sub Gerencia de Sanidad, encarga do de realizar las tareas de carga y procesamiento de datos.
Requerimientos del sistema Los requerimientos del sistema se obtienen a partir de las necesidades actuales identificadas luego de analizar los los procesos de negocio identificados. Los requerimientos están divididos en Funcionales y No Funcionales. Requerimientos funcionales Los requerimientos funcionales, son aquellos que nacen a partir de las necesidades de aquellos actores que harán uso del sistema. Los requerimientos del sistema del Observatorio de Salud son los siguientes y se obtuvieron de la matriz de automatización como parte del análisis del proceso de negocio (Ver Anexo Nº 1: Matriz de Automatización): 1) 2) 3)
4)
5)
El sistema debe permitir matricular el tipo de información que debe almacenar y procesar el sistema del Observatorio de Salud. Por ejemplo: Muertes Violentas. El Sistema debe permitir configurar la estructura de datos que soportará cada Tipo de Información, es decir, matricular cada variable que debe registrar datos. El sistema debe permitir que la información pueda ser cargada a la base de datos en dos formas: un caso a la vez o de forma masiva a través de un formato estándar en Excel. Estos dos procesos deben permitir la validación de los datos y en el caso de la carga masiva debe realizar la aprobación de los datos a cargar. El sistema debe realizar la validación de los datos que serán cargados al sistema tomando en cuenta lo siguiente: verificar la existencia de duplicados, verificar incongruencias entre variables, validar los rangos válidos. El sistema debe permitir corregir en pantalla los registros con problemas.
Página | 8
6) El sistema debe proveer en Excel el formato de carga masiva de información con la estructura de datos para cada Tipo de Información 7) El sistema debe permitir seleccionar los periodos (mes y año) a comparar, asimismo debe permitir seleccionar la variable o variables que desea compararse, seleccionar la variable de corte y realizar los cálculos necesarios para realizar la comparación. 8) El sistema debe permitir obtener los reportes indicados en el Anexo Nº 3: Reportes del Sistema del Observatorio de Salud. 9) El sistema debe permitir incluir en los reportes información de las Tasas sobre la población total, para ello debe utilizar la información de la población total proyectada o censada del año. 10) El sistema debe permitir la exportación de los resultados obtenidos a un formato de excel. 11) El sistema debe permitir mostrar gráficas de tendencias a partir de los resultados obtenidos. Para ello solo debe indicarse que la variable de corte puede ser usada en la línea de abscisa. 12) El sistema debe permitir aprobar la difusión de los datos y resultados del mes. 13) El sistema debe permitir mostrar en un mapa el ranking de los distritos, con respecto a una variable evaluada. El valor del ranking de un distrito debe mostrarse pintando al distrito con una intensidad diferente de un color. 14) El sistema debe permitir subir y publicar en el sitio web los boletines y los mapas obtenidos durante el procesamiento de datos georeferenciados con el gvSIG. Requerimientos No Funcionales Los requerimientos no funcionales especifican las propiedades ó características del sistema que se deben cumplir para tener un eficaz y óptimo funcionamiento. Los requerimientos no funcionales son: Disponibilidad La información se encontrará disponible las 24 horas del día los 7 días de la semana, brindando información a todo momento. El sistema será desarrollado en plataforma web para cumplir con este requerimiento. La disponibilidad dependerá del Nivel de Servicio que otorguen los servicios de hosting o servidores donde se instale el sistema. Escalabilidad El sistema debe permitir crear nuevas estructuras de datos que puedan ser configuradas de forma sencilla por el Administrador del Sistema. Asimismo, el sistema se desarrollará con un enfoque a Objetos para facilitar la reutilización de componentes de software en caso se requiera ampliar funciones al sistema. Facilidad de uso de la Información La navegación en el Portal se presentará de manera ágil y dinámica para cualquier usuario. El sistema presentará mensajes de error y mensajes de información que serán de fácil entendimiento y que permitan al usuario entender un error para buscar la solución o comunicarlo al Administrador del Sistema.
Página | 9
Sección: Especificaciones Funcionales 7.
Diagrama de Casos de Uso de Sistema El diagrama de casos de uso de sistema (CUS), permite mostrar gráficamente las funcionalidades que tendrá disponible el sistema del Observatorio de Salud, así como las relaciones con los Actores que interactúan con dichas funcionalidades, de esta forma se delimita el sistema. A continuación se muestra el diagrama de Casos de Uso del Sistema Informático del Observatorio de Salud: uc Modelo de casos de uso
Ingresar al sistema
Obtener mapa de ranking A petición «extend»
Miembro del Observ atorio de Salud
Realizar comparativ o de datos
Exportar reportes comparativ os
A petición «extend»
Usuario A petición «extend» Generar reportes gráficos
Responsable del Observ atorio de Salud
Configurar Información a cargar al sistema Especialista en Información del Observ atorio
Realizar carga masiv a de datos
Aprobar la difusión de los resultados Registrar información de un registro
A petición «extend»
Descargar formato de carga masiv a
Si existen problemas de validación «extend» «include»
Publicar boletines y mapas georeferenciados
«include»
Realizar v alidación de datos
«include»
Corregir registros con problemas de v alidación
Gráfico Nº 4: Diagrama de Casos de Uso de Sistema
Página | 10
8.
Especificación de Casos de Uso de Sistema (CUS) La especificación de casos de uso de sistema, permite observar con mayor detalle las actividades que se realizarán en cada funcionalidad del sistema. Cada CUS tiene un código que lo identifica, de esta forma se mantiene la trazabilidad o relación con los requisitos del sistema. Cada caso de uso está relacionado con uno o más requisitos del sistema. Esta relación de Caso de Uso de Sistema y Requerimientos del Sistema puede verse en el Anexo Nº 2: Matriz de Trazabilidad.
Código del CUS
CUS000
Nombre del CUS:
Ingresar al sistema
Actores:
Usuario
Precondiciones: Flujo Básico Sub Flujos
1. 2. 1. 2. 3. -
El Actor debe estar registrado en el sistema. El Actor debe tener permisos de acceso. El actor escribe su usuario y contraseña. El actor presiona aceptar El actor logra ingresar al sistema
1.
Flujos alternativos Post condiciones
El nombre del usuario o contraseña no encontrada: En el punto 2, el usuario no logra ingresar al sistema y el sistema de mostrar un mensaje indicando el motivo. El usuario ingresa al sistema.
Prototipo de pantalla: custom Formularios principales Login Ingresar al Sistema
Usuario:
Contraseña:
Aceptar
Gráfico Nº 5: Pantalla de ingreso al sistema
Código del CUS
CUS001
Nombre del CUS:
Configurar Información a cargar al sistema
Actores:
Especialista en Información del Observatorio
Precondiciones:
1.
El Actor está logeado en el sistema y tiene permisos para la tarea.
Flujo Básico
1. 2. 3. 4.
El sistema obtiene los Tipos de Información disponibles. El Actor selecciona el Tipo de Información. El sistema muestra las variables que se encuentran registradas El Actor ingresa el nombre de la nueva variable y su tipo: Numérico,
Página | 11
Código del CUS
CUS001
Nombre del CUS:
Configurar Información a cargar al sistema cadena, fecha u hora. El actor ingresa los valores aceptados por la variable o indica si acepta rango mínimos y máximo de la variable. 6. El Actor presiona el botón: ‘Grabar Variable’ para grabar la nueva variable en el sistema. 7. El Actor presiona Cerrar la salir de la pantalla actual. Eliminar Variable 1. El Actor presiona el botón Eliminar de la lista de variables. 2. El sistema Elimina el registro elegido. Modificar Variable 1. El Actor presiona el botón de Modificar de la lista de variables 2. El sistema muestra los datos del registro seleccionado en pantalla 3. El Actor actualiza los datos 4. El actor presiona el botón ‘Grabar Variable’. 1. En el punto 1: Si el Tipo de Información no existe. 2. El sistema muestra una ventana para registrar el Tipo de Información el actor ingresa el nombre del nuevo Tipo de Información (Categoría). 3. El actor graba el nuevo Tipo de Información (Categoría). 1. Un nuevo Tipo de Información (Categoría de Dato) es registrado. 2. Una o más variable y su tipo de datos se registra en el sistema y forma parte de la estructura de datos que se gestionará en el sistema. 5.
Sub Flujos
Flujos alternativos
Post condiciones
Prototipo de pantalla: custom Formularios principales Configurar Estructura de Datos Nuev o Tipo de Información
Configurar Estructura de Datos
Ingrese el nuevo Tipo de Información
Tipo o Categoría de Información:
...
«navigate» Aceptar
Cancelar
Nombre de la nueva variable:
Tipo de dato:
Cerrar
Grabar variable
Lista de variables Nombre de la variable
Tipo de dato
Acción Eliminar Modificar
Eliminar v ariable ¿Eliminar variable seleccionada?
«navigate» Si
No
Gráfico Nº 6: Pantalla para Configurar Estructura de Datos
Página | 12
Código del CUS
CUS002
Nombre del CUS:
Registrar información de un registro
Actores:
Especialista en Información del Observatorio
Precondiciones:
1.
El Actor está logeado en el sistema y tiene permisos para la tarea.
1. 2.
El sistema obtiene los Tipos de Información disponibles. El Actor selecciona el Tipo de Información (Categoría) a la que se cargará información. 3. El Actor selecciona el periodo de datos (Mes y Año). 4. El sistema muestra un listado de los registros almacenados. 5. El Actor presiona el botón ‘Agregar’. 6. El sistema se habilita para ingresar un registro de datos. 7. El Actor ingresa los valores del nuevo registro. 8. El Actor presiona Grabar 9. El sistema realiza la validación de la información registrada para ello realiza el CUS Nº: 0010. 10. La información validada se almacena con un estado de: CARGADO. Modificar Variable 1. El Actor presiona el botón de Modificar de la lista de registros. 2. El sistema muestra los datos del registro seleccionado en pantalla 3. El Actor actualiza los datos. 4. El actor presiona el botón ‘Grabar. Cerrar ventana 1. El Actor presiona Cerrar, el sistema pregunta si desea salir sin grabar. 2. El Actor elige No y no se cierra el proceso. 3. El Actor elige Si y sale del proceso sin grabar. -
Flujo Básico
Sub Flujos
Flujos alternativos
1.
Post condiciones
Un nuevo registro de datos fue registrado en el sistema.
Prototipo de pantalla: custom Formularios principales Registrar información
Tipo de Información: Mes
Año
Variable 1
Variable 2
Valor 1
Valor 2
Variable n Valor n
:Eliminar v ariable Eliminar Modificar
¿Eliminar variable seleccionada? Si
Agregar
Grabar
No
Cerrar
Gráfico Nº 7: Pantalla para Registrar la Información
Página | 13
Código del CUS
CUS003
Nombre del CUS:
Realizar carga masiva de datos
Actores:
Especialista en Información del Observatorio 1. 2. 1. 2.
Precondiciones:
Flujo Básico
Sub Flujos
Flujos alternativos
Post condiciones
El Actor está logeado en el sistema y tiene permisos para la tarea. El formato de carga masiva en Excel debe tener información a cargar. El sistema obtiene los Tipos de Información disponibles. El Actor selecciona el Tipo de Información (Categoría) a la que se cargará información. 3. El Actor presiona el botón […] y busca el formato de carga masiva de datos en Excel y lo selecciona. 4. El Actor presiona el botón de “Realizar Carga Masiva”. 5. El sistema evalúa cada registro a cargar realizando las validaciones efectuadas por el Caso de Uso Nº 10 6. El sistema graba todos los registros en la base de datos. 7. Cada registro grabado tiene el estado de: CARGADO 8. El sistema muestra el mensaje: “Todos los datos fueron cargados correctamente”, asimismo mostrará la cantidad de registros grabados: “Se grabaron un total de XX registros”. 9. El Actor presiona ‘Cerrar’. Descargar formato de carga masiva 1. El Actor elige la opción “Descargar formato: Carga Masiva” y el sistema realiza el CUS Nº004. Registro con información no valida: 1. En el paso 5 del flujo básico: Si el sistema detecta que existen registros que no pasaron la validación estos registros se graban con el estado: POR VALIDAR. 2. El sistema mostrará el mensaje: “Existe NN registro(s) con información no válida y no serán tomados en cuenta en los cálculos futuros, dar click para revisar”. 3. El Actor da click al link y se realiza el CUS Nº 0011 Se logra grabar en el sistema más de un registro de información.
Prototipo de pantalla: custom Formularios principales Realizar carga masiv a de datos
Tipo de Información:
Descargar Formato de Carga Masiva Seleccionar archivo de carga masiva con datos
...
Realizar Carga Masiva
Mensaje de Usuario: Existe NN registro(s) con información no válida y no serán tomados en cuenta en los cálculos futuros, dar click para revisar
Gráfico Nº 8: Pantalla para Carga Masiva de Datos
Página | 14
Código del CUS
CUS004
Nombre del CUS:
Descargar formato de carga masiva
Actores:
Especialista en Información del Observatorio
Precondiciones:
1. 2. 1. 2.
Flujo Básico
El Actor está logeado en el sistema y tiene permisos para la tarea. Se ha seleccionado un Tipo de Información (Categoría). El Actor da click sobre el botón: “Descargar formato: Carga Masiva”. El sistema lee todas las variables correspondientes al tipo de información y graba los nombres de cada variable en la primera fila de cada columna del archivo en Excel. El sistema graba el formato en Excel e inicia la descarga de archivo.
Sub Flujos
3. -
Flujos alternativos
-
Post condiciones
Archivo de Carga Masiva, obtenido desde la web.
Código del CUS
CUS005
Nombre del CUS:
Realizar comparativo de datos
Actores:
Usuario
Precondiciones:
Flujo Básico
Sub Flujos
Flujos alternativos
1. 2. 1. 2. 3.
El usuario está en la ventana de realizar comparativos de datos. Existe información en estado: APROBADO. El sistema obtiene los Tipos de Información disponibles. El Actor selecciona el Tipo de Información (Categoría). El sistema obtiene los Periodos (Año y mes) disponibles para el Tipo de Información. 4. El Actor selecciona los periodos (mes y año) a comparar: Para ello elige el Primer Periodo (mes y año) y luego el Segundo Periodo de referencia (mes y año de referencia). 5. El actor selecciona la variable que desea compararse (totalizarse). 6. El actor seleccionar UNA variable de corte o agrupamiento y presiona el botón de COMPARAR. 7. El sistema realiza los cálculos y procedimientos necesarios para realizar la comparación. 8. El sistema muestra en una pantalla el reporte obtenido. 9. El usuario presiona ‘Cerrar’ y sale del reporte. 10. El Actor presiona ‘Cerrar’ y sale del Obtener Mapa de Ranking 1. El Actor presiona el botón ‘Mapa de Ranking’ 2. El sistema realiza el CUS Nº 009 para mostrar el mapa. 3. El usuario presiona ‘Cerrar’ Exportar a Excel 1. En el paso 8 del Flujo básico, el actor elige la opción ‘Exportar a Excel’ y se efectúa el CUS Nº 006: Exportar reportes comparativos. 2. El actor presiona ‘Cerrar’. Obtiene Gráfica 1. En el paso 8 del Flujo básico, el Actor elige la opción ‘Gráfica’ y se efectúa el CUS Nº 007: Generar reportes gráficos. 2. El actor presiona ‘Cerrar’. 1. En el punto 1 de flujo básico, el sistema no encuentra Tipos de Información registrados. 2. El sistema muestra un mensaje: “No hay registro de Tipo o Categoría de Información”.
Página | 15
Código del CUS
CUS005
Nombre del CUS:
Realizar comparativo de datos 3.
El actor acepta el mensaje y se cierra la ventana actual.
Se obtiene un cuadro comparando los datos de dos periodos.
Post condiciones Prototipo de pantalla:
custom Formularios principales Comparar Información por Periodo
Tipo de Información:
Indique el rango de periodos a comparar Periodo Final
Periodo Inicial Año:
Año:
Mes:
Mes:
Seleccione la v ariable a comparar:
Variable de corte o agrupamiento:
Comparar
Mapa de ranking
Cerrar
Gráfico Nº 9: Pantalla para realizar los reportes de comparación por periodo
Página | 16
Código del CUS
CUS006
Nombre del CUS:
Exportar reportes comparativos
Actores:
Usuario
Precondiciones:
Se ha efectuado exitosamente el Comparativo de datos. 1. 2. 3.
Flujo Básico
4.
El Actor presiona el botón ‘Exportar a Excel’. El sistema apertura el objeto Excel. El sistema graba todos los datos de la tabla del Comparativo en las celdas correspondientes en la hoja de Excel. El sistema graba la hoja de Excel e inicia la descarga del archivo.
Sub Flujos
-
Flujos alternativos
-
Post condiciones
Se logra la descarga del archivo en formato Excel.
Código del CUS
CUS007
Nombre del CUS:
Generar reportes gráficos
Actores:
Usuario
Precondiciones:
1.
Es necesario que se haya procesado un reporte de datos comparados
1. 2. 3. 4. -
El Actor da click sobre el botón “Gráfica”. El sistema toma los resultados del CUS005. El sistema toma a la variable para ser usada en la línea de abscisa. El sistema muestra las gráficas de tendencias los datos calculados.
Flujo Básico Sub Flujos
1.
Flujos alternativos Post condiciones
En el punto 1 del flujo básico, no existe aún datos calculados del CUS005, el sistema muestra un mensaje: “No existen datos disponibles para el gráfico solicitado.” Se obtiene el gráfico de tendencia.
Prototipo de pantalla:
Gráfico Nº 10: Pantalla de Reporte Gráfico de Tendencia
Código del CUS
CUS008
Nombre del CUS:
Aprobar la difusión de los resultados
Actores:
Responsable del Observatorio de Salud
Precondiciones:
1. 2.
Flujo Básico
El Actor está logeado en el sistema y tiene permisos para la tarea. Existe información registrada del periodo en ESTADO: CARGADO. 1. El sistema muestra un listado de los periodos con información
Página | 17
Código del CUS
CUS008
Nombre del CUS:
Aprobar la difusión de los resultados registrada en estado: CARGADO. El Actor selecciona un periodo a la vez. El Actor presiona el botón ‘APROBAR DIFUSIÓN’. El sistema actualiza todos los registros relacionados al periodo seleccionado, cambiando su estado a: APROBADO. 5. El sistema muestra un mensaje: “Todos los registros del período seleccionado fueron aprobados para ser difundidos”. 6. El Actor cierra la ventana actual. 2. 3. 4.
-
Sub Flujos Flujos alternativos
-
Post condiciones
La información CARGADA en el sistema es APROBADA para su difusión.
Código del CUS
CUS009
Nombre del CUS:
Obtener mapa de ranking
Actores:
Usuario 1. 2. 3. 1. 2.
Precondiciones:
Flujo Básico 3.
Existe información registrada del periodo en ESTADO: APROBADO APROBADO. El Actor se encuentra en el CUS005: Realizar comparativo de datos. En el reporte la variable de agrupamiento debe ser un distrito de Lima. El sistema obtiene obtiene los datos del CUS005: Realizar comparativo de datos datos. El sistema calcula el ranking de la variable seleccionada asignando un valor de 1 al primer ranking y de forma sucesiva de mayor a menor con el resto. El sistema muestra el mapa de Lima Metropolitana, Metropolitana, pintando de un mismo color a todos, pero haciendo variar la tonalidad de acuerdo aal valor del ranking de cada distrito. distrito
Sub Flujos
-
Flujos alternativos
-
Post condiciones
El sistema provee un mapa de ranking por variable.
Prototipo de Pantalla:
Mapa de ranking: Muertes violentas, Mes Marzo, 201X 201
Cerrar
Gráfico Nº 11: Pantalla a de Mapa de Ranking
Página | 18
Código del CUS
CUS010
Nombre del CUS:
Validar datos cargados
Actores:
-
Precondiciones:
1. 2. 1.
Flujo Básico Sub Flujos
2. -
Existe información registrada del periodo en ESTADO: POR VALIDAR. Es requerido por los CUS Nº 002, 003 y 011. El sistema recibe los datos del registro y Busca registros duplicados, verifica los rangos válidos para el dato, verifica incongruencias. El sistema devuelve un valor indicando que el registro es correcto.
Post condiciones
En el paso 1: Si el sistema encuentra un valor inválido devuelve un valor indicando el mensaje de error. La información en el sistema es validada.
Código del CUS
CUS011
Nombre del CUS:
Corregir registros con problemas de validación
Actores:
Especialista en Información del Observatorio
Flujos alternativos
Precondiciones:
Flujo Básico
Sub Flujos
Flujos alternativos
Post condiciones
1. 2. 11. 12. 13.
El Actor está logeado en el sistema y tiene permisos para la tarea. Existe información registrada del periodo en ESTADO: POR VALIDAR. El sistema obtiene los Tipos de Información disponibles. El Actor selecciona el Tipo de Información (Categoría). El sistema obtiene los Periodos (Año y mes) disponibles para el Tipo de Información. 1. El Actor elige el tipo de información y periodo de la información que desea corregir. 2. El sistema muestra un listado de todos los registros que tiene Estado: POR VALIDAR. 3. El actor elige uno de los registros. 4. El sistema muestra el mensaje de validación relacionado al problema. 5. El actor corrige los valores del registro 6. El actor presiona GRABAR. 7. El sistema realiza la validación de los datos a través del CUS Nº 010 8. El sistema graba el registro como CARGADO. 9. El actor realiza los pasos 2 al 6, hasta completar todos los registros mostrados. 10. El actor presiona CERRAR y sale de la ventana. Tipo de información y periodo preseleccionados 1. En el flujo básico paso 1: Si el Actor, viene del CUS: Nº 3, el sistema obtiene el tipo de información y periodo y lo usa para listar los registros en el paso 2 del flujo básico. Problemas de validación persistentes 1. En el paso 6: El sistema detecta aún problemas de validación y muestra un mensaje: “El registro grabado presenta problemas de validación y no será tomado en cuenta en los cálculos futuros”. La información CARGADA en el sistema ha sido validada por el usuario.
Página | 19
Prototipo de pantalla:
Gráfico Nº 12: Pantalla para Corregir datos con problemas de validación
Código del CUS
CUS012
Nombre del CUS:
Publicar boletines y mapas georeferenciados
Actores:
Especialista en Información del Observatorio
Precondiciones:
El Actor se encuentra en el módulo de publicación
Flujo Básico
Sub Flujos
Flujos alternativos
Post condiciones
1. 2. 3. 4. 5. 6. 7.
El Actor elige el tipo de publicación a cargar, ejemplo: Boletín o Mapas. El Actor llena los recuadros ‘Descripción del documento’, ‘Periodo’. El Actor da click en en la opción ‘SELECCIONAR DOCUMENTO’ El Actor elige un archivo en formato PDF desde su computadora. El Actor elige ‘Grabar’ El Sistema verifica el tamaño y tipo de archivos. El sistema realiza el uploading cambiando el nombre del archivo a un nombre interno y graba el nuevo nombre. 8. El Sistema graba la información del archivo. 9. El Actor presiona ‘Cerrar. Agregar Tipo de Publicación 1. El Actor elige la opción […] 2. El sistema pone disponible una ventana para ingresar el nuevo tipo de publicación. 3. El Actor ingresa el nuevo tipo de publicación. 4. El Actor elige Grabar 5. El Actor elige Cerrar En el paso 6: 1. El sistema detecta que no se está subiendo un tipo de archivo válido y muestra un mensaje de error: “El Tipo de archivo no es aceptado’. 2. El sistema detecta que el tamaño del archivo excede al mínimo aceptado y muestra un mensaje: “El tamaño mínimo de archivo a cargar es NNN KB” La publicación es cargada y difundida.
Página | 20
Prototipo de pantallas:
ui Formularios secundarios Publicación de boletines y otros documentos
Ingresar nuev o tipo de publicación Ingrese el nuevo Tipo de Publicación
Tipo de publicación que desea difundir:
...
Grabar
Descripción del documento:
Cerrar
Periodo:
Seleccionar Documento
,,,,,/NuevaPublicación.pdf
Grabar
Solo se permite documentos en formato PDF
Cerrar
Gráfico Nº 13: Pantalla de publicación de documentos
Página | 21
9.
Diagramas de Secuencia de Análisis Los diagramas de secuencia de análisis permiten identificar gráficamente cómo el Actor interactúa con la interfaz del sistema, en qué momento deberán ocurrir los cálculos complejos y las principales entidades de información que forman parte del ámbito del sistema. La simbología utilizada tiene el siguiente significado:
Clase Boundary, representa la interfaz a través de la cual el Actor interactúa con el sistema, es decir, representan a las pantallas del sistema. Clase Control, representa los cálculos propios del caso de uso. Clase Entity, representa la información usada en el sistema.
A continuación se desarrolla los diagramas de secuencia de los principales casos de uso, en términos de la notación UML, se trata de la realización de los casos de uso de sistema.
Caso de Uso Nº 001: Configurar Información a cargar al sistema sd sd Configurar Informacion
Mariell a :Especiali sta en Información del Observatori o
:Configurar Estructura de Datos
:Gestor de Estructura de datos
:Estructura de datos
:Tipo de Datos
:Nuev o Tipo de Información
:Gestor de Tipos de Información
Obti ene los T ipos de Informaci ón()
opt Sel ecci ona agregar T ipo de Informaci ón()
Habili ta el ingreso del nuevo tipo de informaci ón()
Ingresa el nuevo Ti po de Informaci ón (categoría)
El ige Aceptar()
Elige el T ipo de Información() Visualiza las variables registradas()
Ingresa el nombre de la nueva variable y su ti po de dato()
Selecciona Grabar()
Graba los datos()
Gráfico Nº 14: Diagrama de Secuencia - Configurar Información a cargar al sistema
Graba el nuevo tipo()
:Tipo de Información
Caso de Uso Nº 002: Registrar información de un registro sd sd Registrar Información de un Registro
Mariella :Especialista en Información del Observatorio
:Registrar Información
:Gestor de Registro de Información
:Gestor de Tipos de Información
:Tipo de Información
:Periodo
:Estructura de datos
Obtiene los Tipos de Información()
Obtiene los periodos()
Selecciona el Tipo de Información()
Selecciona el periodo() Carga los registros disponibles()
Elige Agregar() Habilita el ingreso de datos()
Ingresa el nuevo registro()
Presiona Grabar() Inicia las validaciones() ref Validación de Datos
Almacena la información()
Gráfico Nº 15: Diagrama de Secuencia - Registrar información de un registro
Página | 23
:Dato
Caso de Uso Nº 003: Realizar carga masiva de datos sd sd Carga Masiv a
Mariella :Especialista en Información del Observatorio
:Carga Masiv a de Datos
:Gestor de Carga Masiv a de datos
:Tipo de Información
:Periodo
:Estructura de datos
:Dato
Obtener Tipos de Información disponible()
:FormatoExcel
:Corregir problemas de v alidación
Obtener los periodos disponibles()
Buscar formato de carga masiva() Elige 'Realizar Cargar Masiva'() Obtiene los datos del formato ()
ref Validación de datos
opt Si existen registros que no pasan la v alidación Grabar registros con problemas de validación con estado 'POR VALIDAR'() Mostrar mensaje de registros con errores() Elige corregir los datos con error()
Graba los nuevos registros con estado CARGADO() Indica cantidad de registros grabados() Mensaje indicando cantidad de registros grabados()
Elige Cerrar()
Gráfico Nº 16: Diagrama de Secuencia - Realizar carga masiva de datos
Página | 24
Caso de Uso Nº 005: Realizar comparativo de datos sd sd Comparativ o de datos
:Usuario :Comparar Información por Periodo
:Gestor de Comparación
:Mostrar Reporte
:Tipo de Información
:Periodo
:Estructura de datos
:Dato
Obtiene los Tipos de Información()
Elige el Tipo de Información() Obtiene los periodos con información disponibles()
Selecciona el periodo inicial y final()
Elige la variable que desea compararse (totalizarse)
Elige una variable de corte o agrupamiento de datos()
opt Si elige Mapa de Ranking Elige mapa de ranking()
ref Mapa de Ranking
Elige 'Comparar'() Realiza los cálculos para obtener el comparativo()
Toma los datos de Población para calcular Tasas() Muestra el reporte()
opt Si elige la opción 'Exportart a Excel' Elige la opción ‘Exportar a Excel’ () ref Exportar reportes
opt Si elige 'Graficar'
Elige la opción ‘Gráfica’ () ref Generar reporte gráfico
Elige 'Cerrar'()
Elige 'Cerrar'()
Gráfico Nº 17: Diagrama de Secuencia - Realizar comparativo de datos
Página | 25
:Población
Caso de Uso Nº 011: Corregir registros con problemas de validación sd sd Corregir registros con problemas de v alidaci...
Especialista :Especialista en Información del Observatorio
:Corregir problemas de v alidación
:Gestor de Correción de datos inv álidos
:Tipo de Información
:Periodo
:Estructura de datos
Obtiene los Tipos de Información ()
Elige un Tipo de Información() Obtiene los Periodos con información disponible()
Elige el periodo() Obtiene los registros en estado: POR VALIDAR()
loop Hasta elegir 'Cerrar' Elige un registro para modificar() Habilita la modificación del registro()
loop Hasta que no existan problemas de v alidación Modifica los datos mostrados()
Elige 'Grabar'() Inicia la validación de datos()
ref Validación de datos
opt Si existe problemas de v alidación Muestra mensaje con los problemas de validación()
Graba los datos modificados() opt Si selecciona Elige 'Cerrar'()
Gráfico Nº 18: Diagrama de Secuencia - Corregir registros con problemas de validación
Página | 26
:Dato
Caso de Uso Nº 012: Publicar boletines y mapas georeferenciados sd sd Publicar boletín y mapas
Mariella :Especialista en Información del Observatorio
:Publicar boletines y documentos
:Gestor de Publicación
:Nuev o Tipo de Publicación
:Gestor de Tipo de Publicación
:Periodo
:Tipo de Publicación
Obtiene los Tipo de Publicación()
Obtiene los periodos disponibles() opt Si selecciona ... Elige agregar Tipo de Publicación()
Ingresa el nuevo tipo de publicación()
Habilita el ingreso() Graba ()
Elige el Tipo de Publicación() Ingresa la descripción del documento() Elige el periodo() Busca y selecciona el documento() Elige 'Grabar'() Verifica el tamaño y tipo de documento() Realiza el uploading del archivo() Cambia el nombre del archivo() Graba la información ingresada()
Elige 'Cerrar'()
Gráfico Nº 19: Diagrama de Secuencia - Publicar boletines y mapas georeferenciados
Página | 27
:Publicación
Sección diseño Físico 10. Modelo físico de datos El modelo de datos es la representación física de los datos, permite reconocer la estructura de la base de datos del sistema. Esta estructura servirá para la generación de los scripts que permitirán la creación de la base de datos.
TipoInformacion
EstructuraDatos
Prov incia
«column» *PK CodT ipoInfo: nvarchar(5) *PK CodVariable: nvarchar(3) NomVariable: nvarchar(80) «PK» + PK_EstructuaDatos(nvarchar, nvarchar)
Departamento
«column» *PK CodT ipoInfo: nvarchar(5) DescripTipoInfo: nvarchar(70) FechaReg: datetime
«column» *PK CodPro: char(2) * NomProv: nvarchar(50)
«column» *PK CodDep: char(2) NomDep: nvarchar(50)
«PK» + PK_T ipoInformacion(nvarchar)
«PK» + PK_Provincia(char)
«PK» + PK_Departamento(char)
Distrito Dato RangoValores «column» *PK CodRango: int TipoValidacion: char(1) ValorInicial: bigint ValorFinal: bigint
TipoDato «column» *PK CodT ipo: nchar(3) * NomT ipoDato: nvarchar(50) Estado: nvarchar(3)
«PK» + PK_RangoValores(int)
«FK» + FK_CodT ipo(nchar) «PK» + PK_T ipoDato(nchar)
«column» *PK CodDist: char(2) * NomDis: nvarchar(50)
«column» ValorNum: float ValorT ext: nvarchar(200) ValorFecha: date
Usuario «column» *PK UserName: nvarchar(8) * Password: nvarchar(10) Estado: char(1)
«PK» + PK_Distrito(char)
Periodo PoblacionAnual «column» *PK CodPeriodo: nvarchar(6) Anio: nvarchar(4) Mes: nvarchar(2)
«column» *PK AnioPob: nvarchar(4) CantPoblacion: bigint
«PK» + PK_Periodo(nvarchar)
«PK» A + PK_PoblacionAnual(nvarchar)
Perfil «column» *PK CodPerfil: int NomPerfil: nvarchar(20) «PK» + PK_Perfil(int)
PermisosPerfil «column» *PK CodPerfil: nchar(3) *PK CodFunc: nvarchar(5) «PK» + PK_PermisosPerfil(nchar, nvarchar)
«PK» + PK_Usuario(nvarchar)
Funcionalidad «column» *PK CodFunc: nvarchar(5) CodPadre: nchar(4) NomFunc: nvarchar(50) Formulario: nvarchar(50) EsMenu: char(1) Posicion: int Activo: char(10) «PK» + PK_Funcionalidad(nvarchar)
Gráfico Nº 20: Modelo de datos: Diagrama Entidad - Relación
Publicacion
TipoPublicacion
«column» *PK CodPublic: nvarchar(10) * UbicDocumento: nvarchar(200) FechaReg: date EstadoPub: nchar(3)
«column» *PK CodTipoPub: int * DescT ipoPub: nvarchar(70) FechaReg: date Estado: char(3)
«PK» + PK_Publicacion(nvarchar)
«PK» + PK_TipoPublicacion(int)
11.
Detalles de las entidades del modelo físico de datos Cada una de las entidades presentada en el modelo de datos permite al Sistema la gestión de la información del Observatorio de Salud. A continuación se describen las entidades que forman parte del modelo de datos Entidad Relación presentado.
Entidad TipoInformacion «column» *PK CodTipoInfo: nvarchar(5) DescripTipoInfo: nvarchar(70) FechaReg: datetime «PK» + PK_TipoInformacion(nvarchar)
EstructuraDatos «column» *PK CodTipoInfo: nvarchar(5) *PK CodVariable: nvarchar(3) NomVariable: nvarchar(80) «PK» + PK_EstructuaDatos(nvarchar, nvarchar)
Dato «column» ValorNum: float ValorText: nvarchar(200) ValorFecha: date
Descripción Permite el registro de los tipos de información que manejaría el Sistema de Observatorio de Salud. De esta forma el software permitirá que el Observatorio de Salud pueda procesar diferentes tipos de información en el futuro. Inicialmente se configuraría el tipo de información: Muertes Violentas. Permitirá el registro de la estructura de datos que se debe gestionar para cada Tipo de Información. La estructura de datos se conforma por todas las variables que en el futuro registrarán los datos (valores). Ejemplo de las variables: Causa de muerte (Homicidio, Accidente de Tránsito o Suicidio), Distrito de ocurrencia, Fecha y hora de accidente, Sexo. Permitirá el registro de la información (valor) de cada variable que forma la Estructura de Datos. La entidad permite el registro de 3 tipos de datos: Numérico (soporta decimales), Alfanumérico y Fecha.
TipoDato «column» *PK CodTipo: nchar(3) * NomTipoDato: nvarchar(50) Estado: nvarchar(3) «FK» + FK_CodTipo(nchar)
Registrará los tipos de datos principales que manejará el sistema de información, se prevee manejar los siguientes tipo de datos: Numérico (soporta decimales), Alfanumérico y Fecha.
«PK» + PK_TipoDato(nchar)
Periodo «column» *PK CodPeriodo: nvarchar(6) Anio: nvarchar(4) Mes: nvarchar(2) «PK» + PK_Periodo(nvarchar)
Permitirá que matricular en la base de datos, los periodos: Año y Mes para los que se registrará la información.
Entidad Publicacion «column» *PK CodPublic: nvarchar(10) * UbicDocumento: nvarchar(200) FechaReg: date EstadoPub: nchar(3) «PK» + PK_Publicacion(nvarchar)
Descripción Permite registrar las publicaciones: boletines, mapas georeferenciados y otros, que serán difundidos por el Observatorio de Salud. Esta entidad permitirá almacenar una descripción de la publicación, la ubicación del archivo y su estado: Activo o Inactivo, estos dos estados filtrarán que solo los documentos ‘Activos’ pueden ser mostrados como disponibles para descargar.
TipoPublicacion «column» *PK CodTipoPub: int * DescTipoPub: nvarchar(70) FechaReg: date Estado: char(3)
Permite identificar el Tipo de Publicación que se desea publicar a través del sistema. Ejemplo de Tipos: Boletines, Mapas Georeferenciados.
«PK» + PK_TipoPublicacion(int)
PoblacionAnual «column» *PK AnioPob: nvarchar(4) CantPoblacion: bigint «PK» A + PK_PoblacionAnual(nvarchar)
Esta entidad permitirá registrar la información censada o proyectada de uno o más años. Este dato poblacional a nivel de distrito permitirá realizar los cálculos de Tasas. El registro más reciente es el que se utilizará para realizar los cálculos.
Departamento «column» *PK CodDep: char(2) NomDep: nvarchar(50) «PK» + PK_Departamento(char)
Permite el almacenamiento de los códigos de ubicación geográfica de los departamentos del Perú. Esta información será la misma que el INEI tenga disponible.
Prov incia «column» *PK CodPro: char(2) * NomProv: nvarchar(50) «PK» + PK_Provincia(char)
Permite el almacenamiento de los códigos de ubicación geográfica de los Provincias del Perú. Esta información será la misma que el INEI tenga disponible.
Distrito «column» *PK CodDist: char(2) * NomDis: nvarchar(50) «PK» + PK_Distrito(char)
Permite el almacenamiento de los códigos de ubicación geográfica de los Distritos del Perú. Esta información será la misma que el INEI tenga disponible.
Página | 30
Entidad
Descripción
Usuario «column» *PK UserName * Password Estado «PK» + PK_Usuario()
Permite mantener el registro de todos los usuarios del sistema. Debido a que existe muchas funcionalidades que solo pueden ser utilizados por un Usuario con permisos, esta entidad soportará el proceso de ingreso al sistema.
Perfil «column» *PK CodPerfil: int NomPerfil: nvarchar(20) «PK» + PK_Perfil(int)
Esta entidad permite diferenciar a los Usuarios por Grupos de tal forma que facilite la gestión de los permisos de acceso al sistema. Ejemplo de Perfil: Especialista de Información, Responsable de Observatorio, Administrador de Sistema, otros.
Funcionalidad «column» *PK CodFunc: nvarchar(5) CodPadre: nchar(4) NomFunc: nvarchar(50) Formulario: nvarchar(50) EsMenu: char(1) Posicion: int Activo: char(10)
Esta entidad permitirá registrar todas las funcionalidades del sistema. Ejemplo de funcionalidad: Realizar Carga masiva de datos, Publicar Documentos. Facilitará dar soporte a la gestión de los permisos de acceso al sistema.
«PK» + PK_Funcionalidad(nvarchar)
PermisosPerfil «column» *PK CodPerfil: nchar(3) *PK CodFunc: nvarchar(5) «PK» + PK_PermisosPerfil(nchar, nvarchar)
Esta entidad facilitará gestionar los permisos que son asignados a cada Perfil o Grupo de Usuario. En esta entidad se podrá conocer los Perfil o Grupo de Usuario que tiene acceso a las Funcionalidades del sistema.
12. Aspectos de Tecnología A continuación se sugieren algunos detalles técnicos requeridos. • •
El sistema se debe desarrollar sobre plataforma web ASP .NET. La computadora del Especialista de Información del Observatorio debería disponer de lo siguiente: o Software: MS Excel 2010. PDF995 (free) para convertir de documentos a formato PDF. gvSIG, para el procesamiento de mapas georeferenciados. Página | 31
•
Implementar un proceso de respaldo de datos: El Administrador de Sistemas debe configurar la tarea de backup de datos para que esta copia de seguridad se realice automáticamente cada fin de mes o efectuarla manualmente posterior a la carga de datos en el sistema. La copia de seguridad debe ser grabada en medio magnético (CD/DVD) indicando la fecha y hora y luego ser almacenada dentro de un estuche cerrado en un espacio de acceso controlado. Es posible que para el mapa de ranking sea necesario adquirir algunos servicios adicionales de Google Maps.
Servicio de Hosting y Dominio:
El servicio de Hosting y Dominio, deberán tener alta capacidad en almacenamiento y de servicios proveidos. En el servidor de datos o servicio hosting debe encontrarse disponible MS SQL Server 2008, Internet Information Server (las licencias siempre son responsabilidad del servicio de hosting). Estos servicios (Hosting y Dominio) se pueden adquirir pagando el servicio a través del internet y pueden ser adquiridos en uno o en diferentes proveedores de servicio. Se sugiere que el costo de estos servicios deba ser cancelados anualmente.
Página | 32
Glosario de Términos ML:
Municipalidad de Lima
UML:
The Unified Modeling Language™, es una notación gráfica para visualizar, especificar, construir y documentar un sistema.
IML:
Instituto de Medicina Legal
CUN:
Caso de Uso de Negocio, es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso.
Actor de Negocio: Un actor es cualquier entidad externa al sistema que mantiene una relación con ésta y es para quién se realiza el Caso de Uso de Negocio. Business Worker:
Es un actor interno del sistema que está involucrado directamente en las tareas o las realiza.
CUS:
Caso de Uso de Sistema, es la abstracción de una parte del sistema y muestra un proceso especifico del mismo. Este define una secuencia de acciones que el sistema realiza para un actor en particular.
Hosting:
Servicio web que permite el alojamiento de un portal web y que dispone de los servicios necesarios para su correcto funcionamiento.
Dominio:
Servicio web que permite identificar mediante un nombre (URL) a un portal web y facilita su ubicación en la internet. Ejemplo: www.reniec.gob.pe
Página | 33
Referencias Publicaciones y Documentos: •
Data systems: a road safety manual for decision-makers and practitioners. World Health Organization 2010.
•
Proyecto Observatorio de la Violencia de la Municipalidad de la Victoria, Junio 2010, Dr. Hernán Málaga
Portales webs de Observatorios de Salud: •
Observatorio de salud en Asturias: http://www.obsaludasturias.com/obsa/ http://www.obsaludasturias.com/obsa/determinantes/
•
Global Health Observatory Data Repository. World Health Organization http://apps.who.int/ghodata/
Página | 34
Anexos ANEXO Nº 1: MATRIZ DE AUTOMATIZACIÓN PROCESO DE NEGOCIO: PROCESAMIENTO DE LA INFORMACIÓN PARA EL OBSERVATORIO DE SALUD ¿Es Actividades Responsable Requerimientos del Sistema Automatizable? Miembro del Remite información de No Observatorio de Muertes Violentas Salud El sistema debe permitir matricular el tipo de información que debe almacenar y procesar el sistema del Observatorio de Salud. Por ejemplo: Muertes Violentas. El Sistema debe permitir configurar la estructura de datos que soportará cada Tipo de Información, es decir, matricular cada variable que debe registrar datos. Recibe y almacena la información en una carpeta
Si
Especialista de Información
El sistema debe permitir que la información pueda ser cargada a la base de datos en dos formas: un caso a la vez o de forma masiva a través de un formato estándar en Excel. Estos dos procesos deben permitir la validación de los datos y en el caso de la carga masiva debe realizar la aprobación de los datos a cargar. El sistema debe realizar la validación de los datos que serán cargados al sistema tomando en cuenta lo siguiente: verificar la existencia de duplicados, verificar incongruencias entre variables, validar los rangos
CUS *
Configurar Información a cargar
Registrar información de un registro Realizar carga masiva de datos Realizar validación de datos.
ANEXO Nº 1: MATRIZ DE AUTOMATIZACIÓN PROCESO DE NEGOCIO: PROCESAMIENTO DE LA INFORMACIÓN PARA EL OBSERVATORIO DE SALUD ¿Es Actividades Responsable Requerimientos del Sistema Automatizable? válidos.
Realiza un comparativo de las tendencias de muertes violentas
Si
Especialista de Información
El sistema debe permitir corregir en pantalla los registros con problemas de validación. El sistema debe proveer en Excel el formato de carga masiva de información con la estructura de datos para cada Tipo de Información El sistema debe permitir seleccionar los periodos (mes y año) a comparar, asimismo debe permitir seleccionar la variable que desea compararse, seleccionar la variable de corte y realizar los cálculos necesarios para realizar la comparación. El sistema debe permitir obtener los reportes indicados en el Anexo Nº 3: Reportes del Sistema del Observatorio de Salud. El sistema debe permitir incluir en los reportes información de las Tasas sobre la población total, para ello debe utilizar la información de la población total proyectada o censada del año. El sistema debe permitir mostrar en un mapa el ranking de los distritos, con respecto a una variable evaluada. El valor del ranking de un distrito debe mostrarse pintando al distrito con una intensidad diferente de un color.
CUS *
Corregir registros con problemas de validación Descargar formato de carga masiva
Realizar reportes comparativo de datos
Obtener mapa de ranking
Página | 36
ANEXO Nº 1: MATRIZ DE AUTOMATIZACIÓN PROCESO DE NEGOCIO: PROCESAMIENTO DE LA INFORMACIÓN PARA EL OBSERVATORIO DE SALUD ¿Es Actividades Responsable Requerimientos del Sistema Automatizable? Obtiene reportes Especialista de El sistema debe permitir la exportación de los Si comparativos en cuadros Información resultados obtenidos a un formato de excel. El sistema debe permitir mostrar gráficas de Obtiene gráficas de Especialista de tendencias a partir de los resultados obtenidos. Para Si tendencias Información ello solo debe indicarse que la variable de corte puede ser usada en la línea de abscisa. Especialista de Elabora un boletín mensual No Información Entrega boletín a Jefa de Responsable del El sistema debe permitir aprobar la difusión de los División y Sub Gerencia de Si Observatorio de datos y resultados del mes. Laboratorio Salud El sistema debe permitir subir y publicar en el sitio web Difusión de boletines y Especialista de los boletines y los mapas obtenidos durante el mapas georeferenciados Si Información procesamiento de datos georeferenciados con el obtenidos desde el gvSIG. gvSIG. * CUS: Caso de Uso de Sistema
CUS * Exportar reportes comparativos Generar reportes gráficos
Aprobar la difusión de los resultados Publicar boletines y mapas georeferenciados.
Página | 37
ANEXO Nº 2: MATRIZ DE TRAZABILIDAD
RF04
CUS008
CUS009
CUS010
Exportar reportes comparativos
Generar reportes gráficos
Aprobar la difusión de los resultados
Obtener mapa de ranking
Validar datos cargados
x
x
CUS011
CUS012 Publicar boletines y mapas georeferenciad
CUS007
Corregir registros con problemas de validación
CUS006
Realizar reportes comparativo de datos
RF03
CUS005
Descargar formato de carga masiva
RF02
El sistema debe permitir matricular el tipo de información que debe almacenar y procesar el sistema del Observatorio de Salud. Por ejemplo: Muertes Violentas. El Sistema debe permitir configurar la estructura de datos que soportará cada Tipo de Información, es decir, matricular cada variable que debe registrar datos. El sistema debe permitir que la información pueda ser cargada a la base de datos en dos formas: un caso a la vez o de forma masiva a través de un formato estándar en Excel. Estos dos procesos deben permitir la validación de los datos y en el caso de la carga masiva debe realizar la aprobación de los datos a cargar. El sistema debe realizar la validación de los datos que serán cargados al sistema tomando en cuenta lo siguiente: verificar la existencia de duplicados, verificar incongruencias entre variables, validar los rangos
CUS004
Realizar carga masiva de datos
RF01
Requerimientos funcionales del sistema
CUS003
Registrar información de un registro
Cód. Req.
CUS002
Configurar Información a cargar
Casos de Uso de Sistema CUS001
x x
x
Página | 38
CUS006
CUS007
CUS008
CUS009
CUS010
Descargar formato de carga masiva
Realizar reportes comparativo de datos
Exportar reportes comparativos
Generar reportes gráficos
Aprobar la difusión de los resultados
Obtener mapa de ranking
Validar datos cargados
CUS011
CUS012 Publicar boletines y mapas georeferenciad
CUS005
Corregir registros con problemas de validación
CUS004
Realizar carga masiva de datos
Requerimientos funcionales del sistema
CUS003
Registrar información de un registro
Cód. Req.
CUS002
Configurar Información a cargar
Casos de Uso de Sistema CUS001
válidos.
RF05
RF06
RF07
RF08
RF09
El sistema debe permitir corregir en pantalla los registros con problemas. El sistema debe proveer en Excel el formato de carga masiva de información con la estructura de datos para cada Tipo de Información El sistema debe permitir seleccionar los periodos (mes y año) a comparar, asimismo debe permitir seleccionar la variable o variables que desea compararse, seleccionar la variable de corte y realizar los cálculos necesarios para realizar la comparación. El sistema debe permitir obtener los reportes indicados en el Anexo Nº 3: Reportes del Sistema del Observatorio de Salud. El sistema debe permitir incluir en los reportes información de las Tasas sobre la población total, para ello debe utilizar la información de la población total proyectada o censada del año.
x x
x
x x
Página | 39
RF10
RF11
RF12
RF13
RF14
El sistema debe permitir la exportación de los resultados obtenidos a un formato de excel. El sistema debe permitir mostrar gráficas de tendencias a partir de los resultados obtenidos. Para ello solo debe indicarse que la variable de corte puede ser usada en la línea de abscisa. El sistema debe permitir aprobar la difusión de los datos y resultados del mes. El sistema debe permitir mostrar en un mapa el ranking de los distritos, con respecto a una variable evaluada. El valor del ranking de un distrito debe mostrarse pintando al distrito con una intensidad diferente de un color. El sistema debe permitir subir y publicar en el sitio web los boletines y los mapas obtenidos durante el procesamiento de datos georeferenciados con el gvSIG.
CUS006
CUS007
CUS008
CUS009
CUS010
Descargar formato de carga masiva
Realizar reportes comparativo de datos
Exportar reportes comparativos
Generar reportes gráficos
Aprobar la difusión de los resultados
Obtener mapa de ranking
Validar datos cargados
CUS011
CUS012 Publicar boletines y mapas georeferenciad
CUS005
Corregir registros con problemas de validación
CUS004
Realizar carga masiva de datos
Requerimientos funcionales del sistema
CUS003
Registrar información de un registro
Cód. Req.
CUS002
Configurar Información a cargar
Casos de Uso de Sistema CUS001
x x x x
x
Página | 40
ANEXO Nº 3: REPORTES DEL SISTEMA DEL OBSERVATORIO DE SALUD El siguiente listado son los reportes que debe permitir obtener el Sistema del Observatorio de Salud, los mismos que fueron obtenidos boletín preparado por la División de Laboratorio y Prevención de Zoonosis: Muertes Violentas 1. Muertes violentas por lesiones de causa externa, según presencia o no de alcohol. 2. Muertes violentas, según día de la semana y presencia de alcohol 3. Muertes violentas, según hora del día y presencia de alcohol Muerte por accidente de tránsito: 4. 5. 6. 7. 8. 9. 10. 11. 12.
Muertes en accidentes de tránsito, según sexo Muertes en accidentes de tránsito, según edad Cadáveres alcoholizados de muertos en accidentes de tránsito Cadáveres alcoholizados de varones muertos en accidentes de tránsito Muertes en accidentes de tránsito, según estado civil Muertes en accidentes de tránsito, según día de la semana y presencia de alcohol Muertes en accidentes de tránsito, según edad y presencia de alcohol Muertes en accidentes de tránsito, según lugar de domicilio Muertes en accidentes de tránsito, según lugar de ocurrencia
Muertes por suicidios: 13. 14. 15. 16. 17. 18. 19. 20. 21.
Suicidios según sexo Suicidios según edad Suicidios, según presencia de alcohol Suicidios en varones, según presencia de alcohol Suicidios, según día de la semana y presencia de alcohol Suicidios, según edad y presencia de alcohol Suicidios, según estado civil Suicidios, según lugar de domicilio Suicidios, según lugar de Ocurrencia
Muertes por homicidios: 22. 23. 24. 25. 26. 27. 28. 29. 30.
Homicidios, según sexo Homicidios, según edad Homicidios, según presencia de alcohol Homicidios en varones, según presencia de alcohol Homicidios, según día de la semana y presencia de alcohol Homicidios, según edad y presencia de alcohol Homicidios según estado civil Homicidios según lugar de domicilio Homicidios según lugar de Ocurrencia
31. El sistema de permitir obtener el reporte diario.