Implementación de una aplicación web para el análisis del riesgo de liquidez en cooperativas=

<= i>Implementation of = a web application for the analysis of liquidity risk in cooperatives

¹⁼	Wellington Francisco Cabezas Lucio	https://= orcid.org/0009-0000-5210-3042
	Escuela Superior Politécnica = de Chimborazo (ESPOCH) wellingtoncabezaslucio@= gmail.co m=
²⁼	Jhonnathan Rafael Castillo Quiroz https://= orcid.org/0009-0002-5878-5755 Escuela Superior Politécnica de Chimborazo (ESPOCH) jhoncastilloq88@gmail= .com
³	Ligia Maricela Niama Rivera https= ://orcid.org/0000-0002-1818-0041 Escuela Superior Politécnica = de Chimborazo (ESPOCH) ligia.niama@espoch.edu.ec <= o:p>
⁴	Miguel Angel Duque Vaca ht= tps://orcid.org/0000-0001-9442-2420 Escuela Superior Politécnica = de Chimborazo (ESPOCH) m_duque@espoch.edu.ec

<= span style=3D'font-size:12.0pt;line-height:115%;mso-ansi-language:ES-EC'>

=

=	Artículo de Investigación Científica y Tecnológica Enviado: 15/05/2024 Revisado: 14/06/2024 Aceptado: 31/07/2024 Publicado:09/08/2024 DOI: https://doi.org/10.33262/ap.v6i3.1.514<= /span> <= /b> = <= span style=3D'mso-spacerun:yes'> <= span style=3D'mso-spacerun:yes'> =
<= span style=3D'font-size:12.0pt;line-height:115%;mso-fareast-font-family:Calibr= i; color:blue;mso-ansi-language:ES-EC'>
Cítese: =		&nbs= p; Cabezas Lucio, W. F., Castillo Quiroz, J. R., Niama Rivera, L. M., & Duque Va= ca, M. A. (2024). Implementación de una aplicación web para el análisis del riesgo de liquidez en cooperativas. AlfaPublicaciones, 6(3.1), 6–33. https://doi.org/10.33262/= ap.v6i3.1.514 =
		ALFA PUBLICACIONES, es una revis= ta multidisciplinar, trimestral, que se publicará en soporte electrón= ico tiene como misión contribuir a la formación de profesionales competentes con visión humanística y crítica que sean capac= es de exponer sus resultados investigativos y científicos en la misma medida= que se promueva mediante su intervención cambios positivos en la sociedad.&nb= sp;https://alfapublicaciones.com La revista es editada por la Editorial Ciencia Digital (Editorial de prestigio registrada en la Cámara Ecuatoria= na de Libro con No de Afiliación 663) www.celibro.org.ec
		Esta revista está protegida bajo una licencia Creative Commons Attribution Non Commercial No Derivatives 4.0 International. Copia de la licencia: http://creativecommons.org/license= s/by-nc-nd/4.0/
Palabras claves: software, sistemas informáticos, riesgo de liquidez.	=	Resumen Introducción: <= span style=3D'font-size:12.0pt;line-height:115%;mso-fareast-font-family:Calibr= i; mso-ansi-language:ES-EC;font-weight:normal;mso-bidi-font-weight:bold'>Las cooperativas de ahorro y crédito desempeńan un papel crucial al atender l= as necesidades financieras de sus socios y otros individuos, especialmente aquellos que tradicionalmente han estado excluidos del sistema financiero convencional. Objetivos: La presente investigación tiene como objetivo la implementación de una aplicación web para el análisis del riesgo de liquidez de las cooperativa= s. La investigación es de tipo aplicativo, ya que el proyecto incorporará un conjunto de características proporcionan el uso de herramientas tecnológi= cas con el fin de resolver los problemas para el análisis de los índices de riesgo de liquidez. Metodología: Además, se decidió emplear la metodología de desarrollo XP junto con sus práctica= s, siguiendo el proceso estipulado. Para la etapa de desarrollo se implement= ó el uso de iteraciones con la finalidad de realizar un seguimiento del proyec= to. Al finalizar el desarrollo, se procede a la incorporación y análisis de la usabilidad, centrado en los indicadores de aprendizabilidad, accesibilida= d, operabilidad y reconocibilidad de la adecuación, a través de una encuesta como herramienta del método empírico y una herramienta de software para el análisis del método heurís= tico. Resultados: Como resultado, se determina = que la usabilidad de la aplicación es alta en comparación a la media de los indicadores mencionados anteriormente con un 77,97% determinando como bue= no. Conclusiones: <= span style=3D'font-size:12.0pt;line-height:115%;mso-fareast-font-family:Calibr= i; mso-ansi-language:ES-EC;font-weight:normal'>Se consiguió la implementació= n de la aplicación web para el análisis de riesgos de liquidez con el objeto de agilitar los procesos de toma de decisiones en cooperativas ya que este índice que representa la toma de decisiones asertivas en cada institución financiera. Área de estudio general: Tecnología de la Información aplicado a Finanzas. Área de estudio específica: Software. Tipo de estudio: articulo original.
Keywords: software, computer systems, liquidity risk.		= Abstract Introduction: Credit unions play a crucial role in serving the financial needs of their members and other individual= s, especially those who have traditionally been excluded from the convention= al financial system. Objective= s: The objective of this research is the implementation of a web application for the analysis of the liquidity ris= k of cooperatives. The research is of an application type, since the project w= ill incorporate a set of characteristics that provide the use of technological tools to solve the problems for the analysis of liquidity risk indices. <= /span>Methodology: In addition, it was decided to use the XP development methodology together with its practices, following the stipulated process. For the development stage, the use of iterations was implemented to monit= or the project. At the end of the development, the incorporation and analysi= s of usability is carried out, focusing on the indicators of learnability, accessibility, operability and recognizability of adequacy, through a sur= vey as a tool of the empirical method and a software tool for the analysis of= the heuristic method. Results: = As a result, it is determined that the usabil= ity of the application is high compared to the average of the indicators mentioned above with 77.97% determining it as good. Conclusions: The implementation of the web application for the analysis of liquidity risks was achieved to streamline the decision-making processes in cooperatives since this index represents assertive decision-making in each financial institution. General area of study: Information Technology applied to Finance. Specific area of study: Software. Type of study: original, applicative, descriptive.

<= /span>

Introdu= cción

