• No se han encontrado resultados

Diseno del Modulo Control de Personas del Sistema Unico de Aduanas.

N/A
N/A
Protected

Academic year: 2023

Share "Diseno del Modulo Control de Personas del Sistema Unico de Aduanas."

Copied!
116
0
0

Texto completo

(1)

UNIVERSIDAD DE LAS CIENCIAS INFORMÁTICAS FACULTAD 4

Trabajo de Diploma para Optar por el Título de Ingeniero en Ciencias Informáticas

Título: Diseño del Módulo Control de Personas del Sistema Único de Aduanas.

Autores:

Yisel Rodríguez Pérez Rafael Andrés Céspedes Basteiro

Tutores:

Ing. Pedro Manuel Alás Verdecia Ing. Jaznahizkel Jaen Brea

Ciudad de La Habana, abril de 2009

“Año 50 de la Revolución”

(2)

Declaración de Autoría

Declaramos que somos los únicos autores de este trabajo y autorizo a la Universidad de las Ciencias Informáticas a hacer uso del mismo en su beneficio.

Para que así conste firmamos la presente a los __ días del mes de ___ del año 200_

____________________________ ___________________________

Yisel Rodríguez Pérez Rafael Andrés Céspedes Basteiro Firma del Autor Firma del Autor

_____________________________ ___________________________

Ing. Pedro Manuel Alás Verdecia Ing. Jaznahizkel Jaen Brea Firma del Tutor Firma del Tutor

(3)

Agradecimientos

A todos los que han tenido que ver en nuestra formación como profesionales.

Yisel y Rafael

(4)

Dedicatoria

A nuestra familia, nuestros amigos y a la Revolución que nos ha dado la posibilidad de realizar este sueño.

Yisel y Rafael

(5)

Resumen

Llevar a cabo de forma efectiva el control de personas naturales es una de las responsabilidades de mayor peso en el área de Lucha Contra el Fraude de la Aduana General de la República de Cuba. El presente trabajo tiene como objetivo diseñar el módulo Control de Personas para el Sistema Único de Aduanas, para facilitar la gestión de los procesos relacionados con el control de personas naturales en la frontera. Para este propósito se utiliza la metodología de desarrollo RUP, la cual utiliza UML para elaborar todos los artefactos y como herramienta de modelado el Visual Paradigm.

Para comprender el negocio se realizó un modelado por procesos, donde se analizaron los sistemas existentes en la Aduana cubana para efectuar este tipo de control, pudiéndose identificar las principales deficiencias que afectan hoy día el proceso de control de personas. Partiendo de los conceptos más relevantes se identifican los actores, se realizan diagramas de casos de usos del sistema, descripción de los casos de uso del sistema, especificaciones de los requisitos funcionales, además de otros elementos que se abordarán en el transcurso y desarrollo del trabajo.

La puesta en marcha de este sistema permitirá erradicar los problemas existentes, disponiéndose de un sólo software que permita realizar el estudio de información adelantada de pasajeros, monitorizar el flujo de los viajeros por frontera e insertar las infracciones de estos, también se cuenta con un historial de las personas y varios reportes que brindan información a los analistas de Lucha Contra el Fraude para tomar decisiones en su trabajo.

(6)

Tabla de Contenidos

Introducción. ... 8

Capítulo 1. Fundamentación Teórica. ... 12

1.1 Introducción. ... 12

1.2 Aplicación de Sistemas Informáticos en el mundo.. ... 13

1.2.1 Sistemas extranjeros. ... 13

1.2.2 Soluciones cubanas. ... 15

1.3 Metodología, lenguaje y herramientas de modelado para el desarrollo ... 17

1.3.1 Metodología de desarrollo. ... 18

1.3.2 Notación para el Modelado de Procesos de Negocio. ... 20

1.3.3 Tipo de sistema y plataforma. ... 21

1.3.4 Lenguaje de programación. ... 21

1.3.5 Framework de trabajo. ... 21

1.3.6 Interfaz de Usuario. ... 22

1.3.7 Sistema gestor de base de datos... 22

1.3.8 Herramienta CASE. ... 22

1.4 Patrones y técnicas de captura de requisitos.. ... 23

1.4.1 Patrones de Casos de uso. ... 24

1.4.2 Patrones de Diseño. ... 26

1.4.3 Las técnicas de captura de requerimientos. ... 26

1.5 El rol de analista. ... 28

1.6 El rol de diseñador. ... 29

(7)

1.7 Conclusiones parciales. ... 29

Capítulo 2. Descripción de la solución propuesta ... 30

2.1 Introducción. ... 30

2.2 ¿En qué consisten los procesos a informatizar? ... 30

2.3 ¿Qué dificultades existen en la práctica que hacen necesario la informatización de los procesos? ... 33

2.4 Técnicas de captura de requisitos. ... 35

2.5 Requisitos funcionales. ... 36

2.6 Validación de los requisitos de software. ... 41

2.7 Diagramas de casos de uso del sistema . . ... 41

2.7.1 Descripción de los actores del sistema. ... 43

2.7.2 Descripción textual reducida de los Casos de Uso. ... 45

2.8 Aportes de la solución y beneficios esperados. ... 58

2.9 Conclusiones parciales. ... 59

Capítulo 3. ... 60

Diseño del Sistema. ... 60

3.1 Introducción. ... 60

3.2 Patrones de diseños utilizados. ... 61

3.2.1 Patrones GRASP implementados. ... 61

3.2.2 Patrones GOF utilizados. ... 62

3.2.3 Patrón MVC. ... 62

3.3 Clases de diseño. ... 64

3.3.1 Extensiones para el diseño Web... 64

(8)

3.3.2 Clases del diseño con estereotipos Web. ... 66

3.3.3 Paquetes Acceso a Datos e Interfaces JS. ... 87

3.4 Diagramas de secuencia. ... 91

3.5 Diseño de la base de datos. ... 94

3.6 Diagrama de despliegue. ... 95

3.7 El módulo “Control de Personas” orientado a la arquitectura del SUA. ... 96

3.8 Conclusiones parciales. ... 97

Conclusiones ... 98

Recomendaciones ... 99

Bibliografía ... 100

Glosario de términos ... 102

Anexos ... 104

(9)

Introducción

Cada día se utilizan en mayor grado las Tecnologías de la Información y las Comunicaciones (TIC) para apoyar y automatizar los procesos de una empresa. Con ayuda de las TIC las organizaciones han logrado grandes beneficios, como son la optimización de sus recursos y mejora de sus operaciones, logrando aumentar su eficiencia y competitividad.

La Aduana General de la República de Cuba es una organización creada el 5 de febrero de 1963 con el objetivo fundamental de garantizar la seguridad nacional. Con este propósito se crea el área de Lucha Contra el Fraude (LCF) encargada de enfrentar las acciones terroristas, de narcotráfico, y las que ponen en riesgo el patrimonio cultural y natural del país.

Como toda empresa de vanguardia la Aduana cubana ha estado trabajando en la informatización de sus procesos. El área LCF ha obtenido resultados en esta esfera, por ejemplo se implantó en 1995 el Sistema Automatizado de Personas de Interés Aduanal (SAPIA), utilizado para gestionar las personas naturales que cometen infracciones y las que viajan con frecuencia al país. En el año 1998 fue puesto en práctica el sistema Loren, encargado de monitorizar las personas que pasan por frontera, emitiendo un mensaje al inspector.

