75.10 TECNICAS DE DISEÑO

TRABAJO PRACTICO

MIKLOLIFE

GRUPO	2

AYUDANTE	Daniel Tomaszevski

CUATRIMESTRE	2005 - 1

INTEGRANTES

Apellido	Nombre	E-mail	Padrón
Castagnino	Florencia	florcastagnino@gmail.com	79504
Dimov	Nicolás	nicodimov@yahoo.com	77624
Lavena	Sebastián	sjlavena@gmail.com	78767
Lucarella	Leandro	luca-7510@llucax.hn.org	77891
Marcet	Diego	dmarcet@fi.uba.ar	78862
Markiewicz	Ricardo	rmarkie@fi.uba.ar	78226
Mazzitelli	Lautaro	lmazzitelli@gmail.com	77020
Pérez	María Florencia	maryflowerp@yahoo.com.ar	79357
Rugilo	Guillermo	guillerugilo@yahoo.com.ar	78439
Sosa	Julián	jsosa@certant.com	81135

Índice de contenido

1. Modelo de clases	1

1.1. Identificación de actores	1

1.1.1. Operador	1

1.1.2. Promotor	1

1.1.3. Enrutador	1

1.1.4. Prestador	1

1.1.5. Cobranzas	1

1.1.6. Pagos	1

1.1.7. Auditor Médico	2

1.1.8. Director	2

1.1.9. Ministerio	2

1.1.10. Administrador	2

1.1.11. Dpto. Servicios Al Cliente	2

1.2. Identificación de casos de uso	2

1.2.1. Funcionalidades	2

1.2.1.1. Paquete Administración	2

1.2.1.2. Paquete Autorizaciones	2

1.2.1.3. Paquete Reportes	3

1.2.1.4. Paquete interacción con promotor	3

1.2.1.5. Paquete interacción con cobranzas	3

1.2.1.6. Paquete interacción con prestadores	3

1.2.1.7. Paquete interacción con clientes	3

1.3. Especificación de casos de uso	4

1.3.1. Actualizar morosos	4

1.3.2. Armar cartilla	4

1.3.3. Ingresar solicitud	4

1.3.4. Agregar Afiliado	4

1.3.5. Mantener promotores	4

1.3.6. Pedir autorización manual	4

1.3.7. Registrar visitas	4

1.3.8. Emitir hoja de ruta	4

1.3.9. Mantener prestadores	4

1.3.10. Recibir y cotejar consumos y prestaciones	4

1.3.11. Pedir autorización automática	4

1.3.12. Atender consulta afiliado	4

1.3.13. Mantener CAPs	4

1.3.14. Actualizar autorización manual	4

1.3.15. Generar reporte autorizaciones rechazadas	4

1.3.16. Generar reporte prestaciones con deuda	4

1.3.17. Generar reporte porcentaje rechazos	4

1.3.18. Mantener planes	4

1.3.19. Mantener prestaciones	4

1.3.20. Mantener afiliados	4

1.3.21. Eliminar afiliado	4

1.3.22. Modificar afiliado	4

1.3.23. Consultar autorizaciones	4

1.3.24. Enviar información carnets	5

1.3.25. Consultar cobertura online	5

1.3.26. Solicitar autorización automática online	5

1.4. Especificación de clases	5

1.5. Diagrama de casos de uso	6

1.6. Diagramas paquetes	7

1.6.1. Diagrama de arquitectura general del sistema	7

1.6.2. Diagrama de paquete de dominio	8

1.6.3. Diagrama de paquete de control	9

1.6.4. Diagrama de paquete de reportes	10

1.7. Diagramas de clases	11

1.7.1. Diagrama de clases de dominio	11

1.7.2. Diagrama de relación de clases de dominio	12

1.7.3. Diagrama de clases de control	13

1.7.4. Diagrama de clases de persistencia	14

2. Diseño de la base de datos	15

2.1. Diagrama de tablas	15

2.2. Diccionario de datos	16

2.2.1. Composición física de las tablas	16

2.2.2. Diccionario de datos de las tablas	19

2.2.3. Diccionario de datos de los atributos	21

Descripción	21

2.3. Mapeo de clases de entidad	24

Clase.atributo	24

2.4. Reglas de integridad referencial	27

2.5. Análisis del volumen de datos	35

2.5.1. Espacio estimado	36

2.6. Criterios de depuración	37

3. Alcance del Software	40

3.1. Diagrama de alcance	41

4. Funciones complementarias al Software	42

4.1. Importación inicial de datos	42

4.2. Cruzar el reporte de consumo contra el reporte de aprobación/rechazo de prestaciones realizadas	42

4.3. Revisar archivos rechazados del Prestador por formato incorrecto	42

4.4. Armado de hoja de ruta	42

4.5. Entrega al promotor de planes a ofrecer a solicitantes	43

4.6. Entrega de formularios de carga de solicitantes	43

4.7. Confección y reparto de carnets de afiliados	43

4.8. Impresión y reparto de Cartilla médica	43

4.9. Pagos de los afiliados	43

5. Diseño de interfaces	44

5.1. Interfaces con el usuario	44

5.1.1. Modelo de diálogo	44

5.1.2. Diseño de pantallas	44

5.1.3. Diseño de listados	44

5.1.3.1. Hoja de ruta	44

5.1.3.2. Formulario de carga de familiares	44

5.2. Interfaces con otros sistemas	44

5.2.1. Cartilla médica	44

5.3. Interfaces con otros sistemas interactivos	44

6. Modelo de procesamiento	45

6.1. Ciclo del procesamiento	45

6.1.1. Línea de tiempo diaria	45

6.1.2. Línea de tiempo mensual	46

6.1.3. Línea de tiempo anual	46

6.2. Esquema del procesamiento	47

7. Especificación de lanzamiento de tareas	48

8. Diseño y lanzamiento de tareas batch	51

8.1. Tareas	51

8.1.1. Emisión de reporte de autorizaciones rechazadas	51

8.1.1.1. Composición	51

8.1.1.2. Ejecución	51

8.1.1.3. Condiciones previas	51

8.1.1.4. Puntos de control	51

8.1.1.5. Contingencias	51

8.1.2. Emisión de reporte de prestaciones con deuda	52

8.1.2.1. Composición	52

8.1.2.2. Ejecución	52

8.1.2.3. Condiciones previas	52

8.1.2.4. Puntos de control	52

8.1.2.5. Contingencias	53

8.1.3. Emisión de reporte de porcentaje de rechazo de solicitudes	53

8.1.3.1. Composición	53

8.1.3.2. Ejecución	53

8.1.3.3. Condiciones previas	53

8.1.3.4. Puntos de control	54

8.1.3.5. Contingencias	54

8.1.4. Procesar consumos y prestaciones	54

8.1.4.1. Composición	54

8.1.4.2. Ejecución	54

8.1.4.3. Condiciones previas	54

8.1.4.4. Puntos de control	55

8.1.4.5. Contingencias	55

8.1.5. Actualizar estado de morosidad de afiliados	55

8.1.5.1. Composición	55

8.1.5.2. Ejecución	55

8.1.5.3. Condiciones previas	55

8.1.5.4. Puntos de control	56

8.1.5.5. Contingencias	56

8.1.6. Enviar información carnets	56

8.1.6.1. Composición	56

8.1.6.2. Ejecución	56

8.1.6.3. Condiciones previas	56

8.1.6.4. Puntos de control	57

8.1.6.5. Contingencias	57

8.1.7. Depuración	57

8.1.7.1. Composición	57

8.1.7.2. Ejecución	57

8.1.7.3. Condiciones previas	57

8.1.7.4. Puntos de control	57

8.1.7.5. Contingencias	57

8.1.8. Backup de Base de Datos	57

8.1.8.1. Composición	57

8.1.8.2. Ejecución	58

8.1.8.3. Condiciones previas	58

8.1.8.4. Puntos de control	58

8.1.8.5. Contingencias	58

8.2. Nota sobre el control de contingencias de tareas	58

9. Diseño de la arquitectura de procesamiento	59

9.1. Arquitectura física	59

9.2. Modalidad de procesamiento	59

9.3. Diseño funcional	59

10. Especificación de tecnología	60

10.1. Hardware Requerido	60

10.2. Software Requerido	61

10.3. Estaciones de Trabajo	61

10.4. Servidores	61

10.4.1. Servidor stand-alone primario	61

10.4.2. Servidor stand-alone secundario	61

10.4.3. Cluster DB	62

10.4.4. Cluster Directorio	62

11. Modelo de instalación de componentes	63

11.1. Mapa de instalación	63

11.2. Configuración de entorno	63

11.2.1. Estación de trabajo consultas	63

11.2.2. Estación de trabajo recepción	63

11.2.3. Estación de trabajo administración	63

11.2.4. Estación de trabajo director	63

11.2.5. Estación de trabajo técnico	63

11.3. Webserver	63

11.4. Dataserver	63

11.5. Servidor de red	63

12. Diseño conceptual del menú	64

12.1. Estructura elegida	64

12.2. Forma de agrupamiento	64

12.3. Opciones del menú	64

13. Diseño conceptual de seguridad	65

13.1. Introducción – Conceptos Básicos	65

13.2. Infraestructura Física	65

13.3. Infraestructura Lógica	66

13.3.1. Infraestructura de usuarios, y grupos y perfil en base a roles	66

13.3.2. Vínculo hacia la aplicación – Propagación de perfiles según roles	68

13.3.3. Ambiente interno	68

13.3.4. Ambiente externo	69

13.3.5. Conclusión	70

13.4. Enlace	70

13.5. Seguridad frente a accesos externos e internos	70

13.6. Backups	71

13.7. Auditoría	72

13.7.1. Servers y software de base	72

13.7.2. Aplicación	72

13.8. Seguridad dentro de la aplicación	72

13.9. Detección de intrusiones	72

13.10. Glosario de términos para los estandares utilzados	73

14. Diseño de la implementación del menú y seguridad de acceso	76

15. Anexos	77

15.1. Estándares de diseño de interfaces	77

15.2. Informe de evolución del diseño	77

15.3. Planificación de la exposición	77

Modelo de clases

Identificación de actores

Tomando como herramienta de especificación a los “casos de uso”, comenzamos la confección de dicho modelo por la identificación de los actores y sus objetivos frente al sistema. Para el caso de nuestro sistema, los actores son:

Operador

Es el intermediario entre los afiliados y el sistema.

Se encarga de:

atender consultas por parte de los afiliados respecto a la obra social;

ingresar en el sistema datos de solicitantes que quieran afiliarse;

recibir solicitudes personales de autorizaciones manuales y darlas de alta en el sistema;

atender consultas por parte de los afiliados respecto a las prestaciones que realizaron y autorizaciones emitidas a los mismos;

dar de alta afiliados al sistema a partir de los datos de los solicitantes y la interacción con el caso de uso correspondiente;

Promotor

Es el encargado de entrevistar a posibles afiliados de la obra social. Recibe una hoja de ruta con los solicitantes a visitar, un listado que permite la carga de los datos de los afiliados (ref. modelo 5: listado de carga de solicitantes). Registra en el sistema las visitas que pudo o no realizar y los solicitantes que serán afiliados al sistema por parte del operador así como también los datos de los familiares a afiliar.

Enrutador

Es el encargado de confeccionar una hoja de ruta con solicitantes que debe visitar un Promotor en base a los datos brindados por el sistema.

Prestador

Es el actor al cual la obra social debe retribuirle monetariamente por las prestaciones realizadas a los afiliados de la obra social. Puede ser una organización o un profesional particular. Envía un listado con las prestaciones realizadas a los afiliados del sistema.También puede solicitar una autorización automática online y/o consultar coberturas de los afiliados de la misma forma.

Cobranzas

Este actor informa a la obra social que afiliados son morosos y cuantos meses adeudan.

Pagos

Es el área de la Obra Social encargada de pagarle el porcentaje de la prestación cubierto del afiliado al prestador. Recibe un reporte detallado de lo que tiene que abonar.

Auditor Médico

Es un profesional (médico) que se encarga de evaluar la autorización de las autorizaciones manuales que son pedidas a la obra social por parte de los prestadores y/o afiliados.

Director

Drector de la obra social. Se le envían reportes periódicamente.

Ministerio

Ministerio de Salud. Se le envían reportes periódicamente.

Administrador

Es el encargado de:

mantener planes, prestadores, caps, promotores, prestaciones y afiliados. Con mantener nos referimos a alta, baja y modificación de los mismos, excepto en el caso de los afiliados donde solo puede modificar los datos del mismo o darlo de baja en el sistema.

Realizar el armado de la cartilla de un plan del sistema a partir del caso de uso correspondiente

Dpto. Servicios Al Cliente

Departamento encargado de la impresión y el envío tanto de carnets como de cartillas médicas a los afiliados.

Identificación de casos de uso

Funcionalidades

Paquete Administración

Mantener Afiliados: maneja el ABM de los afiliados en el sistema;

Modificar Afiliado: maneja la modificación de datos de un afiliado en el sistema;

Eliminar Afiliado: maneja la baja de un afiliado en el sistema;

Mantener Planes: maneja el ABM de los planes del sistema;

Mantener Prestaciones: maneja el ABM de las prestaciones en el sistema;

Mantener Promotores: maneja el ABM de los promotores en el sistema;

Mantener CAPS: maneja el ABM de los caps en el sistema;

Mantener Prestadores: maneja el ABM de los prestadores en el sistema;

Armar cartilla: de acuerdo al plan ingresado se arma un listado con la descripción del mismo y la cobertura correspondiente a cada prestación que abarca;

Paquete Autorizaciones

Actualizar autorización manual: se actualiza el estado de la autorización manual estableciendo su aprobación o rechazo;

Solicitar Autorización automática online: se carga en el sistema una autorización automática de manera online (webservice);

Pedir Autorización automática: se carga en el sistema una autorización automática de forma manual (a través de un operador);

Pedir Autorización manual: se carga en el sistema una autorización manual;

Consultar autorizaciones: permite consultar la cantidad y tipo de autorizaciones que tiene un cierto afiliado;

Consultar cobertura online: verifica que un afiliado tenga una cobertura determinada y obtiene sus características (tipo, porcentaje, etc);

Paquete Reportes

Generar Reporte Autorizaciones Rechazadas: se genera un reporte con el detalle de las autorizaciones rechazadas en el período;

Generar Reporte Porcentaje Rechazos: se genera un reporte con el porcentaje y detalle de autorizaciones rechazadas en el período;

Generar Reporte Prestaciones con Deuda: se genera un reporte de afiliados que tomaron prestaciones estando morosos;

Paquete interacción con promotor

Emitir hoja de ruta: a través de los solicitantes pendientes de visita se confecciona el listado para el promotor

Registrar visitas: se cargan en el sistema los afiliados a incorporar, los solicitantes no visitados y/o se eliminan los solicitantes que no serán afiliados;

