MODELADO DE UN SISTEMA WEB DE
SERVICIOS FINANCIEROS ACOTADO POR EL
MARCO REGULATORIO DE LA CNBV
MODELING OF A WEB SYSTEM FOR FINANCIAL
SERVICES REGULATED BY THE CNBV FRAMEWORK
Esdras Eduardo García Espinosa
TecNM campus Acapulco, México
José Francisco Gazga Portillo
TecNM campus Acapulco, México
Jorge Carranza Gómez
TecNM campus Acapulco, México
Alma Delia de Jesús Islao
TecNM campus Acapulco, México
pág. 2470
DOI: https://doi.org/10.37811/cl_rcm.v8i2.10684
Modelado de un Sistema Web de Servicios Financieros Acotado por el
Marco Regulatorio de la CNBV
Esdras Eduardo García Espinosa 1
mm22320014@acapulco.tecnm.mx
https://orcid.org/0000-0002-9355-7929
TecNM campus Acapulco
México
José Francisco Gazga Portillo
jose.gp@acapulco.tecnm.mx
https://orcid.org/0000-0002-5629-3020
TecNM campus Acapulco
México
Jorge Carranza Gómez
jorge.cg@acapulco.tecnm.mx
https://orcid.org/0000-0002-0457-1842
TecNM campus Acapulco
México
Alma Delia De Jesús Islao
alma.dejesus.islao@uacm.mx
https://orcid.org/0000-0002-1725-9145
Universidad Autónoma de la Ciudad de México
México
RESUMEN
El objetivo de este artículo es presentar el modelado de un sistema web de administración de servicios
financieros acotado por el marco regulatorio de la Comisión Nacional Bancaria y de Valores (CNBV).
El sistema en mención cuenta con la capacidad de contribuir en las necesidades de gestión de una
Sociedad Financiera de Objeto Múltiple (Sofom) no regulada (ENR) en un entorno web, gestionando
las operaciones del cliente, el seguimiento de cobranza aplicando pagos y consultando saldos además
de contabilizar transacciones a través de una póliza contable. Para ello es necesario cumplir la
normatividad vigente que la CNBV dicta para la autorización, regulación, supervisión y sanción de las
Sofomes no reguladas, además del proceso de negocio que la Sofom utiliza para la gestión de solicitudes
de crédito, seguimiento de cobranza y contabilidad. Se utiliza la metodología de desarrollo de software
en cascada como marco de trabajo general para la automatización de los procesos de gestión de
solicitudes de crédito, seguimiento de cobranza y contabilidad conforme al marco regulatorio de la
CNBV.
Palabras clave: sofom, CNBV, desarrollo web, solicitud de crédito
1
Autor principal.
Correspondencia: mm22320014@acapulco.tecnm.mx
pág. 2471
Modeling of a Web System for Financial Services Regulated by the CNBV
Framework
ABSTRACT
The objective of this article is to present the modeling of a web system for managing financial services
regulated by the Comisión Nacional Bancaria y de Valores (CNBV). The system has the capacity to
contribute to the management needs of a Sociedad financiera de objeto multiple (Sofom) no regulada
(ENR) in a web environment, managing client operations, collection monitoring by applying payments
and checking balances in addition to accounting transactions through an accounting policy. To do this,
it is necessary to comply with the current regulations that the CNBV dictates for the authorization,
regulation, supervision and sanction of Sofomes ENR, in addition to the business process that Sofom
uses to manage credit applications, collection monitoring and accounting. The waterfall software
development methodology is used as a general framework for the automation of credit application
management, collection monitoring and accounting processes in accordance with the CNBV regulatory
framework.
Keywords: sofom, CNBV, web development, credit request
Artículo recibido 27 febrero 2024
Aceptado para publicación: 29 marzo 2024
pág. 2472
INTRODUCCIÓN
Una Sociedad Financiera de Objeto Múltiple (Sofom) es una institución financiera cuyo objetivo
principal es la actividad de otorgamiento de crédito, arrendamiento financiero o factoraje financiero
(CNBV, 2015). Las Sofomes son sociedades anónimas que cuentan con un registro vigente ante la
Comisión Nacional para la Protección y Defensa de los Usuarios de Servicios Financieros.
(CONDUSEF, 2015).
En el presente artículo se trabaja en conjunto con una Sofom no regulada que por fines de
confidencialidad y privacidad se referira a ella simplemente como “Sofom cliente”.
La Sofom cliente en cuestión, es una Sociedad Financiera de Objeto Múltiple no regulada (Sofom ENR),
encargada de ofrecer créditos individuales, grupales y empresariales con el fin de impulsar el desarrollo
de productos y servicios de los clientes. Con el crecimiento y expansión de la institución financiera en
cuestión, aunado a las regulaciones de la Comisión Nacional Bancaria y de Valores, surge la necesidad
de migrar la plataforma informática actual a un entorno web, la cual debe de cubrir las necesidades
vigentes de forma eficiente para mantener a la vanguardia los servicios que ofrece la Sofom cliente.
El presente artículo está motivado por el interés de proporcionar una solución tecnológica a la Sofom
cliente, que satisfaga los procesos administrativos en cuanto seguimiento de créditos, seguimiento de
cobranza y contabilidad, sujeto al marco regulatorio de la CNBV. Así mismo, se verifican las
representaciones del sistema (requerimientos y diagramas de diseño) para validar que el diseño del
sistema cumple con los estándares de la Sofom cliente.
El objetivo de este artículo es modelar un sistema web de administración de servicios financieros
regulado por el marco de la Comisión Nacional Bancaria y de Valores (CNBV) capaz de cubrir las
necesidades de gestión de la Sofom en un entorno web.
Marco Conceptual
Debido a que la Sofom cliente es una Sofom ENR, en primer lugar se requiere conocer el marco
regulatorio al cual está sujeto para el cumplimiento de las disposiciones preventivas de lavado de dinero
y financiamiento al terrorismo.
Además, dada la naturaleza de las operaciones realizadas por la Sofom cliente, es necesario cumplir con
los requisitos de organismos regulatorios, en este caso la CNVB, motivo por el cual, a continuación, se
pág. 2473
describen los organismos encargados de supervisar, en materia de indole financiero, a las Sofomes:
Secretaria de Hacienda y Crédito Público
La Secretaría de Hacienda y Crédito Público (SHCP) tiene como misión proponer, dirigir y controlar la
política del Gobierno Federal en materia financiera, fiscal, de gasto, de ingresos y deuda pública, con
el propósito de consolidar un país con crecimiento económico de calidad, equitativo, incluyente y
sostenido, que fortalezca el bienestar de las y los mexicanos (SHCP, 2023).
Comisión Nacional Bancaria y de Valores
La Comisión Nacional Bancaria y de Valores (CNBV) es un órgano desconcentrado de la Secretaria de
Hacienda y Crédito Público, con autonomía técnica y facultades ejecutivas. Se encarga de supervisar y
regular las instituciones que estén integradas al sistema financiero mexicano con el objetivo de procurar
su estabilidad y correcto funcionamiento (CNBV, 2022).
Por otro lado, es necesario conocer cómo se caracterizan las Sociedades Financieras de Objeto Múltiple,
así como las diferencias que puede haber entre ellas:
Sociedad Financiera de Objeto Múltiple
Las Sociedades Financieras de Objeto Múltiple (Sofomes) son sociedades anónimas que cuentan con
un registro vigente ante la Comisión Nacional para la Protección y Defensa de los Usuarios de Servicios
Financieros (CONDUSEF), cuyo objeto social principal es la realización habitual y profesional de una
o más de las actividades de otorgamiento de crédito (CNBV, 2015).
Las Sofomes pueden ser reguladas y no reguladas:
▪ Reguladas: La CNBV describe que son aquellas sociedades financieras que tienen vínculos
patrimoniales con sociedades financieras populares, sociedades financieras comunitarias o
sociedades cooperativas de ahorro y préstamo y aquellas que mantienen vínculos patrimoniales con
Instituciones de Crédito. De igual forma, son reguladas aquellas que, aunque no se sitúan en algún
supuesto mencionado en el párrafo anterior, voluntariamente soliciten y obtengan la aprobación de
la Comisión Nacional Bancaria y de Valores (CNBV), en los términos establecidos en el Artículo
87-C Bis 1 de la LGOAAC (Cámara de Diputados, 1985).
▪ No Reguladas: Son Sofomes que no están ubicadas en los supuestos señalados para identificarse
como "reguladas" y deben agregar a su denominación social la expresión "sociedad financiera de
pág. 2474
objeto múltiple" o su acrónimo "Sofom", seguido de las palabras "entidad no regulada" o su
abreviatura "E.N.R.". Estas se sujetan a la inspección y vigilancia de la CNBV, pero exclusivamente
con el propósito de verificar el cumplimiento de las disposiciones preventivas de lavado de dinero
y financiamiento al terrorismo (Art. 95-Bis de la LGOAAC). Las Sofomes "no reguladas" deben
proporcionar la información o documentación que se les requieran en el ámbito de su competencia
a la Secretaría de Hacienda y Crédito Público, al Banco de México, la CONDUSEF y a la CNBV.
Las Sofomes no reguladas pueden ser sancionadas en caso de no proporcionar dicha documentación
dentro de los plazos que tales autoridades señalen, o cuando la presenten de manera incorrecta
(CNBV, 2015).
Una actividad fundamental para solventar el problema planteado consiste en identificar desarrollos
similares a soluciones financieras, por ello acontinuación, se menciona brevemente una referencia
relacionada al desarrollo de una aplicación móvil de gestión de solicitudes de crédito nombrada como:
“Implementación de una aplicación móvil para la reutilización de solicitudes de crédito utilizando
webservices” que fue aplicada a una Sofom ENR, ésta fue necesaria para dar una solución propia que
satisfaga los requerimientos del sistema.
La investigación aborda el tema de implementar una aplicación móvil y un webservice para una
financiera en el puerto de Acapulco con el fin de agilizar el proceso de levantamiento, revisión y
aprobación de las solicitudes de crédito, el cual es realizado por los promotores de crédito y el área de
crédito (Salmerón, 2022).
El uso combinado del webservice y una aplicación móvil logra propiciar una herramienta útil y práctica
a los promotores y cualquier otro trabajador de la financiera que realice trabajo de campo y que cuente
con un dispositivo móvil, permitiendo generar solicitudes de crédito en tiempo real desde cualquier
punto en el que se encuentre el promotor.
La investigación demuestra como la implementación del servicio Web y la aplicación móvil dentro de
la empresa, agiliza el proceso de realización de solicitudes de crédito y la otorgación o rechazo de éstas.
Con lo expuesto con anterioridad, el artículo revela como las tecnologías de información son utilizadas
para brindar productos o servicios finacieros en el contexto mexicano futuro, estas herramientas
tecnológicas también son llamadas Fintech, que son la adopción de servicios financieros y de
pág. 2475
información a través de plataformas tecnológicas cuyo fin es simplificar una tecnología para el sector
financiero. (Rivera, 2019).
METODOLOGÍA
En una aplicación informática profesional, es importante guiarse por una metodología de desarrollo de
software que permita ofrecer un marco de trabajo, por ello la metodología de desarrollo utilizada es la
metodología en cascada. El modelo en cascada se considera como un flujo constante hacia abajo (como
una cascada). En este modelo, se debe seguir un riguroso orden en cada etapa que conforman el ciclo
de vida de un proyecto de software. (Chacon, 2010).
De hecho, dependiendo del autor, el nombre y etapas, dicho modelo puede variar ligeramente, el modelo
en cascada en ocaciones también es conocido como ciclo de vida clásico, en donde sugiere un enfoque
sistemático y secuencial para el desarrollo del software. La primera fase radica en la especificación de
los requerimientos por parte del cliente y avanza a través de planeación, modelado, construcción y
despliegue, para concluir con el software terminado (Pressman, 2010).
El modelo en cascada toma las actividades fundamentales del proceso de especificación, desarrollo,
validación y evolución para después representarlas como fases individuales (ver ilustración 1), siendo
estas: definición de requerimientos, diseño del sistema y del software, implementación y prueba de
unidad, integración y prueba del sistema y operación y mantenimiento (Sommerville, 2011).
A continuación se mencionan las etapas de la metodología de desarrollo en cascada, desarrollando
únicamente las primeras 2 etapas que corresponden a la definición de requerimientos y diseño del
sistema y del software que se cubren en este artículo.
Ilustración.1 Representación de la metodología en cascada por Sommerville.
pág. 2476
Etapas de la metodología en cascada
El resultado de cada fase en esta metodología consiste en uno o más documentos que han sido
autorizados por la Sofom cliente. Cada fase siguiente no debe comenzar hasta que la fase previa haya
finalizado.
1. Definición de requerimientos: En esta etapa se establecen los servicios, restricciones, así como las
metas del sistema a través de consultas a los usuarios del sistema cliente.
Se consulta a los asesores dentro de la Sofom cliente, así como los lineamientos establecidos en los
artículos de la Ley General de Organizaciones y Actividades Auxiliares de Crédito, la cual regula la
organización y funcionamiento de las organizaciones auxiliares del crédito (Cámara de Diputados,
1985). Posteriormente se definen con detalle alcances, propiedades y categorizacion que dan forma a la
especificación del sistema.
2. Diseño del sistema y del software: En esta etapa se asignan los requerimientos, tanto para sistemas
de hardware o de software, se establece una arquitectura global del sistema y con base a los
requerimientos obtenidos, éstos se transforman en diagramas específicos para representar abstracciones
del sistema.
Desarrollo de la metodología en cascada
Una vez acotadas las fases a implementar de la metodología de desarrollo, en las siguientes secciones
se describe cómo se llevó a cabo cada uno de los pasos mencionados. A continuación, se explica la fase
de definición de requerimientos.
Definición de requerimientos
Un requerimiento es un atributo necesario dentro de un sistema, una declaración que identifica la
capacidad, característica o factor de calidad de un sistema para que tenga valor y utilidad a un cliente o
usuario (Young, 2003).
Los requerimientos son condiciones o capacidades que se deben cumplir en un sistema o componente
para satisfacer un contrato, norma, especificación, u otros documentos, impuestos formalmente (C.
Wohlin et al., 2012).
Parte de la labor necesaria para recolectar estos requerimientos consistió en realizar la petición de
personal capacitado a los directivos de la Sofom cliente, quienes asignaron a un analista de crédito, un
pág. 2477
oficial de cumplimiento y un ingeniero en sistemas como asesores. Las entrevistas realizadas a los
asesores permitieron la recolección de información necesaria para documentar los requerimientos.
También fue necesario documentarse respecto a la Ley General de Organizaciones y Actividades
Auxiliares de Crédito para la elaboración de los requerimientos relacionados al marco regulatorio de la
CNVB.
En el siguiente apartado, se enumeran algunos de los requerimientos primordiales obtenidos mediante
entrevistas a la Sofom cliente. Estos requerimientos han sido extraídos del documento oficial de
requerimientos que consta de 22 requerimientos funcionales principales y 3 requerimientos no
funcionales principales de los cuales, de manera sintetizada, se presentan a continuación una muestra
de su caracterización de acuerdo a su relevancia, además se identifican atributos para cada uno de los
requerimientos que posteriormente serán de utilidad para la metodología en cascada.
Requermientos funcionales
De acuerdo con Sommerville, los requerimientos funcionales son enunciados acerca de servicios que el
sistema debe proveer, de cómo debería reaccionar el sistema a entradas particulares y de cómo debería
comportarse el sistema en situaciones específicas, éstos se vinculan con las entradas y salidas de los
procesos, así como los datos a almacenar en el sistema web. Los requerimientos funcionales principales
del sistema web para la Sofom cliente son:
Tabla 1. Requermiento funcional RF001
ID
RF001
Nombre:
Editar solicitudes de crédito.
Descripción:
El sistema debe permitir a los usuarios crear y modificar solicitudes de crédito
haciendo uso de los catálogos de productos financieros previamente establecidos en
la base de datos de la Sofom cliente.
Módulo:
Operación de crédito.
Prioridad:
Alta.
Dependencia
:
Ninguna.
Entrada:
Lectura del producto financiero y de los datos de la solicitud.
Salida:
Edición de la solicitud.
pág. 2478
Tabla 2. Requermiento funcional RF005
ID
RF005
Nombre:
Almacenar y descargar archivos digitales del cliente.
Descripción:
El sistema debe permitir almacenar documentos digitales del cliente en un
repositorio y a su vez descargarlos, consumiendo un servicio web propio de la
Sofom cliente.
Módulo:
Operación de crédito.
Prioridad:
Alta.
Dependencia
RF001.
Entrada:
Identificador de la solicitud de crédito.
Salida:
Carga y descarga de los archivos digitales.
Tabla 3. Requermiento funcional RF008
ID
RF008
Nombre:
Exportar póliza contable y visualizar reporte en PDF.
Descripción:
El sistema debe permitir a los usuarios generar la póliza contable de la SOFOM
E.N.R. en formato de texto plano para la paquetería contable CONTPAQi®
(CONTPAQi®, 2023) así como el reporte en formato PDF especificando por fechas,
el periodo de inicio y el periodo final.
Módulo:
Contabilidad.
Prioridad:
Alta.
Dependencia
RF-006, RF-007.
Entrada:
Periodo de inicio y periodo final.
Salida:
Archivo en texto plano con la información de cargos y abonos, reporte de póliza en
formato PDF.
Tabla 4. Requermiento funcional RF011
ID
Nombre:
Descripción:
Módulo:
Prioridad:
Dependencia
pág. 2479
:
Entrada:
Salida:
Requerimientos no funcionales
De acuerdo con Sommerville, los requerimientos no funcionales son limitaciones sobre servicios o
funciones que ofrece el sistema, se suelen aplicar al sistema como un todo, más que a características o
a servicios individuales del sistema. Un requerimiento no funcional primordial del sistema web de la
Sofom cliente es:
Tabla 5. Requermiento no funcional RNF001
ID
RNF001
Nombre:
Aplicar marco regulatorio de la CNBV.
Descripción:
Todos los procesos en los módulos de solicitud de crédito, seguimiento de
cobranza y contabilidad del sistema deben contemplar con la normatividad vigente
que establece la CNBV a la fecha.
Prioridad:
Alta.
Dependencia:
Ninguna.
Entrada:
No aplica.
Salida:
Aplica.
Con lo que corresponde a la actividad de diseño del software, ésta consistió en definir los alcances, las
propiedades y categorizacion de los requerimientos, dando lugar a diferentes tipos de diagramas que
tienen la finalidad de transitar por el espectro de niveles de abstracción que van a especificar con detalle
el desarrollo del sistema, tales como son:
▪ Diagrama de procesos de negocio: abstracción de los procesos de gestión de crédito en la Sofom.
▪ Diagrama de bloques y diagrama de componentes: abstracción de la arquitectura global del sistema
web.
▪ Diagrama de casos de uso: abstracción de los actores que participan en el uso del sistema web, así
como la interacción con los procesos de gestión de la Sofom.
▪ Mapa de navegación: abstracción de navegación para identificar la páginas que conforman el
sistema web.
pág. 2480
RESULTADOS Y DISCUSIÓN
Se toma como hecho que cada una de las etapas de desarrollo proporciona una representación distinta
del sistema final, una vez especificados los requerimientos en formato de texto, la etapa subsiguiente
consiste en construir un modelo gráfico en el que se destaquen las entidades, relaciones y propiedades
de los requerimientos funcionales y no funcionales.
La propuesta en cuanto al diseño, tiene que ver con el modelo conceptual, posteriormente se utilizan
diagramas para describir un aspecto más detallado del diseño del sistema, de esta forma se transita por
los diferentes niveles de abstracción para describir el sistema final.
En razón a lo anterior, se presentan diferentes diagramas que tomaron como base los requerimientos
funcionales y no funcionales, con el objetivo de tener distintos puntos de vista de la organización y
composición del sistema, debido a que cada diagrama representa un nivel de abstracción distinto a otro,
es posible representar a detalle las distintas vistas, funciones y organización del sistema.
Diseño del sistema y del software
Resulta útil que cada diagrama represente un nivel distinto de abstracción en la composición del sistema,
para ello se inicia con el diseño del Diagrama de Procesos de Negocio, con el fin de representar los
pasos que la Sofom cliente debe realizar para completar su proceso de gestión de crédito.
De forma subsecuente, se muestra un diagrama de bloques en conjunto con un diagrama de
componentes, con la finalidad de representar la arquitectura global del sistema web.
Una vez definidas las abstracciones anteriores, es necesario identificar a los actores que participan en
el uso del sistema web, así como la forma en la que estos actores interactuan con los procesos, para ello
se muestra un diagrama de casos de uso del proceso de solicitudes de crédito.
Cuando ya se cuenta con un conjunto esquemático con distintos niveles de abtracción, en complemento
con una arquitectura global del sistema, se prosigue a diseñar una estrategia de interacción para
identificar las páginas con las que debe contar la entrega final del sistema, para ello se utiliza un mapa
de navegación.
Diagrama de Procesos de Negocio
Comenzando por la parte de diseño, se muestra en formato reducido el modelado, que guía los procesos
de negocio de la Sofom cliente (ver ilustración 2), en donde se describe los 3 procesos principales:
pág. 2481
Crédito, Cobranza y Contabilidad.
Ilustración 2 Diagrama de Procesos de Negocio de la Sofom cliente.
Diagrama de bloques
Un diagrama de bloques es la representación de un sistema de control que, puede representarse por
diferentes símbolos, mismos que se interconectan entre sí para formar dicho sistema (Tinoco & Rojas,
2021).
Para mostrar una representación gráfica del sistema web, se desarrolló un diagrama de bloques (ver
ilustración 3) en dónde se identifican los aplicativos que tienen comunicación con el sistema principal.
El nivel de abstracción del presente diagrama permite también mostrar la interacción que hay entre los
siguientes aplicativos:
▪ Webservice: proporciona la carga y descarga de archivos digitales de los clientes.
▪ Aplicación móvil de cartera: para crear solicitudes de crédito.
▪ Aplicación cobranza móvil: gestiona pagos.
▪ API Servicio de Listas Negras: consulta personas bloqueadas.
▪ SQL Database: almacena la lógica de negocio de la Sofom cliente.
pág. 2482
▪ CONTPAQi®: carga la póliza contable exportada por el sistema web.
Ilustración.3 Diagrama de bloques de la Sofom cliente.
Diagrama de componentes (Arquitectura)
La arquitectura de software de un sistema representa una organización de un sistema y detalla un
comportamiento esperado, ésta proporciona una base sólida para contruir un software (Edraw, 2022).
La arquitectura de software es entonces la estructura del sistema que comprende elementos del software,
propiedades visibles externamente de esos elementos y las relaciones entre ellos (Maximiliano Cristá,
2014).
A continuación, en la ilustración 4, se muestra un diagrama de componentes que detalla la arquitectura
del sistema, dicho diagrama expone los componentes y procesos con los que cuenta el sistema de
administración de servicios financieros, siendo estos procesos: el seguimiento de solicitudes de crédito,
seguimiento cobranza y control de contabilidad. Además, se identifican los aplicativos con los que se
planifica realizar la comunicación en el sistema para su funcionamiento, como lo és, el uso de una API
para consulta de listas negras de alto riesgo y un webservice para la carga y descarga de archivos.
pág. 2483
Ilustración.4 Diagrama de componentes que muestra la arquitectura del sistema web.
Mapa de navegación
Un mapa de navegación es una representación visual de la jerarquía, las paginas y la información que
conforman un sitio web (Santos, 2023).
Un mapa de navegación es un esquema que puede contextualizarse como un árbol jerárquico que
representa la arquitectura de las páginas de un sitio web (Fetecua, 2021).
En la ilustración 5 se muestra un diagrama de navegación, éste a diferencia de los mostrados con
anterioridad, permite visualizar a detalle los servicios que estarán disponibles en el sistema web. El
mapa detalla la funcionalidad de login donde el usuario inicia sesión para posteriormente, por medio de
la barra de navegación, visualizar el estatus de las solicitudes de crédito, la consulta de saldos y de
pagos, contabilidad, prevención de lavado de dinero (PLD) y configuración de usuarios.
pág. 2484
Ilustración.5 Mapa de navegación del sistema web
Diagrama de casos de uso
Un diagrama de casos de uso es una representación que ilustra como los usuarios realizan acciones e
interactúan con un sistema en particular (Fonseca, 2022).
Un diagrama de casos de uso representa una unidad funcional y coherente de un sistema, en éste,
interactuan uno o más actores realizando acciones (Vega, 2010).
En la ilustración 6 se detalla el diagrama de casos de uso para el proceso de solicitudes de crédito, la
abstracción de éste, permite visualizar los actores, servicios y reglas de negocio obtenidas de los
requerimientos desde el punto de vista del usuario. El documento completo de requerimientos del
sistema hace referencia a dos tipos de categorización de usuarios para el proceso de solicitud de crédito,
por lo tanto, se cuenta con 2 actores con distintas atribuciones a este proceso, éstos son descritos a
continuación:
▪ Actor capturista de crédito: genera las solicitudes de crédito y envía estas a revisión.
▪ Actor jefe de crédito: revisa la solicitud y a su vez ésta extiende a modificar la solicitud y a
ministrar la solicitud.
pág. 2485
Ilustración.6 Diagrama de casos de uso de solicitud de crédito.
CONCLUSIONES
Con base a las necesidades de los usuarios, servicios y las reglas de negocio identificadas a través de
las entrevistas realizadas a los asesores, en conjunto con los lineamientos solicitados por la CNVB en
los documentos digitales de la Ley General de Organizaciones y Actividades Auxiliares de Crédito, se
construye un documento de requerimientos para la Sofom cliente, con el que se categorizan 22
requerimientos funcionales principales y 3 requermientos no funcionales principales, en donde para la
elaboración y comprensión de cada uno de los requerimientos se tomó en cuenta los atributos: nombre,
descripción, módulo, prioridad, dependencia, encargado de pruebas, entrada y salida, lo cual dio motivo
a que se elijieran diagramas representativos con distinto nivel de asbtracción que exhiben y revelan la
versión gráfica detallada de los requerimientos del sistema.
pág. 2486
Una vez definido el documento de requerimientos, la siguiente fase consistió en realizar su respectivo
modelado, por medio de los diagramas resultantes de la fase de definición de requerimientos, tal cual
son el diagrama de componentes y el diagrama de bloques, con éstos, se proporciona una arquitectura
global del sistema a desarrollar, aportando de esta forma una base esquematizada de la aplicación para
el usuario final así como la interacción que dicho sistema tendrá con los aplicativos actuales de la
financiera.
Por lo que se refiere al diagrama de casos de uso, éste modela los requerimientos funcionales: RF001,
RF002, RF003, RF004 del documento de requerimientos de la Sofom cliente, exponiendo con ello los
actores, servicios y las reglas de negocio, mientras que el diagrama de componentes está orientado a
mostrar un esquema global como sistema, modelando con éste, el requerimiento no funcional: RNF001.
Por otro lado, respecto a la navegación e interacción del usuario con el sistema, se proporcionó un mapa
de navegación (ver ilustración 5) para detallar la maquetación de la barra de navegación del sistema
web y así visualizar los servicios a los que el usuario podrá acceder como se muestra en la ilustración
7, tales servicios son: Configuración, Solicitudes de Crédito, Contabilidad, PLD y Caja.
Ilustración.7 Maquetación de navegación de la aplicación web
Los resultados muestran una construcción de las primeras dos fases de la metodología en cascada,
siendo estas: la fase de definición de requerimientos y la fase de diseño del sistema y del software.
El trabajo a futuro se orienta a construir la fase 3 de implementación y prueba de unidad, donde
principalmente se abordará las tecnologias a utilizar como son: lenguaje de programación C#, patrón
MVC, HTML5, LinQ, CSHTML y Razor y se sugiere como prueba de unidad realizar un documento
de pruebas donde se verifiquen la funcionalidad de los procesos del sistema web, para posteriormente
continuar con la fase 4 de integración y prueba del sistema, donde se verifiquen nuevamente con casos
pág. 2487
de prueba, las funcionalidades del sistema y así finalizar con la fase 5 de operación y mantenimiento en
donde se planea trabajar con una calendarización bimestral de revisiones, modificaciones,
actualizaciones correcciones y adaptaciones correspondientes al sistema y a las reglas de negocio de la
Sofom cliente.
REFERENCIAS BIBLIOGRAFICAS
C. Wohlin, P. Runeson, M. Höst, M. C. Ohlsson, B. Regnell, & A. Wesslén. (2012). Experimentation in
Software Engineering. Berlín, Heidelberg: Springer Berlin.
Cámara de Diputados. (1985). Ley General de Organizaciones y Actividades Auxiliares de Crédito.
Obtenido de www.diputados.gob.mx:
https://www.diputados.gob.mx/LeyesBiblio/pdf/LGOAAC.pdf
Chacon, M. V. (2010). Modelo en Cascada y Modelo en V. Obtenido de www.calameo.com:
https://www.calameo.com/read/000359039f05cc9907e95
CNBV. (2015). Sofomes. Obtenido de www.cnbv.gob.mx: https://www.cnbv.gob.mx/SECTORES-
SUPERVISADOS/OTROS-SUPERVISADOS/Descripci%C3%B3n-del-
Sector/Paginas/SOFOMES-Reguladas.aspx
CNBV. (2022). Comisión Nacional Bancaria y de Valores ¿Qué hacemos? Obtenido de www.gob.mx:
https://www.gob.mx/cnbv/que-hacemos
CONDUSEF. (2015). Sociedades Financieras de Objeto Múltiple ¡Una alternativa más, de servicios
financieros! Obtenido de www.condusef.gob.mx:
https://www.condusef.gob.mx/documentos/111134_CUADERNOSYVIDEOS-
SOFOMES.pdf
CONTPAQi®. (2023). Contpaqi. Obtenido de https://www.contpaqi.com/
Edraw. (2022). Diagrama de Arquitectura de Software. Obtenido de
https://www.edrawsoft.com/es/software-architecture.html
Fetecua, A. (2021). ¿QUÉ ES UN MAPA DE NAVEGACIÓN WEB? ¡LO QUE DEBES SABER!
Obtenido de https://designplus.co/blog/diseno-web/que-es-un-mapa-de-navegacion-web/
Fonseca, L. (2022). 10 ejemplos de diagramas de casos de uso (y cómo crearlos). Obtenido de
https://es.venngage.com/blog/diagramas-de-casos-de-uso/
pág. 2488
Maximiliano Cristá. (2014). Introducción a la Arquitectura de Software. Obtenido de
www.fceia.unr.edu.ar:
https://www.fceia.unr.edu.ar/~mcristia/Introduccion_a_la_Arquitectura_de_Software.pdf
Pressman, R. S. (2010). Ingeníeria de Software un enfoque práctico. México, D. F.: McGraw-Hill
Education.
Rivera, L. M. (2019). Prospectiva del Sector Fintech en México. Obtenido de
https://repositorio.unam.mx/: http://132.248.9.195/ptd2019/septiembre/0795298/0795298.pdf
Salmerón, R. O. (2022). Implementación de Aplicación Móvil para la realización de solicitudes de
crédito utilizando Servicios Web. Obtenido de ojs.Incaing.com.mx:
http://ojs.incaing.com.mx/index.php/ediciones/article/view/205/ronal
Santos, D. (2023). Qué es un mapa de navegación web y cómo crearlo. Obtenido de
https://blog.hubspot.es/website/mapa-navegacion-web
SHCP. (2023). Secretaría de Hacienda y Crédito Público ¿Qué hacemos? Obtenido de www.gob.mx:
https://www.gob.mx/shcp/que-hacemos
Sommerville, I. (2011). Ingeniería de Software. México: PEARSON EDUCACIÓN.
Tinoco, D., & Rojas, I. (2021). Resolución de diagramas de bloques Unidades de Apoyo para el
Aprendizaje. CUAIEED/SUAYED FESC-UNAM. Obtenido de
https://suayed.cuautitlan.unam.mx/uapas/02_Res_DiagramaDeBloques/
Vega, M. (2010). Casos de uso UML. Obtenido de
https://lsi2.ugr.es/~mvega/docis/casos%20de%20uso.pdf
Young, R. R. (2003). The Requirements Engineering Handbook. Boston London: Artech House.