Las cooperativas de ahorro y crédito desempeńan un papel crucial al atender las necesidades financieras de sus socios y otros individuos, especialmente aquellos que tradicionalmente han estado excluidos del sistema financiero convencional. Más allá de su función económica, estas entidades actúan como agentes de cambio social, fomentando el dinamismo económico y promoviendo un impacto social positivo.

Dentro = de las cooperativas de ahorro y crédito, el área de análisis de gestión de riesgos= se identifica como una de las más esenciales, encargándose del cálculo y evaluación de los riesgos inherentes a la institución. En este contexto, el análisis de liqui= dez emerge como un elemento crítico, permitiendo identificar y anticipar posibl= es desafíos financieros, como la imposibilidad de cumplir con obligaciones externas, pagos a socios, adquisición de activos, entre otros aspectos relevantes.

A pesar= de los avances en soluciones de software que buscan facilitar la manipulación y presentación de datos, muchas de estas herramientas carecen de un enfoque centrado en la mantenibilidad y la experiencia del usuario. Por lo tanto, se presenta la necesidad de desarrollar herramientas más adaptadas a las necesidades específicas de estas instituciones.

En este contexto, el objetivo principal de este artículo científico es proponer e implementar una aplicación web dedicada al análisis del riesgo de liquidez = en cooperativas, buscando mejorar la precisión, eficiencia y accesibilidad en = el manejo de la información de los indicadores financieros facilitando una tom= a de decisiones adecuadas.

Marco Teórico

Conceptos Contables

La contabilidad se define como un sistema de información que genera reportes p= ara los usuarios acerca de las actividades económicas y las condiciones de un negocio (Warren et al., 2016, p. 10). Compr= ender con los conceptos principales de la contabilidad permite forjar una comunic= ación estable entre el stackholder y los desarrolladores, po= r lo cual a continuación se definen dichos conceptos.

·&nb= sp; Estado de situación financiera o balance gene= ral

Este in= forme, que también se conoce como balance general, presenta información útil para = la toma de decisiones en cuanto a la inversión y el financiamiento. En él se muestra el monto del activo, pasivo y capital contable en una fecha específ= ica, es decir, se presentan los recursos con que cuenta la empresa (Guajar= do & Andrade, 2008, p. 151).

De este estado surge la información para realizar los cálculos de los índices finan= cieros que a continuación detallaremos.

·&nb= sp; Definición de activos

Los act= ivos, que son los recursos que posee la entidad de negocios, pueden ser partidas físicas, como el efectivo y las provisiones, o intangibles que tienen un va= lor. Algunos ejemplos de activos intangibles son los derechos de patente, los derechos de autor y las marcas registradas (Warren et al., 2016, p. 52).<= /o:p>

·&nb= sp; Definición de activos circulantes o corriente= s

El Acti= vo corriente comprende aquellos activos que la empresa espera vender, consumir= o realizar en un periodo no superior a un ańo; aquellos cuyo vencimiento, enajenación o realización se espera que se produzcan en un corto plazo; los activos financieros clasificados como mantenidos para negociar y el efectiv= o y otros activos líquidos equivalentes (Muńoz,= 2008, p. 37).<= /o:p>

&n= bsp;

·&nb= sp; Pasivos

Los pas= ivos, que son deudas con personas externas al negocio (acreedores), se identifica= n en el balance general con nombres que incluyen la denominación por pagar. Algu= nos ejemplos de pasivos son las cuentas por pagar, los documentos por pagar y l= os sueldos por pagar (Warren et al., 2016, p. 52).<= /o:p>

·&nb= sp; Pasivos circulantes o corrientes

Compren= de aquellas obligaciones que la empresa espera liquidar en el transcurso del c= iclo normal de explotación, el cual no excederá de 12 meses, o cuyo vencimiento o extinción se espera que se produzca en el corto plazo, contado a partir de = la fecha de cierre del ejercicio, así como los pasivos financieros incluidos e= n la cartera de negociación (Muńoz,= 2008, p. 40).<= /o:p>

·&nb= sp; Liquidez

Definid= a como la capacidad financiera de una empresa para generar flujos de fondos y así responder con sus compromisos en el corto plazo, tanto operativos como financieros. El problema inmediato que debe resolver el administrador geren= te o análisis financiero es la deficiencia o exceso de liquidez (Baena,= 2010, p. 12).<= /o:p>

La fórm= ula general que se utiliza para el cálculo de la liquidez se encuentra en la siguiente ecuación (1).

Liquidez Corriente =3D (Activos circulantes) / (Pasivos circulantes) (1)

·&nb= sp; Liquidez Estructural

La metodología de liquidez estructural permite determinar a partir de la estructura del balance, la proporción de los activos líquidos de disponibil= idad inmediata que cubren los pasivos exigibles de la entidad (Superi= ntendencia de Economía Popular y Solidaria [SEPS], 2019). En la figura 1, se puede evidenciar como se distribuye la liquidez estructural dentro de una cooperativa.

Figura 1

Clasificación de la liquidez estructural

Fuente: Sem= antic Scholar (2013)

·&nb= sp; Riesgo de Liquidez

El ries= go de liquidez se refiere a la situación en la que un banco no puede financiar el crecimiento de sus activos y cumplir con las obligaciones de efectivo y garantías previstas y no previstas, todo ello a un costo razonable y sin su= frir pérdidas inaceptables, sin que esto afecte negativamente su situación financiera (Kumar = & Chad, 2013,= p. 1).

A. Superin= tendencia de Economía Popular y Solidaria

La Superintendencia de Economía Popular y Solidaria (SEPS, 2024), es el organi= smo técnico de supervisión y control de las entidades del sector Financiero Pop= ular y Solidario, y de las organizaciones de la Economía Popular y Solidaria del Ecuador que, en el ámbito de su competencia, promueve su sostenibilidad y correcto funcionamiento para proteger a sus socios.

La SEPS proporciona un desglose detallado de las fórmulas que se debe aplicar para obtener el resultado para cada índice de liquidez que las cooperativas deben controlar.

Metodología de desarrollo extreme programming

La programación extrema o extreme programming es una metodología de desarrollo de ingeniería de software formulada por Kent Beck, autor del primer libro sobre el tema Explicación de la Programación Extrema: Abrazando el Cambio. XP es una metodología ligera para equipos pequeńos y medianos que desarrollan software ante requisitos poco precisos o que cambi= an con rapidez (Beck &= amp; Andrés, 2005, p. 3)