Paquete interacción con cobranzas

Actualizar morosos: se actualiza en el sistema el estado de los afiliados, si el afiliado tiene una deuda quedará registrado;

Paquete interacción con prestadores

Recibir y cotejar consumos y prestaciones: se recibe de un prestador el listado de las prestaciones que los afiliados se realizaron, se genera un reporte que se envía a pagos según las prestaciones recibidas aprobadas y/o rechazadas por el sistema, también se genera un reporte señalando el consumo de los afiliados;

Paquete interacción con clientes

Atender consultas afiliado: se atienden consultas realizadas por los afiliados/solicitantes a través del operador;

Ingresar solicitud: se ingresan en el sistema los datos de los clientes que desean afiliarse a la obra social;

Agregar afiliado: da de alta un nuevo afiliado en el sistema (a partir de un solicitante).

Especificación de casos de uso

Actualizar morosos

Armar cartilla

Ingresar solicitud

Agregar Afiliado

Mantener promotores

Pedir autorización manual

Registrar visitas

Emitir hoja de ruta

Mantener prestadores

Recibir y cotejar consumos y prestaciones

Pedir autorización automática

Atender consulta afiliado

Mantener CAPs

Actualizar autorización manual

Generar reporte autorizaciones rechazadas

Generar reporte prestaciones con deuda

Generar reporte porcentaje rechazos

Mantener planes

Mantener prestaciones

Mantener afiliados

Eliminar afiliado

Modificar afiliado

Consultar autorizaciones

Enviar información carnets

Consultar cobertura online

Solicitar autorización automática online

Especificación de clases

Diagrama de casos de uso

Diagramas paquetes

Diagrama de arquitectura general del sistema

Diagrama de paquete de dominio

Diagrama de paquete de control

Diagrama de paquete de reportes

Diagramas de clases

Diagrama de clases de dominio

Diagrama de relación de clases de dominio

Diagrama de clases de control

Diagrama de clases de persistencia

Diseño de la base de datos

Diagrama de tablas

Diccionario de datos

Composición física de las tablas

Tabla	Campo	Tipo	T.Prom	Nulo	PK	FK	Referencia
Afiliados	idAfiliado	Integer	4	No	Si	No	
	Codigo	Integer	4	No	No	No	
	FechaAfiliacion	Date	7	No	No	No	
	FechaBaja	Date	7	Si	No	No	
	Moroso	Integer	4	No	No	No	
	idPlan	Integer	4	No	No	Si	Planes
	idTitular	Integer	4	No	No	Si	Afiliados
Autorizaciones	idAutorizacion	Integer	4	No	Si	No	
	Codigo	Integer	4	No	No	No	
	porcentajeCobertura	Integer	4	No	No	No	
	fechaSolicitud	Date	7	No	No	No	
	fechaRealizacion	Date	7	Si	No	No	
	fechaVencimiento	Date	7	No	No	No	
	Aprobada	Smallint	2	No	No	No	
	fundamentosResolucion	Varchar(255)	50	Si	No	No	
	Tipo	Enum(Manual,Auto)	5	No	No	No	
	idAfiliado	Integer	4	No	No	Si	Afiliados
	idPrestador	Integer	4	No	No	Si	Prestadores
	idPrestacion	Integer	4	No	No	Si	Prestaciones
AutorizacionesManuales	idAutorizacion	Integer	4	No	Si	No	
	fechaResolucion	Date	7	Si	No	No	
	Observaciones	Varchar(255)	100	No	No	No	
	Nrolegajo	Integer	4	No	No	No	
CAPs	idCAP	Integer	4	No	Si	No	
	Codigo	Varchar(255)	10	No	No	No	
	Horario	Varchar(255)	11	No	No	No	
	idDireccion	Integer	4	No	No	Si	Direcciones
Categorías	idCategoria	Integer	4	No	Si	No	
	Codigo	Integer	4	No	No	No	
	Nombre	Varchar(255)	25	No	No	No	
	fechaBaja	Date	7	Si	No	No	
Coberturas	idPrestacion	Integer	4	No	Si	Si	Prestaciones
	idPlan	Integer	4	No	Si	Si	Planes
	Carencia	Float	4	No	No	No	
	Porcentaje	Integer	4	No	No	No	
	LimiteAnual	Integer	4	No	No	No	
	tipoAutoriazacion	Enum(Manual,Auto)	5	No	No	No	
Direcciones	idDireccion	Integer	4	No	Si	No	
	Calle	Varchar(255)	25	No	No	No	
	Numero	Integer	4	No	No	No	
	Piso	Integer	4	Si	No	No	
	Departamento	Varchar(255)	1	Si	No	No	
	CodigoPostal	Varchar(8)	6	No	No	No	
	Provincia	Enum([Provincias])	7	No	No	No	
	Telefono	Varchar(20)	10	No	No	No	
	idZona	Integer	4	No	No	Si	Zonas
HistoriasPlanes	idAfiliado	Integer	4	No	Si	Si	Afiliados
	idPlan	Integer	4	No	Si	Si	Planes
	fechaIngreso	Date	7	No	No	No	
	fechaEgreso	Date	7	No	No	No	
Personas	idPersona	Integer	4	No	Si	No	
	tipoDocumento	Enum(DNI,LC,LE,CI)	2	No	No	No	
	nroDocumento	Integer	4	No	No	No	
	Nombre	Varchar(255)	12	No	No	No	
	Apellido	Varchar(255)	10	No	No	No	
	Email	Varchar(255)	25	Si	No	No	
	fechaNacimiento	Date	7	No	No	No	
	Sexo	Enum(M,F)	1	No	No	No	
	idDireccion	Integer	4	No	No	Si	Direcciones
Planes	idPlan	Integer	4	No	Si	No	
	Codigo	Integer	4	No	No	No	
	Categoría	Float	4	No	No	No	
	Descripción	Varchar(255)	40	No	No	No	
	permanenciaMinima	Float	4	No	No	No	
	fechaBaja	Date	7	Si	No	No	
Prestaciones	idPrestacion	Integer	4	No	Si	No	
	Codigo	Varchar(8)	8	No	No	No	
	Nombre	Varchar(255)	25	No	No	No	
	FechaBaja	Date	7	Si	No	No	
	idCategoria	Integer	4	No	No	Si	Categorías
Prestadores	idPrestador	Integer	4	No	Si	No	
	Cuit	Varchar(11)	11	No	No	No	
	Nombre	Varchar(255)	25	No	No	No	
	FechaBaja	Date	7	Si	No	No	
	Email	Varchar(255)	10	No	No	No	
	idDireccion	Integer	4	No	No	Si	Direcciones
PrestadoresPrestaciones	idPrestador	Integer	4	No	Si	Si	Prestadores
	idPrestacion	Integer	4	No	Si	Si	Prestaciones
Promotores	idPersona	Integer	4	No	Si	Si	Personas
	fechaBaja	Date	7	No	No	No	
Solicitantes	idPersona	Integer	4	No	No	Si	Personas
	Disponibilidad	Varchar(255)	11	No	No	No	
	Familiares	Integer	4	No	No	No	
	Observaciones	Varchar(255)	70	No	No	No	
	Pendiente	Smallint	2	No	No	No	
	idPromotor	Integer	4	No	No	Si	Promotores
	Idtitular	Integer	4	No	No	Si	Titulares
Zonas	IdZona	Integer	4	No	Si	No	
	Nombre	Varchar(255)	10	No	No	No	
	Descripción	Varchar(255)	50	No	No	No	
	IdCAP	Integer	4	No	No	Si	Zonas

Diccionario de datos de las tablas

Tabla	Descripción
Afiliados	Esta tabla almacena los Afiliados de la Obra Social. Están vinculados con un Plan (mediante idPlan) y con otro Afiliado en caso de no ser titular de la cuenta.
Autorizaciones	En esta table se almacenan Autorizaciones que son Automáticas. Cada una de ellas se relacionan con un Afiliado (idAfiliado), con un Prestador (idPrestador) y una Prestación (idPrestacion).
AutorizacionesManuales	Esta tabla representa una entidad débil, que depende de Autorizaciones. Tiene por lo tanto las mismas relaciones que tienen las Autorizaciones. Almacena las Autorizaciones Manuales que llegan a la Obra Social.
CAPs	Esta tabla almacena los CAPs que posee la Obra Social.
Categorías	Almacena las categorías a las que pertenecen las distintas prestaciones. Se basa en el nomenclador.
Coberturas	Almacena la relación que existe entre un plan (idPlan) y las diversas prestaciones (idPrestaciones) que cubre. A su vez indica si para tomar la prestación es necesario una autorización manual o automática.
Direcciones	Almacena las direcciones que eventualmente se involucren en el sistema: tanto las de los Afiliados, Promotores, Solicitantes y CAPs
HistoriasPlanes	Almacena los planes (idPlanes) a los que estuvo asociado un afiliado (idAfiliado) alguna vez dentro de la Obra Social con su respectiva fecha de alta y en caso de haberlo dejado, su fecha de baja.
Personas	Representa la entidad abstracta persona. Está relacionada con un CAP (idCap) y una Dirección (idDireccion).
Planes	Almacena los planes que posee la obra social con sus características.
Prestaciones	Almacena las prestaciones enunciadas en el nomenclador sus características. La principa es el código (codigo) y la vinculación con una categoría (idCategoria).
Prestadores	Almacena tanto médicos particulares como clínicas que pueden realizar prestaciones a los afiliados de la obra social. Los prestadores pertenecen a una zona (idZona) y poseen una dirección física (idDireccion).
PrestadoresPrestaciones	Tabla que relaciona a un prestador (idPrestador) con las distintas prestaciones (idPrestacion) que puede brindar a los afiliados.
Promotores	Almacena los datos de los promotores que posee la Obra Social.
Solicitantes	Esta tabla contiene los datos personales y de contacto de los distintos solicitantes que quizás en un futuro sean afiliados de la Obra Social. Se relaciona con un Promotor (idPromotor) y puede también relacionarse con un titular en caso de poder tener un familiar directo ya asociado en la Obra Social.
Zonas	Almacena las distintas Zonas geográficas en donde hay CAPs.

Diccionario de datos de los atributos

Tabla	Campo	Descripción
Afiliados	idAfiliado	Identificador de un Afiliado en el sistema.
	Codigo	Identificador único de afiliado. Número de carnet.
	FechaAfiliacion	Fecha en la que el solicitante paso a ser un afiliado de la obra social.
	FechaBaja	Fecha en la que el afiliado solicita la baja en el sistema.
	Moroso	Indica cuantos meses adeuda el afiliado.
	IdPlan	Identificador del plan al que pertenece el afiliado.
	IdTitular	Identificador del titular del afiliado actual.
Autorizaciones	idAutorizacion	Identificador de la autorización en el sistema.
	Codigo	Identificador único de la autorización. Número de formulario.
	porcentajeCobertura	Porcentaje de la prestación cubierto por la autorización.
	fechaSolicitud	Fecha en la que fue solicitada la autorización.
	fechaRealizacion	Fecha en la que fue efectivizada la autorización. Es decir el día en que se rechazó o el día en que el afiliado la utilizó.
	fechaVencimiento	Fecha en que vence la autorización.
	Aprobada	Indica si la autorización fue aprobada o no.
	fundamentosResolucion	Una descripción coloquial del por qué se aprueba o rechaza la autorización.
	Tipo	Indica si la autorización es manual o automática.
	idAfiliado	Identificador del afiliado que solicitó la autorización.
	idPrestador	Identificador del prestador que solicitó la autorización.
	idPrestacion	Identificador de la prestación a llevar a cabo.
AutorizacionesManuales	IdAutorizacion	Identificador en el sistema de la autorización a la que pertenece, ya que AutorizacionManual es una entidad débil.
	fechaResolucion	Fecha en la que se aprobo/rechazó la autorización manual.
	Observaciones	Una descripción coloquial del por qué se solicita la autorización.
	nroLegajo	El legajo del profesional que evaluó la autorización.
CAPs	IdCAP	Identrificador del CAP en el sistema.
	Codigo	Identificador único del CAP en el sistema. Código de uso público, se utiliza en listados, etc.
	Horario	Horario de atención (texto libre).
	IdDireccion	Identificador que relaciona a un CAP con una dirección.
Categorías	idCategoria	Identificador de la categoría en el sistema.
	Codigo	Código de la categoría según en nomenclador.
	Nombre	Nombre de la categoría.
	fechaBaja	Fecha en la que fue dada de baja la categoría (NULL si esta activa).
Coberturas	idPrestacion	Identificador de una Prestación en el sistema.
	IdPlan	Identificador de un Plan en el sistema.
	Carencia	Antigüedad (en meses) que debe tener el afiliado en el plan para ser cubierto.
	Porcentaje	Antigüedad (en meses) que debe tener el afiliado en el plan para ser cubierto.
	LimiteAnual	Cantidad de prestaciones que se puede realizar por año (cero indica que no hay límite).
	tipoAutoriazacion	Indica el tipo de autorización que necesita para realizarse la prestación (automática o manual).
Direcciones	idDireccion	Identificador de una dirección en el sistema.
	Calle	Nombre de la calle del domicilio.
	Numero	Número de vivienda del domicilio.
	Piso	Piso del domicilio (NULL si no es aplicable).
	Departamento	Departamento del domicilio (NULL si no es aplicable).
	CodigoPostal	Código postal del domicilio.
	Provincia	Provincia donde se encuentra el domicilio.
	Telefono	Teléfono del domicilio.
	idZona	Identificador de la zona a la que pertenece la dirección.
HistoriasPlanes	idAfiliado	Identificador en el sistema de un afiliado.
	IdPlan	Identificador en el sistema de un plan.
	fechaIngreso	Fecha en que se dio de alta un afiliado en el plan.
	fechaEgreso	Fecha en que se dio de baja un afiliado en el plan (NULL si no se aplica).
Personas	idPersona	Identificador único de una persona en el sistema.
	tipoDocumento	Tipo de documento de la persona.
	nroDocumento	Número de documento de la persona.
	Nombre	Primer y segundo nombre de la persona (en ese orden).
	Apellido	Apellido completo de la persona.
	Mail	Dirección de correo electrónico de la persona.
	fechaNacimiento	Fecha de nacimiento de la persona.
	Sexo	Género de la persona.
	idDireccion	Identificador en el sistema de la dirección de la persona.
Planes	idPlan	Identificador del plan en el sistema.
	Codigo	Identificador único del Plan en el sistema. Se utiliza para listados, etc.
	Categoría	Categoría del plan. Cuanto más grande es la categoría, mejor es el plan
	Descripción	Una breve descripción del plan.
	permanenciaMinima	Permanencia mínima (en meses) que debe cumplir en el plan antes de pasarse a otro.
	fechaBaja	Fecha en la que el afiliado solicita la baja.
