Hannes Rodríguez: Versión: 10-08-2012

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. Fecha y hora de ingreso

2. Sexo
3. Edad
4. Distrito domicilio
5. Grado instrucción
6. Estado civil
7. Causa de muerte: Homicidio, Accidente de Tránsito o Suicidio.
8. Distrito de ocurrencia
9. Fecha y hora de accidente
10. Grado de alcoholemia
La persona responsable en la División de Laboratorio, se encarga de procesar esta información

obteniendo los siguientes resultados:
1. Comparativos mensuales de las ocurrencias de muertes violentas: por accidentes de

tránsitos, suicidios y homicidios.
2. Gráficas de tendencia de muertes violencia según día de la semana.
3. Muertes violentas según hora del día y presencia del alcohol, por mes.
4. Gráfica de tendencia de muertes violentas según hora del día.
5. 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 recibe y almacena la

Muertes Violentas información en una
carpeta Excel con Muertes
Violentas: Mes 2
Realiza un comparativ o
de las tendencias de
Excel con Muertes
muertes v iolentas
Violentas: Mes 3
Obtiene reportes
comparativ os en cuadros
(tablas) 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
Excel con Muertes Responsable de IML

Violentas: Mes 2 Envia
Consulta
Excel con Muertes

Recepciona
Violentas: Mes 3
Especialista de
Elabora
Información
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. Fecha y hora de ingreso

2. Sexo
3. Edad
4. Distrito domicilio
5. Grado instrucción
6. Estado civil
7. Causa de muerte: Homicidio, Accidente de Tránsito o Suicidio.
8. Distrito de ocurrencia
9. Fecha y hora de accidente
10. 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) 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.
6. 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) 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.
2) 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.
3) 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.
4) 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.
5) 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
Realizar comparativ o A petición Exportar reportes
Salud
de datos «extend» comparativ os
Usuario
A petición
«extend»
Generar reportes
gráficos
Responsable del
Observ atorio de Configurar Información
Salud a cargar al sistema
Especialista en
Información del
Observ atorio
Realizar carga A petición Descargar formato

Aprobar la difusión de carga masiv a
masiv a de datos «extend»
de los resultados
Registrar
información de un Si existen problemas de
registro validación
«extend»
«include»
Publicar boletines y
mapas «include»
georeferenciados Corregir registros
con problemas de
v alidación
Realizar v alidación «include»
de datos
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
1. El Actor debe estar registrado en el sistema.
Precondiciones:
2. El Actor debe tener permisos de acceso.
1. El actor escribe su usuario y contraseña.
Flujo Básico 2. El actor presiona aceptar
3. El actor logra ingresar al sistema
Sub Flujos -
1. El nombre del usuario o contraseña no encontrada:
Flujos alternativos En el punto 2, el usuario no logra ingresar al sistema y el sistema de
mostrar un mensaje indicando el motivo.
Post condiciones 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

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.
1. El sistema obtiene los Tipos de Información disponibles.
2. El Actor selecciona el Tipo de Información.
Flujo Básico
3. El sistema muestra las variables que se encuentran registradas
4. El Actor ingresa el nombre de la nueva variable y su tipo: Numérico,
Página | 11
Nombre del CUS: Configurar Información a cargar al sistema
cadena, fecha u hora.
5. 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
Sub Flujos
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
Flujos alternativos
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.
Post condiciones 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.
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:
Grabar variable Cerrar
Lista de variables
Nombre de la variable Tipo de dato Acción
Eliminar v ariable
Eliminar Modificar
¿Eliminar variable seleccionada?

«navigate»
Si No
Gráfico Nº 6: Pantalla para Configurar Estructura de Datos
Página | 12
Nombre del CUS: Registrar información de un registro
Precondiciones: 1. El Actor está logeado en el sistema y tiene permisos para la tarea.
2. 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’.
Flujo Básico
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.
Sub Flujos 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.
-
Flujos alternativos
Post condiciones 1. Un nuevo registro de datos fue registrado en el sistema.
Registrar información
Tipo de Información:
Año Mes
Variable 1 Variable 2 Variable n :Eliminar v ariable
Valor 1 Valor 2 Valor n