En abril de 2007 la Aduana cubana comienza a recibir la Información Adelantada de Pasajeros (API), la cual consiste en un mensaje que envían las aerolíneas, después del despegue del avión y que trae consigo los datos de los viajeros que están en el vuelo. Esta información es muy valiosa para los analistas de LCF; utilizándola son capaces de identificar antes del arribo del avión las personas de interés aduanal (PIA) y las repetidoras, esta última categoría es definida por los especialistas de LCF teniendo en cuenta la cantidad de veces que una persona ha entrado al país en un tiempo determinado. La identificación de las personas se realiza comparando los datos del mensaje API con los datos del SAPIA, esta actividad la realizan los analistas guardando los datos del API en un fichero que luego es copiado para una dirección en la que el SAPIA lee y seguidamente compara las personas del mensaje con las ya registradas en su base de datos. Cuando el sistema encuentra una coincidencia el analista debe decidir si controlar o no la persona al pasar por frontera, escribiendo en un papel los datos personales de la persona a controlar.

Este trabajo es estresante y necesita rapidez porque se ejecuta contra reloj.

(10)

Los sistemas SAPIA y Loren no están conectados por red, lo que atrasa aún más el trabajo porque el analista después de seleccionar a las personas que desea controlar en frontera, deberá introducir los datos manualmente en el Loren y se corre el riesgo de cometer el error humano, que no se puede desestimar, ya que al marcar una persona para controlar, se puede dar el caso de no insertar el mismo nombre en el sistema Loren y por esta razón, no poder tratar la persona sospechosa. Otra situación desfavorable que se presenta es la relacionada con la actualización de las personas repetidoras; donde el Ministerio del Interior (MININT), envía información a la Aduana sobre las personas que repiten viajes al país en un año fiscal, actualizándose los datos aproximadamente cada tres meses. Por lo que una persona pudiera venir al país el día 30 de diciembre, salir el día 31, volver el 2 de enero del otro año y no considerarse repetidor.

Los especialistas de Lucha Contra el Fraude encargados del control de personas, necesitan un software que brinde mayores prestaciones que las que les ofrecen los sistemas antes mencionados, entre estas podemos mencionar:

Poseer un software que reúna las tres funcionalidades principales estas son: monitorizar las personas al pasar por frontera, gestionar las personas de interés aduanal y realizar estudio de la información adelantada de pasajeros.

Permitir desde la jefatura monitorizar un aeropuerto determinado y realizar estudio de la Información Adelantada de Pasajeros para un vuelo establecido por el usuario.

Acceder a los hechos históricos de las personas que son de interés para la Aduana.

Configurar cuando se considera una persona repetidora, teniendo en cuenta la cantidad de viajes en un tiempo determinado.

Gestionar de forma jerárquica los PIA de la Aduana.

Tributar información que permita definir posibles redes de vínculos. Ejemplo, los pasajeros que vienen juntos en más de un viaje desde el mismo destino.

Ante la situación expuesta anteriormente surge el siguiente problema científico: ¿Cuál es el diseño de software que satisface las necesidades de la Aduana, relativas al control de personas en los aeropuertos?

(11)

Debido a lo planteado anteriormente se tiene como objeto de estudio las actividades involucradas con el control de personas y los sistemas utilizados en la Aduana General de la República de Cuba; como campo de acción a desarrollar están los procesos de gestión y control de personas de interés en el área Lucha Contra el Fraude.

Para dar solución a la problemática planteada se establece como objetivo general realizar el diseño de una aplicación Web que facilite la gestión de los procesos relacionados con el control de persona en la Aduana General de la República de Cuba.

Para cumplir con el objetivo y lograr una solución adecuada a la problemática especificada, se plantean las siguientes tareas investigativas:

Analizar el estado del arte de los sistemas informáticos desarrollados en Cuba y en el Mundo, que realicen el control de persona en frontera.

Estudiar la metodología de desarrollo de software definida para el Sistema Único de Aduanas (SUA).

Realizar entrevistas a los especialistas del área de Lucha Contra el Fraude.

Modelar las actividades actuales relacionadas con el proceso de control de persona en los aeropuertos.

Identificar los requisitos funcionales del módulo Control de Personas.

Analizar la arquitectura definida para el proyecto SUA.

Definir los patrones de diseño a utilizar.

Obtener el Modelo de Diseño del Módulo Control de Personas.

Con el presente trabajo se espera obtener el diseño del módulo encargado de gestionar los procesos de control de persona de forma automatizada.

El presente trabajo de diploma está conformado por tres capítulos:

(12)

El primer capítulo incluye un estado del arte del tema tratado a nivel internacional y nacional de los sistemas usados en la actualidad para dar solución al problema que se enfrenta. Se mencionan las técnicas, metodología y herramientas utilizadas en el proyecto. Se identifican los patrones que se utilizarán para modelar el software, así como las responsabilidades y artefactos generados por el rol de analista y diseñador.

El segundo capítulo incluye una descripción más detallada del problema, explicando el flujo actual de los procesos dentro del área de Lucha Contra el Fraude. Se identifican las dificultades que existen en la práctica y que hacen necesario la informatización de los procesos. Se plantea la propuesta del sistema teniendo en cuenta la especificación de los requisitos del software. Se plasma el diagrama de casos de uso del sistema, con una descripción reducida de estos y de sus actores. Se expone la solución, los beneficios y los resultados esperados.

En el tercer capítulo se muestran los diagramas de clases del diseño con estereotipos Web, así como los diagramas de secuencia de los casos de uso críticos. También se construye el modelo físico de datos y el diagrama de despliegue, se especifica además la solución propuesta en el marco de la arquitectura definida para el Sistema Único de Aduanas.

(13)

Capítulo 1.

Fundamentación Teórica.

1.1 Introducción

En el presente capítulo se describen los elementos principales que fundamentan el contenido de este trabajo. Se realizará una descripción de varios sistemas que se utilizan en Cuba y el resto del mundo para realizar el control de personas en frontera, describiendo sus potencialidades. Se detallarán aspectos importantes de la metodología, lenguaje y programas que se utilizarán para el desarrollo del producto.

También se realizará un estudio de los patrones de caso de uso, de diseño y las técnicas de captura de requerimientos más factibles a utilizar.

Las tecnologías actuales del transporte permiten un tráfico elevado de viajeros entre los países. Esto facilita en gran medida el turismo internacional y ayuda al desarrollo de países como Cuba que posee bellos paisajes, una hermosa tradición, cultura e historia. En los últimos años ha crecido notablemente el flujo de turistas hacia el país, sobrepasando por varios años consecutivos los 2 millones de visitantes.

Para el estado cubano es de vital importancia desde el punto de vista económico, mantener una conducta apropiada con los extranjeros que realizan turismo en el país, pero también es importante mantener la seguridad del pueblo cubano. Está claro que un gran número de personas supone un gran número de mercancías asociadas a estas, y que no todas las personas tienen la misma intención al viajar, de forma que pudieran ingresar al estado cubano personas cuyo propósito no sea compartir experiencias sanas en la isla, sino que tengan en mente realizar operaciones que atenten contra la seguridad de los ciudadanos cubanos o que incumplan el código penal por otros delitos cometidos.

El pueblo de Cuba ha sido víctima de múltiples atentados por parte de grupúsculos anticubanos que trabajan fundamentalmente en los Estados Unidos. Se pudieran mencionar ejemplos de acciones terroristas como las bombas puestas en los hoteles de La Habana en el año 1997, experiencias indeseadas como estas suponen que se debe estar alerta en todo momento para impedir el paso de personas o mercancías que pueden causar daños en corto o largo plazo sobre la población.

(14)

Realizar un control en la salida del país es tan importante como realizarlo a la entrada, puesto que podrían extraerse elementos importantes que forman parte del patrimonio nacional, así como artículos prohibidos que contribuyen al contrabando internacional y otros que ponen en riesgo la vida de las personas. En Cuba se cuenta con mercancías que son altamente codiciadas en los distintos países, estas a su vez poseen un alto valor comercial y por tanto han sido objetos de contrabandos. Ejemplo de estas se pudiera mencionar el tabaco y el ron cubano, además de especies endémicas como la polimita, el zunzuncito, el carpintero verde, entre otras.