Prestaciones	idPrestacion	Identificador de la prestación en el sistema.
	Codigo	Identificador único de la prestación en el sistema.
	Nombre	Nombre del plan
	FechaBaja	Fecha de cuando se dio de baja la prestación.
	idCategoria	Identificador en el sistema de la categoría a la que pertenece la prestación.
Prestadores	idPrestador	Identificador del prestador en el sistema.
	Cuit	Número de CUIT del prestador.
	Nombre	Nombre del prestador.
	FechaBaja	Fecha en que fue dado de baja el prestador (NULL si no se aplica).
	Email	Dirección de correo electrónico del prestador.
	idDireccion	Identificador de la dirección a la que pertenece el prestador.
PrestadoresPrestaciones	idPrestador	Identificador en el sistema de un prestador.
	idPrestacion	Identificador en el sistema de una prestación.
Promotores	IdPersona	Identificador en el sistema de una persona (entidad abstracta).
	fechaBaja	Fecha en que fue dado de baja un promotor (NULL si no se aplica)
Solicitantes	IdPersona	Identificador en el sistema de una persona (entidad abstracta).
	Disponibilidad	Horario en el cual puede ser visitado (texto libre).
	Familiares	Cantidad de integrantes del grupo familiar a afiliar.
	Observaciones	Observaciones que puedan ser de utilidad para el Promotor.
	Pendiente	Indica si el solicitante fue visitado o no.
	IdPromotor	Identificador en el sistema del promotor que atendió al solicitante.
	Idtitular	Identificador en el sistema del titular de la cuenta (cero si no es aplicable).
Zona	IdZona	Identificador único en el sistema de una zona.
	Nombre	Nombre de la zona.
	Descripción	Breve descripción de la zona.
	IdCAP	Identificador que relaciona a una Zona con un CAP.

Mapeo de clases de entidad

Tabla	Campo	Clase.atributo
Afiliados		
	Codigo	Afiliado.codigo
	FechaAfiliacion	Afiliado.FechaAfiliacion
	FechaBaja	Afiliado.FechaBaja
	Moroso	Afiliado.Moroso
	IdPlan	Afiliado.Plan
	IdTitular	Afiliado.Titular
Autorizaciones		
	Codigo	Autorización.codigo
	porcentajeCobertura	Autorización.porcentajeCobertura
	fechaSolicitud	Autorización.fechaSolicitud
	fechaRealizacion	Autorización.fechaRealizacion
	fechaVencimiento	Autorización.fechaVencimiento
	Aprobada	Autorización.aprobada
	fundamentosResolucion	Autorización.fundamentosResolucion
	Tipo	Autorización.tipo
	IdAfiliado	Autorización.Afiliado
	IdPrestador	Autorización.Prestador
	IdPrestacion	Autorización.Prestacion
AutorizacionesManuales		
	fechaResolucion	AutorizacionManual.fechaResolucion
	Observaciones	AutorizacionManual.observaciones
	nroLegajo	AutorizacionManual.nroLegajo
CAPs		
	Codigo	CAP.codigo
	Horario	CAP.horario
	IdDireccion	CAP.Direccion
Categorías		
	Codigo	Categoría.codigo
	Nombre	Categoría.nombre
	fechaBaja	Categoría.fechaBaja
Coberturas		
	Carencia	Cobertura.carencia
	Porcentaje	Cobertura.porcentaje
	LimiteAnual	Cobertura.limiteAnual
	tipoAutoriazacion	Cobertura.tipoAutorizacion
Direcciones		
	Calle	Dirección.calle
	Numero	Dirección.numero
	Piso	Dirección.piso
	Departamento	Dirección.departamento
	CodigoPostal	Dirección.codigoPostal
	Provincia	Dirección.provincia
	Telefono	Dirección.telefono
HistoriasPlanes		
	fechaIngreso	HistoriaPlan.fechaIngreso
	fechaEgreso	HistoriaPlan.fechaEgreso
Personas		
	tipoDocumento	Persona.tipoDocumento
	nroDocumento	Persona.nroDocumento
	Nombre	Persona.nombre
	Apellido	Persona.apellido
	Mail	Persona.mail
	fechaNacimiento	Persona.fechaNacimiento
	Sexo	Persona.sexo
	idDireccion	Persona.Direccion
Planes		
	Codigo	Plan.codigo
	Categoría	Plan.categoría
	Descripción	Plan.descripción
	permanenciaMinima	Plan.permanenciaMinima
	fechaBaja	Plan.fechaBaja
Prestaciones		
	Codigo	Prestación.codigo
	Nombre	Prestación.nombre
	FechaBaja	Prestación.fechaBaja
	idCategoria	Prestación.Categoria
Prestadores		
	Email	Prestador.email
	Cuit	Prestador.cuit
	Nombre	Prestador.nombre
	FechaBaja	Prestador.fechaBaja
	idDireccion	Prestador.idDireccion
Promotores		
	FechaBaja	Promotor.fechaBaja
Solicitantes		
	Disponibilidad	Solicitante.disponibilidad
	Familiares	Solicitante.familiares
	Observaciones	Solicitante.observaciones
	Pendiente	Solicitante.pendiente
	idPromotor	Solicitante.Promotor
	idTitular	Solicitante.Titular
Zona		
	Nombre	Zona.nombre
	Descripción	Zona.descripción
	IdCAP	Zona.CAP

Reglas de integridad referencial

Afiliado
Persona afiliada a la obra social. Se da de baja lógica normalmente. Solo se puede dar de baja física si ningún Afiliado lo tiene como titular. Al darse de baja hay que borrar en cascada la tabla HistoriaPlan, Autorización, Persona y Solicitante (que lo tenga como titular). Solo puede darse de alta física si existen las referencias correspondientes a Persona, Plan y Titular (en caso que corresponda).
Atributo	Tipo	Descripción
idPersona	INT	Clave primaria interna de la base de datos
codigo	INT	Identificador único de afiliado
fechaAfiliacion	DATE	Fecha en la que se lo dio de alta en el sistema.
fechaBaja	DATE	Fecha en la que el afiliado solicita la baja. NULL si está activo
moroso	INT	Indica cuantos meses adeuda.
idPlan	INT	No puede ser NULL
idTitular	INT	NULL si es titular, si pertenece a un grupo familiar, se guarda el id del titular del grupo.

Autorización
Autorización para realizarse una Prestación. No tiene bajas a menos que se depure la base de datos, en cuyo caso se debe borrar en cascada la tabla AutorizacionManual. Solo puede darse de alta física si existen las referencias correspondientes al Prestador, Prestación y Afiliado.
Atributo	Tipo	Descripción
id	INT	Clave primaria interna de la base de datos
codigo	INT	Identificador único.
porcentajeCobertura	DECIMAL(3,2)	Porcentaje de la prestacion cubierto por la Autorizacion
fechaSolicitud	DATE	Fecha en que fue solicitada la autorización.
fechaRealizacion	DATE	Fecha en que efectivizada la autorización. Es decir el dia en que se rechazo o el dia en que el afiliado la utilizo. NULL si todavía no fue realizada
fechaVencimiento	DATE	Fecha en que vence la autorización.
aprobada	BOOL	Indica si la autorizacion fue aprobada o no.
fundamentosResolucion	VARCHAR(255)	Una descripcion coloquial del por qué se aprueba o rechaza la autorización
tipo	ENUMmanual,auto)	Tipo de autorización
idPrestador	INT	No puede ser NULL
idPrestacion	INT	No puede ser NULL
idAfiliado	INT	No puede ser NULL

AutorizacionManual
Autorización que debe ser aprobada manualmente, a través de un auditor médico. Solo puede darse de alta física si existe la referencia correspondiente a la Autorización.
Atributo	Tipo	Descripción
idAutorizacion	INT	Clave primaria interna de la base de datos
observaciones	VARCHAR(255)	Una descripción coloquial del por qué se solicita la autorización
fechaResolucion	DATE	Fecha en la que se aprobó/rechazo la autorización. NULL si todavía no hay una resolución tomada.
nroLegajo	INT	Número de legajo del profesional que evaluó la autorización.

Cap
Centro de Atención Personalizada, es un punto de atención al cliente que cubre una o más Zonas y tiene uno o más Promotores. Se puede dar de baja sólo si no tiene asociado Personas ni Zonas. Si se da de baja, hay que dar de baja en cascada la tabla Dirección. Solo puede darse de alta física si existen la referencia correspondiente a Dirección.
Atributo	Tipo	Descripción
id	INT	Clave primaria interna de la base de datos
codigo	VARCHAR(255)	Código único de identificación del Cap.
horario	VARCHAR(255)	Horario de atención como un texto libre.
idDireccion	INT	No puede ser NULL

Categoria
Clasificación de las Prestaciones. Sólo puede ser dado de baja si no tiene Prestaciones asociadas.
Atributo	Tipo	Descripción
id	INT	Clave primaria interna de la base de datos
codigo	INT	Código de la categoría según el codificador
nombre	VARCHAR(255)	Nombre de la categoría
fechaBaja	DATE	Si no es NULL, la Categoria fue dada de baja en la fecha indicada por este campo.

Cobertura
Limitaciones de cobertura para un Plan y una Prestación determinada. Es dado de baja cuando se da de baja el Plan al que pertenece. Solo puede darse de alta física si existen las referencias correspondientes a Prestación y Plan.
Atributo	Tipo	Descripción
idPrestacion	INT	Clave primaria interna de la base de datos
idPlan	INT	Clave primaria interna de la base de datos
carencia	FLOAT	Antigüedad que debe tener el afiliado en el plan para ser cubierto. Si es NULL no tiene tiempo de carencia
porcentaje	INT(3)	Porcentaje de la prestación cubierto.
limiteAnual	INT	Cantidad de prestaciones que se puede realizar por año. Si es NULL no hay límite
tipoAutorizacion	ENUM(manual,auto)	Indica el tipo de autorización que necesita para realizarse la prestación.

Direccion
Direccion de un domicilio. No se puede dar de baja directamente, se da de baja indirectamente al eliminar un Prestador, un Cap o una Persona. Solo puede darse de alta física si existen la referencia correspondiente a Zona.
Atributo	Tipo	Descripción
id	INT	Clave primaria interna de la base de datos
calle	VARCHAR(255)	Calle del domicilio
numero	INT	Número del domicilio
piso	INT	Piso del domicilio. NULL si no aplica
departamento	VARCHAR(255)	Departamento del domicilio. NULL si no aplica
codigoPostal	VARCHAR(8)	Código postal del domicilio
provincia	ENUM([provincias])	Provincia donde se encuentra el domicilio
telefono	VARCHAR(30)	Teléfono del domicilio. NULL si no aplica
idZona	INT	No puede ser NULL

HistoriaPlan
Representa el período de tiempo que un afiliado estuvo en un plan. Se da de baja sólo al dar de baja un Afiliado. Solo puede darse de alta física si existen las referencias correspondientes a Plan y Afiliado.
Atributo	Tipo	Descripción
idAfiliado	INT	Clave primaria interna de la base de datos
idPlan	INT	Clave primaria interna de la base de datos
fechaIngreso	DATE	Fecha en que se dio de alta el plan
fechaEgreso	DATE	Fecha en la que el plan no rige mas para el afiliado. Si es el plan actual es NULL

Persona
Clase abstracta para representar los datos y acciones comunes de una persona. No se puede dar de baja de forma directa, se da de baja al dar de baja un Afiliado, Solicitante o Promotor. Solo puede darse de alta física si existen la referencia correspondiente Dirección.
Atributo	Tipo	Descripción
id	INT	Clave primaria interna de la base de datos
tipoDocumento	ENUM(DNI,LC,LE,CI)	Tipo de documento.
nroDocumento	INT	Número de documento
nombre	VARCHAR(255)	Primer y segundo nombre (en ese orden).
apellido	VARCHAR(255)	Apellido completo.
eMail	VARCHAR(255)	Dirección de correo electrónico de la persona.
fechaNacimiento	DATE	Fecha de nacimiento
sexo	ENUM(M,F)	Género de la persona
idDireccion	INT	No puede ser NULL

Plan
Plan de la obra social. Normalmente tiene baja lógica, pero puede darse de baja física si no tiene Afiliados asociados (y por lo tanto tampoco tiene asociados HistoriaPlan). Si se da de baja, hay que borrar en cascada la tabla Cobertura.
Atributo	Tipo	Descripción
id	INT	Clave primaria interna de la base de datos
codigo	INT	Codigo de plan (nomenclador).
categoria	FLOAT	Categoría a la que pertenece (nomenclador).
descripcion	VARCHAR(255)	Una breve descripción del plan.
permanenciaMinima	FLOAT	Permanencia mínima (en meses) que debe cumplir en el plan antes de pasarse a otro. NULL si no tiene
fechaBaja	DATE	Fecha en la que el plan se dio de baja. Si está activo es NULL.

Prestacion
Tipo de prestación que puede realizarse un afiliado. Tiene sólo baja lógica (excepto que se depure la base de datos, en cuyo caso hay que borrar, sólo si no tiene Autorizaciones y Coberturas asociadas, en cascada la tabla PrestadorPrestacion). Solo puede darse de alta física si existe la referencia correspondiente a Categoria.
Atributo	Tipo	Descripción
id	INT	Clave primaria interna de la base de datos
codigo	VARCHAR(8)	Código de prestación según el codificador
nombre	VARCHAR(255)	Nombre de la prestación.
fechaBaja	DATE	Si no es NULL, la Prestacion fue dada de baja en la fecha indicada por este campo.
idCategoria	INT	No puede ser NULL

Prestador
Entidad prestadora de servicios para la obra social. Podría ser tanto una Clínica, como un centro de radiología o un médico particular. Tiene sólo baja lógica (excepto que se depure la base de datos, en cuyo caso hay que borrar, sólo si no tiene Autorizaciones asociadas, en cascada las tablas Direccion y PrestadorPrestacion). Solo puede darse de alta física si existe la referencia correspondiente a Direccion.
Atributo	Tipo	Descripción
id	INT	Clave primaria interna de la base de datos
cuit	VARCHAR(11)	Número de CUIT
nombre	VARCHAR(255)	Nombre legal de la entidad (no puede ser NULL)
fechaBaja	DATE	Si no es NULL, el Prestador fue dado de baja en la fecha indicada por este campo.
Email	VARCHAR(255)	La dirección de correo electrónico del prestador.
idDireccion	INT	No puede ser NULL

PrestadorPrestacion
Relación N a M entre Prestadores y Prestaciones. Se da de baja sólo cuando se da de baja un Prestador o una Prestación. Solo puede darse de alta física si existen las referencias correspondientes a Prestador y Prestacion.
Atributo	Tipo	Descripción
idPrestador	INT	Clave primaria interna de la base de datos
idPrestacion	INT	Clave primaria interna de la base de datos

