INFORME FINAL PRÁCTICA CRHISTIAN CAMILO TABORDA PAREJA · informe final prÁctica crhistian camilo taborda pareja programa de ingenierÍa en sistemas y computaciÓn departamento

INFORME FINAL PRÁCTICA

CRHISTIAN CAMILO TABORDA PAREJA

PROGRAMA DE INGENIERÍA EN SISTEMAS Y COMPUTACIÓN

DEPARTAMENTO DE SISTEMAS FACULTAD DE INGENIERÍAS

UNIVERSIDAD DE CALDAS

Manizales, Junio 23 del 2018

CONTENIDO

1. Introducción

2. Objetivos

2.1. Objetivo general

2.2. Objetivos específicos

3. Otras actividades

4. Desarrollo

5. Reflexiones

6. Bibliografía

1. Introducción

El objetivo de este informe es documentar todo el proceso de práctica realizado durante el primer semestre del presente año en CONFA.

En este informe se detallan los resultados de un proceso de investigación sobre la tecnología JAVA, la documentación de todo un proceso de desarrollo de software y la documentación del proceso de ETL sobre una base de datos.

CONFA como caja de compensación hace parte del Sistema del Subsidio Familiar en Colombia. Cumplen una función social y se encuentran sometidas al control y vigilancia del Estado en la forma establecida por la Ley. Esta corporación funciona gracias a los aportes que realizan las empresas afiliadas equivalentes al 4% sobre el valor total de su nómina; así desarrollan los diferentes programas y servicios.

Por lo anterior mencionado es de vital importancia para Confa garantizar calidad, integridad y consistencia de la información en sus sistemas para poder llevar a cabo correctamente todas sus funciones como caja de compensación.

2. Objetivos

2.1. Objetivo general Implementar los requerimientos del módulo de salud con sus respectivas

pruebas y documentación, además de realizar una investigación sobre la

tecnología JAVA 9 que proveerá las bases para crear un prototipo utilizando

dicha tecnología.

2.2. Objetivos específicos

■ Desarrollar un prototipo cliente servidor en tecnología JAVA 9 para definir los alcances que posee dicha tecnología y su beneficio para la empresa.

■ Verificar el diseño de estructuras de bases de datos sobre el motor

Oracle requeridas para el módulo de salud para identificar posibles

inconsistencias.

■ Desarrollar los requerimientos asignados para el módulo de salud,

creando proyecto base implementado sobre Java EE, utilizando

framework JSF (JavaServer Faces) con la librería de código abierto

PrimeFaces y complementado con la plantilla de Ultima para el

módulo de salud.

■ Implementar las pruebas técnicas para el módulo de salud.

■ Documentar la solución para el módulo de salud.

■ Documentar el proceso de extracción, transformación y carga sobre la

base de datos de CONFA.

En total se desarrollaron 4 actividades, a continuación se documenta cada una de ellas.

Actividad # 1

Esta actividad pertenece a un proyecto diferente, el proyecto incluye el manejo de las

funciones de cine de CONFA que es un aplicativo web para la gestión de entradas al

auditorio de cine, consistió en hacer que cualquier imagen cargada en un banner se ajustará

automáticamente al tamaño del mismo sin verse afectada su visualización.

Se realizaron los siguientes cambios en las propiedades: style.css

Se realizaron los siguientes cambios en las propiedades: script.js

Resultado final.

Actividad # 2

El proyecto SALUD WEB se presentó una incidencia no planeada que se basa en mantener

la navegación del aplicativo de escritorio en el aplicativo web, para lograr este objetivo se

realizó un análisis detallado del aplicativo de escritorio para entender su navegación y así

poder implementarla en el aplicativo web, esto conllevóinvertir un tiempo en la curva de

aprendizaje para dominar dicho requerimiento.

Para mantener dicha navegación se diseñó una clase con una lista en la cual a medida que

se navega en el aplicativo web las URL de cada vista se almacenan en dicha lista y cuando

se termina de realizar alguna acción o de abandonar una vista dicha URL se elimina,

logrando con esto el control de todas las vistas visitadas y así lograr la navegación que se

tiene en el aplicativo de escritorio

A continuación, se documenta la clase “Navegacion.java” que fue definida para llevar dicho

control:

Actividad # 3

El proyecto SALUD WEB se hicieron mejoras al formulario de parametrización simple de

departamentos para adaptarlo a las necesidades que tienen los formularios compuestos que

lo incluyen en su parametrización.

Documentación del código para el formulario de departamentos:

Clase departamento:

Controlador: MaestroSimpleBean.java:

Clase que implementa el acceso a la base de datos: ParametrizacionImpl.java:

Mockups para el formulario de parametrización de departamentos:

Departamentos listar:

Departamentos crear o editar:

Pantallas finales:

Listar departamentos:

Crear o editar departamentos:

Diseño de las pruebas:

a) Árbol de condiciones.

Formulario de parametrización para los departamentos:

b) Listado de pruebas derivado del árbol (por rama):

Formulario de parametrización para los departamentos:

Existente

Código

No existente

En blanco

Texto

Departamento

En blanco

- Código:

o En blanco

o Existente

o No existente

- Departamento:

o Texto

o En blanco

Pruebas:

1- Datos correctos: Código no existe, Departamento texto.

2- Código en blanco

3- Código existente

5- Departamento en blanco

Resultados de las pruebas:

Formulario de parametrización para los departamentos

Caso de Prueba Valores ingresados Resultados obtenidos ¿Pasó?

Datos correctos:

Código no existe,

Departamento texto.

-código: “030”

-Nombre: “Caldas”

-Departamento:

“Caldas”

Si

Código en blanco -Código: Mensaje indicando que se debe

ingresar el código.

Si

Código existente -Código: “010”

Si

Departamento en

blanco

-Departamento: Mensaje indicando que se debe

ingresar el departamento.

Si

Diagramas de secuencia para el formulario de departamentos:

Método para guardar o editar departamentos:

Método para eliminar un departamento:

Actividad # 4

Surgió la necesidad de un formulario para la consulta de activos fijos de la empresa y su

responsable. A continuación se documenta el desarrollo del formulario.

Documentación del código para el formulario de consulta de activos fijos:

Clase activoFijo:

Controlador: activoFijoBean.java:

Clase que implementa el acceso a la base de datos: activoFijoImpl.java:

Mockups para el formulario de consulta de activos fijos:

activosFijoslistar:

Pantallas finales:

Listar activos fijos

Diseño de las pruebas:


Formulario de consulta de activos fijos:


Formulario de consulta de activos fijos:

- activo:

o En blanco

o Existente

o No existente

- cédula:

o En blanco

o Existente

o No existente

Pruebas:

Existente

activo

No existente

En blanco

Texto

Existente

cédula

No existente

En blanco

1- Datos correctos: activo existe.

2- Datos correctos: cédula existe.

3- activo en blanco

4- activo no existe

5- cédula en blanco

6- cédula no existe

Resultados de las pruebas:

Formulario de consulta de activos fijos


Datos correctos:

activo existe.

-activo: “41458” Se muestra la tabla con la

descripción, nombre del centro

de costos,estado del activo y su

respectivo responsable.

Si

Datos correctos:

cédula existe.

-cedula: “1060878989” Se muestra la tabla con la

descripción, nombre del centro

de costos,estado del activo y su

respectivo responsable.

Si

activo en blanco -activo: Mensaje indicando que se debe

ingresar el activo.

Si

activo no existe -activo: “010” Mensaje indicando que el activo

no existe

Si

cédula en blanco -cedula: Mensaje indicando que se debe

ingresar la cédula.

Si

cédula no existe -cedula: “1087727654” Mensaje indicando que la cédula

no existe

Si

Diagramas de secuencia para el formulario de consulta de activos fijos:

3. Desarrollo Para el desarrollo se utilizó la metodología SCRUM la cual provee las herramientas para un proceso de desarrollo de software rápido y efectivo por parte del equipo.

A continuación se documenta cada una de las iteraciones realizadas en el proceso de práctica: formularios de parametrización simple y compuesta del proyecto SALUD WEB que en total fueron 4 iteraciones, posteriormente se realizó otra iteración para desarrollar un formulario de completitud de datos y por último se realizó un proceso de ETL (Extracción, transformación y carga) sobre una base de datos de CONFA.

Iteración # 1: En esta iteración se desarrollaron los requerimientos asociados a los formularios de parametrización simple del proyecto SALUD WEB

Planeación:

Lista de chequeo: se define una lista de chequeo para evaluar el estado de los requerimientos del proyecto SALUD WEB:

Pregunta S/N Observaciones

¿Se especifican concretamente los campos a parametrizar en los formularios?

¿Se especifican los formatos de datos y las validaciones que se deben realizar en cada campo?

¿Se especifican las dependencias internas entre los campos?

¿Es claro el orden en que se deben realizar los formularios?

¿Se proporciona una documentación detallada de la relación de los campos del formulario con los de la base de datos?

¿La navegación indicada es clara para una rápida ubicación de los formularios?

¿Se especifica la función del formulario de manera concreta? (Incluyendo entradas, salidas y procesos necesarios)

¿El orden de asignación y desarrollo de los formularios simples es acorde para que no se presenten retrasos en el desarrollo de los formularios compuestos?

¿Los tiempos asignados para el desarrollo de los formularios son coherentes y acordes a la dificultad que puedan conllevar?

¿Se especifican restricciones adicionales (si se necesitan), como seguridad, tiempos, etc.?

Mockups formularios de parametrización. Mockup menú:

Vista para listar las especialidades médicas:

Formulario de parametrización para crear o editar las especialidades médicas:

Vista para listar las plantillas de historias clínicas:

Formulario de parametrización para crear o editar las plantillas de historias clínicas:

Vista para listar los mensajes institucionales:

Formulario de parametrización para crear o editar los mensajes institucionales:

Vista para listar las ocupaciones:

Formulario de parametrización para crear o editar las ocupaciones:

Vista para listar los tipos de admisión:

Formulario de parametrización para crear o editar los tipos de admisión:

Vista para listar los tipos de habitación-cama:

Formulario de parametrización para crear o editar los tipos de habitación-cama:

Vista para listar las tarifas:

Formulario de parametrización para crear o editar las tarifas:

Vista para listar las unidades de medida:

Formulario de parametrización para crear o editar las unidades de medida:

Vista para listar las unidades operativas:

Formulario de parametrización para crear o editar las unidades operativas:

Vista para listar las tarifas de cuentas X pagar:

Formulario de parametrización para crear o editar las tarifas de cuentas X pagar:

Vista para listar los servicios:

Formulario de parametrización para crear o editar los servicios:

Vista para listar las unidades de negocio:

Formulario de parametrización para crear o editar las unidades de negocio:

Diagramas de secuencia formularios de parametrización:

Método para consultar las especialidades médicas:

Método para eliminar especialidades médicas:

Método para guardar o editar especialidades médicas:

Método para consultar las plantillas de historias clínicas:

Método para eliminar plantillas de historias clínicas:

Método para guardar o editar las plantillas de historias clínicas:

Método para consultar los mensajes institucionales:

Método para eliminar los mensajes institucionales:

Método para guardar o editar los mensajes institucionales:

Método para consultar las ocupaciones:

Método para eliminar las ocupaciones:

Método para guardar o editar las ocupaciones:

Método para consultar los tipos de admisión:

Método para eliminar los tipos de admisión:

Método para guardar o editar los tipos de admisión:

Método para consultar los tipos de habitación-cama:

Método para eliminar los tipos de habitación-cama:

Método para guardar o editar los tipos de habitación-cama:

Método para consultar las tarifas:

Método para eliminar las tarifas:

Método para guardar o editar las tarifas:

Método para consultar las unidades de medida:

Método para eliminar unidades de medida:

Método para guardar o editar unidades de medida:

Método para consultar las unidades operativas:

Método para eliminar las unidades operativas:

Método para guardar o editar las unidades operativas:

Método para consultar las tarifas de cuentas X pagar:

Método para eliminar tarifas de cuentas X pagar:

Método para guardar o editar tarifas de cuentas X pagar:

Método para consultar los servicios:

Método para eliminar los servicios:

Método para guardar o editar los servicios:

Método para consultar las unidades de negocio:

Método para eliminar las unidades de negocio:

Método para guardar o editar las unidades de negocio:

Especificación de casos de prueba formularios de parametrización. A continuación, se especificarán los casos de prueba para los formularios de parametrización que serán desarrollados:

a) Árbol de condiciones. Formulario de parametrización para las especialidades médicas:

Formulario de parametrización para los mensajes institucionales: Formulario de parametrización para las ocupaciones:

Formulario de parametrización para las tarifas:

Existente Código especialidad médica No existente

En blanco

Texto Descripción

En blanco

Existente Código mensaje

No existente

En blanco

Texto mensaje

En blanco

Existente Código ocupación

No existente

En blanco

Texto Descripción

En blanco

Existente Código tarifa

No existente

En blanco

Formulario de parametrización para las unidades de medida:

Formulario de parametrización para las tarifas de cuentas por pagar: Formulario de parametrización para los servicios:

En blanco

Texto

Texto Descripción

En blanco

Existente Código unidad de medida No existente

En blanco

Texto Descripción

En blanco

Existente Código tarifa

No existente

En blanco

Texto Descripción

En blanco

Existente Código servicio

No existente

Descripción

En blanco

Formulario de parametrización para las unidades de negocio:

Formulario de parametrización para las unidades operativas:

Formulario de parametrización para los tipos de habitación-cama:

Existente Código unidad de negocio No existente

En blanco

Texto Descripción

En blanco

Existente Código unidad operativa No existente

En blanco

Texto Descripción

En blanco

Positivo Longitud <= 10

Longitud > 10

Numérico Negativo Valor

No Numérico

En blanco

Existente Código tipo habitación-cama No existente

En blanco

Texto Descripción

En blanco

Formulario de parametrización para los tipos de admisión:

Negativo

Longitud <= 10 Positivo

Longitud > 10

Numérico

Entero

Decimal Valor día

No Numérico

En blanco

Texto

Características

En blanco

Existente Código tipo admisión

No existente

En blanco

Texto Descripción

En blanco

Atención hospitalaria Atención

Urgencias

Atención ambulatoria

Seleccionado

Requiere habitación-cama No seleccionado

Seleccionado

Cirugía

No seleccionado

Formulario de parametrización para las plantillas de historias clínicas:

Seleccionado

Permitir atención a usuarios morosos

No seleccionado

Seleccionado

Requiere orden

No seleccionado

Seleccionado

Maneja clasificación

No seleccionado

Existente Código plantilla

No existente

En blanco

Texto Descripción

En blanco

Entero

Positivo

Longitud > 10

Longitud <= 10

Numérico

Negativo

Decimal Remisión

No Numérico

En blanco

Edad inicial

Menor que edad final

Mayor que edad final

Numérico

No numérico

En blanco

Ambos Sexo

Longitud <= 5 Masculino

Positivo Longitud > 5 Femenino

Entero Negativo

Decimal

Mayor que edad inicial

Menor que edad inicial

a) Listado de pruebas derivado del árbol (por rama): Formulario de parametrización para las especialidades médicas:

- Código especialidad:

o En blanco o Existente o No existente

- Descripción: o En blanco o Texto

Pruebas:

1- Datos correctos: código especialidad no existe y descripción con texto. 2- Código especialidad en blanco 3- Código especialidad existente 4- Descripción en blanco

Formulario de parametrización para los mensajes institucionales:

- Código mensaje: o En blanco o Existente o No existente

- Mensaje: o En blanco o Texto

Longitud <= 5

Longitud > 5

Negativo

Positivo

Decimal

Entero

Seleccionado

Requiere Asociar orden No seleccionado

seleccionado

Procedimiento

No seleccionado

seleccionado

Inactiva

No seleccionado

Pruebas: 1- Datos correctos: código mensaje institucional no existe y mensaje con texto. 2- Código mensaje en blanco 3- Código mensaje existente 4- mensaje en blanco

Formulario de parametrización para las ocupaciones:

- Código ocupación:



Pruebas:

1- Datos correctos: código ocupación no existe y descripción con texto. 2- Código ocupación en blanco 3- Código ocupación existente 4- Descripción en blanco

Formulario de parametrización para las tarifas:

- Código tarifa:



Pruebas:

1- Datos correctos: código tarifa no existe y descripción con texto. 2- Código tarifa en blanco 3- Código tarifa existente 4- Descripción en blanco

Formulario de parametrización para las unidades de medida:

- Código unidad de medida:



Pruebas:

1- Datos correctos: código unidad de medida no existe y descripción con texto. 2- Código unidad de medida en blanco 3- Código unidad de medida existente 4- Descripción en blanco

Formulario de parametrización para las tarifas de cuentas x pagar:

- Código tarifaCxP:



Pruebas:

1- Datos correctos: código tarifaCxP no existe y descripción con texto. 2- Código tarifaCxP en blanco 3- Código tarifaCxP existente 4- Descripción en blanco

Formulario de parametrización para los servicios:

- Código servicio:



Pruebas:

1- Datos correctos: código servicio no existe y descripción con texto. 2- Código servicio en blanco 3- Código servicio existente 4- Descripción en blanco

Formulario de parametrización para las unidades de negocio:

- Código unidad de negocio:



Pruebas:

1- Datos correctos: código unidad de negocio no existe y descripción con texto. 2- Código unidad de negocio en blanco 3- Código unidad de negocio existente 4- Descripción en blanco

Formulario de parametrización para las unidades operativas: - Código unidad operativa:


- Descripción: o En blanco

o Texto - Valor:

o En blanco o No numérico o Numérico, negativo o Numérico, positivo, longitud > 10 o Numérico, positivo, longitud <= 10

Pruebas:

1- Datos correctos: código unidad operativa no existe, descripción con texto y Numérico, positivo, longitud <= 10

2- Código unidad operativa en blanco 3- Código unidad operativa existente 4- Descripción en blanco 5- Valor en blanco. 6- Valor no numérico 7- Valor numérico, negativo 8- Valor numérico, positivo, longitud > 10

Formulario de parametrización para los tipos de habitación-cama:

- Código tipo habitación-cama:



- Valor día: o En blanco o No numérico o Numérico, decimal o Numérico, entero, negativo o Numérico, entero, positivo, longitud > 10 o Numérico, entero, positivo, longitud <= 10

- Características: o En blanco o Texto

Pruebas:

1- Datos correctos: código tipo habitación-cama no existe, descripción con texto, valor día numérico, entero, positivo, longitud <= 10 y características con texto

2- Código tipo habitación-cama en blanco 3- Código tipo habitación-cama existente 5- Descripción en blanco 6- Valor día en blanco. 7- Valor día no numérico 8- Valor día numérico, decimal 9- Valor día numérico, entero, negativo 10- Valor día numérico, entero, positivo, longitud > 10 11- Características en blanco

Formulario de parametrización para los tipos de admisión:

- Código tipo admisión:



- Atención: o Atención hospitalaria o Urgencias o Atención ambulatoria

- Características: o En blanco o Texto

- Requiere habitación-cama: o Seleccionado o No seleccionado

- Cirugía:

o Seleccionado o No seleccionado

- Permitir atención a usuarios morosos: o Seleccionado o No seleccionado

- Requiere orden: o Seleccionado o No seleccionado

- Maneja clasificación: o Seleccionado o No seleccionado

Pruebas:

1- Datos correctos a: código tipo admisión no existe, descripción con texto, atención hospitalaria, requiere habitación, cirugía, no atención morosos, requiere orden y maneja clasificación.

2- Datos correctos b: código tipo admisión no existe, descripción con texto, urgencias, requiere habitación, cirugía, atención morosos, no requiere orden y maneja clasificación.

3- Datos correctos c: código tipo admisión no existe, descripción con texto, atención ambulatoria, no requiere habitación, no cirugía, atención morosos, requiere orden y maneja clasificación.

4- Datos correctos d: código tipo admisión no existe, descripción con texto, atención urgencias, requiere habitación, cirugía, atención morosos, requiere orden y no maneja clasificación.

5- Código tipo admisión en blanco 6- Código tipo admisión existente 7- Descripción en blanco 8- Características en blanco

Formulario de parametrización para las plantillas de historias clínicas:

- Código plantilla historia clínica:



- Remisión: o En blanco o No numérico o Numérico, decimal o Numérico, entero, negativo o Numérico, entero, positivo, longitud > 10 o Numérico, entero, positivo, longitud <= 10

- Sexo: o Ambos o Masculino o Femenino

- Edad inicial: o En blanco o No numérico o Numérico, mayor que edad final o Numérico, menor que edad final

- Edad Final: o En blanco o No numérico o Numérico, menor que edad inicial o Numérico, mayor que edad inicial

- Requiere asociar orden: o Seleccionado o No seleccionado

- Procedimiento o Seleccionado o No seleccionado

- Inactiva: o Seleccionado o No seleccionado

Pruebas: 1- Datos correctos a: código plantilla historia clínica no existe, descripción con texto,

remisión numérica, entero, positivo, longitud <= 10, sexo ambos, edad inicial numérico, menor que edad final, edad final numérico, mayor que edad inicial, Requiere asociar orden, sin procedimiento, activa

2- Datos correctos b: código plantilla historia clínica no existe, descripción con texto, remisión numérica, entero, positivo, longitud <= 10, sexo masculino, edad inicial numérico, menor que edad final, edad final numérico, mayor que edad inicial, no requiere asociar orden, con procedimiento, inactiva