1.2 Aplicación de Sistemas Informáticos en el mundo.

1.2.1 Sistemas extranjeros.

No solo Cuba ha sido víctima de atentados terroristas o de contrabandos, sino que en los últimos años países como los Estados Unidos, España y Gran Bretaña han sufrido también estos tipos de acciones, se pueden citar por ejemplo, el acto de terrorismo ocurrido el 11 de septiembre de 2001 en la ciudad de Nueva York, donde aeronaves impactaron contra dos de los edificios más altos de esa ciudad, o como el ocurrido en Madrid el 11 de marzo del 2004 que hicieron estallar bombas en 4 trenes casi simultáneamente. Es por eso, que lograr la seguridad de las personas es un tema muy importante para todos los países del mundo y realizar control sobre el tráfico de personas que pasan por sus fronteras, es una parte importante del objetivo planteado. Utilizar software que ayuden a llevar un control sobre las personas que arriban o salen de los países, es realmente primordial para conseguir la seguridad anhelada, debido a esto existen varios sistemas informáticos que se encargan de implementar funcionalidades de este tipo. Ejemplos de estos son:

Smart Border Control.

Smart Border Control se traduce al español como Inteligente Control en Frontera. Es un sistema alemán de identificación de personas desarrollado por la empresa Dermalog, está elaborado de forma modular, lo que permite que los usuarios puedan configurarlo para satisfacer sus requisitos. Cuenta además con interfaces y módulos disponibles para conectarse con sistemas periféricos que complementen el control de personas en las fronteras. La empresa proporciona capacitación, instalación, soporte y hardware necesario para la implantación del software. El sistema está capacitado para leer y validar documentos de

(15)

identificación. También utiliza reconocimiento biométrico de imágenes faciales y cuenta con la funcionalidad de guardar un histórico de las personas.

Sistema de Control de Fronteras.

Es un sistema especializado en la verificación y autenticación de documentos de identificación. Pone en práctica las técnicas más modernas para la validación de documentos como el reconocimiento de ICR*

de Tarjetas de Entrada/Salida, reconocimiento facial y la comparación de huella dactilar frente a una lista de huellas de los más buscados. Cuenta con una base de datos de personas peligrosas y emite un aviso a los inspectores en caso de coincidencia con los individuos identificados. Es desarrollado por la empresa Telvent y proporciona una solución Web, desarrollado con Microsoft Visual Studio .NET, utiliza como gestor de base de datos Oracle y para el trabajo con imágenes las librerías Martox.

*ICR: Reconocimiento Inteligente de Caracteres. La tecnología ICR proporciona a los sistemas de reproducción por escáner y sistemas de imágenes, la habilidad de convertir caracteres en letra manuscrita a caracteres capaces de ser interpretados y reconocidos por una computadora.

CEN.

Es un sistema de alcance mundial utilizado por la Organización Mundial de Aduanas (OMA), sus siglas significan Red Aduanera de Lucha Contra el Fraude (en ingles: Customs Enforcement Network). El CEN empezó a funcionar en julio de 2000 con el objetivo de respaldar e intensificar en las aduanas del mundo la lucha contra la delincuencia trasnacional. En el mismo, las administraciones de las aduanas de los países tributan información de infracciones ocurridas. Trabaja con una serie de estandarizaciones en los datos capaz de recoger prácticamente toda la información sobre una infracción mediante codificaciones, esto resulta realmente importante para poder realizar los reportes, los cuales señalan a individuos como personas peligrosas ante un país determinado. Por otra parte, el sistema puede mostrar las tendencias más comunes de contrabando sobre las mercancías, y los modos de operar más usados en la actualidad.

Esto se logra por el gran volumen de información que es capaz de almacenar. En la actualidad, más de 1.600 funcionarios de aduanas en más de 150 países acceden desde el CEN a más de 150.000 datos relativos a incautaciones. La información proporcionada por el sistema puede ser usada por los

(16)

especialistas de LCF para controlar las personas señaladas, recurriendo a los modus operandis* más utilizados en la actualidad.

* modus operandis: Expresión oriunda del latín significa literalmente “modo de operar”. Esta expresión se emplea para hacer referencia al modo característico de actuar de un delincuente.

Border Management Systems (BMS).

Este software es una solución que integra las funcionalidades más importantes que debe tener un sistema para el control fronterizo, sus siglas en ingles representan Sistema de Administración de Fronteras. Es desarrollado por la empresa australiana Natural Systems la cual posee experiencia en sistemas de inmigración desde el año 1990. Incorpora lector y autenticación de documentos, almacenamiento de imágenes, verificación de listas de alertas, advertencias de viajes irregulares e historial de las personas.

Contiene además, un módulo de estadística que es configurable según las necesidades del usuario y permite integración con sistemas emisores de pasaportes, policía, Interpol, aduanas, software biométricos y con las aerolíneas para obtener la información adelantada de pasajeros.

1.2.2 Soluciones cubanas.

El flujo masivo de pasajeros en el país se presenta por vía aérea, esto está fundamentado por las características geográficas de Cuba. Es entonces en los aeropuertos, donde se escenifica realmente el control de personas, haciéndose necesario la utilización de importantes soluciones de software. En Cuba, la Aduana trabaja con los organismos de Inmigración de forma cooperada, de modo que intercambian constantemente información, de aquí que las soluciones de software desde el punto de vista de la Aduana no requieren necesariamente validar la originalidad de los documentos de identificación. Cada vez que un viajero se presenta ante Inmigración, este valida los documentos, e inserta los datos de la persona en el sistema SENTINEL y la Aduana por un acuerdo establecido tiene acceso a los datos entrados por el sistema anteriormente mencionado. Los datos que recibe la Aduana desde Inmigración son:

1er Nombre: Define el primer nombre de la persona que pasa por inmigración.

1er Apellido: Define el primer apellido de la persona que pasa por inmigración.

2do Nombre: Define el segundo nombre de la persona que pasa por inmigración.

(17)

2do Apellido: Define el segundo apellido de la persona que pasa por inmigración.

Hora: La hora exacta de registrar el documento.

Taquilla: El número de la taquilla de inmigración donde el viajero realiza los trámites migratorios.

Entrada/Salida: Si está entrando o saliendo del País.

Sexo: El sexo de la persona.

De obtener los datos desde la red de Inmigración se encarga el sistema Loren, software desarrollado por el Centro de Automatización de la Dirección y la Información (CADI). Este sistema ejecuta un procedimiento almacenado de la base de datos de Inmigración, operación que se realiza cada 2 segundos, de esta forma se obtienen los datos de las personas que están entrando o saliendo del país.

Este sistema permite entrar una lista de riesgos para emitir un mensaje de voz en caso de obtener coincidencias entre la lista de riesgos y las personas que se obtienen desde el procedimiento. Es importante destacar que la búsqueda realizada es fonética, porque puede darse el caso de una persona que no se conozca la forma exacta de escribir su nombre y sin embargo cuando se insertan sus datos en la lista de riesgo, el sistema es capaz de emitir un aviso por coincidir fonéticamente.

El otro sistema utilizado por parte de la Aduana es el Sistema Automatizado de Personas de Interés Aduanal (SAPIA). Este software está desarrollado en FoxPro versión 3.4 y se utiliza para la gestión de las personas de interés aduanal, siendo capaz de mostrar a partir de un mensaje API las personas de interés que están en el vuelo. Además permite realizar reportes como el listado de los mensajes API llegados, listados de PIA, listado de repetidores, y admite la impresión de la ficha de una persona para que el vice jefe de LCF apruebe o rechace la categoría aduanal. Todas estas funciones permiten a los analistas de LCF obtener información sobre las personas que se han presentado en la Aduana.