Promotor
Persona encargada de atender a los Solicitantes que quieren afiliarse. No se puede dar de baja si tiene Solicitantes asociados. Si se da de baja, hay que dar de baja en cascada a la tabla Persona. Solo puede darse de alta física si existe la referencia correspondiente a Persona.
Atributo	Tipo	Descripción
idPersona	INT	Clave primaria interna de la base de datos

Solicitante
Persona esperando ser Afiliado a la obra social por un Promotor. Si se da de baja, hay que dar de baja en cascada la tabla Persona. Solo puede darse de alta física si existen las referencias correspondientes a Promotor (en caso que corresponda) y Titular (en caso que corresponda).
Atributo	Tipo	Descripción
idPersona	INT	Clave primaria interna de la base de datos
disponibilidad	VARCHAR(255)	Horario en el cual puede ser visitado expresado con texto libre
familiares	INT	Cantidad de integrantes del grupo familiar a afiliar.
observaciones	VARCHAR(255)	Observaciones que puedan ser de utilidad para el Promotor.
pendiente	BOOL	Indica si el solicitante fue visitado o no.
idPromotor	INT	NULL si no está asignado a ningún Promotor
idTitular	INT	NULL si no se va a agregar a un grupo familiar de un Titular existente

Zona
Región geográfica, cuya mínima unidad es un barrio. Solo se puede dar de baja si no tiene un Prestador asociado. Solo puede darse de alta física si existe la referencia correspondiente a CAP.
Atributo	Tipo	Descripción
id	INT	Clave primaria interna de la base de datos
nombre	VARCHAR(255)	Nombre de la Zona
descripcion	VARCHAR(255)	Descripción de la Zona
idCap	INT	No puede ser NULL

Análisis del volumen de datos

Realizamos una proyección estimando las instancias iniciales y el pico máximo de registro utlizando la columna T.Prom del inciso Composición física de las tablas, la cual indica el tamaño promedio en bytes de cada campo, teniendo en cuenta el tipo de dato físico y que es lo que se va a almacenar. A su vez se estimo un posible estado inicial de los datos contenidos en la obra social y que serán importados o cargados en el sistema a desarrollar.

Para confeccionar la siguiente tabla, sugerimos una tasa de crecimiento de datos, basados en entrevistas y/o estadísticas con el personal de la obra social.

Tabla	Tamaño promedio de una tupla [bytes]	Instancias Iniciales [tuplas]	Pico Máximo de Instancias [tuplas]	Tasa de crecimiento [tuplas/mes]
Afiliados	34	400.500	1.001.250	3.500,00
Autorizaciones	97	1.000.000	2.500.000	8.739,08
AutorizacionesManuales	115	100.000	250.000	873,91
CAPs	29	15	38	0,20
Categorías	40	50	125	0,10
Coberturas	24	15.075	37.688	0,10
Direcciones	58	981.185	2.452.963	8.802,20
HistoriasPlanes	22	520.650	1.301.625	3.850,00
Personas	66	901.170	2.252.925	8.752,00
Planes	71	5	13	0,05
Prestaciones	48	2.010	5.025	3,00
Prestadores	76	80.000	200.000	50,00
PrestadoresPrestaciones	8	80.400.000	201.000.000	50.325,00
Promotores	11	45	113	2,00
Solicitantes	99	500.625	1.251.563	5.250,00
Zonas	68	588.711	1.471.778	3.520,88

Espacio estimado

Tabla	Tamaño inicial estimado por mes [bytes]	Tamaño de pico máximo [bytes]	Proyección a 2 años [bytes]
Afiliados	13.617.000	34.042.500	99.297.000
Autorizaciones	97.000.000	242.500.000	707.337.079
AutorizacionesManuales	11.500.000	28.750.000	83.859.551
CAPs	435	1.088	4.611
Categorías	2.000	5.000	2.000
Coberturas	361.800	904.500	363.528
Direcciones	56.908.730	142.271.825	56.908.730
HistoriasPlanes	11.454.300	28.635.750	72.438.300
Personas	59.477.220	148.693.050	59.477.220
Planes	355	888	2.911
Prestaciones	96.480	241.200	96.480
Prestadores	6.080.000	15.200.000	8.816.000
PrestadoresPrestaciones	643.200.000	1.608.000.000	643.200.000
Promotores	495	1.238	16.335
Solicitantes	49.561.875	123.904.688	49.561.875
Zonas	40.032.348	100.080.870	212.414.633
TOTALES	989.293.038	2.473.232.595	1.993.796.252

Criterios de depuración

Conociendo los criterios de depuración se puede estimar el tamaño de los objetos de la base de datos, con lo cual esta sección esta ligada directamente con el análisis del volumen de datos. Estos procesos se almacenarán en las Tareas (Jobs) del motor de la base de datos (ver modelo 8) y se ejecutarán como instrucciones SQL.

Estos procesos se ejecutan luego del backup de la base de datos (Para que el backup este completo antes de la depuración).

Tabla	Frecuencia	Criterio
Afiliados	mensualmente	Se borran de la tabla todos lo registros en donde el campo FechaBaja es anterior a 10 años respecto de la fecha actual. Se borra en cascada de la tabla HistoriaPlan los registros que hacen referencia a ellos y también en la tabla Persona los registros referenciados. Esto ocurre solo si los registros no están referenciados en esta tabla como titulares (idTitular).
Autorizaciones	mensualmente	Se borran de la tabla todos lo registros en donde el campo FechaRealizacion es anterior a 10 años respecto de la fecha actual. Se borran de la tabla todos lo registros en donde el campo FechaVencimiento es anterior a 10 años respecto de la fecha actual. Se borra en cascada los registros de AutorizacionesManuales.
AutorizacionesManuales	-	-
CAPs	-	-
Categorías	mensualmente	Se borran de la tabla todos lo registros en donde el campo FechaBaja es anterior a 10 años respecto de la fecha actual y si no tiene prestaciones a que hagan referencia a ellas.
Coberturas	-	-
Direcciones	-	-
HistoriasPlanes	mensualmente	Se conserva el historial de los últimos 5 planes a los que perteneció el afiliado.
Personas	-	-
Planes	mensualmente	Se borran de la tabla todos lo registros en donde el campo FechaBaja es anterior a 10 años respecto de la fecha actual. Se borran en cascada las Coberturas. Esto solo si no existen Afiliados e Historia de planes (HistoriaPlan) que hagan referencia a este Plan
Prestaciones	mensualmente	Se borran de la tabla todos lo registros en donde el campo FechaBaja es anterior al año respecto de la fecha actual. Se borra en cascada las entradas en PrestadorPrestacion que contengan a estas Prestaciones. Esto solo si no existen Autorizaciones o Coberturas que hagan referencias a estas Prestaciones.
Prestadores	mensualmente	Se borran de la tabla todos lo registros en donde el campo FechaBaja es anterior a 10 años respecto de la fecha actual siempre y cuando no existan autorizaciones que hagan referencia a estos Prestadores. Se borra en cascada la Direccion y PrestadorPrestacion.
PrestadoresPrestaciones	-	-
Promotores	-	-
Solicitantes	-	-
Zonas	-	-

Alcance del Software

Se implementaron los casos de uso que responden a necesidades funcionales, y que hacen referencia a la actividad principal de la obra social. Las acciones secundarias o que pueden ser analizadas e implementadas en futuras versiones del presente trabajo (o software), son debidamente detalladas en el modelo número cuatro, Funciones complementarias al software.

A continuación, se puede ver en el el siguiente diagrama de casos de usos, los casos que son especificados en este trabajo. Estos son los encerrados por una linea punteada.

Diagrama de alcance

TODO

Funciones complementarias al Software

Importación inicial de datos

Una vez finalizada la instalación del sistema, será necesario realizar la importación de ciertos datos que son requisito fundamental para el funcionamiento del mismo y para los que no se diseñó una ventana que permita su ingreso o manipulación (debido a que son datos que se modifican muy raramente). Esta tarea será entonces llevada a cabo por la persona encargada de instalar el sistema. Los datos a importar son los referidos a las zonas (para ubicar CAP´s o bien para determinar el domicilio de los afiliados y relacionarlos así con el CAP más cercano). Los campos a cargar son nombre y descripción de cada zona.

Cruzar el reporte de consumo contra el reporte de aprobación/rechazo de prestaciones realizadas

Consideramos que el manejo de prestaciones que llegaron declaradas por un prestador y qué hacer si los datos enviados por el mismo no se corresponden con los asentados en el sistema, es tarea del sector de Pagos, ya que con criterios propios, ajenos a nuestro sistema (historial de relaciones con el prestador, deudas del afiliado, cantidad de rechazos anteriores, etc.), determinará qué acción tomar respecto a datos que no se correspondan. Son los encargados de ponerse en contacto con el sector correspondiente del Prestador para revisar y llegar a un acuerdo en cuanto a la acción a tomar frente a datos erróneos.

Ésta funcionalidad no está incluida en el sistema por no tener la información necesaria en el mismo como para tomar una decisión al respecto.

Revisar archivos rechazados del Prestador por formato incorrecto

Durante el proceso de la información (de prestaciones realizadas) que los Prestadores envían al Sistema, el Sistema determina si el archivo enviado cumple con el formato pactado y predefinido. Si no es así, ó si el CUIT de Prestador informado en el archivo no es correcto, dicho archivo se mueve a un directorio de “documentos rechazados” en el sitio FTP, y el Sistema envía un mail al Prestador para que éste determine las fallas en su documento, la corrección y volverlo a enviar como si fuera otro archivo distinto. Asimismo, el Sistema envía un mail al sector Pagos informando el nombre de archivo rechazado, el prestador asociado y la fecha de proceso del archivo, para que Pagos esté al tanto de los documentos rechazados y pueda actuar en consecuencia.

Armado de hoja de ruta

La inteligencia respecto al armado de la hoja de ruta que utilizará un promotor para visitar a una serie de solicitantes a los que intentará afiliar no se corresponde con una funcionalidad esencial que nuestro sistema deba contemplar, por lo tanto la confección de la misma queda relegada al actor Enrutador. Éste, a través de consultas al sistema (zonas cargadas inicialmente, datos de los promotores y de los solicitantes pendientes de visita) confecciona la hoja de ruta tendiendo en cuenta las ubicaciones relativas (es decir, la zona en la que habita el solicitante respecto a la zona en la que se encuentra el CAP en el que trabaja el promotor, buscando que sean lo más cercanas posible) y la disponibilidad horaria de los solicitantes en cuestión. Este listado es enviado por email. Los datos que figuran en este formulario son: tipo y número de documento, nombre y apellido del promotor; tipo y número de documento, nombre completo, dirección, disponibilidad horaria y cantidad de familiares del solicitante. (ref. modelo 5: especificación del listado Hoja de Ruta).

Entrega al promotor de planes a ofrecer a solicitantes

Cuando un promotor visita a un solicitante lleva consigo folletería para ofrecerle distintos planes. El diseño, impresión y encuadernado de los folletos es realizado fuera del sistema a través de una imprenta, ya que no se considera algo esencial para su funcionalidad y sería una inversión extra en materiales (impresoras, papel, tinta, diseñadora, etc.). Una vez impresa la folletería se entrega una cantidad determinada a cada promotor para que él distribuya entre los solicitantes como lo considere conveniente.

Entrega de formularios de carga de solicitantes

Cuando un promotor visita a un solicitante toma nota de los datos personales del mismo y de los familiares que desea afiliar en caso que lo desee. El listado de carga de solicitantes utilizado para completar los datos es documentación impresa fuera del sistema. Se distribuyen varias copias para cada promotor, de modo que siempre pueda disponer de la cantidad suficiente para utilizar en las visitas. Los datos que deben figurar en estos formularios son: tipo y número de documento del titular, tipo y número de documento del familiar (sólo en caso de que el solicitante forme parte de un grupo familiar del que no es titular), dirección, teléfono, código postal, provincia, sexo, e-mail, plan elegido para afiliación y fecha de nacimiento del solicitante. Para control interno deben figurar los siguientes datos del promotor: tipo, número de documento y nombre y apellido (ref. modelo 5: listado de carga de solicitantes)

Confección y reparto de carnets de afiliados

La confección y la distribución (por correo o personal) de los carnets que se confeccionan al momento de afiliar a un solicitante o grupo familiar, queda excluida del alcance del sistema debido a que no constituye una funcionalidad esencial y requiere una inversión extra para obtener hardware específico para la confección de los carnets (debido a la impresión en plástico, hologramas, bandas magnéticas, etc.), por lo tanto es tercerizado al Departamento de Servicios al Cliente, que recibe los datos necesarios para imprimir el carnet y luego enviarlo al afiliado..

Impresión y reparto de Cartilla médica

Decidimos dejar afuera del sistema la impresión de la cartilla, por no considerar necesaria la inversión requerida para su diseño, impresión y envío a los afiliados, ya que esta es una funcionalidad auxiliar del sistema. Los datos requeridos para confeccionar una cartilla de un plan son enviados al Departamento de Servicios al Cliente, que se encargará de la impresión y entrega de la misma a los afiliados.

Pagos de los afiliados

El manejo de pagos por parte de los afiliados a la obra social, queda excluido del alcance de nuestro sistema, debido a que solo es necesario saber si un afiliado no está al día con sus pagos (moroso). No consideramos entonces esta característica a la hora de la implementación.

Diseño de interfaces

Interfaces con el usuario

Modelo de diálogo

Diseño de pantallas

Diseño de listados

Hoja de ruta

Formulario de carga de familiares

Interfaces con otros sistemas

Cartilla médica

Interfaces con otros sistemas interactivos

Modelo de procesamiento

Ciclo del procesamiento

Línea de tiempo diaria

Evento	Duración	00	01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22	23
Consulta de afiliados en Casa Central y CAPs	11 hs																								
Consulta de afiliados vía Web	24 hs																								
Ingreso de solicitudes de afiliación	11 hs																								
Alta de afiliados	11 hs																								
Confección y Asignación de hoja de ruta	2 hs																								
Registro de visitas realizadas	2 hs																								
Confección de cartilla	4 hs																								
Ingreso de solicitud de autorización manual	11 hs																								
Resolver solicitud de autorización manual	11 hs																								
Ingreso de solicitud automática	24 hs																								
Procesar consumos y prestaciones	1 hs																								
Actualizar estado de morosidad de afiliados	1 hs																								
Mantenimiento de planes	2 hs																								
Mantenimiento de prestaciones	2 hs																								
Mantenimiento de promotores	2 hs																								
Mantenimiento de CAPs	2 hs																								
Mantenimiento de zonas	2 hs																								
Mantenimiento de prestadores	2 hs																								
Baja y modificación de afiliados	11 hs																								
Emisión de reporte de autorizaciones rechazadas	2 hs																								
Emisión de reporte de prestaciones con deuda	2 hs																								
Enviar información carnets																									