3- Datos correctos c: código plantilla historia clínica no existe, descripción con texto, remisión numérica, entero, positivo, longitud <= 10, sexo femenino, edad inicial numérico, menor que edad final, edad final numérico, mayor que edad inicial, no requiere asociar orden, sin procedimiento, inactiva

4- Código plantilla historia clínica en blanco 5- Código plantilla historia clínica existente 6- Descripción en blanco 7- Remisión en blanco 8- Remisión no numérica 9- Remisión numérica, decimal 10- Remisión numérica, entero, negativo 11- Remisión numérica, entero, positivo, longitud > 10 12- Edad inicial en blanco

13- Edad inicial no numérica 14- Edad inicial numérica, mayor que edad final 15- Edad final en blanco 16- Edad final no numérica 17- Edad final numérica, menor que edad inicial

Documentación del código formularios de parametrización

Todas las clases tienen la siguiente documentación:

clase tipo de admisión:

Controlador: MaestroSimpleBean.java

clase que opera con la base de datos: ParametrizacionImpl.java

Clase Tipos de habitación-cama:

Controlador: ServiciosParametrosBean.java

clase que opera con la base de datos: ServiciosParametrosImpl.java

Clase tarifa:

Controlador: ConvenioBean.java

clase que opera con la base de datos: ParametrizacionConveniosImpl.java

Clase unidad de medida:

Controlador: ConfiguracionBean.java

clase que opera con la base de datos: ParametrizacionConfiguracionImpl.java

Clase unidad operativa

Controlador: ConvenioBean.java

Clase que opera con la base de datos: parametrizacionConveniosImpl.java

Clase servicio


Clase que opera con la base de datos: Parametrizacionimpl.java

Clase especialidad médica:



Clase mensaje institucional:


Clase que opera con la base de datos: Parametrizacionimpl.java.java

Clase ocupación:

Documentación de los métodos para la administración de las ocupaciones:

Controlador: AfiliadosBean.java

Clase que opera con la base de datos: ParametrizacionAfiliadosImpl.java

Clase tarifaCXP:



Clase unidad de negocio:

Controlador: maestroSimplebean.java

Clase que opera en la base de datos: Parametrizacionimpl.java

Clase plantilla historia clínica:


Clase que opera en la base de datos: Parametrizacionimpl.java

Pantallas finales formularios de parametrización

Menú principal:

Pantalla especialidades médicas consultar:

Pantalla especialidades médicas crear o editar:

Pantalla plantillas historias clínicas consultar:

Pantalla plantillas historias clínicas crear o editar:

Pantalla mensajes institucionales consultar:

Pantalla mensajes institucionales crear o editar:

Pantalla ocupaciones consultar:

Pantalla ocupaciones crear o editar:

Pantalla tipos de admisión consultar:

Pantalla tipos de admisión crear o editar:

Pantalla tipos de habitación-cama consultar:

Pantalla tipos de habitación-cama crear o editar:

Pantalla tarifas consultar:

Pantalla tarifas crear o editar:

Pantalla unidades de medida consultar:

Pantalla unidades de medida crear o editar:

Pantalla unidades operativas consultar:

Pantalla unidades operativas crear o editar:

Pantalla tarifas CXP consultar:

Pantalla tarifas CXP crear o editar:

Pantalla consultar servicios consultar:

Pantalla servicios crear o editar:

Pantalla unidades de negocio consultar:

Pantalla unidades de negocio crear o editar:

Resultados de las pruebas formularios de parametrización

Elaborado por: Crhistian Camilo Taborda Pareja

Elemento probado:

Formularios de parametrización proyecto salud web

Fecha: 13/03/2018

Formulario de parametrización para las especialidades médicas


Datos correctos: código especialidad no existe y descripción con texto.

-Código: “102” -Descripción: “radiología”

Si

Código especialidad en blanco

-Código: Mensaje indicando que se debe ingresar el código de la especialidad.

Si

Código especialidad existente

-Código: “001”

Si

Descripción en blanco -Descripción: Mensaje indicando que se debe ingresar la descripción de la especialidad.

Si

Formulario de parametrización para los mensajes institucionales


Datos correctos: código mensaje institucional no existe y mensaje con texto.

-Código: “99” -Mensaje: “Hola a todos”

Si

Código mensaje en blanco

-Código: Mensaje indicando que se debe ingresar el código del mensaje.

Si

Código mensaje existente

-Código: “11”

Si

mensaje en blanco -Mensaje: Mensaje indicando que se debe ingresar el contenido del mensaje.

Si

Formulario de parametrización para las ocupaciones


Datos correctos: código ocupación no existe y descripción con texto.

-Código: “827” -Descripción: “cajero”

Si

Código ocupación en blanco

-Código: Mensaje indicando que se debe ingresar el código de la ocupación.

Si

Código ocupación existente

-Código: “22”

Si

Descripción en blanco -Descripción: Mensaje indicando que se debe ingresar la descripción de la ocupación.

Si

Formulario de parametrización para las tarifas


Datos correctos: código tarifa no existe y descripción con texto.

-Código: “323” -Descripción: “SOAT”

Si

Código tarifa en blanco

-Código: Mensaje indicando que se debe ingresar el código de la tarifa.

Si

Código tarifa existente -Código: “33”

Si

Descripción en blanco -Descripción: Mensaje indicando que se debe ingresar la descripción de la tarifa.

Si

Formulario de parametrización para las unidades de medida


Datos correctos: código unidad de medida no existe y descripción con texto.

-Código: “443” -Descripción: “m/s”

Si

Código unidad de medida en blanco

-Código: Mensaje indicando que se debe ingresar el código de la unidad de medida.

Si

Código unidad de medida existente

-Código: “87”

Si

Descripción en blanco -Descripción: Mensaje indicando que se debe ingresar la descripción de la unidad de medida.

Si

Formulario de parametrización para las tarifas de cuentas X pagar


Datos correctos: código tarifaCxP no existe y descripción con texto.

-Código: “676” -Descripción: “IVA”

Si

Código tarifaCxP en blanco

-Código: Mensaje indicando que se debe ingresar el código de la tarifaCxP.

Si

Código tarifaCxP existente

-Código: “80”

Si

Descripción en blanco -Descripción: Mensaje indicando que se debe ingresar la descripción de la tarifaCxP.

Si

Formulario de parametrización para los servicios


Datos correctos: código servicio no existe y descripción con texto.

-Código: “122” -Descripción: “Atención inmediata”

Si

Código servicio en blanco

-Código: Mensaje indicando que se debe ingresar el código del servicio.

Si

Código servicio existente

-Código: “899”

Si

Descripción en blanco -Descripción: Mensaje indicando que se debe ingresar la descripción del servicio.

Si

Formulario de parametrización para las unidades de negocio


Datos correctos: código unidad de negocio no existe y descripción con texto.

-Código: “442” -Descripción: “$”

Si

Código unidad de negocio en blanco

-Código: Mensaje indicando que se debe ingresar el código de la unidad de negocio.

Si

Código unidad de negocio existente

-Código: “009”

Si

Descripción en blanco -Descripción: Mensaje indicando que se debe ingresar la descripción de la unidad de negocio.

Si

Formulario de parametrización para las unidades operativas


Datos correctos: código unidad operativa no existe,

-Código: “232” -Descripción: “Mm” -Valor: 1000

Si

descripción con texto y Numérico, positivo, longitud <= 10

Código unidad operativa en blanco

-Código: Mensaje indicando que se debe ingresar el código de la unidad operativa.

Si

Código unidad operativa existente

-Código: “45”

Si

Descripción en blanco -Descripción: Mensaje indicando que se debe ingresar la descripción de la unidad operativa.

Si

Valor en blanco -Valor: Por defecto se asigna el valor 0 y permite continuar

Si

Valor no numérico -Valor: lk78 El campo de texto tiene restricciones que no permiten ingresar letras, solo números

Si

Valor numérico, negativo

-Valor: -87 El campo de texto tiene restricciones que no permiten ingresar números negativos

Si

Valor numérico, positivo, longitud > 10

-Valor 3322357777.44 El campo de texto tiene restricciones que no permiten ingresar números de más de 10 dígitos de longitud

Si

Formulario de parametrización para los tipos de habitación-cama


Datos correctos: código tipo habitación-cama no existe, descripción con texto, valor día numérico, entero, positivo, longitud <= 10 y características con texto

-Código: “455” -Descripción: “Personal” -Valor: 255636 -Características: “Cama o habitación para una persona”

Si

Código tipo habitación-cama en blanco

-Código: Mensaje indicando que se debe ingresar el código del tipo de habitación-cama.

Si

Código habitación-cama existente

-Código: “087”

Si

Descripción en blanco -Descripción: Mensaje indicando que se debe ingresar la descripción del tipo de habitación-cama.

Si

Valor día en blanco -Valor: Por defecto se asigna el valor 0 Si

Valor día no numérico -Valor: o98p El campo de texto tiene restricciones que no permiten ingresar letras, solo números

Si

Valor día numérico, -Valor: 3.44 El campo de texto tiene Si

decimal restricciones que no permiten ingresar números decimales

Valor día numérico, entero, negativo

-Valor -448900 El campo de texto tiene restricciones que no permiten ingresar números negativos

Si

Valor día numérico, entero, positivo, longitud > 10

-Valor: 66543456777 El campo de texto tiene restricciones que no permiten ingresar números de más de 10 dígitos de longitud

Si

Características en blanco

-características: Este campo no es obligatorio, permite continuar

Si

Formulario de parametrización para los tipos de admisión


Datos correctos a: código tipo admisión no existe, descripción con texto, atención hospitalaria, requiere habitación, cirugía, no atención morosos, requiere orden y maneja clasificación.

-Código: “4311” -Descripción: “consulta urgencia” -Atención: “hospitalaria” -requiere habitación: seleccionado -cirugía: seleccionado -atención morosos: no seleccionado -requiere orden: seleccionado -maneja clasificación: seleccionado

Si

Datos correctos b: código tipo admisión no existe, descripción con texto, atención urgencias, requiere habitación, cirugía, atención morosos, no requiere orden y maneja clasificación.

-Código: “4312” -Descripción: “consulta” -Atención: “urgencias” -requiere habitación: seleccionado -cirugía: seleccionado -atención morosos: seleccionado -requiere orden: seleccionado -maneja clasificación: seleccionado

Si

Datos correctos c: código tipo admisión no existe, descripción con texto, atención ambulatoria, no requiere habitación, no cirugía, atención morosos, requiere orden y maneja clasificación.

-Código: “4313” -Descripción: “remitido” -Atención: “ambulatoria” -requiere habitación: no seleccionado -cirugía: no seleccionado -atención morosos:

Si

seleccionado -requiere orden: seleccionado -maneja clasificación: seleccionado

Datos correctos d: código tipo admisión no existe, descripción con texto, atención urgencias, requiere habitación, cirugía, atención morosos, requiere orden y no maneja clasificación.