Utilizando los dos sistemas anteriores, los analistas de Lucha Contra el Fraude son capaces de materializar acciones de enfrentamiento para encontrar blancos*.

*blancos: Se refiere a un término aduanero, que se utiliza para denominar a las personas que son posibles infractores de acuerdo a un análisis previo.

(18)

No cabe duda que lograr un software que cumpla con los requisitos necesarios para el control de personas en los aeropuertos es muy importante, para esto el futuro sistema debe contar con opciones que permitan un buen desempeño a los usuarios finales. Analizando las funcionalidades que brindan los sistemas anteriormente mencionados, se obtiene como resultado para la solución cubana del Control de Personas en los aeropuertos, contar con las opciones que realizan los actuales “Loren” y “SAPIA”, como son: tener una lista de riesgos (opción también realizada por el “Sistema de Control de Fronteras” y el

“BMS”), emitir avisos sobre personas identificadas, contar con conexión a Inmigración, gestionar PIA y realizar múltiples reportes. También se contará con varias de las funcionalidades de los sistemas foráneos como el “BMS” que trabaja la información adelantada de pasajeros y el histórico de cada persona, opción presentada igualmente por “Dermalog Smart Border Control”, además se codificarán los datos de las infracciones a partir de la experiencia recogida del sistema “CEN” que tiene esta funcionalidad.

1.3 Metodología, lenguaje y herramienta de modelado para el desarrollo.

El Sistema Único de Aduanas es la solución software cubana para la gestión de los procesos aduanales.

Es desarrollado por la Universidad de las Ciencias Informáticas (UCI) en trabajo unido a los especialistas del CADI. Este trabajo en conjunto se inició en el año 2004 y dentro de los planes de desarrollo se encuentra el subsistema de enfrentamiento que se encargará del desarrollo de los procesos que en esta área se realizan. Precisamente uno de los módulos del subsistema es el Control de Personas, encargado de realizar un sistema con nuevas funcionalidades, para mejorar el trabajo que se realiza hoy en el flujo de viajeros.

Dentro de la universidad el trabajo se desarrolla mediante polos productivos, exactamente el SUA es un producto que desarrolla el polo Sistemas Tributarios y de Aduanas (STA). Existen definiciones ya probadas de las tecnologías de trabajo, así como las herramientas a utilizar en todo el polo. No se pretende realizar un análisis del por qué de su utilización, pero si brindar información de sus ventajas más notables.

(19)

1.3.1 Metodología de desarrollo.

Se utiliza el Proceso Unificado de Rational (RUP) con adaptaciones especiales al proyecto. Esta metodología propone utilizar el Lenguaje Unificado de Modelado (UML), donde forman la metodología estándar más utilizada para el análisis, diseño, implementación y documentación de sistemas orientados a objetos. Esta metodología constituye una guía rectora que decide quién hace qué, cuándo y cómo lo hace.

RUP dirige las actividades que se realizan por rol, les da un orden, define qué artefactos deberían ser desarrollados y puede además monitorear y medir los productos y actividades de un proyecto, teniendo en cuenta la calidad del producto final. RUP se caracteriza por dividir el ciclo de vida de la producción del software en 4 fases:

 Inicio o Conceptualización: es donde se determina la visión del proyecto, o sea se comprende el entorno y se determina el alcance del producto.

 Elaboración: en esta etapa se determinan los cimientos de la arquitectura y se analiza el dominio del problema.

 Construcción: en esta fase se obtiene la capacidad operacional inicial del producto.

 Transición: Se obtiene el release o liberación del producto y se pone en manos de los usuarios finales.

Además de esto cuenta con 9 flujos de trabajo, 6 de ingeniería y 3 de soporte los cuales son:

Modelamiento del negocio, Requerimientos, Análisis y Diseño, Implementación, Prueba, Despliegue, Gestión de configuración y cambios, Gestión de proyectos y por último Entorno, donde los 3 últimos constituyen los flujos de soporte. Esta metodología puede especializarse para una gran variedad de sistemas software, para diferentes áreas de aplicaciones, diferentes tipos de organizaciones, diferentes niveles de amplitud y diferentes tamaños de proyectos.

(20)

Fig.1: Fases y flujos de trabajo de RUP

Los elementos característicos del RUP son:

 Actividades: son los procesos que se llegan a realizar en cada iteración.

 Trabajadores: son las personas o entidades involucradas en cada proceso.

 Artefactos: un artefacto puede ser un modelo, o un elemento de modelo, un documento, en fin todo lo que puede ser generado en el proceso.

 Flujo de Actividades: secuencia de actividades realizadas por trabajadores que producen un resultado de valor observable.

Sus características principales son:

 Dirigido por casos de uso. Los casos de uso guían el proceso de desarrollo pues los modelos que se obtienen representan la realización de los mismos.

 Centrado en la arquitectura. La arquitectura muestra la visión común del sistema completo en la que el equipo de proyecto y los usuarios deben estar de acuerdo.

 Iterativo e incremental. Una iteración involucra actividades de todos los flujos de trabajo, aunque desarrolla fundamentalmente algunos más que otros. En el caso de una iteración de la fase de elaboración, se centra la atención en el análisis y diseño, a la vez que se refinan los requerimientos

(21)

y se obtiene un producto con un determinado nivel, que irá creciendo incrementalmente en cada iteración.

1.3.2 Notación para el Modelado de Procesos de Negocio.

En el polo productivo se utiliza la notación de modelado de procesos de negocio BPMN (Business Process Modeling Notation) es una notación gráfica que representa los pasos de un proceso de negocio.

Con la utilización de esta notación se comprende rápidamente todo el negocio, desde el analista de negocio que hace el borrador inicial hasta los desarrolladores, responsables de implementar la tecnología que llevarán a cabo dichos procesos, para llegar finalmente a los clientes que son los que gestionarán y monitorizarán esos procesos.

El modelado en BPMN se realiza mediante diagramas muy simples con un conjunto muy pequeño de elementos gráficos. Las cuatro categorías básicas de elementos son:

Objetos de flujo: Eventos, Actividades, Rombos de control de flujo (Gateways).

Objetos de conexión: Flujo de Secuencia, Flujo de Mensaje, Asociación.

Swimlanes (Carriles de piscina): Pool, Lane.

Artefactos: Objetos de Datos, Grupo, Anotación.

Estas cuatro categorías de elementos dan la oportunidad de realizar un diagrama simple de procesos de negocio (en inglés Business Process Diagram o BPD). En un BPD se permite definir un tipo personalizado de Objeto de Flujo o un Artefacto, si con ello se hace el diagrama más comprensible.

Otra ventaja de utilizar BPMN para los modeladores y las herramientas de modelado es que muestra flexibilidad a la hora de extender la notación básica. La más importante de todas es que este lenguaje de modelado toma un enfoque orientado al proceso, esto posibilita modelar tal y como suceden estos, en la empresa.

(22)

1.3.3 Tipo de sistema y plataforma.

El SUA es un sistema Web que se desarrolla sobre el sistema operativo GNU/Linux. Es multiplataforma, lo que significa que no requiere de una plataforma específica para su funcionamiento por lo tanto puede funcionar en los sistemas GNU/Linux como Windows, debido a que el lenguaje utilizado (PHP), el framework* de desarrollo (Symfony) y la base de datos (Oracle) también son multiplataformas.

*Framework: Palabra técnica para referirse al marco de trabajo a utilizar. Consiste en un software que facilita notablemente el trabajo de los desarrolladores y ahorra tiempo de desempeño. Este puede incluir librerías, soluciones, otras aplicaciones, etc.

1.3.4 Lenguaje de programación.