El esquema anterior es el utilizado en días hábiles (Lunes a Viernes no feriados). Para los Sábados se mantendrá el mismo esquema salvo para las operaciones realizadas por el personal administrativo y de atención al público, en cuyo caso los horarios de 8 a 18 hs. deben ser reemplazados por el de 8 a 12 hs.

Línea de tiempo mensual

Evento	Duración	01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	…	26	27	28	29	30	31
Backup	4 hs																						
Depuración de Base de Datos	4 hs																						

Línea de tiempo anual

Evento	Duración	01	02	03	04	05	06	07	08	09	10	11	12
Emisión de reporte de porcentaje de rechazo de solicitudes	6 hs												

Esquema del procesamiento

TODO (modelo 06, doc 02, con bullets)

Especificación de lanzamiento de tareas

Tarea	Tipo	Justificación
Casa Central
Atención telefónica de afiliados. Puestos de operadores y supervisor
Atender consulta de afiliado	ON-LINE	Se requiere acceso inmediato a los datos del afiliado para poder responder su consulta.
Ingresar solicitud	ON-LINE	Requiere interacción con el operador. Maneja transacciones de un único registro. Se requiere acceso inmediato para confirmar al solicitante el correcto ingreso en el sistema de su solicitud.
Agregar afiliado	ON-LINE	Requiere interacción con el operador. Maneja transacciones de unos pocos registros.
Mantener afiliado	ON-LINE	Requiere interacción con el operador. Se requiere acceso inmediato para confirmar al afiliado la correcta modificación de sus datos.
Pedir autorización manual	ON-LINE	Maneja transacciones de un único registro. Demanda una carga normal de CPU. Se requiere acceso inmediato para confirmar al prestador el correcto ingreso en el sistema de su solicitud de autorización manual.
Pedir autorización automática vía telefónica	ON-LINE	Maneja transacciones de un único registro. Demanda una carga normal de CPU. Se requiere acceso inmediato para confirmar al prestador el correcto ingreso en el sistema de su solicitud de autorización y del resultado de la misma.
Auditoria médica
Actualizar autorización manual	ON-LINE	Requiere interacción con el auditor. Maneja transacciones de un único registro. No necesita una alta carga de procesamiento para resolverse.
Atender consulta sobre afiliado	ON-LINE	Se requiere acceso inmediato a los datos del afiliado para poder resolver la autorización manual.
Promoción. Puestos de promotores
Registrar visitas	ON-LINE	Requiere interacción con el promotor. Maneja principalmente transacciones de un único registro. Demanda una carga normal de CPU.
Promoción. Puesto de supervisor
Registrar visitas	ON-LINE	Ídem anterior.
Emitir Hoja de Ruta	ON-LINE	Se requiere acceso inmediato debido a que los promotores solo pueden comenzar su trabajo diario luego de que se les ha asignado una hoja de ruta. Ya que el sistema solo se encarga de emitir el reporte y registrar las solicitudes como atendidas, la mayor parte de la tarea es realizada en forma manual y por ende no requiere una alta carga de procesamiento.
Mantener promotores	ON-LINE	Requiere interacción con el supervisor. Maneja principalmente transacciones de un único registro. Demanda una carga normal de CPU.
Administración
Mantener planes	ON-LINE	Necesita interacción con el administrador.
Mantener prestaciones	ON-LINE	Necesita interacción con el administrador. La cantidad de datos a los que accede no es importante y no demanda una alta carga de procesamiento.
Mantener prestadores	ON-LINE	Ídem anterior.
Mantener CAPs	ON-LINE	Ídem anterior.
Mantener zonas	ON-LINE	Ídem anterior.
Armar cartilla	ON-LINE	Ídem anterior.
Dirección
Atender consulta sobre afiliado	ON-LINE	El director de la O.S. puede acceder a los datos de los afiliados en cualquier momento y necesita respuesta inmediata.
Sistemas. Data Server
Depuración	BATCH	Se efectúa fuera del horario laboral. No requiere interacción con el usuario. Procesa gran cantidad de información. Los criterios de depuración son automáticos (ver modelo 2).
Backup de la Base de Datos	BATCH	Se efectúa fuera del horario laboral. No requiere interacción con el usuario. Procesa gran cantidad de información.
Sistemas. Web Server
Consulta de afiliados vía Web	ON-LINE	Los usuarios pueden realizar consultas Web las 24 hs del día y esperan recibir la información al momento de la consulta.
Pedir autorización automática vía Web	ON-LINE	Maneja principalmente transacciones de un único registro. Demanda una carga normal de CPU. Se requiere acceso inmediato para confirmar al prestador el correcto ingreso en el sistema de su solicitud de autorización y del resultado de la misma.
Sistemas. Puesto en sala de servidores
Emisión de reporte de autorizaciones rechazadas	BATCH	Maneja un volumen importante de información. No requiere interacción con el usuario. Se ejecuta fuera del horario laboral. El reporte resultante no se requiere en el momento.
Emisión de reporte de prestaciones con deuda	BATCH	Ídem anterior.
Procesar consumos y prestaciones	BATCH	Maneja un volumen importante de información. No requiere interacción. Se ejecuta fuera del horario laboral. Es una tarea programada para ejecutarse diariamente en un horario acordado con los Prestadores ya que estos deben enviar antes de la ejecución de la tarea, vía FTP, los archivos conteniendo la información de prestaciones e intervenciones.
Actualizar estado de morosidad de afiliados	BATCH	Maneja un volumen importante de información. No requiere interacción. Se ejecuta fuera del horario laboral. Es una tarea programada para ejecutarse diariamente en un horario acordado con el sector de Cobranzas ya que este debe enviar antes de la ejecución de la tarea, vía FTP, el listado de afiliados cuyo estado de cuenta ha sido modificado.
Emisión de reporte de porcentaje de rechazo de solicitudes	BATCH	Por tratarse de un reporte anual, maneja una gran cantidad de información. No requiere interacción. Se ejecuta fuera del horario laboral.
Enviar información carnets	BATCH	No requiere interacción. Se ejecuta fuera del horario laboral. Maneja un volumen importante de información.
Atención personalizada de afiliados. Puestos de atención
Atender consulta de afiliado	ON-LINE	Se requiere acceso inmediato a los datos del afiliado para poder responder su consulta.
Ingresar solicitud	ON-LINE	Requiere interacción con el usuario final. Maneja principalmente transacciones de un único registro. Se requiere acceso inmediato para confirmar al solicitante el correcto ingreso en el sistema de su solicitud.
Mantener afiliado	ON-LINE	Requiere interacción con el usuario final. Se requiere acceso inmediato para confirmar al afiliado la correcta modificación de sus datos.
CAP
Promoción. Puestos de promotores
Registrar visitas	ON-LINE	Requiere interacción con el promotor. Maneja principalmente transacciones de un único registro. Demanda una carga normal de CPU.
Promoción. Puesto de supervisor
Registrar visitas	ON-LINE	Requiere interacción con el supervisor. Maneja principalmente transacciones de un único registro. Demanda una carga normal de CPU.
Emitir Hoja de Ruta	ON-LINE	Se requiere acceso inmediato debido a que los promotores solo pueden comenzar su trabajo diario luego de que se les ha asignado una hoja de ruta.
Mantener promotores	ON-LINE	Requiere interacción con el supervisor. Maneja principalmente transacciones de un único registro. Demanda una carga normal de CPU.
Responsable del CAP
Atender consulta afiliado	ON-LINE	El responsable del CAP puede acceder a los datos de los afiliados en cualquier momento y necesita respuesta inmediata.

Diseño y lanzamiento de tareas batch

Tareas

Emisión de reporte de autorizaciones rechazadas

Composición

Emite un reporte de las autorizaciones rechazadas con rango de un mes desde la fecha actual hacia atrás. Una vez generado, el reporte se almacena y se envía una copia por e-mail al director de la Obra Social. El archivo de salida, tal como se especifica en ReporteAutorizacionesController, queda guardado bajo el nombre DD_MM_AAAA.txt donde DD es el día, MM es el mes, y AAAA el año en que se ejecuto el proceso, en el directorio $INI_PATH/Reportes/Autorizaciones/Rechazadas (donde $INI_PATH es la variable que indica la ruta donde el sistema fue instalado).

En caso de no finalizar la tarea en forma correcta en un ciclo anterior, al lanzarse el proceso se continuará la ejecución desde el registro siguiente al último almacenado en el archivo de log, gracias a la forma en que se nombran los archivos es posible generar el reporte que falló en un primer momento con el mismo rango de fechas que tenía inicialmente. Ya que el orden en que se procesan las autorizaciones rechazadas esta dado por la fecha de resolución, no existe la posibilidad de que, ante un fallo en el proceso, se dejen registros sin procesar.

Ejecución

Se utiliza el scheduler de Windows 2000 Professional (sistema operativo que tiene instalado el puesto en la sala de servidores) para programar la ejecución de la aplicación de consola que llevará adelante la tarea. La misma se realizará diariamente a partir de las 5 a.m. de forma que no entorpezca la ejecución de otras tareas.

Condiciones previas

Para la configuración del generador de reportes, se tendrá un XML almacenado localmente en la maquina que ejecute la tarea. Dicho XML debe definir la/s dirección/es de e-mail adonde se debe enviar una copia del mismo y la dirección de e-mal del help desk para comunicarle cualquier error que exista en la ejecución de la tarea.

Puntos de control

En el directorio de salida del reporte se llevará un archivo de log en el que se guardará en formato binario los números de autorización ya procesados, dicho archivo se nombrará igual que el archivo de salida pero su extensión será .log y un archivo temporal en el que se irá guardando el progreso del reporte. El nombre de estos archivos será el mismo que el de salida del reporte, aunque su extensión será .log y .tmp respectivamente.

Al terminar exitosamente el proceso de generación del reporte el archivo de log será eliminado y el archivo temporal será renombrado según se especifico anteriormente.

Contingencias

Además al ocurrir una falla, se enviará un e-mail al help desk para notificarlo del problema.

Por último, si fuera necesario, puede ejecutarse la tarea manualmente ya que se trata de una aplicación de consola que puede ser invocada por el usuario directamente desde el símbolo del sistema. Dicha ejecución debe ser realizada por una persona del área de sistemas una vez que se haya detectado y solucionado la causa del error. Cabe aclarar que el sistema no tiene las funcionalidades de diagnosticar ni corregir dicho fallo y por ende no realizará ningún tipo de chequeo previo a la ejecución para verificar que el mismo haya sido corregido.

Emisión de reporte de prestaciones con deuda

Composición

Emite un reporte de las prestaciones tomadas por afiliados con deuda con rango de un mes desde la fecha actual hacia atrás. Una vez generado, el reporte se almacena y se envía una copia por e-mail al director de la Obra Social. El archivo de salida, tal como se especifica en ReporteAutorizacionesController, queda guardado bajo el nombre DD_MM_AAAA.txt donde DD es el día, MM es el mes, y AAAA el año en que se ejecuto el proceso, en el directorio $INI_PATH/Reportes/PrestacionesConDeuda (donde $INI_PATH es la variable que indica la ruta donde el sistema fue instalado).

En caso de no finalizar la tarea en forma correcta en un ciclo anterior, al lanzarse el proceso se continuará la ejecución desde el registro siguiente al último almacenado en el archivo de log, gracias a la forma en que se nombran los archivos es posible generar el reporte que falló en un primer momento con el mismo rango de fechas que tenía inicialmente. Ya que el orden en que se procesan las autorizaciones de prestaciones efectuadas esta dado por la fecha de resolución, no existe la posibilidad de que, ante un fallo en el proceso, se dejen registros sin procesar.

Ejecución

Se utiliza el scheduler de Windows 2000 Professional (sistema operativo que tiene instalado el puesto en la sala de servidores) para programar la ejecución de la aplicación de consola que llevará adelante la tarea. La misma se realizará diariamente a partir de las 5 a.m. de forma que no entorpezca la ejecución de otras tareas.

Condiciones previas

Para la configuración del generador de reportes, se tendrá un XML almacenado localmente en la maquina que ejecute la tarea. Dicho XML debe definir la/s dirección/es de e-mail adonde se debe enviar una copia del mismo y la dirección de e-mal del help desk para comunicarle cualquier error que exista en la ejecución de la tarea.

Puntos de control

En el directorio de salida del reporte se llevará un archivo de log en el que se guardará en formato binario los números de autorización ya procesados, dicho archivo se nombrará igual que el archivo de salida pero su extensión será .log y un archivo temporal en el que se irá guardando el progreso del reporte. El nombre de estos archivos será el mismo que el de salida del reporte, aunque su extensión será .log y .tmp respectivamente.

Al terminar exitosamente el proceso de generación del reporte el archivo de log será eliminado y el archivo temporal será renombrado según se especifico anteriormente.

Contingencias

Al ocurrir una falla, se enviará un e-mail al help desk para notificarlo del problema.

Además, si fuera necesario, puede ejecutarse la tarea manualmente ya que se trata de una aplicación de consola que puede ser invocada por el usuario directamente desde el símbolo del sistema. Dicha ejecución debe ser realizada por una persona del área de sistemas una vez que se haya detectado y solucionado la causa del error. Cabe aclarar que el sistema no tiene las funcionalidades de diagnosticar ni corregir dicho fallo y por ende no realizará ningún tipo de chequeo previo a la ejecución para verificar que el mismo haya sido corregido.

Emisión de reporte de porcentaje de rechazo de solicitudes

Composición

Emite un reporte del porcentaje de rechazado de solicitudes con rango de un año desde la fecha actual hacia atrás. Una vez generado, el reporte se almacena y se envía una copia por e-mail al Ministerio de Salud. El archivo de salida queda guardado bajo el nombre DD_MM_AAAA.txt donde DD es el día, MM es el mes, y AAAA el año en que se ejecuto el proceso, en el directorio $INI_PATH/Reportes/Autorizaciones/ProcentajeRechadas (donde $INI_PATH es la variable que indica la ruta donde el sistema fue instalado).

En caso de no finalizar la tarea en forma correcta en un ciclo anterior, al lanzarse el proceso se continuará la ejecución desde el registro siguiente al último almacenado en el archivo de log, gracias a la forma en que se nombran los archivos es posible generar el reporte que falló en un primer momento con el mismo rango de fechas que tenía inicialmente. Ya que el orden en que se procesan las autorizaciones rechazadas esta dado por la fecha de resolución, no existe la posibilidad de que, ante un fallo en el proceso, se dejen registros sin procesar.

Ejecución

Se utiliza el scheduler de Windows 2000 Professional (sistema operativo que tiene instalado el puesto en la sala de servidores) para programar la ejecución de la aplicación de consola que llevará adelante la tarea. La misma se realizará anualmente a partir de las 0 a.m. de forma que no entorpezca la ejecución de otras tareas.