¿Eliminar variable seleccionada?
Eliminar Modificar
Si No
Agregar Grabar Cerrar
Gráfico Nº 7: Pantalla para Registrar la Información
Página | 13
Nombre del CUS: Realizar carga masiva de datos
1. El Actor está logeado en el sistema y tiene permisos para la tarea.
Precondiciones:
2. El formato de carga masiva en Excel debe tener información a cargar.
2. 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
Flujo Básico
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
Sub Flujos 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.
Flujos alternativos
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
Post condiciones Se logra grabar en el sistema más de un registro de información.
Realizar carga masiv a de datos
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
Nombre del CUS: Descargar formato de carga masiva
Precondiciones:
2. Se ha seleccionado un Tipo de Información (Categoría).
1. El Actor da click sobre el botón: “Descargar formato: Carga Masiva”.
2. El sistema lee todas las variables correspondientes al tipo de
Flujo Básico información y graba los nombres de cada variable en la primera fila de
cada columna del archivo en Excel.
3. El sistema graba el formato en Excel e inicia la descarga de archivo.
Sub Flujos -
Flujos alternativos -
Post condiciones Archivo de Carga Masiva, obtenido desde la web.

Nombre del CUS: Realizar comparativo de datos
Actores: Usuario
1. El usuario está en la ventana de realizar comparativos de datos.
Precondiciones:
2. Existe información en estado: APROBADO.
2. El Actor selecciona el Tipo de Información (Categoría).
3. 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).
Flujo Básico 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
Sub Flujos
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.
Flujos alternativos
2. El sistema muestra un mensaje: “No hay registro de Tipo o Categoría
de Información”.
Página | 15
Nombre del CUS: Realizar comparativo de datos
3. El actor acepta el mensaje y se cierra la ventana actual.
Post condiciones Se obtiene un cuadro comparando los datos de dos periodos.
Comparar Información por Periodo
Indique el rango de periodos a comparar
Periodo Inicial Periodo Final
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
Nombre del CUS: Exportar reportes comparativos
Actores: Usuario
Precondiciones: Se ha efectuado exitosamente el Comparativo de datos.
1. El Actor presiona el botón ‘Exportar a Excel’.
2. El sistema apertura el objeto Excel.
Flujo Básico 3. El sistema graba todos los datos de la tabla del Comparativo en las
celdas correspondientes en la hoja de Excel.
4. El sistema graba la hoja de Excel e inicia la descarga del archivo.
Sub Flujos -
Post condiciones Se logra la descarga del archivo en formato Excel.

Nombre del CUS: Generar reportes gráficos
Actores: Usuario
Precondiciones: 1. Es necesario que se haya procesado un reporte de datos comparados
1. El Actor da click sobre el botón “Gráfica”.
2. El sistema toma los resultados del CUS005.
Flujo Básico
3. El sistema toma a la variable para ser usada en la línea de abscisa.
4. El sistema muestra las gráficas de tendencias los datos calculados.
Sub Flujos -
1. En el punto 1 del flujo básico, no existe aún datos calculados del
Flujos alternativos CUS005, el sistema muestra un mensaje: “No existen datos disponibles
para el gráfico solicitado.”
Post condiciones Se obtiene el gráfico de tendencia.
Gráfico Nº 10: Pantalla de Reporte Gráfico de Tendencia

Nombre del CUS: Aprobar la difusión de los resultados
Actores: Responsable del Observatorio de Salud
Precondiciones:
2. Existe información registrada del periodo en ESTADO: CARGADO.
Flujo Básico 1. El sistema muestra un listado de los periodos con información
Página | 17
Nombre del CUS: Aprobar la difusión de los resultados
registrada en estado: CARGADO.
2. El Actor selecciona un periodo a la vez.
3. El Actor presiona el botón ‘APROBAR DIFUSIÓN’.
4. 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.
Sub Flujos -
Post condiciones La información CARGADA en el sistema es APROBADA para su difusión.