Como lenguaje de programación se utiliza el PHP en su versión 5.0.4. Conocido como una tecnología de código abierto que resulta muy útil para diseñar de forma rápida y eficaz aplicaciones Web dirigidas a bases de datos. Este es un lenguaje de programación que se interpreta y ejecuta directamente en el servidor en el que está albergada la página Web, con lo que el visitante a la misma, únicamente recibe el resultado buscado por el código en el que está escrito. Es orientado a objetos y está ampliamente difundido en todo el mundo, presentando grandes volúmenes de documentación que son de gran ayuda para los desarrolladores.

1.3.5 Framework de trabajo.

Symfony es un framework de PHP totalmente libre y de los más usados en la actualidad. Está diseñado para optimizar el desarrollo de aplicaciones Web. Entre sus características se presenta que separa la lógica del negocio, la lógica de servidor y la presentación de la aplicación. Facilita herramientas y clases encaminadas a reducir el tiempo de desarrollo de una aplicación Web compleja. Además presenta abstracción a la base de datos y es compatible con las bases de datos SQLite, MySQL, PostgreSQL y Oracle, esto tiene como ventaja que se puede cambiar de gestor de base de datos realizando pequeños cambios en el archivo de configuración.

(23)

1.3.6 Interfaz de Usuario.

La interfaz de usuario se desarrolla con las librerías ExtJS para el lenguaje JavaScript, estas permiten el desarrollo de aplicaciones Web interactivas usando tecnologías como AJAX, JSON, DHTML. ExtJS proporciona una serie de componentes para incluir dentro de una aplicación Web que facilitan mucho el trabajo de los desarrolladores y hacen más agradable la aplicación para los usuarios, algunos de estos componentes son: los cuadros, las áreas de texto, campos para fechas, campos numéricos, combos, radiobutton y checkboxs, editores de HTML, árbol de datos, pestañas, menú al estilo de Windows, entre otras. Tiene como ventaja además que una vez que el navegador haya interpretado el código JavaScript, el usuario se sentirá trabajando en el sistema como si fuera una aplicación de escritorio. Esto está dado porque la transacción de información se realiza a partir de comunicaciones asincrónicas.

Es importante mencionar que la tecnología AJAX acrónimo de Asynchronous JavaScript And XML (en español JavaScript asincrónico y XML), permite realizar una comunicación asíncrona con el servidor en un segundo plano, de forma que se pueden hacer cambios sobre una página Web sin necesidad de actualizarse completamente. Por su parte el JSON, acrónimo de "JavaScript Object Notation", es un formato ligero para el intercambio de datos que se utiliza también para la comunicación asincrónica.

1.3.7 Sistema gestor de base de datos.

Oracle es un sistema gestor de base de datos relacional desarrollado por la empresa “Oracle Corporation”, este gestor es considerado de los más completos y potentes, destacado por su soporte de transacciones, estabilidad, escalabilidad y ser multiplataforma. La Aduana cubana ha adquirido experiencias positivas con Oracle usándolo desde el año 1997.

1.3.8 Herramienta CASE*.

Como herramienta CASE se utiliza el Visual Paradigm, resulta muy provechosa su utilización pues soporta UML 2.1 además de BPMN y generación de código para PHP. En el trabajo con UML se pueden realizar 13 diagramas de los cuales se pueden mencionar el diagrama de casos de uso, el diagrama de clases, diagrama de secuencias y el de despliegue. Presenta además la posibilidad de generar la documentación del trabajo realizado, la administración de los requerimientos y la creación de esquemas a partir de una base de datos ya existente y viceversa.

(24)

*CASE: Siglas en ingles que se utilizan para referirse a Ingeniería de Software Asistida por Computadora.

1.4 Patrones y técnicas de captura de requisitos.

En el desarrollo de software existen problemas comunes a los cuales se le da solución con el uso de patrones, pues en la práctica y en el transcurrir de los años se ha demostrado que son soluciones eficientes a dificultades presentadas. Según la definición de Craig Larman:

“Un patrón es un par problema/solución con nombre que se puede aplicar en nuevos contextos, con consejos sobre cómo aplicarlo en nuevas situaciones, o sea, un patrón es una descripción de un problema bien conocido que suele incluir: descripción, escenario de uso, solución concreta, consecuencias de utilizar el patrón, ejemplos de implementación y lista de patrones relacionados.” [17]

Otra definición de patrón es la utilizada por Christopher Alexander que plantea:

“Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, para describir después el núcleo de la solución a ese problema, de tal manera que esa solución pueda ser usada más de un millón de veces sin hacerlo ni siquiera dos veces de la misma forma.” [22]

Características de los patrones:

 Solucionan un problema: los patrones capturan soluciones, no sólo principios o estrategias abstractas.

 Son un concepto probado: capturan soluciones demostradas, no teorías o especulaciones.

 La solución no es obvia: los mejores patrones generan una solución a un problema de forma indirecta.

 Describen participantes y relaciones entre ellos: describen módulos, estructuras del sistema y mecanismos complejos.

 El patrón tiene un componente humano significativo: todo software proporciona a los seres humanos confort y calidad de vida (estética y utilidad).

Los patrones se pueden clasificar según el tipo de problema a los que dan solución, debido a esto se encuentran patrones de casos de usos, patrones arquitectónicos, patrones de diseño, entre otros. Los de

(25)

casos de uso, tienen como principal fortaleza asegurar la consecución de un buen modelado del problema y su solución. Por su parte los de arquitectura expresan una organización o esquema estructural fundamental para sistemas software. Y los de diseño proporcionan esquemas para refinar subsistemas o componentes de un sistema.

1.4.1 Patrones de Casos de uso.

El nombre revela la intención: Hace un llamado al uso de nombres descriptivos para los casos de usos, que ubiquen expectativas en el lector. Es decir que revelen la intención del caso de uso y refleje el únic o objetivo que el actor está intentando lograr. Para ello este patrón propone como buena práctica nombrar los casos de uso comenzando con un verbo activo que describa el uso del caso de uso y seguido del verbo con una frase que describa su propósito. Ser conciso pero lo suficientemente descriptivo para capturar la esencia del caso de uso.

Completar una única meta: Consiste en escribir cada caso de uso dirigido hacia una completa y bien definida meta.

Alternativas exhaustivas, íntegras: Trata de capturar todos los fallos y alternativas que deben ser manejados en el caso de uso. Una vez se tienen identificados todos los casos de uso y su flujo principal, se identifican y capturan todas las variaciones del flujo principal que se quiera que el sistema maneje.

Preciso y Legible: El presente patrón plantea escribir cada caso de uso lo suficientemente legible, para que los clientes los lean, evalúen y precisen con exactitud; además que los implementadores entiendan qué están construyendo. Cada caso de uso que se escriba debe exactamente describir una meta única y completa sin ser tan verboso que la audiencia no lo pueda leer o de tan alto nivel que no comunique la suficiente información para entenderlo adecuadamente.

CRUD: Este patrón plantea la definición de un solo caso de uso que fusione diferentes operaciones que pueden ser realizadas como simples casos de uso. Se habla de operaciones como adicionar, eliminar, actualizar y consultar segmentos de información dentro de un caso de uso formando una sola unidad conceptual, cuando se fusionan las cuatro funciones anteriormente mencionadas se denomina CRUD

(26)

Completo. Por otra parte se nombra CRUD Parcial al patrón alternativo que es usado cuando no se tienen las cuatro funcionalidades juntas en un solo caso de uso o cuando unas de las alternativas de los casos de uso es más significativa, larga o más compleja que las otras.

Claro Conjunto de Roles: Plantea identificar los actores y el rol que cada uno juega con respecto al sistema. Describir claramente cada uno de los actores con que el sistema debe actuar recíprocamente.

Esto es porque si se analizan solo los usuarios del sistema y preferiblemente después los roles que los usuarios juegan con respecto al sistema o las partes interesadas en esos roles, entonces se pierden comportamientos importantes del sistema o se introducen comportamientos redundantes.

