CAPÍTULO 8. RECURSOS 8.1 Recursos humanos
A. persona_crud
10.3.4. Módulo de gestión de información
El módulo de gestión de información se compone de la siguiente información:
10.3.4.1. Pensionados
Figura 27. Resultado obtenido para la vista del listado de pensionados.
Fuente Realizado porautor
En la Figura 27 se visualiza el listado de usuarios registrados en el sistema tipificados como
pensionados (el cual se explica más arriba el cómo se compone); además, cada uno de los
registros permite la ejecución de la acción de Experiencia Laboral, la cual redirecciona al
usuario a la información registrada de la historia laboral que contempla el usuario dentro del
sistema.
10.3.4.2. Experiencia Laboral
Figura 28. Resultado obtenido para la vista del listado de experiencia laboral asociada a un pensionado. Fuente Realizado porautor En la Figura 28 se visualiza el listado de la historia laboral registrados en el sistema asociadosal pensionado seleccionado (el cual se explica más arriba el cómo se compone), la información
del mismo como nombres y apellidos se muestra en la parte superior de la tabla, con el fin de
que el usuario realice de manera adecuada el seguimiento a la visualización de la historia
laboral; además, cada uno de los registros permite la ejecución de la acción de Experiencia Laboral, la cual redirecciona al usuario a la información registrada de la historia laboral que contempla el usuario dentro del sistema.
Figura 29. Resultado obtenido para la vista del formulario de experiencia laboral asociada al pensionado.
Fuente Realizado porautor
También permite la creación de un nuevo registro, para el caso de esta opción se redirige al usuario al formulario de edición, donde se deberá de completar los campos requeridos por el sistema con el fin de que se pueda guardar el registro.
En el caso de editar un registro, se redirigirá al usuario al formulario correspondiente (el cual es el mismo de creación) donde se cargaran los datos del mismo, con el fin de cambiarlos en caso de que el usuario así lo desee.
La acción de eliminar permitirá borrar el registro seleccionado.
Finalmente la acción de monto a cobrar redirigirá al usuario al listado registrado que pertenece
al monto aceptado por la organización por concepto de la cuota parte generada a causa de la
pensión de la persona asociada.
10.3.4.3. Monto aceptado
Figura 30. Resultado obtenido para la vista del listado de monto aceptado por concepto de la cuota parte asociada a la experiencia laboral de un pensionado..Fuente Realizado porautor En la Figura 30 se visualiza el listado de los diferentes montos aceptados que puedan
presentarse en el sistema asociados al pensionado seleccionado y la organización en cuestión
teniendo en cuenta el periodo comprendido en las fechas (el cual se explica más arriba el cómo
se compone), la información del mismo como nombres y apellidos se muestra en la parte
superior de la tabla, con el fin de que el usuario realice de manera adecuada el seguimiento a
la visualización de la historia laboral; además, cada uno de los registros permite la ejecución de
la acción de Experiencia Laboral, la cual redirecciona al usuario a la información registrada de la historia laboral que contempla el usuario dentro del sistema.
Figura 31. Resultado para la vista del formulario del registro de un monto aceptado.
Fuente Realizado porautor
También permite la creación de un nuevo registro, para el caso de esta opción se redirige al usuario al formulario de edición, donde se deberá de completar los campos requeridos por el sistema con el fin de que se pueda guardar el registro.
En el caso de editar un registro, se redirigirá al usuario al formulario correspondiente (el cual es el mismo de creación) donde se cargaran los datos del mismo, con el fin de cambiarlos en caso de que el usuario así lo desee.
Figura 32. Diagrama de secuencia para el registro de un nuevo monto aceptado.
Fuente Realizado porautor
La acción de eliminar permitirá borrar el registro seleccionado.
Finalmente la acción de monto a cobrar redirigirá al usuario al listado registrado que pertenece al monto aceptado por la organización por concepto de la cuota parte generada a causa de la pensión de la persona asociada.
10.3.4.4. Cobro registrado
Figura 33. Resultado obtenido para la vista del listado de cobros registrados según el monto aceptado.
Fuente Realizado porautor
En la Figura 33 se visualiza el listado de la historia laboral registrados en el sistema asociados
al pensionado seleccionado (el cual se explica más arriba el cómo se compone), la información
del mismo como nombres y apellidos se muestra en la parte superior de la tabla, con el fin de
que el usuario realice de manera adecuada el seguimiento a la visualización de la historia
laboral; además, cada uno de los registros permite la ejecución de la acción de Experiencia Laboral, la cual redirecciona al usuario a la información registrada de la historia laboral que
contempla el usuario dentro del sistema. También permite la creación de un nuevo registro, para el caso de esta opción se redirige al
usuario al formulario de edición, donde se deberá de completar los campos requeridos por el sistema con el fin de que se pueda guardar el registro.
Figura 34. Diagrama de secuencia para el registro de un nuevo cobro registrado en el sistema.
Fuente Realizado porautor
En el caso de editar un registro, se redirigirá al usuario al formulario correspondiente (el cual es el mismo de creación) donde se cargaran los datos del mismo, con el fin de cambiarlos en caso de que el usuario así lo desee.
La acción de eliminar permitirá borrar el registro seleccionado.
Finalmente la acción de monto a cobrar redirigirá al usuario al listado registrado que pertenece al monto aceptado por la organización por concepto de la cuota parte generada a causa de la pensión de la persona asociada.
10.4. Pruebas
Con el fin de validar el funcionamiento adecuado del presente desarrollo realizado en este proyecto, se realizaron pruebas a nivel local con una herramienta de inspección de código, para este caso se empleó el uso de SonarQube, el cual es una herramienta automatizada para evaluar código fuente, la cual detecta bugs, vulnerabilidades y code smells (indican deficiencias en el diseño que puede ralentizar el desarrollo o aumentan el riesgo de errores o fallos en el futuro) . Es software libre y usa diversas herramientas de análisis estático de código fuente como Checkstyle, PMD o FindBugs para obtener métricas que pueden ayudar a mejorar la calidad del código de un programa.
Para la instalación del entorno de SonarQube se emplea un docker, el cual es una tecnología de código abierto de creación de contenedores que automatiza el despliegue de aplicaciones de software, proporcionando una capa adicional de abstracción y automatización de virtualización de aplicaciones en múltiples sistemas operativos; para realizar la instalación básica de docker basta con dirigirse a la página principal https://www.docker.com/get-started
donde se encuentra el link de descarga del archivo ejecutable con la instalación.
Figura 35. Instalación y ejecución en consola del docker de sonarqube.
Fuente Realizado porautor
En la Figura 35 se puede observar la línea de comando que debe de ejecutarse después de verificar que la instalación de dockerse realizó correctamente; estas líneas permiten descargar el contenedor con el entorno de SonarQube de una manera práctica, además de su ejecución en el puerto 0.0.0.0:9000 donde podremos acceder por medio de nuestro navegador.
Figura 36. Resultado obtenido al ejecutar el servicio de sonarqube localmente.
Fuente Realizado porautor
Para el caso de encontrarse el contenedor con sonarqube descargado de manera previa en nuestro sistema, docker le informará al usuario que no puede ejecutarse la última línea dado que ya existe un daemoncon el mismo nombre, con lo cual bastará con ejecutar el nombre de
nuestro daemon del contenedor de nuestro sonarqube el cual permitirá ejecutarlo e iniciará el proceso como se puede observar en la Figura 36, donde al finalizar la ejecución, nos informará que el contenedor se encuentra arriba (SonarQube is up).
Desde nuestro proyecto (temis_cliente) se debe de configurar el script para poder realizar la inspección de nuestro código, donde inicialmente debemos de instalar por medio de npm las librerías correspondientes como se visualiza en la Figura 37 o simplemente desde nuestro
package.json el cual se encontrará en el root del proyecto añadir las librerías y ejecutar el comando npm install desde la consola en la carpeta del proyecto.
Figura 37. Instalación por medio de npm de las dependencias para ejecutar sonar dentro del proyecto.
Fuente Realizado porautor
A continuación se debe de configurar el karma.conf.jsdesde el root del proyecto, añadiendo las siguientes líneas como se puede ver en la siguiente imagen:
Figura 38. Configuración del karma.config.js para la ejecución del sonar.
Fuente Realizado porautor
Y desde nuestro angular.json se debe de añadir desde el atributo options lo siguiente:
Figura 39. Configuración del angular.js para la ejecución del sonar.
Fuente Realizado porautor
Además, desde nuestro package.json debe de añadirse el scriptque se ejecutará para realizar el análisis de nuestro código añadiendo desde el atributo scripts del mismo lo siguiente:
Figura 40. Creación del script para la ejecución del sonar por medio de npm.
Finalmente, basta con configurar nuestro archivo de propiedades del sonar, el cual debe de crearse en el root del proyecto con el nombre de sonar-project.properties, el cual será el archivo que buscará de manera automática el scriptconfigurado, proporcionando la información necesaria que requiere para ejecutarse el inspector de código, tal como se ve a continuación:
Figura 41. Configuración del archivo sonar-project.properties para la ejecución del sonar.
Fuente Realizado porautor
Donde se puede observar que se excluye la carpeta que contiene las librerías instaladas por medio delnpm (node_modules), además de generar un nombre con el cual podremos realizar la consulta en el servicio de SonarQube desde el puerto configurado (9000 por defecto) y la carpeta de nuestro proyecto (para este caso se examina la **app/pages/**).
Con la anterior configuración realizada sobre nuestro proyecto podremos proceder a ejecutar nuestro script configurado: npm run sonar.
Figura 42. Resultado obtenido al ejecutar el npm run sonar dentro del proyecto temis_cliente.
Fuente Realizado porautor
Se ejecutará la inspección del código como se puede observar en la Figura 42, el cual generará un archivo al finalizar el proceso, el cual podremos consultar previamente desde el servicio en nuestro contenedor con los resultados obtenidos de la inspección.
Figura 43. Resultados obtenidos por la inspección sobre el código fuente de temis_cliente.
Fuente Realizado porautor
Los resultados que nos proporciona esta herramienta son bastante gráficos, donde nos permite la visualización de los diferentes resultados obtenidos de cada una de los parámetros que inspecciona de manera automática sobre nuestro código.
Figura 44. Resultados obtenidos visualizados por las carpetas que componen el proyecto dentro de app/pages.
Figura 45. Ejemplo de resultado obtenido según la inspección del código fuente.
Fuente Realizado porautor
Los detalles que nos proporciona el SonarQubeson bastante específicos, indicandonos la línea de código que presenta la molestia como se observa en la Figura x, además de indicarnos cual es el tipo de error que puede identificar como se observa a continuación:
Figura 46. Ejemplo de resultado de code smell obtenido en la inspección de código.
Fuente Realizado porautor
Fuente Realizado porautor
Figura 48. Ejemplo de bug resaltado por el servicio de SonarQube.
Fuente Realizado porautor
Figura 49. Ejemplo de vulnerabilidades que el sonar encontró en la inspección del código fuente.
Fuente Realizado porautor
Figura 50. Ejemplo de los code smell encontrados después de la inspección del código fuente.
11. Conclusiones
Implementación de los servicios que se presentan en los nuevos desarrollos que se generan en la Oficina Asesora de Sistemas, entre los más relevantes se hace el uso de un servicio genérico para la autenticación de usuarios dentro del sistema, lo cual combinado con los componentes de seguridad que proporciona la librería de Nebular, la cual permite una gestión sobre las funcionalidades del sistema sobre los diferentes usuarios que puedan ingresar.. Se destaca que dentro del desarrollo generado dentro del actual proyecto se implementa el consumo de servicios que se implementan en diferentes sistemas, dada que la información es genérica, lo cual permite hacer una centralización de datos, todo por medio del consumo de servicios de las APIs que se encuentran en el repositorio de WSO2 API Store, tal como los datos de personas, registros de experiencias laborales y datos paramétricos como lo son el IPC, DTF, organizaciones e históricos del salario mínimo legal, que son implementados dentro del sistema de cuotas partes pero que son necesarios también para algunos sistemas e incluso nuevos posibles desarrollos que puedan existir dentro de la dependencia.
La implementación del inspector de código de SonarQube para generar informes del estado del código fuente, además, de ser sencillo de implementar, presenta resultados sobre diferentes errores que pueden presentarse y pasarse por alto durante el desarrollo, los cuales, al prevenirse desde cada una de las etapas del desarrollo (sprints) genera un código amigable para la implementación de los otros módulos que componen este sistema y sirven como prevención de posibles errores o inconsistencias que se puedan presentar más adelante. Finalmente, la implementación de diferentes conceptos durante el desarrollo del presente proyecto proporcionaron conocimientos en diferentes campos, tal como el uso de metodologías ágiles, el modelado de datos, el uso de bases de datos relacionales (PG), el uso de frameworks de libre uso como lo son Beego y Angular, además de la plantilla de administración ngx-admin
y el manejo de autenticación de usuarios por medio del uso del framework AuthO2 por medio de token con JWT, implementando el LocalStorage para guardar los datos de sesión del usuario.