Por tratarse de un proceso que se ejecuta una vez al año, en caso de una falla en la ejecución, no es posible esperar al próximo ciclo para finalizar el reporte. Es por ello que antes de comenzar con la tarea se reprograma el scheduler para que se ejecute al día siguiente en el mismo horario al original. Al finalizar la correcta ejecución se restaurará el valor a la misma fecha del año siguiente. De esta forma, en caso de ocurrir un fallo el sistema volverá a intentar ejecutar la tarea al día siguiente, mas allá de si se corrigió el error o no.

Condiciones previas

Para la configuración del generador de reportes, se tendrá un XML almacenado localmente en la maquina que ejecute la tarea. Dicho XML debe definir la/s dirección/es de e-mail adonde se debe enviar una copia del mismo y la dirección de e-mal del help desk para comunicarle cualquier error que exista en la ejecución de la tarea.

Puntos de control

En el directorio de salida del reporte se llevará un archivo de log en el que se guardará en formato binario los números de autorización ya procesados, dicho archivo se nombrará igual que el archivo de salida pero su extensión será .log y un archivo temporal en el que se irá guardando el progreso del reporte. El nombre de estos archivos será el mismo que el de salida del reporte, aunque su extensión será .log y .tmp respectivamente.

Al terminar exitosamente el proceso de generación del reporte el archivo de log será eliminado y el archivo temporal será renombrado según se especifico anteriormente.

Contingencias

Además al ocurrir una falla, se enviará un e-mail al help desk para notificarlo del problema.

Por último, si fuera necesario, puede ejecutarse la tarea manualmente ya que se trata de una aplicación de consola que puede ser invocada por el usuario directamente desde el símbolo del sistema. Dicha ejecución debe ser realizada por una persona del área de sistemas una vez que se haya detectado y solucionado la causa del error. Cabe aclarar que el sistema no tiene las funcionalidades de diagnosticar ni corregir dicho fallo y por ende no realizará ningún tipo de chequeo previo a la ejecución para verificar que el mismo haya sido corregido.

Procesar consumos y prestaciones

Composición

Procesa los archivos de información de prestaciones e intervenciones de los afiliadosenviados por los prestadores y alojados en el sitio FTP destinado para tal caso (ref: Modelo 5 - Especificación de Interfaces con el Prestador). Una vez procesados todos los archivos de prestadores, genera el informe de aprobaciones/rechazos de prestaciones realizadasy el reporte de consumo de los afiliados y sube ambos documentos al directorio de pagos del sitio FTP (ref: Modelo 5 – Especificación de Interfaces con el sector Pagos).

Ante una falla del proceso en un ciclo anterior, y para evitar procesar varias veces el mismo registro de prestación tomada, se verificará al inicio de la ejecución que no existan los archivos temporales de los reportes informe de aprobaciones/rechazos de prestaciones realizadas y reporte de consumo de los afiliados. En caso de que así fuera, al procesar cada archivo de información de prestaciones e intervenciones de los afiliados se deberá verificar registro por registro, que no exista en los dos primeros archivos y si así fuera a manera de control deberá verificar que los registros coincidentes sean idénticos.

Ejecución

Se utiliza el scheduler de Windows 2000 Professional (sistema operativo que tiene instalado el puesto en la sala de servidores) para programar la ejecución de la aplicación de consola que llevará adelante la tarea. La misma se realizará diariamente a partir de las 3 a.m. por ser el horario acordado con los prestadores como limite diario para el envío de los archivos y de forma que no entorpezca la ejecución de otras tareas.

Condiciones previas

El sitio FTP debe estar online y la aplicación debe tener acceso de lectura/escritura a los directorios de los Prestadores y al directorio de Pagos. Para el acceso al sitio FTP, se tendrá un XML almacenado localmente en la maquina que ejecute la tarea. Dicho XML debe definir la dirección y puerto del sitio FTP, los directorios de los prestadores y el directorio donde se guardarán los reportes generados de forma que sean accesibles al sector de Pagos, además del e-mail del responsable en el área de sistemas al que deba comunicársele cualquier error en el proceso. El Schema de validación del XML debe estar disponible al proceso para que este pueda realizar la validación de los archivos recibidos.

Puntos de control

Al finalizar el procesamiento de cada archivo de información de prestaciones e intervenciones de los afiliados, se mueve dicho archivo al subdirectorio documentos aceptados del directorio del prestador en el sitio FTP; si ocurre un error de validación el archivo se moverá al subdirectorio documentos rechazados perteneciente al directorio antes citado. Por ende, todos los archivos que no hayan sido procesados en su totalidad permanecerán en el directorio de entrada del Prestador y serán reprocesados en caso de que el proceso no finalice correctamente.

Contingencias

Al igual que los otros procesos, ante una falla en la ejecución de la tarea se enviará un e-mail al área de sistemas para notificarla del problema. Por tratarse de un proceso extremadamente sensible al negocio de la organización, será responsabilidad del personal de sistemas resolver en forma inmediata cualquier problema reportado y volver a ejecutar el proceso invocándolo desde la línea de comandos.

Actualizar estado de morosidad de afiliados

Composición

Procesa los archivos recibidos en el sitio FTP en el directorio acordado con el sector Cobranzas (ref: Modelo 5 - Especificación de Interfaces con el sector Cobranzas) y actualiza los estados de morosidad de los afiliados. Los archivos encontrados en el FTP se mueven temporalmente a un directorio de procesamiento que al finalizar el correcto procesamiento de los mismos, se eliminan.

Los archivos se tomarán en orden de acuerdo al nombre que es indicativo de la fecha de emisión.

En caso de que al iniciar la ejecución de la tarea se detecten archivos en el directorio de procesamiento lo que indicaría que la tarea fallo en un ciclo anterior, se comenzará procesando estos antes de los que se encuentren en el FTP.

Ejecución

Se utiliza el scheduler de Windows 2000 Professional (sistema operativo que tiene instalado el puesto en la sala de servidores) para programar la ejecución de la aplicación de consola que llevará adelante la tarea. La misma se realizará diariamente a partir de las 4 a.m. por ser el horario acordado con el sector Cobranzas como limite diario para el envío de los archivos y de forma que no entorpezca la ejecución de otras tareas.

Condiciones previas

El sitio FTP debe estar online y la aplicación debe tener acceso de lectura/escritura al directorio de Cobranzas. Para la configuración del path en el FTP debe existir un XML en el mismo directorio que el del ejecutable que defina la dirección y puerto del sitio y el path al directorio de Cobranzas, dicho documento además contendrá la dirección de e-mail del área de sistemas a la que debe enviarse un correo en caso de ocurrir un error en el proceso.

Puntos de control

A medida que se procesan registros de afiliados estos se eliminan del archivo CSV.

Contingencias

Si se encontrara un error en uno de los CSV no se seguirá ejecutando la tarea y se enviará un e-mail al área de sistemas para informar el problema. Por tratarse de un proceso extremadamente sensible al negocio de la organización, será responsabilidad del personal de sistemas resolver en forma inmediata cualquier problema reportado y volver a ejecutar el proceso invocándolo desde la línea de comandos.

Enviar información carnets

Composición

Para llevar el control de contingencias ocurridas en ciclos anteriores, lo primero que se verifica al comenzar la ejecución de la tarea es el archivo INI para chequear la última fecha en la que se completó en forma exitosa.

Consulta los afiliados ingresados entre la fecha siguiente al del INI y la fecha actual y a partir de sus datos genera un XML con el formato definido en la especificación de la clase CarnetsController (modelo 1). Una vez generado el archivo de salida se envía al departamento de servicios al cliente. El archivo XML de salida queda guardado bajo el nombre DD_MM_AAAA.xml donde DD es el día, MM es el mes, y AAAA el año en que se ejecuto el proceso, en el directorio $INI_PATH/NuevosAfiliados (donde $INI_PATH es la variable que indica la ruta donde el sistema fue instalado). Si la tarea concluye exitosamente se seteará en el INI la fecha actual.

Ejecución

Se utiliza el scheduler de Windows 2000 Professional (sistema operativo que tiene instalado el puesto en la sala de servidores) para programar la ejecución de la aplicación de consola que llevará adelante la tarea. La misma se realizará diariamente a partir de las 23 hs de forma que no entorpezca la ejecución de otras tareas y para que al día siguiente el Depto. de Servicios al Cliente tenga la información necesaria para emitir los carnets.

Condiciones previas

Para la configuración, se tendrá un XML almacenado. Dicho XML debe definir la/s dirección/es de e-mail del departamento de Servicios al Cliente adonde se debe enviar una copia del archivo XML de nuevos afiliados y la dirección de e-mal del help desk para comunicarle cualquier error que exista en la ejecución de la tarea. Además, en el mismo directorio debe existir un archivo INI que contenga la fecha en la que se completó por última vez en forma exitosa la tarea.

Puntos de control

Ya que la cantidad diaria de nuevos afiliados no será excesiva y por lo tanto la carga de trabajo por reprocesar los nuevos afiliados de un día dado no es importante, no se implementan puntos de control sobre el proceso diario. Para llevar control sobre el último día que se terminó correctamente la ejecución de la tarea se utiliza el archivo INI mencionado anteriormente.

Contingencias

Ante un error en la ejecución de la tarea se envía automáticamente un e-mail al help desk. Además del control de contingencias mencionado en la Composición de la tarea, se puede ejecutar el proceso en forma manual si así se requiriese.

Depuración

Composición

Realiza la depuración según lo explicado en el modelo 2.

Ejecución

El proceso de depuración se almacena en las tablas de tareas (jobs) del motor de base de datos y será este el encargado de lanzarlo a las 23 hs de los días 2 de cada mes.

Condiciones previas

El motor de base de datos debe estar corriendo y el backup de la base de datos debe haberse ejecutado el día anterior (ver próxima tarea batch).

Puntos de control

La tarea como se explicó en el modelo 2, esta definida por sentencias SQL que serán ejecutadas por el DBMS, dichas sentencias deben estar atomizadas en transacciones de forma que sea el motor el que realice el proceso con puntos de control en cada commit y debe estar configurado para que lleve un log de lo acontecido (tanto transacciones exitosas como erroneas).

Contingencias

Se debe configurar el DBMS para que ante cualquier error en el proceso se envíe un e-mail al administrador de seguridad (que además cumple tareas de administración de la base de datos). Esta persona podrá diagnosticar el error a partir del archivo de log confeccionado por el motor durante la ejecución de la tarea, y una vez solucionado, deberá ejecutar la tarea reconfigurando el job para que se ejecute ese mismo día fuera del horario de trabajo a partir del último registro exitoso del log.

Backup de Base de Datos

Composición

Se realiza el backup completo de la base de datos: todas las tablas del sistema especificadas en el modelo 2 y en el modelo 14 (tablas referidas a la seguridad). Los archivos resultantes de dicho backup se almacenan en cinta.

Ejecución

El proceso de backup se almacena en las tablas de tareas (jobs) del motor de base de datos y será este el encargado de lanzarlo a las 23 hs de los días 1 de cada mes.

Condiciones previas

El motor de base de datos debe estar corriendo y el equipo de grabación de cinta debe estar conectado y cargado con una cinta de suficiente capacidad para contener la información del backup.

Puntos de control

Ídem a tarea de depuración.

Contingencias

Ídem a tarea de depuración. En caso de error será el administrador de la base de datos el responsable de cancelar la depuración al día siguiente ya que esta solo debe correrse luego de que el proceso de backup se haya completado correctamente.

Nota sobre el control de contingencias de tareas

TODO (poner archivo con notas, tiene bullets)

Diseño de la arquitectura de procesamiento

Arquitectura física

Modalidad de procesamiento

Diseño funcional

Especificación de tecnología

El presente documento detalla la especificación de la tecnología a utilizar, en cuanto a hardware requerido y software de base mínimo para el correcto desempeño del negocio, en particular tomando como base los modelos 13 y 14 que se describirán posteriormente.

Para dar estructura a este modelo, en primer lugar se hará una revisión del hardware mínimo requerido para implementar la solución, y luego el software base para lograr la correcta funcionalidad y disponibilidad del negocio.

Hardware Requerido

El hardware es muy variado de acuerdo a la función que implemente, dentro de la infraestructura de la organización. Como se detalla luego en el modelo 13 acerca de la formación de infraestructura, básicamente se cuenta con terminales de trabajo que es el grueso de los equipos, y luego con aquellas máquinas que hacen a los procesos y al networking de la corporación.

Comenzaremos por el equipamiento potente, el que se encargará de llevar a cabo los procesos de alto consumo de CPU y memoria y que deberán garantizar la eficiencia de la aplicación, así como la disponibilidad de la misma. En este apartado mencionaremos los servidores que deberán ubicarse en la sala de cómputos. En la misma, en la Casa Central además se deberá contar con el equipamiento de networking necesario para garantizar y mantener el enlace entre este edificio y cada uno de los CAPs (ver el detalle en el modelo 13, conceptos de seguridad). Todo este último equipamiento, como ser routers, switches y racks no estarán detallados en este documento, ya que corresponde a un trabajo conjunto entre los Ingenieros especialistas en infraestructura y el proveedor de internet y enlaces físicos y lógicos.

En primer lugar, necesitaremos 2 clusters, uno para albergar el servidor de base de datos relacional y otro para contener el servidor LDAP con la base jerárquica de directorio (ver luego la implementación en el modelo 14).

Estos clusters serán DELL PowerEdge 2850. Por cada cluster serán necesarios por lo menos dos nodos para garantizar la disponibilidad de la información (esto está sujeto a análisis financiero por parte de la empresa). Como bien lo dice su especificación, estas poderosas máquinas son rackeables, incluyen fuentes de alimentación redundantes y unidades de disco conectables en caliente y soporta discos RAID para la redundancia de datos. Las mismas deberán contar con dos procesadores Intel Xeon de 3.6GHz, bus frontal de 800MHz, 1MB de caché L2, 4GB de memoria y unidades de disco de 73GB (por cada nodo). En la imagen podemos apreciar uno de estos nodos. Recordemos que por lo menos necesitaremos dos nodos por cluster. Es importante destacar que esta máquina viene equipada con posibilidad de backup en cinta, requisito que se verá luego en el modelo 13, conceptos de seguridad. La forma de la máquina para el rack es de 2U.

Otro componente importante son los servidores del dominio que actuarán como PDC (Controlador de Dominio Primario) y BDC (Controlador de Dominio Secundario), que adicionalmente contendrán los servicios de DNS y WINS (implementado en Samba). Para ello hemos seleccionado dos servidores HP Proliant DL585. El mismo contará con procesadores AMD Opteron de 2.4GHz (con dos procesadores por cada máquina ya que se espera una alta carga para administrar todos los requerimientos de red), y 32 GB de memoria DDR. Tendrán rígidos de 80 GB. Su forma en el rack es de 4U. En esta maquinaria tendremos además del servidor SMB para controlar contendrán aquellos servicios de infraestructura tales como DHCP y DNS.