Frontera Visible: Es necesario establecer una frontera visible entre el sistema y su ambiente, enumerando quién y que actúa recíprocamente con el sistema, ya que este alcance del sistema puede crecer de manera incontrolable si no se conocen las fronteras. Una frontera visible limita y soporta el patrón clara visión compartida para:

Especificar con qué sistemas y personal externos debe colaborar el sistema.

Especificar qué recursos tiene el sistema disponible para lograr su propósito.

Clara Visión Compartida: La falta de una clara visión sobre el sistema puede inducir a indecisiones y opiniones contrarias entre las partes interesadas y puede rápidamente paralizar el proyecto. Como solución a este problema se pide preparar una declaración del propósito del sistema que describa claramente los objetivos del sistema. Garantizar que esa visión apoye la misión de la organización, y distribuirlo libremente a todos involucrados con el producto. Debe incluir:

Los objetivos del sistema.

Los problemas que el sistema está resolviendo.

Los problemas que el sistema no está resolviendo.

Quiénes son los stakeholders.

Cómo el sistema beneficiará a los stakeholders.

(27)

1.4.2 Patrones de Diseño.

GRASP

Los patrones GRASP acrónimo de General Responsibility Assignment Software Patterns (patrones generales de software para asignar responsabilidades), describen los principios fundamentales de la asignación de responsabilidades a objetos, expresadas en forma de patrones.

Craig Larman en su libro “UML y Patrones” define: “Los patrones GRASP constituyen un apoyo para la enseñanza que ayuda a uno a entender el diseño de objetos esencial, y aplica el razonamiento para el diseño de una forma sistemática, racional y explicable.” [17]

GOF

Los patrones GOF (acrónimo de Gang of Four en español banda de los cuatro), se dividen en tres grupos fundamentales, de creación, estructura y comportamiento. Los primeros se encargan de mostrar una guía de cómo crear objetos cuando sus creaciones requieren tomar decisiones. Estas decisiones serán normalmente resueltas dinámicamente, decidiendo que clases instanciar o sobre que objetos se delegará responsabilidades. Los de estructura se encargan de describir la forma en que diferentes tipos de objetos pueden ser organizados para trabajar unos con otros. Y los de comportamiento se utilizan para manejar, organizar y combinar comportamientos.

1.4.3 Las técnicas de captura de requerimientos.

Durante el desarrollo de un software uno de los problemas que se presenta es el relacionado con la captura de requisitos, esto ocurre porque no hay un modelo o un proceso definido para enfrentar esa labor tan importante. Los datos son extraídos de las personas consultadas y ciertamente pueden variar de un cliente a otro. Por tanto para asegurar una captura de requisitos eficaz se tienen en cuenta varias técnicas para efectuarla correctamente.

Entrevistas

Las entrevistas se emplean para reunir información proveniente de personas o de grupos para recolectar información en forma verbal, a través de preguntas elaboradas por el analista, estas preguntas se les realizan a quienes se encuentran vinculados con la aplicación, a usuarios con gran nivel de conocimiento del sistema o a personas que pueden proporcionar datos. El éxito de esta técnica, depende de la habilidad

(28)

del entrevistador y de su preparación para la misma. Son prácticamente inevitables en el desarrollo, pues son unas de las formas de comunicación más naturales entre personas.

Lluvia de ideas

Este es un modelo que se usa para generar ideas. La intención en su aplicación, es la de generar la máxima cantidad posible de requerimientos para el sistema. No hay que detenerse en pensar si la idea es o no del todo utilizable. La intención de este ejercicio es generar, en una primera instancia, muchas ideas.

Prototipos

Los prototipos son simulaciones del posible producto, que luego son utilizados por el usuario final, permitiendo conseguir una importante retroalimentación en cuanto a si el sistema diseñado con base a los requerimientos recolectados le permite al usuario realizar su trabajo de manera eficiente y efectiva.

Casos de uso

Los casos de uso permiten describir la posible secuencia de interacciones entre el sistema y uno o más actores, en respuesta a un estímulo inicial proveniente de un actor, es una descripción de un conjunto de escenarios, cada uno de ellos comenzado con un evento inicial desde un actor hacia el sistema. La mayoría de los requerimientos funcionales, si no todos, se pueden expresar con casos de uso.

Observación

Observar como se hacen las cosas es una buena manera de entender lo que estas requieren. Conectarse íntimamente con la cultura de la organización, vivirla, es una herramienta que debe ser tomada en cuenta.

También se pueden realizar filmaciones del lugar de trabajo, para luego observarlas y analizarlas, buscando patrones, procesos y problemas.

Sistemas existentes

Esta técnica consiste en analizar distintos sistemas ya desarrollados que estén relacionados con el sistema a construir. Por un lado, se pueden analizar las interfaces de usuario, observando el tipo de información que se maneja y como es manejada. Esto puede ser útil para descubrir información importante a tener en cuenta, información que tal vez el cliente/usuario haya fallado en comunicar. Es

(29)

recomendable que luego de haber analizado el sistema, este sea mostrado al cliente/usuario, ya que por su experiencia puede sugerir importantes y nuevas ideas.

Todas estas técnicas son muy útiles para efectuar la captura de requisitos del software, de manera que permiten obtener una gran cantidad de información del sistema a construir. Además proveen métodos a utilizar para que el analista de software sea capaz de lograr un acuerdo con los clientes sobre el producto a desarrollar. En este documento se plasmarán las técnicas empleadas en el Cáp. 2.

1.5 El rol de analista.

El analista dirige y coordina la etapa de elicitación de requerimientos y modelación de casos de uso de manera que va perfilando las funcionalidades del sistema y delimitando el mismo. Por ejemplo él delimita quiénes son los actores y cuáles son los casos de uso que propician la interacción con el sistema.

La persona que trabaje como el rol de analista debe ser experta identificando y entendiendo problemas y oportunidades. Ha de contar con habilidades para ofrecer soluciones a las necesidades del problema.

Debe ser muy comunicativa. El conocimiento del negocio y el dominio de tecnologías han de ser otras habilidades importantes en este rol, que vienen a perder un poco de importancia si es un profesional que entiende y absorbe las nuevas informaciones rápidamente. Algo que no debe faltar es que tiene que ser capaz de colaborar eficazmente con los otros integrantes del equipo.

Artefactos y responsabilidades del Analista

Artefactos Responsabilidades

1. Modelo de Procesos

2. Especificación de Requisitos

3. Modelo de Casos de Uso del Sistema

Participar en la definición del proyecto.

Modelar el negocio.

Definir los requisitos de la aplicación.

Realizar los prototipos de interfaz de usuario.

Modelar el sistema.

(30)

1.6 El rol de diseñador.

El diseñador es el responsable de diseñar partes del sistema, teniendo en cuenta las restricciones de los requerimientos, la arquitectura y el proceso de desarrollo para el proyecto. Él identifica y define las responsabilidades, funcionamientos, atributos, y relaciones de los elementos del diseño. Asegura que el diseño es consistente con la arquitectura del software, y la detalla a un punto donde la aplicación puede proceder.

La persona que desempeñe el rol de diseñador debe contar con sólidos conocimientos en cuanto a los requisitos del sistema, la arquitectura del mismo, las técnicas de diseño de software, incluyendo el análisis orientado objeto y el lenguaje unificado de modelado, las tecnologías en las que el sistema será implementado y las líneas bases del proyecto.

Artefactos y responsabilidades del Diseñador

Artefactos Responsabilidades

1. Clases del diseño.

2. Paquete del diseño 3. Diagrama de secuencias 4. Diagrama de despliegue 5. Modelo de base de datos.

Definir los elementos del diseño.

Asegurar la coherencia del diseño con la arquitectura.

Integrar los componentes de la solución.

Dirigir el trabajo de los programadores.