Nombre del CUS: Obtener mapa de ranking
Actores: Usuario
1. Existe información registrada del periodo en ESTADO: APROBADO
APROBADO.
Precondiciones: 2. El Actor se encuentra en el CUS005: Realizar comparativo de datos.
3. En el reporte la variable de agrupamiento debe ser un distrito de Lima.
1. El sistema obtiene
obtiene los datos del CUS005: Realizar comparativo de datos
datos.
2. 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
Flujo Básico resto.
3. 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 -
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
Nombre del CUS: Validar datos cargados
Actores: -
1. Existe información registrada del periodo en ESTADO: POR VALIDAR.
Precondiciones:
2. Es requerido por los CUS Nº 002, 003 y 011.
1. El sistema recibe los datos del registro y Busca registros duplicados,
Flujo Básico verifica los rangos válidos para el dato, verifica incongruencias.
2. El sistema devuelve un valor indicando que el registro es correcto.
Sub Flujos -
En el paso 1: Si el sistema encuentra un valor inválido devuelve un valor
Flujos alternativos
indicando el mensaje de error.
Post condiciones La información en el sistema es validada.

Nombre del CUS: Corregir registros con problemas de validación
Precondiciones:
2. Existe información registrada del periodo en ESTADO: POR VALIDAR.
12. El Actor selecciona el Tipo de Información (Categoría).
13. 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.
Flujo Básico 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.
Sub Flujos -
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.
Flujos alternativos
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”.
Post condiciones La información CARGADA en el sistema ha sido validada por el usuario.
Página | 19
Gráfico Nº 12: Pantalla para Corregir datos con problemas de validación

Nombre del CUS: Publicar boletines y mapas georeferenciados
Precondiciones: El Actor se encuentra en el módulo de publicación
1. El Actor elige el tipo de publicación a cargar, ejemplo: Boletín o Mapas.
2. El Actor llena los recuadros ‘Descripción del documento’, ‘Periodo’.
3. El Actor da click en en la opción ‘SELECCIONAR DOCUMENTO’
4. El Actor elige un archivo en formato PDF desde su computadora.
5. El Actor elige ‘Grabar’
Flujo Básico
6. El Sistema verifica el tamaño y tipo de archivos.
7. 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
Sub Flujos 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’.
Flujos alternativos
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”
Post condiciones 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
Tipo de publicación que desea Ingrese el nuevo Tipo de Publicación

...
difundir:
Descripción del documento: Grabar Cerrar
Periodo:
Solo se permite
Seleccionar Documento ,,,,,/NuevaPublicación.pdf documentos
en formato PDF
Grabar 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 :Configurar :Gestor de :Estructura de :Tipo de Datos :Nuev o Tipo de :Gestor de Tipos :Tipo de
Observatori o Estructura de Estructura de datos Información de Información Información
Datos datos
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() Graba el

nuevo tipo()
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

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 :Registrar :Gestor de :Gestor de Tipos :Tipo de :Periodo :Estructura de :Dato
Observatorio Información Registro de de Información Información datos
Información
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
Caso de Uso Nº 003: Realizar carga masiva de datos
sd sd Carga Masiv a
Información del :Carga Masiv a de :Gestor de Carga :Tipo de :Periodo :Estructura de :Dato :FormatoExcel :Corregir
Observatorio Datos Masiv a de datos Información datos problemas de
v alidación
Obtener Tipos de
Información disponible()
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 :Gestor de :Mostrar Reporte :Tipo de :Periodo :Estructura de :Dato :Población
Información por Comparación Información datos
Periodo
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
Caso de Uso Nº 011: Corregir registros con problemas de validación
sd sd Corregir registros con problemas de v alidaci...
Especialista
:Especialista en :Corregir :Gestor de :Tipo de :Periodo :Estructura de :Dato
Información del problemas de Correción de Información datos
Observatorio v alidación datos inv álidos
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
Caso de Uso Nº 012: Publicar boletines y mapas georeferenciados
sd sd Publicar boletín y mapas
Información del :Publicar :Gestor de :Nuev o Tipo de :Gestor de Tipo de :Periodo :Tipo de :Publicación
Observatorio boletines y Publicación Publicación Publicación Publicación
documentos
Obtiene los Tipo