La programación extrema se diferencia de las metodologías clásicas principalme= nte en el nivel de énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP creen que cambiar los requisitos sobre la marcha es un asp= ecto natural, inevitable e incluso deseable del desarrollo del proyecto. Para visualizar de forma más clara en la Fig. 2 se especifican los pasos que conlleva la Metodología XP.

Figura 2

Fases de la Metodología XP

<= v:shape id=3D"Imagen_x0020_11" o:spid=3D"_x0000_i1036" type=3D"#_x0000_t75" style= =3D'width:357.75pt; height:156pt;visibility:visible;mso-wrap-style:square'>

Fuente: Semantic Scholar (2013)=

Migración de datos

La migración de datos es “el proceso de trasladar datos de un sistema de orige= n a un sistema de destino, mientras se preserva la integridad, la consistencia = y la calidad de los datos, y se minimizan los riesgos y los costos asociados con= la transferencia de datos” (Morris, 2012, p. 1)

Morris enfatiza la importancia de definir cuidadosamente la migración de datos y de seguir un proceso estructurado para garantizar que los datos se transfieran= de manera segura. Además, destaca que la migración de datos a menudo involucra múltiples etapas, que puede ser un proceso complejo y desafiante que requie= re una gestión rigurosa y una atención cuidadosa a los detalles.

·&nb= sp; Extracción, Transformación y Carga= (ETL)<= o:p>

ETL es = la recopilación y agregación de datos transaccionales, como se muestra en la Figura 1.4, con datos extraídos de múltiples fuentes para conformarlos en b= ases de datos utilizadas para informes y análisis (Giorda= no, 2011, p. 14). La fi= gura a la que hace referencia el autor se encuentra en la figura 3.

Figura 3

Patrón arquitectónico de integración de datos ETL<= /i>

Fuente: Semantic Scholar (2013)=

El objetivo principal del proceso ETL es extraer un conjunto de datos sin impo= rtar la fuente de donde se desee obtener, seguidamente se transformará dicha inf= ormación según las necesidades del stackholder y fina= lmente se cargará los nuevos datos al respectivo destino.

Normas ISO/IEC 25000

La norma ISO/IEC 25000 también conocida como Systems= and software Quality Requirements and Evaluation (SQuaRE) es un conglomerado de estándares enfocado en la medición y evaluación de la calid= ad de un sistema o un producto software.

El objetivo general de la creación del conjunto de Normas Internacionales SQua= RE era pasar a una serie lógicamente organizada, enriquecida y unificada que cubriera dos procesos principales: la especificación de los requisitos de calidad del software y la evaluación de la calidad de los sistemas y del software, con el apoyo de un proceso de medición de la calidad de los siste= mas y del software (Semantic Scholar, 2013,= p. 5).

Con el propósito de mejorar la organización, la serie SQuaRE presenta una estru= ctura clasificatoria general, que se visualiza en la figura 4.<= /p>
&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

Figura 4

Organization of SQuaRE Series of Standards

Fuente: Sem= antic Scholar (2013)

    1) Usabili= dad

Capacidad del producto software para ser entendido, aprendido, usado y resultar atrac= tivo para el usuario, cuando se usa bajo determinadas condiciones (Semant= ic Scholar, 2013, p. 1-3). =

La usabilidad es importante porque ayuda a asegurar que los usuarios puedan realizar tareas de manera eficiente y sin problemas, lo que puede mejorar la satisfacción del usuario y aumentar la probabilidad de que vuelvan a utiliz= ar el producto o sistema.

Metodología

El diseńo de la investigación está íntimamente relacionado con los métodos y técnicas debido a que facilita la esquematización de parámetros necesarios = con el fin de realizar procesos eficientes y cumplir con los objetivos del proyecto.

Se recopila información distribuida por la SEPS en donde se opta por documentos que estén relacionados con los riesgos de liquidez con el fin de comprender cuales son los principales índices que la superintendencia necesita. Otra fuente de información son las cooperativas debido a que ellos poseen docume= ntos en donde se detalla paso a paso cual es el proceso de obtención de los índi= ces de liquidez.

Consiste en un enfoque de estudio centrado en el análisis detallado de los procesos = de obtención de los índices de liquidez, descomponiendo cada paso hasta llegar= a una mínima expresión con el fin de obtener los conocimientos necesarios para una correcta implementación en el producto final.

Se recurre al método inductivo como una lógica que permite establecer principi= os generales a partir de la observación y el análisis detallado de casos particulares para la obtención de conclusiones amplias y generalizadas.

Se utilizó las revisiones para examinar y sintetizar fuentes bibliográficas co= mo libros, revistas, artículos relevantes con respecto a los riesgos de liquid= ez, permitiendo contextualizar y fundamentar teóricamente partiendo de las principales definiciones de contabilidad hasta la importancia de los índice= s de liquidez dentro de las cooperativas y los riesgos que se pueden generar.

Se realizó entrevistas al personal administrativo a cargo del área de riesgos = con el objetivo de extraer los requisitos funcionales para el desarrollo de la aplicación web. =

Se real= izo la encuesta con la finalidad de obtener las directrices y elementos necesarios para obtener una aplicación web usable.

Dentro de la determinación de la usabilidad se especifica cuáles son los indicador= es de la usabilidad a evaluar del proyecto tomando como referencia la norma ISO/IEC 25010 como se visualiza en la tabla 1.

Tabla 1

Indicadores de usabilidad

Variable

Indicadores

= Usabilidad

= Aprendizabilidad

= Accesibilidad

= Operabilidad

= Reconocibilidad de la adecuación

Métodos de evaluación de Usabilidad

El propósito principal de evaluar la usabilidad es detectar áreas de mejora en= el diseńo y el rendimiento del producto, lo que permite hacer ajustes y optimizaciones para proporcionar una experiencia de usuario más satisfactor= ia. Para analizar la usabilidad, se utilizaron dos herramientas encuesta y una herramienta web.

Las preguntas de la encuesta para medir la usabilidad se tomaron del = CSUQ (Computer System Usability Questionnarie). La evaluación de la aplicación se realizó utilizando una escala de Likert con un rango de 1 a 5, donde 1 representa "totalmente en desacuerdo", 2 "en desacuerdo", 3 "neutral", 4 "de acuerdo" y 5 "totalmente de acuerdo".