Como se puede apreciar, estos equipos son rackeables y sería conveniente que estuviesen en un solo rack dentro de la Casa Central de manera de mantener centralizado físicamente el núcleo de negocio de la corporación, de manera de poder hacer un monitoreo rápido en caso de incontingencia.

Ahora nos referiremos a las estaciones de trabajo. Las mismas tendrán una baja potencia ya que como se mencionó anteriormente, la carga pesada recae en los servidores. Las mismas tendrán un procesador Intel Pentium III a 500Mhz, con 256MB de RAM, rígido de 20GB y placa ethernet de 10MB (además, claro está, de monitor, teclado y mouse).

Software Requerido

El software base requerido será distinto obviamente para los servidores que para las estaciones de trabajo. Empezaremos en este caso al revés ya que es el caso más simple la revisión de una terminal de trabajo y luego pasaremos al software necesario para revestir los servidores.

Estaciones de Trabajo

Las estaciones de trabajo se instalarán en primer lugar con un Sistema Operativo Windows 2000 Professional y serán puestas en el dominio por el administrador del mismo. Además de contar con el Sistema Operativo instalado con aquellos componentes necesarios para acceder a internet y un cliente de correo electrónico como el Outlook Express, las estaciones de trabajo deberán contar con el siguiente software:

* Novell - Mono Framework 2.0

* Gtk# 2.0

La aplicación es multiplataforma con lo cual con estos componentes preinstalados se puede pasar a instalar la aplicación en sí y otros componentes.

Servidores

Para los servidores será necesario un sistema operativo más robusto y con buen soporte técnico, por lo cual la elección es que sean instalados con un Suse 9 de Novell, versión Enterprise (tanto en los clusterizados para el motor de base de datos y el directorio, como en el server stand-alone), instalando los servicios básicos de networking.

Servidor stand-alone primario

En el Server stand-alone se instalará también un demonio DHCP que entregará direcciones IP dentro de un rango acotado según la red que disponga el proveedor del enlace, y un server DNS. Además debe instalarse en el un servicio SAMBA 3. Todos estos paquetes vienen incluídos en la última versión de la distribución. Este servidor hará de PDC (Controlador Primario del Dominio).

Servidor stand-alone secundario

Este server contará con las mismas facilidades del anterior salvo que no tendrá los servicios de DHCP y DNS instalados. Sí tendrá un SAMBA 3 configurado como BDC (Controlador Secundario de Dominio). Para más detalle sobre estos servicios consultar el modelo 13, conceptos de seguridad.

Cluster DB

En este servidor será instalado un Novell Suse 9 versión Enterprise. Adicionalmente deberá instalarse un motor PostgreSQL 8 clusterizada con la base almacenada en un compartido por los nodos del cluster.

Cluster Directorio

En este cluster deberá instalarse nuevamente el Sistema Operativo Novell Suse 9 versión Enterprise y sobre él el directorio Novell eDirectory 8.7.3, junto a su administrador vía web Novell iManager 2. La base del directorio (dib) deberá estar compartida por los clusters de modo que los servicios vía LDAP estén disponibles el 100% del tiempo independientemente del estado del enlace.

El resto del software y el detalle de instalación del mismo será discutida en el modelo siguiente, instalación de componentes.

Modelo de instalación de componentes

Mapa de instalación

Configuración de entorno

Estación de trabajo consultas

Estación de trabajo recepción

Estación de trabajo administración

Estación de trabajo director

Estación de trabajo técnico

Webserver

Dataserver

Servidor de red

Diseño conceptual del menú

Estructura elegida

Forma de agrupamiento

Opciones del menú

Diseño conceptual de seguridad

El presente documento estipula a modo conceptual los requisitos necesarios para cumplir con el negocio y asegurar el correcto tratamiento de la información. El objetivo primario es garantizar la continuidad comercial, y defender la información ante una amplia gama de amenazas, minimizando el daño a la misma y maximizando el retorno sobre inversiones y oportunidades.

El esquema presentado es un lineamiento acotado del esquema 1 de la normativa ISO 17799:2002 el cual es el estándar internacional sobre seguridad en tecnología de la información, adecuando el mismo al dominio de la presente aplicación y extendiendo a la infraestructura de la corporación Obra Social Asistencia Médica Miklolife. Adicionalmente se utilizarán otros estándares, muchos de ellos obtenidos de RFCs de la IETF, los cuales, en el momento de ser utilizados, se hará referencia al número de los mismos.

Introducción – Conceptos Básicos

El término de seguridad en este contexto se referirá a la preservación de las siguientes tres características fundamentales:

A-Confidencialidad: la información deberá ser accesible sólo a aquellas personas autorizadas a tener acceso a la misma.

B-Integridad: se debe mantener la exactitud y totalidad de la información y los métodos de procesamiento.

C-Disponibilidad: los usuarios autorizados al acceso a la información y sus recursos relacionados deben poder acceder a ellos en todo momento en que sea requerido.

En cuanto a la operativa diara de los usuarios frente a sus tareas, se manejarán dos términos clave:

A-Autenticación: se refiere a la fase en que se valida la identidad del usuario.

B-Autorización: se refiere a las actividades permitidas para el usuario, una vez autenticado.

La presente documentación es un delineamiento de cómo será implementada la infraestructura y la aplicación de gestión para respetar estos conceptos y asegurarse de que sean cumplimentados de la manera acordada.

Infraestructura Física

Bajo este tópico se describirá como deberá establecerse la infraestructura física de la corporación debido a la arquitectura remitida en el análisis de la aplicación, haciéndola extensiva para el futuro anexo de nuevas aplicaciones complementarias a la gestión de Afiliados, Coberturas, Planes, Autorizaciones, Prestadores y Prestaciones.

La empresa cuenta con una sede central y numerosos CAP distribuídos en todo el país. Para implementar un esquema de infraestructura física, el núcleo de procesamiento deberá incorporarse en la sede central de la obra social manteniendo la carga pesada del procesamiento de la información, restándole a los CAP la infraestructura mínima para mantener contínuo el enlace hacia la sede central, y a su vez protegido contra intentos de intrusión y violación de la información.

En sede central deberá implementarse un NOC donde serán ubicadas todos los servidores y dispositivos de networking necesarios para distribuir la aplicación a través de los CAPs, y en cada uno de éstos últimos se deberán incorporar racks con el equipamiento necesario para la accesibilidad al enlace y la protección del mismo ante amenazas a la seguridad.

Para el primer caso, se dispondrá de una sala propia. La misma deberá mantener los equipos debidamente instalados sobre racks. Deberá tener techo, piso y paredes falsas por los que deberá pasar el cableado debidamente canalizado. Adicionalmente deberá mantenerse la temperatura de la misma entre 10 y 15 grados Celsius con el objeto de mantener la temperatura de las máquinas. Las paredes, techo y piso reales deben estar preparadas para desastres físicos como fuego o inundación. El acceso debe estar bloqueado con cerraduras electrónicas, y activadas mediante un código numérico o una placa magnética, y toda persona ajena debe ser escoltado al mismo (recordar que es el centro neurálgico del negocio).

En el caso de cada CAP, deberá contar con un rack con los dispositivos de networking y servers necesarios para mantener el enlace, debidamente custodiados bajo llave, de donde saldrán las bocas hacia todos los puestos de trabajo.

Como en breve será descripto, se necesitará un servicio de directorio LDAP para el control de autenticación y autorización de los usuarios, y el motor de base de datos para el uso propio de la aplicación y futuras aplicaciones que fuesen de necesidad. Para garantizar la continuidad de la operativa diaria, se dispondrá de dos cluster separados, uno para guardar la base del directorio y otro para guardar la base relacional. Ambos clusters deben permanecer en el NOC de la sede central de modo de mantener centralizado el control de los mismos. Al estar clusterizados los dos servicios principales, se dispondrá de continuidad ya que ante la caída de uno de los nodos, otro de ellos tomará el servicio.

Infraestructura Lógica

En esta sección se describirá la infraestructura lógica a implementarse en la organización y particularmente en la aplicación. Para comenzar, se tratará la manera de organizar y estructurar a todos los usuarios desde el punto de vista de empleados de la firma, y como vincularlos hacia la aplicación.

Infraestructura de usuarios, y grupos y perfil en base a roles

Los usuarios de la organización serán almacenados en una base de datos jerárquica del tipo ISO X.500, con un servicio LDAP, en su versión 3 del protocolo, full compliant con las RFC 3377, 2251, 2252, 2253, 2254, 2256, 2829-2830 (las dos últimas para la autenticación). El servicio debe estar clusterizado como anteriormente se mencionó, y la conexión al mismo debe ser vía SSL. No deberá permanecer abierto el puerto TCP estándar 389 para comunicaciones por texto plano. El puerto abierto será el estándar para comunicación LDAP sobre SSL que es el 636 y toda comunicación se utilizará mediante querys LDAP. La base del directorio deberá bajarse a un archivo plano LDIF semanalmente e ir almacenando las copias de resguardo en cinta en modo progresivo con el motivo de poder hacer una restauración ante una situación de desastre.

En el siguiente modelo se describirá en exactitud la implementación del directorio y cómo almacenar a los usuarios y grupos. A modo de adelanto, los usuarios serán entries de la clase inetOrgPerson descrita en la RFC 2798 y para los grupos, entries del tipo groupOfUniqueNames, descrita en el estándar X.500.

El árbol tendrá una estructura jerárquica, comenzando por una raíz representando a la organización con clase organization, y luego contenedores de la clase organizationalUnit, cada uno representando un CAP, y debajo de cada uno de ellos los usuarios de ese CAP. Lo mismo para la Sede Central. Luego deberá haber un contenedor especial para los grupos. Los mismos definiran los roles que tendrán los usuarios en la aplicación.

El objetivo de usar un árbol LDAP es que es un servicio distribuído ideal para mantener la información de infraestructura, incluyendo usuarios, grupos, servidores y todo tipo de datos de tal índole. El usuario tendrá almacenados sus datos personales, sus credenciales y podrá ser vinculado a diversos grupos, pudiendo las aplicaciones utilizar estos agrupamientos para poder perfilar a los usuarios. El directorio además permite almacenar un password de diversos modos, inclusive extender la clase propuesta para poder almacenar credenciales del tipo biométrica, como el iris de ojos o las huellas digitales de los usuarios. Este último es muy recomendado debido a su gran avance en cuanto a tecnología se refiere. Adicionalmente, el directorio cuenta con la ventaja de separar la aplicación y la administración de empleados de la organización y sus roles dentro de la misma, manteniendo el usuario una sola identidad dentro de la empresa y conservando sus credenciales para entrar a las diversas aplicaciones con que cuente la corporación.

A modo conceptual, este esquema recién descrito se representa en la siguiente figura:

En el mismo podemos ver varios usuarios en distintos contenedores de acuerdo a su ubicación física de trabajo, y por cada una de ellas un contenedor organizationalUnit de modo de mantener reflejada la jerarquía de la organización. Vemos también el contenedor ou=Grupos_Gestion debajo del cual estarán ubicados aquellos grupos que perfilan los usuarios de nuestra aplicación de acuerdo a sus roles. Por último, el administrador general del directorio, colgando directamente de la raíz organizativa.

Vínculo hacia la aplicación – Propagación de perfiles según roles

En cuanto a la seguridad netamente de la aplicación, la misma estará montada en el mismo schema dentro del motor de base de datos (también clusterizado), pero no tendrá relación con los datos propios de la aplicación. Habrá una tabla con usuarios (donde se guardarán sus usernames, coincidentes con los RDN de sus entries LDAP), con el objeto de integrar un usuario a la aplicación. Adicionalmente esta tabla puede llegar a contener datos exclusivos del usuario dentro de la aplicación de ser necesario, pero es recomendable que se extienda la clase usuario si estos datos son más de infraestructura que de la aplicación en sí. Luego deberá existir una tabla que mapee los grupos con las funcionalidades existentes en la aplicación, y más en detalle, otra tabla que relacione las funcionalidades con ítems de menú (que se describirá en el modelo acerca del concepto e implementación de menues).

A modo conceptual, para aplicar este esquema, la aplicación debe en primer lugar realizar la autenticación del usuario, vía LDAP. Este procedimiento será descrito luego en la implementación. Luego, una vez autenticado se obtendrá su membreía trayendo vía LDAP los grupos a los cuales el usuario está enlazado y una vez con estros grupos y armado el perfil del usuario, se mostrarán aquellas funcionalidades a las que el usuario está autorizado a acceder.

Lo anterior se puede visualizar en el siguiente esquema gráfico:

Como se puede ver, el manejo de la seguridad es sencillo y recae en el poder del directorio con servicio LDAP.

NOTA: En el siguiente modelo, modelo 14 – implementación de seguridad se detallarán todos los pasos desde la autenticación hasta llegar a las acciones propias del usuario, y se presentará el DER en la base de datos relacional y reglas de integridad referencial para implementar este esquema. Este modelo es solamente a nivel descriptivo.

Ambiente interno

Internamente, se utilizará un dominio w2k, pero emulado a través de un SAMBA 3 utilizando el mismo directorio LDAP en reemplazo del Microsoft Active Directory, ya que este último posee escasas prestaciones a nivel de directorio, aunque debemos destacar que cumple con todas las especificaciones de las RFC (el tema de la exclusión de AD es poder tener un dominio windows bajo la administración poderosa de Samba, utilizando adicionalmente un directorio que permita mantener un árbol corporativo).

En las estaciones de trabajo de los usuarios se contará con clientes Windows 2000 Professional debidamente licenciados. Toda la administración del dominio deberá implementarse bajo Novell Suse Linux 9, mediante un PDC Samba 3 como recién se nombró, y adicionalmente manteniendo un servicio BDC Samba 3 a modo de resguardo, y para restaurar el dominio en caso de una caída del PDC.

Antes de proseguir, cabe destacar que deberá extenderse el schema del directorio con las clases auxiliares posixAccount, shadowAccountn y posixGroup, descritas en su totalidad en la RFC 2307 junto con las clases que vienen incorporadas en la instalación de Samba (sambaSamAccount para las cuentas de usuarios de dominio Windows).

La siguiente figura esquematiza el dominio logrado y su vínculo al directorio:

De esta manera, los usuarios se podrán loguear a sus terminales de trabajo y a la aplicación utilizando las mismas credenciales. Se recomienda analizar de incluir un logon script o una herramienta más poderosa de control remoto de terminales para acotar las actividades del usuario dentro de su estación de trabajo.

Ambiente externo