de Publicación()
Obtiene los
periodos
disponibles()
opt Si selecciona ...
Elige agregar Tipo de Publicación()
Habilita
el
ingreso()
Ingresa el nuevo tipo
de publicación()
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
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 Departamento
Prov incia
«column»
«column» «column» «column»
*PK CodT ipoInfo: nvarchar(5)
*PK CodT ipoInfo: nvarchar(5) *PK CodDep: char(2)
DescripTipoInfo: nvarchar(70) *PK CodPro: char(2)
*PK CodVariable: nvarchar(3) * NomProv: nvarchar(50) NomDep: nvarchar(50)
FechaReg: datetime
NomVariable: nvarchar(80)
«PK» «PK» «PK»

«PK» + PK_Departamento(char)
+ PK_T ipoInformacion(nvarchar) + PK_Provincia(char)
+ PK_EstructuaDatos(nvarchar, nvarchar)
Distrito
Dato
«column»
«column» *PK CodDist: char(2)
RangoValores
ValorNum: float * NomDis: nvarchar(50)
ValorT ext: nvarchar(200)
«column»
ValorFecha: date «PK»
*PK CodRango: int
TipoValidacion: char(1) + PK_Distrito(char)
TipoDato ValorInicial: bigint
ValorFinal: bigint
«column»
*PK CodT ipo: nchar(3) Periodo
«PK»
* NomT ipoDato: nvarchar(50) PoblacionAnual
+ PK_RangoValores(int)
Estado: nvarchar(3) «column»
*PK CodPeriodo: nvarchar(6) «column»
Anio: nvarchar(4) *PK AnioPob: nvarchar(4)
«FK»
Mes: nvarchar(2) CantPoblacion: bigint
+ FK_CodT ipo(nchar)
«PK» Usuario
«PK» «PK»
+ PK_T ipoDato(nchar) A
+ PK_Periodo(nvarchar) + PK_PoblacionAnual(nvarchar)
«column»
*PK UserName: nvarchar(8)
* Password: nvarchar(10)
Estado: char(1)
Perfil
«PK»
«column» + PK_Usuario(nvarchar) Publicacion TipoPublicacion
*PK CodPerfil: int
NomPerfil: nvarchar(20) «column» «column»
*PK CodPublic: nvarchar(10) *PK CodTipoPub: int
* UbicDocumento: nvarchar(200) * DescT ipoPub: nvarchar(70)
«PK»
Funcionalidad FechaReg: date FechaReg: date
+ PK_Perfil(int)
EstadoPub: nchar(3) Estado: char(3)
«column»
*PK CodFunc: nvarchar(5) «PK»
«PK»
CodPadre: nchar(4) + PK_Publicacion(nvarchar) + PK_TipoPublicacion(int)
NomFunc: nvarchar(50)
PermisosPerfil
Formulario: nvarchar(50)
EsMenu: char(1)
«column»
Posicion: int
*PK CodPerfil: nchar(3)
Activo: char(10)
*PK CodFunc: nvarchar(5)
«PK»
«PK»
+ PK_Funcionalidad(nvarchar)
+ PK_PermisosPerfil(nchar, nvarchar)
Gráfico Nº 20: Modelo de datos: Diagrama Entidad - Relación

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 Descripción
TipoInformacion
Permite el registro de los tipos de información que
«column» manejaría el Sistema de Observatorio de Salud. De
*PK CodTipoInfo: nvarchar(5)
DescripTipoInfo: nvarchar(70)
esta forma el software permitirá que el Observatorio
FechaReg: datetime de Salud pueda procesar diferentes tipos de
información en el futuro. Inicialmente se configuraría
«PK» el tipo de información: Muertes Violentas.
+ PK_TipoInformacion(nvarchar)
EstructuraDatos Permitirá el registro de la estructura de datos que se