Para medir la Accesibilidad de la aplicación se empleó la herramienta web Accessibility Insights for Web herramienta que ayuda a verificar que una web cum= pla con los estándares de accesibilidad al contenido web (WCAG) 2.1 Nivel AA (Micros= oft, 2024).<= /o:p>

Poblaci= ón y muestra de estudio

Las fuentes principales para la evaluación del nivel de usabilidad de la aplica= ción web son 7 personas que conforman la parte administrativa de una cooperativa seleccionada al azar, de ellos obtendremos toda información relacionada con= su experiencia y perspectivas del software implementado.

Desarro= llo de la aplicación Risk Assistant utilizando XP

Planificación

Se llevó a cabo entrevistas presenciales entre los programadores y el personal= de la cooperativa en cuestión para identificar sus necesidades. Durante una de= las reuniones, se destacó la importancia de controlar y manipular los índices de liquidez, ya que han surgido problemas al incorporar nuevos índices debido = a la falta de flexibilidad del sistema. Además, el área de riesgos solicitó la capacidad de generar reportes actualizados en cualquier momento, evitando largas esperas para obtener ayuda del proveedor. También se enfatizó la necesidad de compartir los reportes de índices de liquidez con otros departamentos para que puedan estar informados sobre los resultados y tomar decisiones oportunas.

Para ello se realizaron los siguientes pasos, en primera instancia se creó histo= rias de usuario para poder plasmar en primera instancia el detalle del requerimi= ento, qué prioridad tiene, cuál va a ser el riesgo que esta historia va a tener además de un flujo principal como de uno alterno.

Seguidamente se creó un backlog el cual va condensando todas las historias de usuario pa= ra crear un cronograma aproximado de fecha las cuales se van a ir cumpliendo e= n cada una de las actividades.

Análisis

Análisis de riesgos

El análisis de riesgo es un proceso sistemático sobre el cual se identifican y analizan los riesgos del producto, con la finalidad de maximizar las consecuencias positivas y reducir las probabilidades de riesgos.=

Identificación de riesgos
Para la identificación de los riesgos en los diferentes de procesos se empleó la métrica versión 3 explicada Fernández (2011), los cuales se pueden evidenci= ar en la tabla 2 (p. 35)= .

Tabla 2

Identificación de riesgos

Identificador<= /o:p>

Descrip= ción

Proceso

Consecu= encia

R01

Incorrecta planificación del proceso

Planifi= cación de sistemas de información.

Entrega atrasada del producto.

Aumento de las pérdidas para la entidad financiera

R02

Mala estructuración de actividades

Planifi= cación de sistemas de información.

Mala coordinación de actividad

Retraso en el cronograma

R03

Mal diseńo de la base de datos

Desarro= llo de sistemas de información.

Complicación en la manipulación de datos= .

Imposibilidad de escalamiento

R04

Falta de comprensión en los requisitos software=

Planifi= cación de sistemas de información.

El producto final puede no cumplir con l= as expectativas del cliente o los usuarios.

R05

Falta de visión para elegir las herramie= ntas de desarrollo

Planifi= cación de sistemas de información.

Demora de tiempo en la etapa de desarrol= lo.

Análisis de riesgos

Una vez que se han identificado los riesgos es necesario ordenarlos en función = de su importancia relativa. A fin de efectuar el ordenamiento, primero se deben cuantificar los riesgos para ello se empleará el método de Delphi con ayuda= del equipo de desarrollo, el tutor académico y el stackholder (Rivaro= la & Lledó, 2007, p. 114).<= /o:p>

A través de este método obtenemos el análisis de riesgos esquematizado en la = tabla 3.

Tabla 3

Análisis de riesgos

Rango de Probabilidad de incidencia

Grado de afectación

Descripción

Valor

1-33

Bajo

1

Tabla 3

Análisis de riesgos (continuación)=

Rango de Probabilidad de incidencia

Grado de afectación

Descripción

Valor

34-40

Medio

2

40-100

Alto

3

Determinación de impacto
Al identificar el impacto, se busca comprender la magnitud de las consecuencias potenciales y su alcance, lo que permite tomar decisiones informadas sobre = cómo gestionar y mitigar esos riesgos. La esquematización de estos resultados se denota en la tabla 4, obtenida a través del método Delphi.

Tabla 4

Categorización de riesgos según el impacto

Retraso (semana)

Grado de afectación

Nivel

Definición técnica

1 semanas

Bajo

Retraso menor

2 semanas

Medio

Retraso moderado

3 semanas

Alto

Retraso severe

1 mes o superior

Critico

Suspensión del proyecto

Determinación de matriz de riesgos=

Para determinar el nivel real a fallar del proyecto, según cada uno de los riesg= os, se realiza una interpolación entre ambos aspectos relevantes para el éxito = de este. Consiste en clasificar y designar un rol especifico según el aspecto = de tiempo y el impacto que forman cada riesgo. Obteniendo como resultado tabla= 5.

Tabla 5

Matriz de riesgos

Retraso Incidencia

Bajo

Medio

Alto=

Critico

Bajo

Pequeńo

Moderado<= /p>

Medio

Elevado

Medio

Bajo

Medio

Medio

Elevado

Alto

Moderado

Elevado

Elevado

Elevado

Determinación de prioridad del riesgo

La determinación de la prioridad del riesgo es un proceso que tiene como objet= ivo asignar niveles de importancia o urgencia a los riesgos identificados en un proyecto, en la tabla 6 propone un resumen de las prioridades.

Tabla 6

Prioridad de riesgos

Identif= icador

Descrip= ción

Exposic= ión

Inciden= cia

Retraso=

Priorid= ad

R01

Incorre= cta planificación del proceso<= o:p>

Medio

Medio

Medio

R02

Mala estructuración de actividades

Alto

Bajo

Moderad= o

R03

Mal dis= eńo de la base de datos

Medio

Medio

Medio

R04

Falta de comprensión en los requisitos software

Bajo

Medio

Pequeńo

R05

Falta de visión para elegir las herramientas de desarrollo

Medio

Bajo

Bajo

Estudio de factibilidad

El estudio de factibilidad descri= be el análisis de los recursos económicos y técnicos que son necesarias para llevar a cabo una inversión, la cual se realiza con un objetivo previamente establecido, limitado por parámetros temporales, tecnológicos, políticos, institucionales, ambientales y económicos.

