Servicios personalizados
Español (pdf)
Articulo en XML
Referencias del artículo
Enviar articulo por email
Citado por SciELO 
Similares en
SciELO 
Permalink
Introducción
Desde los propios cimientos de las sociedades antiguas el ser humano ha tenido la necesidad de controlar sus pertenencias y las del grupo del cual forma parte, por lo que de alguna manera se tenían tipos de control para evitar desfalcos. Con el surgimiento de las relaciones económicas y su evolución en sistemas cada vez más complejos los mecanismos para preservar los bienes han enfrentado desafíos, desarrollándose y jugando un papel protagónico dentro de los más diversos tipos de organizaciones.
Se dice que el control interno es una herramienta surgida de la imperiosa necesidad de accionar proactivamente a los efectos de suprimir o disminuir significativamente la multitud de riesgos a las cuales se hayan afectadas los distintos tipos de organizaciones, estos medios pueden ser de carácter privado o público, con o sin fines de lucro (Mar&Bron, 2016).
Debido a la importancia que ameritan los temas de control, en agosto de 2009 la Asamblea Nacional del Poder Popular en Cuba, crea la Contraloría General de la República, la cual según la Ley 107 (2009) tiene entre sus funciones establecidas: normar, supervisar, evaluar los sistemas de control interno; manifestar las recomendaciones necesarias para su mejoramiento y perfeccionamiento continuo. Los Activos Fijos Tangibles (AFT) representan las propiedades físicamente tangibles con que cuenta una empresa o entidad, con el fin de utilizarse por un período largo en sus operaciones regulares y que normalmente no se destinan a la venta (López, Hurtado & Jiménez, 2012). Existen diversos tipos de activo fijo y cada uno tiene una forma diferente de contabilidad y administración dentro de la organización (Balderas, 2013).
La Universidad de las Ciencias Informáticas (UCI) es un centro cubano de altos estudios con la misión estratégica en el país de la formación de profesionales de alta calidad y la producción de software. El sistema de control interno constituye para la institución garantía de apego a las normas legales respecto a todas las actividades relevantes del centro, representando el mecanismo fundamental de salvaguarda de los recursos o bienes que utiliza de manera continua en el curso de sus operaciones. La preservación y control de los AFT se vuelve tarea primordial en aras de lograr indicadores de eficacia y productividad en muchos de los procesos sustantivos de la entidad, recomendándose como parte del mencionado sistema de control, la auditoría de al menos el 10% de los AFT de manera mensual.
En la Facultad de Ciencias y Tecnologías Computacionales (CITEC) perteneciente a la UCI esta actividad se incluye dentro de la gestión administrativa e involucra a todas las áreas docentes, productivas y de servicio. Algunos inconvenientes hoy limitan la calidad y agilidad con la que se lleva a efecto la auditoría y control de los AFT conforme lo previsto en el sistema de control interno.
El proceso de auditoría mensual se realiza a partir del nivel que cubra la revisión, siendo el responsable del área o centro de costo dentro de la facultad el encargado de obtener a partir del Sistema de Gestión Universitaria (SGU) un listado impreso de los AFT bajo su responsabilidad. Un responsable designado o el propio jefe de área o centro de costo lleva a cabo un testeo manual de los medios, realizando una comparación entre cifras y estado de los activos, debiendo comprobarse su existencia y características. Este modus operandi torna el proceso engorroso e ineficiente con gastos significativos de recursos humanos y materiales, provocando la imposibilidad de cumplir con la cantidad de medios que representa el 10%. Lo anteriormente planteado se reafirma si se tiene en cuenta que la Facultad CITEC cuenta con más de 620 estaciones de trabajo destinadas a los procesos docente-productivos y una aproximación de 2408 AFT en total.
Por otra parte, la forma en la que tiene lugar el proceso no facilita la generación de informes resultantes de las auditorías realizadas, los cuales son realizados de forma manual, lo que introduce una incertidumbre en el dato a partir de un posible error humano. Todo lo anterior limita la toma de decisiones y la calidad y disponibilidad de la información que se presenta. Partiendo de esta problemática se propone como objetivo de la investigación desarrollar una aplicación informática para gestionar el proceso de auditoría y control de los Activos Fijos Tangibles.
Desarrollo
Se propone desarrollar un sistema capaz de agilizar el proceso de auditoría y control de los AFT. La solución se basa en un sistema de escritorio multiplataforma con comunicación mediante servicios al SGU. La aplicación debe ser capaz de, ante la selección de un área determinada a auditar, obtener el listado de medios y servirse de un dispositivo o scanner de barras para apoyar el testeo de los medios, ofreciendo de manera automática los resultados de la auditoria a manera de informe, con gráficos y otros elementos que apoyen la toma de decisiones.
La carencia de una amplia red inalámbrica en el entorno que se propone la solución, descarta la posibilidad de una aplicación web, ya que la mayoría de los medios se encuentran alejados de puntos de acceso cableados a la red, y la movilidad inherente al proceso requiere el trabajo sin conexión. A continuación, en la figura 1, se muestra, de forma gráfica, una idea general de la solución propuesta:
Para seleccionar las herramientas y tecnologías a utilizar durante las diferentes fases del desarrollo de la propuesta de solución, se partió del análisis de varios criterios pertinentes. Dentro de estos criterios se tomaron en cuenta las tendencias en el desarrollo de software más acertadas de acuerdo a las características del sistema, el acceso y disponibilidad de documentación oficial, el soporte por parte de los desarrolladores, así como el principio fundamental de soberanía tecnológica que se defiende en Cuba, donde se prioriza el uso de herramientas y tecnologías libres o de código abierto. Como resultado de este análisis se definió utilizar como lenguajes de programación a Java 8.0, JavaFX 8 para el manejo de las interfaces e Hibernate ORM 5.0.2 como herramienta de correlación objeto-relacional. Como sistema gestor de la base de datos PostgreSQL 9.5, así como la herramienta PgAdmin III 1.20.0 para su administración. Además, se decidió utilizar el entorno de desarrollo NetBeans en su versión 8.0. Para la elaboración de los artefactos correspondientes al diseño, la implementación y el despliegue de la propuesta de solución se definió utilizar la herramienta Visual Paradigm 8.0, haciendo uso del lenguaje de modelado UML en su versión 2.0.
Según Clements (2003),la arquitectura de software de un sistema es la estructura o estructuras del sistema, lo cual abarca componentes de software, las propiedades visibles externamente de esos componentes, y las relaciones entre ellas. La arquitectura de software permite representar de forma concreta la estructura y funcionamiento interno de un sistema.
Al diseñar una arquitectura de software se debe crear y representar componentes que interactúen entre ellos y tengan asignadas tareas específicas, además de organizarlos de forma tal que se logren los requerimientos establecidos. Se puede iniciar con patrones de soluciones ya probados, y utilizar modelos que han funcionado. Estas soluciones probadas se conocen como estilos arquitectónicos o patrones arquitectónicos, que van de lo general a lo particular. Un criterio importante para el éxito de los patrones constituye el hecho de que cumplan los objetivos de la ingeniería de software (Buschmann, Meunier, Rohnert, Sommerlad & Stal, 2001).
Un patrón arquitectónico expresa un esquema de organización estructural esencial para un sistema de software, que consta de subsistemas, sus responsabilidades e interrelaciones a un alto nivel de abstracción. La propuesta de solución se construye a partir del patrón denominado Modelo Vista Controlador (MVC) el cual tiene la intención de particionar las aplicaciones interactivas en tres componentes independientes, tal como su nombre lo indica estos son: Modelo o Model, Vista o View, y Controlador o Controller (Pages Chacón&Martínez Prieto, 2008).
El primero de estos elementos representa el modelo de datos de la aplicación, la estructura de los mismos y la lógica de acceso a ellos. El segundo se refiere a la capa de presentación donde serán mostrados los datos de una o varias maneras con sus correspondientes comportamientos visuales, y a través de la cual se interactúa con la aplicación para acceder a la información. Por su parte, el último de estos elementos se encarga de contener y procesar la lógica que debe seguirse en la aplicación. Aquí se procesan los eventos manipulados por los usuarios, los cuales pueden desencadenar actualizaciones de los datos o una manipulación directa de estos en la vista. Controla la interacción entre la Vista y el Modelo y las secuencias de peticiones con sus respectivas respuestas.
Un actor es una entidad externa al sistema representada por un ser humano, una máquina o un software que interactúa con el sistema. Representa un tipo particular de usuario del negocio más que un usuario físico, debido a que varios usuarios físicos pueden realizar el mismo papel en relación al negocio (Schmuller, 2010). En la tabla 1 se muestran los actores del sistema y las funciones correspondientes a cada uno:
Tabla 1 Actores del Sistema.
| Actor | Descripción |
|---|---|
| Administrador | Es el súper usuario del sistema, con permisos para agregar, eliminar y asignar privilegios a los usuarios. Tiene acceso a todas las funcionalidades del sistema. |
| Usuario | Solo cuenta con los permisos de autenticación y descargar la documentación de una auditoría determinada. |
| Responsable | Puede realizar las auditorías, así como generar los reportes correspondientes a las mismas y graficar los resultados pertinentes. Puede realizar además las mismas funciones que el Usuario. |
| Responsable de Área | Es el encargado de solicitar una auditoría, archivar una auditoría y graficar un comportamiento histórico. Por su rol en el sistema puede realizar las mismas funciones del Responsable y las del Usuario. |
| Vicedecano | Es el encargado de obtener las estadísticas generales, además de poder realizar las mismas funciones que realiza el Responsable del Área, así como las del Responsable y el Usuario. |
El Diagrama de Casos de Uso del Sistema (DCUS), es el encargado de recoger el comportamiento de un sistema desde el punto de vista de los usuarios. Es utilizado para describir las especificidades de un software y documentar su comportamiento, mostrando la relación que existe entre el usuario final y las funcionalidades (Schmuller, 2010).
A continuación, se muestra mediante la figura 2 el DCUS de la solución propuesta.
El propósito del modelo de despliegue es capturar la configuración de los elementos de procesamiento y las conexiones entre estos elementos en el sistema. Permite el mapeo de procesos dentro de los nodos, asegurando la distribución del comportamiento a través de aquellos que son representados(Pressman, 2010). En la figura 3 se muestra una representación del diagrama de despliegue propuesto para el sistema y en la Tabla 2 la descripción de sus nodos.
Tabla 2 Descripción de los nodos correspondientes al diagrama de despliegue del sistema.
| Nodos | Descripción |
|---|---|
| Scanner de Barras | Nodo que representa el dispositivo que permite la fácil recepción y comparación de los rótulos en los AFT transmitiéndolos hacia la aplicación. |
| Estación de Trabajo Portátil | Nodo que representa la computadora o estación de trabajo donde será instalado el Sistema para la Informatización del Proceso de Auditoría y Control en la Facultad CITEC. |
| Servidor de Base de Datos | Nodo que representa el servidor donde se encuentra la Base de Datos que contiene los datos persistentes de la aplicación. |
| SGU | Sistema de Gestión Universitaria, aplicación web que almacena los datos de los AFT de acuerdo a las áreas de responsabilidad y centros de costo de la Facultad CITEC. |
La propuesta de solución, aunque está diseñada específicamente para la Facultad CITEC, puede ser desplegada en otros contextos siempre dentro de la UCI. Esta limitante se manifiesta a partir de la dependencia que tiene el sistema con el SGU, basado en el hecho de que, para poder realizar la auditoría de las diferentes áreas, debe antes consultar los datos de los AFT asignados a cada una de ellas. Dicha información, debido a requerimientos organizativos y legales que rigen el proceso de control interno en la UCI, se centraliza en el SGU, el cual, para posibilitar el acceso a la información, tiene implementado un servicio web, que brinda a la propuesta de solución la retroalimentación necesaria para mediante el consumo de este servicio, actualizar en línea su base de datos local y posteriormente poder utilizar estos datos sin conexión con el servidor del SGU.
De acuerdo a las características de las herramientas y tecnologías con las que se implementa la propuesta de solución, esta puede ser escalable y adaptada a otros contextos fuera de la UCI. Para ello bastaría con agregar un módulo para la gestión y asignación de los AFT, lo cual posibilitaría eliminar la dependencia del SGU como fuente de los datos, otorgando de esta forma al sistema la autonomía para desarrollar completamente el proceso de auditoría y control, utilizando la información de su base de datos local.
Las interfaces del sistema constituyen imágenes tomadas durante su funcionamiento. Estas imágenes muestran parte de los resultados obtenidos con el desarrollo de la investigación. A continuación, se muestra una vista o captura de pantalla referente al módulo de auditoría, en la misma se pueden apreciar diferentes campos que mostrarán la información asociada a cada AFT durante su control, una vez que el escáner de barras extrae la información se mostrarán entonces los datos asociados a al medio en cuestión. (Figura 4)
Con el fin de llevar a cabo la evaluación de la propuesta de solución actual, atendiendo a las características y objetivo del sistema, se seleccionó la aplicación de dos tipos de prueba correspondientes a las pruebas a nivel de componentes.
Las pruebas a nivel de componentes, también llamadas pruebas de función, se enfocan sobre un conjunto de pruebas que intentan descubrir errores en la aplicación. Cada función es un módulo de software el cual se determina probar empleando el método de prueba de Caja Negra.
Las pruebas de Caja Negra se centran en los Requisitos Funcionales (RF) del software, que son los que definen las funciones que el sistema será capaz de realizar y describen las transformaciones que el sistema realiza sobre las entradas para producir determinadas salidas. Este tipo de pruebas se emplean cuando se conoce la función específica para la que se diseñó el producto; se aplican a la interfaz del software intentando demostrar que cada función es plenamente operacional, mientras se buscan los errores de cada función.
El mencionado método utiliza además técnicas para su realización, en la presente investigación se determina el uso de la técnica de Partición Equivalente, la que divide el dominio de entrada de un programa en clases de datos a partir de las cuales pueden derivarse casos de prueba. Un Caso de Prueba representa una forma de probar el sistema, incluyendo la entrada o resultado con la que se ha de probar y las condiciones bajo las que ha de probarse.
Por otra parte, las pruebas de aceptación, son llevadas a cabo por el cliente, básicamente constituyen pruebas funcionales, sobre el sistema completo, y buscan una cobertura de la especificación de requisitos. Estas pruebas no se realizan durante el desarrollo, pues sería impresentable al cliente; sino que se realizan sobre el producto terminado e integrado o pudiera ser una versión del producto o una iteración funcional pactada previamente con el cliente. Las interfaces del sistema constituyen imágenes tomadas durante su funcionamiento. Estas imágenes muestran parte de los resultados
La aplicación desarrollada fue sometida a un proceso de aceptación por parte del Vicedecanato de Economía y Administración. Durante este proceso el colectivo del vicedecanato, ha reconocido que:
La solución propuesta posee una interfaz agradable acorde a la identidad marcaria planteada por la UCI, resultando en botones y menús de fácil acceso. Puede ser operada con facilidad por personal con una cultura informática elemental, mostrando un alto grado de usabilidad.
El funcionamiento de la aplicación es estable y consistente, con tiempos de respuesta no mayores a los 3 segundos para ninguna de sus operaciones.
Facilita de manera sustancial el proceso de testeo de los AFT en cada una de las áreas auditadas, permitiendo agilidad en el proceso y confiabilidad en el resultado de las inspecciones.
Permite la rápida obtención de informes y gráficos que ofrecen de manera interactiva y útil el resultado de las auditorías, resultando en recursos valiosos para la toma de decisiones y representando herramienta eficaz ante el control de los medios.
Como parte de la ejecución de las pruebas de Caja Negra, con el objetivo esencial de identificar en qué medida satisface la aplicación las funcionalidades implementadas, se realizó una primera iteración de pruebas, en la que fueron aplicados los diseños de casos de pruebas realizados a partir de las descripciones textuales de los Casos de Uso del Sistema. En esta primera iteración se identificaron un total de 7 no conformidades, que una vez corregidas, se ejecutaron nuevamente los diseños elaborados obteniéndose un total de tres no conformidades, correspondientes a los Casos de Uso “Realizar Auditoría” y “Gestionar Usuario”. Luego de corregidas estas últimas no conformidades se decide la realización de una tercera iteración de los diseños anteriormente aplicados obteniéndose resultados satisfactorios, por lo que se determina la no realización de una nueva iteración.
Las no conformidades detectadas estuvieron relacionadas con el funcionamiento de las interfaces del usuario. Generalmente asociadas a mensajes de información no personalizados o respuestas no deseadas para los valores de entrada definidos. La realización de las pruebas permitió identificar los errores que no habían sido detectados hasta el momento.
Conclusiones
El estado del arte referido informatización del proceso de auditoría y control permite afirmar que las soluciones que existen, que de alguna manera tributan a la investigación, no resuelven la problemática planteada, evidenciándose la necesidad de esta investigación.
Las herramientas, tecnologías y lenguajes propuestos para la construcción del sistema, se corresponden con las políticas de soberanía tecnológica que impulsa la UCI y el país. La característica de ser una solución multiplataforma amplía las posibilidades de utilización y la gama de usuarios que puede utilizarla.
Todos los RF que se definieron fueron debidamente implementados, igualmente, se incluyeron en la propuesta las exigencias de todos los Requisitos No Funcionales detectados. Los artefactos generados durante el proceso de desarrollo del software permitirán escalar la solución en el futuro y facilitar las labores de mantenimiento y soporte.
La utilización de estilos y patrones promueve buenas prácticas en el desarrollo de la solución al proporcionar uniformidad en la implementación, siendo más entendible y escalable en el tiempo. Los Diseños de Casos de Prueba desarrollados, como parte de las pruebas de Caja Negra, permitieron validar los requisitos de la aplicación con las funcionalidades implementadas.
La utilización de la herramienta aportará agilidad al proceso de auditoría y control de los activos fijos tangibles en la Facultad CITEC de la Universidad de las Ciencias Informáticas.