«column»
debe gestionar para cada Tipo de Información. La
*PK CodTipoInfo: nvarchar(5) estructura de datos se conforma por todas las
*PK CodVariable: nvarchar(3) variables que en el futuro registrarán los datos
NomVariable: nvarchar(80)
(valores). Ejemplo de las variables: Causa de muerte
«PK» (Homicidio, Accidente de Tránsito o Suicidio), Distrito
+ PK_EstructuaDatos(nvarchar, nvarchar) de ocurrencia, Fecha y hora de accidente, Sexo.
Dato
Permitirá el registro de la información (valor) de cada
«column» variable que forma la Estructura de Datos.
ValorNum: float La entidad permite el registro de 3 tipos de datos:
ValorText: nvarchar(200)
ValorFecha: date
Numérico (soporta decimales), Alfanumérico y Fecha.
TipoDato
«column»
*PK CodTipo: nchar(3) Registrará los tipos de datos principales que manejará
* NomTipoDato: nvarchar(50)
Estado: nvarchar(3) el sistema de información, se prevee manejar los
siguientes tipo de datos: Numérico (soporta
«FK»
+ FK_CodTipo(nchar)
decimales), Alfanumérico y Fecha.
«PK»
+ PK_TipoDato(nchar)
Periodo
«column»
*PK CodPeriodo: nvarchar(6) Permitirá que matricular en la base de datos, los
Anio: nvarchar(4) periodos: Año y Mes para los que se registrará la
Mes: nvarchar(2)
información.
«PK»
+ PK_Periodo(nvarchar)
Publicacion Permite registrar las publicaciones: boletines, mapas

georeferenciados y otros, que serán difundidos por el
«column»
*PK CodPublic: nvarchar(10) Observatorio de Salud.
* UbicDocumento: nvarchar(200) Esta entidad permitirá almacenar una descripción de
FechaReg: date
EstadoPub: nchar(3)
la publicación, la ubicación del archivo y su estado:
Activo o Inactivo, estos dos estados filtrarán que solo
«PK» los documentos ‘Activos’ pueden ser mostrados
+ PK_Publicacion(nvarchar) como disponibles para descargar.
TipoPublicacion
«column»
*PK CodTipoPub: int Permite identificar el Tipo de Publicación que se desea
* DescTipoPub: nvarchar(70)
FechaReg: date publicar a través del sistema. Ejemplo de Tipos:
Estado: char(3) Boletines, Mapas Georeferenciados.
«PK»
+ PK_TipoPublicacion(int)
PoblacionAnual
Esta entidad permitirá registrar la información
«column» censada o proyectada de uno o más años. Este dato
*PK AnioPob: nvarchar(4) poblacional a nivel de distrito permitirá realizar los
CantPoblacion: bigint
cálculos de Tasas.
«PK» El registro más reciente es el que se utilizará para
+ A
PK_PoblacionAnual(nvarchar) realizar los cálculos.
Departamento
«column» Permite el almacenamiento de los códigos de

*PK CodDep: char(2) ubicación geográfica de los departamentos del Perú.
NomDep: nvarchar(50)
Esta información será la misma que el INEI tenga
«PK»
disponible.
+ PK_Departamento(char)
Prov incia

*PK CodPro: char(2) ubicación geográfica de los Provincias del Perú. Esta
* NomProv: nvarchar(50) información será la misma que el INEI tenga
«PK»
disponible.
+ PK_Provincia(char)
Distrito

