UNIVERSIDAD NACIONAL DE UCAYALI

FACULTAD DE ING.DE SISTEMA Y DE ING. CIVIL

“AÑO DEL FORTALECIMIENTO DE LA SOBERANIA NACIONAL”

TAREA ACADEMICA

Curso: Practicas Pre Profesionales I

Docente: Mg. Diana Margarita Díaz Estrada

Estudiante:

 Gonzales Macedo Reylers Harol

Ciclo: VII
PUCALLPA-PERU
2022
1. Análisis de la empresa Lorito SOFT S.R.L

La empresa lorito soft dedicada al rubro de facturación electrónica y

manejo de inventarios para facilitar la administración de las
empresas en este presente informe vamos a definir y evaluar las
áreas de la empresa y ver de la mejor forma posible posibles
mejoras para expandir su crecimiento o soluciones a su situación
actual.

Después de la evaluación se elabora el proyecto para las practicas

dos, sería la implementación de la migración de la base de datos de
maríadb a dynamoDB por la próxima implementación que realizara
la empresa con su nuevo proyecto boltin
Debido a que algunas tablas son muy grandes y al solicitar
información es demorado por eso se requiere una base de datos
más rápida en este caso dynamoDB
Cronograma de actividades realizado en Gantt Project
 Análisis de requisitos
Requisitos de sistema

Equipo Procesador Ram SSD

Laptop Core I5 10TH 8gb 256
3.0 DDR4 GB
MV (Máquina 4 core 3.0 8b ddr4 90 GB
virtual)

Requisitos de software
 Lenguaje de programación en php
 JavaScript
 Base de datos DynamoDB
 Base de datos MariaDB
 Windows 10 64 bits

Requerimientos funcionales
1. Compartir datos entre aplicativos boltin y loritopos
2. Nueva base de datos sincronizada para compartir
informacion
3. El usuario pueda colocar sus productos de boltin y facturar
en lorito pos

Requerimientos no funcionales

 La información manejada por el sistema será objeto de

cuidadosa protección contra la corrupción y estados
inconsistentes, de la misma forma será considerada igual a la
fuente o autoridad de los datos.
 El tiempo de respuesta por consulta se realiza en tiempo real.
 El sistema debe permitir el inicio de sesión de forma segura,
autentificando al Usuario.
  Debe indicar el formato de la información a ingresar por el
administrador al sistema (número o letras) en su respectivo
campo.
 Definir las políticas de seguridad, privilegios y roles.

2. Diseño
Se finaliza la implementación de la base de datos actual manejada en
MariaDB, evaluando y revisando las tablas a migrar cada módulo y definir la
nueva estructura de datos para DynamoDB
Ya terminado lo anteriormente se da por finalizado la implementación del en
esta fase, por lo tanto, se debió comenzar con la documentación. En esta fase
de considera el Dimensionar el tamaño total requerido por tabla , como el
más importante, puesto que, nos muestra una visión mas amplia de la
migración a realizar .
La definición de las tablas transaccionales a migrar

Definición de estructura de los nuevos datos

 Son actividades netamente a realizar en papel

3. IMPLEMENTACION

 Dimensionar el tamaño total requerido por tabla para obtener costos para
reservar instancias esto se realiza en MARIADB para calcular las
instancias que se van a reservar para la migración

 Conseguir el rendimiento que necesitan las aplicaciones.

 Asegurar la cantidad física adecuada de espacio en disco

necesario para almacenar los datos y los índices.

Para realizar una estimación del tamaño de una base de datos, realizamos
estimación del tamaño de cada tabla por separado y sume los valores
obtenidos. El tamaño de una tabla depende de si tiene índices y, si los tiene,
del tipo de índices.
 Crear tabla e índices que repliquen solo primary key lo realizamos en
Google cloud y maría DB aquí se va realizar la replica de la primera base
de datos para la segunda en en DyamoDB la base de datos es no
relacional

 Crear CRON por usuario para ejecutar la migración. Una tarea Cron es

un comando de Linux que te permite ejecutar periódicamente un script o
comando de tu sitio web. Normalmente las tareas Cron son utilizadas
para la ejecución periódica de scripts relacionados con correo, bases de
datos o comprobaciones rutinarias.

 Crear Api lambda para recibir los datos y registrarlo en la nueva tabla.

En esta parte vamos a recibir los datos luego de la prueba de CRON de

la migración para registrar en las nuevas tablas en DyanoDB mediante el
api Amazon web services.
 4. PR

5. PRUEBA

 Pruebas de stress y end to end. Pasamos a realizar todas las pruebas

La prueba de estrés es un tipo de prueba de carga que se utiliza para

determinar los límites del sistema. El objetivo de esta prueba es verificar
la estabilidad y fiabilidad del sistema en condiciones extremas.

Las pruebas de estrés (stress test) son uno de los diferentes tipos de
pruebas de carga.

Mientras que las pruebas de carga se ocupan principalmente de evaluar

el rendimiento de los sistemas, el propósito de las pruebas de estrés es
 evaluar la disponibilidad y la estabilidad del sistema bajo una carga
pesada.

Pruebas end to end

El objetivo de estas pruebas es el mismo que cualquier otro tipo

de prueba: la detección de errores. Pero la perspectiva E2E nos permite
dar un paso más y, aparte de errores con una visibilidad más o menos
inmediata, podremos determinar la existencia de indefiniciones
funcionales o errores ocultos

 Iniciar el pase a producción y ejecución por parte de Operaciones esta

operación se realiza en Dynamodb se ejecutan los procesos de

maríaDB a dynamoDB

6. MANTENIMIENTO

Validar que la información este conforme con la cantidad de

registros enviados y procesados.
Este es el proceso donde verificación que toda la información se
realice correctamente ya migrado y periódicamente durante los
días estimados en el cronograma detallado. luego puede
utilizarse normalmente y que todos los usuarios y clientes tenga
acceso a la información.
Toda esta operación se realiza en dynamodb