Factibilidad económica

La cooperativa proporciona su hardware para realizar el despliegue del proyecto por tal razón no se incur= rirá en gastos con costos elevados, a continuación, se presenta una tabla con el presupuesto necesario para este proyecto.

Estimación de costos del proyecto =

Los costos del desarr= ollo del producto software está condicionado por la utilización de los recursos software, hardware y recursos humanos empleados en el desarrollo de la aplicación web. En la tabla se describe los costos unitarios y el valor tot= al de los recursos necesarios para desarrollo de la aplicación web.

Costos de materia prima

Para el desarrollo de este proyecto no se requiere de gastos en la materia prima. Debido a que los entornos de desarrollo que se emplean son gratuitos, así como las demás herramientas software.

Costos operativos
L= os costos operativos están distribuidos entre el personal de un proyecto, para este caso en específico se establecerá para los dos estudiantes que están desarrollando este proyecto de titulación, revisar la tabla 7.

Tabla 7=

Costos operativos

Recurso Humano=

Numero de meses

Sueldo por mes=

Sueldo total

Wellington Francisco Cabezas Lucio

5

$ 450

$ 2250

Jhonnathan Rafael Castillo Quiroz<= /o:p>

5

$ 450

$ 2250

Total

$ 4500

Costos indirectos de fabricación

L= os costos indirectos de fabricación son los elementos utilizados que no afectan directamente relacionados con el desarrollo del producto, pero es una parte complementaria, en la tabla 8 se detallan los costos indirectos para el proyecto de titulación.

Tabla 8=

Costos indirectos de fabricación

Recurso

Tiempo de trabajo (Meses)

Deprecación por mes

Valor Total

Hp Notebook Pavilon

5

$ 17

$ 85

Dell Precision 7510

5

$ 10.833

$ 54.16

Servidor HP

5

$ 33.33

$ 166.65

Total

$ 305.81

Diseńo y codificación<= /span>

Estándares de codificación<= /span>

Los estándares de codificación se refieren a directrices y normas que se establecen para la creación de códig= o en un lenguaje de programación determinado. Su principal propósito es mejorar = la claridad, facilidad de mantenimiento y eficiencia del código, lo cual fomen= ta una mejor comprensión y colaboración entre los desarrolladores. En la tabla= 9 se especifican los estándares que están dentro del proyecto.=

Tabla 9=

Costos indirectos de fabricación

Elemento

Estándar de codificación

Ejemplo

Clases

Pascal Case

Usuario

Métodos y funciones

Pascal Case

UsuarioRegistrado

Atributos y variables=

Snake Case

calcular_salario

Patrón de diseńo del proyecto

El sistema se basa en el patrón M= VC en el cual la aplicación web funciona como la vista, la lógica del negocio conforma la sección de controladores y el modelo está representado por la A= PI para interactuar con la base de datos, lo que permite su despliegue en una amplia variedad de procesos y garantiza su escalabilidad y rendimiento. En = la figura 5 se establece el diagrama de despliegue que tendrá el proyecto.

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

Figura = 5

Diagram= a de despliegue

Fuente: Semantic Scholar (2013)

Pruebas

La fase de testing o pruebas es un proceso fundamen= tal que tiene como objetivo verificar y validar el funcionamiento correcto de un software o sistema. Su principal propósito es identificar defectos, errores= o fallas en el código, garantizando así la calidad del producto final. Para la creación de pruebas dentro del backend se utiliza Junit y Mockito dos libre= rías especializadas para las pruebas unitarias y de integración en java.

Las pruebas unitarias se aplicaron a la sección de servicios del Api, en la fig= ura 6 se presenta un ejemplo de las pruebas unitarias realizadas a la tabla de = actividad económica.

Figura 6

Ejemplo de pruebas unitarias

&n= bsp;

<= v:shape id=3D"Imagen_x0020_8" o:spid=3D"_x0000_i1032" type=3D"#_x0000_t75" style= =3D'width:358.5pt; height:192.75pt;visibility:visible;mso-wrap-style:square'>

Para las pruebas de integración se procedió a realizar el testing en los respectivos controladores con los que cuenta la Api, con la ayuda de Mockito se logra simular una base de datos para comprobar el procesamiento de los datos desd= e el ingreso a cualquier endpoint del controlador.

Despliegues

En esta sección se detallan las evidencias que indican que el servidor está en producción, así como los requisitos necesarios para desplegar el proyecto y= las solicitudes formuladas por los stakeholders para futuras actualizaciones. C= on el objetivo de facilitar el trabajo del personal de TI, el equipo de desarr= ollo ha implementado una solución mediante la creación de una máquina virtual de= ntro del entorno VMware. Esta iniciativa permite una rápida incorporación del servidor RiskAssistant, independientemente del virtualizador que se utilice= en las instalaciones correspondientes.

·         Evidencia del despliegue

El proyecto se encuentra ejecutan= do en los servidores de la cooperativa como se aprecia en la figura 7, para el= los se asesoró al equipo de TI para su respectiva configuración.

Figura 7

Diagrama de despliegue<= /p>

·         Requerimientos para futuras actualizaciones

Después de la entrega del proyecto y tras un periodo de uso del sistema, los usuari= os han proporcionado comentarios relevantes sobre posibles mejoras que podrían implementarse en futuras actualizaciones, estas sugerencias tienen como objetivo enriquecer el sistema y abordar nuevas necesidades de los usuarios= . En la tabla 10 se resumen los comentarios expresados por los usuarios, los cua= les serán considerados como recomendaciones en el contexto de este proyecto de titulación.

Tabla 10

Requisitos para actualizaciones de RiskAssist= ant

N°

Requisito

Descripción

1

Clave temporal

Para cambiar la contraseńa del usuario = el stackholder solicitó la asignación de una clave temporal para que el mismo usuario realice la actualización.

2

Riesgos de Créditos <= /p>

El paso siguiente es abarcar los riesgo= s de créditos por su similitud con respecto a los de liquidez.

3

Exportación de los reportes<= /span>

Permitir la exportación de los reportes= en formato de imagen o pdf.

4

Parametrización en la semaforización

Facilitar la administración de semafori= zación porque una reciente resolución explique sobre la eliminación de un nivel dentro de la semaforización.

Migraci= ón de datos