*PK CodDist: char(2) ubicación geográfica de los Distritos del Perú. Esta
* NomDis: nvarchar(50)
información será la misma que el INEI tenga
«PK»
disponible.
+ PK_Distrito(char)
Página | 30
Usuario
Permite mantener el registro de todos los usuarios del
«column»
*PK UserName sistema. Debido a que existe muchas funcionalidades
* Password que solo pueden ser utilizados por un Usuario con
Estado
permisos, esta entidad soportará el proceso de
«PK»
ingreso al sistema.
+ PK_Usuario()
Perfil
Esta entidad permite diferenciar a los Usuarios por
«column»
*PK CodPerfil: int
Grupos de tal forma que facilite la gestión de los
NomPerfil: nvarchar(20) permisos de acceso al sistema. Ejemplo de Perfil:
Especialista de Información, Responsable de
«PK» Observatorio, Administrador de Sistema, otros.
+ PK_Perfil(int)
Funcionalidad
«column»
*PK CodFunc: nvarchar(5) Esta entidad permitirá registrar todas las
CodPadre: nchar(4) funcionalidades del sistema. Ejemplo de
NomFunc: nvarchar(50)
Formulario: nvarchar(50)
funcionalidad: Realizar Carga masiva de datos,
EsMenu: char(1) Publicar Documentos.
Posicion: int Facilitará dar soporte a la gestión de los permisos de
Activo: char(10)
acceso al sistema.
«PK»
+ PK_Funcionalidad(nvarchar)
PermisosPerfil
Esta entidad facilitará gestionar los permisos que son
«column» asignados a cada Perfil o Grupo de Usuario. En esta
*PK CodPerfil: nchar(3)
*PK CodFunc: nvarchar(5) entidad se podrá conocer los Perfil o Grupo de
Usuario que tiene acceso a las Funcionalidades del
«PK» sistema.
+ PK_PermisosPerfil(nchar, nvarchar)
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 CUS *
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. Configurar Información a
El Sistema debe permitir configurar la estructura de cargar
datos que soportará cada Tipo de Información, es
decir, matricular cada variable que debe registrar
datos.
Recibe y almacena la Especialista de El sistema debe permitir que la información pueda ser
Si Registrar información de
información en una carpeta Información 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 un registro
en Excel. Estos dos procesos deben permitir la
validación de los datos y en el caso de la carga masiva Realizar carga masiva de
debe realizar la aprobación de los datos a cargar. datos
El sistema debe realizar la validación de los datos que
serán cargados al sistema tomando en cuenta lo Realizar validación de
siguiente: verificar la existencia de duplicados, verificar datos.
incongruencias entre variables, validar los rangos

¿Es
Automatizable?
válidos.
El sistema debe permitir corregir en pantalla los Corregir registros con
registros con problemas de validación. problemas de validación
El sistema debe proveer en Excel el formato de carga
Descargar formato de
masiva de información con la estructura de datos para
carga masiva
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 Realizar reportes
indicados en el Anexo Nº 3: Reportes del Sistema del comparativo de datos
Realiza un comparativo de Observatorio de Salud.
Especialista de
las tendencias de muertes Si El sistema debe permitir incluir en los reportes
Información
violentas 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.
Obtener mapa de
El valor del ranking de un distrito debe mostrarse
ranking
pintando al distrito con una intensidad diferente de un
color.
Página | 36

¿Es
Automatizable?
Obtiene reportes Especialista de El sistema debe permitir la exportación de los Exportar reportes
Si
comparativos en cuadros Información resultados obtenidos a un formato de excel. comparativos
El sistema debe permitir mostrar gráficas de
Obtiene gráficas de Especialista de tendencias a partir de los resultados obtenidos. Para Generar reportes
Si
tendencias Información ello solo debe indicarse que la variable de corte puede gráficos
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 Aprobar la difusión de
División y Sub Gerencia de Si Observatorio de
datos y resultados del mes. los resultados
Laboratorio Salud
El sistema debe permitir subir y publicar en el sitio web
Difusión de boletines y Publicar boletines y
Especialista de los boletines y los mapas obtenidos durante el
mapas georeferenciados Si mapas
Información procesamiento de datos georeferenciados con el
obtenidos desde el gvSIG. georeferenciados.
gvSIG.
* CUS: Caso de Uso de Sistema
Página | 37
ANEXO Nº 2: MATRIZ DE TRAZABILIDAD
Casos de Uso de Sistema