1.7 Conclusiones parciales.

En este capítulo se demuestra la importancia que tiene para la Aduana cubana y para todo el país un software que ayude a controlar las personas. Además se estudian los sistemas extranjeros que trabajan con un objetivo similar, el de lograr mayor seguridad en las fronteras, de las funcionalidades de estos software se toman ideas, las cuales se implantarán en la propuesta, de forma que el producto cuente con opciones similares a las de sus competidores en el mundo.

(31)

Capítulo 2.

Descripción de la solución propuesta.

2.1 Introducción.

En el presente capítulo se describe la solución propuesta. Comenzando por una descripción de los procesos a automatizar y los problemas existentes que hacen necesario la informatización de estos.

También se describen los requisitos funcionales que han de satisfacer el sistema. Se modela el diagrama de casos de usos y se detallan los beneficios esperados.

2.2 ¿En qué consisten los procesos a informatizar?

El área de Lucha Contra el Fraude es la encargada de impedir la entrada o salida de productos, artículos y personas que atenten contra la seguridad de la sociedad cubana, además de proteger al país del tráfico ilegal de armamentos, explosivos, drogas, sustancias químicas, objetos del patrimonio cultural, especies protegidas, tráfico ilegal de personas y otras. Este trabajo se centrará específicamente en los procesos realizados en el control de personas naturales y las acciones para enfrentar toda actividad ilícita. Según el estudio realizado en el campo de acción, se observa el proceso Controlar Persona, que a su vez tiene asociado tres subprocesos fundamentales:

El primero, encargado de gestionar las Personas de Interés Aduanal, este subproceso comienza realizando el análisis y selección de personas que serán propuestas como PIA, estas deben ser aceptadas por el jefe de la unidad para que el administrador del SAPIA introduzca todos los datos necesarios en el Sistema Automatizado de Personas de Interés Aduanal, encargado de gestionar las personas naturales que cometen infracción o que son de interés para la Aduana hacerle un seguimiento.

Periódicamente el administrador del SAPIA en la jefatura revisa e imprime la planilla de todas las propuestas realizadas en las unidades, donde el vice jefe de Lucha Contra el Fraude tiene la facultad para aceptar o rechazar las propuestas, justificando su decisión en caso de no ser aceptada. Luego un administrador actualiza los datos en el sistema. En este proceso también participan los órganos operativos del MININT, con el objetivo de que la Aduana separe del flujo de viajeros las personas de su interés al

(32)

pasar por frontera. Es por ello que solicitan a la Aduana introducir estas personas, catalogándolas como PIA Loren MININT en la base de datos y al igual que en la situación anterior el vice jefe analiza las planillas y acepta o rechaza las propuestas realizadas. Ver la figura 2.1. Este subproceso es la base, sobre el cual se apoya el segundo llamado “Realizar análisis de vuelo”.

Figura 2.1. Modelo del subproceso Gestionar PIA.

(33)

El mismo comienza con la salida de un avión que tiene como destino Cuba, donde la aerolínea al cual pertenece el vuelo, emite un mensaje con los datos de todos los pasajeros que realmente vienen en el avión. Este mensaje se consulta en la Aduana para realizar un estudio previo de las personas que entrarán al país, posibilitando a los analistas conocer cuáles son las personas que se les debe realizar un mayor control. Para conocer las personas que necesitan este control, los analistas utilizan el Sistema Automatizado de Personas de Interés Aduanal donde se compara cada uno de los datos de las personas que están en el mensaje API con las registradas en el SAPIA. Como resultado de este estudio se obtiene una lista con los datos de las personas que se quieren controlar, estos datos se introducen de forma manual en el sistema Loren. Ver figura 2.2.

Figura 2.2. Modelo del subproceso Realizar análisis de vuelo.

Es aquí donde comienza el tercer subproceso llamado “Controlar persona por frontera” donde se verificará con el mensaje que manda Inmigración si los datos de la persona entrante/saliente, coinciden con los datos de las personas a controlar en el sistema Loren, si coincide se le informa rápidamente al inspector del salón el número de la puerta por donde hará salida el viajero, además del tratamiento que debe realizar, como puede ser: cacheo corporal, rayos X, Ionscan, y otras técnicas de detección

.

En caso de detectar una infracción se introducen los resultados del control en un documento llamado AGR2 donde se toman todas las medidas providentes: ejemplo de estas son: decomiso, multa, retención o traslado a otro organismo. Cuando la persona no coincide sigue el flujo normal de viajeros, si el inspector capta un indicio, se llena el “Modelo de Obtención de Información Operativa” luego se procede a un control para encontrar la posible infracción, que de ser positiva se llenaría el AGR2. Ver figura 2.3.

(34)

Figura 2.3. Modelo del subproceso Controlar persona por frontera.

2.3 ¿Qué dificultades existen en la práctica que hacen necesario la informatización de los procesos?

En un entorno altamente cambiante y demandante como el de hoy, se hace necesario modificar el funcionamiento de las organizaciones, y por ende sus procesos. Ya no se piensa en diseños con una estructura ideal e inmutable con el paso de los años, sino permanentemente sometidos a revisiones, en virtud de que cada proceso de por sí es mejorable y para lograr esto, lo primero que debe hacerse es identificar los problemas existentes en los procesos identificados.

(35)

Unas de las dificultades que aprecian los usuarios del Sistema Automatizado de Personas de Interés Aduanal desarrollado en el lenguaje FoxPro versión 3.4, es el complicado entorno de trabajo que presenta la aplicación al tener que trabajar en un ambiente de modo texto, donde la navegación es difícil porque se deben memorizar varias combinaciones de teclas para cada acción que se pretenda realizar. El sistema gestor de bases de datos utilizado es el que trae originalmente el lenguaje FoxPro, imposibilitando tener una base de datos única, que permita lograr una integración con otros sistemas utilizados por la Aduana que usan Oracle.

El sistema no permite establecer más de una línea de enfrentamiento para controlar a una persona, esto puede ocurrir en la realidad perfectamente. Para poder realizar esta operación hoy día es necesario entrar nuevamente los datos personales al sistema. Respecto al control de las personas naturales que cometen infracción, el sistema no permite recoger la cantidad de datos suficientes que necesitan los analistas para lograr un trabajo eficiente por ejemplo: la medida a tomar de la infracción, las fotos del hecho y cuando efectuar el control sobre una persona (a la entrada, la salida o en ambos casos). Por otra parte el administrador del SAPIA y el personal del departamento de análisis tienen que trabajar sobre un escritorio remoto, para poder acceder a los mismos datos, porque la base de datos está en el mismo ordenador.

Es preciso mencionar que la información que maneja el sistema SAPIA y la información API no están correlacionadas, esto retrasa el estudio previo de los viajeros, porque los analistas realizan la búsqueda en el SAPIA y escriben los nombres de las personas a controlar de forma manual, resultando este trabajo difícil y agotador para los usuarios por la gran cantidad de datos que se manejan y la precisión que se deben tener en los mismos para efectuar un control seguro de la persona. Los sistemas SAPIA y Loren no están conectados en red, lo que hace más engorroso el control de las personas, porque después que el analista culmina el estudio del vuelo, realiza un listado con las personas que desea monitorizar cuando pasan por frontera, estos datos se introducen de forma manual en el sistema Loren pudiéndose cometer el error humano. El mensaje que visualiza el Loren no muestra la medida a aplicar, entonces el inspector del salón deberá entrar al SAPIA y ver la medida que disponen los superiores para esa persona, este procedimiento atrasa el flujo de viajeros.

(36)

En los procesos que se realizan en la Aduana para controlar personas existen actividades que se ejecutan de forma manual y otras con ayuda de programas. Por esta razón se requiere realizar un sistema que integre las actividades que hoy se realizan en los programas SAPIA y Loren, que adicione las actividades que se hacen manualmente, e incorpore operaciones que perfeccionen y faciliten aún más el trabajo.