-Código: “4314” -Descripción: “atención urgencia” -Atención: “urgencia” -requiere habitación: seleccionado -cirugía: seleccionado -atención morosos: seleccionado -requiere orden: seleccionado -maneja clasificación: no seleccionado

Si

Código tipo admisión en blanco

-Código: Mensaje indicando que se debe ingresar el código del tipo admisión.

Si

Código tipo admisión existente

-Código: “82”

Si

Descripción en blanco -Descripción: Mensaje indicando que se debe ingresar la descripción del tipo admisión.

Si

Características en blanco

-características: Este campo no es obligatorio, permite continuar

Si

Formulario de parametrización para las plantillas de historias clínicas


Datos correctos a: código plantilla historia clínica no existe, descripción con texto, remisión numérica, entero, positivo, longitud <= 10, sexo ambos, edad inicial numérico, menor que edad final, edad final numérico, mayor que edad inicial, Requiere asociar orden, sin procedimiento, activa

-Código: “5311” -Descripción: “patología” -Remisión: 1221 -sexo: “Ambos” -edad inicial: 0 -edad final: 50 -Requiere asociar orden: seleccionado -Procedimiento: no seleccionado -inactiva: no seleccionado

Si

Datos correctos b: código plantilla historia clínica no existe, descripción con texto, remisión

-Código: “66311” -Descripción: “cancerígeno” -Remisión: 123 -sexo: “masculino”

Si

numérica, entero, positivo, longitud <= 10, sexo masculino, edad inicial numérico, menor que edad final, edad final numérico, mayor que edad inicial, no requiere asociar orden, con procedimiento, inactiva

-edad inicial: 10 -edad final: 70 -Requiere asociar orden: no seleccionado -Procedimiento: seleccionado -inactiva: seleccionado

Datos correctos c: código plantilla historia clínica no existe, descripción con texto, remisión numérica, entero, positivo, longitud <= 10, sexo femenino, edad inicial numérico, menor que edad final, edad final numérico, mayor que edad inicial, no requiere asociar orden, sin procedimiento, inactiva

-Código: “911” -Descripción: “infectología” -Remisión: 1110 -sexo: “femenino” -edad inicial: 20 -edad final: 80 -Requiere asociar orden: no seleccionado -Procedimiento: no seleccionado -inactiva: seleccionado

Si

Código plantilla historia clínica en blanco

-Código: Mensaje indicando que se debe ingresar el código de la plantilla historia clínica

Si

Código plantilla historia clínica existente

-Código: “002”

Si

Descripción en blanco -Descripción: Mensaje indicando que se debe ingresar la descripción de la plantilla historia clínica.

Si

Remisión en blanco

-Remisión: Por defecto se asigna el valor 0 Si

Remisión no numérica

-Remisión: hy44 El campo de texto tiene restricciones que no permiten ingresar letras, solo números

Si

Remisión numérica, decimal

-Remisión: 3.22 El campo de texto tiene restricciones que no permiten ingresar números decimales

Si

Remisión numérica, entero, negativo

-Remisión: -222 El campo de texto tiene restricciones que no permiten ingresar números negativos

Si

Remisión numérica, entero, positivo, longitud > 10

-Remisión: 232123434333

El campo de texto tiene restricciones que no permiten ingresar números de más de 10 dígitos de longitud

Si

Edad inicial en blanco

-Edad inicial: Por defecto se asigna el valor 0 Si

Edad inicial no numérica

-Edad inicial: i88 El campo de texto tiene restricciones que no permiten ingresar letras, solo números

Si

Edad inicial numérica, mayor que edad final

-Edad inicial: 10 -Edad final: 5

Mensaje indicando que la edad inicial es mayor a la edad final

Si

Edad final en blanco

-Edad final: Por defecto se asigna el valor 0 Si

Edad final no numérica

-Edad final: h65 El campo de texto tiene restricciones que no permiten ingresar letras, solo números

Si

Edad final numérica, menor que edad inicial

-Edad final: 10 -Edad inicial: 25

Mensaje indicando que la edad final es menor a la edad inicial

Si

Iteración # 2: En esta iteración se desarrollaron los requerimientos asociados a los

formularios de parametrización compuesta del proyecto SALUD WEB, para la planeación se

pasó de usar excel a Trello que es una herramienta adecuada para la metodología

empleada(SCRUM).

Planeación:

Lista de Chequeo formularios de parametrización compuesta A continuación, analizaremos el detalle de los requerimientos asignados:



N En algunos requerimientos se nombran todos los campos a parametrizar.


N Los campos de algunos formularios son dependientes entre sí.


N


N

¿Se proporciona una documentación detallada N

de la relación de los campos del formulario con los de la base de datos?


S


S


S


N


N

¿Se consideraron las posibles incidencias al migrar de aplicativo de escritorio a web?

N

¿El orden de asignación de los formularios de parametrización compuesta es acorde a las dependencias de los formularios entre sí?

N

¿Los tiempos de desarrollo de los formularios de parametrización compuesta son acorde a la dependencia que tiene entre sí?

N

Mockups formularios de parametrización compuesta Vista para listar las variables de control:

Formulario de parametrización para crear o editar las variables de control:

Vista para listar las habitaciones - camas:

Formulario de parametrización para crear o editar las habitaciones - Camas:

Vista para listar las variables por modelo:

Formulario de parametrización para crear o editar las variables por modelo:

Diagramas de secuencia formularios de parametrización compuesta

Método para consultar las variables de control:

Método para guardar o editar las variables de control:

Método para eliminar las variables de control:

Método para consultar las habitaciones – camas:

Método para guardar o editar las habitaciones - camas:

Método para eliminar las habitaciones – camas:

Método para consultar las variables por modelo:

Método para guardar o editar las variables por modelo:

Método para eliminar las variables por modelo:

Especificación de casos de prueba formularios de parametrización. A continuación, se especificarán los casos de prueba para los formularios de parametrización compuesta que serán desarrollados:

a) Árbol de condiciones. Formulario de parametrización para las variables de control:

Texto

Mayor que máximo

Menor que máximo

Existente Variable

No existente

En blanco

Nombre Variable

En blanco

Seleccionada

Unidad de medida

En blanco Mayor que mínimo

Menor que mínimo

Positivo

Negativo Numérico

Máximo

No Numérico

En blanco

Positivo

Numérico Negativo

Mínimo

No Numérico

En blanco

Formulario de parametrización para las habitaciones - camas:

Formulario de parametrización para las variables por modelo:


Existente Hab cama

No existente

En blanco

Texto Descripción

En blanco

Seleccionado

Tipo

En blanco

Libre Estado

Limpieza

Ocupada

Reparación

Igual o posterior a la actual

Fecha

Anterior a la actual

Existente Código modelo

No existente

En blanco

Existente Variable

No existente

En blanco

Formulario de parametrización para las variables de control:

- Variable:


- Nombre variable: o En blanco o Texto

- Unidad de medida: o Seleccionada o En blanco

- Máximo: o En blanco o No numérico o Numérico, negativo o Numérico, positivo, menor que mínimo o Numérico, positivo, mayor que mínimo

- Mínimo: o En blanco o No numérico o Numérico, negativo o Numérico, positivo, mayor que máximo o Numérico, positivo, menor que máximo

Pruebas:

1- Datos correctos: variable no existe, nombre variable con texto, unidad de medida seleccionada, máximo mayor que mínimo y mínimo menor que máximo.

2- variable en blanco 3- variable existente 4- Nombre variable en blanco 5- Unidad de medida en blanco 6- Máximo en blanco 7- Máximo no numérico 8- Máximo numérico, negativo 9- Máximo numérico, positivo, menor que mínimo 10- Mínimo en blanco 11- Mínimo no numérico 12- Mínimo numérico, negativo 13- Mínimo numérico, positivo, mayor que máximo

Formulario de parametrización para las habitaciones - camas:

- Hab cama: o En blanco o Existente o No existente


- Tipo: o En blanco o Seleccionado

- Estado:

o Libre o Limpieza o Ocupada o Reparación

- Fecha: o Anterior a la actual o Igual o posterior a la actual

Pruebas:

1- Datos correctos: Hab cama no existe, descripción con texto, tipo seleccionado, estado libre, fecha igual o posterior a la actual

2- Datos correctos: Hab cama no existe, descripción con texto, tipo seleccionado, estado ocupada, fecha igual o posterior a la actual

3- Hab cama en blanco 4- Hab cama existente 5- Descripción en blanco 6- Tipo en blanco 7- Fecha anterior a la actual

Formulario de parametrización para las variables por modelo:

- Código modelo:


- Variable: o En blanco o Existente o No existente

Pruebas:

1- Datos correctos: código modelo no existe y variable no existe. 2- Código modelo en blanco 3- Código modelo existente 4- variable en blanco 5- variable existente

Documentación del código formularios de parametrización compuesta

Todas las clases tienen la siguiente documentación:

clase tipo variableControl:

Controlador: ConfiguaraciobBean.java


Clase habitación-cama:

Controlador: ServiciosParametrosBean.java

clase que opera con la base de datos: ServiciosParametrosImpl.java

Clase VariableXModelo:

Controlador: ConfiguraciónBean.java


Pantallas finales formularios de parametrización compuesta

Pantalla variables de control consultar:

Pantalla variables de control crear o editar:

Pantalla habitaciones -camas consultar:

Pantalla habitaciones-camas crear o editar:

Pantalla variables por modelo consultar:

Pantalla variables por modelo crear o editar:

Resultados de las pruebas proyecto SALUD WEB formularios de parametrización


Elemento probado:

Formularios de parametrización compuesta proyecto salud web

Fecha: 03/04/2018

Formulario de parametrización para las variables de control


Datos correctos: variable no existe, nombre variable con texto, unidad de medida seleccionada, máximo mayor que mínimo y mínimo menor que máximo.

-Variable: “FC” -Nombre variable: “Frecuencia cardíaca” -Unidad de medida: “pulsos/minuto” -Máximo: 120 -Mínimo: 50

Si

variable en blanco -Variable: Mensaje indicando que se debe ingresar la variable.

Si

variable existente -Código: “TMP”

Si

Nombre variable en blanco

-Nombre variable: Mensaje indicando que se debe ingresar el nombre de la variable.

Si

Unidad de medida en blanco

-Unidad de medida: Mensaje indicando que se debe seleccionar la unidad de medida.

Si

Máximo en blanco -Máximo: Por defecto se asigna el valor 0.00

Si

Máximo no numérico -Máximo: “sdsds” El campo de texto tiene restricciones que no permiten ingresar letras, solo números

Si

Máximo numérico, negativo

-Máximo: -122 El campo de texto tiene restricciones que no permiten ingresar números negativos

Si

Máximo numérico, positivo, menor que mínimo

-Maximo:100 -Mínimo:140

Mensaje indicando que el valor máximo no puede ser menor que el mínimo

Si

Mínimo en blanco -Mínimo: Por defecto se asigna el valor 0.00