Se reconoce la importancia de contar con una documentación detallada de los pa= sos descritos en su obra. No obstante, se comprende que alcanzar este idealismo puede ser un desafío, dada la naturaleza dinámica de los proyectos. Mantener una documentación exhaustiva después de cada actualización implica un considerable esfuerzo. Por ello, se sugiere que un buen punto de partida es contar con un diagrama de flujo de alto nivel, un modelo de datos, el mapeo origen-destino y una descripción del proyecto.

Diagram= a de alto nivel

En la figura 8 se puede observar cuales son las características principales pa= ra tomar en cuenta dentro del desarrollo de los procesos ETL. Los procesos más comunes que se distinguen son las validaciones de los datos para evitar que exista información inconsistente como puede ser información vacía o null que conllevaría a un mal funcionamiento de RiskAssistant.

Figura 8

Diagrama de alto nivel<= /p>
<= v:shape id=3D"Imagen_x0020_6" o:spid=3D"_x0000_i1030" type=3D"#_x0000_t75" style= =3D'width:370.5pt; height:301.5pt;visibility:visible;mso-wrap-style:square'>

Fuente: Semantic Scholar (2013)=

Modelo = de datos y mapas de origen destino

La cooperativa por sus estándares de seguridad y recomendación del proveedor d= el sistema principal que utiliza la entidad financiera proporcionaron la información para realizar la respectiva migración mediante tablas visión creadas por área de TI. En la tabla 11 se puede apreciar los detalles sobre= la tabla visión VCATALOGOSTESIS la cual posee la información relacionada con l= as cuentas contables configuradas desde el nombre de las columnas hasta valida= r si las columnas aceptan valores null.

Tabla 11

Modelo de datos de la tabla VCATALOGOSTESIS

Nombre=

Tip= o Dato

Des= cripción

N

PK<= o:p>

FCONTABLE

Dat= e

Fec= ha de corte de la información de la fila

No<= o:p>

-

COFICINA

Num= ber (4)

Ide= ntificador de la oficina

No<= o:p>

-

CSUCURSAL

Num= ber (4)

Ide= ntificador de la sucursal

No<= o:p>

-

CUENTAS

Var= char2(20)

Cód= igo de la cuenta contable

No<= o:p>

-

DESCRIPCION

Var= char2(200)

Des= cripción de la cuenta contable

Si<= o:p>

-

MONTO<= /p>

Num= ber (19,6)

Mon= to de la cuenta contable

Si<= o:p>

-

El paso siguiente después de comprender la información de la tabla visión es relaci= onar dichos datos con la estructura diseńada para guardar los datos de las cuent= as contables dentro de la base de datos de RiskAssistant, en la tabla 12 se observa cual fue el resultado del análisis.

Tabla 12

Mapeo de la tabla VCATALOGOSTESIS a cuentas_contables

Dat= os Origen

Datos Destino

Nombre de tabla

Nombre columna

Tipo de dato<= /span>

Nombre de tabla

Nom= bre

col= umna

Tipo de dato<= /span>

=

=

=

cuenta_

contable

=

=

id_= cuenta_

con= table

int

=

=

=

est= ado_cuenta_

con= table

boolean

Tabla 12

Mapeo de la tabla VCATALOGOSTESIS a cuentas_contables (continuación)

VCATALO

GOSTESIS

=

CUENTAS

VAR

CHAR2<= /p>
(20)

cod= igo_

cue= nta_contable

nvarchar

(255)<= /p>

DESCRIPCION

VAR

CHAR2<= /p>
(200)<= /p>

des= cripcion_

cue= nta_contable

nvarchar

(255)<= /p>

Descripción general

El objetivo principal de la migración de los datos de la cooperativa hacia la base de datos de RiskAssistant se enfoca en preparar la información para que tenga relación = con la fórmula matemática que el usuario configuró dentro de la aplicación web. Dando continuidad al ejemplo que se ha venido desarrollando en los puntos anteriores se agregó una funcionalidad el cual es realizar una comparación = si existen nuevas cuentas contables que no están registradas dentro de la aplicación web de acuerdo con lo que se presenta en la figura 9.=

= Figura = 9

= Flujo f= inal para migración de cuentas contables

Fuente: Semantic Scholar (2013)=

&n= bsp;

&n= bsp;

Resulta= dos

La evaluación de la usabilidad es crucial en el diseńo y desarrollo de product= os y servicios digitales, y la norma ISO 25010 proporciona un marco para evaluar= la calidad del software, incluida la usabilidad. La norma explica cómo aplicar= los principios y criterios de la ISO 25010 en la evaluación de la usabilidad, c= on el objetivo de asegurar que la aplicación web implementada sea efectiva y satisfactoria para los usuarios. Analizaremos los diferentes aspectos de la usabilidad según los objetivos definidos, relacionándolos con la información recopilada a través del Cuestionario de Usabilidad de Sistemas Informáticos (CSUQ) para medir la usabilidad de RiskAssistant y abordando las diversas s= ub características de la usabilidad establecidas.

La encuesta CSUQ versión 3 consta de 16 preguntas de las cuales enfrascan las diferentes sub características de usabilidad. De esta lista se extrajeron únicamente las preguntas que corresponden a las sub características a evalu= ar, dando como resultado una encuesta que consta de 11 preguntas. Dado que la encuest= a de usabilidad ha sido modificada, se llevó a cabo un análisis de fiabilidad pa= ra confirmar su validez.

En la tabla 13 se muestra que el valor de alfa de Cronbach es 0.816 para el cuestionario utilizado en la medición de la usabilidad de la aplicación web= , lo cual se encuentra dentro de los niveles aceptables de fiabilidad, por lo ta= nto, puede ser empleado con confianza.

Tabla 13

Estadísticas de fiabilidad<= /i>

Alfa de Cronbach=

Alfa de Cronbach basada en elementos estandarizados

N de elem= entos

.816

.806

11=

Análisis de usabilidad por cada sub caracterí= stica

Para una mejor comprensión de los datos, se han organizado los resultados según = cada sub característica de usabilidad, como se presenta en la Fig. 10. En esta última, resalta la accesibilidad como la más destacada, con un porcentaje d= el 90.20%. Este valor indica que los usuarios pueden acceder al sistema y utilizarlo sin enfrentar dificultades significativas, sin importar su nivel= de experiencia. Sin embargo, se observa que la sub característica de aprendizabilidad requiere mayor atención, con un 72.38%. Esto sugiere que el sistema presenta ciertos desafíos en cuanto a la facilidad de aprendizaje p= ara los usuarios, lo que implica una curva de aprendizaje en su uso.=