CUS001 CUS002 CUS003 CUS004 CUS005 CUS006 CUS007 CUS008 CUS009 CUS010 CUS011 CUS012
masiva de datos
comparativo de
georeferenciad
información de
difusión de los
Obtener mapa
Realizar carga
Información a
problemas de
comparativos
registros con
Validar datos
carga masiva
Cód. Requerimientos funcionales del
formato de
un registro
boletines y
Configurar
de ranking
Aprobar la
resultados
Descargar
validación
Registrar
cargados
Exportar
reportes
reportes
reportes
Corregir
Generar
Publicar
gráficos
Realizar
Req. sistema
mapas
cargar
datos
El sistema debe permitir matricular
el tipo de información que debe
RF01 almacenar y procesar el sistema del
Observatorio de Salud. Por ejemplo:
x
Muertes Violentas.
El Sistema debe permitir configurar
la estructura de datos que
RF02 soportará cada Tipo de Información,
es decir, matricular cada variable
x
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
RF03
Excel. Estos dos procesos deben x x
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
RF04
siguiente: verificar la existencia de x
duplicados, verificar incongruencias
entre variables, validar los rangos
Página | 38
masiva de datos
comparativo de
georeferenciad
información de
difusión de los
Obtener mapa
Realizar carga
Información a
comparativos
problemas de
registros con
carga masiva
Validar datos
formato de
un registro
boletines y
Configurar
de ranking
Aprobar la
resultados
Descargar
validación
Registrar
cargados
Exportar
reportes
reportes
reportes
Corregir
Generar
Publicar
gráficos
Realizar
Req. sistema
mapas
cargar
datos
válidos.
El sistema debe permitir corregir en

RF05 pantalla los registros con
problemas.
x
El sistema debe proveer en Excel el
formato de carga masiva de
RF06 información con la estructura de
datos para cada Tipo de
x
Información
El sistema debe permitir seleccionar
los periodos (mes y año) a
comparar, asimismo debe permitir
seleccionar la variable o variables
RF07
que desea compararse, seleccionar x
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º
RF08
3: Reportes del Sistema del x
Observatorio de Salud.
El sistema debe permitir incluir en
los reportes información de las
Tasas sobre la población total, para
RF09
ello debe utilizar la información de x
la población total proyectada o
censada del año.
Página | 39
masiva de datos
comparativo de
georeferenciad
información de
difusión de los
Obtener mapa
Realizar carga
Información a
comparativos
problemas de
registros con
carga masiva
Validar datos
formato de
un registro
boletines y
Configurar
de ranking
Aprobar la
resultados
Descargar
validación
Registrar
cargados
Exportar
reportes
reportes
reportes
Corregir
Generar
Publicar
gráficos
Realizar
Req. sistema
mapas
cargar
datos
El sistema debe permitir la
RF10 exportación de los resultados
obtenidos a un formato de excel.
x
El sistema debe permitir mostrar
gráficas de tendencias a partir de
los resultados obtenidos. Para ello
RF11
solo debe indicarse que la variable x
de corte puede ser usada en la línea
de abscisa.
El sistema debe permitir aprobar la
RF12 difusión de los datos y resultados
del mes.
x
El sistema debe permitir mostrar en
un mapa el ranking de los distritos,
con respecto a una variable
RF13 evaluada. El valor del ranking de un
distrito debe mostrarse pintando al
x
distrito con una intensidad diferente
de un color.
El sistema debe permitir subir y
publicar en el sitio web los boletines
RF14 y los mapas obtenidos durante el
procesamiento de datos
x
georeferenciados con el gvSIG.
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. Muertes en accidentes de tránsito, según sexo

5. Muertes en accidentes de tránsito, según edad
6. Cadáveres alcoholizados de muertos en accidentes de tránsito
7. Cadáveres alcoholizados de varones muertos en accidentes de tránsito
8. Muertes en accidentes de tránsito, según estado civil
9. Muertes en accidentes de tránsito, según día de la semana y presencia de alcohol
10. Muertes en accidentes de tránsito, según edad y presencia de alcohol
11. Muertes en accidentes de tránsito, según lugar de domicilio
12. Muertes en accidentes de tránsito, según lugar de ocurrencia
Muertes por suicidios:
13. Suicidios según sexo