Para lograr este objetivo es necesario conocer los requisitos funcionales que son capacidades o condiciones que el sistema debe cumplir. La obtención de estos se logra a partir de la comunicación entre los desarrolladores y los clientes, hasta alcanzar un acuerdo de las funcionalidades que se esperan en el futuro sistema. Esto propicia además, una elaboración clara de los casos de uso del sistema para guiar el desarrollo del software deseado.

En el desarrollo de un software uno de los problemas que se presenta es el relacionado con la captura de requisitos, esto ocurre porque no hay un modelo o un proceso definido para enfrentar esa labor tan importante. Los datos son extraídos de las personas consultadas y ciertamente pueden variar de un cliente a otro. Por tanto para asegurar una captura de requisitos eficaz se tienen en cuenta varias técnicas para obtenerlos correctamente.

2.4 Técnicas de captura de requisitos.

Unas de las técnicas utilizadas para capturar los requisitos fue la entrevista, donde el cliente explica todo tipo de preguntas relacionadas con su trabajo y expone lo que quisiera lograr en el futuro con el empleo de un software. Esta técnica fue utilizada al realizarle una entrevista a la administradora del SAPIA en la jefatura y a los analistas de LCF en el aeropuerto internacional José Martí utilizando además la técnica de lluvia de ideas para revelar las dificultades existentes en su trabajo. Se utilizó la introspección que consiste en ponerse en el lugar del cliente e imaginar como el quisiera que quedara el sistema, luego sobre la base de estas suposiciones se le recomendó al cliente un grupo de funcionalidades que pudieran resolver su problema. Otra técnica utilizada fue el análisis de prototipos, donde se le presentó al cliente una vista real de cómo quedaría el sistema a desarrollar, en este análisis participaron el Vice jefe de Lucha Contra el Fraude junto al Jefe de la Aduana de Cuba, donde se pudieron definir claramente si la aplicación cumpliría con las necesidades y expectativas creadas. También se emplearon técnicas complementarias como la observación para ver como se hacen las actividades en la institución y el

(37)

estudio de los sistemas existentes en la Aduana para el control de personas. A continuación se detallan los requisitos funcionales.

2.5 Requisitos funcionales.

Requisito Funcional 1

-El sistema debe registrar automáticamente las personas que cruzan frontera. (Utilizando información que provee Inmigración).

Requisito Funcional 2

-El sistema debe poseer la opción de activar un monitoreo sobre todas las personas que transitan por la Aduana, para efectuar aviso en las unidades y en la jefatura, cuando pasen los pasajeros seleccionados.

Requisito Funcional 3

-El aviso que se visualiza en el monitoreo depende del tipo de control que se haya definido en la gestión, este puede ser de entrada o salida del país. Deberá mostrar el número de la puerta por donde cruza el viajero, datos personales, línea de enfrentamiento, modalidad, órgano que lo propone, criterio de marcaje, medida a aplicar y si está entrando o saliendo del país.

Requisito Funcional 4

-El sistema permitirá en caso que detecte coincidencia fonética y no exacta de caracteres, mostrar un cartel de color naranja con una lista de personas coincidentes, donde el Inspector LCF selecciona la persona esperada, en caso de completa coincidencia mostrará un cartel de color rojo fuerte.

Requisito Funcional 5

-El sistema debe mostrar un aviso en caso que existan más personas a controlar y no se haya confirmado el mensaje anterior.

Requisito Funcional 6

-El sistema debe permitir según el usuario escoger la Aduana que se desee realizar el monitoreo.

(38)

Requisito Funcional 7

-El sistema permitirá la selección de un vuelo para realizar un estudio de la Información Adelantada de Pasajeros. Donde se debe mostrar la información relativa a cada pasajero y sus categorías PIA, PIA-Control, Repetidor, Requerimiento Puntual, así como un reloj que avisa el tiempo estimado que le queda al analista para terminar el Estudio API.

Requisito Funcional 8

-El sistema debe marcar por defecto las personas que tienen las categorías PIA-Control o Requerimiento Puntual al realizar el estudio API.

Requisito Funcional 9

-El sistema debe permitir marcar las personas que el analista considere conveniente en la opción Realizar estudio API.

Requisito Funcional 10

-El sistema debe permitir entrar los datos del marcaje al seleccionar una persona. Además de insertar los datos adicionales para las personas que tienen categoría PIA-Control y Requerimiento Puntual.

Requisito Funcional 11

-El sistema debe permitir enviar el estudio API realizado de una Unidad a otra.

Requisito Funcional 12

-El sistema debe permitir modificar el estudio API siempre que no haya entrado un viajero del vuelo seleccionado.

Requisito Funcional 13

-El sistema no debe permitir el acceso a realizar el estudio API después de la entrada del primer viajero por inmigración.

(39)

Requisito Funcional 14

-El sistema debe emitir un mensaje en caso que termine el tiempo estimado de arribo y registrar toda la información adquirida del Estudio API realizado hasta ese instante.

Requisito Funcional 15

El sistema debe registrar todos los estudios API realizados por cada usuario.

Requisito Funcional 16

-El sistema debe tener un historial de todas las personas, mostrando todas las acciones que ha cometido en la aduana.

Requisito Funcional 17

-El sistema debe permitir acceder al historial de una persona cuando: se realice un Estudio API, Gestión de PIA a todos los niveles, Gestión de Requerimiento Puntual, Definir Propuesta, Concretar Propuesta, y por último al Registrar Incidencias.

Requisito Funcional 18

-El sistema debe permitir definir cuando una persona es Repetidor: que ha viajado al país una cantidad de veces mayor e igual que M en N días atrás. M y N son cantidades que son gestionadas por el Jefe LCF AGR.

Requisito Funcional 19

-El sistema debe permitir Gestionar PIA al Analista LCF Unidad. Permitiendo insertar una persona, que no se encuentre en el sistema realizando una propuesta de su categoría aduanal (PIA, PIA- Control). Puede además proponer categoría sobre una persona ya entradas al sistema, así como proponer cambios sobre los PIA y PIA-Control de su unidad.

Requisito Funcional 20

-El sistema debe permitir Gestionar PIA al Jefe LCF Unidad. Permite insertar una persona que no se encuentre en el sistema, realizando una propuesta de categoría PIA-Control o haciendo efectiva

Referencias

Documento similar

En este ensayo de 24 semanas, las exacerbaciones del asma (definidas por el aumento temporal de la dosis administrada de corticosteroide oral durante un mínimo de 3 días) se

En un estudio clínico en niños y adolescentes de 10-24 años de edad con diabetes mellitus tipo 2, 39 pacientes fueron aleatorizados a dapagliflozina 10 mg y 33 a placebo,

• Descripción de los riesgos importantes de enfermedad pulmonar intersticial/neumonitis asociados al uso de trastuzumab deruxtecán. • Descripción de los principales signos

Debido al riesgo de producir malformaciones congénitas graves, en la Unión Europea se han establecido una serie de requisitos para su prescripción y dispensación con un Plan

Como medida de precaución, puesto que talidomida se encuentra en el semen, todos los pacientes varones deben usar preservativos durante el tratamiento, durante la interrupción

Abstract: This paper reviews the dialogue and controversies between the paratexts of a corpus of collections of short novels –and romances– publi- shed from 1624 to 1637:

En junio de 1980, el Departamento de Literatura Española de la Universi- dad de Sevilla, tras consultar con diversos estudiosos del poeta, decidió propo- ner al Claustro de la

5-Imita movimientos de los Órganos articulatorios (sacar la lengua, apretar las mandíbulas, inflar mejillas, soplar, etc.). Modalidad de Evaluación. Cuando no pueda recogerse