Si

Mínimo no numérico -Mínimo: “sdsds” El campo de texto tiene restricciones que no permiten ingresar letras, solo números

Si

Mínimo numérico, negativo

-Mínimo: -32 El campo de texto tiene restricciones que no permiten ingresar números negativos

Si

Mínimo numérico, positivo, mayor que máximo

-Maximo:100 -Mínimo:140

Mensaje indicando que el valor máximo no puede ser menor que el mínimo

Si

Formulario de parametrización para las habitaciones - Camas


Datos correctos: Hab cama no existe, descripción con texto, tipo seleccionado, estado libre, fecha igual o posterior a la

-Hab cama: “99” -Descripción: “cama hospital” -Tipo:”Bipersonal” -Estado:”Libre” -Fecha: 12/12/2018

Si

actual

Datos correctos: Hab cama no existe, descripción con texto, tipo seleccionado, estado ocupada, fecha igual o posterior a la actual

-Hab cama: “122” -Descripción: “cama ips” -Tipo:”Unipersonal” -Estado:”Ocupada” -Fecha: 03/11/2018

Si

Hab Cama en blanco -Hab cama: Mensaje indicando que se debe ingresar el valor de hab cama.

Si

Hab cama existente - Hab cama: “01”

Si

Descripción en blanco -Descripción: Mensaje indicando que se debe ingresar la descripción.

Si

Tipo en blanco -Tipo: Mensaje indicando que se debe seleccionar el tipo.

Si

Fecha anterior a la actual

-Fecha: 12/12/2011 Mensaje indicando que la fecha de registro no puede ser menor a la fecha actual

Si

Formulario de parametrización para las variables por modelo


Datos correctos: código modelo no existe y variable no existe.

-Código modelo: “ASS” -variable: “mm”

Si

Código modelo en blanco

-Código: Mensaje indicando que se debe ingresar el código del modelo

Si

Código modelo existente

-Código modelo: “11”

Si

variable en blanco -Variable: Mensaje indicando que se debe ingresar la variable.

Si

Variable existente -variable: “MPS”

Si

Iteración # 3: En esta iteración se continuó con el desarrollo de los requerimientos

asociados a los formularios de parametrización compuesta del proyecto SALUD WEB.

Planeación:

Solo se muestra el pantallazo con la planeación inicial, entendiendo que se realiza el

seguimiento igual que en la iteración anterior.








N


N


N


S


S


S


N


N


N

¿El orden de asignación de los formularios de parametrización compuesta es acorde a las

N

dependencias de los formularios entre sí?


N

¿Se han presentado retrasos en el desarrollo de formularios compuestos por la falta de otros formularios necesarios para su implementación?

S

Mockups formularios de parametrización compuesta. Solo se muestra el primer formulario, a manera de ilustración. Vista para listar las ciudades:


Solo se muestra un diagrama para dar una muestra del trabajo realizado. Método para

consultar las ciudades:

Especificación de casos de prueba formularios de parametrización compuesta. A continuación, se especificarán los casos de prueba para los formularios de parametrización compuesta que serán desarrollados:

a) Árbol de condiciones. Formulario de parametrización para las ciudades: Formulario de parametrización para las zonas: Formulario de parametrización para los sitios de atención básica (SAB):

Texto Nombre

En blanco

Seleccionado

Departamento

Existente

Zona

No existente

Existente Código

No existente

En blanco

En blanco

En blanco

Texto Descripción

En blanco

Seleccionado

Ciudad

En blanco

No existente

Texto

Descripción

Dirección

Teléfonos

Seleccionado

Ciudad

Texto Jerarquía

Seleccionado

Responsable

Existente

Código

En blanco

En blanco

Texto

En blanco

Texto

En blanco

En blanco

En blanco

En blanco

b) Listado de pruebas derivado del árbol (por rama): Formulario de parametrización para las ciudades:

- Código:


- Nombre: o En blanco o Texto

Monto máximo mayor que mínimo

Negativo Numérico Monto máximo

menor que mínimo

Positivo

Monto máximo

Monto mínimo menor que máximo

Positivo

Numérico Negativo Monto

mínimo

Positivo

Negativo

Monto reembolso

No Numérico

Texto Sufijo cuenta JDE

Estado

Inactivo

No Numérico

En blanco

Monto mínimo mayor que máximo

No Numérico

En blanco

Mayor que monto máximo Menor que monto máximo y mayor que monto mínimo

Numérico

En blanco Menor que monto mínimo

En blanco

Activo

- Departamento: o Seleccionado o En blanco

Pruebas:

1- Datos correctos: Código no existe, nombre con texto, Departamento seleccionado.

2- Código en blanco 3- Código existente 4- Nombre en blanco 5- Departamento en blanco

Formulario de parametrización para las zonas: - Zona:



- Ciudad: o Seleccionada o En blanco

Pruebas:

1- Datos correctos: Zona no existe, descripción con texto, ciudad seleccionada. 2- Zona en blanco 3- Zona existente 4- Descripción en blanco 5- Ciudad en blanco

Formulario de parametrización para los sitios de atención básica (SAB):

- Código: o En blanco o Existente o No existente


- Dirección: o En blanco o Texto

- Teléfonos: o En blanco o Texto

- Ciudad: o Seleccionada o En blanco

- Jerarquía: o En blanco o Texto

- Responsable: o Seleccionado

o En blanco - Monto máximo:

o En blanco o No numérico o Numérico, negativo o Numérico, positivo, menor que monto mínimo o Numérico, positivo, mayor que monto mínimo

- Monto mínimo: o En blanco o No numérico o Numérico, negativo o Numérico, positivo, mayor que monto máximo o Numérico, positivo, menor que monto máximo

- Monto reembolso: o En blanco o No numérico o Numérico, negativo o Numérico, positivo, mayor que monto mínimo o Numérico, positivo, menor que monto mínimo

- Sufijo JDE: o En blanco o Texto

- Estado: o Activo o Inactivo

Pruebas:

- 1- Datos correctos: Código no existe, descripción con texto, dirección con texto, teléfonos con texto, ciudad seleccionada, jerarquía con texto, responsable seleccionado, monto máximo numérico, positivo, mayor que monto mínimo, monto mínimo numérico, positivo, menor que monto máximo , monto reembolso numérico, positivo, Menor que monto máximo y mayor que monto mínimo , sufijo JDE con texto, estado: activo o inactivo.

- 2- Código en blanco - 3- Código existente - 4- Descripción en blanco - 5- Dirección en blanco - 6- Ciudad en blanco - 7- Teléfonos en blanco - 8- Jerarquía en blanco - 9- Responsable en blanco. - 10-Monto máximo en blanco - 11-Monto máximo no numérico - 12-Monto máximo numérico, negativo - 13-Monto máximo numérico, positivo, menor que monto mínimo - 14-Monto mínimo en blanco - 15-Monto mínimo no numérico - 16-Monto mínimo numérico, negativo - 17-Monto mínimo numérico, positivo, mayor que monto máximo - 18-Monto reembolso en blanco - 19-Monto reembolso no numérico - 20-Monto reembolso numérico, negativo - 21-Monto reembolso numérico, positivo, mayor que monto máximo - 22-Monto reembolso numérico, positivo,menor que monto mínimo - 23-Sufijo JDE en blanco


Se realizó de la misma forma que en la iteración anterior, documentando cada una de las

clases y métodos desarrollados. Solo se muestra la documentación de una clase para

ilustrar la estructura.



Se muestran solo las pantallas relacionadas con Ciudades, para dar una idea del resultado

del desarrollo en esta iteración.

Pantalla ciudades crear o editar:



Elemento probado:

Formularios de parametrización compuesta proyecto salud web

Fecha: 16/04/2018

Formulario de parametrización para las ciudades


Datos correctos: Código no existe, nombre con texto, Departamento seleccionado.

-código: “030” -Nombre: “Manizales” -Departamento: “Caldas”

Si

Código en blanco -Código: Mensaje indicando que se debe ingresar el código.

Si


Si

Nombre en blanco -Nombre: Mensaje indicando que se debe ingresar el nombre.

Si

Departamento en blanco

-Departamento: Mensaje indicando que se debe seleccionar un departamento.

Si

Formulario de parametrización para las zonas


Datos correctos: Zona no existe, descripción con texto, ciudad seleccionada.

-Zona: “1788” -Nombre: “Villa del rio” -Ciudad: “Manizales”

Si

Zona en blanco -zona: Mensaje indicando que se debe ingresar la zona.

Si

Zona existente -Código: “1700”

Si


Si

Ciudad en blanco -Ciudad: Mensaje indicando que se debe seleccionar una ciudad.

Si

Formulario de parametrización para los sitios de atención básica (SAB)


Datos correctos: Código no existe, descripción con texto, dirección con texto, teléfonos con texto, ciudad seleccionada, jerarquía con texto, responsable seleccionado, monto máximo numérico, positivo, mayor que monto mínimo, monto mínimo numérico, positivo, menor que monto máximo, monto reembolso numérico, positivo, menor que monto máximo y mayor que monto mínimo, sufijo JDE con texto, estado: activo o inactivo.

-Código: “111” -descripción: “Versalles” -direccion: “av. Paralela calle 56” -teléfonos: “8876558” -ciudad: “Manizales” -jerarquía: cotizante -responsable: “Medico general” -monto máximo: 400000 -monto mínimo: 50000 -monto reembolso: 200000 -sufijoJde: “6555” -estado: activo

Si


Si


Si


Si

Dirección en blanco -Dirección: Mensaje indicando que se debe ingresar la dirección.

Si

Ciudad en blanco -Ciudad: Mensaje indicando que se debe seleccionar una ciudad.

Si

Teléfonos en blanco -Teléfonos: Mensaje indicando que se deben ingresar los teléfonos.

Si

Jerarquía en blanco -Jerarquía: Mensaje indicando que se debe ingresar la Jerarquía.

Si

Responsable en blanco

-responsable: Mensaje indicando que se debe seleccionar un responsable.

Si

Monto máximo en blanco

-Monto máximo: Por defecto se asigna el valor 0.00

Si

Monto máximo no numérico

-Monto máximo: “sdsds”

El campo de texto tiene restricciones que no permiten ingresar letras, solo números

Si

Monto máximo numérico, negativo

-Monto máximo: -122 El campo de texto tiene restricciones que no permiten ingresar números negativos

Si

Monto máximo numérico, positivo, menor que monto mínimo

-Monto maximo:100 -Monto mínimo:140

Mensaje indicando que el monto máximo no puede ser menor que el monto mínimo

Si

Monto máximo numérico, positivo, mayor que monto mínimo


Permite ingresar el monto reembolso

Si

Monto mínimo en blanco

-Monto mínimo: Por defecto se asigna el valor 0.00

Si

Monto mínimo no numérico

-Monto mínimo: “sdsds”


Si

Monto mínimo numérico, negativo