Hay dos tipos de accesos internos con los que se deben llevar cuentas. Uno de ellos es el grueso y son los afiliados. Otro son los prestadores. Ambos estarán dentro de un contenedor único llamado externos al nivel siguiente de la organización en el árbol de directorio, y la funcionalidad de los mismos se otorgará bajo el mismo esquema que a los usuarios internos de la aplicación. Esto se explicará en detalle en el modelo 14, implementación de la seguridad.

Conclusión

Bajo este esquema de infraestructura lógica, el usuario contará con el beneficio de mantener una única identidad dentro de la organización, pudiendo tener un set de credenciales único para todos los entornos operativos en donde se movilice y extendiendo este esquema a futuras implementaciones Single Sign On.

Enlace

Se deberá contratar un ISP para proveer un enlace dedicado que interconecte la Sede Central de la Obra Social con todos sus CAPs. Toda la organización dispondrá de una única red privada, y será en la Sede Central el único punto con salida a Internet, a través de otro enlace provisto por el ISP, centralizando de esta manera todos los controles de seguridad frente a amenazas externas. Los usuarios rasos no tendrán salida a intenet, utilizando mensajería interna para comunicarse. El servidor SMTP para los mails deberá permanecer en el NOC central para controlar el flujo hacia la red exterior.

A nivel conceptual, se refleja en el siguiente diagrama:

Seguridad frente a accesos externos e internos

Las transacciones que se realicen por las aplicaciones deben realizarse a través de un canal SSL, debiendo implementarse internamente un CA que emita certificados, los cuales deberán ser incorporados por todas las instancias clientes de la aplicación para poder establecer comunicaciones con las respectivas fuentes de datos. Bajo ningún punto de vista se permitirá información viajando vía texto plano.

En relación a esto, también se deberán establecer canales SSL para las comunicaciones provenientes desde el exterior. Todos los archivos recibidos por los prestadores deberán viajar bajo SSL. En este caso se deberá comprar certificados de un CA correspondiente disponible en Internet para garantizar la identidad de los participantes de la transacción. Los mismos deberán ser enviados por SFTP o SCP.

En el caso de los archivos subidos desde los prestadores y la clínica, el formato de los documentos dependerán de la operativa necesitada por la aplicación. En esta fase inicial los documentos transaccionados son emitidos vía un web service utilizando el estándar XML y vía FTP, según las interfaces ya pactadas por ambas partes.

En relación al último párrafo, es importante tener en cuenta que estas transacciones implican un alto impacto entre las partes negociantes, con lo cual se recomienda que en el futuro, se reconsidere que el documento trasmitido sea concatenado con la firma digital del origen de manera que garantice el no repudiation de la información enviada, y adicionalmente, todo este paquete deberá finalizarse con el hash MD5 del conjunto, certificando así que la información recibida es la que fue enviada desde el origen. Esto es sólo una recomendación a futuro y deberá ser evaluada por ambas partes como un proyecto aparte.

Para cada CAP deberá implementarse un firewall de modo que sólo estén abiertos los puertos que se utilicen para la aplicación, mail y mensajería. Visto y considerando el desempeño y papel que tienen los CAPs, deberán bloquearse todos los paquetes ICMP ya que no tienen sentido a nivel interno. Deberán estár disponibles a la altura del GateWay para que el administrador local de infraestructura pueda hacer debuggings y correcciones en casos de contingencia.

También debe estár debidamente configurado un firewall desde la Sede Central hacia la salida al exterior, permitiendo el paso único de puertos sobre de nivel aplicativo. Se deberá habilitar exclusivamente la salida a Inteneret para servicios como SMTP y aquellos que necesariamente requieran de la red externa. Asimismo se negociará con la parte gerencial, ya que por lo general son los que demandan tener conectividad con Internet, y servicios de mensajería externos.

Los WebServers deben estár detrás del firewall dentro del NOC de la Sede Central. El mismo estára habilitado hacia el exterior para cumplimentar con las transacciones online del cliente. En casos futuros de pasar a un Application Server se deberá respetar las mismas reglas, reconfigurando el FireWall para que habilitar la entrada y salida hacia el mismo.

Backups

Dado a que se prevee un alto volumen de tráfico diario con la base de datos, se establecerá un backupeo de la base de datos, diariamente y en forma progresiva, los cuales serán pasados a cinta y almacenados en lugares debidamente custodiados, preferentemente bajo llave electrónica o mediante autenticación biométrica.

Para el servicio de directorio se bajará a un LDIF semanalmente, debido a que el mismo no sufrirá cambios en el corto plazo.

NOTA: estos backups son a nivel servidores y no lo referente a la información que por lo general maneja la base de datos, contemplado en el modelo 06, Modelo de Procesamiento. Estos backups se hacen en forma progresiva y se almacenan en cinta y es el respaldo ante incontingencias y desastre. Solamente en el caso del directorio adicionalmente se guardará el LDIF como se nombró recientemente.

Auditoría

Servers y software de base

Se deben activar todos los logs de los servers y software de base utilizado, con un grado moderado de información además del timestamp de cada evento detectado, e incluyendo de ser posible un owner que haya disparado el evento. Los mismos deberán ser backupeados regularmente a intervalos diarios y bajados a cinta, para auditar a futuro en caso de contingencias. Es fundamental e indispensable que entre los servicios que logueen se encuentren la base de datos de la aplicación (para detectar eventos a nivel transacción) y el directorio, para detectar intentos de intrusión.

Aplicación

La aplicación deberá emitir un archivo de log por cada evento ocurrido. Principalmente deberá auditarse la pantalla de login y el logout del usuario, para detectar quien entró a la aplicación, quien salió y a que hora, así como intentos de intrusión o adivinación de passwords.

Dentro de la aplicación se deberá loguear cada transacción crítica con la base (como inserts o updates, no es necesario autidar selects a este nivel, para ello estára el log de la base de dato propia). También deberán auditarse aquellas operaciones a nivel de negocio, como por ejemplo la anexión de un Afiliado y por quien fue realizada, con su respectivo timestamp.

Seguridad dentro de la aplicación

Desde el momento del desarrollo se deberán tener las precauciones necesarias para evitar ataques comunes. Es obligatorio que en ningún momento valores introducidos por el usuario sean llevados directamente a la base de datos. Las transacciones con la misma deben estar en una capa superior evitando ataques indirectos a la base de datos, como sql injection. En el caso de ser absolutamente necesario llevar el contenido de una entrada del usuario a una sentencia sql, la misma deberá obligatoriamente parsearse con expresiones regulares a fin de detectar que venga sql embebido en la misma, el cual pudiera ocasionar inclusive hasta el borrado de las tablas si se tuvieran los permisos necesarios.

Referido a esto último, se deberá prearmar un usuario para el acceso a la base de datos, el cual deba tener restringido el acceso a la misma para hacer operaciones sobre el esquema de la misma. El usuario en el cual se impersonificará la apliación deberá tener permiso de lectura sobre las tablas y escritura y update de las mismas, de ningún modo podrá hacer alteraciones al esquema físico que compone la base de datos de la aplicación.

Detección de intrusiones

Para respaldar la seguridad de los usuarios, se establece como máximo un número de 3 intentos seguidos de login. Si el cuarto intento es fallido, la aplicación debe lockear la cuenta del usuario vía LDAP e inhabilitar al mismo. Sólo el administrador LDAP deberá ser capaz de rehabilitar y poner online al usuario, y en caso de pérdida de password, el administrador LDAP deberá pisar el password y se requerirá al usuario que cambie el password en el dominio al reingresar a la estación de trabajo. Todo esto se hará desde la clase inetOrgPerson explicada en el modelo 14 – implementación de seguridad.

NOTA: el administrador pisará el password del usuario y habilitará los flags necesarios para que el dominio exija un ingreso de password para entrar por parte del usuario. Este paso es instantáneo y debe ser instruído el empleado a realizarlo automáticamente al confirmarle el administrador que su password está listo para ser llenado. De la misma manera al ingresar un nuevo usuario se procederá de la misma manera. El acceso a una terminal física por agentes externos se debería contemplar en una documentación aparte acerca de seguridad a nivel organizacional, pero de todas formas debe estar garantizado que un extraño realice un acceso a una terminal propia de la empresa justo en el momento en que su password está vulnerable.

Glosario de términos para los estandares utilzados

Si bien todo lo usado en este documento son estándares internacionales altamente utilizados a nivel mundial, esta última sección provee un mini glosario con aquellos términos que puedan resultar de difícil comprensión para el lector.

ISO (Internacional Organization for Standarization):organización mundial cuyo objetivo es la normalización de un gran número de actividades y procedimientos a nivel corporativo, científico o de procedimiento.

IETF (Internet Engineer Task Force):organización mundial dedicada a la estandarización de protocolos de red disponibles públicamente en internet en RFCs.

RFC (Request for Comments):cada RFC es la definición de un protocolo de la IETF donde se incluyen todos los detalles e interfaces de los mismos, los cuales deben ser respetados estrictamente para mantener compatibilidad en las comunicaciones.

ISO 17799:2002 esquema-1: estándar a nivel internacional desarrollado por ISO para tratar la seguridad en tecnología de la información. Este estandar es requerido a nivel megacorporativo y normaliza todo el desenvolvimiento relacionado a la información tanto electrónica como no electrónica. Este documento es una versión acotada de los pasos a seguir propuestos por este esquema.

Directorio X.500:se cita la definición provista por la Universidad de Murcia, España acerca de este estándar “X.500 como normativa nace como un intento de impulsar la construcción de un servicio de Directorio a nivel mundial, totalmente distribuido para proporcionar servicio tanto a personas como a máquinas. La normativa ha sido desarrollada conjuntamente por ISO y el CCITT, dando lugar en 1988 a la primera serie de recomendaciones”. En resumen, es una base de datos jerárquica con interfaces de acceso bien definidas y estrictas.

DAP (Directory Access Protocol): es parte del estándar X.500 y define una de las interfaces con el directorio.

LDAP (Lightway Directory Access Protocol):es el estándar usado hoy en día para el acceso a directorios X.500. En un primer momento se utilizaba DAP pero se realizó un acotamiento del mismo protocolo restándole complejidad poco o nunca utilizada, resultando este protocolo que se define en las RFC de la IETF citadas al comienzo del documento.

LDAP URI: protocolo de acceso a directorio vía una URL, descrita en una RFC de la IETF.

LDIF:estándar de serialización de los objetos del directorio, tambipen descrito en una RFC de la IETF. Mediante este protocolo se pueden tener objetos serializados. Adicionalmente, establece una interfaz con el directorio tanto para exportar como para importar archivos de este tipo, facilitando backups de la base, y generación de multiples objetos.

TCP:protocolo de transporte. Es parte de la pila TCP/IP y se ubica en la capa de transporte. Su objetivo es garantizar la transmisión de la información y garantizar que la misma llegue a las capas superiores en el orden en que fue mandada.

Puerto TCP:es el punto de acceso al servicio (SAP) de las capas superiores (aplicación, presentación y sesión). Las aplicaciones que se comunican a través de la red deberán establecer un número llamado puerto tanto de origen como destino, de modo de que el protocolo TCP pueda trabajar para múltiples aplicaciones simultáneamente.

SSL (Secure Socket Layer):protocolo para trasmisión de informción en modo seguro a través de una red, desarrollado por Netscape. El mismo descansa sobre TCP, y utiliza certificados clave pública/privada para realizar una transmisión encriptada sobre un canal.

SFTP (Secure File Transfer Protocol):protocolo utilizado principalmente para hacer subida y bajada de archivos entre máquinas remotas. Es FTP resposando sobre una capa SSL.

SSH (Secure Shell):protocolo reemplazante del RLogin el cual reposa sobre una transmisión encriptada mediante certificados correspondientes.

SCP (Secure Copy):protocolo que reposa sobre SSH para realizar subida y bajada de archivos entre terminales remotas, encriptando la información que viaja por la red.

NOC (Networt Operation Center):lugar físico donde residen servidores y dispositivos de networking de capa 1 a la 3, enfocados primordialmente en mantener la infraestructura de red de una o varias organizaciones, y en menor grado el funcionamiento de servicios. Si priman servers de información sobre los dispositivos de networking suele llamarse DataCenter.

RACK:proveniente del inglés, dícese del armario donde residen diversos dispositivos de networking como servers, switches, hubs y routers. Los mismos vienen construídos para tales fines y los dispositivos proveen soportes estandarizados para poder ser apilados en los mismos.

SMB/CIFS:protocolo utilizado para el compartimiento de recursos para grupos de trabajo, proveyendo reglas como autenticación y autorización a recursos.

PDC:siglas de Primary Domain Controler. Es el server que se encarga de realizar la autenticación y autenticación en un dominio SMB.

BDC: realiza el mismo trabajo que el server PDC, pero a nivel secundario, es decir, retoma su actividad en caso de detectar que sa crasheado el PDC.

Encriptación LanManager: se toma el password del usuario y se lo trunca a 14 bytes (o se lo rellena si no llega a esta cantidad). Con estos 14 bytes se encripta 3 veces un string predefinido de 8 bytes utilizando el algoritmo DES.

Encriptación NT:se toma el password del usuario, se lo convierte a unicode y se le aplica un hash MD4. Muy fácil de romper.

ISP (Internet Service Provider):compañía proveedora de enlaces corporativos y/o hogareños para conectividad a internet o propia.

SMTP (Simple Mail Transfer Protocol):protocolo para el envío de mensajería (llamado típicamente ‘e-mail’) a través de una red. Es RFC en la IETF.

No repudiation:metodología a nivel electrónico que garantiza que una actividad o documento ejecutada por una entidad (individuo, corporación, etc), no puede ser refutada por la misma.

SQL (Structured Query Language):desarrollado originalmente por IBM, es un estándar para comunicación con una base de datos relacional. Hoy en día existe un ANSI base del que parten todos los motores, y customizado según el motor en particular, lo que lo hace un lenguaje débil y poco portable, a diferencia de LDAP.

Application Server:Servidor de aplicaciones Java tales como JSP o Servlets (o los más recientes Portlets). Proveen servicios a nivel portal para aplicaciones tanto de intrnet como extranet.

JAVA:lenguaje originalmente llamado OAK desarrollado por Sun Microsystems, totalmente orientado a objetos. El mismo es interpretado por una JVM (máquina virtual), la cual posee la desvirtud de consumir muchos recursos de la máquina, y a su vez no permite realizar tareas de bajo nivel, sin utilizar la interfaz de lenguaje nativo.

Diseño de la implementación del menú y seguridad de acceso

Anexos

Estándares de diseño de interfaces

Informe de evolución del diseño

Planificación de la exposición

1.3. Especificación de casos de uso

Página 3

Técnicas de Diseño (75.10)

III

6.1.2. Línea de tiempo mensual

2005-06-25T17:35:35