SciELO - Scientific Electronic Library Online

 
vol.11 número1Interculturalidad: contribuciones y propuestas desde un enfoque interdisciplinario en el Instituto de Ciencias Sociales y Humanísticas de la Universidad Autónoma del Estado HidalgoConstructo teórico en el estudio del turismo comunitario en la provincia de Namibe, Angola índice de autoresíndice de materiabúsqueda de artículos
Home Pagelista alfabética de revistas  

Servicios Personalizados

Articulo

Indicadores

  • No hay articulos citadosCitado por SciELO

Links relacionados

  • No hay articulos similaresSimilares en SciELO

Compartir


Revista Universidad y Sociedad

versión On-line ISSN 2218-3620

Universidad y Sociedad vol.11 no.1 Cienfuegos ene.-mar. 2019  Epub 02-Mar-2019

 

Articulo Original

Sistema para la auditoría y control de los activos fijos tangibles

System for the audit and control of tangible fixed assets

0000-0001-8259-8904Bernardo Hernández González1  *  , 0000-0001-6250-5686Tania Ramírez Ramírez1  , 0000-0002-0689-6341Omar Mar Cornelio1 

1 Universidad de las Ciencias Informáticas. La Habana. Cuba. E-mail: tramirez@uci.cu, omarmar@uci.cu

RESUMEN

Como parte de las normas del sistema de control interno cubano, se establece que el 10% de los activos fijos tangibles sean auditados mensualmente, representando tarea medular dentro de cualquier entidad. En la Facultad de Ciencias y Tecnologías Computacionales de la Universidad de las Ciencias Informáticas, se realiza a través del testeo manual de los medios contra un inventario previamente impreso, lo que genera un proceso engorroso e ineficiente. La investigación que a continuación se presenta consiste en el análisis, diseño, implementación y evaluación de una aplicación informática encaminada a agilizar el proceso de Auditoría y Control de los Activos Fijos Tangibles. El desarrollo del sistema se encuentra marcado por el empleo de tecnologías y herramientas de actualidad apegadas a la política de soberanía tecnológica que impulsa el país. La solución obtenida mejora el empleo de los recursos humanos y materiales, permitiendo obtener resultados de manera rápida y fiable a partir de la realización del proceso de auditoría y control.

Palabras-clave: Activo fijo tangible; aplicación informática; auditoría y control

ABSTRACT

As part of the rules of the Cuban internal control system, it is established that 10% of fixed tangible assets be audited monthly, representing a core task within any entity. In the School of Sciences and Computational Technologies of the University of the Computer Science, it is done through the manual testing of the resources with a previously printed inventory, which generates a cumbersome and inefficient process. The research that follows is the analysis, design, implementation and evaluation of a computer application aimed at streamlining the process of Auditing and Control of Fixed Tangible. The development of the system is marked by the use of current technologies and tools attached to the policy of technological sovereignty that drives the country. The solution obtained improves the use of human and material resources, allowing results to be obtained quickly and reliably from the completion of the audit and control process.

Key words: Tangible fixed assets; computer application; audit and control

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:

Fig. 1 Propuesta de solución. 

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.

Fig. 2 Diagrama de Casos de Uso del Sistema. 

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.

Fig. 3 Representación del diagrama de despliegue del sistema. 

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)

Fig. 4 Interfaz del Sistema. 

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.

Referencias bibliográficas

Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P. y Stal, M. (2001).Pattern-Oriented Software Architecture. A System of Patterns. New York: John Wiley and Sons. [ Links ]

Balderas, M. (2013) Administración y control interno de activo fijo. Veracruz: Universidad Veracruzana. [ Links ]

Cuba. Contraloría General de la República. (2009).Reglamento de la Ley No. 107/09.Recuperado de http://www.contraloria.gob.cu/documentos/Reglamento%20de%20la%20Ley%20107.pdfLinks ]

López Clemente, A., Hurtado Beltrán, D., & Jiménez González, N. (2012) Propuesta de acciones para solucionar las deficiencias en cuanto al control de los activos fijos tangibles en Cuba. Filial Universitária de Salud Município de Yaguajay. Recuperado de http://www.eumed.net/cursecon/ecolat/cu/2012/cbg.pdfLinks ]

Mar, O., Bron, B., & González, Y. (2016). Sistema para la auditoría y control de los Activos Fijos. Serie Científica, 9(6). Recuperado de https://publicaciones.uci.cu/?journal=SC&page=article&op=view&path%5B%5D=1781 Links ]

Clements, L., Bassan, L., & Kazzman, R. (2003). Software Architecture in Practice. Reading: Adison Wesley. [ Links ]

Pages Chacón, D., & Martínez Prieto, J. P. 2008). Principales variantes tecnológicas del entorno Java para el desarrollo de aplicaciones en la capa cliente. XIX Conferencia Científica de Ingeniería. Recuperado de http://ccia.cujae.edu.cu/index.php/siia/siia2008/paper/view/1246/305 Links ]

Pressman, R. (2010). Ingeniería del software Un enfoque práctico. México: Mc Graw Hill. [ Links ]

Schmuller, J. (2010). Aprendiendo UML en 24 horas. México: Pearson Education Latinoamérica. [ Links ]

Received: September 20, 2018; Accepted: December 23, 2018

*Autor para correspondencia. E-mail: bhernandez@uci.cu

Creative Commons License