-Monto mínimo: -32 El campo de texto tiene restricciones que no permiten ingresar números negativos

Si

Monto mínimo numérico, positivo, mayor que monto máximo


Mensaje indicando que el monto máximo no puede ser menor que el monto mínimo

Si

Monto mínimo numérico, positivo, menor que monto máximo


Permite ingresar el monto reembolso

Si

Monto reembolso en blanco

-Monto reembolso : Por defecto se asigna el valor 0.00

Si

Monto reembolso no numérico

-Monto reembolso: “sdsds”


Si

Monto reembolso numérico, negativo

-Monto reembolso: -32 El campo de texto tiene restricciones que no permiten ingresar números negativos

Si

Monto reembolso numérico, positivo, mayor que monto máximo

-Monto reembolso: 200000 -Monto máximo: 170000

Mensaje indicando que el monto reembolso debe ser menor que el monto máximo

Si

Monto reembolso numérico, positivo, menor que monto mínimo

-Monto reembolso: 100000 -Monto mínimo: 170000

Mensaje indicando que el monto reembolso debe ser mayor o igual que el monto mínimo

Si

Sufijo JDE en blanco -sufijoJde: Mensaje indicando que se debe ingresar el sufijo de JDE.

Si

Iteración # 4: En esta iteración se continuó con el desarrollo de los requerimientos asociados a los formularios de parametrización compuesta del proyecto SALUD WEB.

Al igual que para la iteración anterior, solo muestran algunos resultados para no extender demasiado el informe.

Planeación:








N


N


N


S


S


S


N


N


N

¿El orden de asignación de los formularios de parametrización compuesta es acorde a las dependencias de los formularios entre sí?

N


N

¿Los formularios que son prerrequisito de los formularios compuestos están implementados?

N

Mockups formularios de parametrización compuesta Vista para listar los items tarifa:


Método para consultar los item Tarifa:

Especificación de casos de prueba proyecto SAS WEB iteración 4: Formularios de parametrización compuesta. A continuación, se muestra la especificación de los casos de prueba para uno de formularios de parametrización compuesta desarrollados. Formulario de parametrización para los item tarifa:


Existente Código Tarifa

No existente

En blanco

Numérico Negativo

Positivo

Valor No Numérico

En blanco

Seleccionado

Prefijo

En blanco

Seleccionado

Código

En blanco

Seleccionada

Unidad operativa

En blanco

b) Listado de pruebas derivado del árbol (por rama): Formulario de parametrización para los item tarifa:

- Código Tarifa:


- Valor: o En blanco o No numérico o Numérico, negativo o Numérico, positivo

- Prefijo: o Seleccionado o En blanco

- Código: o Seleccionado o En blanco

- Unidad operativa: o Seleccionada o En blanco

Pruebas: 1- Datos correctos: Código tarifa no existe, valor numérico positivo, prefijo

seleccionado, código seleccionado, unidad operativa seleccionada 2- Código tarifa en blanco 3- Código tarifa existente 4- Valor en blanco 5- Valor no numérico 6- Valor numérico negativo 7- Prefijo en blanco 8- Código en blanco 9- Unidad operativa en blanco


Controlador: convenioBean.java


Pantalla consultar item’s tarifa:

Pantalla item’s tarifa crear o editar:



Elemento probado:

Formularios de parametrización compuesta proyecto SAS WEB

Fecha: 03/05/2018

Formulario de parametrización para los items tarifa


Datos correctos: Código tarifa no existe, valor númerico positivo, prefijo seleccionado, código seleccionado, unidad operativa seleccionada

-codigoTarifa: “TAR11” -valor:3 -prefijo: “PRF11” -codigo: “0011” -unidadOperativa: “UND11”

Si

Código tarifa en blanco

-codigoTarifa: “” Mensaje indicando que se debe ingresar el código de la tarifa.

Si

Código tarifa existente -codigoTarifa: “TAR1”

Si

Valor en blanco -valor: Mensaje indicando que se debe ingresar el valor

Si

Datos correctos: Código no existe, nombre con texto, Departamento seleccionado.

-código: “030” -Nombre: “Manizales” -Departamento: “Caldas”

Si


Si


Si

Valor en blanco -valor: Por defecto se asigna el valor 0 Si

valor no numérico -valor: “sdsds” El campo de texto tiene restricciones que no permiten ingresar letras, solo números

Si

valor numérico, negativo

-valor: -122 El campo de texto tiene restricciones que no permiten ingresar números negativos

Si

Prefijo en blanco -prefijo: Mensaje indicando que se debe seleccionar un prefijo.

Si

Código en blanco -Codigo: Mensaje indicando que se debe seleccionar un código.

Si

Unidad operativa en blanco

-Unidad operativa: Mensaje indicando que se debe seleccionar una unidad operativa.

Si

Iteración # 5: Para esta iteración se desarrolló un formulario de completitud de datos, el

cual servirá a CONFA como herramienta de calidad de datos para tener información

actualizada de todos sus usuarios al momento de realizar transacciones, por ejemplo

solicitud de créditos.

Planeación formulario de completitud de datos.

Lista de Chequeo requerimientos formulario de completitud de datos A continuación, analizaremos el detalle de los requerimientos asignados:


¿Se especifican concretamente los campos a completar en el formulario?

S


S


S

¿Se proporciona una documentación detallada de la relación de los campos del formulario con los de la base

S

de datos?


S


S

Mockup formulario de completitud de datos Vista para listar el registro encontrado:

Formulario para completar los datos:

Diagramas de secuencia formulario de completitud de datos

Método para consultar el registro a editar:

Especificación de casos de prueba formulario de completitud de datos A continuación, se especificarán los casos de prueba para el formulario de completitud de datos:


Seleccionado

Tipo identificación:

En blanco

Numérico Negativo

Positivo

No Numérico

Número de identificación

En blanco

Texto

Primer nombre

En blanco

Texto

Segundo nombre

En blanco

Texto

Primer apellido

En blanco

Texto Segundo apellido

En blanco

Seleccionado

Género:

En blanco

Seleccionado

Estado documento:

En blanco

Formato Correcto

Texto

Fecha expedición:

Formato incorrecto

En blanco

Seleccionado

Dirección:

En blanco

b) Listado de pruebas derivado del árbol (por rama): - Tipo identificación:

o Seleccionado o En blanco

- Número identificación: o En blanco o No numérico o Numérico, negativo o Numérico, positivo

- Primer nombre: o Texto o En blanco

- Segundo nombre: o Texto

Seleccionado

Departamento:

En blanco

Seleccionado

Municipio:

En blanco

Seleccionado

Teléfono:

En blanco

Seleccionado

Celular:

En blanco

Seleccionado

Correo:

En blanco

o En blanco - Primer apellido:

o Texto o En blanco

- Segundo apellido: o Texto o En blanco

- Género: o Seleccionado o En blanco

- Estado documento: o Seleccionado o En blanco

- Fecha expedición: o Texto,Formato Correcto o Texto,Formato incorrecto o En blanco

- Dirección: o Seleccionado o En blanco

- Departamento: o Seleccionado o En blanco

- Municipio: o Seleccionado o En blanco

- Teléfono: o Seleccionado o En blanco

- Celular: o Seleccionado o En blanco

- Correo: o Seleccionado o En blanco

Pruebas: 1- Datos correctos: Tipo identificación seleccionado, número de identificación

numérico positivo, primer nombre con texto, segundo nombre con texto, primer apellido con texto, segundo apellido con texto, género seleccionado, estado documento, seleccionado, fecha de expedición con texto y formato correcto, dirección seleccionada, departamento seleccionado, municipio seleccionado, teléfono seleccionado, celular seleccionado, correo seleccionado.

2- Tipo identificación en blanco 3- número de identificación en blanco 4- número de identificación no numérico 5- número de identificación numérico negativo 6- Primer nombre en blanco 7- Segundo nombre en blanco 8- Primer apellido en blanco 9- Segundo apellido en blanco 10- género en blanco 11- estado documento en blanco 12- Fecha de expedición con texto formato incorrecto 13- dirección en blanco

14- departamento en blanco 15- municipio en blanco 16- teléfono en blanco 17- celular en blanco 18- correo en blanco

Documentación del código formulario de completitud de datos

Controlador: CompletitudBean.java

Pantallas finales formularios de completitud de datos:

Pantalla consultar registros:

Pantalla para completar los datos:

Resultados de las pruebas para el formulario de completitud de datos


Elemento probado:

Formulario de completitud de datos

Fecha: 24/05/2018

Formulario de completitud de datos

Caso de Prueba Valores ingresados Resultados obtenidos

¿Pasó?

Datos correctos: Tipo identificacion seleccionado, número de identificacion numérico positivo, primer nombre con texto, segundo nombre con texto, primer apellido con texto, segundo apellido con texto, género seleccionado, estado documento, seleccionado, fecha de expedición con texto y formato correcto,dirección seleccionada, departamento seleccionado, municipio seleccionado, teléfono

-tipoIdentificacion: seleccionado: “CC” - numeroIdentificacion:884 -primerNombre:”MARIO” -segundoNombre:”PAOLO” -primerApellido:”PEREA” -segundoApellido:”PEREZ” -genero: Seleccionado:”HOMBRE” -estadoDocumento: Seleccionado: vigente -fechaExpedicion:”22/12/2001” (dd/MM/yyy) -direccion: seleccionada -departamento:seleccionado -municipio: seleccionado -telefono:seleccionado -celular:seleccionado -correo: seleccionado

Mensaje indicando que el registro se actualizó con exito

Si

seleccionado, celular seleccionado, correo seleccionado.

Tipo identificación en blanco

-tipoIdentificacion: “” Mensaje indicando que se debe seleccionar el tipo de identificacion

Si

Número de identificación en blanco

-numeroIdentificacion: “” Mensaje indicando que se debe ingresar el número de identificación

Si

numero de identificación no numérico

-numeroIdentificacion: 4ddd3 Mensaje indicando que el numero de identificación debe ser númerico

Si

numero de identificación numérico, negativo

-numeroIdentificacion: -1233 Mensaje indicando que el numero de identificación no puede ser negativo

Si

Primer nombre en blanco

-Primer nombre: “” Mensaje indicando que se debe ingresar elprimer nombre

Si

Segundo nombre en blanco

-Segundo nombre: “” Permite continuar Si

Primer apellido en blanco

-Primer apellido: “” Mensaje indicando que se debe ingresar el primer apellido

Si

Segundo apellido en blanco

-Segundo apellido: “” Mensaje indicando que se debe ingresar el segundo apellido

Si

Género en blanco -Genero: “” Mensaje indicando que se debe seleccionar el género

Si

Estado documento en blanco

-EstadoDocumento: “” Mensaje indicando que se debe seleccionar el estado del documento

Si

Fecha de expedición con texto formato incorrecto

-FechaExpedicion:”11-22-2001”