14. Suicidios según edad
15. Suicidios, según presencia de alcohol
16. Suicidios en varones, según presencia de alcohol
17. Suicidios, según día de la semana y presencia de alcohol
18. Suicidios, según edad y presencia de alcohol
19. Suicidios, según estado civil
20. Suicidios, según lugar de domicilio
21. Suicidios, según lugar de Ocurrencia
Muertes por homicidios:
22. Homicidios, según sexo

23. Homicidios, según edad
24. Homicidios, según presencia de alcohol
25. Homicidios en varones, según presencia de alcohol
26. Homicidios, según día de la semana y presencia de alcohol
27. Homicidios, según edad y presencia de alcohol
28. Homicidios según estado civil
29. Homicidios según lugar de domicilio
30. Homicidios según lugar de Ocurrencia
31. El sistema de permitir obtener el reporte diario.

Hannes Rodríguez: Versión: 10-08-2012

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Hannes Rodríguez: Versión: 10-08-2012

Transféré par

Droits d'auteur :

Formats disponibles

Documento de Análi

Sección: Requerimientos del Sistema ..................................................................................... 3

1. Alcance del documento:

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

La Sub Gerencia de Sanidad, requiere implementar el Sistema Informático Observatorio de Salud,

Diagrama de Caso de Uso de Negocio (CUN)

uc Modelo de Casos de Uso de Negocio

Gráfico Nº 1: Diagrama de Caso de Uso de Negocio (CUN)

A continuación se describe las actividades que involucran el CUN: Procesamiento de la Información

Actualmente, la Sub Gerencia de Sanidad, a través de su División de Laboratorio y Prevención de

1. Fecha y hora de ingreso

La persona responsable en la División de Laboratorio, se encarga de procesar esta información

1. Comparativos mensuales de las ocurrencias de muertes violentas: por accidentes de

CUN: Procesamiento Actual de la Información para el Observatorio de Salud

act Act Procesamiento de Informacion

Resposable de IML Especialista de Información

Remite información de recibe y almacena la

Entrega boletin a Jefa de

Gráfico Nº 2: Diagrama de Secuencia del Procesamiento de la Información para el Observatorio de Salud

class cls Procesamiento

Excel con Muertes Responsable de IML

Excel con Muertes

Elabora Tablas comparativas de

Gráfico Nº 3: Diagrama de Clases de Negocio

1. Fecha y hora de ingreso

El Instituto de Medicina Legal es la fuente de información actualmente activa, ya que remite su

• El Instituto de Medicina Legal

Propuesta de carga de información al sistema

Para esta parte considero conveniente citar lo siguiente:

El Sistema Informático del Observatorio de Salud permitirá almacenar y procesar la información

• El Instituto de Medicina Legal.

5. Identificación de usuario, roles

c) Especialista de Información del Observatorio de Salud de la Sub Gerencia de Sanidad, encarga do

6. Requerimientos del sistema

Facilidad de uso de la Información

7. Diagrama de Casos de Uso de Sistema

uc Modelo de casos de uso

Ingresar al sistema Obtener mapa de

Realizar carga A petición Descargar formato

Gráfico Nº 4: Diagrama de Casos de Uso de Sistema

Código del CUS CUS000

custom Formularios principales

Gráfico Nº 5: Pantalla de ingreso al sistema

Código del CUS CUS001

custom Formularios principales

Configurar Estructura de Datos

Nuev o Tipo de Información

Grabar variable Cerrar

Nombre de la variable Tipo de dato Acción

¿Eliminar variable seleccionada?

Gráfico Nº 6: Pantalla para Configurar Estructura de Datos

Post condiciones 1. Un nuevo registro de datos fue registrado en el sistema.

custom Formularios principales

Variable 1 Variable 2 Variable n :Eliminar v ariable

Valor 1 Valor 2 Valor n

Agregar Grabar Cerrar

Gráfico Nº 7: Pantalla para Registrar la Información

custom Formularios principales

Realizar carga masiv a de datos

Descargar Formato de Carga Masiva

Seleccionar archivo de carga masiva con datos ...

Realizar Carga Masiva