Figura 10

Porcentaje de usabilidad según sus sub caract= erísticas

Análisi= s de resultados de usabilidad

En la figura 11 se detalla que, de las 7 personas encuestadas dentro de la cooperativa, el 77.97% calificó la usabilidad como favorable, mientras que = el 22.03% la consideró desfavorable. La calificación negativa se atribuye principalmente a la baja puntuación obtenida en la sub característica de ap= rendizabilidad del sistema, la cual requiere mejoras, como la integración de módulos más fáciles de comprender y aprender.

Para identificar qué secciones o módulos específicos están generando los problem= as, sería necesario realizar encuestas o entrevistas adicionales. Esto permitir= ía al equipo de desarrollo identificar las áreas problemáticas y trabajar en su mejora, con el fin de aumentar el nivel de usabilidad del proyecto para fut= uras actualizaciones.

Figura 11

Porcentaje de usabilidad de RiskAssistant

En la figura 12 se presenta una escala para evaluar el porcentaje de usabilida= d de un sistema. En ese contexto el resultado obtenido fue del 77,97%, lo que se considera aceptable según el rango de calificación B, ponderando la aplicac= ión web como buena.

Figura 12

Una comparación de las calificaciones de los adjetivos, los puntajes de aceptabilidad y las escalas de calificaciones escolares, en relación con el puntaje promedio del SUS

<= v:shape id=3D"Imagen_x0020_2" o:spid=3D"_x0000_i1026" type=3D"#_x0000_t75" style= =3D'width:379.5pt; height:129pt;visibility:visible;mso-wrap-style:square'>

Conclusiones

·      =    Se identificó cinco grupos de indicadores de liquidez mediante la revisión bibliográfica, los cuales nos ayudaron a representar la información para que el personal del área designa= da realice el análisis de cada índice y se pueda proporcionar una solución para mitigar los riesgos detectados.

·      =    Se desarrollo correctamente los mód= ulos de administración de usuarios, administración de índices de liquidez y generación de reportes. El desarrollo de la aplicación se llevó a cabo de manera adecuada, respetando las prácticas de programación y realizando el seguimiento a través de las iteraciones dictadas por la metodología. Logran= do finalizar el desarrollo del proyecto con los recursos destinados, cumpliendo así con la planificación.

·      =    La migración de información desde la base de datos de la cooperativa hacia la aplicación web fue un paso relevan= te para asegurar el éxito del proyecto. Este proceso se llevó a cabo utilizand= o el método ETL, garantizando así una migración ordenada, confiable y sin pérdid= a de datos. Esta migración facilita la persistencia del proyecto al proporcionar= una base sólida para su desarrollo continuo.

·      =    Tras evaluar a las 7 personas correspondientes a la muestra especificada sobre la aplicación web en térmi= nos de usabilidad, se observa que la accesibilidad alcanzó un 90,20%, la aprendizabilidad un 72,38%, la reconocibilidad de la adecuación el 75,71% y= la operabilidad un 73,57%. En conjunto, estos resultados conducen a una usabil= idad general de la aplicación web del 77,97%, calificando a la aplicación con una ponderación de aceptable.

·      =    Se consiguió la implementación de la aplicación web para el análisis de riesgos de liquidez de manera efectiva. = Esto es debido a la culminación de cada uno de los objetivos específicos consiguiendo así que el sistema sea aceptable en términos de usabilidad, lo= que implica que la entidad financiera se encuentra satisfecha con el producto f= inal.

Conflicto de intereses

Los autores declaran que no existe conflicto de intereses en relación con el artículo presentado.

Referencias Bibliográficas

Baena Toro, D. (2010). Análisis financiero: Enfoque, proyecciones financieras<= /i>. Ecoe Ediciones. https://www.ecoeediciones.com/wp-= content/uploads/2015/09/Analisis-financiero.-Enfoque-y-proyecciones.pdf

Beck, K., & Andres, C. (2005). Extreme programming explained: embrace change. Addison-Wesley. https://archive.org/details/extre= meprogrammi00beck/page/n9/mode/2up

Fernández Flores, H. A. (2011). Procesos de ingeniería de software. Vínculos, 6(1), 27-39. https://www.google.com/url?sa=3Dt&rct=3Dj&q=3D&am= p;esrc=3Ds&source=3Dweb&cd=3D&ved=3D2ahUKEwj-u5LyjLKHAxXQVTABHR= tzBKkQFnoECBMQAQ&url=3Dhttps%3A%2F%2Frevistas.udistrital.edu.co%2Findex= .php%2Fvinculos%2Farticle%2Fdownload%2F4141%2F5806%2F17311&usg=3DAOvVaw= 1ewU9yEKDdymrRI02w2Vgx&opi=3D89978449

Giordano, A. D. (2011). Data integration bluepr= int and modeling: techniques for a scalable and sustainable architecture. I= BM Press Pearson. https://www.oreilly.com/library/v= iew/data-integration-blueprint/9780137085309/

Guajardo Cantú, G., & Andrade de Guajardo, N. = E. (2008). Contabilidad financiera. McGraw-Hill. https://gc.scalahed.com/recursos/= files/r161r/w25145w/Contabilidad_financiera_6ta_ed_Gerardo_G.pdf=

Semantic Scholar. (2013). Systems and software engineering [ISO/IEC 25010]. Systems and software Quality Requirements and Evaluation (SQuaRE) https://www.semanticscholar.org/p= aper/ISO-IEC-25010-%3A-2011-Systems-and-software-—-Systems/57a5b99eceff9da2= 05e244337c9f4678b5b23d25

Kumar, M., & Chad Yadav, G. (2013). Liquidity risk management in ban= k: a conceptual framework. AIMA Journal of Management & Research, 7(2= /4). https://apps.aima.in/ejournal_new= /articlesPDF/Manish-Kumar.pdf

Microsoft. (2024). Accessibility Insights for W= eb. Microsoft. https://accessibilityinsights.io<= /span>

Morris, J. (2012). Practical Data Migration. BCS Learning & Development Ltd. https://books.google.com.ec/books/about/Practical_Data_Mi= gration.html?id=3DdveUyGMwNzwC&redir_esc=3Dy