Mensaje indicando que el formato de la fecha debe ser (dd/MM/yyyy)

Si

direccion en blanco -Dirección: “” Mensaje indicando que se debe seleccionar la dirección

Si

departamento en blanco -Departamento: “” Mensaje indicando que se debe seleccionar el departamento

Si

municipio en blanco -municipio: “” Mensaje indicando que se debe seleccionar el municipio

Si

Teléfono en blanco -telefono: “” Permite continuar Si

celular en blanco -celular: “” Mensaje indicando que se debe seleccionar un celular

Si

correo en blanco -correo: “” Permite continuar Si

Iteración # 6: Para la última iteración del proceso de práctica se desarrollo una integración entre un sistema antiguo en motor de base de datos DB2 y un sistema nuevo en motor de base datos PostgreSQL para migrar la información de la empresa, empleando para esto un proceso ETL (extraer, transformar y cargar). A continuación, se documenta todo el proceso de ETL y la integración entre los sistemas.

ETL es el proceso que permite a las organizaciones mover datos desde múltiples fuentes, reformatearlos y limpiarlos, y cargarlos en otra base de datos,

A partir del análisis del modelo antiguo y nuevo se plantean una serie de observaciones para garantizar que el proceso de transformación sea correcto y no se presenten retrasos en la ejecución del proceso:

Temas Observaciones

Afiliación Afiliación: Fecha de Expedición es obligatoria?

Afiliación Padre Biológico: Está en control de cambios.

Afiliación Revisar si hay alguna manera de actualizar el Código postal basados en

el barrio.

Afiliación Empresas Desafiliadas: Se migran como No formalizadas Retirada con

Aportes si hay aportes luego de la desafiliación.

Afiliación Novedades de Afiliados

Afiliación Novedades de Empresas

Afiliación Beneficiarios - Pendiente de ajuste en Heinsohn

Cartera En cartera, el negocio debe definir el método a aplicar. Tener en cuenta

que la cartera también hay que asociarla a los cotizantes en la sábana de

cartera pendiente.

Cartera Sábana Bitácora Cartera, son los eventos asociados antes a una cartera.

Correcciones Corrección de aportes: Validar con el negocio si de esto se va a hacer

migración.

Cuota

Monetaria

Sábana de Cuenta de Administrador de Subsidios.

Cuota

monetaria

Cuota monetaria está pendiente de que Heinsohn termine de liberar.

Cuota

monetaria

Pendiente que Asopagos nos confirme si es posible migrar las

liquidaciones con derecho.

Cuota

monetaria

Migramos los subsidios retenidos de las agrupadoras? y cómo se

relacionan en Afiliación esas agrupadoras?

Cuota

monetaria Sábana de Subsidio: Ver los ejemplos que nos van a entregar

Cuota

Monetaria

Sábanas de Subsidio: Pendiente de definir estados de Anulados y otros

campos relacionados con la transacción de cobro.

Cuota

monetaria

Regalar un escenario del pago de subsidio nuestro con todo el

movimiento (que tenga pagos fraccionados)

Devolución Sábanas Devoluciones

Devolución Las devoluciones hay que asociarlas a los cotizantes. Cómo afecta esto

en otros procesos, por ejemplo pago?

Devolución En el caso de devoluciones se afecta el valor del aporte. La historia del

movimiento queda en la tabla "MovimientoAportes"

Devolución Intereses de mora y devoluciones se puede aplicar sobre un solo

cotizante,pero revisar con el negocio que tan válido es este manejo.

Fovis Fovis: Fecha de Expedición es obligatoria?

Fovis Fovis: Cola de Espera

Fovis Fovis: Errores de digitación. Se pueden corregir antes de asignar?

Fovis Fovis: Madre comunitaria tiene derecho a vivienda usada. Cómo se

parametriza?

Fovis Fovis: Reajustes

Fovis Sábana Fovis de novedades (histórico)

Fovis Fovis: Se pueden postular hogares unipersonales?

Fovis Fovis: Qué son los parentescos ????_hogar

Fovis Fovis: Rangos salariales(RangoTopeValorSFV). Cómo se relaciona en el

modelo y guarda histórico.

Fovis Fovis: Arreglar sábana de Ahorros

Fovis Fovis: Doble relación de empresa oferente

Fovis Fovis: Salario de Jefe de hogar e integrante salen de Genesys

Fovis Fovis: Sumatoria de salarios por multiafiliación. Lo hacen?

Fovis Fovis: migración de vencimientos

Fovis Ahorro previo en estructura de datos está asociado a la postulación pero

no permite identificar a quién pertenece.

Fovis Fovis: Sábana estados diferentes a Postulado y Desembolsado

Fovis Sábana Fovis: Pendiente de revisión de varios campos, en especial los

de estados.

Fovis Sábana Fovis: Pendiente de corrección para que puedan relacionar las

condiciones especiales ya que pueden ser varias. Actualmente solo se

puede relacionar una.

Sábana Todas las sábanas para finales de Agosto.

Listado de tablas necesarias con su respectiva documentación y la historia de usuario a la que pertenece:

Total 299 tablas.

Políticas(SQL) para las transformaciones:

Empresas:

La fecha del último pago debe ser posterior a 2011-06-01

Trabajadores:

Fecha de afiliación posterior a 2012-06-01

Personas a cargo: verifica que la fecha de afiliación posterior a 2012-06-01

Liquidación: Se verifica que la fecha de liquidación sea mayor a 2013-06-01

Aportes: Se verifica que el estado de registro sea activo y que la fecha de último pago sea mayor a 2011-06-01:

Ahora se hace una descripción más formal de las políticas definidas para migración, solo para la parte de “Empresas”:

EMPRESAS:

1. Aportantes que en Nasfa tienen actividad económica diferente a 9700 y su tipo de

documento es Cédula de ciudadanía, se deberán cambiar a tipo de documento Nit.

2. Aportantes con 9700 hay que colocarle la actividad económica que trae Pila

3. Revisar que las empresas que están como personas natural el Representante Legal

sea el mismo; de lo contrario deben verificar con el medio que permita la

actualización y determinar con cual se actualizará: (Rues, Cámara de Comercio,

Llamadas, Etc.)

4. Determinar qué acción se debe tomar con las empresas que se encuentran con la

matrícula mercantil vencida o cancelada.

5. Para las empresas desafiliadas y expulsadas el tiempo que se tendrá en cuenta para

realizar verificacion y actualizacion de datos será de 5 Años: (diciembre 2013 en

adelante) al igual que sus aportes; por lo tanto con el archivo que Cesar Molina

genera identificando estas inconsistencias debe ser verificadas.

6. Determinar las empresas que no tienen registro en el Rues como: (Consorcios,

Cooperativas, personas naturales, propiedades horizontes, entes públicos); cuál

será el medio para actualizar sus datos de ubicación y contacto.

7. Las actividades económicas no se pudieron revisar frente a la actividad que se

reporta en PILA, ya que no genera confiabilidad por ser un dato que el aportante

solo lo registra una vez y no se vuelve a actualizar. Subsidios debe definir fuente de

actualización.

8. Revisar para la migración que la actividad económica de la principal sea la misma de

la sucursal excepto para algunos casos en los en los cuales se identificó que son del

sector agrario o empleada del servicio doméstico. (porque en la actualidad nasfa no

maneja actividad económica para las sucursal)

9. Se debe revisar todas las sucursales de las empresas con tipo de documento cédula

de ciudadanía, para determinar que no sean actividades económicas comerciales

verificando directamente con el empleador.

10. Validar con Carlos Andrés y Hermilson si es posible realizar ajustes en subsi plus en

el módulo de UGPP con el fin que no tenga restricciones al momento de ingresar

direcciones u otra información. (verificar con Sebastián en aportes cuales son las

restricciones).

11. Se deben verificar las empresas que eran ‘N’ y fueron activadas entre septiembre y

diciembre de 2016 erradamente por PILA WEB, las cuales quedó Diego de arreglar

pero se detectó que no todas fueron corregidas como por Ejemplo: (Códigos

0346551, 0302778, 0333500, 0324855, 0303537, 0341073, 0209403, 0345017,

0349001) , estas empresas deben ser detectadas y antes de ser corregidas se debe

revisar que aportes fueron reportados como no identificados y cuales como

dependientes ya que se debe realizar el respectivo ajuste.

Para iniciar el proceso de transformación es necesario ejecutar consultas SQL sobre la base de datos para afinar los registros y así garantizar calidad de datos.

A continuación, se presentan algunas de las consultas elaboradas.

Consulta de borrado de empresas que ya existen bajo otro código.

Actualización temporal de los tipos de empresas.

Consulta para verificar que no se repite la empresa.

Actualización de representantes legales

Cambio de ubicación en sucursal:

Por cada sucursal:

Consultas para verificar que los datos almacenados estén correctos:

Eliminación de registros repetidos.

(SQL Scripts Tablas)

TABLAS PARAMÉTRICAS

opciones del campo tifMedidaCapacidad:

Listado de transformaciones a realizar sobre las tablas de la base de datos:

Programa Java de Separación

de Nombres:

principalSeparNombreEmp.java

Programa que separa los nombres de Pensionados e

Independientes que aportan por sí mismos. Alimentan la

tabla T219_NOMEMP.

SQL para generar la tabla

Persona

Genera tabla "persona" en el servidor

Trans: Empresas-c Genera la tabla temporal Empresas_c

-- SE BORRAN DE EMPRESAS_NASFA ESTAS

EMPRESAS PORQUE YA EXISTEN BAJO OTRO

CODIGO Y ESTAN AFECTANDO LA MIGRACION

Trans: Empresa - Persona Carga empresas principales del sevirvidor a la tabla

"persona" en Postgres.

Trans:

persona400ActualizaCoincident

es

Carga primero los registros coincidentes como empresa y

como persona.

Trans: persona400 Carga la tabla "persona" del I520 a "persona400" en

Postrgres

Trans: persona400-persona Carga de la tabla "persona400" en Postgres a la tabla

"persona" en Postgres. Esto se hace para unificar los

nombres y apellidos que originalmente están desagregados

en trabajador y/o PC y/o Beneficiario de pago y/o

Representante-Contacto.

Trans: Empresa Carga empresas principales del I520 a la tabla "empresa"

en Postgres cruzando con la tabla "persona" y "codigociiu".

Trans: Empleador Carga empresas principales del I520 a la tabla "empleador"

en Postgres cruzando con la tabla "persona" y "empresa".

Trans: SolicitudAfiliacion Carga de Empresas principales del I520 a las tablas

"SolicitudAfiliaciEmpleador", "Solicitud" y

"EtiquetaCorrespondenciaRadicado" cruzando con las

tablas "empleador", "empresa" y "persona" en Postgres.

Trans: sucursales Carga la Sucursales del I520 a la tabla "sucursalempresa"

cruzando con las tablas de "empresa" y "persona" en

Postgres.

Trans:

SolicitudAfiliacionSucursal

Carga de datos de Sucursal que se necesitan en la Sábana

de Mirgración. Los datos se llevan a la tabla temporal

"solicitudAfilSucursal" y a la tabla "Solicitud" cruzando con

las tablas "SucursalEmpresa", "Empresa" y "Persona" en

Postgres.

Trans: UbicaciónEmpresas Carga la tabla de "ubicacion" y "ubicacionempresa" con las

direcciones de Empresas principales.

Trans: UbicaciónSucursales Carga la tabla de "ubicacion" y la tabla temporal

"ubiEmpSucuNasfa" con las direcciones de Empresas

Sucursales. La tabla temporal se utiliza luego para poder

actualizar el campo de ubicación en la tabla de

"sucursalempresa".

Trans:

ActualizaUbicacionSucursal

Actualiza en la tabla "sucursalempresa", el campo de

ubicación "sueUbicacion", a través de la tabla temporal

"ubiEmpSucuNasfa" .

Trans: Ubicacion-Persona Se actualiza en la tabla Persona la ubicación de los

afiliados.

Trans: Ubi-

PersonaBenefTraUnion

Se actualiza en la tabla Persona la ubicación de los

beneficiarios que cruzan con archivo TransUnion.

Trans: Ubi-PersonaBenef-T002 Se actualiza en la tabla Persona la ubicación de los

beneficiarios que están sin ubicación y que cruzan con el

trabajador.

Trans: Ubi-PersonaFaltantes Se actualiza en la tabla Persona la ubicación de las

personas que no cruzaron con ninguno de los ETLs

anteriores..

Trans: RolContactoEmpleador Actualiza en la tabla "RolContactoEmpleador", cruzando

con la tabla de Empleador. Por ahora se deja constante

como persona contacto a "Maria Emilia Tabares" .

Trans:

AsesorResponsableEmpleador

Actualiza en la tabla "AsesorResponsableEmpleador",

cruzando con la tabla de Empleador. Por ahora se deja

constante como asesor a "JUAN ANTONIO CARDONA" .

Trans: EntidadPagadora Actualiza en la tabla "EntidadPagadora" las empresas de

pago de Pensionados, Facultativos y Voluntarios.

Trans: BeneficioEmpleador Actualiza en la tabla "BeneficioEmpleador" las empresas

con beneficio de Ley1429 o Ley 590.

Para la ejecución de estas transformaciones se utilizó la herramienta data-integration en su versión 7.0.0.

Documentación de los procesos:

Trans: Empresa -

Persona

Carga empresas principales

del I520 a la tabla "persona"

en Postgres.

El campo "secuencia" en la

transformación se inicializa en 1.

El ítem Empresas_Nasfa carga los tipos y números de documento de la tabla Empresas_Nasfa :

Con el ítem secuencia añade una secuencia para los identificadores de los registros anteriores.

En el siguiente ítem se especifican las propiedades de la transformación como lo es la ubicación de destino:

El ítem persona-Genesys es el resultado de la transformación, este ítem se conecta con la base de datos de destino para insertar los registros.

Trans:

persona400ActualizaC

oincidentes

Carga primero los registros

coincidentes como empresa y

como persona.

* Cada vez que se vaya a ejecutar

este paso, verificar que el campo

"id_persona" de la tabla

"PERSONA" en el I520 esté en en

999999

En el ítem persona400 se transforman los resultados obtenidos de acuerdo a las reglas definidas para el nuevo sistema:

En el ítem sort rows se ordena descendentemente los registros obtenido por número y tipo de documento.

En el ítem persona se cargan todos los registros de la tabla persona:

En el ítem merge join se unen los resultados de las consultas anteriores para su transformación:

El ítem persona400-Genesys es el resultado de la transformación, este ítem se conecta con la base de datos de destino para insertar los registros.

Trans: persona400 Carga la tabla "persona" del

I520 a "persona400" en

Postgres

* Se debe revisar cuantas

empresas cargó en la tabla

"persona" e inicializar el campo

"secuencia" en un número más del

MAX(perId) de "persona".

El ítem persona400 = 999999 realiza la transformación de los tipos y números de documento de las personas con id = 999999 para su transformación.

A continuación se agrega una secuencia al resultado anterior para su carga en el sistemas nuevo.

El ítem persona400 es el resultado de la transformación, este ítem se conecta con la base de datos de destino para insertar los registros.

Trans: persona400-

persona

Carga de la tabla

"persona400" en Postgres a la

tabla "persona" en Postgres.

Esto se hace para unificar los

nombres y apellidos que

originalmente están

desagregados en trabajador

y/o PC y/o Beneficiario de

pago y/o Representante-

Contacto.

El id (perId) ya viene calculado del

paso anterior.

El ítem persona400 carga todos los registros de las personas con registro = ‘N’:

El ítem persona genesys recibe los registros anteriores:

Trans: Empresa Carga empresas principales

del I520 a la tabla "empresa"

en Postgres cruzando con la

tabla "persona" y "codigociiu".

El campo "secuencia" en la

transformación se inicializa en 1.

El cruce con la T006 se hace a

partir de K080_F_REC >=

'20131201'.

El ítem T001 transforma los tipos de documentos de los registros:

El ítem empresas_Nasfa transforma el código de actividad económica de los registros:

El ítem T001_EmpresasNasfa une los resultados de anteriores:

Con el ítem orden empresas ordena descendentemente los registros por tipo y número de identificación.

En el ítem persona se cargan todos los registros de la tabla persona:

El ítem empresaspersonas une los resultados de los 3 ítems anteriores.

Con el ítem orden-k027 se ordenan de forma descendente los registros del resultado anterior.

El ítem código ciiud consulta todos los códigos de las actividades económicas:

El ítem T001-codigociiu une los resultados del anterior ordenamiento y la consulta de códigos de actividad económica:

los resultados de la unión anterior se ordenan por documento del representante legal.

El ítem persona-RepLegal carga todos los datos de los representantes legales:

Ahora confrontamos resultados para verificar que estén todos los datos::

A continuación se agrega una secuencia a los resultados anteriores.

Finalmente el ítem empresa Genesys recibe los datos anteriores para su carga en el nuevo sistema.

Este mismo proceso es similar para las transformaciones restantes.

Pruebas.

Para probar la correcta generación y carga de datos se realizarán una serie de consultas sobre la base de datos nueva, en cada una de las siguientes consultas se deben obtener resultados de lo contrario se concluye que el proceso de carga no fue exitoso.

Consulta sobre la tabla: sentencia (select * from “tabla”)

Resultado (Con registros/Sin registros)

¿Pasó? (Si/No)

ActaAsignacionFovis Con registros Si

ActividadCartera Con registros Si

ActividadDocumento Con registros Si

ActoAceptacionProrrogaFovis Con registros Si

AgendaCartera Con registros Si

AhorroPrevio Con registros Si

AplicacionValidacionSubsidio Con registros Si

AplicacionValidacionSubsidioPersona Con registros Si

ArchivoConsumosAnibol Con registros Si

ArchivoLiquidacionSubsidio Con registros Si

ArchivoRetiroTerceroPagador Con registros Si

BitacoraCartera Con registros Si

Cartera Con registros Si

CarteraDependiente Con registros Si

CarteraNovedad Con registros Si

CicloAportante Con registros Si

CicloAsignacion Con registros Si

CicloCartera Con registros Si

CicloModalidad Con registros Si

CondicionEspecialPersona Con registros Si

ConjuntoValidacionSubsidio Con registros Si

ConvenioPago Con registros Si

ConvenioPagoDependiente Con registros Si

ConvenioTerceroPagador Con registros Si

Correccion Con registros Si

CuentaAdministradorSubsidio Con registros Si

Cruce Con registros Si

DesafiliacionAportante Con registros Si

DescuentosSubsidioAsignado Con registros Si

DetalleSolicitudAnulacionSubsidioCobr

ado

Con registros Si

DetalleSolicitudGestionCobro Con registros Si

DetalleSubsidioAsignado Con registros Si

DetalleSubsidioAsignadoProgramado Con registros Si

DevolucionAporte Con registros Si

DevolucionAporteDetalle Con registros Si

DocumentoCartera Con registros Si

DocumentoDesafiliacion Con registros Si

DocumentoSoporte Con registros Si

DocumentoSoporteConvenio Con registros Si

DocumentoSoporteOferente Con registros Si

DocumentoSoporteProyectoVivienda Con registros Si

En este punto se da por concluida la documentación de todo el proceso de desarrollo llevado a cabo durante la práctica.

4. Reflexiones

Al llevar a cabo este proceso de práctica pude perfeccionar mis conocimientos adquiridos

durante toda la carrera universitaria además pude aplicar todo lo relacionado con las asignaturas ingeniería de software, programación, sistemas operativos, bases de datos y redes de computadoras.

También tuve la oportunidad de ver la aplicación de las asignaturas del componente administrativo como son: auditoría informática y administración de sistemas por parte del área de tecnología.

En este proceso he adquirido experiencias muy buenas en lo personal y laboral gracias al buen ambiente de trabajo.

Esta es una empresa que cada vez avanza más en en el factor de TI, al inicio del proceso lei el PETI 2013-2018, y al dia de hoy se han cumplido los objetivos a cabalidad y ya se está trabajando en el PETI 2018-2023.

En cuanto a las herramientas utilizadas en esta empresa cada día se buscan nuevas herramientas que se ajusten a las necesidades, en estos tiempos la curva de evolución aumenta rapidamente asi que se debe estar a la vanguardia. Constantemente se están explorando nuevas herramientas que aporten a la empresa desde su perspectiva tecnológica, por ejemplo: Reconocimiento por torrente sanguíneo, chatbots, servicios en la nube, firma y facturación electrónica.

5. Bibliografía

https://docs.balsamiq.com/desktop/

https://docs.oracle.com/javase/9/documentacion

https://help.pentaho.com/Documentation/8.1

https://netbeans.org/kb/archive/index.html

https://www.eclipse.org/documentation/

https://www.ibm.com/analytics/us/en/db2/

http://www.javaserverfaces.org/documentation

http://www.oracle.com/technetwork/es/middleware/glassfish/documentation/index.html

https://www.postgresql.org/docs/

https://www.primefaces.org/documentation/

https://docs.balsamiq.com/desktop/

https://docs.oracle.com/javase/9/documentacion

https://help.pentaho.com/Documentation/8.1

https://netbeans.org/kb/archive/index.html

https://www.eclipse.org/documentation/

https://www.ibm.com/analytics/us/en/db2/

http://www.javaserverfaces.org/documentation



https://www.postgresql.org/docs/

https://www.primefaces.org/documentation/

Documents

INFORME FINAL PRÁCTICA CRHISTIAN CAMILO TABORDA PAREJA · informe final prÁctica crhistian camilo taborda pareja programa de ingenierÍa en sistemas y computaciÓn departamento