Muńoz Jiménez, J. (2008). Contabilidad financiera. Pearson Educación. https://www.academia.edu/35591314/Contabilidad_Financiera= _1ed_José_Muńoz_Jiménez

Rivarola, G. & Lledó, P. (2007). Gestión de Proyectos - Cómo dirigir proyectos exitosos, coordinar los recursos humanos y administrar los riesgos. Prentice Hall. https://www.ingebook.com/ib/NPcd/IB= _BooksVis?cod_primaria=3D1000187&codigo_libro=3D5198

Superintendencia de Economía Popular y Solidaria [SEPS]. (2019). Nota técnica de la norma para la administración de riesgos de liquidez. https://www.seps.gob.ec/wp-content/uploads/Nota-Tecnica-N= orma-de-Liquidez_V5.pdf

Superintendencia de Economía Popular y Solidaria [SEPS]. (2024). żQué es la SEPS? https://www.seps.gob.ec/institucion/que-es-la-seps/

Warren, C., Reeve, J. M. & Duchac, J. (2016). Contabilidad financiera. <= /span>CENGAGE. https://latam.cengage.com/libros/con= tabilidad-financiera-2/

= ;

= ;

El artículo que se publica es de exclusiva responsabilidad de los autores y no necesariamente reflejan el pensamiento = de la Revista Alfa Publicaciones.

&nbs= p;

El artículo queda en propiedad de la revista y, por tanto, su publicación parcial y/o total en otro medio tiene que ser autoriz= ado por el director de la Revista Alfa Publicaciones.

= ;

Variable	Indicadores
= Usabilidad	= Aprendizabilidad
= Accesibilidad
= Operabilidad
= Reconocibilidad de la adecuación

Identificador<= /o:p>	Descrip= ción	Proceso	Consecu= encia
R01	Incorrecta planificación del proceso	Planifi= cación de sistemas de información.	Entrega atrasada del producto. Aumento de las pérdidas para la entidad financiera
R02	Mala estructuración de actividades	Planifi= cación de sistemas de información.	Mala coordinación de actividad Retraso en el cronograma
R03	Mal diseńo de la base de datos	Desarro= llo de sistemas de información.	Complicación en la manipulación de datos= . Imposibilidad de escalamiento
R04	Falta de comprensión en los requisitos software=	Planifi= cación de sistemas de información.	El producto final puede no cumplir con l= as expectativas del cliente o los usuarios.
R05	Falta de visión para elegir las herramie= ntas de desarrollo	Planifi= cación de sistemas de información.	Demora de tiempo en la etapa de desarrol= lo.

Rango de Probabilidad de incidencia	Grado de afectación
Descripción	Valor
1-33	Bajo	1

Retraso (semana)	Grado de afectación
Nivel	Definición técnica
1 semanas	Bajo	Retraso menor
2 semanas	Medio	Retraso moderado
3 semanas	Alto	Retraso severe
1 mes o superior	Critico	Suspensión del proyecto

Retraso Incidencia	Bajo	Medio	Alto=	Critico
Bajo	Pequeńo	Moderado<= /p>	Medio	Elevado
Medio	Bajo	Medio	Medio	Elevado
Alto	Moderado	Elevado	Elevado	Elevado

Identif= icador	Descrip= ción	Exposic= ión
Inciden= cia	Retraso=	Priorid= ad
R01	Incorre= cta planificación del proceso<= o:p>	Medio	Medio	Medio
R02	Mala estructuración de actividades	Alto	Bajo	Moderad= o
R03	Mal dis= eńo de la base de datos	Medio	Medio	Medio
R04	Falta de comprensión en los requisitos software	Bajo	Medio	Pequeńo
R05	Falta de visión para elegir las herramientas de desarrollo	Medio	Bajo	Bajo

Recurso Humano=	Numero de meses	Sueldo por mes=	Sueldo total
Wellington Francisco Cabezas Lucio	5	$ 450	$ 2250
Jhonnathan Rafael Castillo Quiroz<= /o:p>	5	$ 450	$ 2250
Total			$ 4500

Recurso	Tiempo de trabajo (Meses)	Deprecación por mes	Valor Total
Hp Notebook Pavilon	5	$ 17	$ 85
Dell Precision 7510	5	$ 10.833	$ 54.16
Servidor HP	5	$ 33.33	$ 166.65
Total			$ 305.81

Elemento	Estándar de codificación	Ejemplo
Clases	Pascal Case	Usuario
Métodos y funciones	Pascal Case	UsuarioRegistrado
Atributos y variables=	Snake Case	calcular_salario

N°	Requisito	Descripción
1	Clave temporal	Para cambiar la contraseńa del usuario = el stackholder solicitó la asignación de una clave temporal para que el mismo usuario realice la actualización.
2	Riesgos de Créditos <= /p>	El paso siguiente es abarcar los riesgo= s de créditos por su similitud con respecto a los de liquidez.
3	Exportación de los reportes<= /span>	Permitir la exportación de los reportes= en formato de imagen o pdf.
4	Parametrización en la semaforización	Facilitar la administración de semafori= zación porque una reciente resolución explique sobre la eliminación de un nivel dentro de la semaforización.

Nombre=	Tip= o Dato	Des= cripción	N	PK<= o:p>
FCONTABLE	Dat= e	Fec= ha de corte de la información de la fila	No<= o:p>	-
COFICINA	Num= ber (4)	Ide= ntificador de la oficina	No<= o:p>	-
CSUCURSAL	Num= ber (4)	Ide= ntificador de la sucursal	No<= o:p>	-
CUENTAS	Var= char2(20)	Cód= igo de la cuenta contable	No<= o:p>	-
DESCRIPCION	Var= char2(200)	Des= cripción de la cuenta contable	Si<= o:p>	-
MONTO<= /p>	Num= ber (19,6)	Mon= to de la cuenta contable	Si<= o:p>	-

Dat= os Origen	Datos Destino
Nombre de tabla	Nombre columna	Tipo de dato<= /span>	Nombre de tabla	Nom= bre col= umna	Tipo de dato<= /span>
=	=	=	cuenta_ contable = =	id_= cuenta_ con= table	int
=	=	=	est= ado_cuenta_ con= table	boolean

Alfa de Cronbach=	Alfa de Cronbach basada en elementos estandarizados	N de elem= entos
.816	.806	11=